01:00 Kaiepi left 02:01 frost joined 02:38 Kaiepi joined 03:33 Guest35 left 04:57 Kaiepi left 06:04 Oshawott joined 06:08 archenoth left 09:01 Kaiepi joined 09:06 Kaiepi left 09:11 Kaiepi joined 09:47 razetime joined 13:35 razetime left 13:41 frost left 13:47 razetime joined 13:48 razetime left 14:02 Guest35 joined 14:56 CIAvash left 14:57 CIAvash joined 15:26 Kaiepi left 16:06 Kaiepi joined
Anton Antonov I based some functionalities of my package Data::Reshapers on Pretty::Table, and because of that Data::Reshapers has installation failures. It seems that the package Pretty::Table is not maintained since February 2020. In order to be able to use Pretty::Table I install it from GitLab (not via zef.) See : gitlab.com/uzluisf/raku-pretty-table . 17:19
What is the best approach to address the failures because of Pretty::Table?
1) I can replace Pretty::Table in Data::Reshapers with a more maintained package.
2) I can duplicate the tabulation functionalities in some way in Data::Reshapers.
3) Someone has to re-own Pretty::Table. (I am willing to do it, but I am not sure how...)
I based some functionalities of my package Data::Reshapers on Pretty::Table, and because of that Data::Reshapers has installation failures. It seems that the package Pretty::Table is not maintained since February 2020. In order to be able to use Pretty::Table I install it from GitLab (not via zef.) See : gitlab.com/uzluisf/raku-pretty-table .
What is the best approach to address the failures because of Pretty::Table?
1) I can replace Pretty::Table in Data::Reshapers with a more maintained package.
2) I can duplicate the tabulation functionalities in some way in Data::Reshapers.
3) Someone has to re-own Pretty::Table. (I am willing to do it, but I am not sure how...)
17:56 Kaiepi left 17:57 Kaiepi joined 18:18 Kaiepi left 18:19 Kaiepi joined
piotrklibert I think that depends on how much of the functionality of Pretty::Table Data::Reshapers actually make use of, and especially in the code paths that you're interested in. Writing a simple table formatting code is not hard, as long as you're fine with occasional edge cases you forgot to handle. Actually, I'm currently working on a post about it, but I took writing a tabular data formatter was my fir 18:49
I think that depends on how much of the functionality of Pretty::Table Data::Reshapers actually make use of, and especially in the code paths that you're interested in. Writing a simple table formatting code is not hard, as long as you're fine with occasional edge cases you forgot to handle. Actually, I'm currently working on a post about it, but I took writing a tabular data formatter as my firs 18:51
<@297037173541175296> thanks, that explained the behavior. I
<@297037173541175296> thanks, that explained the behavior.
<@297037173541175296> thanks, that explained the behavior I was observing.
One more question, about "turtles all the way down" what are these things: 19:06
m: 1.HOW.HOW.^methods.map(-> $a { say $a.key, $a.value }, :kv)[^3]
and how to introspect them? Which docs should I read?
m: 1.HOW.HOW.^methods.map(-> $a { say $a.key, $a.value }, :kv)[^3]
One more question, about "turtles all the way down" what are these things below and how to introspect them? Which docs should I read? 19:08
m: 1.HOW.HOW.^methods.sort(*.key)[^10].map(*.say) 19:20
(slightly better formatting this time, hopefully)
Morfent m: 1.HOW.HOW.^methods.sort(.key)[^10].map(.name.say) 19:30
m: 1.HOW.HOW.^methods.sort(*.key)[^10].map(*.name.say) 19:31
m: 1.HOW.HOW.^methods.sort(*.key)[^10].map(*.value.name.say)
there we go
m: 1.HOW.HOW.^methods.head.value.^name.say 19:33
m: 1.HOW.^methods.map(*.name).sort 19:37
m: 1.HOW.^methods.map(*.name).sort.say
the reason i pull up `name` there is `methods` is a hash on more nqp-ish HOWs, but a list on the more raku-ish ones 19:39
in which case you want `method_table` for a hash
the reason i pull up `name` there is `methods` is a hash on more nqp-ish HOWs, but a list of code objects alone on the more raku-ish ones 19:41
in which case you'd want `method_table` for a hash
the raku ones are described primarily by docs.raku.org/type/Metamodel::MethodContainer 19:47
as for the code itself, it *can* be a `ForeignCode` on core types, but those are typically bootstrapped, and are more likely to be a `Method` of some sort instead 19:53
piotrklibert I mean the "more nqp-ish HOWs" - I know those on Raku side 🙂 Where is `(low-level object NQPClassHOW)` implemented? Also, with normal `Method`s I can see their signatures, right? Like this: 20:14
m: 1.^methods.map({ :{(.name) => .signature.raku} }).sort(*.key)[^5].join("\n")
m: 1.^methods.map({ :{(.name) => .signature.raku} }).sort(*.key)[^5].join("\n").say
What can I do with the objects of 'ForeignCode' type?
(other than calling them, ofc 🙂 ) 20:15
Morfent you can get a `name` and `signature`-related properties mainly 20:23
piotrklibert I tried, some of them say they're `<anon>` 😦 20:24
I tried, some of them say they're `<anon>` 😢
Morfent for those, you need their key as known by their HOW
for those, you need their key as known by the HOW they belong to 20:25
not sure why those couldn't depend on `anon` though. i think nqp supports that? 20:28
that would let them have their name
piotrklibert Hm, I tried to search for `NQPClassHOW` in both rakudo and moarvm github repos, but got zero hits in both? Where could this be defined, then? 20:30
Morfent it's in nqp's `src/how` somewhere
piotrklibert Ah, `nqp`! I forgot it's in a separate repo. Sorry! Found them 🙂 20:31
github.com/Raku/nqp/blob/56aded28e...OW.nqp#L23 20:32