Re: [fpc-devel] Compiling fpc subversion on a AMD64 box with Win 7 64 bit OS
Dimitrios Chr. Ioannidis schrieb: * native x86_64 compiler (assuming your fpc.exe in the path is an x86_64 version) * 'native' i386 compiler * ARM/wince cross-compiler In the above case i will end up with two dir's in fpc\bin. One i386-win32 and one x86_64-win64. Just use a cross x86-64 compiler. There is no reason to use a native 64 bit compiler as long as your compilation process needs no more than 2 GB (3 GB) of ram. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] First cppclass test
Sven Barth schrieb: Florian Klaempfl schrieb: Sven Barth schrieb: All in all I have the following goals for (my) future work on this: * make a cppclass an implicit pointer I don't like this idea because C++-classes aren't an implicit pointer either. At first I wanted to disagree with you... philosophing about the Pascal way of doing things, bla, bla... Pascal has also objects which are no pointers ;) But after 8 km of deep thinking (as I'm riding those by bike, I have much time :) ), I came to the conclusion that you are right. We are interfacing with a foreign language here and if we are in Rome, we shall do as the Romans do... Yes, this is also my point. so: forget the idea of implicit pointers ^^ Another question though: Do you want me to write tests for the compiler for this feature (e. g. those in the tests directory)? tests/test/tcppclass1.pp, tcppclass2.pp etc. If so, how do you suggest to write those tests, especially as they (currently) rely on a external library... Libraries or object files? FPC does similiar testing for C linking: the C sources are checked in into http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/obj/ Compiled object files lay in the appropriate sub dir of this dir. Testing C++ class linking should be done similiar imo. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Comparing arrays of char
Here is output from my program p compiled with Delphi (5) and FPC.
I believe that FPC fails because the first byte is chr(0) when comparing
70501033728 with
0.
I did run into this problem when moving code from a Pascal compiler that can
compare
records of the same type.
In Delphi I can come around this problem creating an array of char in the
record of the same
size and then comparing those.
But it looks like this doesn´t work in FPC.
Is this an error in FPC, or dos the compiler always look at an array of char as
a null
terminated string.
Carsten
OK:70501033728/0
OK:70501033729/0
OK:70501033727/0
Error:70501033728/0
OK:70501033729/0
OK:70501033727/0
Free Pascal Compiler version 2.2.4 [2009/09/01] for arm
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for ARM
Compiling p.pp
Program p;
type
t_typ=packed array[0..4] of char;
b_typ=packed array[0..4] of byte;
t2=record
case integer of
0:(t:t_typ);
1:(b:b_typ);
2:(i:Int64);
end;
Var
b1,b2:t2;
Begin
b2.i:=0;
b1.i:=70501033728;
if b1.t=b2.t then
writeln('Error:',b1.i,'/',b2.i)
else
writeln('OK:',b1.i,'/',b2.i);
b2.i:=0;
b1.i:=70501033729;
if b1.t=b2.t then
writeln('Error:',b1.i,'/',b2.i)
else
writeln('OK:',b1.i,'/',b2.i);
b1.i:=70501033727;
if b1.t=b2.t then
writeln('Error:',b1.i,'/',b2.i)
else
writeln('OK:',b1.i,'/',b2.i);
End.
Error:70501033728/0
OK70501033729/0
OK70501033727/0
Med venlig hilsen
Carsten Bager
BEAS A/S
Brørupvænget 10
DK-7650 Bøvlingbjerg
Tlf. : +45 9788 5222 Fax : +45 9788 5434
www.beas.dk
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparing arrays of char
In our previous episode, Carsten Bager said: Here is output from my program p compiled with Delphi (5) and FPC. I believe that FPC fails because the first byte is chr(0) when comparing 70501033728 with 0. Did you also try this on a PC? I haven't really tested, but it seems that you are converting between integers and arrays making use of their memory storage. The memory storage format differs between x86 and (typical) arm. The former is little endian, the latter mostly bigendian. Google/wikipedia those terms to get an overview, e.g. http://en.wikipedia.org/wiki/Endianness ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparing arrays of char
In our previous episode, Carsten Bager said: Here is output from my program p compiled with Delphi (5) and FPC. I believe that FPC fails because the first byte is chr(0) when comparing 70501033728 with 0. Did you also try this on a PC? I haven't really tested, but it seems that you are converting between integers and arrays making use of their memory storage. The memory storage format differs between x86 and (typical) arm. The former is little endian, the latter mostly bigendian. It is the same on a PC As far as I can see, the problem is the compiler does not differ between an array of char and a null terminated string. As a result of this, if the first byte/char are 0 in both arrays the compiler stops checking and says that there are equal. Carsten Carsten ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparing arrays of char
Carsten Bager wrote on Mon, 02 Nov 2009: As far as I can see, the problem is the compiler does not differ between an array of char and a null terminated string. As a result of this, if the first byte/char are 0 in both arrays the compiler stops checking and says that there are equal. When I implemented the current behaviour, I compared it either Turbo Pascal or Kylix 3 (which is Delphi 6.5), I'm not sure which one anymore. There, a) if the array is zero-based (i.e., lower bound is 0), then the array of char is treated as a null-terminated string b) if the array is non-zero-based, then the array of char is always checked completely That should also be the current behaviour for FPC. So if you want to always use the full array, change your lower array bounds. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparing arrays of char
Jonas Maebe wrote: a) if the array is zero-based (i.e., lower bound is 0), then the array of char is treated as a null-terminated string b) if the array is non-zero-based, then the array of char is always checked completely The Delphi behavior sounds not very obvious :(. Is this true as well for arrays of char as for arrays of byte ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparing arrays of char
Michael Schnell wrote on Mon, 02 Nov 2009: Jonas Maebe wrote: a) if the array is zero-based (i.e., lower bound is 0), then the array of char is treated as a null-terminated string b) if the array is non-zero-based, then the array of char is always checked completely The Delphi behavior sounds not very obvious :(. I guess it's because C-arrays are also always 0-based (and in C a char array is the closest thing there is to a string). But yes, it also cost me quite a bit of testing before I finally figured out the rules. Is this true as well for arrays of char as for arrays of byte ? You cannot compare an array of byte with another array using the regular comparison operators, afaik. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Ivo Steinmann schreef:
Hello all
I started some wiki for dynamic loading libraries support discussion.
http://wiki.freepascal.org/Dynamically_loading_headers
I already added an experimental implementation. If you have got some
ideas, whises and criticism, don't hesitate to write.
I don't like the looks of lines like:
{$IFDEF S}function{$ELSE}var{$ENDIF}foobar_dosomething{$IFDEF D}:
function{$ENDIF}(a:cint; b:cdouble): cint; extdecl;{$IFDEF S}external
foobarlib;{$ENDIF}
They are hard to read. I understand that this way makes sure that both
static and dynamical declaration are in sync, but the loss of
readability is too much.
Maybe it is better to generate a foobar_dyn.inc based on the foobar.inc
or generate both foobar.inc and foobar_dyn.inc from a common file format
(maybe even the original header file).
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparing arrays of char
That should also be the current behaviour for FPC. So if you want to always use the full array, change your lower array bounds. Jonas I will keep that in mind - thanks Carsten ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Ivo Steinmann schreef: Most libraries are translated by a tool like h2pas from the original headers and then rehashed manually. The best solution would be, if there's a tool that generates the var procedures directly from all external procedures. What do you exactly mean? A tool which takes for example: http://svn.freepascal.org/trunk/packages/libpng/src/png.pp and outputs a png_dyn.pp. But else it's much simpler to maintain a construct as the one above than allways starting from the orignal h file or updating allways both declarations. I know what i'm talking about, since I translated about 15 headers in /fpc/packages ^^ But of course you are right, it's not the nice solution ;) The best solution would be to have got some support from the compiler itself ;) What kind of help? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Ivo Steinmann escreveu: Vincent Snijders schrieb: Maybe it is better to generate a foobar_dyn.inc based on the foobar.inc or generate both foobar.inc and foobar_dyn.inc from a common file format (maybe even the original header file) [..] Most libraries are translated by a tool like h2pas from the original headers and then rehashed manually. The best solution would be, if there's a tool that generates the var procedures directly from all external procedures. I think that creating a tool to translate a static header to a dyn header should be easy to create (i'm not talking to convert c header directly ;-)). Should do the following right? Correct me if i'm wrong: Static function: function foobar_dosomething(a:cint; b:cdouble): cint; extdecl;external foobarlib; Becomes a dyn function: var foobar_dosomething: function(a:cint; b:cdouble): cint; extdecl; I can write such tool. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Luiz Americo Pereira Camara schreef: Ivo Steinmann escreveu: Vincent Snijders schrieb: Maybe it is better to generate a foobar_dyn.inc based on the foobar.inc or generate both foobar.inc and foobar_dyn.inc from a common file format (maybe even the original header file) [..] Most libraries are translated by a tool like h2pas from the original headers and then rehashed manually. The best solution would be, if there's a tool that generates the var procedures directly from all external procedures. I think that creating a tool to translate a static header to a dyn header should be easy to create (i'm not talking to convert c header directly ;-)). Should do the following right? Correct me if i'm wrong: Static function: function foobar_dosomething(a:cint; b:cdouble): cint; extdecl;external foobarlib; Becomes a dyn function: var foobar_dosomething: function(a:cint; b:cdouble): cint; extdecl; And a statement to initialize the variable. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Vincent Snijders wrote: Should do the following right? Correct me if i'm wrong: Static function: function foobar_dosomething(a:cint; b:cdouble): cint; extdecl;external foobarlib; Becomes a dyn function: var foobar_dosomething: function(a:cint; b:cdouble): cint; extdecl; And a statement to initialize the variable. I'd also note that the current approach (loading all functions at once) actually defeats the nature of dynamic linking, and smartlinking as well. If some function is absent in the library, error will occur on loading regardless of whether this function is actually used by the program. With static linking, if the problematic function isn't used, there will be no loading error. For this reason, I use the following approach in my projects (in pseudocode): interface function foo(args): integer; implementation type tfoo = function(args): integer; const bad_ptr = pointer(1); var _foo: pointer = bad_ptr; function foo(args): integer; var p: PPointer; begin p := @_foo; Result := E_NOTIMPL; // other values may be used, or an exception raised if p^ = bad_ptr then p^ := GetProcAddress(libHandle, 'foo_name'); if Assigned(P^) then Result := tfoo(p^)(args); end; Such approach, of course, introduces somewhat bigger overhead, but allows the compiler to optimize unused parts away. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Vincent Snijders escreveu:
Luiz Americo Pereira Camara schreef:
I think that creating a tool to translate a static header to a dyn
header should be easy to create (i'm not talking to convert c header
directly ;-)).
Should do the following right? Correct me if i'm wrong:
Static function:
function foobar_dosomething(a:cint; b:cdouble): cint;
extdecl;external foobarlib;
Becomes a dyn function:
var foobar_dosomething: function(a:cint; b:cdouble): cint; extdecl;
And a statement to initialize the variable.
Do you mean this?
sqlite3_symbols: array[0..152{$IFDEF SQLITE_OBSOLETE}+6{$ENDIF}] of
TLibSymbol = (
(pvar:@sqlite3_libversion; name:'sqlite3_libversion'; weak:false), etc..
Luiz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Luiz Americo Pereira Camara schreef:
Vincent Snijders escreveu:
Luiz Americo Pereira Camara schreef:
I think that creating a tool to translate a static header to a dyn
header should be easy to create (i'm not talking to convert c header
directly ;-)).
Should do the following right? Correct me if i'm wrong:
Static function:
function foobar_dosomething(a:cint; b:cdouble): cint;
extdecl;external foobarlib;
Becomes a dyn function:
var foobar_dosomething: function(a:cint; b:cdouble): cint; extdecl;
And a statement to initialize the variable.
Do you mean this?
sqlite3_symbols: array[0..152{$IFDEF SQLITE_OBSOLETE}+6{$ENDIF}] of
TLibSymbol = (
(pvar:@sqlite3_libversion; name:'sqlite3_libversion'; weak:false), etc..
That is one solution, filling the symbols array.
Another solution is simply:
@sqlite3_libversion := GetProcAddress(libHandle, 'sqlite3_libversion');
I was pointing at a missing link.
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Luiz Americo Pereira Camara schrieb: Ivo Steinmann escreveu: Vincent Snijders schrieb: Maybe it is better to generate a foobar_dyn.inc based on the foobar.inc or generate both foobar.inc and foobar_dyn.inc from a common file format (maybe even the original header file) [..] Most libraries are translated by a tool like h2pas from the original headers and then rehashed manually. The best solution would be, if there's a tool that generates the var procedures directly from all external procedures. I think that creating a tool to translate a static header to a dyn header should be easy to create (i'm not talking to convert c header directly ;-)). Should do the following right? Correct me if i'm wrong: Static function: function foobar_dosomething(a:cint; b:cdouble): cint; extdecl;external foobarlib; Becomes a dyn function: var foobar_dosomething: function(a:cint; b:cdouble): cint; extdecl; I can write such tool. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel exactly Including the list of symbols I suggested. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamically Loading Libraries
Vincent Snijders schrieb:
Ivo Steinmann schreef:
Most libraries are translated by a tool like h2pas from the original
headers and then rehashed manually. The best solution would be, if
there's a tool that generates the var procedures directly from all
external procedures.
What do you exactly mean? A tool which takes for example:
http://svn.freepascal.org/trunk/packages/libpng/src/png.pp
and outputs a png_dyn.pp.
But else it's much simpler to maintain a construct as the one above than
allways starting from the orignal h file or updating allways both
declarations. I know what i'm talking about, since I translated about 15
headers in /fpc/packages ^^
But of course you are right, it's not the nice solution ;) The best
solution would be to have got some support from the compiler itself ;)
What kind of help?
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
well, there are a lot of possibilities, but that's one:
unit foobar;
{$DYNLOADING ON}
function foobar_dosomething(a:cint; b:cdouble): cint; extdecl;external
foobarlib;
Now when compiler flag {$DYNLOADING ON} is set, the compiler don't do
smart/static linking.
Internally it creates an array of all USED!! symbols (similar to the one
I recommended) and also generates functions like
InitializeFoobar;
TryInitializeFoobar; // silent
FinalizeFoobar;
Then the user have to call this functions before he can use one of the
external symbols. If one of the used symbols is not found in the
library, we get an error similar to when do smart linking, but at runtime.
This way we could use the same headers as dynamic and static, just by
switching {$DYNLOADING ON} or OFF
This mechanism would be also interesting for packages in lazarus.
-Ivo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Mercurial mirror is stuck
For both FPC and Lazarus at about 8 days ago. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
