Re: Older libc
Check out nimpcre as well which compiles in pcre instead of requiring a static lib file. Probably more useful on Windows.
Opposite of astGenRepr
Given a string with the results of an `astGenRepr` in it, how do I convert it
back to a NimNode that matches the original?
Consider this:
import macros
macro astFor*(s:untyped):untyped =
result = newLit(s.astGenRepr)
macro start(): untyped =
var x = astFor:
proc foo() =
echo "hi"
echo "x: ", x
var parsed = x.parseStmt()
echo "parsed: ", parsed.astGenRepr
# why is parsed.astGenRepr not the same as x?
start
Run
I'm looking for something like `parseStmt` that would make `parsed.astGenRepr`
and `x` be the same. Instead, it produces this:
x: nnkStmtList.newTree(
nnkProcDef.newTree(
newIdentNode("foo"),
newEmptyNode(),
newEmptyNode(),
nnkFormalParams.newTree(
newEmptyNode()
),
newEmptyNode(),
newEmptyNode(),
nnkStmtList.newTree(
nnkCommand.newTree(
newIdentNode("echo"),
newLit("hi")
)
)
)
)
parsed: nnkStmtList.newTree(
nnkCall.newTree(
nnkDotExpr.newTree(
newIdentNode("nnkStmtList"),
newIdentNode("newTree")
),
nnkCall.newTree(
nnkDotExpr.newTree(
newIdentNode("nnkProcDef"),
newIdentNode("newTree")
),
nnkCall.newTree(
newIdentNode("newIdentNode"),
newLit("foo")
),
nnkCall.newTree(
newIdentNode("newEmptyNode")
),
nnkCall.newTree(
newIdentNode("newEmptyNode")
),
nnkCall.newTree(
nnkDotExpr.newTree(
newIdentNode("nnkFormalParams"),
newIdentNode("newTree")
),
nnkCall.newTree(
newIdentNode("newEmptyNode")
)
),
nnkCall.newTree(
newIdentNode("newEmptyNode")
),
nnkCall.newTree(
newIdentNode("newEmptyNode")
),
nnkCall.newTree(
nnkDotExpr.newTree(
newIdentNode("nnkStmtList"),
newIdentNode("newTree")
),
nnkCall.newTree(
nnkDotExpr.newTree(
newIdentNode("nnkCommand"),
newIdentNode("newTree")
),
nnkCall.newTree(
newIdentNode("newIdentNode"),
newLit("echo")
),
nnkCall.newTree(
newIdentNode("newLit"),
newLit("hi")
)
)
)
)
)
)
Run
Older libc
For GNU/Linux system, I have created this config.nims to statically link pcre using musl. See [https://github.com/kaushalmodi/hello_musl](https://github.com/kaushalmodi/hello_musl). Clone it (on a GNU/Linux system with musl-gcc installed) and simply run `nim musl -d:pcre src/hello_musl_pcre.nim`.
Re: Does Nim need package-level visibility?
How about something _similar to_ child packages in Ada? [1] - where "sibling" modules could have visibility of each others, as well as their parents private parts. [1]: [https://en.wikibooks.org/wiki/Ada_Programming/Packages#Child_packages](https://en.wikibooks.org/wiki/Ada_Programming/Packages#Child_packages)
Re: Read gzip-compressed file line by line
Open your Gz file with the os proc, store it completely in a string buffer, use [zlib uncompress](https://github.com/nim-lang/zip/blob/master/zip/zlib.nim#L271) I recommend you just use streams to avoid the extra uncompressed buffer (and maybe even the result buffer if you only work line by line).
Re: Read gzip-compressed file line by line
I have found this answer to a similar question but is there a way to not use Streams? [https://forum.nim-lang.org/t/3488#21813](https://forum.nim-lang.org/t/3488#21813)
Re: confused about new runnable code blocks `.. code-block:: :test:` (#9228) vs runnableExamples?
Did you mean to put `runnableExamples` in comments? I have only seen them uncommented: proc fill*[T](a: var openArray[T], first, last: Natural, value: T) = ## fills the slice ``a[first..last]`` with ``value``. runnableExamples: var a: array[6, int] a.fill(1, 3, 9) doAssert a == [0, 9, 9, 9, 0, 0] fillImpl(a, first, last, value) Run [reference](https://github.com/nim-lang/Nim/blob/6620b5dc8d231dfd846072aa060f414e5e2e3838/lib/pure/algorithm.nim#L33-L39) That gives this output: [algorithm docs from devel docs](http://nim-lang.github.io/Nim/algorithm.html#fill%2CopenArray%5BT%5D%2CNatural%2CNatural%2CT)
Read gzip-compressed file line by line
I'm using the following approach to read a file line by line. This is a bogus example that only returns each line, but you can imagine I am doing some work on each line. iterator line_iterator*(input_filename: string): string = var infile: File if open(infile, input_filename): defer: close(infile) var line: string while not endOfFile(infile): # Do some real work here yield infile.readline.strip Run I would like to do exactly the same but reading lines within a gzip-compressed file (eg: file.gz). I'm trying to use import zip/gzipfiles and then use File, GzFile, GzFileStream... but I'm failing. What would my code above look like if I was iterating over the lines of a .gz file?
Re: Drop RST and join the Markdown train?
for concrete proposal on how to migrate, see:
[https://github.com/nim-lang/Nim/issues/9291](https://github.com/nim-lang/Nim/issues/9291)
[RFC] module/package level pragma {.doctype: markdown|rst.} to help migrate
docs from RST to Markdown
Re: Quick Start Documentation
Hey everyone: Great resources! Plus, silly me, I haven't noticed: github provides a wiki So I started a document, [https://github.com/nim-lang/Nim/wiki/Quick-Start-2018](https://github.com/nim-lang/Nim/wiki/Quick-Start-2018) it's the overview, **should have** links to beautiful image-filled friendly explanations. I think it's all a person could ever want. No excuses after that! When people say they wait for v1.0, what I hear is: a big 1.0, you will revamp your website, provide all the niceties, plenty of documentation to not get stuck, a customer friendly experience. comfort. you know, we all like that. so that's partly the goal here, imo. I think the seasoned writers can make the general layout, and we'll fill it by bits. Any takers? :-)
Re: confused about new runnable code blocks `.. code-block:: :test:` (#9228) vs runnableExamples?
> Isn't that redundant with runnableExamples? **Exactly**! That is my confusion too. If there were a poll, I would vote to keep only `runnableExamples`.
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
doAssert is standard in runnableExamples, not assert. runnableExamples typically shows a few illustrative unittests (eg doAssert "/tmp/foo".isAbsolute)
confused about new runnable code blocks `.. code-block:: :test:` (#9228) vs runnableExamples?
[https://github.com/nim-lang/Nim/pull/9228](https://github.com/nim-lang/Nim/pull/9228) (nim doc can run code blocks) introduced this feature: proc foo*() = ## Does something unexpected. ## ## .. code-block:: ##:test: ##foo() ## ## Don't run it! raise newException(Exception, "boo!") Run Isn't that redundant with runnableExamples? When should one be preferred over the other? If we're allowing runnable code embedded inside documentation, I've argued we might as well use the friendlier, shorter syntax runnableExamples: proc foo*() = ## Does something unexpected. ## ## runnableExamples: ##foo() ## ## Don't run it! raise newException(Exception, "boo!") Run which also allows one-liners: proc foo*() = ## Does something unexpected. ## runnableExamples: foo() ## Don't run it! raise newException(Exception, "boo!") Run ## links * note: would also address concerns from [https://forum.nim-lang.org/t/4279](https://forum.nim-lang.org/t/4279)
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
The word _Test_ is blurry, are you referring to Unittests or just test, you can add an `assert` anywhere, `assert` are removed when compiled for Release :P
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
runnableExamples is intended for documenting code, not exhaustively unit-testing it, so just a few doAssert per runnableExamples is standard (depending on function complexity). I intend to clarify this in [https://github.com/nim-lang/Nim/blob/devel/doc/contributing.rst](https://github.com/nim-lang/Nim/blob/devel/doc/contributing.rst) > I thought runnableExamples are example codes that help people learning how > the proc works indeed > These code are tested so that you don't write a example code that fail to > compile or cause assert error. in practice, even if the code is separately being tested in a separate test file, a code snippet that's not run by compiler will often end up containing bugs or bitrot later on. And oftentimes there's not even such separate test file (or isMainModule block) to being with, so in this case runnableExamples is better than nothing. As said earlier, Nim has poor test coverage, and this lowers barrier of entry to increase it.
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
Test code can be larger than 100 lines. For example: [https://github.com/nim-lang/Nim/blob/devel/tests/stdlib/tjsontestsuite.nim](https://github.com/nim-lang/Nim/blob/devel/tests/stdlib/tjsontestsuite.nim) Is it a good idea to put such a large test code under runnableExamples? Or if test code is larger than N (20~50?), put them in other file (e.g. "tests/tfoo.nim")? I thought runnableExamples are example codes that help people learning how the proc works. These code are tested so that you don't write a example code that fail to compile or cause assert error.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
> IMO include is good enough. No it's not. I've expanded on why include is not good enough, see my updated post here [https://forum.nim-lang.org/t/4296#26730](https://forum.nim-lang.org/t/4296#26730)
Re: Quick Start Documentation
[https://github.com/juancarlospaco/nim-presentation-slides/blob/master/nim-en.md#intro-to-nim](https://github.com/juancarlospaco/nim-presentation-slides/blob/master/nim-en.md#intro-to-nim) [https://github.com/juancarlospaco/nim-presentation-slides/tree/master/ejemplos/basico](https://github.com/juancarlospaco/nim-presentation-slides/tree/master/ejemplos/basico) [https://github.com/juancarlospaco/nim-presentation-slides/tree/master/ejemplos/avanzado](https://github.com/juancarlospaco/nim-presentation-slides/tree/master/ejemplos/avanzado)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
IMO `include` is good enough.
Re: Possible problem with my bcrypt module?
While you're at it you should probably move your .c/.h files into a `bcrypt` directory. In the future Nimble might make this compulsory (otherwise .c files will have a potential for clashing).
Re: Quick Start Documentation
> it is like driving a car without any knowledge of physics and how engine, > gears and brake basically work internally. Fortunately most people know the > basics already. Fortunately, most people drive cars just fine without any knowledge of "how cars really work internally" ;) Source: my friends and family
Re: Quick Start Documentation
That's probably selection bias. If someone is coming from a low-level language he knows this but if someone comes from a dynamic language that hides all those subtleties he wouldn't (unless he fought against the language and GC to access raw primitives).
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
Maybe:
import foo {.visibility: private.}
Run
Re: Quick Start Documentation
Yes that is true, and it is a fine tutorial. But for someone without any computer programming experience one would have to explain basics of memory management (Stack, Heap, GC, ref/ptr vs value types) and maybe even basic computer layout (CPU, RAM, most basic assembler operations). Without that information, it is like driving a car without any knowledge of physics and how engine, gears and brake basically work internally. Fortunately most people know the basics already.
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
> Perhaps there's merit to having runnableExamples: and runnableTests: , the > former copied to docs and the latter not? No matter what we call it, separating doc example code from actual tests is a good thing: * Regular source code of a module should be validated against tests with a testing framework/convention. * Doc example code should be validated against regular source code by the doc generator. * Some testing code is good example code, but not all of it, and vice versa. @timothee said in the original thread that D can generate tests into the docs (optionally?), so somebody thought about this and it sure sounds nice.
Re: Quick Start Documentation
> Where Beginner means more someone with some programming experience but new to > Nim, not someone with absolutely no computer-programming background. I've tried to make Nim Basics fall as much as possible in the latter category (while keeping it reasonably brief, and moving at a reasonable pace for people in the first category).
Re: Quick Start Documentation
Indeed most Nim documentation is in the area of "Quick-Start" or "Beginner, for example that one listed under Tutorials or Books at [https://nim-lang.org/documentation.html](https://nim-lang.org/documentation.html) Where Beginner means more someone with some programming experience but new to Nim, not someone with absolutely no computer-programming background. Note that Rosetta-Code has also many Nim examples: [http://www.rosettacode.org/wiki/Category:Nim](http://www.rosettacode.org/wiki/Category:Nim) But of course more fine documentation is always welcome.
Re: Full nimble support for gintro package (high level GTK3 GUI) available
> Is this Library considered the proper way to do a GUI application in Nim? No!
buy Real registred IELTS ,TOEFL , Certificates ,Passports , Drivers License , ID Cards,Visas, etc
buy Real registred IELTS ,TOEFL , Certificates ,Passports , Drivers License , ID Cards,Visas, etc To get the additional information and place your order, contact us at For Faster Communication And Transactions Contact On Kik or Wickr %100 secured [https://www.legitdocuments.net](https://www.legitdocuments.net)/ Kik..generaldocument Wickr..generaldocument whatsapp.+1(929)257-1434 wechat.houseofdocuments skypehouseofdocuments2...@gmail.com emailhouseofdocuments2...@gmail.com Buy registered ID cards Buy registered drivers license worldwide Buy registered USA (United States) passports, Buy registered Australian passports, Buy registered Belgium passports, Buy registered Brazilian (Brazil) passports, Buy registered Canadian (Canada) passports, Buy registered Finnish (Finland) passports, Buy registered French (France) passports, Buy registered German (Germany) passports, Buy registered Dutch (Netherlands / Holland) passports, Buy registered Israel passports, Buy registered UK (United Kingdom) passports, Buy camouflage passports, Express work permits Do You Need 100% Ielts/Toelf/Gmat/Gre/Pte/Nebosh certificates urgently without taking/writting/attending the test/exam ? Contact us and shall treat each case as urgent and important.
Re: Does Nim need package-level visibility?
I don't know which solution I would appreciate most, but I should mention that have also frequently incurred in 1), 2), 3), 4)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
+1 on some kind of invisibility/private-ness override feature. Another bonus of
that is to use it as a temporary workaround if some 3rd party package has made
something "overly" private as viewed by an "expert" user. While this has come
up in the context of library writing, sometimes users of libraries understand
many of its internals and sometimes they don't. Private, not exported, is
probably the right default or at least too late to change, but it's easy to
forget a `*` export marker and easy to disagree. This proposed mechanism would
allow temporary workarounds much closer to a likely more sanitary future usage.
It might be better to call it something scarier/less similar to a token like
`private` which can be _so_ common in other prog.lang's as to lead to questions
like "why does `private` mean this negative sense in Nim but positive sense in
Foo?". `import foo {.overrideInvisibility.}` or `overridePrivate` or something.
Just some kind of word to indicate bypassing of normal-ness (to act as a
redundant cue over there being a pragma there at all). I agree that
`{.breakTheGlassAndMakeEverythingVisible.}` is severe overkill. :-)
Re: runnableExamples should generally be preferred to `.. code-block:: nim`
Yeah, well, `runnableExamples` is exactly what its name says, it's both, it's documentation that is **checked**. You dislike this conflation, but I like it (and hopefully others too) and I 've seen how Nim worked before we had them, it was worse. And to find out how well D's `unittest` works you can read on the D forum about them, they are not loved either. ;-)
Re: Type inference and pragma issues in lambdas
Oh, right, the issue is for proc within tuples: [https://github.com/nim-lang/Nim/issues/7808](https://github.com/nim-lang/Nim/issues/7808)
Re: runnableExamples should generally be preferred to `.. code-block:: nim`
@Araq > Again, runnableExamples are not just documentation. They are also tests. Does that mean there can be testing code in a block named runnable Example s which is run by the documentation generator, but not by the regular testing framework? Testing and doc examples are two different concerns IMHO. The point of compiling and/or running doc code examples should be to validate the examples, not to test the module. The correctness hierarchy should be tests -> code -> examples, not (tests and examples) -> code. @timothee > This isn't specific to Nim. The fact that it is linked to a block comment context while technically being code is specific, and that's the part that bothers me. > ... in D, unittest blocks are not embedded in documentation even though they > end up in documentation and can be run from html. TBH that sounds like a great solution: * devs looking at comments in the source are not confused by block comments mixed with code. * tests are clearly separated from documentation in the source and are honored by the doc generator and the compiler/testing framework (I assume). Can't we get something like this? If `runnableExamples` was renamed to something with `test` and detached from comments, the only missing part would be validation for actual doc example code, and that would be relatively straight-forward: the doc generator could just compile example code blocks in doc comments at the end of the module/scope. If `.. code-block:: nim` is too cumbersome to type, the doc generator could learn about fenced code blocks (```-blocks). > thanks for reporting this; but please report as github issue next time ... I didn't report it as an issue because I wasn't sure it is one or if it's just me not understanding the intended behavior of the code. > ... instead of forum to increase change it gets fixed ... That was not what I wanted, sorry if I made it look like that.
Re: Full nimble support for gintro package (high level GTK3 GUI) available
Is this Library considered the proper way to do a GUI application in Nim?
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
> include foo does this kind of, just need to include it once in the program or
> you get duplicates.
include (which is really like C's #include) is very different:
* include it once in the program or you can get duplicates, as you said
* no way to force full qualification, eg from foo import nil {.private.}
Re: Type inference and pragma issues in lambdas
@adobai, this is work
proc doIt(x: string, p: proc()) =
echo x
doIt("xx", proc() = echo "aa")
Run
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I've edited my comment above while you posted yours ... With respect to "sticks out enough", I totally agree at the early adopter stage Nim is still in, but totally disagree for the time it reaches more widespread audience (and of course total world domination) - to many programmers, especially from a C++ / Java background, slapping a "private" or "public" onto things until the compiler is happy is a way of life.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
include foo does this kind of, just need to include it once in the program or you get duplicates.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I think import foo {. private .} sticks out enough, but feel free to recommend
something else if you have a better suggestion (that is also self-explanatory).
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
> What's currently been missed in this discussion here IMO is that > runnableExamples are not just documentation, they are also tests That's a very important point. Perhaps there's merit to having runnableExamples: and runnableTests: , the former copied to docs and the latter not? (or, perhaps start hidden behind a "show runnable test" button in HTML?); perhaps an arg to runnableExamples?
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
It's a good idea to have an escape hatch, but like all "break the glass" devices it should stick out as the wrong thing to do unless absolutely necessary; not sure how to achieve that, though.
