> 1\. The best way is to keep the file structure as simple as possible so that
> the common user can tell which is the EXE file easily. I don't think a .zip
> file is a good way; if the user has (de)compressor application installed, the
> double click will not open the .zip file as a directory
Thanks for the various solutions. The best way is to keep the file structure as
simple as possible so that the common user can tell which is the EXE file
easily. I don't think a .zip file is a good way; if the user has (de)compressor
application installed, the double click will not open the .zip
[https://nim-lang.org/docs/niminst.html](https://nim-lang.org/docs/niminst.html)
?.
hello,
nim-lang 1.2.4 I have an error with the lib vte that I did not have with 0.7.6
pkgs/gintro-0.7.9/gintro/vte.nim(686, 23) Error: undeclared identifier:
'Regex00Array'
thank you
hello, nim-lang 1.2.4 I have an error with the lib vte that I did not have with
0.7.6 pkgs/gintro-0.7.9/gintro/vte.nim(686, 23) Error: undeclared identifier:
'Regex00Array'
thank you
Example (yes, function names are mangled, but you have mapping to original Nim
source code):
Also, did you know about `--debugger:native`? It makes the Nim compiler emit
Nim source code lines for native tools, so you'll get Nim source code lines in
tools like GDB/AMD uProf/Intel VTune/etc
One particular problem arises when you have generic procs or templates. As
different instantiations uses the same name, the difference in the hash does
not help at all.
It would be useful if the generated C identifiers include the instantiated type
name.
X5BX5D means 'x5Bx5D' which is []
Yeah, it's usually the library code that confuses me. For example, in some
server code I'm trying to optimize, by far the heaviest leaf function is called
`X5BX5D___5BvGDMkIeGfxVmn2qvm1Yg`. There are multiple calls to it in the stacks
shown by `sample` (the macOS sampling profiler) and it accoun
Yes, but what if it's not your code? You're not gonna do exportc for every
single proc are you?
OP said is for Debugging. 🤷♂️
So you say when you debug the stack trace is always 100% your code? :) I doubt
that
`{.exportc: "my_very_readable_name_sir".}`.
There's
[https://github.com/nim-lang/Nim/pull/14632](https://github.com/nim-lang/Nim/pull/14632)
(AFAIK it's in frozen state for now) which aims to make more readable function
names in the resulting C code.
Is there any option to have Nim's C backend generate more readable/descriptive
mangled function names? Sometimes I have to look at those names, when using
native profiling/debugging tools, and they can be very ambiguous. For example,
`write__UlykqHUJzrYfskoCKJB7AQ` is obviously a function named
This is an example of resulting C code provided by disruptek:
[http://ix.io/2s9S](http://ix.io/2s9S) (warning: big!)
UPDATE: The bug has been [fixed in
devel](https://github.com/nim-lang/Nim/pull/15012) thanks to @dom96. Turned out
to be a mistake with not handling EAGAIN properly. I am much relieved.
Ship the application as a .zip file, put the DLLs next to the .exe file. It
works, it's simpler than the proposed solutions and it scales better when your
application needs more external files.
`var module = static(staticRead("libadd.dll"))`
Check out [nimdeps](https://github.com/genotrance/nimdeps) which makes this
easier - of course, it doesn't load DLL from memory but simply writes it to a
file on first start. This also means you have to manually load it with the
dynlib module but seems like that's something you plan on doing any
If you really want to staticRead then you must save the string in a const.
Why not just recompile and link the library statically? This would be the best
way.
If you can't or have no source code access I would recommend an installer
creator like NSIS
I think because spawn is non-blocking the if statement is evaluated before test
is ever run, leaving success in its default state, which happens to be false.
You could test this by changing success into an int and setting any number
other than 0 instead of true in test.
What should also work is
24 matches
Mail list logo
