Forbidden-by-default effects?

How about: type YieldPermission = object proc `=copy`(dest: var YieldEffect, src: YieldEffect) {.error.} # you cannot duplicate yield permission proc jield*(y: YieldPermission) = discard # todo: implement me proc createYieldPermission(): YieldPerm

how to integrate existing react components in karax?

Did this post get renewed?

how to integrate existing react components in karax?

Can you tell me what karax is, I'm not really familiar with this concept. I'm a novice programmer, please don't be angry for my stupid questions. I'm just curious.

How to hide FFI details from implementations of a (C FFI) interface?

Thanks for your replies. I'll try to wrap my head around this soon again, see how far I can get and report back.

Zen of Nim

There is a typo: `s/byndSym/bindSym`

Forbidden-by-default effects?

> Does this sound like a good idea or am I overlooking something? It does sound like a good idea, assuming that the effect system is a good idea. ;-)

htmlgen question

Yes, that's great! Thanks for the reply!

Question about memory management with bindings

https://nim-lang.org/docs/destructors.html

Question about memory management with bindings

I am working with the bindings to MLT. You can create a number of producers: `newProducer`. Once used you would destroy them with: `close`. So the pattern needed would be something like: p1 = newProducer() p2 = newProducer() ... ... p1.close() p2.close()

Forbidden-by-default effects?

Hey, I've recently been exploring the effect system as a way to stop people from calling coroutine-only functions outside of a coroutine. This _seems_ like a prime use-case for effects. # coro.nim type YieldEffect = ref object of RootEffect proc jield*() {.tags: [Y

Preview of coming attractions?

Thanks for linking me to this - I appreciate seeing the example. I think I'll need to extend this example to be able to handle scope-based allocation and things like that, but this is definitely a step in the right direction. I'd love to see this kind of thing get easier / better supported.

UFCS issue

Wow thanks a lot. I think I would have never found it.

Preview of coming attractions?

I actually stumbled upon the very same problem, and I found a way to use custom allocators within Nim's ARC. It's a bit hacky, as it requires to "patch" a stdlib module, but it works perfectly. Take a look here:

Preview of coming attractions?

Precisely - if I can't use Nim types with my own custom allocators I want to at least be sure that the runtime isn't making any allocations for me without my knowledge. I know I can in effect do this by just not relying on any stdlib module, but the warnings from `--gc:none` are extremely valua

Preview of coming attractions?

Thanks, that's useful feedback. (No irony here.) So you don't care about the `--gc:none` mode all that much but about the _warnings_ it produces (which originally were added as an afterthought).

Preview of coming attractions?

I know with ARC I can implement my own custom allocators and destructors and not rely on Nim's default memory allocation strategy. The problem here is that `--gc:none` currently does a great job of informing me of when the runtime makes an allocation for me. Without that feature, if the runtime

Preview of coming attractions?

I just see Nim trending more and more towards some high level language. `--gc:none` is being removed because it was a "failed experiment" and "ARC" succeeded yet I still have no good way to opt out of manual memory management / write my own custom allocators. Your solutions of override malloc or

Preview of coming attractions?

> I still have no good way to opt out of manual memory management / write my > own custom allocators. Your solutions of override malloc or patch the stdlib > aren't good enough... Please be more specific, what do you need to do.

Zen of Nim

A transcript of Araq's presentation at NimConf2021 is now available as a blog post (thanks to @pietroppeter!):

compiling to macOS

Why not just setup up a virtual machine to test on? You can virtualize virtually an OS now days. I recommend using KVM or VBox /

htmlgen question

Here's some ideas -

Preview of coming attractions?

What is missing for ORC ?. (Other than doing it default, that I doubt will happen soon).

Preview of coming attractions?

> What is missing for ORC ? Nothing but bug fixes and as far as I'm aware all major bugs have been fixed.

UFCS issue

If I've found the right code you've got type ConsumerS = object ... close: proc (a1: Consumer) {.cdecl.} Consumer = ptr ConsumerS Run which means `c.close()` refers to the member `close` of c, i.e. a proc which expects a parameter

Evolving the moderation of the Nim communities

Hello everyone, We wanted to take this opportunity to announce a few changes to the moderation of the Nim communities. Firstly we are announcing the appointment of new moderators. The current list includes @Vindaar, @mratsim, @Yardanico, @ftsf, @PMunch, @federico3 as well as @Araq and myself.

Treat memory allocation as effect?

PR-wise, it is often easier to put some new, questionable feature behind an `experimental` or `when defined` barrier to make it easier to remove/overhaul if it turns out to be undesirable. Unsure if that is possible/warranted in this case, but seemed worth mentioning (and also mentioning that it

Preview of coming attractions?

I would push back against making any sweeping claims about what Nim is for and what it isn't for. After all Nim is the one language to rule them all :) It's important to make a distinction between the Nim core devs being spread too thin (because we are trying to implement features for all domain

Treat memory allocation as effect?

> To rephrase my question, if Nim has an effect system and it's not going away, > then it'd be nice to use it to solve problems me and others run into. Or > rather enable community members like myself to try out ideas to see if it'd > even be feasible or useful. Maybe it's a PR to enable others

Treat memory allocation as effect?

Let's focus on the proposal in this thread and stop diverging into an off-topic discussion about feature removal. Feel free to open another thread about this topic specifically, but note that other posts here regarding this topic are likely to be removed.

Treat memory allocation as effect?

> You can say that v1 already had too much cruft in it we should have removed > for v1 There was (at least) [this forum discussion](https://forum.nim-lang.org/t/3772) back around the time. It is often hard work to remove features giving workarounds to users. This indeed would have delayed the l

dot-like operations and calls

If you were to ask me, I would prefer either the `DotLike` or the old `Call` options, because they're explicit. The `Infix` with more arguments would also work for me. But I have no insight into how the parser works for the dot-like operators, and what is achievable without too much hassle.

Readability problems

Too many harsh words, I'm closing this thread.

How to hide FFI details from implementations of a (C FFI) interface?

> # How to allow assignment of implementation with type > # `proc (number: > uint): uint` to `aDescriptor.aProc` of type > # `proc (container: > aContainer): aContainer`? > > Via a converter which > # extracts the integer from the container prior > invocation and puts it > # back after? Conver

UFCS issue

Might be that `impmltDyn` macro is causing the `a` parameter to `mlt_consumer_close` to disappear. Try doing import std/macros expandMacros: proc mlt_consumer_close*(a1: mlt_consumer) {.importc, cdecl, impmltDyn.} Run and see what it expands to.

Treat memory allocation as effect?

> Nim's original design philosophy was to be a lean, simple, powerful, elegant > and efficient garbage collected programming language. It has drifted so far > from that original design premise, because it has had all of these > experimental and R&D'd features to it that have eventually gone out