Activity for Don Porter
-
Don Porter modified ticket #291
memory leak in ItclCreateArgList function
-
Sure looks like this was fixed more than 2 years ago. Upgrade to fix. https://core.tcl-lang.org/itcl/info/0b0d0e0b8cd8105c
-
That said, the routine ItclCreateArgList() in current development certainly includes ckfree() calls on both argv and defaultArgv. Can you specify the code path that misses those calls and leaks?
-
~~~ All work on Itcl 4.0.* is abandoned. Upgrade to Itcl 4.1.2 or development trunk.
-
Once I set up a testbed with all those outdated releases on an OSX High Sierra system, my testing shows no failure running the test script. Sorry, but there continues to be nothing I can do when I cannot reproduce the failure.
-
When an ItclMemberCode improvement is done, we'll want you to try it and determine how much it helps you.
-
Looks like the next low-hanging fruit in preserve elimination is ItclMemberCode. Give it a proper refcount as we've done with several other structs now.
-
Sorry, no. At base that implementation also calls Tcl_Preserve.
-
There's a build option in Itcl, ITCL_PRESERVE_DEBUG that makes it use its own implementation instead of a call to Tcl_Preserve. It's possible that will have a different performance impact.
-
~~~~ Ok. It's only in the implementation of Itcl_PreserveData(), but that still gets significant use.
-
~~~~ I see only 3 calls to Tcl_Preserve() left in the Itcl trunk of development. You're really seeing one or more of them account for significant runtime? Please tell more.
-
Confirmed I see factor of 4 slower operation in Itcl 4.1.1 compared with 3.4.4. No idea yet whether there's anything reasonable that can be done about it.
-
I don't think it's a bug, no. I think it's intrustion into an implementation detail. If there's documentation otherwise, let me know.
-
ok, I see. "proc: -> "itcl::body" makes it work ok.
-
Indeed these test scripts do not run in Itcl 3.4.4. That's what I'm willing to test.
-
This is probably related: http://core.tcl.tk/tcl/tktview?name=3610400fff
-
~~~~ This change is due to a re-implementation in terms of [tailcall]. Here's a Tcl-only demonstration: % proc cb args {puts TRACE:$args} % proc demo {} { tailcall string cat x } % trace add execution demo leave cb % demo TRACE:demo 0 {} leave x If execution traces and [tailcall] are not supposed to interact this way, it's a matter to get resolved in Tcl itself.
-
Maybe we can try this with one focused, working example at a time?
-
Demo script doesn't work: invalid command name "GetSingleton" while executing "GetSingleton" (procedure "CWithProc::CallSomeMethod" line 2) invoked from within "CWithProc::CallSomeMethod" invoked from within "time {CWithProc::CallSomeMethod} $count" (procedure "test_calls_to_singleton_via_class_proc" line 2) invoked from within "test_calls_to_singleton_via_class_proc" (file "/home/dgp/sf271.tcl" line 274)
-
"info vars" fails with no pattern
-
Fix committed to trunk. Will be in Itcl 4.1.2
-
Don't know why it wasn't clear before, but this is a simple fix.
-
$ tclsh % dict get [namespace ensemble configure info -map] vars ::tcl::info::vars % package require Itcl 4.1.1 % dict get [namespace ensemble configure info -map] vars ::itcl::builtin::Info::vars
-
The "dgp-method-type" branch has become the Itcl 4.1.* branch which is now the trunk, so this needs a solution.
-
Fixed for Itcl 4.1.2
-
Protected common variables not visible to children
-
Fixed for Itcl 4.1.2
-
Throwing an error from within an itcl::ensemble causes a segmentation fault (core dump)
-
By all appearances, in the entire Itcl 4 development history, this just hasn't been done. I suspect it's not hard to do, but I'm not ready to predict a completion date. You can keep using Itcl 3.4.4 with Tcl 8.6 in the meantime.
-
Itcl_InvokeEnsembleMethod is failing to set a ProcErrorProc.
-
application error when using combobox dropdown
-
Dup of bug 115. Already fixed.
-
Obsolete references to "@itcl" syntax
-
Obsolete references to "@itcl" syntax
-
Extra quote in "scope" error message
-
fixed for Itcl 3.4.4 and 4.1.1
-
It appears this is an error inherited from Itcl 3.
-
tclconfig is a separate project core.tcl.tk/tclconfig/ See these instructions http://core.tcl.tk/itcl/wiki?name=Tracking+Itcl+Sources
-
ok, now synced.
-
Improvement committed to trunk. See what you think.
-
Guess we had the same plans for a Sunday afternoon. Will tackle this soon.
-
Object creation/deletion speed and memory usage
-
Well this may not be too bad. The line that creates the trouble is: https://core.tcl.tk/itcl/artifact/cf873c608adaa772?ln=272 Itcl_PreserveData() is crude and inefficient. It needs replacing with an appropriate refcounting scheme directly on the ioPtr argument.
-
On 10/27/2017 11:19 AM, Tim Tomkinson wrote: This is still a problem with Itcl 4.1.0. Itcl 3.4's object creation time is constant at about 2 µs, while Itcl 4.1.0's time increases linearly (see attachments). Is this going to be too difficult to fix based on Itcl 4's internal design? Looks like object creation must still be doing something linear in the number of existing objects. Any idea what that is? -- | Don Porter Applied and Computational Mathematics Division | | donald.porter@nist.gov Information...
-
"is object -class" fails in namespace
-
Fixed for Itcl 4.1.1
-
Confirmed. Appears this has never worked in the Itcl 4 development series.
-
iwidgets fails for TCL 6.4.5
-
I am sorry to report that my builds of all those packages on an OSX Sierra system do not demonstrate a crash on the submitted script. If you can supply more information, I can try again, but if I cannot reproduce the trouble I cannot really begin to chase down what might be the problem.
-
Thank you for a good report. The demo script seems to work fine on a linux system. I will try on an OS X system later when I am on one. Perhaps next week. My underinformed guess at this point is you've run into some platform-specific trouble in Itk 4.1.0. or possibly Tk 8.6.6. If you have time to blindly try things, you might look into using Tcl/Tk 8.6.7 and/or Itcl/Itk 4.0.6. Will be able to give better answers after I reproduce the trouble. Should I expect a crash each time?
-
iwidgets 4.1.0 configure error in line 6515
-
I committed a refreshed tcl.m4 and the resulting new configure file to the HEAD of iwidgets. Can you check if they work any better?
-
One thing we can blindly try is to just sweep into place an updated tclconfig/tcl.m4 from the current tclconfig project and see if this is some ancient problem fixed long ago.
-
No, perhaps not. That line in the configure file is not new. This is going to require someone on a Windows system to debug.
-
This appears to be a consequence of adding TEA_CONFIG_CFLAGS([]) to configure.in
-
configure error on latest trunk
-
The "configure" file on the Itcl trunk does not have that content on line 6515. It also doesn't appear to have any lines with both substrings "ac_space" and "grep". Can you help pinpoint the precise sources and conditions that lead to the failure? http://core.tcl.tk/itcl/timeline?y=ci
-
You say "latest trunk". Is the same problem present in the Itcl 4.1.0 release? If so, is the Itcl 4.0.6 release any better? If not, what was the latest Itcl release that worked in this environment?
-
iwidgets 4+ with Tcl/Tk 8.6+
-
This is a place where the iwidgets::combobox was still relying on Tcl to accommodate its programming errors. In release 8.6, Tcl stopped doing that. The fix for this particular problem is to change line 1261 of combobox.itk from [itcl::code $this _selectCmd] to eval [itcl::code $this _selectCmd] More examples of this problem may lurk. Committed to CVS for Iwidgets 4.1.1 whenever that may come.
-
Something to check.. Try adding this package require Itcl 3.4 package require Itk...
-
Try current releases. If that fails, try trunk. This smells like a known and fixed...
-
I don't have any reason to believe that the changes since the release of Itcl 4.0.5...
-
a few more patches fixing flaws discovered along the way.
-
Just committed to trunk a patch that plugs all leaks I could find when Itcl is used...
-
I have a test script now. Appears to be something in a method that is leaking.
-
Telling me clearly that multiple Tcl threads are involved. I think that's what I...
-
Thank you for these submissions. I'd like to adopt them, but for my own process,...
-
Good advice. I just ran this test script: package require Itcl itcl::class A { public...
-
Cycles of creation/deletion of instances of an empty class now appear leak free....
-
Timeline for Itcl development is here: http://core.tcl.tk/itcl/timeline Over the...
-
~~~~ Reading between the lines above, if there's a demo of a leak in Tcl's own oo::*...
-
You typo'd that, right? 8.6.5 and not 8.5.6 ?
-
ok, I did a simple check, and there does appear to be a possible leak to track down...
-
If that's not a typo, then updating to Itcl 4.0.4 will help you a lot. Maybe not...
-
constructor namespace
-
This matter is part of constructor invocation, and is closely related to http://core.tcl.tk/itcl/tktview?name=ec215db901...
-
Found a fix that works interactively, but not in a test suite(?!?!) Exploring that...
-
In Itcl 3, compare with: % itcl::class C { inherit A } % C #auto :: c0 We seem to...
-
Trying for myself I see that Itcl 3 thinks the uplevel namespace is ::B While Itcl...
-
Are those results supposed to be blank?
-
Namespace collision
-
Missing method error is incorrect
-
"scope" failure
-
I suspect that your bug report and my bug fix crossed each other in the stream. http://core.tcl.tk/itcl/info/0bd3e2c8fb03aaa4...
-
Update "scope" manual page
-
The value returned by scope had also become incorrect in light of the fix to bug...
-
Instantiating object within class definition crashes
-
Fixed the problem with Itcl 3. Then replaced the panic with acceptance. Will have...
-
Ok, check this out: % package require Itcl 3.4 % itcl::class C { C ::x } % itcl::delete...
-
Well, this is a weird thing to do, I think. The demo script is creating a command...
-
Destructor error corrupts object
-
fixed on trunk
-
This is not a recent regression. Any guidance on what the right behavior ought to...
-
Recursive class procedures corrupt stack
-
fixed.
-
This is a botch in the "fix" for bug 272.
-
In the reported case, indeed, replacing simple names with fully qualified names could...
-
Namespace class deletion error
-
Trouble here is that some of class teardown is accomplished via delete traces on...
1 >