Tcl/TK is indeed dying
in [TCL]
|
Prev: www.prevayler.org anyone do an in ram data base with transactionlog in tcl?
Next: accessing GUI with TWAPI (was: Accessing GUI of CAD through Tcl/Tk)
From: Sean Woods on 18 Dec 2009 09:22 On Dec 16, 9:06 am, MSEdit <mse...(a)gmail.com> wrote: > I am not sure where all this bloat you are seeing comes from. > > My 8.6 full GUI binary is 90k bigger than my 8.5.7 binary for me 90k > is not bloat. > > Martyn Hey 90k used to be a huge deal. Back when we were dealing with 120k floppies. When I was a lad. And we had to walk uphill both ways to school...
From: tom.rmadilo on 18 Dec 2009 12:55 On Dec 18, 12:38 am, Rodericus <sc...(a)web.de> wrote: > On 17 Dez., 17:00, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > > > But it should be pointed out that this particular form of goto isn't > > in any way unstructured, the original code in C and my use are > > designed as an efficient loop contained within a single procedure (so > > many function calls and variable passing are avoided). [...] > > I never came to the idea of jumping from to an uncalled procedure, is > that possible in C? > How are the local variables of the new procedure set? As Donal said, this is beyond the abstraction of the C language, but isn't impossible. It is about as safe as browsing the internet. You can use non-recursive function calls in C and still use goto in the main function. Anyway I never suggested jumping to another function, I suggested changing the code run within a label, in C you just us a function pointer instead of a name. The way you "share" variables in C is to declare/define them outside the functions, usually at the top of the file (the variables will be shared with all functions in the file). I just added an example of this style, again using a sudoku exact cover algo, this time without backtracking. This required two helper procs and a few shared variables: http://www.junom.com/gitweb/gitweb.perl?p=sd.git;a=tree;f=test The .c and .tcl file named no-backtrack-exact-cover In Tcl you just use a namespace, but you have to add the [variable] syntax inside each tcl proc. One good reason to use this type of algorithm, instead of a recursive method is to run inside of a fixed memory and stack space. > > But the fact that code can shift under your feet in Tcl means that you > > can't implement a [goto] which is implemented anything like your > > program counter. > > Yes, there may be a problem. Not really a problem. I haven't shown any uses of goto which are really an abuse. Truth is you can abuse anything. On further analysis of the original C code, I noticed that the backtracking step "abused" the fact that C will just continue on working even if a function returns an error, or if you try to access uninitialized array indexes. (In this case, the zero indexes are unused.) Tcl still complains when you do this, but has stopped complaining if you try to increment an uninitialized (non-existing) variable. This is an area where you could have an honest disagreement about bloat. Is is better to force users to initialize variables prior to use? This seems to bloat every application. If you initialize on first use, user code is less bloated...at least initially. But now the bloat is in the internal code which handles the initialization. This bloat only handles the special case, so you are stuck with any non-default initializations. I think the right decision was made in this case: you can't force users to write good code, but if you can make most code easier to write, then more time is available for the hard parts.
From: Helmut Giese on 18 Dec 2009 13:27 >Popularity and survival are not synonymous. A company is not going to >take 10 years of R&D and re-write it from scratch into something else >simply because it's not en vogue. > >(Pause) > >Ok, we can all stop laughing. LOL (just starting). What did you have in mind?
From: Tcl Bliss on 18 Dec 2009 16:21 On Dec 18, 2:53 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > On Dec 15, 7:33 pm, Tcl Bliss <tcl.bl...(a)gmail.com> wrote: > > > > > One very visible major shortcoming, IMHO, is a flaky support of > > command line history browsing. Most modern scripting languages support > > readline but in TCL it doesn't work by default and requires a good > > effort to make it work. I have not been patient enough lately to make > > it work. Of course, I can use Tkcon but not when I ssh to a remote > > system, which I do a lot. > > Uh, on Windows it works out of the box, and on major Unices you can > use the universal readline wrapper "rlwrap". > Not reinventing the wheel is a rather smart choice when people are > worrying about bloat (and I do worry about bloat from time to time). > > -Alex Thank. Works great. I wasn't aware of "rlwrap" until now.
From: Rodericus on 18 Dec 2009 16:48
On 18 Dez., 18:55, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > As Donal said, this [jump to other funktion] is beyond the abstraction of the C language, but > isn't impossible. From Kernighan Ritchie's book: "A label has the same form as a variable name, and is followed by a colon. It can be attached to any statement in the same function as the goto. The scope of the label is the entire function". This means, by definition of C is a goto to other procedure not allowed. If it is possible, then due to a bug in the compiler (it should give an error) or due the hacker exploiting the bug. It stays also: "Although we are not dogmatic about the matter, it does seem that goto statements should be used rarely, if at all" The authors were aware of the dogmatic discussions. >> How are the local variables of the new procedure set? > The way you "share" variables in C is to declare/define them outside the functions, But then they are not anymore local. There is also no memory allocated for the arguments of the function, that are also local: this is done when calling the function, and this do not happend when you jump inside. I could not reach the link: > http://www.junom.com/gitweb/gitweb.perl?p=sd.git;a=tree;f=test > you can't force users to write good code, but if you can make most code easier to > write, then more time is available for the hard parts. I agree. Rodrigo. |