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
From IRC (bridge bot)
@FromIRC
<Araq> wNim does use yuriy's work iirc
liuxiaodong
@gogolxdong
write once , run everywhere.
From IRC (bridge bot)
@FromIRC
<PMunch> @gogolxdong, that is the plan. My preliminary experiments target Gtk and Karax
From IRC (bridge bot)
@FromIRC
<clyybber> Araq: Or we just remove the special case of treat f([...]) like f(...) for the moment
<clyybber> Since it isn't neccessary
From IRC (bridge bot)
@FromIRC
<Araq> clyybber, come on
<Araq> you invented partially materialized objects and don't want them?
<clyybber> Hmm, I'll try to make them work without problems
<clyybber> Btw, Araq. Unifying pArg and p doesn't make as much sense as I thought it would
<clyybber> The only real overlap there is the handling of arguments of nkCallKinds
<clyybber> But that can be extracted into helpers
From IRC (bridge bot)
@FromIRC
<Araq> ok
From IRC (bridge bot)
@FromIRC
<Zevv> I think I asked this before, but can't find it in the irc logs: is there a way to control name mangling inside templates? I now pass dummy arguments to the template just to make sure these names are not suffixed, or I make the whole template .dirty. Are there other methods to do this?
From IRC (bridge bot)
@FromIRC
<leorize> Zevv: {.inject.}
<leorize> it's in the manual as well, though it might not be that apparant
From IRC (bridge bot)
@FromIRC
<Zevv> hmm let me see if i can fit that in
From IRC (bridge bot)
@FromIRC
<disruptek> tuples... shouldn't we be able to use fields as a default iterator? and shouldn't we have a contains?
bevo009
@bevo009

Hi all, I wrapped C++ fmt::print & fmt::format:

proc print*(formatstr: cstring) {.header: "/c/h/format.cc", importcpp: "fmt::print(@)", varargs.}
proc format*(formatstr: cstring) {.header: "/c/h/format.cc", importcpp: "fmt::format(@)", varargs.}

print works perfectly in Nim, but I'm having no luck using format
In C++ you would assign a variable to the formatted string and print it as below:

string msg = fmt::format("The answer is {}", 42);
cout << msg << endl;

How would I do it in Nim?
I copied the below strformat method:

import strutils, strformat
var msg = &"$# is {3.14159265:.3f} to $# places" %  ["pi",  $3]
echo msg            # works as expected
print("{}\n", msg)    # this also works

But trying to assign fmtformat to a variable throws an error:

var nsg = fmtformat("{}\n", 42)
print("{}\n", nsg)

Error: expression 'fmtformat("{}\n", 42)' has no type (or is ambiguous)

Any idea what I'm doing wrong? Cheers for any help

From IRC (bridge bot)
@FromIRC
<Araq> Zevv, .dirty templates are not really "dirty", they are far simpler to understand and maybe we got the default wrong
From IRC (bridge bot)
@FromIRC
<Zevv> hmm yes I just spent some time figuring out what happens and how, and dirty is indeed less "messy"
<Zevv> but my setup is pretty complex anyway, 5 calls deep into macro > proc > getasts > template > proc > template
<Zevv> that's kind of like 6
<Zevv> but how are they not really "dirty"?
<Zevv> because relative to normal templates, they are
bevo009
@bevo009
I'm going through Miran's book and the 1st proc throws an error
What's wrong with it?
proc findMax(x: int, y: int): int =  
  if x > y:
    return x  
  else:
    return y
findmax(5, 6)
# Error: expression 'findMax(5, 6)' is of type 'int' and has to be discarded
From IRC (bridge bot)
@FromIRC
<Zevv> you are calling the function but not using its return value
<narimiran> bevo009 you need to echo the result, or do something with it
<Zevv> so you eather need to use it, or explicitly "throw it away", using "discard findmax(5, 6)"
<Zevv> And we all know Mirans books are known to be full of errors
<Zevv> oh, wait, he's here. I didn't say that
<narimiran> :⁠P
bevo009
@bevo009
doh! should have tried echo...disregard
From IRC (bridge bot)
@FromIRC
<Araq> Zevv, ok, they are "dirty" but often easier and that's what counts
bevo009
@bevo009
Great book Miran, it's been an excellent refresher
From IRC (bridge bot)
@FromIRC
<narimiran> bevo009 i think it is a valid complaint. maybe there should be a sentence/paragraph/example warning discarded value
<narimiran> *warning about ...
<livcd> narimiran: will you write "Nim advanced" ?
<narimiran> bevo009 thanks! if you find more confusing stuff like this one, please open an issue in the repo, so i can improve it
<narimiran> livcd: i would like to write it at some point, but currently i don't have enough time for it
From IRC (bridge bot)
@FromIRC
<Zevv> Araq: I have some cases in which --expandMacro is not expanding my macros, but I'm not able to figure out what the conditions exactly are - is this a known issue?
From IRC (bridge bot)
@FromIRC
<Araq> Zevv, never heard of it before
<Araq> and it's hard to imagine how it can fail
From IRC (bridge bot)
@FromIRC
<zedeuss> Is there a way to accomplish this? Using a string variable to generate a field access: https://play.nim-lang.org/
Vindaar
@Vindaar
zedeuss: if I understand your intention correctly, then no. The name field of Pref is only filled at runtime, but in order to access a field, the name must be known at compile time. However, you can access object fields in a similar manner from a string. But only if that string is static (i.e. defined at CT). So your pref instance must be defined as a const. Like so: https://play.nim-lang.org/#ix=1Rww
dawkot
@dawkot
Nim not raising exception when "overflowing" range types is a bug, right?
on js
Alexander Ivanov
@alehander42
hmm

got <proc (e: js){.closure.}>
but expected one of:

proc (e: js){.closure.}

doesnt sound right