🦋 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.
00:08 reportable6 left 00:22 Skarsnik left 01:11 reportable6 joined 01:35 linkable6 joined 01:36 evalable6 joined 02:36 linkable6 left, evalable6 left, lockywolf left, linkable6 joined 02:37 evalable6 joined 03:07 lockywolf joined 03:18 lockywolf left, lockywolf joined 03:28 jgaz left 04:04 DISCO94 joined 04:07 DISCO94 left 05:07 bisectable6 left, coverable6 left, notable6 left, greppable6 left, reportable6 left, evalable6 left, committable6 left, shareable6 left, squashable6 left, unicodable6 left, sourceable6 left, quotable6 left, releasable6 left, bloatable6 left, benchable6 left, tellable6 left, linkable6 left, nativecallable6 left, statisfiable6 left, statisfiable6 joined 05:08 committable6 joined 05:09 linkable6 joined, nativecallable6 joined, bisectable6 joined, notable6 joined 05:10 releasable6 joined, reportable6 joined 05:13 canw joined 05:17 canw left 05:42 guifa joined 05:43 guifa left 06:06 reportable6 left 06:07 coverable6 joined 06:08 quotable6 joined 06:09 bloatable6 joined, evalable6 joined 06:10 squashable6 joined 06:11 lockywolf left 06:12 lockywolf joined 06:34 lockywolf left 06:35 lockywolf joined 06:36 Xliff_ joined 06:39 Xliff left 07:07 tellable6 joined 07:09 greppable6 joined 07:10 unicodable6 joined 07:17 frost left
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
07:28 seednode left 07:29 seednode joined 07:49 lockywolf left 07:53 lockywolf joined, defaultxr joined
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
08:03 lockywolf left 08:07 benchable6 joined 08:09 shareable6 joined 08:14 lockywolf joined 08:20 lockywolf left 08:21 lockywolf joined 08:28 Sgeo left 08:30 lockywolf left 08:31 lockywolf joined 08:43 merpaderp left 08:44 merpaderp joined 09:08 reportable6 joined 09:09 sourceable6 joined
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
09:53 Oshawott joined 09:56 archenoth left 10:01 jjido joined 10:47 dakkar joined
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?
10:56 sena_kun joined
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)
11:32 jjido left
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
11:36 jjido joined
lizmat hmmm... I guess a Junction could have lazy eigenstates 11:37
11:54 synthmeat left 11:55 synthmeat joined 11:59 frost joined 12:07 reportable6 left 12:08 reportable6 joined 12:14 sena_kun left 12:15 sena_kun joined, sena_kun left 12:19 sena_kun joined 12:44 Kaiepi left 12:53 Kaiepi joined 13:53 linkable6 left, evalable6 left 13:55 linkable6 joined 14:27 sena_kun left 14:56 evalable6 joined 15:00 sena_kun joined 15:01 sena_kun left 15:07 Sgeo joined 15:15 jgaz joined 16:15 linkable6 left, evalable6 left 16:36 monkey_ joined 16:46 jgaz left 17:02 holyghost joined
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
17:15 sena_kun joined 17:17 linkable6 joined 17:36 TheAthlete joined 17:39 jgaz joined, discord-raku-bot left 17:40 discord-raku-bot joined 17:55 discord-raku-bot left, discord-raku-bot joined 18:06 sena_kun left, atroxaper joined
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…
18:08 sena_kun joined, reportable6 left
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
18:17 evalable6 joined
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
18:25 monkey_ left 18:29 monkey_ joined
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.
18:31 dakkar left
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
18:50 monkey_ left
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
18:51 monkey_ joined
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
19:26 jgaz left
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
19:34 retupmoca left
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
20:07 mexen left 20:10 reportable6 joined 20:11 atroxaper left 20:19 Skarsnik joined
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
20:27 monkey_ left 20:29 euandreh left, monkey_ joined
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
20:46 ProperN[out] joined, ProperNoun left 21:42 swaggboi left 21:44 euandreh joined 21:45 swaggboi joined 21:52 jgaz joined 21:53 jgaz left 21:57 Kaiepi left 21:59 swagg_boi joined 22:02 TheAthlete left 23:02 linkable6 left, evalable6 left 23:03 swaggboi left, swagg_boi left 23:04 swaggboi joined, swaggboi left 23:14 swaggboi joined 23:16 jjido left 23:47 djerius left 23:50 djerius joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!