|
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 | ||