On 26.11.2014 00:48, Gennady Agranov wrote:
Hi,
When can regular FPC user expect 2.7.1 to graduate and be marked as
stable release?
Somewhere in Spring - like 2.6.4?
We are currently in branch preparation phase of 2.8. Once it's branched
it will be roughly half a year till the release (don't
On 25.11.2014 23:55, luiz americo pereira camara wrote:
But fpexprpars is not recompiled
Is there any better way to compile and test changes in the RTL?
Just a slight correction: everything in "packages" is not "RTL" (except
maybe the "rtl-*" packages). The RTL itself resides in directory "rt
On 11/25/2014 6:48 PM, Gennady Agranov wrote:
Hi,
When can regular FPC user expect 2.7.1 to graduate and be marked as stable
release?
it won't... if i understand the fpc versioning methods, it will be 2.7.2 or
2.8.0 ;)
Somewhere in Spring - like 2.6.4?
we used to have a well used and sli
Marco van de Voort wrote:
In our previous episode, Pierre Free Pascal said:
I am surprised,
for me, as French, I always believed that
the French thousand separator is simply a space,
what else should it be?
A shift space. In utf8 that takes two bytes.
How does that look when hand-written on
Hi,
When can regular FPC user expect 2.7.1 to graduate and be marked as stable
release?
Somewhere in Spring - like 2.6.4?
Thanks,
Gennady
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc
On 11/25/2014 07:36 PM, Hans-Peter Diettrich wrote:
>
> I'd assume that national separators are part of the according
> codepage, but is that always true?
Of the OS/window manager actually. You are of course right in that there
are a certain set of separators that can be used, but the exact
separa
On Tue, 25 Nov 2014 19:36:45 +0100
Hans-Peter Diettrich wrote:
>[...]
> > Maybe a widechar is sufficient ? Making it a string is more invasive
> > than making it a widechar.
>
> Are all possible separators members of the Unicode BMP?
I found 12 thousand-separators and they are all in the BMP.
Hi,
Until now, when i make changes to RTL units in trunk, i take two pathes to
test and compile:
1) If the unit is self contained, i go to source directory and compile
directly
2) If the unit is a dependency of other RTL parts, i rebuild all the
compiler and RTL
I tried improve this cycle.
So a
Am 25.11.2014 17:51 schrieb "Michael Van Canneyt" :
>
>
>
> On Tue, 25 Nov 2014, Mattias Gaertner wrote:
>
>> Hi,
>>
>> The ThousandSeparator is "char" and supports only 1 byte characters.
>> For example French and Russian need more.
>> Are there any plans to extend it?
>
>
> Plans: yes. Time: no.
Mattias Gaertner schrieb:
Does concatenating a string and a WideChar create a UnicodeString? Can
this become a problem?
Concatenation requires 2 strings, so everything depends on the concrete
code. Regardless of eventual compiler magics, something like this will
happen:
var c: WideChar; s,
Michael Van Canneyt schrieb:
The ThousandSeparator is "char" and supports only 1 byte characters.
For example French and Russian need more.
Are there any plans to extend it?
Plans: yes. Time: no.
Maybe a widechar is sufficient ? Making it a string is more invasive
than making it a widechar.
In our previous episode, Michael Van Canneyt said:
> > The ThousandSeparator is "char" and supports only 1 byte characters.
> > For example French and Russian need more.
> > Are there any plans to extend it?
>
> Plans: yes. Time: no.
>
> Maybe a widechar is sufficient ?
If you start changing th
On Tue, 25 Nov 2014 17:51:41 +0100 (CET)
Michael Van Canneyt wrote:
>
>
> On Tue, 25 Nov 2014, Mattias Gaertner wrote:
>
> > Hi,
> >
> > The ThousandSeparator is "char" and supports only 1 byte characters.
> > For example French and Russian need more.
> > Are there any plans to extend it?
>
>
On Tue, 25 Nov 2014, Mattias Gaertner wrote:
Hi,
The ThousandSeparator is "char" and supports only 1 byte characters.
For example French and Russian need more.
Are there any plans to extend it?
Plans: yes. Time: no.
Maybe a widechar is sufficient ?
Making it a string is more invasive than
2014-11-25 17:21 GMT+01:00 Pierre Free Pascal :
> I am surprised,
> for me, as French, I always believed that
> the French thousand separator is simply a space,
> what else should it be?
>
Not quite. It looks like a space, but:
- you wouldn't like to see 2 000 € printed as: 2
000 € would you?
-
In our previous episode, Pierre Free Pascal said:
> I am surprised,
> for me, as French, I always believed that
> the French thousand separator is simply a space,
> what else should it be?
A shift space. In utf8 that takes two bytes.
___
fpc-devel mailli
As a Russian, I'm equally surprised. We don't normally separate
thousands at all.
On 11/25/2014 11:21 AM, Pierre Free Pascal wrote:
I am surprised,
for me, as French, I always believed that
the French thousand separator is simply a space,
what else should it be?
Pierre Muller
from Strasbourg,
I am surprised,
for me, as French, I always believed that
the French thousand separator is simply a space,
what else should it be?
Pierre Muller
from Strasbourg, France
> -Message d'origine-
> De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
> boun...@lists.freepascal.org] D
Hi,
The ThousandSeparator is "char" and supports only 1 byte characters.
For example French and Russian need more.
Are there any plans to extend it?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/m
On Tue, 25 Nov 2014, Chris Dryburgh wrote:
On 25/11/14 03:47 AM, Michael Van Canneyt wrote:
On Mon, 24 Nov 2014, Chris Dryburgh wrote:
Found this bug report from 2010 on using implicit transactions in
PostgreSQL. As far as I can tell nothing has happened since. Using the
TSQLTransaction.
On 25/11/14 03:47 AM, Michael Van Canneyt wrote:
On Mon, 24 Nov 2014, Chris Dryburgh wrote:
Found this bug report from 2010 on using implicit transactions in
PostgreSQL. As far as I can tell nothing has happened since. Using
the TSQLTransaction.Action setting looks like a good approach to
i
In our previous episode, Jonas Maebe said:
> > (and
> > not making the 2.8.0 release) so that's what is concerning me.
>
> Committing large patches right before forking a stable branch is
> generally not done in any case (it's kind of a contraction in terms).
> At first sight there is nothing
On 11/25/2014 14:03, Jonas Maebe wrote:
>
> On 25 Nov 2014, at 13:52, John Marino wrote:
>
>> I see a lot of activity in the trunk thus I'm worried about bitrot (and
>> not making the 2.8.0 release) so that's what is concerning me.
>
> Committing large patches right before forking a stable branc
On 25 Nov 2014, at 13:52, John Marino wrote:
I see a lot of activity in the trunk thus I'm worried about bitrot
(and
not making the 2.8.0 release) so that's what is concerning me.
Committing large patches right before forking a stable branch is
generally not done in any case (it's kind of
On 11/25/2014 13:17, Jonas Maebe wrote:
>
> On 25 Nov 2014, at 12:29, John Marino wrote:
>
>> I am wondering what the next step is. Are these patch sets currently
>> under review? Is anything more needed from me?
>
> It's best to open a bug report at http://bugs.freepascal.org and attach
> the
On 25 Nov 2014, at 12:29, John Marino wrote:
I am wondering what the next step is. Are these patch sets currently
under review? Is anything more needed from me?
It's best to open a bug report at http://bugs.freepascal.org and
attach them there.
Jonas
___
On 11/23/2014 12:04, John Marino wrote:
> Hello,
> I've applied the DragonFly BSD support to the trunk. The 2.6.4 compiler
> can bootstrap it and it builds itself and helloworld.
>
> I've split it into 3 patch sets for the convenience of the committer:
> http://leaf.dragonflybsd.org/~marino/df-fp
On 24/11/14 23:50, Gennady Agranov wrote:
suse-32 builds fine though ...
Anything obvious I have missed?
Thanks,
Gennady
Start compiling package gdbint for target x86_64-linux.
File libgdb.a not found
Compiling gdbint/src/gdbint.pp
Compiling gdbint/src/gdbcon.pp
Compili
On Mon, 24 Nov 2014, Chris Dryburgh wrote:
Found this bug report from 2010 on using implicit transactions in PostgreSQL.
As far as I can tell nothing has happened since. Using the
TSQLTransaction.Action setting looks like a good approach to implementing
implicit transactions. It would mean w
29 matches
Mail list logo
