[fpc-pascal] Changing variable in conditional
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 GetSomeValue
}
I wonder if FPC has equivalent for this.
Regards
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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 ) {
// variable "i" already has value returned by GetSomeValue
}
I wonder if FPC has equivalent for this.
I hope not.
Why do you use Pascal if you want this ugly C-crap-style?
Even the i += 1 is a sin.
*shudder*
Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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 = GetSomeValue ) >= 10 ) {
> // variable "i" already has value returned by GetSomeValue
> }
>
> I wonder if FPC has equivalent for this.
Even C has some equivalent:
i = GetSomeValue;
if ( i >= 10 ) {
// no comment needed, the value of i is obvious
}
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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 = GetSomeValue ) >= 10 ) {
> // variable "i" already has value returned by GetSomeValue
> }
>
> I wonder if FPC has equivalent for this.
No, and thanks Wirth for that, and for FPC/Delphi devs for not adding it up.
It's one of the worst possible features ever existed in programming
languages, and the cause for many bugs
>
> Regards
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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
Re: [fpc-pascal] Changing variable in conditional
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 maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Linker fails cross compiling from Linux to Mac.
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. It produces errors like these: i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libiconv.dylib load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libobjc.dylib load command 7 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libc.dylib load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Cocoa.framework/Cocoa load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Foundation load command 6 unknown cmd field Here's what I'm using: 1) FPC 2.6.2 rc1 (and I've tried 2.6.0 as well). 2) Apple's cctools 809 release suitably patched. 3) A Debian Wheezy Linux host. The cctools-809 source comes from: http://www.opensource.apple.com/tarballs/cctools/cctools-809.tar.gz The patch applied to make it buildable for Linux is: https://github.com/mingwandroid/xchain/blob/master/patches/cctools-809-nondarwin.patch plus a few tweaks of my own to fix some build bugs. It's built against MacOSX10.6.sdk (I've tried MacOSX10.5.sdk too) for 32 bit (-m32) builds (64 bit is not supported). FPC, FCL, LCL et al are all built against the same SDK. Compilation works just but linking fails as shown above. I've tried various combination of compilation switches but nothing seems to allow the link to succeed. Does anyone have a clue why this might be failing? I seems like I'm on the brink of success if only I can work out why these errors are occurring. The most obvious thought is that not all objects were built against the same revision of the SDK but I can confirm they are. The missing command codes are (from MacOSX10.6.sdk/usr/include/mach-o/loader.h): #define LC_THREAD 0x4 /* thread */ #define LC_UNIXTHREAD 0x5 /* unix thread (includes a stack) */ #define LC_LOADFVMLIB 0x6 /* load a specified fixed VM shared library */ #define LC_IDFVMLIB0x7 /* fixed VM shared library identification */ I will give up on this if no one has any ideas and the wiki needs to be updated to report that cross-compilation from Linux to Mac is no longer possible but I'm willing to give it some more work based on pointers anyone can suggest. Failing that I will revert to a native Mac system but I'd really like to have cross-compilation working if possible. Any suggestions? Bruce ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linker fails cross compiling from Linux to Mac.
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 linking for OSX on a Linux no longer works for me. What had changed when it stopped working? It produces errors like these: i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libiconv.dylib load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libobjc.dylib load command 7 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libc.dylib load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Cocoa.framework/Cocoa load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/ Foundation load command 6 unknown cmd field This suggests that you are using a linker that is too old. Are you certain that the used i386-darwin-ld is the one you built from cctools-809? (compile with -Cn and look at the generated ppas.sh) The most obvious thought is that not all objects were built against the same revision of the SDK but I can confirm they are. That has no influence anyway. Objects are not really built against an SDK, only libraries and applications are. The SDK only affects the linking in case of Pascal (in case of C/C++, it also affects the compilation because of the used headers). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linker fails cross compiling from Linux to Mac.
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 previously built odcctools linker (derived from the older cctools-758) required libraries no longer available in Wheezy which required that I rebuild it from source but the long dead odcctools source was no longer available so I rebuilt from Apple's upstream cctools-809 with the new patches. > This suggests that you are using a linker that is too old. Should be okay, cctool-809 is 10.6 aware (the get_macosx_deployment_target() function in the linker reports 10.6 when run). > Are you certain that the used i386-darwin-ld is the one you built from > cctools-809? Yep, I already checked this. ppas.sh reports /usr/local/opt/cctools/bin/i386-darwin-ld which is correct. The linker is built with this script (working in a repository I created): #!/bin/bash # Compilation parameters, adjust as required... export TARGET=i386-darwin # OSX target (i386-darwin or x86_64-darwin) export SYSROOT=/usr/local/opt/osx/MacOSX10.6.sdk # OSX SDK root export CCTOOLS="809" # OSX cctools version (must be a patched for linux) export PREFIX=/usr/local/opt/cctools # build host installation directory cd cctools # working repository # Checkout revision and patch hg update -C cctools-$CCTOOLS hg -R $(hg root)/.hg/patches update -C cctools-$CCTOOLS hg qpush --all # configure and build autoconf && chmod +x configure CFLAGS="-m32 -D__DARWIN_UNIX03" LDFLAGS="-m32" ./configure \ --prefix=$PREFIX \ --target=$TARGET \ --with-sysroot=$SYSROOT \ && make && make install # cleanup hg update -C hg qpop --all hg clean >> The most obvious thought is that not all objects were built against >> the same revision of the SDK but I can confirm they are. > > That has no influence anyway. Objects are not really built against an SDK, > only > libraries and applications are. The SDK only affects the linking in case of > Pascal > (in case of C/C++, it also affects the compilation because of the used > headers). Thanks, understood. It's linking the application that presents the problem. I've noticed that all errors except these two: i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field disappear IF I enable debug symbols when compiling. Don't know if this is a clue and it does not appear to matter which type of debug info I enable. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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 readable) because they think that the best language is the one wich allows to write a whole program in a single line of code. Thats because they dont usually think before writing, they think while they are implementing, and then the only thing between current momment and the momment when their program is "ready" is the ammount of typing. Pascal programmers tend to plan ahead, they think before they type. We type a lot because of Pascal verboseness, but usually our code is right from the start. We end up typing less because we fix less bugs. Pascal generally improves programmer productivity. Lets not break this by adding crazy ideas from C/C++ family of languages... 2013/1/8 Marco van de Voort : > 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 maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Changing variable in conditional
> 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"! -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Changing-variable-in-conditional-tp5712493p5712503.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: FPC's broken cross-compiler directory structure?
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-directory-structure-tp5712491p5712504.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Use of abstract classes
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 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?
Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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 didn't propagate a value like that I'm not sure a distinction would have to be made between (C-style) = and == or (Pascal-style) := and = -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use of abstract classes
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 class as abstract is curious syntax. What led you to think
of that? But obviously the compiler knows it.
As soon as you add an abstract method the compiler will give a warning.
Howard
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use of abstract classes
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 soon as you add an abstract method the compiler will give a warning. Yes, this behaviour I know. But I would prefer an error for abstract classes. I was hoping, that the class abstract keyword led to this error. Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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 despise pascal because pascal is somewhat verbose (ignoring that > this is what makes pascal readable) because they think that the best > language is the one wich allows to write a whole program in a single > line of code. > > Thats because they dont usually think before writing, they think while > they are implementing, and then the only thing between current momment > and the momment when their program is "ready" is the ammount of > typing. > > Pascal programmers tend to plan ahead, they think before they type. We > type a lot because of Pascal verboseness, but usually our code is > right from the start. We end up typing less because we fix less bugs. > > Pascal generally improves programmer productivity. Lets not break this > by adding crazy ideas from C/C++ family of languages... "Better to keep your mouth closed and be thought a fool than to open it and remove all doubt" ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use of abstract classes
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 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 with some extra checks for abstract classes and then FPC will follow. Best regards, Paul Ishenin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use of abstract classes
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 with some extra checks for abstract classes
and then FPC will follow.
Hm, and how about a pioneer solution?
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.
Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use of abstract classes
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 defeats the point of "abstract" in object design!
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linker fails cross compiling from Linux to Mac.
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 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 previously built odcctools linker (derived from the older > cctools-758) required libraries no longer available in Wheezy which > required that I rebuild it from source but the long dead odcctools > source was no longer available so I rebuilt from Apple's upstream > cctools-809 with the new patches. > > > This suggests that you are using a linker that is too old. > > Should be okay, cctool-809 is 10.6 aware (the > get_macosx_deployment_target() function in the linker reports 10.6 > when run). > > > Are you certain that the used i386-darwin-ld is the one you built from > cctools-809? > > Yep, I already checked this. > > ppas.sh reports /usr/local/opt/cctools/bin/i386-darwin-ld which is correct. > > The linker is built with this script (working in a repository I created): > > #!/bin/bash > > # Compilation parameters, adjust as required... > > export TARGET=i386-darwin # OSX target (i386-darwin or x86_64-darwin) > export SYSROOT=/usr/local/opt/osx/MacOSX10.6.sdk # OSX SDK root > export CCTOOLS="809" # OSX cctools version (must be a patched for linux) > export PREFIX=/usr/local/opt/cctools # build host installation directory > > cd cctools # working repository > > # Checkout revision and patch > > hg update -C cctools-$CCTOOLS > hg -R $(hg root)/.hg/patches update -C cctools-$CCTOOLS > hg qpush --all > > # configure and build > > autoconf && chmod +x configure > CFLAGS="-m32 -D__DARWIN_UNIX03" LDFLAGS="-m32" ./configure \ > --prefix=$PREFIX \ > --target=$TARGET \ > --with-sysroot=$SYSROOT \ > && make && make install > > # cleanup > > hg update -C > hg qpop --all > hg clean > > >> The most obvious thought is that not all objects were built against > >> the same revision of the SDK but I can confirm they are. > > > > That has no influence anyway. Objects are not really built against an > SDK, only > > libraries and applications are. The SDK only affects the linking in case > of Pascal > > (in case of C/C++, it also affects the compilation because of the used > headers). > > Thanks, understood. It's linking the application that presents the problem. > > I've noticed that all errors except these two: > > i386-darwin-ld: > MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load > command 4 unknown cmd field > i386-darwin-ld: > MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load > command 5 unknown cmd field > > disappear IF I enable debug symbols when compiling. Don't know if this > is a clue and it does not appear to matter which type of debug info I > enable. > > Bruce. > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use of abstract classes
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use of abstract classes
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-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Changing variable in conditional
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, so i infer you are the idiot here. 2013/1/8 Henry Vermaak : > 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 despise pascal because pascal is somewhat verbose (ignoring that >> this is what makes pascal readable) because they think that the best >> language is the one wich allows to write a whole program in a single >> line of code. >> >> Thats because they dont usually think before writing, they think while >> they are implementing, and then the only thing between current momment >> and the momment when their program is "ready" is the ammount of >> typing. >> >> Pascal programmers tend to plan ahead, they think before they type. We >> type a lot because of Pascal verboseness, but usually our code is >> right from the start. We end up typing less because we fix less bugs. >> >> Pascal generally improves programmer productivity. Lets not break this >> by adding crazy ideas from C/C++ family of languages... > > "Better to keep your mouth closed and be thought a fool than to open it > and remove all doubt" > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: FPC's broken cross-compiler directory structure?
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, Jan 8, 2013 at 10:31 PM, leledumbo wrote: > 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-directory-structure-tp5712491p5712504.html > Sent from the Free Pascal - General mailing list archive at Nabble.com. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
