Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-30

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

All times shown according to UTC.

Time Nick Message
00:07 colomon joined #moarvm
00:11 rudi_s Hi. Just noticed the following error message when perl6 fails to open a file with open 'foo': "Failed to open file: no such file or directory". This message is not really helpful as it's not telling me which file it couldn't open. Is there a reason why the filename is not reported?
00:11 rudi_s Looking at the code: src/io/syncfile.c:414 it seems to be no problem to just extend the line to also print fname as well.
00:12 rudi_s Something like MVM_exception_throw_adhoc(tc, "Failed to open file %s: %s", fname, uv_strerror(req.result)); - untested.
00:13 rudi_s (Might a bit problematic with non-ascii filenames though.)
00:14 rudi_s Oh, and btw. just noticed, in line 407, is the %d for "Invalid open mode: %d" correct? Shouldn't this be a %s as fmode is a char * const.
00:15 TimToady yeah, looks pretty LTA to me...
00:17 rudi_s LTA?
00:18 TimToady Less Than Awesome
00:18 rudi_s Ah.
00:18 TimToady sorry, a meme that's more current in #perl6 than here...
00:19 rudi_s np ;-)
00:20 TimToady and not surprising, often the earliest things that were implemented in moarvm are the roughest, since things have to get bootstrapped based on very primitive...er...primitives...
00:23 rudi_s Just compiling the VM, is there a reason why it's not built with -Wall? Noticed quite a few warnings with -Wall ..
00:28 japhb rudi_s: Because not all of the warnings have been cleaned up.  Volunteers have helped to reduce it considerably, but as yet I don't think anyone's made it build completely clean.
00:29 rudi_s Would patches which cleanup -Wall warnings but provide no new features be accepted?
00:29 japhb (Some people like having the annoyance of every possible warning, in order to convince them to keep it clean, but if you're starting warnings-heavy instead of warnings-clean, it's easy for people to just start ignoring the noise.  So we don't do that.)
00:29 rudi_s Btw. regarding the %d vs. %s, it might be a good idea to use __attribute__((format(printf,2,3))) in a few places.
00:29 japhb rudi_s: Yes, that's quite likely, as long as you do them a chunk at a time, and not some gigantic 3000 line patch.
00:30 japhb (Plus, remember we want to be clean on VC++, clang, gcc, ...)
00:31 colomon joined #moarvm
00:32 rudi_s Good to know. Might send a few patches when I have some time. - Never used VC++, does it support stuff like PRIX32 when printing uint32 and similar?
00:45 colomon joined #moarvm
01:45 colomon joined #moarvm
02:11 rudi_s Is there a mailing list where I can submit the patches?
02:15 TimToady we generally use pull requests on github
02:19 colomon joined #moarvm
02:22 vendethiel joined #moarvm
02:35 colomon joined #moarvm
02:38 colomon joined #moarvm
03:17 colomon joined #moarvm
05:57 brrt joined #moarvm
06:00 vendethiel joined #moarvm
06:49 FROGGS joined #moarvm
06:52 Ven joined #moarvm
06:55 kjs_ joined #moarvm
06:59 Ven joined #moarvm
07:30 Ven joined #moarvm
07:32 brrt joined #moarvm
07:40 zakharyas joined #moarvm
08:15 kjs_ joined #moarvm
08:39 rurban_ joined #moarvm
11:44 rudi_s I see. I don't like github very much.
11:45 nwc10 you could send git-am ready patches to perl6-compiler@perl.or
11:45 nwc10 er,
11:45 nwc10 perl6-compiler@perl.org
12:06 brrt yes, we do accept patches :-)
12:06 brrt may i ask why you don't like github?
12:17 jnthn The other perfectly fine workflow is to clone from github, push the repo somewhere online you *do* like, push commits to branches there, and then they can be dealt with as remotes
12:18 nwc10 oooh, I'd not tried that :-)
12:18 jnthn Which works faster than patches
12:18 jnthn Well, for me it does
12:18 * brrt agrees with jnthn
12:18 brrt you can make some really funky repo structures with remotes :-)
12:29 jnthn With regard to __attribute__((format(printf,2,3))) there is no VS equivalent afaik
12:29 timotimo that can be #ifdef'd, though?
12:29 jnthn But also it's not clear how useful it is
12:29 timotimo do i understand it correctly that that will give error messages if the ... attributes for a call don't align with printf semantics?
12:29 jnthn I'm not even sure what the darn arguments mean at first guess.
12:30 timotimo first argument means where the format string is, i bet
12:30 timotimo because our first arg is always tc
12:30 jnthn So there's as much chance of screwing up the attribute as there is of screwing up the printf, so far as I can see.
12:30 timotimo The parameter string-index specifies which argument is the format string argument (starting from 1), while first-to-check is the number of the first argument to check against the format string.
12:31 timotimo damn you, C, for not having named arguments!
12:31 jnthn Oh, but it's on the callee, not the caller
12:31 jnthn So I guess it kinda could be useful diagnostics.
12:31 timotimo of course
12:32 timotimo you can have attributes on callsites?
12:32 jnthn No idea :P
12:32 jnthn Ah, apparently there is some way in newer MSVC
12:33 timotimo is that "newer than we target"?
12:33 jnthn Well, guess I'm open to it; we don't have very many vararg things.
12:33 jnthn Yes, but again, #if :)
12:33 timotimo thank you, rudi_s, for bringing this up :)
12:34 * jnthn is happy to introduce things that stand a chance of catching real bugs, but very wary of many things that are more ceremony and about "looking like high quality code" then actually helping
12:35 jnthn That one seems to alnd on the side of "actually helps"
12:35 jnthn *land
12:43 timotimo well, rudi_s already found two cases of wrong format strings
12:44 jnthn *nod*
13:19 rudi_s brrt: Central places for everything isn't well fitted to a DVCS IMHO.
13:19 rudi_s japhb: Good idea. Give me a sec.
13:23 brrt i agree. on the other hand, federation is really hard to maintain
13:23 brrt doable? yes definitely. but no (VC) money goes to it
13:25 timotimo i wouldn't mind if we had a public mirror for all perl6 related repos on github
13:25 timotimo we do have a beefy server now ...
13:25 * brrt agrees
13:26 brrt and is also not in a position to build said mirrors
13:26 timotimo someone™ would just have to build a little thingie that keeps things up to date
13:32 rudi_s brrt, japhb: git://git.informatik.uni-erlangen.de/he29heri/moarvm/
13:33 rudi_s Repository with patches. I'v split them into "easy" and maybe problematic patches where I remove calls to functions. It should be correct, but somebody should check that.
13:34 brrt aye, i'll check it out :-)
13:34 brrt thanks for taking the time :-)
13:34 rudi_s np, it's just trivial cleanup.
13:34 jnthn .oO( you need to fetch it before you checkout it :P )
13:34 rudi_s ;D
13:35 brrt yes, you do :-)
13:35 rudi_s Btw. it might be useful to add -Wformat to catch future problems with format issues. Otherwise the __attribute__((format())) is not that useful.
13:35 brrt any idea if __attribute__((format())) works with clang?
13:35 brrt i'm forced / stuck on os x for the time being
13:36 brrt otherwise i've nothing to base on
13:36 rudi_s AFAIK yes. But haven't tested it.
13:37 rudi_s http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format <- looks like yes.
13:37 brrt (good lord the slowness of clang it never ceases to amaze me)
13:37 brrt excellent
13:37 * jnthn kicked off a build/test on MSVC
13:37 rudi_s I haven't tested it with MSVC, if it supports the format attribute the patch should be adapted.
13:39 rudi_s Regarding the last patch, I'm not sure if special characters in the file name are a problem (like "\r" or such). If you have an escape function for that in the code-base, it might be a good idea to use it instead.
13:41 [Coke] clang seems fast enough on os x, but then, I don't have much to compare it too here.
13:42 brrt what is the zu field?
13:42 brrt well, that's the thing isn't it... i'm sure jnthn fields non-parallel nmake is plenty fast too :-P
13:43 brrt (the %zu format specifier, never seen that before)
13:44 nwc10 brrt: I assume that you can get gcc via macports
13:45 nwc10 jnthn: I can test on clang (I think) but I'd prefer to have about 15 minutes to take it all the way to a spectest
13:45 * brrt should probably get gcc then
13:46 jnthn nwc10: Go for it, I've got a Rakudo build/spectest running here
13:46 jnthn NQP looks fine on MSVC with the rudi_s++ patches
13:46 nwc10 I've got to "spectesting master/master/nom with clang"
13:46 nwc10 which I'd not done before
13:48 jnthn .oO( Does running "make specktest" bring home the bacon? )
13:48 nwc10 you have a pun track mind
13:50 brrt my, what many variables have been removed
13:55 jnthn spectest looks good
13:55 nwc10 jnthn: I get to the end of the spectest
13:55 nwc10 t/spec/S17-lowlevel/lock.rakudo.moar failed during the spectest run, but happens to pass when run interactively
13:55 brrt jnthn, i have S32-list/squish.rakudo.moar TODO passing
13:55 nwc10 the clang build is very chatty
13:55 brrt but i assume that to be unrelated?
13:55 nwc10 but was without the changes
13:55 nwc10 t/spec/S32-list/squish.rakudo.moar                          (Wstat: 0 Tests: 36 Failed: 0) TODO passed:   16, 18
13:55 nwc10 me too!
13:56 brrt anyway, looks good to me
13:56 brrt can't believe we had so many unused variables
13:57 brrt shall i push, or wait until others have results?
13:57 jnthn brrt: Yes, I saw that TODO pass also
13:57 brrt perhaps a fix in rakudo?
13:58 nwc10 my results are in
13:58 jnthn brrt: Lemme finish glancing through the patches themselves
13:58 brrt np
13:59 nwc10 I admit that I've not looked into the patches (or the commit messages)
14:02 jnthn Seems fine overall
14:03 jnthn I'd be a bit more inclined to just toss the unused functions in 712b5582c0a than comment them
14:05 brrt yeah, me too
14:06 brrt i can rebase that to a delete, but i don't think it's worth it
14:06 brrt what is more of these functions i can believe that 'one day' they'll be usefull
14:07 dalek MoarVM: fd011ba | (Simon Ruderich)++ | src/moar.h:
14:07 dalek MoarVM: moar.h: mark MVM_vm_set_exec_name as MVM_NO_RETURN
14:07 dalek MoarVM:
14:07 dalek MoarVM: Also fixes a compiler warning for main().
14:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fd011ba514
14:08 brrt sorry dalek!
14:08 dalek joined #moarvm
14:08 [Coke] in general, if we're not using them, I'd remove them. maybe open an issue to track that they were removed and what commit hash if someone wants to try to retrieve them later. unused code is a maintenance issue.
14:08 timotimo jnthn: do you think it'd be all right if the eventloop thread would get a signal the event loop can wait for to handle the gc synchronisation stuff?
14:09 brrt in general i agree. but this is serialization stuff. it's not unthinkable that one day we'd need a read_int64 and a read_int32
14:09 brrt and nobody is going to find these functions if we bury them in history
14:10 jnthn [Coke], brrt: Actually they are about identical to some functions in serialization.c that are used
14:10 jnthn So you can find a similar one to steal easy enough :)
14:11 jnthn timotimo: There's probably an even better way
14:12 jnthn timotimo: In that the GC understands threads that are unable to join in, so we really need to clear/set that each time around the event loop, and I think there is a way to arrange for that to happen.
14:14 timotimo that sounds good
14:15 jnthn That whole area needs a re-visit at some point soonish
14:15 timotimo brrt: is there a good reason why reading 64bit and 32bit ints would be superior to varints?
14:15 timotimo perhaps if we know that the higher bits are very likely to be set or something
14:15 jnthn Some bits of it were very much "make this work so we can figure out the Perl 6 level pieces"
14:16 timotimo ah, sure
14:16 timotimo i should start the weekly
14:17 rudi_s brrt: %zu is the specifier for size_t.
14:17 timotimo oh, good to know
14:23 cygx joined #moarvm
14:24 cygx o/
14:24 cygx any thoughts on http://irclog.perlgeek.de/moarvm/2015-03-27#i_10352051 ?
14:24 nwc10 IIRC %zu is C99, but I've no idea how many really grumpy C89 only C compilers remain (of interest)
14:25 brrt i have no idea btw :-)
14:25 brrt \o cygx
14:25 rudi_s nwc10: It is.
14:25 cygx Does MSVC support the 'z' modifier nowadays? IIRC, it did not in the past...
14:25 rudi_s If not, the patches need an update and a few more casts.
14:26 nwc10 given jnthn's build completed, I infer that *his* MVSC (at least) is happy with it
14:26 cygx nwc10: just because it builds does not mean it works as intended
14:27 brrt cygx - the memorization can be implemented in a simpler way, iirc
14:27 brrt i have implemented that a once looong time ago, without moarvm changes
14:27 brrt let me see if i can dig up the commit
14:28 nwc10 cygx: that's a good point.
14:28 nwc10 if the code path is never exercised by a test, problems won't be spotted, because it has to go wrong at runtime.
14:29 timotimo cygx: i'd love for us to have bytecode loading from memory :)
14:29 brrt can't find it :-(
14:30 brrt but anyway, it's a good feature, that's for sure
14:32 cygx Microsoft's C runtime shipped on my machine apparently does not understand %zu
14:33 cygx apparently, it should be spelled %Iu in MS land
15:06 brrt that's lame
15:20 synopsebot joined #moarvm
16:41 kjs_ joined #moarvm
17:26 colomon joined #moarvm
17:47 kjs_ joined #moarvm
17:48 ShimmerFairy joined #moarvm
17:58 kjs_ joined #moarvm
17:59 FROGGS joined #moarvm
18:01 kjs_ joined #moarvm
18:13 brrt joined #moarvm
19:18 rurban_ joined #moarvm
19:44 kjs_ joined #moarvm
19:47 brrt joined #moarvm
19:52 rudi_s I guess it's time a for a new macro ...
19:53 rudi_s If you tell me how I should call it, I can update my patch.
19:53 FROGGS marco?
19:53 rudi_s %zu vs. %Iu for size_t.
19:56 brrt hmm, somethng like SIZE_T_PRINTF_FORMAT_SPECIFIER :-P
19:56 FROGGS sorry, marco already was my suggestion :S
19:56 FROGGS ahh, it is about sprintf
19:57 brrt or may PRIszt like PRIx32 etc
19:57 jnthn Prefix any macros we add with MVM_
19:57 brrt nryyrt yry
19:57 brrt .. that's what i was about to say
19:57 brrt :-)
19:57 jnthn MVM_FORMAT_SIZE_T or so
19:58 brrt for what it's worth, apparantly git federation isn't hard at all
19:58 * brrt should get his own server
19:59 brrt btw, i've sadly lost the patches to fakexecutable perl6, but i know nwc10 was also working on it
19:59 FROGGS there is also stuff in the execname branches... though I dunno how useful that is
20:00 brrt rudi_s - is your server down perchance?
20:00 brrt i can't fetch from here
20:17 rudi_s brrt: Should work fine.
20:18 brrt should be git://git.informatik.uni-er​langen.de/he29heri/moarvm/ right
20:19 rudi_s Yeah.
20:47 brrt hmm
20:50 brrt must've typoed
20:50 brrt now it works
21:03 brrt for those interested, I have nearly finished my hague grant application: https://docs.google.com/document/d/18Uofes2m79GvfHm_XFlu0_G18meLp4Tks0tDwAcrvtY/edit?usp=sharing
21:03 brrt it needs a better description of benefits, for one thing
21:19 timotimo yay, bart gets monies!
21:19 brrt free money!
21:20 brrt many hacking!
21:20 timotimo i'm glad to see you possibly get sponsored
21:22 brrt i hope it'll work out
21:26 kjs_ joined #moarvm
21:27 jnthn brrt: Taking a look :)
21:27 brrt thanks
21:30 jnthn "These deliverables are not ordered chronologically."
21:30 jnthn Is there any way they could be? :)
21:31 jnthn "Moreover because each part is independent even very simple optimizations across fragment boundaries are impossible or very hard."
21:31 jnthn That'd benefit from a comma or two :)
21:31 * brrt looks at it
21:31 jnthn After the Moreover and the independent
21:32 brrt added :-)
21:33 brrt dynasm is just about the densest C code I have ever seen
21:34 brrt and it's author thinks nothing of goto-ing into an else {} block
21:35 timotimo i thought dynasm was lua
21:35 timotimo shows how much i know :P
21:35 timotimo i thought it's lua code that generates c code, that is
21:35 jnthn "Moreover because each part is independent even very simple optimizations across fragment boundaries are impossible or very hard."
21:35 jnthn oops
21:36 jnthn "I will report on my work using my blog as I have done last year"
21:36 jnthn I'd add "during GSoC" to the end there maybe
21:36 brrt ah yes
21:37 jnthn "Worhtington"...who's that guy? :P
21:38 timotimo tingtong?
21:39 brrt damnit i'm a misspelling fool
21:39 brrt better this way.. right :-)
21:39 jnthn "many talks at perl conferences" may want Perl capitalized :)
21:40 jnthn There's a "perl6" that could be "Perl 6" in the benefits section, but you said you're still working on that... :)
21:40 brrt yes
21:41 brrt of course one of the benefits is 'this is a lot of fun for me' but i don't think that is really convincing to TPF
21:42 jnthn aye :)
21:44 timotimo it might be taken as a sign for "i'll finish this for sure"
21:46 brrt that is true
21:47 [Coke] I would recommend not adding that as a reason. :P
21:48 jnthn I'd expand on higher performance a bit
21:49 jnthn It's "less CPU instructions to execute, producing greater speed and using less memory."
21:49 brrt right
21:50 timotimo i was idly wondering if our jit (or spesh) stage would benefit from loop unrolling at all
21:50 jnthn "This will help make Perl 6's performance more competitive."
21:50 timotimo also, when/how do we emit gc sync points in tight loops?
21:51 jnthn timotimo: At the moment, probably all over the palace, but we only need to emit them on back branches.
21:51 brrt jnthn: you're going to forgive me for plagiarizing that
21:51 brrt right :-)
21:51 jnthn brrt: Apparently :)
21:51 timotimo can back branches be determined just by comparing bb index?
21:52 brrt no
21:52 brrt that is indeed a bit harder a problem than it looks
21:52 brrt but
21:53 brrt back branches are always non-successor branches
21:53 timotimo for something as simple as deciding where to put GC sync points, probably not as terrible to not always be right
21:53 brrt (loop detection is a thing of its own, btw :-))
21:53 brrt no but it also used e.g. for register allocation
21:53 timotimo i'm not going to fall into the trap of saying "how hard could it be" :P
21:53 timotimo we don't do smart register allocation yet anyway
21:54 timotimo at least not after the mast compiler is through
21:54 brrt read the book: http://www.amazon.co.uk/Compilers-Principles-Techniques-Alfred-Aho/dp/0321491696/ref=sr_1_2?ie=UTF8&amp;qid=1427752445&amp;sr=8-2&amp;keywords=compilers+aho :-P
21:54 jnthn timotimo: I think brrt is talking about CPU register allocation :)
21:54 timotimo oh, fair enough
21:54 brrt yeah, i am :-)
21:54 jnthn The mast compiler makes a pretty good effort.
21:54 timotimo wow, expensive book
21:55 brrt iirc global register allocation has combinatorial difficulty problems
21:55 timotimo but probably also expansive
21:55 timotimo yeah
21:55 timotimo i remember that part; same thing as graph coloring, no?
21:57 brrt iirc, yes
21:57 brrt (the hardcover one sells for 168 euro :-o)
21:57 timotimo ugh
21:58 timotimo is it out of print or something?
21:59 brrt i guess so
21:59 timotimo d'oh, not much progress on the weekly yet
21:59 timotimo and it's almost midnight
22:00 brrt oh, good luck on that :-)
22:00 * brrt is going to sleep for now
22:00 jnthn 'night, brrt
22:01 timotimo gnite brrt!
22:01 brrt 'night all
22:01 timotimo man, i'm looking forward to that
22:02 jnthn Sleep? :)
22:03 timotimo nah, the jit after brrt's pleased with it :)
22:04 jnthn ah :)
23:11 rudi_s Pushed a few more patches to fix warnings to git://git.informatik.uni-erlangen.de/he29heri/moarvm/
23:45 dalek joined #moarvm

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