Zoffix Is there a macro for MacOS-only code, same as we got `#if defined _WIN32` ? 00:23
samcv Zoffix, yeah. uhm platform/memmem.c prolly has it 00:54
or i think it's memmem.h
defined(__APPLE__) || defined(__Darwin__) is what you want Zoffix 00:55
Zoffix Thanks 00:56
Is MVM_platform_is_fd_seekable a crap name? Like is this just internal or what? 01:16
This is in same place as MVM_platform_lseek 01:17
01:56 ilbot3 joined
samcv Zoffix, doesn't sound too bad 02:02
Geth MoarVM/fix-macos-eof: 24007720d5 | (Zoffix Znet)++ | 5 files
Fix seekability detection on MacOS

POSIX does not define which devices must support lseek() and on MacOS it returns some non-zero value that isn't -1 indicating failure when lseek()ing TTY STDIN. This results in such handles marked as seekable and in turn causes issues, such as mvm_eof() trying to figure out whether we've reached EOF and falsely returning True ... (17 more lines)		 02:37
MoarVM: zoffixznet++ created pull request #731:
Fix seekability detection on MacOS		 02:43
Zoffix whoops, missing semicolon on win32 03:02
And my other attempt to spectest it on macos looks to have hung. Something tells me this PR is nasty for perf/resources
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)
Geth MoarVM/fix-macos-eof: 97fc8bf61d | (Zoffix Znet)++ | 5 files
Fix seekability detection on MacOS

POSIX does not define which devices must support lseek() and on MacOS it returns some non-zero value that isn't -1 indicating failure when lseek()ing TTY STDIN. This results in such handles marked as seekable and in turn causes issues, such as mvm_eof() trying to figure out whether we've reached EOF and falsely returning True ... (17 more lines)		 03:03
Zoffix (just fixed the win32 typo)
03:11 evalable6 joined 06:04 evalable6 joined 06:19 rba joined 06:23 rba joined 06:44 domidumont joined 07:02 rba_ joined 07:03 brrt joined 07:09 domidumont joined
brrt good * #moarvm 07:13
timotimo hey brrt
brrt i've been doing some of that old thinking
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?
brrt can't help it 07:15
and cross-template is virtually impossible by construction; it'd be possible the optimizer could protect against it 07:16
*could cuase it and have to protect against it
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:26
cool, that seems to work at first glance 07:35
i wonder if that'd be allowed in the release? 07:40
probably better for after. 07:41
right now it goes via div_I and skips the int cache entirely, which is not terribly problematic 07:44
after this, though, the int cache can be used for div_I as well
ah crap 07:46
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:47
not an unreasonable request by any stretch 07:48
lizmat Q: can I nqp::clone an nqp::list threadsafely ? 07:49
as in: can it never cause a segfault or other internal corruption?
timotimo i expect it can crash 07:50
imagine you're cloning a gigantic list on one thread and at the same time another thread resizes it
the resizing thread would free the data blob and poof
lizmat ok, but reading from it should be ok, right? 07:51
timotimo reading from what?
you mean reading a list while another thread clones it?
lizmat if one thread is reading from an nqp::list, and another thread is resizing it ?
timotimo can still cause problems
lizmat actually, more specifically, doing an nqp::elems on it 07:52
timotimo oh, nqp::elems is less problematic
let me have a closer look
lizmat cause I think that's the underlying issue with rakudo issue 1220
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 :-)
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 ?
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)
lizmat hmmm... 07:55
samcv tested the Alpine build. works fine 08:07
though some nativecall things seem to fail. but it builds. going to see what the NativeCall things are 08:08
rakudo t/04-nativecall/08-callbacks.t and 21-callback-other-thread.t fail 08:10
08:19 evalable6 joined 08:38 rba joined 08:44 bartolin joined 08:54 rba joined 09:09 rba joined 09:20 zakharyas joined
AlexDaniel` would be great to have some eyes on github.com/MoarVM/MoarVM/pull/731 before the release 09:21
09:22 rba_ joined
timotimo maybe someone can implement what geekosaur suggested 09:23
i wonder how often the "is_seekable" is called in a regular program 09:27
09:38 rba joined
lizmat I think I now fixed all of the HLL race conditions of Rakudo issue 1202 11:52
MoarVM panic: Heap corruption detected: pointer 0x10b508430 to past fromspace 12:09
after 8.5 minutes on an unloaded system
MoarVM panic: Heap corruption detected: pointer 0x1119a2580 to past fromspace (after 42 seconds) 12:11
12:17 synopsebot joined
lizmat .tell jnthn I think I've reduced 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 13:30 ggoebel joined 14:08 brrt joined 14:09 zakharyas joined 14:22 buggable joined
Zoffix New blog post: "Rakudo Perl 6 Advent Calendar 2017 Call for Authors": rakudo.party/post/Rakudo-Perl-6-Ad...or-Authors 14:42
15:07 zakharyas joined 15:19 brrt joined 16:09 zakharyas joined
samcv Zoffix++ 16:12
16:12 domidumont joined
Geth MoarVM/fix-macos-eof: a13b23a36c | (Zoffix Znet)++ | 5 files
Fix seekability detection on MacOS

POSIX does not define which devices must support lseek() and on MacOS it returns some non-zero value that isn't -1 indicating failure when lseek()ing TTY STDIN. This results in such handles marked as seekable and in turn causes issues, such as mvm_eof() trying to figure out whether we've reached EOF and falsely returning True ... (17 more lines)		 16:12
16:17 brrt joined
Geth MoarVM/fix-macos-eof: a82770334b | (Zoffix Znet)++ | 5 files
Fix seekability detection on MacOS

POSIX does not define which devices must support lseek() and on MacOS it returns some non-zero value that isn't -1 indicating failure when lseek()ing TTY STDIN. This results in such handles marked as seekable and in turn causes issues, such as mvm_eof() trying to figure out whether we've reached EOF and falsely returning True ... (17 more lines)		 16:18
Zoffix (just fixed the weird spacing discrepancy in build/Makefile.in change)
probably can be cleaner with the non-macos define just defining a macro replacement instead of defining a function 16:20
…
Zoffix does that
uhh, but then I don't know how to include the platform/posix/io.c thing 16:23
screw it; gonna leave it as is. Maybe fix up later when I'm less of a C n00b 16:24
16:29 brrt joined 16:30 domidumont joined
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
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
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
samcv nwc10, are you sure about that?
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)
please do. I'm not *sure* about it
samcv c usually doesn't care about indentation
but i think zoffix meant the things inside the ifdefs
nwc10 anywa,y IIRC the defensive approach is to have the # on the left always
and indent with spaces
samcv i have #define's that are indented many places in the code
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¿
Zoffix The books says: "The # symbol need not be at the beginning of a line, as long as only white space precedes it."
nwc10 ah OK 16:36
I forget whether we ever met a compiler that was fussy about this (standard or nt)
samcv i mean C compilers technically shouldn't care about whitespace rigth? i don't think it's needed most places
Zoffix This book 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* :-)
but occasionally some are buggy
or just decide to adopt annyoing parts of the standard and stick to them
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
timotimo ok
nwc10 but also, I find that indenting #ifdefs etc does make it easier to follow
which I think was where all this started before I digressed it
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
Zoffix FWIW I meant both the code and other preprocessor directives inside
nwc10 I was thinking about nested preprocessor directives
and I think I'm about to be AFK
which is probabl ygood for productivty
samcv Zoffix, you are trying to include things from that file? do you want help? 16:40
ilmari indenting the # is not portable
Zoffix ilmari: ah dammit
ilmari space between the # and the directive is fine, though 16:41
# ifdef FOO
^^ fine
samcv ilmari, do you have a citation for that?
ilmari perl5.git.perl.org/perl.git/commit...f74b831a4d 16:42
Zoffix samcv: nah, no help. It works, just wanted to make it look pretty too :)
samcv any clue which compilers ilmari?
ilmari samcv: sorry, no. probably some ancient proprietary unix compiler
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
nwc10 (I shoudl be AFK. I sneaked back)
but yes, it was something old and whacko
possibly the netware compiler :-/
samcv haha
i'm reading pre-ansi the compilers only supported ones not indented 16:45
Zoffix The standard says whitespace OK: www.iso-9899.info/n1570.html#6.10
ilmari as samcv says, the compilers moarvm actually supports are probably fine 16:46
Geth MoarVM/fix-macos-eof: fbd7dc8fa5 | (Zoffix Znet)++ | 4 files
Fix seekability detection on MacOS

POSIX does not define which devices must support lseek() and on MacOS it returns some non-zero value that isn't -1 indicating failure when lseek()ing TTY STDIN. This results in such handles marked as seekable and in turn causes issues, such as mvm_eof() trying to figure out whether we've reached EOF and falsely returning True ... (17 more lines)
Zoffix (cleaned up a bit so not to define a separate function for Linux/Win32)
samcv nice 16:48
ilmari short? 16:52
shouldn't it be bool?
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:53
some minor amount at least 16:54
because with short usually it will have to use int then convert to store it as that size. depending
Zoffix ilmari: well, that's the datatype of seekable. I just used the same one 16:55
I think int is better innit?
'cause it fits into register or something or other 16:56
samcv i would just use int for both
Zoffix k, gonna change that after release
samcv i usually use int for things that don't matter about size being consistent between archetectures like booleans
ilmari sizeof(bool) is 1 here 16:58
samcv well bool makes more code than int
see stackoverflow.com/questions/576495...l-or-ifint
so there's no point unless you are having a large array
ilmari only without optimizing: stackoverflow.com/a/5765024 17:01
Zoffix That post just says there's no more code if you enable proper opt flags
samcv so it computes it as an int then? 17:03
if you optimize?
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:04
(from one of the answers on that SO) 17:05
17:37 domidumont joined 18:01 domidumont joined 18:02 greppable6 joined
Geth MoarVM/fix-macos-eof: 3f3045d6ec | (Zoffix Znet)++ | 4 files
Fix seekability detection on MacOS

POSIX does not define which devices must support lseek() and on MacOS it returns some non-zero value that isn't -1 indicating failure when lseek()ing TTY STDIN. This results in such handles marked as seekable and in turn causes issues, such as mvm_eof() trying to figure out whether we've reached EOF and falsely returning True ... (17 more lines)		 18:15
Zoffix (fixed missing return)
18:40 synopsebot joined 18:52 synopsebot joined 19:01 zakharyas joined
samcv Zoffix, well. then there's no point putting it as short in the first place :P 20:09
heh
i'd put it as int, or put it as MVMintX ideally one of the two 20:10
but it's not urgent or anything
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:27
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
samcv hah ZofBot 20:46
ZofBot, also for return values since calling functions basically is manipulating a bunch of registers 20:47
though i prefer typing unless the only values are boolean or maybe some very small number 20:48
Geth MoarVM: 3f3045d6ec | (Zoffix Znet)++ | 4 files
Fix seekability detection on MacOS

POSIX does not define which devices must support lseek() and on MacOS it returns some non-zero value that isn't -1 indicating failure when lseek()ing TTY STDIN. This results in such handles marked as seekable and in turn causes issues, such as mvm_eof() trying to figure out whether we've reached EOF and falsely returning True ... (17 more lines)		 21:55
MoarVM: 27f91344cc | (Zoffix Znet)++ (committed using GitHub Web editor) | 4 files
Merge pull request #731 from MoarVM/fix-macos-eof

Fix seekability detection on MacOS
Zoffix
.oO( no colours? )
 21:57
22:05 MasterDuke joined
samcv color in this room is disabled :( 22:05
MasterDuke interesting. this patch gist.github.com/MasterDuke17/1f46c...31246ca4c5 fails just two tests 22:21
the one Zoffix added for Int.new (no surprise)
and one in t/spec/S02-types/subset.t: subset Even of Int where { $_ % 2 == 0 }; use Test; throws-like q|Even.new|, Exception
it lives instead of throws 22:22
Geth MoarVM: 6e9e89eead | (Samantha McVey)++ | docs/ChangeLog
Add some more ChangeLog entries
 22:37
samcv ok that should be everything
in the changelog
23:56 MasterDuke 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!