|
weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today Set by moderator on 3 October 2010. |
|||
|
03:19
eternaleye joined
03:23
eternaleye left,
eternaleye joined
05:41
pmichaud left
05:57
pmichaud joined
08:17
[particle] left
08:49
[particle] joined
12:46
[particle] left
12:48
[particle] joined
14:41
eternaleye left
|
|||
| sorear | ok. I seem to have at least not slept through #phasers this time... | 18:39 | |
| moritz_ might be a bit later for #phasers, preparing dinner right now | 18:44 | ||
| Util | Pre-posting: | 18:56 | |
| * Added 1 RosettaCode Perl6 solution: Horner's rule. | |||
| * Wrote code to dump all RC task solutions and extract all Perl 6 solutions. | |||
| * Working on RC: Polynomial long division | |||
| .end | |||
|
18:57
masak joined
|
|||
| masak | o/ | 19:01 | |
| Util | \\o | 19:03 | |
|
19:04
takadonet joined
|
|||
| sorear | o/ | 19:04 | |
| masak | the non-liveliness of #perl6 makes me think there will not be much of a meeting today. or it will be delayed. :/ | ||
| sorear | I have started working in earnest to get Niecza to accept a version of STD.pm6 | 19:05 | |
| pmichaud | hola | ||
| masak | sorear: nice! | 19:06 | |
| pmichaud | +1 | ||
|
19:07
colomon joined
|
|||
| colomon | o/ | 19:07 | |
| sorear | o/ | 19:08 | |
| pmichaud | my report: $otherjob and @family stuff continue to eat up my time, and I have a bit of a $!cold. I'm hoping to be back into heavy-duty hacking in the next 48 hrs, though. | 19:09 | |
| masak | I don't have much to report today. I submitted 16 rakudobug since last week. went to Paris and held two talks on Sunday; one which I consider to be unusually successful, and the other one which was OK and that made me learn a bit about exposition of Perl 6. .eor | 19:10 | |
| colomon | (backlogging...) ooo, sorear++ | ||
| sorear | I still have rather more to do than I realized, though. | ||
| masak | pmichaud: I'm glad your $!cold has an exclamation mark. that's one of the cases where encapsulation really helps. get well soon. | 19:11 | |
| moritz_ had done a bit of the usual here-and-there | 19:14 | ||
| masak | moritz_++ | ||
| moritz_ | s/had/has/ | ||
| apart from that, $lack-of-tuits | 19:15 | ||
| colomon | moritz_++ # for the lovely regex implementation of the palindrome finder | ||
| masak | moritz_++ # for a blog post that went to reddit and didn't provoke trolling | ||
| takadonet | not yet.... | 19:17 | |
| masak | the trolls are usually first on location. | 19:18 | |
| takadonet | maybe they are sleeping at the switch | 19:20 | |
| masak | then find that timestamp and write it down somewhere. | 19:21 | |
| I find that if we don't end this meeting soon, it's going to end by itself. | 19:22 | ||
| anyone have anything more to add? | 19:23 | ||
| pmichaud | 0 from me :-) | ||
| moritz_ | currently development seems a bit slow | ||
| I guess it's because jnthn++ is working in a different repo, and everybody else seems to lack tuits | 19:24 | ||
| masak | I can attest to that. I've been in transit much of my time last week. | 19:25 | |
| pmichaud | yes, I'm short on tuits | ||
| colomon | I spent too much time celebrating my birthday. :) | ||
| masak | (mberends' car)++ may have 220V electricity, but it's hardly an ideal hacking environment. neither are planes, trains, or buses. | ||
| colomon | errr, and playing Lacuna Expanse. | ||
| masak has managed to fall into that time sink so far :) | 19:27 | ||
| Util in Tuit crop failure | |||
| sorear is very optimistic and has a few tuits | 19:41 | ||
| masak is happy and well-rested, and looks forward to the rest of 2010 | |||
| colomon is crazy busy and never gets enough sleep, but would still sneak in some Rakudo hacking if he had a clear idea where a little hacking could be useful. | 19:43 | ||
| masak | may I recommend hunting around a bit in the vicinity of named enums? | ||
| pmichaud: still around? | 19:44 | ||
| sorear | colomon: that's my problem with rakudo, I don't feel like there's a place for me to be useful | ||
| colomon | sorear: I'm sure there's plenty of room for both of us to be useful there, the hard part is figuring out what needs work, other than generic "we desperately need optimizations". | 19:46 | |
| masak | pmichaud: remember when I had (class { ... }).new in my enums patch? I still don't like the '.new' part, but I'm thinking of adding it back again, since *not* having it in there prevents enums from reaching their full potential. | 19:47 | |
| PerlJam | greetings #phasers | 20:01 | |
| colomon: what you just said! | 20:02 | ||
|
20:04
mberends joined
|
|||
| sorear | \\o mberends | 20:05 | |
| mberends | hi sorear and @others, sorry I'm late | 20:06 | |
| masak | there's still plenty of room for everything from small scripts to medium-sized applications written in Perl 6. every time someone does that, a lot of good things happen: everything from bug reports and better spectest coverage to blog posts and improved spec. | ||
| sorear | OOC, what's the largest program currently written in Perl 6? | ||
| masak | hinges a lot on definition, methinks. | ||
| STD.pm6 is pretty large. | |||
| November is not half-small. | |||
| GGE is large, and runs on the latest Rakudo. | 20:07 | ||
| sorear | mberends: | ||
| colomon | masak: yes, I've been keeping up with the scripts. but the problem is they are mostly working... it's not like the old days where you'd write a ten line script and find two new Rakudo bugs. | 20:08 | |
| sorear | mberends: do you know if it's possible to run llvm in an environment where stacks need to be parsed? | ||
| masak | colomon: you don't? I do. :) | ||
| colomon: you're mostly right, though. | |||
| mberends | sorear: at a first guess, no, because llvm "manages" the stack for your program, you probably don't get access to a stack pointer register. | 20:10 | |
| sorear: however, llvm does support one's own implementation of coroutines and such like, which implies that such stack pointer type access might be available. | 20:11 | ||
| sorear | coroutines are not too hard; it's caller I'm pondering | 20:13 | |
| mberends | sorear: if you give me about a week, I can look into it for a more certain answer. | ||
| sorear | mberends: sure. I've already been doing a lot of looking myself - do you have any pointers? | ||
| mberends | sorear: is that a kind of "walking the stack" problem? | ||
| sorear | Yes | 20:14 | |
| mberends | first idea: llvm.org/docs/LangRef.html#i_unwind | 20:15 | |
| no, that's probably not suitable. You want to read the stack, not goto where it is pointing. | 20:18 | ||
| ENOJNTHN? I'm closing in on a 6model/java bug by old fashioned print and crash, but could do with debugging tips. | 20:23 | ||
| sorear: another pointer would be (sorry for the unavoidable pun) to access memory via a pointer produced by the GetElementPtr instruction. The best docs for that are llvm.org/docs/GetElementPtr.html . If you have an with a value on the stack, overrun the bounds of the array to read what is stored higher up the stack. Messy, but messing is what you are going to do. | 20:34 | ||
| *an array | |||
| sorear | mberends: that's not quite what I mean | 20:35 | |
| mberends: the stack parser is going to be asm | |||
| mberends: however, I need to know how llvm has layed out the stack | |||
| basically, I need the ability to hook into .eh_frame generation and spit out a different kind of table | |||
| one that, for instance, knows that $*FOO is stored at CFA+16 in this frame | 20:36 | ||
| mberends | sorear: llvm uses the same memory layouts as a C compiler would, so just guessing how gcc would push data onto the stack would probably apply. | 20:39 | |
| there are other calling conventions available, but C style is the default. | 20:43 | ||
| sorear | A calling convention is a local thing. | ||
| It allows you to pass arguments and get return values. | 20:44 | ||
| It does not allow you to peek at the local variables of a frame 10 levels up | |||
| Or even, for that matter, to find out if there *is* a frame 10 levels up | |||
| Debuggers face the same problem, and they need compiler support | |||
| LLVM generates a .eh_frame section containing frame parse information for use by gdb | 20:45 | ||
| jnthn | Hi folks, sorry I missed #phasers. Unexpectedly got invited out. | 20:52 | |
| sorear | Hi jnthn. | ||
| jnthn | Sadly, not a great deal more energy than last night. D'oh. | 20:53 | |
| o/ sorear | |||
| mberends | o/ jnthn: now packing for drive to Ljubljana :) | 21:08 | |
| jnthn | Whoa, that's a LONG drive! | ||
| mberends | nearer than Bratislava (only just) | 21:09 | |
| jnthn | Really? | 21:10 | |
| I'd have had it as further. | |||
| But not by that much either. | |||
| mberends | ok, quite similar | ||
| jnthn: I have narrowed the 6model/java bug down to a null LexPad field in a Context object (using the fake Setting for simplicity). By inspection, it's not the Context created by Init. I haven't yet looked for or found where else Context objects are created. | 21:14 | ||
| jnthn | mberends: The setting makes one and returns it. | 21:15 | |
| mberends | is that the one that the fake Setting populates with KnowHOW, capture, NQPInt, NQPNum, NQPStr, LLCode and list? Because that one is not null and looks correct. In the java startup, there are three other LexPads that get created (I cannot yet say where from) but these three all contain no entries :( That seems to be the bug, but whence they are created is not clear. | 21:20 | |
| jnthn | mberends: I was more meaning the one that NQPSetting.cs returns | 21:23 | |
| But wait, is it blowing up inside there? | |||
| Maybe check the bit of code that handles copying the static lexpad entries into the dynamic one. | |||
| That would be an easy way for things to be wrong, if it's not doing that. | 21:24 | ||
| I think it's in Context.[cs|java] off hand... | |||
| Just gonna go prepare bits I need for $dayjob tomorrow while I'm still lucid enough :-) | 21:25 | ||
| bbs | |||
| mberends | jnthn: thanks for the suggestions, will try that later. packing & | 21:32 | |
|
21:34
masak left
|
|||