Hello Lazarus developers!

My issue #0015641 + patch for improving converter is seemingly waiting for approval from Mattias G?rtner (as do some other patches of mine).

Now, is Mattias really the right person to check such a patch? He is busy. His main focus is not in Delphi converter. I perfectly understand he has better things to do than check my patches.

Better candidates for checking my code are the ones who want to use and test Delphi converter and then give feedback. There are many such people compiling Lazarus trunk and waiting to see improved features. How many people use and test the trunk version? I guess hundreds. That means I would certainly get feedback for my patches and would be motivated to work on any issues and improve it more. I know the patches themselves can be tested by anyone but it needs more effort and usually people just follow the trunk. That's what I do also.
A separate branch is good for new experimental features which would break the main project somehow. However, my patches clearly fix issues of an existing Lazarus feature.

Is this part of "growth pain" of Lazarus? There is a sentence in About dialog: "As Lazarus is growing we need more developers."
but nobody though of what it means in practice. How do you plan to attract new developers? By ignoring their patches? Rejecting a patch is one thing but ignoring it means there is a problem in the project's process and policy. They should be fixed.

Some other projects have much more unstable trunk versions. There are many developers submitting and it can cause clashes and crashes and tension and irritation and negative feedback and whatever but it also speeds up development. Usually the author is very motivated to fix a problem in his code if many people complain about it. I would be motivated in such situations at least.

So I suggest you to pass patches in more easily! There is a danger that some poor patches go through but it is much better than ignoring (mostly good) patches.

I have read that the power of open source is that hundreds of eyes can find problems in code better than 2 eyes.
It works only if the code ends up into a place where those eyes can see it. So if this new "loose" policy lets a problematic patch in, it will be spotted quickly. And, revision control lets you reverse any change, doesn't it? Nothing dramatic would happen.

About my original problem: How to get my converter patches to trunk? I understand you are careful with core features like the form designer. It interacts with other parts in complex ways.
Delphi converter is different. It is rather isolated and easier to manage. Nobody else works on it now. And my code is mostly good...

If you accept my patches strictly related to converter I promise to work on it based on feedback and bug reports, essentially maintaining that piece of code.

What you say?

Regards,
Juha Manninen

Hi Juha,
I know a number of people who would be interested in your delphi converter, including myself :)

An easy to use 3d modeling package has now gone open source:

www.delgine.com

https://sourceforge.net/projects/deled/

The project has currently been written using Delphi, but some of us would love to be able to convert it over completely to Lazarus/freepascal so it is multi-platform :)

This won't be easy as there is a LOT of delphi GUI forms and frames there, but it would be great if this could be done.

perhaps your delphi converter improvments could help us in this area :)

Keep up the great work :)

Perhaps I should try using lazarus from SVN instead of binaries and try your patch?

cheers,
Paul

Juha Manninen wrote

What you say?

When I first saw your converter patches I decided that first someone need to check the style of your patches. If it is wrong then correct you. And then we can give you rights to commit to delphi converter. I asked Mattias to review since previosly he has commented and commited to similar delphi converter issues.

Best regards,
Paul Ishenin.

Juha Manninen wrote

That's what I do also. A separate branch is good for new experimental features which would break the main project somehow. However, my patches clearly fix issues of an existing

A workflow we have adopted at work allows for experimental features, maintenance branches, an always stable branch and quick & dirty ideas branch. We promote features up the chain through branches, going from unstable to very stable. At any point in time we can cut a stable release of our "stable" master branch (Trunk in SubVersion speak).

I think Lazarus could benefit from such a workflow too. There seems to be more and more experimental feature that go untested because they are "experimental". Getting more developers to simply switch to another branch at allow testing of new features before they go to Trunk would be very beneficial. Beneficial to the Laz developers, end-users and definitely to the new feature maintainer - get people to test and comment on a new feature before it makes it into Trunk.

The workflow we use in our company is based on the idea of the Git project workflow (I'm not advocating please!). It works very well for us - maybe others could adopt something similar for there environments.

http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

I guess something like this could be adapted to SubVersion, but how good it will work or if it is possible is up to the Lazarus team.

Is there an official workflow document about the Lazarus project?

Regards,
- Graeme -

Years of experience with fpc showed that very few people are testing such branches. Even rcs aren't intensively tested, just look at the resource trouble with fpc 2.4.0

Hi.

I know a number of people who would be interested in your delphi converter, including myself :)

Good to know!
(Although it is not really MY converter, but I am willing to improve it.)

Wow, such a good test case!
I became curious and downloaded it and converted to Lazarus. Conversion worked better than expected. All the forms I opened looked good.

My patches for converter make it less verbose, not asking so many trivial questions. Now I see it still asks too many questions, about non existing units and properties. It should be made configurable to be fully silent and automatic.

perhaps your delphi converter improvments could help us in this area :)

Yes, the amount of questions is more reasonable now but there are still many things to improve.

Please remember that you still must make (lots of) manual changes to make your code compile and work. The converter doesn't try to fix windows dependent code or such things. In your code I see at least 2 things that need porting: OpenGL and jpeg. There is support for both in FPC/Lazarus (GL and pasjpeg) but I have no idea how difficult the porting is. At least the windows handles will not work.

Keep up the great work :) Perhaps I should try using lazarus from SVN instead of binaries and try your patch?

I hope I can develop the code for trunk. That would allow interaction with people who use it. Besides the isolated patches can end up being ignored forever, that's how I feel now...

<OT>
Your code has very many units. How did you solve the circular reference problem? I didn't make any deep analysis of your code but it looks clean. I could expect there are lots of cross references in such 3D design prog. Or, maybe there are some units full of type casting but I missed them. </OT>

Regards,
Juha Manninen

Florian Klaempfl wrote

Years of experience with fpc showed that very few people are testing such branches. Even rcs aren't intensively tested, just look at the resource trouble with fpc 2.4.0

Not to get into all that again (you can read the archives), but SubVersion doesn't lend itself to easily using branches. So I don't think the problem is the lack of developers wanting to test new features in other branches, but rather the effort (and time) forced by the repository system used. I simply don't have the time to wait 5 minutes for a new branch to be checked out, to simply find it totally useless, and then wait another 5 minutes to checkout out the previous branch I was using. Not everybody has super fast internet or uncapped bandwidth - which such testing with SubVersion would require.

Regards,
- Graeme -

I didn't have that experience when I was developing graphics in a separate lcl branch. I can't remember how I did it, but it was just one simple svn statement and a few secs waiting.

Marc

Yes, you showed that you have neither a clue about subversion nor git ...

but SubVersion doesn't lend itself to easily using branches.

... or did you ever here that Subversion has a switch command to switch easily and cheap between branches? Apparently not ...

The 2.4.0 release candidates were binary so the whole chain has been tested, but even the Linus fud believers could use your git branch. Nobody did so however and found the issues with the resources which probably requires 2.4.2 asap.

florian at ubuntu32:~/fpc/branches/trunk$ ifconfig eth0 | grep "RX bytes" RX bytes:57135108 (57.1 MB) TX bytes:1798253 (1.7 MB) florian at ubuntu32:~/fpc/branches/trunk$ svn switch http://svn.freepascal.org/svn/fpc/branches/fixes_2_4 > log florian at ubuntu32:~/fpc/branches/trunk$ ifconfig eth0 | grep "RX bytes" RX bytes:57681323 (57.6 MB) TX bytes:1814129 (1.8 MB)

Florian, I for one - which had tried some branches only a few times - think that the main culprits for this is lack of
information/advertisement of these/the relevant branches, and, not to copycat Graeme, the slowness of switching branches in svn. Yes, I know the switch command, as I used svn for quite time, coming from years of cvsnt use (and some frustration). Actually I've been using/trying svn regularly its early bdb days, as I had high hopes for it, but I always come back frustrated.
I'm not 100% sure it would/can work, but it sounds good in principle...

-Fl?vo

Florian Klaempfl wrote

florian at ubuntu32:~/fpc/branches/trunk$ svn switch http://svn.freepascal.org/svn/fpc/branches/fixes_2_4 > log florian at ubuntu32:~/fpc/branches/trunk$ ifconfig eth0 | grep "RX bytes" RX bytes:57681323 (57.6 MB) TX bytes:1814129 (1.8 MB)

OK, so I create a patch that modifies one line of code. This modification is in a new branch.

So you justify that I (and anybody else that wants to try out my one line change) downloads 57 MB for each 'svn switch' command?

 $ (I'm in Trunk)
 $ svn switch ....branch     ( it downloads 57 MB )
 $ (code, code, code)
 $ svn switch ....trunk   ( back to trunk and it downloads *another* 57MB )
 $ (oh wait, I want to try something else..)
 $ svn switch ....branch   ( oops, lets download yet another 57MB )
 $ (okay what I wanted to try doesn't work - let get back to trunk)
 $ svn switch ....trunk     ( it downloads again 57 MB )

I'm sorry but such waist of time and bandwidth is not for me and clearly not for others developers either.

Only alternative is to download 57MB for each branch, but in separate directory location - DON'T use 'svn switch'. But that means I need to keep updating my fpc.cfg settings or updating the Lazarus environment settings etc. to the new directory locations... To much effort.

Note:
I only have 500MB of data available per month on my 3G internet connection. That's 8x 'svn switch' using the FPC repository and I'm out of bandwidth! No more internet for the rest of the month!! So don't even bother asking me to locate a regression bug, which requires stacks of 'svn switch' commands.

See, I could have contributed more to FPC or Lazarus by searching where regression bugs were introduced or test new features, but I simply will not because I can't afford the waisted time, effort and bandwidth. This is probably why you experience that other developers also don't bother testing feature branches. Not everybody lives in a country with super fast internet or unlimited bandwidth.

Regards,
- Graeme -

Marc Weustink wrote

simple svn statement and a few secs waiting.

svn switch ....

But that downloads the whole repository every time you run that command. See my reply to Florian why this is an issue.

Regards,
- Graeme -

Then you do something wrong. It only downloads the diff.

Marc

Please read man ifconfig and Florians complete post. It is not Friday yet. ;-)

Vincent

Do actually believe what you write? Guess why I posted the total amount of traffic on eth0 before and after the switch ...

Who says that? His Godness Linus? Even the best compression cannot fold the FPC sources into 0.5 MB.

This is not correct. It downloads a diff. I do this multiple times a day. Try it.

Michael.

Florian, I for one - which had tried some branches only a few times - think that the main culprits for this is lack of information/advertisement of these/the relevant branches

But this is not svn's fault. We can tell only people to test RCs, no more no less.

Marc Weustink wrote

Then you do something wrong. It only downloads the diff.

Then my svn repository was seriously screwed or something, because it took forever and downloaded for ages. Since then I abandoned the idea of branches with SubVersion. [...I have to add, this was 3+ years ago...]

Regards,
- Graeme -

Graeme Geldenhuys wrote

Then my svn repository was seriously screwed or something, because it took forever and downloaded for ages. Since then I abandoned the idea of branches with SubVersion. [...I have to add, this was 3+ years ago...]

I don't think that it is a good idea to discuss this once per month. Please don't start this again at least in this mail-list.

Best regards,
Paul Ishenin.

Florian Klaempfl wrote

But this is not svn's fault. We can tell only people to test RCs, no more no less.

I tested 2.4.0-rc since the day it was announced. For once I did my part and even noted those issues in the wiki. But like YOU and other Lazarus team developers, the resources bug eluded us all. My excuse for not seeing the bug is probably because I don't use resources like Lazarus LCL (no external version information, no external forms, no external icons etc.).

So not all of us ignore announcements about RC releases. :)

Regards,
- Graeme -

There is 1 case where this can occur, namely when you do svn+ssh:// -> http://
even though it is the same repository, if you change protocol it will download the whole repository again.

In all the years that I use subversion I do the sw command multiple times a day, and it only downloads a diff.

Even CVS does that correctly.

Michael.

----- Original Message -----

Graham, PLEASE stop plugging git in any thread, dragged there by the hairs.

(I simply use multiple checkouts. I only use switch to switch between RC/release branches and fixes, but I keep trunk and fixes apart)

Paul Nicholls wrote

Is there anyway I could try out your Lazarus delphi converter improvements? What is the procedure for this?

Any comments from Lazarus developers?

Juha

How to try out a patch from others is explained here: http://wiki.lazarus.freepascal.org/Creating_A_Patch#Applying_a_patch

With kind regards,
Vincent

Vincent Snijders wrote

How to try out a patch from others is explained here: http://wiki.lazarus.freepascal.org/Creating_A_Patch#Applying_a_patch

Yes I know.
I was just hoping for comments on the original problem. How can people easily test my changes? I am not referring to this one set of patches only. I promised to work more on this feature, remember.

Can my changes be applier to trunk?
Or would you suggest a separate branch for me instead (even though not so many people would test it)?
If my changes were rejected for some reason it would be OK for me, but now they are just ignored and I am little puzzled of what is going on.

Regards,
Juha Manninen

Oh, but that was not the question from Paul Nicholls. Sorry for the misunderstanding.

If my changes were rejected for some reason it would be OK for me, but now they are just ignored and I am little puzzled of what is going on.

The most likely cause is that nobody with enough knowledge about the converter has the patch is pending, waiting for review.

Vincent

--- El jue 4-feb-10, Juha Manninen escribi?:

I tested the patch(es), it involves parts of Lazarus which I don't usually touch so I won't comment on the code but on the results.

In summary, yes, I think it's an improvement.

My comments are about the conversion process and don't know if the patch meant to fix some of the problems I found.

I was playing with some synapse samples and tried to convert some (I did it manually many years ago) when converting mime project sample (synapse39.zip/source/demo/mime).

* The first is the usual dialog where converter inform us that some properties are invalid and offer us to remove them. But this dialog needs some improvement for example when there is a component on form resource that is unknown, such as the case of for example TRichedit, maybe because it's provided by an user package or maybe the user wants to swap such class for a TMemo and then retry again to remove new invalid properties, etc.

* A dialog pops that some units are not found: dnssend, smtpsend, synautil, synamisc. It offer us to remove or comment them. I would be happy if: (the best) it makes an effort to find the best package (known by lazarus at that time) that provides these units and offer a list if find more than one and then add the requirement to converted project, or (the worst) it could ask where to find such units and add them to source path.

My selection this time was comment them, at this point the convertion process finished.

To fix the project so it compiled I have to do in addition:

* There is no main form visible (a no forms in forms list) although unit1.pas was added to project inspector. Doubleclicking the unit1.pas node in project inspector showed the form and form1 now appears in forms list.

* added synapse package requirement and uncommented the synapse units in mailchck.pas unit.

* saved the project and compiled. It failed with this: Error: Can't open resource file "/home/prog/work/synapse/39/source/demo/MailCheck/MailCheck.RES", .RES?, I looked into project source and found {$R *.RES}, simply changed *.RES to *.res and this time it compiled fine.

did it run? yes. did it work? no, at least no here in linux x86_64 but that is another matter :)

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

Hi,

Is there anyway I could try out your Lazarus delphi converter improvements?

I made a GitHub repository with my converter branch. It is an extra step but not really complicated for anyone interested in this feature. It is actually only 4 command line commands.

http://wiki.lazarus.freepascal.org/git_mirrors#Git_repository_with_Delphi_Converter_branch

I will copy the future converter improvements there, too.

And hey, this is not a political act in the battle between revision control systems. This is a practical act because I had my changes in a Git branch already.

The original problem has nothing to do with revision control systems. Parts of Lazarus code is known by very few people and they are busy. It is nobody's fault of course but still it leads to patches being ignored. Something should be done to fix this situation.

Regards,
Juha Manninen

The original problem has nothing to do with revision control systems. Parts of Lazarus code is known by very few people and they are busy. It is nobody's fault of course but still it leads to patches being ignored.

One cannot sit at home and wait for new patches coming in. Simply applying all patches without reviewing is usually a no-go so it takes usually a dozen of days till a patch is applied to trunk if the patch is accepted in principle.

Juha Manninen wrote

The original problem has nothing to do with revision control systems. Parts of Lazarus code is known by very few people and they are busy. It is nobody's fault of course but still it leads to patches being ignored. Something should be done to fix this situation.

Your patches have my focus, but I won't commit a bunch of changes just before I'm off for a short holiday. So when I'm back and noone applied, then you're on the top of my list.

Marc

Right. The dialog is used also for checking existing .lfm files. I think the same improvements would help there, too.
I started to collect a list of fallback components for some Delphi components. Now it has 3 items:

TRichedit -> TMemo
TValueListEditor -> ???
TCoolbar -> TPanel

When testing the big 3-D program Deled I got lots of errors while the converter was reading the form stream. Here are some screenshots of them. What could be the reason? Is it some new Delphi format?

http://koti.phnet.fi/juhamann/Lazarus/ReadError1.jpg http://koti.phnet.fi/juhamann/Lazarus/ReadError3.jpg http://koti.phnet.fi/juhamann/Lazarus/ReadError5.jpg http://koti.phnet.fi/juhamann/Lazarus/ReadError6.jpg http://koti.phnet.fi/juhamann/Lazarus/ReadError7.jpg http://koti.phnet.fi/juhamann/Lazarus/ReadError8.jpg

Non-existent properties don't cause such read errors but the "normal" dialog:

http://koti.phnet.fi/juhamann/Lazarus/FixLfmDialog.jpg

Interesting note: when I converted this big project using GTK2 build of Lazarus, it finally died for invalid floating point operation, about like with the qtcurve theme library earlier. QT build of Lazarus worked fine (no crash).

Yes. It should be more automatic.

* There is no main form visible (a no forms in forms list) although unit1.pas was added to project inspector. Doubleclicking the unit1.pas node in project inspector showed the form and form1 now appears in forms list.

I fixed it and copied changes into the github repo. I also did a major refactoring to the converter code. Now it is more object oriented. Earlier there were only functions, 1980's style pascal ... :-)

Right. Could it be located and changed easily with codetools? Dunno...

did it run? yes. did it work? no, at least no here in linux x86_64 but that is another matter :)

Fully automatic conversion will not happen, except for some trivial programs.

Juha Manninen

Hi,

The converter is improving gradually in SVN trunk. Converting the source code works better and there is an option to support Delphi compatibility with conditional compilation.

For Lazarus / LCL code, "Windows" is now replaced with "LCLIntf", "LCLType" and "LMessages".
I realized there are other windows specific units like "ShellApi". What should I do with it?

I haven't touched the missing components / properties problem yet. It needs much work.

Feedback is welcome.

Regards,
Juha

Why it is so? What if I want just to port to windows 64 and other platforms are not important? Maybe to have an option for this?

And even if we need an LCL equivalents then we need to replace Messages unit with Messages, LMessages. Imo Windows and LMessages are not very related.

I realized there are other windows specific units like "ShellApi". What should I do with it?

Leave as is - ShellApi is availble in fpc for the windows platform.

Best regards,
Paul Ishenin.

Hi,

I have understood LCLIntf", "LCLType" and "LMessages" are compatibitily units and most Delphi code compiles after adding them to uses section. Is it not so?

The converter UI could of course have 3 choices for conversion target:

1. Lazarus/LCL
2. Lazarus/LCL for Windows only
3. Both Lazarus/LCL and Delphi

What do you think?

Personally I don't understand why someone would make a Windows-only program using a multi-platform system like FPC / Lazarus.
...but that's just my thought...

Regards,
Juha

Well, even if we don't delve into that pit, when converting a program you typically first port it to windows, make it working, and only then start preparing for cross-platform.

Juha Manninen wrote

Personally I don't understand why someone would make a Windows-only program using a multi-platform system like FPC / Lazarus. ...but that's just my thought...

why? because they only work with winwhatever systems and they can't afford or simply don't want to purchase delphi and/or get stuck in something (else) proprietary... i'm sure there are other reasons out there, as well...

Personally I don't understand why someone would make a Windows-only program using a multi-platform system like FPC / Lazarus. ...but that's just my thought...

Do you know a similar open source Pascal compiler/IDE that is for Windows only? If yes, let me know, I will try it. If not, what are you wondering about? ;-)

1. Lazarus/LCL 2. Lazarus/LCL for Windows only 3. Both Lazarus/LCL and Delphi

I added those options.

I also realized that "LResources" unit is not needed any more because the converted files don't use LRS resources but the new Delphi compatible FPC resource.
LResources is not added now.

Regards,
Juha