Parrot 0.8.2 Feliz Loro Released | parrot.org | 45 TT | 538 RT
Set by moderator on 17 December 2008.
00:09 AndyA joined 00:16 ruoso joined 00:21 apple-gunkies joined
dalek r34263 | pmichaud++ | trunk/languages/perl6/src (2 files): 00:51
: [rakudo]: refactor more "list methods" from Mapping into Any
review: xrl.us/3248b
00:55 apple-gunkies joined 01:11 ewilhelm_ joined 01:14 particle1 joined 01:19 apple-gunkies joined
Coke pmichaud: I am glad that I am probably one of the few people who will ever want to say "anyone" to your statement about nested sub definitions. 02:00
Tene Coke: eh? 02:01
purl Get off my lawn!
Coke tene: feh?
purl feh is ricocheting
Coke cj? 02:03
purl i heard cj was a soylent donut or from Poulsbo, WA or AIM:carljcollier or mailto:jabber:cjcollier@seattlewireless.net or mailto:MSN:cjcollier@colliertech.org or mailto:cjcollier@colliertech.org
Coke yup, that's him.
Coke wonders at facebook. 02:06
02:10 tetragon joined 02:16 kid51 joined
dalek r34264 | jkeenan++ | trunk/t/tools/ops2pm: 02:17
: Jiggle the tests until more of them pass.
review: xrl.us/4auuf
02:25 apeiron joined
pmichaud Tene: I think I've decided that for the short term we're not going to worry about NEXT/LAST/REDO handlers in PCT just yet. 02:26
the various loop types do need to catch the loop exceptions and dtrt, though.
TiMBuS is there a reason this would segfault for an op? int a = VTABLE_get_integer(interp, VTABLE_get_pmc_keyed_int(interp, $3, 0)); 02:35
pmichaud depends on what the get_pmc_keyed_int is returning.
TiMBuS $3 is a resizablepmcarray, and im certain its got a value in it, and its an Integer
Coke and what $3 is, though that'd be harder to screw up. 02:36
pmichaud ...any tailcalls involved? ;-)
pmichaud tries his new heuristic.
TiMBuS nope, at least not directly
particle1 msg barney barney++ # nice work with the "pir injection" technique for .HLL :) 02:37
purl Message for barney stored.
pmichaud ...pir injection?
TiMBuS i guess ill just screw around until the error shows itself
particle1 make PAST::Stmts.new( $past, PAST::Op.new( :inline( "_block11()\\n.end\\n.HLL 'Pipp'\\n.sub 'anon'" ) )); 02:39
pmichaud ick.
Coke I'd split that into 2 lines, and step through them. Also, grab the backtrace. Also, does it go away with -G?
pmichaud adds HLL to PCT.
TiMBuS caught it. whoops that was my bad, was assigning to uninit'd pointer 02:40
the joy of coding in c 02:41
particle1 pmichaud: seems rakudo's failing some inf/nan spectests on win32 02:43
i haven't read all the recent commits, so i'm not precisely sure what's changed
i'll nopaste the report...
...later...afk & 02:49
Coke particle: are they the same inf/nan errors that fail for parrot itself? 02:57
pmichaud guesses yes. 03:01
dalek r34265 | pmichaud++ | trunk/compilers/pct/src/POST (2 files): 03:33
: [pct]: .HLL support part 1 -- 'hll' attribute in POST nodes.
review: xrl.us/4gsbq
03:38 ewilhelm joined
kid51 ewilhelm ping 03:39
ewilhelm kid51, pong? 03:40
kid51 Hi. Do you have anything to add to rt.perl.org/rt3/Ticket/Display.html?id=57320 ? (I think you opened it, originally.) 03:41
ewilhelm haven't been following too closely. does it no longer do `mkdir /tmp/t` ?
dalek r34266 | pmichaud++ | trunk/compilers/pct/src/PAST (2 files):
: [pct]: .HLL support part 2 -- .hll in PAST::Block nodes.
review: xrl.us/4hpyh
pmichaud msg barney you should be able to set :hll('...') on PAST::Block to put blocks into a different .HLL . 03:42
purl Message for barney stored.
kid51 ewilhelm: [parrot] 514 $ grep mkdir t/perl/Parrot_IO.t 03:44
[parrot] 515 $
dalek r34267 | pmichaud++ | trunk/docs/pdds:
: [pct]: Update pdd26_ast.pod with 'hll' attribute on PAST::Block .
review: xrl.us/4hxrp
kid51 No 'mkdir' at all.
uses File::Temp::tempdir().
ewilhelm kid51, that sounds good
kid51 anyone: Do we not have an IRC channel topic set right now? Or have my settings gotten screwed up? 03:45
ewilhelm: Thanks. I will close the ticket.
ewilhelm sees no topic
moderator Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2 03:47
kid51 ... for lack of a better idea ;-) 03:48
ewilhelm thanks
kid51 Re: Win32 math errors: rt.perl.org/rt3/Ticket/Display.html?id=52198 03:50
kid51 must sleep 03:57
purl $kid51->sleep(8 * 3600);
04:02 elmex_ joined 04:10 pdcawley joined 04:21 MariachiElf joined 04:22 ChrisDavaz joined 04:31 flw joined 04:32 flw joined 05:04 tetragon joined 05:09 masak joined, petdance joined 05:53 ChrisDavaz joined 06:25 MariachiElf joined
Tene pmichaud: next/last/redo work in rakudo in the branch. Should we just merge for now and deal with the handlers later? 06:32
pmichaud I still want to avoid the throwing of the exceptions. 06:37
They aren't needed.
(I should say "the forced throwing of the exceptions")
Just posted a draft article at use.perl.org/~pmichaud/journal/38134 -- comments and suggestions welcome. 06:38
(I'm also planning to send it to rakudo.org and perl6-users mailing list.)
nopaste "tene" at 166.70.38.237 pasted "pmichaud: so like this?" (41 lines) at nopaste.snit.ch/15074 06:44
Tene ... wait, that doesn't work.
masak likes the article 06:46
pmichaud posts. 06:47
masak enthusiastic Perl 6 coders are what we need.
the more, the better.
dalek r34268 | tene++ | branches/pctloop/compilers/pct/src/PAST: 06:53
: [pct]: Use a goto instead of an exception in one place.
review: xrl.us/4y9eg
pmichaud Tene: I'm falling asleep at my keyboard, so pctloop will be the first thing I look at tomorrow morning.
afk # sleep 06:55
06:59 Theory joined
masak wrote a short summary: use.perl.org/~masak/journal/38135 07:07
hope that's ok. :)
07:37 Theory joined 08:04 iblechbot joined 08:55 barney joined 09:25 ask_ joined 09:42 donaldh joined
dalek r34269 | bernhard++ | trunk/languages/pipp/src/pct: 09:53
: [Pipp] Use the nifty hll attribute on PAST::Block.
: Unbreak 'require_once'. pmichaud++
review: xrl.us/5dyee
09:56 ask_ joined
dalek r34270 | bernhard++ | trunk/languages/pipp/t/embed: 09:58
: [Pipp] Reenable example with function lookup.
review: xrl.us/5eaom
10:12 particle joined 10:17 ask_ joined 10:39 alvar joined 10:57 Zaba joined 11:38 ruoso joined 11:41 Lorn joined 12:00 TiMBuS joined 12:04 GeJ joined
dalek r34271 | bernhard++ | trunk (2 files): 12:10
: Trac#75: Add file ext/Parrot-Embed/t/pipp.t with most test cases commented out.
review: xrl.us/5orh9
12:44 ChrisDavaz joined
szabgab barney: thanks 13:01
barney szabgab: I submitted trac.parrot.org/parrot/ticket/85, as 'eval' is not found in the 'pipp' hll root namespace 13:03
13:06 tetragon joined
szabgab barney: yeah, I hope things start to move on the embedding front now so in a few days/weeks I'll be able to write Padre::Plugins in other languages, not only perl 5 13:06
13:10 petdance joined
dalek r34272 | bernhard++ | trunk/languages/pipp/src (7 files): 13:30
: [Pipp] Avoid the implicit downcasing of the HLL name.
: Prepare for using the '_pipp' hll root namespace for Pipp internals.
review: xrl.us/5toim
13:44 ask_ joined
dalek r34273 | bernhard++ | trunk/languages/pipp/src: 13:47
: [Pipp] Move some internal functions into the '_pipp' hll root namespace. 13:48
review: xrl.us/5vdji
13:50 petdance joined, ffwonko joined 13:52 Theory joined 14:01 particle1 joined
Coke I tend to think of xrl.us as a scarce resource; do we really need to use it here? 14:10
is www.parrotvm.org/svn/parrot/revision?rev=34273 really too long?
pmichaud not for me. As long as it doesn't trigger one of the other bots that "helpfully" shortens it for us. 14:12
jonathan pmichaud: What's status of use/initload things? 14:18
And rakudoreg stuff?
jonathan is too lazy to backlog several days worth
pmichaud use/initload is finished 14:19
I'm *much* happier with what we have now.
jonathan ok, good 14:20
dalek r34274 | bernhard++ | trunk/languages/pipp/src (2 files):
jonathan Did those get updated into the branch?
pmichaud I was going to do rakudoreg stuff next, but ended up attacking spectests.
dalek : [Pipp] Set the scope of the superglobals to 'package' in the TOP-Block.
: Beware that there are still local symbol scope declarations the override the
: declaration in TOP.
review: xrl.us/5xcxk
barney likes www.parrotvm.org/svn/parrot/revision?rev=34273
pmichaud (updated into branch) short answer, no -- I figure it might be easier to start a new branch and then bring rakudoreg updates into that new branch
jonathan maybe 14:21
I don't have svn 1.5 on this laptop...
Guess I can upgrade though.
pmichaud well, that's part of what makes the new branch easier -- don't need svn 1.5 to do it 14:24
jonathan In that case, it's your job, 'cus I don't understand pre-1.5 branch management. :-) 14:25
pmichaud okay, I'll do that part, but basically it's:
14:25 Wknight8111 joined
pmichaud svn copy svn.perl.org/parrot/trunk svn.perl.org/parrot/branches/rakudoreg2 # create new branch 14:25
jonathan I can do that bit. :-) 14:26
pmichaud svn co svn.perl.org/parrot/branches/rakudoreg2 # check out copy
cd rakudoreg2
# figure out starting revision of rakudoreg branch
dalek r34275 | Whiteknight++ | trunk/src: 14:27
pmichaud svn merge -r $rev:head svn.perl.org/parrot/branches/rakudoreg
dalek : [Patch] remove a little bit of logic redundancy. A smart compiler probably ignored this already, but I don't count on all compilers being smart. jimmy++
review: xrl.us/5xefb
pmichaud where $rev is the starting revision of the rakudoreg branch. That can be determined quickly by using svn log --stop-on-copy
...but instead of doing a all-at-once merge, I was just going to look at the diffs and recreate them in the new branch 14:28
jonathan OK.
pmichaud I probably won't get to it for another couple of hours, though, as I told Tene I'd work on loops this morning.
jonathan There's a better chance of you not screwing it up. :-)
Oh, that's fine.
pmichaud I've also decided to implement find_lex_contextual and store_lex_contextual ops.
jonathan I'm sorta in holiday mode, have a load of family around, am seeing various UK friends etc.
So only getting snatches of hacking time. 14:29
Oh, cool.
Context vars. :-)
pmichaud yes -- I've come up with about a half-dozen immediate use cases for them, so I'm going to stick 'em into NQP.
(and PCT)
jonathan Great.
Wknight8111 pmichaud++
14:29 donaldh joined
jonathan I may well dig into S14. 14:30
pmichaud and although I could probably make something work without the new opcodes, it's so much more straightforward with the ops that I'm just going to do it that way. :-)
jonathan Oh yes, I can imagine.
Not to mention faster at runtime.
pmichaud Sam Vilain sent a message to parrot-dev, gist of the message was "Rakudo needs a better install, line numbers in error messages, less error trace information, debugger, avoid VM spiraling out of control" 14:31
so "line numbers in error messages" (bytecode annotations) would be good to work on if you get a chance :-) 14:32
jonathan Line numbers in error messages is already in progress.
pmichaud I'll likely do that part of the PGE refactor this week.
jonathan Great.
I want to land the Parrot changes for it early Jan.
pmichaud so it'll be ready when the bytecode annotations come in.
jonathan Good. 14:33
14:33 flh joined
jonathan Better install - sorta depends on sorting it out for Parrot first. 14:33
less error trace information - more is useful for now, IMO. 14:34
though we won't want to incldue the stuff below Rakudo level in backtraces. 14:35
debugger - more important things to focus on right now, IMO, but I'd very happily see someone working on it if they wanted to. 14:36
VM spiraling out of control - usually we gotta fix this on a case by case basis...
jonathan is trying to find the original message 14:37
barney find_lex_contextual() can that be used for checking wether a lexical is already declared ? 14:41
14:42 gryphon joined 14:45 jhorwitz joined
jonathan barney: In the dynamic scope. 14:46
14:51 contingencyplan joined
Coke needs to add a sanity check to the spec_test tool tcl runs that verifies we're running against a /clean/ copy of the spec tests. 14:51
accidentally passed something. 14:52
PerlJam Coke: gas? :) 14:53
Coke a spec test.
jonathan lol 14:54
Coke shares a horrible joke from a coworker. 15:01
A SQL query goes into a bar, walks up to two tables and says, "Can I join you?"
jonathan *GROAN*
Coke ... that's what I said. 15:02
Andy eeenteresting: smallcode.weblogs.us/2006/08/22/fas...-function/ 15:10
shorten Andy's url is at xrl.us/5zqc4
Andy Duff's device + anding for equality 15:11
dalek r34276 | pmichaud++ | trunk/languages/perl6/docs: 15:26
: [rakudo]: spectest-progress.csv update: 264 files, 5833 passing, 0 failing
review: xrl.us/52k8r
jonathan Wow. 6,000 coming soon?!
pmichaud maybe.
I probably hit a lot of the low-hanging fruit this past weekend.
jonathan *nod* 15:27
Sure, but having a sweep out of that lot now and then can be a good thing.
The stuff you've done all needed doing at some point.
pmichaud right now I don't have a good feel for what we need to be working on to pass more tests, though. 15:28
I guess there's a fair bit of S05 stuff that needs doing.
barney When adding a 'lexical' PAST::Var to a PAST tree: Can I say :isdecl(1) unless already declared ? 15:29
nopaste "pmichaud" at 72.181.176.220 pasted "spectests by synopsis, 2008-12-23" (16 lines) at nopaste.snit.ch/15076
pmichaud right now having multiple :isdecl(1)'s in a block causes problems for Parrot.
jonathan pmichaud: Doing parameter stuff would let us at least close some tickets. 15:30
It won't win us hundreds of tests maybe, but some for sure.
pmichaud jonathan: agreed. 15:31
in reviewing the test suite I didn't see anything (other than S05 stuff) that might win us hundreds of tests
jonathan Once you get that in place I will mostly likely not be that far behind with the unpacking stuff, 'cus it's -Ofun ;-)
pmichaud of course, that only includes tests that are in t/spec . There may still be tests in t/ (not t/spec/) that need migration.
PerlJam barney: On the first day of a christmas my true-love gave to me ... a PAST::Var in a PAST tree. 15:32
jonathan *nod*
barney Can I use find_lex for checking whether a var is already declared? Or do I have to search the blocks, like in the Squaak tutorial ?
pmichaud barney: find_lex is runtime, search blocks sounds like compile-time 15:33
so...?
purl Yeah, so?
barney wants a big PAST::Block, not a small PAST::Var
PerlJam barney: what are you implementing?
barney PHP variables, which are not declared. 15:34
15:34 contingencyplan joined
PerlJam so, you're doing the auto-declare-on-first-use dance? 15:35
barney yep
pmichaud barney: you want to be using the PAST::Block.symbol table then
when you encounter a variable, check the Block's symbol table to see if it's already defined. If yes, generate a normal PAST::Var node. (more) 15:36
If no, then generate a PAST::Var node with :isdecl(1) and put it at the beginning of the block, and mark an entry in the .symbol table. Then generate a normal PAST::Var node.
barney Does that work with symbols in symbol tables in outer blocks? 15:39
pmichaud are you trying to handle the case of nested subs? 15:40
I haven't done much nested subs in PHP.... but if you have function a() { $x = 1; function b() { $x = 2 } } then the $x that is in b() doesn't refer to the same $x as function a(), right? 15:41
barney Kind of. Currently I only have superglobals in TOP Block, that I declared as 'package' vars. All other vars should be lexicals, so that I can support closures 15:42
PerlJam PHP does closures? 15:43
pmichaud anyway, I'm trying to come up with a case where a variable needs to be checking its outer blocks.
(and not coming up with one.) 15:44
barney pmichaud: In 5.3 there is a 'use' syntax, that says which vars should be taken from the outer scope
pmichaud how does one declare a local var, then?
(haven't seen 5.3 at all.)
barney in functions all vars are local, unless they have been declared with 'use' 15:45
pmichaud so 'use' explicitly means "check the outer scope"
?
barney yes 15:46
PerlJam barney: does it just look in the immediately outer scope or does it keep looking outward until it finds the var or runs out of scopes?
pmichaud okay, for a 'use' statement then you simply put an entry in PAST::Block.symbol that indicates that the lexical is already declared.
That prevents subsequent references from creating a new lexical in the PAST::Block, and PAST will default to using the lexical from its outer scopes.
i.e., 'use' is "suppress :isdecl for this variable in this block" 15:47
you still don't need to check the outer scopes :-). Unless of course someone has "use $x" and $x doesn't exist in any outer scopes -- I don't know if that's an error (or should be). 15:48
barney PerlJam: the 'use' is only for anonymous subs, I suppose for deeply nested anonymous subs it keeps on looking
pmichaud: At this point I can live with a runtime error 15:49
pmichaud anyway, the "magic" for making this work is to use the PAST::Block.symbol tables to keep track of variables. 15:50
In fact, that's what allows you to not have to put a :scope attribute on every PAST::Var node.
barney k
pmichaud so, in PHP, "global $foo" should do the equivalent of $past.'symbol'('$foo', :scope('package')); 15:51
barney I'll add the :isdecl(0) for the 'use'ed vars and for the superglobals
pmichaud (where $past is the node for the PAST::Block)
any later references to "$foo" simply do PAST::Var.new( :name('$foo') ) 15:52
(well... after doing the lexical check we described earlier)
barney pmichaud: Currently I think that "global $foo" would be $past.'symbol'('$foo', :scope('lexical')) 15:55
nopaste "pmichaud" at 72.181.176.220 pasted "code for PHP variables" (10 lines) at nopaste.snit.ch/15077
pmichaud ...why lexical?
barney or look up only one level 15:56
pmichaud is that because globals need capturing in a closure? 15:57
barney I think that working with lexicals simplifies handling of functions that are defined in required files.
pmichaud well, you can definitely do global variables as lexical also 15:58
where are you storing the global?
barney 'require' being basically a function call
a global in a required file is, AFAIK, only global to the required file. So that makes is look like a lexical. 15:59
pmichaud that doesn't sound familiar. 16:00
barney Where files and function are lexical boundaries, but { } is not
pmichaud oh. 16:01
the symbol is scoped to the file, but the variable lifetime isn't.
because in a required file, if I say "global $foo" then I'm talking about the same $foo that all of my other files that do "global $foo" are referencing.
I'm not creating a new $foo that is local to the file. 16:02
basically files just serve as another function boundary.
(even to the point of 'return' meaning 'exit this file') 16:03
16:07 flh joined
barney I haven't thought about 'global' yet. Maybe I need to put them into a 'package' and initialize from the lexical 16:08
pmichaud that works too. Anyway, I'd focus on lexicals to begin with. I think the answer lies in making use of the PAST::Block.symbol table (which is why it's there, of course :-) 16:09
16:14 ask_ joined
flh hi everyone 16:14
purl Howdy, flh, you fantastic person you.
16:15 masak joined
flh I had a question about pir: I'm trying to write a function which expects a fixed number of arguments, but when given less arguments, it returns a new function which waits for the rest 16:16
16:17 donaldh joined
flh and I'm afraid I don't know how to start writing such a thing... 16:17
pmichaud flh: ah, that's currying. :-)
apple-gunkies self.curry() ?
flh sure, I'm playing with the ocaml language :)
pmichaud in Rakudo we do it using lexicals. 16:18
barney was reading up on de.php.net/global The toplevel scope seems to be special for 'global'
flh I knew I should have asked earlier 16:19
pmichaud the code that Rakudo uses (in Perl 6 it's the ".assuming method") is languages/perl6/src/classes/Code.pir line 132. 16:20
16:20 contingencyplan_ joined
flh thanks! 16:23
16:24 contingencyplan_ joined 16:27 pdcawley joined
PerlJam What's the difference between creating objects using PMCs vs. straight PIR? Why choose one over the other? Is it strictly speed? Are there some capabilities that one has and the other does not? 16:29
pmichaud PerlJam: you mean the difference between writing a new PMC type versus doing "newclass" in PIR? 16:30
Coke tcl has a form of currying like "interp alias {} foo {} if 1"; then whenever you say "foo {puts hi}", it's like you had typed "if 1 {puts hi}". (if you're testing, it's a way to run things all the time, or skip, depending on the alias.); I was pleasantly surprised I could do this with proc foo {args} { uplevel 1 "if 1 $args" } with partcl already.
PerlJam pm: right.
16:30 contingencyplan__ joined
Coke (it's not really currying. Though tcl has that with 'apply', which I also need to hack on.) 16:30
pmichaud the primary difference at the moment is that PMCs give you the ability to do things in C, while Objects limit you to PIR. 16:31
Coke if you want the best of both worlds, you could theoreticaly do a base in PMC and provide methods in PIR.
(though ISTR that kind of mixin has issues atm.)
pmichaud Coke: that works for the most part -- we do it a fair bit in Rakudo. 16:32
Coke ah, cool.
pmichaud what's tougher to handle is overriding vtable methods in a PMC
16:32 contingencyplan_ joined
Coke I find it helpful to use PIR for cases where I want attributes. 16:32
Wknight8111 PIR vtable overrides definitely have problems 16:34
at least, some of them do
16:35 contingencyplan joined
barney is back after dinner 16:36
16:39 tomyan left
PerlJam pm: ping 16:47
16:51 contingencyplan_ joined 16:55 mberends joined 16:56 davidfetter joined 17:24 particle joined
donaldh Hi, I'm looking for advice trying to debug a GC crash. 17:27
17:29 alvar joined
donaldh I have a p6 sub that typically crashes in pobject_lives. With -G it runs to completion. With --runcore=gcdebug it _appears_ to infinite loop. 17:29
pmichaud PerlJam: pong 17:30
donaldh In the debugger, it's looping through runops_gc_debug_core but I can't tell if it's just repeating the exact same loop or not. 17:31
Are there any helpful tools in the GC debugging armoury?
PerlJam pm: Could you explain the 'for' pasttype a little more? It seems to only be used in two places: cardinal and rakudo. rakudo's usage seems complicated by comparison to cardinal. 17:32
pm: also, all of the other pasttypes seem to operate on individual nodes (which may be aggregates), while the 'for' pasttype talks about iterating over it's first child. That seems odd to me right nwo. 17:34
s/nwo/now/
pmichaud pj: iterating over an aggregate is fairly common. PHP does it, Perl 6 does it, Ruby does it, and I think Python does also. 17:35
so that's what 'for' represents.
PerlJam right, that makes sense. I guess it's just that there don't seem to be "arrays" in PAST. 17:36
pmichaud even 'for' doesn't really iterate over arrays -- it uses iterators. :-)
I suppose it would make more sense if 'for' took an iterator as its first child instead of an aggregate, though. 17:37
anyway, having it automatically construct an iterator from an aggregate is useful, so I might keep it the way it is. 17:39
pmichaud rationalizes. :-)
Wknight8111 donaldh: You have a test case? 17:44
dalek r34277 | pmichaud++ | branches: 17:48
: New branch for 2nd attempt at loop refactoring.
review: xrl.us/6fbd3
Coke donaldh: chromatic has some tips on debugging GC in parrot. 17:49
I'd start there.
www.google.com/search?rlz=1C1CHMP_e...t+gc+debug
shorten Coke's url is at xrl.us/6fhkf
Coke wonders if he can make a parrot Interp == tcl's [interp] 17:53
Wknight8111 Coke, you're probably going to have to subclass it 18:03
18:03 Whiteknight joined 18:05 rurban joined
donaldh sorry, afk 18:09
Whiteknight 'salright.
18:12 flh joined
pmichaud #ps in 11 18:19
Whiteknight w00t 18:20
dalek r34278 | Whiteknight++ | trunk/src/stm: 18:21
: [STM] Added a note here about how the debug definition for STM_TRACE is not C89 compliant, and linked to the ticket where we are discussing the issue.
review: xrl.us/6h3ti
nopaste "donaldh" at 213.123.171.12 pasted "Whiteknight: weather.p6 test case uses ext/SQLite3" (14 lines) at nopaste.snit.ch/15078 18:26
donaldh Whiteknight: any sqlite db with >100 rows should cause it. 18:27
dalek r34279 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST: 18:28
: [pct]: Initial version of loop_gen, 'until' using 'loop_gen'. NQP tests pass.
review: xrl.us/6iqhj
18:32 allison joined
dalek r34280 | bernhard++ | trunk/languages/pipp/src/pct (2 files): 18:33
: [Pipp] Start with keeping track whether a variable is declared.
review: xrl.us/6jcjw
Whiteknight donaldh, you might have to ask chromatic about this. I'm not too good with Rakudo or SQL stuff 18:34
donaldh :D
pmichaud #ps in -5 18:35
(as in 5 minutes ago)
18:35 apeiron joined
Coke irclog? 18:35
purl i guess irclog is irclog.perlgeek.de/parrot/today or see also: infrared clogs
18:36 PacoLinux joined 18:37 chromatic joined
dalek r34281 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST: 18:40
: [pct]: Switch 'while' to use loop_gen, refactor 'until'.
review: xrl.us/6j35e
particle how do i get access to parrot's coverity reports? 18:41
chromatic I send your contact information to Coverity.
particle aha. send away! 18:44
18:49 ambs joined
Whiteknight so we don't use STM? 18:52
particle no, never worked on win32 anyway
chromatic It relies on the old threading model too. 18:53
Whiteknight Really? what was holding it back on Win32? Who was working on it?
Coke ... and we haven't ripped it out?
particle it was a gsoc project from 2-3 years ago
Coke wasn't it a SOC project?
Whiteknight: let that BE A LESSON TO YOU! =-)
particle was mostly integrated, but never fully integrated since threads was still in prototype
we have no tuits to get it working before 1.0
it's not critical, so we rip it out and address it later 18:54
Whiteknight I've got tuits, I didn't realize it wasn't working
Coke Whiteknight: (tuits) hey, where's my shiny new GC? =-)
Whiteknight i'm practically made of tuits. Sleep is for lesser men
GC is in the pipeline
particle gc is critical
szabgab chromatic: do I need to try to nag you regerding the Parrot::Embed issues ?
Whiteknight I'm working on GC, had a few GC-related commits this week 18:55
particle rip out stm, get gc working, get docs ready for 1.0, then take a look at stm
Coke apologies to chromatic, but your ballot has already been cast. there's no papertrail.
Whiteknight docs are too out of date. We should rip them out too :)
particle i'll let you get the karma for that ;) 18:56
Whiteknight no, can't rip out docs. We'll just have to start going through them slowly 18:57
particle we can, however rip out stm. we^Wyou ripped out your gc, after all. :) 18:58
allison Whiteknight: yes, we can't simply rip out docs without reviewing them, but I suspect many of the current doc files will be ripped out 19:00
Whiteknight: or merged into other doc files 19:01
Whiteknight i was joking about the docs. I'm not going to rip them out, I'm going to slowly fix them
particle of course you are, and we might even help
dalek r34282 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST: 19:02
: [pct]: Move repeat_until to use the loop_gen code.
review: xrl.us/6obbz
particle allison: any thoughts as to how long a sockets impl might take in ideal developer hours?
allison particle: about 3 days 19:03
the core infrastructure is there, but needs the PMC on top
BTW, we have no tests for the socket implementation 19:04
19:04 ask_ joined
allison we have no code using the sockets implementation 19:04
particle yeah, that's a good place to have contributors
we have examples using sockets
Coke allison: tcl was using tcpstream
19:05 ambs left
Coke so, barney, is your question answered? =-) 19:05
dalek r34283 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST: 19:10
: [pct]: Refactor repeat_while to use loop_gen.
review: xrl.us/6pe34
Whiteknight particle, which runcores were you planning to rip out? 19:11
particle cgp, for one 19:12
Whiteknight we don't use cgp? I thought we did
particle it's gcc-only
chromatic We almost never test these runcores.
particle we need 1.0 to be *stable* 19:13
Coke cage test: find failing smoke tests and skip them on the reporting platform.
particle if we're not testing parts of parrot, like rarely used runcores and gc impls, we can't guarantee stability
allison particle: and frankly, many of those will never be used in their current state (or anything even vaguely resembling their current state), so we might as well scrap them 19:17
particle i'll gen some tickets after my errands 19:18
btw osuosl will host smolder for us
allison particle: excellent!
purl plays air guitar
particle i'm scheduling install for january
Whiteknight by that logic, we should rip out JIT too since it's got spotty platform coverage and isn't oft-tested 19:19
chromatic It's tested on platforms where it generates our NCI thunks.
pmichaud actually, I think JIT is the default build.
particle jit's a different beast
Coke works for me. I never use JIT. =-)
pmichaud (on platforms that support it)
allison Whiteknight: the JIT is good enough to keep 19:20
Whiteknight: we do have it on our roadmap for a substantial revamp later, though
chromatic LLVM++ 19:21
allison chromatic: yes, that's one of our primary possibilities
chromatic There's also Adobe's Nanojit, if you like Forth and Python. 19:22
Coke gnu lightning?
rurban cd branches; svn up... D ... D ... Out of memory - terminating application. !!! 19:24
I have experience with gnu lightning 19:25
Our JIT is better
Whiteknight if cgp is gone, whats the next fastest core? switch?
chromatic Runcore overhead isn't our biggest performance problem by any means. 19:26
Whiteknight perhaps not, but it's not something we should ignore
Coke be nice to have callgrind output so we could know for sure.
I'd rather make that a higher priority than keeping multiple runcors of undeterminate value. 19:27
Whiteknight particle, you going to create tickets for all the things that are slated for removal? Be good to take stock if there are a lot of things on the chopping block 19:29
allison Coke: yes
Coke (more tickets makes it easier to divvy up the work, also.)
19:34 ask- joined 19:48 rurban_ joined
Coke allison++ #ps 19:48
particle coke: DEPRECATED.pod is pretty big, looking now :( 19:52
Coke particle: imagine how much bigger it was!
Whiteknight let's hope this GC branch goes more smoothly now then it went over the summer 19:53
Coke +1
purl 1
Coke purl is also captain obvious
purl okay, Coke.
allison Whiteknight: breaking the changes down into small sets will certainly help 19:54
Whiteknight here's hoping 19:57
barney Is there a 'Recent changes' button in trac.parrot.org/parrot/wiki ? 19:59
particle trac.parrot.org/parrot/wiki/RecentChanges 20:00
how do we get parrot docs displayed on parrot.org? 20:04
should we have a cron job for make html?
Coke if we're going to put the docs on the site, we should have version #'d docs. 20:05
have one for daily updates from trunk; have one that corresponds to the last devel and last stable release. 20:06
particle yes, agreed 20:08
Coke even just having trunk for now works, just need to make sure we leave a space for devel/stable 20:09
if there's a space we could ftp the files to, we can setup a cron job on feather. 20:10
particle: one down. 20:13
dalek r34284 | coke++ | trunk (5 files):
: Eliminate [DEPRECATED] runtime/parrot/library/Parrot/Capture_PIR.pir
Coke here's something: experimental.ops should probably be empty at 1.0
dalek : was only referenced by one language, but it wasn't being used.
review: xrl.us/6v5ny
particle looks like we can delete some non RELEASE_ tags... svn.perl.org/parrot/tags/ 20:19
i hoped that "make release" included the html docs, but it seems it does not
which means we can't just pull them from the release tarballs :(
however, we can set up a dir at ftp.parrot.org for uploading docs 20:20
ftp-osl.osuosl.org actually 20:22
20:33 chromatic joined 20:34 Aisling joined
dalek r34285 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files): 20:49
: [jit_h_files] move functions from the first part of the .h file to the .c file, along with a few duplicated macros. Compiles.
review: xrl.us/6zm6w
Whiteknight we can change make release to include the docs/html targets 20:50
Coke chromatic: any gotchas ripping out PIC? 20:51
(and/or the ops that rely on it?) 20:52
chromatic You break all predereferenced runcores. 20:53
Other than that, none.
I think you break JIT too.
Coke ah. breaking jit is bad, since I can't fix it.
perhaps a branch on this one 20:54
Whiteknight branch++
dalek r34286 | coke++ | branches: 20:56
: RT #60048. - remove polymorphic inline cache.
review: xrl.us/62eie
Coke chromatic: pic.ops should also go, neh? 20:58
chromatic I think that can go safely.
Coke sees a bunch of references to PIC lying about in t/conf* tests.
chromatic That's probably the -fPIC flag for cc. 20:59
Whiteknight later
Coke chromatic: ... no, sadly. 21:00
things testing ops generation that happened to refer to pic.ops.
dalek r34287 | chromatic++ | trunk (4 files): 21:02
: [ops] Removed deprecated add_io_event opcode.
review: xrl.us/62toq
chromatic So much for the triumph of hope over experience.
dalek r34288 | chromatic++ | trunk/config/auto: 21:03
: [config] Added -funit-at-a-time to GCC flag detection to avoid inlining
: warnings on GCC 4.3.x.
21:03 jan joined
dalek review: xrl.us/62wqr 21:03
Coke ... PIC has lots of hooks everywhere. 21:04
chromatic What doesn't?
Some of these features look like abstraction and encapsulation got drunk and vomited all over our source code.
Coke is amazed how much of this code he has touched without understanding what it does. 21:07
"remove B. build. does it compile? repeat."
i haz a parrot that builds. running make test... 21:10
remove pic is requiring deleting a LOT more than the two *.c files mentioned in the ticket. 21:11
*removing
chromatic Yep. 21:12
Coke only 5 test failures in 'make test'. 21:16
chromatic Now try make testC
Coke committing first. 21:17
dalek r34289 | coke++ | branches/remove_pic (15 files): 21:18
: First machete hack at removing PIC. 5 failures in 'make test':
: t/pmc/packfile (Wstat: 512 Tests: 11 Failed: 2)
: Failed tests: 7, 9
: t/run/options (Wstat: 768 Tests: 26 Failed: 3)
: Failed tests: 22-24
review: xrl.us/64x3v
r34290 | chromatic++ | trunk/src (2 files): 21:19
: [JIT] Added checks for the return values of some system calls when writing
: stabs files.
review: xrl.us/64yrd
Coke I am not sure testC works on osx/intel anyway. does it?
hurm. somewhat. 21:20
chromatic It should. 21:21
dalek r34291 | coke++ | branches/remove_pic/t/pmc: 21:22
: don't expect PIC anymore.
: He's gone to live at the farm.
review: xrl.us/642gh
r34292 | coke++ | branches/remove_pic/src: 21:24
: eliminate some PIC that otherwise borks 'make testC'
review: xrl.us/6445b
Coke running 'make testC' now; at least some tests are passing...
(no failures yet.)
do have a hang, though. 21:25
chromatic I'm not surprised. 21:26
You're probably not getting parameters in a function. 21:27
dalek r34293 | chromatic++ | trunk/src: 21:28
: [src] Improved casts of functions loaded through Parrot_dlsym(). See RT
: #61038 (reported by Jarkko Hietaniemi).
review: xrl.us/65bcz
r34294 | coke++ | branches/remove_pic/compilers/imcc: 21:29
: remove apparently (now) unused struct member
review: xrl.us/65d6m
Coke ok. I'm done with remove_pic for the next short while if someone wants to play cleanup. 21:30
(that's about the limit of what I can remove without being forced to understand what I'm doing.) 21:31
chromatic Is make testC totally broken?
How about make testg?
Coke testC runs about 4 test files to completion before hanging. 21:32
21:33 Aisling joined
chromatic Figured. 21:33
Coke testg gets further.
chromatic Removing the PIC files altogether relegates just about every other runcore to the scrap heap of history.
Coke ... was that an expected result of removing src/pic.c ? 21:34
it certainly seems to mesh with earlier discussions about removing things we don't use.
chromatic That's what I meant when I said "You're going to break every predereferenced runcore if you do that." 21:35
Coke Yes, but is that a problem?
I'm happy to rip out code. =-)
if you want to add a note to the ticket about which runcores this obviates, I can make an effort to kill them in the branch.
(assuming this is the desired direction) 21:36
testg seems to be fine, btw.
chromatic We haven't deprecated any runcores yet.
Coke but it follows logically from removing PIC, neh?
If so, then lets get a ruling and throw it on the heap for removal right after january. 21:37
chromatic Only because the PIC implementation sucks in terms of encapsulation.
Coke ok. I don't have the brainz to fix it, just to kill it.
chromatic No one else understands it either. 21:39
Someone's going to have to dig into it and play around with it to do anything other than delete it.
21:39 ask_ joined
chromatic That doesn't have to be me. In fact, it would be really nice if it weren't me. 21:39
Coke if we're talking about potentially eliminating other runcores, let's just rm it all.
If no core committers have the time to maintain this, and we have a bunch of stuff to do before 1.0... 21:40
chromatic And it's not like the code is brilliant or clean enough that it's worth keeping around either.
Alright, I'm convinced. 21:41
Coke Could you write up a note to the list with a list of which cores would be affected by this?
I can rip them all out in branch, which can then land after the january release. 21:42
chromatic Everything other than the default core, the nearly-useless profiling core, and the gc-debug core.
I'm not sure about the JIT core.
Coke well, I'd hate to break JIT, you know?
(even though I can't use it myself.)
ok. Given that, I'll write something up. 21:43
chromatic The JIT core doesn't really help us now.
dalek r34295 | chromatic++ | trunk (2 files):
: [src] Fixed function decorations on unimplemented encoding functions to
: demonstrate that they really do not return now.
review: xrl.us/67cco
Coke is there JIT in the regular core? 21:44
chromatic On supported platforms, we use JIT to generate NCI thunks, rather than relying on the contents of src/nci.c.
Coke I'm not sure what that means, exactly, but it sounds like we can live without -j then. 21:45
chromatic We use JIT in the default core on certain platforms, but the JIT runcore doesn't add a lot. 21:46
It's messy, difficult to maintain, undocumented, and incomplete.
21:53 kid51 joined 22:02 Whiteknight joined
GeJ Good morning everyone 22:07
22:07 TiMBuS joined
chromatic Any objections to making Parrot IO PMCs upgrade to buffered mode when you peek on them? I have a working patch. 22:08
dalek r34296 | Whiteknight++ | branches/pdd09gc_part1 (2 files): 22:11
: [pdd09gc_part1] add the new GC to the makefile, and add it as an option to src/gc/memory.c
review: xrl.us/7at9t
chromatic Can any Windows hacker run t/src/compiler.t without the skipall and tell me if we've fixed our linking problems? 22:14
nopaste "particle" at 76.121.106.245 pasted "rakudo spectest failure summary" (8 lines) at nopaste.snit.ch/15080 22:15
particle chromatic: i'll take a look now
dalek r34297 | chromatic++ | trunk/t/src:
: [t] Removed a test of imcc_compile_pir() as Parrot_compile_string() does a much
: better job and we already expose that anyway. See RT #61154 for the
: motivation.
review: xrl.us/7ay6r
chromatic particle, how about also t/dynpmc/foo.t ? 22:18
particle i need to reconfig/build head first, but it's in the queue 22:19
chromatic Thanks. I'm reviewing untouched tickets now. Closed 2. 22:20
Have a patch for one, depending on if we can convince allison it's a good idea (which it is).
particle buffering stdin? 22:21
oh, any io
chromatic Exactly. 22:22
particle i've got a number of build warnings, some of which are probably easy fixes. wanna ticket? 22:23
chromatic I see a bunch of warnings too (building with -O2). Let me start cleaning mine up, then I can work on yours. 22:24
particle ok, i'm linking now. 22:25
# compiler_5.obj : error LNK2001: unresolved external symbol _PMCNULL 22:26
still haven't resolved link errors on windows 22:27
chromatic I thought we exported PMCNULL. 22:28
Maybe we need the PMC_is_null() function there.
particle PMC_IS_NULL() is used in those tests 22:29
chromatic Swap that for PMC_is_null() and see if that helps. 22:30
particle same error, all tests 22:31
chromatic That's strange. 22:33
See include/parrot/interpreter.h:891.
Is that not the case on your machine?
particle #define PARROT_CATCH_NULL 1 22:34
#if PARROT_CATCH_NULL 22:35
PARROT_DATA PMC * PMCNULL; /* Holds single Null PMC */
i'll try adding PARROT_EXPORT to that 22:36
chromatic Yes, but the source code of the test doesn't refer to PMCNULL at all.
dalek r34298 | Whiteknight++ | branches/pdd09gc_part1 (7 files):
: [pdd09gc_part1] fix makefile, make headerizer, add a few macros, and a few small changes to get this bad boy to compile
review: xrl.us/7cw4k
particle #if PARROT_CATCH_NULL
# define PMC_IS_NULL(pmc) ((pmc) == PMCNULL || (pmc) == NULL)
chromatic Is that outside of the PARROT_IS_CORE guard? 22:37
Doesn't look like it. 22:38
particle 'tis not, indeed. 22:41
nopaste "donaldh" at 213.123.171.12 pasted "crash backtrace from perl6 code - recursive fail_if_type_exists for "Grammar"." (337 lines) at nopaste.snit.ch/15081 22:51
donaldh Not sure if my GC crash is actually a GC crash. Looks more like Rakudo misbehaving and causing GC to crash. 23:00
particle what's the source look like? 23:01
diakopter greek?
purl greek is probably nice too, I hear. or illlegible to idiots who can't read Greek. or illegible to geniuses who can't read Greek or greek to me
23:07 bacek_ joined
nopaste "donaldh" at 213.123.171.12 pasted "p6 source causing crash" (12 lines) at nopaste.snit.ch/15082 23:10
23:28 Theory joined 23:29 Zaba joined
dalek r34299 | chromatic++ | trunk/include/parrot: 23:30
: [include] Removed a trailing comma in an enum, which picky C compilers hate
: (reported by Jarkko).
review: xrl.us/7im2p
donaldh Hmm. Bad memory profile for rakudo. A piece of PIR that runs a SQLite query and prints ~18000 rows maxes out at 6MB when run with -G. The equivalent in Rakudo maxes out at 1.6GB 23:40
s/maxes/tops/ 23:42
23:43 particle left
chromatic PGE/PCT/Rakudo use more STRINGs and PMCs. If you disable garbage collection, Parrot won't reuse them. 23:44
donaldh Sure. I'm just realising how much pressure Rakudo is putting on GC. 23:45
dalek r34300 | chromatic++ | trunk/src: 23:57
: [src] Switched some bzero() system calls to use memset(), as the former is
: deprecated. While doing so, cleaned up some potential memory overflows thanks
: to the wrong type used in a macro, and tidied some code.
review: xrl.us/7na7g
pmichaud rakudo is somewhat constrained by the architecture Parrot provides, unfortunately. 23:58
dalek r34301 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST: 23:59
: [pct]: Switch 'for' to use loop_gen code.
review: xrl.us/7nmhp

Powered by Cro and the Raku® Programming Language.

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

Thank you!