Same issue for me. March payment was processed but not April's.
I know this is a Bounty Source problem and not a Nim problem, but I thought I
would share here anyway as the Nim community is probably more responsive than
Bounty Source lol.
I set up a Bounty Source account to contribute to Nim monthly, but seems to
have only taken a one time donation.
I
`bitsets` \- I haven't used them but I know I will someday and I wouldn't
remove them. If they can be moved to a nimble package, that's fine with me.
`exceptions` \- I'm 100% behind Araq that "bubble up" is the right default.
Yet, I tend to favor having a Result type (similar to Rust) and
I'm glad @arnetheduck started this thread. I appreciate his minimalist leanings
and the nod to Antoine de Saint-Exupéry.
* `exceptions` Can't live with'em, can't live without'em. I agree that
they're questionable, but like @Araq said there's no obviously better
alternative. I know that in D
@Araq
Yes, I think static[T] should be nnkLitXXX, and typedesc should be nnkLitType
maybe. Every should be NimNode in the macro, but it affect compatibility.
To be able to eat and keep the cake, consider a three-layered architecture:
kernel, modules, distros.
**Nim kernel** Would contain just the core features so that Nim can compile
itself and majority of Rosetta code problems can be solved. Very compact, very
stable, very efficient, very well
Thanks for your comments.
Starting point for these investigations was
[https://github.com/StefanSalewski/nim-chess4/blob/master/engine.nim#L522](https://github.com/StefanSalewski/nim-chess4/blob/master/engine.nim#L522)
it.df.abs == BishopID or it.df.abs == QueenID
I was
I think there are probably a lot more lower hanging fruit than 'do' notation
and coroutines. 'do' notation is super handy. Coroutines is fairly fundamental
for Actor model and generators.
Completing my first answer with tings that came up after:
* `converters` currently are a bit unsafe. They can happily trigger ambiguous
calls when a converter to numeric type exist. I don't mind them going
especially if the int literals stuff is sorted out. Or it would be nice if we
could
sorry, I misunderstood your question.
> Why the t1, t2 cannot be treated as correct typedesc, they all Sym "User"
> just like nT.
echo repr nT.getType() # typeDesc[User]
echo repr t1.getType() # object
echo repr t2.getType() # object
I don't know if this just some
> Excuse me @Udiknedormin, maybe you aren't fluent in English?
This is my last warning. Watch your tone.
Yeah, this behaviour is specified in the manual but I consider it broken too...
`typedesc` and `static[T]` are special as macro parameters and that doesn't
work well. We need to change it.
typedesc seems different from other type in the macro.
macro m1(T: typed): untyped =
echo treeRepr T
macro m2(T: typedesc): untyped =
#echo treeRepr T # compile error
echo repr T.getType
m1(int) # Sym "int"
m2(int) # typeDesc[int]
when you cross macro boundary, not only typedesc transformed into NimNode,
practically all args passed to macros will be transformed into NimNode, no
matter it is an int, string, int literal, string literal, or a block of
code/statements, all will be transformed into NimNode with specific kind.
Because discard expects a single statement but in the line there were several
tokens space-separated.
Apart from that, it's preferable to use it only for single argument function or
other obvious function call.
> So you DID inspect C code differences and also checked another compiler, but
> you still blame Nim, not gcc, for that time difference? Even to the point of
> calling it a security issue?
Excuse me @Udiknedormin, maybe you aren't fluent in English? I have not
_blamed_ Nim or gcc. I have asked
Replying because thread is broken and 3rd page is linked but 404s
@jzakiya
So you DID inspect C code differences and also checked another compiler, but
you still blame Nim, not gcc, for that time difference? Even to the point of
calling it a security issue?
This is a thread that I wanted to create myself in preparation for v1. Thank
you for creating it. For everyone reading this thread: **please let us know
your opinions of what needs to go before v1 is released.**
I'll probably read everyone's answers later, but here is the quick small list
off
19 matches
Mail list logo
