tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

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

On Fri, Nov 03, 2006 at 05:33:37PM +0800, Steve Landers wrote:
> Now, before I waste any more time p*ssing into the wind - what's the  
> feeling of the TCT re #291. If Joe's attitude is the predominant one  
> then I won't bother pushing this. Conversely, if the concept of #291  
> is reasonable and just needs refinement then I'm more than happy to  
> invest the time.
> 
> Just don't make me waste a bunch of time so you can say "hmmmm ...  
> maybe not".

I dunno whether the core will go for it or not but we have a pair
of scripts (one stolen from configure or something and a post
processing one) that do some of this.  It's what gets the version
string in BK.

If it is of any help then I'm happy to forward what we use to Steve.
He's probably got something better (in which case I'd love it if 
I could use it).

Here's a sample:

bk-4.0-alpha-glibc22-linux.bin
bk-4.0-hppa-glibc23-linux.bin
bk-4.0-hppa-hpux10.bin
bk-4.0-hppa-hpux11-32bit.bin
bk-4.0-hppa-hpux11.bin
bk-4.0-ia64-glibc23-linux.bin
bk-4.0-ia64-hpux11.bin
bk-4.0-mips-glibc22-linux.bin
bk-4.0-mips-irix.bin
bk-4.0-powerpc-aix.bin
bk-4.0-powerpc-glibc23-linux.bin
bk-4.0-powerpc-macosx.bin
bk-4.0-s390-glibc23-linux.bin
bk-4.0-sparc-glibc23-linux.bin
bk-4.0-sparc-solaris.bin
bk-4.0-x86-freebsd2.bin
bk-4.0-x86-freebsd3.bin
bk-4.0-x86-freebsd4.bin
bk-4.0-x86-freebsd5.bin
bk-4.0-x86-freebsd6.bin
bk-4.0-x86-glibc20-linux.bin
bk-4.0-x86-glibc21-linux.bin
bk-4.0-x86-glibc22-linux.bin
bk-4.0-x86-glibc23-linux.bin
bk-4.0-x86-glibc24-linux.bin
bk-4.0-x86-netbsd.bin
bk-4.0-x86-openbsd.bin
bk-4.0-x86-sco.bin
bk-4.0-x86-solaris.bin
bk-4.0-x86-win32.exe
bk-4.0-x86_64-glibc23-linux.bin
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

[<ke...@cr...>]

don...@ma... said:
> As far as I can see, there are effectively three, no, four choices:
>   1: Reject any attempt to put anything like the 'platform' package
>      in/with the core.
>   2: Wait for a solution that can perfectly identify all platforms that
>      ever might possibly exist.
>   3: Accept Steve's partial solution on the pragmatic grounds of it being
>      good enough for most users at the moment.
>   4: Sit on our hands.

Donal, you and I are in violent agreement.  (3) is the only sensible
choice.  Given the pragmatics, I'd like to see:

    3 bis: Accept Steve's partial solution - augmented with some means of
           updating it outside the normal Tcl release cycle.

and further:

    3 ter: Extend the ability to update outside the release cycle to other
           volatile portions of the core, such as tzdata and msgs.

and maybe even wrap this up as

    3 quater: Sort out bundled packages so that we can define a "usual"
              mechanism for packaging "non-core" components that nontheless
              ship "with the core."


--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [TCLCORE] TIP #294: The "entier" Function: It's Spelt "entire"

[<ke...@cr...>]

"Entier" is not a misspelling.

"Entier" is a French word meaning 'integer,' which was used for coercion
to an integer in Algol 60, Algol 68, Simula 67, and BCPL.  "Entire" was
not the word I intended.

That said, I realize that "entier" is perhaps too obscure in the modern
era.  "Entire" is worse.  "Integer" is misleading, since it suggests
a platform-dependent native integer; likewise "bigint" is misleading, since
the "entier" function coerces to a native integer if possible.  "Floor"
is more or less accurate in terms of the function's operation, but already
taken for coercion to the corresponding floating-point number.

In short, I chose a bad name because it appeared that all the good ones
were taken.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

[Virden, L. W. <lv...@ca...>]

Would a layerd approach be too complex?

That is, have basic support in the core. Then a layer on top of it, with
some sort of code that selects the tcllib code first if newer, that
people could work out the details for new platforms. Then, during the
next Tcl release, the proven additions are moved from the tcllib module
to the core, and the cycle begins again.

I was just trying to figure out a way to bridge the two camps.


--=20
<URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20

[TCLCORE] TIP #294: The "entier" Function: It's Spelt "entire"

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

 TIP #294: THE "ENTIER" FUNCTION: IT'S SPELT "ENTIRE" 
======================================================
 Version:      $Revision: 1.1 $
 Author:       Lars Hellström <Lars.Hellstrom_at_residenset.net>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.5
 Vote:         Pending
 Created:      Friday, 03 November 2006
 URL:          http://purl.org/tcl/tip/294.html
 WebEdit:      http://purl.org/tcl/tip/edit/294
 Post-History: 

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

 ABSTRACT 
==========

 It is proposed that the *expr* function *entier*() introduced by [TIP 
 #237] is renamed to *entire*(). 

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

 This appears to be a typo. Even though American English differs from 
 British English in that many words which in the latter end in "-re" are 
 spelt "-er", this is not one of these. Neither /Merriam-Webster Online/ 
 nor /dictionary.com/ recognises "entier", whereas both list "entire". A 
 Google search for "entier" reports 61400000 pages, but if one narrows 
 it down to pages in English the count drops to 943000, and even then 
 most of these are in fact written in French. Within the first 60 
 matches, only 3 show "entier" occurring in English text, and in all 
 these cases it is part of a trademark/product name. 

 ALTERNATIVES 
==============

 While the term "entire" meaning "whole" is known in mathematics, it is 
 rarely applied to numbers. The typical thing to be entire is instead a 
 function [<URL:http://planetmath.org/encyclopedia/Entire.html>], and 
 that is quite unrelated to integers. Better names could be: 

     * *whole* ("whole number" sounds a bit childish, but unlike "entire 
       number", it would probably be recognised as meaning "integer") 

     * *integer* (this is the proper name for the concept in question) 

 It could also be argued that the function is rather silly, since 
 "coercing to integer" (which seems to be the same as truncation, i.e., 
 rounding towards zero) is mathematically a rather useless operation. 
 More useful operations are rounding to the nearest integer (available 
 as round), floor (rounding downwards), and ceiling (rounding upwards), 
 since these admit tight inequalities that do not depend on the sign of 
 the number. Currently the two latter have to be had by combining 
 *round* and *floor*/*ceil*, whereas separate functions *ifloor* and 
 *iceil* would have been more appropriate. Getting them would however 
 require actually implementing something new. 

 IMPLEMENTATION 
================

 This TIP can be implemented by applying the following command prefix to 
 the contents of the files of the Tcl source tree: 

    string map {entier entire Entier Entire}

 (It may of course be more convenient to use the search and replace 
 functionality of a text editor.) Grepping indicates that the only C 
 file affected would be /generic/tclBasic.c*, the only Tcl files 
 affected would be /tests/expr.test/ and /tests/info.test/, and the only 
 documentation file affected would be /doc/mathfunc.n/. 

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

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] Status of TIP #89

[Carlos T. <ca...@el...>]

On Friday 03 November 2006 03:25, dg...@ni... wrote:
> Quoting Robert Hicks <si...@gm...>:
> > This was the tip to add "Try/Catch Exception Handling in the Core". It
> > showed up on the wiki and I read the tip and it says the vote is
> > "pending".
> >
> > Is this going to make it in?
>
> No.
>
> If this feature is important to you, bring it up again when the 8.5
> freeze/stabilization work dies down, so you can help aim it for
> 8.6.
>
> DGP

Why is not included in the 8.5 features? I compiled the code as an extension 
and works flawlessly.

-- 
Carlos Tasada
Software Developer

The Electronic Farm

Tel  +34 971 166 571
Fax  +34 971 647 871
 
www.electronicfarm.com

This e-mail and any attached files may contain confidential and/or privileged 
information. If you are not the
intended recipient (or have received this e-mail in error) please notify the 
sender immediately and destroy
this e-mail. Any unauthorised copying, disclosure or distribution of the 
material in this e-mail is strictly forbidden

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

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

    Wait a minute.  How is it that the 'platform' package is not able to 
identify a new platform exactly?  As I understand it, it probably works 
pretty similar to the package I wrote for my own stuff.  We look at 
tcl_platform to pull some information and then twiddle it to make it 
pretty.  IE:

tcl_platform(byteOrder) = bigEndian
tcl_platform(machine) = sun4u
tcl_platform(os) = SunOS
tcl_platform(osVersion) = 5.6
tcl_platform(platform) = unix
tcl_platform(user) = lwv26

    Becomes Solaris-sparc.  Why?  Because SunOS-sun4u looks stupid 
(thanks, Sun).  So, what would platform::identifier do if it ran into 
Solaris and we'd never seen it before?  You'd get SunOS-sun4u since the 
default is most likely to just return 
$tcl_platform(os)-$tcl_platform(machine).

    What does a repository do when it doesn't recognize that OS?  Well, 
one of three things:

1.  Let's say the repository really DOES have packages for Solaris, but 
it thinks the platform is supposed to be Solaris-sparc since that's what 
it is in the newest 'platform' package, but the user doesn't have that 
yet.  The repository code could just as easily do a quick map since it 
knows SunOS-sun4u is really Solaris-sparc and install the correct 
binaries.  Might even update the platform package while we're there.

2.  Let's say the repository doesn't know what the hell you're talking 
about.  The package installer could try and grab the 'platform' package 
first before grabbing other packages to make sure it had the latest.  
This would all be done on the package install side, not the repository.  
It's pure-Tcl, and it just uses tcl_platform, so there's no real risk of 
it being incompatible with the version they're running.

3.  Screw it.  I really don't have binaries for that platform, so you 
asking for them does no good anyway.

    This isn't that tough.  Every platform, regardless of whether we've 
heard of it or not, is going to give us SOMETHING in tcl_platform.  And 
if the 'platform' package has never heard of it, we're going to get a 
default identifier.  Maybe it's the right one, maybe it's not.  Either 
way, if we've never heard of it, chances are good it's not in our 
repository anyway.

Damon


> Hmm, there's a counterargument to that, though.  As Joe points out,
> the Core platform package is always likely to be obsolete on a
> given installation.  As such, it's likely to be the first thing
> downloaded from a package repository.  And if it *is* written in
> Tcl, then it oughtn't to need anything extra to run from the
> repository.
>
> Nevertheless, it feels strange to have something in the repository
> that is a dependency of virtually every package there . The natural
> question would arise, "why isn't this in the Core?" 
>
> In short, there are forces pulling 'platform' into the Core,
> and forces keeping it out. Perhaps the only real resolution 
> of this approach-avoidance conflict would be to get off our arses 
> and sort out "bundled packages."  That way, the Core installation could 
> come with at least *some* platform package, and those that need to (which 
> might indeed be most of us) could load an updated version from the \
> repository.
>
>   

Re: [TCLCORE] Status of TIP #89

[Kristoffer L. <se...@fi...>]

On Thu, 2 Nov 2006, Robert Hicks wrote:

> Important might be too strong a word but it seems a "nice to have", so
> yes I will wait and bring it up again.

For what it's worth, I'm with you on that and would love to have a proper 
try-catch system in the core. I mostly use a self-built system on top of 
the normal [catch] command but performance can suffer.

It's a fairly fundamental thing which has made its way into many 
languages. Just makes life easier.

                               / http://www.fishpool.com/~setok/

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

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

Kevin Kenny wrote:
> Nevertheless, it feels strange to have something in the repository
> that is a dependency of virtually every package there . The natural
> question would arise, "why isn't this in the Core?" 

It's more than that. It's a dependency of the repository client itself.
You can't use the repository (or at least you can't use it to acquire
binary packages, which are what you need really need a repository for
anyway) without the package as you can't figure out what build of a
package to ask for.

As far as I can see, there are effectively three, no, four choices:
  1: Reject any attempt to put anything like the 'platform' package
     in/with the core.
  2: Wait for a solution that can perfectly identify all platforms that
     ever might possibly exist.
  3: Accept Steve's partial solution on the pragmatic grounds of it being
     good enough for most users at the moment.
  4: Sit on our hands.

Option 1 is a rejection of the principle of supplying a package that can
identify the platform, and I think it would be not the best possibility.
I regard option 4 (refusing to choose) as an abdication of our
responsibility and I promise to mock anyone going for option 2 most
mercilessly!

(On the matter of updates, as long as the package is returning the
correct platform descriptor, it doesn't matter whether it is up to date
or not. But if that's the case, we must be strict about not allowing
changes to the API. Let it do what it does and nothing else.)

Donal.

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

[<ke...@cr...>]

don...@ma... said:
>  Just because the package is written in Tcl doesn't mean that it
> should not be taken as a contribution!

Indeed - otherwise, we'd not have the 8.5 [clock]! ;)


don...@ma... said:
> Right now, we're starting to move into the brave new world of
> supporting a real package repository. This is great! (And about time
> too!) But supporting this requires some small amount of code extra so
> that we can know what platform we're dealing with (in the sense of
> "what package instance do I download and/or use so that it will work
> in the current interpreter") so that we can tie the whole thing
> together.

Hmm, there's a counterargument to that, though.  As Joe points out,
the Core platform package is always likely to be obsolete on a
given installation.  As such, it's likely to be the first thing
downloaded from a package repository.  And if it *is* written in
Tcl, then it oughtn't to need anything extra to run from the
repository.

Nevertheless, it feels strange to have something in the repository
that is a dependency of virtually every package there . The natural
question would arise, "why isn't this in the Core?" 

In short, there are forces pulling 'platform' into the Core,
and forces keeping it out. Perhaps the only real resolution 
of this approach-avoidance conflict would be to get off our arses 
and sort out "bundled packages."  That way, the Core installation could 
come with at least *some* platform package, and those that need to (which 
might indeed be most of us) could load an updated version from the \
repository.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [TCLCORE] =?iso-8859-15?q?TIP_=23290=3A_Registration_of_Custom_Er?= =?iso-8859-15?q?ror_Handler_Scripts?=

[<ec...@we...>]

> Actually, as the author of [using] and several other control  
> constructs, I can say that you definitely do end up catching  
> everything just to rethrow errors again. Apart from being essential  
> in order to clean up resources (i.e., equivalent of a "finally"  
> clause), it is also necessary if you want to catch "break" or  
> "continue" exceptions. This isn't some obscure corner case: any time  
> you want to [catch] anything you have to catch everything and then  
> rethrow those exceptions you don't know how to deal with.

You mean things like this?:

set err [catch {...} m]
switch -- $err {
1 {do this}
2 {do that}
default {return -code $err "Hae? $m"}
}

It means that you expect return codes 1 and 2, but everything else is not expected and thus rethrown. An errorhandler on -uncaught woud pitch in for the "default" branch above. It helps you not to find out where and how the error exactly happened in the catch {} block, although it helps you certainly to see how it came there.

This makes me think whether it might be useful to register custom handlers for different return codes...


Eckhard

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

Re: [TCLCORE] TIP #290: Registration of Custom Error Handler Scripts

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

On 3 Nov 2006, at 08:44, Eckhard Lehmann wrote:
>> Just an endorsement to this... You wouldn't implement a procedure  
>> this way in practice.
> ^^^^
>
>> Why? Because you can't debug it with *any* method - it is useless  
>> here to catch the error just to rethrow it at a different place.  
>> The only good reason to catch an error and rethrow it is to do  
>> some special processing *immediately* - e.g.
>
> Ahhmm I should have seen that [using] actually *does* this kind of  
> special processing (by closing the $chan no matter if error or  
> not). My fault, the above marked was a wrong statement... sorry.
>
> But the point stays the same.

Actually, as the author of [using] and several other control  
constructs, I can say that you definitely do end up catching  
everything just to rethrow errors again. Apart from being essential  
in order to clean up resources (i.e., equivalent of a "finally"  
clause), it is also necessary if you want to catch "break" or  
"continue" exceptions. This isn't some obscure corner case: any time  
you want to [catch] anything you have to catch everything and then  
rethrow those exceptions you don't know how to deal with.

-- Neil

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

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

Steve Landers wrote:
> Now, before I waste any more time p*ssing into the wind - what's the  
> feeling of the TCT re #291. If Joe's attitude is the predominant one  
> then I won't bother pushing this. Conversely, if the concept of #291  
> is reasonable and just needs refinement then I'm more than happy to  
> invest the time.

Right now, we're starting to move into the brave new world of supporting
a real package repository. This is great! (And about time too!) But
supporting this requires some small amount of code extra so that we can
know what platform we're dealing with (in the sense of "what package
instance do I download and/or use so that it will work in the current
interpreter") so that we can tie the whole thing together.

Steve's got a package that provides this (or at least a good approx to
this) and which will therefore complete the foundational work for the
repository by standardizing the platform descriptors. It's therefore
needed in the core, even if just as a "package that we import from
elsewhere from time to time". We do have precedents for this (the MP
math library, the timezone data). Just because the package is written in
Tcl doesn't mean that it should not be taken as a contribution!

Donal.

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

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

On 03/11/2006, at 1:28 PM, Joe English wrote:

> Now if the platform package were the kind of thing we could
> get right the first time, then sure, put it in the core and
> _eventually_ everyone could rely on it (some sooner, some later).

And this attitude is why Tcl is (in the eyes of many) a dead or dying  
language. At least the Debianistas understand that "stable" means  
"obsolete" :/

> But it's not: by its very nature, [platform::identifier] is
> going to be perpetually incomplete and frequently out of date.
> No matter how extensive the implementation, it's going to
> be obsolete the moment somebody ports Tcl to a new platform.
>
> Of course putting it in tcllib won't make it universally
> available either, but it *will* make it easier for people
> who need the latest version to get it when they need it.

Like I said, I'm more than happy for it to go into Tcllib, as well as  
be in Tcl itself. Now that I think about it, why is tcltest in Tcl  
and not Tcllib? ;-)

>> Remember that the TIP authors are at the pointy-end of delivery  
>> multi-
>> platform distributions and extensions - and only too aware of the
>> problems that entails.
>
> Y'know, I've done a bit of development and deployment myself.

Indeed - and you know I know that.

Now, before I waste any more time p*ssing into the wind - what's the  
feeling of the TCT re #291. If Joe's attitude is the predominant one  
then I won't bother pushing this. Conversely, if the concept of #291  
is reasonable and just needs refinement then I'm more than happy to  
invest the time.

Just don't make me waste a bunch of time so you can say "hmmmm ...  
maybe not".

Steve

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

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

Brian Griffin wrote:
> I'd like to see a build time option to remove the alpha compatibility.  
> We don't currently use 8.5, but when we do, I know someone, somewhere 
> will start using {expand} and I don't want to have to deal with this 
> issue again when transitioning to 9.0.

The explanation is simple: I messed up the editing of the TIP. :-)

Donal.

Re: [TCLCORE] =?iso-8859-15?q?TIP_=23290=3A_Registration_of_Custom_Er?= =?iso-8859-15?q?ror_Handler_Scripts?=

[Eckhard L. <ec...@we...>]

> Just an endorsement to this... You wouldn't implement a procedure this w=
ay in practice.
^^^^

> Why=3F Because you can't debug it with *any* method - it is useless here t=
o catch the error just to rethrow it at a different place. The only good r=
eason to catch an error and rethrow it is to do some special processing *i=
mmediately* - e.g.

Ahhmm I should have seen that [using] actually *does* this kind of special=
 processing (by closing the $chan no matter if error or not). My fault, th=
e above marked was a wrong statement... sorry.

But the point stays the same.


Eckhard

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Viren-Scan f=FCr Ihren PC! Jetzt f=FCr jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/=3Fmc=3D022222

Re: [TCLCORE] =?iso-8859-15?q?TIP_=23290=3A_Registration_of_Custom_Er?= =?iso-8859-15?q?ror_Handler_Scripts?=

[<ec...@we...>]

> Yes, but the rethrowing of an error could take place very far from 
> where it originally happened. With something like 
> http://wiki.tcl.tk/using, you don't get the requested chance to debug 
> errors that happen within the [using], since that command catches and 
> rethrows errors.

Just an endorsement to this... You wouldn't implement a procedure this way in practice.
Why? Because you can't debug it with *any* method - it is useless here to catch the error just to rethrow it at a different place. The only good reason to catch an error and rethrow it is to do some special processing *immediately* - e.g.

- close resources
- do some logging mumble.
- etc...

In the case of [using], it would look like this:
 
 proc using {varName chan script} {
     upvar 1 $varName var
     set var $chan
     set rc [catch { uplevel 1 $script } result]
     
     # log any error and proceed
     if {$rc} {
         puts "Yipieee, an error: $result"
     }

     catch { close $chan }
     return -code $rc
 }

or like this:

 proc using {varName chan script} {
     upvar 1 $varName var
     set var $chan
     set rc [catch { uplevel 1 $script } result]
     
     # step out on error. Close the channel before
     if {$rc} {
         catch {close $chan}
         error "Yippieee, there was an error: $result"
     }
     
     catch { close $chan }
     return $result
 }

In the first case, you don't want to debug anything yet - you consider that it is enough to have it logged. 
In the second case, you get an error immediately, which can be trapped and debugged. BTW, the new [info frame] command (TIP #280) is very helpful here.

Eckhard


PS:
<cite src="http://lambda-the-ultimate.org/node/1544#comment-18176">
People have an unfortunate tendency to ignore these basic conveniences and focus on hypothetical software-engineering mumbo-jumbo scenarios. "Oh my, what if Luke installed an exception handler that ROT13 encoded every string on the heap, then how would Jane debug her programs?" This is not the way to illumination.
</cite>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

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

Steve Landers wrote:
> Joe English wrote:
> > This would be an excellent candidate for tcllib, but I don't
> > believe it belongs in the core.
> > [...]
>
> Good points Joe, but I don't see this as an "either/or" situation.
>
> I'm more than happy for platform to go into tcllib and evolve
> quicker, but strong believe that it needs to go into the core as
> well, so developers can rely on it being present.

Putting this -- or anything, for that matter -- "into the core"
doesn't help all that much when it comes to universal availability,
since it leaves a large class of end users behind.  Namely: Unix
users who rely on whatever Tcl build comes with the OS.

There's a big delay between when a facility goes into the core
and when *all* developers can rely on it being present.
Most of us have to wait for:

 + The next Tcl release -- around 6-8 months for dot-dot releases
   (and upwards of four years for dot releases, but that's a
   different problem).

 + The OS distributor to pick it up -- a couple of weeks if they're
   paying attention, longer if they're not, or if they're in their
   own freeze phase.

 + The OS distributor to make a new release -- typically 6-12 months,
   much longer for "enterprise editions" and for Debian.

 + The end users to upgrade their OS -- this can take anywhere
   from 24 hours (Gentoo users and other bleeding-edgers)
   to "never" (people working for companies with obstructive
   QA policies).

Now if the platform package were the kind of thing we could
get right the first time, then sure, put it in the core and
_eventually_ everyone could rely on it (some sooner, some later).

But it's not: by its very nature, [platform::identifier] is
going to be perpetually incomplete and frequently out of date.
No matter how extensive the implementation, it's going to
be obsolete the moment somebody ports Tcl to a new platform.

Of course putting it in tcllib won't make it universally
available either, but it *will* make it easier for people
who need the latest version to get it when they need it.

> Remember that the TIP authors are at the pointy-end of delivery multi-
> platform distributions and extensions - and only too aware of the
> problems that entails.

Y'know, I've done a bit of development and deployment myself.


--Joe English

  jen...@fl...

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[Michael A. C. <mi...@cl...>]

On 11/2/06, Will Duquette <wi...@wj...> wrote:
>
> On Nov 2, 2006, at 5:25 PM, Robert Hicks wrote:
>
> > Neil Madden wrote:
> >> Still digesting this, but one point leaps out at me:
> >> ...
> >>>     2. The usage of both *{expand}* and *{}* will be deprecated.
> >>>        However, both idioms will remain enabled as alternatives.
> >> ...
> >>
> >> What does "remain enabled" mean in relation to {}? Does this TIP also
> >> enable {} as expansion syntax in the 8.5+ line?
> >>
> >
> > Oh yes, why would you do that? There should only be one idiom for
> > expand. You shouldn't leave alternatives in as that is just asking for
> > abuse.
>
> ActiveTcl 8.5 (though not, IIRC, the core Tcl builds) supports {} as
> an alternate syntax for {expand}.  I remember Jeff Hobbs talking about
> it at the conference in '05.

Jeff did talk about it at the conference.  {} in lieu of {expand} is
principally ActiveTcl or a customized build only, not the stock Tcl
distribution.  The code for {} support is in the 8.5 core but it is
#ifdef'ed out by default.  (You'd have to define ALLOW_EMPTY_EXPAND to
get it.)

> I believe the notion was (Warning! I might be making this up!) that
> we might eventually have several syntax escapes of the form
> {expand} or {this} or {that} or {<your word here>}, but that
> {expand} was likely to always be the most common, therefore if
> the word were left out, as in {}, it would be reasonable to let
> it default to {expand}.
>
> Me, I like {*} better.

Ditto, many times over! :-)

Michael

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[Will D. <wi...@wj...>]

On Nov 2, 2006, at 5:25 PM, Robert Hicks wrote:

> Neil Madden wrote:
>> On 2 Nov 2006, at 23:12, Miguel Sofer wrote:
>>>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*}
>>> ===============================================
>>
>> Still digesting this, but one point leaps out at me:
>> ...
>>>     2. The usage of both *{expand}* and *{}* will be deprecated.
>>>        However, both idioms will remain enabled as alternatives.
>> ...
>>
>> What does "remain enabled" mean in relation to {}? Does this TIP also
>> enable {} as expansion syntax in the 8.5+ line?
>>
>
> Oh yes, why would you do that? There should only be one idiom for
> expand. You shouldn't leave alternatives in as that is just asking for
> abuse.

ActiveTcl 8.5 (though not, IIRC, the core Tcl builds) supports {} as
an alternate syntax for {expand}.  I remember Jeff Hobbs talking about
it at the conference in '05.

I believe the notion was (Warning! I might be making this up!) that
we might eventually have several syntax escapes of the form
{expand} or {this} or {that} or {<your word here>}, but that
{expand} was likely to always be the most common, therefore if
the word were left out, as in {}, it would be reasonable to let
it default to {expand}.

Me, I like {*} better.

Will

>
> Robert
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] Status of TIP #89

[Robert H. <si...@gm...>]

dg...@ni... wrote:
> Quoting Robert Hicks <si...@gm...>:
> 
>> This was the tip to add "Try/Catch Exception Handling in the Core". It 
>> showed up on the wiki and I read the tip and it says the vote is "pending".
>>
>> Is this going to make it in?
> 
> No.
> 
> If this feature is important to you, bring it up again when the 8.5
> freeze/stabilization work dies down, so you can help aim it for
> 8.6.
> 
> DGP
> 

Important might be too strong a word but it seems a "nice to have", so 
yes I will wait and bring it up again.

Robert

Re: [TCLCORE] Status of TIP #89

[<dg...@ni...>]

Quoting Robert Hicks <si...@gm...>:

> This was the tip to add "Try/Catch Exception Handling in the Core". It 
> showed up on the wiki and I read the tip and it says the vote is "pending".
> 
> Is this going to make it in?

No.

If this feature is important to you, bring it up again when the 8.5
freeze/stabilization work dies down, so you can help aim it for
8.6.

DGP

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[Robert H. <si...@gm...>]

Neil Madden wrote:
> On 2 Nov 2006, at 23:12, Miguel Sofer wrote:
>>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*}
>> ===============================================
> 
> Still digesting this, but one point leaps out at me:
> ...
>>     2. The usage of both *{expand}* and *{}* will be deprecated.
>>        However, both idioms will remain enabled as alternatives.
> ...
> 
> What does "remain enabled" mean in relation to {}? Does this TIP also  
> enable {} as expansion syntax in the 8.5+ line?
> 

Oh yes, why would you do that? There should only be one idiom for 
expand. You shouldn't leave alternatives in as that is just asking for 
abuse.

Robert

[TCLCORE] Status of TIP #89

[Robert H. <si...@gm...>]

This was the tip to add "Try/Catch Exception Handling in the Core". It 
showed up on the wiki and I read the tip and it says the vote is "pending".

Is this going to make it in?

Robert

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[Robert H. <si...@gm...>]

Donal K. Fellows wrote:
> Miguel Sofer wrote:
>>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*} 
> 
> I draw the attention of members of this list who are not members of the
> TCT to the fact that this TIP has already been voted on and accepted (we
> didn't want this lost in the noise of OO flaming!) The results of the
> vote were as follows:
> 

I just want to say as a plain old user that I like {*} much more than 
{expand}. Thanks for changing it guys.

Robert