Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2010-03

LRS files

6 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Flávio Etrusco

Hello,

what is needed to replace .lrs files with .res ones, for e.g. IDE images (images folder)?
If that's not desirable, shouldn't the .lrs files force a codepage in its "header"? Otherwise we get spurious changes when the files are generated in different systems...

Best regards,
Fl?vio

Reply by email

Mattias Gaertner
to Flávio Etrusco
[...] If that's not desirable, shouldn't the .lrs files force a codepage in its "header"? Otherwise we get spurious changes when the files are generated in different systems...

lrs files are plain ASCII. They are the same in any 8bit codepage.

What "spurious changes"?

Mattias

Reply by email

Flávio Etrusco
to Mattias Gaertner
Mattias Gaertner wrote 13 lines
On Sun, 28 Mar 2010 16:34:42 -0300 Fl?vio Etrusco wrote: >[...] > If that's not desirable, shouldn't the .lrs files force a codepage in > its "header"? Otherwise we get spurious changes when the files are > generated in different systems... lrs files are plain ASCII. They are the same in any 8bit codepage. What "spurious changes"? Mattias

Do you mean "plain ASCII" or "plain text"? AFAICS they are generate with sytem's default codepage, which for most modern Linux systems is UTF8, different to Windows' native/ANSI codepages. At least this is how a I interpreted the spurious changes that were generated when I added images to the IDE and needed to (re)generate the .lrs files.

Best regards,
Fl?vio

Reply by email

Mattias Gaertner
to Flávio Etrusco
Show quoted text 21 lines
On Sun, Mar 28, 2010 at 5:08 PM, Mattias Gaertner wrote: > On Sun, 28 Mar 2010 16:34:42 -0300 > Fl?vio Etrusco wrote: > >>[...] >> If that's not desirable, shouldn't the .lrs files force a codepage in >> its "header"? Otherwise we get spurious changes when the files are >> generated in different systems... > > lrs files are plain ASCII. They are the same in any 8bit codepage. > > What "spurious changes"? > > Mattias Do you mean "plain ASCII" or "plain text"? AFAICS they are generate with sytem's default codepage, which for most modern Linux systems is UTF8, different to Windows' native/ANSI codepages. At least this is how a I interpreted the spurious changes that were generated when I added images to the IDE and needed to (re)generate the .lrs files.

The lrs only use characters from #10,#13,#32..#126. The line endings are different, but this is handled by a good version control system automatically.

Some months ago the lrs comment was translated, which created differences. Maybe you checked with an old version?

Mattias

Reply by email

Flávio Etrusco
to Mattias Gaertner
Mattias Gaertner wrote 34 lines
On Mon, 29 Mar 2010 02:03:08 -0300 Fl?vio Etrusco wrote: > On Sun, Mar 28, 2010 at 5:08 PM, Mattias Gaertner > wrote: > > On Sun, 28 Mar 2010 16:34:42 -0300 > > Fl?vio Etrusco wrote: > > > >>[...] > >> If that's not desirable, shouldn't the .lrs files force a codepage in > >> its "header"? Otherwise we get spurious changes when the files are > >> generated in different systems... > > > > lrs files are plain ASCII. They are the same in any 8bit codepage. > > > > What "spurious changes"? > > > > Mattias > > Do you mean "plain ASCII" or "plain text"? AFAICS they are generate > with sytem's default codepage, which for most modern Linux systems is > UTF8, different to Windows' native/ANSI codepages. At least this is > how a I interpreted the spurious changes that were generated when I > added images to the IDE and needed to (re)generate the .lrs files. The lrs only use characters from #10,#13,#32..#126. The line endings are different, but this is handled by a good version control system automatically. Some months ago the lrs comment was translated, which created differences. Maybe you checked with an old version? Mattias

I don't know. How do you explain these changes:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/images/bookmark.lrs?root=lazarus&r1=24264&r2=24263&pathrev=24264

Best regards,
Fl?vio

Reply by email

Mattias Gaertner
to Flávio Etrusco
Show quoted text 39 lines
On Mon, Mar 29, 2010 at 4:39 AM, Mattias Gaertner wrote: > On Mon, 29 Mar 2010 02:03:08 -0300 > Fl?vio Etrusco wrote: > >> On Sun, Mar 28, 2010 at 5:08 PM, Mattias Gaertner >> wrote: >> > On Sun, 28 Mar 2010 16:34:42 -0300 >> > Fl?vio Etrusco wrote: >> > >> >>[...] >> >> If that's not desirable, shouldn't the .lrs files force a codepage in >> >> its "header"? Otherwise we get spurious changes when the files are >> >> generated in different systems... >> > >> > lrs files are plain ASCII. They are the same in any 8bit codepage. >> > >> > What "spurious changes"? >> > >> > Mattias >> >> Do you mean "plain ASCII" or "plain text"? AFAICS they are generate >> with sytem's default codepage, which for most modern Linux systems is >> UTF8, different to Windows' native/ANSI codepages. At least this is >> how a I interpreted the spurious changes that were generated when I >> added images to the IDE and needed to (re)generate the .lrs files. > > The lrs only use characters from #10,#13,#32..#126. > The line endings are different, but this is handled by a good version > control system automatically. > > Some months ago the lrs comment was translated, which created > differences. Maybe you checked with an old version? > > Mattias > I don't know. How do you explain these changes: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/images/bookmark.lrs?root=lazarus&r1=24264&r2=24263&pathrev=24264

The special character #127 is now written as constant instead of string. This was changed a long time ago, but apparently there are still some even older lrs files.
They need to be updated.

Mattias

Reply by email