Re: RFC 343 (v1) New Perl Mascot
Perl6 RFC Librarian wrote: > =head1 TITLE > > New Perl Mascot > > =head1 ABSTRACT > > Perl has no common symbol usable by the public at large to state to > the world "I am a Perl Programmer, and D**n Proud Of It!" > > =head1 DESCRIPTION > > The symbol that would be commonly used for this is the Camel, of course, > but that symbol has strict trademark restrictions, and is unsuitable for > the purpose of identification. O'Reilly allows only its commercial > friends and allies to use it, and any other use is strictly prohibited. > This presumes in a way to commercialize the public face of the Perl > language as an O'Reilly-owned commodity. No other symbol is currently > recognized to symbolize Perl and its community. I don't know trademark law, but it seems unlikely that O'Reilly can trademark the concept of the camel, or all representations of the camel. Since the new symbol would be used to promote [pP]erl, which is good for O'Reilly, perhaps they would not object to the use of a sufficiently distinct rendering. (Has anyone trademarked the Alpaca yet? :-) Since perl developers don't conflict but in fact enhance O'Reilly's buisness, I'm not sure I see why they'd object. OT: What's the history of the camel? Does it predate O'Reilly's involvement? -- -- Tim Conrow [EMAIL PROTECTED] |
Re: Math functions? (Particularly transcendental ones)
>Okay, I'm whipping together the "fancy math" section of the interpreter >assembley language. I've got: > ... >Can anyone think of things I've forgotten? It's been a while since I've >done numeric work. HP calculators sometimes define lnp1(x) = ln(1 + x) expm1(x) = exp(x) - 1 to deal accurately and quickly with the special case where x<<1. This may not be useful in an environment of pseudo-infinite precision, unless speed begins to matter alot. Maybe they could be called automagically when the compiler sees something like the RHS of the above as an optimization. -- -- Tim Conrow [EMAIL PROTECTED] |
p6d gatewayed by nntp.perl.org?
I'm not seeing it. My problem, or is it not being mirrored yet? -- Tim
Re: p6d gatewayed by nntp.perl.org?
Simon Cozens wrote: [EMAIL PROTECTED] (Tim Conrow) writes: >I'm not seeing it. My problem, or is it not being mirrored yet? I'm reading it via NNTP. Right, I've got it now. Don't know why I didn't see it there before. -- Tim
Re: purge: opposite of grep
Michael Lazzaro wrote: I worry that C sounds too much like something class-related, and would confuse people. What about C or something? Decent thesaurus entries for include: assign, classify, comb, compartmentalize, discriminate, distribute, group, order, segregate, sift, winnow, amputate, cut, dismember, excise, lop, disunite, divorce, estrange, part, wean, detach, disconnect, disengage, dissociate, extract, isolate, part, steal, take, uncouple, withdraw designate? -- Tim
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Tom Christiansen wrote: > Perhaps what you're truly looking for is a generalized tainting mechanism. Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers? RFCs? Examples? Hints? -- -- Tim Conrow [EMAIL PROTECTED] |
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Tim Conrow wrote: > > Tom Christiansen wrote: > > Perhaps what you're truly looking for is a generalized tainting mechanism. > > Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers? > RFCs? Examples? Hints? Sorry for the clutter, but I didn't want to come off too clueless. I know what tainting is, I just don't know what you mean by generalized tainting. If it's been discussed before I'd love to see a pointer to the thread. -- -- Tim Conrow [EMAIL PROTECTED] |
Re: RFC 258 (v1) Distinguish packed binary data from printablestrings
Sam Tregar wrote: > > On 19 Sep 2000, Perl6 RFC Librarian wrote: > > > Distinguish packed binary data from printable strings > > What defines a "printable" string? What if I'm working in an environment > that can "print" bytes that yours can't? Usage DWIMishly defines a printable string. As I noted in another thread on this RFC, I should never have used the word "binary" in the proposal; it has been excised, with extreme prejudice. > Specifically I'm wondering how this proposal handles Unicode. If the Unicode derives from a source which makes it look like a string that's meant to be human readable, nothing will change from current (or proposed) behavior, AFAIK. These are all unalterd: $line ; $arg = shift @ARGV; @help_lines = ; Only C (except the "A" and "U" templates (confession: I forgot about "U" in v1 of the RFC)), C, C, string-context bitwise ops plus C and C create "packed strings". If Unicode is commonly acquired or manipulated by any of those and meant to stay human readable, then there may be a conflict. -- -- Tim Conrow [EMAIL PROTECTED] |
Re: RFC 258 (v1) Distinguish packed binary data from printablestrings
Andy Dougherty wrote: > > > Perl should be able to distinguish between printable strings and > > packed binary data stored as strings (presumed to not be printable > > text) > > All strings are "printable" in perl, since print just calls fwrite(). I > can and do use perl to "print" binary data. print $a is perfectly fine > even if $a is a packed binary thing. Under this RFA you'd either have to say C or simply not invoke C. > In fact, since there is no other way > to call fwrite() [write does format things, and syswrite bypasses stdio, > which may not be appropriate] print $a is probably the best way to output > a packed binary thing. If this is true, that this is a common usage, and explicitly stringifying with C<""> seems unacceptable, DWIMishness would require backing off the warning on this construct. > > > If anyone knows of common constructs/idioms which would break under > > this scheme and where it's too painful to add C or > > C<"..."> as appropriate ... well I don't have to ask to have them > > pointed out, do I? :-) The only cases I've been able to think of are > > JAPHs or code samples. > > "too painful" is, of course, a judgment call. I do use the > read/unpack/modify/pack/print cycle a fair amount dealing with image data. > I guess I'd say working around RFC 258 might be annoying but not painful. AFAICT backing off on the warning applied to C would remove your only source of annoyance. I don't *think* I have a problem with doing that. -- -- Tim Conrow [EMAIL PROTECTED] |
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Nathan Wiger wrote: > > Tom Christiansen wrote: > > > > Perl should fly far and fast from starting down the bumpy road where > > that data is strongly typed in the mythical and deceptive text-vs-binary > > sense ... Heed the wisdom of the Unix ... I shouldn't have used the term "binary" in the proposal because that's not the distinction. Usage determines whether or not the string is likely to be meant to be readable. An attempt at some added DWIMishness. The data are never examined. I've removed all references to "binary" so people won't misconstrue. (I know that's not the totality of your point; I just wanted to clarify.) > Tom's exactly right. Data should be data, at least by default. > > One of the beauties of UNIX, and one of the reasons it doesn't suck > (unlike some other "operating systems") is that it's guided by > simplicity: everthing's a file, and a file contains data. No drive > letters or .txt vs .exe files to ruin your day. I can't argue with any of that. And true to that spirit, no data were harmed in the creation of this RFC! The DWIMish behavior regarding strings, packed or not, is largely retained. The changes seem to me to apply only to a narrow range of situations, and those only when asked. I've endeavored to arrange things such that this RFC will not change how people use perl now, but will reduce the occurance of one class of errors. > As the examples show, this is an infinitely complicated issue. Perhaps it is to those of you who can see more of the Perl landscape than I, but from down here the RFC looks well cirucmscribed and limited. If there *is* infinite complexity looming, obviously it will never be done; no need for further argument on this list. > [... snip ...] > Basically, I think the type of stuff you suggest is best viewed as > *extensions* to Perl, and not default behavior that could potentially > cause many more problems than it solves. The example code was meant to convey that the additional checking is only done when explicitly invoked via C and/or C. Perhaps I should make that more explicit. In a sense, it's already proposed to be sort of an extension, just one which is provided to everyone. Everyone's short of tuits, but I'd love to see some hint of where you think this causes problems. -- -- Tim Conrow [EMAIL PROTECTED] |
