nim-lang/Nim

Nim is a compiled, garbage-collected systems programming language which has an excellent productivity/performance ratio. Nim's design focuses on efficiency, expressiveness, elegance (in the order of priority).

From IRC (bridge bot)

@FromIRC

<Araq> krux02, that code is wrong and nimpretty will rewrite it.

Kaushal Modi

@kaushalmodi

below the yellow line is with varargs[typed] -> varargs[untyped] and removed callsite() lines

the code runs, no errors, but is functionally incorrect

If there is no opposition from anyone I can attempt rewriting styledWriteLine, styledEcho and the new styledWrite using templates.

Can the IRC folks see the image I pasted above?

From IRC (bridge bot)

@FromIRC

<miran> @kaushajmodi: we can click on the link and see it in browser

Kaushal Modi

@kaushalmodi

OK cool, just checking. Thanks!

Rokas Kupstys

@rokups

type ustring* = distinct string
proc `[]`*(s: ustring, i: int): ustring = "foo"
echo "abcdefgh"[1..^2]

results in Error: type mismatch: got <string> but expected 'ustring = distinct string'. any idea why defined [] operator would interfere with proc [](s: string, i: int)?

Vindaar

@Vindaar

@kaushalmodi see here: https://github.com/nim-lang/Nim/pull/8047#issuecomment-397676285

Tested it on a couple of cases and it seems to work for me

Danil Yarantsev

@Yardanico

@rokups it doesn't do that on devel, but you have an error in your proc - "foo" is of type string

maybe the compiler is not smart enough to detect that you want "foo" to be of type "ustring"

proc `[]`*(s: ustring, i: int): ustring = ustring"foo"

or ustring("foo")

Rokas Kupstys

@rokups

odd. it happens on devel. and it used to work in the past

ephja

@ephja

I think he wanted to call [] defined in system

@rokups the error is on line 2 though and doesn't involve line 3

Rokas Kupstys

@rokups

its on line 3

wait damn, i messed up test

sec

From IRC (bridge bot)

@FromIRC

<Yardanico> you have an error in your proc body

<Yardanico> it doesn't affect line 3 at all

Rokas Kupstys

@rokups

well sucks. i cant make a minimal testcase that would be convenient for anyone to look at :|

Kaushal Modi

@kaushalmodi

@Vindaar Thanks! While the PR doesn't need that macro anymore, your comment is helpful. Why do you have result[^1].add(arg) instead of result.add(arg). I was just following the example of styledEcho.

Vindaar

@Vindaar

@kaushalmodi the reason is that if you simply use result.add(arg), you will add arg as a new node to the statement list, i.e. resulting in the following code (excluding the newline part):

  StmtList
    Call
      Sym "styledWrite"
      Sym "stdout"
    Curly
      Sym "styleBright"
      Sym "styleUnderscore"
    StrLit "test"

However, what you want is that the Curly and StrLit nodes are also parts of the Call tree, since they are the arguments to that function, i.e.:

StmtList
  Call
    Sym "styledWrite"
    Sym "stdout"
    Curly
      Sym "styleBright"
      Sym "styleUnderscore"
    StrLit "test"

From IRC (bridge bot)

@FromIRC

<Yardanico> @kaushalmodi you can see what code you've generated in your macro

Kaushal Modi

@kaushalmodi

I really need to starting learning about macros. I don't yet know how to read that tree and what Call, Curly, etc. mean. I am saving this reference to my notes for future. Thanks!

Danil Yarantsev

@Yardanico

well, just read macros documentation :)

and this tree is just an AST tree

ephja

@ephja

if semantic analysis for included files work then maybe it's just the vscode extension that's broken

Kaushal Modi

@kaushalmodi

@Yardanico Yes, it's just that I haven't yet got to that. Learning macros is on my list :)

Arne Döring

@krux02

@kaushalmodi just look at node.repr and node.treeRepr, and then you will learn and understand a lot

dumpTree can really help you to understand how nim parses a tree

From IRC (bridge bot)

@FromIRC

<Araq> krux02. can you confirm n.ident should be written as n.strVal ?

From IRC (bridge bot)

@FromIRC

<krux02> Araq: yes

<krux02> I can

<krux02> when n is a NimNode and you want to get the string value of identifier, then yes

<subsetpark> I know globals can be marked {.threadvar.} to make them thread-local, but what exactly does that do? Does it reinitialize a new copy of the variable for each thread? Or does it simply tell the compiler that I'm doing that manually?

<krux02> subsetpark, I am not sure exactly, I just know that thread_local makes an instance of that variables per thread.

<krux02> (in c++)

From IRC (bridge bot)

@FromIRC

<subsetpark> I have the impression that all I have to do is mark as {.threadvar.} and it will magically be taken care of (esp. because it doesn't get mutated) - I just want to make sure that I am not mistaken, and that I don't have to actually change how I instantiate it myself

<dom96> you do have to instantiate it yourself

<dom96> (in each thread)

<subsetpark> hm ok

<subsetpark> so if i have a proc which makes use of a hash table (which never changes), and I want to be GC-safe - can I instantiate within the proc and mark as {.global.} ?

<subsetpark> (because I don't want to re-instantiate every time the proc is called)

From IRC (bridge bot)

@FromIRC

<dom96> create a proc that checks if the global variable has be initialised

<dom96> if so return the variable

<dom96> otherwise init and return the variable

From IRC (bridge bot)

@FromIRC

<subsetpark> ok that works

Where communities thrive

People

Repo info

Activity