[fpc-pascal] BUG:flush the serial in FPC2.6.0
I am trying to flush the serial incom on Linux with no success. So far I have: serial.pp in fpc 2.6.0 is SerFlush, which calls fpfsync, intended to discard input data, no work. it is patch as 0018946 but for fpc 2.4.2 no 2.6.0 http://free-pascal-general.1045716.n5.nabble.com/Unix-serial-port-handling-td3413763.html#a3415365 -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/BUG-flush-the-serial-in-FPC2-6-0-tp5710299.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] BUG:flush the serial in FPC2.6.0
kc87654321 wrote: I am trying to flush the serial incom on Linux with no success. So far I have: serial.pp in fpc 2.6.0 is SerFlush, which calls fpfsync, intended to discard input data, no work. it is patch as 0018946 but for fpc 2.4.2 no 2.6.0 http://free-pascal-general.1045716.n5.nabble.com/Unix-serial-port-handling-td3413763.html#a3415365 That patch should be good all the way to 2.7.1- I'm using it here as routine. SerFlush() was discussed in the list a few months ago, and the consensus was that it was probably inappropriate which is why I've marked it as deprecated. Try SerFlushInput() which goes straight to the operating system. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Database problem on Solaris SPARC
I've found a problem when a (well-tested) program that connects to a PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux SPARC is OK. I appreciate that this is a minority platform, but would I be less unpopular reporting it against 2.6.0 or testing it against 2.7.1 first? Problem appears to be in pqconnection.pp and I can see that it's recently been worked on. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database problem on Solaris SPARC
Am 12.07.2012 10:11 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > I've found a problem when a (well-tested) program that connects to a PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux SPARC is OK. > > I appreciate that this is a minority platform, but would I be less unpopular reporting it against 2.6.0 or testing it against 2.7.1 first? Problem appears to be in pqconnection.pp and I can see that it's recently been worked on. As you said sparc-solaris is a minority target so it would be very helpful if you could test with trunk as well. If the problem does not appear there you could ask whether the fixes could be merged back. Otherwise you report a bug for 2.7.1 and then ask to merge it back once that is fixed. Though it's likely that your help will be required because of the seldomness of your target. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : JSON and UTF8
On 11-7-2012 22:22, waldo kitty wrote: > On 7/11/2012 01:36, Reinier Olislagers wrote: >> On 11-7-2012 4:19, waldo kitty wrote: >>> On 7/10/2012 07:00, Luiz Americo Pereira Camara wrote: With the old behavior, in an system with a system code page<> UTF8, if i try to show the parsed value of "\u4E01" in e.g. a LCL app will get garbage. I would expect to work correctly in any enviroment >>> >>> this means that some environments will end up with "garbage" for those >>> UTF-8 characters that cannot be translated back to the local codepage... >> >> And your point is? > > that there will be data loss when converting from UTF-8 to codepages > with less characters than UTF-8 has... that is what i stated and i > thought it was an answer to the poster's question/problem of conversion... > maybe we're talking the same basic point to each other? ;) Could be, but I had the feeling you failed to see the advantage of not doing an unicode=>codepage conversion inside the FPJSON code if you don't want codepage output. Actually, it was me who had trouble with the original setup of FPJSON discarding information because it did the unicode=>codepage conversion regardless. I wanted to get UTF8 and could never get that. My solution was to modify (a tiny bit) and fork FPJSON for my twitter/OAuth v1 library. To my pleasant surprise, Luiz Americo posted bug 22310 based on that and fortunately Michael Van Canneyt adapted fpjson so I can use it for e.g. my twitter code... and retire the fork once FPC trunk has been released as stable and is widely available (solved it now with a conditional unit inclusion). So thanks to Luiz & Michael, and as always comments/patches welcome: https://bitbucket.org/reiniero/fpctwit ... or new applications based on this; oauthv1 is apparently also used by Yahoo and other providers... Leledumbo on the forum has e.g. written an application for plurk.com with the library: https://bitbucket.org/leledumbo/fpctwit ... and he said he intended to adapt it for use with Facebook sometime... Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Database problem on Solaris SPARC
> I've found a problem when a (well-tested) program that connects to a > PostgreSQL database is compiled and run on Solaris 10 for > SPARC, Linux > SPARC is OK. > > I appreciate that this is a minority platform, but would I be less > unpopular reporting it against 2.6.0 or testing it against > 2.7.1 first? > Problem appears to be in pqconnection.pp and I can see that it's > recently been worked on. > AFAIK non of the recent changes in pqconnection.pp would affect solaris (alignment or other). So if the program compiled with 2.6.0 works fine on linux sparc and fails on solaris sparc I would suspect more the PostgreSQL client libraries. Are those the same versions? What problems are you experiencing? Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Ludo Brands wrote: I've found a problem when a (well-tested) program that connects to a PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux SPARC is OK. I appreciate that this is a minority platform, but would I be less unpopular reporting it against 2.6.0 or testing it against 2.7.1 first? Problem appears to be in pqconnection.pp and I can see that it's recently been worked on. AFAIK non of the recent changes in pqconnection.pp would affect solaris (alignment or other). So if the program compiled with 2.6.0 works fine on linux sparc and fails on solaris sparc I would suspect more the PostgreSQL client libraries. Are those the same versions? What problems are you experiencing? As background, program gets information from a table on a PostgreSQL server using 2x query objects in a thread. The current info is then copied to foreground LCL components using synchronise. I don't think any of this is relevant since it works reliably on Linux on all other architectures available to me, doesn't work on Windows for unrelated reasons (named pipe issue). Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a consistent error Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Current language: auto; currently pascal (gdb) bt #0 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLO #1 0x004b58c8 in TCUSTOMSQLQUERY__LOADFIELD (FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=false, this=0xf #2 0x004ef414 in TCUSTOMBUFDATASET__LOADBUFFER (BUFFER=0xfa5f00bc '', this=0xfceb96c0) at bufdataset.pas:1781 #3 0x004eeaec in TCUSTOMBUFDATASET__GETNEXTPACKET (this=0xfceb96c0) at bufdataset.pas:1665 #4 0x004edf4c in TCUSTOMBUFDATASET__GETRECORD (BUFFER=0xfa5f04a0 '', GETMODE=GMNEXT, DOCHECK=true, this=0xf #5 0x004c8278 in TDATASET__GETNEXTRECORD (this=0xfceb96c0) at dataset.inc:770 #6 0x004c8438 in TDATASET__GETNEXTRECORDS (this=0xfceb96c0) at dataset.inc:799 #7 0x004c9744 in TDATASET__RECALCBUFLISTSIZE (this=0xfceb96c0) at dataset.inc:1154 #8 0x004c6e14 in TDATASET__DOINTERNALOPEN (this=0xfceb96c0) at dataset.inc:411 #9 0x004c8cb0 in TDATASET__OPENCURSOR (INFOQUERY=false, this=0xfceb96c0) at dataset.inc:962 #10 0x004c92fc in TDATASET__SETACTIVE (VALUE=true, this=0xfceb96c0) at dataset.inc:1087 Those lines are truncated since I've C&Ped from a disconnected ssh session. Appears to be this on 2.6.0: dbl := pointer(buffer); if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; // 803 which I think is this on 2.7.1 although I've not tested yet: dbl := pointer(buffer); if FIntegerDatetimes then dbl^ := BEtoN(pint64(CurrBuff)^) / 100 // 856 else Also I've not tested recently on ARM Linux, but since SPARC Linux is OK it's unlikely to be a straight alignment error. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Patch application
I uploaded a patch in #22359 about a week ago but I see that it’s not been applied yet. (There was something wrong in previous versions but I believe the latest one should be correct.) Since it’s been about a week, I’m wondering if there’s still something that I missed. Thanks. -- Best regards, JC Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: BUG:flush the serial in FPC2.6.0
good work,thinks! -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/BUG-flush-the-serial-in-FPC2-6-0-tp5710299p5710308.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Hi, On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote: > Ludo Brands wrote: > > Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a > consistent error > > Program received signal SIGSEGV, Segmentation fault. > [Switching to LWP 4] > 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, > FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa > 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. "buffer" is not aligned to 8 bytes here... (0xfa5f00bc <---) Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Thomas Schatzl wrote: Hi, On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote: Ludo Brands wrote: Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a consistent error Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. "buffer" is not aligned to 8 bytes here... (0xfa5f00bc <---) Although it's OK on Linux. However that pint64() could be relevant. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database problem on Solaris SPARC
Thomas Schatzl wrote on Thu, 12 Jul 2012: On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. "buffer" is not aligned to 8 bytes here... (0xfa5f00bc <---) We only support 32 bit SPARC, and there we split a 64 bit load into two 32 bit loads. dbl, assuming it points to a double, should point to a 64 bit-aligned memory location though (depending on the cpu, 32 bit alignment may be sufficient, but better be safe than sorry). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database problem on Solaris SPARC
Jonas Maebe wrote: Thomas Schatzl wrote on Thu, 12 Jul 2012: On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. "buffer" is not aligned to 8 bytes here... (0xfa5f00bc <---) We only support 32 bit SPARC, and there we split a 64 bit load into two 32 bit loads. dbl, assuming it points to a double, should point to a 64 bit-aligned memory location though (depending on the cpu, 32 bit alignment may be sufficient, but better be safe than sorry). I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK. Is the if FIntegerDatetimes then something Solaris-specific Ludo?)? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database problem on Solaris SPARC
Mark Morgan Lloyd wrote on Thu, 12 Jul 2012: I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK. The memory layout is not necessarily the same on both OSes. Is the if FIntegerDatetimes then something Solaris-specific Ludo?)? That would be extremely unlikely. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Small and not instalable web server for a local Pascal CGI application
Hello all, I am running some CGIs in localhost. When talking about web servers, the name of Apache comes as natural. However, I would like to share some zip files to show the results. For this purpose, Apache is not the best because I need something not instalable. I tried a small server called Mongoose. I was enthusiastic with the size: 140 kilobytes. Unfortunately, it used to fail when dealing with some UTF-8 PathInfos. Regarding I don't need many resources to run simple applications in localhost, I would like indications about small, not instalable web servers, ideal for my simple and sharable Pascal CGIs! Does someone know something about this? Regards, Luciano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Database problem on Solaris SPARC
In our previous episode, Jonas Maebe said: > > > I'll try to test against 2.7.1 later in the day, although as I've > > said Linux is OK. > > The memory layout is not necessarily the same on both OSes. Or does the linux kernel contain a facility to work around certain kinds of exceptions? E.g. IIRC linux recovered float loading alignment problem automatically for PPC 603, and netbsd didn't. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Small and not instalable web server for a local Pascal CGI application
On Thu, 12 Jul 2012, luciano de souza wrote: Hello all, I am running some CGIs in localhost. When talking about web servers, the name of Apache comes as natural. However, I would like to share some zip files to show the results. For this purpose, Apache is not the best because I need something not instalable. I tried a small server called Mongoose. I was enthusiastic with the size: 140 kilobytes. Unfortunately, it used to fail when dealing with some UTF-8 PathInfos. Regarding I don't need many resources to run simple applications in localhost, I would like indications about small, not instalable web servers, ideal for my simple and sharable Pascal CGIs! Does someone know something about this? FPC comes with a small webserver ? You don't even need the CGIs then. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Database problem on Solaris SPARC
> > We only support 32 bit SPARC, and there we split a 64 bit load into > > two > > 32 bit loads. dbl, assuming it points to a double, should > point to a 64 > > bit-aligned memory location though (depending on the cpu, 32 bit > > alignment may be sufficient, but better be safe than sorry). > > I'll try to test against 2.7.1 later in the day, although as > I've said > Linux is OK. Is the if FIntegerDatetimes then something > Solaris-specific Ludo?)? > No, the value is read from the server and depends on how the server was compiled. Run 'show integer_datetimes;' in psql or whatever client you are using to see the value. Pqconnection has detected that it is 'on' on your server. You can check with above command to see if the server agrees with that. With integer_datetimes on the datetime is returned as an int64 with the number of microseconds since 2000-01-01 00:00:00 UTC, hence the dbl^ := pint64(buffer)^/100; Dbl is a Pdouble, so the alignment problem could indeed come from there. The buffer returned by the driver is correct because just before you have pint64(buffer)^ := BEtoN(pint64(CurrBuff)^); CurrBuff being the pointer returned. Now, you are getting a SIGSEGV, not a SIGBUS which is what you would get for an alignment problem. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Small and not instalable web server for a local Pascal CGI application
Theres lightwebserver in Powutils 2012/7/12 Michael Van Canneyt : > > > On Thu, 12 Jul 2012, luciano de souza wrote: > >> Hello all, >> I am running some CGIs in localhost. When talking about web servers, >> the name of Apache comes as natural. However, I would like to share >> some zip files to show the results. For this purpose, Apache is not >> the best because I need something not instalable. >> I tried a small server called Mongoose. I was enthusiastic with the >> size: 140 kilobytes. Unfortunately, it used to fail when dealing with >> some UTF-8 PathInfos. >> Regarding I don't need many resources to run simple applications in >> localhost, I would like indications about small, not instalable web >> servers, ideal for my simple and sharable Pascal CGIs! Does someone >> know something about this? > > > FPC comes with a small webserver ? You don't even need the CGIs then. > > Michael. > > ___ > 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
Re: [fpc-pascal] Patch application
Am 12.07.2012 12:20 schrieb "JC Chu" : > > I uploaded a patch in #22359 about a week ago but I see that it’s not > been applied yet. (There was something wrong in previous versions but > I believe the latest one should be correct.) Since it’s been about a > week, I’m wondering if there’s still something that I missed. Patch application or bug fixing in general is not always done immediately (see for example how old some generic bugs are). A developer needs to have time to look at the patch and check whether it breaks anything. That said I myself am currently a bit busy with university related topics as it's the end of the term so the time I can spend with working on FPC is sadly limited. :( Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Small and not instalable web server for a local Pascal CGI application
On 12 July 2012 15:20, luciano de souza wrote: > localhost, I would like indications about small, not instalable web > servers, ideal for my simple and sharable Pascal CGIs! Does someone > know something about this? Have a look an nYume. It is a small and easy, but fully functional HTTP-server. Multi-threaded, supports CGI and Virtual Hosts. It consists of 4 object pascal units and a total of 1000 lines of code. That's small, and very functional. There is also the HttpServ example of Synapse. Then there is the Aservia project from Powtils. It is based on nYume, but I don't actually know what they changed. http://powtils.googlecode.com/svn/dev/tools/aservia/ I've personally had good success with the nYume project. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fcl-passrc package question about source file and line number info
Greetings! I've been using fcl-passrc (PParser and PasTree) to create a tool to help me with coverage analysis. Using the example provided in the package directory as a starting point, I've created a tool which finds the "begin" line number for each function/procedure definition and inserts a line of code there to help me keep track which functions are called and which aren't in my coverage tests. I've got it working great and it's giving me some really useful information. I was looking at the idea of increasing my granularity by doing this for every code block rather than just once at the beginning of every function. However, as I'm descending down through the parse tree, I'm finding that most of the TPasImplBlock objects have empty SourceFilename values and SourceLinenumber is 0. TPasProcedure's TProcedureBody's TPasImplBlock has the source file/line number information set, but if I descend any lower than that the deeper TPasImplBlock do not. Could someone with insight into this area give me any idea of why this is? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc package question about source file and line number info
On Thu, 12 Jul 2012, Seth Grover wrote: Greetings! I've been using fcl-passrc (PParser and PasTree) to create a tool to help me with coverage analysis. Using the example provided in the package directory as a starting point, I've created a tool which finds the "begin" line number for each function/procedure definition and inserts a line of code there to help me keep track which functions are called and which aren't in my coverage tests. I've got it working great and it's giving me some really useful information. I was looking at the idea of increasing my granularity by doing this for every code block rather than just once at the beginning of every function. However, as I'm descending down through the parse tree, I'm finding that most of the TPasImplBlock objects have empty SourceFilename values and SourceLinenumber is 0. TPasProcedure's TProcedureBody's TPasImplBlock has the source file/line number information set, but if I descend any lower than that the deeper TPasImplBlock do not. Could someone with insight into this area give me any idea of why this is? Oversight, a bug. I am currently working on the parser, I'll look into this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Ludo Brands wrote: We only support 32 bit SPARC, and there we split a 64 bit load into two 32 bit loads. dbl, assuming it points to a double, should point to a 64 bit-aligned memory location though (depending on the cpu, 32 bit alignment may be sufficient, but better be safe than sorry). I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK. Is the if FIntegerDatetimes then something Solaris-specific Ludo?)? No, the value is read from the server and depends on how the server was compiled. Run 'show integer_datetimes;' in psql or whatever client you are using to see the value. Pqconnection has detected that it is 'on' on your server. You can check with above command to see if the server agrees with that. Agreed, returns 'on'. With integer_datetimes on the datetime is returned as an int64 with the number of microseconds since 2000-01-01 00:00:00 UTC, hence the dbl^ := pint64(buffer)^/100; Dbl is a Pdouble, so the alignment problem could indeed come from there. The buffer returned by the driver is correct because just before you have pint64(buffer)^ := BEtoN(pint64(CurrBuff)^); CurrBuff being the pointer returned. Now, you are getting a SIGSEGV, not a SIGBUS which is what you would get for an alignment problem. [Nod], understood. Hit a slight snag here with trunk FPC + trunk Lazarus: Target OS: Solaris for SPARC Compiling sqldblaz.pas Compiling registersqldb.pas registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used by registersqldb Fatal: Compilation aborted make[2]: *** [sqldblaz.ppu] Error 1 make[2]: Leaving directory `/export/home/local-share/lazarus-trunk/components/sqldb' make[1]: *** [bigide] Error 2 make[1]: Leaving directory `/export/home/local-share/lazarus-trunk/components' make: *** [bigidecomponents] Error 2 -bash-3.00$ svn up At revision 37922. Anybody got any quick suggestions? "all" builds OK but I presume I need "bigide" because I've used the TQuery etc. on the form. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
> Oversight, a bug. > I am currently working on the parser, I'll look into this. > Michael. Thanks, I appreciate it. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch application
Our end-of-semester rushes usually take 2 weeks. Anyway I’m hoping it’s going to be tested (I did for i386-win32 and x86_64-win64) and applied asap. :( -- Best regards, JC Chu On Jul 12, 101 R.O.C., at 23:32, Sven Barth wrote: Am 12.07.2012 12:20 schrieb "JC Chu" : > > I uploaded a patch in #22359 about a week ago but I see that it’s not > been applied yet. (There was something wrong in previous versions but > I believe the latest one should be correct.) Since it’s been about a > week, I’m wondering if there’s still something that I missed. Patch application or bug fixing in general is not always done immediately (see for example how old some generic bugs are). A developer needs to have time to look at the patch and check whether it breaks anything. That said I myself am currently a bit busy with university related topics as it's the end of the term so the time I can spend with working on FPC is sadly limited. :( Regards, Sven ___ 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
