github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 3 August 2013.
00:47 colomon joined 01:06 colomon joined 01:18 FROGGS joined 01:32 FROGGS_ joined
JimmyZ Good Moarning 01:42
01:52 benabik joined
diakopter hi 02:18
could you review my last commit 02:19
JimmyZ I can test :P 02:24
diakopter its not showing the right line numbers or filenames
02:31 FROGGS_ joined
benabik implicit declaration of clock_gettime 02:34
JimmyZ benabik: -lrt 02:35
benabik JimmyZ: Erm, no that won't fix compilation errors.
JimmyZ oh
benabik It appears that clock_gettime doesn't exist in OS X. 02:36
diakopter benabik: you'd think I would test on that OS since I have a mac 02:37
benabik Hm. Probably want to start a platform/darwin. Looks like we need to poke Mach level stuff.
diakopter but I spend all my time in the Windows VM
benabik stackoverflow.com/questions/5167269...n-mac-os-x
Is there a particular reason we're using the realtime clock instead of just gettimeofday? 02:41
JimmyZ Confused at line 28, actually shoude be 27 :)
diakopter wasn't part of that 02:42
JimmyZ OS X does not have clock_gettime, use clock_get_time 02:43
gist.github.com/jbenet/1087739 02:44
benabik ah. gettimeofday goes to Āµs, get time is ns
diakopter ns units, but what precision 02:45
JimmyZ yeah, the line number is off-by-one 02:53
02:55 FROGGS joined
JimmyZ github.com/agentzh/sregex/commit/f...ca5e3b099a 04:54
It's funny that "add TC, 1" is faster than "inc TC" 04:55
05:18 not_gerd joined
not_gerd o/ 05:18
dalek arVM/darwin: 1fc9e93 | (Gerhard R)++ | / (3 files):
Add custom implementation of MVM_platform_now() for Darwin
 05:21
not_gerd benabik: could you test ^^
dalek arVM/darwin: e7eb44f | (Gerhard R)++ | src/platform/darwin/time.c:
Use CALENDAR_CLOCK on Darwin.
 05:25
05:31 cognominal joined
JimmyZ ../moarvm nqp.moarvm -e "say('Hello, MoarVM')" is stopped at futex(0x27002f0, FUTEX_WAIT_PRIVATE, 2.... 05:31
grondilu failed to noticed that nqp had been compiled to moarvm bytecode. Is that recent? 05:34
JimmyZ yes
grondilu cool. That's the last step until rakudo is compiled on moarvm, right? 05:36
05:37 moritz joined
moritz oh hai 05:37
I get an error building moarvm on mac os x
JimmyZ grondilu: maybe
not_gerd moritz: try darwin branch
moritz src/platform/posix/time.c:9:23: error: use of undeclared identifier 'CLOCK_REALTIME'
moritz tries
not_gerd: with that branch merge into master (locally), I get src/platform/darwin/time.c:14:29: error: use of undeclared identifier 'mts'; did you mean 'ts'? 05:38
JimmyZ not_gerd: the link said clock_get_time is slow ,the like gettimeofday * 1000
moritz seems like a typo 05:39
not_gerd moritz: it is
moritz can fix that
not_gerd copy-pasto
moritz: feel free
dalek arVM/darwin: d8b8446 | moritz++ | src/platform/darwin/time.c:
unbreak the build
 05:40
JimmyZ not_gerd: stackoverflow.com/a/8363218
not_gerd JimmyZ: then someone needs to make the call what's more important: prcision or performance
moritz just doubled the number of his moarvm commits
JimmyZ not_gerd: thay said : ". And, what's worse, the return value has steps of 1000, i.e. it's still microsecond granularity." 05:42
dalek arVM/gettime: 211ab0b | (Gerhard R)++ | src/platform/posix/time.c:
Use gettimeofday() if clock_gettime() is not available
 05:52
not_gerd moritz: ^^ 05:53
dalek arVM: 211ab0b | (Gerhard R)++ | src/platform/posix/time.c:
Use gettimeofday() if clock_gettime() is not available
 06:01
grondilu ../moarvm nqp.moarvm -e 'say("hello");' # returns with no error but does not say anything 06:11
06:42 crab2313 joined
diakopter you guys need to add the new platform files to the Makefile.in 06:51
JimmyZ or in setup.pm 06:52
diakopter just that I did git pull and it updated a source file but I hit nmake and nothing happened 06:53
oh, erm, maybe configure excluded it b/c i'm not on that platform
meh
not_gerd diakopter: the problem is, it's all POSIX - just different levels of support, that might or might not vary with OS versions 06:56
I actually added platform-specific code for darwin in a branch, but according to stackoverflow, using the Mach API is a bad idea[tm] 06:57
JimmyZ the BSD are not friendly with each other :-) 06:58
07:00 FROGGS joined
dalek arVM/libuv5: c244e89 | jimmy++ | src/ (3 files):
cleans up needless apr headers
 07:42
08:08 cognominal joined
JimmyZ if I changed MVM_dir_close to MVM_platform_closedir, than we don't need MVM_dir_close 09:18
*then
but there is MVM_dir_chdir 09:19
jnthn
.oO( oh dir )
JimmyZ what's why I'd like mv MVM_dir_close to src/platform/XXX.c and include "platform/dir.h" in src/io/dirops.h 09:20
that is , platform/dir.h is part of src/io/dirops.h 09:21
and with same prefix: MVM_dir_ 09:22
same for fileops.h
jnthn: how do you think about it? 09:23
I don't think we need MVM_dir_close to wrap MVM_platform_closedir again 09:24
or other MVM_file_ wrappers
jnthn I'm pretty sure we'll at some point want an organization for file handle stuff a little like what I did for the IO stuff on Rakudo JVM, where various operations are agnostic of the underlying handle kind... But even there the directory handling stuff doesn't fall within that... 09:27
Anything that lives in src/platform/ should probably be MVM_platform_ though.
You should be able to look at a function name and have a decent idea where to find it. 09:28
JimmyZ I'm fine with it. but then I'd like to call MVM_platform_ instead of call MVM_dir_ or MVM_file_ wrappers which simply call MVM_platform_ functions 09:29
and then cause prefix chaos 09:31
or like apr 09:33
create src/io/win32/ and src/io/posix/ 09:34
09:34 dalek joined
JimmyZ and mv mmap to src/io/ 09:35
jnthn Well, but then I suspect the MVM_platform_ functions end up not just being about platform abstraction, but also dealing with the MoarVM handle objects, etc.
There's probably a worthwhile separation to be had there.
JimmyZ but many wrappers simply call another function should be bad aslo 09:36
jnthn What I'm saying is we probably need a v-table for IO things, not a bunch of functions. 09:37
JimmyZ oh
jnthn The thing to keep in mind is that things like nqp::closefh($fh) could be used on all kinds of things.
From socket to file handle to stdin tty...
Same for nqp::readlinefh($fh) 09:38
Well, maybe not that one on a socket...
JimmyZ v-table, I'm not sure I like it. because of parrot :)
jnthn heh 09:39
No, v-table just means "a struct of function pointers".
It's a very generic concept. :)
JimmyZ parrot's v-table is calling another v-table, which is calling another v-table :P 09:40
then I'm lost :-)
jnthn Yes, I'm not proposing a bunch of layers here. :)
JimmyZ that will be much better 09:41
jnthn What I'm worried about is ending up with a bunch of, "if it's a tty, this thing, else if it's a file handle, this thing..." 09:42
JimmyZ yes 09:46
so much pointer there ends up we really needs a good JIT :P 09:47
jnthn Well, IO is IO bound :P 09:48
JimmyZ repr
jnthn But for REPR stuff, yes, we do, but REPRs are non-virtual. If you know the representation (or you assume you know it and do a guard clause) you can inline it.
JimmyZ aye
09:50 crab2313 joined
not_gerd thinks we should all just move to plan9 09:54
jnthn We've still working our way through plans 1..8 :P 09:56
not_gerd note that the parrot never got its IO factoring quite right
(IO vtable vs PMC polymorphism and how to integrate sockets)
jnthn Last time I looked at it, I couldn't find anything anywhere :)
Well, we don't have PMCs, so there's that problem gone :)
moritz diakopter: did you push that NFG branch you talked about in Kiev? 09:57
jnthn And the only built-in thing that has any methods is KnowHOW. :)
not_gerd but the libuv API itself has some polymorphism 09:58
they just haven't unified all types (yet?)
JimmyZ only uv_fs_ 10:00
but will in the future, per uv.h
I mean only uv_fs_t hasn't be unified :P 10:02
JimmyZ decommutes
11:04 colomon joined
JimmyZ Good evening 11:09
I guess NFG branch is in private repo? 11:10
11:19 not_gerd left
JimmyZ hmm, I saw jnthn's slide also said have a NFG branch 11:29
benabik master and darwin both build for me on OS X 11:54
JimmyZ good 11:55
darwin branch does not need
12:10 colomon joined 14:01 crab2313 joined
diakopter jnthn: I think it's running the deserialization or load frame but then not running the main frame 14:15
14:32 cognominal joined
JimmyZ diakopter: Was there a NFG branch? 14:36
diakopter yes in jnthn's private repo 14:43
jnthn diakopter: Do you want it moved into the public one? 14:44
diakopter nah; I have a local copy; I'll merge it manually to a new public branch and hopefully hand it off to moritz
well hm, maybe should branch it from libuv5 14:45
nah
14:47 mst joined 14:55 jlaire joined
diakopter jnthn: you saw my comment above about MAIN? 14:57
(43 min ago) 14:58
dalek arVM/libuv5: 0080bda | jimmy++ | src/ (4 files):
fixed Linux build
jnthn diakopter: yeah but I'm doing other stuff 14:59
diakopter: But yeah, ti's probably a combo of that plus not passing command line args right or something...
JimmyZ four of us are on windows ;) 15:02
15:02 not_gerd joined
JimmyZ \\o/ not_gerd 15:03
diakopter mst: I saw your presentation notebook is Windows - do you use Windows often?
not_gerd o/
mst diakopter: at this point, only for presentations until I figure out how to make the nexus do it
though I may prop the laptop up somewhere so I can smoke cygwin and strawberry on it 15:04
not_gerd mst: libuv doesn't support cygwin, and APR has issues on mingw64 15:08
mst I mean smoking cpan in general
not_gerd then, no worries 15:11
I just find it somewhat ironic that by relying on portability layers, moarvm ended up being not particularly portable 15:12
at least some of the headache will be gone once APR has kicked the bucket
jnthn Well, if somebody must run Rakudo on cygwin, they'll just have to pick another backend. :) 15:13
TimToady cygwin/jvm, yum :)
mst jnthn: but but but cygwin perl is so much less annoying than strawberry and I wanted the MoarVM module :) 15:15
jnthn argh
grondilu used to run cygwin. It's a nice port of GNU tools on windows. Please don't overlook it. 15:16
not_gerd still uses cygwin 15:17
the mingw64 cross packages handled compiling LLVM/Clang from source just fine
jnthn Fine, hopefully somebody who understands it will give libuv patches for cygwin support. I guess Node.js on cygwin must be desirable to somebody too... :) 15:18
not_gerd well, I'm mostly interested in the --os=win32 --toolchain=gnu --shell=posix --compiler=clang combination 15:19
why do you think my Configure.pl refactor looks like it does ;)
JimmyZ :P 15:34
--shell=rc 15:38
Good night 15:49
not_gerd ~~
lizmat gnight, JimmyZ 15:55
15:56 FROGGS joined 16:39 colomon joined 16:44 donaldh joined
not_gerd bye, #moarvm 18:38
18:39 not_gerd left 18:47 donaldh joined 19:11 colomon joined 20:03 donaldh joined 21:03 ingy joined
diakopter jnthn: hi 21:29
jnthn o/ 21:30
21:35 BenGoldberg joined
jnthn attempts to fix the startup thing 21:40
diakopter: um, I think the backtracer segfaults... 21:44
diakopter didn't for me :P
(but I'm sure it's plausible)
I think the values it's getting from the annotations are wrong
the integers
oh; it probably should range test the string heap index it allegedly gets 21:45
jnthn It's getting something wrong with the filenames too
diakopter that's what I mean
the integers from the annotations
including the string heap index
jnthn line 39 in $*ARGS_USED
:)
diakopter right, I said this yesterday
you must not've backlogged
dalek arVM: 9910a6a | jnthn++ | nqp-cc/src/QASTCompilerMAST.nqp:
Pass command line args to main.
 21:46
jnthn Well, or forgot what I backlogged :)
TimToady ooh, command line args!
well, at least it's different 21:52
$ ../moarvm nqp.moarvm -e 'say(42)'
Failed to tell position of filehandle: Illegal seek line 39 in $*ARGS_USED (op <unknown>, instr 0<unknown>, frame frame_name_799, compunit ./NQPHLLMoar.moarvm) line 65 in frame_cuuid_1130 (op set, instr 32849, frame interactive, compunit ./NQPHLLMoar.moarvm) line 71 in @statements (op bindlex, instr 32933, frame command_eval, compunit ./NQPHLLMoar.moarvm)
line 71 in$int (op return_o, instr 32896t, frame command_line, compunit ./NQPHLLMoar.moarvm)
Segmentation fault (core dumped)
FROGGS $*ARGS_USED sounds pretty HLL::sprintf-ish 21:53
TimToady seems to get that error regardless of the args or lack thereof 21:54
jnthn aye
Somehow it's not sending the args along flattened. 22:05
oh, I think it's the cross-comp's fault...or something. 22:09
lizmat isn't it always?
TimToady could be someone instead 22:10
dalek arVM: 3a5b0b5 | jnthn++ | src/io/procops.c:
Send in args boxed.
arVM: 6b65830 | jnthn++ | nqp-cc/nqp-src/NQP.nqp:
Work around MAIN args issue.
lizmat or the butler 22:11
jnthn Well, now it tries to start parsing.
oh, no it doesn't 22:12
Can confirm the line numbers are bunk though. :) 22:13
ingy greetings 22:15
FROGGS hi ingy
ingy hey FROGGS :)
jnthn OK, *now* we get into attempting the parse.
dalek arVM: 10153a3 | jnthn++ | src/io/procops.c:
Create clargs with current HLL array type.
FROGGS cool!
jnthn oh, or it's deceiving me again :/ 22:17
FROGGS O.o
jnthn yeah, think so... 22:19
dalek arVM: 2725332 | jnthn++ | src/core/coerce.c:
Exceptions smart-stringify to the message.
 22:24
jnthn Back to segfaulting now; not sure where/why yet. 22:43
FROGGS Program received signal SIGSEGV, Segmentation fault. 22:45
0x0000000000441385 in extract_key (tc=0x81c2e0, kdata=0x7fffffffd290, klen=0x7fffffffd298, key=0x4) at src/6model/reprs/MVMHash.c:36
diakopter heh. 22:47
diakopter feels to-blame
FROGGS gnight 22:54
diakopter well that one seems to be because the hash body is zeroed, which usually indicates a missing MVMROOT somewhere
jnthn The body just contains a null hash_head at the moment 22:58
diakopter yeah but that shouldn't be a problem
jnthn Which is the normal starting state of a hash.
It fails in extract key 22:59
The key object appears to be null
diakopter oh. yeah. the pointer is "4"
well that can't be right. :) 23:00
jnthn sure can't
diakopter
.oO( never seen a pointer at address 4 before... )
jnthn: we need a function we can call from the "watch" section in VS 23:01
that returns a C string of a backtrace 23:02
... once backtraces work
jnthn ooh, yes
diakopter TimToady: if you spec forward traces, I'll ask jnthn to implement them. :) 23:03
.oO( I'll forward trace you ... )
 23:04
jnthn Well, this is confusing. It seems to crash earlier now...
diakopter heh, in the backtrace probably
lizmat is that forward or backward ?
diakopter "excuse me son, you're being too forward with my daughter." "well you're being too backward with her" 23:07
jnthn hm, golfed
sub foo($x) { my %h; %h{$x} := 1; say('alive') }; foo(42)
boom segfault 23:08
O(MFG) 23:09
diakopter ?
dalek arVM: c13a6db | jnthn++ | src/core/coerce.c:
Fix a stupid in earlier patch; jnthn--.
 23:10
diakopter tries not to laugh a bit
(i'm allowed to laugh a bit though since I've done far worse) 23:11
oh, well that fixes that 23:12
jnthn yeah
Now it spits out a usage message. :)
diakopter whee
jnthn Something fun in arg parsing I guess :)
diakopter speaking of which, we use apr for arg parsing
er
something like that
.oO( I think I wrote a test for args )
 23:13
<- *guffaw* "a test"
jnthn All we need to do is grab the stuff from argv etc.
Unless you mean "args to MoarVM itself" 23:14
diakopter no I mean to get --dump
and --help and such
jnthn ah
diakopter yeah clargs should be not too far from right 23:15
jnthn yeah...
I just fixed it up a bit and it seems to be workingish
diakopter jnthn: wait, didn't you teach today? so how is your brain even on? 23:16
jnthn No, I didn't teach
I just wrote course material :)
masak was teaching :) 23:17
I gotta teach next week. In Oslo.
diakopter quick, jnthn, what's Worse than Norse?
jnthn ... 23:19
American?
:P
Illegal option --ā•žĀ”
...that looks broken!
diakopter you're an illegal option 23:20
push your local so I can see
jnthn Got nothing extra locally 23:21
just do
..\\moarvm.exe nqp.moarvm fake -e "say(42)"
-e "say(42)" # also gives wierd
diakopter haha
jnthn It shouldn't even be in the -- long option code path that dies that way! 23:22
diakopter wait, mine dies differently from yours
jnthn It's gotta be some corruption related to strings...
diakopter Error encoding UTF-8 string near grapheme position 17 with codepoint 48694944
line 75 in !fresh_highexpect (op <unknown>, instr 0<unknown>, frame frame_name_896, compunit ./NQPHLLMoar.moarvm)
line 1 in <unknown> (op null, instr 21, frame frame_name_893, compunit ./NQPHLLMoar.moarvm)
jnthn wow 23:23
That also points to corrupt strings
diakopter
.oO( someone should fix those annotations )
jnthn
.oO( someone should fix this ropey string impl )
diakopter hey that can't be it 23:24
jnthn It looks like it could be substr related but I'm really too tired to tell 23:25
I think things starting going awry around line 1751 of nqp-src/NQPHLL.nqp anways 23:26
*anyways
time for some rest; 'night 23:28
diakopter 'night 23:30

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!