Re: Compilation error after upgrade to 1.0.2 from 0.19
Thanks for the answer; I'll give that a try...
Re: Compilation error after upgrade to 1.0.2 from 0.19
Sorry for my late reply, and thanks for the answer. However I didn't find a solution for the following problem: import nre var tokens = newSeq[string]() tokens = "abc > def".match(re"\s*(\S+)\s*(?:>\s*(\S.*\S))?\s*").get.captures.toSeq() # ERROR echo tokens[0] tokens[0] = "ghi" Run The nre docs state: Note: If you love sequtils.toSeq we have bad news for you. This library doesn't work with it due to documented compiler limitations." Suppose, this is still the problem... Is there a simpler workaround than to enumerate the captures, get the values, and assign to tokens? - as e.g. in caps = "abc > def".match(re"\s*(\S+)\s*(?:>\s*(\S.*\S))?\s*").get.captures for cap in caps: tokens.add(cap.get) Run
Compilation error after upgrade to 1.0.2 from 0.19
The following code used to compile in nim 0.19: result = newSeq[string]() ... var tokens = li.match(re"\s*(\S+)\s*(?:>\s*(\S.*\S))?\s*").get.captures.toSeq() # Add to the list of list values result.add(tokens[ITEM_NAME]) Run Now, I get the following error: G:\src\nim\vim256\opts.nim(281, 19) Error: type mismatch: got but expected one of: proc add[T](x: var seq[T]; y: openArray[T]) first type mismatch at position: 2 required type for y: openArray[T] but expression 'tokens[0]' is of type: Option[system.string] proc add[T](x: var seq[T]; y: T) first type mismatch at position: 2 required type for y: T but expression 'tokens[0]' is of type: Option[system.string] 9 other mismatching symbols have been suppressed; compile with --showAllMismatches:on to see them Run As I have "been away" from nim for a relatively long period, I would appreciate some hint as how to remedy this...
Is winnim still usable with nim 0.17.3?
Using winim 1.2.0 gives the following error: nim c .console.nim C:Usersben.nimblepkgswinim-1.2.0winimwinapi.nim(15620, 42) Error: type mismatch: got (int32) but expected 'uint16' This still used to work some incarnations of nim ago...
Re: unable to build PDF documentation
Two questions: 1) How would I build the docs on Windows (not LaTeX here w/o GNU) [Yes, I know, I could... => but this is more of a principal question... Is there perhaps another way to provide the source docs?] 2) Where would I download the readily compiled docs? [Yes, I know => "The Index", and Ctrl-F is your friend , but I prefer PDFs for that matter...]
Re: -p:
@Araq Tried it, doesn't work (schade...)
Re: -p:
Thanks. Is there a possibility to search for e.g. gcc.exe in another location (just setting gcc.path in confignim.cfg doesn't work, as depending tools like c1.exe will fail)?
-p:
>From the docs I take: "-p:PATH" => Add path to search paths" So in my understanding a call of "nim -p:c:\tools\mingw64\bin ..." would add "c:\tools\mingw64\bin" to the contents of my %PATH% environment variable and thus search e.g. gcc.exe along the new %PATH% (i.e. ;c:\tools\mingw64\bin"). However, this doesn't seem to work. Is my assumption/understanding wrong?
Re: Code page 65001
Thanks a lot!
Code page 65001
@Araq: Since v0.15, whenever I run "nim.exe" (or a program compiled with the new compiler) my console's copde page is changed from 1252 (Windows Latin-1) to 65001 (UTF-8), which is - let's say - a litte counter-productive in my environment. So, please have the compiler (and compiled programs) respect the current console's code page!
Re: Going to Haxe. Nim In Action book available.
@wulfklaue Interesting; what's your movtivation to make the move from Nim to Haxe; would you mind giving details of your decision?
Re:
Hey, come on - I'm a lazy bump ;)
"Processing" hint
Using --hint[Processing]:off doesn't turn this message of in Windows 7 64-bit. How would I accomplish that?
Compiler colors
Is there any way to customize the compiler's colors?