On 10/04/2011 01:02 PM, Hans-Peter Diettrich wrote:
I wonder when Lazarus will be able to follow and use this string type
for the complete library.
The LCL will use one unique encoding, most probably UTF-8 as the only
losless Unicode representation. This means that strings with different
e
Michael Schnell schrieb:
On 10/04/2011 10:59 AM, Michael Van Canneyt wrote:
Yes. Each string will have a codepage identifier associated with it.
if, during an assign operation, a difference exists, a conversion will
occur.
(there are of course some exceptions)
GREAT !
Not really :-(
I wo
On 10/04/2011 11:59 AM, Sven Barth wrote:
The earliest point is when the next big release after 2.6 is released
(note: I don't mean 2.6.x here, more a 2.8). As 2.6 is currently
prepared you can estimate how long that will take.
I see. ;-)
Unfortunately Delphi is way ahead on this behalf, b
Am 04.10.2011 11:19, schrieb Michael Schnell:
On 10/04/2011 10:59 AM, Michael Van Canneyt wrote:
Yes. Each string will have a codepage identifier associated with it.
if, during an assign operation, a difference exists, a conversion will
occur.
(there are of course some exceptions)
GREAT !
I
On 10/04/2011 10:59 AM, Michael Van Canneyt wrote:
Yes. Each string will have a codepage identifier associated with it.
if, during an assign operation, a difference exists, a conversion will
occur.
(there are of course some exceptions)
GREAT !
I wonder when Lazarus will be able to follow an
On Tue, 4 Oct 2011, Michael Schnell wrote:
On 10/03/2011 11:41 AM, michael.vancann...@wisa.be wrote:
Currently, hard work is being put in the unicode string and codepage string
routines in the RTL.
Do I understand correctly that this is the "New String" string handling (to
be optionally,
On 10/03/2011 11:41 AM, michael.vancann...@wisa.be wrote:
Currently, hard work is being put in the unicode string and codepage
string
routines in the RTL.
Do I understand correctly that this is the "New String" string handling
(to be optionally, by default or exclusively used) ?
Do I und
On Tue, 4 Oct 2011, Alexander Klenin wrote:
On Tue, Oct 4, 2011 at 08:48, Michael Van Canneyt
wrote:
There is, again, a continuum between careful development and stangation.
While acknowledging great work that FPC team has done on the former,
I'd venture to say that is came uncomfortably clo
On Tue, Oct 4, 2011 at 08:48, Michael Van Canneyt
wrote:
>> There is, again, a continuum between careful development and stangation.
>> While acknowledging great work that FPC team has done on the former,
>> I'd venture to say that is came uncomfortably close to the latter.
>
> I'd venture to disa
On Tue, 4 Oct 2011, Alexander Klenin wrote:
On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl wrote:
Anyway, what I suggest is IMO a good compromise and should satisfy both
sides --
Felipe can continue development of his packages unobstucted,
while the quality of FPC will not suffer.
That's wh
On 03 Oct 2011, at 16:06, Alexander Klenin wrote:
There is, again, a continuum between careful development and
stangation.
While acknowledging great work that FPC team has done on the former,
I'd venture to say that is came uncomfortably close to the latter.
I think http://wiki.freepascal.o
On Tue, Oct 4, 2011 at 00:49, Paul Ishenin wrote:
> 03.10.2011 21:32, Alexander Klenin wrote:
>>
>> I'd say there is a continuum between those extremes, and (unfortunately)
>> from my point of vew, FPC review is sometimes rather close to the former.
>> I have been burned by this myself.
>
> When?
Am 03.10.2011 16:06, schrieb Alexander Klenin:
On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl wrote:
Anyway, what I suggest is IMO a good compromise and should satisfy both
sides --
Felipe can continue development of his packages unobstucted,
while the quality of FPC will not suffer.
That's wh
On Tue, Oct 4, 2011 at 01:01, Felipe Monteiro de Carvalho
wrote:
>
> I think we should agree to disagree: Let's delete fpvectorial from
> FPC, I'll export it into lazarus/components/fpvectorial and we move
> our separate ways.
+1
Among other things, this will simplify management of TAChart's
fpve
On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl wrote:
>> Anyway, what I suggest is IMO a good compromise and should satisfy both
>> sides --
>> Felipe can continue development of his packages unobstucted,
>> while the quality of FPC will not suffer.
>
> That's why I proposed a branch and that's wha
On Mon, Oct 3, 2011 at 3:42 PM, Florian Klämpfl wrote:
> That's why I proposed a branch and that's what branches are for.
So far we had two against and one maybe a small part of it ...
seriously I think it is unrealistic to expect that if there is
virtually no support from fpc developers for the
On 03 Oct 2011, at 15:49, Paul Ishenin wrote:
As I remember there is a package "lnet" which can be somehow
installed via internet. I don't remember the details but I believe
I've seen this a half year ago or so. Why fpspreadsheet and
fpverctorial together with new utf8 package can't be fol
On Mon, Oct 3, 2011 at 3:49 PM, Paul Ishenin wrote:
> As I remember there is a package "lnet" which can be somehow installed via
> internet. I don't remember the details but I believe I've seen this a half
> year ago or so. Why fpspreadsheet and fpverctorial together with new utf8
> package can't
03.10.2011 21:32, Alexander Klenin wrote:
I'd say there is a continuum between those extremes, and (unfortunately)
from my point of vew, FPC review is sometimes rather close to the former.
I have been burned by this myself.
When?
Anyway, what I suggest is IMO a good compromise and should satisf
Am 03.10.2011 15:32, schrieb Alexander Klenin:
On Mon, Oct 3, 2011 at 22:40, Florian Klämpfl wrote:
Am 03.10.2011 13:23, schrieb Alexander Klenin:
This way, you can develop much faster, without the need to fight for
your changes,
Others call this fighting "review" and consider it as importa
On Mon, Oct 3, 2011 at 22:40, Florian Klämpfl wrote:
> Am 03.10.2011 13:23, schrieb Alexander Klenin:
>>
>> This way, you can develop much faster, without the need to fight for
>> your changes,
>
> Others call this fighting "review" and consider it as important part to
> improve software quality.
On 3-10-2011 13:45, Felipe Monteiro de Carvalho wrote:
Also not a solution, because then fpvectorial and fpspreadsheet would
not be able to compile in other RTL modes.
What? You mean you are seeking the solution upstream? Seems
the design of those units is lacking.
_
On Mon, Oct 3, 2011 at 12:40 PM, Marco van de Voort wrote:
> True, because we never planned to have support for such utf8 only libraries
> in the first place.
...
> Then factor out the relevant LCL independent stuff to an external project.
>
> If it is non visual, it doesn't automatically mean it
Am 03.10.2011 13:23, schrieb Alexander Klenin:
This way, you can develop much faster, without the need to fight for
your changes,
Others call this fighting "review" and consider it as important part to
improve software quality.
___
fpc-devel mailli
On Mon, Oct 3, 2011 at 21:13, Felipe Monteiro de Carvalho
wrote:
> On Mon, Oct 3, 2011 at 11:38 AM, Marco van de Voort wrote:
>> These things are related to Lazarus UTF8
>> decision and thus logically belong in Lazarus,
>
> Not really. One can write a non-visual library which uses utf8string
> as
On Mon, 3 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Mon, Oct 3, 2011 at 11:41 AM, wrote:
Please do not include this package yet.
I'd rather find a consensus on this now then to postpone yet again. I
have patches to merge about this and I have some time now which is
something which c
In our previous episode, Felipe Monteiro de Carvalho said:
>
> Not really. One can write a non-visual library which uses utf8string
> as its main string type, why not? But the RTL is not adequate for
> utf8string projects
True, because we never planned to have support for such utf8 only libraries
Am 03.10.2011 12:20, schrieb Felipe Monteiro de Carvalho:
On Mon, Oct 3, 2011 at 11:41 AM, wrote:
Please do not include this package yet.
I'd rather find a consensus on this now then to postpone yet again. I
have patches to merge about this and I have some time now which is
something which ca
On Mon, Oct 3, 2011 at 11:41 AM, wrote:
> Please do not include this package yet.
I'd rather find a consensus on this now then to postpone yet again. I
have patches to merge about this and I have some time now which is
something which can disappear at any moment.
> So I suggest you wait till th
On Mon, Oct 3, 2011 at 11:38 AM, Marco van de Voort wrote:
> These things are related to Lazarus UTF8
> decision and thus logically belong in Lazarus,
Not really. One can write a non-visual library which uses utf8string
as its main string type, why not? But the RTL is not adequate for
utf8string
On Mon, 3 Oct 2011, Felipe Monteiro de Carvalho wrote:
Hello,
I would like to add a new package to Free Pascal into the directory
packages/fputf8 which will provide classes and routines for UTF-8
applications. It might grow to include things like:
* full unicode tables and conversion routine
In our previous episode, Felipe Monteiro de Carvalho said:
> I would like to add a new package to Free Pascal into the directory
> packages/fputf8 which will provide classes and routines for UTF-8
> applications. It might grow to include things like:
>
> * full unicode tables and conversion routin
Hello,
I would like to add a new package to Free Pascal into the directory
packages/fputf8 which will provide classes and routines for UTF-8
applications. It might grow to include things like:
* full unicode tables and conversion routines
* Equivalents of RTL classes which are not adequate for UT
33 matches
Mail list logo
