I have translated several programs from Python to Nim. Some of them where quite
simple and the translation was easy… for a human who knows what the program is
intended for. Other were a bit more complicated, but as these are programs I
wrote, there is little usage of dynamic features.
In any ca
This is strange. I get the long execution time in release mode without changing
a line in the code.
Why is the code not optimized in my case? To get the same behavior, I have to
use `-d:danger` instead of `-d:release`. May be it depends on some options of
the C compiler.
But, at least, we have
I changed the count for 1_000_000 to 100_000 and compiled your test with stable
and devel in release mode and my results are totally different. With version
1.2.4:
List: (seconds: 3, nanosecond: 71413798)
Table: (seconds: 0, nanosecond: 496792)
Run
So, I retried w
Which compiler did you use? Your program compiles correctly with 1.2.2 and
#devel on a Linux platform.
Note that your use of _echo_ is incorrect. As it is written, you write a tuple
which contains the string "\nProcessor count " and an int. To get what you
expect, you have to write:
Yes, you are right. But as Nim syntax doesn’t change a lot, this is
understandable. Nevertheless, there are several issues which should have been
solved (easier said than done of course).
The alternative plugin seems currently more active. So, this may be a better
choice in the future. But I th
Personally, I use the original plugin as I was not aware that an alternative
one exists. This plugin seems in fact quite recent (first commit by Gary M on
20 April) and, logically, there is some activity on it.
Besides, we can’t say that the original plugin is abandoned as the last commit
was o
I didn’t use `create` but reading the documentation it is clear that the
parameter `size`, whose default value is 1, is the number of elements to
allocate. That is, for a string, 8 bytes for a pointer and, under the hood, 8
bytes for the length, 8 bytes for the capacity and 0 bytes for the actua
When you allocate the string using `create`, it is initialized with zeroes. So
its capacity and its length are null as if it was assigned `""`. Then, if you
assign globally the string, it works, but not if you assign each element
individually.
But this works:
# test.nim
proc m
Sorry, but your second example is no more valid than the first one.
In both cases, as @Hlaaftana said, you need to declare the proc before
referencing it.
You need to provide an anonymous proc. This works:
import sugar
proc calc(a: int, b: int): (int) -> int =
let diff = a - b
result = proc (c: int): int =
result = c - diff
let diff_proc = calc(5, 6)
echo diff_proc(7)
Run
As far as I know, the default has not changed in 1.2. It’s better as some
programs will not work with `--gc:arc` without changes (if you have created
cycles). I suppose the default is likely to change with 2.0.
Note that I have been able to get the right result by compiling your example
with `--gc:arc`.
OK, thanks.
My question was for a catchable error but, indeed, maybe I could use two
exceptions in this case, one catchable, the other not catchable.
Hi,
Until now, the normal way to create a new exception type was by inheriting from
Exception. At least, it was the recommended way in the manual (and is still).
In the development version and in the new 1.2 version, this is considered bad
style and you get a warning if you inherit from Excepti
To make datum a variable you need to use mitems:
import options
type T = ref object
data: seq[Option[T]]
proc p(t: var T) =
for datum in t.data.mitems:
datum = none(T)
Run
I have tried to declare a `varargs[string | seq[string]]` but the compiler
rejects it. It seems that for `varargs`, more strict rules apply to avoid some
nasty problems.
But there may exist other problematic cases as Araq said. Adding – in a future
version – an explicit unpacking as he suggests
As regards implicit dereferencing, the compiler, when looking for the field "a"
has to detect that "p" is a reference or a pointer, check if the referenced
type is an object or a tuple and that it contains a field "a" and if this is OK
generate the code for dereferencing. I don’t see that as sty
There is no reason to use a special syntax to tell the compiler that expansion
is needed. Thanks to static typing, the compiler is able to see if the array or
sequence must be transmitted as a whole to the procedure or must be expanded.
In Python, you need a special syntax. Given a function _def
Exporting the type is not enough. You need to mark the fields you want to
export with an * too. So, here, put an * after "extraData":
type myModuleException* = ref object of Exception
extraData* : uint32
Run
As last year, I will use Nim and only Nim.
[https://github.com/lscrd/AdventOfCode2019](https://github.com/lscrd/AdventOfCode2019)
This is a great day for Nim. Many thanks to the development team.
Thanks for your explanation.
This is Interesting. Thank you.
So the documentation is wrong when it says: “Neither inline nor closure
iterators can be recursive”. Here:
[https://nim-lang.org/docs/manual.html#iterators-and-the-for-statement-first-class-iterators](https://nim-lang.org/docs/manual.html#iterators-and-the-for-sta
> Note that Nim iterators correspond to Python generators…
I would like, but they are less powerful. Generators can be recursive in Python
while iterators cannot. And in Python it’s easy to use a generator without a
_for_ loop thanks to the _next_ function.
But, despite these limitations, itera
You are right, I was too restrictive regarding static typing. Provided the code
in the loop is compatible with each field type, it works.
You can iterate on an _openarray_ , of course.
proc p(x: openarray[int]) =
for val in x:
echo val
p([1, 2, 3])
p(@[4, 5, 6])
Run
It depends on authors. I said that French people generally consider 0 as being
neither positive nor negative. For instance, a positive temperature is above
0°C.
For the french mathematician group Nicolas Bourbaki, which is a well known
reference, zero is both positive and negative. But that not
Sorry, I’m French and for me positive means strictly positive (as negative
means strictly negative), but to avoid any ambiguity, I always use «
strictement positif » for numbers > 0 and « positif ou nul » for numbers ≥ 0.
Some authors (Bourbaki for instance) considers that zero is both a positiv
Yes, there is indeed a change in the documentation between 0.19.6 and 0.19.9.
Personally, for signed integers I would find more consistent to use an
arithmetic shift to the right. With a logical shift, _-2 shr 1_ is equal to
9223372036854775807 on a 64 bits machine which may seem odd. We would r
I have not been able to reproduce this behavior. On my Manjaro Linux with the
last development version (built with _choosenim_ ) _shr_ is a logical right
shift, not an arithmetic one. This is also the case with the last stable
version.
And there is already an arithmetic right shift in the syste
Very interesting explanation.
As regards Python floats, they are native floats (64 bits long in IEEE 754
format), not arbitrary precision floats. Only integers are in arbitrary
precision. So, I think that the rounding errors are also present in the Python
program.
To add to _mratsim_ answer, you can also write:
import math
echo 2.0^2 * 2.0
Run
and even:
import math
echo 2.0^2 * 2
Run
In the latter code, the compiler convert 2 to 2.0 as it knows that a float is
expected. So, there is
I have used "gintro" with a TreeView. There are some things that do not work
the way I want (for instance the impossibility in Gtk3 to use alternate colors
for rows if the theme doesn’t provide it), so I still use my previous version
in gtk2. But here is how I proceed using _gintro_.
To allocat
Yes, you are right :-(. I forgot your requirement.
I fear there is no simple solution in this case, as you need to create the
object with the right type (to get the right size) and, at this moment, you
don’t have access to the private field. In fact, I’m sure that my first
solution with a cast
In this direction, to make it work, you have to do a cast:
proc newElementA(): ElementA =
cast[ElementA](newElement("A"))
Run
Another way consists to create a proc _initElement_ in _lib_ :
proc initElement*(elem: Element, id: string) =
elem.id
Sorry, I don’t see any aliasing in the code presented by `e`. The float value
is copied into an array of uint8 and there is no sharing of memory. It would be
different is one had used pointers, of course.
But, with unions, you have an aliasing as two fields refer to the same address
in the unio
No, without `global` it works and even this way:
def f():
print(x)
x = 4
f()
Run
But, the following doesn’t work and you have indeed to specify `global` (quite
different from Nim here as the “equivalent” would be `var x = 2 * x + 1` which
compiles
> There is no var keyword that you have to use when first create a variable. My
> "implicit var" proposal was for Nim to behave the same way for b = 2 as for
> var b = 2. You'd still get b type-inferred as int with static checking like
> in Crystal (or like with b := 2 in Go).
But there are cas
I don’t understand when you are saying that `b = 2` means `let b = 2` in
Python. Python has neither an equivalent of `var`, nor an equivalent of `let`.
When you write `b = 2`, you simply bind the object `2` to the name `b`. And
that doesn't prevent you to write afterwards `b += 1`, so it certain
I mostly agree with you and I am also rather optimistic for the future of Nim.
The community is tiny, but composed of truly motivated Nim users. My remark
about the small number of Nim users in Project Euler was there only to give
true numbers, and yes, Nim is certainly a marginal language here.
Yes, I can understand that you don’t appreciate Project Euler tasks. They may
seem less fun that, for example, those of Advent of Code. Most of them have a
strong mathematical nature and not everybody likes to deal with prime numbers
and totient function. So, you have to like mathematics or, mor
> Any ideas how to make it more popular? :-)
In the Project Euler community, this is not easy. Members are mostly
mathematicians and either they use main languages such as C, C++, Java, Python,
or they use languages such as Haskell (6863 users!) or more logically
Mathematica or Matlab. For thos
Hi all,
In another thread, someone ( _mratsim_ ) has spoken of a lot of users using Nim
for Project Euler. Maybe members of this “project” have done a lot of noise to
make illusion, but I want to give some more precise data regarding Nim and
Project Euler.
For those who do not know about this
For Python users, the syntax of Nim is not disturbing whereas this may be an
obstacle for those using another language. But, this is a trap. Despite their
syntax similarities, Python and Nim are very different languages and those who
are not aware of the constraints of a statically typed and non
I encountered the same difficulties. The fact that the problem provides several
test cases shows that the creators are aware of the difficulties. There are
several traps to fall into. And, for part 2, there are also performance issues.
For now, this problem has been the most challenging. Day 16
It seems that I was not in a great shape yesterday. There are some errors in my
message.
Indeed, a set of _range[ '0'..'9']_ will occupy 58 bits rounded to 64, not 9
bits rounded to 16. I will have to declare _Digit_ as a _range[0..9]_ to use
only 10 bits (not 9!) rounded to 16 and, in this cas
Thanks, it works!
But, as this only hides the warning and doesn’t suppress the check , I hope
that, despite what is said in the message, this warning will never become a
compile time error.
Hi,
When trying to solve some project Euler problem, I declared something like that:
import tables
const N = 16
type Digit = range['0'..'9']
var counters: array[N, TableCount[Digit]]
var exclusion: array[N, set[Digit]]
. . .
Run
and got the usual wa
Marking the type as exported is not sufficient. You have to mark the field pos
as exported (and also for the field dir I guess):
import nico/vec
type
GameObject* = ref object of RootObj
pos*: Vec2i
Player* = ref object of GameObject
dir*: i
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
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
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
> Stating that the same group of people dislike style insensitivity, GC, etc is
> a bold claim.
That’s not what I meant. I suppose I should have been more precise :-).
What I mean is that some people will find any reason to reject a language they
don’t like. And why do they not like this langua
I think that changing Nim to get more users is exactly what should not be done.
A language should not be adapted to suit the opinion of a majority of potential
users. Rather users have to learn other ways to work.
For me, many of those who definitively rejected Nim for its case insensivity
will
For me, this idea of voting is strange and even makes me uncomfortable. Does
the creator of the language agree with this procedure? If this is not the case,
we are following a wrong path here.
Moreover, are we going to vote for each presumably controversial topic, for
instance the syntactically
The message is misleading. "result" is the one at line 325 in system.nim, i.e.
the HSlice which is returned by the proc.
When instanciating the slice (".."), the fields "a" and "b" of "result" (a
slice) should be initialized with 0. But "b" is of type "range[8..10] and
cannot be initialized wit
In any case, you have to indicate at least that the first value is a byte. For
instance:
const LOOKUP_TABLE: array[4, byte] = [1'u8, 2, 3, 4]
Run
or more elegant
const LOOKUP_TABLE: array[4, byte] = [byte 1, 2, 3, 4]
Run
I have already encountered this error. As far as I remember, it occurs when you
use "var" in a proc whereas the type is a "ref object". If you change this in
your example, the error disappears.
type
Animal* = ref object of RootObj
age*: int
proc init(x: Animal
Here is your example translated to Nim using a method for "cry".
type
Animal* = ref object of RootObj
weightOfAnimal*: int
method cry(x: Animal) {.base.} =
echo "Animal is crying..."
type Dog* = ref object of Animal
name*: string
The copy doesn’t worry me if the behavior is consistent. But, there is
something I don’t understand.
In this program
proc p() =
let x = "abc"
Run
there is a string copy (and an allocation) for "x".
But in this one
proc p() =
var a = "abc"
To add to Stephan's answer, I have tried both packages when solving puzzles
from "Euler project":
* "bigints" is pure Nim and has the best API in my opinion, but it is about
twice slower than "bignum" and has some issues (see comments in source); it is
still a work in progress.
* "bignum" u
Yes, I understand. Indeed, it seemed to me it was an issue quite difficult to
solve. But, it is something very unlikely to happen in real programs and, so
far, nobody has encountered these problems. I have built these examples when I
have suspected that something may be wrong in some cases and t
Yes, I think the last example is the most annoying one as, to solve it, we have
to do a copy which is just something we don't want to do for obvious
performance reasons. I have tried to change the parameter type from sequence to
openarray with same result. And with an array instead of a sequence
Yes, I know it works with **var**. I have once written a statement let b = a
in a program, **a** being a sequence, with a comment # No copy. Reading this
some months later, I was not sure that there is actually no copy (and I thought
that, in fact, a copy is needed). So I done some checks and
I use 0.18.0, so the results may differ, of course. When running in the
browser, I get the same results as with version 0.18.0.
Maybe the compiler does some optimization but it cannot consider that _a_ and
_b_ are not used in another place: they are used by _echo_.
Assigning with **var** works,
I would like to discuss a problem I have encountered and for which I have
submitted a report on the bug tracker with a different version using
_newSeqOfCap_.
Here is a simple program:
proc p() =
var a = @[0, 1, 2]
let b = a
a.add(3)
echo a # @[0, 1, 2, 3]
You have not convinced me either. I have shown that on 32 bits platform, when a
variable is initialized without explicit type, the current rule will cause
problems as the variable size will vary according to the initialization value.
I think it's really a bigger problem that which seems a proble
@StasB
> Not sure what you mean. Can you state what you think the general rule is?
The general rule is written in the manual: "Literals without a type suffix are
of the type **int** , unless the literal contains a dot or **E|e** in which
case it is of type **float**. " This is the reason why I
I don't see why 10_000_000_000 could not be an **int** on a 64 bits platform
and produce an error on a 32 bits platform. As there is always the possibility
to write 10_000_000_000 'i64, this is not a restriction.
Furthermore, it would make things consistent as const c = 10 * 1_000_000_000
would
Thank you all for your answers. Is seems that my first replies are still
blocked .
@Stefan_Salewski
I didn't remember this paragraph, but indeed the compiler does what is written
in the manual. However, in "Numerical constants" is is said that "Literals
without a type suffix are of the type **
Seems OK, now
Thank you. I will wait until my messages appear in the thread.
Hi. I submitted my first post some time ago without any problem, but my replies
do not appear in the thread. To reply, I click on "reply", type my message,
click on "preview" (to check if anything is OK) then on "submit". The window
closes, but that's all. I have tried three times, first with th
Hi. This is my first post on this forum, but I have used Nim for some time now
(in particular, the Gtk3 bindings).
Compiling one of my old programs with the new 0.18 version, I have encountered
an error which can be sum up to a single statement:
var x: int = 10_000_000_000
Th
74 matches
Mail list logo
