Strange ambiguous call error

Well, that's the nature of function overloading. It's not normally an issue because the problem only applies to procedures with the exact same name that relies on int literals not having a concrete type. It's a very small scenario, and personally I don't think I've ever come across loading a lib

Strange ambiguous call error

> And @Stefan_Salewski, not quite sure what you don't like about it. Because you did not really explained it. You started the paragraph with "Because 56 is an undetermined int literal," which is already a questionable statement. At least I have seen better explanations of you in the past. :-) W

nlvm updated

How much work do you think it would be to support Windows? I'm willing to help out, a little.

jsFetch fetch

Solved. I think, that is it bug in js compiler. `result.headers` is null. I I add `result.headers = headers`, its work. proc ajaxOptions(metoda: HttpMethod = HttpGet): FetchOptions = let headers = newHeaders() headers.add("key", "value") result = newFe

nlvm updated

AFAIK this other LLVM JIT supports windows so it seems quite straightforward:

nlvm updated

Forgot one more thing: there's a small runtime to implement here: \- it "mostly" covers the things that are implemented with C macros, and fills in some platform-specific magic that Nim usually gets from the C library - more or less the

nlvm updated

There would be two stages for getting things to work - the first stage is to get nlvm itself to compile on windows - this should be trivial - it's a matter of fixing the build scripts to download the windows libraries of llvm instead of ubuntu, then make some trivial adjustments to the linking p

jsFetch fetch

Looks to me like an unintentional omission in `std/jsfetch`: func newfetchOptions*(metod: HttpMethod; body: cstring; mode: FetchModes; credentials: FetchCredentials; cache: FetchCaches; referrerPolicy: FetchReferrerPolicies; keepalive: bool; redirect = frFollow; refer

=destroy for files and sockets

The underlying issue IMHO is whether or not we accept that =destroy hook can raise. Currently, I've had cases where letting it happen made code harder to debug because =destroy can be called in the finally clause of a try block overriding (and thus hiding the first raised exception). In C++, i

=destroy for files and sockets

Just make `=destroy` to call `close` if it were not called. Those who are debugging sockets can `close` it manually, in which case `=destroy` raises no exception.

Fidgets: widgets using Fidget

> What about a fully qualified name -> screen_name.widget_name (and shortcuts > when the widget is in the same screen) Not sure that you'd work too well given that the fully qualified names are based on the Node tree path. You need that because the name given in the code isn't unique and there