From: Donal K. F. <don...@ma...> - 2012-09-10 21:51:26
Attachments:
donal_k_fellows.vcf
|
On 10/09/2012 17:25, Lars Hellström wrote: > So I suppose the big question now is: Is this something that could make it > into Tcl 8.6 (and thus would need TIPping-with-reference-implementation > right away), or is it something that would go into 8.7 (and thus could be > left as a weekend fun project for some rainy day)? Since it's not addressing a problem in something that was added in 8.6, fixing is not top priority; everyone who might use it is working around things right now. The onus for justifying pushing the change in 8.6 is on you (because every extra feature is a potential to delay). That's not to say that this shouldn't be done after 8.6. It's just that the case for doing it in 8.6 is rather weak. Donal. |
From: Stuart C. <st...@be...> - 2012-09-10 23:03:19
|
On 09/10/12 10:46, Donald G Porter wrote: > The "-force" option is a misfeature we ought not continue. It exists > to work around a design bug we fixed many releases ago. So it could be taken out of all the .test files? Stu |
From: Kevin K. <kk...@ny...> - 2012-08-27 16:27:34
|
On 08/27/2012 04:40 AM, Harald Oehlmann wrote: >> All four are approved for incorporation into Tcl (hopefully without >> breaking [clock], yes?) > > I want to take this as a motivation to really attack the issue (See also > the motivation post by DGP). > Unfortunately, the solution within the tip is half-baken and I ask for > some time to design a better solution and rewrite a tip. > > I am sorry for that but I am convinced, this is the best way to go. > I might be wrong, but at least I will try. > > A good solution for TIP 399 must reload locale files on a locale change. > > Local clock never worked for me anyway, and was always broken in reflect > of a locale change. Try: > clock format [clock seconds] -format %B > msgcat::mclocale fr > clock format [clock seconds] -format %B" Did you omit '-locale current'? The default locale for [clock] is the root locale {}: you need to override that to get localised strings. This decision was by design: far more calls to [clock format] produce time strings that are consumed by programs than ones that produce time strings that are read by humans, and it was thought preferable to make the default behaviour entirely locale-independent. -- 73 de ke9tv/2, Kevin |
From: Harald O. <har...@el...> - 2012-08-27 16:58:21
|
Am 27.08.2012 18:27, schrieb Kevin Kenny: > On 08/27/2012 04:40 AM, Harald Oehlmann wrote: > >>> All four are approved for incorporation into Tcl (hopefully without >>> breaking [clock], yes?) >> >> I want to take this as a motivation to really attack the issue (See also >> the motivation post by DGP). >> Unfortunately, the solution within the tip is half-baken and I ask for >> some time to design a better solution and rewrite a tip. >> >> I am sorry for that but I am convinced, this is the best way to go. >> I might be wrong, but at least I will try. >> >> A good solution for TIP 399 must reload locale files on a locale change. >> >> Local clock never worked for me anyway, and was always broken in reflect >> of a locale change. Try: >> clock format [clock seconds] -format %B >> msgcat::mclocale fr >> clock format [clock seconds] -format %B" > > Did you omit '-locale current'? The default locale for [clock] is the > root locale {}: you need to override that to get localised strings. This > decision was by design: far more calls to [clock format] produce time > strings that are consumed by programs than ones that produce time > strings that are read by humans, and it was thought preferable to make > the default behaviour entirely locale-independent. Thank you, Kevin, didn't know that. I looked to the clock code. It currently implements the dynamic patch (as planed) for its purpose. The package remembers which locale files were already loaded and loads any missing file on demand. In future, the dynamic msgcat package may do that. - Harald |
From: Jeff R. <dv...@di...> - 2012-09-10 18:21:41
|
Lars Hellström wrote: > Maybe a variant like > > namespace importfrom ?-force? $ns ?$cmdname ...? > > would make it easier to do The Right Thing here? What about something like perl's EXPORT_TAGS, where a single name is set up as an alias for a group of related items. namespace export -tag @common foo bar baz ... namespace import ::ns1::@common ;# imports foo, bar, baz -J |
From: Donald G P. <don...@ni...> - 2012-09-10 19:08:31
|
On 09/10/2012 02:21 PM, Jeff Rogers wrote: > What about something like perl's EXPORT_TAGS, where a single name is set > up as an alias for a group of related items. Has the same problem as glob patterns. The importer doesn't know what he's getting. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Martin L. <mar...@gm...> - 2012-09-10 19:52:57
|
But the importer can inspect what he got: namespace inscope :: ns {namespace import} Martin Lemburg Berlin / Deutschland mar...@gm... http://about.me/Martin0815 ------- Original message ------- > From: Donald G Porter <don...@ni...> > To: tcl...@li... > Sent: 10/9/'12, 21:08 > > On 09/10/2012 02:21 PM, Jeff Rogers wrote: > >> What about something like perl's EXPORT_TAGS, where a single name is set >> up as an alias for a group of related items. > > Has the same problem as glob patterns. The importer doesn't know > what he's getting. > |
From: Stuart C. <st...@be...> - 2012-09-10 23:05:42
|
On 09/10/12 10:05, Donald G Porter wrote: > On 09/10/2012 09:23 AM, Harald Oehlmann wrote: >> I only fear that it is common practive to do a: >> namespace import msgcat::* > > The people persisting in that "common practice" need to be trained > out of it. > > The ability to import by glob pattern, rather than by explicitly naming > each desired command to import, I believe, has to be seen as only a > convenience for interactive work. > Really? Who doesn't do that? Sure, I know what commands from a package I'll be using but why do I have to list them all when importing? The package creator theoretically specified only the necessary commands to export and I import * to get them. Stu |
From: Donald G P. <don...@ni...> - 2012-09-11 13:44:28
|
>>> I only fear that it is common practive to do a: >>> namespace import msgcat::* >> >> The people persisting in that "common practice" need to be trained >> out of it. > Sure, I know what commands from a package I'll be using > but why do I have to list them all when importing? > The package creator theoretically specified only the > necessary commands to export and I import * to get them. Look back at what started this tangent in the first place. Why have the authors of msgcat felt compelled to use command names matching "mc*" ? That's what comes from the scenario where importers don't know what they're getting, ask for everything anyway, and the cautious package authors try to reduce the risks of what they're doing. A ball of misdirected incentives, negating much of the value of namespaces. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Stuart C. <st...@be...> - 2012-09-11 08:05:21
|
On 09/11/12 03:53, Donal K. Fellows wrote: > On 11/09/2012 00:03, Stuart Cassoff wrote: >> On 09/10/12 10:46, Donald G Porter wrote: >>> The "-force" option is a misfeature we ought not continue. It exists >>> to work around a design bug we fixed many releases ago. >> >> So it could be taken out of all the .test files? > > Yeah, probably. Or at least not put in any new ones. :-) > > Donal. > Groovy. Since I was using the Tcl test setup as an example for my own work I can at least rip that out of my .test files. Serves me right for thinking that Tcl makes a good role model? ;) Stu |
From: Martin L. <mar...@gm...> - 2012-09-11 13:33:03
|
Dear Stuart, Good to hear, that I'm not the only one using glob patterns while importing commands from another namespace. Greetings, Martin Lemburg Berlin / Deutschland mar...@gm... http://about.me/Martin0815 ------- Original message ------- > From: Stuart Cassoff <st...@be...> > To: tcl...@li... > Sent: 11/9/'12, 1:05 > > On 09/10/12 10:05, Donald G Porter wrote: >> On 09/10/2012 09:23 AM, Harald Oehlmann wrote: >>> I only fear that it is common practive to do a: >>> namespace import msgcat::* >> >> The people persisting in that "common practice" need to be trained >> out of it. >> >> The ability to import by glob pattern, rather than by explicitly naming >> each desired command to import, I believe, has to be seen as only a >> convenience for interactive work. >> > > Really? Who doesn't do that? > Sure, I know what commands from a package I'll be using > but why do I have to list them all when importing? > The package creator theoretically specified only the > necessary commands to export and I import * to get them. > > Stu > > > > --------------------------------------------------------------------------- > --- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |