Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-08-30

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

All times shown according to UTC.

Time Nick Message
00:34 colomon joined #moarvm
00:39 diakopter FROGGS: ping
00:46 jnap joined #moarvm
01:07 dalek MoarVM: 653ce49 | diakopter++ | / (2 files):
01:07 dalek MoarVM: tabs to spaces and more compact trace format
01:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/653ce49abf
01:15 FROGGS joined #moarvm
02:01 foo_bar_baz joined #moarvm
02:23 JimmyZ .tell jnthn I doubt the gc bug are from compose in P6opaque.c, compose update st->size dynamically .
02:23 yoleaux JimmyZ: I'll pass your message to jnthn.
02:31 JimmyZ .tell jnthn which may be set wrongly, and cause the pointer offset wrongly
02:31 yoleaux JimmyZ: I'll pass your message to jnthn.
02:40 JimmyZ .tell jnthn I see nqp/parrot have spec.align, and MoarVM doesn't, Does MoarVM need it?
02:40 yoleaux JimmyZ: I'll pass your message to jnthn.
02:45 FROGGS joined #moarvm
02:46 diakopter JimmyZ: I'm working on moving size to the MVMCollectable header, and making it per-object essentially
02:47 JimmyZ diakopter: oh
02:47 JimmyZ diakopter++
02:47 diakopter (which is what I thought jnthn said he wanted)
02:49 diakopter .. I don't understand how objects with the same STable can have different sizes
02:52 JimmyZ I can see the evil is from P6opaque
02:52 diakopter UM.
02:52 diakopter W.
02:52 diakopter T.
02:52 diakopter F.
02:53 diakopter oh.  nm.
02:55 diakopter so.. compose can be called again on a single object? or on a type only
02:55 * JimmyZ is not sure
03:00 diakopter bah...
03:00 diakopter I give up....
03:01 * JimmyZ is not good at arithmetic
03:02 diakopter whee.  nqp.moarvm gives parse errors.. :)
03:02 diakopter C:\Users\mwilson\src\MoarVM\nqp-cc>..\moarvm nqp.moarvm -e ";"
03:02 diakopter Confused at line 2, near ";"
03:02 diakopter panic
03:04 JimmyZ meant that it doesn't trig P6opaque yet :P
03:04 diakopter 2nd gc you mean
03:05 JimmyZ yeah, and 2nd gc
03:22 diakopter well it definitely hit P6opaque a lot b/c much of the nqp compiler ran
03:22 diakopter well, this is encouraging - that same invocation above takes 49ms or less
03:23 diakopter but parrot nqp it takes 77ms
03:23 diakopter (to hit the identical parse error)
03:23 JimmyZ :)
03:23 diakopter well, 64ms.
03:24 diakopter and parrot is generating the stack trace but moarvm isn't
03:24 diakopter so, meh.
04:53 FROGGS joined #moarvm
05:21 benabik joined #moarvm
06:02 JimmyZ hmm, I found threads.t hangs because the loop in finish_gc() can't be broken
06:12 not_gerd joined #moarvm
06:12 not_gerd o/
06:16 JimmyZ \o
06:20 TimToady $ ../moarvm nqp.moarvm -e 'foo:'
06:20 TimToady Could not locate compile-time value for symbol foo
06:20 TimToady frame_name_162
06:21 TimToady $ ../moarvm nqp.moarvm -e 'my $x;'
06:21 TimToady Redeclaration of symbol $x at line 2, near ";"
06:21 TimToady panic
06:21 TimToady looks like progress :)
06:21 JimmyZ :)
06:22 JimmyZ well, nqp.moarvm eats memory, about 15M here
06:45 diakopter JimmyZ: 15M?
06:45 diakopter that's..... miniscule... parrot nqp uses 350MB
06:48 FROGGS joined #moarvm
06:49 JimmyZ diakopter: ./npq eats 30M here
06:50 JimmyZ ./nqp
07:15 dalek MoarVM/nativecall: 9510d6f | (Gerhard R)++ | src/6model/reprs/CStr.c:
07:15 dalek MoarVM/nativecall: Make CStr.c compile with dummy set_str()
07:15 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/9510d6fe1b
07:16 FROGGS diakopter: pong
07:44 dalek MoarVM/nativecall: ebb6b62 | (Gerhard R)++ | src/6model/reprs/ (4 files):
07:44 dalek MoarVM/nativecall: More bits and pieces, mostly search and replace
07:44 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/ebb6b62f42
07:44 not_gerd bye, #moarvm
07:44 not_gerd left #moarvm
08:23 nwc10 jnthn: do you need to store the *byte* size of objects? In that, are there any objects that have sizes which are not multiples of 4 bytes? Or "the pointer size"?
08:31 donaldh joined #moarvm
08:39 jnthn nwc10: Unlikely. But I'll go with byte size for now.
08:42 jnthn JimmyZ, diakopter: The problem is that mixing in causes a change of type, causing an object to point to a different STable than the one it did at the point of allocation, so now the size of the allocated memory and the size in the STable are out of sync.
08:43 JimmyZ jnthn: Does MoarVM need spec.align ?
08:44 jnthn JimmyZ: At some point, yes
08:44 jnthn JimmyZ: Not until we get to int32/int16/int8
08:44 jnthn etc.
08:44 JimmyZ thanks
08:52 donaldh joined #moarvm
08:55 donaldh joined #moarvm
09:56 diakopter jnthn: oh yeah...
09:56 diakopter you *did* say that.. but I forgot... :S
10:20 grondilu joined #moarvm
11:26 diakopter jnthn: so will STable still have a "default size" member on its struct?
11:38 cognominal joined #moarvm
11:38 jnthn diakopter: I'm planning to leave that, yes, so allocation will just copy that value into the collectable header.
11:38 jnthn diakopter: Planning to work on it soon-ish...
11:39 jnthn diakopter: Unless you already started on it?
11:51 jnap joined #moarvm
12:07 diakopter jnthn: heh... started but then reset hard
12:08 jnthn .oO( reset hard with a vengence )
12:10 diakopter I was making it more complicated than it needed to be
12:11 jnthn It should involve patches to around 3 or 4 files I expect.
12:12 jnthn (6model.h to change flags to 16 bits and add the 16 bit size field, allocate.c to make sure the size is always written from the STable, collect.c to use the object header size)
12:30 diakopter yeah
13:24 dalek MoarVM/nativecall: 9e20546 | (Gerhard R)++ | src/6model/reprs/C (2 files):
13:24 dalek MoarVM/nativecall: Use *Body structures to determine storage bits and align
13:24 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/9e205461a5
13:24 dalek MoarVM/nativecall: edc2519 | (Gerhard R)++ | build/Makefile.in:
13:24 dalek MoarVM/nativecall: Add dyncall to header search path
13:24 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/edc2519ce0
13:24 dalek MoarVM/nativecall: 1f2b97b | (Gerhard R)++ | src/6model/reprs/NativeCall. (2 files):
13:24 dalek MoarVM/nativecall: Make NativeCall.o compile
13:24 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/1f2b97b800
14:27 JimmyZ hmm, libuv use stdint also on posix
15:09 cognominal joined #moarvm
15:11 JimmyZ not_gerd: Do you mind to merge warnings branch?
15:12 jnthn What does the branch do?
15:12 jnthn Add a target that gives us more warnings to the Makefile?
15:13 FROGGS joined #moarvm
15:14 JimmyZ jnthn: nope, just avoids some wanings
15:14 JimmyZ *warning
15:15 JimmyZ jnthn: https://github.com/MoarVM/Moa​rVM/compare/master...warnings for a quick review
15:16 jnthn (void)data, (void)class_handle, (void)name, (void)hint;
15:16 jnthn *grmbl*
15:16 jnthn Can we not just disable that warning... :/
15:16 jnthn Also, is that portable?
15:17 jnthn Either way, an UNUSED(data, class_handle, name, hint); macro would be better...
15:17 jnthn Mostly, I just find such things noise, though.
15:18 JimmyZ linenoise use: #define __NOTUSED(V) ((void) V)
15:19 JimmyZ so should portable, and parrot uses it aslo
15:19 JimmyZ *also
15:26 nwc10 perl 5 uses it also
15:26 nwc10 I'd trust perl 5 to be a lot more portable than linenoise, and more portable than parrot
15:26 JimmyZ ;)
15:27 nwc10 although possibly too portable (ie to platforms that MoarVM will never end up targetting)
15:27 FROGGS blasphemy!
15:27 nwc10 well, for starters I don't have access to any suitably old Crays
15:27 nwc10 IRIX and Tru64 are about to be end of life
15:28 nwc10 etc
15:28 JimmyZ BEOS
15:28 JimmyZ Does Perl5 have a JIT?
15:29 FROGGS the main target would be linux, osx, windows, and someday maybe android and similars
15:29 FROGGS ohh, bsd of course too
15:29 JimmyZ android shouldn't be hard, since libuv supports it
15:30 FROGGS well, performance wise it is hard
15:31 nwc10 No. I think trying to write a JIT for Perl 5 would be even less successful than trying to write a JIT for Parrot
15:31 nwc10 Solaris, AIX and HP-UX aren't dead
15:31 nwc10 Although HP might be working on self destruction.
15:32 FROGGS true
15:33 nwc10 Solaris is safe as long as it helps pay for Larry Ellison's yachts
15:33 FROGGS I even have a opensolaris box somewhere...
15:33 nwc10 Sparc or x86_64?
15:33 JimmyZ I think trying to write a JIT for Parrot would be even less successful than trying to write a JIT for MoarVM :P
15:35 nwc10 I think that it ended up being documented somewhere that the problem with Parrot's JIT was that while it could do good work on code that comprised of simple OPs
15:35 nwc10 as soon as code was made of OPs that had to call vtable routines to get into C
15:35 nwc10 then it was crossing back and forth across the Parrot<->C boundary
15:36 nwc10 and couldn't really do much better than generating code which was a sucession of method calls
15:36 nwc10 hence why the Lorito plan came along - to replace a lot of the opaque (ro the JIT) C code with a way of implementing most of it in something that a JIT could understand
15:38 JimmyZ I doubt M0 won't be better. since it goes into another extreme
15:39 JimmyZ well m0 will end up a bit like lua though
15:39 nwc10 M0 was proposed in 2011, and hasn't got very far
15:45 nwc10 and I suspect that it's more than just the NSA watching this channel (oh, and GCHQ), but I think I'll still post this: https://www.ohloh.net/p/parrot/commits/summary
15:46 nwc10 Parrot hasn't been very active recently, and if it doesn't show an uptick, I doubt that M0 will progress from where it currently is
16:00 not_gerd joined #moarvm
16:00 not_gerd o/
16:00 diakopter not_gerd: speaking of m0..
16:01 not_gerd ;)
16:01 JimmyZ not_gerd: \0
16:02 JimmyZ not_gerd: Do you mind to merge warnings branch?
16:02 not_gerd I never quite understood how m0 would magically solve most of parrots problems
16:02 not_gerd (which is why I lost interest)
16:02 JimmyZ not_gerd: consider m0 is just another lua with CPS
16:03 not_gerd jnthn: casting to void is the idiomatic C way so silence unused warnings
16:03 not_gerd (be it parameters, local vars, return values)
16:04 not_gerd C programmers will probably recognize it
16:04 not_gerd JimmyZ: I did not merge warnings yet because we need to do some decision-making on signed vs unsigned for some things
16:05 JimmyZ ok, when we got the decision :-)
16:05 not_gerd some things are unsigned, some things like indices are signed and check for non-negative
16:06 not_gerd then, do we use signed or unsigned for our bool-equivalent?
16:07 JimmyZ speaking of parrot, they have 100+ branches, and never got the decision
16:07 odc _Bool is not portable?
16:07 not_gerd odc: microsoft :(
16:07 odc aha
16:07 not_gerd though they did recently decide to implemented some more of C99
16:08 odc then i vote int
16:08 jnthn Well, more importantly, the nqp::op set doesn't have a separate notion of bool
16:08 jnthn It uses (signed) integers in that place
16:08 jnthn So it makes sense to follow that.
16:08 odc i see
16:08 nwc10 beware of picking a not-a-bool type that is smaller than some of the things (ie expressions) that you are trying to assign to it
16:09 nwc10 in case interesting flag bits fall off the top, and you always have "False"
16:09 not_gerd so I guess changing exists_key to return int64 instead of uint64 was the right call ;I
16:09 jnthn I'd say so
16:09 not_gerd nwc10: that's why _Bool was introduced
16:09 TimToady a uint1 fits nicely into either int64 or uint64 :)
16:10 JimmyZ so goes with uint1? :P
16:11 TimToady well, that's my view, but you'll have to argue with C to get it to have the same view :)
16:12 not_gerd typedef _Bool uint1;
16:12 not_gerd [x] done
16:12 TimToady :D
16:14 JimmyZ btw: I'm +1 to merge ctypes also :P
16:14 odc but nwc10 says 1 bit is not enough :x
16:15 nwc10 no, I didn't say *that*. I said that emulating the real C99 bool type with an integer is risky if you don't take care
16:15 TimToady that's because C has braneded coercion semantics
16:15 nwc10 well, I wasn't clear that that was what I said
16:17 TimToady at least p6 has some different ideas about the right way to turn multiple bits into one bit :)
16:17 odc ok
16:17 TimToady but I realize talking about p6 is actually OT here :)
16:18 jnthn :P
16:18 TimToady where OT might mean Occupational Therapy...
16:19 jnthn I think it's on-topic enough that I want to keep using the MVMint32 typenames, though :)
16:19 jnthn Rather than adopting the C ones, so then I have to remember the Perl 6 names and the C names...
16:19 not_gerd well, we don't on the JVM, so there's prior art for not using them as well ;)
16:19 jnthn I woulda if I coulda :P
16:20 jnthn Java isn't exactly a language of choice :)
16:20 TimToady Java is a language of choice--it's just a bad choice...
16:21 jnthn Well, I was more meaning "doesn't give you much choice about anything", but there is that... :)
16:28 not_gerd another thing I've been thinking about is opcode reorganization
16:29 not_gerd I'd like to collapse them into 4 banks and remove the double-indirection from the first one
16:29 not_gerd a flat 16-bit space would probably be better for dispatch
16:29 not_gerd keeping common ops in an 8-bit space is better for bytecode size, though
16:29 jnthn not_gerd: I've been pondering tossing the banks
16:29 jnthn not_gerd: They don't serve much purpose any more.
16:30 jnthn not_gerd: So then we'd have a single flat space.
16:30 not_gerd well, in the scheme I'm proposing they would serve to lose 1 byte in case of the primitive bank
16:31 jnthn huh...
16:32 not_gerd primitive ops would take 1 byte, ops from the other banks 2 and ext ops whatever they're supposed to use (3?)
16:32 jnthn That sounds like an unrequired complication...
16:32 not_gerd jnthn: could be more cache friendly
16:33 not_gerd no idea if it's significant, but such things can be measured ;)
16:33 jnthn It could be, otoh it's probably less alignment friendly...
16:35 not_gerd does x86 care for 2-byte alignment?
16:35 not_gerd 4, 8 (and 16 in case of x64) are the important boundaries
16:36 jnthn I don't think it cares in so far as "will refuse to do it", but efficiency is another matter..
16:37 not_gerd jnthn: well, you can make it care
16:37 not_gerd and mms needs proper alignment
16:37 not_gerd (did some inline asm and it was a pain to get those floats aligned right...)
16:38 not_gerd but I was thinking about whether it's more efficient to ne misaligned by 2 than by 1 or 3 bytes
16:38 not_gerd *s/ne/be/
16:39 nwc10 I think that modern (ie after my time) ARM CPUs can do 16 bit loads more efficiently if 2 byte aligned
16:41 * TimToady bets his shorts on it...
16:44 not_gerd so, make int16 the unit of our 'byte'-code?
16:45 * nwc10 has a long long way to go before he gets good at these puns
16:46 TimToady double your pleasure, double your pun...
16:46 nwc10 some are hard to a-void
16:46 * TimToady would float the notion that a simpler solution is probably better in the absence of evidence to the contrary
16:47 not_gerd less complex is a real win
16:47 TimToady that's just how it struct me
16:49 jnthn not_gerd: I'm fine with a patch to remove banks.
16:50 jnthn not_gerd: I'm less convinced/comfortable with the 1/2/3 byte variable-length ops.
16:50 not_gerd jnthn: think of it as 1-byte ops with the 2-byte one taking another 1-byte argument
16:51 not_gerd but there are arguments for 16-bit ops as well
16:51 JimmyZ I'd like to remove banks also :P
16:51 TimToady otoh, with 16-bit ops, you can do some analysis and add a few 16-bit ops that just happen to do two common operations
16:51 not_gerd the computed goto dispatch would like a flat op space, for what it's worth
16:52 TimToady any given architecture is probably going to be optimized for fetching instructions of a particular size, which may or may not map to fetching data of that size
16:53 diakopter the number of opcode instructions is small compared to the rest of the bytecode (operands)
16:53 nwc10 IIRC C compilers were getting upset with trying to dispatch of-the-order-of 65536 things. Of-the-order of 256 is fine
16:54 nwc10 so a flat space may hurt for different reasons
16:54 nwc10 or C compilers may be better now than 5-10 years ago
16:54 TimToady one can hope
16:54 TimToady one can also assume another increment of progress over the next 5-10 years
16:55 not_gerd it's not as if there's no prior art for variable-length op sets, though
16:56 diakopter I agree with jnthn that's it's a complication unneeded atm
16:57 not_gerd I assume we want a dense opcode set?
16:57 FROGGS diakopter: seen my /msg ?
16:58 TimToady dense is likelier to turn into a jumptable in C
16:59 TimToady otoh dense makes it difficult to keep related opcodes together as you add new ones, if you want to keep backcompat
16:59 TimToady not sure keeping them close is worth much though
16:59 diakopter not sure backcompat is worth much
17:00 not_gerd how much has the nqp op set changed over time?
17:00 not_gerd (after 6model, taht is)
17:00 diakopter added many tens
17:00 diakopter if not hundreds
17:04 TimToady mostly you need a version number, so you can remap if necessary
17:04 jnthn dinner, bbiab
17:05 JimmyZ re ctypes, we can #define MVMint32 int32_t :P
17:05 diakopter the opset is quite arbitrary.. it's just driven by discrete needs of the compiler.. if an activity can be factored into an op, it is, so it doesn't have to be compiled to lots of ops, while you're writing the compiler. it's just a way of adding runtime calls; it doesn't really map to a "language"... many of the opcodes will cause millions of cpu instructions to run, each
17:08 JimmyZ jnthn: re ctypes, we can #define MVMint32 int32_t :P
17:08 colomon joined #moarvm
17:10 diakopter not_gerd: did you find the irclogs where jnthn and I talked about nativecall type composition?
17:10 diakopter hmm, I may have "sent" those messages when yoleaux wasn't actually here
17:10 dalek joined #moarvm
17:11 diakopter those messages = where I said you should look for that chat log
17:13 not_gerd diakopter: I saw them
17:13 not_gerd the way I'm going about right now is fix the easy stuff and make it compile
17:13 not_gerd then revisit and get it right
17:14 diakopter <- same for serialization
17:16 diakopter TimToady: the bytecode format had a version number from the start
17:16 diakopter I think it started at 667
17:16 diakopter (kidding)
17:24 not_gerd any objections to promoting MVMStorageSpec.bits to 32-bit?
17:24 jnthn not_gerd: Any reason to do so?
17:24 jnthn not_gerd: That thing gets passed by value, so keeping it compact is nice :)
17:25 not_gerd jnthn: 64k should be enought for anyone?
17:25 not_gerd (actually, only 8k)
17:25 jnthn not_gerd: Given it's used for inlining native types into the bodies of opaques... :)
17:26 not_gerd jnthn: so we don't support inlining structures?
17:26 jnthn not_gerd: Not yet.
17:26 not_gerd well, do we want to?
17:26 jnthn not_gerd: I guess at some point arrays of compact structs may want to do that.
17:27 not_gerd then 8k might become an issue
17:27 not_gerd why bits and not bytes, btw?
17:27 not_gerd bitfield support planned as well?
17:27 jnthn int1, int2, etc.
17:27 jnthn VMArray can store those as bitfields, potentially.
17:28 not_gerd would it make sense to distinguish between bit size and byte size?
17:28 not_gerd (thinking of long double)
17:28 not_gerd (or 21-bit unicide chars)
17:29 not_gerd *unicode
17:29 jnthn Not really, I don't think; it's a statement of need from the thing it's inlined into, not a demand for compactness.
17:31 not_gerd so 80-bit long double ands up with bits 96 on x86 and 128 on x64 as this is the storage they need to be correctly aligned
17:31 not_gerd whereas uint1 would get a value of 1?
17:32 not_gerd (just trying to figure out the edge cases)
17:34 not_gerd or should long double get 80 bits and we then rouhd up to the correct multiple of align?
17:35 not_gerd that would probably be the most correct one, semantically
17:36 jnthn There's (meant to be) an alignment thing in the storage spec also, which should be enough to convey this?
17:36 jnthn Or did I miss a detail?
17:38 not_gerd jnthn: well, I re-added it
17:38 not_gerd there are 3 different, but related quantities: bit width, byte size and byte alignment
17:38 not_gerd you can get the byte size from the other 2
17:40 not_gerd so I guess we're good to go
17:40 jnthn \o/
17:40 jnthn diakopter: Did you get anywhere with the object size thing?
18:11 not_gerd jnthn: should I just add https://gist.github.com/gerdr/882309b6203f14120473 to 6model.h?
18:18 diakopter jnthn: nope
18:19 dalek MoarVM/nativecall: 5471a7e | (Gerhard R)++ | src/6model/6model.h:
18:19 dalek MoarVM/nativecall: Add MVM_STORAGE_SPEC_BYTES() - we're going to need it
18:19 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/5471a7e7b2
18:20 jnthn not_gerd: wfm
18:21 jnthn diakopter: ok, I take it
18:22 diakopter ok
18:32 arnsholt not_gerd++ # NativeCall!
18:33 TimToady now if we could only get the non-native calls working... :P
18:35 diakopter they keep dropping when hopping
18:38 diakopter jnthn: remind me again what we said about p5 packages and how they'd know how to respond to .Str and such
18:38 diakopter it has escaped me.
18:38 diakopter again.
18:38 diakopter I'm writing it down this time, I promise
18:39 jnthn Dammit, I can't remember either :/
18:39 diakopter hm, maybe I'll search the log for .Str
18:39 jnthn Was it just that Perl 5 types would have a meta-object that made them look sufficiencly like Perl 6 types?
18:39 jnthn Just like we do for Java types?
18:40 jnthn So they pretend to be ~~ Any
18:40 diakopter here it is
18:40 diakopter yeah but that just pushes it down a level
18:40 diakopter something has to set up the mappings
18:41 diakopter http://irclog.perlgeek.de/m​oarvm/2013-07-19#i_7348711  ff.
18:59 diakopter jnthn: u see that?
18:59 diakopter I'm hoping to discuss/review it sumoar
19:01 arnsholt diakopter, not_gerd: I'm working on a simple test file for native call functionality, ATM. Hoping to have it done tonight or tomorrow
19:02 not_gerd arnsholt++
19:03 arnsholt 'Cuz I need it too, for the JVM stuff
19:04 arnsholt My general idea is using that file to get the basics running, then using the NativeCall test suite to get the rest working once the basics are done
19:09 FROGGS joined #moarvm
19:59 dalek MoarVM/nativecall: 55df863 | (Gerhard R)++ | / (4 files):
19:59 dalek MoarVM/nativecall: Import Parrot's ops/nqp_dyncall.ops as core/nativecall.c
19:59 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/55df86351d
19:59 dalek MoarVM/nativecall: f7e74e9 | (Gerhard R)++ | src/6model/reprs/C (4 files):
19:59 dalek MoarVM/nativecall: More bits and pieces
19:59 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/f7e74e9a7d
20:00 not_gerd bye, #moarvm
20:00 not_gerd left #moarvm
20:03 diakopter r: not_gerd++
20:03 diakopter gerd++
20:03 diakopter er.
20:03 diakopter why did I prefix that with r:
20:04 * jnthn back
20:04 diakopter jnthn: pending question to you ^
20:04 diakopter er, request
20:05 * jnthn looks at the clog
20:06 jnthn (that you linked)
20:06 diakopter in Oppressive Regime, ir clogs you
20:08 diakopter jnthn: esp don't miss 23:26FF
20:08 diakopter ff
20:10 jnthn Hmm
20:10 jnthn Grr, hard problems are hard :)
20:12 diakopter well we've already got CPS, of sorts since the current/return/next frame is accessible from tc
20:12 jnthn Yeah
20:12 jnthn Well, we use that for smart_stringify already
20:12 * diakopter has forgotten
20:13 jnthn It's possible that "" stringification of a Perl 6 thing from Perl 5 wants to use very similar semantics to that...
20:13 diakopter yeah, but...
20:14 jnthn It's just that we're not in a Moar runloop at that point, probably...
20:14 diakopter that means many many more ops need to become non-local returning possibly
20:14 jnthn How so?
20:14 diakopter hrm.
20:15 jnthn I think we discussed that $p6-thing . $p6-thing in Perl 5 would just be two coercions to string and then the default Perl 5 . for example...
20:20 diakopter ?
20:21 diakopter p5 operations on p6 objects aren't the problem - the other way is
20:22 diakopter well
20:23 diakopter my brain is need fried food
20:27 lizmat you are what you eats
20:46 jnthn diakopter: It was just those 3 files needing changes :)
20:48 jnthn diakopter++ # backtrace better
20:49 dalek MoarVM: 8b04b25 | jnthn++ | src/6model/6model.h:
20:49 dalek MoarVM: Add per-object size to MVMCollectable.
20:49 dalek MoarVM:
20:49 dalek MoarVM: Not yet used for anything.
20:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8b04b25a8e
20:49 dalek MoarVM: f0766e0 | jnthn++ | src/gc/allocation.c:
20:49 dalek MoarVM: Start recording collectable size in header.
20:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f0766e0c5f
20:49 dalek MoarVM: 9e0d1e4 | jnthn++ | src/gc/collect.c:
20:49 dalek MoarVM: Use per-object size in GC.
20:49 dalek MoarVM:
20:49 dalek MoarVM: Turns out to lead to simpler code as well as being more correct.
20:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9e0d1e4790
20:51 * jnthn is happy when a change like that turns out effortless 'cus stuff is factored into the right places...
20:56 FROGGS there is nothing better than a good design
20:56 FROGGS designer(s)*, even
20:59 diakopter so.. what's the next blocker
20:59 jnthn a skype call, bbs
21:01 * diakopter is tickled to imagine jnthn trying to explain to the rakudo class the finer points of the qast->mast
21:25 FROGGS nqp nqp.moarvm -e '1'
21:25 FROGGS Error while reading from file: Malformed UTF-8 string
21:26 FROGGS $ ../moarvm nqp.moarvm -e '1'
21:26 FROGGS Too many positional arguments; max 1, got 4
21:26 FROGGS please ignore the first one :o)
21:27 FROGGS diakopter: that `max 1, got 4` is that about the void thing?
21:27 FROGGS void op*
21:38 dalek MoarVM: 4a62522 | jnthn++ | nqp-cc/tools/build/moarqast.pl:
21:38 dalek MoarVM: QAST -> MAST needs NQPHLL for lineof.
21:38 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4a62522322
21:55 dalek MoarVM: e839e37 | jnthn++ | nqp-cc/tools/build/Makefile.in:
21:55 dalek MoarVM: Missing Makefile dependency.
21:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e839e370eb
21:55 dalek MoarVM: 100dcc6 | jnthn++ | nqp-cc/src/QASTCompilerMAST.nqp:
21:55 dalek MoarVM: Missing null check.
21:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/100dcc6bac
21:56 jnthn C:\consulting\MoarVM\nqp-cc>..\moarvm.exe nqp.moarvm -e "say(42)"
21:56 jnthn mbc NYI
21:56 jnthn \o/
21:57 jnthn This means that it manages to create a MAST tree.
21:58 jnthn Now I "just" need to write up MAST => bytecode, and invoking of the result.
23:01 BenGoldberg joined #moarvm
23:01 BenGoldberg left #moarvm

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