01:00 librasteve_ left 01:56 guifa left 07:27 melezhik joined
ab5tract what's the base-compiler version of $context.ensure-sc ? 07:57
is there a method on $*W or something? 07:59
lizmat add_object_if_no_sc ? 08:30
ab5tract ^^ 08:31
ab5tract lizmat: thanks! 08:38
this nominalizable thing is so weird
why would the nominalization of a subset be the nominalization of its refinee? 08:39
(for example)
the code is basically $!of := self.IMPL-MAYBE-NOMINALIZE: $of 08:40
in the container creator
that's why in v6e .VAR.default isn't giving the subset, because its "nominalization" is just the refinee (or its nominalization) 08:41
it seems far fetched that in one language version you get the subset type object and in the next you get its refinee 08:42
lizmat agree 09:08
09:30 librasteve_ joined
Geth rakudo/main: 44bb652dce | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod
RakuAST: allow ::Block.new() to take :$multiness

This is apparently being passed to it in some situations, but does not apparently serve any purpose in the ::Block case.
This may be a band-aid type of fix, but since there is apparently already the same situation for :$signature, it feels it is ok to apply a similar fix for this case.
Fixes #5997		 10:25
ab5tract I think nine++ is right, just need to drop this, fix roast, and move on 10:35
10:54 Pixi` joined 10:58 Pixi left
melezhik . 11:24
I wonder if there an API or Raku module that calculate a REVERSE dependency count for specific Raku distribution ? 11:25
I probably might do it myself , it just would be handy if something already exists 11:26
I know Raku.land shows such counters 11:27
For modules
lizmat raku.land/zef:lizmat/Ecosystem#rev...pendencies perhaps? 11:28
melezhik lizmat: great šŸ‘ 11:31
^^ ab5tract ))
lizmat also, potentially raku.land/zef:lizmat/Ecosystem#river 11:39
melezhik Yep , exactly šŸ‘ that , you read my mind ) 11:49
github.com/melezhik/brownie/commit...0e9334f7e4
[Coke] I wanted that for App::zef-deps and never finished it, oops 12:06
releasable6: next
releasable6 [Coke], Next release in ā‰ˆ18 days and ā‰ˆ6 hours. There are no known blockers. 24 out of 24 commits logged
14:30 librasteve_ left
ugexe zef rdepends Foo lists reverse dependencies 16:07
[Coke] ugexe++ 16:12
ab5tract the ecosystem approach fits a bit better here, but I'm glad we've got redundancy 16:17
[Coke] melezhik: if you can successfully test "Red" in your setup, that would be impressive. 16:18
Or both versions of JSON::Class for that matter. 16:19
melezhik [Coke]: we are in the way to that ) 16:20
[Coke] in the way... "on the path"?
it's in the roadmap?
ab5tract I think melezhik means that we are almost ready to do a full run of the ecosystem 16:39
right now we are testing what happens with a shared install directory with 8 agent containers
going pretty good so far 16:40
most recent stastic is 11 minutes to test the first 100 most depended on libs (no shared volume)
timo how do we handle stuff like "we need to install DB libraries for testing much of DBIish"? 16:41
ab5tract timo: you mean native deps? 16:42
I guess we just add them to the Dockerfile as we encounter them 16:43
did I understand you correctly tho? 16:44
timo yeah, native deps 16:45
some stuff can only really be tested with a bit more setup, like a running database server with the right access credentials and stuff, which is potentially quite a bit more effort still 16:46
16:46 librasteve_ joined
ab5tract I think it makes sense to pre-install native deps. I'm not sure how to automate that but even doing it by hand shouldn't be *too* terrible 16:46
timo: that's fair, but then we might also just do the usual exclusion of say, `pg` 16:47
Anything that requires full setup is going to be on the developer to test fully
or perhaps add some stuff to the agent/sparrow code that handles their particular cornercase, if they want to be "all in in blin", so to speak 16:48
timo blin is for the benefit of the core development team to find stuff that breaks stuff in the ecosystem, so at least for some important modules i think adding that effort can be beneficial, and it's better for us to make such breakage show up in blin than for us to wait for module developers/maintainers to build a pre-release rakudo and run their own tests 16:50
it's very much a question of degrees, though
ab5tract yeah, fully agreed
luckily I think the frameworks that melezhik++ has put together should make even setting up and starting a postgres server straightforward 16:51
timo i think some things are reasonable, like running a postgres server and a mysql server so we can run tests for our database driver modules
"run a Xephyr server so that GUI toolkit tests can at least run" might be acceptable, too 16:52
we don't have very many modules like that
ab5tract ugexe: can multiple zefs install to the same directory or would each zef be contending on a single repo lock? 16:54
here I'm talking about a cluster of containers with a single shared volume
timo i wonder. maybe the lock is only held for the "staging" part but downloading, precompiling, testing can happen without holding? 16:56
16:59 ab5tract_ joined
[Coke] (native deps) that's how blin handles them now. we preinstall what we need. 17:00
if we find a module is failing because of a non-preinstalled dep, we add it to the list and rerun. 17:01
melezhik Brownie mimics that as well github.com/melezhik/brownie/blob/a...erfile#L33
But if we need more sophisticated scenarios itā€™s quite easy to enable them via sparky 17:02
ab5tract_ okay, thought on the naming .. what about "brownie" -> "bling"
melezhik Like spinning up Mariadb or whatever
ab5tract_ too cute, maybe?
melezhik I am open for renaming ) 17:05
We can launch a vote on mastodon or something
Or fosstodon 17:08
17:09 ab5tract_ left 17:15 ab5tract_ joined 17:16 ab5tract_ left 17:17 ab5tract_ joined
ab5tract_ I'm starting to like brownie in it's own right. it just occured to me, the blin -> bling. but maybe even better is blin -> blink (because it runs so much faster) 17:18
as it's an internal-focused tool, I wouldn't be very concerned about discoverability 17:19
17:50 ab5tract_ left
ab5tract [Coke]: looks like we are through 500 modules tested after ~ 1 hour 18:45
I think that the shared volumw helps a lot. If there is indeed contention issues on the repository, we could spread the resources over fewer containers and raise the degree in the zef config 18:49
ugexe any locks for installation are done by rakudo on a per-repo basis 19:10
melezhik Yep . Indeed after 1,5 hour brownie have completed 775 modules 19:11
ugexe if blin is using --install-to= to install to custom locations then it wouldnt be using staging and would be installing the old way 19:12
19:13 librasteve_ left
ugexe also i don't think precompiling can happen without holding the lock 19:17
the results of precompilation could change from when it is started to when it finished if someone adds files while it is precompiling
19:19 melezhik_ joined 19:21 melezhik_ left
ugexe if you could find a way to avoid setting --install-to / ZEF_INSTALL_TO and just installed to the default site repo it would be quite a bit faster 19:21
melezhik How changing installation to default site repo would solve concurrency issue? 19:24
I mean we can change the location , but having shared file storage with multiple zef installs on the time still remain 19:25
This is what happens now
For example - gist.github.com/melezhik/9e9a5390d...c01f4dfaee 19:31
Also this brw.sparrowhub.io/file_view/agent.r...g-Bird.log 19:33
Not sure how to read this - zef fails to install Hamming Bird or it successfully installed but just threw few warnings about already installed dependencies ? Anyway exit code is not zero , thus why sparrow treats this as a failureā€¦ 19:35
[Coke] There is a skiplist of bad modules you can swipe from blin as needed 19:38
github.com/Raku/Blin/blob/8497e679...51C1-L70C7 19:39
(of course, if they work you don't have to skip them)
ugexe anytime you want me to comment on zef output i would suggesting running with --debug 19:40
if i were to guess why it is failing it is related to rakudo precompilation 19:41
er, actually i assume it is because you have ZEF_INSTALL_TO set to something without also having RAKULIB set 19:42
without RAKULIB being set to (what i assume is) /root, and assuming TestML is already installed there, rakudo is not going to see that module or that it is installed 19:44
ab5tract ugexe: fair, though for the purposes of validating installation that should be fine, no? 19:46
ugexe it is inherently going to be flakey but maybe that is acceptable 19:48
ab5tract so our plan so far is to sort the input by reverse dependencies and start with the most used ones 19:49
but actually when it comes to the lock, I guess the actual dists being installed are less important 19:51
melezhik ugexe: so we also need to set RAKULIB so that zef will see installed modules, right ?
ugexe if that is the problem then yeah. im just taking a wild guess 19:52
ab5tract ah, yeah that makes sense
melezhik Ok . I guess this explain that , easy to patch . So we need to add export RAKULIB=$ZEF_INSTALl_TO:$RAKULIB ? 19:53
Ok . I just checked - RAKULIB="inst#/root/zef_install" should work 20:07
^^ ab5tract
ab5tract nice 20:08
20:12 disbot1 joined
whistlingzephyr testing the Discord bridge 20:13
alright, works 20:14
21:37 librasteve_ joined 22:42 melezhik 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!