Perl 6 - the future is here, just unevenly distributed

IRC log for #phasers, 2010-10-12

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

All times shown according to UTC.

Time Nick Message
03:19 eternaleye joined #phasers
03:23 eternaleye left #phasers
03:23 eternaleye joined #phasers
05:41 pmichaud left #phasers
05:57 pmichaud joined #phasers
08:17 [particle] left #phasers
08:49 [particle] joined #phasers
12:46 [particle] left #phasers
12:48 [particle] joined #phasers
14:41 eternaleye left #phasers
18:39 sorear ok.  I seem to have at least not slept through #phasers this time...
18:44 * moritz_ might be a bit later for #phasers, preparing dinner right now
18:56 Util Pre-posting:
18:56 Util * Added 1 RosettaCode Perl6 solution: Horner's rule.
18:56 Util * Wrote code to dump all RC task solutions and extract all Perl 6 solutions.
18:56 Util * Working on RC: Polynomial long division
18:56 Util .end
18:57 masak joined #phasers
19:01 masak o/
19:03 Util \o
19:04 takadonet joined #phasers
19:04 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. :/
19:05 sorear I have started working in earnest to get Niecza to accept a version of STD.pm6
19:05 pmichaud hola
19:06 masak sorear: nice!
19:06 pmichaud +1
19:07 colomon joined #phasers
19:07 colomon o/
19:08 sorear o/
19:09 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:10 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++
19:10 sorear I still have rather more to do than I realized, though.
19:11 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:14 * moritz_ had done a bit of the usual here-and-there
19:14 masak moritz_++
19:14 moritz_ s/had/has/
19:15 moritz_ apart from that, $lack-of-tuits
19:15 colomon moritz_++ # for the lovely regex implementation of the palindrome finder
19:15 masak moritz_++ # for a blog post that went to reddit and didn't provoke trolling
19:17 takadonet not yet....
19:18 masak the trolls are usually first on location.
19:20 takadonet maybe they are sleeping at the switch
19:21 masak then find that timestamp and write it down somewhere.
19:22 masak I find that if we don't end this meeting soon, it's going to end by itself.
19:23 masak anyone have anything more to add?
19:23 pmichaud 0 from me :-)
19:23 moritz_ currently development seems a bit slow
19:24 moritz_ I guess it's because jnthn++ is working in a different repo, and everybody else seems to lack tuits
19:25 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
19:25 colomon I spent too much time celebrating my birthday.  :)
19:25 masak (mberends' car)++ may have 220V electricity, but it's hardly an ideal hacking environment. neither are planes, trains, or buses.
19:25 colomon errr, and playing Lacuna Expanse.
19:27 * masak has managed to fall into that time sink so far :)
19:27 * Util in Tuit crop failure
19:41 * 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
19:43 * 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?
19:44 masak 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
19:46 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:47 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.
20:01 PerlJam greetings #phasers
20:02 PerlJam colomon: what you just said!
20:04 mberends joined #phasers
20:05 sorear \o mberends
20:06 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.
20:06 sorear OOC, what's the largest program currently written in Perl 6?
20:06 masak hinges a lot on definition, methinks.
20:06 masak STD.pm6 is pretty large.
20:06 masak November is not half-small.
20:07 masak GGE is large, and runs on the latest Rakudo.
20:07 sorear mberends:
20:08 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?
20:08 masak colomon: you don't? I do. :)
20:08 masak colomon: you're mostly right, though.
20:10 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:11 mberends 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:13 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.
20:13 sorear mberends: sure.  I've already been doing a lot of looking myself - do you have any pointers?
20:13 mberends sorear: is that a kind of "walking the stack" problem?
20:14 sorear Yes
20:15 mberends first idea: http://llvm.org/docs/LangRef.html#i_unwind
20:18 mberends no, that's probably not suitable. You want to read the stack, not goto where it is pointing.
20:23 mberends ENOJNTHN?  I'm closing in on a 6model/java bug by old fashioned print and crash, but could do with debugging tips.
20:34 mberends 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 http://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 mberends *an array
20:35 sorear mberends: that's not quite what I mean
20:35 sorear mberends: the stack parser is going to be asm
20:35 sorear mberends: however, I need to know how llvm has layed out the stack
20:35 sorear basically, I need the ability to hook into .eh_frame generation and spit out a different kind of table
20:36 sorear one that, for instance, knows that $*FOO is stored at CFA+16 in this frame
20:39 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:43 mberends there are other calling conventions available, but C style is the default.
20:43 sorear A calling convention is a local thing.
20:44 sorear It allows you to pass arguments and get return values.
20:44 sorear It does not allow you to peek at the local variables of a frame 10 levels up
20:44 sorear Or even, for that matter, to find out if there *is* a frame 10 levels up
20:44 sorear Debuggers face the same problem, and they need compiler support
20:45 sorear LLVM generates a .eh_frame section containing frame parse information for use by gdb
20:52 jnthn Hi folks, sorry I missed #phasers. Unexpectedly got invited out.
20:52 sorear Hi jnthn.
20:53 jnthn Sadly, not a great deal more energy than last night. D'oh.
20:53 jnthn o/ sorear
21:08 mberends o/ jnthn: now packing for drive to Ljubljana :)
21:08 jnthn Whoa, that's a LONG drive!
21:09 mberends nearer than Bratislava (only just)
21:10 jnthn Really?
21:10 jnthn I'd have had it as further.
21:10 jnthn But not by that much either.
21:10 mberends ok, quite similar
21:14 mberends 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:15 jnthn mberends: The setting makes one and returns it.
21:20 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:23 jnthn mberends: I was more meaning the one that NQPSetting.cs returns
21:23 jnthn But wait, is it blowing up inside there?
21:23 jnthn Maybe check the bit of code that handles copying the static lexpad entries into the dynamic one.
21:24 jnthn That would be an easy way for things to be wrong, if it's not doing that.
21:24 jnthn I think it's in Context.[cs|java] off hand...
21:25 jnthn Just gonna go prepare bits I need for $dayjob tomorrow while I'm still lucid enough :-)
21:25 jnthn bbs
21:32 mberends jnthn: thanks for the suggestions, will try that later. packing &
21:34 masak left #phasers

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