github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:01 reportable6 left 00:03 reportable6 joined 01:31 frost-lab joined 02:52 linkable6 left, evalable6 left 02:53 evalable6 joined 02:54 linkable6 joined 03:54 greppable6 left, nativecallable6 left, committable6 left, notable6 left, reportable6 left, sourceable6 left, bisectable6 left, squashable6 left, coverable6 left, evalable6 left, quotable6 left, releasable6 left, benchable6 left, statisfiable6 left, bloatable6 left, unicodable6 left, shareable6 left, tellable6 left 03:55 benchable6 joined, tellable6 joined, releasable6 joined, sourceable6 joined, greppable6 joined 03:56 bloatable6 joined, committable6 joined, quotable6 joined, notable6 joined, coverable6 joined, evalable6 joined, squashable6 joined, statisfiable6 joined 03:57 bisectable6 joined, reportable6 joined, nativecallable6 joined, shareable6 joined, unicodable6 joined 06:01 reportable6 left 06:02 reportable6 joined
nwc10 good *, #moarvm 06:22
(for some value of good) 06:23
nine A good value I hope
nwc10 Not quite. On the M1 Mac I can get everything to build with the Apple toolchain 06:25
(unmodified)
so hey, where is gcc?
Let's just paste this. This is fun: 06:26
nick@minimac MoarVM % /usr/bin/gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: arm64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
not quite icc level cheating.
Ooh. cheating.
anyway, it *does* have gcc10, if I find it and put it into my path. But then I need GNU ar, apparently, so I fix that
and now i have messy link failures
eg 06:27
ld: warning: ignoring file 3rdparty/tinymt/libtinymt.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
can you spot the difference between macOS-arm64 and macOS-arm64 ?
it's like a Sun C++ compiler error message I had decades ago. (They'd failed to put "const" into one of the two things that it said were different)
I don't think that a missing "const" is the problem here. 06:28
japhb nwc10: Or at least, that's Apple's *general* problem ....
Though to be fair, they're hardly alone in the tech industry. :-P
06:29 domidumont joined
nwc10 there's also a newline that gets into the wrong place in the 5 error messages about libraries, making me wonder if some part of this thing is multi-threaded 06:29
(which if so is cool, but they haven't got there error message I/O properly thread safe. OK, first world problem) 06:30
MasterDuke nwc10: is this an exercise in getting moarvm built with gcc on an M1? because there are some existing issues/PRs about building there. i think someone said they did get it built and running some simple raku scripts, but rakudo tests were failing 06:48
i assume they were using clang, but don't remember details 06:52
oh, missed your first messages, nm 06:54
nwc10 there's a PR about libatomicops 07:05
and I'm figuring that on the failing machine, `uname -a` must be reporting `arm64`
whereas on the machine I have access to it reports `arm`
cog nwc10: my experience with M1. I can't use CRO on intel emulation because of problems with ssl. I did not investigate. I have hacked scripts to do a fat built. I have not worked on it recently. github.com/cognominal/rakudo/commi...761d481e68 07:15
Apparently it is possible, to have docker containers in M1. I should create one with raku and the library I use. That would be a step toward a fat support of Rakudo star on M1. What is the target date for Rakudo star ? 07:22
* libraries
nwc10 I have no idea about Rakudo star 07:28
cog Currently it does not make much sense to put a fat rakudo in a M1 docker container because of problem with QEMU docs.docker.com/docker-for-mac/apple-silicon/ 07:45
08:03 Altai-man_ left 09:10 dogbert11 left, dogbert11 joined 09:28 sena_kun joined 10:03 zakharyas joined 10:09 zakharyas left 10:28 frost-lab left 11:15 linkable6 left 11:16 linkable6 joined 11:33 Kaiepi left 11:39 LizBot left 11:43 domidumont left 12:01 reportable6 left 12:03 reportable6 joined 13:10 lucasb joined
MasterDuke if nobody has any objections or suggestions for github.com/MoarVM/MoarVM/pull/1483 i'll probably merge it today or tomorrow and then see about applying some of the same simplifications to the nqp and rakudo files 14:15
complete change of topic, is there any chance moarvm would bump up to C11 instead of C99? 14:20
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/05/03/2021-...ble-comma/ 14:22
nine MasterDuke: I'm pretty sure that depends solely on our target platforms. Or lets face it, MSVC. My personal grudge was with C89 and C99 fixed that so that's what I went for. 15:12
MasterDuke according to wikipedia, "Microsoft Visual C++ starting with VS 2019 (16.8)[9] in September 2020." 15:14
i have no strong feelings, but the first line of the readme for libatomic_ops is "IN NEW CODE, PLEASE USE C11 OR C++14 STANDARD ATOMICS INSTEAD OF THIS PACKAGE." and that got me wondering
cog: if you didn't see in the weekly lizmat just posted, tyil just released a star for 2021.04 15:16
re C11, i know nothing about other platforms 15:17
15:35 zakharyas joined
cog MasterDuke++ 16:25
17:53 zakharyas left 18:01 reportable6 left 18:03 reportable6 joined 18:09 zakharyas joined 18:14 zakharyas left 18:18 dogbert11 left 18:24 patrickb joined 18:26 linkable6 left 18:27 dogbert17 joined, linkable6 joined 19:29 zakharyas joined 19:56 zakharyas left 19:57 zakharyas joined
jnthn omg, so I guess those who did enough Raku regex writing know that `/:my $x = "foo"; $x/` style things work - that is, you can declare a variable. 20:08
I too knew this. It's only today, looking at doing the RakuAST node for it, that I discovered this syntactic form is a bit more liberal than I'd first appreciated. 20:09
m: say "foo" ~~ /:my sub foo($x) { $x eq "o" }; \w <?{ foo($/) }>/
camelia 「o」
jnthn Declare a sub in a regex!
You could declare a class too :)
lizmat it always was my understanding that the /: syntax was basically a thunk ? 20:10
jnthn However, it gets "better", because it doesn't actually do anything to assert that there's a word boundary after one of the scope declarators, before entering the main language. 20:12
Which, well
m: say "foo" ~~ /:my-goodness-lol;/; sub my-goodness-lol { say "hahaha" }
camelia hahaha
「」
jnthn lizmat: Not quite sure I'd use thunk for this; the code of the main language is compiled directly into the regex, so there's no thunk there. 20:13
There doesn't need to be because regexes and "normal" code (mine is more "abnormal" code :)) compile into the same bytecode anyway :) 20:14
lizmat well, I meant to emphasize that it doesn't have its own scope, different from when using { }
jnthn Anyway, I may just sneak a word boundary assertion into the grammar of the RakuAST-based compiler 'cus I'm pretty sure this is an accident :)
But it amused me. 20:15
(To be clear, I think the second bit is an accident. I think declaring a sub or whatever there can live on. It doesn't do any harm.)
walk, bbl
20:32 patrickb left 20:58 zakharyas left 21:40 [Coke] left