How to dynamically link LGPL nim library to closed-source nim application?

Any reason you chose LGPL over MPL then? MPL sounds like a perfect fit for your case - it only requires users to open source the changes that they did in your library.

How to dynamically link LGPL nim library to closed-source nim application?

@giaco if you are referring to NimQml, since i'm the author, i'm fine in adding an exception to allowing static linking. The usage of LPGL was for forcing publications of the library not preventing closed source usages. Write and issue in the NimQml github.

How to dynamically link LGPL nim library to closed-source nim application?

I'm only replying to your questions, I'm not really sure about using LGPL libraries in proprietary Nim programs: > case A: is it possible to dynamically link a nim library/module in a nim > project? Yes, but then you have to exportc the needed procedures from the module and compile it separate

How to dynamically link LGPL nim library to closed-source nim application?

thanks for your contribution but yeah, my question is more on the technical than the legal side

How to dynamically link LGPL nim library to closed-source nim application?

I am not a lawyer - but here is how I see it: Case A - yes you can do that. Make sure to make the full source code and all modifications of the dll / so file available. Case B - you should better not link LGPL code statically. You can do so, as it doesn't violate the LGPL as long as someone can

Unexpected behavior when using custom finalizers + ARC/ORC + RootObj

thanks, I do confirm that wrapping the test cases in proc makes the test succeeds in all 4 cases with refc, and confirms the odd behavior in case n==0 and n==2

profiler for mac?

> I have written a command line sampling profile +1 that's seems to be exactly what I want. Maybe it would be worth to mention it in the docs for std/nimprof .

Unexpected behavior when using custom finalizers + ARC/ORC + RootObj

@giaco: What you are missing is that things that are allocated globally aren't collected; you need to allocate locally inside a function/proc in order to qualify for collection: You need to declare your test code as follows: if isMainModule: let mem0 = getOccupiedMem()

Unexpected behavior when using custom finalizers + ARC/ORC + RootObj

I've extended the experiment to --gc:refc, this also is giving me some unexpected results: finalizers seems never called even after GC_fullCollect() Compile with --gc:refc const n = 0 when n == 0: # RootObj + forward declaration # Custom finalizer not called ty

Unexpected behavior when using custom finalizers + ARC/ORC + RootObj

I was tracking down a memory issue when I encountered an unexpected the behavior of ORC/ARC when using custom finalizers. I'm using `new` function to assign a finalizer to a type. Not sure if this is worth a github issue, ple

How to dynamically link LGPL nim library to closed-source nim application?

If an LGPL nim library is used in closed-source nim project, the LGPL requirements needs to be fulfilled. 10.8 Distributing Works Based On the Library Essentially, “works based on the library” must

Nim Community Survey 2021

> Talking about typed vs. untyped is a big one I've been meaning to add. I think that would be really valuable, especially considering that Araq has stated more than once ([here](https://github.com/nim-lang/Nim/issues/19323#issuecomment-1004677854) and [here](https://github.com/nim-lang/RFCs/is

Topfew - a Nim port of Tim Bray's logfile utility

So which do you use for maximum performance? Or you don't use any regex library at all in that case

Topfew - a Nim port of Tim Bray's logfile utility

This problem is basically the classic Knuth-McIlroy contrast, cast in parallel form with some generalization Re: tokenization. So, you may want to have a look at It may or may not be optimal for your specific application, but there may b

Topfew - a Nim port of Tim Bray's logfile utility

Which is slower?

Topfew - a Nim port of Tim Bray's logfile utility

regex in Nimble is slower

Comments and criticism,please: Nimplementation of Church Numerals

@shirleyquirk: About the YCombinator > trying to get closer to whatever the hell haskell does... Everything is lazy in Haskell, so to do the same thing in a strict language like Nim, we need to inject some laziness with differed execution using thunks. As per [my RosettaCode Y-Combinator in Nim

Topfew - a Nim port of Tim Bray's logfile utility

But it is sadly slower, sometimes quite significantly :) That said, I prefer it to std/re too when I don't need maximum performance, and I use regexes rarely anyway.

Topfew - a Nim port of Tim Bray's logfile utility

Checkout regex which is written in pure nim and doesn't depend on PCRE

Cleanup at program end - open files automatically closed?

Ok. Although I don't usually do manual file handling

Topfew - a Nim port of Tim Bray's logfile utility

Hey Nimians, Over the holidays I started a port of Tim Bray's topfew logfile utility for fun and educational purpose. with the intent of comparing Nim's relative performance against the original Go implementation. Github link: If you're not familiar wi

Suppressing non-exported fields in nim doc

Issue [here](https://github.com/nim-lang/Nim/issues/19396), related pull request [here](https://github.com/nim-lang/Nim/pull/19397).

Cleanup at program end - open files automatically closed?

Almost all C libraries will also flush the buffers in `FILE` (that is what the Nim `File` wraps) and then the OS itself reclaims file slots (if the C lib does not call the OS close which it probably does, but you can tell with "system call tracers"). If the OS did not reclaim then any user coul

Cleanup at program end - open files automatically closed?

They will leak even as the program exits?

Cleanup at program end - open files automatically closed?

Nim wouldn't clean up them at the program exit, so it's up for the OS to close the file handles, and AFAIK most do that.

Cleanup at program end - open files automatically closed?

As of right now you need to close them yourself - the standard library doesn't automatically close them. That might change in the future though if destructors will be added to the file object.

Cleanup at program end - open files automatically closed?

Bear with me if I missed this in documentation: Assume I open a few files in a nim program, but never close them explicitly. Do these get closed automatically - either when the variables holding the handles run out of scope or at the end of the program (in the sense of the nim compiler creating

Nim Community Survey 2021

Lot's of people have covered macros, there is an example in ` tutorial part 3 <[https://nim-lang.github.io/Nim/tut3.html>`](https://nim-lang.github.io/Nim/tut3.html>`)_ which is quite good and a couple more in I once made a [post](https://nim-lang.org/blog/

Nim Community Survey 2021

I'll take a stab at simplifying macros. > What (in plain english) is a macro. Macros read/output Nim syntax, instead of run time data. This is called "meta-programming"; code that generates code. > Why would you want to use one. And what are the benefits They can take arbitrary syntax and outp

closure and for loop problem

needs closure scope capture

closure and for loop problem

Thank you very much! I didnt know about this. For other readers this is the solution: for i in 1..10: closureScope: let j = i var f: Foo f.something = proc() = echo $j foos.add(f) Run

closure and for loop problem

Hello Nim friends! i dont known how i can solve this problem. See minimal and runnable example: type Foo = object something: proc() var foos: seq[Foo] # test 1 does not work because of closures # for i in 1..10: # var f: Foo # f.s

Nim Community Survey 2021

I don't know if it's a lack of language tutorial, maybe a lack about use case or tools. I think to 3 subjects: * Embedded programming for example on ESP32, * How to use Nimble with concrete examples, * Debugging on Linux, Windows and MacOS. May be creating a RFC about tutorials.

Namespaces for non-enums without customizing the import statement?

I see, that helps a lot. Thanks!

Comments and criticism,please: Nimplementation of Church Numerals

@shirleyquirk: Sorry, I somehow missed seeing your reply: > I've only seen them (predecessor functions - GBG) based upon church pairs > before, what was your inspiration? I got it [from Wikipedia Church Encoding](https://en.wikipedia.org/wiki/Church_encoding#Calculation_with_Church_numerals)

Namespaces for non-enums without customizing the import statement?

No, it won't. They can still refer to it as `experimental.hello`.

Program does not compile with ARC/ORC

see

Program does not compile with ARC/ORC

My Nim program containing self-referencing data types works fine with the default GC. When I try to compile with `--mm:orc` or `--mm:arc` I see the below error. **Minimal reproducer that I could build** # main.nim import std/options type C = ref object ou

Namespaces for non-enums without customizing the import statement?

As I understand, this would remove `experimental.hello` completely. It _should_ be available for users of the package.

Suppressing non-exported fields in nim doc

I would add yet another flag to renderer.nim that is used by the docgen, that leaves out a `nkIdentDef` within a `nkObjectTy` that lacks the postfix export marker. I suppose that is the solution that you described too.

Namespaces for non-enums without customizing the import statement?

`export experimental except hello ` Run

Namespaces for non-enums without customizing the import statement?

Thanks for these ideas. Alas both seem somewhat hacky, I was hoping for something more established. Also, both require modifying each occurrence of a symbol and/or don't work for every kind of symbol. I might have over-generalized my question in the hope of getting a general answer. If namespac