What is the difference between this and the TUI that comes up when you
start tp. (Same obviously already is part of the fpc source code
distribution.)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 12/29/2013 10:57 AM, Michael Van Canneyt wrote:
We're way past that stage.
Sorry, but IMHO freezing the current (supposedly DXE compatible) state
does not make much sense.
To decently support creating fully portable applications for multiple
OSes, TStrings and its siblings (e.g.
While this behavior is absolutely logical, as a normal procedure could
not use a property in that way.
OTOH just as a courtsey, the _builtin_ procedures inc() and dec() could
be implemented in a way that allows for doing it.
-Michael
___
fpc-devel
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 12/29/2013 10:57 AM, Michael Van Canneyt wrote:
We're way past that stage.
Sorry, but IMHO freezing the current (supposedly DXE compatible) state does
not make much sense.
To decently support creating fully portable applications for
On 12/29/2013 07:26 PM, Hans-Peter Diettrich wrote:
My view on RawByteString:
My view on RawByteString originally had been that it can hold strings of
any encoding and the software that gets such a variable (or function
argument) can detect the actual encoding and behave accordingly. Thus
On 12/30/2013 12:53 PM, Jy V wrote:
A quick note: the new LLVM Delphi compiler forbid the use of
AnsiString and AnsiChar,
Yuck !
Forking the platforms in that incompatible way a really ugly move of
Delphi's. Hopefully fpc (and Lazarus) is able to continue it's path to
real source code
On 01/07/2014 10:41 AM, Michael Van Canneyt wrote:
We know this. But that is stage 2.
Sounds great !
Could you elaborate those plans ?
I fear that releasing stage 1 to the public might introduce another
source of incompatibility.
Explanation: My horror-scenario when trying to convince
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 10:41 AM, Michael Van Canneyt wrote:
We know this. But that is stage 2.
Sounds great !
Could you elaborate those plans ?
There is not much to say.
There will be 2 sets of units:
* Unicode
* AnsiString
for unicode, there is no
On 01/07/2014 11:22 AM, Michael Van Canneyt wrote:
There is not much to say.
There will be 2 sets of units:
* Unicode
* AnsiString
for unicode, there is no problem, since everything is 2 bytes
(ignoring some exotic codepoints here) so string encoding does not apply.
for ansistring,
On 07 Jan 2014, at 11:22, Michael Van Canneyt wrote:
There will be 2 sets of units:
* Unicode
* AnsiString
Or they may be integrated to a large extent. This has not yet been
decided. In any case, creating two separate sets of units is a good
step regardless of what happens eventually,
On 01/07/2014 11:28 AM, Jonas Maebe wrote:
creating two separate sets of units is a good step regardless of what
happens eventually, since we need the functionality of both in any case.
This sounds like State 3 is flickering at the horizon t as well :-) :-)
-Michael
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 11:22 AM, Michael Van Canneyt wrote:
There is not much to say.
There will be 2 sets of units:
* Unicode
* AnsiString
for unicode, there is no problem, since everything is 2 bytes (ignoring
some exotic codepoints here) so string
On 01/07/2014 11:48 AM, Michael Van Canneyt wrote:
TRawByteString is what you need.
AFAI was told by DXE users, this is not true. That is why i did not test
this yet. But as you state otherwise I will check into that.
But anyway this does not help, as long as the RTL (especially TStrings,
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 11:48 AM, Michael Van Canneyt wrote:
TRawByteString is what you need.
AFAI was told by DXE users, this is not true. That is why i did not test this
yet. But as you state otherwise I will check into that.
But anyway this does not
On 01/07/2014 12:27 PM, Michael Van Canneyt wrote:
if you have use-case 1 (which I doubt, since it is not possible even
today) then you're better off using unicodestring anyway.
My argumentation is driven by the experience (some myself, a huge lot by
my colleagues) with doing embedded
Hi,
Large parts of the returning discussions about code page-aware
AnsiStrings are related to the fact that many people don't how they
work. For this reason I've created an overview that explains the rules
that are followed by the RTL/compiler at
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 12:27 PM, Michael Van Canneyt wrote:
if you have use-case 1 (which I doubt, since it is not possible even today)
then you're better off using unicodestring anyway.
My argumentation is driven by the experience (some myself, a huge
This in fact is in the paragraph Old/obsolete sections, but it does
not seem to be mentioned in any current paragraph:
Roadmap of RTL Unicode support with UnicodeString:
- TStrings Not implemented There is no UnicodeString version
of TStrings
- TStringList Not implemented
On 01/07/2014 01:05 PM, Michael Van Canneyt wrote:
This is a mistake. You should use TByteArray for that. Old
pre-unicode Delphi also handles this type.
Of course I do know that this sometimes is recommended, but (with
pre-Unicode Delphi) I don't see any point in not using String, which
is
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 01:05 PM, Michael Van Canneyt wrote:
This is a mistake. You should use TByteArray for that. Old pre-unicode
Delphi also handles this type.
Of course I do know that this sometimes is recommended, but (with pre-Unicode
Delphi) I
On 07 Jan 2014, at 13:11, Michael Schnell wrote:
On 07 Jan 2014, at 12:57, Jonas Maebe wrote:
[ http://wiki.freepascal.org/FPC_Unicode_support ]
This in fact is in the paragraph Old/obsolete sections, but it
does not seem to be mentioned in any current paragraph:
Roadmap of RTL Unicode
On 01/07/2014 01:24 PM, Michael Van Canneyt wrote:
But like I said: Do not expect us to adapt the RTL to suit any
inappropriate use of strings.
Like I said: I don't ! (With the requested behavior this comes for free
as a side-effect.)
But I do expect decent handling of locale based 1 Byte
On 01/07/2014 01:23 PM, Jonas Maebe wrote:
... nor an attempt to address every person's wish list written down
previously on that page.
Yep. And as (pure) Delphi XE compatible behavior (at least in my
opinion) is not what is desirable for a portable language/rtl, while
generally Delphi
Jonas Maebe jonas.ma...@elis.ugent.be hat am 7. Januar 2014 um 12:57
geschrieben:
Hi,
Large parts of the returning discussions about code page-aware
AnsiStrings are related to the fact that many people don't how they
work. For this reason I've created an overview that explains the
On 07 Jan 2014, at 14:13, Mattias Gaertner wrote:
What is this crap:
http://wiki.freepascal.org/FPC_Unicode_support#FPC_Unicode_support
?
It's under the header Old/obsolete sections and as mentioned above,
that's incomplete or wishful thinking. I didn't want to delete any
existing
Michael Van Canneyt schrieb:
If you want a TStrings that can hold strings which may differ in their
encoding (i.e. strings[0] has a different encoding from strings[1]) then
you'll be left in the cold.
Just an idea:
What if FPC adds another encoding, similar to RawByteString ($), but
Jy V schrieb:
A quick note: the new LLVM Delphi compiler forbid the use of AnsiString
and AnsiChar, (declared in the unit AnsiString.pas, you cannot use this
unit anyway),
The compiler supports AnsiStrings, but these are hidden for *mobile*
targets. There exists a hack to enable AnsiString
Jonas Maebe schrieb:
Large parts of the returning discussions about code page-aware
AnsiStrings are related to the fact that many people don't how they
work. For this reason I've created an overview that explains the rules
that are followed by the RTL/compiler at
On Tue, Jan 7, 2014 at 12:57 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote:
For this reason I've created an overview that explains the rules that are
followed by the RTL/compiler at
http://wiki.freepascal.org/FPC_Unicode_support
it is best to save the source code in UTF-8 with a BOM.
Is
On 07 Jan 2014, at 15:54, Jy V wrote:
n Tue, Jan 7, 2014 at 12:57 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote:
For this reason I've created an overview that explains the rules that are
followed by the RTL/compiler at
http://wiki.freepascal.org/FPC_Unicode_support
it is best to save
On 01/07/2014 02:24 PM, Hans-Peter Diettrich wrote:
The compiler supports AnsiStrings, but these are hidden for *mobile*
targets.
Any reason for this strangeness ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 01/07/2014 03:35 PM, Hans-Peter Diettrich wrote:
What if FPC adds another encoding, similar to RawByteString ($),
but without the Delphi quirks? Or simply fix the RawByteString flaws
in the *Ansi* compiler and RTL?
+1 (in fact I elaborated on that in some older Threads here)
1) In a
On 1/7/2014 8:35 AM, Hans-Peter Diettrich wrote:
Sorting (TStringList) eventually should ignore the dynamic encoding,
i.e. work on a strictly binary (byte-by-byte) base.
Why would that be desirable? If you sort a *string* list you'd expect
it to do a string based sort, and more than likely, a
The compiler supports AnsiStrings, but these are hidden for *mobile*
targets.
Any reason for this strangeness ?
They're using the mobile compiler as an opportunity to break backwards
compatibility and push the language in the directions they want to go.
A single, 0-based string type, automatic
On 07 Jan 2014, at 15:35, Hans-Peter Diettrich wrote:
1) In a discussion in the Embarcadero groups it turned out that, in an
assignment of a RawByteString to another AnsiString type, the Delphi compiler
should (but does not) check and eventually convert the string to the static
encoding
On Tue, 7 Jan 2014, Craig Peterson wrote:
The compiler supports AnsiStrings, but these are hidden for *mobile*
targets.
Any reason for this strangeness ?
They're using the mobile compiler as an opportunity to break backwards
compatibility and push the language in the directions they want
On 01/07/2014 04:24 PM, Craig Peterson wrote:
They're using the mobile compiler as an opportunity to break backwards
compatibility and push the language in the directions they want to go.
A single, 0-based string type, automatic reference counting, no
with, etc. Apparently the developers
On 01/07/2014 04:33 PM, Jonas Maebe wrote:
but more regarding descendent classes in existing third party (= user)
source code that override methods using AnsiString parameters.
Automatic type conversion should be able to handle this (as the new type
would preserve and thus dynamically know
Am 07.01.2014 17:00 schrieb Michael Schnell mschn...@lumino.de:
- there have been decent discussions in multiple forums showing that
that classes with automatic reference counting are dangerous
I like the idea of ARC classes. In fact I'm trying to develop an
implementation that is fully
Am 07.01.2014 14:34, schrieb Jonas Maebe:
On 07 Jan 2014, at 14:13, Mattias Gaertner wrote:
What is this crap:
http://wiki.freepascal.org/FPC_Unicode_support#FPC_Unicode_support
?
It's under the header Old/obsolete sections and as mentioned above,
that's incomplete or wishful thinking.
On 07 Jan 2014, at 21:41, Florian Klämpfl wrote:
Am 07.01.2014 14:34, schrieb Jonas Maebe:
It's under the header Old/obsolete sections and as mentioned above,
that's incomplete or wishful thinking. I didn't want to delete any
existing content for now, but yes, what's mentioned there but
Jonas Maebe schrieb:
On 07 Jan 2014, at 15:35, Hans-Peter Diettrich wrote:
2) The stupid conversion to CP_ACP in an assignment *to* an
RawByteString should be dropped. This applies in detail to the
assignment to *function results*.
The conversion does not happen for all assignments, it only
42 matches
Mail list logo
