Parrot 1.0 Released | parrot.org | 380 RTs left!
Set by moderator on 28 March 2009.
Infinoid I particularly love how this jit bug trashes the stack before it crashes 00:02
00:04 cotto joined 00:05 Tene joined 00:09 AndyA joined
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:16
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
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
Infinoid hi bacek_
bacek_ hi Infinoid
cotto I wouldn't know what to do with it.
Infinoid I need to understand where and how jit generated this code, in order to fix this 00:20
first off, where can I find the jit engine sources? :)
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)
rg++ 00:22
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
bacek_ I've got stupid question - who can check fax machine at Parrot Foundation? :) 00:28
Infinoid particle2: Have you gotten bacek's CLA yet? 00:29
bacek_ Infinoid: any objections about approach in github.com/bacek/parrot/tree/packfile_revamp ? (I'm going to move more tests from perl to pir today. And start adding "write" ability to packfile*.pmc) 00:31
bacek_ heading off to another meeting... 00:32
00:36 darbelo left
Infinoid bacek_: +1, good stuff 00:37
it appears before I can learn the horrors of JIT, I need to learn the horrors of MMD first 00:50
cotto Infinoid, why? 00:53
dalek rrot: r37933 | cotto++ | trunk/tools/dev/parrot-fuzzer:
[fuzzer] minor refactor, add --ignore_blacklist option
 00:54
Infinoid cotto: I want to know how this nci function is generated by the jit engine 00:55
but unfortunately, that leads directly into the middle of pcc/mmd 00:56
dalek rrot: r37934 | cotto++ | trunk/src/pmc (2 files):
[PMC] finish the switch to ATTRs in *ManagedStruct
 01:01
cotto smolder? 01:11
purl well, smolder is 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 smolder.plusthree.com/app/public_pr..._reports/8
cotto lovely? 01:14
purl i heard lovely was programmer-speak for "JUST FUCKING WONDERFUL AND BY THAT I MEAN POOP"
cotto no, lovely is engrishfunny.com/2008/10/15/engrish...-yourself/
purl okay, cotto.
Util heh 01:15
Infinoid cotto: Oh, nevermind. Process of elimination worked, the bad jit code call was generated at src/jit/i386/jit_defs.c:2320 01:19
Is there a function it can call to fetch the value of nci_info->orig_func? 01:23
Preferably without having to call Parrot_PCCINVOKE (I assume the whole point of using jitted nci is to speed things up) 01:25
cotto It'd be very easy to add a get_pointer VTABLE function that did that. 01:27
get_pointer deals with orig_func, so it'd go with the principle of least surprise.
01:28 acajou left
cotto Are you thinking in terms of debugging or coding? 01:28
Infinoid hmm, I think we can make VTABLE_get_pointer
mikehh kid51: I notice that in your config you have -lnsl and -lutil which I don't have
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
I'm done debugging, now trying to code a replacement
cotto Infinoid, you can look at r37897 where tewk calls a VTABLE function from the jit code. 01:30
Infinoid awesome, thanks
cotto also, engrishfunny.com/2008/11/06/engrish...r-octopus/ 01:31
shorten cotto's url is at xrl.us/owkqm
Infinoid ah, that vtable code doesn't look too bad 01:32
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 ;-)
I didn't consciously do anything to add them.
mikehh I was just wondering what they were - I couldn't seem to track them down 01:36
kid51 vi +88 ./tools/build/dynpmc.pl 01:40
But that's not source; it must be built by something. Hold on. 01:41
01:45 mikehh joined
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:48
perl Configure.pl --configure_trace && perl -MData::Dumper -MStorable -e '$hashref=retrieve(q|.configure_trace.sto|);print Dumper $hashref' | grep -n lutil 01:51
... and same for lnsl
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
kid51 Well, my build, though by hand, was whatever the simplest possible build is. No special arguments to Perl's Configure. 01:53
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 ;-)
mikehh I think I might build to localperl - who knows how to build from the git repo? 01:55
kid51 does not. I got a tarball the day it came out -- which was before the move to the git repo, IIRC. 01:57
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:00
I just spent a day building gcc 4.3.3 and I am not sutr I want to do Perl at the moment :-{ 02:04
dalek rrot: r37935 | jkeenan++ | trunk/t/tools/ops2pm/05-renum_op_map_file.t:
Correct 'Stage' numbers in messages of 4 tests.
 02:10
rrot: r37936 | jkeenan++ | trunk/t/tools/ops2pm/05-renum_op_map_file.t:
Eliminate superfluous get_last_opcode() calls in Stages 3 and 6.
 02:13
kid51 Well, as noted above, building your own gcc is only for the very brave or very foolish. 02:14
But I've built perl -- albeit always in the simplest possible configuration -- quite a few times.
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:21
mainly because it has CPAN modules in /usr/local/lib/perl 02:23
kid51 Eeeek. That *is* a messy install.
02:23 eternaleye joined
mikehh also /usr/local/share/perl and /usr/local/share/perl5 and /usr/lib/perl5 and ... and 02:25
Infinoid cotto, you still around?
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:27
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 nopaste.snit.ch/16163 02:28
mikehh The number of times that I have updated with cpanp and had to remove some of the old files manually ... :-} 02:29
dalek rrot: r37937 | pmichaud++ | trunk (2 files):
[codestring]: Add 'lineof' method for finding line numbers.
Infinoid msg cotto I have to run. 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.
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.
Infinoid gone & 02:34
02:35 janus joined
dalek rrot: r37938 | pmichaud++ | trunk/compilers/pge/PGE/Match.pir:
[pge]: Use a CodeString PMC to hold match targets instead of String.
 02:36
kid51 must sleep 02:37
purl $kid51->sleep(8 * 3600);
02:56 eternaleye_ joined 03:02 karatorian joined
cotto Infinoid, back 03:11
messages erase
03:57 karatorian left
Coke_afk messages shake etch a sketch 03:58
04:29 tetragon joined 04:44 masak joined
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:48
cotto eternaleye_, that's a good question for #parrotsketch 04:52
eternaleye_ Cool, I'll join 05:00
cotto Good for you! 05:02
eternaleye_, #parrotsketch is where we hold our weekly meetings 05:29
eternaleye_ Ohhh 05:30
Tene eternaleye_: the weekly meeting is tomorrow
eternaleye_ Gotcha.
Tene purl: parrotsketch?
purl well, parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
cotto Sorry. I assumed too much there.
eternaleye_ 'sokay.
cotto If you're around, you're free to join and ask your question, though.
I'd ask it, but I'll have to miss it tomorrow. 05:31
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:36
dalek rrot: r37939 | cotto++ | trunk/t/codingstd/copyright.t:
[t] unTODO a passing codingstd test
 05:37
cotto You only occasionally have to pay attention, especially if you're a fast reader. 05:39
The usual format for #ps is that regular contributors report, then it's open for questions. 05:40
eternaleye_ Sounds good. I'll probably set a hilight fot the regex 'question(s?)', and just check it every few minutes 05:46
Let me know when it's time 05:47
s/^L/That should l/ 05:48
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 06:06 eiro joined
cotto msg tewk When you have a minute, the patch for 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 (trac.parrot.org/parrot/raw-attachm...t365.patch ) and either give it your +1 or say what needs to be fixed. Thanks. 06:15
purl Message for tewk stored.
shorten cotto's url is at xrl.us/ben5b7
cotto Infinoid++ #(le)jit hackery 06:16
sleepytime 06:19
moritz eternaleye_: PCT based compiler have a target=parse option that reveals the syntax tree
06:29 Tene_ joined
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 07:07 bsdz joined 08:03 particle joined 08:20 donaldh joined
nopaste "mikehh" at 92.30.6.100 pasted "Weird happenings with the jit core" (106 lines) at nopaste.snit.ch/16172 08:29
mikehh Anyone want to have a look at this - I think my computer has lost the plot 08:30
09:07 cognominal joined 09:22 elmex joined 09:25 PacoLinux joined
dalek rrot: r37940 | fperrad++ | trunk/compilers/nqp/src/builtins.pir:
[nqp] refactor 'say' with tailcall
 09:54
09:59 schinkelm joined 11:12 eiro joined 11:39 kid51 joined 11:40 flh joined
Coke_zzz bacek: ping 12:12
(asking things in parrotsketch) there's also the mailing list, which has the advantage of being open 24/7. 12:28
12:36 rg1 joined 12:53 iblechbot joined, PacoLinux joined 12:56 register joined
Infinoid finds some jit docs and reads them 13:03
13:08 ruoso joined 13:12 register joined
register Hi! 13:13
how to configure the big int library?
moritz I think you install libgmp3-dev and run Configure.pl again 13:15
register ah ok 13:17
thx 13:18
moritz (libgmp3-dev is the name on Debian, on other systems it might vary=
s/=/)/
you're welcome
oh, and recompile of course ;-)
register well... yes... 13:19
I am using an ubuntu
should be the same name 13:20
moritz right 13:21
Ubuntu++ # bringing apt/dpkg to a wider user base
register well it's a fabolous distribution 13:22
I have a double boot laptop with ubuntu and windows 2008 server 13:23
on the w2008 server I have a virtualbox with xubuntu
13:23 gryphon joined
register when I can foresee that I need to do some mix development 13:23
xubuntu really rocks
it's extremely fast and solid
I really cannot see the difference between the vm xubuntu and the pure ubuntu... 13:24
and another revolution has been the release of qt creator
this ide is on par with visual studio
but it is completely open
I foresee big things for it
it will become the de-facto standard for C++ development on all the supported platforms 13:25
moritz is still on vim for C++ development 13:26
register well
i still use vim on linux too
but i code c++ for a living 13:27
and i can really appreciate the difference between a textual development environment
and a real IDE
just setting breakpoints on gdb typing a sourcecodefilename:linenumber
is a complete waste of time 13:28
moritz aye, agreed
register and being forced to remember every signature of every function is a complete waste of brain .memory also
intellisense helps
just by having an ide that is able to remember breakpoints
you save at least 50% of the development time 13:29
Even if I admire the open source movement for the quality of the code and the braveness of some ideas
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
<c-]> and <c-t> are your friends 13:31
(i do it everytime with every langagesà
moritz ctags?
purl ctags is cool :) or at ctags.sf.net/
eiro moritz, yep 13:32
register ctags with vim?
eiro register, yes of course
register with automatic tags compilation every time the source is modified?
eiro and it complete the names of functions with <c-x><c-]> (i remapped with <c-j> ... borland souvenirs)
register, no ... i have a macro to do it manually 13:33
register eheh
gotcha
eiro ,rt ( refresh tags)
register ;)
eiro i don't carre: i don't have signatures
btw it can be easy to add a event handler ... for every pressed keys if you want 13:34
so it's not an argument ;)
breakpoints is one !
:(
moritz it would be nice to have a really good IDE with vim as the editor 13:35
register well
moritz I've seen a vim plugin for msvc, but I couldn't get it to run (but that's years ago)
register with qt creator I guess it could be done
the ide is extendible
is very modular
as soon as I get some spare time I will play with it
but I suggest you to have a look at it 13:36
it's intellisense in magnificient
its intellisense
is
eiro it could be great! i can't imagine the developpement without vim
register by the way 13:39
what is missing from the bigint pmc?
14:01 bsdz joined
dalek kudo: 2c7f5b3 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 349 files, 8436 passing, 0 failing
 14:22
shorten dalek's url is at xrl.us/ben5z4
dalek rrot: r37941 | coke++ | trunk (3 files):
[cage] make sure src/exec.c is headerized

it passes the function doc test.		 14:24
14:27 Theory joined
Coke that seems to me the wrong way to fix headerizer. are we not linking against exec.o ? 14:30
14:36 particle1 joined
Coke ah. we are, just not on my platform. blah. 14:38
dalek rrot: r37942 | coke++ | trunk/config/gen/makefiles/root.in:
[cage] revert explicit add of exec.o

is skipped on osx/x86, but not on linux/x86.		 14:41
14:42 davidfetter joined
dalek rrot: r37943 | coke++ | trunk/tools/build/headerizer.pl:
[cage] when warning about missing function docs, give the filename.
 14:44
Coke ponders an eclipse plugin. 14:49
Infinoid If you wrote one, I would use it 14:50
Coke If I wrote one, I'm not sure /i/ would use it. =-) 15:00
might be interesting to learn how, so I could also hack on cfeclipse, though.
flh when I write, in PIR, new 'something', this calls the "something" pmc init vtable function? 15:02
particle1 $P0 = new ['Something'] is the correct syntax now btw 15:03
and yes, it calls Something's init vtable function
particle- $P0 = new ['Something'], $P1 calls Something's init_pmc vtable function 15:04
flh and it should work also with a dynpmc?
particle- yes 15:05
flh ok, so I missed something somewhere else, since my init_pmc should throw an exception, but it doesn't
particle- are you using gcc, and if so, do you know your way around gdb? 15:06
you can set a breakpoint at init_pmc
dalek kudo: ea94175 | (Moritz Lenz)++ | t/harness:
re-enable parallel testing in t/harness again

Requires a sufficiently recent Test::Harness. For example the harness works fine with 3.12, but for parallelism you need something newer, 3.16 seems to work.		 15:11
shorten dalek's url is at xrl.us/ben567
dalek kudo: 27f0c01 | (Moritz Lenz)++ | README:
document requirements for parallel testing
shorten dalek's url is at xrl.us/ben569
flh well, actually, my init_pmc is not even in the C file generated from the .pmc 15:14
let's see how Rakudo is doing :) 15:16
Coke particle-: new ['Something'] - that's /recommended/ but not /required/, neh? 15:20
(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
pmichaud aiui, ['Something'] is not required.
'Something' is still valid.
particle- ok, y'all know better than me at this point, i'm sure.
Coke particle-: the test suite has NOT been fully converted. 15:22
(nor has most of the codebase. =-)
flh hum, found it... "badly balanced pmc": I should definitely close curly brackets :)
Coke pmichaud: is new <STRING> eventually going to be illegal?
particle- i lose.
flh: that'll do it, every time :)
pmichaud Coke: I haven't had that impression. 15:23
Coke pmichaud: k
pmichaud Coke: I think that chromatic and I were arguing for making it illegal, but allison wanted to keep it.
dalek kudo: 4453712 | pmichaud++ | build/Makefile.in:
Refactor checks for Makefile updates so that 'make realclean' continues to work.
 15:25
shorten dalek's url is at xrl.us/ben58n
15:28 Tene joined
flh particle, the funny thing being that with my original source, pmc2c did not complain about the missing bracket 15:29
particle- flh: that's a bug, and if you can get a minimal test case, it would be wonderful to report 15:31
Coke there is a LONG open bug about that. 15:33
moment.
check this: rt.perl.org/rt3/Ticket/Display.html?id=39313 15:34
there are some things that are just dropped on the floor when using pmc2c.pl 15:35
I presume this is a case of that.
pmc2c.pl should pass through anything it doesn't understand to the .c (where it would presumably fail miserably)
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.
particle- was that ever funny?
15:37 rdice joined
Coke what, GI/BI? clearly you're not an animaniacs fan. 15:37
particle- i am, but that one isn't funny.
potty emergency? 15:38
Coke no, I'm good.
;)
rg lol. don't do that when i'm drinking :P 15:39
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
bsdz pmichaud. 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?
bsdz 88 and below. 15:42
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
pmichaud you need $<return_identifier>[0]<identifier>
instead of $<return_identifier><identifier>
oops, "return_identifier_list"
particle- classic failure 15:44
PerlJam Seems like there should be some DWIM there though.
bsdz hmm. i think i tried that and many other combinations.
PerlJam (I get bitten by that one occasionally too :)
pmichaud well, $<return_identifier_list> will be an array.
bsdz i'm not at my normal dev env right now but will try and give it a spin.
pmichaud PerlJam: at one point we had ? quantifiers as not returning arrays.... but that got changed.
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:45
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:46
(depending on which path gets taken in the return_identifier_list rule) 15:47
dalek tracwiki: v4 | coke++ | Deprecation
tracwiki: trac.parrot.org/parrot/wiki/Deprec...ction=diff
shorten dalek's url is at xrl.us/ben6at
bsdz ah okay
pmichaud you can force it to always be an array by using <identifier>**{1}
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
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?
bsdz ah right
dalek tracwiki: v5 | coke++ | Deprecation
tracwiki: trac.parrot.org/parrot/wiki/Deprec...ction=diff
shorten dalek's url is at xrl.us/ben6bf
pmichaud PerlJam: not beyond what we might've discussed last time.
PerlJam okay 15:51
pmichaud but look at the goal-matching parser for ideas about how to do the parsing
that part should be easier now.
speaking of which, I need to fix that.
PerlJam "the goal-matching parser"?
pmichaud That, and synopsis 5.
Tene ~ 15:52
pmichaud oh.
goal matching: '(' ~ ')' <expression>
PerlJam oh, yes. I don't really have a term for that in my head :)
bsdz ah okay. i'll take a look at synopsis 5
pmichaud I call that the goal-matching syntax.
bsdz: my synopsis 5 comment was for PerlJam (but you could look there, yes)
bsdz in: 15:53
token return_identifier_list { | <identifier> {*} #= single | '[' <identifier> [',' <identifier> ]* ']' {*} #= multiple
}
argh
bsdz yep - i admit it's not elegant ;-)
pmichaud if the parser takes the 'single' path, then $<return_identifier_list>[0]<identifier> will be a Match object
if the parser takes the 'multiple' path, then $<return_identifier_list>[0]<identifier> will be an Array of Match objects
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.
so to force it to be an array in both cases
use
| <identifier>**{1} {*} #= single
then in the action, @($<return_identifier_list>[0]<identifier>) will always be an array of Match objects 15:55
(that you can loop over)
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
pmichaud oh... 15:57
right
in that case, you also don't need the @(...)
dalek rrot: r37944 | pmichaud++ | trunk/src/ops (2 files):
[lex]: Add find_caller_lex opcode for getting lexicals from callers' scopes.
pmichaud it's just for $<return_identifier_list>[0]<identifier> { ... }
(because it's already an array)
bsdz doh - sorry 15:58
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
thank a lot btw :)
pmichaud that's just a quantifier 16:00
same as **{1..4} # match 1 to 4 times
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
thanks again
16:18 schinkelm joined 16:30 AndyA joined 16:31 Khisanth joined 16:45 braceta joined 16:53 AndyA joined 16:54 jrockway joined
pmichaud #parrotsketch in ~90 17:01
17:12 darbelo joined
PacoLinux make spectest now 19m12.009s :) 17:16
17:16 acajou joined 17:19 allison joined 17:22 particle1 joined
Coke pmichaud: did you run 'make opsrenumber' ? 17:22
(don't do that.)
Coke moves to email on that one. 17:26
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.
ISTR that kid51 is working on it.
PerlJam cool.
Coke not that particular item, but "why does opsrenumber suck in a post 1.0 world." 17:30
17:32 eternaleye joined
PerlJam well, still cool 17:33
Tene purl: parrotsketch? 17:43
purl parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
Tene ah, next hour
cotto Coke, (wrt tt #543), the duplicate copyright test passes for me. 17:44
Do you have any idea why it'd pass for me but not you? 17:45
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
dalek rrot: r37945 | chromatic++ | trunk/docs/project/branching_guide.pod:
[docs] Updated references to svn.parrot.org from svn.perl.org.
 17:56
17:56 chromatic joined
pmichaud I did do opsrenumber, yes. 17:57
If that's an oops, I need to know what the correct procedure is now.
dalek rrot: r37946 | chromatic++ | branches/headercleanup:
Created branch to clean up headers and move code into subsystem directories
 17:59
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)
Coke my concern being that doing a renumber now makes any future PBC migration hard.
18:05 gryphon joined
NotFound hi 18:05
Coke (even though we're not doing that right now)
dalek rrot: r37947 | moritz++ | trunk/docs/book/ch02_getting_started.pod:
[docs/book] delete reference to snapshots that are 404s now
 18:06
Coke NotFound: namaste
pmichaud right, I was under the impression that we're not yet too concerned with ops numbering
Coke pmichaud++
no, but there's no sense chumming the water.
pmichaud So, should I revert+fix ops.num, or leave it for now? Either way is likely to require realcleans. 18:07
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?
chromatic I believe the biannual releases will go on the CPAN.
particle- that's my recollection
moritz chromatic: thanks
Coke cotto: 5.10 18:10
"what chromatic said."
1.0 is already on the cpan.
cotto I'm on 5.8.8. The copyright test passing on my system might be due to that.
Coke cotto: that's freaky. 18:11
18:11 barney joined
cotto Coke, it's just a guess. 18:11
18:12 gryphon_ joined
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
pmichaud yay. I don't have to undo, then?
allison pmichaud: aye
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.
chromatic I thought (but am not arguing for) we were going to renumber ops only once, right before the 1.4 release.
Infinoid, I haven't browsed them yet. I will.
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
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.
chromatic I'm not a huge fan of adding yet another special purpose PMC, but... it does look cleaner.
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
allison Coke: yes, we do ops renumbering on a deprecation cycle
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
Coke allison: what is the point of renumbering the ops, though? 18:16
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
Coke I'm arguing specifically about future attempts to translate bytecode.
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.
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
Coke s/a ton of/pretty much every/
Ok. -1 from me.
allison Coke: right, but we're not going to retroactively do bytecode translations for all previous versions of bytecode
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
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.
allison Coke: and the guess is just as likely to be wrong as right
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.
but it doesn't matter.
allison Coke: so we might as well stick with the policy that works for the current implementation
chromatic Infinoid, if Parrot didn't allocate the memory (from a GC pool), Parrot won't be able to destroy it. 18:21
Coke allison: respectfully disagree, but ok. 18:22
Infinoid So you're arguing for a more general approach.
allison Coke: fair enough :)
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.
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....
Infinoid Well, my current patch fails because munmap() doesn't get the right size parameter. I'm certainly open to ideas.
(This kind of thing makes me wish C had closures.)
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:25
dalek rrot: r37948 | NotFound++ | trunk/compilers/imcc/parser_util.c:
[imcc] fix a C warning/C++ error
 18:26
Infinoid I suppose so. I'd worry about alignment, but hey, if someone needs strict alignment they can do it themselves.
chromatic Presumably anything returned from mmap() will be aligned properly to start. 18:28
#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
That said, it's going to make the two-staged (write+noexec -> readonly+exec) allocation model Santtu wants ... interesting 18:31
chromatic How so?
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 #?
Coke trac.parrot.org/parrot/ticket/489 18:33
(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.)
I suggested to him that perhaps he revert the test change to the way it was.
allison Coke: appears to be related to trac.parrot.org/parrot/ticket/469 (poor Jim, serving two masters) 18:35
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:36
Coke That's what he gets for listening to me. 18:37
Infinoid But this can wait until after #ps
Coke is that now?
chromatic Sounds almost like defining a struct for JIT and storing that pointer in the PMC.
Coke irc logs?
purl irc logs are nothing like http logs... very low overhead and storage
Coke irclogs?
purl somebody said irclogs was irclog.perlgeek.de/parrot/today or see also: infrared clogs
moritz also s/parrot/parrotsketch/ 18:38
dalek rrot: r37949 | chromatic++ | branches/headercleanup (13 files):
Moved src/interpreter.c and src/interp_guts.h into src/interp/.
 18:39
chromatic Hm, we could get down to 550 open tickets by the next release. 18:45
Coke 258+378
purl 636
Coke no we can't. =-)
I could see 600. 18:46
chromatic A lot of those 378 can just go away with a bit of review.
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)
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.
Infinoid pmichaud: Apologies, I haven't yet found tuits for figuring out why your icu patches cause segfaults here.
18:52 Santtu joined
Infinoid Santtu: [11:37] <@chromatic> Sounds almost like defining a struct for JIT and storing that pointer in the PMC. 18:57
(the ManagedStruct PMC, he means)
Coke chromatic: when merging that back to trunk, watch out for changes to renamed files. 18:58
chromatic Coke, I'm fairly confident that these files are stable enough that that won't hurt too much. 18:59
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.
Coke chromatic: did you not run mk_manifest on purpose to make the merge simpler? =-)
Infinoid Right, so you'll need a custom clone as well as custom destroy to get this working with ManagedStruct
Coke chromatic: also, you shouldn't be renaming things in ports/cygwin, I wager. 19:01
since those refer to the 1.0.0 that ws.
"was"
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.
chromatic Ugh.
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
Coke you could always just renaming /everything/ in the branch and not merge those files back. 19:01
19:02 rob joined
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.
Santtu Global GC? 19:04
19:04 Theory joined
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.
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
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.)
Infinoid selinux prevents RWX pages, right? 19:08
Santtu Yeah. Silently. You just run into segv.
Infinoid Beautiful.
purl it has been said that beautiful is a love thing
tewk thats really inefficient
Santtu RWX gets downgrated into RX, then you try to write and ...
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.
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
That sounds painful
Santtu JIT typically is :-) 19:11
chromatic Hooray for not maintaining our own JIT!
Infinoid Is LLVM on our roadmap?
(or something similar, I dunno what's out there)
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 :)
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:13
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
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:15
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.
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..
Infinoid or ManagedPointer
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?
dalek tracwiki: v145 | allison++ | ParrotRoadmap 19:19
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/ben67p
chromatic Rather than adding two PMCs, let's stick with one until we need to generalize more.
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)
chromatic I'd rather see CPointer expanded, if we can make it work. 19:21
Hm, src/interp/interpreter.c (nee src/interpreter.c) has very little about interpreters in it. It mostly works on runcores and dynops.
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.
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
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:26
allison chromatic: src/interp/interpreter.c sounds like a candidate for a file-rename 19:27
Whiteknight allison: agreed
chromatic Oh, it's already on my list. 19:28
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.
allison chromatic: src/ops? 19:29
src/ops is just for *.ops files and ops.num, not for general C functions
+1 on src/runcores 19:30
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?
allison (it already exists)
chromatic Already existing is a plus.
Most of these functions are about registering and initializing ops.
allison then maybe src/runcores/core.c 19:32
or src/call/core.c
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
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
cotto I'm going to rewrite and update it as soon as I get rid of the PMC_x_val macros.
If it'd be helpful to you, I could do it sooner.
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
They're not really about calling things.
particle- (src/runcores/core.c)++
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
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
Infinoid It sounds like we want custom free/dup handlers, an extension of the 02 patch. 19:37
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
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?
tewk cotto: yes 19:38
cotto tewk, will you have the tuits to look at TT #365 within the next week or so?
Santtu Ummm... why? There's already PMC subclassing, why use function pointers when just subclassing the PMC you could do all without them?
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.
Infinoid Santtu: 19:40
[11:14] <@chromatic> I'm not a huge fan of adding yet another special purpose PMC, but... it does look cleaner.
[11:15] <@chromatic> Then again, I suspect that UnManagedStruct might need a custom free() pointer anyway sometimes.
So I think the motivation is just to be able to reuse this infrastructure later
cotto tewk, that's fine. I just noticed that Whiteknight++ gave it his +1.
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.
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
Whiteknight Infinoid: Okay, I'll double-check that for you
Infinoid and whether the stuff at args_offset was already set up properly, and all of that 19:43
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.
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..
cotto tewk, all of t/pmc/nci.t passes
Infinoid Amazingly enough, they seem to. 19:45
tewk Thats a good sign.
Santtu (okay apart from apache-style region allocators, but interfacing with them isn't probably be solvable with the size parameter either)
NotFound Santtu: c++ allocators come to mind 19:46
Infinoid Santtu: True. But the jit struct saves us from having to add size handling to ManagedStruct directly 19:47
(and also saves us from having to worry about how many arguments the free function takes)
cotto Whiteknight, lmk when you've checked. I'm ready to commit whenever.
Whiteknight I'm not going to get to it till tonight. I'll send you a msg or somethign when I do
Infinoid In this case, we're just "managing" the jit struct, which seems reasonable enough
cotto Whiteknight, ok. 19:48
Santtu How'd you make region allocator work with ManagedStruct? 19:49
Infinoid You mean in mod_parrot? I have no idea 19:50
jhorwitz perks up 19:51
Coke chromatic: have fun re-headerizing. =-)
chromatic No kidding.
Coke headerizer sucks, btw. seems to be a custom run based on your build. 19:52
dalek tracwiki: v1 | allison++ | NamespaceTasklist
tracwiki: trac.parrot.org/parrot/wiki/Namesp...ction=diff
tracwiki: v10 | allison++ | IOTasklist
shorten dalek's url is at xrl.us/ben7cd
dalek tracwiki: trac.parrot.org/parrot/wiki/IOTask...ction=diff
Santtu infinoid: With ManagedStruct specifically, since region allocator free routine takes two pointers (region + memory within the region).
shorten dalek's url is at xrl.us/ben7cf
Coke (so if you build with jit, you headerize more).
Still beats the alternative.
chromatic Rather than saying it sucks, let's call it not yet complete.
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?
jhorwitz has done many things he's not proud of 19:54
Infinoid jhorwitz: Don't worry, we love you anyway.
jhorwitz that's why i keep coming back
particle- jhorwitz: ...do you work out?
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*).
dalek tracwiki: v63 | allison++ | WikiStart
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/ben7cy
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?
Infinoid Santtu: Yeah. My current thinking is void (*)(void*), but we pull the additional stuff from within the void* 19:57
jhorwitz: Do you have to worry about freeing the data, or does apache do that internally?
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. :)
jhorwitz i didn't read back far enough to understand the issue, but i'm glad i don't have to now. :)
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:00
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? :)
Santtu JIT code stays around forever.. (almost) 20:03
PerlJam pmichaud: ping
Santtu .. and doesn't move around .. if it is smack in the middle of some page then the allocator cannot coalesce it ..
(or 2^N region)
jhorwitz Santtu: verifying something.....
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 (?)
Infinoid We don't have a compacting GC yet
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...
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.
Santtu jhorwitz: But is that user's problem? E.g. "don't do that"? 20:07
pmichaud PerlJam: pong
PerlJam: you can try _dumper(match) 20:08
PerlJam do I have to load_bytebode 'dumper.pir' or something? 20:10
ah, so I do. nevermind
(I had PGE/Dumper.pir, but not dumper.pir)
Infinoid Santtu: I'm not sure what you're trying to say, but I don't think the additional struct is an issue
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.
pmichaud very useful for debugging changes to Perl6Regex
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?
jhorwitz: agree on that
chromatic That seems the least invasive right now.
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
s/mod/mob/
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.
pmichaud PerlJam: .'new' returns a new Match object 20:14
its .from is set to the current position of whatever was passed to it, and it's set as a failed match
PerlJam pmichaud: how do I clone one?
pmichaud I don't know that you clone one. You shouldn't need to clone one. (more)
oh, the new Match object has its target already set to the same target as the mob you passed in.
it's basically a clone with updated .from and .to 20:15
PerlJam target, from and to ? or just target and from?
pmichaud (.to being set to a value that causes the Match to act like a failed match)
(I think .to is set to -1 )
a failed Match is one where .to < .from
PerlJam okay, thanks 20:16
moritz so you don't support reversed Match objects? ;-)
pmichaud I do not.
*something* has to be straight>forward< somewhere! 20:17
:-P
moritz lol
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.
which, iirc, Damian did choose to do at last year's OSCON keynote :-P 20:19
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)
pmichaud my humor is often underappreciated.
particle- very funny. 20:21
purl Thanks, I'm here all week.
rg moritz: you can put it there: trac.parrot.org/parrot/wiki/ParrotQuotes 20:23
moritz rg: thanks 20:24
dalek tracwiki: v8 | moritz++ | ParrotQuotes 20:28
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/ben7hc
20:34 sjn joined
bacek good morning 20:36
Coke: pong
20:36 Tene joined
bacek hates DST... 20:36
Coke bacek: yes, I've seen your CLA. 20:37
bacek Coke: that's good :)
Coke Infinoid: were you mentoring?
I can't see how to add commit bits. =-) 20:38
Infinoid Coke: Yes, I can mentor 20:39
cotto Coke, I'd also be interested in helping mentor the person who's doing libdecnumber integration. 20:40
chromatic Is there a Configure.pl option only to regenerate makefiles? 20:43
Coke I'm referring to mentoring a new committer, not mentoring a GSOC candidate. 20:46
if you're interested in that, sign up with dukeleto.
chromatic: you could try to run just that step.
I would just rerun the whole damn thing.
bacek: do you have a trac id? 20:47
bacek Coke: yes, "bacek" 20:48
20:48 acajou left
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.
Coke chromatic: like to? absolutely not. Want to fix configure? not that either. 20:50
we could probably rip out 70% of configure and put it into makefiles.
moritz usually 'make' works pretty well for me
Coke bacek, Infinoid: bacek is now a committer, which ISTR was approved last #ps.
Infinoid: usual caveats about your minion breaking anything. 20:51
Infinoid bacek: please don't break anything, kthx :)
bacek Infinoid: I'll try :) 20:52
Coke: where I can find password for svn?
rg bacek: same as trac 20:53
Coke bacek... did you try your trac id? =-)
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
or add your name to release managers for some month this year ;)
bacek particle-: Can it be post-2.0 release? :) 20:56
Infinoid: I want to create "packfile_revamp" branch in svn. Any objections? 20:57
Infinoid No objections 20:58
bacek Infinoid: ok. 20:59
bacek reading "git svn --help" to understand how to do it
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
But that's because I've never really figured out git-svn's branch handling.
chromatic perldoc docs/projects/branching_guide.pod
bacek chromatic: thanks 21:01
Tene Infinoid: just use -s or --stdlayout and svn branches become git branches.
moritz I have also a git clone of parrot including all branches
hm, I would have searched for that in docs/dev/
dalek rrot: r37950 | chromatic++ | branches/headercleanup (6 files):
Moved the other src/interp_*.c files into src/interp/, updating all references
Coke chromatic: bah. I am juggling 10 branches here at work. 21:03
chromatic Yeah, but you're a mathematician. 21:04
PerlJam and a juggler apparently 21:11
Coke is a juggler. Can only do 3-at-a-time, though. 21:13
Infinoid (the rest are emulated using timeslices)
pmichaud I can see why 10 is a problem, then. :-)
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.
dalek rrot: r37951 | bacek++ | branches/packfile_revamp:
Created branch for improving packfile*.pmc
 21:15
Infinoid I'd like to learn that 21:24
Don't all start throwing clubs at me at once tho.
Coke I can teach you how to juggle like my dad taught me how to swim.
Infinoid can juggle 3, but hasn't tried any team stuff
dalek rrot: r37952 | allison++ | branches/pcc_rewiring:
Creating branch for refactoring calling conventions, rewiring the internals of pcc dispatch.
 21:28
21:29 register joined
PerlJam Infinoid: you can juggle 3 clubs? 21:30
register what is missing from bigint?
cotto seen dukeleto
purl dukeleto was last seen on #pdx.pm 7 hours, 10 minutes and 7 seconds ago, saying: register: yes?
cotto seen dukeleto in #parrot
Infinoid Yeah. Haven't practiced in a long time tho
bacek "git svn dcommit" in action 21:31
dalek rrot: r37953 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Remade t/pmc/packfile.t in pure PIR.
bacek afk # morning duties: kids, breakfast, etc. 21:32
Coke I haven't done clubs. are there special clubs or can I use like lawn bowling pins? =-) 21:34
dalek rrot: r37954 | bacek++ | branches/packfile_revamp/t/native_pbc (6 files):
Rebuild few t/native_pbc/*.pbc
 21:35
rrot: r37955 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Simplify slightly packfile loading
rrot: r37956 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Move helper function to the end of file
rrot: r37957 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Factor out _filename function. It will be useful for testing on different platforms
PerlJam Coke: they're special enough. www.dube.com
rrot: r37958 | bacek++ | branches/packfile_revamp/src/packfile.c:
Fill padding with zeros during pack
rrot: r37959 | bacek++ | branches/packfile_revamp/src/packfile.c:
Fill one more padding with zeros
Coke PerlJam: european or american?
rg bacek: if you need some native_pbc files for big endian, just ask ;) 21:36
Coke holy #*(&. 41 bucks a PIN?
cotto It's getting kinda branchy in here.
Coke guesses bacek is using git2svn.
bacek rg: I definitely need them :)
PerlJam Coke: theres are cheaper manufacturers. Generally the pros use dube though :)
Coke PerlJam: ok. for practice, I'll check out something cheaper. =-) 21:37
21:37 Casan joined
Infinoid bacek is importing the last week's worth of patches from github.com/bacek/parrot/tree/packfile_revamp, I imagine 21:37
PerlJam Coke: dube has various pricing too. Not sure how their cheaper clubs compare though
bacek Infinoid: yes I am :)
rg bacek: will you need special versions build from you branch or will trunk do? 21:38
dalek rrot: r37960 | bacek++ | branches/packfile_revamp/src/packfile/pf_items.c:
Fill padding for stored cstring with zeros.
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.
PerlJam (that applies to dube as well as others)
rrot: r37961 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Add test for Packfile_pack
rrot: r37962 | bacek++ | branches/packfile_revamp/t/pmc/packfiledirectory.t:
Rewrite t/pmc/packfiledirectory.t in PIR
rrot: r37963 | bacek++ | branches/packfile_revamp/src/pmc/packfiledirectory.pmc:
Propogate segment name on replacing old segment with new one.
chromatic Cheaper club is cheaper?
rrot: r37964 | bacek++ | branches/packfile_revamp/t/pmc/packfiledirectory.t:
Remove disabled check for replacing old segment with new one.
PerlJam chromatic: redundancy is your friend :)
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 $$.
PerlJam (I haven't seriously juggled in a long while though)
Coke PerlJam: if I go. note that I am currently merely a balljuggler.
PerlJam: www.amazon.com/Juggling-Club-Set-Pa...amp;sr=1-8 ?? 21:41
shorten Coke's url is at xrl.us/ben7uk
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.)
Coke Infinoid: I hear you. I am actually considering not going merely due to lack of being paid. 21:42
dalek rrot: r37965 | bacek++ | branches/packfile_revamp/src/pmc/packfile.pmc:
Made get_string_native/set_string_native shortcuts for pack/unpack
Coke hurm. i should ask my consulting company if there's any money for that sort of thing.
(expecting the answer no)
hurm. i wonder if toysRus would have a crappy set to experiment with.
Coke drowns in commit emails. 21:43
PerlJam Coke: probably depends on where you're at. I've never seen one in a toysrus
moritz parrot-dev is such a quiet place when you don't subscribe to ticket mails...
Coke feels an obligation to review commits. 21:44
moritz too - for rakudo
Coke disconnects so no one expects him to review. =-)
Coke will return thursday, prolly. 21:45
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
dalek rrot: r37966 | pmichaud++ | trunk/PBC_COMPAT:
Forgot to update PBC_COMPAT in r37944. Coke++ pmichaud--
 21:58
22:03 Whiteknight joined
dalek rrot: r37967 | allison++ | branches/pcc_rewiring (5 files):
[pcc] Broad rework of the core calling conventions for subroutine/method
 22:19
chromatic Now there's a big commit to review. 22:25
jonathan chromatic: Dares you to grep it for varargs. ;-) 22:26
dalek kudo: f822294 | (Moritz Lenz)++ | docs/ChangeLog:
[docs] more ChangeLog
 22:30
shorten dalek's url is at xrl.us/ben7zo
cotto chromatic, do you review all commits?
dalek rrot: r37968 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
[pct]: Refactor POST code generation in preparation for bytecode annotations.
 22:35
jonathan pmichaud++ # yay! 22:36
Whiteknight he certainly reviews all of mine (for good reason)
dalek kudo: 6eef54b | jnthn++ | src/classes/ (2 files):
Signature on positional and associative postcircumfixes should not use @ and % sigils, since they are what define said sigils in the signature.
 22:48
shorten dalek's url is at xrl.us/ben73h
dalek kudo: fb553bd | jnthn++ | src/ (3 files):
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.
shorten dalek's url is at xrl.us/ben73j
dalek kudo: 4abd893 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/ben73o
22:50 bsdz joined
chromatic cotto, I do my best. I skim the Perl ones. 23:02
23:03 Doubi joined
Infinoid starts adding custom free/destroy attrs to ManagedStruct 23:09
23:10 Tene joined 23:11 cognominal joined
Infinoid uh, s/free/clone/ 23:21
23:24 tetragon joined 23:29 s1n joined
Infinoid pmc2c doesn't seem to like: ATTR void (*custom_free_func)(void *ptr, void *priv); 23:42
Infinoid uses void * and external typedefs 23:43
cotto Infinoid, that part of the pmc2c code is fairly naive. 23:46
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
Infinoid I'll add a TT so I can come back to it later 23:48
chromatic Or if it really bothers you, we can use a PGE-based PMC preprocessor. 23:49
Infinoid Let me fix ManagedStruct first. And jit. And packfile*.pmc. And parrotcode.org. And world hunger. 23:50
Oh goodie, more codetest failures for me to fix 23:51
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:52
dalek rrot: r37969 | Infinoid++ | trunk (2 files):
[cage] Fix trailing whitespace.
 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!