Re: Nim's Easy Serialization Macro - new version available

[xomachine]

**@cdunn2001** msgpack just can not cover all the fields that NESM does. For 
example deserialization of third-party file format or make a model of IP packet.

[Here](https://github.com/FedericoCeratto/NESM/blob/6b08b33ff82a5d5b7eec166c6d7427446ceab75a/demos/ntp.nim)
 is a little demo of NTP packet model created by **@FedericoCeratto**. Can 
msgpack do something like this? I'm not much familiar with it but something 
tells me that it is not the purpose msgpack made for. 

Re: Generic array size in proc return type

[cdome]

I see general perception that this code should compile of course if it depends 
only constant expressions. I will file yet another ticket at github issue 
tracker, using the following code as reproducible example:


proc len(T: typedesc[tuple|object]): static[int] =
  var f: T
  for _ in fields(f):
inc result


proc fieldNames(T: typedesc[tuple|object]): array[len(T), string] =
  var i = 0
  var f:T
  for name,_ in fieldPairs(f):
result[i] = name
inc i

let tt = (a: 10, b: 20, c:30)
echo fieldNames(type(t))

Re: Can't install nim on Win 8.1

[Trustable]

Maybe relevant: 
[https://github.com/nim-lang/Nim/issues/5086](https://github.com/nim-lang/Nim/issues/5086)
 (How did this get fixed?)

Re: Generic array size in proc return type

[coffeepot]

Another thing is that using


let tt = (a: 10, b: 20, c:30)


means you're not dealing with compile time variables. This should be a const 
instead of an let.

Having said that, the compiler should (and normally does) state this. With the 
version I'm running, the compiler doesn't even throw an error, it just says 
Hint: test [processing] then silently quits. If you comment out the fieldNames 
proc compilation is as normal. I'm a bit out of date with devel though.

Re: Generic array size in proc return type

[mratsim]

If you want to use an array as a return type, instead of a seq "len(t)" should 
be a static[int] (so known at compile-time).

You can check andrea's linalg library on various static[int] examples in a 
matrix/vector context: 
[https://github.com/unicredit/linear-algebra](https://github.com/unicredit/linear-algebra)

Re: Generic array size in proc return type

[coffeepot]

proc len(t: tuple|object): int =
  for _ in fields(t):
inc len


Should this be


proc len(t: tuple|object): int =
  for _ in fields(t):
inc result


Fieldnames still doesn't compile for me as written but len returns 3 with this 
change. Before changing, the compiler was trying to increment the len proc, 
reporting:

_Error: type mismatch: got (proc (t: tuple or object): int | proc (w: 
WideCString): int{.noSideEffect, gcsafe, locks: 0.} | proc (x: TOpenArray): 
int{.noSideEffect.} | proc (x: string): int{.noSideEffect.} | proc (x: seq[T]): 
int{.noSideEffect.} | proc (x: array[I, T]): int{.noSideEffect.} | proc (x: 
cstring): int{.noSideEffect.})_

_but expected one of:_

_proc inc[T: Ordinal | uint | uint64](x: var T; y = 1)_

Generic array size in proc return type

[cdome]

I have stumbled upon interesting use case when length of array I return from 
proc depends on the type of the input argument. From language design 
perspective is it something Nim should support or no? Currently compiler 
crashes. I know it can be done with macro, more of conceptual discussion.


proc len(t: tuple|object): int =
  for _ in fields(t):
inc len

proc fieldNames(t: tuple|object): array[len(t), string] =
  var i = 0
  for name,_ in fieldPairs(t):
result[i] = name
inc i


let tt = (a: 10, b: 20, c:30)
echo fieldNames(tt)