> I think it might be easier to overlook if there was a tool that could that
> could format the code in one way or another, or a linter of sorts that would
> enforce a particular style?
`--styleCheck:hint` or `--styleCheck:error` can be passed to the compiler which
enforces that all symbols in
> I've found that the style insensitivity is by far the biggest obstacle I've
> found in Nim adoption at my company.
I can definitely say it's incorrect finding. 99% companies like to play safe,
use whatever popular without really understand pros/cons of what they're using.
Because they don't w
The reason the C sometimes relied upon underscores at one time was because in
the good old days many system only supported one case. Now that all modern
systems have upper and lower case, it makes sense to use an initial uppercase
letter to use the same descriptive for a type rather than variabl
When people say it's an obstacle for adoption, exactly in what way? Do you mean
that they actually tried to compile something, and it failed because of
identifiers being considered the same in Nim? Or just that they looked at the
web page, saw that and that is the thing they decided to use as th
Does ANYONE know how to use memory regions beyond the examples that are
available on the forum? These examples tend to consist of -
var rx: MemRegion
withRegion rx:
discard 0
Run
While this example code proves regions work - it doesn't prove much beyond
Has anyone written something like 'Expect' in Nim?
Expect is a tool for wrapping command-line commands with a parser that can
execute the command and then interpret the results.
Commonly used as one of the basic pieces for constructing command execution
tools like ansible or fabric.
(see 'Expl
Although I do not use Nim everyday (I'd like to!) - I've found that the style
insensitivity is by far the biggest obstacle I've found in Nim adoption at my
company.
I think it might be easier to overlook if there was a tool that could that
could format the code in one way or another, or a linte
Completely agree. If that is the main benefit, why not focus on giving a non
controversial solution to that particular problem?
> I thought if is used in run-time while when is for compile-time, is not like
> that?
Generally it is of course.
But I just tested what I wrote above, and my memory was indeed correct: "echo
(a +1)" does not compile for your example code, but replacing if with when
makes it compile again. As
Yes, I agree that this function is not generally what is needed. Most of the
time, we want a string and "format" is what should be used. I didn’t wanted to
discuss the decision, I was just curious to know if there exists situations
where it actually gives a wrong result.
Now, in my case, this i
@gemath Actually, a pure Nim library could not respect NEP1 and follow a
different naming style. If I use such library, I will call it using NEP1
identifiers - no importc in sight.
I think it could make sense to add a warning in the compiler for the case where
mixed styles are used **inside** t
You could put those even into an int. But yeah, sure. Though note that Variant
will not distinguish type aliases.
Can i put data types like HMENU, HWND, HPEN, HBRUSH, in a variant ?
One person wouldn't use multiple styles, a big team of developers, it's
different story.
Imagine in real big project, when you hire consultants to work on part of a
project, and they write their code in a different style than that of the team,
which they are using for months, and then you need
What's new is my answer. :P
I don't know, but this post already asked several months ago and 90% of post
wording is same, :/
[https://forum.nim-lang.org/t/4049](https://forum.nim-lang.org/t/4049)
> But then the if statement makes not much sense any more, it should be a when.
> But when is compile time of course. So for me here is no actual runtime test
> at all.
I thought `if` is used in run-time while `when` is for compile-time, is not
like that?
Our plans for the future are more general but improve the support for wasm as a
side-effect:
* Make the language more agnostic to the used underlying allocators
(destructors).
* Introduce an optional code transformation that maps exception handling to
`if` statements.
* Make the tracing g
Here's something that could help:
[https://github.com/yglukhov/variant](https://github.com/yglukhov/variant). And
+1 in most cases you can/should go with static typing.
We decided that this variant of round is almost never what you should use. The
stdlib needs to avoid procs that trick you into programming bugs. If you
**really** need it, use this code:
proc myRound*[T: float32|float64](x: T, places: int): T=
if places == 0:
result =
@kcvinu This is a very interesting experiment, and I'll be interested in seeing
if it's possible for it to work well.
Still, keep in mind, that this is just veeery unusal in normal Nim code: I
doubt I'll ever use anything like that even if it works, because 1) one can use
normal types / variant
> Does anyone out there routinely use this feature of diverging from the style
> of an import or as I mentioned just follow the lib's conventions?
I do. I do not feel it to be problematic how the Nim lib naming is but I always
and consistently use my own style in my own code (CamelCase for vars,
> you are not supposed to use style insensitivity to mix styles inside a
> codebase
If that was the case, and I wish it was, style insensitivity would at least be
limited to the `import`, `importcpp` and `importc` statements to be resolved
with symbol binding.
Side note: Adapting to a libraries style _can_ also been as an advantage
("Obviously code from elsewhere").
In fact, almost all of those questions _can_ be seen this or that way.
Based on some decades experience I can't remember having felt that some
libraries naming convention was problematic
It is just an experiment. I love ArrayList in vb.net and list in python. I am
trying to implement something like them in Nim. I know, that most of the time
we can make a user defined type and declare a seq contains that type will work.
But this is also a good feature of a language.
This is my a
Does anyone out there routinely use this feature of diverging from the style of
an `import` or as I mentioned just follow the lib's conventions? Part of
@dom96's survey should perhaps ask if that aspect is just a "theoretical
nicety".
I mean, someone cared enough about project-internal style co
Could you please post a code snippet using "of" instead of "is"
Hey @kcvinu, what are you trying to do generally with this approach? It seems
interesting, but it's very rarely needed to do something like that in normal
Nim code: I think you're trying to recreate some Python/Ruby code patterns, but
maybe you can solve this in a generally different way (e.g. o
Thanks man. Great help. :)
It is installed, but it has to be in the same directory as the rest, else it
does not appear to be recognized. That makes sense, of course. It's as you
describe now ... and I probably should have upgraded to 0.19 earlier.
@allochi that experiment does not really make much sense, because you are not
supposed to use style insensitivity to mix styles inside a codebase, unless you
are masochistic. Style insensitivity is used to take a library written in a
different style and use inside your project without having to
Here is a little experiment.
1. Write a sample code, explicitly use style insensitive in the code
2. Show it to some colleagues who doesn't know nim
3. Try to explain to them the code without bringing style insensitive up
unless they ask
4. They will definitely ask why you have get_data()
When sdl.nim is missing (package not installed) you should get an error at
compile time. When a dll is missing, you should get an error when you launch
your executable.
For inherited types (i.e. runtime types) you can use `of` instead of `is`.
Hello all,
When compiling (with development version of Nim) a module which uses the
"round" function from the "math" module, more precisely the "round" function
with two arguments (the second one being the number of positions after decimal
point), I got a deprecation warning. The recommended wa
Okay, so apparently I've mixed up example files ... and it's not the dll that's
missing, but the package. I've figured it out by looking at the tests in
nim/tests/.../sdl. I saw "import sdl" and went "oh" That doesn't explain
why i have the dll problem with csfml, but at least this is probab
Ah okay, so apparently the sdl.nim is **required** to work, and it is not
actually asking for the dll (like it did in the old version) but actually asks
for sdl.NIM ... man ...
In Python everything is a ref object. When porting you might get the wrong
result if you use tables with value semantics instead of TableRef if the
Table/TableRef is copied.
[https://irclogs.nim-lang.org/26-10-2018.html#09:38:42](https://irclogs.nim-lang.org/26-10-2018.html#09:38:42)
Can someone explain?
I think a vote would be fine. Ballot box stuffing is possible, but probably
identifiable via sheer numbers since the Nim community is so small unless the
vote gets HackerNews'd or Slashdotted. I also agree that the people who matter
most would never participate in such a vote because they've alr
mashingan, your above example looks a bit funny and strange to me.
Your printout proc is generic, so due to actual calls with int, string and
float parameters, we should actually get 3 distinct instances of that proc in
executable. And actual parameter decides which actual instance is called. Bu
Greetings. I don't know why it is not working.
I have updated to the latest nim. I have made sure that I have the correct dll
installed, which is the 64bit version. I have placed the dll everywhere where
it might make sense, including system32 and nimbin and, of course, the local
directory.
Wh
I went from Go and recently had an interest in Web Assembly, but I do not feel
that Go is particularly good for it, mainly due to the large binary size. So I
look around for a new language and Nim seems perfect for it, modern, fast and
makes even binary files even under the web.
Have I found so
Thanks for the precision. But is it really style insensitivity? That’s what I
thought until I understood that it is only a consequence of ignoring the
underscores in identifiers as underscores are ignored in numbers.
So Nim style insensitivity may be seen only a consequence of Nim case
insensit
Just because code has uniform _naming-style_ doesn't make it easier to read,
and vice-versa.
By non-programmer point-of-view, glorious_function and gloriusFunction is
(about) same, read same, and (almost) look same, and that's only natural.
> Types exist at compile-time only (opposite to Ruby, Python and the like).
I just want to check the type at runtime and want to make some changes in
program. So i am assuming i cant do it in nim.
> I just want to check the type at runtime
[https://nim-lang.org/docs/typeinfo.html](https://nim-lang.org/docs/typeinfo.html)
We can turn it anyway we like but we must not go against the vital rule that a
compiler must not ever change an identifier behind the developers back.
leading '_' can be discussed (I'm pro but can accept Nim staying against it).
Case sensitivity and/or rules (like types capital 1st. letter, vars
48 matches
Mail list logo
