ct4laz

[avra]

I don't see any reason why you shoud not apply your valid fixes now.

Well, validity is in question here. Patches were only partially applied by the author, and although I asked for the reason - I have never received a reply, so I can only guess that there was something that the author didn't like. Without deeper understanding I can not defend these patches, only PilotLogic could do that (but that is hardly going to happen). I was hoping for the author to fix all compilation issues, but I am still puzzled with only partial fixes appliance without any feedback to reveal the mystery. That is the reason why I am not for changing CCR WST by myself, to avoid more mess. OPM already provides patched WST (I think that GetMem has applied all mentioned CT patches based on my DIFF files, but I use CT version so I would not know that for sure). OPM version is probably fine, and I am only advocating (a little) for CT version that I could host on ct4laz repo to avoid repatching when new version emerges.

Do you have the commit rights for CCR?

No, and because of the reasons already described I would not like to patch WST on CCR by my self. Regarding CCR, the first thing I would like to see is to completely delete MultiLog and LuiControls from CCR files, or leave only 1 readme file that would point users to author GIT repos which are maintained, unlike 11 year old files at CCR. That is pretty embarrassing for both components and CCR, and probably the case with some other CCR files. For MultiLog I know personally because I was involved in helping author making it thread safe (file logging), and implementing a TMemoChannel so several threads can write to gui Memo in a thread safe way. I have an impression that nothing of this will ever get into CCR, and even if it did it would be outdated soon, so I see no point to have it in CCR. Especially since they can be found in OPM now.
https://github.com/blikblum/multilog
https://github.com/blikblum/luipack

[avra]

I fixed the synapse issue.

I will check and let you know. Thanks!

Checked and works well. Tested with 32-bit 1.8.1+3.0.5 and with latest trunks on Win10. Thank you very much!

[balazsszekely]

Thank you @avra.

[avra]

I have attached Excel spreadsheet with all CT packages classified. Here is my loud thinking of further development (all ideas are welcome):

1.   Only pl_* packages and examples are interesting to us, so green colored will not end up in ct4laz repo.
2.   Yellow ones are already in OPM and it should stay that way.
3.   Orange ones are in OPM but taken from CT. They should probably all switch to ct4laz.
4.   Red ones do not exist in OPM. Some are CT unique, some exist elsewhere. There are some good candidates for OPM.

Currently, when extracting packages from typhon_src.7z and examples from CodeOcean.7z, I get a directory structure like this:

Code: [Select]

CodeOcean\
     pl_Abbrevia\
     pl_ACS\
     pl_AGGPas\
     pl_AGGPasVS\
     pl_APE\
     pl_ASIOVST\
     ...
typhon\
     components\
          pl_Abbrevia\
          pl_ACS\
          pl_AGGPas\
          pl_AGGPasVS\
          pl_APE\
          pl_ASIOVST\
          ...
For ease of maintenance I would like to keep such directory structure in the ct4laz repo too, so I need to know if that would be a problem for OPM? I see that OPM has some kind of group package that could be used to install both component package and related CodeOcean example dir package at once, but I have to ask before definite directory structure is made in ct4laz.

EDIT: Orpheus package info updated

[wp]

Just a small correction: Orpheus has been added to OPM recently.

[balazsszekely]

The directory structure from the OPM's point of view is irrelevant. I have no other choice but add the packages manually. I will have to remove the orange ones then add back the red + the orange ones.
When do you plan to start the conversion process? Once you're done I can do my part in 1-2 days or so.

PS: Please mark Orpheus as yellow since it's already in OPM.

[avra]

Just a small correction: Orpheus has been added to OPM recently.

Thanks for the info 

The directory structure from the OPM's point of view is irrelevant.

Nice 

When do you plan to start the conversion process? Once you're done I can do my part in 1-2 days or so.

Conversion process is not much time consuming. Testing is. I have a very tight schedule these days so no promises, but I hope pretty soon. 

Please mark Orpheus as yellow since it's already in OPM.

Done

OPM uses CT Vulkan package. I could not link it to anything from the http://wiki.freepascal.org/Vulkan, so ct2laz will not be able to convert Vulkan projects between Lazarus and CT unless CT version is used in both. It looks like PilotLogic is devoted to 3D (look at pl_Win_DirectX* packages - most are CT unique), so maybe we are on the safe side with CT version here. What do you think? To me CT version looks bigger then anything from the wiki, but someone up to date with the topic should have a word here.

Having more then one version of anything is something we should try to avoid whenever possible (remember synapse). Speaking of duplicates, pl_barcodes (barcodes package in OPM) is much richer then lazbarcodes (CCR version in OPM), and file comparison reveals the same origin. Compiling both asks for trouble, so I think that only one should stay. Either CT version, or CCR version if someone updates it with CT changes.

[wp]

Speaking of duplicates, pl_barcodes (barcodes package in OPM) is much richer then lazbarcodes (CCR version in OPM), and file comparison reveals the same origin. Compiling both asks for trouble, so I think that only one should stay. Either CT version, or CCR version if someone updates it with CT changes.

I once did a few fixes for it, therefore I kind of feel "responsible" for it after its creator has abandoned his child...

A quick comparison of the CCR and CT versions shows no dramatic differences. They added some more units for other bar code types, they fixed a divide-by-zero error, and they published some properties - nothing which requires too much work. I already fixed the divide-by-zero bug and published the inherited properties in the trunk CCR version. As for the new units I'll investigate where they come from and whether their license is suitable.

I'd vote to use the CCR version within OPM because it's under our control then.

[EDIT]
ok - found them. The added units belong to TurboPower SysTools. I think it would not be a good idea to mix this with LazBarcodes because LazBarcodes is licensed GPL, and Systools is MPL. Maybe it's better to begin a new folder SysTools on CCR (there used to be one according to http://wiki.lazarus.freepascal.org/FpSystools, but it is gone now).

[avra]

As for the new units I'll investigate where they come from and whether their license is suitable.

Thanks for looking into this. It is very much appreciated.

The added units belong to TurboPower SysTools. I think it would not be a good idea to mix this with LazBarcodes because LazBarcodes is licensed GPL, and Systools is MPL.

Nice catch. Mixing is not good. CT version should probably be avoided in this case. However could you please look into this:
http://blog.rubypdf.com/2014/07/18/zint-shared-library-change-license-from-gpl-to-bsd/
It looks like zint shared library is now BSD, so maybe LazBarcodes license can be changed also (to be commercial software friendly)? Does LazBarcodes use only zint shared lib or some other part of zint? According to http://wiki.lazarus.freepascal.org/LazBarcodes license is "GPL 3.0 as it is being inherited from the zint source code", so maybe a license switch is possible in this case? Can original author be contacted? Were there any contributors besides yourself?

[balazsszekely]

@avra

I have a very tight schedule these days so no promises, but I hope pretty soon. 

I'm also busy lately...no need to hurry.

OPM uses CT Vulkan package. I could not link it to anything from the http://wiki.freepascal.org/Vulkan, so ct2laz will not be able to convert Vulkan projects between Lazarus and CT unless CT version is used in both. It looks like PilotLogic is devoted to 3D (look at pl_Win_DirectX* packages - most are CT unique), so maybe we are on the safe side with CT version here. What do you think? To me CT version looks bigger then anything from the wiki, but someone up to date with the topic should have a word here.

It's fine by me. I do not have much experience with CT packages so I leave this issue to you. In the end all I need is a list with orange and red items + the link to the converted packages. 

@wp
I'd vote to use the CCR version within OPM because it's under our control then.
[EDIT]
ok - found them. The added units belong to TurboPower SysTools. I think it would not be a good idea to mix this with LazBarcodes because LazBarcodes is licensed GPL, and Systools is MPL. Maybe it's better to begin a new folder SysTools on CCR (there used to be one according to http://wiki.lazarus.freepascal.org/FpSystools, but it is gone now).

Ok then. Lazbarcodes has to be replaced with the one from CCR.

[wp]

Ok then. Lazbarcodes has to be replaced with the one from CCR.

I released the current trunk revision as v1.0.1 (https://sourceforge.net/projects/lazarus-ccr/files/LazBarcodes/lazbarcodes-1.0.1.zip/download); changes are described in my previous post. The update-json is at https://sourceforge.net/projects/lazarus-ccr/files/LazBarcodes/OPM/update_lazbarcodes.json/download

[balazsszekely]

@wp
The update json only contains the design time package, more over the name is "mbColorLib". I attach the json, please update in CCR. Thanks.

[wp]

Sorry for the inconvenience, done. I had copied the update-json of mbcolorlib, and obviously there was more to be changed than what I considered.

[balazsszekely]

@wp
No problem. Thanks for updating.

[wp]

I added TurboPower SysTools as a new project to CCR-trunk; it contains the barcode components (which were copied to pl_BarCodes by CodeTyphon), as well as some math-related units. A lot of stuff is still missing from the ported package, I am a bit hesitant because a lot is available already in fcl, lcl etc. I also don't know what to do with the astromony stuff which CodeTyphon has put into the Astronomy package along with other related units from other authors - another mixup. BTW, the author mentioned by OPM is not correct, all the St* unit are by TurboPower (I tend to add the astronomy units to SysTools from where they come).

A zip file for OPM will follow when I am sure about the package contents.