Hi,

Just played with TProcess for the first time. (I come from Delphi 3) I observed some oddities (?, or maybe I'm just dumb ...).

If you try to execute a process that is non-executable (like for example a word doc), then on Windows an exception is raised and GetLastOSError returns 193.

If you try this on (my) linux, no exception is raised and a non-functional childprocess is forked (you can see it with ps ax). If you do this in a GTK 1 app, however, then the app gets killed. No errormessage, it just disappears.
On the console you can se some errormessage:
Xlib: unexpected async reply (sequence 0x4cf)

In GTK 2 app, there is no crash.

So 3 questions:

1.
Shouldn't trying to execute a non-executable file raise some kind of exception (like it does in Windows)?
If you try to execute a non-executable file from the console and query for the exitcode that bash returns, it will return an exitcode of 126, meaning: "Command invoked cannot execute" (Permission problem or command is not an executable)
(This errorcode is not known to the syserrormessage function b.t.w.)

2.
Why does the GTK 1 app crash? This might be a GTK bug and not fpc related.

3.
As a way to work arond this (and at least preventing the crash): is there a reliable way of cheking that a file can be executed in the first place? I know I can check for the execute permission of the file in question, but that is not enough (on my system any file copied from my windows partition to linux will have the x permission set).

I tend to try to make my (silly) programs foolproof, so it would be nice if either TProcess.Execute raises an error for this or I can implement my workaraound, so I can present the user with an appropriate errormessage, and not the app crash on him, or in the eyes of the user do nothing at all, when the user expects it to execute some other program...

Bart

This is because it is not waited for.

You cannot do this reliably. Starting a new process in linux is a 2-step algorithm:
1 Fork a clone of the current process.
2 Execute the program that you want executed.
If step 2 fails, then there is no way to return an error message to the parent process except a run-error code (127, I believe).

No, because this is bash-specific.

2. Why does the GTK 1 app crash? This might be a GTK bug and not fpc related.

I don't think it is fpc related.

You can use the fpaccess() call with X_OK for this; But it is not a bullet-proof guarantee. You must know for sure which file exactly will be executed.

Well, you can try using fpaccess.

Michael.

Yeah, found that out myself after fiddling around just a little more.

OK, I come from DOS, so my knowledge of "inside-linux" is alomost zero at this point, so I did not know this.
This makes me wonder, howevr, how bash can tell me that I tried to execute a non-executable file?

Well, learned 2 new things in 1 email ;-)

That would suck then, since I guess GTK1 is "dead" (in the sence that it is not maintained)?

In my case I do know what file is executed (at leat I think I do know, I supply the absolute path to the program), but checking for X_OK is not a foolproof guarantee (see my remarks above).

Well, you can try using fpaccess.

I borrowed this from somewhere in the code for the IDE (I believe):

function FileIsExecutable(const AFilename: string): boolean;
begin
  Result:= BaseUnix.FpAccess(AFilename,BaseUnix.X_OK)=0;
end;

Thanks, for your input.

Bart

Hello,

1. I start fp

2. I open file:

program HelloWorldv2;
{$mode delphi}
begin
        writeln('Hello Free Pascal World !');
        readln;
end.

3. I tried to compile/build to "Darwin i386".

4. Error/compile screen says:

Main file: Y:\..\helloworld\helloworldv2.pas
Failed to compile...
Target: Darwin for i386
Line number: 0 Total lines: 0
Used memory: 208K Allocated memory: 1504K
Total errors: 1 Compile time: 0.0s

5. FP about box says:

FreePascal IDE for Win32 for i386
Target CPU: i386
Version 1.0.10 2008/08/03
(Compiler Version 2.2.2)
(Debugger GDB 6.2.1)
Copyright (C) 1998-2008 by

Bérczi Gábor
Pierre Muller
and
Peter Vreman

I want to make little Hello World example for Mac OS X :)

How can I do this ? Little help/tutorial would be helpfull ;)

Website says FPC had compile bugs for Darwin ?

Compiler 2.2.2 is on my system do I need to update or something ?

Bye,
Skybuck.

I suspect cross compiling not functional.

I did find a free pascal compiler for Mac OS X so I ll give that one a try ;)

This does require compiling inside a virtual machine which is less ideal/slow ? ;)

And could expose source code but ok... net's disabled for now I hope ;)

Bye,
Skybuck.

That didn't go well.

Couldn't install package, the installer said.

RTF can't be opened.

So much for that.

Bye,
Skybuck.

See information about cross-compilation in FPC Wiki (http://wiki.freepascal.org/Cross_compiling) including the referenced documents like buildfaq.pdf. However, don't expect cross-compilation from Win32 to Mac OS X to be very easy.

Tomas

Skybuck Flying wrote

I suspect cross compiling not functional.

Not unless you installed the cross compiler, no.

I did find a free pascal compiler for Mac OS X so I ll give that one a try ;)

The native compilers work fine on both Intel and PPC Macs.

I believe building *nix cross compilers on Win32 can be a bit of a bear. Something to do with libraries and linkers from memory (hazy as I don't do Win32)

You can relatively easily build Win32 and Darwin cross compilers on Linux.

I build for all three(4) platforms from my Linux machine.

uname -a
Linux bklaptop2 2.6.27.7 #1 Sat Nov 29 13:35:51 GST 2008 i686 GNU/Linux fpc -Ppowerpc -Tdarwin test.pas
Free Pascal Compiler version 2.2.3 [2008/11/28] for powerpc Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Darwin for PowerPC
Compiling test.pas
Assembling hello_world
Linking test
5 lines compiled, 0.3 sec
file test
test: Mach-O executable ppc

Regards,
Brad

I suspect cross compiling not functional.

Then it's a surprise I can compile for Linux from my Win32 machine, just don't forget the i386-linux-ld. Don't expect you have cross compiling capability out of the box. Some tools and libraries might be needed depending on your needs.

Hello,

To make it easy for Delphi programmers to write code in Delphi and then switch to free pascal/lazarus the following could be done:

1. Export code from Free Pascal into Delphi packages so they can be installed in Delphi.
2. Export code from Lazarus into Delphi packages so they can be installed in Delphi.

This way Delphi users can make applications inside the Delphi IDE, using libraries/code from Free Pascal and Lazarus.

For example some runtime libraries/routines and some Lazarus widgets/gui components.

Then later the user/code could be switched to free pascal/lazarus.

This means code-compatibility with Delphi *is* important, otherwise too many porting issue's.

This also means the user can get used to Lazarus and Free Pascal code inside the Delphi environment and get used to it first before actually switching to free pascal and lazarus ide... otherwise the switch to different tools, and different language and different runtimes/libraries is to great !?!?

Finally the big benefit of free pascal should be cross compiling... therefore FreePascal could come with as many cross compilers and cross linkers as possible, the same for Lazarus.

This is probably the biggest benefit of free pascal: cross compiling.

Otherwise I don't see any benefit to switching to free pascal.

Delphi's IDE is still more stable than Lazarus IDE.

Delphi's compiler still works pretty good.

Free Pascal compiler can do 64 bit but no performance benefits so far ?!

I would be interested in learning about any Lazarus/GUI Packages available for Delphi ?!? If these already exist... please point me towards them ;)

However currently I am interested in cross compiling to darwin/os x which seems not included :( so that sux.

Also I am willing to provide cpu-power for compiling. So if "the team" needs more cpu-power for compiling then I suggest the following:

Create a filedisk image containing all necessary tools and code and batch files or scripts to make the compiling automatic.

Then I or anybody else should be able to download the image, mount it, run a batch file and voila... everything gets compiled automatically without having to follow a zillion tutorials and a zillion downloads and installs ;)

I would also be interested in helping out with creating such a file disk image... but then I still need more instructions...

For example how to build the free pascal runtime library units... something like that. I am probably not the best candidate to do this because I understand very little about all these files which seem like a zillion files ! ;)

Also when cross compiling to many different platforms then different binary files might have to be generated.

I am not sure but I think currently *.o is always the default extension... maybe this should be changed to something like:

o.mswindows32
o.mswindows64
o.osx32
o.osx64
o.dos16
o.dos32
o.linux32
o.linux64

etc.

And finally ofcourse the executables themselfes.

exe.mswindows32
exe.mswindows64
osx32 (in case no extension then just keep suffix) osx64

For distributions the programmer could simply remove the extensions.

In case many extensions need to be removed then a little tool/command could be made which does it for the programmer for example:

"Prepare for Distribution"

This deletes all *.o and then copies *.o.target to *.o and *.exe.target to *.exe

So for example:

// first delete junk from previous distribution:
delete MyUnit.o
delete MyApplication.o

// make new distribution:
copy MyUnit.o.mswindows32 to MyUnit.o
copy MyApplication.exe.mswindows32 to MyApplication.exe

Bye,
Skybuck.

"Free Pascal compiler can do 64 bit but no performance benefits so far ?!"

I am developing a GA (genetical algorithm) that needs a large amount of data to work with.
My development machine has 64 GB RAM and 4 cores.
In that space, I can run simultaneously 4 processes that each use 16 GB of data (Intraday stock market of all ticker symbols of years of data).

This would have been impossible with Delphi. It's not even a performance issue in my case.

Why should I/we spent time into improving other people's software (making a delphi plugin) instead of improving our own software (debugging lazarus)?

The whole point of FPC/Lazarus is not needing Delphi. Efforts should go directly towards this goal.

Also, in general, the feasability and amount of work is heavily underestimated. It is technically next to undoable, and magnitudes more difficult to get it working then to do the same in lazarus.

In theory, all problems can be worked around, and heaps of developers have stressed that. However none of them that tried came up with even halfworking code, they all stumble on the complexity, magnitude of the task.

For starters, because you don't have Delphi in source.

Otherwise I don't see any benefit to switching to free pascal.

Well, above lists another example, you have total system control. This gets important if you have massive applications that you want to maintain indefinitely. The Kylix history clearly illustrates this.

Delphi's IDE is still more stable than Lazarus IDE.

Personally, debugging annoys me more than that. Delphi dies daily on me too.

Delphi's compiler still works pretty good.

But to get it up to par with FPC, I have to buy the most recent one.

Free Pascal compiler can do 64 bit but no performance benefits so far ?!

There were never supposed to be any.

I would be interested in learning about any Lazarus/GUI Packages available for Delphi ?!? If these already exist... please point me towards them ;)

It's not clear what you mean here. Several packages can be used both with Lazarus and Delphi, like Indy.

However currently I am interested in cross compiling to darwin/os x which seems not included :( so that sux.

Because it is hard, and limited. Advanced topics need advanced skills.

Create a filedisk image containing all necessary tools and code and batch files or scripts to make the compiling automatic.

This is not possible, some files needed for OS X crosscompilation are copyrighted.

Still, the situation could be made easier. I hope that some of the people that need it urgently start working on making that happen. (hint, hint)

batch file and voila... everything gets compiled automatically without having to follow a zillion tutorials and a zillion downloads and installs ;)

And I hope that some users will pull their own weight, and invest some time too. The team already invests enough.

I would also be interested in helping out with creating such a file disk image... but then I still need more instructions...

People have succeeded crosscompiling to OS X by reading the buildfaq. Try harder.

For example how to build the free pascal runtime library units... something like that. I am probably not the best candidate to do this because I understand very little about all these files which seem like a zillion files ! ;)

The library situation is complex and unfinished. Specially the portable situation

I am not sure but I think currently *.o is always the default extension... maybe this should be changed to something like:

No. This info is already in the .o, and can be read using various tools like objdump. This causes only more trouble in calling the linker

(workarounds with renaming removed. Computers are easier confused than users, so no point in that)

> Free Pascal compiler can do 64 bit but no performance benefits so far ?! There were never supposed to be any.

64-bit code can, in some specialist cases, be made to execute in about double the speed of 32-bit code due to the wider registers. The availability of more registers is another speed-boon to 64-bit code.

These are indeed really specialist cases, as it requires to consist of almost nothing but 64 bit math and almost no pointers (since every pointer is twice as wide, reducing cache effectivity by half).

The availability of more registers is another speed-boon to 64-bit code.

On x86_64, to be precise (on other architectures, 32 bit mode already has plentiful registers). However, register variables are not enabled in FPC 2.2.x for x86_64, but only in in 2.3.x (and this will not be merged).

Jonas

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

Hi,

AFAIK, it's impossible to compile FPC in Delphi since FPC's 1.0x versions. If FPC compiles itself (wich it does), I don't see the point in twisting FPC source in to compiling in Delphi, especially spending efforts to overcome Delphi's limits.
As long as FPC compiles my Delphi code, I'm happy.

You forget that FPC source is available, thus you are preaching to the choir, here.
Borland/Inprise/Codegear/Embarcadero are the ones that have a closed source compiler and go their way without caring about the others (a legitimate policy, by the way)

Thus the pascal compiler writes should make sure there is one pascal language and not a zillion different ones.

As I explained above, the only way they have to do this is running after the other compilers to catch up with the changes. This is what is being done, but asking for a specific change or a different pace will only get you one answer: The source is here, do it yourself.
It may sound rude, but that's the basic contract between FPC's developers and you.

I think this has been taken care of, at least on th FPC side. ;-)

There was one attempt from the CrossKylix author, that seems to be abandonned. Again you would be chasing a moving target, with no cooperation from Codegear.

When it comes to debugging Lazarus this seems difficult. How does one debug Lazarus with Lazarus ? Very strange really...

With patience. Welcome the world of IDE development.

If lazarus crashes... then how could I possible debug it ? Since it already crashed ? Pretty strange...

A) with an external debugger.
B) With another instance of LAzarus.

Maybe an idea would be to use two Lazarus instances... one which will be debugged with the other Lazarus instance... but then it's hoping that not both will crash... ;)

Could happen.

To have a spare solution, and in some cases a better solution. After seeing the erratic behaviour and policies of Borland/Inprise/Codegear/Embarcadero, do you feel safe with Delphi?

Why would we Delphi programmers invest time in trying to make Free Pascal better ?

See above.

So far these two tools do little for us Delphi programmers:

I don't think it's everybody's case.

Lazarus is still buggy, and kinda annoying ;) :)

True, but the solution is partially in your hands.

Yes, this is really what we need. Ditch DOS filenames and switch to a DOS based text GUI.

The stop dreaming. ;-)

Op donderdag 18-12-2008 om 18:47 uur [tijdzone +0100], schreef Skybuck Flying:

Maybe you should read somewhat more about freepascal, re-think what you wrote and then come here again.

And in that case, post al your ideas in a seperate mails.

The fpc-compiler can compile Delphi-code, in it's Delhi-mode, and code written for fpc in Delphi-mode can be compiled by Delphi. As long as you don't use any of the extensions of fpc on Delphi. So that is already done.

There also is a improved version of the VCL available, namely the LCL. Only the LCL is better because it can be used-cross platform. You can not do that with the VCL, because it's design does not allow that.

The problem you are pointing at is more that the Codegear people don't cooperate with us, not that we don't try to cooperate with them. We can't force Codegear to change it's policies. Maybe you should write some essays to them. (But that has been done before)

There is none usefull idea in your essay which isn't already implemented, tried or be proven wrong. Just search this list, google and our website.

Joost.

I think all efforts should the concentrated on providing mainstream features that are common in newer development platforms (Java/C#) . I feel that spending time on making Delphi code more readable is a waste since there are SO many other issues that need to be dealt with.

C# has a lot of ideas FPC can take on. I say contributors should think about bringing in new functionality and Expanding FPC to include such features rather than deal with Delphi issues. The benefits of using FPC (write 1 compile X OSs) far outweigh any issues an individual will have at learning which Library replaces Win32 or what not.

FPC/Lazarus has come a long way in the 2 years I've been following the project. Keep up the good work and push forward... Don't get side tracked by all these compatibility issues. Infact, add more features that are currently not present in Pascal - Lamda Expressions etc... A.I. in Code Insight... There are hundreds of new issues to pioneer - let's not get caught up in a quagmire.

I think you missed the point here.

The point was:

DWPL simply replaced some unit aliases, and implemented a compatible text-based VCL (probably using CLX).

This ment the application could be compiled for windows with a graphical gui.
This ment the application could be compiled for dos with a text gui which looked graphical.

Delphi uses:

WinTypes=Windows;WinProcs=Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE;

DWPL would change it to:

messages=sysutils;controls=qcontrols;dialogs=qdialogs;extctrls=qextctrls;forms=qforms;graphics=qgraphics;menus=qmenus;stdctrls=qstdctrls;WinTypes=Windows;WinProcs=Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE;

Then use tool to convert windows exe to wdosx32 exe.

By using only the supported gui components at least the gui code would simply compile without any changes necessary.

Probably same for RTL... for threading I am not sure ;) it was being implemented at the time.

Something like that for Lazarus would be nice ! :)

Bye,
Skybuck.