On Wed, 22 Aug 2012 09:34:33 +0500
Ivanko B wrote:
> > Do you mean replacing a character in an UCS-2/UCS-4 string can be
> > implemented more efficiently than in an UTF-8/UTF-16 string?
> >
>
> Sure, just scan the string char by char as array elements and replace
> as matches encounter. Like wor
In our previous episode, Hans-Peter Diettrich said:
> > utf8/16 -> ansi are a bit more involved. (since mapping many chars to few,
> > naieve implementation requiring large lookupsets)
>
> A single 256 element array can be used for both directions. In Ansi to
> Unicode the char value is used to i
On 22 August 2012 00:54, Hans-Peter Diettrich wrote:
> IMO string conversion and CRC are mutually exclusive.
Accessing a 100k of files (filenames to be exact) in a UTF-8
environment (Linux), which must all be stored in a UTF-16 string type.
That's lots and lots of encoding conversions right there
On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote:
>
> You still miss the point. Why deal with single characters, by index,
> when working with substrings also covers the single-character use?
>
Why not if it is faster, simpler and more intuitive for beginners?
Martin
___
How many functions have you written that replaces
characters in an UTF-8/UTF-16 string with different size characters?
=
Me adore UTF-8 - a great way of storing unicode text, using non-latin
passwords,.. ! But if we have the RTL string type UTF-8 then we should
also have whole RTL
On 08/21/2012 02:53 PM, Mattias Gaertner wrote:
The LCL uses the same string as the FCL classes.
Yep:
type
TCaption = TTranslateString;
...
TTranslateString = type String;
The FCL uses 8-bit strings ...
Isn't this exactly what I tried to point out ? AFAIK in newer Delphi
TCaption is St
On 08/21/2012 02:53 PM, Mattias Gaertner wrote:
If the FCL moves to another string or starts enforcing an encoding the
LCL has to be adapted.
I believe if "String" becomes a sequence of 16 bit entities instead of 8
bit entities, the LCL needs a really thorough rework.
In the Lazarus form som
On Wed, 22 Aug 2012 10:37:45 +0200
Michael Schnell wrote:
> On 08/21/2012 02:53 PM, Mattias Gaertner wrote:
> > If the FCL moves to another string or starts enforcing an encoding the
> > LCL has to be adapted.
>
> I believe if "String" becomes a sequence of 16 bit entities instead of 8
> bit e
On 08/21/2012 02:53 PM, Graeme Geldenhuys wrote:
http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/
Other than politics, the big news regarding technology seems to be that
Objects (or whatever) seem to get reference counted and thus I
understand ".Free" gets obsolete (like wi
Am 22.08.2012 11:08, schrieb Michael Schnell:
On 08/21/2012 02:53 PM, Graeme Geldenhuys wrote:
http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/
Other than politics, the big news regarding technology seems to be that
Objects (or whatever) seem to get reference counted and th
On 08/22/2012 10:56 AM, Mattias Gaertner wrote:
The UTF-8 optimized functions needs UTF-16 versions. But why do you
mean it needs a "really thorough rework"?
Guesswork :-)
The LCL itself already has some widgetsets using UTF-16.
Yep. So there the conversion needs to be dropped, while with the
On 08/22/2012 11:19 AM, Sven Barth wrote:
Depending on how they implement it this might indeed be an interesting
feature that we could implement (cherry picking Delphi features ^^).
It will be interesting to watch if they might implement other Prism
goodies as well (e.g. parallel loops and f
In our previous episode, Sven Barth said:
> > Objects (or whatever) seem to get reference counted and thus I
> > understand ".Free" gets obsolete (like with Prism). Without assessment -
> > this is a huge move for a native code compiler. If FPC will follow, this
> > sounds like a lot of work.
>
>
Does anybody have an update on where the MIPS port has got to after the
flurry of activity in June?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maill
On 08/22/2012 12:16 PM, Mark Morgan Lloyd wrote:
Does anybody have an update on where the MIPS port has got to after
the flurry of activity in June?
I'm very interested in this as well, as I am planning to do a controller
based on a (future) PIC32 chip, that has a MIPS CPU and lots of internal
On Wed, 22 Aug 2012 11:35:17 +0200
Michael Schnell wrote:
> On 08/22/2012 10:56 AM, Mattias Gaertner wrote:
> > The UTF-8 optimized functions needs UTF-16 versions. But why do you
> > mean it needs a "really thorough rework"?
> Guesswork :-)
> > The LCL itself already has some widgetsets using
Am 22.08.2012 11:44, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
Objects (or whatever) seem to get reference counted and thus I
understand ".Free" gets obsolete (like with Prism). Without assessment -
this is a huge move for a native code compiler. If FPC will follow, t
Am 22.08.2012 12:16, schrieb Mark Morgan Lloyd:
Does anybody have an update on where the MIPS port has got to after the
flurry of activity in June?
I can not say any details (I'm not envolved with the MIPS port), but we
have at least on testsuite running on mipsel-linux with around 150
error
Michael Schnell schrieb:
On 08/21/2012 02:53 PM, Graeme Geldenhuys wrote:
http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/
Other than politics, the big news regarding technology seems to be that
Objects (or whatever) seem to get reference counted and thus I
understand ".
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
utf8/16 -> ansi are a bit more involved. (since mapping many chars to few,
naieve implementation requiring large lookupsets)
A single 256 element array can be used for both directions. In Ansi to
Unicode the char va
Graeme Geldenhuys schrieb:
On 22 August 2012 00:54, Hans-Peter Diettrich wrote:
IMO string conversion and CRC are mutually exclusive.
Accessing a 100k of files (filenames to be exact) in a UTF-8
environment (Linux), which must all be stored in a UTF-16 string type.
Filenames typically deser
Ivanko B schrieb:
Do you mean replacing a character in an UCS-2/UCS-4 string can be
implemented more efficiently than in an UTF-8/UTF-16 string?
Sure, just scan the string char by char as array elements and replace
as matches encounter. Like working with integer arrays.
This applies only to
Ivanko B schrieb:
Why deal with single characters, by index, when working with
substrings also covers the single-character use?
Possibly because it tens times as slower for multiple chars processed.
Not really. Replacing the same amount of bytes can *always* be done
in-pla
Martin Schreiber schrieb:
On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote:
You still miss the point. Why deal with single characters, by index,
when working with substrings also covers the single-character use?
Why not if it is faster, simpler and more intuitive for beginners?
On 08/21/2012 02:53 PM, Graeme Geldenhuys wrote:
I have a program that does exactly that... Loads files to do CRC
checking to see what changed.
Hmm. I feel that reading files takes a lot m,ore CPU time than
converting the stings at the border of the LCL.
This of course does not include convert
Graeme Geldenhuys wrote on Wed, 22 Aug 2012:
Accessing a 100k of files (filenames to be exact) in a UTF-8
environment (Linux), which must all be stored in a UTF-16 string type.
That's lots and lots of encoding conversions right there - in a tight
loop.
It's nevertheless a bad example, because
In our previous episode, Hans-Peter Diettrich said:
> > this is a huge move for a native code compiler. If FPC will follow, this
> > sounds like a lot of work.
>
> I don't see much work here. The code for handling interface references
> exists, it only has to be applied to the new TObject type,
Ignoring ligatures or other foreign languages' constructs and habits
will bite you, sonner or later.
==
To handle this, constantly size growing fixed-char enconings exit.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
this is a huge move for a native code compiler. If FPC will follow, this
sounds like a lot of work.
I don't see much work here. The code for handling interface references
exists, it only has to be applied to the new
Even if you would implement something like the Unix "find" or "ls"
programs, they would be more likely to be limited by I/O and all sorts
of file/directory attribute lookups than code page conversions of file
names.
1) I/O is heavily cached on modern a-lot-of-RAM machines & 2)
conversi
On Wed, 22 Aug 2012 22:30:52 +0500
Ivanko B wrote:
> Even if you would implement something like the Unix "find" or "ls"
> programs, they would be more likely to be limited by I/O and all sorts
> of file/directory attribute lookups than code page conversions of file
> names.
>
> 1) I/
Hi all,
I thought that it was possible to use environment-variables in fpc.cfg.
But I can't find how. Am I wrong?
Joost.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 22 Aug 2012, at 20:23, Joost van der Sluis wrote:
> I thought that it was possible to use environment-variables in fpc.cfg.
> But I can't find how. Am I wrong?
Afaik you can only use them on the command line, via
!envvar_containing_fpc_options
Jonas
___
I saw some activity on this bug, so I thought it would be a good idea to
draw some attention to this message.
On Sat, 2011-12-24 at 16:03 +0100, Joost van der Sluis wrote:
> Hi all,
>
> Seems like it that bug 18702 has nothing to do with my changes to the
> stack-balancing code, and that nested
Hi,
I'm trying to debug a issue I found in a recent 2.6.1 update under
Windows. What is the difference between the branches/fixes_2_6 and
branches/fixes_2_6_0?
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgu
On Wednesday 22 August 2012 15:07:50 Hans-Peter Diettrich wrote:
> Martin Schreiber schrieb:
> > On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote:
> >> You still miss the point. Why deal with single characters, by index,
> >> when working with substrings also covers the single-charac
Also, how do I find out in SubVersion at what revision the 2.6.1 branch started?
G.
On 22 August 2012 20:33, Graeme Geldenhuys wrote:
> Hi,
>
> I'm trying to debug a issue I found in a recent 2.6.1 update under
> Windows. What is the difference between the branches/fixes_2_6 and
> branches/fix
On 22 August 2012 10:19, Sven Barth wrote:
> Depending on how they implement it this might indeed be an interesting
> feature that we could implement (cherry picking Delphi features ^^).
It's already possible, just use IInterface (and TInterfacedObject)
everywhere. :)
--
Regards,
- Graeme -
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber wrote:
> I am not talking about Unicode. I am talking about day by day programming of
> an average programmer where the live is easier with utf-16 than with utf-8.
> Unicode is not done by using pos() instead of character indexes.
> I think everybo
Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho:
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber wrote:
I am not talking about Unicode. I am talking about day by day programming of
an average programmer where the live is easier with utf-16 than with utf-8.
Unicode is not done by u
I worked on it quite some time before leaving for holidays,
and tried to get it working again with current svn trunk...
I haven't yet checked if current svn trunk is
usable for mipsel target.
Currently, using revision 21906
you should be able to do a complete 'make all install' at
fpcsrc level
Daniël Mantione schrieb:
Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho:
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber
wrote:
I am not talking about Unicode. I am talking about day by day
programming of
an average programmer where the live is easier with utf-16 than with
utf-8.
On Wednesday 22 August 2012 21:47:53 Felipe Monteiro de Carvalho wrote:
> On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber
wrote:
> > I am not talking about Unicode. I am talking about day by day programming
> > of an average programmer where the live is easier with utf-16 than with
> > utf-8. U
2012/8/23 Hans-Peter Diettrich :
> Daniël Mantione schrieb:
>
>> Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho:
>>
>>> On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber
>>> wrote:
I am not talking about Unicode. I am talking about day by day
programming of
an average
44 matches
Mail list logo
