On 14/09/2011 03:56, Luiz Americo Pereira Camara wrote:
I propose that the above behavior be implemented as a type named RTLString
The Object Pascal language already has enough damn string types. I
really don't think we should be adding fuel to the fire, by adding yet
more string types!
So
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
Current strategy on fpc core seems to be to have 2 RTLs:
One with unicode string, one with ansistring.
Isn't that somewhat nasty for people currently using UTF-8?
I mean, lets say that we can divide everyone
On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreiber mse00...@gmail.com wrote:
Linux expects an array of bytes in filenames (no encoding, no utf-8) AFAIK.
That's a nice theory, but:
All Linux distributions that I know use utf-8
Android uses utf-8
Meego uses utf-8
So, do you have any concrete
On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
One with unicode string, one with ansistring. They will have the same code,
but will be compiled twice, each time with a different compiler define to
On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
Current strategy on fpc core seems to be to have 2 RTLs:
One with unicode string, one with ansistring.
Isn't that somewhat nasty for people currently
On Wed, Sep 14, 2011 at 8:59 AM, michael.vancann...@wisa.be wrote:
No, why do you think so ?
Well, at the very least:
1 All var parameters from the RTL will no longer be directly usable
with UTF-8 strings
http://www.freepascal.org/docs-html/rtl/sysutils/appendstr.html
How can I pass a UTF-8
On Wed, 14 Sep 2011 08:50:22 +0200
Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote:
On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreiber mse00...@gmail.com wrote:
Linux expects an array of bytes in filenames (no encoding, no utf-8) AFAIK.
That's a nice theory, but:
It's
On 13/09/2011 21:23, Michael Van Canneyt wrote:
Current strategy on fpc core seems to be to have 2 RTLs:
One with unicode string, one with ansistring.
Can you clarify a bit. When you say unicode string to you mean UTF-16
(Delphi's definition of a unicode string), or do you mean a Unicode
On 14 Sep 2011, at 04:15, Paul Ishenin wrote:
If I change cdecl to stdcall in g_object_dosomething then it
compiles with no error.
For me it is strange. Should developer care about internal compiler
representation of an array of const for different conventions?
It's more that even
Am 14.09.2011 07:50, schrieb Felipe Monteiro de Carvalho:
On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreibermse00...@gmail.com wrote:
Linux expects an array of bytes in filenames (no encoding, no utf-8) AFAIK.
That's a nice theory, but:
All Linux distributions that I know use utf-8
Android
On 14.09.2011 09:08, Martin Schreiber wrote:
Am 14.09.2011 07:50, schrieb Felipe Monteiro de Carvalho:
On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreibermse00...@gmail.com
wrote:
Linux expects an array of bytes in filenames (no encoding, no utf-8)
AFAIK.
That's a nice theory, but:
All Linux
On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Wed, Sep 14, 2011 at 8:59 AM, michael.vancann...@wisa.be wrote:
No, why do you think so ?
Well, at the very least:
1 All var parameters from the RTL will no longer be directly usable
with UTF-8 strings
On Wed, Sep 14, 2011 at 19:03, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
It's more that even though both are called array of const, they are
completely different things. They also don't support the same types.
Perhaps varargs-compatible parameter type should be called something else then?
On Wed, Sep 14, 2011 at 9:45 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
It's more than theory.
You can use file names under Linux that are no valid UTF-8.
At work I see it every week.
In this case then for sure we cannot only have file routines only in
UTF-16, because that would
On 14 Sep 2011, at 10:40, Alexander Klenin wrote:
On Wed, Sep 14, 2011 at 19:03, Jonas Maebe
jonas.ma...@elis.ugent.be wrote:
It's more that even though both are called array of const, they are
completely different things. They also don't support the same types.
Perhaps varargs-compatible
On Wed, Sep 14, 2011 at 10:46 AM, michael.vancann...@wisa.be wrote:
Can you clarify a bit. When you say unicode string to you mean UTF-16
(Delphi's definition of a unicode string), or do you mean a Unicode
string in the true sense - it can be utf-8 or utf-16 etc depending on
the platform's
In our previous episode, Felipe Monteiro de Carvalho said:
Following from a discussion on mac-pascal, I'd like to propose a
solution for Unicode support.
First and for all. Backwards compat dropping is not going to happen. If we
were planning that, we had changed everything to something
On 14/9/2011 03:40, Graeme Geldenhuys wrote:
On 14/09/2011 03:56, Luiz Americo Pereira Camara wrote:
I propose that the above behavior be implemented as a type named RTLString
The Object Pascal language already has enough damn string types. I
really don't think we should be adding fuel to the
Unfortunately, once about 2 mails are exchanged on the subject of what I
actually tried to talk about, the whole discussion takes off and all
kind of debugger woes are included
So back again:
I am trying to find out, if the below could make a reasonable feature
request (and therefore have
On 14/9/2011 03:48, Felipe Monteiro de Carvalho wrote:
[..]
Of course one path is migrating everything, the LCL, the IDE, SynEdit,
all packages, etc, to UTF-16, but that's a huge, immense work with
zero advantages over what we are doing up to now, it's just migrate to
migrate, who will be
On Wed, Sep 14, 2011 at 6:04 AM, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
On Wed, Sep 14, 2011 at 10:46 AM, michael.vancann...@wisa.be wrote:
Can you clarify a bit. When you say unicode string to you mean UTF-16
(Delphi's definition of a unicode string), or do you
On Wed, Sep 14, 2011 at 11:32 AM, Luiz Americo Pereira Camara
luiz...@oi.com.br wrote:
Because if someone for some reason, like porting Delphi code, stays with a
UTF16 string, under windows, when using RTL functions TWO conversions will
be made:
User Code (UTF16) RTL (UTF8) WINAPI (UTF16)
Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com hat am 14.
September 2011 um 10:51 geschrieben:
On Wed, Sep 14, 2011 at 9:45 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
It's more than theory.
You can use file names under Linux that are no valid UTF-8.
At work
On 14/09/2011 11:19, Luiz Americo Pereira Camara wrote:
This is not desirable simply because at each platform (windows / unix)
the user code of the same program will have a different encoding
increasing the possibility of subtle errors.
Why? Not every program is a text manipulation program
In our previous episode, Felipe Monteiro de Carvalho said:
* Make file-handling routines which take filenames as parameters from
the RTL modular so that the LCL can implement them with UTF-8 support.
This plus a UTF-8 widestring manager and the Ansi RTL can be fully
UTF-8.
I'm not as
On Wed, Sep 14, 2011 at 11:53 AM, Marco van de Voort mar...@stack.nl wrote:
* Make file-handling routines which take filenames as parameters from
the RTL modular so that the LCL can implement them with UTF-8 support.
This plus a UTF-8 widestring manager and the Ansi RTL can be fully
UTF-8.
On 14/09/2011 11:04, Felipe Monteiro de Carvalho wrote:
IMHO a platform-dependent string would be the worse solution of all
... far worse then migrating to UTF-16.
I don't see why? Use the RTL functions to manipulate your text strings.
Both the string and RTL functions will use the same
In our previous episode, Felipe Monteiro de Carvalho said:
And why would the interfaces change in the other proposal?
It is only
1 more overloaded option for the routines,
Which is just 1 more interface change. And for something that is a temporary
workaround.
That is what I like on Mattias
In our previous episode, Martin Schreiber said:
Is this possible in UNIX? I can see that in Windows you can use the
trick to use W versions which are identical except for the string type
and drop Windows 9x support, but is this really possible for the UNIX
syscalls? They expect UTF-8 not
On Wed, Sep 14, 2011 at 12:03 PM, Marco van de Voort mar...@stack.nl wrote:
Is this possible in UNIX? I can see that in Windows you can use the
trick to use W versions which are identical except for the string type
and drop Windows 9x support, but is this really possible for the UNIX
syscalls?
On 09/13/2011 04:52 PM, Hans-Peter Diettrich wrote:
It's not the CPU, it's more the MMU which can help in finding changed
(global) variables.
AFAIK, the MMU can not work in byte addresses but just with much bigger
blocks of data. So it does not seem to help with finding a write access
to a
On 09/13/2011 02:53 PM, Joost van der Sluis wrote:
You do know that GDB does have a Pascal extension, right?
IMHO, if we really can work with the gdb team on feeding the necessary
Object-Pascal specific add-ons into gdb, creating a new debugger from
scratch does not make any sense at all.
On 09/13/2011 04:59 PM, Hans-Peter Diettrich wrote:
IMO you're addressing the wrong audience. Most things, beyond
breakpoint handling, stepping and memory read/writes, can be done
outside the debugger. Such external code is not bound to debugger
support, and can use language specific
On 09/14/2011 08:50 AM, Felipe Monteiro de Carvalho wrote:
All Linux distributions that I know use utf-8
Android uses utf-8
Meego uses utf-8
AFAIK, the EXT system does not care about the code the file-name
byte-arrays are done in. only 0x00 (end of name) and '\' are interpreted.
-Michael
On 09/14/2011 10:51 AM, Felipe Monteiro de Carvalho wrote:
In this case then for sure we cannot only have file routines only in
UTF-16, because that would make it impossible to identify many files
in Linux...
Who says that file names are supposed to be human readable and this done
in some
On 09/14/2011 11:05 AM, Marco van de Voort wrote:
First and for all. Backwards compat dropping is not going to happen.
It already has and supposedly can't be avoided. Take a look of what
Lazarus was forced to make out of the identity of ANSIString and
UTF8String seemingly forced by FPC.
On 14.09.2011 12:44, Michael Schnell wrote:
On 09/13/2011 04:52 PM, Hans-Peter Diettrich wrote:
It's not the CPU, it's more the MMU which can help in finding changed
(global) variables.
AFAIK, the MMU can not work in byte addresses but just with much bigger
blocks of data. So it does not seem
On 09/14/2011 01:58 PM, Sven Barth wrote:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary
from the complete process memory down to
Felipe Monteiro de Carvalho schrieb:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
One with unicode string, one with ansistring. They will have the same code,
but will be compiled twice, each time with a different compiler define to
decide which version it
Graeme Geldenhuys schrieb:
If FPC has true unicode support, then all functions should work correct
with just the UnicodeString type. That type's encoding is based on the
native encoding of each platform. NO performance hit required.
Can you specify, *which* strings ever *require* platform
Michael Schnell schrieb:
On 09/14/2011 11:05 AM, Marco van de Voort wrote:
First and for all. Backwards compat dropping is not going to happen.
It already has and supposedly can't be avoided. Take a look of what
Lazarus was forced to make out of the identity of ANSIString and
UTF8String
Graeme Geldenhuys schrieb:
As for the text-to-braille functionality, that is outside the scope of
the FPC and RTL. But common sense should prevail, use RTL string
functions to implement your conversion - don't assume 1 byte = 1
character. A unicode aware string iterator could be implemented to
Sven Barth schrieb:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary from
the complete process memory down to only the page size.
On Wed, Sep 14, 2011 at 6:48 AM, Michael Schnell mschn...@lumino.de wrote:
IMHO, if we really can work with the gdb team on feeding the necessary
Object-Pascal specific add-ons into gdb, creating a new debugger from
scratch does not make any sense at all.
That's true. The only thing concerns
On 14.09.2011 14:53, Michael Schnell wrote:
On 09/14/2011 01:58 PM, Sven Barth wrote:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary
On 14/9/2011 06:41, Felipe Monteiro de Carvalho wrote:
On Wed, Sep 14, 2011 at 11:32 AM, Luiz Americo Pereira Camara
luiz...@oi.com.br wrote:
Because if someone for some reason, like porting Delphi code, stays with a
UTF16 string, under windows, when using RTL functions TWO conversions will
be
On 14/9/2011 06:48, Graeme Geldenhuys wrote:
On 14/09/2011 11:19, Luiz Americo Pereira Camara wrote:
This is not desirable simply because at each platform (windows / unix)
the user code of the same program will have a different encoding
increasing the possibility of subtle errors.
Why? Not
On Wednesday 14 September 2011 17:02:14 Hans-Peter Diettrich wrote:
Felipe Monteiro de Carvalho schrieb:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
One with unicode string, one with ansistring. They will have the same
code, but will be compiled
48 matches
Mail list logo
