🦋 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.
tbrowder__ y 00:05
*yes, something like that. might ask that author if he would do one for raku and give him some serious "free" help to aid the Raku Foundation 00:07
or his helpers (hint-hint jj) 00:08
avuserow uzl[m]: many years ago, I wrote Binary::Structured for parsing binary data. No idea if it still works, but your code reminds me of this in spirit: raku.land/github:avuserow/Binary::Structured 01:41
looks like I didn't add many examples, but I was able to use it to parse (and then modify and serialize) a bunch of fairly complex data from a video game 01:44
I remember wanting to use it to make an (inefficient) parser for .zip or .tar files, but never got around to it
Voldenet fwiw just chedked, it still works 01:46
tonyo avuserow: there's a TAR parser in fez 02:14
(in pure raku) 02:15
avuserow sure, and the point wasn't to create a good tar parser implementation, but rather to provide an in-depth example of parsing a real-world format with Binary::Structured (and to validate the module's use for a real format) 02:16
tonyo wonder if that could be used to pickle 02:18
avuserow maybe? do you mean python's pickle format or something else? 02:21
tonyo rf: not seeing anything in 2.1.5 showing all the qs kvs 02:22
disregard, missed the key being optional now 02:23
does anyone have a mailgun module underway? 02:32
rf How is mail gun, I've never used it
tonyo++ for all the Humming-Bird input, really appreciate it 02:36
tonyo seems to be doing fine and they let me use it free for fez's stuff 02:37
at least if i stay under 10k emails
rf Neat 02:41
tonyo the query thing threw me off because the other ones (cookies, headers, params) have the plural version to retrieve the hash
rf Yeah haha, I wasn't sure if I wanted to rename it... 02:42
Maybe queries is better?
But in the end it's still one query... so i'm not sure
tonyo yea, but that might be confusing in another way..i'd probably do it
or param -> path and query -> param 02:43
rf I'll do queries for now 02:45
patrickb rf: Given hb is meant to be used with a reverse proxy exclusively it might make sense to think about a fcgi backend in the longer run. 06:06
tellable6 patrickb, I'll pass your message to rf
lizmat clickbaits rakudoweekly.blog/2023/05/15/2023-20-so-survey/ 10:42
sjn clicks 10:47
uzl[m] avuserow: Thanks, I've skimmed it and it looks interesting! Once I'm done with the baby DBF parsing I'm currently doing, I might give your module a shot to do the same thing. It seems it might benefit from an overhaul, namely extension pm6 -> raku. I'll look at the TODO and check if there's a low-hanging fruit I can grab 12:04
tbrowder__: "Raku for Kids" by Jason R. Briggs and JJ Merelo. It has a nice rhyme to ;) 12:05
uzl[m] BTW 34 questions short of 2000 questions on SO! 12:08
tbrowder__ uzl[m]: i emailed Briggs about it. we'll see if i get a response. 12:50
Anton Antonov @avuserow Yes, please, document more! 🙂 13:14
<rant>Usually, writing an useful documentation takes me 2-3+ times longer than writing package’s code. Nevertheless, a package without documentation is simply uselesss.</rant> 13:17
avuserow Yeah, documentation is important but time consuming. And I don't even know if my documentation is useful 🙃 13:25
For Binary::Structured, the main modernization would be to use the Blob.read-uint32 and Buf.write-uint32 style methods instead of pack/unpack. The module seems to work fine otherwise 13:26
The big question is if the model overall makes sense and is maintainable. I don't have any current use for this module so it's hard for me to explore this design further 13:28
I do want to actually get my main project to be public at some point since it's an actual application, but Binary::Structured does not fit into that project. 13:30
tbrowder__ lizmat: i can't find the RakuAST =tble 14:13
=table code. what reopo and branch, pls 14:14
lizmat tbrowder_: main branch, src/core.c/RakuAST/Fixups.pm6 14:29
lizmat method interpret-as-table 14:32
tbrowder__ got it, thnx! 14:40
tbrowder__ lizmat: since you're kind of reinventing pod, i would love to see a para type that indicates no more recursion is required. seems to me like that would ease parsing and handling text in writing pure rakudoc documents. 14:54
lizmat recursion with regards to parsing ?
tbrowder__ yes
lizmat could you gist an example ? 14:55
Voldenet btw, regarding Binary::Structured: if it could use kaitai format it would be incredibly useful (combined with formats.kaitai.io) 15:00
tbrowder__ yes, it'll take a while. but one of the probs for me is every para has to be searched for children before one can go back and do rendering calcs for things like indentation depth, table layout, etc. maybe it's just the linear way i tend to visualize docs. it's 15:02
easier if you are just producing lines of unlimited length. 15:04
avuserow Kaitai struct is very interesting but probably a separate project. Looks like it's a codegen style project which would be probably be faster. I do remember seeing this project back in 2016 but it was very young and I didn't like the verbosity. I was mostly inspired by the Python module construct 15:28
leont Reinventing POD? That reminds me I should write my blogpost about what direction we need to take POD (mainly the stuff I mentioned at last year's conference) 15:34
lizmat leont: so far, it's only the implementation of POD6 in RakuAST 15:43
but... with making rendering and maintenance of pod much easier
avuserow Oh right, kaitai struct doesn't support serialization, that was the issue. I was doing lots of load/edit/save workflows so it was not useful there
leont IMNSHO having POD as data instead of as comments isn't really useful until we make manipulating it easier as well. 15:46
lizmat well, in the RakuAST implementation, it only becomes data because of $=pod 15:47
it is now technically possible to parse a file for pod, and get a RakuAST tree, and use *that* for rendering *before* any bytecode is made 15:48
in a CHECK phaser
leont Yeah, that's progress
lizmat I should say: at CHECK stage, not in a CHECK phaser
but perhaps that could even work
leont Keeping that pod around when loading a module would be really useful as well
(as in, being able to get the POD of a loaded module) 15:49
lizmat you mean what is now in $=pod, or the RakuAST tree
leont $=pod, but accessible for other modules.
lizmat to get the RakuAST tree of a file, you'd basically go "file".IO.slurp.AST
leont E.g. that way I could implement a proper Pod::Usage. Right now I have to add additional function call to pass in $=pod for that compilation unit. 15:50
lizmat then walk the tree for all RakuAST::Doc::xxx objects
and render those
IMO the $=pod data structure loses too much information 15:51
leont It isn't much tree shaped, which makes filtering and manipulating it more difficult than it should be
E.g. github.com/Leont/pod-usage/blob/ma...akumod#L11
What I really want is just "give me all text under the USAGE heading", that should be easier than that. 15:52
But what I ultimately want is Pod::Weaver type functionality. That way one can insert all the boilerplate automatically when the pod is rendered, but doesn't have to think about it otherwise. 15:56
That's the sort of workflow where documentation-as-data really shines. 15:57
lizmat well, the RakuAST tree would even allow you to filter on location of the file, as the doc blocks are just part of the statement lists 16:04
leont avuserow: seems we're both writing an SQL abstraction :-) 19:07
rf Afternoon folks 19:16
tellable6 2023-05-16T06:06:40Z #raku <patrickb> rf: Given hb is meant to be used with a reverse proxy exclusively it might make sense to think about a fcgi backend in the longer run.
rf @patrickrb: Probably. I
'd have to familiarize myself with FCGI though
avuserow leont: yes. Perl 5's SQL::Abstract has been a tool in my belt for many years now, so that's an inspiration. I did give your SQL::Abstract a look in between iterations of my abstraction, and it looks pretty nice - though not exactly what I need :) 19:33
my previous attempt that was more inspired by SQL::Abstract is still online (github.com/avuserow/raku-sql-cantrip), though I will probably archive this eventually 19:36
leont If you're more of a direct SQL::Abstract user that makes sense. Ultimately my goal is more building something ORM-like on top of it 19:37
avuserow yeah, for some of my API endpoints, I'm using postgres to generate the json output directly, and sending that to my client. going from thousands of DB rows -> raku hashes -> JSON output was unfortunately too slow, so adding an ORM is a no-go 19:40
SmokeMachine leont: have you heard about Red?
leont SmokeMachine: yes, and it fundamentally can't do things I want it to do 19:41
rf Is red still WIP?
avuserow (with postgres generating the JSON, the client-side javascript is the next "too slow" part, so that's a good problem to have)
leont Primarily because it's too strictly an ORM.
Like, I do want to be able to do joins and stuff, and aggregation 19:42
SmokeMachine rf: yes, I still have a few issues to solve before realising the first stable version
rf Cool. Looking forward for it 19:43
leont (this is a problem almost all ORMs have, DBIx::Class and SQL::Alchemy are the only ones I know that are usable in that area)
SQLAlchemy, why did my fingers put colons there 19:44
rf I wish Perl, and Raku have something as extensive as JPA
s/have/had/
SmokeMachine rf: github.com/FCO/Red/projects/3
leont: what’s the way you want it to be done? 19:45
leont: what’s the way you want it to be done? 19:46
You can do joins and aggregations with Red… 19:48
leont: not only relationship joins but also custom joins: fco.github.io/Red/tutorials/cookbook.html (take a look at custom join topic) 19:51
leont Hmmm, last time I looked I don't think it had join-model yet (or maybe it just wasn't documented), but that sounds useful yes 19:59
leont Red feels to me like a tool designed for people who like the object side a lot more than the relational side. I'm genuinely impressed by the overloading magic that you use, but I'd personally like a bit less magic. 20:12
avuserow leont: SQL::Builder will gain some query execution capabilities (and it already has a prototype in my other project). It'll be intended to get rows (and single values) rather than objects. Think more SQLAlchemy Core instead of the SQLAlchemy ORM
leont avuserow: yeah, a good query generator is useful 20:13
SmokeMachine: basically, I think your audience exists, but it's not me :-) 20:15
The other thing I don't like in all existing systems is that they're synchronous, when async is one of Raku's biggest strengths. But that's largely caused by the database layers below. Also working on that :-) 20:16
tonyo datalog-esque would be a much more compelling style ORM 20:40
sqlalchemy has a lot of warts 20:41
leont All ORMs have warts, it comes with the tension of abstracting the difference between objects and relations 20:44
blog.codinghorror.com/object-relat...r-science/ 20:45
patrickb rf: I have a WIP fcgi cro backend at sr.ht/~patrickb/cro-fcgi/ it's mostly done. Maybe it can be an inspiration. 20:48
rf With tonyo's implementation of multiple backends we can look into it 20:49
tonyo sqla seems to have more than the normal amount of warts 20:56
guifa re Binary::Structured just a quick reminder I am working on creating a binary regex format 22:13
Just waiting a TINY BIT MORE with RakuAST to go back and work on it
avuserow guifa: best of luck, I'm really interested in that 22:36
that said, would those allow serialization too? that's most of the reason to use Binary::Structured vs kaitai struct (via FFI) 22:37
guifa avuserow: no, it wouldn't. It's parse focused (it's mostly but not entirely just a syntactical sugar ontop of regex) 22:38
avuserow though I don't think I'll find much time to do anything with Binary::Structured, aside from maybe answer some questions on what I was thinking way back then 22:40
uzl[m] tbrowder__: Awesome! Fingers crossed! 23:15
>a package without documentation is simply uselesss. 23:17
Worse than that, it's a package with outdated docs or docs that don't agree with the code :')

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!