Camelia, the Perl 6 bug

IRC log for #parrot, 2011-10-04

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 benabik whiteknight: Saw you talking with nine about the exception problems on his branch.  Did you two figure out anything?
00:00 whiteknight I haven't really been able to look at it
00:13 eternaleye joined #parrot
00:13 arnsholt joined #parrot
00:13 AzureStone joined #parrot
00:13 perlite joined #parrot
00:14 particle1 joined #parrot
00:14 TiMBuS joined #parrot
00:14 dod joined #parrot
00:18 AzureStone joined #parrot
00:19 particle joined #parrot
00:19 nopaste joined #parrot
00:40 cotto http://zackarymorris.tumblr.com/post/1097​3087527/the-state-of-the-art-is-terrible
02:14 cotto ~~
02:20 crickets chirp
02:29 nbrown_ joined #parrot
02:32 cotto the dis spec reminds me of M0.  I'm sure it'd be the other way around if I'd seen it first.
02:32 cotto http://www.vitanuova.com/inferno/papers/dis.html
02:34 * plobsing remembers chromatic posting that a year or so ago. everything old is new again.
02:35 cotto I'm pretty sure I originally heard about it from him.
02:40 plobsing it may be worth noting that, IIRC, there was a gsoc task this year (not sure if they got a student) to *replace* dis.
02:41 plobsing if I can find where I read that, I'll link it so we can learn from their mistakes
02:47 plobsing http://code.google.com/p/infern​o-os/wiki/InfernoAndLimboPlans has hints
03:10 plobsing I'm not finding a lot of information about the current inferno community. I'm starting to turn up completely unrelated information.
03:10 plobsing http://www.hpi.uni-potsdam.de/hirschfeld/publica​tions/media/HauptPerscheidHirschfeld_2011_TypeHa​rvestingAPracticalApproachToObtainingTypingInfor​mationInDynamicProgrammingLanguages_AcmDL.pdf
03:10 plobsing unrelated, but interesting
04:29 nbrown joined #parrot
05:37 SHODAN joined #parrot
06:00 cotto plobsing, Hmm.  I'm not sure what to do with that.
06:23 Coke joined #parrot
07:06 baest joined #parrot
07:11 rfw joined #parrot
07:41 schmooster joined #parrot
07:57 mj41 joined #parrot
08:25 lucian joined #parrot
08:39 jkitazawa joined #parrot
08:50 lateau joined #parrot
09:12 baest joined #parrot
10:03 schmooster joined #parrot
11:22 lateau joined #parrot
11:36 benabik joined #parrot
11:42 Psyche^ joined #parrot
12:02 bluescreen joined #parrot
12:13 whiteknight joined #parrot
12:14 whiteknight good morning, #parrot
12:15 benabik o/ whiteknight
12:16 whiteknight good morning benabik. How are you doing today?
12:17 benabik whiteknight: tired and don't wanna study
12:17 whiteknight so don't! Procrastination is a wonderful, magical time machine to awesome adventures
12:17 whiteknight except, you don't feel like going right now
12:46 Themeruta joined #parrot
13:15 dukeleto ~~
13:18 whiteknight good morning, dukeleto
13:33 dukeleto whiteknight: how goes it?
13:33 * dukeleto has been on vacation and out of the loop
13:33 whiteknight dukeleto: it's going very well. Where was the vacation?
13:36 whiteknight I started adding pcre support and RegExp to Jaesop over the weekend, along with basic IO, so that has me very happy
13:38 dalek rakudo/nom: 299e5af | moritz++ | src/core/Mu.pm:
13:38 dalek rakudo/nom: Mu.not
13:38 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/299e5af864
13:38 dalek rakudo/nom: 545638a | moritz++ | src/Perl6/Actions.pm:
13:38 dalek rakudo/nom: deal with "require ::"
13:38 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/545638a018
13:39 dukeleto whiteknight: visiting family in Florida
13:39 dukeleto whiteknight: i am very happy to see Jaesop happily hopping along
13:40 benabik nine's been busy on getting tasks in place, but has been hampered by strange behavior involving longjmp + data corruption.
13:41 whiteknight the pcre bindings are one of the last big things before the stage0 compiler is usable to bootstrap. I have to add a few more runtime details, but we should be able to get started on stage1 soon if we are so inclined
13:41 whiteknight I would like to have 6model in place beforehand, and I would love to be able to use a new PACT instead of PCT for the backend if possible
13:42 dalek jaesop: 6187388 | Whiteknight++ | t/stage0/regexp.t:
13:42 dalek jaesop: Add in a quick test for RegExp.compile
13:42 dalek jaesop: review: https://github.com/Whiteknig​ht/jaesop/commit/6187388454
13:43 benabik Maybe post-midterms I'll try to get the low-level of PACT stubbed out...
13:44 dukeleto whiteknight: i have heard rumors of PACT, but haven't seen a spec for it yet
13:44 whiteknight dukeleto: no spec. We're shooting from the hip
13:44 dukeleto A good reason to never write ASM for performance reasons: http://zombe.es/post/40599​99783/openssl-outmoded-asm
13:45 benabik I've been collecting my thoughts in a gist: https://gist.github.com/05267b2b46beca86b8da
13:46 dukeleto I found that link from DJB's twitter account ( https://twitter.com/#!/hashbreaker ) which means we live in the future now.
13:47 dukeleto whiteknight: i like shooting from the hip, as long as I have a flamethrower
13:53 whiteknight I think we've learned quite a good deal over the years from PCT and tree-optimization and the like
13:54 whiteknight and if we start small, PACT can benefit from trial and error
13:54 dalek jaesop: a868012 | Whiteknight++ | t/stage0/regexp.t:
13:54 dalek jaesop: add in another quick test for /regexp/ syntax, which should be the same as the explicit constructor
13:54 dalek jaesop: review: https://github.com/Whiteknig​ht/jaesop/commit/a868012b79
13:54 mtk joined #parrot
13:59 dukeleto benabik: i would like to see that gist go into a doc in a branch
14:22 benabik dukeleto: If I get it into some kind of organization, sure.  If someone else wants to do the same, sure.  But at the moment it's more a "pile of benabik's brainstorming" than anything else.
14:23 alester joined #parrot
14:30 benabik Some thoughts added, including how I was thinking about building PACT (under bottom up)
14:40 whiteknight I had been meaning to take a stab at organizing it
14:40 whiteknight I'll look at it today
14:47 benabik Although I was although thinking PACT wouldn't be developed in parrot.git.  A small separate repository might be easier to work on.  Wouldn't have to integrate with parrot build system, could use outside dependencies like Rosella for tests.
14:47 benabik But since I don't have the time to build it myself, I can't really complain about what someone who does does with it.
15:14 whiteknight I'm not against all that, in theory. I would even be perfectly happy to have it as a part of Rosella, if you like that idea
15:15 whiteknight or separate too
15:17 benabik I'm a fan of the UNIX philosophy…  Separate small things each doing their job.  :-D
15:18 whiteknight that's fine too.
15:19 benabik But, as I said, I don't have time to work on it enough, so feel free to do it however's convenient for you.
15:19 whiteknight :)
15:25 dalek Rosella: c2edf5e | Whiteknight++ | src/unstable/container2/ (3 files):
15:25 dalek Rosella: Throw in a few quick notes about rewriting the Container lib
15:25 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/c2edf5eec5
15:25 dukeleto benabik: i don't care if PACT code is in parrot.git, but a more permanent document that parrot devs can edit is better for a spec
15:26 dukeleto benabik: i love gists, but as soon as multiple people want to edit it, it should become a document in a repo somewhere
15:26 dukeleto benabik: do you want a pact repo in the parrot github org?
15:26 whiteknight I can create one there
15:26 dukeleto whiteknight++
15:26 benabik dukeleto: Once someone else wants to edit it, they're welcome to stick it somewhere.  :-D  But as long as it's just my notes, I'll leave it in the gist.
15:27 benabik dukeleto: Unless/until I sort it out into coherent thoughts instead of random notes.
15:27 benabik It's getting closer each time I poke at it.
15:28 dukeleto benabik: sounds good to me
15:30 whiteknight https://github.com/parrot/PACT
15:32 benabik Huh.  Github added an "edit this file" button to the web interface.  I can keep just opening it and mucking with it whenever I feel like.  :-D
15:36 whiteknight the more mucking, the better
15:37 benabik The less mucking you do, the worse things get.  :-D
15:38 dukeleto benabik: yes, they added that just after the merge button. It is like an quick "fork, commit, merge" wearing an Edit button costume
15:53 dalek Rosella: cac0dec | Whiteknight++ | src/query/Query.winxed:
15:53 dalek Rosella: Add an exploratory routine to Query to install some basic methods on built-in types.
15:53 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/cac0deca7e
16:30 lateau left #parrot
16:34 cotto good morning
16:34 benabik o/ cotto
16:34 cotto dukeleto: nice to see you alive
16:47 dukeleto cotto: just been charging my batteries
16:47 dukeleto cotto: the next release is sneaking up on us. What are we trying to deliver for m0 ?
16:49 dmalcolm joined #parrot
16:52 cotto dukeleto: I'm getting back in the M0 boat after what turns out to have been a break, but I'm not sure if it makes sense to try to predict what'll be in the release wrt M0.
16:54 dukeleto cotto: i don't care much about timelines, but knowing the next logical steps are useful
16:54 cotto dukeleto: ok
16:55 cotto I pushed a couple commits yesterday that'll make it a little easier to add and remove ops.  I expect a lot of that to happen in the near future.
16:55 dukeleto cotto: we seem to be at an impasse where we don't know how many m0 ops we want anymore
16:56 cotto dukeleto: I wouldn't say that.  It's just a change in philosophy
16:56 dukeleto cotto: i like the philosophy of making it easy to add+remove ops and then forging ahead
16:56 cotto that's good
16:56 dukeleto cotto: ok. so our philosophy about ops has change to "as few as possible" to "the right number to optimize the speed of a jit" ?
16:56 dukeleto s/change/changed/
16:57 cotto not necessarily a jit
16:57 cotto M0 should map pretty closely to the operations a CPU can perform so that an optimizer isn't required to generate good code.
16:58 dukeleto cotto: isn't that another way of saying the same thing?
16:59 * cotto rereads
16:59 cotto dukeleto: pretty similar
16:59 dukeleto cotto: i agree with that statement, but it is much to vague too discern exactly which m0 ops should exist. We need specifics
17:00 cotto dukeleto: yes.
17:00 dukeleto cotto: and your statement is a bit more generic then my statement about jitting, but they are very similar
17:01 cotto dukeleto: my current plan is to plow ahead and look at how CIL and possibly one other VM deal with types (in addition to jvm, nanojit and gnu lightning) and use that as a basis for what'll be in M0.
17:03 cotto The first part of that should be done tonight.
17:05 cotto I'm a bit uneasy about M0 registers, especially since very few processors have 256 general purpose registers.
17:05 cotto ;)
17:06 dukeleto cotto: i would like to see a table of different vms and how many registers they have, and of what type
17:06 benabik cotto: 256 registers is more "explicit cache page" than register set
17:06 cotto I don't fully understand not_gerd's M0+/- proposal, but I like that he's put a lot of effort into making them match x86.
17:06 cotto dukeleto: that's close to what I've been producing
17:07 cotto it's more of "here's what types VM X knows about and what operations it can perform on them"
17:07 cotto register count doesn't really apply to stack VMs, which is a lot of them
17:08 benabik May want to include non-virt in there… i386, x86-64, ARM
17:08 cotto sigh.  There you go being all sensible.
17:08 benabik sorry
17:09 cotto well don't let it happen again
17:09 cotto ;]
17:10 cotto that'll take longer, but it's a very good idea that I really should have thought of
17:10 dukeleto cotto: yes, the register sets of hardware is actually more useful than software vm register sets
17:10 cotto benabik++
17:10 dukeleto cotto: because we want parrot to be fast on real hardware, not other vms
17:10 benabik Shouldn't take too long...
17:10 cotto benabik: no.  just another day or so depending on tuits
17:10 benabik Depends on how much data you're collating, I guess.
17:12 dukeleto cotto: is m0 trying to be risc or cisc ?
17:13 cotto dukeleto: running efficiently on x86/x64 is a high priority, so I'd say cisc-y
17:14 dukeleto cotto: look at that, we have more specifics :)
17:14 cotto whee
17:15 cotto dukeleto: nice to have you bach
17:15 cotto *back
17:15 cotto or Bach
17:18 cotto lulz: http://arstechnica.com/
17:19 benabik cotto: engadget.com too
17:20 whiteknight what's going on with those sites?
17:20 benabik DDoSed by people wanting to know what's up with the iPhone 4s
17:20 cotto ah.  That makes sense.
17:28 contingencyplan joined #parrot
17:32 fperrad joined #parrot
17:35 cotto http://merbist.com/2011/10/03/​about-concurrency-and-the-gil/
17:50 not_gerd joined #parrot
17:50 not_gerd hello, #parrot
17:50 dukeleto not_gerd: welcome
17:51 nine cotto: very interesting read
17:55 cotto hio not_gerd, nine
18:02 not_gerd hello, cotto
18:03 not_gerd m0- is shaping up to look pretty much like the current m0 spec
18:03 not_gerd (aside from the register number, that is...)
18:03 cotto not_gerd: we were just talking about M0 a bit earlier
18:03 cotto interesting
18:12 alester so what's up with http://tt.taptinder.org/buildstatus/parrot/master ?
18:12 alester It is sad and lonely, it seems.
18:13 cotto not_gerd: what's changing about M0-?
18:14 cotto alester: quite
18:16 alester Anything I can do to help things?
18:16 bubaflub i thought Coke was working on a replacement for that
18:20 alester What's wrong with the existing one?
18:21 not_gerd cotto: m0- ops are now variable length (ie the number of immediate arguments depends on the op)
18:21 not_gerd cotto: also, tehre's no longer a single word size (64 bit) because that lead to too much spilling on x86
18:21 not_gerd pointers and memory offsets are now 32 bit
18:27 whiteknight can't we have fixed-length ops? That makes traversal and analysis so much easier
18:29 not_gerd whiteknight: you're not supposed to analyse m0- - that's what m0+ is for
18:29 whiteknight oh, okay.
18:29 not_gerd whiteknight: you could think of it as the jit target for architectures without dedicated jit
18:29 whiteknight okay, that makes more sense then
18:30 whiteknight So long as there is a nice, pretty, friendly, uncompressed instruction format
18:45 cotto #ps in 45
18:46 nine Damn....sometimes reading the docs would be a really great idea: "The stack context will be invalidated if the function which called setjmp() returns."
18:49 whiteknight yes, setjmp is a tricky bastard
18:51 whiteknight We use it in the embedding API for callin/callout semantics, and we have to jump through some serious hoops there
18:52 nine nice pun ;)
18:56 fperrad joined #parrot
18:56 nine So I see two possible ways: try to fix the jump point issue, or try to work around continuations referencing their runloop so I can use runops
19:02 whiteknight what's wrong with the jump points?
19:05 nine The problem is that currently preempting a task means that runops returns. On return the jump point is invalidated according to setjmp(3). So there's no way I can resume that runloop, since it's most central feature is gone. So either runops does not return or I use a new runloop for the resumed task.
19:06 whiteknight why does runops have to return?
19:11 nine The scheduler just Parrot_ext_calls a task. On return it picks the next. I probably could use longjmp instead to return to the scheduler, which would leave the runloop intact. Or I make it work with a new runloop for every part of a task's execution.
19:12 whiteknight okay, that's where my confusion came from. The gsoc_threads branch used a preemptive task switch, so runops never exited
19:12 whiteknight or, it could exit, but for most cases it didn't need to
19:12 whiteknight in that case, the jump points are preserved
19:13 whiteknight when runops returns, we can call into it again. that's not an issue
19:13 nine I think gsoc_threads never actually really worked.
19:13 whiteknight no, it didn't really. It worked for some trivial things, but it didn't work for a lot of it
19:14 nine I changed almost nothing. Especially the preemption. So it has to have the same problems.
19:14 whiteknight okay
19:15 nine I'll just try the longjmp to the scheduler. Sounds like the least intrusive way.
19:15 whiteknight okay
19:25 cotto #ps in 5m
19:31 cotto my how time flies
19:35 cotto dukeleto: care to take a ride on the M0 train?
19:35 cotto er, #ps
19:35 cotto train
19:58 mj41 joined #parrot
20:01 benabik joined #parrot
20:24 dmalcolm joined #parrot
20:34 Coke joined #parrot
20:41 benabik I think the biggest change we'd need to make for parrot to be relocatable is our runtime directories.  Linker will be able to find libparrot, but we'd need to do a real search path for includes, dynpmcs, dynops, etc.
20:45 benabik Could have a PARROTLIB environment variable (think PERL5LIB or VIMRUNTIME) or a path given to the interp on creation.
20:56 cotto benabik: that sounds like a good starting point
21:37 benabik joined #parrot
21:48 eqhmcow joined #parrot
22:36 dmalcolm_ joined #parrot
22:41 dmalcolm__ joined #parrot
22:50 whiteknight joined #parrot
22:56 bubaflub joined #parrot
23:02 whiteknight good evening, #parrot
23:13 cotto howdy
23:22 benabik joined #parrot
23:36 dalek Rosella: ebac3aa | Whiteknight++ | src/ (4 files):
23:36 dalek Rosella: Merge branch 'master' of github.com:Whiteknight/Rosella
23:36 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/ebac3aae58

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

Parrot | source cross referenced