there are many (recent!) x86 and ARM processors that do not support true
non-rounded FMAs, e.g. the Celerons. implicitly setting `-march=mative` would
also inherently makes many nim programs non-portable by design which is an
assumption we really do not want to make. the libc impl does implicitl
nim is not lisp, that it has a more complicated grammar beyond sexps means
ultimately that there are AST substitutions you cannot do in `quote do`. this
is why when building macros you should always keep `astGenRepr` close by in
case you do have to get dirtier.
as your concern is with readabili
in fairness to OP it can be often vague where "official support" begins and
ends in the compiler. if you don't want people using TCC as the backend then it
should be deprecated, otherwise it will be just assumed as a feature, esp.
without any experimental flags blocking usage
> There I only can surrender.
codegen on other compilers for atomic compare-and-swap uses the compiler
intrinsic directly. TCC being so barebones as it is uses x86 inline asm in
absence of compiler builtins.
seems like the impl was borrowed [from
here.](https://stackoverflow.com/q/833122)
ARM
> It would be nice to be able to at least disable default constructors. We have
> various hooks now, so it seems it'd be a natural extension from there.
> There's just some cases when a default object constructor needs to be
> disabled or overridden.
what about `{.requiresInit.}`?
what even is the difference in functionality between `enumerate` and the
`pairs` iterator?
Use the compiler flag `--rangeChecks:on`
Interesting work! I feel getting JITs work in Nim would dovetail quite nicely
with NimScript (especially in the context of embedding Nim plugins to user
applications). However, [I thought NLVM also had support for
ORCv2?](https://github.com/arnetheduck/nlvm/blob/master/nlvm/lljit.nim)
`std / tables` pulls in `std / hashes`: the reason `seq[string]` works out of
the box is because that there is a [hash function for a generic
`seq[T]`](https://nim-lang.org/docs/hashes.html#hash%2CopenArray%5BA%5D%2Cint%2Cint),
which in return calls the `hash()` function over each of its element
approximately, `NimMain`:
* pulls in command line arguments
* links to all `{.dynlib.}` procedures
* if needed, starts TLS emulation
* if needed, start the GC
* if needed, registers all nim-side procedures and globals with the HCR
(hot-code reloader)
* initalizes the nim-side callstac
unrelated but the time limit on being able to edit anything is kinda silly -
would have preferred to be more concise.
> However, a senior programming educator and a former engineer told me that
> such a language is impossible due to the "Church-Turing thesis".
In all honesty, this is a bad and unrelated answer (and kind of a cop-out). Nim
is not trying to question conundrums of computability, Nim is questioning
I assume a reference to [this](https://forum.nim-lang.org/t/10135#66993)
entirely unrelated. it's specifically for extending procedures from a base type
to a distinct type
> If you have background in programming with Scala, could you please explain
> how does a macro in Scala and Nim differ AND why aren't they more popular in
> Scala?
I suspect it may be because the language is in a "Python 2 -> 3" bifurcation
moment.
It has been a long time since I've personall
you can borrow like so:
type Foo = distinct int
proc `$`(x: Foo): string {.borrow.}
echo (Foo 1)
Run
also, instead of borrowing, you can use `distinctBase` for weird type-general
nonsense:
import std / typetraits
type
Foo = dis
one of the things that is also less fortunate about this example is that there
is a latent yet untaken opportunity for DCO to turn `reverse` into a noop the
way it's used in the loop.
there once was a point where it was easier to have momentum on stuff like this,
in spite of w/e significance it has and whatever degree of relation it has to
the "bigger picture" of the language as a whole, primarily because there were
fewer affected parties using the language in general. this i
* the header is unnecessary if you have the binary definitions, which is that
`MTLDevice` is a `ptr object` and that `MTLCreateSystemDefaultDevice()` is of
calling convention `cdecl`
* you need to also link in `-framework Metal` and `-lobjc`. if you want to use
the header you need to pass the fr
i am not really sure that i am a fan of adding `init` and `new` as it would
give the false impression of how constructing objects works in Nim.
an alternative convention: `init` and `new` in this case do not refer to
copying semantics but whether or not the object is heap-backed.
Reminds me of the [type union operator from
Pike.](https://pike.lysator.liu.se/docs/man/chapter_3.html#3.3.3)
Very glad to do a `choosenim update stable` today!
nim can technically "compile to Obj-C" and produce loose method calls through
`{.importObjc.}`, [found here in the
docs](https://nim-lang.org/0.20.0/manual.html#implementation-specific-pragmas-importobjc-pragma).
however this interface is pretty much one-way: e.g. you can't subclass in pure
nim
[here you
go.](https://developer.apple.com/documentation/appkit/nswindow/1419690-setframeorigin?language=objc)
you may prefer using a cross-platform windowing library instead, e.g.
[SDL2](https://github.com/nim-lang/sdl2) or
[windy](https://github.com/treeform/windy)
make sure there are no captures in the call - in your case `image` is
implicitly captured. instead you would want to pass it as a `var Image`. also
the return type should be void as you are not actually returning an `Image`
from that procedure.
also from a cursory glance this may fail because `proc` is probably being
considered as a typeclass here instead of as a concrete procedure type in the
context of `assign()`
firstly, you probably want `for j in 0..https://github.com/Araq/malebolgia/blob/master/src/malebolgia.nim#L168).
this works for `seq[T]` elements because `[]` returns a `var T` [in the
stdlib](https://github.com/nim-lang/Nim/blob/version-1-6/lib/system.nim#L2644)
whereas pixie defines a `[]=` (a
> Nim won't allow to use addr and suggest to use unsafe_addr instead, why?
`unsafeAddr` is on its way out for 2.0 iirc but, moving beyond reorienting
around arrays: parameters are constant in Nim (unless you use something like
`var`) through which whether a copy or an implicit ref is passed beco
why not just use `newSeq[float32](largeNumber)`? just remember not to push or
pop anything (which won't happen if the array is piped into a `let` or `const`
anyway). it's not entirely 100% clean, like you get an unused negible
`capacity` value, etc. but for all intents and purposes it is probabl
when it comes to intermingling managed code in which multiple memory management
schemes have no actual knowledge of each other, you need to use the language's
built-in utilities to preclude object destruction. C#, for instance, has
[`unsafe`
contexts](https://learn.microsoft.com/en-us/dotnet/cs
imo Win32/NT is for the most part more sensibly designed than UNIX (and even
then, MacOS tries to hide its UNIX heritage very frequently, aside from the
most basic OS bookkeeping substrata)
in any case it matters little because (being a cross-platform language, as most
languages tend to be) Nim
I agree (Nim has the habit of being a little Windows-centric) - perhaps [submit
a PR](https://github.com/nim-lang/Nim/blob/devel/doc/nimc.md#dll-generation)?
Try compiling with `--app:gui`. If you have DLL errors it will show up as a
dialog box instead of popping in an command line which might vanish very fast
if you launch from explorer.
I took a look at your deps and I would concur with @Yardanico, however, looking
at the deps for `dimscord`, I wo
FWIW I've been using static ranged dimensions for a while in my own (short, 2-4
dimensions) vectors + matrixes plus distinct types for unit vectors, colors,
etc. and I really find it quite easy to deal with. (Though my context is
graphics/game engineering, not ML/numeric processing, so my commen
OP, have you tried this? This seems to work.
type
Foo[T] = object
x:T
Bar[T,R] = Foo[T]
Baz = Bar[int,float]
proc qux(x: Bar) = discard
var b:Baz
b.qux()
Run
@Yadarnico have you tried MSVC's PGO at all w/ the Nim compiler (or are you not
on Windows?)
> What are the use cases?
There are four main things I can think of:
* Parsing trees with mixed semantically-valid and DSL code (e.g. the prior
example)
* Including generated code from a cache that must be programmatically
retrieved (such as Nimterop/Futhark etc.) with better semantic analy
To be more specific with what I mean: the semcheck pass performed with `typed`
only works with code blocks produced directly from the source. There is no
`proc typify(node: NimNode): NimNode`. If an AST is produced either from the
compile time VM or (probably more usefully) if there are specific
Have you tried using the compiletime FFI too?
In Nim, macros and templates have the ability to be designate their params as
being `typed` or `untyped` which enables a user to optionally pass their input
to the semantic stage (and produce symbol-bounded, constant-folded, etc. AST
trees as a result), or avoid the semcheck if a less “Standard
if for some reason you do need this array at compile time, there is really no
necessity for using generic params, just use `const`.
TBH I'd be in favor of forking this off and starting a new thread (or GH issue)
focusing on stdlib issues versus language/compiler-level/package managment
issues; especially RE: breaking some of the existing libraries off into
`fusion`.
* more willingness to breaking changes in the stdlib, for sure, as others
have said, and hunt down inconsistencies/reduce the number of "alternate
approaches" that exist. consider moving certain libraries over to fusion and
take fusion more seriously. for instance, just off the top of my head:
This also makes it easier for Nimble to comprehend a package's dependencies.
That being said, Nim already supports some interesting ways of establishing
dependencies through Nim code itself (albeit from a different angle - Nimterop
comes to mind).
Personally, I don't see much of an advantage to
> Do you use other things for benchmarking ?
Try [cpuTime()](https://nim-lang.org/docs/times.html#cpuTime) or
[monotimes](https://nim-lang.org/docs/monotimes.html).
Actually, silly me: you can define `wWinMain()` without needing `windows.h`
like this:
int __stdcall wWinMain(void* w, void* x, void* y, int z) {}
Run
On the point of removing `windows.h` from the Nim compiler/standard lib:
> GetLastError is declared in lib/system/excpt.nim and
> lib/system/threadlocalstorage.nim. These APIs should be moved to winlean
> module?
I would avoid doing this. `winlean` is still pretty large (considering it is a
tr
`int.low` is an inferior method, as it becomes a magic value unlike the option
which forces you to check. However options as they currently are strike me as
limited in the optimization department because internally an `Option[int]` will
be represented as a `(has: bool; value: int)` in memory whe
If you feel awkward coming to Nim after getting so used to braced languages,
believe me, after a while you will get used to it and maybe end up preferring
it in the end.
Discussions about syntax can be important (to provide an extremely arbitrary
example: Nim doesn't "cheapen" the syntax at the
We already generally avoid `{.include.}` for Win32 API stuff, as `winlean`
mirrors the API (basically a translation of `windows.h` w/
`WIN32_LEAN_AND_MEAN` def'd) in general but pulls the necessary functions in
through `{.dynlib.}` instead of through the C header.
There are a few places where w
My repo can be found at <https://github.com/awr1/aoc>
51 matches
Mail list logo
