!EtGqjSRNQoJCbpCJSF:matrix.org

Nim programming language

8422 Members
Official Matrix channel for the Nim programming language. This channel is bridged with our main Discord and Gitter channels.96 Servers

Load older messages


SenderMessageTime
1 Nov 2024
@leorize:envs.netleorizeso stuff like this are expected19:20:43
@leorize:envs.netleorize

this is more akin to Rust's mem::take than a traditional move

19:21:11
@_discord_200775012796334081:t2bot.iograveflo sink seems to do this just fine in a more sane way. Why use move that just puts the "use after move" scenario in a state of uninitialize memory rather then it's current state 19:23:44
@_discord_607600292086939696:t2bot.iofabric.input_output more like c++ std::move 19:23:49
@_discord_200775012796334081:t2bot.iograveflo Just trying to get the rational of what to use this for. iirc sink will not make a copy as long as you do not mutate the object after it was sunk (barring situations where a copy is inevitable) 19:24:13
@_discord_200775012796334081:t2bot.iograveflo and by that I mean mutate it in the calling context after giving it away. Not the context where is was given to 19:25:05
@_discord_318284269908918273:t2bot.ioguzba8
const
  n = 1000
  chunkLenLimit = 10

var chunks: seq[seq[int]]
block:
  var chunk: seq[int]

  for i in 0 ..< n:
    chunk.add(i)
    if chunk.len == chunkLenLimit:
      chunks.add(move chunk)

  if chunk.len > 0:
    chunks.add(move chunk)

echo chunks.len

take a long list of big things, add them to a set of smaller chunks without copying memory
19:26:10
@_discord_318284269908918273:t2bot.ioguzba8 in this case int would be something huge like a big string 19:26:22
@_discord_200775012796334081:t2bot.iograveflo right I think if you did this it should be the same (since add is annotated with sink):
const
  n = 1000
  chunkLenLimit = 10

var chunks: seq[seq[int]]
block:
  var chunk: seq[int]

  for i in 0 ..< n:
    chunk.add(i)
    if chunk.len == chunkLenLimit:
      chunks.add(chunk)
      chunk = newSeq[int]()

  if chunk.len > 0:
    chunks.add(move chunk)

echo chunks.len
19:27:59
@_discord_318284269908918273:t2bot.ioguzba8 nope you need to explicitly steal it from the big seq 19:28:21
@_discord_318284269908918273:t2bot.ioguzba8 i just did add(i) but it really is add(move bigseq[i]) 19:28:32
@_discord_318284269908918273:t2bot.ioguzba8 it partially works 19:28:50
@_discord_200775012796334081:t2bot.iograveflo I see what you are getting at with that 19:31:05
@_discord_318284269908918273:t2bot.ioguzba8
chunks.add(chunk)
chunk = newSeq[int]()

does nim actually sink chunk in this case? it is referenced later, even tho just to reinitialize
19:31:15
@_discord_318284269908918273:t2bot.ioguzba8 it should be but ive not tested that 19:31:20
@_discord_200775012796334081:t2bot.iograveflo there is the issue of bigseq having a hole in it after that happens, which does seem to be linked to this type of situation in general, but eh 19:31:26
@_discord_200775012796334081:t2bot.iograveflo I'm actually not sure 19:32:10
@_discord_200775012796334081:t2bot.iograveflo well it always sinks it.. question is, is nim smart enough to know that resetting the value ensures that it is not mutated after the sink 19:32:44
@_discord_200775012796334081:t2bot.iograveflo
--expandArc: main

var chunks
block :tmp:
  var chunk
  block :tmp_1:
    var i_cursor
    mixin inc
    var i_1 = 0
    block :tmp_2:
      while i_1 < 1000:
        var :tmpD
        i_cursor = i_1
        add(chunk):
          :tmpD = i_cursor
          :tmpD
        if len(chunk) == 10:
          add(chunks):
            let blitTmp = chunk
            `=wasMoved`(chunk)
            blitTmp
          `=sink`(chunk, newSeq(0))
        inc i_1, 1
  `=destroy`(chunk)
`=destroy_1`(chunks)
-- end of expandArc ------------------------
19:35:18
@_discord_318284269908918273:t2bot.ioguzba8 i look at this and still have no idea if it avoids a copy 19:38:20
@_discord_318284269908918273:t2bot.ioguzba8 but this is the right thing to check ofc 19:38:47
@_discord_200775012796334081:t2bot.iograveflo if you don't re-initialize it you get a dep which is what I would expect:
--expandArc: main

var chunks
block :tmp:
  var chunk
  block :tmp_1:
    var i_cursor
    mixin inc
    var i_1 = 0
    block :tmp_2:
      while i_1 < 1000:
        var :tmpD
        i_cursor = i_1
        add(chunk):
          :tmpD = i_cursor
          :tmpD
        if len(chunk) == 10:
          var :tmpD_1
          add(chunks):
            :tmpD_1 = `=dup`(chunk)
            :tmpD_1
        inc i_1, 1
  `=destroy`(chunk)
`=destroy_1`(chunks)
-- end of expandArc ------------------------

so yea.. done spamming the chat for now. sry. Pretty sure this means that it is not making a copy. wasMoved and sink shouldn't create a copy
19:43:16
@_discord_200775012796334081:t2bot.iograveflo * if you don't re-initialize it you get a dup which is what I would expect:
--expandArc: main

var chunks
block :tmp:
  var chunk
  block :tmp_1:
    var i_cursor
    mixin inc
    var i_1 = 0
    block :tmp_2:
      while i_1 < 1000:
        var :tmpD
        i_cursor = i_1
        add(chunk):
          :tmpD = i_cursor
          :tmpD
        if len(chunk) == 10:
          var :tmpD_1
          add(chunks):
            :tmpD_1 = `=dup`(chunk)
            :tmpD_1
        inc i_1, 1
  `=destroy`(chunk)
`=destroy_1`(chunks)
-- end of expandArc ------------------------

so yea.. done spamming the chat for now. sry. Pretty sure this means that it is not making a copy. wasMoved and sink shouldn't create a copy
19:43:24
@reh678:matrix.orgMuhammad Rehan Khan joined the room.21:11:57
@rf.c:matrix.orgClonkkIs there a way to automatically import from C header identifier that can either be an enum or a macro pointing to that enum, without having to re-calculate the enum value 23:07:55
@elegantbeef:matrix.orgElegantbeefFuthark?23:11:20
@rf.c:matrix.orgClonkkWouldn't that gives me all the symbol from the headers ? 23:14:07
@rf.c:matrix.orgClonkkI guess dead code will be eliminated on compilation23:14:20
@leorize:envs.netleorizeunless your header is gigantic (which would meant slower compile time), I'd say that the dead code wouldn't be too much of an issue23:38:48
@_discord_392962235737047041:t2bot.iopmunch Yes it would, but as you mention dead code elimination makes this a non issue, 23:47:02

There are no newer messages yet.


Back to Room ListRoom Version: