Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply merge
Set by moderator on 23 October 2009.
jonathan whiteknight: OK, thanks. I'll investigate tomorrow. 00:00
Coke In fact, I'm pretty sure I've been using install-dev since then with no problems.
(but yah, it's not exactly an alias at this point.) 00:05
pmichaud_ oh, wait, "make install" does "install-bin install-dev"? 00:09
that's a problem.
fixing.
dalek rrot: r42095 | pmichaud++ | trunk/config/gen/makefiles/root.in:
[install]: Restore install-dev target to also do 'make install' actions.
pmichaud_ also, I should note that "make help" says: 00:10
install-dev: Same as 'install' but also install support for development.
(which it will do again in a moment)
jonathan -> sleep, see y'all tomorrow.
dalek rrot: r42096 | pmichaud++ | trunk/config/gen/makefiles/root.in:
[install]: Oops, previous patch resulted in a circular dependency.

  'make install-dev' depends on 'install-bin'.		 00:12
japhb pmichaud_, there should be a target that does *only* the non-bin stuff. 00:15
'install-devel'?
pmichaud_ ...why?
japhb For packagers.
pmichaud_ okay, install-devel then
part of me wants "install-devlibs" instead 00:16
wait
that doesn't make any sense
japhb ... with a comment explaining why 'install-dev' and 'install-devlibs' both exist.
pmichaud_ what were packagers using before now...?
japhb pmichaud_, they were guessing.
ttbot Parrot trunk/ r42095 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/123645.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
pmichaud_ where "guessing" means...?
Austin how about "make for-packagers" 00:17
pmichaud_ Austin: packagers have two targets they want to make
Austin: they want to be able to get a runtime
japhb probably reading the install-dev script, figuring out what it does, and figuring out the list of files it would install
pmichaud_ on ubuntu at least, the standard package name is "*-devel" 00:18
are there any packaging systems that use "*-dev"?
what's the typical RPM name ?
Austin Ad placement fail: failblog.org/2009/10/23/ad-placement-fail-4/
japhb pmichaud_, core debian uses -dev 00:19
whiteknight PL/Parrot?
purl PL/Parrot is probably a really cool project irc://irc.freenode.net/plparrot
japhb Fedora/Redhat use -devel
pmichaud_ so I think it should be -devel then
japhb I'm fine with that
pmichaud_ oh wait, ubuntu uses -dev 00:20
grrrr
Austin What's the other target name?
pmichaud_ what we had previously (before this weekend)
'make install' -- install parrot runtime environment
'make install-dev' -- same as 'make install', plus all files needed for development
Austin Why does a packager want that? 00:21
pmichaud_ they don't
but developers do (more)
japhb (My only concern was that there be targets in the makefile that packagers could use for both cases, so they stopped trying to guess what we really want. I don't strongly care what they are named, as long as it makes some semblance of sense.)
pmichaud_ typically if I do "apt-get install foo-dev", I expect to get 'foo' plus its development environment
I vote for "install-dev-only"
japhb pmichaud_, fine with that
pmichaud_ which *only* installs the development files
japhb yup 00:22
pmichaud_ and perhaps install-bin should be install-bin-only
but I'll let someone else make that decision/change
japhb fine with that too.
plobsing could someone take a look at TT1147 ? 00:23
japhb So now we'd have install -> install-dev -> (install-bin-only + install-dev-only)
ttbot Parrot trunk/ r42096 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/123678.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
pmichaud_ actually, I'm going to do
install-dev -> install
install -> (install-bin + install-dev-only)
japhb check it in. ;-) 00:24
pmichaud_ testing now.
tested, committed. 00:28
dalek rrot: r42097 | pmichaud++ | trunk/config/gen/makefiles/root.in:
[install]: Per further discussion on irc, add a new 'make install-dev-only'

and 'install-dev-only', and 'make install-dev' is just an alias for
  'make install'.		 00:29
purl 'make install' is just plain all over the place for non-module things..like templates, etc
japhb purl, forget 'make install' 00:31
purl japhb: I forgot 'make install'
japhb I spend more time telling purl to forget stuff than any other interaction, I think.
Austin :) Japhb, you just have to love her for what she is. Trying to change her is like teaching a pig to sing. 00:32
pmichaud_ I don't mind that parrot automatically picks up useless facts, I just mind that she spouts them off when not explicitly asked for them.
s/parrot/purl/
Liza How do you feel about she spouts them off when not explicitly asked for them? 00:34
pmichaud_ whips out his bazooka ... "THIS IS HOW I FEEL ABOUT IT. MUWAHAHAHAHAH" 00:35
wow.... latest parrot is _much_ faster (for nqp-rx) than 1.7.0 00:36
(parrot-devs)++
bacek_at_work pmichaud_, about 40% faster. Still slower than 1.4...
pmichaud_ yes, 40% is about what I'm seeing 00:37
Coke no, 'make install' is <reply>
(then she can't relearn it. 00:38
ttbot Parrot trunk/ r42097 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/123728.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
pmichaud_ oh, wait 00:39
I might be testing the wrong version of nqp-rx
Austin Pmichaud_, I'm getting an error saying "A method named '_ABSTRACT_METHOD' already exists in class 'Class::BaseBehavior'. It may have been supplied by a role. 00:40
pmichaud_ Austin: never seen anything like it before
Austin Is that from reloading pbc, or re-defining the class, or what?
pmichaud_ probably from one of those two items, yes.
Austin :( 00:41
Neither have I.
pmichaud_ I've seen the "already exists" message before, yes.
it often occurs when attempting to redefine a class
or when something gets run/loaded more than once
especially things like :init :load subs that appear at the top of a .pir file and there is no :main
whiteknight bacek++ and chromatic++ have been kicking ass on the optimization front 00:43
pmichaud_ ugh. I _really_ need to find a way to get a handle on the :main sub inside of a .pbc file
e.g., when loaded via load_bytecode
Austin I'm working on that. 00:44
pmichaud_ how so?
Austin krt0.pir
pmichaud_ that doesn't mean anything to me :-|
Austin It's a framework that grabs control, sets up some stuff, etc.
pmichaud_ I think that load_bytecode should be able to return the .pbc that was loaded. 00:45
Austin So [],main is called, unless you register_main something else. And init ordering is supported.
I agree.
It would be nice to be able to inspect the namespaces, etc, that just came in.
whiteknight pmichaud_: what are you talking about, that you would be able to get a Sub PMC for the :main sub?
pmichaud_ whiteknight: yes
so that I can execute the .pbc's mainline code somehow 00:46
(but preserve the ability to load the .pbc w/o executing the mainline code)
Austin Whiteknight: When you do load_bytecode, currently it returns nothing. For managing libraries, it would be nice to inspect the loaded pbc, get a list of :mains, :inits, etc.
pmichaud_ currently rakudo jumps through all sorts of hoops to try to manage the order of execution under the various load/init/main contexts 00:48
and it looks like I'll have to do something similar for nqp-rx
ideally I'd expect to get back the same sort of PMC that doing a runtime PIR compilation would give me 00:49
i.e,. it's a PMC that contains the entire bytecode image that was loaded
Austin There's your answer.
Don't use load_bytecode, just compile the pir.
:)
pmichaud_ that's actually pretty tempting. 00:50
of course, that doesn't help me out when all I have is a .pbc that I got from somewhere else.
alas, looks like I was wrong about the speed improvement :-( 00:51
Austin pbc_dump --disassemble file.pbc > /tmp/newfile.pasm ?
pmichaud_ I was running a very old (and much smaller) copy of nqp-rx
whiteknight I've been trying to plan a comprehensive redo of the way subs are compiled and execued 00:55
so all this information is good feedback
Austin Man, even without annotations the exception-locator was off by 5000 lines. :( 00:58
whiteknight IMCC should return an array of all compiled subs, and then I think some sort of execution engine (the scheduler?) should execute them in order
pmichaud_ I prefer what we have now
IMCC returns an Eval PMC, which contains an array of all compiled subs
invoking the Eval PMC invokes the first compiled sub 00:59
whiteknight that's basically what I'm saying
00:59 abqar joined
pmichaud_ certainly "execute all compiled subs in order" is incorrect. 00:59
whiteknight I'm simplifying
probably too muc
pmichaud_ I'd like for load_bytecode to likewise return an Eval PMC
then I can start introspecting it for things that I need
whiteknight okay. So if we add another variant of load_bytecode that returns the Eval PMC, that would satisfy? 01:00
pmichaud_ seems like it would, yes.
it would certainly remove quite a few hoops I currently have to jump through. 01:01
whiteknight where does the Eval PMC come from now, the PIR compreg?
pmichaud_ yes.
whiteknight okay. 01:02
okay, I think I see how this works 01:08
If I create an Eval PMC, and pass that to Packfile_fixup_subs, it should populate it
I wonder if that will execute :load subs though?
pmichaud_: do you want :load subs to execute immediately, or do you want them in the Eval PMC and you can execute them manually? 01:09
pmichaud_ execute immediately, same as IMCC
I suspect that if I don't want them to execute immediately I'd just use 'thaw'
whiteknight okay, I think I can add this 01:10
Austin Okay, now I'm into space weirdness. I'm getting an exception from a sub that doesn't exist anymore. ?:-( 01:11
How do I print out the searchpath for pir/pbc files? 01:12
whiteknight pmichaud_: patch in testing now 01:23
ah, nevermind. PGE doesn't build now 01:29
so I'm probably not handling :load subs correctly now
will work on it tomorrow
Going to bed now. Goodnight
Austin sings, "Children, I hope you sleep tight! And don't let the bedbugs bite. If you should die before you wake, pray good God your soul to take!" 01:31
01:33 s1n_mini joined
dalek p-rx: a669f19 | pmichaud++ | build/ (2 files):
Clean up Makefile a bit, bump PARROT_REVISION.
 02:23
p-rx: 920efd9 | pmichaud++ | src/PAST/Compiler-Regex.pir:
[regex]: Add 'pastnode' type for PAST::Regex.
 02:24
02:34 eternaleye joined
bacek_at_work pmichaud_, can you give some good example in nqp-rx for performance testing? I'll try to do something tonight. 02:41
Coke so, when I switch from a tclint pmc (subclass of Integer) to a class defined in PIR, I start getting MMD errors (no suitable candidate) for add. I wasn't overriding add before. any clues/ 03:11
?
pmichaud_ Coke: sounds like the ongoing mmd bugs. 03:19
03:24 eternaleye joined 03:27 eternaleye joined 03:47 janus joined 04:20 mikehh joined 04:24 mikehh joined 04:55 eternaleye joined 04:58 eternaleye joined 05:03 mikehh joined 05:06 theory joined 05:10 mberends joined 05:15 hiroyuk__ joined
dalek p-rx: 63139fe | pmichaud++ | (3 files):
Refactor the build/bootstrap build process to avoid cross-stage conflicts.
 05:29
p-rx: 1a369e2 | pmichaud++ | (6 files):
More build process cleanups. Add :PIR{{...}} modifier for inlined PIR
05:33 kurahaupo joined
dalek p-rx: 4039648 | pmichaud++ | build/Makefile.in:
Improve "make clean" target a bit.
 05:41
05:47 eternaleye joined 05:52 rhr joined 05:58 chromatic joined 06:00 patspam joined 06:09 JimmyZ joined 06:26 cotto joined
cotto hi 06:35
bacek_at_work cotto: looks like you've lost last "o" :) 06:48
06:59 uniejo joined 07:13 desertm4x joined 07:18 desertm4x_ joined 07:32 KatrinaTheLamia joined 07:39 iblechbot joined 07:42 fperrad joined 07:50 flh joined
flh is there a way to manipulate contexts from a dynpmc? I'm trying to call for example Parrot_set_new_context, but the linker complains about this symbol not being found (I guess it's due to the fact that it doesn't have PARROT_EXPORT) 07:57
chromatic What problem are you trying to solve with that call? 08:00
flh I want to push a new context (like the current Sub PMC does), to call some PIR code 08:01
actually, it sounds like there are functions to call PIR subs from C :) 08:02
ok, but this will probably create a nested runloop, which was not really part of my plan 08:05
so I'll try to give move details: I have a subroutine, which returns another subroutine 08:07
when the first one returns, I want its result to be automatically invoked
so I wanted to use a continuation PMC, which would invoke the result sub: pushing a new context (so between the caller's context and the sub's context) would allow the continuation to fetch the second subroutine 08:09
unfortunately, it seems that I actually have no way to play with contexts from a dynpmc 08:10
chromatic That sounds like a tailcall to me. 08:13
dukeleto 'ello 08:14
flh more or less: I want "first_sub(a,b)" to act as "$P0 = first_sub(a, b) ; .tailcall ($P0())" 08:15
treed wouldn't that be an infinite loop? 08:16
since the first thing your function does is call itself?
with the same parameters
It'd never reach the tailcall 08:17
(Unless I'm missing something.)
flh actually, the syntax "first_sub(a,b)" does not have the same semantics in my two statements
treed I see. 08:18
so the first one wasn't PIR?
dukeleto msg Whiteknight the RTEMS devs are going to send me a makefile that compiles and then we have to make our configure system generate that. darbelo is on board to hack on it as well
purl Message for whiteknight stored.
flh the first one isn't PIR :) It's my-own-invoke
treed Aha. 08:19
treed really has to go to bed.
flh the thing is: I want this to be regular PIR, but with a custom Sub PMC which redefines the invoke method to behave like the statement on the right
desertm4x_ dukeleto: What's RTEMS, btw? 08:20
moritz RTEMS? 08:21
purl RTEMS is a real time OS
desertm4x_ oh, thanks purl, moritz. :-)
moritz (I don't know more than that either :)
JimmyZ purl: no, RTEMS is the Real-Time Operating System for Multiprocessor Systems, see www.rtems.com/ for more. 08:24
purl okay, JimmyZ.
JimmyZ RTEMS?
purl RTEMS is the Real-Time Operating System for Multiprocessor Systems, see www.rtems.com/ for more.
08:25 KatrinaTheLamia joined
Austin flh: If you have a custom sub pmc, what are you expecting to put in it? 08:28
flh it extends the core Sub, and only redefines invoke
Austin Sure, but Subs are instantiated objects. So whose code is going to be compiled down to this object type? 08:29
flh maybe the answer is: they will map Sub in my HLL
dukeleto desertm4x_: a real-time embedded OS 08:30
desertm4x_: i talked a bunch with their core devs, and they are very interested in getting parrot working on it
which i think is pretty awesome
i also got lots of interesting security ideas from the Tor folks 08:31
flh Austin: so every sub created by my HLL should use this custom sub pmc
Austin I genuinely don't know if that will work or not. If you compile 7 .sub 'foo' ; .return (1) ; .end from PIR, and load it in an HLL that remaps Sub, I suspect that the loader is not going to honor the HLL map, unless you get the PBC to reference the sub type somehow.
desertm4x_ dukeleto: That sounds good, thanks for the answer.
Austin But a better question is, what on earth for? 08:32
flh it's actually part of handling natively curried subs 08:33
Austin Okay.
Can you give me a simple example? 08:34
flh take: .sub 'identity' ; .param pmc x ; .return (x) ; .end
08:34 gaz joined
Austin takes 'identity'. 08:35
flh so "identity(identity)" is again the identity function: I want in this case "identity(identity, 42)" to return 42
Austin But that's not identity, it's apply. 08:36
flh in some sense your right
I want my sub pmc to realise that "identity" only takes one argument 08:37
Austin And pre-execute the inner identity? 08:38
flh so it leaves the "42" somewhere, then calls "identity(identity)", gets the result of this application and feeds the "42" to it
Austin Ah.
flh that's it
Austin You want it to be 7 identity(identity)(42) , instead of 7 identity( identity(42) ), right? 08:39
flh yes, left one is what I want
Austin Would that be recursive? Should 7 identity(identity, identity, identity, 42) also work? 08:40
flh it's actually lambda-calculus: (((id id) id) id) 42 08:41
so yes, I expect it to work :)
Austin I don't think you need a new Sub pmc. 08:42
flh I know Parrot was not specifically designed for such questions, take it as a challenge
Austin :)
flh if you have a better suggestion, I would be really happy to hear it 08:43
but I definitely want the syntax "identity(identity, identity, identity, 42)" to work in PIR 08:44
Austin In pir?
Or in your hll?
dalek trixy: 12424a0 | dukeleto++ | ROADMAP.pod:
Fix a pod warning in ROADMAP.pod
trixy: d303187 | dukeleto++ | README.pod:
Fix warning in README.pod
flh Austin, in PIR 08:45
dukeleto i recently learned that ohloh.net makes money by selling info to big corporations about development activity in languages/countries/app stacks/etc. Good to keep in mind. 08:46
Austin The only way that can work in PIR would be if identity was a register.
moritz urgh.
dukeleto: any link which describes that?
I mean it doesn't disturb me as long they don't sell infos about individual developers, for example 08:47
dukeleto moritz: nope, I just talked to one of their devs
moritz: i do not know the level of detail involved
Austin flh: PIR does not support lexicals or package scope references that don't go through a lookup opcode. 08:48
7 $P0 = get_global 'identity' ; $P0($P0, $P0, $P0, 42)
flh this one is certainly ok for me
Austin ? 08:49
moritz flh: is your goal to implement some functional language?
08:49 eternaleye_ joined
flh moritz, yes it is 08:50
moritz flh: would it make sense to do the partial application thing by static analysis, and emit more idiomatic PIR code instead?
(don't know if "idiomatic" is the right word here...) 08:51
08:51 bacek joined
bacek o hai 08:51
flh I'm not sure there exists an easy way to figure out how to write the application
Austin What happens if the arity is > 1?
flh moritz, for sure, I know the type of my functions, but I cannot easily distinguish between (a -> a) -> (a -> a) (which is identity(identity) in my previous example and (a -> a) -> a -> a (the sub which takes two arguments and returns the second one) 08:53
moritz and can you distinguish between the two non-easily? :-) 08:54
flh I'm running into trouble certainly because I want my subs to look uncurried if someone wants to see them this way
Austin I think this may be a non-issue. You just define an arglist coercion rule and include that in all your generated subs. 08:55
flh moritz, I think I can only know at runtime, when the sub is actually invoked (imagine: read a boolean, define $P0 as identity(identity) when it is true, and the second projection when the boolean is false ; then call $P0: depending on the value of the boolean, we have to choose between two different ways to call $P0) 08:58
Austin 7 .sub 'foo' ; .param pmc a ; .param pmc b ; .param pmc more :slurpy ; $I0 = elements more ; unless $I0 goto do_work ; ... coerce args ... ; do_work : ... .end
Is there a common or standard args coercion rule? 09:00
If I define add(a, b) and then call it as add(a, b, c), what do I get?
flh if "add(a,b)" returns a function, then "add(a,b,c)" is this function applied to c 09:01
if "add(a,b)" doesn't return a function, then "add(a,b,c)" gives you an error
Austin So the rule in that case would be "die 'too many args'"? 09:02
flh yes
Austin (Which is what Parrot does by default, btw.) 09:03
flh but my DynPMC would work if it were allowed to call Parrot_set_new_context... 09:05
Austin I can't help you there. Sorry.
flh is there a reason not to PARROT_EXPORT it?
moritz ask allison :-)
09:05 mikehh joined
chromatic I'm still not sure that's an approach we want to encourage, manually setting control flow like that. 09:06
flh continuations already provide the ability to do strange things with control flow 09:08
chromatic Sure, but you're talking about manipulating them at below the level of continuations. 09:09
flh but it's just a very little bit below this level :) 09:10
chromatic Maybe, but I'd grab the current continuation at the first invoke, inspect the return value of the sub, then invoke it if it's invokable with the stored continuation. 09:11
flh I think that's what I'm trying to do 09:13
the tricky part is "inspect the return value of the sub": I think I need to set up a specific context to grab this return value
chromatic Not if you're dispatching from C. 09:14
flh ok, agree on that
there was a problem with exceptions thrown from inferior runloops, has it been resolved? 09:15
bacek chromatic: ping 09:22
chromatic pong 09:23
09:24 xenoterracide joined
bacek what about merging CallSig and Context? 09:24
chromatic Seems like the next logical step. 09:25
We should list on the wiki the behavior they both have to support (especially in terms of attributes and the vtable interface).
bacek there is not intersection between Context and CallSig currently 09:26
(in VTABLEs)
Apart from set|get_attr, which is resolvable
chromatic There's not much in Context at all, is there? 09:27
bacek chromatic: almost nothing
purl it has been said that almost nothing is up to date
bacek I think we merge Context into CallSig. 09:28
Just add pointer for Parrot_Context
chromatic Which is easier, moving the fields of the context stored in Context's PMC_data() into Context attributes and getting rid of the old struct, or merging in CallSig?
bacek Parrot_Context has variable size...
chromatic Also, what are the implications for the :call_sig behavior and custom CallSigs in Rakudo? 09:29
bacek :call_sig will just return "The Context"
chromatic I'm sure we could figure out variable sizes somehow.
bacek which is union of Context and CallSig
chromatic: we can. But we can't use ATTRs for it 09:30
chromatic I don't see why not.
It's only the register storage that's variable sized. 09:31
bacek chromatic: then we have to use second call to alloc registers. 09:32
chromatic True. 09:33
bacek it was main reason why I didn't migrate Context to ATTRs...
chromatic We have to do three allocs for a Context/CallSig PMC anyway: the header, the attributes, and the register storage. 09:35
bacek Right. I can trade allocation of whole Parrot_Context for allocation of registers only. 09:36
let's create branch!
chromatic Bring it on. 09:37
purl That's allright, that's OK, you're gonna pump our gas some day
bacek "context_unify"?
chromatic Sure.
bacek oh shi... git decided to fetch old history... It will take some time... 09:40
dalek rrot: r42098 | bacek++ | branches/context_unify:
Branch for merging CallSignature and Context
 09:41
bacek chromatic: CallSignature, Context of CallContext? 09:42
s/of/or/
or even ParrotContext 09:43
moritz CallFoo :-)
bacek CallFu :)
chromatic ParrotCall?
bacek it's not "Call" only. 09:44
"Frame"? (ignoring fact of CPS)
chromatic Returns are calls in CPS. 09:45
Maybe the simplest is CallContext.
bacek deal
btw, if I put fields from CallSig into Parrot_Context then we can have 2 allocations only 09:46
chromatic Exactly. 09:47
We might have to profile and move things around depending on processor cache access though.
bacek Sure 09:49
09:51 masak joined
jonathan ain't sure how this context/call-sig merge is going to work out. 09:57
I'll handle getting Rakudo going on trunk again, but I'd appreciate patches as needed if this second branch works out/lands. 09:58
dukeleto msg Infinoid dalek still does not know about pl/parrot, even tho' it is on the wiki languages page 10:02
purl Message for infinoid stored.
10:04 abqar joined
chromatic jonathan, it should be reasonably transparent. 10:04
jonathan chromatic: The main thing I see is that I'd rely on being able to use the CallSignature multiple times. 10:06
And if the context and call signature are merged, that may get more interesting.
May have to start cloning it for example.
dalek rrot: r42099 | bacek++ | branches/context_unify/src (1 files):
Rename Context into CallContext.
 10:07
rrot: r42100 | bacek++ | branches/context_unify (3 files):
Copy ATTRs from CallSignature into Parrot_Context structure.
rrot: r42101 | bacek++ | branches/context_unify/src/pmc/callcontext.pmc:
Move functions from CallSignature into CallContext
rrot: r42102 | bacek++ | branches/context_unify/src/pmc/callcontext.pmc:
Move banch of VTABLE and functions from CallSignature into CallContext.
 10:24
rrot: r42103 | bacek++ | branches/context_unify/src/pmc/callsignature.pmc:
Remove CallSignature PMC.
 10:37
rrot: r42104 | bacek++ | branches/context_unify (3 files):
Update various build_sig_object functions to use CallContext
10:37 plobsing joined
bacek oookey. "It compiles" :) 10:39
hmm... Not really. 10:40
10:42 zak_ joined 11:04 szabgab joined
dalek rrot: r42105 | bacek++ | branches/context_unify/config/gen/makefiles/root.in:
Update makefile dependencies.
 11:06
rrot: r42106 | bacek++ | branches/context_unify (2 files):
Added accessors for new Parrot_Context fields.
 11:09
rrot: r42107 | bacek++ | branches/context_unify/src/call/context.c:
Initialise new fields in Parrot_alloc_context.
rrot: r42108 | bacek++ | branches/context_unify (2 files):
Remove duplicated field "current_results" vs "results"
moritz msg chromatic rt.cpan.org/Public/Bug/Display.html?id=50794 if you haven't seen it already 11:25
purl Message for chromatic stored. 11:26
11:32 bacek joined 11:36 mikehh joined 11:43 patspam joined
dalek rrot: r42109 | bacek++ | branches/context_unify/src/call/args.c:
Use CallContext accessors instead of poking into dead CallSignature attributes
 12:05
12:07 bluescreen joined
dalek rrot: r42110 | bacek++ | branches/context_unify (7 files):
Remove current_sig from Parrot_Context. Start switching to CallContext from CallSignature
 12:08
Coke yawns. 12:09
12:20 whiteknight joined
whiteknight good morrow #parrot 12:26
Coke guten morgen 12:31
whiteknight hello Coke 12:41
how is partcl doing today? 12:59
Coke segfaulting. 13:10
purl segfaulting is probably hardly a good way to deal with bad data
Coke (trac.parrot.org/parrot/ticket/1131)
13:23 iblechbot joined 13:28 bluescreen joined
whiteknight well, segfaulting is lousy 13:30
there are two assign_p_p calls in that code snippet. Which one segfaults? 13:31
13:34 mikehh joined
Coke I think it's the second one. 13:39
whiteknight okay, that's interesting 13:57
14:00 Andy joined
pmichaud_ hmmmm.... somewhere either I (or parrot) has introduced a bug somewhere that causes 'nqp-rx' to randomly fail. 14:12
jonathan :-( 14:13
pmichaud_: Random in what sense? Fail in what sense?
pmichaud_ random in the sense that sequential executions of the same script give different results 14:14
jonathan Oh, ouch.
-G ?
purl i guess -G is computed goto
jonathan purl: I GUESS IT'S NOT.
purl jonathan: excuse me?
jonathan purl: forget -G
purl jonathan: I forgot -g
pmichaud_ I'll try that, but I think last time I tried it made no difference
moritz pmichaud_: did that happen after you bump PARROT_REVISION the other day? 14:15
*bumped
pmichaud_ it's only been happening over the past few days, yes
but I also tried putting PARROT_REVISION back to 1.7.0 and I still get the random fails
Coke jonathan: --gc-debug might be more useful. (fail early, fail often.)
jonathan Aye, that too. 14:16
pmichaud_ somehow I don't think this is a gc bug.
(just a hunch)
jonathan pmichaud_: That sounds odd. You sure it's not anything to do with timestamps stuff during the compile?
I know you fixed that kinda stuff lately though...
So I guess not.
pmichaud_ timestamps in the compile has been my suspicion too, but the weirdness doesn't seem to follow (more) 14:17
for example, I'll do "make nqp-test" and of the 9 test files, only 09-var.t will fail.
Then I'll run the same command again immediately, and this time I get fails in all of 05-, 06-, 07-, and 08-, but 09 will pass.
not only that, but the 05- through 08- fails are "immediate" 14:18
Coke pmichaud_: are you running the tests in || ?
pmichaud_ no, sequential.
Coke k.
pmichaud_ pmichaud@orange:~/nqp-rx$ ./par -G t/p6regex/01-regex.t | grep '^ok' | wc -l
603
pmichaud@orange:~/nqp-rx$ ./par -G t/p6regex/01-regex.t | grep '^ok' | wc -l
591
jonathan Wow, it need not even be under the harness too. :-S 14:19
pmichaud_ pmichaud@orange:~/nqp-rx$ ./par -G t/p6regex/01-regex.t | grep '^ok' | wc -l
545
pmichaud@orange:~/nqp-rx$ ./par -G t/p6regex/01-regex.t | grep '^ok' | wc -l 14:20
603
whiteknight pmichaud_: how are they failing? unhandled exception? segfault?
pmichaud_ every once in a while, when run from the harness, it'll fail immediately with "no tests run". 14:21
But I can't see what the actual output was. If I run the harness with -v, it never fails immediately.
(at least, it's never done so yet)
at the moment they fail by simply returning the wrong output
nopaste.snit.ch/18451 # sequential make test runs in nqp-rx 14:24
Coke what is "./par" ? 14:25
pmichaud_ it's a symlink to the parrot binary executable
I can't call it "parrot" because there's a parrot subdir
Coke is it linking to the same parrot in the path in your nopaste? 14:26
pmichaud_ should be
it's the parrot in parrot_install/bin/parrot
(where parrot_install is the locally-created version of parrot for nqp)
(created via --gen-parrot)
and what's really kinda weird is the way in which the tests fails 14:28
for example, looking at the last "make test", the first set of failures are tests 17-26
i.e., the failures often come in blocks 14:29
14:29 mikehh joined
Coke are /any/ failures expected at this point? 14:29
pmichaud_ yes 14:30
oh, geezum
Coke without looking at tests 17-26, it seems more likely that they are testing something similar.
pmichaud_ nopaste coming
Coke (is it me, or is feather getting sloooower?) 14:31
pmichaud_ nopaste.snit.ch/18452 # sequential "make nqp-test" runs in nqp-rx
jonathan Wow, in the last run it fails 'em all?! 14:32
pmichaud_ yes
jonathan Super odd.
pmichaud_ not only that, but in this case each test runs in a separate process
as opposed to the earlier "make test" case where all of the tests run in a single process 14:33
nopaste.snit.ch/18453 # more nqp-rx oddness 14:34
it's gotta be an uninitialized value/register that is coming back random, something based on time, or some other random-generated sort of thing :-| 14:35
jonathan I suppose you already tried realclean, and all that stuff? Not that I can see why it'd make a big difference...
pmichaud_ yes, I've tried realclean, and multiple recent versions of Parrot
I suppose I could try a much older version of Parrot
jonathan nod
Hmm
pmichaud_ I suspect the problem is in nqp-rx and not parrot itself, but I'm kinda lost as to where to begin tracking it down 14:36
moritz bisect?
pmichaud_ it's hard to know when I have a "good" case, though 14:37
jonathan Aye.
Hmm.
pmichaud_ let's see if I can get a failure in a simple case
whiteknight the failures look like they are all happening in comp_unit 14:42
dump the PIR code of that rule and let's pick through it 14:43
pmichaud_ comp_unit is just the place where the failure gets noticed
it's not the source of the error
i.e., a match failed somewhere that should've passed
jonathan whiteknight: Parrot trunk currently fails to build for me on MS VC++ - known?
14:44 payload joined
jonathan nci_test.obj : error LNK2001: unresolved external symbol _PMCNULL 14:44
14:44 theory joined
whiteknight jonathan: not that I am aware of 14:44
pmichaud_ (I suggest working on jonathan's bug more than mine at the moment -- it's more critical)
jonathan whiteknight: Wait, didn't you fix this issue once? 14:45
whiteknight: The nci_test.dll failing to build?
whiteknight jonathan: I did fix it at one point. the pcc_reapply merger may have undone it 14:46
jonathan Ah.
whiteknight SVN branch merges: "We suck so bad, you're going to wish we didn't suck so bad"
jonathan Can you remember what you did? It looks like libparrot.lib is actually in the link line, which I thought was the issue.
14:48 payload joined
whiteknight Added a reference to libparrot to the link line for libnci_test.dll 14:51
i'm sure if you check the SVN log for root.in, you'll see the change in there somewhere 14:52
jonathan whiteknight: Hmm. But that appears to be in the link line. :-S 14:53
gah, the log only shows it changing in the merge... 14:55
Coke pmichaud_: I can duplicate the non-repeatable failures on feather with npq-rx latest and parrot-latest. 14:57
pmichaud_ nopaste.snit.ch/18454 # narrowing it down a bit!
in the nopaste, 01-regex.t has been modified to run exactly one test 14:58
Coke pmichaud_: is one of the things in your toolchain generating ids based on timestamp? 14:59
pmichaud_ yes
not solely on timestamp, but timestamp is a component
Coke so you're not really running the same code each time. =-)
pmichaud_ right, but the timestamp is simply used as a string
oh, this is interesting. 15:00
15:00 eternaleye joined
pmichaud_ nopaste.snit.ch/18455 # running 01-regex.t with the -t flag to parrot 15:01
Coke (also, -D60 is helpful to dig through the pir code that is built at runtime.)
pmichaud_ I *always* get the segfault.
at the same place.
Coke yay.
what's after that getinterp?
an hll map, guessing based on the code before it. 15:02
pmichaud_ I'd have to go find the getinterp, it's in one of the parrot libs
15:03 mikehh joined
pmichaud_ $P0 = getinterp 15:03
$P0 = $P0['namespace';1]
so it's asking for the caller's namespace
guess it's time to grab gdb on this one :) 15:06
bah
the segfault is in the tracer
that doesn't tell me anything other than -t has a bug in it :-(
15:06 PacoLinux joined
whiteknight urg 15:08
pmichaud_ nopaste.snit.ch/18456 # execution and backtrace
jonathan whiteknight: Heh. I have a patch that, uh, "works". 15:09
whiteknight jonathan: stop building libnci_test?
jonathan whiteknight: Thing is, nci_test.c really is an excention, so it should define PARROT_IN_EXTENSION.
*extension 15:10
pmichaud_ since I don't want to spend my morning debugging the -t option, I think I'll run gdb w/o the -t
whiteknight pmichaud_: good idea
purl whiteknight: Good Idea: Finding Easter eggs on Easter morning. Bad Idea: Finding Easter eggs on Christmas morning.
jonathan whiteknight: However, it doesn't, meaning that we don't end up importing PMCNULL, we try and export it instead. Then we fail.
whiteknight: However, we then get the "fun" that nci_test.c wants to mark stuff as exported.
whiteknight jonathan: that actually makes goo sense
jonathan And we only seem to define PARROT_EXPORT, which depends on PARROT_IN_EXTENSION 15:11
pmichaud_ before I do that, let me see if I can file a ticket for the -t segfault
jonathan So I can get this to work by ripping all uses of PARROT_EXPORT out of nci_test.c and defining PARROT_IN_EXTENSION at the top.
I wonder if I now fail tests though. 15:12
15:12 Psyche^ joined
whiteknight jonathan: parrot builds for me on win32 no problem 15:13
jonathan whiteknight: Compiler?
purl Compiler is a controversial feature of Perl5.005 which will probably be used for evil ends or a way for the unenlightened to make themselves think their programs will run faster.
whiteknight jonathan: strawberry
purl somebody said strawberry was a Perl for Windows that works just like Perl everywhere else. See win32.perl.org/wiki/index.php?title...berry_Perl or well where is RAWBERRY
particle i haven't been able to build parrot on windows for two weeks
jonathan Oh
That's MinGW
Not MS VC++
whiteknight oh, you're on VC++? 15:14
jonathan Yes.
whiteknight urg
jonathan I'm guessing particle is too.
particle yep, of course
whiteknight so then 1.7.0 probably went out the door not building on VC++
particle yep
jonathan Well, heh, I fail all of the nci tests.
But that beats not building
whiteknight all my testing was strawberry
jonathan So in goes the patch.
whiteknight jonathan++
particle 1.7 went out without building on msvc
jonathan And we can iterate on it.
Coke particle: what happened to our windows remote access?
whiteknight We need to kill those tests anyway, rework them into something better
Coke (is it just waiting for someone to use it?) 15:15
whiteknight we have remote access to a windows machine somewhere?
particle coke: gotta ask alias about that, i guess. iunno if that ever happened for cpan users, either.
jonathan whiteknight: I think we also need to define some separate symbol for if you want to just mark something as export that isn't tangle up in whether we're inside Parrot or in an extension.
particle alas, i haven't been in touch with microsoft for quite some time now
pmichaud_ trac.parrot.org/parrot/ticket/1149 15:16
dalek TT #1149 created by pmichaud++: [bug] Segfault in -t trace output 15:17
pmichaud_ (what dalek++ said)
jonathan oh wait, I can use PARROT_DYNEXT_EXPORT 15:18
Hopefully this fixes the build *and* passes the tests... 15:19
15:22 eternaleye joined
pmichaud_ nopaste.snit.ch/18457 # segfault and backtrace when running minimal 01-regex.t 15:22
it appears the problem always occurs when attempting to take a substr
sometimes it gives "Cannot substr on a null string" 15:23
sometimes it works
sometimes it segfaults
unfortunately the backtrace doesn't give me a lot of clues about _which_ substr operation resulted in the segfault.
15:24 mikehh joined
jonathan pmichaud_: cur_opcode=0xb6d09ea4 will, er, help if you can find a pointer to the start of the current bytecode data segment... 15:25
dalek rrot: r42111 | jonathan++ | trunk/src/nci_test.c:
Corret usage of symbol import/export in nci_test.c. Fixes the build on MS VC++.
jonathan ...and then somehow match that up with the PIR (maybe pbcdump)
But it's a long shot. :-(
pmichaud_ yes, not having -t1 here really hurts.
jonathan got a bt for -t1 segfault pasted? 15:27
pmichaud_ I can get one easily.
I just added a backtrace to the ticket 15:28
trac.parrot.org/parrot/ticket/1149
although, given that both segfaults are related to producing strings, I wonder if they are, in fact, related :) 15:29
oh, hmm, I bet I can follow the interp structure to figure out what sub I'm in. 15:30
Coke (nci_test) are we still linking that into the parrot executable?
jonathan Coke: I didn't know we ever were. 15:31
Coke: We aren't now though, for sure.
We link against libparrot
Coke er.
ok. yah, should we be doing that, even?
that is, I'd expect nci_test to depend on libparrot, but not vice versa. 15:32
jonathan That's how it is. 15:33
pmichaud_ nopaste.snit.ch/18458 # can someone explain frame #0 in this backtrace ? 15:34
15:40 uniejo joined
pmichaud_ in gdb, how can I display the current_sub entry of a context PMC? 15:41
(I used to know how to do it when contexts weren't PMCs)
nm, found it. 15:42
15:42 ruoso joined, Essobi joined
Essobi Howdy. 15:43
15:43 payload joined
Essobi I can't find any documents relevant to the state of threading in the PVM... Am I overlooking something? 15:45
pmichaud_ Essobi: I'm not aware of any current documents on threading. 15:46
moritz trac.parrot.org/parrot/ticket/757 describe some not-so-nice aspects of the current state 15:47
15:50 masak joined 15:51 einstein joined
Essobi www.parrot.org/files/Fagerholm-Parrot.pdf mentions it 15:58
moritz that's like, 4 years old 15:59
is there any subsystem that wasn't revamped in the last 4 years?
16:01 masak joined
Essobi moritz: Fair enough. So.. are there no threading ops in PIR? 16:02
moritz Essobi: there is some threading support, but not yet good enough for most HLLs
pmichaud_ There may be threading ops, but I don't know what they are.
Essobi Drat. 16:03
moritz pdd25_concurrency.pod should document them
but I don't know how up-to-date it is
16:07 solarion joined
solarion just got the Parrot Developer's Guide: PIR. :) 16:07
Essobi - Parrot supports multiple concurrency models, including POSIX threads, event-based programming, and asynchronous I/O. <--- YAAAAAAY 16:08
pmichaud_ it might be more accurate to say that Parrot's *design* supports .... 16:09
moritz wonders if that is a flat lie
16:09 davidfetter joined
pmichaud_ I'm not sure if the implementation supports all of that yet :-| 16:09
Essobi docs.parrot.org/parrot/devel/html/d...y.pod.html
pmichaud_ "pdd" == "Parrot Design Document", fwiw 16:10
Essobi right right.. I get it. 16:11
pmichaud_ okay, I *think* I've narrowed down the nqp-rx problem I'm seeing, but could use some feedback 16:12
I think the problem is that I have a hash that has entries added to it while it's being iterated. Is that a no-no in Parrot?
(I didn't realize the hash was being modified during iteration until just now) 16:13
moritz it would certainly explain a lot
pmichaud_ anyway, that seems to confuse the heck out of the Iterator, and it ultimately returns me a null string
Essobi .... there is a pmc for threads...
jonathan The Rakudo branch pccupdate on github is the initial bits on getting us using the new Parrot Calling Conventions.
pmichaud_ (not an empty string, a true string NULL pointer) 16:14
jonathan We can now compile the pmcs and ops again.
However, segfault soon arrives later on.
pmichaud_ jonathan++ !!!
or it otherwise returns a garbage pointer
jonathan pmichaud_: I don't know either way, but it sounds like a good suspect. 16:15
Essobi and the concurrency scheduler..
pmichaud_ is there something that randomizes hashes somehow now?
I've noticed that identical runs often produce different hash results
cotto_w0rk pmichaud_, yes 16:16
pmichaud_ that would explain why I'm getting random results, then.
jonathan Aha.
Nice explanation.
jonathan needs to go lie down for a bit - feeling ill-ish. :-/ 16:17
moritz hopes jonathan recovers quickly
whiteknight Essobi: we have threads, and they do work, but they are not good 16:22
we have event-based stuff with tasks and exceptions
we don't have asynchronous IO 16:23
Essobi: see the examples in t/pmc/threads.t, t/pmc/task.t, t/pmc/timer.t and t/pmc/scheduler.t
dalek rrot: r42112 | NotFound++ | trunk/src/runcore/trace.c:
[core] fix trace keys, TT #1149
 16:24
whiteknight pmichaud_: bacek did a refactor a while back that randomized hash keys 16:25
and as far as I am aware, modifying a hash while iterating it is a big no-no
pmichaud_ yes, but is "segfault" a correct response to that? ;-) 16:26
dalek TT #1149 closed by NotFound++: [bug] Segfault in -t trace output
moritz pmichaud_: probably not :-)
cotto_w0rk pmichaud_, if you want it to be deterministic, I think src/string/api.c +274 is the right code to change 16:28
pmichaud_ well, it's good to know that instead of blaming the garbage collector for our random segfaults, we can now start to blame hashes for them as well. 1/2 :-)
16:29 uniejo joined
cotto_work maybe we should make it deterministic on non-optimized builds under the assumption that optimized is what end-users will care about. 16:29
whiteknight modifying a hash that is under iteration should probably throw an exception instead
pmichaud_ how would a hash know it's under iteration, though?
whiteknight i didn't say it would be easy to do it :) 16:30
pmichaud_ the onus is on the iterator, not the hash
just because an iterator exists for a hash doesn't mean it's ever going to be iterated again. we might've broken out of a loop.
an iterator would need to detect that a hash has been modified, and then throw an exception.
whiteknight that works too 16:31
NotFound Iterator existence may mean just the GC is being lazy ;)
dalek rrot: r42113 | NotFound++ | trunk/src/runcore/trace.c:
[cage] drop redundant cast from r42112
cotto_work xkcd is special today 16:34
japhb cotto_work, I don't think anything should vary semantically between opt and non-opt builds. 16:35
NotFound Great! :)
cotto_work japhb, thinking about it more, I agree. 16:36
it'd be nice to have an easy way to make hashing repeatable, though 16:37
japhb Sounds like a Configure option to me 16:38
cotto_work I was thinking runtime, but those are kinda crufty atm. 16:39
japhb I would have said 'env var' but I know random hashing is a security thing, so I don't want to make it any easier for the attacker
cotto_work Yeah. It's "randomized" in the first place to avoid vulnerabilities from predictable hashing. 16:42
mikehh All tests PASS (pre/post-config, smoke (#29400), fulltest) at r42111 - Ubuntu 9.10 RC amd64
pmichaud_ well, random hashes also makes it less likely for someone to write code that (inadvertently) depends on the ordering of the hash
cotto_work I remember finding that out when I added the randomization. ;) 16:43
mj41 MS VC++ fixed in r42111, jonathan++ 16:47
pmichaud_ yay, avoiding the modification-while-iterate seems to have resolved the problem. 16:48
thanks to all for suggestions and help 16:49
jonathan pmichaud++ # debugging skillz 16:52
moritz: I think I'm just a tad exhausted, that's all.
cotto_work ugh. Flashbacks. www.guidebookgallery.org/screenshots/macos70
pmichaud_ jonathan: how was IPW, btw? 16:53
16:55 hercynium joined
jonathan pmichaud_: IPW was good. I gave a couple of talks, and demo'd a partial Lolsql -> sql convertor running in Rakudo. :-) 16:55
pmichaud_ niiiiiice 16:56
jonathan I'll pop the code somewhere when I get a chance.
I didn't get loads of sleep while there and then had to get up at 4:30am to go to the airport yesterday though...so I'm kinda exhausted righ tnow.
Well, I'm hoping its that, and not that I've caught some bug. 16:57
pmichaud_ understandable. On Saturday I went to the Texas Regional Python Workshop and gave some presentations there
jonathan Ooh, nice. On PCT?
pmichaud_ Pynie and Git
jonathan Cool. :-)
pmichaud_ but they also wanted to hear about Perl culture and how Perl was addressing problems they're experiencing in the Python community 16:58
(it's amazing to see the parallels)
japhb Do tell!
jonathan Oh, interesting.
NotFound Look at the parallels in perspective, and they converge ;)
pmichaud_ for example, they are also finding themselves hamstrung by an inability to get rid of old modules out of their standard libraries (the ones shipped with python) 16:59
purl okay, pmichaud_.
whiteknight if all these languages were running on Parrot, everybody would be having the same problems!
dalek kudo: 22ded10 | (Carlin Bingham)++ | src/setting/IO/Socket.pm:
Change IO::Socket.recv() to accept a parameter specifying the number of bytes which will be received
purl dalek: that doesn't look right
pmichaud_ other issues in dealing with module archive infrastructure, and steering committees, and the like 17:00
japhb OOC, do you remember anything about the module archive infrastructure complaints? 17:01
pmichaud_ many of the same issues we hear about cpan :-) 17:02
figuring out how to manage module dependencies, especially when modules can be installed in multiple locations on a system
some people want to have a global "module registry", others are dead-set against any form of registry 17:03
japhb sigh
pmichaud_ there's an existing dependency on a standard setup/install script, which has some problems but is so complex that refactoring it or redesigning it will be a pain 17:04
moritz well, I don't think perl 6 will work without a module registry
pmichaud_ moritz: the word is "cache"
we won't have a registry, we'll have cache indexes
cotto_work sneaky
whiteknight anything to avoid confusion with the horrible Windows Registry 17:05
japhb heh
cotto_work +yes
pmichaud_ I've had some discussions with obra++ and a few others on the topic, and I'm fairly convinced that registry is not workable
moritz pmichaud_: if that's only a question of terminology, there's nothing wrong with "cache"
whiteknight still has nightmares of regedt32
japhb OK, so "make sure Plumage is easy to iterate". Check.
pmichaud_ moritz: it's not just terminology
a "registry" is something where each module adds itself as it is installed 17:06
that's not what we want
a "cache" is something that keeps track of what has been discovered, and adapts itself to whatever is in existence
put another way, registries tend to think that there's one global, correct view of the system. They're usually wrong. 17:07
caches provide views from a particular location in the system, which could be different
another way to think of it is that caches act more like lexically-scoped views, while registries tend to be global-scoped views
moritz well, if we can come up with good ideas for module name mangling, that might be workable 17:08
pmichaud_ the nice thing about a cache is that the name doesn't become important
the cache can introspect the module for the metadata, and keep it locally based on whatever name/locator the module has
in other words, the locator information (file path and/or file name) should not be responsible for holding the metadata. (it can be a key for a metadata index, but it shouldn't be the metadata) 17:09
japhb Plumage already has the concept that the project name is just a key. 17:10
I guess that's one I have right-ish. 17:11
One thing that's increasingly bothering me is what to do about uninstall and upgrade-where-some-files-should-disappear
pmichaud_ that was discussed also. I don't think there's a universal answer, I think such decisions have to be managed by site policy 17:12
japhb Yeah. 17:13
pmichaud_ parrot question: If I use the "-L" option to Parrot to add another directory to the library search path, it always adds the directory at the end. This means that a system or current-directory copy of a library will always be used in preference to any that might be found in the library directory. Is this intentional? 17:14
(same goes for -I)
japhb And as for supporting the Perl 6 "you can have any version of any module under any authority you can name" magic, I'm not sure how to make that work with Parrot.
pmichaud_ I suspect Perl 6 will have to layer its own module management on top of Parrot, unless Parrot wants to also handle that case. 17:15
japhb The problem will be modules that need PIR or C level help.
Parrot will be forced to deal with the versioning ... or alternately we create a massive name-mangling thing on top so that Parrot think's it's just loading really crazy module names. 17:16
Coke ah, C++
japhb Coke, yeah, and that's part of why it's causing me dispepsia 17:17
Mmmm, Pepsi
Coke anything with ***** in it can't be good for you.
japhb heh
pmichaud_ agreed -- that's one of the few commercial beverages I refuse to drink.
"I'll have a Dr Pepper." "We only have Pepsi." "I'll have water." 17:18
Coke I appreciate the inadvertent solidarity. 17:19
cotto_work Darn. I seem to have "American Dinosaurs" stuck in my head. 17:20
japhb Apropos of the Coke/Pepsi thing -- I spoke to a soda fountain repair guy once about the whole Pepsi Challenge thing, way back in the day. Turns out there was a reason they served the samples warm -- Pepsi and Coke react differently to temperature; Coke's flavor changes if it is not mixed and served cold. Pepsi is the same, but significantly less so. So the Pepsi Challenge was served warm.
dalek p-rx: 09880e0 | pmichaud++ | src/NQP/ (2 files):
Refactor scope and variable declarators.
p-rx: 9f56d59 | pmichaud++ | src/Regex/Cursor-protoregex-peek.pir:
[regex]: Building a tokrx hash can result in the protoregex hash

we get the complete list of method names from the protoregex hash before we start building tokrx.
p-rx: 18624fc | pmichaud++ | build/ (2 files):
Bump PARROT_REVISION to get Parrot -t fixes, and fix build sequence
pmichaud_ it's been a real pain lately because Pepsi has made exclusive deals with both of the Dallas-area airports so that only Pepsico beverages are available.
p-rx: 45d5132 | pmichaud++ | src/stage0/P6 (2 files):
Update bootstrap versions of P6Regex/P6Grammar.
pmichaud_ which means that flying outbound from Dallas I'm stuck with water in the airport. :) 17:21
cotto_work And don't even try to take it onto the plane. ;)
pmichaud_ well, I meant "after the security gate"
Coke particle, allison: Are we signed up to get spammed by efax.com?
cotto_work ah 17:22
PerlJam pmichaud_: It was the same thing in Las Vegas pepsi--
Coke karma pepsi?
purl pepsi has karma of -4
pmichaud_ pepsi--
Coke cannot remember the last time he had a real coke.
Coke suspects it was kosher-for-passover coke about ... 10 years ago.
japhb I'm an equal opportunity caffeinated-carmel-colored-phosphoric-acid-containing-beverage drinker. 17:23
particle coke: pafo has an efax account
pmichaud_ is that just another way of saying you have no taste? ;-) ;-)
japhb Mmmm, sugared coke.
Coke particle: yes. and they keep sending us spam.
japhb No, I just think of them as different drinks 17:24
Coke for example, the gotomypc ad that I'm about to discard.
japhb I like Coke in a bottle from Mexico.
jonathan didn't actually like any fizzy drink when he was a kid.
Coke (being sent to legal@parrot.org)
jonathan: HERETIC
NotFound pmichaud_: -L option was a quick addition without any design
Coke jonathan: *screamy noise from end of invasion of the body snatchers, spock version*
jonathan Coke: Nor baked beans, or eggs.
Coke jonathan: I'm not sure there's a pattern there. 17:25
pmichaud_ NotFound: hmmm.
Infinoid those don't make very good drinks, either
jonathan No.
japhb You're forgiven for not liking baked beans. Eww.
NotFound pmichaud_: I know, I added it ;)
Coke bah. we had baked beans for special occasions.
pmichaud_ generally -I and -L on other systems (e.g., Perl, C) prepend the directory to the path, not append it
jonathan japhb: Yes, while I do now not dislike most fizzy drinks, and I can handle egg in more forms, I never managed to like baked beans.
cotto_work NotFound, maybe it should get designed before it's too late to fix it.
pmichaud_ NotFound: when did it get added?
17:25 mikehh joined
NotFound pmichaud_: maybe a year ago 17:26
whiteknight doesn't drink Coke or pepsi. No soda at all, in fact
PerlJam japhb: you're a fan of real-sugar in your Coke?
pmichaud_ it's causing major fits for nqp-rx at the moment, because it means that the build process always prefers an older/installed version of a library to the one that I've just built
PerlJam whiteknight: good, you're healthier for it
whiteknight: plus that leaves more for me :) 17:27
japhb PerlJam, definitely. And I really hate the artificial "diet" sweeteners. I tolerate HFCS. Sorta.
PerlJam takes a sip of his ice cold Dr Pepper
NotFound pmichaud_: I think we can change it without breaking anything, but better ask in #ps
pmichaud_ I'll put it in my queue. Or I can send a message to parrot-dev
PerlJam japhb: I do not drink diet anything. They taste odd enough that I can't stand it.
japhb Ditto 17:28
pmichaud_ I have reactions to Nutrasweet, Splenda, and the others
so "diet soda" is also out for me :)
japhb Sodium Saccharin for the cancer causing win!
PerlJam The wind just picked up here quite a bit and now it's raining big fat rain drops 17:31
big, fat, high velocity rain drops
japhb PerlJam, a la "A Bug's Life"? 17:33
PerlJam worse IMHO, but yeah. 17:35
17:35 payload joined
pmichaud_ we've gotten a huge amount of rain here this year 17:36
Coke pmichaud_: no Tab, even? =-)
japhb We're getting it all as flash floods this fall.
... and landslides for the mountain residents. 17:37
pmichaud_ Yesterday was supposed to be week 9 of our soccer season (out of 10), and thus far we've only been able to play five games (the rest have been rained-out)
PerlJam From one of my student workers .. "this wind + heavy rain is nuts. I just double checked the weather to make sure it wasn't a hurricane I didn't know about"
pmichaud_ so at the moment the league is trying to figure out how to fit in four make-up games in the next couple of weeks, in addition to the regularly scheduled games. 17:38
and, of course, every other soccer league in the area is trying to do the same thing.
japhb ouch # to both 17:39
cotto_work whiteknight, nice mixed metaphor in your blog post 17:40
17:41 payload1 joined
cotto_work also, nice alliteration 17:41
whiteknight cotto_work: Thanks! I'm sure I put some conscious effort into either of those things :) 17:42
17:43 darbelo joined 18:03 payload joined
whiteknight we have a surprising number of little projects like that, which don't get a lot of exposure 18:08
Coke is 70025 a perl6 ticket? 18:11
(or is that for perl5?) 18:12
(looks like the latter)
einstein if think I found litte bug in trunk/parrot/src/call/context_accessors.c->get_context_str_fast 18:13
I replaced return PMC_data_typed(ctx, Parrot_Context *); with return PARROT_CONTEXT(ctx)->context; 18:14
to make my copy (with lots of my changed) of the code working
whiteknight einstein: what's the bug? 18:15
purl the bug is www.cbttape.org/funny/bug3.jpg or img227.imageshack.us/img227/2596/featureiu1.jpg
einstein sorry it is no problem 18:17
I'am still busy with ticket 1020 and removed the auto_attr (all pmc have attributes), for that reason it was problem for me 18:18
whiteknight ok 18:19
einstein the rest of the pcc reapply update did nicely merge into my changed code (had to do some minor changed) so I can go further :) 18:21
whiteknight nice 18:22
I don't know if there has ever been any kind of consensus on #1020. It was a pretty big change
cotto_work I wasn't even aware of it until you mentioned it just now. I don't seem to be alone. 18:24
einstein I know
cotto_work Getting Warnocked is almost as much fun as getting rickrolled. 18:25
einstein I did post a message in the mailing list, but got only reaction of whiteknight on the ticket :$ 18:27
dalek kudo: fc56071 | markmont++ | src/ (3 files):
make $! always be a Perl object instead of sometimes being a Parrot Exception PMC.
 18:28
einstein But i though I could try to see where would end and it is still going as planned
Coke segfaaaaaaaaaaaaaaaaault. 18:35
kthakore Coke: fun! 18:36
jonathan meh. Guess what I gotta hunt down next in my efforts to get Rakudo to run on Rakudo trunk... :-/ 18:38
Coke jonathan: a recursion recursor?
jonathan Coke: no. segfaaaaaaaaaaaaaaaaault. 18:39
Coke (do you mean parrot trunk?)
jonathan Yes.
oh
damm
Coke hopefully it's the same segfault that's killing partcl. =-)
jonathan Well, it's possible.
18:39 chromatic joined
jonathan Annoyingly, it doesn't involve any of the Rakudo specific stuff in the backtrace. 18:39
dalek kudo: 657d55c | (Kyle Hasselbacher)++ | src/setting/ (2 files):
[setting] make !% work with Whatever
 18:45
whiteknight haha, that commit message is very funny, unintentionally 18:52
nopaste "coke" at 72.228.52.192 pasted "improve this perl6 code..." (15 lines) at nopaste.snit.ch/18460 18:53
japhb Coke: What is your definition of "improve"? 18:54
Coke japhb: vague.
japhb Well, instead of has_twin doing an if-else, just return the result of the if expression directly. 18:55
Or if you're really feeling picky about the exact return, at least use a ternary instead ... 18:56
jonathan Oh ouch.
I've realized why we haz a segfault.
japhb jonathan, "we" as in Rakudo, or "we" as in Rakudo and Partcl?
jonathan japhb: Parrot. 18:57
get_iter in the MultiSub PMC assumes that we are currently doing a call.
It thus tries to sort based on the current call signature.
However, that is Null.
So we explode.
It used to just give you the candidates without worrying about a sort. 18:58
japhb Coke: also, the for loop can be considerably compacted. Perhaps: say "$_\\t{has_twin($_)}" for 1...20;
jonathan I guess I'll just check for nullness...
Coke japhb: if I don't do the if, I get 1 or undef.
(i'd really have it show true or false.)
japhb Coke, then booleanize it.
jonathan Oh hmm...get_iter complains about no applicable candidates too? :-S 18:59
japhb so: sub has_twin(Int $n) { ?is_prime(all($n,any($n+2|$n-2)))) } 19:00
chromatic jonathan, I think we can safely remove that code from MultiSub's get_iter. It looks almost unused. 19:01
Unless it's a guard condition, but it's a segfaulty guard condition. 19:02
jonathan chromatic: Hmm.
chromatic: I'm not sure if it's used. It looks...weird...to have that in there though.
japhb Coke, actually, that looks like redundant junctioning. How about: sub has_twin(Int $n) { ?is_prime($n & ($n+2|$n-2)) }
jonathan chromatic: otoh it means its possible to sort the candidates and iterate over the result which may well be useful.
chromatic It doesn't returned the sorted results or the best candidate, however. 19:03
jonathan chromatic: No, but I'm guessing it sorts the list in place? 19:04
dalek rrot: r42114 | jonathan++ | trunk/src/pmc/multisub.pmc:
[core] Eliminate a segfault and fix a regression in get_iter for MultiSub.
jonathan chromatic: I've patched it not to segfault. Feel free to rip out the whole thing and just leave the superclass method to be called though.
japhb Coke: So, without running it to see if it all works, I'd leave is_prime() alone, and do the much shorter versions of has_twin() and the for loop. Good enough? 19:05
jonathan Blech.
Now the stage 1 compiler starts, but soon after promptly segfaults.
Coke japhb: much better, danke. 19:09
japhb Coke: np, glad I could help
dalek rrot: r42115 | pmichaud++ | trunk/compilers/pct/src/PAST (2 files):
[pct/past]: Add 'nsentry' attribute to PAST::Block.
 19:11
chromatic Wow, another big jump in Rakudo passing tests.
jonathan chromatic: Might you have a moment to sanity check something with me? 19:12
I'm looking at Parrot_call_method 19:13
(extend.c)
It takes const char *signature
chromatic Right.
jonathan It then does char return_sig = signature[0]; 19:14
In the lines after it gets up Pi first - for the invocant.
And then it strcats signature on
chromatic Yes, Coke found that the other day. It's buggy.
jonathan Thing is, that means Parrot_pcc_build_sig_object_from_varargs
gets PiPP
And then seems to segfault.
Since one of those P's is the return type.
chromatic allison said to use Parrot_call_ext instead.
whiteknight should be PiP->P
is it Parrot_ext_call or Parrot_call_ext? 19:15
jonathan whiteknight: Not according to the code.
chromatic Someone* was going to write some tests in t/src/extend.t for those functions and then I'd fix them, but I've forgotten who or if that was me.
jonathan chromatic: Any reason not to patch Parrot_call_meth
?
whiteknight Parrot_call_method is definitely going away
jonathan ...wow. 19:16
allison Parrot_ext_call is the same as Parrot_pcc_invoke_sub_from_c_args, but is the public interface (and so the one guaranteed to stick around)
chromatic There's no reason not to call it, but I wanted some tests first for this. I think I was trying to give Coke homework.
jonathan I thought I applied a patch to switch Rakudo away from using something else *to* using Parrot_call_meth not so long ago. :-/
allison whiteknight: ext is the prefix for the extend/embed subsystem
whiteknight: otherwise it would just be Parrot_call 19:17
jonathan allison: So which should I use?
whiteknight allison: right, I was getting confused
jonathan: Parrot_ext_call
purl Parrot_ext_call is the same as Parrot_pcc_invoke_sub_from_c_args, but is the public interface (and so the one guaranteed to stick around)
allison jonathan: Parrot_ext_call, everything else is deprecated
whiteknight was supposed to write up deprecation notices for all of them
whiteknight was supposed to put together a list first
allison whiteknight: I started adding some deprecation notices 19:18
whiteknight allison++
jonathan allison: OK, but otoh if it's not going away until the next deprecation cycle is up, we probably should make it not segfault.
allison: Anyway, I'll switch over. 19:19
whiteknight where is Parrot_call_method defined?
jonathan whiteknight: you'll love this
extend.c ;-)
whiteknight that was my first guess
19:20 joeri joined
jonathan The one time I bother to use something that's actually in the API, it's wrong. ;-) 19:20
meh, OK, even with my patch Parrot_call_method still ends up doing something that leads to a (diferent) segfault.
whiteknight jonathan: info on the segfault? backtrace?
jonathan switches to Parrot_ext_call, hoping it is left shafted.
whiteknight: It segfaults inside the inner runloop now, doing a can. 19:21
Probably because of some argument passing fail.
allison: Argh, Parrot_ext_call uses the -> form of signatures. 19:22
That means I gotta do updates all over. :-| 19:23
whiteknight ah, Parrot_call_method doesn't pass the invocant to Parrot_pcc_build_sig_object_from_varargs
jonathan whiteknight: Yeah, the whole thing looks generally messed. :-(
whiteknight so it's overflowing the va_list
jonathan whiteknight: Yeah, that was my analysis.
whiteknight creates a pointer to whatever garbage is on the stack, then segfault
jonathan whiteknight: I figure I'll spend tuits on switching to Parrot_ext_call though, since we'll have to in the end.
whiteknight okay, good
jonathan whiteknight: I'll nopaste the other bit of the patch I wrote. 19:24
whiteknight: gist.github.com/218945
whiteknight too many interfaces to the PCC code!
jonathan Yeah, and the one to switch to here is going to make me re-arrange quite a bit of code. 19:26
jonathan is a little pissed off that he spent a while switching to Parrot_call_method after being told the previous thing he was using was not API, only to learn that it is deprecated also. 19:27
whiteknight jonathan: PCC refactors were always going to be painful 19:28
Coke whiteknight: when you change the API, that isn't a refactor.
whiteknight in fact, I remember the rakudo people asking us to push it forward anyway, despite the problems and the need for deprecation cycles
Coke: that's what they are being called colloqially
Coke whiteknight: <chromatic>words mean things</chromatic> 19:29
besides, he's only a /little/ pissed. =-)
chromatic PCC rewrites were always going to be painful.
The problem is, the old, deprecated functions don't work because they don't have any tests. 19:30
Their interfaces stayed the same.
whiteknight and because they are held together by duct tape, prayers, and unicorn tears
19:30 bacek joined
chromatic They're not great code, I admit, but they're untested code. 19:31
bacek Good morning
chromatic Anyone who feels the least bit of surprise that they don't work, I don't know what to say.
whiteknight hello bacek
bacek G'Day whiteknight
dalek rrot: r42116 | bacek++ | branches/context_unify/include/parrot/context.h:
Add optimised Context accessors
 19:33
rrot: r42117 | bacek++ | branches/context_unify/lib/Parrot/Pmc2c/PCCMETHOD.pm:
Update PCCMETHOD.pm to use CallContext
rrot: r42118 | bacek++ | branches/context_unify/src/call/args.c:
Reimplement early return from fill_params
chromatic I'm *sympathetic* to HLLs that have trouble tracking Parrot, but when tests don't flow from HLLs to Parrot -- especially tests of C components and APIs -- then I'm not surprised that HLLs have trouble with Parrot's C components.
dalek p-rx: caa7f04 | pmichaud++ | src/cheats/hll-compiler.pir:
[hll]: Remove obsolete emulation of old grammar+action setup.
 19:34
p-rx: 4c4a0e2 | pmichaud++ | (3 files):
[nqp] Initial subroutine declaration code (still missing params).
Coke chromatic: perhaps if parrot's documentation indicated which things were untested, it would be easier for us to know when to help out. 19:35
19:35 nnunley joined
Coke as it is, I try to report whenever something breaks. It's not always easy to derive tests back. 19:36
dalek rrot: r42119 | bacek++ | branches/context_unify/src/pmc/callcontext.pmc:
Remove marking of non-existing field
chromatic Assume that every time you have a bug, we need a test.
rrot: r42120 | bacek++ | branches/context_unify/src/call/pcc.c:
invoke_from_sig_object doesn't require to push_context
rrot: r42121 | bacek++ | branches/context_unify/tools/build/nativecall.pl:
Update NCI to use CallContext
rrot: r42122 | bacek++ | branches/context_unify/src/pmc/continuation.pmc:
Update Continuation to use CallContext
rrot: r42123 | bacek++ | branches/context_unify/src/pmc/multisub.pmc:
Update MultiSub to use CallContext
cotto_work bacek, do you expect any speedup from that branch or is it just to reduce code duplication?
bacek cotto_work: I already win about 15% 19:38
19:38 kthakore left
cotto_work bacek++ 19:38
19:38 kthakore joined
chromatic That's with removing some of the optimizations from trunk, isn't it? 19:38
bacek cotto_work: and expect to return back to 1.4 speed
chromatic: nope
chromatic I thought I saw some macros yanked in earlier patches. 19:39
bacek chromatic: I replaced them with other macros :)
chromatic Good.
bacek branch can compile already.
Many tests are broken 19:40
Positive note: fib.pir is faster :)
whiteknight I think maybe we should put together a database of benchmark times
chromatic I have fib.pir within 0.292% of pre-merge right now. cotto, that's with an optimized build at -O3. 19:41
cotto_work I'd really like to get a good benchmark that exercises the basic code that a HLL would use and make a graph charting our expected real-world performance as a function of the current parrot revision.
chromatic, how do you get that number?
chromatic Callgrind.
purl callgrind is probably a very intresting profiling tool for linux with details at kcachegrind.sourceforge.net/cgi-bin/show.cgi
cotto_work and just use the instruction count?
chromatic Yes.
whiteknight instruction count isn't necessarily a good metric for performance 19:42
especially if a reduction in instruction count hoses the pipeline 19:43
chromatic I pay attention to the pipeline as well, but IC is the closest thing we have to a reliable and comparable metric for performance.
whiteknight does callgrind give metrics on things like pipeline hazards, cache misses, page faults, etc? 19:44
cotto_work you can get some of that with cachegrind 19:45
chromatic Cachegrind does some of those -- mostly cache misses.
whiteknight cache misses are probably very important to Parrot performance right now
chromatic Pipeline depends too much on the specific processor, and I'm not sure you can annotate that without perturbing the results past the point of no meaning.
whiteknight I'll give you that. Won't worry about pipeline nonsense 19:46
cotto_work I suppose that on platforms where it's supported we could use clock_gettime to count exactly how much time parrot spent running.
chromatic Cache misses show what we should already know: per-GCable GC flags are ex-pen-si-ve.
whiteknight The next big GC performance improvement might be that cardmarking scheme of yours 19:47
chromatic That'll help caching, but I really do think the linked-list scheme gets us out of sweep, which cuts out half of the time and half of the memory churn of mark and sweep. 19:48
whiteknight although I'm sure PMC_is_free_TESTALL() would become more expensive
chromatic It's also not incompatible with a full mark and sweep.
whiteknight it doesn't get us out of sweep, just reduces the number of PMCs that need sweeping 19:49
and, it accesses the memory in a much more random pattern
chromatic Sweep becomes "prepend this list of headers to that list of headers".
whiteknight after "search this entire list of headers for headers with flag X set"
chromatic No searching necessary.
whiteknight oh, you're right 19:50
I'm conflating algorithms in my head
chromatic The nice part about this is that the lists can be *generations*.
whiteknight it's a nice thought. Have to worry about intergenerational pointers, however 19:51
cotto_work moritz, iwbn if the irclog search highlighted search terms in the results.
chromatic We need reliable write barriers for that.
whiteknight correction: we need ANY write barriers for that
chromatic True. 19:52
szbalint [offtopic] is tempted to reply to that maemo bug page
whiteknight i really need to look back at some of my notes. I can't put my finger on it, but I have an uneasy feeling about this algorithm 19:54
as per usual, I may be full of shit and garbage
chromatic Your uneasy feeling is probably "But what if something gets allocated during the mark?"
whiteknight it would have to be stop-the-world 19:57
dalek p-rx: 4c594ad | pmichaud++ | src/NQP/ (2 files):
[nqp]: Add simple parameters to signatures.
 19:58
whiteknight or, we could use a multi-tier scheme. Each GC run, marked items move to the top, everything else moves down 1 level
have 3 levels, so every PMC needs to survive at least every other mark
(which means new PMCs can survive the first mark without being marked 19:59
Add additional tiers as generations which get marked less often but don't automatically demote
chromatic My recent realization was that we can put new PMCs on a "maybe free" list as soon as we allocate them.
Once we start marking, we create a new maybe free list.
whiteknight Benefit to this scheme is that it translates very readily into a concurrent scheme
chromatic After we've finished marking, the previous maybe free list is the obviously free list, and we prepend that to the current free list. 20:00
whiteknight why "maybe free" and not "newly allocated"
einstein I have to go, but i would like to note that Parrot_pcc_build_sig_object_from_varargs does via CallSignatureReturns.pmc store pointers to data which is on the stack. It works but it can be dangerous if used in inproper way
whiteknight chromatic: similar to what I was just saying, just a slight difference in the order and meanings of the various lists
chromatic They're the same thing, but my theory is that we make a lot of transient garbage. 20:01
whiteknight I would agree with that.
chromatic My naming assumes that most of those GCables won't survive their first mark.
whiteknight a scheme that lets transient garbage get recycled lazily is good. The only effort we need to do is lift "live" PMCs up, and let everything else sink as group
so we only need to change the linked list root node to move the whole damn group down a peg 20:02
chromatic Basically.
whiteknight "YOU'SE GONNA DIE"
that's a quote that I actually heard one time on the subway
chromatic Once we've let mark() move the reachable ones out of that group.
whiteknight exactly 20:03
did you see that Paper on the concurrent collection algorithm? I've been very inspired by it
chromatic I didn't read it. 20:04
cotto_work My "throw stuff at whiteknight and see if it sticks" algorithm seems to have succeeded.
whiteknight chromatic: doc.cat-v.org/inferno/concurrent_gc/
cotto_work++ 20:05
I've got so many of these printed out papers in my apartment that it's creating a firehazard
20:08 Wolong joined
whiteknight what I like about that algorithm, and there are obviously places to improve, is that the transient garbage falls out the bottom in a pretty lazy fashion 20:08
And I think we can make a single-threaded implementation of it quite easily 20:09
theory hugs chromatic
whiteknight I think enough of the gristle has been removed from the GC now that we can start seriously thinking about implementing a new core 20:14
In fact, I would like a few new cores that we can race
like a soapbox derby, only a lot more frustrating and esoteric
and less fun
purl less fun is when the other people in the dream don't listen
whiteknight thinks that purl hangs around in some pretty shady chatrooms 20:15
and now it's time for me to leave. Later 20:16
jonathan Switching to Parrot_ext_call seems to have helped somewhat. 20:17
20:18 kj joined
jonathan Well, I get different failures now, anyways... 20:18
20:21 janus joined
dalek p-rx: 8d35cab | pmichaud++ | src/Regex/P6Grammar/ (2 files):
[p6grammar]: Allow names of form category:sym�foo� .
 20:23
p-rx: c4b8459 | pmichaud++ | (4 files):
[nqp]: Add relational ops, prefix ops.
rrot-linear-algebra: 34615d0 | darbelo++ | config/Makefile.in:
Cleanup makefile variables to use Configure data.
 20:24
20:25 desertm4x joined, ash_ joined, kurahaupo joined
Coke jonathan: silver lining1 20:29
dalek rrot: r42124 | bacek++ | branches/context_unify/src/call/pcc.c:
Don't create new ret_continuation in invoke_from_sigobject
 20:31
rrot: r42125 | bacek++ | branches/context_unify/src/pmc/continuation.pmc:
Update passing params in Continuation
 20:34
chromatic makes the function pointers in the vtable struct const, just for laughs. 20:38
Ah, memcpy() -- I love your type unsafe evil. 20:39
dalek rrot: r42126 | chromatic++ | trunk/src/pmc/multisub.pmc:
[PMC] Removed get_iter() vtable entry from MultiSub, as it may be possible to

to the SUPER implementation instead.		 20:41
jonathan eww 20:42
attempt to access code outside of current code segment
:-/
cotto_work That's just a segfault wearing a nice hat. 20:43
jonathan Aye
20:46 baest joined
dalek p-rx: d38591b | pmichaud++ | (2 files):
[nqp]: Complete subroutine declarations (positionals only),
 20:46
Coke jonathan: I was seeing that on my segfault every so often. 20:47
trac.parrot.org/parrot/ticket/1131
(the original big tcl file was occasionally saying that, as I recall. after I trimmed it down, it started segfaulting consistently.) 20:48
jonathan Hmm 20:50
Coke: My guess in your case may be that one of the two PMCs that you pass in there is somehow invalid. 20:51
(e.g. the two involved in the assign op)
20:51 mokurai joined
Coke jonathan: worked immediately before the pcc mergeback. 20:51
jonathan That's what seems to often be the case when there's a segv in an op body.
Coke and if I print out $P1, $P0, ISTR they were ok. I could be mistaken, though.
jonathan Coke: Aye, what I'm thinking is that somehow, one of those parametrs is somehow damaged...I may be wrong, it's just what I often discover in backtraces that look this way. 20:52
Coke jonathan: given that the 'sort' there is PIR callling C calling PIR throwing an exception, my money is on PCC. =-)
(would explain why it fails just after the sort.)
jonathan *nod*
I'm doing similar evil.
Coke jonathan: I'll see if I can generate a PIR only version of that this evening. 20:54
chromatic: converting partcl over to the new pct-like thing might help in generating easy-to-test PIR for you.
s/you/parrot/ 20:55
chromatic That would be nice. 20:56
20:57 payload joined
bacek purl: ( 4637738821 - 3981486428) / 4637738821 * 100 20:59
purl 14.1502662898662
cotto_work Where 21:00
's that win coming from?
bacek GC pressure
purl i guess GC pressure is the biggest problem right now.
bacek botsnack
purl thanks bacek :)
cotto_work Does the branch allow more PMC reuse or create fewer PMCs? 21:01
chromatic It should create about 25% fewer.
bacek create fewer PMC.
sjn bacek: looks like swedish phone numbers are 14.15% better than italian ones.
21:02 hercynium joined
jonathan sjn: That's because Sweden has a lovely telephone system. ;-) 21:02
sjn jonathan: yeah, they're much cooler too (mostly because of the cold weather though) 21:03
jonathan Mmmm...cold weather. :-) 21:04
21:04 kid51 joined
sjn +5 C in Oslo clears the mind :-) 21:04
jonathan Did anything much change during pcc_reapply to do with a Sub's invoke vtable, or return continuation invocation? 21:08
Notably, anything that might have broken an inovke of a sub followed by an invoke of the return continuation installed in the created context without necesarily entering the runloop inbetween?
21:17 Whiteknight joined 21:26 joeri left
chromatic You might need Parrot_cs_switch_to_seg or whatever that is. 21:27
darbelo Whiteknight: ping
21:29 mikehh joined
Whiteknight darbelo: pong 21:29
darbelo Looking at nummatrix2d.pmc now. 21:30
21:31 bluescreen joined
darbelo Are you sure it needs PObj_custom_destroy ? 21:31
I don't see a destroy() VTABLE there.
Also, if it's using auto_attrs, you shouldn't allocate them in init() 21:32
desertm4x That's probably my fault, I basically copied these things from another PMC I've written (that did not use auto_attrs). 21:33
darbelo Also, I think they are pre-zeroed. But I'm not sure on that point. 21:34
jonathan chromatic: Ah...worth checking. I thought VTABLE_invoke always did that, but will verify. 21:35
darbelo The other thing is about resize_matrix
jonathan chromatic: It looks also though like I was not saving some state when doing nested calls, and it was thus getting trampled.
darbelo Why are we doing a double loop instead of straight memcpy()? 21:36
chromatic VTABLE_invoke() should do that, yes.
darbelo And we should probably consider making that function deal with raw storage, instead of PMCs. 21:39
21:41 joeri joined
desertm4x darbelo: In my opinion, memcpy would be the better option (but maybe Whiteknight didn't do this for a reason). But why should resize_matrix deal with raw storage? 21:42
bacek chromatic: ping 21:44
Whiteknight darbelo: we can't do a memcpy because of the way memory is laid out
rows are allocated end-to-end
so if we increase the length of the rows, we have to loop anyway
dalek p-rx: 64e2c87 | pmichaud++ | (3 files):
[nqp]: Add infix:<||>, infix:<&&>, and infix:<//>.
p-rx: ccd1d5b | pmichaud++ | (3 files):
[nqp]: More operators and tests.
Whiteknight keep in mind that arrays should be preallocated for best performance 21:45
darbelo Sorry, I meant memcpy() the rows. Go down to 1 loop.
bacek chromatic: I hit major roadblock. It's not quite clear who should create new context... 21:47
chromatic: Sub.invoke, build_sigobject, someone else? 21:48
darbelo We start with a pointer to the beggining of each buffer, we memcpy() the data, and increment each pointer by the size of a row.
chromatic My first guess is Sub.invoke.
jonathan I don't think Sub.invoke can. 21:49
Since multi-dispatchers need the call signature before they pick what to invoke.
moritz cotto_work: I have a large TODO list for the irclog search, and I plan to re-do it completely, based on KinoSearch
cotto_work: but it's unlikely that I'll get to it this year
jonathan I'm guessing that we'd create it wherever we create the CallSignature now, and invoke just fills in the missing bits. 21:50
chromatic Good point.
bacek chromatic: it was mine too...
cotto_work moritz, ok. It's usable as-is but I'm glad you plan on making it better. 21:53
nopaste "chromatic" at 72.87.39.97 pasted "Make vtable function pointers const (segfaults, but an interesting idea)" (102 lines) at nopaste.snit.ch/18463 21:56
21:58 joeri left 22:07 integral joined
nopaste "darbelo" at 200.49.154.173 pasted "Whiteknight: memcpy() the rows" (26 lines) at nopaste.snit.ch/18464 22:11
NotFound chromatic: don't lie to the compiler. They aren't const. 22:13
chromatic Everywhere except the initialization they are. 22:14
NotFound Enough to fool the compiler. 22:15
jonathan chromatic: Interestingly, Rakudo's benchmarks (the tools/benchmark.pl one) don't seem to lose too much.
darbelo desertm4x: nopaste.snit.ch/18464
jonathan chromatic: That is, after switching to trunk.
chromatic: There's a loss, sure, but on the other hand I didn't switch to just taking the :call_sig yet (one step at a time...) 22:16
chromatic ~10%?
darbelo Unless I have x and y crossed in my head. Which has happened before.
jonathan chromatic: About that, no more than 15%.
desertm4x darbelo: In my opinion this should work (better than the current solution). 22:17
jonathan chromatic: Unfortunately, right now somehow 1 + 1 doesn't even work, so we don't do very well on the sanity tests. ;-)
desertm4x I'm just checking whether you crossed x and y. ;-)
chromatic NotFound, can you think of a place where we modify the function pointers in a vtable besides PMC class init? I can't.
darbelo I also think we should do shrinking on both dimesions a no-op. 22:18
NotFound chromatic: update_vtable functions use asiignment, so they can't be const. 22:24
dalek p-rx: 190f5e9 | pmichaud++ | (3 files):
[nqp]: Add while/until/repeat_while/repeat_until .
 22:25
p-rx: 01986c7 | pmichaud++ | t/nqp/14-while.t:
[nqp]: Add tests for "repeat [while|until] <xblock>" form.
rrot-linear-algebra: a92780f | darbelo++ | dynext/IGNORE:
Remove IGNORE file.
 22:26
rrot-linear-algebra: b4d7970 | darbelo++ | dynext/.gitignore:
Add empty .gitignore file in dynext/ to keep the dir alive.
rrot-linear-algebra: fdade98 | darbelo++ | src/pmc/nummatrix2d.pmc:
Remove ATTR allocation and initialization, auto_attrs should handle that for us.
chromatic NotFound, those all get called from class_init.
dalek rrot-linear-algebra: 22d7dfd | darbelo++ | src/pmc/nummatrix2d.pmc:
Make non-METHOD, non-VTABLE function static.
allison jonathan: yes, Parrot_ext_call uses the -> form of signatures 22:27
jonathan: everything is moving to that form, the old form can be considered deprecated
NotFound chromatic: yes, and you may need a nightmare of casts and/or copying to make that work. 22:28
22:29 Whiteknight joined
chromatic I'd like to see 1) what that nightmare of casts/copying looks like (in generated code) and 2) if const function pointers in the vtable helps C compilers optimize out repeated subexpression fetches. 22:29
Whiteknight EUBUNTUCRASHED 22:30
darbelo Whiteknight: nopaste.snit.ch/18464
NotFound chromatic: mmmm... maybe a few casts in the VTABLE macros can do the desired work easily. 22:31
chromatic I never thought of that. I like the idea. 22:32
22:32 kid51 joined
Whiteknight darbelo: I would be surprised if that actually helped performance at all 22:34
plus, like I said, resizes should be uncommon. 22:35
kj hi #parrot
cotto_work hi kj
Whiteknight hello kj
NotFound chromatic: What type of repeated subexpressions are you thinking about? 22:36
kj well, found some interesting things happening. Some bugs in PIRC have been fixed.. without fixing PIRC! However, new issues have automatically introduced themselves.
jonathan allison: OK, I've done the switch now. 22:37
chromatic Repeated pointer dereferencing and its consequences for branch prediction, grabbing a vtable pointer out of a PMC in a tight loop.
darbelo kj: You were probably experiencing parrot bugs that got fixed^W replaced with other bugs.
kj darbelo: Yes. You think it would help to just wait for the others to be fixed automatically? :-) 22:38
s/others/new ones/
NotFound chromatic: Using the same pmc during the loop? 22:39
chromatic yes
22:39 particle joined
NotFound The problem I see is that PMC are never const, so the compiler can't assume that pmc->vtable doesn't chenge 22:40
darbelo kj: It eventually comes down to what new bugs the fixes introduce.
If you do it yourself you get to pick the bugs introduced. ;)
kj darbelo: Yes. well this is scary. PIRC-generated bytecode runs fine on Windows, but on MacOS it's faulty
darbelo parsed that as "MacOS: it's faulty" 22:41
darbelo agrees.
NotFound Maybe a pbc_diff program will be useful.
chromatic Hm, maybe we need to mark certain PMCs as const then. 22:42
moritz kj: the server on which you had access for testing has been replaced by a new one... do you need access to a linux box again?
chromatic I mean, in parameter signatures or stack variables.
kj moritz: yes that would be handy
moritz: haven't used it in ages, since i havent worked on it for ages..
NotFound chromatic: we almost never can because vtable functions take pointer to non-const.
Some time ago we talked about what vtable functions can take const pmc, and te answer was none. 22:44
dalek tracwiki: v3 | jkeenan++ | ArchivedNewsEvents
tracwiki: trac.parrot.org/parrot/wiki/Archiv...ction=diff
tracwiki: v112 | jkeenan++ | WikiStart
tracwiki: Moved some completed 'news and events' to archived news events
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
chromatic The third thing I do when I get a time machine is to go back in time and replace C as the systems programming language with, say, ML.
dalek rrot: r42127 | allison++ | trunk/docs/embed.pod:
[cage] Delete deprecated and deleted functions from the extend/embed API.
NotFound chromatic: Maybe we must rewrite parrot in Forth ;) 22:46
Whiteknight chromatic: you thin ML would be superior to C for that purpose?
chromatic From this angle of my particular frustration with C today, yes. 22:47
darbelo chromatic: third? What are the frist two?
s/frist/first/
chromatic One is a business plan. The second is a personal goal.
darbelo Ah.
allison How about a new C-level language? 22:48
NotFound PL/I ?
purl PL/I is a stinking abomination. or FAQ at www.faqs.org/faqs/computer-lang/pli-faq/
dalek rrot: r42128 | allison++ | trunk/lib/Parrot/Pmc2c/Object.pm:
[cage] Remove an unused code path that hasn't worked in several years.
allison project goal "to develop a compelling replacement for C"
kid51 kj ping
kj kid51: hi
allison (al la svn)
NotFound That can be the personal goal part.
Whiteknight C is very good for particular uses. The important part is knowing what the boundaries of those uses are 22:49
kid51 kj: are you kjs (as in TT #1146)?
NotFound And business plan for it, thee birds in a shot.
kj i am kjs yes
and also the one in 1146 for that matter
jonathan Eww!
The way do_run_ops decides whether to invoke or not is, erm, ouch.
darbelo allison: There's about a dozen of those. Some of them are even used by their authors :)
kid51 So, it's been so long that we had any work done in pirc, I don't know how to get to this command: $ ./pirc -b -x inv.pir
NotFound Whiteknight: for example, to write a Winxed compiler C++ is better ;)
kid51 How do I get a pirc executable? 22:50
allison darbelo: then they clearly aren't "compelling"
kj kid51: cd compilers/pirc && make
Whiteknight NotFound: C is portable assembly (though it could be better in that regard). It's good for low-level stuff
kj kid51: I had some problems building on windows I think
jonathan allison: Is there a way a dynpmc can flag itself as having an invoke method that leads to us wanting to run bytecode, besides inheriting from Sub?
kid51 which make target
Whiteknight jonathan++ fixed some windows issues today
kj and on Cygwin the build is broken for some reason, haven't looked into that
kid51 Do you mean: cd compilers/pirc && make 22:51
jonathan allison: My problem is that P6Invocation doesn't.
kj kid51: make target, are you assuming there it's in the main Makefile? It's not.
NotFound Whiteknight: That's the beauty of C++:: you can do the low level stuff parts without switching language.
jonathan allison: And I kinda really don't need it to (and worry about will happen if I make it do so).
kj kid51: yes, you have to manually build it in the compilers/pirc directory
allison jonathan: not sure I understand the question
chromatic I wish I could believe that C++ was finally cross-platform compatible.
kj eh, manually build=manually invoke make there. it's not compiled as part of parrot build process
Whiteknight NotFound: C++ isn't much higher-level then C is.
NotFound Whiteknight: but you don't need to be low-level in all parts of the code. 22:52
allison jonathan: any object with an invoke vtable function should be polymorphically substitutable for Sub
jonathan: if it isn't, I'd call it a bug
jonathan allison: See do_run_ops in src/call/pcc.c 22:53
allison: It would appear it is a bug. ;-)
Whiteknight allison: we still have a little ways to go before they're all perfectly polymorphically
allison jonathan: yup, bug 22:54
jonathan allison: OK, glad you agree. :-)
allison jonathan: (hardcoding class names for feature selection = bad)
jonathan Sure. At the very least it should be a "provides".
allison aye
kj kid51: sorry for confusion. added a note on how to get a pirc executable in the ticket.
pmichaud_ chromatic: patch for t/op/fetch.t at nopaste.snit.ch/18465 if you get a chance :) 22:55
jonathan allison: I'm not quite sure exactly what a fix would look like.
pmichaud_ (and I'm at a point where having fetch could be very useful to me). 22:56
(but can continue to live w/o it)
jonathan I guess we could try comparing the_pmc->vtable->invoke with the one of the default PMC but that feels not quite right -ish.
(e.g. what if it had the readonly vtable swapped in...) 22:57
allison jonathan: I'd add another check after VTABLE_isa
NotFound jonathan: looks like the bug is the control flow inside that sub.
allison jonathan: for VTABLE_does 22:58
NotFound Mmm... no, is ugly but correct.
jonathan allison: What would we be checking for?
allison jonathan: but would have to move the check for enum_class_core_max after the isa and does checks
darbelo has just stumbled across doc.cat-v.org/plan_9/4th_edition/pa.../acidpaper
allison jonathan: make it up
jonathan NotFound: lol...you mean the max_class_core... :-) 22:59
allison: invokable? ;-)
allison jonathan: sounds good
jonathan allison: No no, letting me name things is always a bad idea. :-)
oh wow :-)
NotFound allison: Replacing VTABLE_isa with VTABLE_does will be enough?
allison could be does invoke
jonathan allison: It turns out making P6Invocation like about being a Sub works too, but that's...bad. 23:00
allison NotFound: not at the moment, since Sub isn't marked with this magical does property
jonathan By the way, with that, we now pass all of the Rakudo sanity tests on top of latest Parrot trunk.
allison jonathan: yes, pretending inheritance is just nasty
jonathan allison: Aye, but at least now I know something like this will be a good ifx. 23:01
*fix
Will add the does check.
kj kid51: any luck with that, or weren't you looking into that? 23:02
NotFound The enum_class_core_max can be placed before the enum_class checks, and do some checks in the if branch and other in a else part.
jonathan After that, it'll be time to see how epicly Rakudo fails its spectests.
NotFound Let me do a few tests... 23:03
Whiteknight there are a surprisingly large number of Parrot_PCCINVOKE() calls in the codebase still 23:04
allison Whiteknight: we didn't do the search and replace on that in the branch
Whiteknight allison: should we? 23:05
allison Whiteknight: it just needs a direct replacement with Parrot_pcc_invoke_method_from_c_args, which is identical
(really, identical, they're cut-and-paste the same code)
nopaste "kid51" at 68.237.19.30 pasted "pirc: make test on Darwin/PPC (got similar on Linux/i386)" (45 lines) at nopaste.snit.ch/18466 23:06
Whiteknight yes. Parrot_PCCINVOKE was externally-facing, right? So I can't just chop it entirely?
allison Parrot_PCCINVOKE isn't part of the public API, so could be removed without a deprecation cycle
(though, it's a bit of an edge case)
jonathan allison: The role check works nicely. 23:07
allison Whiteknight: it at least falls under deprecation item TT #443
darbelo Whiteknight: Chop! Chop! Chop!
allison jonathan: excellent
nopaste "NotFound" at 213.96.228.50 pasted "patch for call/ppc Sub check" (30 lines) at nopaste.snit.ch/18467
NotFound jonathan: That can work? 23:08
allison NotFound: not "Sub" on the does check
NotFound: something like "Invokable"
jonathan NotFound: should be
|| VTABLE_does(interp, sub_obj, CONST_STRING(interp, "Sub"));
oh fail
|| VTABLE_does(interp, sub_obj, CONST_STRING(interp, "invokable"));
NotFound Ah, yes. 23:09
jonathan NotFound: You going to commit this soon (e.g. after a make test run)? 23:10
NotFound jonathan: I'd like to have some way to test it first.
allison NotFound: will CONST_STRING work across lines like that? 23:11
NotFound: IIRC, it has a silly bug that won't allow it on split lines 23:12
(bug, feature, whatever)
jonathan Wow, while runtime benchmarks for Rakudo are not bad, the spectests feel way slower. :-(
I'm guessing parsing related things.
NotFound allison: I fail to understand under what circunstances CONST_STRING think there are multiple lines implied.
jonathan allison: I think it's only triggered when it's more like CONST_STRING(interp, <newline> "monkey") 23:13
allison NotFound: in my experience, it's anytime the CONST_STRING isn't on the same line as the start of that code
Whiteknight what needs to happen to fix CONST_STRING to dtrt?
23:13 plobsing joined
NotFound I'll write a static inline function with written in a cleaner way and let the compiler optimize it, then. 23:14
allison we have a special exception in the coding standards tests not to flag the line length of anything with CONST_STRING in it
chromatic Whiteknight, we have to fix all stupid C compilers everywhere.
Did I mention the words "ML" and "time machine" yet?
allison replace C!
Whiteknight chromatic: why does it have to do with C compilers at all? Isn't it a perl5-based translator? 23:15
allison Whiteknight: but it's translated *to* C
Whiteknight: specifically, it's translated to this bizarre macro system based on line number 23:16
Whiteknight allison: right. So why can't we have perl5 generate better code?
chromatic C preprocessors don't handle #line reliably.
allison Whiteknight: because it's generating C code 23:17
Whiteknight allison: we can generate anything we want. we can generate better C code
allison Whiteknight: we could use a completely different way of preprocessing the CONST_STRINGs... but probably not in Perl 5
Whiteknight we don't need to use #line directives
dalek p-rx: d9b2cc4 | pmichaud++ | (3 files):
[nqp]: Add 'for' statement and tests.
 23:18
Whiteknight one situation I'm thinking of is to store the literal string constants in a separate file as a series of uniquely-named globals, and replace CONST_STRING in the code with a pointer to that string constant
preserves line numbering for debugging
allison Whiteknight: before we run too far down that path, we should take a look at internationalization 23:19
Whiteknight if we stored string constants by hash, we could reuse identical strings and save space
allison Whiteknight: which will have to do something very similar
Whiteknight exactly.
allison (with substitutions for different languages)
nopaste "NotFound" at 213.96.228.50 pasted "patch for call/ppc Sub check - second edition" (47 lines) at nopaste.snit.ch/18468 23:20
plobsing TT1147 - fix NCI for pcc_reapply. Any takers? 23:21
allison NotFound: should one of the VTABLE_isa checks in is_invokable be VTABLE_does?
NotFound Uh, today I'm not very clear %- 23:22
allison plobsing: think you could split that patch out a bit?
plobsing sure, I'll try. 23:23
nopaste "NotFound" at 213.96.228.50 pasted "patch for call/ppc Sub check - service pack" (47 lines) at nopaste.snit.ch/18469
23:23 mikehh joined
allison plobsing: particularly, some parts can be applied before 2.0, others have to wait until after 23:23
plobsing what parts have to wait? 23:24
dalek rrot: r42129 | whiteknight++ | trunk (15 files):
[pcc] rename all instances of Parrot_PCCINVOKE to the more modern Parrot_pcc_invoke_method_from_c_args
allison plobsing: and changes to nativecall.pl should be separate from changes to the PMC 23:25
NotFound Passes all test. 23:26
nopaste "jonathan" at 89.173.82.225 pasted "NotFound - here is the patch I wrote, fwiw" (14 lines) at nopaste.snit.ch/18470 23:27
jonathan NotFound: ^
NotFound: If it's going to be functionally equivalent to that, should be just fine. ;-)
NotFound jonathan: Do you have some idea on how to write a quick test?
jonathan NotFound: Off hand, not too easily.
dalek rrot: r42130 | whiteknight++ | trunk/src/call/pcc.c:
[pcc] add a deprecation note to the POD of Parrot_PCCINVOKE. Future reference: Don't use this function! You have been warned
 23:28
jonathan NotFound: I ran into it because of a dynpmc that I use.
That an overloaded find_method hands back.
plobsing allison: OK. I don't see what parts need to wait for 2.0 though. I don't think I've removed or modified a public facing interface.
jonathan So it's a fairly...convoluted...example.
;-)
NotFound jonathan: I can commit it right now and we can create a todo ticket for the test, then.
Whiteknight speaking of dynpmcs: Does anybody here know how to go about installing one?
jonathan Whiteknight: Rakudo's make install target surely does.
darbelo Whiteknight: I do. 23:29
Whiteknight darbelo: parrot-linear-algebra needs a make install target
darbelo Whiteknight: look at the decnum-dynpmcs cfg/makefile.in
Whiteknight okay, I can do tha
darbelo Whiteknight: It's ok, I'm on it.
allison plobsing: it looked like you changed the signature strings for NCI
darbelo Just give me a sec to finish off something else. 23:30
plobsing no, I changed the parsing of them to generate the new pcc strings
apparently the diff wasn't smart enough
Whiteknight darbelo: I don't see an install target anywhere in decnum-dynpmcs 23:31
allison plobsing: dropped some METHODs from the object
darbelo Whiteknight: cfg/Makefile.in line 172 23:32
It's been there since ages immemorial.
Whiteknight oh, I was looking in the wrong Makefile.in
allison plobsing: aye, it can get confused with large diffs
NotFound allison: Is fine to commit that change now and create a todo ticket for a test?
allison NotFound: yes, good fix
NotFound: sounds like a candidate for a new dynpmc 23:33
Whiteknight darbelo: got it! Working on it now
plobsing oops sorry, I guess I dropped set_raw_nci_ptr.
allison NotFound: testinvokable.pmc, or something like that
plobsing fixing
NotFound I'm not sure about what are the immediate intended usages, better if someone that knows writes the ticket. 23:34
23:38 Whiteknight joined, patspam joined
Whiteknight EUBUNTUCRASHEDAGAIN 23:38
cotto_work Whiteknight, are you playing with the 9.10 beta? 23:39
darbelo I think that ubuntu has been the greatest incentive ever to keep me on OpenBSD.
23:40 nbrown joined
Whiteknight cotto_work: maybeee.... 23:40
I loved 9.04. Absolutely loved it
and 9.10 will be awesome too when they work these bugs out
(which is why I like to be on the forefront of testing)
cotto_work From what I've read, I'm not going to bother upgrading until I'm convinced it's significantly less buggy.
Apart from a few apps, I didn't care for the hassle of upgrading last time I bothered. 23:41
jonathan doesn't do OS upgrades often. 23:42
Too lazy, and don't enjoy it.
Whiteknight they're switching to a new power manager. and there are obviously some kinks to work out with that 23:44
dalek rrot: r42131 | NotFound++ | trunk/src/call/pcc.c:
[pcc] allow Parrot_pcc_invoke_from_sig_object to take a PMC that isa Sub or does invokable
Whiteknight my laptop has been running noticably warmer since the upgrade, for instance
cotto_work I'm really unimpressed by the inability to restart dbus without screwing stuff up. 23:47
nopaste "darbelo" at 200.49.154.173 pasted "Install target for Whiteknight" (14 lines) at nopaste.snit.ch/18471 23:52
Whiteknight darbelo: just committed it 23:53
thanks though!
darbelo Whiteknight: Have you pushed it? 23:54
Whiteknight ....did now 23:56
allison save an endangered parrot? www.saveyourlogo.org/en
23:58 Essobi joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!