On Sat, Jan 21, 2006 at 07:07:39PM +0100, Olle Raab wrote:
> 06-01-19 13.05, skrev Jonas Maebe följande:
>
> >
> > On 19 jan 2006, at 11:51, L505 wrote:
> >
> >> From the FPC ReadLn sources I was under the impression that the Mac
> >> used #13 for line
> >> feeds and unix used #10 for line feeds
On 21 Jan 2006, at 19:07, Olle Raab wrote:
But one should be aware of that a mac user, using Mac OS X might
run classic
Mac OS programs, in the classic environmant, which produces #13 files.
Actually, the standard Carbon stuff might also still use #13.
Jonas
__
06-01-19 13.05, skrev Jonas Maebe följande:
>
> On 19 jan 2006, at 11:51, L505 wrote:
>
>> From the FPC ReadLn sources I was under the impression that the Mac
>> used #13 for line
>> feeds and unix used #10 for line feeds, but I've heard that
>> sometimes certain unix
>> systems used #13.
>
> M
> At 19.01.2006 11:57, you wrote:
>
> >I've grown to like ObjFPC mode for understanding Pascal at a greater level
> >but using
> >Delphi mode is a good idea with code coming from Delphi.
>
> I agree completely. Delphi mode should support struggling with legacy code,
> but the idea of FP is (hop
At 19.01.2006 11:57, you wrote:
I've grown to like ObjFPC mode for understanding Pascal at a greater level
but using
Delphi mode is a good idea with code coming from Delphi.
I agree completely. Delphi mode should support struggling with legacy code,
but the idea of FP is (hopefuly) not to co
On 19 jan 2006, at 11:51, L505 wrote:
From the FPC ReadLn sources I was under the impression that the Mac
used #13 for line
feeds and unix used #10 for line feeds, but I've heard that
sometimes certain unix
systems used #13.
Mac OS 9 and below used #13. Mac OS X, with it's unix/bsd herita
> Maybe it helps to trust in Delphi mode
> and makes porting to FP easier.
I've grown to like ObjFPC mode for understanding Pascal at a greater level but
using
Delphi mode is a good idea with code coming from Delphi. Many of the objfpc mode
choices were made with Pascal philosophy in mind, wherea
L505 wrote:
Is it possible the Apple/Mac line feed could be causing your name
to be rammed into
the text below :-)
No. Mac OS X uses the same line feed as every other *nix out there.
From the FPC ReadLn sources I was under the impression that the Mac used #13
for line
feeds and unix used
> > Is it possible the Apple/Mac line feed could be causing your name
> > to be rammed into
> > the text below :-)
>
> No. Mac OS X uses the same line feed as every other *nix out there.
>From the FPC ReadLn sources I was under the impression that the Mac used #13
>for line
feeds and unix used #1
At 19.01.2006 11:08, Jonas wrote:
...
Anyway, in Delphi mode we should compile everything also compilable
by Delphi, so if that's not the case please submit a bug.
Ok. I will check it again and do so. Maybe it helps to trust in Delphi mode
and makes porting to FP easier.
--
Wolfram Kläger
[
On 19 jan 2006, at 11:00, Wolfram Kläger wrote:
Thanks. This seems exactly to be the point. Now I know better,
where to be careful. Let´s keep the difference to Delphi for
religious purposes.
I think the use of "religious" is inappropriate in this case since
religion is based on faith, a
At 19.01.2006 10:02, Jonas wrote:
The reason this is not a problem, is that you cannot access the
parameters of one procedure in another anyway. But you can access a
property of a parent class in the method of a child class.
Thanks. This seems exactly to be the point. Now I know better, where
At 19.01.2006 01:46, L505 wrote:
I dunno it is a religious thing, read the other messages too :)
Of course, the whole pascal thing is religion. And maillists like this are
kind of praying, at least when you have urgent questions :-)
Wolfram
--
Mosaikfabrik (r) Bilder von Bildern www.mosai
On 19 jan 2006, at 00:18, Wolfram Kläger wrote:
... This error should not be reported if you switch to Delphi mode.
Unfortunately no. This kind of errors ís reported by FPC, no matter
which mode, while Delphi does not.
I understand your explanation, but don´t really understand that an
a
On 19 jan 2006, at 00:49, L505 wrote:
Is it possible the Apple/Mac line feed could be causing your name
to be rammed into
the text below :-)
No. Mac OS X uses the same line feed as every other *nix out there.
No big deal, I just wondered from an academic perspective, whether
the line fee
> > ... use the underscore, although a bit messy looking:
> >
> > function SubstringData(const Offset, Count_: Integer): WideString;
> > virtual;
> > ...
>
> Thanks. Matches to the habit of the guy, who has written
> the Delphi code, that I am working on. He usually begins
> each private class i
L505 18.01.06 21:33:48:
> ... use the underscore, although a bit messy looking:
>
> function SubstringData(const Offset, Count_: Integer): WideString; virtual;
> ...
Thanks. Matches to the habit of the guy, who has written the Delphi code, that
I am working on. He usually begins each private
Is it possible the Apple/Mac line feed could be causing your name to be rammed
into
the text below :-)
No big deal, I just wondered from an academic perspective, whether the line
feed on
the Mac would cause this issue on a PC, or whether it was for other reasons.
Lars
-
Jonas 18.01.06 21:30:58:
> ... This error should not be reported if you switch to Delphi mode.
Unfortunately no. This kind of errors ís reported by FPC, no matter which mode,
while Delphi does not.
I understand your explanation, but don´t really understand that an
anyproc.anyparam.name can
On Wed, 18 Jan 2006 13:39:21 -0700
L505 <[EMAIL PROTECTED]> wrote:
> > Conclusion: never call any parameter of any procedure or function exactly
> > like any property of any class and its ancestors. So far I thought,
> > parameter names of functions and procedures are always local, i.e. valid
> >
> Conclusion: never call any parameter of any procedure or function exactly
> like any property of any class and its ancestors. So far I thought,
> parameter names of functions and procedures are always local, i.e. valid
> for this function or procedure block only. Is this a bug or feature of FPC
On 18 Jan 2006, at 21:21, Wolfram Kläger wrote:
Conclusion: never call any parameter of any procedure or function
exactly like any property of any class and its ancestors. So far I
thought, parameter names of functions and procedures are always
local, i.e. valid for this function or proced
Hi, it´s me, the guy with this internal error recently, while porting
OpenXML to FP. Meanwhile, the compiler switch -B did help me out.
Apparently by compiling all units, regardless wether they have been changed
or not, this internal error is avoided. Now I believe this B stands for
Back to hel
23 matches
Mail list logo
