00:07 colomon joined
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
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.
Something like MVM_exception_throw_adhoc(tc, "Failed to open file %s: %s", fname, uv_strerror(req.result)); - untested. 00:12
(Might a bit problematic with non-ascii filenames though.) 00:13
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:14
TimToady yeah, looks pretty LTA to me... 00:15
rudi_s LTA? 00:17
TimToady Less Than Awesome 00:18
rudi_s Ah.
TimToady sorry, a meme that's more current in #perl6 than here...
rudi_s np ;-) 00:19
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:20
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:23
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:28
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.)
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.
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.
(Plus, remember we want to be clean on VC++, clang, gcc, ...) 00:30
00:31 colomon joined
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:32
00:45 colomon joined 01:45 colomon joined
rudi_s Is there a mailing list where I can submit the patches? 02:11
TimToady we generally use pull requests on github 02:15
02:19 colomon joined 02:22 vendethiel joined 02:35 colomon joined 02:38 colomon joined 03:17 colomon joined 05:57 brrt joined 06:00 vendethiel joined 06:49 FROGGS joined 06:52 Ven joined 06:55 kjs_ joined 06:59 Ven joined 07:30 Ven joined 07:32 brrt joined 07:40 zakharyas joined 08:15 kjs_ joined 08:39 rurban_ joined
rudi_s I see. I don't like github very much. 11:44
nwc10 you could send git-am ready patches to [email@hidden.address] 11:45
er,
[email@hidden.address]
brrt yes, we do accept patches :-) 12:06
may i ask why you don't like github?
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:17
nwc10 oooh, I'd not tried that :-) 12:18
jnthn Which works faster than patches
Well, for me it does
brrt agrees with jnthn
you can make some really funky repo structures with remotes :-)
jnthn With regard to __attribute__((format(printf,2,3))) there is no VS equivalent afaik 12:29
timotimo that can be #ifdef'd, though?
jnthn But also it's not clear how useful it is
timotimo do i understand it correctly that that will give error messages if the ... attributes for a call don't align with printf semantics?
jnthn I'm not even sure what the darn arguments mean at first guess.
timotimo first argument means where the format string is, i bet 12:30
because our first arg is always tc
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.
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.
damn you, C, for not having named arguments! 12:31
jnthn Oh, but it's on the callee, not the caller
So I guess it kinda could be useful diagnostics.
timotimo of course
you can have attributes on callsites? 12:32
jnthn No idea :P
Ah, apparently there is some way in newer MSVC
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.
Yes, but again, #if :)
timotimo thank you, rudi_s, for bringing this up :)
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:34
That one seems to alnd on the side of "actually helps" 12:35
*land
timotimo well, rudi_s already found two cases of wrong format strings 12:43
jnthn *nod* 12:44
rudi_s brrt: Central places for everything isn't well fitted to a DVCS IMHO. 13:19
japhb: Good idea. Give me a sec.
brrt i agree. on the other hand, federation is really hard to maintain 13:23
doable? yes definitely. but no (VC) money goes to it
timotimo i wouldn't mind if we had a public mirror for all perl6 related repos on github 13:25
we do have a beefy server now ...
brrt agrees
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
rudi_s brrt, japhb: git://git.informatik.uni-erlangen.de/he29heri/moarvm/ 13:32
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:33
brrt aye, i'll check it out :-) 13:34
thanks for taking the time :-)
rudi_s np, it's just trivial cleanup.
jnthn
.oO( you need to fetch it before you checkout it :P )
rudi_s ;D
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.
brrt any idea if __attribute__((format())) works with clang?
i'm forced / stuck on os x for the time being
otherwise i've nothing to base on 13:36
rudi_s AFAIK yes. But haven't tested it.
clang.llvm.org/docs/AttributeRefere...gnu-format <- looks like yes. 13:37
brrt (good lord the slowness of clang it never ceases to amaze me)
excellent
jnthn kicked off a build/test on MSVC
rudi_s I haven't tested it with MSVC, if it supports the format attribute the patch should be adapted.
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:39
[Coke] clang seems fast enough on os x, but then, I don't have much to compare it too here. 13:41
brrt what is the zu field? 13:42
well, that's the thing isn't it... i'm sure jnthn fields non-parallel nmake is plenty fast too :-P
(the %zu format specifier, never seen that before) 13:43
nwc10 brrt: I assume that you can get gcc via macports 13:44
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
jnthn nwc10: Go for it, I've got a Rakudo build/spectest running here 13:46
NQP looks fine on MSVC with the rudi_s++ patches
nwc10 I've got to "spectesting master/master/nom with clang"
which I'd not done before
jnthn
.oO( Does running "make specktest" bring home the bacon? )
 13:48
nwc10 you have a pun track mind
brrt my, what many variables have been removed 13:50
jnthn spectest looks good 13:55
nwc10 jnthn: I get to the end of the spectest
t/spec/S17-lowlevel/lock.rakudo.moar failed during the spectest run, but happens to pass when run interactively
brrt jnthn, i have S32-list/squish.rakudo.moar TODO passing
nwc10 the clang build is very chatty
brrt but i assume that to be unrelated?
nwc10 but was without the changes
t/spec/S32-list/squish.rakudo.moar (Wstat: 0 Tests: 36 Failed: 0) TODO passed: 16, 18
me too!
brrt anyway, looks good to me 13:56
can't believe we had so many unused variables
shall i push, or wait until others have results? 13:57
jnthn brrt: Yes, I saw that TODO pass also
brrt perhaps a fix in rakudo?
nwc10 my results are in 13:58
jnthn brrt: Lemme finish glancing through the patches themselves
brrt np
nwc10 I admit that I've not looked into the patches (or the commit messages) 13:59
jnthn Seems fine overall 14:02
I'd be a bit more inclined to just toss the unused functions in 712b5582c0a than comment them 14:03
brrt yeah, me too 14:05
i can rebase that to a delete, but i don't think it's worth it 14:06
what is more of these functions i can believe that 'one day' they'll be usefull
dalek arVM: fd011ba | (Simon Ruderich)++ | src/moar.h:
moar.h: mark MVM_vm_set_exec_name as MVM_NO_RETURN

Also fixes a compiler warning for main().		 14:07
brrt sorry dalek! 14:08
14:08 dalek joined
[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?
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
and nobody is going to find these functions if we bury them in history
jnthn [Coke], brrt: Actually they are about identical to some functions in serialization.c that are used 14:10
So you can find a similar one to steal easy enough :)
timotimo: There's probably an even better way 14:11
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:12
timotimo that sounds good 14:14
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?
perhaps if we know that the higher bits are very likely to be set or something
jnthn Some bits of it were very much "make this work so we can figure out the Perl 6 level pieces"
timotimo ah, sure 14:16
i should start the weekly
rudi_s brrt: %zu is the specifier for size_t. 14:17
timotimo oh, good to know
14:23 cygx joined
cygx o/ 14:24
any thoughts on irclog.perlgeek.de/moarvm/2015-03-27#i_10352051 ?
nwc10 IIRC %zu is C99, but I've no idea how many really grumpy C89 only C compilers remain (of interest)
brrt i have no idea btw :-) 14:25
\o cygx
rudi_s nwc10: It is.
cygx Does MSVC support the 'z' modifier nowadays? IIRC, it did not in the past...
rudi_s If not, the patches need an update and a few more casts.
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
brrt cygx - the memorization can be implemented in a simpler way, iirc 14:27
i have implemented that a once looong time ago, without moarvm changes
let me see if i can dig up the commit
nwc10 cygx: that's a good point. 14:28
if the code path is never exercised by a test, problems won't be spotted, because it has to go wrong at runtime.
timotimo cygx: i'd love for us to have bytecode loading from memory :) 14:29
brrt can't find it :-(
but anyway, it's a good feature, that's for sure 14:30
cygx Microsoft's C runtime shipped on my machine apparently does not understand %zu 14:32
apparently, it should be spelled %Iu in MS land 14:33
brrt that's lame 15:06
15:20 synopsebot joined 16:41 kjs_ joined 17:26 colomon joined 17:47 kjs_ joined 17:48 ShimmerFairy joined 17:58 kjs_ joined 17:59 FROGGS joined 18:01 kjs_ joined 18:13 brrt joined 19:18 rurban_ joined 19:44 kjs_ joined 19:47 brrt joined
rudi_s I guess it's time a for a new macro ... 19:52
If you tell me how I should call it, I can update my patch. 19:53
FROGGS marco?
rudi_s %zu vs. %Iu for size_t.
brrt hmm, somethng like SIZE_T_PRINTF_FORMAT_SPECIFIER :-P 19:56
FROGGS sorry, marco already was my suggestion :S
ahh, it is about sprintf
brrt or may PRIszt like PRIx32 etc 19:57
jnthn Prefix any macros we add with MVM_
brrt nryyrt yry
.. that's what i was about to say
:-)
jnthn MVM_FORMAT_SIZE_T or so
brrt for what it's worth, apparantly git federation isn't hard at all 19:58
brrt should get his own server
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
brrt rudi_s - is your server down perchance? 20:00
i can't fetch from here
rudi_s brrt: Should work fine. 20:17
brrt should be git://git.informatik.uni-er​langen.de/he29heri/moarvm/ right 20:18
rudi_s Yeah. 20:19
brrt hmm 20:47
must've typoed 20:50
now it works
for those interested, I have nearly finished my hague grant application: docs.google.com/document/d/18Uofes...sp=sharing 21:03
it needs a better description of benefits, for one thing
timotimo yay, bart gets monies! 21:19
brrt free money!
many hacking! 21:20
timotimo i'm glad to see you possibly get sponsored
brrt i hope it'll work out 21:22
21:26 kjs_ joined
jnthn brrt: Taking a look :) 21:27
brrt thanks
jnthn "These deliverables are not ordered chronologically." 21:30
Is there any way they could be? :)
"Moreover because each part is independent even very simple optimizations across fragment boundaries are impossible or very hard." 21:31
That'd benefit from a comma or two :)
brrt looks at it
jnthn After the Moreover and the independent
brrt added :-) 21:32
dynasm is just about the densest C code I have ever seen 21:33
and it's author thinks nothing of goto-ing into an else {} block 21:34
timotimo i thought dynasm was lua 21:35
shows how much i know :P
i thought it's lua code that generates c code, that is
jnthn "Moreover because each part is independent even very simple optimizations across fragment boundaries are impossible or very hard."
oops
"I will report on my work using my blog as I have done last year" 21:36
I'd add "during GSoC" to the end there maybe
brrt ah yes
jnthn "Worhtington"...who's that guy? :P 21:37
timotimo tingtong? 21:38
brrt damnit i'm a misspelling fool 21:39
better this way.. right :-)
jnthn "many talks at perl conferences" may want Perl capitalized :)
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
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:41
jnthn aye :) 21:42
timotimo it might be taken as a sign for "i'll finish this for sure" 21:44
brrt that is true 21:46
[Coke] I would recommend not adding that as a reason. :P 21:47
jnthn I'd expand on higher performance a bit 21:48
It's "less CPU instructions to execute, producing greater speed and using less memory." 21:49
brrt right
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."
timotimo also, when/how do we emit gc sync points in tight loops?
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
right :-)
jnthn brrt: Apparently :)
timotimo can back branches be determined just by comparing bb index?
brrt no 21:52
that is indeed a bit harder a problem than it looks
but
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
brrt (loop detection is a thing of its own, btw :-))
no but it also used e.g. for register allocation
timotimo i'm not going to fall into the trap of saying "how hard could it be" :P
we don't do smart register allocation yet anyway
at least not after the mast compiler is through 21:54
brrt read the book: www.amazon.co.uk/Compilers-Principl...pilers+aho :-P
jnthn timotimo: I think brrt is talking about CPU register allocation :)
timotimo oh, fair enough
brrt yeah, i am :-)
jnthn The mast compiler makes a pretty good effort.
timotimo wow, expensive book
brrt iirc global register allocation has combinatorial difficulty problems 21:55
timotimo but probably also expansive
yeah
i remember that part; same thing as graph coloring, no?
brrt iirc, yes 21:57
(the hardcover one sells for 168 euro :-o)
timotimo ugh
is it out of print or something? 21:58
brrt i guess so 21:59
timotimo d'oh, not much progress on the weekly yet
and it's almost midnight
brrt oh, good luck on that :-) 22:00
brrt is going to sleep for now
jnthn 'night, brrt
timotimo gnite brrt! 22:01
brrt 'night all
timotimo man, i'm looking forward to that
jnthn Sleep? :) 22:02
timotimo nah, the jit after brrt's pleased with it :) 22:03
jnthn ah :) 22:04
rudi_s Pushed a few more patches to fix warnings to git://git.informatik.uni-erlangen.de/he29heri/moarvm/ 23:11
23:45 dalek 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!