See this forum post:
[https://forum.nim-lang.org/t/1209](https://forum.nim-lang.org/t/1209)
> I am writing an application that will have objects that I write in my modules
> that will not have any objects created at compile time. I do not want any of
> these eliminated. They will be created at runtime when a configuration file
> is read into the app.
Well either there is a path to
IMO, I will not encounter any problems. AFAIK, no extra protection needed.
Hello,
I have searched the Nim site and this forum trying to read up on deadCodeElim.
I am not finding sufficient information for me to understand. Pointers to docs
are always welcome. Looking through the manual and compiler or internal guides,
I did not find much or overlooked something. I
@Araq, @mratsim: As promised, I'm posting some code that shows the current
difficulty of bypassing the overly simplistic (and performance costly) default
behaviour for the current channels and threadpool libraries of deepCopy'ing all
GC'ed ref's so they won't be prematurely destroyed if they go
Yet another approach is to have the `nim c`-generated C code just `#include
"foo.c"` via `{.importc: "func", header: "foo.c".}`.
system.`=`(a, b)
Run
should work
NimNode are ref types with an overloaded = proc.
I do not agree that lazy linear lists are the "main example" of recursion. They
may be the _simplest_ example, thusly allow several easy workarounds. I
mentioned "trees" right in my comment. Most of the (admittedly subjective)
elegance of tree algorithms comes from the way recursive code
I want to read binary file inNim-language. Because I want to work with WAV
files.
But I don't know how easy it is to read the first four bytes. This may be
because I am not good at English.
I wrote the following code. However, nil is displayed.
var hFile = open("example.wav",
Your buffer points to nothing, allocate an `array[4, byte]` and pass its
address to readBuffer.
I suggest you use streams if you need to save your position/restart your
processing.
For example this is [how I read the first 6
Here is my code that reads wave files:
[https://github.com/treeform/euphony/blob/master/src/euphony/wav.nim](https://github.com/treeform/euphony/blob/master/src/euphony/wav.nim)
There i use newFileStream which makes reading binary files really easy. Just
use readStr, readUint16, readUint32...
It does. I'm surprised I didn't try that before. Thanks.
I assumed based on how NimNodes were implemented that the == operator was
completely overwritten.
You dont need extra protections.
Look at this video, mainly the part about how the AST works:
[https://www.youtube.com/watch?v=QXjU9qTsYCc](https://www.youtube.com/watch?v=QXjU9qTsYCc)
There are always workarounds since CPUs are little state machines. That should
be news to no one. Recursion working makes code look much nicer, IMO. For what
it's worth, the example considered among the more compelling by the Python guys
back in the Python 2.3 days when they added generators
I'm surprised everyone is treating owned and unowned refs as if they were
something new. C++ has owned and unowned refs. In C++, they're called
"std::unique_ptr" and "dumb pointers." The semantics of the C++ version are
almost exactly the same as the semantics of the nim version - the one
15 matches
Mail list logo
