On Thursday 24 September 2015 09:52:34 Jonas Maebe wrote:
> Martin Schreiber wrote:
>
> >>> Another question, it looks to me that -Fcutf8 does not work like
> >>> {$codepage utf8} for string constants. Is this intend?
> >>
> >> I think they should have the same effect.
> >
> > Another bug?
>
> If
On 24.09.2015 09:22, Graeme Geldenhuys wrote:
> On 2015-09-24 09:09, Martin Schreiber wrote:
>> It is an advantage to have pure ASCII files for such data.
>
>
> Escaped text seems optional, but the UTF-8 encoding seem recommended.
> Using non-escaped Unicode text is faster to parse and easier to
On 2015-09-24 09:09, Martin Schreiber wrote:
> It is an advantage to have pure ASCII files for such data.
Escaped text seems optional, but the UTF-8 encoding seem recommended.
Using non-escaped Unicode text is faster to parse and easier to read [by
a human] - and from my understanding of the RFC
On Thursday 24 September 2015 09:46:06 Michael Van Canneyt wrote:
> On Thu, 24 Sep 2015, Martin Schreiber wrote:
> > On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote:
> >>> Should I make a bug report?
> >>
> >> There is already a (very old) bug report for that.
> >
> > I meant a bug report
On Thursday 24 September 2015 09:59:49 Graeme Geldenhuys wrote:
> On 2015-09-24 08:14, Martin Schreiber wrote:
> >> > What did you expect to see ?
> >
> > "
> > {"version":1,"strings":[
> > {"hash":7200948,"name":"json.a","value":"a\u00E4\u00C4"}
> > ]}
> > "
>
> I would have expected the same as t
On 2015-09-24 08:14, Martin Schreiber wrote:
>> > What did you expect to see ?
>> >
> "
> {"version":1,"strings":[
> {"hash":7200948,"name":"json.a","value":"a\u00E4\u00C4"}
> ]}
> "
>
I would have expected the same as the original.
"
{"version":1,"strings":[
{"hash":7200948,"name":"json.a","val
Martin Schreiber wrote:
On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote:
There are several more, including lack of support for non-ansi encoded
file names and most classes that (still) exist only in ansistring form.
You can of course create replacements for all of that, but then again,
On Thu, 24 Sep 2015, Martin Schreiber wrote:
On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote:
Should I make a bug report?
There is already a (very old) bug report for that.
I meant a bug report for the unusual json format.
Please do.
Michael.
___
On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote:
>
>
> > Should I make a bug report?
>
> There is already a (very old) bug report for that.
>
I meant a bug report for the unusual json format.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.f
On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote:
>
> There are several more, including lack of support for non-ansi encoded
> file names and most classes that (still) exist only in ansistring form.
> You can of course create replacements for all of that, but then again,
> you could also im
Martin Schreiber wrote:
On Thursday 24 September 2015 08:42:11 Jonas Maebe wrote:
I have no idea. I only looked at the compiler/cresstr.pas unit and saw
that the codepage of resource strings stored in the object code is set
to the source file code page. I don't even know how the .rst/.rsj files
On Thursday 24 September 2015 09:21:01 Mattias Gaertner wrote:
> On Thu, 24 Sep 2015 09:10:06 +0200
>
> Martin Schreiber wrote:
> >[...]
> > Another question, it looks to me that -Fcutf8 does not work like
> > {$codepage utf8} for string constants.
>
> What do you mean?
>
If I looked right, {$code
On Thu, 24 Sep 2015 09:10:06 +0200
Martin Schreiber wrote:
>[...]
> Another question, it looks to me that -Fcutf8 does not work like {$codepage
> utf8} for string constants.
What do you mean?
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freep
On Thursday 24 September 2015 09:00:47 Michael Van Canneyt wrote:
> > produces the file json.rsj
> > "
> > {"version":1,"strings":[
> > {"hash":7200948,"name":"json.a","value":"a\u00C3\u00A4\u00C3\u0084"}
> > ]}
> > "
> > Is this intended? How can translation tools know that the Unicode points
> >
On Thursday 24 September 2015 08:42:11 Jonas Maebe wrote:
> Martin Schreiber wrote:
> > FPC fixes_3_0 with the program
> > "
> > program json;
> > {$codepage utf8}
> > {$ifdef FPC}{$mode objfpc}{$h+}{$endif}
> > {$ifdef mswindows}{$apptype console}{$endif}
> > uses
> > {$ifdef FPC}{$ifdef unix}ct
On Thu, 24 Sep 2015, Martin Schreiber wrote:
On Monday 21 September 2015 11:06:53 Jonas Maebe wrote:
Martin Schreiber wrote on Sun, 20 Sep 2015:
Are there any changes? How resourcestrings are encoded?
Resourcestrings are stored using the same code page as constant
ansistrings in the source
On 2015-09-24 06:55, Martin Schreiber wrote:
> Is this intended? How can translation tools know that the Unicode points must
> be interpreted as utf-8 code units in this case?
I would guess you found a bug or the implementation is incomplete - but
then FPC 3.0 is in rc phase as far as I know.
I
Martin Schreiber wrote:
FPC fixes_3_0 with the program
"
program json;
{$codepage utf8}
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
{$ifdef FPC}{$ifdef unix}cthreads,cwstring,{$endif}{$endif}
sysutils;
resourcestring
a = 'aäÄ';
begin
end.
"
prod
On Monday 21 September 2015 11:06:53 Jonas Maebe wrote:
> Martin Schreiber wrote on Sun, 20 Sep 2015:
> > Are there any changes? How resourcestrings are encoded?
>
> Resourcestrings are stored using the same code page as constant
> ansistrings in the source file in which they are defined (i.e.,
> a
Martin Schreiber wrote on Sun, 20 Sep 2015:
Are there any changes? How resourcestrings are encoded?
Resourcestrings are stored using the same code page as constant
ansistrings in the source file in which they are defined (i.e.,
according to the rules for constant ansistrings described on
On Sun, 20 Sep 2015, Martin Schreiber wrote:
Hi,
I did not find resourcestrings mentioned here:
http://wiki.freepascal.org/User_Changes_3.0
http://wiki.freepascal.org/FPC_Unicode_support
There encoding is not mentioned here:
http://www.freepascal.org/docs-html/prog/progse39.html#x228-2410009.
21 matches
Mail list logo
