06:19 domidumont joined 06:22 domidumont joined
JimmyZ hmm, seems that call mkdir and then call readdir will get a error 06:30
rm -rf test && ./perl6-m -e 'use nqp; nqp::mkdir("test", 0o777) unless "test".IO.e; my $io := nqp::opendir("test"); say nqp::nextfiledir($io);'
Failed to read dirhandle: 2
this only happens when make an un-existed dir and then read it 06:32
dalek arVM: a94e744 | (Jimmy Zhuo)++ | src/io/dirops.c:
fixed readdir, so it won't check old errno
 06:45
arVM/even-moar-jit: a70f9fb | brrt++ | src/jit/linear_scan.c:
Implement register assignment

This almost enables the use of the linear scan algorithm.		 06:52
07:10 brrt joined
brrt \o 07:16
JimmyZ o/ 07:17
brrt reproting on progress: going well, but I've still got problems with (referencing) pseudotiles
because everything is accessed by index
07:23 domidumont joined 07:36 domidumont joined 07:40 domidumont joined
brrt i'll get into more detail on that later, have to run now 07:53
08:14 domidumont joined 08:22 zakharyas joined 09:34 domidumont joined 09:41 domidumont joined 10:04 domidumont joined 11:04 domidumont joined
dalek arVM: 20c8591 | FROGGS++ | src/platform/posix/time.c:
work around clock_gettime issue on OSX (#438)

This resolves issue #437. Tested on pre- and post OSX 10.12 / Xcode 8.		 12:02
13:26 domidumont joined 13:35 domidumont joined 14:04 domidumont joined 14:14 domidumont joined
stmuk FROGGS++ 14:15
apple-- 14:16
14:41 _longines joined 16:37 FROGGS joined
FROGGS o/ 16:37
17:04 japhb joined 17:56 lizmat joined
FROGGS btw, I've got now access to an AIX@powerpc machine now 17:58
though, libatomic-ops and dyncall dont support it
and libffi isnt installed
timotimo oof 18:01
FROGGS what do we actually need libatomic-ops for? 18:05
timotimo MVM_ADD, MVM_CAS 18:06
FROGGS which means?
timotimo well, CAS is Compare-And-Swap
jnthn Atomic operations and memory barriers, in short. 18:07
Providing access to CPU primitives that we use to implement various concurrent data structures.
FROGGS hmmm, thanks :o) 18:16
18:18 pyrimidine joined
lizmat jnthn: any thoughts on the parse-base addition as a sub ? 18:25
18:41 pyrimidine joined 18:45 zakharyas joined 18:48 pyrimidine joined, domidumont joined
timotimo first read that as "parse-based addition" and was quite confused 18:52
FROGGS was able to build libffi on aix... with some hacks :S 18:56
lizmat timotimo: well, I thought we weren't supposed to just add built-in subs in 6.c ? 18:58
or exposed classes?
we were going to use a "6.d" setting for this, weren't we ? 18:59
18:59 vendethiel joined
lizmat I mean, personally I would be fine with adding stuff and call it 6.d at some point in the (near) future 18:59
timotimo right, i suppose it'd have to be unavailable if you "use v6.c" 19:00
19:00 pyrimidine joined
[Coke] wrong channel? 19:00
lizmat [Coke]: perhaps
FROGGS not bad, not bad: 19:09
compiling src/core/loadbytecode.o
compiling src/math/num.o
src/math/num.c:9:1: error: initializer element is not constant
19:09 pyrimidine joined
jnthn lizmat: Will try and catch up with perl6-dev once I'm done cooking/eating dinner :) 19:10
But yeah, we could do with the 6.d setting added 19:11
nine++ did have a branch that did it, iirc
And while it's arguable we just don't have the userbase size to worry a lot about it at the moment, we should get into the habbit and figure out the quirks/issues before that point. 19:12
19:15 pyrimidine joined
timotimo jnthn: would you spend a minute looking at the multidimarray_view branch - it'd probably be enough to look at flat_index and the struct - and tell me if it's a sane direction to go in? 19:17
FROGGS uhhh, moarvm compiles further... 19:31
nine The branch is called language_versions 19:32
FROGGS compiling 3rdparty/libuv/src/unix/linux-core.o 19:43
3rdparty/libuv/src/unix/linux-core.c:33:23: fatal error: sys/prctl.h: No such file or directory
compilation terminated.
FROGGS cries
19:43 domidumont joined
FROGGS uncries 19:55
TimToady m: say v6.d after v6.d.a 20:23
camelia rakudo-moar c196af: OUTPUTĀ«Trueā¤Ā»
lizmat TimToady: so that's wrong, right ? 20:27
TimToady no, that's correct 20:28
alphas come before .0, .1, .2...
lizmat because 6.d would give you the latest 6.d ? 20:29
TimToady 6.d is supposed to be short for 6.d.0+ I thought 20:30
if we changed that, it has fled my brane 20:31
which happens frequently enough :) 20:32
20:34 ggoebel joined
TimToady I guess smartmatching is a little more forgiving 20:43
jnthn Certainly as I recollect it, the idea was we'd have 6.d.ALPHA or 6.d.a or such to be our "get a preview of what 6.d will be" 21:12
So when we introduce the 6.d setting, for now you'll use 6.d.a to get at it. 21:13
jnthn makes an attempt to backlog #perl6-dev :)
21:16 pyrimidine joined 21:25 pyrimidine joined 21:37 pyrimidine joined 21:43 pyrimidine joined
japhb timotimo: re: API for ndarray-view: Perl 5 had a particularly powerful one called PDL (pdl.perl.org). It does pretty cool things like allowing you to do a multidimensional slice, swap coordinates, etc. extremely cheaply. 21:51
timotimo japhb: yeah, i'm hoping what i'm implementing can let you do that, too 21:54
though how am i supposed to know if it's cheap until i implement it fully and we look at jitting all the ndarray stuff0
if i'm not mistaken, my implementation will allow to go from any amount of dimensions to any other (as long as the number of values doesn't exceed the target array) 21:55
jnthn timotimo: will take a look later this week...really tired today :(
timotimo it'll allow any dimension to be mapped to any target dimension, and to map it forwards, backwards, or with full-integer steps in either dierction
and also it'll allow you to access an array of 64bit ints as many more 8bit ints, for example 21:56
your move, PDL
23:46 yfkj joined
yfkj timotimo: are you implementing it column-major order ? 23:47
it's the order of Fortran, R, OpenGL and MATLAB
timotimo ndarrays have already been implemented with C order, i believe 23:49
but using views you can store your array in column-major order and have a C-style view onto the data
yfkj mainly thinking that having OpenGL, ATLAS, LAPACK binding would be cool ;) 23:51

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!