Stainless steel sinks were introduced to households in the mid-20th century.
They are affordable and lightweight, and they are practically unbreakable.
However, maintaining the new look of a stainless steel sink can present
problems, especially in hard-water areas. Dissolved minerals in the wate
Hi,
I'm trying to see if regions is appropriate for FFI interfaces. I need to
allocate some sequences and pass it to FFI functions and later, dealloc them.
Currently, GC_Ref and GC_Unref is an option, but still a bit unintuitive and
have to be very careful for every allocation. With regions, th
Hmm, how might my attempt at this go wrong? I have
`logging.setLogFilter(lvlNotice)` at the top after `import logging` but still
jester is showing INFO level logging. I can make other changes and they show up
okay.
@emg \- as @cdome mentioned - your best bet is to look at the code since the
feature isn't really documented.
You can explicitly free the region, however I have a feeling the GC will
collect it anyway regardless.
Not sure what you're trying to achieve with regions - I haven't seen them used
an
Which C lib are you trying to use?
You check it's code to have an idea how it is working
[https://github.com/nim-lang/Nim/blob/devel/lib/system/gc_regions.nim](https://github.com/nim-lang/Nim/blob/devel/lib/system/gc_regions.nim)
The link doesn't contain anything useful. Even the docs of importcpp is useless.
IMO, you need to use with_region template
Is there an up-to-date guide on how to do FFI with C++ shared libraries?
https://nim-lang.org/docs/backends.html
fails on `devel` too
Seems I managed to bring the macro/generics processing to its limits.
Compiling the following program fails with a compile error from gcc:
import macros
type
Expression* = ref object of RootObj
VarExpression = ref object of Expression
name: s
> Well noted, I could provide more detail (and I did for Nim which is worth it)
> but I don't for D.
No you didn't develop for Nim as well.
> With all due respect I'm not interested in your list. Those things are
> technicalities. A good language, however, needs deeper insights (I'd even say
>
@sayol, I'm the creator of that library. In order to export the class, you need
to put the export marker with of RootObj at the end. This is due to some
limitations in the Nim parser.
You also need the export markers on all methods/properties you want to be
exported, just as @mratsim suggested.
Thanks for the reply.
So to use regions, do you have to declare regions manually or does the compiler
take care of it automatically when compiled with --gc:regions? I ask this
because even using stdlib, when compiled with --gc:regions the compiler doesn't
throw any errors and everything works a
Hmm, I see. A classical political correctness and Über-Ich argument ...
Well, no. I clearly said "personal summary" and I have no obligation to meet
any arbitrary conditions like e.g. "examples!" Well noted, I _could_ provide
more detail (and I did for Nim which is _worth it_ ) but I don't for D
Awesome! I saw this while mobile and forgot to reply, but this is exactly the
kind of logical reason I was looking for. Thank you!
\--gc:stack has been named --gc:regions|
---|---
[https://github.com/nim-lang/Nim/blob/devel/lib/system/gc_regions.nim](https://github.com/nim-lang/Nim/blob/devel/lib/system/gc_regions.nim)
There is not really any documentation - you basically create a memory region
and then use the provi
Dear All,
Does anyone have an implementation of a progress bar/message that works with
spawn?
Marking the type as exported is not sufficient. You have to mark the field pos
as exported (and also for the field dir I guess):
import nico/vec
type
GameObject* = ref object of RootObj
pos*: Vec2i
Player* = ref object of GameObject
dir*: i
You have to mark pos field in GameObject with a star also to make it accessible
from your main.nim module. Unless you do that, it is considered not public, but
private to types.nim module.
Hello there. I am getting a really confusing error message.
"Error: attempting to call undeclared routine: 'pos='"
when doing this (shortened down to relevant bits, code is based on nico
examples):
main.nim
import types
proc newPlayer(x,y: int): Player =
result
Thanks Stefan,
I will copy the string on the heap to avoid it to be overwritten and cast it to
a Raw_Frame ptr.
1. only one memcpy is necessary
2. it can be optimized better
3. casting to a tuple eases coding as you don't have to remember where is
what.
4. no mem management gets in my w
There's no need for disparaging other languages, especially without examples to
give more substance to your claims.
I do feel like in terms of design goals and at a high level, D is the closest
cousin of Nim.
* statically compiled
* strong meta-programming and CTFE
* C and C++ FFI
* Pro
I didn't test and never used the oop library but you are probably missing the
public export marker `*`
import oop
class MyClass:
var
value*: int
method init*(value: int){.base.}=
self.value = value
method prin
I found day 7 to be the most challenging and rewarding to solve thus far. Day 9
was pretty cool as well.
26 matches
Mail list logo
