Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 03 2017 15:52
    @dom96 banned @Octopoda7
  • Feb 12 2017 23:57
    @dom96 banned @zzz125
  • Dec 23 2016 19:43
    @dom96 banned @Izrab
Matt Haggard
@iffy
(or a dual target one)
Kaushal Modi
@kaushalmodi
sounds like it
you seem to have only 64-bit versions of those libs like msvcrt
From IRC (bridge bot)
@FromIRC
<narimiran> @vindaar ok, i can reproduce it on my machine too
Vindaar
@Vindaar
yay! thanks for testing
From IRC (bridge bot)
@FromIRC
<narimiran> it is about 15% slower
Vindaar
@Vindaar
only 15% on your machine? on mine it's almost a factor of 10 slower w/ debug build and ~4 w/ danger
Jason Koch
@jason_koch_twitter
i'm still trying to reinstall nim, lol, switched over OSs recently
From IRC (bridge bot)
@FromIRC
<narimiran> i have a quite old machine so it might have to do with that. i don't have all the fancy modern optimizations that you might have
Vindaar
@Vindaar
ah yes, maybe
From IRC (bridge bot)
@FromIRC
<clyybber> Soo, Araq, any idea? I can also do it for the checks in semcheck and still do the transformation in transf. The compile time impact isn't too big I think, and its only for case objects anyways.
<Araq> hmmm ok
Kaushal Modi
@kaushalmodi

Araq: This is what I got back when I asked my SV compiler vendor about the "client switching stacks" warning in valgrind:

The switching stack warning is coming when xmsim makes the dpi call (or you return). Xmsim doesn’t use a traditional c stack and it confuses valgrind when it makes c calls. You can definitely ignor that.

and

Not sure why the nim gc would be impacted by the internal way xmsim does its stack. When it calls the dpi you have a normal C stack frame at that point… it confuses valgrind because valgrind is seeing the jumps, etc., and it knows something funky is going on… but your dpi code should be pretty insulated from that unless nim is trapping all mallocs, not just the ones you use, and then is trying to free something it doesn’t own.

From IRC (bridge bot)
@FromIRC
<Araq> that's not what Boehm nor Nim do
<Araq> but both trace the stack conservatively
Kaushal Modi
@kaushalmodi
"calling the DPI" above means the call to the Nim compiled proc that I call from the SV side
From IRC (bridge bot)
@FromIRC
<FromDiscord> <WilliamDraco> Amateur here looking for a hand with threadpool - the moment I import it, the nim check (VSCode) throws many warnings/errors re: 'imported and not used' and 'template/generic instantiation's. I haven't even done anything with it, how is just importing it breaking so much? (Although it does actually compile... just mistaken checks?)
<PMunch> disruptek, but then I'd need to pass the body into the template
<Araq> @kaushalmodi: can you do GC_disable/GC_enable in your callback and schedule the GC at some better time
<PMunch> Essentially adding an indent level for every call to this function
<Araq> WilliamDraco: I'm not sure, stdlib warnings should be surpressed
<PMunch> I guess that is the clean solution though..
<disruptek> PMunch: but you need to indent anyway to put the variable in a scope where defer will free it, right?
Kaushal Modi
@kaushalmodi

Araq:

can you do GC_disable/GC_enable in your callback

You mean call GC_disable at the very beginning of the exportc'd proc and GC_enable at the very end?

and schedule the GC at some better time

How do I do this scheduling?

From IRC (bridge bot)
@FromIRC
<Araq> yes
Kaushal Modi
@kaushalmodi
wouldn't above be similar to running with --gc:none?
From IRC (bridge bot)
@FromIRC
<PMunch> disruptek, not really. I have let x = createThePointer(); defer: c_free x
<Araq> but then the GC must run at some time
Kaushal Modi
@kaushalmodi
GC_disable/GC_enable did the trick
though.. I did not get how to do the scheduling?
If I have only exportc'd procs in my Nim lib, and I disable GC when they are being run, when would GC actually run?
From IRC (bridge bot)
@FromIRC
<disruptek> PMunch: i get it. we should probably come up with a macro to do this.
<Araq> @kaushalmodi: I don't know, isn't there one exportc'ed proc that is actually called when there is a sane stack around...
Kaushal Modi
@kaushalmodi
each time a Nim exportc'd proc is called, it's called via the DPI-C interface in SV
so the SV simulator does that stack switching thing each time
From IRC (bridge bot)
@FromIRC
<Araq> this is not a "C interface", c doesn't allow stack switching
Kaushal Modi
@kaushalmodi
that means --gc:none is the best bet for now?
From IRC (bridge bot)
@FromIRC
<Araq> they claim it's a C interface, but it isn't. anyway, your only option then is --gc:none until --gc:destructors is ready
Kaushal Modi
@kaushalmodi
and then I can try out --gc:destructors
yes

so.. the "issue" I have with gc:none is that my terminal gets flooded with warns like:

Warning: 'setLen(result, 1)' uses GC'ed memory [GcMem]

I can ignore those warnings I believe, but I do not know how serious those warnings are
From IRC (bridge bot)
@FromIRC
<disruptek> this is fine.
<clyybber> house starts burning
<narimiran> clyybber: i'll sleep fine tonight
<clyybber> nice
<FromDiscord> <Aidiakapi> How do you pass a slice as a function parameter, I can't seem to find it for some reason?
Vindaar
@Vindaar
@Adiakapi: https://nim-lang.github.io/Nim/system.html#HSlice see also the procs which take a HSlice for reference
From IRC (bridge bot)
@FromIRC
<narimiran> or maybe what you want is toOpenArray