!CENmKDnMngVwJJrTry:matrix.org

Inko (lang)

28 Members
General purpose chat room about the Inko programming language.2 Servers

Load older messages


SenderMessageTime
6 Aug 2020
@yorickpeterse:matrix.orgyorickpeterseThen I could restrict constant values to integers, strings, ranges, and floats19:46:49
@yorickpeterse:matrix.orgyorickpeterseoh hmpf I forgot, Inko's own test suite relies on a global19:47:15
12 Aug 2020
@yorickpeterse:matrix.orgyorickpeterseTaking a small detour from the compiler to work on https://gitlab.com/inko-lang/inko/-/issues/4318:27:34
@yorickpeterse:matrix.orgyorickpeterseThe implementation is a bit different: the VM now runs a single bytecode image that contains all modules; not an archive18:27:49
@yorickpeterse:matrix.orgyorickpeterse it also only supports that image, so no more parsing of modules at runtime 18:28:02
@yorickpeterse:matrix.orgyorickpeterseCombined with some cleanups to the bytecode parser, an image of about 2MB (= the entire test suite+standard library) takes about 7ms to load (when parsing modules in parallel, otherwise it takes about 15ms)18:29:30
@yorickpeterse:matrix.orgyorickpeterseTotal runtime of the test suite is also reduced by about 20ms18:29:53
@yorickpeterse:matrix.orgyorickpeterseOne weird thing though is that it seems performance degrades when using more than 4 threads for parsing, so I'm trying to figure out why that is18:31:01
@yorickpeterse:matrix.orgyorickpeterseThe end goal is faster loading/startup, parallel module parsing, and easier distribution (you only need to distribute a single file, instead of many)19:09:56
13 Aug 2020
@cheer:tchncs.decheer joined the room.21:54:05
14 Aug 2020
@yorickpeterse:matrix.orgyorickpeterseimage support is landing in https://gitlab.com/inko-lang/inko/-/merge_requests/98, pretty happy with the result00:18:31
@yorickpeterse:matrix.orgyorickpeterseGot rid of a ton of cruft in the bytecode parser too00:18:53
@yorickpeterse:matrix.orgyorickpeterseI think it's one of the oldest parts of the VM, and it was showing it's age in various places00:19:21
@yorickpeterse:matrix.orgyorickpeterseAh yes, quite a bit of code originates from 201600:19:50
@yorickpeterse:matrix.orgyorickpeterseThis should also make bootstrapping the self-hosting compiler easier, as we only need to find one image file; not hundreds of bytecode files00:22:00
@yorickpeterse:matrix.orgyorickpeterseIn theory we could even provide a wrapper that's just a Rust executable with the image and VM embedded00:22:14
@yorickpeterse:matrix.orgyorickpeterseThat way we don't have to go through a whole bunch of paths just to figure out where the darn image is located00:22:30
@yorickpeterse:matrix.orgyorickpeterseNot sure about that just yet though, but at least it's easier to do now00:22:53
@andrew_chou:matrix.organdrew changed their display name from Andrew Chou to andrew.17:28:30
15 Aug 2020
@hernytan:matrix.orghernytan
In reply to @yorickpeterse:matrix.org
Right now that term is indeed not correct, but it's supposed to be immutable/a true constant
Do you plan to make immutability deep? i.e. if an object is immutable, and it contains an array, can that array mutate?
15:21:58
@hernytan:matrix.orghernytan
In reply to @yorickpeterse:matrix.org
Basically yes. The issues I have with tracing are the usual ones: no determinism, significant runtime complexity, not the most developer friendly (e.g. you can't have destructors without finalizers)
very interesting, I'd be curious to see how this turns out. Nim is on the same path, you may want to look at what's done there, though the language semantics are quite different
15:24:00
@hernytan:matrix.orghernytan

btw yorickpeterse I'm quite curious as to how Inko does its preemptive scheduling, as I'm looking into this area. For instance, BEAM uses reductions based on function calls mostly.

I found the scheduler here: https://gitlab.com/inko-lang/inko/-/tree/master/vm/src/scheduler but was wondering if you could point me in the right direction?

15:28:13
@yorickpeterse:matrix.orgyorickpeterse hernytan: The idea was to make (im)mutability transitive yet. With that said, I have postponed it for the time being. It's an interesting idea, but it comes with a bunch of challenges that are super hard to fix (e.g. memory fragmentation becomes a problem). I also fear it would make Inko too different of a language 21:41:00
@yorickpeterse:matrix.orgyorickpeterseI probably will revisit it over time as sort of a side-project/curiosity, but I think it will be a while before anything concrete comes of it21:41:25
@yorickpeterse:matrix.orgyorickpeterse
In reply to @hernytan:matrix.org

btw yorickpeterse I'm quite curious as to how Inko does its preemptive scheduling, as I'm looking into this area. For instance, BEAM uses reductions based on function calls mostly.

I found the scheduler here: https://gitlab.com/inko-lang/inko/-/tree/master/vm/src/scheduler but was wondering if you could point me in the right direction?

Inko uses a similar approach. Currently we only reduce for method calls, but this probably will change at some point
21:42:02
@yorickpeterse:matrix.orgyorickpeterseReducing is done in the interpreter loop, starting at https://gitlab.com/inko-lang/inko/-/blob/master/vm/src/vm/machine.rs#L28721:42:49
@yorickpeterse:matrix.orgyorickpeterseIt's then reduced e.g. here https://gitlab.com/inko-lang/inko/-/blob/master/vm/src/vm/machine.rs#L40921:43:17
@yorickpeterse:matrix.orgyorickpeterseThat macro is implemented here https://gitlab.com/inko-lang/inko/-/blob/master/vm/src/vm/machine.rs#L10121:43:36
@yorickpeterse:matrix.orgyorickpeterseHm I think that comment is out of date, heh21:44:22
@yorickpeterse:matrix.orgyorickpeterseThe code you linked to is used for the actual scheduling part, that is figuring out what thread to run something on, pulling work to do, etc21:45:22

Show newer messages


Back to Room List