Stubs and a minicore.. how to do?
David Gravereaux
should I handle Stubs? Leave the holes as a NULL? I wouldn't want to change
the positions. All the UTF stuff is ingrained so deeply. I'm trying to look
into stripping UTF completely out from 8.4 .
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 7.5 year ping times when placing a call from alpha centari
Bob Techentin
>
> Let's say a attempt to trim Tcl a bit and chop out parts I don't like. How
> should I handle Stubs? Leave the holes as a NULL? I wouldn't want to change
> the positions. All the UTF stuff is ingrained so deeply. I'm trying to look
> into stripping UTF completely out from 8.4 .
Hi David,
I've noticed a few recent posts and threads with this same basic idea.
Unfortunately, the response seems to generally be "Geee. Stripping all
that stuff out of Tcl would be hard. Have you looked at TinyTcl or Tcl
7.6?"
I've occasionally wondered if it might make more sense to recreate a
small Tcl implementation that includes just the basics of the Tcl
language, but an implementation into which all the new, cool (and bulky)
stuff could be inserted. Building from the ground up, instead of either
regressing or chopping.
I'm not entirely sure what would constitute "just the basics". It might
be as simple as just eval, set, for, if, case, interp, join, and a few
others. Everything else would be drop-in packages, including I/O,
files, channels, arrays, event loops, regular expressions, byte-code
compilation, and even encodings.
A "small" Tcl implementation which could optionally support UTF would
need to be cleverly architected. You would need to use something like
Jacl's approach, which uses a real object for Tcl_Obj, and techniques
like abstract factories and careful interface abstraction to create a
core that could work with or without encodings.
I've just taken a look at Jacl with Source Navigator, but I haven't the
ability to reverse engineer Java into UML diagrams. Would anybody else
out there be interested in exploring object oriented architectures for
Tcl which could support this kind of implementation?
Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.mayo.edu/sppdg/
David Gravereaux
>David Gravereaux wrote:
>>
>> Let's say a attempt to trim Tcl a bit and chop out parts I don't like. How
>> should I handle Stubs? Leave the holes as a NULL? I wouldn't want to change
>> the positions. All the UTF stuff is ingrained so deeply. I'm trying to look
>> into stripping UTF completely out from 8.4 .
>
>Hi David,
>
>I've noticed a few recent posts and threads with this same basic idea.
>Unfortunately, the response seems to generally be "Geee. Stripping all
>that stuff out of Tcl would be hard. Have you looked at TinyTcl or Tcl
>7.6?"
Yes, but I'd like to base a branch from the current HEAD. Merging it, would be
a whole lot easier and, yes, I do realize its more work.
>I've occasionally wondered if it might make more sense to recreate a
>small Tcl implementation that includes just the basics of the Tcl
>language, but an implementation into which all the new, cool (and bulky)
>stuff could be inserted. Building from the ground up, instead of either
>regressing or chopping.
If one team starts at the bottom and another at the top, meeting in the middle
would be an interesting exchange.
>I'm not entirely sure what would constitute "just the basics". It might
>be as simple as just eval, set, for, if, case, interp, join, and a few
>others. Everything else would be drop-in packages, including I/O,
>files, channels, arrays, event loops, regular expressions, byte-code
>compilation, and even encodings.
See generic/tclBasic.c for the TCL_GENERIC_ONLY macro, and what it blocks. I
can't create a shell with just that stuff. It's a wash in cross dependencies to
mainly Tcl_UniChar and friends. I can't even remove the file system.
One place that's interesting is generic/tclAsync.c . Tcl_AsyncMark is truly
just for outside use in the API and not used inside the core. I can't just
remove it though, or I get this:
tclBasic.obj : error LNK2001: unresolved external symbol _Tcl_AsyncInvoke
tclParse.obj : error LNK2001: unresolved external symbol _Tcl_AsyncInvoke
tclNotify.obj : error LNK2001: unresolved external symbol _Tcl_AsyncInvoke
tclExecute.obj : error LNK2001: unresolved external symbol _Tcl_AsyncInvoke
tclBasic.obj : error LNK2001: unresolved external symbol _Tcl_AsyncReady
tclParse.obj : error LNK2001: unresolved external symbol _Tcl_AsyncReady
tclNotify.obj : error LNK2001: unresolved external symbol _Tcl_AsyncReady
tclExecute.obj : error LNK2001: unresolved external symbol _Tcl_AsyncReady
tclEvent.obj : error LNK2001: unresolved external symbol _TclFinalizeAsync
Next step would be to wrap the use of the Async API within a compile-time
switches:
void
Tcl_FinalizeThread()
{
ExitHandler *exitPtr;
ThreadSpecificData *tsdPtr =
(ThreadSpecificData *)TclThreadDataKeyGet(&dataKey);
if (tsdPtr != NULL) {
/*
* Invoke thread exit handlers first.
*/
tsdPtr->inExit = 1;
for (exitPtr = tsdPtr->firstExitPtr; exitPtr != NULL;
exitPtr = tsdPtr->firstExitPtr) {
/*
* Be careful to remove the handler from the list before invoking
* its callback. This protects us against double-freeing if the
* callback should call Tcl_DeleteThreadExitHandler on itself.
*/
tsdPtr->firstExitPtr = exitPtr->nextPtr;
(*exitPtr->proc)(exitPtr->clientData);
ckfree((char *) exitPtr);
}
TclFinalizeIOSubsystem();
TclFinalizeNotifier();
#if TCL_NOASYNC == 1
TclFinalizeAsync();
#endif
/*
* Blow away all thread local storage blocks.
*/
TclFinalizeThreadData();
}
}
At least that one is easy. And we could do levels of stripping as macros just
to be nice containers.
#ifdef TCL_MINICORE
# define TCL_NOASYNC 1
# define TCL_NOFILECHAN 1
# define TCL_NOUNICODE 1
# define TCL_NOSERIALCHAN 1
# define TCL_NOSOCKETCHAN 1
...etc
#endif
Pretty crazy, eh?
>A "small" Tcl implementation which could optionally support UTF would
>need to be cleverly architected.
Oh boy. I'm starting to see it.
> You would need to use something like
>Jacl's approach, which uses a real object for Tcl_Obj, and techniques
>like abstract factories and careful interface abstraction to create a
>core that could work with or without encodings.
>
>I've just taken a look at Jacl with Source Navigator, but I haven't the
>ability to reverse engineer Java into UML diagrams. Would anybody else
>out there be interested in exploring object oriented architectures for
>Tcl which could support this kind of implementation?
>
>Bob
--
David Gravereaux
>#if TCL_NOASYNC == 1
> TclFinalizeAsync();
>#endif
Cute typo on my part.. please reverse the logic there ;)
Volker Hetzer
> I'm not entirely sure what would constitute "just the basics". It might
> be as simple as just eval, set, for, if, case, interp, join, and a few
> others.
"Basics" should IMHO be the command structure, Dollar sign, [], {}, ""
and the semicolon. Every tcl command should be strippable from
the interpreter so that one could create a embeddable language
supporting only three or four commands provided by the developer and
especially no loops, procs or other dangerous things.
Maybe one should approach the problem from another angle and try to
extract the parser instead of trying to remove commands?
> Everything else would be drop-in packages, including I/O,
> files, channels, arrays, event loops, regular expressions, byte-code
> compilation, and even encodings.
Is it still possible to remove the bytecode compiler without replacing
it by some other text interpreter?
> A "small" Tcl implementation which could optionally support UTF would
> need to be cleverly architected.
I think UTF should not be taken out. It's part of the basics of
the language. And it makes sense for embedded stuff too, like
native error messages.
Greetings!
Volker
--
Das meiste Geld habe ich fuer exklusive Restaurants, schnelle Autos und
teure Frauen ausgegeben. Den Rest habe ich verplempert.
David Gravereaux
>Bob Techentin wrote:
>> I'm not entirely sure what would constitute "just the basics". It might
>> be as simple as just eval, set, for, if, case, interp, join, and a few
>> others.
>Much too much.
>"Basics" should IMHO be the command structure, Dollar sign, [], {}, ""
>and the semicolon. Every tcl command should be strippable from
>the interpreter so that one could create a embeddable language
>supporting only three or four commands provided by the developer and
>especially no loops, procs or other dangerous things.
>
>Maybe one should approach the problem from another angle and try to
>extract the parser instead of trying to remove commands?
The parser is just fine the way it is, IMO. That is what defines Tcl as Tcl.
What has to go are some of the subsystems. For me, the channel API would stay,
but the file and socket stuff would be chopped. Same for serial. I plan to put
different channel drivers there implementing different stuff.
>> Everything else would be drop-in packages, including I/O,
>> files, channels, arrays, event loops, regular expressions, byte-code
>> compilation, and even encodings.
>Is it still possible to remove the bytecode compiler without replacing
>it by some other text interpreter?
I would leave that and the Tcl_Obj stuff.
>> A "small" Tcl implementation which could optionally support UTF would
>> need to be cleverly architected.
>I think UTF should not be taken out. It's part of the basics of
>the language. And it makes sense for embedded stuff too, like
>native error messages.
Not for me. I want Unicode gone for what I plan on using a smaller Tcl for
where Tcl would itself be the OS.
>Greetings!
>Volker
Volker Hetzer
>
> Volker Hetzer <volker...@fujitsu-siemens.com> wrote:
>
> >Bob Techentin wrote:
> >> I'm not entirely sure what would constitute "just the basics". It might
> >> be as simple as just eval, set, for, if, case, interp, join, and a few
> >> others.
> >Much too much.
> >"Basics" should IMHO be the command structure, Dollar sign, [], {}, ""
> >and the semicolon. Every tcl command should be strippable from
> >the interpreter so that one could create a embeddable language
> >supporting only three or four commands provided by the developer and
> >especially no loops, procs or other dangerous things.
> >
> >Maybe one should approach the problem from another angle and try to
> >extract the parser instead of trying to remove commands?
>
> The parser is just fine the way it is, IMO. That is what defines Tcl as Tcl.
having the minimum tcl consist of the parser and then see what additional items
need to go into the minimum tcl.
I certainly agree that the parser is the essence of the tcl language.
I just suggested to start the minimum tcl effort with this essence instead
of the full tcl.
> I would leave that and the Tcl_Obj stuff.
Leave it in or leave it out?
> >> A "small" Tcl implementation which could optionally support UTF would
> >> need to be cleverly architected.
> >I think UTF should not be taken out. It's part of the basics of
> >the language. And it makes sense for embedded stuff too, like
> >native error messages.
>
> Not for me. I want Unicode gone for what I plan on using a smaller Tcl for
> where Tcl would itself be the OS.
Ok. Would this affect the parser?
IMHO the goal should be to have one code base for both the minimum and full
tcl, not one parser for minimum tcl and another for full tcl.
David Gravereaux
>> Not for me. I want Unicode gone for what I plan on using a smaller Tcl for
>> where Tcl would itself be the OS.
>Ok. Would this affect the parser?
I don't know what you mean by parser? There's only one and it isn't all that
modular and it doesn't need to be. Or does it? the unicode bits like \u2121, I
might want to remove. I think that's all that's in there with regards to
unicode.
David Gravereaux
>IMHO the goal should be to have one code base for both the minimum and full
>tcl, not one parser for minimum tcl and another for full tcl.
Look.. there's only one parser. what is it you're saying?
Volker Hetzer
>
> Volker Hetzer <volker...@fujitsu-siemens.com> wrote:
>
> >> Not for me. I want Unicode gone for what I plan on using a smaller Tcl for
> >> where Tcl would itself be the OS.
> >Ok. Would this affect the parser?
>
> I don't know what you mean by parser? There's only one and it isn't all that
> modular and it doesn't need to be.
I've no idea about how it's realized for tcl, but if I'd use a tool
like flex for scanning tcl code I think I'd have to take care that for
instance umlauts are properly recognized.
David Gravereaux
>IMHO the goal should be to have one code base for both the minimum and full
>tcl, not one parser for minimum tcl and another for full tcl.
If that's your goal, go make a branch and do it. I want a Tcl that's smaller,
by a large factor. I don't what DLL hell. If that's your goal, and you mean
splitting the sections as separate DLLs, my all means pursue that goal, but I'll
have no part of it.
Volker Hetzer
>
> Volker Hetzer <volker...@fujitsu-siemens.com> wrote:
>
> >IMHO the goal should be to have one code base for both the minimum and full
> >tcl, not one parser for minimum tcl and another for full tcl.
>
> If that's your goal, go make a branch and do it. I want a Tcl that's smaller,
> by a large factor. I don't what DLL hell. If that's your goal, and you mean
> splitting the sections as separate DLLs, my all means pursue that goal, but I'll
> have no part of it.
Frédéric Bonnet
"David Gravereaux" <davy...@pobox.com> wrote:
> Let's say a attempt to trim Tcl a bit and chop out parts I don't like.
How
> should I handle Stubs? Leave the holes as a NULL? I wouldn't want to
change
> the positions. All the UTF stuff is ingrained so deeply. I'm trying to
look
> into stripping UTF completely out from 8.4 .
IMHO completely removing UTF-8 from the core is going to be tough. There are
too much code relying on UTF library calls, unless you want to rewrite
everything. I suppose you want to replace Unicode by some specific
fixed-width 8-bit encoding (let's say Latin-1). In this case, rewrite all
the UTF-related procs so that they operate on this hard-coded encoding
rather than on UTF-8. For example, Tcl_UtfAtIndex(string, index) would
return string[index] instead of iterating over variable-width UTF-8 chars.
Existing code is not supposed to operate directly on UTF-8 chars, so you're
likely to cover all the existing code. The only problem I see with this
approach is embedded null chars. UTF-8 properly escapes nulls so that it's
safe to call str(len|cpy|whatever) on strings. In this case you'll get
roughly the same support as Tcl8.0 for string objects (which are byte
counted anyway), still better than with 7.6.
BTW what is the exact reason why you want to remove UTF-8 or Unicode? Or
just UTF-8, keeping Unicode? Do you also want to remove encodings? Would
replacing variable-width UTF-8 with fixed-width Unicode fit your needs? I
see two issues regarding UTF-8 and Unicode: memory and CPU consumption.
Unicode strings cost twice as much memory as 8-bit strings, but with roughly
the same performances (direct indexing). UTF-8 is a tradeoff between memory
and CPU consumption: variable-width characters waste less space than
fixed-width 2-byte Unicode with common strings (ASCII-7), but lose direct
addressing (O(n) instead of O(1)). If your OS is going to be embedded into
smallish devices (with a few KBs left), I'd choose 8-bit strings. Else I'd
go Unicode.
See you, Fred
--
Frédéric Bonnet fbo...@users.sourceforge.net
----------------------------------------------------------------------------
"Theory may inform, but Practice convinces" George Bain
Chang LI
The min Tcl should have a same kernel base as the full Tcl.
The UTF is a difficult stuff to strip off. But many commands
can be organized as the dynamic loading libraries. This could
reduce hundred Ks memory. The memory size is critical for
embedded applications. Current Tcl basically lose an important
application area.
It is a pity Tcl community has lost most of the people who can
write the core.
Chang
Cameron Laird
Chang LI <chang...@hotmail.com> wrote:
>David Gravereaux <davy...@pobox.com> wrote in message news:<2l8ppto6k8p5ke9m9...@4ax.com>...
>
>The min Tcl should have a same kernel base as the full Tcl.
>The UTF is a difficult stuff to strip off. But many commands
>can be organized as the dynamic loading libraries. This could
>reduce hundred Ks memory. The memory size is critical for
into dynamically-loaded libraries--has
benefits that are not so certain. I once
thought the same as you: that a few
hundred thousands of bytes would be
readily salvageable. My own experiments,
and the testimony of Dr. Ousterhout and
others, suggest that the potential is con-
siderably more limited. Lots of the Tcl
core simply doesn't divide out this way.
Networking is about the only functionality
that fits this model well. Other things--
even [expr] functions--are either too small
or too widely used to segment out easily.
>embedded applications. Current Tcl basically lose an important
>application area.
>
>It is a pity Tcl community has lost most of the people who can
>write the core.
.
.
.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Bob Techentin
>
> Volker Hetzer <volker...@fujitsu-siemens.com> wrote:
>
> >IMHO the goal should be to have one code base for both the minimum and full
> >tcl, not one parser for minimum tcl and another for full tcl.
>
> If that's your goal, go make a branch and do it. I want a Tcl that's smaller,
> by a large factor. I don't what DLL hell. If that's your goal, and you mean
> splitting the sections as separate DLLs, my all means pursue that goal, but I'll
> have no part of it.
I was thinking of a single code base. Not DLL hell.
If you look in tclObj.c, for example, you'll find that there are two
versions of Tcl_NewObj(), selected by the compile time option
TCL_MEM_DEBUG. You can either get debug objects, or normal objects.
And because they're both Tcl_Objs, and behave like Tcl_Objs, most of the
rest of Tcl doesn't care which type of object it gets.
If you apply some of the same architectural techniques (more recently
documented as "design patterns" by Gamma et. al) to the rest of the
core, you could end up with a set of Tcl_Objs that are either straight
ASCII or Unicode aware. The selection could be either at compile time
or run time. It could use a single code base, and would not necessarily
result in DLL hell.
But I'm having a little trouble concentrating just now. I'll try to
talk about this later.
David Gravereaux
>But I'm having a little trouble concentrating just now. I'll try to
>talk about this later.
yes, my concerns are elsewhere today as well. No code fu for me. not today.
Andreas Kupries
"Chang LI" <chang...@hotmail.com> wrote in message
news:89cc6e1f.01091...@posting.google.com...
> David Gravereaux <davy...@pobox.com> wrote in message
news:<2l8ppto6k8p5ke9m9...@4ax.com>...
>
> The min Tcl should have a same kernel base as the full Tcl.
> The UTF is a difficult stuff to strip off. But many commands
> can be organized as the dynamic loading libraries. This could
> reduce hundred Ks memory. The memory size is critical for
> embedded applications. Current Tcl basically lose an important
> application area.
>
> It is a pity Tcl community has lost most of the people who can
> write the core.
And please what are the Tcl maintainers working through the SF DB
fixing bugs, cleaning up, optimizing things ... ?
Sorry if I sound more harsh than necessary, interference from the news
I heard this morning about NYC/WTC ...
--
Andreas Kupries <andr...@ActiveState.com>
Developer @ http://www.ActiveState.com
Jeff Hobbs
>
> Let's say a attempt to trim Tcl a bit and chop out parts I don't like. How
> should I handle Stubs? Leave the holes as a NULL? I wouldn't want to change
> the positions. All the UTF stuff is ingrained so deeply. I'm trying to look
> into stripping UTF completely out from 8.4 .
If I were you, I'd start with 8.0.5 and work from there. There is
a branch that I think even played with stubs in 8.0 IIRC. That
gives you the byte compiler and Tcl_Obj's without all the Unicode
overhead.
Otherwise, I'd look at the making the core respond better to having
TCL_UTF_MAX == 1 (meaning 8-bit ascii only). In any case, that's
likely to be a branch, because the confusion it would add to the core,
along with maintenance overhead, would not be beneficial.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
David Gravereaux
>David Gravereaux wrote:
>>
>> Let's say a attempt to trim Tcl a bit and chop out parts I don't like. How
>> should I handle Stubs? Leave the holes as a NULL? I wouldn't want to change
>> the positions. All the UTF stuff is ingrained so deeply. I'm trying to look
>> into stripping UTF completely out from 8.4 .
>
>If I were you, I'd start with 8.0.5 and work from there. There is
>a branch that I think even played with stubs in 8.0 IIRC. That
>gives you the byte compiler and Tcl_Obj's without all the Unicode
>overhead.
I remember Scott Redman looked at doing Stubs for 8.0.6 in a compatibility
manner. I'll look at it.
>Otherwise, I'd look at the making the core respond better to having
>TCL_UTF_MAX == 1 (meaning 8-bit ascii only). In any case, that's
>likely to be a branch, because the confusion it would add to the core,
>along with maintenance overhead, would not be beneficial.
If I want unmodified extensions to run in a small core, I'd better get my goals
clear about what a small core is.
unicode with a compile-time switch? truly compatible with the existing Stubs
table for the API which only would be replacements for the UNI and UTF ones?
With APIs I might remove (like sockets), would I just leave a null as the
function pointer in the Stubs table? How would it best to version it so an
extension would know it's running in a small core?
Chang LI
> >
> >The min Tcl should have a same kernel base as the full Tcl.
> >The UTF is a difficult stuff to strip off. But many commands
> >can be organized as the dynamic loading libraries. This could
> >reduce hundred Ks memory. The memory size is critical for
For a tiny Tcl with a common core base I do not see other ways
except the segmentation. 600K Tcl is huge for embedded system
and a wrap Tcl. At least I think the eval commond could be
separated.
I am concerned the size of wrapped Tcl size. I do not think it
is reasonable that 2 lines Tcl has the wrapped exe of 600k.
Chang
Volker Hetzer
> But I'm having a little trouble concentrating just now. I'll try to
> talk about this later.
Volker
David Gravereaux
>I am concerned the size of wrapped Tcl size. I do not think it
>is reasonable that 2 lines Tcl has the wrapped exe of 600k.
This is what eval-based languages are all about, though. There is no linker,
like in C, where unreferenced symbols are discarded. The whole weight needs to
be there because Tcl_Eval() is run-time. There is no pre-known reference to
what the script is. If you offer an editbox in a Tk GUI for an eval, what will
the person type into it? There is no link step.
How, given a link step, could one know what will be typed into that editbox?
You don't. If small footprint is paramount in your design, you might want to
give up the idea of run-time based execution for the price you pay with the
weight it caries.
lvi...@yahoo.com
According to David Gravereaux <davy...@pobox.com>:
:Let's say a attempt to trim Tcl a bit and chop out parts I don't like. How
:should I handle Stubs?
If you are dropping most of the bigger parts of Tcl, but you are interested
in a Stubs like mechanism, I would forget about attempts at maintaining
some semblance of compatibility with the current stubs but create a new
structure.
--
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
Bob Techentin
>
> If I want unmodified extensions to run in a small core, I'd better get my goals
> clear about what a small core is.
>
> unicode with a compile-time switch? truly compatible with the existing Stubs
> table for the API which only would be replacements for the UNI and UTF ones?
> With APIs I might remove (like sockets), would I just leave a null as the
> function pointer in the Stubs table? How would it best to version it so an
> extension would know it's running in a small core?
You and I may be talking about different things David.
In my grand scheme of the universe, "small core" means that only a
subset ot Tcl would be available. I would expect to be able to add
extensions, but I would not expect stubs-compatible extensions to drop
in without recompiling.
I would _want_ a compile failure if I tried to add an extension that
utilized a feature that was not available. Otherwise I won't find out
that the extension is calling non existant stubbed functions until run
time.
David Gravereaux
>You and I may be talking about different things David.
Yes, I think so. Hold the pickles, hold UTF... special cores and compile-time
switches don't upset us...
I'm looking at a roll-my-own flavor.
lvi...@yahoo.com
According to Andreas Kupries <andr...@ActiveState.com>:
:
:"Chang LI" <chang...@hotmail.com> wrote in message
:news:89cc6e1f.01091...@posting.google.com...
:> David Gravereaux <davy...@pobox.com> wrote in message
:news:<2l8ppto6k8p5ke9m9...@4ax.com>...
:> It is a pity Tcl community has lost most of the people who can
:> write the core.
:
:And please what are the Tcl maintainers working through the SF DB
:fixing bugs, cleaning up, optimizing things ... ?
Certainly there is much great work being done by the community's cast
of coders.
And we are always looking for more volunteers - so please people, step
forward. The only real experience required is to be able to read C
code, or at least the willingness to LEARN C - get on the job training!
Jeff Hobbs
> It is a pity Tcl community has lost most of the people who can
> write the core.
Actually, being in a position to know, I can say this is an incorrect
statement. There were never more than about 8 people that were
in-depth into the true core at any one point in time. The hey-day
would have been at Sun, where experts on Unicode, Mac, Windows, I/O,
compilers, and UI all worked together to create what became Tcl 8.0
and 8.1 (also 4.1+). Others were there as well, but they worked on
side projects outside the core.
Now however, with the open system that we have, more people are
working on lots of subtler aspects of the core. Anyone with a good
knowledge of C (or good perseverance) can become familiar with one
or more parts of the core. Examples are people like Rolf Schroedter
who knows more about serial I/O than any previous core author;
Miguel Sofer, who is examining the deep internals and byte compiler
with a fine toothed comb; Andreas Kupries, who was key in rewriting
the I/O core for further stability and cool new features; David
Gravereaux, who worked doggedly on the utmost stability for threads
(for all that he didn't want to ;) ); Mo DeJong, who helps to ensure
things compile right; Vince Darley, who gave us VFS amongst other
new tidbits; Peter Spjuth and Eric Melski, authors of new core
widgets; ... the list goes on.
This is definitely a living language and moving further forward.
Getting into writing the core isn't as hard as some think. Sure,
you don't jump into the execution engine on your first day, but
there's lots more to it than that. And the wealth of comment and
cleanliness of the code ... compare the code base to any other
major scripting language, and you'll see why Tcl is the one that
won the ACM Software Engineering award for John Ousterhout.
Scott Stanton
> Bob Techentin <techenti...@mayo.edu> wrote:
>
> >You and I may be talking about different things David.
>
> Yes, I think so. Hold the pickles, hold UTF... special cores and compile-time
> switches don't upset us...
Could you explain your motivation for cutting out the UTF support? I
understand why you wouldn't want to deal with lots of different
encodings in an embedded system, but is there a specific reason to not
to use UTF8 and possibly one specific encoding? It doesn't add that
much overhead, and it seems like it would be a lot simpler to just
compile in the encodings you care about.
I'm all for stripping Tcl down to the basics, but changing the
internal character representation just doesn't seem worth the effort.
--Scott
Bob Techentin
>
> David Gravereaux <davy...@pobox.com> wrote in message news:<amnuptc6215dclvt3...@4ax.com>...
> >
> > switches don't upset us...
>
> Could you explain your motivation for cutting out the UTF support?
Every time somebody says "Gee, Tcl 8.3 is slower than 8.0.5" the
immediate response is "Of course it is. We added unicode." If you
build Tcl 8.4a3 for profiling, and run the tclbench suite, you'll find
Tcl_UniCharToUtf() in the top ten, with 20% of the CPU time and fifty
times the function calls of TclExecuteByteCode.
Not every application *needs* unicode support.
Jeff Hobbs
> > > switches don't upset us...
> >
> > Could you explain your motivation for cutting out the UTF support?
>
> Every time somebody says "Gee, Tcl 8.3 is slower than 8.0.5" the
> immediate response is "Of course it is. We added unicode." If you
> build Tcl 8.4a3 for profiling, and run the tclbench suite, you'll find
> Tcl_UniCharToUtf() in the top ten, with 20% of the CPU time and fifty
> times the function calls of TclExecuteByteCode.
Hmmm, and to think that even then there are parts of 8.4 that have
been made faster then 8.0. Anyone with hard profiling info (either
from gprof or Quantify) is welcome to send me the details. Mind
you, I don't promise to do anything with it unless you pay me :),
but just knowing what the blocks are is a first step.
Also, I'm interested in Tcl-level profiling information. What calls
your application makes the most (if, while, string, ...), and, if
possible, what submethods of major commands like string are used.
Bob Techentin
>
> Hmmm, and to think that even then there are parts of 8.4 that have
> been made faster then 8.0. Anyone with hard profiling info (either
> from gprof or Quantify) is welcome to send me the details. Mind
> you, I don't promise to do anything with it unless you pay me :),
> but just knowing what the blocks are is a first step.
>
> Also, I'm interested in Tcl-level profiling information. What calls
> your application makes the most (if, while, string, ...), and, if
> possible, what submethods of major commands like string are used.
>
> --
> Jeff Hobbs The Tcl Guy
> Senior Developer http://www.ActiveState.com/
> Tcl Support and Productivity Solutions
OK. Here is a little data.
1. Tcl 8.4a3 built under HP-UX 10.20 with A.10.32.30 ANSI C
compiler. Configured with --disable-shared and CFLAGS=-G for profiling,
but make insisted on including the +z flag for position indpendent code
(which is incompatible with -G). Edited the makefiles to compile and
link a profilable tclsh.
2. Ran tclbench -iterations 10 on a relatively old and slow machine.
Used gprof to generate this report. (I can email you the whole file, if
you like, but I've just posted a bit of it here.)
granularity: each sample hit covers 4 byte(s) for 0.00% of 1747.71
seconds
flat profile:
%time the percentage of the total running time of the
program used by this function.
cumsecs a running sum of the number of seconds accounted
for by this function and those listed above it.
seconds the number of seconds accounted for by this
function alone. This is the major sort for this
listing.
calls the number of times this function was invoked, if
this function is profiled, else blank.
name the name of the function. This is the minor sort
for this listing.
%time cumsecs seconds calls msec/call name
24.8 432.90 432.90 _mcount
10.3 613.38 180.48 2421919 0.07 TclExecuteByteCode
7.4 742.56 129.18 647095 0.20 DupListInternalRep
6.7 858.97 116.41 1282663 0.09 FreeListInternalRep
3.9 926.51 67.54 18358173 0.00 miss
3.2 982.16 55.65 11700444 0.00 tree_insert
2.6 1027.44 45.28 35392229 0.00 TclSetIndexedScalar
2.6 1072.09 44.65 7856456 0.01 _memcpy
2.3 1112.86 40.77 18339965 0.00 pickss
2.1 1149.61 36.75 1265392 0.03 TableToUtfProc
2.0 1184.15 34.54 133412173 0.00 Tcl_UniCharToUtf
1.8 1215.99 31.84 18339965 0.00 getvacant
1.7 1246.26 30.27 2678066 0.01 Tcl_ListObjReplace
1.5 1272.38 26.12 44067336 0.00 TclGetIndexedScalar
1.3 1295.60 23.22 19916854 0.00 Tcl_CreateHashEntry
1.1 1315.48 19.88 8340536 0.00 malloc
1.1 1335.02 19.54 8329625 0.00 free
0.9 1351.58 16.56 19309527 0.00 Tcl_ListObjAppendElement
0.9 1367.27 15.69 1574991 0.01 shortest
0.8 1380.89 13.62 46185459 0.00 Tcl_UniCharToLower
0.7 1393.81 12.92 50823640 0.00 Tcl_InvalidateStringRep
0.7 1406.51 12.70 5719 2.22 Tcl_StringObjCmd
0.7 1418.67 12.16 23574320 0.00 Tcl_UniCharNcasecmp
0.7 1430.67 12.00 $$dyncall_external
0.6 1441.06 10.39 23172591 0.00 Tcl_ListObjLength
0.6 1451.36 10.30 4603112 0.00 tree_concatenate
0.6 1461.06 9.70 17450852 0.00 Tcl_NewLongObj
0.5 1469.65 8.59 14776166 0.00 Tcl_SetLongObj
0.5 1478.19 8.54 8687828 0.00 ResetObjResult
0.4 1485.77 7.58 4984893 0.00 SortCompare
0.4 1492.65 6.88 2240007 0.00 TclObjInterpProc
0.4 1499.40 6.75 2423725 0.00 Tcl_EvalObjEx
0.4 1505.80 6.40 2677397 0.00 Tcl_LreplaceObjCmd
0.4 1512.00 6.20 6210783 0.00 Tcl_GetCommandFromObj
0.3 1517.80 5.80 8656665 0.00 Tcl_ResetResult
0.3 1523.59 5.79 2015 2.87 Tcl_SplitObjCmd
0.3 1529.34 5.75 5110867 0.00 Tcl_SetObjResult
0.3 1534.92 5.58 9728426 0.00 Tcl_ListObjIndex
0.3 1540.36 5.44 16950436 0.00 Tcl_UtfToUniChar
0.3 1545.52 5.16 14197451 0.00 Tcl_GetThreadData
... 750 lines skipped ...
call graph profile:
The sum of self and descendents is the major sort
for this listing.
function entries:
index the index of the function in the call graph
listing, as an aid to locating it (see below).
%time the percentage of the total time of the program
accounted for by this function and its
descendents.
self the number of seconds spent in this function
itself.
descendents
the number of seconds spent in the descendents of
this function on behalf of this function.
called the number of times this function is called (other
than recursive calls).
self the number of times this function calls itself
recursively.
name the name of the function, with an indication of
its membership in a cycle, if any.
index the index of the function in the call graph
listing, as an aid to locating it.
parent listings:
self* the number of seconds of this function's self time
which is due to calls from this parent.
descendents*
the number of seconds of this function's
descendent time which is due to calls from this
parent.
called** the number of times this function is called by
this parent. This is the numerator of the
fraction which divides up the function's time to
its parents.
total* the number of times this function was called by
all of its parents. This is the denominator of
the propagation fraction.
parents the name of this parent, with an indication of the
parent's membership in a cycle, if any.
index the index of this parent in the call graph
listing, as an aid in locating it.
children listings:
self* the number of seconds of this child's self time
which is due to being called by this function.
descendent*
the number of seconds of this child's descendent's
time which is due to being called by this
function.
called** the number of times this child is called by this
function. This is the numerator of the
propagation fraction for this child.
total* the number of times this child is called by all
functions. This is the denominator of the
propagation fraction.
children the name of this child, and an indication of its
membership in a cycle, if any.
index the index of this child in the call graph listing,
as an aid to locating it.
* these fields are omitted for parents (or
children) in the same cycle as the function. If
the function (or child) is a member of a cycle,
the propagated times and propagation denominator
represent the self time and descendent time of the
cycle as a whole.
** static-only parents and children are indicated
by a call count of 0.
cycle listings:
the cycle as a whole is listed with the same
fields as a function entry. Below it are listed
the members of the cycle, and their contributions
to the time and call counts of the cycle.
granularity: each sample hit covers 4 byte(s) for 0.00% of 1314.81
seconds
called/total parents
index %time self descendents called+self name index
called/total children
<spontaneous>
[1] 30.6 0.42 402.21 TclProcInterpProc [1]
6.88 395.33 2240007/2240007 TclObjInterpProc
[2]
-----------------------------------------------
6.88 395.33 2240007/2240007 TclProcInterpProc
[1]
[2] 30.6 6.88 395.33 2240007 TclObjInterpProc [2]
6.24 362.56 2240007/2423725 Tcl_EvalObjEx [3]
2.04 13.27 2240007/2240150 Tcl_PopCallFrame
[74]
3.66 0.00 2240007/2240007
TclInitCompiledLocals [130]
3.21 0.00 2240007/2240007 TclProcCompileProc
[132]
2.22 0.00 2240007/2240150 Tcl_PushCallFrame
[142]
1.11 0.04 2240007/9667391 Tcl_GetObjResult
[116]
0.96 0.00 2240007/3276356
Tcl_GetStringFromObj [161]
0.01 0.00 20652/211565 strcmp [275]
0.00 0.00 386/804 Tcl_NewListObj
[455]
0.00 0.00 44/8294830 Tcl_Alloc [29]
0.00 0.00 44/8284481 Tcl_Free [32]
0.00 0.00 11/11
ProcessProcResultCode [564]
0.00 0.00 1/8 TclProcCleanupProc
[556]
-----------------------------------------------
0.00 0.00 1/2423725 Tcl_CatchObjCmd
[576]
0.00 0.00 10/2423725 NamespaceEvalCmd
<cycle 6> [413]
0.00 0.00 19/2423725 Tcl_IfObjCmd [446]
0.00 0.05 289/2423725 Tcl_ForeachObjCmd
[268]
0.00 0.08 508/2423725 Tcl_UplevelObjCmd
<cycle 9> [299]
0.00 0.12 743/2423725 Tcl_SwitchObjCmd
[48]
0.01 0.64 3951/2423725 Tcl_EvalObjCmd
[197]
0.01 0.84 5207/2423725 Tcl_ForObjCmd [159]
0.48 28.00 172990/2423725 Tcl_TimeObjCmd [50]
6.24 362.56 2240007/2423725 TclObjInterpProc
[2]
[3] 30.4 6.75 392.30 2423725 Tcl_EvalObjEx [3]
180.28 195.48 2419264/2421897 TclExecuteByteCode
<cycle 2> [5]
0.91 9.80 1871/1898 Tcl_EvalEx <cycle
8> [180]
1.62 2.38 2419266/8656665 Tcl_ResetResult
[77]
0.75 0.76 2098120/8308902 Tcl_AsyncReady
[110]
0.30 0.00 2419266/2424452 TclpCheckStackSpace
[233]
0.00 0.01 2588/2588 Tcl_EvalObjv [438]
0.00 0.00 1915/4305319 TclFreeObj [121]
0.00 0.00 1871/3276356
Tcl_GetStringFromObj [161]
-----------------------------------------------
[4] 28.6 180.48 195.69 2421897+2677 <cycle 2 as a whole>
[4]
180.48 195.57 2421919 TclExecuteByteCode
<cycle 2> [5]
0.00 0.12 2655 Tcl_ExprObj <cycle
2> [279]
-----------------------------------------------
2655 Tcl_ExprObj <cycle
2> [279]
180.28 195.48 2419264/2421897 Tcl_EvalObjEx [3]
[5] 28.6 180.48 195.57 2421919 TclExecuteByteCode
<cycle 2> [5]
40.78 7.83 31871763/35392229
TclSetIndexedScalar [37]
2.60 27.13 3520466/3520466
TclIncrIndexedScalar [47]
24.03 0.00 40546870/44067336
TclGetIndexedScalar [57]
2.95 12.04 1555201/1555451
TclSetElementOfIndexedArray [75]
6.54 6.95 11252724/14776166 Tcl_SetLongObj
[69]
4.16 6.12 6205622/8656665 Tcl_ResetResult
[77]
8.38 0.00 15080297/17450852 Tcl_NewLongObj
[97]
6.19 0.00 6205597/6210783
Tcl_GetCommandFromObj [107]
4.83 0.75 10766780/23172591 Tcl_ListObjLength
[84]
1.69 3.07 3228493/8596012 TclGetIntForIndex
[83]
2.22 2.26 6205597/8308902 Tcl_AsyncReady
[110]
3.08 0.10 6205949/9667391 Tcl_GetObjResult
[116]
1.70 1.28 3220761/3233946
Tcl_ListObjGetElements [136]
2.98 0.00 6205597/6205984 Tcl_Preserve [137]
2.22 0.72 1550371/1550621
TclGetElementOfIndexedArray [138]
2.72 0.04 2421896/5110867 Tcl_SetObjResult
[111]
1.23 1.46 2370665/2370665 Tcl_SetDoubleObj
[139]
2.41 0.00 6205597/6205984 Tcl_Release [141]
1.91 0.00 5257331/14197451 Tcl_GetThreadData
[114]
0.01 0.92 10013/10013 Tcl_LogCommandInfo
[183]
0.11 0.75 91643/95764 Tcl_ObjGetVar2
[185]
0.13 0.19 520379/50823640
Tcl_InvalidateStringRep [46]
0.02 0.25 17732/727029 Tcl_NewStringObj
[89]
0.01 0.14 35050/3669513 Tcl_GetLongFromObj
[73]
0.00 0.09 2600/2600 TclIncrVar2 [293]
0.00 0.08 11787/8284481 Tcl_Free [32]
0.08 0.00 14040/7856456 _memcpy [39]
0.00 0.05 6767/8294830 Tcl_Alloc [29]
0.00 0.05 3161/646861 Tcl_ObjSetVar2 [86]
0.03 0.02 35815/37013 TclLooksLikeInt
[319]
0.02 0.02 17732/17732 Tcl_GetUniChar
[321]
0.04 0.00 10039/10039 GetExceptRangeForPc
[332]
0.03 0.00 89/89
Tcl_UniCharCaseMatch [354]
0.03 0.00 67875/3276356
Tcl_GetStringFromObj [161]
0.00 0.02 20077/22370 Tcl_GetCharLength
[359]
0.02 0.00 39433/39433 Tcl_NewIntObj [383]
0.02 0.00 10013/10013 GetSrcInfoForPc
[384]
0.00 0.01 419/848244 Tcl_UniCharNcmp
[52]
0.00 0.01 91/91
Tcl_GetBooleanFromObj [415]
0.00 0.00 17732/133412173 Tcl_UniCharToUtf
[42]
0.00 0.00 250/250
TclIncrElementOfIndexedArray [460]
0.00 0.00 8036/632265 Tcl_NewObj [236]
0.00 0.00 838/1609411
Tcl_GetUnicodeFromObj [140]
0.00 0.00 2696/3627528 Tcl_GetString [150]
0.00 0.00 178/178 Tcl_GetUnicode
[497]
0.00 0.00 1354/211565 strcmp [275]
0.00 0.00 765/9729035
Tcl_GetDoubleFromObj [127]
0.00 0.00 11/19309527
Tcl_ListObjAppendElement [45]
22 Tcl_ExprObj <cycle
2> [279]
-----------------------------------------------
... 9000 lines skipped ...
David Gravereaux
Hi Scott, LTNS BTW.
memory is the first answer.. I know strings are mostly in UTF, and at times are
up-cast to 16-bit unicode, but for times like using a simple LCD display such as
this one (see page 9)
http://www.hvwtech.com/dnload/lcd/lcd0821.pdf
characters are just 8-bit. I understand what you mean by wanting me to keep the
"all neutral" unicode capabilities and define the glyph rep in an encoding for
the specifics of the use. I know Tcl's unicode is top notch, but the added
memory to keep those strings and ... I just miss 8.0.X, I guess. I remember
when 8.0.6 was dumped. At the time, I would have preferred to not use unicode,
but I've grown into it and do make use of it for limited stuff, and is the
central part of one application of mine.
Maybe it's good for me to keep it... I can't say for sure. It sure would be
nice to have a TCL_NOUNICODE compile-time flag to swap if I wanted to.