Send Tcl-Core mailing list submissions to
tcl-core@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/tcl-core
or, via email, send a message with subject or body 'help' to
tcl-core-request@lists.sourceforge.net

You can reach the person managing the list at
tcl-core-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tcl-Core digest..."

Today's Topics:

1. Re: TIP #363: Vector Math in the Tcl Core (Alexandre Ferrieux)
2. Re: passing tcl "structs"(array of structs) as parameters
(Donal K. Fellows)
3. Re: TIP #363: Vector Math in the Tcl Core (Neil Madden)
4. slave interpreter namespace sharing (Frank Graffagnino)
5. Re: slave interpreter namespace sharing (Donal K. Fellows)
6. Re: slave interpreter namespace sharing (Lars Hellstr?m)
7. Re: slave interpreter namespace sharing (Frank Graffagnino)

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

Message: 1
Date: Fri, 5 Mar 2010 08:55:01 +0100
From: Alexandre Ferrieux
Subject: Re: [TCLCORE] TIP #363: Vector Math in the Tcl Core
To: Karl.Hansen@brilliantpoints.com
Cc: tcl-core@lists.sourceforge.net, Neil.Madden@nottingham.ac.uk
Message-ID:
<5e9437311003042355x2827ffe8u9b203e73679fd5c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 3/4/10, Karl C. Hansen wrote:
> >> So basically you're proposing to break just about everything in Tcl
> >> parsing to avoid writing a simple proc for vector/matrix/tensor
> >> computations ?
> >>
> >> # The following four do the same today without breaking anything:
> >> myexpr $ListA + {4 5 6}
> >> myexpr $ListA + $ListB
> >> myexpr {1 2 3} + $ListB
> >> myexpr {1 2 3} + {4 5 6}
>
> Alexandre - that and a dozen other ways force it to work in the existing
> system but not in a way that is integrated and *fast*.

Ah, you're interested in speed ?
Then forget all your string-level brace-juggling, and as Neil says,
brace your exprs !

Indeed when you write

expr $ListA + $ListB

regardless of patches in the expression syntax, the five strings

(contents of var ListA)
" "
"+"
" "
(contents of var ListB)

go through INST_CONCAT1, purely at string level, and lose any internal
rep of the values, while [expr {$ListA+$ListB}] keeps everything and
doesn't need *any* scary redefinition of things like '$'...

-Alex

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

Message: 2
Date: Fri, 05 Mar 2010 08:55:39 +0000
From: "Donal K. Fellows"
Subject: Re: [TCLCORE] passing tcl "structs"(array of structs) as
parameters
To: C S
Cc: tcl-core@lists.sourceforge.net
Message-ID: <4B90C70B.9070006@manchester.ac.uk>
Content-Type: text/plain; charset="utf-8"

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: donal_k_fellows.vcf
Type: text/x-vcard
Size: 241 bytes
Desc: not available

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

Message: 3
Date: Fri, 5 Mar 2010 11:58:50 +0000
From: Neil Madden
Subject: Re: [TCLCORE] TIP #363: Vector Math in the Tcl Core
To: Karl.Hansen@BrilliantPoints.com
Cc: tcl-core@lists.sourceforge.net
Message-ID:
Content-Type: text/plain; charset=us-ascii

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.

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

Message: 4
Date: Tue, 9 Mar 2010 17:30:00 -0600
From: Frank Graffagnino
Subject: [TCLCORE] slave interpreter namespace sharing
To: tcl-core@lists.sourceforge.net
Message-ID:
<381376aa1003091530r4489f67di5c4e416381cd756d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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

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

Message: 5
Date: Wed, 10 Mar 2010 09:28:16 +0000
From: "Donal K. Fellows"
Subject: Re: [TCLCORE] slave interpreter namespace sharing
To: tcl-core@lists.sourceforge.net, frankie@graffagnino.net
Message-ID: <4B976630.1000102@manchester.ac.uk>
Content-Type: text/plain; charset="utf-8"

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: donal_k_fellows.vcf
Type: text/x-vcard
Size: 241 bytes
Desc: not available

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

Message: 6
Date: Wed, 10 Mar 2010 15:11:10 +0100
From: Lars Hellstr?m
Subject: Re: [TCLCORE] slave interpreter namespace sharing
To: "Donal K. Fellows"
Cc: frankie@graffagnino.net, tcl-core@lists.sourceforge.net
Message-ID: <4B97A87E.4020305@residenset.net>
Content-Type: text/plain; charset=UTF-8; format=flowed

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

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

Message: 7
Date: Wed, 10 Mar 2010 09:19:54 -0600
From: Frank Graffagnino
Subject: Re: [TCLCORE] slave interpreter namespace sharing
To: "Donal K. Fellows"
Cc: tcl-core@lists.sourceforge.net
Message-ID:
<381376aa1003100719i550a7daei6d78314cdb2f71bc@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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
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.
>

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

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

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

_______________________________________________
Tcl-Core mailing list
Tcl-Core@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core

End of Tcl-Core Digest, Vol 46, Issue 5
***************************************