github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
cog MasterDuke++ 16:25
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!