RFC:
if strutils has `toBin()`, `toHex()`, `toOctal()`, `intToStr()`
and from system.nim, the `$` operator is described as
`The stringify operator for an integer argument. Returns x converted to a
decimal string. $ is Nim's general way of spelling toString.`
why not add a helper proc to
Here you go
const allowedInts = {1, 3, 5, 8}
proc foo(bar:static[int]) =
static: assert bar in allowedInts, "Value " & $bar & " not allowed"
echo "Success"
foo(6)
const allowedInts = {1, 3, 5, 8}
proc foo(bar:static[int]) =
I guess we get spoiled with everything that is possible in Nim .
I've submitted a feature request:
[https://github.com/nim-lang/Nim/issues/6696](https://github.com/nim-lang/Nim/issues/6696)
Another hidden benefit of documentation is getting at the top of Google . I was
surprised today by looking at "inline iterator chaining" and there are 3 Nim
links, before Rust result.
Thanks a whole lot!
The Docs really need to get better by showing clear examples like this for just
about everything. It took way too long for me to search and not even find this,
and had to resort to asking how to do this here. I also agree the semantics for
doing this has to become a lot
Well, the only way to do type checking like this is through static analysis,
which is typically performed by the compiler. The other way to do this is to
make a variant of a procedure that accepts static parameters, and then use when
to test their value.
What would be the idiomatic way to do something like a compile time assert.
Say that you had proc foo(bar:int) where you want to restrict bar to values
1,3,5 and 8. I don't think you can use a range here because they are not
contiguous. But you could use a when to check at compile time, but
import strutils
let num = 10.123456789
echo num.formatFloat(ffDecimal, 4)
Cool, I didn't know how flexible you can process with MVTools. It sounds great
for recreating motion vectors. Then, there are solutions that have some kind of
optimality (like
[https://people.csail.mit.edu/celiu/OpticalFlow/)](https://people.csail.mit.edu/celiu/OpticalFlow/\)).
I might
let num = 10.123456789
echo( formatFloat(num) )
Could I get a little help here to make this work.
let num = 10
const x = 9
echo(num + x)
let num = 10.int
const x = 9
echo(num + x)
let num = 10.uint
const x = 9
echo(num + x)
> I'm not understanding, are you saying that destructors and move semantics are
> the resource management of Nim in the future? If so, what happens to the
> tracing GC, regions, and all that? If not, I don't know which uniform
> solution you are proposing.
Yes, that's what I am saying for the
That seems to be the case because you have to explicitly cast `let` s (or the
compiler assumes a default cast).
Must be a bug, because int is ConceptB also returns true.
What's makes one happy: Araq saying you're right.
Well, I guess what monster said about imperfect product with lots of grateful
users seems more satisfying than a perfect product only you dare to use. ^^"
That's one of the reasons why writing docs and examples is important --- this
way more
Not exactly as nice as it can't handle positional arguments, can it?
That's impossible right now, I think.
You can use a named tuple for it:
proc add(p: int): int {.echoName: (number: 42, name: "p1").} =
result = p + 1
I want to do the equivalent to the following but as a macro:
`{.pragma: align64, codegenDecl: "$# $# __attribute__((aligned(64)))".}`
Macros as pragmas for procs work fine, is it also available for variables?
macro align64*(x: untyped): untyped =
# expectKind(x, nnkIdent)
And hopefully we will soon have string interpolation in Nim
([PR](https://github.com/nim-lang/Nim/pull/6507)). Then it would be something
like this (or similar, language is still in discussion):
echo "$x%.4f"
About concept body proc syntax:
type
ConceptA = int # to avoid the bug
ConceptB = concept c
# both of these work:
# c.myProc(ConceptA) # standard
proc myProc(c: Obj, x: ConceptA)# declarative
I have a module split into different files, let's say f1.nim, f2.nim, f3.nim
that stay in the myModule folder, then I have a file called index.nim which
does
include f1,f2,f3
then I can import myModule from a file sibling to the myModule directory
writing
read
[here](https://nim-lang.org/docs/strutils.html#formatFloat,float,FloatFormatMode,range\[\],Char)
I compute a floating point number `x`. How do I use `echo|write.stdout` to
output it with just 4 decimal digits showing?
Uh strange, I tried it here
[https://glot.io/snippets/ev7buwzukn](https://glot.io/snippets/ev7buwzukn) and
it worked fine, it's probably a regression.
> Apparent for numerical constants, when you do this: const modpg = 2310 the
> compiler will convert it to whatever is required to make math operations work
> (at least it did so in my code).
>
> But doing: const modpg = parameter[0] causes it to retain the int casting
> from the proc, which
@Udiknedormin Rust has absolutely no tracing GC at all.
@Araq I'm not understanding, are you saying that destructors and move semantics
are the resource management of Nim in the future? If so, what happens to the
tracing GC, regions, and all that? If not, I don't know which uniform solution
I don't know if this is currently possible, but it would be nice to have.
It seems I could theoretically speed the execution of this code.
proc segsieve(Kmax: uint, KB: int) = # for Kn resgroups|bytes in segment
let Ks = KB# make default seg size
What I was trying to get at is how to make the generated constant values behave
like coding specific numerical numbers.
Apparent for numerical constants, when you do this: `const modpg = 2310` the
compiler will convert it to whatever is required to make math operations work
(at least it did so
> I remember you always saying people who want to limit GC usage just don't get
> it and it'll be fast anyway so why bother. Of course destructors have
> advantages of their own (like deterministic freeing you mentioned) but if you
> say Nim's GC is so blazingly fast (I don't doubt it, I just
Pass a tuple to the macro.
proc add(p: int): int {.echoName: (42, "p1").} =
result = p + 1
@Krux02
Isn't it true only for floating-point calculations?
It would be sad if it was possible as it would (probably) mean that Nim is just
a syntactic sugar.
@Araq Nice riposte. By the way: I never noticed {} is a valid multi-argument
operator, actually! It looks a little... unnimish. ^^"
Sorry to hear it breaks for you, it works on my compiler.
But give quote + getAst at try, it's recommended over quote-do anyway, if I
recall.
import macros
macro decDumbType(): untyped =
let sym = genSym(nnkType, "Dumb")
template decl(ty) =
type Dumb =
@mratsim
I know it's an offtop anyway but... please correct me if I'm wrong, but as far
as I know MPI-3 provides data parallelism both across a distributed AND shared
memory systems. It seems quite widely supported.
@ctTypeNames It's not necessary to only access the data at compile-time. Just
assign the compTime var to a const and voila --- you have both compile time
read-write access AND runtime read access.
@rayman22201 As far as I know, destructors can be slower in no-single-ownership
environments. That's why some languages (e.x. Rust) do the opposite of what Nim
is doing now --- they introduce optional GC for cases when it's useful / more
natural.
@Araq > Destructors, assignment operators, the
Wow, your version actually makes the compiler crash without any error messages.
I'm on version 0.17.3 on Windows 10, going to file an issue.
@jxy Good to know it was already implemented as I was actually planning to
implement it myself. ^^" I haven't tried your lib in practice but the code
looks pretty nice.
40 matches
Mail list logo
