Why takes this code 22ns with cstring and 52ns with string?
mport hashes, times, math, random type tring = cstring Entry[K, V] = object key: K val: V delta: uint8 k0: int8 Map[K, V] = object data: seq[Entry[K, V]] numentries: int hi: int fillrate: int cfr: int proc genArray(i, j: int) : seq[tring] = result = newSeqOfCap[tring](j - i + 1) for k in i .. j: var h = $k GC_ref(h) result.add(h.tring) proc newMap[K, V](capacity: Natural; fillrate: range[10 .. 95] = 50): Map[K, V] = var h = capacity result.hi = nextPowerOfTwo(h) result.data = newSeq[Entry[K, V]](result.hi) proc contains[K, V](m: Map[K, V]; key: K): bool = #var i = key.hash var i = random(1e7.int) if i != 0: return true echo "newer reached! -- otherwise it would crash!" if m.data[i].key == key: return true var m = newMap[tring, tring](512*2, 95) var a = genArray(1, 900) echo "contains" var x = cpuTime() for i in a: discard m.contains(i) echo((cpuTime() - x) / 900) $ ./h contains 2.216e-08 When I change line 4 to "tring = string" I get about 52 ns instead. Of course a Nim string is more complex than a plain cstring. But I think I have already removed all what is really related to the actual Nim string. What remains is basically a call of proc contains() and immediate return. I have even replaced hash() call by plain random() call. Of course the total memory occupied by a Nim string is larger, so less of it fits into cache. But where does it makes the difference.
Re: unable to build PDF documentation
Nvm. Just install the _texlive-fontsextra_ package and all your problems will go away.
Re: unable to build PDF documentation
I encountered this issue while attempting to build the Arch Linux AUR nim-git package. I think the issue had to do with not being in the right directory.
Re: unable to build PDF documentation
I'm pretty sure the issue is that _nimweb_ is installed in nim/tools/ but web/website.ini is in /nim/web/website.ini and _nimweb_ is searching for _website.ini_ in /nim/tools/web/website.ini. There is probably a better way to explain that, you'll probably have to read it twice.
Re: unable to build PDF documentation
Run `pdflatex doc/manual.tex` manually and see what it says.
unable to build PDF documentation
post git clone, i am trying to build the PDF documentation. [strikr@victory nim]$ ./koch pdf Adding to $PATH: /home/strikr/source-nim/nim/bin bin/nim cc -r tools/nimweb.nim --pdf web/website.ini --putenv:nimversion=0.16.0 Hint: used config file '/home/strikr/source-nim/nim/config/nim.cfg' [Conf] Hint: system [Processing] Hint: nimweb [Processing] Hint: os [Processing] Hint: strutils [Processing] Hint: parseutils [Processing] Hint: math [Processing] Hint: algorithm [Processing] Hint: times [Processing] Hint: posix [Processing] Hint: ospaths [Processing] Hint: parseopt [Processing] Hint: parsecfg [Processing] Hint: hashes [Processing] Hint: etcpriv [Processing] Hint: lexbase [Processing] Hint: streams [Processing] Hint: tables [Processing] Hint: strtabs [Processing] Hint: re [Processing] Hint: pcre [Processing] Hint: rtarrays [Processing] Hint: htmlgen [Processing] Hint: macros [Processing] Hint: md5 [Processing] Hint: osproc [Processing] Hint: cpuinfo [Processing] Hint: linux [Processing] Hint: parsecsv [Processing] Hint: xmltree [Processing] nimweb.nim(357, 10) Hint: 'dir' is declared but not used [XDeclaredButNotUsed] nimweb.nim(294, 6) Hint: 'nimweb.pathPart(d: string)' is declared but not used [XDeclaredButNotUsed] nimweb.nim(377, 6) Hint: 'nimweb.genNewsLink(title: string)' is declared but not used [XDeclaredButNotUsed] Hint: [Link] Hint: operation successful (31347 lines compiled; 3.055 sec total; 56.645MiB; Debug Build) [SuccessX] Hint: /home/strikr/source-nim/nim/tools/nimweb --pdf web/website.ini --putenv:nimversion=0.16.0 [Exec] pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016/Arch Linux) kpathsea version 6.2.2 Copyright 2016 Han The Thanh (pdfTeX) et al. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Han The Thanh (pdfTeX) et al. Compiled with libpng 1.6.26; using libpng 1.6.28 Compiled with zlib 1.2.8; using zlib 1.2.11 Compiled with poppler version 0.50.0 bin/nim rst2tex --hint[Conf]:off --hint[Path]:off --hint[Processing]:off --putenv:nimversion=0.16.0 doc/manual.rst pdflatex doc/manual.tex external program failed Error: execution of an external program failed: '/home/strikr/source-nim/nim/tools/nimweb --pdf web/website.ini --putenv:nimversion=0.16.0' FAILURE Any pointers ?
Amicable numbers in Nim and a few questions
I've translated the Euler problem #21 solution (C and Rust versions lifted off the net) to Nim and benchmarked the binary. Time to solution for C/Nim/Rust on my Cortex A5 cpu: 1.5s/1.5s/2.5s Two questions about compiling the generated C immediately spring to mind. Does the nim compiler use $CFLAGS in release mode, if present, and is there a switch for performing a PGO build automatically? C: [http://pastebin.com/X3ZTp1c0](http://pastebin.com/X3ZTp1c0) Rust: [http://pastebin.com/u2TixCiV](http://pastebin.com/u2TixCiV) Nim: [http://pastebin.com/drhfFJGW](http://pastebin.com/drhfFJGW)
Re: Nim Podcast
@Krux02 feel free to email me if Gitter is not OK: moigagoo [at] live.com.
Re: No way to run my code, idk how to force a float as an Int
There's gitter [https://gitter.im/nim-lang/Nim](https://gitter.im/nim-lang/Nim)
Re: Audio/Video File Read/Write Support In NIM
ok, since I wrote this, I think the example with the codec developer is just a bad example. Just because there is a codec in the standard library, doesn't main you can't develop a better one in that language. But I don't change my opinion. I think the Nim language is powerfull enough, that it doesn't need any new language feature, but allows to implement all your dreams that you want to have. And sorry to tell you this, the Nim community is an idealistic underpaid small group of talented people. When you implement this idea in Nim, we will all support you in getting your things done. But we will not do it for you (unless you pay for the work you want to profit from).
Re: No way to run my code, idk how to force a float as an Int
You know if there is a slack or a discord channel or an for nim ?
type mismatch assigning function pointer? gcsafeness confusion?
Hi!
What am I doing wrong here:
type
FooProc = proc(x: int)
Callbacks = tuple [
cb: FooProc
]
proc foo(x: int) : void = echo "foo: " & $x
let f:FooProc = foo
let c0: Callbacks = (cb: f)# works fine
let c1: Callbacks = (cb: foo) # type mismatch!
c0.cb(42)
c1.cb(42)
The assignment to c1 complains, saying:
: type mismatch: got (tuple[cb: proc (x: int){.gcsafe, locks: 0.}]) but
expected 'Callbacks = tuple[cb: FooProc]'
But surely f and foo are the same? Shouldn't that assignment either always
fail, or always be OK? What am I missing?
Thanks!
Re: No way to run my code, idk how to force a float as an Int
ok nice for the help it's working now I have an other problem with type mismatch with sequence haha
No way to run my code, idk how to force a float as an Int
hi guys I have this few line, nombreDePyramides = 4 var maxLignes: int = ((nombreDePyramides+2)*(nombreDePyramides+3)/2-4) here the second line is giving me a float but I need a int because of the rest of the code and I can't find the syntax ... -Pro-de-Pablo:sastentua pablocolson$ nim c satstentua.nim Hint: used config file '/Users/pablocolson/nim/config/nim.cfg' [Conf] Hint: system [Processing] Hint: satstentua [Processing] satstentua.nim(2, 68) Error: type mismatch: got (float) but expected 'int' MacBook-Pro-de-Pablo:sastentua pablocolson$ thanks for awnsers
Re: No way to run my code, idk how to force a float as an Int
This happens because `/` on ints returns a float. You want to use `div` instead, which is integer division. var maxLignes = ((nombreDePyramides + 2) * (nombreDePyramides + 3)) div 2 - 4 Or, alternatively, convert it – this is clearly the inferior solution, but given here for completeness: var maxLignes = int((nombreDePyramides+2)*(nombreDePyramides+3)/2-4) In both cases, you do not need to give the type because it is derived from the expression.
Re: 2 question about DLL with Mingw
NimMain don't need to be called, because all GC initialization procedures can reside in DllMain() function, so there no reason to export NimMain.
Re: Audio/Video File Read/Write Support In NIM
As @krux02 mentioned, core language should be compact and flexible without diminishing its usability. Nim syntax already flexible enough so you shouldn't have any problem implementing the dsl for multimedia applications. While developing language to fill the niche is nice, it would be more nice if you can do anything with it. Also, since the video/audio processing is your expertise, it would be nice if you write some library for it.
Re: Exploring namespaces support in Nim
@Jehan, yglukhov: I wonder then how clashes would be handled then with a template-based approach: import Foo, Bar: ... baz(x) with baz defined in both Foo and Bar...
Re: Exploring namespaces support in Nim
@Krux02: I may be the only one to think this, but "openFile" seems just as good (from a syntax perspective) as "File.open" while the second form is far more flexible, offers more guarantees and is more easily discoverable and fixable should a problem occur... As far as I am concerned, I don't want to spend my time checking that the names I chose conflict with nothing in the totality of packages in nimble and elsewhere. I want to be able to rename NativeExcelReaderPackage.open/close/write/append/metadata/etc. to xlsread.open/close/write/append/metadata/etc. if I feel like it instead of being stuck with it. I don't want to spend my time writing "Foo_init(); Foo_do_bar(); Foo_do_baz()" because, after all, these are the Foo variant of init, do_bar and do_baz... Regarding the OOP approach, well this is definitely cleaner (and what I would use anyway) but may not be considered idiomatic because of the instantiation/mutation pattern... Partly initialized objects are a source of bugs, even more when there is no notion of blessed (i.e. guaranteed) constructor in the language.
Re: Exploring namespaces support in Nim
D supports local imports and has to deal with overloading. Nim supports the following: from foo import nil block: # Start of scope template someSymbolFromFoo(a: int): int = foo.someSymbolFromFoo(a) type SomeTypeFromFoo = foo.SomeTypeFromFoo # Use SomeTypeFromFoo and someSymbolFromFoo # Pop scope. SomeTypeFromFoo and someSymbolFromFoo are not defined again. So we can local "import" symbols from another module "artificially", we just need to automate it a bit =)
Re: Audio/Video File Read/Write Support In NIM
People in Audiovisual Computing need 2 things from a programming language: 1. As fast as possible code execution speed 2. Easy to use, built-in image/audio/video file read/write commands There is NO programming language right now that does both. The programming language is either SLOW but supports audio/video nicely, or it is FAST, but getting audio/video in and out of the language is a horror to set up. We are in 2017. The world we live in is highly audiovisual content oriented. If you want Nim to become popular in audiovisual computing - Computer Vision for self-driving cars or Video Processing for Film & Television for example - I strongly suggest that the language comes with basic image/audio/video read/write capabilities by default. When people ask on the internet "what programming language is good for video processing?" people would then answer "Nim is really good for that". Please consider basic audio/video support seriously. Nim would become the first language that is both FAST, and that can do basic audio/video processing from the moment you install it. You would reach thousands of users quickly just due to this built-in audiovisual functionality. Thanks!
Re: Nim VFS (virtual file system)
You may want to look at PhysicsFS: [https://icculus.org/physfs](https://icculus.org/physfs)/ It's a C library. And it looks like someone generated a nim wrapper for it: [https://github.com/fowlmouth/physfs/blob/master/physfs.nim](https://github.com/fowlmouth/physfs/blob/master/physfs.nim)
Re: Exploring namespaces support in Nim
Local imports is something I would also vote for. I bet they should be easy to implement. @Araq, what do you think?
Re: Exploring namespaces support in Nim
**yglukhov:** _I bet they should be easy to implement._ Well, first there's also the problem of semantics. OCaml, SML, and Python as three languages that support them don't have to worry about overloading. Definitions shadow each other, so that the innermost import always wins. With overloading, that may not be the case and/or may require explicit prioritization to ensure that you get something sane. I'm also not certain if it's all that easy. I haven't looked at that part of the compiler in a while, but I seem to remember that some of the data structures implicitly assume that imports are global.
Re: Exploring namespaces support in Nim
> Well, then it is useless. I am from a domain (science) where similar concepts
> are generally called a similar way and where clashes occur a lot because
> something as simple as * has a gazillion meanings depending on the context
> (and all of them applied to arrays of any dimensions, so no useful dispatch
> there).
Maybe this is exactly where the context is. Nim allows you to use types and
overloading unlike languages such as python. Generally speaking when type of
the argument does not encode the context, you should use a more explicit name.
I can give a bad example:
proc open(arg: string): auto = ...
It does not tell you what it actually opens. Since the module is not generally
prepended to function calls, I would recommend to encode what is actually meant
to be opened in the Name:
proc openFile(filename: string): auto = ...
Now it is more clear that the function is supposed to open a File, but still it
doesn't tell what it actually opens.
proc openTexture(filename: string): Texture ...
proc openDocument(filename: string): Document ...
proc openSoundSample(filename: string): SoundSample ...
But when using object oriented programming, overloading can be used again:
proc open(self: var Document; filename: string): void = ...
proc open(self: var Texture; filename: string): void = ...
proc open(self: var SoundSample; filename: string): void = ...
var myDoc: Document
myDoc.open("myfile")
Now it is clear what the naked open does, depending on the Type of the first
argument. Maybe you should pack your naked arrays into objects, so that you can
use overloading to define the meaning of the operation you want to do. Maybe
you are just too used to put everything in just an Array, because you got used
to do that from Fortran so much, but maybe that is simply not the best practice
in other programming languages.
Re: Exploring namespaces support in Nim
@Jehan: I see, I did not understand correctly but it is clear now. Its akin to scoped imports then and it seems far better for scientific computing (especially for operators).
Re: Exploring namespaces support in Nim
**lltp:** _@Jehan, could you elaborate a little bit on how ML-type module management would help for scientific computing because I am still not sure that I have grasped everything._ The problem that local imports solve is to provide a midpoint between the extremes of putting identifiers in the global namespace and qualifying every single use of an imported identifier. This can matter in scientific computing because you frequently have overloaded operators and functions, while automatic overloading rules can be insufficient when it comes to resolving which one to use. At the same time, you don't want to qualify every single operator in a complex expression with a module name.
Re: 2 question about DLL with Mingw
1. proc double(x: cint): cint {.cdecl, dynlib: "foo.dll", importc:"_double".}
2. use compiler switch --nomain
Re: Exploring namespaces support in Nim
> modules in Nim provide no intrinsic guarantees about that splitting There are not many languages that provide such guarantees. C guarantees nothing. C++ guarantees a member to be defined in the class definition or its superclasses, which in turn are not guaranteed to reside in any specifically named file. C# has class extensions, so no guarantees again. Ruby has implicitly object static functions, so no luck. Even if you take Java which provides a whole ton of guarantees, still a symbol could either belong to a class or any of its superclasses. Still all of these languages proved to have extremely large codebases. Usually they manage to do so by following common sense and good engineering practices. I personally love such approach. With powers comes responsibility. >From my own statistics, the project I work on (splitted to libs) counts more >than 90KLOC of pure Nim code, not counting numerous dependencies in nimble >packages, and still there was no pain at all with name conflicts, lack of >namespaces, or symbol-origin-determination. However, there was some pain with >cyclic imports a few times, but that doesn't mean Nim is not the best language >out there
2 question about DLL with Mingw
I have met this page: [http://stackoverflow.com/questions/37950722/load-function-in-nim-dll](http://stackoverflow.com/questions/37950722/load-function-in-nim-dll) I have 2 question for my MingW on windows: 1. what can we do with Mingw? "#pragma comment(linker, "/export:double=_double")" produces only _double( that is to say there is no double) in the DLL 2. Can we delete the NimMain in foo.dll?
Re: Exploring namespaces support in Nim
Hi! (please bear with the length, I promise this is my last long post) * * * @Araq, I quite agree with @Jehan's view that eventually, a reasonable developer would try to provide structural guarantees in his code and in that sense, your suggestion (which make sense in general) would seem weird and become synonymous to "oh, if that guy imports types, his code is messy". * * * @Jehan, could you elaborate a little bit on how ML-type module management would help for scientific computing because I am still not sure that I have grasped everything. * * * Now that I have read more about this, it seems that talking about encapsulation itself is not the correct term. I should have talked about implicit **guarantees**... _What are the problems when someone tries to contribute to a large code base (like Firefox, GLib, QuantumESPRESSO or OpenFOAM)?_ * First we need to clearly determine what the problem is and split it into smaller, manageable parts. * Then we need to determine what changes to make. * Then where to make the change. In that list, the first point is completely up to the developer whereas the two last ones are much more language- and structure-dependent. In small programs like most of what we have in Nim today, it is easy to build a reliable mental map of the totality of the program in a short time, this is why Nim works so well! But take any of the programs I cited above, creating such a map is impossible: our brain just can't handle it! The general solution to that is to follow Descartes' principles and split the problem (here the program) into smaller pieces. In Nim, this is currently provided by files and therefore modules. The gist of the problem that I couldn't explain clearly earlier is that modules in Nim provide no intrinsic guarantees about that splitting: in class-based OOP, I don't expect to find Bar-related methods and attributes in the class Foo; likewise, I don't expect any of the "important" Foo-related methods or attributes to be defined outside of the class. This is why I was able to identify and dump that Density class I talked about somewhere else and hack on that without ever worrying about the remaining 95% of the program! But with Nim, I don't have that: sure, if I were to use @Jehan's programs, I would be fine but most of the other scientists don't really code like that... Now, as I said, I don't care about the particular implementation as long as it provides this kind of guarantee. I don't have an extended knowledge of programming languages, so please, really please, if you have any suggestions to provide such guarantees in any form that fits well with Nim, then do.
Re: Question about NimEdit
I have a branch of NimEdit that uses nimx for the font rendering but never got it to work. OpenGL context setup issues. But if there is so much interest in my pet project, I will clean up the code and release it soon, hopefully.
Re: links on http://nim-lang.org/docs/documentation.html are wrong
[http://nim-lang.org/docs/documentation.html](http://nim-lang.org/docs/documentation.html) is obviously some broken stuff but the website doesn't link to it, as far as I know.
Re: Question about NimEdit
@Krux02, thats a bit sad to hear. Text-related stuff in nimx is designed to be fast, so if you're experiencing slowdowns, you might want to report that as a bug
Re: Audio/Video File Read/Write Support In NIM
If anyone's interested, I've started integrating webm support into the [rod](https://github.com/yglukhov/rod) engine. The core libs are [webm](https://github.com/yglukhov/webm) which is mkv/libvpx wrapper and [rod_video](https://github.com/yglukhov/rod_video) which is a component for rod. All of the libs are still pretty immature, so PRs are welcome =)
links on http://nim-lang.org/docs/documentation.html are wrong
for example, Language Manual is said to be [http://nim-lang.org**/docs/docs/**manual.html
Re: Winim - Nim's Windows API and COM Library
Translation: "awesome! Are you Taiwan?" Next time please speak English.
Re: Winim - Nim's Windows API and COM Library
厉害厉害！ 你是台湾的？
Re: C#/Java like interfaces for Nim
Maybe you want to take a look at my Go like interfaces. [http://forum.nim-lang.org/t/2422#14994](http://forum.nim-lang.org/t/2422#14994) The difference between Go like interfaces and Java like interfaces, is that object that implement that interface does not need to be a ref object or inherit from root in any way. That object can be a plain old data object. The vtable pointer is not stored in the object at all, but a pointer that is stored in an interface is actually a tuple with the pointer to that object, and the pointer to the vtable that implements the interface for that object.
Re: Question about NimEdit
@hcorion Nimx is not ready for real applications. It is a proof af concept and a nice project to work on. But currently I get slowdows, just when I want to highlight some text. In my opinion that rules out nimx to be used for anything at this point in time.
Re: My stupid usage of cstrings
or proc genArray(i, j: int) : seq[cstring] = result = newSeqOfCap[cstring](j - i + 1) for k in i .. j: let s = $k GC_ref(s) result.add(s.cstring)
Re: My stupid usage of cstrings
Yes, if the strings used are stored somewhere as `string` at the time they are checked, the output is normal, e.g.: var s: seq[string] proc genArray(i, j: int) : seq[cstring] = result = newSeqOfCap[cstring](j - i + 1) s = newSeqOfCap[string](j - i + 1) for k in i .. j: s.add $k result.add((s[k-i]).cstring)
Re: My stupid usage of cstrings
Thank you!
My stupid usage of cstrings
proc genArray(i, j: int) : seq[cstring] = result = newSeqOfCap[cstring](j - i + 1) for k in i .. j: result.add(($k).cstring) var a = genArray(1, 900) for i in a: echo i The output contains mostly valid numbers, but some garbage. Of course cstrings exists only for C FFI, so using it this way is really stupid. I tried it just for a test of a robin hood hash, to investigate how key size degrades performance. (I was a bit surprised at first that hash is much slower for Nim strings as key than for plain ints -- but it is clear, int size is 4 or 8 byte, Nim string size should be at least twice, c pointer and size.) For the code above -- may GC just free the string immediately?
