As I stated, Nim was not installed via these distros, and was being installed
per the process given on Nim's website.
Putting in the suggested PATH did solve the problem though, so thanks.
$ export PATH=~/nim-0.17.0/bin:$PATH
However, this just highlights the inadequacies of
I see. I had done a test which mislead me. Yes, as far as I can tell,
everything works now. Thanks.
... Ugh. I just pulled Nim@devel (a43eae8e6c77149be77082388bb0fa546b9c97a7) and
rebuilt according to readme.md:
c_code/2_2/stdlib_osproc.o: In function
What is the goal of these silly bot messages?
[https://forum.nim-lang.org/t/2682#16605](https://forum.nim-lang.org/t/2682#16605)
> Please create a proper pull request. We can introduce -d:oldLinux for example
> for this feature.
Is that still the plan? If so, why did you close my PR?
`posix.nim` contains `{.deadCodeElim: on.}` and so this should just work. If
not, that's a separate issue. but I would guess that we simply need to update
the C sources.
What's the plan for `execvpe()`, the GNU extenion? While it's in `posix.nim`, I
cannot build Nim.
What is the use case? I can't think of one, unless it is just for experimenting.
Recently, a thread starting with a simple question went OT and became a
different exchange starting [here](https://forum.nim-lang.org/t/3128/2#19739).
The short version:
"Methods (inheritance based dispatch) and concepts (user defined type classes
with VTable based dispatch) are two solutions
Get off my lawn, dude. Passing a tuple to a factory proc is definitely a neat,
and clean, thing to do.
You can construct a tuple and pass it in, and use that to construct an object.
Much neater than a huge parameter list, I think.
Sometimes.
It depends. As always.
Are you sure you want to
@jacmoe, no it's not. It is [code
smell](https://en.wikipedia.org/wiki/Code_smell)
CMIIW, Nim folder is self contained.
@jzakiya, very likely you already have Nim installed from package manager, and
its installation done like usual any package.
If you put the path in front of `$PATH`, it'll solve your problem.
$ export PATH=~/nim-0.17.0/bin:$PATH
In your
For what it's worth, I have built Nim several times without incident on my
Debian box - following the instructions to the letter - so I guess the problem
you have is specific to your machine.
Fix should be ready by tonight, it's not a coincidence `os.nim` has been
refactored to make it easier to see what's going on.
$ export PATH=$PATH:~/nim-0.17.0/bin
The problem might be the expansion of `~` in the default shell on some O/S. Try
$ export PATH=$PATH:$HOME/nim-0.17.0/bin
You could create an "Issue" in Nim's GitHub repo so this specific problem can
be discussed there, separate
Creating an object from a tuple using a macro is actually very neat!
Calling getType() multiple times may give you the parents, I did that here:
[https://github.com/StefanSalewski/gintro/blob/master/gintro/gimpl.nim#L12](https://github.com/StefanSalewski/gintro/blob/master/gintro/gimpl.nim#L12)
I got it from a hint of Araq, I have no idea what really is
My intuition tells me that you did something wrong in your types, if you want
to convert an object to a tuple or vice versa. Try to redesign your code so
that you either only use tuples or only use objects, but don't try to make
mixing them up easy.
If you still want to make it easy to mix up
memo to myself, read:
[https://github.com/loloiccl/Nim/commit/5fc1b3a95ad73951e8383dcbc09fab3056827ec1](https://github.com/loloiccl/Nim/commit/5fc1b3a95ad73951e8383dcbc09fab3056827ec1)
hi,
i'm trying to fix issue #5856 (that json.to() is not marshaling the base
object). When i look into the macro it calls getType. Everything then looks
fine (to me). It seems that the child type does not know about its base type.
Is there a way to also get the base object atributes?
OR
can
Try pragams like `{.checks: on.}`/`{.checks: off.}` and the like (there are
ones for specific checks), better via `{.push checks: off.}` and then
`{.pop.}`, so for the rest of the code checks are still contolled by configs
and command line. For the 2nd, try `GC_disable`/`GC_enable` (inside the
I've been considering creating a Snap package and/or AppImage for Nim for a
while. Maybe I'll have a proper look at it after my holiday.
My macro:
import macros
macro createObj(typ: typedesc, data: untyped): untyped =
# This macro only accepts tuples in parenthesis, but this can be changed
assert data.kind == nnkPar
# Object construction syntax
result = newTree(nnkObjConstr)
#
Why they should be truncated, if they are of the same size?
And your macro assigns fields by names... That is, it in the end doesn't allow
you to write like `createRef(O, (5, 6.6, 7i8, 8i8))`, just providing a type and
values.
I am trying to create a callback procedure to be passed to a C library (SDL2
mixer). My problem is that unless I use "-d:release" the callback procedure
causes the program to crash.
Is it possible to compile the program in debug mode, but disable debug for that
specific procedure?
Is it also
@LeGuim I guess bits would be truncated if you do the unsafe cast.
I created the following macros. It's a bit too verbose though - considering the
python/c++.
macro settattr(attr:static[string]): typed =
newNimNode(nnkAsgn).add(
An unsafe but fast and clean way - just to cast your tuple to your object type:
proc createRef(typeinfo: typedesc, data: tuple): auto =
result = new(typeinfo)
result[]=cast[typeinfo](data)
Be aware you should provide a tuple of values of needed types, or the
You can definitely do this with a macro
I started learning Nim recently. Is there a way to convert a tuple into a
object? What I want is to do the following.
proc createRef(typeinfo:typedesc, data:tuple):auto =
result = new(typeinfo)
#fill the result object with the values in the tuple ???
Maybe you can't access Nim directory from user account because it has wrong
permissions? And also maybe you have another Nim installed?
29 matches
Mail list logo
