Camelia, the Perl 6 bug

IRC log for #parrot, 2011-09-30

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 soh_cah_toa_ joined #parrot
00:16 dalek rakudo/optimizer: b2d15fa | jnthn++ | src/binder/bind.c:
00:16 dalek rakudo/optimizer: Start filling out the compile time trial binding for onlies. We'll start off just doing analysis for those that only have required positional parameters. This detects any arity mis-matches in this case at compile time. Some spectest failures, though most seem legitimate (they fail because we catch the innevitable failure at compile time now).
00:16 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/b2d15fa863
00:16 dalek rakudo/optimizer: 7d65d53 | jnthn++ | src/Perl6/Actions.pm:
00:16 dalek rakudo/optimizer: Fix to inline spec generator.
00:16 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/7d65d53aed
00:16 dalek rakudo/optimizer: bcb7c05 | jnthn++ | src/binder/bind.c:
00:16 dalek rakudo/optimizer: First crack at trial binding type analysis. Seems to do the right kind of thing.
00:16 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/bcb7c05acf
00:16 dalek rakudo/optimizer: 2e5a594 | jnthn++ | src/Perl6/Optimizer.pm:
00:16 dalek rakudo/optimizer: Small fix to inline handling, plus better error reporting if it hits an internal error.
00:17 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/2e5a594367
01:02 cotto ~~
01:42 dalek rakudo/nom: 008201f | Coke++ | t/spectest.data:
01:42 dalek rakudo/nom: track failures, run fudged tests.
01:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/008201fbf6
02:10 plobsing joined #parrot
02:17 Coke perl: say Failure()
02:17 Coke ww
02:18 cotto joined #parrot
02:36 woosley joined #parrot
02:45 cotto joined #parrot
03:29 cotto joined #parrot
03:55 rfw joined #parrot
04:39 fperrad joined #parrot
05:14 rfw joined #parrot
06:02 he_ joined #parrot
06:07 mj41 joined #parrot
06:31 contingencyplan joined #parrot
06:55 wagle joined #parrot
06:56 cotto joined #parrot
07:10 mj41 joined #parrot
07:16 cotto joined #parrot
07:18 dalek rakudo/nom: 66d0a4a | moritz++ | src/core/ (2 files):
07:18 dalek rakudo/nom: infix % and %% only make sense on Real, not Numeric
07:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/66d0a4af67
07:25 schmooster joined #parrot
07:39 cotto joined #parrot
08:11 lucian joined #parrot
09:28 mj41 joined #parrot
09:36 Khisanth joined #parrot
09:47 dalek rakudo/nom: 6060607 | moritz++ | t/spectest.data:
09:47 dalek rakudo/nom: dash-e depends on ICU
09:47 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/60606073f2
09:47 jkitazawa joined #parrot
11:36 Psyche^ joined #parrot
11:42 bluescreen joined #parrot
12:05 whiteknight joined #parrot
12:09 he joined #parrot
12:14 whiteknight good morning, #parrot
12:20 nbrown joined #parrot
12:27 bluescreen joined #parrot
12:34 SHODAN joined #parrot
12:38 jsut joined #parrot
12:55 nine good morning whiteknight
12:55 whiteknight hello nine
12:55 whiteknight I didn't get that branch merged last night
12:55 whiteknight or do anything else at all
12:55 nine well, no need to hurry, I can still use it to make progress
12:58 nine Basic task handling seems to work. Preemption is making problems: a continued task has a different runloop. But the continuation still has the old runloop's id, and this blows up in Parrot_finalize_pc
12:59 nine correction: Parrot_finalize_p
13:16 whiteknight ouch
13:16 whiteknight why do the different tasks have different runloops? are they different threads?
13:19 whiteknight if you save the current pc in the task, you should be able to share the same runloop
13:19 nine whiteknight: because Parrot_ext_call ends up using runops which creates a new runloop to run the ops
13:20 whiteknight okay. We may want to try to put together a new routine instead of Parrot_ext_call
13:21 nine that's what I thought. Parrot_ext_call feels a little heavy for just continuing a task anyway
13:29 awwaiid nine - preemption?
13:30 awwaiid crazyness
13:32 nine awwaiid: I'm trying to improve a VM who's biggest user is a half finished implementation of an unfinished programming language that's been in the works for over a decade and that has just about 10 users. A little crazyness can only help ;)
13:32 awwaiid that's the spirit!
13:38 whiteknight nine: what did the gsoc_threads branch do? I thought it shared the same runloop, I didn't think it created new runloops
13:41 whiteknight VTABLE_invoke returns a pointer to bytecode to start execution at, so when we execute a task we should be able to call VTABLE_invoke on the task to get the current pc and set that in the runloop
13:45 nine whiteknight: gsoc_threads did just the same. I don't know why it worked there. Tried to find out but suddenly gsoc_thread doesn't build anymore on my machine.
13:45 whiteknight urg
13:47 whiteknight okay
14:01 bluescreen joined #parrot
14:13 dalek rakudo/nom: 5feefbe | moritz++ | t/spectest.data:
14:13 dalek rakudo/nom: run capturing-contexts.t
14:13 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5feefbe438
14:13 dalek rakudo/nom: f2cc823 | moritz++ | src/core/IO.pm:
14:13 dalek rakudo/nom: IO.seek and .tell
14:13 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f2cc8231af
14:15 rg joined #parrot
15:01 cosimo joined #parrot
15:01 jsut joined #parrot
15:11 sjn_ joined #parrot
15:11 sjn_ left #parrot
15:51 contingencyplan joined #parrot
16:42 cotto joined #parrot
16:46 dodathome joined #parrot
16:50 cotto joined #parrot
16:59 cotto ~~
17:05 jevin joined #parrot
17:09 whiteknight hello cotto
17:12 fperrad joined #parrot
17:19 dalek parrot/whiteknight/main_args: f34a88c | Whiteknight++ | t/src/embed/api.t:
17:19 dalek parrot/whiteknight/main_args: fix t/src/embed/api.t
17:19 dalek parrot/whiteknight/main_args: review: https://github.com/parrot/parrot/commit/f34a88c059
17:19 dalek parrot/whiteknight/main_args: b7e7400 | Whiteknight++ | / (5 files):
17:19 dalek parrot/whiteknight/main_args: Merge remote-tracking branch 'origin/master' into simplify_main_args
17:19 dalek parrot/whiteknight/main_args: review: https://github.com/parrot/parrot/commit/b7e7400be8
17:19 dalek parrot: d6a0c0f | Whiteknight++ | / (9 files):
17:19 dalek parrot: Simplify argument passing to :main. Always pass exactly one PMC arg to :main. The new frontend combines it's two arrays into a single array argument, and parses that out.
17:19 dalek parrot: review: https://github.com/parrot/parrot/commit/d6a0c0f5db
17:19 dalek parrot: f34a88c | Whiteknight++ | t/src/embed/api.t:
17:19 dalek parrot: fix t/src/embed/api.t
17:19 dalek parrot: review: https://github.com/parrot/parrot/commit/f34a88c059
17:19 dalek parrot: b7e7400 | Whiteknight++ | / (5 files):
17:20 dalek parrot: Merge remote-tracking branch 'origin/master' into simplify_main_args
17:20 dalek parrot: review: https://github.com/parrot/parrot/commit/b7e7400be8
17:20 whiteknight msg nine I just merged whiteknight/main_args to master. Enjoy
17:20 aloha OK. I'll deliver the message.
17:21 nine whiteknight: thank you :)
17:24 dmalcolm joined #parrot
17:27 cotto 'morning whiteknight
17:38 lateau1 joined #parrot
17:39 dodathome joined #parrot
18:00 dalek rakudo/nom: f2e57ca | tadzik++ | VERSION:
18:00 dalek rakudo/nom: [release] bump VERSION
18:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f2e57ca01b
18:00 dalek rakudo/nom: 1403177 | tadzik++ | t/spectest.data:
18:00 dalek rakudo/nom: Temporarily comment out dash-e.t
18:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1403177a5d
18:13 nbrown joined #parrot
18:17 * nine will try to make sense of runops tomorrow
18:18 dalek rakudo/nom: cf85f33 | moritz++ | t/spectest.data:
18:18 dalek rakudo/nom: run instance attribute tests
18:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/cf85f33d60
18:18 dalek rakudo/nom: 091bee7 | moritz++ | src/core/ (2 files):
18:18 dalek rakudo/nom: fail() in Complex.Real
18:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/091bee7464
18:37 whiteknight nine: down that path lies insanity
18:41 cotto_work ~~
19:08 jlaire joined #parrot
19:14 dalek rakudo/nom: ebd4d87 | moritz++ | src/core/Failure.pm:
19:14 dalek rakudo/nom: throw an exception when calling an exception of Failure
19:14 dalek rakudo/nom:
19:14 dalek rakudo/nom: Probably not spec, but much better than the message that the method could not be found
19:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ebd4d87a0e
19:35 soh_cah_toa joined #parrot
19:44 nine whiteknight: that much I already found out :) But without knowing how this stuff actually works, it's gonna be very hard to change control flow in any way.
19:45 whiteknight nine: Yeah, true. Much of those innards are kind of crusty from age. I have no doubt changes or cleanups need to be made. Again, don't hesitate to point me in the right direction and give me a kick if you need something done
19:46 whiteknight much of the work in runops is just bookkeeping, like setting up jump points for exceptions, picking the core to use, etc
19:47 nine yep: the question for me is: how much of that bookkeeping is needed to resume a preempted task. Since runops also includes the setting up a new runloop which I'll have to avoid if possible
19:47 nine But I don't know enough about runloops yet
19:47 whiteknight Every time we go into a runloop, it sets up a jump_buf to jump to that loop for the purpose of exceptions, etc
19:48 whiteknight it's very likely that you can hijack that same mechanism to jump from the task scheduler to the most recent runloop
19:49 whiteknight We run into a potential problem where it probably becomes bad to resume a task in a runloop where it was not created, because then the C stack in one of the tasks gets messed up. The temporary solution to that might be to avoid preemption if we're in the wrong runloop until we unwind the stack
19:49 whiteknight I don't think it's a bad thing to say the scheduler gets put on hold if we preempt during a nesting operation
19:51 nine The problem is, that right now the resuming of a preempted task always creates a new runloop which is different from the runloop where the continuation of the preempted task was created
19:52 nine I have not yet found out how to actually safe that runloop to just continue later. Or what exactly a runloop is here for that matter :)
19:59 pyrimidine left #parrot
20:00 benabik o/ #parrot
20:02 whiteknight nine: yeah, it's tricky
20:03 benabik Runloops appear to be a holder for the C code outside the VM.  So when we call from VM -> C -> VM, a new runloop is called to hold that inner C bit.
20:03 benabik *created*
20:04 ambs joined #parrot
20:04 benabik I'm not sure why continuations would be runloop specific…  But I bet it's deep magical interactions with how we handle the C stack.
20:06 nine Well today I learned what setjmp is. Scared me :)
20:06 benabik nine: It should.  non-local control flow in C is scary
20:08 whiteknight nine: there's a reason why setjmp is not well known, even though it's been a part of the standard library since the beginning
20:08 whiteknight people don't use it because, in all but the most extreme cases, it should not be used
20:09 benabik Writing a VM is pretty extreme.  :-D
20:10 nine Oh how could I _not_ like this challenge :)
20:10 whiteknight :)
20:12 benabik Hm.  setjmp is something like get_current_continuation
20:12 nine btw. I told my supervisor at the university today that I want to have green threads running in two weeks. And I'll probably change the topic of my paper to just getting hybrid threads to work and investigate its performance properties. I'll leave the Perl 6 stuff for the second paper
20:13 preflex_ joined #parrot
20:14 whiteknight right now the best thing we can do is work around the runloop bullshit. Hopefully, in the shiney M0 future, we won't have nested runloops
20:14 benabik Ah, setjmp/longjmp have to be in the same stack.  interesting...
20:14 whiteknight at least, not that need to be aware of each other and place nicely with each other
20:14 * benabik is reading about continuations in C.
20:14 whiteknight benabik: yeah, they come with lots of limitations
20:15 whiteknight they must be in the same stack, setjmp must happen higher in the stack than longjmp, you shouldn't setjmp inside a loop or other stateful control flow structure, etc
20:16 benabik whiteknight: I was just reading someone's implementation where they used pointers to determine the positions of the stack and use pointers to manipulate it.
20:16 whiteknight yeah, implementations can be messy
20:16 benabik It's strangely elegant.
20:16 whiteknight a very simple implementation takes a snapshot of some of the most important processor register values and then restores them
20:16 benabik setjmp inside a loop shouldn't be to…  wait, some variables might be in registers and some in stack.  ow.
20:17 whiteknight like, saving EIP, EBP, and ESP shoudl be mostly enough
20:17 benabik setjmp handles saving and restoring registers.  You just have to do "fun" pointer manipulation to save/restore the _stack_
20:17 whiteknight right
20:17 whiteknight it's horrid
20:18 benabik whiteknight: http://http://homepage.mac.com/sig​fpe/Computing/continuations.html#1
20:18 whiteknight I once wrote a clone of setjmp/longjmp in PIR using continuations. The implementations were like 10 lines of PIR total and had none of these limitations
20:18 benabik Well, yes.
20:18 benabik Because continuations are registers and stack.
20:19 whiteknight so it goes to show that the ideas are good, the level of abstraction in C world is wrong
20:19 benabik C is a low-level language.  It's one step above writing assembly.
20:19 benabik And that's _useful_.  But bad for application programming.
20:23 nine Well, have to got to bed now. Getting up early again tomorrow. Good night #parrot
20:23 cotto_work 'night, nine
20:23 benabik Hm.  I wonder how portable get context/setcontext are.
20:23 benabik They're POSIX, so probably non-existent in Win32 like most useful POSIX constructs.
20:25 benabik Ah, but there's an equivalent GetThreadContext.  Handy.
20:25 * whiteknight has to go home. See you later
20:25 benabik o/ whiteknight
20:35 dalek rakudo/optimizer: 56be5f9 | jnthn++ | src/binder/bind.c:
20:35 dalek rakudo/optimizer: Fix a couple of oversights in compile-time bind analysis.
20:35 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/56be5f9f70
20:44 * benabik wonders how getcontext/setcontext interact with full threads.
20:46 * benabik should really do research for his thesis instead.
20:46 benabik bbiab
20:56 Eclesia joined #parrot
20:56 Eclesia hi
21:01 cotto_work hi Eclesia
21:09 Eclesia it might not be the best place to ask but ... anyone tryed Neko VM ?
21:29 benabik I wonder if you can use get/setcontext to implement M:N threading…  Anybody know?
21:35 benabik Are global variables outside the stack?
21:38 cotto_work In C I'm pretty sure they are.
21:40 benabik We use setjmp/longjmp for unwinding runloops, right?  I wonder if we could use getcontext/setcontext to make runloops more independent.
21:41 benabik As far as I can tell, ucontext is the closest C gets to continuations.
21:42 benabik Bah, idle thoughts after examining C threading constructs.  Moving on to thesis research..
23:00 rfw joined #parrot
23:01 whiteknight joined #parrot
23:06 whiteknight good evening, #parrot
23:07 tadzik good night, whiteknight
23:18 whiteknight hello tadzik. How are you doing today?
23:18 tadzik pretty good, although today is only one hour long for me now :) But friday was pretty nice, how about you?
23:19 whiteknight being done work for the week is always a good thing
23:24 nbrown joined #parrot
23:33 benabik o/ whiteknight
23:33 whiteknight hello benabik
23:44 soh_cah_toa_ joined #parrot
23:50 jsut_ joined #parrot
23:51 preflex_ joined #parrot
23:56 diakopte1 joined #parrot
23:57 diakopte1 I just tried rakudo's (fresh clone) --gen-parrot and it failed on cygwin

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

Parrot | source cross referenced