| 19 Jun 2022 | |||
| japhb | Good idea | 18:48 | |
| You know, every time I see Rakudo's build message "Installed 20 core modules in 14.123456789 seconds!" I always think "There is no machine on which the timing of that operation could be nanosecond-exact." | 18:49 | ||
| lizmat | japhb: yeah, that could be better :-) | 19:03 | |
| it's just that the nano-second accuracy was added later :-) | |||
| japhb | :-) | 19:06 | |
| SmokeMachine | 👍 | 19:09 | |
| japhb | SmokeMachine: Everything built fine on Rakudo 2022.06-21-gd253dc79e | 19:41 | |
| Actually wait ... stuff I have locally checked out may not run tests. Let me force that. | |||
| Crap. Yep, Cro::CBOR throws an error. | 19:44 | ||
| Dang it. | |||
| Refreshed certs indeed fixes it. Looks like I need to update to current release standards too. | 19:51 | ||
| OK, new Cro::CBOR 0.0.4 released | 19:58 | ||
| SmokeMachine | Now the exceptions accept a reason... I'll remove the exception and try again just after passing the tests of this new commit (github.com/FCO/Red/commit/60016ea1...7d359830d) | 20:00 | |
| japhb | Sounds good | ||
| Bah. Anyone know how to deal with the MacOS "loading libcrypto in an unsafe way" failure on GHA? github.com/japhb/Cro-CBOR/runs/695...focus=true | 20:07 | ||
| SmokeMachine | japhb: github.com/FCO/Red/runs/6957413833...#step:6:34 | 20:10 | |
| japhb | Anyone know how to deal with the MacOS "loading libcrypto in an unsafe way" failure on GHA? github.com/japhb/Cro-CBOR/runs/695...e#step:7:5 | 20:24 | |
| Sorry, was trying to send to another channel | 20:25 | ||
| 6 Aug 2022 | |||
| leont | Question about the example in the README: in the .active-posts.grep example does that filtering client side or on the server? | 01:47 | |
| I assume the former, but if it's the latter I'm really curious how you did that | |||
| japhb | leont: One of the Red pieces of magic is that it essentially builds ASTs from simple greps and turns them into where clauses. Remember that .grep doesn't have to be the one provided by Raku. ;-) | 02:50 | |
| SmokeMachine | Not only for grep, but also map, first and etc… | 03:21 | |
| leont: that’s DB side. You can see the generated SQL just below that on README. | 03:23 | ||
| leont: this is what’s used to do that: github.com/FCO/Red/blob/master/lib...de.pm6#L56 | 03:25 | ||
| I plan to make it even more powerful with RakuAST once it’s done… | 03:26 | ||
| And here is the grep it uses: github.com/FCO/Red/blob/master/lib...q.pm6#L131 | 03:27 | ||
| leont | That sounds cool, but I'm not understanding it quite yet | 11:30 | |
| PrepareCode.pm6#L62 looks like where the magic happens, but just calling func with a type object shouldn't do much, right? | 11:31 | ||
| And $try-again should be False at that point, so the next line should always return?? | 11:50 | ||
| lizmat | pretty much looks like that, yes :-) | 12:08 | |
| SmokeMachine | Red::AST have a special Bool method… github.com/FCO/Red/blob/master/lib...ST.pm6#L28 | 13:24 | |
| leont: 👆 | 13:26 | ||
| leont | I didn't see that one coming | 13:29 | |
| lizmat | hmmm me neither | 13:30 | |
| SmokeMachine | (I hope that become much better with RakuAST) | 13:32 | |
| leont | Yeah, I don't think this can be done in a sane way without RakuAST. I'm surprised you got this far | ||
| SmokeMachine | I hope it become as simple as a RakuAST —> Red::AST translator | 13:35 | |
| lizmat: ant that’s why I wanted a easy way of getting the ast of a block… 👆 | 13:40 | ||
| lizmat | gotcha | 13:41 | |
| SmokeMachine | Would that make sense? | 13:44 | |
| leont | It makes sense on your side, but would it make sense to keep those ASTs around everywhere? | 14:02 | |
| It's easy to imagine an «ast { ... }» block though | 14:07 | ||
| SmokeMachine | I think that could be a way to do that optionally | 14:57 | |
| leont | Also, SQLite supports RETURNING nowadays (since 3.35), I think your docs would be a lot more readable if you used that | 16:55 | |
| SmokeMachine | leont: would mind to create an issue for that? | 18:11 | |
| I'm preparing a presentation for The Raku Conference about Red and I'm wondering... to run an update for several rows, one could just run a map doing the changes on a ResultSeq and call .save on the returned ResultSeq, like this: `Post.^all.grep(not *.title.ends-with: "!!!").map({ .title ~= "!!!" }).save`... and now I'm wondering... should ResultSeq.sink call .save? | 22:55 | ||
| what do you all think? | 22:56 | ||
| 7 Aug 2022 | |||
| japhb | That feels like a level too much of magic. | 03:45 | |
| SmokeMachine | Yes… maybe… | 04:08 | |
| leont | Yeah | 10:50 | |
| lizmat | a .sink could warn the resuls are lost ? | 11:08 | |
| and/or have an autosave option ? | 11:09 | ||
| SmokeMachine | I was thinking on autosaveing… but the warn is a great idea! | 11:20 | |