Michael Van Canneyt wrote:
I suggest you create an external preprocessor, and limit yourself to that.
I don't consider your construct to be Pascal, so I will fight inclusion of it
in the compiler, not even under some {$Mode} construct.
Well all I ask is you wait til I have written it then g
Daniël Mantione wrote:
Op Sun, 5 Jun 2005, schreef Jamie McCracken:
yes but isn't it fair to say that such developers that require such
structures would be knowledgable enough to make it safe by using weak refs?
What is a weak ref?
Allows you to make a reference without increasi
L505 wrote:
Now there are some bondage discipline languages and Pascal is considered one..
even
though it's not case sensitive.. isn't indentation sort of bondage-discipline?
of course it is - any formal language will have some "bondage" in their
syntax. Indentation and Begin..End are such e
Daniël Mantione wrote:
Op Sun, 5 Jun 2005, schreef Jamie McCracken:
Its not a black or white issue IMO its a shade of grey. At the end of
the day you have to make a judgement call based on the facts. Im
asserting that with non-component objects the incidence of cycles is so
rare that
Michael Van Canneyt wrote:
On Sun, 5 Jun 2005, Jamie McCracken wrote:
Hans-Peter Diettrich wrote:
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
end
else
Hans-Peter Diettrich wrote:
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
end
else
if
...
lol - thats not what I meant. If you want readab
Danny Milosavljevic wrote:
you *might* have less overhead using ref count on a tstringlist then
making it a component (if you are creating more than one reference to it
or passing it as a parameter to a function then yes a component would be
more efficient). You also have the problem of what y
Danny Milosavljevic wrote:
I'd suggest creating tlist, tstringlist, tfilestream-like things with an
optional owner (TComponent-like). I've been programming delphi for
years, and trust me, I know how annoying keeping track of tlist memory
is (and I mean _annoying like [EMAIL PROTECTED] hell_ :)).
Nico Aragón wrote:
El Sábado, 4 de Junio de 2005 11:00, Jamie McCracken escribió:
I had thought of that but thats problematic for debugging. IE the
compiler returns line numbers for errors and they will not match if I
use an external preprocessor.
See the recent thread "How to man
Hans-Peter Diettrich wrote:
You obviously missed that a compiler does not only consist of scanner
and parser, but that optimizers and code generators also have to be
implemented. For multiple target platforms and CPU's...
The new dialect simply makes the syntax less annoying and verbose - it
Vincent Snijders wrote:
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use
it - stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks for
Marc Weustink wrote:
Jamie McCracken wrote:
[snip]
would become under Rad Pascal:
uses
Classes, SysUtils;
TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
inherited Create(AnOwner);
inc (count
Yes. Too bad it is not possible. One of the problems you can expect is
with cyclic units. Normally the interfaces of the units form a tree, which
define how they get called. So the compiler can compile the interfaces in
the depth first order, then it can do the implementations in any order it
w
Daniël Mantione wrote:
Op Thu, 2 Jun 2005, schreef Jamie McCracken:
Daniël Mantione wrote:
Ok! We'll be happy to assist anyone doing interresting developments with
Free Pascal. Keep in mind though that implementing ideas can take "a lot"
more time that thinking out i
Daniël Mantione wrote:
Granting all those wishes would turn the language in an enourmous
monster. That doesn't look like a good idea. We've also a limit amount of
developers whos time needs to be spent well, or we'll get behind.
So, we're very convervative. Good ideas though, that will really
L505 wrote:
| Yeah I know this sounds like a hybrid Pascal/python but I believe thats
| the way to go - marry Delphi's speed and component framework with less
| verbose python style syntax and you will have the best RAD language ever
| written.
|
You are asking to reinvent python. If I were you
Vinzent Hoefler wrote:
On Thursday 02 June 2005 15:16, Uberto Barbini wrote:
If the goal is this, I'd prefear a way to declare objects
autocreated:
varauto:
strlist: TStringList;
begin
//some stuff
end;
[...]
It could be a problem to pass parameters to the constructor.
Yes, exactly.
Michael Van Canneyt wrote:
But the compiler needs to check many things:
1. Initialize the S with Nil.
2. Check that S is assigned only once during the lifetime of the
procedure.
This is actually a bigger restriction than you might think,
unless you want to introduce reference counting.
Vinzent Hoefler wrote:
>
manual memory management of tobjects is redundant as you can get good
performance with ref counting tobjects.
That can be a point, yes. But it is somehow not related to any syntax.
It means not having to bother with my pet hate the try..finally..free
All in all
Micha Nelissen wrote:
On Thu, 02 Jun 2005 15:31:51 +0100
Jamie McCracken <[EMAIL PROTECTED]> wrote:
Micha Nelissen wrote:
I don't understand, why are these forward declarations so evil ?
More code bloat, more typing and they get in the way. They dont give me
anything usefu
Vinzent Hoefler wrote:
On Thursday 02 June 2005 14:01, Jamie McCracken wrote:
Vinzent Hoefler wrote:
What matters is designing und understanding the code, not writing
it. I spend less than 10% of my time at work in actually _writing_
code, so even if someone can type in his/her code twice
Micha Nelissen wrote:
I don't understand, why are these forward declarations so evil ?
More code bloat, more typing and they get in the way. They dont give me
anything useful in return.
Garbage collection is largely no issue when using the Owner concept in
TComponent, using TObjectList,
Michael Van Canneyt wrote:
I don't consider Ojbect Pascal to be verbose at all, so it's not an
issue for
me...
Well I will typically spend about 25% of my development time with
forward declarations, doing loads of try finaly blocks to free memory
and other things instead of implementing m
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
You must be a damn fast typer the
Florian Klaempfl wrote:
If that were the case then yeah it would sux (however pythons
performance is due to bien a bytecode interpreter and dynamic typing
neither of which we need in pascal).
Ref. counting etc. eats time because you need good garbage collection to detect
cycles and other ugl
Micha Nelissen wrote:
On Thu, 02 Jun 2005 14:22:55 +0100
Jamie McCracken <[EMAIL PROTECTED]> wrote:
In terms of _written_ or in terms of _working_ lines of code? :->
Dont kid yourself - a lot of my fellow Delphi programmers have dumped it
for C# already so it is really worryi
Michael Van Canneyt wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#. Ironically python is
perhaps the most popular language on Linux and most of its syntax is
derived from object pascal whereas pascal on linux is virtually
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet with any
python programmer that I create any application faster than him :)
You must be a damn fast typer then :)
Ironically python is perhaps the
most popular language on Linux and most of its syn
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
MyObject.Create is impossible with classes on the heap. You need to
assign MyObject a pointer but you can't do that from within create.
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:04, Jamie McCracken wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#.
In terms of _written_ or in terms of _working_ lines of code? :->
Dont kid yourself - a lot of
Marc Weustink wrote:
What is easier to read is a matter of taste.
Being a pascal devel for years now, it takes time to "decode" a "a := b
:= c := d := 0" line. There might be a ; inbeween which results in a
complete different assignment. With such lines I've to read them over and
over to see
Jonas Maebe wrote:
On 30 May 2005, at 18:29, Jamie McCracken wrote:
What would be nice is to have a compiler switch which takes say an
8bit value to indicate how many bytes a function must contain in
order to be inlined automatically. That way it is scaleable and so
wont exacerbate the
Hans-Peter Diettrich wrote:
well thats soemthing you should add to your to do list. Automatic
inlining can deliver a signifcant performance improvement especially as
delphi uses a lot of one line procedures to set property values. A
fucntion call adds quite a bit of overhead (around 10+ clock c
well thats soemthing you should add to your to do list. Automatic
inlining can deliver a signifcant performance improvement especially
as delphi uses a lot of one line procedures to set property values. A
fucntion call adds quite a bit of overhead (around 10+ clock cycles at
a guess)
But inl
Jonas Maebe wrote:
On 29 May 2005, at 13:41, Peter Vreman wrote:
Doesn't the compiler attempt to inline small functions/methods
automatically as part of its optimisation (even if the inline
directive is not specified)?
No.
The inline directive is only a hint to the compiler. The behaviou
Some things that will affect executable size include:
1) Over zealous use of inlining (I dont see a command option to
control how much inlining is done)
There is almost none in the rtl.
Doesn't the compiler attempt to inline small functions/methods
automatically as part of its optimisat
Daniël Mantione wrote:
Op Sat, 29 May 2004, schreef Matthias Hryniszak:
In addition comparing the sources of VCL and FCL they
don't differ that much and the source isn't that much bigger so by this kind
of differences the problem must lie with compiler/linker.
It *is* the source. The compi
Jonas Maebe wrote:
On 28 feb 2005, at 12:26, Jamie McCracken wrote:
FPC uses an platform independent method. The C++ ABI isn't used.
But it could be used on platforms that have a "fairly" stable and
standardised C++ ABI (windows and Linux mainly). Other platforms can
use the curr
Peter Vreman wrote:
Why are you looking at GC/Refcounting when the problem is the
try..finally?
It is better to rewrite the try..finally code using the C++ ABI for
exception handling.
Where do you see improvements in the C++ ABI? Or even differences?
Windows implements this ABI, and every language
Marco van de Voort wrote:
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether any
Uberto Barbini wrote:
I also thought immediately what Uberto already said: how do you recognize
a valid/invalid reference without accessing memory that is invalid in the
mean time.
How does a GC do this? It would have the same problem?
A GC dont' try to recognize a valid/invalid reference, it is i
Marco van de Voort wrote:
a valid/invalid reference without accessing memory that is invalid in the mean
time.
How does a GC do this? It would have the same problem?
A GC manages all memory, local variable allocation inclusive. IOW, the
way a GC does it, is not possible in a mixed environment.
Are
Marco van de Voort wrote:
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether any
Uberto Barbini wrote:
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether anything that references it is still valid and delete if
ap
Hi,
Rather than continuing the GC stuff which seems fruitless I thought it
might be better to improve what we have with ref counting (whilst taking
a leaf out of the GC book as well).
I note that ref counting is very fast without all the implicit
try..finally stuff so I was wondering if it was
DrDiettrich wrote:
Jamie McCracken wrote:
GC is very inefficient with memory and current implementations tend to
cost a lot performance wise too.
I don't see how GC is inefficient with memory?
Reference counting and (mark/sweep) garbage collection have a different
runtime behaviour: Refe
Marco van de Voort wrote:
On 25 feb 2005, at 15:49, Marco van de Voort wrote:
- Critical parts are often handoptimized by using a lot of non GCed
types
(like int), this is not a typical programming method for these
languages, but outright expert tuning.
Critical paths are also optimized in our
Florian Klaempfl wrote:
Jamie McCracken wrote:
I did wrote GC in C++ itself. So it binds rather well...
not a compacting one then -
Ref. counting isn't compacting either?
Not an issue cause memory allocation is conventional when ref counting.
GCs allocate memory from a managed heap
Sebastian Kaliszewski wrote:
On Thursday 24 February 2005 13:51, Jamie McCracken wrote:
IMO the best solution for (almost) all of your problems were garbage
collection. GC is part of Oberon, and it would fit into .NET/DotGNU as
well.
GC is very inefficient with memory and current implementations
Sebastian Kaliszewski wrote:
On Thursday 24 February 2005 14:57, Jamie McCracken wrote:
It's *much* faster than reference counting everything. Reference
counting is more or less the slowest garbage collection technique there
is (except if only very few objects have to garbage collected). It
Jonas Maebe wrote:
On 24 feb 2005, at 13:51, Jamie McCracken wrote:
IMO the best solution for (almost) all of your problems were garbage
collection. GC is part of Oberon, and it would fit into .NET/DotGNU as
well.
GC is very inefficient with memory and current implementations tend to
cost a lot
I do need an IDE anyhow for container based GTK2/Gnome2/Glade apps so
maybe I ought to start writing one that implements this.
Why don't you see if you can get this implemented as an add-on in
Lazarus ? You get the rest of the IDE for free.
In the short term yes (although I use delphi 5 under Wi
DrDiettrich wrote:
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
Marco van de Voort wrote:
My mistake it actually avoids initialising the loop variable rather than
not declaring it:
for i in myarray do
myarray[i] := 0;
as opposed to
for i := low(myarray) to high (myarray) do
myarray[i] := 0;
I think the for..in is much clearer and more compact (it works f
Marco van de Voort wrote:
2. For Each. Its in Delphi 2005 and every modern language implements it.
Yeah, and I still wonder why. There is nothing to gain with it.
one less variable to manually declare
Implement something in lazarus that auto-adds the variable to the local var
section. No need
Florian Klaempfl wrote:
So if you look at this, you know why classes aren't ref. counted. And
there is no chance to avoid the code generated for the interface.
Yes that does look very bad but if you passed a pointer to the ref
counted object as the function arguement then you would not get all t
Marco van de Voort wrote:
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 re
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 saf
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
59 matches
Mail list logo
