Topic for #parrot is: Parrot 1.2.0 released | parrot.org/ | Weekly Priority: Testing for 1.3.0! | Parrot VM Workshop, Pittsburgh, June 20-21
Set by moderator on 14 June 2009.
00:01 ruoso joined 00:02 ruoso joined
dalek rtcl: r491 | coke++ | trunk/lib/Parrot/Test/Tcl.pm:
Fix a comment.
 00:05
Infinoid Okay. Any other temp files? :) 00:06
GeJ anyone (other than me that is) experiencing lots of imcc syntax errors with 'perl t/harness t/examples/pod.t' ? 00:12
Coke GeJ: I believe that has been reported. if those errors are in the book, I presume allison and chromatic are working on them. 00:18
you can search trac tickets to see if there's an open one.l
GeJ will do. 00:19
mikehh reported it already. 00:21
So, please feel free to just ignore me and resume what it is that you usually do. thanks. 00:23
Infinoid Once I figure that out, I will do so :) 00:26
Whiteknight GeJ: I'm seeing the same thing 00:30
serious karma to the person who resolves that
00:31 bacek joined
Infinoid Whiteknight: Are you working on NEWS yet? 00:32
Coke Whiteknight: really? it's a trivial fix, at least to mark the tests as TODO.
I'll take care of it.
dalek rtcl: r492 | coke++ | trunk/ (24 files):
Eliminate the helper .sub toList - instead, use the .getListValue() METHOD
 00:34
Coke Whiteknight: done. 00:41
well, "test passing", anyway. =-) 00:42
you still get the annoying output. =-)
but the test passes.
dalek rrot: r39566 | coke++ | trunk/docs (2 files):
pass the t/examples/pod.t by TODO'ing or fixing some sample PIR code.
Coke to get rid of the output will require slightly more work.
Infinoid fsvo "slightly" 00:43
(there's a lot of it, and there are a lot of other pir examples already todoed)
coke++
00:44 mikehh_ joined
Coke since we have pir_error_like, I imagine we could use an existing test function to grab that output and make sure it was empty. 00:45
(but not report it if the test was TODO'd)
ah. I cheated when I wrote that test, and didn't use any of the builtin test functions. 00:46
I am just doing system(parrot -o /dev/null foo.pir)
Whiteknight Coke++ # Awesome! 00:50
Infinoid: I was hoping some other developers would chronicle their own exploits in NEWS
but, it seems I had hoped wrong
Infinoid Whiteknight: Yeah. I'd get a head start on it if you can - I spent 4 hours on it for 1.2.0 and it felt ... rushed 01:02
(clicking "Next Revision" over and over in trac)
Whiteknight I was going to use TortoiseSVN on my work computer, it has a really nice log interface 01:03
but yeah, I'll get started on it tomorrow
(people not updating NEWS)--
Infinoid cool. 01:04
01:04 mikehh_ joined
Infinoid I had trouble deciding exactly where the line in the sand should be drawn, with regards to what importance level should be deemed newsworthy 01:04
so I sorta just followed the previous releases' lead 01:05
bacek wonders what he can put in NEWS 01:09
Infinoid The branch merges tend to be the most noteworthy 01:11
01:11 mikehh_ joined 01:12 Andy joined
Coke nice. some of those PIR examples are causing segfs. 01:13
Whiteknight bacek: Anything you want. Just put something in NEWS 01:15
I don't care what
Coke and Infinoid: You guys too. Do it now!
update NEWS!
Infinoid erm. Did I do anything this month? 01:17
Coke Whiteknight: ... I have pretty much been working on partcl. 01:18
Whiteknight, Infinoid: fixed t/example/pod.t to be much less verbose. now YOU get to fix the very visible segfaults. =-)
dalek rrot: r39567 | coke++ | trunk/t/examples/pod.t:
Instead of spewing stderr to the screen, save it, and verify that it's 0.

showing the error for those expected to pass. BTW - when I run this, 3 of the sample PIR files are segfaulting; they should be hunted down and fixed.		 01:19
Infinoid Whiteknight: I cleaned some cages, nothing newsworthy. The performance improvements are already mentioned 01:21
I spent a lot of time on planes this month... not much parrot time
Hmm. TT #726 got warnocked, which is too bad, it's a significant performance improvement 01:23
That and r39414 speed up Hash allocations 01:24
Whiteknight which was #762? 01:25
Infinoid #726 chops the number of malloc()s for a hash creation in half
I dunno #762
Whiteknight oh wow 01:26
Infinoid I posted it as a ticket because I didn't have time to review it thoroughally... and that hasn't changed since 01:27
Infinoid putting together an expense report for moving to delaware right now... such fun 01:28
Whiteknight Infinoid: #726 has a +1 from me
and it doesn't cause any test failures?
Infinoid No failures. I haven't checked it for leaks yet tho
dalek rtcl: r493 | coke++ | trunk/ (4 files):
Move the String overrides into their own class file.
Whiteknight if it were a few days earlier I would say to just dump it into trunk. But so close to the release, don't do it unless you're sure it's good 01:29
Dump it to trunk on tuesday afternoon :)
Infinoid Yeah, will do. I've still got it in my local patch stack anyway, hoping for some time to run valgrind on it tomorrow 01:31
dalek rtcl: r494 | coke++ | trunk/ (4 files):
move TclList.getListValue() into PIR.
 01:33
bacek found only one thing worth putting in NEWS - TT#452 01:34
Whiteknight bacek: There are no small commits.
(only small committers) :)
Infinoid (like me) 01:35
bacek (..)
O
o
.
bacek disappears
Infinoid ohnoes
Whiteknight ENOBACEK 01:36
bacek :)
Ah. Packfile PMCs are useful now. "Someone" can put it in NEWS.
Whiteknight if (someone == bacek) { bacek,can_do_it(); } 01:37
are the packfile PMCs actually being used, or are they just a novelty? 01:38
Infinoid The next step is to make the rest of the system use them
dalek rtcl: r495 | coke++ | trunk/ (3 files):
move TclList.'reverse'() into PIR.
bacek Whiteknight: no way. Or you'll get something like - "Old crappy PMCs for Packfiles was greatly improved. They are shiny now and can be used for generatinc PBCs"
Infinoid And after that, we can start getting rid of that old and nasty src/packfile.c code 01:39
Whiteknight is there a schedule for that work?
that would be great to have pre-1.4
Infinoid Not likely. Big task, short on tuits
Whiteknight who'se the teamleader on that project?
Infinoid I guess I am, as bacek has assigned the ticket to me again 01:40
But I normally just defer to jonathan or allison when someone asks me questions
bacek btw, tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk shows t/pmc/packfile.t failure on freebsd. Probably regenerating native PBCs will fix it.
Infinoid (again? I've already done that, what, 3 times now?)
Whiteknight Infinoid++
bacek PBC format is too fragile... 01:41
Infinoid Yes. PBC is insufficiently P
Whiteknight What would need to get done to make it more robust, I wonder?
a more informative header?
bacek different strategy for store them. 01:42
Whiteknight okay
Well, any major PBC format changes that don't get done before 1.4 will have to wait until 2.0 I think
Infinoid Yeah, it's a mess and it won't go away any time soon 01:43
Although... tossing a simple lookup table of op/pmc names and values would go a long way to improve forward compatibility of these things
Whiteknight so many systems are a mess still
Infinoid: I was thinking the same thing
Infinoid ^into the file
Whiteknight although you end up with problems when ops are deprecated and disappear from core 01:44
Infinoid Well, now you have a means of detecting it and can toss an exception only in that case
...rather than just invalidating *everything*
Whiteknight yeah
Infinoid Now, changing APIs of existing stuff... that's a bigger problem.
bacek simple solution: don't renumber ops.
Whiteknight we could probably "borrow" some of the predereferencing code to renumber PMCs and Ops from the packfile on the fly 01:45
bacek Assign enum_class_Foo values explicitely
Infinoid bacek: The last couple of PBC_COMPAT bumps didn't renumbered ops, they just added a couple of new PMCs
s/renumbered/renumber/
Whiteknight bacek: That's quite an interesting idea, but we still run into problems where a type disappears
bacek which cause enum_class_Foo renumbering
Infinoid So, what then, you propose assigning them by hand? 01:46
bacek Whiteknight: if type disappear we can throw exception on load.
Infinoid: exactly
Infinoid Then you end up with numbers you can never reclaim
Whiteknight okay, I am heading to bed nowish. Goodnight 01:47
Infinoid I think I prefer the lookup table embedded in pbc file idea
night Whiteknight
Tene Looks like chromatic was the last person to touch the internals I'm trying to deal with right now.
bacek Oh... 2^32 has enough numbers
Infinoid (why does that sound like a tongue twister?)
Whiteknight goodnight
Infinoid bacek: And we're volunteering you to maintain that list, on demand, forever and ever. :)
Tene and creiss
Infinoid (rather than letting the computer do the things it's good at :))
bacek we already maintaining it. 01:48
Tene most of it hasn't been changed since 2006 or 2007
Infinoid bacek: Putting in the lookup table will reduce the amount of maintenance overhead
bacek (not for PMC)
Infinoid: really?
Lookup from what to what? 01:49
Infinoid pbc op numbers to parrot op names, pbc pmc numbers to parrot pmc names
bacek what about passing freezed PMC to another instance of Parrot over network? 01:50
from my pov is better to store PMC name in freezed format 01:51
And we have "pmc_type" to deal with it 01:52
Infinoid What about it? 01:53
When you load an ELF object, you do the link and everything works
This is the same sort of thing
bacek exactly. 01:54
So just store PMC name instead of type.
call "pmc_type(interp, name)" on thaw.
...
Profit!
Infinoid You'd need a type placeholder in the opcode array, to replace at runtime
That's the numeric component of the lookup table
bacek I don't get it... 01:55
Infinoid I'm proposing having an ELF-style relocation list, but the implementation details aren't important
Decoupling ops/pmcs from their numbers will solve a lot of problems, no matter how we do it.
davidfetter hello 02:07
purl que tal, davidfetter.
Util good evening
davidfetter can rakudo build against a pre-installed parrot, and if so, what version(s)?
bacek davidfetter: You'll need a time machine to achieve this :) 02:10
davidfetter ugh
with a time machine, there's all kinds of things i'd do, very few having to do with computers ;)
bacek :) 02:11
davidfetter is putting this capability back on anybody's roadmap? 02:12
Util current recommended practice is not just to use a non-installed parrot, but to use a particular version (which changes frequently) of parrot that rakudo builds itself (by using Configure.pl --gen-parrot).
It is high on the roadmap
(well, that is from memory; I do not actually see it on the roadmap report) 02:13
bacek Don't smoke roadmap!!!
davidfetter well, it's safer than shooting roadmap
Util davidfetter: clarifying - I *think* that, in the past (3 months), making languages (Rakudo and partcl) work from an installed Parrot has been a priority, including roadmap. Several tickets addressed parts of the issue, and are closed now. However, after this was working (for some definition of "work"), the functionality has drifted. 02:23
In the last #ps meeting ( irclog.perlgeek.de/parrotsketch/2009-06-09 ), pmichaud reported this among his items of work from the last week: "Fixing Rakudo to work from installed Parrot".
END_BRAIN_DUMP 02:24
davidfetter thanks for the info :)
Util glad to help 02:26
Util ==> bed; 'night, all
davidfetter g'night, Util 02:29
Infinoid As long as he doesn't break running from a non-installed parrot, I'll be happy
(and I'll be happier if tcl runs from a non-installed parrot, too, because then I can test it)
goodnight all 02:30
davidfetter g'night, Infinoid 02:49
Coke hurm. my 'reverse' method is not working in PIR. 02:55
ah, because I'm an idiot. 02:56
dalek rtcl: r496 | coke++ | trunk/t/cmd_lreverse.t:
Check even and odd length lists
 03:01
03:04 mikehh__ joined
dalek rtcl: r497 | coke++ | trunk/src/class/tcllist.pir:
actually make 'reverse'() work.
 03:10
Coke how to override a PMC vtable from PIR? 03:13
(just declaring it in the namespace isn't sufficient.)
03:17 amuck joined 03:20 donaldh joined 03:42 xenoterracide joined
xenoterracide what installs nqp? I seem to have parrot otherwise installed... but that doesn't seem to be installed 03:43
Coke I am not sure it gets installed. one moment. 03:52
you could try 'make install-dev' 03:53
(I seem to have it installed on my dev box, and that's what I use.)
(ends up in lib/parrot/1.2.0-devel/languages/nqp/)
I'm getting a class not found on "root_new ['parrot'; 'TclList']", having just switched it to a PIR class from a dynpmc. any clues? 03:55
xenoterracide interestingly I have build errors (odd that I didn't have them the last time I built 1.2) 03:57
privatepaste.com/fd1uQnM790
Coke: hmm... from the prebuilt binary I have installed that directory and files exist... but I don't have an executable in my path 04:00
Coke xenoterracide: those look like references to ICU. 04:01
xenoterracide has an icu package installed and the headers should be there... hmm... 04:02
Coke: is the executable for nqp lib/parrot/1.2.0-devel/languages/nqp/nqp ? 04:04
Coke there is no executable, I think, just a .pbc file 04:08
xenoterracide hmm 04:09
Coke so then /path/to/parrot nqp.pbc
xenoterracide hmm 04:11
introductory docs may be a bit off
are there any books about parrot that reference 1.0? (or greater)? 04:19
Coke in progress. 04:21
the docs/book/ directory is as close as we have atm.
two folks on the board are working on writing/editing it, hopefully in time for a dead-tree version at YAPC::NA. 04:22
xenoterracide hmm 04:23
cool
seems that the getting started doc suggests running nqp test.pir and that does work. so I've got nqp installed... would I just run it with parrot then? 04:25
Coke TT #218 is now blocking several hours of work I just put into partcl. :|
xenoterracide s/does/doesn't
Coke if it's suggesting ./nqp, try /path/to/parrot /path/to/nqp.pbc
xenoterracide ah 04:26
that whole page seems to have quite a few bugs
mostly I think formatting code that's being displayed
ah well
I think I'm gonna go get food now
Coke xenoterracide: are you using perldoc to read the doc? 04:27
easiest way to read the book at the moment is: 04:28
docs.parrot.org/parrot/latest/html/...n.pod.html
(though that's from the 1.2 release, not svn)
bacek Coke: (vtable in PIR) did you try mark them as :vtable ? 04:29
Coke bacek: ... yes
bacek: I got around it by converting the whole (&*#$ PMC to pir.
xenoterracide well I'd suggest that it's chapter 2 that's bugged ;) 04:30
bacek PIR ftw! 04:35
Coke bacek: except for TT #218. 04:38
bacek Coke: sorting of RPA?...
Coke <nod> 04:39
I was switching my array-like PMC over. =-)
so now all my sorts explode.
bacek oh shi... 04:49
Coke bacek: evil workaround: $P0 = new 'RPA', assign $P0, my_list; $P0.'sort'() ; assign my_list, $P0 05:02
bacek yeah... But this can be removed right after 1.4 afaiu 05:08
dalek rtcl: r498 | coke++ | branches/convert_tcllist:
Try to eliminate the tcllist PMC and replace it with a PIR class.
 05:12
rtcl: r499 | coke++ | branches/convert_tcllist/ (5 files):
First pass at eliminating the the TclList PMC and using a class instead.
05:41 chromatic joined
Coke chromatic: evening. 05:52
purl it has been said that evening is when IRC is dead, TV is laden down with ads, and you're having my own dinner.
chromatic yes 05:54
dalek rtcl: r500 | coke++ | branches/convert_tcllist/runtime/builtin/namespace.pir:
Avoid TT #218 again.
 05:56
Coke gets the dreaded "Object must be created by a class." error. 05:57
chromatic: I think I just got 'make test' passing again with a pure-pir tcllist. 06:07
will give a spec test run to see if there's a speed improvement. 06:08
06:08 eternaleye joined
chromatic Very nice. 06:11
dalek rtcl: r501 | coke++ | branches/convert_tcllist/src/ (2 files):
These uses of TclList generate a "Object must be created by a class" error now.

With this, 'make test' now passes in branch.
06:13 uniejo joined 06:20 xenoterracide left 06:57 kyle_l5l joined, c0tt0 joined
cotto hi 07:02
bacek seen Andy 07:03
purl Andy was last seen on #parrot 5 days, 8 minutes and 8 seconds ago, saying: ok beditme for me. [Jun 10 06:51:34 2009]
07:18 barney joined 07:21 donaldh joined
Coke chromatic: slight improvement in speed, but I regressed on some test files: 07:22
"2009-06-13 06:08",483,"r39529",67,5145,2972,1352,821,4374
+"2009-06-15 08:12",498,"r39537",62,4792,2763,1222,807,4129
chromatic The regression is odd. 07:23
Coke looks like a reduction in tests/second, but it's hard to tell how far each of those 5 failing tests got before dying.
chromatic: given that classes are not drop in replacements for PMCs, not really. 07:24
chromatic They ought to be.
Coke and that's assuming I didn't screw up the C to PIR translations.
chromatic: they're not. =-)
TT #218, for example.
once I had a mostly function PIR version, I still had to make other changes elsewhere in the code to deal with it. 07:25
also: code.google.com/p/partcl/source/detail?r=501
chromatic C versus PIR strikes again. 07:26
Coke so, I'll have to fix those regressions before I can get a real speed compare. so far looks "slightly better." 07:27
another way: overriding :multi vtable entries.
afk_coke (oi) 07:28
07:31 viklund_ joined 07:37 clinton joined 08:11 cognominal joined 08:43 gaz joined 08:48 viklund_ joined 09:15 DanielC joined 09:30 mikehh_ joined
nopaste "mikehh" at 90.209.69.154 pasted "patch to fix docs/pdds/pdd19_pir.pod" (60 lines) at nopaste.snit.ch/16916 09:36
mikehh docs/pdds/pdd19_pir.pod failed t/codingstd/pod_syntax.t - fixed that but then failed examples_tests agin - now also fixed by patch 09:39
passes codetest and examples_tests with patch nopaste.snit.ch/16916
also fixed html 09:40
looking at TODO passes in t/op/debuginfo.t 09:42
barney applied patch in r39568
dalek rrot: r39568 | barney++ | trunk/docs/pdds/pdd19_pir.pod:
Better annotation of PIR examples
 09:44
mikehh barney: thanks muchly 09:45
barney he, eays karma for me 09:46
s/eays/easy/ 09:52
09:56 gaz joined 10:27 whoppix joined 11:07 burmas joined
mikehh how do you run a specific test in a given runcore - I think I have fixed t.op.debuginfo,t but need to test and don't want to run fulltest yet 11:10
moritz mikehh: perldoc t/harness
mikehh I did a prove t.op.debuginfo,t and that works but need to test the other runcores 11:11
ok I'll look
11:13 iblechbot joined 11:15 burmas joined 11:21 donaldh joined 11:34 szbalint joined 11:40 skids joined 11:51 bacek_ joined
mikehh got t/op/debuginfo.t TODOs fixed in everything but the -g core Test 8 ok 11:52
ok I think that works now 12:04
going to run codetest etc will post patch for t/op/debuginfo.t in a bit 12:07
got to go to the store - will run tests
12:11 ruoso joined 12:15 Whiteknight joined 12:26 AndyA joined 12:28 DanielC joined 12:41 elmex joined
Whiteknight bacek: ping 12:56
purl msg bacek Can you write about some of your annotations-related work in NEWS? 13:00
purl Message for bacek stored.
13:00 burmas joined 13:03 gryphon joined
dalek rrot: r39569 | whiteknight++ | trunk/NEWS:
[NEWS] Add a preliminary selection of news items from the past month, based on my understanding of short, oblique SVN log messages
 13:04
bacek Whiteknight: "+ Initial version of Packfile PMCs with read/write capabilities" 13:06
"+ Support for 'self' in NQP"
Whiteknight that was your annotations work? 13:08
afk_coke I want "lexical trace mode", so I can say "make this .sub have verbose tracing, but disable it whenever I leave the sub."
Coke (whenever you use PGE, it's mandatory. :|) 13:09
bacek Whiteknight: I did nothing with annotations. It probably was Tene and jonathan.
Whiteknight bacek: r38965 "Merge branch tt504_annations" 13:10
dalek rrot: r39570 | whiteknight++ | trunk/NEWS:
[NEWS] Added two items for bacek++
 13:11
bacek yeah. It was PackfileAnnotations :)
Whiteknight ah, okay
nopaste "mikehh" at 90.209.69.154 pasted "PATCH to correct TODO PASSes in t/op/debuginfo.t" (45 lines) at nopaste.snit.ch/16917 13:15
mikehh the patch passes all tests - no extra TODO passes 13:16
Whiteknight wow, nice work
mikehh++
mikehh codetest etc passes
if fact with that patch make fulltest passes 13:17
Whiteknight are you a committer?
mikehh no
I just hope there are no probs on other paltforms 13:20
I am running Ubuntu (.04 i386 13:21
9.04
Whiteknight I'm on 9.04 x86_64, so can't help much with diversified testing
dalek rrot: r39571 | barney++ | trunk/t/library/p6object.t:
Add test for registering a parrotclass.
 13:25
13:34 buildbot joined 14:03 PacoLinux joined
Coke remembers to run fulltest with TEST_JOBS this time. 14:12
no love on pbc_to_exe, huh?
wow. I am getting a TON of fulltest failures. 14:14
nopaste "coke" at 72.228.52.192 pasted "failures on os x/x86" (38 lines) at nopaste.snit.ch/16920 14:15
14:15 burmas left
Util Coke: which aspect of pbc_to_exe are you referring to? 14:21
mikehh coke: my patch should at least fix the first one - nopaste.snit.ch/16917 14:25
sorry
Coke: my patch should at least fix the first one - nopaste.snit.ch/16917 14:26
Whiteknight Coke: Don't say that! fulltest was running perfectly for me a few minutes ago
14:28 davidfetter joined
Coke Util: there's a ticket.. 14:37
code.google.com/p/partcl/wiki/ParrotIssues -> trac.parrot.org/parrot/ticket/691 14:38
Whiteknight: it's failing for me drastically on os x/x86
Util coke, thanks 14:39
Whiteknight shit, I'm getting failures now in t/op/trans.t
Coke /drastically//
Whiteknight bacek: ping 14:41
purl msg bacek I'm getting some failures in t/op/trans.t, could r39565 or r39538 cause that? 14:42
purl Message for bacek stored.
Whiteknight Coke, what is failing specifically?
Coke Whiteknight: feather.perl6.nl/~coke/fulltest.txt 14:44
(that's darwin)
no new failures on partcl...
Whiteknight: linux looks fine... 14:45
Whiteknight urg 14:46
Coke Whiteknight: I don't run fulltest often; no clue when those were introduced. 14:47
I can probably give someone remote access to the box in question.
mikehh whiteknight: don't fail for me at r39567/8
Whiteknight I don't have any time now to do any remoting myself 14:48
pmichaud Good morning, #parrot 14:50
mikehh hi
davidfetter OH HAI
purl bonjour, mikehh.
Coke pmichaud: thanks for your input this weekend. couldn't override :vtable in PIR on a PMC, so I ended up just converting the whole PMC to PIR. 14:52
bacek Whiteknight: pong 14:53
Coke (which caused a few wierd spec test regressions I'm hunting down, but is otherwise going ok)
pmichaud Coke: glad to help.
Whiteknight bacek: I sent you a few messages
hello pmichaud
bacek Whiteknight: can you nopaste failures? 14:54
Whiteknight nopaste?
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
moritz make fulltest pass on linux/amd64 with --optimize
nopaste "whiteknight" at 66.252.102.37 pasted "test failures for bacek++" (32 lines) at nopaste.snit.ch/16921 14:55
Coke does PIR support SUPER? 14:56
Whiteknight yeah, I had a successful fulltest last night on that platform, although I didn't optimize
Coke: no
there is a way to do it, but it involves the PMCProxy and it's a mess
14:56 PerlJam joined
Coke oh, right. I'm already using that trick. Thank you. 14:57
Whiteknight no prob
bacek Whiteknight: oh. platform and Configure.pl flags? 14:58
Whiteknight Win32, no configure flags
Strawberry Perl 14:59
purl hmmm... Strawberry Perl is found at strawberryperl.com/
bacek msg mj41 Can you add just Win23 into TapTinder?
purl Message for mj41 stored.
15:04 Theory joined
bacek Whiteknight: can you tweak test to output N2? Line 245, right before "print not" 15:05
Whiteknight it didn't fail when I did that. Let me rerun the tests 15:10
bacek Btw, I've got failure in t/pmc/pmc.t. Didn't see it yesterday. 15:11
Is Win32 jit capable?
Whiteknight yes
I can't duplicate the failure outside of make testj, which is weird 15:13
bacek May be this is a problem. Some of those tests marked with @jittodo. Some of them - not. But technically - all this functions are very similar. 15:14
Whiteknight bacek: The value is NaN in make testj 15:16
bacek hrm... 15:17
but... It's not parsing floating point. Second part is for "tanh N2, I1"... 15:19
So it's just "N2 = tahn 1". And I bet that "1" parsed correctly!
15:20 donaldh joined
bacek We need jit expert to fix it. 15:21
o wait...
Coke pmichaud: wierd. $P0 = 5 (when a PMC), then $P0[0] was returning ""; now it's returning NULL. 15:23
(so am cheating by overriding the get_string_keyed_int vtable to convert it for me.
bacek Whiteknight: trac.parrot.org/parrot/ticket/530#comment:2
pmichaud Coke: that sequence doesn't make sense to me. 15:24
15:27 donaldh left
Coke if I pre-extend a list to size FOO; and then ask to stringify the list, I walk through the elements, asking for the string value of each one (and potentially modifying it for display). When my list was a PMC, an element existed due to the extension (but had never been set), returned an empty string. 15:29
now that it's PIR, I have to override the "give the string representation of the Nth element" to return the empty string where it would otherwise be the NULL string.
One wonders why I'm pre-extending a subclass of RPA, though. =-) 15:33
pmichaud oh, so you're using $P0 = 5 to pre-extend the list. 15:34
okay, I'm used to doing that with 'assign' instead of 'set'.
normally RPA returns "" for any unset elements of an array.
(if asking for a string)
Coke right.
my subclass was returning null.
(class vs. dynpmc) 15:35
15:35 Andy joined
pmichaud it's not inheriting what RPA does? 15:35
oh, src/pmc/fixedpmcarray.pmc:303 looks bogus. 15:36
compare to line 286.
NotFound pmichaud: Have you looked at my last patch in TT #752? 15:41
pmichaud I looked at the discussion, not the patch. Looking. 15:42
15:44 viklund_ joined
pmichaud looks like we're starting to see the rash of -G failures again. 15:44
nopaste "pmichaud" at 72.181.176.220 pasted "-G failures rear their ugly head again" (34 lines) at nopaste.snit.ch/16922 15:46
pmichaud (note test #6 in the nopaste) 15:47
NotFound: TT #752 doesn't really solve my problem. 15:49
(the patch)
NotFound pmichaud: it pass the test case for me
pmichaud sure, but you have ICU.
NotFound I don't
I'm buliding with debian amd64 without icu right now 15:50
pmichaud oh.
15:50 amuck joined
pmichaud okay, I'll look again. Did you see my note to the list about this issue? 15:50
lists.parrot.org/pipermail/parrot-d...02357.html
I think there's a bug in utf8->to_encoding 15:51
NotFound If fails if I make it to convert to utf16 by default, but I make it to use utf8 for ascii, utf8 and latin1 cases.
pmichaud okay. My patch in the mailing list does the same thing (convert to utf8), but gives me a segfault. Any ideas why? 15:52
NotFound pmichaud: note that this patch always uses to_charset and to_encoding, to be on the safe side.
pmichaud: probably because some code somewhere assumes that utf8 encoding implies unicode charset, and that assumption fails because of other assumptions on other parts. 15:54
%-)
pmichaud well, in the specific test case I give, it's all unicode charset.
(since unicode is a superset of iso-8859-1 and ascii)
so I don't think that quite explains it.
NotFound pmichaud: it is in the real world, but not in parrot code. 15:55
pmichaud Okay. I'm saying that we need to find that bug and fix it.
NotFound iso-8859-1 is charset iso-8859-1 and encoding fixed 8
pmichaud We shouldn't just work around it for this one case. 15:56
NotFound Different charset, different encoding, If you just change the encoding the result is not what other parts of parrots expect.
pmichaud Okay. I'm saying that we need to find that bug and fix it. 15:57
We shouldn't just work around it for this one case.
"working around a special test case" is what led to this point in the first place.
NotFound Then tell people to stop complaining about not being able to do things without icu. 15:59
pmichaud I did do that.
I've been told that requiring ICU isn't an option until July. 16:00
Coke for perl or parrot?
NotFound For rakudo, or for parrot?
pmichaud for parrot.
Coke heh.
pmichaud but the bug we're experiencing is a parrot one, and it's unrelated to ICU.
NotFound pmichaud: then what we do for this month release? Workaround, or nothing? 16:01
pmichaud When will the workaround get taken out?
wait, we're off on a tangent. 16:02
Let me back up.
In the email I sent to the list, I point to a place where there's a known segfault.
There's a segfault that shouldn't be there.
NotFound That depends on what you consider a workaround. Dropping the special case for utf8 can be easily done. Stablishing a permanent and well documented behaviour, I don't know.
pmichaud I have a repeatable test case that demonstrates the segfault.
You're proposing to change my test case so that we don't see the segfault. I claim that's wrong. 16:03
Given that Rakudo is now experiencing segfault-and-gc issues again, I'd like us to be addressing the segfaults.
The segfault I'm seeing is completely unrelated to ICU.
so, to get to your question of "what do we do for this month release".... if the option is "workaround so that a test case passes but leaves the segfault undiagnosed", I'm opposed. 16:04
NotFound pmichaud: Did you mean the segfault when applying the patch you put in that thread?
pmichaud Yes. 16:05
NotFound I'll take a look at it.
pmichaud Changing a string's encoding to utf8 should not result in a segfault.
NotFound pmichaud: but note that the workaround is not for that segfault, but for the concatenation problem that originates all that discussion.
pmichaud: it doesn't segfault for me. It says 'equal' 16:13
Whiteknight the whole mechanics of string encodings still mystifies and frightens me 16:15
pmichaud NotFound: on my system, I get a segfault after the equal. See the mail. 16:19
Yes, I note that the workaround is for the concatenation problem that originated the discussion. However, your workaround ultimately uses the same routine that my post in the email does, which leads to a segfault.
NotFound I'll try in a 32 bit system in a few minutes 16:20
16:20 jhorwitz joined 16:21 Psyche^ joined
pmichaud I do think your patch is more of a correct solution, however, by changing the charsets to match as well. So I think I'll do that in my version and see what happens. 16:21
oh, wait. 16:26
Apparently it's the "debug 1" that is causing the segfault.
eliminating it, or changing it to "debug 0" no longer segfaults.
Okay.
NotFound What debug? 16:27
purl well, debug is 1 to see what => being sent and received 'down the wire'
pmichaud in my test PIR script
I had a "debug 1" in there to make it easier to trace with GCC.
er, GDB.
NotFound Yes, adding that it segfaults for me. 16:29
pmichaud okay.
I'm revising my patch and I propose we use it.
(I'm revising to change charset instead of encoding) 16:30
(or to change both)
nopaste "pmichaud" at 72.181.176.220 pasted "my proposed fix to TT #752" (52 lines) at nopaste.snit.ch/16923 16:31
pmichaud I'm running "make test" now. 16:32
16:33 eternaleye joined
pmichaud actually, I have an even better patch. One moment. 16:33
16:35 eternaleye_ joined
nopaste "pmichaud" at 72.181.176.220 pasted "better fix to TT #752" (55 lines) at nopaste.snit.ch/16924 16:35
NotFound pmichaud: looks good 16:40
16:41 eternaleye joined 16:42 cghene joined
pmichaud I get a couple of failures where it's expecting utf16 results.... just a sec 16:44
NotFound It pass for me, I think because all that tests are skiped when no icu. 16:45
pmichaud correct.
I'm going to update the encoding just a bit more.
NotFound Still segfaults with debug 1 16:47
pmichaud yes, that appears to be a separate issue. I'll add a note to my mailing list post. 16:48
16:50 Sark joined
pmichaud string_cs.t seems to assume that concatenating utf16 should always result in utf16. I'm not sure I agree, but... 16:53
NotFound I think we need more unicode encodings 16:56
pmichaud I'm happy with utf8 and utf16 :-)
NotFound They are variable length. 16:57
pmichaud utf16 is fixed width.
NotFound Is not
pmichaud depends on what you mean by "width"
utf16 has the surrogates that handle things in the upper page blocks 16:58
at any rate, we have at least one more encoding coming, according to the new strings pdd :-)
NotFound The same can be said with utf8 and the 8th bit
17:00 Theory joined
TimToady I do not consider utf16 to be fixed width 17:00
pmichaud fair enough, I agree.
(upon reconsideration) 17:01
TimToady surrogates are evil
pmichaud I completely agree.
I read something in my unicode book that said utf16 was fixed width, but upon reflection I disagree with that.
NotFound pmichaud: It was, a lot of years ago. But it wasn't called utf16 at that time, I think. 17:02
pmichaud the book is the Unicode 4.0 guide. It understood the difference between utf16 and ucs2
moritz UCS-2 is usually said to be fixed-width
NotFound moritz: It is, but it has limited range.
TimToady so does UCS-1 :) 17:03
NotFound The same as iso-8859-1 is a unicode encoding of fixed width with limited range.
And ascii.
17:04 ruoso_ joined 17:05 ruoso_ joined
Coke wonders if/when he should retest partcl after the unicode changes. =-) 17:07
pmichaud finally, all tests pass. 17:17
nopaste "pmichaud" at 72.181.176.220 pasted "patch to fix string concat (TT #752)" (61 lines) at nopaste.snit.ch/16926
NotFound pmichaud: pass for me in amd64, now with icu 17:24
dalek rrot: r39572 | pmichaud++ | trunk (2 files):
[core]: Fix to TT #752 to get concatenation of mixed string types to work.
Coke pmichaud: no core partcl failures with r39572 17:37
(running the spec tests for string/utf handling)
dalek TT #752 closed by pmichaud++: Parrot concatenates iso-8859-1 and utf8 incorrectly 17:39
pmichaud Coke++ # thanks
I'm pretty comfortable with the patch doing the right thing for now. 17:40
It will undoubtedly be revisited/re-implemented when work begins on the new strings implementation.
NotFound pmichaud: agree 17:41
skids when and who is doing the new STRING? 17:42
Coke SFAIK, there is no concrete time line at this time. 17:45
simon cozens had started to spec out the new interface.
skids is he posting/blogging that somewhere? 17:46
NotFound I think that there is a branch with seudocode for some operations.
Coke pmichaud: stringComp.test is ABENDing.
I'll try to figure out if/when it broke. 17:47
skids was that the branch I saw someone say was rather old a few days back?
Coke er, s/if//
NotFound skids: probably yes
Coke last updated in january. never kept up to date with trunk. 17:49
trac.parrot.org/parrot/wiki/BranchDescriptions //Strings
skids thanks.
18:03 sekimura joined 18:09 viklund_ joined 18:13 Theory joined
he_ Hi, folks. 18:15
I'm doing "Testing for 1.3.0", as directed by the title, and ... have a new failure. I'll send a nopaste. 18:16
nopaste "he" at 158.38.152.63 pasted "t/pmc/eval.t test failure stack backtrace++" (106 lines) at nopaste.snit.ch/16927
18:17 chromatic joined
dalek kudo: 0d5221a | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get latest parrot changes.
 18:52
18:55 mikehh_ joined
NotFound he_: What were you executing to get that failure? 18:58
19:20 donaldh joined 19:22 particle joined
dalek kudo: d3185be | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 404 files, 11535 passing, 0 failing
 19:28
kudo: ba09b27 | pmichaud++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
NotFound pmichaud: the segfault in your test is no strings related at all, is a pitfall in the debugger ops.
pmichaud correct.
did I say it incorrectly in my message?
NotFound I have a simple fix for it.
pmichaud (checking)
NotFound pmichaud: no, is just the conclusion of some test I'm doing 19:30
pmichaud oh, okay.
19:32 donaldh left
dalek rrot: r39573 | NotFound++ | trunk/src/debug.c:
[cage] fix for a problem with the debug op found while working on TT #752
 19:37
20:03 mikehh joined 20:07 mikehh_ joined 20:18 Theory joined
pmichaud NotFound: You might want to look at TT #760. 20:24
NotFound pmichaud: I'm doing right now 20:27
The diagnostic is wrong, FileHadle.readline_interactive returns NULL 20:30
BTW I've never used a system that has a default of control-G for eof 20:32
pmichaud me either... I think it's really CTRL-D 20:35
anyway, I can verify that it fails under current trunk.
NotFound Ctrl-D is the default value in unix systems, and windows uses ctrl-z since the times of ms-dos and cp/m AFAIK 20:36
pmichaud (rebuilding trunk, then will nopaste) 20:38
NotFound I agree that setting the EOF flag in the filehandle is reasonable, anyway.
pmichaud that also requires a deprecation cycle, I think.
nopaste "pmichaud" at 72.181.176.220 pasted "trunk readline_interactive is incorrect" (29 lines) at nopaste.snit.ch/16928 20:40
NotFound pmichaud: that test is wrong 20:41
pmichaud how so?
NotFound The string is null, the pmc that contains a null string is not. 20:42
pmichaud NotFound: no.
readline_interactive has been defined from the beginning to return NULL when reaching EOF
in particular, it's been defined to return a PMCNULL
NotFound pmichaud: It returns a NULL string.
pmichaud NotFound: I'm telling you the way it was defined in 1.0.0 20:43
you cannot change that definition without a deprecation cycle
the definition of returning a NULL PMC has been in place for a very long time
NotFound So it returned a PMC, not a string?
pmichaud YES.
not an empty string.
NotFound That's a different kind of problem.
pmichaud readline_interactive returns an empty string if the person simply hits "enter" ( any newline is automatically chopped off ) 20:44
so the way to determine EOF has always been to check for a Null PMC
NotFound I don't get it. It must return a PMC only for the eof case, or it must always return a PMC? 20:48
pmichaud it doesn't really matter, normally. 20:49
because the calling conventions normally take care of casting to alternate forms.
i.e., it would work even if I did $I0 = $P0.'readline_interactive'('prompt') 20:50
NotFound pmichaud: here lies the problem: the calling conventions does not convert a NULL string to a NULL PMC.
pmichaud a NULL string isn't EOF.
I don't need it to convert a null string to a null PMC
a null string should be returned as a null string. 20:51
the way it was set up in the 1.2.0 was correct.
NotFound There is no way no read a null string. An empty line is an empty string.
pmichaud sure, no problem. 20:52
but an empty line is returned as a null string.
NotFound pmichaud: the current code does not do that.
pmichaud NotFound: the current code is WRONG.
the interactive readline code chops off the trailing newlines of any input data.
you may disagree with the design of 'readline_interactive'. That's fine if you disagree there. But it cannot be changed without a deprecation cycle. 20:53
NotFound pmichaud: the readline lib already does that
pmichaud That's my point.
(the readline lib already does that) -- that's my point. 20:54
NotFound Already does the chop, but does not return null
pmichaud please, let's get some terms straight
what do you mean by "null string"?
NotFound At c level (char *) 0. At parrot level (STRING *)0 20:55
pmichaud okay.
so, "null string" is a 0 pointer.
"empty string" is a string of zero length.
okay so far?
NotFound Yeah, bot in C and in parrot strings
20:56 Andy joined
pmichaud now then, the readline library returns an empty string if there's an empty line of input, yes? 20:56
NotFound Ok
pmichaud the readline library returns a null string if EOF is reached
the readline_interactive method must return a PMCNULL if EOF is reached
because otherwise the caller doesn't have an easy way to determine that EOF has been reached. 20:57
if EOF is not reached, then readline_interactive simply returns whatever string it got back from the readline library.
NotFound Minor point: if EOF is found without reaching EOL, it does not return NULL.
pmichaud fair enough, but not a major issue to the way things are set up. 20:58
again, readline_interactive was explicitly created to mimic the behavior of the readline method in earlier versions of Parrot (but also providing better prompting support)
so you can't claim that my test is wrong, because my test is testing the API that was set up for Parrot 1.0.0 20:59
NotFound pmichaud: is wrong as a way of checking if it returns NULL. It already returns NULL, just a different kind of NULL than expected. 21:00
pmichaud how do you think it should be testing for NULL? 21:01
and that question is bogus anyway.
In 1.0.0, the way to check for EOF from readline_interactive was to check for PMCNULL.
NotFound pmichaud: for the current state of the code, using a string for the result, not a pmc
pmichaud how does one check for a null string in PIR?
NotFound Same as a pmc, just using a string register 21:02
Anyway, we can just change the method to always return a PMC, both for eof and not eof cases. 21:03
pmichaud that's fine with me. I just don't want to see an API change without proper deprecation.
NotFound A null pmc for eof, a string pmc otherwise.
pmichaud why was this changed in the first place, out of curiosity?
it was working correctly in 1_2_0
oh. 21:04
There is no "isnull" opcode for string registers.
NotFound pmichaud: I remember a talk about inconsistently returning string or pmc, don't remember if it was about this method or another thing.
pmichaud So, it's not "same as a pmc"
NotFound pmichaud: I've been testing with 'unless null ...' and works fine :? 21:06
pmichaud it looks like there's an "unless_null" for string registers, yes.
but not an "isnull"
NotFound Ah, the isnull opcode... I didn't think about that.
There is some reason for not having it? 21:07
pmichaud Not that I'm aware of. We could potentially add it. Still, the readline_interactive needs to be able to work with PMCs
NotFound pmichaud: I think the clean solution is to always return a PMC. 21:08
pmichaud I should be able to do $P0 = $P1.'readline_interactive'() and have it do the right thing.
why always return a PMC?
that seems inefficient.
NotFound Consistency.
purl it has been said that consistency is a problem. or highly overrated or the hobgoblin of small minds or (see FOOLISH consistency)
pmichaud why does it need to be consistent? (more)
NotFound Good question 21:09
purl Yeah, it is. I'm stumped.
pmichaud or are you claiming that all of the PIR methods we right should also consistently always return the same thing?
right now in PIR we can do
.return ($P0)
and
.return ($S0)
in the same method. Why would this need to be any different?
s/right/write/ # above 21:10
NotFound I'm most used to statically typed systems
pmichaud In general, I think type conversions should be left up to the calling conventions as much as possible, since we have them.
if we always return a PMC, then
$S0 = $P1.'readline_interactive'() 21:11
will end up always creating a PMC that is immediately thrown away.
bacek good morning #parrot...
NotFound pmichaud: not a big speed problem for interactive usage, but I see the point. 21:13
pmichaud yes, I agree it's not a big speed problem.
given that we even have a way to check string registers for null, I don't have an issue for that. At the time when all of this was being put together, I didn't realize there was a way to check string registers for null because there wasn't an appropriate isnull opcode 21:14
21:15 Whiteknight joined
NotFound Well, I think a good plan might be: restore the old behaviour now, propose to deprecate it in favour of returning a null string, and propose to add a isnull opcode for string 21:15
pmichaud I think I'd be okay with that. 21:16
Whiteknight +1 from me
just so long as we get a fix in for the release tomorrow
NotFound Whiteknight: I'll do that
pmichaud well, from a parrot perspective it has to be fixed by 1.4.
Having it fixed by tomorrow would be a bonus, yes. :-)
Whiteknight NotFound++ 21:22
t/codingstd/paren.t failure: /home/andrew/Projects/parrot/src/string/api.c 21:25
mikehh ditto - all other tests pass on make -k fulltest on Kubuntu 9.04 Amd64 at r39573 21:27
Whiteknight i just put in a fix
NotFound There is a minor problem: returning PMCNULL causes a Null PMC access exception when using a string for the result, but I suppose that code that expected the previous behaviour never does that,
mikehh I did apply the patch nopaste.snit.ch/16917
pmichaud NotFound: correct. 21:28
dalek rrot: r39574 | whiteknight++ | trunk/src/string/api.c:
[t] fix coding std failure
21:28 kid51 joined
mikehh I now pass fulltest on Ubuntu 9.04 i386 and Kubuntu 9.04 Amd64 (apart from the codetest failure) 21:30
The patch nopaste.snit.ch/16917 works on both
Whiteknight mikehh, is that patch associated with a ticket? 21:31
dalek rrot: r39575 | NotFound++ | trunk/src/pmc/filehandle.pmc:
[io] restore behaviour of readline_interactive, TT #760
mikehh whiteknight: I didn't create one - I can 21:32
Whiteknight don't worry about it, I'm testing it now
committed 21:33
mikehh++ 21:34
dalek rrot: r39576 | whiteknight++ | trunk/t/op/debuginfo.t:
[t] add patch from mikehh++ to fix TODO test passing in some places in t/op/debuginfo.t
 21:35
mikehh :-} - that's two patches I got in today
NotFound Fix a TODO passing is don't do it? ;-) 21:37
Whiteknight fix it so it's not TODO and is always passing 21:39
NotFound Ah, good :) 21:40
BTW, I'm not having amd64 test errors for more than a week :) 21:42
Is a shame, I've installed a linux 64 in order to be able to work on that problems X-) 21:43
chromatic I rooted your box and made it a 32 bit installation. You're welcome.
NotFound I always thinked that there must be some obscure reason for the nopaste showing of the IP ;) 21:45
he_ NotFound: sorry; a trip to the cinema got between us... This is the result of running "perl t/harness t/pmc/eval.t", and it fails test 17 with "src/call/pcc.c:563: failed assertion 'PObj_is_PMC_TEST(sig_pmc)'". 21:53
chromatic Did you 'make realclean' and rebuild, he_? 21:56
he_ chromatic: yes, "make distclean; perl ./Configure.pl && make && make smoke". I can repeat just to be absolutely certain. 21:57
chromatic Is distclean different from realclean? 21:59
I don't know the differences.
Ah, they're the same. Okay. Hm. 22:00
Tene chromatic: I found a FAIL in some C code that was last touched by you afaict... TT 757
he_ Not really; top-level Makefile has "distclean : realclean" 22:01
chromatic Tene, the fail is probably an old, old fail, but I can take a look.
Tene chromatic: Thanks. I'd really like to get threading working to some degree in rakudo. 22:02
chromatic Me too. 22:03
Autothreading would be spectacular.
Whiteknight what is the state of the Parrot threading system? 22:06
I know it "works" to some degree, but don't know if it's good or needs work or what
chromatic Cloning interpreters doesn't fully work.
I think there's a problem cloning classes and other interpreter global information.
Whiteknight that doesn't sound so bad 22:07
the code I saw seemed a little old and messy but otherwise sane 22:08
chromatic It's not horrible. It's merely incomplete. 22:10
Tene Whiteknight: The pir file attached to TT757 exposes a bug with class cloning, iiuc. it runs fine without perl6.pbc loaded, but when you uncomment the load_bytecode perl6.pbc, it fails an ASSERT. 22:11
Whiteknight Somebody else had done some work on that system (chromatic?) after I wrote it, poorly
I'll take a look at the ticket, how urgent is it? 22:12
Tene Whiteknight: if someone can get it working, I can add 'async' to rakudo, afaict. 22:13
To get basic threading.
And after that, maybe some autothreading.
Whiteknight oh wow, okay, so that is important
can it wait till after the release though?
Tene Well, I don't know if anybody is actually blocking on async.
22:13 jan joined
Whiteknight okay 22:13
Tene Um, ask pmichaud? 22:14
Whiteknight next month will be a big one for asynchronous stuff, I think
Tene Oh! I'm kinda blocking on it... as far as "this would be fun to play with" counts as a blocker. ;)
Which is "not much". 22:15
chromatic I think we have more important blockers to concentrate on first.
Tene Rather. :)
chromatic I'd like to talk about that at YAPC next week. 22:16
Whiteknight talk about what, our short-term priorities? 22:17
I've got AIO in my sights now, and I'm tackling that system soon, come hell or high water 22:18
Infinoid What assert does it fail? 22:19
Whiteknight Maybe one more round of IO cleanups as soon as the release lands, and then it's on to AIO
Tene sad to be missing YAPC
Infinoid: ./src/pmc/parrotinterpreter.pmc:94 22:20
Infinoid sees about reproducing that in gdb 22:21
Tene I always have trouble remembering how to get information from parrot structures in gdb, and have to re-discover every time. 22:22
chromatic Not our short term priorities but how we handle priorities and milestones and tasks. I think we could be more effective.
Tene Infinoid: it fails on the first iteration, and class_name is "Perl6;Grammar;Actions"
if that helps 22:23
Infinoid thanks, I'm gonna start by seeing which class it's calling the exists_keyed_str vtable on 22:24
Tene Infinoid: parrotinterpreter 22:26
look at line 80 22:27
also at the signature of the function 22:28
Infinoid I don't get an assert failure
I get: get_pmc_keyed_str() not implemented in class 'Key'
Tene I remember seeing that after I removed the assert
22:28 viklund_ joined
Whiteknight chromatic: I agree, we haven't been too good at estimating what tasks will get done when 22:29
chromatic More than that, we still flail around at the edges of the important tasks and sometimes poke at them. 22:30
We do pretty well when we work together on things, but we don't work together on things as often as I'd like. We could be more effective. 22:31
Whiteknight I agree with that, but those are intrinsic mechanics of volunteer-driven groups
people work on what interests them first, which isn't necessarily what's best for the organization
Tene Whiteknight: that doesn't mean that we can't try to do something different (on a volunteer basis)
Whiteknight Tene: Oh, I definitely agree, we need to encourage people to work on important things, but not get discouraged when they don't 22:32
it's like herding cats
Tene Whiteknight: I'm often primarily interested in "Doing something for parrot", but the current priorities aren't very clear.
Infinoid cats who like shiny things, and often disagree on which things are shiny
Tene Not so much in the past few months, but before that I often came in here, asking "Is there anything anyone wants me to work on?" 22:33
22:34 rg1 joined
Tene I don't do that so much anymore due to lask of response and decreasing available time. 22:34
Whiteknight chromatic: What in your mind is highest priority right now?
Infinoid It often seems like the highest priority stuff (like, for instance, making PCC faster and making the GC suck less) are the least approachable tasks to those people who are just looking to throw a spare hour at parrot here and there 22:36
Whiteknight I'll be happy to focus on whatever is the task du jure, allowing for some focus on areas of personal interest 22:37
Tene My life is settling down a lot lately... I'm looking to have a regular scheduled Parrot Hour every evening. 22:38
Whiteknight Tene: luck you! my life is becoming increasingly unsettled
Infinoid The last couple of weeks were a statistical outlier, it's all downhill from there for me too 22:39
he_ chromatic: new test results are same as before (as expected), smolder.plusthree.com/app/public_pr...ails/23783 22:40
Tene Whiteknight: seems like I'm paying for the next year's complexity and stress over about two weeks, centered around last weekend. 22:41
so, it's a tradeoff. :) 22:42
Infinoid noms PBJ and tests the TT #726 patch for leaks 22:48
Yay, no leaks. 22:53
Infinoid will commit it after 1.3.0
chromatic I'm not sure what the current priorities are.
Infinoid Actually, putting a priority in the channel topic has helped me a lot
chromatic Obviously PCC rewiring (but that one depends highly on Allison either to explain or finish).
Installable Parrot and HLLs running from installable Parrot. 22:54
NotFound Tene: <Tene> I always have trouble remembering how to get information from parrot structures in gdb, and have to re-discover every time.
chromatic Multidispatch semantics, I think.
NotFound Tene: a page in the wiki about that will be helpful
chromatic It'd be nice to have a regular plan for refactoring a part of Parrot.
Infinoid NotFound, Tene: There are some helpers in tools/dev/.gdbinit 22:55
chromatic Mostly I'd like to pick one or two targets for each monthly release, have someone take charge of breaking it up into bite-sized tasks, and help herd all of us to getting it done.
Whiteknight chromatic: I was looking at the pcc_rewiring branch the other day, and just merging it up to trunk HEAD is a bit of a nightmare 22:56
chromatic Yeah, it needs smaller merges.
Tene I remember several times seeing someone working on a branch, and not having enough information about the branch to help.
chromatic Or git.
Tene The majority of our branches have been one or two person affairs, and if that person loses momentum, the work is lost. 22:57
iirc
Whiteknight chromatic: I'm almost convinced that the best way forward on pcc_rewiring is to delete the branch and start a shorter-lived one in it's place
although there's a point beyond which a large chunk of work needs to get done between merges, to migrate things from one system to another
chromatic That's one of our problems. We have plenty of expertise and people to solve a problem, but too often the solution to that problem is in one person's head where it's difficult to collaborate.
Infinoid eats some git spinach and takes a crack at merging
Tene I'll try a pcc merge with git. 22:58
NotFound The same might apply to the strings branch
Whiteknight Infinoid: I got the merge to work today, but it was ugly
and I lost track of some metadata along the way, so I have to redo it later
chromatic It should just be a git rebase, if I understand git correctly (and I'm not sure I do).
Whiteknight on the bright side, it does clean up the error backtraces significantly
because of all the io_rewiring work, cleaning up PCCINVOKEs in the IO system
Infinoid chromatic: Yep, that's what it is 22:59
How's pmc_pct going?
chromatic That's cotto and bacek, I think. 23:00
I've watched how they work and I watch how Allison and I can work and I watch how Patrick and Jonathan work, and I believe more strongly that we go faster and write better code when two people tackle a problem.
Infinoid I just think we have a lot of rock stars. :) 23:01
Tene Yeah, it doesn't merge cleanly, and I don't know enough about the changes to sanely resolve the merge conflicts.
Whiteknight chromatic: I'm sure of it, Infinoid and I did really well together this month, and I'd be happy to pair up on other projects in the future 23:02
chromatic Pairing would be good. Maybe that's sufficient. 23:03
I hate to introduce that dreaded P-word into the discussion, but a little more formality on how we approach things might help a lot. 23:04
Whiteknight I'm very open to the idea of pairing
Infinoid Whiteknight++ # You did most of the work, I just swung through like a pirate and stabbed a couple of things sticking out
Whiteknight and like I said, I'll work on anything people have a clear need to do, and without a major focus I work on areas of personal interest
I'm looking forward to some real heads-together hacking at YAPC, if we can find time to do that 23:05
chromatic That's the sticking point Allison thought might come up; people work on what they want to work on.
Infinoid I need to figure out a way to get there
Problem is I can't actually stay for YAPC, so I'd just be going for the hackathon 23:07
Then again, I'm an hour away from Whiteknight, maybe I can just drop by some other weekend with pizza.
NotFound pizza++
chromatic Thursday wouldn't be bad. 23:09
Whiteknight I'm leaving tuesday evening, unfortunately 23:10
Infinoid: I would love to get together for hackathons
Coke yay, ^D now closes interactive tcl.
... of course, [exit] doesn't. wierd. figured those were the same problem. 23:11
Whiteknight chromatic: First step is identifying our priorities, second step is motivating people to tackle them
Coke the roadmap was supposed to help identify priorites. 23:12
Whiteknight getting together for focused planning meetings for those tasks would be nice, like #ps but focused on a single task
NotFound The addition of an isnull (out INT, in STR) opcode needs a RFC, or it just doesn't exist because nobody noticed his absence?
Coke but they really need more requirements than just "bullet item".
Whiteknight NotFound: I say add it, but maybe ask tomorrow at #ps to be sure
Coke perhaps have a patch ready in case no one minds. =-)
NotFound Whiteknight: ok
Tene Several times, I've found a severe lack of information on the roadmap. 23:13
chromatic That's just it.
The idea was in someone's head at some point, but it's not available in a form that lets Tene say "Oh, I can do THIS in an hour" or Infinoid say "I have Saturday morning free" or Whiteknight "I'll take my laptop while my wife is watching Pride and Prejudice again." 23:14
Whiteknight I think a part of it is uncertainty about who can and should be updating design docs 23:15
and what the process is for putting plans together, and where such plans should be
chromatic Yep.
We do that ad hoc anyway though. 23:16
Whiteknight I do a lot of informal planning on my blog, but that's only helpful to me and the one dude who reads it
NotFound Coke: I located the exit problem some months ago while putting a hand on ecmascript. Exceptions are unconditionally catched by the code generated by the tools, and the interactive loop reentered.
Infinoid Whiteknight: Can has blog URL? 23:17
purl, whiteknight?
purl whiteknight is mailto:wknight8111@gmail.com or the grand master funk
23:17 Andy joined
Whiteknight the parrot-related posts are in the planet.parrot.org aggregator 23:18
planet.parrotcode.org
purl i guess planet.parrotcode.org is the aggregator
23:18 skids joined
Coke NotFound: I just figured that out. (Easier to see now that the ^D issue is fixed.) 23:19
of course, since I have my own REPL, have to figure it myself.
s/have/had/
NotFound: looks like that never would have worked. =-) 23:20
Tene I wonder how helpful it would be to have explicit "email <tene@allalone.org> for more information on what's required here" notes.
NotFound In ecmascript I worked around that by throwing a fatal excpetion, but I don't think that is a good general solution.
chromatic email has too much latency.
Tene presuming the content of those emails would be "Please add detail on A, B, and C to the page"
Phone? ;) 23:21
dalek rtcl: r502 | coke++ | trunk/src/tclsh.pir:
Allow [exit] to leave the REPL
Infinoid purl, whiteknight is also wknight8111.blogspot.com/ 23:22
purl okay, Infinoid.
23:27 patspam joined
GeJ Good morning everyone 23:28
everyone good morning, GeJ 23:30
nopaste "GeJ" at 202.22.227.128 pasted "NEWS: be consistent with previous releases and add '.' after each item. Also fix a couple of typos I found" (51 lines) at nopaste.snit.ch/16929 23:32
dalek TT #10 closed by coke++: -r33351 causes tcl segfault
GeJ I may have missed some. Never trust the English of a French. 23:33
Hello davidfetter
dalek rrot: r39577 | bacek++ | branches/tt761_keys_revamp (4 files):
[pmc] Initial version of HashIterator/HashIteratorKey.
 23:36
bacek OH HAI.
GeJ G'Day bacek 23:37
23:38 eternaleye joined
kid51 Whiteknight: With Infinoid now in DE, possibility of East Coast hackathon becomes non-zero. 23:40
Coke I could be up for an east coast thing. 23:41
though I'll probably just show up and whine about how everyone keeps breaking partcl.
(which, oddly, hasn't happened recently.)
kid51 Sometime between Sept and Nov would fit nicely into the yearly conference cycle.
chromatic I seem to recall *fixing* partcl.
Tene Coke: Now that you can use partcl libraries from rakudo, you just need to get some tests that use partcl into rakudo's test suite. ;) 23:42
Coke chromatic: =-)
chromatic: I'm actually trying to close out a few bugs you fixed.
dalek TT #193 closed by coke++: segfault using -t1
Infinoid What's the difference between "Integer" and "INTVAL" from an MMD perspective? BigNum declares MULTI PMC *add(BigNum value, PMC *dest), MULTI PMC *add(Integer value, PMC *dest), MULTI PMC *add(DEFAULT value, PMC *dest) and VTABLE PMC *add_int(INTVAL value, PMC *dest), which confuses me. 23:44
one is for the .add method, and one is for the add op, I guess? 23:45
Coke I would expect INTVAL is 'int' 23:46
but I wonder why we wouldn't just write "int" instead of exposing the C type.
dalek rrot: r39578 | tene++ | trunk/NEWS:
minor NEWS update
rtcl: r503 | coke++ | wiki/ParrotIssues.wiki:
Several parrot tickets have been resolved.
Infinoid oh, I get it. Integer is a PMC type 23:47
chromatic Integer is the PMC type, isn't it?
Infinoid BigNum has a distinct lack of *_float vtables
Coke Is there any documentation on interacting with parrot's call chain? I wish to stop managing my own. 23:51
chromatic What do you have in mind?
kid51 I know certain people will hate to hear this but ... 23:52
Coke I need to be able to execute code in the context of higher levels.
or return control up N levels.
kid51 I'm getting a codingstd failure t/codingstd/c_indent.t fails on src/pmc/filehandle.pmc
chromatic [upvar]
Coke chromatic: yes. upvar, uplevel, return -level 4 continue
right now I manage my own and can pull off... most of that. 23:53
but it's extra work I shouldn't be doing.
chromatic I'm not sure how to do upvar, but return -level 4 should be following the return continuation chain.
kid51 This "bad indent" is the line after an #ifdef 23:54
Test wants 4 spaces; line is indented 8.
Coke kid51: that conflicts with another test. have fun. =-)
either that, or with good sense.
23:54 amuck joined
kid51 But line is indented 8 to be consistent with overall indent style: file is one big block 23:54
#ifdef has to be flush left, correct? 23:55
Coke /have/ to be? no.
chromatic Unless it's within an #ifdef.
kid51 lemme se
see
Coke This is one of those cases where it's not worth spending the time making the test pass.
chromatic: so, pointers to docs on return continuation chain? Esp. the part where I only care about HLL scopes? 23:56
chromatic Beyond the Continuation POD, I'm not aware of any. 23:57
There *might* be some general discussion of how things work in a PDD (calling conventions?) or docs/dev/ somewhere, but certainly not from an HLL implementor POV.
HLLIPOV
Coke bah. 23:58
ok. shelving that, then.
chromatic Consider it a cri-pportunity to provide some! 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!