🦋 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. |
|||
cfa | like, someone else my want to use MyMod 'widget' isntead? | 00:00 | |
00:00
reportable6 left
|
|||
cfa | (to alias &foo as &widget) | 00:00 | |
lucs | Exactly. | 00:01 | |
cfa | urgh, typos, sorry; someone else may want to use MyMod 'widget' instead? | ||
lucs | Yep. | ||
00:02
reportable6 joined
|
|||
ugexe | so just make a sub EXPORT that exports everything regardless of whatever is on the right side of `use Foo :bar` | 00:02 | |
lucs | You know, ultimately, rf's solution could be fine, but I'm really curious about how to do this inside the module itself. | ||
cfa | i think that's almost the example here: docs.raku.org/language/modules#EXPORT | ||
look for $short_name => MyModule::Class | |||
lucs | ugexe: I tried a bunch of stuff with EXPORT, but I wasn't able to make it work. | ||
cfa: Yeah, I saw all that. | 00:03 | ||
cfa | you want to just map whatever's passed in to the sub | ||
lucs | Looks easy, right? Welp, I wasn't able to come up with the right expression. | 00:04 | |
In that $short_name example, I think I'd want something like 「Map.new: do "&$short_name" => ??? if $short_name」, but is it indeed 「&$short_name」 and what goes at 「???」? | 00:18 | ||
cfa | with the caveat that i have no idea what i'm doing: | 00:22 | |
gist.github.com/cfa/13c5088670b6a1...b237ebca9f | |||
00:22
derpydoo left
|
|||
cfa | (i used `our` in this example so that i could easily reference A's &foo from within EXPORT) | 00:23 | |
i'm sure someone who's used EXPORT before can provide better guidance; i was just riffing on that example | 00:24 | ||
lucs | I didn't think of 'our'. | ||
But this, copied from my failing experiments, fails: | 00:25 | ||
Map.new: do "&$new-subname" => &MyMod::subname if $new-subname; | |||
(same as yours, eh) | |||
cfa | yeah but subname will just be lexically scoped by default | ||
i.e. it's effectively `my sub subname` | 00:26 | ||
so EXPORT can't see it | |||
lucs | Won't the EXPORT take care of that? | ||
Maybe I'm not following... | |||
cfa | EXPORT isn't in the same scope | ||
lucs | Right. | ||
cfa | from the docs: it looks like EXPORT is part of the compunit rather than the package/module, so we can't place it inside the module definition (and hence the module's scope). | 00:31 | |
lucs | Correct. | 00:33 | |
Um, I'm going to eat now, and resimplify my gist again. | |||
(there is also a potential "multi" problem) | 00:34 | ||
TTYL | |||
cfa | cheers | ||
00:36
Manifest0 left
|
|||
cfa | hmm | 00:49 | |
regarding this, | |||
m: module A { sub foo is export { ... } }; module B { sub foo is export { ... } } | |||
camelia | ===SORRY!=== Error while compiling <tmp> A symbol '&foo' has already been exported at <tmp>:1 |
||
cfa | i might have answered my own question, though the behaviour still seems surprising | ||
i.e. if the exporter relates to the compunit rather than the module itself, then this makes sense | 00:50 | ||
(as does this differing from the .rakumod case) | |||
anyway, & | 00:51 | ||
rf | I successfully made cinnamon buns | 00:58 | |
01:36
evalable6 left,
linkable6 left
01:37
linkable6 joined
01:39
evalable6 joined
01:50
derpydoo joined
|
|||
Anton Antonov | @rf Using Raku? | 02:09 | |
rf | I wish. No, sadly just in real life. | 02:10 | |
lucs | Is this legit?: $condition ?? (use A) !! (use B) | ||
'use' is compile-time, iiuc, so I'm wondering. | 02:11 | ||
Anton Antonov | @rf If you proclaimed that earlier I might have used cinnamon buns making example in my Gherkin grammar post... | ||
el compile time conditions hmm | 02:12 | ||
rf | Lol. That would have been excellent | ||
lucs | Well, the $condition would be evaluated at runtime, eh. | 02:13 | |
rf | You're much better off using require vs use in that scenario. | 02:15 | |
lucs | Oh, maybe 'require'. | ||
rf | ^ | ||
lucs | Yeah, just thought of that :) | ||
el @if $?VERSION ~~ v2.d+ foo @else bar @endif | 02:19 | ||
Anton Antonov | @rf The "Highlander" movie example is the same as the one in cucumber.io . Food preparation would be also good. | ||
02:20
cfa left
02:22
frost joined
|
|||
Nemokosch | the BEGIN phaser runs at compile time, though | 02:32 | |
so who knows... | |||
02:46
razetime joined
|
|||
lucs | Okay, can't make it simpler. Hope I'm clear in what I'm trying to do (previously explained): gist.github.com/lucs/5335c195d3642...48606c21d8 | 03:16 | |
03:21
coleman left,
coleman joined
03:35
razetime left
03:58
razetime joined
03:59
codesections joined
04:17
rf left
04:31
codesections left,
codesections joined
04:37
razetime left
04:47
razetime joined
04:52
codesections left,
codesections joined
05:21
codesections left
05:23
codesections joined
06:00
reportable6 left
06:03
reportable6 joined
|
|||
Nahita | @lucs only slight change is needed. problem is, A::orig is not really accessing the &orig residing inside the class A because subroutines are "my"-scoped, i.e., lexical by default. So to attach that symbol to the class, you can "our"-declare it instead. In multis, it wants an our-declared proto, so our proto sub orig(|) is export {*} multi orig (Int $n) { $n * 2 } multi orig (Str $s) { $s ~ $s } inside the | 06:10 | |
class A should do it | |||
06:10
bbrtj left
06:56
pingu joined
06:57
razetime left
07:02
jpn joined
07:04
razetime joined
07:07
jpn left
07:19
frost left
07:29
razetime left
07:30
razetime joined
07:41
abraxxa-home joined
07:44
razetime left
07:45
sena_kun joined
07:53
razetime joined
|
|||
el will raku have implicit interfaces (static duck typing)? | 07:55 | ||
07:56
p6steve left
08:08
frost joined
08:24
frost left
|
|||
moritz | I don't think so, that doesn't fit with the dynamic vibe of raku | 08:28 | |
08:30
jpn joined
|
|||
el moritz: then why have gradual typing in the first place 🤔 | 08:35 | ||
08:35
jpn left
|
|||
moritz | so that you don't have to specify types when you don't want to care about them, but you *can* specify types if you want, and get benefit from them | 08:39 | |
08:40
Sgeo left
08:42
grondilu joined
|
|||
grondilu | Hi all (today I'm trying Emacs's IRC client) | 08:42 | |
tellable6 | 2023-02-18T21:26:37Z #raku <tbrowder> grondilu the raku/perl6 emacs mode does have the capability to show an index of raku classes, subs, and variables | ||
moritz waves to grondilu | 08:43 | ||
el m:perl role R { sub a() { ... } } class C { sub a() { say ‘hello’ } } say C ~~ R; | |||
Raku eval | False | ||
el roles can’t be checked for implicit satisfaction | 08:45 | ||
grondilu | that seems sensible to me | ||
el i want structural typing | 08:46 | ||
roles is not a viable way to do that | 08:47 | ||
grondilu | subsets then? | 08:49 | |
08:49
freeside left
|
|||
grondilu thinks raku's subsets are pretty neat | 08:49 | ||
08:50
dakkar joined
|
|||
moritz | subsets are neat, but they don't provide any benefits at compile time | 08:55 | |
el how can i do this with subsets then protocol Pet { sub cry(); sub pet(); sub feed(Food $); } | 08:57 | ||
moritz | subset Pet of Any where { .^has_method('cry') and .^has_method('pet') } | 08:58 | |
not ideal | 09:00 | ||
el it doesn’t have any constraints on the signature | |||
09:00
jpn joined
|
|||
grondilu: how would you do that then | 09:01 | ||
09:05
jpn left
|
|||
grondilu | Apart from something like what moritz showed above, I don't know. | 09:05 | |
el see | 09:06 | ||
09:08
Manifest0 joined
|
|||
moritz | there's not really structurual typing in raku, it's mostly nominal | 09:14 | |
Nemokosch | Which is a bit strange, given that you can create a class that respects indexing, without making it Positional | 09:16 | |
el raku allows dynamic duck typing but not static duck typing smh | 09:24 | ||
El_Che | static duck typing? | 09:25 | |
el structural typing | |||
El_Che | millions of static language programmers cried in error! A unbalance in the force! | ||
09:26
jpn joined
|
|||
Nemokosch | by the way, static duck typing is present in traditional C++ templatess | 09:41 | |
I remember the uni teacher even said "it's the only reasonable form of duck typing" | |||
09:43
ab5tract joined
09:55
pingu left
09:59
ab5tract left
10:05
freeside joined
|
|||
el c++ - the language that tries to do everythin | 10:11 | ||
10:30
sena_kun left
10:38
jpn left
10:53
freeside left
11:06
sena_kun joined
11:14
grondilu left
11:26
razetime left
11:39
jpn joined,
TieUpYourCamel joined
11:41
razetime joined
11:57
razetime left
12:00
reportable6 left
12:02
reportable6 joined
|
|||
Geth | ecosystem/main: 774f4da9cf | (Elizabeth Mattijsen)++ | META.list Remove Intl::Format::Number, it now lives in zef ecosystem |
12:03 | |
12:04
codesections left
12:18
Xliff joined
|
|||
Geth | doc/finanalyst-patch-1: f03b281df7 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/101-basics.pod6 remove TM char for consistency This addresses issue #119 in doc-website, was in Raku/doc Either all references to Raku should have tm or none. My preference is for none as it is obvious |
12:24 | |
doc: finanalyst++ created pull request #4205: remove TM char for consistency |
|||
[Coke] | .ask codesections can we get feedback on github.com/Raku/doc-website/issues/119 | 12:32 | |
tellable6 | [Coke], I'll pass your message to codesections | ||
[Coke] | what do folks think of something like "use rakudo *>2022.07;" | 12:37 | |
(Trying to think of a syntax in the docs to say this was introduced in some compiler version, and then wondering if we could use the same syntax in the actual compiler) | |||
12:39
Xliff left
|
|||
lizmat | that syntax could actually be made into a module | 12:40 | |
[Coke] | right! | ||
lizmat | and possibly added to the core | ||
[Coke] | then I can make it *your* problem, and just document it. :) | ||
lizmat | but better in ecosystem, as then older versions of Rakudo would also be able to use it | ||
[Coke] | as all things should be? ;) | ||
12:41
gcd joined
|
|||
lizmat | I just wonder about what the name of the distribution should be | 12:41 | |
"rakudo" feels.. ambiguous ? | |||
Rakudo::VersionMatcher ? | 12:42 | ||
[Coke] | something from <use rakudo compiler version requirement> | ||
That seems reasonable. | |||
then we can document "use this module" somewhere in the docs, and add these lines wherever we have a known version requirement. (We already have the version specification one.) | 12:43 | ||
12:46
derpydoo left
|
|||
lizmat | actually, make it a real version object, so "use rakudo * > v2022.07" | 12:46 | |
to allow for better version semantics | |||
this would also allow: "use rakudo v2022.07+" | 12:47 | ||
[Coke] | Yes, please. | ||
lizmat | I'll whip up the module after finishing today's Weekly | ||
[Coke] | ... Crap. Ok, I'll get this incorporated into the docs for the next milestone (end of March). | 12:48 | |
(sooner if possible) | |||
github.com/Raku/doc/issues/302 was the original ticket where we were discussing what this might look like. | 12:50 | ||
Nemokosch | what would that module do exactly? | 12:53 | |
Iirc there is a module that dies if you don't fulfill some version constraint, courtersy of Zoffix | |||
12:54
hythm joined
|
|||
[Coke] | that's it, die if your compiler version didn't match. | 12:56 | |
Sure, if it's already out there, maybe we can save lizmat a few minutes here. | |||
Nemokosch | github.com/raku-community-modules/RakudoPrereq | 12:57 | |
it doesn't seem like a lot of work; if you decide on a different interface, this could probably even be archived, with some pointers to the new thing | 12:58 | ||
[Coke] | looks like the syntax there is a little different (and only lets you set a minimum version, not a where clause), but seems good enough. | ||
added that to the ticket, thanks. | 12:59 | ||
lizmat | fwiw, I think if you want to match the documentation with the use statement, a new module may make sense after all | 13:05 | |
hythm | .tell Nemokosch: wrt to grammar question I posted a few days ago, looks like I needed to do two things to solve the issue, first needed to use `|` semantics (as you suggested), instead of `proto` which seems uses `||` semantics. second needed to use `regex` instead of `token`, looks like regex backtracks to find best match. updated the gist with | ||
the changes gist.github.com/hythm7/128bc02c190...f9b827f892 | |||
tellable6 | hythm, I'll pass your message to Nemokosch | ||
lucs | Aha! Yes, that appears to work fine. Thanks for the code and for the explanation! | 13:06 | |
13:14
jpn left
|
|||
[Coke] | lizmat: I agree. we can always point to the prior art and include the info about why a new one in the readme. | 13:15 | |
Nemokosch | oh yes, regex backtracks, I did know that part but I didn't know that would have the right consequence here | 13:17 | |
moritz | I generally recommend to avoid backtracking over regex boundaries in a grammar, things can get very confusing very quickly | 13:33 | |
hythm | If no backtracking over regex, what would be the alternative | 13:36 | |
13:42
jpn_ joined
|
|||
moritz | I have no idea what you're parsing, but generally you can chose your tokens/regexes in a way that once you have parsed something as a token, you commit to that | 13:42 | |
(at least when parsing computer code/languages; might be different for natural language) | 13:43 | ||
Nemokosch | well a lot of the issue boils down to the grammar definition, that's for sure | 13:47 | |
hythm | I', trying to parse a command line options by grammar. lets say I have an option that is both can be specified as boolean or as having value. lets say an option named "deps", when grammar sees "deps", actions method will make `deps => True`. when grammar sees "deps test", action method will make `deps => 'test'. so far so good, but if there is | 13:49 | |
exisiting another option named "test", therre will be an issu | |||
e how to parse it, should be paresd as two options "deps" and "test", ot one option "deps => test" | |||
moritz | and if the input string is "--deps --verbose", then --verbose will be parsed as a separate option? | 13:51 | |
token option-with-optional-argument { '--deps' \s <argument-that-does-not-look-like-option>? } | 13:52 | ||
token argument-that-does-not-look-like-option { <!before '--'> \S+ } | 13:53 | ||
hythm | Thanks will try these and see how it goes. | 13:54 | |
re: "and if the input string is "--deps --verbose", then --verbose will be parsed as a separate option?" yes. | |||
moritz | token option-with-optional-argument { '--deps' [ \s+ <argument-that-does-not-look-like-option> ]? } # likely better, the separating space should also be optional | 13:56 | |
hythm | regarding the optional space, I'm thinking to make use of it in an edge case when the user really want "deps test" to be parsed as `deps => "test"`, instead of parsed as two options"deps" and "test". so the user can remove the optional space "depstest" | 14:02 | |
anyway I'll try the above and see how it goes, thanks | 14:03 | ||
14:05
jpn_ left
14:10
razetime joined
|
|||
hythm | if I'm not prefixing options with `--` (meaning "verbose" instead of "--verbose", how token argument-that-does-not-look-like-option will look like | 14:10 | |
moritz | well, you have to have *something* to distinguish options from their arguments | 14:14 | |
even if it's a hard-coded list of possible option names | |||
if you don't, neither the grammar nor a human has a good chance to parse it correctly | 14:15 | ||
el oh no 😢 ===> Searching for: fez ===> Updating fez mirror: 360.zef.pm/ !!!> Failed to update fez mirror: 360.zef.pm/ ===> Updating rea mirror: raw.githubusercontent.com/Raku/REA.../META.json !!!> Failed to update rea mirror: raw.githubusercontent.com/Raku/REA.../META.json No candidates found matching identity: fez | 14:46 | ||
14:48
jpn joined
14:53
rf joined
|
|||
rf | Good morning folks. | 14:55 | |
Anton Antonov | @rf Did you eat all buns yet? | 15:04 | |
rf | No, but i'm ashamed to say I ate 6 out of the 14 I made haha | 15:05 | |
lucs | Solved: Renaming an exported sub: gist.github.com/lucs/cc60e0b0f6a34...bf704da061 | ||
Anton Antonov | @rf Well, it is a good idea to eat you own food -- helps aligning the food preparation process. | 15:06 | |
@rf So, what is the verdict? You did good? | |||
el can someone add my module to p6c github.com/dangduomg/Super | |||
rf | Yeah I like them, by far my best attempt yet! | ||
@el gatito you should upload to zef | 15:07 | ||
Anton Antonov | @rf Ok, not to be too obnoxious here, but how many attempts did you do? | 15:08 | |
el i can't install fez | |||
rf | Lol. I've been trying to make them for about 2 months, maybe 3 tries total I am not a very good baker :D | ||
Why not @el gatito? | 15:09 | ||
Anton Antonov | @rf Cool. (Persistence is the key.) | ||
Nemokosch | it would be better to fix that installation because p6c is not usable in the long run | ||
rf | ^^ | ||
Nemokosch | is there a reason you put the subs inside a class? | ||
el rf: C:\Users\jack9>zef install fez ===> Searching for: fez ===> Updating fez mirror: 360.zef.pm/ !!!> Failed to update fez mirror: 360.zef.pm/ ===> Updating rea mirror: raw.githubusercontent.com/Raku/REA.../META.json !!!> Failed to update rea mirror: raw.githubusercontent.com/Raku/REA.../META.json No candidates found matching identity: fez | |||
lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/02/20/2023-...herkining/ | 15:10 | |
rf | lizmat++ | ||
lucs | Nemokosch: I'm not quite sure. The idea is to make them available when the user does "use A". | 15:11 | |
Nemokosch | to be fair... | ||
===> Searching for: fez ===> Updating fez mirror: 360.zef.pm/ ===> Updated fez mirror: 360.zef.pm/ The following distributions will be upgraded: fez:ver<40>:auth<zef:tony-o>:api<0> ===> Updating: fez:ver<40>:auth<zef:tony-o>:api<0> Segmentation fault | |||
rf | Lol. | ||
Nemokosch | An unexpected old friend... | 15:12 | |
rf | el gatito: What version of rakudo? | ||
Nemokosch | (installed for the second time though) | ||
el C:\Users\jack9>raku -v Welcome to Rakudo™ v2022.12. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2022.12. C:\Users\jack9>zef --version v0.14.5 | 15:13 | ||
Nemokosch | looks like Windows | ||
el my terminal doesn't support unicode lmao | |||
Nemokosch | @lucs frankly I keep mixing up what name signifies what but I'm assuming it didn't work without | ||
a class is a package probably | 15:14 | ||
rf | @el gatito maybe clone and build from master | ||
el tenor.com/view/crying-emoji-dies-gif-21956120 | 15:15 | ||
Anton Antonov | @lizmat The link to "Intl::Format::Number" is not working; it should be raku.land/zef:guifa/Intl::Format::Number . (And thank you very much for posting!) | ||
rf | git clone github.com/tony-o/raku-fez.git && cd raku-fez && zef install . --force-install | ||
el gatito ^ | |||
Adjust that to be windows compatible lol. Sorry I am not sure how windows works at all for command line | 15:16 | ||
I think powershell is posix compliant so maybe use that | |||
Nemokosch | zef can still install from a github link iirc | 15:17 | |
lizmat | Anton Antonov thanks for the headsup, fixed: the link was to the version I just removed from the ecosystem :0) | ||
Nemokosch | zef install github.com/tony-o/raku-fez.git | ||
rf | Oh yeah forgot about that. zef install --force-install -v github.com/tony-o/raku-fez.git | ||
I find I need force-install if the build has failed sometimes | |||
Nemokosch | hmmm | 15:18 | |
not sure if that's intended or not | |||
el also why raku has 3 ecosystems 😭 | |||
rf | Don't ask why. | ||
Nemokosch | historical reasons - nowadays, only "the zef ecosystem" should be relevant | ||
rf | Yeah, only use zef. | ||
Nemokosch | the other two were experimental attempts, so to speak | ||
el Unable to find a suitable handler for web (tried Fez::Util::Curl, Fez::Util::Wget) | 15:21 | ||
failed | 15:22 | ||
lucs | Nemokosch: Interestingly, the only apparent difference when having the proto and the multis outside the class (no class necessary then) and changing the 'Map.new' line from 「… => &A::orig …」 to 「… => &orig …」 is that when doing 「use A 'mine';」, the 'orig' sub remains visible instead of being undeclared (I have no idea why -- I'm semi-cargo-culting all this). | 15:23 | |
Nemokosch | that's probably because it is our-scoped | 15:25 | |
what if you take your former code and check if you can see A::orig? | |||
(iirc classes are our-scoped themselves) | 15:26 | ||
el full text: gist.github.com/dangduomg/7c4f8f9b...9f5e8c69ca | |||
in conclusion: can't install fez on windows 😭 | |||
lucs | Nemokosch: Not sure which former code you mean -- I've done so many variations, eh. What you're thinking about is not mentioned in my latest gist? | 15:27 | |
Nemokosch | well you are doing a great service by at least figuring that out and illustrating the demand | ||
lizmat | [Coke]: considering Rakudo::Version as the name of the module | ||
allowing for "use rakudo v2022.01+" | 15:28 | ||
Nemokosch | the one you said about that "it worked" | ||
rf | el gatito: You need curl installed | 15:29 | |
el rn only way is to download the module yourself and zef install it | |||
rf | curl.se/windows/ | ||
[Coke] | lizmat: sounds good to me. | ||
lucs | Nemokosch: Sorry, I'm really not sure which one you mean -- the code would need to be spelled out. | 15:30 | |
Nemokosch | the code you made the "difference" to | 15:33 | |
and the "difference" was that orig became visible | |||
now I'm hypothesizing that A::origin became invisible, in return - something that we earlier haven't paid attention | 15:34 | ||
15:36
cfa joined
15:38
jpn_ joined
|
|||
el rf: ok, where do i place the directory for curl for zef to recognize | 15:41 | ||
15:41
jpn left
|
|||
lucs | Nemokosch: When the A class wraps the "our proto" and the multis and the 'Map.new' has 「"&$new-name" => &A::orig」, then having 「use A 'mine'」 makes 'orig() undeclared, but 'A::orig()' is visible. | 15:43 | |
Nemokosch | then gotcha - there is the one extra sub | 15:46 | |
lucs | The 'our' at work, eh. But for my use case, this is okay, since it's the plain 'orig()' that I want to hide. If the user does 'A::orig()', well they know exactly what they're getting. | 15:48 | |
el rf: | 15:51 | ||
oh just add curl to PATH | 15:53 | ||
found that out by reading the code lol | |||
15:54
Sgeo joined
|
|||
cfa | lucs: if you don't want the our, how about gist.github.com/cfa/4efb1fa5eb2f98...11ccc6abaf ? | 15:55 | |
lucs | cfa: Not that I don't want it per se, but that's an interesting idea, I'll play with it. | 15:56 | |
15:58
freeside joined
|
|||
lucs | freeside: Hallo! | 15:58 | |
rf | el gatito: Did it end up working? | 15:59 | |
16:01
jpn joined
16:02
freeside left
16:03
jpn_ left
|
|||
el i also have to install tar | 16:04 | ||
it worked now | |||
poggers | |||
rf | Nice. | 16:05 | |
16:13
freeside joined
|
|||
el what C:\Users\jack9\Documents\raku\Super>fez upload =<< ERROR: Failed to write 67 bytes to filehandle: Bad file descriptor | 16:14 | ||
16:18
freeside left
|
|||
bruh | 16:19 | ||
ugexe | Modern versions of windows 10 and 11 come with both curl and tar | ||
shouldn’t need to update PATH when using them either | 16:20 | ||
cfa | as part of wsl, or just normal binaries? | ||
ugexe | normal binaries | ||
cfa | (i haven't used windows since, hmm, 7?) | ||
and then, only very briefly | |||
ugexe | Windows 7 is no longer supported so I suspect there won’t be much more catering to it | 16:21 | |
cfa | oh, i just meant that my knowledge of the platform is fairly dated | 16:22 | |
the last windows i used "properly" was probably 2000 | |||
that's *cough cough* years old at this point | 16:23 | ||
cfa sighs | |||
ugexe | pureinfotech.com/tar-curl-windows-10/ | ||
rf | el gatito are you on windows 7? | 16:25 | |
ugexe | Depending on a specific version of rakudo (or even rakudo in general) should be discouraged in distributed modules | 16:26 | |
el i use older versions of windows 10 (because my computer is 10 years old and screams at higher versions) | |||
rf | Maybe its time to use linux :^) | ||
ugexe | otherwise in the future we end up with ecosystems for each raku compiler | ||
el rf: need spare flash drives for that lmao | 16:27 | ||
ugexe | I would suggest updating windows 10 to something more modern. Not necessarily 11, but at least the latest patches / service packs | 16:28 | |
el does anyone know this error | |||
rf | I can almost gurantee that is something to do with windows version | ||
16:29
pingu joined
|
|||
ugexe | Windows 10 build 17063 and later | 16:30 | |
el in case you are curious i use build 10240 lmao the og windows 10 | |||
16:31
ab5tract joined
|
|||
rf | Virtual machine? | 16:43 | |
If you aren't willing to update windows, or install linux VM is probably your only option | |||
[Coke] | ugexe++ | 16:47 | |
el windows 10 version 1803 should be good enough imo | |||
it contains build 17063 | 16:50 | ||
cygwin? | 16:51 | ||
rf | WSL | ||
[Coke] | I have a build version higher than that here (still on windows 10), been mostly ok. | ||
(using neither cygwin nor wsl) | |||
16:52
abraxxa-home left
16:56
freeside joined
|
|||
lizmat | [Coke]: raku.land/zef:lizmat/Rakudo::Version | 16:59 | |
17:04
freeside left
|
|||
Nemokosch | yes, one shouldn't depend on Rakudo versions, yet it's probably an invisible bomb for a long time | 17:06 | |
with modules that downright use NQP | |||
[Coke] | lizmat: thank you. I may provide a PR that addresses ugexe's concern about balkanizing the ecosystem. | ||
17:13
QhpAptyj9hj0RQwM joined
17:26
freeside joined
17:28
perlbot left
17:29
simcop2387 left
17:30
freeside left
17:31
simcop2387 joined
17:33
perlbot joined
|
|||
[Coke] | (just a note in the README) | 17:35 | |
17:36
razetime left
17:39
dakkar left
17:40
jpn_ joined
17:42
jpn left
17:47
jpn_ left
17:48
freeside joined
17:52
freeside left
|
|||
ugexe | We don’t try to make it easier to e.g. use nqp | 17:54 | |
Nemokosch | How to put it. The guidance to not use nqp just to gain performance, is indeed out there. But then there is also JSON::Fast which must be among the most used Raku dists out there - all NQP. And truth be told, I'm also relying a lot on stuff like HTML::Entity::Fast, simply because the performance benefit couldn't be overlooked... | 17:59 | |
18:00
reportable6 left
|
|||
ugexe | truth be told it shouldnt be written in nqp | 18:00 | |
or rather it should be written in nqp and in the core | 18:01 | ||
(which it is, so rather it should be a public feature) | |||
18:03
reportable6 joined
|
|||
ugexe | if we want to bless a single compiler into existence and base our future outlook on a single compiler then i'll change my stance though | 18:03 | |
Nemokosch | Fair enough. It seems that these days, it's worth considering. Currently, it doesn't seem legitimate to create another Raku compiler - neither technically, nor specification-wise (it's not worked out well to actually make that possible), nor ecosystem-wise (a lot of stuff would just downright break) | 18:05 | |
Also, the development of the language itself is driven by what can be achieved with Rakudo | 18:06 | ||
ugexe | technically there actually is a public interface to JSON parsing through CUR, you just have to use it in a way it wasn't intended | ||
cfa | specification-wise, isn't it the case that any compiler that passes the test suite is spec-compliant? | 18:07 | |
ugexe | there was a time that zef ran on parrot, moarvm, and jvm (and maybe even niecza) | ||
so the dream technically was alive at one point | |||
cfa | i | 18:08 | |
(also, i'm not sure what "doesn't seem legitimate" means) | |||
infeasible, perhaps? | |||
Nemokosch | cfa: what I mean is that a lot of what we usually just consider "the language", is actually not specified - I guess because that would put a lot of burden to a possible other implementation, pressure onto it to be like Rakudo | 18:09 | |
a massive example is the metamodel | |||
cfa | yeah, good point | ||
i remember controversy at documenting some of the *HOW stuff on the doc site | |||
lucs | Which Discord channel would be appropriate to suggest an IRC-bridge improvement? | 18:10 | |
Nemokosch | #meta probably | ||
lucs | Okay, I'll go there. | ||
Nemokosch | back to metamodel business - ... but to give up on actually using the metamodel to any extent, seems like a huge cost | ||
18:11
sena_kun left
|
|||
a lot of things that you could do easily, "by writing Raku code", would suddenly become unavailable | 18:11 | ||
another itch that I keep getting back to is the versioning. Right now, there is no precedent of handling bigger changes - although it seems at least mainstream to think that some breaking changes would be beneficial at the right time and in the right form | 18:12 | ||
cfa | i mean, there's a difference between leveraging implementation-specific details and calling an established api | 18:13 | |
18:13
freeside joined
|
|||
Nemokosch | then we can say that there is no "established api" at the moment, and I don't know what cost it would take and who would be willing to work it out | 18:13 | |
ugexe | using features that were just implemented are usually a bad idea anyway. they need to be baked into a few releases so e.g. apt-get users using a rakudo thats only like a year old don't have a terrible experience | 18:14 | |
in a distribution other people will use at least | 18:15 | ||
for programs that aren't distributed knock yourself out | |||
Nemokosch | That's also a point | 18:16 | |
At the same time, it's good to feel that there is continuous development in the most literal sense of the word, and perhaps find ways to show it, too. | 18:17 | ||
18:18
freeside left
|
|||
ugexe | i'm trying to think of a feature that a program like zef would be better off using immediately | 18:18 | |
cfa | hmm, how do distributions like debian treat rakudo versioning? | ||
and are dated bugfix releases still made? | |||
like would there be a 2022.12.3? | |||
ugexe | i imagine i'd probably just implement that feature in zef until that feature is in a few rakudo releases | ||
Nemokosch | I guess that's again the cost of "CoreHackers" pretending to be users, like myself. For me, a 2 years old Rakudo compiler is unusable, not even because of missing features but mainly because of all the bugs that I'm aware of and would step on. | ||
ugexe | the p6c ecosystem gets generated by a pretty old rakudo | 18:19 | |
Nemokosch | When I need to get something used by others for company, I'd tell them to get rakubrew by running like 2 commands in the command line, and come straight to the "bleeding edge" | 18:20 | |
ugexe | for a regular user i dont think old rakudos are that much of a show stopper other than when they try to use modules that don't work on old versions | ||
cfa | or when they run into a bug that was that was fixed in a later release | ||
18:20
jpn joined
|
|||
ugexe | i mean bugs still get introduced in new versions as well | 18:21 | |
cfa | sure -- but that might be a 'show stopper' scenario | ||
ugexe | but what i mean is i almost never hit rakudo bugs when i'm writing programs | ||
Nemokosch | yes, fair enough - and this is where the bias kicks in. If you know the old bugs, you are probably much more sensitive to that | ||
ugexe | only when im writing modules or doing core development | ||
cfa | i've run into quite a few | ||
Nemokosch | because you might remember them being fixed | ||
or how much you were bothered by them | 18:22 | ||
Rog | Yes, I would definitely like some consistency and some way to handle moderation across the “divide” so to speak | ||
cfa | i suppose the sensible response hereis a good test suite, plus rakubrew to test against a reasonable set of older versions | ||
Nemokosch | For Roast, I think it's just not what it claims to be. It's a semi-decent test suite for Rakudo, as things stand | 18:23 | |
cfa | why semi-decent, and what's missing? | ||
Nemokosch | Remember the bug with lists of custom-key hashes? | 18:24 | |
cfa | you mean the hash bug i reported? | ||
Nemokosch | yep | ||
cfa | yeah | ||
Nemokosch | That's just one handy example but bugs like that happen quite often. That was a regression that nobody noticed for seven years | 18:25 | |
I added like two tests for it but one can quickly think of cases that still aren't covered | |||
cfa | sounds like a great initiative | 18:26 | |
Nemokosch | well I'm planning to return to the whole "storing (and storing into) different Maps" topic, just didn't want to jump into it right now | 18:27 | |
rf | The only bug in Rakudo I ever hit is the `our %map is Map;` bug | ||
cfa | i meant spending time adding tests if you can think of cases that aren't covered already | ||
perhaps not as glamorous as other core development but surely very important | |||
Nemokosch | so yes - I'd say that's the easier part. To make Roast a decent Rakudo test suite 😛 | 18:28 | |
cfa | oh huh, github.com/rakudo/rakudo/issues/2753 is still causing a panic | 18:29 | |
18:29
QhpAptyj9hj0RQwM left
|
|||
cfa | Nemokosch: saying it's not 'decent' strikes me as dismissive but sure, being able to catch regressions early is always good | 18:30 | |
tellable6 | cfa, I'll pass your message to Nemokosch | ||
Nemokosch | What word would you fancy to express the idea that it's not as good as it should be? | ||
cfa | to make a more comprehensive suite, i guess? | 18:31 | |
Nemokosch | Okay, so - to make Roast an actually comprehensive Rakudo test suite seems to be the easier part. | ||
Rog | lizmat - Discord owner here: as far as how I want to handle moderation concerns in the future, I have two goals | 18:32 | |
Nemokosch | To make it a generic language specification that provides one a usable interface and followable, consistent features tied to language versions, regardless of the internals of a compiler - that would be much harder. | ||
Rog | 1. Shutting down the bridge entirely should no longer be (or need to be) our first course of action, and it sounds like we are moving toward that which is good | 18:33 | |
2. We need some channel of communication between moderators on either side and some standards on how to handle situations where there is inappropriate behavior spotted by someone who has no power on the “other side” | 18:34 | ||
lizmat | agree on 1 and 2 | 18:35 | |
Rog | On our end we essentially have a team of two, one of whom is me, and I have quite a bit going on atm | ||
Zephyr is doing an excellent job thankfully but maybe we need one more person in my time zone for coverage. idk, will figure that out later | 18:36 | ||
As for this situation in particular, I have only had time to glance through the relevant discussion, but my impression is that everybody has the same ultimate goal of making Raku a success, but the desire to be argumentative if creating division where there need not be any | 18:38 | ||
18:38
freeside joined
|
|||
s/if/is/ | 18:38 | ||
lizmat | Rog indeed | ||
indeed : some of the users describe interactions as ranging from "everything is a fight" to "toxic" :-( | 18:39 | ||
Rog | My expectation here is that we drop the negative tone and always assume the best of other people rather than jumping to snark or attacks | 18:40 | |
lizmat | whereas there's never a mention of malicious intent to harm Raku | ||
Nemokosch | by the way: Daniel Sockwell texted me yesterday and hopefully you received my mail, too | ||
seemed like the intention was to have a discussion in the upcoming days | |||
lizmat | Rog I hope so | 18:41 | |
Nemokosch indeed | |||
Rog | I will try to stay more active over the coming weeks and get a bead on how things feel | 18:45 | |
Nemokosch | Just sticking to the tighter events of the last couple of days, that consists of multiple topics, ranging from my personal contribution to the relations within the active part of the community and better targeting the right messages to the right audience overall | 18:46 | |
18:47
freeside left
|
|||
lizmat | Rog thanks! | 18:48 | |
18:49
freeside joined
18:50
swaggboi joined
|
|||
cfa | uh, sorry if i prompted that | 18:51 | |
18:53
freeside left
|
|||
Nemokosch | I don't think so; it's just these things kinda look different on Discord. | 18:59 | |
I don't think replies are attached in any shape or form | |||
19:02
jpn left,
sena_kun joined
19:09
pingu left
19:11
derpydoo joined
19:25
jpn joined
19:34
freeside joined
19:39
freeside left
|
|||
[Coke] | on windows, I have $dir = "C:\...", and can do `dd dir $dir.IO` and get a subfolder. if I add that subfolder to the path, I can get True on .IO.e, .IO.d, but if I dd dir $dir.IO, I get an error reading the dirhandle. | 20:29 | |
gfldex | [Coke]: is .resolve or .absolute changing the behaviour? | 20:31 | |
20:32
jpn left
|
|||
[Coke] | gfldex: just tested: nope. | 20:34 | |
20:34
freeside joined
|
|||
[Coke] | before invoking dir and failing, the path name is 258 chars. | 20:35 | |
gfldex | [Coke]: there used to be filemon from sysinternals that would should the error as reported by the win32 API. Sadly, I can't remember to what they renamed that tool. | 20:36 | |
the limit is 260 characters. Unclear if that is really characters or bytes. | 20:37 | ||
[Coke] | I'm guessing this is related to the long filename issue (but the file in that directory *exists*, and I can cd there in git bash and look at it.) | ||
gfldex | ohh, the volume is not included | ||
so you are beyond the limit | |||
see: learn.microsoft.com/en-us/windows/...limitation | |||
20:39
freeside left
|
|||
[Coke] | ok, so if I update the registry this might work. | 20:40 | |
gfldex | Frankly, if you got the problem, you are very likely heading for another cliff. | ||
Have you considered to use a proper OS? :-> | 20:41 | ||
20:45
jpn joined
|
|||
gfldex | [Coke]: I believe the proper way of dealing with this is to avoid absolut paths. | 20:46 | |
ugexe | Thing is, libuv uses UNC paths which isn’t beholden to that rule | 20:48 | |
so I dunno why it this length issue occurs in the first place | |||
[Coke] | my path explicitly has a C:\ in it, if that matters. | ||
(well, this test file. the original was relative, I think) | 20:49 | ||
I updated the registry, rebooted, the error is still occuring. | |||
the page you linked says we also have to update the "application manifest", but I don't think we have one of those for rakudo. :|\ | 20:50 | ||
ugexe | github.com/libuv/libuv/issues/2331 For example | 20:51 | |
I wonder if we use a non libuv file op somewhere | |||
[Coke] | Looks like MVM_dir_open is not using libuv on windows? | 20:56 | |
ugexe | Nice, can you link it? I’m on my phone | 20:57 | |
[Coke] | github.com/MoarVM/MoarVM/blob/mast...ops.c#L217 | ||
in fact, it looks like non windows is just calling "opendir", not anything in libuv. | 20:58 | ||
looks like nine wrote most of that in 2019. | 20:59 | ||
ugexe | yeah I think replacing that with whatever the libuv variant is might solve the path length issue | 21:04 | |
21:05
jpn left
21:06
cfa left
21:08
swaggboi left
|
|||
ugexe | hmm maybe thats not it either though. `raku -e "my $path = q|a| x 400; say $path.IO.open(:create)"` fails with no such file | 21:13 | |
if i s/400/40/ it works | |||
github.com/MoarVM/MoarVM/blob/34ba...rops.c#L71 this function looks like it might need to remove the MAX_PATH check and just always run the logic | 21:19 | ||
i wish i had an easy way to get a stack trace on windows... or how even :P | 21:20 | ||
knew how^ | |||
[Coke]: do you get the same error with that one liner i posted? and have you done the supposed enabling of long paths in the windows registry or whatever? | 21:27 | ||
my vmware trial ends in 3 days :( | 21:28 | ||
[Coke] | ugexe: your oneliner: No such file or directory | 21:36 | |
(works with 40) | |||
I did update the registry and rebooted | |||
I can probably setup an azure VM and get folks access, but I don't recall what version of windows you can get with that. | 21:37 | ||
MAX_PATH is also checked in mkdir | 21:39 | ||
ugexe | same with MVM_dir_cwd | 21:43 | |
[Coke] | I'll try a build that just removes that check and see if it explodes. | 21:44 | |
(and put the registry back and see how it explodes there.) | |||
ugexe | thing is the one-liner i posted shouldnt use mkdir | 21:45 | |
it just creates a file in the current directory | |||
so while reading a directory might be the cause, creating one would seem unlikely (at least in the case of the one liner) | |||
the good news is updating moarvm to use new libuv uv_ ops is pretty easy and one can basically just look at a PR for any of the existing ops | 21:46 | ||
usually just writing a small wrapper around the function | |||
they also don't need a windows machine to do it | 21:47 | ||
[Coke] | OK. that's probably better than trying to half-rip out MAX_PATH. | 21:53 | |
ugexe: added github.com/MoarVM/MoarVM/issues/1743 | 22:02 | ||
22:08
evalable6 left,
linkable6 left,
evalable6 joined
22:11
linkable6 joined
22:14
ab5tract left
22:29
QhpAptyj9hj0RQwM joined
22:30
NemokoschKiwi joined
22:34
QhpAptyj9hj0RQwM left
|
|||
ugexe | so my golf is a bit misguided in a way | 22:43 | |
22:44
sena_kun left
|
|||
ugexe | `raku -e 'my $path = q|a| x 255; say $path.IO.mkdir'` # works, even though im inside a directory thats like 30 characters long already | 22:44 | |
`raku -e 'my $path = q|a| x 256; say $path.IO.mkdir'` # mkdir error 123 | |||
i mention this because even with long path names enabled, each directory part / file name is limited to 255 | |||
thing is while the precomp errors on windows suggest path length issues, they aren't creating single path parts that are that long | 22:45 | ||
the above examples i ran with long path support enabeld in windows registry | 22:46 | ||
something like a rakudo-gdb-m dump would be pretty valuable | 22:48 | ||
it seems like when i try to create a file it takes the entire path length into consideration, not each path part individually | 22:56 | ||
22:59
NemokoschKiwi left
23:07
swaggboi joined
23:35
freeside joined
23:39
freeside left
23:40
jgaz joined
|