Nim (1.4 ORC) v.s. Rust in terms of safety?

> What's unsafe is dereferencing the pointers they produce. While technically correct, that is a dangerous path to safety: type Obj = object a: array[3, int] b: int var x: Obj let theEnd = addr(x.a[3]) # safe by Rust's definition? # unsafe by

Unexpected error vs [HSlice[system.int,system.int] when working with an integer array

Why do I get errors on lines 11,17,18 and 19. import strformat proc Play*() = var memy = [0..<3000] var myArray =[0,14,1,3,7,9] var turn:int = 0 var last:int = -1 for myIndex ,myvalue in myArray: last = myvalue memy[last] =

Nim (1.4 ORC) v.s. Rust in terms of safety?

It's called unsafe because it's a property of the scope; not a function. `unsafe {}` in Rust is **not** a contract by the developer, it's a checkbox that disable a few compiler checks that would otherwise make some necessary low level operation impossible. It's not the developer telling other d

Nim (1.4 ORC) v.s. Rust in terms of safety?

Nim already does something like this with types. As it is, every time you want to bind a socket to a port, you can't pass in a number, but have to say something like `Port(1234)`. There are similar uses with TaintedStrings and `type SQL = distinct string`. This model could be extended to stuff l

IS there any beginner friendly tutorial for nim with examples like "Python crash course" etc.?

> The ones on are not like "python crash > course". What specifically do you miss from Python Crash Course? That book has an introduction where you install Python, and then a Part 1 that is a tutorial that shows off language features with examples, and then a P

Nim (1.4 ORC) v.s. Rust in terms of safety?

> IMHO a better name for the keyword would have been actuallySafe. You've said this a couple of times but it would be much harder to shame a dev for having too many `actuallySafe` blocks in his code, and someone getting prompted to add such a block would think "oh, this makes it actually safe?

Seq, table. How to efficiently reference the last item

I stored the last at most two turns per number, so `Table[int, seq[int]]`. If number 37 appeared in the past two times, and the new spoken 37 comes out several turns later, you need to subtract those last two in the table. ([My solution](https://gist.github.com/fxn/be211ef18b9cfd0c05c143e1215e03

Seq, table. How to efficiently reference the last item

Ah, screw that. I misunderstood one of the examples as more generic than it is, `Table[int, int]` is enough.

Nim (1.4 ORC) v.s. Rust in terms of safety?

So every time I want to get something from a Table, I'd need to do: var t: Table[int, string] actuallySafe: if t.hasKey(1): echo t[1] Run No thank you.

Nim (1.4 ORC) v.s. Rust in terms of safety?

So I'm a Rust noob, but I was porting some code to Nim :) I came across this code: self.slots .get(key.idx as usize) .filter(|slot| slot.version == key.version.get()) .map(|slot| unsafe { // This is safe beca

one more "collect" question (bug?)

Not a bug, I though it would be expected, after the set report you made :), workaround is the same.

one more "collect" question (bug?)

Not a bug, I though it would be expected, after the set report you made :), workaround is the same.

Nim (1.4 ORC) v.s. Rust in terms of safety?

@Araq: That's not the way I'd usually write a Rust `unsafe` block. The block does nothing to ensure that the dereferences are safe. If we assume in this case the only danger is that the pointers might be nil, then: unsafe { if r1 != nil { println!("r1 is: {}", *r1); }

Nim (1.4 ORC) v.s. Rust in terms of safety?

I've put my money where my mouth is and written [an RFC](https://github.com/nim-lang/RFCs/issues/302) ... not for `unsafe` itself, but for two extensions to the effects system that would allow it to be partially implemented in Nim code. I think these extensions would have other uses as well, an

Nim (1.4 ORC) v.s. Rust in terms of safety?

This is getting silly but consider this Rust code: unsafe { println!("r1 is: {}", *r1); println!("r2 is: {}", *r2); } Run What is unsafe about it? Only the `*r1`, `*r2` operations. So Rust's "superior" `unsafe` block is actually impre

one more "collect" question (bug?)

If I understand the message correctly, `collect` expect the type to be generic, but `string` is not generic.

Nim (1.4 ORC) v.s. Rust in terms of safety?

Oh by the way — > The unsafe constructs are cast and addr and unsafeAddr. Easy enough for code > reviews, no big difference to Rust. That's not actually true. Neither addr nor unsafeAddr can cause a crash or UB. What's unsafe is _dereferencing_ the pointers they produce. (I was going to say th

Nim (1.4 ORC) v.s. Rust in terms of safety?

> ctrl-f cast: 0 hits Huh. I'm not clear on why passing a `string` to a `cstring` parameter works in your code but not when I try it. Or is passing a string literal somehow different than passing a variable? > It's still not good enough to be part of a Nim library's public API Agreed. And I'm

one more "collect" question (bug?)

Either way we should investigate, please report it on github.

Seq, table. How to efficiently reference the last item

Thanks I think that was it!

C++ Smart pointers 101 and FFI

> I understand that this is how C++ deal with the lack of GC, is it like that? C++ smart pointers are actually very much like the way Nim ARC is implemented internally. Or the other way around, under ARC a `ref` is like a C++ smart pointer. (To be pedantic, this applies to ref-counted smart poi

Seq, table. How to efficiently reference the last item

@hyl \- you may be thinking of `adix/lptabz.nthKey` (or `nthPair`) in compact, insertion-ordered mode. (Maybe I should make that be `[]` for positional access and `{}` for keyed access, but this [seems unpopular](https://forum.nim-lang.org/t/6167#38125).) That mode is active when sentinel type

lint+ - an improved linter for the lite text editor, incl. Nim support

I'm not sure I understood correctly, but you're mentioning the lack of highlighting in fmt, right? Well unfortunately, due to the limitations of lite's highlighter, that's not really possible without incorporating a custom highlighting engine to the plugin. Personally I don't use fmt that much,

Seq, table. How to efficiently reference the last item

> they used a standard Table[int, int] with key as number and value as turn > last seen. You would also keep track separately of the last element. This.

Seq, table. How to efficiently reference the last item

The keys for the Orderedtable arrive in a random sequence and may be repeated. The sequence associated with each key stores the step number on which the key arrives. If I get Keys of 3,2,5,9,2,3, the sequences for key 3 and 2 would have two items each (1,6) and (2,5) for Keys 2 and 3. If I ask

Seq, table. How to efficiently reference the last item

for the specifics of Day 15 problem I think that most people (including myself) did not use an OrderedTable, instead they used a standard Table[int, int] with key as number and value as turn last seen. You would also keep track separately of the last element. As far as I know the use case for O

IS there any beginner friendly tutorial for nim with examples like "Python crash course" etc.?

Very beginner friendly tutorials: Hope this helps, and good luck on your journey. Before you know it you'll be an absolute killer.

Seq, table. How to efficiently reference the last item

I didn't see it mentioned, but mySeq.high also exists. That is: `let lastElement = mySeq[mySeq.high]`. That can be useful sometimes, eg: `for i in 0..mySeq.high: ...` That doesn't help in the OrderedTable example though, you still need to know the key. I'm a little surprised that there isn't an

Seq, table. How to efficiently reference the last item

Advent of Code 2020 Day 15.

Seq, table. How to efficiently reference the last item

How do you expect `myTable[ myTable.len ][ myTable[ myTable.len ].len ]` to work? If the table has holes, that means `myTable[myTable.len]` will not make much sense, and indexing seqs by their length errors because Nim is 0 indexed. You might want a `seq[(int, seq[int])]` here, from my knowledge

IS there any beginner friendly tutorial for nim with examples like "Python crash course" etc.?

thanks

Seq, table. How to efficiently reference the last item

How about keeping a “maximum index of the table” variable and updating it when you add to the table? Then you can just write `myTable[maxIndex][^1]`.

Seq, table. How to efficiently reference the last item

I have holes hence the use of a table.

Seq, table. How to efficiently reference the last item

There's no such thing as a "last" index in a table. If your table doesn't have holes, you may as well use a `seq[seq[int]]`, in which case the last index of the last seq in the seq would be written as `mySeq[^1][^1]`.

Seq, table. How to efficiently reference the last item

Taking tentative steps into nim coming from VBA by having a go at Advent of Code 2020 I have an OrderedTable[ int, seq[ int ] ] what is the most nimy (minish, nithonic?) way to get the value of the last item of the last sequence in the table when you don't now the specific indeces. At the mome

C++ Smart pointers 101 and FFI

I wrap them with: type CppUniquePtr* {.importcpp: "std::unique_ptr", header: "", byref.} [T] = object Run And then I can sue them in Nim

Concat for linked lists?

No, ignore the `` thing, it's dead already.

Advent of Nim 2020 megathread

I see my repository is already listed here :) But for those who don't follow the IRC/Discord/Gitter channel I am also live-streaming my attempts at solving the AoC every day on both [YouTube](https://www.youtube.com/playlist?list=PL9Yd0XwsGAqzeDak6qtp6hQ4m7Qo_XA_4) and [Twitch](https://twitch.t

Concat for linked lists?

Thanks for the tip! There is one possible problem: the head of linked lists is defined as `(ref SinglyLinkedNodeObj[T])`, which seems to mean that the memory pointed by `head` is `owned`, whatever that means. After the proposed operation, the two lists would share structure, could this cause an