Re: Legal Threats In Nimble Packages
yeah I discovered that nasty license stuff recently. Actually I have a problem in choosing the right license for my wrapper. the lib itself is apache2 but I dont´t like that for my wrapper. Are there possibilities to override that built in virus behaviour? And I think it depends if you wrap a binary lib or include a (for instance header-lib only) into your sourcecode?.. lives not easy with these lawyers nowadays..
Re: Legal Threats In Nimble Packages
Please understand my priorities: * Dealing with the aforementioned threat of "even more restrictive than copyleft" licenses is the most pressing concern, and it's an issue that I hope most people can agree on. Nim module licenses are not the place to punish people you don't like. * The copyLEFT vs copyFREE debate is second. * The "not copyleft but [not quite copyfree](http://copyfree.org/standard/rejected)" licenses like Apache, PyPL, Zlib, and Vim is the lowest priority. > why pick MIT over Apache 2? MIT doesn't have patent protection and patent > trolls are a real-world problem. Apache also has additional restrictions, which is why it's [rejected by the Copyfree Initiative](http://copyfree.org/standard/rejected) and [OpenBSD](https://www.openbsd.org/policy.html). There are other ways to grant patent protection: like [Golang's patent grant](https://golang.org/PATENTS), [Rust giving you the choice of (MIT || Apache)](https://rust-lang-nursery.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive), or [COIL](http://coil.apotheon.org/). (Although there's confusion in Rustland with some crates being "Apache && MIT", and instead of or, which is bad.)
Re: Is there are something like Python's 'pass' statement in Nim
> Is there are something like this in Nim? proc foo = discard Run
Re: Legal Threats In Nimble Packages
> Checking that the Nimble license metadata matches the license claims in the > code. Very true. > I think most people will disagree with me on where this line should be drawn.. Very true :o) > .., but it needs to be drawn somewhere... Yes, individually by every user of a library. If I don't like the license, I don't use the thing. > Politely nagging module authors to encourage using the same legal terms as > Nim itself: the good 'ol MIT license, or equivalent. Don't nag, give people reasons: why pick MIT over Apache 2? MIT doesn't have patent protection and patent trolls are a real-world problem.
Legal Threats In Nimble Packages
Did you know that using Nim's import keyword supposedly constitutes entering into a contract? Are you aware of all the legalese imposed on you by the modules you use (as well as their dependencies, and their dependencies' dependencies, etc)? Here are a few examples: * The [libravatar](https://nimble.directory/pkg/libravatar) module uses the PPL / "[Peer Production License](https://raw.githubusercontent.com/juancarlospaco/nim-libravatar/master/LICENSE)", self-described as "copyFARleft". It includes language like: "Any use by a business that is privately owned and managed, and that seeks to generate profit from the labor of employees paid by salary or other wages, is not permitted under this license." Even professional lawyers would disagree on what that license actually means exactly. You might need a special permission slip signed by the ghost of Karl Marx... * The license for the [nimwc](https://nimble.directory/pkg/nimwc) module is incorrectly identified as "GPLv3" in nimble metadata, but it's [actually](https://github.com/ThomasTJdev/nim_websitecreator/blob/master/nimwc.nimble) the [PPL](https://raw.githubusercontent.com/ThomasTJdev/nim_websitecreator/master/LICENSE) as well. So it's not enough to look in the nimble directory, you have to look at the actual package code to know what "contracts" you've supposedly just agreed to... * The ["anti-fascist" license](https://github.com/jamiebuilds/anti-fascist-mit-license/blob/master/LICENSE) bans use by Trump supporters (and, judging from how many leftists misuse this term, anyone to the right of Bernie Sanders). This hasn't reached the Nim ecosystem yet (as far as I know - I didn't check every single package), but it's only a matter of time... I have been observing the state of Nim ecosystem's [license freedom](https://copyfree.org) for quite some time. I once thought that the relative lack of legal encumberedness could be [a unique selling point](https://voat.co/v/programming/2853775) for Nim. It's been very disappointing to watch Nimble copyfree package percentage fall from [89.2% in Aug 2016](https://archive.fo/zz9t6), [88.1% in Sep 2017](https://archive.fo/YShGX#selection-825.0-825.4), to 85.7% today. Nim's biggest competitor, Dlang, has been moving in the favorable direction instead... Things I recommend: * Checking that the Nimble license metadata matches the license claims in the code. * Limiting the official Nimble module list to just the code with acceptable licenses. I think most people will disagree with me on where this line should be drawn, but it needs to be drawn somewhere... * Politely [nagging](https://archive.fo/7jzCs/3c8f7fb0cb40574f48e753972f0e055c61281839.png) module authors to encourage using the same legal terms as Nim itself: [the good 'ol MIT license](https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html), or [equivalent](http://copyfree.org/standard/licenses).
Is there are something like Python's 'pass' statement in Nim
I am a newer to Nim programing language. when I use Python, I can use the 'pass' to skip the defination detail of a function and class. .. def foo(): pass # skip detail class Bar(): pass nim Is there are something like this in Nim?
Can't call Nim dll in NodeJS
I have a C library clib.c with this function. int hi(char*
hello) { return 900; } compiled as: gcc clib.c -o clib.so --shared
-fPIC I'm consuming this in a Nim libray called 'nlib.nim`:
proc hi*(hello: cstring): cint {.cdecl, importc: "hi", dynlib:
"./clib.so".} proc hi2*(hello: cstring): cint {.cdecl, exportc.} = return
hi(hello) complied as:
nim c --app:lib --noMain -o:nlib.so nlib.nim If I call the hi2
function directly in Nim, it returns 900, perfectly. But if I call it from
NodeJS via FFI:
var ffi = require('ffi'); var lib = ffi.Library('./nlib.so', { 'hi2' : [
"int", ["string"] ] }); console.log(lib.hi2("hey")); I get a
Segmentation fault (core dumped)
Re: Some weird Heisenbug with the implicit result variable which results in a segfault
I would double-check the ZLIB binding code that you have, to make sure that everything is correct. This looks suspiciously like a memory-corruption issue, which tends to happen when Nim bindnigs don't accurately represent the functions/structures they are wrapping. You _[might](https://forum.nim-lang.org/postActivity.xml#might) have some luck with defining the symbol 'checkAbi' (so `-d:checkAbi`) to insert C binding checks.
Some weird Heisenbug with the implicit result variable which results in a segfault
So while cleaning up [https://github.com/haldean/nimage](https://github.com/haldean/nimage) I came across a rather weird bug, which results in a segfault/SIGSEV. To reproduce, clone this repo: [https://github.com/Clyybber/nimage.git](https://github.com/Clyybber/nimage.git) and checkout the branch "crash" and do nim c tests/test1.nim and then run ./tests/test1 In this line [https://github.com/Clyybber/nimage/blob/crash/private/zutil.nim#L47](https://github.com/Clyybber/nimage/blob/crash/private/zutil.nim#L47) it will segfault. Apparently it has to do with invalid writes/reads according to valgrind: Invalid write of size 8 at 0x10E249: removeChunkFromMatrix2_XFftAAJrARamxGOKUFQy9aw (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10E577: getBigChunk_stlXHMKRKFIGOvq8t4ynRQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10F6CC: rawAlloc_mE4QEVyMvGRVliDWDngZCQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114251: rawNewObj_ehkAaLROrd0Hc9aLROWt1nQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114321: newObjNoInit (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114391: rawNewStringNoInit (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114A0F: setLengthStr (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x11F7CC: zuncompress_VbbZ4LVDy6izxF4k3Gvj3g (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x121798: load_idat_P5PrAgoAkNqPZC5CDuYW7A (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x12311B: load_png_ACPUuVacvyp8EtUpaNSq9cg (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x1237F7: NimMainModule (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x123699: NimMainInner (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) Address 0x17 is not stack'd, malloc'd or (recently) free'd Invalid read of size 8 at 0x10E1B4: removeChunkFromMatrix2_XFftAAJrARamxGOKUFQy9aw (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10E577: getBigChunk_stlXHMKRKFIGOvq8t4ynRQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10E70C: getSmallChunk_0ixBBlKB5QN59bxrmztRmCw (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10F3B0: rawAlloc_mE4QEVyMvGRVliDWDngZCQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114251: rawNewObj_ehkAaLROrd0Hc9aLROWt1nQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114864: newObj (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x1148FA: rawNewString (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x11798E: signalHandler (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x4A33DFF: ??? (in /usr/lib/libc-2.28.so) by 0x10E248: removeChunkFromMatrix2_XFftAAJrARamxGOKUFQy9aw (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10E577: getBigChunk_stlXHMKRKFIGOvq8t4ynRQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10F6CC: rawAlloc_mE4QEVyMvGRVliDWDngZCQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) Address 0xf is not stack'd, malloc'd or (recently) free'd Process terminating with default action of signal 11 (SIGSEGV): dumping core Access not within mapped region at address 0xF at 0x10E1B4: removeChunkFromMatrix2_XFftAAJrARamxGOKUFQy9aw (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10E577: getBigChunk_stlXHMKRKFIGOvq8t4ynRQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10E70C: getSmallChunk_0ixBBlKB5QN59bxrmztRmCw (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10F3B0: rawAlloc_mE4QEVyMvGRVliDWDngZCQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114251: rawNewObj_ehkAaLROrd0Hc9aLROWt1nQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x114864: newObj (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x1148FA: rawNewString (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x11798E: signalHandler (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x4A33DFF: ??? (in /usr/lib/libc-2.28.so) by 0x10E248: removeChunkFromMatrix2_XFftAAJrARamxGOKUFQy9aw (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1) by 0x10E577: getBigChunk_stlXHMKRKFIGOvq8t4ynRQ (in /home/clyybber/projects/wyven/concept/image/nimage/tests/test1)
Re: Can I access arrays faster than this?
@cblake True, true. I was simply enjoying that I could write "one through fifty, so fifty times" very simply and easy to read in nim, whereas I just relied on trained C eyes to interpret the C code of its intended meaning "zero up until 50, meaning 50 times". Perhaps nim's `countup()` would have been even more appropriate. @Stefan_Salewski You're making fun of my specific example! :) Yes adding `i32` wasn't that cumbersome in THAT example, but I'm sure you could imagine scenarios where it would get more annoying - this was only an illustration of how it works. Also, you have to be sure that you didn't miss one, not to mention you'll already have to annotate by hand any relevant var types in the signature since the macro doesn't handle that part.
Httpclient and hangs
Is there any reason that getContent should hang indefinitely even if httpclient has been given a set timeout?
Re: Can I access arrays faster than this?
With such a brief comment, it's hard to know which is why I said "probably
intending". Only one person knows. ;) Maybe he did think iterators cost more.
You are right I did misread his 1..50 as 0..50 {after looking at the first
version of the ggibson Nim code, not the 2nd where he confusingly switched to
1..50 not paralleling the C as well, but correcting his amount-of-work
mismatch}.
Re: Can I access arrays faster than this?
> @mratsim is probably intending to refer to the .. including 50 in Nim while > the C for with a < excludes 50 I doubt that because he has written **1** .. 50 ;)
Re: nlvm update
> Do you think it is feasible? probably not. what would likely be needed is that nim would expose a nim api/abi to nlvm, much like if you had wrapped a c++ library with a c api.. that would require a lot of changes to nim, including specifying an ABI etc. header pragmas for C stuff are kind of not needed if you take care to correctly specify the ABI (correct function signatures / types) - that's how nlvm is able to use the nim std lib which is full of references to the C std library. In fact, nim itself doesn't really need header if you write things correctly. Of course, for C++ that's nearly impossible.
Run all failed tests?
Is it possible to run all failed tests using unittest? If not, is there a nim testing framework that allows this?
Re: Can I access arrays faster than this?
@mratsim is probably intending to refer to the `..` including `50` in Nim while
the C `for` with a `<` excludes `50` doing about 2% less work, but the
terseness and style of of his comment may leave the wrong impression.
for i in 0..50: echo i
Run
indeed compiles down (in release mode) to simply:
NI res = ((NI) 0);
while (1) {
if (!(res <= ((NI) 50))) goto LA3;
res += ((NI) 1);
}
LA3: ;
Run
plus some stuff only related to my choice of `echo` for the body (which I
removed for clarity). Any decent optimizing C compiler should treat those two
ways to spell the loop (@mratsim's `for` and the above `while`) the same.
TL;DR the extra time is from the bounds of the iteration, not the language or
iterator overhead.
Re: Can I access arrays faster than this?
Also for r in 1 .. 50: does more work than C for (size_t r=0; r<50; r++) {
