Re: [fpc-pascal] linking to a shared library (linux platform)
On 03 Jan 2006, at 23:58, Alain Michaud wrote:
plPlotterParams * pl_newplparams (void)
The function "pl_newplparams" is supposed create a structure (record)
and then return some "pointer" to it. The user is not supposed to
access
this data directly, so there is NO reference to "plPlotterParams"
al all
in the header files (plot.h)! How does the C compiler knows what
plPlotterParams is then?
It is in a header file, otherwise the C compiler will not compile it
either. According to https://bugzilla.redhat.com/bugzilla/
attachment.cgi?id=3380, it may be defined like this in plotter.h:
typedef struct plPlotterParamsStruct
{
int (*setplparam) (struct plPlotterParamsStruct *_plotter_params,
const char *parameter, void * value);
void * plparams[33];
}
PlotterParams;
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Constants
Hi I am programming to an embedded ARM platform and my question is, is it possible to force constants to stay in the code segment (constant strings etc.) In C you can do this using "static". It looks as all string constants are placed in the data segment, and all variables are placed in the bss segment. Is that always the case? Regards Carsten ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with FPC2.0.2 and windows
Jonas Maebe wrote: They should be. Thank you for your careful answer. I will return later if I am able to make a simple sample program that can reproduce the problem. (Or may be I should stick to 1.0.10 that worked for me) It would be nice if you could provide the sample program (and submit it as a bugreport at http://www.freepascal.org/bugs.html), since if you ran into this it's quite possible that other people will do so as well. When trying to locate the problem I found out that the first problem was due to my mistake, I'm sorry. The error message was Error: Incompatible types: got "LongWord, LongInt):LongInt;StdCall>" expected "of function(LongWord, LongWord, LongInt, LongInt):LongInt;StdCall>" I interpreted this as if the error was caused by an address in stead of a procedure variable, but actually correcting the type of the 3rd parameter was sufficient to remove the error. FPC 1.0.10 compiled the statement with a longword in stead of a longint correctly without any comments, but it looks like 2.0.2 has a much stronger type checking. But my second problem persists. The program is compiled, but the dialogue box does not show up, when using 2.0.2. Before I go on trying to locate this problem I must take into account that Windows requires the data structure for dialogue boxes to be aligned in a certain way, so I would like to ask the question: Does PPC 2.0.2 handle alignment of data the same way as former versions? Will the statements (the conditions) if (dword(pBoxtemplate) and 1)=1 then pBoxtemplate:=nil; if (dword(pBoxtemplate) and 2)=2 then inc(pBoxtemplate); be treated the same way, and is pointer(pBoxItem) - pointer(pBoxAllokate) still equal to the distance between the pointers measured in bytes, regardless of the type of pBoxItem? Hans Mårtensson ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with FPC2.0.2 and windows
Hans Mĺrtensson wrote:
.
.
> Does PPC 2.0.2 handle alignment of data the same way as former versions?
.
.
Actually, I don't think so - I believe the default alignment might have
changed from 2 to 4 (at least this seems to be indicated by my simple
test). You can check this easily for pBoxtemplate^ (or anything else as
required) by calling:
WriteLn (SizeOf (pBoxtemplate^));
Furthermore, you can enforce required alignment using {$PACKRECORDS x}.
Tomas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] MacOSX limited linker path length
I run into some strange linker errors. Shorten the paths fixed the problem. The application has the following linker options: -k-framework -kcarbon -k-framework -kAGL And the output file was -o/Users/Username/pascal/carbon/agl/carboncustomcontrol.app/Contents/MacOS/ TestProgram Granted, it is not short, but at least half of it is needed anyway. I have now to work with symbolic links if I want to add only one other framework. What should I write into the wiki? Don't use long paths under MacOSX as the linker will cut too long parameter lists. Or is it a fpc problem? How can I find out? How can I see, how fpc calls the linker under MacOSX? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MacOSX limited linker path length
On 04 Jan 2006, at 18:25, Mattias Gaertner wrote: How can I see, how fpc calls the linker under MacOSX? Compile with -s and check ppas.sh and link.res. There are still various 255 char limits in fpc regarding command line arguments passed to the assembler and linker. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with FPC2.0.2 and windows
On 04 Jan 2006, at 17:51, Hans Mårtensson wrote: Does PPC 2.0.2 handle alignment of data the same way as former versions? The statements below have nothing to do with alignment. Will the statements (the conditions) if (dword(pBoxtemplate) and 1)=1 then pBoxtemplate:=nil; I can only think of one way to interpret this. if (dword(pBoxtemplate) and 2)=2 then inc(pBoxtemplate); Somewhere in the past, inc(pBoxtemplate) would have increased pBoxtemplate with one. Nowadays, this increases pBoxtemplate with sizeof(pBoxtemplate^). I don't know when this change was done though, but I'm quite confident it was before 1.0. If this is the behaviour you need, it's ok. be treated the same way, and is pointer(pBoxItem) - pointer(pBoxAllokate) still equal to the distance between the pointers measured in bytes, regardless of the type of pBoxItem? Yes. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with FPC2.0.2 and windows
Jonas Maebe wrote: On 04 Jan 2006, at 17:51, Hans Mårtensson wrote: Does PPC 2.0.2 handle alignment of data the same way as former versions? The statements below have nothing to do with alignment. Will the statements (the conditions) if (dword(pBoxtemplate) and 1)=1 then pBoxtemplate:=nil; I can only think of one way to interpret this. if (dword(pBoxtemplate) and 2)=2 then inc(pBoxtemplate); The type of pBoxtemplate is ^word. Is it not true that (dword(pBoxtemplate) and 1)=1 evaluates to TRUE, if and only if pBoxtemplate is NOT aligned to a word boundary (16 bit boundary)? And then, assuming pBoxtemplate is aligned to word boundary, is it not true, that if (dword(pBoxtemplate) and 2)=2 evaluates to TRUE, if pBoxtemplate is NOT aligned to a dword boundary (32 bit boudary), causing the statement if (dword(pBoxtemplate) and 2)=2 then inc(pBoxtemplate); to make the pBoxtemplate align to a dword boundary (by eventually adding 2 to pBoxtemplate (because sizeof(word)=2)?? Hans Mårtensson ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with FPC2.0.2 and windows
On 04 Jan 2006, at 21:51, Hans Mårtensson wrote: Does PPC 2.0.2 handle alignment of data the same way as former versions? The statements below have nothing to do with alignment. The type of pBoxtemplate is ^word. Is it not true that (dword(pBoxtemplate) and 1)=1 evaluates to TRUE, if and only if pBoxtemplate is NOT aligned to a word boundary (16 bit boundary)? And then, assuming pBoxtemplate is aligned to word boundary, is it not true, that if (dword(pBoxtemplate) and 2)=2 evaluates to TRUE, if pBoxtemplate is NOT aligned to a dword boundary (32 bit boudary), causing the statement if (dword(pBoxtemplate) and 2)=2 then inc(pBoxtemplate); to make the pBoxtemplate align to a dword boundary (by eventually adding 2 to pBoxtemplate (because sizeof(word)=2)?? Yes, but this is independent of how the compiler handles alignment of data. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with FPC2.0.2 and windows
Jonas Maebe wrote:
On 04 Jan 2006, at 21:51, Hans Mårtensson wrote:
The type of pBoxtemplate is ^word.
Is it not true that
(dword(pBoxtemplate) and 1)=1
evaluates to TRUE, if and only if pBoxtemplate is NOT aligned to a
word boundary (16 bit boundary)?
And then, assuming pBoxtemplate is aligned to word boundary, is it
not true, that
if (dword(pBoxtemplate) and 2)=2
evaluates to TRUE, if pBoxtemplate is NOT aligned to a dword
boundary (32 bit boudary), causing the statement
if (dword(pBoxtemplate) and 2)=2 then inc(pBoxtemplate);
to make the pBoxtemplate align to a dword boundary (by eventually
adding 2 to pBoxtemplate (because sizeof(word)=2)??
Yes, but this is independent of how the compiler handles alignment of
data.
OK, then I really don't understand where the problem is.
It seems difficult to me to supply a bug report, because it is still so
uncertain where the problem lies.
But I attach the source code to my test program, in case you can do
anything with it.
When I compile this source code with FPC 1.0.10, it produces a program
that makes a window with one menu item. When you click on it, a dialogue
box pops up.
But when I compile the same source code with FPC 2.0.2, I still get a
program that makes the window. But the dialogue box does not show, when
you click the menu item.
Hans Mårtensson
Program test;
// Program for testing dialogue boxes
{$APPTYPE GUI}
Uses windows;
Const
AppName = 'Lydexperiment';
var
AMessage: Msg; hWindow: HWnd;
pbox2: pointer; box2var1, box2var2: longint;
Boxtemplate: DlgTemplate;
Boxtemplatesize: word;
pBoxAllokate: ^word; //Start of allocated memory
pBoxtemplate: ^word; //Start of Boxtemplate
pBoxItem: ^word; //Start of free space after added items
{$Rangechecks off}
//**
Procedure newboxtemplate(title: string; width, height, boxsize: word);
var i:integer;
begin boxtemplatesize:=boxsize; pBoxItem:=nil;
getmem(pBoxAllokate,boxsize); pBoxtemplate:=pBoxAllokate;
if (dword(pBoxtemplate) and 1)=1 then pBoxtemplate:=nil;
if (dword(pBoxtemplate) and 2)=2 then inc(pBoxtemplate);
if pBoxtemplate=nil then exit;
Boxtemplate.style:=DS_CENTER or WS_POPUP or WS_CAPTION or WS_SYSMENU or
DS_MODALFRAME;
Boxtemplate.dwextendedstyle:=0;
Boxtemplate.x:=0; Boxtemplate.y:=0; Boxtemplate.cx:=width;
Boxtemplate.cy:=height;
Boxtemplate.cdit:=0; pBoxItem:=pointer(pBoxtemplate) + sizeof(Boxtemplate);
pBoxItem^:=0; inc(pBoxItem); pBoxItem^:=0; inc(pBoxItem); // menu and class
for i:=1 to length(title) do begin pBoxItem^:=ord(title[i]); inc(pBoxItem)
end;
pBoxItem^:=0; inc(pBoxItem) end; // terminating 0 in titel
Procedure newboxtemplate(title: string; width, height: word);
begin newboxtemplate(title, width, height, 2000) end;
//**
Procedure appendboxitem(id: word; style: DWORD; class: word; title: string;
x,y,width,height: WORD);
var i: word; Bi: Dlgitemtemplate;
begin if pBoxItem=nil then exit; if (dword(pBoxItem) and 2)=2 then
inc(pBoxItem);
Bi.style:=style or WS_VISIBLE or WS_CHILD;
if class<>$82 then Bi.style:=BI.style or WS_TABSTOP;
Bi.dwextendedstyle:=0;
Bi.x:=x; Bi.y:=y; Bi.cx:=width; Bi.cy:=height; Bi.id:=id;
move(Bi,pBoxItem^,sizeof(Bi)); inc(pBoxItem,sizeof(bi) div 2);
pBoxItem^:=$; inc(pBoxItem); pBoxItem^:=class; inc(pBoxItem);
//standard-class presumed
for i:=1 to length(title) do begin pBoxItem^:=ord(title[i]); inc(pBoxItem)
end;
pBoxItem^:=0; inc(pBoxItem); // terminating 0 in titel
pBoxItem^:=0; inc(pBoxItem); // creation data is not used
inc(Boxtemplate.cdit); move(Boxtemplate,pBoxtemplate^,sizeof(Boxtemplate));
end;
Function getboxtemplate: pointer;
var nbox: DWORD; pBoxny: ^word;
begin if pBoxItem=nil then begin
getboxtemplate:=nil; MessageBox (0,'WinCreate failed','Error',MB_OK); exit
end
else getboxtemplate:=pBoxtemplate;
nbox := pointer(pBoxItem) - pointer(pBoxAllokate); getmem(pBoxny,nbox+2);
if pBoxny=nil then exit;
if (dword(pBoxny) and 1)=1 then pBoxny:=nil;
if (dword(pBoxny) and 2)=2 then begin inc(pBoxny); dec(nbox,2) end;
move(pBoxtemplate^,pBoxny^,nbox); freemem(pBoxAllokate,Boxtemplatesize);
pBoxtemplate:=pBoxny; getboxtemplate:=pBoxny; pBoxItem:=nil end;
//**
//End of dialogue box data structure making procedures
//Start of specific dialogue box definition
//**
Function Box2Proc(Box: hWnd; Message: UINT; WPrm : longint; LPrm: longint):
Longint; stdcall;
begin Box2Proc:=1; if LPrm=0 then ;
case Message of
WM_INITDIALOG: begin box2var1:=8000; box2var2:=2;
case box2var1 of
8000: Checkradiobutton(Box,2,7,2);
11025: Checkradiobutton(Box,2,7,3);
16000: Checkradiobutton(Box,2,7,4);
22050: Checkradiobutton(Box,2,7,5);
48000:
Re: [fpc-pascal] Ansistrings exported in DLL's - mystery
> i learned a few things from here: > > http://velthuis.homepage.t-online.de/articles/articles-pchars.html > http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_howto5 > I have seen Rudy's article too, and am reading the other website now, though. I'm at the point where I feel 100 percent confident using Pchars at this point and have started to write pages about pchars too. The mystery was why Trustmaster's website has been working for 2-3 years now (or so) using ansistrings - defying all the laws and warnings and hand wavings from people. Also, I wrote this a while back and update it with new info too: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Clearing-Up-PChar-and-DLL-Confusion But it is overwhelming and mainly just notes for my own purposes, so some people might find it too verbose to wade through. With Cmem, and according to my current knowledge, Cmem should allow one to safely export strings from one Pascal program to another Pascal program (but only Pascal programs, or programs who have compatible reference counting - i.e. maybe Delphi). Even if trustmaster's website does work fine with exporting strings without any Cmem, it would be wiser to just use Cmem - as it doesn't really cost you anything, and ensures things should work better than they are now, even if there are no problems now. When considering a C program or library will interface in to the DLL, of course pchars will be needed - one cannot use ansistrings even with cmem. And I'm fine with that - since confident with pchars. I didn't know about cmem and glad Jonas mentioned it. I still have to test it out though, to make sure things work in real life like they do in theory, when having two pascal applications talk to each other via cmem using ansistrings. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] source file size ?
hi all, i wanted to ask a question, before i spend time going down a road to implement it. are there any know limits on how big a source file can be for the FPC compiler ? i was thinking about experimenting with "code generating" a source file that would become a memory resident database of sorts. this would make my application, implemented as a shared library "plugin" quite fast, and would potentially simplify the distribution of my shared library to my user base. are there any thoughts on having a source file that might be megabytes in size that is basically just structured data implemented as source ? tia, Tony -- X-SA user ? 0.4 is out ! http://x-plane.dsrts.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] source file size ?
> are there any know limits on how big a source file can be for the FPC
> compiler ?
interesting question... hmm did you try a 3GB file which calls writeln('test')
over
and over and over again? That's the stupid way of doing tests - the smart way
would
be waiting for an answer from the FPC team.
Here are my prefered colors for your website (take it or leave it):
body bgcolor="#1E1E1E" text="#D7D7D7" link="#006699" alink="#006699"
vlink="#006699"
Gotta love dark backgrounds.
hmmm website Sigs really do work because I went ahead and clicked on your site.
--
L505
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] source file size ?
On 1/5/06, L505 <[EMAIL PROTECTED]> wrote:
>
> > are there any know limits on how big a source file can be for the FPC
> > compiler ?
>
> interesting question... hmm did you try a 3GB file which calls
> writeln('test') over
> and over and over again?
> That's the stupid way of doing tests - the smart way would
> be waiting for an answer from the FPC team.
hmmm ... i'm sensing some sarcasm.
i'm not usually one to post dumb questions to a list because i'm lazy
or have nothing better to do.
also, i thought this was the "users" list ... not the compiler developers list.
in any event ... i have no idea if putting 3GB's of "writeln"
statements in a file is a good test.
in my case, the data would have to have structure.
it isn't just the size of the source file, but the size of the code as
generated by the compiler into the DLL.
are there limits to the "code segment" or other such internals of the
compiler and runtime file ?
i think the way i would have to lay it out would be to have 1000's of
Pascal "record" types, with members that are a mixture of "constant"
String and Double values.
i guess i would have to put all of these "record"s inside of a
procedure that alloced and assigned them all as members of an array,
upon invocation of the function at runtime ?
maybe i could put them in the initializer ?
it would actually take me some time to even lay the thing out to begin
with ... only to find that it doesn't work ... or that I _assume_ it
won't work ... because i took one path that didn't work, where there
might have been another that would have ... had i known.
so you see ... i feel like it is maybe more complicated that just
testing by echoing 3GB's of "writeln" statements into a source file
and compiling it.
if no one has any thoughts on it ... i'll go to the next step ... but
i didn't think it would hurt to ask the question.
but thanks for the help.
>
> Here are my prefered colors for your website (take it or leave it):
>
> body bgcolor="#1E1E1E" text="#D7D7D7" link="#006699" alink="#006699"
> vlink="#006699"
>
> Gotta love dark backgrounds.
>
> hmmm website Sigs really do work because I went ahead and clicked on your
> site.
hmmm ... i just don't know if i'm reading into the intent of your
comments very well.
btw ... the screenshots you see there are screenshots of a plugin i've
written for a simulator i use from http://www.x-plane.com ... using
Free Pascal.
>
> --
> L505
Tony
--
X-SA user ? 0.4 is out !
http://x-plane.dsrts.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] source file size ?
Tony Pelton wrote: hi all, i wanted to ask a question, before i spend time going down a road to implement it. are there any know limits on how big a source file can be for the FPC compiler ? i was thinking about experimenting with "code generating" a source file that would become a memory resident database of sorts. this would make my application, implemented as a shared library "plugin" quite fast, and would potentially simplify the distribution of my shared library to my user base. are there any thoughts on having a source file that might be megabytes in size that is basically just structured data implemented as source ? I think there are no hard limits on the source size. But you have to keep in mind that procedures (and maybe data) cannot become infinitely long, generating fast object code for them would be too complicated. I would definitely try it. BTW, lazarus is doing something similar, generating large strings that act as resource, the largest several 100's of KB. But they are statically linked. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
