|
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
|
|||