As we all know, nim seperates the procedures that operate on an object from the
data of the object itself. I understand the thinking and largely agree with it.
However, a side-effect of this is that when importing an object from a module,
it is difficult to control what is being imported. Such c
"anti UFCS fire"? There is no UFCS involved here. "vexing parse" also has
nothing to do with it. Hate what you want but an informed opinion can't hurt
either.
No, not aware of any. Tried these?:
[https://nimble.directory/search?query=gmp](https://nimble.directory/search?query=gmp)
A long program startup is often caused by an antivir program.
> the rationale is Python
Python's ranges have upper limit excluded, while Nim has upper limit included.
To mimic Python's range, use `..<`.
@miran certainly, the rationale is Python:
myString = "Some String"
print(myString[0 :]) # echos "Some String"
print(myString[0 : -1]) # echos "Some Strin"
That issue you linked explains it, thanks. I will mark this as solved.
I use the UI0.9 module examples, compiled by release model program, first run
in the windows environment, you need to wait a few seconds before they can be
displayed. And the interface with IUP compiler module does not have this
problem. It's weird.Is there a problem with libui.dll?
> I had the same code from pre-0.18.0 and it worked with ^0,
This reminds me of [this issue](https://github.com/nim-lang/Nim/issues/7444).
The previous behaviour, where null terminator is ignored, is just wrong. You
should change your program and use `^1` for the last character.
* * *
Btw, sin
Why not just treat `discard` like a function call which takes another function
call? Then `discard fun x, y` would parse as `discard(fun(x), y)`, just like
with, say, `echo`. Then it just makes sense.
Hi Nim Community,
Does anyone aware of usable MPFR library wrapper for Nim? I fail to find it in
the packages repo.
Thank you
Thanks @Krux02,
I had the same code from pre-0.18.0 and it worked with **^0** , then recompiled
it with 0.18.1 and it added the terminator, that is why I was confused. Then it
seems to be a change?
Sorry again for the mistake guys.
well you have a bug in your code, `^0` actually indexes the 0 terminator of a
string, and this behavior is correct. Use `^1` instead.
Sorry, my mistake! I showed the wrong code, it should be:
var myString = "Some String"
echo "'", myString[0 .. ^0], "'"
Sorry guys! Is this a regression?
Tested on Windows 10 x64, Nim 0.18.1 x64, works for me, no binary zero / space.
it took me a good minute to understand what you said @mashingan. That is a
vexing parse in my opinion, and only some more gasoline on my anti UFCS fire.
It's sad that I end up with negative judgments of a feature that sounds so
marvelous on paper. (and I like the command call syntax, spaces with
Thanks @miran,
It may have been introduced in one of the mid 0.18.0 versions, because I tried
it again on a friends **Windows 10 x64, Nim 0.18.1 x64** machine and the error
is present.
@miran, could you perhaps try it with a newer version of Nim?
Thanks
Windows, version 0.18.0:
'Some String'
Araq, `{.experimental.}`, that's an exceptionally (haha) pragmatic and likable
plan! Even the exceptions are fine with an exception-free core because that
makes a no-exceptions flag quite feasible in the future, when a better option
emerges.
What about the crufty / obsolete / inconsistent stuff
Can someone with Windows please confirm the error, please?
Works for me too.
Just tested it on Void Linux x64, with Nim 0.18.1 (recompiled a few hours ago
with choosenim).
Pre 0.18.0:
var myString = "Some String"
echo "'", myString, "'" # --> echos 'Some String'
Post 0.18.0:
var myString = "Some String"
echo "'", myString, "'" # --> echos 'Some String ', notice the space (null
character)
Is this here to stay or a reg
Weird regression. Works for me on OSX.
macro styledEchoPrint*(m: varargs[untyped]): typed = ## partially lifted from
an earler macro in terminal.nim and removed new line result =
newNimNode(nnkStmtList) for i in countup(0, m.len - 1):
result.add(newCall(bindSym"styledEchoProcessArg", m[i]))
result.add(newCall(bindSym"write", bindSym
I see warnings that callsite() is being deprecated.
I use this macro and would like to know how to rewrite
it without using callsite() to achieve the same effect.
macro styledEchoPrint*(m: varargs[untyped]): typed =
## partially lifted from an earler macro in terminal.nim and
@didlybom The names follow
[https://nim-lang.org/docs/apis.html](https://nim-lang.org/docs/apis.html) (a
document that is not well known). `initT` is used for value-based types, `newT`
for pointer-based types. `newSeq` and `newString` depart from it because they
were created early on.
One small thing that feels inconsistent in the standard library (and which has
confused me a bit since I started using nim) is that in addition to the new
keyword different standard library classes have different new and/or init
procedures. For example there is newSeq and newSeqWith, newTable, n
@Araq sounds like a good plan to me. If that plan was implemented would it be
feasible to launch V1 by end of June?
I think v1 plan should be a plan that allows v1 launch this year.
If Nim used Swift release strategy it would probably be version 11 by now.
27 matches
Mail list logo
