Template default parameters question

make overloading template webSession(sessionInfo: untyped, baseUrl: string, actions: untyped): untyped = webSession(sessionInfo, baseUrl, Chrome, false, actions) Run

Found a Niche that only Nim can do: Easy Retro(e.g. MOS 65xx) Development with ORC/ARC

> Also, the reason I can't use Nim is not becuase I'm being an *, but > because I'm too stupid. I usually rely on libraries others make. You are neither but you should try to program in Nim what you previously did in Python. Now of course the lack of libraries might be a problem but there ar

Template default parameters question

When you call your template without setting those arguments it tries to put the block of code as the next argument. So essentially your actions now end up in the `browser` field and stuff breaks down.

Page allocation for a custom OS

As Araq said it should be "stdlib" This was for me a learning point on how to use patchFile :

Page allocation for a custom OS

As far as I can tell it should work for `include` too but you need "stdlib" instead of "nim".

Template default parameters question

I am obviously missing something here regarding optional defaulted parameters using templates: # Defaulting is supported in the following (even when there is an untyped parameter) var lastGreeting: string template greet*(lastGreeting: untyped, text = "Hello", who = "Bob

Found a Niche that only Nim can do: Easy Retro(e.g. MOS 65xx) Development with ORC/ARC

Why would you need JSON on a MOS-6502?

Page allocation for a custom OS

Oh, interesting. Didn't know about `patchFile`. Now that I read the docs on nimscript and did some research on the compiler code, I can't seem to get it to work. This is what I have: # src/kernel/config.nims patchFile("nim", "osalloc", "../nimpatches/osalloc")

Page allocation for a custom OS

Provide your own `osalloc.nim` file and use the `patchFile` configuration mechanism to use it.

Page allocation for a custom OS

I'm working on a hobby OS, and one thing I'm tackling next is trying to leverage Nim's heap allocator instead of writing my own allocator. I know that in [osalloc.nim](https://github.com/nim-lang/Nim/blob/devel/lib/system/osalloc.nim) Nim uses the underlying OS page allocator to allocate/free p

Found a Niche that only Nim can do: Easy Retro(e.g. MOS 65xx) Development with ORC/ARC

Nice that you found that one niche where Nim excels at while the rest of us mere mortals only use it for scientific computing, OS development, crypto currencies, games, compilers, web services, scripting... Can you now finally use Nim in good conscience? Ah no, here we go... > Do you mean Nim d

Found a Niche that only Nim can do: Easy Retro(e.g. MOS 65xx) Development with ORC/ARC

Found a Niche that only Nim can do: Easy Retro(e.g. MOS 65xx) Development with ORC/ARC

> Do you mean Nim doesn't have out of the box 8-bit CPU support? If that's the > case then, it is indeed a problem. Well you do need to "hack" the compiler anyway into accepting weird use-cases somehow, and there's only so many platforms that Nim can realistically support… At least GBA has the

Found a Niche that only Nim can do: Easy Retro(e.g. MOS 65xx) Development with ORC/ARC

CC65 is an old compiler and doesn't support C99. You can cross-compile using LLVM-MOS and have a lot lot lot faster compile times and also get all modern compiler optimizations of LLVM.

Found a Niche that only Nim can do: Easy Retro(e.g. MOS 65xx) Development with ORC/ARC

More of this kinda stuff would be interesting to see, but I am not quite confident yet with the hardware of any of those machines to give it a shot myself at the moment. There already exists dedicated C compilers for 65xx such as [SDCC](https://sdcc.sourceforge.net/) and [CC65](https://cc65.git