Re: [fpc-devel] MS SQL tests: fix for string settings invalid dates
Hello, I am struggeling with Lazarus and a connection to MSSQL server 2005. I get the data, but when i change a fieldvalue, then apply updates, I get the error 20019 like you listed: http://lists.freepascal.org/fpc-devel/2014-March/033494.html When ik hit OK the update is not applied, when i apply updates again immediately, then the updates apply correctly, but the connection or the query closes. Is there a solution? [cid:image001.png@01D00295.ED0CB500] Thanks in advance, Jan-Pieter Stolk ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MS SQL tests: fix for string settings invalid dates
On Mon, Nov 17, 2014 at 6:50 PM, JP Stolk jpst...@stolkbv.nl wrote: Hello, I am struggeling with Lazarus and a connection to MSSQL server 2005. I get the data, but when i change a fieldvalue, then apply updates, I get the error 20019 like you listed: http://lists.freepascal.org/fpc-devel/2014-March/033494.html When ik hit OK the update is not applied, when i apply updates again immediately, then the updates apply correctly, but the connection or the query closes. Is there a solution? Could you send an example of your code? The problem could be transaction, PK do not exists or other thing. I work with MSSQL 2005~2008 without these problems. But, I have problems with Transactions because SQLdb works little different to Delphi so, I create a project, the Greyhound*, that works better for me. Maybe you shoud try. * https://github.com/mdbs99/Greyhound Regards, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MS SQL tests: fix for string settings invalid dates
On Tue, Nov 18, 2014 at 8:56 AM, Marcos Douglas m...@delfire.net wrote: On Mon, Nov 17, 2014 at 6:50 PM, JP Stolk jpst...@stolkbv.nl wrote: Hello, I am struggeling with Lazarus and a connection to MSSQL server 2005. I get the data, but when i change a fieldvalue, then apply updates, I get the error 20019 like you listed: http://lists.freepascal.org/fpc-devel/2014-March/033494.html When ik hit OK the update is not applied, when i apply updates again immediately, then the updates apply correctly, but the connection or the query closes. Is there a solution? Could you send an example of your code? The problem could be transaction, PK do not exists or other thing. I work with MSSQL 2005~2008 without these problems. But, I have problems with Transactions because SQLdb works little different to Delphi so, I create a project, the Greyhound*, that works better for me. Maybe you shoud try. * https://github.com/mdbs99/Greyhound Regards, Marcos Douglas I mean: I *had* problems. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
Hi guys, I've spent a couple of days porting FPC to DragonFly BSD with some success. uname -a DragonFly banshee.x.com 3.9-DEVELOPMENT DragonFly v3.9.0.710.g6792a-DEVELOPMENT #0: Fri Oct 24 18:32:12 CEST 2014 r...@banshee.x.com:/usr/obj/usr/src/sys/X86_64_BANSHEE_SMP x86_64 bin/fpc -i Free Pascal Compiler version 2.6.4 Compiler Date : 2014/11/18 Compiler CPU Target: x86_64 Supported targets: Linux for x86-64 FreeBSD for x86-64 Win64 for x64 Darwin for x86_64 Solaris for x86-64 (under development) OpenBSD for x86-64 (under development) NetBSD for x86-64 (under development) DragonFly for x86-64 Supported CPU instruction sets: ATHLON64 Supported FPU instruction sets: SSE64 SSE3 Supported ABI targets: DEFAULT SYSV AIX EABI ARMEB Supported Optimizations: REGVAR STACKFRAME LOOPUNROLL TAILREC CSE Supported Whole Program Optimizations: All DEVIRTCALLS OPTVMTS SYMBOLLIVENESS Supported Microcontroller types: This program comes under the GNU General Public Licence For more information read COPYING.v2 Please report bugs in our bug tracker on: http://bugs.freepascal.org More information may be found on our WWW pages (including directions for mailing lists useful for asking questions or discussing potential new features, etc.): http://www.freepascal.org Since DragonFly uses the FreeBSD ports collection, the plan was to start with patches there and then get most of them into the repository (x86_64 only). However I hit a snag in the middle of the bootstrapping process and I could use some help. It won't compile because it can't find the units, but it can't find the units because it can't properly find out if a directory exists. bin/fpc -vut Configfile search: /home/marino/.fpc.cfg Configfile search: /usr/local/etc/fpc.cfg Reading options from file /usr/local/etc/fpc.cfg Path ./lib/fpc/2.6.4/units/x86_64-dragonfly/ not found Path ./lib/fpc/2.6.4/units/x86_64-dragonfly/*/ not found Path ./lib/fpc/2.6.4/units/x86_64-dragonfly/rtl/ not found Path /home/marino/.fppkg/lib/fpc/2.6.4/units/x86_64-dragonfly/*/ not found Path /usr/lib/ not found Path /lib/ not found Free Pascal Compiler version 2.6.4 [2014/11/18] for x86_64 Copyright (c) 1993-2014 by Florian Klaempfl and others Fatal: No source file name in command line Fatal: Compilation aborted Error: bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) I've narrowed down the problem to a malfunctioning strpas command, and further to the move command. I've temporarily disabled the assembly routines and I'm using the generic move command. What's going on is the move dest argument is receiving a different address location than the procedure that calls it gives. So the string copy works, but it's getting copied to the wrong location. See below gdb bin/fpc GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-dragonfly. For bug reporting instructions, please see: http://bugs.dragonflybsd.org/... Reading symbols from /usr/local/bin/fpc...done. (gdb) set args -vut (gdb) b generic.inc:886 Breakpoint 1 at 0x403b5f: file ../inc/generic.inc, line 886. (gdb) r Starting program: /usr/local/bin/fpc -vut Breakpoint 1, fpc_shortstr_to_shortstr (RES=..., highRES=255, SSTR=...) at ../inc/generic.inc:886 886 ../inc/generic.inc: No such file or directory. (gdb) p sstr $1 = '/etc/localtime' (gdb) p slen $2 = 14 (gdb) p @sstr $3 = (^SHORTSTRING) 0x658c48 '/etc/localtime' (gdb) p @res $4 = (^ OPENSTRING) 0x7228 ''#127#0#0'?'#127#0#0#27'WD'#0#0#0#0#0'?? Z'#2#1#0#0#0#1#0#0#0'?#'#4#138'?'#129'R'#128#0#0#0#0#0#0#0#0'?)kT'#0#0#0#0'? ?S'#0#0#0#0':?qP'#0#0#0#0#8#129'|,'#0#0#0#0':?qP'#0#0#0#0#8#129'|,'#0#0#0#0'6'# 8#0#0#0#0#0#0#4#0#0#0#0#0#0#0#0'@', #0 repeats 30 times, #2#16#0#0#0#0#0#0#3#0
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 18/11/14 13:00, John Marino wrote: Since DragonFly uses the FreeBSD ports collection, the plan was to start with patches there and then get most of them into the repository (x86_64 only). However I hit a snag in the middle of the bootstrapping process and I could use some help. It won't compile because it can't find the units, but it can't find the units because it can't properly find out if a directory exists. bin/fpc -vut Configfile search: /home/marino/.fpc.cfg Configfile search: /usr/local/etc/fpc.cfg Reading options from file /usr/local/etc/fpc.cfg Path ./lib/fpc/2.6.4/units/x86_64-dragonfly/ not found Path ./lib/fpc/2.6.4/units/x86_64-dragonfly/*/ not found Path ./lib/fpc/2.6.4/units/x86_64-dragonfly/rtl/ not found Path /home/marino/.fppkg/lib/fpc/2.6.4/units/x86_64-dragonfly/*/ not found Path /usr/lib/ not found Path /lib/ not found Free Pascal Compiler version 2.6.4 [2014/11/18] for x86_64 Copyright (c) 1993-2014 by Florian Klaempfl and others Fatal: No source file name in command line Fatal: Compilation aborted Error: bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) Such problems usually mean that the stat or statfs record needs adjustments. You can find the stat record definition in rtl/bsd/ostypes.inc. statfs is in rtl/yourosdir/ptypes.inc I've narrowed down the problem to a malfunctioning strpas command, and further to the move command. This is probably an issue of gdb being confused about formal parameters. I think @formalpara will get you the location on the stack of that parameter (it's passed in a register in that case, but FPC will copy it back to the stack locally if you compile without optimisations), not its value. Parameter passing on x86-64 is identical for all platforms except for Win64, so it would be very strange if it went wrong in such a common routine only on your new platform. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
Am 18.11.2014 13:46 schrieb John Marino fpc-de...@marino.st: Hi guys, I've spent a couple of days porting FPC to DragonFly BSD with some success. [...] bin/fpc -i Free Pascal Compiler version 2.6.4 I can't help you much with your specific problen, but new targets should be added to the development version of FPC (in this case 2.7.1) and not the release. Afterall you'll need to port it sooner or later to that version anyway and especially in the current case (2.6.4 vs 2.7.1) quite some changes happened. Additionally we (core developers) only work with the development version anyway (the release compiler is basically only used for compiling trunk), so it will be easier for us to help you as well. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 14:38, Jonas Maebe wrote: Such problems usually mean that the stat or statfs record needs adjustments. You can find the stat record definition in rtl/bsd/ostypes.inc. statfs is in rtl/yourosdir/ptypes.inc I think you nailed it. Actually I found an error on that file about half an hour ago and am regenerating everything. This is probably an issue of gdb being confused about formal parameters. I think @formalpara will get you the location on the stack of that parameter (it's passed in a register in that case, but FPC will copy it back to the stack locally if you compile without optimisations), not its value. Parameter passing on x86-64 is identical for all platforms except for Win64, so it would be very strange if it went wrong in such a common routine only on your new platform. Yeah, after finding the error above, I started wondering how accurate gdb was being. Will post back in a minute. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 14:58, John Marino wrote: On 11/18/2014 14:38, Jonas Maebe wrote: Such problems usually mean that the stat or statfs record needs adjustments. You can find the stat record definition in rtl/bsd/ostypes.inc. statfs is in rtl/yourosdir/ptypes.inc I think you nailed it. Actually I found an error on that file about half an hour ago and am regenerating everything. fixing the error in rtl/bsd/ostypes.inc didn't solve this particular issue. I'm pretty confident stat record is good though, I checked it thoroughly last night. However, I have very little confidence in rtl/dragonfly/ptypes.inc where statfs is concerned. In fact, I never touched it. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 14:43, Sven Barth wrote: Am 18.11.2014 13:46 schrieb John Marino fpc-de...@marino.st mailto:fpc-de...@marino.st: Hi guys, I've spent a couple of days porting FPC to DragonFly BSD with some success. [...] bin/fpc -i Free Pascal Compiler version 2.6.4 I can't help you much with your specific problen, but new targets should be added to the development version of FPC (in this case 2.7.1) and not the release. Afterall you'll need to port it sooner or later to that version anyway and especially in the current case (2.6.4 vs 2.7.1) quite some changes happened. Additionally we (core developers) only work with the development version anyway (the release compiler is basically only used for compiling trunk), so it will be easier for us to help you as well. It doesn't matter, I'll just have to do it twice. I have to patch the latest release -- otherwise we won't get it until the next release and subsequent import into ports. Plus it's more important to get FPC bootstrapped at this point. I think the patches would apply to a dev branch without too much trouble though. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
In our previous episode, Jonas Maebe said: Path /usr/lib/ not found Path /lib/ not found Free Pascal Compiler version 2.6.4 [2014/11/18] for x86_64 Copyright (c) 1993-2014 by Florian Klaempfl and others Fatal: No source file name in command line Fatal: Compilation aborted Error: bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) Such problems usually mean that the stat or statfs record needs adjustments. You can find the stat record definition in rtl/bsd/ostypes.inc. statfs is in rtl/yourosdir/ptypes.inc And - getcwd (part of truename directory expansion) - opendir/readdir and friends. If something is wrong it sometimes shows up in ptrace. getcwd is a likely candidate since afaik that changed FreeBSD 5+ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MS SQL tests: fix for string settings invalid dates
Hi, try set PacketRecords=-1 in your TSQLQuery -Laco. Hello, I am struggeling with Lazarus and a connection to MSSQL server 2005. I get the data, but when i change a fieldvalue, then apply updates, I get the error 20019 like you listed: http://lists.freepascal.org/fpc-devel/2014-March/033494.html When ik hit OK the update is not applied, when i apply updates again immediately, then the updates apply correctly, but the connection or the query closes. Is there a solution? Thanks in advance, Jan-Pieter Stolk ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 16:02, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: Path /usr/lib/ not found Path /lib/ not found Free Pascal Compiler version 2.6.4 [2014/11/18] for x86_64 Copyright (c) 1993-2014 by Florian Klaempfl and others Fatal: No source file name in command line Fatal: Compilation aborted Error: bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) Such problems usually mean that the stat or statfs record needs adjustments. You can find the stat record definition in rtl/bsd/ostypes.inc. statfs is in rtl/yourosdir/ptypes.inc And - getcwd (part of truename directory expansion) - opendir/readdir and friends. If something is wrong it sometimes shows up in ptrace. getcwd is a likely candidate since afaik that changed FreeBSD 5+ Thanks, Marco. The TStatfs structure needed updating but it wasn't the cause of my issues. In case people are interested, I pushed my patches publicly: https://github.com/DragonFlyBSD/DeltaPorts/commit/117fa674817cc090a11b058d2f7bbf8e96b2e286 Don't worry about the patches to the generated makefiles. I had to do that based on the ports build order. I know those will get regenerated when they get incorporated into the dev branch. The patch that defines OLDBINUTILS to avoid assembly is not a permanent patch (Dragonfly has binutils 2.24 in base, not an issue). I'll check out your hints! John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] UTF8 RTL
Hi and much kudos for those who made the UTF8 RTL. GetCurrentDir, FindFirst, FileExist, TStringList, etc. all work well. :) ParamStr is not yet converted and only supports system codepage. I would like to help improving it. Has someone already started it? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
In our previous episode, Mattias Gaertner said:
Hi and much kudos for those who made the UTF8 RTL.
GetCurrentDir, FindFirst, FileExist, TStringList, etc. all work well. :)
ParamStr is not yet converted and only supports system codepage. I
would like to help improving it.
Has someone already started it?
In {$mode delphiunicode} it returns unicodestring.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On Tue, 18 Nov 2014 17:05:49 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
In our previous episode, Mattias Gaertner said:
Hi and much kudos for those who made the UTF8 RTL.
GetCurrentDir, FindFirst, FileExist, TStringList, etc. all work well. :)
ParamStr is not yet converted and only supports system codepage. I
would like to help improving it.
Has someone already started it?
In {$mode delphiunicode} it returns unicodestring.
A UnicodeString function would be sufficient.
But it seems this uses the argv PChar in system codepage.
Paramstr:=UnicodeString(Argv[Param])
It needs a unicode version of Argv.
For example a function like GetCommandLineW could be used to create a
ArgvW. Is this the right approach?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 16:14, John Marino wrote: On 11/18/2014 16:02, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: Path /usr/lib/ not found Path /lib/ not found Free Pascal Compiler version 2.6.4 [2014/11/18] for x86_64 Copyright (c) 1993-2014 by Florian Klaempfl and others Fatal: No source file name in command line Fatal: Compilation aborted Error: bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) Such problems usually mean that the stat or statfs record needs adjustments. You can find the stat record definition in rtl/bsd/ostypes.inc. statfs is in rtl/yourosdir/ptypes.inc And - getcwd (part of truename directory expansion) - opendir/readdir and friends. If something is wrong it sometimes shows up in ptrace. getcwd is a likely candidate since afaik that changed FreeBSD 5+ getcwd seems to work okay, I don't think that's a problem. This is where the problems start (cfileutl.pas, PathExists function): if allowcache then Result:=DirCache.DirectoryExists(hs) The DirCache.DirectoryExists function always returns false, even on valid paths. Still looking... John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 17:29, John Marino wrote: getcwd seems to work okay, I don't think that's a problem. This is where the problems start (cfileutl.pas, PathExists function): if allowcache then Result:=DirCache.DirectoryExists(hs) The DirCache.DirectoryExists function always returns false, even on valid paths. more importantly, if allowcache then Result:=DirCache.DirectoryExists(hs) else Result:=SysUtils.DirectoryExists(hs); SysUtils.DirectoryExists(hs) returns false too. so I'm back at rtl/unix/sysutils Function DirectoryExists (Const Directory : String) : Boolean; Var Info : Stat; begin DirectoryExists:=(fpstat(pointer(Directory),Info)=0) and fpS_ISDIR(Info.st_mode); end; John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 17:35, John Marino wrote: On 11/18/2014 17:29, John Marino wrote: getcwd seems to work okay, I don't think that's a problem. This is where the problems start (cfileutl.pas, PathExists function): if allowcache then Result:=DirCache.DirectoryExists(hs) The DirCache.DirectoryExists function always returns false, even on valid paths. more importantly, if allowcache then Result:=DirCache.DirectoryExists(hs) else Result:=SysUtils.DirectoryExists(hs); SysUtils.DirectoryExists(hs) returns false too. so I'm back at rtl/unix/sysutils Function DirectoryExists (Const Directory : String) : Boolean; Var Info : Stat; begin DirectoryExists:=(fpstat(pointer(Directory),Info)=0) and fpS_ISDIR(Info.st_mode); end; so DirectoryExists is only hit once -- on a file (/usr/local/etc/fpc.cfg). The DirCache.DirectoryExists function seems to be used instead for all directories, all the time. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
Am 18.11.2014 15:17 schrieb John Marino fpc-de...@marino.st: On 11/18/2014 14:43, Sven Barth wrote: Am 18.11.2014 13:46 schrieb John Marino fpc-de...@marino.st mailto:fpc-de...@marino.st: Hi guys, I've spent a couple of days porting FPC to DragonFly BSD with some success. [...] bin/fpc -i Free Pascal Compiler version 2.6.4 I can't help you much with your specific problen, but new targets should be added to the development version of FPC (in this case 2.7.1) and not the release. Afterall you'll need to port it sooner or later to that version anyway and especially in the current case (2.6.4 vs 2.7.1) quite some changes happened. Additionally we (core developers) only work with the development version anyway (the release compiler is basically only used for compiling trunk), so it will be easier for us to help you as well. It doesn't matter, I'll just have to do it twice. I have to patch the latest release -- otherwise we won't get it until the next release and subsequent import into ports. Plus it's more important to get FPC bootstrapped at this point. If you get it working with trunk fast enough then there might even be a remote chance that it will be on the next release, that will be branched soon (no guarantees though). I think the patches would apply to a dev branch without too much trouble though. In trunk there are quite some changes in the RTL, because of the introduction of codepage aware strings and RawByteString. I don't know in how far the specialized Posix RTLs are affected there (e.g. Linux, FreeBSD, etc. instead of the base directories bsd and unix), but you should be aware that it might involve a bit more work. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 17:42, John Marino wrote:
so DirectoryExists is only hit once -- on a file
(/usr/local/etc/fpc.cfg). The DirCache.DirectoryExists function seems
to be used instead for all directories, all the time.
If I delete {$define usedircache} from cfileutl.pas, then FPC can find
the directories and it is is able to build helloworld program natively.
So it seems the problem is limited to dircache.
I tried that last night but it didn't work, probably because of the bad
statfs type.
Maybe I'll go with dircache disabled for now just to see if I can
bootstrap it.
John
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 18/11/14 16:59, Mattias Gaertner wrote: Hi and much kudos for those who made the UTF8 RTL. Thanks, but there is no UTF-8 RTL. GetCurrentDir, FindFirst, FileExist, TStringList, etc. all work well. :) They are not guaranteed to use UTF-8, and you must not assume that they do (and TStringList in particular has not been changed in any way). See http://wiki.freepascal.org/FPC_Unicode_support for the details, and http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes for the list of RTL routines that currently work correctly with arbitrary code pages (or that at least should do so). ParamStr is not yet converted and only supports system codepage. I would like to help improving it. It will always only support system code page on Unix platforms, because everything that comes from the shell must be assumed to be in that code page. On Windows, it can be changed though. Has someone already started it? Not that I know. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On Tue, 18 Nov 2014 18:17:25 +0100 Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 18/11/14 16:59, Mattias Gaertner wrote: Hi and much kudos for those who made the UTF8 RTL. Thanks, but there is no UTF-8 RTL. That's what I thought too a week ago. FPC 2.7 made an old dream come true. :) GetCurrentDir, FindFirst, FileExist, TStringList, etc. all work well. :) They are not guaranteed to use UTF-8, and you must not assume that they do (and TStringList in particular has not been changed in any way). See http://wiki.freepascal.org/FPC_Unicode_support for the details, and http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes for the list of RTL routines that currently work correctly with arbitrary code pages (or that at least should do so). Yes, this page is great. I had to read it twice to understand the flexibility of the new RTL. ParamStr is not yet converted and only supports system codepage. I would like to help improving it. It will always only support system code page on Unix platforms, because everything that comes from the shell must be assumed to be in that code page. On Windows, it can be changed though. True. From Lazarus point of view most Unicode problems are on Windows. And now most of them are solved. FPC 2.7 will be a big improvement for Lazarus users. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
In our previous episode, John Marino said: If something is wrong it sometimes shows up in ptrace. getcwd is a likely candidate since afaik that changed FreeBSD 5+ getcwd seems to work okay, I don't think that's a problem. This is where the problems start (cfileutl.pas, PathExists function): if allowcache then Result:=DirCache.DirectoryExists(hs) The DirCache.DirectoryExists function always returns false, even on valid paths. Still looking... /me points to the fallback code of when fpgetcwd fails in unix/sysdir.inc: function do_getdir. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] CMem allocator memory alignment experiment
Hi, I think there are several issues with the cmem memory allocator. The main issue that it breaks the underlying malloc() memory alignment, by adding a four/eight byte size value to the start of each block for the sole reason to be able to throw Runtime Error 204 in case someone tries to free a block with the wrong size. At least on Linux, malloc() is documented to align to 64 bit on 32 bit and 128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that to 4 bytes and 8 bytes, respectively. This causes multiple performance and other issues, especially on processors which require stricter alignment (most ARM CPUs, but also x86 with SSE, etc). I created a cmem variant, which does 16 byte alignment of the returned memory blocks, just like FPC's own Heap Manager does: https://gist.github.com/chainq/6f69a7821cfa2503962f However, when I build FPC with this cmem16 allocator, the compiler explodes. Also it fails with other larger parts of code, and I'm unsure why, I spent a few days debugging, but I couldn't find the issue. Ideas? I wanted to contribute the code to the FPC SVN (after some cleanup) but because of these issues, I couldn't. Yes, the current alignment code is not the most optimal and wastes some memory, but at least it should work. Must be something trivial. Ideas, opinions, suggestions welcomed. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DF64 BSD -- FPC running natively but argument address mangling prevents bootstrap
On 11/18/2014 20:07, Marco van de Voort wrote: In our previous episode, John Marino said: If something is wrong it sometimes shows up in ptrace. getcwd is a likely candidate since afaik that changed FreeBSD 5+ getcwd seems to work okay, I don't think that's a problem. This is where the problems start (cfileutl.pas, PathExists function): if allowcache then Result:=DirCache.DirectoryExists(hs) The DirCache.DirectoryExists function always returns false, even on valid paths. Still looking... /me points to the fallback code of when fpgetcwd fails in unix/sysdir.inc: function do_getdir. Thanks, Marco. In the meantime, FPC can fully bootstrap when dircache is disabled. I completely the package and it can build itself and 81 other FPC packages successfully. http://muscles.dragonflybsd.org/bulk/bleeding-edge-potential/20141118_112715/ There were 9 failures but they could have been broken anyway or the quick-n-dirty replacement hack I did to make x86_64-dragonfly a valid OS for the makefile backfired. I definitely want to figure out why cachedir isn't working, but at least FPC seems functional without it. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
In our previous episode, Mattias Gaertner said: It will always only support system code page on Unix platforms, because everything that comes from the shell must be assumed to be in that code page. On Windows, it can be changed though. True. From Lazarus point of view most Unicode problems are on Windows. And now most of them are solved. FPC 2.7 will be a big improvement for Lazarus users. As Jonas said, not using utf8 on Windows. A TStringlist with a ansistrings in them passed to an RTL routine will be seen as ansi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 18/11/14 22:00, Marco van de Voort wrote: As Jonas said, not using utf8 on Windows. No, that's not what I said. There is no problem with using UTF-8 on Windows. A TStringlist with a ansistrings in them passed to an RTL routine will be seen as ansi. That is incorrect (although right now there are no RTL routines that accept stringlists and that are also codepage-aware). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
