Nim version 2.0.0 is here

[Isofruit]

Super cool! Thanks @moigagoo!

newSeq() named inconsistently?

[hamidrb80]

It would be nice to introduce `initSeq` in Nim 2

newSeq() named inconsistently?

[Araq]

Meh, what's the point. Human brains can handle a couple of exceptions. And they 
can handle these better than a constant stream of micro changes.

Nim version 2.0.0 is here

[junelac]

Congratulation !

Problems compiling objc code including on osx

[krakengore]

Hello, i'm trying to compile this simple program:


{.passL: "-framework UIKit".}

type
MTLDevice* {.importc, header: "", incompleteStruct.} = 
object

proc MTLCreateSystemDefaultDevice(): MTLDevice {.importc, header: 
"".}

proc main() =
let device = MTLCreateSystemDefaultDevice()
discard device

when isMainModule:
main()


Run

But it produces:


kunitoki$ nim objc -r test.nim
Hint: used config file 
'/Users/kunitoki/.choosenim/toolchains/nim-2.0.0/config/nim.cfg' [Conf]
Hint: used config file 
'/Users/kunitoki/.choosenim/toolchains/nim-2.0.0/config/config.nims' [Conf]
..
CC: ../.choosenim/toolchains/nim-2.0.0/lib/system/exceptions.nim
CC: ../.choosenim/toolchains/nim-2.0.0/lib/std/private/digitsutils.nim
CC: ../.choosenim/toolchains/nim-2.0.0/lib/system/dollars.nim
CC: ../.choosenim/toolchains/nim-2.0.0/lib/system.nim
CC: test.nim
/Users/kunitoki/.cache/nim/test_d/@mtest.nim.m:8:10: fatal error: 
'UIKit/UIKit.h' file not found
#include 
 ^~~
1 error generated.
Error: execution of an external compiler program 'clang -c  -pthread   
-I/Users/kunitoki/.choosenim/toolchains/nim-2.0.0/lib 
-I/Users/kunitoki/nim_test -o /Users/kunitoki/.cache/nim/test_d/@mtest.nim.m.o 
/Users/kunitoki/.cache/nim/test_d/@mtest.nim.m' failed with exit code: 1


Run

Any idea what i should be looking for ? (i have xcode tools installed and ready 
if that is what you are thinking).

Karkas: Karax library to build layouts and work with styles

[hugogranstrom]

Nice work, will try this out next time I need to create something requiring 
layouts :)

> I'd like to do a special shoutout to the Nimibook team. In the docs, the 
> frontend samples are rendered live inside the doc pages, thanks to Nimib's 
> nbKaraxCode blocks. It's such a powerful feature, I'm loving it.

That's awesome to see the javascript features of nimib being put to use 🤩 

Nim version 2.0.0 is here

[Pumpus]

Hi! Great job!

Unfortunately nimble doesn't work anymore here. I'm on Windows 10. I can't 
install any package. Any idea? 

newSeq() named inconsistently?

[awr1]

i am not really sure that i am a fan of adding `init` and `new` as it would 
give the false impression of how constructing objects works in Nim.

an alternative convention: `init` and `new` in this case do not refer to 
copying semantics but whether or not the object is heap-backed.

Problems compiling objc code including on osx

[awr1]

* the header is unnecessary if you have the binary definitions, which is that 
`MTLDevice` is a `ptr object` and that `MTLCreateSystemDefaultDevice()` is of 
calling convention `cdecl`
* you need to also link in `-framework Metal` and `-lobjc`. if you want to use 
the header you need to pass the framework to the compiler and not just the 
linker

Karkas: Karax library to build layouts and work with styles

[Isofruit]

nimibook keeps providing reasons for me to write docs in them :-P

Cool to see you're working on a nicer karax abstraction! Looks good!

Nim version 2.0.0 is here

[kazuki]

Congratulations🎉

Nim version 2.0.0 is here

[Isofruit]

You'll have a better chance to get decent troubleshooting in the discord ;-) 
Though in general providing more information on _how_ the installation causes 
problems doesn't hurt ^^

Nim version 2.0.0 is here

[elcritch]

Finally! I wonder if calling it a "warning" by default helped.

It was great to see a lot of comments on HN about people using Nim and 
interested in building stuff instead of (just) bike-shedding! 

Is ORC considered production-ready? What is the consensus on its use?

[elcritch]

It's a bit later, but it does seem like the stdlib's async library will need 
some TLC to work well with ORC. Future's cause all sorts of chaotic cycles. 
Ideally the core async library will be ARC compatible itself, which would make 
it more deterministic.

Also, using ORC on embedded is tricky since the cycle collector doesn't run 
often enough. There used to be a "debug mode" which ran the cycle collector 
more often, but I couldn't find it the last time I looked. That may be an 
important property to tune in the future as well.

Problems compiling objc code including on osx

[elcritch]

You may also find looking at how Windy does it:

  * 

  * 

Is ORC considered production-ready? What is the consensus on its use?

[elcritch]

> Atomic refcounting works, however, because the access to heap memory is 
> protected by atomic operations even when the ref variable goes out of the 
> scope, and thus prevents races.

It's very important to note that _only_ protects against races in the atomic 
count, _not_ data races in general.

In my opinion, relying on just atomic-ref's is an easy way to lure developers 
into a false sense of security like is seen in Golang. Essentially you have one 
of: read only data (atomic sharedptr wrappers), movable data with single 
ownership (Isolate[T]), or you need some sort of locking mechanism around the 
data in "atomic chunks" (locks).

Is ORC considered production-ready? What is the consensus on its use?

[elcritch]

On that topic, @arnetheduck is Chronos non-cyclic / ARC capable now? I recall 
reading that it was, but would be curious if there have been updates in that 
world. Especially it looks looks like there was some big refactoring in Chronos 
recently.

CBOR?

[elcritch]

Out of curiosity, has anyone made a complete CBOR implementation? I recall 
seeing a couple of partial ones last year, but haven't followed up since.

newSeq() named inconsistently?

[alexeypetrushin]

Things like this should be just instantly fixed and moved on, without unneeded 
RFC discussions, Proc/Cons consideration etc. Its problems like this are Nim 
number one problem.

newSeq() named inconsistently?

[Araq]

It's not good to mislabel a tiny quirk as a "bug" either.

Any way to produce Arm64 binaries for MacOS from choosenim versions of nim?

[JohnLuck]

I am on Arm macos and when I compile anything it produces x86_64 binaries, 
(which Macos will interpret). This does not work for compiling dynamic 
libraries which are included in pure Arm projects. Adding --cpu:arm64 does not 
seem to make a difference.

If you try this out, check the actual architecture of the file using `lipo 
-archs filename` as macos will run x86_64 binaries interpreted.

Also is there a place I can find older stable prebuilt nim versions somewhere?

Is ORC considered production-ready? What is the consensus on its use?

[arnetheduck]

> On that topic, @arnetheduck is Chronos non-cyclic / ARC capable now? I recall 
> reading that it was, but would be curious if there have been updates in that 
> world. Especially it looks looks like there was some big refactoring in 
> Chronos recently.

chronos has been acyclic for a good while for memory efficiency reasons - ie 
even with refc, it is a lot better to avoid cycles... as to arc, we don't test 
that specifically and I don't think we ever will.

I imagine that in some future when orc is (more) stable we'll start using / 
supporting that, but ARC looks like a niche compromise that will never work 
quite well because developers will keep shooting themselves in the foot with it 
and then complain it hurts. 

Show Nim: JWTea, Crunchy and Depot. New repos you may find useful.

[grd]

Good question. You need to realize that @guzba only committed 7 times and is 
currently apparently "away" from github. Maybe you can create an issue, since 
the only issue in there has been fixed recently. Was that you?

CBOR?

[blackmius]

it's bad answer, but why not msgpack?