4 ms·

Neat! I have been trying to, in Nim, but I've had so little experience working with raw terminals and the IOCTL handles, I've been struggling! https://github.c

by girvo 10y ago

Neat! I have been trying to, in Nim, but I've had so little experience working with raw terminals and the IOCTL handles, I've been struggling! https://github.com/girvo/te https://github.com/girvo/te This looks like a great tutorial to work through with it :)

nickpsecurity 10y ago
Quickly looked at your source without the slightest knowledge of Nim language. It was certainly Python-like in ease of reading like some here told me. Nice, clean look to it vs the C stuff. Exception is types.nim file that just looks syntactically rougher than others with the asterisks. It looks like class or struct definitions but I'm curious if the asterisk has an effect like it does in C or what's it do?
- girvo 10y ago
  The asterisks are what define a symbol as "exported" from a module -- every symbol is private to the module scope by default, but able to be exported by applying the asterisks to it; types.nim is funky because I was exploring a slightly different file/module structure (and having a singular place for top-level shared types that most other modules import is quite useful at times, and gets around circular dependencies), except it does end up looking slightly odd!
  - nickpsecurity 10y ago
    I appreciate it. So, it looks weird because it's an experiment with something non-standard? Makes sense. Things stay clean overall.
    - girvo 10y ago
      That's it. For the most part, one would just export the symbols from given modules as needed (and a lot of the properties on some of the ref object types are needlessly exported, too, which makes it worse) One other thing is that the {.compile.} pragma in term.nim is not needed anymore, as Nim's stdlib has added a lot of those in[0], but it does show how easy it is to bridge between the two languages (and I'm not much of a C developer!) [0] https://nim-lang.org/docs/terminal.html https://nim-lang.org/docs/terminal.html
      - nickpsecurity 10y ago
        Ah. That link is the cleaner look I was expecting. Makes sense.
- deleted 10y ago
  [deleted]

by girvo 10y ago

nickpsecurity 10y ago

Quickly looked at your source without the slightest knowledge of Nim language. It was certainly Python-like in ease of reading like some here told me. Nice, clean look to it vs the C stuff. Exception is types.nim file that just looks syntactically rougher than others with the asterisks. It looks like class or struct definitions but I'm curious if the asterisk has an effect like it does in C or what's it do?

girvo 10y ago
The asterisks are what define a symbol as "exported" from a module -- every symbol is private to the module scope by default, but able to be exported by applying the asterisks to it; types.nim is funky because I was exploring a slightly different file/module structure (and having a singular place for top-level shared types that most other modules import is quite useful at times, and gets around circular dependencies), except it does end up looking slightly odd!
- nickpsecurity 10y ago
  I appreciate it. So, it looks weird because it's an experiment with something non-standard? Makes sense. Things stay clean overall.
  - girvo 10y ago
    That's it. For the most part, one would just export the symbols from given modules as needed (and a lot of the properties on some of the ref object types are needlessly exported, too, which makes it worse) One other thing is that the {.compile.} pragma in term.nim is not needed anymore, as Nim's stdlib has added a lot of those in[0], but it does show how easy it is to bridge between the two languages (and I'm not much of a C developer!) [0] https://nim-lang.org/docs/terminal.html https://nim-lang.org/docs/terminal.html
    - nickpsecurity 10y ago
      Ah. That link is the cleaner look I was expecting. Makes sense.
deleted 10y ago
[deleted]