github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 8 September 2013.
01:16 tokuhirom joined 03:25 cognominal joined 04:42 Woodi joined
diakopter 7 05:00
tokuhirom: how goes
tokuhirom hm? 05:01
yoleaux 27 Aug 2013 04:44Z <[Coke]> tokuhirom: how do you run a perl6 program in pvip?
tokuhirom Ah
diakopter pvip
tokuhirom It's just a parser
library.
And i'm writing transpiler from perl6 to perl5(in progress). metacpan.org/release/Seis 05:02
diakopter well, it's an implementation then, if it can compile perl6 to 5 and then run it... so [Coke] wants to add it to the test suite 05:10
er
test stuff
JimmyZ and FROGGS compile perl5 to 6 :P 05:13
diakopter no 05:16
his software compiles p5 to qast 05:18
jnthn moarning o/ 05:58
JimmyZ morning 05:59
jnthn commute... 06:07
06:36 FROGGS joined
FROGGS .tell arnsholt And we would have an awesome name! MIR :o) irclog.perlgeek.de/moarvm/2013-09-10#i_7569896 06:39
yoleaux FROGGS: I'll pass your message to arnsholt.
jnthn beans...det goda kaffet... *slurp* 06:45
06:46 Woodi joined
FROGGS Bohnen... der gute Kaffee? 06:58
jnthn If Bohnen means beans... :) 06:59
And not boning or something...
arnsholt FROGGS: Even better! =D
yoleaux 06:39Z <FROGGS> arnsholt: And we would have an awesome name! MIR :o) irclog.perlgeek.de/moarvm/2013-09-10#i_7569896
07:02 foo_bar_baz joined 07:11 LWA joined 07:29 dalek joined
JimmyZ \\o/ 09:14
FROGGS \\o/ 09:17
what's up?
JimmyZ nothing yet 09:18
FROGGS awww 09:21
09:25 not_gerd joined
not_gerd o/ 09:25
JimmyZ \\o 09:27
not_gerd jnthn: how should containers for native types be handled? 09:28
as I read it, using a ContainerSpec would require boxing...
jnthn Yeah, if you must have a container then you have to create an object.
Normally you don't need it. 09:29
not_gerd what's the best way to pull a native out of a CScalar (ie a pointer to a scalar C type)?
jnthn We don't need to worry about it in Moar for nwo 'cus it's not handled in any backend yet.
What's a CScalar? 09:30
You're doing far, far more with NativeCall than just porting what we need for the current state.
I don't have the tuits to care about this rgiht now. Sorry. 09:31
not_gerd ok
(a CScalar would be a typed pointer pointing to a primitive type)
jnthn My expectation is we'll introduce a couple of REPRs (LexRef, AttrRef) that reference native leicals and native attributes.
They'll have container specs that do the right thing, but there's a bit of missing design there 09:32
And there'll be corresponding nqp:: ops for this
When Rakudo gets to support
$native-int++;
Then the optimizer needs to (a) inline it, and (b) know that the nqp::lexref and nqp::assign_i (prelim names) can collapse into a nqp::bindlex_i 09:33
jnthn didn't get much further into the design than that, but hopes it might be enough for not_gerd to progress on what he's looking at 09:34
(by "inline it" I mean the call to postfix:<++>, just to be clear...)
For things that can't statically inline, by pushign these ops down to MoarVM level, the JIT should, after inlining, be able to perform the same style of analysis. 09:36
not_gerd sound feasible
so I'll implement the boxing container spec and add some temporary ops for native access
jnthn OK, feel free to try and flesh it out. But this is really not Moar specific, so whatever it looks like needs to be viable elsewhere too. 09:37
I don't think that shall be too problematic, though... :)
I did the last contaienrs refactor with eventually supporting this in mind. 09:38
not_gerd well, the ops will only work with the C subsystem of the 6model type system (that I'm implementing)
could be used for prototyping the general version, though 09:39
jnthn aye, we probably want to use the same mechanism for the general solution
not_gerd just to clarify what I'm doing - I implemented a malloc() wrapper that supports (pr is going to support) putting arbitrary C objects in that memory block 09:40
CScalar would be a typed pointer into that block supporting container semantics 09:41
jnthn ok, I think I see
fits with what you were asking about the gc too... :)
not_gerd first, I thought it ould be possible to inline such blocks via p6opaque 09:42
that... turned out to be unworkable as far as I can see
hm... 09:44
did I mean should, could or would there?
you decide! 09:45
jnthn Well, I guess when I decided that the GC needn't support interior pointers and would move objects, I kinda did decide :P 09:46
10:08 not_gerd joined 10:19 LWA joined 12:22 not_gerd joined
dalek arVM/nativecall2: a3c9c88 | (Gerhard R)++ | src/ (3 files):
Finish ptrcast implementation
 12:23
arVM/nativecall2: d790e18 | (Gerhard R)++ | / (10 files):
Implement cpointer op and stub cscalar
arVM/nativecall2: 177d5ba | (Gerhard R)++ | / (9 files):
Rename FlexibleStruct to FlexStruct and get rid of anon structs
arVM/nativecall2: bed5d41 | (Gerhard R)++ | src/native/ (2 files):
Work on CScalar, partially implementing ContainerSpec
MoarVM/nativecall2: f79a8d4 | (Gerhard R)++ | / (8 files):
MoarVM/nativecall2: Hack in cscalar_decont_i and int16 regs for testing
not_gerd that made gist.github.com/gerdr/02a79383788fb1254978 work 12:24
bye, #moarvm 12:29
12:29 not_gerd left 13:34 eternaleye joined 14:08 lizmat joined 14:26 jnap joined 14:59 FROGGS[mobile] joined 15:42 LWA joined 15:57 {amon} joined 16:01 FROGGS joined
dalek arVM: 177e825 | (Tobias Leich)++ | src/core/exceptions.c:
inrease/decrease frame refcounter
 16:18
arVM: aecc96d | (Tobias Leich)++ | src/core/exceptions.c:
code indentation
 16:21
16:34 LWA left
FROGGS Q: if previously something stored a function pointer somewhere, can I check against later a given funtion pointer? is that reliable? 16:38
arnsholt Depends on what you mean by function pointer, probably 16:39
If it's a C function pointer, the GC's not gonna mess with that. A Perl/NQP one, not so much
FROGGS arnsholt: this github.com/MoarVM/MoarVM/blob/mast...ons.c#L164 16:40
unwind_after_handler is declared a few lines below
arnsholt That looks like a normal C function pointer, so that's not gonna move around 16:41
FROGGS so I can do: if (unwind_after_handler == something->frame->->special_return ) ??
well, written in valid C of course 16:42
arnsholt Yeah, I'd be surprised if that doesn't work
FROGGS (excuse my wording, I had a liter Oktoberfestbeer)
k, awesome
thank you
arnsholt diakopter: That sounds reasonable, right?
FROGGS well, we'll see if it assplodes :o) 16:45
hmm, okay, seems to work fine 16:47
diakopter arnsholt: which is reasonable? 16:59
arnsholt What FROGGS asked about above 17:00
FROGGS I can paste a diff in a few minutes 17:01
arnsholt It's all pointers to functions implemented in C AFAICT, so that shouldn't be subject to GC shenanigans
FROGGS here: gist.github.com/FROGGS/d3febe484052ce8976bf 17:03
unwind_after_handler is a function 17:04
yeah, I guess this is safe 17:06
dalek arVM: 7c4ae2c | (Tobias Leich)++ | src/core/exceptions.c:
heck for already installed handler, allocate otherwise
 17:08
17:19 lizmat joined 17:32 jnap joined 19:14 colomon joined 19:38 FROGGS joined 20:05 FROGGS joined 20:31 tgt joined
diakopter .ask not_gerd ping 20:36
yoleaux diakopter: I'll pass your message to not_gerd.
20:37 tgt joined 21:02 not_gerd joined
not_gerd o/ 21:02
yoleaux 20:36Z <diakopter> not_gerd: ping
not_gerd diakopter: pong
dalek arVM/nativecall2: fac625f | (Gerhard R)++ | / (5 files):
Remove HOW argument from cscalar op - use newtype instead
arVM/nativecall2: 3b39712 | (Gerhard R)++ | / (10 files):
Cache more native type objects and fix some bugs
arVM/nativecall2: cd44f90 | (Gerhard R)++ | src/native/ (4 files):
Fix gc bits
diakopter ] >> i % 64 & 1 // C operator precedence knowledge fail on my part 21:09
not_gerd rule of thumb: bitwise and/or have low precedence - just higher than logical and/or 21:11
for arithmetics, it's multiplication/division, then addition/substraction, then shifts 21:12
masak is reminded of blog.plover.com/prog/featurism.html 21:19
dalek arVM/gcorch: 5c01f0c | diakopter++ | / (6 files):
wip4
 21:21
21:22 donaldh joined 21:23 jnap joined
diakopter masak: well, when the manual actually does need to be that long to explain obscure feature interactions... 21:23
"we got a 2000 page manual" ... "well maybe you needed a 4000 page one" 21:24
masak nods in the direction of the "essential complexity"/"accidental complexity" distinction
a bit of a cop-out, because there's no sure-fire way to distinguish a truly global minimum from merely a local one. 21:25
diakopter number of distinct macros in your source code with fewer than 9 letters in their names? 21:27
*zing*
masak :P
not_gerd well, Chuck Moore will tell you all that complexity is totally unnecessary 21:30
not_gerd digged out the link: www.ultratechnology.com/1xforth.htm
jnthn
.oO( You shojldn't Chuck Moore complexity in there... )
 21:32
22:16 tadzik joined
not_gerd heads off to sleep 22:48
23:12 jnap joined 23:33 Mouq joined 23:51 dolmen joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!