🦋 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.
00:00 Manifest0 left, reportable6 left 00:03 reportable6 joined
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
00:36 rf joined 00:54 vrurg_ joined, vrurg left 00:56 saint- left 01:29 derpydoo joined
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
02:17 tea3po joined
tonyo wonder if that could be used to pickle 02:18
02:20 teatwo left
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
03:12 gkqha joined, gkqha left 03:37 rf left 04:37 linkable6 left, reportable6 left, evalable6 left, quotable6 left, nativecallable6 left, bisectable6 left, sourceable6 left, greppable6 left, coverable6 left, statisfiable6 left, notable6 left, releasable6 left, shareable6 left, benchable6 left, evalable6 joined, sourceable6 joined, benchable6 joined, quotable6 joined, shareable6 joined 04:38 coverable6 joined, nativecallable6 joined, greppable6 joined, statisfiable6 joined, reportable6 joined, linkable6 joined 04:39 releasable6 joined, bisectable6 joined, notable6 joined 04:42 zara joined 04:57 zara left 05:09 zara joined 05:20 zara left 05:45 Sauvin left 05:51 zara joined 05:55 Sauvin joined 06:00 reportable6 left 06:02 reportable6 joined 06:04 zara left
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
06:51 abraxxa joined 06:53 abraxxa left, sena_kun joined 07:03 abraxxa joined 07:36 Manifest0 joined 07:40 zara joined 08:11 zara left 08:19 jpn joined 08:36 jpn left 08:40 Sgeo left 09:25 jpn joined 09:27 abraxxa1 joined, abraxxa left 10:31 jpn left 10:41 derpydoo left
lizmat clickbaits rakudoweekly.blog/2023/05/15/2023-20-so-survey/ 10:42
sjn clicks 10:47
10:56 andinus left 11:08 jpn joined 11:44 jpn left 12:00 reportable6 left 12:02 reportable6 joined
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
12:08 dakkar joined
uzl[m] BTW 34 questions short of 2000 questions on SO! 12:08
12:15 jpn joined
tbrowder__ uzl[m]: i emailed Briggs about it. we'll see if i get a response. 12:50
13:05 jpn left 13:06 jpn joined 13:09 squashable6 left 13:11 squashable6 joined
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
13:27 squashable6 left
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
13:29 squashable6 joined
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
13:35 jgaz left
tbrowder__ lizmat: i can't find the RakuAST =tble 14:13
=table code. what reopo and branch, pls 14:14
14:18 tea3po left, tea3po joined
lizmat tbrowder_: main branch, src/core.c/RakuAST/Fixups.pm6 14:29
14:30 Sgeo joined
lizmat method interpret-as-table 14:32
tbrowder__ got it, thnx! 14:40
14:52 teatwo joined 14:53 teatime joined
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
14:55 tea3po left
lizmat could you gist an example ? 14:55
14:56 teatwo left
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
15:13 gabiruh left 15:19 gabiruh joined 15:25 zara joined
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
15:28 zara left
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
16:03 jpn left
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
16:09 cm_ joined 16:10 cm left, cm_ is now known as cm 16:12 abraxxa1 left 16:41 dakkar left 17:41 linkable6 left, evalable6 left, linkable6 joined 17:43 evalable6 joined 17:58 jpn joined 18:00 reportable6 left 18:02 reportable6 joined 18:03 jpn left 18:15 MasterDuke joined 18:52 jpn joined 18:59 jpn left
leont avuserow: seems we're both writing an SQL abstraction :-) 19:07
19:15 rf joined
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
19:51 vrurg_ is now known as vrurg
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
20:07 jpn joined
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
20:18 jpn left
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
20:46 sena_kun left
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
20:52 rf left, jpn joined, rf joined 20:56 rf left
tonyo sqla seems to have more than the normal amount of warts 20:56
20:58 jpn left 21:58 squashable6 left, evalable6 left, linkable6 left, notable6 left, benchable6 left, releasable6 left, greppable6 left, quotable6 left, sourceable6 left, coverable6 left, bisectable6 left, nativecallable6 left, reportable6 left, statisfiable6 left, shareable6 left, bloatable6 left, unicodable6 left, committable6 left, tellable6 left, nativecallable6 joined, greppable6 joined 21:59 bloatable6 joined, tellable6 joined, committable6 joined, statisfiable6 joined, coverable6 joined 22:00 quotable6 joined, bisectable6 joined, notable6 joined, unicodable6 joined, benchable6 joined 22:01 releasable6 joined, squashable6 joined, linkable6 joined, shareable6 joined, evalable6 joined, reportable6 joined, sourceable6 joined 22:09 jpn joined
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
22:19 jpn left 22:28 gfldex left
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
23:04 jpn joined 23:08 jpn left
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 :')
23:21 rf joined 23:35 gfldex joined 23:58 jpn joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!