github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 19 October 2013.
01:32 ssutch joined 02:17 benabik joined 08:21 donaldh joined
FROGGS nwc10: I get to the same error like you fwiw 08:23
damn, the -ldl was an easy fix... I should have spotted it 08:24
dalek arVM: b85d5e6 | (Tobias Leich)++ | src/main.c:
fix linebreaks in USAGE msg
08:55
10:13 benabik joined
dalek arVM/ext: 81c654e | moritz++ | src/strings/ops.c:
return -1 from index_s with start out of range

this brings it in line with parrot and JVM, and easier for regex codegen
11:18
arVM/ext: b85d5e6 | (Tobias Leich)++ | src/main.c:
fix linebreaks in USAGE msg
arVM/ext: 0f32f5e | (Tobias Leich)++ | src/ (2 files):
Merge branch 'master' of github.com:MoarVM/MoarVM into ext
MoarVM/ext: 28c47b6 | (Tobias Leich)++ | build/Makefile.in:
FROGGS dalek: that's all? 11:19
it should state this too: "install config.h and libmoar" and "added --cflags and --libs" 11:20
jnthn: I hope the flags are correct 11:21
11:57 colomon joined 12:17 cognominal joined 13:58 ggoebel10 joined 14:03 grondilu joined 14:07 ggoebel11 joined 14:11 BenGoldberg joined 17:26 cognominal joined 17:50 timotimo joined
FROGGS I have a problem regarding to irclog.perlgeek.de/moarvm/2013-10-16#i_7722788 17:51
I thought it might be nice that the nqp::backendconfig op would return a proper hash of strings/arrays/hashes... 17:52
but for that I have to turn %config hash in Configure.pl into C code
so, should I create a backendcfg.c.in file, that gets filled by Configure? this would then provide a function that returns the hash 17:53
I'll try this now with build/config.c.in 18:15
jnthn FROGGS: Something like that, yeah 18:59
FROGGS k, good to know 19:00
jnthn: I will push to a branch, so it is reviewable
19:51 dalek joined 20:00 ssutch joined
FROGGS I believe the config thingeny works 20:00
jnthn k 20:02
FROGGS hmmm, do I need to create a stage0? it tells me here that the operation is unknown: 20:03
class HLL::Backend::MoarVM {
our %moar_config := nqp::backendconfig();
if I dont use it it HLL::Compiler, then I can execute nqp::backendconfig() 20:04
jnthn Yeah, you can't use an nqp:: op if it's not known 20:07
FROGGS ahh damn, push_s strikes again 20:17
ahh, wait 20:18
jnthn: seems to work :o) 20:24
dalek arVM/config: c45df2e | (Tobias Leich)++ | / (11 files):
added bakendconfig op

Which return the hash $config from Configure.pl.
20:28
FROGGS that is the generated C file: gist.github.com/FROGGS/6c57472990e44a8565d0 20:32
nqp -e 'say( nqp::backendconfig()<version> )' 20:33
2013.10-42-g1e8ea80
so, if that will be applied, I would rip out --cflags and --libs again 20:34
--version can stay I'd say
jnthn I thought we were adding --show-oncig to dump the lot? 20:39
FROGGS jnthn: yes, this is what I'd do next 20:40
jnthn ok, but then we don't need the ones for specific flags 20:41
That cna just dump all of them
FROGGS exactly
I would find and optional key to --show-config handy though
dunno if rakudo would benefit from that 20:42
jnthn: btw, --show-config would already work by adding three lines to HLL::Backend (after creating a new stage0) 20:44
jnthn aye 20:54
[Coke] is backendconfig basically the same thing as jvmgetconfig? 21:04
(if so, can we unify the names?)
FROGGS same names for same things would be cool, yes :o) 21:05
then we should wrap pir::getinterp__P()[pir::const::IGLOBALS_CONFIG_HASH] into the new opname too, and we'd have a single thing in rakudo 21:07
diakopter .
<- is still alive
FROGGS :o) 21:08
jnthn: what would be the name of choice? nqp::backendconfig? in nqp there is $!backend.config for example, so this would fit 21:11
gnight 21:12
jnthn FROGGS: Seems reasonable 21:17
21:51 colomon joined
[Coke] s/backend/vm/ 22:22
maybe.
FROGGS++ jnthn++ either way.
22:27 d4l3k_ joined 23:42 gshank joined 23:56 colomon joined