Re: runnableExamples should generally be preferred to `.. code-block:: nim`
isn't the whole point of rst though that it's sufficiently structured to extract detailed code blocks to pass to the compiler? ie if you're not using this feature of rst, it's completely useless compared to markdown which has a much larger developer mindshare. tbh, I found the runnableExamples distracting to look at - they're syntax colored along with the rest of the actual code and it's hard to know when the example ends and real code begins (indent is not that clear) - they muddle the logic It also looked hard to surround examples with descriptive text - you have to start a comment block, end it, write a runnableexample, then start a new comment block which seems really ugly..
Re: runnableExamples should generally be preferred to `.. code-block:: nim`
regarding editors, the same applies - an editor could easily provide ide features in code block sections thanks to RST
unary operators are often best replaced by explicit names, eg: `%*` => toJson
IMO, unary operators are often best replaced by explicit names. For eg: %* in [https://nim-lang.github.io/Nim/json.html#%25%2A.m%2Cuntyped](https://nim-lang.github.io/Nim/json.html#%25%2A.m%2Cuntyped) would be best replaced by toJson (and %* could become a deprecated alias to it): macro `%*`(x: untyped): untyped Run Nim is not perl, the goal is not to minimize the number of characters we type at the expense of clarity (at least, minimizing the number of tokens we type is a better metric than minimizing the number of characters). %* seems like a perfect example of operator abuse.
Re: nim doc hypertext link
@geezer9 maybe send a bug report /feature request on [https://github.com/nim-lang/Nim/issues](https://github.com/nim-lang/Nim/issues) ?
Re: Capabilities of backend compiler and conditional flags
Seems indeed useful to have a standard library module for that.
Could be based on stuff like this :
const output = staticExec("cc --version")`
when output.hasSomeProperty: ... # eg: check version > something
Run
const hasLTO = not staticExec("clang -flto --version").contains("error")
when hasLTO: ...
Run
Capabilities of backend compiler and conditional flags
Increasingly, I've been running into situations where it would be beneficial, from a cross-platform and cross-compiler point of view, to selectively enable flags and features depending on the capabilities and defaults of the C compiler is being used. There is some support for doing stuff like `when gcc`, but it's crude. Let's say for example that a project would benefit from LTO compiles - what's the best way to enable this for compilers that support it and gracefully degrade to non-LTO? Only recent GCC versions support it. A similar situation arises with dialects - which one is the default for a given compiler (C99, C11, etc) changes over time, while something like a wrapper might need to force a particular version for a particular compiler - likewise for -arch flags and the like. Autoconf solves this pragmatically, simply by running tests for each interesting feature and spitting out a decision variable that can be used later in the build process - what would nim's approach be? A non-solution is to dump this one the user of the code (ie "go edit your nim.cfg") - this doesn't scale.
Re: what happened to Nim community survey 2018?
Yeah, sorry, I simply didn't get a chance to do the write up yet.
Re: runnableExamples should generally be preferred to `.. code-block:: nim`
Some of my `runnableExamples` also has `.. code-block:: nim` ;P Actually I changed from `when is_main_module:` to `runnableExamples` (for libs), is the correct way. I think is an awesome feature, because other lang have DocTests or the like (Python, Rust, etc), but the code is on comments, that means you dont have any features of the IDE/Editor you are using, like syntax highlight, etc, is still code on a comment.
runnableExamples should generally be preferred to `.. code-block:: nim`
.. code-block:: nim (or similar) tends to go out of date eg [1], unlike runnableExamples which is guaranteed to stay in sync. runnableExamples is also easier to write IMO. ## links /cc @dom96| ---|--- * for eg: [https://nim-lang.org/blog/2018/10/01/hacktoberfest-with-nim.html](https://nim-lang.org/blog/2018/10/01/hacktoberfest-with-nim.html) mentions .. code-block:: nim but makes no mention of runnableExamples * [1] [https://github.com/nim-lang/Nim/commit/a0ac0b9696f3a79fbde153c63878aea363b09ad4](https://github.com/nim-lang/Nim/commit/a0ac0b9696f3a79fbde153c63878aea363b09ad4)
what happened to Nim community survey 2018?
* [https://nim-lang.org/blog/2018/06/23/community-survey-2018.html](https://nim-lang.org/blog/2018/06/23/community-survey-2018.html) was launched in june ## links * [https://docs.google.com/forms/d/e/1FAIpQLSdWY315uYcL-5H0DD3T9_IqMKfHONTW45uZt5FvjfaYJK7kNA/closedform](https://docs.google.com/forms/d/e/1FAIpQLSdWY315uYcL-5H0DD3T9_IqMKfHONTW45uZt5FvjfaYJK7kNA/closedform)
Question regarding --warning[ProveField] and proc params
I recently learning about the --warning[ProveField] flag for object variants, and enjoy the increased level of type checking that it provides. However, I have a small issue using this flag alongside procedures that take a specific branch of the object variant. The procedures shouldn't be used on any of the other branches, and I was curious if I could indicate this to the compiler, so that I could get the compile time check on that procedures usage. I know I could get this behavior with a class hierarchy, but I prefer the object variant and it models the domain a lot better than a class hierarchy. I appreciate the help!
docgen user defined role
Can a user define a custom "role" for the interpretation of ## source comments by docgen? The site <[http://docutils.sourceforge.net/docs/howto/rst-roles.html](http://docutils.sourceforge.net/docs/howto/rst-roles.html)> explains how to do this, but the context is python programming. Can this be done for the **nim doc xxx.nim** command?
Re: Some questions about Nim compiler parameters
Thank you both, this helped alot!
