I cannot compile examples/httpserver2.nim with the latest release (0.14.2) on
Windows. I get the following error:
c:nimlibpuresockets.nim(174, 6) Error: ambiguous call; both system.==(x: T, y:
T) and unsigned.==(x: T, y: T) match for: (uint16, uint16)
Is that normal?
> Got it. I will bookmark it in my mail folder, so i can send you the book
> later.
Why that effort? See google or Manning page:
[https://account.manning.com/support](https://account.manning.com/support)
Section shipping:
I need to change my shipping address on a pending order.
Please send a
Wow, that's really nice of you to send the book to somebody else for free!
Sucks that you won't be using it and Nim but I hope you will pop back into
Nim-land every once in a while to see how we're doing, otherwise I hope Haxe
has everything you're looking for.
@didlybom: In C#, we call them IEnumerable which is quite a good name.
Something like enumerable[int] or iterable[int] might make more sense than
openarray does, though it's a fairly substantial change.
Yes, I feared something like that...
I think it was already discussed a while ago but I think this thread shows that
"openarray" is not a very good name. IMHO it really does not convey what it
really means. Something else such as "anyarray" or "arraylike" might be less
accurate but easiert o inderstand (again, IMVHO).
> I just posted you the address, I am from Aachen so yes in Germany.
Got it. I will bookmark it in my mail folder, so i can send you the book later.
If you change adres, do not forget to update. ;)
> But it's said that you've decided for the wrong language
_lol_ ... Each there own. ;)
>
I think I have my answer for my original question already. I will just a
proposal about what I would like to change here in the forums. It then has full
potential to be moved into an official document, whatever form that might be. I
really like the interactive part here, and the forum is not
Sure you can c2nim it. It looks like a week of work though, it's 235 header
files.
Thanks for the casting idea.
I really don't think you should think of boehm as "dirty." I mean, compared to
what?
Real multi-threaded programs need to store structured data in shared memory.
Just to give an example, let's say that this structured data is json. With
boehm, I can load the
Thanks, Araq, I will definitely look into it. This might be the fastest way (in
terms of time needed to create the bindings) to get it working in Nim.
Do you think it is possible to directly wrap the C++ library itself? Or would
that be too much work?
Since seqs and strings have value semantics we can implement them with C++'s
"Small vector optimization" and don't need more complexity in the language (but
in the runtime).
@wulfklaue
Interesting; what's your movtivation to make the move from Nim to Haxe; would
you mind giving details of your decision?
I just posted you the address, I am from Aachen so yes in Germany. But it's
said that you've decided for the wrong language ;)
@AxBen My guess would be that his focus is not on metaprogramming and overhead
free datastructures.
Dear fellow Nim users,
_Disclaimer first:_ I am an organic chemist by training and although I have a
strong interest in computers (using a Linux desktop) and
[programming](https://github.com/apahl) (mainly Python so far), I am by no
means a computer scientist, so please go easy on me.
I am
Well that became offtopic rather quickly...
1. `cstring` used to mean "C string", now it means "compatible string", a
weird backronym and the manual needs an update.
2. Whether my example should produce an error or a warning or nothing is
besides the point. The real question is: What do you
We don't really want to have a Nim dialect per --gc option so the frontend
checking is not aware of `--gc:boehm`. You can `cast` GC safety into existance
though and be as dirty as Boehm allows for.
Sketch:
type EnforcedGcSafe = proc() {.gcsafe.}
proc myproc =
> What do you want for it?
Nothing at all. Think of it as a free gift. I'll ship it for free ( if your in
the EU ). German is cheapest for me :)
Better to give it to another person then me just putting it on the bookshelf
and not using it.
> I would like to have it.
Ok. Send me a mail at
What do you want for it? I would like to have it.
As i decided to focus purely on Haxe instead of Nim, my copy of Nim In Action
book will be useless to me.
So when the physical book is printed and shipped to me in Europe ( 4 months
until it ships ), i can forward it to somebody else. Only EU programmers
because of shipping costs and stuff.
@Krux02 looks nice to me ... why don't you try it? I did that in the past too
for some ideas of me which where supposed to be easy. But then I found out that
stuff seldom is as simple as it seems :(
according to the
[manual](http://forum.nim-lang.org///nim-lang.org/docs/manual.html#types-cstring-type):
> The cstring type represents a pointer to a zero-terminated char array
> compatible to the type char* in Ansi C. Its primary purpose lies in easy
> interfacing with C
There is no
@Krux02 yes there is a (experimental) PHP backend which actually is even used
as fallback in production for [Nim driven Zend
Modules](https://github.com/metatexx/nimzend). @Araq works for our company so
we can experiment more freely :)
Besides that: cstring is a very important part of
flyx wrote:
> And yes, something between array and seq would be nice. But currently, Nim's
> type system does not allow a type with a runtime-calculated length parameter.
> Allowing it would be a hack similar to C VLAs.
No hack involved here. The length parameter can be part of the object like
> Weirdly enough that code runs ~25% faster for me when changing res from
> string to seq[char], 1.51 instead of 1.99. I have no clue why.
@Tarmean: Strange indeed ...
I did try that too, but the performance was the same.
Well, I think we discussed this before, but "c" in `cstring` means "compatible"
not the C language, and it's a magic type which may be different in different
backend instead of unchecked ptr to array of char.
cstring* {.magic: Cstring.} ## built-in cstring (*compatible string*)
cblake: C11 made VLAs an optional feature though. I consider C VLAs a very poor
solution; as you say, it's mostly syntactic sugar for alloca.
And yes, something between array and seq would be nice. But currently, Nim's
type system does not allow a type with a runtime-calculated length
I've compiled with --gc:boehm because I want to be able to share data
structures between threads.
Despite this, I'm still getting this error from my .thread. proc: procedure is
not GC-safe. As I understand it, this is the compiler trying to enforce
separate heaps. This surprises me: I assumed
Don't forget that there are other backends like javascript and PHP which are
using cstring as the "native string type". This needs to be decoupled from the
"c-wrapper" meaning of cstring. I think there may be monsters...
@flyx - c99 (and gcc long before it) have VLAs of the
fixed-after-initialization variety...mostly syntactic sugar for alloca, of
course. All that is surely more commonly used than Ada and required no fancy
containers or any constraints about being a leaf function. Such an array style
may be
Just a quick idea: if you don't understand what happens under the hood, then
you can peek at nimcache/*.c (or even better, you can diff two versions).
> Peter
wiffel
Weirdly enough that code runs ~25% faster for me when changing res from string
to seq[char], 1.51 instead of 1.99. I have no clue why.
That's exactly where I think the problem is. cstring should be explicitly an
unsafe type, and users who use it should know about how it behaves. It's a type
that is just for wrappers, where you have to deal with unmanaged pointers
anyway.
And no matter how you treat the cstring, it will be an
Well, addr and ptr are explicitely unsafe. cstring isn't and will still be
invalidated once x goes out of scope. Ideally it would require you to make a
deep copy of the cstring somewhere or explicitely shallow copy, I guess?
35 matches
Mail list logo
