Socket questions. selectRead(fds), dispatcher.

In an attempt to detect clients closing their side of the SSE connection I use selectRead(fds) on the specific handle. When the connection is alive the result is 0, i.e. can't be read. When the client closes the connection the result is 1. I have a hard time reasoning about this. Lack of knowled

Thoughts on pure Nim api for SPI & I2C device access?

Prefixes are for C, idiomatic Nim doesn't use them. > I'm still a bit unclear what the best(preferred?) technique is in Nim for > defining a generic API that different packages can implement. While you can use concepts for that, I usually use pretty much "interface by convention". The modules a

Nim 1.6.0 RC1

@zahary thank you for the explanation!

Thoughts on pure Nim api for SPI & I2C device access?

Hey all, I've been tossing around the idea creating a "Nim-ified" API for SPI & I2C device access. Ideally this would be "cross-platform" API targeted for generic devices similar to Arduino's Wire.h or SPI.h. Any other thoughts people would have on a good API to start from? I know there's a coup

Nim for Beginners #26 Reference Objects

This disregards any of the semantic differences between pointer objects and value objects. Plus if you want an api that changes where a reference points you still need var parameters. The reason you use value types instead of reference types is that you want their semantics. There is more to obj

Nim for Beginners #26 Reference Objects

> The other point is, that you said that for references we do not need the var > keyword when passing data to procs -- we can modify the fields of object > passed as references always. Well, beginners may be confused: Is the most > significant advantage of references that we don't have to type t

--gc:orc when is it usable (huge compile times)

Yes, your code compiles with `--gc:orc|arc` in version 1.4.8.

FieldPairs iterator

OK, then I was very wrong, my guess after some thinking was that the frame may indicate new stuff for the upcoming release.

FieldPairs iterator

> For the first overloaded iterator on that page my Firefox browser shows a > frame built of red dots around it. Has this a special meaning? It means: the URL you're on points exactly to the thing inside of that frame. Try clicking on some other links to see it in action.

Nim 1.6.0 RC1

Communication issue aside, sounds like a `nimble install --link` that replicate the old `nimble develop` would solve most of the issue. The new `nimble develop` sounds really appealing honestly, I think once people get used to it it will be an improvement.

FieldPairs iterator

I was considering using the FieldPairs() iterator, one one them, for the first time. First question is: For the first overloaded iterator on that page my Firefox browser shows a frame built of red dots around it. Has this a sp

Nim 1.6.0 RC1

Trying to sum it up: 1) This change in the behavior of `nimble develop` favors the more complex use case described by @zahary (multiple devs, multiple packages in development) over the simpler use cases described here by single developers. The latter now have to add `.develop` files and must pr

Nim for Beginners #26 Reference Objects

You get a shortcut regardless.. let x = (ref Foo)(a: ...) Run

Nim 1.6.0 RC1

> Seems like 1.6 will be shipped with previous version of nimble > We rolled it back for the time being but ideally 1.6 will ship with a new Nimble where we sorted out its ... teething troubles.

--gc:orc when is it usable (huge compile times)

Does it compile with the `--gc:orc`, as well?

--gc:orc when is it usable (huge compile times)

This compiles on 1.4.8

nimja; compiled and statically typed template engine (like twig or jinja2)

Nice , new template engines are rare to see these days since that part is done at clientside mostly, thanks to SPA Trend. But I still find serverside , client code generation does make development work done alot faster than developing SPA with gazllion of javascript frameworks. I think its still

Nim 1.6.0 RC1

> Nimble is responsible only for the creation of a nim.cfg file that points to > the correct location of the installed packages with the standard --path: > option of the compiler (this is done by running nimble setup once within your > project). >From

Nim 1.6.0 RC1

> If it is executed in a package directory it adds cloned packages to the > special nimble.develop file. This is a special file which is used for holding > the paths to development mode dependencies of the current directory package. > It has the following structure: >From

Nim 1.6.0 RC1

> What nimble develop is going a way? It's is like the best thing about nimble. > How do I develop 20+ packages all related in some way? `nimble develop` is not going away. It is enhanced with new features that precisely try to make it more practical to work with a large number of develop mode

--gc:orc when is it usable (huge compile times)

Thanks to all! The `--verbosity` flag shows some `not GC-safe` warnings which I don't understand. Terminating the Nim compiler (in gdb) gives the following trace back Program received signal SIGINT, Interrupt. 0x55be8afc in hash_injectdestructors_188 () (gdb) where

Article on writing hacking tools in Nim

I wanted to know more information about hackers, so I read online this information about a hackers list. The hacker's list services are for people who want to keep their hacking activities private but still want a way to get around the restrictions placed on other lists, such as realists created

Nim 1.6.0 RC1

Seems like 1.6 will be shipped with previous version of nimble

db_sqlite prepared statement

> That's useful for some modules, but others ... didn't age all that well. as a comment on age... Regarding the Nim release cycle, Nimble/Batteries for wrapped libs and experimental? just thoughts, not for discussion in this thread.

JsonNode should be Any

> Using types in this case is just overkill and waste of effort, as most of the > time it's one time experiment. That doesn't match my experience at all fwiw, I find types just as useful for "quick'n'dirty" code. Dynamic typing kills productivity, try more static typing.

JsonNode should be Any

Any <-> JSON/XML/YAML can be implemented using compile-time introspection and serialization, see treeform/jsony for example. nimyaml also allows to unmarshall objects to and from. At the same time, solving this problem in general is hardly possible, becau

JsonNode should be Any

I frequently use JsonNode as a container for Any object. Another use case is how it's used for JSON, YAML, XML, etc. formats. Right now every such library had to create its own object mapper. While it would be much easier if `std/any` provided the `Any <-> Nim` conversions, and the custom libra

db_sqlite prepared statement

> Looking at all the other libs though, most of them are promoted as 'thin', > where I think that Nim as well "the most used" lib both deserve a wrapper > that covers everything and where appropriate with a fair amount sugar (as a > standard library). FatSQLite! That should done as a separate N

Nim 1.6.0 RC1

> For example we could roll-back the Nimble version that we ship with 1.6. This would be a preferred solution, since features like this have to be discussed on RFC level, and it takes time. See no reason why we should be delaying release of the language for weeks because of the "lockfiles PR" i

Nim 1.6.0 RC1

Though old nimble develop is literally a convoluted wrapper for symlink

Nim 1.6.0 RC1

> It sounds like creating a workspace.develop or nimble.develop in a parent > directory would support that workflow? And creating nimble package for every single small script that I compile, yes. `nim c` does not understand new develop configurations, and it should not, `--nimblePath` is dumb b

Nim 1.6.0 RC1

> In other cases new workflow must be beneficial, but it is still very > surprising that feature of this scale has been added without an RFC process, > let alone replacing older one. This has been mentioned on > (last > part

Nim 1.6.0 RC1

> I often test my own packages in a separate files that are not part of any > project - for various examples, while trying to cleanly debug things and so > on. If I understand correctly, new develop mode is fundamentally unable to > support this workflow without creating a new project and runnin

Nim 1.6.0 RC1

If we are willing to play with fire (old `nimble develop`), then let us. Don't take away our lighters just because **you** think it's a bad idea.

Nim 1.6.0 RC1

I often test my own packages in a separate files that are not part of any project - for various examples, while trying to cleanly debug things and so on. If I understand correctly, new develop mode is fundamentally unable to support this workflow without creating a new project and running everyt