TimToady would like to point out that nowhere in the design docs equates 'int' with C's 'long' type 00:08
00:09 vendethiel joined
TimToady according to S02:772 'int' might well be 'long long' on some machines 00:13
synopsebot Link: design.perl6.org/S02.html#line_772
01:58 vendethiel joined 02:47 vendethiel joined 02:49 ilbot3 joined 03:24 vendethiel joined 03:51 vendethiel joined 04:29 vendethiel joined 05:16 vendethiel joined 06:08 vendethiel joined 06:13 sivoais joined 06:42 FROGGS[mobile] joined
FROGGS[mobile] even more a reason that NativeCall should export types that are called long etc 06:43
06:48 vendethiel joined 07:15 rurban joined 07:30 vendethiel joined 07:41 brrt joined 07:47 FROGGS joined
brrt as far as i can tell, libuv's sendfile - which is what we use for the nqp::copy op, can accept arguments larger than 2g very well, it just doesn't send more than 2g in one go 07:49
FROGGS that's what I guessed also, that the 2G are just the first chunk 07:53
brrt so all that's needed is to write a loop around 2g chunks 07:54
FROGGS their documentation is worse than ours 07:56
brrt yeah 07:58
i'd say that was harsh, but, it's true
FROGGS heh, they want(ed?) to drop sendfile :o) - github.com/joyent/node/issues/3854 07:59
brrt what
... 08:00
we can perfectly well write MVM_sendfile
but it'd be missing the point of using libuv i guess
FROGGS aye
nwc10 is their only API to file metadata using stat buffers?
FROGGS I think so 08:01
nwc10 then :-( if you're windows
in that, if you're faking up stat propery on windows, you have to put effort into faking device and inode
which then immediately gets thrown away if all someone wanted to know is "is this a directory?" or "how long is the file?" 08:02
brrt that... 08:03
is very true
dunno if they're accepting of patches 08:04
nwc10 (1) I wouldn't know what would make a better subset of APIs 08:05
FROGGS why shouldn't they accept patches?
nwc10 (2) I'm not using Windows (and have never ever ever developed for it)
brrt they probably are
nwc10 - general lack of knowledge of windows api's is a weak spot of the OSS community 08:06
myself included
xiaomiao wouldn't call it a weak spot 08:12
brrt it is if you need your code to run everywhere 08:13
xiaomiao my code runs on all relevant platforms
I don't see how windows gets involved there
:)
brrt well, thats because you're choosing what you find relevant and what not 08:14
xiaomiao I played with the Win8 demo
it's kinda ... interesting ... demo
but it's so rough that I wouldn't want to do QA for it
brrt win8 or win10? 08:15
xiaomiao 8
plus the 8.1 'update'
so very beta ...
like, the shutdown button / dropdown menu is broken, and wrong
how does that even happen. 08:16
brrt i found 8.1 quite acceptable actually 08:18
you can ignore the whole metro thingy
also, it natively runs word/excel, which is a benefit
xiaomiao too slow
and too buggy
but, kinda ... nice showroom demo 08:19
"shutdown" hibernates ... that kind of buggy
and the incoherent mess of icons, text, icons+text ... any localized version is total mindbender and horrible to figure out
brrt i ran it in a virtualbox 08:30
the best way to run anything imho
anyway, that's really offtopic; moarvm supports windows whether you or i like it or not 08:31
:-)
and we're also likely to keep using libuv for the forseeable future
FROGGS ohh ye 08:32
s
08:39 vendethiel joined 08:45 Ven joined
brrt ok, it's a known issue 08:48
09:09 zakharyas joined
jnthn Well, given we're using sendfile to implement copy, if we need a Windows-specific solution there we just use CopyFile to do the whole thing :) 09:15
09:25 Ven joined
brrt this is true 09:29
frankly, that's actually a pretty good idea 09:30
we do lots of stuff windows-specific 09:32
nwc10 "we run on both kinds of OS, Linux *and* Windows"? 09:33
(well, maybe "POSIX and Windows")
brrt mac, linux, and windows
nwc10 then again, what does libuv run on?
brrt well... i guess those
perhaps also bsd
nwc10 Mac is a FreeBSD fork atop a mach microkernel (and then diverged) so it's pretty POSIX
brrt but pretty lame POSIX imho
almost-but-not-quite good implementations of many things, and good-but-different implementations of many others 09:34
nwc10 I've not actually hit enough of these to know where the pain is 09:35
jnthn nwc10: And...what's the marketshare of non-POSIX, non-Windows OS users that are likely to want to run Perl 6? :)
nwc10 but I'm still annoyed that they thought that dtruss was an adequate replacement for ktrace
jnthn: well, possibly someone will say that they want to run it on iOS and on Android 09:36
brrt which are...
:-P
nwc10 Android libc is an utter joke
brrt fair enough
but that's not my problem
as in
nwc10 (mind you, it didn't need to be anything other than that, because it's not the default runtime)
jnthn So, crapply implemented POSIX? :)
nwc10 worse
brrt libc is very much beyond the scope of moarvm
nwc10 I'm pretty sure it's not C89 conformant 09:37
(at least) the local functions exist as stubs which print to stderr that they aren't impleneted
what use is that?
jnthn wtf!
nwc10 if they didn't exist, probing code would detect this easily
yes, there's some other wtf
like the dynamic linker (certianly used to) only care about the shared object leafname 09:38
none of this matters if you're using it for what it was intended
anyway, "I want to run a programming language in my phone" is not IMO (and not H here) worth it if that's *All* that it is 09:39
"I want to write apps on my phone, and upload them to the app store" is what is needed
otherwise it's really a "nice to have", and that's not a priority 09:40
brrt it's geek cred 09:43
but ehm.. couldn't a moar-on-android just ship another libc
(python does run on android, fwiw) 09:44
nwc10 or target the JVM-a-like on it? 09:45
brrt that's a pretty good idea 09:46
10:08 rurban joined
FROGGS jnthn: I need to distinguish int from int64 in moar somehow :/ 10:15
so, we needs to extend MVMP6intREPRData 10:16
jnthn Uh
FROGGS :o) 10:17
jnthn We should probably look for a better solution to whatever problem you're trying to solve.
Such as, exporting clong, cint, etc. types from NativeCall... 10:18
FROGGS the problem I try to solve is basically to expose a C long type to Perl 6, that has either 32bits or 64bits
same for long long I guess 10:19
m: my native long is repr('P6int') is Int is nativesize(32) { }
camelia ( no output )
jnthn Sure, so what determines what the size will be? 10:20
FROGGS I'm not sure... we could run probes when we build/install nativecall and fallback to waht the vm suggests 10:22
jnthn Well, if you want to do the second we need to have a mechanism for doing that 10:25
I think at one point we pondered using negative values of nativesize as a cheat for conveying these things :) 10:26
That might have been arnsholt++'s idea...
FROGGS jnthn: we already check for certain things when building moar, it is just about putting more information into the generated config.c
hmmm
jnthn FROGGS: No, it's more conveying to the REPR that you want a "C long"
The REPR is written in C so it can just do sizeof(long) :P 10:27
FROGGS the question is just at what time it does a sizeof() :o)
jnthn That'd be at the time the VM is compiled.
Which only gets you in trouble if the library you're loading was compiled with a different idea of C type sizes than the VM itself. 10:28
FROGGS I guess that is something you can hardly solve 10:29
jnthn That'd strike me as a rather odd setup.
nwc10 I believe your C runtime would already have crashed by then
arnsholt Yeah
In that case you're gonna have a bad time no matter what
jnthn nwc10: I was gonna say, it sounds painful :)
arnsholt (And yes, negative bitwidths was my bad idea =) 10:30
jnthn OK, so that probably gives us a solution
arnsholt: It feels horrible, but it's hard to find specific negatives with this option... :P
arnsholt Well, your idea was better
Add another field to the compose protocol =)
jnthn Ah 10:31
That is perhaps cleaner :)
arnsholt Yup 10:32
Just need to check in the REPR that we don't get passed both at the same time
jnthn aye 10:34
And something in Perl 6 to get the info into the REPR
arnsholt The "you are C int" information you mean?
FROGGS is nativetype() ? 10:36
arnsholt Something like that was my plan, yeah 10:37
FROGGS is nativetype('int'), is nativetype('longlong')
or, is nativesize('int')
arnsholt An additional method in the HOW, and a trait. Just like we set bitwidths
FROGGS we can happily take a number or a string there I guess
arnsholt My plan is string in Perl 6, and number in the REPR 10:40
The HOW can do the mapping
jnthn Works for me
FROGGS awesome
jnthn Use nqp::const::C_TYPE_INT stuff for the integers.
FROGGS k
arnsholt Oh, yeah
I would've just hardcoded them, but consts are definitely a good idea 10:41
FROGGS consts are way better then magic numbers :o)
moritz magic constants!
FROGGS shh!
:P
10:58 Ven joined
lizmat good *, #moarvm 11:00
jnthn: looking at isreadable/iswritable/isexecutable
the odd one out is isexecutable, which does its own thing on Win32 using the extension
wouldn't it make sense to have them all use nqp::stat as well 11:01
and in the case of Win32, return "unknown" ?
jnthn wonders what Perl 5's "is it executable" does on Windows... 11:03
Is it -x?
lizmat yes
jnthn Hm 11:04
It comes back with 1 if I point it at an exe file
haha
echo omg > wtf.exe
lizmat ?
jnthn perl -e "print -x 'wtf.exe'"
1 11:05
11:05 vendethiel joined
jnthn :) 11:05
lizmat which is similar to what's being done in MoarVM atm
jnthn Yeah
That might be the best you can do on Windows.
But we could do that cheat behind nqp::stat also. 11:06
So we don't have to choose between it and keeping isexecutable
lizmat ok, fair enough
jnthn I'm inclined to retain the behavior
lizmat ok
jnthn It's technically dubious, but practically useful.
lizmat but shall I refactor to eradicate nqp::isreadable / nqp::iswritable / nqp::isexecutable ? 11:07
the alternative would be that I add nqp::lisreadable / liswritable / lisexectiable
*whatever
jnthn Yeah, I'd rather decrease the number of ops here than increase them, when there's an obvious generic interface to this stuff. 11:08
It's just duplicate functionality.
lizmat so what was the reason to do it this way in the first place ?
jnthn I've no idea :) 11:09
lizmat ok, otoh, rwx on a symlink pretty much seem unchangable
hmmm....
let me ponder on this some more :-) 11:11
FROGGS lizmat: on windows there is an environment variable that has a list of file extensions that are considered executable 11:47
that's how it works there
lizmat PATHEXT, yeah
11:58 xiaomiao joined 12:14 ggoebel111111114 joined 12:24 vendethiel joined 12:39 dalek joined 12:55 Ven joined 13:11 vendethiel joined
brrt blog.noctua-software.com/c-tricks.html <- some of these are quite nice 13:15
13:56 vendethiel joined, Ven joined 14:01 rurban joined 14:21 kjs_ joined 15:04 xiaomiao joined 15:10 xiaomiao joined 15:11 Ven joined
dalek arVM/longish: 7d111ae | FROGGS++ | src/6model/reprs/P6int.h:
add constants for C data types
 16:20
16:28 vendethiel joined 16:29 FROGGS[mobile] joined
dalek arVM/longish: 1c4087d | FROGGS++ | src/6model/reprs/P6int.h:
add C type long (that's why we do it after all)
 16:32
16:55 vendethiel joined 17:04 Ven joined 18:03 kjs_ joined 18:14 vendethiel joined 18:23 flussence joined 19:01 FROGGS joined
FROGGS MVMP6int: Unsupported int size (-4bit) 19:02
at src/gen/m-Metamodel.nqp:2889 (blib/Perl6/Metamodel.moarvm:compose:104)
so far, so good
timotimo that's really not much 19:04
FROGGS it is supposed to be not much 19:06
you know, ssd hard disk space is not that cheap 19:07
that approach seems to be too easy to actually work 19:15
though, too easy often also means 'much reliable'
dalek arVM/longer: 79b9b38 | FROGGS++ | src/6model/reprs/P6 (4 files):
support C type sized P6ints and P6nums

We can now ask the P6int repr to give us a an int, that is as wide as a long in C on the current platform. This should solve the issues with NativeCall on 32 bit machines. arnsholt++ and jnthn++ for the solution.		 19:25
nwc10 FROGGS: how do I test that? 19:27
FROGGS MoarVM+nqp+rakudo+zavolaj with 'longer' branch 19:28
though, I am preparing the zavolaj branch right now
nwc10 oh, OK, mmm, I might not get as far as zavolaj
FROGGS I'll also test it on x86 linux in a moment
timotimo btw, can we somehow get single precision floats to work? 19:43
FROGGS what's wrongs? 19:44
-s
TimToady that'd presumably just be num32 on the P6 side 19:51
FROGGS nwc10: CArray does not yet play nicely with long 19:52
TimToady: aye
timotimo: what is wrong with floats?
TimToady and obviously 'short double' on the C side :) 19:53
timotimo dunno, aren't our reals always double precision? 19:54
FROGGS timotimo: if you chose 'num', you get the biggest numeric type for your platform, whatever that is 19:55
timotimo and how do i get a half big numeric type?
FROGGS timotimo: half big as what? 19:56
timotimo as a double :) 19:57
FROGGS timotimo: use num32
a double is num64
timotimo oh
duh
i didn't think of that. though it's very obvious
FROGGS there is no num16 though :o)
timotimo but when we calculate stuff with num32, we'll always be converting to regular num internally? 19:58
FROGGS I would have guessed that you might better know than me :o) 20:00
timotimo right 20:01
TimToady unless you have a pragma like 'use native num32' or so, according to spec 20:02
but I think the current implementation doesn't actually follow the 'wide temps' policy
timotimo fair enough 20:03
20:07 kjs_ joined
FROGGS hups, I confused bits and bytes 20:11
... and with that NativeCall passes on x86_64 again 20:14
dalek arVM/longer: 78890ef | FROGGS++ | src/6model/reprs/P6 (2 files):
unconfuse bits and bytes
 20:15
FROGGS NativeCall passes on x86 \o/ 20:16
TimToady though on some machines you have long double, num80 or so
FROGGS TimToady: it is prepared for that... 20:19
my native longdouble is repr("P6num") is Num is nativesize('longdouble') { } 20:20
one can do that
'char' and 'short' and so on works too
when the branches are merged I'd even like to go that far as to disallow 'int' in NativeCall 20:21
same for 'num'
TimToady seems sane 20:24
FROGGS nwc10: the 'longer' branches in the for repositories are ready now 20:26
retupmoca FROGGS: if 'int' is disallowed, will there be a new type I can use to represent a C 'int64_t' ?
timotimo int64 exists already 20:27
FROGGS retupmoca: there is 'int64'
retupmoca oh, ok
didn't know that
FROGGS only 'int' means: the biggest integer type there is on your system... which does not really map to what C thinks (or thought)
(and num)
so, C's int is int32, C's long is long, ... 20:28
retupmoca makes sense
FROGGS retupmoca: the NativeCall readme has a nice table for that
I'd like to export like like char and short, though, then you cannot have subs with these names in your namespace anymore 20:29
jnthn / arnsholt: please review the 'longer' branches in moar+nqp+rakudo+nativecall... it passes all tests on 32 and 64bit on linux 20:32
TimToady well, int is biggest integer "that runs at full speed" 20:34
so even if your C can emulate int128, that runs slower than int64 on a 64-bit machine
c-char and c-short would work as a systematic prefix, I suppose 20:36
could even have c-long-long
FROGGS ahh yes, makes sense (int speed)
TimToady with hyphens for spaces
we could kinda reserve the c- space for C types 20:37
or we could even go with c:long-long
std: c:long-long
camelia std f9b7f55: OUTPUTĀ«===SORRY!===ā¤Undeclared routine:ā¤ 'c:long-long' used at line 1ā¤Check failedā¤FAILED 00:00 134mā¤Ā»
FROGGS hmmm, if you port a bigger C lib this might be not that fun to type all the time
TimToady std: C:long-long 20:38
camelia std f9b7f55: OUTPUTĀ«===SORRY!===ā¤Undeclared name:ā¤ 'C:long-long' used at line 1ā¤Check failedā¤FAILED 00:00 134mā¤Ā»
TimToady if you don't mind the uppercase
FROGGS looks nice though
I'd prefer the uppercase, yes
I like to spell language names correctly :o)
TimToady m: constant C:int = int64; say C:int 20:39
camelia rakudo-moar fec233: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/d3OziuSFEBā¤Variable '&C' is not declaredā¤at /tmp/d3OziuSFEB:1ā¤------> constant C:int = int64; say āC:intā¤Ā»
TimToady rakudo needs to be taught better about extended names
FROGGS std: constant C:int = int64; say C:int
camelia std f9b7f55: OUTPUTĀ«===SORRY!===ā¤Undeclared name:ā¤ 'C:int' used at line 1ā¤Check failedā¤FAILED 00:00 135mā¤Ā»
FROGGS you first :P
TimToady apparently so does STD :)
but differently
eep, someone removed the color 20:40
yuck
FROGGS :/
TimToady I guess it's a channel setting 20:42
flussence that'd be mode +c, iirc... 20:43
FROGGS yeah, I see colors in privmsg
nwc10 FROGGS: well, all "ok ..." on x86_64 with an ASAN build of MoarVM, but ASAN isn't valgrind, so wont' spot issues with "other" people's code 20:59
but, "it did work" with something far more paranoid than usual
I need to go to bed 21:00
FROGGS me too :o)
thanks for testing, and gnight :o)
nwc10 the small "auf" likes to wake up early
not *that* early, but still early enough that I didn't want to be
er, don't. 21:01
whatever. zzzz
FROGGS we'll get up at 6:30 to get to the zoo early :o/
nwc10: sleep well
21:04 kjs_ joined 22:01 rurban joined
jnthn FROGGS: I think I'd have preferred a different trait at Rakudo level. 22:02
FROGGS: Introspecting type name feels...smelly.
"is cnativetype('long')" or so 22:04
22:04 FROGGS_ joined
jnthn FROGGS_: Otherwise, I'm happy enogh with it. 22:10
enough, even.
japhb BTW, to whoever mentioned 16-bit floating point: It's a thing. It's called 'half' on the compilers that support it, IIRC. 22:14
TimToady short float!
japhb It's used for HDR rendering and other graphics tasks.
TimToady don't some GPUs speak it natively
?
japhb TimToady: Yes, exactly. 22:15
So if you want to send or receive a pile of data from those cards without a crazy amount of conversion ....
jnthn "Unrecognized revision specifier 'food-31-g2d7eddb'"...dammit, I really shouldn't use my real dev checkouts of repos for demos in class... 22:21
Merging native-ref in Moar. It should break nothing for mainline NQP/Rakudo. 22:25
And there's no reason for it to be a branch any more :)
Moar needs to learn to optimize them better, but I'm happy the API will live on.
timotimo i haven't yet gotten to know what exactly about them is optimizable 22:28
not having to take a reference when a simple native value "copy" would suffice, perhaps?
dalek Heuristic branch merge: pushed 35 commits to MoarVM by jnthn
jnthn timotimo: Yeah
timotimo: Well, the interesting case to make work is that
class Foo { has int $.x is rw } 22:29
$a-foo.x = 42;
When it inlines the accessor method, we'd like it to eliminate taking a ref at all
And basically just emit a bindattr
Which in turn lowers to a pointer thingummy
timotimo right, so we would want to remember where a reference was taken from and when we know the reference isn't used afterwards any more, we'll just bindattr instead of going through the reference 22:30
jnthn yeah
timotimo i'd like to have something mildly similar for boxing/unboxing 22:31
jnthn I'd been pondering handling them in the same kinda way
timotimo where we remember, that some value is just a box for a register that's (hopefully) still alive
jnthn Both really want doing post-inline.
TimToady does our current JIT have any sort of peephole optimization? 22:32
timotimo yes, very much so
jnthn Lots of ops get turned into simpler one, though a lot of it is possible because of non-local analyses. 22:33
TimToady if it's non-local, it's not a peephole optimizer
jnthn so I'm not sure you'd class all of 'em as true peephole.
TimToady but I really mean after it gets turned into linear assembly/machine code 22:34
jnthn Ah
Then no, not much there...
TimToady seems there are some infelicities at that level
jnthn Though real reg alloc would help us out a lot.
And probably those two want tackling around the same time.
It all needs care as you need to keep the callframe in decent enough shape for deopt. 22:35
TimToady not suggesting any schedule change, just trying to keep a feel for where we are
jnthn Well, if we're really lucky we might get brrt++ for another summer to focus on producing better code :)
timotimo say, jnthn, are we already running over code again after an inline has happened? 22:37
TimToady hopes the big announcement makes it more likely that TPF gets admitted as an org
jnthn timotimo: Not to do the same things we did as we go inlining
timotimo: But yes, we do things like dead code elimination after inlining, for example. 22:38
timotimo: We need to be careful not to do too many passes...or we make it harder for the optimizations to actually pay off.
TimToady: Hopefully, yes 22:39
timotimo understood 22:41
well, once the spesh graph is already completely in the cache, we could as well go over it a second time :P 22:42
jnthn Just 'cus it's in cache doesn't mean it's free :P The way spesh allocates does mean all the stuff ends up bunched together in memory for cache happiness, though :) 22:43
timotimo yup, i thought of that
jnthn Grrr...airline didn't feed me quite enough so now I have midnight munchies :)
Maybe I should go take a beer snack. :) 22:44
Which can only be eaten with a beer. Hard life.
The post-merge Moar seems to build NQP and Rakudo fine :) 22:45
So, should be all good.
jnthn wanders off for the evening 22:47
timotimo sweet
jnthn Will be distracted most of tomorrow, but may get some patch or two in during the evening :)
o/
timotimo neato
23:14 vendethiel 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!