Performing goto in Nim

If nothing helps, you could also see if throwing and catching an exception works. In the posted example you could throw an exception at "from here" and catch it at "here we go". But abusing exceptions like this is very bad style and should only be used as a last resort.

Performing goto in Nim

Nim's optimizer does not understand control flow hiding in `emit` and is free to break your program. Instead of goto, use structured programming constructs like `if` and `while` (there is also `return` and `break`). Do yourself a favor and read books about basic programming techniques -- you mi

Performing goto in Nim

Perhaps `{.emit: astToStr(name) & ":;".}` would be safer, in case you're in a place that doesn't allow a label?

cstring has different behavior in different MM mode

The code is invalid regardless of the used mm scheme. It never was correct and `cstring` is always a pointer and `string` always a value type.

Performing goto in Nim

I'll test for it. Thank you!

Performing goto in Nim

You don't need a macro, you can just use a template. template label(name, body) = {.emit: astToStr(name) & ":".} body template goto(name) = {.emit: "goto " & astToStr(name) & ";".} proc main = echo "from here" goto here echo "nowhe

Performing goto in Nim

I've write a macro to do that.

Raises tracking and no more cyclic references in `chronos`

> Be careful though, the cycle fixes in chronos focus on internals as a memory > usage optimization technique first and foremost: you can still create circles > in your own code by accident and suddenly determinism is gone and so are > destructors - de facto you're back in finalizer land - in li

Performing goto in Nim

You can't. As in you can, but only by emitting C code that performs the goto. Depending on your use case, you may want `defer:`, `try:`/`finally:` or `block:`. Read the [manual](https://nim-lang.org/docs/manual.html#statements-and-expressions) for Nim's control flow options.

Performing goto in Nim

How to do goto in Nim ? e.g. echo "from here" goto here echo "nowhere" here: echo "here we go" Run

Raises tracking and no more cyclic references in `chronos`

The manual says literally: > The current implementation allows to switch between these different behaviors > via --panics:on|off. When panics are turned on, the program dies with a > panic, if they are turned off the runtime errors are turned into exceptions. The implementation does not contrad

Raises tracking and no more cyclic references in `chronos`

> Though I will say I’ve seen a lot of Rust code that just “panics”, which is > even worse IMHO. rust panic = Nim `Defect`, more or less: it's a design choice of the author of a library when trigger them (sort of), they can both "mostly" be caught, but in rust you have a dedicated mechanism for

cstring has different behavior in different MM mode

Maybe there should be a collection of “gotchas” like this?

cstring has different behavior in different MM mode

as we know, string in nim is value type, but i do not know the type of cstring. so i wrote a snippet: var y = "abc" let z = cstring(y) y.add("d") # when mm:arc # assert y == "abcd" # assert z == cstring"abc" # when mm:refc assert y == "abcd"

Anyone working on a new Nim book or second edition of Nim in Action?

Great! Looking forward to it. Please consider offering EAP access before it's finished.

Anyone working on a new Nim book or second edition of Nim in Action?

Thank you. Will check it out soon.

Embedded STM32 - Bare Metal Bootstrap

Happy to see more stuff coming out that could bring aware to Nim as a viable tool for embedded software! Personally, video tutorials are not really my thing, but some people do enjoy them. I think most youtubers try to aim for 10-ish minute videos though, maybe cut it up in 2-3 parts next time?

To prompt one character input only

Must press enter: stdout.write("Enter x to exit ") let ch = stdin.readChar() echo ch Run Without enter: import terminal stdout.write("Enter x to exit ") let ch = getch() echo ch Run

Fidget UI: scrolling on OpenGL backend

How much work would it be to move from "immediate mode" UI to an event based solution? Ideally fidget would support both modes equally well, but I have no idea how hard would this be. Anyway, the lack of a business-compatible event-based model keeps me from fully exploring Fidget. And that's ver

Raises tracking and no more cyclic references in `chronos`

> But it’s not clear how to catch all possible defects including odd ones like > int overflows. `try ... except: ...` does the job. It catches overflows too. With `--panics:on` it doesn't, so use `panics:off` which is the default anyway.

Anyone working on a new Nim book or second edition of Nim in Action?

I'm writing a book but it's probably too early to even talk about it. :-)

linux moving to C11

Linus is famous to blame C++ and supporters of C++ for Linux Kernel. Here you can find his arguments about (2007 and 2004). Back in 2004 he didn't seem to trust on C++ compilers too. Nowadays he really seems to still hate C++ and more open to consid

OrderedTable missing Seq methods

For unordered things, `std/sets.HashSet` has an unkeyed `pop` which I use in [suggest](https://github.com/c-blake/suggest), but `OrderedSet` does not. So, these may not be good answers. If order and key sparsity and out-of-the-box table-like operation is truly needed, my generally more full-fea

Fidget UI: scrolling on OpenGL backend

I have noticed that the nim-community seems sort of neutral towards the choice of GUI, which is usually a wise choice. I suppose they have had heated discussions in the past and now want to avoid "this tool is better than that discussions". However in relation to the take-up of Nim it is relevan

To prompt one character input only

It is possible to use terminal.getch(), but it doesn't show the typed character in the terminal:

To prompt one character input only

How to get one character input just like in Bash `read -n1` ?

OrderedTable missing Seq methods

I'm pretty sure they're suggesting (and that's what I'd suggest too) that you do something like this: type Node[T] = ref object payload: T parents: seq[T] children: seq[T] var graph: seq[Node] Run Then you don't need any kind of t