> > > 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 s
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
> libr
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
On Sun, Mar 22, 2009 at 8:37 AM, Graeme Geldenhuys
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 ARM
> sy
On Fri, Mar 20, 2009 at 5:04 PM, Henry Vermaak 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 ARM
systems (tested
On 3/21/09, Marco van de Voort 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 package, s
In our previous episode, Bart said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 3/20/09, Marco van de Voort 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
On 3/20/09, Marco van de Voort 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 installed on most OS
2009/3/20 Graeme Geldenhuys :
>
> 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
2009/3/20 Marco van de Voort :
>
> 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, th
On Fri, Mar 20, 2009 at 4:54 PM, Marco van de Voort 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
2009/3/20 Bart :
>> 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.
>
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" alter
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
On Fri, Mar 20, 2009 at 4:28 PM, Bart 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 mi
> 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
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 "depend
2009/3/20 Marco van de Voort :
> 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:
> > 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
2009/3/20 Marco van de Voort :
> 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
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 :
>
> 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 for
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//LC_MESSAGES
> > but also other LC_ fi
2009/3/20 Marco van de Voort :
> 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/shar
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/l
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 fo
2009/3/19 Marco van de Voort :
> 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.
>
>
2009/3/19 Bart :
>> 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:
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/l
> 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/locale
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
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 SysUti
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.
>
On Thu, Mar 19, 2009 at 11:40 AM, Michael Van Canneyt
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 st
On Thu, 19 Mar 2009, Graeme Geldenhuys wrote:
> On Thu, Mar 19, 2009 at 10:55 AM, ik 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 abou
On Thu, Mar 19, 2009 at 10:55 AM, ik 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 ba
On Thu, Mar 19, 2009 at 10:48 AM, Marco van de Voort 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 cros
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 da
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 depen
On Thu, Mar 19, 2009 at 10:17 AM, ik 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 c
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
wrote:
> [moved the conversation from Lazarus mailing list]
>
>
> O
[moved the conversation from Lazarus mailing list]
On Wed, Mar 18, 2009 at 7:29 PM, Bart 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 giv
42 matches
Mail list logo
