Camelia, the Perl 6 bug

IRC log for #moe, 2013-03-04

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

All times shown according to UTC.

Time Nick Message
02:22 hiratara joined #moe
05:41 hiratara joined #moe
13:24 hiratara joined #moe
14:16 bphillips1 what's the distinction between things like org.moe.runtime.builtins.ArrayClass and org.moe.runtime.nativeobjects.MoeArrayObject ?  What stuff goes where?
14:17 gizmomathboy_ joined #moe
14:19 stevan_ bphillips1: MoeArrayObject is a wrapped Scala object
14:20 stevan_ ArrayClass is actually an instance of MoeClass that provides the runtime access to MoeArrayObject
14:21 stevan_ bphillips1: as for what goes where, I think MoeHashObject and HashObject are the best examples
14:21 stevan_ and the Int and Num stuff as well
14:21 stevan_ ideally the bulk of the work should go into the nativeobjects.Moe*Object
14:21 stevan_ cause it is more easy to test
14:22 stevan_ and the builtins.*Class should just be a thin shim
14:22 bphillips right, I was noticing that MoeArrayObject is very small compared to MoeHashObject
14:23 bphillips so I was thinking that might be an easy way to add some simple methods to operate on arrays, but then I saw "shift" was implemented in the ArrayClass file
14:23 bphillips is that the distinction between shift(@array) vs. @array.shift ?
14:23 bphillips (ArrayClass vs. MoeArrayObject respectively)
14:24 stevan_ no, shift(@array) will just be re-written at @array->shift
14:24 stevan_ yeah MoeArrayObject would be a nice low hanging fruit
14:24 stevan_ though be warned, I think the List[] representation might not be suitable in the long run
14:25 bphillips right, I was discovering that as well (seems to be fairly immutable)
14:25 jnap joined #moe
14:25 stevan_ yeah, I haven't yet dug deeply enough into the Scala collections to know which is best, but ArrayBuffer looked to have promise
14:27 stevan_ actually shift in ArrayClass is totally wrong
14:27 stevan_ it only fetches the value, and doesn't change the underlying list
14:27 stevan_ I suspect I added that for a test in the REPL and then forgot to go back and fix it
14:53 am0c joined #moe
14:58 masak hi! how's everything going?
14:58 masak (a seriously meant question. also, meta-ly, is there a way to find out the current status of moe?)
15:02 stevan_ masak: its going okay actually, slowly but surely
15:02 stevan_ I should update the status document though, just haven't been
15:02 * masak encourages stevan_ to do so :>
15:03 masak stevan_++
15:03 masak everyone++
15:03 masak I know moe is "just" an experiment at this point.
15:03 masak but it makes me happy, hopeful, and expectant.
15:04 stevan_ I am still focusing heavily on the runtime, specifically the nativeobjects and attaching them to the runtime
15:04 stevan_ the AST needs a handful of nodes and the parser needs a lot of work
15:08 masak how much is your AST work inspired by QAST?
15:08 masak in my view, that's well worth looking at.
15:09 jasonmay is that a part of NQP?
15:10 bluescreen joined #moe
15:10 masak yes. it was designed last year.
15:10 jasonmay https://github.com/perl6/nqp/tree/master/src/QAST is the gist of it?
15:11 doy stevan_: yes, ArrayBuffer is almost certainly what you want
15:11 masak jasonmay: yes. pay special attention to Compiler.pm and Operations.pm
15:11 stevan_ masak: so initially none
15:11 doy although it'd be nice if we could do some level of analysis to see when switching to a different data structure might be helpful
15:11 bphillips doy: do you mean ArrayBuffer or ListBuffer?
15:12 doy bphillips: i mean ArrayBuffer
15:13 stevan_ masak: i would like to understand QAST better
15:13 stevan_ cause it is not intuitive to me
15:14 masak stevan_: I may give some guidance, but not all of it. pmichaud and jnthn are the ones to talk to.
15:14 jnap joined #moe
15:14 stevan_ yeah
15:14 masak stevan_: what amazes me is how few node types QAST gets away with defining.
15:14 stevan_ yeah, that is what worries me
15:14 masak much fewer than my intuition tells me are needed.
15:14 masak pmichaud basically evolved that design and it works very well for us.
15:15 stevan_ I wonder how much of that is unique to Parrott/Rakudo
15:15 masak jnthn added one node type last year for VM-independence.
15:15 masak but that's all.
15:15 stevan_ our AST is much more closely mapped to the language itself
15:15 masak yeah, there is that.
15:15 masak but I don't think QAST is very tied to Perl 6 at all.
15:15 masak it's just an AST format for HLLs.
15:16 stevan_ yeah
15:16 stevan_ I will make a note to myself to study it more closely
15:17 stevan_ as I said, my focus is on the runtime, I like to design bottom up
15:17 bluescreen_ joined #moe
15:19 PerlJam masak++ stevan++
15:20 masak stevan_: that makes sense.
17:08 chansen joined #moe
19:32 jnap joined #moe
20:25 bphillips1 joined #moe
20:55 moe [moe] brianphillips opened pull request #66: native MoeArrayObject methods (master...arraybuffer-for-arrays)  http://git.io/x1__fw
21:12 moe [moe] stevan pushed 12 new commits to master: http://git.io/-8Eq1Q
21:12 moe moe/master 840b83f Brian Phillips: replace List with ArrayBuffer for MoeArrayObject...
21:12 moe moe/master a8d8f48 Brian Phillips: array length method + tests
21:12 moe moe/master e2cdc94 Brian Phillips: add "clear" method for arrays
21:12 bphillips1 stevan_: did that look reasonable?
21:13 stevan_ bphillips: yes, its been merged :)
21:13 stevan_ some of that if (array.length == ...) stuff might be replaceable with array.get(i).getOrElse(...)
21:14 stevan_ but I don't know if ArrayBuffer supports that kind of get()
21:14 stevan_ but thats workable later on
21:14 bphillips yeah, I have a long way to go when it comes to scala idioms I'm sure
21:17 bphillips another thing I wasn't entirely sure of: should the methods that take an optional list of items (i.e. push, unshift) use a varargs type signature, or just require a List (possibly 0-length) to be passed in?
21:18 bphillips i.e. https://github.com/MoeOrganization/moe/c​ompare/51b22fa03f9c...7707d0f72e56#L3R39
21:19 stevan_ so I am doing that right here
21:19 stevan_ https://github.com/MoeOrganization/moe/b​lob/master/src/main/scala/org/moe/runtim​e/nativeobjects/MoeStrObject.scala#L49
21:19 stevan_ in MoeStrObject
21:19 stevan_ but I am not sure that is correct, the proper version is varargs
21:19 stevan_ which the runtime doesn't yet support
21:20 stevan_ so for now we can just stick with a single item, and once i add varargs to the Signature and decide how to represent them, we can switch
21:28 am0c joined #moe
21:34 jnap1 joined #moe
22:35 bphillips is there anything in the runtime that represents a code ref yet?
22:36 bphillips MoeCode?
22:56 stevan_ nope
22:56 stevan_ was thinking about that this weekend actually
23:05 gizmomathboy joined #moe
23:12 jnap joined #moe
23:40 bphillips1 joined #moe

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