A plugin is the more logical route, for the ones that want to remain
libc
free, but want to risk maintainance problems.
Like an fplocale unit, that users can include if they do not want to
use clocale?
Yes, I don't see a problem with that, if the quality is suitable. (read:
On Fri, Mar 20, 2009 at 5:04 PM, Henry Vermaak henry.verm...@gmail.com wrote:
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).
fpGUI depends on libx11 for X11 based systems. Also on embedded
On Sun, Mar 22, 2009 at 8:37 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
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).
fpGUI depends on libx11 for X11 based systems. Also on
In our previous episode, Bart said:
I could help writing the Linux (only x86 32-bit) part of it, I only
have acces to my own (almost ancient) Linux and WinME system for
development.
It was mostly a hint at the other unices, since it would indeed be *nix
only. VMs get you a long way, and you
In our previous episode, Graeme Geldenhuys said:
But last time I tested libc was not available for FreeBSD. Hence the
reason I have code as follows (which only includes libc when the OS is
Linux on cpu386).
OK, maybe I am confusing myself - between the libc unit and the libc
library as
On 3/20/09, Marco van de Voort mar...@stack.nl wrote:
A plugin is the more logical route, for the ones that want to remain libc
free, but want to risk maintainance problems.
Like an fplocale unit, that users can include if they do not want to
use clocale?
Are they guaranteed default
In our previous episode, Bart said:
[ Charset ISO-8859-1 unsupported, converting... ]
On 3/20/09, Marco van de Voort mar...@stack.nl wrote:
A plugin is the more logical route, for the ones that want to remain libc
free, but want to risk maintainance problems.
Like an fplocale unit, that
On 3/21/09, Marco van de Voort mar...@stack.nl wrote:
Like an fplocale unit, that users can include if they do not want to
use clocale?
Yes, I don't see a problem with that, if the quality is suitable. (read: the
code quality is good and multiplatform).
I won't accept a linux own
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
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
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
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,
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
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
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.
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
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
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
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
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
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
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
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
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
[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
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
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
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 -
___
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
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
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 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
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
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
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
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
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
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
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/*
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.
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
41 matches
Mail list logo
