Hi Trevor,

Twylite wrote:
>  Jeff Hobbs wrote:
> > You speak as one who has likely never tried TDK (TclApp in particular, 
> > but also tclchecker for the static analysis), is that right?  While it 
> > isn't a panacea, or end-all-be-all (there are a couple tricks I'd like 
> > to do still), it is better than solutions that other languages 
> > provide.  TclApp is based on tclkit technology of course.
> >
>  We started evaluating TDK for our last project but didn't get very far.  
>  First because this was in February-April last year and we intended 
>  delivering on HEAD/8.5 (for which there was no clear roadmap), and 

Yes, that was prior to proper 8.5 support in TDK (especially since 8.5.0 
wasn't out until December, and things did change).

>  second because of the $249 (iirc) price tag (times 5 developers).  
>  Actually the price could have been $1 and it would have been just as 
>  hard to get purchase approval (less than 2% of our developers use Tcl 
>  and this would be an international transaction, so we're talking months 
>  due to various policies and legal requirements).
>  The nails in the coffin were two core bugs  that we discovered as we 
>  were wrapping up the previous project (also based on HEAD/8.5): a leak 
>  in mutex handling (#1726873) and an interp bug (#1658572).  Our only 
>  option to deliver on time was to deploy a build of Tcl from CVS with our 
>  patches added.  Our team works in a lot of environments and we're 
>  encountered compiler bugs in MSVC and various embedded C products, but a 
>  workaround is usually possible.  VM bugs in Java or interpreter bugs in 
>  Tcl are often impossible to work around.  In fact we'd been in a similar 

Yes, they often require patching - but it is open source, and the 
advantage you have seen is that you could patch yourself.  ActiveState 
also provides full support services on top for those companies that 
require Tcl to "just work" without wanting to distract themselves by 
code-diving into the sources.

>  situation a year before on 8.4 with a string/UTF8 bug that we found 
>  (#1410553).  So the sensible decision was to ensure that we could always 
>  be in a position to deploy a CVS or custom build if the need arose.
>  
>  We thus deployed a RYO solution based on 8.5a4 and experience gained 
>  from some painful experiences with our TclKit 8.4 environment (in 
>  particular accidental use of packages we weren't intended to use, and 
>  missing packages in the wrapped EXE).

I'm happy to see that all the bugs you noted are fixed in the current 
sources ... but delivering product on 8.5a4 ... that is brave.  Is your 
test cycle so long that moving to 8.5.2 now isn't an option?

>  I was pretty impressed with tclchecker from what I saw, and we've also 
>  tried nagelfar.  Both tools missed a number of callbacks (scripts passed 
>  to functions) and variables that were defined by upvars or uplevel.  In 
>  a test on an older source file that had subsequently undergone peer 
>  review tclchecker picked up some problems that the review had missed, 
>  and missed some problems that the review had corrected (logic bugs 
>  excluded, of course).

Note that tclchecker also received numerous updates in the TDK 4.x 
release, so hopefully it is better now.  There are limitations to even 
the static checking with callbacks and other bits that would require a 
high level of inference and guesstimating intentions.  As dynamic as Tcl 
is, static analysis can be tricky.

Regards,

Jeff

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core