🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
nine japhb: no, the two situations are not nearly the same. If bytecode files are not really architecture independent, it's because of 1 or maybe 2 bugs that are easy to fix. I'd be quite surprised if it was more, since I have tested it on MIPS 07:25
japhb nine: I'm happy to hear that at least. Was the MIPS 32-bit or 64-bit? 07:54
nine IIRC 32 bit 07:55
Woodi so, how much precomp files depend on comiler(s) version ? i'm usually testing monthly releases so "stable" thing - is there technical reason to recompile every month ? compiler version string changes so system wants to recompile. but maybe internal representation of precomps do not change or can be abstracted somehow to "relink" or something ? 09:21
s/technicl reason to recompile modules every month/ 09:22
nine Short answer is: very, very much. A small, innocent change in the compiler's source code can change things so precompiled code cannot work anymore. 09:31
dakkar m: my %a=:1x,:2y,:3z; sub f(:$x,:$y) { 1 }; say f(|%(%a<x y>:p)); 10:50
camelia 1
dakkar is there a prettier way to pass a hash slice as a set of named arguments?
lizmat dakkar: if you have control of sub f: 10:58
ah, no.. :-(
dakkar were you trying sub f(*%named) ? 10:59
lizmat yeah
or even sub f(%named)
but you're interested in the caller side :-) 11:00
dakkar f(%named) makes it a bit hard to set different type constraints on the different parameters 😜
moon-child sub f(%named where .<y> ~~ T) 11:02
dakkar sure, that's why I said "a bit hard"
oh well, I'll probably spell it out the long way, to make the call clearer 11:03
different question: what's the reason for not supporting something like `sub f(Str|Int $x)` ? 11:05
(I actually wanted `Any:U|Int:D()`, which may have different implementation problems)
moon-child I'm not sure what that would mean, actually 11:09
(the latter, that is)
does that mean: convert it to an Int:D if you can, otherwise leave it as Any:U?
or: if it's defined, then it must be Int:D(); if it's undefined, then it can be Any:U?
dakkar yes 11:10
moon-child which?
lizmat m: subset StrOrInt of Cool where * ~~ Str | Int; sub a(StrOrInt:D $a) { dd }; a 42; a "foo" 11:12
camelia sub a(Cool:D $a where { ... })
sub a(Cool:D $a where { ... })
lizmat I guess eventually a sig of sub a(Str|Int $a) could be syntactic sugar for that
dakkar moon-child: I'm not sure I see the difference between the two things you wrote… 11:14
lizmat: I was under the impression that `Foo $x` was generally nicer to the dispatcher/optimiser/introspection than `$x where Foo` 11:15
(also, coercions and `where` don't seem to play very well together) 11:16
moon-child dakkar: supposing there were some undefined type which could be implicitly converted to Int:D
lizmat pre new-disp the overhead was ginormous if you used "where"
dakkar moon-child: ooh, right, of course
moon-child would it fall into the Any:U bucket, on account of being undefined, or into the Int:D() bucket on account of being converted?
lizmat it's one of new-disp's features that that has become a lot less
moon-child also remember that by convention | is not short-circuiting and || i 11:17
dakkar moon-child: multi f(Any:U);multi f(Int:D()); ← do the same as that?
lizmat: very good to know (and many thanks to jnthn)
moon-child in that case it depends on the order of definition. But I assume that || is short-circuiting and | is not, so I find that inconsistent
dakkar moon-child: you're right 11:18
moon-child that said a short-circuiting (aka lazy) junction would be an interesting idea 11:19
dakkar in the end I wrote `proto f($x) { my code }; multi f(Any:U) {}; multi f(Int:D()) {}` 11:20
lizmat junction collapse is already short-circuiting
moon-child m: say so none lazy <x y>.map(&say) 11:23
camelia x
y
False
moon-child lizmat: I mean something that would avoid printing 'y' in the above 11:24
lizmat m: say so none lazy <x y>.first(&say) 11:25
camelia x
No such method 'lazy' for invocant of type 'Str'. Did you mean any of
these: 'any', 'say'?
in block <unit> at <tmp> line 1
lizmat m: say so none <x y>.first(&say)
camelia x
False
moon-child sure, but that's because of first, not none
lizmat Hmmm... 11:28
the problem with this is that none() currently will need to build the Junction, before the "so" can collapse it 11:29
moon-child yeah. I'm imagining a 'none-lazy(...)' sort of thing, analogous to [...] 11:30
(or just none(...), print it the same way)
dakkar www.thenautilus.net/cgit/media-con...akumod#n95 I got what I wanted thanks to `proto` and a probably-weird use of `{*}` 11:33
lizmat m: sub sonone(Iterable:D $i) { my $iter := $i.iterator; until (my $pulled := $iter.pull-one) =:= IterationEnd { return False if $pulled }; True }; say sonone ^10 # moon-child 11:34
camelia False
lizmat hmmm... I guess a Junction could have lazy eigenstates 11:37
holyghost re 17:03
BFI
holyghost is a bit drunk but had a nice vacation 17:05
www.mediafire.com/file/eois5z8xluu...ar.gz/file
An irc bot system from me
I'm trying out NLP (== natural language processing) with ANNs :-) 17:07
atroxaper Hello, #raku 18:06
tellable6 2021-12-21T21:06:15Z #raku <SmokeMachine> atroxaper maybe FCO is not that smart… :) but Red has :ver there because it’s updated by Mi6 and I could be wrong but I think that broke mi6 release when I removed that…
atroxaper .tell ugexe, please, tell me, is there a legal way to know which module what to 'use' from a custom CompUnit::Repository's need or so? An argument only tell us about what to load, but who needs it? 18:10
tellable6 atroxaper, I'll pass your message to ugexe
ugexe who says `use` comes from a module? 18:15
-e 'use Foo' and scripts `use Foo` as well
atroxaper If it is script - ok. But if it was another CompUnit. 18:17
ugexe I'm not even sure what that would mean 18:20
examine the call stack i guess 18:21
that will give you a file anyway
atroxaper ugexe: Now I will explain a little more. I found that if we don't write a version in "use", then the newest version from the repository will be used. Regardless of what is written in META 6.json, of course. I believe that firstly it is inconsistent, and secondly it is a security hole. I can upload a module to an Ecosystem with a module, for example, a Zef::Client module with a version higher than the real zef. If somebody install the module 18:30
than zef will use it instead of its Zef::Client. Because the zef modules did not specify the version in the usage statements.
lizmat atroxaper: the META just indicates what is needed according to the developer. If the developer then just doesn't care what it loads... well... that's their problem :-) 18:34
at least, that's the current situation
that's why I *always* specify versions in my -use- statements 18:35
atroxaper ugexe: Moreover, even within the same module, without dependencies, old versions of modules will use the new versions of their submodules, although they were tested only among the old version during installation.
lizmat now I agree we have room for improvement here
ugexe so pin your use statements 18:36
lizmat atroxaper: what ugexe says :-)
ugexe there is no consistent way to derive what versions to use from META6.json depends because you can very well depend on multiple version of the same module
atroxaper lizmat: I no do not agree that if is their problem. It is security problem. We cannot to force all developers specify version in use statements. But we want to use their module. I think we need to base on META6 information in case of 'empty' use version. 18:38
ugexe misusing dependencies is indeed a developer problem even if we wish it wasnt 18:40
atroxaper ugexe: META6 describes what we need to be installed for proper functioning of the module. When we need to 'use' a concrete version then we specify it. If we omit it, then use META6 info.
ugexe "because you can very well depend on multiple version of the same module" 18:41
how do you solve this?
(note this is only the most very basic problem)
lizmat ugexe: if you depend on multiple versions of a module, you need to be specific in your use statement 18:42
ugexe thats pretty inconsistent
lizmat I mean if code depends on Foo:ver<1.0> *and* Foo:ver<2.0>, then a "use Foo" in a module of that distro, could be a compilation error?
ugexe how do you declare you literally want any version? 18:43
and not for META6.json to do magic?
lizmat Foo:ver<*> afaik ?
ugexe which is the same as use Foo...
atroxaper Any version - omit it at all in use statement.
lizmat well, yes, at the moment
but with :ver<*> you're *specific* about accepting *any* version 18:44
ugexe well anyway I'm completely against inconsistencies so good luck trying to convince me of anything i guess
atroxaper lizmat: yes. You are right.
ugexe: which inconsistencies? META6 is obligatory elemnt of module. I specify dependency version there. And think that I do not need to specify the version in *all* use statement. Because I need to literally do in in *all* statement. 18:47
ugexe that `use` does different things
oh use will fill out your version unless you do this and then it instead does this, but you can also declare things like this to workaround that and get things to do this 18:48
atroxaper If I update a version of dependency, i need to update a version literal in *all* use statements. It is consistent but it is very uncomfortably. 18:49
ugexe you could very well write something to do it for you 18:50
ugexe which is way more reasonable than being in rakudo core because you can actually use dependencies to do it 18:50
rakudo doesn't know how to e.g. parse complicated depends
atroxaper ugexe: One more time. I can override Zef::Client right now on foreigner host. And do anything on someone else's host instead of Zef::Client work. 18:52
ugexe yes im quite familiar with how it works github.com/ugexe/zef/pull/334 18:53
atroxaper ugexe: exactly! After this patch, I won't be able to replace the Zef::Client, but I can replace almost any module in the ecosystem. We won't be able to force all developers to write START my $VER... in each file. 18:57
ugexe we could
an ecosystem doesn't have to accept a distribution
atroxaper But we already force them to write META6.json. We just need to ask them to specify version and auth for each depends. 18:58
ugexe a user doesn't have to use a specific ecosystem
we don't force them to write META6.json because they can use -Ilib 18:59
atroxaper And do something like BEGIN my $VER... automatically. It will not crash anything but fix a lot of things.
ugexe i would suggest being explicit until someone figures out how to implement all that in a consistent way 19:01
atroxaper If I use -Ilib I know what I do. But if I use official ecosystem, I what to safe installation of safe modules.
ugexe ecosystems are configurable, you're free to use whatever ecosystem your e.g. business allows/trusts
if some module doesn't live up to some ecosystems standard that isn't really isn't something to be solved by the language 19:02
atroxaper ugexe: Ok. Then. Let me rephrase. Now the language state allows siply achieve dependency hell situation. Raku has very good system with auth, ver and api versioning but it is not defend us from dependency hell. There is no Ecosystem word in my description now. 19:05
ugexe its not intended to avoid dependency hell. if anything our entire system welcomed it by making everything overridable/configurable/supercedable/etc 19:06
even still, i would hardly classify our situation as what most people refer to as dependency hell 19:07
being explicit about your dependencies everywhere is the classic way to avoid dependency hell 19:08
atroxaper 1. I install module A, depends B:ver<1>. A works well. I install Module C depends B:ver<2>. A stopped working. 19:09
ugexe if i write a module that doesnt work right that isnt the language fault
we are looking for a solution to allow existing sloppy patterns to DTRT some of the time
atroxaper Modules A,B and C is not my.
ugexe so dont use the broken modules 19:10
no one forces you to use code that is written in a way that doesnt work
if a given ecosystem had e.g. quality control Module A might not even be indexed at all 19:11
atroxaper Are you serious? Ok. Then we need to ask all developers who what that other people use their work, write BEGIN my $VER... my $A-VER... my $B-VER.... It is so Raku, I mean easy. 19:13
ugexe well like i said, you are welcome to attempt to implement what you suggest 19:14
the hardest part will be figuring out how to do this without reading the META6.json when loading modules 19:15
otherwise `use` statements will need to read a file and parse it to json which in the past has been too much of a performance penalty to consider doing 19:17
atroxaper ugexe: I propose the following algorithm. Firstly, in CompUnit::Repository we need to have an access to caller CompUnit if it is. If we processing use statement with ver then load it. If we processing use statement with * then load higher version. if we processing omit version, then read META6 and understand which version the module whanted and load it. 19:18
ugexe well part of my point was that is all so complicated to do that anything short of an implementation is probably moot 19:19
atroxaper We can store META6 in some binary format. Or better write versions of module(file) dependencies in precomp file.
ugexe I don't think anyone would stop you from doing those things 19:20
atroxaper ugexe: I really ask you to consider the feasibility of these changes within the RSC. I think this is very, very important for the language. 19:24
ugexe i have been commenting on the *feasibility* specifically 19:25
thats why im telling you that if you think it is feasible that you should champion it and implement it
lizmat atroxaper: again, what ugexe said :-) 19:26
but also, please make a problem solving issue for this
atroxaper lizmat: will do. 19:26
lizmat I also have some ideas about the situation, and I think these are best discussed / developed in an issue, rather than on IRC
atroxaper lizmat: not so always :) github.com/lizmat/Hash2Class/blob/...keleton#L8 19:33
lizmat atroxaper: hehe , ok, almost always :-) 19:34
ugexe fwiw if I were doing raku apps in production I would a) be using a local ecosystem/darkpan with vetted distributions only b) installing distributions in application specific locations instead of global locations 19:52
atroxaper ugexe: I think Python's virtual environment is a crutch. I wouldn't want that for Raku. 19:57
Today I found --contained flag in zef and this is just the beginning. 19:59
ugexe only problem is there is no way to remove the default site/home repos
i.e. no way to say "only use this one specific repository and none of the defaults" 20:00
atroxaper Custom CompUnit::Repository could hide site/home repos, no? 20:01
ugexe yeah that would probably work
atroxaper CompUnit::Repository::Barrier :)
ugexe but it would probably be useful as a core thing so you can do `RAKUDO_DEFAULT_REPOS="" raku -I. t/my-test.t` 20:02
(which would only use the . repo) 20:03
then again in a test you'd want `use Test` which would mean it would have to be `RAKUDO_DEFAULT_REPOS="perl" raku -I. t/my-test.t` 20:04
s/perl/core
spacekookie Hey! Another grammar question >.> I extended the one I posted a few days ago to have "scopes" (which themselves are a set of lines with stuff in them). But I think something is not being evaluated properly because the % binding at the bottom is failing: paste.rs/woZ.pl 20:24
Skarsnik grammar are black magic! xD 20:25
spacekookie They are but also one of the main reason I want to learn raku :P 20:30
I keep being like "hey I should write this DSL" and doing this is Rust every time is just overkill

Powered by Cro and the Raku® Programming Language.

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

Thank you!