tcl-core — Tcl Core Team discussions about Tcl development

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

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

On 3/4/10, Karl C. Hansen <Kar...@br...> 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

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

[C S <us...@ya...>]

I have a tcl struct that i have created somewhere in my program like so:


set array(0.x) 10
set array(0.y) 20
set array(0.z) 30

lets say i have 20 of these structs that have been filled with data. 

I want to pass this to a proc and be able to retrieve the data(or print it out) but keep getting errors. i would also like to change values on the fly so that the original array also changes. I actually have this part working...so naturally i am confused as to why i cannot access the array when trying to output it to the screen. 

Can anyone help? Thanks much in advance.

***so if i have:***

proc print_array {arr} {

upvar arr a

#set a(0.x) 25  <---update this value

#puts  "$a(0.x)" <---Error in startup script: can't read "a(0.x)": no such element in array while executing "puts "$a(0.x)""
}

and in my main somewhere i have created and filled the array with values so i call the proc:

print_array myArray

puts "$myArray(0.x)" <---this prints out the changed value successfully from up in the proc.


      

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

[Larry W. V. <lv...@gm...>]

When I read the subject line, I thought perhaps someone was going to propose
taking the BLT vector data structure and building it into Tcl core...

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

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

On 04/03/2010 19:40, Twylite wrote:
> What Tcl_could_  do with is higher-order functions like map, filter,
> foldl/reduce, foldr, and range/iota in the core.

You should make a FRQ for that. (A [map] that has [foreach]'s extra
goodness would be rather delicious.)

Donal.

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

[Twylite <tw...@cr...>]

Karl C. Hansen wrote:
>  TIP #363: VECTOR MATH IN THE TCL CORE 
> =======================================
>
>    expr $ListA + {4 5 6}
>    expr $ListA + $ListB
namespace import tcl::mathop::*
map + $ListA $ListB

What Tcl _could_ do with is higher-order functions like map, filter, 
foldl/reduce, foldr, and range/iota in the core.

My 2c,
Twylite

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

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

On the package side there is

	http://tcl-nap.sourceforge.net/

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

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

[Karl C. H. <Kar...@Br...>]

>> So basically you're proposing to break just about everything in Tcl
>> parsing to avoid writing a simple proc for vector/matrix/tensor
>> computations ?
>>
>>     proc myexpr {x op y} {
>>...
>>     }
>>
>>    # 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}
>
> Or just Brace Your Exprs (TM) and then write a TIP which actually
> proposes what the title suggests: adding vector versions of operators to
> [expr], such that [expr {$ListA + {4 5 6}}] does what makes sense.


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*.  To do it with
compiled code I would have to essentially rewrite the entire expr engine
to handle vectors.

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.

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.

The {*} operand satisfied the need to be able to turn a list into multiple
arguments for calling a procedure without having to use eval.

The proposal fixes the above so that B *always* gets a list, because
that's what A *is*.

With the proposal, you get symmetric behavior.

* If you want a list broken into pieces when used, prefix with {*}$varname.
* If you want a list preserved as a single entity, just use $varname.

I welcome the discussion.  It took some time before '{*}' was accepted,
and in the end it is extremely useful.  I am hopeful this will precipitate
a way to get vector math into the core so that it becomes a tool capable
of going head-to-head with the high-end engines out there.

Best Regards,

Karl

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

[Damon C. <da...@tc...>]

> Possibly. It's an idea like the old "SourceForge compile farm;"
> we'd perhaps do well, before doing anything like that, to try
> to determine what issues killed it, so that our ship doesn't
> founder on the same rock.

SourceForge killed the compile farm themselves.  If I recall, it was mainly just a pain for them to manage and it cost more money than it was worth. BitMover will always have its server farm.  It's how we build our software, so there's no chance of it going away.  We do periodically remove nodes from the cluster as we deprecate a platform, but we support a helluva lot of platforms.

That being said, if we could work out the security issues, I think it would be awesome.  For the record, we already compile Tcl / Tk 8.6 on every platform that Larry listed since we ship them with our product.  We've had to make a few small build adjustments over the years as the Tcl maintainers have deprecated platforms before we do, but we still build Tcl/Tk on every platform every time we crank.  We don't run the test suite though that I'm aware of.  I'm pretty sure we run the L test suite, but I don't know if we run the entire Tcl/Tk regressions.

It would be an awesome platform for build and release testing if we can work it all out.  I would love to see an ActiveTcl-style batteries included release in binary form for all the available platforms.  Don't get me wrong, I love ActiveTcl, but there will always be platforms it's not cost-effective for them to support.  I've been asking for FreeBSD for years.

D

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

[David S. <Dav...@sy...>]

I added Vector/Matrix/Array operators to Tcl about 19 years ago. In doing so I did it with a handle based approach since textually displaying large vectors and mutli-dimensional arrays is not particularly useful. I also added waveforms for EDA at the same time and that deals with large data sets.

The core change was to overload all the operators (plus add a few) to know about the new types. The new operators had to do with defining slices of arrays using a syntactical notation the parser knows about plus some matrix operators.

Doing things with lists I think is not a great idea. The underlying data structure does not support an efficient mechanism for defining slices into large datasets that does duplicate storage. The other incompatible syntax changes are also undesirable.

I can provide more details on this if anyone is interested. I passed it to John O. and Scriptics a long time ago and they did not see a lot of demand for the functionality.

Regards
David

David W. Smith
Synopsys Scientist
 
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124

Voice: 503.547.6467
Main:  503.547.6000
Cell:    503.560.5389
FAX:   503.547.6906
Email: dav...@sy...
http://www.synopsys.com
 
Saber Accelerates Robust Design
Predictable. Repeatable. Reliable. Proven.

-----Original Message-----
From: Neil Madden [mailto:ne...@Cs...] 
Sent: Thursday, March 04, 2010 8:36 AM
To: Alexandre Ferrieux
Cc: tcl...@li...; Karl C. Hansen
Subject: Re: [TCLCORE] TIP #363: Vector Math in the Tcl Core

Alexandre Ferrieux wrote:
> On 3/4/10, Karl C. Hansen <Kar...@br...> wrote:
>>   TIP #363: VECTOR MATH IN THE TCL CORE  
>> =======================================
>>
>>   With the proposed enhancement, and a vector-math core enhancement,
>>   given the assignments above, the following would behave identically:
>>
>>    expr $ListA + {4 5 6}
>>    expr $ListA + $ListB
>>    expr {1 2 3} + $ListB
>>    expr {1 2 3} + {4 5 6}
> 
> So basically you're proposing to break just about everything in Tcl 
> parsing to avoid writing a simple proc for vector/matrix/tensor 
> computations ?
> 
>     proc myexpr {x op y} {
>       if {[llength $x]==1} {return [expr $x $op $b}
>       if {[llength $x]!=[llength $y]} {error "Dimension mismatch"}
>       set z {}
>       foreach a $x b $y {lappend z [myexpr $a $op $b]}
>       return $z
>     }
> 
>    # 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}

Or just Brace Your Exprs (TM) and then write a TIP which actually proposes what the title suggests: adding vector versions of operators to [expr], such that [expr {$ListA + {4 5 6}}] does what makes sense.

-- Neil

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

[Neil M. <ne...@Cs...>]

Alexandre Ferrieux wrote:
> On 3/4/10, Karl C. Hansen <Kar...@br...> wrote:
>>   TIP #363: VECTOR MATH IN THE TCL CORE
>>  =======================================
>>
>>   With the proposed enhancement, and a vector-math core enhancement,
>>   given the assignments above, the following would behave identically:
>>
>>    expr $ListA + {4 5 6}
>>    expr $ListA + $ListB
>>    expr {1 2 3} + $ListB
>>    expr {1 2 3} + {4 5 6}
> 
> So basically you're proposing to break just about everything in Tcl
> parsing to avoid writing a simple proc for vector/matrix/tensor
> computations ?
> 
>     proc myexpr {x op y} {
>       if {[llength $x]==1} {return [expr $x $op $b}
>       if {[llength $x]!=[llength $y]} {error "Dimension mismatch"}
>       set z {}
>       foreach a $x b $y {lappend z [myexpr $a $op $b]}
>       return $z
>     }
> 
>    # 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}

Or just Brace Your Exprs (TM) and then write a TIP which actually 
proposes what the title suggests: adding vector versions of operators to 
[expr], such that [expr {$ListA + {4 5 6}}] does what makes sense.

-- Neil

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

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

Larry McVoy wrote:
> Yes, we can, but I'll need a little education on your process.  2952904
> is checked in or it is a patch somewhere?  I just need to know how to
> do what you want.

2952904 is the bug ID at SourceForge, accessible like any other
tracker item. The patch is attached to the bug.

The test is simply to launch a Tcl shell and determine that it
doesn't write to syslog.

(For most patches, the test is to run the test suite; we're
generally quite good about including regression test cases with
our patches where needed. If you see a patch without a test case
it's usually because the existing test suite exposed the bug. The
test suite doesn't take that long to run; most of us routinely run
the whole thing on one or two configurations before committing.)

In this particular case, on the kernel in question, running the
full-up test suite *will* write to syslog, because the test suite
is intentionally exercising the floating-point software assist.
The patch is specifically a change to avoid the annoying message
from a Tcl shell that doesn't use the functionality.

> Also, I'm stewing on an idea here.  Suppose we had CVS installed on
> the entire cluster (which I think we do and if not we can).  Suppose
> we built a simple batch system where you could specify a tuple
> 
> 	<head revision>, <patch>, <test>
> 
> and we went, checked out that revision, applied the patch, built, and
> ran the test and reported back the results.
> 
> Leaving aside the security details of a test like
> 
> 	/bin/rm -rf /
> 
> or
> 
> 	cd where/we/keep/bk/src && tar cf - . | mail git+bzr+hg_guys
> 
> would a service like that make any sense?  

Possibly. It's an idea like the old "SourceForge compile farm;"
we'd perhaps do well, before doing anything like that, to try
to determine what issues killed it, so that our ship doesn't
founder on the same rock.

-- 
73 de ke9tv/2, Kevin

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

[Frédéric B. <fre...@fr...>]

Karl C. Hansen wrote:
>     2. Modify *$* substitution so that /lists/ are enclosed in braces 
>        during substitution, i.e. after *set A {1 2}* execution of *puts 
>        "$A"* yields *{1 2}* instead of *1 2* as it currently does. Note 
>        that this behavior only manifests inside of quoted strings, as 
>        the assignment *set B $A* still gives the same results as the 
>        original implementation, i.e. assigning a list to *B*. 

     % set name {Frédéric Bonnet}
     % puts "Hello, $name"
     Hello, {Frédéric Bonnet}

Hmm, no.

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

[Larry M. <lm...@bi...>]

On Thu, Mar 04, 2010 at 12:00:26AM -0500, Kevin Kenny wrote:
> Larry McVoy wrote:
>> Would it help if I had Damon what you suggest across our cluster?
>
> Not really [...]

> except that it seems to have been
> decided that proper engineering practice demands pre-commit review.

I missed that memo but I absolutely support it.  And since I whined
about that process it seems appropriate to offer to help.  All whine
and no help makes jack a dull boy :)

> But, if you've got that huge farm available, it might be worthwhile
> to use it to vet the patches for TIP 357.  Let's let them stabilize
> before we put Damon through the work, though.

OK.

> Also, I see that you have Linux-ia64, HPUX-ia64 and SGI on the list.
> Could you possibly do a test of 2952904 and verify that it fixes the
> issue where an ia64 kernel writes a spurious message to syslog
> (about a "floating point software assist fault") on Tcl startup?
> I'm certain that the coding change is harmless - it's in a platform
> independent path that is exercised in 'make test' - but have no way
> to verify that it fixes the bug. (It should have negligible performance
> impact, since the changes that it makes are either in straight-line
> code in startup, or else affect only the printing of numbers that
> have suffered gradual floating-point underflow; surely not a common
> case!)

Yes, we can, but I'll need a little education on your process.  2952904
is checked in or it is a patch somewhere?  I just need to know how to
do what you want.

Also, I'm stewing on an idea here.  Suppose we had CVS installed on
the entire cluster (which I think we do and if not we can).  Suppose
we built a simple batch system where you could specify a tuple

	<head revision>, <patch>, <test>

and we went, checked out that revision, applied the patch, built, and
ran the test and reported back the results.

Leaving aside the security details of a test like

	/bin/rm -rf /

or

	cd where/we/keep/bk/src && tar cf - . | mail git+bzr+hg_guys

would a service like that make any sense?  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

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

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

Sorry for the typo, untamed fingers.

 proc myexpr {x op y} {
     if {[llength $x]==1} {return [expr $x $op $y]}
     if {[llength $x]!=[llength $y]} {error "Dimension mismatch"}
     set z {}
     foreach a $x b $y {lappend z [myexpr $a $op $b]}
     return $z
  }

-Alex

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

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

On 3/4/10, Karl C. Hansen <Kar...@br...> wrote:
>
>   TIP #363: VECTOR MATH IN THE TCL CORE
>  =======================================
>
>   With the proposed enhancement, and a vector-math core enhancement,
>   given the assignments above, the following would behave identically:
>
>    expr $ListA + {4 5 6}
>    expr $ListA + $ListB
>    expr {1 2 3} + $ListB
>    expr {1 2 3} + {4 5 6}

So basically you're proposing to break just about everything in Tcl
parsing to avoid writing a simple proc for vector/matrix/tensor
computations ?

    proc myexpr {x op y} {
      if {[llength $x]==1} {return [expr $x $op $b}
      if {[llength $x]!=[llength $y]} {error "Dimension mismatch"}
      set z {}
      foreach a $x b $y {lappend z [myexpr $a $op $b]}
      return $z
    }

   # 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}

-Alex

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

[Karl C. H. <Kar...@Br...>]

 TIP #363: VECTOR MATH IN THE TCL CORE 
=======================================
 Version:      $Revision: 1.1 $
 Author:       Karl C. Hansen <Karl.Hansen_at_BrilliantPoints.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  9.0
 Vote:         Pending
 Created:      Tuesday, 02 March 2010
 URL:          http://purl.org/tcl/tip/363.html
 WebEdit:      http://purl.org/tcl/tip/edit/363
 Post-History: 

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

 ABSTRACT 
==========

 The "expand" operator - *{*}* - was adopted in Tcl 8.5 and is very 
 useful for simplifying code involving lists. It is proposed to add this 
 operator to the list of actions performed during processing of 
 double-quote ("), joining the *$*, *[*, and *\*, and to modify the 
 behavior of *$* in variable substitution. The proposed behavior /will/ 
 break existing substitution, but a trivial quoted-string substitution 
 restores original behavior with the new approach. The proposed approach 
 will enable eventual incorporation of vector-math to the Tcl engine 
 without changing any of the existing syntax. 

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

 It is desired to enhance the current math engine in TCL to handle 
 vector math, without having to create new syntax or add cumbersome new 
 function calls. Given the assignments *set ScalarA 1*, *set ScalarB 2*, 
 *set ListA {1 2 3}*, and *set ListB {4 5 6}*, evaluating *$ScalarA + 
 $ScalarB*, *$ListA + $ListB*, and *$ListA + $ScalarB* would all be 
 trivially understandable, with the first behaving as currently 
 implemented, the second returning a list containing the 
 element-by-element sums of the two lists, and the third returning a 
 list containing the elements of ListA incremented by the common 
 ScalarB. 

 With the proposed enhancement (see below) the expression parser would 
 receive a brace-delimited set of values wherever the lists appear, and 
 a single value wherever the scalars appear. 

 With the proposed enhancement, and a vector-math core enhancement, 
 given the assignments above, the following would behave identically: 

   expr $ListA + {4 5 6}
   expr $ListA + $ListB
   expr {1 2 3} + $ListB
   expr {1 2 3} + {4 5 6}

 With the proposed enhancement, incorporating vector math into the TCL 
 core is vastly simplified, reducing to enhancing the current math 
 handlers to perform different actions based on whether they received 
 lists or scalars or both, and checking that the vectors have the 
 appropriate element counts for the operation specified. 

 PROPOSAL 
==========

    1. Add expansion -- *{*}* -- to set of actions performed during 
       double-quote processing. 

           1. Treat expand operator as a single character 'tri-graph'. 

           2. Escape the operator -- *\{*}* -- to turn it into "regular 
              text" causing it to behave as it currently does during 
              double-quote processing. Note that this is identical with 
              the current behavior of escape, i.e., *\{* currently gives 
              *{*. With the new implementation it turns the expand 
              operator into normal text inside of a quoted string. 

    2. Modify *$* substitution so that /lists/ are enclosed in braces 
       during substitution, i.e. after *set A {1 2}* execution of *puts 
       "$A"* yields *{1 2}* instead of *1 2* as it currently does. Note 
       that this behavior only manifests inside of quoted strings, as 
       the assignment *set B $A* still gives the same results as the 
       original implementation, i.e. assigning a list to *B*. 

           1. Prefix *$* with expand *{*}* to restore current behavior, 
              i.e., with the same assignment above, execution of *puts 
              "{*}$A"* yields *1 2* instead of *{*}1 2* as it currently 
              does. Note that this provides a fairly simple way to fix 
              scripts broken by implementing this proposal. If exising 
              scripts contain quoted lists, simply (a) replace all 
              double-quoted occurrances of *{*}* with *\{*}*, and (b) 
              replace all double-quoted occurrances of *$* with *{*}$*. 

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

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

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

Larry McVoy wrote:
> Would it help if I had Damon what you suggest across our cluster?

Not really, in the case of 2962373; it's just running a bog-simple Tcl
script. If two runs get different answers *anywhere*, we've got
far worse problems than anything the patch is doing. I've been
running tclZIC every month or two since 8.5 to keep the time zone
information in sync with Olson's files. It's a completely automated
process, and I'd just commit the results - the way I've been doing
for the last couple of years - except that it seems to have been
decided that proper engineering practice demands pre-commit review.

But, if you've got that huge farm available, it might be worthwhile
to use it to vet the patches for TIP 357.  Let's let them stabilize
before we put Damon through the work, though.

Also, I see that you have Linux-ia64, HPUX-ia64 and SGI on the list.
Could you possibly do a test of 2952904 and verify that it fixes the
issue where an ia64 kernel writes a spurious message to syslog
(about a "floating point software assist fault") on Tcl startup?
I'm certain that the coding change is harmless - it's in a platform
independent path that is exercised in 'make test' - but have no way
to verify that it fixes the bug. (It should have negligible performance
impact, since the changes that it makes are either in straight-line
code in startup, or else affect only the printing of numbers that
have suffered gradual floating-point underflow; surely not a common
case!)

-- 
73 de ke9tv/2, Kevin

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

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

Joe English wrote:
> For instance: if you just want to load a DLL for preloading purposes
> you need to pass 3 dummy NULL pointers to Tcl_LoadFile();
> conversely if you want to load multiple procedure tables from
> a single shared library you either have to reimplement half
> of Tcl_LoadFile() by hand or open the shared library multiple times.

Huh? The load handle is still open, and Tcl_FindSymbol is also
exported in the ccurrent version of the TIP. It's not *that* hard
to do a trivial loop with Tcl_FindSymbol calls.  One convenience of
combining the two pieces is, as you pointed out earlier, that
(given the fact that it now fails if one or more symbols are not
found) it cleans up after itself on failure.

In any case, I wanted to make the common use case (load a shared
library, resolve a few symbols in it, and then forget about it
and let process exit clean up) to be a single call.

> Suggested interface:
> 
> EXTERN Tcl_LoadHandle *		/* [note 1]
> Tcl_LoadFile(
> 	Tcl_Interp *interp,	/* optional; for error reporting */
> 	const char *pathName,	/* [note 2] */
> 	unsigned flags);	/* [note 3] */
> 
> EXTERN  int
> Tcl_LoadProcedures(
> 	Tcl_Interp *interp,	/* optional; for error reporting */
> 	Tcl_LoadHandle *,	/* returned from Tcl_LoadFile */
> 	const char *symbols[],	/* NULL-terminated [note 4] */
> 	void *procPtrs);
> 
> 
> [note 1]: Instead of returning an int (which is always TCL_OK or
> TCL_ERROR) and storing the load handle in an "out" parameter,
> suggest returning the load handle directly, using NULL to signal
> an error.

Hmm. I tend to use the integer status when there is more than one
'out' parameter, but I suppose I could consider that.

> [note 2]: Suggest passing the path name as a 'const char *'
> instead of a Tcl_Obj *.  Rationale: in the common case,
> the name of the shared library to load is a compile-time
> constant, and it's less work to get a 'const char *' out of
> a Tcl_Obj* than it is to build a Tcl_Obj* from a const char *.

Maybe. I was thinking of Tcl_LoadFile as a Consumer of the
file name, and ISTR that there are platform-native implementations
that need to hold onto it.

> [note 3]: With reluctance: you'll probably want a flags argument.
> Not needed now, but there's a better-than-average chance that
> it'll be needed in future; adding it now will head off the
> need for a future Tcl_LoadFileEx().  (Possible enhancements
> that people are likely to ask for: use equivalent of RTLD_GLOBAL;
> *don't* use equivalent of RTLD_GLOBAL; ...)

Eeeeew. You're probably right, but... eeeeew.


> [note 4]: Instead of separate 'symc' and 'symv' parameters,
> let 'symv' be a NULL-terminated array.  Don't make programmers
> count.

You said that before. I don't mind that much using
sizeof(symv)/sizeov(*symv)

> 
> Also worth considering: following the rule of thumb "don't
> check for errors that you can't do anything about", consider
> changing Tcl_FSUnloadFile() to:
> 
>     EXTERN void Tcl_UnloadFile(Tcl_LoadHandle *);

Oh, but I can: in the case on Windows where I can't unload the
file because someone is still using it (and therefore can't
remove a copy-vfs-to-native file), I can launch a subprocess
to clean it up after I exit.

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

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

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.

I will suggest once again that Tcl_LoadFile() be split into
two pieces: one to load the shared library and a second to
load the procedure table, possibly with a third convenience
routine that does both in one step. As currently specified it's
inconvenient to do one without the other.

For instance: if you just want to load a DLL for preloading purposes
you need to pass 3 dummy NULL pointers to Tcl_LoadFile();
conversely if you want to load multiple procedure tables from
a single shared library you either have to reimplement half
of Tcl_LoadFile() by hand or open the shared library multiple times.

Suggested interface:

EXTERN Tcl_LoadHandle *		/* [note 1]
Tcl_LoadFile(
	Tcl_Interp *interp,	/* optional; for error reporting */
	const char *pathName,	/* [note 2] */
	unsigned flags);	/* [note 3] */

EXTERN  int
Tcl_LoadProcedures(
	Tcl_Interp *interp,	/* optional; for error reporting */
	Tcl_LoadHandle *,	/* returned from Tcl_LoadFile */
	const char *symbols[],	/* NULL-terminated [note 4] */
	void *procPtrs);


[note 1]: Instead of returning an int (which is always TCL_OK or
TCL_ERROR) and storing the load handle in an "out" parameter,
suggest returning the load handle directly, using NULL to signal
an error.

[note 2]: Suggest passing the path name as a 'const char *'
instead of a Tcl_Obj *.  Rationale: in the common case,
the name of the shared library to load is a compile-time
constant, and it's less work to get a 'const char *' out of
a Tcl_Obj* than it is to build a Tcl_Obj* from a const char *.

[note 3]: With reluctance: you'll probably want a flags argument.
Not needed now, but there's a better-than-average chance that
it'll be needed in future; adding it now will head off the
need for a future Tcl_LoadFileEx().  (Possible enhancements
that people are likely to ask for: use equivalent of RTLD_GLOBAL;
*don't* use equivalent of RTLD_GLOBAL; ...)

[note 4]: Instead of separate 'symc' and 'symv' parameters,
let 'symv' be a NULL-terminated array.  Don't make programmers
count.

Also worth considering: following the rule of thumb "don't
check for errors that you can't do anything about", consider
changing Tcl_FSUnloadFile() to:

    EXTERN void Tcl_UnloadFile(Tcl_LoadHandle *);



--Joe English

  jen...@fl...

[TCLCORE] Patch 2962373 awaiting review: tzdata2010c

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

I've auto-generated the patch for Olson's tzdata2010c
(available from ftp://elsie.nci.nih.giv/). The tables were
generated by the usual automatic process of

    - download and untar the latest tzdata
    - run 'tclsh tools/tclZIC.tcl path/to/tzdata2010c library/tzdata'

Nations affected are Bangladesh, Fiji, Mexico (some locales
near the US border), Paraguay, and the Antarctic bases.

Changes are available at

https://sourceforge.net/tracker/?func=detail&aid=2962373&group_id=10894&atid=310894

(I daresay there's not much to review - it's all numbers.
Probably the most effective review would simply be to run
tclZIC independently and confirm that the numbers match.)

-- 
73 de ke9tv/2, Kevin

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

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

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.

-- 
73 de ke9tv/2, Kevin

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

[Damon C. <da...@tc...>]

> ...have you considered putting the -32bit or -64bit *before* the /subcommand/ instead of after? That would make it clearer that this does not change the meaning of any previously valid command.
> 
> Also, it would allow creating an alias that explicitly selects the 32bit or 64bit version of the command while otherwise providing the behaviour of the classic registry ensemble, e.g.
> 
>  interp alias {} mypkg::registry {} registry -32bit
> 
> to minimally patch an old package that for some reason needs to operate against the -32bit version.

You are correct, and in my head, this is exactly what I was going to do in my applications.  I guess the implementation got ahead of me in my head, and I didn't think about the ordering of the option. 0-]

I will make a change to the code as well as the TIP.

> 
>> See Patch #2960976 at SourceForge  [<URL:https://sourceforge.net/support/tracker.phpaid=2960976>]. 
> 
> That URL misses a "?". Also, there doesn't seem to be any files attached yet (not that I'm actually curious, just pointing it out).

Attached the original patch (which will now be changed) and alerted Donal to the missing ?.

Damon

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

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

On 01/03/2010 5:28 AM, Kevin Kenny wrote:
> Damon Courtney wrote:
>>   TIP #362: SIMPLE 32 AND 64 BIT REGISTRY SUPPORT
>
> While we are past feature 'slush', I think that this change is both
> sufficiently constrained and sufficiently important that it should
> be considered for 8.6.
>
> The fact that Microsoft shipped the Access 2007 database format
> as a 32-bit-only product, stating that drivers will not be
> available for 64-bit ODBC (or higher-level data access systems that
> depend on it) has interesting implications for TDBC. We have an
> opportunity to provide some badly needed glue in the Access world,
> but that'll require some co-operation between 32-bit and 64-bit
> co-resident versions of Tcl.

+1

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

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

Mostly not my cup of tea, but...

Damon Courtney skrev:
>  The *registry* command will receive two new (mutually exclusive) 
>  options to specify that the given *registry* command should be executed 
>  against the 32 bit or 64 bit registry. The proposed implementation is 
>  the addition of a -32bit and a -64bit option like so: 
> 
>        *registry* /subcommand/ ?*-32bit* | *-64bit*? ?/options/? 

...have you considered putting the -32bit or -64bit *before* the 
/subcommand/ instead of after? That would make it clearer that this 
does not change the meaning of any previously valid command.

Also, it would allow creating an alias that explicitly selects the 
32bit or 64bit version of the command while otherwise providing the 
behaviour of the classic registry ensemble, e.g.

   interp alias {} mypkg::registry {} registry -32bit

to minimally patch an old package that for some reason needs to operate 
against the -32bit version.

>  See Patch #2960976 at SourceForge 
>  [<URL:https://sourceforge.net/support/tracker.phpaid=2960976>]. 

That URL misses a "?". Also, there doesn't seem to be any files 
attached yet (not that I'm actually curious, just pointing it out).

Lars Hellström

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

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

Damon Courtney wrote:
>  TIP #362: SIMPLE 32 AND 64 BIT REGISTRY SUPPORT 

While we are past feature 'slush', I think that this change is both
sufficiently constrained and sufficiently important that it should
be considered for 8.6.

The fact that Microsoft shipped the Access 2007 database format
as a 32-bit-only product, stating that drivers will not be
available for 64-bit ODBC (or higher-level data access systems that
depend on it) has interesting implications for TDBC. We have an
opportunity to provide some badly needed glue in the Access world,
but that'll require some co-operation between 32-bit and 64-bit
co-resident versions of Tcl.

-- 
73 de ke9tv/2, Kevin