BlackBox Framework Center

Make it as simple as possible...

Use (i.e. vote about using) GitHub unless there is a severe argument against it.
The advantages are:
It is free
It is widely used
It is managed by professionals
It does not put any CPU load regarding the repository on our EDIS server
It does not put any bandwidth regarding the repository on our EDIS server
It emphasizes the fact that BlackBox is open source

The disadvantages are:
It is 'overdesigned' with a lot of bells and whistles, but we will get used to it as others did
It has a learning curve, but the same holds for each of the Git and other SCM platforms
Any other strong objections? Please add to this list.

If there are no killer arguments, I would not consider any of the more exotic repository hosters/tools.
It will lead us into an endless evaluation phase with very limited value.
The only viable alternative is Google code, but this has been rejected
by center members because of our non-existing friends in Cuba
and I don't want to go into this discussion again.

My understanding of Git is that the hosting platform can be changed any time later
if there are serious problems. This results from the distributed nature of Git.
Any local working copy is a complete repository, and that can be used
to set up a Git repository on another hosting platform.
The bigger problem is the issue tracker.
But if that is redmine, it is independent from Github anyway.

- Josef

I agree with Josef, the GitHub looks good choice. However, I am suggesting to put this GitLab alternative as an option? Rene, can you please make some votes?

I wanted to repeat again that GitLab in future can be adopted to show binary diff files like I did with Redmine.

The sources from my point of view should be stored in binary format to reduce the difficulty for the developers to deploy blackbox from the repository and fix the issues.

Ivan Denisov wrote:I wanted to repeat again that GitLab in future can be adopted to show binary diff files like I did with Redmine.

The sources from my point of view should be stored in binary format to reduce the difficulty for the developers to deploy blackbox from the repository and fix the issues.

By 'binary format' do you mean encoded, compressed?

I believe he means the format used for BlackBox source files (*.odc). These are not the plain text files that are normally used in source code control systems.

Open up an odc file in NotePad or other text editor and you will see what I mean. Because they are not plain text it makes it difficult to use comparison tools or any other standard text processing application. However, if you do convert them to plain text then you lose any special formatting that the developer intended.

cfbsoftware wrote:I believe he means the format used for BlackBox source files (*.odc). These are not the plain text files that are normally used in source code control systems.

Open up an odc file in NotePad or other text editor and you will see what I mean. Because they are not plain text it makes it difficult to use comparison tools or any other standard text processing application. However, if you do convert them to plain text then you lose any special formatting that the developer intended.

Thanks Chris.

That is another reason why it would be nice if those comparison tools were written in BlackBox.
I do have the XSearch algorithm that can search arbitrary files for multiple strings in parallel which
is very fast. But that is not a 'dif' program. I think Helmut (and others) have dif programs.

DGDanforth wrote:I think Helmut (and others) have dif programs.

Helmut uses "Dos"
http://forum.oberoncore.ru/viewtopic.ph ... 040#p87015

Zinn wrote:How do I compare two different version of BlackBox?

1. Store the original version 1.6 of BlackBox in D:\BlackBox
2. Store the CPC Edition in D:\BlackBoxBeta
3. Install subsystem Dos in the working version of BlackBox
4. Select the Menu Dos -> Integrate…
5. Click in the group Compare on the button Blackbox and wait until it is done.
6. In the Log window you find a list of different files.
7. Click on one file in the list to see the differences.

That's my knowledge base.

Ivan,
Is Helmut's Dos solution more or less difficult that what you get with Git?
(I still do not know the distinction between GitHub, GitLab, ..., Redmine)

DGDanforth wrote:Ivan,
Is Helmut's Dos solution more or less difficult that what you get with Git?
(I still do not know the distinction between GitHub, GitLab, ..., Redmine)

I have tried Dos. It is good for local work, however you need to download dos (two, Spanish) copies of BlackBoxes on your machine and see the differences. With git you can see the changes on-line. That is better for the logging purposes.

For example,
here I fixed search bug and add Trim function to the Strings module:
http://redmine.molpit.com/projects/blac ... cbdd045d44
here I added the feature of single UTF characters concatenation:
http://redmine.molpit.com/projects/blac ... 92f9fda6e0

Ivan Denisov wrote: here I add the feature of single UTF characters concatenation:
http://redmine.molpit.com/projects/blac ... 92f9fda6e0

Ivan, It appears there is a missing "(*" in that code.


THEN new := DevCPT.char16typ

##=> email

Dear Wening Luo,

this is really awesome! It works! You have a very high qualification and an excellent understanding of BlackBox compiler. Fantastic.

Fix must looks as:

ELSIF ((f = Char16) OR (g = Char16)) & (op # plus) THEN new := DevCPT.char16typ

( I changed "newtyp := DevCPT.char16typ" to "new := DevCPT.char16typ" ).

I tested the fix for this code:

MODULE PrivTestUCharConcat; IMPORT StdLog;

CONST

Auni* = 410X + 430X + 431X + 432X + 433X + 434X;

PROCEDURE Do* ;

VAR

CP1251: ARRAY 5 OF CHAR;

BEGIN

CP1251 := 402X + 403X + 201AX + 453X;

StdLog.String(CP1251);

END Do;

END PrivTestUCharConcat.##<=

*)