tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

On 17/03/2010 05:27, Elchonon Edelson wrote:
> What are the problems with Expect that make threads such a non-option?

I don't know. To be honest, I don't really grok the innards of Expect
enough to be able to say off-hand. However, if you're up to looking then
the things to check for are fork() and signal handling; they're known to
be problems (due to the notifier and POSIX botches, respectively). Both
of those become nastier when there are threads about.

I ought to look at the Expect sources sometime so I can argue from
knowledge instead of (mainly) ignorance. :-)

> What options are there for a fix, or a work-around? If there were a good
> writeup of the issue, a good starting point would be to include a note
> in the Expect distribution, and possibly have Expect's ./configure issue
> a warning if you're configuring against a threaded Tcl.

Yes. If fork and signals are just in there "because it is convenient"
then it might be better off to say that people wanting them should add a
[package require TclX] too. Separation of concerns and all that.

> While I like Expect, and would very much hate to lose it, I don't think
> an extension should be able to hold Tcl hostage in the way that it
> sounds like Expect is doing. My opinion is that you should do what you
> need to with Tcl. By all means, of course, let Expect know how and why
> it's being broken, and maybe if what's being broken is important enough,
> someone will find a way to fix it. In the mean time, if they need it
> that badly, they'll still be able to make their own non-threaded build,
> just for Expect, right?

My big concern with that is that a lot of the deployed uses of Tcl are
for Expect, and they tend to be people who are not following what we're
doing here closely. Being able to say "oh, you'll need an updated
Expect" is one type of story, saying "oh, that doesn't work any more" is
a totally different one.

Donal.

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

On 16/03/2010 23:42, Reinhard Max wrote:
> On Tue, 16 Mar 2010 at 21:26, Jeff Hobbs wrote:
>> [...] but I believe that Reinhard was in process with a variant
>> patch that had "improved" characteristics.
>
> that one got sort of stuck due to the lack of volunteers to test it
> and help fixing/finishing it on non-Linux platforms (or better: my
> lack to find such people).

I'm very happy to help review. Point at the patch and I'll see how it
looks (and check for buildability/working-ness on OSX, up to the extent
that my available IPv6 networking allows).

Donal.

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Elchonon E. <cas...@gm...>]

Donal K. Fellows wrote:
>   Thread package... We've needed this for ages (along with making the
>   threaded build default) so that we can take advantage of modern
>   hardware, and it is a quite thoroughly tested configuration and
>   package, but we keep getting stymied by Expect on Unix. Can we dare
>   to move anyway? Can we tell if Expect needs problem things like
>   [fork]? A lot of expect scripts don't.
What are the problems with Expect that make threads such a non-option? 
What options are there for a fix, or a work-around? If there were a good 
writeup of the issue, a good starting point would be to include a note 
in the Expect distribution, and possibly have Expect's ./configure issue 
a warning if you're configuring against a threaded Tcl.

While I like Expect, and would very much hate to lose it, I don't think 
an extension should be able to hold Tcl hostage in the way that it 
sounds like Expect is doing. My opinion is that you should do what you 
need to with Tcl. By all means, of course, let Expect know how and why 
it's being broken, and maybe if what's being broken is important enough, 
someone will find a way to fix it. In the mean time, if they need it 
that badly, they'll still be able to make their own non-threaded build, 
just for Expect, right?

-EE

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Joe E. <jen...@fl...>]

Donal K. Fellows wrote:

> OK, the specific discussions:
>
>    #348 and #362 are two TIPs that I just don't have a great feel for
>    one way or the other. They might well be ready right now; I'm too
>    ignorant to be able to say. :-)
>
>    #357 is very close, and I keep getting surprised that Kevin and Joe
>    can't reach agreement over it. What can the rest of us do to help?

As I explained to kbk off-list, I have no objections to the
TIP as it stands; I just think that the API could be improved.
Feel free to ignore if you don't think that the refactoring
I proposed is not, in fact, an improvement :-)

I certainly did not intend to block the release over this.
There was a CFD; I gave my review notes.  That's all.

TIP#348 r1.10 (-errorstack return option) looks OK to me too.

No opinion on TIP#362 (64-bit Registry support).


--Joe English

  jen...@fl...

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Kevin K. <ke...@ac...>]

Donal K. Fellows wrote:
>     #357 on better ways to handle libraries
>     #362 on a fix for the [registry] command

I'm the TCT member responsible for both of these.  And I intend to have
both of them voting next week, if someone else can tally (I'm
going to be traveling.) They just need fiddly changes.

>   Non-TIPs (included for "strategic" reasons which we can discuss):
>     Add basic IPv6 support (no official API changes)
>     Add the Thread package to tcl/pkgs/
Maybe tdbc::odbc and tdbc::sqlite as well, if we can sort out the
dependency issues.  The MySQL, Postgres and Oracle native drivers
are going to be more work (but can go in post-release, since we've
agreed that pkgs/ doesn't need to be tied to the Core release cycle).

>     Make the Unix [tk_getOpenFile] more powerful
>   (Plus the usual bugfixes, of course.)
> 
> What's involved in making a release if we ignore these things? Well, the
> HEAD is (usually) buildable from checkout and mostly passes its test
> suite so we're not actually that far. Given how much has changed since
> 8.6b1, I'd actually argue that the best thing we can do now is to make
> another beta. Now.

+1. Just don't burn out Don!

-- 
73 de ke9tv/2, Kevin

[TCLCORE] [Fwd: Re: The Long and Winding Road.. to 8.6.0]

[Kevin K. <kev...@gm...>]

Forwarding to tcl-core, in case other core maintainers want to comment

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Kevin K. <kev...@gm...>]

Donal K. Fellows wrote:
>   #357 is very close, and I keep getting surprised that Kevin and Joe
>   can't reach agreement over it. What can the rest of us do to help?

Joe and I have reached private agreement.  I'm doing his suggested
change to make symv on Tcl_LoadFile NULL-terminated, and adding an
(unused) 'flags' option so that he can have his RTLD_GLOBAL at some
point.  We've agreed that the remaining changes aren't needed in the
first release. Expect a vote late in the week.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Kevin K. <ke...@ac...>]

Donald G Porter wrote:
> Donal K. Fellows wrote:
>> What's involved in making a release if we ignore these things? 
> 
> I need bundle-able releases of Itcl and tdbc.
> 

Let me know what you need. I keep the "vendor branch" of tdbc in
release-worthy condition (although it needs the drivers to be useful).

-- 
73 de k9etv/2, Kevin

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Reinhard M. <ma...@tc...>]

Hi,

On Tue, 16 Mar 2010 at 21:26, Jeff Hobbs wrote:

> [...] but I believe that Reinhard was in process with a variant 
> patch that had "improved" characteristics.

that one got sort of stuck due to the lack of volunteers to test it 
and help fixing/finishing it on non-Linux platforms (or better: my 
lack to find such people).


cu
 	Reinhard

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

On 16/03/2010 18:36, Donal K. Fellows wrote:
> TIPs:
>   #348 on better information about errors
>   #357 on better ways to handle libraries
>   #362 on a fix for the [registry] command
> Non-TIPs (included for "strategic" reasons which we can discuss):
>   Add basic IPv6 support (no official API changes)
>   Add the Thread package to tcl/pkgs/
>   Make the Unix [tk_getOpenFile] more powerful

For these things, it's probably better if, instead of making any
specific commitment to have them in 8.6b2 or not, we instead set a
strict timebox on how long we'll wait. Call me impatient if you want,
but the community has been waiting for b2 for 16 months now. :-)

OK, the specific discussions:

   #348 and #362 are two TIPs that I just don't have a great feel for
   one way or the other. They might well be ready right now; I'm too
   ignorant to be able to say. :-)

   #357 is very close, and I keep getting surprised that Kevin and Joe
   can't reach agreement over it. What can the rest of us do to help?

   IPv6... This is the one we have to deal with. Possibly also back-port
   to 8.5. The issue is that (if my reading of the runes is right) it
   won't be very long (year or two) before the IPv4 address space is
   exhausted in some parts of the world. Getting Tcl ready before the
   catastrophe strikes is a good thing, especially as it takes time to
   roll things out into distributions. I'd like the script-level API to
   be as non-invasive as possible too, please (but only TCP is needed
   over IPv6; other things are out of scope).

   Thread package... We've needed this for ages (along with making the
   threaded build default) so that we can take advantage of modern
   hardware, and it is a quite thoroughly tested configuration and
   package, but we keep getting stymied by Expect on Unix. Can we dare
   to move anyway? Can we tell if Expect needs problem things like
   [fork]? A lot of expect scripts don't.

   Unix [tk_getOpenFile]... Oh well, mea culpa. In my defence, it's
   actually a tricky thing to improve in the ways suggested in the
   submitted patches.

In summary, of these I'd say that two (IPv6 and Thread) are very
important due to the changing nature of the environment in which Tcl
finds itself; the driving changes are coming whether we change ourselves
or not. And #357 would be nice to have too (as it is a blocker for
including TDBC drivers with a Tcl distribution). The other three could
slip b2 without any great harm, though if they get done that's cool too.

I'm not planning to listen to anyone who suggests that we should wait
until all prio9 bugs are dealt with. Well, not unless they also work on
dealing with the remaining nasty ones... ;-)

Donal.

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

On 3/16/10, Donal K. Fellows <don...@ma...> wrote:
> Hi everyone
>
>  I think I speak for just about everyone here when I say that I'd like to
>  see Tcl 8.6.0. After all, it will have many interesting features and
>  there's plenty of evidence that it is able to support intensive use
>  (e.g., the Wiki runs on 8.6). But we seem to be stuck at 8.6b1.1!
>
>  What needs to change?
>
>  Well, someone (several of us someones in fact) needs to pull their
>  finger out and get on with it! It's about as simple as that.
>
>  More specifically, we need to stop waiting on features before doing
>  another beta. The features that I see people being interested in are:
>
>   TIPs:
>     #348 on better information about errors
>     #357 on better ways to handle libraries
>     #362 on a fix for the [registry] command
>   Non-TIPs (included for "strategic" reasons which we can discuss):
>     Add basic IPv6 support (no official API changes)
>     Add the Thread package to tcl/pkgs/
>     Make the Unix [tk_getOpenFile] more powerful
>   (Plus the usual bugfixes, of course.)
>
>  What's involved in making a release if we ignore these things? Well, the
>  HEAD is (usually) buildable from checkout and mostly passes its test
>  suite so we're not actually that far. Given how much has changed since
>  8.6b1, I'd actually argue that the best thing we can do now is to make
>  another beta. Now.
>
>  Or at least a release candidate for a beta so that we can check to see
>  if we build in at least the critical configurations on key platforms.
>  I'd argue that none of the features above are likely to be worth waiting
>  a beta on, and the benefit for getting out of our current stasis far
>  exceeds the cost of not having all the above. (Only build bugs should be
>  fixed in the period from b2RC1 to b2, so I'd hope that we can make that
>  very short.)
>
>  Once 8.6b2 is out, we can sort the above features out (or explicitly
>  decide to postpone them) and refocus on getting to the finishing line.
>  The main point is that we've got to stop messing about. The community
>  deserves better from us.
>
>  Donal.

I don't know exactly for the other items, but please note that #348 is
close to being fully baked, only awaiting Don's review. Given this
status, it would be very disappointing to let that TIP miss a second
chance of contact with beta testers.

-Alex

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

Donal K. Fellows wrote:
> On 16/03/2010 21:04, Donald G Porter wrote:
>> Donal K. Fellows wrote:
>>> What's involved in making a release if we ignore these things?
>> I need bundle-able releases of Itcl and tdbc.
> 
> I'd argue that those are not blockers, merely good-to-haves. We really
> cannot (as a matter of general policy) allow contributed packages to
> delay a beta release.

I'm not going to engage this argument and simply take your message
as the prod it's intended to be.

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

On 16/03/2010 21:04, Donald G Porter wrote:
> Donal K. Fellows wrote:
>> What's involved in making a release if we ignore these things?
>
> I need bundle-able releases of Itcl and tdbc.

I'd argue that those are not blockers, merely good-to-haves. We really
cannot (as a matter of general policy) allow contributed packages to
delay a beta release.

Donal.

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

Donal K. Fellows wrote:
> What's involved in making a release if we ignore these things? 

I need bundle-able releases of Itcl and tdbc.

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

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

On 2010-03-16, at 11:36 AM, Donal K. Fellows wrote:
>  Non-TIPs (included for "strategic" reasons which we can discuss):
>    Add basic IPv6 support (no official API changes)

This actually has adds one option to 'socket' (-type or -family, depending on what you want to choose), as you need to have support to provide selection of the INET type for key applications.

I provided a patch for this that was tested, but I believe that Reinhard was in process with a variant patch that had "improved" characteristics.

Jeff

[TCLCORE] The Long and Winding Road.. to 8.6.0

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

Hi everyone

I think I speak for just about everyone here when I say that I'd like to
see Tcl 8.6.0. After all, it will have many interesting features and
there's plenty of evidence that it is able to support intensive use
(e.g., the Wiki runs on 8.6). But we seem to be stuck at 8.6b1.1!

What needs to change?

Well, someone (several of us someones in fact) needs to pull their
finger out and get on with it! It's about as simple as that.

More specifically, we need to stop waiting on features before doing
another beta. The features that I see people being interested in are:

   TIPs:
     #348 on better information about errors
     #357 on better ways to handle libraries
     #362 on a fix for the [registry] command
   Non-TIPs (included for "strategic" reasons which we can discuss):
     Add basic IPv6 support (no official API changes)
     Add the Thread package to tcl/pkgs/
     Make the Unix [tk_getOpenFile] more powerful
   (Plus the usual bugfixes, of course.)

What's involved in making a release if we ignore these things? Well, the
HEAD is (usually) buildable from checkout and mostly passes its test
suite so we're not actually that far. Given how much has changed since
8.6b1, I'd actually argue that the best thing we can do now is to make
another beta. Now.

Or at least a release candidate for a beta so that we can check to see
if we build in at least the critical configurations on key platforms.
I'd argue that none of the features above are likely to be worth waiting
a beta on, and the benefit for getting out of our current stasis far
exceeds the cost of not having all the above. (Only build bugs should be
fixed in the period from b2RC1 to b2, so I'd hope that we can make that
very short.)

Once 8.6b2 is out, we can sort the above features out (or explicitly
decide to postpone them) and refocus on getting to the finishing line.
The main point is that we've got to stop messing about. The community
deserves better from us.

Donal.

Re: [TCLCORE] CFV WARNING: TIP #357: Export TclLoadFile

[Kevin K. <kev...@gm...>]

Kevin Kenny wrote:
> I've adopted most of the suggestions that other Tcl'ers have made
> for TIP #357 - "Export TclLoadFile", and the reference implementation is 
> also nearly complete. Please be informed that unless there is further
> substantive discussion of TIP #357, I intend to call the vote early next
> week.
> 

In light of Joe English's extensive comments, I withdraw the warning
and I have no immediate plans to call the vote.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] CFV WARNING: TIP #362: Simple 32 and 64 bit Registry Support

[Kevin K. <kev...@gm...>]

Damon Courtney, the author of TIP #362, informs me that he considers
it ready for vote.

If I hear no substantive comment by Friday, I intend to call the vote.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] Call For Ideas - GSoC/Tcl 2010

[Andreas K. <and...@ac...>]

Hi all.

As we seem to have found our admin and backup-admin for handling the Tcl 
Community's application to GSoC 2010 it is now also the time to look over our 
page of ideas for 2010, i.e.

	http://wiki.tcl.tk/23186

and spruce it up a bit.

Prospective mentors and students (and anybody else actually),

*	if you have an idea or project, please record it on that page.

*	if you believe that an idea or project from previous years (x)
	is still feasible, please copy it over to the new page

Further, regardless of your ability to work on the ideas page, please spread 
the word among your community and contacts about the Summer of Code in general, 
and Tcl in particular.

Lastly, the general GSoC/Tcl meeting point for prospective and actual students 
and mentors is the tcl-gsoc mailing list at SourceForge. To subscribe see

	https://lists.sourceforge.net/lists/listinfo/tcl-gsoc

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Ad x)	2009	http://wiki.tcl.tk/22182
	2008	http://wiki.tcl.tk/20832
	2007	http://wiki.tcl.tk/17872

-- 
Sincerely,
     Andreas Kupries <an...@ac...>
     Developer @    <http://www.activestate.com/>

Re: [TCLCORE] slave interpreter namespace sharing

[Frank G. <fr...@gr...>]

sorry for being on the wrong list... but you've definitely answered my
question!!! I think I need to look into another way to do what i
want!!!

Thanks.

FG


On Wed, Mar 10, 2010 at 3:28 AM, Donal K. Fellows
<don...@ma...> wrote:
> On 09/03/2010 23:30, Frank Graffagnino wrote:
>>
>> I'm experimenting with a slave interpreter for the first time.
>> Basically, I have an untrusted string I want to execute, so I started
>> looking into safe slave interpreters.
>>
>> So far, I think this is what I want, as I can expose each of the
>> commands I want individually from the master to the slave with the
>> alias command.
>>
>> But I've run into a snag: I can't seem to find any way to expose the
>> global variables to the slave interpreter.  Before moving to a slave
>> interpreter, I was previously executing the command with a "uplevel
>> #0" which gave me access to everything.  Is there any way to have this
>> sort of access to global variables inside a slave interpreter?
>
> While this is strictly off-topic for this list (general help is on
> comp.lang.tcl) it's got some interesting aspects so I'll answer here anyway.
>
> There's currently no direct support for coupling a variable in one
> interpreter to a variable in another; only interpreter aliases (which
> are commands) can bridge the divide. However, what you could do is have
> traces on the variables that you want to bridge which call a command
> that is an alias to a handler in master interpreter that imposes
> whatever policy is desired on variable reads and writes.
>
> More awkward is the fact that if the master interpreter wants to update
> the value, the slave has no way of being notified of it. The only way to
> make it happen right is for the master to run a suitable [set] in the
> slave, which is very messy. Arguably, this is a general weakness (which
> is why I think it merits the attention of this list). The easiest
> workaround that I'm aware of is this:
>
> % interp create i
> % i eval {
>    namespace export set
>    namespace eval foo {
>      namespace import ::set
>      rename ::set ::RealSet
>      rename ::foo::set ::set
>      namespace delete ::foo
>    }
>    namespace export -clear
>  }
> % i hide RealSet set
> % i invokehidden set env(PATH)
> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>
> The aim is that you make the special undivertable version of [set]
> before letting user code in the interpreter. (In a safe interpreter you
> wouldn't have the global env array, of course, but the rest of it will
> work just the same.) The big down-side of the above code is that it
> makes the [set] command in the child interpreter impossible to bytecode
> compile, which is a real issue for speed ([set] is very common!)
>
> Donal.
>

Re: [TCLCORE] slave interpreter namespace sharing

[Lars H. <Lar...@re...>]

Donal K. Fellows skrev:
> More awkward is the fact that if the master interpreter wants to update
> the value, the slave has no way of being notified of it. The only way to
> make it happen right is for the master to run a suitable [set] in the
> slave, which is very messy. Arguably, this is a general weakness (which
> is why I think it merits the attention of this list). The easiest
> workaround that I'm aware of is this:
> 
> % interp create i
> % i eval {
>     namespace export set
>     namespace eval foo {
>       namespace import ::set
>       rename ::set ::RealSet
>       rename ::foo::set ::set
>       namespace delete ::foo
>     }
>     namespace export -clear
>   }
> % i hide RealSet set
> % i invokehidden set env(PATH)
> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

Anything wrong with

% interp create i
% i hide set
% i alias set i invokehidden set

? (Well, it shows up as an extra level in the -errorinfo, but I can 
live with that.)

But since we're discussing slave interpreters, I'd like to mention two 
things I've been missing:

  1. [interp catch] -- like [interp eval], but does a [catch] on the 
slave side, while setting variables in the master. (Or returns a list 
which the master can [lassign] as it prefers.)

  2. [interp unknown] -- divert [unknown] processing to some other 
interpreter (typically {}). With ordinary [unknown] or [namespace 
unknown], it is (AFAICT) necessary to have at least one unknown-ish 
command in the slave, even if that command can be an alias. An [interp 
unknown] could do without that, thus better approximate an empty 
interpreter.

Lars Hellström

Re: [TCLCORE] slave interpreter namespace sharing

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

On 09/03/2010 23:30, Frank Graffagnino wrote:
> I'm experimenting with a slave interpreter for the first time.
> Basically, I have an untrusted string I want to execute, so I started
> looking into safe slave interpreters.
>
> So far, I think this is what I want, as I can expose each of the
> commands I want individually from the master to the slave with the
> alias command.
>
> But I've run into a snag: I can't seem to find any way to expose the
> global variables to the slave interpreter.  Before moving to a slave
> interpreter, I was previously executing the command with a "uplevel
> #0" which gave me access to everything.  Is there any way to have this
> sort of access to global variables inside a slave interpreter?

While this is strictly off-topic for this list (general help is on
comp.lang.tcl) it's got some interesting aspects so I'll answer here anyway.

There's currently no direct support for coupling a variable in one
interpreter to a variable in another; only interpreter aliases (which
are commands) can bridge the divide. However, what you could do is have
traces on the variables that you want to bridge which call a command
that is an alias to a handler in master interpreter that imposes
whatever policy is desired on variable reads and writes.

More awkward is the fact that if the master interpreter wants to update
the value, the slave has no way of being notified of it. The only way to
make it happen right is for the master to run a suitable [set] in the
slave, which is very messy. Arguably, this is a general weakness (which
is why I think it merits the attention of this list). The easiest
workaround that I'm aware of is this:

% interp create i
% i eval {
     namespace export set
     namespace eval foo {
       namespace import ::set
       rename ::set ::RealSet
       rename ::foo::set ::set
       namespace delete ::foo
     }
     namespace export -clear
   }
% i hide RealSet set
% i invokehidden set env(PATH)
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

The aim is that you make the special undivertable version of [set]
before letting user code in the interpreter. (In a safe interpreter you
wouldn't have the global env array, of course, but the rest of it will
work just the same.) The big down-side of the above code is that it
makes the [set] command in the child interpreter impossible to bytecode
compile, which is a real issue for speed ([set] is very common!)

Donal.

[TCLCORE] slave interpreter namespace sharing

[Frank G. <fr...@gr...>]

I'm experimenting with a slave interpreter for the first time.
Basically, I have an untrusted string I want to execute, so I started
looking into safe slave interpreters.

So far, I think this is what I want, as I can expose each of the
commands I want individually from the master to the slave with the
alias command.

But I've run into a snag: I can't seem to find any way to expose the
global variables to the slave interpreter.  Before moving to a slave
interpreter, I was previously executing the command with a "uplevel
#0" which gave me access to everything.  Is there any way to have this
sort of access to global variables inside a slave interpreter?

Thanks for any help or suggestions!

FG

Re: [TCLCORE] TIP #363: Vector Math in the Tcl Core

[Neil M. <Nei...@no...>]

On 4 Mar 2010, at 17:24, Karl C. Hansen wrote:
> [...]
> 
> Neil - intriguing idea.  I had not tried it, and it turns out that:
> 
>    expr {1 + {2 3 4}}
> 
> gives
> 
>    can't use non-numeric string as operand of "+"
> 
> I'll have to track down that error message, but if it is occurring at the
> math-handler rather than in the expression tree this may be a possible
> approach.

The + operator here is seeing two arguments: one it recognises as a number, and one it doesn't recognise: the string "2 3 4". You can use the command version of + to see the same error message:

 % tcl::mathop::+ 1 {2 3 4}
 can't use non-numeric string as operand of "+"

If this was an expression syntax error you'd have seen an error like the following:

 % expr {1 +. {2 3 4}}
 invalid character "."
 in expression "1 +. {2 3 4}"

So really the only work to do is to find the implementation of +, -, * etc and possibly any functions, and adjust them to do the right thing. Whether there is always one unambigous right thing to do in each case is perhaps a little more tricky, but at the least it should preserve the existing behaviour for scalar arguments.

My own preference would be to introduce new versions of the operators that exhibit this behaviour, otherwise it might lead to subtle bugs where previously there were only obvious bugs. E.g., use expr {1 +/ {2 3 4}} or something similar.

> One positive side-effect of the proposed approach is that it essentially
> "reverses" what is done by '{*}' when using 'eval' strings.  For example,
> these work:
> 
>    set A 1
>    eval set B $A
> 
> but these do not:
> 
>    set A {1 2 3}
>    eval set B $A
> 
> Why?  Because of the "hidden"
> 'convert-everything-in-rest-of-line-to-string' that strips the fact that A
> is a list, so you end up with multiple values for the 'set' command.

This is a behaviour of [eval] and [expr] commands, not the parser: both of these commands do double-substitution, which results in this behaviour. This is why it has been good practice for at least 10 years now to always brace expressions, and to [list]-quote anything you pass to [eval]. If you want to "fix" this behaviour, then you only need to change the behaviour of these commands, not the parser. However, there are historical reasons why these commands behave the way they do, and changing them now is probably more trouble than it is worth (almost every script in existence would need to be changed).

My own opinion is that [expr] currently does it's job well enough. Existing operators can be "lifted" to work over lists (or a custom high-performance vector type) by using higher-order combinators like map, filter, fold/reduce, zip, etc. Adding high-performance versions of these commands to the core would be great. As would, adding a vector/matrix type.

-- NeilThis message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [TCLCORE] passing tcl "structs"(array of structs) as parameters

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

On 05/03/2010 07:23, C S wrote:
> I have a tcl struct that i have created somewhere in my program like so:
[...]
> Can anyone help? Thanks much in advance.

This isn't a general help forum. That's the comp.lang.tcl newsgroup.
    http://groups.google.com/group/comp.lang.tcl

> ***so if i have:***
>
> proc print_array {arr} {
>
> upvar arr a

Your problem looks to be there. Switch to:
   upvar $arr a

You might also need to add a level parameter if that array is always global:
   upvar #0 $arr a

OTOH, you might also be better off using lists and dictionaries as your 
basic data structure. Or considering a database like sqlite. Ask on 
comp.lang.tcl for help with those.

Donal.