Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-26

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 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.
00:05 Coke (but yah, it's not exactly an alias at this point.)
00:09 pmichaud_ oh, wait, "make install" does "install-bin install-dev"?
00:09 pmichaud_ that's a problem.
00:09 pmichaud_ fixing.
00:09 dalek parrot: r42095 | pmichaud++ | trunk/config/gen/makefiles/root.in:
00:09 dalek parrot: [install]:  Restore install-dev target to also do 'make install' actions.
00:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42095/
00:10 pmichaud_ also, I should note that "make help" says:
00:10 pmichaud_ install-dev:       Same as 'install' but also install support for development.
00:10 pmichaud_ (which it will do again in a moment)
00:10 * jonathan -> sleep, see y'all tomorrow.
00:12 dalek parrot: r42096 | pmichaud++ | trunk/config/gen/makefiles/root.in:
00:12 dalek parrot: [install]:  Oops, previous patch resulted in a circular dependency.
00:12 dalek parrot: Now 'make install' does the equivalent of 'make install-dev', and
00:12 dalek parrot: 'make install-dev' depends on 'install-bin'.
00:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42096/
00:15 japhb pmichaud_, there should be a target that does *only* the non-bin stuff.
00:15 japhb 'install-devel'?
00:15 pmichaud_ ...why?
00:15 japhb For packagers.
00:15 pmichaud_ okay, install-devel then
00:16 pmichaud_ part of me wants "install-devlibs" instead
00:16 pmichaud_ wait
00:16 pmichaud_ that doesn't make any sense
00:16 japhb ... with a comment explaining why 'install-dev' and 'install-devlibs' both exist.
00:16 pmichaud_ what were packagers using before now...?
00:16 japhb pmichaud_, they were guessing.
00:16 ttbot Parrot trunk/ r42095 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/123645.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
00:16 pmichaud_ where "guessing" means...?
00:17 Austin how about "make for-packagers"
00:17 pmichaud_ Austin: packagers have two targets they want to make
00:17 pmichaud_ Austin: they want to be able to get a runtime
00:17 japhb probably reading the install-dev script, figuring out what it does, and figuring out the list of files it would install
00:18 pmichaud_ on ubuntu at least, the standard package name is "*-devel"
00:18 pmichaud_ are there any packaging systems that use "*-dev"?
00:18 pmichaud_ what's the typical RPM name ?
00:18 Austin Ad placement fail:   http://failblog.org/2009/1​0/23/ad-placement-fail-4/
00:19 japhb pmichaud_, core debian uses -dev
00:19 whiteknight PL/Parrot?
00:19 purl PL/Parrot is probably a really cool project irc://irc.freenode.net/plparrot
00:19 japhb Fedora/Redhat use -devel
00:19 pmichaud_ so I think it should be -devel then
00:19 japhb I'm fine with that
00:20 pmichaud_ oh wait, ubuntu uses -dev
00:20 pmichaud_ grrrr
00:20 Austin What's the other target name?
00:20 pmichaud_ what we had previously (before this weekend)
00:20 pmichaud_ 'make install' -- install parrot runtime environment
00:20 pmichaud_ 'make install-dev'  -- same as 'make install', plus all files needed for development
00:21 Austin Why does a packager want that?
00:21 pmichaud_ they don't
00:21 pmichaud_ but developers do (more)
00:21 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.)
00:21 pmichaud_ typically if I do  "apt-get install foo-dev", I expect to get 'foo' plus its development environment
00:21 pmichaud_ I vote for "install-dev-only"
00:21 japhb pmichaud_, fine with that
00:21 pmichaud_ which *only* installs the development files
00:22 japhb yup
00:22 pmichaud_ and perhaps install-bin should be install-bin-only
00:22 pmichaud_ but I'll let someone else make that decision/change
00:22 japhb fine with that too.
00:23 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)
00:23 ttbot Parrot trunk/ r42096 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/123678.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
00:23 pmichaud_ actually, I'm going to do
00:23 pmichaud_ install-dev -> install
00:23 pmichaud_ install -> (install-bin + install-dev-only)
00:24 japhb check it in.  ;-)
00:24 pmichaud_ testing now.
00:28 pmichaud_ tested, committed.
00:29 dalek parrot: r42097 | pmichaud++ | trunk/config/gen/makefiles/root.in:
00:29 dalek parrot: [install]:  Per further discussion on irc, add a new 'make install-dev-only'
00:29 dalek parrot: target for packagers.  The 'make install' target now depends on 'install-bin'
00:29 dalek parrot: and 'install-dev-only', and 'make install-dev' is just an alias for
00:29 dalek parrot: 'make install'.
00:29 purl 'make install' is just plain all over the place for non-module things..like  templates, etc
00:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42097/
00:31 japhb purl, forget 'make install'
00:31 purl japhb: I forgot 'make install'
00:31 japhb I spend more time telling purl to forget stuff than any other interaction, I think.
00:32 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.
00:32 pmichaud_ s/parrot/purl/
00:34 Liza How do you feel about she spouts them off when not explicitly asked for them?
00:35 * pmichaud_ whips out his bazooka ... "THIS IS HOW I FEEL ABOUT IT.  MUWAHAHAHAHAH"
00:36 pmichaud_ wow.... latest parrot is _much_ faster (for nqp-rx) than 1.7.0
00:36 pmichaud_ (parrot-devs)++
00:36 bacek_at_work pmichaud_, about 40% faster. Still slower than 1.4...
00:37 pmichaud_ yes, 40% is about what I'm seeing
00:37 Coke no, 'make install' is <reply>
00:38 Coke (then she can't relearn it.
00:38 ttbot Parrot trunk/ r42097 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/123728.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
00:39 pmichaud_ oh, wait
00:39 pmichaud_ I might be testing the wrong version of nqp-rx
00:40 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
00:40 Austin Is that from reloading pbc, or re-defining the class, or what?
00:40 pmichaud_ probably from one of those two items, yes.
00:41 Austin :(
00:41 Austin Neither have I.
00:41 pmichaud_ I've seen the "already exists" message before, yes.
00:41 pmichaud_ it often occurs when attempting to redefine a class
00:41 pmichaud_ or when something gets run/loaded more than once
00:41 pmichaud_ especially things like :init :load subs that appear at the top of a .pir file and there is no :main
00:43 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
00:43 pmichaud_ e.g., when loaded via  load_bytecode
00:44 Austin I'm working on that.
00:44 pmichaud_ how so?
00:44 Austin krt0.pir
00:44 pmichaud_ that doesn't mean anything to me :-|
00:44 Austin It's a framework that grabs control, sets up some stuff, etc.
00:45 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.
00:45 Austin I agree.
00:45 Austin It would be nice to be able to inspect the namespaces, etc, that just came in.
00:45 whiteknight pmichaud_: what are you talking about, that you would be able to get a Sub PMC for the :main sub?
00:45 pmichaud_ whiteknight: yes
00:46 pmichaud_ so that I can execute the .pbc's mainline code somehow
00:46 pmichaud_ (but preserve the ability to load the .pbc w/o executing the mainline code)
00:46 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.
00:48 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 pmichaud_ and it looks like I'll have to do something similar for nqp-rx
00:49 pmichaud_ ideally I'd expect to get back the same sort of PMC that doing a runtime PIR compilation would give me
00:49 pmichaud_ i.e,. it's a PMC that contains the entire bytecode image that was loaded
00:49 Austin There's your answer.
00:49 Austin Don't use load_bytecode, just compile the pir.
00:49 Austin :)
00:50 pmichaud_ that's actually pretty tempting.
00:50 pmichaud_ of course, that doesn't help me out when all I have is a .pbc that I got from somewhere else.
00:51 pmichaud_ alas, looks like I was wrong about the speed improvement :-(
00:51 Austin pbc_dump --disassemble file.pbc > /tmp/newfile.pasm ?
00:51 pmichaud_ I was running a very old (and much smaller) copy of nqp-rx
00:55 whiteknight I've been trying to plan a comprehensive redo of the way subs are compiled and execued
00:55 whiteknight so all this information is good feedback
00:58 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
00:58 pmichaud_ I prefer what we have now
00:58 pmichaud_ IMCC returns an Eval PMC, which contains an array of all compiled subs
00:59 pmichaud_ invoking the Eval PMC invokes the first compiled sub
00:59 whiteknight that's basically what I'm saying
00:59 abqar joined #parrot
00:59 pmichaud_ certainly "execute all compiled subs in order" is incorrect.
00:59 whiteknight I'm simplifying
00:59 whiteknight probably too muc
00:59 pmichaud_ I'd like for load_bytecode to likewise return an Eval PMC
00:59 pmichaud_ then I can start introspecting it for things that I need
01:00 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.
01:01 pmichaud_ 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?
01:01 pmichaud_ yes.
01:02 whiteknight okay.
01:08 whiteknight okay, I think I see how this works
01:08 whiteknight If I create an Eval PMC, and pass that to Packfile_fixup_subs, it should populate it
01:08 whiteknight I wonder if that will execute :load subs though?
01:09 whiteknight 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
01:09 pmichaud_ I suspect that if I don't want them to execute immediately I'd just use 'thaw'
01:10 whiteknight okay, I think I can add this
01:11 Austin Okay, now I'm into space weirdness. I'm getting an exception from a sub that doesn't exist anymore. ?:-(
01:12 Austin How do I print out the searchpath for pir/pbc files?
01:23 whiteknight pmichaud_: patch in testing now
01:29 whiteknight ah, nevermind. PGE doesn't build now
01:29 whiteknight so I'm probably not handling :load subs correctly now
01:29 whiteknight will work on it tomorrow
01:29 whiteknight Going to bed now. Goodnight
01:31 * 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:33 s1n_mini joined #parrot
02:23 dalek nqp-rx: a669f19 | pmichaud++ | build/ (2 files):
02:23 dalek nqp-rx: Clean up Makefile a bit, bump PARROT_REVISION.
02:23 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​669f199e640a1e631249cb30ca59d14dead6c95
02:24 dalek nqp-rx: 920efd9 | pmichaud++ | src/PAST/Compiler-Regex.pir:
02:24 dalek nqp-rx: [regex]:  Add 'pastnode' type for PAST::Regex.
02:24 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/9​20efd9f5258557a73d25227a929b5f701ab8343
02:34 eternaleye joined #parrot
02:41 bacek_at_work pmichaud_, can you give some good example in nqp-rx for performance testing? I'll try to do something tonight.
03:11 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 Coke ?
03:19 pmichaud_ Coke: sounds like the ongoing mmd bugs.
03:24 eternaleye joined #parrot
03:27 eternaleye joined #parrot
03:47 janus joined #parrot
04:20 mikehh joined #parrot
04:24 mikehh joined #parrot
04:55 eternaleye joined #parrot
04:58 eternaleye joined #parrot
05:03 mikehh joined #parrot
05:06 theory joined #parrot
05:10 mberends joined #parrot
05:15 hiroyuk__ joined #parrot
05:29 dalek nqp-rx: 63139fe | pmichaud++ |  (3 files):
05:29 dalek nqp-rx: Refactor the build/bootstrap build process to avoid cross-stage conflicts.
05:30 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/6​3139fe0382466df643732425e32c1d8069bf1a9
05:30 dalek nqp-rx: 1a369e2 | pmichaud++ |  (6 files):
05:30 dalek nqp-rx: More build process cleanups.  Add :PIR{{...}} modifier for inlined PIR
05:30 dalek nqp-rx: in regexes.
05:30 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​a369e20210f189717b6f8b32fcea1cdb0df0300
05:33 kurahaupo joined #parrot
05:41 dalek nqp-rx: 4039648 | pmichaud++ | build/Makefile.in:
05:41 dalek nqp-rx: Improve "make clean" target a bit.
05:41 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/4​039648d92023552b703e832a43bb428c65e33ae
05:47 eternaleye joined #parrot
05:52 rhr joined #parrot
05:58 chromatic joined #parrot
06:00 patspam joined #parrot
06:09 JimmyZ joined #parrot
06:26 cotto joined #parrot
06:35 cotto hi
06:48 bacek_at_work cotto: looks like you've lost last "o" :)
06:59 uniejo joined #parrot
07:13 desertm4x joined #parrot
07:18 desertm4x_ joined #parrot
07:32 KatrinaTheLamia joined #parrot
07:39 iblechbot joined #parrot
07:42 fperrad joined #parrot
07:50 flh joined #parrot
07:57 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)
08:00 chromatic What problem are you trying to solve with that call?
08:01 flh I want to push a new context (like the current Sub PMC does), to call some PIR code
08:02 flh actually, it sounds like there are functions to call PIR subs from C :)
08:05 flh ok, but this will probably create a nested runloop, which was not really part of my plan
08:07 flh so I'll try to give move details: I have a subroutine, which returns another subroutine
08:07 flh when the first one returns, I want its result to be automatically invoked
08:09 flh 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:10 flh unfortunately, it seems that I actually have no way to play with contexts from a dynpmc
08:13 chromatic That sounds like a tailcall to me.
08:14 dukeleto 'ello
08:15 flh more or less: I want "first_sub(a,b)" to act as "$P0 = first_sub(a, b) ; .tailcall ($P0())"
08:16 treed wouldn't that be an infinite loop?
08:16 treed since the first thing your function does is call itself?
08:16 treed with the same parameters
08:17 treed It'd never reach the tailcall
08:17 treed (Unless I'm missing something.)
08:17 flh actually, the syntax "first_sub(a,b)" does not have the same semantics in my two statements
08:18 treed I see.
08:18 treed so the first one wasn't PIR?
08:18 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
08:18 purl Message for whiteknight stored.
08:18 flh the first one isn't PIR :) It's my-own-invoke
08:19 treed Aha.
08:19 * treed really has to go to bed.
08:19 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
08:20 desertm4x_ dukeleto: What's RTEMS, btw?
08:21 moritz RTEMS?
08:21 purl RTEMS is a real time OS
08:21 desertm4x_ oh, thanks purl, moritz. :-)
08:21 moritz (I don't know more than that either :)
08:24 JimmyZ purl: no, RTEMS is the Real-Time Operating System for Multiprocessor Systems, see http://www.rtems.com/ for more.
08:24 purl okay, JimmyZ.
08:24 JimmyZ RTEMS?
08:24 purl RTEMS is the Real-Time Operating System for Multiprocessor Systems, see http://www.rtems.com/ for more.
08:25 KatrinaTheLamia joined #parrot
08:28 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
08:29 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
08:30 dukeleto desertm4x_: a real-time embedded OS
08:30 dukeleto desertm4x_: i talked a bunch with their core devs, and they are very interested in getting parrot working on it
08:30 dukeleto which i think is pretty awesome
08:31 dukeleto 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
08:31 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.
08:31 desertm4x_ dukeleto: That sounds good, thanks for the answer.
08:32 Austin But a better question is, what on earth for?
08:33 flh it's actually part of handling natively curried subs
08:33 Austin Okay.
08:34 Austin Can you give me a simple example?
08:34 flh take: .sub 'identity' ; .param pmc x ; .return (x) ; .end
08:34 gaz joined #parrot
08:35 * 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
08:36 Austin But that's not identity, it's apply.
08:36 flh in some sense your right
08:37 flh I want my sub pmc to realise that "identity" only takes one argument
08:38 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
08:38 Austin Ah.
08:38 flh that's it
08:39 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
08:40 Austin Would that be recursive? Should 7 identity(identity, identity, identity, 42)  also work?
08:41 flh it's actually lambda-calculus: (((id id) id) id) 42
08:41 flh so yes, I expect it to work :)
08:42 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
08:42 Austin :)
08:43 flh if you have a better suggestion, I would be really happy to hear it
08:44 flh but I definitely want the syntax "identity(identity, identity, identity, 42)" to work in PIR
08:44 Austin In pir?
08:44 Austin Or in your hll?
08:44 dalek matrixy: 12424a0 | dukeleto++ | ROADMAP.pod:
08:44 dalek matrixy: Fix a pod warning in ROADMAP.pod
08:44 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/12424a0bdb1102a0eca701f9986752c23eb14819
08:44 dalek matrixy: d303187 | dukeleto++ | README.pod:
08:44 dalek matrixy: Fix warning in README.pod
08:44 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/d303187c971dc0c5acfabf1f3d11865e2cddf3f1
08:45 flh Austin, in PIR
08:46 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.
08:46 moritz urgh.
08:46 moritz dukeleto: any link which describes that?
08:47 moritz 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
08:47 dukeleto moritz: i do not know the level of detail involved
08:48 Austin flh: PIR does not support lexicals or package scope references that don't go through a lookup opcode.
08:48 Austin 7  $P0 = get_global 'identity' ;  $P0($P0, $P0, $P0, 42)
08:48 flh this one is certainly ok for me
08:49 Austin ?
08:49 moritz flh: is your goal to implement some functional language?
08:49 eternaleye_ joined #parrot
08:50 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?
08:51 moritz (don't know if "idiomatic" is the right word here...)
08:51 bacek joined #parrot
08:51 bacek o hai
08:51 flh I'm not sure there exists an easy way to figure out how to write the application
08:51 Austin What happens if the arity is > 1?
08:53 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:54 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
08:55 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:58 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
09:00 Austin Is there a common or standard args coercion rule?
09:00 Austin If I define add(a, b) and then call it as add(a, b, c), what do I get?
09:01 flh if "add(a,b)" returns a function, then "add(a,b,c)" is this function applied to c
09:01 flh if "add(a,b)" doesn't return a function, then "add(a,b,c)" gives you an error
09:02 Austin So the rule in that case would be "die 'too many args'"?
09:02 flh yes
09:03 Austin (Which is what Parrot does by default, btw.)
09:05 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.
09:05 flh is there a reason not to PARROT_EXPORT it?
09:05 moritz ask allison :-)
09:05 mikehh joined #parrot
09:06 chromatic I'm still not sure that's an approach we want to encourage, manually setting control flow like that.
09:08 flh continuations already provide the ability to do strange things with control flow
09:09 chromatic Sure, but you're talking about manipulating them at below the level of continuations.
09:10 flh but it's just a very little bit below this level :)
09:11 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:13 flh I think that's what I'm trying to do
09:13 flh 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
09:14 chromatic Not if you're dispatching from C.
09:14 flh ok, agree on that
09:15 flh there was a problem with exceptions thrown from inferior runloops, has it been resolved?
09:22 bacek chromatic: ping
09:23 chromatic pong
09:24 xenoterracide joined #parrot
09:24 bacek what about merging CallSig and Context?
09:25 chromatic Seems like the next logical step.
09:25 chromatic We should list on the wiki the behavior they both have to support (especially in terms of attributes and the vtable interface).
09:26 bacek there is not intersection between Context and CallSig currently
09:26 bacek (in VTABLEs)
09:26 bacek Apart from set|get_attr, which is resolvable
09:27 chromatic There's not much in Context at all, is there?
09:27 bacek chromatic: almost nothing
09:27 purl it has been said that almost nothing is up to date
09:28 bacek I think we merge Context into CallSig.
09:28 bacek Just add pointer for Parrot_Context
09:28 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?
09:28 bacek Parrot_Context has variable size...
09:29 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"
09:29 chromatic I'm sure we could figure out variable sizes somehow.
09:29 bacek which is union of Context and CallSig
09:30 bacek chromatic: we can. But we can't use ATTRs for it
09:30 chromatic I don't see why not.
09:31 chromatic It's only the register storage that's variable sized.
09:32 bacek chromatic: then we have to use second call to alloc registers.
09:33 chromatic True.
09:33 bacek it was main reason why I didn't migrate Context to ATTRs...
09:35 chromatic We have to do three allocs for a Context/CallSig PMC anyway: the header, the attributes, and the register storage.
09:36 bacek Right. I can trade allocation of whole Parrot_Context for allocation of registers only.
09:36 bacek let's create branch!
09:37 chromatic Bring it on.
09:37 purl That's allright, that's OK, you're gonna pump our gas some day
09:37 bacek "context_unify"?
09:37 chromatic Sure.
09:40 bacek oh shi... git decided to fetch old history... It will take some time...
09:41 dalek parrot: r42098 | bacek++ | branches/context_unify:
09:41 dalek parrot: Branch for merging CallSignature and Context
09:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42098/
09:42 bacek chromatic: CallSignature, Context of CallContext?
09:42 bacek s/of/or/
09:43 bacek or even ParrotContext
09:43 moritz CallFoo :-)
09:43 bacek CallFu :)
09:43 chromatic ParrotCall?
09:44 bacek it's not "Call" only.
09:44 bacek "Frame"? (ignoring fact of CPS)
09:45 chromatic Returns are calls in CPS.
09:45 chromatic Maybe the simplest is CallContext.
09:45 bacek deal
09:46 bacek btw, if I put fields from CallSig into Parrot_Context then we can have 2 allocations only
09:47 chromatic Exactly.
09:47 chromatic We might have to profile and move things around depending on processor cache access though.
09:49 bacek Sure
09:51 masak joined #parrot
09:57 * jonathan ain't sure how this context/call-sig merge is going to work out.
09:58 jonathan I'll handle getting Rakudo going on trunk again, but I'd appreciate patches as needed if this second branch works out/lands.
10:02 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 #parrot
10:04 chromatic jonathan, it should be reasonably transparent.
10:06 jonathan chromatic: The main thing I see is that I'd rely on being able to use the CallSignature multiple times.
10:06 jonathan And if the context and call signature are merged, that may get more interesting.
10:06 jonathan May have to start cloning it for example.
10:07 dalek parrot: r42099 | bacek++ | branches/context_unify/src (1 files):
10:07 dalek parrot: Rename Context into CallContext.
10:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42099/
10:07 dalek parrot: r42100 | bacek++ | branches/context_unify (3 files):
10:07 dalek parrot: Copy ATTRs from CallSignature into Parrot_Context structure.
10:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42100/
10:07 dalek parrot: r42101 | bacek++ | branches/context_unify/src/pmc/callcontext.pmc:
10:07 dalek parrot: Move functions from CallSignature into CallContext
10:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42101/
10:24 dalek parrot: r42102 | bacek++ | branches/context_unify/src/pmc/callcontext.pmc:
10:24 dalek parrot: Move banch of VTABLE and functions from CallSignature into CallContext.
10:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42102/
10:37 dalek parrot: r42103 | bacek++ | branches/context_unify/src/pmc/callsignature.pmc:
10:37 dalek parrot: Remove CallSignature PMC.
10:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42103/
10:37 dalek parrot: r42104 | bacek++ | branches/context_unify (3 files):
10:37 dalek parrot: Update various build_sig_object functions to use CallContext
10:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42104/
10:37 plobsing joined #parrot
10:39 bacek oookey. "It compiles" :)
10:40 bacek hmm... Not really.
10:42 zak_ joined #parrot
11:04 szabgab joined #parrot
11:06 dalek parrot: r42105 | bacek++ | branches/context_unify/con​fig/gen/makefiles/root.in:
11:06 dalek parrot: Update makefile dependencies.
11:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42105/
11:09 dalek parrot: r42106 | bacek++ | branches/context_unify (2 files):
11:09 dalek parrot: Added accessors for new Parrot_Context fields.
11:09 dalek parrot: Non-optimised version only.
11:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42106/
11:09 dalek parrot: r42107 | bacek++ | branches/context_unify/src/call/context.c:
11:09 dalek parrot: Initialise new fields in Parrot_alloc_context.
11:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42107/
11:09 dalek parrot: r42108 | bacek++ | branches/context_unify (2 files):
11:09 dalek parrot: Remove duplicated field "current_results" vs "results"
11:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42108/
11:25 moritz msg chromatic http://rt.cpan.org/Public/​Bug/Display.html?id=50794 if you haven't seen it already
11:26 purl Message for chromatic stored.
11:32 bacek joined #parrot
11:36 mikehh joined #parrot
11:43 patspam joined #parrot
12:05 dalek parrot: r42109 | bacek++ | branches/context_unify/src/call/args.c:
12:05 dalek parrot: Use CallContext accessors instead of poking into dead CallSignature attributes
12:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42109/
12:07 bluescreen joined #parrot
12:08 dalek parrot: r42110 | bacek++ | branches/context_unify (7 files):
12:08 dalek parrot: Remove current_sig from Parrot_Context. Start switching to CallContext from CallSignature
12:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42110/
12:09 * Coke yawns.
12:20 whiteknight joined #parrot
12:26 whiteknight good morrow #parrot
12:31 Coke guten morgen
12:41 whiteknight hello Coke
12:59 whiteknight how is partcl doing today?
13:10 Coke segfaulting.
13:10 purl segfaulting is probably hardly a good way to deal with bad data
13:10 Coke (https://trac.parrot.org/parrot/ticket/1131)
13:23 iblechbot joined #parrot
13:28 bluescreen joined #parrot
13:30 whiteknight well, segfaulting is lousy
13:31 whiteknight there are two assign_p_p calls in that code snippet. Which one segfaults?
13:34 mikehh joined #parrot
13:39 Coke I think it's the second one.
13:57 whiteknight okay, that's interesting
14:00 Andy joined #parrot
14:12 pmichaud_ hmmmm.... somewhere either I (or parrot) has introduced a bug somewhere that causes 'nqp-rx' to randomly fail.
14:13 jonathan :-(
14:13 jonathan pmichaud_: Random in what sense? Fail in what sense?
14:14 pmichaud_ random in the sense that sequential executions of the same script give different results
14:14 jonathan Oh, ouch.
14:14 jonathan -G ?
14:14 purl i guess -G is computed goto
14:14 jonathan purl: I GUESS IT'S NOT.
14:14 purl jonathan: excuse me?
14:14 jonathan purl: forget -G
14:14 purl jonathan: I forgot -g
14:14 pmichaud_ I'll try that, but I think last time I tried it made no difference
14:15 moritz pmichaud_: did that happen after you bump PARROT_REVISION the other day?
14:15 moritz *bumped
14:15 pmichaud_ it's only been happening over the past few days, yes
14:15 pmichaud_ but I also tried putting PARROT_REVISION back to 1.7.0 and I still get the random fails
14:15 Coke jonathan: --gc-debug might be more useful. (fail early, fail often.)
14:16 jonathan Aye, that too.
14:16 pmichaud_ somehow I don't think this is a gc bug.
14:16 pmichaud_ (just a hunch)
14:16 jonathan pmichaud_: That sounds odd. You sure it's not anything to do with timestamps stuff during the compile?
14:16 jonathan I know you fixed that kinda stuff lately though...
14:16 jonathan So I guess not.
14:17 pmichaud_ timestamps in the compile has been my suspicion too, but the weirdness doesn't seem to follow (more)
14:17 pmichaud_ for example, I'll do "make nqp-test"  and of the 9 test files, only 09-var.t will fail.
14:17 pmichaud_ 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.
14:18 pmichaud_ not only that, but the 05- through 08- fails are "immediate"
14:18 Coke pmichaud_: are you running the tests in || ?
14:18 pmichaud_ no, sequential.
14:18 Coke k.
14:18 pmichaud_ pmichaud@orange:~/nqp-rx$ ./par -G t/p6regex/01-regex.t | grep '^ok' | wc -l
14:18 pmichaud_ 603
14:18 pmichaud_ pmichaud@orange:~/nqp-rx$ ./par -G t/p6regex/01-regex.t | grep '^ok' | wc -l
14:18 pmichaud_ 591
14:19 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
14:19 pmichaud_ 545
14:20 pmichaud_ pmichaud@orange:~/nqp-rx$ ./par -G t/p6regex/01-regex.t | grep '^ok' | wc -l
14:20 pmichaud_ 603
14:20 whiteknight pmichaud_: how are they failing? unhandled exception? segfault?
14:21 pmichaud_ every once in a while, when run from the harness, it'll fail immediately with "no tests run".
14:21 pmichaud_ But I can't see what the actual output was.  If I run the harness with -v, it never fails immediately.
14:21 pmichaud_ (at least, it's never done so yet)
14:21 pmichaud_ at the moment they fail by simply returning the wrong output
14:24 pmichaud_ http://nopaste.snit.ch/18451  # sequential make test runs in nqp-rx
14:25 Coke what is "./par" ?
14:25 pmichaud_ it's a symlink to the parrot binary executable
14:25 pmichaud_ I can't call it "parrot" because there's a parrot subdir
14:26 Coke is it linking to the same parrot in the path in your nopaste?
14:26 pmichaud_ should be
14:26 pmichaud_ it's the parrot in parrot_install/bin/parrot
14:26 pmichaud_ (where parrot_install is the locally-created version of parrot for nqp)
14:26 pmichaud_ (created via --gen-parrot)
14:28 pmichaud_ and what's really kinda weird is the way in which the tests fails
14:28 pmichaud_ for example, looking at the last "make test",  the first set of failures are tests 17-26
14:29 pmichaud_ i.e., the failures often come in blocks
14:29 mikehh joined #parrot
14:29 Coke are /any/ failures expected at this point?
14:30 pmichaud_ yes
14:30 pmichaud_ oh, geezum
14:30 Coke without looking at tests 17-26, it seems more likely that they are testing something similar.
14:30 pmichaud_ nopaste coming
14:31 Coke (is it me, or is feather getting sloooower?)
14:31 pmichaud_ http://nopaste.snit.ch/18452  # sequential "make nqp-test" runs in nqp-rx
14:32 jonathan Wow, in the last run it fails 'em all?!
14:32 pmichaud_ yes
14:32 jonathan Super odd.
14:32 pmichaud_ not only that, but in this case each test runs in a separate process
14:33 pmichaud_ as opposed to the earlier "make test" case where all of the tests run in a single process
14:34 pmichaud_ http://nopaste.snit.ch/18453   # more nqp-rx oddness
14:35 pmichaud_ 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...
14:35 pmichaud_ yes, I've tried realclean, and multiple recent versions of Parrot
14:35 pmichaud_ I suppose I could try a much older version of Parrot
14:35 jonathan nod
14:35 jonathan Hmm
14:36 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?
14:37 pmichaud_ it's hard to know when I have a "good" case, though
14:37 jonathan Aye.
14:37 jonathan Hmm.
14:37 pmichaud_ let's see if I can get a failure in a simple case
14:42 whiteknight the failures look like they are all happening in comp_unit
14:43 whiteknight 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
14:43 pmichaud_ it's not the source of the error
14:43 pmichaud_ i.e., a match failed somewhere that should've passed
14:43 jonathan whiteknight: Parrot trunk currently fails to build for me on MS VC++ - known?
14:44 payload joined #parrot
14:44 jonathan nci_test.obj : error LNK2001: unresolved external symbol _PMCNULL
14:44 theory joined #parrot
14:44 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)
14:45 jonathan whiteknight: Wait, didn't you fix this issue once?
14:45 jonathan whiteknight: The nci_test.dll failing to build?
14:46 whiteknight jonathan: I did fix it at one point. the pcc_reapply merger may have undone it
14:46 jonathan Ah.
14:46 whiteknight SVN branch merges: "We suck so bad, you're going to wish we didn't suck so bad"
14:46 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 #parrot
14:51 whiteknight Added a reference to libparrot to the link line for libnci_test.dll
14:52 whiteknight i'm sure if you check the SVN log for root.in, you'll see the change in there somewhere
14:53 jonathan whiteknight: Hmm. But that appears to be in the link line. :-S
14:55 jonathan gah, the log only shows it changing in the merge...
14:57 Coke pmichaud_: I can duplicate the non-repeatable failures on feather with npq-rx latest and parrot-latest.
14:57 pmichaud_ http://nopaste.snit.ch/18454   # narrowing it down a bit!
14:58 pmichaud_ in the nopaste, 01-regex.t has been modified to run exactly one test
14:59 Coke pmichaud_: is one of the things in your toolchain generating ids based on timestamp?
14:59 pmichaud_ yes
14:59 pmichaud_ not solely on timestamp, but timestamp is a component
14:59 Coke so you're not really running the same code each time. =-)
14:59 pmichaud_ right, but the timestamp is simply used as a string
15:00 pmichaud_ oh, this is interesting.
15:00 eternaleye joined #parrot
15:01 pmichaud_ http://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.)
15:01 pmichaud_ I *always* get the segfault.
15:01 pmichaud_ at the same place.
15:01 Coke yay.
15:01 Coke what's after that getinterp?
15:02 Coke 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 #parrot
15:03 pmichaud_ $P0 = getinterp
15:03 pmichaud_ $P0 = $P0['namespace';1]
15:03 pmichaud_ so it's asking for the caller's namespace
15:06 pmichaud_ guess it's time to grab gdb on this one :)
15:06 pmichaud_ bah
15:06 pmichaud_ the segfault is in the tracer
15:06 pmichaud_ that doesn't tell me anything other than -t has a bug in it :-(
15:06 PacoLinux joined #parrot
15:08 whiteknight urg
15:08 pmichaud_ http://nopaste.snit.ch/18456   # execution and backtrace
15:09 jonathan whiteknight: Heh. I have a patch that, uh, "works".
15:09 whiteknight jonathan: stop building libnci_test?
15:09 jonathan whiteknight: Thing is, nci_test.c really is an excention, so it should define PARROT_IN_EXTENSION.
15:10 jonathan *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
15:10 whiteknight pmichaud_: good idea
15:10 purl whiteknight: Good Idea: Finding Easter eggs on Easter morning. Bad Idea: Finding Easter eggs on Christmas morning.
15:10 jonathan whiteknight: However, it doesn't, meaning that we don't end up importing PMCNULL, we try and export it instead. Then we fail.
15:10 jonathan whiteknight: However, we then get the "fun" that nci_test.c wants to mark stuff as exported.
15:10 whiteknight jonathan: that actually makes goo sense
15:11 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
15:11 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.
15:12 jonathan I wonder if I now fail tests though.
15:12 Psyche^ joined #parrot
15:13 whiteknight jonathan: parrot builds for me on win32 no problem
15:13 jonathan whiteknight: Compiler?
15:13 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.
15:13 whiteknight jonathan: strawberry
15:13 purl somebody said strawberry was a Perl for Windows that works just like Perl everywhere else. See http://win32.perl.org/wiki/in​dex.php?title=Strawberry_Perl or well where is RAWBERRY
15:13 particle i haven't been able to build parrot on windows for two weeks
15:13 jonathan Oh
15:13 jonathan That's MinGW
15:13 jonathan Not MS VC++
15:14 whiteknight oh, you're on VC++?
15:14 jonathan Yes.
15:14 whiteknight urg
15:14 jonathan I'm guessing particle is too.
15:14 particle yep, of course
15:14 whiteknight so then 1.7.0 probably went out the door not building on VC++
15:14 particle yep
15:14 jonathan Well, heh, I fail all of the nci tests.
15:14 jonathan But that beats not building
15:14 whiteknight all my testing was strawberry
15:14 jonathan So in goes the patch.
15:14 whiteknight jonathan++
15:14 particle 1.7 went out without building on msvc
15:14 jonathan And we can iterate on it.
15:14 Coke particle: what happened to our windows remote access?
15:14 whiteknight We need to kill those tests anyway, rework them into something better
15:15 Coke (is it just waiting for someone to use it?)
15:15 whiteknight we have remote access to a windows machine somewhere?
15:15 particle coke: gotta ask alias about that, i guess.  iunno if that ever happened for cpan users, either.
15:15 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.
15:15 particle alas, i haven't been in touch with microsoft for quite some time now
15:16 pmichaud_ https://trac.parrot.org/parrot/ticket/1149
15:17 dalek TT #1149 created by pmichaud++: [bug] Segfault in -t trace output
15:17 pmichaud_ (what dalek++ said)
15:18 jonathan oh wait, I can use PARROT_DYNEXT_EXPORT
15:19 jonathan Hopefully this fixes the build *and* passes the tests...
15:22 eternaleye joined #parrot
15:22 pmichaud_ http://nopaste.snit.ch/18457  # segfault and backtrace when running minimal 01-regex.t
15:22 pmichaud_ it appears the problem always occurs when attempting to take a substr
15:23 pmichaud_ sometimes it gives "Cannot substr on a null string"
15:23 pmichaud_ sometimes it works
15:23 pmichaud_ sometimes it segfaults
15:23 pmichaud_ unfortunately the backtrace doesn't give me a lot of clues about _which_ substr operation resulted in the segfault.
15:24 mikehh joined #parrot
15:25 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 parrot: r42111 | jonathan++ | trunk/src/nci_test.c:
15:26 dalek parrot: Corret usage of symbol import/export in nci_test.c. Fixes the build on MS VC++.
15:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42111/
15:26 jonathan ...and then somehow match that up with the PIR (maybe pbcdump)
15:26 jonathan But it's a long shot. :-(
15:26 pmichaud_ yes, not having -t1 here really hurts.
15:27 jonathan got a bt for -t1 segfault pasted?
15:27 pmichaud_ I can get one easily.
15:28 pmichaud_ I just added a backtrace to the ticket
15:28 pmichaud_ https://trac.parrot.org/parrot/ticket/1149
15:29 pmichaud_ although, given that both segfaults are related to producing strings, I wonder if they are, in fact, related :)
15:30 pmichaud_ 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?
15:31 jonathan Coke: I didn't know we ever were.
15:31 jonathan Coke: We aren't now though, for sure.
15:31 jonathan We link against libparrot
15:31 Coke er.
15:31 Coke ok. yah, should we be doing that, even?
15:32 Coke that is, I'd expect nci_test to depend on libparrot, but not vice versa.
15:33 jonathan That's how it is.
15:34 pmichaud_ http://nopaste.snit.ch/18458   # can someone explain frame #0 in this backtrace ?
15:40 uniejo joined #parrot
15:41 pmichaud_ in gdb, how can I display the current_sub entry of a context PMC?
15:41 pmichaud_ (I used to know how to do it when contexts weren't PMCs)
15:42 pmichaud_ nm, found it.
15:42 ruoso joined #parrot
15:42 Essobi joined #parrot
15:43 Essobi Howdy.
15:43 payload joined #parrot
15:45 Essobi I can't find any documents relevant to the state of threading in the PVM... Am I overlooking something?
15:46 pmichaud_ Essobi: I'm not aware of any current documents on threading.
15:47 moritz https://trac.parrot.org/parrot/ticket/757 describe some not-so-nice aspects of the current state
15:50 masak joined #parrot
15:51 einstein joined #parrot
15:58 Essobi http://www.parrot.org/files/Fagerholm-Parrot.pdf mentions it
15:59 moritz that's like, 4 years old
15:59 moritz is there any subsystem that wasn't revamped in the last 4 years?
16:01 masak joined #parrot
16:02 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
16:02 pmichaud_ There may be threading ops, but I don't know what they are.
16:03 Essobi Drat.
16:03 moritz pdd25_concurrency.pod should document them
16:03 moritz but I don't know how up-to-date it is
16:07 solarion joined #parrot
16:07 * solarion just got the Parrot Developer's Guide: PIR. :)
16:08 Essobi - Parrot supports multiple concurrency models, including POSIX threads, event-based programming, and asynchronous I/O. <--- YAAAAAAY
16:09 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 #parrot
16:09 pmichaud_ I'm not sure if the implementation supports all of that yet :-|
16:09 Essobi http://docs.parrot.org/parrot/devel/htm​l/docs/pdds/pdd25_concurrency.pod.html
16:10 pmichaud_ "pdd" == "Parrot Design Document",  fwiw
16:11 Essobi right right.. I get it.
16:12 pmichaud_ okay, I *think* I've narrowed down the nqp-rx problem I'm seeing, but could use some feedback
16:12 pmichaud_ 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?
16:13 pmichaud_ (I didn't realize the hash was being modified during iteration until just now)
16:13 moritz it would certainly explain a lot
16:13 pmichaud_ anyway, that seems to confuse the heck out of the Iterator, and it ultimately returns me a null string
16:13 Essobi .... there is a pmc for threads...
16:13 jonathan The Rakudo branch pccupdate on github is the initial bits on getting us using the new Parrot Calling Conventions.
16:14 pmichaud_ (not an empty string, a true string NULL pointer)
16:14 jonathan We can now compile the pmcs and ops again.
16:14 jonathan However, segfault soon arrives later on.
16:14 pmichaud_ jonathan++ !!!
16:14 pmichaud_ or it otherwise returns a garbage pointer
16:15 jonathan pmichaud_: I don't know either way, but it sounds like a good suspect.
16:15 Essobi and the concurrency scheduler..
16:15 pmichaud_ is there something that randomizes hashes somehow now?
16:15 pmichaud_ I've noticed that identical runs often produce different hash results
16:16 cotto_w0rk pmichaud_, yes
16:16 pmichaud_ that would explain why I'm getting random results, then.
16:16 jonathan Aha.
16:16 jonathan Nice explanation.
16:17 * jonathan needs to go lie down for a bit - feeling ill-ish. :-/
16:17 * moritz hopes jonathan recovers quickly
16:22 whiteknight Essobi: we have threads, and they do work, but they are not good
16:22 whiteknight we have event-based stuff with tasks and exceptions
16:23 whiteknight we don't have asynchronous IO
16:23 whiteknight Essobi: see the examples in t/pmc/threads.t, t/pmc/task.t, t/pmc/timer.t and t/pmc/scheduler.t
16:24 dalek parrot: r42112 | NotFound++ | trunk/src/runcore/trace.c:
16:24 dalek parrot: [core] fix trace keys, TT #1149
16:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42112/
16:25 whiteknight pmichaud_: bacek did a refactor a while back that randomized hash keys
16:25 whiteknight and as far as I am aware, modifying a hash while iterating it is a big no-no
16:26 pmichaud_ yes, but is "segfault" a correct response to that?  ;-)
16:26 dalek TT #1149 closed by NotFound++: [bug] Segfault in -t trace output
16:26 moritz pmichaud_: probably not :-)
16:28 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 #parrot
16:29 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
16:29 pmichaud_ how would a hash know it's under iteration, though?
16:30 whiteknight i didn't say it would be easy to do it :)
16:30 pmichaud_ the onus is on the iterator, not the hash
16:30 pmichaud_ 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.
16:30 pmichaud_ an iterator would need to detect that a hash has been modified, and then throw an exception.
16:31 whiteknight that works too
16:31 NotFound Iterator existence may mean just the GC is being lazy ;)
16:31 dalek parrot: r42113 | NotFound++ | trunk/src/runcore/trace.c:
16:31 dalek parrot: [cage] drop redundant cast from r42112
16:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42113/
16:34 cotto_work xkcd is special today
16:35 japhb cotto_work, I don't think anything should vary semantically between opt and non-opt builds.
16:35 NotFound Great! :)
16:36 cotto_work japhb, thinking about it more, I agree.
16:37 cotto_work it'd be nice to have an easy way to make hashing repeatable, though
16:38 japhb Sounds like a Configure option to me
16:39 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
16:42 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
16:42 pmichaud_ well, random hashes also makes it less likely for someone to write code that (inadvertently) depends on the ordering of the hash
16:43 cotto_work I remember finding that out when I added the randomization. ;)
16:47 mj41 MS VC++ fixed in r42111, jonathan++
16:48 pmichaud_ yay, avoiding the modification-while-iterate seems to have resolved the problem.
16:49 pmichaud_ thanks to all for suggestions and help
16:52 jonathan pmichaud++ # debugging skillz
16:52 jonathan moritz: I think I'm just a tad exhausted, that's all.
16:52 cotto_work ugh.  Flashbacks. http://www.guidebookgaller​y.org/screenshots/macos70
16:53 pmichaud_ jonathan: how was IPW, btw?
16:55 hercynium joined #parrot
16:55 jonathan pmichaud_: IPW was good. I gave a couple of talks, and demo'd a partial Lolsql -> sql convertor running in Rakudo. :-)
16:56 pmichaud_ niiiiiice
16:56 jonathan I'll pop the code somewhere when I get a chance.
16:56 jonathan 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.
16:57 jonathan 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
16:57 jonathan Ooh, nice. On PCT?
16:57 pmichaud_ Pynie and Git
16:57 jonathan Cool. :-)
16:58 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 pmichaud_ (it's amazing to see the parallels)
16:58 japhb Do tell!
16:58 jonathan Oh, interesting.
16:58 NotFound Look at the parallels in perspective, and they converge ;)
16:59 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_.
16:59 whiteknight if all these languages were running on Parrot, everybody would be having the same problems!
16:59 dalek rakudo: 22ded10 | (Carlin Bingham)++ | src/setting/IO/Socket.pm:
16:59 dalek rakudo: Change IO::Socket.recv() to accept a parameter specifying the number of bytes which will be received
16:59 purl dalek: that doesn't look right
16:59 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
16:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​2ded10cd3f8e9774ca17d5bb8e42bed7efb7938
17:00 pmichaud_ other issues in dealing with module archive infrastructure, and steering committees, and the like
17:01 japhb OOC, do you remember anything about the module archive infrastructure complaints?
17:02 pmichaud_ many of the same issues we hear about cpan :-)
17:02 pmichaud_ figuring out how to manage module dependencies, especially when modules can be installed in multiple locations on a system
17:03 pmichaud_ some people want to have a global "module registry", others are dead-set against any form of registry
17:03 japhb sigh
17:04 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
17:04 pmichaud_ moritz:  the word is "cache"
17:04 pmichaud_ we won't have a registry, we'll have cache indexes
17:04 cotto_work sneaky
17:05 whiteknight anything to avoid confusion with the horrible Windows Registry
17:05 japhb heh
17:05 cotto_work +yes
17:05 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
17:05 moritz pmichaud_: if that's only a question of terminology, there's nothing wrong with "cache"
17:05 * whiteknight still has nightmares of regedt32
17:05 japhb OK, so "make sure Plumage is easy to iterate".  Check.
17:05 pmichaud_ moritz: it's not just terminology
17:06 pmichaud_ a "registry" is something where each module adds itself as it is installed
17:06 pmichaud_ that's not what we want
17:06 pmichaud_ a "cache" is something that keeps track of what has been discovered, and adapts itself to whatever is in existence
17:07 pmichaud_ put another way, registries tend to think that there's one global, correct view of the system.  They're usually wrong.
17:07 pmichaud_ caches provide views from a particular location in the system, which could be different
17:07 pmichaud_ another way to think of it is that caches act more like lexically-scoped views, while registries tend to be global-scoped views
17:08 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
17:08 pmichaud_ the cache can introspect the module for the metadata, and keep it locally based on whatever name/locator the module has
17:09 pmichaud_ 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:10 japhb Plumage already has the concept that the project name is just a key.
17:11 japhb I guess that's one I have right-ish.
17:11 japhb One thing that's increasingly bothering me is what to do about uninstall and upgrade-where-some-files-should-disappear
17:12 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:13 japhb Yeah.
17:14 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 pmichaud_ (same goes for -I)
17:14 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.
17:15 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.
17:16 japhb 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++
17:17 japhb Coke, yeah, and that's part of why it's causing me dispepsia
17:17 japhb Mmmm, Pepsi
17:17 Coke anything with ***** in it can't be good for you.
17:17 japhb heh
17:17 pmichaud_ agreed -- that's one of the few commercial beverages I refuse to drink.
17:18 pmichaud_ "I'll have a Dr Pepper."  "We only have Pepsi."  "I'll have water."
17:19 Coke I appreciate the inadvertent solidarity.
17:20 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.
17:20 dalek nqp-rx: 09880e0 | pmichaud++ | src/NQP/ (2 files):
17:20 dalek nqp-rx: Refactor scope and variable declarators.
17:20 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/0​9880e06b3e1dfdd714bf389bdc1a80855eaae7f
17:20 dalek nqp-rx: 9f56d59 | pmichaud++ | src/Regex/Cursor-protoregex-peek.pir:
17:20 dalek nqp-rx: [regex]:  Building a tokrx hash can result in the protoregex hash
17:20 dalek nqp-rx: being modified while it's being iterated -- refactor so that
17:20 dalek nqp-rx: we get the complete list of method names from the protoregex hash
17:20 dalek nqp-rx: before we start building tokrx.
17:20 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/9​f56d592362265f8a84c8f4d1d75ec77b3f6d542
17:20 dalek nqp-rx: 18624fc | pmichaud++ | build/ (2 files):
17:20 dalek nqp-rx: Bump PARROT_REVISION to get Parrot -t fixes, and fix build sequence
17:20 dalek nqp-rx: so that we're left with a P6Regex.pbc .
17:20 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.
17:20 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​8624fcfb4ba0d6a96b4e525b10542be3a75a60a
17:20 dalek nqp-rx: 45d5132 | pmichaud++ | src/stage0/P6 (2 files):
17:20 dalek nqp-rx: Update bootstrap versions of P6Regex/P6Grammar.
17:20 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/4​5d5132e606fcbd124e0087bcf3488a8f207e1f1
17:21 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. ;)
17:21 pmichaud_ well, I meant "after the security gate"
17:21 Coke particle, allison: Are we signed up to get spammed by efax.com?
17:22 cotto_work ah
17:22 PerlJam pmichaud_: It was the same thing in Las Vegas  pepsi--
17:22 Coke karma pepsi?
17:22 purl pepsi has karma of -4
17:22 pmichaud_ pepsi--
17:22 * Coke cannot remember the last time he had a real coke.
17:22 * Coke suspects it was kosher-for-passover coke about ... 10 years ago.
17:23 japhb I'm an equal opportunity caffeinated-carmel-colored-phos​phoric-acid-containing-beverage drinker.
17:23 particle coke: pafo has an efax account
17:23 pmichaud_ is that just another way of saying you have no taste?  ;-) ;-)
17:23 japhb Mmmm, sugared coke.
17:23 Coke particle: yes. and they keep sending us spam.
17:24 japhb No, I just think of them as different drinks
17:24 Coke for example, the gotomypc ad that I'm about to discard.
17:24 japhb I like Coke in a bottle from Mexico.
17:24 * jonathan didn't actually like any fizzy drink when he was a kid.
17:24 Coke (being sent to legal@parrot.org)
17:24 Coke jonathan: HERETIC
17:24 NotFound pmichaud_: -L option was a quick addition without any design
17:24 Coke jonathan: *screamy noise from end of invasion of the body snatchers, spock version*
17:24 jonathan Coke: Nor baked beans, or eggs.
17:25 Coke jonathan: I'm not sure there's a pattern there.
17:25 pmichaud_ NotFound: hmmm.
17:25 Infinoid those don't make very good drinks, either
17:25 jonathan No.
17:25 japhb You're forgiven for not liking baked beans.  Eww.
17:25 NotFound pmichaud_: I know, I added it ;)
17:25 Coke bah. we had baked beans for special occasions.
17:25 pmichaud_ generally  -I and -L on other systems (e.g., Perl, C)  prepend the directory to the path, not append it
17:25 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.
17:25 cotto_work NotFound, maybe it should get designed before it's too late to fix it.
17:25 pmichaud_ NotFound: when did it get added?
17:25 mikehh joined #parrot
17:26 NotFound pmichaud_: maybe a year ago
17:26 * whiteknight doesn't drink Coke or pepsi. No soda at all, in fact
17:26 PerlJam japhb: you're a fan of real-sugar in your Coke?
17:26 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
17:26 PerlJam whiteknight: good, you're healthier for it
17:27 PerlJam whiteknight: plus  that leaves more for me  :)
17:27 japhb PerlJam, definitely.  And I really hate the artificial "diet" sweeteners.  I tolerate HFCS.  Sorta.
17:27 * PerlJam takes a sip of his ice cold Dr Pepper
17:27 NotFound pmichaud_: I think we can change it without breaking anything, but better ask in #ps
17:27 pmichaud_ I'll put it in my queue.  Or I can send a message to parrot-dev
17:27 PerlJam japhb: I do not drink diet anything.  They taste odd enough that I can't stand it.
17:28 japhb Ditto
17:28 pmichaud_ I have reactions to Nutrasweet, Splenda, and the others
17:28 pmichaud_ so "diet soda" is also out for me :)
17:28 japhb Sodium Saccharin for the cancer causing win!
17:31 PerlJam The wind just picked up here quite a bit and now it's raining big fat rain drops
17:31 PerlJam big, fat, high velocity rain drops
17:33 japhb PerlJam, a la "A Bug's Life"?
17:35 PerlJam worse IMHO, but yeah.
17:35 payload joined #parrot
17:36 pmichaud_ we've gotten a huge amount of rain here this year
17:36 Coke pmichaud_: no Tab, even? =-)
17:36 japhb We're getting it all as flash floods this fall.
17:37 japhb ... 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)
17:37 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"
17:38 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 pmichaud_ and, of course, every other soccer league in the area is trying to do the same thing.
17:39 japhb ouch # to both
17:40 cotto_work whiteknight, nice mixed metaphor in your blog post
17:41 payload1 joined #parrot
17:41 cotto_work also, nice alliteration
17:42 whiteknight cotto_work: Thanks! I'm sure I put some conscious effort into either of those things :)
17:43 darbelo joined #parrot
18:03 payload joined #parrot
18:08 whiteknight we have a surprising number of little projects like that, which don't get a lot of exposure
18:11 Coke is 70025 a perl6 ticket?
18:12 Coke (or is that for perl5?)
18:12 Coke (looks like the latter)
18:13 einstein if think I found litte bug in trunk/parrot/src/call/context_ac​cessors.c->get_context_str_fast
18:14 einstein I replaced return PMC_data_typed(ctx, Parrot_Context *); with return PARROT_CONTEXT(ctx)->context;
18:14 einstein to make my copy (with lots of my changed) of the code working
18:15 whiteknight einstein: what's the bug?
18:15 purl the bug is http://www.cbttape.org/funny/bug3.jpg or http://img227.imageshack.us​/img227/2596/featureiu1.jpg
18:17 einstein sorry it is no problem
18:18 einstein 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:19 whiteknight ok
18:21 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:22 whiteknight nice
18:22 whiteknight I don't know if there has ever been any kind of consensus on #1020. It was a pretty big change
18:24 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
18:25 cotto_work Getting Warnocked is almost as much fun as getting rickrolled.
18:27 einstein I did post a message in the mailing list, but got only reaction of whiteknight on the ticket  :$
18:28 dalek rakudo: fc56071 | markmont++ | src/ (3 files):
18:28 dalek rakudo: make $! always be a Perl object instead of sometimes being a Parrot Exception PMC.
18:28 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
18:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​c560718604c9fdfa9fdfeab27f58e089ab874ea
18:28 einstein But i though I could try to see where would end and it is still going as planned
18:35 Coke segfaaaaaaaaaaaaaaaaault.
18:36 kthakore Coke: fun!
18:38 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?
18:39 jonathan Coke: no. segfaaaaaaaaaaaaaaaaault.
18:39 Coke (do you mean parrot trunk?)
18:39 jonathan Yes.
18:39 jonathan oh
18:39 jonathan damm
18:39 Coke hopefully it's the same segfault that's killing partcl. =-)
18:39 jonathan Well, it's possible.
18:39 chromatic joined #parrot
18:39 jonathan Annoyingly, it doesn't involve any of the Rakudo specific stuff in the backtrace.
18:45 dalek rakudo: 657d55c | (Kyle Hasselbacher)++ | src/setting/ (2 files):
18:45 dalek rakudo: [setting] make !% work with Whatever
18:45 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​57d55cce1f1ded33fd1f731344bd31b33099cb8
18:52 whiteknight haha, that commit message is very funny, unintentionally
18:53 nopaste "coke" at 72.228.52.192 pasted "improve this perl6 code..." (15 lines) at http://nopaste.snit.ch/18460
18:54 japhb Coke: What is your definition of "improve"?
18:54 Coke japhb: vague.
18:55 japhb Well, instead of has_twin doing an if-else, just return the result of the if expression directly.
18:56 japhb Or if you're really feeling picky about the exact return, at least use a ternary instead ...
18:56 jonathan Oh ouch.
18:56 jonathan I've realized why we haz a segfault.
18:56 japhb jonathan, "we" as in Rakudo, or "we" as in Rakudo and Partcl?
18:57 jonathan japhb: Parrot.
18:57 jonathan get_iter in the MultiSub PMC assumes that we are currently doing a call.
18:57 jonathan It thus tries to sort based on the current call signature.
18:57 jonathan However, that is Null.
18:57 jonathan So we explode.
18:58 jonathan 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;
18:58 jonathan I guess I'll just check for nullness...
18:58 Coke japhb: if I don't do the if, I get 1 or undef.
18:58 Coke (i'd really have it show true or false.)
18:58 japhb Coke, then booleanize it.
18:59 jonathan Oh hmm...get_iter complains about no applicable candidates too? :-S
19:00 japhb so: sub has_twin(Int $n) { ?is_prime(all($n,any($n+2|$n-2)))) }
19:01 chromatic jonathan, I think we can safely remove that code from MultiSub's get_iter.  It looks almost unused.
19:02 chromatic Unless it's a guard condition, but it's a segfaulty guard condition.
19:02 jonathan chromatic: Hmm.
19:02 jonathan chromatic: I'm not sure if it's used. It looks...weird...to have that in there though.
19:02 japhb Coke, actually, that looks like redundant junctioning.  How about: sub has_twin(Int $n) { ?is_prime($n & ($n+2|$n-2)) }
19:02 jonathan chromatic: otoh it means its possible to sort the candidates and iterate over the result which may well be useful.
19:03 chromatic It doesn't returned the sorted results or the best candidate, however.
19:04 jonathan chromatic: No, but I'm guessing it sorts the list in place?
19:04 dalek parrot: r42114 | jonathan++ | trunk/src/pmc/multisub.pmc:
19:04 dalek parrot: [core] Eliminate a segfault and fix a regression in get_iter for MultiSub.
19:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42114/
19:04 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.
19:05 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.
19:05 jonathan Now the stage 1 compiler starts, but soon after promptly segfaults.
19:09 Coke japhb: much better, danke.
19:09 japhb Coke: np, glad I could help
19:11 dalek parrot: r42115 | pmichaud++ | trunk/compilers/pct/src/PAST (2 files):
19:11 dalek parrot: [pct/past]:  Add 'nsentry' attribute to PAST::Block.
19:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42115/
19:11 chromatic Wow, another big jump in Rakudo passing tests.
19:12 jonathan chromatic: Might you have a moment to sanity check something with me?
19:13 jonathan I'm looking at Parrot_call_method
19:13 jonathan (extend.c)
19:13 jonathan It takes const char *signature
19:13 chromatic Right.
19:14 jonathan It then does char  return_sig = signature[0];
19:14 jonathan In the lines after it gets up Pi first - for the invocant.
19:14 jonathan And then it strcats signature on
19:14 chromatic Yes, Coke found that the other day.  It's buggy.
19:14 jonathan Thing is, that means Parrot_pcc_build_sig_object_from_varargs
19:14 jonathan gets PiPP
19:14 jonathan And then seems to segfault.
19:14 jonathan Since one of those P's is the return type.
19:14 chromatic allison said to use Parrot_call_ext instead.
19:14 whiteknight should be PiP->P
19:15 whiteknight is it Parrot_ext_call or Parrot_call_ext?
19:15 jonathan whiteknight: Not according to the code.
19:15 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.
19:15 jonathan chromatic: Any reason not to patch Parrot_call_meth
19:15 jonathan ?
19:15 whiteknight Parrot_call_method is definitely going away
19:16 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)
19:16 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.
19:16 jonathan I thought I applied a patch to switch Rakudo away from using something else *to* using Parrot_call_meth not so long ago. :-/
19:16 allison whiteknight: ext is the prefix for the extend/embed subsystem
19:17 allison whiteknight: otherwise it would just be Parrot_call
19:17 jonathan allison: So which should I use?
19:17 whiteknight allison: right, I was getting confused
19:17 whiteknight jonathan: Parrot_ext_call
19:17 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)
19:17 allison jonathan: Parrot_ext_call, everything else is deprecated
19:17 * whiteknight was supposed to write up deprecation notices for all of them
19:17 * whiteknight was supposed to put together a list first
19:18 allison whiteknight: I started adding some deprecation notices
19:18 whiteknight allison++
19:18 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.
19:19 jonathan allison: Anyway, I'll switch over.
19:19 whiteknight where is Parrot_call_method defined?
19:19 jonathan whiteknight: you'll love this
19:19 jonathan extend.c ;-)
19:19 whiteknight that was my first guess
19:20 joeri joined #parrot
19:20 jonathan The one time I bother to use something that's actually in the API, it's wrong. ;-)
19:20 jonathan meh, OK, even with my patch Parrot_call_method still ends up doing something that leads to a (diferent) segfault.
19:20 whiteknight jonathan: info on the segfault? backtrace?
19:20 * jonathan switches to Parrot_ext_call, hoping it is left shafted.
19:21 jonathan whiteknight: It segfaults inside the inner runloop now, doing a can.
19:21 jonathan Probably because of some argument passing fail.
19:22 jonathan allison: Argh, Parrot_ext_call uses the -> form of signatures.
19:23 jonathan 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
19:23 jonathan whiteknight: Yeah, the whole thing looks generally messed. :-(
19:23 whiteknight so it's overflowing the va_list
19:23 jonathan whiteknight: Yeah, that was my analysis.
19:23 whiteknight creates a pointer to whatever garbage is on the stack, then segfault
19:23 jonathan whiteknight: I figure I'll spend tuits on switching to Parrot_ext_call though, since we'll have to in the end.
19:23 whiteknight okay, good
19:24 jonathan whiteknight: I'll nopaste the other bit of the patch I wrote.
19:24 jonathan whiteknight: http://gist.github.com/218945
19:24 whiteknight too many interfaces to the PCC code!
19:26 jonathan Yeah, and the one to switch to here is going to make me re-arrange quite a bit of code.
19:27 * 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:28 whiteknight jonathan: PCC refactors were always going to be painful
19:28 Coke whiteknight: when you change the API, that isn't a refactor.
19:28 whiteknight in fact, I remember the rakudo people asking us to push it forward anyway, despite the problems and the need for deprecation cycles
19:28 whiteknight Coke: that's what they are being called colloqially
19:29 Coke whiteknight: <chromatic>words mean things</chromatic>
19:29 Coke besides, he's only a /little/ pissed. =-)
19:29 chromatic PCC rewrites were always going to be painful.
19:30 chromatic The problem is, the old, deprecated functions don't work because they don't have any tests.
19:30 chromatic Their interfaces stayed the same.
19:30 whiteknight and because they are held together by duct tape, prayers, and unicorn tears
19:30 bacek joined #parrot
19:31 chromatic They're not great code, I admit, but they're untested code.
19:31 bacek Good morning
19:31 chromatic Anyone who feels the least bit of surprise that they don't work, I don't know what to say.
19:31 whiteknight hello bacek
19:31 bacek G'Day whiteknight
19:33 dalek parrot: r42116 | bacek++ | branches/context_unify/include/parrot/context.h:
19:33 dalek parrot: Add optimised Context accessors
19:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42116/
19:33 dalek parrot: r42117 | bacek++ | branches/context_unify/lib/​Parrot/Pmc2c/PCCMETHOD.pm:
19:33 dalek parrot: Update PCCMETHOD.pm to use CallContext
19:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42117/
19:33 dalek parrot: r42118 | bacek++ | branches/context_unify/src/call/args.c:
19:33 dalek parrot: Reimplement early return from fill_params
19:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42118/
19:33 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.
19:34 dalek nqp-rx: caa7f04 | pmichaud++ | src/cheats/hll-compiler.pir:
19:34 dalek nqp-rx: [hll]:  Remove obsolete emulation of old grammar+action setup.
19:34 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​aa7f042cd333599ce75b9eb36927bdc44011628
19:34 dalek nqp-rx: 4c4a0e2 | pmichaud++ |  (3 files):
19:34 dalek nqp-rx: [nqp] Initial subroutine declaration code (still missing params).
19:34 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/4​c4a0e20dd0dd13769af661cf07576c28bafa504
19:35 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 nnunley joined #parrot
19:36 Coke as it is, I try to report whenever something breaks. It's not always easy to derive tests back.
19:36 dalek parrot: r42119 | bacek++ | branches/context_unify/src/pmc/callcontext.pmc:
19:36 chromatic Assume that every time you have a bug, we need a test.
19:36 dalek parrot: Remove marking of non-existing field
19:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42119/
19:36 dalek parrot: r42120 | bacek++ | branches/context_unify/src/call/pcc.c:
19:36 dalek parrot: invoke_from_sig_object doesn't require to push_context
19:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42120/
19:36 dalek parrot: r42121 | bacek++ | branches/context_unify/tools/build/nativecall.pl:
19:36 dalek parrot: Update NCI to use CallContext
19:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42121/
19:36 dalek parrot: r42122 | bacek++ | branches/context_unify/src/pmc/continuation.pmc:
19:36 dalek parrot: Update Continuation to use CallContext
19:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42122/
19:36 dalek parrot: r42123 | bacek++ | branches/context_unify/src/pmc/multisub.pmc:
19:37 dalek parrot: Update MultiSub to use CallContext
19:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42123/
19:37 cotto_work bacek, do you expect any speedup from that branch or is it just to reduce code duplication?
19:38 bacek cotto_work: I already win about 15%
19:38 kthakore left #parrot
19:38 cotto_work bacek++
19:38 kthakore joined #parrot
19:38 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
19:38 bacek chromatic: nope
19:39 chromatic I thought I saw some macros yanked in earlier patches.
19:39 bacek chromatic: I replaced them with other macros :)
19:39 chromatic Good.
19:39 bacek branch can compile already.
19:40 bacek Many tests are broken
19:40 bacek Positive note: fib.pir is faster :)
19:40 whiteknight I think maybe we should put together a database of benchmark times
19:41 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.
19:41 cotto_work chromatic, how do you get that number?
19:41 chromatic Callgrind.
19:41 purl callgrind is probably a very intresting profiling tool for linux with details at http://kcachegrind.sourcef​orge.net/cgi-bin/show.cgi
19:41 cotto_work and just use the instruction count?
19:41 chromatic Yes.
19:42 whiteknight instruction count isn't necessarily a good metric for performance
19:43 whiteknight 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.
19:44 whiteknight does callgrind give metrics on things like pipeline hazards, cache misses, page faults, etc?
19:45 cotto_work you can get some of that with cachegrind
19:45 chromatic Cachegrind does some of those -- mostly cache misses.
19:45 whiteknight cache misses are probably very important to Parrot performance right now
19:45 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.
19:46 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.
19:46 chromatic Cache misses show what we should already know: per-GCable GC flags are ex-pen-si-ve.
19:47 whiteknight The next big GC performance improvement might be that cardmarking scheme of yours
19:48 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
19:48 chromatic It's also not incompatible with a full mark and sweep.
19:49 whiteknight it doesn't get us out of sweep, just reduces the number of PMCs that need sweeping
19:49 whiteknight and, it accesses the memory in a much more random pattern
19:49 chromatic Sweep becomes "prepend this list of headers to that list of headers".
19:49 whiteknight after "search this entire list of headers for headers with flag X set"
19:49 chromatic No searching necessary.
19:50 whiteknight oh, you're right
19:50 whiteknight I'm conflating algorithms in my head
19:50 chromatic The nice part about this is that the lists can be *generations*.
19:51 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.
19:51 chromatic We need reliable write barriers for that.
19:51 whiteknight correction: we need ANY write barriers for that
19:52 chromatic True.
19:52 * szbalint [offtopic] is tempted to reply to that maemo bug page
19:54 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 whiteknight as per usual, I may be full of shit and garbage
19:54 chromatic Your uneasy feeling is probably "But what if something gets allocated during the mark?"
19:57 whiteknight it would have to be stop-the-world
19:58 dalek nqp-rx: 4c594ad | pmichaud++ | src/NQP/ (2 files):
19:58 dalek nqp-rx: [nqp]:  Add simple parameters to signatures.
19:58 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/4​c594adce99ab5a481d3ce47a3990c96ca1d5cba
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
19:58 whiteknight have 3 levels, so every PMC needs to survive at least every other mark
19:59 whiteknight (which means new PMCs can survive the first mark without being marked
19:59 whiteknight Add additional tiers as generations which get marked less often but don't automatically demote
19:59 chromatic My recent realization was that we can put new PMCs on a "maybe free" list as soon as we allocate them.
19:59 chromatic Once we start marking, we create a new maybe free list.
19:59 whiteknight Benefit to this scheme is that it translates very readily into a concurrent scheme
20:00 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"
20:00 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
20:00 whiteknight chromatic: similar to what I was just saying, just a slight difference in the order and meanings of the various lists
20:01 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.
20:01 chromatic My naming assumes that most of those GCables won't survive their first mark.
20:01 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
20:02 whiteknight so we only need to change the linked list root node to move the whole damn group down a peg
20:02 chromatic Basically.
20:02 whiteknight "YOU'SE GONNA DIE"
20:02 whiteknight that's a quote that I actually heard one time on the subway
20:02 chromatic Once we've let mark() move the reachable ones out of that group.
20:03 whiteknight exactly
20:03 whiteknight did you see that Paper on the concurrent collection algorithm? I've been very inspired by it
20:04 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.
20:04 whiteknight chromatic: http://doc.cat-v.org/inferno/concurrent_gc/
20:05 whiteknight cotto_work++
20:05 whiteknight I've got so many of these printed out papers in my apartment that it's creating a firehazard
20:08 Wolong joined #parrot
20:08 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:09 whiteknight And I think we can make a single-threaded implementation of it quite easily
20:09 * theory hugs chromatic
20:14 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 whiteknight In fact, I would like a few new cores that we can race
20:14 whiteknight like a soapbox derby, only a lot more frustrating and esoteric
20:14 whiteknight and less fun
20:14 purl less fun is when the other people in the dream don't listen
20:15 * whiteknight thinks that purl hangs around in some pretty shady chatrooms
20:16 whiteknight and now it's time for me to leave. Later
20:17 jonathan Switching to Parrot_ext_call seems to have helped somewhat.
20:18 kj joined #parrot
20:18 jonathan Well, I get different failures now, anyways...
20:21 janus joined #parrot
20:23 dalek nqp-rx: 8d35cab | pmichaud++ | src/Regex/P6Grammar/ (2 files):
20:23 dalek nqp-rx: [p6grammar]:  Allow names of form  category:sym�foo� .
20:23 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/8​d35cabb1ceb394746ece6334d32a20cc9cabe21
20:23 dalek nqp-rx: c4b8459 | pmichaud++ |  (4 files):
20:23 dalek nqp-rx: [nqp]:  Add relational ops, prefix ops.
20:23 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​4b8459641c006711c5b3b58cff29fdbd7ef8acc
20:24 dalek parrot-linear-algebra: 34615d0 | darbelo++ | config/Makefile.in:
20:24 dalek parrot-linear-algebra: Cleanup makefile variables to use Configure data.
20:24 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/34615d0810369ae12fb4b6bdaf13c73f769932ac
20:25 desertm4x joined #parrot
20:25 ash_ joined #parrot
20:25 kurahaupo joined #parrot
20:29 Coke jonathan: silver lining1
20:31 dalek parrot: r42124 | bacek++ | branches/context_unify/src/call/pcc.c:
20:31 dalek parrot: Don't create new ret_continuation in invoke_from_sigobject
20:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42124/
20:34 dalek parrot: r42125 | bacek++ | branches/context_unify/src/pmc/continuation.pmc:
20:34 dalek parrot: Update passing params in Continuation
20:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42125/
20:38 * chromatic makes the function pointers in the vtable struct const, just for laughs.
20:39 chromatic Ah, memcpy() -- I love your type unsafe evil.
20:41 dalek parrot: r42126 | chromatic++ | trunk/src/pmc/multisub.pmc:
20:41 dalek parrot: [PMC] Removed get_iter() vtable entry from MultiSub, as it may be possible to
20:41 dalek parrot: crash when calling -- and the unique part is irrelevant, as it later delegates
20:41 dalek parrot: to the SUPER implementation instead.
20:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42126/
20:42 jonathan eww
20:42 jonathan attempt to access code outside of current code segment
20:42 jonathan :-/
20:43 cotto_work That's just a segfault wearing a nice hat.
20:43 jonathan Aye
20:46 baest joined #parrot
20:46 dalek nqp-rx: d38591b | pmichaud++ |  (2 files):
20:46 dalek nqp-rx: [nqp]:  Complete subroutine declarations (positionals only),
20:46 dalek nqp-rx: add nullterms in comma lists.
20:46 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/d​38591b438a9e19e02f2bef170be35682124acbe
20:47 Coke jonathan: I was seeing that on my segfault every so often.
20:47 Coke https://trac.parrot.org/parrot/ticket/1131
20:48 Coke (the original big tcl file was occasionally saying that, as I recall. after I trimmed it down, it started segfaulting consistently.)
20:50 jonathan Hmm
20:51 jonathan Coke: My guess in your case may be that one of the two PMCs that you pass in there is somehow invalid.
20:51 jonathan (e.g. the two involved in the assign op)
20:51 mokurai joined #parrot
20:51 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.
20:51 Coke and if I print out $P1, $P0, ISTR they were ok. I could be mistaken, though.
20:52 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. =-)
20:52 Coke (would explain why it fails just after the sort.)
20:52 jonathan *nod*
20:52 jonathan I'm doing similar evil.
20:54 Coke jonathan: I'll see if I can generate a PIR only version of that this evening.
20:54 Coke chromatic: converting partcl over to the new pct-like thing might help in generating easy-to-test PIR for you.
20:55 Coke s/you/parrot/
20:56 chromatic That would be nice.
20:57 payload joined #parrot
20:59 bacek purl: ( 4637738821 -  3981486428) / 4637738821 * 100
20:59 purl 14.1502662898662
21:00 cotto_work Where
21:00 cotto_work 's that win coming from?
21:00 bacek GC pressure
21:00 purl i guess GC pressure is the biggest problem right now.
21:00 bacek botsnack
21:00 purl thanks bacek :)
21:01 cotto_work Does the branch allow more PMC reuse or create fewer PMCs?
21:01 chromatic It should create about 25% fewer.
21:01 bacek create fewer PMC.
21:01 sjn bacek: looks like swedish phone numbers are 14.15% better than italian ones.
21:02 hercynium joined #parrot
21:02 jonathan sjn: That's because Sweden has a lovely telephone system. ;-)
21:03 sjn jonathan: yeah, they're much cooler too (mostly because of the cold weather though)
21:04 jonathan Mmmm...cold weather. :-)
21:04 kid51 joined #parrot
21:04 sjn +5 C in Oslo clears the mind :-)
21:08 jonathan Did anything much change during pcc_reapply to do with a Sub's invoke vtable, or return continuation invocation?
21:08 jonathan 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 #parrot
21:26 joeri left #parrot
21:27 chromatic You might need Parrot_cs_switch_to_seg or whatever that is.
21:27 darbelo Whiteknight: ping
21:29 mikehh joined #parrot
21:29 Whiteknight darbelo: pong
21:30 darbelo Looking at nummatrix2d.pmc now.
21:31 bluescreen joined #parrot
21:31 darbelo Are you sure it needs PObj_custom_destroy ?
21:31 darbelo I don't see a destroy() VTABLE there.
21:32 darbelo Also, if it's using auto_attrs, you shouldn't allocate them in init()
21:33 desertm4x That's probably my fault, I basically copied these things from another PMC I've written (that did not use auto_attrs).
21:34 darbelo Also, I think they are pre-zeroed. But I'm not sure on that point.
21:35 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
21:35 jonathan chromatic: It looks also though like I was not saving some state when doing nested calls, and it was thus getting trampled.
21:36 darbelo Why are we doing a double loop instead of straight memcpy()?
21:36 chromatic VTABLE_invoke() should do that, yes.
21:39 darbelo And we should probably consider making that function deal with raw storage, instead of PMCs.
21:41 joeri joined #parrot
21:42 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:44 bacek chromatic: ping
21:44 Whiteknight darbelo: we can't do a memcpy because of the way memory is laid out
21:44 Whiteknight rows are allocated end-to-end
21:44 Whiteknight so if we increase the length of the rows, we have to loop anyway
21:44 dalek nqp-rx: 64e2c87 | pmichaud++ |  (3 files):
21:44 dalek nqp-rx: [nqp]:  Add infix:<||>, infix:<&&>, and infix:<//>.
21:44 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/6​4e2c87c819666a8cdb2e613cf649044f68f88ef
21:44 dalek nqp-rx: ccd1d5b | pmichaud++ |  (3 files):
21:44 dalek nqp-rx: [nqp]:  More operators and tests.
21:44 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​cd1d5b98897e4cb90720ae5874794bbf5881073
21:45 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.
21:47 bacek chromatic: I hit major roadblock. It's not quite clear who should create new context...
21:48 bacek 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.
21:48 chromatic My first guess is Sub.invoke.
21:49 jonathan I don't think Sub.invoke can.
21:49 jonathan Since multi-dispatchers need the call signature before they pick what to invoke.
21:49 moritz cotto_work: I have a large TODO list for the irclog search, and I plan to re-do it completely, based on KinoSearch
21:49 moritz cotto_work: but it's unlikely that I'll get to it this year
21:50 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.
21:50 bacek chromatic: it was mine too...
21:53 cotto_work moritz, ok.  It's usable as-is but I'm glad you plan on making it better.
21:56 nopaste "chromatic" at 72.87.39.97 pasted "Make vtable function pointers const (segfaults, but an interesting idea)" (102 lines) at http://nopaste.snit.ch/18463
21:58 joeri left #parrot
22:07 integral joined #parrot
22:11 nopaste "darbelo" at 200.49.154.173 pasted "Whiteknight: memcpy() the rows" (26 lines) at http://nopaste.snit.ch/18464
22:13 NotFound chromatic: don't lie to the compiler. They aren't const.
22:14 chromatic Everywhere except the initialization they are.
22:15 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.
22:15 darbelo desertm4x: http://nopaste.snit.ch/18464
22:15 jonathan chromatic: That is, after switching to trunk.
22:16 jonathan 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%?
22:16 darbelo Unless I have x and y crossed in my head. Which has happened before.
22:16 jonathan chromatic: About that, no more than 15%.
22:17 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. ;-)
22:17 desertm4x I'm just checking whether you crossed x and y. ;-)
22:17 chromatic NotFound, can you think of a place where we modify the function pointers in a vtable besides PMC class init?  I can't.
22:18 darbelo I also think we should do shrinking on both dimesions a no-op.
22:24 NotFound chromatic: update_vtable functions use asiignment, so they can't be const.
22:25 dalek nqp-rx: 190f5e9 | pmichaud++ |  (3 files):
22:25 dalek nqp-rx: [nqp]:  Add while/until/repeat_while/repeat_until .
22:25 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​90f5e9294ce8da9694daf7529b31fd052a48560
22:25 dalek nqp-rx: 01986c7 | pmichaud++ | t/nqp/14-while.t:
22:25 dalek nqp-rx: [nqp]:  Add tests for "repeat [while|until] <xblock>" form.
22:25 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/0​1986c719def7eeae2bfc33430da9bb0abc49114
22:26 dalek parrot-linear-algebra: a92780f | darbelo++ | dynext/IGNORE:
22:26 dalek parrot-linear-algebra: Remove IGNORE file.
22:26 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/a92780facf660c1ae7f1fffe9f66a2799531250c
22:26 dalek parrot-linear-algebra: b4d7970 | darbelo++ | dynext/.gitignore:
22:26 dalek parrot-linear-algebra: Add empty .gitignore file in dynext/ to keep the dir alive.
22:26 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/b4d79705926fc48fed11209607e5dfd80325211d
22:26 dalek parrot-linear-algebra: fdade98 | darbelo++ | src/pmc/nummatrix2d.pmc:
22:26 dalek parrot-linear-algebra: Remove ATTR allocation and initialization, auto_attrs should handle that for us.
22:26 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/fdade98550315f0425285c3a515cfbc5a99d547e
22:26 chromatic NotFound, those all get called from class_init.
22:26 dalek parrot-linear-algebra: 22d7dfd | darbelo++ | src/pmc/nummatrix2d.pmc:
22:26 dalek parrot-linear-algebra: Make non-METHOD, non-VTABLE function static.
22:26 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/22d7dfdc9b33b8e6bd8a0a4a609e4b7bf01509dc
22:27 allison jonathan: yes, Parrot_ext_call uses the -> form of signatures
22:27 allison jonathan: everything is moving to that form, the old form can be considered deprecated
22:28 NotFound chromatic: yes, and you may need a nightmare of casts and/or copying to make that work.
22:29 Whiteknight joined #parrot
22:29 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:30 Whiteknight EUBUNTUCRASHED
22:30 darbelo Whiteknight: http://nopaste.snit.ch/18464
22:31 NotFound chromatic: mmmm... maybe a few casts in the VTABLE macros can do the desired work easily.
22:32 chromatic I never thought of that.  I like the idea.
22:32 kid51 joined #parrot
22:34 Whiteknight darbelo: I would be surprised if that actually helped performance at all
22:35 Whiteknight plus, like I said, resizes should be uncommon.
22:35 kj hi #parrot
22:35 cotto_work hi kj
22:35 Whiteknight hello kj
22:36 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.
22:37 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.
22:37 darbelo kj: You were probably experiencing parrot bugs that got fixed^W replaced with other bugs.
22:38 kj darbelo: Yes. You think it would help to just wait for the others to be fixed automatically? :-)
22:38 kj s/others/new ones/
22:39 NotFound chromatic: Using the same pmc during the loop?
22:39 chromatic yes
22:39 particle joined #parrot
22:40 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.
22:40 darbelo If you do it yourself you get to pick the bugs introduced. ;)
22:40 kj darbelo: Yes. well this is scary. PIRC-generated bytecode runs fine on Windows, but on MacOS it's faulty
22:41 * darbelo parsed that as "MacOS: it's faulty"
22:41 * darbelo agrees.
22:41 NotFound Maybe a pbc_diff program will be useful.
22:42 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?
22:42 chromatic I mean, in parameter signatures or stack variables.
22:42 kj moritz: yes that would be handy
22:42 kj moritz: haven't used it in ages, since i havent worked on it for ages..
22:42 NotFound chromatic: we almost never can because vtable functions take pointer to non-const.
22:44 NotFound 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
22:44 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Arch​ivedNewsEvents?version=3&amp;action=diff
22:44 dalek tracwiki: v112 | jkeenan++ | WikiStart
22:44 dalek tracwiki: Moved some completed 'news and events' to archived news events
22:44 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=112&amp;action=diff
22:44 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.
22:44 dalek parrot: r42127 | allison++ | trunk/docs/embed.pod:
22:44 dalek parrot: [cage] Delete deprecated and deleted functions from the extend/embed API.
22:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42127/
22:46 NotFound chromatic: Maybe we must rewrite parrot in Forth ;)
22:46 Whiteknight chromatic: you thin ML would be superior to C for that purpose?
22:47 chromatic From this angle of my particular frustration with C today, yes.
22:47 darbelo chromatic: third? What are the frist two?
22:47 darbelo s/frist/first/
22:47 chromatic One is a business plan.  The second is a personal goal.
22:47 darbelo Ah.
22:48 allison How about a new C-level language?
22:48 NotFound PL/I ?
22:48 purl PL/I is a stinking abomination. or FAQ at http://www.faqs.org/faqs/computer-lang/pli-faq/
22:48 dalek parrot: r42128 | allison++ | trunk/lib/Parrot/Pmc2c/Object.pm:
22:48 dalek parrot: [cage] Remove an unused code path that hasn't worked in several years.
22:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42128/
22:48 allison project goal "to develop a compelling replacement for C"
22:48 kid51 kj ping
22:48 kj kid51: hi
22:48 allison (al la svn)
22:48 NotFound That can be the personal goal part.
22:49 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)?
22:49 NotFound And business plan for it, thee birds in a shot.
22:49 kj i am kjs yes
22:49 kj and also the one in 1146 for that matter
22:49 jonathan Eww!
22:49 jonathan The way do_run_ops decides whether to invoke or not is, erm, ouch.
22:49 darbelo allison: There's about a dozen of those. Some of them are even used by their authors :)
22:49 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
22:49 NotFound Whiteknight: for example, to write a Winxed compiler C++ is better ;)
22:50 kid51 How do I get a pirc executable?
22:50 allison darbelo: then they clearly aren't "compelling"
22:50 kj kid51: cd compilers/pirc && make
22:50 Whiteknight NotFound: C is portable assembly (though it could be better in that regard). It's good for low-level stuff
22:50 kj kid51: I had some problems building on windows I think
22:50 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?
22:50 kid51 which make target
22:50 Whiteknight jonathan++ fixed some windows issues today
22:50 kj and on Cygwin the build is broken for some reason, haven't looked into that
22:51 kid51 Do you mean:  cd compilers/pirc && make
22:51 jonathan allison: My problem is that P6Invocation doesn't.
22:51 kj kid51: make target, are you assuming there it's in the main Makefile? It's not.
22:51 NotFound Whiteknight: That's the beauty of C++:: you can do the low level stuff parts without switching language.
22:51 jonathan allison: And I kinda really don't need it to (and worry about will happen if I make it do so).
22:51 kj kid51: yes, you have to manually build it in the compilers/pirc directory
22:51 allison jonathan: not sure I understand the question
22:51 chromatic I wish I could believe that C++ was finally cross-platform compatible.
22:51 kj eh, manually build=manually invoke make there. it's not compiled as part of parrot build process
22:51 Whiteknight NotFound: C++ isn't much higher-level then C is.
22:52 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
22:52 allison jonathan: if it isn't, I'd call it a bug
22:53 jonathan allison: See do_run_ops in src/call/pcc.c
22:53 jonathan allison: It would appear it is a bug. ;-)
22:53 Whiteknight allison: we still have a little ways to go before they're all perfectly polymorphically
22:54 allison jonathan: yup, bug
22:54 jonathan allison: OK, glad you agree. :-)
22:54 allison jonathan: (hardcoding class names for feature selection = bad)
22:54 jonathan Sure. At the very least it should be a "provides".
22:54 allison aye
22:54 kj kid51: sorry for confusion. added a note on how to get a pirc executable in the ticket.
22:55 pmichaud_ chromatic: patch for t/op/fetch.t at http://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.
22:56 pmichaud_ (and I'm at a point where having fetch could be very useful to me).
22:56 pmichaud_ (but can continue to live w/o it)
22:56 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.
22:57 jonathan (e.g. what if it had the readonly vtable swapped in...)
22:57 allison jonathan: I'd add another check after VTABLE_isa
22:57 NotFound jonathan: looks like the bug is the control flow inside that sub.
22:58 allison jonathan: for VTABLE_does
22:58 NotFound Mmm... no, is ugly but correct.
22:58 jonathan allison: What would we be checking for?
22:58 allison jonathan: but would have to move the check for enum_class_core_max after the isa and does checks
22:58 * darbelo has just stumbled across http://doc.cat-v.org/plan_9/​4th_edition/papers/acidpaper
22:58 allison jonathan: make it up
22:59 jonathan NotFound: lol...you mean the max_class_core... :-)
22:59 jonathan allison: invokable? ;-)
22:59 allison jonathan: sounds good
22:59 jonathan allison: No no, letting me name things is always a bad idea. :-)
22:59 jonathan oh wow :-)
22:59 NotFound allison: Replacing VTABLE_isa with VTABLE_does will be enough?
22:59 allison could be does invoke
23:00 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
23:00 jonathan By the way, with that, we now pass all of the Rakudo sanity tests on top of latest Parrot trunk.
23:00 allison jonathan: yes, pretending inheritance is just nasty
23:01 jonathan allison: Aye, but at least now I know something like this will be a good ifx.
23:01 jonathan *fix
23:01 jonathan Will add the does check.
23:02 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.
23:02 jonathan After that, it'll be time to see how epicly Rakudo fails its spectests.
23:03 NotFound Let me do a few tests...
23:04 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
23:05 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
23:05 allison (really, identical, they're cut-and-paste the same code)
23:06 nopaste "kid51" at 68.237.19.30 pasted "pirc: make test on Darwin/PPC (got similar on Linux/i386)" (45 lines) at http://nopaste.snit.ch/18466
23:06 Whiteknight yes. Parrot_PCCINVOKE was externally-facing, right? So I can't just chop it entirely?
23:06 allison Parrot_PCCINVOKE isn't part of the public API, so could be removed without a deprecation cycle
23:06 allison (though, it's a bit of an edge case)
23:07 jonathan allison: The role check works nicely.
23:07 allison Whiteknight: it at least falls under deprecation item TT #443
23:07 darbelo Whiteknight: Chop! Chop! Chop!
23:07 allison jonathan: excellent
23:07 nopaste "NotFound" at 213.96.228.50 pasted "patch for call/ppc Sub check" (30 lines) at http://nopaste.snit.ch/18467
23:08 NotFound jonathan: That can work?
23:08 allison NotFound: not "Sub" on the does check
23:08 allison NotFound: something like "Invokable"
23:08 jonathan NotFound: should be
23:08 jonathan || VTABLE_does(interp, sub_obj, CONST_STRING(interp, "Sub"));
23:08 jonathan oh fail
23:08 jonathan || VTABLE_does(interp, sub_obj, CONST_STRING(interp, "invokable"));
23:09 NotFound Ah, yes.
23:10 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.
23:11 allison NotFound: will CONST_STRING work across lines like that?
23:12 allison NotFound: IIRC, it has a silly bug that won't allow it on split lines
23:12 allison (bug, feature, whatever)
23:12 jonathan Wow, while runtime benchmarks for Rakudo are not bad, the spectests feel way slower. :-(
23:12 jonathan I'm guessing parsing related things.
23:12 NotFound allison: I fail to understand under what circunstances CONST_STRING think there are multiple lines implied.
23:13 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
23:13 Whiteknight what needs to happen to fix CONST_STRING to dtrt?
23:13 plobsing joined #parrot
23:14 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
23:14 chromatic Whiteknight, we have to fix all stupid C compilers everywhere.
23:14 chromatic Did I mention the words "ML" and "time machine" yet?
23:14 allison replace C!
23:15 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
23:16 allison 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?
23:16 chromatic C preprocessors don't handle #line reliably.
23:17 allison Whiteknight: because it's generating C code
23:17 Whiteknight allison: we can generate anything we want. we can generate better C code
23:17 allison Whiteknight: we could use a completely different way of preprocessing the CONST_STRINGs... but probably not in Perl 5
23:17 Whiteknight we don't need to use #line directives
23:18 dalek nqp-rx: d9b2cc4 | pmichaud++ |  (3 files):
23:18 dalek nqp-rx: [nqp]:  Add 'for' statement and tests.
23:18 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/d​9b2cc4eff58743ea3007a61dcc7dbcc15f800c1
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
23:18 Whiteknight preserves line numbering for debugging
23:19 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
23:19 allison Whiteknight: which will have to do something very similar
23:19 Whiteknight exactly.
23:19 allison (with substitutions for different languages)
23:20 nopaste "NotFound" at 213.96.228.50 pasted "patch for call/ppc Sub check - second edition" (47 lines) at http://nopaste.snit.ch/18468
23:21 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?
23:22 NotFound Uh, today I'm not very clear %-
23:22 allison plobsing: think you could split that patch out a bit?
23:23 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 http://nopaste.snit.ch/18469
23:23 mikehh joined #parrot
23:23 allison plobsing: particularly, some parts can be applied before 2.0, others have to wait until after
23:24 plobsing what parts have to wait?
23:24 dalek parrot: r42129 | whiteknight++ | trunk (15 files):
23:24 dalek parrot: [pcc] rename all instances of Parrot_PCCINVOKE to the more modern Parrot_pcc_invoke_method_from_c_args
23:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42129/
23:25 allison plobsing: and changes to nativecall.pl should be separate from changes to the PMC
23:26 NotFound Passes all test.
23:27 nopaste "jonathan" at 89.173.82.225 pasted "NotFound - here is the patch I wrote, fwiw" (14 lines) at http://nopaste.snit.ch/18470
23:27 jonathan NotFound: ^
23:27 jonathan NotFound: If it's going to be functionally equivalent to that, should be just fine. ;-)
23:27 NotFound jonathan: Do you have some idea on how to write a quick test?
23:27 jonathan NotFound: Off hand, not too easily.
23:28 dalek parrot: r42130 | whiteknight++ | trunk/src/call/pcc.c:
23:28 dalek parrot: [pcc] add a deprecation note to the POD of Parrot_PCCINVOKE. Future reference: Don't use this function! You have been warned
23:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42130/
23:28 jonathan NotFound: I ran into it because of a dynpmc that I use.
23:28 jonathan That an overloaded find_method hands back.
23:28 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.
23:28 jonathan So it's a fairly...convoluted...example.
23:28 jonathan ;-)
23:28 NotFound jonathan: I can commit it right now and we can create a todo ticket for the test, then.
23:28 Whiteknight speaking of dynpmcs: Does anybody here know how to go about installing one?
23:28 jonathan Whiteknight: Rakudo's make install target surely does.
23:29 darbelo Whiteknight: I do.
23:29 Whiteknight darbelo: parrot-linear-algebra needs a make install target
23:29 darbelo Whiteknight: look at the decnum-dynpmcs cfg/makefile.in
23:29 Whiteknight okay, I can do tha
23:29 darbelo Whiteknight: It's ok, I'm on it.
23:29 allison plobsing: it looked like you changed the signature strings for NCI
23:30 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
23:30 plobsing apparently the diff wasn't smart enough
23:31 Whiteknight darbelo: I don't see an install target anywhere in decnum-dynpmcs
23:31 allison plobsing: dropped some METHODs from the object
23:32 darbelo Whiteknight: cfg/Makefile.in line 172
23:32 darbelo It's been there since ages immemorial.
23:32 Whiteknight oh, I was looking in the wrong Makefile.in
23:32 allison plobsing: aye, it can get confused with large diffs
23:32 NotFound allison: Is fine to commit that change now and create a todo ticket for a test?
23:32 allison NotFound: yes, good fix
23:33 allison NotFound: sounds like a candidate for a new dynpmc
23:33 Whiteknight darbelo: got it! Working on it now
23:33 plobsing oops sorry, I guess I dropped set_raw_nci_ptr.
23:33 allison NotFound: testinvokable.pmc, or something like that
23:33 plobsing fixing
23:34 NotFound I'm not sure about what are the immediate intended usages, better if someone that knows writes the ticket.
23:38 Whiteknight joined #parrot
23:38 patspam joined #parrot
23:38 Whiteknight EUBUNTUCRASHEDAGAIN
23:39 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 #parrot
23:40 Whiteknight cotto_work: maybeee....
23:40 Whiteknight I loved 9.04. Absolutely loved it
23:40 Whiteknight and 9.10 will be awesome too when they work these bugs out
23:40 Whiteknight (which is why I like to be on the forefront of testing)
23:40 cotto_work From what I've read, I'm not going to bother upgrading until I'm convinced it's significantly less buggy.
23:41 cotto_work Apart from a few apps, I didn't care for the hassle of upgrading last time I bothered.
23:42 * jonathan doesn't do OS upgrades often.
23:42 jonathan Too lazy, and don't enjoy it.
23:44 Whiteknight they're switching to a new power manager. and there are obviously some kinks to work out with that
23:44 dalek parrot: r42131 | NotFound++ | trunk/src/call/pcc.c:
23:44 dalek parrot: [pcc] allow Parrot_pcc_invoke_from_sig_object to take a PMC that isa Sub or does invokable
23:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42131/
23:44 Whiteknight my laptop has been running noticably warmer since the upgrade, for instance
23:47 cotto_work I'm really unimpressed by the inability to restart dbus without screwing stuff up.
23:52 nopaste "darbelo" at 200.49.154.173 pasted "Install target for Whiteknight" (14 lines) at http://nopaste.snit.ch/18471
23:53 Whiteknight darbelo: just committed it
23:53 Whiteknight thanks though!
23:54 darbelo Whiteknight: Have you pushed it?
23:56 Whiteknight ....did now
23:56 allison save an endangered parrot? http://www.saveyourlogo.org/en
23:58 Essobi joined #parrot

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

Parrot | source cross referenced