Hi to all and merry xmas,

I have some questions on the 2.4 version.

1)...will be the debug information availables on separated files or I'll need alway use the "strip" command to remove them?

2)...will be finally avaiable the "packages (as Delphi Bpl)" support (and if yes when will be available the first test version with packagees support)?

3)....when will be released the 2.4 version?

Debug information will still be stored inside the final executable (except for Dwarf on Mac OS X, because there the used tool chain does not do this). This step can be automated by both IDEs and the compiler (the -Xs compiler option; and if that one does not work properly, file bug reports).

Furthermore, it is always a good idea to compile all code going into a release version without debug information from the start, because when debug information is on some optimizations may not be performed (e.g., on PowerPC we always store the link register on the stack if debug information is generated, as dictated by the various ABIs).

That's why most IDEs feature debug/development/.. and release/ deployment/.. targets.

2)...will be finally avaiable the "packages (as Delphi Bpl)" support (and if yes when will be available the first test version with packagees support)?

That is not known at this point.

3)....when will be released the 2.4 version?

There is no planned time table for this. The next released version will be 2.2.2, and when that one will be released mainly depends on how long it will still take to replace all potentially tainted code in the rtl/fcl.

Jonas

Why is so hard deide to add package support?

Iss only a new feature, if one do not need it can simply do not use it!

For the debug inforrmation do you think will possible do not include them directly from compiler increasing optimization level?

2007/12/26, Jonas Maebe :

Op Wed, 26 Dec 2007, schreef Fabio Dell'Aria:

Why is so hard deide to add package support? Iss only a new feature, if one do not need it can simply do not use it!

It would require to ship the rtl as dynamic library, which is unstable in its interface, causing "DLL hell".

Patches are accepted though.

For the debug inforrmation do you think will possible do not include them directly from compiler increasing optimization level?

Debug info should be possible at higher optimization levels. I don't see what the problem is if you decide yourself wether you want debug info?

Daniël

Fabio Dell'Aria wrote

Why is so hard deide to add package support?

It's not about deciding, it's about being interested in doing and maintaining it.

For the debug inforrmation do you think will possible do not include them directly from compiler increasing optimization level?

I don't understand what you mean here.

Jonas

It would not be possible to ship the compiler and rtl as is today and let the user/programmer decide if his project will use packages?

Or necessarily, if the change is done, the only option will be use packages instead of unit files in all projects, including fpc?

If there will be a option i'm in favor of shipping fpc as is today and let the programmer decide if will use or not.

If there's no option i'm against the change.

Luiz

This is possible, but it simply doubles the size of the installer.

Maybe you did not understand.

My idea is *not* give the option to the programmer use the fpc rtl as package. It would be forbid to use the fpc rtl as package.

The feature would be available only for programmer own projects.

Did i miss something, technically? Is necessary to compile with rtl packages to distribute custom packages?

Luiz

Yes. If one package is used, everything else must be a package too (rtl, fcl, lcl etc.).

Op Wed, 26 Dec 2007, schreef Luiz Americo Pereira Camara:

Yes. Well, unless you want the RTL statically linked into each package, which will not work in a compatible way due the one heap/multiple heaps issues.

There is a solution though: Distribute the rtl in source code form and compile it on installation. This could also be an advantage for setting up cross compilation environments. But don't get excited yet: We may or may not move to such a system in the future.

Daniël

Thanks for the info. With this picture, i'm in favor of staying like is today. No packages.

Luiz

Why is not possible add the package support as is on Delphi (using Rtl.bpl, Vcl.bpl ...)?

Only if my project is compiled with packajes I must use all base packages, otherwise I can continue to compile my project as today just do Freepascal.

2007/12/26, Luiz Americo Pereira Camara :

Why is not possible add the package support as is on Delphi (using Rtl.bpl, Vcl.bpl ...)?

Time?

Ok,but if time is the only problem then why do not simple add the feature in the official and definitive 2.4 roadmap and try to add it in the next 6/12/24 months?

Is also possible add it as undocumented feature (as generics in 2.2) in the next 2.4 version and finish its implementation and testing in the 2.6 version.

2007/12/26, Florian Klaempfl :

Ok,but if time is the only problem then why do not simple add the feature in the official and definitive 2.4 roadmap and try to add it in the next 6/12/24 months?

It increases maintainance time for all future releases and the current team can't spend more time in release building and maintainance.

Ok, but do you think exists a so simple technology to can create plugin in freepascal (without use packages)?

2007/12/26, Florian Klaempfl :

Ok but whitout the full package support many companies will never uses Freepascal because is common think split big application in modules or simply sell extra application plugins.

What do you think about?

2007/12/26, Florian Klaempfl :

The simple answer is: companies really interested in packages might provide patches.

Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:

Ok but whitout the full package support many companies will never uses Freepascal because is common think split big application in modules or simply sell extra application plugins.

What do you think about?

Popular business languages (C++, Java, etc.) don't have package support, so apparently, packages aren't a decision maker for companies to select their programming language.

Of course, this does not exclude that some Delphi users highly appreciate the feature, and it could be a significant plus for fpc, but I am convinced it plays a micro-role in the total picture.

Daniël

Popular business languages (C++, Java, etc.) don't have package support, so apparently, packages aren't a decision maker for companies to select their programming language.

Because object pascal (OP) is NOT like other languages. That's why we love it or we won't use it at the first place. ;)

Of course, this does not exclude that some Delphi users highly appreciate the feature, and it could be a significant plus for fpc, but I am convinced it plays a micro-role in the total picture.

It's micro-role in the total picture of software business, it's correct. Anyway, OP is a niche language and won't fit the "total picture". But for OP developers or software business that came from Delphi background this feature is a must-have.

I also vote for it. Yes, I can live without it. But my life would be nicer and easier if it exists. :-D

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Can I use PPUMOVE tool to simulate basic packages features?

2007/12/27, Florian Klaempfl :

Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:

Can I use PPUMOVE tool to simulate basic packages features?

Depends, you can use ppumove to convert units into shared libraries and you can use such converted units like other units.

Daniël

Hi,

2007/12/27, Daniël Mantione :

Why "depends"?

In what circumstances I can use PPUMOVE to obtain the same Packages features/behavior ?

Daniël

Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:

If you want to dynamically link to a (group of) unit(s), ppumove can provide you this functionality.

Daniël

Can I also dynamically link to all RTL units (system.pp included)?

2007/12/27, Daniël Mantione :

Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:

Can I also dynamically link to all RTL units (system.pp included)?

Certainly, but I do not recommend to build a librtl.so containing all rtl units, as the amount of dependecies will be so huge that it'll be a challenge to get your program working on your users their systems.

Daniël

OK, but the important is that I can do this (using only my needed units).

Is this working on Win, Linux and MacOSX ?

2007/12/27, Daniël Mantione :

Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:

OK, but the important is that I can do this (using only my needed units). Is this working on Win, Linux and MacOSX ?

You will have to check yourself, I can confirm Linux though.

Daniël

Hi,

2007/12/27, Daniël Mantione :

I'm trying it on Win32.

What is the command to obtain a shared lib (dynamically loaded) for system.ppu, sysutils.ppu and sysinit.ppu ?

Daniël

Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:

Please read the documentation; we write it with reason.

ppumove -olibrtl.so system.ppu sysutils.ppu sysinit.ppu

... should do the trick.

Daniël

Yes but I just read the doc and I still obtain the following error:

Processing system.ppu...Error: PPU is already in a library : system.ppu Linking Error: no files found to be linked
Done.

Why? :(

2007/12/27, Daniël Mantione :

Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:

You can only use ppumove on a unit once, its ppu is marked as "moved" and the library in which it is stored is stored in the ppu. Once used, you need to recompile the unit to get a unmoved unit again.

Daniël

And RTTI, and duplicate symbols.

OK, but why on my PC:

ppumove system.ppu

return the following long error:

...
Cannot export fpc_write_text_widestr: symbol not found Cannot export fpc_writeln_end: symbol not found
Cannot export operatingsystem_result: symbol not found system.o: In function `SYSTEM_init':
system.pp:1103: undefined reference to `FindResourceA' system.pp:1103: undefined reference to `LoadResource' system.pp:1103: undefined reference to `SizeofResource' system.pp:1103: undefined reference to `LockResource' ...
Fatal: Library building stage failed.

2007/12/27, Daniël Mantione :

Op Fri, 28 Dec 2007, schreef Fabio Dell'Aria:

Seems it doesn't work on win32, so you are out of luck. Make ppumove dump its linker script and find out what it does wrong. You have to do it yourself, investigating Win32 linking problems is not something where I can be of any help.

Daniël

Hi,

can I simply add a bugreport in the Mantis Freepascal site related to this issue?

2007/12/28, Daniël Mantione :

Op Fri, 28 Dec 2007, schreef Fabio Dell'Aria:

Hi, can I simply add a bugreport in the Mantis Freepascal site related to this issue?

As interrest in the FPC team for these things is low, I recommend you find out what goes wrong yourself and then create a bug report so developers only need to make ppumove do the right thing.

Daniël

OK, but how I can: "Make ppumove dump its linker script and find out what it does wrong." ?

The -b options return the following .bat file:

ld -shared -E -o system.dll system.o

2007/12/28, Daniël Mantione :

Op Fri, 28 Dec 2007, schreef Fabio Dell'Aria:

OK, but how I can: "Make ppumove dump its linker script and find out what it does wrong." ? The -b options return the following .bat file:

That is the correct option.

ld -shared -E -o system.dll system.o

What is at least missing from this script is prt0.o, so I suggest to add it, and see what it does. Probably you also need to add some DLL import stuff as that was reported to be missing too (no idea how it exactly works in Win32).

As soon as the linker no longer complains, we can adapt ppumove to generate the script that way.

Daniël

Hi,

this is the results:

ld -shared -E -o system.dll system.o prt0.o

ld: prt0.o: No such file: No such file or directory

2007/12/28, Daniël Mantione :

Shared library creation (e.g with ppumove) is not supported on windows. The PE-COFF file format does not support real shared libraries like they are supported under unix. If you try it you will get linking errors as shown above.

Peter

But on the wiki I found same ppumove winnt examples:

http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7

2007/12/28, Peter Vreman :

Fabio Dell'Aria wrote

But on the wiki I found same ppumove winnt examples: http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7

I suspect that those docs are outdated. It's been quite some time since ar.exe needed to be copied to arw.exe or ld.exe needed to be copied to ldw.exe.

Regards,

Andrew

But if the doc is outdated then an old version works.

Is possible modify the current version to works (as the old version just done)?

2007/12/28, Andrew Haines :

you wrote

But on the wiki I found same ppumove winnt examples: <http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7>http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7

I've never seen a ppumove created library working under windows. PPUMove is nothing more than a simple wrapper around ld and changing a flag inside the ppu. Maybe it that time of writing the GNU ld produced some binary. But that was for sure no real DLL. The Win32 support in the GNU toolchain has always been worse and error-prone. It is the main reason why i wrote the internal linker first for this target.

There is and was never any package support in the existing code of fpc and support tools.

Ofcourse patches to fpc are welcome if you manage to get packages working.

Peter
Peter

Ofcourse patches to fpc are welcome if you manage to get packages working.

Or, if the hurdle to that is too large, then research to what is possible will already help tremendously.

Fabio Dell'Aria wrote

Why is so hard deide to add package support?

I suppose Lazarus would heavily use package support, as with same you can add custom components without recompiling Lazarus.

So it's important but it needs to be bug free from the start.

-Michael

Fabio Dell'Aria wrote: > Why is so hard deide to add package support? > I suppose Lazarus would heavily use package support, as with same you

As I said before, I doubt this because it would require that all packages are compiled separetly for every combination of fpc and lazarus version.

can add custom components without recompiling Lazarus.

Only if a package is offered for exactly the version of lazarus and fpc you're using.

This is possible, but it simply doubles the size of the installer.

The FPC Installer ? Same could compile the RTL etc as library and/or as a package on request (or the user project make process could do this once it's required).

-Michael

Then I don't get why people refuse that lazarus is recompiled and see dyn. loaded packages as _the_ solution to this "problem" :)

Is there another way of helping Lazarus to be able to let the user add components without recompiling the complete system ?

-Michael

Packages would do that of course. What Florian says just makes binary distributed packages possible.

But what is the exact problem with recompiling? Do you install multiple packages a day ?

Then I don't get why people refuse that lazarus is recompiled and see dyn. loaded packages as _the_ solution to this "problem" :)

Because the make process is just automatic and a not existing package that needs to be created just adds compile time (once) but does not need any user actions.

(IMHO, the main point for recommending Lazarus is that using it is simple for the average Delphi language programmer.)

-Michael

Then I don't get why people refuse that lazarus is recompiled and see dyn. loaded packages as _the_ solution to this "problem" :)

Is there another solution that makes it possible to compile and test a (future) visual component before installing it and with a simple click-click action add it to the component library (even if this involves waiting some minutes).

-Michael

Rebuilding/restarting lazarus is also automatic? Do you install daily packages in lazarus on a Pentium with 128 MB?

No. Not even Delphi has that. The property editors and component registrations must be known to the visual environment.

That's also why Delphi has a very definitive install step (in which you can see a reinit of the component palette, and e.g. problems can happen if components have been deleted from disk, but ignored on startup)

So it is roughly the same, except for the time, and the "hardening" of the process.

Rebuilding/restarting lazarus is also automatic? Do you install daily packages in lazarus on a Pentium with 128 MB?

I'm not a daily Lazarus user (yet). Maybe I'm still too little trained on this stuff :(.

-Michael

If you really care about a destroyed installation, test components in a vm.

Supposedly ? No, this is not correct. You install once and recompile as much as needed, that's it.

Michael.

But what is the exact problem with recompiling? Do you install multiple packages a day ?

Usually you don't.

But if you want to create a visual component, you supposedly need to install it several times when testing/debugging it.

-Michael

Supposedly ? No, this is not correct. You install once and recompile as much as needed, that's it.

So you suggest on a future (not too unusual) visual component that all testing can be done before having it (or the correct version of it) in the visual component palette ?

Is it possible to "install (and thus recompile) a preliminary version and use the source code of an updated one ?

So maybe all this is just a question of Lazarus not providing an "install visual component" feature that just includes recompiling Lazarus.

-Michael

It depends on how much IDE stuff the package needs.

Property Editors can be tested without the IDE by using the RTTI controls.

New codetools features can be tested without the IDE.

Some IDE parts can be tested with the SimpleIDEIntf package components/simpleideintf/simpleideintf.lpk. This package simulates a simple IDE to allow testing IDE experts at command line. It fills several objects and functions of the IDEIntf.

Experts and Component Editors need the whole IDE.

Mattias

No, obviously the component must be installed.

Is it possible to "install (and thus recompile) a preliminary version and use the source code of an updated one ?

This is by default always so.

Michael.

I'm not sure what you mean.
When you press 'install' in the package editor, the following happens:
- The IDE calls 'make IDE OPT=-Cn' to compile the IDE (not the LCL, not any component) without final linking. This is needed for packages using the IDE sources directly. FPC will only recompile what has changed.
- IDE compiles all changed packages
- IDE links the new IDE
- IDE restarts

Every step requires some checks. And the first time the OS has to load a lot of files into its cache, so it can take a lot of time the first time. After that the IDE rebuilds itself in a few seconds on a recent machine.
The first step could be omitted when the IDEIntf is good enough. We could ask on the mailing list if this is already the case. Maybe this halves the time needed for building.

Mattias

I'll have to retest doing a visual component in Lazarus....

Thanks,
-Michael

I developed several visual components for Lazarus and usually you install once and as you develop is not necessary to recompile the IDE, but are some exceptions:

1) The installed version crashes the IDE designer
2) You added a published event/property and wants to make a demo app that uses it through designer

Luiz

Thanks, I'll take care.

BTW. I always searched for a way to extend an existing visual component by some new properties or functionalities and move same into the palette and after this easily replace the old one by the new one in (multiple instances) an existing application.

Dis not find a n easy way in Delphi nor in Lazarus.

-Michael

Properties (and I think component editors too) can also be tested with the ObjectInspector example.

Marc

Zitat von Marc Weustink :

Right.
Component editors are the menu items for the designer. These can not be tested without the designer. But if the menu item only starts a dialog to edit a control, then you can test that dialog in a simple project. Hmm, maybe an article can be written about that.

Mattias

Is this a hint for me ? :-)

Michael.

Zitat von Michael Schnell :

Create a descendant:
Package Editor / Add / New component / ...

Test it and install it.

Change class of one control:
Designer / popup menu / Change Class

There is no dialog/option yet to apply Change Class to all controls of a class on a form or on all forms of a project/package yet. Although if the class was only extended, then probably this will work:
Close all designers and use
Search / Find in Files / Replace on .pas/.lfm files. The .lrs files will be automatically updated by the IDE on compile.

Mattias

Zitat von Michael Van Canneyt :

Naah, just thinking loud. ;)
Will you write it?

Mattias

Designer / popup menu / Change Class

Sounds great !

Thanks !

-Michael

If you meant for toolbox: sure :-)

Michael.

Works just fine.

I never found that feature in Delphi.

Applause to the Lazarus team !

-Michael