Am 12.01.2011 07:16, schrieb LacaK:
P.S. I still does not understand, how can things work correctly if LCL
expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does
not strictly follow this (at least in Windows) ?
LCL uses SysToUTF8 and UTF8ToSys if it uses the RTL (and the FCL).
Am 12.01.2011 08:00, schrieb Paul Ishenin:
12.01.2011 13:54, kingbiz...@gmail.com пишет:
Well guys, thanks for replying, the generic method is a very nice
method, I personally didn't know that the FPC support it, very thank you
for that!
FPC does not support it at the moment. I hope it will
12.01.2011 15:20, Sven Barth wrote:
Btw: Do you plan to implement constraints as well?
I thought to implement all what delphi has but I don't know whether I
will be able to.
Best regards,
Paul Ishenin
___
fpc-devel maillist -
Sven Barth wrote / napísal(a):
Am 12.01.2011 07:16, schrieb LacaK:
P.S. I still does not understand, how can things work correctly if LCL
expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does
not strictly follow this (at least in Windows) ?
LCL uses SysToUTF8 and UTF8ToSys
On 01/11/2011 05:50 PM, Hans-Peter Diettrich wrote:
Since the generic Delphi string type can be any Unicode encoding now,
This
From what O read I understand
that the dynamically code string type can hold 1, 2, and 4 byte (maybe
even more) Codes for it's elements (denoted in one
Hello FPC,
Wednesday, January 12, 2011, 9:45:47 AM, you wrote:
L 2. Is it wrong in implementation of TSQLConnectors, which write data
L into record buffer (of TStringField) and do not convert them always into
L UTF-8 ?
Do you set the CHARSET field in your TSQLConnector to UTF-8 ? Do you
define
12.01.2011 14:15, kingbiz...@gmail.com wrote:
Something that I always thought very nice on other languages is the
possible of adding variables inside the codes, I'm very happy using the
FPC but came on my mind, FPC is always getting better and better (I
first saw it like 2 years ago and I am
On Wed, 12 Jan 2011, Paul Ishenin wrote:
12.01.2011 14:15, kingbiz...@gmail.com wrote:
Something that I always thought very nice on other languages is the
possible of adding variables inside the codes, I'm very happy using the
FPC but came on my mind, FPC is always getting better and better
On 01/11/2011 05:19 PM, Hans-Peter Diettrich wrote:
IMO a single encoding, i.e. UTF-8, can cover all cases.
Of course you are right here, but there are some things to be considered:
In Windows (and maybe elsewhere, too) a two-Byte API (e.g. UTF-16) needs
to be used, forcing lots of
Am 12.01.2011 06:29, schrieb Jeppe Johansen:
What do you think about this proposal?
Is the current solution of using procedure variables so bad? Or what
does it lack?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Den 12-01-2011 10:34, Florian Klaempfl skrev:
Am 12.01.2011 06:29, schrieb Jeppe Johansen:
What do you think about this proposal?
Is the current solution of using procedure variables so bad? Or what
does it lack?
___
fpc-devel maillist -
12.01.2011 16:34, Florian Klaempfl пишет:
Is the current solution of using procedure variables so bad? Or what
does it lack?
I see the next benefits from WeakExternal:
1. Less accidental errors. Which procedural variables you need to care
about the initial assignment to nil, then to use
L 2. Is it wrong in implementation of TSQLConnectors, which write data
L into record buffer (of TStringField) and do not convert them always into
L UTF-8 ?
Do you set the CHARSET field in your TSQLConnector to UTF-8 ?
not all connectors supports CharSet property. When I look into sources
only
On Wednesday, 12. January 2011 09.45:47 LacaK wrote:
So where is error ?
1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string
-or-
2. Is it wrong in implementation of TSQLConnectors, which write data
into record buffer (of TStringField) and do not convert them always
On Wed, 12 Jan 2011, Paul Ishenin wrote:
12.01.2011 16:34, Florian Klaempfl пишет:
Is the current solution of using procedure variables so bad? Or what
does it lack?
I see the next benefits from WeakExternal:
1. Less accidental errors. Which procedural variables you need to care about
On Tue, 2011-01-11 at 22:12 +, Martin wrote:
On 11/01/2011 21:39, Joost van der Sluis wrote:
On Tue, 2011-01-11 at 15:59 +, Martin wrote:
On 11/01/2011 09:54, Joost van der Sluis wrote:
There's a new version at that location now. This one has a better
case-sensitivity patch and
This was discussed few times here. Later ppl tired from the endless
discussions and summarised their ideas on this page:
http://wiki.lazarus.freepascal.org/Modernised_Pascal
Nice!
For me, If I can say is most interested:
1. try ... except ... finally ... end;
2. C style IIF operator: l ?
Den 12-01-2011 11:25, michael.vancann...@wisa.be skrev:
That's not correct. You must write all the default handlers.
For each procedure signature you must write a handler. So you must
write more code.
And if you want a correct error message at runtime, then you must
write a handler per
Hello FPC,
Wednesday, January 12, 2011, 11:02:00 AM, you wrote:
L 2. Is it wrong in implementation of TSQLConnectors, which write data
L into record buffer (of TStringField) and do not convert them always into
L UTF-8 ?
Do you set the CHARSET field in your TSQLConnector to UTF-8 ?
L not all
On Wed, Jan 12, 2011 at 11:41, LacaK la...@zoznam.sk wrote:
3. C style comments: /* ... */ (I have never understood why in Pascal was
used (* ... *) )
Because they are much more clear and easy to understand (both for
compiler and for reader). C comments are very-very-very ugly. For
example,
On 12/01/2011 10:39, Joost van der Sluis wrote:
On Tue, 2011-01-11 at 22:12 +, Martin wrote:
The new one crashes, when my test application is run (dwarf and dwarf 3):
I coudn't reproduce, but I had some local changes.
+ ExecuteCommand('-gdb-set case-sensitive off', []);
IT could be
+= does work for variables, even Strings.
AFAIR, there already has been a discussion about += and friends for
properties.
In fact I don't see why the compiler not just generates x.a := x.a + y
from x.a += y before doing any code generating, disregarding what x.a
is. Of course an error
On 12 Jan 2011, at 06:29, Jeppe Johansen wrote:
While trying to find a nice solution for generating interrupt vector
tables on ARM, I found that the usually employed solution is to
generate weak references to symbols, that are initialized to a
single handler. This way an application can
On Wed, 2011-01-12 at 11:23 +, Martin wrote:
On 12/01/2011 10:39, Joost van der Sluis wrote:
That is bad news, because it seems like it that the
final-case-sensitivity solution will be that the case-sensitive flag is
used to control the behavior. But that will then break backwards
On 12/01/2011 11:53, Joost van der Sluis wrote:
Well, the version I use has version 7.2.50.20110107-cvs. But those
version-numbers are a mess. Especially since Fedora in fact uses a fork
of gdb (Archer) but it has the same name. It's this fork I base my work
on. And I don't think you can detect
Hi all,
When working on bug 16545, I needed some reference so I did a 'readelf
-S' on a random .o file created by fpc.
I saw that the offset of the section behind the .note.GNU-stack section
has it's offset increased by one in comparison to the offset of
the .note.GNU-stack section. But the
On Wed, 2011-01-12 at 12:05 +, Martin wrote:
On 12/01/2011 11:53, Joost van der Sluis wrote:
Well, the version I use has version 7.2.50.20110107-cvs. But those
version-numbers are a mess. Especially since Fedora in fact uses a fork
of gdb (Archer) but it has the same name. It's this
On 12 Jan 2011, at 13:12, Joost van der Sluis wrote:
I saw that the offset of the section behind the .note.GNU-stack
section
has it's offset increased by one in comparison to the offset of
the .note.GNU-stack section. But the length of this section is 0, so
there shouldn't be an increase in
On 12/01/2011 12:20, Joost van der Sluis wrote:
What are the chances for that to be fixed in
In what...?
Strange. Some of my mail didn't make it...
What are the chances of the assertation bug being fixed in other
branches of gdb? how soon?
___
On Wed, 2011-01-12 at 13:22 +0100, Jonas Maebe wrote:
On 12 Jan 2011, at 13:12, Joost van der Sluis wrote:
I saw that the offset of the section behind the .note.GNU-stack
section
has it's offset increased by one in comparison to the offset of
the .note.GNU-stack section. But the
Am 12.01.11 11:39, schrieb Joost van der Sluis:
That is bad news, because it seems like it that the
final-case-sensitivity solution will be that the case-sensitive flag is
used to control the behavior. But that will then break backwards
compatibility...
I have osx, freebsd, linux and windows as
On Wed, 2011-01-12 at 12:23 +, Martin wrote:
On 12/01/2011 12:20, Joost van der Sluis wrote:
What are the chances for that to be fixed in
In what...?
Strange. Some of my mail didn't make it...
What are the chances of the assertation bug being fixed in other
branches of gdb?
On 12/01/2011 12:30, Helmut Hartl wrote:
Am 12.01.11 11:39, schrieb Joost van der Sluis:
That is bad news, because it seems like it that the
final-case-sensitivity solution will be that the case-sensitive flag is
used to control the behavior. But that will then break backwards
compatibility...
Resolved in revision 2521. I added your example to the test suite.
Darius
On Jan 12, 2011, at 7:13 AM, Alex Shishkin wrote:
http://bugs.freepascal.org/view.php?id=18471
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Martin Schreiber wrote / napísal(a):
On Wednesday, 12. January 2011 09.45:47 LacaK wrote:
So where is error ?
1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string
-or-
2. Is it wrong in implementation of TSQLConnectors, which write data
into record buffer (of
On Wed, 2011-01-12 at 09:45 +0100, LacaK wrote:
Sven Barth wrote / napísal(a):
Am 12.01.2011 07:16, schrieb LacaK:
P.S. I still does not understand, how can things work correctly if LCL
expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does
not strictly follow this (at
On Wed, 2011-01-12 at 11:02 +0100, LacaK wrote:
Yes, this is not primary question of database side, but db client
library api, which is used by SQLConnector to retrieve data.
For example in ODBC we use SQLGetData in LoadField method to retrieve
data from odbc interface.
And for example in
On Wednesday, 12. January 2011 14.27:14 LacaK wrote:
Yes, sounds logicaly to me.
Then you propose same way for TStringField ? (internaly store as
UnicodeString UTF-16 and also TStringField.Text should return
UnicodeString instead of String ?
It is done so in MSEgui fork of sqldb.
In case you
L but db client library api, which is used by SQLConnector to
L retrieve data.
How an UTF8 SQLConnector can retrieve UTF8 data from a field defined
as binary ?
It cann't .
Here I am speaking about TStringField, which is IMHO designed for
character data, for binary data is designed
On Wed, 2011-01-12 at 14:59 +0100, LacaK wrote:
No. It is mandatory that you send/receive UTF8 to/from GUI LCL
elements.
As LCL elements are using TStringField.Text property, then this property
should return UTF8String, right (not AnsiString in ANSI code page) ?
If yes, then also
kingbiz...@gmail.com wrote:
I come here humbly to ask for a new implementation, the IIF ?:, the IIF
is a shortcut that make the coding a little faster, it works by
returning a true or a false part of a condition, a more detailed
information can be found there: http://en.wikipedia.org/wiki/%3F:
Hello FPC,
Wednesday, January 12, 2011, 2:59:53 PM, you wrote:
L but db client library api, which is used by SQLConnector to
L retrieve data.
How an UTF8 SQLConnector can retrieve UTF8 data from a field defined
as binary ?
L It cann't .
L Here I am speaking about TStringField, which is IMHO
On Wed, Jan 12, 2011 at 21:24, Michael Schnell mschn...@lumino.de wrote:
+= does work for variables, even Strings.
AFAIR, there already has been a discussion about += and friends for
properties.
In fact I don't see why the compiler not just generates x.a := x.a + y
from x.a += y before
On 01/12/2011 04:48 PM, Alexander Klenin wrote:
Blindly replacing a += b with a := a + b may lead to a semantic change
if a is an expression with side-effects.
Nevertheless, I do think that implementing += for properties is a good idea,
but unfortunately FPC developers disagree.
I do see that
On Wed, 12 Jan 2011, Michael Schnell wrote:
On 01/12/2011 04:48 PM, Alexander Klenin wrote:
Blindly replacing a += b with a := a + b may lead to a semantic change
if a is an expression with side-effects.
Nevertheless, I do think that implementing += for properties is a good
idea,
but
On 01/12/2011 05:01 PM, michael.vancann...@wisa.be wrote:
reference counting, which could bite you in the leg.
(as they already have for some people).
I see. _Hidden_ side effects :)
-Michael
___
fpc-devel maillist -
On Thu, Jan 13, 2011 at 00:51, Marc Weustink marc.weust...@cuperus.nl wrote:
Note that there is a tiny little difference between those two.
the ?: operator evaluates either the TruePart or FalsePart while IfThen will
evaluate both parts first.
Exactly. This is why for me IfThen is much less
kingbiz...@gmail.com schrieb:
I come here humbly to ask for a new implementation, the IIF ?:, the
IIF is a shortcut that make the coding a little faster, it works by
returning a true or a false part of a condition, a more detailed
information can be found there:
LacaK schrieb:
...: the new ansistring type has a hidden element size field (in
addition to the reference count, length and codepage), and from what I
can see at page 10 of
http://edn.embarcadero.com/article/images/38980/Delphi_and_Unicode.pdf,
Delphi 2009's unicodestring is simply an
Jeff Wormsley schrieb:
On 01/11/2011 11:10 AM, Hans-Peter Diettrich wrote:
UTF-8 combines an single (byte-based) storage type with lossless
encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look*
easier to handle in user code, but both will fail and require special
code whenever
Den 12-01-2011 12:42, Jonas Maebe skrev:
On 12 Jan 2011, at 06:29, Jeppe Johansen wrote:
While trying to find a nice solution for generating interrupt vector
tables on ARM, I found that the usually employed solution is to
generate weak references to symbols, that are initialized to a single
On 12.01.2011 13:38, Hans-Peter Diettrich wrote:
Jeff Wormsley schrieb:
On 01/11/2011 11:10 AM, Hans-Peter Diettrich wrote:
UTF-8 combines an single (byte-based) storage type with lossless
encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look*
easier to handle in user code, but
In our previous episode, michael.vancann...@wisa.be said:
exactly what the user would expect ?
Most of the time, yes. But there are some subtleties with interfaces and
reference counting, which could bite you in the leg.
(as they already have for some people).
Moreover, that IMHO the c
On 12 Jan 2011, at 19:16, Jeppe Johansen wrote:
Den 12-01-2011 12:42, Jonas Maebe skrev:
How is it normally done in C? At first sight, using the weakexternal
directive to /define/ symbols seems like a wrong approach.
With C it's done using compiler dependent attributes. With gcc you can
In our previous episode, LacaK said:
3. C style comments: /* ... */ (I have never understood why in Pascal
was used (* ... *) )
You probably have to formulate that the other way around. Pascal is older.
___
fpc-devel maillist -
In our previous episode, Hans-Peter Diettrich said:
memory management and the occasional code page conversion (and since
this may reduce the number of code page conversions when working with
non-native strings, it can also be a performance win).
IMO a single encoding, i.e. UTF-8, can
I recently startet getting the below error = 2.4.2 and trunk, so
probably not fpc.
But The particular code in Lazarus hasn't changed (from what it was
before I start getting the error)
If I step into it, then fpc_ansistr_concat get's 2 perfectly valid
strings (as far as I can see). Tha code
On 12/01/2011 21:15, Martin wrote:
I recently startet getting the below error = 2.4.2 and trunk, so
probably not fpc.
Solved
the talk about it effect.
I had an out of range memory access in completely unrelated code.
___
fpc-devel maillist -
In our previous episode, Sven Barth said:
legacy code can be broken by (eventually) required changes to set of
char, sizeof(char) and PChar, sizeof(string) as opposed to
Length(string), upper/lower conversion, and many more not so obvious
consequences.
I don't believe that PChar will be
Den 12-01-2011 20:47, Jonas Maebe skrev:
The weakexternal directive already defines a symbol, it will exist at
runtime, but it might be nil.
What I meant is that there is a semantic difference between referencing a
symbol that may or may not be defined somewhere else (regardless of whether a
On 12 Jan 2011, at 22:54, Jeppe Johansen wrote:
Den 12-01-2011 20:47, Jonas Maebe skrev:
I can't immediately think of a good syntax to directly define MyIRQHandler
as a weak symbol with the address of NoHandler as default value. Maybe this,
although I'm not 100% happy with it either:
Den 12-01-2011 23:18, Jonas Maebe skrev:
On 12 Jan 2011, at 22:54, Jeppe Johansen wrote:
Den 12-01-2011 20:47, Jonas Maebe skrev:
I can't immediately think of a good syntax to directly define MyIRQHandler as a
weak symbol with the address of NoHandler as default value. Maybe this,
although
Has dwarf 2 changed ?
with trunk ( I updated from a few month back, to today), I no longer get
the classname of an exception (stabs is fine, but dwarf now fails)
TCmdLineDebugger.SendCmdLn -data-evaluate-expression
^^shortstring(^POINTER($eax)^+12)^^
TCmdLineDebugger.ReadLn
On Wed, Jan 12, 2011 at 7:38 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Until now most users, including you, most probably don't
realize that difference between phyiscal and logical characters, and assume
that sizeof(char) always is 1
Oh, I'm aware of it. But to date, I haven't had
Michael Schnell schrieb:
+= does work for variables, even Strings.
AFAIR, there already has been a discussion about += and friends for
properties.
In fact I don't see why the compiler not just generates x.a := x.a + y
from x.a += y before doing any code generating,
This would result in
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
memory management and the occasional code page conversion (and since
this may reduce the number of code page conversions when working with
non-native strings, it can also be a performance win).
IMO a single
On Wed, 2011-01-12 at 23:52 +, Martin wrote:
Has dwarf 2 changed ?
Yes
with trunk ( I updated from a few month back, to today), I no longer get
the classname of an exception (stabs is fine, but dwarf now fails)
Well, passing variables to procedures by reference has different
67 matches
Mail list logo
