Any libraries for dictionary coding (compression) of array structures ?

No, it's not at all the easiest way to go at it. I don't see what I can use from there, even conceptually. This is the barebones code I wrote for this - It has some shortcomings: The algorithm to generate it is probably not optimal, checking if each new entry

Polymorphism doesn't work building a dylib for Playdate (Cortex M7) with ARC

Also looks like they're using FreeRTOS under the hood so you can also set `--os:freertos`. I found `--define:nimAllocPagesViaMalloc` to work well with FreeRTOS and embedded too. see

Polymorphism doesn't work building a dylib for Playdate (Cortex M7) with ARC

Please open an issue for this, I have a fix for it.

Polymorphism doesn't work building a dylib for Playdate (Cortex M7) with ARC

Not calling NimMain also causes all sorts of other issues too like global variables not being initialized. I ran into that one before too. :) You probably also want your cpu to match the target cpu not the hosts. So it'd be just `arm`. PS feel free to ask about the cortex m7's if you run into i

Basic window graphics library?

Looking for a library that will let me simply display an array of pixels, and get keypresses(not a strict requirement). Python with Pygame would allow me to do this with pygame.surfarray.blit_array(pgscreen, pixelarray) Run where pixelarray is a multidimensional NumPy

Polymorphism doesn't work building a dylib for Playdate (Cortex M7) with ARC

Another workaround is to use `--nomain:off`.

Choosing Nim out of a crowded market for systems programming languages

I want to say that I have tried many languages, and came to understand that Nim is "future-proof", it can go down all the way, and go up all the way. So, very abstract because of macros, and very low level, because it compiles to c. performance was always good enough. memory use, had to be optim

nimNx: a compilable nintendo switch example

Also created another project to show how to make static libraries for switch using nim. This should be useful if you already have some code in C and want to extend it.

Polymorphism doesn't work building a dylib for Playdate (Cortex M7) with ARC

Wow, that seems to be it. Thank you!

Polymorphism doesn't work building a dylib for Playdate (Cortex M7) with ARC

I think the issue here is that the RTTI needs to initialized. You should probably call `NimMain()` in `eventHandler` before everything else.

Choosing Nim out of a crowded market for systems programming languages

Okay this post does it. I agree that choosing a programming language to 'Get Sh!t done' is a perfectly reasonable goal, In my case any time I save with programming I can put it on managing my health issues. I like that Nim has showcased that performance and cognitive hog needn't be mutually in

Polymorphism doesn't work building a dylib for Playdate (Cortex M7) with ARC

I'm writing Nim bindings for the C SDK release by Panic for the Playdate portable console. However, I stumbled upon an issue writing a more ergonomic API over the existing one. I'm testing this on the Playdate simulator. Polymorphism doesn't work as expected, here's my code: # ---

Not able to get `in` for sets to work properly

Hahahaha @ LaTeX (I can't believe you remember that!)

Not able to get `in` for sets to work properly

Bad idea: Looking at the C code. Better idea: Looking at the assembler code. Even better idea: Looking at the results of a profiler. Best idea: Stop using LaTeX.

ARC and {.requiresInit.} issue

> I believe this might be related to/caused by > I agree, it looks very much like that.

ARC and {.requiresInit.} issue

> What is the problem of zero initialization for objects? In the case of your > code, it seems nimZeroMem is removed by GCC. This is a reduced version. Optimization does not always work. I discovered this problem when I was looking through the generated assembly and noticed pointless operations

Not able to get `in` for sets to work properly

>Or shouldn't I even bother in this case? probably not? You should be looking >at the assembly, not the c code Godbolt is your friend

Ideas about the exception-tracing system

This is what effectsOf is for: proc f(callback: proc()) {.effectsOf:callback.} = callback() proc g() {.raises: [ValueError].} = raise newException(ValueError, "") proc h(){.raises:[].} = f(g) Run does not compile because

Ideas about the exception-tracing system

Consider the following code: proc f(callback: proc()) {.raises: [].} = callback() proc g() {.raises: [ValueError].} = raise newException(ValueError, "") f(g) Run This incorrect, as `f` does raise an exception, but above code compiles becaus

Type macro returning a transformed type def + other definitions

Thanks! For others, I've found this feature to be partially documented here:

Not able to get `in` for sets to work properly

Observation (I spotted it!) If I change this: if unlikely(not (x.kind in static spec[0][1])): Run to this (basically, just remove `static`): if unlikely(not (x.kind in spec[0][1])): Run then it compiles to: T9_ = NIM_UNLIKELY(

Not able to get `in` for sets to work properly

I imagined that. But I'd still like to benchmark the two version to see if there is any actual difference. At some point (I honestly don't remember how; it was after moving the different parts around and trying to pass just an one-dimensional array to `require`, I think), I got it to work... bu

Not able to get `in` for sets to work properly

Ah, okay, I understand now, you want the `in` operator to be optimized out at the Nim compilation level because the set is constant. I don't think Nim does that, but I'm 99.9% sure all modern C compilers will optimize that anyway, so it shouldn't be a big deal I think.

Not able to get `in` for sets to work properly

My main doubt is why this is not properly converted into a set-membership test...

Not able to get `in` for sets to work properly

Well, the so-many uses of static are to be cleaned up. That's exactly what I'm working on right now. Having said this, the test `x.kind in spec[0][0]` for example cannot be static in its entirety since `x.kind` is not known at compile-time. `spec[0][0]` is, however.

Not able to get `in` for sets to work properly

Why are you using so many `static` in that template? And if you want to make sure the whole expression is computed at compile-time, you need to wrap the whole expression in `static`, not just an argument, so `static(1+5)` and not `1 + static(5)`.

Not able to get `in` for sets to work properly

I have an enum `ValueKind` and set based on this: `ValueSpec = set[ValueKind]` Most of the times I use something like `someValue in someSpec`, the test works correctly and transformed into bit arithmetic (in the C code). I have one particular case I've been struggling with, which I cannot get to