Re: A sketch of the security model
On 4/15/05, Shevek [EMAIL PROTECTED] wrote:
How can dropping a privilege for the duration of a (dynamic) scope be
implemented? Does this need to be implemented via a parrot intrinsic,
such as:
without_privs(list_of_privs, code_to_be_run_without_these_privs);
..or is it possible to do so with the primitives you sketched out above?
This is usually done by creating a function f(code) { code() } without
any static privileges in list_of_privs.
To evaluate a function g()
without those privileges, evaluate f(g), and the natural mechanisms of
the interpreter will ensure that these privileges are not held during
g().
I understand, thanks.
Michael
Re: [] ugly and hard to type
On 4/15/05, Juerd [EMAIL PROTECTED] wrote:
Am I the only one who thinks [a-z] is ugly and hard to type because of
the nested brackets? The same goes for {...}. The latter can't easily
be fixed, I think, but the former perhaps can. If there are more who
think it needs to, that is. And {} is a bit easier to type because all
four are shifted (US QWERTY and US Dvorak), while with [] I really
have to think hard about when to press and when to release the shift
key.
I never liked character sets. They introduced yet another exception to
the parsing rules, and it irked me. If it weren't for the need to
optimize character sets, I'd prefer to be Pythonized into using @{'a'
.. 'z'}
If I read the Apocalypses correctly, I'm allowed to use this bizzare construct:
$foo ~~ /@{ [ ] { } : ++ $ . ? / +| + ?| ? }/
to match some of my favorite punctuations, right? It allows
multi-character alternatives as well as the single-character ones, so
it seems preferable to me (assuming it could be optimized happily).
Ashley Winters
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
According to Michael G Schwern:
On Fri, Apr 15, 2005 at 08:31:57PM -0400, Chip Salzenberg wrote:
There are several methods to determine the current directory.
Perl 6 is going to have to decide on some sort of standard internal getcwd
technique, $CWD or not.
I don't think Perl 6 has to do anything of the kind. It would
be a mistake to try.
In the same way that we have open() not fopen, fdopen, freopen... we
can choose the safest and most sensible technique for determining
the cwd and use that.
There's more than one sensible thing. There's more than one safe
thing.
And there is more than one open. Perl does have fopen/fdopen/freopen,
but they're accessed through other techniques besides the name of the
operator. For example, Perl spells Cfh = fdopen(5, r) as Copen
$fh, =5). The unique technique is there, just pushed out of the
operator name and into its parameters.
And then there's sysopen().
But open() is beside the point, no matter that it supports my point. :-)
As you know, under Unix, there's no such thing as the current
directory as a string. The only durable current directory is the
device and inode of Cstat('.'). It's not wise to conflate the
current directory with a name that at some point in the past could
have been used to reach it.
You have to because when a new user asks how do I get the current
working directory? [...]
Then I answer him with the same patience I answer someone who asks
how to get the filename corresponding to an open file descriptor:
There is no portable way. Tell me what you want to do, and maybe
I can help you.
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
Open Source is not an excuse to write fun code
then leave the actual work to others.
Re: [] ugly and hard to type
I never liked character sets. They introduced yet another exception to
the parsing rules, and it irked me. If it weren't for the need to
optimize character sets, I'd prefer to be Pythonized into using @{'a'
.. 'z'}
Isn't that just a digression into the bad old pre-internationalized
days. Unicode-schmunicode, but I'm all about the internationalization,
even if I am just an English speaker, and Unicode makes it happen, so
I love it. And it's WAY too easy for me as an English speaker to
ignore or badly program so that Internationalization is more work than
it needs to be, so any effort to push me into character classes is
Good and I appreciate the discipline.
Re: VTABLE methods and interfaces
Sam, Just wondering what the status is on python/parrot/pirate/pyrate. These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/ Is there a up to date cvs repo? Can we get this code checked into the parrot svn repo? Kevin Tew
Python on parrot
Sam, Just wondering what the status is on python/parrot/pirate/pyrate. These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/ Is there a up to date cvs repo? Can we get this code checked into the parrot svn repo? Kevin Tew
Re: [perl #34959] config/auto/gmp/gmp.in returns 1 instead of 0
Am Donnerstag, 14. April 2005 09:04 schrieb Leopold Toetsch via RT: Lambeck [EMAIL PROTECTED] wrote: Hi all, Configure.pl failed to find the GNU Math Lib (GMP) on my system eventhough it is installed properly (version 4.1.4) . I compiled config/auto/gmp/gmp.in by hand and it returned: 4950 1 but expected was: 4950 0 Everything seems to be right, except that mpz_fits_slong_p(k) returned 1 instead of 0. Could not find anything usefull to explain what it means. I am on amd64 running Linux. ^ Yeah. The test is bogus for 64-bit systems. The tested number fits within a 64-bit long. Could you please patch gmp.in and gmp.pl to use some bigger numbers 64 bit. Why do you test for that after all ? I never used gmp - it came up when I noticed that the config failed. gmp provides a test suite to test all this. Of course you can expect the user did not run it but why write your own tests if there are already tests? I would only check if gmp is installed and that`s it. If the user did not run make check (strongly advised on the gmp website) then that should not be the problem of parrot. Anything against this standpoint ? Adrian Lambeck pgp4BtnQk46Fn.pgp Description: PGP signature
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
On Fri, Apr 15, 2005 at 09:32:23PM -0400, Chip Salzenberg wrote: Perl 6 is going to have to decide on some sort of standard internal getcwd technique, $CWD or not. I don't think Perl 6 has to do anything of the kind. It would be a mistake to try. Sorry, I had assumed that having a simple cwd() was a forgone conclusion so I just tried to bull through it. My bad. Lemme back up a few steps and try again. [1] Yes, there are lots of ways to check the cwd each filling in one edge case or another. However I'd like to believe its possible to come up with one simple, safe cwd() that works for 99.9% of the cases and call that cwd(). Then have a Cwd module full of all the various other techniques (or perhaps attributes to alter the behavior of cwd()). This lets you answer the question How do I get the current working directory? with Short answer: cwd(). Long answer: For this set of conditions, use this... This avoids the current state of things where a user with a simple desire must slog through the rather daunting choices provided by Cwd.pm and probably wind up making the wrong decision. [2] A high level language really should smooth all that over. How cwd() is implemented is not so important as what happens when it hits an edge case. So maybe we can try to come up with a best fit cwd(). I'd start by listing out the edge cases and what the possible behaviors are. Maybe we can choose a set of behaviors which is most sensible across all scenarios and define cwd() to act that way. Or maybe even just define what various cwd variations currently do. Here's the ones I know of off the top of my head. You probably know more. * The cwd is deleted * A parent directory is renamed * A parent directory is a symlink [1] http://angryflower.com/pathof.gif [2] The state of Cwd.pm's docs add to my anxiety.
Re: [RFC] some doubtable MMDs?
Larry Wall [EMAIL PROTECTED] wrote:
On Fri, Apr 15, 2005 at 02:38:36PM +0200, Leopold Toetsch wrote:
: I'm not quite sure, but it seems that some of the MMD functions may
: better be vtable methods:
:
: - bitwise_sh[rl]*shift by anything other then int?
: - bitwise_lsris missing generally
:
: or even just a plain opcode only:
:
: - logical_{or,and,xor} return a PMC depending on the boolean value
:
: What are HLLs expecting of these infix operations?
Perl 6 tends to distinguish these as different operators, though Perl 5
did overload the bitwise ops on both strings and numbers, which newbies
found confusing in ambiguous cases, which is why we changed it.
We have distinct functions for bitwise shift int and string. That's no
prblem. But can the right operand be anything different then a plain
integer?
: OTOH it might be useful that the current get_type_keyed operations
: (postcircumfix:[]) become MMD subroutines:
:
: Px = Py[Pz]Pz = String, Int, Key, Slice, ...
At the moment, the Perl 6 optimizer is explicitly allowed to optimize
array indices with the assumption that the subscript is a scalar
(or slice) of integer, or something that converts to integer. I'd be
interested to know if that policy will actually buy us any performance.
If it always has to go through MMD anyway, maybe it doesn't. But
array indexing code tends to be pretty hot, so if we can keep it
somewhat optimizable and/or jittable, that'd be nice.
Above are only the PMC variants. There are optimized forms for array and
hash lookup by native types:
Px = Py[Iz]
Px = Py[Sz]
But with PMCs we seem to have a bunch of different key-ish PMCs,
including a BigInt PMC for bitarrays.
With MMD we'd have one function per key. Without the usual cascaded if
statements:
if key.type == Int
...
elsif key.type == Slice
...
From a performance POV, MMD is faster with optimizing run cores that can
rewrite the opcode and about the same speed with a plain MMD function cache.
Larry
leo
Re: Various questions
Philip Taylor [EMAIL PROTECTED] wrote:
I've been working on a C-to-Parrot compiler (actually an IMC backend
for the LCC compiler), tentatively named Carrot, over the past week. It
can currently do some reasonably useful things, like running the Cola
compiler (with only a very small amount of cheating), but it has raised
a few queries:
Wow.
* I can usually handle unsigned numbers by pretending they're signed and
using 'I' registers, but some things appear to be awkward without new
ops - in particular, div and cmod, and le/lt/ge/gt comparisons. (As far
as I can tell, those are the only ones C would need; everything else
should work fine with the signed variants).
I've added divu/leu/etc ops to math.ops/cmp.ops (and just made them cast
their operands into UINTVALs) - is that a reasonable thing to do? Would
they be better in a new .ops file?
No, keeping the ops in their categories is fine.
* Should there be an 'isatty' op/method? (or is there something else
that isatty(fileno(file)) (which Cola's lexer uses) should do, in
order to return a reasonable answer?)
A method, like e.g. Ceof, see classes/parrotio.pmc
$P0 = getstding
$I0 = $P0.__isatty()
METHOD INTVAL __isatty() ...
(we'll create the mangled version with two underscores automagically
soon)
* Is it possible to merge PBC files together, like load_bytecode but at
compile-time?
Not really. But you might have a look at src/pbc_info.c, which
demonstrates some of the packfile manipulations. Such a utility would be
really great.
* How efficient are PMC method calls? (And are performance concerns
documented anywhere, like op calls are roughly n times faster than
methods, so compiler-writers could avoid implementing things in stupid
ways, or is it too early to be doing that?)
It's a bit early still, but a general rule of thumb is:
- if you have native I or N types, make it an opcode
- everything else is at least a function call already and will be
optimized like hell and will be fast enough ;)
I've been using [gs]et_integer_keyed_int on a PMC to allow pointer
access. Since it reads whole ints, it probably crashes unnecessarily
when e.g. reading chars at unlucky addresses - but IMC code like val =
mem.read_i1(ptr) feels unpleasantly inefficient, particularly in
string-processing loops.
That (but not only) seems to warrant new {Fixed,Resizable}ByteArray
PMCs. See e.g. the *BooleanArray PMCs.
Hmm... Should I just accept that C-on-Parrot will always be relatively
slow, since its concept of memory is slightly incompatible with
Parrot's, and anybody who wants speed can use a native C compiler, so I
can stop worrying about it? :-)
WRT memory access probably yes. When it comes to raw calculation speed
with INTVALs, Parrot can reach the speed of optimized C.
Thanks,
Welcome,
leo
[FYI] possibly incompatible string change - rev 7851
Yesterday on IRC was some discussion [1] about the default string
representation. The consensus was that strings should by default have
ascii charset and not iso-8859-1 as it was for some weeks.
Autrijus has prepared a patch parrot-broken-ascii.patch, which did
parts of this change. I've completed and extended the patch now. But
it's probably still a bit rough. Tests succeed though.
There are a lot of string_make calls in the interpreter. I've replaced
most explicit charsets by NULL, which uses the default ascii now. But
for correctness, in the absence of a charset, the strings should be
inspected, if it's ascii or not.
Mixed operations like append, substr, or bitwise_{and,or,xor} on
fixed8-encoded strings should also be ok now, but there are no tests yet
- these are very welcome.
Please folks grep through the sources and have a look at each string
creation, whether it's plain ascii or not.
Thanks,
leo
[1] I missed the first part of it - would be great if such discussions
could be brought forth to the list.
Re: nbsp in \s, ?ws and
Larry Wall [EMAIL PROTECTED] wrote: On Fri, Apr 15, 2005 at 11:44:03PM +0200, Juerd wrote: : Is there a ?ws-like thingy that is always \s+? Not currently, since \s+ is there. ?ws used to be that, but currently is defined as the magical whitespace matcher used by :words. : Do \s and ?ws match non-breaking whitespace, U+00A0? Yes. Yes, any Unicode whitespace, but you seem to have a different list than I do. Well there are three different whitespace lists. The Parrot program [1] below shows all, including space and blank. $ ./parrot ws.imc charuws ws jws sp bl U+0008 0 0 0 0 0 U+0009 1 1 0 1 1 U+000a 1 1 0 1 0 U+000b 1 1 0 1 0 U+000c 1 1 0 1 0 U+000d 1 1 0 1 0 U+0020 1 1 1 1 1 U+0085 1 1 0 1 0 U+00a0 1 0 1 1 1 U+1680 1 1 1 1 1 U+180e 1 1 1 1 1 U+2000 1 1 1 1 1 U+2001 1 1 1 1 1 U+2002 1 1 1 1 1 U+2003 1 1 1 1 1 U+2004 1 1 1 1 1 U+2005 1 1 1 1 1 U+2006 1 1 1 1 1 U+2007 1 0 1 1 1 U+2008 1 1 1 1 1 U+2009 1 1 1 1 1 U+200a 1 1 1 1 1 U+2028 1 1 1 1 0 U+2029 1 1 1 1 0 U+202f 1 0 1 1 1 U+205f 1 1 1 1 1 U+2060 0 0 0 0 0 U+3000 1 1 1 1 1 U+feff 0 0 0 0 0 So I make it: which seems to match Parrot_char_is_JavaSpaceChar leo [1] Needs some additions, which I'll ci in a minute, and the ICU lib installed. There isn't an interface for these functions yet, so they are looked up via dlsym(3) inside parrot itself. $ cat ws.imc .sub main @MAIN .local pmc chars, uws, ws, jws, sp, bl, nul, fmt .local int i, n, is, c chars = new ResizableIntegerArray push chars, 0x8 push chars, 0x9 push chars, 0xa push chars, 0xb push chars, 0xc push chars, 0xd push chars, 0x20 push chars, 0x85 push chars, 0xA0 push chars, 0x1680 push chars, 0x180e i = 0x2000 pl: push chars, i inc i if i = 0x200a goto pl push chars, 0x2028 push chars, 0x2029 push chars, 0x202f push chars, 0x205f push chars, 0x2060 push chars, 0x3000 push chars, 0xfeff null nul uws = dlfunc nul, Parrot_char_is_UWhiteSpace, IJI ws = dlfunc nul, Parrot_char_is_Whitespace, IJI jws = dlfunc nul, Parrot_char_is_JavaSpaceChar, IJI sp = dlfunc nul, Parrot_char_is_space, IJI bl = dlfunc nul, Parrot_char_is_blank, IJI n = elements chars i = 0 print char uws ws jws sp bl\n loop: fmt = new ResizableIntegerArray c = chars[i] push fmt, c is = uws(c) push fmt, is is = ws(c) push fmt, is is = jws(c) push fmt, is is = sp(c) push fmt, is is = bl(c) push fmt, is $S0 = sprintf U+%04x\t%d\t%d\t%d\t%d\t%d\n, fmt print $S0 inc i if i n goto loop .end
Re: [perl #34959] config/auto/gmp/gmp.in returns 1 instead of 0
Adrian Lambeck wrote: Am Donnerstag, 14. April 2005 09:04 schrieb Leopold Toetsch via RT: Lambeck [EMAIL PROTECTED] wrote: Hi all, Configure.pl failed to find the GNU Math Lib (GMP) on my system eventhough it is installed properly (version 4.1.4) . I compiled config/auto/gmp/gmp.in by hand and it returned: 4950 1 but expected was: 4950 0 Everything seems to be right, except that mpz_fits_slong_p(k) returned 1 instead of 0. Could not find anything usefull to explain what it means. I am on amd64 running Linux. ^ Yeah. The test is bogus for 64-bit systems. The tested number fits within a 64-bit long. Could you please patch gmp.in and gmp.pl to use some bigger numbers 64 bit. Why do you test for that after all ? I would only check if gmp is installed and that`s it. I'm not trying to replace gmp's make check here, just test if it's working. The second test for mpz_fits_slong was included, because on some BSD there was an old GMP installed, which didn't have this feature. Obviously this one is wrong for 64-bit systems, so using just bigger numbers is the way to fix it. leo
Re: [perl #34984] [PATCH] Fix segfault with const
Nicholas Clark wrote: On Fri, Apr 15, 2005 at 07:26:56PM +0100, Nick Glencross wrote: +// Forbid assigning a string to anything other than a string const +// for now In future, please don't use C99 comments. (apart from that, I don't have the knowledge to comment on this patch) Ahh! I always sigh when I see people do it, but it's hard to juggle C and C++ comments! Thanks for pointing that out. Probably best to resubmit patch... Well spotted, Nick
Re: [perl #34984] [PATCH] Fix segfault with const
Nick Glencross [EMAIL PROTECTED] wrote: Leopold Toetsch via RT wrote: I think, we could be a bit more graceful here for I/N mismatch and set for the above case the constant val-set to 'N'. Let me redo that... I've just sent the wrong attachment which had a typo in it ... Similar patch is in now, capable of handling PMC constants too: .const Integer = 42 and with C99 comment style removed. [This should really address rare but possible Unicode strings, shouldn't it?] Yep. Nick Thanks, leo
Re: [pugs] Quoting constructs
On Sat, Apr 16, 2005 at 03:14:50AM +0300, Roie Marianer wrote: By the way, something tells me perl6-compiler isn't the best place for this discussion. Is there a secret group of people that discusses cornercases for perl6, and if so could someone tell me on what list they live? perl6-compiler is fine for discussing corner cases and asking for or verifying an interpretation/clarification of them. If it turns out that there are multiple competing interpretations available and some disagreement about which one should be correct, then perl6-language is (or becomes) the better location for the discussion. Pm
Quoting interpolation in Perl5 vs. Perl6
Hi all.
I'm trying to get quoting interpolation to work, which means I first have to
understand it a little better.
In Perl 5, as far as I can see, the delimiter of quoting constructs (whether
it's , '' or qq delim) is searched for before the string is parsed. This
means that, for example,
%hash{string value}
parses as
%hash{
which is a syntax error.
Current behaviour in Pugs is to read anything that interpolates until its
logical conclusion, so that for example
{a}
is 'a', and not a syntax error. I think this behaviour is more useful than the
old behaviour when it's not ambiguous. (By the way, this behaviour is my
fault, so it's not authoritative in any way)
My suggestion is to check for delimiters only when it's ambiguous: Inside a
variable name (qq x$varxy - $vary), and at the beginning of every
subscript of a scalar, and every subscript after the first one of an array,
hash of sub (because in these cases the first subscript is mandatory).
By the way, maybe it's not even an issue: Is it possible for the closing
delimiter of a string to be an opening bracket or brace? In Perl 5, if a
quote is opened by a closing brace it must be closed by the same closing
brace, while in current Pugs an opening closing brace is closed by a closing
opening brace:
Perl5: q]a] Pugs: q]a[
both mean 'a'. If the Perl 5 behaviour is maintained, then there is no chance
at all of ever mistaking a subscript for a closing delimiter, which makes the
only special case qq x$varxy.
Sorry for being long-winded; does this make any sense at all?
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Re: Quoting interpolation in Perl5 vs. Perl6
Roie Marianer skribis 2005-04-16 18:28 (+0300): My suggestion is to check for delimiters only when it's ambiguous: Inside a variable name (qq x$varxy - $vary), and at the beginning of every subscript of a scalar, and every subscript after the first one of an array, hash of sub (because in these cases the first subscript is mandatory). [...] both mean 'a'. If the Perl 5 behaviour is maintained, then there is no chance at all of ever mistaking a subscript for a closing delimiter, which makes the only special case qq x$varxy. I wouldn't mind at all if alphanumeric delimiters should go. I have never seen them used in serious programming, and if they present a problem with natural parsing, then why keep them around? Obfuscation is nice, but let's not design the language around that. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Maybe I'm back
Hello all, Maybe some of you remember how I used to have endless hours in Berlin to fiddle with Parrot documentation. Then I got a job, moved back to London, and disappeared. I can't say I have been following the list closely, but I have read the occasional summary from time to time. I'm out of touch, but curious again. Now I know, promises are worthless, but I have been thinking of putting a Getting Started Guide together again. In the process of poking around in the subversion checkout I noticed that write_docs.pl was broken. I fixed it. (What is a .bundle file anyway?) Maybe some kind soul could shortcut me to how/where I check in the changes. Mike
Re: [pugs] Quoting constructs
On Sat, Apr 16, 2005 at 03:14:50AM +0300, Roie Marianer wrote: : I actually knew that, but in my head $key_b and $value_b were single words. : But according to S02, the interpolation is protected by quotes. That is, if : $key_b is q0/printf Hello, world\n or die/, that's four words, correct? Or : is it just if the quotes actually appear in the quoting construct? Basically : I'm wondering if there's a detailed specification of how should work. That's a really good question, and since I don't offhand know the right answer, I'll put this up onto the fence so it can topple over into p6l-land where there are many king's horses and many king's men, and the question is who's to be master, that's all. My feeling is that we want to allow both kinds of quoting, one to protect against interpolation, and one to protect against splitting, but not allow levels to be mixed. That is, the outer quotes will cause any interpolation inside them to be treated as a word string without any consideration of any of the characters inside, even if they happen to be spaces or quote characters. The outer quotes must therefore nest correctly without considering whether there might be inner quotes of the same sort. So we distinguish quoted interpolation from unquoted, and for unquoted interpolation, we look for inner quotes after interpolation and treat them as protection against splitting just as if they'd been outer quotes. I think that works, and won't be terribly surprising to shell programmers, but it still needs some caffeinated thinking. It's not at all clear to me at this point whether we should allow the q forms of quoting on either/both levels, or stick with shell-ish quotes. I can argue that one multiple ways. : Several only-slightly-related questions about interpolating: : : 1. qq x$varx eq $var? (That's how it works in Perl5, anyway) I think I'd prefer that we disallow alphanumeric delims in P6. (But if we did allow them, it would consider the second x to be part of the variable name, since we're looking for the final delimiter only when we're not scanning an internal token, or nested construct.) : 2. If the delimiter is not a single character (I think this only applies to : ), does a backslash protect the first character or both? For example, in : some words \ or die : Is that three words ['some', 'words', ''] with the ending the construct, : or is that ['some', 'words', '', 'or', 'die']? (and the rest of the file : is interpolated and split into words) I would look at it from the other direction. When used as a quote rather than a meta-syntax starter, backslash only ever quotes a single character, never a token. However, the fact that the final delimiter has to be means that if you backwhack the first one, it is not available for token comparison, so the second one can only be the first of a pair, and if the next character happens not to be , both of your become part of the string, so it looks as if the backslash protected both of them. However, \ terminates with a final as part of the string. : 3. Are -style delimiters allowed in other quoting constructs? Is : qHello the string Hello, or the string Hello followed by the : greater-than sign? (As you can probably tell, I haven't implemented yet : at all.) I think in general only single characters may be used for pick-your-own quotes, but if we make any exception, ... would be it, on the grounds that some would-be Texan might translate all «...» to ... and then wonder why things break. But I always try to have six breakfasts before I believe anything impossible. As long as this is going over the fence to p6l, we might as well solicit opinion on this one as well, maybe with a different subject. : My head hurts. :-) Eventually the endorphins kick in, and it wraps around to the other end. :-) : By the way, something tells me perl6-compiler isn't the best place for this : discussion. Is there a secret group of people that discusses cornercases for : perl6, and if so could someone tell me on what list they live? As Patrick said, we ain't picky, as long as everyone remains sensitive to the fact that long-running speculative threads do p6c little good, and p6l little harm. Larry
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
On Saturday 16 April 2005 01:53, Michael G Schwern wrote: How cwd() is implemented is not so important as what happens when it hits an edge case. So maybe we can try to come up with a best fit cwd(). I'd start by listing out the edge cases and what the possible behaviors are. Maybe we can choose a set of behaviors which is most sensible across all scenarios and define cwd() to act that way. Or maybe even just define what various cwd variations currently do. Here's the ones I know of off the top of my head. You probably know more. * The cwd is deleted * A parent directory is renamed * A parent directory is a symlink There is also the possibility for permissions issues: * You don't have permissions to determine cwd as an absolute pathname * You are in a directory that you couldn't have chdir'ed into (that makes the localized $CWD fail to return you to the original location when it goes out of scope). It's not hard to run a program that is setuid (to a non-root account) from within a directory that is owner-only accessible.
Re: [RFC] some doubtable MMDs?
On Fri, Apr 15, 2005 at 11:11:00PM -0400, Bob Rogers wrote: : By the same token, couldn't one reasonably ask for a boolean array that : required BigInt subscripts, even on said 32-bit machine? (Once boolean : arrays actually store one element per bit, that is.) Or are subscripts : this large ruled out? It's certainly reasonable to have some way of allocating a bit array that big. If you have to turn you're entire memory into a bit array, that's fine by me. I've never been much into arbitrary limits. But my question as a language designer then has to be: What do you mean by ask for, and is merely asking for any bit array the same thing as asking for one that big? :Or are you using integer conceptually to include both Integer and : BigInt? Whether I am or not depends on whether I take a big speed hit for the generality. I like generality, but I also want Perl 6 to be fast in the common case, as long as it is not too difficult for the compiler to figure out which cases are not the common ones. Syntactically speaking, Perl 6 can easily distinguish my bit @array is shape(int);# native int subscript from my bit @array is shape(Int);# big int subscript but I'm just wondering which I should be thinking of as the default for my bit @array; It seems to me that assuming shape(int) is not generally going to be a hardship on people, especially once 64-bit machines get to be the norm. And if it means that the optimizer can do tricks and eek some more speed out, then I'm willing to force the occasional user to declare shape(Int) when they want the generality. Larry
Re: [RFC] some doubtable MMDs?
On Sat, Apr 16, 2005 at 10:36:37AM +0200, Leopold Toetsch wrote: : Larry Wall [EMAIL PROTECTED] wrote: : Perl 6 tends to distinguish these as different operators, though Perl 5 : did overload the bitwise ops on both strings and numbers, which newbies : found confusing in ambiguous cases, which is why we changed it. : : We have distinct functions for bitwise shift int and string. That's no : prblem. But can the right operand be anything different then a plain : integer? I don't think Perl cares. (Can't speak for other languages.) I do think bit shifts tend to be in very hot code for crypto routines, so any hints we can give the optimizer would help those apps. : Above are only the PMC variants. There are optimized forms for array and : hash lookup by native types: : : Px = Py[Iz] : Px = Py[Sz] Is there a bitarray lookup by native int? : But with PMCs we seem to have a bunch of different key-ish PMCs, : including a BigInt PMC for bitarrays. I don't mind the general MMDish cases, as long as they don't get in the way of a writing a devilish fast LINPACK in Perl 6 without too many contortions. And we can certainly contort Perl 6 to our hearts' content, but I'm just trying to figure out whether ordinary arrays default to shape(int) or shape(Int). My gut feeling is that defaulting to shape(int) is going to buy the optimizer something, but it's just that, a gut feeling. (That, and the fact that plural slice subscripts are generally visible to the compiler, because we don't automatically interpolate $foo into a list even if it's a sublist. So we generally know when we're doing a singular subscripting op.) : With MMD we'd have one function per key. Without the usual cascaded if : statements: : : if key.type == Int : ... : elsif key.type == Slice : ... : : From a performance POV, MMD is faster with optimizing run cores that can : rewrite the opcode and about the same speed with a plain MMD function cache. Yes, but there's still got to be some internal overhead in deciding whether the run-time Int object is representing the integer in some kind of extended bigint form. (Or are you meaning Int as Parrot's native integer there?) Plus if you're optimizing based on run-time typing, there has to be some check somewhere to see if you're assumptions are violated so you can pessimize. That sort of check can be factored out to some extent, but not to the same extent that a compiler can factor it out with sufficient advance type information, either direct or inferred. (At least, that's my assumption. I don't claim to up-to-date on the latest in optimizing run cores.) Basically, Perl[1-5] got a lot of performance out of assuming IEEE floats were available and sufficiently accurate, whereas earlier languages like REXX has to roll their own numerics to achieve accuracy. I'd like to think that native integers will (soon) always be big enough for most purposes, and am wondering how much it buys us to stay close to the metal here. (And whether the answer is different for 32-bit and 64-bit machines, but that feels like a hack.) Larry
Re: trim() and words() functions?
[EMAIL PROTECTED] (Larry Wall) writes: Of course, generations of Perl programmers have made do with various forms of s///, I have found String::Strip on CPAN to work well for my needs in this area.
Re: nbsp in \s, ?ws and
On Sat, Apr 16, 2005 at 10:22:45AM +0200, Leopold Toetsch wrote: : Well there are three different whitespace lists. The Parrot program [1] : below shows all, including space and blank. I suspect we'll end up with about as many whitespace definitions as there are computer languages, or maybe as many as there are programmers. Or maybe the cross product of those... The basic problem is that as we get off into the land of pragmatics, a term like whitespace becomes extremely context dependent. And things like zero-width spaces and non-breaking spaces can have meanings that depend contextually on the actual human language you're dealing with. The job for a language designer is to decide whether any of the default standards are good enough to serve as the default for the language, or whether we need yet another standard to choose from. :-) The other job is to make sure that, regardless of the default, it's possible to make any other choice *look* like the default within a particular lexical scope, and to cajole the language implementer into making sure it's not too much overhead to support other character classes. Larry
Re: [perl #34959] config/auto/gmp/gmp.in returns 1 instead of 0
On Thursday 14 April 2005 08:36, Leopold Toetsch wrote:
Lambeck [EMAIL PROTECTED] wrote:
Hi all,
Configure.pl failed to find the GNU Math Lib (GMP) on my system
eventhough it is installed properly (version 4.1.4) .
I compiled config/auto/gmp/gmp.in by hand and it returned:
4950 1 but expected was:
4950 0
Everything seems to be right, except that mpz_fits_slong_p(k) returned
1 instead of 0. Could not find anything usefull to explain what it
means. I am on amd64 running Linux.
^
Yeah. The test is bogus for 64-bit systems. The tested number fits
within a 64-bit long. Could you please patch gmp.in and gmp.pl to use
some bigger numbers 64 bit.
I changed the test to calculate a mersenne prime number. I have tested it
on amd 64 and it finds amd64.
Ok to commit?
boe
Index: config/auto/gmp/gmp.in
===
--- config/auto/gmp/gmp.in (revision 7853)
+++ config/auto/gmp/gmp.in (working copy)
@@ -7,21 +7,17 @@
int main(int argc, char *argv[])
{
-mpz_t i, j, k;
+mpz_t prime;
char *s; int y;
-mpz_init(i);
-mpz_set_si(i, 99);
-mpz_init(j);
-mpz_set_si(j, 100);
-mpz_init(k);
-mpz_mul(k, i, j);
-mpz_set_si(i, 2);
-mpz_div(k, k, i);
+/* Calculate the 13th Mersenne prime 2^521 - 1 */
+mpz_init(prime);
+mpz_ui_pow_ui(prime, 2, 521);
+mpz_sub_ui(prime, prime, 1);
-y = mpz_fits_slong_p(k);
+y = mpz_fits_slong_p(prime);
-s = mpz_get_str(NULL, 10, k);
+s = mpz_get_str(NULL, 10, prime);
printf(%s %d\n, s, y);
free(s);
return 0;
Index: config/auto/gmp.pl
===
--- config/auto/gmp.pl (revision 7853)
+++ config/auto/gmp.pl (working copy)
@@ -55,7 +55,7 @@
my $has_gmp = 0;
if (! $@) {
my $test = cc_run();
- if ($test eq 4950 0\n) {
+ if ($test eq 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151 0\n) {
$has_gmp = 1;
print (yes) if $verbose;
$Configure::Step::result = 'yes';
Re: [] ugly and hard to type
On Sat, Apr 16, 2005 at 02:42:25AM -0700, Ashley Winters wrote:
: I never liked character sets. They introduced yet another exception to
: the parsing rules, and it irked me. If it weren't for the need to
: optimize character sets, I'd prefer to be Pythonized into using @{'a'
: .. 'z'}
:
: If I read the Apocalypses correctly, I'm allowed to use this bizzare
construct:
:
: $foo ~~ /@{ [ ] { } : ++ $ . ? / +| + ?| ? }/
:
: to match some of my favorite punctuations, right?
Not unless you backwhack that internal there.
: It allows
: multi-character alternatives as well as the single-character ones, so
: it seems preferable to me (assuming it could be optimized happily).
I will happily assume that all sorts of things could be optimized away
if only someone will generate an endless supply of convex tuits.
Assuming someone doesn't invent such a tuit factory, and that the @ matcher
is smart about caching unchanged arrays, you might actually get much better
performance out of:
@myfavoritepunctuations = [ ] { } \ : ++ $ . ? / +| + ?| ? ;
$foo ~~ /@myfavoritepunctuations/;
It's arguably a lot more readable too.
Larry
Re: Quoting interpolation in Perl5 vs. Perl6
On Sat, Apr 16, 2005 at 06:28:37PM +0300, Roie Marianer wrote:
: Hi all.
:
: I'm trying to get quoting interpolation to work, which means I first have to
: understand it a little better.
:
: In Perl 5, as far as I can see, the delimiter of quoting constructs (whether
: it's , '' or qq delim) is searched for before the string is parsed. This
: means that, for example,
: %hash{string value}
: parses as
: %hash{
: which is a syntax error.
:
: Current behaviour in Pugs is to read anything that interpolates until its
: logical conclusion, so that for example
: {a}
: is 'a', and not a syntax error. I think this behaviour is more useful than
the
: old behaviour when it's not ambiguous. (By the way, this behaviour is my
: fault, so it's not authoritative in any way)
Please rest assured that that behavior, is, in fact, mandated.
: My suggestion is to check for delimiters only when it's ambiguous: Inside a
: variable name (qq x$varxy - $vary), and at the beginning of every
: subscript of a scalar, and every subscript after the first one of an array,
: hash of sub (because in these cases the first subscript is mandatory).
The basic rule of thumb is that we pretend we're a top-down parser
even if we aren't, and we only look for the trailing delimiter when
we're not trying to parse something embedded that would naturally
slurp up the trailing delimiter as part of the internal construct.
Certainly any kind of bracketing structure hides anything inside it
from the delimiter scanner, but so do tokens like identifiers.
: By the way, maybe it's not even an issue: Is it possible for the closing
: delimiter of a string to be an opening bracket or brace?
Nope, if you open with an opener it only looks for the closer.
: In Perl 5, if a
: quote is opened by a closing brace it must be closed by the same closing
: brace, while in current Pugs an opening closing brace is closed by a closing
: opening brace:
: Perl5: q]a] Pugs: q]a[
: both mean 'a'. If the Perl 5 behaviour is maintained, then there is no chance
: at all of ever mistaking a subscript for a closing delimiter, which makes the
: only special case qq x$varxy.
I think I would prefer the Perl 5 behavior here, or maybe we should
simply disallow closers as openers. As Juerd points out, it really
makes little sense to allow alphanumerics either, especially now that
we allow any Unicode brackets to be
used.
And inside-out brackets are just going to drive highlighters absolutely
bonkers, though arguably the same could be said for q]a], only more so.
: Sorry for being long-winded; does this make any sense at all?
Yep, it makes any sense at all.
Larry
Re: Quoting interpolation in Perl5 vs. Perl6
On Sat, Apr 16, 2005 at 11:30:49AM -0700, Larry Wall wrote: : The basic rule of thumb is that we pretend we're a top-down parser : even if we aren't, and we only look for the trailing delimiter when : we're not trying to parse something embedded that would naturally : slurp up the trailing delimiter as part of the internal construct. : Certainly any kind of bracketing structure hides anything inside it : from the delimiter scanner, but so do tokens like identifiers. I think I have to clarify what I mean by that last phrase. Trailing delimiters are hidden inside any token that has already been started, but not at the start of a token (where token is taken to be fairly restrictive). Therefore these are errors: qq. $foo.bar() . qq: @foo::bar[] : However qq/ foobar( $a / $b ) / is just fine, since (...) is looking for its own termination. Basically we don't have to keep track of sets of terminators (unless we want to use that info after a syntax error to make hypotheses and explore alternate realities in the service of better error messages). Given our plan of a hybrid parser with a bottom-up operator precedence parser sandwiched between top-down parsers, and assuming that . is the tightest operator that the bottom-up expression parser treats as an operator, it more or less comes down to the fact that anything the expression parser pulls in as a single term is going to be treated as a construct that ignores any outer delimiters because it's calling out to a lower-level top-down parser at that point to parse the term in question. Hmm, I guess there's still a little ambiguity in there in the case of lookahead. And the fact is, a construct like qq. $foo.bar() . either has to do some lookhead or some backtracking to determine that the entire interpolated expression ends with a bracketed construct, since we've said that $foo.bar() interpolates $foo.bar(), while $foo.bar interpolates only $foo. (With similar constraints on array and hash interpolation.) So it's possible that qq. $foo.bar() . could parse okay if we treat the () as a terminator that some grammatical construct is looking ahead for. But given that $foo is the one interpolator that doesn't require trailing brackets, it seems like it's terribly ambigous in this case. However, only dot has that problem, and with qq: @foo::bar[] : you know it requires the [] to interpolate at all. So I guess this is one of those we can argue both ways. The chance of someone writing qq:@foo::bar[] when they mean qq:@foo: :bar[] seems fairly remote. So my best guess at this point is that we should let the interpolative lookahead hide the trailing delimiter also, and that is probably what the user expects in any event, since when they were writing the expression, the nearby context is the preceding term, but the distant context is the delimiter, which they've probably just forgotten is potentially ambiguous. So let's just resolve it that way without telling them. I guess this is the one place we're requiring arbitrarily long lookahead to figure things out, since we interpolate @foo::bar::baz::fee::fie::foe[] but not @foo::bar::baz::fee::fie::foe under the current rules. I think the lookahead doesn't have to parse past the [ (or other opener), though. All it has to decide is whether the next : (or dot) is to be treated as part of the interpolation. So this is a syntax error (of the runaway variety, presumably): @foo::bar::baz::fee::fie::foe[ Larry
Re: Quoting interpolation in Perl5 vs. Perl6
On Saturday 16 April 2005 10:10 pm, Larry Wall wrote: So this is a syntax error (of the runaway variety, presumably): @foo::bar::baz::fee::fie::foe[ I was with you until that. What about @foo::bar::baz::fee::fie::foe[ 1 ] Isn't that a valid index into the array? Or is that just true with hashes? -- -Roie v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8 [ http://www.hackerkey.com ]
Re: Quoting interpolation in Perl5 vs. Perl6
On Sat, Apr 16, 2005 at 10:16:43PM +0300, Roie Marianer wrote: : On Saturday 16 April 2005 10:10 pm, Larry Wall wrote: : So : this is a syntax error (of the runaway variety, presumably): : : @foo::bar::baz::fee::fie::foe[ : I was with you until that. What about : @foo::bar::baz::fee::fie::foe[ 1 ] : Isn't that a valid index into the array? Or is that just true with hashes? No, you're right--I was just talking about the case where the user actually writes an unmatched bracket. Larry
Re: [] ugly and hard to type
Larry Wall skribis 2005-04-16 11:08 (-0700):
: $foo ~~ /@{ [ ] { } : ++ $ . ? / +| + ?| ? }/
Not unless you backwhack that internal there.
[...]
@myfavoritepunctuations = [ ] { } \ : ++ $ . ? / +| + ?| ? ;
Why isn't nesting allowed there? I'd expect it to work a bit like q
foo bar in Perl 5, which equals
foo bar .
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: [] ugly and hard to type
On Sat, Apr 16, 2005 at 10:01:44PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-16 11:08 (-0700):
: : $foo ~~ /@{ [ ] { } : ++ $ . ? / +| + ?| ? }/
: Not unless you backwhack that internal there.
: [...]
: @myfavoritepunctuations = [ ] { } \ : ++ $ . ? / +| + ?| ? ;
:
: Why isn't nesting allowed there? I'd expect it to work a bit like q
: foo bar in Perl 5, which equals
: foo bar .
Forgot about that. I guess we should talk about it. It's pretty obvious
what the benefits of doing it that way are. I only wonder if, in the
age of Unicode, it's going to get a little less clear what are actually
brackets and what aren't, unless you actually look up the properties.
But then, that constraint applies to openers and closers in general, so
maybe it's not an issue with respect to embedded openers and closers.
Okay, let's keep the P5 semantics, unless someone can think up a better
reason not to than I have.
Larry
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
According to Michael G Schwern: Yes, there are lots of ways to check the cwd each filling in one edge case or another. However I'd like to believe its possible to come up with one simple, safe cwd() that works for 99.9% of the cases and call that cwd(). Well, it's certainly possible ... and it's not up to me, anyway; but I still think it's a Bad Idea to standardize like that. I've already said why (there's no good reason to pick one over another), though it doesn't surprise me opinions differ. :-, A high level language really should smooth all that over. An HLL or LLL, it doesn't really matter. This isn't a language feature, this is an _operating_system_ feature. Pretending that the system is providing an attribute that it really isn't just confuses people in the long run. * The cwd is deleted * A parent directory is renamed * A parent directory is a symlink s/parent/parent or current/g. Also: * A parent or current directory is relocated entirely, not just renamed within the same parent * A parent or current directory has become unreadable * Any of the above happens _during_ the execution of cwd(), rather than beforehand [2] The state of Cwd.pm's docs add to my anxiety. Sucker punch. :-) -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] Open Source is not an excuse to write fun code then leave the actual work to others.
Re: ANN: JavaScript TestSimple 0.02
* Decide where to send test output, and where to allow other output to be sent. Test::Builder clones STDERR and STDOUT for this purpose. We'll probably have to do it by overriding Cdocument.write(), but it'd be good to allow users to define alternate outputs (tests may not always run in a browser, eh?). Maybe we can use an output object? Currently, a browser and its DOM are expected to be present. I could really use some advice from real JavaScript gurus on this one. It's going to totally depend on what you want to wrap around it... Do you want the human interacty mode? Or the machine county mode. Forget the document object for a moment, you are more accurately in the ever present window when you are running. I just finished Class::Adapter, so I'm currently imagining some sort of basic IO Adapter... TestOutputArray just appends to an internal array, TestOutputDocument appends to window.document... Or you could just create an anonymous document object, and use that for the internal case. Adam K
Re: Kwalitee and has_test_*
Christopher H. Laco wrote: Tony Bowden wrote: On Thu, Apr 07, 2005 at 12:32:31PM -0400, Christopher H. Laco wrote: CPANTS can't check that for me, as I don't ship those tests. They're part of my development environment, not part of my release tree. That is true. But if you don't ship them, how do I know you bothered to check those things in the first place? Why do you care? What's the difference to you between me shipping a a .t file that uses Pod::Coverage, or by having an internal system that uses Devel::Cover in a mode that makes sure I have 100% coverage on everything, including POD, or even if I hire a team of Benedictine Monks to peruse my code and look for problems? The only thing that should matter to you is whether the Pod coverage is adequate, not how that happens. I think you just answered youre own question, assuming you just agreed that I should care about whether your pod coverage is adequate. How as a module consumer would I find out that the Pod coverage is adequate again? Why the [unshipped] .t file in this case. The only other way to tell is to a) write my own pod_coverage.t test for someone elses module at install time, or b) hand review all of the pod vs. code. Or CPANTS. The main point is not so much that you define a measure of quality, but that you dictate to everyone the one true way in which they must determine it. The POD is the worst example of this. Why on earth should you care? You say because you should care if the author does consistent POD checking. Fine, but you dictate the One True Path to POD checking, which is to bundle a test for it with the package. I've got all sorts of crap in my package delivery pipeline, but it doesn't mean I want to go bundling all of it in. Imagine a PPI-based tool that verifies that the required version matches the syntax. Should we make every single module bundle it, and make every single user download a 55 class 5000 SLOC 3 meg package? Just to install Thingy.pm. Why not give a kwalitee point for modules that bundle a test that checks for kwalitee? The required kwalitee.t checks quality and requires your kwalitee be over 15 before passing. Where does it end? Adam K
Re: Kwalitee and has_test_*
Michael Graham wrote: Another good reason to ship all of your development tests with code is that it makes it easer for users to submit patches with tests. Or to fork your code and retain all your development tools and methods. Perl::MinimumVersion, which doesn't exist yet, could check that the version a module says it needs is higher than what Perl::MinimumVersion can work out based on syntax alone. And it uses PPI... all 55 classes of it... which uses Class::Autouse, which uses Class::Inspector, and prefork.pm, and Scalar::Util and List::Util, oh and List::MoreUtils and a few other bits and pieces. I'm not going to push that giant nest of dependencies on people just so they can install Chart::Math::Axis... So I run it in my packaging pipeline. It's a low percentage test that catches some annoying cases that bite me once a year. And I should probably not talk about the RecDescent parser for the bundled .sql files, or the test that ensures that any bundled .gif files are at something close to their best possible compression level. Adam K
Re: TestSimple/More/Builder in JavaScript
David Wheeler wrote: On Apr 7, 2005, at 11:32 AM, Christopher H. Laco wrote: OK, now whos gonna build JPANTS? :-) JSPANTS, you mean? I think we need a CJSPAN, first. Alias? Yes well... I'm getting there slowly. JavaScript::Librarian + Algorithm::Dependency + YAML ought to be enough to get some basics sorted out... Adam K
Re: Kwalitee and has_test_*
Michael Graham wrote: Another good reason to ship all of your development tests with code is that it makes it easer for users to submit patches with tests. Or to fork your code and retain all your development tools and methods. Perl::MinimumVersion, which doesn't exist yet, could check that the version a module says it needs is higher than what Perl::MinimumVersion can work out based on syntax alone. And it uses PPI... all 55 classes of it... which uses Class::Autouse, which uses Class::Inspector, and prefork.pm, and Scalar::Util and List::Util, oh and List::MoreUtils and a few other bits and pieces. I'm not going to push that giant nest of dependencies on people just so they can install Chart::Math::Axis... I'm not suggesting that end users be forced to *run* your development tests. Just that the tests be included in your CPAN package. Ideally, the install process can be made smart enough to skip this kind of test. So I run it in my packaging pipeline. It's a low percentage test that catches some annoying cases that bite me once a year. And I should probably not talk about the RecDescent parser for the bundled .sql files, or the test that ensures that any bundled .gif files are at something close to their best possible compression level. If someone were to take over maintenance of your module, or they were to fork it, or they were submitting patches to you, then they would want these tools and tests, right? How would they get them? Michael --- Michael Graham [EMAIL PROTECTED] YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - [EMAIL PROTECTED] ---
Re: Comparing rationals/floats
On Fri, Apr 15, 2005 at 04:18:51PM -0700, gcomnz wrote: : More questions stemming from cookbook work... Decimal Comparisons: : : The most common recipe around for comparisons is to use sprintf to cut : the decimals to size and then compare strings. Seems ugly. Certainly, but I don't think the situation arises all that frequently in practice. : The non-stringification way to do it is usually along the lines of: : : if (abs($value1 - $value2) abs($value1 * epsilon)) : : (From Mastering Algorithms with Perl errata) You should someday peruse the Ada documentation for this sort of stuff. It's pretty enlightening (in the Zen sense of feeling smacked upside the head) about how hard it is to guarantee any particular set of real semantics across unknown machine architectures. : I'm wondering though, if C$value1 == $value2 is always wrong (or : almost always wrong) then should it be smarter and: : : a. throw a warning : b. DWIM using overloaded operators (as in reduce precision then compare) : c. throw a warning but have other comparison operators just for this : case to make sure you know what you're doing : : I'd vote for b., but I don't know enough about the problem domain to : know if that is safe, and realistically I just want to write the : cookbook entry rather than start a math-geniuses flame war ;-) I think I'd vote for d. Educate users that they almost never want to use == to compare two numbers on the real number line, however they're represented. e. Put some rough dwimmery into the ~~ operator instead. The definition of rough dwimmery can be negotiated, but as a form of definitional handwaving it's probably enough to write examples with. I welcome input from people who know more about this than I do, but in the interests of speed, you probably want some way to tell ~~ how many bits of binary mantissa to pay attention to if the exponents are equal, so you can do most of your work without a horrid conversion to decimal, or less horribly, subtraction to find a number to compare to your epsilon. But by the time you compare exponents, it's possible that it's cheaper to go ahead and let the hardware do the subtraction for you. I'll leave that up to the implementors. My main point is that the default slop should be fairly liberal on the assumption that the ordinary user has written a fairly sloppy algorithm. I'd probably leave about the last 8 bits out of an ordinary double comparison, but let the user change that pragmatically. I can see arguments for making the slop a lot bigger than that. On the other hand, you don't want to make it so big that different integers start comparing as equal merely because they happen to be big. On the other other hand, if you know you're storing only integer values into your floaters, you can safely use == instead of ~~ because they will always compare equal until you exceed the precision of the floater. On the other other other hand, we're gonna all be using 64-bit computers in a few years, so there will be less demand for putting large integers into floaters to get around 32-bit limitations. 'Course, then we'll be worrying about the precision of 128-bit floaters... : Which leads to another question: Are there $value.precision() and : $value.accuracy() methods available for decimals? I'd really rather : not do the string comparison if it can be avoided, maybe it's just the : purist in me saying leave the numbers be :-) As the other reply pointed out, it'd be nice to have a data type that supports these semantics, but they would certainly run slower than the usual floating-point algorithms do. Historically the people doing this sort of stuff would rather have the raw speed and just sort of hand calculate the uncertainty in their heads, from the basic rule-of-thumb that additions add uncertainty, while multiplications multiply uncertainties. But for models that are trying to be provably accurate rather than fast, I could see a use for the smarter data type. For the rest of us, leaving out about 8 bits for ~~ comparison lets us use algorithms with a little bit of additive slop, and punishes us a bit when we use algorithms with a lot of multiplicative slop. :-) : Apologies in advance if this is somewhere I missed. I did a lot of searching. It's not something we've paid much attention to, partly because I *did* read the Ada spec when it first came out. :-) Larry
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
Chip Salzenberg wrote:
As you know, under Unix, there's no such thing as the current
directory as a string. The only durable current directory is the
device and inode of Cstat('.'). It's not wise to conflate the
current directory with a name that at some point in the past could
have been used to reach it.
So can we make a stronger statement, and say that Perl6 won't think of
directories as strings, either. When you ask for a directory, it'll give
you an object. If you use one in string context then it will try its
best to give you a string that your OS might be able to use to access it
(or, thinking about cygwin, a string that a different OS might be able
to use...). But if it can't (e.g. when you access a directory relative
to one whose name it doesn't know), then it will fail.
A directory object could have a method to tell you if it thinks its
stringification is currently valid (i.e. if it can stat it and get the
same device+inode). It could also have a method that attempts obtain a
currently-valid name.
It'd also suggest that Copen et al should be methods on a directory
object (default object for the global forms would be $*ENV.cwd)
And Csystem, Cexec, Cqx etc. shoul be methods on an environment
object, again defaulting to $*ENV. I should be able to do
my Env $env = $*ENV.clone;
$env.cwd ~= /..;
$env.system(foo);
$env.fork might be interesting, too -- I'd expect it to set $*ENV = $env
in the child process. Which could be nice if an Env also has stdout,
stdin, etc. methods.
You have to because when a new user asks how do I get the current
working directory? [...]
How do you get the cwd? You call $*ENV.cwd. How to you get its name? You
use it in string context. (Of course, a new user probably won't think to
ask that second question: they'll print it, and it'll do what they
expect ... most of the time).
More quoting issues
OK, so I'm getting close to having everything work ( gave me a hard time,
but I tamed it in the end). I noticed something weird about the construct:
pugs %a
(('1' = 'a'), ('1 2' = 'both'), ('2' = 'b'))
pugs %a{1 2}
'both'
pugs %a{1,2}
('a', 'b')
pugs %a{1 2,()}
('a', 'b')
I tried to look into things, and it seems that 1 2 acting like a scalar when
it's inside a hash subscript, but nowhere else; when I forced the final
parameter of doFetch to be False (Eval.hs line 402) I got the correct result.
I have no idea what's going on in there, so I thought I might throw this out
to whoever does. I'll try to go in deeper later, but sleep and homework await
me. (Also, I'm waiting for the repository to come back up, I want the
history).
Incidentally, %a1 2 does work in the current version, but that's because
it's not a real quoting construct (which means it doesn't interpolate \, for
example). I found the bug when I tried to make %a1 2 act like real ,
and broke it.
Oh, I'm on r2044. (Can't update, no svn.openfoundry.org)
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Re: Python on parrot
Kevin Tew wrote: Sam, Just wondering what the status is on python/parrot/pirate/pyrate. These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/ I haven't looked at it for a few months now. I do plan to revisit it enough to get the Pie-thon tests completed by the time of OSCON (in August). Is there a up to date cvs repo? http://pirate.tangentcode.com/ Can we get this code checked into the parrot svn repo? Unfortunately, no. Much of this code is copyright Michal Wallace. The good news is that the good stuff is in the parrot repo already. What is left - a simple translator - can and should, IMHO, be recoded into Perl6 once enough of that is running. - Sam Ruby
Re: Python on parrot
[I hope you don't mind me putting this back on the list - I would prefer that everybody who is interested can follow along and/or participate] Kevin Tew wrote: Sam Ruby wrote: Kevin Tew wrote: Sam, Just wondering what the status is on python/parrot/pirate/pyrate. These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/ I haven't looked at it for a few months now. I do plan to revisit it enough to get the Pie-thon tests completed by the time of OSCON (in August). Is there a up to date cvs repo? http://pirate.tangentcode.com/ Can we get this code checked into the parrot svn repo? Unfortunately, no. Much of this code is copyright Michal Wallace. The good news is that the good stuff is in the parrot repo already. What is left - a simple translator - can and should, IMHO, be recoded into Perl6 once enough of that is running. - Sam Ruby So why won't Michal Wallace sign over the copyright? I talked to Michal briefly about this a while back. My impression was that he wanted to sign over the copyright to the Python foundation. Which makes a bit of sense - the goal of having everything run on a single runtime does not necessarily imply that everything has to be owned by a single organization and put into a single repository. My own opinions is that Michal thinks too much. ;-) My impression is that everybody here is reasonable, and if it made sense for further development to be transferred to another organization, then some reasonable arrangement would be made. Also, I believe that much of the initial work is throwaway work anyway. Build one to throw away, and all that. Cool I did notice all the python pmcs. By translator I assume you mean a interpreter/compiler to parrot byte code. At the moment, it is to Python to IMC, but eventually going directly to bytecode would be a good idea. Why would you do it in Perl6, why not self hosted in python? Self hosted in Python is a good idea, once it can be bootstrapped. Overview of the current process: 1) Leverage python's compiler class to convert source to AST 2) Pirate converts AST to IMC 3) Parrot converts IMC to bytecode I'm thinking of toying around with python and just want to leverage all the previous work. Excellent. In the meantime, if you are interested in getting commit access to the Pirate repository, I'm confident that that can be arranged. My feeling, for what it is worth, the translator is known to be a solvable problem. Determining the proper mapping of Python semantics to Parrot is the research problem. The overwhelming majority of that work is in getting the PMCs right. Not having to worry about the syntax of python or the conversion to bytecodes allows one to focus on just that aspect of the problem. But, as with all open source projects, feel free to scratch your own itches. Looks like I'll start with a translator and some new test cases so they can be contributed copyright free. There also are a fair amount of python test cases in the parrot repository. parrot/languages/python/*/*.t and t/dynclass/python/*.t. When I last looked, these were not complete. Undoubtably, there is likely to be some minor regressions as I have not kept up with the latest Parrot changes. If past history is any guide, this is not much of a problem. - Sam Ruby
Re: Kwalitee and has_test_*
On Sat, 2005-04-16 at 19:31 -0400, Michael Graham wrote: I'm not suggesting that end users be forced to *run* your development tests. Just that the tests be included in your CPAN package. Ideally, the install process can be made smart enough to skip this kind of test. Shipping tests but not running them is a sign of kwalitee? Some file somewhere mentions POD::Coverage is a sign of kwalitee? Shipping useless code is a sign of kwalitee? I'm about halfway ready to propose 'has_indentation' as a kwalitee metric. If someone were to take over maintenance of your module, or they were to fork it, or they were submitting patches to you, then they would want these tools and tests, right? How would they get them? I think this is a discussion completely separate from CPANTS' kwalitee metrics. Besides, if someone wants to run test or documentation coverage checks against any of my modules, he or she ought to be able to copy and paste the SYNOPSIS output to the appropriate test files, if not ask me for them outright. -- c
Re: Kwalitee and has_test_*
I'm about halfway ready to propose 'has_indentation' as a kwalitee metric. And the more the better! -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Kwalitee and has_test_*
On Sat, 2005-04-16 at 20:59 -0500, Andy Lester wrote: I'm about halfway ready to propose 'has_indentation' as a kwalitee metric. And the more the better! Well sure. Two-space indent is clearly better than one-space indent, and four-space is at least twice as good as that. It falls down a bit as the numbers increase from there, though. -- c
Re: [perl #34988] [PATCH] Fix a few more typos
On Thu, 2005-04-14 at 12:28 -0700, Nick Glencross wrote: This patch fixes a few more typos. I'll leave it a few months before doing this again. I'm assuming that 'heisenbugs' is for real, that made me chuckle It's a real term, for as real as programmer neologisms can be. Thanks, applied. -- c
Re: [perl #34989] [PATCH] Fix a few more typos
On Thu, 2005-04-14 at 12:29 -0700, Nick Glencross wrote: This patch fixes a few more typos. I'll leave it a few months before doing this again. This looks like a duplicate of #34988, which I've applied, so queuemasters please close. Nick, I've changed at least one occurrence of 'uninitialized' back to 'initialized'. Please check the other and ensure that I caught it all. -- c
Re: More quoting issues
On Sun, Apr 17, 2005 at 03:33:26AM +0300, Roie Marianer wrote: I tried to look into things, and it seems that 1 2 acting like a scalar when it's inside a hash subscript, but nowhere else; when I forced the final parameter of doFetch to be False (Eval.hs line 402) I got the correct result. You need to add a case to AST.hs line 580ish to tell it that 1 2, like (1,), /looks/ like a list, not a scalar. Oh, I'm on r2044. (Can't update, no svn.openfoundry.org) Sorry for the downtime; it should be fixed in the next 18 hours or so... Meanwhile, you can svn switch to this repository: http://svn.perl.org/perl6/pugs/trunk/ and feel free to post patches on p6c, so I can apply them. :) Thanks, /Autrijus/ pgp8LidSYSiFv.pgp Description: PGP signature
forced manifest check
Well, it always depends, how responds looks like: Committed revision 1234 * ATT MAINFEST ERROR missing bla.bla ... * This is very similar to what it did under CVS, although maybe not quite as big. Anyway, if this is something the community wants, if someone could implement a first pass at the hook script, we can run it. It'll need to use svnlook cat to look at the Manifest, svnlook changed to detect new files or removed files, and then compare. Actual details are up to the implementer. Many thanks to Garrett Goebel who created our CVS implementation. -R
