Re: Introducing --gc:arc
> "gtkmm" which is a C++ wrapper and I'm quite sure it uses C++ destructors. That is a fine hint. I don't know much about gtkmm, so I am not sure if they really use C++ destructors or just plain gtk internal ref counting as C does. Will ask Mr E.Bassi at gtk forum. Found comment of mratsim: [https://forum.nim-lang.org/t/4797#30036](https://forum.nim-lang.org/t/4797#30036) > Shouldn't context stay a ref object? It's not a type that you can trivially > copy (i.e. it's a resource like memory, a socket, a file handle, not an > integer or string). My impression was that Destructors works best for stack objects. But I can imagine that with Destructors one theoretically can write a custom memory management system which supports some form of GC_ref(), then it may work for gtk. > finalizers are attached to the "new" call which sucks; Interesting, other people said that in the past too. I think finalizers attached to the types would be fine for gtk.
Re: Introducing --gc:arc
> Will this become default and if so when? I hope it reaches production quality in a couple of months and we can make it the default. I haven't used it myself but I had [https://github.com/status-im/nim-json-serialization](https://github.com/status-im/nim-json-serialization) in mind.
Re: How Can i compile nim code as a lib.so and use it in C code ?
you need to add dynlib prama too, and compile with \--app:lib option. more details [here](https://nim-lang.org/docs/manual.html#foreign-function-interface-dynlib-pragma-for-export)
Re: Introducing --gc:arc
Will this become default and if so when? > Ever since we added macros.getType we had more efficient ways to produce > serialization code, it's not a big loss (IMHO, I never use it), there are > also third party modules that do what marshal.nim does, but better. I am using marshal myself, which modules do you recommend switching to?
Re: Introducing --gc:arc
Just tested [https://github.com/StefanSalewski/cdt](https://github.com/StefanSalewski/cdt) That one is indeed not really tested yet, so I did not make a nimble package out of it to not pollute the nimble database. And it is again a bit complex. # with import fix: import dt, vectors, edges, types /tmp/cdt/src/cdt $ nim c --gc:arc test0.nim Run /tmp/cdt/src/cdt/edges.nim(15, 15) Warning: 'q.e[0].next = q.e[0]' creates an uncollectable ref cycle; annotate 'next' with .cursor [CycleCreated] /tmp/cdt/src/cdt/edges.nim(17, 15) Warning: 'q.e[2].next = q.e[2]' creates an uncollectable ref cycle; annotate 'next' with .cursor [CycleCreated] Run Crash with /tmp/cdt/src/cdt/vertices.nim(6) newVertex SIGSEGV: Illegal storage access. (Attempt to read from nil?) Run I have to learn what the warning means, maybe I will get it working then. Tomorrow I may test [https://github.com/StefanSalewski/minmaxheap](https://github.com/StefanSalewski/minmaxheap) but that one is so trivial that I am sure that it will work. Final note: RTree is fine indeed, I am using it already -- without --gc:arc
Re: Introducing --gc:arc
> Second, what does arc in Nim mean for us mortals? Will compiling or running > programs become faster? Easier to debug, better latency, less memory consumption, better multi-core support. > Will we have to use a different mechanism to get type information now that > typeinfo is unavailable with arc? Is this information going to be different? Ever since we added `macros.getType` we had more efficient ways to produce serialization code, it's not a big loss (IMHO, I never use it), there are also third party modules that do what `marshal.nim` does, but better. > Will we have to use new language constructs like sink and lent, whatever they > mean? You don't have to use them but they also improve the clarity of the code, I don't consider them hacks to gain more speed. `lent T` means "I'm providing a readonly view into the data I'm owning" (get, [] accessors), `sink T` means "I'm storing the passed data permanently in a collection". > Is this a huge change for Nim under the hood or is just yet another gc option? It's a huge change under the hood and also "yet another gc option". For now. I hope to make it the only "GC" that survives in the long term.
Re: Introducing --gc:arc
> That test is also part of our test suite and is so complex that it doesn't > run on 32 bits, nor in C++ I was not aware that it is in test suite. But I was aware that it does not compile with C++, and that nimsuggest has big problems with it. Will try to investigate which problems with 32 bit may occur, that may be a bug of mine. gintro with destructors, that seems to be nearly impossible. We discussed that years ago when destructors became available for Nim, mratsim was involved. The main problem is, that we can pass objects to gtk lib, and can GET BACK the same object later. For example a widget in a grid container -- we create a widget, put it into grid container, forget it, and get it back later, maybe put it into another container then. That seems to be really a hard problem, and people will expect that this works. Maybe we could disallow it, but it is a serious restriction. I think that is not only a restriction for gtk, maybe for libs like CGAL or BOOST too, where we may intent to store objects in data structures of that lib, for example edges and vertices in a spatial triangulation data structure. (Maybe there are solutions, we may not use refs, but id numbers for access.) > I was surprised that GC_ref() compiles with --gc:arc type O = ref object i: int proc main = var o = O(i: 7) GC_ref(o) echo o.i main() Run Of course gc:arc is great, I like the deterministic memory management. For native Nim libs it should work fine.
Re: Introducing --gc:arc
> The RTree test.nim from > [https://github.com/StefanSalewski/RTree/tree/master/tests](https://github.com/StefanSalewski/RTree/tree/master/tests) > compiles but running the executable gives an assertion error. Funny. That test is also part of our test suite and is so complex that it doesn't run on 32 bits, nor in C++ mode nor could it be "joined" into our larger test. So I'm not blaming ARC for its failure, IMHO it never actually worked. :P > Unfortunately gintro apps seems not to compile, seems that finalizers are not > supported. I said that in the beginning and also what to use instead. > But without finalizers support -- again no idea what I could do. Read it again. Or look at the current implementation of `re.nim`.
Re: Cannot build old project - TChannel problem
Thanks a lot, it compiles with Channel.
Re: Introducing --gc:arc
Did just a first test. The RTree test.nim from [https://github.com/StefanSalewski/RTree/tree/master/tests](https://github.com/StefanSalewski/RTree/tree/master/tests) compiles but running the executable gives an assertion error. Funny. Unfortunately gintro apps seems not to compile, seems that finalizers are not supported. I expected that gintro would not work with newruntime because GC_ref was not available, but had some hope for ARC. But without finalizers support -- again no idea what I could do.
Re: Cannot build old project - TChannel problem
You may look for available symbols at [https://nim-lang.org/docs/lib.html](https://nim-lang.org/docs/lib.html) I think most P and T prefixes have vanished, was a legacy from Pascal notation. Channel is available, TChannel not, so I assume TChannel is replaced with plain Channel.
Cannot build old project - TChannel problem
Hello, I'm trying to build an old project, created with 0.11.2 version, using Nim 1.0.2. I'm blocked with the following error: Error: undeclared identifier: 'TChannel' I'm using the following options to build the project: \--threads:on --opt:none --debuginfo --gc:markAndSweep| ---|--- How can I solve the problem? Is TChannel deprecated?
Re: Introducing --gc:arc
First, congrats! Seems like an important milestone, even if there's much to be done ahead. Second, what does arc in Nim mean for us mortals? Will compiling or running programs become faster? Will we have to use a different mechanism to get type information now that typeinfo is unavailable with arc? Is this information going to be different? Will we have to use new language constructs like sink and lent, whatever they mean? Is this a huge change for Nim under the hood or is just yet another gc option? Thanks, and Merry Christmas!
Re: Error converting json to types
BSON uses Extended Json (v2); and BSON does have a UTC Time/Date function.
Granted, it converts to Time rather than DateTime. BSON also has marshalling
support to/from objects.
If interested in that:
[https://nimble.directory/pkg/bson](https://nimble.directory/pkg/bson)
Example of use with objects:
import json
import times
import bson
import bson/marshal
type
MyType = object
cannonicalDate: Time
relaxedDate: Time
marshal(MyType)
let example = """{
"cannonicalDate": {"$date": {"$numberLong": "1567367316000"}},
"relaxedDate": {"$date": "2019-08-11T17:54:14"},
}"""
let parsedJsonDoc = parseJson(example)
let bsonDoc = interpretExtendedJson(parsedJsonDoc)
var exampleObj = MyType()
exampleObj.pull(bsonDoc) # this applies the BSON to the object
assert exampleObj.relaxedDate.format("-MM-dd\'T\'HH:mm:ss", utc()) ==
"2019-08-11T17:54:14"
Run
But, this does not solve the original poster's problem if the JSON he receives
is not ExtendedJSON compliant.
As to modifying the library, IMO Araq is correct, since JSON does not support
dates, putting such support into the standard library would be improper.
Someone could write a nimble support library though.
Re: Error converting json to types
(disclaimer: I'm the author of BSON)
Re: Distinct for indices, is it good library Api?
In the end, I think, it makes no sense to write an 1:1 port of petgraph, I will do a library that is usable at least by a noob (me). I think its best not to export `EdgeIndex` and keep edges private, if the weight must be updated, updateEdge is available, findEdge though will be private. Removing nodes and edges invalidates the last indices, so I won't implement it.
Re: Distinct for indices, is it good library Api?
Now I get it thanks, I've seen a couple of ways to model an adjacency list, but I think this must be the most efficient. Actually it models a doubly linked list with indices, there is no need for a seq, it has no limitations. You can see how the example at the end represented in memory, take a look at the commented output.
Re: Introducing --gc:arc
It's explained here [https://github.com/nim-lang/RFCs/issues/177](https://github.com/nim-lang/RFCs/issues/177), a bit.
Re: Distinct for indices, is it good library Api?
Nice idea, thanks! I also tried converters (like the original library does) but it failed to compile. will submit a bug report
Re: Distinct for indices, is it good library Api?
> What do you mean? If I understand correctly, you defined the Node with information of incoming / outgoing Edge type Node*[N] = object ## The graph's node type. weight*: N ## Associated node data. next: array[2, EdgeIndex] ## Next edge in outgoing and incoming edge lists. Run This way, you only have 1 Edge for each, 1 for incoming and 1 for outgoing. Unless your graph specifically only as a one line flow, a node should be able to have several nodes incoming and outgoing but you only defined it as an array of two Edge member. If it's seq, you can add it later based on new graph connection or any info. Simply changing the definition into seq should somehow solve the limitation of current definition. But since it's in development phase, you would recognize it the more you develop it, that's why I mentioned "will be unused". CMIIW
Re: Distinct for indices, is it good library Api?
Why not overload procs like fromEdges to accept pairs of integers?
Re: Distinct for indices, is it good library Api?
> The array of two nodes index for incoming/outgoing will be unused the more > you add APIs to your graph. What do you mean by this?
Re: Introducing --gc:arc
> Correct, it's very close to how C++ works. This is awesome then! Can’t wait to try it :-) Can you explain what the .cursor pragma does and how it must be used?
Re: What is the meaning of this C code ?
Thanks for the reply.
Re: Object Variants and redefinition of labels or reusbility of field names
I would just create 26 different types and make conversions between them? There is no need to stuff everything into a single type... I do this with Chroma: [https://github.com/treeform/chroma](https://github.com/treeform/chroma)
Re: How to check if a proc has no return type?
You can use the compiles special function to do a ton of this work:
[https://play.nim-lang.org/#ix=25sG](https://play.nim-lang.org/#ix=25sG)
proc echo2(s: string): string = ""
template returnsVoid(f: untyped): bool =
compiles:
let v = f
echo returnsVoid(echo(":)"))
echo returnsVoid(echo2(":)"))
Run
false
true
Run
How to check if a proc has no return type?
This approach doesn't compile:
echo echo(":)") is void
Run
{.global.} in global scope
What does the global pragma do the way it is used
[here](https://github.com/Araq/ormin/blob/master/examples/forum/forum.nim)?
import "../ormin/ormin", json
importModel(DbBackend.sqlite, "forum_model")
var db {.global.} = open("stuff", "", "", "")
...
Run
Re: Distinct for indices, is it good library Api?
IMO, It's not worthy to make it distinct, moreover, you should use generic instead of int for nodes label. Unrelated to the question, you should keep the Node definition is literally as a node, and keep Edge definition is the connection from Node1 and Node2. The array of two nodes index for incoming/outgoing will be unused the more you add APIs to your graph.
Re: What is the meaning of this C code ?
`WNDCLASSEX` must be a struct whose first field is numerical, and `={0}`
initializes it to 0. [You can read about this and more on this
page.](https://en.cppreference.com/w/c/language/struct_initialization)
What is the meaning of this C code ?
Hi all, I would like to know what is the meaning of this C code.
WNDCLASSEX wcx={0};
Run
All i can understand is, this line declares an instance of WNDCLASSEX type
variable. But i can't understand the "{0}" part. What is it ?
Distinct for indices, is it good library Api?
Hi and merry Christmas,
I was trying to port [petagraph](https://github.com/petgraph/petgraph) rust
library to nim and although I made some
[progress](https://gist.github.com/b3liever/de2d4e2267b13832f7d52f10ba3140fe) I
am struggling with some fundamental decisions.
for example, when adding a node in the graph, it returns the index:
var graph: Graph[string, float]
let nodeA = graph.addNode("a")
let nodeB = graph.addNode("b")
let nodeC = graph.addNode("c")
let nodeD = graph.addNode("d")
let nodeE = graph.addNode("e")
let nodeF = graph.addNode("f")
let nodeG = graph.addNode("g")
let nodeH = graph.addNode("h")
# Also returns the edge index when adding an edge, not sure if its useful
let edge1 = graph.addEdge(nodeA, nodeB, 1.0)
Run
These indices are `distinct` types like so:
type
IndexType = int
NodeIndex = distinct IndexType
EdgeIndex = distinct IndexType
Run
That allows to have array element access syntax for nodes and edges:
proc `[]`*[N, E](self: Graph[N, E], a: NodeIndex): N =
## Access the weight for node `a`.
self.nodes[int(a)].weight
proc `[]`*[N, E](self: Graph[N, E], e: EdgeIndex): E =
## Access the weight for edge `e`.
self.edges[int(e)].weight
# works like so:
echo graph[edge1] # 1.0
echo graph[nodeA] # "a"
Run
And this was the only benefit I think there is with `distinct` indices,
consider this code:
import graph, sequtils
let graph2 = fromEdges[int, int](mapLiterals(@[
(0, 1), (0, 2), (0, 3),
(1, 2), (1, 3),
(2, 3)], NodeIndex))
Run
becomes tiresome to write, since everything needs to converted to the correct
`IndexType` subtype. Also the internal code is littered with
`self.nodes[int(nix)]`. My question is does it worth it, or should I just use
int everywhere?
Re: Introducing --gc:arc
> Just to make sure I'm not confused - there are no changes to the source code > needed, though "sink" and "lent" annotations do provide optimization? Correct. > And it's independent of the bacon/dingle "owned" system (and is b/d going to > stay or is it deprecated and going away?) It's independent of it but the `owned ref` idea is still very useful and will find its way, somehow. Both `--gc:arc` and `--newruntime` are implemented with the same technology, fixing a bug for `--gc:arc` most likely also fixes a bug for `--newruntime`. > In what way does "async" need to be ported to arc? Is it just a performance > thing, a cycle thing, or is it a deeper issue? On Unix I got the async tests to work but it leaks memory, probably because of cycles. On Windows I got crashes instead for yet unknown reasons... It's hard and takes time, but the number of bugs is finite, right? ;-)
How Can i compile nim code as a lib.so and use it in C code ?
Hi! iam traying compile this code as a lib.so to use it in C code
**lib.nim**
`proc fib(): cstring {.exportc.} = return "Hi From Nim"`
how can i do it ?
Re: Introducing --gc:arc
Just to make sure I'm not confused - there are no changes to the source code needed, though "sink" and "lent" annotations do provide optimization? And it's independent of the bacon/dingle "owned" system (and is it going to stay or is it deprecated and going away?) In what way does "async" need to be ported to arc? Is it just a performance thing, a cycle thing, or is it a deeper issue?
Re: Introducing --gc:arc
> For example, if I create a local seq or string variable on a procedure A, and > that variable is only used within that procedure A or at most is used by > procedures called within that procedure A, will it’s memory be freed > immediately when the procedure A is done (and before other code is executed)? Correct, it's very close to how C++ works. > That is, are there separate, non deterministic garbage collection events? Is > this suitable for embedded, hard real-time code? Yes, embedded, hard real-time code is supported and was a design goal. There are no separate GC events. > Also, does this require anything that is not in nim v1.0? It adds a `.cursor` pragma that v1.0 can emulate via the `ptr T` type. Everything else is in the language spec for v1.0, but the implementation is in the Nim development branch. You need to get a nightly build to get it.
File and directory structure for a hybrid project
I have a project that consists of a library (that will be split over several files but will have a single file as its entry point) and an executable that uses the library but which doesn't share its name. At the moment I have this layout: src/myexe.nim src/mypkg/mypkg.nim src/mypkg/support1.nim Run but when I run `nimble test` I get a warning about the structure. So, what should the structure be?
Re: Introducing --gc:arc
This looks awesome! Can you give more info on what you mean when you say that this new GC will provide a “deterministic memory management”? For example, if I create a local seq or string variable on a procedure A, and that variable is only used within that procedure A or at most is used by procedures called within that procedure A, will it’s memory be freed immediately when the procedure A is done (and before other code is executed)? I guess my question is if this will behave like a shared pointer in C++ (or perhaps even like a unique pointer in certain cases)? That is, are there separate, non deterministic garbage collection events? Is this suitable for embedded, hard real-time code? Also, does this require anything that is not in nim v1.0?
