00:18 finanalyst left
timo ugexe: it looks like the change you suggested, to make the dependency entries in the meta6.json match exactly, made the problem go away! \o/ 00:59
oh, hold on, i confused which package the conflict was with 01:01
i would like to retract my retraction. i just had to change not just the dependency entry in the meta6 but of course also the use statement in the code 01:13
ugexe I was afraid that would work 02:55
Because im
not sure how easy it will be to fix in rakudo
timo :| 02:56
we can just make the version matcher used become part of what decides what the filename is, so that it at least doesn't cause conflicts, just duplicate and triplicate precompilation? :| 02:57
ugexe probably not a bad compromise 02:59
releasable6 Next release in ≈6 days and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
timo better than getting FTBFS issues and auto-removals every time we accidentally trigger the problem 05:27
09:25 sena_kun joined 09:51 finanalyst joined 09:55 sena_kun left 10:40 finanalyst left 10:42 finanalyst joined 11:42 finanalyst left, finanalyst joined 11:53 finanalyst left 12:45 finanalyst joined
[Coke] blows away his git repo of rakudo on windows, re-clones and tries one more time with vs2022 12:46
maybe some weirdness with submodules.
[Coke] thanks whoever it was that made VERBOSE_BUILD=1 an option 12:48
NMAKE : fatal error U1077: 'echo Creating library libdynload_s.lib ...' : return code '0xc0000409' 13:02
ab5tract still wonders whether specifying a branch to gen-moar genuinely works 13:27
14:03 finanalyst left 14:06 finanalyst joined
ugexe I’ve used —gen-moar with commit hashes in the past 14:22
14:27 finanalyst left
[Coke] ab5tract: it works in general, but not, as you noted, in the specific case where your 3 versions don't play nice together. 14:56
Happens infrequently enough that it's probably not worth having an option to NQP and rakudo's configs to ignore the required version. 14:59
note that I'm just trying to be vanilla rakudo 2024.10 here.
*build
coleman here's a link to zig's naming scheme for their on disk package cache github.com/ziglang/zig/issues/20178 15:15
ugexe yeah it would be pretty easy to do if our identifiers were [A-Za-z_][A-Za-z0-9_]* like zig 15:18
but our identifiers can include pretty much anything, including things that won't work on (some or all) file systems 15:19
one might then say well just puny encode the identifier when using it as a path name. but puny encoding isnt case sensitive, which means on systems with case sensitive file systems you can get conflicts between packages e.g. Foo and foo 15:20
coleman we can define a canonical encoding 15:21
but I am out of my depth on how it works in Raku exactly 15:22
ugexe you know any round trippable encodings that are file system safe on all file systems?
i dont
doesnt mean they don't exist but when i spent time trying to solve this i couldnt find an acceptable encoding solution 15:23
even then, the `auth` of a package also needs to be encoded into the name 15:24
which i mention because even if we restricted file package names and versions to file system safe characters, we'd still have the `auth` issue
coleman we would need a more creative solution, for sure 15:25
ugexe its a decent example of why exposing as much as possible often leads to situations where optimizations can't be made, since many optimizations often are based on using existing restrictions 15:27
15:38 finanalyst joined 15:50 finanalyst left 16:14 finanalyst joined 16:41 finanalyst left 17:29 finanalyst joined 17:45 finanalyst left, finanalyst joined 17:54 finanalyst left 18:21 sena_kun joined 18:27 finanalyst joined
patrickb [Coke]: github.com/MoarVM/MoarVM/pull/1859 fixes one of the build issues you observed. 18:47
I had trouble running moar Configure.pl with a non-main branch checked out. It helped to to do a build on main, then switch the branch, then build again. 18:49
timo patrickb: could be related to where the branch was branched off of the main branch, because the output of "git describe" is "last tag + number of commits since then" and the other configure.pls require the tag + number to be higher 19:00
[Coke] trying a build of your moarvm branch, patrickb.
if I'm building by hand, I'll just rewrite the required VERSION if needed in nqp/rakudo 19:01
patrickb: dies here with "fatal error LNK1181: cannot open input file '3rdparty\dyncall\dyncallback\ilbdyncallback_s.lib' 19:04
er, "libdyn..." 19:06
... that dir is not built at all, it seems
... there's a dyncall\dyncall\*lib .... but not a dyncall\dyncallback\*lib 19:09
timo uhh does a "git submodule update" change anything? 19:12
is this a problem with stuff missing in the makefile we create, or maybe the wrong prefix is used somewhere to compose these paths? 19:13
[Coke] I have "modified 3rdparty/libuv (untracked content)" also 19:20
which I don't know how to clear (git restore which is suggested does nothing) 19:21
timo that shouldn't be a problem. i assume that's some part of the build system adding files there that aren't in libuv's own .gitignore or something
[Coke] ... also if I go up a dir and trying to rmdir MoarVM, get a ton of errors about not having sufficient access rights to remove the .git folders. 19:25
which seems like a me problem, but that is weird, since they were created -as- me.
timo hahaha oh crap :D 19:33
but you're on windows, so
i just the other day read about something ino
involving git submodules and the permissions ending up without the write flag for some reason on windows
i think that would cause that kind of access rights error 19:34
but also, it might be what's preventing the libdyncallback_s.lib from being created? perhaps?
maybe a chmod u+w -R . could help solve all this trouble?
[Coke] instead of doing the triple build, going to find a version of moarvm that builds (got it, 2023.11) - now doing a git bisect to see if I can figure out when it stopped building here. 19:42
timo oooh, a thought occurs: what if we had a variant of MVM_oops that takes an argument "blame" that would then go through the raku stack and look for names that the blamed object has, so that when you encounter something like "hash with stale pointer encountered" it could actually give you the names of variables that hold this object ... and what if it could also look at other the stacks of other 19:44
threads to find one that also has a named reference to the same object at hopefully that very moment?
poured that thought into github.com/MoarVM/MoarVM/issues/1850 19:58
gist.github.com/timo/a938a7d4fb9f0...a33e7b3f73 - cross thread write log is currently unusable when Lock::Async is in use 20:19
"when Lock::Async is in use" is a funny way to say "when you use Supply blocks" 20:22
"supply" block / "react" block 20:26
[Coke] .... ugh; moar's 'nmake install' compiles a LOT more than just 'nmake' 20:42
Guessing my bisect is useless. 20:43
(or does it just recompile everything??)
Yah, I did 'nmake' and it built throught to moar.dll.exp - immediately typed 'nmake install' and appears to have recompiled everything. 20:46
timo damn, that sucks 20:47
[Coke] moving to #moarvm 21:02
22:41 sena_kun left
timo was the setup of moarop mappers in QASTOperationsMAST something that happened only at compile time before? 22:44
releasable6 Next release in ≈5 days and ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
Geth App-MoarVM-Debug/main: 44731b8e65 | (Timo Paulssen)++ | lib/App/MoarVM/Debug.rakumod
Make "step until" more interactive.

Cancellable with ctrl-c, showing how many steps it's done so far.
23:01 finanalyst left

Powered by Cro and the Raku® Programming Language.

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

Thank you!