At 08:50 PM 7/13/2018, you wrote:
<URL: https://rt.cpan.org/Ticket/Display.html?id=125472 >
2018-07-07 22:46 GMT+08:00 huck :
>
> Yes, as we saw when code disposal was introduced , even existing
> applications can be ruined if care is not properly taken. Maybe if
> create_tcl_sub() had been documented as part of the api this problem would
> not have been created in the first place.
>
I think it had not been because create_tcl_sub() was created for
internal use only and not intended to be an API.
Maybe if it had been documented the original code disposal changes
would not have busted existing programs like they did.
I also find it hard to believe that just because something was one
designed for internal use it means it can never be exposed as part of the API.
create_tcl_sub() is now integral to the code disposal changes. It is
the place that code disposal is now controled. allowing external
access to it is basically the only way to allow the developer to
control code disposal.
>
>>
>> My idea is to apply a prefix to identify if first argument of call() is a
>> DESCRNAME. If the first arg call() is '%' , then it is a DESCRNAME. (Let's
>> forget previous AT sign '@' example, which might confuse you).
Otherwise the
>> first arg is a tcl verb. For example the following code:
>>
>> call('%button1', ..., $sub1, sub{})
>> call('%button1', ..., $sub2, $sub3)
>> call('if', '1', $sub3)
>> :
>> code_dispose('button1');
>>
>> Then inline sub{}, $sub1 and $sub2 would get disposed while #sub3 is kept.
>> The code looks much cleaner compared to annoying TCLNAME/GENCODE/EVENT
>> dealing and storing. Here one DESCRNAME maps to multiple $subs,
which is not
>> allowed in current implementation. Just share an idea for a
better disposal
>> interface.
>
>
>
> And how would you implement this via Tkx?
> for instance how do you modify a $menu>add_command(%args); call?
> or $button =$in->new_ttk__button(-text=>$args{text},
-command=>$args{sub} );
>
It's not for Tkx user. It's for Tcl user (such as Tkx). Tkx can
associate a unique DESCRNAME 'menu1' with an object $menu and call
code_dispose('menu1') on destroyer of $button1.
Ya know i dont care much about the Tcl only user. I use it from Tkx,
somebody busted tkx. i fixed it. QED.
Who is going to make the changes to Tkx to do this? How do i pass
this information from my program to tkx to do it? Right now tkx is a
simple intercept interface between perl and ttk. Basically a tkx
developer does not interface with call() at all. How do you propose
they do it under your scenario?
My WORKING solution allows the tkx user to get access to code
disposal via create_tcl_sub(). I dont hear any solutions from you ,
just proposals.
And what destroyer of $button1 are you talking about? can you show me
where Tkx sets up a destroyer for a button? Or are you proposing that
someone come up with the new code? Are you going to do it?
tkx just recodes a perl call into the corresponding tk name and calls
that tk procedure.
In previous example, $sub1, inline sub{}, $sub2 get disposed when
code_dispose('button1') is called. They get disposed because they are
associated with DESCRNAME 'button1' via call('%button1'). $sub3 is
also associated with 'button1', it does not get disposed because it
has also been call()'ed once without DESCRNAME.
It is never called without a DESCRNAME, call() always assigns a
DESCRNAME when it calls create_tcl_sub(), i think your proposal to
add a leading argument to call() has not been well thought out yet.
The arguments to call() are very well defined now, they constitute
the elements of a call to tcl, now you want to majorly modify what
the arguments are for no good reason i can figure out so far.
> like you said before if you dont know what to do with EVENT it can be
> defined as undef, and then TCLNAME is the same as GENCODE (as the doc says)
> and only that one item needs to be saved, just like you need to save the
> CMDNAME passed to CreateCommand ()
>
> Changing the existing and working interface to call() seems to be much more
> error prone than documenting the interface to create_tcl_sub(), just making
> things more complex.
>
> As i already mentioned by using create_tcl_sub() to manage code disposal, i
> can just add one call to create_tcl_sub() to lock down a sub from code
> disposal, and add another call to _code_destroy() when i want to release
> that coderef. Your proposed method requires every call with a
coderef to be
> modified which was one thing i was trying to avoid.
>
> And you say "would get disposed", but when? the only time code may get
> automagicly disposed is when something has the same DESCRNAME, but here you
> propose allowing DESCRNAME ot have the same value over multiple calls, are
> you proposing that inside the second call $sub1 and sub{}) get disposed?
> or are you proposing that $sub3 gets added to that list for disposal later?
>
> And a DESCRNAME can have more than one sub attached to it since v1.06 What
> it is is that when the same DESCRNAME is seen again, the prior code calls
> are now eligible for code destruction. One change i made is to delay code
> destuction untill after the entire command is parsed, so as not to have to
> destroy/recreate a coderef that already exists in both the current and the
> prior call with the same DESCRNAME This wasnt a problem at v1.02 because
> %anon_refs was only assigned to if the TCLNAME did not exist already
>
>> BTW, I found _code_dispose() has to be called in the form
>> 'Tcl::_code_dispose(...)' rather than '$interp->_code_dispose(...)'. It is
>> documented, but it is counter-intuitive. Programmers can hardly find their
>> incorrect calling via $interp object. I suggest to check input
parameter and
>> provide some warning at least. IMO, %anon_refs{} would be
better an object
>> instance variable instead of global one.
>
>
>
> but it isnt an object instance now, as far as i can tell never has been, So
> the change you are proposing here is not trivial. What should it be an
> instance of?
>
> While $interp can be considered an object all it is really is a blessed
> scalar. So where do you propose you store this new object instance? If we
> make $interp be the first key to %anon_refs that will cause a lot
of code to
> need to be changed.
>
> And as i pointed out while delete_ref() is called with an $interp for the
> most part that doesnt matter, since the $interp stored in the Tcl::Code
> object is used for the deletion, and while there could be many different
> interpreters, there is only one %anon_refs, so that on a single TCLNAME can
> exist, there cannot be one for each interpreter.
I mean %anon_refs shall be better to be something like
$interp->{anon_refs}. Different interpreters shall be better have
separated TCLNAME/CMDNAME/DESCRNAME naming space. It does not make
sense that TCLNAME/DESCRNAME have to be unique across different
interpreters.
It is not that way now, and as far as i can tell it was never that
way ever. What you are asking for is not a simple change to make,. it
changes a lot of things.
my $inter=Tcl->new(); print Dumper($inter);
$VAR1 = bless( do{\(my $o = 149405600)}, 'Tcl' );
there is no place for $interp->{anon_refs} to live. it is just a
blessed scalar.
Have you even looked at the code at all yet?
> Again, maybe the solution is to make a RFP asking for input on code
> disposal, what it should do, how it should be called and what modification
> will be needed to existing code. Without that my intentions were to make it
> so existing v1.02 code still worked, and there was a mechanism to control
> code disposal. I think my patches have met both of those goals. (and as i
> watched code disposal in action i realized it was destroying/recreating tcl
> subs over and over and i wanted to prevent that too)
>
> and i also realized that a deep bug in the xs code was leading to a massive
> memory leak and fixed that as well.
Yes I believe v1.06 got quite some bugs fixed. Here just some
discussion for any possibility to make interface more clean.
Yes my fixes have made v1.11 working again. All is working at least
like it used to and there is elementary code disposal for 'after'
calls like intorduced after v1.02.
All i see is trying to make the interface more complicated, without
proposing any code changes yourself. You want to change what $inter
is, from a blessed scalar to a blessed hash. you want to change how
call() is defined, yoiu are proposing major changes to tkx.pm that
will complicate it by introducing some sort of interface between all
the perl and tcl calls that will create destroyers.
So are you proposing to pay me to do all this or are you going to do
it yourself?
I think the easiest thing here is for you to make your own branch and
put in the changes you want, show me the working code that passes all
the tests. Then explain how it is cleaner, and why it is any better
than what we have now. I have no desire to do something just because
you want it done.
I wanted to get my tkx programs working again, i put the time in to
make it so, and i think i did a much better job than what you have
proposed so far. It you can do better than go right ahead.
My proposal for you is to start with a statement of what you want
code disposal to do. then describe how you will modify tcl.pm to do
that, then describe how you will modify tkx.pm to incorporate that
path. Once you have reached that point publish your proposal and see
what comments you get back.
Then you can go in and study v1.02 and v1.05 and see what changed,
once you have reached that point you can start making the
improvements to the code. Then you can publish a patch so we can
install it to a local branch and see how it works.
Again, my purpose when I took on this task to make tcl better than it
was because for no fault of mine my programs stopped working. I spent
a lot of time looking thru the code and learning how to think like
the authors did when they wrote their code. The change from v1.02 to
v1.05 was not minor, It changed a lot of how %anon_refs was used. My
fix incorporates the original design of %anon_refs tracking the
TCLNAME so it doenst constantly redefine perl <->tcl coderefs, it
also tracks the new DESCRNAME used for code disposal purposes, I does
not redefine a TCLNAME that currently exists, and only destroys it
when all the registered users of that TCLNAME have been
eliminated. I joined the original v1.02 and the v1.05 code in a way
that satisfies the purposes of both of them
It requires no changes to existing tcl/tkx programs or to tkx.pm to
work properly.
It also allows for developer access to this code disposal procedure
via create_tcl_sub() so they can have a say in how code disposal
works for them.
SJ
