!CENmKDnMngVwJJrTry:matrix.org

Inko

295 Members
The Inko programming language. | #inko:matrix.org4 Servers

Load older messages


SenderMessageTime
2 Jul 2022
@_discord_910264557761593345:t2bot.iosepia#0635 changed their profile picture.17:05:13
3 Jul 2022
@mdr721:matrix.orgmdr721 joined the room.00:44:11
@_discord_608442079323881473:t2bot.iojenra#6502 changed their display name from jenra [amethyst] to jenra#6502.01:31:58
@_discord_490626591983140864:t2bot.ioAnFunctionArray[Re-regularC]#5380 changed their display name from AnFunctionArray to AnFunctionArray[Re-regularC]#5380.16:52:40
@_discord_490626591983140864:t2bot.ioAnFunctionArray[Re-regularC]#5380 changed their profile picture.16:52:41
@_discord_553754597651513345:t2bot.iory#2827 changed their profile picture.22:55:57
4 Jul 2022
@_discord_783460822525149196:t2bot.iohyenasky#1860 changed their profile picture.00:39:31
@chepyrka:nitro.chatchepyrka joined the room.03:03:36
@yorickpeterse:matrix.orgYorick PeterseNext challenge: making it so you can share processes between processes, ideally without complicating code generation too much21:42:28
@yorickpeterse:matrix.orgYorick PeterseThat is, if you spawn a process you sort of get a handle/client back (really just a pointer to the spawned process). You should be able to clone that, so multiple processes can send messages to the same one21:43:06
@yorickpeterse:matrix.orgYorick Peterse

This introduces a few challenges though:

  1. clone is a method from the Clone trait, but async classes (= used for processes) can't implement traits. This is because regular methods can't be accessed by anybody but the process itself, and thus implementing traits is kind of pointless. It would also be hard to verify a method is safe to use from the outside

  2. If we can't implement traits for async classes, we can't implement Clone; unless we "bless" that implementation (basically by the compiler generating the implementation and ignoring the limitation). Technically this is safe, but it feels weird that clone would literally be the only method you can use from the outside/client side

  3. Creating refs to processes, dropping them, and dropping processes themselves needs extra work. Refs would need atomic operations (because they'd modify the same shared value). When dropping a process, it shouldn't be free'd until there are no more references/clients to it

Alternatives involve wrapping the client side in a dedicated type, but then you're lying at the type level (e.g. you'd actually have a Handle[Proc] instead of just a Proc, but type it as Proc in the compiler), and you end up with this weird setup where Proc {} returns a Handle[Proc], while for regular classes it would return Proc

21:47:55
@yorickpeterse:matrix.orgYorick Petersebasically the meaning of class literals changes, which I'm not a fan of21:48:07
@yorickpeterse:matrix.orgYorick Peterse also you'd need extra work when sending messages, because given a proc.message() call, you'd have to translate that to proc.wrapped_process_pointer.message() more or less 21:48:38
@yorickpeterse:matrix.orgYorick PeterseAnd of course spawning a process would require two allocations: one for the server-side, and one for the client-side21:48:58
@yorickpeterse:matrix.orgYorick PeterseToday I experimented with basically adding "shared values", which are values that use atomic reference counting, and dropping their owned counterpart doesn't run the destructor/frees it until the ref count is zero. I applied it to both processes and strings (since I want strings to be value types but not copy the bytes). It sort of works, but it feels icky21:50:06
@yorickpeterse:matrix.orgYorick PeterseIn particular, I'm still not sold on strings being value types21:50:23
@yorickpeterse:matrix.orgYorick Peterse The implementation is also icky: basically every object header now stores a shared flag, and based on the value of this flag it either uses regular ref counting operations or atomic ones, but it's not clear how this impacts optimisations of the VM 21:50:58
@yorickpeterse:matrix.orgYorick Peterseand it's an extra branch for every increment and decrement21:51:17
5 Jul 2022
@_discord_916986454104739860:t2bot.io/etc/rc.d/nishi#9519 changed their profile picture.07:02:21
@_discord_894935459459895377:t2bot.iojoe {sarcosuchus} changed their display name from カニ (doesnt hurt to try elixir) to kani#8733.16:47:28
@_discord_894935459459895377:t2bot.iojoe {sarcosuchus} changed their display name from kani#8733 to joe {sarcosuchus}.16:47:56
@_discord_280107928965349376:t2bot.iofullsync#8302 changed their display name from fuzzypixelz#8302 to fullsync#8302.20:30:00
@yorickpeterse:matrix.orgYorick PeterseGot this working, now need to decide if I like it. In particular generics are complicated a bit more, due to the lack of monomorphisation 21:48:19
@yorickpeterse:matrix.orgYorick Peterse e.g. fn foo[T](value: T) {} produces this CFG: 21:48:58
@yorickpeterse:matrix.orgYorick Petersebb.png
Download bb.png
21:49:21
@yorickpeterse:matrix.orgYorick Peterse Here the issue is that T could be an owned value, a reference, or a value that uses atomic reference counting 21:49:46
@yorickpeterse:matrix.orgYorick Peterse One thing I need to decide on is if I want my drop instruction to be a sort of macro that expands to the above 21:50:27
@yorickpeterse:matrix.orgYorick Peterse That is, in MIR there's just drop that can operate on an owned value, a ref, or an atomic value. When generating the final code, this would expand into the appropriate code based on the type it's operating on 21:50:52
@yorickpeterse:matrix.orgYorick PeterseThis simplifies generating MIR in a few places, and makes it easier to remove/adjust through optimisations, as only a single instruction needs to be looked at/modified/etc, instead of a bunch of instructions in different basic blocks21:51:35
6 Jul 2022
@_discord_781745960829059072:t2bot.ioforeignsasquatch#6574 changed their profile picture.13:15:52

There are no newer messages yet.


Back to Room List