Camelia, the Perl 6 bug

IRC log for #parrot, 2009-04-07

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 Infinoid I particularly love how this jit bug trashes the stack before it crashes
00:04 cotto joined #parrot
00:05 Tene joined #parrot
00:09 AndyA joined #parrot
00:16 Infinoid cotto: Ok, I'm looking at the generated code here... it's just dereferencing the pmc pointer directly, expecting to find your PMC_struct_val at offset 0 within the structure
00:17 cotto Sounds like the right place.  Where is that code?
00:17 Infinoid it's on the heap, it's the function called as jit_func()
00:19 bacek_ joined #parrot
00:19 Infinoid apparently the jit code doesn't bother to maintain stack frames, so gdb's backtraces are useless at this point, but I have a register dump and disassembly if you want the exact offset
00:19 bacek_ good morning
00:19 Infinoid hi bacek_
00:19 bacek_ hi Infinoid
00:19 cotto I wouldn't know what to do with it.
00:20 Infinoid I need to understand where and how jit generated this code, in order to fix this
00:20 Infinoid first off, where can I find the jit engine sources? :)
00:21 rg you mean like src/jit/i386?
00:21 Infinoid (We're pretty fortunate that we're only one function call deep, by the way.  Makes the result pretty easy to read)
00:22 Infinoid rg++
00:23 * rg has looked at the jit sources before ... without much success (as documented in TT #501 and the linked RT)
00:23 * Infinoid stares at Parrot_pcc_invoke_from_sig_object() for starters
00:28 bacek_ I've got stupid question - who can check fax machine at Parrot Foundation? :)
00:29 Infinoid particle2: Have you gotten bacek's CLA yet?
00:31 bacek_ Infinoid: any objections about approach in http://github.com/bacek/pa​rrot/tree/packfile_revamp ? (I'm going to move more tests from perl to pir today. And start adding "write" ability to packfile*.pmc)
00:32 * bacek_ heading off to another meeting...
00:36 darbelo left #parrot
00:37 Infinoid bacek_: +1, good stuff
00:50 Infinoid it appears before I can learn the horrors of JIT, I need to learn the horrors of MMD first
00:53 cotto Infinoid, why?
00:54 dalek parrot: r37933 | cotto++ | trunk/tools/dev/parrot-fuzzer:
00:54 dalek parrot: [fuzzer] minor refactor, add --ignore_blacklist option
00:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37933/
00:55 Infinoid cotto: I want to know how this nci function is generated by the jit engine
00:56 Infinoid but unfortunately, that leads directly into the middle of pcc/mmd
01:01 dalek parrot: r37934 | cotto++ | trunk/src/pmc (2 files):
01:01 dalek parrot: [PMC] finish the switch to ATTRs in *ManagedStruct
01:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37934/
01:11 cotto smolder?
01:11 purl well, smolder is http://sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or http://smolder.plusthree.com/app​/public_projects/smoke_reports/8
01:14 cotto lovely?
01:14 purl i heard lovely was programmer-speak for "JUST FUCKING WONDERFUL AND BY THAT I MEAN POOP"
01:14 cotto no, lovely is http://engrishfunny.com/2008/​10/15/engrish-make-yourself/
01:14 purl okay, cotto.
01:15 Util heh
01:19 Infinoid cotto: Oh, nevermind.  Process of elimination worked, the bad jit code call was generated at src/jit/i386/jit_defs.c:2320
01:23 Infinoid Is there a function it can call to fetch the value of nci_info->orig_func?
01:25 Infinoid Preferably without having to call Parrot_PCCINVOKE (I assume the whole point of using jitted nci is to speed things up)
01:27 cotto It'd be very easy to add a get_pointer VTABLE function that did that.
01:27 cotto get_pointer deals with orig_func, so it'd go with the principle of least surprise.
01:28 acajou left #parrot
01:28 cotto Are you thinking in terms of debugging or coding?
01:28 Infinoid hmm, I think we can make VTABLE_get_pointer
01:28 mikehh kid51: I notice that in your config you have -lnsl and -lutil which I don't have
01:29 Infinoid Those VTABLE_* things are preprocessor magic that isn't available at this level, but I can look and see if jit has a wrapper I can use
01:29 Infinoid I'm done debugging, now trying to code a replacement
01:30 cotto Infinoid, you can look at r37897 where tewk calls a VTABLE function from the jit code.
01:30 Infinoid awesome, thanks
01:31 cotto also, http://engrishfunny.com/2008/11/06/e​ngrish-please-present-your-octopus/
01:31 shorten cotto's url is at http://xrl.us/owkqm
01:32 Infinoid ah, that vtable code doesn't look too bad
01:34 Infinoid though I'm not really sure how get_pointer gets the pointer of its invocant (eax is overwritten during the pmc->vtable->get_pointer dereferencing)
01:34 kid51 mikehh:  Then you know my config better than I do ;-)
01:34 kid51 I didn't consciously do anything to add them.
01:36 mikehh I was just wondering what they were - I couldn't seem to track them down
01:40 kid51 vi +88 ./tools/build/dynpmc.pl
01:41 kid51 But that's not source; it must be built by something.  Hold on.
01:45 mikehh joined #parrot
01:48 kid51 mikehh:  It's picked from my Perl 5 %Config in step 2:  init::defaults.  Am configuring with /usr/local/bin/perl.  Perl 5.10.0 manually compiled (on the day it came out!).
01:51 kid51 perl Configure.pl --configure_trace && perl -MData::Dumper -MStorable -e '$hashref=retrieve(q|.configure_trace.sto|);print Dumper $hashref' | grep -n lutil
01:51 kid51 ... and same for lnsl
01:52 kid51 But I don't know what those two libs are all about.
01:52 mikehh I am using the Perl 5,10 that is distributed with Intrepid - updated and with CPAN but I am not happy with their build - they are Python people - NOT Perl
01:53 kid51 Well, my build, though by hand, was whatever the simplest possible build is.  No special arguments to Perl's Configure.
01:54 mikehh They have install directories all over the place including /usr/local which worries me if I build to that dir
01:54 * kid51 leaves that to AndyD ;-)
01:55 mikehh I think I might build to localperl - who knows how to build from the git repo?
01:57 * kid51 does not.  I got a tarball the day it came out -- which was before the move to the git repo, IIRC.
02:00 mikehh I have an up to date git locally - I think I need to build against Maint 10,0 or maybe I should jyst try Bleed
02:04 mikehh I just spent a day building gcc 4.3.3 and I am not sutr I want to do Perl at the moment :-{
02:10 dalek parrot: r37935 | jkeenan++ | trunk/t/tools/ops2pm/05-renum_op_map_file.t:
02:10 dalek parrot: Correct 'Stage' numbers in messages of 4 tests.
02:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37935/
02:13 dalek parrot: r37936 | jkeenan++ | trunk/t/tools/ops2pm/05-renum_op_map_file.t:
02:13 dalek parrot: Eliminate superfluous get_last_opcode() calls in Stages 3 and 6.
02:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37936/
02:14 kid51 Well, as noted above, building your own gcc is only for the very brave or very foolish.
02:14 kid51 But I've built perl -- albeit always in the simplest possible configuration -- quite a few times.
02:21 mikehh I woukd normally build to /usr/local/bin but the standard build would conflict with the Ubuntu one so I  need to consider that very carefully
02:23 mikehh mainly because it has CPAN modules in /usr/local/lib/perl
02:23 kid51 Eeeek.  That *is* a messy install.
02:23 eternaleye joined #parrot
02:25 mikehh also /usr/local/share/perl and /usr/local/share/perl5 and /usr/lib/perl5 and ... and
02:25 Infinoid cotto, you still around?
02:27 mikehh as I said they really are Python people and they made a mess the first time and then updated to try and get it right but did not remove all the old directories
02:28 nopaste "infinoid" at 75.5.243.250 pasted "cotto: [PATCH] [HALFBAKED] [DANGER WILL ROBINSON] JIT NCI call wrapper should use VTABLE_get_pointer to access function pointer, not PMC_struct_val" (71 lines) at http://nopaste.snit.ch/16163
02:29 mikehh The number of times that I have updated with cpanp and had to remove some of the old files manually ... :-}
02:29 dalek parrot: r37937 | pmichaud++ | trunk (2 files):
02:29 dalek parrot: [codestring]:  Add 'lineof' method for finding line numbers.
02:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37937/
02:30 Infinoid msg cotto I have to run.  http://nopaste.snit.ch/16163 works for me, but it could use some polishing, and a review from a JIT person.  I haven't had to do explicit stack handling on x86 for a long time, and I *think* it's right, but I'm not really sure about all that temp_calls_offset and args_offset handling stuff.
02:30 purl Message for cotto stored.
02:33 Infinoid msg cotto The PMC_struct_val(SELF) = NULL stuff is in there just to make sure it segfaulted when it should.  That can be removed.
02:33 purl Message for cotto stored.
02:34 * Infinoid gone &
02:35 janus joined #parrot
02:36 dalek parrot: r37938 | pmichaud++ | trunk/compilers/pge/PGE/Match.pir:
02:36 dalek parrot: [pge]:  Use a CodeString PMC to hold match targets instead of String.
02:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37938/
02:37 * kid51 must sleep
02:37 purl $kid51->sleep(8 * 3600);
02:56 eternaleye_ joined #parrot
03:02 karatorian joined #parrot
03:11 cotto Infinoid, back
03:11 cotto messages erase
03:57 karatorian left #parrot
03:58 Coke_afk messages shake etch a sketch
04:29 tetragon joined #parrot
04:44 masak joined #parrot
04:48 eternaleye_ Are there any plans for an API to access the AST for HLL code from an embedding program? I could see it being immensely useful for, say, syntax hilighting. Especially the Declaration-Use Chain  stuff the KDevelop guys are doing.
04:52 cotto eternaleye_, that's a good question for #parrotsketch
05:00 eternaleye_ Cool, I'll join
05:02 cotto Good for you!
05:29 cotto eternaleye_, #parrotsketch is where we hold our weekly meetings
05:30 eternaleye_ Ohhh
05:30 Tene eternaleye_: the weekly meeting is tomorrow
05:30 eternaleye_ Gotcha.
05:30 Tene purl: parrotsketch?
05:30 purl well, parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
05:30 cotto Sorry.  I assumed too much there.
05:30 eternaleye_ 'sokay.
05:30 cotto If you're around, you're free to join and ask your question, though.
05:31 cotto I'd ask it, but I'll have to miss it tomorrow.
05:36 eternaleye_ I ought to be able to show up. It's at 11:30am localtime (PST8PDT). I'll be in class, but I ought to be able to manage (It's my CS class XD)
05:37 dalek parrot: r37939 | cotto++ | trunk/t/codingstd/copyright.t:
05:37 dalek parrot: [t] unTODO a passing codingstd test
05:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37939/
05:39 cotto You only occasionally have to pay attention, especially if you're a fast reader.
05:40 cotto The usual format for #ps is that regular contributors report, then it's open for questions.
05:46 eternaleye_ Sounds good. I'll probably set a hilight fot the regex 'question(s?)', and just check it every few minutes
05:47 eternaleye_ Let me know when it's time
05:48 eternaleye_ s/^L/That should l/
06:05 cotto seen tewk
06:05 purl tewk was last seen on #parrot 2 days, 8 hours, 51 minutes and 43 seconds ago, saying: :q  [Apr  4 21:12:07 2009]
06:05 eiro joined #parrot
06:06 eiro joined #parrot
06:15 cotto msg tewk When you have a minute, the patch for https://trac.parrot.org/parrot/ticket/365 needs review by someone who understands the JIT code.  I'd appreciate it if you could review the patch (https://trac.parrot.org/parrot/raw-attac​hment/ticket/365/nci_jit_fix_tt365.patch ) and either give it your +1 or say what needs to be fixed.  Thanks.
06:15 purl Message for tewk stored.
06:15 shorten cotto's url is at http://xrl.us/ben5b7
06:16 cotto Infinoid++ #(le)jit hackery
06:19 cotto sleepytime
06:19 moritz eternaleye_: PCT based compiler have a target=parse option that reveals the syntax tree
06:29 Tene_ joined #parrot
06:44 eternaleye_ moritz: That's cool! I'll probably still end up asking #parrotsketch whether there'll be an API for embedders to access that AST though, like to walk the AST from C or C++
06:44 moritz eternaleye_: sure, feel free
06:52 iblechbot joined #parrot
07:07 bsdz joined #parrot
08:03 particle joined #parrot
08:20 donaldh joined #parrot
08:29 nopaste "mikehh" at 92.30.6.100 pasted "Weird happenings with the jit core" (106 lines) at http://nopaste.snit.ch/16172
08:30 mikehh Anyone want to have a look at this - I think my computer has lost the plot
09:07 cognominal joined #parrot
09:22 elmex joined #parrot
09:25 PacoLinux joined #parrot
09:54 dalek parrot: r37940 | fperrad++ | trunk/compilers/nqp/src/builtins.pir:
09:54 dalek parrot: [nqp] refactor 'say' with tailcall
09:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37940/
09:59 schinkelm joined #parrot
11:12 eiro joined #parrot
11:39 kid51 joined #parrot
11:40 flh joined #parrot
12:12 Coke_zzz bacek: ping
12:28 Coke_zzz (asking things in parrotsketch) there's also the mailing list, which has the advantage of being open 24/7.
12:36 rg1 joined #parrot
12:53 iblechbot joined #parrot
12:53 PacoLinux joined #parrot
12:56 register joined #parrot
13:03 * Infinoid finds some jit docs and reads them
13:08 ruoso joined #parrot
13:12 register joined #parrot
13:13 register Hi!
13:13 register how to configure the big int library?
13:15 moritz I think you install libgmp3-dev and run Configure.pl again
13:17 register ah ok
13:18 register thx
13:18 moritz (libgmp3-dev is the name on Debian, on other systems it might vary=
13:18 moritz s/=/)/
13:18 moritz you're welcome
13:18 moritz oh, and recompile of course ;-)
13:19 register well... yes...
13:19 register I am using an ubuntu
13:20 register should be the same name
13:21 moritz right
13:21 moritz Ubuntu++ # bringing apt/dpkg to a wider user base
13:22 register well it's a fabolous distribution
13:23 register I have a double boot laptop with ubuntu and windows 2008 server
13:23 register on the w2008 server I have a virtualbox with xubuntu
13:23 gryphon joined #parrot
13:23 register when I can foresee that I need to do some mix development
13:23 register xubuntu really rocks
13:23 register it's extremely fast and solid
13:24 register I really cannot see the difference between the vm xubuntu and the pure ubuntu...
13:24 register and another revolution has been the release of qt creator
13:24 register this ide is on par with visual studio
13:24 register but it is completely open
13:24 register I foresee big things for it
13:25 register it will become the de-facto standard for C++ development on all the supported platforms
13:26 * moritz is still on vim for C++ development
13:26 register well
13:26 register i still use vim on linux too
13:27 register but i code c++ for a living
13:27 register and i can really appreciate the difference between a textual development environment
13:27 register and a real IDE
13:27 register just setting breakpoints on gdb typing a sourcecodefilename:linenumber
13:28 register is a complete waste of time
13:28 moritz aye, agreed
13:28 register and being forced to remember every signature of every function is a complete waste of brain .memory also
13:28 register intellisense helps
13:28 register just by having an ide that is able to remember breakpoints
13:29 register you save at least 50% of the development time
13:29 register Even if I admire the open source movement for the quality of the code and the braveness of some ideas
13:30 register I have to blame it a little bit for not producing an interesting - modern - standard ide for development on linux
13:30 eiro register, ++ about bps .. -- about signatures
13:31 eiro <c-]> and <c-t> are your friends
13:31 eiro (i do it everytime with every langagesà
13:31 moritz ctags?
13:31 purl ctags is cool :) or at http://ctags.sf.net/
13:32 eiro moritz, yep
13:32 register ctags with vim?
13:32 eiro register, yes of course
13:32 register with automatic tags compilation every time the source is modified?
13:32 eiro and it complete the names of functions with <c-x><c-]> (i remapped with <c-j> ... borland souvenirs)
13:33 eiro register, no ... i have a macro to do it manually
13:33 register eheh
13:33 register gotcha
13:33 eiro ,rt ( refresh tags)
13:33 register ;)
13:33 eiro i don't carre: i don't have signatures
13:34 eiro btw it can be easy to add a event handler ... for every pressed keys if you want
13:34 eiro so it's not an argument ;)
13:34 eiro breakpoints is one !
13:34 eiro :(
13:35 moritz it would be nice to have a really good IDE with vim as the editor
13:35 register well
13:35 moritz I've seen a vim plugin for msvc, but I couldn't get it to run (but that's years ago)
13:35 register with qt creator I guess it could be done
13:35 register the ide is extendible
13:35 register is very modular
13:35 register as soon as I get some spare time I will play with it
13:36 register but I suggest you to have a look at it
13:36 register it's intellisense in magnificient
13:36 register its intellisense
13:36 register is
13:36 eiro it could be great! i can't imagine the developpement without vim
13:39 register by the way
13:39 register what is missing from the bigint pmc?
14:01 bsdz joined #parrot
14:22 dalek rakudo: 2c7f5b3 | pmichaud++ | docs/spectest-progress.csv:
14:22 dalek rakudo: spectest-progress.csv update: 349 files, 8436 passing, 0 failing
14:22 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​c7f5b300c8ef41c1f620bc1a5987b7e6d0499c6
14:22 shorten dalek's url is at http://xrl.us/ben5z4
14:24 dalek parrot: r37941 | coke++ | trunk (3 files):
14:24 dalek parrot: [cage] make sure src/exec.c is headerized
14:24 dalek parrot: It was setup to be, but not run via 'make headerizer'. After h11n
14:24 dalek parrot: it passes the function doc test.
14:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37941/
14:27 Theory joined #parrot
14:30 Coke that seems to me the wrong way to fix headerizer. are we not linking against exec.o ?
14:36 particle1 joined #parrot
14:38 Coke ah. we are, just not on my platform. blah.
14:41 dalek parrot: r37942 | coke++ | trunk/config/gen/makefiles/root.in:
14:41 dalek parrot: [cage] revert explicit add of exec.o
14:41 dalek parrot: This file IS headerized, but headerization is platform dependant - this file
14:41 dalek parrot: is skipped on osx/x86, but not on linux/x86.
14:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37942/
14:42 davidfetter joined #parrot
14:44 dalek parrot: r37943 | coke++ | trunk/tools/build/headerizer.pl:
14:44 dalek parrot: [cage] when warning about missing function docs, give the filename.
14:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37943/
14:49 * Coke ponders an eclipse plugin.
14:50 Infinoid If you wrote one, I would use it
15:00 Coke If I wrote one, I'm not sure /i/ would use it. =-)
15:00 Coke might be interesting to learn how, so I could also hack on cfeclipse, though.
15:02 flh when I write, in PIR, new 'something', this calls the "something" pmc init vtable function?
15:03 particle1 $P0 = new ['Something'] is the correct syntax now btw
15:03 particle1 and yes, it calls Something's init vtable function
15:04 particle- $P0 = new ['Something'], $P1 calls Something's init_pmc vtable function
15:04 flh and it should work also with a dynpmc?
15:05 particle- yes
15:05 flh ok, so I missed something somewhere else, since my init_pmc should throw an exception, but it doesn't
15:06 particle- are you using gcc, and if so, do you know your way around gdb?
15:06 particle- you can set a breakpoint at init_pmc
15:11 dalek rakudo: ea94175 | (Moritz Lenz)++ | t/harness:
15:11 dalek rakudo: re-enable parallel testing in t/harness again
15:11 dalek rakudo: Based on a patch by pmichaud++
15:11 dalek rakudo: Requires a sufficiently recent Test::Harness. For example the harness works
15:11 dalek rakudo: fine with 3.12, but for parallelism you need something newer, 3.16 seems to
15:11 dalek rakudo: work.
15:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​a9417560bd818e31419b6fcbdf3d265a93f186a
15:11 shorten dalek's url is at http://xrl.us/ben567
15:11 dalek rakudo: 27f0c01 | (Moritz Lenz)++ | README:
15:11 dalek rakudo: document requirements for parallel testing
15:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​7f0c01189593b4cfebf9e5c51da2b0fbfcea01a
15:11 shorten dalek's url is at http://xrl.us/ben569
15:14 flh well, actually, my init_pmc is not even in the C file generated from the .pmc
15:16 flh let's see how Rakudo is doing :)
15:20 Coke particle-: new ['Something'] - that's /recommended/ but not /required/, neh?
15:21 Coke (and if it's eventually going to be required, let's document the changeover in DEPRECATED.pod and start warning on the old syntax.
15:21 particle- iirc the test suite has been converted over
15:21 pmichaud aiui,   ['Something'] is not required.
15:21 pmichaud 'Something' is still valid.
15:21 particle- ok, y'all know better than me at this point, i'm sure.
15:22 Coke particle-: the test suite has NOT been fully converted.
15:22 Coke (nor has most of the codebase. =-)
15:22 flh hum, found it... "badly balanced pmc": I should definitely close curly brackets :)
15:22 Coke pmichaud: is new <STRING> eventually going to be illegal?
15:22 particle- i lose.
15:22 particle- flh: that'll do it, every time :)
15:23 pmichaud Coke: I haven't had that impression.
15:23 Coke pmichaud: k
15:23 pmichaud Coke: I think that chromatic and I were arguing for making it illegal, but allison wanted to keep it.
15:25 dalek rakudo: 4453712 | pmichaud++ | build/Makefile.in:
15:25 dalek rakudo: Refactor checks for Makefile updates so that 'make realclean' continues to work.
15:25 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​453712948d0ca39296a32034ea163cf8f38ba77
15:25 shorten dalek's url is at http://xrl.us/ben58n
15:28 Tene joined #parrot
15:29 flh particle, the funny thing being that with my original source, pmc2c did not complain about the missing bracket
15:31 particle- flh: that's a bug, and if you can get a minimal test case, it would be wonderful to report
15:33 Coke there is a LONG open bug about that.
15:33 Coke moment.
15:34 Coke check this: http://rt.perl.org/rt3/Tic​ket/Display.html?id=39313
15:35 Coke there are some things that are just dropped on the floor when using pmc2c.pl
15:35 Coke I presume this is a case of that.
15:35 Coke pmc2c.pl should pass through anything it doesn't understand to the .c (where it would presumably fail miserably)
15:37 particle- Good Idea.
15:37 purl particle-: Good Idea: Singing Christmas carols to your neighbors. Bad Idea: Singing Christmas carols to your neighbors on the Fourth of July.
15:37 particle- was that ever funny?
15:37 rdice joined #parrot
15:37 Coke what, GI/BI? clearly you're not an animaniacs fan.
15:37 particle- i am, but that one isn't funny.
15:38 particle- potty emergency?
15:38 Coke no, I'm good.
15:38 Coke ;)
15:39 rg lol. don't do that when i'm drinking :P
15:40 bsdz pmichaud: hi, do you mind taking a look at a PCT compiler prob I have. I've a nopaste.
15:40 pmichaud bsdz: sure thing
15:41 bsdz pmichaud. http://nopaste.snit.ch/16135 ; it's a boiled down snippet. i'm trying to loop through the elements of a capture but using @(..) comes up empty.
15:41 pmichaud which line is the one giving you trouble?
15:42 bsdz 88 and below.
15:43 pmichaud in func_sig?
15:43 bsdz yes. i can access each array element one by one but can't get them into a 'for' loop
15:43 pmichaud you need $<return_identifier>[0]<identifier>
15:43 pmichaud instead of $<return_identifier><identifier>
15:43 pmichaud oops, "return_identifier_list"
15:44 particle- classic failure
15:44 PerlJam Seems like there should be some DWIM there though.
15:44 bsdz hmm. i think i tried that and many other combinations.
15:44 PerlJam (I get bitten by that one occasionally too :)
15:44 pmichaud well, $<return_identifier_list> will be an array.
15:44 bsdz i'm not at my normal dev env right now but will try and give it a spin.
15:44 pmichaud PerlJam: at one point we had ? quantifiers as not returning arrays.... but that got changed.
15:45 pmichaud okay, I'm about to make a commit that adds a new opcode.  Any special rules for adding opcodes in the post-1.0 world that I should know about?
15:46 pmichaud bsdz:  you're also likely to run into a problem because $<return_identifier_list>[0] will sometimes have <identifier> as a single Match object and sometimes as an Array
15:47 pmichaud (depending on which path gets taken in the return_identifier_list rule)
15:47 dalek tracwiki: v4 | coke++ | Deprecation
15:47 dalek tracwiki: https://trac.parrot.org/parrot/wiki/D​eprecation?version=4&amp;action=diff
15:47 shorten dalek's url is at http://xrl.us/ben6at
15:47 bsdz ah okay
15:47 pmichaud you can force it to always be an array by using    <identifier>**{1}
15:50 bsdz is that something along the lines of: -          for $<return_identifier_list>[0]<identifier>**{1} {
15:50 pmichaud no, I mean in the regex/rule
15:50 PerlJam pm: speaking of ** ... we had talked about the <thingy>**',' version before and I intended on implementing it, but never did.  I've run into places where I've wanted to use it a couple of times in the last few days, so maybe I'll take a stab at it again.  Any advice or clues you want to impart upon me?
15:50 bsdz ah right
15:50 dalek tracwiki: v5 | coke++ | Deprecation
15:50 dalek tracwiki: https://trac.parrot.org/parrot/wiki/D​eprecation?version=5&amp;action=diff
15:50 shorten dalek's url is at http://xrl.us/ben6bf
15:50 pmichaud PerlJam: not beyond what we might've discussed last time.
15:51 PerlJam okay
15:51 pmichaud but look at the goal-matching parser for ideas about how to do the parsing
15:51 pmichaud that part should be easier now.
15:51 pmichaud speaking of which, I need to fix that.
15:51 PerlJam "the goal-matching parser"?
15:51 pmichaud That, and synopsis 5.
15:52 Tene ~
15:52 pmichaud oh.
15:52 pmichaud goal matching:    '(' ~ ')' <expression>
15:52 PerlJam oh, yes.  I don't really have a term for that in my head  :)
15:52 bsdz ah okay. i'll take a look at synopsis 5
15:52 pmichaud I call that the goal-matching syntax.
15:52 pmichaud bsdz: my synopsis 5 comment was for PerlJam (but you could look there, yes)
15:53 pmichaud bsdz in:
15:53 pmichaud token return_identifier_list { | <identifier> {*}                                  #= single  | '[' <identifier> [',' <identifier> ]* ']' {*}     #= multiple
15:53 pmichaud }
15:53 pmichaud argh
15:53 bsdz yep - i admit it's not elegant ;-)
15:53 pmichaud if the parser takes the 'single' path, then  $<return_identifier_list>[0]<identifier>   will be a Match object
15:53 pmichaud if the parser takes the 'multiple' path, then  $<return_identifier_list>[0]<identifier> will be an Array of Match objects
15:54 bsdz yes i think i was getting Capture when i used dumper on the first.
15:54 pmichaud thus  @($<return_identifier_list>[0]<identifier)  will give you different results depending on which path was taken.
15:54 pmichaud so to force it to be an array in both cases
15:54 pmichaud use
15:54 pmichaud | <identifier>**{1} {*}     #= single
15:55 pmichaud then in the action,  @($<return_identifier_list>[0]<identifier>)  will always be an array of Match objects
15:55 pmichaud (that you can loop over)
15:56 PerlJam bsdz: that would simplify your action for return_identifier_list  too
15:56 bsdz seems to give a "Method 'list' not found for invocant of class 'ResizablePMCArray'"
15:57 Psyche^ joined #parrot
15:57 pmichaud oh...
15:57 pmichaud right
15:57 pmichaud in that case, you also don't need the @(...)
15:57 dalek parrot: r37944 | pmichaud++ | trunk/src/ops (2 files):
15:57 dalek parrot: [lex]:  Add find_caller_lex opcode for getting lexicals from callers' scopes.
15:57 dalek parrot: Note that "make realclean" is probably required.
15:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37944/
15:57 pmichaud it's just     for $<return_identifier_list>[0]<identifier> { ... }
15:57 pmichaud (because it's already an array)
15:58 bsdz doh - sorry
15:59 bsdz does appear to be working as I expect now even with out the **{1} modifier. hmm :/ are there any more docs on that modifier syntax - looks very handy?
15:59 bsdz thank a lot btw :)
16:00 pmichaud that's just a quantifier
16:00 pmichaud same as   **{1..4}   # match 1 to 4 times
16:01 pmichaud the use of the quantifier forces it to be an array of matches instead of just a match
16:01 bsdz of course! i've think i've been looking at too much other stuff today
16:01 bsdz thanks again
16:18 schinkelm joined #parrot
16:30 AndyA joined #parrot
16:31 Khisanth joined #parrot
16:45 braceta joined #parrot
16:53 AndyA joined #parrot
16:54 jrockway joined #parrot
17:01 pmichaud #parrotsketch in ~90
17:12 darbelo joined #parrot
17:16 PacoLinux make spectest now 19m12.009s :)
17:16 acajou joined #parrot
17:19 allison joined #parrot
17:22 particle1 joined #parrot
17:22 Coke pmichaud: did you run 'make opsrenumber' ?
17:22 Coke (don't do that.)
17:26 * Coke moves to email on that one.
17:29 PerlJam Coke: given the "don't do that" nature of it, it sounds like someone should make it say "Don't!  If you *really* want to ..." by default.  (assuming it's a useful tool for someone)
17:29 Coke PerlJam: a ticket has already been opened on this.
17:29 Coke ISTR that kid51 is working on it.
17:29 PerlJam cool.
17:30 Coke not that particular item, but "why does opsrenumber suck in a post 1.0 world."
17:32 eternaleye joined #parrot
17:33 PerlJam well, still cool
17:43 Tene purl: parrotsketch?
17:43 purl parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
17:43 Tene ah, next hour
17:44 cotto Coke, (wrt tt #543), the duplicate copyright test passes for me.
17:45 cotto Do you have any idea why it'd pass for me but not you?
17:48 Infinoid Coke: I think I offered previously to rewrite opsrenumber.pl to be as non-invasive as possible... that offer still stands :)
17:48 cotto it seems that your machine dtrt
17:56 dalek parrot: r37945 | chromatic++ | trunk/docs/project/branching_guide.pod:
17:56 dalek parrot: [docs] Updated references to svn.parrot.org from svn.perl.org.
17:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37945/
17:56 chromatic joined #parrot
17:57 pmichaud I did do opsrenumber, yes.
17:57 pmichaud If that's an oops, I need to know what the correct procedure is now.
17:59 dalek parrot: r37946 | chromatic++ | branches/headercleanup:
17:59 dalek parrot: Created branch to clean up headers and move code into subsystem directories
17:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37946/
18:05 Coke pmichaud: there's a ticket about it in trac. ISTR that kid51 was working on it.
18:05 pmichaud I also replied to list message (just now)
18:05 Coke my concern being that doing a renumber now makes any future PBC migration hard.
18:05 gryphon joined #parrot
18:05 NotFound hi
18:05 Coke (even though we're not doing that right now)
18:06 dalek parrot: r37947 | moritz++ | trunk/docs/book/ch02_getting_started.pod:
18:06 dalek parrot: [docs/book] delete reference to snapshots that are 404s now
18:06 Coke NotFound: namaste
18:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37947/
18:06 pmichaud right, I was under the impression that we're not yet too concerned with ops numbering
18:06 Coke pmichaud++
18:06 Coke no, but there's no sense chumming the water.
18:07 pmichaud So, should I revert+fix ops.num, or leave it for now?  Either way is likely to require realcleans.
18:09 moritz do we still do cpan releases? If not, ports/cpan/pause_guide.pod could go away
18:09 cotto Coke, which perl are you running?
18:09 chromatic I believe the biannual releases will go on the CPAN.
18:09 particle- that's my recollection
18:09 moritz chromatic: thanks
18:10 Coke cotto: 5.10
18:10 Coke "what chromatic said."
18:10 Coke 1.0 is already on the cpan.
18:10 cotto I'm on 5.8.8.  The copyright test passing on my system might be due to that.
18:11 Coke cotto: that's freaky.
18:11 barney joined #parrot
18:11 cotto Coke, it's just a guess.
18:12 gryphon_ joined #parrot
18:12 cotto If I remove the $ from the end of $copyright_parrot, it dtrt
18:12 allison Coke/pmichaud: yes, we're still doing ops renumbering
18:12 pmichaud yay.  I don't have to undo, then?
18:12 allison pmichaud: aye
18:13 pmichaud yay * 2.
18:13 Infinoid chromatic: Santtu++ has posted some patches to TT #18 to fix the nonexecutable-heap issue on selinux/fedora.  He followed a different approach which reasonable to me, but I was wondering if you had any feedback before I started committing that stuff.
18:13 chromatic I thought (but am not arguing for) we were going to renumber ops only once, right before the 1.4 release.
18:13 chromatic Infinoid, I haven't browsed them yet.  I will.
18:13 Infinoid When we discussed this issue, you suggested fixing up ManagedStruct with a custom free() pointer, which I failed to do.  He just added a JitCode PMC instead, which seems pretty clean
18:14 Infinoid Thanks
18:14 Coke allison: I think that's going to make it much harder to do retroactive bytecode translation, which I know we're not doing now, but would be nice to have.
18:14 chromatic I'm not a huge fan of adding yet another special purpose PMC, but... it does look cleaner.
18:15 chromatic Then again, I suspect that UnManagedStruct might need a custom free() pointer anyway sometimes.
18:15 Infinoid He's got some further plans regarding splitting jit buffer allocation into "write" and "executable" phases, which apparently will make selinux happier.  But I wanted some review before he got too far into that, to avoid wasted effort
18:15 allison Coke: yes, we do ops renumbering on a deprecation cycle
18:16 allison Coke: and support for backward compatibility also happens on the deprecation cycle
18:16 Infinoid I think the problem with the custom free() pointer approach is that munmap() required the right "size" argument, which my patch wasn't doing correctly.  So it's more than just the pointer to the free() function itself
18:16 jhorwitz joined #parrot
18:16 Coke allison: what is the point of renumbering the ops, though?
18:17 Infinoid If you still think it's better to put all of that stuff in UnmanagedStruct, I'll see if I can rework it
18:17 allison Coke: but, when we have a deprecation notice in (which we do for 1.4) there may be several changes between two supported releases
18:17 Coke I'm arguing specifically about future attempts to translate bytecode.
18:17 chromatic Infinoid, this seems like one example of a case where we need a C function to free() memory allocated from C.  I can imagine that NCI bindings may have to do the same thing too.
18:18 Coke (where we'll have to now remap a ton of opcodes that we would otherwise be able to just leave alone)
18:18 allison Coke: renumbering is for code sanity, and we're still adding and removing substantial numbers of opcodes
18:18 Coke s/a ton of/pretty much every/
18:18 Coke Ok. -1 from me.
18:18 allison Coke: right, but we're not going to retroactively do bytecode translations for all previous versions of bytecode
18:19 Coke not now. =-)
18:19 allison Coke: when we have support for multiple versions of bytecode, then we'll establish a bytecode policy that works with the implementation
18:20 allison Coke: right now, we'd just be making a guess at what policy might possibly work with the future implementation
18:20 Infinoid chromatic: ... as opposed to letting the object expire so the GC/destroy function can do it?  I'm not sure what you mean.
18:20 allison Coke: and the guess is just as likely to be wrong as right
18:20 Coke Yes. I'm fairly certain that renumbering ops will be more painful in that regard than not. I'm willing to stand by that guess.
18:20 Coke but it doesn't matter.
18:20 allison Coke: so we might as well stick with the policy that works for the current implementation
18:21 chromatic Infinoid, if Parrot didn't allocate the memory (from a GC pool), Parrot won't be able to destroy it.
18:22 Coke allison: respectfully disagree, but ok.
18:22 Infinoid So you're arguing for a more general approach.
18:22 allison Coke: fair enough :)
18:23 chromatic Right.  I think we have to solve that problem generally anyway.
18:23 Infinoid I'm going to have to add a buffer-size attribute to UnmanagedStruct to get it working, I think that's the only implementation detail worth noting.
18:24 Infinoid I suppose other allocation models might have their own weirdnesses.  But that's just handwaving, not really an argument, so I'll JFDI.
18:24 chromatic If we're clever, I don't think we even have to add that....
18:24 Infinoid Well, my current patch fails because munmap() doesn't get the right size parameter.  I'm certainly open to ideas.
18:24 Infinoid (This kind of thing makes me wish C had closures.)
18:25 chromatic We need to store it somewhere, but in theory we *could* store the size as the first four bytes of the mmap()ed chunk.
18:26 dalek parrot: r37948 | NotFound++ | trunk/compilers/imcc/parser_util.c:
18:26 dalek parrot: [imcc] fix a C warning/C++ error
18:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37948/
18:26 Infinoid I suppose so.  I'd worry about alignment, but hey, if someone needs strict alignment they can do it themselves.
18:28 chromatic Presumably anything returned from mmap() will be aligned properly to start.
18:29 chromatic #ps in 2
18:29 Infinoid Yeah, it's still dword-aligned.  We won't be using this interface for I/O buffers so we don't have to care about page alignment, either.  So I think we can make it work
18:31 Infinoid That said, it's going to make the two-staged (write+noexec -> readonly+exec) allocation model Santtu wants ... interesting
18:31 chromatic How so?
18:32 Coke allison: reopened the ticket regarding opsrenumber so that jim can revert the tests back to the way they were.
18:32 allison Coke: ticket #?
18:33 Coke https://trac.parrot.org/parrot/ticket/489
18:33 Coke (in which tests failed, I complained about the tests in light of my stance here about ops renumbering, and jim fixed the test to compensate for my complaint.)
18:33 Coke I suggested to him that perhaps he revert the test change to the way it was.
18:35 allison Coke: appears to be related to https://trac.parrot.org/parrot/ticket/469 (poor Jim, serving two masters)
18:36 Infinoid chromatic: If we have two kinds of buffers with different mmap flags, I'm guessing it would be nice to be able to store the current status of that somewhere.
18:37 Coke That's what he gets for listening to me.
18:37 Infinoid But this can wait until after #ps
18:37 Coke is that now?
18:37 chromatic Sounds almost like defining a struct for JIT and storing that pointer in the PMC.
18:37 Coke irc logs?
18:37 purl irc logs are nothing like http logs...  very low overhead and storage
18:37 Coke irclogs?
18:37 purl somebody said irclogs was http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
18:38 moritz also s/parrot/parrotsketch/
18:39 dalek parrot: r37949 | chromatic++ | branches/headercleanup (13 files):
18:39 dalek parrot: Moved src/interpreter.c and src/interp_guts.h into src/interp/.
18:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37949/
18:45 chromatic Hm, we could get down to 550 open tickets by the next release.
18:45 Coke 258+378
18:45 purl 636
18:45 Coke no we can't. =-)
18:46 Coke I could see 600.
18:46 chromatic A lot of those 378 can just go away with a bit of review.
18:47 chromatic One ticket closed per committer per day is 140 tickets.
18:47 Coke I don't see it happening. (a lot of that low hanging fruit has already been plucked from RT)
18:49 cotto I'm sure a lot of them can die once the right person looks at them, but that's the trick.
18:49 chromatic Exactly.
18:49 Infinoid pmichaud: Apologies, I haven't yet found tuits for figuring out why your icu patches cause segfaults here.
18:52 Santtu joined #parrot
18:57 Infinoid Santtu: [11:37] <@chromatic> Sounds almost like defining a struct for JIT and storing that pointer in the PMC.
18:57 Infinoid (the ManagedStruct PMC, he means)
18:58 Coke chromatic: when merging that back to trunk, watch out for changes to renamed files.
18:59 chromatic Coke, I'm fairly confident that these files are stable enough that that won't hurt too much.
19:00 Infinoid Santtu: When you start working on your two-stage jit buffer allocation model, what kind of additional state will you need to keep?  The JIT state struct seems like a good idea, just because the amount of state may grow
19:00 Santtu I'm not sure how JIT code is shared between interps/threads, but if the interp clone routine does a copy of globals, including the _XJIT_ from NCI then the JIT code itself needs to be copied too.
19:00 Coke chromatic: did you not run mk_manifest on purpose to make the merge simpler? =-)
19:00 Infinoid Right, so you'll need a custom clone as well as custom destroy to get this working with ManagedStruct
19:01 Coke chromatic: also, you shouldn't be renaming things in ports/cygwin, I wager.
19:01 Coke since those refer to the 1.0.0 that ws.
19:01 Coke "was"
19:01 Santtu And the safe method to do JIT code is to first get rw page, write code to it, then change it to rx. So exec-capable page allocation is three-step process, first get writable page, then write stuff to it, then mark it read-executable but without write permissions.
19:01 chromatic Ugh.
19:01 Infinoid (a shallow copy won't work for jit buffers... they will just copy the jit structure, not the mmapped buffer)
19:01 Whiteknight joined #parrot
19:01 Coke you could always just renaming /everything/ in the branch and not merge those files back.
19:02 rob joined #parrot
19:03 Santtu And I think you'd really want to share NCI JIT pages between interpreters, since they're more or less static. I'm not familiar with that part of parrot so I don't know whether PMCs can be shared between interps or not.
19:03 chromatic They can.
19:04 Santtu Global GC?
19:04 Theory joined #parrot
19:05 tewk Santtu: do we have to grab a whole page per NCI jit?  NCI jits are usually pretty short.
19:05 chromatic We mark the shared PMC as shared, so child interpreters don't try to free it.
19:06 Santtu tewk: Yes. mprotect works on a page level.
19:06 Infinoid If you differentiate between writable pages and executable pages, you'd have to flipflop the permission bits as you try to write more to the buffer, and somehow prevent other threads from executing anything in the buffer during that process
19:07 tewk I knew NX was going to be a pain in the butt
19:07 Santtu So it is 4k or 8k typically. It'd be useful to at some point walk the NCI code through and coalesce multiple NCI stubs into a single page, but that is premature optimization at this point, since I'd just want to get the JIT code working even on selinux-enabled box (which it won't do without mmap+mprotect changes.)
19:08 Infinoid selinux prevents RWX pages, right?
19:08 Santtu Yeah. Silently. You just run into segv.
19:08 Infinoid Beautiful.
19:08 purl it has been said that beautiful is a love thing
19:08 tewk thats really inefficient
19:08 Santtu RWX gets downgrated into RX, then you try to write and ...
19:10 tewk Well I guess we could calesce jits during a gc op and fixup NCI PMCs to point to the new coalesced versions.
19:10 Santtu NCI code is PIC, so you could just generate N stubs and keep count until you've got a full page, then go back and copy those over to a new page and update the NCI stub pointers.
19:10 Infinoid Hmm.  You'd not only have to prevent other threads from executing within the buffer while you're appending to it, you'd also have to detect when other threads have already called through the buffer to something that hasn't returned yet
19:10 Infinoid That sounds painful
19:11 Santtu JIT typically is :-)
19:11 chromatic Hooray for not maintaining our own JIT!
19:11 Infinoid Is LLVM on our roadmap?
19:11 Infinoid (or something similar, I dunno what's out there)
19:12 Santtu I've worked on a system that JITted stuff into kernel-mode code, that'd be fun, single incorrect insn and panic :-)
19:12 particle- it's on our list of gsoc projects :)
19:13 Santtu anyways, there's two unrelated problems: unused memory on underfilled pages, and jit-specific pmc vs. extending managedstruct pmc to store the JIT pages.
19:14 Santtu The first one has no nice or simple solution, since you do end up with page coalescing on concurrent threads of execution with nice liveness issues related to call stacks.
19:14 Infinoid For ManagedStruct to work, you'd need custom destroy and custom clone methods.  I'm starting to think a subclass would be cleaner than a bunch of function pointers in attrs
19:15 Infinoid but ... the custom destroy and custom clone methods are the *only* requirements I can think of, from the jit buffer perspective.  Does it need to be a subclass of ManagedStruct at all?
19:16 chromatic I'm not sure what a subclass offers, in that case.
19:16 Infinoid it offers a cleaner way to override destroy() and clone(), that's all.
19:17 chromatic Sounds more like a ManagedBuffer.
19:17 Santtu I'd like to point also that since ManagedStruct subclasses UnManagedStruct, it comes with a lot of methods that don't make sense with jit code. If you'd ever later want to hand PMCs holding JIT code to PIR level for processing (peephole optimization, anyone?) you could break a lot of things quickly..
19:17 Infinoid or ManagedPointer
19:18 chromatic We already have a CPointer PMC, but it probably doesn't do the right thing here.
19:18 Santtu ManagedPointer, then subclass JitCode from that for the specific clone/destroy?
19:19 dalek tracwiki: v145 | allison++ | ParrotRoadmap
19:19 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Par​rotRoadmap?version=145&amp;action=diff
19:19 shorten dalek's url is at http://xrl.us/ben67p
19:19 chromatic Rather than adding two PMCs, let's stick with one until we need to generalize more.
19:20 Santtu Is the solution then to generalize ManagedStruct more and add custom clone/free handlers (function pointers)?
19:20 allison CPointer is very simple and could certainly have more features added (rather than making another PMC that does mostly the same things)
19:21 chromatic I'd rather see CPointer expanded, if we can make it work.
19:21 chromatic Hm, src/interp/interpreter.c (nee src/interpreter.c) has very little about interpreters in it.  It mostly works on runcores and dynops.
19:22 Infinoid We can make ManagedStruct or CPointer work.  We'd just be putting most of the jit-specific stuff into a jit-specific structure, rather than having a jit-specific pmc.  Which one makes a better base?
19:22 Santtu I don't think JIT code needs really anything except a place to stash pointer + size info, plus custom destroy and clone handling. I would prefer it to have *nothing* else available, since the need is very specific.
19:22 Infinoid We have two patches that do this in different ways... I'm willing to adapt the stuff we already have to play nicely with whatever we decide here
19:26 Santtu What would be the semantics for ManagedPointer or ManagedMemory be? I noticed that there's already sockaddr PMC that doesn't really do much more than wraps a known struct (sockaddr_in) and handles its allocation/destruction, and nothing more?
19:27 allison chromatic: src/interp/interpreter.c sounds like a candidate for a file-rename
19:27 Whiteknight allison: agreed
19:28 chromatic Oh, it's already on my list.
19:28 chromatic I'm going to move its functions into src/ops/dynops and src/runcores/foo.c (better name welcome) and there'll be nothing left.
19:29 allison chromatic: src/ops?
19:29 allison src/ops is just for *.ops files and ops.num, not for general C functions
19:30 allison +1 on src/runcores
19:31 allison chromatic: if it really is about calling opcodes, then src/call/ops.c might make sense
19:31 chromatic Where else would you stick files related to the ops subsystem?
19:31 allison (it already exists)
19:31 chromatic Already existing is a plus.
19:31 chromatic Most of these functions are about registering and initializing ops.
19:32 allison then maybe src/runcores/core.c
19:32 allison or src/call/core.c
19:32 Infinoid Santtu: Sockaddr is a placeholder for now until we start getting a lot smarter about sockaddr_in, sockaddr_inet6, etc.  It's support infrastructure for the (similarly new) Socket PMC
19:33 cotto eternaleye, I recommend you ignore docs/pmc.pod.
19:33 allison chromatic: the core.c file in each subsystem contains the pieces that need to be initialized in the interpreter for the subsystem to run
19:33 cotto I'm going to rewrite and update it as soon as I get rid of the PMC_x_val macros.
19:33 cotto If it'd be helpful to you, I could do it sooner.
19:34 Infinoid Santtu: it sounds like we're going to wrap all the needed functionality into ManagedStruct or CPointer directly.  They both have a lot of extra stuff we don't need, but if we're actually using it to store a pointer to a JIT structure, ManagedStruct seems a little more appropriate than CPointer does
19:34 chromatic I prefer src/runcores/core.c
19:34 chromatic They're not really about calling things.
19:34 particle- (src/runcores/core.c)++
19:35 allison chromatic: makes sense
19:35 Infinoid Santtu: Does that seem reasonable to you?  I can rework the patch that's already up there, and if you have any other outstanding changes, I can adapt them as well
19:36 Santtu infinoid: If so, then should jit-specific stuff be subclassed from managedstruct (unmanagedstruct->managedstruct->jitcode), or have custom free/dup handlers (like ManagedStruct_free_ptr_t in your 02 patch in TT#18?
19:36 cotto tewk, ping
19:37 Infinoid It sounds like we want custom free/dup handlers, an extension of the 02 patch.
19:37 Infinoid But we also want to use it in a slightly different way, with an nci buffer struct sitting between the ManagedStruct object and the actual mmap buffer
19:37 Infinoid I am a little nervous about adding custom clone and destroy methods that can't be tested directly from PIR space, does anyone have suggestions about that?
19:38 tewk cotto: yes
19:38 cotto tewk, will you have the tuits to look at TT #365 within the next week or so?
19:38 Santtu Ummm... why? There's already PMC subclassing, why use function pointers when just subclassing the PMC you could do all without them?
19:39 tewk I just glanced at it, dont have a co copy of parrot who wrote " /* TT #365 - Some i386 jit code depends on this.  If t/pmc/nci.t "
19:39 NotFound Infinoid: adding methods to set them to nci functions.
19:40 Infinoid Santtu:
19:40 Infinoid [11:14] <@chromatic> I'm not a huge fan of adding yet another special purpose PMC, but... it does look cleaner.
19:40 Infinoid [11:15] <@chromatic> Then again, I suspect that UnManagedStruct might need a custom free() pointer anyway sometimes.
19:40 Infinoid So I think the motivation is just to be able to reuse this infrastructure later
19:40 cotto tewk, that's fine.  I just noticed that Whiteknight++ gave it his +1.
19:41 Whiteknight I need to do more testing, but it looks sane
19:41 NotFound I'd like to have a way to set a custom free, the Xlib module will benefit from that.
19:42 Infinoid tewk, Whiteknight, the reason I wanted more review is because I'm not familiar with JIT at all, and wasn't sure I was handling temp_calls_offset correctly
19:42 NotFound And be able to set it from pir, to a function imported with nci
19:42 Whiteknight Infinoid: Okay, I'll double-check that for you
19:43 Infinoid and whether the stuff at args_offset was already set up properly, and all of that
19:44 Infinoid I mean, I guess it had to be if it runs at all.  But extra eyeballs can't hurt
19:44 tewk Infinoid: I'll try to take a look tonight, do all the pmc/nci.t tests pass? if so its probably safe.
19:44 Santtu The problem with JIT code is that you must keep hold of the size information and pass it to the free routine. That is *really* exceptional -- no other allocator interface has that requirement (until you go to kernel-land, but that's another issue). So trying to keep stuff generalized based on that requirement might give a does-not-really-fit-any-size solution..
19:44 cotto tewk, all of t/pmc/nci.t passes
19:45 Infinoid Amazingly enough, they seem to.
19:45 tewk Thats a good sign.
19:45 Santtu (okay apart from apache-style region allocators, but interfacing with them isn't probably be solvable with the size parameter either)
19:46 NotFound Santtu: c++ allocators come to mind
19:47 Infinoid Santtu: True.  But the jit struct saves us from having to add size handling to ManagedStruct directly
19:47 Infinoid (and also saves us from having to worry about how many arguments the free function takes)
19:47 cotto Whiteknight, lmk when you've checked.  I'm ready to commit whenever.
19:47 Whiteknight I'm not going to get to it till tonight. I'll send you a msg or somethign when I do
19:47 Infinoid In this case, we're just "managing" the jit struct, which seems reasonable enough
19:48 cotto Whiteknight, ok.
19:49 Santtu How'd you make region allocator work with ManagedStruct?
19:50 Infinoid You mean in mod_parrot?  I have no idea
19:51 * jhorwitz perks up
19:51 Coke chromatic: have fun re-headerizing. =-)
19:51 chromatic No kidding.
19:52 Coke headerizer sucks, btw. seems to be a custom run based on your build.
19:52 dalek tracwiki: v1 | allison++ | NamespaceTasklist
19:52 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Name​spaceTasklist?version=1&amp;action=diff
19:52 dalek tracwiki: v10 | allison++ | IOTasklist
19:52 shorten dalek's url is at http://xrl.us/ben7cd
19:52 dalek tracwiki: https://trac.parrot.org/parrot/wiki/I​OTasklist?version=10&amp;action=diff
19:52 Santtu infinoid: With ManagedStruct specifically, since region allocator free routine takes two pointers (region + memory within the region).
19:52 shorten dalek's url is at http://xrl.us/ben7cf
19:52 Coke (so if you build with jit, you headerize more).
19:52 Coke Still beats the alternative.
19:52 chromatic Rather than saying it sucks, let's call it not yet complete.
19:53 Infinoid Santtu: I'm not sure we've ever tried to wrap a ManagedStruct around an apache region-allocated object.  I think jhorwitz is the mod_parrot author, so if anyone has tried, it'd be him
19:53 Santtu Since JIT code custom free routine needs size parameter, and region allocators need additional pointer, that's not really one-size-fits-all custom callback free?
19:54 * jhorwitz has done many things he's not proud of
19:54 Infinoid jhorwitz: Don't worry, we love you anyway.
19:54 jhorwitz that's why i keep coming back
19:54 particle- jhorwitz: ...do you work out?
19:55 jhorwitz ah particle, the memories are still fresh
19:55 Santtu e.g. the 02 patch has "typedef void (*ManagedStruct_free_ptr_t)(void*, size_t)" type, for region allocators it'd need be (...)(void*,void*).
19:55 dalek tracwiki: v63 | allison++ | WikiStart
19:55 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=63&amp;action=diff
19:55 shorten dalek's url is at http://xrl.us/ben7cy
19:56 jhorwitz Infinoid: mod_parrot uses UnManagedStruct only, letting NCI code access any Apache-specific data
19:56 Santtu Maybe it should really be (*)(PMC*) and let the custom free routine pull out necessary bits from the PMC?
19:57 Infinoid Santtu: Yeah.  My current thinking is void (*)(void*), but we pull the additional stuff from within the void*
19:57 Infinoid jhorwitz: Do you have to worry about freeing the data, or does apache do that internally?
19:59 jhorwitz i was very careful to make sure that data in apache structures is allocated by apache, and parrot data is allocated by parrot.  so for apache structures, apache will free the data when its pool is destroyed.
19:59 Infinoid Ok, so you were able to sidestep our issue. :)
19:59 jhorwitz i didn't read back far enough to understand the issue, but i'm glad i don't have to now.  :)
20:00 Santtu infinoid: If the PMC_data(self) field contains pointer to struct with meta-information, then that totals 3 separate allocations for each NCI stub (JIT code, PMC and meta-structure). Is memory fragmentation an issue?
20:02 Santtu jhorwitz: How does mod_parrot ensure that apache pool references are not referenced after the pool is destructed (after request is finished)? Or is it a non-issue by requiring that the user must not hold to references to pool memory?
20:02 Infinoid Memory fragmentation an issue?  Have you *seen* how many GCable elements we throw away on average per pir op? :)
20:03 Santtu JIT code stays around forever.. (almost)
20:03 PerlJam pmichaud: ping
20:03 Santtu .. and doesn't move around .. if it is smack in the middle of some page then the allocator cannot coalesce it ..
20:03 Santtu (or 2^N region)
20:03 jhorwitz Santtu: verifying something.....
20:04 PerlJam (or anyone), how do I visually inspect the structure of a match object? Isn't there a way to dump it to stdout?
20:04 Santtu .. and there's probably a lot of JIT code, from both NCI and I guess eventually from jitting actual PIR code too (?)
20:04 Infinoid We don't have a compacting GC yet
20:05 Infinoid Yeah.  That goes to your other issue of what to do with partially filled jit buffers
20:05 Santtu Not GC, the PMC is the only GCable object there. JIT code and meta-structure would come directly from system allocator (well, mmap + system allocator). Okay, the mmap page isn't an issue since it is handled by system. On UNIX. On windows it would be from heap...
20:06 Santtu I'd think that Many Objects × Many Small Allocations × Long Lifetime => Slab/Region Fragmentation :_)
20:06 jhorwitz Santtu: it's possible that PIR/HLL code could hold onto an [APR;Pool] object that references a destroyed pool.
20:07 Santtu jhorwitz: But is that user's problem? E.g. "don't do that"?
20:07 pmichaud PerlJam: pong
20:08 pmichaud PerlJam: you can try   _dumper(match)
20:10 PerlJam do I have to load_bytebode 'dumper.pir' or something?
20:10 PerlJam ah, so I do.  nevermind
20:10 PerlJam (I had PGE/Dumper.pir, but not dumper.pir)
20:10 Infinoid Santtu: I'm not sure what you're trying to say, but I don't think the additional struct is an issue
20:11 pmichaud PerlJam: also, you might want to know that  PGE understands  'target'=>'pir'  and 'target'=>'pge::exp'   and 'target'=>'parse'
20:11 jhorwitz Santtu: yes, but it's unlikely to happen anyway.  most apache pools you would use will be destroyed when the request ends, along the lexical variables referencing them.  now, if you referenced a short-lived pool as a persistent global, then you're digging your own grave.
20:11 pmichaud very useful for debugging changes to Perl6Regex
20:11 Santtu Anyway. Should the JIT in NCI ManagedStruct just use some struct Jit_NCI_Bridge allocated and stuffed to PMC_data and reference that in custom free/clone?
20:11 Santtu jhorwitz: agree on that
20:11 chromatic That seems the least invasive right now.
20:13 PerlJam pmichaud: when I do  mob.'new'(mod, ...)   Do I just get a new "empty" match object, or is it cloned from the original and then morphed into whatever I've asked for in the ... portion?
20:13 PerlJam s/mod/mob/
20:13 Santtu And for the fragmentation.. NCI could chain JIT allocations and keep a running count of the sizes, and at suitable point coalesce multiple pages, replace the _XJIT_ references (to sub-page addresses) and let the GC handle the no-longer-referenced old NCI JIT PMCs.
20:14 pmichaud PerlJam:  .'new'  returns a new Match object
20:14 pmichaud its .from is set to the current position of whatever was passed to it, and it's set as a failed match
20:14 PerlJam pmichaud: how do I clone one?
20:14 pmichaud I don't know that you clone one.  You shouldn't need to clone one.  (more)
20:14 pmichaud oh, the new Match object has its target already set to the same target as the mob you passed in.
20:15 pmichaud it's basically a clone with updated .from and .to
20:15 PerlJam target, from and to ? or just target and from?
20:15 pmichaud (.to being set to a value that causes the Match to act like a failed match)
20:15 pmichaud (I think .to is set to -1 )
20:15 pmichaud a failed Match is one where .to < .from
20:16 PerlJam okay, thanks
20:16 moritz so you don't support reversed Match objects? ;-)
20:16 pmichaud I do not.
20:17 pmichaud *something* has to be straight>forward< somewhere!
20:17 pmichaud :-P
20:17 moritz lol
20:18 PerlJam Just following the precedent of the arrow of time?  :)
20:18 pmichaud It's a darn good precedent, and anyone who disagrees can go back and fix it.
20:19 pmichaud which, iirc, Damian did choose to do at last year's OSCON keynote :-P
20:20 PerlJam When you're a Q, time doesn't really matter.
20:20 moritz (that conversation above would be worth submitting to bash.org - then again I think that most readers wouldn't appreciate its humor)
20:20 pmichaud my humor is often underappreciated.
20:21 particle- very funny.
20:21 purl Thanks, I'm here all week.
20:23 rg moritz: you can put it there: https://trac.parrot.org/parrot/wiki/ParrotQuotes
20:24 moritz rg: thanks
20:28 dalek tracwiki: v8 | moritz++ | ParrotQuotes
20:28 dalek tracwiki: https://trac.parrot.org/parrot/wiki/P​arrotQuotes?version=8&amp;action=diff
20:28 shorten dalek's url is at http://xrl.us/ben7hc
20:34 sjn joined #parrot
20:36 bacek good morning
20:36 bacek Coke: pong
20:36 Tene joined #parrot
20:36 * bacek hates DST...
20:37 Coke bacek: yes, I've seen your CLA.
20:37 bacek Coke: that's good :)
20:37 Coke Infinoid: were you mentoring?
20:38 Coke I can't see how to add commit bits. =-)
20:39 Infinoid Coke: Yes, I can mentor
20:40 cotto Coke, I'd also be interested in helping mentor the person who's doing libdecnumber integration.
20:43 chromatic Is there a Configure.pl option only to regenerate makefiles?
20:46 Coke I'm referring to mentoring a new committer, not mentoring a GSOC candidate.
20:46 Coke if you're interested in that, sign up with dukeleto.
20:46 Coke chromatic: you could try to run just that step.
20:46 Coke I would just rerun the whole damn thing.
20:47 Coke bacek: do you have a trac id?
20:48 bacek Coke: yes, "bacek"
20:48 acajou left #parrot
20:48 cotto dukeleto, ping
20:48 chromatic Yeah, I know some people like to make realclean then reconfigure and make the whole thing for every commit, but one of the reasons for maintaining a makefile is so that you don't have to do that whole thing every time.
20:50 Coke chromatic: like to? absolutely not. Want to fix configure? not that either.
20:50 Coke we could probably rip out 70% of configure and put it into makefiles.
20:50 moritz usually 'make' works pretty well for me
20:50 Coke bacek, Infinoid: bacek is now a committer, which ISTR was approved last #ps.
20:51 Coke Infinoid: usual caveats about your minion breaking anything.
20:51 Infinoid bacek: please don't break anything, kthx :)
20:52 bacek Infinoid: I'll try :)
20:52 bacek Coke: where I can find password for svn?
20:53 rg bacek: same as trac
20:53 Coke bacek... did you try your trac id? =-)
20:54 bacek Coke: not yet :) It's 7AM here and I'm little bit scared to commit anything at this time
20:54 particle- you can update credits
20:54 particle- or add your name to release managers for some month this year ;)
20:56 bacek particle-: Can it be post-2.0 release? :)
20:57 bacek Infinoid: I want to create "packfile_revamp" branch in svn. Any objections?
20:58 Infinoid No objections
20:59 bacek Infinoid: ok.
20:59 * bacek reading "git svn --help" to understand how to do it
21:00 moritz bacek: there's a branching guide somehwere in doc/
21:00 Infinoid if it were me, I'd create it with svn and then do a fresh git-svn checkout of just the branch
21:00 Infinoid But that's because I've never really figured out git-svn's branch handling.
21:00 chromatic perldoc docs/projects/branching_guide.pod
21:01 bacek chromatic: thanks
21:01 Tene Infinoid: just use -s or --stdlayout and svn branches become git branches.
21:01 moritz I have also a git clone of parrot including all branches
21:01 moritz hm, I would have searched for that in docs/dev/
21:01 dalek parrot: r37950 | chromatic++ | branches/headercleanup (6 files):
21:01 dalek parrot: Moved the other src/interp_*.c files into src/interp/, updating all references
21:01 dalek parrot: to them elsewhere (mostly documentation and comments).
21:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37950/
21:03 Coke chromatic: bah. I am juggling 10 branches here at work.
21:04 chromatic Yeah, but you're a mathematician.
21:11 PerlJam and a juggler apparently
21:13 * Coke is a juggler. Can only do 3-at-a-time, though.
21:13 Infinoid (the rest are emulated using timeslices)
21:13 pmichaud I can see why 10 is a problem, then.  :-)
21:14 PerlJam I can juggle 6 clubs ... if I have a partner sharing the load :)
21:14 Coke hurm. I could potentially do that, though I have no one to practice with. I sense a BOF.
21:15 dalek parrot: r37951 | bacek++ | branches/packfile_revamp:
21:15 dalek parrot: Created branch for improving packfile*.pmc
21:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37951/
21:24 Infinoid I'd like to learn that
21:24 Infinoid Don't all start throwing clubs at me at once tho.
21:24 Coke I can teach you how to juggle like my dad taught me how to swim.
21:24 * Infinoid can juggle 3, but hasn't tried any team stuff
21:28 dalek parrot: r37952 | allison++ | branches/pcc_rewiring:
21:28 dalek parrot: Creating branch for refactoring calling conventions, rewiring the internals of pcc dispatch.
21:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37952/
21:29 register joined #parrot
21:30 PerlJam Infinoid: you can juggle 3 clubs?
21:30 register what is missing from bigint?
21:30 cotto seen dukeleto
21:30 purl dukeleto was last seen on #pdx.pm 7 hours, 10 minutes and 7 seconds ago, saying: register: yes?
21:30 cotto seen dukeleto in #parrot
21:30 Infinoid Yeah.  Haven't practiced in a long time tho
21:31 bacek "git svn dcommit" in action
21:31 dalek parrot: r37953 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
21:31 dalek parrot: Remade t/pmc/packfile.t in pure PIR.
21:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37953/
21:32 bacek afk # morning duties: kids, breakfast, etc.
21:34 Coke I haven't done clubs. are there special clubs or can I use like lawn bowling pins? =-)
21:35 dalek parrot: r37954 | bacek++ | branches/packfile_revamp/t/native_pbc (6 files):
21:35 dalek parrot: Rebuild few t/native_pbc/*.pbc
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37954/
21:35 dalek parrot: r37955 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
21:35 dalek parrot: Simplify slightly packfile loading
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37955/
21:35 dalek parrot: r37956 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
21:35 dalek parrot: Move helper function to the end of file
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37956/
21:35 dalek parrot: r37957 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
21:35 PerlJam Coke: they're special enough.  www.dube.com
21:35 dalek parrot: Factor out _filename function. It will be useful for testing on different platforms
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37957/
21:35 dalek parrot: r37958 | bacek++ | branches/packfile_revamp/src/packfile.c:
21:35 dalek parrot: Fill padding with zeros during pack
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37958/
21:35 dalek parrot: r37959 | bacek++ | branches/packfile_revamp/src/packfile.c:
21:35 dalek parrot: Fill one more padding with zeros
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37959/
21:35 Coke PerlJam: european or american?
21:36 rg bacek: if you need some native_pbc files for big endian, just ask ;)
21:36 Coke holy #*(&. 41 bucks a PIN?
21:36 cotto It's getting kinda branchy in here.
21:36 * Coke guesses bacek is using git2svn.
21:36 bacek rg: I definitely need them :)
21:36 PerlJam Coke: theres are cheaper manufacturers.  Generally the pros use dube though :)
21:37 Coke PerlJam: ok. for practice, I'll check out something cheaper. =-)
21:37 Casan joined #parrot
21:37 Infinoid bacek is importing the last week's worth of patches from http://github.com/bacek/pa​rrot/tree/packfile_revamp, I imagine
21:37 PerlJam Coke: dube has various pricing too. Not sure how their cheaper clubs compare though
21:37 bacek Infinoid: yes I am :)
21:38 rg bacek: will you need special versions build from you branch or will trunk do?
21:38 dalek parrot: r37960 | bacek++ | branches/packfile_revamp/src/packfile/pf_items.c:
21:38 PerlJam Coke: quality is kind of important  though.  Cheaper clubs are usually made from cheaper, hard plastic and they tend to hurt your hands after a while.
21:38 dalek parrot: Fill padding for stored cstring with zeros.
21:38 PerlJam (that applies to dube as well as others)
21:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37960/
21:38 dalek parrot: r37961 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
21:38 dalek parrot: Add test for Packfile_pack
21:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37961/
21:38 dalek parrot: r37962 | bacek++ | branches/packfile_revamp/t​/pmc/packfiledirectory.t:
21:38 dalek parrot: Rewrite t/pmc/packfiledirectory.t in PIR
21:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37962/
21:38 dalek parrot: r37963 | bacek++ | branches/packfile_revamp/src​/pmc/packfiledirectory.pmc:
21:38 dalek parrot: Propogate segment name on replacing old segment with new one.
21:38 chromatic Cheaper club is cheaper?
21:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37963/
21:38 dalek parrot: r37964 | bacek++ | branches/packfile_revamp/t​/pmc/packfiledirectory.t:
21:39 dalek parrot: Remove disabled check for replacing old segment with new one.
21:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37964/
21:39 PerlJam chromatic: redundancy is your friend :)
21:40 PerlJam Coke, Infinoid: so ... if I make it to YAPC this year, should I bring my clubs so we can juggle?  :)
21:40 Coke PerlJam: if I was serious about it, I'd spend $$.
21:40 PerlJam (I haven't seriously juggled in a long while though)
21:40 Coke PerlJam: if I go. note that I am currently merely a balljuggler.
21:41 Coke PerlJam: http://www.amazon.com/Juggling-Club-Set-Pas​se/dp/B001UJG5EA/ref=sr_1_8?ie=UTF8&amp;s=t​oys-and-games&amp;qid=1239140256&amp;sr=1-8 ??
21:41 shorten Coke's url is at http://xrl.us/ben7uk
21:41 Infinoid Coke: If I make it to YAPC, I'd love to.  (Note: I've yet to ever make it to a YAPC, and so far this year doesn't look much different, unfortunately.)
21:42 Coke Infinoid: I hear you. I am actually considering not going merely due to lack of being paid.
21:42 dalek parrot: r37965 | bacek++ | branches/packfile_revamp/src/pmc/packfile.pmc:
21:42 dalek parrot: Made get_string_native/set_string_native shortcuts for pack/unpack
21:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37965/
21:42 Coke hurm. i should ask my consulting company if there's any money for that sort of thing.
21:42 Coke (expecting the answer no)
21:42 Coke hurm. i wonder if toysRus would have a crappy set to experiment with.
21:43 * Coke drowns in commit emails.
21:43 PerlJam Coke: probably depends on where you're at.  I've never seen one in a toysrus
21:43 moritz parrot-dev is such a quiet place when you don't subscribe to ticket mails...
21:44 * Coke feels an obligation to review commits.
21:44 * moritz too - for rakudo
21:44 * Coke disconnects so no one expects him to review. =-)
21:45 * Coke will return thursday, prolly.
21:45 Coke chromatic: I'll probably miss the call tomorrow, though I may be on a bus and bored and call in anyway.
21:56 cghene joined #parrot
21:58 dalek parrot: r37966 | pmichaud++ | trunk/PBC_COMPAT:
21:58 dalek parrot: Forgot to update PBC_COMPAT in r37944.  Coke++ pmichaud--
21:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37966/
22:03 Whiteknight joined #parrot
22:19 dalek parrot: r37967 | allison++ | branches/pcc_rewiring (5 files):
22:19 dalek parrot: [pcc] Broad rework of the core calling conventions for subroutine/method
22:19 dalek parrot: invocation from opcodes and from C.
22:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37967/
22:25 chromatic Now there's a big commit to review.
22:26 jonathan chromatic: Dares you to grep it for varargs. ;-)
22:30 dalek rakudo: f822294 | (Moritz Lenz)++ | docs/ChangeLog:
22:30 dalek rakudo: [docs] more ChangeLog
22:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​8222940fc6f27b0dfa9a2c50473446a4ee1442b
22:30 shorten dalek's url is at http://xrl.us/ben7zo
22:30 cotto chromatic, do you review all commits?
22:35 dalek parrot: r37968 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
22:35 dalek parrot: [pct]: Refactor POST code generation in preparation for bytecode annotations.
22:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37968/
22:36 jonathan pmichaud++ # yay!
22:36 Whiteknight he certainly reviews all of mine (for good reason)
22:48 dalek rakudo: 6eef54b | jnthn++ | src/classes/ (2 files):
22:48 dalek rakudo: Signature on positional and associative postcircumfixes should not use @ and % sigils, since they are what define said sigils in the signature.
22:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​eef54b86b17ca02f4ca52dc369eec76ee6e9c5a
22:48 shorten dalek's url is at http://xrl.us/ben73h
22:48 dalek rakudo: fb553bd | jnthn++ | src/ (3 files):
22:48 dalek rakudo: More progress on typed arrays and hashes. This patch allows them to be declared, gets them responding correctly to .of, allows checking for (potentially typed) positionals/associatives/callables in the signature and allows the sigils and the Positional/Associative/Callable parametric types to participate in multi dispatch.
22:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​b553bd5ba649eb526a16a99f8caecb799c405ef
22:48 shorten dalek's url is at http://xrl.us/ben73j
22:48 dalek rakudo: 4abd893 | jnthn++ | :
22:48 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
22:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​abd893bdbb4fe205ec3e9191154243782b695e8
22:48 shorten dalek's url is at http://xrl.us/ben73o
22:50 bsdz joined #parrot
23:02 chromatic cotto, I do my best.  I skim the Perl ones.
23:03 Doubi joined #parrot
23:09 * Infinoid starts adding custom free/destroy attrs to ManagedStruct
23:10 Tene joined #parrot
23:11 cognominal joined #parrot
23:21 Infinoid uh, s/free/clone/
23:24 tetragon joined #parrot
23:29 s1n joined #parrot
23:42 Infinoid pmc2c doesn't seem to like: ATTR void (*custom_free_func)(void *ptr, void *priv);
23:43 * Infinoid uses void * and external typedefs
23:46 cotto Infinoid, that part of the pmc2c code is fairly naive.
23:47 Infinoid Fair enough.  It's working well enough for me to keep hacking, for now
23:47 cotto lib/Parrot/Pmc2c/Parser.pm around line 133 if you're curious
23:48 Infinoid I'll add a TT so I can come back to it later
23:49 chromatic Or if it really bothers you, we can use a PGE-based PMC preprocessor.
23:50 Infinoid Let me fix ManagedStruct first.  And jit.  And packfile*.pmc.  And parrotcode.org.  And world hunger.
23:51 Infinoid Oh goodie, more codetest failures for me to fix
23:52 cotto I opened a tt on the copyright.t failures.  It's a Perl 5.8 vs 5.10 issue from what I can tell.
23:58 dalek parrot: r37969 | Infinoid++ | trunk (2 files):
23:58 dalek parrot: [cage] Fix trailing whitespace.
23:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37969/

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced