github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 25 August 2013.
diakopter argh, annoying 00:01
dalek arVM/tinymt: 90ff4a4 | (Gerhard R)++ | / (12 files):
Import TinyMT and use it for random number generation
 00:11
arVM/serialize: 661f1cd | diakopter++ | src/6model/serialization.c:
lil bit of progress
 00:13
diakopter not_gerd: I can't remember.. did you import dyncall? feel free to kill my dyncall branch.. 00:22
not_gerd diakopter: I had a branch that integrated dyncall, libuv, linenoise 00:23
I guess it's still in my fork
it's out of date, though
I think dyncall integration can wait until we have our other ducks in a row 00:24
diakopter not_gerd: it's [sortof] a dependency of my p5interop project, as it'll be an extension, and I was planning to use a bit of the loading/resolution resolution features. 00:26
'course, could use libuv's facility for that until then...
not_gerd if it's a blocker, I can get it into master 00:29
diakopter I'm curious to see what we've changed in the exported copy in nqp from upstream
could you diff from that import?
or the latest sync?
in the nqp repo
I think we "fixed" a few things, but I dunno if they made it upstream 00:30
b/c I'm curious if we need to update that too
not_gerd well, I did some build system stuff and sent a bug report
no idea what became of that
diakopter I'm thinking of the other patches jnthn&crew made in the copy in nqp repo 00:31
(I'm wondering if we still need them)
not_gerd I don't see anything that stands out particularly in the diff 00:41
if we started from a clean import, upping the warning levels would probably lead to doing the same fixes again ;)
diakopter oh
has upstream changed much since then?
not_gerd don't think so 00:42
build system stuff, mostly
diakopter not_gerd++ # doing the tiresome work nobody else wants to do 00:46
hmm, well, this is a problem
the context serialization stuff needs to be able to allocate a new MVMContext...... 00:49
OR
I can fake it and allocate just 1 at the beginning and re-use it as a temp. 00:50
or just pass around MVMFrames only
and essentially reimplement the MVMContext repr stuff
bah.
bah, probably should do the latter since it's closer to what the jvm backend does 00:51
bbiab
dalek arVM/dyncall2: e00b95e | (Gerhard R)++ | 3rdparty/dyncall/ (317 files):
Import dyncall 0.7 from gerdr/integration
 01:10
arVM/dyncall2: 19345a2 | (Gerhard R)++ | build/ (3 files):
Wire up dyncall build
not_gerd good night 01:13
o/
01:13 not_gerd left 01:35 colomon joined 02:18 benabik joined
diakopter .tell not_gerd awesome! 02:34
yoleaux diakopter: I'll pass your message to not_gerd.
diakopter .ask arnsholt dyncall is now compiling in the dyncall2 branch.. want to stub in the dyncall reprs and ops? 02:35
yoleaux diakopter: I'll pass your message to arnsholt.
dalek arVM/dyncall1: 7bf57e1 | jimmy++ | / (2 files):
Add dyncall as submodule
 02:37
arVM/dyncall1: cbaa529 | (Gerhard R)++ | build/ (3 files):
Wire up dyncall build
JimmyZ .tell diakopter I added dyncall as submodule in dyncall1 branch 02:38
yoleaux JimmyZ: I'll pass your message to diakopter.
JimmyZ .tell not_gerd I added dyncall as submodule in dyncall1 branch 02:39
yoleaux JimmyZ: I'll pass your message to not_gerd.
JimmyZ I have got mirror of dyncall into github.com/zhuomingliang/dyncall
dalek arVM/libuv5: 811b455 | jimmy++ | / (4 files):
fixed socket tests
 03:19
JimmyZ hmm, the sockect test is not easily fixed, I got a libuv bug which was reported a years ago. see github.com/joyent/libuv/issues/444 05:32
if we can ignore the socket test, then the branch can be merged into master. I think the socket part will be redesigned by someone after runing rakudo 05:35
dalek arVM/libuv5: ea819fe | jimmy++ | nqp-cc/t/moar/socket_send_recv.t:
added a comment to socket_send_recv.t
 05:38
arVM: 2c21560 | (Gerhard R)++ | / (2 files):
Don't link 3rdparty libs twice when doing a shared build
 06:30
JimmyZ not_gerd: you're hardworking 06:33
06:34 FROGGS joined
JimmyZ not_gerd: I got some warnings when linking moarvm.dll and linking moarvm.exe 06:37
FROGGS morning
JimmyZ morning, FROGGS 06:38
.tell not_gerd Do you know why --shared link libmoarvm.so is 2.7M and no --shared link moarvm.exe is only 2.0M? 06:50
yoleaux JimmyZ: I'll pass your message to not_gerd.
JimmyZ .tell not_gerd but on windows the --shared link moarvm.dll is the same 2.26M as no -shared link moarvm.exe 07:05
yoleaux JimmyZ: I'll pass your message to not_gerd.
07:13 not_gerd joined
not_gerd o/ 07:13
yoleaux 02:34Z <diakopter> not_gerd: awesome!
02:39Z <JimmyZ> not_gerd: I added dyncall as submodule in dyncall1 branch
06:50Z <JimmyZ> not_gerd: Do you know why --shared link libmoarvm.so is 2.7M and no --shared link moarvm.exe is only 2.0M?
07:05Z <JimmyZ> not_gerd: but on windows the --shared link moarvm.dll is the same 2.26M as no -shared link moarvm.exe
not_gerd JimmyZ: you need to do a `make realclean` after switching between static and shared builds
oh... 07:14
I misunderstood
linking statically means the linker can remove unused code 07:15
also, DLLs come with some overhead as they need to do some bookkeeping 07:16
JimmyZ not_gerd: well, on windows they are the same 2.26M, but on linux not the same
not_gerd JimmyZ: might be because on linux, we generate different code via -fPIC
JimmyZ .so is about 0.7M bigger than moarvm.exe
not_gerd JimmyZ: did you try the noapr branch yet? 07:18
JimmyZ not_gerd: I removed PIC, same 2.7M
not_gerd no idea, then
JimmyZ not_gerd: are you fine to remove dyncall2 branch? 07:20
I got a dyncall mirror ;)
not_gerd JimmyZ: go ahead 07:25
I thought we might need to pull apart the dyncall build so we can build position-independant code as needed 07:26
if I read configure2 correctly, dyncall always compiles position-independent
so it should work out right 07:27
JimmyZ not_gerd: I got a diff gist.github.com/zhuomingliang/6338854/revisions 07:31
for --shared makefile and --noshared
not_gerd looks right to me 07:35
dalek arVM/noapr: 811b455 | jimmy++ | / (4 files):
fixed socket tests
 07:37
arVM/noapr: ea819fe | jimmy++ | nqp-cc/t/moar/socket_send_recv.t:
added a comment to socket_send_recv.t
arVM/noapr: 65feab8 | (Gerhard R)++ | / (4 files):
Merge branch 'libuv5' into noapr
JimmyZ not_gerd: Did jnthn +1 to tinyMT ? 07:41
not_gerd JimmyZ: no, not yet
also, I'll need the ok/no-go on stdtypes
JimmyZ so don't merge to noapr, though noapr can't build due to lack random :) 07:42
not_gerd right now, I can't build noapr at all 07:43
removing APR messed with the winapi headers
I get redeclarations for winsock stuff
JimmyZ er 07:44
the .so is bigger is weird
dalek arVM/noapr: c6107fb | (Gerhard R)++ | build/setup.pm:
Pass flags for compiling shareable objects down to APR
 08:05
MoarVM/noapr: 62ed85a | (Gerhard R)++ | build/ (2 files):
MoarVM/noapr: Add . to library search path
08:06 dalek joined
dalek arVM/libuv5: 3df9b42 | (Gerhard R)++ | src/moarvm.h:
Reorder headers so winsock2.h precedes windows.h
 08:06
08:07 benabik joined
dalek arVM/noapr: 300ed79 | (Gerhard R)++ | src/io/procops.c:
Fake random numbers for now
 08:13
arVM/noapr: d93006b | (Gerhard R)++ | 3rdparty/apr/ (464 files):
Remove 3rdparty/apr
not_gerd JimmyZ: you can now work with noapr instead of libuv5 08:20
FROGGS ETOOMANYBRANCHES 08:21
not_gerd just a dozen
not even a baker's one
JimmyZ not_gerd: I have done all the work 08:23
except redesign socket part...
I got a question: Do we need rand_i and rand_n 08:26
not_gerd yes - I don't think we can get awy with just removing them ;) 08:27
FROGGS rakudo uses rand_n and rand_I from what I can see 08:28
JimmyZ yes
I see it
but no rand_i
FROGGS correct 08:29
and there is no rand_i in nqp
JimmyZ so We don't need rand_i in MoarVM
FROGGS looks like 08:30
not_gerd I'd vote for keeping it
we don't expose it to users *yet*
the functionality is useful
JimmyZ is useful for who? 08:31
not_gerd I'm sure there are people who want to generate random integers reasonably fast 08:32
also, we need to support rand_n anyway
if we use TinyMT, we get the other one for free
JimmyZ pull a request when they need it ,or then can write bye themself
not_gerd JimmyZ: but it' no effort on our part to support it 08:33
it would be more effort to remove it
JimmyZ that makes me think about parrot :P 08:35
but yes, rand_i is useful, if rakudo wants it 08:37
I'm not care other users which is not existed 08:38
It'll be good to s/rand_i/rand_I/ ? :-) 08:44
rakudo needs rand_I 08:45
not_gerd I'd argue that in many cases where we use rand_I right now, rand_i would be the better choice 08:46
think about pick() or something
lists will never grow so large that you need bigints to index them 08:47
JimmyZ I think it's about perl6 spec 08:48
not sure
timotimo read somewhere that for integer randomness you have to be extra careful not to mess up the distribution of numbers generated
as in: just using a modulo on the randomness will give you screwed distributions
JimmyZ but yes, I like rand_i more than rand_I
rand_I is using rand() 08:49
timotimo why not rand_r? 08:50
oh, that's obsolete
JimmyZ oh, compiling MoarVM is much faster in noapr, not_gerd++ 08:53
not_gerd masak++ for getting rid of apr_atomic 08:54
JimmyZ hmm, libmoarvm.so is still 2.7M without apr
moritz how much was it with apr? 08:55
JimmyZ 2.7M
08:56 donaldh joined
JimmyZ if we ignore rand and socket test, we can merge it :P 08:57
well, these two are only needed for rakudo 08:58
timotimo since the current target is self-hosting nqp, i suppose it doesn't have to work instantly, eh?
JimmyZ yes, if jnthn++ give a +1 to merge 08:59
not_gerd JimmyZ: so the dll size did not decrease at all? 09:04
that's.... curious
JimmyZ not_gerd: not 09:05
not_gerd my last commit 2c21560 may be wrong 09:10
nope, seems to work as expected on windows 09:12
JimmyZ moarvm.dll size is 2338KB on master and 2417KB on noapr :) 09:13
not_gerd how does that work oO 09:14
oh, because we're now linking in libuv 09:16
moritz was apr dynamically linked?
not_gerd moritz: no
JimmyZ: could you compare libuv5 and noapr?
JimmyZ and on linux, .so is still bigger :(
09:17 grondilu_ joined
JimmyZ not_gerd: libuv5 is 2417KB 09:21
not_gerd exactly the same sizes?
JimmyZ yes 09:22
not_gerd perhaps the linker already threw out all the APR code we did not use 09:23
or something is really wrong ;)
well, on --shared --optimize I get 2445312 for noapr and 2445824 for libuv5 09:25
a whopping 512 bytes
JimmyZ the really weird is about on linux, the .so file :) 09:27
not_gerd master is only 2365440 09:29
timotimo not sure if commit id or file size :P 09:30
not_gerd size of optimized moarvm.dll
feel free if there's any codebase world-wide that has that commit id ;)
JimmyZ Let's vote, who are +1 to merge noapr into master :P 09:34
BabsSeed stays silent, unsure. :D 09:35
09:54 colomon joined
masak what are the downsides of merging noapr into master? 09:54
timotimo sockets go missing
masak a few breaking tests?
ah, yes.
timotimo and rand
masak then that's a legitimate reason to hold, methinks.
right. 09:55
prefer to keep master working.
so -1
not_gerd masak: keep in mind that we don't really have users to keep happy yet
failing tests in master might motivate someone to fix them ;) 09:56
JimmyZ or mark test tot TOTO if you're happy that
*to
masak there's something to be said for establishing sensible workflows early, though. 09:57
and I don't like workflows involving the phrases "we don't really have users" and "just mark the previously working tests as TODO".
JimmyZ socket is low priority
the good thing for merging it avoid merge conflict 09:58
with time ... master added new things, which will be a conflict to noapr
timotimo masak: "TODO: nom regression"
:3
masak timotimo: :( 09:59
JimmyZ TODO: noapr regression :)
masak timotimo: people optimistically promised that that wouldn't happen. it did.
nwc10 I think that you shouldn't merge it until jnthn says yes
and that really a solution for rand should also happen first
masak timotimo: and if you don't think that erodes the confidence of users, then exhibit A: chromatic. 10:00
nwc10 and both of those are possible within 24 hours
JimmyZ rand is only need after got rakudo running on moarvm
methinks
nwc10 does removing it right now make tests fail?
masak regardless, putting the current blockers and TODOs down in written form somewhere would be a good thing.
nwc10 good point. why didn't I think of that 10:01
not_gerd masak: it's not gone, just returns 42 on every invocation
nwc10 oh, is there an upstream fix in libuv for that socket bug? Or just a report?
not_gerd that'S a totally valid random seuqence
JimmyZ nwc10: it's fixed for posix, but not for windows 10:02
masak not_gerd: that's a totally *cromulent* random sequence. :)
JimmyZ the other thing is that, socket part needs redesign for async io 10:03
so mark TODO is not bad
JimmyZ decommutes 10:04
not_gerd (strawberry perl|mingw)-- 10:05
no LPOVERLAPPED_ENTRY
10:08 grondilu joined
not_gerd hm.. 10:13
libuv appears to use Vista API
\\o/ 10:15
first moarvm built on mingw
nwc10 not_gerd: which implies that it won't work on XP? Is that a problem for the next 8 months? 10:31
10:36 donaldh joined
not_gerd well, reportedly xp still has a big install base 10:49
the question is, do we care about these people
FROGGS I'd say yes 10:50
not_gerd uv.gyp: _WIN32_WINNT=0x0600 10:51
flussence make it work, but only if it's not unreasonable extra effort 10:54
not_gerd flussence: we might have to hack libuv 10:56
we don't build with strawberry perl right now brcause the bundled mingw version is too old 10:57
flussence well then look at it the other way, no point making it work unless people start complaining :)
(and I'd guess at least one of jvm/parrot runs on XP, so it's not a total loss for any such users) 10:59
not_gerd actually, I might be wrong there 11:00
not_gerd tries again to get strawberry-perl to work
JimmyZ Good evening 11:02
not_gerd now, it actually compiled 11:05
JimmyZ good 11:07
cd 11:30
not_gerd: error while loading shared libraries: libmoarvm.so: cannot open shared object file: No such file or directory 11:33
when make nqptest
11:35 donaldh joined
not_gerd JimmyZ: you'll probably need to set LD_LIBRARY_PATH 11:38
JimmyZ :( 11:41
not_gerd JimmyZ: we don't compile-in path information yet
JimmyZ oh
not_gerd we'll probably ask someone who is more firm in their *nix knowledge what the most appropriate approach is 11:42
* have to ask
JimmyZ ok :-)
hmm, make nqptest hangup 11:43
in noapr branch 11:44
not sure master
11:51 woolfy joined
not_gerd JimmyZ: hangs here as well 11:56
60-bigint.t nqp::expmod_I test
12:03 JimmyZ_ joined
JimmyZ_ not_gerd: hangs here from 01 test :( 12:04
not_gerd hm... 12:13
the string failures look like an off-by-one somewhere
(perhaps not) 12:14
not_gerd pokes random stuff
12:20 jnap joined
not_gerd hm... 12:21
do we have a canonical empty string somewhere? 12:22
guesses tc->instance->str_consts->empty
12:46 ggoebel joined 13:10 colomon joined
JimmyZ_ another workļ¼š port CStruct/CArrray to MoarVM 13:15
nwc10 not_gerd: rpath. You steal the logic from how Perl 5 does it already -) 13:23
but, if the plan is to have a libmoar.so (or equivalent) I think that the testing setup needs to be done a bit better than Perl 5 does it
else you with hit problems (in the future) that we've hit with Perl 5 13:24
where the perl binary thinks that it wants to load a libperl.so
and you're testing the perl binary locally, so you have to use LD_LIBRARY_PATH etc to force it to load the *un*installed library
which messes up anything in your installed toolchain written in perl 13:25
JimmyZ_ oh, I'd like to s/moarvm.exe/moar.exe/
not_gerd that sounds... unfortunate
(re nwc10)
JimmyZ_ moar.exe hello.moar 13:26
nwc10 it is. I think it comes from conflating the design - is one testing an executable, or a library? 13:29
JimmyZ_ parrot had the problem, and finally got installable_parrot :/ 13:31
moritz ... which wasn't relocatable, which caused huge problems 13:35
so don't steal parrot's "design"
nwc10 oh yes. you really ought to be testing the thing that you install 13:37
you can't go "relocatable" everywhere. Not every OS give you quite enough information 13:38
moritz you can go relocatable much more than parrot did :-) 13:58
nwc10 yes, Win32, Linux, most *BSDs, Solaris, OS X can all tell you the full path of the current executable 13:59
I don't think that it's possible for AIX or HP-UP (at least, as not-root) 14:00
er, HP-UX
JimmyZ_ diakopter: ping 14:16
14:18 donaldh joined
dalek arVM: 80dc8cd | (Gerhard R)++ | src/strings/ops.c:
Some fixes to string ops to make t/nqp/59-nqpop.t pass

Note that NQP/Parrot, NQP/JVM and NQP/MoarVM all disagree on how nqp::substr() should behave.		 14:31
14:35 benabik joined
JimmyZ_ wonders how 59-nqpop.t passed before 14:38
not_gerd: have a interest in CStruct.c ;) 14:40
?
JimmyZ_ still doesn't know how to cover Parrot_pcc_invoke_from_sig_object to MoarVM 14:41
dalek arVM: a1f8b1e | (Gerhard R)++ | src/strings/ops.c:
Add some missing parens
 14:42
JimmyZ_ *convert
not_gerd: I don't know why it needs parens 14:43
not_gerd JimmyZ_: doesn't need them 14:44
coding style
14:46 lizmat joined
JimmyZ_ oh, I'm ask cause start_pos = ... no parens ;) 14:47
not_gerd oh, well... 14:49
they should be there ;)
JimmyZ_ hehe
not_gerd quick vore: parens or no parens? 14:50
*vote
JimmyZ_ no parens, I'd vote
dalek arVM: b5086c3 | (Gerhard R)++ | src/strings/ops.c:
Revert "Add some missing parens" - JimmyZ++ voted 'no'

This reverts commit a1f8b1e8ac98f552cd076343bd6646a31c7e448e.		 14:52
JimmyZ_ btw, sometimes I think parser is slow because of heavily using substr() :/ 14:55
which makes me *char++ is faster in C
s/me/me think/
FROGGS I thought that was planned, at least I remember hearing diakopter++ talking about it 14:56
JimmyZ_ what was planned?
FROGGS just moving pointers instead of substr-ing 14:57
JimmyZ_ oh
after NFG?
FROGGS no idea
JimmyZ_ .ask diakopter time to public the NFG branch? ;) 15:03
yoleaux JimmyZ_: I'll pass your message to diakopter.
timotimo yeah, the NFG branch is secretly already done and just needs to be pushed to github 15:05
dalek arVM: d945262 | (Gerhard R)++ | src/strings/ops.c:
Add boxing that got lost intranslation

Threads aside, this should make test pass again.		 15:07
arVM/noapr: 80dc8cd | (Gerhard R)++ | src/strings/ops.c:
Some fixes to string ops to make t/nqp/59-nqpop.t pass

Note that NQP/Parrot, NQP/JVM and NQP/MoarVM all disagree on how nqp::substr() should behave.		 15:22
arVM/noapr: a1f8b1e | (Gerhard R)++ | src/strings/ops.c:
Add some missing parens
arVM/noapr: b5086c3 | (Gerhard R)++ | src/strings/ops.c:
Revert "Add some missing parens" - JimmyZ++ voted 'no'

04be0b2 | (Gerhard R)++ | / (2 files): Better MinGW support
diakopter pong 15:38
yoleaux 02:39Z <JimmyZ> diakopter: I added dyncall as submodule in dyncall1 branch
15:04Z <JimmyZ_> diakopter: time to public the NFG branch? ;)
diakopter JimmyZ_: no not stable enough yet
moritz well, if you don't publish it, I can't hack on it 15:39
jnthn Branches don't have to be stable.
yoleaux 25 Aug 2013 23:15Z <diakopter> jnthn: < diakopter> argh, I'm suspecting only jnthn can do it from here :(
jnthn :)
yoleaux 25 Aug 2013 23:32Z <diakopter> jnthn: line 572 of SerializationWriteer.java - staticCode is always null
FROGGS master is a branch too 15:40
FROGGS hides
jnthn :P
not_gerd diakopter, jnthn: github.com/MoarVM/MoarVM/blob/d945...ops.c#L342
moritz FROGGS: as long as nom is stable... :-)
not_gerd new nqp::substr() semantics
FROGGS *g*
diakopter jnthn: i was unclear; i meant theres no branch stable enough on which to base it
not_gerd Parrot and JVM don't agree, so I did what made sense to me
moritz ... now we have three interpretations :-) 15:41
not_gerd (tests pass)
diakopter (not renough tests)
jnthn not_gerd: eek :) 15:43
not_gerd: Parrot and JVM don't disagree deliberately fwiw :)
not_gerd jnthn: irclog.perlgeek.de/perl6/2013-08-26#i_7502562 15:44
diakopter jnthn: scrollback here is .. long!
jnthn I noticed :/
FROGGS you may need a scrollbreak in between :o)
diakopter jnthn: to summarize what I concluded: I'll pass around frames and add MVMROOTs everywhere (sigh) 15:45
commutance& 15:46
15:46 FROGGS[mobile] joined
not_gerd jnthn: highlight - the noapr branch, that removes APR 15:46
problems: sockets, no random numbers 15:47
15:56 colomon joined
arVM: ee5a49d | (Gerhard R)++ | / (2 files):
Better MinGW support
16:11 FROGGS joined
diakopter what's the socket problem? 16:13
16:14 JimmyZ_ joined
JimmyZ_ not_gerd: re d945262fa0, I think it's not needed MVMROOT, just MVM_repr_set_str(tc, pobj, tc->instance->str_consts->empty); 16:15
Good night
not_gerd diakopter: socket tests fail 16:17
also, async IO wants integration with the scheduler
TimToady sockets aren't necessary to a bootstrap, plus people will be highly motivated to make sure they work later :) 16:20
async IO is a bit more abstruse though, and likelier to suffer from lack of attention
but also probably not needed for bootstrap 16:21
not_gerd also, one of the bigint tests from nqptest hangs in MinGW when using the noapr branch 16:23
MSVC build looks good, though 16:24
jnthn diakopter: In the serializer? Do you need to allocate? 16:25
diakopter: If so you can always do what the deserializer does: flip over to using gen2 direct allocation...which of course never triggers a collect :) 16:26
diakopter jnthn: yeah it allocates iterators and also perhaps contexts
though I can cheat and use mutable temps of those 16:27
since they're not recursive
not_gerd: I wouldn't worry about the socket tests; just delete them. :) they were very much POC 16:31
masak: yes, we have no users. :P the tests are hardly worth anything, also
the ops are likely not even the right api 16:32
not_gerd I'm more worried about t\\nqp\\60-bigint.t hanging ;)
16:54 colomon joined
not_gerd ok, it's just a tommath mis-configuration 16:55
we end up with a 32-bit mp_digit, but a DIGIT_BIT of 60
diakopter not_gerd++ 16:56
16:58 woolfy1 joined
masak diakopter: I wasn't talking about the number of users, I was talking about using "we have no users" as an excuse to skimp on good practices. 17:10
TimToady fixing things is always good practice, it's just easier when there are fewer users 17:14
17:22 woolfy joined
dalek arVM/noapr: fb22aee | (Gerhard R)++ | 3rdparty/libtommath/tommath.h:
Make libtommath work with MinGW
 17:49
arVM/noapr: aa9695a | (Gerhard R)++ | src/gc/ (2 files):
Don't use MVM_casptr() on non-pointers
diakopter masak: what's the good practice you didn't want skimped? 17:52
FROGGS good practice is to keep passing tests passing, features in place and the master branch buildable 17:56
not_gerd
.oO( let's get a deprecation policy in place )
 17:57
if anyone's got the time, the noapr branch needs testing 17:58
diakopter FROGGS: right, but the sockets are wrong, wronger, and wrong... they're not features 18:03
18:06 japhb__ joined
timotimo .o(the rakudo sockets have some wrongness, too ...) 18:12
not_gerd bye, #moarvm 18:25
18:56 colomon joined 19:08 cognominal joined 19:28 jnap joined 20:12 d4l3k_ joined 20:13 eternaleye joined
dalek arVM/serialize: ed6c529 | diakopter++ | src/6model/serialization.c:
li'l' bit more progress
 20:32
diakopter .tell not_gerd +1 to merge tinymt imho 20:33
yoleaux diakopter: I'll pass your message to not_gerd.
dalek arVM/serialize: 69cf281 | (Gerhard R)++ | / (2 files):
Don't link 3rdparty libs twice when doing a shared build
 20:34
arVM/serialize: ea39381 | (Gerhard R)++ | src/strings/ops.c:
Some fixes to string ops to make t/nqp/59-nqpop.t pass

Note that NQP/Parrot, NQP/JVM and NQP/MoarVM all disagree on how nqp::substr() should behave.
arVM/serialize: b235670 | (Gerhard R)++ | src/strings/ops.c:
Add some missing parens
MoarVM/serialize: 6e4b490 | (Gerhard R)++ | src/strings/ops.c:
MoarVM/serialize: Revert "Add some missing parens" - JimmyZ++ voted 'no'
diakopter .tell JimmyZ +1 to merge the dyncall build 20:38
yoleaux diakopter: I'll pass your message to JimmyZ.
diakopter .tell not_gerd I vote +1 on merging stdtypes.. jnthn? 20:48
yoleaux diakopter: I'll pass your message to not_gerd.
diakopter .tell not_gerd +1 to merge noapr and delete the socket tests and merge tinymt, and also clean up all the libuv branches 20:50
yoleaux diakopter: I'll pass your message to not_gerd.
diakopter anyway that should remove all the branches but serialize :) 21:28
jnthn I'm not gonna catch up on backlog tonight... :( 21:34
Anything I need to comment on? :) 21:35
diakopter jnthn: just whether to merge a ton of branches :)
jnthn aww crap :)
I'm gonna be pretty tied up until Wed, when I will suddenly have free time again :)
diakopter really just "can we use tinymt for rand"
(surely yes) 21:36
and "can we kill some socket tests for now"
(please yes, so noapr can merge and libuv is in)
jnthn Sockets - does this mean we're not going to have a socket impl at all?
(for now)|
diakopter well there's a libuv bug upstream
I haven't looked at it; could be a simple fix 21:37
jnthn Aye, I just mean, we're just saying "we put implementing socket stuff off until later"?
diakopter not_gerd hasn't looked at it either
yes
jnthn OK, +1
diakopter the tests and op sigs need redone anyway
jnthn Right, we should see what NQP JVM settles on in nqp:: ops.
diakopter k
jnthn And steal it once the various networking related modules are working against that.
diakopter other question is the stdtypes branch - whether to remove all the MVM* for C types and replace with standard ones (incl. a .h that adds them to msvc pre-2013) 21:38
jnthn I'd like some more time to ponder that.
So don't merge that one yet.
diakopter k
jnthn noapr implies merging the rand thing? 21:39
diakopter yeah if you don't want broken rand test
jnthn *nod*
Are you comfortable with it? It's fine license wise too?
diakopter masak++ got rid of the apr_atomic uses
bsd
of course, no clue about patent infringement, but then again we probably infringe 50,000 patents we don't know about 21:40
21:40 BenGoldberg joined
jnthn yes, well, the best thing to do with software patents is not read any :) 21:40
diakopter <- hasn't read any, that I can recall. ;)
jnthn OK, let's go for the noapr branch and the rand thing it implies, if you're comfortable with it. 21:41
diakopter k
jnthn Where is libuv living?
In a separate git repo?
Submodule?
diakopter yeah I think so, if not we'll put it there
oh also dyncall building merge 21:42
seems fine
jnthn Yes, please submodule it.
diakopter that's submoduled
jnthn (libuv and dynall
)
masak noapr seems to contain my libuv5+no_apr_atomic, so \\o/
diakopter github.com/MoarVM/MoarVM/compare/m.....dyncall1
jnthn I can create repos under MoarVM account if needed.
diakopter masak: yes :D
masak I'll just go ahead and remove libuv5+no_apr_atomic and apr_to_libatomic_trial_3 now. 21:43
diakopter please create dyncall repo and libuv repo
though we might not need the libuv one
jnthn ok, lemme do that now so nobody blocks on at least that aspect of things I can do :)
Wait, should I create them or fork them from somewhere?
diakopter create blank I think
er, well fork 21:44
fork dyncall from zhuomingliang/dyncall
jnthn github.com/MoarVM/dyncall 21:45
And libuv? Fork from...?
github.com/joyent/libuv ? 21:46
Or clean repo?
diakopter nm we don't need libuv
pulling that directly from joyent for now
jnthn oh, can just subodule the joyent one?
1
+1 even
diakopter *shrug* somehow...
jnthn OK, then my work here is done :)
diakopter jnthn: well bunches of strange/unknown spec/rakudo behavior in #perl6 log but I'll leave those to masak++ 21:47
strange/unknown to me, anyway. 21:48
fwiw
jnthn :)
I'll backlog it tomorrow 21:49
diakopter jnthn: do you want the p5interop stuff to live in the MoarVM repo or be a separate repo? doesn't matter to me. can work fine either way.
jnthn diakopter: Is there a reason for it not to be in the MoarVM repo?
diakopter eh, not really I guess except tpf would own some of the code.. 21:50
jnthn diakopter: the only reasons I can think of for separate repo are (a) enforced loose coupling, and (b) your convenience :)
oh, that's a third reason :)
diakopter but the main one can always pull in the other one as a submodule
so whichever
jnthn No strong feeling either way on my part. I'll leave it for your judgement. :) 21:51
diakopter can you create a repo just in case... mvmp5 I guess 21:53
or moarp5
jnthn diakopter: Access just to you, or all who have MoarVM commit bits? 21:56
diakopter all
jnthn (asking in case TPF connection implies CLA stuff...)
diakopter oh, hrm
dunno
well I made it clear the project as a whole wouldn't be tpf, just the code I put in 21:57
during that time period
masak I'll backlog it tomorrow as well. :)
FROGGS your grant got accepted?
diakopter no
not yet
maybe this week 21:58
FROGGS cool
21:58 not_gerd joined
diakopter not_gerd: hi 21:58
not_gerd o/
yoleaux 20:33Z <diakopter> not_gerd: +1 to merge tinymt imho
20:48Z <diakopter> not_gerd: I vote +1 on merging stdtypes.. jnthn?
20:50Z <diakopter> not_gerd: +1 to merge noapr and delete the socket tests and merge tinymt, and also clean up all the libuv branches
diakopter .tell not_gerd jnthn agreed on those except stdtypes (yet) 21:59
yoleaux diakopter: I'll pass your message to not_gerd.
21:59 colomon joined
not_gerd ;) 21:59
yoleaux 21:59Z <diakopter> not_gerd: jnthn agreed on those except stdtypes (yet)
dalek Heuristic branch merge: pushed 84 commits to MoarVM/tinymt by gerdr
Heuristic branch merge: pushed 82 commits to MoarVM/stdtypes by gerdr 22:00
jnthn diakopter: github.com/MoarVM/moarp5 22:01
diakopter ty 22:02
not_gerd: don't merge stdtypes yet :P 22:03
(though it'd clearly be easy to back out that change)
not_gerd note that when relying on stdint.h, we're no worse off than we are right now as libuv relies on it as well 22:04
and we can avoud having to probe for how to print fixed-sized types 22:05
jnthn Time for sleep. Happy libuv-merging. :) 22:07
not_gerd good night
jnthn 'night
diakopter 'night 22:08
jnthn btw, will get back to working on NQP self-host on Wed, once I'm back home :)
o/
diakopter will try to unblock serialization by then
not_gerd
.oO( so I can expect NQP to self-host on Thu morning )
diakopter can I delete libuv, libuv1, and libuv5 branches? 22:10
not_gerd I believe so
JimmyZ would know for sure 22:11
dalek arVM: 7bf57e1 | jimmy++ | / (2 files):
Add dyncall as submodule
arVM: cbaa529 | (Gerhard R)++ | build/ (3 files):
Wire up dyncall build
arVM: ab8e468 | (Matthew Wilson)++ | / (5 files):
Merge pull request #52 from MoarVM/dyncall1

Dyncall1
diakopter JimmyZ: ping
not_gerd I have no idea why he kept libuv and libuv1 around
diakopter I still have them locally anyway 22:12
deleted. 22:13
github.com/MoarVM/MoarVM/branches
FROGGS: ETOOMANYBRANCHES fixed
FROGGS *g* 22:14
not_gerd I believe noapr can be merged even without tinymt 22:15
diakopter well jnthn ok'd tinymt too
not_gerd rand_i/rand_n may not work, but we actually only use rand_I right now 22:16
diakopter: I'd like to know for sure if we go with standard types or not before doing that work
otherwise, I'd have to convert tinymt to MVM* types 22:17
diakopter oh
I agree with you that rand_i is important for internals and extensions
oh, another todo :)
extend the hash algorithm to be smart enough to traverse tree strings instead of requiring all strings to be flattened before used as hash keys
the machinery to make the traversal modular enough should already mostly be there 22:18
should I add it as an issue?
not_gerd does it make sense to cache the hash value?
diakopter yes 22:19
not_gerd having it around is also useful for eq
do we already do it?
diakopter don't think so
though I might've put a slot in for it
another todo:
all the string literals in the moarvm source where we construct MVMStrings from C literal strings (without format)... should be cached in a struct that hangs off MVMInstance 22:20
(and all rooted)
(and their constructor calls obviously set to lookup in the cache) 22:21
parrot has a convenience function for this
there are already a few strings cached on Instance like that ->Str , ->Num, ->Empty I think 22:22
but it needs generalized
further generalized would be to find any unchanging/immutable things created by runtime code and make those cached too
could even make the .h that stores their slots generated if you use a macro sneakily 22:24
i'll create issue 22:25
issues
cleaned up: github.com/MoarVM/MoarVM/issues 22:31
not_gerd: are you merging noapr? 22:32
not_gerd diakopter: I can do it, assuming it's fine as-is 22:34
diakopter where does it need testing? 22:35
I can test macosx
or linux or windows
all 64
not_gerd it's tested on win64 msvc+mingw
diakopter msvc and mingw separately!? 22:37
not_gerd yes
diakopter ok
not_gerd you can now use strawberry perl to build moarvm
diakopter AWESOME
both 32 and 64/
?
how about cygwin
not_gerd only tested on 64 22:38
diakopter github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
22:17 < diakopter> oh, another todo :)
22:17 < diakopter> extend the hash algorithm to be smart enough to traverse tree strings instead of requiring all strings to be flattened before used as
hash keys
22:18 < diakopter> the machinery to make the traversal modular enough should already mostly be there
22:18 < diakopter> should I add it as an issue?
22:18 < not_gerd> does it make sense to cache the hash value?
22:19 < diakopter> yes
22:19 < not_gerd> having it around is also useful for eq
22:19 < not_gerd> do we already do it?
22:19 < diakopter> don't think so
22:19 < diakopter> though I might've put a slot in for it
22:19 < diakopter> another todo:
22:20 < diakopter> all the string literals in the moarvm source where we construct MVMStrings from C literal strings (without format)... should be cached in a struct that hangs off MVMInstance
22:20 < diakopter> (and all rooted)
22:21 < diakopter> (and their constructor calls obviously set to lookup in the cache)
22:21 < diakopter> parrot has a convenience function for this
22:22 < diakopter> there are already a few strings cached on Instance like that ->Str , ->Num, ->Empty I think
22:22 < diakopter> but it needs generalized
22:22 < diakopter> further generalized would be to find any unchanging/immutable things created by runtime code and make those cached too 22:39
22:23 -!- colomon [~colomon@97-95-33-142.dhcp.bycy.mi.charter.com] has quit [Quit: colomon]
22:24 < diakopter> could even make the .h that stores their slots generated if you use a macro sneakily
22:25 < diakopter> i'll create issue
22:25 < diakopter> issues
22:31 < diakopter> cleaned up: github.com/MoarVM/MoarVM/issues
22:32 < diakopter> not_gerd: are you merging noapr?
22:34 < not_gerd> diakopter: I can do it, assuming it's fine as-is
22:35 < diakopter> where does it need testing?
22:35 < diakopter> I can test macosx
22:35 < diakopter> or linux or windows
[22:35] [diakopter(+i)] [3:freenode/#moarvm(+cnt)] [Act: 2]
[#moarvm]
0*$ mwilson@host06 198.211.109.45 Menu:<F9>
erm.
sorry.
not_gerd ;)
diakopter <- fail
not_gerd np
diakopter argh.
once again, irssi's paste warning fails me
not_gerd cygwin isn't supported by libuv 22:40
one can probably make it work by using the windows version
Tene irssi paste warning didn't work for you?
not_gerd but it might be a bit fiddly
diakopter Tene: it didn't prompt me
Tene Huh. :( 22:41
diakopter PuTTY must outsmart it
gist.github.com/diakopter/239e6bdaec4aed3a1580 22:42
not_gerd: ^
Tene Incidentally, I've heard a lot of compliments for KiTTY, a fork of PuTTY, but haven't used it myself: kitty.9bis.net/
diakopter (it's what I'm using actually) 22:43
my main complaint about KiTTY is it messes up saved sessions 22:44
Tene Ah. That's unfortunate.
diakopter so you have to launch PuTTY to edit and save session settings
but it's fine otherwise. esp clickable urls 22:45
that's nice
not_gerd: you see that nopaste?
not_gerd diakopter: that was a static build? 22:48
silly question
the gist mentions libmoarvm.a, so yes ;) 22:49
wild guessing on my part is that clang's ccmiscflags probably should contain -D_LARGEFILE64_SOURCE as well... 22:52
diakopter: could you add that to your Makefiles CFLAGS, make clean && make 22:53
diakopter not_gerd: same error 22:54
we can't be calling pthread stuff directly without including the pthread header.. 22:56
.. or linking to pthread 22:59
not_gerd we should link to pthread 23:03
do a NOISY=1 make and -lpthread should be there 23:05
and pthread.h should get included via uv-unix.h 23:07
diakopter how do I do NOISY=1 make?
I did NOISY=1 make... but didn't seem noisy
not_gerd `make NOISY=1`
diakopter pthread's not listed 23:08
not_gerd gist yout makefile?
diakopter gist.github.com/diakopter/b745536a6dc2f92fd558 23:10
not_gerd thanks
23:10 colomon joined
dalek arVM/noapr: 3aeea5e | (Gerhard R)++ | build/setup.pm:
Add -lpthread for Darwin
 23:14
not_gerd diakopter: ^^
diakopter same error 23:16
not_gerd: ^ 23:19
not_gerd diakopter: apparently, there's no lseek64 on darwin - one should just use lseek 23:20
so that error is correct
I'm wondering what's up with pthreads, though... 23:21
diakopter well did you include the .h? 23:22
not_gerd diakopter: I did not write that code
but the pthreads header should be pulled in via uv.h 23:23
diakopter does that branch #include the .h? :)
not necessarily
23:23 FROGGS joined
diakopter well it's pulled in by unix.h 23:26
uv-unix.h I mean
which supposedly is included by uv.h 23:27
dalek arVM/noapr-fix: 0991a60 | (Gerhard R)++ | / (2 files):
Use lseek() with _FILE_OFFSET_BITS=64 instead of _LARGEFILE64_SOURCE and lseek64()
diakopter not_gerd: that fixed the lseek thing 23:28
not_gerd lists.apple.com/archives/unix-porti...00052.html 23:30
no pthread_yield on macos 23:31
we should add something to platform/ for that
diakopter ok
dalek arVM/noapr-fix: 6f19745 | (Gerhard R)++ | src/ (2 files):
Add platform wrappers for yielding threads
 23:39
not_gerd diakopter: ^^
diakopter worked
dalek arVM/noapr: 0991a60 | (Gerhard R)++ | / (2 files):
Use lseek() with _FILE_OFFSET_BITS=64 instead of _LARGEFILE64_SOURCE and lseek64()
 23:42
arVM/noapr: 6f19745 | (Gerhard R)++ | src/ (2 files):
Add platform wrappers for yielding threads
not_gerd that's it from me for today
good night o/
23:43 not_gerd left 23:48 Util joined 23:49 foo_bar_baz joined 23:59 FROGGS 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!