Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-01-22

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

All times shown according to UTC.

Time Nick Message
02:01 timotimo tbh i had hoped for a bit of praise :P
02:14 Ven joined #moarvm
02:40 brokenchicken W00t! Amazing! timotimo++ Job well done!
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:31 Ven joined #moarvm
04:05 samcv timotimo, sorry good work :)
04:05 samcv working on getting them generating without any 'gaps'
04:06 samcv i had surgury a few days ago which is why i was afk for a long while, so still not totally with it
04:07 Ven joined #moarvm
04:10 samcv as of this change we won't have any 0 value base 40 numbers either :) (though one at the end of everything is possible)
04:15 Ven joined #moarvm
04:18 samcv nice 470K => 402K
04:23 Ven_ joined #moarvm
05:40 samcv timotimo, names.c now works with removing one line. look me a bit to figure out how it worked, but here's the change https://github.com/samcv/UCD/commit/20c96e860b188cf7034ed8618f5bf8492272ff27
06:10 Ven joined #moarvm
07:13 Ven joined #moarvm
07:37 Ven joined #moarvm
07:59 FROGGS joined #moarvm
09:05 domidumont joined #moarvm
09:10 domidumont joined #moarvm
09:18 Geth MoarVM: 7f591ea159 | (Daniel Green)++ | 12 files
09:18 Geth MoarVM: Change tabs to spaces
09:18 Geth MoarVM:
09:18 Geth MoarVM: To be consistent with the rest of the source.
09:18 Geth MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7f591ea159
09:18 Geth MoarVM: 76872dbe71 | (Jimmy Zhuo)++ | 12 files
09:18 Geth MoarVM: Merge pull request #510 from MasterDuke17/change_tabs_to_spaces
09:18 Geth MoarVM:
09:18 Geth MoarVM: Change tabs to spaces
09:18 Geth MoarVM: review: https://github.com/MoarVM/MoarVM/commit/76872dbe71
09:27 domidumont joined #moarvm
09:29 domidumont joined #moarvm
12:22 timotimo ah, that line could have done with a comment like "flush the queue"
13:47 mst so ... add such a comment?
13:48 timotimo well, samcv already understands what's going on in that line
13:48 timotimo i don't expect that code to last much longer
13:48 timotimo though i guess for historical reasons it'd be interesting?
14:08 mst even if you expect the code to be nuked, it's probably still worth it since (a) code often lasts longer than expected (b) people looking at the new code will likely look at the last release containing the old code to compare
14:08 mst (c) basically it can't hurt
14:23 zakharyas joined #moarvm
14:40 geekosaur joined #moarvm
14:49 MasterDuke is there a way to silence/fix the remaining two warnings (`implicit declaration of function ‘pthread_yield’`) when building moar?
14:56 jnthn MasterDuke: Probably, but iirc the last attempt somebody made at fixing tht totally broke the build on some platform.
14:59 MasterDuke ah, then i'm just going to keep on ignoring them
15:00 jnthn Yeah, that's what I've done too ;)
16:03 dogbert17 jnthn: are you around?
16:04 dogbert17 have a gist (wrt MoarVM Issue #234) that possibly might be of interest: https://gist.github.com/dogbert17/b9f7edee2b6734aae21ae0bee21ff4f6
16:10 nwc10 according to the wisdom of the internet the correct fix is to replace pthread_yield() with sched_yield()
16:19 samcv timotimo, not sure if this was the off by one error you were seeing, but with the latest changes: https://gist.github.com/4e54b6566d953369614d0f74d7e8de19
16:28 samcv oh just fixed the off by one. it's lined up properly now. wasn't a problem with the c code at all
16:31 domidumont joined #moarvm
16:33 timotimo yes, i fixed it in the p6 code
16:34 timotimo the off-by-one was what made MARTIAL ARTS UNIFORM b0rk, and i pointed out in the pr comments that i fixed it
16:37 jnthn dogbert17: Seems to give a hint of what's going on, at least
16:38 jnthn nwc10: (sched_yield) that sounds...familiar :)
16:40 dogbert17 jnthn: made the loop smaller so that the (Too many open files) shouldn't have anything to do with it
16:40 dogbert17 and 32k nursery
16:43 jnthn Ah, here's the history: https://github.com/MoarVM/MoarVM/commit/0194409f7599850d73b8861cd26d2fe9b9f7f85b
16:43 jnthn So, switching to sched_yield was not the thing we tried
16:43 jnthn So, we can try that :)
16:44 timotimo why don't we just #ifndef that? :)
16:44 timotimo or are there platforms that pthread_yield with an argument?
16:45 geekosaur more likely platforms that have it return (void)
16:49 timotimo we don't care about the return value anywhere in the code, i don't think
16:49 timotimo so just defining it to be void(void) should be fine
16:50 geekosaur the point is, on platforms that *do* have it defined, your redefinition must match
16:50 geekosaur or you will get a compile error
16:50 timotimo no
16:50 timotimo i already said we #ifnde it
16:50 geekosaur and the define you use is?
16:51 geekosaur (if you are already checking for a valid prototype then it should have been conditional already. if you weren't, there is no preprocessor symbol you can use to test for it)
16:53 timotimo ...?
16:54 timotimo #ifndef pthread_yield void pthread_yield(void); #endif
16:54 geekosaur you arer confusing macros with functions
16:55 timotimo are you sure you can't #ifndef a symbol?
16:56 geekosaur a C function symbol? yes
16:56 geekosaur it is not a preprocessor macro
16:56 geekosaur it is not considered defined by the preprocessor
16:56 timotimo oh!
16:56 timotimo i was under the impression that you could do that, and even #undef things
16:56 geekosaur only if it's a macro
16:56 geekosaur some things are, many are not
16:57 timotimo got to go! :)
20:45 ggoebel joined #moarvm
21:23 ggoebel joined #moarvm

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