[fpc-pascal] Re: put data to stdout (fpc vs. gcc)
Hi Jonas,
I know, programs with a writeln() have lower performance, but I think,
printf() and writeln() must do the same. This need time to calculate.
But the difference between printf() and writeln() are so, that the fpc
program breaks with errors.
What kind of errors?
It will break with an error from the library, if the procedure is to slow. The
fpc-writeln() works fine but to slow. The gcc-printf() works fine and fast.
Do you know a better way to produce a fast formated output in FreePascal.
I would use FreePascal and not gcc, but the fpc result is not practical.
Markus
--
C source:
for (i=0;in;i++) {
out1=(single) libout1[i];
out2=(single) libout2[i];
count+=1;
printf(%20.0f%15.5f%15.5f\n,count,out1,out2);}
--
fpc source:
for i:=0 to n do
begin
out1:=single(libout1[i]);
out2:=single(libout2[i]);
inc(count);
writeln(stdout, count:20, out1:15:5, out2:15:5); (* This will break! *)
end;
--
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: put data to stdout (fpc vs. gcc)
On 15 jun 2007, at 11:24, [EMAIL PROTECTED] wrote: Hi Jonas, I know, programs with a writeln() have lower performance, but I think, printf() and writeln() must do the same. This need time to calculate. But the difference between printf() and writeln() are so, that the fpc program breaks with errors. What kind of errors? It will break with an error from the library, if the procedure is to slow. I'm sorry, but you are not providing enough information to give any useful comments. There is no reason why a generic library would error out because certain code is too slow. Is this a real time application on an embedded system or so? Do you know a better way to produce a fast formated output in FreePascal. I would use FreePascal and not gcc, but the fpc result is not practical. If your program depends on converting floating point numbers to string representation as quickly as possible, I agree that FPC is not the tool you want in this case. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: put data to stdout (fpc vs. gcc)
On 15 jun 2007, at 11:44, Michael Van Canneyt wrote: I'm sorry, but you are not providing enough information to give any useful comments. There is no reason why a generic library would error out because certain code is too slow. Is this a real time application on an embedded system or so? I think that the problem is the buffering. Just set the text buffer (settextbuf) to a larger buffer, and it should work a lot faster. That's quite unlikely to be the case. settextbuf seldomly makes a difference for me. Especially if you write to standard output, which will trigger a flush after every writeln anyway. I don't see why not ? What would make it more slow than a comparable routine in libc ? Of course it is possible to write a routine which is just as fast as the one in libc, but I'm not going to spend my time on that (I spent months on debugging the current routine on different architectures to get consistent and pretty correct output, and there are plenty of other more interesting and -as far as I am concerned- important things to do). Currently, FPC's float-string conversion is apparently too slow for him however, so FPC is not useful for him at this time if his main interest is speed of converting floating point numbers to string representation. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: put data to stdout (fpc vs. gcc)
On 15 jun 2007, at 11:53, Jonas Maebe wrote: That's quite unlikely to be the case. settextbuf seldomly makes a difference for me. Especially if you write to standard output, which will trigger a flush after every writeln anyway. (unless you redirect the output to a file, at least under *nix) Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac losing Carbon support in 64bit Leopard
memsom schrieb: Rumour has it that the Mac OS X 10.5 will not have 64bit Carbon support under Intel. That means that Intel based Carbon based apps will only ever be 32bit and that if 32bit support is ever withdrawn (likely?) Carbon will be gone. I know that the FPC GUI ports under Mac OS X tend to use Carbon anyone heard any definite reports on this? Currently, Cocoa is only usable from ObjC. I know OS News has one, but that is allegedly still hear-say. Is it even possible/practical to use Cocoa to build a GUI and then use Pascal code to do the logic? Apaprently Troll Tech is unhappy as they use Carbon in their Qt port for Mac OS X... Well, they have the same problem as any non ObjC user probably: using Cocoa from non ObjC languages is hard. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac losing Carbon support in 64bit Leopard
On 15 jun 2007, at 17:00, memsom wrote: Rumour has it that the Mac OS X 10.5 will not have 64bit Carbon support under Intel. It's not just a rumour, and it's not Intel-only. Several parts of Carbon will not be 64 bit under Mac OS X 10.5. See the 64-bit Carbon and Is Carbon Viable? threads at http://lists.apple.com/archives/carbon-dev/2007/Jun/thrd3.html (and on the following pages) In particular the messages from Eric Schlegel (he's from Apple), e.g. http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00426.html http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00433.html That means that Intel based Carbon based apps will only ever be 32bit and that if 32bit support is ever withdrawn (likely?) Carbon will be gone. Nobody can say how likely that is. It definitely won't happen in the near future, since there are a lot of Carbon apps out there. I know that the FPC GUI ports under Mac OS X tend to use Carbon anyone heard any definite reports on this? I know OS News has one, but that is allegedly still hear-say. Is it even possible/practical to use Cocoa to build a GUI and then use Pascal code to do the logic? Yes, it is (just as practical to do the logic in C or C++). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac losing Carbon support in 64bit Leopard
On 15 jun 2007, at 17:09, Henry Vermaak wrote: you can try and build all your functionality into an fpc dynamic lib and then link to it out of xcode. we'll need a layer to export the objective c in a way that we can use it if we're ever going to use cocoa directly. i think it contains a gazillion objects, so this is not trivial... You don't really have to do that, Apple already did that: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/ And those routines can be used to build an Objective Pascal on top, to make interfacing easier. And for inspiration for that, see http://www.pascal-central.com/cwpascal.html#Extensions%20providing% 20compatibili http://en.wikipedia.org/wiki/Objective_Modula-2 Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac losing Carbon support in 64bit Leopard
On 15 jun 2007, at 17:18, Henry Vermaak wrote: On 15/06/07, Henry Vermaak [EMAIL PROTECTED] wrote: On 15/06/07, memsom [EMAIL PROTECTED] wrote: allegedly still hear-say. Is it even possible/practical to use Cocoa to build a GUI and then use Pascal code to do the logic? you can try and build all your functionality into an fpc dynamic lib by the way, do fpc dynamic libraries work in osx? Yes. i remember that i had to use the -install_name option with gcc. does fpc have something similar? You can use the equivalent linker parameter using -k'-dylib_install_name Your Installation Location' Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac losing Carbon support in 64bit Leopard
On 15/06/07, Jonas Maebe [EMAIL PROTECTED] wrote: You don't really have to do that, Apple already did that: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/ And those routines can be used to build an Objective Pascal on top, to make interfacing easier. And for inspiration for that, see http://www.pascal-central.com/cwpascal.html#Extensions%20providing% 20compatibili http://en.wikipedia.org/wiki/Objective_Modula-2 interesting, thanks for the links. Jonas henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac losing Carbon support in 64bit Leopard
On 15/06/07, Henry Vermaak [EMAIL PROTECTED] wrote: On 15/06/07, memsom [EMAIL PROTECTED] wrote: allegedly still hear-say. Is it even possible/practical to use Cocoa to build a GUI and then use Pascal code to do the logic? you can try and build all your functionality into an fpc dynamic lib by the way, do fpc dynamic libraries work in osx? i remember that i had to use the -install_name option with gcc. does fpc have something similar? henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac losing Carbon support in 64bit Leopard
On 6/15/07, memsom [EMAIL PROTECTED] wrote: Apaprently Troll Tech is unhappy as they use Carbon in their Qt port for Mac OS X... Everyone is unhappy. Office, Photoshop, Adobe products, Firefox, wxWidgets, etc, are all based on Carbon. Actually to me it seams that Apple is the only entusiastic company about Objective C This is sad, but at the same time isn't the end of the world, because: * The transition to 64-bits will take time, so we have some years still where work can continue with Carbon * Even then 32-bits carbon apps will keep working normally on 64-bits computers * Until 64-bits GUIs are really needed we will already have some way of interfacing with Cocoa, which can be either supporting obj-c objects on Pascal or procedurizing the Cocoa API To write stand-alone apps the first approach is 1 million times better, but, for example, to write a Lazarus interface the second is more then enougth. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: put data to stdout (fpc vs. gcc)
Michael Van Canneyt wrote: You would have to test the speed of each of them separately to be able to say anything definitive. Like it is now, there is no indication that it is the float-to-text routine which is to blame. So use sprintf in C, and the equivalent in fpc; and rerun the test. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] library initialization and deinitialization
I've got a shared library (.so) I wrote in C, with initialization and
finalization code declared by using the GCC attributes constructor and
destructor. These init and fini functions simply print out start and
stop to stdout. The .so exports one function, which prints out
Hello.
I've got a test program (also written in C) which calls the .so's
function. What I see on stdout is
start
Hello
stop
Just like you'd expect.
I wrote a Free Pascal test program which also uses the .so. However,
what I see is this:
start
Hello
So for some reason, the fini never seems to get called! I thought this
was strange, so I wrote a similar library in free pascal:
==
library subs;
procedure SayHello (); cdecl; export;
begin
writeln('Hello ');
end;
exports
SayHello;
initialization
writeln('start');
finalization
writeln('done');
end.
==
Again, I ran a c test program against it and a fpc test program
against it. The C program's output was:
start
Hello
stop
The freepascal program's output was:
Hello
What's going on here?
With humble thanks,
Seth Grover
--
Seth Grover
sethdgrover[at]gmail[dot]com
http://grovers.us/seth
Who is John Galt?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: library initialization and deinitialization
A bug report (with sample code reproducing the behavior) has been logged. http://freepascal.org/mantis/view.php?id=9089. Probably should have done that before I emailed the mailing list. Sorry. -SG -- Seth Grover sethdgrover[at]gmail[dot]com http://grovers.us/seth Who is John Galt? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
