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
> >
> > wrote:
> >> One with unicode string, one with ansistring. They will have the same
> >> code, but will be compiled twice, each
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 ever
On 14/9/2011 06:41, Felipe Monteiro de Carvalho wrote:
On Wed, Sep 14, 2011 at 11:32 AM, Luiz Americo Pereira Camara
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
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 Wed, Sep 14, 2011 at 6:48 AM, Michael Schnell 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 me about that, is
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.
No
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 h
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 seem
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 spec
Felipe Monteiro de Carvalho schrieb:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
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 must be.
Is this possi
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 o
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 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. e.g.:
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 charac
On 09/14/2011 01:01 PM, Michael Schnell wrote:
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.
Sorry, (typing too fast again)
Only 0x00 (end of name) and '/' are interpreted.
AFAIK, even '\" is allowe
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/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 informat
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.
-Mi
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 de
On Wed, Sep 14, 2011 at 12:03 PM, Marco van de Voort 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? They ex
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-
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 Mattia
In our previous episode, Felipe Monteiro de Carvalho said:
> 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 must be.
>
> Is this possible in UNIX? I ca
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 e
On Wed, Sep 14, 2011 at 11:53 AM, Marco van de Voort 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.
>
> I'm not
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 op
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
Felipe Monteiro de Carvalho hat am 14.
September 2011 um 10:51 geschrieben:
> On Wed, Sep 14, 2011 at 9:45 AM, Mattias Gaertner
> 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
On Wed, Sep 14, 2011 at 11:32 AM, Luiz Americo Pereira Camara
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)
This would
On Wed, Sep 14, 2011 at 6:04 AM, Felipe Monteiro de Carvalho
wrote:
> On Wed, Sep 14, 2011 at 10:46 AM, 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
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 motiva
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: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 f
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 uni
On Wed, Sep 14, 2011 at 10:46 AM, 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 native encoding.
>
On 14 Sep 2011, at 10:40, Alexander Klenin wrote:
On Wed, Sep 14, 2011 at 19:03, Jonas Maebe
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
On Wed, Sep 14, 2011 at 9:45 AM, Mattias Gaertner
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 make it impossible to iden
On Wed, 14 Sep 2011, Graeme Geldenhuys wrote:
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
On Wed, Sep 14, 2011 at 19:03, Jonas Maebe 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?
--
Alexander S. Klenin
On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Wed, Sep 14, 2011 at 8:59 AM, 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/app
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 Schreiber
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
Am 14.09.2011 07:50, schrieb Felipe Monteiro de Carvalho:
On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreiber 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 use
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
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 Wed, 14 Sep 2011 08:50:22 +0200
Felipe Monteiro de Carvalho wrote:
> On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreiber wrote:
> > Linux expects an array of bytes in filenames (no encoding, no utf-8) AFAIK.
>
> That's a nice theory, but:
It's more than theory.
You can use file names under Li
On Wed, Sep 14, 2011 at 8:59 AM, 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 string to AppendStr in th
Reported it in Mantis so that is does not get forgotten.
http://bugs.freepascal.org/view.php?id=20238
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel maillist -
On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
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?
No, why
48 matches
Mail list logo