[fpc-pascal] Printed documentation
Hi, I have been looking at the FPC documentation (August 2007) in pdf format. Wow, there is a lot - awesome work Michael! I know we are supposed to save the environment and trees (I'm a big fan of environmentally friendly procedures), but has anybody actually had those books printed and bound? Considering the RTL docs I have, it's just over 1500 pages in size. That would make one massive book, so would probably have to be printed as two books (part 1 and part 2). Anybody know of a printing company in South Africa that will be willing to do a once off print? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Web link to documentation
Hi, I know that to find the documentation for Free Pascal, I have to go to... http://www.freepascal.org/docs.var ...not the most intuitive URL. Most users would try the following without browsing the website (most other website work like this). http://www.freepascal.org/docs/ http://docs.freepascal.org Is it possible that the above two URL's could be made to point to the [http://www.freepascal.org/docs.var] address? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
Graeme Geldenhuys schreef: Hi, I know that to find the documentation for Free Pascal, I have to go to... http://www.freepascal.org/docs.var ...not the most intuitive URL. Most users would try the following without browsing the website (most other website work like this). http://www.freepascal.org/docs/ http://docs.freepascal.org I wonder how many entries in apache error log can be found for these links prior to your posting. IOW, I wonder how many people equals Most users. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, 20 Mar 2009, Graeme Geldenhuys wrote: Hi, I know that to find the documentation for Free Pascal, I have to go to... http://www.freepascal.org/docs.var ...not the most intuitive URL. Most users would try the following without browsing the website (most other website work like this). http://www.freepascal.org/docs/ http://docs.freepascal.org Is it possible that the above two URL's could be made to point to the [http://www.freepascal.org/docs.var] address? I suppose it could be done through some DNS, virtual hosts and mod_rewrite magic. Added to my Todo list. (which, meanwhile, is larger than the docs themselves, unfortunately enough) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, Mar 20, 2009 at 10:00 AM, Vincent Snijders vsnijd...@vodafonevast.nl wrote: I wonder how many entries in apache error log can be found for these links prior to your posting. IOW, I wonder how many people equals Most users. I'm pretty sure there must be a few... ;-) Other website examples (just to name a few): doc.trolltech.com/ www.wxwidgets.org/docs/ java.sun.com/docs/ httpd.apache.org/docs/ docs.rubyonrails.org docs.joomla.org It's not like we need a new web page or anything, it's simply a '/docs/' alias that needs to be added to the web server or a new 'virtual' host (I think) setup for docs.freepascal.org. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, 20 Mar 2009, Graeme Geldenhuys wrote: On Fri, Mar 20, 2009 at 10:00 AM, Vincent Snijders vsnijd...@vodafonevast.nl wrote: I wonder how many entries in apache error log can be found for these links prior to your posting. IOW, I wonder how many people equals Most users. I'm pretty sure there must be a few... ;-) Other website examples (just to name a few): doc.trolltech.com/ www.wxwidgets.org/docs/ java.sun.com/docs/ httpd.apache.org/docs/ docs.rubyonrails.org docs.joomla.org It's not like we need a new web page or anything, it's simply a '/docs/' alias that needs to be added to the web server or a new 'virtual' host (I think) setup for docs.freepascal.org. docs.freepascal.org now points straight to the documentation page. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, Mar 20, 2009 at 11:22 AM, Michael Van Canneyt mich...@freepascal.org wrote: docs.freepascal.org now points straight to the documentation page. Thanks! As Marco mentioned, it's not working yet, but that's probably a DNS update time issue. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
In our previous episode, Michael Van Canneyt said: I wonder how many entries in apache error log can be found for these links prior to your posting. IOW, I wonder how many people equals Most users. I'm pretty sure there must be a few... ;-) Other website examples (just to name a few): doc.trolltech.com/ www.wxwidgets.org/docs/ java.sun.com/docs/ httpd.apache.org/docs/ docs.rubyonrails.org docs.joomla.org It's not like we need a new web page or anything, it's simply a '/docs/' alias that needs to be added to the web server or a new 'virtual' host (I think) setup for docs.freepascal.org. docs.freepascal.org now points straight to the documentation page. Not working yet here, but that could be dns propagation time. Anyway, I like this, I already had a button added to the firefox buttonbar. Problem is only that it won't work for mirrors. P.s. Speaking about docs: I saw the current documentation is still badly linked. (the next/prev links) I also retried myself using the most recent tex4ht updates (januari 2009), and failed again, the links are still borked, though i have a feeling they are slightly better. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Henry Vermaak said: /usr/local/share/locale/, but the directory structure is there. I should have mentioned that it is FreeBSD. /usr/local is probably the same, writable by ports. ?I have .mo files in /usr/share/locale/code/LC_MESSAGES but also other LC_ files with locale info are there. I don't have any of the other dirs mentioned. where does localedef put the compiled files on bsd? localedef is part of the single unix spec, so we should probably parse the compiled files (like libc) Does the single unix spec define the exact format for these files? Since otherwise they might vary between the 3/4 supported unices (solaris, OS X/FreeBSD and Linux) (OS X and FreeBSD sometimes share details) since this will be _much_ faster. Personally I don't see the use of going this way. Why not simply use iconv? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Henry Vermaak said: I noticed that I had more direectories in /usr/lib/locale (echh with it's compiles LC_xxx files) than I have /usr/share/118n/locales directory. I've some in /usr/share/local and /usr/local/share/locale the ones in /usr/share/locale are .mo files for the different programs (on debian, at least). i don't have any files under /usr/local/share/locale/, but the directory structure is there. I should have mentioned that it is FreeBSD. /usr/local is probably the same, writable by ports. I have .mo files in /usr/share/locale/code/LC_MESSAGES but also other LC_ files with locale info are there. I don't have any of the other dirs mentioned. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
2009/3/20 Marco van de Voort mar...@stack.nl: In our previous episode, Henry Vermaak said: I noticed that I had more direectories in /usr/lib/locale (echh with it's compiles LC_xxx files) than I have /usr/share/118n/locales directory. I've some in /usr/share/local and /usr/local/share/locale the ones in /usr/share/locale are .mo files for the different programs (on debian, at least). i don't have any files under /usr/local/share/locale/, but the directory structure is there. I should have mentioned that it is FreeBSD. /usr/local is probably the same, writable by ports. I have .mo files in /usr/share/locale/code/LC_MESSAGES but also other LC_ files with locale info are there. I don't have any of the other dirs mentioned. where does localedef put the compiled files on bsd? localedef is part of the single unix spec, so we should probably parse the compiled files (like libc), since this will be _much_ faster. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, 20 Mar 2009, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: I wonder how many entries in apache error log can be found for these links prior to your posting. IOW, I wonder how many people equals Most users. I'm pretty sure there must be a few... ;-) Other website examples (just to name a few): doc.trolltech.com/ www.wxwidgets.org/docs/ java.sun.com/docs/ httpd.apache.org/docs/ docs.rubyonrails.org docs.joomla.org It's not like we need a new web page or anything, it's simply a '/docs/' alias that needs to be added to the web server or a new 'virtual' host (I think) setup for docs.freepascal.org. docs.freepascal.org now points straight to the documentation page. Not working yet here, but that could be dns propagation time. Anyway, I like this, I already had a button added to the firefox buttonbar. I didn't update the zone version number yet, I'll do this. Problem is only that it won't work for mirrors. This is so, but unfortunately that can't be helped easily. P.s. Speaking about docs: I saw the current documentation is still badly linked. (the next/prev links) I also retried myself using the most recent tex4ht updates (januari 2009), and failed again, the links are still borked, though i have a feeling they are slightly better. I'm happy that you think they are better :-) But as far as I'm concerned, this is a non-issue. The HTML version of the docs is still only a courtesy. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
In our previous episode, Michael Van Canneyt said: P.s. Speaking about docs: I saw the current documentation is still badly linked. (the next/prev links) I also retried myself using the most recent tex4ht updates (januari 2009), and failed again, the links are still borked, though i have a feeling they are slightly better. I'm happy that you think they are better :-) But as far as I'm concerned, this is a non-issue. The HTML version of the docs is still only a courtesy. I don't agree that the fact that HTML docs is secondary makes it automatically a non-issue :-) A lesser issue of course, but OTOH we have been messing with it for over ten years (I started with Latex2html 96) now, and it is still borked. I'm thinking of trying to create an html fixer app. I know, that wouldn't be the first too, but at least it would be better than this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
In our previous episode, Michael Van Canneyt said: I don't agree that the fact that HTML docs is secondary makes it automatically a non-issue :-) A lesser issue of course, but OTOH we have been messing with it for over ten years (I started with Latex2html 96) now, and it is still borked. I'm thinking of trying to create an html fixer app. I know, that wouldn't be the first too, but at least it would be better than this. Feel free to do so... I will not stop anyone from doing so. Although it might be better to try and fix tex4ht, more people will benefit from that :-) Yes, that is what you said with latex2html too. Hacking in that 1.5 MB perl script is the worst programming experience I ever had :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, 20 Mar 2009, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: I don't agree that the fact that HTML docs is secondary makes it automatically a non-issue :-) A lesser issue of course, but OTOH we have been messing with it for over ten years (I started with Latex2html 96) now, and it is still borked. I'm thinking of trying to create an html fixer app. I know, that wouldn't be the first too, but at least it would be better than this. Feel free to do so... I will not stop anyone from doing so. Although it might be better to try and fix tex4ht, more people will benefit from that :-) Yes, that is what you said with latex2html too. Hacking in that 1.5 MB perl script is the worst programming experience I ever had :-) In the end, there will be nothing for it but to write our own latex2html. If it can convert the docs, it'll convert most latex out there... =) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
In our previous episode, Michael Van Canneyt said: I'm thinking of trying to create an html fixer app. I know, that wouldn't be the first too, but at least it would be better than this. Feel free to do so... I will not stop anyone from doing so. Although it might be better to try and fix tex4ht, more people will benefit from that :-) Yes, that is what you said with latex2html too. Hacking in that 1.5 MB perl script is the worst programming experience I ever had :-) In the end, there will be nothing for it but to write our own latex2html. If it can convert the docs, it'll convert most latex out there... =) Wouldn't it be simpler to take the fpdoc approach? Something alternately generating latex or html? You could cut out half of the latex macro usage since you would simply expand them when writing the latex code in pascal. It also isolates us from the latex-external plugin bond which is apparantly fragile, since nobody seems to be able with a good converter in ten years. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Henry Vermaak said: Personally I don't see the use of going this way. Why not simply use iconv? but that's just for char set conversion, how would we get the locale data (like time/date format, etc)? i guess we have no choice but to parse the definition files, then. Correct, it is apparantly libc itself, not iconv, but the point is if clocale can, why not abstract it that way. Because the textmode versions might not be installed on all systems, the compiled versions might be OS specific, and if they ever change for linux distributions you have another problem at your hand. And IMHO it is not crucial enough to try to bypass libc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, 20 Mar 2009, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: I'm thinking of trying to create an html fixer app. I know, that wouldn't be the first too, but at least it would be better than this. Feel free to do so... I will not stop anyone from doing so. Although it might be better to try and fix tex4ht, more people will benefit from that :-) Yes, that is what you said with latex2html too. Hacking in that 1.5 MB perl script is the worst programming experience I ever had :-) In the end, there will be nothing for it but to write our own latex2html. If it can convert the docs, it'll convert most latex out there... =) Wouldn't it be simpler to take the fpdoc approach? Something alternately generating latex or html? You could cut out half of the latex macro usage since you would simply expand them when writing the latex code in pascal. It also isolates us from the latex-external plugin bond which is apparantly fragile, since nobody seems to be able with a good converter in ten years. No, because I want to have available the full power of LaTeX. I tried docbook once, but that was a real pain. Everything I write (also my day-time job documents) is in LaTeX, so switching is not an option. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Web link to documentation
On Fri, 20 Mar 2009, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: P.s. Speaking about docs: I saw the current documentation is still badly linked. (the next/prev links) I also retried myself using the most recent tex4ht updates (januari 2009), and failed again, the links are still borked, though i have a feeling they are slightly better. I'm happy that you think they are better :-) But as far as I'm concerned, this is a non-issue. The HTML version of the docs is still only a courtesy. I don't agree that the fact that HTML docs is secondary makes it automatically a non-issue :-) A lesser issue of course, but OTOH we have been messing with it for over ten years (I started with Latex2html 96) now, and it is still borked. I'm thinking of trying to create an html fixer app. I know, that wouldn't be the first too, but at least it would be better than this. Feel free to do so... I will not stop anyone from doing so. Although it might be better to try and fix tex4ht, more people will benefit from that :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
2009/3/20 Marco van de Voort mar...@stack.nl: Does the single unix spec define the exact format for these files? Since otherwise they might vary between the 3/4 supported unices (solaris, OS X/FreeBSD and Linux) (OS X and FreeBSD sometimes share details) you are right, according to sus website the format of the created output (of localedef) is unspecified. Personally I don't see the use of going this way. Why not simply use iconv? but that's just for char set conversion, how would we get the locale data (like time/date format, etc)? i guess we have no choice but to parse the definition files, then. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
2009/3/20 Marco van de Voort mar...@stack.nl: In our previous episode, Henry Vermaak said: Personally I don't see the use of going this way. Why not simply use iconv? but that's just for char set conversion, how would we get the locale data (like time/date format, etc)? i guess we have no choice but to parse the definition files, then. Correct, it is apparantly libc itself, not iconv, but the point is if clocale can, why not abstract it that way. Because the textmode versions might not be installed on all systems, the compiled versions might be OS specific, and if they ever change for linux distributions you have another problem at your hand. And IMHO it is not crucial enough to try to bypass libc. i agree. my opinion has always been that since it's a libc invention in the first place , libc will always be available on systems with this locale information, so it's a lot easier just linking to libc and using nl_langinfo to set up the global variables in fpc. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
2009/3/20 Marco van de Voort mar...@stack.nl: In our previous episode, Henry Vermaak said: Because the textmode versions might not be installed on all systems, the compiled versions might be OS specific, and if they ever change for linux distributions you have another problem at your hand. And IMHO it is not crucial enough to try to bypass libc. i agree. my opinion has always been that since it's a libc invention in the first place , libc will always be available on systems with this locale information, so it's a lot easier just linking to libc and using nl_langinfo to set up the global variables in fpc. That's what clocale already does. Note that the way how this happens is not straight forward, since the exact interpretation of what libc returns and which fields are filled differ. See clocale. i know, i've seen it before. So please start with inventorizing what clocale doesn't do, and see if this can be amended some other way before embarking on great adventures into the unknown, because those are never _that_ simple. Specially when done multiplatform and then maintained over time (hence: multiversion). i think you misunderstand me, i've looked at this thing ages ago and come to the same conclusion. i'm just trying to convince the people that scream dependency that it's not worth going through the effort. it would really be reinventing _someone else's_ wheel. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Henry Vermaak said: multiplatform and then maintained over time (hence: multiversion). i think you misunderstand me Seems I have. i've looked at this thing ages ago and come to the same conclusion. i'm just trying to convince the people that scream dependency that it's not worth going through the effort. it would really be reinventing _someone else's_ wheel. Well, a bit of reinvention is not always a bad thing, but only if it is _really_ necessary. Note that a bulky read externally alternative won't be enabled by default in FPC anyway, so it doesn't even alleviate the need to include clocale issue. The point is if in this case it is worth the trouble if most people then happily link to X or Lazarus. I can imagine that e.g. somebody doing point of sales systems or so or has mixed libc/uclibc systems wants to avoid it, but IMHO that is a specialist solution and doesn't belong in the greater FPC distribution. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
Note that a bulky read externally alternative won't be enabled by default in FPC anyway, so it doesn't even alleviate the need to include clocale issue. The point is if in this case it is worth the trouble if most people then happily link to X or Lazarus. Personally I would like to see the formatsettings being localised by default (by SysUtils), since on Windows it is (Delphi compatibility) and I'd expect it ot be the same on all platforms. For this reason a bulky read external alternative might be useful if we do not want SysUtils be dependent on libc. In that case I'd opt for parsing the text-based versions, since the compiled ones are libc dependent (their format changes). Anyone who links his app to libc (like a standard Lazarus app) can the hapilly include clocale (because the text-based parsing might not be 100% accurate). Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] SQLDB/Firebird unable to open table with more than 128 fields
Hi, I've found a bug in sqldb/firebird. Its reported here, with sample project to reproduce: http://bugs.freepascal.org/view.php?id=13340 Regards, Funky Beast ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
On Fri, Mar 20, 2009 at 4:28 PM, Bart bartjun...@gmail.com wrote: Personally I would like to see the formatsettings being localised by default (by SysUtils), since on Windows it is (Delphi compatibility) and I'd expect it ot be the same on all platforms. For this reason a bulky read external alternative might be useful if we do not want SysUtils be dependent on libc. Exactly. It is currently very annoying that my Windows apps have correct locale settings and the exact same application under Linux doesn't. To resolve this, I had to build a config screen into my application where the user can specify correct formatting for various things. In that case I'd opt for parsing the text-based versions, since the compiled ones are libc dependent (their format changes). Seeing that correct locale information is totally missing on anything but Windows, I don't see why we can't enable correct locale information on systems we can support via parsing text files for now. And incrementally add support for other platforms like FreeBSD etc as we figure out what to do - without linking to libc. My alternative is to build locale information into fpGUI's translation files. But that would only solve my problems (any fpGUI based apps) and not anybody else's. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Bart said: Note that a bulky read externally alternative won't be enabled by default in FPC anyway, so it doesn't even alleviate the need to include clocale issue. The point is if in this case it is worth the trouble if most people then happily link to X or Lazarus. Personally I would like to see the formatsettings being localised by default (by SysUtils), since on Windows it is (Delphi compatibility) and I'd expect it ot be the same on all platforms. For this reason a bulky read external alternative might be useful if we do not want SysUtils be dependent on libc. It's really doubtful it would be done that way. It just adds a possible reason for breakage to (in practice) each binary. The timezone stuff didn't really make me happy. Since it is only a global (and not per unit) decision, Delphi compatibility doesn't say much, since project-wide information is not Delphi compatible in the first place. A plugin is the more logical route, for the ones that want to remain libc free, but want to risk maintainance problems. In that case I'd opt for parsing the text-based versions, since the compiled ones are libc dependent (their format changes). Are they guaranteed default installed on most OSes ? It's pretty hard to parse something that is not there. Also start inventorizing all possible solutions on all possible distro's and OSes. Anyone who links his app to libc (like a standard Lazarus app) can the hapilly include clocale (because the text-based parsing might not be 100% accurate). But has an unneeded size penalty (and breakage, since it is always run!). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SQLDB/Firebird unable to open table with more than 128 fields
2009/3/20 Funky Beast funkybe...@pacific.net.sg: I've found a bug in sqldb/firebird. Its reported here, with sample project to reproduce: http://bugs.freepascal.org/view.php?id=13340 What version of Firebird? How many bytes does a single record require? Maybe you reached the table limit in Firebird RDBMS? If I remember correctly MS SQL Server 2000 had a record size byte limit and I would imagine other RDBMS's have something similar. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Graeme Geldenhuys said: Personally I would like to see the formatsettings being localised by default (by SysUtils), since on Windows it is (Delphi compatibility) and I'd expect it ot be the same on all platforms. For this reason a bulky read external alternative might be useful if we do not want SysUtils be dependent on libc. Exactly. It is currently very annoying that my Windows apps have correct locale settings and the exact same application under Linux doesn't. To resolve this, I had to build a config screen into my application where the user can specify correct formatting for various things. Well, if you are so strung up on orthogonality, maybe we should move the windows detection to clocale also :_) In that case I'd opt for parsing the text-based versions, since the compiled ones are libc dependent (their format changes). Seeing that correct locale information is totally missing on anything but Windows Just include clocale. I don't see why we can't enable correct locale information on systems we can support via parsing text files for now. Make a libc-free plugin unit, and it can be added as package. I see no problem in that, as long as it is suitably multiplatform. And incrementally add support for other platforms like FreeBSD etc as we figure out what to do - without linking to libc. No other platforms as afterthought please! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
2009/3/20 Bart bartjun...@gmail.com: Note that a bulky read externally alternative won't be enabled by default in FPC anyway, so it doesn't even alleviate the need to include clocale issue. The point is if in this case it is worth the trouble if most people then happily link to X or Lazarus. Personally I would like to see the formatsettings being localised by default (by SysUtils), since on Windows it is (Delphi compatibility) and I'd expect it ot be the same on all platforms. For this reason a bulky read external alternative might be useful if we do not want SysUtils be dependent on libc. you can't do this automatically, since there will be a performance penalty and you're not even sure that the locale definitions are installed. In that case I'd opt for parsing the text-based versions, since the compiled ones are libc dependent (their format changes). Anyone who links his app to libc (like a standard Lazarus app) can the hapilly include clocale (because the text-based parsing might not be 100% accurate). on debian (for example), the locale definitions are bundled up in the locales package, which depends on glibc. i'm willing to bet that you won't find these definitions bundled without localedef, since that's the only program that uses them. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
On Fri, Mar 20, 2009 at 4:54 PM, Marco van de Voort mar...@stack.nl wrote: Well, if you are so strung up on orthogonality, maybe we should move the windows detection to clocale also :_) Well it's simple for me really. I moved away from Lazarus LCL simply because of inconsistencies between platforms. Hence the reason I use fpGUI Toolkit. I would prefer FPC to be more consistent between platforms compared to LCL. Just include clocale. Part of using fpGUI Toolkit is to greatly minimise library dependencies (compared to other GUI toolkits like GTK, QT, LCL etc.). This allows fpGUI based apps to run on a lot more bare boned systems and platforms (new and old). Make a libc-free plugin unit, and it can be added as package. I see no problem in that, as long as it is suitably multiplatform. Yes, this is how I was going to start it off. Simply include the unit in your project and locale files are parse and variables populated. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
2009/3/20 Marco van de Voort mar...@stack.nl: Are they guaranteed default installed on most OSes ? It's pretty hard to parse something that is not there. Also start inventorizing all possible solutions on all possible distro's and OSes. no, none of my embedded systems have the definition files. also, they depend on glibc under debian. Anyone who links his app to libc (like a standard Lazarus app) can the hapilly include clocale (because the text-based parsing might not be 100% accurate). But has an unneeded size penalty (and breakage, since it is always run!). exactly. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
2009/3/20 Graeme Geldenhuys graemeg.li...@gmail.com: Part of using fpGUI Toolkit is to greatly minimise library dependencies (compared to other GUI toolkits like GTK, QT, LCL etc.). This allows fpGUI based apps to run on a lot more bare boned systems and platforms (new and old). but fpgui depends on x, right? and x depends on libc? you might as well include clocales by default under an ifdef (like lazarus does with cthreads). henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: SQLDB/Firebird unable to open table with more than 128 fields
Graeme Geldenhuys wrote: 2009/3/20 Funky Beast funkybeast-s7p20sfedvbhupcrv1q...@public.gmane.org: I've found a bug in sqldb/firebird. Its reported here, with sample project to reproduce: http://bugs.freepascal.org/view.php?id=13340 What version of Firebird? How many bytes does a single record require? Maybe you reached the table limit in Firebird RDBMS? If I remember correctly MS SQL Server 2000 had a record size byte limit and I would imagine other RDBMS's have something similar. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal-pd4fty7x32k2wbthl531ywd2fqjk+...@public.gmane.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal Hi, Its Firebird 2.0.3, that bug only appears in sqldb/firebird combination. The same table that this combo can't open, opens successfully with fblib-0.85, flamerobin and fenixsql. There's a sample project in the bug report which generates a firebird database file with a table that produces the bug automatically. All fields are *integer* fields. You can generate any number of fields by executing the sample project with an integer argument. It failed at 128. I'm aware of the size limit, but the bug appears way below the limit (Firebird docs says you can have approximately 16,000 integer fields per taable). I'm guessing that somewhere in ibase60.inc or TIBConnection might have a misplaced declaration between shortint/smallint.(I'm basing this on hunch that a short type has a range of -128..127) Regards, Funky Beast ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal arrays vs TStringList.DelimitedText
Paul Nicholls writes: Hi Francisco, regular arrays can start at whatever index you want: Var MyArray1 : Array[1..3] Of Integer; Thanks for the info and examples. Dynamic Arrays : MyDynamicArray : Array Of Integer; .. These always start with a zero index. This is very usefull too. I will check when I use a class for the first time. I guess most will start at zero then since the classes probably use dynamic arrays. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Printed documentation
Graeme Geldenhuys writes: Anybody know of a printing company in South Africa that will be willing to do a once off print? Searching google for book printing small quantities Returned a decent list. I think it would only be a matter of seeing which one is closer to you or can deliver to your destination. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Sending UDP packets windows, linux
With 2 Linux PC's this works, but I wanted to connect a Linux and a Windows
computer.
Would that be possible with UDP packets?
fpsendto blocks the program now in windows.
function socksend( d : pointer ; l : word ) : longint;
begin
result := fpsendto( inet_socket , d , l , 0 , @inetaddrsend ,
sizeof( inetaddrsend ) );
end;
function sockreceive( d : pointer ; maxlen : word ) : longint;
var msg : longint;
begin
memclr( @inetaddrrecv , sizeof( inetaddrrecv ) );
inetaddrrecv.sin_family := AF_INET;
// inetaddrrecv.sin_addr := strtonetaddr( s1 );// Empfangsadresse
// inetaddrrecv.sin_port := htons( net_port );
msg := 0;
{$ifdef linux}
msg := msg_dontwait;
{$endif}
result := fprecv( inet_socket , d , maxlen , msg );
// result := fprecvfrom( inet_socket , d , maxlen , msg , @inetaddrrecv ,
sizeof( inetaddrrecv ) );
end;
function init_socket( s1 , s2 : string ; exeproc : net_execproc ; var erg :
longint = -1 ) : boolean;
var
r : boolean;
nb : dword;
n : integer;
const net_port = $8000;
begin
memclr( @inetaddrbind , sizeof( inetaddrbind ) );
inetaddrbind.sin_family := AF_INET;
inetaddrbind.sin_addr := strtonetaddr( s1 );// Empfangsadresse
inetaddrbind.sin_port := htons( net_port );
memclr( @inetaddrsend , sizeof( inetaddrsend ) );
inetaddrsend.sin_family := AF_INET;
inetaddrsend.sin_addr := strtonetaddr( s2 );// Sendeadresse
inetaddrsend.sin_port := htons( net_port );
net_execute := exeproc;
inet_socket := fpsocket( PF_INET , SOCK_DGRAM , 0 );
if inet_socket = 0 then begin
{$ifdef windows}
nb := 1; // 1=nonblocking, 0=blocking
n := ioctlsocket( inet_socket , FIONBIO , @nb );
{$endif}
inet_bind := fpbind( inet_socket , @inetaddrbind , sizeof( inetaddrbind ) );
erg := socketerror;
result := inet_bind = 0;
end
else result := false;
mylo_os_net_ipxok := result;
end;
procedure exit_socket;
begin
if inet_socket 0 then closesocket( inet_socket );
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TStream ReadComponent
Hi, I'm trying to read a file stream created using TMemoryStream's WriteComponent method with a Delphi 7 program. To read the component I use TMemoryStream's ReadComponent method. When I read use ReadCompoent, a EReadError is raised. Does anyone tried this?. The same program works perfectly in Delphi. Leonardo. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream ReadComponent
On Fri, 20 Mar 2009, Leonardo M. Ramé wrote: Hi, I'm trying to read a file stream created using TMemoryStream's WriteComponent method with a Delphi 7 program. To read the component I use TMemoryStream's ReadComponent method. When I read use ReadCompoent, a EReadError is raised. Does anyone tried this?. The same program works perfectly in Delphi. It's not guaranteed that the streams created by Delphi 7 and FPC are binary equivalent. The best you can do in such a case is to create a text stream in delphi, FPC should be able to convert and read that. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
