Parrot 3.8.0 "Magrathea" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 29 September 2011.
00:01 soh_cah_toa_ joined
dalek kudo/optimizer: b2d15fa | jnthn++ | src/binder/bind.c:
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
kudo/optimizer: 7d65d53 | jnthn++ | src/Perl6/Actions.pm:
Fix to inline spec generator.
kudo/optimizer: bcb7c05 | jnthn++ | src/binder/bind.c:
First crack at trial binding type analysis. Seems to do the right kind of thing.
kudo/optimizer: 2e5a594 | jnthn++ | src/Perl6/Optimizer.pm:
Small fix to inline handling, plus better error reporting if it hits an internal error.
cotto ~~ 01:02
dalek kudo/nom: 008201f | Coke++ | t/spectest.data:
track failures, run fudged tests.
 01:42
02:10 plobsing joined
Coke perl: say Failure() 02:17
ww
02:18 cotto joined 02:36 woosley joined 02:45 cotto joined 03:29 cotto joined 03:55 rfw joined 04:39 fperrad joined 05:14 rfw joined 06:02 he_ joined 06:07 mj41 joined 06:31 contingencyplan joined 06:55 wagle joined 06:56 cotto joined 07:10 mj41 joined 07:16 cotto joined
dalek kudo/nom: 66d0a4a | moritz++ | src/core/ (2 files):
infix % and %% only make sense on Real, not Numeric
 07:18
07:25 schmooster joined 07:39 cotto joined 08:11 lucian joined 09:28 mj41 joined 09:36 Khisanth joined
dalek kudo/nom: 6060607 | moritz++ | t/spectest.data:
dash-e depends on ICU
 09:47
09:47 jkitazawa joined 11:36 Psyche^ joined 11:42 bluescreen joined 12:05 whiteknight joined 12:09 he joined
whiteknight good morning, #parrot 12:14
12:20 nbrown joined 12:27 bluescreen joined 12:34 SHODAN joined 12:38 jsut joined
nine good morning whiteknight 12:55
whiteknight hello nine
I didn't get that branch merged last night
or do anything else at all
nine well, no need to hurry, I can still use it to make progress
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:58
correction: Parrot_finalize_p 12:59
whiteknight ouch 13:16
why do the different tasks have different runloops? are they different threads?
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
whiteknight okay. We may want to try to put together a new routine instead of Parrot_ext_call 13:20
nine that's what I thought. Parrot_ext_call feels a little heavy for just continuing a task anyway 13:21
awwaiid nine - preemption? 13:29
crazyness 13:30
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!
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:38
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:41
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
okay 13:47
14:01 bluescreen joined
dalek kudo/nom: 5feefbe | moritz++ | t/spectest.data:
run capturing-contexts.t
 14:13
kudo/nom: f2cc823 | moritz++ | src/core/IO.pm:
IO.seek and .tell
14:15 rg joined 15:01 cosimo joined, jsut joined 15:11 sjn_ joined, sjn_ left 15:51 contingencyplan joined 16:42 cotto joined 16:46 dodathome joined 16:50 cotto joined
cotto ~~ 16:59
17:05 jevin joined
whiteknight hello cotto 17:09
17:12 fperrad joined
dalek rrot/whiteknight/main_args: f34a88c | Whiteknight++ | t/src/embed/api.t:
fix t/src/embed/api.t
 17:19
rrot/whiteknight/main_args: b7e7400 | Whiteknight++ | / (5 files):
Merge remote-tracking branch 'origin/master' into simplify_main_args
rrot: d6a0c0f | Whiteknight++ | / (9 files):
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.
rrot: f34a88c | Whiteknight++ | t/src/embed/api.t:
fix t/src/embed/api.t
rrot: b7e7400 | Whiteknight++ | / (5 files):
Merge remote-tracking branch 'origin/master' into simplify_main_args
whiteknight msg nine I just merged whiteknight/main_args to master. Enjoy
aloha OK. I'll deliver the message.
nine whiteknight: thank you :) 17:21
17:24 dmalcolm joined
cotto 'morning whiteknight 17:27
17:38 lateau1 joined 17:39 dodathome joined
dalek kudo/nom: f2e57ca | tadzik++ | VERSION:
[release] bump VERSION
 18:00
kudo/nom: 1403177 | tadzik++ | t/spectest.data:
Temporarily comment out dash-e.t
18:13 nbrown joined
nine will try to make sense of runops tomorrow 18:17
dalek kudo/nom: cf85f33 | moritz++ | t/spectest.data:
run instance attribute tests
 18:18
kudo/nom: 091bee7 | moritz++ | src/core/ (2 files):
fail() in Complex.Real
whiteknight nine: down that path lies insanity 18:37
cotto_work ~~ 18:41
19:08 jlaire joined
dalek kudo/nom: ebd4d87 | moritz++ | src/core/Failure.pm:
throw an exception when calling an exception of Failure

Probably not spec, but much better than the message that the method could not be found		 19:14
19:35 soh_cah_toa joined
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:44
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:45
much of the work in runops is just bookkeeping, like setting up jump points for exceptions, picking the core to use, etc 19:46
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
But I don't know enough about runloops yet
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
it's very likely that you can hijack that same mechanism to jump from the task scheduler to the most recent runloop 19:48
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
I don't think it's a bad thing to say the scheduler gets put on hold if we preempt during a nesting operation
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:51
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:52
19:59 pyrimidine left
benabik o/ #parrot 20:00
whiteknight nine: yeah, it's tricky 20:02
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
*created*
20:04 ambs joined
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:04
nine Well today I learned what setjmp is. Scared me :) 20:06
benabik nine: It should. non-local control flow in C is scary
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
people don't use it because, in all but the most extreme cases, it should not be used
benabik Writing a VM is pretty extreme. :-D 20:09
nine Oh how could I _not_ like this challenge :) 20:10
whiteknight :)
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
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...
whiteknight at least, not that need to be aware of each other and place nicely with each other
benabik is reading about continuations in C.
whiteknight benabik: yeah, they come with lots of limitations
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:15
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
benabik It's strangely elegant.
whiteknight a very simple implementation takes a snapshot of some of the most important processor register values and then restores them
benabik setjmp inside a loop shouldn't be to… wait, some variables might be in registers and some in stack. ow.
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_
whiteknight right
it's horrid
benabik whiteknight: http://homepage.mac.com/sigfpe/Comp...ons.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
benabik Well, yes.
Because continuations are registers and stack.
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.
And that's _useful_. But bad for application programming.
nine Well, have to got to bed now. Getting up early again tomorrow. Good night #parrot 20:23
cotto_work 'night, nine
benabik Hm. I wonder how portable get context/setcontext are.
They're POSIX, so probably non-existent in Win32 like most useful POSIX constructs.
Ah, but there's an equivalent GetThreadContext. Handy. 20:25
whiteknight has to go home. See you later
benabik o/ whiteknight
dalek kudo/optimizer: 56be5f9 | jnthn++ | src/binder/bind.c:
Fix a couple of oversights in compile-time bind analysis.
 20:35
benabik wonders how getcontext/setcontext interact with full threads. 20:44
benabik should really do research for his thesis instead. 20:46
bbiab
20:56 Eclesia joined
Eclesia hi 20:56
cotto_work hi Eclesia 21:01
Eclesia it might not be the best place to ask but ... anyone tryed Neko VM ? 21:09
benabik I wonder if you can use get/setcontext to implement M:N threading… Anybody know? 21:29
Are global variables outside the stack? 21:35
cotto_work In C I'm pretty sure they are. 21:38
benabik We use setjmp/longjmp for unwinding runloops, right? I wonder if we could use getcontext/setcontext to make runloops more independent. 21:40
As far as I can tell, ucontext is the closest C gets to continuations. 21:41
Bah, idle thoughts after examining C threading constructs. Moving on to thesis research.. 21:42
23:00 rfw joined 23:01 whiteknight joined
whiteknight good evening, #parrot 23:06
tadzik good night, whiteknight 23:07
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?
whiteknight being done work for the week is always a good thing 23:19
23:24 nbrown joined
benabik o/ whiteknight 23:33
whiteknight hello benabik
23:44 soh_cah_toa_ joined 23:50 jsut_ joined 23:51 preflex_ joined 23:56 diakopte1 joined
diakopte1 I just tried rakudo's (fresh clone) --gen-parrot and it failed on cygwin 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!