Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply and context_auto_attrs merges | find out what's up with the slice opcode | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 1 November 2009.
dalek TT #1104 closed by jkeenan++: Correct erroneous reference in docs to Number PMC 00:08
00:09 mikehh joined
darbelo realizes that performing a 'net install' was a bad idea. 00:10
Debian mirror slooooooooow.
00:21 Whiteknight joined
dukeleto parrot github mirror is synced again! 00:21
darbelo dukeleto: You should document the procedure and add backup commiters there. Give it a higher bus number. 00:22
dukeleto darbelo: it is a script :) the machine it was running on died 00:23
darbelo: i have the script in my github util repo
darbelo: github.com/leto/Util/blob/master/bi...ate_parrot 00:24
darbelo Ok, as long as the bus doesn't hit both you and github we're safe.
;)
dukeleto darbelo: don't worry, i back up to my gitweb as well :)
darbelo Good enough for me. 00:25
kesselhaus couldn't parrot and all the languages look for parrot-executable in ['.',PATH] + argv[0], and then if it's bindir is found use the bin + '../' as base to look for the rest ofthe rumtime stuff? 00:41
chromatic Wouldn't the +argv[0] open a world of symlink attacks? 00:44
NotFound kesselhaus: we don't expect that most users have lots of parrot instalations. 00:48
kesselhaus the thing is, i can't execute parrot installed on C:\\parrot-1.7.0, when i am in an directory on drive d: 00:49
NotFound kesselhaus: Do you have the parrot bin dir in your PATH ? 00:50
kesselhaus D:\\temp>C:\\parrot-1.7.0\\bin\\perl6 --help 00:51
== SORRY! ==
Unable to find Perl 6 dynops and dynpmcs library.
If you want to run Rakudo outside of the build directory, please make install.
D:\\temp>parrot_nqp --help 00:52
"load_bytecode" couldn't find file 'PGE.pbc'
current instr.: 'parrot;NQP;Compiler;__onload' pc -1 ((unknown file):-1)
called from Sub 'parrot;NQP;Compiler;main' pc 44 (nqp.pir:19)
so neither way works... it just doesn't find the base dir C:\\parrot-1.7.0 .. how would i set that? 00:53
C:\\Users\\kesselhaus>perl6 --help 00:54
perl6 ... Usage: perl6 [switches] [--] [programfile] [arguments]
see? being on drive C: --> no problem, being on drive D: --> major problem 00:55
that's why i suggested, that parrot and the languages should somehow bring the base dir into the environment, which can be somehow picked up by all parrot tools, e.g. check envvar PARROT_HOME, if not exist, try find parrot in PATH, if exist, set PARROT_HOME internally to one dir up, if not in path, use argv[0], maybe there is a whole path... 00:57
japhb pmichaud, what am I doing wrong here: $ nqp -e 'pir::load_bytecode("P6Regex.pbc"); my $p6regex := Q:PIR { %r = compreg "Regex::P6Regex" }; my $regex := $p6regex.compile("a*"); my $cursor := Regex::Cursor.new; my $match := $cursor.parse("dbcaaaa", $regex); say($match.dump_str("mob", " ", ""));' 00:59
mob: < @ 0> 0
If I change the target string to just "aaaa", it matches.
NotFound kesselhaus: unfortunately we have very few developpers working habitually on windows, so that type of things are poorly tested. 01:00
japhb pmichaud, it's like there's an implicit '^' at the start of the regex
kid51 mikehh ping 01:02
japhb pmichaud, sorry, the above should have had a regex of "a+" ... too many different attempts, sigh 01:09
01:10 hercynium joined
japhb pmichaud, AH! Nevermind, I found the proper incantation. 01:13
.oO( One monkey, hitting keys randomly ....)
dukeleto thank $deity for beer and fridays 01:22
Tene japhb: am I correct in remembering that plumage can install rakudo?
dukeleto Tene: yes
japhb Tene: yes, in fact that's how I always install rakudo. :-) 01:27
pmichaud back again 01:38
Coke yawns
japhb pmichaud, halp! I can't figure out how to get the next match from a cursor. (I can get the first match fine, but I can't figure out the incantation to get the *next* one in the same string.) 01:46
in NQP-rx, of course
pmichaud well, you normally don't have a cursor, you have a match.
there might not be a way to get "next match" yet. 01:47
japhb Oh. ow.
pmichaud put it on the list, I can add it soon
(as in the next 24 hrs)
japhb adding ...
dukeleto pmichaud: ping!
pmichaud dukeleto: pong
japhb now has a permanent browser tab open on the Plumage Requests wiki page
dukeleto pmichaud: have you had a chance to make something like tools/dev/mk_language_shell.pl for nqp-rx ? 01:48
japhb Also, I've taken to using the NQP-rx test suite to figure out what is implemented and what isn't. I didn't see tests for attribute declaration in there ....
dukeleto pmichaud: also, i was having trouble compiling nqp-rx recently
pmichaud dukeleto: you had to have had some old sources lying around somewhere 01:49
dukeleto pmichaud: do you have a recommended commit for plumage/HLL authors?
pmichaud dukeleto: master is working for me, latest commit. If it's not working for you, let me know.
(and I checked it from a fresh clone)
japhb: yes, attribute declaration is implemented and (I think) tested. checking
dukeleto pmichaud: i have the examples you gave me, is that what you are asking about? 01:50
japhb dukeleto, I've been reinstalling nqp-rx regularly using Plumage, which implicitly pulls from master, so I ride the blead.
dukeleto pmichaud: i am going to try the latest nqp-rx master now
pmichaud japhb: you're correct, no tests for attributes yet
but attributes are implemented
dukeleto japhb: which os/platform and parrot configure flags?
japhb Ha! I'm not as blind as I appear!
pmichaud class XYZ { has $!abc; } # should work 01:51
japhb Debian/x86, --optimize --jitcapable=0 --prefix=/usr/local/parrot
pmichaud, excellent, thank you
dukeleto japhb: are you using an installed parrot with nqp-rx or using --gen-parrot ?
japhb: or do you hate -gen-parrot ;) ? 01:52
japhb I never use --gen-parrot any more. It is the anti-Plumage. It must die.
:-)
dukeleto japhb: is it supported? are people going to use it?
pmichaud fwiw, last I chatted with allison we're likely to include nqp as part of the parrot core
japhb I consider --gen-parrot FAIL to be a *feature*. ;-)
dukeleto we need to either kill gen-parrot, or make it work
japhb pmichaud, I saw that. I'm VERY happy to see sanity prevailed.
I vote kill. We don't need it.
OK, maybe I'm being a bit harsh 01:53
pmichaud plumage probably doesn't need --gen-parrot. But other environments need it.
dukeleto pmichaud: 'make test' gives me: $ make test
prove -r --exec ./nqp t/nqp
Unknown option: exec
pmichaud it depends on what you expect the users' installation model to be
japhb I can see the use for people to keep their playground in one place. But I'd like to just incorporate that little bit of magic into Plumage. 01:54
pmichaud dukeleto: I'm guessing you have an older version of 'prove'
dukeleto pmichaud: prove v2.64, using Test::Harness v3.16 and Perl v5.10.0
pmichaud Any profiling gurus around?
pmichaud.com/sandbox/snapshot4.png
dukeleto pmichaud: what is the min version required? shouldn't that be checked at configure-time ?
japhb All kidding aside, I'd really like to see all other installation methods for Parrot projects go away, and Plumage be considered canonical. Only then can we get people eating dog food enough to really work out all the problems.
pmichaud japhb: that doesn't always work, though. Will plumage be able to follow Parrot head constantly? 01:55
japhb The only reason I haven't marched down the field with that flag yet is that I spent a while being sick, and couldn't respond to people needing help with Plumage.
pmichaud if Plumage only targets monthly releases, that absolutely won't work for developers
japhb pmichaud, I'm not sure I understand your question.
For now, Plumage is making use of the newest stuff nqp-rx is adding, so I have to ride HEAD on both. 01:56
pmichaud you're suggesting that, say, Rakudo go through plumage in order to obtain Parrot, yes?
japhb pmichaud, no. I'm saying people should install Parrot, then Plumage, then use that to build and install Rakudo. Only thing missing there is 01:57
pmichaud japhb: that's not the sequence I want people to use
how will people know what version of Parrot to install?
japhb the 'this' pronoun to build and install the user's working directory, rather than in the temp space.
Tene why don't we just make a tarball of all released versions of Parrot? 01:58
and install them side-by-side?
pmichaud rakudo development doesn't target released parrots
japhb I've designed (but been too sick to implement yet -- soon though) the ability to say 'plumage upgrade all' and have it pull down the projects, find the minimal parrot version that works, rebuild and reinstall parrot, and then reinstall all projects on top of it. 01:59
pmichaud the longest that rakudo has ever been able to use a released parrot is 5 days
Tene Yes, and that's the only thing wrong with my idea. ;)
pmichaud japhb: what if the minimal version of parrot is too new for the current version of parrot?
japhb pmichaud, I know that. :-)
pmichaud sorry, for the current version of rakudo?
japhb pmichaud, you're asking if for example partcl needs a newer version of parrot than Rakudo can handle? 02:00
pmichaud japhb: yes
but beyond that
purl rumour has it beyond that is just groovy :)
japhb pmichaud, that is a valid point. let me think for a minute on it.
pmichaud I don't want to tell people that in order to develop for rakudo they have to first go grab parrot, install it, grab plumage, install it, and then start with rakudo
I'd much prefer to say "grab rakudo, run Configure.pl with the --gen-parrot (or --gen-plumage) option, and go." 02:01
dukeleto pmichaud++ # i like --gen-plumage
pmichaud now then, for an end-user installation, plumage is probably the way to go
japhb Plumage will be snapshotted into Parrot in the same way as nqp-rx is.
Tene for an end-user installation, distro packages are even nicer.
japhb So only "install Parrot, plumage install rakudo"
pmichaud personally I think that "plumage install rakudo" should be targeting released versions of Rakudo, not head 02:02
japhb Tene: yes, and several people have demanded that Plumage be able to help distro packagers make binary packages. So it will, eventually. :-)
pmichaud japhb: anyway, if the tools get sophisticated enough then eventually we might recommend the plumage approach. but for rakudo development, --gen-parrot is currently far better. 02:03
japhb pmichaud, I've been thinking about that, actually. I want people to be able to (in fact, I think according to the design of Perl 6, we *have to*) be able to install multiple versions of any Parrot project. And I'm running up against the problem that parrot's library handling structure really doesn't like to do that, especially for HLLs. 02:04
pmichaud japhb: I agree, it's a big problem. :)
japhb pmichaud, I totally understand that the short term reality is not representative of the long term goal. :-)
pmichaud anyway
japhb In all that, Plumage Requests was updated with one new item. :-) 02:06
pmichaud okay
japhb And thanks for making attribute declarations work, I hopefully can start doing an OO refactor of Plumage soon.
02:06 joeri left
pmichaud they were already working earlier in the week :) 02:06
actually, last week, come to think of it
but we definitely need a test
japhb stashes his attempts at switching to P6Regex into a branch, and tries starting the OO work instead. 02:17
dalek TT #1170 closed by jkeenan++: /docs/book/pir/ch04_variables.pod: Iterator does not work as documented 02:18
02:19 eiro joined
japhb pmichaud, does nqp-rx have file-scoped class declarations? 02:30
pmichaud depends on what you mean by "file-scoped"
japhb class Foo; as opposed to class Foo { } 02:35
pmichaud I don't know if it has that yet
checking
looks like "yes"
japhb Yay 02:36
pmichaud++ # yet again
pmichaud afk for a bit
japhb keeps writing 'had $!foo;' instead of 'has $!foo;' 02:37
My classes are prone to losing themselves.
02:40 eternaleye joined 02:53 elmex joined
japhb pmichaud, Am I correct in assuming that only private attributes exist in NQP ('has $!foo;' only)? 03:14
er nqp-rx
03:21 kthakore joined 03:35 janus joined
pmichaud correct, only private attributes 03:42
I'm not sure how to handle public ones, since what makes an attribute public in p6 is that there's an accessor method generated
We could generate accessor methods for readonly public attributes, though 03:47
that's probably worthwhile
I have no good idea how to make "has $.foo is rw" work though
(because there's no way to lvalue an attribute)
japhb nod 03:48
pmichaud but having $.foo automatically generate a 'foo' method is probably worthwhile
eternaleye pmichaud: my $ret := $!var; return( $ret ); ?
pmichaud eternaleye: that gets you read only access, yes
eternaleye pmichaud: I would have thought the := would bind as 'is ref', allowing writes? 03:49
pmichaud yes, but what is a "write" ?
eternaleye read/write
pmichaud right
eternaleye left!
pmichaud so, suppose you have $ret. How do you write to it such that it changes $!var ?
japhb On a separate note ... according to the P6protoobject docs, it's possible to override the proto object's .new() by just declaring a method new in the class itself. But what do I need to put in that method to instantiate the object?
pmichaud (nqp code, please)
japhb: I need to come up with a good way to do that, yes.
japhb: I'm thinking it will be worthwhile to have a CREATE method to do that 03:50
or... something
eternaleye Well, they're bound to the same container, so $obj.var = "foo"; since that ends up as '$ret := $!var; $ret = "foo"'
pmichaud eternaleye: nqp doesn't have assignment, or containers
(because parrot doesn't have them) 03:51
eternaleye Ah, thinko on my part
japhb pmichaud, I'd be willing to make the first half of my new method be inline PIR at this point. I just don't know what PIR to use ... because the only example I have is the proto object new method, and that's written from the perspective of a completely different point in the meta space. 03:52
eternaleye In that case, the only way I can think of would be to introduce a layer of abstraction. Have all 'names' be links to a 'supername', and do something like $ret.ROOTOBJ := "foo" 03:53
pmichaud eternaleye: the point is that there's no real concept of a "supername" in Parrot either
eternaleye and since $ret and $!var both point to the smae 'supername', both now point to "foo"
pmichaud NQP simply layers a Perl 6 syntax on Parrot semantics
if Parrot doesn't have it, then NQP either generates code to do it, or does without
and NQP isn't fond of creating its own custom data types 03:54
eternaleye Hm
pmichaud In rakudo we're able to solve the problem by creating container types 03:55
but that gets kind of ugly. In particular, arrays often end up being arrays of container PMCs, which then have to point to the value PMC
so we end up with two PMCs for every element 03:56
eternaleye pmichaud: In that case, make a slight syntax difference: $obj.var => returns $!var; $obj.var($val) => sets $!var to $val and returns $val
pmichaud (we get around this by using references)
well, in nqp private attributes will probably not be truly private 03:57
eternaleye There are already several syntax differences (say(...) vs say ...), so this wouldn't be a big deal
pmichaud there's a bit difference there
say(...) is valid p6 syntax
eternaleye Mmm, true
pmichaud nqp uses a subset of p6 syntax. It tries not to introduce things that fall outside of p6 syntax. 03:58
03:58 plobsing joined
pmichaud the reason I'm (as yet) able to get say ... to work is that there's not a good way to distinguish bareword type names from bareword listops 03:58
we might introduce the notion that barewords beginning with uppercase are types, while barewords beginning with lowercase are listops.... but I'm not sure that works out well in the long run. 03:59
eternaleye pmichaud: Going slightly off topic (back to your comment about 2 PMCs per object), would there be any way to default to not having them, and then 'promote' (similar to autoboxing) when a request that requires them is made? 04:00
pmichaud eternaleye: we pretty much do this in rakudo already
eternaleye Okay
pmichaud but sometimes it can't be helped
for the basic value types (Int, Str, Num) we're able to avoid the extra PMC reference
but for everything else we basically end up with a reference PMC 04:01
eternaleye pmichaud++ # teaching me neat stuff
japhb raises his hand and looks anxious to be called on 04:02
pmichaud japhb: ...yes? ;-) 04:03
japhb I could really use even some example inline PIR of how to create an object from within an NQP class's new() method. I want my new() to be able to take an argument, and I can't do that with the default protoobject new 04:04
pmichaud oh, sorry, thought I answered that 04:05
I'd suggest
pir::new(<Some Class>) # create an instance of Some::Class
or you can do it with
Q:PIR{ %r = new ['Some';'Class'] }
japhb Wait, that's all? I don't have to do anything to hook it up to the metamodel? 04:06
pmichaud p6object takes care of that automatically
the hooks into the p6object metamodel are based on an object's (parrot) class
japhb Oh, cool. I was thinking I had to do a whole bunch of magic in new(), and I was at a loss as to what to do.
pmichaud as long as the class itself was created by or registered with P6object (and all NQP-created classes are), then P6object gets the rest 04:07
japhb Oh, what a relief.
purl D-E-A-T-H
japhb goes to actually try it
pmichaud here's the default .new method, fwiw
.sub 'new' :method .local pmc parrotclass $P0 = self.'HOW'() ## for speed we access the 'parrotclass' attribute directly here parrotclass = getattribute $P0, 'parrotclass' $P1 = new parrotclass .return ($P1) 04:08
.end
pasto
oops
(nopasting)
nopaste "pmichaud" at 72.181.176.220 pasted "P6object's default .new method" (8 lines) at nopaste.snit.ch/18594
pmichaud it just gets the parrotclass of the invocant and then creates a new object of the same type 04:09
japhb Can 'self' be assigned to? 04:10
pmichaud ...assigned?
japhb bound, Mr. Pedantic Boy
;-)
pmichaud sure, it's just a lexical
of course, inside of .new it starts out as the invocant
but you can rebind it to a different object
I'm not sure that's valid Perl 6, but... :) 04:11
while we try hard to always be valid Perl 6, we do sometimes come up short.
japhb OK, so in NQP, I can do: method new($name) { my $how := self.HOW; my $class = pir::getattribute($how, 'parrotclass'); self := $class.new; $!name = $name; } 04:12
er, last = should be := of course
pmichaud I don't think you can do self := $class.new though
japhb er, and the first as well
pmichaud I don't think parrot classes have a 'new' method
japhb bah
pmichaud you could do pir::new($class) though 04:13
japhb self := pir::new($class) then?
pmichaud yeah
japhb Ok, lemme try that
pmichaud I'd even shorten it to
pir::getattribute(self.HOW, 'parrotclass')
or for real fun
pir:new( pir::getattribute( self.HOW, 'parrotclass' ) )
which avoids binding the lexicals 04:14
...but I think it's probably worthwhile for me to just add a BUILD method to p6object
then it can just be self = self.BUILD; $!name := $name 04:15
or something like that
nopaste "japhb" at 76.191.190.8 pasted "Hmmm, new() fails" (7 lines) at nopaste.snit.ch/18595
pmichaud huh 04:16
getattribute_PPs then
er
getattribute__PPs
japhb Do I have to do the type specifier thing on the pir::getattribute?
ah, right
pmichaud shouldn't have to, but apparently do
checking
looks like yes, needs the signature
I'll add it to PAST so that a plain getattribute works in the future 04:17
(after I get through figuring out why POST -> PIR generation is now taking an incredibly huge amount of time.... it didn't used to)
....did the pcc refactor significantly slow down pccmethod calls?
as in, by at least an order of magnitude or more? 04:18
japhb Hmmm, I got the same error with pir::new now, so I tried pir::new__Ps and pir::new__PP, and neither one worked (both get Null PMC access in find_method() )
pmichaud it would be __PP
japhb yeah, I tried both just in case my logic was wrong. :-) 04:19
afk for a sec
pmichaud oh, I'm missing a colon in the version I gave above
pir::new instead of pir:new
maybe that's it.
japhb nope, I had it right in my code 04:20
pmichaud hmmm
I'll have to look at it a bit later
I suggest the Q:PIR for now
(I _know_ that works :-)
japhb really wishes the 'Null PMC access in find_method()' error actually said which method it was trying to find .... 04:21
pmichaud yeah, me too
that might be fixable
although I suspect if it was fixable, we would've already fixed it 04:22
japhb nod
dukeleto 'ello
dukeleto attempts to start backlogging
japhb o/ 04:23
pmichaud oh, I think it can be fixed 04:24
pcc refactor landed after the oct release, yes? 04:26
japhb yes 04:27
pmichaud okay 04:28
pmichaud benchmarks the october release
japhb Is there a way to put a newline into Q:PIR{} strings? \\n doesn't seem to work. Without it, oneliners are kinda painful? 04:29
pmichaud ...one liners?
(short answer, no)
japhb sigh
japhb is a big fan of -e
OK, time to put this in a probe script 04:30
pmichaud if Q:PIR{...} honored \\n as a newline, then Q:PIR{ print "foo\\nbar" }; would dtwt
japhb Not if it also handled \\\\
which I guess with shell quoting would become \\\\\\\\, sigh 04:31
plobsing what about QQ:PIR?
pmichaud no, it would want to be qq:PIR { ... }
but then $'s would get interpolated
so really what you want is qb:PIR { ... }
or q:b:PIR { ... } 04:32
plobsing do you plan on adding such a construct? 04:34
pmichaud hadn't planned on it, but could be talked into it :) 04:35
hmmm. my slowdown doesn't appear to be due to PCCMETHOD 04:37
dukeleto pmichaud: do you know the min version of prove that nqp-rx's test suite requires? 04:45
pmichaud dukeleto: no 04:52
dukeleto pmichaud: it is > -test] Error 1 04:56
(kadath)(~/git/nqp-rx master )$ prove --version
prove oops
sorry about the paste bomb 04:57
i meant to say "it is > v2.64"
nopaste "japhb" at 76.191.190.8 pasted "Works! But how to simplify ...?" (24 lines) at nopaste.snit.ch/18596
pmichaud dukeleto: looks like you need something after 2.64 though 04:58
dukeleto japhb: that looks pretty tricked out
pmichaud dukeleto: prove 2.64 appears to have come out in Oct 2006. The --exec option was added in August 2007. 04:59
japhb pmichaud, can you see a way to improve that method new()? And why do I need to restate '$!name;' at the end of method name()? It appears as if the binding statement cannot work with implict return
dukeleto, :-)
dukeleto pmichaud: wow, i am behind the times 05:00
pmichaud japhb: I'm not sure why the need for the extra $!name 05:04
I suppose that binding might not be returning the lvalue side
(but it should...)
japhb Is that likely to be a difficult fix? 05:05
pmichaud only if it ends up requiring a deprecation
otherwise, no
pmichaud checks
yeah, looks like setattribute isn't returning a value 05:06
looking further...
hmmmmm 05:07
given setattribute $P0, 'attr', $P1 05:08
what should be the "value" of that bind?
$P0, or $P1 ? 05:09
I can argue it both ways.
eternaleye pmichaud: What's the argument ordering for a simple binding? I'd say they should be consistent. 05:10
pmichaud in this case, it's
japhb Well, the high level versions would be 'return($!foo := $bar)' and '$!foo := $bar; return(self)', so I argue $P1
pmichaud yeah, in this case it's pretty clear it should be $P1
we might have a deprecation issue here, then. 05:11
japhb :-( 05:12
pmichaud for some reason setattribute in PAST::Compiler is set to return $P0
may have been to make it easy to set multiple attributes on an object
setprop does the same
japhb chaining
purl i heard chaining was Catalyst::DispatchType::Chained or www.catalystframework.org/calendar/2006/10 or the bizomb
pmichaud yeah 05:13
but that's a :pirop, not bind, so....
checking
japhb Yeah, I can see how that might have been useful for some HLLs.
Come to think of it, the JavaScript library jQuery is really, REALLY into chaining. If it even vaguely makes sense to do so, it's chainable. Even when it's a bit of a stretch. 05:18
In any case, NQP != jQuery. :-)
pmichaud japhb: aha, looks like a pct bug
japhb: which means it can be fixed :)
japhb yay! 05:19
pmichaud I'll do that now.
japhb Excellent, thank you.
pmichaud testing now 05:20
japhb pmichaud, any luck? 05:39
ENOPMICHAUD 05:43
Ah well, I think I'll go eat some ice cream then. :-)
pmichaud r42317 05:45
dukeleto where would a good place be in the parrot repo to put notes about the RTEMS port? 05:46
the wiki is pissing me off
dalek rrot: r42317 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
[pct]: binding an attribute node should return the bound value (japhb++)
 05:47
japhb OK, while my parrot rebuilds ... any thoughts on improving that method new() in my test program? 05:54
pmichaud looked fine to me
japhb Just felt a little over-heavy ... ah well. 05:58
r42137 confirmed working for me, thanks! 06:05
pmichaud++
07:00 workbench joined
dalek rrot-plumage: 0e62a77 | japhb++ | :
[PROBES] Add class.nqp, testing accessor and custom new() creation
 07:08
japhb pmichaud, CREATE added to Classes section of wiki.github.com/perl6/nqp-rx/plumage-requests 07:11
nopaste "NotFound" at 213.96.228.50 pasted "Do you want to find a method?" (7 lines) at nopaste.snit.ch/18597
NotFound Is this that you were talking about?
Just five lines of code :) 07:12
japhb NotFound, who are you talking to? 07:13
NotFound [05:21] * japhb really wishes the 'Null PMC access in find_method()' error actually said which method it was trying to find ....
japhb Oh, yes, actually! 07:14
Thank you!
is that committed?
NotFound I'm testing it
Pass tests, going to commit. 07:15
japhb NotFound++ 07:16
NotFound r42318 07:18
dalek rrot: r42318 | NotFound++ | trunk/src/pmc/null.pmc:
show the method name in 'Null PMC access in find_method' messages
 07:19
08:16 iblechbot joined 08:34 fperrad joined 09:00 bacek joined
bacek o hai 09:00
seen pmichaud 09:01
purl pmichaud was last seen on #parrot 3 hours, 6 minutes and 41 seconds ago, saying: looked fine to me
NotFound Can someone give me review of this page? code.google.com/p/winxed/wiki/HowToInstall 09:03
09:20 chromatic joined
dalek rrot: r42319 | bacek++ | branches/pmc_headers_move:
Branch for moving generated pmc_foo.h headers in include/pmc
 09:23
rrot: r42320 | bacek++ | branches/pmc_headers_move (55 files):
Generate pmc_foo.h files inside include/pmc instead of src.

pmc_foo.h files for core and dynpmc. 2. Change all #include "../src/pmc/pmc_foo.h" to just #include
  "pmc/pmc_foo.h"
3. Change dependencies in root.in and dynpmc.in This bring build-tree closer to installed parrot and allows to use consistent #include "pmc/pmc_foo.h" across codebase.		 09:27
rrot: r42321 | bacek++ | branches/pmc_headers_move/include/pmc (2 files):
Add dummy file inside include/pmc to keep directory from being removed.
lscript: b92879a | fperrad++ | src/pmc/wmls (4 files):
modernize API
lscript: 85f1ad5 | fperrad++ | (8 files):
convert Configure to PIR (from Perl)
purl I don't know how to convert Configure to PIR (from Perl).
bacek msg pmichaud LexPad.get_iter is (partially) implemented. DynLaxPad is little bit more tricky. 10:01
purl Message for pmichaud stored.
dalek rrot: r42322 | bacek++ | trunk (2 files):
[pmc] Implement LexPad.get_iter
lscript: 2000d2c | fperrad++ | (41 files):
reorg tree
 10:03
lscript: db3475e | fperrad++ | (2 files):
chmod +x
 10:09
lscript: 43328b9 | fperrad++ | (6 files):
update PMC tests,

   .const 'WmlsType' K = 'from string'		 11:20
lscript: f8c4443 | fperrad++ | Makefile.in:
remove PROVE
lscript: 4d8d4d8 | fperrad++ | dynext/pmc/wmls (4 files):
[codingstd] fix line length
lscript: 3b24ba6 | fperrad++ | doc/ (2 files):
update doc :

various paths
lscript: db914b9 | fperrad++ | Makefile.in:
clean up
purl clean up is a breeze
11:32 joeri joined 12:09 payload joined
dalek TT #1217 created by bubaflub++: [PATCH] t/dynpmc/foo.t converted to PIR 12:44
TT #1218 created by bubaflub++: [PATCH] t/dynpmc/foo2.t converted to PIR 12:48
12:49 Whiteknight joined 12:54 mokurai left 13:23 kj joined
kj Coke: ping 13:39
dalek TT #1219 created by kjs++: Parrot's default namespaces should be fully typed 13:51
a: 00bc9aa | fperrad++ | (13 files):
Since r42279, VTABLE instantiate_str is gone.

   .const 'LuaType' K = 'init_from_string'		 13:52
Whiteknight purl msg desertm4x there are a few parrot-linear-algebra test failures after your last commit. I'll try to do some debugging to see what I can find. Most of your changes look very nice 13:54
purl Message for desertm4x stored.
dalek rrot: r42323 | kjs++ | trunk/src/global.c:
[src] update reference from RT ticket to TT ticket nr.
 13:57
rrot: r42324 | kjs++ | trunk/src/global.c:
[src] update reference from RT ticket to TT ticket nr.
 14:00
TT #1220 created by kjs++: Stop depending upon typed namespaces in internal_ns_keyed() 14:01
TT #1221 created by kjs++: Match HLL of enclosing namespace in internal_ns_keyed()?
rrot: r42325 | kjs++ | trunk/src/global.c:
[src] update reference from RT ticket to TT ticket nr.
 14:04
TT #1222 created by kjs++: Use the untyped interface in Parrot_find_global_n()
rrot: r42326 | kjs++ | trunk/src/global.c:
[src] update reference from RT ticket to TT ticket nr.
 14:07
rrot: r42327 | kjs++ | trunk/src/global.c:
[src] update reference from RT ticket to TT ticket nr.
rrot: r42328 | kjs++ | trunk/src/global.c:
[src] update reference from RT ticket to TT ticket nr.
 14:11
TT #1223 created by kjs++: Parrot_find_name_op() should walk up the scopes
TT #1224 created by kjs++: Fix temporary hack for cache invalidation; should be a namespace function; ... 14:15
TT #1225 created by kjs++: Method cache invalidation should be a namespace function 14:18
rrot: r42329 | kjs++ | trunk/src/global.c:
[src] update reference from RT ticket to TT ticket nr + add a ticket reference for a TEMPORARY HACK note.
 14:21
rrot: r42330 | kjs++ | trunk/t/compilers/json/to_parrot.t:
[t] update RT ticket no. to TT ticket no.
 14:25
TT #1226 created by kjs++: Increase code coverage of json
Whiteknight purl msg desertm4x nevermind, I figured it out. Small typo in the INDEX_XY_ROWMAJOR macro. Resolved now. Everything is working normally 14:41
purl Message for desertm4x stored.
dalek rrot-linear-algebra: ddc652b | Whiteknight++ | src/pmc/pla_matrix_types.h:
fix a small typo that was breaking some tests
 14:46
rrot: r42331 | mikehh++ | trunk/src/global.c:
fix codetest failure - trailing space
 14:47
a: 171cc98 | fperrad++ | (43 files):
reorg tree (non core libraries)
 14:58
a: a28bbc6 | fperrad++ | (30 files):
reorg tree (PMC)
15:05 payload joined 15:06 nbrown joined 15:17 nbrown joined 15:21 masak joined 15:24 Psyche^ joined
dalek a: 53bff84 | fperrad++ | (50 files):
reorg tree
 15:49
15:54 Hunger joined
dalek a: 597612d | fperrad++ | lua/library/Makefile.in:
fix after reorg
 16:00
lscript: 98c7001 | fperrad++ | dynext/ (2 files):
fix after reorg
 16:04
lscript: 029ea8f | fperrad++ | dynext/ (2 files):
fix after reorg
a: 0eae52a | fperrad++ | dynext/pmc/Makefile.in:
fix after reorg
 16:17
a: 7bab379 | fperrad++ | doc/ (2 files):
update doc
16:22 theory joined
dalek a: 4ed6f1d | fperrad++ | Configure.pir:
chmod +x
 16:23
a: 3245743 | fperrad++ | dynext/pmc/Makefile.in:
fix after reorg
 16:29
a: baef520 | fperrad++ | (2 files):
fix after reorg
16:44 davidfetter joined
dalek a: 4c22900 | fperrad++ | (2 files):
fix after reorg
 16:57
16:58 iblechbot joined 17:08 DrForr_ joined 17:32 Zak joined 17:34 whoppix joined 18:03 kid51 joined
Coke ~._ 18:57
diakopter \\__/ 18:58
dalek rrot: r42332 | coke++ | trunk (7 files):
Fix codingstd outdent test, courtesy plobsing++

   (but passed the old test.)
Resolves issue #1137.		 18:59
TT #1137 closed by coke++: [PATCH] fix codingstd/c_indent.t wrt switch/case labels 19:01
19:03 eternaleye joined
Coke yay, RT down to 61. 19:04
(and I didn't even do those 8.)
diakopter is the goal to move all the RT ones to trac? 19:06
19:12 mikehh joined
dalek TT #759 closed by coke++: Reconsider one-test-file-per-PMC policy 19:14
rrot: r42333 | coke++ | trunk (2 files):
Remove test file that checks for test files.

Resolves Issue #759		 19:16
Coke msg kid51 fyi, hll_interop is not appropriate for /every/ HLL-related ticket, only for those where two HLL's are trying to talk to each other. 19:20
purl Message for kid51 stored.
dalek TT #376 closed by coke++: support policy refers to x.5 releases 19:21
19:22 bacek joined
Coke is trac this slow for anyone else, or is it just me? 19:23
NotFound Coke: an hour or so ago it worked well. 19:25
Coke If I want the trac wiki page for languages, is there somethign I can enter in the seach to force it? 19:28
NotFound google ;) 19:30
dalek TT #252 closed by coke++: xlst out of date 19:31
NotFound Coke: uh... There is a trac wiki page for languages? I only know the one in www.parrot.org 19:33
dalek TT #915 closed by coke++: email2trac test 19:34
Coke I have no idea why that effort was duplicated on parrot.org 19:36
the one on trac was the "real" one, I thought.
msg mikehh hey, when you untodo a test that has a TT number... you might want to resolve the ticket. =-) 19:38
purl Message for mikehh stored.
NotFound Coke: The one that that feeds dalek?
dalek TT #1027 closed by coke++: PIR-only segfault 19:41
NotFound Coke: the search works reasonably fast for me now. 19:43
dalek TT #897 closed by coke++: Review test coverage and add more tests or deprecate unused functionality. 19:44
Coke pmichaud: ping 19:48
Can we reject #590 (presuming these are only going to be in nqp-rx, not PGE)
pmichaud pong
yes 19:49
or we can mark it as being done in nqp-rx instead
dalek TT #590 closed by coke++: PGE proto regex 19:51
tracwiki: v106 | NotFound++ | Languages 19:52
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
19:58 payload joined
Coke I wonder which page dalek is using. 19:58
NotFound pmichaud: Have you seen my patch in TT #1078 ? 19:59
pmichaud NotFound: no, hadn't seen it -- looking 20:01
the original source is incorrect -- it forgets to pop the handler after catching the exception
i.e., I don't think a patch is needed, because the original test case is flawed 20:02
NotFound pmichaud: dying with exahusted stack for a pitfall like that is very wrong, IMO. 20:03
And from time to time people create new tickets like that, wich doesn't help anything. 20:04
pmichaud NotFound: I'd be fine with (re)using the recursion limit as a limit for exception handler triggering
since they're effectively the same thing. does your patch do that?
Coke I'm kind of surprised the recursion limit doesn't already trigger that.
NotFound pmichaud: no, just tested with an arbitrary value.
pmichaud I'd suggest recursion limit.
and throw the same sort of exception as a recursion limit
NotFound pmichaud: but my main question is that I'm doing the right thing to avoid interfere with control exceptions. 20:05
Coke I don't think that limiting the # of times a handler can fire is the right approach.
(and if we do, the limit should be 1.)
NotFound Coke: segfaulting sure is not.
pmichaud I agree, limiting the number of times a handler can fire is wrong. 20:06
NotFound Coke: I agreed, but last time I asked the answer was a big NO.
Coke right.
NotFound Is wrong, but segfaulting is hardly better. 20:07
pmichaud putting in an incorrect behavior is equally bad, though.
worse, because people might come to depend on it 20:08
(I admit, not likely in this case)
NotFound What is the correct behavior, then?
pmichaud use the same logic that gets used for recursion limits, I suspect
NotFound The logic is setting a limit and throw. That's what I'm doing.ç 20:09
pmichaud right, but the question is where the limit gets counted
it shouldn't be counted in the exception handler itself
NotFound Ah, that is a secondary question for me.
Coke I imagine we'd get this for free if we used sub-based handlers.
pmichaud because it's very likely that one handler might be asked to handle thousands or tens of thousands of exceptions that aren't recursive
Coke: I'm in general disagreement that sub-based handlers solve any of the problems they're intended to solve (inferior runloop, e.g.), although I admit it might help with this case 20:10
NotFound pmichaud: given that we don't have a way to know when the handler has finished, I can't imagine other place. 20:12
pmichaud I'd prefer to segfault on incorrect code than to have incorrect behavior on correct code, though. 20:13
segfaults are bad, yes, but fixing them shouldn't cause correct code to fail 20:14
NotFound pmichaud: I'm tired of losing time tracking that type of bugs.
pmichaud then we should fix the issues with exception handlers at some point 20:15
I'll add my comments to the ticket, and then others can decide the best approach.
Added. 20:18
dalek TT #1227 created by bubaflub++: [PATCH] config/gen/crypto/digest_t.in for generated tests in t/dynpmc
NotFound I suppose that best approach will be the same as in previous cases: do nothing. 20:20
pmichaud s/best/best currently available/
I fully agree with you that it should not segfault. I do not have a superior answer at the moment, though.
NotFound I wonder why we check array out of bounds access. After all, is an error in the user code, same as this. 20:21
</rant> ;)
pmichaud because adding that check doesn't impose an incorrect semantic on correct code.
adding a limit to the number of times a handler may be triggered would be like adding a limit to the number of times a subroutine can be invoked 20:23
20:23 chromatic joined
mikehh Coke: which ticket? 20:27
purl which ticket is, like, this now
diakopter purl, forget which ticket 20:28
purl diakopter: I forgot which ticket
diakopter purl, forget yourself
purl diakopter, I didn't have anything matching yourself
20:31 Zak joined 20:34 mokurai joined
dalek rrot: r42334 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
[pct/post]: Remove spurious tailcall of void result in void context.
 20:39
pmichaud Coke: since you'll be away for the week, I'll plan that we'll do partcl stuff soon after you get back 20:40
hopefully I'll have a lot of the other rakudo and nqp stuff out of the way by then 20:41
20:41 eternaleye joined 21:10 mokurai joined
mikehh I am getting a failure with t/op/comp.t with g++ and --optimize on Ubuntu 9.10 i386 - it does not fail with gcc and without --optimize 21:11
nopaste "mikehh" at 81.149.189.7 pasted "failure with t/op/comp.t with g++ and --optimize on Ubuntu 9.10 i396" (31 lines) at nopaste.snit.ch/18601 21:17
kid51 mikehh: Have you tested with that platform/compiler/options combination before? 21:19
mikehh bah i386
kid51 i.e., is this a new failure ... or something newly exposed by different, say, compiler?
mikehh kid51: we have only recently got g++ 4.4.1 to work on Ubuntu 9.10 (NotFound++) and it the first time I tested (yesterday I think) on Ubuntu 9.10 i386 21:22
I Haven't got any other i386 installations at the moment - I updated my 9.04 i386 and it was ok last time I tested there 21:23
kid51 Sounds like it's mostly the new version of g++
mikehh possibly - it does pass without optimize and passes on amd64
NotFound mikehh: going to try now on my laptop 21:24
kid51 But it sounds more like our code being exposed to a new environment, rather than a long-standing (known) defect in our code.
i.e., it doesn't sound like it's due to a recent commit. 21:25
... so bisecting probably wouldn't say very much.
NotFound Thanks to new platform, otherwise I'm unable to convince some people to fix 'features' }:) 21:27
kid51 mikehh: Sorry I wasted your time on that test for TT #1194 21:28
mikehh kid51: np 21:29
kid51 Would you be able to give that another try on your amd64?
NotFound mikehh: fails also for me 21:30
mikehh the last test I did on Ubuntu 9.04 i386 was at r42132 - that passed (with g++ and --optimize)
NotFound Don't worry too much, I had an old gcc where 0.0 > 0.0 failed sometimes X-) 21:31
mikehh I can't go back to that revision with g++ 4.4.1 because it won't build 21:32
kid51 tries compiling for first time with mikehh's combination of command-line options 21:33
mikehh kid51: I am headed back to amd64 shortly - I just want to look at that test in more detail 21:36
kid51 Thanks! 21:38
Util Does Parrot provide any way to undo a `loadlib` op in a running PIR program? 21:43
NotFound The numbers looks equal in the Float vtable function using an fprintf with lot of precission 21:44
21:51 NotFound left, NotFound joined
NotFound FLOATVAL n1= SELF.get_number(); 21:53
FLOATVAL n2= VTABLE_get_number(INTERP, value);
(n1 == n2) and (SELF.get_number() == VTABLE_get_number(INTERP, value)) give different values
dalek rrot: r42335 | jkeenan++ | trunk/src/pmc/integer.pmc:
Add 'TODO' notation.
 21:55
Coke buys disney tickets for 9 people for 3 days and nearly faints. 21:57
Util: I don't think so. 21:58
dalek TT #1228 created by jkeenan++: src/pmc/integer.c: Implement Complex and BigInt RHS values for the pow() ...
Coke it's basically a dynamic load, yes? (is there a way to do that unload from C?)
kid51++: thanks for doing ticket cleanup.
also kj++ and fperrad++
dalek rrot: r42336 | jkeenan++ | trunk/src/pmc/integer.pmc:
Change RT # to TT #.
 22:01
purl dalek: that doesn't look right
TT #1229 created by jkeenan++: src/pmc/fixedpmcarray.pmc: get_repr() should use freeze/thaw 22:08
rrot: r42337 | jkeenan++ | trunk/src/pmc/fixedpmcarray.pmc:
Change RT # to TT #.
 22:12
purl dalek: that doesn't look right
NotFound SELF.get_number() - VTABLE_get_number(INTERP, value) gives 4.445229e-17 22:17
No wonder that == gives false 22:18
dalek TT #1230 created by jkeenan++: src/pmc/eval.pmc: Walk the fixups, locate globals and nullify the Sub PMC
rrot: r42338 | jkeenan++ | trunk/src/pmc/eval.pmc:
Change RT # to TT #.
purl dalek: that doesn't look right
Util Coke: Ah, I see. I had not thought it through to the dyld/dlopen calls. 22:20
So, anything that tests different ways of loading a lib (like t/dynpmc/foo.t does) will need a fresh Parrot instance for each `loadlib`.
bubaflub++ did nice work in TT #1217 converting foo.t from Perl to PIR. However, it is now full of false negatives, since the first successful `loadlib` masks any later failures.
NotFound I don't know if we must fix this by storing the values in a FLOATVAL variable before comparing, or fix the test because is wrong to compare for exact equality two floating values calculated in different ways.
Coke it's always wrong to test floats for equality. no? 22:21
NotFound Coke: in the vast majority of cases, yes. 22:22
I'm not sure if the optimizer is doing the right thing is this case, though. 22:24
mikehh the problem being is that it passes the test in most cases but not with optimized g++ on i386
dalek TT #1231 created by jkeenan++: src/pmc/hash.pmc: Use freeze in get_repr() (for hashes) 22:25
NotFound mikehh: if the test is wrong, I don't care that it passes.
dalek rrot: r42339 | jkeenan++ | trunk/src/pmc/hash.pmc:
Change RT # to TT #.
purl dalek: that doesn't look right
NotFound I don't want tests that fails when optimizing if they are not testing the absolutely right thing. 22:26
mikehh NotFound: oh I agree, but just curious why it fails in that case
NotFound mikehh: I'm not sure, nut maybe just because the compiler is doing a better optimization.
I think that the standard allows to optimize any temporary result until is assigned to a variable, and for floats this mean he can use the higher precision available. 22:28
mikehh fp values should never be tested for equality
Tene should we make that an error, then? 22:29
NotFound mikehh: not always. For example, in a compiler deciding if he must use the absolute zero format for printing.
Coke "almost never"
Tene can the cases where it's appropriate be completely enumerated, so we can fail the rest of the time? 22:30
NotFound Did we have a mathematician in the room? ;) 22:31
mikehh if (abs(value1 - value2) < epsilon)
Tene mikehh: that's not equality. 22:32
NotFound But perfect equality is not what that test must be doing. 22:33
mikehh it's a valid test for approximate values - i.e. floating point
Tene Right.
NotFound In fact, I'm not sure if having that opcode makes sense. 22:34
Tene So, could it ever make sense to change the is_equal vtable in float.pmc to throw an exception?
NotFound Compare for exact equality floating point values stored or obtained in different ways, which is what that opcode do, is wrong. 22:35
22:36 Essobi joined
NotFound Tene: is not the is_equal vtable, is the is_equal_num 22:36
But I think the is_equal multi has the same problem when comparing PMC of different types. 22:39
dalek TT #1232 created by jkeenan++: t/src/warnings.t: Test fails when Parrot built with g++ and --optimize 22:41
NotFound The problem is that in an op with an integer result we can't test the result is 'almost true' X-)
Mmmmm... I've found the simplest fix: add a lot of zeros to the values used in the test 22:49
set P0, -1.200000000000000 ... set P1, "-1.200000000000000"
dalek TT #1233 created by jkeenan++: t/pmc/exporter.t: Refactor namespace getting code once make_namespace() ... 22:54
rrot: r42340 | jkeenan++ | trunk/t/pmc/exporter.t:
Change RT # to TT #.
 22:55
purl dalek: that doesn't look right
NotFound TT #1176 migth be the cause of that failure: 22:56
"I have redefined POW to be pow() unconditionally in r42217, and put a note referencing this TT"
Yes, defining POW as powl the test pass. 22:57
At least we know why it don't failed before :) 22:58
23:05 Zak joined
mikehh NotFound: you only need to add zeros to the string not the number 23:14
and minimum is "-1.2000000000"
any fewer fails 23:15
zeros that is
NotFound mikehh: yes, but maybe that way is worsen things, it may fool the precision in the Parrot_str_to_num calculations. 23:16
Why we just doesn't use scanf? 23:17
sscanf
dalek tracwiki: v107 | NotFound++ | Languages 23:40
tracwiki: Restore alphabetic order
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
mikehh NotFound: I'll create a ticket for this in a bit - I want to check on some issues 23:46
mikehh needs a break - bbl
dalek rrot: r42341 | jkeenan++ | trunk (77 files):
Merge convert_OSNAME into trunk. In config steps after auto::arch, we know 'osname', so use '->data->get('osname')' instead of '->data->get_p5('OSNAME')'. Cf.: trac.parrot.org/parrot/ticket/1194.
 23:51
NotFound mikehh: I've put a comment in TT #1176 23:52
dalek rrot: r42342 | jkeenan++ | branches/convert_OSNAME:
Branch has been merged into trunk and is no longer needed at HEAD.
 23:54
purl i already had it that way, dalek.

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!