Am 21.09.2014 06:13, schrieb Jonas Maebe:
On 21/09/14 08:10, Samuel Herzog wrote:
But it's not accepted.
*procedure* TFormThreading.Button1Click(Sender: TObject);
*var*
aTask: ITask;
**procedure* *MyTask*;
*begin*
*sleep (3000); // 3 seconds*
*ShowMessage ('Hello');*
AFAIR there already were several debates on ARC Objects that seem do be
a "modern" language feature but in Pascal language they are considered
to provide lots of pitfalls.
Why not use "interface" to add ref-counting to an object ? This seems to
work nicely even though the name "interface" in n
On 09/20/2014 01:42 PM, Sven Barth wrote:
"a farmer doesn't eat what he doesn't know"
Really healthy laughter from Germany,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-dev
On 09/21/2014 07:17 PM, Boian Mitov wrote:
In general I would prefer to see this implemented with attributes
rather than with new keywords.
Yet another attribute to "class".
This might (re-)trigger thought about a complete rework of of
record-enhancing types and allow for the "record" and "obj
On 09/20/2014 08:33 PM, Giuliano Colla wrote:
Can you explain how reference counting can be safely implemented in a
parallel multithreaded environment, without heavily affecting performance?
*Very* good point !
IMHO a by far more advantageous feature to be added than ref-counted
objects would
On 09/21/2014 06:36 PM, Boian Mitov wrote:
I consider it a design bug that local functions can't be passed as
anonymous methods in Delphi. There is no reason for that not to be
done, except that they did not bother.
???
Local functions can use local variables of the outer function. Same are
On 09/20/2014 08:04 PM, Boian Mitov wrote:
This is actually a very good idea IMHO!
I would vote for it. Record inheritance is something I miss badly in
Delphi.
As said in a previous mail: why have "Record" ad all, if you want things
like inheritance (and "active" properties, ...) Maybe multip
Am 22.09.2014 10:54 schrieb "Michael Schnell" :
>
> On 09/21/2014 06:36 PM, Boian Mitov wrote:
>>
>> I consider it a design bug that local functions can’t be passed as
anonymous methods in Delphi. There is no reason for that not to be done,
except that they did not bother.
>>
> ???
> Local functio
Am 22.09.2014 10:38 schrieb "Michael Schnell" :
>
> On 09/20/2014 08:33 PM, Giuliano Colla wrote:
>>
>> Can you explain how reference counting can be safely implemented in a
parallel multithreaded environment, without heavily affecting performance?
>
> *Very* good point !
>
> IMHO a by far more adv
Am 22.09.2014 09:47 schrieb "Michael Schnell" :
>
> AFAIR there already were several debates on ARC Objects that seem do be a
"modern" language feature but in Pascal language they are considered to
provide lots of pitfalls.
>
> Why not use "interface" to add ref-counting to an object ? This seems t
On 09/22/2014 11:13 AM, Sven Barth wrote:
Interfaces, strings and arrays already work well in multi threaded
contexts and ARC will use the same mechanisms here, so there is no
need to discuss "parallel" and ARC together.
Yep. it will work.
But one point speaking against ARC is performance
On 09/22/2014 11:15 AM, Sven Barth wrote:
Because you'll need to declare an interface for each class you want to
have reference counted so that you can access its methods, properties,
etc.
Con: more typing
Pro: you know what you are doing.
-Michael
_
> > Because you'll need to declare an interface for each class you want to
> > have reference counted so that you can access its methods, properties,
> > etc.
> >
> Con: more typing
> Pro: you know what you are doing.
I cannot agree more.
_
(to Sven)
So the cycle break mechanism is going to be marking potential cycle cases
as weak.
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too hard?
IOW I'm wondering what will happen (and what to do) if there is a cycle in a
suffi
Sven Barth schrieb:
On 21.09.2014 21:09, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
[...]
I'd add a _RefCount field to TObject, regardless of whether it's really
used later; this will fix the field offset - just like the VMT reference
is fixed in TObject, but not in Object types. This wil
On 09/22/2014 11:54 AM, Peter Popov wrote:
> > Because you'll need to declare an interface for each class you
want to
> > have reference counted so that you can access its methods,
properties,
> > etc.
> >
> Con: more typing
> Pro: you know what you are doing.
I cannot agree more.
Another c
Florian Klämpfl wrote:
Am 19.09.2014 um 22:49 schrieb Boian Mitov:
On Fri, 19 Sep 2014, Adriaan van Os wrote:
Your remarks seem to imply that you think RTTI can be used to inspect any
aspect of an object.
It was/is not meant for that.
<<<
Quite incorrect. All languages with modern RTTI allow
On 09/22/2014 07:52 AM, Sven Barth wrote:
I openly *hate* the attribute syntax. It's just not Pascal and simply
copied from their .Net compiler, because hey, other .Net compilers do
that just like that... -.-
Maybe instead of attribute appropriate base classes could be provided.
E.g. a (ma
Am 22.09.2014 11:57 schrieb "Marco van de Voort" :
>
>
> (to Sven)
>
> So the cycle break mechanism is going to be marking potential cycle cases
> as weak.
Basidally, yes.
> Do you still plan to at least detect cycles for debugging purposes?
>
> Or is the cycle detection itself already too hard?
Sven Barth schrieb:
Am 22.09.2014 09:47 schrieb "Michael Schnell"
> Why not use "interface" to add ref-counting to an object ? This seems
to work nicely even though the name "interface" in not "speaking" on
that behalf.
Because you'll need to declare an interface for each class you want to
Michael Schnell schrieb:
On 09/20/2014 08:04 PM, Boian Mitov wrote:
This is actually a very good idea IMHO!
I would vote for it. Record inheritance is something I miss badly in
Delphi.
As said in a previous mail: why have "Record" ad all, if you want things
like inheritance (and "active" pr
Marco van de Voort schrieb:
(to Sven)
So the cycle break mechanism is going to be marking potential cycle cases
as weak.
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too hard?
IOW I'm wondering what will happen (and what to do) i
Am 22.09.2014 14:19 schrieb "Michael Schnell" :
>
> On 09/22/2014 07:52 AM, Sven Barth wrote:
>>
>>
>> I openly *hate* the attribute syntax. It's just not Pascal and simply
copied from their .Net compiler, because hey, other .Net compilers do that
just like that... -.-
>>
> Maybe instead of attribu
Am 22.09.2014 12:59 schrieb "Hans-Peter Diettrich" :
>
> Sven Barth schrieb:
>>
>> On 21.09.2014 21:09, Hans-Peter Diettrich wrote:
>>>
>>> Sven Barth schrieb:
>
> [...]
>>>
>>> I'd add a _RefCount field to TObject, regardless of whether it's really
>>> used later; this will fix the field offset -
On 09/22/2014 02:34 PM, Sven Barth wrote:
I already suggested the addition of a TARCObject as a general
reference counted base class in my RFC ;)
So I am proud to have independently recreated your idea :-)
-Michael
___
fpc-devel maillist - fpc-d
Am 22.09.2014 14:30 schrieb "Hans-Peter Diettrich" :
>
> Sven Barth schrieb:
>
>> Am 22.09.2014 09:47 schrieb "Michael Schnell"
>
>> > Why not use "interface" to add ref-counting to an object ? This seems
to work nicely even though the name "interface" in not "speaking" on that
behalf.
>>
>> Beca
Am 22.09.2014 11:22 schrieb "Michael Schnell" :
>
> On 09/22/2014 11:13 AM, Sven Barth wrote:
>>
>>
>> Interfaces, strings and arrays already work well in multi threaded
contexts and ARC will use the same mechanisms here, so there is no need to
discuss "parallel" and ARC together.
>>
> Yep. it will
Am 22.09.2014 14:31 schrieb "Hans-Peter Diettrich" :
>
> Marco van de Voort schrieb:
>
>> (to Sven)
>>
>> So the cycle break mechanism is going to be marking potential cycle cases
>> as weak.
>>
>> Do you still plan to at least detect cycles for debugging purposes?
>>
>> Or is the cycle detection i
On 09/22/2014 02:51 PM, Sven Barth wrote:
Then you should also not use interfaces, strings and arrays, because
they use the same mechanisms.
Yep. The advanced developer should know what he is doing.
What us confusing there?
Of course I do know the pitfalls.
If fpc would provide a syntax
In our previous episode, Sven Barth said:
> > Do you still plan to at least detect cycles for debugging purposes?
> >
> > Or is the cycle detection itself already too hard?
> >
> > IOW I'm wondering what will happen (and what to do) if there is a cycle
> in a
> > sufficiently complex program.
>
>
On 09/22/2014 02:19 PM, Hans-Peter Diettrich wrote:
AFAIK *variant* records (currently) can not be replaced by something else.
I suppose you are right, but maybe appropriate syntax can be introduced
to class definition that might be helpful in certain instances.
-Michael
_
On 09/22/2014 02:05 PM, Hans-Peter Diettrich wrote:
TMyARCclass = interface(TObject)
IMHO, Sven's idea of introducing a "TARCObject" base class (triggering
the compiler magic for ref counting) sounds a lot nicer.
-Michael
___
fpc-devel maillist - f
In our previous episode, Hans-Peter Diettrich said:
> > Do you still plan to at least detect cycles for debugging purposes?
> >
> > Or is the cycle detection itself already too hard?
> >
> > IOW I'm wondering what will happen (and what to do) if there is a cycle in a
> > sufficiently complex prog
How will referenced objects behave when referenced by a threadvar. This is an
exceptional situation for both dynamic arrays and ansi strings.
Another comment: If referenced objects all derive from a single base, then, the
user cannot possibly have another hierarchy, which uses ref. objects. As
On 22 Sep 2014, at 16:44, Peter Popov wrote:
Another comment: If referenced objects all derive from a single
base, then, the user cannot possibly have another hierarchy, which
uses ref. objects. As I mentioned earlier, I do this explicitly for
an object well down my hierarchy. So, it seems
From: jonas.ma...@elis.ugent.be
To: fpc-devel@lists.freepascal.org
Date: Mon, 22 Sep 2014 17:11:08 +0200
Subject: Re: [fpc-devel] weak referencing (was Suggestion:.)
I would strongly recommend against that. Referenced and unreferenced objects
are completely different beasts with different
Although TBH what i'd prefer more than the above is language features that
would allow me to implement refcounted objects myself. Stuff like automatic
destruction when a generic variable goes out of scope, etc.
On Mon, Sep 22, 2014 at 5:45 PM, Kostas Michalopoulos <
badsectorac...@gmail.com> wrote
I prefer the TARCObject approach too, i don't want anything to be
refcounted unless i *explicitly* ask for it (yes i know some things are
already refcounted and at the past i was bitten by that which is a big
reason why i don't want hidden things to do magic stuff behind my back).
Also i don' want
Attributes are actually one of the biggest revolutions in computing IMHO.
Pascal has one of the oldest, and lets admit it not the prettiest syntax. If
we want to keep something in as un-pretty shape, we surely can, but should
it be a goal?
Adding new keywords to any language pollutes the languag
Am 22.09.2014 16:45 schrieb "Peter Popov" :
>
> How will referenced objects behave when referenced by a threadvar. This
is an exceptional situation for both dynamic arrays and ansi strings.
There is no need for special handling, afterall a threadvar is (roughly) as
if you had defined a variable lo
Am 22.09.2014 17:11 schrieb "Jonas Maebe" :
>
>
> On 22 Sep 2014, at 16:44, Peter Popov wrote:
>
>> Another comment: If referenced objects all derive from a single base,
then, the user cannot possibly have another hierarchy, which uses ref.
objects. As I mentioned earlier, I do this explicitly for
Am 22.09.2014 17:33 schrieb "Peter Popov" :
> I will add another comment to the race condition issues: they are easily
avoided by a single line assembly atomic inc/dec. It however will not
resolve performance issues where a certain function assigns classes
references left and right and there are mu
Am 22.09.2014 18:52 schrieb "Boian Mitov" :
>
> Attributes are actually one of the biggest revolutions in computing IMHO.
> Pascal has one of the oldest, and lets admit it not the prettiest syntax.
If we want to keep something in as un-pretty shape, we surely can, but
should it be a goal?
> Adding
Because it requires writing a lot more code, just to get the Ref. Count, and
as I stated in another mail, you don't have direct field access.
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
-
Hi Sven,
Yes I knew the problem in the latter approach. However my thinking is that
some features can be derived from others and I believe that this applies
here too.
So by adding these extension to records and the operator overload the
feature can be implemented as a library extension. Also thos
If you have anonymous methods, you don’t need parallel loops, as I have
demonstrated in my sessions.
We use anonymous method parallel loop, and parallel recursion easily, and with
greater flexibility than any language modification can achieve.
With best regards,
Boian Mitov
But it can be encapsulated in the anonymous object of anonymous method as it is
done with local (stack) variables already in Delphi.
Anonymous methods can and do use local variables, and are regularly returned as
result or passed to other threads.
That is the power of anonymous methods. I covered
In general, records and classes are inherently the same thing (and in C++ are
indeed practically interchangeable). The only real difference in Delphi/FPC is
that records are instantiated in the stack, the objects in the heap, and the
artificial restriction on record inheritance.
Now adding the o
Strongly disagree...
For multithreading and parallel processing ARC is lifesaver. I have been
using it trough interfaces for 10 years already, and once I rewrote the old
code to use ARC it was a huge performance boost, and it keeps getting
better.
Doing parallel processing without ARC is pract
Then the best option is Assembler.
There you really know what you are doing.
In ARC I also know perfectly what I am doing. It may be con for some, but
surely not for me ;-) .
Honestly if you don’t know what you are doing when using ARC, I doubt a bit,
you really know what you are doing otherwise
As I already stated, those are the same arguments that I have heard 30 years
ago when people ware asking me why I would use C instead of doing it like them
in Assembler.
later, why I would use C++ classes, when we has sructures in C++.
Why use virtual methods, in C++ instead of using the EC++ wit
I am not big fan of the compiler handling parallel loops, as it will limit
any flexibility in implementation.
A library based functionality with shared executors is a better design, and
it allows not only for parallel loops but also for easy parallel recursions
and many other combined(iterative/
Here is example from our implementation:
for AIndex := 0 to Length( AList ) - 1 do
AExecutionTask.Add(
FExecutor.Execute(
TDelegate.Capture( AIndex,
procedure( ALocalIndex : Integer )
begin
Sleep( 1000 ); // Simulate thread busy doing time c
BTW: Please note that since you can keep adding executions to the task, it
can be done in nested loops, as well as in function calls thus doing fully
fledged parallelization.
The executor also can be single thread, unlimited threads, self balancing,
or limited pool depending on the specific inst
On 09/22/2014 08:28 PM, Boian Mitov wrote:
> In general, records and classes are inherently the same thing (and in
> C++ are indeed practically interchangeable). The only real difference
> in Delphi/FPC is that records are instantiated in the stack,
Or on the heap:
==
Type
TMyRecord =
I know ;-) . I meant the default behavior.
Very much anything can be accessed and instantiated trough pointers :-) .
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
From: E
I suggest doing one thing at a time. ARC class first, complex delegates
capturing local context later
In my opinion having ARC class would be a great advantage. As far as I
know this feature was proposed many times in the past. Developers have
been asking for it for years. It just feels right
Hi
recently we ported a code using 4 dimensional variant array to fpc. The
code, originally in Delphi, used VarArrayLock/Unlock to get a handle on
the array and write directly on iy. It turned out that the layout is not
as it is in delphi, and we could not figure out what it was.
The quest
On 22/09/14 22:17, hinstance wrote:
> I am not even sure if weak reference feature is necessary. We don't have
> weak references for COM interfaces, and it still works so far.
That's because you can't have circular references between interfaces,
since interfaces don't have fields. Similarly, you c
On Mon, 22 Sep 2014 21:34:34 +0300, Boian Mitov wrote:
Strongly disagree...
For multithreading and parallel processing ARC is lifesaver. I have been
using it trough interfaces for 10 years already, and once I rewrote the
old code to use ARC it was a huge performance boost, and it keeps
g
The thing is that we have weak references for COM – standard pointer ;-)
ARC without optional weak pointers leads to guaranteed memory leak.
Simple example:
Parent calls with children, and child with pointer to parent. If the pointer to
parent is not weak, the objects will never be freed.
In COM
If you are experienced in parallel processing, you should know the answer.
This is a huge topic, and I have done number of sessions on some aspects of
it, but here will give you a small example (again this is just a small
example).
You have a data object that needs to be processed by 600 threads
Am 22.09.2014 22:23 schrieb "hinstance" :
>
> I suggest doing one thing at a time. ARC class first, complex delegates
capturing local context later
Considering that those are two different features that don't have anything
to do with each other their development doesn't need to be serialized, but
Actually, although on first glance different, anonymous methods are done as
reference counted objects in Delphi, (well technically trough interfaces.), so
since the anonymous method storage by definition has to be kept alive trough
reference counting or similar approach, the topic is not that de
Sven Barth schrieb:
Am 22.09.2014 12:59 schrieb "Hans-Peter Diettrich"
> That's why I also suggested an compiler option, useful for all people
which care about program size or ARC at all.
The problem with the compiler option is that you'd need to rebuild the
complete RTL, packages and your
Boian Mitov schrieb:
In general, records and classes are inherently the same thing (and in
C++ are indeed practically interchangeable).
This model might have been the reason for introducing Object at all, for
compatibility with CBuilder.
The only real difference in
Delphi/FPC is that record
Because TObject always has virtual table as example, and you can't use
anything inherited from it to map into communication header.
Structures on another hand by default start from empty hierarchy, and do not
have Virtual Table pointer so I can create a structure and send it to a
socket for tran
On Mon, Sep 22, 2014 at 07:21:46PM +0200, Sven Barth wrote:
> Am 22.09.2014 17:11 schrieb "Jonas Maebe" :
> >
> >
> > On 22 Sep 2014, at 16:44, Peter Popov wrote:
> >
> >> Another comment: If referenced objects all derive from a single base,
> then, the user cannot possibly have another hierarchy,
Because none of those is a strong typed language.
Each language has weak and strong points.
Pascal is semi strong typed language, and as such is very well declarative
style oriented.
Functional programming however merges very well with strong typed
declarations actually getting us closer to the
On 22.09.2014 23:37, Boian Mitov wrote:
Actually, although on first glance different, anonymous methods are done
as reference counted objects in Delphi, (well technically trough
interfaces.), so since the anonymous method storage by definition has to
be kept alive trough reference counting or sim
On 23.09.2014 02:24, John Briggs wrote:
Why has there been so many messages on this list debating the pros and cons
of reference counting objects?
The beauty of the Pascal language is in its structure ie:
procedures,functions,OOP. Why does it need to be a functional programming
language as well
71 matches
Mail list logo
