Converters (merged with Converters Docu)
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Converters
1.7.1 can has only bugfixes, no features.
Not even 1.8 but also 1.7 for Linux/BSD should be discussed and started.
I think, that further we can distribute some work. You can concentrate on handling found bug fixes for 1.7.1. At the same time another members can think about neccessary features for 1.8 and avaluate them in test builds.
I am defenitly will concentrate my efforts around 64-bit version and the version for Linux/BSD.
Not even 1.8 but also 1.7 for Linux/BSD should be discussed and started.
I think, that further we can distribute some work. You can concentrate on handling found bug fixes for 1.7.1. At the same time another members can think about neccessary features for 1.8 and avaluate them in test builds.
I am defenitly will concentrate my efforts around 64-bit version and the version for Linux/BSD.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Converters
Why not?Ivan Denisov wrote:1.7.1 can has only bugfixes, no features.
The principle behind the numbering is that the first number is the software compatibility level.
As longs as a simple recompilation suffices, at least for the vast majority of cases, it is 1.
If the forms subsystem or the text subsystem or other core parts of the library change significantly,
it would be 2.
The second number is the binary compatibility number.
as long as there is no (or almost no?) binary incompatibility it will be 7.
If a new command is added, for example, this does not affect the binary compatibility and it is still 7.
1.8 marks a (significantly) binary incompatible new version. This means you have to recompile
all your sources in order to upgrade.
This was, to my knowledge, always the idea behind the version numbers from ominc
and it worked quite well until 1.6, so why should that be changed now?
Big projects such as a native version for Linux or a 64 bit version cannot be handledIvan Denisov wrote: Not even 1.8 but also 1.7 for Linux/BSD should be discussed and started.
I think, that further we can distribute some work. You can concentrate on handling found bug fixes for 1.7.1. At the same time another members can think about neccessary features for 1.8 and avaluate them in test builds.
I am defenitly will concentrate my efforts around 64-bit version and the version for Linux/BSD.
inside the center with the current development process and resources.
This must be done offline, i.e. outside the center.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Converters
You right. If the feature is really required and binary compatible with 1.7 it can come to patch.Josef Templ wrote:Why not?Ivan Denisov wrote:1.7.1 can has only bugfixes, no features.
The principle behind the numbering is that the first number is the software compatibility level.
As longs as a simple recompilation suffices, at least for the vast majority of cases, it is 1.
If the forms subsystem or the text subsystem or other core parts of the library change significantly,
it would be 2.
The second number is the binary compatibility number.
as long as there is no (or almost no?) binary incompatibility it will be 7.
If a new command is added, for example, this does not affect the binary compatibility and it is still 7.
1.8 marks a (significantly) binary incompatible new version. This means you have to recompile
all your sources in order to upgrade.
This was, to my knowledge, always the idea behind the version numbers from ominc
and it worked quite well until 1.6, so why should that be changed now?
However features, what will have binary incomparability can be done as the additional components
I think, that important feature, that can be added in 1.7.1 is an package manager for easy install/upgrade/remove components.
I do not agree, because during the creation of the Center we decided to support another OS.Josef Templ wrote:Big projects such as a native version for Linux or a 64 bit version cannot be handled
inside the center with the current development process and resources.
This must be done offline, i.e. outside the center.
http://wiki.blackboxframework.org/index ... e_software
Current process and resources are such because we have nothing interesting to do.
If we will make more value, we also will have more people and more resources.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Converters
I always pointed out that 64 bit is a lot of work and not on my TODO list
as long as there is the Win32 API available.
If somebody wants to do it, fine, but:
Warning: It will need at least half a person year of concentrated work, probably more.
This is not trivial and you cannot do this in the usual issue/voting style.
It is a separate project that starts as a private project of one or several people.
The center cannot do much to help until it is finished, I am afraid.
Most center members are unable to get git running on their PCs, so how
should they be able to support the 64 bit project?
When it is finished, we can offer the web hosting, for example.
Good luck, anyway.
- Josef
as long as there is the Win32 API available.
If somebody wants to do it, fine, but:
Warning: It will need at least half a person year of concentrated work, probably more.
This is not trivial and you cannot do this in the usual issue/voting style.
It is a separate project that starts as a private project of one or several people.
The center cannot do much to help until it is finished, I am afraid.
Most center members are unable to get git running on their PCs, so how
should they be able to support the 64 bit project?
When it is finished, we can offer the web hosting, for example.
Good luck, anyway.
- Josef
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Converters
How shall we proceed with the open Converters discussion,
I mean, the export of the next field?
If it is not in 1.7 it will not be there for a long time.
- Josef
I mean, the export of the next field?
If it is not in 1.7 it will not be there for a long time.
- Josef
Re: Converters
I would vote to support just changing '-' to '*' in 1.7.Josef Templ wrote:How shall we proceed with the open Converters discussion,
I mean, the export of the next field?
If this is found to be inadequate, and a more involved solution is needed, it can be added in 1.8 when we have experience with the problems with this simple solution.
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters
See App Center Store
Installing CacketRtfConv places it at the end of the list of converters. I was going to say that it didn't work until I realized I had
selected the wrong converter (the standard rtf converter) when I tried it. I needed to scroll way down to the end of the
converter list to see the (Cachet) Rtf converter.
What I would prefer is to "replace" the Standard rtf converter with the Casket rtf converter. Making Converters.list modifiable
would make that possible. So there is another reason for
Installing CacketRtfConv places it at the end of the list of converters. I was going to say that it didn't work until I realized I had
selected the wrong converter (the standard rtf converter) when I tried it. I needed to scroll way down to the end of the
converter list to see the (Cachet) Rtf converter.
What I would prefer is to "replace" the Standard rtf converter with the Casket rtf converter. Making Converters.list modifiable
would make that possible. So there is another reason for
Code: Select all
TYPE
Converter = POINTER TO RECORD
next*: Converter;
imp-, exp-: Dialog.String;
storeType-: Stores.TypeName;
fileType-: Files.Type;
opts-: SET
END;
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Converters Docu
We forgot to change the documentation for Converters so I just did that.
I did a clone, modified docu, a commit, and a push. Worked.
Now I have forgotten whether it is necessary to do a second pull request for issue-#122.
Is it?
-Doug
I did a clone, modified docu, a commit, and a push. Worked.
Now I have forgotten whether it is necessary to do a second pull request for issue-#122.
Is it?
-Doug
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Converters Docu
Seems to be ok:DGDanforth wrote:We forgot to change the documentation for Converters so I just did that.
I did a clone, modified docu, a commit, and a push. Worked.
Now I have forgotten whether it is necessary to do a second pull request for issue-#122.
Is it?
http://redmine.blackboxframework.org/pr ... 56fd0937c7
Thank you, Doug, that you mentioned this.
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters (merged with Converters Docu)
I just did a "replace" in the Converters.list of 'rtf' with Casket's version. It worked and I preserved
the rest of the list. Thank's guys!
the rest of the list. Thank's guys!