On 23/11/14 17:23, Mattias Gaertner wrote:
> I started the thread about ParamStr, which only supports the system
> codepage. I would like to improve it so that it supports
> DefaultSystemCodepage. Or at least add an Unicode version of
> ParamStr.
We need both, as Marco mentioned. The main issue is
On 23/11/14 17:46, Marco van de Voort wrote:
> So now we support changing defaultsystemcodepage formally by endusers? I was
> not made aware of that.
There is the SetMultiByteConversionCodePage() routine in the interface
of the system unit that does exactly that. It's kind of strange to have
such
On Sun, 23 Nov 2014, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
To make things clear:
I meant in the way Mattias proposed, continueing making the default
"string" type utf8 on Windows. Utf8string is fine, but limited.
That basically perpetuates the current h
In our previous episode, Michael Van Canneyt said:
> > To make things clear:
> > I meant in the way Mattias proposed, continueing making the default
> > "string" type utf8 on Windows. Utf8string is fine, but limited.
> >
> > That basically perpetuates the current hack, just slightly more elegant.
>
In our previous episode, Mattias Gaertner said:
> > Let's try to understand first why do you insist on the "UTF-8" in the name ?
> >
> > Maybe "UTF-8 aware" is better, if you really want the UTF-8 in the name.
>
> Maybe there is a misunderstanding. At least I can't follow you here.
>
> I started
On 23/11/14 17:21, Florian Klaempfl wrote:
> Am 23.11.2014 16:50, schrieb Jonas Maebe:
>> When reporting problems, always mention all steps that you took and
>> extra parameters you specified. In this case, the problem only occurs if
>> you use a variant of the -g parameter (which I only know becau
On Sun, 23 Nov 2014, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
It is not, and neither is it "aware". It is only so when you set
defaultsystemcodepage to utf8 and ignore the problems that causes. That is
not intended functionality.
To make things clear:
I
In our previous episode, Michael Van Canneyt said:
> > It is not, and neither is it "aware". It is only so when you set
> > defaultsystemcodepage to utf8 and ignore the problems that causes. That is
> > not intended functionality.
To make things clear:
I meant in the way Mattias proposed, continu
On Sun, 23 Nov 2014 16:31:10 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> That seems wrong, since UTF-8 is not the default on Windows ?
>
> Let's try to understand first why do you insist on the "UTF-8" in the name ?
>
> Maybe "UTF-8 aware" is better, if you really want the UTF-8 in the name
On Sun, 23 Nov 2014, Marco van de Voort wrote:
In our previous episode, Mattias Gaertner said:
doesn't support all characters that can be encoded using UTF-8, ...) or
on all platforms (some platforms don't even support multiple code pages).
Hmm, maybe you have a point there.
It is similar t
Am 23.11.2014 16:50, schrieb Jonas Maebe:
> On 23/11/14 16:31, Joao Morais wrote:
>> Trunk is broken on Darwin i386 since rev 29085 with the following message:
>>
>> =
>> /Applications/Xcode.app/Contents/Developer/usr/bin/make echotime
>> Start now 13:25:24
>> /usr/bin/diff ppc3 ppc386
>> B
In our previous episode, Mattias Gaertner said:
> > doesn't support all characters that can be encoded using UTF-8, ...) or
> > on all platforms (some platforms don't even support multiple code pages).
>
> Hmm, maybe you have a point there.
> It is similar to normal RTL and RTL with CurrencyString
On 23/11/14 16:31, Joao Morais wrote:
> Trunk is broken on Darwin i386 since rev 29085 with the following message:
>
> =
> /Applications/Xcode.app/Contents/Developer/usr/bin/make echotime
> Start now 13:25:24
> /usr/bin/diff ppc3 ppc386
> Binary files ppc3 and ppc386 differ
> make[2]: ***
Hello list!
Trunk is broken on Darwin i386 since rev 29085 with the following message:
=
/Applications/Xcode.app/Contents/Developer/usr/bin/make echotime
Start now 13:25:24
/usr/bin/diff ppc3 ppc386
Binary files ppc3 and ppc386 differ
make[2]: *** [cycle] Error 2
make[1]: *** [compiler_
On Sun, 23 Nov 2014, Mattias Gaertner wrote:
On Sun, 23 Nov 2014 14:26:08 +0100
Jonas Maebe wrote:
On 18/11/14 19:51, Mattias Gaertner wrote:
On Tue, 18 Nov 2014 18:17:25 +0100
Thanks, but there is no UTF-8 RTL.
That's what I thought too a week ago.
FPC 2.7 made an old dream come true. :
On Sun, 23 Nov 2014 14:26:08 +0100
Jonas Maebe wrote:
> On 18/11/14 19:51, Mattias Gaertner wrote:
> > On Tue, 18 Nov 2014 18:17:25 +0100
> >> > Thanks, but there is no UTF-8 RTL.
> > That's what I thought too a week ago.
> > FPC 2.7 made an old dream come true. :)
>
> Nevertheless, please stop
On 18/11/14 19:51, Mattias Gaertner wrote:
> On Tue, 18 Nov 2014 18:17:25 +0100
>> > Thanks, but there is no UTF-8 RTL.
> That's what I thought too a week ago.
> FPC 2.7 made an old dream come true. :)
Nevertheless, please stop calling it the UTF-8 RTL. It will give people
the wrong impression, be
On 11/23/2014 13:28, John Marino wrote:
> On 11/23/2014 13:13, Jonas Maebe wrote:
>> On 23/11/14 12:04, John Marino wrote:
>>
>>> B) rtl/bsd/ostypes: fixed constants S_IRUSR, S_IWUSR, S_IRGRP,
>>> S_IWGRP, S_IXGRP. These were actually incorrect.
>>
>> Not for Darwin at least:
>>
>> Since these a
On 11/23/2014 13:13, Jonas Maebe wrote:
> On 23/11/14 12:04, John Marino wrote:
>
>> B) rtl/bsd/ostypes: fixed constants S_IRUSR, S_IWUSR, S_IRGRP,
>> S_IWGRP, S_IXGRP. These were actually incorrect.
>
> Not for Darwin at least:
>
> Since these are octal numbers, they correspond to the existi
On 23/11/14 12:04, John Marino wrote:
> B) rtl/bsd/ostypes: fixed constants S_IRUSR, S_IWUSR, S_IRGRP,
> S_IWGRP, S_IXGRP. These were actually incorrect.
Not for Darwin at least:
/* Read, write, execute/search by owner */
#define S_IRWXU 700 /* [XSI] RWX mask for owner */
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-fpc/dfly-support-existing-most.diff
http://leaf.drag
Am 19.11.2014 12:32, schrieb Karoly Balogh (Charlie/SGR):
> Hi,
>
> On Wed, 19 Nov 2014, Jonas Maebe wrote:
>
>>> Since the RTL's allocator is documented to align to 16 bytes
>>
>> Where?
>
> Ok, that's actually a very good question. :) I didn't find it anywhere,
> except some earlier ML/forum p
22 matches
Mail list logo
