Re: PerlNum -0.0 bug?
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: # define Parrot_is_nzero(x) ((x) == copysign(0.0, -1.0)) use that if signbit isn't, patch? applied ;) Thanks, leo
Re: Optimizations for Objects
Dan Sugalski [EMAIL PROTECTED] wrote: At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote: Which brings up again my warnocked question: How can return continuations get reused? Works like this. (No pasm, but it should be obvious) Ok. First (and that applies to Jens example too), I'd like to outline continuation vs return continuation and its usage: 1) First there was only a Continuation PMC. Performance with CPS sucked. So I did invent a RetContinuation PMC Performance sucked less. The difference between these two is: the former has COW copied stacks inside its context, the latter has only pointers of the stacks in its context. 2) A return continuation is automatically created by invokecc callmethodcc It's totally hidden when using PIR function or method call syntax _func(a, b) obj.meth(args) These internally create above opcodes and create a new return continuation on each sub or method invocation 3) Returning from the sub or method in PIR syntax again totally hides the return continuation .pcc_begin_return .return result .pcc_end_return .end or just .sub _foo .end# automatic return sequence inserted. 4) From PIR level there is no official way to even reference this return continuation - its invisible. 5) *But* If a continuation's taken from within a sub somewhere, return continuations may (probably will) be used multiple times, once for the original return then once for each time the continuation is invoked. 6) Yes, that's true. So the questios is: Can we invent some HLL PIR syntax that clearly indicates: this subroutine will return multiple times through the same return continuation. We have already a similar construct for Coroutines: .pcc_begin_yield .result # optional .pcc_end_yield This is invokeing the coroutine and returns to the caller. What's the usage of Continuations from HLLs point of view? Can we get some hints, what is intended? I'd like to have, if possible a clear indication: that's a plain function or method call and this is not. I think the possible speedup is worth the effort. leo
Re: [BUG] imcc: no newline at end of file
Jens Rieks [EMAIL PROTECTED] wrote: the attached test fails. There is no newline at the end of the file. Imcc is reading text files. A text file has a newline on *each* line. The error message could be a bit more user friendly, though. leo
Re: [perl #27746] Fix for languages/tcl, when '.' is not in $PATH
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: this patch changes the calls of parrot to './parrot'. This is needed when the current directory is not in $PATH. Thanks, applied. leo
Re: cvs commit: parrot/config/gen/platform/generic math.h
Leopold Toetsch wrote: Courtesy of Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Er...that wasn't me--I was just passing it along, as I said in the message. (If it was me, I'd likely have committed it myself. ;^) ) Credit goes to Matt Fowles [EMAIL PROTECTED]. (Leo, I tried to send this to you directly, but got this message: host mail.toetsch.at [216.71.209.130]: 550 5.7.1 We donot relay.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: [perl #27690] Numeric comparison bug
The real problem is that you always want to use exactly the same code for
ALL cases of string-to-float conversion. The first public example of this
problem was the FORTRAN II compiler from IBM in the 60's. The compiler and
the IO library was written by two different people and so constants in
program code didn't match those read in from IO, OOPS! you'd think
people would remember and learn from the past. By exactly the same,
I mean exactly the same machine code (hardware floating point status and rounding mode
bits included) not just the same HL source code. I.e., You
need exactly one routine, compiled only once and used EVERYWHERE. It also pays
to have a single routine for the other direction that has the property:
S = ftos(atof(S)) and F = atof(ftoa(F)). Otherwise you get obscure
very hard to find bugs.
--
Mark Biggar
[EMAIL PROTECTED]
Its the old problem of rounding errors in floating point arithmetic.
In string_to_num() in src/string.c,
f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
Which in this case translates to 12.0*-1*0.1 which is -1.2000...2 != -1.2.
I replaced this bit of code from a block I found in mysql. I only tested
this
on linux, but it seems to do the trick. See attached.
Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
This code:
new P0, .PerlNum
set P0, -1.2
new P1, .PerlString
set P1, -1.2
eq_num P0, P1, OK
print not
OK: print ok\n
end
[And yes, I'm well aware of the problems inherent in doing floating point
comparisons.
Breakpoint 1, Parrot_PerlNum_cmp_num (interpreter=0x82654f0, pmc=0x40305850,
value=0x40305838) at perlnum.c:301
301 diff = PMC_num_val(pmc) - VTABLE_get_number(interpreter, value);
(gdb) n
302 return diff 0 ? 1 : diff 0 ? -1 : 0;
(gdb) p diff
$1 = 2.2204460492503131e-16
(gdb)
Simon
leo
*** tmp/parrot/src/string.c Sat Mar 6 03:00:06 2004
--- parrot/src/string.c Wed Mar 17 12:24:02 2004
***
*** 1836,1844
int exp_sign = 0;
INTVAL in_exp = 0;
INTVAL in_number = 0;
! FLOATVAL exponent = 0;
INTVAL fake_exponent = 0;
INTVAL digit_family = 0;
while (start end) {
UINTVAL c = s-encoding-decode(start);
--- 1836,1845
int exp_sign = 0;
INTVAL in_exp = 0;
INTVAL in_number = 0;
! INTVAL exponent = 0;
INTVAL fake_exponent = 0;
INTVAL digit_family = 0;
+ FLOATVAL exp_log=10.0, exp_val=1.0;
while (start end) {
UINTVAL c = s-encoding-decode(start);
***
*** 1849,1855
if (df df == digit_family) {
if (in_exp) {
! exponent = exponent * 10 + s-type-get_digit(s-type,c);
if (!exp_sign) {
exp_sign = 1;
}
--- 1850,1856
if (df df == digit_family) {
if (in_exp) {
! exponent = exponent + s-type-get_digit(s-type,c);
if (!exp_sign) {
exp_sign = 1;
}
***
*** 1906,1912
exponent = fake_exponent + exponent * exp_sign;
! f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
}
return f;
--- 1907,1936
exponent = fake_exponent + exponent * exp_sign;
! if(exponent 0) {
! exponent = -exponent;
! exp_sign=-1;
! }
!
! for (;;) {
! if (exponent 1) {
! exp_val *= exp_log;
! exponent--;
! }
! if (!exponent)
! break;
! exp_log *= exp_log;
! exponent = 1;
! }
!
! if(exp_sign 0)
! f /= exp_val;
! else
! f *= exp_val;
!
!
! if(sign 0)
! f = -f;
}
return f;
Re: Continuation usage
Piers Cawley [EMAIL PROTECTED] wrote: Jens Rieks [EMAIL PROTECTED] writes: Hi, does the attached test use the Continuation in a correct way? The test failes, what am I doing wrong? Without running it I'm guessing that it prints out something like 456=789 456=456 123=123 Why would it print 3 lines? Easy. Brrr. One part of your problem (The state of P16-18) is, therefore, a bug in your program. The other part seems to be a bug in the current implementation of Continuation. Yep. A new Continuation should grab the current P1 continuation. If you later invoke that Continuation, it should make the jump and reset P1. Until that's done, all we have is a heavyweight goto. I don't get that. Below is a stripped down version of Jens program. There are 2 ways of invokeing the return continuation: invoke conti or conti() The former is more or less ignored by imcc, the latter is recognized as a regular function call: registers are preserved and a flag sub_calls_a_sub is set, so that e.g. the return continuation is preserved around the call. These variants give different output. How schould it really work? .sub _main .local int a a = 1 _func() print a print main\n end .end .sub _func .local pmc conti .local int a a = 4 conti = newcont _end _do_something( conti ) _end: print a print _func\n .end .sub _do_something .param pmc conti .local int a a = 7 # invoke conti # (1) conti() # (2) print error!\n .end Thanks, leo
Re: [BUG] imcc: no newline at end of file
Jens Rieks [EMAIL PROTECTED] wrote: Hi, the attached test fails. There is no newline at the end of the file. I think that imcc is causing a memory leak due to this, I got error messages like: store_sub_in_namespace: sub '__new_class' namespace #1082752832 too big.namespace Must have beed something different. in a large program due to this bug. Please note the .namespace at the end of the error message, which is also printed by parrot when running this small test. The .namespace was printed by the lexer because a rule was lacking for this case (begin of comment, but no newline). So the default rule (ECHO) of flex did print it to stdout. Due to the missing newline, it arrived on the console after the ok. Now its: $ parrot basic_22.imc error:imcc:parse error, unexpected $undefined, expecting $end in file 'basic_22.imc' line 7 jens Thanks for the test, leo
[CVS ci] OpsFile hints - 1
Some weeks ago I posted a proposal for additional hints in ops files. We
need additionally (at least):
1) a per argument flag, if this argument is indicating a branch offset
or address:
inline op bsr (label INT)
label is basically in, additionally there are now labelvar and
labelconst which transform to invar and inconst. The label
variants set additionally a bit, that this argument has branch
information (from core.pm):
LABELS = [ 0, 1 ] # first is opcode
2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done
a few - only to see if it get parsed correctly. This needs a lot of work
and thought. Any help is much appreciated here.
3) A flag, if the opcode should do event checking, e.g. invoke and such.
The Syntax for 2 and 3 is just (\S*) which goes into FLAGS currently.
So the Cbsr opcode is now:
inline op bsr (label INT) :base_core,check_event {
And in core.pm is a line:
FLAGS = :base_core,check_event,
which awaits further processing.
leo
Re: [perl #27690] Numeric comparison bug
Mark A Biggar [EMAIL PROTECTED] wrote: The real problem is that you always want to use exactly the same code for ALL cases of string-to-float conversion. Yep, was outlined by Larry too. That's already changed. [ Please don't quote the whole thread, thanks ] leo
Re: [CVS ci] OpsFile hints - 1
Leopold Toetsch wrote: Some weeks ago I posted a proposal for additional hints in ops files. We need additionally (at least): 1) a per argument flag, if this argument is indicating a branch offset 2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done 3) A flag, if the opcode should do event checking, e.g. invoke and such. We also need a way to mark ops for inclusion in miniparrot's limited op set--although it might be better to do that in an external file. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote: Which brings up again my warnocked question: How can return continuations get reused? Works like this. (No pasm, but it should be obvious) Ok. First (and that applies to Jens example too), I'd like to outline continuation vs return continuation and its usage: 1) First there was only a Continuation PMC. Performance with CPS sucked. So I did invent a RetContinuation PMC Performance sucked less. The difference between these two is: the former has COW copied stacks inside its context, the latter has only pointers of the stacks in its context. 2) A return continuation is automatically created by invokecc callmethodcc It's totally hidden when using PIR function or method call syntax _func(a, b) obj.meth(args) These internally create above opcodes and create a new return continuation on each sub or method invocation 3) Returning from the sub or method in PIR syntax again totally hides the return continuation .pcc_begin_return .return result .pcc_end_return .end or just .sub _foo .end# automatic return sequence inserted. 4) From PIR level there is no official way to even reference this return continuation - its invisible. 5) *But* If a continuation's taken from within a sub somewhere, return continuations may (probably will) be used multiple times, once for the original return then once for each time the continuation is invoked. 6) Yes, that's true. So the questios is: Can we invent some HLL PIR syntax that clearly indicates: this subroutine will return multiple times through the same return continuation. We have already a similar construct for Coroutines: .pcc_begin_yield .result # optional .pcc_end_yield This is invokeing the coroutine and returns to the caller. What's the usage of Continuations from HLLs point of view? Can we get some hints, what is intended? I'd like to have, if possible a clear indication: that's a plain function or method call and this is not. I think the possible speedup is worth the effort. I think that requires solving the halting problem.
Re: [CVS ci] OpsFile hints - 1
Hi,
On Friday 19 March 2004 12:07, Leopold Toetsch wrote:
Some weeks ago I posted a proposal for additional hints in ops files. We
need additionally (at least):
1) a per argument flag, if this argument is indicating a branch offset
or address:
inline op bsr (label INT)
label is basically in, additionally there are now labelvar and
labelconst which transform to invar and inconst. The label
variants set additionally a bit, that this argument has branch
information (from core.pm):
LABELS = [ 0, 1 ] # first is opcode
2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done
a few - only to see if it get parsed correctly. This needs a lot of work
and thought. Any help is much appreciated here.
I want to help. Tell me what OP range or file I should work on,
and I'll try my best.
3) A flag, if the opcode should do event checking, e.g. invoke and such.
The Syntax for 2 and 3 is just (\S*) which goes into FLAGS currently.
So the Cbsr opcode is now:
inline op bsr (label INT) :base_core,check_event {
And in core.pm is a line:
FLAGS = :base_core,check_event,
which awaits further processing.
leo
jens
[Patch] fix tests failing due to recent PerlNum modifications
jens Index: t/pmc/pmc.t === RCS file: /cvs/public/parrot/t/pmc/pmc.t,v retrieving revision 1.84 diff -u -r1.84 pmc.t --- t/pmc/pmc.t 14 Mar 2004 08:49:16 - 1.84 +++ t/pmc/pmc.t 19 Mar 2004 12:20:49 - @@ -774,7 +774,7 @@ set P0, 0.0 set S0, P0 -eq S0, 0, OK5 +eq S0, 0.00, OK5 print not OK5:print ok 5\n Index: t/pmc/perlnum.t === RCS file: /cvs/public/parrot/t/pmc/perlnum.t,v retrieving revision 1.7 diff -u -r1.7 perlnum.t --- t/pmc/perlnum.t 18 Mar 2004 10:40:54 - 1.7 +++ t/pmc/perlnum.t 19 Mar 2004 12:20:50 - @@ -697,6 +697,6 @@ print \n end CODE -0 +0.00 -0.00 OUTPUT Index: t/pmc/dumper.t === RCS file: /cvs/public/parrot/t/pmc/dumper.t,v retrieving revision 1.9 diff -u -r1.9 dumper.t --- t/pmc/dumper.t 16 Mar 2004 09:19:46 - 1.9 +++ t/pmc/dumper.t 19 Mar 2004 12:20:50 - @@ -211,7 +211,7 @@ 0.30, 3, bravo, -0, +0.00, 0, echo ] Index: t/pmc/sort.t === RCS file: /cvs/public/parrot/t/pmc/sort.t,v retrieving revision 1.4 diff -u -r1.4 sort.t --- t/pmc/sort.t 8 Mar 2004 00:20:09 - 1.4 +++ t/pmc/sort.t 19 Mar 2004 12:20:50 - @@ -281,7 +281,7 @@ .include library/sort.imc CODE 0 -0 +0.00 0.10 0.20 0.30
Re: Optimizations for Objects
I may have a possible solution. Disclaimer: I do not really understand continuations, so I may be completely wrong. This idea involves two assumptions: 1. Most Parrot code will not use continuations except for returning. (There will be a significant efficiency loss otherwise.) 2. The most expensive part of constructing a continuation is COWing the stack, etc.--simply constructing the data structure is cheap. 3. A return continuation may be safely reused if: a. It has not been stored externally. b. None of the return continuations for subroutines it has called (recursively speaking) have been stored externally. c. No other continuations have been constructed. Here's how it works: A ReturnContinuation is a lightweight version of a normal Continuation; it contains the information needed to create a Continuation, but is not really a continuation itself. Once allocated, a ReturnContinuation is never[1] truly deallocated; if it dies, it's put on a free list, and will be reused if it's needed. Before a ReturnContinuation may be stored externally (and thus have the possibility of being invoked later), it has to be transformed into a normal Continuation. This will probably require compilers (or IMCC) to insert an extra instruction, but I don't think that'd be too difficult. (A naive way to do it would be to simply emit a second/different instruction whenever P1 is retrieved. It might be possible to make IMCC do this, or even to write this into the 'set' op.) If a program either creates a normal Continuation or transforms a ReturnContinuation into a normal one, Parrot will automatically turn all currently-live ReturnContinuations into normal Continuations. (How is an unknown, admittedly--perhaps we'll keep a list of currently-live ReturnContinuations, too.) This means that your return continuation may in fact be a real Continuation instead of a ReturnContinuation. If a ReturnContinuation is invoked without being stored externally (and thus transformed into a real Continuation), it is immediately considered dead, and returns to the free list. The effect is that the heavy work of constructing real Continuations is deferred until we have a good reason to believe they'll be needed. For programs that never use continuations except for old-fashioned returning, a lot of work is avoided, because ReturnContinuations are faster to construct; for programs that do use continuations, a little extra work is done, because it would have been faster to construct real Continuations in the first place. I suspect this would usually be a win, although it might be wise to give the language compiler a way to say I know this program will use continuations, so just construct them that way in the first place. Example: A calls B, creates ReturnContinuation rA1. B calls C, creates ReturnContinuation rB1. C invokes ReturnContinuation rB1 to return to B. ReturnContinuation rB1 returns to the free list. B calls D, creates ReturnContinuation rB2 (ex-rB1?). D stores rB2 into Z: rB2 becomes a real Continuation. rA1 becomes a real Continuation. D invokes Continuation rB2 to return. Continuation rB2 does *not* return to the free list. B calls E, creates ReturnContinuation rB3. E invokes ReturnContinuation rB3 to return. ReturnContinuation rB3 returns to the free list. B invokes Continuation rA1 to return. Continuation rA1 does *not* return to the free list. A calls F, creates ReturnContinuation rA2 (ex-rB3?). F creates and stores a new Continuation into Y: rA2 becomes a real Continuation. F invokes rA2 to return. Continuation rA1 does *not* return to the free list. A invokes Z--control jumps to the next statement in B after the call to D. [1] Conceptually, that is. Realistically, it might make sense to do so if you have a few thousand spare return continuations floating around. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: [CVS ci] OpsFile hints - 1
Jens Rieks [EMAIL PROTECTED] wrote: Hi, On Friday 19 March 2004 12:07, Leopold Toetsch wrote: 2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done a few - only to see if it get parsed correctly. This needs a lot of work and thought. Any help is much appreciated here. I want to help. Tell me what OP range or file I should work on, and I'll try my best. Great, thanks. I'll currently touch core.ops only. So you can do just the rest ;) leo
Re: [CVS ci] OpsFile hints - 1
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: Some weeks ago I posted a proposal for additional hints in ops files. We need additionally (at least): 1) a per argument flag, if this argument is indicating a branch offset 2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done 3) A flag, if the opcode should do event checking, e.g. invoke and such. We also need a way to mark ops for inclusion in miniparrot's limited op set--although it might be better to do that in an external file. Or mark exclusion, which might be simpler. What ops aren't supposed to be in miniparrot? leo
Re: Continuation usage
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Jens Rieks [EMAIL PROTECTED] writes: Hi, does the attached test use the Continuation in a correct way? The test failes, what am I doing wrong? Without running it I'm guessing that it prints out something like 456=789 456=456 123=123 Why would it print 3 lines? Actually, it doesn't, I was going mad and mixing it up with the problem I've been having with ParrotUnit, which does bad things with returning...
Re: [CVS ci] OpsFile hints - 1
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: What ops aren't supposed to be in miniparrot? Anything we can't guarantee can be supported on any ANSI-compliant platform with very little to no probing. (Ideally, I'd like for miniparrot to include no test C programs; realistically, that may not be possible.) That means anything dealing with JIT, dynaloading, NCI, threading, signals, processes (except system()), possibly binary data, probably environment variables...you get the idea. That should be covered by the (todo) classification of ops. :miniparrot = :all except (:system | :some_other) leo
Re: [Patch] fix tests failing due to recent PerlNum modifications
Jens Rieks [EMAIL PROTECTED] wrote: I'm currently fixing the code. So thanks - not needed. leo
Something rotten with the state of continuations...
I've been trying to implement a Parrot port of xUnit so we can write tests natively in parrot and things were going reasonably well until I reached the point where I needed to do exception handling. Exception handling hurt my head, badly, so eventually I gave up and used a continuation instead. Here's the basic 'run' and 'exception failure' parts of my code (The current full suite is in the tar file attached): .sub run method .param pmc testResult .local Sub handler .local Sub exceptRet .local pmc name .local string nameString name = self.name() self.setResult(testResult) save nameString handler = new Continuation set_addr handler, catch0 self.setFailureHandler(handler) self.setUp() self.name() testResult.pass(nameString) finally: self.tearDown() .pcc_begin_return .pcc_end_return catch0: P17 = self.name() S16 = P17 P16 = P2.testResult() P16.fail(S16) branch finally .end .sub assertion_failed method .param string rawMsg .local pmc handler handler = self.failureHandler() # invoke handler handler() .end Now, depending on whether I use Chandler() or Chandler, teardown gets run 3 (handler()) or two (invoke) times. If I create the handler continuation using Chandler = newcont break0 then it makes it to branch0, but there are problems with self, the first method call works fine, but after that things go haywire and self appears to get trashed so method lookups fail after the first one. Very frustrating. BTW, you can make Leo's test program go into an infinite loop simply by replacing the n conti = newcont _end with new conti, .Continuation set_addr conti, _end which is weird because I *thought* they were supposed to do equivalent things.
Oops, here's the full parrotunit
I knew I forgot something in my last post... If you unpack this in your parrot directory you'll get library/parrotunit.imc library/TestCase.imc library/TestResult.imc library/WasRun.imc t/test.imc Go to the parrot directory and, do ./parrot t/test.imc and the tests will run. Annoyingly, everything works perfectly if none of the tests fail...
Re: Optimizations for Objects
This idea involves two assumptions: there are three kinds of people. those that can count and the others ;) ~ibotty
Re: [Patch] fix tests failing due to recent PerlNum modifications
Hi, On Friday 19 March 2004 16:23, Leopold Toetsch wrote: I'm currently fixing the code. So thanks - not needed. new P0, .PerlNum set P0, 0.0 print P0 should IMO print 0.00 rather than 0, because its a floating point number and not an integer. What are the arguments for printing 0? leo jens
Funky «vector» operator
I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Apologies if this is common knowledge, but it was news to me, and I thought I'd share this little Perl6 of wisdom. Your mileage may vary, of course, but now that I know that it's been hiding there in my keyboard all along and I didn't need to do anything special to set it up, I don't feel so uneasy about it being a Perl 6 operator. A
Re: Funky «vector» operator
Viernes 19 Marzo 2004 13:08, Andy Wardley wrote: I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Apologies if this is common knowledge, but it was news to me, and I thought I'd share this little Perl6 of wisdom. Hi Andy, Well, I did not know about it, so you can be sure that your message has enlighted at least one poor soul. By the way, it has never been easy to write Perl in certain keyboards. The spanish keyboard doesn't have the so perlish character ~, and one must use a different combination depending of your OS (like Alt + 126 or Alt + ¡ or Alt + ñ). Most people know about this sequence because the ~ character is a common one in URLs, so the situation is not as bad as i may look. Neverthless, I definetly hope that a future FAQ of perl6 has a big section labeled How do I Write These Funky Chars in My OS. And making a final big show of my ignorance: does anyone know if there is a easier way to write « and » in windows than ALT + 0171 and ALT + 0187? -angel
Re: Funky «vector» operator
Andy Wardley wrote in perl.perl6.language : I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Of course this information is almost completely unusable without knowing your OS, your locale, and your keyboard flavour. But thanks anyway, and I'll share mine : with vim, and with the 'digraph' option set, just type Del to get « Del to get » This is probably common knowledge as well.
Re: Funky «vector» operator
Angel Faus wrote: Most people know about this sequence because the ~ character is a common one in URLs, so the situation is not as bad as i may look. Neverthless, I definetly hope that a future FAQ of perl6 has a big section labeled How do I Write These Funky Chars in My OS. That sounds like a good idea. Might help avoid people being put off by operators like « and ». Another section close by on ASCII equivalents for those which have them would also go down well. For the record, on Mac OS X it's Option-\ for « and Option-Shift-\ for » (where Option-Shift-\ may also be seen as as Option-Shift-|). It is entirely possible that this is different on a normal Apple keyboard as opposed to the one in my Powerbook, but that strikes me as unlikely. Probably getting a little ahead of myself here though, as we can't actually use this masterpiece language yet. :-(
Re: Funky «vector» operator
Matthew Walton wrote: For the record, on Mac OS X it's Option-\ for « and Option-Shift-\ for » (where Option-Shift-\ may also be seen as as Option-Shift-|). It is entirely possible that this is different on a normal Apple keyboard as opposed to the one in my Powerbook, but that strikes me as unlikely. Specifying the OS is not enough, you need at least the keyboard layout. It would be impossible to have shortcuts involving | or \ on a French keyboard since they are respectively Alt-Shift-L and Alt-Shift-: OS X / iBook / fr-fr « Alt-è » Alt-Shit-è -- Robin Berjon
Re: Funky «vector» operator
For me, (vim 6.2), that is bs to get « bs to get » after doing :set digraph (list of available digraphs can be seen by :digraph) But, I find the above a bit unnerving because I've deleted the character, and then if I type a certain character next I haven't. Vim also allows ctrl-k to get « ctrl-k to get » Regards, -- Gregor On Fri, 2004-03-19 at 05:39, Rafael Garcia-Suarez wrote: Andy Wardley wrote in perl.perl6.language : I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Of course this information is almost completely unusable without knowing your OS, your locale, and your keyboard flavour. But thanks anyway, and I'll share mine : with vim, and with the 'digraph' option set, just type Del to get « Del to get » This is probably common knowledge as well. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Funky «vector» operator
Oh, and the ctrl-k form doesn't require you to do the :set digraph thing. Its always available. Regards, -- Gregor On Fri, 2004-03-19 at 06:16, Gregor N. Purdy wrote: For me, (vim 6.2), that is bs to get « bs to get » after doing :set digraph (list of available digraphs can be seen by :digraph) But, I find the above a bit unnerving because I've deleted the character, and then if I type a certain character next I haven't. Vim also allows ctrl-k to get « ctrl-k to get » Regards, -- Gregor On Fri, 2004-03-19 at 05:39, Rafael Garcia-Suarez wrote: Andy Wardley wrote in perl.perl6.language : I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Of course this information is almost completely unusable without knowing your OS, your locale, and your keyboard flavour. But thanks anyway, and I'll share mine : with vim, and with the 'digraph' option set, just type Del to get « Del to get » This is probably common knowledge as well. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Funky «vector» operator
Robin Berjon wrote: Specifying the OS is not enough, you need at least the keyboard layout. It would be impossible to have shortcuts involving | or \ on a French keyboard since they are respectively Alt-Shift-L and Alt-Shift-: OS X / iBook / fr-fr « Alt-è » Alt-Shit-è Good point. I tend to be a bit shortsighted on things like that. OS X / Powerbook / en_GB « Option-\ » Option-Shift-\
Re: Funky «vector» operator
Another approach would be to write a little fixup script that turns the ASCII variants into the non-ASCII variants, and then you could bind it to a function key to translate the current line. That has the advantage that you could use it on a script someone else sends you as well if you find the ASCII workarounds too visually offensive. Larry
Re: Funky «vector» operator
On 19 Mar 2004, at 16:16, Larry Wall wrote Another approach would be to write a little fixup script that turns the ASCII variants into the non-ASCII variants, and then you could bind it to a function key to translate the current line. That has the advantage that you could use it on a script someone else sends you as well if you find the ASCII workarounds too visually offensive. /lurk That would be really nice, and would go along way to counter my (probably unreasonable) fear of non-ASCII in the core language. Being able to easily switch between ASCII/non-ASCII using the Perl 6 equivalent of perltidy would be excellent. Adrian lurk
Re: Funky «vector» operator
Dear All, just for the Emacs-users among you: C-x 8 yields « and C-x 8 yields ». For the Unix/Linux users it is possible to setup or modify the keyboard layout using xmodmap. Actually there are so many combinations of OS, keyboard layouts, tools, editors and unicode encodings that this could become quite an FAQ... Btw. since it is favored that the default encoding for perl6 source code will be utf-8, it is not enough that you type something that displays as « or ». Your editor has to support utf-8 or you need to have conversion tools to and from something that your editor supports. Best regards, Karl
Re: Funky «vector» operator
On Fri, Mar 19, 2004 at 08:58:52PM +0100, Karl Brodowsky wrote: : Btw. since it is favored that the default encoding for perl6 : source code will be utf-8, it is not enough that you type something : that displays as « or ». Your editor has to support utf-8 or : you need to have conversion tools to and from something that your : editor supports. It's possible that Perl will be able to intuit your script's encoding in many cases if it decides your script is obviously illegal as Unicode. However, it's best to declare an explicit encoding declaration if you're not going to use something easily recognizable as utf-* or scsu. Larry
Some questions about operators.
I just read Synopsis 3, and I have several questions. 1) Synopsis 3 says that the difference between $x ?| $y and $x || $y is that the later always returns a Boolean. Does this mean that $x ?| $y short-circuits? 2) Do all of the xor variants have the property that chained calls return true if exactly one input parameter is true? 3) Is there an ASCII digraph for the | operator? 4) Do == and != participate in chained comparisons, so that $a == $b == $c evaluates to true if and only if all three are equal? Is $x $y $z a legal chaining? Or $x $y lt $z? 5) Would it be possible for me to create a user-defined operator that does chaining? Joe Gottman
Re: Some questions about operators.
Joe Gottman writes: 2) Do all of the xor variants have the property that chained calls return true if exactly one input parameter is true? I would imagine not. Cxor is spelled out, and by definition XOR returns parity. On the other hand, the junctive ^ (one()) is exactly one. 3) Is there an ASCII digraph for the | operator? No. Just use Czip. 4) Do == and != participate in chained comparisons, so that $a == $b == $c evaluates to true if and only if all three are equal? Yes. But not really. It evaluates true if $a == $b and $b == $c (while only evaluating $b once). This may not be the same as all three being equal if $a, $b, and $c are objects whose equality isn't transitive. Is $x $y $z a legal chaining? Or $x $y lt $z? Sure. It (rather confusingly) asks whether $y is less than both $x and $z. The latter is too, and it's equivalent to: $x +$y and ~$y lt $z 5) Would it be possible for me to create a user-defined operator that does chaining? Yes. You just have to be clever about your return values. A comparison operator could return its right argument Cbut true or Cbut false. To get them to short circuit is exactly the same problem as getting other user-defined operators to short circuit, something that's been adressed but I don't remember the answer to. Luke
RE: Some questions about operators.
-Original Message- From: Luke Palmer [mailto:[EMAIL PROTECTED] Sent: Friday, 19 March, 2004 10:06 PM To: Joe Gottman Cc: Perl6 Subject: Re: Some questions about operators. Joe Gottman writes: 2) Do all of the xor variants have the property that chained calls return true if exactly one input parameter is true? I would imagine not. Cxor is spelled out, and by definition XOR returns parity. On the other hand, the junctive ^ (one()) is exactly one. Hmmm: If infix:xor returns Scalar.boolean, there might be hope. This would involve returning something like a.or.b but a.xor.b. 3) Is there an ASCII digraph for the | operator? No. Just use Czip. Re: | vs Boggle! Who let that slip in? I kind of got the impression he was asking about e.g., ??! or some such, a la ANSI C. (In the same vein as for , etc.) But no, it's far worse: every keyboard that is capable of generating '|' is labeled incorrectly. How's that for the principle of least surprise? It's like the old Far Side cartoon showing Ed's Dingoes right next to Martha's Day Care -- trouble waiting to happen. Let's pray nobody uses ... =Austin PS: S3 appears inconsistent WRT the . operator and hyperoperation. One example uses (f,oo,bar).length, while elsewhere you have @objects.run(); Comment?
building an open source testing community
I run a mailing list for software testers called swtest-discuss (http://lists.topica.com/lists/swtest-discuss/). There are a few people there (including me) who are interested in talking about how people do testing for open source projects. I haven't yet found a community of open source testers that cuts across multiple tools/applications. If you're interested in sharing your experiences in testing open source software, please consider joining swtest-discuss, at least long enough to see if there's any interest in having an on-going forum on this topic. If you do subscribe, please either send me a private email or introduce yourself to the list so we know you're there. So far we have representatives from the Open Source Development Lab (OSDL) and the FitNesse project. I'd also like to hear from people who are testing Perl and its modules. -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/
Nesting Test::Harness
Is there a way to nest usage of Test::Harness? I have an application with a number of custom modules. I want to structure my test suite this way: myapp.t module_a.t module_b.t module_a.t foo.t bar.t module_a.t baz.t quux.t That is, I want the top-level test suite to call the module test suites, and the module suites to call their own test sets (often one *.t for each sub in the module). I want to do this because: 1) I want to be able to run either the full suite or just one module's tests. 2) I don't want to have to make changes in two places when I add a new subtest. 3) I want to tweak the flags to Devel::Cover for each module so that it only collects data for the module I'm actively testing and doesn't get incidental coverage for things it depends on. Test::Harness::runtests() doesn't seem happy about being (indirectly) nested. When I get it to work at all (path/cwd issues) I get results like this: Module_A..skipped all skipped: no reason given Module_Bskipped all skipped: no reason given All tests successful, 2 tests skipped. Files=2, Tests=0, 10 wallclock secs (0.00 cusr + 0.00 csys = 0.00 CPU) Does anyone know of a way to get Test::Harness to DWIM here? Or failing that, does anyone have a suggestion for an alternate approach? -mjc
Re: [Patch] fix tests failing due to recent PerlNum modifications
Jens Rieks [EMAIL PROTECTED] wrote: Hi, new P0, .PerlNum set P0, 0.0 print P0 should IMO print 0.00 rather than 0, because its a floating point number and not an integer. What are the arguments for printing 0? PerlNums evaluating to whole integers (except -0.0 now) are morphed to PerlInts. jens leo
Re: Optimizations for Objects
On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: What's the usage of Continuations from HLLs point of view? Can we get
: some hints, what is intended?
From the standpoint of Perl 6, I hope to hide continuations far, far
away in a galaxy long ago. No wait, wrong movie...
We can certainly make it the default that a routine is not going to
do anything fancy with continuations unless it is explicitly declared
to allow it. As to what that declaration should be, I have no idea.
Probably just a trait that says, is continuationalizableish or
some such.
: I'd like to have, if possible a clear indication: that's a plain
: function or method call and this is not. I think the possible speedup is
: worth the effort.
I have no problem with plain being the default. I suppose you could
declare it explicitly if you like:
sub foo () is plain {...}
Then obviously the other kind would be:
sub bar () is peanut {...}
Hmm, actually, smooth and nutty might be more accurate.
Larry
Re: Oops, here's the full parrotunit
parrotunit.tar.gz Description: Binary data
Re: Optimizations for Objects
Larry Wall wrote: We can certainly make it the default that a routine is not going to do anything fancy with continuations unless it is explicitly declared to allow it. As to what that declaration should be, I have no idea. Probably just a trait that says, is continuationalizableish or some such. is mindwarping? does the_time_warp_again? The problem, in any case, is similar to throws in Java: if any of your children are marked, so shall you be, unto the Nth generation. (Or, at least, this is how I understand it.) -=- James Mastros
Re: Oops, here's the full parrotunit
Piers Cawley [EMAIL PROTECTED] wrote: I knew I forgot something in my last post... Still: EÄttätschmentMissin leo
Re: Configure.pl and the history of the world
I began a little piece of this ages ago- attempting to translate the parts that identify the platform ($^O, essentially) from metaconfig to something we could put into Configure.pl. Even that relatively simple chore wasn't too easy. I should still have the work-in-progress code for that around here somewhere. --Josh At 19:47 on 03/16/2004 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Hey folks. Now that we're integrating in with perl 5, a few things are becoming really obvious. First, we really need to work on the embedding interface. Memory handling, signals, and I/O are the biggies there. Working on that, though not fast enough for Arthur. Second, we're running over the same problems in system configuration that perl (and python, and ruby, for that matter) have already run across. Moreover, we're making the same decisions, only... differently. This is silly both because we're re-inventing the wheel and we're making the wheel with metric nuts instead of english. We could go dig through perl's configure every time we add a new environment probe, but that'll get really old really quick. Instead, what I'd like is for someone (Oh, Brent... :) to go through perl's configure and dig out the tests in it, as well as the defaults that it has and just get all the config variables in once and for all. While some of what's in there we don't have to deal with (joys of C89 as a minimum requirement) there's a lot of hard-won platform knowledge in there and ignoring it's foolish. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Configure.pl and the history of the world
At 10:22 on 03/18/2004 EST, Andrew Dougherty [EMAIL PROTECTED] wrote: 5. You probably don't need to support Eunice anymore. I think i'm not the only one who would be deeply upset if I ceased to be congratulated for not running Eunice though. --Josh
Re: Configure.pl and the history of the world
Josh Wilmes wrote: At 10:22 on 03/18/2004 EST, Andrew Dougherty [EMAIL PROTECTED] wrote: 5. You probably don't need to support Eunice anymore. I think i'm not the only one who would be deeply upset if I ceased to be congratulated for not running Eunice though. Ah, but since we'll have One Configure To Rule Them All, we can replace it with something more modern: Congratulations, you aren't running Windows. (I expect the OS probe step to be noisy, because we don't know what the OS is yet, so we'll probably be spewing out error messages left and right as we stumble about without knowing if we can even do Unix-style I/O redirection.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Optimizations for Objects
Larry Wall [EMAIL PROTECTED] wrote:
On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: I'd like to have, if possible a clear indication: that's a plain
: function or method call and this is not. I think the possible speedup is
: worth the effort.
I have no problem with plain being the default. I suppose you could
declare it explicitly if you like:
sub foo () is plain {...}
Then obviously the other kind would be:
sub bar () is peanut {...}
There is of course no need to declare the default, which will be very
likely beyond 99%. I won't discuss P6 syntax here, which could lead to
sub bar() will reuse_P1 { ... }
Piers' statement was related to solving the halting problem, which isn't
really positive. I don't throw or catch pies, but CPS returns are
currently the major performance loss Parrto has.
Larry
leo
Testing XS modules on Ponie
Arthur Bergman [EMAIL PROTECTED] writes: This is Ponie, development release 2 And, isn't sanity really just a one-trick ponie anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit. -- the tick Welcome to this second development release of ponie, the mix of perl5 and parrot. Ponie embeds a parrot interpreter inside perl5 and hands off tasks to it, the goal of the project is to hand of all data and bytecode handling to parrot. With this release all internal macros that poke at perl data types are converted to be real C functions and to check if they are dealing with traditional perl data types or PMC (Parrot data types) data. Perl lvalues, arrays and hashes are also hidden inside PMCs but still access their core data using traditional macros. The goal and purpose of this release is to make sure this approach keeps on working with the XS modules available on CPAN and to let people test with their own source code. No changes where made to any of the core XS modules. So ponie-2 compiles and passes all its tests for me. So how do I see if it can handle the XS module from hell - Tk ?
Re: Some questions about operators.
Austin Hastings writes:
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: Friday, 19 March, 2004 10:06 PM
To: Joe Gottman
Cc: Perl6
Subject: Re: Some questions about operators.
Joe Gottman writes:
2) Do all of the xor variants have the property that
chained calls return true if exactly one input
parameter is true?
I would imagine not. Cxor is spelled out, and by
definition XOR returns parity. On the other hand,
the junctive ^ (one()) is exactly one.
Hmmm: If infix:xor returns Scalar.boolean, there might be hope. This
would involve returning something like a.or.b but a.xor.b.
I don't know what you're hoping for when you say 'hope.'
3) Is there an ASCII digraph for the | operator?
No. Just use Czip.
Re: | vs
Boggle! Who let that slip in?
I kind of got the impression he was asking about e.g., ??! or some
such, a la ANSI C. (In the same vein as for , etc.)
But no, it's far worse: every keyboard that is capable of generating
'|' is labeled incorrectly. How's that for the principle of least
surprise?
I've never been too fond of the (lack of) visual distinction between |
and . They're just too similar. I'd much rather see something like
U+299A VERTICAL ZIGZAG LINE (). But alas, not in latin-1 (not to
mention my terminal's inability to render that character, but that
wasn't a design constraint last time I checked -).
But context serves us humans well here. Very infrequently will you see:
for @a | @b - $a, $b {...}
My head hurts just thinking about what that actually does. Among other
things, it should probably issue a warning saying did you mean ?
It's like the old Far Side cartoon showing Ed's Dingoes right next
to Martha's Day Care -- trouble waiting to happen. Let's pray nobody
uses ...
=Austin
PS:
S3 appears inconsistent WRT the . operator and hyperoperation. One
example uses (f,oo,bar).length, while elsewhere you have
@objects.run();
Oops. The latter is correct.
Luke
