tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] private font-files in tcltk

[Jeff H. <je...@ac...>]

On 24/03/2009 9:46 AM, T. Horsnell wrote:
> Is there a way in TCLTK to use fontfiles from a private directory?
> Preferably a way in which one can refer to such files by an explicit
> file-path.

Tk is directed by the fonts the X server (or OS system) says are 
available.  Just make that font available through the X server and Tk 
will see it.

Jeff

[TCLCORE] private font-files in tcltk

[T. H. <ts...@mr...>]

Hi all,
Is there a way in TCLTK to use fontfiles from a private directory?
Preferably a way in which one can refer to such files by an explicit
file-path.
It would, for example, be lovely to be able to create a font name
associated with such a file:

font create myfont -fontfile /mydir/myfont.ttf

Cheers,
Terry

Re: [TCLCORE] [Tcl-soc2008] Tcl GSoC 2009 - missing parts

[Donal K. F. <don...@ma...>]

Jeff Hobbs wrote:
> Tomasz Kosiak wrote:
>> 1. Who will you be able to submit Tcl GSoC 2009 application and act
>> as an admin?
> 
> I will not have the time to both admin and mentor, and I would prefer to 
> mentor.

I definitely won't admin, and probably won't formally mentor. Alas, I
have a very heavy workload with paywork. But I'm happy to offer advice
and perform reviews (code and docs) by email, provided I'm not on
vacation at the time, of course.

>> One *very *important question is if we can/will act as umbrella
>> organization for Tcl/Tk + AOLserver/Naviserver/OpenACS/XOTcl/aMSN
>> which gave us 5 more slots last year.
> 
> I feel that it doesn't hurt to represent the umbrella, but perhaps we 
> can assist in more clearly breaking out components by sub-area. 
> Labelling things AREA::... as ideas.

The 2009 project ideas page on the wiki really needs a cleanup. I've
been enriching it with links and fixing the obviously broken bits (like
suggestions running together!) but there's a lot still to do.

>> 2. Who is *really* willing to be a mentor this summer (if we got selected)
> 
> Given the available opportunities and the open scope of ideas, I would 
> be willing to mentor in the Tk area.  Specifically more photo 
> manipulation, megawidgets and anything in tklib are right up my alley.
> 
> In particular, a megawidget system based on TclOO with the features of 
> snidgets would be a big win for the core and I believe a easier to 
> medium level difficulty project.

I'm also willing to help out with these things. Indeed, I've already had
someone asking about the megawidget idea; he was seeking clarification
about the scope and whether it involved C programming (my response was
"hopefully not").

Donal.

Re: [TCLCORE] [Tcl-soc2008] Tcl GSoC 2009 - missing parts

[Jeff H. <je...@ac...>]

Tomasz Kosiak wrote:
> 1. Who will you be able to submit Tcl GSoC 2009 application and act
> as an admin?

I will not have the time to both admin and mentor, and I would prefer to 
mentor.

> One *very *important question is if we can/will act as umbrella
> organization for Tcl/Tk + AOLserver/Naviserver/OpenACS/XOTcl/aMSN
> which gave us 5 more slots last year.

I feel that it doesn't hurt to represent the umbrella, but perhaps we 
can assist in more clearly breaking out components by sub-area. 
Labelling things AREA::... as ideas.

> 2. Who is *really* willing to be a mentor this summer (if we got selected)

Given the available opportunities and the open scope of ideas, I would 
be willing to mentor in the Tk area.  Specifically more photo 
manipulation, megawidgets and anything in tklib are right up my alley.

In particular, a megawidget system based on TclOO with the features of 
snidgets would be a big win for the core and I believe a easier to 
medium level difficulty project.

Jeff

[TCLCORE] Fwd: Tcl GSoC 2009 - missing parts

[Tomasz K. <tk...@gm...>]

I repost it to reach wider audience.

--tkosiak

---------- Forwarded message ----------
From: Tomasz Kosiak <tk...@da...>
Date: Tue, Mar 10, 2009 at 2:22 AM
Subject: Tcl GSoC 2009 - missing parts
To: Tcl GSoC 2008 <tcl...@li...>


That are IMHO the missing points for Tcl/Tk/others to be accepted  in GSoC
2009:


1. Who will you be able to submit Tcl GSoC 2009 application and act as an
admin?

Will Matthew Burke find enough time or we need someone else to volunteer?

IMHO we *badly* need clear answer who will act as Tcl/Tk organization
admin in year 2009.

I offer myself to help such a person, but I think that to formulate
good application we need native English speaker as an admin.

I have reviewed last year application at http://wiki.tcl.tk/20836 and
this year questions - we at least have to fix/fill only a few answers:

- What criteria do you use to select the members of your group
(mentors/admins)? Please be as specific as possible.
- Has your group participated previously? If so, please summarize your
involvement and any past successes and failures (I think I can help
with this --tkosiak)
- What is the application template you would like contributors to your
organization to use (this is a *major* new question but I think we can
gather what was good in student application last year - I can review
them as I have the access to last year students' applications).

but it would be desirable to rework more. Tomorrow I can set up a new
wiki page and give my suggestions, but I will let some native speaker
formulate this well.

One *very *important question is if we can/will act as umbrella
organization for Tcl/Tk + AOLserver/Naviserver/OpenACS/XOTcl/aMSN
which gave us 5 more slots last year.




2. Who is *really* willing to be a mentor this summer (if we got selected)

I think we'll need full mentor name below the project title so
students can easily contact mentor for more info if needed.

* Cliff Flynt mentioned he can mentor up to 2 of
- "TkPrinting"
- "TkTutor"
- "XLS Read/Write"

* Gerald Lester is willing to mentor "Tcl Application Server"

* Andreas Kupries is willing to mentor but which ideas ???

* Steve Huntley "Tclhttpd refurbish" - did I correctly deciphered the
mentor?

Steve Landers mentored last year graph related project so maybe it
could be continued
- "Create a graph query language (GraphQL), analogous to the existing
TreeQL"
- "Based on the previous comment, create a language to specify and
execute graph transformations"

* William J Giddings "Extending Gnocl support to include Glade and
GtkBuildable UI XML Description Files"

* David N. Welton
"Tray Tip" An implementation of this:
http://www.tcl.tk/cgi-bin/tct/tip/325.html
"Create and integrate a theme that integrates Ttk with Gnome/Gtk."

* Pawel Salawa (Googie) - SSH client in Pure-Tcl

* Arjen Markus  "TkLib Enhancements"

Who is willing to mentor these?

* ??? "Coverage Analysis" -  Larry Virden or maybe we can ask Richard
Hipp as he has an expertise in this area with SQLite.
* ??? "Tcl Core Byte Code" - DKF or AK ?
* ??? "Regexp engine cleanup"
* ??? "Curses implementation of Tk"
* ??? TIP 308 TDBC (Tcl DataBase Connectivity) - PostgreSQL & Oracle
Tcl/C drivers are really needed
* ??? "Tcllib enhancements"
* ??? "Tk - factor out of Tk photo image processing" & "Icon thems" &
"Better" communication with window managers/desktop environments like
Gnome and KDE"
* ??? "Gnocl" - What specifically could be done here?

Last year as mentors we also had:

* Patrick Thoyts
* Jeff Hobbs
* Gustaf Neumann (XOTcl or OpenACS)
* Youness El Alaoui (aMSN)
* Tomasz Kosiak (I will write down 2 ideas tomorrow)




3. Our "Ideas page" need *major* improvement.

I think we should group/reformat ideas to bring it into something like
last year http://wiki.tcl.tk/20832.
Except mentioning full mentor name as a link to contact page we should
state at least project difficulty and what is required from a student:
Tcl or C and what else if really needed.

We shall reorder the ideas so those defined more clearly should be
higher. In fact I think that we should somehow top ideas that are
proffered by a community. Students will sometimes only read a few
first entries. That's why I think that we need an index at the top
consisting only from titles linked to anchors.

Another important thing is that we have to include an introduction at
the top. We shall even state that this is "Ideas page" for
Tcl/Tk/AOLserver/Naviserver/OpenACS/XOTcl and give links to proper
home pages, because students may not know those projects. Something
like last year is minimum.

We should advertise we've received 9 student slots (lets even explain
what that meant) and that all those projects were somehow successful
(students completed some work and get *paid*). AFAIR we where as good
as PHP last year.

Quoting from the GSoC FAQ:

What is an "Ideas" list?

An "Ideas" list should be a list of suggested student projects. This
list is meant to introduce contributors to your project's needs and to
provide inspiration to would-be student applicants. It is useful to
classify each idea as specifically as possible, e.g. "must know
Python" or "easier project; good for a student with more limited
experience with C++." If your organization plans to provide an
application template, it would be good to include it on your Ideas
list.

Keep in mind that your Ideas list should be a starting point for
student applications; we've heard from past mentoring organization
participants that some of their best student projects are those that
greatly expanded on a proposed idea or were blue-sky proposals not
mentioned on the Ideas list at all.

Re: [TCLCORE] Ideas for an optimization project

[Jeff H. <je...@ac...>]

On 7-Mar-09, at 9:18 PM, David Gravereaux wrote:
>> There is no need or value in the Win9x codebase support anymore.   
>> It's  totally EOL from MS and if we dropped all the extra pieces in  
>> Tcl and  Tk that used it, we would improve long term  
>> maintainability and likely  fix some bugs.
>
> Agreed.  There's a lot of funny use of ReadFile() used by the  
> windows channel drivers when today those handles are waitable and  
> could be switched over to WaitFor..().  The same code could be used  
> for sockets with WSAEventSelect(), too.  Instead of two additional  
> threads per pipe or console for managing readable and writable, it  
> could be one thread per 63 pipes.
>
> Does WinCE have CreateIoCompletionPort() and  
> GetQueuedCompletionStatus()?

Actually, no, AFAIK CE does not yet support IO completion ports.

Jeff

Re: [TCLCORE] Ideas for an optimization project

[David G. <dav...@po...>]

Jeff Hobbs wrote:
> On 7-Mar-09, at 4:07 PM, David Gravereaux wrote:
>> Getting win9x support back would require a second (or parallel  
>> switched
>> at run-time) notification system based around WSAEventSelect() rather
>> than completion ports.  Most of the code could be shared as the  
>> concept
>> of overlapped usage is the same.
> 
> There is no need or value in the Win9x codebase support anymore.  It's  
> totally EOL from MS and if we dropped all the extra pieces in Tcl and  
> Tk that used it, we would improve long term maintainability and likely  
> fix some bugs.

Agreed.  There's a lot of funny use of ReadFile() used by the windows 
channel drivers when today those handles are waitable and could be 
switched over to WaitFor..().  The same code could be used for sockets 
with WSAEventSelect(), too.  Instead of two additional threads per pipe 
or console for managing readable and writable, it could be one thread 
per 63 pipes.

Does WinCE have CreateIoCompletionPort() and GetQueuedCompletionStatus()?

Re: [TCLCORE] Ideas for an optimization project

[Jeff H. <je...@ac...>]

On 7-Mar-09, at 4:07 PM, David Gravereaux wrote:
> Getting win9x support back would require a second (or parallel  
> switched
> at run-time) notification system based around WSAEventSelect() rather
> than completion ports.  Most of the code could be shared as the  
> concept
> of overlapped usage is the same.

There is no need or value in the Win9x codebase support anymore.  It's  
totally EOL from MS and if we dropped all the extra pieces in Tcl and  
Tk that used it, we would improve long term maintainability and likely  
fix some bugs.

Jeff

Re: [TCLCORE] Ideas for an optimization project

[David G. <dav...@po...>]

Jeff Hobbs wrote:
...
> +1 on this project idea, and note that the difficulty will be in getting 
> a consistently 'configure'able setup that detects the best policy on the 
> machine you are on.  If you wanted the same advances on Windows, it 
> would be integrating davygravy's iocpsock work into the core.  That 
> completely drops Win9x support, but that is fine in the 8.6 (even 8.5) 
> codebase.


I'm alive, just busy with other stuff completely unrelated to programming.

Help with putting ipv6 and any other new protocols such as IrDA, 
BlueTooth, IPX/SPX, Appletalk, etc..  into [socket] (if only a framework 
for the others) would be wonderful.  And there is asynchronous multi 
protocol name resolution of all three types (static, dynamic, and 
persistent). The branch is still there, unfinished.

Maybe I can get to it in a months time, maybe not...  It really is a 
large project and way overdo.

Getting win9x support back would require a second (or parallel switched 
at run-time) notification system based around WSAEventSelect() rather 
than completion ports.  Most of the code could be shared as the concept 
of overlapped usage is the same.

Re: [TCLCORE] Ideas for an optimization project

[Jeff H. <je...@ac...>]

Kieran wrote:
> Daniel Hans wrote:
>> Ok, I was quite misunderstood ;-) I am not looking for a GSOC idea. I
>> have to accomplish my project by the beginning of June, so maybe 1500
>> lines is to many... For example Tomasz Kosiak suggested me to deal
>> with C10k problem in Tcl Channels.
> 
> FWIW, I'd also like to see Tcl better support huge numbers of socket 
> connections. Not sure if it exactly fits into the scope of your project 
> though.
> 
> I recently worked on a project where Tcl could not be used for (at 
> least) this reason - it needed to support many thousand clients on UNIX 
> and Tcl's select() based socket polling wasn't likely to cut it (see 
> unix/tclUnixNotify.c). Not sure what the Windows situation is.
> 
> The difficulty is that even across Unices, there are a variety of 
> select/poll replacements - e.g. epoll, kqueues, /dev/poll each with 
> their own quirks and limitations.
> 
> The dual BSD/GPL licensed C library libev seems like a promising attempt 
> to offer a unified interface across Linux/Solaris/BSD - see 
> http://software.schmorp.de/pkg/libev.html.

+1 on this project idea, and note that the difficulty will be in getting 
a consistently 'configure'able setup that detects the best policy on the 
machine you are on.  If you wanted the same advances on Windows, it 
would be integrating davygravy's iocpsock work into the core.  That 
completely drops Win9x support, but that is fine in the 8.6 (even 8.5) 
codebase.

Jeff

Re: [TCLCORE] Ideas for an optimization project

[Kieran <ki...@du...>]

Daniel Hans wrote:
> Ok, I was quite misunderstood ;-) I am not looking for a GSOC idea. I
> have to accomplish my project by the beginning of June, so maybe 1500
> lines is to many... For example Tomasz Kosiak suggested me to deal
> with C10k problem in Tcl Channels.
> 

Hello Daniel,

FWIW, I'd also like to see Tcl better support huge numbers of socket 
connections. Not sure if it exactly fits into the scope of your project 
though.

I recently worked on a project where Tcl could not be used for (at 
least) this reason - it needed to support many thousand clients on UNIX 
and Tcl's select() based socket polling wasn't likely to cut it (see 
unix/tclUnixNotify.c). Not sure what the Windows situation is.

The difficulty is that even across Unices, there are a variety of 
select/poll replacements - e.g. epoll, kqueues, /dev/poll each with 
their own quirks and limitations.

The dual BSD/GPL licensed C library libev seems like a promising attempt 
to offer a unified interface across Linux/Solaris/BSD - see 
http://software.schmorp.de/pkg/libev.html.

Regards,
Kieran Elby

Re: [TCLCORE] Ideas for an optimization project

[Daniel H. <da...@gm...>]

Ok, I was quite misunderstood ;-) I am not looking for a GSOC idea. I
have to accomplish my project by the beginning of June, so maybe 1500
lines is to many... For example Tomasz Kosiak suggested me to deal
with C10k problem in Tcl Channels.

Donal,
thank you, for your response, I will read about namespaces in Tcl.

Best,
Daniel

2009/3/3 Steve Landers <st...@di...>:
>
> On 03/03/2009, at 5:15 PM, Donal K. Fellows wrote:
>
>> Daniel Hans wrote:
>>>
>>> The aim of my project is to improve effectiveness (time, memory usage,
>>> etc.)
>>> of a particular aspect of
>>> an open source program. Then I have to show that my solution is really
>>> somehow
>>> better than the existing one by running some tests or something. That
>>> would be
>>> appreciated to use for example some profiling tools like Google Profiler
>>> or
>>> gprof. I would like my project to be up to 1500-2500 lines of code.
>>
>> Chiseling away at the cost of a few of the key structures in Tcl would
>> be a good thing. For example, it would be nice if the cost of namespaces
>> was lower, which Tcl 8.6 uses much more heavily than previous versions.
>> The runtime stack (the entity that is allocated new for each coroutine)
>> might be another area that could do with attention. Actually, one of the
>> best things for the Tcl Maintainers to know would be where the expensive
>> allocations are; evidence-based optimization is better than going on
>> hunches, even for experts.
>
> Firstly, Daniel's proposal sounds like a splendid project for the GSOC
> banner.
>
> I would suggest that a range of tools be considered, not just the usual
> suspects (purify et al).  One tool I've had success with in the distant past
> was Parasoft's Insure++  - if there was interest I would be willing to
> approach Parasoft and see if they would donate a copy to be used in
> conjunction with GSOC.
>
> I have absolutely no qualms using commercial tools on open source software -
> it's the results that matter :)
>
> Steve
>
>

Re: [TCLCORE] Ideas for an optimization project

[Steve L. <st...@di...>]

On 03/03/2009, at 5:15 PM, Donal K. Fellows wrote:

> Daniel Hans wrote:
>> The aim of my project is to improve effectiveness (time, memory  
>> usage, etc.)
>> of a particular aspect of
>> an open source program. Then I have to show that my solution is  
>> really somehow
>> better than the existing one by running some tests or something.  
>> That would be
>> appreciated to use for example some profiling tools like Google  
>> Profiler or
>> gprof. I would like my project to be up to 1500-2500 lines of code.
>
> Chiseling away at the cost of a few of the key structures in Tcl would
> be a good thing. For example, it would be nice if the cost of  
> namespaces
> was lower, which Tcl 8.6 uses much more heavily than previous  
> versions.
> The runtime stack (the entity that is allocated new for each  
> coroutine)
> might be another area that could do with attention. Actually, one of  
> the
> best things for the Tcl Maintainers to know would be where the  
> expensive
> allocations are; evidence-based optimization is better than going on
> hunches, even for experts.

Firstly, Daniel's proposal sounds like a splendid project for the GSOC  
banner.

I would suggest that a range of tools be considered, not just the  
usual suspects (purify et al).  One tool I've had success with in the  
distant past was Parasoft's Insure++  - if there was interest I would  
be willing to approach Parasoft and see if they would donate a copy to  
be used in conjunction with GSOC.

I have absolutely no qualms using commercial tools on open source  
software - it's the results that matter :)

Steve

Re: [TCLCORE] Ideas for an optimization project

[Donal K. F. <don...@ma...>]

Daniel Hans wrote:
> The aim of my project is to improve effectiveness (time, memory usage, etc.)
> of a particular aspect of
> an open source program. Then I have to show that my solution is really somehow
> better than the existing one by running some tests or something. That would be
> appreciated to use for example some profiling tools like Google Profiler or
> gprof. I would like my project to be up to 1500-2500 lines of code.

Chiseling away at the cost of a few of the key structures in Tcl would
be a good thing. For example, it would be nice if the cost of namespaces
was lower, which Tcl 8.6 uses much more heavily than previous versions.
The runtime stack (the entity that is allocated new for each coroutine)
might be another area that could do with attention. Actually, one of the
best things for the Tcl Maintainers to know would be where the expensive
allocations are; evidence-based optimization is better than going on
hunches, even for experts.

There's also plenty of room for improvement on speed, but that's rather
more difficult to do as a small project.

Donal.

[TCLCORE] Ideas for an optimization project

[Daniel H. <da...@gm...>]

Hello,

my name is Daniel Hans and I participated in gsoc 2008.

Now I attend "open source programs optimization" course at my university.
In order to pass I have to write a quite simple optimization for a certain
open source program. I thought it would be great to do something for the Tcl
community.

The aim of my project is to improve effectiveness (time, memory usage, etc.)
of a particular aspect of
an open source program. Then I have to show that my solution is really somehow
better than the existing one by running some tests or something. That would be
appreciated to use for example some profiling tools like Google Profiler or
gprof. I would like my project to be up to 1500-2500 lines of code.

I have already one idea of what to do from Tomasz Kosiak, but I am sure
that there are some other things to do. I would be grateful for some other
suggestions.

Regards,
Daniel

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

On Fri, Feb 27, 2009 at 6:34 PM, Konstantin Khomoutov
<fla...@us...> wrote:
>
> If what [info level 0] internally returns is just a Tcl_ListObj,
> referencing several other Tcl_Objs, growing a list behind ::errorStack
> is OK, but when it would be converted to the user-visible form, that is,
> to a string rep, the proposed approach might turn out to be too
> simple-minded as it might blow too much data at the user.
> In this case something akin to what Erlang shell does could be used --
> it elides that part of the string representation which is beyond a
> certain threshold using "..." (see format() in [1], the description of
> the 'W' format specifier).
> Another problem is showing byte arrays.

All that is entirely the problem of the code which uses errorStack. It
may just do a [puts] on it and blast thousands of pages of control
chars (including beeps ;-) to the terminal, but that's no worse than a
[puts $x] on the very same value outside of error handling. Smarter
code can very well truncate and append "..."; this doesn't affect the
present TIP which is about making the tool available.

-Alex

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Jeff H. <je...@ac...>]

Donal K. Fellows wrote:
> Jeff Hobbs wrote:
>> I don't believe the options dict applies in this case because we are 
>> trying to establish improved error traceability, without necessarily a 
>> catch being used.  What would happen with uncaught errors?
> 
> Depends on the bgerror handler or main loop code, surely? So long as the
> info is in the result of Tcl_GetReturnOptions, we can handle it one way
> or another.

Er, not sure that translated properly from what I meant.  In the 
uncaught error case, I want to be able to inspect tcl::errorStack in the 
same way that people use ::errorInfo now.  It is the uncaught errors 
that are often more interesting for global traceback than anything else. 
  IOW, this does not fit solely into the return options.

Jeff

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Donal K. F. <don...@ma...>]

Jeff Hobbs wrote:
> I don't believe the options dict applies in this case because we are 
> trying to establish improved error traceability, without necessarily a 
> catch being used.  What would happen with uncaught errors?

Depends on the bgerror handler or main loop code, surely? So long as the
info is in the result of Tcl_GetReturnOptions, we can handle it one way
or another.

Donal.

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Jeff H. <je...@ac...>]

Alexandre Ferrieux wrote:
> On Fri, Feb 27, 2009 at 6:06 PM, Donald G Porter <dg...@ni...> wrote:
>> That said, I think the proposal itself steps off on the wrong foot
>> by proposing another magic variable.  We've had extensible
>> return options since 8.5 (TIP 90) and this is a perfect
>> place to make use of them.
> 
> Oh of course, the important thing is the content, not the vehicle :)
> ::tcl::errorStack, [interp errorStack], or $optionsdict(errorStack)
> are equally palatable to me...
> 
> (I believed ::tcl::errorStack was a neat cleanup wrt ::errorStack ...
> everything is relative !)

I don't believe the options dict applies in this case because we are 
trying to establish improved error traceability, without necessarily a 
catch being used.  What would happen with uncaught errors?

Jeff

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Konstantin K. <fla...@us...>]

Alexandre Ferrieux wrote:
>  TIP #348: SUBSTITUTED 'ERRORSTACK' / 'TRACEBACK' 
[...]
>  This TIP proposes to create a *::tcl::errorStack* variable which is a 
>  list of lists, made of the [*info level* 0] lists of command-and-args 
>  at each proc level at the time of error unwinding. 
[...]
>  The performance hit of maintaining ::errorStack should be very small, 
>  since basically it amounts to growing a (usually short) list whose 
>  elements are already existing Tcl_Obj's (the [*info level* 0] lists).  
>  However, if it proves necessary to provide an on/off switch, one can 
>  imagine a *::tcl::useErrorStack* boolean linked var. 
[...]

I don't know Tcl internals well, so here's my question: what occurs if a 
script fails, which processed some immense amount of data that was 
passed by value, following the Tcl semantics -- say, some huge list?

If what [info level 0] internally returns is just a Tcl_ListObj, 
referencing several other Tcl_Objs, growing a list behind ::errorStack 
is OK, but when it would be converted to the user-visible form, that is, 
to a string rep, the proposed approach might turn out to be too 
simple-minded as it might blow too much data at the user.

In this case something akin to what Erlang shell does could be used -- 
it elides that part of the string representation which is beyond a 
certain threshold using "..." (see format() in [1], the description of 
the 'W' format specifier).

Another problem is showing byte arrays.

1. http://www.erlang.org/doc/man/io.html

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

On Fri, Feb 27, 2009 at 6:06 PM, Donald G Porter <dg...@ni...> wrote:
>
> That said, I think the proposal itself steps off on the wrong foot
> by proposing another magic variable.  We've had extensible
> return options since 8.5 (TIP 90) and this is a perfect
> place to make use of them.

Oh of course, the important thing is the content, not the vehicle :)
::tcl::errorStack, [interp errorStack], or $optionsdict(errorStack)
are equally palatable to me...

(I believed ::tcl::errorStack was a neat cleanup wrt ::errorStack ...
everything is relative !)

-Alex

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Donald G P. <dg...@ni...>]

Alexandre Ferrieux wrote:
>  TIP #348: SUBSTITUTED 'ERRORSTACK' / 'TRACEBACK' 

Some implementation of this capability has long been
a request.  See Tracker Reports 523900 and 1047543
for two examples; there may be more.

Alexandre has a good habit of prompting action on
languishing good ideas, so I'm happy to see action here.

That said, I think the proposal itself steps off on the wrong foot
by proposing another magic variable.  We've had extensible
return options since 8.5 (TIP 90) and this is a perfect
place to make use of them.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

 TIP #348: SUBSTITUTED 'ERRORSTACK' / 'TRACEBACK' 
==================================================
 Version:      $Revision: 1.2 $
 Author:       Alexandre Ferrieux <alexandre.ferrieux_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Thursday, 26 February 2009
 URL:          http://purl.org/tcl/tip/348.html
 WebEdit:      http://purl.org/tcl/tip/edit/348
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 This TIP proposes to add a *::tcl::errorStack* variable giving a 
 "substituted" traceback similar to Python's or gdb's ones. 

 BACKGROUND 
============

 The ::errorInfo variable is a valuable tool for debugging; however, it 
 yields mostly static information regarding each level of procedure 
 call, as it only gives the static text (extracted from the source) at 
 the call site. This leads to frustrating situations, like when an error 
 occurs at a deep level of a recursive function, /::errorInfo/ 
 repeatedly reporting "f $x [foo [bar]]" or similar un-substituted 
 commands. In other languages, the traceback is more useful in that it 
 contains the actual values passed as arguments. 

 PROPOSED CHANGE 
=================

 This TIP proposes to create a *::tcl::errorStack* variable which is a 
 list of lists, made of the [*info level* 0] lists of command-and-args 
 at each proc level at the time of error unwinding. 

 RATIONALE 
===========

 In a natural implementation, its construction is analogous to 
 ::errorInfo's, which is built incrementally, one level at a time while 
 popping back from the error site. The only differences are that (1) 
 dynamic arglists (from [*info level* 0]) are stored, (2) the result is 
 a true list built by *lappend*, and (3) the granularity is coarser than 
 ::errorInfo's since there is just one element per proc level (and not 
 for intervening *while* or *foreach* constructs) and no adornment like 
 "... while executing ..." . 

 The performance hit of maintaining ::errorStack should be very small, 
 since basically it amounts to growing a (usually short) list whose 
 elements are already existing Tcl_Obj's (the [*info level* 0] lists). 

 However, if it proves necessary to provide an on/off switch, one can 
 imagine a *::tcl::useErrorStack* boolean linked var. 

 REFERENCE IMPLEMENTATION 
==========================

 A C reference implementation will be provided shortly. In the meantime, 
 a pure-Tcl proof of concept based on write traces on ::errorInfo can be 
 found at <URL:http://wiki.tcl.tk/traceback> . 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] Serializing and Mmapping dicts

[Alexandre F. <ale...@gm...>]

Hi Donal,

On Mon, Feb 23, 2009 at 2:16 PM, Donal K. Fellows
<don...@ma...> wrote:
>
> My point about arrays is that I think it might be possible to have an
> array that doesn't have a Tcl_HashTable behind it.

I followed your advice and dug through the guts of array lookups.

Then I noticed one nasty thing: the focal point, which is
TclLookupArrayElement, must return a (Var *), that is a structure
witnessing the fact that arrays are collections of variables.
So, if I plug a readonly backend (like an mmapped hashtable) behind
the Array API, each and every such lookup will require the allocation
of a "fake Var". In addition to that being cumulative side-effects
(but I've been prepared to them for values' string reps which cannot
stay in the readonly area and must be copied), it also implies
emulating much of the traditional array's internal state....

While [dict get] is just supposed to yield a Tcl_Obj.

Superficially, it would then look like dicts are way simpler to handle
than arrays...
Can you comment on this ?

-Alex

Re: [TCLCORE] Serializing and Mmapping dicts

[Alexandre F. <ale...@gm...>]

On Mon, Feb 23, 2009 at 11:41 AM, Donal K. Fellows
<don...@ma...> wrote:
> But in
> general, I think attaching to arrays has much better "Architectural
> Smell" (by analogy with "Code Smell" :-)) than attaching to dicts.

OK, thanks for the info. In fact I mentioned dicts thinking "dicts or
arrays", meaning infact the Tcl_HashTable that underlies both.
So I'll happily follow your advice and attack by the south face.

As to the value semantics and the "leaf" Tcl_Objs, of course the
serialization process takes care of that too, and yes I am aware that
serialization involves turning all pointers into offsets. Again, I'm
serializing hashtables all the time at work. So I was just proposing
to do it to Tcl hashtables too.

> In short, your current plan is a bit wonky but the larger picture scheme
> should be quite practical.

OK.

To play the devil's advocate, instead of this positive feedback, I was
also prepared to hear something along the lines of:

 "Don't do that. People can already [puts $d] or [puts [array get a]]
for small hashes, and for large ones we're entering the realm of True
Databases."

But you didn't say that, and I'm glad ;-)

-Alex