🦋 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. |
|||
01:00
Riviera left
01:39
hulk joined
01:40
kylese left
01:44
Sevalecan left,
Sevalecan joined
|
|||
tbrowder | antononcube: thnx for the reminder of lizmat's review of new stuff | 02:05 | |
02:15
hulk left,
kylese joined
|
|||
SmokeMachine | does anyone here uses nvim + telescope? I'm playing with it to create a plugin for Rak, is anyone interested? usercontent.irccloud-cdn.com/file/....54.41.gif | 02:58 | |
stanrifkin_ | SmokeMachine: What is telescope? | 02:59 | |
SmokeMachine | telescope is a fuzyfinder for neovim... it's highly plugabble... | 03:00 | |
(on my gif, that's that panel that opens to let me search using rak) | 03:01 | ||
stanrifkin_: ^^ | |||
stanrifkin_: github.com/nvim-telescope/telescope.nvim | 03:02 | ||
Xliff | I have most of the bindings for GLib::Top ready to go. Hope to release in the next week or two: developer-old.gnome.org/libgtop/stable/ | 03:19 | |
So obtaining information from /proc in a usable manner is near! | |||
03:34
stanrifkin joined
03:36
stanrifkin_ left
05:12
ponycat left
05:29
kylese left
05:34
kylese joined
06:00
Sgeo left
|
|||
Geth | docker: sorairolake++ created pull request #62: Add CI status badge |
06:00 | |
docker: 0dc0527914 | (Shun Sakai)++ (committed using GitHub Web editor) | README.md Add CI status badge |
06:20 | ||
docker: dbc5eef911 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | README.md Merge pull request #62 from sorairolake/add-badge Add CI status badge |
|||
06:25
corwin is now known as catwin
07:04
kst left
07:48
sena_kun joined
08:40
ptc joined
09:32
jpn joined
|
|||
Geth | ecosystem/main: aeb3205dae | (Elizabeth Mattijsen)++ | META.list MoarVM::Remote now lives in zef ecosystem |
09:48 | |
patrickb | lizmat: Thanks for tackling MoarVM::Remote. Very appreciated. | 09:59 | |
lizmat | it actually needs more TLC | 10:00 | |
I had to disable one test to be able to upload | |||
I also feel that Data::MessagePack could use some updating | 10:01 | ||
10:28
jpn left
10:32
jpn joined
|
|||
Tirifto | m: role R is Int { ; }; role S is Int { ; }; class C does R does S { ; }; | 11:12 | |
camelia | ===SORRY!=== Error while compiling <tmp> Package '<anon|1' already has parent 'Int' at <tmp>:1 |
||
Tirifto | ↑ Is it a good thing that this fails? Intuitively, I’d expect that to be okay, since both roles want the new class to inherit from the same class. :o | 11:14 | |
At least my reading of this hierarchy isn’t that the author wants to inherit from the same class twice (which is odd and sensibly fails), but that the author wants to mix in two roles, both of which want to add the same class to the inheritance. So there’s a duplicate requirement from two separate roles, which could be met by only inheriting once, thereby avoiding the error. | 11:27 | ||
ab5tract | Tirifto: That's a reasonable take. However the roles are already composed before they are being used for C | 11:29 | |
*with C | 11:30 | ||
which allows them to use / override methods and attributes from the Int class in their definitions | 11:32 | ||
without this composition, they can't be compiled as such roles (usually) refer to things not within their core definition | 11:39 | ||
Tirifto | ab5tract, how can I imagine a role being ‘composed’ before being used with a class? Since the documentation says the role’s methods are copied into the class, I imagined that mixing in a class was (conceptually) much like writing its body into the body of the class (without overwriting anything) and adding the carried classes to the chain of inheritance. `o` | 11:40 | |
ab5tract | Yeah, I see what you mean | 11:46 | |
11:46
amenonsen left,
amenonsen joined
|
|||
ab5tract | Tirifto: I've done a quick search of open issues that would match this and haven't found one. | 11:56 | |
Would you mind creating one? | 11:57 | ||
lizmat | I guess the reason for not allowing this, is that that the order of composing roles with already existing parents, could create some unexpected method lookup efffects | 12:01 | |
in this simple example it wouldn't | |||
12:08
jpn left
|
|||
Tirifto | ab5tract, I wouldn’t in theory, but I am not in possession of a GitHub account; are there alternative ways of submitting reports? :o | 12:09 | |
lizmat | Tirifto: do you have reasons for not wanting to have a Github account? | 12:10 | |
just OOC | |||
ab5tract | Tirifto: No worries. I'll take care of it | ||
tbrowder | hi, i'm try file open with other line endings. but there seems to be a newline at the very end when i read a single string from a file | 12:17 | |
my file looks like this: | 12:18 | ||
name, age || go, 32 | 12:19 | ||
i cannot see the newline at the end | 12:20 | ||
i open the file for reading like this: my $fh = open $f, :nl-in("||"); | 12:22 | ||
for $fh.lines ... | |||
afk& | |||
Tirifto | lizmat, mostly various ethical concerns, such as requiring the use of non-libre software, licence violations, being owned by a notoriously user-hostile company, etc. | 12:27 | |
lizmat | gotcha | ||
Tirifto | ab5tract, once again, thank you very much! | ||
12:30
MasterDuke left
12:38
jpn joined
|
|||
tbrowder | i guess i can strip any trailing newlines without interfering with interior newlines | 13:08 | |
lizmat | without more code and/or the input file in a gist, it's hard to guess what's going on, tbrowder | 13:11 | |
tbrowder | ok, i think i have it. i'll gist it in a bit | 13:21 | |
i'm trying to make my little csv module very powerful as you and [Coke] would like. one issue though is a real test file with embedded newlines. | 13:22 | ||
lizmat | tbrowder: there is already a very powerful Text::CSV: I was merely pointing out potential issues in the "simple" approach | 13:23 | |
tbrowder | i have one (i'll show in the gist). but trying to visualize how the final product looks. | ||
lizmat | as long as everybody is on the same page wrt to known issues with an implementation, we should be ok | ||
tbrowder | yes, but the difference in mine is it's a final table (on top of my own parser). the file is read entirely before the user gets it | 13:25 | |
obviously not able to handle huge files | 13:26 | ||
and the input file may have comment lines | |||
which are removed on read and the "raw" csv file can be saves to use in libreoffice or excell | 13:27 | ||
*excel | 13:28 | ||
of course my motivation is to use it in another module 😄 | 13:30 | ||
aha, i'll create a test file in excel and output to csv (he said while slapping forehead) | 13:32 | ||
15:54
haxxelotto_ joined
15:57
haxxelotto_ left
|
|||
ugexe | ptc: in your building and testing in raku blogpost you mention not installing the distribution being tested, but actually you *should* install it as that will precompile everything (catching any compile time errors that might not have been exercised by the test suite) as well as ensuring that the META6.json is listing all the provides/modules it should | 16:36 | |
i've seen these type of errors from various developers that would have been caught by installing instead of just running the tests tens of times | 16:39 | ||
additionally one should just use `zef install .` (i.e. let the install workflow also run the tests) instead of `zef test . && zef install .` (i.e. run the tests and install as seperate workflows) as the former will only precompile things once, whereas the later precompiles twice | 16:41 | ||
additionally additionally, you should almost always use `-I.` (i.e. -I $path-to-directory-containing-META6) and not `-Ilib`, since the later doesn't use META6.json and thus isn't equivalent to what the installed version might be. For example if you fail to list a module in META6.json it would fail very obviously with -I., whereas -Ilib guesses what files should be included based on the files it sees | 16:44 | ||
17:05
teatwo left,
teatwo joined
17:06
jpn left
|
|||
ptc | ugexe: ok, good to know. I thought one explicitly *doesn't* want to install a dist's modules because then if one changes the code, how does one know that one is testing the right code? I've definitely had the situation in the past where the installed code was being found first and any changes I made weren't having any effect. | 17:07 | |
good point about -I though; I didn't know about that effect. Thanks! | 17:09 | ||
I wonder if there's a workflow whereby one tests such compile time and META6.json errors as a pre-release check. It'd also be necessary to uninstall the dist afterwards too, I think, in case one doesn't want to have it installed locally. | 17:12 | ||
17:46
vlad joined
19:10
vlad left
19:11
ptc left
|
|||
ugexe | fro CI tests at least you wouldn't worry about having leftover installed code | 19:14 | |
but you can also just install it into some temporary directory | 19:15 | ||
--install-to=/tmp/whatever | |||
for quickly testing and iterating locallym using `zef test .` or `prove -I. t/` is fine. you would want to do a test install at some point though, likely before pushing any changes | 19:17 | ||
however, I wouldn't recommend using --install-to= when CI tests, because that prevents the use of the staging repository and thus precompilation will occur twice (once during tests, once during install) | 19:18 | ||
21:08
antononcube joined
21:22
antononcube left,
antononcube joined
|
|||
librasteve | I have started to go zef install . in my workflow ... it was a bit of a gear change, but I agree that it is the best approach (I use --force --/test so that I can run the test manually when I want (since that can take a while) and to avoid having to uninstall (except the last time ;-) | 21:39 | |
21:59
Sgeo joined
22:17
antononcube left
22:28
sena_kun left
22:30
MasterDuke joined
22:34
stanrifkin left
|
|||
tbrowder | i do the same as librasteve, works great and i can always fall back to the published module if need be | 22:54 |