Yes we still do, the implementation is currently integrated with `net.Socket`.
You can open an issue on GitHub requesting a pluggable mechanism and I might
look into it. It's not really that hard to replace the current system with a
pluggable one, but there aren't enough interest to go for it
You can just not export `options`. The `body` passed in will get access to
template-declared functions/macros/templates by default.
I think you'll be interested in this:
[https://nim-lang.org/docs/destructors.html](https://nim-lang.org/docs/destructors.html)
> Maybe manually allocated strings like this can only be achieved using
> `UncheckedArray[char]`?
It depends on your use case. `newString()` also supports taking a length if all
you want is to create a pre-allocated buffer.
> Is there any way to convert a seq to vararg?
Array types can be implicitly converted to `varargs`:
[https://play.nim-lang.org/#ix=2ilk](https://play.nim-lang.org/#ix=2ilk)
In fact, `varargs` is a syntactic sugar for `openArray` :)
> A `varargs` parameter is an `openarray` parameter that
`--os:standalone` has been deprecated I think, the replacement is now
`--os:any`:
[https://nim-lang.org/docs/nimc.html#nim-for-embedded-systems](https://nim-lang.org/docs/nimc.html#nim-for-embedded-systems)
> So is there a way to detect that an error happened at compiler parsing phase
> and catch it?
You have [compiles()](https://nim-lang.org/docs/system.html#compiles%2Cuntyped)
for that. Though usually we never write tests like this...
> I would love to have a nim switch that will generate platform specific linker
> options to load dynlibs from binary's location, like on Windows. This could
> be considered as default behavior for nim programs.
Depends on who you ask, using this as the default behavior have possible
security
> receiving input from a socket requires a runForever()
`runForever()` is just an infinite while loop running `poll()`. Just make sure
to run `poll()` along your GUI event loop and you should be fine :)
You might find this interesting:
[https://github.com/nim-lang/Nim/pull/12105](https://github.com/nim-lang/Nim/pull/12105)
> This is because we removed dead code elimination from the openssl wrapper,
> why did we do this?
Unrelated, it's due to this:
[https://github.com/nim-lang/Nim/pull/6664](https://github.com/nim-lang/Nim/pull/6664).
This feature requires OpenSSL 1.1 and above. You can pass
This looks awesome.
I found a small issue while skiming the book: The example
[here](http://ssalewski.de/nimprogramming.html#_input_and_output) don't need
`import streams`, as `readLine` for `File` is in `io` and that one is imported
by default.
That's not possible in Nim, instead just import the second file to get the
object definition.
> Is there any way I can leverage multiple cores of the target system to
> maximize efficiency?
Yes, but efficiency can't be guaranteed. The workload must be sufficiently
large for the cores to most all of their time processing it, or else the
bottleneck will fall into the creation and
You de-reference the `ref`, like this:
proc foo(i: var int) = discard
let a = new int
foo(a[])
#^~ dereference operator
Run
Looks like what you found was a bug in ARC :)
[https://github.com/nim-lang/Nim/commit/8705ee7015382ac2957733dfef5e02a0831e7fb4](https://github.com/nim-lang/Nim/commit/8705ee7015382ac2957733dfef5e02a0831e7fb4)
If you do an explicit move, the variable will be cleared, so it can be reused.
The segfault is an indicator of a different problem.
Well it said `-d:danger` (in case you don't know, it disables all runtime
checks). Also you won't be able to find types like these in C, because they
just don't exist. Nim instead implements these via checked conversions IIRC.
The compiler enforces code paths to not have `nil``s (ie. forcing ``ref` to be
initialized). In the case where you use an FFI API that might return `nil`, you
have to add the checks in yourself, and the compiler will do analysis to
determine if it's enough.
Currently Nim has `not nil`
According to the
[documentation](https://nim-lang.org/docs/times.html#parsing-and-formatting-dates):
> Other strings can be inserted by putting them in `''`. For example `hh'->'mm`
> will give `01->56`. The following characters can be inserted without quoting
> them: `:` `-` `(` `)` `/` `[`
> So the ownership model has been changed again? What is the replacement?
`--gc:arc`:
[https://forum.nim-lang.org/t/5734](https://forum.nim-lang.org/t/5734)
And here's the official docs on destructors:
> to be more common, what if there are many 0 in a C string, how can we deal
> the information correctly in nim?
Hope this helps:
[https://play.nim-lang.org/#ix=2d9d](https://play.nim-lang.org/#ix=2d9d)
Here you go:
[https://play.nim-lang.org/#ix=2d96](https://play.nim-lang.org/#ix=2d96)
As I don't use Windows, I can't verify the code and have only written it based
on documentations lying around.
Please note that the string that `GetLogicalDriveStringsW` returns is a wide
string, not a C
proc main() =
var a = create(int)
echo a[]
a[] = 10
echo a[]
dealloc(a)
a = nil
main()
Run
We also have the `create` template in the stdlib that's super easy to use, and
cuts all the clutter.
We also have a working port that passes all the test here:
[https://github.com/clyybber/nimryu](https://github.com/clyybber/nimryu)
Since both `re` and `nre` made it to version 1 of Nim, you can be certain that
they will be around for as long as there are interest in maintaining the 1.x
series :) That's the stability commitment of Nim v1.
lent/sink is no longer a valid type for variables under the revised destructors
scheme. And no, it won't help you with multi-threading either.
The simplest way to go is `--gc:boehm` and a global `TableRef`, assuming that
read-only access is the only thing you want. The reason behind using
I think it's headed for the 1.1 release. Patch releases never get new features.
FWIW, this is how nim docs are generated:
https://github.com/nim-lang/Nim/blob/devel/tools/kochdocs.nim#L363
Please note that Nim identifiers cannot start with an underscore, except for
the special identifier `_`.
Have you checked out the "Nim basics" book, linked in our "Learn" page?
[https://nim-lang.org/learn.html](https://nim-lang.org/learn.html). IMO it
focuses on a lot of basic concepts.
But if you really want to start learning "native" programming then I will
recommend learning some of the more
> That was a good post, it's just unclear to me what the concrete changes will
> look like for writing everyday code.
It'll look like this:
Yes, nothing will change for writing everyday code, that's a goal of ARC, as
the replacement default GC. What ARC will bring are extra features that
A [demo](https://asciinema.org/a/276278) on debugging in neovim:
\--
I made this a long time ago, but forgot to share it on the forums.
Nowadays, with vim 8 & neovim's `packages` feature (see `:h packages`) it has
never been easier to maintain a full setup that you can just clone from your
git and got everything working right after :)
> For some reason, I couldn't get vim embedded instructions to do the tabs
> properly. I
> At present I can get cligen things (like that example bench above) to compile
> and run ok, but with gc:arc invoking with --help raises a HelpOnly exception
> that then dumps core. Current runtime seems to think the exception is
> unhandled. (Haven't looked into it further.)
`zf` is for creating fold :) To close one you use `zc`. See `:h fold-commands`
for further folding magic.
As a shameless plug, but I made one of the most featureful Nim plugin for
neovim :) Check it out at
[https://github.com/alaviss/nim.nvim](https://github.com/alaviss/nim.nvim)
Here you go:
[https://play.nim-lang.org/#ix=26DP](https://play.nim-lang.org/#ix=26DP), just
one extra line and your code works.
The way this work is that templates are a way to insert premade AST into a
specified location, which means:
template cmpTaskField*(fieldName: untyped):
Apparently your file managed to cause extreme slowdown for `nimsuggest`. While
using editors with `nimlsp` or my `nim.nvim` plugin won't cause any lag due to
asynchronous communications, the time it took for `nimsuggest` to return the
results is extremely long.
It took about 8-9 seconds on my
> There are truly readonly data in the physical world, such as ROM. If a value
> of type `T` is stored in ROM, what's the type of ``? It's `const T *`. How
> to model this in Nim?
Just use `T`. If the data cannot be modified, then indicate so in the
parameters by not having `var` there. Nim
No, the memory will be released to the OS.
The GC does release memory under certain
[circumstances](https://github.com/nim-lang/Nim/blob/b07694cd90ab7c6eb4660971ddb818b461d4eed8/lib/system/alloc.nim#L861).
The code is rather hard to follow though, and I'm not sure _when_ exactly
would the GC release memory back to OS. But if you
You'll have to deal with them for now, as the Nim ecosystem is not that big
yet. It's not too hard to provide abstractions for cstrings, as Nim's string
can be converted implicitly to them.
If you're on Linux, `gdk-pixbuf` is a viable choice (bindings provided by
gintro package). Here's a CLI
You might also wants to do this the [Nim
way](https://nim-lang.org/docs/manual.html#procedures-properties)
proc age(a: Human): int = a.age
proc `age=`(a: var Human, age: int) =
a.age = age
Frank.age = 99 # or `age=`(Frank, 99)
echo Frank.age # or
The `unittest` module is not deprecated, at least not anytime soon. The amount
of projects using it is huge, and there aren't many reasons to remove it afaik.
The Nim compiler itself is a project that's using testament.
However, if you're just making a toy project, the `unittest` module should be
suffice.
> Thanks a lot. I was trying to write macro that generates: enum type and
> procedure to map value of this enum to related string.
It's... a native feature of Nim:
[https://nim-lang.org/docs/manual.html#types-enumeration-types](https://nim-lang.org/docs/manual.html#types-enumeration-types)
This is definitely not how you write a macro :P You should take a look at the
[Macro tutorial](https://nim-lang.org/docs/tut3.html) for a hands-on experience
with macros.
More learning resources can be found at the [learning
portal](https://nim-lang.org/learn.html).
Here you go, requires nim version 1.0:
[https://play.nim-lang.org/#ix=1Yu9](https://play.nim-lang.org/#ix=1Yu9)
With the new destructors system, the compiler can seamlessly convert
destructors to finalizer.
> Compile with `--gc:destructors` switch.
It appears that you're not using a custom GC like
[araqsgc](https://github.com/Araq/araqsgc), so why does this package requires
`--gc:destructors`?
There's also NESM, which provides easy to use DSLs for serializing and
deserializing objects in binary form.
[https://gitlab.com/xomachine/NESM](https://gitlab.com/xomachine/NESM)
I think you should remove this account. I've had a quick look at their post
history and it seems to be clones of various posts on this forum.
This is a clone of @miran post:
[https://forum.nim-lang.org/t/3917#24412](https://forum.nim-lang.org/t/3917#24412)
This might be a kind of spam.
Yes
[https://rosettacode.org/wiki/Nim_Game#Nim](https://rosettacode.org/wiki/Nim_Game#Nim)
Hmm, @Araq should have already fixed this. Can you test this with Nim 1.0 and
raise an issue on github should there still be errors?
Quick fix:
import cirruParser / types as cpTypes
Run
This is because the actual module name is `types`, not `cirruParser/types`, so
it will conflict when you import yet another `types` elsewhere. In such case,
the `import as` statement becomes handy.
This error means that `libgcc` wasn't linked in by the compiler. Make sure that
the "linker" is set to your cross-compiling gcc instead of `ld`. Also, can you
elaborate more on how you setup your system?
I think what he meant is that there might be issues with your setup as Nim
apparantly works fine on MIPS.
It could be a bug in `bigints`. My stacktrace was:
test.nim(24)test
nim/pure/collections/sequtils.nim(727) product
nimble/pkgs/bigints-0.4.3/bigints.nim(395) multiplication
Run
Have fun
const ∞ = high(BiggestInt)
echo ∞
Run
>From what I understood, the `E` inside the pragma is not instantiated. Not
>sure if it's a bug or intentional design.
For now just drop the `{.raises.}` annotation, the compiler can compute this on
its own.
Try this:
proc returnZero(T: typedesc = typedesc[float64]): T = T(0)
discard returnZero(int)
discard returnZero()
Run
Although you might want to use `system.default[T]()` instead
While the `B` object inherited most of `A`, they don't have the same size, so
you can't store them in the same array/seq.
What you might want to do, is to use `ref object`, which is a pointer so they
can be placed on the same array/ref
type
A = ref object of RootRef
The `db_sqlite.DbConn | db_mysql.DbConn` syntax creates a typeclass, which is a
kind of generics that resolves at **compile-time**.
Instead, use a variant object to create a type that stores either `DbConn`:
import db_sqlite, db_mysql
type
DbType = enum
yea, but you can just map Ctrl-S to save if you save so much.
Typically vim keeps swap files and save the file state there periodically, so
you don't have to keep saving the file as you type. If the editor crashes, you
can re-open the file and the editor will ask to restore it.
The power of
neovim with my own [nim.nvim](https://github.com/alaviss/nim.nvim).
Feature-wise, it should be on par with the VSCode plugin.
> Specifically for structuring data, I have one advice: you use tuples instead
> of objects whenever you don't need the extra features that objects provide.
I'm against this advice. A `tuple` should be used when you need its feature
(ie. tuple unpacking, array-like accessing syntax, etc.).
Remove `{.discardable.}`. Don't use that pragma if you don't understand how Nim
works.
> When trying to compile without {.Discardable.} I get an error - van2.nim(49,
> 24) Error: expression 'splitstring(new_string, split_by, accu)' is of type
> 'seq[string ]' and has to be discarded; start of
You're missing the important part in that example:
let outp =
Run
The way you're doing it is correct, but `execProcess` returns a `TaintedString`
Here you go:
[https://play.nim-lang.org/#ix=1OyF](https://play.nim-lang.org/#ix=1OyF)
You mean something like this?
[https://play.nim-lang.org/#ix=1Oki](https://play.nim-lang.org/#ix=1Oki)
Macros can only create ASTs, they can't modify them. It'd be really dangerous
if it could, since you wouldn't know where the macro executes.
> So my question is this: If my understanding is correct, then why should I
> invest in Nim when I won't have the advantage of the GC and instead I could
> use another language with the same memory-management mechanism as Nim but
> with a huge community behind it, backed by Mozilla?
Nim's new
Typically when interfacing with C I'd recommend using `c*` types, in this case
`culong`. Nim and C have different integer sizing rules, so using `uint` may
not be correct for all architectures.
@cantanima @avandy Have you tried the
[contracts](https://github.com/Udiknedormin/NimContracts) module?
The way I shown just avoids the import/export pair :p If you have more advanced
needs (ie. import all module in a folder), then some macro magic can be used.
Make a nim file of your choice (`testPackage/prelude.nim`), with the following
content
import testPackage / [submodule1, submodule2, submodule3]
Run
Then just `include testPackage/prelude` and all of your imports should be there.
This approach is used by Karax.
Typeclasses in Nim is only used for generics, meaning that they're a
compile-time constraint, not a runtime one. You'd need an object variant for
this case.
Yea, that part is rather misleading, but it's due to how `docopt` [convert that
to
string](https://github.com/docopt/docopt.nim/blob/65da8739a7534b8d78249a90778e1b38d4bdcf5c/src/docopt/value.nim#L82).
Looks the the correct way to check for that is:
if args["--wid"].kind == vkNone
You've successfully broke the compiler :) Can you file a bug report on github
for this? Preferably with a code snippet that could reproduce the problem.
@Stefan_Salewski From the stacktrace it appears that this is a compiler bug,
not a bug with the user's code.
template corsResp(code, message: untyped): untyped =
mixin resp
resp code, {"Access-Control-Allow-Origin": "*"}, message
Run
Some templating magic for this, haven't tested though.
It's a 1-1 bindings of sdl2, except without the `SDL_` prefix. You can use
SDL2's documentation to write apps with it.
I think it's omitted due to the fact that @Araq finished the re-design of
destructors right before 0.20, so we should wait until 0.21 for that :)
> But I wonder then, aren't enums supposed to be helpful also for working with
> bit flags? so you can AND and OR together when handling settings parameters?
> In this case you can't avoid leaving holes in the enumeration. From what I
> understood from reading the documentation (and I might be
Update this file:
[https://github.com/alpinelinux/aports/blob/master/testing/nim/APKBUILD](https://github.com/alpinelinux/aports/blob/master/testing/nim/APKBUILD)
I've merged the `indentexp` branch, which should now brings a better indenting
experience for everyone. Please [file an
issue](https://github.com/alaviss/nim.nvim/issues) for any undesired indents
that this change might have caused.
You can ignore `{.locks.}` pragma. It's only important when you use the `locks`
module and/or the [guard
system](https://nim-lang.github.io/Nim/manual_experimental.html#guards-and-locks).
It's one of the most misleading thing in the error message, where it bears
zero significance.
Same as
> Thanks everyone, I thought it would be better to write some tests and make
> sure it’s at least a little bit stable before submitting to Nimble - is that
> wrong?
You can give it a nimble structure without submitting to nimble (basically
don't do `nimble publish`). That would allow
`cast` is a re-interpretation of the underlying data as an another type, which
is why you can't cast a pointer to a `seq` and expect that it'd work.
However, instead of converting, you can use a seq like this:
var utf16buf = newSeq[uint16]()
addr utf16buf[0] # <-- this is
Testers needed for new feature: NEP-1-like indentation, and some small auto
indenting improvements.
Small demo of how this acts:
[https://asciinema.org/a/RXbwCTJXGRKEhMRiHIUEoDGd7](https://asciinema.org/a/RXbwCTJXGRKEhMRiHIUEoDGd7)
The code currently resides in `indentexp` branch on
Looks like this is a Nim bug. Normally you are not allowed to put an object
variant into a `const`. The compiler will error out if you do so. Apparantly
using an array somehow bypassed this check.
I think you should open an issue on
[nim-lang/Nim](https://github.com/nim-lang/Nim) for this.
Can you try invoking the compiler like this instead?
nim --cc:clang
--clang.exe:/home/hdias/tmp/android-ndk-r19c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android24-clang
Looks like you haven't set the cross compiler to the correct architecture. The
error is the architecture Nim targets is different from what the underlying C
compiler targets.
Passing the correct compiler via the switch
`--gcc.exe:/path/to/C/cross/compiler` and
I've spent sometime making the `lexbase` version:
[https://gist.github.com/alaviss/83a48f0344d55efbebcca3bce35e4157](https://gist.github.com/alaviss/83a48f0344d55efbebcca3bce35e4157)
This beast has ~310 LoC, so it's just ~100 LoC more than your `re` version :)
After writing mine, I noted a few
Great work!
Personally I think you should build one using `lexbase` instead of `re` as `re`
seems to be too big just for this (the C version is written in plain C without
`re`).
Actually if I could find sometime I'd try to build a `lexbase` version as it
seemed fun :)
Its purpose is to facilitate manual memory management, and there are plenty of
`proc` to manage them in the
[stdlib](http://nim-lang.github.io/Nim/system#create%2Ctypedesc).
You can also create a `ptr` pointing to a variable with the `addr` operator.
> As for the editor: I - and certainly not just me - want, need, must have a
> "basic tool set" that works on all supported systems and the editor, a
> critical component of that tool set, should be relatively small and have
> modest dependencies.
May I suggest neovim with:
*
Fixed :)
You might be interested in [nimpy](https://github.com/yglukhov/nimpy)
1 - 100 of 103 matches
Mail list logo
