Re: [fpc-devel] compiling fpc from cvs
On Tuesday 22 February 2005 08:09, Peter Vreman wrote: So let's assume I'm a completely idiot and I have downloaded fpc from cvs to compile it on a windows system. Do I have any hope to compile it? Install fpc 1.0.10 Download fpc from cvs Start cmd.exe Go to the new fpc directory Type 'make all' Not much different from compiling any other C project. OK, tried, done... I'm definitely a complete idiot! ;) Thanks to all. Bye Uberto ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problem with install/binw32
It would appear that the set of win32 binaries that Peter installed in the install/binw32 directory of cvs on 2/7 contains a back-level version of a couple programs, as compared to the versions available from the binary download (1.9.6 released 1/1/2005). Specifically, the download version of ld, strip and windres are all "2.15.91 20040904" while the cvs install/binw32 versions of these three are "2.9.5". Using the 2.9.5 version of ld causes the following error when doing a make (linking the ide) libcygwin.a(pseudo-reloc.o)(.text+0x52)undefined reference to __RUNTIME_PSEUDO_RELOC_LIST_END__ libcygwin.a(pseudo-reloc.o)(.text+0x59)undefined reference to __RUNTIME_PSEUDO_RELOC_LIST_END__ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Modernising Pascal
Hi,
Just wandering if any of you are interested in modernising Pascal which
is looking quite dated when compared to modern languages like Python. I
note free pascal supports a variety of pascal dialects but none of them
are particular modern.
My main gripes with Delphi/pascal is its additional verbosity and
somewhat tedious coding practices which seem superfluous in some cases.
Now I dont mind typing a bit extra to make code cleaner and more legible
but I have a few ideas which would reduce needless typing and improve
clarity at the same time.
(feel free to shoot down any of these ideas)
1. Memory management. Delphi is quite incosistent here by allowing
component classes to be auto managed (via their owner) whilst
non-component class have to be manually managed. The best solution I can
think for this is to reference count non-component classes. This should
be safe for TObjects but obviously not for Tcomponent descendants (cf
circular reference problem) so a protected variable could be added to
TObject to specify whether to ref count it or not (with TComponent
turning it off). This will improve legibility of code too as there will
no longer be a need for having loads of try..finally statements to free
stuff. Backwards compatibility should not be affected so if you call a
free method it will free it whatever its ref count.
2. For Each. Its in Delphi 2005 and every modern language implements it.
3. Increasing the number of base types to include common stuff like
lists (Tlist, TStringList). Python does this nicely and theres no reason
Pascal cant. Base types are dynamically allocated and reference counted
so theres no need to explicitly create or destroy them. The following
code would therefore work :
var strlist : Stringlist;
begin
strlist.add('mystring');
end;
(note I did not use a T in front of StringList so as to distinguish it
from non-base types and also to maintain backwards compatibility with
existing code that uses TStringList conventionally)
jamie.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Modernising Pascal
(note I did not use a T in front of StringList so as to distinguish it from non-base types and also to maintain backwards compatibility with existing code that uses TStringList conventionally) jamie. Are you always drunk? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modernising Pascal
Jamie McCracken wrote: Hi, Just wandering if any of you are interested in modernising Pascal which is looking quite dated when compared to modern languages like Python. Oh, the language which is on fortran 77 level regarding formatting? Sorry, couldn't resist :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Modernising Pascal
1. Memory management. Delphi is quite incosistent here by allowing component classes to be auto managed (via their owner) whilst non-component class have to be manually managed. The best solution I can think for this is to reference count non-component classes. This should be safe for TObjects but obviously not for Tcomponent descendants (cf circular reference problem) so a protected variable could be added to TObject to specify whether to ref count it or not (with TComponent turning it off). This will improve legibility of code too as there will no longer be a need for having loads of try..finally statements to free stuff. Backwards compatibility should not be affected so if you call a free method it will free it whatever its ref count. there would be quite some performance penalty to this. Refcounting is actually quite expensive especially because of the way it adds loads of extra try-finally blocks to the asm. furthermore how do you propose to do such a thing while maintaining the capability to typecast safely back and forward between object types and integer types which so much code relys on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modernising Pascal
peter green wrote: 1. Memory management. Delphi is quite incosistent here by allowing component classes to be auto managed (via their owner) whilst non-component class have to be manually managed. The best solution I can think for this is to reference count non-component classes. This should be safe for TObjects but obviously not for Tcomponent descendants (cf circular reference problem) so a protected variable could be added to TObject to specify whether to ref count it or not (with TComponent turning it off). This will improve legibility of code too as there will no longer be a need for having loads of try..finally statements to free stuff. Backwards compatibility should not be affected so if you call a free method it will free it whatever its ref count. there would be quite some performance penalty to this. Refcounting is actually quite expensive especially because of the way it adds loads of extra try-finally blocks to the asm. not much more cause you would still need try finally blocks in most cases for robust code. In other cases you can use a pointer to avoid overhead (IE in cases where you are not actually creating instances). furthermore how do you propose to do such a thing while maintaining the capability to typecast safely back and forward between object types and integer types which so much code relys on. not sure I understand the problem here. Can you give an example? jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
