Re: Python transpiler
Fully automatic translation seems (almost?) feasible if you map every value to a JSON-like universal type, say PyObject. Then you would have super-non-idiomatic Nim code but you can gradually rewrite it to use more of Nim's static typing and native types.
Re: Python transpiler
Well we can try to learn the lessons from [https://github.com/metacraft-labs/py2nim_deprecated](https://github.com/metacraft-labs/py2nim_deprecated) * Python code is more dynamic than it looks and even your code doesn't use much of Python's dynamic nature, some of your dependencies do. * py2nim uses a very clever idea: Run the Python code and inspect the types/structures at runtime. Maybe that's too clever, I don't know. In the following section I assume that it is. How would I translate 200_000 lines of Python to Nim? Though nut. I probably would write a Python lexer/parser in Nim and translate a Python AST to Nim by constructing Nim's AST much like c2nim does it. Inside py2nim I would try to detect _project specific_ patterns to make the Nim more correct until it's close enough that manual editing of the remaining glitches becomes feasible.
Re: Experimenting with a FreeRTOS OS Port
> So it's a pain to rebase... Anyone know what's required to get the base PR > merged? Where is your PR?
Re: Understanding Nim compiler
> Is there a wish to build a compiler's internals documentation or is it a > knowledge that lives in the compiler hackers' minds? Well we have the internal documentation and we're always accepting PRs but I generally assume that compiler contributors have read some book about compiler development, there are good ones available like [https://people.inf.ethz.ch/wirth/CompilerConstruction/index.html](https://people.inf.ethz.ch/wirth/CompilerConstruction/index.html) > What are the important internal data structures? It's ASTs all the way down and the compiler's AST is the same AST that is exposed in the macro system. :-)
Re: Question about move semantics for objects and seqs
> Case 2. Overloading for optimization, to avoid copy/reuse buffers we can have > 2 versions of a procedure, one with sink and one without, for example That's not supported by Nim and so far I haven't seen convincing examples. If you want to take over ownership, you always want to leaving you with the sink T version only.
Re: Understanding Nim compiler
Well if you want to know why something works for procs and not for templates, look at the different handling of `skTemplate` inside `sigmatch.nim` and elsewhere. Looking at the AST is pointless, no matter how much you look at it and under which views and wether it's the AST for the proc or for the full module and whether it's the AST after parsing and before sem'checking or after sem'checking.
Re: now().utc fails with --gc:arc
Please report issues on github so that we track their progress.
Re: File not found error EVERY TIME
Try `cmd.exe` and not bash.
Re: File not found error EVERY TIME
Run `finish.exe` please and install GCC via it.
Re: Introducing --gc:arc
Interesting, did you compile with `-d:danger --panics:on` ? Also watch out, the allocator now uses 16 byte alignments iirc and for reasons currently unknown to me `-d:withRC` uses much more peak memory than ARC. Also a fun fact: Even without `.acyclic` ORC has the same performance than ARC on this benchmark. For me at least, ymmv.
Re: Introducing --gc:arc
Another major update: On Nim devel destructors are now scope based, not function based. This brings Nim's semantics closer to C++/Rust and is a key enabler for more optimizations. Still left to do: * Bugfixes, as usual. * Better inlining for the generated assignment operators and destructors. * Elide wasMoved+destroy pairs (though a decent C optimizer should do it too for us). Best time for the "binary trees" benchmark on my old notebook: > 12.6s (ARC) vs 12.1s (manual) So there is still room for improvement. :-)
Re: How to do feature detection with JS backend?
Something like: proc newAudioContext*(): AudioContext {.importjs: "new (window.AudioContext || window.webkitAudioContext)()".} Run
Re: Why does wrapping the code in a top level procedure make it faster?
Whenever you leave the C code that Python happens to use like actually looping over an array it's slow. Python is in fact an _abstraction inversion_ , primitive operations are slow and high level operations are fast (because they can avoid Python's slow VM) and so you need to use premade libraries for everything. In Nim it's the opposite, primitive operations are fast and custom code wins over premade libraries quite often because custom code is specialized for the task at hand. **That 's the fundamental lesson to learn when coming from Python.** Surely we can and will improve the rough edges you encountered but it won't change the fundamental lesson.
Re: Why does wrapping the code in a top level procedure make it faster?
Yeah and in fact, I considered such an optimization but with ARC/ORC the effect isn't as big as it used to be so it's better to focus on these.
Re: What's the future of "implicitDeref"?
Good point so probably we should require `ptr T not nil` for auto-deref...
Re: advanced `nim doc` use
The define to use is `when defined(nimdoc)`.
Re: What's the future of "implicitDeref"?
We didn't develop it further as there were unforeseen interactions where `p != nil` would be rewritten to `p[] != nil` or `p != q` to `p[] != q[]` but tbh I don't remember the details. This feature needs to be re-designed. Here is my current proposal: "If overloading resolution in a call using the syntax `a.b` or `a.b(X)` produces no matching candidate for `b`, the expression is rewritten to `a[].b` (or `a[].b()`) and overloading resolution is tried once again" This rule seem to be more consistent with what Nim does for field access and seems to avoid weird feature interaction. If the rule allows for custom overloaded deref operators it would also improve custom smart pointers because these can then be written without `converter` which is an unloved feature of Nim. Will write an RFC.
Re: Nuglifier - Nim source code uglifier
Since I suspect it'll come up: You can compare it to Java public class HelloWorld{ public static void main(String []args){ \u0053\u0079\u0073\u0074\u0065\u006D\u002E\u006F\u0075\u0074\u002E\u0070\u0072\u0069\u006E\u0074\u006C\u006E("Hello World"); } } Run
Re: Procedure overloading with explicit parameters
> magine swapping out Nim's object variants for Rust's enums. I think that > would be an improvement. > > Araq has explained on several occasions why he designed Nim's object variants > the way he did. Well you're both right. :-) The current design has its advantages but Rust's seems nicer. However, Rust's only works with more borrow checking, IMO. I couldn't copy Rust's design for Nim's case objects because back then Rust didn't exist. I knew ML's but ML's works because of its immutability.
Re: New garbage collector --gc:orc is a joy to use.
> Is that the plan? Almost. We need to run the cycle collector before a send already to ensure the thread local "cycle candidates" list is empty (note that it is always empty after a cycle collection), otherwise it would interfere with multi-threading. Alternatively we can make the list global and protected via a lock (or implement it as lockfree queue...). There are many other options, we can also restrict the sending to `.acyclic` types. Or we request that "orphaned objects" that will be misdetected as false external roots to be cleaned up manually. That is a good idea anyhow, ensuring the programmer he still aware of the typology: proc process(x: Node) = use(x.left) # likely invalid: spawn process(x.right) # better: extract it spawn process(move x.right) Run
Re: New garbage collector --gc:orc is a joy to use.
> How will the iso property be checked dynamically? Well, the object's > refcounts will be checked, they all have to be zero (or one, depending of how > we count). Now, the owned ref comes into play. Nah. I mean, you could do it this way, but there is a much better way: You traverse the subgraph. In doing so you could the edges (= E) and sum the RC fields (= S). A graph is sendable to a different thread if and only if S = E + 1.
Re: NvP: s.add('x') 100M times
Nim's strings do a mild form of copy-on-write so that string literals can be copied in O(1). Probably the logic is flawed.
Re: NvP: s.add('x') 100M times
> I think this kicking the tires has probably uncovered a real problem. Indeed, there is a high priority bug lurking here, please keep investigating!
Re: New garbage collector --gc:orc is a joy to use.
> And furthermore, the object you're moving to another thread can't refer to > any other objects that have references on the current thread ... this sounds > like something that could accidentally lead to difficult-to-discover race > conditions if one is not careful! That is correct but we'll have an `isIsolated` runtime check for that. There is also a plan for ensuring this at compile-time via an `islolated:` block. Seems entirely within reach thanks to Nim's effect system.
Re: ok to merge "overload resolution" label into "Symbol Resolution" label in github issues?
These are two different mechanisms, so IMHO it shouldn't be merged.
Re: NvP: s.add('x') 100M times
Huh? Tracing GCs should never win this. Something strange is going on... :-)
Re: NvP: s.add('x') 100M times
Memory consumption is usually _much_ better with `--gc:arc`.
Re: Change Nim colour on GitHub
> I am not sure why since the rst parser seems to support it, maybe it would be > fixed by a forum update or maybe I just did something wrong. Security. You are not allowed to destroy the site's layout. ;-)
Re: NvP: s = s & 'x'
Use `.add` instead. We don't optimize `` s = s & 'x'`` because nobody writes it this way.
Re: sha1, danger vs release builds
We only recently started to care about benchmarking everything against the C code inside Python's implementation.
Re: More fuzz testing
Because `write` collects all the arguments in an array? See [https://nim-lang.org/docs/io.html#write%2CFile%2Cvarargs%5Bstring%2C%5D](https://nim-lang.org/docs/io.html#write%2CFile%2Cvarargs%5Bstring%2C%5D) Reading the docs can beat "fuzzing".
Re: "subsequence" type (like Go's "slice")
> I'm writing code that manipulates portions of seq s, and I keep creating proc > parameter lists that include input: openarray[byte]; inRange: var Slice[int], > and then inside the proc I keep writing stuff like input[inRange.a + i] Er, you can slice with `toOpenArray`, no need for the `inRange: var` stuff. In an ideal world we would have made `a[x..y]` an alias for `toOpenArray`. > I don't believe any of it is 0% complete ;-) We're fixing the "last" bugs for ARC/ORC (ha ha...), work on IC was done by an external developer but it's far from finished. There has been no work done on [https://github.com/nim-lang/RFCs/issues/178](https://github.com/nim-lang/RFCs/issues/178) Sad but true.
Re: Use getenv with js
The error message could be better, of course, but JS has no `getEnv` and Nim's JS target is **not** NodeJS.
Re: Norm 2.0.0
Interesting. Can you outline the learned lessons?
Re: detectOs template in for loop
> But it's actually a tricky problem that might not be able to be solved with > an iteration of Distribution, which is probably why it's not in the stdlib. distros is for Nimble support, for nothing else. Detecting the distro is fundamentally flawed anyway, test for features, not for distros or versions.
Re: Idea: Nim Online Conference
Once again a big "Thanks you" to every speaker, the quality of the talks were high throughout and the fact that every speaker was online during the stream and replied to questions made it even more enjoyable. Coming soon: A hackathon? How to organize one?
Re: Can't install the bin tarball of nim 1.2.2.
You can use `-d:nimEmulateOverflowChecks` for 1.2.0
Re: Experimenting with a FreeRTOS OS Port
There is also [https://github.com/zevv/nimcsp](https://github.com/zevv/nimcsp) which is better suited for embedded development, it deserves more attention and development.
Re: On my first 'greet.nim' I get a C compiler error on RHEL 7
Compile with 1.2.2 and if that fails still, compile with `-d:nimEmulateOverflowChecks`.
Re: Is --gc:arc completely independent from the older ownership model?
> I think you've mentioned Pony elsewhere, though — their approach sounds much > better; transfer ownership of a heap object between threads without actually > having to copy the bytes around. Yes, that's what we're working on.
Re: Is --gc:arc completely independent from the older ownership model?
The move optimizations help but the biggest impact is the fact that Nim's ARC does **not** use atomic reference counting, instead a complete SCC will be moved between threads. It's the atomic instructions that kill Swift's performance, not the refcounting.
Re: Is --gc:arc completely independent from the older ownership model?
I think you should watch my talk at NimConf.
Re: When will the NimConf timeline get posted?
We're scheduling the talks today and will contact the speakers and update the website afterwards. Sorry for the delay but just today we received 3 more talks.
Re: Is --gc:arc completely independent from the older ownership model?
Well I can only describe how arc works and I can assure you that Rust/Lobster work very similarly and none of these languages have "compile-time reference counting", strictly speaking. Nim's integers, floats, enums, bools and objects of these and arrays of these _always_ are "value" based types. And always have been. They are embedded into the host container. They are not necessarily allocated on the stack (though usually they are), for example: type O = object a: array[2, int] proc main = var x = (ref O)(a: [1, 2]) # aha! we have an array here! and it's not allocated on the stack! Run `a` is directly _embedded into_ the `O` and we put it onto the heap. The `x` itself is stored on the stack and it points into the heap. Now the question is: When is the block inside the heap freed? Under --gc:arc/orc it's always at the end of `main`. Under the other GCs it's "you don't know". That is true for C++ shared_ptr, unique_ptr, Rust's equivalents and whatever Lobster's name for these things is. Why is that? Well there is one pointer to the `ref O`, it's a _uniquely_ referenced memory cell. Now let's make this program more complex: proc main = var x = (ref O)(a: [1, 2]) var y = x Run Now we have 2 references to `ref O`. When it is freed? Still at the end of `main`. Why? Because that's how reference counting works. What's the point of move semantics then? It makes the assignment `var y = x` cheaper by exploiting that `x` isn't used afterwards. Does this affect "deterministic" memory management? No. Ok, so about this example: proc construct(p: int): ref O = var x = (ref O)(a: [1, 2]) if haltingProblem(p): result = x else: result = nil proc main = let x = construct(12) Run When is the `ref O` object really freed? Well it depends on a halting problem, either it's freed right after `construct` or after `main`. Why is that? Because unique pointers are really a 1 bit reference counting system. Note how even uniqueness doesn't help all that much with "deterministic" memory management because the uniqueness means "0 or 1" and not "always 1". However, in practice, if you do a minimal amount of testing or reasoning about your code, the runtime profile of your code remains analysable. That's true for both classic reference counting like C++'s shared_ptr and Rust's 1-bit reference counting or various schemes in between where you optimize away more and more RC operations ("compile-time reference counting"). So why is this "better" for "hard realtime" systems than classical tracing GC algorithms or copying GCs or Jamaica's hard realtime GC? It's better in the sense that it attaches a simpler _cost model_ to a program where some modularity is preserved. Your subsystem allocates N objects on the heap? The costs are N deallocations when the subsystem is done, regardless of other subsystems in your program.
Re: Is --gc:arc completely independent from the older ownership model?
> Are these things completely unrelated? They are related, --gc:arc is the evolution of `owned ref`. > So what will happen to ownership? It is outlined here, [https://github.com/nim-lang/RFCs/issues/178](https://github.com/nim-lang/RFCs/issues/178) [https://github.com/nim-lang/RFCs/issues/177](https://github.com/nim-lang/RFCs/issues/177) Ownership is still coming but owned can be implemented as a library. > Also am I correct that --gc:arc is very similar to the memory model described > here Yes, it's basically C++'s / Rust's / Lobster's algorithm, as it's a pretty natural outcome of move semantics.
Re: Nim version 1.2.2 is out!
A couple of remarks: * 1.2.2 does away with the runtime's infamous genericReset calls, instead much faster code is produced. * The SSL bugs have been fixed. At least that's what I have been told. * There is a new warning about "Observable Stores". I have yet to see a case where this warning indicates a real problem and so your config should probably disable it. Code to do that is: # nim.cfg @if nimHasWarningObservableStores: warning[ObservableStores]: off @end Run * Apart from that 1.2.2 focus was ARC-related bugfixes.
Re: What is ?
It's dead code and we should remove it.
Re: Why is my HTTP handler not gcsafe?
> If I add the gcsafe pragma to my callback proc, it now compiles without > errors! Where's my "extended error information"? There is a phase ordering problem in today's compiler so that in rare cases `.gcsafe` isn't inferred the way it should be. (Known problem.) The good news is that when the code compiles with `.gcsafe`, it really is GC safe and nothing to worry about. There is also [https://github.com/nim-lang/RFCs/issues/142](https://github.com/nim-lang/RFCs/issues/142) for how to evolve the "GC safety" issues.
Re: Transform procs at compile time?
You can also import the compiler as an API and do the transformation as a separate compiler pass. Unfortunately [https://github.com/nim-lang/Nim/blob/devel/tests/compilerapi/tcompilerapi.nim](https://github.com/nim-lang/Nim/blob/devel/tests/compilerapi/tcompilerapi.nim) only shows how to use Nim as a scripting layer but it's a start.
Re: Comparisons of Nim to the Chapel computer programming language...
> In all languages (Go, Nim, ...) channels are built either on top of > Lock+Condition variables or Atomics (reusing queue designs) but I expect we > will reach the limits of memory coherency at the CPU level and that in the > future NUMA will become increasingly important and we might see hardware > channels being more popular (rather than restricted to stuff like Infiniband) Well this has been claimed for over ten years now, it's one reason why Nim did bet on thread local heaps + message passing and I don't see it becoming the reality anytime soon. I can be wrong of course. However, it is insightful to look at what GPUs do. The classical view is that they are based on shared memory. But when you look at it from a different angle what happens is that inside a GPU a program fragment is passed over to the data. Maybe I'm nuts and is has nothing to do with GPUs, but the idea is a good one. Don't transport data, transport programs.
Re: Unicode support for Windows 10 console
Nice to see progress here. Maybe we can improve the stdlib's solution too, PRs are welcome.
Re: Can't access fields of object returned by a procedure
Anytime soon now (ha!) we'll improve the error message for this, it's a common gotcha for newcomers.
Re: Website probably not up-to-date for Nim installation
Yes, indeed. Thanks!
Re: Comparisons of Nim to the Chapel computer programming language...
So far I found "ParaSail" to be most inspiring. It keeps Ada's (and Nim's) parameter passing modes, throws away pointers completely, adds some mild aliasing checks and ends up with a system where g and h can and are run in parallel within f(g(args), h(otherArgs)).
Re: What's happening with devel releases and version numbers?
> Does that mean there are problems compiling to these two targets? No, there are currently problems with the nightly builds but nim devel is green on all major OSes including BSD.
Re: What's happening with devel releases and version numbers?
> I.e. if we uncover showstopper bugs on 1.2 we hope to have a 1.2.4 release > with the fixes. Well surely you will get a 1.2.4 if you need one.
Re: What's happening with devel releases and version numbers?
It's like this: 1.0 is our long-term support (LTS) stable release. While 1.0.N is in development the version is 1.0.(N-1). The reason that 1.0.7 exists in our branch is that there will be a 1.0.8. Because 1.0 is the version we support for the upcoming X (X = 5?) years. 1.2.0 is the first release that ships `--gc:arc`. 1.2.2 will be released soon having many arc-related fixes and also other fixes we seemed important enough to backport. Probably there will be no version 1.2.4 because 1.2.0 isn't an LTS release. 1.3.x is the development version that will become 1.4.0. For technical reasons having to do with bootstrapping the x is more frequently updated these days. It's expected that 1.4.0 will ship --gc:arc with the cycle collector. Regarding arc being hard to implement, well, it's still automatic memory management and it works with threading so there is some intrinsic complexity involved. **Everything should be made as simple as possible, but no simpler.**
Re: bizarre name clash with template
Sure, we're working on a fix. No promises on a release date.
Re: New entry on Nim blog...
Perhaps but omg I wasn't aware the documentation for this tool is already on our website... :-)
Re: Using a Table as an object's member.
Please don't do that, `ref` exists for aliasing, not for convenience.
Re: Justification for auto type
> Then all our serialization libraries at Status have a tremendous amount of > bugs I don't understand how this follows. So you heavily use `auto`, ok, no worries. My claim is that `auto` can "almost" always be avoided.
Re: Module level variables in plugin libraries
Remove the `nimGC_setStackBottom` and `GC_fullCollect` calls and compile with `--gc:arc`.
Re: Justification for auto type
Corner cases aside, `auto` can always be avoided and if it cannot, it's likely a compiler bug.
Re: Uncle Bob - one syntax to rule them all?
> but choosing the right tool for the right purposes. Nim is the right tool for all purposes. ;-)
Re: Justification for auto type
The best justification for it is that without it `sugar.=>` would be harder to write. Or impossible.
Re: Creating a seq or openarray on unmanaged memory
> But Go's slices are memory-safe and zero-copy and can be stored, for example. They are technically memory-safe but prone to aliasing bugs anyway.
Re: Best Nim translation of C {void*, size_t} struct
It's supposed to work, yes and should be documented in the manual.
Re: Nim Cheatsheet PDF (English+Spanish+Latex)
Iteration order that depends on runtime values is a design bug.
Re: incorrect set-to-int conversion
> Is this a bug, or intentional? If the latter, is there a cleaner workaround > like a pragma? It's intentional but it's not part of the spec and we could change it. The workaround is to add an enum field that is mapped to 0.
Re: Stream IO errors with -d:release flag
It's likely that your code is buggy. Use `setupForeignThreadGC()` in callbacks that are called from C and run in a different thread.
Re: Change Nim colour on GitHub
Fwiw orange is my favorite color.
Re: Generate warnings for default returns
I completely agree with this proposal. It's time to make implicit result values a warning. The extra line `result = 0` or similar in the beginning of a proc won't kill us.
Re: Best Nim translation of C {void*, size_t} struct
I would use `openarray[uint8]` too. Strictly speaking though Nim uses a Nim `int` (== `ssize_t`) as the length information and so it's incompatible for arrays which contain more than 2 billion elements (on a 32 bit machine). Never happens.
Re: Faster and Safer Raytracing in Nim
Before we re-publish this as an article on our website, can you explain the 2min14.616s outlier for GCC 10 C++ OpenMP? Or can at least somebody confirm these numbers? :-)
Re: How mature is async/threading in Nim?
> I may very well be missing something, ... Read mratsim's post from the same thread then, [https://forum.nim-lang.org/t/6352#39200](https://forum.nim-lang.org/t/6352#39200)
Re: Write Nim in Matlab/Julia style using macros while still deploy to Cloud/PC/GPU/embedded?
> But is this within Nim's capabilities? Well yes, I think so. But maybe I'm a little biased. ;-)
Re: raise error using zig as cross compile
_shrug_ Not our bug. :-)
Re: raise error using zig as cross compile
It's `cc:clang`.
Re: closure procs with the javascript backend
That's a bug in `dom.nim`, fix is in the works.
Re: raise error using zig as cross compile
You should use `--cc:clang --clang.exe=zig`.
Re: How mature is async/threading in Nim?
> At this point I'm unclear on how much of this stuff is solid and > enabled-by-default (in particular, what's the difference between "arc" and > "orc"?) ARC is in version 1.2 with significant stability improvements around the corner in 1.2.2. Many Nimble packages already work with `--gc:arc`. While the stability is still not good enough for Nim compiler bootstrapping, for new projects I wouldn't use anything else because the tooling is so much better. All the sanitizers from C++ simply work, compile your code with `nim c --gc:arc --debuginfo -d:useMalloc y.nim && valgrind ./y` and you can be assured the remaining ARC bugs (sorry!) don't affect you. You can also slowly move from the C++ code to Nim, the interop between Nim and C++ is superb and only getting better with ARC.
Re: How to instantiate `ptr object`
> For your example ARC makes a gigantic difference. Yeah, known problem. Method dispatch got super slow for ARC. Not sure yet how to fix it. I can do it the old way without problems, but where is the fun in that. ;-)
Re: Experimenting with a FreeRTOS OS Port
> P.S. while the "hello world" http server is working, it currently blows up > after about ~22 requests. Anyone got suggestions? For stdlib's async you need `--gc:orc` and Nim devel, otherwise it leaks memory. Sorry, I hope we can get 1.2.2 out soon! The good news is that we're also planning an async more suited for embedded.
Re: Idea: Nim Online Conference
> But with a mention of prerecorded talks, I'm now really confused as to > planned level of interactivity...? Personally, it would be much harder for me > to present if I could not feel any kind of live connection with the > audience... Well for a prerecorded talk the speaker would be available afterwards for live questions.
Re: oids library import + Karax --> error
Asking questions here that may or may not be answered in our manuals or tutorials is fine. But short answers are fine too. ;-)
Re: Experimenting with a FreeRTOS OS Port
I'm _very_ interested in this port and would appreciate PRs. Ideally even CI support.
Re: Revisiting my oldest Nim project.
> I did not want to use json. I wanted to use binary formats .. compressed > binary formats. Bummer, I still like them better than json. :-)
Re: New blog, with some Nim articles
Sure, how about: "Idiomatic Nim code is fast and Nim does not have "optimization walls." "
Re: New blog, with some Nim articles
> It's not that Nim is fast, it's that Nim does not have "optimization walls." Great quote! Can we put it on the website? It says in one sentence what I've always tried to express.
Re: Define variables in proc with same name as arguments
No, in fact it's common idiom to do this: proc test(n: int) = let n = n - 1 # my indexing starts at 0 or something echo a[n] Run
Re: Idea why this does not compile?
I know why it doesn't compile but my reply would be identical to the compiler's error message. You need to define your destructor earlier, like so: when defined(gcDestructors): proc `=destroy`*(self: var typeof(Event()[])) = if not self.ignoreFinalizer and self.impl != nil: echo "gdk_event_unref(self.impl)" self.impl = nil template fnew*(a: untyped; finalizer: untyped) = when defined(gcDestructors): new(a) else: new(a, finalizer) proc `ref`*(self: Event): Event = fnew(result, generic_gdk_event_unref) echo "result.impl = gdk_event_ref(cast[ptr Event00](self.impl))" proc generic_gdk_event_unref*[T](self: ref T) = if not self.ignoreFinalizer: echo "gdk_event_unref(self.impl)" Run
Re: How to instantiate `ptr object`
> you can't mix inheritance with un-managed raw pointers. I can do it. In fact, I did in Nim's allocator.
Re: How to instantiate `ptr object`
> you can't mix inheritance with un-managed raw pointers. I can do it. In fact, I did in Nim's allocator.
Re: Is it possible for a macro to know the context it is used?
> Instead of having multiple small macros that don't play well together and > have only a local context, I'll apply a visitor-like pattern and I can > control the scopes in the DSL. Yes! Now you're cooking.
Re: Markdown test
I think more things will work after a redeploy of nimforum. :-)
Re: A good word for idiomatic nim?
Boring: Simply "idiomatic". The context "for Nim" is usually implied. Fun: "nimish".
Re: Detect englobing scope in macros
We're always improving the documentation but here is a good rule of thumb: **Whenever you need to analyse the AST, you need a macro.**
Re: oids library import + Karax --> error
The oids module doesn't work for the JS backend, that's why.
Re: Detect englobing scope in macros
> I think you confuse nim templates with template from another language. Maybe not, but writing DSLs without learning macros is simply not a good idea.
Re: The let alias trap with HashSet[string]
Fixed with `--gc:arc`.