RE : [fpc-pascal] Re: RE : Re: RE : RE : RE : Assigning value to ftVariant datatype& varbytes-still stuck
> Oops, sorry, you're right. Your cygwin diffs don't seem to > agree with (the way I use) fpc patch; I got it to apply only > the first part of the patch... Now it works. > The patches I upload to bugs.freepascal are made with svn diff. The ones I sent you earlier were made with cygwin diff since the code wasn't versioned with svn. > Using fpc diff -u --minimal oldfile newfile > patch.diff does > work for me with patch -p0 < patch.diff I suppose you use > cygwin patch to apply the patches? > I use patch -p0 < patch.diff. The cygwin diff I sent earlier: I forgot to mention the diff -u parameter, hence the different format. Sorry, Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
Hello, I am ressuscitating this ancient thread because I'd like to continue the talk about it =) My main doubt here is if androidprt0.as is really required, which would mean that I can only produce android libraries if I make changes to the compiler. Benjamin, couldn't one just declare the missing simbols in code? This would simplify things a bit. Original message since most probably won't have it: On Sun, Jun 27, 2010 at 9:50 AM, Benjamin Jan Alexander Rosseaux wrote: > I've done a working Free Pascal android JNI example (with working .apk for > current ARM-based Android device of the second device generation (because > with VFPv3, so Motorola Droid/Milestone, HTC Desire, Nexus One, Samsung > Galaxy S, and so on) inside) > > http://vserver.rosseaux.net/stuff/FPCAndroidJNINativeTest.zip > > It contains androidprt0.as as replacement for the empty arm/linux dllprt0.as > of the FreePascal RTL from the SVN, because otherwise the Android Dalvik VM > refuses to load the .so library because of missed/absent > global/import/export symbols (_haltproc_eabi, __strptr, > __operatingsystem_parameter_argv and so on). > > It contains also a own JNI header port from the Android NDK, and own ARM > Toolchain hook binaries to inject some command line parameters to the > original "as" and "ld" binary calls. For "as": "--march=armv7-a > -mfloat-abi=softfp -mfpu=vfp3" and for "ld": "--fix-cortex-a8" > > And important FPC parameters are -CpARMv6 -CfVFPV3 > > I've done it, because i'm needing my own ECMAScript 5th edition engine > called BESEN in a Android project of me. > > Someone can make maybe a true patch from this for FreePascal for a offical > android target support in FreePascal. And my OpenGL ES 2.0 headers (what I > did originally for Nokia N900 for Maemo 5) are already in the FPC > bugtracker, which should also under Android after a single-line-change of > the OpenGL ES library path. > > Benjamin 'BeRo' Rosseaux > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] timer_create on linux
Hi,
I tried to implement linux timer with timer_create and signals, but an
exception always fired (External:SIGUSR1).
It was a lcl program, but I narrowed it to a console one.
Here is the lines without extra codes of releasing (the error appears
before),
What can be wrong with the code below?
Thanks in advance,
Max
==
program ConsTest;
uses ... libc, baseunix;
procedure PosixTimerHandler(signal: longint; info: psiginfo; context:
psigcontext);cdecl;
begin
Now; // <- Never stops here.
end;
procedure TMyApplication.DoRun;
var
...
fnewact: SigActionRec;
fits: itimerspec;
sev: sigevent;
timerid: timer_t;
begin
...
{ add your program here }
FillChar(fnewact, sizeof(SigActionRec),0);
fnewact.sa_handler := @PosixTimerHandler;
fnewact.sa_flags:=SA_SIGINFO;
if fpsigaction(SIGUSR1,@fnewact, Nil) <> 0 then
raise Exception.Create('sigaction failed');
sev.sigev_notify := SIGEV_SIGNAL;
sev.sigev_signo := SIGUSR1;
timer_create(CLOCK_REALTIME, @sev, @timerid);
fits.it_value.tv_sec := 1;
fits.it_value.tv_nsec := 0;
fits.it_interval.tv_sec := 1;
fits.it_interval.tv_nsec := 0;
timer_settime(timerid, 0, @fits, Nil);
ReadLn(); // <- raise External:SIGUSR1. With debug fpc rtl, the line stops
at "call psysinfo" inside FpSysCall
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigning value to ftVariantdatatype& varbytes-still stuck
> > I do get a segfault in the last test when assigning to > > ftWideString256. When tracing the code it crashes when moving the > > size+1 chracters to the database. This fixed length moving is > > fundamentally wrong. The string is only 20 or so chars long and > > TCustomBufDataset.SetFieldData tries to do a move of the full 514 > > bytes (256+1)*2. This asking for trouble. The source of the data is > > here a temporary WideString created by casting a string, so > probably > > on the heap. Reading 514 bytes when only 40 odd where > allocated is not > > always working > > > > I'll try to fix that one also. > I'd appreciate that a lot! > Uploaded a patch to http://bugs.freepascal.org/view.php?id=19930. Initially, because of the crash, I wanted to submit another bug report but the more I dig into this, the more I feel the definition of SetFieldData/GetFieldData without a length/size parameter and strings passed as pchar is causing all kind of problems: 1) TStringField.SetAsString copies the string to a buffer with size dsMaxStringSize so that datasets that don't figure out the original length of the string can simply copy the full Field.TDatasize (TBufDataset, TDbf, TMemDataset,...). TWideStringField.SetAsString didn't which caused the crash when the string is shorter than Field.Size. TCustomSqliteDataset uses a StrNew(PChar(Buffer)); to get the length of the string but fails sometimes (see 4). 2) dsMaxStringSize isn't enforced for TStringField. Defining a Field.size > dsMaxStringSize causes a crash in TStringField.SetAsString. I haven't raised an issue on this, yet. 3) some of the speed advantage of memory based datasets is offset by moving full Field.Tdatasize bytes in both set and get fielddata 4) pascal strings can contain #0 characters in the string. When converting to pchar part of these strings is lost. What I propose is: 1 to create overloaded versions of SetFieldData and GetFieldData that include a length parameter, to change TStringField.SetAsString and TWideStringField.SetAsWideString to use these versions and to migrate the different datasets to use these new versions. This way existing (user) code using SetFieldData/GetFieldData will still work (and the user still being responsible for buffer overruns...) and datasets can correctly save and retrieve strings while improving performance. 2 change the bufdataset internal storage for ftstring and ftwidestring fields to include the string length so that stored strings can be retrieved in full when containing #0 characters and without having to copy systematically datasize bytes. However this will introduce an incompatible binary format for TFpcBinaryDatapacketReader. Having a second FpcBinaryIdent would allow for both formats to co-habitate. If need be the discussion can be moved to fpc-devel. Ludo PS: no misunderstanding. I'm volunteering to make these changes;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
Hi, On Wed, 10 Aug 2011 11:09:26 +0200, Felipe Monteiro de Carvalho wrote: Hello, I am ressuscitating this ancient thread because I'd like to continue the talk about it =) My main doubt here is if androidprt0.as is really required, which would mean that I can only produce android libraries if I make changes to the compiler. Note that there is no dedicated android/arm support (or any arm support) for freepascal yet. In some circumstances the arm/linux stuff works. Benjamin, couldn't one just declare the missing simbols in code? This would simplify things a bit. An improved dllprt0.as has been created since, which works fine at least for arm/linux. However, you might want to use the hack from http://mantis.freepascal.org/view.php?id=18833 on android for now. If you can give me some documentation how/if argc/argv/envp are passed to a shared library on android, one could see if support can be added. I assume that some sort of new target may need to be added though. You might want to check whether proper initialization and finalization is performed for those libraries correctly for arm/android. At least when using dlopen and friends on arm/linux (and others) this works. When linking a FPC library using $LINKLIB, initialization/finalization is not called on several linux platforms (ppc/ppc64/arm) or crashes badly on unload at least on some linuxes (x86/amd64 on ubuntu). It contains also a own JNI header port from the Android NDK, and own ARM Toolchain hook binaries to inject some command line parameters to the original "as" and "ld" binary calls. For "as": "--march=armv7-a -mfloat-abi=softfp -mfpu=vfp3" and for "ld": "--fix-cortex-a8" And important FPC parameters are -CpARMv6 -CfVFPV3 Not sure whether the as/ld issues have been fixed in the meantime. Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timer_create on linux
On Wed, 10 Aug 2011, Max Vlasov wrote: Hi, I tried to implement linux timer with timer_create and signals, but an exception always fired (External:SIGUSR1). It was a lcl program, but I narrowed it to a console one. Here is the lines without extra codes of releasing (the error appears before), What can be wrong with the code below? I assume threads are used for these timers. If so, then this is normal, signal USR1 is used by the linux threading mechanism, if I remember correctly. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
Hi, On Wed, 10 Aug 2011 11:59:03 +0200, Thomas Schatzl wrote: Hi, On Wed, 10 Aug 2011 11:09:26 +0200, Felipe Monteiro de Carvalho wrote: Hello, I am ressuscitating this ancient thread because I'd like to continue the talk about it =) My main doubt here is if androidprt0.as is really required, which would mean that I can only produce android libraries if I make changes to the compiler. Note that there is no dedicated android/arm support (or any arm support) for freepascal yet. In some circumstances the arm/linux stuff works. meant "or any android support" here. Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Quitting simplehttpserver
ZeelandNet Webmail I've been trying the simplehttpserver and found a problem, but I have no idea what is goiing on. When I request a page, everything works fine, but when I try to request a non existing page and then go back to the existing page, the server quits. I have tried GDB, but I get no backtrace at all. Also heaptrace does not show any unfreed memory, which indicates the server has quit nicely and tidied up everything. Is this a known issue? I would say it's a bug, but maybe I'm missing something here. Regards, Darius ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : RE : RE : Assigning value to ftVariantdatatype& varbytes-still stuck
On Wednesday 10 August 2011 11:51:41 Ludo Brands wrote: > What I propose is: > 1 to create overloaded versions of SetFieldData and GetFieldData that > include a length parameter, to change TStringField.SetAsString and > TWideStringField.SetAsWideString to use these versions and to migrate the > different datasets to use these new versions. This way existing (user) code > using SetFieldData/GetFieldData will still work (and the user still being > responsible for buffer overruns...) and datasets can correctly save and > retrieve strings while improving performance. > 2 change the bufdataset internal storage for ftstring and ftwidestring > fields to include the string length so that stored strings can be retrieved > in full when containing #0 characters and without having to copy > systematically datasize bytes. However this will introduce an incompatible > binary format for TFpcBinaryDatapacketReader. Having a second > FpcBinaryIdent would allow for both formats to co-habitate. > MSEgui version of tbufdataset uses UnicodeString in recordbuffer for string fields, see file lib/common/db/msebufdataset.pas. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
On Wed, Aug 10, 2011 at 11:59 AM, Thomas Schatzl wrote: > However, you might want to use the hack from > http://mantis.freepascal.org/view.php?id=18833 on android for now. What do you think about merging this hack to trunk and to 2.6.0? I can do the commit on trunk. I think that a hack support is better then no support at all. > If you can give me some documentation how/if argc/argv/envp are passed to a > shared > library on android I have no idea. > When linking a FPC library using $LINKLIB, initialization/finalization is > not called on several linux platforms (ppc/ppc64/arm) or crashes badly on > unload at least on some linuxes (x86/amd64 on ubuntu). =( The LCL contains initialization/finalization sections, so that could prevent the LCL to work via JNI. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Quitting simplehttpserver
On Wed, 10 Aug 2011 12:06:15 +0200, wrote: Nevermind, I overlooked the deactivation code in the example. Darius I've been trying the simplehttpserver and found a problem, but I have no idea what is goiing on. When I request a page, everything works fine, but when I try to request a non existing page and then go back to the existing page, the server quits. I have tried GDB, but I get no backtrace at all. Also heaptrace does not show any unfreed memory, which indicates the server has quit nicely and tidied up everything. Is this a known issue? I would say it's a bug, but maybe I'm missing something here. Regards, Darius ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
On 10 Aug 2011, at 12:10, Felipe Monteiro de Carvalho wrote: On Wed, Aug 10, 2011 at 11:59 AM, Thomas Schatzl wrote: However, you might want to use the hack from http://mantis.freepascal.org/view.php?id=18833 on android for now. What do you think about merging this hack to trunk and to 2.6.0? I can do the commit on trunk. I think that a hack support is better then no support at all. No, hacks like that do not belong in trunk. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timer_create on linux
On Wed, Aug 10, 2011 at 2:04 PM, wrote: > > > On Wed, 10 Aug 2011, Max Vlasov wrote: > > Hi, >> >> I tried to implement linux timer with timer_create and signals, but an >> exception always fired (External:SIGUSR1) >> What can be wrong with the code below? >> > > I assume threads are used for these timers. If so, then this is normal, > signal USR1 is used > by the linux threading mechanism, if I remember correctly. > > I also thought that the signal could be occupied by some api, but changing it to SIGRTMIN + 1, +2,+3 just changes the exception to "External:SIG35", "External:SIG36"... Maybe I should apply the blocking mask for other signal for this api since it probably uses threads? Max ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Re: RE : RE : RE : Assigning value toftVariantdatatype& varbytes-still stuck
> MSEgui version of tbufdataset uses UnicodeString in > recordbuffer for string > fields, see file lib/common/db/msebufdataset.pas. > Well done. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigning value toftVariantdatatype& varbytes-still stuck
> Uploaded a patch to > http://bugs.freepascal.org/view.php?id=19930. Initially, > because of the crash, I wanted to submit another bug report > but the more I dig into this, the more I feel the definition > of SetFieldData/GetFieldData without a length/size parameter > and strings passed as pchar is causing all kind of problems: > 1) TStringField.SetAsString copies the string to a buffer > with size dsMaxStringSize so that datasets that don't figure > out the original length of the string can simply copy the > full Field.TDatasize (TBufDataset, TDbf, TMemDataset,...). > TWideStringField.SetAsString didn't which caused the crash > when the string is shorter than Field.Size. > TCustomSqliteDataset uses a StrNew(PChar(Buffer)); to get the > length of the string but fails sometimes (see 4). > 2) dsMaxStringSize isn't enforced for TStringField. Defining > a Field.size > dsMaxStringSize causes a crash in > TStringField.SetAsString. I haven't raised an issue on this, yet. > 3) some of the speed advantage of memory based datasets is > offset by moving full Field.Tdatasize bytes in both set and > get fielddata > 4) pascal strings can contain #0 characters in the string. > When converting to pchar part of these strings is lost. > > What I propose is: > 1 to create overloaded versions of SetFieldData and > GetFieldData that include a length parameter, to change > TStringField.SetAsString and TWideStringField.SetAsWideString > to use these versions and to migrate the different datasets > to use these new versions. This way existing (user) code > using SetFieldData/GetFieldData will still work (and the user > still being responsible for buffer overruns...) and datasets > can correctly save and retrieve strings while improving performance. > 2 change the bufdataset internal storage for ftstring and > ftwidestring fields to include the string length so that > stored strings can be retrieved in full when containing #0 > characters and without having to copy systematically datasize > bytes. However this will introduce an incompatible binary > format for TFpcBinaryDatapacketReader. Having a second > FpcBinaryIdent would allow for both formats to co-habitate. > > If need be the discussion can be moved to fpc-devel. > > Ludo > > PS: no misunderstanding. I'm volunteering to make these changes;) > > BTW. Just noticed http://bugs.freepascal.org/view.php?id=19940 which is directly linked to problem 2). Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: timer_create on linux
On Wed, Aug 10, 2011 at 1:18 PM, Max Vlasov wrote: > Hi, > > I tried to implement linux timer with timer_create and signals, but an > exception always fired (External:SIGUSR1). > Hmm, it seems that it's not a 'wrong' exception, I executed the same program from console and it worked. So there's a range of signals that is 'wrong' for the debugger/ide and it stops catching them. Can I somehow tell it to ignore some, for example 'SIG35'? I tried to add it to Language exceptions ignore list as 'External: SIG35', 'External:SIG35' (without space), SIG35. Nothing helped. Max ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
On 10 Aug 2011, at 14:24, Max Vlasov wrote: On Wed, Aug 10, 2011 at 1:18 PM, Max Vlasov wrote: I tried to implement linux timer with timer_create and signals, but an exception always fired (External:SIGUSR1). Hmm, it seems that it's not a 'wrong' exception, I executed the same program from console and it worked. So there's a range of signals that is 'wrong' for the debugger/ide and it stops catching them. It's not considered as "wrong" by gdb. By default it simply catches all signals. If you type "cont" at that point, the program will continue execution and the signal will be delivered to the program. Can I somehow tell it to ignore some, for example 'SIG35'? I tried to add it to Language exceptions ignore list as 'External: SIG35', 'External:SIG35' (without space), SIG35. Nothing helped. handle SIG35 nostop noprint pass Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
On Wed, Aug 10, 2011 at 4:34 PM, Jonas Maebe wrote:
>
>
> Can I somehow tell it to
>> ignore some, for example 'SIG35'? I tried to add it to Language exceptions
>> ignore list as 'External: SIG35', 'External:SIG35' (without space), SIG35.
>> Nothing helped.
>>
>
> handle SIG35 nostop noprint pass
>
>
>
Jonas, where am I supposed to add this options?
I tried adding
--eval-command="handle SIGUSR1 nostop noprint pass"
to
Debugger_Startup_Options
but that didn't help. Actually nothing happened until I restarted the IDE.
After the restart the first run showed
---
Initialization output:
&"Undefined command:\"\".Try \"help\".\n"
--
To ensure the string is correct I tried
gdb --eval-command="handle SIGUSR1 nostop noprint pass"
from terminal and it worked.
Is it possible that some procedure makes c-style string translation (" ->
\") while actually it isn't necessary here?
Max
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
On 10 Aug 2011, at 15:32, Max Vlasov wrote: On Wed, Aug 10, 2011 at 4:34 PM, Jonas Maebe >wrote: Can I somehow tell it to ignore some, for example 'SIG35'? I tried to add it to Language exceptions ignore list as 'External: SIG35', 'External:SIG35' (without space), SIG35. Nothing helped. handle SIG35 nostop noprint pass Jonas, where am I supposed to add this options? That's what you can enter on the gdb console after you start it from the command line. I've never debugged using Lazarus, so I can't help with that. I tried adding --eval-command="handle SIGUSR1 nostop noprint pass" While this won't solve your problem, as Michael said you should not use SIGUSR1 because it's probably already used by the system. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Re: RE : Re: RE : RE : RE : Assigning value to ftVariant datatype& varbytes-still stuck
On 10-8-2011 9:49, Ludo Brands wrote: >> Oops, sorry, you're right. Your cygwin diffs don't seem to >> agree with (the way I use) fpc patch; I got it to apply only >> the first part of the patch... Now it works. >> > > The patches I upload to bugs.freepascal are made with svn diff. The ones I > sent you earlier were made with cygwin diff since the code wasn't versioned > with svn. > I use patch -p0 < patch.diff. > The cygwin diff I sent earlier: I forgot to mention the diff -u parameter, > hence the different format. Sorry, Thanks, no problem. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigning value to ftVariantdatatype& varbytes-still stuck
On 10-8-2011 11:51, Ludo Brands wrote: >>> I do get a segfault in the last test when assigning to >>> ftWideString256. When tracing the code it crashes when moving the >>> size+1 chracters to the database. This fixed length moving is >>> fundamentally wrong. The string is only 20 or so chars long and >>> TCustomBufDataset.SetFieldData tries to do a move of the full 514 >>> bytes (256+1)*2. This asking for trouble. The source of the data is >>> here a temporary WideString created by casting a string, so >> probably >>> on the heap. Reading 514 bytes when only 40 odd where >> allocated is not >>> always working >>> >>> I'll try to fix that one also. >> I'd appreciate that a lot! >> > > Uploaded a patch to http://bugs.freepascal.org/view.php?id=19930. Initially, > because of the crash, I wanted to submit another bug report but the more I > dig into this, the more I feel the definition of SetFieldData/GetFieldData > without a length/size parameter and strings passed as pchar is causing all > kind of problems: > 1) TStringField.SetAsString copies the string to a buffer with size > dsMaxStringSize so that datasets that don't figure out the original length > of the string can simply copy the full Field.TDatasize (TBufDataset, TDbf, > TMemDataset,...). TWideStringField.SetAsString didn't which caused the crash > when the string is shorter than Field.Size. TCustomSqliteDataset uses a > StrNew(PChar(Buffer)); to get the length of the string but fails sometimes > (see 4). > 2) dsMaxStringSize isn't enforced for TStringField. Defining a Field.size > > dsMaxStringSize causes a crash in TStringField.SetAsString. I haven't raised > an issue on this, yet. > 3) some of the speed advantage of memory based datasets is offset by moving > full Field.Tdatasize bytes in both set and get fielddata > 4) pascal strings can contain #0 characters in the string. When converting > to pchar part of these strings is lost. > > What I propose is: > 1 to create overloaded versions of SetFieldData and GetFieldData that > include a length parameter, to change TStringField.SetAsString and > TWideStringField.SetAsWideString to use these versions and to migrate the > different datasets to use these new versions. This way existing (user) code > using SetFieldData/GetFieldData will still work (and the user still being > responsible for buffer overruns...) and datasets can correctly save and > retrieve strings while improving performance. > 2 change the bufdataset internal storage for ftstring and ftwidestring > fields to include the string length so that stored strings can be retrieved > in full when containing #0 characters and without having to copy > systematically datasize bytes. However this will introduce an incompatible > binary format for TFpcBinaryDatapacketReader. Having a second FpcBinaryIdent > would allow for both formats to co-habitate. > > If need be the discussion can be moved to fpc-devel. > > Ludo > > PS: no misunderstanding. I'm volunteering to make these changes;) > I'd be happy to help with testing at least! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
On Wed, Aug 10, 2011 at 5:43 PM, Jonas Maebe wrote: > > > I tried adding >> --eval-command="handle SIGUSR1 nostop noprint pass" >> > > While this won't solve your problem, as Michael said you should not use > SIGUSR1 because it's probably already used by the system. > > SIG35 behaves the same. Strangely, I looked in system monitor for gdb command-line, it looked ok /usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint pass" but after the same Initialization output dialog it still stops with "External:SIG35" Actually looking at the -i mi options, I see it's machine interface with all these escaping sequences, so probably lazarus didn't undestand something, but it's strange it still stops Thanks anyway Max ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
On 10 Aug 2011, at 16:12, Max Vlasov wrote: SIG35 behaves the same. Strangely, I looked in system monitor for gdb command-line, it looked ok /usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint pass" but after the same Initialization output dialog it still stops with "External:SIG35" Actually looking at the -i mi options, I see it's machine interface with all these escaping sequences, so probably lazarus didn't undestand something, but it's strange it still stops Most commands are different in the machine interface. "handle SIG35 nostop noprint pass" is probably only valid when using the default interface. I don't know what the MI equivalent is. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
On Wed, Aug 10, 2011 at 6:20 PM, Jonas Maebe wrote: > > On 10 Aug 2011, at 16:12, Max Vlasov wrote: > > SIG35 behaves the same. Strangely, I looked in system monitor for gdb >> command-line, it looked ok >> >> /usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint >> pass" >> >> but after the same Initialization output dialog it still stops with >> "External:SIG35" >> Actually looking at the -i mi options, I see it's machine interface with >> all >> these escaping sequences, so probably lazarus didn't undestand something, >> but it's strange it still stops >> > > Most commands are different in the machine interface. "handle SIG35 nostop > noprint pass" is probably only valid when using the default interface. I > don't know what the MI equivalent is. > > > If I invoke the same full line in the terminal the output $ /usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint pass" =thread-group-added,id="i1" ~"SignalStop\tPrint\tPass to program\tDescription\n" ~"SIG35 No\tNo\tYes\t\tReal-time event 35\n" So looks like (Stop = No) gdb got the command. Jonas, I see that you probably have your reasons not to use gdb inside the lazarus, but it was quite decent for me until this strange unavoidable moment :) It still is, hope I will find a work around Max ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
Am 10.08.11 16:56, schrieb Max Vlasov: Jonas, I see that you probably have your reasons not to use gdb inside the lazarus, but it was quite decent for me until this strange unavoidable moment :) It still is, hope I will find a work around Max Max, This works (for me) 1) Add a file like : /Users/helly/fos_buildsys/gdbinit 2) Content of file is: handle SIGUSR1 pass noprint nostop 3) Add in Lazarus at Debuger_Startup_Options : --command /Users/helly/fos_buildsys/gdbinit 4) Depending on lazarus version -> Reset Debugger via Menu / or restart --- I use this to ignore signals, and it works here. (afair under linux/freebsd the same way) I debug a multithreaded server hith kevent/kqueue waiting on the signals. (hup,kill,usr1,int) in a commandline daemon. I am on OSX Lion, fpc 2.5.1 trunk (2 weeks ago) lazarus trunk (2-3 weeks) ago. helmut ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: timer_create on linux
On Wed, Aug 10, 2011 at 7:28 PM, Helmut Hartl wrote: > Am 10.08.11 16:56, schrieb Max Vlasov: > > Jonas, I see that you probably have your reasons not to use gdb inside the >> lazarus, but it was quite decent for me until this strange unavoidable >> moment :) It still is, hope I will find a work around >> >> Max >> > > Max, > > This works (for me) > > 1) Add a file like : > /Users/helly/fos_buildsys/**gdbinit > > 2) Content of file is: > handle SIGUSR1 pass noprint nostop > > 3) Add in Lazarus at > > Debuger_Startup_Options : --command /Users/helly/fos_buildsys/**gdbinit > > 4) Depending on lazarus version -> Reset Debugger via Menu / or restart > > --- > > I use this to ignore signals, and it works here. (afair under linux/freebsd > the same way) > I debug a multithreaded server hith kevent/kqueue waiting on the signals. > (hup,kill,usr1,int) in a commandline daemon. > I am on OSX Lion, fpc 2.5.1 trunk (2 weeks ago) lazarus trunk (2-3 weeks) > ago. > > Helmut, worked like magic! Thanks :) In case Graeme see this post (he hates over-quoting desperately), I intentionally did not cut the quote to make this useful information exist twice everywhere ;) Max ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Linking generics with long names with STABS gives Undefined Symbol
Hello.
I have the following program:
program atest;
{$mode objfpc}{$H+}
uses
Classes, SysUtils, fgl;
type
TMyClass = class end;
TControlObjectSpecializedWithAVeryLongNameOfClass = class end;
{$IFDEF USELONGNAME}
TMyType = TControlObjectSpecializedWithAVeryLongNameOfClass; // Error
{$ELSE}
TMyType = TMyClass; // OK
{$ENDIF}
TSpecControlInfo = specialize TFPGList;
begin
end.
If I build with:
$ fpc -dUSELONGNAME -gs atest.pas
Target OS: Win32 for i386
Compiling atest.pas
Linking atest.exe
atest.pas(36,1) Error: Undefined symbol:
VMT_P$ATEST_TBASECONTROLINFO$TOBJECTINFO$TVERYLONGNAMEOFCLASS_$_TFPGOBJECTLIST$TOBJECTINFO$TVERYLONGNAMEOFCLASS_$__TFPGLISTENUMERATOR$TOBJE
atest.pas(36,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
If I omit either "-dUSELONGNAME" or "-gs", or use dwarf debugging info
then linking is successful.
Is this some limitation of STABS or a bug?
My platform is Windows XP SP3 i386. FPC 2.7.1 r18142.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Patch to add GLX 1.4 support
Hi, For people working with new OpenGL features: I just submitted a patch to upgrade our GLX unit to GLX 1.4, add some new GLX extensions, and add comfortable functions to check existence of a particular GLX extension/version. This allows you to easily use modern GLX "FB config" functions to initialize OpenGL context, and to use glXCreateContextAttribsARB to request forward-compatible OpenGL context (without deprecated stuff). The patch is on http://bugs.freepascal.org/view.php?id=19953 The patch contains also modifications to glxtest example, to show new context creation approach. There's a good description of modern OpenGL context creation in the opengl.org wiki, see http://www.opengl.org/wiki/Creating_an_OpenGL_Context and http://www.opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_%28GLX%29 Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] The fpOpen call on a serial port blocks on a Mac. Why?
I am using the latest synaser (007.005.002) from the synapse library which works just fine with (USB) serial ports on Linux and Windows but Mac OSX 10.6 it is proving problematic. The call which opens the port (synaser.pas:946) is: FHandle := THandle(fpOpen(FDevice, O_RDWR or O_SYNC)); where in my case, FDevice is /dev/tty.usbserial.DCUIYCH4. This fpOpen call blocks indefinitely (i.e. it never returns). The device is present, working and requires no flow control: My-Mac:~ admin$ stty -f /dev/tty.usbserial-DCUIYCH4 -a speed 9600 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8 -ignbrk -brkint -inpck -ignpar -parmrk oflags: -opost -onlcr -oxtabs -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ; eol2 = ; erase = ^?; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; and the screen command opens and communicates via this port just fine so I don't believe there is anything wrong with the device, the driver or the state of any port flags when fpOpen is attempted. Can anyone tell me what I might be doing wrong here? Note that adding the O_NONBLOCK flag allows the fpOpen to succeed but all subsequent attempts to talk to the port return ENOTTY which is of course wrong as it is a real (USB) serial (TTY) device. I'm building with FPC 2.4.2 binaries and sources (for Mac) and it's an FTDI serial device I'm dealing with. Any and all advice most welcome. Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Where's my OSX window dressing?
I'm new to OSX so bear with me. Something has changed but I can't tell what. The consequence is that my Lazarus/FPC generated OSX applications are now missing their "window dressing"? It's like the OSX window manager has gone AWOL when I run my Lazarus apps. That is, the apps run fine but they run without a window title and they are located under the desktop menu, top left of the screen, from where they cannot be relocated. What's missing? What am I doing differently? How does Lazarus/FPC manage this stuff apropos the OSX window manager? I've done a clean rebuild thinking there may be something wrong with the Application Bundle previously created by Lazarus but recreating it does not seem to make any difference. Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Where's my OSX window dressing?
Okay, sorted. I had inadvertently relocated the application's main form design position to 0,0 and it was specified to appear at Form.Position poDefault which seems to mean the design location. I've changed the Form.Position to poDesktopCenter and it works okay now. What puzzles me is that OSX allows an application to appear such that its title bar is hidden by the desktop menu bar but does not seem to provide an easy way to then relocate the window to a new position. I'm clearly a Mac newbie, what am I missing? Cheers, Bruce. On 08/11/11 16:08, Bruce Tulloch wrote: > I'm new to OSX so bear with me. Something has changed but I can't tell > what. The consequence is that my Lazarus/FPC generated OSX applications > are now missing their "window dressing"? > > It's like the OSX window manager has gone AWOL when I run my Lazarus > apps. That is, the apps run fine but they run without a window title and > they are located under the desktop menu, top left of the screen, from > where they cannot be relocated. > > What's missing? What am I doing differently? How does Lazarus/FPC manage > this stuff apropos the OSX window manager? I've done a clean rebuild > thinking there may be something wrong with the Application Bundle > previously created by Lazarus but recreating it does not seem to make > any difference. > > Cheers, Bruce. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
