| releasable6 | Next release in ≈1 day and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 03:00 | |
|
05:45
[Coke] left
05:49
[Coke] joined
07:19
[Coke] left,
[Coke] joined
|
|||
| Geth | GD-Raw: 0racle++ created pull request #1: Add some in-place filters |
08:17 | |
|
08:40
sena_kun joined
|
|||
| Geth | GD-Raw/main: 21113fdddb | 0racle++ | lib/GD/Raw.rakumod Add some in-place filters Adds some of the functions documented here: - libgd.github.io/manuals/2.3.0/file...ter-c.html I have inserted them below gdImagePixelate as that is where they appear in the C header github.com/libgd/libgd/blob/master/src/gd.h |
08:56 | |
| GD-Raw/main: 6654e5af23 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | lib/GD/Raw.rakumod Merge pull request #1 from 0racle/add-filters Add some in-place filters |
|||
|
08:57
sena_kun left
|
|||
| Geth | GD-Raw/main: 399cb5b06d | (Elizabeth Mattijsen)++ | 3 files 0.4 |
09:02 | |
|
09:27
lizmat left
09:29
lizmat joined
|
|||
| Geth | rakudo/main: ce03069d2b | (Elizabeth Mattijsen)++ | 3 files Make Iterable.flat an only again Turning it into a multi broke Dan, and possibly other modules that Blin didn't catch. Turning it back into an only again, required changes in Range and native array as well. The problem is really caused by the fact that current consumers ofi ... (7 more lines) |
09:47 | |
| rakudo/main: 2750112c08 | (Elizabeth Mattijsen)++ | src/core.c/REPL.rakumod Handle REPL case if %*ENV<_> is not set Which may happen if modules start instantiating the REPL class, which I'm not sure is actually documented or supported. Unbreaks Text::CodeProcessing module |
10:12 | ||
| lizmat | jdv: concluded my blin induced investigations | 10:24 | |
| jdv | looks like its all figured then. Thanks! | 14:24 | |
| i wasn't able to repro the gio one. i guess its fine. | 14:28 | ||
| its normal for a test to fail but not really a moarvm panic like that, at least not in a long time | 14:29 | ||
| i meant fail in the blin run but not be reproducable | 14:30 | ||
| lizmat | well, there's still some gremlins in MoarVM and NativeCall specifically, so I'm not really surprised by the non-reproducebility | 14:34 | |
| jdv | maybe a few years ago or so it was way more common for moarvm to freak iirc | 14:37 | |
| hopefully this is not a new regression | 14:38 | ||
| lizmat | I hope so too :-) | 14:39 | |
| the fact that they're less common now, is a good sign | 14:40 | ||
| jdv | yes, i remember a few people did a lot of work to fix that up back in the day. | ||
| ab5tract | once again wrestling while angry with the native `to-json` .. why is `no worries` not enough to suppress the deprecation notice? | 16:44 | |
| imagine a script that wants to output some json to be read by another process. is it impossible to do this without a third-party module? | 16:45 | ||
| I mean, at least the deprecation notice arrives on stderr, so I guess the above concern is mitigated | 16:47 | ||
| jdv | what would be the vm cored json lib? the simd one? | ||
| ugexe | ab5tract: github.com/ugexe/zef/blob/45f3ac76...umod#L5-L8 >:) | 16:49 | |
| ab5tract | ooooo | ||
| ugexe | naturally this is the part where i have to tell you not to do that, which you are free to ignore | 16:50 | |
| ab5tract | jdv: If / when I have the tuits, I would try wiring the simdjson.c or whatever it's called into MoarVM | ||
| then likewise deliver jackson -- or if I get around to it -- kotlin serilization for the JVM backend | |||
| both exposed via a single nqp api | 16:51 | ||
| ugexe: I had no idea that zef was such a mischevious machine :) | 16:52 | ||
| jdv | that could be cool. ctilme did some nice work modularly but iirc ultimately its the c/nqp/raku barrier that eats resources | ||
| ab5tract | yeah, I don't want to make NativeCall resemble XS by any means | 16:53 | |
| but the flipside of that is that in situations where NativeCall is unfairly handicapping an important (imo integral) component of the language, we need a way to vault over the issue and deliver a VM-level solution | 16:54 | ||
| but who knows, maybe smarter minds than mine already have some notions about how to cleanly provide VM hashes to NativeCall space ... I know nine has some ideas on where the current implementation could receive an upgrade | 16:56 | ||
| jdv | except hes busy building a biz:) | 16:57 | |
| ab5tract | One last thought: I think this all falls under the principle of making the difficult possible | ||
| To which I mean, don't handicap our external libraries to the lowest common denominator, but instead allow VMs to have VM-specific libraries | 16:58 | ||
| jdv | that was kinda the point of nqp:) but maybe with a lot of careful effort it could be threaded around well. | 17:00 | |
| ab5tract | if the JVM backend ever reaches strong interoperability with other JVM libraries and the like, then it would be fair to expect that there would be Raku modules that would either only run on JVM or would run with significant changes to the backed | ||
| nqp is a perfect solution for how to allow two backends to have divergent solutions to the same problem but comply to the same API | 17:01 | ||
| I'm talking more about trying to integrate C but not being able to access any Raku datastructures. Which is fair, but it doesn't make sense to me that we wouldn't allow easy-ish access to MoarVM ones | |||
| Or trying to integrate a Java/Scala/Kotlin library but being forced to use a sub-optimal data structure to do so | 17:02 | ||
| not even a datastructure, essentially a function callback | |||
| Right now all the weight is placed on the "maybe one day Rakudo will run on a zillion VMs next to another zillion independent Raku implementations" ... and I just don't see the utility in that line of thinking. I'm not saying we should abandon that dream, but it needs to be tempered with the reality of where we are currently at. | 17:05 | ||
| jdv fondly remembers parrot | 17:07 | ||
| ab5tract fondly remembers reading the initial Perl + Python = Parrot announcement on slashdot.org | 17:09 | ||
| jdv | did dan get a pie in the face? i barely remember. | 17:11 | |
|
17:40
sena_kun joined
|
|||
| Geth | roast: 9bf4b1ea07 | (Christian Bartolomäus)++ | spectest.data Revert "Disable test file that hogs up all memory" This reverts commit a9808b7896ab5f675ccca910b411e34bbd0dbfa2. The underlying problem has been fixed and the test file can (and should) be used again. Relevant commits for Rakudo: * github.com/rakudo/rakudo/commit/4b53990c2b * github.com/rakudo/rakudo/commit/6f8d314c2a |
19:49 | |
| [Coke] | pretty sure yes | 20:14 | |
|
20:43
lizmat left
|
|||
| ab5tract | Dan? | 21:52 | |
| [Coke] | www.perlmonks.org/?node_id=502226 | 22:06 | |
|
22:15
sena_kun left
|
|||
| releasable6 | Next release in ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 23:00 | |
|
23:22
lizmat joined
|
|||