It actually uses record helpers, but the end result looks very much like
Java primitive types where you have .ToString, .Equals,
.Split etc...
Not with the intent to be contrary, but for the sake of clarity in
discussion, String in Java is not a primitive type; it is a full-fledged
class like
C# is a full OO language, so I guess yes it's supported. Anyway, Delphi
doesn't seem to move toward Java, but Embarcadero is missing Anders' touch.
And this is the way they get it for free :p
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Seems-Delphi-is-movin
In our previous episode, Vincent Snijders said:
> > I thought about the 2.6.0<->2.6.2 transition, but it is easy to temporarily
> > wrap another version check around it for a few weeks. More work, but not a
> > problem. (just needs documentation in rel_eng)
>
> Alternatively, it could just be a wa
On 2012-10-17 15:57, Vincent Snijders wrote:
>
> Alternatively, it could just be a warning. Then if it fails later, the
> complete output will show the reason.
I disagree. To prevent any strange side-effects (undefined behaviour),
the version check should happen as early as possible - before any
2012/10/17 Marco van de Voort :
> D:\repo\fpc>make all
> makefile:2717: *** The only supported starting compiler version is 2.6.0.
> You are trying to build with 2.7.1. If you are absolutely sure that the
> current
> compiler is built from the exact same version/revision, you can try to use
> OVER
In our previous episode, Jonas Maebe said:
> > OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Even
> > more: it will suggest that building a cross-compiler should also be
> > done starting with the latest release, while in fact it they should
> > be built using a native compiler
On 2012-10-17 14:18, michael.vancann...@wisa.be wrote:
>
> If you specify the dependencies right, it should figure out the order by
> itself.
I tried but it seems impossible, especially with uses clause pulling in
other dependencies.
I then tried fpmake from FPC 2.7.1... WOW, that made a huge di
On Wed, 17 Oct 2012, Graeme Geldenhuys wrote:
On 2012-10-17 11:17, Jonas Maebe wrote:
fpmake does not know about unit dependencies,
Ah OK. Thanks for the explanation. So if I ordered my units better in
the fpmake program, then that might reduce the multiple compiling too.
If you spe
In our previous episode, Jonas Maebe said:
> > It is kept simple on purpose. Only works on toplevel makefile (easy to
> > maintain), only on the toplevel "all" target, the required version
> > is also
> > kept there (toplevel Makefile.fpc as only place).
>
> I think it's annoying that you then h
On 2012-10-17 13:54, Jonas Maebe wrote:
> ...whenever you build a cross-compiler. Even more: it will suggest that
> building a cross-compiler should also be done starting with the latest...
Simply update the error message to say that the version check rules
might not apply to newly implemented pl
On 17 Oct 2012, at 14:54, Jonas Maebe wrote:
I think it's annoying that you then have to type
OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Even
more: it will suggest that building a cross-compiler should also be
done starting with the latest release, while in fact it they sh
On 17 Oct 2012, at 13:43, Marco van de Voort wrote:
It is kept simple on purpose. Only works on toplevel makefile (easy to
maintain), only on the toplevel "all" target, the required version
is also
kept there (toplevel Makefile.fpc as only place).
I think it's annoying that you then have t
In our previous episode, Reinier Olislagers said:
> > work-in-progress.
> >
> > So saying "if it won't compile with stable then sod off" isn't helpful.
>
> Mark, I understand what you mean.
>
> Regardless of the way Graeme put his point, I think having:
> - a rough check on latest stable compile
On 2012-10-17 11:49, Mark Morgan Lloyd wrote:
>
> So saying "if it won't compile with stable then sod off" isn't helpful.
That's definitely not how I meant for it to sound [the joys of email
conversations]. Reinier summed up my thoughts. Default behaviour is to
only allow last released FPC versio
On 2012-10-17 12:43, Marco van de Voort wrote:
>
> It is kept simple on purpose. Only works on toplevel makefile (easy to
> maintain), only on the toplevel "all" target, the required version is also
> kept there (toplevel Makefile.fpc as only place).
Nice, works perfectly here under 64-bit Linux
Reinier Olislagers wrote:
On 17-10-2012 12:49, Mark Morgan Lloyd wrote:
Graeme Geldenhuys wrote:
On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
Some slack would be desirable: stable is 2.6.0 but there are known
issues which are fixed by 2.6.1.
Nope, the FPC developers made the rules quite clea
On 17-10-2012 12:49, Mark Morgan Lloyd wrote:
> Graeme Geldenhuys wrote:
>> On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
>>> Some slack would be desirable: stable is 2.6.0 but there are known
>>> issues which are fixed by 2.6.1.
>>
>> Nope, the FPC developers made the rules quite clear! Not even t
Graeme Geldenhuys wrote:
On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
Some slack would be desirable: stable is 2.6.0 but there are known
issues which are fixed by 2.6.1.
Nope, the FPC developers made the rules quite clear! Not even the fixes
branch is guaranteed to compile FPC Trunk. ONLY the
Am 17.10.2012 12:31 schrieb "Graeme Geldenhuys" :
>
> On 2012-10-17 11:15, Paul Ishenin wrote:
> >
> > This was already discussed here or fpc-devel list.
>
>
> The video was about Delphi XE3, which just got release... was this
> Delphi functionality already existing in earlier Delphi versions too?
On 2012-10-17 11:15, Paul Ishenin wrote:
>
> This was already discussed here or fpc-devel list.
The video was about Delphi XE3, which just got release... was this
Delphi functionality already existing in earlier Delphi versions too?
[sorry, I don't keep up with every Delphi feature any more]
On 2012-10-17 11:17, Jonas Maebe wrote:
>
> fpmake does not know about unit dependencies,
Ah OK. Thanks for the explanation. So if I ordered my units better in
the fpmake program, then that might reduce the multiple compiling too.
Graeme.
__
On 2012-10-17 10:15, Jonas Maebe wrote:
>
> See http://www.mail-archive.com//msg25868.html and the rest of
> the thread.
[embarrassed] Clearly my age is starting to show. :-) How do you find
this old messages in any case.
Your concern about cross-compiling could be an exception - FPC versio
On 17 Oct 2012, at 12:08, Graeme Geldenhuys wrote:
> I'm using FPC 2.6.0 and have a fpmake.pas program for fpGUI. To be
> honest I don't really use it, but to keep it up to date. Anyway, I
> noticed that if I do a 'fpmake build', that fpmake compiles many of my
> units multiple times. Anywhere fr
On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
>
> Some slack would be desirable: stable is 2.6.0 but there are known
> issues which are fixed by 2.6.1.
Nope, the FPC developers made the rules quite clear! Not even the fixes
branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is
17.10.12, 17:00, Graeme Geldenhuys пишет:
Well, kind-of... I don't know if C# also supports this (like Java). It
probably does, because for the last few years, Delphi has just been
copying whatever is in C#. [sad]
...
Interesting.
This was already discussed here or fpc-devel list.
Best rega
Hi,
I'm using FPC 2.6.0 and have a fpmake.pas program for fpGUI. To be
honest I don't really use it, but to keep it up to date. Anyway, I
noticed that if I do a 'fpmake build', that fpmake compiles many of my
units multiple times. Anywhere from 2-4 times. I double checked my
fpmake.pas unit, and I
Am Wednesday 17 October 2012 11:10:22 schrieb Mark Morgan Lloyd:
> Graeme Geldenhuys wrote:
> > On 2012-10-17 01:40, Frank Church wrote:
> >> As the solution doesn't seem to be too difficult which file or files can
> >> "we" zoom in on to fix it?
> >
> > Thanks for showing interest in this. I know
On 17 Oct 2012, at 10:53, Graeme Geldenhuys wrote:
> The idea seems quite simple though. Do a `$compiler -iV` where $compiler
> is the starting compiler use to compile the FPC source code. If that
> version doesn't match a known "latest stable compiler version" constant,
> then report an error an
Graeme Geldenhuys wrote:
On 2012-10-17 01:40, Frank Church wrote:
As the solution doesn't seem to be too difficult which file or files can
"we" zoom in on to fix it?
Thanks for showing interest in this. I know near zero about Makefiles
and Makefile.fpc. I'm still a bit confused with FPC thoug
Well, kind-of... I don't know if C# also supports this (like Java). It
probably does, because for the last few years, Delphi has just been
copying whatever is in C#. [sad]
eg: This compiles and works in Delphi XE3.
ShowMessage('Hello World!'.ToUpper);
And there are lots more string function
On 2012-10-17 01:40, Frank Church wrote:
>
> As the solution doesn't seem to be too difficult which file or files can
> "we" zoom in on to fix it?
Thanks for showing interest in this. I know near zero about Makefiles
and Makefile.fpc. I'm still a bit confused with FPC though. Does FPC now
use fp
31 matches
Mail list logo
