[fpc-pascal] locale solution for unix systems
[moved the conversation from Lazarus mailing list] On Wed, Mar 18, 2009 at 7:29 PM, Bart bartjun...@gmail.com wrote: Yes, i see. I have those files on Suse too. Not sure what package is responsible. An rpm -q locale (or locales) reveals nothing. I'm pretty sure rpm must have a way to query it by giving the file and asking what package it belongs to. I was under the impression that actually the LC_xxx files in /usr/lib/locales/ determined the locale setting? I think the /usr/share/i18n/locales/* files are simply text based versions of those files - I have not confirmed this though, on speculating. See that grouping differs. (I have not extensively checked other LC_xxx files) I have tried that test on my side using en_GB, en_ZA and af_ZA and the grouping is the same in either text or LC_xxx files. Maybe your text files and LC_xxx files are differing versions? Either way, parsing the /usr/share/i18n/locales/* should give much better locale results than the current FPC implementation under Unix systems. If you don't use the libc locale unit, everything is hard-coded to en_US which is not so nice. 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] Boehm GC
Hi bd, than I guess, this is why you look at the boehm gc (that's why I was looking at it). I have put some haxe/neko pascal related code at http://code.google.com/p/pascal4neko/ The code is only tested with delphi, but should work with fpc as well. There is no memory manager for boehm, but some code which shows how to handle the gc for objects and interfaces. If you have any questions, you can contact me directly, because this a bit OT for this list. Cheers, Adrian. ritchie turner schrieb: Hi Adrian, Guilty! bd. On Wed, 2009-03-18 at 17:03 +0100, Adrian Veith wrote: ritchie turner schrieb: Thanks all, I've got something to go on now. bd. bye the way - are you black dog from the haxe list ? Cheers, Adrian. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ 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 order to know what is the active local in Unix/Linux you should check the environment variables. If it was not defined or it stand on C, then en_US is inplace. Ido On Thu, Mar 19, 2009 at 8:49 AM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: [moved the conversation from Lazarus mailing list] On Wed, Mar 18, 2009 at 7:29 PM, Bart bartjun...@gmail.com wrote: Yes, i see. I have those files on Suse too. Not sure what package is responsible. An rpm -q locale (or locales) reveals nothing. I'm pretty sure rpm must have a way to query it by giving the file and asking what package it belongs to. I was under the impression that actually the LC_xxx files in /usr/lib/locales/ determined the locale setting? I think the /usr/share/i18n/locales/* files are simply text based versions of those files - I have not confirmed this though, on speculating. See that grouping differs. (I have not extensively checked other LC_xxx files) I have tried that test on my side using en_GB, en_ZA and af_ZA and the grouping is the same in either text or LC_xxx files. Maybe your text files and LC_xxx files are differing versions? Either way, parsing the /usr/share/i18n/locales/* should give much better locale results than the current FPC implementation under Unix systems. If you don't use the libc locale unit, everything is hard-coded to en_US which is not so nice. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pas...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
On Thu, Mar 19, 2009 at 10:17 AM, ik ido...@gmail.com wrote: In order to know what is the active local in Unix/Linux you should check the environment variables. If it was not defined or it stand on C, then en_US is inplace. Currently FPC doesn't populate the locale variable on unix systems (if you don't compile your application with the libc related units). $ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_DK.UTF-8 LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=en_GB.UTF-8 LC_ADDRESS=en_GB.UTF-8 LC_TELEPHONE=en_GB.UTF-8 LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=en_GB.UTF-8 LC_ALL= Yet if I create a simple console application the date formats etc are all en_US. I want to write a new unit that doesn't rely on libc (seeing that it isn't available on all UNIX-style platforms) that will parse the correct locale text files (base on LC_xxx environment variables) and populate the locale variables in the RTL. It's on my todo list, but I have a few more things to finish before I can start this project. 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
On Thu, Mar 19, 2009 at 10:48 AM, Marco van de Voort mar...@stack.nl wrote: Note that clocale depends on iconv, not (strictly) libc, though in some system iconv is bundled into the libc library. That's what I meant. :) 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
On Thu, 19 Mar 2009, Graeme Geldenhuys wrote: On Thu, Mar 19, 2009 at 10:55 AM, ik ido...@gmail.com wrote: The locale itself is not just ascii based files, there are compiled files, so you will require to re-implement the way of reading the data inside the compiled files. I'm not talking about the compiled binary files, I am talking about the text based locale files. On my Linux Ubuntu 7.10 system they are include in the 'locales' package and are install in the following directory location: /usr/share/i18n/locales/* eg: usr/share/i18n/locales/wo_SN /usr/share/i18n/locales/xh_ZA /usr/share/i18n/locales/yi_US /usr/share/i18n/locales/zh_CN /usr/share/i18n/locales/zh_HK /usr/share/i18n/locales/zh_SG /usr/share/i18n/locales/zh_TW /usr/share/i18n/locales/zu_ZA For example here in Israel our first work day in the week is Sunday and not Monday, so you will need to work with it. Also our date format is dd/mm/ and not mm/dd/ or /mm/dd etc.. Currency separator is comma, the actual names of things are in Here is the details of the /usr/share/i18n/locales/he_IL file: [ he_IL ]--- .snip.. LC_MONETARY int_curr_symbol U0049U004CU0053U0020 currency_symbol U05E9U05D7 mon_decimal_point U002E mon_thousands_sep U002C mon_grouping 3;3 positive_sign negative_sign U002D int_frac_digits 2 frac_digits 2 p_cs_precedes 1 p_sep_by_space1 n_cs_precedes 1 n_sep_by_space1 p_sign_posn 2 n_sign_posn 2 END LC_MONETARY .snip LC_TIME ...snip d_fmt U0025U0064U002FU0025U006DU002FU0025U0079 t_fmt U0025U0048U003AU0025U004DU003AU0025U0053 first_weekday 1 END LC_TIME snip --[ end ]--- For example: South Africa's date format is also dd/mm/ and is defined as follows: % Date representation to be referenced by the %x field descriptor - % %d/%m/%Y, day/month/year as decimal numbers (01/01/2000). d_fmt U0025U0064U002FU0025U006DU002FU0025U0059 Hebrew, so for each locale you will require to re-implement all of this rules. That's why using the libc functions is better. All the locale information seems to be in those text files (date, time, paper size, day;week;month names, measurements, names, addresses etc.). It's just a matter of parsing them and populating the locale variables in FPC. No external programs or libraries are required. As per fpGUI Toolkit's design rules: I hate 3rd party requirements! :-) BTW: Does FPC's locale variables cover all the locale categories? For example: category en_ZA:2003;LC_IDENTIFICATION category en_ZA:2000;LC_CTYPE category en_ZA:2000;LC_COLLATE category en_ZA:2003;LC_TIME category en_ZA:2000;LC_NUMERIC category en_ZA:2000;LC_MONETARY category en_ZA:2003;LC_MESSAGES category en_ZA:2000;LC_PAPER category en_ZA:2000;LC_MEASUREMENT category en_ZA:2003;LC_NAME category en_ZA:2003;LC_ADDRESS category en_ZA:2003;LC_TELEPHONE If not, can we extend the FPC locale variable to include salutation (names), telephone, measurement, paper sizes etc.. In that case I think we better start a 'locale' unit. I don't want to burden SysUtils with even more stuff. 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
On Thu, Mar 19, 2009 at 11:40 AM, Michael Van Canneyt mich...@freepascal.org wrote: If not, can we extend the FPC locale variable to include salutation (names), telephone, measurement, paper sizes etc.. In that case I think we better start a 'locale' unit. I don't want to burden SysUtils with even more stuff. Would that then mean we could fix issues like Russian locales that use unicode characters which do not fit into a Char size (as is used in the current local variables)? Or would that be a totally different can of worms. 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
On Thu, Mar 19, 2009 at 10:55 AM, ik ido...@gmail.com wrote: The locale itself is not just ascii based files, there are compiled files, so you will require to re-implement the way of reading the data inside the compiled files. I'm not talking about the compiled binary files, I am talking about the text based locale files. On my Linux Ubuntu 7.10 system they are include in the 'locales' package and are install in the following directory location: /usr/share/i18n/locales/* eg: usr/share/i18n/locales/wo_SN /usr/share/i18n/locales/xh_ZA /usr/share/i18n/locales/yi_US /usr/share/i18n/locales/zh_CN /usr/share/i18n/locales/zh_HK /usr/share/i18n/locales/zh_SG /usr/share/i18n/locales/zh_TW /usr/share/i18n/locales/zu_ZA For example here in Israel our first work day in the week is Sunday and not Monday, so you will need to work with it. Also our date format is dd/mm/ and not mm/dd/ or /mm/dd etc.. Currency separator is comma, the actual names of things are in Here is the details of the /usr/share/i18n/locales/he_IL file: [ he_IL ]--- .snip.. LC_MONETARY int_curr_symbol U0049U004CU0053U0020 currency_symbol U05E9U05D7 mon_decimal_point U002E mon_thousands_sep U002C mon_grouping 3;3 positive_sign negative_sign U002D int_frac_digits 2 frac_digits 2 p_cs_precedes 1 p_sep_by_space1 n_cs_precedes 1 n_sep_by_space1 p_sign_posn 2 n_sign_posn 2 END LC_MONETARY .snip LC_TIME ...snip d_fmt U0025U0064U002FU0025U006DU002FU0025U0079 t_fmt U0025U0048U003AU0025U004DU003AU0025U0053 first_weekday 1 END LC_TIME snip --[ end ]--- For example: South Africa's date format is also dd/mm/ and is defined as follows: % Date representation to be referenced by the %x field descriptor - % %d/%m/%Y, day/month/year as decimal numbers (01/01/2000). d_fmt U0025U0064U002FU0025U006DU002FU0025U0059 Hebrew, so for each locale you will require to re-implement all of this rules. That's why using the libc functions is better. All the locale information seems to be in those text files (date, time, paper size, day;week;month names, measurements, names, addresses etc.). It's just a matter of parsing them and populating the locale variables in FPC. No external programs or libraries are required. As per fpGUI Toolkit's design rules: I hate 3rd party requirements! :-) BTW: Does FPC's locale variables cover all the locale categories? For example: category en_ZA:2003;LC_IDENTIFICATION category en_ZA:2000;LC_CTYPE category en_ZA:2000;LC_COLLATE category en_ZA:2003;LC_TIME category en_ZA:2000;LC_NUMERIC category en_ZA:2000;LC_MONETARY category en_ZA:2003;LC_MESSAGES category en_ZA:2000;LC_PAPER category en_ZA:2000;LC_MEASUREMENT category en_ZA:2003;LC_NAME category en_ZA:2003;LC_ADDRESS category en_ZA:2003;LC_TELEPHONE If not, can we extend the FPC locale variable to include salutation (names), telephone, measurement, paper sizes etc.. 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
The locale itself is not just ascii based files, there are compiled files, so you will require to re-implement the way of reading the data inside the compiled files. If you wish to make rules on your own, well it's way too much information to add to RTL. For example here in Israel our first work day in the week is Sunday and not Monday, so you will need to work with it. Also our date format is dd/mm/ and not mm/dd/ or /mm/dd etc.. Currency separator is comma, the actual names of things are in Hebrew, so for each locale you will require to re-implement all of this rules. That's why using the libc functions is better. Or am I missing here something in what you are saying ? Ido On Thu, Mar 19, 2009 at 10:44 AM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On Thu, Mar 19, 2009 at 10:17 AM, ik ido...@gmail.com wrote: In order to know what is the active local in Unix/Linux you should check the environment variables. If it was not defined or it stand on C, then en_US is inplace. Currently FPC doesn't populate the locale variable on unix systems (if you don't compile your application with the libc related units). $ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_DK.UTF-8 LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=en_GB.UTF-8 LC_ADDRESS=en_GB.UTF-8 LC_TELEPHONE=en_GB.UTF-8 LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=en_GB.UTF-8 LC_ALL= Yet if I create a simple console application the date formats etc are all en_US. I want to write a new unit that doesn't rely on libc (seeing that it isn't available on all UNIX-style platforms) that will parse the correct locale text files (base on LC_xxx environment variables) and populate the locale variables in the RTL. It's on my todo list, but I have a few more things to finish before I can start this project. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pas...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Graeme Geldenhuys said: If not, can we extend the FPC locale variable to include salutation (names), telephone, measurement, paper sizes etc.. In that case I think we better start a 'locale' unit. I don't want to burden SysUtils with even more stuff. Would that then mean we could fix issues like Russian locales that use unicode characters which do not fit into a Char size (as is used in the current local variables)? Or would that be a totally different can of worms. I think that would be a different can of worms. Format et al are ansistring, not widestring/unicodestring. It doesn't know about unicode, only the local (non mbcs) charset. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
Marco van de Voort schrieb: In our previous episode, Graeme Geldenhuys said: If not, can we extend the FPC locale variable to include salutation (names), telephone, measurement, paper sizes etc.. In that case I think we better start a 'locale' unit. I don't want to burden SysUtils with even more stuff. Would that then mean we could fix issues like Russian locales that use unicode characters which do not fit into a Char size (as is used in the current local variables)? Or would that be a totally different can of worms. I think that would be a different can of worms. Format Format has a widestring flavour? et al are ansistring, not widestring/unicodestring. It doesn't know about unicode, only the local (non mbcs) charset. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
In our previous episode, Florian Klaempfl said: Would that then mean we could fix issues like Russian locales that use unicode characters which do not fit into a Char size (as is used in the current local variables)? Or would that be a totally different can of worms. I think that would be a different can of worms. Format Format has a widestring flavour? True. Missed that. I quickly looked, and noticed two things: - Does it (still) work, since it seems to include an includefile with functions as implementation that return a char? - The tformatsettings is still ansistring. However if the default locale is UTF-8 this might translate to unicode? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] using fpc on a arm4t system failed
Hi, i installed fpc-2.2.2 with the arm-linux-binaries from the main page. the installation finished with no problems. but when i try to use on of the installed programms (e.g. ppcarm, fpc or fpcmake) i get a Illegal instruction error. What ARM CPUs are supported by FPC? My cpu info : r...@om-gta02:/opt/lazarus# cat /proc/cpuinfo Processor : ARM920T rev 0 (v4l) BogoMIPS: 198.65 Features: swp half thumb CPU implementer : 0x41 CPU architecture: 4T CPU variant: 0x1 CPU part: 0x920 CPU revision: 0 Hardware: GTA02 Revision: 0350 Serial : ___ 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: Yet if I create a simple console application the date formats etc are all en_US. I want to write a new unit that doesn't rely on libc (seeing that it isn't available on all UNIX-style platforms) libc what and where? Note that clocale depends on iconv, not (strictly) libc, though in some system iconv is bundled into the libc library. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] proxy for sql
This isn't really a FPC question, but since the application is being written in FPC I thought I would ask here. I am developing an application that controls machinery. The application will store everything that happens in a SQL database. Some clients (restricted) should have permission to access the database to generate their own reports via some 3rd party report generation software of their choice. However I want to restrict who has access without placing a user password on the SQL server since some clients purchase multiple instances of the SW but not all options. 1) Is it possible to place my app between the 3rd party app and the SQL server? How would I do this. 2) Is it possible to configure the SQL server to query my app to see if a user can log on? 3) Any other ideas? Regards, Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] proxy for sql
On Thu, 19 Mar 2009, Andreas Berger wrote: This isn't really a FPC question, but since the application is being written in FPC I thought I would ask here. I am developing an application that controls machinery. The application will store everything that happens in a SQL database. Some clients (restricted) should have permission to access the database to generate their own reports via some 3rd party report generation software of their choice. However I want to restrict who has access without placing a user password on the SQL server since some clients purchase multiple instances of the SW but not all options. 1) Is it possible to place my app between the 3rd party app and the SQL server? How would I do this. I seriously doubt this, unless you write an ODBC driver that connects to your application instead of the database. There is no way to know in advance what tool the user will use, and ODBC is more or less the only standard that most reporting tools support... 2) Is it possible to configure the SQL server to query my app to see if a user can log on? That depends on the database and how your login is defined. In e.g. firebird, I don't think this is possible. IMHO Your best shot is to force a particular reporting tool. I have very good experiences with FastReport, however it currently does not work with FPC. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
off-topic [Re: [fpc-pascal] proxy for sql]
Andreas Berger wrote: This isn't really a FPC question, but since the application is being written in FPC I thought I would ask here. I am developing an application that controls machinery. The application will store everything that happens in a SQL database. Some clients (restricted) should have permission to access the database to generate their own reports via some 3rd party report generation software of their choice. However I want to restrict who has access without placing a user password on the SQL server since some clients purchase multiple instances of the SW but not all options. 1) Is it possible to place my app between the 3rd party app and the SQL server? How would I do this. 2) Is it possible to configure the SQL server to query my app to see if a user can log on? 3) Any other ideas? Regards, Andreas Well I imagine that will be hard to do, if you do it in FPC (since you may have to start from scratch). I don't think there is a component emulating the mysql server interface. Rewriting the server (just the protocol part) is a lot of work. You may want to look at the mysql site, they have a mysql-proxy, which can be controlled by LUA script. So that my do the trick for you. You could probably replace the client credentials inside the proxy. Make sure you forward using a restricted account. Otherwise you must ensure that nothing in the sql could ever violate the permissions. Best Regards Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] proxy for sql
Andreas Berger wrote: This isn't really a FPC question, but since the application is being written in FPC I thought I would ask here. I am developing an application that controls machinery. The application will store everything that happens in a SQL database. Some clients (restricted) should have permission to access the database to generate their own reports via some 3rd party report generation software of their choice. However I want to restrict who has access without placing a user password on the SQL server since some clients purchase multiple instances of the SW but not all options. 1) Is it possible to place my app between the 3rd party app and the SQL server? How would I do this. 2) Is it possible to configure the SQL server to query my app to see if a user can log on? 3) Any other ideas? Here is another idea. You would still need a user on the DB, to limit what can be accessed. But to check if access should be granted (allow or deny tcp) you can use your own software. All you need is some sort of Proxy/socket forwarder, that you can implement using FPC. The Tool would run on the users local PC or Server. It would accept connections for the database, and forward the Connection straight to the real DB (or maybe encrypt it, using whatever access control). Of course if the user is not allowed to connect at all, you do not make the forward. The user could have a key(public/private), so if you remove the opposite on the server, the user can no longer connect. However this acts like a tunnel, so you do not get any control on the SQL itself. The SQL server needs to be configured to restrict access to the permitted data. Best Regards Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] proxy for sql
Martin Friebe wrote: Here is another idea. You would still need a user on the DB, to limit what can be accessed. But to check if access should be granted (allow or deny tcp) you can use your own software. All you need is some sort of Proxy/socket forwarder, that you can implement using FPC. The Tool would run on the users local PC or Server. It would accept connections for the database, and forward the Connection straight to the real DB (or maybe encrypt it, using whatever access control). Of course if the user is not allowed to connect at all, you do not make the forward. The user could have a key(public/private), so if you remove the opposite on the server, the user can no longer connect. However this acts like a tunnel, so you do not get any control on the SQL itself. The SQL server needs to be configured to restrict access to the permitted data. Best Regards Martin Thanks Martin for the idea. Actually I had already thought of this. The problem is that 3rd party report programs connect directly to the SQL server. I would need a password or some other ID to know that THIS 3rd party prog is allowed to enter, so a direct tunnel is not possible. The only way might be for me to capture the user and password handshake, test if the user\password is correct for my app and then substitute it with the real user\password or cut the connection. But for this I would have to interpret the logon sequence and I have no idea how that works. Regards, Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] locale solution for unix systems
I'm not talking about the compiled binary files, I am talking about the text based locale files. On my Linux Ubuntu 7.10 system they are include in the 'locales' package and are install in the following directory location: /usr/share/i18n/locales/* eg: usr/share/i18n/locales/wo_SN /usr/share/i18n/locales/xh_ZA 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. For instance I don't have any xx_XX.utf8 dir in /usr/share/118n/locales, but my LANG setting is nl_NL.UTF-8 Bart ___ 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: usr/share/i18n/locales/wo_SN /usr/share/i18n/locales/xh_ZA 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 It could be that the ones in /usr/local are older, they use a single level (xx) country designation instead of the threelevel (xx_yy.zz) ISO one. ___ 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/19 Bart bartjun...@gmail.com: I'm not talking about the compiled binary files, I am talking about the text based locale files. On my Linux Ubuntu 7.10 system they are include in the 'locales' package and are install in the following directory location: /usr/share/i18n/locales/* eg: usr/share/i18n/locales/wo_SN /usr/share/i18n/locales/xh_ZA 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. the files in /usr/lib/locale are the compiled locale definition files (using localdef). i've only got one file there: locale-archive. these files are used by the libc locale functions (like nl_langinfo). 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/19 Marco van de Voort mar...@stack.nl: In our previous episode, Bart said: usr/share/i18n/locales/wo_SN /usr/share/i18n/locales/xh_ZA 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. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] using fpc on a arm4t system failed
Beni, Please try the ARM-Linux example on this page and see if it works: http://www.turbocontrol.com/helloworld.htm -- Regards, Paul Breneman http://www.TurboControl.com http://www.TurboControl.com/embeddedfreepascal.htm - Notes on using FreePascal on embedded systems http://www.TurboControl.com/monitor.htm - Free environment monitoring programs http://www.TurboControl.com/TPSupport.htm - TurboPower support links ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] using fpc on a arm4t system failed
same problem with this test. just the output Illegal instruction. nothing in dmesg. --- r...@om-gta02:/opt/test# tar -xvzf HelloWorld-fpc-2.2.2.arm-linux.tar.gz copying copying.fpc hello.pas ppcarm prt0.o system.o system.ppu TurboControlDistributionReadMe.txt r...@om-gta02:/opt/test# ./ppcarm hello Illegal instruction -- Paul Breneman schrieb: Beni, Please try the ARM-Linux example on this page and see if it works: http://www.turbocontrol.com/helloworld.htm -- Regards, Paul Breneman ___ 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 the rules how to decide which file to process. First check for LC_ALL environmentvariable, if it is set it overrules any LC_xxx env.var. set If no LC_ALL check for env.var. LC_xxx If no LC_xxx check for env.var LANG (If nothing there, defualt to US system settings) The env.var found has the following format: language[_territory[.codeset...@modifier] To get a fallback do (in this order) 1. remove codeset 2. remove normalised codeset (I have no Idea what that means) 3. remove territory 4. remove modifier. (fallback method found at http://ftp.gnu.org/gnu/glibc/glibc-2.5.tar.bz2) However I found that the locale program (/usr/bin/locale) does not exactly behave like this. My $LANG = nl_NL.UTF-8 The nl_NL.UTF-8 directory (in /usr/lib/locale) does not exist and it falls back on nl_NL.utf8 Any comments appreciated. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Pascal arrays vs TStringList.DelimitedText
Getting back to Pascal.. Aren't pascal arrays 1 based? As I get myself re-acquainted with pascal I am working on a small open source utility. Bumped into something that confused me.. It seems TStringList.DelimitedText produces an array that starts at zero, but from what I can tell regular arrays start at 1. Is there a list anywhere of which classes in the FCL use arrays that start at zero? Tried reading the Tstringlist documentation and the beginning of the classes unit for any indicator of arrays in that unit starting at zero, but did not see any. Did I miss it? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal arrays vs TStringList.DelimitedText
- Original Message - From: Francisco Reyes li...@stringsutils.com To: FreePascal list fpc-pascal@lists.freepascal.org Sent: Friday, March 20, 2009 2:32 PM Subject: [fpc-pascal] Pascal arrays vs TStringList.DelimitedText Getting back to Pascal.. Aren't pascal arrays 1 based? As I get myself re-acquainted with pascal I am working on a small open source utility. Bumped into something that confused me.. It seems TStringList.DelimitedText produces an array that starts at zero, but from what I can tell regular arrays start at 1. Is there a list anywhere of which classes in the FCL use arrays that start at zero? Tried reading the Tstringlist documentation and the beginning of the classes unit for any indicator of arrays in that unit starting at zero, but did not see any. Did I miss it? Hi Francisco, regular arrays can start at whatever index you want: Var MyArray1 : Array[1..3] Of Integer; MyArray2 : Array[-3..21] Of String; Dynamic Arrays : Var MyDynamicArray : Array Of Integer; These always start with a zero index. TStringList and similar classes use a zero index too. I don't know if there is any list like you want though... cheers, Paul ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
