|
00:02
librasteve_ left
|
|||
| patrickb | I'm gonna do something dirty. Question: How dirty. | 05:27 | |
| I'm creating a class `VarArgPointerSentinel` with a single $target attribute holding a reference to the thing to pass by pointer. `Pointer.to($some-var)` will construct an object of that class. | 05:28 | ||
| I could either in the native call dispatcher extract that target and pass it unwrapped and add an additional bool array which states which args should be passed by pointer and which not. | 05:30 | ||
| This is a lot of shuffling around and thus pretty expensive. | 05:31 | ||
| But I could also just pass that VarArgPointerSentinel down to Moar and fumble out the target there. | 05:39 | ||
| That is simpler but couples Moar code to that Rakudo class. | 05:40 | ||
| ab5tract | Is that possible while staying "in" Raku(do) code? If it doesn't require custom patches to moarvm, then I think it is not a big deal | 05:55 | |
| patrickb | No, I'd have to do it in moar. thus the coupling. But: I just realized that it might actually be more performant to do the extraction in Rakudo land in the dispatcher. Reason: The extraction in the dispatcher can be optimized by spesh. When reaching into that class in Moar land, spesh can do nothing. | 06:08 | |
| ab5tract | ah, nice catch | 06:11 | |
| patrickb | now I wonder: What's the best data structure to pass the info down to moar which args are pointery? A bitmap? A list of ints? | 06:13 | |
| How would I create such a bitmap list? Manually putting together a uint64? (assuming we'll never try to pass more than 64 var-args?) | 06:15 | ||
| ab5tract | "manually putting together the uint64" -- manually implies doing a lot of bit twiddling with the +& , +^ , etc, right? | 06:20 | |
| patrickb | yes | 06:32 | |
| to be honest that's really not as bad as it sounds | |||
| ab5tract | good to hear :) | 06:39 | |
| ugexe: I think there was a strong consensus emerging for removing all implicit $/ from the language | 06:54 | ||
|
07:54
librasteve_ joined
14:25
shareable6 left
14:27
shareable6 joined
19:18
Geth left,
Geth joined
|
|||
| japhb | patrickb: You can actually put together an Int via bitops, and hand that down ... because P6bigint exists at the C level | 20:20 | |
| patrickb | jup that's the plan | ||
| the Rakudo side is almost done. :-) | |||
| the non pointer case works already. there is finally some progress. Yay! | 20:21 | ||
| [Coke] | is github.com/rakudo/rakudo/pull/5215 still needed? Looks like it depended on PR A, but similar PR B got merged in its place. | 22:55 | |
| releasable6: next | 22:59 | ||
| releasable6 | [Coke], Next release in ≈24 days and ≈20 hours. There are no known blockers. 18 out of 22 commits logged | ||
| [Coke], Details: gist.github.com/d1fac55543a79d042c...400a201243 | |||
| [Coke] | releasable6: next | ||
| releasable6 | [Coke], Next release in ≈24 days and ≈20 hours. There are no known blockers. 18 out of 22 commits logged | ||
| [Coke], Details: gist.github.com/076640aa0f0a6cf70d...b5f0cd7391 | |||