|
01:47
MasterDuke joined
|
|||
| timo | and why is it $!decoder.add-bytes(self.READ($bytes max 0x100000)); rather than the same thing but with "min", i wonder? | 01:55 | |
| so in the IO::Handle.Supply.lines case we're actually already reading "up to" the amount, but if an encoding in installed, we're calling $!decoder.consume-exactly-chars with the size, that's why even though read on the handle is returning multiple buffers, we're immediately asking for more to be read since consume-exactly-chars doesn't return until it can give you exactly that amount | 02:26 | ||
| fwiw, IO::Handle.lines.Supply does what you want immediately, since it uses decoder.get-line-chars | |||
| Supply uses readchars which has the same issue when used by the user directly: if the read size is too much, it won't return until that much is read, or EOF | 02:27 | ||
| most probably not what anybody wants | |||
| i don't see an op to get the number of available characters, so i'm not sure how to get the decodestream api to give up to a maximum. i could ask it to consume-available-chars but that could give more than the desired amount of graphemes, and i'm not sure if it's possible to unread back into the decodestream | 02:29 | ||
| there is bytes-available which i think is on the input side, not the output side? | |||
| MVM_string_decodestream_get_chars has a comment in front that says "if we are not yet able to decode that many, returns NULL", whereas the function MVM_decoder_take_chars is commented to "Takes the specified number of chars from the decoder, or all if there", so that's a discrepancy already | 02:39 | ||
| ..."or all if there is not enough" | 02:46 | ||
| so i made a MVM_string_decodestream_get_up_to_chars that behaves like MVM_decoder_take_chars is described to behave | 02:58 | ||
| seems to work how we want it | 03:00 | ||
| would be great to get some testing in for github.com/MoarVM/MoarVM/pull/1832 but it would probably be a Very Bad idea to immediately merge it for this month's release | 03:18 | ||
| releasable6 | Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 07:00 | |
|
07:43
sena_kun joined
|
|||
| timo | there is an nqp test that explicitly asks for nqp::decodertakechars(100) to return null if it can't generate 100 chars, so sounds like there needs to be a new nqp op, and a new method in Decoder that calls it? | 08:52 | |
| lizmat | not sure... I mean: the nqp op is only called in 1 place in the core | 08:54 | |
| I'd be more worried about the JVM backend not having it | |||
| (a new op) | 08:55 | ||
| any new op would have to be made on the JVM as well, or we introduce yet another discrepancy between backends :-( | 08:56 | ||
|
09:04
finanalyst joined
|
|||
| Geth | rakudo/splice-is-item-again-twice: 3e3e407e84 | ab5tract++ | src/core.c/traits.rakumod fix trait |
09:08 | |
| rakudo/splice-is-item-again-twice: f9c910189e | ab5tract++ | 4 files Using traits and dispatcher logic |
|||
| ab5tract | nine: it's working and ready for a sanity check before moving on to the non-multi dispatch case and implementations in the old dispatcher, and of course adding the internal revisiion to the QAST preamble (if I understood your proposal correctly) | 09:14 | |
|
09:31
sena_kun left
10:17
finanalyst left
11:30
MasterDuke left
13:42
Geth joined
|
|||
| Geth | rakudo/splice-is-item-again-twice: 70bd8e12c0 | ab5tract++ | src/vm/moar/dispatchers.nqp Using traits and dispatcher logic |
16:04 | |
| rakudo/splice-is-item-again-twice: 3b8e399ab2 | ab5tract++ | src/Raku/ast/compunit.rakumod First pass at providing language revision at the compunit level |
|||
| ab5tract | I wonder if that's _too_ easy... because it was very, very easy :) | 16:05 | |
|
16:12
finanalyst joined
|
|||
| nine | Making things like this easy was kinda the point of RakuAST :) | 16:18 | |
| ab5tract | and this even works as expected: 'use v6.e.PREVIEW; q|use v6.d; dd $?LANGUAGE-REVISION|.EVAL' => 2 | 16:24 | |
| can't say the same for the World.nqp version | 16:25 | ||
| 'use v6.e.PREVIEW; q|use v6.d; my @a = 1,2,3; @a.splice(1,1,$[7,8]); dd @a|.EVAL' => [1, 7, 8, 3] | 16:27 | ||
| (with RakuAST enabled) | |||
| Geth | rakudo/splice-is-item-again-twice: 869c43b5de | ab5tract++ | 2 files Add to World.nqp, use in dispatch |
16:28 | |
| ab5tract | nine: does this look more like what you had in mind? ^^^ | ||
| timo | nine: do you happen to have an opinion on the decodestream ops thing i mentioned? | 16:37 | |
| has anyone prototyped something like a raku linter based on RakuAST yet? | 16:38 | ||
| ab5tract | hmmm.. I wonder if the syntax highlighting efforts could be leveraged for linting | 16:42 | |
| timo | i bet there's some overlap, since some linting tools also look at formatting for additional context hints | 16:45 | |
| like "this else is in the wrong indent level for the if it belongs to" | |||
| can't think of more examples right now though? | 16:46 | ||
| ab5tract | I don’t have much experience with linters, clearly, because that is laterally the only thing I thought they could do 😅 | 16:56 | |
| timo | oh? well, you may be thinking more of like autoformatters | 16:57 | |
| linters can give a lot of different kinds of advice, from "best practices" / "idiomatic style", over things like security advice (make sure the input to this os.system is checked), over performance suggestions sometimes? | 16:58 | ||
| ab5tract | they are used for checking whether something complies with a code style spec, right? So superficial formatting as well as “we don’t do that here” kind of perlcritic stuff | ||
| timo | the better linters give you way more than that | 16:59 | |
| ab5tract | I guess I haven’t met one yet then | ||
| timo | if you write python, ruff seems pretty cool | ||
| ab5tract | We have SomarQube at work for the Java stuff and that thing is set to stupid | 17:00 | |
| timo: if you ever see me willingly embrace significant white space, you can rest assured the body snatchers have arrived and that I’ve already fallen to the invasion | 17:01 | ||
| :) | |||
| timo | maybe you're using brython? :) | ||
| ab5tract | My big thing with SonarQube, and I don’t know how applicable this is to other linters, but : if you can tell me what’s wrong, why on earth can’t you prepare an MR with the “brilliant fixes” you have in mind? | 17:03 | |
| Maybe one day we will be able to provide such a comprehensive nagging nanny via RakuAST :) | 17:04 | ||
| timo | there are linters that can fix stuff they complain about automatically | 17:06 | |
| ruff can fix a bunch of stuff, and there's an extra category of "dangerous" fixes you can opt into, which are fixes that are not guaranteed to keep semantics | 17:07 | ||
| like when it threw out all my print function calls because you shouldn't use them LOL | |||
| well, it was just a git checkout -p away to get it back | |||
| ab5tract | Haha! | 17:10 | |
| printing? You side effecting maniac! | 17:11 | ||
|
17:35
sena_kun joined
|
|||
| Geth | rakudo/splice-is-item-again-twice: 9e259df48e | ab5tract++ | 7 files [6.e] Dispatch in Array.splice based in `is item` trait This allows the following to DWIM: > use v6.e.PREVIEW; > my @a = 1,2,3; > @a.splice(1,1,$[7,8]) # [1,[7,8],3] For multis, you should add the `is revision-gated` trait at the minimum compatible revision supported by its candidates. |
17:43 | |
| rakudo/splice-is-item-again-twice: d3b456f1b0 | ab5tract++ | 7 files [6.e] Dispatch in Array.splice based in `is item` trait This allows the following to DWIM: > use v6.e.PREVIEW; > my @a = 1,2,3; > @a.splice(1,1,$[7,8]) ... (8 more lines) |
17:52 | ||
| rakudo/splice-is-item-again-twice: f3a11e2a8b | ab5tract++ | 7 files [6.e] Dispatch in Array.splice based in `is item` trait This allows the following to DWIM: > use v6.e.PREVIEW; > my @a = 1,2,3; > @a.splice(1,1,$[7,8]) ... (8 more lines) |
17:54 | ||
| ab5tract | okay, sorry for the spams. I think this one is ready for review | ||
| timo | this probably also has a very negligible performance impact on running code? | 18:06 | |
| github.com/rakudo/rakudo/pull/5630...d3c53R3889 this comment sits all alone, but it's already been valid before this PR? | 18:07 | ||
|
18:29
vrurg_ left
18:30
vrurg joined
|
|||
| ab5tract | timo: yes, it will have the impact of calling find method and checking for concreteness | 18:33 | |
| that comment was added while I was editing that area before. | 18:35 | ||
| The changes I added didn’t make it into the final commit, but the comment didn’t seem worth deleting | |||
| IIRC, the dispatch logic is only run once per callsote | 18:37 | ||
| *callsite | |||
| lizmat | if none of the guards fail, right ? | 18:38 | |
| timo | right, if the callsite turns out to end up with multiple targets, it can call the dispatcher multiple times, i think? | 18:41 | |
| lizmat | that's my understanding | 18:42 | |
| timo | but dispatchers are also built kind of like a chain, so there's parts that only run once per callsite and make some decisions and after that even if guards fail it will not start "all the way from the beginning"? not 100% clear on that though | 18:43 | |
| i want more debugging functionality for all of this because i don't understand it thoroughly | 18:44 | ||
|
21:50
sena_kun left
|
|||