|
From: Andreas L. <av...@lo...> - 2008-06-13 18:33:21
|
> On Fri, Jun 13, 2008 at 3:49 PM, Andreas Leitgeb <av...@lo...> wrote: > > The "string is dict" could be used for some entrance check of > > a parameter, that could be already a dict, or an arbitrary > > string, and where one needs to be "rather safe than sorry". I just noticed that current implementation of [string is list $l] fails to shortcut for pure list-objects. How can that be observed in tcl? so: string is list [lrepeat 1000000 [lrepeat 1000000 x]] If it bombs the tclsh, it tried to serialize the list: "string representation size exceeds sane bounds" Is that a bug, or a deliberate miss out? Anyway, it limits the practicability of [string is dict|list...] for parameter entry-validation in procedures severely. I think, it makes sense to make the "string is"-family fit for parameter-validation purposes, but that would require that the value to be checked is not principially shimmered to string, at least not if it is already of the type it's being queried for. Otoh, it's acceptable that e.g. a list-object queried for it's integerness is still shimmered. |
|
From: Laurent D. <lau...@uf...> - 2000-07-18 15:22:20
|
-- Laurent Duperval "Montreal winters are an intelligence test, U|Force - Java Center and we who are here have failed it." Phone: (514) 282-8484 ext. 228 -Doug Camilli mailto:lau...@uf... Penguin Power! |
|
From: Donald G P. <dg...@em...> - 2003-11-20 17:57:56
|
> There is one thing in Tcl that uses it: The encoding of the null byte. > It is encoded as non shortest sequence. I don't know if it is sent over > the net in this form if a socket is configured as -encoding utf-8 I think we should be careful in this discussion to distinguish the working of the [encoding] command and the -encoding option to [fconfigure] from the "internal encoding" used by Tcl's C API. We've called that "internal encoding" UTF-8. That's never been entirely true, AIUI, and as the true UTF-8 standard has evolved, it's apparently less true now. Perhaps we should be more careful in our descriptions and documentation (apparently CESU is a better name for things closer to what we're doing) so that we don't mislead people, but I don't see any reason Tcl should need to change its internals. No standard body should have a care about how Tcl's internals are organized. What we perhaps do need to do is provide sufficient tools with our [encoding] command and our -encoding option to allow Tcl application programmers to create programs and libraries that conform to the UTF-8 spec laid down in RFC 3629. I think that creation of a new encoding, "utf-8-rfc3629" might be sufficient to address that issue. When using that new encoding, which presumably would not accept invalid UTF-8 input, we'd need to sort out among Donal's options of how to react to invalid UTF-8. Note that none of Tcl's current encodings have any script-level reaction to invalid input. The TCL_CONVERT_SYNTAX return code from Tcl_ExternalToUtf() is silently ignored. | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: <ke...@cr...> - 2005-10-04 18:53:56
|
dr...@hw... said:
> It doesn't technically. Open-Source does not require an ECCN. But it
> is often easier to supply one that to convince the people asking for
> it that they do not need it. At least, that has been my experience.
I've never had an issue with, where an ECCN is requested, putting in
"License Exception TSU, 70 CFR 770.13(d)(3), subparagraph (ii)(A)"
--
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
|
|
From: <ke...@cr...> - 2005-10-04 18:56:58
|
ke...@cr... said:
> I've never had an issue with, where an ECCN is requested, putting in
> "License Exception TSU, 70 CFR 770.13(d)(3), subparagraph (ii)(A)"
Brain fart - 15 CFR 740.13(d)(3), subparagraph (ii)
--
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
|
|
From: Techentin, R. W. <tec...@ma...> - 2005-10-05 10:55:33
|
> From: ke...@cr... (Kevin Kenny) > > rog...@er... said: > > To enable export you HAVE to give the authorities an ECCN > > code for each piece of software in the product. > > The last time that I had to consult an export control lawyer, > I learned: .... That looks like useful reference information. I'd put it on the wiki, but I don't know where. Any suggestions on where this would like? (Surely to the 'export' pages? Or not.) Bob -- Bob Techentin tec...@ma... Mayo Foundation (507) 538-5495 200 First St. SW FAX (507) 284-9171 Rochester MN, 55901 USA http://www.mayo.edu/sppdg/ |
|
From: Donald G P. <dg...@ni...> - 2006-03-13 14:40:22
|
> Here is the C implementation of the foriter command : > | int Tcl_ForiterObjCmd (dummy, interp, objc, objv) I don't see any use of internal interfaces, which suggests to me that Tcl's public interface is adequate for an extension to create this foriter command. That is, I don't see anything to TIP here. As written, the command doesn't handle execptions in the loop body well, so some changes dealing with Tcl_(Get|Set)ReturnOptions() are in order. | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |