 | Inko (lang) | 15 Members |
| General purpose chat room about the Inko programming language. | 1 Servers |
| Inko (lang) | 15 Members |
| General purpose chat room about the Inko programming language. | 1 Servers |
| Timestamp | Message | |
|---|---|---|
| 12 Nov 2019 | ||
| 21:49:12 |  yorickpeterse | For 1: basically the algorithm work by maintaining a "busy" counter, and when this reaches 0 the threads terminate |
| 21:49:47 | yorickpeterse | But if one thread spins super fast (incrementing it again at the start of a spin), other slower threads may never observe a value of 0 |
| 21:52:51 | yorickpeterse | e.g. sometimes I see this:
Here the first few columns are the number of objects marked per thread |
| 21:53:05 | yorickpeterse | but once in a while you'll get this:
|
| 13 Nov 2019 | ||
| 06:35:43 |  sarna | but one thread would be able to observe it, right? before incrementing it |
| 06:36:07 | sarna | ah, but it could check, it’d be 1, and then some other thread could decrement |
| 06:36:18 | sarna | * ah, but it could check, it’d be 1, and then some other thread could decrement |
| 14:17:56 | yorickpeterse | The issue here is that we may end up with threads terminating too soon |
| 14:18:21 | yorickpeterse | Though there will at least always be one thread left to do the work, so the worst case it just takes much longer (instead of losing work) |
| 19:12:00 | sarna | doesn’t sound too bad |
| 20:31:51 | yorickpeterse | I think I got the termination detection to work properly and not terminate prematurely, now to see if I can make sure all workers at least do some work |
| 20:31:59 | yorickpeterse | instead of one or two sometimes not being able to do any work |
| 17 Nov 2019 | ||
| 19:01:42 | yorickpeterse | https://inko-lang.org/news/inko-0-6-0-has-been-released/ |
| 20:11:24 |  fsx | 🎉 |
| 20:14:36 | sarna | very nice 👏 |
| 20 Nov 2019 | ||
| 22:29:18 | yorickpeterse | Ugh, having quite some trouble with the new compiler's design. I want the compiler to compile modules in parallel, but this is tricky as those processes need access to type information. In my current approach I have a single process called the type database, owning all the structures. Other processes simply use type IDs (wrappers around integers), and message passing. |
| 22:30:10 | yorickpeterse | Sadly this creates some design issues, such as how do we implement type checking? e.g. we could define the method type_compatible? on these type IDs, but then the implementation would have to be on the server side (since an ID doesn't really know what it actually points to), serialising most type operations |
| 22:31:58 | yorickpeterse | One approach I am currently considering is to have a different object for every kind of type ID (so a BlockId, MethodId, ObjectId, etc) instead of one general TypeId |
| 22:32:19 | yorickpeterse | Then those Id types can implement the necessary functionality, meaning the types on the server side are just dumb data objects |
| 22:32:57 | yorickpeterse | So you get something like this: |
| 22:34:03 | yorickpeterse | This setup would (in a way) be somewhat similar to an Entity Component System |
| 22:38:49 | yorickpeterse | All of this would be easier if there was shared memory, but that would bring 99 new problems 😛 |
| 22:38:55 | yorickpeterse | * All of this would be easier if there was shared memory, but that would bring 99 new problems :P |
| 22:39:13 | yorickpeterse | * All of this would be easier if there was shared memory, but that would bring 99 new problems 😛 |
| 23 Nov 2019 | ||
| 21:34:12 |  Andrew Chou changed their display name from andrew_chou to Andrew Chou. | |
| 29 Nov 2019 | ||
| 15:13:44 | yorickpeterse | Decided to ditch the parallel type checking approach, as I could not make this work in a way that I did not hate. Instead, compilation will be broken up in stages and only some will be done in parallel |
| 15:14:00 | yorickpeterse | e.g. parsing will be done in parallel, but type defining and checking will be done sequentially |
| 15:14:28 | yorickpeterse | Optimising will also be done sequentially because it needs type info, but I don't expect this to be very expensive as most optimisations will be pretty simple |
| 15:14:42 | yorickpeterse | Then generating bytecode can be done in parallel again |
| 6 Dec 2019 | ||
| 15:12:43 | yorickpeterse | https://inko-lang.org/news/inko-progress-report-november-2019/ |