How to access command line parameters under the JS backend

Would be better to keep platform specific code away from Nim's core. 1. Node is not only platform, there's also Deno which could be the future. 2. Even in Node.JS many essential functions are not in the core but in libraries. So the libraries to deal with Node.JS (or Deno) feels better. Li

Defects and CatchableErrors

Wow, this is a pretty new paradigm for me: Coming from Python I usually obeyed EAFP ("easier to ask for forgiveness than permission") and only in time critical situations I optimised code against it. But, ok, LBYL (look before you leap) sounds good to. :-)

How to access command line parameters under the JS backend

Thanks @ElegantBeef. Will give it a try.

hotcodereloading and libfswatch

Interesting - thanks for testing this, @shirleyquirk! If the only diff between our setups is OS, and therefore the backend for libfswatch, its almost certainly libfswatch. I guess the next step is to try a different file-watching utility.

hotcodereloading and libfswatch

@shirleyquirk also your vim behavior is interesting.. is it doing some kind of autosave? That's even more of an automated code reload!

Nim 1.2.10 RC and 1.4.4 RC

how about releasing RC candidates with odd numbers, eg: `1.4.2` is a stable release `1.4.3` is a RC candidate for `1.4.4` (if needed, you could even have`1.4.3.1`, `1.4.3.3` but that's not actually needed for this proposal)

hotcodereloading and libfswatch

on linux: i don't get a crash but it does occasionally stall with a `inotify_rm_watch: Invalid argument` but changing the file again (not even saving, i dunno what vim is doing) makes it work again. the inotify_rm_watch error is from inotify, the linux backend that libfswatch uses. circumstan

Error: Closure iterators are not supported by JS backend!

closure iterators never worked in JS backend. iterator foo(limit: int = int.high): int {.closure.} = yield 12 for x in foo(12): discard Run Error: internal error: for statement not eliminated No stack traceback available To create a stacktrace

hotcodereloading and libfswatch

I can definitely minimize. How about I remove SDL. mymain.nim import logic import libfswatch import libfswatch/fswatch import osproc var running = true proc cb(event: fsw_cevent, event_num: cuint) = echo "saved" echo execProcess("nim c --hotc

Strange memory problem

assert( vsmap.len("clip") == 1, "the vsmap should contain one node")

Error: Closure iterators are not supported by JS backend!

Thanks, this is the showstopper I run into. The more appropriate error message might be: "Error: Closure iterators are not supported **anymore** by JS backend!" It seems to be "work in progress" and I'll wait for you guys to get this sorted out.

Error: Closure iterators are not supported by JS backend!

See

Error: Closure iterators are not supported by JS backend!

Open up an issue here: maybe some people on the GitHub have a few pointers.

Strange memory problem

I am reviewing some code that I did some time ago and has stopped working properlly. The code wraps a C library (vapoursynth). What is happening is that the code works when run with `--d:danger` but it fails without it. The code is pretty simple. In one hand: import ../src/vapour

Error: Closure iterators are not supported by JS backend!

I could not find any clues in Any suggestion what to do?

How to kill a process and all of its descendants in Nim?

Thanks @shirleyquirk. That's right, $ kill $pid only without (-9) works as expected. Thanks again :-)

Nim 1.2.10 RC and 1.4.4 RC

When can we expect a non RC release?

Defects and CatchableErrors

Sure you can, but you should is another can of worms see

Error: Closure iterators are not supported by JS backend!

Regression, a showstopper one I dare say, platform support shouldn't change in a bugfix release.

How to kill a process and all of its descendants in Nim?

it is not possible to catch or ignore SIGKILL (-9) or SIGSTOP @dom96 and @kaushalmodi have put together this example for other signal handlers:

Error: Closure iterators are not supported by JS backend!

After the last update to 1.4.2 (from 1.4.0) I get the following error message: Error: Closure iterators are not supported by JS backend! Run The culprit line is ... iterator foo*(limit: int = int.high): int {.closure.} = Run Is this a

How to kill a process and all of its descendants in Nim?

same answer, ish. just copying from the stackoverflow answer, using `pkill -P $pid` or `kill $(ps -o pid= --ppid 31384)`

How to kill a process and all of its descendants in Nim?

Thanks @shirleyquirk for your help, but my problem persists, or I haven't explained myself well. What I want is to write the command "kill" in the terminal to kill the process and all of its descendants. How to catch the signal sent by "kill" in Nim? Example: # launch n processes

String "interning" attempt

Here is a minimally optimized module to do interning - basically 30 lines of a specialized hash table, 30 of the main logic, and a little test thing (more useful if you change the XXX 1024 to 2). Only minimal error checking is done and interning `""` may not work and several things should probab

Redis - how to select database

if you're using : import redis let r = redis.open() let database = 5 r.select(database) Run

Installation and configuration of the Nim language

https://nim-lang.org/install_windows.html

Installation and configuration of the Nim language

Hi please, i just discovered this nim programming aguage, and i need you to help me install and configure

Defects and CatchableErrors

No, I don’t think so. This works (without --panics:on: of course): var x = 0 try: echo 1 div x except DivByZeroDefect: echo "ok" Run

Redis - how to select database

Hi import redis in python - def __init__(self,host,port=6379,db=0): in nim - proc open(host = "localhost"; port = 6379.Port): In python and other bindings you can select the database as well as the host and port. Can this be done with Nim and Redis? Seems to not be available. Thanks Murray

How to kill a process and all of its descendants in Nim?

you can kill all processes that share a PGID with `kill(-pgid,SIGTERM)` or all processes that share the same PGID as the current process with `kill(0,SIGTERM)` so `kill(0, SIGTERM)` (or `kill(-1 * getpgid(0),SIGTERM)` ) will kill the parent and all the children immediately, even if sent from a c

Defects and CatchableErrors

Is that really true? In C/C++ one can "install" handlers for such hardware interrupts.

How to kill a process and all of its descendants in Nim?

I replicated the following code from a python program to nim to create processes via fork. But how to do to kill all processes (parent and child's) at once? import posix import os proc parent_child(p = 0) = while true: echo "Process: ", p sleep(100

Composing templates / macros?

also, don't forget that Nim lets us define custom setters transparently, which might obviate all of the above. i.e. proc `set_health=`(f: var Foo, i: int) = f.baz = i let setbaz = registerGodotField(Foo,set_health, "") #works just like the field access version

Defects and CatchableErrors

`DivByZero` is literally not catchable. This is a check that Nim does before actually dividing when checks are on. If you divide by zero your CPU will send a signal and your OS will abort your program with SIGFPE and you cannot do anything about it.

Composing templates / macros?

`{.inject.}` is the answer yes. here's @Hlaaftana's answer with a template instead: : template op1: untyped = a + b template op2: untyped = a - b template run(op:string): untyped = proc myFunc(a{.inject.}:int, b{.inject.}: int): int = when op == "plus"

How to access command line parameters under the JS backend

While I'm usually against JS specific code in "native Nim", in this case I encourage such a PR too.

How to access command line parameters under the JS backend

I would support a well written PR that adds `paramCount`, `paramStr` to -d:nodejs (see also )

hotcodereloading and libfswatch

please try to find a minimized reproducible example and file a bug :) (minimizing as much as possible)

Defects and CatchableErrors

Yes, indeed, you should test for zero yourself.