🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel! Set by lizmat on 6 September 2022. |
|||
00:00
reportable6 left
00:01
reportable6 joined
00:03
xinming left
00:07
jpn left
00:08
xinming joined
00:14
a3r0 left,
a3r0 joined,
DarthGandalf left
00:15
DarthGandalf joined
00:23
epony left
00:27
freeside left
00:32
Manifest0 left
00:40
freeside joined
00:44
cfa left
00:46
freeside left
00:49
freeside joined,
jpn joined,
epony joined
00:51
ProperNoun left
00:55
freeside left
00:59
rf_ left,
rf joined
|
|||
rf | . | 01:02 | |
Evening folks, I won't be too active here and in the doc repo for a bit. Having some massive prod issues at work, and of course I'm on call. If you need me though i'll be checking IRC for tells everyday. | 01:03 | ||
01:03
xinming left
01:05
xinming joined
01:12
freeside joined
01:17
freeside left
01:22
rypervenche joined
01:23
freeside joined
01:50
ProperNoun joined
01:53
MasterDuke joined
|
|||
guifa | rf, happens to the best of us sometimes. but appreciate all your work | 02:01 | |
02:12
jpn left
|
|||
rf | guifa: thanks! | 02:13 | |
02:36
jpn joined
02:43
jpn left
02:45
jpn joined
02:50
jpn left
03:01
jpn joined
03:08
jpn left
03:19
jpn joined
03:29
jpn left
03:53
freeside left
04:21
jpn joined
04:22
freeside joined
04:29
jpn left
05:14
jpn joined
05:19
jpn left
06:00
reportable6 left
06:03
reportable6 joined
06:08
jpn joined
06:10
freeside left
06:12
jpn left
06:47
freeside joined
07:03
jpn joined
07:08
jpn left
07:45
Sgeo left
08:28
jpn joined
08:33
jpn left,
stevied_test left
08:34
stevied_test joined
09:04
Manifest0 joined
09:08
ab5tract joined
09:10
DarthGandalf left,
dakkar joined
09:14
DarthGandalf joined
09:24
freeside left
09:28
freeside joined
09:30
sena_kun joined
09:32
freeside left
09:36
freeside joined
09:41
freeside left
09:58
abraxxa-home joined
10:01
abraxxa-home left
10:21
grondilu joined
|
|||
grondilu | Hi all. | 10:21 | |
So, some time ago I broke my Digest module. | 10:22 | ||
Or worse : I made changes that broke modules that were depending on it. | |||
I think it's kind of unfortunate that this can happen at all. | 10:23 | ||
el reinstall it? | |||
grondilu | Lately I've learned about Nix/NixOS, and if I understand correctly with that system of package management it's impossible to break something. | 10:24 | |
Maybe zef could take inspiration from it to avoid that kinds of pitfalls? | |||
10:28
freeside joined
10:32
freeside left
|
|||
grondilu | or even look into Hydra, NixOS's Continuous Integration system. Seems pretty cool. | 10:33 | |
in any case package management seems to me like quite a generic task, I'm kind of surprised that Raku needs its own system for it, can't it use an already existing, possibly more robust system? | 10:34 | ||
lizmat | grondilu: you broke it because you changed the code and not updated the version ? | 10:40 | |
grondilu | I did change the version, I think. | 10:41 | |
lizmat | if that's the case, I think it's at least partially the fault of the user for not pinning the version that they want to use in their production code | 10:42 | |
grondilu | but the truth is, I find it quite annoying to have to change the version number all the time. | ||
El_Che | I would love to one day evolve to "build" of a minimal rakudo + all libs. Of course, C dependencies shatter the dream a little :) | ||
lizmat | grondilu: how would people be able to tell which version they want of your module? | ||
from a sha? | 10:43 | ||
grondilu | yes | ||
a digest | |||
like in nix | |||
El_Che | grondilu: versioning is essential, and not moving tags | ||
grondilu | El_Che: I hate it | ||
El_Che | otherwise users will hate you | ||
semantic versioning is where is at today | |||
and that create expectations | 10:44 | ||
s | |||
Nemokosch | well, "pinning versions" is only as much a solution as bundling someone else's code with yours, offline | ||
lizmat | grondilu: you could use something like App::Mi6 that basically makes updating version numbers something like "version 0.0.4? Y/n" | ||
El_Che | Nemokosch: bundling is good | 10:45 | |
tellable6 | El_Che, I'll pass your message to Nemokosch | ||
Nemokosch | unless it turns out there was, say, a zero-day in what you bundled | ||
receiving updates to something in production - even "implicit", mandatory updates - can be important | 10:46 | ||
El_Che | Nemokosch: bundling == you are responsable, you need to publish an update | ||
tellable6 | El_Che, I'll pass your message to Nemokosch | ||
Nemokosch | then it's basically not actual modularity | ||
El_Che | and it's not because it's bundled that you can not update it, or get an update lib before on the search path | 10:47 | |
Nemokosch: yes by design | |||
tellable6 | El_Che, I'll pass your message to Nemokosch | ||
Nemokosch | then probably the generalization that "this needs to be done in production" seems unfortunate | ||
then probably the generalization that "this needs to be done in production" seems unfortunate | 10:48 | ||
El_Che | that's why ruby's ecosystem is a burning garbage container | ||
everything breaks all the time | |||
in gem land | |||
Nemokosch | anyway grondilu, there is a reason concepts like semantic versioning exist | 10:49 | |
grondilu | I think it's ridiculous that a package management system can fail so bad that it breaks things. | ||
Nemokosch | not to say that I'm super good at authoring but I lowkey wish the ecosystem enforced some meaningful versioning, rather than Whatever | ||
and a lot of the worms seem to be coming from the banal fact that a lot of modules were authored in a time when people were happy to publish Perl 6 code at all | 10:51 | ||
versioning was nonexistent in the ecosystems, and that was the least thing to worry about | |||
another problem that grondilu's example highlighted is the lack of conceptual awareness of the dependency resolution system | 10:53 | ||
I was also shocked to learn how it is designed to work - and on some level, it doesn't matter if somebody is "shocked" or just "surprised" | 10:54 | ||
grondilu | I admit I don't know the details of how these things work. | ||
Nemokosch | if you think that your dependencies are dists and at some point it turns out that they are in fact modules, probably there has been enough harm done in the meantime | ||
grondilu | but I can see that how things work currently seems very far from optimal | 10:55 | |
10:56
abraxxa joined
|
|||
Nemokosch | grondilu: for the record this was a big part of the module breakage. if you depend on "Digest", that's Digest the module, not Digest the dist - however, the dist may also be found and resolved to it, as a kind of fallback | 10:56 | |
grondilu | like the name Conflict there was with the Digest::HMAC module. This was ridiculous IMHO | 10:57 | |
Nemokosch | there were two bites | ||
in quick succession | |||
the first bite was that dependencies are all modules, irrespective of the dist they are contained in - therefore your Digest::HMAC module can collide with any other Digest::HMAC module (or dist, at installation) | 10:58 | ||
grondilu | modules or repo should not be identified with a low entropy name such as 'Digest', IMHO | 10:59 | |
it's a recepe for name resolution conflicts. | |||
Nemokosch | I mean, why did you give it that name? 😄 | ||
it clearly increased the pressure | |||
grondilu | I mean the names should be salted | 11:00 | |
like they do in Nix. I'm impressed by this system, I think they do things right. | |||
Nemokosch | cont "modules are the dependencies": inb4 yes, if you pin the author, you half solve the problem - collisions are still possible within the same author but then one will blame the author anyway, right? | ||
11:00
abraxxa left
|
|||
el salt it yourself Digest_718719794791 | 11:01 | ||
Nemokosch | 🤣 | ||
grondilu | fair point | ||
Nemokosch | by the way, how does a dependency look like, in that system? | ||
grondilu | I think they just use hashes everywhere, basically. Not sure that answers your question, though. | 11:03 | |
Nemokosch | yeah nah, doesn't give much of an idea about the user's perspective | ||
anyway, let me finish the analysis - the second bite was that in the META6 file (and clearly not in the code!), a name still may resolve to a distribution rather than a module, and apparently module resolution doesn't even have absolute priority over dist resolution | 11:05 | ||
this means that somebody could depend on "Digest", understood as a dist, and then try to use Digest - which wasn't provided by the dist anymore | |||
grondilu | but what does the 'depends' entry mean in the META6 file? Does it refer to modules or repos? | 11:09 | |
Nemokosch | it means modules as a main rule - but zef at least can find dists as well, under some circumstances | ||
grondilu | I thought it meant repos, so I thought not having a Digest module in my Digest repo was fine. | 11:10 | |
Nemokosch | well, if it meant modules strictly and consistently, that would have probably worked... | ||
because then it wouldn't have treated a recent "Digest" as a possible candidate at all | 11:11 | ||
also... in case anybody is already getting salty somewhere, about the "complaining". YES, the author of the module has made a mistake (improper versioning - changing modules of a distribution is a breaking change on the highest level, not sure if it should even be allowed tbh). | 11:14 | ||
YES, the users also made a mistake (by not pinning their dependencies by anything else but name - not any pattern of version, not the author) | 11:15 | ||
grondilu | That's the thing : the system should be more robust and not break because of a human error. | ||
At the very least, it should notice the upgrade failed and then rollback, no? | 11:16 | ||
Nemokosch | Well, if it treats modules the dependencies, it definitely shouldn't select the dist when there are modules with that name available | 11:17 | |
el if there is a name collision should that be resolved with namespaces? | 11:19 | ||
or is it a different problem | 11:20 | ||
Nemokosch | "Always complaining", right? If by complaining, we really only mean criticism without offering possible directions of resolving the problem - then all the complaining is about the attitude of "fix yourself", that's basically a betrayal of the Perl 6 vision | ||
For the dependency management, there have been several, really varied ideas for improvements, a great variety honestly | 11:21 | ||
I don't know much about Nix and dependency immutability but that's also a point | |||
"clarifying the relation of a distribution and a module" is like five points | 11:22 | ||
this is about dependency resolution, my feline friend | 11:23 | ||
grondilu | I enjoy writing raku code, but having to housekeep a module repo is not fun at all to be honest. | 11:24 | |
el elaborate im lost in this discussion 😭 | |||
Nemokosch | grondilu: I think it gets easier once you have the right idea of what is going on | ||
however, I have to say I don't like "what is going on", and that I've already said with arguments that basically just bounced back without an acho | 11:25 | ||
*echo | |||
I still think not everything is lost and dependency management could be designed around distributions, rather than modules floating in heavens | 11:26 | ||
lizmat | grondilu: again, things like App::Mi6 do most of that work for you | ||
grondilu | lizmat: I'll look into it | 11:27 | |
lizmat | and speaking as the author with the most modules in the ecosystem, I think I can say I know what I'm talking about :-) | ||
Nemokosch | however, if module dependencies are really the way to go (which puts immediate pressure on the naming of your exposed modules, too!) - then the META6 needs to get "nerfed" in favor of paying attention to metadata directly provided by modules | 11:28 | |
grondilu | lizmat: I don't doubt it, but not everyone can spend a lot of time into figuring out how all of this work | ||
Nemokosch | hence basically making modules as sort of mini-distributions | 11:29 | |
I don't think this is a hard rule but right now, ecosystems rely a lot on META6 solely | 11:30 | ||
and META6 exists per distribution, not per module | |||
lizmat | grondilu: in short: zef install App::Mi6; mi6 new Foo; cd Foo; edit lib/Foo.rakumod; edit t/01-basic.rakutest; mi6 build; git diff for checks; mi6 release | ||
Nemokosch | which practically means that even a properly-pinned name is "dirty": it partially refers to data tied to the distribution, and data tied to the module | 11:31 | |
el i think its about breaking something and forgetting to specify a version | |||
grondilu | maybe a bit out there but : shouldn't module distribution informations belong in POD6 comments inside the module, instead of a separate META6 file? | ||
Nemokosch | basically yes, I think that would be one way to get more stable and transparent | 11:32 | |
grondilu | also then that would settle the issue about module vs repo distributions : everything would be modules, and a repo would just be a set of modules. | 11:33 | |
Nemokosch | yes! | ||
grondilu | glad to see we agree | ||
Nemokosch | right now, META6 (and the lack of consideration for module-provided metadata) is the biggest enemy of that | ||
mind you, modules can technically provide their metadata - it's just not taken into account over META6 | 11:34 | ||
grondilu | if I'm not mistaken, at the moment POD6 is very much NYI, isn't it? | ||
that is the %*POD6 var or something | |||
Nemokosch | good question but I'd say that would be an unrelated discussion. Modules can communicate their metadata with attributes | 11:35 | |
11:35
lizmat left
|
|||
Those attributes are just ignored/not set, most of the time | 11:35 | ||
grondilu looks the doc about pod variables | 11:36 | ||
the = twigil is what I was thinking about | |||
I guess that would be needed to put the distrib info in POD6 comments | 11:37 | ||
Nemokosch | another question would be: does it even make sense to say that a distribution has a "version"? And if it does, that version has loose relation with the module versions | ||
grondilu | 🤷 | 11:38 | |
Nemokosch | let's take your Digest distribution again. Say, you make a change to, idk, your Digest::MD5 module. Then clearly it receives a new version. However, if you have, for example, a Digest::MAC module as well, why should that get a new version? | 11:39 | |
moritz | usually just for simplicity | 11:40 | |
grondilu | well it shouldn't if we decide to distribute everything as modules. | ||
Nemokosch | I mean I don't think publishing the same thing under different consecutive versions can actually break anything but it's confusing at best | ||
Yes, well... another banal solution is to just not bundle any two modules together 😆 | |||
Then a module will indeed correspond to a dist | 11:41 | ||
moritz | if you have shared code between your modules (in the form of helper modules, for example) it can be really hard to tease out which module is affected | ||
and if you don't have any shared code, yes, separate distributions sound like a good idea | |||
Nemokosch | I was about to say that moritz probably knows the history of distributions better | 11:42 | |
Apparently it's pretty much the same thing in Perl 5 land | |||
11:43
lizmat joined
|
|||
perhaps it seemed safer to do "whatever changes, everything changes" | 11:43 | ||
because of the possibility of internal changes, not exposed by the module | 11:44 | ||
11:54
grondilu left
12:00
reportable6 left
12:02
reportable6 joined
|
|||
anyways... actually I had a question - does anybody have experience with generating module code as a part of the build? | 12:03 | ||
Would make life easier for HTML tags | |||
lizmat | whenever I needed to generate code, I usually wanted to have that as a separate step for the developer, using a helper script | 12:07 | |
if you really want that, I guess using a Build module would be the place ? | |||
Nemokosch | yes, I would think so, it's just I never did something like that so I don't really know the places of interaction, like what can happen when | 12:12 | |
this Build module would run before the usual installation step? | 12:13 | ||
12:15
woei joined
|
|||
ugexe | what language are you using where every module in a bundle is versioned searately? | 12:47 | |
Nemokosch | this is kind of a "principle of explosion" question without first asking: what language makes modules of a bundle with no individual metadata, the units of dependency | 12:49 | |
ugexe | ah, the 'ol answer the question with another question | 12:50 | |
Nemokosch | it was begging the question | 12:52 | |
ugexe | is that what begging the question means? | 12:55 | |
jast | begging the question essentially means circular reasoning | 12:56 | |
ugexe | right | 12:57 | |
jast | more specifically, assuming the conclusion | ||
12:58
ispyhumanfly left
|
|||
jast | example from Wikipedia: "Green is the best color because it is the greenest of all colors" | 12:58 | |
Nemokosch | sorry if I didn't use the right term, maybe "complex question" fits better en.wikipedia.org/wiki/Complex_question | 13:01 | |
ugexe | alright, then: ah, the 'ol answer the question with a complex question | 13:04 | |
lizmat | ugexe: why do you say that? :-) (no, don't answer :-) | ||
Nemokosch | more like, the ol' "ask a complex question out of context to imply something" | 13:05 | |
lizmat | perhaps we should get back to the question: does anybody have experience with generating module code as a part of the build? | 13:06 | |
ugexe | ok. well my point is (since i've recently mentioned "answering questions with more questions" here) that answering questions with more questions (regardless of if they imply something, or whatever) isn't likely to get you answers | ||
El_Che | isn'it? (back to the circular thing :) ) | ||
ugexe | there are a couple of modules that had like Foo.pm6.in file (a template) and filled them in at build time | ||
i don't remember them though | 13:07 | ||
Nemokosch | anyway, this is a usual case of, people will react to what they want, the way they feel like. Apparently the discussion was more worth adding questions of dubious value than sharing experience about codegenned modules 😦 | 13:08 | |
ugexe | no, its just that you have a pattern of answering my questions (and probably others) the same way | 13:09 | |
i'm trying to help you get your answers, but i'm not a chatgpt bot | 13:10 | ||
Nemokosch | and you have a pattern of asking presumptuous questions, and also declaring at one point that the whole discussion is just pointless. Why even bother, then, really? Who does it help? | 13:11 | |
ugexe | well, have it your way i guess. I won't keep wasting both our time | 13:12 | |
Nemokosch | tbh IRC probably isn't even the best place for certain discussions to happen | 13:17 | |
however, unfortunately there is this tendency that on github, one must have tons of luck to get anyone's attention for a topic | 13:18 | ||
p6steve | I would like to have support for code generation in the module build-execute process ... the use case is (i) there's a raku slang, (ii) it can parse and codegen for a compiled language (C, C++, Rust...), (iii) it can dynamically build a SO and (iv) it can then call the new SO to execute the new code --- where is the best place to post this as a feature requiest? | 13:26 | |
ugexe | you can do all of that | 13:29 | |
Inline::Perl5 does this | |||
you essentially just do all of that in a make file and then execute that in a Build.rakumod or using Distribution::Builder::MakeFromJSON | 13:32 | ||
p6steve | sorry --- I did not mean to imply that this can't be done --- thanks for the pointer | ||
Geth | doc/lizmat-lose-compose: 47a9da7df3 | (Elizabeth Mattijsen)++ | doc/Language/phasers.pod6 Lose mention of COMPOSE phaser Associated with github.com/rakudo/rakudo/pull/5193 Note: there are *NO* tests for the COMPOSE phaser |
13:37 | |
13:52
jpn joined
|
|||
ab5tract | Nemokosch: Can you clarify what you mean about "making life easier for HTML tags" ? | 14:04 | |
tellable6 | ab5tract, I'll pass your message to Nemokosch | ||
ab5tract | I wrote a recent blog post about generating subs on import, not sure if that is something that could help | 14:05 | |
Nemokosch | I'm thinking about getting decent coverage of tags in the HTML::Tag dist | 14:15 | |
(because, well, I noticed that the poor guy continuing my work is doing ugly hacks and it's simply because HTML5 tags are usually missing, lol) | 14:16 | ||
so one thought I had is that I don't mind having dummy classes for each and every tag; that type system can come handy possibly | 14:17 | ||
Geth | ¦ doc: coke assigned to MonalikaPatnaik Issue update CONTRIBUTING.md github.com/Raku/doc/issues/4189 | ||
Nemokosch | however, in that case, it would be good to generate these dummy classes, rather than having, I don't know, 100 in a maintained raku module file | ||
ab5tract | Hmmm, defining classes on the fly like that is probably a lot trickier than subs | 14:19 | |
Though in either case my approach would probably avoid actual codegen in favor of dynamically generating definitions in code | 14:20 | ||
I guess that's the kind of thing that RakuAST is going to unlock ... | |||
rf | Lol prod issue at work caused almost 2tb of memory to leak in 5 hours | 14:27 | |
We figured it out though :D | 14:28 | ||
El_Che | rf: you should close DB transactions! | 14:29 | |
:) | |||
rf | It was actually S3 bucket files lol | ||
The developer thought the file handles were being closed but they definetley weren't | |||
El_Che | close | 14:30 | |
Nemokosch | ab5tract: you know, I'm fine with simply generating the file, as source | ||
it's a very simple structure, after all | 14:31 | ||
14:34
perlbot left,
simcop2387_ joined,
simcop2387 left
|
|||
ab5tract | Not sure how to do that in a way that "just works" | 14:34 | |
14:35
freeside joined,
simcop2387_ is now known as simcop2387
14:38
perlbot joined
|
|||
moritz | cd | 14:38 | |
sorry | |||
Nemokosch | 😅 | 14:39 | |
either way, it's good to see you around every now and then | 14:40 | ||
moritz | even when I'm just here for changing my directory :-) | 14:42 | |
Nemokosch | a rare feature of the #raku channel | 14:45 | |
rf | lol | ||
Nemokosch | pfff, thank you, discord | ||
# r a k u | |||
rf | What does :D: vs just :D mean? | 14:47 | |
In type definitions. | |||
Nemokosch | : appears in methods in particular, no? | 14:48 | |
in which case I'd assume you mean the separator of the "self" parameter | |||
rf | Something like method(Complex:D: --> Complex:D) | ||
Nemokosch | yes, that's for the "self" | 14:49 | |
rf | I see | ||
Nemokosch | it can be called on a Complex:D and returns a Complex:D | ||
fun fact: there even is a call syntax like that | |||
instead of foo.bar(baz) or foo.bar: baz, there is even bar foo: baz | |||
moritz | TBH after doing Python for quite some time, I like their default better, which is that all methods are instance methods, unless you specify it otherwise | 14:50 | |
rf | submethod vs method? | 14:51 | |
moritz | forgetting the :D on the invocant is just too easy, and when you specify it all the time, it's quite the clutter | ||
Nemokosch | method vs "class method" | ||
moritz | submethod is not inherited, that's orthogonal to class vs. instance method | ||
Nemokosch | It's not even that clear what would be THE one "class method" in Raku | ||
oh well, thinking Python, it is clear after all | 14:52 | ||
a subroutine scoped in a class - that's a "static method" | |||
a method taking a type object - that's a "class method" | |||
perhaps? | |||
tbh I don't know many languages that make this distinction, let alone as consciously as Python does | 14:53 | ||
moritz | most "static" OO languages make that distinction | 14:58 | |
"static" in java and C++ (iirc) | |||
(where with the first "static" I meant statically typed) | |||
Nemokosch | as much as I remember, C++ only had "static methods" by Python's terms | 14:59 | |
which would make sense since C++ classes are not first-class citizens of the language | |||
so a function cannot just take them | |||
I'd assume the same about Java, C# etc even though they have reflection some way | 15:00 | ||
15:20
jgaz joined
15:40
zashi joined
|
|||
Voldenet | it would be awesome if there was no distinction between static and not on syntax level | 15:46 | |
where using reference to self would promote the static method into instance method automatically | 15:47 | ||
not that it's realistic to implement that across module usages | |||
15:48
Sgeo joined
|
|||
Nemokosch | well, this is Raku, if you don't mind the risks | 15:48 | |
that you really meant a definite instance and ended up passing a type object | |||
Voldenet | m: class { my $.ok = 1; method instance-method { say self.ok; } }.instance-method | 15:50 | |
camelia | 1 | ||
Voldenet | Yes, this is proper code | ||
forgetting the .new gives you runtime error so it's not that amazing | 15:51 | ||
rf | why my over has here? | 15:52 | |
Voldenet | :> | 15:53 | |
my is a static variable here | |||
m: class { has $.ok = 1; method instance-method { say self.ok; } }.instance-method; | 15:54 | ||
camelia | Cannot look up attributes in a <anon|1> type object. Did you forget a '.new'? in method ok at <tmp> line 1 in method instance-method at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
Voldenet | tbh though, it's poor syntax in this case, really implies something else | 15:55 | |
m: class { my $ok = 1; method instance-method { say $ok; } }.instance-method; | |||
camelia | 1 | ||
Voldenet | this is more obviously static | ||
Nemokosch | m: my $.ok = 1; dd $.ok; | ||
Raku eval | Exit code: 1 ===SORRY!=== Variable $.ok used where no 'self' is available at /home/glot/main.raku:1 ------> my $.ok = 1; dd $.ok⏏; expecting any of: argument list term Other potential difficulties: Useless generation of accessor method in mainline at /home/glot/main.raku:1 ------> my ⏏$.ok = 1; dd $.ok; | ||
Nemokosch | gotcha | ||
still... is that $ok only an accessor or a normal, fully-fledged variable? | 15:56 | ||
m: class { my $ok = 1; method instance-method { say self.ok; } }.instance-method; | |||
Raku eval | Exit code: 1 No such method 'ok' for invocant of type '<anon|1>' in method instance-method at main.raku line 1 in block <unit> at main.raku line 1 | ||
Nemokosch | it is a variable, then | ||
with has scoping, it would be just an alias of the accessor | 15:57 | ||
my $.ok could even be an oversight? | |||
Voldenet | still, using accessors on type objects feels weird | ||
Could be, but maybe generics change something here | 15:58 | ||
Nemokosch | Again, I'd hope that the new compiler frontend will be considerably cleaner | 16:00 | |
hence easier to reason about these decisions | |||
see why they came to be and how they could be changed | |||
Voldenet | nope, generics don't change anything in here | 16:01 | |
m: role n[\T] { my $.ok = 1; method instance-method { self.ok++; } }; for ^10 { say n[$_ %%2 ?? Int !! Str].instance-method } | 16:03 | ||
camelia | 1 1 2 2 3 3 4 4 5 5 |
||
Voldenet | m: role n[\T] { my $ok = 1; method instance-method { $ok++; } }; for ^10 { say n[$_ %%2 ?? Int !! Str].instance-method } | ||
camelia | 1 1 2 2 3 3 4 4 5 5 |
||
16:14
freeside left
16:22
freeside joined
|
|||
Scotteh | lizmat: Thank you for the lovely message on the obituary. | 16:24 | |
16:34
camelia left,
m_athias left,
nine left
16:35
nine joined,
m_athias joined
16:38
m_athias left,
nine left,
m_athias_ joined
16:39
camelia joined
16:40
nine joined,
zashi left
16:43
m_athias_ is now known as m_athias
16:50
jpn left
17:30
Xliff joined
17:38
dakkar left
17:43
freeside left
17:44
freeside joined
17:53
freeside left
17:54
freeside joined
18:00
reportable6 left
18:01
reportable6 joined
|
|||
rf | Been thinking about writing an emacs package for fez | 18:01 | |
18:05
freeside left
18:09
nine left,
m_athias left
18:10
nine joined
18:19
freeside joined
18:25
Monalika9 joined
18:29
jgaz left
|
|||
lizmat | Scotteh: you're very much welcome | 18:32 | |
19:10
epony left
19:11
epony joined
19:20
freeside left
19:23
freeside joined
19:27
jgaz joined
19:28
freeside left
20:01
NemokoschKiwi joined,
freeside joined
20:23
xinming left
20:25
xinming joined
20:37
Monalika9 left
21:01
freeside left
21:05
NemokoschKiwi left
21:12
freeside joined
21:16
deoac joined,
freeside left
|
|||
deoac | Is it possible to use Perl source filtering in a Raku program? I've tried ```use Filter::Simple:from<Perl5>;``` without success. | 21:17 | |
21:25
melezhik joined
|
|||
melezhik | .tell jjatria I created a simple CI pipeline that also runs a code snippet from http tiny readme, let me know if you are interested and I can create a pr | 21:26 | |
tellable6 | melezhik, I'll pass your message to jjatria | ||
p6steve | deoac: let me test on my kit | 21:30 | |
what is your OS? how did you install rakudo & Inline::Perl5? | 21:32 | ||
21:34
melezhik left
21:48
freeside joined
|
|||
deoac: it works for me (although I barely know how to use this module | 21:49 | ||
gist.github.com/p6steve/624fe58c68...7d35068496 | |||
^^^ here's how - you are welcome to use or to plunder my example Dockerfile | 21:50 | ||
===SORRY!=== Error while compiling //scum.raku Unsupported use of /g. In Raku please use: :g. at //scum.raku:4 | 21:51 | ||
21:51
jpn joined
21:53
freeside left
21:57
jpn left
22:00
jpn joined
22:06
jpn left
22:07
sena_kun left
22:08
freeside joined
22:14
deoac left
22:18
Xliff left
|
|||
rf | Can I destructure a Pair the same way we can a List | 22:32 | |
Something like | |||
m: my $pair = :abc(123); -> :$key($value) { say $key, $value; }($pair); | 22:33 | ||
camelia | ===SORRY!=== Error while compiling <tmp> Shape declaration with () is reserved; please use whitespace if you meant a subsignature for unpacking, or use the :() form if you meant to add signature info to the function's type at <tmp>:1… |
||
rf | m: my $pair = :abc(123); -> :$key ($value) { say $key, $value; }($pair); | 22:34 | |
camelia | Too few positionals passed to '<anon>'; expected 1 argument but got 0 in sub-signature of parameter $key in block <unit> at <tmp> line 1 |
||
rf | m: my $pair = :abc(123); -> ($value => $key) { say $key, $value; }($pair); | ||
camelia | ===SORRY!=== Error while compiling <tmp> Preceding context expects a term, but found infix > instead. at <tmp>:1 ------> my $pair = :abc(123); -> ($value =>⏏ $key) { say $key, $value; }($pair); |
||
Nemokosch | I think you can, the syntax didn't click | 22:37 | |
:$key, :$value | |||
m: my $pair = :abc(123); -> :$key, :$value { say $key, $value; }($pair); | 22:38 | ||
Raku eval | Exit code: 1 Too many positionals passed; expected 0 arguments but got 1 in block <unit> at main.raku line 1 | ||
Nemokosch | yeah yeah | ||
m: m: my $pair = :abc(123); -> (:$key, :$value) { say $key, $value; }($pair); | |||
Raku eval | abc123 | ||
rf | Okay cool, thanks! | 22:39 | |
22:55
ispyhumanfly joined
22:59
ispyhumanfly left
23:10
freeside left
|
|||
Geth | ¦ doc: coke self-assigned Move HTML/CSS/js out of the repo github.com/Raku/doc/issues/2931 | 23:22 | |
¦ doc: coke assigned to dontlaugh Issue The binary-based CI test is broken github.com/Raku/doc/issues/2859 | 23:26 | ||
¦ doc: coke self-assigned What's really autothreading and is it used correctly? github.com/Raku/doc/issues/2779 | 23:30 | ||
¦ doc: coke self-unassigned What's really autothreading and is it used correctly? github.com/Raku/doc/issues/2779 | |||
¦ doc: coke self-unassigned Spin off Pod::Convenience github.com/Raku/doc/issues/2696 | 23:32 | ||
23:35
ab5tract left
23:39
freeside joined
23:44
freeside left
23:45
nachtvlinder joined
23:48
nachtvlinder left
23:51
Nemokosch joined
23:59
freeside joined
|