News for hackers. Stuff that matters.
Re:D as a Better C by dom96 on Wednesday August 23, 2017 @04:20PM (#15084705)
Indeed there are some bugs with unicode output[1]. Just to be clear the standard way to output anything to the console is `echo` (similar to Python's `print`).

It seems that the progress on that issue has stalled. It's unfortunate but we do have limited man-power and rely on the community to help us out, this does mean that at this stage it helps if you don't mind getting your hands dirty with potential bugs.

Unless one of us are directly affected by a bug, or we see a large number of users affected by it, it's unlikely that we will focus on it. Not much we can do there sadly. I hope you can understand.

Regarding static linking I would say that it's challenging for most languages. Especially on Windows. If you pop into our IRC/Gitter channel[2] though I'm sure somebody would help you out. You can also probably get pretty far by asking C users for help.

Regarding the build system, perhaps you are referring to the fairly recent addition of NimScript? I think that has stabilised by now. But if you've got any specific questions about it then feel free to ask them.

1 - https://github.com/nim-lang/Nim/issues/2348

2 - https://nim-lang.org/community.html

Re:D as a Better C by e12e on Thursday August 24, 2017 @12:29AM (#15087598)
As I'm now on my laptop with access to the two simple programs; for text output:

  import encodings
  var hello1 = convert("Hellø, wørld!", "850", "UTF-8")

  # Doesn't work - seems to think current codepage is utf8.
  var hello2 = convert("Hellø, wørld!", getCurrentEncoding(), "UTF-8")

  # Outputs correct text:
  echo hello1
  # Outputs corrupted text:
  echo hello2
(And simply outputting an unconverted string fails, like hello2 does).

As for the linking problem I had, the main issue is that it seems to be harder than it probably should, to get started with the GUI-programming with nim on windows. The following code works, provided one manually obtains sdl2.dll (and sdl2.lib for static linking) - however, even with static linking flags (no errors), the resulting exe still depends on the presence of sdl2.dll:

  import nimx.window
  import nimx.text_field
  import nimx.system_logger

  proc startApp() =
    var window = newWindow(newRect(40, 40, 800, 600))
    let label = newLabel(newRect(20, 20, 150, 20))
    label.text = "Hellø, wørld!"
    window.addSubview(label)

  runApplication:
    startApp()
With sdl2.dll (and .lib) in the same folder both of these work:

nim --threads:on --dynlibOverride:SDL2 --passL:SDL2.lib c -r win.nim

nim --threads:on c -r win.nim

but both fail without sdl2.dll present (ie: the "statically" linked exe still depends on dynamically loading sdl2.dll).

And there's so far no easy way of getting a "supported" sdl2.dll to go with the nim compiler - as far as I can tell, neither "nimble install sdl2" or "nimble install nimx" provide a way to get the sdl2.dll and/or C source code to compile it.

But perhaps managing DLLs and such is considered to be out-of-scope for nimble/nim package manager for now.

Re:D as a Better C by FullyFunctional on Saturday August 26, 2017 @07:25PM (#15108030)
Ha, your comment was my first introduction to Nim but it looks interesting so I "brew install nim" and tried your test (thanks!) with "nim c test.nim && ./test" on macOS and my results is the opposite of your: hello1 is garbled while hello2 works.

I bit of googling found the next steps "nimble install minx" but for compiling your win.nim example I had to use "nim --noMain --threads:on c -r win.nim" but the result worked. However AFAIK, there's no official way to make statically linked binaries on the latest macOS.