On 09/14/2011 09:00 PM, Hans-Peter Diettrich wrote:
Every (reasonable) OS provides such features in its debug API.
Available support depends on the actual hardware, of course.
Can you point us to a description (Win XP, Win 7, Linux ?)
Thanks,
-Michael
On 09/14/2011 08:47 PM, dmitry boyarintsev wrote:
That's true. The only thing concerns me about that, is there's no
really a standard in GDB (i can be wrong).
This of course would be a necessary condition for working with the gdb team.
Also, IRC, Apple forked gdb (as well other gnu-tools) to
On 09/14/2011 05:02 PM, Hans-Peter Diettrich wrote:
The NT WinAPI (not 9x) *implements* everything in the Wide (UTF-16)
routines
without reference-counting: Yak !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/14/2011 05:19 PM, Hans-Peter Diettrich wrote:
Can you specify, *which* strings ever *require* platform specific
encoding?
If not strings, Chars do:
MyString := 'Öse';
MyChar := MyString[1];
-Michael
___
fpc-devel maillist -
On 09/14/2011 07:24 PM, Hans-Peter Diettrich wrote:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character.
Yep.
The problem is that a normal programmer (especially a beginner) does
not know (and does not want to know, and IMHO should not
On 14/09/2011 17:02, Hans-Peter Diettrich wrote:
Many users still want simple string handling, with direct mapping
between logical and physical chars (SBCS). This is not possible at all
with UTF-8, while UTF-16 works fine with the BMP, at least.
What rubbish! The only utf-8 limit is that
On 15/09/2011 06:19, Martin Schreiber wrote:
Agreed. And so it is made in MSEgui:
Yeah, and everything you said applies to fpGUI, except I use TfpgString,
TfpgChar and the UTF-8 encoding. Though I would prefer having the
native encoding on each platform - thus less conversions and
On 15/09/2011 09:43, Michael Schnell wrote:
there are lots of file systems in Linux. They can work differently. i.e.
FAT works case insensitive while ext* works cases sensitive. IMHO ext
completely ignores character coding and just works on byte arrays.
You also forgot to mention that most
On Thu, Sep 15, 2011 at 1:50 AM, Luiz Americo Pereira Camara
luiz...@oi.com.br wrote:
OK. The drawback is increasing file size of executables (that are already
big).
And disk storages are getting each time bigger. Any modern smartphone
comes with at least 8GB of storage ...
--
Felipe Monteiro
In our previous episode, Hans-Peter Diettrich said:
Lazarus was forced to make out of the identity of ANSIString and
UTF8String seemingly forced by FPC. e.g.:
Old programs assuming local ANSI 8 bit code retrieved from LCL GUI
components, compiled with the new version don't work (e.g.
Hi,
On Thu, 15 Sep 2011 09:31:39 +0200, Michael Schnell wrote:
On 09/14/2011 09:00 PM, Hans-Peter Diettrich wrote:
Every (reasonable) OS provides such features in its debug API.
Available support depends on the actual hardware, of course.
Can you point us to a description (Win XP, Win 7,
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
How many users will have to deal with chars outside the Unicode BMP?
You are very narrow minded! It depends on the application you are
developing. Lets take a Science application as an example. Many
scientific symbols fall
On 15/09/2011 10:16, Michael Schnell wrote:
In fact users want to deal with decently coded characters and not
with cryptic bytes some of which together are representing a
character. (e.g. when doing MyChar := MyString[1]; )
None of our company's users using our products would even
2011/9/15 Michael Schnell mschn...@lumino.de:
In fact users want to deal with decently coded characters and not with
cryptic bytes some of which together are representing a character. (e.g.
when doing MyChar := MyString[1]; )
I think of Unicode text as a stream of Unicode characters in some
On 14/09/2011 20:47, dmitry boyarintsev wrote:
really a standard in GDB (i can be wrong). But I've seen a lot of
issues in Lazarus gdb-support, because of the different builds of GDB
used.
Exactly the reason we need a FPC based debugger. Currently each Linux
distro includes a different version
On Thursday 15 September 2011 10:27:28 Graeme Geldenhuys wrote:
And considering the amount of text processing apps I have written
(plenty of them), indexed character access is really not a top priority
or a often used feature.
Graeme, please have look into:
On Thu, Sep 15, 2011 at 10:59 AM, Martin Schreiber mse00...@gmail.com wrote:
There are plenty of user problems with utf-8 character access and string
length. I assume 100% of them would be solved with utf-16.
It would solve for those writing buggy software which ignores part of
the Unicode
On 15/09/2011 09:53, Michael Schnell wrote:
If not strings, Chars do:
MyString := 'Öse';
MyChar := MyString[1];
and to show you AGAIN how flawed your direct index access to a
character example is. How is that 'Öse' entered into the system.
Is the Ö a
U+00D6 LATIN CAPITAL LETTER O WITH
On 15/09/2011 11:06, Felipe Monteiro de Carvalho wrote:
It would solve for those writing buggy software which ignores part of
the Unicode characters.
On the other hand 100% of them would be solved correctly, for all
Unicode characters by using LCLProc.UTF8CharacterLength
+1 on both
On 15/09/2011 10:59, Martin Schreiber wrote:
There are plenty of user problems with utf-8
Then they are not well versed in Unicode are they...
character access
in fpGUI:
UTF8Copy(...)
UTF8CharAtByte(...)
and string length.
in fpGUI:
Length(...) result is in bytes
On 09/15/2011 10:39 AM, Graeme Geldenhuys wrote:
MyChar := UTF8Copy(MyString, 1, 1);
The above example is safe,
Of course. But generations of Pascal programmers have been trained to do
MyChar := MyString[1];
So it would at least be candid to abolish the String[i] notation as a
syntax
On 09/15/2011 10:43 AM, cobines wrote:
MyChar := MyString[1]
appropriate function retrieves first unicode character, regardless of encoding.
MyChar is an 8 bit thingy and thus is not even able to hold a Unicode
'ä' (in what ever UTF).
-Michael
___
On 09/15/2011 11:08 AM, Graeme Geldenhuys wrote:
+1 on both counts.
Hoping for complex things to automatically be solved by just ignoring
the complexity usually leads into hell.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote:
and to show you AGAIN how flawed your direct index access to a
character example is.
It's not my intend to use it. I'll never use it as I do know that it
is bound to create problems. But it is what generations of pascal
programmers are trained
On Thursday 15 September 2011 11:06:00 Felipe Monteiro de Carvalho wrote:
On Thu, Sep 15, 2011 at 10:59 AM, Martin Schreiber mse00...@gmail.com
wrote:
There are plenty of user problems with utf-8 character access and string
length. I assume 100% of them would be solved with utf-16.
It
On 09/14/2011 07:24 PM, Hans-Peter Diettrich wrote:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character.
Unicode is 32 Bis and allowing for (nearly) any supported character.
So a 32 Bit UnicodeCharacter in fact is very viable.
-Michael
On Thursday 15 September 2011 11:15:22 Graeme Geldenhuys wrote:
And now there should be an even more complex string type implemented?
UTF-8 is not more complex at all.
A new encoding aware FPC string type is more complex.
Martin
___
fpc-devel
2011/9/15 Michael Schnell mschn...@lumino.de:
Of course. But generations of Pascal programmers have been trained to do
MyChar := MyString[1];
Such people should retrain if they want to switch to Unicode using
some instructions how to convert your application. If they do not
want, they should
On 15/09/2011 10:38, Michael Schnell wrote:
On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote:
and to show you AGAIN how flawed your direct index access to a
character example is.
It's not my intend to use it. I'll never use it as I do know that it
is bound to create problems. But it is what
On 09/15/2011 11:40 AM, cobines wrote:
Such people should retrain if they want to switch to Unicode using
some instructions how to convert your application.
In fact they don't know about Unicode and thus don't even know that they
need training :-) .
If they do not
want, they should stay with
On 09/15/2011 11:43 AM, Martin wrote:
Which imho makes utf8 far more preferable than utf16
in UTF8 the error is bound to happen
ROFL.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 15/09/2011 11:38, Michael Schnell wrote:
is bound to create problems. But it is what generations of pascal
programmers are trained to do. They all need to be re-trained.
Just like all Delphi developers had to since Delphi 2009+. Obviously,
the RTL could cater for it, or implement more
2011/9/15 Michael Schnell mschn...@lumino.de:
If thy use Lazarus they are forced to use Unicode unless they wand to stick
with a very old version.
Then this is a problem of Lazarus. They want to make applications with
Lazarus (which is always UTF-8?) and they are unaware of using Unicode
where
On 09/15/2011 12:41 PM, cobines wrote:
I don't know if in Delphi you can use just Ansi,
Delphi is a completely different matter as (by default) old versions use
ANSI and new versions use Unicode in NewDelphiStrins with dynamic encoding.
-Michael
___
2011/9/15 Michael Schnell mschn...@lumino.de:
Delphi is a completely different matter as (by default) old versions use
ANSI and new versions use Unicode in NewDelphiStrins with dynamic encoding.
I see. Then people switching from Delphi/Ansi to Lazarus/UTF-8 will
have problems if they are not
On Thu, Sep 15, 2011 at 5:52 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Last night I made some good progress with my forked Duby. Over 50
patches since the fork, loads of memory leak fixes, class cleanup by
slowly removing those pesky global variables, finally have a working
http://bugs.freepascal.org/view.php?id=20225
I did run a test on w32 vista
with gdb 6.7.5 / 7.0 / 7.2.1 / 7.3.1 / 7.3.2
with fpc 2.4.4 / recent fixes 2.6 / recent trunk
stabs
dwarf
dwarf3 (only trunk + gdb 7.3.2)
the result:
- all combinations of gdb and fpc using stabs got the
On 15/09/2011 13:52, Marcos Douglas wrote:
And you will provide these patches, from SVN/Git, right? =)
Yes of course. Now that I know Dmitry's goals for Duby is quite
different to mine [based on his recent posts], I'll publish it to GitHub
in due time - with a different project name to
On 09/15/2011 01:26 PM, cobines wrote:
I see. Then people switching from Delphi/Ansi to Lazarus/UTF-8 will
have problems if they are not aware they have to adjust their
applications.
Switching from Lazarus-pre-Unicode, Delphi pre-Unicode and
Delphi-Unicode will cause this problems (for not
On 15 Sep 2011, at 13:55, Martin wrote:
http://bugs.freepascal.org/view.php?id=20225
I did run a test on w32 vista
with gdb 6.7.5 / 7.0 / 7.2.1 / 7.3.1 / 7.3.2
with fpc 2.4.4 / recent fixes 2.6 / recent trunk
stabs
dwarf
dwarf3 (only trunk + gdb 7.3.2)
The DWARF3 implementation
On Thu, Sep 15, 2011 at 11:15 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
in fpGUI:
UTF8Copy(...)
UTF8CharAtByte(...)
in fpGUI:
Length(...) result is in bytes
UTF8Length(...) result is in characters
Well, here we see why I started this thread. fpGUI and the LCL are
Jonas wrote:
The DWARF information is correct. Maybe Anton is using a GDB on a
Fedora-based distribution. Fedora's GDB is built from the Archer
branch. It's possible that this fixes another bug in GDB that is also
triggered by the DWARF2-encoding of dynamic arrays.
This morning I tried the
On 15 Sep 2011, at 17:34, Seth Grover wrote:
This morning I tried the vanilla GDB 7.2 release, the vanilla GDB
7.3.1 release, and various git branches from the archer branch
(http://sourceware.org/gdb/wiki/ProjectArcher), specifically the
archer-jankratochvil-vla and archer-tromey-python
On Thu, 15 Sep 2011 17:21:47 +0200
Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote:
On Thu, Sep 15, 2011 at 11:15 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
in fpGUI:
UTF8Copy(...)
UTF8CharAtByte(...)
in fpGUI:
Length(...) result is in bytes
On Thu, Sep 15, 2011 at 6:01 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
It seems to me, that all of the above functions and classes could be
solved for applications using UTF-8 ansistrings with a special
widestring manager and filefunction manager, right?
Theorically, it could, but
On Thu, 2011-09-15 at 09:34 -0600, Seth Grover wrote:
Jonas wrote:
The DWARF information is correct. Maybe Anton is using a GDB on a
Fedora-based distribution. Fedora's GDB is built from the Archer
branch. It's possible that this fixes another bug in GDB that is also
triggered by the
On Thu, 15 Sep 2011 19:00:35 +0200
Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote:
On Thu, Sep 15, 2011 at 6:01 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
It seems to me, that all of the above functions and classes could be
solved for applications using UTF-8
Graeme Geldenhuys schrieb:
There shouldn't be anything complicated for the developer or
enduser. UnicodeString under Linux and Mac should be UTF-8, under
Windows it should be UTF-16.
You're a bit inconsequent ;-)
UTF-8 is much more complicated to handle by the user, than
Michael Schnell schrieb:
On 09/15/2011 09:57 AM, Graeme Geldenhuys wrote:
What the hell has experience got to do with the preference between
UTF-8 and UTF-16?
In fact users want to deal with decently coded characters and not with
cryptic bytes some of which together are representing a
Graeme Geldenhuys schrieb:
On 14/09/2011 17:02, Hans-Peter Diettrich wrote:
Many users still want simple string handling, with direct mapping
between logical and physical chars (SBCS). This is not possible at all
with UTF-8, while UTF-16 works fine with the BMP, at least.
What rubbish!
cobines schrieb:
2011/9/15 Michael Schnell mschn...@lumino.de:
Of course. But generations of Pascal programmers have been trained to do
MyChar := MyString[1];
Such people should retrain if they want to switch to Unicode using
some instructions how to convert your application. If they do not
cobines schrieb:
2011/9/15 Michael Schnell mschn...@lumino.de:
In fact users want to deal with decently coded characters and not with
cryptic bytes some of which together are representing a character. (e.g.
when doing MyChar := MyString[1]; )
I think of Unicode text as a stream of Unicode
cobines schrieb:
2011/9/15 Michael Schnell mschn...@lumino.de:
If thy use Lazarus they are forced to use Unicode unless they wand to stick
with a very old version.
Then this is a problem of Lazarus. They want to make applications with
Lazarus (which is always UTF-8?) and they are unaware of
Martin schrieb:
On 15/09/2011 10:38, Michael Schnell wrote:
On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote:
and to show you AGAIN how flawed your direct index access to a
character example is.
It's not my intend to use it. I'll never use it as I do know that it
is bound to create problems.
Michael Schnell schrieb:
On 09/14/2011 05:19 PM, Hans-Peter Diettrich wrote:
Can you specify, *which* strings ever *require* platform specific
encoding?
If not strings, Chars do:
MyString := 'Öse';
MyChar := MyString[1];
So what?
(which platform function would require such coding?)
DoDi
Graeme Geldenhuys schrieb:
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
How many users will have to deal with chars outside the Unicode BMP?
You are very narrow minded! It depends on the application you are
developing. Lets take a Science application as an example. Many
Marco van de Voort schrieb:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character. A Unicode BMP user could be happy
with a 2-byte char, of course, at his own (low) risk.
Probably. But while a good point for a application builder based in
On 15/09/2011 19:36, Hans-Peter Diettrich wrote:
Martin schrieb:
On 15/09/2011 10:38, Michael Schnell wrote:
On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote:
and to show you AGAIN how flawed your direct index access to a
character example is.
It's not my intend to use it. I'll never use it
On 15/09/2011 19:52, Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
How many users will have to deal with chars outside the Unicode BMP?
Any app that loads a text from disk.
it can never know what the text contains.
On Thu, Sep 15, 2011 at 8:16 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
Yes.
Or 3 - migrate LCL to UTF8String
Indeed. And we can aditionally provide UTF-8 versions of routines like
we do now for people to use, or alternatively people can also use
Unicode RTL routines if the extra
In our previous episode, Felipe Monteiro de Carvalho said:
And I say more, two RTLs will immediately cause problems in all kinds
of libraries.
Why?
Will the FCL work with the Ansi RTL, with the Unicode
RTL, with both?
Generally both, and problematic packages are not coded in string but in
In our previous episode, Hans-Peter Diettrich said:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character. A Unicode BMP user could be happy
with a 2-byte char, of course, at his own (low) risk.
Probably. But while a good point for
Joost wrote:
That should work. Did you compile using -gw3?
I did, but it behaves even more strangely (I can't seem to print any
variables). However I'm not in the trunk, I'm using 2.4.4 (this is a
production environment) so maybe there's more recent changes in the
dwarf 3 generation I don't
On 15 September 2011 18:43, Hans-Peter Diettrich wrote:
UTF-8 is much more complicated to handle by the user, than e.g. UTF-16.
I don't see this. Please give an example?
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI
On 15 September 2011 17:21, Felipe Monteiro de Carvalho wrote:
// file operations
function FileExistsUTF8(const Filename: string): boolean;
function FileAgeUTF8(const FileName: string): Longint;
fpGUI has similar, for file handling functions.
With the currently planned Unicode RTL it
On 15 September 2011 19:09, Hans-Peter Diettrich wrote:
What data type would you use, to store an UTF-8 character?
And how to access the n-th character in an UTF-8 string?
I already showed how in a previous post. For more details on how fpGUI
does this, have a look at the fpg_base.pas and
On Thu, 15 Sep 2011 22:51:36 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 15 September 2011 18:43, Hans-Peter Diettrich wrote:
UTF-8 is much more complicated to handle by the user, than e.g. UTF-16.
I don't see this. Please give an example?
Please don't.
This was
On 15 September 2011 20:52, Hans-Peter Diettrich wrote:
When I want a program for German or French users, I'll hire an coder with
experience in those *languages*, not with experience only in Unicode.
Why? We simply hired average people (not programmers) to translate
your English resource
- Graeme Geldenhuys graemeg.li...@gmail.com schreef:
On 15 September 2011 19:09, Hans-Peter Diettrich wrote:
What data type would you use, to store an UTF-8 character?
And how to access the n-th character in an UTF-8 string?
I already showed how in a previous post. For more
- Graeme Geldenhuys graemeg.li...@gmail.com schreef:
Why? We simply hired average people (not programmers) to translate
your English resource strings into German, Portuguese, French etc..
No
other modifications where required. No code or programs had to be
recompiled. Our resource
2011/9/15 Hans-Peter Diettrich drdiettri...@aol.com:
cobines schrieb:
When doing:
MyChar := MyString[1]
appropriate function retrieves first unicode character, regardless of
encoding.
This is just wrong :-(
MyString[1] accesses the first element of the *physical* character array,
On 16/09/2011 00:03, cobines wrote:
2011/9/15 Hans-Peter Diettrichdrdiettri...@aol.com:
cobines schrieb:
When doing:
MyChar := MyString[1]
appropriate function retrieves first unicode character, regardless of
encoding.
This is just wrong :-(
MyString[1] accesses the first element of the
Who will be the first to write a UnicodeString object that uses an
AnsiString as buffer so we can start doing some tests?
What is in the cpstrnew and other unicode branches of FPC? (sorry, I'm
using a 3G limited connection and FPC doesn't have a viewvc...)
Can we start putting well thought-out
On Thu, Sep 15, 2011 at 3:34 AM, Michael Schnell mschn...@lumino.de wrote:
Yak !
Is a reunification in progress ?
I'd ask on Apple-dev-maillist, gdb-maillist, gnu-maillist or Jonas :)
2 Graeme: thanks for your hard work! I could definitely use code clean-ups.
thanks,
Dmitry
Martin schrieb:
On 15/09/2011 19:52, Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
How many users will have to deal with chars outside the Unicode BMP?
Any app that loads a text from disk.
Again: please answer my question first:
Marco van de Voort schrieb:
FPC also allows to use Complex values - but nobody is forced to use such
numbers without any good reason and technical (mathematical) background.
The same for the use of astral Unicode characters, IMO.
IMHO you are right, but the big difference is of course that
On 15/9/2011 12:21, Felipe Monteiro de Carvalho wrote:
Lazarus is literally being forced to implement it's own RTL...
With the currently planned Unicode RTL it will just get worse, we will
then need to either migrate to UnicodeString
No.
Lazarus can continue to use UTF-8.
Just there will
Graeme Geldenhuys schrieb:
RTL is a mere *display* feature, the chars still are stored from first to
My problem is not the implementation, but the fact that I can't read
or understand any right-to-left languages. :)
Don't worry, a compiler also doesn't understand any but his own
language,
Graeme Geldenhuys schrieb:
On 15 September 2011 20:52, Hans-Peter Diettrich wrote:
When I want a program for German or French users, I'll hire an coder with
experience in those *languages*, not with experience only in Unicode.
Why? We simply hired average people (not programmers) to translate
2011/9/16 Martin laza...@mfriebe.de:
On 16/09/2011 00:03, cobines wrote:
2011/9/15 Hans-Peter Diettrichdrdiettri...@aol.com:
cobines schrieb:
When doing:
MyChar := MyString[1]
appropriate function retrieves first unicode character, regardless of
encoding.
This is just wrong :-(
2011/9/16 Luiz Americo Pereira Camara luiz...@oi.com.br:
Lazarus can continue to use UTF-8.
Just there will be an implicit conversion when using those functions. The
overhead is minimum.
Currently UTF8String is just an alias for AnsiString, i.e., the
implicit conversion UTF8String -
81 matches
Mail list logo
