Thanks, but that's what the make file appears to do already
(crossinstall into a local target which is then zipped).
If this problem is not affecting anyone else I'll not worry about it
it as I've coded a simple script to work around the problem when
installing on my system here.
Bruce.
On Tue,
Your phrase almost made me care about...
Do you wanna make me care ? Show some points, make a constructive
critic about what i said etc.
For all that matter, your answer is just a plain old argumentum ad
hominem, a fallacy category, and being a fallacy, tells me you cant
really make a good answer
09.01.13, 6:26, Michael Fuchs пишет:
What is the best way for a discussion on this? Should I create a feature
request in bugtracker?
First create a desired implementation with a patch.
Best regards,
Paul Ishenin
___
fpc-pascal maillist - fpc-pasca
Am 08.01.2013 17:33, schrieb Graeme Geldenhuys:
+1
The current behaviour (even if Delphi compatible) seems just wrong -
totally defeats the point of "abstract" in object design!
What is the best way for a discussion on this? Should I create a feature
request in bugtracker?
Michael
_
Any other thoughts as to what I should do or information I can provide to
help diagnose this further? It would be a shame to loose the ability to
cross compile to Mac. Bruce.
On Jan 8, 2013 10:07 PM, "Bruce Tulloch" wrote:
> On Tue, Jan 8, 2013 at 9:04 PM, Jonas Maebe
> wrote:
> >
> > On 08 Jan
On 01/08/13 12:33, Michael Fuchs wrote:
>
> For example a compiler error in {$MODE ObjFpc} and the actual behaviour
> in {$MODE Delphi}. That would not break compatibility, but gets a nice
> feature for FPC.
+1
The current behaviour (even if Delphi compatible) seems just wrong -
totally defeat
Am 08.01.2013 13:29, schrieb Paul Ishenin:
Abstract class feature is implemented the same way as it is done in
delphi. In delphi it does not raise any error, so it works in FPC. The
only limitation is that you can't both set sealed and abstract for the
same class.
Maybe later delphi will come wi
08.01.13, 19:48, Michael Fuchs пишет:
I thougt this would cause a compiler error, while creating a abstract
class. Surprisingly it compiles, even without a warning.
Do I have to use any compiler switches or is there no sense in using the
abstract keyword for a class?
Abstract class feature is
On Tue, Jan 08, 2013 at 08:19:15AM -0300, Jorge Aldo G. de F. Junior wrote:
> C programmers are (usually, but there are a lot of exceptions) bad
> programmers who confuse the power of a language with the capability of
> decrease the ammount of typing needed to reach a certain goal.
>
> They despis
Am 08.01.2013 13:06, schrieb Howard Page-Clark:
TAbstractClass = class abstract(TObject)
>
'Casting' a class as abstract is curious syntax. What led you to think
of that? But obviously the compiler knows it.
This is no casting, it is the new abstract class syntax coming from delphi.
As s
On Tue, Jan 08, 2013 at 09:58:19AM +0100, Krzysztof wrote:
> I don't like a lot of C++ syntax but this one is interesting. You really
> don't like it? :)
Most C programmers I've dealt with (including myself) consider this bad
practise.
Henry
___
fpc-pas
On 08/1/13 11:48, Michael Fuchs wrote:
program AbstractTest;
{$MODE ObjFpc}{$H+}
uses Classes;
type
TAbstractClass = class abstract(TObject)
end;
var
MyAbstractClass: TAbstractClass = nil;
begin
MyAbstractClass := TAbstractClass.Create;
MyAbstractClass.Free;
end.
'Casting' a
Marco van de Voort wrote:
In our previous episode, Krzysztof said:
I don't like a lot of C++ syntax but this one is interesting. You really
don't like it? :)
It's the worst thing ever. 95% of the hard to find errors in C in my code
are due to = vs == mixup.
Seconded. In fact, if assignment d
Hello,
I have the following test program:
program AbstractTest;
{$MODE ObjFpc}{$H+}
uses Classes;
type
TAbstractClass = class abstract(TObject)
end;
var
MyAbstractClass: TAbstractClass = nil;
begin
MyAbstractClass := TAbstractClass.Create;
MyAbstractClass.Free;
end.
I thougt this
I never use [cross]zipinstall so I have no idea about it, make [cross]install
produce the correct directory structure. Perhaps you can [cross]install
first then manually zip the result.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/FPC-s-broken-cross-compiler
> I don't like a lot of C++ syntax but this one is interesting. You really
don't like it? :)
HELL NO! Most C/C++ programmers don't have any idea who will READ and
CONTINUE their work, and I'm one of those unlucky person who has to deal
with this stupid, error prone, unreadable, worthless "feature"
C programmers are (usually, but there are a lot of exceptions) bad
programmers who confuse the power of a language with the capability of
decrease the ammount of typing needed to reach a certain goal.
They despise pascal because pascal is somewhat verbose (ignoring that
this is what makes pascal r
On Tue, Jan 8, 2013 at 9:04 PM, Jonas Maebe wrote:
>
> On 08 Jan 2013, at 10:49, Bruce Tulloch wrote:
>
> I had a working Debian Squeeze to Mac OSX Snow Leopard cross-
>
> What had changed when it stopped working?
I had to upgrade from Debian Sneeze to Wheezy (for other reasons) and
the previousl
On 08 Jan 2013, at 10:49, Bruce Tulloch wrote:
I had a working Debian Squeeze to Mac OSX Snow Leopard cross-
compilation system working. It's documented here:
http://wiki.freepascal.org/Cross_compiling_OSX_on_Linux
Unfortunately the method described on that page is now broken.
The problem li
I had a working Debian Squeeze to Mac OSX Snow Leopard cross-
compilation system working. It's documented here:
http://wiki.freepascal.org/Cross_compiling_OSX_on_Linux
Unfortunately the method described on that page is now broken.
The problem linking for OSX on a Linux no longer works for me.
I
In our previous episode, Krzysztof said:
> I don't like a lot of C++ syntax but this one is interesting. You really
> don't like it? :)
It's the worst thing ever. 95% of the hard to find errors in C in my code
are due to = vs == mixup.
___
fpc-pascal mai
I don't like a lot of C++ syntax but this one is interesting. You really
don't like it? :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Tue, Jan 8, 2013 at 10:44 AM, Krzysztof wrote:
> Hi,
>
> I like when Free Pascal trying to implement best practices from other
> languages. That was with increment variable using assign operator: i += 1.
> Anyway, few days ago I analyzed C++ code and I liked one syntax:
>
> if ( ( i = GetSomeVa
On Tue, 8 Jan 2013 09:44:13 +0100
Krzysztof wrote:
> Hi,
>
> I like when Free Pascal trying to implement best practices from other
> languages. That was with increment variable using assign operator: i += 1.
> Anyway, few days ago I analyzed C++ code and I liked one syntax:
>
> if ( ( i = GetSo
Am 08.01.2013 09:44, schrieb Krzysztof:
I like when Free Pascal trying to implement best practices from other
languages. That was with increment variable using assign operator: i += 1.
Anyway, few days ago I analyzed C++ code and I liked one syntax:
if ( ( i = GetSomeValue ) >= 10 ) {
// vari
Hi,
I like when Free Pascal trying to implement best practices from other
languages. That was with increment variable using assign operator: i += 1.
Anyway, few days ago I analyzed C++ code and I liked one syntax:
if ( ( i = GetSomeValue ) >= 10 ) {
// variable "i" already has value returned by
26 matches
Mail list logo
