> since I haven't seen
Search for "nim kernel" at github, there is also
[https://github.com/samanthadoran/Mero](https://github.com/samanthadoran/Mero)
[https://github.com/pascalmouret/assyria](https://github.com/pascalmouret/assyria)
See official tutorial part 2:
[https://nim-lang.org/docs/tut2.html#generics](https://nim-lang.org/docs/tut2.html#generics)
You may see Araq's reply in
[https://forum.nim-lang.org/t/4827#30222](https://forum.nim-lang.org/t/4827#30222)
If this really should be not spam then you may see
[https://forum.nim-lang.org/t/5861](https://forum.nim-lang.org/t/5861)
I new tried it, but what is wrong with the this straight forward approach:
proc main(): int =
var
a: ptr int = cast[ptr int](alloc(sizeof(int)))
echo cast[int](a)
a[] = 10
echo a[]
dealloc(a)
a = nil
return 0
echo main()
Maybe something like
import tables, hashes
type
Node[T] = ref object
parent: Node[T]
children: seq[Node[T]]
data: T
Data = ref object
name: string
proc hash(d: Data): Hash =
hash(d.name)
proc
> it's a serious question,
Maybe. I hoped he would come back so that we would know for sure, but he did
not.
Well sometimes my answers may be wrong or bad, so it may be better to do not
answer at all and leave answers to the paid Nim devs, or at least native
english speakers. In am none of
> please write Nim code like this
Maybe I missed a lot, but I have no idea what that part of your answer may mean
and how it may help for the initial question.
It`s a bit hard to believe that this is a serious question because of
[https://nim-lang.org/docs/math.html#round%2CT%2Cint](https://nim-lang.org/docs/math.html#round%2CT%2Cint)
But maybe you missed that and have no CS experience.
The basic fact is that we can not present each decimal number
That may work too.
But currently I consider replacing compileOption("gc", "arc") with
defined(gcDestructors) because I have seen use of defined(gcDestructors) in Nim
stdlib code. I am not sure if that is best -- all the options are a bit
confusing.
From
[https://irclogs.nim-lang.org/23-02-2020.html#14:16:11](https://irclogs.nim-lang.org/23-02-2020.html#14:16:11)
[https://github.com/StefanSalewski/gintro/issues/66](https://github.com/StefanSalewski/gintro/issues/66)
it seems that your when defined(gcDestructors): is the more correct test,
Yes, something like that. I added --gc:arc support with finalizers some weeks
ago, and destructor support yesterday. Note that we do not really need
destructors for ARC, finalizers are ok also, I added them because of the
subclassing problem, see Araqs reply to filcuc and my last edit in
c2nim can translate most basic C and even Cpp code, problems can be C macros
and cpp classes, and somtimes it generates a div instead desired / for floating
point division. But it save some work and avoids errors.
When you change datatypes, you have to be careful, as float and integer
Have you done the transfer with c2nim tool? Seems that you did at least manual
modifications:
time : uint32 = 0
oldTime : uint32 = 0
time = getTicks()
var diff : uint32 = time - oldTime
var frameTime : float = float(diff) / 1000.0
Run
Time and
> "Why spaces instead of tabs?"
There are two valid reasons for spaces:
myproc(
a: int;
b: float
) =
Run
This formating scheme would not work with tabs.
And github inserts 8 spaces for a tab, which looks bad.
For me both arguments
Thanks for all your support.
Indeed it is partly my own bug, I call in generator script gen.nim
unintentionally something like
var s = newSeq[int]()
try:
for x in combinations(s, 1):
echo x
except:
discard
Run
Of course makes no sense with empty seq,
Thanks for confirming that a combinations() iterator is not available in std
lib yet.
Have just tried to explore Mr Behrends module, but I do not understand the code
nor the error messages when compiled with --gc:arc. OK, then I will fix oldgtk3
for now and wait with combinations() iterator.
You think it is still an ARC issue? I assumed that the problem is just that the
code of Mr Behrends is 6 years old now. But generally I still hope to have that
combinations() iterator from a more reliable source -- std lib or maintained
nimble package.
Yes, the Rosetta example seems to be outdated unfortunately, but one gets the
idea.
You may also consider
[https://nim-lang.org/docs/strscans.html](https://nim-lang.org/docs/strscans.html)
or
[https://nim-lang.org/docs/parseutils.html](https://nim-lang.org/docs/parseutils.html),
that may be
Is isDigit() really deprecated? I can not imagine a reason.
[https://github.com/nim-lang/Nim/blob/devel/lib/pure/strutils.nim#L144](https://github.com/nim-lang/Nim/blob/devel/lib/pure/strutils.nim#L144)
For the question, google points us to
I was just testing if installing gintro works when generator script is compiled
with --gc:arc already. (Of course that will be needed only when ARC will become
default for Nim.)
First trivial issue is with glib.nim from oldgtk3 generated by old c2nim years
ago,
const
#
Well, we may ask: Why do we have openArray proc parameter type at all, when
varargs works for multiple arguments, for a seq and for an array? So varargs
should be able to fully substitute openArray parameter type. Maybe varargs has
more overhead, or maybe there exists cases where we want to
For an openArray parameter you can pass an array or a seq, but only a single
one. For varargs parameter you can pass multiple arguments.
I think the explanation at
> [https://nim-lang.org/docs/manual.html#types-open-arrays](https://nim-lang.org/docs/manual.html#types-open-arrays)
is fine, but
Please stop spreading these wrong and unfriendly remarks!
> but there isn't any uptodate gtk3 bindings as far as I am concerned.
You did it already in
[https://forum.nim-lang.org/t/5657#35169](https://forum.nim-lang.org/t/5657#35169)
> Same pattern goes for gtk3. The only upto date gtk binding
Note that there are many tutorials available, the "Nim Days" is already
advanced and for special topics. See
[https://nim-lang.org/learn.html](https://nim-lang.org/learn.html). The
official Tutorial part 1 and 2 are a good start.
For your first question: Some people coming from Python have not
To get small executables with Nim you may try
nim c -d:danger --gc:arc -d:useMalloc -flto myprog.nim
Run
Im best case use also gcc10, it can generate smaller binaries than gcc9 with
-flto. (It shrinks my chess game to 105k.) Also there was a tutorial by Mr
Felsing
> found my suspicion confirmed. cast[PResult](s.x) had Nim copy the content (32
> bytes) rather than simply
Great. It would be nice if you could push minimal example code for that
behaviour to Nim issue tracker, it may be a bug. I personally avoid casts
myself, but I would not assume it
> I need no optimization help.
But you ask exactly for this -- for help optimizing the C -- Nim interface.
You know C well, and in the Nim cache directory there is all the C code
visible, so you could invest it. I don't think that even the brightest Nim devs
can just guess the problem.
For your first problem: It should be obvious that warnings of the C compiler
makes not much sense for Nim generated code, as warnings are mostly for human
errors. Would you care for such warnings when Nim would generate assembly
directly? Even extremly ugly or verbose C code is fine as long as
For really cluttered files like
[https://github.com/StefanSalewski/gintro/blob/master/tests/gen.nim](https://github.com/StefanSalewski/gintro/blob/master/tests/gen.nim)
it is not easy to find code segments which are never executed. In the past I
added 'echo' or 'assert false' statements when I
I think your code should not compile at all in its current form, as result =
ch[0] is an incompatible assignment, string to float.
Generally parallel processing is restricted in Nim currently with default GC,
as each thread has its own heap ans so passing data is difficult. I never used
No, you may read his post more carefully, he wrote:
When your container should be dynamically sized, then you can not use an array,
as in Nim and legacy C an array is a fixed size block of memory. You will have
to use a pointer to array, and you have to dynamically allocate the block of
memory where the array lives. We have in Nim a data type
$ nimble search with
cascade:
url: https://github.com/citycide/cascade (git)
tags:macro, cascade, operator, dart, with
description: Method & assignment cascades for Nim, inspired by Smalltalk
& Dart.
license: MIT
website:
I know a bit more about gtk then about cairo. For gtk we have for example
[https://developer.gnome.org/gtk3/stable/GtkGrid.html#gtk-grid-get-child-at](https://developer.gnome.org/gtk3/stable/GtkGrid.html#gtk-grid-get-child-at)
where we get back objects from gtk. For cairo I have to inspects API
I told you recently in your Nim cairo issue that there is some sort of high
level cairo available in gintro for some years now, being not much testing, but
working with ARC now. So what is wrong with that one or what do you miss? And
what are you planing to do with your new cairo -- standalone
Nice to hear that. For memory leaks or corruption I generally test with
--gc:arc, -d:useMalloc and valgind, and generally get some leak reports. Not
only for gintro but also for pure Nim programs, see
[https://forum.nim-lang.org/t/5839](https://forum.nim-lang.org/t/5839) for
example. But I
I have just shipped gintro v0.7.0 with \--gc:arc support, so you may test your
app with it. See top of readme in
[https://github.com/StefanSalewski/gintro](https://github.com/StefanSalewski/gintro)
for details. There are some serious changes, so it may not work for you out of
the box. But we
type
O1 = object of RootObj
i: int
R1 = ref O1
proc `=destroy`(x: var O1) =
echo "destroy"
type
O2 = object of O1
j: int
R2 = ref O2
proc `=destroy`(x: var O2) =
`=destroy`(O1(x))
proc main =
var r =
The fact that currently finalizers have to be defined in the same module as the
corresponding object makes subclassing of objects by user impossible. For
example
>
The result of your code is not really surprising: As you specify the type Elem
as an or type, you get finally two instances of vec2() proc. One produces an
object containing float32 fields, and one producing an object containing
float64 fields. The decision to use which of then is here taken
I know that :-)
The point is that only the bottom most code above compiling with --gc:arc give
us the desired compile-time error. The topmost code compiles always without
error, the bottom most code compiles with default gc.
Well, it is indeed good enough, our actual code should most of the
This code compiles with default gc and with --gc:arc:
type
Language* = ref object
impl*: pointer
proc gBoxedFreePangoLanguage*(self: Language) =
discard
proc languageFromString*(): Language =
var l: Language
new(result)
Not only ~/Nim/tests/generics/trtree.nim but also the extended one with
bulkloading and nearest neightbour search from
[https://github.com/StefanSalewski/RTree](https://github.com/StefanSalewski/RTree).
And fully unchanged!
Running with valgrind we get
$ nim c --gc:arc
Creating bindings can be more difficult than programming in the target
language. I can program in C and a bit in C++. But creating Ruby bindings for
C/C++ was not easy. Low level C bindings can be generated with tools like
c2nim, nimterop and similar, high level bindings are not that easy
When you call it from C++ valgrind is happy?
And you are using --gc:arc ?
Have you tested storing Nim objects in std::vector before and that works fine?
I can not really help you, as I do know not much about C++ wrapping. But there
was a thread about std::vector mapping recently, and the core
type
Object* = ref object of RootRef
impl*: pointer
type
InitiallyUnowned* = ref object of Object
type
Widget* = ref object of InitiallyUnowned
proc finalizeGObject*[T](o: ref T) =
echo "finalizeGObject"
proc main =
var
For me it is silently.
Mixing float64 and float32 unintentionally can be dangerous for precision and
have disadvantage for performance.
May we allow that mixing only when lenientOps is imported or can compiler give
us warnings at least?
> i would deprecate finalizers
I may agree, but i think automatic calling of destructors for references does
only work with devel compiler and --gc:arc? At least this test was only working
with arc some weeks ago:
[https://forum.nim-lang.org/t/5786](https://forum.nim-lang.org/t/5786)
So code
There is no buy-able beginner book available beside Dom's "Nim in Action", but
there are many good tutorial-like beginner docs available now, see
[https://nim-lang.org/learn.html](https://nim-lang.org/learn.html)
See
[https://www.reddit.com/r/nim/comments/empsdf/using_nim_without_garbage_collection](https://www.reddit.com/r/nim/comments/empsdf/using_nim_without_garbage_collection)/
there someone asked in exactly the same wordings.
Now that finalizers work fine with --gc:arc there are two questions left:
[https://nim-lang.org/docs/system.html#new%2Cref.T%2Cproc%28ref.T%29](https://nim-lang.org/docs/system.html#new%2Cref.T%2Cproc%28ref.T%29)
>Note: The finalizer refers to the type T, not to the object! This means that
for
[https://irclogs.nim-lang.org/23-12-2019.html#16:10:45](https://irclogs.nim-lang.org/23-12-2019.html#16:10:45)
16:10:45 FromDiscord the best simd wrapper is here:
[https://github.com/numforge/laser/blob/master/laser/simd.nim](https://github.com/numforge/laser/blob/master/laser/simd.nim)
But
A basic test is generally "when compiles()".
But I think your case can not really work: The user of your lib would import
your lib, and on the other hand your lib would import drive() proc from user
module. So you have cyclic imports.
Maybe your lib can define and export a proc var of type
I think I heard about that in nim forum long time ago, but tested only with
default gc, where destroy is not called. But with ARC it is called indeed
currently, and gc_ref/unref seems to work also, so gintro and other packages
using finalizers may survive.
type
O = object
That is great.
But my feeling is that there are two problems still: First, when I visited that
page for the first time, then there was a proc square() available for testing,
but there was no ASM code for it. Seems the reason is that nim compiler
generates code for it only when it is called, so
The optimizing C compiler generates generally very good code for all the cases,
but when you really need utmost performance you may inspect the generated
assembler code. The cast to array may be a good solution when you need indeed
bytes as result, but when you need ints as result, only with
> i did not understand what is happening there,
There is nothing special. First it has not to be a template, a proc would do.
And you have to know only masking and shifting. You shift the bits right, and
then mask all but the lower 8 bits. Same as in C. Another way is casting to
array of bytes
Congratulations, the first real gintro/GTK3 app. And even with Windows support.
Great work!
I think that is an old known issue:
[https://github.com/nim-lang/nimble/issues/318](https://github.com/nim-lang/nimble/issues/318)
Also see
[https://github.com/nim-lang/Nim/issues/4441](https://github.com/nim-lang/Nim/issues/4441)
See
[https://forum.nim-lang.org/t/5353](https://forum.nim-lang.org/t/5353)
(I just asked google)
Have just done a short test why cdt module will crash with arc. Bellow is the
stripped down code.
Problem seems to be that initVector() creates a Vector3 while
initDelaunayTriangulation() expects a Vector2.
I always admitted that cdt is untested, that is the reason that it is not in
nimble.
> "gtkmm" which is a C++ wrapper and I'm quite sure it uses C++ destructors.
That is a fine hint. I don't know much about gtkmm, so I am not sure if they
really use C++ destructors or just plain gtk internal ref counting as C does.
Will ask Mr E.Bassi at gtk forum.
Found comment of mratsim:
Just tested
[https://github.com/StefanSalewski/cdt](https://github.com/StefanSalewski/cdt)
That one is indeed not really tested yet, so I did not make a nimble package
out of it to not pollute the nimble database. And it is again a bit complex.
# with import fix: import dt,
> That test is also part of our test suite and is so complex that it doesn't
> run on 32 bits, nor in C++
I was not aware that it is in test suite. But I was aware that it does not
compile with C++, and that nimsuggest has big problems with it. Will try to
investigate which problems with 32
Did just a first test.
The RTree test.nim from
[https://github.com/StefanSalewski/RTree/tree/master/tests](https://github.com/StefanSalewski/RTree/tree/master/tests)
compiles but running the executable gives an assertion error. Funny.
Unfortunately gintro apps seems not to compile, seems that
You may look for available symbols at
[https://nim-lang.org/docs/lib.html](https://nim-lang.org/docs/lib.html)
I think most P and T prefixes have vanished, was a legacy from Pascal notation.
Channel is available, TChannel not, so I assume TChannel is replaced with plain
Channel.
> I know that there is mod and %%.
There is also floorDiv() and floorMod(), maybe you like that better:
[https://nim-lang.org/docs/math.html#floorDiv%2CT%2CT](https://nim-lang.org/docs/math.html#floorDiv%2CT%2CT)
Why that keycode.int16 in Nim code? Seems that C-code passes cint.
Is trunc(float(n mod 10)).int not identical to plain n mod 10? And you may use
for i in countdown(5, 0) if you like.
Well, I wrote that above is [only] my personal view. I am in no way part of the
the Nim team, only an observer.
Obviously you have a different point of view, that is fine.
But what do you think when you see a lot serious unanswered questions on
stackoverflow? Are you not thinking that this
[https://stackoverflow.com/questions/tagged/nim-lang](https://stackoverflow.com/questions/tagged/nim-lang)
I just saw that you polluted stackoverflow with lots of mostly un-anwered,
duplicated questions, at the same time advertising yourself with a Dr degree,
giving the questions a serious
of wmu_DrawControl : # This line is causing the error !
Run
The value after of keyword in case statement have to be a constant, but you
define it in module a with let, which is not a const def.
More compact source code you may get with something like
var a: array[32, byte]
var p: ptr uint64
var myUint64: uint64 = 123456
p = cast[ptr uint64](addr a[8])
p[] = myUint64
Run
but so you have no influence on endianess and of course you have to
We had discussed that in the past, seem there is still no better solution:
> [https://forum.nim-lang.org/t/4745#29623](https://forum.nim-lang.org/t/4745#29623)
It should be obvious that for high performance you should avoid many add()
operations for sequences. add() is a not trivial proc call, even when inlined
it has to check if buffer is full and needs reallocation, and it has to
increase len field. What was not that obvious for me is how much
Funny question of a new forum user, isn't it?
So lets wait for nice new spam links:
> This is a very interesting point.
And to make it more precise: When we access an arbitrary element of a array/seq
base address + index * element_size is calculated to determine its memory
address and access it. If multiple elements are accessed one after the other,
then a compiler is
Maybe one additional note:
When we access elements of an array, that generally occurs with an offset to
stackpointer. Stackpointer is generally fixed while we are inside a proc, and
stackpointer is generally located in a register, so to access an array element
a offset plus stackpointer is
I think that question has been answered many times already, and I am nearly
sure you know it already. At least you are no newbie, I have seen you name in
this forum for at least a few months already :-)
Nim array is basically a C array located on the stack, so just a fixed block of
memory. As
Are you looking for
[https://nim-lang.org/docs/manual.html#foreign-function-interface-exportc-pragma](https://nim-lang.org/docs/manual.html#foreign-function-interface-exportc-pragma)
> to sell only a few thousand copies
Good joke! To sell 100 with current Nim community size may be possible, maybe
200 with a chinese translation. A free book may have indeed 1k readers. My
guess is that manning sold some hundreds of NimInActions indeed, but that was
when Nim was new and had
Outplace is new in devel, but I wrote "shuffle does the trick". I only used
outplace in the example to generate the mutable test array from the range.
And note that NiGui depends on GTK on Linux, so your earlier statement "pure
Nim, no depencies" is only valid for windows. There are some GUI
@cndkhuong
have replied to your issue already at github:
[https://github.com/StefanSalewski/gintro/issues/60](https://github.com/StefanSalewski/gintro/issues/60)
If you wrote something here as a new forum user it may take some time until
text will become visible.
> it takes me 4 lines to choose 4 unique random colors from a sequence of 17;
shuffle() should do the trick, not only in Nim:
import sequtils, random, sugar
var a = toSeq(1 .. 17).outplace(shuffle())[0 .. 3]
echo a
Run
The other points you miss in NiGui
Thanks for testing.
So I think I will consider using your neovim. I have used GVim some years ago,
so I know at least the most basic vim commands. My gentoo box has to install a
lot of additional packages for neovin, that is the reason why I have not tested
neovim for Nim already. Other reason
My own NEd editor works really bad when many generics are used, so I wrote the
rtree module with plain gedit without any special Nim support. Unfortunately my
editor has the same problems when I only import rtree module -- for a file with
only 700 lines of code and gtk3 and rtree import it
Currently I am using for my editor and mostly for the whole desktop display
"Source Serif Pro Semibold" downloaded from the Google Webfont collection. The
space glyph is still small, but large enough. Some years ago I had another
proportional font with really tiny spaces, with it two char
Thanks for clarification, I was indeed a bit surprised by your former post.
Two spaces for indentation is indeed fine. One exception is for some
proportional (none monospace) fonts with tiny spaces. And yes, I am using
proportional fonts for code, they work great. Aligning lines of code like
Also see
[https://www.reddit.com/r/nim/comments/d90z2w/practical_examples_showing_how_macros_lead_to](https://www.reddit.com/r/nim/comments/d90z2w/practical_examples_showing_how_macros_lead_to)/
and maybe ignore the spam links which will be inserted soon in the initial
post.
We know already:
[https://www.reddit.com/r/nim/comments/e1j4ot/i_made_an_idea_incubator_cli_app_nimspire](https://www.reddit.com/r/nim/comments/e1j4ot/i_made_an_idea_incubator_cli_app_nimspire)/
> Same pattern goes for gtk3. The only upto date gtk binding lacks any form of
> API reference, and it's been a couple years.
We had the discussion (again) some days ago at GTK forum:
> Anyway, why are i32 integers the fastest when performing calculations?
Some CPU may have no 64 bit data type at all, like some ARM and embedded chips.
So for int64 addition we would get two operations at least, one plain addition
and one add with carry. Even for a CPU with 64 bit support a
> lists each tag
Unfortunately not all packages have an optimal set of tags. For tagging, once
my nimble publish was rejected due to too many tags, then I may had a nimble
publish fail maybe because I typed the tags too slowly, then I tried gain with
only one fast typed tag and nimble publish
See also
[https://github.com/nim-lang/Nim/wiki/Curated-Packages](https://github.com/nim-lang/Nim/wiki/Curated-Packages)
[https://github.com/VPashkov/awesome-nim](https://github.com/VPashkov/awesome-nim)
> 2\. why
You have to accept that compilers may not see x = {1..9, 15, 45..78} as one
entity, but as an assignment, where the right side is evaluated first and then
assigned to the var on the left. And {1..9, 15, 45..78}is evaluated as a set of
integers, which is not compatible to a set of
With a fresh Nim devel I am getting
Hint: glib [Processing]
/home/stefan/gintrotest/tests/glib.nim(68, 13) Warning: use `csize_t`
instead; csize is deprecated [Deprecated]
/home/stefan/gintrotest/tests/glib.nim(69, 12) Warning: use `csize_t`
instead; csize is deprecated
Basically I agree -- for someone with at least a minimal computer science
background reading Araqs tutorial part I and II is enough to start, and that
takes only a few hours. Learning macros, async, parallel processing is not that
easy. And fully unskilled people seems to have some more
101 - 200 of 880 matches
Mail list logo
