Re: Compilation error after upgrade to 1.0.2 from 0.19

2020-01-11 Thread axben
Thanks for the answer; I'll give that a try...


Re: Compilation error after upgrade to 1.0.2 from 0.19

2020-01-09 Thread axben
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

2019-11-17 Thread axben
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?

2017-11-15 Thread AxBen
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

2017-01-24 Thread axben
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:

2016-11-05 Thread axben
@Araq

Tried it, doesn't work (schade...)


Re: -p:

2016-11-05 Thread axben
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:

2016-11-04 Thread axben
>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

2016-10-18 Thread axben
Thanks a lot!


Code page 65001

2016-10-15 Thread axben
@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.

2016-08-11 Thread AxBen
@wulfklaue

Interesting; what's your movtivation to make the move from Nim to Haxe; would 
you mind giving details of your decision?


Re:

2016-07-02 Thread axben
Hey, come on - I'm a lazy bump ;)


"Processing" hint

2016-07-01 Thread axben
Using --hint[Processing]:off doesn't turn this message of in Windows 7 64-bit. 
How would I accomplish that?


Compiler colors

2016-07-01 Thread axben
Is there any way to customize the compiler's colors?