Implicit line joining rules

We should do this: > parser should accept parenthesized (unambiguous) multiline expression

Visualizing Garbage Collector Algorithms (2014)

Ran into this old post visualizing garbage collector algorithms and thought to share here. It would be nice to see visualizations like these for Nim! /

Use proxy and ports httpclient

I tryed that but it give my an other error /home/gabriel/Bureau/NIM/nimtrogen/test.nim(7) test /usr/lib/nim/pure/httpclient.nim(1095) getContent /usr/lib/nim/pure/httpclient.nim(1090) get /usr/lib/nim/pure/httpclient.nim(1066) request /usr/lib/nim/pure/httpclient.nim(1

The `db_postgres`, distinguish "" from NULL

Iirc you cannot distinguish NULL from "" in the `db_` modules and have to use other Nimble packages instead. There is "Norm", "Ormin" and others.

How to catch DOM exception in Nim code?

When targeting the JS backend I want to catch the JavaScript DOMException "A network error occurred.". So I tried: var httpRequest = newXMLHttpRequest() try: httpRequest.open("GET", cstring"http://ireallydontexist.org/";, async=false) httpRequest.send

sendfile over ssl

the way it works, broadly, is: you do the handshake with whichever ssl lib, then pass the encryption key to the kernel, which allows you to use the standard [sendfile](https://man7.org/linux/man-pages/man2/sendfile.2.html) call. This is a platform-specific thing, [here](https://www.kernel.org/d

The `db_postgres`, distinguish "" from NULL

be careful - PostgreSQL's behaviour differs from Oracle : an empty string is not null there (same as in SQLServer)

Implicit line joining rules

> but it's not a good style. I disagree. Because the standard in mathematical typesetting is to write: r = 1 + 2 Run rather than: r = 1 + 2 Run

The `db_postgres`, distinguish "" from NULL

Is there a way to distinguish Empty String from NULL in `db_postgres`? The docs mention that """... NULL database values will be converted to nil ...""", but it seems like it's not always working. In the example below there are 2 strange things: * The definition of column doesn't indicate if

sendfile over ssl

os `sendfile` provide zero copy send file directly to socket, the openssl lib provide `SSL_sendfile` interface , I dont know how `SSL_sendfile` works internally, for others ssl lib how to do sendfile efficiently？for example chronos's dependency `bearssl`

Tabulation symbols not allowed

> I have done my best not to say which I prefer. The reason is that it doesn't > matter If it doesn't matter as you say, then why rant about it ? Choose one,and be done with it. Consistency across codebase is more important than the space vs tabs debate.

Get column names for `db_postgres`?

It is efficient.

Get column names for `db_postgres`?

It works, thanks! One more question, does querying column names has overhead? Like would the driver returns both column names and results in single query, or it does two queries, one to get column names and another to get results? If anyone else needs this: import postgres, db_pos

Sequences, Type Inference, and Inheritance... I am slightly lost.

To put it another way, borrowing a geneaological term: when initializing a seq with a set of inheritable types, the resulting type will be that of the most recent common ancestor of those types. type Fish{.inheritable.} = ref object RayFinnedFish = ref object of Fish

How to make Nim more popular

There are several ways for Nim to become popular. * You have to exist in social networks, developer websites and on Youtube with lot of tutorial. * Have development tools that allow easy coding, debugging and performance analysis. * On the website: * add a part that exposes the logos o

Get column names for `db_postgres`?

instantRows should provide access to the columns: `iterator instantRows(db: DbConn; columns: var DbColumns; query: SqlQuery; args: varargs[string, `$`]): InstantRow {...}` Here is the example from the db_sqlite var columns: DbColumns for row in db.instantRows(columns, sql"SELE

Sequences, Type Inference, and Inheritance... I am slightly lost.

That actually makes sense. I just also worked out (just before reading your reply) that explicitly converting the first element to the `Resource` type: var app = Application( resources: @[(Resource)food] ) Run Thanks for the help! It actually totally makes se

Sequences, Type Inference, and Inheritance... I am slightly lost.

Please don't convert types that way. Here are three options: Resource(food) food.Resource Resource food Run

Sequences, Type Inference, and Inheritance... I am slightly lost.

I believe the reason is: `@[food]` is a `seq[FoodResource]`, which can **not** be converted to a `seq[Resource]`, since `seq` is an invariant type. `@[food, fuel]` is a `seq[Resource]`, since there's no other option.

Sequences, Type Inference, and Inheritance... I am slightly lost.

You can explicitly convert the `FoodResource` to a `Resource`: var app = Application( resources: @[food.Resource] ) Run

Implicit line joining rules

It is useful to split long ternary operators and long conditionals.

Implicit line joining rules

"It probably shouldn't be prohibited.." \- of course it should (at least it should be prohibited to mention in the reference sources).

Sequences, Type Inference, and Inheritance... I am slightly lost.

Hello all, I can't seem to find an answer to this one, and I'm a little stumped. So I'm reaching out to get a better understanding as to what is happening here. So I'm building a small project which relies on OOP in Nim, and specifically the inheritance aspect. So take for example, I have the

Implicit line joining rules

> Also, it makes sense to allow such code: if false or true: echo(1) Run There's a reason grammar/style guides of many natural languages dictate putting punctuation and conjunctions before a line break. It probably shouldn't be prohibited, but it's not

Tabulation symbols not allowed

> The bottom line is this. Compilers were originally created to bridge human > readable text and machine language. Every compiler has been written to > improve this bridge. In other words, compilers are designed to make coding > easier for the coder, not the computer. Clearly you haven't seen t