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: 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 pgpjlpg0MKhs0.pgp Description: PGP signature
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: 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: 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: [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
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: [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: 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: 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: [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
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
