Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-10-24

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

All times shown according to UTC.

Time Nick Message
00:23 Zoffix Is there a macro for MacOS-only code, same as we got `#if defined _WIN32` ?
00:54 samcv Zoffix, yeah. uhm platform/memmem.c prolly has it
00:54 samcv or i think it's memmem.h
00:55 samcv defined(__APPLE__) || defined(__Darwin__) is what you want Zoffix
00:56 Zoffix Thanks
01:16 Zoffix Is MVM_platform_is_fd_seekable a crap name? Like is this just internal or what?
01:17 Zoffix This is in same place as MVM_platform_lseek
01:56 ilbot3 joined #moarvm
01:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:02 samcv Zoffix, doesn't sound too bad
02:37 Geth ¦ MoarVM/fix-macos-eof: 24007720d5 | (Zoffix Znet)++ | 5 files
02:37 Geth ¦ MoarVM/fix-macos-eof: Fix seekability detection on MacOS
02:37 Geth ¦ MoarVM/fix-macos-eof:
02:37 Geth ¦ MoarVM/fix-macos-eof: POSIX does not define which devices must support lseek() and on
02:37 Geth ¦ MoarVM/fix-macos-eof: MacOS it returns some non-zero value that isn't -1 indicating failure
02:37 Geth ¦ MoarVM/fix-macos-eof: when lseek()ing TTY STDIN. This results in such handles marked
02:37 Geth ¦ MoarVM/fix-macos-eof: as seekable and in turn causes issues, such as mvm_eof() trying
02:37 Geth ¦ MoarVM/fix-macos-eof: to figure out whether we've reached EOF and falsely returning True
02:37 Geth ¦ MoarVM/fix-macos-eof: <…commit message has 17 more lines…>
02:38 Geth ¦ MoarVM/fix-macos-eof: review: https://github.com/MoarVM/MoarVM/commit/24007720d5
02:43 Geth ¦ MoarVM: zoffixznet++ created pull request #731: Fix seekability detection on MacOS
02:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/731
03:02 Zoffix whoops, missing semicolon on win32
03:02 Zoffix And my other attempt to spectest it on macos looks to have hung. Something tells me this PR is nasty for perf/resources
03:02 Zoffix oh wait, it completed after I poked it.. Says "test run interrupted" but then still says Files=670, Tests=37079, 2394 wallclock secs (13.25 usr  3.32 sys + 2124.93 cusr 158.12 csys = 2299.62 CPU)
03:03 Geth ¦ MoarVM/fix-macos-eof: 97fc8bf61d | (Zoffix Znet)++ | 5 files
03:03 Geth ¦ MoarVM/fix-macos-eof: Fix seekability detection on MacOS
03:03 Geth ¦ MoarVM/fix-macos-eof:
03:03 Geth ¦ MoarVM/fix-macos-eof: POSIX does not define which devices must support lseek() and on
03:03 Geth ¦ MoarVM/fix-macos-eof: MacOS it returns some non-zero value that isn't -1 indicating failure
03:03 Geth ¦ MoarVM/fix-macos-eof: when lseek()ing TTY STDIN. This results in such handles marked
03:03 Geth ¦ MoarVM/fix-macos-eof: as seekable and in turn causes issues, such as mvm_eof() trying
03:03 Geth ¦ MoarVM/fix-macos-eof: to figure out whether we've reached EOF and falsely returning True
03:03 Geth ¦ MoarVM/fix-macos-eof: <…commit message has 17 more lines…>
03:03 Geth ¦ MoarVM/fix-macos-eof: review: https://github.com/MoarVM/MoarVM/commit/97fc8bf61d
03:03 Zoffix (just fixed the win32 typo)
03:11 evalable6 joined #moarvm
06:04 evalable6 joined #moarvm
06:19 rba joined #moarvm
06:23 rba joined #moarvm
06:44 domidumont joined #moarvm
07:02 rba_ joined #moarvm
07:03 brrt joined #moarvm
07:09 domidumont joined #moarvm
07:13 brrt good * #moarvm
07:13 timotimo hey brrt
07:13 brrt i've been doing some of that old thinking
07:14 brrt it occured to me that a within-template conditional-before-unconditional-use, we can detect at precompilation time
07:14 nwc10 that's dangerous. are you sure you want to admit to it?
07:15 brrt can't help it
07:16 brrt and cross-template is virtually impossible by construction; it'd be possible the optimizer could protect against it
07:16 brrt *could cuase it and have to protect against it
07:26 timotimo the only way i see to make the int cache sane in the face of rebless is to have a flag set on the int cache objects that forces a rebless to first do a clone
07:35 timotimo cool, that seems to work at first glance
07:40 timotimo i wonder if that'd be allowed in the release?
07:41 timotimo probably better for after.
07:44 timotimo right now it goes via div_I and skips the int cache entirely, which is not terribly problematic
07:44 timotimo after this, though, the int cache can be used for div_I as well
07:46 timotimo ah crap
07:47 timotimo S14-roles/parameterized-mixin relies on being able to mix into an Int with does and having the effect reflected properly in the variable that used to hold it
07:48 timotimo not an unreasonable request by any stretch
07:49 lizmat Q: can I nqp::clone an nqp::list threadsafely ?
07:49 lizmat as in: can it never cause a segfault or other internal corruption?
07:50 timotimo i expect it can crash
07:50 timotimo imagine you're cloning a gigantic list on one thread and at the same time another thread resizes it
07:50 timotimo the resizing thread would free the data blob and poof
07:51 lizmat ok, but reading from it should be ok, right?
07:51 timotimo reading from what?
07:51 timotimo you mean reading a list while another thread clones it?
07:51 lizmat if one thread is reading from an nqp::list, and another thread is resizing it ?
07:51 timotimo can still cause problems
07:52 lizmat actually, more specifically, doing an nqp::elems on it
07:52 timotimo oh, nqp::elems is less problematic
07:52 timotimo let me have a closer look
07:52 lizmat cause I think that's the underlying issue with rakudo issue 1220
07:53 timotimo yeah, the elems count lives directly on the object; when the list resizes, the elems count gets written to, but the worst you could possibly get is a value that's half-updated
07:53 lizmat that would be fine, as long as it doesn't make it crash :-)
07:54 timotimo it's a 64 bit unsigned int; whether one thread reading while another is writing can cause a corrupted value to be read depends on the architecture of the machine in question
07:54 lizmat hmmm.. shouldn't that then be atomicinted ?
07:54 timotimo reading it atomically seems like an option until you realize that the maximum size of an atomic int might be smaller on some systems (and also atomic updates are noticably slower)
07:55 lizmat hmmm...
08:07 samcv tested the Alpine build. works fine
08:08 samcv though some nativecall things seem to fail. but it builds. going to see what the NativeCall things are
08:10 samcv rakudo t/04-nativecall/08-callbacks.t and 21-callback-other-thread.t fail
08:19 evalable6 joined #moarvm
08:38 rba joined #moarvm
08:44 bartolin joined #moarvm
08:54 rba joined #moarvm
09:09 rba joined #moarvm
09:20 zakharyas joined #moarvm
09:21 AlexDaniel` would be great to have some eyes on https://github.com/MoarVM/MoarVM/pull/731 before the release
09:22 rba_ joined #moarvm
09:23 timotimo maybe someone can implement what geekosaur suggested
09:27 timotimo i wonder how often the "is_seekable" is called in a regular program
09:38 rba joined #moarvm
11:52 lizmat I think I now fixed all of the HLL race conditions of Rakudo issue 1202
12:09 lizmat MoarVM panic: Heap corruption detected: pointer 0x10b508430 to past fromspace
12:09 lizmat after 8.5 minutes on an unloaded system
12:11 lizmat MoarVM panic: Heap corruption detected: pointer 0x1119a2580 to past fromspace  (after 42 seconds)
12:17 synopsebot joined #moarvm
12:29 lizmat .tell jnthn I think I've reduced https://github.com/rakudo/rakudo/issues/1202 to a pure MoarVM issue
12:29 yoleaux lizmat: I'll pass your message to jnthn.
13:00 brrt joined #moarvm
13:30 ggoebel joined #moarvm
14:08 brrt joined #moarvm
14:09 zakharyas joined #moarvm
14:22 buggable joined #moarvm
14:42 Zoffix New blog post: "Rakudo Perl 6 Advent Calendar 2017 Call for Authors": https://rakudo.party/post/Rakudo-Perl-6-Advent-Calendar-2017--Call-for-Authors
15:07 zakharyas joined #moarvm
15:19 brrt joined #moarvm
16:09 zakharyas joined #moarvm
16:12 samcv Zoffix++
16:12 domidumont joined #moarvm
16:12 Geth ¦ MoarVM/fix-macos-eof: a13b23a36c | (Zoffix Znet)++ | 5 files
16:12 Geth ¦ MoarVM/fix-macos-eof: Fix seekability detection on MacOS
16:12 Geth ¦ MoarVM/fix-macos-eof:
16:12 Geth ¦ MoarVM/fix-macos-eof: POSIX does not define which devices must support lseek() and on
16:12 Geth ¦ MoarVM/fix-macos-eof: MacOS it returns some non-zero value that isn't -1 indicating failure
16:12 Geth ¦ MoarVM/fix-macos-eof: when lseek()ing TTY STDIN. This results in such handles marked
16:12 Geth ¦ MoarVM/fix-macos-eof: as seekable and in turn causes issues, such as mvm_eof() trying
16:12 Geth ¦ MoarVM/fix-macos-eof: to figure out whether we've reached EOF and falsely returning True
16:12 Geth ¦ MoarVM/fix-macos-eof: <…commit message has 17 more lines…>
16:12 Geth ¦ MoarVM/fix-macos-eof: review: https://github.com/MoarVM/MoarVM/commit/a13b23a36c
16:17 brrt joined #moarvm
16:18 Geth ¦ MoarVM/fix-macos-eof: a82770334b | (Zoffix Znet)++ | 5 files
16:18 Geth ¦ MoarVM/fix-macos-eof: Fix seekability detection on MacOS
16:18 Geth ¦ MoarVM/fix-macos-eof:
16:18 Geth ¦ MoarVM/fix-macos-eof: POSIX does not define which devices must support lseek() and on
16:18 Geth ¦ MoarVM/fix-macos-eof: MacOS it returns some non-zero value that isn't -1 indicating failure
16:18 Geth ¦ MoarVM/fix-macos-eof: when lseek()ing TTY STDIN. This results in such handles marked
16:18 Geth ¦ MoarVM/fix-macos-eof: as seekable and in turn causes issues, such as mvm_eof() trying
16:18 Geth ¦ MoarVM/fix-macos-eof: to figure out whether we've reached EOF and falsely returning True
16:18 Geth ¦ MoarVM/fix-macos-eof: <…commit message has 17 more lines…>
16:18 Geth ¦ MoarVM/fix-macos-eof: review: https://github.com/MoarVM/MoarVM/commit/a82770334b
16:18 Zoffix (just fixed the weird spacing discrepancy in build/Makefile.in change)
16:20 Zoffix probably can be cleaner with the non-macos define just defining a macro replacement instead of defining a function
16:20 Zoffix
16:20 * Zoffix does that
16:23 Zoffix uhh, but then I don't know how to include the platform/posix/io.c thing
16:24 Zoffix screw it; gonna leave it as is. Maybe fix up later when I'm less of a C n00b
16:29 brrt joined #moarvm
16:30 domidumont joined #moarvm
16:31 Zoffix Is there a reason why #ifdef ... #define ... #endif are written all flush to the left instead of indented? Hard to see what's what
16:31 samcv Zoffix, you can indent, and I often do
16:32 Zoffix OK
16:32 samcv i mean it depends. if it's #define's usually i'll leave it on the left. if it's actual code, i'll indent it unless it's like DEBUG code ifdef
16:33 samcv Zoffix, where are you trying to include it Zoffix
16:33 nwc10 IIRC if the '#' character itself is in anything other than the leftmost column it's undefinfine behaviour
16:33 samcv nwc10, are you sure about that?
16:34 * Zoffix double-checks the book
16:34 nwc10 (because the C standards committee appears to have been very lazy and said "oh, well, whatever, it's undefined behaviour" when presented with naything they didn't care about)
16:34 nwc10 please do. I'm not *sure* about it
16:34 samcv c usually doesn't care about indentation
16:34 samcv but i think zoffix meant the things inside the ifdefs
16:34 nwc10 anywa,y IIRC the defensive approach is to have the # on the left always
16:34 nwc10 and indent with spaces
16:34 samcv i have #define's that are indented many places in the code
16:35 samcv mostly in places where it's used in a single function many places so i put it where it's used instead of in some far off place
16:35 timotimo is the c preprocessor standardised by the c committee¿
16:35 Zoffix The books says: "The # symbol need not be at the beginning of a line, as long as only white space precedes it."
16:36 nwc10 ah OK
16:36 nwc10 I forget whether we ever met a compiler that was fussy about this (standard or nt)
16:36 samcv i mean C compilers technically shouldn't care about whitespace rigth? i don't think it's needed most places
16:37 Zoffix This book http://knking.com/books/c2/  and so far it seems a pretty legit source of info (including on compiler variations) and was recommended by ##c channel
16:37 nwc10 agree about *should* :-)
16:37 nwc10 but occasionally some are buggy
16:37 nwc10 or just decide to adopt  annyoing parts of the standard and stick to them
16:38 samcv i wouldn't worry about it for now at least. since we have it many places in the code heh
16:38 Zoffix timotimo: it's part of the C standard yeah
16:38 timotimo ok
16:38 nwc10 but also, I find that indenting #ifdefs etc does make it easier to follow
16:38 nwc10 which I think was where all this started before I digressed it
16:39 samcv nwc10, you mean the code inside of it?
16:39 nwc10 sorry, wasn't clear and I think I'm talking at cross purposes
16:39 Zoffix FWIW I meant both the code and other preprocessor directives inside
16:39 nwc10 I was thinking about nested preprocessor directives
16:39 nwc10 and I think I'm about to be AFK
16:39 nwc10 which is probabl ygood for productivty
16:40 samcv Zoffix, you are trying to include things from that file? do you want help?
16:40 ilmari indenting the # is not portable
16:40 Zoffix ilmari: ah dammit
16:41 ilmari space between the # and the directive is fine, though
16:41 ilmari #  ifdef FOO
16:41 ilmari ^^ fine
16:41 samcv ilmari, do you have a citation for that?
16:42 ilmari https://perl5.git.perl.org/perl.git/commitdiff/f8a8fb6dab10a8ee2d0991f575c512f74b831a4d
16:42 Zoffix samcv: nah, no help. It works, just wanted to make it look pretty too :)
16:42 samcv any clue which compilers ilmari?
16:42 ilmari samcv: sorry, no. probably some ancient proprietary unix compiler
16:43 nwc10 "hateful ones"
16:43 samcv none of the ones we support have that at least. gcc, clang, msvc have issues. so i wouldn't worry too much
16:43 nwc10 (I shoudl be AFK. I sneaked back)
16:43 nwc10 but yes, it was something old and whacko
16:43 nwc10 possibly the netware compiler :-/
16:43 samcv haha
16:45 samcv i'm reading pre-ansi the compilers only supported ones not indented
16:45 Zoffix The standard says whitespace OK: http://www.iso-9899.info/n1570.html#6.10
16:46 ilmari as samcv says, the compilers moarvm actually supports are probably fine
16:46 Geth ¦ MoarVM/fix-macos-eof: fbd7dc8fa5 | (Zoffix Znet)++ | 4 files
16:46 Geth ¦ MoarVM/fix-macos-eof: Fix seekability detection on MacOS
16:46 Geth ¦ MoarVM/fix-macos-eof:
16:46 Geth ¦ MoarVM/fix-macos-eof: POSIX does not define which devices must support lseek() and on
16:46 Geth ¦ MoarVM/fix-macos-eof: MacOS it returns some non-zero value that isn't -1 indicating failure
16:46 Geth ¦ MoarVM/fix-macos-eof: when lseek()ing TTY STDIN. This results in such handles marked
16:47 Geth ¦ MoarVM/fix-macos-eof: as seekable and in turn causes issues, such as mvm_eof() trying
16:47 Geth ¦ MoarVM/fix-macos-eof: to figure out whether we've reached EOF and falsely returning True
16:47 Geth ¦ MoarVM/fix-macos-eof: <…commit message has 17 more lines…>
16:47 Geth ¦ MoarVM/fix-macos-eof: review: https://github.com/MoarVM/MoarVM/commit/fbd7dc8fa5
16:47 Zoffix (cleaned up a bit so not to define a separate function for Linux/Win32)
16:48 samcv nice
16:52 ilmari short?
16:52 ilmari shouldn't it be bool?
16:53 samcv we don't use bool anywhere in the code. i would just use int. i usually use that since cpu operations are faster i've read using the native cpu size
16:54 samcv some minor amount at least
16:54 samcv because with short usually it will have to use int then convert to store it as that size. depending
16:55 Zoffix ilmari: well, that's the datatype of seekable. I just used the same one
16:55 Zoffix I think int is better innit?
16:56 Zoffix 'cause it fits into register or something or other
16:56 samcv i would just use int for both
16:56 Zoffix k, gonna change that after release
16:56 samcv i usually use int for things that don't matter about size being consistent between archetectures like booleans
16:58 ilmari sizeof(bool) is 1 here
16:58 samcv well bool makes more code than int
16:58 samcv see https://stackoverflow.com/questions/5764956/which-is-faster-if-bool-or-ifint
16:58 samcv so there's no point unless you are having a large array
17:01 ilmari only without optimizing: https://stackoverflow.com/a/5765024
17:01 Zoffix That post just says there's no more code if you enable proper opt flags
17:03 samcv so it computes it as an int then?
17:03 samcv if you optimize?
17:04 Zoffix no idea; "so it compiles to essentially the same code, except for cmpl vs cmpb. This means that the difference, if there is any, doesn't matter. Judging by unoptimized code is not fair."
17:05 Zoffix (from one of the answers on that SO)
17:37 domidumont joined #moarvm
18:01 domidumont joined #moarvm
18:02 greppable6 joined #moarvm
18:15 Geth ¦ MoarVM/fix-macos-eof: 3f3045d6ec | (Zoffix Znet)++ | 4 files
18:15 Geth ¦ MoarVM/fix-macos-eof: Fix seekability detection on MacOS
18:15 Geth ¦ MoarVM/fix-macos-eof:
18:15 Geth ¦ MoarVM/fix-macos-eof: POSIX does not define which devices must support lseek() and on
18:15 Geth ¦ MoarVM/fix-macos-eof: MacOS it returns some non-zero value that isn't -1 indicating failure
18:15 Geth ¦ MoarVM/fix-macos-eof: when lseek()ing TTY STDIN. This results in such handles marked
18:15 Geth ¦ MoarVM/fix-macos-eof: as seekable and in turn causes issues, such as mvm_eof() trying
18:15 Geth ¦ MoarVM/fix-macos-eof: to figure out whether we've reached EOF and falsely returning True
18:15 Geth ¦ MoarVM/fix-macos-eof: <…commit message has 17 more lines…>
18:15 Geth ¦ MoarVM/fix-macos-eof: review: https://github.com/MoarVM/MoarVM/commit/3f3045d6ec
18:15 Zoffix (fixed missing return)
18:40 synopsebot joined #moarvm
18:52 synopsebot joined #moarvm
19:01 zakharyas joined #moarvm
20:09 samcv Zoffix, well. then there's no point putting it as short in the first place :P
20:09 samcv heh
20:10 samcv i'd put it as int, or put it as MVMintX ideally one of the two
20:10 samcv but it's not urgent or anything
20:27 Zoffix ##c told me `int` is better than `short` for single variables cause CPU registers work better with them or something and you ain't saving any space with just a few vars (as opposed to an array of shorts for example)
20:28 Zoffix ZofBot: array of shorts is better than array of pants tho, amirite?
20:28 ZofBot Zoffix, The guards, too, treated the common criminals with a certain forbearance, even when they had to handle them roughly
20:46 samcv hah ZofBot
20:47 samcv ZofBot, also for return values since calling functions basically is manipulating a bunch of registers
20:48 samcv though i prefer typing unless the only values are boolean or maybe some very small number
21:55 Geth ¦ MoarVM: 3f3045d6ec | (Zoffix Znet)++ | 4 files
21:55 Geth ¦ MoarVM: Fix seekability detection on MacOS
21:55 Geth ¦ MoarVM:
21:55 Geth ¦ MoarVM: POSIX does not define which devices must support lseek() and on
21:55 Geth ¦ MoarVM: MacOS it returns some non-zero value that isn't -1 indicating failure
21:55 Geth ¦ MoarVM: when lseek()ing TTY STDIN. This results in such handles marked
21:55 Geth ¦ MoarVM: as seekable and in turn causes issues, such as mvm_eof() trying
21:55 Geth ¦ MoarVM: to figure out whether we've reached EOF and falsely returning True
21:55 Geth ¦ MoarVM: <…commit message has 17 more lines…>
21:55 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3f3045d6ec
21:55 Geth ¦ MoarVM: 27f91344cc | (Zoffix Znet)++ (committed using GitHub Web editor) | 4 files
21:55 Geth ¦ MoarVM: Merge pull request #731 from MoarVM/fix-macos-eof
21:55 Geth ¦ MoarVM:
21:55 Geth ¦ MoarVM: Fix seekability detection on MacOS
21:55 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/27f91344cc
21:57 Zoffix .oO( no colours? )
22:05 MasterDuke joined #moarvm
22:05 samcv color in this room is disabled :(
22:21 MasterDuke interesting. this patch https://gist.github.com/MasterDuke17/1f46cd7f02cd191ba5657731246ca4c5 fails just two tests
22:21 MasterDuke the one Zoffix added for Int.new (no surprise)
22:21 MasterDuke and one in t/spec/S02-types/subset.t: subset Even of Int where { $_ % 2 == 0 }; use Test; throws-like q|Even.new|, Exception
22:22 MasterDuke it lives instead of throws
22:37 Geth ¦ MoarVM: 6e9e89eead | (Samantha McVey)++ | docs/ChangeLog
22:37 Geth ¦ MoarVM: Add some more ChangeLog entries
22:37 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6e9e89eead
22:37 samcv ok that should be everything
22:37 samcv in the changelog
23:56 MasterDuke joined #moarvm

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