From mazofeifer at gmail.com Fri Apr 1 05:36:02 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Fri, 1 Apr 2016 00:36:02 -0300 Subject: [fpc-pascal] Framework for Objects Serialization / Deserialization Message-ID: Hello list, Is there a fpc framework for or some standard to serialize / deserialize classes and other custom types? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Fri Apr 1 08:46:08 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 1 Apr 2016 08:46:08 +0200 (CEST) Subject: [fpc-pascal] Framework for Objects Serialization / Deserialization In-Reply-To: References: Message-ID: On Fri, 1 Apr 2016, Mazola Winstrol wrote: > Hello list, > > Is there a fpc framework for or some standard to serialize / deserialize > classes and other custom types? At least two units offer the base for such functionality: jsonrtti (fcl-json) and restbase (fcl-web) And obviously any TComponent can be streamed in the Delphi-native format. Michael. From ingemar at ragnemalm.se Fri Apr 1 13:44:56 2016 From: ingemar at ragnemalm.se (Ingemar Ragnemalm) Date: Fri, 1 Apr 2016 13:44:56 +0200 Subject: [fpc-pascal] Write Applet with FPC JVM Message-ID: <56FE5F38.5080901@ragnemalm.se> Hello, FPC list! Is there anyone who knows how to write a JVM applet with FPC? I have this minimal Java applet: import java.applet.*; import java.awt.*; public class HelloWorldApplet extends Applet { public void paint (Graphics g) { g.drawString ("Hello World", 25, 50); } } AFAIK this translates to: {$mode objfpc} // I try to make an Applet. How? program HelloWorldAppletProgram; uses jdk15; type HelloWorldApplet = class(JAApplet) public procedure paint(g: JAGraphics);override; end; procedure HelloWorldApplet.paint(g: JAGraphics); begin g.drawString('Hello World (FPC)',25,50); end; begin end. Compiles, produces HelloWorldAppletProgram.class and HelloWorldApplet.class. FPC compilation line: /usr/local/bin/ppcjvm -O2 -g HelloWorldAppletProgram.pas -XP -FD/usr/local/bin/ Java compilation line: /usr/bin/javac HelloWorldApplet.java Uses this HTML file: HelloWorldApplet
Should IMHO run with appletviewer HelloWorldApplet.html It compiles with both Java and FPC, but the FPC version doesn't run. Any ideas? Any obvious mistakes of mine? /Ingemar From mazofeifer at gmail.com Fri Apr 1 15:51:57 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Fri, 1 Apr 2016 10:51:57 -0300 Subject: [fpc-pascal] Framework for Objects Serialization / Deserialization In-Reply-To: References: Message-ID: 2016-04-01 3:46 GMT-03:00 Michael Van Canneyt : > > > On Fri, 1 Apr 2016, Mazola Winstrol wrote: > > Hello list, >> >> Is there a fpc framework for or some standard to serialize / deserialize >> classes and other custom types? >> > > At least two units offer the base for such functionality: > jsonrtti (fcl-json) and restbase (fcl-web) > > And obviously any TComponent can be streamed in the Delphi-native format. > > Thanks for your reply Michael. I can't change the actual hierarchical structure of my classes so i can't use TComponent. I can serialize custom types (e.g records) using fcl-json? Delphi do have an intersting way to do with serialization: they have some standard classes (TTypeMashaller, TConverter). If one wants to serialize to a new format (e.g binary format), one can extended those base classes and implement such serialization. Would be interesting if we create an infrastructure like that. http://docwiki.embarcadero.com/RADStudio/Seattle/en/Serializing_User_Objects -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Fri Apr 1 17:47:30 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Fri, 1 Apr 2016 11:47:30 -0400 Subject: [fpc-pascal] Framework for Objects Serialization / Deserialization In-Reply-To: References: Message-ID: On Fri, Apr 1, 2016 at 9:51 AM, Mazola Winstrol wrote: > I can't change the actual hierarchical structure of my classes so i can't > use TComponent. > > Delphi do have an intersting way to do with serialization: they have some > standard classes (TTypeMashaller, TConverter). If one wants to serialize to > a new format (e.g binary format), one can extended those base classes and > implement such serialization. Would be interesting if we create an > infrastructure like that. > That might be handy. In order to support Xcode project file (.pbx) structures I had to create a stand-alone (de)serializers from scratch. It's RTTI dependent, but is not based of TComponent. It would also not fail, if encounters unrecognized property, instead would keep it for the later serialization ( .pbx is undocumented and could change without notice ) thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From hartnegg at gmx.de Fri Apr 1 18:17:33 2016 From: hartnegg at gmx.de (Klaus Hartnegg) Date: Fri, 1 Apr 2016 18:17:33 +0200 Subject: [fpc-pascal] fpSelect fails with UDP sockets? Message-ID: <56FE9F1D.5020101@gmx.de> Hello, Does fpSelect not work with UDP sockets? It always returns 0, which means it did not see a packet. Is anything wrong with this code? Uses UnixType, BaseUnix, Sockets; procedure abort (reason:string); begin writeln (reason); halt; end; var sock: cint; adr : {TInet}SockAddr; rc : cint; FDS : Tfdset; begin sock := fpSocket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); if sock = -1 then abort ('Error from fpSocket'); adr.sin_family := AF_INET; adr.sin_addr.s_addr := INADDR_ANY; adr.sin_port := htons(53); rc := fpBind (sock, @adr, sizeof(adr)); if rc <> 0 then abort ('Error from fpBind'); Writeln ('send udp packet in less than 5 seconds'); Fpfd_zero(FDS); FpFd_set (sock,FDS); rc := fpSelect (1, at FDS,nil,nil,5000); if rc = -1 then abort ('Error from fpSelect'); if rc > 0 then Writeln ('Thank you !') else Writeln ('Too late !'); end. From markMLl.fpc-pascal at telemetry.co.uk Fri Apr 1 19:10:09 2016 From: markMLl.fpc-pascal at telemetry.co.uk (Mark Morgan Lloyd) Date: Fri, 01 Apr 2016 17:10:09 +0000 Subject: [fpc-pascal] fpSelect fails with UDP sockets? In-Reply-To: <56FE9F1D.5020101@gmx.de> References: <56FE9F1D.5020101@gmx.de> Message-ID: Klaus Hartnegg wrote: > Hello, > > Does fpSelect not work with UDP sockets? > It always returns 0, which means it did not see a packet. > Is anything wrong with this code? I don't have time to play with that right now, but test it with a port > 1024 before trying a lower-numbered one. What OS are you running on- the select() semantics vary slightly on Linux compared with e.g. Solaris, and I don't know where e.g. BSD stands on this. > Uses > UnixType, BaseUnix, Sockets; > > procedure abort (reason:string); > begin > writeln (reason); > halt; > end; > > var > sock: cint; > adr : {TInet}SockAddr; > rc : cint; > FDS : Tfdset; > > begin > sock := fpSocket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); > if sock = -1 then > abort ('Error from fpSocket'); > > adr.sin_family := AF_INET; > adr.sin_addr.s_addr := INADDR_ANY; > adr.sin_port := htons(53); > rc := fpBind (sock, @adr, sizeof(adr)); > if rc <> 0 then > abort ('Error from fpBind'); > > Writeln ('send udp packet in less than 5 seconds'); > Fpfd_zero(FDS); > FpFd_set (sock,FDS); > rc := fpSelect (1, at FDS,nil,nil,5000); > if rc = -1 then > abort ('Error from fpSelect'); > if rc > 0 then > Writeln ('Thank you !') > else > Writeln ('Too late !'); > end. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From dibo20 at wp.pl Sat Apr 2 00:02:29 2016 From: dibo20 at wp.pl (Krzysztof) Date: Sat, 2 Apr 2016 00:02:29 +0200 Subject: [fpc-pascal] FPC 3.0.0 and constref default param In-Reply-To: References: Message-ID: Anyone? :) From leledumbo_cool at yahoo.co.id Sat Apr 2 12:39:41 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Sat, 2 Apr 2016 03:39:41 -0700 (MST) Subject: [fpc-pascal] Write Applet with FPC JVM In-Reply-To: <56FE5F38.5080901@ragnemalm.se> References: <56FE5F38.5080901@ragnemalm.se> Message-ID: <1459593581645-5724733.post@n5.nabble.com> > It compiles with both Java and FPC, but the FPC version doesn't run. Works fine here: fpc-helloworld-applet.png > Any ideas? Any obvious mistakes of mine? I change your program to a unit, though I don't think that matters as long as HelloWorldApplet.class is generated. Then I modify your applet tag by removing archive attribute as it's not in a .jar but a standalone .class. That's it. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Write-Applet-with-FPC-JVM-tp5724727p5724733.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From bo.berglund at gmail.com Sat Apr 2 20:29:02 2016 From: bo.berglund at gmail.com (Bo Berglund) Date: Sat, 02 Apr 2016 20:29:02 +0200 Subject: [fpc-pascal] Postgresql interface bronken for Raspberry pi model 1b References: <20160328130203.BE35D73037@toad.stack.nl> <20160328130203.BE35D73037-qrYVWrDT6MbgjWiVKyS68A@public.gmane.org> <56F931FC.1010502@gmail.com> Message-ID: <1l30gb9nr73nevaclhve3rq667aq3u7cmv@4ax.com> On Mon, 28 Mar 2016 15:30:36 +0200, Björn Lundin wrote: >That speaks for trying to compile 3.0.0. >The pi is on wheezy, so there is no .deb package >for it. I made a script for installing FPV 3.0.0 and Lazarus 1.6 release on an RPi. http://blog.boberglund.com/install_laz_pi.sh You can have a look at it and strip off Lazarus if you like. It is not very difficult to build FPC from sources really... One caveat with wheezy and some Pi versions is that you should up swap to 1000 to not get caught in the linker. Swap expansion is found in sudo raspi-config. -- Bo Berglund Developer in Sweden From bo.berglund at gmail.com Sat Apr 2 20:33:46 2016 From: bo.berglund at gmail.com (Bo Berglund) Date: Sat, 02 Apr 2016 20:33:46 +0200 Subject: [fpc-pascal] SVN FPC tag content? Message-ID: <0140gbtncch5b5thhiksbd1smjm01n9i0f@4ax.com> I am wondering if the FPC release tag for 3.0.0 is ever updated with the bugfixes or if it is static. I.e. if I want to get the bugfixes into my FPC do I have to update to a new tag then? Or is it OK just to make a svn up in the source dir? -- Bo Berglund Developer in Sweden From leledumbo_cool at yahoo.co.id Sat Apr 2 20:39:50 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Sat, 2 Apr 2016 11:39:50 -0700 (MST) Subject: [fpc-pascal] SVN FPC tag content? In-Reply-To: <0140gbtncch5b5thhiksbd1smjm01n9i0f@4ax.com> References: <0140gbtncch5b5thhiksbd1smjm01n9i0f@4ax.com> Message-ID: <1459622390089-5724736.post@n5.nabble.com> > I am wondering if the FPC release tag for 3.0.0 is ever updated with > the bugfixes or if it is static. > I.e. if I want to get the bugfixes into my FPC do I have to update to > a new tag then? > Or is it OK just to make a svn up in the source dir? It seems to be static, otherwise branches/fixes_3_0 will be useless. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/SVN-FPC-tag-content-tp5724735p5724736.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From mailinglists at geldenhuys.co.uk Sat Apr 2 20:53:39 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sat, 2 Apr 2016 19:53:39 +0100 Subject: [fpc-pascal] SVN FPC tag content? In-Reply-To: <0140gbtncch5b5thhiksbd1smjm01n9i0f@4ax.com> References: <0140gbtncch5b5thhiksbd1smjm01n9i0f@4ax.com> Message-ID: <57001533.8040008@geldenhuys.co.uk> On 2016-04-02 19:33, Bo Berglund wrote: > I am wondering if the FPC release tag for 3.0.0 is ever updated with > the bugfixes or if it is static. As far as I'm concerned, tags should *never* move, otherwise, what's the point of tagging a commit. That should apply to SubVersion and Git repos. If you want to track minor bug fixes after a release, which to that release's bug-fix branch... regarding FPC that is normally named "_fixes". Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From bo.berglund at gmail.com Sat Apr 2 21:08:45 2016 From: bo.berglund at gmail.com (Bo Berglund) Date: Sat, 02 Apr 2016 21:08:45 +0200 Subject: [fpc-pascal] SVN FPC tag content? References: <0140gbtncch5b5thhiksbd1smjm01n9i0f@4ax.com> <0140gbtncch5b5thhiksbd1smjm01n9i0f-e09XROE/p8c@public.gmane.org> <57001533.8040008@geldenhuys.co.uk> Message-ID: On Sat, 2 Apr 2016 19:53:39 +0100, Graeme Geldenhuys wrote: >On 2016-04-02 19:33, Bo Berglund wrote: >> I am wondering if the FPC release tag for 3.0.0 is ever updated with >> the bugfixes or if it is static. > >As far as I'm concerned, tags should *never* move, otherwise, what's the >point of tagging a commit. That should apply to SubVersion and Git >repos. If you want to track minor bug fixes after a release, which to >that release's bug-fix branch... regarding FPC that is normally named >"_fixes". I hade a look here: http://svn.freepascal.org/svn/fpc/branches/fixes_3_0/ there are sources And here: http://svn.freepascal.org/svn/fpc/tags/release_3_0_0/ same here So there seems not to be any release_3_0_1 or similar. Is the accepted convention to check out the branches/fixes_3_0/ and regularly svn up on it and then make? trunk/ seems to be work in progress and might be unstable, right? -- Bo Berglund Developer in Sweden From marcov at stack.nl Sat Apr 2 21:52:29 2016 From: marcov at stack.nl (Marco van de Voort) Date: Sat, 2 Apr 2016 21:52:29 +0200 (CEST) Subject: [fpc-pascal] SVN FPC tag content? In-Reply-To: Message-ID: <20160402195229.B759973036@toad.stack.nl> In our previous episode, Bo Berglund said: > >that release's bug-fix branch... regarding FPC that is normally named > >"_fixes". > > I hade a look here: > http://svn.freepascal.org/svn/fpc/branches/fixes_3_0/ > there are sources That is the 3.0 series branch from which releases are branched. > And here: > http://svn.freepascal.org/svn/fpc/tags/release_3_0_0/ > same here That is the 3.0(.0) release. > So there seems not to be any release_3_0_1 or similar. The fixes_3_0 has as moving version "3.0.1" till 3.0.2 is released, and after it will be 3.0.3 and so on. > Is the accepted convention to check out the branches/fixes_3_0/ and > regularly svn up on it and then make? Yes. Though the activity is not continous. It has had quite some updates in the last few days though. > trunk/ seems to be work in progress and might be unstable, right? Well, lately that instability is relative, it is generally usable, but fixes_3_0 is a bit more conservative with respect to breaking interfaces and compatibility. From ingemar at ragnemalm.se Sun Apr 3 13:20:47 2016 From: ingemar at ragnemalm.se (Ingemar Ragnemalm) Date: Sun, 3 Apr 2016 13:20:47 +0200 Subject: [fpc-pascal] Write Applet with FPC JVM In-Reply-To: References: Message-ID: <5700FC8F.4000102@ragnemalm.se> > Message: 1 > Date: Sat, 2 Apr 2016 03:39:41 -0700 (MST) > From: leledumbo > To: fpc-pascal at lists.freepascal.org > Subject: Re: [fpc-pascal] Write Applet with FPC JVM > Message-ID: <1459593581645-5724733.post at n5.nabble.com> > Content-Type: text/plain; charset=us-ascii > >> It compiles with both Java and FPC, but the FPC version doesn't run. > Works fine here: > fpc-helloworld-applet.png > > >> Any ideas? Any obvious mistakes of mine? > I change your program to a unit, though I don't think that matters as long > as HelloWorldApplet.class is generated. Then I modify your applet tag by > removing archive attribute as it's not in a .jar but a standalone .class. > That's it. Great! I tried and indeed, compiling a unit did it! Editing the HTML file didn't seem to matter though. /Ingemar From b.f.lundin at gmail.com Sun Apr 3 17:37:54 2016 From: b.f.lundin at gmail.com (=?UTF-8?Q?Bj=c3=b6rn_Lundin?=) Date: Sun, 3 Apr 2016 17:37:54 +0200 Subject: [fpc-pascal] Postgresql interface bronken for Raspberry pi model 1b In-Reply-To: <1l30gb9nr73nevaclhve3rq667aq3u7cmv@4ax.com> References: <20160328130203.BE35D73037@toad.stack.nl> <20160328130203.BE35D73037-qrYVWrDT6MbgjWiVKyS68A@public.gmane.org> <56F931FC.1010502@gmail.com> <1l30gb9nr73nevaclhve3rq667aq3u7cmv@4ax.com> Message-ID: <570138D2.2050709@gmail.com> On 2016-04-02 20:29, Bo Berglund wrote: > On Mon, 28 Mar 2016 15:30:36 +0200, Björn Lundin > wrote: > >> That speaks for trying to compile 3.0.0. >> The pi is on wheezy, so there is no .deb package >> for it. > > I made a script for installing FPV 3.0.0 and Lazarus 1.6 release on an > RPi. > http://blog.boberglund.com/install_laz_pi.sh > > You can have a look at it and strip off Lazarus if you like. > It is not very difficult to build FPC from sources really... > One caveat with wheezy and some Pi versions is that you should up swap > to 1000 to not get caught in the linker. > Swap expansion is found in sudo raspi-config. Yes, I saw that link somewhere else. I got 2 pi:s, one original B with 256 mb and one later B model with 512 mb RAM. I downloaded and ran it 'as is'. The pi:s do have 1Bb each of swap, but both froze during compilation. Both are on rasbian wheezy. I'll strip away lazarus as you say and try again. If I don't get it to work, I'll look into cross compiling from win32 to the pi -- Björn From hartnegg at gmx.de Sun Apr 3 18:32:50 2016 From: hartnegg at gmx.de (Klaus Hartnegg) Date: Sun, 3 Apr 2016 18:32:50 +0200 Subject: [fpc-pascal] SOLVED fpSelect fails with UDP sockets? In-Reply-To: <56FE9F1D.5020101@gmx.de> References: <56FE9F1D.5020101@gmx.de> Message-ID: <570145B2.3080307@gmx.de> It works with rc := fpSelect (sock+1, at FDS,nil,nil,5000); I did not understand the description of the first argument in the docs, so I used the value from the sample, this was not a good idea. For reference here is the source that works: Uses UnixType, BaseUnix, Sockets; procedure abort (reason:string); begin writeln (reason); halt; end; var sock: cint; ladr : SockAddr; radr : SockAddr; adrlen: tSockLen; msg : string[255]; FDS : Tfdset; rc : cint; begin sock := fpSocket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); if sock = -1 then abort ('Error from fpSocket'); ladr.sin_family := AF_INET; ladr.sin_addr.s_addr := INADDR_ANY; ladr.sin_port := htons(2000); rc := fpBind (sock, @ladr, sizeof(ladr)); if rc <> 0 then abort ('Error from fpBind'); adrlen := sizeof(radr); Fpfd_zero (FDS); FpFd_set (sock,FDS); rc := fpSelect (sock+1, at FDS,nil,nil,5000); writeln (rc); if rc = -1 then abort ('Error from fpSelect'); if rc = 0 then abort ('timeout'); rc := fpRecvFrom (sock, @msg[1], 255, 0 {flags}, @radr, @adrlen); if rc = -1 then abort ('Error from FpRecv'); if rc > 255 then rc := 255; msg[0] := chr(rc); writeln (msg); end. And this is the sender: Uses UnixType, BaseUnix, Sockets; procedure abort (reason:string); begin writeln (reason); halt; end; var sock: cint; sadr: {TInet}SockAddr; dadr: {TInet}SockAddr; adrlen: tSockLen; msg : string; rc : cint; begin sock := fpSocket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); if sock = -1 then abort ('Error from fpSocket'); sadr.sin_family := AF_INET; sadr.sin_addr.s_addr := INADDR_ANY; sadr.sin_port := 0; { auto-select } rc := fpBind (sock, @sadr, sizeof(sadr)); if rc <> 0 then abort ('Error from fpBind'); dadr.sin_family := AF_INET; dadr.sin_addr.s_bytes[1] := 127; dadr.sin_addr.s_bytes[2] := 0; dadr.sin_addr.s_bytes[2] := 0; dadr.sin_addr.s_bytes[2] := 1; dadr.sin_port := htons(2000); adrlen := sizeof(dadr); msg := 'hello, world!'; rc := fpSendTo (sock, @msg[1], length(msg), 0 {flags}, @dadr, adrlen); if rc = length(msg) then writeln ('ok'); end. From hartnegg at gmx.de Sun Apr 3 18:44:35 2016 From: hartnegg at gmx.de (Klaus Hartnegg) Date: Sun, 3 Apr 2016 18:44:35 +0200 Subject: [fpc-pascal] SOLVED fpSelect fails with UDP sockets? In-Reply-To: <570145B2.3080307@gmx.de> References: <56FE9F1D.5020101@gmx.de> <570145B2.3080307@gmx.de> Message-ID: <57014873.3020609@gmx.de> Am 03.04.2016 um 18:32 schrieb Klaus Hartnegg: > dadr.sin_addr.s_bytes[1] := 127; > dadr.sin_addr.s_bytes[2] := 0; > dadr.sin_addr.s_bytes[2] := 0; > dadr.sin_addr.s_bytes[2] := 1; The array index numbers are of course garbage (from incomplete copy&paste editing), but somehow it worked nevertheless. Should have been dadr.sin_addr.s_bytes[1] := 127; dadr.sin_addr.s_bytes[2] := 0; dadr.sin_addr.s_bytes[3] := 0; dadr.sin_addr.s_bytes[4] := 1; Loopback appears to catch the whole loopback network, not just that single address. From wkitty42 at windstream.net Sun Apr 3 18:49:22 2016 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Sun, 3 Apr 2016 12:49:22 -0400 Subject: [fpc-pascal] SOLVED fpSelect fails with UDP sockets? In-Reply-To: <570145B2.3080307@gmx.de> References: <56FE9F1D.5020101@gmx.de> <570145B2.3080307@gmx.de> Message-ID: <57014992.3090901@windstream.net> On 04/03/2016 12:32 PM, Klaus Hartnegg wrote: > dadr.sin_family := AF_INET; > dadr.sin_addr.s_bytes[1] := 127; > dadr.sin_addr.s_bytes[2] := 0; > dadr.sin_addr.s_bytes[2] := 0; > dadr.sin_addr.s_bytes[2] := 1; shouldn't this be dadr.sin_addr.s_bytes[1] := 127; dadr.sin_addr.s_bytes[2] := 0; dadr.sin_addr.s_bytes[3] := 0; dadr.sin_addr.s_bytes[4] := 1; NOTE: i've not done any research to see what dadr.sin_addr.s_bytes is but i assume that it is an array of bytes to contain each of the IP address parts... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. From markMLl.fpc-pascal at telemetry.co.uk Sun Apr 3 22:44:56 2016 From: markMLl.fpc-pascal at telemetry.co.uk (Mark Morgan Lloyd) Date: Sun, 03 Apr 2016 20:44:56 +0000 Subject: [fpc-pascal] SOLVED fpSelect fails with UDP sockets? In-Reply-To: <57014992.3090901@windstream.net> References: <56FE9F1D.5020101@gmx.de> <570145B2.3080307@gmx.de> <57014992.3090901@windstream.net> Message-ID: wkitty42 at windstream.net wrote: > NOTE: i've not done any research to see what dadr.sin_addr.s_bytes is > but i assume that it is an array of bytes to contain each of the IP > address parts... It's usually an untagged variant record so you can also do something like target.s_addr:= HToNL($7F000001); Just /don't/ assume you can do maths with it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From tobiasgiesen at gmail.com Mon Apr 4 10:08:14 2016 From: tobiasgiesen at gmail.com (Tobias Giesen) Date: Mon, 04 Apr 2016 10:08:14 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion Message-ID: <20160404100813.818A.7A733E13@gmail.com> Hello, my application uses the AnsiString type to store UTF-8 data. That was totally fine. Now in FPC 3, automatic conversions cause data loss. I get question marks replacing Chinese characters, for example. I do not fully understand at which points these conversions are done. The FPC 3 Unicode documentation says something about "passing it to a RTL routine". What about this code: var a,b:Ansistring; begin a:=Utf8Encode(AWideString); b:=Copy(a,1,10); end; Is "Copy" an RTL routine? Is this OK or not? Best for me would be to be able to turn the conversions off completely. Is that possible? Cheers, Tobias From tobiasgiesen at gmail.com Mon Apr 4 10:18:18 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 10:18:18 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? Message-ID: <20160404101817.818D.B7062D51@tgtools.de> Hello, disallowing "AnsiString" code for UTF-8 is a huge regression. I use TStringList for UTF-8 strings. This is no longer possible, because automatic conversions cause question marks and data loss. I also use a large amount of third-party libraries that use the AnsiString data type for UTF-8. I really want to use FPC 3 due to other things, but this is a deal breaker. Why not add a simple switch or even a run-time Boolean global variable to turn off codepage conversions? It behaves differently from Delphi too. Cheers, Tobias From nc-gaertnma at netcologne.de Mon Apr 4 10:30:59 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 4 Apr 2016 10:30:59 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404101817.818D.B7062D51@tgtools.de> References: <20160404101817.818D.B7062D51@tgtools.de> Message-ID: <20160404103059.286dab90@limapholos.matflo.wg> On Mon, 04 Apr 2016 10:18:18 +0200 tobiasgiesen at gmail.com wrote: > Hello, > > disallowing "AnsiString" code for UTF-8 is a huge regression. > > I use TStringList for UTF-8 strings. This is no longer possible, because > automatic conversions cause question marks and data loss. Lazarus uses TStringList with UTF-8 all over the place. Please post a complete example demonstrating the problem. Mattias From michael at freepascal.org Mon Apr 4 10:32:58 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 10:32:58 +0200 (CEST) Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404100813.818A.7A733E13@gmail.com> References: <20160404100813.818A.7A733E13@gmail.com> Message-ID: On Mon, 4 Apr 2016, Tobias Giesen wrote: > Hello, > > my application uses the AnsiString type to store UTF-8 data. That was > totally fine. Now in FPC 3, automatic conversions cause data loss. I > get question marks replacing Chinese characters, for example. > > I do not fully understand at which points these conversions are done. > The FPC 3 Unicode documentation says something about "passing it to a > RTL routine". > > What about this code: > var a,b:Ansistring; > begin > a:=Utf8Encode(AWideString); > b:=Copy(a,1,10); > end; > > Is "Copy" an RTL routine? Is this OK or not? > > Best for me would be to be able to turn the conversions off completely. You cannot, but you can set DefaultSystemCodePage to CP_UTF8. Then no conversions will be done for all ansistrings that contain UTF8. Michael. From michael at freepascal.org Mon Apr 4 10:34:17 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 10:34:17 +0200 (CEST) Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404101817.818D.B7062D51@tgtools.de> References: <20160404101817.818D.B7062D51@tgtools.de> Message-ID: On Mon, 4 Apr 2016, tobiasgiesen at gmail.com wrote: > Hello, > > disallowing "AnsiString" code for UTF-8 is a huge regression. > > I use TStringList for UTF-8 strings. This is no longer possible, because > automatic conversions cause question marks and data loss. Same answer as in my other mail. Set DefaultSystemCodePage to CP_UTF8. > > I also use a large amount of third-party libraries that use the AnsiString > data type for UTF-8. > > I really want to use FPC 3 due to other things, but this is a deal > breaker. Why not add a simple switch or even a run-time Boolean global > variable to turn off codepage conversions? > > It behaves differently from Delphi too. This depends on the version of Delphi :) Michael. From tobiasgiesen at gmail.com Mon Apr 4 10:36:29 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 10:36:29 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: References: <20160404100813.818A.7A733E13@gmail.com> Message-ID: <20160404103628.8197.B7062D51@tgtools.de> > You cannot, but you can set DefaultSystemCodePage to CP_UTF8. > Then no conversions will be done for all ansistrings that contain UTF8. Fantastic. Many thanks. That fixes my problem entirely (I think). Sorry, I was not able to come to that conclusion from the existing docs. Cheers, Tobias From tobiasgiesen at gmail.com Mon Apr 4 10:43:42 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 10:43:42 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404103059.286dab90@limapholos.matflo.wg> References: <20160404101817.818D.B7062D51@tgtools.de> <20160404103059.286dab90@limapholos.matflo.wg> Message-ID: <20160404104341.819A.B7062D51@tgtools.de> > > I use TStringList for UTF-8 strings. This is no longer possible, because > > automatic conversions cause question marks and data loss. > > Lazarus uses TStringList with UTF-8 all over the place. > > Please post a complete example demonstrating the problem. Sorry - this was only theoretical, because of the Backward compatibility section on the FPC Unicode Support page. It says that a "defined way" to use strings is "you do not store data in an ansistring that has been encoded using something else than the system's default code page, and subsequently pass this string as-is to an FPC RTL routine". That would mean I cannot use TStringList for UTF-8. The paragraph is misleading, really. Very theoretical. What you really need to tell people is something like this: "Unicode aware Pascal code needs to set DefaultSystemCodePage to CP_UTF8". I am sorry but I was really shocked this morning when I saw the question marks :) Cheers, Tobias From mailinglists at geldenhuys.co.uk Mon Apr 4 10:49:20 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 09:49:20 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404104341.819A.B7062D51@tgtools.de> References: <20160404101817.818D.B7062D51@tgtools.de> <20160404103059.286dab90@limapholos.matflo.wg> <20160404104341.819A.B7062D51@tgtools.de> Message-ID: <57022A90.3070002@geldenhuys.co.uk> On 2016-04-04 09:43, tobiasgiesen at gmail.com wrote: > Very theoretical. What you really need to tell > people is something like this: That please update the wiki - it is user editable. Even a seasoned developers as myself still needs to get my head around all this FPC Unicode stuff. So any information and tips on the wiki would be greatly appreciated. I haven't moved to FPC 3.0 yet, but when I do, I too will have lots of testing to do in my own code. I don't use LCL, but but do currently store UTF-8 text inside AnsiString's for years (on all platforms). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From tobiasgiesen at gmail.com Mon Apr 4 10:59:44 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 10:59:44 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <57022A90.3070002@geldenhuys.co.uk> References: <20160404104341.819A.B7062D51@tgtools.de> <57022A90.3070002@geldenhuys.co.uk> Message-ID: <20160404105943.819D.B7062D51@tgtools.de> > That please update the wiki - it is user editable. Done: http://wiki.freepascal.org/FPC_Unicode_support#Backward_compatibility I hope this is correct. Cheers, Tobias From jonas.maebe at elis.ugent.be Mon Apr 4 11:21:42 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Mon, 04 Apr 2016 11:21:42 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404105943.819D.B7062D51@tgtools.de> References: <20160404104341.819A.B7062D51@tgtools.de> <57022A90.3070002@geldenhuys.co.uk> <20160404105943.819D.B7062D51@tgtools.de> Message-ID: <20160404112142.Horde.qdqlekisJlFXAjImKc_xG9A@mail.elis.ugent.be> tobiasgiesen wrote on Mon, 04 Apr 2016: >> That please update the wiki - it is user editable. > > Done: > http://wiki.freepascal.org/FPC_Unicode_support#Backward_compatibility > > I hope this is correct. It is incorrect in the sense that there is nothing utf8-specific about the way your code (ab)used ansistrings. I will fix it, since that page is more or less part of the official FPC documentation (since it's linked from the FPC 3.0 release notes). Jonas From juha.manninen62 at gmail.com Mon Apr 4 11:21:45 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 4 Apr 2016 12:21:45 +0300 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404103628.8197.B7062D51@tgtools.de> References: <20160404100813.818A.7A733E13@gmail.com> <20160404103628.8197.B7062D51@tgtools.de> Message-ID: On Mon, Apr 4, 2016 at 11:36 AM, wrote: > Sorry, I was not able to come to that conclusion from the existing docs. Your question was not about Lazarus but maybe you should read this: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus It works also without LCL. The bottom line is: remove all explicit conversion functions. Juha From juha.manninen62 at gmail.com Mon Apr 4 11:27:30 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 4 Apr 2016 12:27:30 +0300 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404101817.818D.B7062D51@tgtools.de> References: <20160404101817.818D.B7062D51@tgtools.de> Message-ID: On Mon, Apr 4, 2016 at 11:18 AM, wrote: > I use TStringList for UTF-8 strings. This is no longer possible, because > automatic conversions cause question marks and data loss. You are completely lost with this issue. The automatic conversion of encodings is a big step forward. Just use the new UTF-8 mode provided by Lazarus and remove all explicit conversion functions. http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus Juha From nc-gaertnma at netcologne.de Mon Apr 4 11:31:29 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 4 Apr 2016 11:31:29 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: References: <20160404100813.818A.7A733E13@gmail.com> Message-ID: <20160404113129.57f54d94@limapholos.matflo.wg> On Mon, 4 Apr 2016 10:32:58 +0200 (CEST) Michael Van Canneyt wrote: >[...] > You cannot, but you can set DefaultSystemCodePage to CP_UTF8. I think it is important to note how to do this properly: SetMultiByteConversionCodePage(CP_UTF8); SetMultiByteRTLFileSystemCodePage(CP_UTF8); You should add these lines in an early initialization section. The beginning of your program might be too late. > Then no conversions will be done for all ansistrings that contain UTF8. And this really means AnsiString, not AnsiString(something). Mattias From michael at freepascal.org Mon Apr 4 11:35:53 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 11:35:53 +0200 (CEST) Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404113129.57f54d94@limapholos.matflo.wg> References: <20160404100813.818A.7A733E13@gmail.com> <20160404113129.57f54d94@limapholos.matflo.wg> Message-ID: On Mon, 4 Apr 2016, Mattias Gaertner wrote: > On Mon, 4 Apr 2016 10:32:58 +0200 (CEST) > Michael Van Canneyt wrote: > >> [...] >> You cannot, but you can set DefaultSystemCodePage to CP_UTF8. > > I think it is important to note how to do this properly: > > SetMultiByteConversionCodePage(CP_UTF8); > SetMultiByteRTLFileSystemCodePage(CP_UTF8); > > You should add these lines in an early initialization section. The > beginning of your program might be too late. > >> Then no conversions will be done for all ansistrings that contain UTF8. > > And this really means AnsiString, not AnsiString(something). The latter cannot contain UTF8 unless you do some really nasty tricks... :-) Michael From tobiasgiesen at gmail.com Mon Apr 4 11:39:08 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 11:39:08 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: References: <20160404103628.8197.B7062D51@tgtools.de> Message-ID: <20160404113907.81B0.B7062D51@tgtools.de> > Your question was not about Lazarus but maybe you should read this: > http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus Very interesting, but apparently there is some wrong info. It says "On Linux and Mac OS X UTF-8 is typically the system codepage, so the RTL uses here by default CP_UTF8." Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001. Should I fix this bit on the documentation page? Apparently the LCL assumes that FCL sets it to UTF-8, but it does not. I think the LCL should explicitly set it to CP_UTF8 on Mac and Linux. Cheers, Tobias From michael at freepascal.org Mon Apr 4 11:43:46 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 11:43:46 +0200 (CEST) Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404113907.81B0.B7062D51@tgtools.de> References: <20160404103628.8197.B7062D51@tgtools.de> <20160404113907.81B0.B7062D51@tgtools.de> Message-ID: On Mon, 4 Apr 2016, tobiasgiesen at gmail.com wrote: >> Your question was not about Lazarus but maybe you should read this: >> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus > > Very interesting, but apparently there is some wrong info. > > It says "On Linux and Mac OS X UTF-8 is typically the system codepage, so the RTL uses > here by default CP_UTF8." > > Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001. > > Should I fix this bit on the documentation page? No. It says 'typically'. That doesn't necessarily mean it is so, but is mostly correct. > > Apparently the LCL assumes that FCL sets it to UTF-8, but it does not. > > I think the LCL should explicitly set it to CP_UTF8 on Mac and Linux. No, that would be wrong. it normally is CP_UTF8 on linux. But it can differ. I know people that still use ISO-8895 (or something similar). Only the programmer can know what is correct. Michael. From tobiasgiesen at gmail.com Mon Apr 4 11:47:23 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 11:47:23 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: References: <20160404113907.81B0.B7062D51@tgtools.de> Message-ID: <20160404114722.81B3.B7062D51@tgtools.de> > > > On Mon, 4 Apr 2016, tobiasgiesen at gmail.com wrote: > > >> Your question was not about Lazarus but maybe you should read this: > >> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus > > > > Very interesting, but apparently there is some wrong info. > > > > It says "On Linux and Mac OS X UTF-8 is typically the system codepage, so the RTL uses > > here by default CP_UTF8." > > > > Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001. > > > > Should I fix this bit on the documentation page? > > No. It says 'typically'. That's the first part of the sentence. The second part says: "the RTL uses here by default CP_UTF8." That is wrong. It does not (at least not on Mac). This must be fixed. Cheers, Tobias From nc-gaertnma at netcologne.de Mon Apr 4 11:48:51 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 4 Apr 2016 11:48:51 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: References: <20160404100813.818A.7A733E13@gmail.com> <20160404113129.57f54d94@limapholos.matflo.wg> Message-ID: <20160404114851.4ff6a8bd@limapholos.matflo.wg> On Mon, 4 Apr 2016 11:35:53 +0200 (CEST) Michael Van Canneyt wrote: >[...] > >> Then no conversions will be done for all ansistrings that contain UTF8. > > > > And this really means AnsiString, not AnsiString(something). > > The latter cannot contain UTF8 unless you do some really nasty tricks... :-) UTF8String is type AnsiString(CP_UTF8) and if you mix that with AnsiString the compiler adds conversions code, because at compile time CP_ACP is not UTF-8. These kind of traps confuse people. Mattias From michael at freepascal.org Mon Apr 4 11:49:57 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 11:49:57 +0200 (CEST) Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404114722.81B3.B7062D51@tgtools.de> References: <20160404113907.81B0.B7062D51@tgtools.de> <20160404114722.81B3.B7062D51@tgtools.de> Message-ID: On Mon, 4 Apr 2016, tobiasgiesen at gmail.com wrote: >> >> >> On Mon, 4 Apr 2016, tobiasgiesen at gmail.com wrote: >> >>>> Your question was not about Lazarus but maybe you should read this: >>>> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus >>> >>> Very interesting, but apparently there is some wrong info. >>> >>> It says "On Linux and Mac OS X UTF-8 is typically the system codepage, so the RTL uses >>> here by default CP_UTF8." >>> >>> Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001. >>> >>> Should I fix this bit on the documentation page? >> >> No. It says 'typically'. > > That's the first part of the sentence. > > The second part says: "the RTL uses here by default CP_UTF8." > > That is wrong. It does not (at least not on Mac). This must be fixed. Why do you think it is wrong ? It is perhaps wrong on your computer. Maybe it checks the environment ? Did you include clocale ? etc. There are maybe a 100 things that can change this. Don't be too hasty in changing things. Jonas (who created that page) is usually very careful in such matters. Michael. From jonas.maebe at elis.ugent.be Mon Apr 4 11:49:48 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Mon, 04 Apr 2016 11:49:48 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404113907.81B0.B7062D51@tgtools.de> References: <20160404103628.8197.B7062D51@tgtools.de> <20160404113907.81B0.B7062D51@tgtools.de> Message-ID: <20160404114948.Horde.sa-jcUisJlFXAji8bKjAePA@mail.elis.ugent.be> tobiasgiesen wrote on Mon, 04 Apr 2016: >> Your question was not about Lazarus but maybe you should read this: >> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus > > Very interesting, but apparently there is some wrong info. > > It says "On Linux and Mac OS X UTF-8 is typically the system > codepage, so the RTL uses > here by default CP_UTF8." > > Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001. That's because you don't use the cwstring unit nor another widestring manager. In that case, the DefaultSystemCodePage is set to ASCII because the default string conversion routines on Unix platforms do not support anything else (neither for converting from ansi/shortstring to wide/unicodestring, nor between ansistrings using different codepages). This is not new with FPC 3.0, it has always been like that. Jonas From mailinglists at geldenhuys.co.uk Mon Apr 4 11:52:20 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 10:52:20 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> Message-ID: <57023954.7060303@geldenhuys.co.uk> On 2016-04-04 10:27, Juha Manninen wrote: > Just use the new UTF-8 mode provided by Lazarus and remove all > explicit conversion functions. This is the FPC mailing list. Not everybody here uses Lazarus or LCL, so making such a suggestion is wishful thinking. For example, your suggestion means nothing to me, I don't use LCL. Regards, - Graeme - From jonas.maebe at elis.ugent.be Mon Apr 4 11:58:26 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Mon, 04 Apr 2016 11:58:26 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: References: <20160404113907.81B0.B7062D51@tgtools.de> <20160404114722.81B3.B7062D51@tgtools.de> Message-ID: <20160404115826.Horde.e-oNVUisJlFXAjrCAwNAeUA@mail.elis.ugent.be> Michael Van Canneyt wrote on Mon, 04 Apr 2016: > Don't be too hasty in changing things. Jonas (who created that page) > is usually very careful in such matters. I did forget to mention that the Default*CodePage variables are only initialised with the "real" values on *nix platforms if you include a widestring manager unit. I have now updated the page to reflect this fact. Jonas From michael at freepascal.org Mon Apr 4 12:02:39 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 12:02:39 +0200 (CEST) Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404115826.Horde.e-oNVUisJlFXAjrCAwNAeUA@mail.elis.ugent.be> References: <20160404113907.81B0.B7062D51@tgtools.de> <20160404114722.81B3.B7062D51@tgtools.de> <20160404115826.Horde.e-oNVUisJlFXAjrCAwNAeUA@mail.elis.ugent.be> Message-ID: On Mon, 4 Apr 2016, Jonas Maebe wrote: > > Michael Van Canneyt wrote on Mon, 04 Apr 2016: > >> Don't be too hasty in changing things. Jonas (who created that page) is >> usually very careful in such matters. > > I did forget to mention that the Default*CodePage variables are only > initialised with the "real" values on *nix platforms if you include a > widestring manager unit. I have now updated the page to reflect this fact. I will update the docs with such info for the upcoming 3.0.2. It clearly needs mentioning... Michael. From mailinglists at geldenhuys.co.uk Mon Apr 4 12:04:04 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 11:04:04 +0100 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404113907.81B0.B7062D51@tgtools.de> References: <20160404103628.8197.B7062D51@tgtools.de> <20160404113907.81B0.B7062D51@tgtools.de> Message-ID: <57023C14.8040307@geldenhuys.co.uk> On 2016-04-04 10:39, tobiasgiesen at gmail.com wrote: > It says "On Linux and Mac OS X UTF-8 is typically the system codepage, so the RTL uses > here by default CP_UTF8." > > Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001. Indeed, and on my FreeBSD system DefaultSystemCodePage returns 0. So the "typically" seems more like "unlikely in most cases". Regards, - Graeme - From michael at freepascal.org Mon Apr 4 12:07:11 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 12:07:11 +0200 (CEST) Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <57023C14.8040307@geldenhuys.co.uk> References: <20160404103628.8197.B7062D51@tgtools.de> <20160404113907.81B0.B7062D51@tgtools.de> <57023C14.8040307@geldenhuys.co.uk> Message-ID: On Mon, 4 Apr 2016, Graeme Geldenhuys wrote: > On 2016-04-04 10:39, tobiasgiesen at gmail.com wrote: >> It says "On Linux and Mac OS X UTF-8 is typically the system codepage, so the RTL uses >> here by default CP_UTF8." >> >> Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001. > > Indeed, and on my FreeBSD system DefaultSystemCodePage returns 0. > > So the "typically" seems more like "unlikely in most cases". Not necessarily: if you are dealing with UTF8/UnicodeString and other codepages, it is quite likely, and preferred, that you have unit cwstring included. Michael. From mailinglists at geldenhuys.co.uk Mon Apr 4 12:07:54 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 11:07:54 +0100 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: References: <20160404103628.8197.B7062D51@tgtools.de> <20160404113907.81B0.B7062D51@tgtools.de> Message-ID: <57023CFA.60703@geldenhuys.co.uk> On 2016-04-04 10:43, Michael Van Canneyt wrote: > > No. It says 'typically'. > > That doesn't necessarily mean it is so, but is mostly correct. It is still a very vague assumption. As I mentioned in my previous reply, that statement is false on my FreeBSD system too. So I should read the wiki as "typically incorrect" ;-) > No, that would be wrong. it normally is CP_UTF8 on linux. But it can differ. > I know people that still use ISO-8895 (or something similar). Only the > programmer can know what is correct. Just curious, how do you change the default codepage on a Linux system? By exporting a new value to the LANG environment variable? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Mon Apr 4 12:18:43 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 11:18:43 +0100 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: References: <20160404103628.8197.B7062D51@tgtools.de> <20160404113907.81B0.B7062D51@tgtools.de> <57023C14.8040307@geldenhuys.co.uk> Message-ID: <57023F83.4070301@geldenhuys.co.uk> On 2016-04-04 11:07, Michael Van Canneyt wrote: > if you are dealing with UTF8/UnicodeString and other codepages, it is > quite likely, and preferred, that you have unit cwstring included. OK, I just confirmed. Adding clocale to my 5-line test program doesn't affect the DefaultSystemCodePage result, but as soon as I add cwstring to the uses clause, then DefaultSystemCodePage returns 65001. I never use the UnicodeString type, and was under the impression that only UnicodeString (and WideString) requires the cwstring unit to function correctly. I use UTF-8 encoded text everywhere (stored inside String), so never bothered with the cwstring unit. But clearly in FPC 3.0 it is vital to include cwstring if you do anything text related. Something funny: I thought it really funny when Delphi introduced Unicode support, and how everybody struggled. I thought: "what a mess". Now FPC developers seem to be in the same boat. :-/ Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Mon Apr 4 12:20:25 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 11:20:25 +0100 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <20160404115826.Horde.e-oNVUisJlFXAjrCAwNAeUA@mail.elis.ugent.be> References: <20160404113907.81B0.B7062D51@tgtools.de> <20160404114722.81B3.B7062D51@tgtools.de> <20160404115826.Horde.e-oNVUisJlFXAjrCAwNAeUA@mail.elis.ugent.be> Message-ID: <57023FE9.6090408@geldenhuys.co.uk> On 2016-04-04 10:58, Jonas Maebe wrote: > I have now updated the page to reflect this > fact. Thanks Jonas, that's an important point to note. Regards, - Graeme - From tobiasgiesen at gmail.com Mon Apr 4 12:23:51 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 12:23:51 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <57023F83.4070301@geldenhuys.co.uk> References: <57023F83.4070301@geldenhuys.co.uk> Message-ID: <20160404122350.81B8.B7062D51@tgtools.de> > OK, I just confirmed. Adding clocale to my 5-line test program doesn't > affect the DefaultSystemCodePage result, but as soon as I add cwstring > to the uses clause, then DefaultSystemCodePage returns 65001. On Mac, not even cwstring does that. It sets the DefaultSystemCodePage to 20127. So, on Mac, the DefaultSystemCodePage is not "typically" set to UTF_8. It is never set to UTF_8 unless you do it yourself. Cheers, Tobias From juha.manninen62 at gmail.com Mon Apr 4 12:27:05 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 4 Apr 2016 13:27:05 +0300 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <57023954.7060303@geldenhuys.co.uk> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> Message-ID: On Mon, Apr 4, 2016 at 12:52 PM, Graeme Geldenhuys wrote: > This is the FPC mailing list. Not everybody here uses Lazarus or LCL, so > making such a suggestion is wishful thinking. For example, your > suggestion means nothing to me, I don't use LCL. Yes, I should have mentioned that this feature does not require LCL. It only requires LazUtils package and LazUTF8 unit in your uses section. It can be used in cmd line and server programs and I guess in fpGUI, too, although I have not tested. But yes, it requires Lazarus IDE because LazUtils is a Lazarus package. At least you must create and compile the project using Lazarus IDE. Anyway, this UTF-8 mode does more that sets the default String encoding. It also provides proper UTF-8 functions as backends for RTL's Ansi...() string functions. It also uses cwstring although it pulls in clib. Then typical users' code is amazingly Delphi compatible despite the different encoding, because code only seldom deals with individual codepoints beyond 7-bit ASCII. Juha From michael at freepascal.org Mon Apr 4 12:32:37 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 12:32:37 +0200 (CEST) Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion In-Reply-To: <57023CFA.60703@geldenhuys.co.uk> References: <20160404103628.8197.B7062D51@tgtools.de> <20160404113907.81B0.B7062D51@tgtools.de> <57023CFA.60703@geldenhuys.co.uk> Message-ID: On Mon, 4 Apr 2016, Graeme Geldenhuys wrote: > On 2016-04-04 10:43, Michael Van Canneyt wrote: >> >> No. It says 'typically'. >> >> That doesn't necessarily mean it is so, but is mostly correct. > > It is still a very vague assumption. As I mentioned in my previous > reply, that statement is false on my FreeBSD system too. So I should > read the wiki as "typically incorrect" ;-) > > >> No, that would be wrong. it normally is CP_UTF8 on linux. But it can differ. >> I know people that still use ISO-8895 (or something similar). Only the >> programmer can know what is correct. > > Just curious, how do you change the default codepage on a Linux system? > By exporting a new value to the LANG environment variable? Yes. And various LC_ environment vars. Michael. From nc-gaertnma at netcologne.de Mon Apr 4 12:34:20 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 4 Apr 2016 12:34:20 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <57023954.7060303@geldenhuys.co.uk> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> Message-ID: <20160404123420.1856b987@limapholos.matflo.wg> On Mon, 4 Apr 2016 10:52:20 +0100 Graeme Geldenhuys wrote: > On 2016-04-04 10:27, Juha Manninen wrote: > > Just use the new UTF-8 mode provided by Lazarus and remove all > > explicit conversion functions. > > This is the FPC mailing list. Not everybody here uses Lazarus or LCL, so > making such a suggestion is wishful thinking. For example, your > suggestion means nothing to me, I don't use LCL. First of all it's part of LazUtils. So you don't have to use the LCL for that. In fact you don't have to use LazUtils: some users simply copied the two units FPCAdds and LazUTF8. It's all open source. Second I find it funny that the statement comes from you - a notorious promoter of software on forums/lists of competing projects. And third setting the DefaultSystemCodePage is a good start, but not enough. Instead of explaining all the gory details, Juha promoted a more complete solution for UTF-8. This is useful for many users. They don't have to reinvent the wheel. Mattias From mailinglists at geldenhuys.co.uk Mon Apr 4 12:34:18 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 11:34:18 +0100 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160404122350.81B8.B7062D51@tgtools.de> References: <57023F83.4070301@geldenhuys.co.uk> <20160404122350.81B8.B7062D51@tgtools.de> Message-ID: <5702432A.9090500@geldenhuys.co.uk> On 2016-04-04 11:23, tobiasgiesen at gmail.com wrote: > On Mac, not even cwstring does that. It sets the DefaultSystemCodePage > to 20127. I just installed FPC 3.0 on my Macbook Pro (bought in the UK) and did the same test. Here DefaultSystemCodePage returned 65001. So I guess it depends on your OSX installation and which default locale settings was set up during install. Regards, - Graeme - From nc-gaertnma at netcologne.de Mon Apr 4 12:40:14 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 4 Apr 2016 12:40:14 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> Message-ID: <20160404124014.2f1e187e@limapholos.matflo.wg> On Mon, 4 Apr 2016 13:27:05 +0300 Juha Manninen wrote: >[...] > But yes, it requires Lazarus IDE because LazUtils is a Lazarus > package. At least you must create and compile the project using > Lazarus IDE. Or simply copy the two units FPCAdds, LazUTF-8 or parts of them from here: http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_6/components/lazutils/ Mattias From mailinglists at geldenhuys.co.uk Mon Apr 4 12:45:08 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 11:45:08 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404124014.2f1e187e@limapholos.matflo.wg> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404124014.2f1e187e@limapholos.matflo.wg> Message-ID: <570245B4.6030905@geldenhuys.co.uk> On 2016-04-04 11:40, Mattias Gaertner wrote: > Or simply copy the two units FPCAdds, LazUTF-8 or parts of them from > here: Thank you Juha and Mattias - I'll take a look at those to see what they do. Regards, - Graeme - From nc-gaertnma at netcologne.de Mon Apr 4 12:45:41 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 4 Apr 2016 12:45:41 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <5702432A.9090500@geldenhuys.co.uk> References: <57023F83.4070301@geldenhuys.co.uk> <20160404122350.81B8.B7062D51@tgtools.de> <5702432A.9090500@geldenhuys.co.uk> Message-ID: <20160404124541.09f4b2e3@limapholos.matflo.wg> On Mon, 4 Apr 2016 11:34:18 +0100 Graeme Geldenhuys wrote: > On 2016-04-04 11:23, tobiasgiesen at gmail.com wrote: > > On Mac, not even cwstring does that. It sets the DefaultSystemCodePage > > to 20127. > > I just installed FPC 3.0 on my Macbook Pro (bought in the UK) and did > the same test. Here DefaultSystemCodePage returned 65001. So I guess it > depends on your OSX installation and which default locale settings was > set up during install. All my Macs since 10.4 had UTF-8 as default and I can't remember a setting during install to change it. How did you get a codepage 20127 Mac? Mattias From tobiasgiesen at gmail.com Mon Apr 4 12:59:08 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 12:59:08 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160404124541.09f4b2e3@limapholos.matflo.wg> References: <5702432A.9090500@geldenhuys.co.uk> <20160404124541.09f4b2e3@limapholos.matflo.wg> Message-ID: <20160404125907.81BE.B7062D51@tgtools.de> > How did you get a codepage 20127 Mac? The Mac is UTF-8, but cwstring or whatever does not realize it. Since I cannot easily step into it with the debugger, I can't tell you why. Terminal has LC_CTYPE=UTF-8. Well I will just set the default codepages manually. Cheers, Tobias From mailinglists at geldenhuys.co.uk Mon Apr 4 13:00:38 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 12:00:38 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404123420.1856b987@limapholos.matflo.wg> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> Message-ID: <57024956.704@geldenhuys.co.uk> On 2016-04-04 11:34, Mattias Gaertner wrote: > for that. In fact you don't have to use LazUtils: some users simply > copied the two units FPCAdds and LazUTF8. It's all open source. This was not made clear until you explicitly mentioned it. Juha's initial comment was vague on the matter, and the original poster never mentioned they used Lazarus or LCL. > Second I find it funny that the statement comes from you I simply wanted an answer or explanation that benefits anybody using FPC. > more complete solution for UTF-8. This is useful for many users. They > don't have to reinvent the wheel. Not having looked at the two units you mentioned... but if this is a general requirement for anybody using UTF-8 or similar with FPC 3.0, then wouldn't it be best to see if those units can be contributed to FPC's FCL? The ultimate "don't reinvent the wheel" location. ;-) Regards, - Graeme - From michael at freepascal.org Mon Apr 4 13:06:34 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 13:06:34 +0200 (CEST) Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <57024956.704@geldenhuys.co.uk> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> <57024956.704@geldenhuys.co.uk> Message-ID: On Mon, 4 Apr 2016, Graeme Geldenhuys wrote: >> more complete solution for UTF-8. This is useful for many users. They >> don't have to reinvent the wheel. > > Not having looked at the two units you mentioned... but if this is a > general requirement for anybody using UTF-8 or similar with FPC 3.0, > then wouldn't it be best to see if those units can be contributed to > FPC's FCL? The ultimate "don't reinvent the wheel" location. ;-) One would think so but: 1. Using UTF8 is a choice of lazarus. Other people may prefer UnicodeString. On Windows, UnicodeString is more 'natural' or 'native'. 2. The release cycle of FPC is rather long, so updates will be available not as fast as the lazarus team needs them. And in view of 1. that may be a problem. If memory serves well, there was initially an attempt to get some of the functionality into FPC by Felipe, but this was quickly abandoned due to above arguments... Michael. From jonas.maebe at elis.ugent.be Mon Apr 4 13:10:38 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Mon, 04 Apr 2016 13:10:38 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160404125907.81BE.B7062D51@tgtools.de> References: <5702432A.9090500@geldenhuys.co.uk> <20160404124541.09f4b2e3@limapholos.matflo.wg> <20160404125907.81BE.B7062D51@tgtools.de> Message-ID: <20160404131038.Horde.c4qMJkisJlFXAkuuRBPgeUA@mail.elis.ugent.be> tobiasgiesen wrote on Mon, 04 Apr 2016: >> How did you get a codepage 20127 Mac? > > The Mac is UTF-8, This statement makes no sense. There is no "UTF-8" or "non-UTF-8" Mac. The Unix environment on OS X can use any OS-supported code page. > but cwstring or whatever does not realize it. cwstring simply sets the code page based on how it is defined in your environment. > Terminal has LC_CTYPE=UTF-8. What about LC_ALL? LC_ALL overrides LC_CTYPE, because that is how the meaning of these environment variables is defined by POSIX (see e.g. http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html ) > Well I will just set the default codepages manually. Then you will probably be back in a few months with another message complaining how FPC 3.0 supposedly breaks X or Y, because you are merely hiding the real issue (e.g. when calling an external program, which may then try to interpret your UTF-8 command line arguments as plain ASCII). Jonas From mailinglists at geldenhuys.co.uk Mon Apr 4 13:21:17 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 12:21:17 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> <57024956.704@geldenhuys.co.uk> Message-ID: <57024E2D.2070007@geldenhuys.co.uk> On 2016-04-04 12:06, Michael Van Canneyt wrote: > 1. Using UTF8 is a choice of lazarus. Other people may prefer UnicodeString. > On Windows, UnicodeString is more 'natural' or 'native'. Based on Internet standards and most popular OSes (mobile devices included), UTF-8 is kind - so we all know Windows backed the wrong horse [encoding]. ;-) [...Graeme runs and hides...] > 2. The release cycle of FPC is rather long, so updates will be available not > as fast as the lazarus team needs them. That's a valid point. Though it could probably be added as quick as in FPC 3.0.2. It's simply two new units that need to be explicitly used by somebody to have any affect, so it will not break existing code otherwise [if not used]. Regards, - Graeme - From michael at freepascal.org Mon Apr 4 13:48:46 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 13:48:46 +0200 (CEST) Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <57024E2D.2070007@geldenhuys.co.uk> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> <57024956.704@geldenhuys.co.uk> <57024E2D.2070007@geldenhuys.co.uk> Message-ID: On Mon, 4 Apr 2016, Graeme Geldenhuys wrote: > On 2016-04-04 12:06, Michael Van Canneyt wrote: >> 1. Using UTF8 is a choice of lazarus. Other people may prefer UnicodeString. >> On Windows, UnicodeString is more 'natural' or 'native'. > > Based on Internet standards and most popular OSes (mobile devices > included), UTF-8 is kind - so we all know Windows backed the wrong horse > [encoding]. ;-) > > [...Graeme runs and hides...] > Well, in 2016, I still only use UTF-8, even on windows. It works without problems if you know what you're doing. >> 2. The release cycle of FPC is rather long, so updates will be available not >> as fast as the lazarus team needs them. > > That's a valid point. > > Though it could probably be added as quick as in FPC 3.0.2. It's simply > two new units that need to be explicitly used by somebody to have any > affect, so it will not break existing code otherwise [if not used]. They should at least be renamed, to avoid confusion. Other than that, I personally see no objections. Michael. From jonas.maebe at elis.ugent.be Mon Apr 4 13:56:15 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Mon, 04 Apr 2016 13:56:15 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> <57024956.704@geldenhuys.co.uk> <57024E2D.2070007@geldenhuys.co.uk> Message-ID: <20160404135615.Horde.kE0wNUisJlFXAlZfJ5thHBA@mail.elis.ugent.be> Michael Van Canneyt wrote on Mon, 04 Apr 2016: > On Mon, 4 Apr 2016, Graeme Geldenhuys wrote: > [add LCL UTF-8 helper units to FPC] >> Though it could probably be added as quick as in FPC 3.0.2. It's simply >> two new units that need to be explicitly used by somebody to have any >> affect, so it will not break existing code otherwise [if not used]. > > They should at least be renamed, to avoid confusion. > > Other than that, I personally see no objections. I do: it's more units that we have to maintain, process bug reports and feature requests for, etc (or, in case they are supposed to remain copies of the Lazarus units, then it's extra work keeping them in sync and given the non-synchronised release cycles, they will almost never be in sync). We already have plenty of work with our own code. Jonas From tobiasgiesen at gmail.com Mon Apr 4 13:58:06 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Mon, 04 Apr 2016 13:58:06 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160404131038.Horde.c4qMJkisJlFXAkuuRBPgeUA@mail.elis.ugent.be> References: <20160404125907.81BE.B7062D51@tgtools.de> <20160404131038.Horde.c4qMJkisJlFXAkuuRBPgeUA@mail.elis.ugent.be> Message-ID: <20160404135805.81C1.B7062D51@tgtools.de> > > Terminal has LC_CTYPE=UTF-8. > > What about LC_ALL? My Mac OS installations do not have LC_ALL. But I just noticed that Carbon GUI programs do not get LC_CTYPE in their environment either. So maybe cwstring needs to be fixed for Carbon GUI Mac OS X programs. What I see in the environment is __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 I think Carbon apps should override DefaultSytemCodePage, because the Carbon interfaces always use UTF-8, they do not care about any environment strings. Cheers, Tobias From michael at freepascal.org Mon Apr 4 14:01:01 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 4 Apr 2016 14:01:01 +0200 (CEST) Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404135615.Horde.kE0wNUisJlFXAlZfJ5thHBA@mail.elis.ugent.be> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> <57024956.704@geldenhuys.co.uk> <57024E2D.2070007@geldenhuys.co.uk> <20160404135615.Horde.kE0wNUisJlFXAlZfJ5thHBA@mail.elis.ugent.be> Message-ID: On Mon, 4 Apr 2016, Jonas Maebe wrote: > > Michael Van Canneyt wrote on Mon, 04 Apr 2016: > >> On Mon, 4 Apr 2016, Graeme Geldenhuys wrote: >> > [add LCL UTF-8 helper units to FPC] >>> Though it could probably be added as quick as in FPC 3.0.2. It's simply >>> two new units that need to be explicitly used by somebody to have any >>> affect, so it will not break existing code otherwise [if not used]. >> >> They should at least be renamed, to avoid confusion. >> >> Other than that, I personally see no objections. > > I do: it's more units that we have to maintain, process bug reports and > feature requests for, etc (or, in case they are supposed to remain copies of > the Lazarus units, then it's extra work keeping them in sync and given the > non-synchronised release cycles, they will almost never be in sync). We > already have plenty of work with our own code. And that is why I wrote 'personally' :-) Michael. From pascaldragon at googlemail.com Mon Apr 4 14:15:33 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 4 Apr 2016 14:15:33 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <57024E2D.2070007@geldenhuys.co.uk> References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> <57024956.704@geldenhuys.co.uk> <57024E2D.2070007@geldenhuys.co.uk> Message-ID: Am 04.04.2016 13:21 schrieb "Graeme Geldenhuys" < mailinglists at geldenhuys.co.uk>: > > On 2016-04-04 12:06, Michael Van Canneyt wrote: > > 1. Using UTF8 is a choice of lazarus. Other people may prefer UnicodeString. > > On Windows, UnicodeString is more 'natural' or 'native'. > > Based on Internet standards and most popular OSes (mobile devices > included), UTF-8 is kind - so we all know Windows backed the wrong horse > [encoding]. ;-) > > [...Graeme runs and hides...] > Qt uses UTF-16 as well... (and our company's OS uses UTF-32) Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Mon Apr 4 15:19:05 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 4 Apr 2016 14:19:05 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <57023954.7060303@geldenhuys.co.uk> <20160404123420.1856b987@limapholos.matflo.wg> <57024956.704@geldenhuys.co.uk> <57024E2D.2070007@geldenhuys.co.uk> Message-ID: <570269C9.3090909@geldenhuys.co.uk> On 2016-04-04 13:15, Sven Barth wrote: > Qt uses UTF-16 as well... I always thought that strange. After all, Qt was born as a Unix-type GUI toolkit. Unless I got my facts wrong. Then again, it's only in recent years that Unix-like systems moved to UTF-8. I think even FreeBSD didn't use UTF-8 out of the box (until the last one or two releases). Java also uses UTF-16. What I like about those two are that they only have one string type. No confusion, but then they don't have as long a history as Pascal, so no legacy code to worry about. Regards, - Graeme - From jonas.maebe at elis.ugent.be Mon Apr 4 15:24:11 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Mon, 04 Apr 2016 15:24:11 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160404135805.81C1.B7062D51@tgtools.de> References: <20160404125907.81BE.B7062D51@tgtools.de> <20160404131038.Horde.c4qMJkisJlFXAkuuRBPgeUA@mail.elis.ugent.be> <20160404135805.81C1.B7062D51@tgtools.de> Message-ID: <20160404152411.Horde.PdgGLEisJlFXAmr7BwuxHBA@mail.elis.ugent.be> tobiasgiesen wrote on Mon, 04 Apr 2016: >> > Terminal has LC_CTYPE=UTF-8. >> >> What about LC_ALL? > > My Mac OS installations do not have LC_ALL. > > But I just noticed that Carbon GUI programs do not get LC_CTYPE in their > environment either. If none of the environment variables related to code pages are set, FPC falls back to UTF-8 for (a.o.) OS X. > So maybe cwstring needs to be fixed for Carbon GUI Mac OS X programs. If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or LANG environment variables is set to a setting that corresponds to ASCII (such as "C"), or set to a value that is not recognised as or translatable into a Windows code page number. > What I see in the environment is > __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 > > I think Carbon apps should override DefaultSytemCodePage, because the > Carbon interfaces always use UTF-8, they do not care about any > environment strings. On OS X, unlike on Windows, there is no inherent difference between "GUI" (be it Carbon, Cocoa, or --most likely-- a mixture of the two) and "non-GUI" applications. You can have command line applications linking to a Carbon framework to deal with aliases, and a GUI application calling into libutil to open a pseudo tty. The above environment variable is also unrelated to Carbon, but comes from CoreFoundation. 0x1F5 is the hexadecimal value of your user ID. At least one of the 0x0's indeed refers to the default/ansi encoding of CoreFoundation, but it's definitely not the value you want to use. It's the value of the MacRoman text encoding. That said, FPC 3.1.1 also contains an OS X/iOS-specific widestring manager unit that you can use instead of cwstring (iosxwstr), and that one will always default to UTF-8 (because the "ansi" code page of CoreFoundation only makes sense from a classic Mac backward compatibility standpoint, which we don't have to care about because we don't have a legacy code base that depends on this default setting -- if someone would want to port code that depends on this to FPC, they would have to set this themselves). Jonas Jonas From sethdgrover at gmail.com Mon Apr 4 15:51:11 2016 From: sethdgrover at gmail.com (Seth Grover) Date: Mon, 4 Apr 2016 07:51:11 -0600 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversion Message-ID: > Not necessarily: > if you are dealing with UTF8/UnicodeString and other codepages, it is > quite likely, and preferred, that you have unit cwstring included. > Michael. Question about this: If I use cthreads, cwstring, and load my own memory manager, what should the order in the uses clause be? I know if they are loaded/unloaded in the wrong order you can get SIGSEGVs during shutdown. >From my experience cthreads needs to be first. So should it be: cthreads, my_memory_manager, cwstring or cthreads, cwstring, my_memory_manager? Thanks, -SG -- Seth Grover -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkitty42 at windstream.net Mon Apr 4 16:55:20 2016 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Mon, 4 Apr 2016 10:55:20 -0400 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160404122350.81B8.B7062D51@tgtools.de> References: <57023F83.4070301@geldenhuys.co.uk> <20160404122350.81B8.B7062D51@tgtools.de> Message-ID: <57028058.2090704@windstream.net> On 04/04/2016 06:23 AM, tobiasgiesen at gmail.com wrote: >> OK, I just confirmed. Adding clocale to my 5-line test program doesn't >> affect the DefaultSystemCodePage result, but as soon as I add cwstring to >> the uses clause, then DefaultSystemCodePage returns 65001. > > On Mac, not even cwstring does that. It sets the DefaultSystemCodePage to > 20127. > > So, on Mac, the DefaultSystemCodePage is not "typically" set to UTF_8. It is > never set to UTF_8 unless you do it yourself. FWIW: i keep seeing the argument "on Mac" but never has the OS on that Mac been mentioned... AFAIK there is more than one OS for Mac or at least more than one version of the OS... it is possible that the default has been changed plus there's whatever was selected for the language during the installation... this really should be clarified for your Mac and its OS... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. From mschnell at lumino.de Mon Apr 4 12:44:12 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 04 Apr 2016 12:44:12 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160404104341.819A.B7062D51@tgtools.de> References: <20160404101817.818D.B7062D51@tgtools.de> <20160404103059.286dab90@limapholos.matflo.wg> <20160404104341.819A.B7062D51@tgtools.de> Message-ID: <5702457C.1020404@lumino.de> On 04/04/2016 10:43 AM, tobiasgiesen at gmail.com wrote: > "Unicode aware Pascal code needs to set DefaultSystemCodePage to > CP_UTF8". That can't be this ubiquitous. I do suppose that the default value is supposed to make sense in many cases. OTOH, if - as you seem to suggest - there is any conversion at all when using TSTringList to store your UTF8 strings, (independent whether it "works" or not) this will introduce a decent performance problem. I don't know it that depends on the setting of DefaultSystemCodePage. Please let us know what you find. (right now Lazarus does not seem to compile for me with 3.1.1, so I can't easily check myself.) -Michael From mschnell at lumino.de Mon Apr 4 12:52:46 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 04 Apr 2016 12:52:46 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> Message-ID: <5702477E.2020307@lumino.de> On 04/04/2016 11:27 AM, Juha Manninen wrote: > On Mon, Apr 4, 2016 at 11:18 AM, wrote: >> I use TStringList for UTF-8 strings. This is no longer possible, because >> automatic conversions cause question marks and data loss. > You are completely lost with this issue. The automatic conversion of > encodings is a big step forward. > Just use the new UTF-8 mode provided by Lazarus and remove all > explicit conversion functions. (How) does the new UTF-8 mode in Lazarus change the way TStringList works (as this is what Tobias is concerned about) ? -Michael From mailinglists at geldenhuys.co.uk Wed Apr 6 13:23:01 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 6 Apr 2016 12:23:01 +0100 Subject: [fpc-pascal] Class vs Object type Message-ID: <5704F195.3030506@geldenhuys.co.uk> Hi, I use Class and Object data types frequently in my code. I like the fact that Object data types can be used without first instantiating an instance and it gets freed automatically. But is there a technical (maybe compiler) reason why I should possibly switch all my code to only using Class types for instance? It has to be said that for more complex "objects" I always use a Class type though. Also, Delphi compatibility (or their lack of Object type support) is of no concern to me. >From the FPC documentation I noted the following: "The difference between objects and classes is mainly that an object is allocated on the stack, as an ordinary record would be, and that classes are always allocated on the heap." Are there pros or cons to either? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From michael at freepascal.org Wed Apr 6 13:26:13 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 6 Apr 2016 13:26:13 +0200 (CEST) Subject: [fpc-pascal] Class vs Object type In-Reply-To: <5704F195.3030506@geldenhuys.co.uk> References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: On Wed, 6 Apr 2016, Graeme Geldenhuys wrote: > Hi, > > I use Class and Object data types frequently in my code. I like the fact > that Object data types can be used without first instantiating an > instance and it gets freed automatically. > > But is there a technical (maybe compiler) reason why I should possibly > switch all my code to only using Class types for instance? > > It has to be said that for more complex "objects" I always use a Class > type though. Also, Delphi compatibility (or their lack of Object type > support) is of no concern to me. > >> From the FPC documentation I noted the following: > > "The difference between objects and classes is mainly that an object is > allocated on the stack, as an ordinary record would be, and that classes > are always allocated on the heap." > > Are there pros or cons to either? 1. Classes are automatically zeroed out. That's an advantage. 2. When doing a:=b (a and B classes) you copy a pointer. This is cheap. when doing the same with objects, you are potentially copying a lot of data, with unknown side effects. Michael. From XHajT03 at hajny.biz Wed Apr 6 14:07:07 2016 From: XHajT03 at hajny.biz (Tomas Hajny) Date: Wed, 6 Apr 2016 14:07:07 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: On Wed, April 6, 2016 13:26, Michael Van Canneyt wrote: > On Wed, 6 Apr 2016, Graeme Geldenhuys wrote: Hi, >> I use Class and Object data types frequently in my code. I like the fact >> that Object data types can be used without first instantiating an >> instance and it gets freed automatically. . . > 1. Classes are automatically zeroed out. That's an advantage. True. Note that objects descended from TObject are automatically zeroed out as well as soon as one calls the constructor Init. > 2. When doing a:=b (a and B classes) you copy a pointer. This is cheap. > when doing the same with objects, you are potentially copying a lot of > data, > with unknown side effects. Well, one can work with pointers to objects as well if this is the intention. You should always know whether you want to copy a reference to certain data or whether you want to create copy of the stored data (the latter obviously takes more time, but that doesn't matter much if this is what you need to do anwyay). Otherwise you could equally say that copying just a pointer may have "unknown side effects" as soon as you change the "copy". Tomas From pascaldragon at googlemail.com Wed Apr 6 14:21:48 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 6 Apr 2016 14:21:48 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: Am 06.04.2016 14:06 schrieb "Tomas Hajny" : > > On Wed, April 6, 2016 13:26, Michael Van Canneyt wrote: > > On Wed, 6 Apr 2016, Graeme Geldenhuys wrote: > > Hi, > > >> I use Class and Object data types frequently in my code. I like the fact > >> that Object data types can be used without first instantiating an > >> instance and it gets freed automatically. > . > . > > 1. Classes are automatically zeroed out. That's an advantage. > > True. Note that objects descended from TObject are automatically zeroed > out as well as soon as one calls the constructor Init. Just for clarification (cause I first thought wrong as well): this means the TObject object from unit Objects, instead of the class TObject. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Wed Apr 6 14:23:54 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 6 Apr 2016 14:23:54 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <5704F195.3030506@geldenhuys.co.uk> References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: Am 06.04.2016 13:23 schrieb "Graeme Geldenhuys" < mailinglists at geldenhuys.co.uk>: > > Hi, > > I use Class and Object data types frequently in my code. I like the fact > that Object data types can be used without first instantiating an > instance and it gets freed automatically. Note: with the modeswitch advandedrecords you can also use methods in records which allows you to declare operator overloads that can also be picked up by generics. (Just in case you'd need it) Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobiasgiesen at gmail.com Wed Apr 6 15:05:02 2016 From: tobiasgiesen at gmail.com (tobiasgiesen at gmail.com) Date: Wed, 06 Apr 2016 15:05:02 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160404152411.Horde.PdgGLEisJlFXAmr7BwuxHBA@mail.elis.ugent.be> References: <20160404135805.81C1.B7062D51@tgtools.de> <20160404152411.Horde.PdgGLEisJlFXAmr7BwuxHBA@mail.elis.ugent.be> Message-ID: <20160406150501.9C2D.B7062D51@tgtools.de> Hello, Jonas wrote: > If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or LANG environment variables is set to > a setting that corresponds to ASCII (such as "C"), or set to a value that is not recognised as or translatable into > a Windows code page number. That was it - only when running under Lazarus via debugger, my project has LANG=C. I wonder where LANG=C comes from? Note that it is a very old project. A newly created project file does not have LANG=C in the environment. Cheers, Tobias From vojtech.cihak at atlas.cz Wed Apr 6 15:13:56 2016 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=C4=9Bch_=C4=8Cih=C3=A1k?=) Date: Wed, 06 Apr 2016 15:13:56 +0200 Subject: [fpc-pascal] =?utf-8?q?Class_vs_Object_type?= In-Reply-To: References: <5704F195.3030506@geldenhuys.co.uk>, Message-ID: <20160406151356.E4A7F91F@atlas.cz> How can I do it?   When I try do:   TMyObj = object(TObject)   compiler tells me:   Error: The mix of different kind of objects (class, object, interface, etc) isn't allowed   Thanks   V. ______________________________________________________________ > Od: Tomas Hajny > Komu: "FPC-Pascal users discussions" > Datum: 06.04.2016 14:07 > Předmět: Re: [fpc-pascal] Class vs Object type > On Wed, April 6, 2016 13:26, Michael Van Canneyt wrote: > On Wed, 6 Apr 2016, Graeme Geldenhuys wrote: True. Note that objects descended from TObject are automatically zeroed out as well as soon as one calls the constructor Init. Tomas _______________________________________________ fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonas.maebe at elis.ugent.be Wed Apr 6 15:25:32 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Wed, 06 Apr 2016 15:25:32 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160406150501.9C2D.B7062D51@tgtools.de> References: <20160404135805.81C1.B7062D51@tgtools.de> <20160404152411.Horde.PdgGLEisJlFXAmr7BwuxHBA@mail.elis.ugent.be> <20160406150501.9C2D.B7062D51@tgtools.de> Message-ID: <20160406152532.Horde.hDsxQUisJlFXBQ5MXQpRc8A@mail.elis.ugent.be> tobiasgiesen wrote on Wed, 06 Apr 2016: > Jonas wrote: >> If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or >> LANG environment variables is set to >> a setting that corresponds to ASCII (such as "C"), or set to a >> value that is not recognised as or translatable into >> a Windows code page number. > > That was it - only when running under Lazarus via debugger, my > project has LANG=C. > > I wonder where LANG=C comes from? > > Note that it is a very old project. A newly created project file > does not have LANG=C in the > environment. Then it's probably from the info.plist of that old project. Jonas From nc-gaertnma at netcologne.de Wed Apr 6 15:37:37 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 6 Apr 2016 15:37:37 +0200 Subject: [fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx In-Reply-To: <20160406150501.9C2D.B7062D51@tgtools.de> References: <20160404135805.81C1.B7062D51@tgtools.de> <20160404152411.Horde.PdgGLEisJlFXAmr7BwuxHBA@mail.elis.ugent.be> <20160406150501.9C2D.B7062D51@tgtools.de> Message-ID: <20160406153737.34fdbe98@limapholos.matflo.wg> On Wed, 06 Apr 2016 15:05:02 +0200 tobiasgiesen at gmail.com wrote: > Hello, > > Jonas wrote: > > If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or LANG environment variables is set to > > a setting that corresponds to ASCII (such as "C"), or set to a value that is not recognised as or translatable into > > a Windows code page number. > > That was it - only when running under Lazarus via debugger, my project has LANG=C. > > I wonder where LANG=C comes from? Check Run / Run Parameters / Environment. > Note that it is a very old project. A newly created project file does not have LANG=C in the > environment. Mattias From XHajT03 at hajny.biz Wed Apr 6 16:06:44 2016 From: XHajT03 at hajny.biz (Tomas Hajny) Date: Wed, 6 Apr 2016 16:06:44 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <20160406151356.E4A7F91F@atlas.cz> References: <5704F195.3030506@geldenhuys.co.uk>, <20160406151356.E4A7F91F@atlas.cz> Message-ID: On Wed, April 6, 2016 15:13, Vojtěch Čihák wrote: > How can I do it? >   > When I try do: >   > TMyObj = object(TObject) >   > compiler tells me: >   > Error: The mix of different kind of objects (class, object, interface, > etc) isn't allowed You need to add unit Objects to the uses clause (see also the e-mail from Sven). Tomas > ______________________________________________________________ >> Od: Tomas Hajny >> Komu: "FPC-Pascal users discussions" >> Datum: 06.04.2016 14:07 >> Předmět: Re: [fpc-pascal] Class vs Object type >> > On Wed, April 6, 2016 13:26, Michael Van Canneyt wrote: >> On Wed, 6 Apr 2016, Graeme Geldenhuys wrote: > > True. Note that objects descended from TObject are automatically zeroed > out as well as soon as one calls the constructor Init. > > Tomas From dec12 at avidsoft.com.hk Wed Apr 6 16:28:01 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Wed, 06 Apr 2016 22:28:01 +0800 Subject: [fpc-pascal] Class vs Object type In-Reply-To: References: <5704F195.3030506@geldenhuys.co.uk>, <20160406151356.E4A7F91F@atlas.cz> Message-ID: <57051CF1.5000103@avidsoft.com.hk> objects unit contains TObject = OBJECT CONSTRUCTOR Init; PROCEDURE Free; FUNCTION Is_Object(P:Pointer):Boolean; DESTRUCTOR Done; Virtual; END; On the other hand, objpash.inc contains TObject = class public { please don't change the order of virtual methods, because their vmt offsets are used by some assembler code which uses hard coded addresses (FK) } constructor Create; ..... That is so confusing. What are other real benefits in inheriting from object unit's TObject? The zeroing function of init can easily be achieved by copying the code to the user's object init constructor: CONSTRUCTOR TObject.Init; VAR LinkSize: LongInt; Dummy: DummyObject; BEGIN LinkSize := Pbyte(@Dummy.Data)-Pbyte(@Dummy); { Calc VMT link size } FillChar((Pbyte(@Self)+LinkSize)^, SizeOf(Self)-LinkSize, #0); { Clear data fields } END; Dennis Tomas Hajny wrote: > On Wed, April 6, 2016 15:13, Vojtěch Čihák wrote: >> How can I do it? >> >> When I try do: >> >> TMyObj = object(TObject) >> >> compiler tells me: >> >> Error: The mix of different kind of objects (class, object, interface, >> etc) isn't allowed > You need to add unit Objects to the uses clause (see also the e-mail from > Sven). > > Tomas > > >> ______________________________________________________________ >>> Od: Tomas Hajny >>> Komu: "FPC-Pascal users discussions" >>> Datum: 06.04.2016 14:07 >>> Předmět: Re: [fpc-pascal] Class vs Object type >>> >> On Wed, April 6, 2016 13:26, Michael Van Canneyt wrote: >>> On Wed, 6 Apr 2016, Graeme Geldenhuys wrote: >> True. Note that objects descended from TObject are automatically zeroed >> out as well as soon as one calls the constructor Init. >> >> Tomas > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal From pascaldragon at googlemail.com Wed Apr 6 17:09:41 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 6 Apr 2016 17:09:41 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <57051CF1.5000103@avidsoft.com.hk> References: <5704F195.3030506@geldenhuys.co.uk> <20160406151356.E4A7F91F@atlas.cz> <57051CF1.5000103@avidsoft.com.hk> Message-ID: Am 06.04.2016 16:28 schrieb "Dennis" : > > objects unit contains > TObject = OBJECT > CONSTRUCTOR Init; > PROCEDURE Free; > FUNCTION Is_Object(P:Pointer):Boolean; > DESTRUCTOR Done; Virtual; > END; > > > On the other hand, objpash.inc contains > TObject = class > public > { please don't change the order of virtual methods, because > their vmt offsets are used by some assembler code which uses > hard coded addresses (FK) } > constructor Create; > ..... > > That is so confusing. > What are other real benefits in inheriting from object unit's TObject? It's mainly there for backwards compatibility with TP code. It's also the base class of the FV object hierarchy. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Wed Apr 6 17:27:26 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 6 Apr 2016 16:27:26 +0100 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <5704F195.3030506@geldenhuys.co.uk> References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: <57052ADE.2020102@geldenhuys.co.uk> On 2016-04-06 12:23, Graeme Geldenhuys wrote: > Are there pros or cons to either? Thanks for the replies everybody. From the answers I've seen thus far I came to the conclusion that if the code which uses Object style objects works, there is no real reason or urgency to port that code to Class style objects. No technical or performance related reasons at least. Very good to know, thanks. Regards, - Graeme - From peter at pblackman.plus.com Wed Apr 6 18:34:31 2016 From: peter at pblackman.plus.com (Peter) Date: Wed, 6 Apr 2016 17:34:31 +0100 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <5704F195.3030506@geldenhuys.co.uk> References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: <57053A97.2070209@pblackman.plus.com> On 06/04/16 12:23, Graeme Geldenhuys wrote: > Hi, > ....... > >>From the FPC documentation I noted the following: > > "The difference between objects and classes is mainly that an object is > allocated on the stack, as an ordinary record would be, and that classes > are always allocated on the heap." > > Are there pros or cons to either? > > Regards, > - Graeme - > Hi Graeme, A comment re stack vs heap on Linux. Using a recursive routine, I discovered the hard way that 1) the stack is surprisingly small by default (8192Kb) 2) the stack blow error message "broken pipe" is rather unintuitive The stack may be set to be unlimited (I've done this now), but this is not usually the default setting. Regarding the 2nd point, the kernel sends a signal to a process with a blown stack, but signal processing requires stack space! This might be fixable by directing the process to use the alternate stack for signal handling. The error message would hopefully then be more meaningful. Regards, Peter From svaa at ciberpiula.net Thu Apr 7 12:58:14 2016 From: svaa at ciberpiula.net (Santiago A.) Date: Thu, 7 Apr 2016 12:58:14 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <5704F195.3030506@geldenhuys.co.uk> References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: <57063D46.2030709@ciberpiula.net> El 06/04/2016 a las 13:23, Graeme Geldenhuys escribió: > "The difference between objects and classes is mainly that an object is > allocated on the stack, as an ordinary record would be, and that classes > are always allocated on the heap." > > Are there pros or cons to either? > > Regards, > - Graeme - A nice pro of objects is that, if you don't need a constructor, you can forget about calling create and free. If you need a constructor (ie it has virtual methods), there is not that advantage. Moreover, if the object uses classes instances that must be freed, you also must call destructor, then any advantage is over. Maybe a little performance gain using stack instead of heap. A nice feature would be default creator and destructor: ej. type TMyObject=Object constructor default; Destructor default; end; procedure foo; var obj:TMyObject; begin // Default constructor (if it has) automatically called here obj.xxxx; obj.zzz; // Default destructor automatically called here end; Or even with parameters type TMyObjectParam=Object constructor default(n:Integer); Destructor default; end; procedure foo; var obj1:TMyObjectParam(7); obj2:TMyObjectParam; begin // Default constructor of obj1 automatically called here with param 7 // Default constructor of obj2 not called because the declaration has no parameters obj1.xxxx; obj1.zzz; if condition then begin obj2.Default(x); // Constructor must be called manually obj2.xxxx; obj2.zzz; end; // Default destructor of obj2 automatically called here if it has been initializated // Default destructor of obj1 automatically called here end; -- Saludos Santi svaa at ciberpiula.net From mailinglists at geldenhuys.co.uk Thu Apr 7 13:04:53 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 7 Apr 2016 12:04:53 +0100 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <57063D46.2030709@ciberpiula.net> References: <5704F195.3030506@geldenhuys.co.uk> <57063D46.2030709@ciberpiula.net> Message-ID: <57063ED5.1080308@geldenhuys.co.uk> On 2016-04-07 11:58, Santiago A. wrote: > Moreover, if the object uses classes instances that must be freed, you > also must call destructor, then any advantage is over. Technically yes, but as a rule of thumb, I *never* use Class objects inside an Object object. That just seems messy. Regards, - Graeme - From svaa at ciberpiula.net Thu Apr 7 13:19:41 2016 From: svaa at ciberpiula.net (Santiago A.) Date: Thu, 7 Apr 2016 13:19:41 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <57063ED5.1080308@geldenhuys.co.uk> References: <5704F195.3030506@geldenhuys.co.uk> <57063D46.2030709@ciberpiula.net> <57063ED5.1080308@geldenhuys.co.uk> Message-ID: <5706424D.1080504@ciberpiula.net> El 07/04/2016 a las 13:04, Graeme Geldenhuys escribió: > On 2016-04-07 11:58, Santiago A. wrote: >> Moreover, if the object uses classes instances that must be freed, you >> also must call destructor, then any advantage is over. > Technically yes, but as a rule of thumb, I *never* use Class objects > inside an Object object. That just seems messy. Usually, me neither. But I often use open arrays that can grow. Although open arrays are pointers that use heap, they are supposed to be liberated when the object is removed from stack, but in fpc 2.6.4 didn't properly. and 3.0.0 I have found strange behaviors and errors if I don't call a constructor. Nevertheless, I stick on my idea that even if objects have virtual methods, they should be initializated properly even if you don't call the constructor. -- Saludos Santi svaa at ciberpiula.net From luizamericop at gmail.com Thu Apr 7 14:00:21 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Thu, 7 Apr 2016 09:00:21 -0300 Subject: [fpc-pascal] Create dynamic SQL according to available params Message-ID: I enconter the following pattern frequently (simplified): SQL: Select * From Customers Where FieldX = 1 Later i need a similar query that uses a different filter like Select * From Customers Where FieldX = 1 and FieldY = :paramy Is there any code that given a SQL Template would generate the second filter when paramy is available and keep blank when not available? Like Select * From Customers Where FieldX = 1 ${paramtemplate paramy} The param not necessarily have to be in TParams, in my case the param is both in a JSON object and in TParams If there's not in pascal, someone knows such templating in another languages? The hard part is getting a flexible and functional syntax Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Thu Apr 7 14:03:40 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 7 Apr 2016 14:03:40 +0200 (CEST) Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: On Thu, 7 Apr 2016, Luiz Americo Pereira Camara wrote: > I enconter the following pattern frequently (simplified): > > SQL: > Select * From Customers Where FieldX = 1 > > Later i need a similar query that uses a different filter like > > Select * From Customers Where FieldX = 1 and FieldY = :paramy > > Is there any code that given a SQL Template would generate the second > filter when paramy is available and keep blank when not available? > > Like > Select * From Customers Where FieldX = 1 ${paramtemplate paramy} > > The param not necessarily have to be in TParams, in my case the param is > both in a JSON object and in TParams I have not found such code. I rolled my own. Michael. From luizamericop at gmail.com Thu Apr 7 14:06:39 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Thu, 7 Apr 2016 09:06:39 -0300 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: 2016-04-07 9:03 GMT-03:00 Michael Van Canneyt : > > > On Thu, 7 Apr 2016, Luiz Americo Pereira Camara wrote: > > >> Is there any code that given a SQL Template would generate the second >> filter when paramy is available and keep blank when not available? >> >> >> > I have not found such code. I rolled my own. > > Any chance sharing the code or at least the syntax? Thanks in advance Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Thu Apr 7 14:17:03 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 7 Apr 2016 14:17:03 +0200 (CEST) Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: On Thu, 7 Apr 2016, Luiz Americo Pereira Camara wrote: > 2016-04-07 9:03 GMT-03:00 Michael Van Canneyt : > >> >> >> On Thu, 7 Apr 2016, Luiz Americo Pereira Camara wrote: >> >> >>> Is there any code that given a SQL Template would generate the second >>> filter when paramy is available and keep blank when not available? >>> >>> >>> >> I have not found such code. I rolled my own. >> >> > Any chance sharing the code or at least the syntax? No, that was for a commercial project. sorry. Michael. From mailinglists at geldenhuys.co.uk Thu Apr 7 14:20:08 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 7 Apr 2016 13:20:08 +0100 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: <57065078.30207@geldenhuys.co.uk> On 2016-04-07 13:00, Luiz Americo Pereira Camara wrote: > If there's not in pascal, someone knows such templating in another > languages? The hard part is getting a flexible and functional syntax I have written such code for the tiOPF project, but it should be quick to detach any tiOPF dependencies. The code is well unit tested too (see the tiCriteria_TST.pas unit). The unit test code is also good for usage examples. It can't handle all complex cases, but is fairly good. It also has an option to inject any SQL as-is, in case you need a complex WHERE clause. http://geldenhuys.co.uk/tiopf/ticriteria/index.html In summary, you use the TtiCriteria class to add your desired criteria, then call tiCriteriaAsSQL(...) which will generate the SQL WHERE clause string for you. tiOPF is available on SourceForge or Github: https://sourceforge.net/p/tiopf/code/ci/tiopf2/tree/ tiCriteria.pas lives in the Core/ directory. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mike.cornflake at gmail.com Thu Apr 7 14:25:34 2016 From: mike.cornflake at gmail.com (Michael Thompson) Date: Thu, 7 Apr 2016 20:25:34 +0800 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: On 7 April 2016 at 20:00, Luiz Americo Pereira Camara < luizamericop at gmail.com> wrote: > Is there any code that given a SQL Template would generate the second filter when paramy is available and keep blank when not available? Nope, or at least I don't think so. I've spent a long time looking as well. Been meaning to bring up the discussion either here or in the forum I ended up implementing my own "Macro" functionality. Unfortunately I've broken a few rules and tied the functionality to the UI, making it hard to share. I need this all the time. My primary usage is in Master-Detail relationships, where I always want the Master to contain an "ALL" option. To achieve I write SQL's like... Select Incident_Type As "Incident_Type", Description As "Description", 'Where Incident_Type=''' || Incident_Type || '''' As "Filter_ID" From PIG Union Select '(ALL)' As "Incident_Type", 'All Types' As "Description", '' As "Filter_ID" From DUAL The first Select returns the Master Table, the second Select appends my ALL. Note that "Filter_ID" contains my full SQL Where clause. Over in my Detail SQL, I can write stuff like Select * From Incident :Filter_ID Order By Incident_Type, Incident I implement the detail refresh myself (easy), and I implement the Macro substitution myself before executing the Detail SQL. (Any SQL field ending in _ID is automatically hidden in my code) I use this so often, and in so many different ways (Macro's don't have to contain Where clauses, they can be any SQL elements, including simple data), that I cannot consider SQL development without it. And as such, I've often wondered how do others deal with this... Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpc at microbizz.nl Thu Apr 7 14:43:11 2016 From: fpc at microbizz.nl (Adriaan van Os) Date: Thu, 07 Apr 2016 14:43:11 +0200 Subject: [fpc-pascal] Class vs Object type In-Reply-To: <5704F195.3030506@geldenhuys.co.uk> References: <5704F195.3030506@geldenhuys.co.uk> Message-ID: <570655DF.10206@microbizz.nl> Graeme Geldenhuys wrote: > Are there pros or cons to either? The fashion of the day. Apparently, programmers are (supposed to be) not intelligent enough to work with pointers themselves -- if needed. So the compiler does that for you and declares everything a pointer automatically. Same with "magic" types such as PChar and "AnsiString". Poor man's programming in my view, but as said, that's the fashion of the day. Needless to say that a program where the programmer does have full control himself (and uses that to the advantage) is both faster and more reliable than a program where things are handled "automagically". Regards, Adriaan van Os From mike.cornflake at gmail.com Thu Apr 7 14:44:18 2016 From: mike.cornflake at gmail.com (Michael Thompson) Date: Thu, 7 Apr 2016 20:44:18 +0800 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: On 7 April 2016 at 20:06, Luiz Americo Pereira Camara < luizamericop at gmail.com> wrote: > Any chance sharing the code or at least the syntax? (I realise I'm hijacking your conversation with Michael - apologies for that, but this interests me) My code to initialise the grid (which hides all _ID columns) Procedure InitialiseDBGrid(oGrid: TDBGrid; oDataset: TDataset; bHideIDs: Boolean = False); <...> Begin If not oDataset.Active Then Exit; oDataset.DisableControls; Try <...> oDataset.First; For iTemp := oGrid.Columns.Count - 1 Downto 0 Do Begin oColumn := oGrid.Columns[iTemp]; oField := oColumn.Field; <...> // Hide the ID columns if so requested If (bHideIDs) And (Copy(oField.FieldName, Length(oField.FieldName) - 1, 2) = 'ID') Then Begin oColumn.Visible := False; oField.Visible := False; End; <...> End; <...> oDataset.First; Finally oDataset.EnableControls; End; End; Without getting into my architecture too deeply, I have code that hooks into the Master dataset OnAfterScroll, and the Macro's for each Detail data are handled simply by the follow sort of code... Function TfrmSQLExplorer.ReplaceCommonMacros(sSQL: String): String; Begin Result := sSQL; Result := FindReplace(Result, ':UserDate', FormatDateTime('yyyy-mm-dd', dtUserDate.Date)); Result := FindReplace(Result, ':Time', FormatDateTime('HH:mm:ss', Now)); Result := FindReplace(Result, ':Date', FormatDateTime('yyyy-mm-dd', Now)); Result := FindReplace(Result, ':Database', FClient.DatabaseName); Result := FindReplace(Result, ':Repository', FClient.DatabaseName + '_Rep'); Result := FFilters.ReplaceMacros(Result); End; (FFilters is essentially a list of frames that each contain a DBlookupCombo) and Function TdckMacros.ReplaceCommonMacros(oExclude: TDataset; sSQL: String): String; Var i: Integer; iField: Integer; oField: TField; oDataset: TDataset; sReplace: String; Begin Result := sSQL; For i := 0 To FDatasets.Count - 1 Do Begin oDataset := Dataset[i]; If (oDataset <> oExclude) Then For iField := 0 To oDataset.Fields.Count - 1 Do Begin oField := oDataset.Fields[iField]; sReplace := oField.AsString; If (oField.DataType = ftInteger) And (sReplace = '') Then Result := FindReplace(Result, ':' + oField.FieldName, '-99999') Else Result := FindReplace(Result, ':' + oField.FieldName, sReplace); End; End; End; You don't need to follow my architecture (I hope ;-) ), just the concept of cycling through a dataset, treating all columns as potential Macros for replacement. Sure, there's issues in the above code that are on my TODO, but have been there for a while, but as I construct all the SQLs used by this code, I've got used to working around those issues :-) Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.cornflake at gmail.com Thu Apr 7 14:47:25 2016 From: mike.cornflake at gmail.com (Michael Thompson) Date: Thu, 7 Apr 2016 20:47:25 +0800 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: <57065078.30207@geldenhuys.co.uk> References: <57065078.30207@geldenhuys.co.uk> Message-ID: On 7 April 2016 at 20:20, Graeme Geldenhuys wrote: > On 2016-04-07 13:00, Luiz Americo Pereira Camara wrote: > > If there's not in pascal, someone knows such templating in another > > languages? The hard part is getting a flexible and functional syntax > > I have written such code for the tiOPF project, but it should be quick > to detach any tiOPF dependencies. The code is well unit tested too (see > the tiCriteria_TST.pas unit). The unit test code is also good for usage > examples. > > It can't handle all complex cases, but is fairly good. It also has an > option to inject any SQL as-is, in case you need a complex WHERE clause. > > http://geldenhuys.co.uk/tiopf/ticriteria/index.html > > In summary, you use the TtiCriteria class to add your desired criteria, > then call tiCriteriaAsSQL(...) which will generate the SQL WHERE clause > string for you. Interesting. I've been meaning to look into tiOPF for a while. Part of that massive TODO list :-) This moves it up that list... Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Thu Apr 7 15:04:24 2016 From: md at delfire.net (Marcos Douglas) Date: Thu, 7 Apr 2016 10:04:24 -0300 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: On Thu, Apr 7, 2016 at 9:00 AM, Luiz Americo Pereira Camara wrote: > > I enconter the following pattern frequently (simplified): > > SQL: > Select * From Customers Where FieldX = 1 > > Later i need a similar query that uses a different filter like > > Select * From Customers Where FieldX = 1 and FieldY = :paramy > > Is there any code that given a SQL Template would generate the second filter when paramy is available and keep blank when not available? You can do this: ===begin=== select * from Customers where 1=1 and FieldX = 1 and (:paramy = -1 or FieldY = :paramy) ===end=== if you do not want to filter, just pass -1 (or whatever). Otherwise, pass the real value. For MSSQL I like to declare a variable like this: ===begin=== declare @paramy int = :paramy ... and (@paramy = -1 or FieldY = @paramy) ===end=== Regards, Marcos Douglas From svaa at ciberpiula.net Thu Apr 7 16:20:16 2016 From: svaa at ciberpiula.net (Santiago A.) Date: Thu, 7 Apr 2016 16:20:16 +0200 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: Message-ID: <57066CA0.10608@ciberpiula.net> El 07/04/2016 a las 14:00, Luiz Americo Pereira Camara escribió: > I enconter the following pattern frequently (simplified): > > SQL: > Select * From Customers Where FieldX = 1 > > Later i need a similar query that uses a different filter like > > Select * From Customers Where FieldX = 1 and FieldY = :paramy I remember a component of RxLib named TRxQuery. It had a published property "macros" of type TParams, so you could write this sql Select * From Customers Where FieldX = 1 and (%extrafilter). After setting de sql property, in design time was added an item to macros with name 'extrafilter' of type string and initial value '(0=0)', In run time you could do: RxQuery1.Macros.ParamByName('extrafilter'):='(0=0)'; or RxQuery1.Macros.ParamByName('extrafilter'):='FieldY=:paramy'; (I think there was also a RxQuery1.MacroByName to shorten RxQuery1.Macros.ParamByName) When you prepared the sql, macros where expanded in the sql. The was also a property named RealSQL of TString, it was the sql statement after macro substitution. (I'm not sure if RealSQL was public or I modified the library to make it public) When you changed a macro it was like changing the sql. You needed to prepare again the query. It is not that different from saving the original sql string and replacing certain parts, (in fact, I have done things like that). But it was handy. -- Saludos Santiago A. svaa at ciberpiula.net From mailinglists at geldenhuys.co.uk Thu Apr 7 17:06:42 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 7 Apr 2016 16:06:42 +0100 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: <57065078.30207@geldenhuys.co.uk> Message-ID: <57067782.3030706@geldenhuys.co.uk> On 2016-04-07 13:47, Michael Thompson wrote: > This moves it up that list... I can give you many more reason to move it up even further. ;-) tiOPF is a treasure trove of goodies (for DB and non-DB projects). Regards, - Graeme - From luizamericop at gmail.com Thu Apr 7 17:30:17 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Thu, 7 Apr 2016 12:30:17 -0300 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: <57067782.3030706@geldenhuys.co.uk> References: <57065078.30207@geldenhuys.co.uk> <57067782.3030706@geldenhuys.co.uk> Message-ID: Thanks for all the responses The Marcos' one is particular interesting since goes in a direction a did not think earlier Luiz 2016-04-07 12:06 GMT-03:00 Graeme Geldenhuys : > On 2016-04-07 13:47, Michael Thompson wrote: > > This moves it up that list... > > I can give you many more reason to move it up even further. ;-) tiOPF is > a treasure trove of goodies (for DB and non-DB projects). > > Regards, > - Graeme - > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Thu Apr 7 17:41:40 2016 From: md at delfire.net (Marcos Douglas) Date: Thu, 7 Apr 2016 12:41:40 -0300 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: References: <57065078.30207@geldenhuys.co.uk> <57067782.3030706@geldenhuys.co.uk> Message-ID: On Thu, Apr 7, 2016 at 12:30 PM, Luiz Americo Pereira Camara wrote: > Thanks for all the responses > > The Marcos' one is particular interesting since goes in a direction a did > not think earlier Thanks. I do this for years. The major advantage, I think, is doesn't need to change the SQL in pieces. You can put the original SQL in a Query component or file integrally. The DBMS engine is smarter enough to optimize all that. Best regards, Marcos Douglas From mse00000 at gmail.com Thu Apr 7 17:53:53 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Thu, 7 Apr 2016 17:53:53 +0200 Subject: [fpc-pascal] Create dynamic SQL according to available params In-Reply-To: <57066CA0.10608@ciberpiula.net> References: <57066CA0.10608@ciberpiula.net> Message-ID: <201604071753.53616.mse00000@gmail.com> On Thursday 07 April 2016 16:20:16 Santiago A. wrote: > El 07/04/2016 a las 14:00, Luiz Americo Pereira Camara escribió: > > I enconter the following pattern frequently (simplified): > > > > SQL: > > Select * From Customers Where FieldX = 1 > > > > Later i need a similar query that uses a different filter like > > > > Select * From Customers Where FieldX = 1 and FieldY = :paramy > > I remember a component of RxLib named TRxQuery. It had a published > property "macros" of type TParams, so you could write this sql > > Select * From Customers Where FieldX = 1 and (%extrafilter). In MSEgui SQL properties are of type TSQLStringList. TSQLStringList has a property "Macros" which is an array of TSQLMacroItem. TSQLMacroItem.Value inherits from TSQLStringList, so it is possible to build a macro tree which items can be accessed by a name path (TMacroProperty.ItemByNames()). " select ${fields} from ${table} where ${filter} " in example http://mseide-msegui.sourceforge.net/pics/sqlmacros.png expands to " select FIELD1 from TABLE1 where FIELD1 = 'abc' " Martin From mailinglists at geldenhuys.co.uk Thu Apr 7 18:07:03 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 7 Apr 2016 17:07:03 +0100 Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 Message-ID: <570685A7.4060705@geldenhuys.co.uk> Hi, No my Win64 VM I have FPC 2.6.2 and 2.6.4 installed using the official FPC installers. For example: fpc-2.6.4.x86_64-win64.exe I wanted to upgrade my VM to FPC 3.0.0, but I don't seem to find an official Win64 release like prior versions. All I can find as a what I assume is a 32-bit cross-complier to win64: fpc-3.0.0.i386-win32.cross.x86_64-win64.exe Why did FPC stop making official native win64 compilers? Or is this just a naming convension change? ps: How do I know if a program (executable) is 32-bit or 64-bit under Windows? Using Unix-like OSes, I can simply use the "file" command. What is the equivalent under Windows? ps #2: Why doesn't the Free Pascal SourceForge page contain a "Win64" folder. The prior FPC releases, the native 64-bit installations are filed under the "Win32" folder. This seems a bit confusing. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From michael at freepascal.org Thu Apr 7 18:11:59 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 7 Apr 2016 18:11:59 +0200 (CEST) Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 In-Reply-To: <570685A7.4060705@geldenhuys.co.uk> References: <570685A7.4060705@geldenhuys.co.uk> Message-ID: On Thu, 7 Apr 2016, Graeme Geldenhuys wrote: > Hi, > > No my Win64 VM I have FPC 2.6.2 and 2.6.4 installed using the official > FPC installers. For example: fpc-2.6.4.x86_64-win64.exe > > I wanted to upgrade my VM to FPC 3.0.0, but I don't seem to find an > official Win64 release like prior versions. All I can find as a what I > assume is a 32-bit cross-complier to win64: > > fpc-3.0.0.i386-win32.cross.x86_64-win64.exe > > Why did FPC stop making official native win64 compilers? Or is this > just a naming convension change? The windows team doesn't think there are sufficient reasons/arguments for a 64-bit native compiler. (So, I roll my own. Luckily, this is not that hard) > ps: > How do I know if a program (executable) is 32-bit or 64-bit under > Windows? Using Unix-like OSes, I can simply use the "file" > command. What is the equivalent under Windows? Right-click in explorer, 'Properties', and then 'details' or so ? > > ps #2: > Why doesn't the Free Pascal SourceForge page contain a "Win64" folder. > The prior FPC releases, the native 64-bit installations are filed > under the "Win32" folder. This seems a bit confusing. See above. Michael. From mailinglists at geldenhuys.co.uk Thu Apr 7 18:21:10 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 7 Apr 2016 17:21:10 +0100 Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 In-Reply-To: References: <570685A7.4060705@geldenhuys.co.uk> Message-ID: <570688F6.1050603@geldenhuys.co.uk> On 2016-04-07 17:11, Michael Van Canneyt wrote: > > The windows team doesn't think there are sufficient reasons/arguments > for a 64-bit native compiler. Lazy buggers! ;-) > (So, I roll my own. Luckily, this is not that hard) I'll do the same, thanks. >> How do I know if a program (executable) is 32-bit or 64-bit under >> Windows? Using Unix-like OSes, I can simply use the "file" >> command. What is the equivalent under Windows? > > Right-click in explorer, 'Properties', and then 'details' or so ? Nope, that's the firs place I looked. I've got 64-bit Windows 7 installed. The "Properties -> Details" dialog list the file type, version, copyright etc... but nowhere does it say 32-bit or 64-bit. I can see the "*32" in the Windows Task Manager which indicates 32-bit or 64-bit applications. But that is only useful for long running apps.For very fast running applications (eg: many console utilities) it appears and disappears to quickly for me to see. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From d.ioannidis at nephelae.eu Thu Apr 7 20:38:15 2016 From: d.ioannidis at nephelae.eu (Dimitrios Chr. Ioannidis) Date: Thu, 07 Apr 2016 21:38:15 +0300 Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 In-Reply-To: <570685A7.4060705@geldenhuys.co.uk> References: <570685A7.4060705@geldenhuys.co.uk> Message-ID: <5b1f3ea1c052ebfc690216739d6ac90a@nephelae.eu> Hi Graeme, Στις 2016-04-07 19:07, Graeme Geldenhuys έγραψε: > How do I know if a program (executable) is 32-bit or 64-bit under > Windows? Using Unix-like OSes, I can simply use the "file" > command. What is the equivalent under Windows? you can use file ;) http://gnuwin32.sourceforge.net/packages/file.htm http://superuser.com/questions/103071/quick-way-to-tell-if-an-installed-application-is-64-bit-or-32-bit regards, -- Dimitrios Chr. Ioannidis From marcov at stack.nl Thu Apr 7 20:53:35 2016 From: marcov at stack.nl (Marco van de Voort) Date: Thu, 7 Apr 2016 20:53:35 +0200 (CEST) Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 In-Reply-To: <5b1f3ea1c052ebfc690216739d6ac90a@nephelae.eu> Message-ID: <20160407185335.E7AA073036@toad.stack.nl> In our previous episode, Dimitrios Chr. Ioannidis said: > ???? 2016-04-07 19:07, Graeme Geldenhuys ??????: > > How do I know if a program (executable) is 32-bit or 64-bit under > > Windows? Using Unix-like OSes, I can simply use the "file" > > command. What is the equivalent under Windows? > > you can use file ;) > > http://gnuwin32.sourceforge.net/packages/file.htm > > http://superuser.com/questions/103071/quick-way-to-tell-if-an-installed-application-is-64-bit-or-32-bit or PE Explorer iirc even some objdump builds (maybe even the ones that come with FPC) From jonas.maebe at elis.ugent.be Fri Apr 8 10:12:24 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Fri, 08 Apr 2016 10:12:24 +0200 Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 In-Reply-To: <570685A7.4060705@geldenhuys.co.uk> References: <570685A7.4060705@geldenhuys.co.uk> Message-ID: <20160408101224.Horde.QES-e0isJlFXB2foVkXihXA@mail.elis.ugent.be> Graeme Geldenhuys wrote on Thu, 07 Apr 2016: > I wanted to upgrade my VM to FPC 3.0.0, but I don't seem to find an > official Win64 release like prior versions. All I can find as a what I > assume is a 32-bit cross-complier to win64: > > fpc-3.0.0.i386-win32.cross.x86_64-win64.exe > > Why did FPC stop making official native win64 compilers? Or is this > just a naming convension change? It's a naming change: the previous Win64 releases were also cross-compilers. There is no advantage I'm a aware of to having a "native" Win64 release compiler, and there are disadvantages such as the inability to compile for any other x86-64 target (because the x87 fpu is deprecated for 64 bit on Windows). Jonas From mailinglists at geldenhuys.co.uk Fri Apr 8 10:32:44 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 09:32:44 +0100 Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 In-Reply-To: <20160408101224.Horde.QES-e0isJlFXB2foVkXihXA@mail.elis.ugent.be> References: <570685A7.4060705@geldenhuys.co.uk> <20160408101224.Horde.QES-e0isJlFXB2foVkXihXA@mail.elis.ugent.be> Message-ID: <57076CAC.7020804@geldenhuys.co.uk> On 2016-04-08 09:12, Jonas Maebe wrote: > > It's a naming change: the previous Win64 releases were also > cross-compilers. I have the installs (with unintall support) for 2.6.0 & 2.6.2 on my system, and they are both native Win64 compilers. I believe they are official installers. The 2.6.4 and 3.0.0 installers on SF.net are definitely cross-compilers. No matter, like Michael said, it is quite easy to build your own, which I did. > There is no advantage I'm a aware of to having a > "native" Win64 release compiler Well, at the moment you need to do two downloads & installs to get Win64 support. First you need to install the win32 compiler, then the win64 cross-compiler. But yes, I guess that is minor - how often does one install release compilers anyway. ;-) Thanks for the info though. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Fri Apr 8 10:40:12 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 09:40:12 +0100 Subject: [fpc-pascal] FPC releases for Win64 - 2.6.2 & 2.6.4 versus 3.0.0 In-Reply-To: References: <570685A7.4060705@geldenhuys.co.uk> Message-ID: <57076E6C.9020104@geldenhuys.co.uk> On 2016-04-07 17:11, Michael Van Canneyt wrote: > Right-click in explorer, 'Properties', and then 'details' or so ? I checked again, and you were on the right track. The easiest way, without installing another program or running the GNU "file" command, is just to right click on the file, choose Properties, and then go the the Compatibility tab. If there are no greyed out options and Windows XP and 9x modes are offered, it's 32-bit. If there are greyed out options and Vista is the earliest mode offered, it's 64-bit. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From svaa at ciberpiula.net Fri Apr 8 11:08:41 2016 From: svaa at ciberpiula.net (Santiago A.) Date: Fri, 8 Apr 2016 11:08:41 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui Message-ID: <57077519.2060902@ciberpiula.net> I know it is a dangerous question that can easily turn into a holly war, flame or whatever. But here it is. I have only used Lazarus or a general editor (usually Jedit, geany). Time ago I checked a little MSEgui and, well, I didn't go for it. In MSEgui I found fonts small and interface not very nice. Beside I found it a little confusing. Later I found that it could be compiled to make fonts bigger etc. The honest reality is that I didn't devote much time to evaluate it. That's the problem of frameworks: when you learn one you get a little married with it, there are always complains and quirks, but before divorce you want to be sure that where you are moving to is better that what you have now. Unfortunately, getting the pros and cons requires working with it some time. The first pro of MSEgui is that it is light. In fact, That is the main pro of any thing that is not lazarus. No just because it's lighter but because lighter usually means less complex and less bugs. Cons. The most important. It looks like Lazarus has more developers, so may be a better decision for the long term. The second is the RAD. The immediate two directions updates, from GUI to source and from source to GUI, is very handy. Any body has experience in both (or another IDE for FPC) and has his two cents? By the way, has anybody managed to debug strings.text or any property with a getter? -- Saludos Santi svaa at ciberpiula.net From dibo20 at wp.pl Fri Apr 8 11:54:37 2016 From: dibo20 at wp.pl (Krzysztof) Date: Fri, 8 Apr 2016 11:54:37 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <57077519.2060902@ciberpiula.net> References: <57077519.2060902@ciberpiula.net> Message-ID: I'm also learning MSEgui from a few weeks. It was very hard start but now I love it. First what you need understand is that it is not using any Qt, Gtk, WinAPI backend as Lazarus so you never get native OS look but of course you can imitate it with own style. Yes, MSEgui has styles engine. For example this is soft written in MSEgui: http://almin-soft.ru/index.php?multimedia/xelplayer/xelplayer-screenshots Here is demo of dark theme: http://s14.postimg.org/qrw8tgrwx/linux.png And default font size for all controls can be changed immedietaly at runtime: stockobjects.fonts[stf_default].height:= 30; They are pros and cons for Lazarus and MSEgui. I would not stuck to the one framework. You must calculate needs for your project and choose the one which fit From mailinglists at geldenhuys.co.uk Fri Apr 8 11:59:17 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 10:59:17 +0100 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <57077519.2060902@ciberpiula.net> References: <57077519.2060902@ciberpiula.net> Message-ID: <570780F5.8050400@geldenhuys.co.uk> On 2016-04-08 10:08, Santiago A. wrote: > Any body has experience in both (or another IDE for FPC) and has his two > cents? ps: It's MSEide - if you are refering to the IDE portion of the project. ;-) I switch between Lazarus and MSEide very frequently. Overall I prefer MSEide. Yes it's settings are different, but that doesn't mean bad. Don't let habits or what you are used to detract from trying something new. Once I got used to the MSEide way, I quite liked it a lot. Here is my list... Pros of MSEide: - better code templates - better debugging - import & export of project settings - macros (global and per project) - no use of "packages" - I found macros work much better for me. - it's really really fast. I also never install components in a IDE, so Lazarus Packages are of no use to me. - not too much automation. I fight more and more with Lazarus to try and disable automation that I don't want or like. Martin managed to strike the exact right balance between automated code generation, and the programmer doing what it loves - writing code. - Code navigation is not as fussy as Lazarus. eg: I have lots of code with include files in the head of the unit. From another project, Lazarus refuses to navigate that code. MSEide has no troubles. - It is very stable, and Martin is super fast at fixing things. Normally everything gets done the same day. I have no idea how he finds the time to manage that!! - Code Templates: Much better implemented than Lazarus. Separate files for each template (thus easy to share or update). Quick to configure or modify, and has all the features needed. - Very good cross-platform console output window support. No need to run apps in a separate console window, just to see output. The IDE does this for you across platforms and consistently. - Fantastic docking support. I can configure the IDE in seconds just the way I want - per project too. I like the small detached "control center" as Martin calls it - the main IDE window. Cons of MSEide - some quirky behaviour in the editor, but Martin has explain his reasoning for some - which actually makes perfect sense. - Minor: Yes by default fonts are small, but again it is done to fit as much on the screen as posible. Simply pass a command line parameter to the IDE to adjust any fonts - a simple fix. - No code-insight (or very limited). I think that's what it is called. Where you type for example a . and then get a list of available methods pop up. My work-around is to code with DocView help viewer permanently open on the side so I can quickly search for what I need. I can't evaluate the gui toolkit MSEgui, as I don't use that. Neither do I use LCL for that matter. Pros of Lazarus: - Everybody here loves Delphi. Lazarus copies Delphi, so many seem instantly at home and happy. I'm not a lemming. ;-) - Some like all the automation (code completion, auto indentation etc.) - Debugging is moving in the right direction, but I still don't think it's as good as MSEide. Cons of Lazarus: - Things break often. As the saying goes: "Too many hands in the pot". - Things change often. - Lazarus Packages. Recently I was told I don't understand them correctly. I simply don't like them (I used too). Compiler settings often differ in a package compared to the project itself. Sometimes changes in code in a package (especially if include files were used) are not detected on a recompile of the project doesn't trigger a recompile of the package in question. This happens often, and I waste a lot of time debugging something I should have to. Sometimes packages a recompiled for no reason. - I hate all the automation added to Lazarus. I fight for hours trying to disable some feature, and often can't find where... the settings are too complex and spread out over multiple screens. eg: In my one copy of Lazarus it still does seemingly random indentation or begin..end completion - often producing code I don't want. I still can't figure out where to disable that. - big toolbar buttons in every IDE window - wasting massive amounts of screen space. - LCL is inconsistent in feature between platforms. So I can't set up my IDE under Windows the same as I can under FreeBSD or Linux. For example I like my editor tabs on the right, and the tab text MUST be horizontal. This is not possible with LCL-Qt or LCL-Win. I'm sure spending more time I can add more items to each category. My advice. Try each one for a week at least. Ask questions if you don't understand. You can't evaluate something as complex as an IDE in a single day, or worse, just a couple of hours. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From rainerstratmann at t-online.de Fri Apr 8 12:27:07 2016 From: rainerstratmann at t-online.de (Rainer Stratmann) Date: Fri, 08 Apr 2016 12:27:07 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <57077519.2060902@ciberpiula.net> References: <57077519.2060902@ciberpiula.net> Message-ID: <1581241.81ul2ZPzHk@debian8inet> con of mside why I don't use it: The behaviour of the cursor on the end of the line. You cannot go behind the line as it is usual in almost every other editor. Martin says it is difficult to integrate which I find hard to understand. That behaviour of the cursor confuses me. The other editors are smarter in that way. And the editor is the most important thing you use when programming. Am Freitag, 8. April 2016, 11:08:41 schrieb Santiago A.: > I know it is a dangerous question that can easily turn into a holly > war, flame or whatever. But here it is. > > I have only used Lazarus or a general editor (usually Jedit, geany). > Time ago I checked a little MSEgui and, well, I didn't go for it. > In MSEgui I found fonts small and interface not very nice. Beside I > found it a little confusing. Later I found that it could be compiled to > make fonts bigger etc. > > The honest reality is that I didn't devote much time to evaluate it. > That's the problem of frameworks: when you learn one you get a little > married with it, there are always complains and quirks, but before > divorce you want to be sure that where you are moving to is better that > what you have now. Unfortunately, getting the pros and cons requires > working with it some time. > > The first pro of MSEgui is that it is light. > In fact, That is the main pro of any thing that is not lazarus. No just > because it's lighter but because lighter usually means less complex and > less bugs. > > Cons. The most important. It looks like Lazarus has more developers, so > may be a better decision for the long term. > The second is the RAD. The immediate two directions updates, from GUI to > source and from source to GUI, is very handy. > > Any body has experience in both (or another IDE for FPC) and has his two > cents? > > By the way, has anybody managed to debug strings.text or any property > with a getter? > > > -- > Saludos > > Santi > svaa at ciberpiula.net > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal From mailinglists at geldenhuys.co.uk Fri Apr 8 13:19:52 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 12:19:52 +0100 Subject: [fpc-pascal] FPC generated executables and digital signatures Message-ID: <570793D8.3000301@geldenhuys.co.uk> Hi, I don't visit Windows much, but was doing some testing on a Win7 VM. Every time I run my FPC generated executable I get a Security Warning dialog pop up and it mentions a "Unknown Publisher", and I have to then click the 'Run' button before my application runs. Does anybody know what is required to get rid of this Security Warning? Like I said, I don't know which much, and when I do us Windows, it's normally Win2000 which doesn't have this issue. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From dibo20 at wp.pl Fri Apr 8 13:33:35 2016 From: dibo20 at wp.pl (Krzysztof) Date: Fri, 8 Apr 2016 13:33:35 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <1581241.81ul2ZPzHk@debian8inet> References: <57077519.2060902@ciberpiula.net> <1581241.81ul2ZPzHk@debian8inet> Message-ID: 2016-04-08 12:27 GMT+02:00 Rainer Stratmann : > con of mside why I don't use it: > > The behaviour of the cursor on the end of the line. You cannot go behind the > line as it is usual in almost every other editor. Martin says it is difficult to > integrate which I find hard to understand. That behaviour of the cursor > confuses me. The other editors are smarter in that way. And the editor is the > most important thing you use when programming. I'm using MSEide only for design forms. For coding I'm still use Lazarus (with paths to MSEgui source) so I still can enjoy with Lazarus code completition, build modes etc. Double profit, light final GUI, fully functional Lazarus code editor From fiens at hotmail.com Fri Apr 8 13:34:33 2016 From: fiens at hotmail.com (Fred van Stappen) Date: Fri, 8 Apr 2016 13:34:33 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <1581241.81ul2ZPzHk@debian8inet> References: <57077519.2060902@ciberpiula.net>, <1581241.81ul2ZPzHk@debian8inet> Message-ID: > con of mside why I don't use it: > > The behaviour of the cursor on the end of the line. You cannot go behind the > line as it is usual in almost every other editor. Huh, what do you mean ? I do not feel any difference with other editors... The big plus, IMO, of MSEide is his weight. : less than 8 megas for the hole installed/working IDE ! Also MSEide has greatest debug features. And, because of the perfect assistive interface of MSEgui, there is a child of MSEide (https://github.com/fredvs/ideU) that makes MSEide the first and only IDE totally assisted. Maybe (once again IMO) the only con is that MSEide cannot deal with LCL projects. But I do not use LCL anymore, so, for me, it is not a problem. Fre;D -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcov at stack.nl Fri Apr 8 13:36:50 2016 From: marcov at stack.nl (Marco van de Voort) Date: Fri, 8 Apr 2016 13:36:50 +0200 (CEST) Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: <570793D8.3000301@geldenhuys.co.uk> Message-ID: <20160408113650.AD5F373036@toad.stack.nl> In our previous episode, Graeme Geldenhuys said: > Every time I run my FPC generated executable I get a Security Warning > dialog pop up and it mentions a "Unknown Publisher", and I have to then > click the 'Run' button before my application runs. > Does anybody know what is required to get rid of this Security Warning? Try chmls unblock Keep a backup of the .exe just in case. Or try to see if there is an "unblock" in the properties of the .EXE. If so it is because MSIE adds a note in a secondary stream that it is downloaded content from an untrusted zone. Your IE zone configuration might be a cause too. I've seen report that it sometimes also happens when copying of (non Windows hosted) shares, but haven't seen that confirmed. > Like I said, I don't know which much, and when I do us Windows, it's > normally Win2000 which doesn't have this issue. It started with XPsp2 IIRC. From mailinglists at geldenhuys.co.uk Fri Apr 8 13:39:45 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 12:39:45 +0100 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: References: <57077519.2060902@ciberpiula.net> <1581241.81ul2ZPzHk@debian8inet> Message-ID: <57079881.6070402@geldenhuys.co.uk> On 2016-04-08 12:34, Fred van Stappen wrote: > Maybe (once again IMO) the only con is that MSEide cannot deal with > LCL projects. Maybe not designing forms visually, but there is no problems in compiling LCL based projects with MSEide. In fact, I have done that many times before. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Fri Apr 8 13:44:48 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 12:44:48 +0100 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: <20160408113650.AD5F373036@toad.stack.nl> References: <20160408113650.AD5F373036@toad.stack.nl> Message-ID: <570799B0.2020200@geldenhuys.co.uk> On 2016-04-08 12:36, Marco van de Voort wrote: > Try ...snip... Thanks Marco, I'll give those a try. >> Like I said, I don't know which much, and when I do us Windows, it's >> normally Win2000 which doesn't have this issue. Wow, that reads terrible. My brain thought one thing, and my fingers typed another. :-/ More coffee is required! > It started with XPsp2 IIRC. Good to know, thanks. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From fiens at hotmail.com Fri Apr 8 13:51:06 2016 From: fiens at hotmail.com (Fred van Stappen) Date: Fri, 8 Apr 2016 13:51:06 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <57079881.6070402@geldenhuys.co.uk> References: <57077519.2060902@ciberpiula.net> <1581241.81ul2ZPzHk@debian8inet>, , <57079881.6070402@geldenhuys.co.uk> Message-ID: > > Maybe (once again IMO) the only con is that MSEide cannot deal with > > LCL projects. > > Maybe not designing forms visually, but there is no problems in > compiling LCL based projects with MSEide. In fact, I have done that many > times before. Oooops, I did not know that it was possible. So, I do not see any con... Fre;D -------------- next part -------------- An HTML attachment was scrubbed... URL: From mse00000 at gmail.com Fri Apr 8 14:17:39 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Fri, 8 Apr 2016 14:17:39 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: References: <57077519.2060902@ciberpiula.net> <1581241.81ul2ZPzHk@debian8inet> Message-ID: <201604081417.39202.mse00000@gmail.com> On Friday 08 April 2016 13:33:35 Krzysztof wrote: > > I'm using MSEide only for design forms. For coding I'm still use > Lazarus (with paths to MSEgui source) so I still can enjoy with > Lazarus code completition, build modes etc. Just a little hint: MSEide has "build modes". IIRC it had it even before Lazarus introduced them. Please ask on the MSEide+MSEgui mailinglist if you like to know how it works. http://news.gmane.org/gmane.comp.ide.mseide.user https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk Martin From pascaldragon at googlemail.com Fri Apr 8 14:35:20 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 8 Apr 2016 14:35:20 +0200 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: <570793D8.3000301@geldenhuys.co.uk> References: <570793D8.3000301@geldenhuys.co.uk> Message-ID: Am 08.04.2016 13:20 schrieb "Graeme Geldenhuys" < mailinglists at geldenhuys.co.uk>: > > Hi, > > I don't visit Windows much, but was doing some testing on a Win7 VM. > Every time I run my FPC generated executable I get a Security Warning > dialog pop up and it mentions a "Unknown Publisher", and I have to then > click the 'Run' button before my application runs. Do you mean an UAC elevation dialog (with a broad yellow bar at the top), thus asking you whether you can run with elevated right or a dialog that tells you that the executable has cone from a untrusted source? In the first case: Does your application need administrator privileges? If not, make sure that you don't have "install" or "setup" in the name and that in the Manifest the setting is "AsInvoker" (you can check the Lazarus IDE if you're using that). If it does require these... Well, that's by design then. Only thing you can do is to sign your application so that instead of "Unknown Publisher" it will show your own or your company's name, but code signing certificates are costly... In the second case: Your file either has a Alternate Data Stream (a NTFS feature) attached that marks it as coming from a insecure source. You need to remove the ADS (or simply uncheck the box) to solve this. I fathom that the "chmls unblock" from Marco does exactly that. Alternatively it could be that you execute your application from a network drive. I think there's a setting for that somewhere as well, but I don't know that right now... Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.caduto at gmail.com Fri Apr 8 14:51:14 2016 From: tony.caduto at gmail.com (Tony Caduto) Date: Fri, 8 Apr 2016 07:51:14 -0500 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: <570793D8.3000301@geldenhuys.co.uk> References: <570793D8.3000301@geldenhuys.co.uk> Message-ID: I only get that if I run the exe from a shared network drive on Windows 7 and up. Maybe your not enabling the manifest, the laz ide does it automatically for win32. On Apr 8, 2016 6:20 AM, "Graeme Geldenhuys" wrote: > Hi, > > I don't visit Windows much, but was doing some testing on a Win7 VM. > Every time I run my FPC generated executable I get a Security Warning > dialog pop up and it mentions a "Unknown Publisher", and I have to then > click the 'Run' button before my application runs. > > Does anybody know what is required to get rid of this Security Warning? > Like I said, I don't know which much, and when I do us Windows, it's > normally Win2000 which doesn't have this issue. > > Regards, > - Graeme - > > -- > fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal > http://fpgui.sourceforge.net/ > > My public PGP key: http://tinyurl.com/graeme-pgp > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Fri Apr 8 14:54:56 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 13:54:56 +0100 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: References: <570793D8.3000301@geldenhuys.co.uk> Message-ID: <5707AA20.6030604@geldenhuys.co.uk> On 2016-04-08 13:35, Sven Barth wrote: > > Do you mean an UAC elevation dialog (with a broad yellow bar at the top), No, see attached screenshot. It is weird. Only some applications seem to pop up with this dialog, others don't. This specific app doesn't require admin privileges, and doesn't use NTFS features. It's the test app for fcl-pdf, included in FPC Trunk. In this case it is a console application. On Win2000 if I double click on it, it will pop up with a console window, execute the app, then close the console window. No warning dialogs. With Win7 it immediately pops up with this warning dialog and I have to click Run first for the application runs. I need to do some more testing to see if I can find a pattern. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot1.png Type: image/png Size: 7809 bytes Desc: not available URL: From mailinglists at geldenhuys.co.uk Fri Apr 8 15:01:35 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 14:01:35 +0100 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: References: <570793D8.3000301@geldenhuys.co.uk> Message-ID: <5707ABAF.5030109@geldenhuys.co.uk> On 2016-04-08 13:51, Tony Caduto wrote: > I only get that if I run the exe from a shared network drive on Windows 7 > and up. Ha, that was the problem! My Win7 is a VirtualBox VM, and my source code is on a VirtualBox shared folder (mapped to a drive letter in Windows 7). If I copy that executable to the C: drive, then in runs without the warning dialog. What is the point of that? A drive letter is a drive letter. Why does it make a difference to Windows it that drive is local, or a network drive? At least now we found the cause of the problem. Thanks Tony. It least now I know this will not happen on every Windows system. Now to figure out a solution (eventually). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From tony.caduto at gmail.com Fri Apr 8 15:18:54 2016 From: tony.caduto at gmail.com (Tony Caduto) Date: Fri, 8 Apr 2016 08:18:54 -0500 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> Message-ID: Graeme, Glad to help, that's always annoyed me as well but have never had time to fully investigate it, I imagine it's due to a signing issue like you originally thought. If you find anything out let us know 😁 On Apr 8, 2016 8:01 AM, "Graeme Geldenhuys" wrote: On 2016-04-08 13:51, Tony Caduto wrote: > I only get that if I run the exe from a shared network drive on Windows 7 > and up. Ha, that was the problem! My Win7 is a VirtualBox VM, and my source code is on a VirtualBox shared folder (mapped to a drive letter in Windows 7). If I copy that executable to the C: drive, then in runs without the warning dialog. What is the point of that? A drive letter is a drive letter. Why does it make a difference to Windows it that drive is local, or a network drive? At least now we found the cause of the problem. Thanks Tony. It least now I know this will not happen on every Windows system. Now to figure out a solution (eventually). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp _______________________________________________ fpc-pascal maillist - fpc-pascal at lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibo20 at wp.pl Fri Apr 8 15:33:08 2016 From: dibo20 at wp.pl (Krzysztof) Date: Fri, 8 Apr 2016 15:33:08 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <201604081417.39202.mse00000@gmail.com> References: <57077519.2060902@ciberpiula.net> <1581241.81ul2ZPzHk@debian8inet> <201604081417.39202.mse00000@gmail.com> Message-ID: > Just a little hint: MSEide has "build modes". IIRC it had it even before > Lazarus introduced them. Please ask on the MSEide+MSEgui mailinglist if you > like to know how it works. > http://news.gmane.org/gmane.comp.ide.mseide.user > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk Yes, I know that. I'm already on that list :) . I'm just used to Lazarus build modes From obones at free.fr Fri Apr 8 15:39:30 2016 From: obones at free.fr (OBones) Date: Fri, 8 Apr 2016 15:39:30 +0200 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> Message-ID: <5707B492.2030105@free.fr> If the exe is unsigned, then Windows will complain everytime it is run. If it is signed with a fully resolved certificate (not a self created one), then it will show the publisher in the dialog and depending on your security settings will either ask you if you want to be asked the next time or not ask you at all. But this only works with paid for certificates that can trace back to one of the recognized CAs. Tony Caduto wrote: > > Graeme, > > Glad to help, that's always annoyed me as well but have never had time > to fully investigate it, I imagine it's due to a signing issue like > you originally thought. > If you find anything out let us know 😁 > > On Apr 8, 2016 8:01 AM, "Graeme Geldenhuys" > > > wrote: > > On 2016-04-08 13:51, Tony Caduto wrote: > > I only get that if I run the exe from a shared network drive on > Windows 7 > > and up. > > Ha, that was the problem! My Win7 is a VirtualBox VM, and my > source code > is on a VirtualBox shared folder (mapped to a drive letter in Windows > 7). If I copy that executable to the C: drive, then in runs > without the > warning dialog. > > What is the point of that? A drive letter is a drive letter. Why > does it > make a difference to Windows it that drive is local, or a network > drive? > > At least now we found the cause of the problem. Thanks Tony. It least > now I know this will not happen on every Windows system. Now to figure > out a solution (eventually). > > Regards, > - Graeme - > > -- > fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal > http://fpgui.sourceforge.net/ > > My public PGP key: http://tinyurl.com/graeme-pgp > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal From tony.caduto at gmail.com Fri Apr 8 15:48:57 2016 From: tony.caduto at gmail.com (Tony Caduto) Date: Fri, 8 Apr 2016 08:48:57 -0500 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: <5707B492.2030105@free.fr> References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> <5707B492.2030105@free.fr> Message-ID: It only does that if the exe is executed from a location windows deems unsafe. Even on Windows 10 my laz exes work fine with no publisher warning but as soon as you try from a network mapped drive or a UNC location bam you get the warning. On Apr 8, 2016 8:39 AM, "OBones" wrote: > If the exe is unsigned, then Windows will complain everytime it is run. > If it is signed with a fully resolved certificate (not a self created > one), then it will show the publisher in the dialog and depending on your > security settings will either ask you if you want to be asked the next time > or not ask you at all. > > But this only works with paid for certificates that can trace back to one > of the recognized CAs. > > Tony Caduto wrote: > >> >> Graeme, >> >> Glad to help, that's always annoyed me as well but have never had time to >> fully investigate it, I imagine it's due to a signing issue like you >> originally thought. >> If you find anything out let us know 😁 >> >> On Apr 8, 2016 8:01 AM, "Graeme Geldenhuys" < >> mailinglists at geldenhuys.co.uk > >> wrote: >> >> On 2016-04-08 13:51, Tony Caduto wrote: >> > I only get that if I run the exe from a shared network drive on >> Windows 7 >> > and up. >> >> Ha, that was the problem! My Win7 is a VirtualBox VM, and my >> source code >> is on a VirtualBox shared folder (mapped to a drive letter in Windows >> 7). If I copy that executable to the C: drive, then in runs >> without the >> warning dialog. >> >> What is the point of that? A drive letter is a drive letter. Why >> does it >> make a difference to Windows it that drive is local, or a network >> drive? >> >> At least now we found the cause of the problem. Thanks Tony. It least >> now I know this will not happen on every Windows system. Now to figure >> out a solution (eventually). >> >> Regards, >> - Graeme - >> >> -- >> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal >> http://fpgui.sourceforge.net/ >> >> My public PGP key: http://tinyurl.com/graeme-pgp >> _______________________________________________ >> fpc-pascal maillist - fpc-pascal at lists.freepascal.org >> >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> >> >> >> _______________________________________________ >> fpc-pascal maillist - fpc-pascal at lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Fri Apr 8 16:02:17 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 15:02:17 +0100 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> <5707B492.2030105@free.fr> Message-ID: <5707B9E9.6000700@geldenhuys.co.uk> On 2016-04-08 14:48, Tony Caduto wrote: > It only does that if the exe is executed from a location windows deems > unsafe. I just noticed that if I run the executable from a console window (not Windows Explorer, Total Commander, Double Commander etc), then the prompt does not appear. We got to love Windows consistency. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mike.cornflake at gmail.com Fri Apr 8 16:12:04 2016 From: mike.cornflake at gmail.com (Michael Thompson) Date: Fri, 08 Apr 2016 14:12:04 +0000 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: <5707B9E9.6000700@geldenhuys.co.uk> References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> <5707B492.2030105@free.fr> <5707B9E9.6000700@geldenhuys.co.uk> Message-ID: On Fri, 8 Apr 2016 22:02 Graeme Geldenhuys wrote: > On 2016-04-08 14:48, Tony Caduto wrote: > > It only does that if the exe is executed from a location windows deems > > unsafe. > > I just noticed that if I run the executable from a console window (not > Windows Explorer, Total Commander, Double Commander etc), then the > prompt does not appear. We got to love Windows consistency. ;-) Thats hilarious :-) As you've worked out, this isn't an issue with the exe, it's the new security paradigm. To solve/workaround you need to let your windows know the network location is secure. From memory, internet option / security / trusted sites / add the ip of PC hosting the shared folder. Its somewhere around there. Why internet options? I guess MS thought that would be obvious :-) Every corporate environment I've been in recently have prevented users from adding trusted sites :-( Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Fri Apr 8 16:19:49 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 8 Apr 2016 15:19:49 +0100 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> <5707B492.2030105@free.fr> <5707B9E9.6000700@geldenhuys.co.uk> Message-ID: <5707BE05.9030808@geldenhuys.co.uk> On 2016-04-08 15:12, Michael Thompson wrote: > From memory, internet option / security / > trusted sites / Excellent, that did the trick - thanks! I ticked the "all network paths (UNCs)" option. I would never have found that option as I don't consider my local network as part of "Internet Options'. Oh well, that's just me. Regards, - Graeme - From mike.cornflake at gmail.com Fri Apr 8 16:20:33 2016 From: mike.cornflake at gmail.com (Michael Thompson) Date: Fri, 8 Apr 2016 22:20:33 +0800 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> <5707B492.2030105@free.fr> <5707B9E9.6000700@geldenhuys.co.uk> Message-ID: On 8 April 2016 at 22:12, Michael Thompson wrote: > As you've worked out, this isn't an issue with the exe, it's the new > security paradigm. To solve/workaround you need to let your windows know > the network location is secure. From memory, internet option / security / > trusted sites / add the ip of PC hosting the shared folder. Its somewhere > around there. Why internet options? I guess MS thought that would be > obvious :-) > > Forgot you're not a windows user. The Internet Options I'm referring to are available through either Internet Explorer, or through Control Panel. On the PC I'm currently I solved it the lazy way. Internet Options - Security - Local intranet - Set "Security level for this zone" to lowest possible level "low". Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.cornflake at gmail.com Fri Apr 8 16:24:14 2016 From: mike.cornflake at gmail.com (Michael Thompson) Date: Fri, 8 Apr 2016 22:24:14 +0800 Subject: [fpc-pascal] FPC generated executables and digital signatures In-Reply-To: <5707BE05.9030808@geldenhuys.co.uk> References: <570793D8.3000301@geldenhuys.co.uk> <5707ABAF.5030109@geldenhuys.co.uk> <5707B492.2030105@free.fr> <5707B9E9.6000700@geldenhuys.co.uk> <5707BE05.9030808@geldenhuys.co.uk> Message-ID: On 8 April 2016 at 22:19, Graeme Geldenhuys wrote: > Excellent, that did the trick - thanks! I ticked the "all network paths > (UNCs)" option. I would never have found that option as I don't > consider my local network as part of "Internet Options'. Oh well, that's > just me. No, it's not just you. For lots of us it was part of the horrible learning curve that was Vista. While people will tell you later Windows are better (and by and large they're right), IMO most of the better is a combination of incremental betterness and "we just got used to it". We still live with silly decisions from that era. Office Ribbons! Arrrgggghhhhhh :-) Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Fri Apr 8 20:22:09 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 8 Apr 2016 20:22:09 +0200 (CEST) Subject: [fpc-pascal] PDF generator: please test Message-ID: Hello, Graeme has fixed a number of errors that should hopefully solve the problems with codepages; Changes have been tested on windows/linux/bsd but on Windows only with a system that has an english locale. These changes have been committed to FPC svn. (rev 33453) We would appreciate it if someone could test the PDF generating demo on a Windows with non-english locale, and report whether the first page of the generated PDF looks OK. Michael. From anthony at unihedron.com Fri Apr 8 17:08:08 2016 From: anthony at unihedron.com (Anthony Tekatch) Date: Fri, 8 Apr 2016 11:08:08 -0400 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <57077519.2060902@ciberpiula.net> References: <57077519.2060902@ciberpiula.net> Message-ID: <20160408110808.3a6a901c@pino.pino.basement> On Fri, 8 Apr 2016 11:08:41 +0200, "Santiago A." wrote: > Cons. The most important. It looks like Lazarus has more developers, so > may be a better decision for the long term. > The second is the RAD. The immediate two directions updates, from GUI to > source and from source to GUI, is very handy. Can MSEgui/MSEide be used to make programs for Mac OSX ? I could not find notes for that on the website. From mschnell at lumino.de Fri Apr 8 12:51:18 2016 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 08 Apr 2016 12:51:18 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <57077519.2060902@ciberpiula.net> References: <57077519.2060902@ciberpiula.net> Message-ID: <57078D26.2080201@lumino.de> My very short list: Pro Lazarus: - The LCL is very compatible with the Delphi VCL and so you can easily port Delphi VCL applications to Linux (but for reasons I don't understand Delphi moved to Firemonkey). - On top of that there is a great number of rather compatible "widget types" that allow for easily porting such programs to multiple different OS and widget set variants. Pro MSE: - There is a "NoGui" "Widget" option out of the box, allowing for completely decent event driven programming (TTimer, Thread to mainthread signaling) with programs that run on (deeply embedded Linux-) systems with no widget set installed at all - Martin provides the "IFI" add-on that allows for remoting the GUI (designed in MSEIDE) of a program via (e.g.) TCP/IP. -Michael From rymg19 at gmail.com Fri Apr 8 21:09:22 2016 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 8 Apr 2016 14:09:22 -0500 Subject: [fpc-pascal] How do record variants without a field name? Message-ID: I posted this to Stack Overflow ( http://stackoverflow.com/questions/36504292/iso-pascal-record-variants-without-a-field-name), but it hasn't gotten any feedback. So, here I go... Free Pascal allows you to do this: type RPoint = Record Case Boolean of False : (X,Y,Z : Real); True : (R,theta,phi : Real); end; To construct it, you do: var p: RPoint; begin p.x := 1; end. There's one part I don't understand: what's the purpose of the Case Boolean part? I understand that you can do case MyVal: Boolean; then MyVal becomes the field selector. However, what is the purpose when there is no field selector, just a type? In addition, the ISO Pascal standard says: With each variant-part shall be associated a type designated the selector-type possessed by the variant-part . If the variant-selector of the variant-part contains a tag-field, or if the case-constant- list of each variant of the variant-part contains only one case-constant, then the selector-type shall be denoted by the tag-type, and each variant of the variant-part shall be associated with those values specified by the selector-type denoted by the case-constants of the case-constant-list of the variant . Otherwise, the selector-type possessed by the variant-part shall be a new ordinal-type that is constructed to possess exactly one value for each variant of the variant-part, and no others, and each such variant shall be associated with a distinct value of that type. I don't quite understand what the selector-type is and why it would be a new ordinal-type. Wouldn't the selector-type just be the type like in case Boolean of? And what does each case-constant-list having only one case-constant have to do with it? Thanks in advance! -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mse00000 at gmail.com Sat Apr 9 10:38:52 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Sat, 9 Apr 2016 10:38:52 +0200 Subject: [fpc-pascal] Lazarus vs MSEgui In-Reply-To: <20160408110808.3a6a901c@pino.pino.basement> References: <57077519.2060902@ciberpiula.net> <20160408110808.3a6a901c@pino.pino.basement> Message-ID: <201604091038.52451.mse00000@gmail.com> On Friday 08 April 2016 17:08:08 Anthony Tekatch wrote: > > Can MSEgui/MSEide be used to make programs for Mac OSX ? > Currently not. In case of OSX-X11 compatibility layer the effort probably is manageable. I would prefer a Quartz backend. Sponsors wanted! ;-) Martin From leledumbo_cool at yahoo.co.id Sat Apr 9 14:25:17 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Sat, 9 Apr 2016 05:25:17 -0700 (MST) Subject: [fpc-pascal] How do record variants without a field name? In-Reply-To: References: Message-ID: <1460204717177-5724868.post@n5.nabble.com> > I posted this to Stack Overflow (http://stackoverflow.com/questions/36504292/iso-pascal-record-variants-without-a-field-name), but it hasn't gotten any feedback There are 2 answers already ATM, so I won't add the 3rd one (hard to get upvote :p) > what's the purpose of the Case Boolean part? That's what makes variant record different from ordinary record. > I understand that you can do case MyVal: Boolean; then MyVal becomes the > field selector. However, what is the purpose when there is no field > selector, just a type? The same, it's useful when you have no need to check which variant is active ATM. I seldom do this, I always think the selector can be useful someday. > I don't quite understand what the selector-type is It's in the first sentence: "With each variant-part shall be associated a type designated the selector-type possessed by the variant-part." Just imagine there is this selector-type owned by variant-part, whose meaning is decided later because it depends on conditions explained afterwards. > why it would be a new ordinal-type because multiple constant values in the case-constant-list does not have a type yet, so it's a new ordinal type when used. > Wouldn't the selector-type just be the type like in case Boolean of? yes and no, see above. > And what does each case-constant-list having only one case-constant have > to do with it? When only one case-constant is used, there's no confusion, each of the constant will of course should be in the range of tag-type. Hence, no new type required to be constructed. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/How-do-record-variants-without-a-field-name-tp5724866p5724868.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From roward at mac.com Sat Apr 9 16:12:15 2016 From: roward at mac.com (Richard Ward) Date: Sat, 09 Apr 2016 10:12:15 -0400 Subject: [fpc-pascal] Class vs Object type In-Reply-To: References: Message-ID: <81203AD8-C759-46FB-9C56-48F117EB34EE@mac.com> <> > I use Class and Object data types frequently in my code. I like the fact > that Object data types can be used without first instantiating an > instance and it gets freed automatically. > > It has to be said that for more complex "objects" I always use a Class > type though. Also, Delphi compatibility (or their lack of Object type > support) is of no concern to me. > > Are there pros or cons to either? > When I first decided to explore OOP in FPC, I (as well as most others) discovered that FPC supported two different Object models and wondered the same. In those days I had some free time to explore and ended up creating a Free Pascal Wiki article : http://wiki.freepascal.org/Programming_Using_Objects Programming Using Objects - Free Pascal wiki Unfortunately I ran out of time and never got to the Class based version. I started out liking the Object model for exactly the same reason you state, due to the simpler overhead of not having to “worry” as much about memory leak and initialization coding. In short, I abandoned the Object model since most of the FPC support was for the Class model and mixing Class and Object models in the same code base can get confusing resulting in more types of bugs and increased time spent maintaining stuff. Also, there are other (sometimes subtle) differences in how the Object and Class models are implemented. For production code, my opinion is to avoid mixing models. There was an offshoot discussion about reference vs. value types and your original comment above seems to be a common general consensus that one gravitates towards value types for simple structures and class (reference) types for more complex information where “identity” aspects are considered. About two years ago, I decided I needed to learn another language and started exploring Ruby and Python. About 3 months after surveying those languages, Apple unveiled Swift and I decided I would bite the bullet and delve into it. If anyone wants to hear summaries of what I have learned, I would be happy to take a discussion over to FPC-other or private email. I mention my extended Swift dalliance here because one of the major internal dichotomies in the Swift language itself is reference vs value languages constructs superimposed with mutable and immutable keywords. You may find the following article helpful which discusses how to determine when to use value vs. reference types. It uses Swift examples but the analysis is generic. Should I use a Swift struct or a class? http://faq.sealedabstract.com/structs_or_classes/ -Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.cornflake at gmail.com Sat Apr 9 22:34:12 2016 From: mike.cornflake at gmail.com (Michael Thompson) Date: Sun, 10 Apr 2016 04:34:12 +0800 Subject: [fpc-pascal] Debug a getter (was Lazarus vs MSEgui) Message-ID: On 8 April 2016 at 17:08, Santiago A. wrote: > By the way, has anybody managed to debug strings.text or any property > with a getter? > I was hoping someone would answer this. I currently insert the equivalent of sHack := MyStrings.Text; into code, and watch that.... Means I have to know I want the value of that list before I start debugging... Ta Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Sun Apr 10 01:31:53 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 10 Apr 2016 00:31:53 +0100 Subject: [fpc-pascal] Debug a getter (was Lazarus vs MSEgui) In-Reply-To: References: Message-ID: <570990E9.8050702@geldenhuys.co.uk> On 2016-04-09 21:34, Michael Thompson wrote: > I was hoping someone would answer this. I currently insert the equivalent > of > sHack := MyStrings.Text; Yes, that is a shortcoming of using the GDB debugger. Currently querying a result of property Getter function is not possible with GDB. You have to store the property result in a variable. Then later delete all such references after debugging (or use your SCM to revert such code changes). Using GDB has many other shortcomings with the Object Pascal language too. So I often use alternative forms of debugging. 1) I use tiOPF's tiLog unit and can output debug info to Console or File, or what I use most frequent, to a non-Modal GUI window. All logging is cached and happens in a separate thread so doesn't slow down the application. 2) fpGUI contains a modified dbgintf.pp unit, compared to the one included with FPC. I've also written my own GUI Debug Server, also included with fpGUI. So I can log color values and actually see the color in the debug server. I can use "live view" which can show me for example very frequently updated valuese (eg: mouse pointer position) but doesn't cause the debug server content to scroll off screen. 3) I believe there is a Lazarus based debug viewer similar to (2) above. I think I saw some info on that on the wiki once. I can't remember the name though. Mostly I use tiOPF's logging though (it doesn't require your code to be tiOPF based). I have many code templates set up in my IDE, so adding debug lines (wrapped in debug IFDEFs) are only 3-4 key presses away. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From fpc at mfriebe.de Sun Apr 10 03:02:29 2016 From: fpc at mfriebe.de (Martin) Date: Sun, 10 Apr 2016 02:02:29 +0100 Subject: [fpc-pascal] Debug a getter (was Lazarus vs MSEgui) In-Reply-To: References: Message-ID: <5709A625.6060809@mfriebe.de> On 09/04/2016 21:34, Michael Thompson wrote: > On 8 April 2016 at 17:08, Santiago A. > wrote: > > By the way, has anybody managed to debug strings.text or any property > with a getter? > > > I was hoping someone would answer this. I currently insert the > equivalent of > sHack := MyStrings.Text; > > into code, and watch that.... Means I have to know I want the value > of that list before I start debugging... > getters are a long way to go still, and if the strings are involved, then even longer. 1) gdb does not support function calls to pascal 2) strings are managed, gdb does not know how to deal with them, if they are needed for function param or result. Special calls to string management are needed or memory will be leaked or corrupted 3) stabs, dwarf2 & 3 do not support encoding the above info 4) Due to 3 fpc can not make that info avail. (maybe later dwarf formats have it) But often you can find the private variable that holds the value, and watch this. In Lazarus use the debug INSPECTOR, you can double click any member variables, and go to nested objects etc. Once you found it copy it to watches. for stringlist you can get all individual strings (but not the text). tstringlist.flist.... somewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luizamericop at gmail.com Sun Apr 10 13:27:37 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Sun, 10 Apr 2016 08:27:37 -0300 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? Message-ID: I switched most of my SQL queries to use Params instead of formatting directly the SQL. But until now i havent figured a way to pass an array of values (mostly integers) to be used with IN operators. Example: SQL: Select * from Customer where Id in (:idlist) I need to query customers with Ids 1, 2 and 3 If i do ParamByName('idlist').AsString := '1,2,3'; will not work. Is there a way to accomplish this? Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From leledumbo_cool at yahoo.co.id Sun Apr 10 14:39:56 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Sun, 10 Apr 2016 05:39:56 -0700 (MST) Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: References: Message-ID: <1460291996483-5724874.post@n5.nabble.com> > But until now i havent figured a way to pass an array of values (mostly integers) to be used with IN operators. That, unfortunately, is not possible. It's a DBMS limitation, parameterized values are actually passed as is to DBMS. So there's nothing you can do unless you can convince DBMS maintainer to implement it. > Is there a way to accomplish this? No other way than direct formatting for now. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Sqldb-How-to-pass-an-array-of-values-as-a-param-to-be-used-with-SQL-IN-operator-tp5724873p5724874.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From tony.caduto at gmail.com Sun Apr 10 16:01:03 2016 From: tony.caduto at gmail.com (Tony Caduto) Date: Sun, 10 Apr 2016 09:01:03 -0500 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: <1460291996483-5724874.post@n5.nabble.com> References: <1460291996483-5724874.post@n5.nabble.com> Message-ID: Did you try putting quotes around the param ID in the sql query? in(":myparam") I am guessing it's the commas that are the problem. Sqlite will accept double qoutes as will MySQL postgres will not though. On Apr 10, 2016 7:40 AM, "leledumbo" wrote: > > But until now i havent figured a way to pass an array of values (mostly > integers) to be used with IN operators. > > That, unfortunately, is not possible. It's a DBMS limitation, parameterized > values are actually passed as is to DBMS. So there's nothing you can do > unless you can convince DBMS maintainer to implement it. > > > Is there a way to accomplish this? > > No other way than direct formatting for now. > > > > > -- > View this message in context: > http://free-pascal-general.1045716.n5.nabble.com/Sqldb-How-to-pass-an-array-of-values-as-a-param-to-be-used-with-SQL-IN-operator-tp5724873p5724874.html > Sent from the Free Pascal - General mailing list archive at Nabble.com. > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hnb.code at gmail.com Sun Apr 10 20:10:17 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Sun, 10 Apr 2016 20:10:17 +0200 Subject: [fpc-pascal] FPC 3.0.0 and constref default param In-Reply-To: References: Message-ID: 2016-03-28 17:49 GMT+02:00 Krzysztof : > This code worked fine on FPC 2.6.4: > > procedure Test(constref AParam: String = 'def_param'); > begin > writeln(AParam); > end; > > But on FPC 3.0.0 I get error: > > unit1.pas(30,42) Error: Default values can only be specified for > value, const and constref parameters > I can confirm. Seems like is worth to put this on bugtracker :) -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibo20 at wp.pl Sun Apr 10 20:30:00 2016 From: dibo20 at wp.pl (Krzysztof) Date: Sun, 10 Apr 2016 20:30:00 +0200 Subject: [fpc-pascal] FPC 3.0.0 and constref default param In-Reply-To: References: Message-ID: > I can confirm. Seems like is worth to put this on bugtracker :) Reported here: http://bugs.freepascal.org/view.php?id=29992 From pontiac76 at gmail.com Sun Apr 10 20:39:03 2016 From: pontiac76 at gmail.com (Stephen Chrzanowski) Date: Sun, 10 Apr 2016 14:39:03 -0400 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: References: <1460291996483-5724874.post@n5.nabble.com> Message-ID: The problem with that Tony is that the the bind might make :myparam a string, so you'll be doing a 1-integer to 1-string comparison, which won't give you any results. Essentially you'll be asking for a list of results whos field is equal to "1,2,3,4", not a list of results in which the field in question contains the numbers 1, or 2, or 3, or 4. At OP Due to the nature of the bind mechanism, you won't be able to do it this way. The only way you'll be able to do that is with your program doing string substitution instead of doing the bind. Since you're dealing with integers only, you'll just need to make sure that every entry you're substituting for is actually an integer. On Sun, Apr 10, 2016 at 10:01 AM, Tony Caduto wrote: > Did you try putting quotes around the param ID in the sql query? > in(":myparam") > I am guessing it's the commas that are the problem. > > Sqlite will accept double qoutes as will MySQL postgres will not though. > On Apr 10, 2016 7:40 AM, "leledumbo" wrote: > >> > But until now i havent figured a way to pass an array of values (mostly >> integers) to be used with IN operators. >> >> That, unfortunately, is not possible. It's a DBMS limitation, >> parameterized >> values are actually passed as is to DBMS. So there's nothing you can do >> unless you can convince DBMS maintainer to implement it. >> >> > Is there a way to accomplish this? >> >> No other way than direct formatting for now. >> >> >> >> >> -- >> View this message in context: >> http://free-pascal-general.1045716.n5.nabble.com/Sqldb-How-to-pass-an-array-of-values-as-a-param-to-be-used-with-SQL-IN-operator-tp5724873p5724874.html >> Sent from the Free Pascal - General mailing list archive at Nabble.com. >> _______________________________________________ >> fpc-pascal maillist - fpc-pascal at lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luizamericop at gmail.com Sun Apr 10 20:49:42 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Sun, 10 Apr 2016 15:49:42 -0300 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: References: <1460291996483-5724874.post@n5.nabble.com> Message-ID: 2016-04-10 11:01 GMT-03:00 Tony Caduto : > Did you try putting quotes around the param ID in the sql query? > in(":myparam") > I am guessing it's the commas that are the problem. > Its the other way around the problem is the quotes See the attached app. When using Select * from Test where Id in (1,3) it works but using Select * from Test where Id in (:idlist) and doing the param binding does not work because is translated into: Select * from Test where Id in ('1,3') Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: project1.lpr Type: application/octet-stream Size: 1409 bytes Desc: not available URL: From luizamericop at gmail.com Sun Apr 10 20:57:12 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Sun, 10 Apr 2016 15:57:12 -0300 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: References: <1460291996483-5724874.post@n5.nabble.com> Message-ID: 2016-04-10 15:39 GMT-03:00 Stephen Chrzanowski : > Due to the nature of the bind mechanism, you won't be able to do it this > way. The only way you'll be able to do that is with your program doing > string substitution instead of doing the bind. Since you're dealing with > integers only, you'll just need to make sure that every entry you're > substituting for is actually an integer. > > I'm afraid is really not possible. Some months ago i searched for a delphi solution and the proposed is the same as yours. I hoped that would exist some solution in fpc side. As a workaround, I just implemented pre processing the SQL with a regular expression to detect param binding inside in expression and replace the binding with the string without the quotes before passing to the query. The remaining issue is that open doors for SQL injection attacks. Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.caduto at gmail.com Sun Apr 10 21:29:02 2016 From: tony.caduto at gmail.com (Tony Caduto) Date: Sun, 10 Apr 2016 14:29:02 -0500 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: References: <1460291996483-5724874.post@n5.nabble.com> Message-ID: What about using a stored procedure to do it ? You could pass the list for the in as a string and handle it in the stored procedure. Of course that's no help if using sqlite or other that does not support stored procedures. On Apr 10, 2016 1:39 PM, "Stephen Chrzanowski" wrote: The problem with that Tony is that the the bind might make :myparam a string, so you'll be doing a 1-integer to 1-string comparison, which won't give you any results. Essentially you'll be asking for a list of results whos field is equal to "1,2,3,4", not a list of results in which the field in question contains the numbers 1, or 2, or 3, or 4. At OP Due to the nature of the bind mechanism, you won't be able to do it this way. The only way you'll be able to do that is with your program doing string substitution instead of doing the bind. Since you're dealing with integers only, you'll just need to make sure that every entry you're substituting for is actually an integer. On Sun, Apr 10, 2016 at 10:01 AM, Tony Caduto wrote: > Did you try putting quotes around the param ID in the sql query? > in(":myparam") > I am guessing it's the commas that are the problem. > > Sqlite will accept double qoutes as will MySQL postgres will not though. > On Apr 10, 2016 7:40 AM, "leledumbo" wrote: > >> > But until now i havent figured a way to pass an array of values (mostly >> integers) to be used with IN operators. >> >> That, unfortunately, is not possible. It's a DBMS limitation, >> parameterized >> values are actually passed as is to DBMS. So there's nothing you can do >> unless you can convince DBMS maintainer to implement it. >> >> > Is there a way to accomplish this? >> >> No other way than direct formatting for now. >> >> >> >> >> -- >> View this message in context: >> http://free-pascal-general.1045716.n5.nabble.com/Sqldb-How-to-pass-an-array-of-values-as-a-param-to-be-used-with-SQL-IN-operator-tp5724873p5724874.html >> Sent from the Free Pascal - General mailing list archive at Nabble.com. >> _______________________________________________ >> fpc-pascal maillist - fpc-pascal at lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > _______________________________________________ fpc-pascal maillist - fpc-pascal at lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -------------- next part -------------- An HTML attachment was scrubbed... URL: From luizamericop at gmail.com Sun Apr 10 21:38:58 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Sun, 10 Apr 2016 16:38:58 -0300 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: References: <1460291996483-5724874.post@n5.nabble.com> Message-ID: 2016-04-10 16:29 GMT-03:00 Tony Caduto : > What about using a stored procedure to do it ? You could pass the list > for the in as a string and handle it in the stored procedure. Of course > that's no help if using sqlite or other that does not support stored > procedures. > I'm working with multiple DB engines, so i try to avoid non standard syntax/features. My workaround is working fine, so no need to break this rule Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.caduto at gmail.com Sun Apr 10 21:42:43 2016 From: tony.caduto at gmail.com (Tony Caduto) Date: Sun, 10 Apr 2016 14:42:43 -0500 Subject: [fpc-pascal] Sqldb - How to pass an array of values as a param to be used with SQL IN operator? In-Reply-To: References: <1460291996483-5724874.post@n5.nabble.com> Message-ID: Well, I guess if there is no user input going into the query it's not a big dea,l of course if there is you should at least sanitize it to prevent injection. On Apr 10, 2016 2:39 PM, "Luiz Americo Pereira Camara" < luizamericop at gmail.com> wrote: > > > 2016-04-10 16:29 GMT-03:00 Tony Caduto : > >> What about using a stored procedure to do it ? You could pass the list >> for the in as a string and handle it in the stored procedure. Of course >> that's no help if using sqlite or other that does not support stored >> procedures. >> > > I'm working with multiple DB engines, so i try to avoid non standard > syntax/features. > My workaround is working fine, so no need to break this rule > > Luiz > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazofeifer at gmail.com Sun Apr 10 22:15:06 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Sun, 10 Apr 2016 17:15:06 -0300 Subject: [fpc-pascal] Implicit Operator Overloading In-Reply-To: References: Message-ID: 2016-03-07 3:53 GMT-03:00 Sven Barth : > Am 06.03.2016 22:09 schrieb "Mazola Winstrol" : > > > > Hello, > > > > Fpc: 3.0 > > > > Should the compiler to allow the definition of two operator overloading > with the same parameters and diferent result types? > > > > e.g: > > > > ==== code ==== > > > > TMyRecord record > > class operator Implicit(A: TMyRecord): Real; > > class operator Implicit(A: TMyRecord): Integer; > > end; > > > > ==== end ==== > > > > The code above doesn't compile. Error: function is already declared > Public/Forward operator. > > Would you please test with trunk? I thought I had fixed that... If it > doesn't work there either then please report as well. > > Regards, > Sven > > Tested with the trunk version of the build 2016/04/10 (i dont know the revision number. i used the fcup tool to build). It works. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Sun Apr 10 23:58:00 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Sun, 10 Apr 2016 23:58:00 +0200 Subject: [fpc-pascal] Implicit Operator Overloading In-Reply-To: References: Message-ID: Am 10.04.2016 22:15 schrieb "Mazola Winstrol" : > > 2016-03-07 3:53 GMT-03:00 Sven Barth : >> >> Am 06.03.2016 22:09 schrieb "Mazola Winstrol" : >> > >> > Hello, >> > >> > Fpc: 3.0 >> > >> > Should the compiler to allow the definition of two operator overloading with the same parameters and diferent result types? >> > >> > e.g: >> > >> > ==== code ==== >> > >> > TMyRecord record >> > class operator Implicit(A: TMyRecord): Real; >> > class operator Implicit(A: TMyRecord): Integer; >> > end; >> > >> > ==== end ==== >> > >> > The code above doesn't compile. Error: function is already declared Public/Forward operator. >> >> Would you please test with trunk? I thought I had fixed that... If it doesn't work there either then please report as well. >> >> Regards, >> Sven >> >> > > Tested with the trunk version of the build 2016/04/10 (i dont know the revision number. i used the fcup tool to build). It works. Thanks for the heads up. Then I need to find which revision fixed this and have that merged to 3.0.1... Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Mon Apr 11 22:33:55 2016 From: md at delfire.net (Marcos Douglas) Date: Mon, 11 Apr 2016 17:33:55 -0300 Subject: [fpc-pascal] fcl-pdf: Extracting a page... Message-ID: Hi, Is it possible read a PDF, extract a page and create a new one using the new fcl-pdf? If yes, could you send an example how I can do that? Regards, Marcos Douglas From mailinglists at geldenhuys.co.uk Mon Apr 11 22:45:08 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 11 Apr 2016 21:45:08 +0100 Subject: [fpc-pascal] fcl-pdf: Extracting a page... In-Reply-To: References: Message-ID: <570C0CD4.5030709@geldenhuys.co.uk> On 2016-04-11 21:33, Marcos Douglas wrote: > Is it possible read a PDF, extract a page and create a new one using > the new fcl-pdf? I'm sure it is possible - there are PDF-to-Text tools around. Is it possible with the current fcl-pdf code? No. The fcl-pdf was designed to work the other way.... take content (code, JSON etc) and create PDF's. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From md at delfire.net Mon Apr 11 22:52:15 2016 From: md at delfire.net (Marcos Douglas) Date: Mon, 11 Apr 2016 17:52:15 -0300 Subject: [fpc-pascal] fcl-pdf: Extracting a page... In-Reply-To: <570C0CD4.5030709@geldenhuys.co.uk> References: <570C0CD4.5030709@geldenhuys.co.uk> Message-ID: On Mon, Apr 11, 2016 at 5:45 PM, Graeme Geldenhuys wrote: > I'm sure it is possible - there are PDF-to-Text tools around. Is it > possible with the current fcl-pdf code? No. The fcl-pdf was designed to > work the other way.... take content (code, JSON etc) and create PDF's. Right. PDF-to-text is not an option because I need to extract the page with the same appearance as the original so I can't rewrite the page. Thanks for answer. Regards, Marcos Douglas From joshyfun at gmail.com Mon Apr 11 23:46:26 2016 From: joshyfun at gmail.com (=?UTF-8?Q?Jos=c3=a9_Mejuto?=) Date: Mon, 11 Apr 2016 23:46:26 +0200 Subject: [fpc-pascal] fcl-pdf: Extracting a page... In-Reply-To: References: <570C0CD4.5030709@geldenhuys.co.uk> Message-ID: <570C1B32.8050506@gmail.com> El 11/04/2016 a las 22:52, Marcos Douglas escribió: > On Mon, Apr 11, 2016 at 5:45 PM, Graeme Geldenhuys > wrote: >> I'm sure it is possible - there are PDF-to-Text tools around. Is it >> possible with the current fcl-pdf code? No. The fcl-pdf was designed to >> work the other way.... take content (code, JSON etc) and create PDF's. > > Right. > PDF-to-text is not an option because I need to extract the page with > the same appearance as the > original so I can't rewrite the page. Hello, Use qpdf: http://qpdf.sourceforge.net/files/qpdf-manual.html http://qpdf.sourceforge.net/files/qpdf-manual.html#ref.page-selection -- From md at delfire.net Tue Apr 12 15:10:34 2016 From: md at delfire.net (Marcos Douglas) Date: Tue, 12 Apr 2016 10:10:34 -0300 Subject: [fpc-pascal] fcl-pdf: Extracting a page... In-Reply-To: <570C1B32.8050506@gmail.com> References: <570C0CD4.5030709@geldenhuys.co.uk> <570C1B32.8050506@gmail.com> Message-ID: On Mon, Apr 11, 2016 at 6:46 PM, José Mejuto wrote: > Hello, > > Use qpdf: > > http://qpdf.sourceforge.net/files/qpdf-manual.html > http://qpdf.sourceforge.net/files/qpdf-manual.html#ref.page-selection That's what I need. Thank you! Regards, Marcos Douglas From silvioprog at gmail.com Wed Apr 13 02:42:49 2016 From: silvioprog at gmail.com (silvioprog) Date: Tue, 12 Apr 2016 21:42:49 -0300 Subject: [fpc-pascal] TStringHelper with SysUtils functions Message-ID: Hello, How do I use the TStringHelper with SysUtils functions? When I've tried to compile this code: === code === program Project1; {$mode objfpc}{$H+} uses SysUtils; begin WriteLn(ExtractFileExt(ParamStr(0)).Substring(1)); ReadLn; end. === /code === I've got: project1.lpr(9,39) Error: Illegal qualifier A possible fix would be changing the TStringHelper declaration from "TStringHelper = Type Helper for AnsiString" to "TStringHelper = Type Helper for string" keeping it Delphi compatible. Thank you! -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Tue Apr 12 09:52:06 2016 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 12 Apr 2016 09:52:06 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> Message-ID: <570CA926.4070609@lumino.de> On 04/04/2016 11:27 AM, Juha Manninen wrote: > Just use the new UTF-8 mode provided by Lazarus and remove all > explicit conversion functions. > http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus I just did some tests and it seems that TStringList (this is what Tobias is concerned about) (with the Lazarus installation straight from the svn) seemingly always uses UTF8. Is this correct ? -Michael From dhkblaszyk at zeelandnet.nl Tue Apr 12 14:12:43 2016 From: dhkblaszyk at zeelandnet.nl (Darius Blaszyk) Date: Tue, 12 Apr 2016 14:12:43 +0200 Subject: [fpc-pascal] TP lex change input buffer Message-ID: <2808a1c32d06cb390ddfbc3c746c6601@zeelandnet.nl> Hi, I'm using TP lex in my application and I would like to change the input buffer from using files to (memory) strings. What is the supposed way to do this? Currently I have made a local copy of lexlib and modified the get_char (and friends) routine. However this does not seem to be the ideal way to do it, although the comments in lexlib seem to indicate otherwise. Regards, Darius -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Wed Apr 13 09:04:51 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 13 Apr 2016 09:04:51 +0200 (CEST) Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <570CA926.4070609@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> Message-ID: On Tue, 12 Apr 2016, Michael Schnell wrote: > On 04/04/2016 11:27 AM, Juha Manninen wrote: >> Just use the new UTF-8 mode provided by Lazarus and remove all explicit >> conversion functions. >> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus > I just did some tests and it seems that TStringList (this is what Tobias is > concerned about) (with the Lazarus installation straight from the svn) > seemingly always uses UTF8. > > Is this correct ? No. It uses the DefaultSystemcodepage. If the system codepage is UTF8, then it will use UTF8. Michael. From leledumbo_cool at yahoo.co.id Wed Apr 13 19:31:17 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Wed, 13 Apr 2016 10:31:17 -0700 (MST) Subject: [fpc-pascal] TP lex change input buffer In-Reply-To: <2808a1c32d06cb390ddfbc3c746c6601@zeelandnet.nl> References: <2808a1c32d06cb390ddfbc3c746c6601@zeelandnet.nl> Message-ID: <1460568677335-5724895.post@n5.nabble.com> > I'm using TP lex in my application and I would like to change the input buffer from using files to (memory) strings. What is the supposed way to do this? >From the comments: "The variables yyinput and yyoutput are the text files which are used by the lexical analyzer. By default, they are assigned to standard input and output, but you may change these assignments to fit your target application (use the Turbo Pascal standard routines assign, reset, and rewrite for this purpose)." Thankfully, we also have: http://www.freepascal.org/docs-html/3.0.0/fcl/streamio/index.html Which can turn any TStream descendant into a TextFile. Just change Assign as in the comment above into AssignStream, everything else is totally the same. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/TP-lex-change-input-buffer-tp5724893p5724895.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From mazofeifer at gmail.com Wed Apr 13 20:48:47 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Wed, 13 Apr 2016 15:48:47 -0300 Subject: [fpc-pascal] Initialization in Shared Libraries Message-ID: Hello list, I writting a cross-platform shared library (.dll, .so). I need to initialize some global variables. As the free pascal doesn't support library events (PROCESS_ATTACH, PROCESS_DETACH), what is the correct to way to do this? best ragrds -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Wed Apr 13 20:52:27 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 13 Apr 2016 20:52:27 +0200 (CEST) Subject: [fpc-pascal] Initialization in Shared Libraries In-Reply-To: References: Message-ID: On Wed, 13 Apr 2016, Mazola Winstrol wrote: > Hello list, > > I writting a cross-platform shared library (.dll, .so). I need to > initialize some global variables. > > As the free pascal doesn't support library events (PROCESS_ATTACH, > PROCESS_DETACH), what is the correct to way to do this? It does, but it catches them in the system unit; I do not think they are exposed. Michael. From mazofeifer at gmail.com Wed Apr 13 20:56:26 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Wed, 13 Apr 2016 15:56:26 -0300 Subject: [fpc-pascal] Initialization in Shared Libraries In-Reply-To: References: Message-ID: 2016-04-13 15:52 GMT-03:00 Michael Van Canneyt : > > > On Wed, 13 Apr 2016, Mazola Winstrol wrote: > > Hello list, >> >> I writting a cross-platform shared library (.dll, .so). I need to >> initialize some global variables. >> >> As the free pascal doesn't support library events (PROCESS_ATTACH, >> PROCESS_DETACH), what is the correct to way to do this? >> > > It does, but it catches them in the system unit; I do not think they are > exposed. > > So, what is the correct way to initialize global variables? In a normal program i can use unit's initialization section or class constructors. But the documentation is not clear about the the case of shared libraries. regrds -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonas.maebe at elis.ugent.be Wed Apr 13 20:56:26 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Wed, 13 Apr 2016 20:56:26 +0200 Subject: [fpc-pascal] Initialization in Shared Libraries In-Reply-To: References: Message-ID: <570E965A.905@elis.ugent.be> Michael Van Canneyt wrote: > > > On Wed, 13 Apr 2016, Mazola Winstrol wrote: > >> I writting a cross-platform shared library (.dll, .so). I need to >> initialize some global variables. >> >> As the free pascal doesn't support library events (PROCESS_ATTACH, >> PROCESS_DETACH), what is the correct to way to do this? > > It does, but it catches them in the system unit; I do not think they are > exposed. And hence you can just initialise those variables in the initialization section of the library and finalize them (if necessary) in the finalization section of the library. Jonas From mazofeifer at gmail.com Wed Apr 13 21:30:42 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Wed, 13 Apr 2016 16:30:42 -0300 Subject: [fpc-pascal] Initialization in Shared Libraries In-Reply-To: <570E965A.905@elis.ugent.be> References: <570E965A.905@elis.ugent.be> Message-ID: 2016-04-13 15:56 GMT-03:00 Jonas Maebe : > > And hence you can just initialise those variables in the initialization > section of the library and finalize them (if necessary) in the finalization > section of the library. > > Thanks! Can i use class constructors in shared libraries? Does unit's initialization section and class constructors have the same behaviour in all platforms and the same when compared with a normal program? regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Wed Apr 13 21:48:11 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 13 Apr 2016 21:48:11 +0200 Subject: [fpc-pascal] Initialization in Shared Libraries In-Reply-To: References: <570E965A.905@elis.ugent.be> Message-ID: <570EA27B.9060401@googlemail.com> On 13.04.2016 21:30, Mazola Winstrol wrote: > 2016-04-13 15:56 GMT-03:00 Jonas Maebe >: > > > And hence you can just initialise those variables in the > initialization section of the library and finalize them (if > necessary) in the finalization section of the library. > > > Thanks! > > Can i use class constructors in shared libraries? Does unit's > initialization section and class constructors have the same behaviour in > all platforms and the same when compared with a normal program? Yes and mostly yes. The finalization sections might not be called in the context of the same thread as the initialization sections, because if the thread that does the last unload of the library (if it is dynamically loaded) then it's called in that thread's context. But other then that they behave the same as for normal programs. Regards, Sven From ryan at thealchemistguild.com Thu Apr 14 06:29:42 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 11:29:42 +0700 Subject: [fpc-pascal] A better way? Message-ID: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> The most annoying problem I have with Pascal currently is with circular unit dependanices and “global” classes that need to be referenced from many units. In other languages I would make a forward declaration of the class in one file then implement it in another file so that all files could reference the class. It’s maybe a symptom of a “bad" design but sometimes it’s just faster and easier so it’s a problem I have to fight Pascal to make it work. When I moved to FPC the solution I started using was this pattern below where I make an abstract class then override the methods I need in the global namespace within in the “main unit”. This is a bad hack to workaround a feature of the language but I wonder if there’s a better way. Does anyone have any ideas I could try? ======== "global” unit shared by many other units: type TSomeClassAbstract = class (TObject) procedure DoSomething; virtual; abstract; end; “main” unit which implements the class: type TSomeClass = class (TSomeClassAbstract) procedure DoSomething; override; end; Regards, Ryan Joseph From mschnell at lumino.de Wed Apr 13 09:40:16 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 13 Apr 2016 09:40:16 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> Message-ID: <570DF7E0.6060203@lumino.de> On 04/13/2016 09:04 AM, Michael Van Canneyt wrote: > > It uses the DefaultSystemcodepage. If the system codepage is UTF8, > then it will use UTF8. Thanks for the enlightenment. Am I right assuming that the DefaultSystemcodepage is determined when compiling the RTL and/or the compiler) ? (As the default code page for the type Strings is not dynamic, but a built-in setting.) So Lazarus (IDE/LCL) can't do anything about that, as it will not enforce re-building the compiler and/or the RTL. -Michael From mschnell at lumino.de Wed Apr 13 10:15:29 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 13 Apr 2016 10:15:29 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> Message-ID: <570E0021.9030303@lumino.de> On 04/13/2016 09:04 AM, Michael Van Canneyt wrote: > It uses the DefaultSystemcodepage. If the system codepage is UTF8, then > it will use UTF8. > (Sorry for replying yet another answer to the same message of yours) http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus says: > On the other hand a *String* is assumed at compile time to have > /DefaultSystemCodePage/ (CP_ACP). /DefaultSystemCodePage/ is defined > at run time, so the compiler conservatively assumes that /String/ and > /UTF8String/ have different encodings. So I was wrong assuming from your message that DefaultSystemcodepage is the default encoding for the type "String" (and with that for TStrings and with that for TSringList). Now I still don't know whether/how the default encoding for the type "String (which I still assume is defined when building the compiler) is depending on the arch/OS the compiler is built for. (I only tested on Linux and here it rather obviously is UTF8. I assume on Windows it's UTF16 for Delphi compatibility). -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Thu Apr 14 08:52:16 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 14 Apr 2016 08:52:16 +0200 (CEST) Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <570E0021.9030303@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> Message-ID: On Wed, 13 Apr 2016, Michael Schnell wrote: > On 04/13/2016 09:04 AM, Michael Van Canneyt wrote: >> It uses the DefaultSystemcodepage. If the system codepage is UTF8, then >> it will use UTF8. >> > (Sorry for replying yet another answer to the same message of yours) > > > http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus says: >> On the other hand a *String* is assumed at compile time to have >> /DefaultSystemCodePage/ (CP_ACP). /DefaultSystemCodePage/ is defined at run >> time, so the compiler conservatively assumes that /String/ and /UTF8String/ >> have different encodings. > > So I was wrong assuming from your message that DefaultSystemcodepage is the > default encoding for the type "String" (and with that for TStrings and with > that for TSringList). > > Now I still don't know whether/how the default encoding for the type "String > (which I still assume is defined when building the compiler) Your assumption is wrong. The default encoding for the string type is determined at run-time, not at compile time. Michael. From mailinglists at geldenhuys.co.uk Thu Apr 14 09:56:30 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 14 Apr 2016 08:56:30 +0100 Subject: [fpc-pascal] A better way? In-Reply-To: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> Message-ID: <570F4D2E.7000209@geldenhuys.co.uk> On 2016-04-14 05:29, Ryan Joseph wrote: > The most annoying problem I have with Pascal currently is with > circular unit dependanices and “global” If you can give an actual example we can help. I've used TP then Delphi and now Free Pascal for more than 20+ years. I can probably count on one hand how many circular reference issues I had. So I dont' think it is such a big problem as you make out. Often moving uses clause references from the Interface section to the Implementation section solve the problem. Sometimes using a base class in the interface works. Sometimes using Interfaces (the language feature) is a much better approach. So again, if you can give an actual example of the various units, and how they relate (use each other), then we might be able to help you further. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From tony.whyman at mccallumwhyman.com Thu Apr 14 10:02:37 2016 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Thu, 14 Apr 2016 09:02:37 +0100 Subject: [fpc-pascal] A better way? In-Reply-To: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> Message-ID: <570F4E9D.1020808@mccallumwhyman.com> Ryan, Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units from the "uses" clause in the "implementation" section and keeping the "uses" clauses in "interfaces" down to those references strictly necessary for the unit's interface. Having probably told you something you already know, i do sometimes get circular reference problems and usually because a program has evolved rather than having been designed properly. Sometimes it's better just to take as a hint to structure your program better but, otherwise, the techniques available are: 1. Abstract classes (as you suggest) 2. Interfaces 3. Dynamic casts. Of the three, dynamic casts are often the quick and dirty way of fixing the problem as they can allow you to move a problematic unit reference from the "interface uses" to the "implementation uses", replacing the class reference in the unit interface to something generic like "TObject" and them coercing it to the required class when you actually use it. I hope this helps. Regards Tony Whyman MWA On 14/04/16 05:29, Ryan Joseph wrote: > The most annoying problem I have with Pascal currently is with circular unit dependanices and “global” classes that need to be referenced from many units. In other languages I would make a forward declaration of the class in one file then implement it in another file so that all files could reference the class. It’s maybe a symptom of a “bad" design but sometimes it’s just faster and easier so it’s a problem I have to fight Pascal to make it work. > > When I moved to FPC the solution I started using was this pattern below where I make an abstract class then override the methods I need in the global namespace within in the “main unit”. This is a bad hack to workaround a feature of the language but I wonder if there’s a better way. Does anyone have any ideas I could try? > > ======== > > "global” unit shared by many other units: > > type > TSomeClassAbstract = class (TObject) > procedure DoSomething; virtual; abstract; > end; > > “main” unit which implements the class: > > type > TSomeClass = class (TSomeClassAbstract) > procedure DoSomething; override; > end; > > > Regards, > Ryan Joseph > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > From mazofeifer at gmail.com Thu Apr 14 10:07:00 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Thu, 14 Apr 2016 05:07:00 -0300 Subject: [fpc-pascal] Initialization in Shared Libraries In-Reply-To: <570EA27B.9060401@googlemail.com> References: <570E965A.905@elis.ugent.be> <570EA27B.9060401@googlemail.com> Message-ID: 2016-04-13 16:48 GMT-03:00 Sven Barth : > > Yes and mostly yes. The finalization sections might not be called in the > context of the same thread as the initialization sections, because if > the thread that does the last unload of the library (if it is > dynamically loaded) then it's called in that thread's context. But other > then that they behave the same as for normal programs. > > Thanks for the clarification! Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazofeifer at gmail.com Thu Apr 14 10:19:01 2016 From: mazofeifer at gmail.com (Mazola Winstrol) Date: Thu, 14 Apr 2016 05:19:01 -0300 Subject: [fpc-pascal] try..finally vs interfaces performance Message-ID: Recently i did some maintenance in a code of a colleague. I realized that he designed several classes with interface support so he do not need to protect the code blocks with try..finally to ensure that the instances are released from memory. Theoretically, which solution has higher performance? The traditional approach (code protected try..finally) or classes with interfaces (no need to protect the code. by otherside, classes with interfaces support have lock operations)? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Thu Apr 14 10:27:52 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 14 Apr 2016 09:27:52 +0100 Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: References: Message-ID: <570F5488.50501@geldenhuys.co.uk> On 2016-04-14 09:19, Mazola Winstrol wrote: > Theoretically, which solution has higher performance? Interesting question. As for the answer I have no idea. Why don't you put a quick test together. Loop the code 10,000 or 100,000 times and time the results. Please share your test code and answer if you don't mind. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From ryan at thealchemistguild.com Thu Apr 14 10:14:10 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 15:14:10 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <570F4E9D.1020808@mccallumwhyman.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4E9D.1020808@mccallumwhyman.com> Message-ID: <6BD09B47-E5E2-4016-92AD-509C1A02D2AE@thealchemistguild.com> > On Apr 14, 2016, at 3:02 PM, Tony Whyman wrote: > > Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units from the "uses" clause in the "implementation" section and keeping the "uses" clauses in "interfaces" down to those references strictly necessary for the unit's interface. I had no idea you could declare uses in the implementation! That could probably fix 90% of the problems I’m having which I’ve used abstract classes, dynamic method invocation and more recently interfaces to workaround. Don’t tell me this has been around for 20 years now I just never knew about it. ;) I should have asked sooner that’s for sure. Thanks! Regards, Ryan Joseph From michael at freepascal.org Thu Apr 14 10:50:22 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 14 Apr 2016 10:50:22 +0200 (CEST) Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: References: Message-ID: On Thu, 14 Apr 2016, Mazola Winstrol wrote: > Recently i did some maintenance in a code of a colleague. I realized that > he designed several classes with interface support so he do not need to > protect the code blocks with try..finally to ensure that the instances are > released from memory. > > Theoretically, which solution has higher performance? The traditional > approach (code protected try..finally) or classes with interfaces (no need > to protect the code. by otherside, classes with interfaces support have > lock operations)? > It should be exactly the same. As soon as interfaces are used the compiler inserts an implicit try...finally in a procedure. You can see this if you step through the code with GDB, the execution point will jump to the end of the procedure and then back to the beginning... Michael. From pascaldragon at googlemail.com Thu Apr 14 11:14:06 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 14 Apr 2016 11:14:06 +0200 Subject: [fpc-pascal] A better way? In-Reply-To: <6BD09B47-E5E2-4016-92AD-509C1A02D2AE@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4E9D.1020808@mccallumwhyman.com> <6BD09B47-E5E2-4016-92AD-509C1A02D2AE@thealchemistguild.com> Message-ID: Am 14.04.2016 10:45 schrieb "Ryan Joseph" : > > > > On Apr 14, 2016, at 3:02 PM, Tony Whyman wrote: > > > > Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units from the "uses" clause in the "implementation" section and keeping the "uses" clauses in "interfaces" down to those references strictly necessary for the unit's interface. > > I had no idea you could declare uses in the implementation! That could probably fix 90% of the problems I’m having which I’ve used abstract classes, dynamic method invocation and more recently interfaces to workaround. Don’t tell me this has been around for 20 years now I just never knew about it. ;) I should have asked sooner that’s for sure. When was Delphi 3 released? Before '96? In that case it would indeed be more than 20 years ;) Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at thealchemistguild.com Thu Apr 14 11:21:01 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 16:21:01 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <570F4D2E.7000209@geldenhuys.co.uk> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> Message-ID: > On Apr 14, 2016, at 2:56 PM, Graeme Geldenhuys wrote: > > If you can give an actual example we can help. I've used TP then Delphi > and now Free Pascal for more than 20+ years. I can probably count on one > hand how many circular reference issues I had. So I dont' think it is > such a big problem as you make out. > > Often moving uses clause references from the Interface section to the > Implementation section solve the problem. Sometimes using a base class > in the interface works. Sometimes using Interfaces (the language > feature) is a much better approach. > > So again, if you can give an actual example of the various units, and > how they relate (use each other), then we might be able to help you further. > > Regards, > Graeme I’ve just browsed over some code and found moving uses to the implementation did in fact help. That’s really helpful thank you both. However I’m still seeing some common patterns which just don’t seem Pascal friendly. I started using these more often after using Objective-C on Mac frequently and I really like it but it requires me to hack around the compiler in Pascal. In that example below the “main” class has children it talks to using an interface and returning a reference to itself for introspection. They are interdependent but Pascal doesn’t offer a way to expose a global namespace for both the units as far as I know. In other languages I would make another “globals” unit and keep forward references to TClassA, TClassB and IClassA. ============================== ClassB.pas: uses ClassA; // <----- circular reference but I need to know about ClassA type TClassB = class (IClassA) // when we implement this method we may need to know some things // about the parent (TClassA) so it must be included procedure ClassDidThis (parent: TClassA; action: integer); end; ClassA.pas: uses ClassB; type TClassA = class child: TClassB; end; // TClassA uses this interface to talk with it's “children” (TClassB) // and always returns a reference to itself because the children // often need to know about the parent also IClassA = interface procedure ClassDidThis (parent: TClassA; action: integer); end; Regards, Ryan Joseph From michael at freepascal.org Thu Apr 14 12:00:29 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 14 Apr 2016 12:00:29 +0200 (CEST) Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> Message-ID: On Thu, 14 Apr 2016, Ryan Joseph wrote: > >> On Apr 14, 2016, at 2:56 PM, Graeme Geldenhuys wrote: >> >> If you can give an actual example we can help. I've used TP then Delphi >> and now Free Pascal for more than 20+ years. I can probably count on one >> hand how many circular reference issues I had. So I dont' think it is >> such a big problem as you make out. >> >> Often moving uses clause references from the Interface section to the >> Implementation section solve the problem. Sometimes using a base class >> in the interface works. Sometimes using Interfaces (the language >> feature) is a much better approach. >> >> So again, if you can give an actual example of the various units, and >> how they relate (use each other), then we might be able to help you further. >> >> Regards, >> Graeme > > > I’ve just browsed over some code and found moving uses to the implementation did in fact help. That’s really helpful thank you both. However I’m still seeing some common patterns which just don’t seem Pascal friendly. I started using these more often after using Objective-C on Mac frequently and I really like it but it requires me to hack around the compiler in Pascal. > > In that example below the “main” class has children it talks to using an interface and returning a reference to itself for introspection. They are interdependent but Pascal doesn’t offer a way to expose a global namespace for both the units as far as I know. In other languages I would make another “globals” unit and keep forward references to TClassA, TClassB and IClassA. > > ============================== > > ClassB.pas: > > uses > ClassA; // <----- circular reference but I need to know about ClassA > > type > TClassB = class (IClassA) > // when we implement this method we may need to know some things > // about the parent (TClassA) so it must be included > procedure ClassDidThis (parent: TClassA; action: integer); > end; > > ClassA.pas: > > uses > ClassB; > > type > TClassA = class > child: TClassB; > end; You should not need TClassB here. You defeat the point of using an interface. Child : IClassA; should be sufficient. Michael. From ryan at thealchemistguild.com Thu Apr 14 11:32:16 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 16:32:16 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4E9D.1020808@mccallumwhyman.com> <6BD09B47-E5E2-4016-92AD-509C1A02D2AE@thealchemistguild.com> Message-ID: <59B2D80A-4E90-4B1F-8AC9-98A0FAFA300E@thealchemistguild.com> > On Apr 14, 2016, at 4:14 PM, Sven Barth wrote: > > When was Delphi 3 released? Before '96? In that case it would indeed be more than 20 years ;) I was using CodeWarrior back then (coming from a Mac background) and I didn’t switch to FPC until 2004 maybe. It would have been smart to learn about Delphi and new features but I just went ahead as normal missing lots of things that would help me in future years, like today for example. :) Regards, Ryan Joseph From ryan at thealchemistguild.com Thu Apr 14 12:35:14 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 17:35:14 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> Message-ID: <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> > On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt wrote: > > You should not need TClassB here. You defeat the point of using an > interface. I’m using the interface for specific communication I want denoted in the interface but I’m still typically using properties of the child class in addition to the interface. Offloading all properties to the interface would work but it would be making accessing them very cumbersome because it requires using Support instead of just accessing them directly. The interface was probably over complicating the example actually because the true problem is having this pattern of a parent->child relationship where both classes need to know about each other to some extent but putting them in the same unit causes clutter and pollution in other units namespaces. In this example it’s likely that many other units use TClassB and it’s not exclusive to TClassA so putting them in the same unit doesn’t make sense. Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. Regards, Ryan Joseph From tony.whyman at mccallumwhyman.com Thu Apr 14 12:51:18 2016 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Thu, 14 Apr 2016 11:51:18 +0100 Subject: [fpc-pascal] A better way? In-Reply-To: <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> Message-ID: <570F7626.3070305@mccallumwhyman.com> Ryan, > Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. Pascal does have forward declarations e.g. class TClassB; class TClassA private FClassBObject: TClassB; end; class TClassB ... end; Otherwise, if you really want to avoid defining interdependent classes in the same unit (not sure why you want to avoid this) then try this: unit unitA; interface type class TClassA private FClassBObject: TObject; public procedure SomeProc; end; implementation uses unitB; Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. procedure TClassA.SomeProc; begin TClassB(FClassBObject).OtherProc; end; end. unitB is pretty similar. As long as you make sure that FClassBObject really is a TClassB object when it is assigned, the above should all work. The only extra effort is with the TClassB(...) wrapper for each reference to FClassBObject. On 14/04/16 11:35, Ryan Joseph wrote: >> On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt wrote: >> >> You should not need TClassB here. You defeat the point of using an >> interface. > I’m using the interface for specific communication I want denoted in the interface but I’m still typically using properties of the child class in addition to the interface. Offloading all properties to the interface would work but it would be making accessing them very cumbersome because it requires using Support instead of just accessing them directly. > > The interface was probably over complicating the example actually because the true problem is having this pattern of a parent->child relationship where both classes need to know about each other to some extent but putting them in the same unit causes clutter and pollution in other units namespaces. In this example it’s likely that many other units use TClassB and it’s not exclusive to TClassA so putting them in the same unit doesn’t make sense. > > Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. > > Regards, > Ryan Joseph > > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > From michael at freepascal.org Thu Apr 14 13:09:34 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 14 Apr 2016 13:09:34 +0200 (CEST) Subject: [fpc-pascal] A better way? In-Reply-To: <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> Message-ID: On Thu, 14 Apr 2016, Ryan Joseph wrote: > >> On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt wrote: >> >> You should not need TClassB here. You defeat the point of using an >> interface. > > I’m using the interface for specific communication I want denoted in the > interface but I’m still typically using properties of the child class in > addition to the interface. Offloading all properties to the interface > would work but it would be making accessing them very cumbersome because > it requires using Support instead of just accessing them directly. So, put bluntly, you are unwilling to do things properly, and then complain that the language does not allow you to do this easily enough ? No, you need to do things properly. > > The interface was probably over complicating the example actually because > the true problem is having this pattern of a parent->child relationship > where both classes need to know about each other to some extent but > putting them in the same unit causes clutter and pollution in other units > namespaces. In this example it’s likely that many other units use TClassB > and it’s not exclusive to TClassA so putting them in the same unit doesn’t > make sense. It certainly does make sense, if they are so intertwined. This is not Java where you must put all classes in a single separate file. If classes are so intertwined that they need detailed knowledge of each other's property, put them in 1 unit. It is as simple as that. > > Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. Pascal has forward declarations. But only inside 1 unit. Michael. From ryan at thealchemistguild.com Thu Apr 14 14:27:23 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 19:27:23 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <570F7626.3070305@mccallumwhyman.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570F7626.3070305@mccallumwhyman.com> Message-ID: > On Apr 14, 2016, at 5:51 PM, Tony Whyman wrote: > > unit unitA; > > interface > > type > > class TClassA > private > FClassBObject: TObject; > public > procedure SomeProc; > end; > > implementation > > uses unitB; > > Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. > > > procedure TClassA.SomeProc; > begin > TClassB(FClassBObject).OtherProc; > end; > > end. > > unitB is pretty similar. > > As long as you make sure that FClassBObject really is a TClassB object when it is assigned, the above should all work. The only extra effort is with the TClassB(...) wrapper for each reference to FClassBObject. I use forward declarations sometimes but of course they need to be in the same block so they don’t solve this problem. Yeah type casting. :) Like interfaces they work but they add a significant overhead and clutter (especially if they need to be used with dozens of methods in a unit) so that’s why I’m seeing if there’s a better way. However I think I like your idea of using them in conjunction with the uses in the implementation instead of my "abstract class" solution. Thanks for the tip. Regards, Ryan Joseph From ryan at thealchemistguild.com Thu Apr 14 14:42:38 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 19:42:38 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> Message-ID: > On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt wrote: > > So, put bluntly, you are unwilling to do things properly, and then complain that the > language does not allow you to do this easily enough ? > > No, you need to do things properly. I thought that was probably the answer I’d get but I wanted to ask anyways. I get there’s a Pascal way but it’s making the job more difficult then it should be so I opt for the quick and easy hack. Maybe it’s bad form but at the end of the day I just want to make things work and get the job done instead of getting held up on small details. > >> >> The interface was probably over complicating the example actually because >> the true problem is having this pattern of a parent->child relationship >> where both classes need to know about each other to some extent but >> putting them in the same unit causes clutter and pollution in other units >> namespaces. In this example it’s likely that many other units use TClassB >> and it’s not exclusive to TClassA so putting them in the same unit doesn’t >> make sense. > > It certainly does make sense, if they are so intertwined. > > This is not Java where you must put all classes in a single separate file. > > If classes are so intertwined that they need detailed knowledge of each > other's property, put them in 1 unit. > > It is as simple as that. That would be a solution but it’s not very pretty. Having 2 classes in the same unit that need knowledge of each other but are still mutually exclusive is also bad design in my opinion. Why is it so terrible that classes could have forward declarations outside of a single block anyways? It seems like a practical and efficient solution that requires lots of extra work in design or typecasting/interfaces. Regards, Ryan Joseph From md at delfire.net Thu Apr 14 15:15:18 2016 From: md at delfire.net (Marcos Douglas) Date: Thu, 14 Apr 2016 10:15:18 -0300 Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: References: Message-ID: On Thu, Apr 14, 2016 at 5:19 AM, Mazola Winstrol wrote: > Recently i did some maintenance in a code of a colleague. I realized that he > designed several classes with interface support so he do not need to protect > the code blocks with try..finally to ensure that the instances are released > from memory. > > Theoretically, which solution has higher performance? The traditional > approach (code protected try..finally) or classes with interfaces (no need > to protect the code. by otherside, classes with interfaces support have lock > operations)? Hi, I don't know the answer but I think should be exactly the same. Even if not, I strongly recommend you to use interfaces instead "try-finally" approach because you gain more than just automatic memory release. Regards, Marcos Douglas PS. I have a blog about Object Pascal. I write about real object-oriented approach. The blog is written in Portuguese but using Google Translate I guess you won't have problems to translate. http://objectpascalprogramming.com/ From mailinglists at geldenhuys.co.uk Thu Apr 14 15:58:54 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 14 Apr 2016 14:58:54 +0100 Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: References: Message-ID: <570FA21E.50903@geldenhuys.co.uk> On 2016-04-14 14:15, Marcos Douglas wrote: > because you gain more than just automatic memory release. It is also worth noting that not all Interface usage means “automatic memory release”. If you use COM-style Interfaces, then yes you get memory management. If you use CORBA-style Interface, then no you don’t get memory management. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From md at delfire.net Thu Apr 14 16:17:43 2016 From: md at delfire.net (Marcos Douglas) Date: Thu, 14 Apr 2016 11:17:43 -0300 Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: <570FA21E.50903@geldenhuys.co.uk> References: <570FA21E.50903@geldenhuys.co.uk> Message-ID: On Thu, Apr 14, 2016 at 10:58 AM, Graeme Geldenhuys wrote: > On 2016-04-14 14:15, Marcos Douglas wrote: >> because you gain more than just automatic memory release. > > It is also worth noting that not all Interface usage means “automatic > memory release”. If you use COM-style Interfaces, then yes you get > memory management. If you use CORBA-style Interface, then no you don’t > get memory management. You're right, well remembered. I use only COM-style Interfaces. Regards, Marcos Douglas From michael at freepascal.org Thu Apr 14 16:25:31 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 14 Apr 2016 16:25:31 +0200 (CEST) Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> Message-ID: On Thu, 14 Apr 2016, Ryan Joseph wrote: > >> On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt wrote: >> >> So, put bluntly, you are unwilling to do things properly, and then complain that the >> language does not allow you to do this easily enough ? >> >> No, you need to do things properly. > > I thought that was probably the answer I’d get but I wanted to ask anyways. I get there’s a Pascal way but it’s making the job more difficult then it should be so I opt for the quick and easy hack. Maybe it’s bad form but at the end of the day I just want to make things work and get the job done instead of getting held up on small details. > >> >>> >>> The interface was probably over complicating the example actually because >>> the true problem is having this pattern of a parent->child relationship >>> where both classes need to know about each other to some extent but >>> putting them in the same unit causes clutter and pollution in other units >>> namespaces. In this example it’s likely that many other units use TClassB >>> and it’s not exclusive to TClassA so putting them in the same unit doesn’t >>> make sense. >> >> It certainly does make sense, if they are so intertwined. >> >> This is not Java where you must put all classes in a single separate file. >> >> If classes are so intertwined that they need detailed knowledge of each >> other's property, put them in 1 unit. >> >> It is as simple as that. > > That would be a solution but it’s not very pretty. Having 2 classes in the > same unit that need knowledge of each other but are still mutually > exclusive is also bad design in my opinion. Each is entitled to his opinion. Practical people use the tools at their disposal how they are meant to use. In this case the tool tells you that the 2 classes should be in 1 unit. So, you can waste your time looking for a way out, or just use the tool as it is meant. Michael. From ryan at thealchemistguild.com Thu Apr 14 16:46:42 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Thu, 14 Apr 2016 21:46:42 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> Message-ID: > On Apr 14, 2016, at 9:25 PM, Michael Van Canneyt wrote: > > In this case the tool tells you that the 2 classes should be in 1 unit. > So, you can waste your time looking for a way out, or just use the tool as > it is meant. I think I prefer using type casting or abstract classes more than mixing 2 mutually exclusive classes into one unit even though they may have dependancies on each other. Editing and navigating the files would be confusing for one since there’s no obvious name to use for the file now. Regards, Ryan Joseph From silvioprog at gmail.com Thu Apr 14 17:19:19 2016 From: silvioprog at gmail.com (silvioprog) Date: Thu, 14 Apr 2016 12:19:19 -0300 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? Message-ID: Hello, Is there any chance to add a class like Delphi's TStringBuilder to FCL? It would be very useful to port Delphi code libraries to Free Pascal. Thank you! -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From leledumbo_cool at yahoo.co.id Thu Apr 14 19:36:41 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Thu, 14 Apr 2016 10:36:41 -0700 (MST) Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: References: Message-ID: <1460655401784-5724928.post@n5.nabble.com> > Is there any chance to add a class like Delphi's TStringBuilder to FCL? It would be very useful to port Delphi code libraries to Free Pascal. That exists mainly to overcome the read-only, 0-based string implementation limitations in Delphi NextGen, doesn't it? Porting will still require 0-based string implementation, that class implementation alone won't be enough. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Any-chance-to-add-the-TStringBuilder-to-FCL-tp5724927p5724928.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From florian at freepascal.org Thu Apr 14 19:59:48 2016 From: florian at freepascal.org (=?UTF-8?Q?Florian_Kl=c3=a4mpfl?=) Date: Thu, 14 Apr 2016 19:59:48 +0200 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> Message-ID: <570FDA94.5080305@freepascal.org> Am 14.04.2016 um 16:25 schrieb Michael Van Canneyt: >> >> That would be a solution but it’s not very pretty. Having 2 classes in the >> same unit that need knowledge of each other but are still mutually >> exclusive is also bad design in my opinion. > > Each is entitled to his opinion. > > Practical people use the tools at their disposal how they are meant to use. > > In this case the tool tells you that the 2 classes should be in 1 unit. > So, you can waste your time looking for a way out, or just use the tool as > it is meant. > Or do it in two separate include files and add include both in the unit. FPC can do the C++ way :)))) From ewald at yellowcouch.org Thu Apr 14 20:23:21 2016 From: ewald at yellowcouch.org (Ewald) Date: Thu, 14 Apr 2016 20:23:21 +0200 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> Message-ID: <570FE019.9020409@yellowcouch.org> On 14/04/16 16:46, Ryan Joseph wrote: > I think I prefer using type casting or abstract classes more than mixing 2 mutually exclusive classes into one unit even though they may have dependancies on each other. Editing and navigating the files would be confusing for one since there’s no obvious name to use for the file now. Mutually exclusive classes are mutually exclusive to classes which have dependencies on one another ;-) Or am I missing something? -- Ewald From pascaldragon at googlemail.com Thu Apr 14 20:27:59 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 14 Apr 2016 20:27:59 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <1460655401784-5724928.post@n5.nabble.com> References: <1460655401784-5724928.post@n5.nabble.com> Message-ID: <570FE12F.1000905@googlemail.com> On 14.04.2016 19:36, leledumbo wrote: >> Is there any chance to add a class like Delphi's TStringBuilder to FCL? It > would be very useful to port Delphi code libraries to Free Pascal. > > That exists mainly to overcome the read-only, 0-based string implementation > limitations in Delphi NextGen, doesn't it? Porting will still require > 0-based string implementation, that class implementation alone won't be > enough. We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is used (it's a local switch). It works with Ansi-, Wide- and UnicodeString, but not with ShortString. The following example will print === output begin === l o === output end === === code begin === program tzerostr; {$H+} var s: String; begin s := 'Hello World'; Writeln(s[4]); {$ZeroBasedStrings On} Writeln(s[4]); end. === code end === Regards, Sven From vincent.snijders at gmail.com Thu Apr 14 22:13:25 2016 From: vincent.snijders at gmail.com (Vincent Snijders) Date: Thu, 14 Apr 2016 22:13:25 +0200 Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: References: Message-ID: 2016-04-14 10:50 GMT+02:00 Michael Van Canneyt : > > > On Thu, 14 Apr 2016, Mazola Winstrol wrote: > > Recently i did some maintenance in a code of a colleague. I realized that >> he designed several classes with interface support so he do not need to >> protect the code blocks with try..finally to ensure that the instances are >> released from memory. >> >> Theoretically, which solution has higher performance? The traditional >> approach (code protected try..finally) or classes with interfaces (no need >> to protect the code. by otherside, classes with interfaces support have >> lock operations)? >> >> > It should be exactly the same. As soon as interfaces are used the compiler > inserts an implicit try...finally in a procedure. > You can see this if you step through the code with GDB, the execution point > will jump to the end of the procedure and then back to the beginning... > > I would venture, that manually adding try finally would give you better performance than using interfaces at the cost of writing more code and therefore less clear and more error-prone source. If you use interfaces, the compiler also adds reference counting, which you don't have if you free the objects at the right places. It is not sure if you can measure the difference in performance though. Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From luizamericop at gmail.com Thu Apr 14 22:45:23 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Thu, 14 Apr 2016 17:45:23 -0300 Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: <570FA21E.50903@geldenhuys.co.uk> References: <570FA21E.50903@geldenhuys.co.uk> Message-ID: 2016-04-14 10:58 GMT-03:00 Graeme Geldenhuys : > On 2016-04-14 14:15, Marcos Douglas wrote: > > because you gain more than just automatic memory release. > > It is also worth noting that not all Interface usage means “automatic > memory release”. If you use COM-style Interfaces, then yes you get > memory management. Not necessarily, you can use COM interfaces with TComponent or other class that implements addref method but does not automatically frees the instance when refcount is zero Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Thu Apr 14 23:22:26 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 14 Apr 2016 22:22:26 +0100 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <570FE12F.1000905@googlemail.com> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> Message-ID: <57100A12.4040600@geldenhuys.co.uk> On 2016-04-14 19:27, Sven Barth wrote: > We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is > used (it's a local switch). Wow, learnt something new again. Never new that existed. I really should read the “what’s new” document. Regards, Graeme From mailinglists at geldenhuys.co.uk Thu Apr 14 23:24:21 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 14 Apr 2016 22:24:21 +0100 Subject: [fpc-pascal] try..finally vs interfaces performance In-Reply-To: References: <570FA21E.50903@geldenhuys.co.uk> Message-ID: <57100A85.2030300@geldenhuys.co.uk> On 2016-04-14 21:45, Luiz Americo Pereira Camara wrote: > other class > that implements addref method but does not automatically frees the instance > when refcount is zero I always considered that a bit of a hack. But yes, you are right. Regards, Graeme From pascaldragon at googlemail.com Fri Apr 15 00:10:22 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 00:10:22 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <57100A12.4040600@geldenhuys.co.uk> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> Message-ID: Am 14.04.2016 23:22 schrieb "Graeme Geldenhuys" < mailinglists at geldenhuys.co.uk>: > > On 2016-04-14 19:27, Sven Barth wrote: > > We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is > > used (it's a local switch). > > Wow, learnt something new again. Never new that existed. I really should > read the “what’s new” document. Seems like that wasn't added to the New Features 3.0.0 page anyway :/ Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at thealchemistguild.com Fri Apr 15 05:01:18 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 10:01:18 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <570FE019.9020409@yellowcouch.org> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FE019.9020409@yellowcouch.org> Message-ID: <622E0A3F-7262-437D-9648-2A5F356A3FBC@thealchemistguild.com> > On Apr 15, 2016, at 1:23 AM, Ewald wrote: > > Mutually exclusive classes are mutually exclusive to classes which have > dependencies on one another ;-) > > Or am I missing something? In the example I gave TClassB may be used by many other units but TClassA is only used with one other unit. TClassB is communicating with TClassA via interfaces but it’s still useful standalone and distinct in nature. This happens to me all the time actually where I need to expose some type information or an interface to both classes because I don’t want them merged. Regards, Ryan Joseph From juergen.hestermann at gmx.de Fri Apr 15 08:24:19 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Fri, 15 Apr 2016 08:24:19 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <57100A12.4040600@geldenhuys.co.uk> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> Message-ID: <57108913.9000604@gmx.de> Am 2016-04-14 um 23:22 schrieb Graeme Geldenhuys: > On 2016-04-14 19:27, Sven Barth wrote: >> We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is >> used (it's a local switch). > Wow, learnt something new again. Never new that existed. Me too. Though I will not use it. Is there also a switch {$OneBasedDynArrays On} ? I would love it. No more confusion about first and last element index. From mschnell at lumino.de Thu Apr 14 10:16:21 2016 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 14 Apr 2016 10:16:21 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> Message-ID: <570F51D5.3090109@lumino.de> On 04/14/2016 08:52 AM, Michael Van Canneyt wrote: > The default encoding for the string type is determined at run-time, > not at compile time. > How can that work for string constants ? Will they in fact (virtually) change their encoding when DefaultSystemcodepage is different ? For a test I did result := StringCodePage('äü'); This results in a 0 which is CP_ACP, which is supposed to mean "in fact its the value of DefaultSystemcodepage", which in my test in Linux is 65001 which means UTF8. Of course in this test it's correct. But if I start the executable in a system that imposes another value of DefaultSystemcodepage or if it is compiled in a way that results in the constant strings to be coded in another way than 65001, what will I see ? (Right now I don't have a Lazarus installation on Windows at hand). -Michael From michael at freepascal.org Fri Apr 15 08:35:40 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 15 Apr 2016 08:35:40 +0200 (CEST) Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <570F51D5.3090109@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> Message-ID: On Thu, 14 Apr 2016, Michael Schnell wrote: > On 04/14/2016 08:52 AM, Michael Van Canneyt wrote: >> The default encoding for the string type is determined at run-time, not at >> compile time. >> > How can that work for string constants ? Will they in fact (virtually) change > their encoding when DefaultSystemcodepage is different ? It depends. > > For a test I did result := StringCodePage('äü'); > > This results in a 0 which is CP_ACP, which is supposed to mean "in fact its > the value of DefaultSystemcodepage", which in my test in Linux is 65001 > which means UTF8. For string constants there are slightly different rules. There the result depends on the {$codepage} directive of the source file. See http://wiki.freepascal.org/FPC_Unicode_support > > Of course in this test it's correct. But if I start the executable in a > system that imposes another value of DefaultSystemcodepage or if it is > compiled in a way that results in the constant strings to be coded in another > way than 65001, what will I see ? (Right now I don't have a Lazarus > installation on Windows at hand). Again, see http://wiki.freepascal.org/FPC_Unicode_support Michael. From michael at freepascal.org Fri Apr 15 08:39:37 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 15 Apr 2016 08:39:37 +0200 (CEST) Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> Message-ID: On Fri, 15 Apr 2016, Sven Barth wrote: > Am 14.04.2016 23:22 schrieb "Graeme Geldenhuys" < > mailinglists at geldenhuys.co.uk>: >> >> On 2016-04-14 19:27, Sven Barth wrote: >>> We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is >>> used (it's a local switch). >> >> Wow, learnt something new again. Never new that existed. I really should >> read the “what’s new” document. > > Seems like that wasn't added to the New Features 3.0.0 page anyway :/ Even I didn't know we supported this. It's definitely not documented either. Michael. From ryan at thealchemistguild.com Fri Apr 15 08:15:28 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 13:15:28 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <570FDA94.5080305@freepascal.org> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> Message-ID: <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> I’ve cleaned up some code by declaring uses in the implementation and using generic untyped variables like TObject for parameters. This compiles but I’m left with lots of ugly type casting in the implementation because the parameters for methods are untyped. Yes it works but I feel like the compiler could be helping more. Just as an idea to float out here’s a suggestion for a “hint” syntax which would be used to solve the type casting issue by doing some dynamic typing. Sure you could put those all in file for this example but in the real world there may be dozens of TClassB subclasses which would make the unit 10,000’s of lines long and impossible to navigate. The other solution as mentioned would be to use $includes and still use the single unit approach (how reliable is this? I’ve never tried). Does this look like more work than using $includes? Maybe I need to seriously considering reorganizing my projects to work like this but it just feels wrong for some reason. ===================== unit Globals; interface type HClassB = 'TClassB'; // declare a hint to the class name implementation end. ===================== unit ClassB; interface uses ClassA; type TClassB = class procedure DoSomething (sender: TClassA); end; implementation procedure TClassB.DoSomething (sender: TClassA); begin // full access to TClassA end; end. ===================== unit ClassA; interface uses Globals; type TClassA = class // The interface section can't know about TClassB so we declare a // class name hint from Globals.pas (HClassB) and assign the paramter with it // using the "hint" syntax procedure SetValue (value: TObject[HClassB]); end; implementation // use ClassB now so hints evaluate uses ClassB; procedure TClassA.SetValue (value: TObject[HClassB]); begin // behind the scenes the compiler (or preparser if FPC has one) replaces the text "TObject[HClassB]" to “TClassB" or throws an error if the identifier TClassB is not found value.DoSomething(self); end; end. Regards, Ryan Joseph From mailinglists at geldenhuys.co.uk Fri Apr 15 10:32:55 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 15 Apr 2016 09:32:55 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <570F51D5.3090109@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> Message-ID: <5710A737.70903@geldenhuys.co.uk> On 2016-04-14 09:16, Michael Schnell wrote: > For a test I did result := StringCodePage('äü'); If you as a programmer knows the unit is saved in UTF-8 encoding, then add {$codepage utf8} to the top of the unit. That tells the compiler how to interpret string constants in that unit (without the need for any guessing). Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Fri Apr 15 10:24:05 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 15 Apr 2016 09:24:05 +0100 Subject: [fpc-pascal] A better way? In-Reply-To: <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> Message-ID: <5710A525.8050602@geldenhuys.co.uk> On 2016-04-15 07:15, Ryan Joseph wrote: > Sure you could put those all in file for this example but in the real > world there may be dozens of TClassB subclasses which would make the > unit 10,000’s of lines long and impossible to navigate. Big units have never been a problem to navigate for me. Years ago I've implemented the "procedure list" IDE add-on for Lazarus and Maximus. I can find locations in code in one or two seconds (however fast I can type). Procedure List (Alt+G) is now installed as standard with Lazarus IDE. Use bookmarks to jump between often used locations. Lazarus IDE includes a feature called Code Explorer, but I find Procedure List much faster. > The other > solution as mentioned would be to use $includes and still use the > single unit approach (how reliable is this? I’ve never tried). Yes, include files work very well (much better than in Delphi). Lazarus IDE knows how to handle include files very well to. So too does MSEide, but Lazarus has a few more tricks. The Free Pascal code (compiler and RTL) uses include files extensively. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From tony.whyman at mccallumwhyman.com Fri Apr 15 10:46:00 2016 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Fri, 15 Apr 2016 09:46:00 +0100 Subject: [fpc-pascal] A better way? In-Reply-To: <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> Message-ID: <5710AA48.8080709@mccallumwhyman.com> Ryan, If you want to get rid of (ugly) typecasts then maybe you should investigate the "absolute" keyword. You get a lot of examples in the LCL. For example, here's one I chose at random: function TGtk2WidgetSet.RawImage_CreateBitmaps(const ARawImage: TRawImage; out ABitmap, AMask: HBitmap; ASkipMask: boolean): boolean; var GdiObject: PGDIObject absolute ABitmap; GdiMaskObject: PGDIObject absolute AMask; Desc: TRawImageDescription absolute ARawImage.Description; .... You could describe it as typecast done in the var clause of a method. The right hand identifier is not restricted to function parameters. Regards Tony Whyman MWA On 15/04/16 07:15, Ryan Joseph wrote: > I’ve cleaned up some code by declaring uses in the implementation and using generic untyped variables like TObject for parameters. This compiles but I’m left with lots of ugly type casting in the implementation because the parameters for methods are untyped. Yes it works but I feel like the compiler could be helping more. > > > From mailinglists at geldenhuys.co.uk Fri Apr 15 10:26:51 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 15 Apr 2016 09:26:51 +0100 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <57108913.9000604@gmx.de> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> <57108913.9000604@gmx.de> Message-ID: <5710A5CB.8040904@geldenhuys.co.uk> On 2016-04-15 07:24, Jürgen Hestermann wrote: > Though I will not use it. Neither would I. I don't see the need for it. > Is there also a switch > {$OneBasedDynArrays On} ? > No more confusion about first and last element index. You really should be using low() and high() instead. ;-) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From pascaldragon at googlemail.com Fri Apr 15 10:51:21 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 10:51:21 +0200 Subject: [fpc-pascal] A better way? In-Reply-To: <5710AA48.8080709@mccallumwhyman.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> Message-ID: Am 15.04.2016 10:46 schrieb "Tony Whyman" : > > Ryan, > > If you want to get rid of (ugly) typecasts then maybe you should investigate the "absolute" keyword. You get a lot of examples in the LCL. For example, here's one I chose at random: > > function TGtk2WidgetSet.RawImage_CreateBitmaps(const ARawImage: TRawImage; out > ABitmap, AMask: HBitmap; ASkipMask: boolean): boolean; > var > GdiObject: PGDIObject absolute ABitmap; > GdiMaskObject: PGDIObject absolute AMask; > Desc: TRawImageDescription absolute ARawImage.Description; > .... > > > You could describe it as typecast done in the var clause of a method. The right hand identifier is not restricted to function parameters. While it works using "absolute" for a public API is rather unsafe (I'd only use that in private methods). In those cases the "as" operator should he used (or at least "is" plus returning an error). Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Fri Apr 15 10:56:26 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 10:56:26 +0200 Subject: [fpc-pascal] A better way? In-Reply-To: <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> Message-ID: Am 15.04.2016 08:46 schrieb "Ryan Joseph" : > Does this look like more work than using $includes? Maybe I need to seriously considering reorganizing my projects to work like this but it just feels wrong for some reason. > > ===================== > > unit Globals; > interface > > type > HClassB = 'TClassB'; // declare a hint to the class name > > implementation > end. > > ===================== > > unit ClassB; > interface > uses > ClassA; > > type > TClassB = class > procedure DoSomething (sender: TClassA); > end; > > implementation > > procedure TClassB.DoSomething (sender: TClassA); > begin > // full access to TClassA > end; > > end. > > ===================== > > unit ClassA; > interface > uses > Globals; > > type > TClassA = class > // The interface section can't know about TClassB so we declare a > // class name hint from Globals.pas (HClassB) and assign the paramter with it > // using the "hint" syntax > procedure SetValue (value: TObject[HClassB]); > end; > > implementation > > // use ClassB now so hints evaluate > uses > ClassB; > > procedure TClassA.SetValue (value: TObject[HClassB]); > begin > // behind the scenes the compiler (or preparser if FPC has one) replaces the text "TObject[HClassB]" to “TClassB" or throws an error if the identifier TClassB is not found > value.DoSomething(self); > end; > > end. *shudders* Before we introduce such syntax I'd prefer to get the formal class types that were added for Objective Pascal working with Object Pascal as well (which would be exactly what you want just with a more sane syntax). But again: you're currently fighting against the language. Use interfaces and abstract classes and overthink your dependencies and design. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Fri Apr 15 10:59:48 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 10:59:48 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <5710A5CB.8040904@geldenhuys.co.uk> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> <57108913.9000604@gmx.de> <5710A5CB.8040904@geldenhuys.co.uk> Message-ID: Am 15.04.2016 10:47 schrieb "Graeme Geldenhuys" < mailinglists at geldenhuys.co.uk>: > > Is there also a switch > > {$OneBasedDynArrays On} ? > > No more confusion about first and last element index. > > You really should be using low() and high() instead. ;-) Definitely (and they also work for strings now ;) - or at least low() does). Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From dec12 at avidsoft.com.hk Fri Apr 15 11:22:21 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Fri, 15 Apr 2016 17:22:21 +0800 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> Message-ID: <5710B2CD.8090908@avidsoft.com.hk> > > You could describe it as typecast done in the var clause of a > method. The right hand identifier is not restricted to function > parameters. > > While it works using "absolute" for a public API is rather unsafe (I'd > only use that in private methods). In those cases the "as" operator > should he used (or at least "is" plus returning an error). > > Regards, > Sven > > May I know why it is unsafe to use absolute on public method's parameters? Also, will there be any compiler options in which the parameters are passed through registers? In that case, will the absolute of private method's parameters still work? Dennis From ryan at thealchemistguild.com Fri Apr 15 11:00:11 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 16:00:11 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <5710AA48.8080709@mccallumwhyman.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> Message-ID: <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> > On Apr 15, 2016, at 3:46 PM, Tony Whyman wrote: > > You could describe it as typecast done in the var clause of a method. The right hand identifier is not restricted to function parameters. I’m not understanding how this would work. I’ve read that the keyword (I’ve never heard about until now) makes a variable share memory so it’s like an alias I guess. So, a common scenario is a member variable being declared as TObject then having to typecast it every time I need to access one of it’s methods. Declaring another variable in each function instead of typecasting is perhaps more work but maybe I’m not getting it. Thanks. Regards, Ryan Joseph From ryan at thealchemistguild.com Fri Apr 15 11:08:27 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 16:08:27 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> Message-ID: <1D8291F2-AFBD-41F9-9763-C573FDB18BD3@thealchemistguild.com> > On Apr 15, 2016, at 3:56 PM, Sven Barth wrote: > > *shudders* Before we introduce such syntax I'd prefer to get the formal class types that were added for Objective Pascal working with Object Pascal as well (which would be exactly what you want just with a more sane syntax). I agree 100%. Putting a class definition into the namespace of another unit and importing like Objective Pascal(c) does is preferable. There doesn’t seem to be much interest in the problem though. > > But again: you're currently fighting against the language. Use interfaces and abstract classes and overthink your dependencies and design. > Thanks to better usage of “uses” in the implementation I’ve learned now how to replace the abstract classes with weakly typed parameters and typecasting which is perhaps a small improvement because I don’t need to worry about extra classes and overriding etc… I’m happy with that but I’m still doing something the compiler could be helping with so I thought I’d mention it in the spirit of efficiency. :) The only question now is if using $ifdef’s and $includes to make large single units is preferable to typecasting ugliness. Thanks. Regards, Ryan Joseph From tony.whyman at mccallumwhyman.com Fri Apr 15 12:13:36 2016 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Fri, 15 Apr 2016 11:13:36 +0100 Subject: [fpc-pascal] A better way? In-Reply-To: <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> Message-ID: <5710BED0.10409@mccallumwhyman.com> On 15/04/16 10:00, Ryan Joseph wrote: > So, a common scenario is a member variable being declared as TObject then having to typecast it every time I need to access one of it’s methods. Declaring another variable in each function instead of typecasting is perhaps more work but maybe I’m not getting it. > > Thanks. Here's an update of my previous example. In this example, "absolute" is just a way of tidying up the code when you need to make multiple references to a variable that always has to have its type coerced. In the end though this is just a "what's in a name? A rose by any other name would smell as sweet" debate. No matter how you approach the problem, you have to have an identifier for the other class when you reference its methods and properties. If you don't want to declare two mutually referential classes in the same unit, then one of them (but only one) has to use some technique to avoid circular references. Type casting is a simple technique and you either have to coerce each use (think of TClassB(FObject) as just being a longer name for the same thing) or declare an alias of the correct type - a "With" statement can also be your friend here. It's not that big an overhead and when it comes to type casts a 'C' programmer would wonder what all the fuss was about. unit unitA; interface type class TClassA private FClassBObject: TObject; public procedure SomeProc; end; implementation uses unitB; procedure TClassA.SomeProc; var aClassBObject: TClassB absolute FClassBObject; begin aClassBObject.OtherProc; end; end. From tony.whyman at mccallumwhyman.com Fri Apr 15 12:34:16 2016 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Fri, 15 Apr 2016 11:34:16 +0100 Subject: [fpc-pascal] A better way? In-Reply-To: <5710BED0.10409@mccallumwhyman.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> <5710BED0.10409@mccallumwhyman.com> Message-ID: <5710C3A8.2010005@mccallumwhyman.com> Just remembered, FPC also supports macros - see http://www.freepascal.org/docs-html/prog/progse5.html I haven't tested it, but you should be able to do {$MACRO On} {$DEFINE aClassBObject:=TClassB(FClassBObject) } and then use aClassBObject instead of the coercion. On 15/04/16 11:13, Tony Whyman wrote: > In the end though this is just a "what's in a name? A rose by any > other name would smell as sweet" debate. No matter how you approach > the problem, you have to have an identifier for the other class when > you reference its methods and properties. If you don't want to declare > two mutually referential classes in the same unit, then one of them > (but only one) has to use some technique to avoid circular references. > Type casting is a simple technique and you either have to coerce each > use (think of TClassB(FObject) as just being a longer name for the > same thing) or declare an alias of the correct type - a "With" > statement can also be your friend here. From ryan at thealchemistguild.com Fri Apr 15 13:26:21 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 18:26:21 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <5710C3A8.2010005@mccallumwhyman.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> <5710BED0.10409@mccallumwhyman.com> <5710C3A8.2010005@mccallumwhyman.com> Message-ID: <3A6127E4-A309-4888-A610-820B0EC52B67@thealchemistguild.com> > On Apr 15, 2016, at 5:34 PM, Tony Whyman wrote: > > Just remembered, FPC also supports macros - see http://www.freepascal.org/docs-html/prog/progse5.html > > I haven't tested it, but you should be able to do > > {$MACRO On} > > {$DEFINE aClassBObject:=TClassB(FClassBObject) } > > and then use aClassBObject instead of the coercion. I remember trying to doing pre-parser type things using macros but the think the conclusion is they don’t work by just replace text like in C. I’m trying an example like this but getting errors and even crashing the compiler (seg faults). Regards, Ryan Joseph From ryan at thealchemistguild.com Fri Apr 15 13:39:19 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 18:39:19 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <3A6127E4-A309-4888-A610-820B0EC52B67@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> <5710BED0.10409@mccallumwhyman.com> <5710C3A8.2010005@mccallumwhyman.com> <3A6127E4-A309-4888-A610-820B0EC52B67@thealchemistguild.com> Message-ID: > On Apr 15, 2016, at 6:26 PM, Ryan Joseph wrote: > > I remember trying to doing pre-parser type things using macros but the think the conclusion is they don’t work by just replace text like in C. > > I’m trying an example like this but getting errors and even crashing the compiler (seg faults). Never mind! I was getting recursion causing the problems. It looks like they do work like the c preprocessor. Thanks, I’ll see if I can do something with this. Regards, Ryan Joseph From dec12 at avidsoft.com.hk Fri Apr 15 13:40:45 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Fri, 15 Apr 2016 19:40:45 +0800 Subject: [fpc-pascal] Error: Internal error 2014052302 on changing some common units Message-ID: <5710D33D.50203@avidsoft.com.hk> whenever I change the source of a common unit (that is used by many other units), when I compile with lazarus 1.7 +FPC 3.1.1, this error will appear in the messages "Error: Internal error 2014052302". What is that? Normally, I just go to Menu -> Run-Build and this message will disappear but this process is slow and I try to avoid it. Any idea ? Dennis From ryan at thealchemistguild.com Fri Apr 15 13:28:14 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 18:28:14 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: <5710BED0.10409@mccallumwhyman.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> <5710BED0.10409@mccallumwhyman.com> Message-ID: <818B2390-86F9-4544-A4E2-D28576CA7997@thealchemistguild.com> > On Apr 15, 2016, at 5:13 PM, Tony Whyman wrote: > > unit unitA; > > interface > > type > > class TClassA > private > FClassBObject: TObject; > public > procedure SomeProc; > end; > > implementation > > uses unitB; > > procedure TClassA.SomeProc; > var aClassBObject: TClassB absolute FClassBObject; > begin > aClassBObject.OtherProc; > end; > > end. I see now. That’s possibly preferable so I’ll keep it in mind but like you said just sucking it up and type casting is not so bad. :) Sure enough but it would even better if the compiler was more friendly here. If there was a good pre parser in FPC I’d just make some custom syntax but that’s not an option either as far as I know. Regards, Ryan Joseph From pascaldragon at googlemail.com Fri Apr 15 14:01:28 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 14:01:28 +0200 Subject: [fpc-pascal] A better way? In-Reply-To: <5710B2CD.8090908@avidsoft.com.hk> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <5710B2CD.8090908@avidsoft.com.hk> Message-ID: Am 15.04.2016 11:22 schrieb "Dennis" : > > >> > You could describe it as typecast done in the var clause of a method. The right hand identifier is not restricted to function parameters. >> >> While it works using "absolute" for a public API is rather unsafe (I'd only use that in private methods). In those cases the "as" operator should he used (or at least "is" plus returning an error). >> >> Regards, >> Sven >> >> > May I know why it is unsafe to use absolute on public method's parameters? I didn't mean that in the context of the "public" section of classes, but if your API is available to third party users (that can also include other members of the same development team) then you need to make sure that the instance that is passed in is indeed a correct one as otherwise you'd access the wrong fields or methods. For this kind of mistake public and protected methods are of course the most affected ones as are routines that are declared in the interface section of a unit. > Also, will there be any compiler options in which the parameters are passed through registers? In that case, will the absolute of private method's parameters still work? Parameters are already often passed in registers (of course this depends on the platform). However parameters also often have a spilling locations in the stack to store the parameter if register pressure gets too high, so absolute shouldn't be a problem normally. It might also be that the usage of absolute prohibits some optimizations the compiler would otherwise do with that parameter inside the function. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Fri Apr 15 14:03:50 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 14:03:50 +0200 Subject: [fpc-pascal] A better way? In-Reply-To: <818B2390-86F9-4544-A4E2-D28576CA7997@thealchemistguild.com> References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> <5710BED0.10409@mccallumwhyman.com> <818B2390-86F9-4544-A4E2-D28576CA7997@thealchemistguild.com> Message-ID: Am 15.04.2016 13:58 schrieb "Ryan Joseph" : > > > > On Apr 15, 2016, at 5:13 PM, Tony Whyman wrote: > > > > unit unitA; > > > > interface > > > > type > > > > class TClassA > > private > > FClassBObject: TObject; > > public > > procedure SomeProc; > > end; > > > > implementation > > > > uses unitB; > > > > procedure TClassA.SomeProc; > > var aClassBObject: TClassB absolute FClassBObject; > > begin > > aClassBObject.OtherProc; > > end; > > > > end. > > I see now. That’s possibly preferable so I’ll keep it in mind but like you said just sucking it up and type casting is not so bad. :) Sure enough but it would even better if the compiler was more friendly here. If there was a good pre parser in FPC I’d just make some custom syntax but that’s not an option either as far as I know. Again, you're fighting against design principles of the language. It's just as if you'd want to have virtual class methods in C++... Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at thealchemistguild.com Fri Apr 15 14:20:46 2016 From: ryan at thealchemistguild.com (Ryan Joseph) Date: Fri, 15 Apr 2016 19:20:46 +0700 Subject: [fpc-pascal] A better way? In-Reply-To: References: <14E95213-E535-4662-958A-06A0DC9D0F2C@thealchemistguild.com> <570F4D2E.7000209@geldenhuys.co.uk> <6CDB6CA5-EDB8-436F-9C9D-4C3F4F67F149@thealchemistguild.com> <570FDA94.5080305@freepascal.org> <9DEC6267-180B-454B-AE00-84E5B2BFDFCA@thealchemistguild.com> <5710AA48.8080709@mccallumwhyman.com> <9BE40AC2-9E8D-43E3-AFBF-1C79C63ED44C@thealchemistguild.com> <5710BED0.10409@mccallumwhyman.com> <818B2390-86F9-4544-A4E2-D28576CA7997@thealchemistguild.com> Message-ID: > On Apr 15, 2016, at 7:03 PM, Sven Barth wrote: > > Again, you're fighting against design principles of the language. It's just as if you'd want to have virtual class methods in C++… Agreed. Everyone has their own list of things they want their language to do I guess. Maybe I got spoiled with the typeless “id” type from Objective-C that let me have little work arounds for things like this. Not having a dictionary type after using PHP hurts also. ;) Here’s another option I thought of. If the type casting was of a serious quantity doing this could save time and improve readability of code. unit unitA; interface type class TClassA private FClassBObject: TObject; public procedure SomeProc; end; implementation uses unitB; type TClassAHelper = class helper for TClassA function aClassBObject: TClassB; end; function TClassAHelper.aClassBObject: TClassB; begin result := TClassB(FClassBObject) end; procedure TClassA.SomeProc; begin aClassBObject.OtherProc; end; end. Regards, Ryan Joseph From pascaldragon at googlemail.com Fri Apr 15 14:44:24 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 14:44:24 +0200 Subject: [fpc-pascal] Error: Internal error 2014052302 on changing some common units In-Reply-To: <5710D33D.50203@avidsoft.com.hk> References: <5710D33D.50203@avidsoft.com.hk> Message-ID: Am 15.04.2016 13:40 schrieb "Dennis" : > > whenever I change the source of a common unit (that is used by many other units), when I compile with lazarus 1.7 +FPC 3.1.1, this error will appear in the messages > "Error: Internal error 2014052302". Are you sure that you're using the most current version? Cause I had fixed that in r33054 at the beginning of February. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at avidsoft.com.hk Fri Apr 15 16:19:54 2016 From: dennis at avidsoft.com.hk (Dennis Poon) Date: Fri, 15 Apr 2016 22:19:54 +0800 Subject: [fpc-pascal] Error: Internal error 2014052302 on changing some common units In-Reply-To: References: <5710D33D.50203@avidsoft.com.hk> Message-ID: <5710F88A.6010504@avidsoft.com.hk> Sven Barth wrote: > > Am 15.04.2016 13:40 schrieb "Dennis" >: > > > > whenever I change the source of a common unit (that is used by many > other units), when I compile with lazarus 1.7 +FPC 3.1.1, this error > will appear in the messages > > "Error: Internal error 2014052302". > > Are you sure that you're using the most current version? Cause I had > fixed that in r33054 at the beginning of February. > > Regards, > Sven > > I get it from getlazarus.org a few days ago. please see the screen capture below: Dennis From juergen.hestermann at gmx.de Fri Apr 15 19:19:21 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Fri, 15 Apr 2016 19:19:21 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <5710A5CB.8040904@geldenhuys.co.uk> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> <57108913.9000604@gmx.de> <5710A5CB.8040904@geldenhuys.co.uk> Message-ID: <57112299.40403@gmx.de> Am 2016-04-15 um 10:26 schrieb Graeme Geldenhuys: >> Is there also a switch >> {$OneBasedDynArrays On} ? >> No more confusion about first and last element index. > You really should be using low() and high() instead. ;-) So why do we need {$ZeroBasedStrings On} at all? ;-) Of course, when you simply want to traverse all elements from the first to the last you can use low() and high(). But I would not use this for strings as for i := 1 to Length(S) is IMO more readable than for i := low(s) to high(S) (where it's unclear, whether high() means the highest *possible* or the highest *current* index). And I often need to calculate or store indices. Then I have to take into account where counting starts and ends which is unintuitive in dynamic arrays (not Pascal like). When I set INDEX := 2; then I always have to remind me that this means that it's the 3rd index in dynamic arrays while it's the 2nd one in strings. From juergen.hestermann at gmx.de Fri Apr 15 19:37:22 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Fri, 15 Apr 2016 19:37:22 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <57112299.40403@gmx.de> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> <57108913.9000604@gmx.de> <5710A5CB.8040904@geldenhuys.co.uk> <57112299.40403@gmx.de> Message-ID: <571126D2.6090603@gmx.de> Another advantage of having 1-based indeces in dyn. arrays would be that you could store indeces in unsigned integers while with 0-based indices high() may give -1. From silvioprog at gmail.com Fri Apr 15 18:38:26 2016 From: silvioprog at gmail.com (silvioprog) Date: Fri, 15 Apr 2016 13:38:26 -0300 Subject: [fpc-pascal] STATIC can only be used on non-virtual class methods Message-ID: Hello, Consider the following code: === test begin === {$MODE DELPHI} TStaticVirtualTest = class sealed(TObject) public class procedure Test; virtual; static; end; class procedure TStaticVirtualTest.Test; begin end; === test end === You can compile it in FPC (trunk), but, when you try to compile it on Delphi (Seattle): === error begin === E2376 STATIC can only be used on non-virtual class methods === error end === Is this a FPC bug? Thank you! -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Fri Apr 15 18:59:55 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Fri, 15 Apr 2016 12:59:55 -0400 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <57112299.40403@gmx.de> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> <57108913.9000604@gmx.de> <5710A5CB.8040904@geldenhuys.co.uk> <57112299.40403@gmx.de> Message-ID: On Fri, Apr 15, 2016 at 1:19 PM, Jürgen Hestermann < juergen.hestermann at gmx.de> wrote: > > So why do we need {$ZeroBasedStrings On} at all? ;-) > The same reason as other FPC features - (some of) Delphi code compatibility. thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Fri Apr 15 20:35:36 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 15 Apr 2016 20:35:36 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <571126D2.6090603@gmx.de> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> <57108913.9000604@gmx.de> <5710A5CB.8040904@geldenhuys.co.uk> <57112299.40403@gmx.de> <571126D2.6090603@gmx.de> Message-ID: Am 15.04.2016 18:37 schrieb "Jürgen Hestermann" : > > Another advantage of having 1-based indeces in dyn. arrays > would be that you could store indeces in unsigned integers > while with 0-based indices high() may give -1. Indices in Pascal are always signed. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From leledumbo_cool at yahoo.co.id Fri Apr 15 21:49:48 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Fri, 15 Apr 2016 12:49:48 -0700 (MST) Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <570FE12F.1000905@googlemail.com> References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> Message-ID: <1460749788261-5724969.post@n5.nabble.com> > We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is > used (it's a local switch). It works with Ansi-, Wide- and > UnicodeString, but not with ShortString. *shocked* so many hidden treasures in FPC... -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Any-chance-to-add-the-TStringBuilder-to-FCL-tp5724927p5724969.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From mschnell at lumino.de Fri Apr 15 10:19:06 2016 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 15 Apr 2016 10:19:06 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> Message-ID: <5710A3FA.7050608@lumino.de> On 04/15/2016 08:35 AM, Michael Van Canneyt wrote: > > For string constants there are slightly different rules. There the > result depends on the {$codepage} directive of the source file. Hmmm. If not setting $codepage Ifor a constant string I get StringCodePage = 0, If setting {$codepage UTF8} for a constant string I get StringCodePage = 1200 which is UTF16. The program does work decently, anyway. And ASM stepping shows that no conversion is done. -Michael From mschnell at lumino.de Fri Apr 15 10:43:55 2016 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 15 Apr 2016 10:43:55 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5710A737.70903@geldenhuys.co.uk> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> Message-ID: <5710A9CB.5080406@lumino.de> On 04/15/2016 10:32 AM, Graeme Geldenhuys wrote: > If you as a programmer knows the unit is saved in UTF-8 encoding, then > add {$codepage utf8} to the top of the unit. That tells the compiler > how to interpret string constants in that unit (without the need for > any guessing). I did some test with results that I can't get sorted. Do you suggest that the codepage of the sourcecode is preserved by the compiler when creating the string constant in object code ? I did not expect this but it of course is a possible way to go. But if that is true, StringCodePage of a constant never should return 0 which is CP_ACP, which is supposed to mean "in fact its the value of DefaultSystemcodepage" and hence is not predefined in the executable file. Seemingly StringCodePage does not work correctly with string constants anyway: I found that setting {$codepage UTF8}, for a constant string I get StringCodePage = 1200 which is UTF16. -Michael From nc-gaertnma at netcologne.de Sat Apr 16 10:47:45 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 16 Apr 2016 10:47:45 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5710A3FA.7050608@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A3FA.7050608@lumino.de> Message-ID: <20160416104745.2eb1d1c8@limapholos.matflo.wg> On Fri, 15 Apr 2016 10:19:06 +0200 Michael Schnell wrote: > On 04/15/2016 08:35 AM, Michael Van Canneyt wrote: > > > > For string constants there are slightly different rules. There the > > result depends on the {$codepage} directive of the source file. > > Hmmm. > > If not setting $codepage Ifor a constant string I get StringCodePage = 0, > > If setting {$codepage UTF8} for a constant string I get StringCodePage = > 1200 which is UTF16. > > The program does work decently, anyway. > > And ASM stepping shows that no conversion is done. That's correct. String literals in a codepage other than system are stored as UTF-16 in the binary and converted on assign. The conversion happens at runtime, so the string codepage is decided at runtime. Mattias From nc-gaertnma at netcologne.de Sat Apr 16 11:02:46 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 16 Apr 2016 11:02:46 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5710A9CB.5080406@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> Message-ID: <20160416110246.102194e5@limapholos.matflo.wg> On Fri, 15 Apr 2016 10:43:55 +0200 Michael Schnell wrote: >[...] > Do you suggest that the codepage of the sourcecode is preserved by the > compiler when creating the string constant in object code ? It depends. There are two codepages. The real one and the one you tell the compiler. If you tell the compiler that the string literal is 8-bit system codepage, it will copy it without conversion to the binary. Otherwise it converts it to UTF-16. For instance using {$codepage utf8} tells the compiler to convert all your literals to UTF-16. Without the {$codepage} the compiler preserves the real codepage. > Seemingly StringCodePage does not work correctly with string constants > anyway: I found that setting {$codepage UTF8}, for a constant string I > get StringCodePage = 1200 which is UTF16. StringCodePage on a literal is pretty useless. You should use StringCodePage on variables. Mattias From jonas.maebe at elis.ugent.be Sat Apr 16 11:44:07 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Sat, 16 Apr 2016 11:44:07 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160416104745.2eb1d1c8@limapholos.matflo.wg> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A3FA.7050608@lumino.de> <20160416104745.2eb1d1c8@limapholos.matflo.wg> Message-ID: <57120967.50009@elis.ugent.be> Mattias Gaertner wrote: > That's correct. String literals in a codepage other than system are > stored as UTF-16 in the binary and converted on assign. The conversion > happens at runtime, so the string codepage is decided at > runtime. That's correct if the assignment is to a variable/parameter that has codepage CP_ACP. If it's an assignment to an ansistring(some_codepage) (except for rawbytestring/cp_none), then the string constant gets converted to that codepage at compile time. Jonas From juergen.hestermann at gmx.de Sat Apr 16 13:13:31 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Sat, 16 Apr 2016 13:13:31 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: References: <1460655401784-5724928.post@n5.nabble.com> <570FE12F.1000905@googlemail.com> <57100A12.4040600@geldenhuys.co.uk> <57108913.9000604@gmx.de> <5710A5CB.8040904@geldenhuys.co.uk> <57112299.40403@gmx.de> <571126D2.6090603@gmx.de> Message-ID: <57121E5B.9030904@gmx.de> Am 2016-04-15 um 20:35 schrieb Sven Barth: > > Am 15.04.2016 18:37 schrieb "Jürgen Hestermann" >: > > > > Another advantage of having 1-based indeces in dyn. arrays > > would be that you could store indeces in unsigned integers > > while with 0-based indices high() may give -1. > > Indices in Pascal are always signed. > > Yes, but I could store indices in DWORD if they would be 1-based and would not risk an exception if the index is "not valid" (which would be 0 in this case while it's -1 for 0-based indices). I would not be forced to make sure it is an signed integer where I store it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcov at stack.nl Sat Apr 16 18:36:55 2016 From: marcov at stack.nl (Marco van de Voort) Date: Sat, 16 Apr 2016 18:36:55 +0200 (CEST) Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <57121E5B.9030904@gmx.de> Message-ID: <20160416163655.BDF8D73036@toad.stack.nl> In our previous episode, J?rgen Hestermann said: > > > while with 0-based indices high() may give -1. > > > > Indices in Pascal are always signed. > > > > > Yes, but I could store indices in DWORD if they would be 1-based > and would not risk an exception if the index is "not valid" (which > would be 0 in this case while it's -1 for 0-based indices). You would have to check everywhere before decrementing. This can be annoying in loops. (it is that way in M2 btw, where the basetype is unsigned. Not happy with that) From juergen.hestermann at gmx.de Sat Apr 16 20:28:13 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Sat, 16 Apr 2016 20:28:13 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <20160416163655.BDF8D73036@toad.stack.nl> References: <20160416163655.BDF8D73036@toad.stack.nl> Message-ID: <5712843D.5040006@gmx.de> Am 2016-04-16 um 18:36 schrieb Marco van de Voort: >> Yes, but I could store indices in DWORD if they would be 1-based >> and would not risk an exception if the index is "not valid" (which >> would be 0 in this case while it's -1 for 0-based indices). > You would have to check everywhere before decrementing. This can be annoying > in loops. (it is that way in M2 btw, where the basetype is unsigned. Not > happy with that) I don't know what you mean. A For-loop has it's limits anyway. And when decrementing 'manually' I would stop if INDEX=0. For 0-based arrays I would stop if INDEX=-1? What would be different? For 1-based arrays I would never get an index<0 because it stops at zero. From skalogryz.lists at gmail.com Sat Apr 16 19:39:52 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Sat, 16 Apr 2016 13:39:52 -0400 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <5712843D.5040006@gmx.de> References: <20160416163655.BDF8D73036@toad.stack.nl> <5712843D.5040006@gmx.de> Message-ID: On Sat, Apr 16, 2016 at 2:28 PM, Jürgen Hestermann < juergen.hestermann at gmx.de> wrote: > I don't know what you mean. > A For-loop has it's limits anyway. > And when decrementing 'manually' I would stop if INDEX=0. > For 0-based arrays I would stop if INDEX=-1? > What would be different? > For 1-based arrays I would never get an index<0 > because it stops at zero. The problem is with using "unsigned" as an index (rather than zero- vs one- based arrays) Take a while loop as an example, where index can change multiple times. Current solution: while i>=0 do if cond then dec(i); dec(i); end; Unsigned index solution while i>=0 do if cond then if i>0 then dec(i); if i>0 then dec(i); end; Without these checks, unsigned integer would loop over to $FFFFFFFF and will continue. thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartjunk64 at gmail.com Sun Apr 17 17:45:12 2016 From: bartjunk64 at gmail.com (Bart) Date: Sun, 17 Apr 2016 17:45:12 +0200 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? Message-ID: Hi, I cannot find any documentation about TMaskUtils.ValidateInput function (unit MaskUtils). AFAICS Delphi does not have such a class? (ref: http://docwiki.embarcadero.com/Libraries/XE6/en/System.MaskUtils) There are some bugreports about this unit in Mantis which got me interested. See the attached demo program. It outputs: C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\maskutils>mutest Mask : "###" Value: "ABCD" VI : " " (Shouldn't this fail?) Mask : "999" Value: "ABCD" VI : " " (Shouldn't this fail?) Mask : "000" Value: "ABCD" ValidateInput Failed Mask : "LLL" Value: "1234" ValidateInput Failed Mask : "lll" Value: "1234" VI : " " (Shouldn't this fail?) Mask : "AAA" Value: "[{|/" ValidateInput Failed Mask : "aaa" Value: "[{|/" VI : " " (Shouldn't this fail?) I am the maintainer of the Lazarus MaskEdit unit. I find the results rather confusing and inconsistent with Lazarus/Delphi MaskEdit behaviour. Note: When the mask contains mask-characters that mean "value must be of type XYZ, but not required" the ValidateInput accepts any input. The same characters in MaskEdit (both Lazarus and Delphi) interpret this as: "if you put anything in that place it must be of type XYZ, but you may leave this place empty (e.g. a blank)". Basically ValidateInput now treats '#', '9', 'l' and 'a' as if it were 'c' (any character allowed here). This seems wrong to me. However, since the function lacks any documentation one can argue that current behaviour is correct. To me the (IMO more logical) behaviour of the ValidateInput function could be described as the result of these actions in a LCL/VCL program: - have a MaskEdit1: TMaskEdit - do MaskEdit1.EditMask := Mask - do MaskEdit1.Text := Value - do MaskEdit1.ValidateEdit - if no exception is raised then the result will be MaskEdit1.EditText, but with all "SpaceChar" repkaced by #32. I.o.w. the function shall raise an exception it Value (after appllying Mask to it) does NOT match the Mask. So, is it a bug? If so, I'll open a ticket in Mantis for it (and the discussion should then move there). Bart -------------- next part -------------- A non-text attachment was scrubbed... Name: mutest.lpr Type: application/octet-stream Size: 2484 bytes Desc: not available URL: From juergen.hestermann at gmx.de Mon Apr 18 08:57:41 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Mon, 18 Apr 2016 08:57:41 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: References: <20160416163655.BDF8D73036@toad.stack.nl> <5712843D.5040006@gmx.de> Message-ID: <57148565.7010904@gmx.de> Am 2016-04-16 um 19:39 schrieb Dmitry Boyarintsev: > The problem is with using "unsigned" as an index (rather than zero- vs one- based arrays) > Take a while loop as an example, where index can change multiple times. > Current solution: > while i>=0 do > if cond then dec(i); > dec(i); > end; > Unsigned index solution > while i>=0 do > if cond then if i>0 then dec(i); > if i>0 then dec(i); > end; > Without these checks, unsigned integer would loop over to $FFFFFFFF and will continue. That looks to my like an very artifical example. I never came over a loop where I (conditionally) decremented the index twice. But of course, if you have such a case, then you can only use signed intergers. But in all the following cases I could used an unsigned integer (when having 1-based arrays): 1.) for i := low(array) to high(array) 2.) repeat or while loops where the index is in- or decremented by a maximum of 1 (which IMO is the case in 99,9% of all such loops). 3.) When storing an array index into a variable for later use. Nevertheless, using unsigned integers was only one aspect of 1-based arrays. The main one for me was, that it is much more intuitive and therefore less error prone. I already often had errors when calculating indices for 0-based arrays. And why was a directive implemented to use 0-based indices even for strings but none for 1-based indices in dynamic arrays? IMO the latter would be much more desired. From marcov at stack.nl Mon Apr 18 09:53:12 2016 From: marcov at stack.nl (Marco van de Voort) Date: Mon, 18 Apr 2016 09:53:12 +0200 (CEST) Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <5712843D.5040006@gmx.de> Message-ID: <20160418075312.D1DCA73036@toad.stack.nl> In our previous episode, J?rgen Hestermann said: > > in loops. (it is that way in M2 btw, where the basetype is unsigned. Not > > happy with that) > > I don't know what you mean. > A For-loop has it's limits anyway. Limits like in for i:=0 to someexpression.count-1 are evaluated as expression before using the result to for. If count=0 this would become for i:=0 to $FFFFFFFF, so you need to guard this with a if count>0 then. This is a common construct so quite annoying. From pascaldragon at googlemail.com Mon Apr 18 11:33:19 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 18 Apr 2016 11:33:19 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <57148565.7010904@gmx.de> References: <20160416163655.BDF8D73036@toad.stack.nl> <5712843D.5040006@gmx.de> <57148565.7010904@gmx.de> Message-ID: Am 18.04.2016 07:58 schrieb "Jürgen Hestermann" : > And why was a directive implemented to use 0-based indices > even for strings but none for 1-based indices in dynamic arrays? > IMO the latter would be much more desired. The usual reason: Delphi compatibility. If Delphi wouldn't have that directive, we wouldn't have that either, because most others are content with the indices as they are. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Mon Apr 18 15:19:11 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 18 Apr 2016 15:19:11 +0200 (CEST) Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: Message-ID: On Sun, 17 Apr 2016, Bart wrote: > Hi, > > I cannot find any documentation about TMaskUtils.ValidateInput > function (unit MaskUtils). > AFAICS Delphi does not have such a class? > (ref: http://docwiki.embarcadero.com/Libraries/XE6/en/System.MaskUtils) > > There are some bugreports about this unit in Mantis which got me interested. I recently did some work on it; the class works completely wrong IMO, and I though to replace it completely with the functions found in the LCL. Michael. From bartjunk64 at gmail.com Mon Apr 18 16:51:14 2016 From: bartjunk64 at gmail.com (Bart) Date: Mon, 18 Apr 2016 16:51:14 +0200 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: Message-ID: On 4/18/16, Michael Van Canneyt wrote: > I recently did some work on it; the class works completely wrong IMO, and I > though to replace it completely with the functions found in the LCL. Yep, I was going that way too (and started coding it so). Currently FormatMaskText from maskedit (LCL) behaves better than the one from maskutils. The LCL implementation handles UTF8, the fpc's will (also with code ported form LCL) only handle single byte encoding. Maybe a version of maskutils unit based on UnicodeString should also be made? Bart From bartjunk64 at gmail.com Mon Apr 18 16:58:10 2016 From: bartjunk64 at gmail.com (Bart) Date: Mon, 18 Apr 2016 16:58:10 +0200 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: Message-ID: On 4/18/16, Bart wrote: >> I recently did some work on it; the class works completely wrong IMO, and As a side note: function ValidateInput : string; The function raises an exception upon failure. Since we did not have to follow Delphi here, a better declaration IMHO would have been: function ValidateInput (out ValidatedString: string): Boolean; or as a pair of functions (like the conversion routines for strings): function ValidateInput : string; function TryValidateInput (out ValidatedString: string): Boolean; Bart From mailinglists at geldenhuys.co.uk Mon Apr 18 17:22:56 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 18 Apr 2016 16:22:56 +0100 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: Message-ID: <5714FBD0.4050702@geldenhuys.co.uk> On 2016-04-18 15:51, Bart wrote: > Maybe a version of maskutils unit based on UnicodeString should also > be made? This seems so redundant. I still need to study the new FPC 3.0 string handling, but I was hoping such duplication of implementations would not be necessary with newer FPC versions. We don't see such rubbish [duplication of code with various string types] in Java or C# or Qt, so why must we put up with it in Object Pascal. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From michael at freepascal.org Mon Apr 18 17:27:39 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 18 Apr 2016 17:27:39 +0200 (CEST) Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: <5714FBD0.4050702@geldenhuys.co.uk> References: <5714FBD0.4050702@geldenhuys.co.uk> Message-ID: On Mon, 18 Apr 2016, Graeme Geldenhuys wrote: > On 2016-04-18 15:51, Bart wrote: >> Maybe a version of maskutils unit based on UnicodeString should also >> be made? > > This seems so redundant. I still need to study the new FPC 3.0 string > handling, but I was hoping such duplication of implementations would not > be necessary with newer FPC versions. We don't see such rubbish > [duplication of code with various string types] in Java or C# or Qt, so > why must we put up with it in Object Pascal. I think Bart meant that the maskutils unit should simply use unicodestring. Given that it almost surely will need to deal with $ and € etc, that seems like a better approach. Michael. From dec12 at avidsoft.com.hk Mon Apr 18 17:34:10 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Mon, 18 Apr 2016 23:34:10 +0800 Subject: [fpc-pascal] is there any pascal library of SNTP (Simple Network Time Protocol)? Message-ID: <5714FE72.2080408@avidsoft.com.hk> I am want to embed the SNTP into my applications so that I don't have to run Dimension 4 or other software to correct my PC Clock. Thanks in advance. Dennis From juergen.hestermann at gmx.de Mon Apr 18 19:01:22 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Mon, 18 Apr 2016 19:01:22 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <20160418075312.D1DCA73036@toad.stack.nl> References: <20160418075312.D1DCA73036@toad.stack.nl> Message-ID: <571512E2.40300@gmx.de> Am 2016-04-18 um 09:53 schrieb Marco van de Voort: > Limits like in > > for i:=0 to someexpression.count-1 > > are evaluated as expression before using the result to for. If count=0 this > would become for i:=0 to $FFFFFFFF, so you need to guard this with a if > count>0 then. > Well, for 1-based arrays it would be for i := 1 to someexpression.count (without the annyoing -1). In general I can make sure that somexpression.count is zero or larger when I use it to determine an index for my array. The same would be for i := low(array) to high(array) which is very common and where I would not need to use an unsigned integer. From juergen.hestermann at gmx.de Mon Apr 18 19:07:42 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Mon, 18 Apr 2016 19:07:42 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: References: <20160416163655.BDF8D73036@toad.stack.nl> <5712843D.5040006@gmx.de> <57148565.7010904@gmx.de> Message-ID: <5715145E.1040607@gmx.de> Am 2016-04-18 um 11:33 schrieb Sven Barth: > > Am 18.04.2016 07:58 schrieb "Jürgen Hestermann" >: > > And why was a directive implemented to use 0-based indices > > even for strings but none for 1-based indices in dynamic arrays? > > IMO the latter would be much more desired. > > The usual reason: Delphi compatibility. If Delphi wouldn't have that directive, we wouldn't have that either, because most others are content with the indices as they are. > > Seems that whenever something goes into the wrong direction then always Delphi is the culprit. ;-( -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Mon Apr 18 18:30:48 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 18 Apr 2016 17:30:48 +0100 Subject: [fpc-pascal] is there any pascal library of SNTP (Simple Network Time Protocol)? In-Reply-To: <5714FE72.2080408@avidsoft.com.hk> References: <5714FE72.2080408@avidsoft.com.hk> Message-ID: <57150BB8.2050603@geldenhuys.co.uk> On 2016-04-18 16:34, Dennis wrote: > I am want to embed the SNTP into my applications Take a look at the Indy 10.6.0.2 components, they have the SNTP protocol implemented. They are free and open source. Get the latest code from their code repository. Official SVN repository: https://svn.atozed.com:444/svn/Indy10/trunk Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From micsch at gmail.com Mon Apr 18 18:38:20 2016 From: micsch at gmail.com (micsch at gmail.com) Date: Mon, 18 Apr 2016 18:38:20 +0200 Subject: [fpc-pascal] is there any pascal library of SNTP (Simple Network Time Protocol)? In-Reply-To: <5714FE72.2080408@avidsoft.com.hk> References: <5714FE72.2080408@avidsoft.com.hk> Message-ID: <201604181838.20649.micsch@gmail.com> Am Monday 18 April 2016 17:34:10 schrieb Dennis: > I am want to embed the SNTP into my applications so that I don't have to > run Dimension 4 or other software to correct my PC Clock. Synapse http://synapse.ararat.cz/doc/help/sntpsend.TSNTPSend.html From bartjunk64 at gmail.com Mon Apr 18 18:47:48 2016 From: bartjunk64 at gmail.com (Bart) Date: Mon, 18 Apr 2016 18:47:48 +0200 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: <5714FBD0.4050702@geldenhuys.co.uk> Message-ID: On 4/18/16, Michael Van Canneyt wrote: > I think Bart meant that the maskutils unit should simply use unicodestring. > Given that it almost surely will need to deal with $ and € etc, that seems > like a better approach. Yep. In UTF8 the 1 on 1 relation between the internal mask structure and the content of Value gets lost. In LCL's MaskEdit unit this is solved by assuming all string data is UTF8. (We convert the result from the widgetset to UTF8 explicitely) The MaskEdit unit has routines (GetCodePoint/SetCodePoint) that rely on routines in LazUtf8 in order to match a position of a codepoint to a position in the internal mask. This cannot be done in pure fpc, so a TMaskUtils based on AnsiChar can only function with single byte encoding (as it is now, so that doesn't break anything).. (UTF8 might even work if no case conversion is used in the mask, I have not tested). I attach an alterative _maskutils unit, which basically uses the same approach as TMaskEdit, but without the UTF8 support. Rewriting this to use WideChar and UnicodeString should be very easy. The internal processing of the (edit)mask is the same as TMaskEdit. If that is broken somehow, it is also broken in TMaskEdit. The only functions that may need adjustments are * function FormatMaskText(const EditMask: string; const AValue: string): string; * function FormatMaskInput(const EditMask: string): string; * function MaskDoFormatText(const EditMask: string; const AValue: string; ASpaceChar: Char): string; * function TMaskUtils.TryValidateInput(out ValidatedString: String): Boolean; But since there is no real documentation and there is no test suite, it's hard to tell if they do not function as they should or introduce regressions. Note; I did not find any reference to use of MaskUtils in FreePascal itself, except for the uses clause in the db uit (where I did not find any reference to the above mentioned functions). Q: Would changing the implementation to UnicodeString introduce regressions or compilation errors for existing programs using this unit? (It'll probably give warnings about possible data loss due to implicit conversions.) Bart -------------- next part -------------- A non-text attachment was scrubbed... Name: _maskutils.pas Type: text/x-pascal Size: 28591 bytes Desc: not available URL: From luizamericop at gmail.com Mon Apr 18 20:26:36 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Mon, 18 Apr 2016 15:26:36 -0300 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: <5714FBD0.4050702@geldenhuys.co.uk> Message-ID: 2016-04-18 13:47 GMT-03:00 Bart : [..] > The internal processing of the (edit)mask is the same as TMaskEdit. > If that is broken somehow, it is also broken in TMaskEdit. > > The only functions that may need adjustments are > > * function FormatMaskText(const EditMask: string; const AValue: string): > string; > * function FormatMaskInput(const EditMask: string): string; > * function MaskDoFormatText(const EditMask: string; const AValue: string; > ASpaceChar: Char): string; > * function TMaskUtils.TryValidateInput(out ValidatedString: String): > Boolean; > > But since there is no real documentation and there is no test suite, > it's hard to tell if they do not function as they should or introduce > regressions. > > I propose to write a test suite first with the desired output, based on Delphi. Given that the implementation becomes a detail, subject to changes in future. I can take the duty of starting, just need to know the format. fpcunit or plain tests like most fpc tests? Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca at ventoso.org Mon Apr 18 17:22:56 2016 From: luca at ventoso.org (Luca Olivetti) Date: Mon, 18 Apr 2016 17:22:56 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <20160418075312.D1DCA73036@toad.stack.nl> References: <20160418075312.D1DCA73036@toad.stack.nl> Message-ID: <5714FBD0.5070108@ventoso.org> El 18/04/16 a les 09:53, Marco van de Voort ha escrit: > In our previous episode, J?rgen Hestermann said: >> > in loops. (it is that way in M2 btw, where the basetype is unsigned. Not >> > happy with that) >> >> I don't know what you mean. >> A For-loop has it's limits anyway. > > Limits like in > > for i:=0 to someexpression.count-1 > > are evaluated as expression before using the result to for. If count=0 this > would become for i:=0 to $FFFFFFFF, so you need to guard this with a if > count>0 then. Wait, doesn't that evaluate to for i:=0 to -1 at least if count is a signed integer? Bye -- Luca From michael at freepascal.org Mon Apr 18 21:06:03 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 18 Apr 2016 21:06:03 +0200 (CEST) Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: <5714FBD0.4050702@geldenhuys.co.uk> Message-ID: On Mon, 18 Apr 2016, Luiz Americo Pereira Camara wrote: > 2016-04-18 13:47 GMT-03:00 Bart : > > [..] > >> The internal processing of the (edit)mask is the same as TMaskEdit. >> If that is broken somehow, it is also broken in TMaskEdit. >> >> The only functions that may need adjustments are >> >> * function FormatMaskText(const EditMask: string; const AValue: string): >> string; >> * function FormatMaskInput(const EditMask: string): string; >> * function MaskDoFormatText(const EditMask: string; const AValue: string; >> ASpaceChar: Char): string; >> * function TMaskUtils.TryValidateInput(out ValidatedString: String): >> Boolean; >> >> But since there is no real documentation and there is no test suite, >> it's hard to tell if they do not function as they should or introduce >> regressions. >> >> > I propose to write a test suite first with the desired output, based on > Delphi. I agree 100% > > Given that the implementation becomes a detail, subject to changes in > future. > > I can take the duty of starting, just need to know the format. fpcunit or > plain tests like most fpc tests? fpcunit. 'most fpc tests' are for the compiler, not for unit functionality. Michael. From mailinglists at geldenhuys.co.uk Mon Apr 18 21:26:06 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 18 Apr 2016 20:26:06 +0100 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: <5714FBD0.4050702@geldenhuys.co.uk> Message-ID: <571534CE.1000202@geldenhuys.co.uk> On 2016-04-18 19:26, Luiz Americo Pereira Camara wrote: > I propose to write a test suite first with the desired output, based on > Delphi. Fantastic idea! Test Driven Development - the best way to write any software. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mschnell at lumino.de Mon Apr 18 12:09:17 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 18 Apr 2016 12:09:17 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160416104745.2eb1d1c8@limapholos.matflo.wg> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A3FA.7050608@lumino.de> <20160416104745.2eb1d1c8@limapholos.matflo.wg> Message-ID: <5714B24D.6000504@lumino.de> On 04/16/2016 10:47 AM, Mattias Gaertner wrote: > That's correct. String literals in a codepage other than system are > stored as UTF-16 in the binary (Assuming with "other than system" you mean different from the DefaultSystemcodepage setting the compiler sees at it's runtime). I see. And of course that will work. Even though IMHO this is rather hard to understand, as UTF 16 seems to be a rather ineffective coding of constants (for software generally working with UTF-8) regarding as well storage as conversion effort. Seemingly the compiler assumes that the executable likely at runtime will see DefaultSystemcodepage not equal the {$codepage setting in the source code and abstains form trying to prepare the possible optimization the user might have intended by using {$codepage . > and converted on assign. By "on assign" you mean "when a constant string is assigned to a string that in it's type has a defined codepage (CP_ACP or any other 7 or 8 bit encoding, or CO_UTF16BE)", but not if it's CP_NONE or CP_UTF16). > The conversion happens at runtime, so the string codepage is decided > at runtime. I'll re-check if I see the convertor working... -Michael From mschnell at lumino.de Mon Apr 18 12:19:28 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 18 Apr 2016 12:19:28 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160416110246.102194e5@limapholos.matflo.wg> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> Message-ID: <5714B4B0.2070604@lumino.de> On 04/16/2016 11:02 AM, Mattias Gaertner wrote: > For instance using {$codepage utf8} tells the compiler to convert all > your literals to UTF-16. Without the {$codepage} the compiler > preserves the real codepage. I.e. (compiling in a UTF-8 based Linux) - using {$codepage utf8} tells the compiler to convert all your literals to UTF-16 - not using {$codepage utf8} tells the compiler to convert all your literals to UTF-8 The compiler is making fun of me ... :-) -Michael From mschnell at lumino.de Mon Apr 18 12:21:02 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 18 Apr 2016 12:21:02 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160416110246.102194e5@limapholos.matflo.wg> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> Message-ID: <5714B50E.7090109@lumino.de> On 04/16/2016 11:02 AM, Mattias Gaertner wrote: > StringCodePage on a literal is pretty useless. You should use > StringCodePage on variables. Just exploring how the compiler works... -Michael From jonas.maebe at elis.ugent.be Tue Apr 19 08:22:51 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Tue, 19 Apr 2016 08:22:51 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5714B4B0.2070604@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> Message-ID: <5715CEBB.2080704@elis.ugent.be> Michael Schnell wrote: > On 04/16/2016 11:02 AM, Mattias Gaertner wrote: >> For instance using {$codepage utf8} tells the compiler to convert all >> your literals to UTF-16. Without the {$codepage} the compiler >> preserves the real codepage. > I.e. (compiling in a UTF-8 based Linux) > > - using {$codepage utf8} tells the compiler to convert all your literals > to UTF-16 That's a, wrongly described, implementation detail. When any {$codepage xxx} directive is specified, string constants in the source are represented in a way that makes lossless conversion to any other code page possible. This conversion to the target code page is performed at compile time where possible (when the target code page cannot change at run time), and otherwise at run time. What this internal lossless representation is at compile time and/or run time is undefined. > - not using {$codepage utf8} tells the compiler to convert all your > literals to UTF-8 No, it does not. Please tell me which sentence of http://wiki.freepascal.org/FPC_Unicode_support#String_constants suggests that in any way. Jonas From mailinglists at geldenhuys.co.uk Tue Apr 19 14:25:08 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 19 Apr 2016 13:25:08 +0100 Subject: [fpc-pascal] fpdoc fixes for FPC 3.0.2 Message-ID: <571623A4.5000500@geldenhuys.co.uk> Hi, I have some fixes for fpdoc [and more to come] and would like them applied to FPC 3.0.2 if possible. Is there an estimate cut-off date for back-porting fixes to 3.0.2, or is there no release date set for 3.0.2 yet. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From michael at freepascal.org Tue Apr 19 14:27:21 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 19 Apr 2016 14:27:21 +0200 (CEST) Subject: [fpc-pascal] fpdoc fixes for FPC 3.0.2 In-Reply-To: <571623A4.5000500@geldenhuys.co.uk> References: <571623A4.5000500@geldenhuys.co.uk> Message-ID: On Tue, 19 Apr 2016, Graeme Geldenhuys wrote: > Hi, > > I have some fixes for fpdoc [and more to come] and would like them > applied to FPC 3.0.2 if possible. Is there an estimate cut-off date for > back-porting fixes to 3.0.2, or is there no release date set for 3.0.2 yet. No release date set yet. Michael. From bartjunk64 at gmail.com Tue Apr 19 19:56:47 2016 From: bartjunk64 at gmail.com (Bart) Date: Tue, 19 Apr 2016 19:56:47 +0200 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: <5714FBD0.4050702@geldenhuys.co.uk> Message-ID: On 4/18/16, Luiz Americo Pereira Camara wrote: > I propose to write a test suite first with the desired output, based on > Delphi. > I agree with the concept, but: Please note that Delphi (AFAICS) does not have a TMaskUtils class. The behaviour of TMaskEdit (and hence methods like ApplyMaskToText) has been tested quit vigorously agains the behaviour of Delphi 3. It is near 100% compatible. So, since Delphi only publishes FormatMaskText function, this is all we can compare. The other 2 functions we have in the interface are only used internally by Delphi if I understand correctly (from some old fpc-devel mails), so there behaviour is an imlementation detail. The Delphi docs on FormatMaskText don't clarify much about how it must behave. Bart From silvioprog at gmail.com Tue Apr 19 20:05:39 2016 From: silvioprog at gmail.com (silvioprog) Date: Tue, 19 Apr 2016 15:05:39 -0300 Subject: [fpc-pascal] FCL maskutils incompatible with Delphi Message-ID: Hello, Last week, a member of Lazarus Brazillian group reported a problem related to the MaskUtils unit. His message (adapted from pt-BR to en-US) was: *"Good afternoon.* *I need help with FormatMaskText, because it doesn't work properly with the same code that works fine on Delphi".* His refactored example was: === code === uses maskutils; const MY_UNMASKED_VALUE = 'H1H357K808K44616YK8720'; begin WriteLn(FormatMaskText('!>cccccc\-ccccc\-ccccc-cccccc;0;*', MY_UNMASKED_VALUE)); // uncomment the like below and enjoy the crash //WriteLn(FormatMaskText('!>CCCCCC\-CCCCC\-CCCCC-CCCCCC;0;_', MY_UNMASKED_VALUE)); end. === /code === The expected value: H1H357-K808K-44616-YK8720. The returned value: H1H357-K808K-44616-******. If you uncomment the code in the last writeln, it will raise the generic "FormatMaskText function failed!" error. However, this attached patch was sent from another member and it seems fix the problem. Can I open an issue at bugtracker related to this problem? Thank you! -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-maskutils-problem.patch Type: application/octet-stream Size: 1586 bytes Desc: not available URL: From bartjunk64 at gmail.com Tue Apr 19 21:14:13 2016 From: bartjunk64 at gmail.com (Bart) Date: Tue, 19 Apr 2016 21:14:13 +0200 Subject: [fpc-pascal] FCL maskutils incompatible with Delphi In-Reply-To: References: Message-ID: On 4/19/16, silvioprog wrote: > The expected value: H1H357-K808K-44616-YK8720. > > The returned value: H1H357-K808K-44616-******. > > If you uncomment the code in the last writeln, it will raise the generic > "FormatMaskText function failed!" error. > The issue you describe looks like http://bugs.freepascal.org/view.php?id=30020 There is also a bugreport about crashes in FormatMaskText. http://bugs.freepascal.org/view.php?id=28201 And there is also a thread in this ML about a new implementation of the MaskUtils unit. Bart From bartjunk64 at gmail.com Tue Apr 19 21:17:14 2016 From: bartjunk64 at gmail.com (Bart) Date: Tue, 19 Apr 2016 21:17:14 +0200 Subject: [fpc-pascal] Any chance to add the TStringBuilder to FCL? In-Reply-To: <5714FBD0.5070108@ventoso.org> References: <20160418075312.D1DCA73036@toad.stack.nl> <5714FBD0.5070108@ventoso.org> Message-ID: On 4/18/16, Luca Olivetti wrote: > Wait, doesn't that evaluate to > > for i:=0 to -1 > > > at least if count is a signed integer? No, not if i is unsigned (and range-checking is off). Bart From rainerstratmann at t-online.de Tue Apr 19 21:35:57 2016 From: rainerstratmann at t-online.de (Rainer Stratmann) Date: Tue, 19 Apr 2016 21:35:57 +0200 Subject: [fpc-pascal] Build in a C compiler Message-ID: <11327366.kVYTVnkxXf@debian8inet> That would be great. It is not that difficult. { = begin } = end and the other stuff is quite similar. Pascal and C are close related. It could be made with a compiler switch to determine if the compiler is in the Pascal or in the C compiling mode. No more need to translate (huge amount of) C code. :-) From silvioprog at gmail.com Tue Apr 19 21:38:04 2016 From: silvioprog at gmail.com (silvioprog) Date: Tue, 19 Apr 2016 16:38:04 -0300 Subject: [fpc-pascal] FCL maskutils incompatible with Delphi In-Reply-To: References: Message-ID: On Tue, Apr 19, 2016 at 4:14 PM, Bart wrote: > On 4/19/16, silvioprog wrote: > > > The expected value: H1H357-K808K-44616-YK8720. > > > > The returned value: H1H357-K808K-44616-******. > > > > If you uncomment the code in the last writeln, it will raise the generic > > "FormatMaskText function failed!" error. > > > > The issue you describe looks like > http://bugs.freepascal.org/view.php?id=30020 > > There is also a bugreport about crashes in FormatMaskText. > http://bugs.freepascal.org/view.php?id=28201 > > And there is also a thread in this ML about a new implementation of > the MaskUtils unit. > Yes, he (Handlei) reported it at Brazillian group, but he didn't tell us that had already reported that at bugtracker. The patch was sent from another member, and he told us that it fix the current maskutils.pp unit, I just sent it here as they asked me. Can I send this patch to #30020 or just wait for new MaskUtils implementation? -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From leledumbo_cool at yahoo.co.id Wed Apr 20 08:58:29 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Tue, 19 Apr 2016 23:58:29 -0700 (MST) Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <11327366.kVYTVnkxXf@debian8inet> References: <11327366.kVYTVnkxXf@debian8inet> Message-ID: <1461135509984-5725010.post@n5.nabble.com> > That would be great. Nope > It is not that difficult. > { = begin > } = end > > and the other stuff is quite similar. Syntax is easy, well once you have fully working preprocessor too, but how about libraries? How will you convert scanf/printf/puts/etc? What if it uses 3rd party libraries? > Pascal and C are close related. Only at the surface. There are many semantics differences that's not convertible at all. e.g.: ALL C expressions are potentially a boolean expression which in turn has boolean value, while in Pascal, only boolean expression has boolean value. At syntax level, there's no Pascal equivalent of C's comma (sequence) operator. Argument evaluation in C is strictly right to left, in Pascal it's up to the compiler. A silly but valid C statement: printf("%d%d%d\n",i++,++i,++i,i++); would be hard to convert to Pascal automatically without blowing out the compiler. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Build-in-a-C-compiler-tp5725008p5725010.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From markMLl.fpc-pascal at telemetry.co.uk Wed Apr 20 09:05:10 2016 From: markMLl.fpc-pascal at telemetry.co.uk (Mark Morgan Lloyd) Date: Wed, 20 Apr 2016 07:05:10 +0000 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <11327366.kVYTVnkxXf@debian8inet> References: <11327366.kVYTVnkxXf@debian8inet> Message-ID: Rainer Stratmann wrote: > That would be great. > > It is not that difficult. > > { = begin > } = end > > and the other stuff is quite similar. > > Pascal and C are close related. No. Pascal and ALGOL are closely related, C and ALGOL are closely related. Pascal and C are not so closely related. If you're looking for commonality go and use ALGOL, rather than making suggestions that are bound to result in a lot of sound and fury :-( -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From hnb.code at gmail.com Wed Apr 20 09:25:26 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Wed, 20 Apr 2016 09:25:26 +0200 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <1461135509984-5725010.post@n5.nabble.com> References: <11327366.kVYTVnkxXf@debian8inet> <1461135509984-5725010.post@n5.nabble.com> Message-ID: 2016-04-20 8:58 GMT+02:00 leledumbo : > At syntax level, there's no Pascal equivalent > of C's comma (sequence) operator. Argument evaluation in C is strictly > right > to left, in Pascal it's up to the compiler. A silly but valid C statement: > > printf("%d%d%d\n",i++,++i,++i,i++); > > would be hard to convert to Pascal automatically without blowing out the > compiler. > C's comma (sequence) operator is possible to use in Pascal: function printf(fmt: PAnsiChar): Integer; cdecl; varargs; external 'msvcrt.dll' name 'printf'; begin printf('%d%d%d'#10,1,2,3,4); end. -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From leledumbo_cool at yahoo.co.id Wed Apr 20 09:32:13 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Wed, 20 Apr 2016 00:32:13 -0700 (MST) Subject: [fpc-pascal] Build in a C compiler In-Reply-To: References: <11327366.kVYTVnkxXf@debian8inet> <1461135509984-5725010.post@n5.nabble.com> Message-ID: <1461137533065-5725013.post@n5.nabble.com> > C's comma (sequence) operator is possible to use in Pascal But your example doesn't show its use, probabyl you don't understand which comma operator I mean. Comma is used both as operator and argument/parameter separator in C, what I mean is the former, what you show is the latter. Here's the wikipedia article to make you understand: https://en.wikipedia.org/wiki/Comma_operator -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Build-in-a-C-compiler-tp5725008p5725013.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From hnb.code at gmail.com Wed Apr 20 09:47:46 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Wed, 20 Apr 2016 09:47:46 +0200 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <1461137533065-5725013.post@n5.nabble.com> References: <11327366.kVYTVnkxXf@debian8inet> <1461135509984-5725010.post@n5.nabble.com> <1461137533065-5725013.post@n5.nabble.com> Message-ID: 2016-04-20 9:32 GMT+02:00 leledumbo : > But your example doesn't show its use, probabyl you don't understand which > comma operator I mean. Comma is used both as operator and > argument/parameter > separator in C, what I mean is the former, what you show is the latter. > Here's the wikipedia article to make you understand: > https://en.wikipedia.org/wiki/Comma_operator In that case you are right. -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.whyman at mccallumwhyman.com Wed Apr 20 10:15:40 2016 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Wed, 20 Apr 2016 09:15:40 +0100 Subject: [fpc-pascal] Problem using ipc with OSX and fpc 3.0.0 Message-ID: <57173AAC.9030009@mccallumwhyman.com> I have a problem with some existing code that compiled with fpc 2.6.4 under OSX and does not compile with fpc 3.0.0. The problem is that the code makes a direct call to the semctl function (defined in ipc.pp) and uses the SEM_GETVAL constant as the command value. "Identifier not found errors" are returned for SEM_GETVAL (and SEM_SETVAL as well). Checking the ipc.pp source, both SEM_GETVAL and SEM_SETVAL are defined for Linux, but when it comes to alternative flavours of unix you now see: {$if not defined(aix) and not defined(darwin)} SEM_GETNCNT = 3; { Return the value of sempid (READ) } SEM_GETPID = 4; { Return the value of semval (READ) } SEM_GETVAL = 5; { Return semvals into arg.array (READ) } SEM_GETALL = 6; { Return the value of semzcnt (READ) } SEM_GETZCNT = 7; { Set the value of semval to arg.val (ALTER) } SEM_SETVAL = 8; { Set semvals from arg.array (ALTER) } SEM_SETALL = 9; {$endif} That is these identifiers appear to have been removed for OSX and with no alternative given. This was not the case with 2.6.4. Does anyone know why this was done and, if so, how calls to semctl should have their command value given under OSX (preferably in a platform independent manner). Tony Whyman MWA From mschnell at lumino.de Tue Apr 19 10:11:50 2016 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 19 Apr 2016 10:11:50 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5715CEBB.2080704@elis.ugent.be> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> <5715CEBB.2080704@elis.ugent.be> Message-ID: <5715E846.3080004@lumino.de> On 04/19/2016 08:22 AM, Jonas Maebe wrote: > > No, it does not. Please tell me which sentence of > http://wiki.freepascal.org/FPC_Unicode_support#String_constants > suggests that in any way. I just was making fun of myself, naively supposing the contrary :-) ;-) -Michael From mschnell at lumino.de Tue Apr 19 10:22:40 2016 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 19 Apr 2016 10:22:40 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5715CEBB.2080704@elis.ugent.be> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> <5715CEBB.2080704@elis.ugent.be> Message-ID: <5715EAD0.5080002@lumino.de> On 04/19/2016 08:22 AM, Jonas Maebe wrote: > When any {$codepage xxx} directive is specified, string constants in > the source are represented in a way that makes lossless conversion to > any other code page possible. This conversion to the target code page > is performed at compile time where possible (when the target code page > cannot change at run time), and otherwise at run time. > Of course I do understand that. But anyway, AFAIK, UTF8 already is a way of lossless coding, so I don't see a forcing necessity to convert that to UTF16 at compile time. And as far as I understand, if the user does not take some means, the executable will work with 8 bit coding and very likely with UTF8, so holding the constants as UTF16 increases as well memory as CPU resource usage. (I am not trying to bash anybody ! It obviously does work nicely and supposedly close to always as expected, and the possible resource overhead will be extremely rare and minimal). -Michael From mschnell at lumino.de Tue Apr 19 10:30:11 2016 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 19 Apr 2016 10:30:11 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5715CEBB.2080704@elis.ugent.be> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> <5715CEBB.2080704@elis.ugent.be> Message-ID: <5715EC93.7010903@lumino.de> BTW.: http://www.freepascal.org/docs-html/rtl/system/defaultsystemcodepage.html says that DefaultSystemcodepage can be modified in the user code at runtime. I suppose that will change the way strings with StringCodePage() = CP_ACP are handled. I'll do some tests... -Michael From jonas.maebe at elis.ugent.be Wed Apr 20 11:05:18 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Wed, 20 Apr 2016 11:05:18 +0200 Subject: [fpc-pascal] Problem using ipc with OSX and fpc 3.0.0 In-Reply-To: <57173AAC.9030009@mccallumwhyman.com> References: <57173AAC.9030009@mccallumwhyman.com> Message-ID: <20160420110518.Horde.c2C8CEisJlFXF0ZOFZN02OA@mail.elis.ugent.be> Tony Whyman wrote on Wed, 20 Apr 2016: > The problem is that the code makes a direct call to the semctl > function (defined in ipc.pp) and uses the SEM_GETVAL constant as the > command value. "Identifier not found errors" are returned for > SEM_GETVAL (and SEM_SETVAL as well). That's indeed a bug in FPC 3.0, where these constants were accidentally disabled for Darwin. They have been re-enabled in svn already, and this fix will be in FPC 3.0.2. To work around this bug, you can copy the constants to your own source file for now. Jonas From jonas.maebe at elis.ugent.be Wed Apr 20 11:26:19 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Wed, 20 Apr 2016 11:26:19 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <5715EAD0.5080002@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> <5715CEBB.2080704@elis.ugent.be> <5715EAD0.5080002@lumino.de> Message-ID: <20160420112619.Horde.vCkyXEisJlFXF0s7mJmXn1A@mail.elis.ugent.be> Michael Schnell wrote on Tue, 19 Apr 2016: > On 04/19/2016 08:22 AM, Jonas Maebe wrote: >> When any {$codepage xxx} directive is specified, string constants >> in the source are represented in a way that makes lossless >> conversion to any other code page possible. This conversion to the >> target code page is performed at compile time where possible (when >> the target code page cannot change at run time), and otherwise at >> run time. >> > Of course I do understand that. > > But anyway, AFAIK, UTF8 already is a way of lossless coding, so I > don't see a forcing necessity to convert that to UTF16 at compile > time. And as far as I understand, if the user does not take some > means, the executable will work with 8 bit coding and very likely > with UTF8, > so holding the constants as UTF16 increases as well > memory as CPU resource usage. The reasons are a) the FPC compiler binary itself prior to 3.x did not contain any UTF-8 encoding support. All it could do was convert the source file code page to UTF-16. b) FPC's widestring manager does not contain any interface to directly convert from one 8 bit encoding to another, only from 16 bit to 8 bit and vice versa (which also made it useless to convert to UTF-8 at compile time, since there was no way to convert it to another code page at run time except by making a round trip via UTF-16 anyway). The reason is that these helpers were already necessary to convert between widestring/unicodestring and other types when assigning such variables to each other c) changing b) would require a lot of testing because not all code page conversion libraries/OS interfaces support converting from any arbitrary character set to any other arbitrary character set. While it is likely that they all support converting from arbitrary code pages to UTF-8 and back (like they do for UTF-16), this would still have to be tested and additionally such an interface would undoubtedly also starting to get used for other code pages by people unaware of this limitation. Adding an interface limited to converting from/to UTF-8 would be another option to address that though. In the end it would be a lot of work, result in a lot of extra code that may not work everywhere (or in specialised routines), and it would be for a use case you can already address yourself if you absolutely want to be completely UTF-8-centric: you can declare your string variables as UTF8Stringm since then the conversion to UTF-8 for constant strings will happen at compile time. If your DefaultSystemCodePage is CP_UTF8, no extra conversion will happen when assigning/converting these variables to regular ansistrings. Furthermore, converting from UTF-8 to other code pages is probably slower than from UTF-16, since UTF-8 is a more complex encoding for most characters. The fact that other things are less convenient if you use UTF8String is the price you will have to pay for such code specialisation (which probably won't make any noticeable difference in 99.999% of the cases anyway). Jonas From marcov at stack.nl Wed Apr 20 13:13:45 2016 From: marcov at stack.nl (Marco van de Voort) Date: Wed, 20 Apr 2016 13:13:45 +0200 (CEST) Subject: [fpc-pascal] Build in a C compiler In-Reply-To: Message-ID: <20160420111345.95A8273036@toad.stack.nl> In our previous episode, Mark Morgan Lloyd said: > > > > Pascal and C are close related. > > No. Pascal and ALGOL are closely related, C and ALGOL are closely > related. Pascal and C are not so closely related. Did ALGOL standarize the preprocessor? The high reliance on preprocessor is often a hinderance in automated C conversion. From rainerstratmann at t-online.de Wed Apr 20 13:29:34 2016 From: rainerstratmann at t-online.de (Rainer Stratmann) Date: Wed, 20 Apr 2016 13:29:34 +0200 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: References: <11327366.kVYTVnkxXf@debian8inet> Message-ID: <4639615.s5dduJRsso@debian8inet> Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd: > No. Pascal and ALGOL are closely related, C and ALGOL are closely > related. Pascal and C are not so closely related. As you can see here Pascal, C, and Basic are very close related. http://www.mikroe.com/compilers From pascaldragon at googlemail.com Wed Apr 20 14:17:41 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 20 Apr 2016 14:17:41 +0200 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <4639615.s5dduJRsso@debian8inet> References: <11327366.kVYTVnkxXf@debian8inet> <4639615.s5dduJRsso@debian8inet> Message-ID: Am 20.04.2016 13:29 schrieb "Rainer Stratmann" : > > Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd: > > No. Pascal and ALGOL are closely related, C and ALGOL are closely > > related. Pascal and C are not so closely related. > > As you can see here Pascal, C, and Basic are very close related. > > http://www.mikroe.com/compilers By that logic C#, C++, VB.net and F# must be closely related as well, because Microsoft is providing compilers for all four... No, C and Pascal are *not* closely related. And it surely isn't done with replacing begin and end with curly brackets! Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From markMLl.fpc-pascal at telemetry.co.uk Wed Apr 20 14:40:19 2016 From: markMLl.fpc-pascal at telemetry.co.uk (Mark Morgan Lloyd) Date: Wed, 20 Apr 2016 12:40:19 +0000 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <4639615.s5dduJRsso@debian8inet> References: <11327366.kVYTVnkxXf@debian8inet> <4639615.s5dduJRsso@debian8inet> Message-ID: Rainer Stratmann wrote: > Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd: >> No. Pascal and ALGOL are closely related, C and ALGOL are closely >> related. Pascal and C are not so closely related. > > As you can see here Pascal, C, and Basic are very close related. > > http://www.mikroe.com/compilers If you want to believe that BASIC- as originally implemented- and ALGOL are related then go ahead and do so. But the politest thing I can say is that it doesn't make you look particularly well-informed. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From markMLl.fpc-pascal at telemetry.co.uk Wed Apr 20 14:42:14 2016 From: markMLl.fpc-pascal at telemetry.co.uk (Mark Morgan Lloyd) Date: Wed, 20 Apr 2016 12:42:14 +0000 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <20160420111345.95A8273036@toad.stack.nl> References: <20160420111345.95A8273036@toad.stack.nl> Message-ID: Marco van de Voort wrote: > In our previous episode, Mark Morgan Lloyd said: >>> Pascal and C are close related. >> No. Pascal and ALGOL are closely related, C and ALGOL are closely >> related. Pascal and C are not so closely related. > > Did ALGOL standarize the preprocessor? The high reliance on preprocessor is > often a hinderance in automated C conversion. Burroughs ALGOL (-60 implied) had include and define as part of the language. I think they were later moved into a preprocessor to make it possible to implement them on smaller computers. Sorry, having a bad day so rushed. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From bartjunk64 at gmail.com Wed Apr 20 16:02:25 2016 From: bartjunk64 at gmail.com (Bart) Date: Wed, 20 Apr 2016 16:02:25 +0200 Subject: [fpc-pascal] FCL maskutils incompatible with Delphi In-Reply-To: References: Message-ID: On 4/19/16, silvioprog wrote: > Yes, he (Handlei) reported it at Brazillian group, but he didn't tell us > that had already reported that at bugtracker. > > The patch was sent from another member, and he told us that it fix the > current maskutils.pp unit, I just sent it here as they asked me. > > Can I send this patch to #30020 or just wait for new MaskUtils > implementation? Send it to the bugreport anyway. The new implementation I wrote is ot going to be implemented soon (see related thread for reasons why). Bart From rainerstratmann at t-online.de Wed Apr 20 16:04:10 2016 From: rainerstratmann at t-online.de (Rainer Stratmann) Date: Wed, 20 Apr 2016 16:04:10 +0200 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: References: <11327366.kVYTVnkxXf@debian8inet> <4639615.s5dduJRsso@debian8inet> Message-ID: <5164151.nPImp9aJ4A@debian8inet> Am Mittwoch, 20. April 2016, 12:40:19 schrieb Mark Morgan Lloyd: > > http://www.mikroe.com/compilers > > If you want to believe that BASIC- as originally implemented- and ALGOL > are related then go ahead and do so. But the politest thing I can say is > that it doesn't make you look particularly well-informed. You can go to the company and say poliltely to them that they are not well informed. I don't know if they take you serious. From jonas.maebe at elis.ugent.be Wed Apr 20 16:08:29 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Wed, 20 Apr 2016 16:08:29 +0200 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <11327366.kVYTVnkxXf@debian8inet> References: <11327366.kVYTVnkxXf@debian8inet> Message-ID: <20160420160829.Horde.46NkPEisJlFXF41dK-FzEgA@mail.elis.ugent.be> Hi. Please continue this thread to the fpc-other list. Thanks, Jonas FPC mailing lists admin From freedos.la at gmail.com Wed Apr 20 16:45:07 2016 From: freedos.la at gmail.com (Ralf Quint) Date: Wed, 20 Apr 2016 07:45:07 -0700 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <4639615.s5dduJRsso@debian8inet> References: <11327366.kVYTVnkxXf@debian8inet> <4639615.s5dduJRsso@debian8inet> Message-ID: <571795F3.1000806@gmail.com> On 4/20/2016 4:29 AM, Rainer Stratmann wrote: > Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd: >> No. Pascal and ALGOL are closely related, C and ALGOL are closely >> related. Pascal and C are not so closely related. > As you can see here Pascal, C, and Basic are very close related. > > http://www.mikroe.com/compilers > I think you are jumping to conclusion here. It is more likely that they spend the time in the past (they are around for quite a while) to build their specific Basic, Pascal and C compiler front end and just have to replace the actual code generator for each architecture they support. Just because a company offers compilers for various languages, with a common IDE, doesn't mean that those compilers are "closely related". Just take Borland of old, Turbo Pascal, Turbo C, Turbo Basic, Turbo Prolog, they all used a very similar IDE but the actual compiler had all completely different origins... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From dec12 at avidsoft.com.hk Thu Apr 21 05:44:30 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Thu, 21 Apr 2016 11:44:30 +0800 Subject: [fpc-pascal] Is Generics.collections stable? Message-ID: <57184C9E.4030108@avidsoft.com.hk> Has Anyone used Generics.Collections at https://github.com/dathox/generics.collections ? Is it stable enough for production use? Dennis From mailinglists at geldenhuys.co.uk Thu Apr 21 06:26:20 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 21 Apr 2016 05:26:20 +0100 Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: <57184C9E.4030108@avidsoft.com.hk> References: <57184C9E.4030108@avidsoft.com.hk> Message-ID: <5718566C.9080407@geldenhuys.co.uk> On 2016-04-21 04:44, Dennis wrote: > Is it stable enough for production use? I don't see a single unit test, so that would make me weary. Regards, Graeme From hnb.code at gmail.com Thu Apr 21 08:27:06 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Thu, 21 Apr 2016 08:27:06 +0200 Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: <57184C9E.4030108@avidsoft.com.hk> References: <57184C9E.4030108@avidsoft.com.hk> Message-ID: 2016-04-21 5:44 GMT+02:00 Dennis : > Has Anyone used Generics.Collections at > https://github.com/dathox/generics.collections ? > > Is it stable enough for production use? Generics.Collections library is used for daily production in my company without problems. Especially TDictionary is well tested. -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From hnb.code at gmail.com Thu Apr 21 08:31:42 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Thu, 21 Apr 2016 08:31:42 +0200 Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: <5718566C.9080407@geldenhuys.co.uk> References: <57184C9E.4030108@avidsoft.com.hk> <5718566C.9080407@geldenhuys.co.uk> Message-ID: 2016-04-21 6:26 GMT+02:00 Graeme Geldenhuys : > I don't see a single unit test, so that would make me weary. > Feel free to help in that field. I have inner tests, but I don't have time to adjust them for public release :\ anyway you are right, that can be confusing. -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From leledumbo_cool at yahoo.co.id Thu Apr 21 09:51:54 2016 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Thu, 21 Apr 2016 00:51:54 -0700 (MST) Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: <5718566C.9080407@geldenhuys.co.uk> References: <57184C9E.4030108@avidsoft.com.hk> <5718566C.9080407@geldenhuys.co.uk> Message-ID: <1461225114611-5725034.post@n5.nabble.com> > I don't see a single unit test, so that would make me weary. I just fork it. I'll try to work on the unit test. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Is-Generics-collections-stable-tp5725030p5725034.html Sent from the Free Pascal - General mailing list archive at Nabble.com. From dec12 at avidsoft.com.hk Thu Apr 21 09:59:59 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Thu, 21 Apr 2016 15:59:59 +0800 Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: References: <57184C9E.4030108@avidsoft.com.hk> Message-ID: <5718887F.2040407@avidsoft.com.hk> Maciej Izak wrote: > 2016-04-21 5:44 GMT+02:00 Dennis >: > > Has Anyone used Generics.Collections at > https://github.com/dathox/generics.collections ? > > Is it stable enough for production use? > > > Generics.Collections library is used for daily production in my > company without problems. Especially TDictionary is well tested. > > -- > Best regards, > Maciej Izak Thanks for info. Dennis From dec12 at avidsoft.com.hk Thu Apr 21 10:17:39 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Thu, 21 Apr 2016 16:17:39 +0800 Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: <5718566C.9080407@geldenhuys.co.uk> References: <57184C9E.4030108@avidsoft.com.hk> <5718566C.9080407@geldenhuys.co.uk> Message-ID: <57188CA3.8020600@avidsoft.com.hk> Graeme Geldenhuys wrote: > On 2016-04-21 04:44, Dennis wrote: >> Is it stable enough for production use? > I don't see a single unit test, so that would make me weary. > > Regards, > Graeme > By the way, I cannot find any unit tests for fgl unit? Where are they located? Are they absent as well? Dennis From el.es.cr at gmail.com Wed Apr 20 18:25:18 2016 From: el.es.cr at gmail.com (Lukasz Sokol) Date: Wed, 20 Apr 2016 17:25:18 +0100 Subject: [fpc-pascal] Build in a C compiler In-Reply-To: <5164151.nPImp9aJ4A@debian8inet> References: <11327366.kVYTVnkxXf@debian8inet> <4639615.s5dduJRsso@debian8inet> <5164151.nPImp9aJ4A@debian8inet> Message-ID: On 20/04/16 15:04, Rainer Stratmann wrote: > Am Mittwoch, 20. April 2016, 12:40:19 schrieb Mark Morgan Lloyd: >>> http://www.mikroe.com/compilers >> >> If you want to believe that BASIC- as originally implemented- and ALGOL >> are related then go ahead and do so. But the politest thing I can say is >> that it doesn't make you look particularly well-informed. > > You can go to the company and say poliltely to them that they are not well > informed. I don't know if they take you serious. Existence of Pascal front-end / parser/ IR creator for any compiler suite (e.g. clang, GNU, whatever) does /not/ /really/ prove anything of the sort of you are implying. -L. From mschnell at lumino.de Wed Apr 20 11:58:37 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 20 Apr 2016 11:58:37 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <20160420112619.Horde.vCkyXEisJlFXF0s7mJmXn1A@mail.elis.ugent.be> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> <5715CEBB.2080704@elis.ugent.be> <5715EAD0.5080002@lumino.de> <20160420112619.Horde.vCkyXEisJlFXF0s7mJmXn1A@mail.elis.ugent.be> Message-ID: <571752CD.5040007@lumino.de> On 04/20/2016 11:26 AM, Jonas Maebe wrote: > > The reasons are Thanks a lot or the great explanation. So there are good reasons to stay with the status-quo (unless doing a completely new versatile and straight forward String implementation that exceeds functionality and "mind" Delphi allows, but this again would be a whole lot of work with maybe limited benefit) -Michael From michael at freepascal.org Thu Apr 21 10:43:52 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 21 Apr 2016 10:43:52 +0200 (CEST) Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: <57188CA3.8020600@avidsoft.com.hk> References: <57184C9E.4030108@avidsoft.com.hk> <5718566C.9080407@geldenhuys.co.uk> <57188CA3.8020600@avidsoft.com.hk> Message-ID: On Thu, 21 Apr 2016, Dennis wrote: > > > Graeme Geldenhuys wrote: >> On 2016-04-21 04:44, Dennis wrote: >>> Is it stable enough for production use? >> I don't see a single unit test, so that would make me weary. >> >> Regards, >> Graeme >> > By the way, I cannot find any unit tests for fgl unit? Where are they > located? Are they absent as well? They are absent. Michael. From marcov at stack.nl Thu Apr 21 11:44:40 2016 From: marcov at stack.nl (Marco van de Voort) Date: Thu, 21 Apr 2016 11:44:40 +0200 (CEST) Subject: [fpc-pascal] Is Generics.collections stable? In-Reply-To: <57184C9E.4030108@avidsoft.com.hk> Message-ID: <20160421094440.B399973036@toad.stack.nl> In our previous episode, Dennis said: > Has Anyone used Generics.Collections at > https://github.com/dathox/generics.collections ? > > Is it stable enough for production use? I used them in my opengl work (dual compile with Delphi), and that worked fine. From dec12 at avidsoft.com.hk Fri Apr 22 11:51:17 2016 From: dec12 at avidsoft.com.hk (Dennis) Date: Fri, 22 Apr 2016 17:51:17 +0800 Subject: [fpc-pascal] TPersistent does not call IFPObserved.FPONotifyObservers Message-ID: <5719F415.1090707@avidsoft.com.hk> I have a class inheriting from Tpersistent: type TCondition=class( TPersistent, ICondition) var aCondition : TCondition; but surprisingly, when I call aCondition.FPOAttachObserver(someobj); I discovered that nothing was executed. I used debugger to step through this line and nothing was executed. As a result, when this aCondition is destroyed, it won't notify the observers. I checked the source code "persist.inc", it is indeed implemented! procedure TPersistent.FPOAttachObserver(AObserver: TObject); Var I : IFPObserver; begin If Not AObserver.GetInterface(SGUIDObserver,I) then Raise EObserver.CreateFmt(SErrNotObserver,[AObserver.ClassName]); If not Assigned(FObservers) then FObservers:=TFPList.Create; FObservers.Add(I); end; What is wrong? I am using FPC 3.1.1 trunk downloaded a few days ago. From the documentation, there is this line: TPersistent implements the IFPObserved interface for the benefit of descendent classes, but does not call IFPObserved.FPONotifyObservers . Descendents such as TStrings and TCollection and TCollectionItem do use it. But the source code DOES CALL IFPObserved.FPONotifyObservers ! destructor TPersistent.Destroy; begin If Assigned(FObservers) then begin FPONotifyObservers(Self,ooFree,Nil); FreeAndNil(FObservers); end; inherited Destroy; end; Why did the documentation say that? Why was those code seemed not linked at all? Some compiler options I messed up? Dennis From mse00000 at gmail.com Fri Apr 22 16:29:45 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Fri, 22 Apr 2016 16:29:45 +0200 Subject: [fpc-pascal] Unit path search order Message-ID: <201604221629.45827.mse00000@gmail.com> Hi, http://www.freepascal.org/docs-html/current/user/usersu7.html#x21-280003.1.2 states: " You can add a directory to the unit search path with the (-Fu (see page 100)) option. Every occurrence of one of these options will insert a directory to the unit search path. i.e. the last path on the command line will be searched first. " Does this still apply? My experiments seem to indicate that the first path on commandline is searched first. Martin From jonas.maebe at elis.ugent.be Sat Apr 23 10:40:58 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Sat, 23 Apr 2016 10:40:58 +0200 Subject: [fpc-pascal] Unit path search order In-Reply-To: <201604221629.45827.mse00000@gmail.com> References: <201604221629.45827.mse00000@gmail.com> Message-ID: <571B351A.60009@elis.ugent.be> Martin Schreiber wrote: > http://www.freepascal.org/docs-html/current/user/usersu7.html#x21-280003.1.2 > states: > " > You can add a directory to the unit search path with the (-Fu (see page 100)) > option. Every occurrence of one of these options will insert a directory to > the unit search path. i.e. the last path on the command line will be searched > first. > " > Does this still apply? From looking at the compiler code: yes. Jonas From mse00000 at gmail.com Sat Apr 23 11:18:48 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Sat, 23 Apr 2016 11:18:48 +0200 Subject: [fpc-pascal] Unit path search order In-Reply-To: <571B351A.60009@elis.ugent.be> References: <201604221629.45827.mse00000@gmail.com> <571B351A.60009@elis.ugent.be> Message-ID: <201604231118.48754.mse00000@gmail.com> On Saturday 23 April 2016 10:40:58 Jonas Maebe wrote: > Martin Schreiber wrote: > > http://www.freepascal.org/docs-html/current/user/usersu7.html#x21-280003. > >1.2 states: > > " > > You can add a directory to the unit search path with the (-Fu (see page > > 100)) option. Every occurrence of one of these options will insert a > > directory to the unit search path. i.e. the last path on the command line > > will be searched first. > > " > > Does this still apply? > > From looking at the compiler code: yes. > I made a test. in ./: " program conssoletest; uses testunit; begin testunit0(); end. " in ./test: " unit testunit; interface procedure testunit0(); implementation procedure testunit0(); begin end; end. " in ./test1: " unit testunit; interface procedure testunit1(); implementation procedure testunit1(); begin end; end. " " mse at linuxmse:~/proj/consoletest> fpc -oconssoletest -Fu./test -Fu./test1 conssoletest.pas Free Pascal Compiler version 3.0.0rc2 [2015/10/14] for i386 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for i386 Compiling conssoletest.pas Compiling ./test/testunit.pas Linking conssoletest /usr/bin/ld: warning: link.res contains output sections; did you forget -T? 14 lines compiled, 0.2 sec " " mse at linuxmse:~/proj/consoletest> fpc -oconssoletest -Fu./test1 -Fu./test conssoletest.pas Free Pascal Compiler version 3.0.0rc2 [2015/10/14] for i386 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for i386 Compiling conssoletest.pas Compiling ./test1/testunit.pas conssoletest.pas(5,2) Error: Identifier not found "testunit0" conssoletest.pas(7) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/bin/ppc386 returned an error exitcode " Martin From andreas.klausmann at web.de Sat Apr 23 11:23:25 2016 From: andreas.klausmann at web.de (Andreas Klausmann) Date: Sat, 23 Apr 2016 11:23:25 +0200 Subject: [fpc-pascal] Linux: resolving hostnames in local network In-Reply-To: References: Message-ID: <571B3F0D.4080409@web.de> Hi, how can I resolve hostnames in a local (private) network under linux? Both gethostbyname() and THostResolver work fine for google.com etc, but not for local hostnames like testhost.local. Testhost is reachable from console by hostname: ping testhost.local -> success (resolved in background by avahi) gethostbyname() works fine under Windows even for LAN resolution (resolved in background by Netbios name service). Currently I'm working on Ubuntu 15.10 on a raspberry, fpc 3.0. Best regards! Andreas From michael at freepascal.org Sat Apr 23 11:30:19 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sat, 23 Apr 2016 11:30:19 +0200 (CEST) Subject: [fpc-pascal] Linux: resolving hostnames in local network In-Reply-To: <571B3F0D.4080409@web.de> References: <571B3F0D.4080409@web.de> Message-ID: On Sat, 23 Apr 2016, Andreas Klausmann wrote: > Hi, > how can I resolve hostnames in a local (private) network under linux? > Both gethostbyname() and THostResolver work fine for google.com etc, but > not for local hostnames like testhost.local. > Testhost is reachable from console by hostname: ping testhost.local -> > success (resolved in background by avahi) > > gethostbyname() works fine under Windows even for LAN resolution > (resolved in background by Netbios name service). > > Currently I'm working on Ubuntu 15.10 on a raspberry, fpc 3.0. You will need to use the C library routines for this. The FPC native implementation does not work with avahi or local DNS caches. Michael. From marcov at stack.nl Sat Apr 23 12:42:03 2016 From: marcov at stack.nl (Marco van de Voort) Date: Sat, 23 Apr 2016 12:42:03 +0200 (CEST) Subject: [fpc-pascal] Linux: resolving hostnames in local network In-Reply-To: Message-ID: <20160423104203.F21A373036@toad.stack.nl> In our previous episode, Michael Van Canneyt said: > You will need to use the C library routines for this. (which is in unit cnetdb in somewhat recent FPC's) From mailinglists at geldenhuys.co.uk Sat Apr 23 15:30:55 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sat, 23 Apr 2016 14:30:55 +0100 Subject: [fpc-pascal] Linux: resolving hostnames in local network In-Reply-To: <571B3F0D.4080409@web.de> References: <571B3F0D.4080409@web.de> Message-ID: <571B790F.6080100@geldenhuys.co.uk> On 2016-04-23 10:23, Andreas Klausmann wrote: > Testhost is reachable from console by hostname: ping testhost.local -> > success (resolved in background by avahi) Not sure, but you could always create a wrapper function or class around the OS 'ping' command, or nslookup. Read the program results and let your wrapper function or class return that as the resolved name. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From andreas.klausmann at web.de Sat Apr 23 20:38:20 2016 From: andreas.klausmann at web.de (Andreas Klausmann) Date: Sat, 23 Apr 2016 20:38:20 +0200 Subject: [fpc-pascal] Linux: resolving hostnames in local network In-Reply-To: <20160423104203.F21A373036@toad.stack.nl> References: <20160423104203.F21A373036@toad.stack.nl> Message-ID: <571BC11C.8080100@web.de> Thanks, cnetdb.gethostbyname() works fine (at least on my raspberry). :) Creating a wrapper function is recently my work-around for an actual ping component (since linux doesn't seem to have a corresponding component like ping.dll and I want to ping as non-root) Am 23.04.2016 um 12:42 schrieb Marco van de Voort: > In our previous episode, Michael Van Canneyt said: >> You will need to use the C library routines for this. > (which is in unit cnetdb in somewhat recent FPC's) > _______________________________________________ > fpc-pascal maillist - fpc-pascal at lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > > From skalogryz.lists at gmail.com Sun Apr 24 02:57:51 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Sat, 23 Apr 2016 20:57:51 -0400 Subject: [fpc-pascal] c-blocks odd hints Message-ID: Hello, The compiler seems to generate odd hints: Local absolutevar "FPC_BLOCK_SELF" is not used Here's the code. if Assigned(gc.extendedGamepad) then gc.extendedGamepad.setValueChangedHandler(GamePadChange) else if Assigned(gc.gamepad) then // <-- hint here gc.gamepad.setValueChangedHandler(GamePadChange); gc.setControllerPausedHandler(PauseHandler); // <--hint here Why? PauseHandler and GamePadChange are procedures: procedure GamePadChange(pad: GCGamePad; el: GCControllerElement); procedure PauseHandler(gc: GCController); thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Sun Apr 24 06:31:52 2016 From: md at delfire.net (Marcos Douglas) Date: Sun, 24 Apr 2016 01:31:52 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS Message-ID: Hi, I'm trying to use FastCGI on IIS without success. https://www.iis.net/configreference/system.webserver/fastcgi My environment is: - FPC 2.6.5 - Lazarus 1.5 - IIS - Windows 10 The CGI protocol works fine, but FastCGI not. I got an error 500. If I change the fpFCGI to fpcgi — and comment the Application.Port — everything works fine. Could you help me? Regards, Marcos Douglas From md at delfire.net Sun Apr 24 07:08:18 2016 From: md at delfire.net (Marcos Douglas) Date: Sun, 24 Apr 2016 02:08:18 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, Apr 24, 2016 at 1:31 AM, Marcos Douglas wrote: > Hi, > > I'm trying to use FastCGI on IIS without success. > https://www.iis.net/configreference/system.webserver/fastcgi > > My environment is: > - FPC 2.6.5 > - Lazarus 1.5 > - IIS > - Windows 10 > > The CGI protocol works fine, but FastCGI not. I got an error 500. > If I change the fpFCGI to fpcgi — and comment the Application.Port — > everything works fine. I've found the problem: The Application.Port cannot be setted. I think this property (Port) is only used in a self-contained server application. Am I right? Regards, Marcos Douglas From michael at freepascal.org Sun Apr 24 07:40:49 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 24 Apr 2016 07:40:49 +0200 (CEST) Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, 24 Apr 2016, Marcos Douglas wrote: > On Sun, Apr 24, 2016 at 1:31 AM, Marcos Douglas wrote: >> Hi, >> >> I'm trying to use FastCGI on IIS without success. >> https://www.iis.net/configreference/system.webserver/fastcgi >> >> My environment is: >> - FPC 2.6.5 >> - Lazarus 1.5 >> - IIS >> - Windows 10 >> >> The CGI protocol works fine, but FastCGI not. I got an error 500. >> If I change the fpFCGI to fpcgi — and comment the Application.Port — >> everything works fine. > > I've found the problem: > The Application.Port cannot be setted. > > I think this property (Port) is only used in a self-contained server > application. Am I right? You are right, Michael. From md at delfire.net Sun Apr 24 08:07:11 2016 From: md at delfire.net (Marcos Douglas) Date: Sun, 24 Apr 2016 03:07:11 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, Apr 24, 2016 at 2:40 AM, Michael Van Canneyt wrote: > >> I've found the problem: >> The Application.Port cannot be setted. >> >> I think this property (Port) is only used in a self-contained server >> application. Am I right? > > > You are right, OK, thanks. Now I have another problem only in fcl-web framework, I think. I have one module: ModuleName= 'pdf' ModuleClass= TPDFModule and two actions: 'act1' 'act2' Browser: http://localhost:2015/fcgitest/pdf/act1 Error: The application encountered the following error: Error: Could not determine HTTP module for request "fcgitest.exe" Stack trace: $004328E3 $00433012 $004323E2 From michael at freepascal.org Sun Apr 24 08:58:21 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 24 Apr 2016 08:58:21 +0200 (CEST) Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, 24 Apr 2016, Marcos Douglas wrote: > On Sun, Apr 24, 2016 at 2:40 AM, Michael Van Canneyt > wrote: >> >>> I've found the problem: >>> The Application.Port cannot be setted. >>> >>> I think this property (Port) is only used in a self-contained server >>> application. Am I right? >> >> >> You are right, > > OK, thanks. > > Now I have another problem only in fcl-web framework, I think. > > I have one module: > ModuleName= 'pdf' > ModuleClass= TPDFModule > > and two actions: > 'act1' > 'act2' > > Browser: > http://localhost:2015/fcgitest/pdf/act1 > > Error: > > The application encountered the following error: > Error: Could not determine HTTP module for request "fcgitest.exe" Why do you put fcgitest in the request ? Michael. From mse00000 at gmail.com Sun Apr 24 09:15:17 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Sun, 24 Apr 2016 09:15:17 +0200 Subject: [fpc-pascal] Unit path search order In-Reply-To: <201604231118.48754.mse00000@gmail.com> References: <201604221629.45827.mse00000@gmail.com> <571B351A.60009@elis.ugent.be> <201604231118.48754.mse00000@gmail.com> Message-ID: <201604240915.17794.mse00000@gmail.com> On Saturday 23 April 2016 11:18:48 Martin Schreiber wrote: > On Saturday 23 April 2016 10:40:58 Jonas Maebe wrote: > > Martin Schreiber wrote: > > > http://www.freepascal.org/docs-html/current/user/usersu7.html#x21-28000 > > >3. 1.2 states: > > > " > > > You can add a directory to the unit search path with the (-Fu (see page > > > 100)) option. Every occurrence of one of these options will insert a > > > directory to the unit search path. i.e. the last path on the command > > > line will be searched first. > > > " > > > Does this still apply? > > > > From looking at the compiler code: yes. > > I made a test. > [...] Bugreport is here: http://bugs.freepascal.org/view.php?id=30053 Martin From md at delfire.net Sun Apr 24 14:26:40 2016 From: md at delfire.net (Marcos Douglas) Date: Sun, 24 Apr 2016 09:26:40 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, Apr 24, 2016 at 3:58 AM, Michael Van Canneyt wrote: >> Browser: >> http://localhost:2015/fcgitest/pdf/act1 >> >> Error: >> >> The application encountered the following error: >> Error: Could not determine HTTP module for request "fcgitest.exe" > > > Why do you put fcgitest in the request ? Sorry, I didn't understand what you mean. I need to put the executable name in the URL, like "mycgi.cgi" in these examples: http://wiki.freepascal.org/fcl-web ...and there is a typo (missing ".exe"). The 'correct' is: http://localhost:2015/fcgitest.exe/pdf/act1 ...but it does not solve the problem. :( Regards, Marcos Douglas From md at delfire.net Sun Apr 24 14:50:35 2016 From: md at delfire.net (Marcos Douglas) Date: Sun, 24 Apr 2016 09:50:35 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, Apr 24, 2016 at 9:26 AM, Marcos Douglas wrote: > On Sun, Apr 24, 2016 at 3:58 AM, Michael Van Canneyt > wrote: >>> Browser: >>> http://localhost:2015/fcgitest/pdf/act1 >>> >>> Error: >>> >>> The application encountered the following error: >>> Error: Could not determine HTTP module for request "fcgitest.exe" >> >> >> Why do you put fcgitest in the request ? > > Sorry, I didn't understand what you mean. I need to put the executable > name in the URL, like "mycgi.cgi" in these examples: > http://wiki.freepascal.org/fcl-web > > ...and there is a typo (missing ".exe"). The 'correct' is: > http://localhost:2015/fcgitest.exe/pdf/act1 > > ...but it does not solve the problem. :( My env: Lazarus 1.5 r50201M FPC 2.6.5 i386-win32-win32/win64 So I took his example here \packages\fcl-web\examples\helloworld Compiled it. ISS configured to port 2020. Call in browser http://localhost:2020/helloworld.exe/func1call ...and got the same error: The application encountered the following error: Error: Could not determine HTTP module for request "helloworld.exe" Stack trace: $0042F823 $0042FF52 $0042F322 $00401775 main, line 13 of helloworld.lpr Please, have you any ideas? Best regards, Marcos Douglas From vfclists at gmail.com Sun Apr 24 20:57:10 2016 From: vfclists at gmail.com (vfclists .) Date: Sun, 24 Apr 2016 19:57:10 +0100 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: <571752CD.5040007@lumino.de> References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> <5715CEBB.2080704@elis.ugent.be> <5715EAD0.5080002@lumino.de> <20160420112619.Horde.vCkyXEisJlFXF0s7mJmXn1A@mail.elis.ugent.be> <571752CD.5040007@lumino.de> Message-ID: Isn't some formality in these Unicode discussions called for? Use of everyday language to express things which can only be properly expressed and tested through source code is very confusing. Consider these few sentences by Mattias >>>> It depends. There are two codepages. The real one and the one you tell the compiler. If you tell the compiler that the string literal is 8-bit system codepage, it will copy it without conversion to the binary. Otherwise it converts it to UTF-16 >>>> How do you know what the "real" codepage is at runtime or compile time, as opposed to "the one you tell the compiler"? Is there some macro that can print out which codepages is active at some stage in the compilation or at runtime? Can codepages be switched around at various stages in the compilation? Being an English speaker and writing software for English speakers only, these are issues I have never had to deal with and hopefully, never will, which is just wishful thinking, but I think that all these discussions must be accompanied by code and use cases whch explain them better. I have been looking in these Unicode discussion threads and I am none the wiser after all these years. There must be some test suites in FPC and Lazarus which cover the issues being raised in these discussions. Wouldn't those be a better starting point? Unicode discussions are leading me to appreciate Edsger Dijkstra more and more. ;) -- Frank Church ======================= http://devblog.brahmancreations.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonas.maebe at elis.ugent.be Sun Apr 24 21:36:13 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Sun, 24 Apr 2016 21:36:13 +0200 Subject: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more? In-Reply-To: References: <20160404101817.818D.B7062D51@tgtools.de> <570CA926.4070609@lumino.de> <570E0021.9030303@lumino.de> <570F51D5.3090109@lumino.de> <5710A737.70903@geldenhuys.co.uk> <5710A9CB.5080406@lumino.de> <20160416110246.102194e5@limapholos.matflo.wg> <5714B4B0.2070604@lumino.de> <5715CEBB.2080704@elis.ugent.be> <5715EAD0.5080002@lumino.de> <20160420112619.Horde.vCkyXEisJlFXF0s7mJmXn1A@mail.elis.ugent.be> <571752CD.5040007@lumino.de> Message-ID: <571D202D.4070805@elis.ugent.be> vfclists . wrote: > Isn't some formality in these Unicode discussions called for? Use of > everyday language to express things which can only be properly expressed > and tested through source code is very confusing. The formal definitions can be found at http://wiki.freepascal.org/FPC_Unicode_support > Consider these few sentences by Mattias > > >>>> > It depends. > There are two codepages. The real one and the one you tell the > compiler. > If you tell the compiler that the string literal is 8-bit system > codepage, it will copy it without conversion to the binary. > Otherwise it converts it to UTF-16 > >>>> > > How do you know what the "real" codepage is at runtime or compile time, > as opposed to "the one you tell the compiler"? On the aforementioned page: * "the one you tell the compiler": the source file code page if explicitly specified * "the real code page": the value of DefaultSystemCodePage on startup of your program Jonas From michael at freepascal.org Sun Apr 24 23:21:18 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 24 Apr 2016 23:21:18 +0200 (CEST) Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, 24 Apr 2016, Marcos Douglas wrote: >> http://localhost:2015/fcgitest.exe/pdf/act1 >> >> ...but it does not solve the problem. :( > > My env: Lazarus 1.5 r50201M FPC 2.6.5 i386-win32-win32/win64 > > So I took his example here \packages\fcl-web\examples\helloworld > Compiled it. ISS configured to port 2020. > Call in browser http://localhost:2020/helloworld.exe/func1call I have never tested the Fastcgi support with IIS. The problem is probably that IIS does not provide the same PATHINFO environment variable as Apache or NGINX. The PATHINFO environment variable is used to determine what module needs to be invoked. You can influence this by setting and handling the OnGetModule event of the TFastCGIApplication application object. In this event, you can examine the request, and return the class of the module that must be created. When you do, please save the contents of PATHINFO to some file, and send it here, so I can examine it and adapt the implementation so it can handle IIS as well. Michael. From md at delfire.net Mon Apr 25 04:08:51 2016 From: md at delfire.net (Marcos Douglas) Date: Sun, 24 Apr 2016 23:08:51 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, Apr 24, 2016 at 6:21 PM, Michael Van Canneyt wrote: > > > On Sun, 24 Apr 2016, Marcos Douglas wrote: > >>> http://localhost:2015/fcgitest.exe/pdf/act1 >>> >>> ...but it does not solve the problem. :( >> >> >> My env: Lazarus 1.5 r50201M FPC 2.6.5 i386-win32-win32/win64 >> >> So I took his example here \packages\fcl-web\examples\helloworld >> Compiled it. ISS configured to port 2020. >> Call in browser http://localhost:2020/helloworld.exe/func1call > > > I have never tested the Fastcgi support with IIS. > The problem is probably that IIS does not provide the same PATHINFO > environment variable as Apache or NGINX. > > The PATHINFO environment variable is used to determine what module needs to > be invoked. You can influence this by setting and handling the OnGetModule > event of the TFastCGIApplication application object. In this event, you can > examine the request, and return the class of the module that must be > created. > > When you do, please save the contents of PATHINFO to some file, and send it > here, so I can examine it and adapt the implementation so it can handle IIS > as well. Hi, Doesn't matter if is CGI or FastCGI. Same problem. I did more tests. In my example, I have 1 Module "pdf" and 1 Action "act1". The Module has a DataModuleRequest event: begin AResponse.Content := 'default'; Handled := True; end; The Action has a Request event: begin AResponse.Content := 'list'; Handled := True; end; #1 Call Action URL: http://localhost:2015/fcgitest.exe/act1/ Result: error - Could not determine HTTP module for request "act1" Log: PATHINFO=/fcgitest.exe/act1/ NEXT_PATHINFO=fcgitest.exe #2 Call Module/Action URL: http://localhost:2015/fcgitest.exe/pdf/act1/ Result: print - "default" Log: PATHINFO=/fcgitest.exe/pdf/act1/ NEXT_PATHINFO=fcgitest.exe If you do not have time, maybe I can try to fix. But how we can know what Server is running (Apache, IIS, etc)? Thanks, Marcos Douglas From michael at freepascal.org Mon Apr 25 08:57:09 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 25 Apr 2016 08:57:09 +0200 (CEST) Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Sun, 24 Apr 2016, Marcos Douglas wrote: >> >> When you do, please save the contents of PATHINFO to some file, and send it >> here, so I can examine it and adapt the implementation so it can handle IIS >> as well. > > Hi, > > Doesn't matter if is CGI or FastCGI. Same problem. > > I did more tests. > In my example, I have 1 Module "pdf" and 1 Action "act1". > > The Module has a DataModuleRequest event: > begin > AResponse.Content := 'default'; > Handled := True; > end; > > The Action has a Request event: > begin > AResponse.Content := 'list'; > Handled := True; > end; > > #1 Call Action > URL: http://localhost:2015/fcgitest.exe/act1/ > Result: error - Could not determine HTTP module for request "act1" > Log: > PATHINFO=/fcgitest.exe/act1/ > NEXT_PATHINFO=fcgitest.exe You always need to specify 2 paths: http://localhost:2015/fcgitest.exe/pdf/act1/ Unless you have set a default module and name in the application: AllowDefaultModule:=True; DefaultModuleName:='pdf'; PreferModuleName:=False; > > #2 Call Module/Action > URL: http://localhost:2015/fcgitest.exe/pdf/act1/ > Result: print - "default" > Log: > PATHINFO=/fcgitest.exe/pdf/act1/ > NEXT_PATHINFO=fcgitest.exe Yes, this is a normal response, it seems ? Even so, PATHINFO should not contain /fcgitest.exe/. You can trust Microsoft to do things in an incompatible way :/ Michael. From md at delfire.net Mon Apr 25 15:41:31 2016 From: md at delfire.net (Marcos Douglas) Date: Mon, 25 Apr 2016 10:41:31 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Mon, Apr 25, 2016 at 3:57 AM, Michael Van Canneyt wrote: > You always need to specify 2 paths: > > http://localhost:2015/fcgitest.exe/pdf/act1/ > > Unless you have set a default module and name in the application: > > AllowDefaultModule:=True; > DefaultModuleName:='pdf'; > PreferModuleName:=False; I've read emails on the list that you said that only if the program has more than one Module is necessary to specify two paths. But Ok, for me makes more sense to use 2 paths. >> #2 Call Module/Action >> URL: http://localhost:2015/fcgitest.exe/pdf/act1/ >> Result: print - "default" >> Log: >> PATHINFO=/fcgitest.exe/pdf/act1/ >> NEXT_PATHINFO=fcgitest.exe > > > Yes, this is a normal response, it seems ? Well, I was thinking if an Action should have more priority to execute if I call it directly on URL — but I don't know if the 'Module request' was execute because of the bug on PATHINFO or because it has more priority. > Even so, PATHINFO should not contain /fcgitest.exe/. > You can trust Microsoft to do things in an incompatible way :/ Yeah... :\ So do you will make a patch or doesn't have time in this week? Maybe I can try. Now I know there is a SERVER_SOFTWARE variable to test if is Windows IIS... but if you will fix just tell me, please. I'm still using FPC 2.6.5 version. But I guess this package still works in this version so, do you think can I replace the fcl-web from 2.6.5 to use 3.0.0 version, after the changes? Thanks, Marcos Douglas From sysrpl at gmail.com Mon Apr 25 22:43:58 2016 From: sysrpl at gmail.com (Anthony Walter) Date: Mon, 25 Apr 2016 16:43:58 -0400 Subject: [fpc-pascal] Class/Record helpers on genericd? Message-ID: Sven, Correct me if I'm wrong, but didn't you add support for class/record helpers on generics? For example I'd like to be able to add methods to dynamic arrays: type TArray = array of ; TCompare = function(constref A, B: T): Integer; TArrayHelper = record helper for TArray private ... public procedure Sort(Compare: TCompare); function First: T; function Last: T; function Random: T; // and so on end; As it is right now the compiler will not allow this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Tue Apr 26 07:57:11 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Tue, 26 Apr 2016 07:57:11 +0200 Subject: [fpc-pascal] Class/Record helpers on genericd? In-Reply-To: References: Message-ID: Am 25.04.2016 22:44 schrieb "Anthony Walter" : > > Sven, > > Correct me if I'm wrong, but didn't you add support for class/record helpers on generics? For example I'd like to be able to add methods to dynamic arrays: > > type > TArray = array of ; > TCompare = function(constref A, B: T): Integer; > > TArrayHelper = record helper for TArray > private > ... > public > procedure Sort(Compare: TCompare); > function First: T; > function Last: T; > function Random: T; > // and so on > end; > > As it is right now the compiler will not allow this. No, I did not and it's also not planned. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Mon Apr 25 09:51:21 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 25 Apr 2016 09:51:21 +0200 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: <571DCC79.1030209@lumino.de> Not believing that FCGI will work decently with IIS, my colleagues successfully used a different approach to use their (Delphi) programs via IIS in the Internet. They did a small ISAPI transfer DLL and did the business logic in a Windows Service They linked the two Delphi programs via RemOBJ. I suppose using FPC and some propriety protocol for linking the DLL and the business logic will be doable. -Michael From hnb.code at gmail.com Tue Apr 26 08:24:41 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Tue, 26 Apr 2016 08:24:41 +0200 Subject: [fpc-pascal] Class/Record helpers on genericd? In-Reply-To: References: Message-ID: 2016-04-26 7:57 GMT+02:00 Sven Barth : > > As it is right now the compiler will not allow this. > > No, I did not and it's also not planned. > That is planned in other way, as extra profit of smart pointers (related to new syntax). -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Tue Apr 26 08:39:43 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 26 Apr 2016 08:39:43 +0200 (CEST) Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Mon, 25 Apr 2016, Marcos Douglas wrote: > On Mon, Apr 25, 2016 at 3:57 AM, Michael Van Canneyt > wrote: >> >> >> Yes, this is a normal response, it seems ? > > Well, I was thinking if an Action should have more priority to execute > if I call it directly on URL — but I don't know if the 'Module > request' was execute because of the bug on PATHINFO or because it has > more priority. because of the bug on PATHINFO. You can control the behaviour with the 'PreferModuleName' property. But that only works if there is a default module. > >> Even so, PATHINFO should not contain /fcgitest.exe/. >> You can trust Microsoft to do things in an incompatible way :/ > > Yeah... :\ > So do you will make a patch or doesn't have time in this week? > Maybe I can try. Now I know there is a SERVER_SOFTWARE variable to > test if is Windows IIS... but if you will fix just tell me, please. Well, time is of course an issue, but more importantly, I do not have ISS to test with. I think that PATHINFO needs to be corrected in custcgi.pp: Procedure TCGIRequest.InitFromEnvironment: Something like If Pos('IIS', ServerName)>0 then // Cut binary name from PathInfo It will then also be fixed for FastCGI as it reuses this routine. > > I'm still using FPC 2.6.5 version. But I guess this package still > works in this version so, do you think can I replace the fcl-web from > 2.6.5 to use 3.0.0 version, after the changes? It should not be a problem. Michael. From sysrpl at gmail.com Tue Apr 26 09:11:51 2016 From: sysrpl at gmail.com (Anthony Walter) Date: Tue, 26 Apr 2016 03:11:51 -0400 Subject: [fpc-pascal] Class/Record helpers on genericd? In-Reply-To: References: Message-ID: Okay. Thanks. Just FYI here is my use case. { User defined vertex type } type TColorLitVertex = record Position: TVec3; Normal: TVec3; Color: TVec4; end; { Contiguous data to be fed to an opengl vertex shader attribute } var VertexData: TArray; It would be nice to have both of these types of functionality supported: VertexData[I].Color.Alpha := 0.5; // you can only write to record fields if the container is an array and .. VertexData.Sort(SortZOrder); // you can only have methods on arrays using record helpers, but not generic arrays and later provide a reference to the first color location to opengl (array types make this easiest) ... glVertexAttribPointer(ColorAttribute, 4, GL_FLOAT, GL_FALSE, SizeOf(TColorLitVertex), @VertexData[0].Color); -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Tue Apr 26 15:52:12 2016 From: md at delfire.net (Marcos Douglas) Date: Tue, 26 Apr 2016 10:52:12 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: <571DCC79.1030209@lumino.de> References: <571DCC79.1030209@lumino.de> Message-ID: On Mon, Apr 25, 2016 at 4:51 AM, Michael Schnell wrote: > Not believing that FCGI will work decently with IIS, my colleagues > successfully used a different approach to use their (Delphi) programs via > IIS in the Internet. FCGI works very well on IIS (until now). Regards, Marcos Douglas From md at delfire.net Tue Apr 26 15:55:07 2016 From: md at delfire.net (Marcos Douglas) Date: Tue, 26 Apr 2016 10:55:07 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Tue, Apr 26, 2016 at 3:39 AM, Michael Van Canneyt wrote: > Well, time is of course an issue, but more importantly, I do not have ISS to > test with. > > I think that PATHINFO needs to be corrected in custcgi.pp: > > Procedure TCGIRequest.InitFromEnvironment: > > Something like If Pos('IIS', ServerName)>0 then > // Cut binary name from PathInfo > > It will then also be fixed for FastCGI as it reuses this routine. I'll work on that. Thanks. Regards, Marcos Douglas From md at delfire.net Wed Apr 27 06:11:22 2016 From: md at delfire.net (Marcos Douglas) Date: Wed, 27 Apr 2016 01:11:22 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: On Tue, Apr 26, 2016 at 10:55 AM, Marcos Douglas wrote: > On Tue, Apr 26, 2016 at 3:39 AM, Michael Van Canneyt > wrote: >> Well, time is of course an issue, but more importantly, I do not have ISS to >> test with. >> >> I think that PATHINFO needs to be corrected in custcgi.pp: >> >> Procedure TCGIRequest.InitFromEnvironment: >> >> Something like If Pos('IIS', ServerName)>0 then >> // Cut binary name from PathInfo >> >> It will then also be fixed for FastCGI as it reuses this routine. Hi Michael, Using the original sources of version 2.6.5 I can get the SERVER_SOFTWARE=Microsoft-IIS/10.0 So, I replaced the fcl-web package, version 2.6.5 to use 3.1.1. But in this last version SERVER_SOFTWARE is empty. I don't know why. Look the code below. ===BEGIN=== procedure TCGIRequest.InitFromEnvironment; Var I : Integer; R,V,OV : String; M : TMap; begin For I:=1 to CGIVarCount do begin V:=GetEnvironmentVariable(CGIVarNames[I]); if (V<>'') then begin M:=MapCgiToHTTP[i]; if M.H<>hhUnknown then SetHeader(M.H,HTTPDecode(V)) else if M.V<>hvUnknown then begin if M.V<>hvQuery then V:=HTTPDecode(V); SetHTTPVariable(M.V,V) end; end; end; //--------------------- if Pos('IIS', ServerSoftware) > 0 then PathInfo := StringReplace(PathInfo, ScriptName, '', []); //--------------------- R:=UpCase(Method); if (R='POST') or (R='PUT') or (ContentLength>0) then ReadContent; end; ===END=== Only these lines are new: if Pos('IIS', ServerSoftware) > 0 then PathInfo := StringReplace(PathInfo, ScriptName, '', []); Nothing happens, because ServerSoftware is empty. If I comment the first line, the PathInfo will be fixed but I got this error: "Could not determine HTTP module for request "list"" Consider this: 1- PathInfo and ScriptName are properties of THTTPHeader class 2- ServerSoftware is a property of TCGIRequest So, on this version you check: M.H<>hhUnknown or M.V<>hvUnknown, then I'd tryed to implement: [unit custcgi, line 166, const MapCgiToHTTP] { 17: 'SERVER_SOFTWARE' } (h:hhUnknown; v : hvServerSoftware), ...and added in httpdefs.THTTPVariableType too ...and I'd implemented this property too: THTTPReader Property ServerSoftware : String Index Ord(hvServerSoftware) read GetHTTPVariable Write SetHTTPVariable; Does't work. So, now I have 2 problems: 1- If I change the PathInfo without check ServerName, I can fix it but the app raise an exception; 2- ServerSoftware doesn't work in version 3.1.1 . Regards, Marcos Douglas From mailinglists at geldenhuys.co.uk Wed Apr 27 16:36:48 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 27 Apr 2016 15:36:48 +0100 Subject: [fpc-pascal] UnicodeString and surrogate pairs Message-ID: <5720CE80.1000501@geldenhuys.co.uk> Hi, Does FPC's RTL (or FCL) include a function to check for UTF-16 surrogate pairs? I'd be very surprised if there isn't, but I have yet to find it in the documentation or source code I searched. I need to process one "character" (loosely based on what you see on the screen) at a time while calculating text width up to a maximum width. I need to make sure I handle all Unicode text correctly, thus NOT just the BMP of the Unicode standard, but all supplementary planes too. My alternative is to convert the text from UTF-16 to UTF-8 and then process it, but in this instance I'm hoping to stay with UTF-16 [never thought I would ever say that out loudly! ;-)] Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Wed Apr 27 16:56:49 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 27 Apr 2016 15:56:49 +0100 Subject: [fpc-pascal] Iterator for Unicode encoded strings Message-ID: <5720D331.3020700@geldenhuys.co.uk> Hi, This question really applies for all Unicode encodings (UTF-8, UTF-16 and UTF-32). In the modern world you simply can't use indexed access into Object Pascal strings to retrieve a "character" (loosely what you see on the screen - ignoring combining diacritics). In my own projects I have custom written Iterators for various data types like StringList, ObjectLists etc, and that includes strings. I know FPC RTL supports the Iterator concept (not as advanced as what I have implemented), but still useful. As far as I know there are some standard iterator classes already implemented. Does FPC include such iterators for the various string types? Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From michael at freepascal.org Wed Apr 27 16:59:45 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 27 Apr 2016 16:59:45 +0200 (CEST) Subject: [fpc-pascal] Iterator for Unicode encoded strings In-Reply-To: <5720D331.3020700@geldenhuys.co.uk> References: <5720D331.3020700@geldenhuys.co.uk> Message-ID: On Wed, 27 Apr 2016, Graeme Geldenhuys wrote: > Hi, > > This question really applies for all Unicode encodings (UTF-8, UTF-16 > and UTF-32). In the modern world you simply can't use indexed access > into Object Pascal strings to retrieve a "character" (loosely what you > see on the screen - ignoring combining diacritics). In my own projects I > have custom written Iterators for various data types like StringList, > ObjectLists etc, and that includes strings. > > I know FPC RTL supports the Iterator concept (not as advanced as what I > have implemented), but still useful. As far as I know there are some > standard iterator classes already implemented. Does FPC include such > iterators for the various string types? Simply said: No. The character iterator var C : Char; S : String; // or unicode string begin for c in S do end. Will iterate bytes or words, not characters. Michael. From mailinglists at geldenhuys.co.uk Wed Apr 27 17:02:51 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 27 Apr 2016 16:02:51 +0100 Subject: [fpc-pascal] Iterator for Unicode encoded strings In-Reply-To: References: <5720D331.3020700@geldenhuys.co.uk> Message-ID: <5720D49B.9080507@geldenhuys.co.uk> On 2016-04-27 15:59, Michael Van Canneyt wrote: > Simply said: No. The character iterator > > Will iterate bytes or words, not characters. OK thanks. So I definitely need the IsSurrogatePair() like function then - in the case of UTF-16 encoded (UnicodeString) text. Do you know if such a function exists in the RTL? If not, I'll browse unicode.org to see what is required for such an implementation. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From marcov at stack.nl Wed Apr 27 17:24:57 2016 From: marcov at stack.nl (Marco van de Voort) Date: Wed, 27 Apr 2016 17:24:57 +0200 (CEST) Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <5720CE80.1000501@geldenhuys.co.uk> Message-ID: <20160427152457.367CD73037@toad.stack.nl> In our previous episode, Graeme Geldenhuys said: > Does FPC's RTL (or FCL) include a function to check for UTF-16 surrogate > pairs? I'd be very surprised if there isn't, but I have yet to find it > in the documentation or source code I searched. Same as Delphi, character.tcharacter.issurrogate() or character.issurrogate() (modern delphi units group everything as class methods in classes for some vague reason) From mailinglists at geldenhuys.co.uk Wed Apr 27 17:32:40 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 27 Apr 2016 16:32:40 +0100 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <20160427152457.367CD73037@toad.stack.nl> References: <20160427152457.367CD73037@toad.stack.nl> Message-ID: <5720DB98.3080602@geldenhuys.co.uk> On 2016-04-27 16:24, Marco van de Voort wrote: > Same as Delphi, character.tcharacter.issurrogate() or > character.issurrogate() Ah, thank you very much. Regards, Graeme From dhkblaszyk at zeelandnet.nl Wed Apr 27 21:39:48 2016 From: dhkblaszyk at zeelandnet.nl (Darius Blaszyk) Date: Wed, 27 Apr 2016 21:39:48 +0200 Subject: [fpc-pascal] FPC create unit path Message-ID: <0226521626efbfaa1bbf0d8a05299904@zeelandnet.nl> Hi, When I try to compile a test app, I get an error saying the output folder (defined by FU) cannot be created by FPC. I suppose this behaviour is ok? Is there a way to have FPC to create the requested folder? fpc -FU.\test mytest.pp Error: Can't create object file: .\test\mytest.o (error code: 3) Fatal: Can't create object .\test\mytest.o Regards, Darius -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Wed Apr 27 21:57:44 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 27 Apr 2016 20:57:44 +0100 Subject: [fpc-pascal] FPC create unit path In-Reply-To: <0226521626efbfaa1bbf0d8a05299904@zeelandnet.nl> References: <0226521626efbfaa1bbf0d8a05299904@zeelandnet.nl> Message-ID: <572119B8.3060302@geldenhuys.co.uk> On 2016-04-27 20:39, Darius Blaszyk wrote: > Is there a way to have FPC to create the requested > folder? I asked the same thing years back, and I was told that no, it's not the job of the compiler, but rather the job of the build script or your IDE. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From pascaldragon at googlemail.com Wed Apr 27 22:48:20 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 27 Apr 2016 22:48:20 +0200 Subject: [fpc-pascal] FPC create unit path In-Reply-To: <572119B8.3060302@geldenhuys.co.uk> References: <0226521626efbfaa1bbf0d8a05299904@zeelandnet.nl> <572119B8.3060302@geldenhuys.co.uk> Message-ID: <57212594.60909@googlemail.com> On 27.04.2016 21:57, Graeme Geldenhuys wrote: > On 2016-04-27 20:39, Darius Blaszyk wrote: >> Is there a way to have FPC to create the requested >> folder? > > I asked the same thing years back, and I was told that no, it's not the > job of the compiler, but rather the job of the build script or your IDE. Indeed. That's by design Regards, Sven From md at delfire.net Thu Apr 28 03:19:42 2016 From: md at delfire.net (Marcos Douglas) Date: Wed, 27 Apr 2016 22:19:42 -0300 Subject: [fpc-pascal] FastCGI on Windows IIS In-Reply-To: References: Message-ID: Michael, Here is the patch to fix that on Windows: http://bugs.freepascal.org/view.php?id=30073 Regards, Marcos Douglas From Paul at MichellComputing.co.uk Thu Apr 28 12:38:19 2016 From: Paul at MichellComputing.co.uk (Paul Michell) Date: Thu, 28 Apr 2016 11:38:19 +0100 Subject: [fpc-pascal] Is there a FPC symbol or define for the binary output filename? Message-ID: <5721E81B.9090700@MichellComputing.co.uk> Hello All, I'm writing a library that needs to be used as statically linked units in an application and also as a stand alone dll/so for use from other software. The library needs to know where its binary file is loaded on the host system. The following code in the main unit's Initialization section does what I need for Windows and Linux, but I would like to avoid having to hard code the compiled binary name into the source. Is there any system symbol or define I could use as a place-holder for the output filename? I would like to be able to replace 'libgiq' with something like {$i %FPCVERSION%} so that I don't need to remember to edit the library when re-using it in other projects. Also is there a better way to retrieve this information on Linux? Thanks, Paul -------------------------------------------- {$IFDEF WINDOWS} DataFolder := IncludeTrailingPathDelimiter(ExtractFilePath(GetModuleName(HInstance))); {$ELSE} If IsLibrary Then Begin AssignFile(DataFile, '/proc/self/maps'); Try Reset(DataFile); While Not EOF(DataFile) Do Begin readln(DataFile, MapText); If Pos('libgiq', MapText)<>0 Then Begin DataFolder := ExtractFilePath(Copy(MapText, LastDelimiter(' ',MapText)+1, Length(MapText))); Exit; End; End; CloseFile(DataFile); Except On E: EInOutError Do writeln('File handling error: ', E.Message); End; End Else DataFolder := IncludeTrailingPathDelimiter(ExtractFilePath(ParamStr(0))); {$ENDIF} From mailinglists at geldenhuys.co.uk Thu Apr 28 15:02:38 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 28 Apr 2016 14:02:38 +0100 Subject: [fpc-pascal] FPC can't determine overloaded function to call Message-ID: <572209EE.2090307@geldenhuys.co.uk> Hi, I can't figure out why FPC is struggling with figuring out which overloaded methods to call. This is my application code which FPC has a problem with. type TPDFFloat = Single; TPDFCoord = record X,Y: TPDFFloat; end; var W, H: integer begin ...snip... P.DrawImage(25, 190, W div 2, H div 2, IDX); // this fails Yet this works P.DrawImage(25, 190, Integer(W div 2), Integer(H div 2), IDX); Here are the overloaded DrawImage() definitions [sorry if you email client wraps this badly]: { X, Y coordinates are the bottom-left coordinate of the image. AWidth and AHeight are in image pixels. } Procedure DrawImage(const X, Y: TPDFFloat; const AWidth, AHeight, ANumber: integer); overload; Procedure DrawImage(const APos: TPDFCoord; const AWidth, AHeight, ANumber: integer); overload; { X, Y coordinates are the bottom-left coordinate of the image. AWidth and AHeight are in UnitOfMeasure units. } Procedure DrawImage(const X, Y: TPDFFloat; const AWidth, AHeight: TPDFFloat; ANumber: integer); overload; Procedure DrawImage(const APos: TPDFCoord; const AWidth, AHeight: TPDFFloat; ANumber: integer); overload; This is the compiler error message I got: ============================== Compile Project, Target: testfppdf: Exit code 1, Errors: 1, Hints: 2 testfppdf.lpr(281,46) Error: Can't determine which overloaded function to call fppdf.pp(1802,20) Hint: Found declaration: TPDFPage.DrawImage(const Single,const Single,const Single,const Single,const LongInt); fppdf.pp(1788,20) Hint: Found declaration: TPDFPage.DrawImage(const Single,const Single,const LongInt,const LongInt,const LongInt); ============================== Doesn't the code ⸢(W div 2)⸥ resolve to an Integer result? W is an Integer type, and DIV is an integer division. I'm using 64-bit FPC 2.6.4. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From peter at pblackman.plus.com Thu Apr 28 15:22:31 2016 From: peter at pblackman.plus.com (Peter) Date: Thu, 28 Apr 2016 14:22:31 +0100 Subject: [fpc-pascal] FPC can't determine overloaded function to call In-Reply-To: <572209EE.2090307@geldenhuys.co.uk> References: <572209EE.2090307@geldenhuys.co.uk> Message-ID: <57220E97.9090502@pblackman.plus.com> On 28/04/16 14:02, Graeme Geldenhuys wrote: > Hi, > > I can't figure out why FPC is struggling with figuring out which > overloaded methods to call. This is my application code which FPC has a > problem with. > > type > TPDFFloat = Single; > > TPDFCoord = record > X,Y: TPDFFloat; > end; > > var > W, H: integer > begin > ...snip... > P.DrawImage(25, 190, W div 2, H div 2, IDX); // this fails > > Yet this works > P.DrawImage(25, 190, Integer(W div 2), Integer(H div 2), IDX); > > > Here are the overloaded DrawImage() definitions [sorry if you email > client wraps this badly]: > > { X, Y coordinates are the bottom-left coordinate of the image. AWidth > and AHeight are in image pixels. } > Procedure DrawImage(const X, Y: TPDFFloat; const AWidth, AHeight, > ANumber: integer); overload; > > Procedure DrawImage(const APos: TPDFCoord; const AWidth, AHeight, > ANumber: integer); overload; > > { X, Y coordinates are the bottom-left coordinate of the image. AWidth > and AHeight are in UnitOfMeasure units. } > Procedure DrawImage(const X, Y: TPDFFloat; const AWidth, AHeight: > TPDFFloat; ANumber: integer); overload; > > Procedure DrawImage(const APos: TPDFCoord; const AWidth, AHeight: > TPDFFloat; ANumber: integer); overload; > > > This is the compiler error message I got: > ============================== > Compile Project, Target: testfppdf: Exit code 1, Errors: 1, Hints: 2 > testfppdf.lpr(281,46) Error: Can't determine which overloaded function > to call > fppdf.pp(1802,20) Hint: Found declaration: TPDFPage.DrawImage(const > Single,const Single,const Single,const Single,const LongInt); > fppdf.pp(1788,20) Hint: Found declaration: TPDFPage.DrawImage(const > Single,const Single,const LongInt,const LongInt,const LongInt); > ============================== > > > Doesn't the code ⸢(W div 2)⸥ resolve to an Integer result? W is an > Integer type, and DIV is an integer division. > > I'm using 64-bit FPC 2.6.4. > > Regards, > Graeme > Sizeof 'W' is 2 Sizeof '(W div 2)' is 8 I suspect '(W div 2) gives int64. Regards, Pete From mailinglists at geldenhuys.co.uk Thu Apr 28 15:33:36 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 28 Apr 2016 14:33:36 +0100 Subject: [fpc-pascal] FPC can't determine overloaded function to call In-Reply-To: <57220E97.9090502@pblackman.plus.com> References: <572209EE.2090307@geldenhuys.co.uk> <57220E97.9090502@pblackman.plus.com> Message-ID: <57221130.2050808@geldenhuys.co.uk> On 2016-04-28 14:22, Peter wrote: > I suspect '(W div 2) gives int64. Interesting thought. But a Integer div Integer cannot give a result larger than a Integer type, so why is the compiler upscaling the result it to a Int64?? If that is really what the compiler is doing, then something is going way wrong, or I simply don't understand the logic. I looked through the help, and the Objects.pp unit actually has a LongDiv() method which does a DIV between two Integer types and returns a Integer [as one would expect the result to be]. But looking at its implementation I see it required a Integer cast too. Very strang compiler behaviour. :-/ FUNCTION LongDiv (X: LongInt; Y: Integer): Integer; BEGIN LongDiv := Integer(X DIV Y); END; Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Thu Apr 28 16:29:51 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 28 Apr 2016 15:29:51 +0100 Subject: [fpc-pascal] FPC can't determine overloaded function to call In-Reply-To: <572209EE.2090307@geldenhuys.co.uk> References: <572209EE.2090307@geldenhuys.co.uk> Message-ID: <57221E5F.9010402@geldenhuys.co.uk> On 2016-04-28 14:02, Graeme Geldenhuys wrote: > ...snip... > P.DrawImage(25, 190, W div 2, H div 2, IDX); // this fails > > Yet this works > P.DrawImage(25, 190, Integer(W div 2), Integer(H div 2), IDX); In this specific example, the following also works - and without the need for the Integer() casting. P.DrawImage(25, 190, W shr 1, H shr 1, IDX); Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From bartjunk64 at gmail.com Thu Apr 28 17:13:56 2016 From: bartjunk64 at gmail.com (Bart) Date: Thu, 28 Apr 2016 17:13:56 +0200 Subject: [fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave? In-Reply-To: References: <5714FBD0.4050702@geldenhuys.co.uk> Message-ID: On 4/18/16, Michael Van Canneyt wrote: > I think Bart meant that the maskutils unit should simply use unicodestring. > Given that it almost surely will need to deal with $ and € etc, that seems > like a better approach. FWIW an unicode version for testing attached. Bart -------------- next part -------------- A non-text attachment was scrubbed... Name: umaskutils.pp Type: application/octet-stream Size: 29051 bytes Desc: not available URL: From jonas.maebe at elis.ugent.be Thu Apr 28 18:10:35 2016 From: jonas.maebe at elis.ugent.be (Jonas Maebe) Date: Thu, 28 Apr 2016 18:10:35 +0200 Subject: [fpc-pascal] FPC can't determine overloaded function to call In-Reply-To: <57221130.2050808@geldenhuys.co.uk> References: <572209EE.2090307@geldenhuys.co.uk> <57220E97.9090502@pblackman.plus.com> <57221130.2050808@geldenhuys.co.uk> Message-ID: On 28/04/16 15:33, Graeme Geldenhuys wrote: > Interesting thought. But a Integer div Integer cannot give a result > larger than a Integer type, so why is the compiler upscaling the result > it to a Int64?? If that is really what the compiler is doing, then > something is going way wrong, or I simply don't understand the logic. Search for "As a pascal compiler" on http://www.freepascal.org/docs-html/ref/refsu5.html You are presumably compiling for a 64 bit target platform. Jonas From mschnell at lumino.de Thu Apr 28 10:03:29 2016 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 28 Apr 2016 10:03:29 +0200 Subject: [fpc-pascal] Iterator for Unicode encoded strings In-Reply-To: <5720D331.3020700@geldenhuys.co.uk> References: <5720D331.3020700@geldenhuys.co.uk> Message-ID: <5721C3D1.8030905@lumino.de> AFAIR, a member of the German Lazarus Forum implemented an iterator class for UTF8 some years ago (before there was Unicode support in fpc). -Michael From mschnell at lumino.de Thu Apr 28 10:05:29 2016 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 28 Apr 2016 10:05:29 +0200 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <5720CE80.1000501@geldenhuys.co.uk> References: <5720CE80.1000501@geldenhuys.co.uk> Message-ID: <5721C449.1040000@lumino.de> On 04/27/2016 04:36 PM, Graeme Geldenhuys wrote: > Does FPC's RTL (or FCL) include a function to check for UTF-16 surrogate > pairs? Would that necessarily be an UTF-8 issue ? -Michael From mailinglists at geldenhuys.co.uk Fri Apr 29 11:09:13 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 29 Apr 2016 10:09:13 +0100 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <5721C449.1040000@lumino.de> References: <5720CE80.1000501@geldenhuys.co.uk> <5721C449.1040000@lumino.de> Message-ID: <572324B9.7030503@geldenhuys.co.uk> On 2016-04-28 09:05, Michael Schnell wrote: > Would that necessarily be an UTF-8 issue ? No, because UTF-8 doesn't use surrogate pairs. In this instance the string is of type UnicodeString, thus UTF-16 encoded. Now I could internally assign that to a UTF8String type, but in this case I wanted to use UnicodeString directly with standard RTL or FCL functions. On a side note: I always use UTF-8 encoded strings with fpGUI and my personal projects, because I simply find it easier and more stable (by default supporting the whole 1.1 million available Unicode code points). The code I'm currently working on is for a client, so I didn't enforce my coding habits. ;-) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Fri Apr 29 11:20:15 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 29 Apr 2016 10:20:15 +0100 Subject: [fpc-pascal] Debug and Release RTL & FCL side by side Message-ID: <5723274F.5070006@geldenhuys.co.uk> Hi, I sometimes hit a bug in my applications, but then there is no Stack Trace information, or simply something like 3 entries that don't give much information. See attached screenshot as an example. Apparently this is caused by the fact that I'm using a Release build of the RTL and FCL and the error was raised inside the RTL or FCL code. So is there a recommended FPC setup having a Release and Debug RTL & FCL side by side. Then in my IDE of choice (or build scripts) I can switch between them as needed. I believe Delphi had a similar setup (or maybe it was only for the VCL), but its been too long since I really used Delphi to remember what Borland did. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -------------- next part -------------- A non-text attachment was scrubbed... Name: debugger.png Type: image/png Size: 4343 bytes Desc: not available URL: From XHajT03 at hajny.biz Fri Apr 29 11:31:43 2016 From: XHajT03 at hajny.biz (Tomas Hajny) Date: Fri, 29 Apr 2016 11:31:43 +0200 Subject: [fpc-pascal] Debug and Release RTL & FCL side by side In-Reply-To: <5723274F.5070006@geldenhuys.co.uk> References: <5723274F.5070006@geldenhuys.co.uk> Message-ID: On Fri, April 29, 2016 11:20, Graeme Geldenhuys wrote: Hi, > I sometimes hit a bug in my applications, but then there is no Stack > Trace information, or simply something like 3 entries that don't give > much information. See attached screenshot as an example. Apparently this > is caused by the fact that I'm using a Release build of the RTL and FCL > and the error was raised inside the RTL or FCL code. > > So is there a recommended FPC setup having a Release and Debug RTL & FCL > side by side. Then in my IDE of choice (or build scripts) I can switch > between them as needed. I believe Delphi had a similar setup (or maybe > it was only for the VCL), but its been too long since I really used > Delphi to remember what Borland did. Obviously, you can have release and debug builds residing in different directories side by side (different location from other third party or your own units). Then depending on your tool of choice, you simply select the right configuration set when compiling and debugging. You can do this with the command line compiler (supplying different configuration files, possibly also having the common part of configuration shared using an include file), you can do that by using the text mode IDE, etc. Or did you mean something different? Tomas From michael at freepascal.org Fri Apr 29 11:34:27 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 29 Apr 2016 11:34:27 +0200 (CEST) Subject: [fpc-pascal] Debug and Release RTL & FCL side by side In-Reply-To: <5723274F.5070006@geldenhuys.co.uk> References: <5723274F.5070006@geldenhuys.co.uk> Message-ID: On Fri, 29 Apr 2016, Graeme Geldenhuys wrote: > Hi, > > I sometimes hit a bug in my applications, but then there is no Stack > Trace information, or simply something like 3 entries that don't give > much information. See attached screenshot as an example. Apparently this > is caused by the fact that I'm using a Release build of the RTL and FCL > and the error was raised inside the RTL or FCL code. > > So is there a recommended FPC setup having a Release and Debug RTL & FCL > side by side. Then in my IDE of choice (or build scripts) I can switch > between them as needed. I believe Delphi had a similar setup (or maybe > it was only for the VCL), but its been too long since I really used > Delphi to remember what Borland did. There is none. what you can do is create install debug versions of the RTL/package units under /usr/local/lib/fpc/$fpcversion/units/debug/$fpctarget/ and then compile your program using -dDEBUGRTL, with in your .fpc.cfg #ifdef DEBUGRTL -Fu/usr/local/lib/fpc/$fpcversion//units/debug/$fpctarget/httpd22 -Fu/usr/local/lib/fpc/$fpcversion/units/debug/$fpctarget/* -Fu/usr/local/lib/fpc/$fpcversion/units/debug/$fpctarget/httpd22 #else -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/httpd22 -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/* -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/httpd22 #endf The compiler will then pick the debug versions of the RTL units. Michael. From mailinglists at geldenhuys.co.uk Fri Apr 29 12:03:56 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 29 Apr 2016 11:03:56 +0100 Subject: [fpc-pascal] Debug and Release RTL & FCL side by side In-Reply-To: References: <5723274F.5070006@geldenhuys.co.uk> Message-ID: <20160429110356.5eb7374a@geldenhuys.co.uk> On Fri, 29 Apr 2016 11:34:27 +0200 (CEST) Michael Van Canneyt wrote: > and then compile your program using -dDEBUGRTL, with in your .fpc.cfg Ah perfect, that's exactly the information I was looking for. I was just looking at the .fpc.cfg file and wondering if I could play with the RELEASE and DEBUG defines already in there. Thanks for your help. Regards, Graeme From mschnell at lumino.de Fri Apr 29 11:23:57 2016 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 29 Apr 2016 11:23:57 +0200 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <572324B9.7030503@geldenhuys.co.uk> References: <5720CE80.1000501@geldenhuys.co.uk> <5721C449.1040000@lumino.de> <572324B9.7030503@geldenhuys.co.uk> Message-ID: <5723282D.5000401@lumino.de> On 04/29/2016 11:09 AM, Graeme Geldenhuys wrote: > > No, because UTF-8 doesn't use surrogate pairs. Really ? I understand that "surrogate pairs" is combining a printable character (i.e on of the nearly 2^32 UTF thingies) with another of those to be combined to a different printable thingy (/e.g. "A" plus "add two dots above" to crate a "Ä"). Now a series of 32-bit UTF thingies can be compressed to as well a series of UTF8 encoded bytes or as a series of UTF16 encoded words. Both of which usually is much shorter (measured in bytes) than the uncompressed UTF32 information. So the UTF8 vs UTF16 issue is a lower layer of encoding. -Michael From pascaldragon at googlemail.com Sat Apr 30 08:31:33 2016 From: pascaldragon at googlemail.com (Sven Barth) Date: Sat, 30 Apr 2016 08:31:33 +0200 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <5723282D.5000401@lumino.de> References: <5720CE80.1000501@geldenhuys.co.uk> <5721C449.1040000@lumino.de> <572324B9.7030503@geldenhuys.co.uk> <5723282D.5000401@lumino.de> Message-ID: Am 30.04.2016 08:24 schrieb "Michael Schnell" : > > On 04/29/2016 11:09 AM, Graeme Geldenhuys wrote: >> >> >> No, because UTF-8 doesn't use surrogate pairs. > > Really ? > > I understand that "surrogate pairs" is combining a printable character (i.e on of the nearly 2^32 UTF thingies) with another of those to be combined to a different printable thingy (/e.g. "A" plus "add two dots above" to crate a "Ä"). No, that's a different thingie. Surrogate pairs are used in UTF-16 to represent characters which would be > $FFFF. What you are talking about is - I think - decomposition (don't know the exact name) and is a whole more complex topic cause you need to know which characters can be combined. Surrogate pairs on the other hand are specific byte ranges that act as first and second part of the character. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Sat Apr 30 12:12:35 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sat, 30 Apr 2016 11:12:35 +0100 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <5723282D.5000401@lumino.de> References: <5720CE80.1000501@geldenhuys.co.uk> <5721C449.1040000@lumino.de> <572324B9.7030503@geldenhuys.co.uk> <5723282D.5000401@lumino.de> Message-ID: <20160430111235.52125fca@geldenhuys.co.uk> Hello Michael, On 2016-04-29 at 11:23 you wrote: > > No, because UTF-8 doesn't use surrogate pairs. > Really ? Yes. > those to be combined to a different printable thingy (/e.g. "A" plus > "add two dots above" to crate a "Ä"). No, that is something totally different and not what I was talking about. You are refering to combining diacritics. Two or more code-points (think "characters") combined to make a new looking single character on screen or printed. > Both of which usually is much shorter (measured in bytes) than the > uncompressed UTF32 information. Without you using the correct terminology, I think you are refering to composed and decomposed formats of a character. For example: e (U+0065) + ̈ (U+0308) = ë (2 code-points used) vs e (U+0065) + ̈ (U+0308) --> ë (1 code-point used) The first example above results in the decomposed version of ë. The second example above results in the composed version of ë. The decomposed versions are the prefered and recommended way by the Unicode Consortium. They (the Unicode Consortium) only included the composed versions for backward compatibility with existing character sets - when the Unicode standard was established. No new composed code-points will be added to the Unicode standard. Anyway, I was refering to surrogate pairs (applies to UTF-16 only), not composed/decomposed glyphs. Regards, Graeme From mse00000 at gmail.com Sat Apr 30 12:32:37 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Sat, 30 Apr 2016 12:32:37 +0200 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <20160430111235.52125fca@geldenhuys.co.uk> References: <5720CE80.1000501@geldenhuys.co.uk> <5723282D.5000401@lumino.de> <20160430111235.52125fca@geldenhuys.co.uk> Message-ID: <201604301232.37672.mse00000@gmail.com> On Saturday 30 April 2016 12:12:35 Graeme Geldenhuys wrote: > > Anyway, I was refering to surrogate pairs (applies to UTF-16 only) > One could say that utf-8 has surrogate pairs, surrogate triplets and surrogate quads. Martin From mailinglists at geldenhuys.co.uk Sat Apr 30 20:39:33 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sat, 30 Apr 2016 19:39:33 +0100 Subject: [fpc-pascal] UnicodeString and surrogate pairs In-Reply-To: <201604301232.37672.mse00000@gmail.com> References: <5720CE80.1000501@geldenhuys.co.uk> <5723282D.5000401@lumino.de> <20160430111235.52125fca@geldenhuys.co.uk> <201604301232.37672.mse00000@gmail.com> Message-ID: <5724FBE5.1060709@geldenhuys.co.uk> On 2016-04-30 11:32, Martin Schreiber wrote: > One could say that utf-8 has surrogate pairs, surrogate triplets and surrogate > quads. No, don't confuse the point. As per the Unicode Standards definition of "surrogate pairs", UTF-8 and UTF-32 don't have surrogate pairs. Regards, Graeme