Re: Documentation contribution
Thanks guys
Re: Documentation contribution
Most System documents have two links following each "section": _Source_ _Edit_ Clicking on the `Edit` link will create a new Pull Request with the changes you make
Re: Documentation contribution
Pull request on the devel branch of [https://github.com/nim-lang/nim](https://github.com/nim-lang/nim)
Documentation contribution
What is the proper way to contribute to the documentation of the standard library?
Re: Thoughts on imports
> Writing `from blah import nil` for every import is ugly Probably less idiomatic/encouraged way should not be absolutely the same easy, as more idiomatic. So two extra words for the whole imports list should be OK, it could be like this: `from xxx, yyy import nil`.
Re: Thoughts on imports
Looks like my `load` macro example has become `require` [on Reddit](https://www.reddit.com/r/nim/comments/6p0q72/help_with_a_macro/) (which I am now boycotting, along with the rest of social media, due to the _still_-unexplained [shadow censorship incident](https://www.reddit.com/r/bugs/comments/6kxn6p/comment_shadowcensored_presumably_automatically/))... Without an official keyword, we'll probably soon see people baking their own variants. [Prolog](https://rosettacode.org/wiki/Include_a_file#Prolog) `consult`, anyone? * * * > How so? That needs to be fixed then. [https://github.com/nim-lang/Nim/issues/6134](https://github.com/nim-lang/Nim/issues/6134)
Re: Thoughts on imports
@Libman Oh man, I've spend this whole day learning about how macros in Nim work only to recreate the exact same macro you've listed. Only I used `require` for its name. Too bad it doesn't read args from the next line like usual sections can.
Re: Thoughts on imports
> Yeah, unused imports still increase binary size despite deadCodeElim > (--d:release --opt:size). In a perfect world that would not be the case... How so? That needs to be fixed then.
Re: Thoughts on imports
> if the condition is never met importing xyz is wasteful
Yeah, unused imports still increase binary size despite deadCodeElim
(`--d:release` `--opt:size`). In a perfect world that would not be the case...
* * *
> you can use `from math import nil`
Yup. But I [still](https://irclogs.nim-lang.org/15-06-2017.html) think Nim
needs better syntax sugar for doing this, since preference for old-fashioned
mandatory namespace prefixes are such a common complaint
[(ex)](https://www.reddit.com/r/Python/comments/6gwv4a/a_glance_at_the_pythonlookalike_nim_programming/diu3g2y/).
Writing `from blah import nil` for every import is ugly. One is tempted to do
something like:
macro load*(modulesSeq: varargs[untyped]): untyped =
result = newStmtList()
for module in modulesSeq:
result.add parseStmt("from " & $module & " import nil")
load os, math
But doing this through an ad-hoc macro has some down-sides. **@Araq, how about
adding a built-in keyword like that before v1.0?**
If so, we should discuss if the keyword name `load` is ideal. I first thought
about using `use`, but that would remind people of Perl, while `import` reminds
people of Python - this would be topsy-turvy of how those two languages behave
regarding mandatory namespace prefixes. It's of course too late to rename the
`import` keyword. So it would mean: "not _just_ `load`, but _also_ `import`
into current namespace".
* * *
> runtime imports are not really possible in Nim because Nim is not an
> interpreted language
Nitpick: Nim is a language that S2S-compiles to a "not interpreted" (C, a
machine code targeting language) target, by default. But it can also compile to
interpreted languages as well (JS now, maybe others later).
Perhaps one could create a library for runtime imports, which would work
differently on different targets:
[JS](https://github.com/bluenote10/KaraxExamples/tree/master/JsIntegration),
[so/dll](https://nim-lang.org/docs/manual.html#foreign-function-interface-dynlib-pragma-for-import),
etc. (It would need to read the target code and generate headers at compile
time.) But that's a whole nother opera.
Re: String pattern matching / regular expression libs
Semi-related to this discussion: I just added Nim to the "Languages" section of Wikipedia's [[[Comparison of regular expression engines]]](https://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines). Someone more knowledgeable may wish to review and complete the "Language features" section there. That WP article is also interesting for its "Libraries" section on top, listing some permissively licensed PCRE alternatives around which Nim wrappers could be created. [Oniguruma](https://github.com/kkos/oniguruma) seems to be the leading contender.
Re: SDL2 and tuples as arguments
I guess one solution is to make a wrapper for the wrapper, and define a tuple type to feed it, but there seems like there should be a better way.
SDL2 and tuples as arguments
Hi, I'm having trouble with one of the procedures from the nim wrapper of sdl2 (nim-lang/sdl2). Specifically, I am trying to modify the color of a texture using setTextureColorMod(). The proc has a signature of (texture: texturePtr, r, g, b: uint8). The proc works fine if I add in the r, g, b values directly, but I can't find a way for it to accept a constant as an argument for the color. I can't use a tuple of uint8s, because the proc signature won't accept one - I guess it can't be unpacked? I feel like there must be an easy way to use a constant or something similar, but I can't figure it out. Any help would be appreciated!
Re: Having a hard time getting raylib bindings to work
I use ubuntu (well, xubuntu... technically). I doubt it's a bug on their side. Someone else would have tripped over this way before I would have and fixed it too.
