I always like to hear about why people pick Nim!
> Many years ago I was tasked with looking after a database for a particle
> physics experiment.
That's awesome! May I ask which experiment that was? Just curious, because I'm
currently doing my PhD in Physics. The majority of my group actually w
e some existing analysis framework.
There was some code written by my predecessor, but that was all ROOT and
MarlinTPC. Threw it all away and started from scratch. Code is here:
[https://github.com/Vindaar/TimepixAnalysis](https://github.com/Vindaar/TimepixAnalysis)
It's one big mono reposi
The issue is that you only define l in g when it is called with type B. In the
let sk line however you call f with type C, which calls g with the same type.
Thus, the when branch isn't part of the g proc for that case. So l is never
defined.
Is that clear?
use
[nimhdf5](https://github.com/vindaar/nimhdf5).
At least HDFView can easily read NetCDF4 files. So it should be no problem to
read data from a .nc file using nimhdf5. Writing them and staying compatible
with NetCDF might be more of a problem however. I don't know what the standard
contains and
I wasn't sure whether you actually fixed your code with that post now, but I
was already looking at your code when I saw the post, so I continued.
I fixed the code differently, by just removing the c types you used. I trust
that the test case works, because I'm not sure if I broke something. :)
y, since I quickly had
to hack together an online event display. But it only supports linux, same as
the old fsmonitor.
[https://github.com/Vindaar/fsmonitor2](https://github.com/Vindaar/fsmonitor2)
However, looking at the File System Event API for OSX, adding support doesn't
seem all t
I'll check it on my kindle tonight.
Ping me on gitter if you don't hear from me until tomorrow.
The compiler complains to you, because the you assign the cleanXmi call to
newNode.
Thus cleanXmi has to return a type.
Up to right now I didn't even know of grib2 files. I need to read up on what
kind of file format that is first. I suppose it's based on HDF5 files, too? If
it is, I should think we should be able to make it work.
Regarding other nimhdf5 users: I'd love to be corrected, but as far as I'm
aware I
@mikebelanger: Oh, I thought you were sure grib2 was based on HDF5, since you
asked about it in reference to the nimhdf5 repo.
If it's a completely different file type then of course loading those files
with the library does not work. In that case either wrap a specific library for
grib2 files:
While I'm not sure what kind of features the times -> j syntax should allow (or
if times and -> are fixed), the simplest implementation for the second usage I
can come up with:
import macros, strutils, os
macro theMagicWord(statments: untyped): untyped =
result = stat
If you want a working version of your port, here you go:
import
system, os, locks, tables, lists
var
L: Lock
data = 0
threadAdata = 0
threadBdata = 0
# make it a sequence if you want to have an arbitrary number
threadlist: seq[Thread
If I understand you correctly, here you go:
import macros
type
Foo = enum
foo = "Foo"
bar = "Bar"
more = "More"
macro enumFields(n: typed): untyped =
let impl = getType(n)
expectKind impl[1], nnkEnumTy
result = nnkBrac
jupyter notebooks anyways. And
given the quick compile times I don't feel the need. I rather like to go the
literate programming path, like e.g. here:
[https://github.com/Vindaar/TimepixAnalysis/tree/refactorRawManipulation/Doc/other](https://github.com/Vindaar/TimepixAnalysis/tree/refactorRawManipulation/Doc/other)
May I ask what the main features are you'd require the ecosystem to provide for
you to consider Nim?
I'm asking since everyone's use cases are different and in my opinion it's
important to know what people actually want and need.
For instance for [ggplotnim](https:
The answer is simply: writeFile sure can write those and it shouldn't break it.
I do essentially the same here, the only difference is where the image comes
from:
[https://github.com/brentp/nim-plotly/blob/master/src/plotly/image_retrieve.nim#L119](https://github.com/brentp/nim-plotly/blob/maste
I just opened an issue on the awesome-nim repo about adding a few more
collaborators, so that PRs can be merged more quickly.
[https://github.com/VPashkov/awesome-nim/issues/65](https://github.com/VPashkov/awesome-nim/issues/65)
> For JSON to() macro we have
>
> > Heterogeneous arrays are not supported.
>
> I have never seen that term in Nim world before ???
That just refers to the fact that in JSON you can of course have a
heterogeneous array, like:
let heterogeneous = %* [1, 2.5, "Hello"]
You're right that there's a couple of examples where the indentation of
nim-mode is all over the place and this is one of them. I've been meaning to
take a look at this too, but lack of time and not being that experienced with
elisp means I haven't done so.
Something like this is another:
So originally I wanted to write a up a nice example to do the replacements via
the scanf macro:
[https://nim-lang.github.io/Nim/strscans.html](https://nim-lang.github.io/Nim/strscans.html)
by defining tuples of strings to match against and their replacements, but I
hit a dead end, because an el
Be that as it may, the fact remains that nim-mode is written in elisp. ;)
I don't even think these changes are hard at all, but I don't know my way
around how to find the code responsible for those indentations without studying
all of nim-mode first.
Good to hear! I couldn't find the source for the new version of the live demo
though. In the markdown document it's still the old code as far as I can tell.
Yes, please just ask!
Sorry, I didn't see the post before.
You're almost there. There's two small things missing in your code.
1. you should add a newline to the string you write to the input stream. cat
wants that newline
2. instead of closing the input stream, you flush it.
Note however that with cat at leas
That part of the manual is now in the experimental document here:
[https://nim-lang.github.io/Nim/manual_experimental.html#taint-mode](https://nim-lang.github.io/Nim/manual_experimental.html#taint-mode)
If I'm not missing something, you should call newSeq instead:
var ret = DICT(newSeq[Context]())
Run
But of course, any Nim code you write should either error during nim
compilation or compile successfully.
Ah yes, indeed. If DICT is just a proc that takes a Context, this also works
btw:
let ret = DICT(@[])
Run
The compiler can deduce the type of the empty seq itself from the args of proc
DICT(c: Context).
Although personally if the use case of an empty seq as the argum
I should participate again I guess. I fear I'll have even less time than last
year though. We'll see!
You might want something like this:
import macros
type Foo = object
a: int
b: string
macro getFields(x: typed): untyped =
let impl = getImpl(x)
let objFields = impl[2][2] # 2 is nnkObjectTy, 2 2 is nnkRecList
expectKind objFields, nnkRec
The error message for the second case isn't as clear as it could be, if you
don't know what to look for maybe. It says:
Error: type mismatch: got but expected 'CharSet
= set[int16]'
Run
See the (int) after the range ...? That tells you the type it gets is actually
Oh wow, I somehow thought it was intended behavior, since @mratsim advocated to
compile with -d:release -d:danger almost immediately after -d:danger was
introduced. So I thought you were aware of this.
I essentially had the same use case as @PMunch in the past.
When I thought about implementing reading Keras stored NNs in Arraymancer, one
of the problems was that
1. creating a NN in Arraymancer currently means using the DSL to design the
network layout. Since that DSL generates a whole bunc
I don't understand what you actually want to accomplish, but I'm pretty sure
you don't actually want a generic macro.
But your "would love to do that" idea actually works, with a small
modification. Just don't use explicit types, but use varargs[typed]. Then you
can extract the type information
That's because there's only a few characters, which can be used directly in a
format string.
To use other characters / longer strings, you have to put them between ' ',
like so:
echo dt.format("'.'mm'.'dd")
Run
See below the table here:
[https://nim-lang.github.
m/HugoGranstrom/numericalnim#natural-cubic-splines)
* to an extent seqmath by @jlp765 (and me to an extent, but not on
interpolation):
[https://github.com/Vindaar/seqmath/blob/master/src/seqmath/smath.nim#L639](https://github.com/Vindaar/seqmath/blob/master/src/seqmath/smath.nim#L639)
and below
You have to be aware that using strings this way is always going to be somewhat
inefficient, since each replace call will make a copy!
Of those especially in the following:
f2.writeLine(sLine.replace(sFind, sReplaced.replace("\"", "")))
Run
the sReplaced.replace("", "
As far as I know such simple string manipulations are actually pretty fast in
python. So don't expect an amazing speed improvement over python if your code
is this simple.
In more "real world" examples you'll see Nim outperforming Python.
Hey!
As many of you will be aware by now, I started to write a port of
[ggplot2](https://ggplot2.tidyverse.org/) some time mid last year:
[https://github.com/Vindaar/ggplotnim](https://github.com/Vindaar/ggplotnim)
After many sometimes frantic sessions working on this, I'm finally approa
Originally in fact the `DataFrame` type was generic and my goal was to write
the code in such a way that the underlying type does not matter. This made
things complicated though. In fact I even thought about an arraymancer backend
from the start:
[https://github.com/Vindaar/ggplotnim/blob/
You do it like this:
template mytempl(prefix) =
proc `prefix World`() = echo "hello world"
Run
See here:
[https://nim-lang.github.io/Nim/manual.html#templates-identifier-construction](https://nim-lang.github.io/Nim/manual.html#templates-identifier-construction)
So I did a thing today… (which is why I haven't answered yet).
This morning I took another look at a rewrite of the `DataFrame` using an
arraymancer backend. Turns out by rethinking a bunch of things and especially
the current implementation of the `FormulaNode`, I managed to come up with a
see
Super short update: I essentially reached feature parity of the arraymancer
backend DF right now.
Still WIP, but the implementation currently lives on the arraymancerBackend
branch in the playground dir here:
[https://github.com/Vindaar/ggplotnim/blob/arraymancerBackend/playground](https
everything
works, except:
[https://github.com/Vindaar/ggplotnim/blob/arraymancerBackend/playground/arraymancer_backend.nim#L946-L958](https://github.com/Vindaar/ggplotnim/blob/arraymancerBackend/playground/arraymancer_backend.nim#L946-L958)
and the modified recipes.
The code currently uses the a
Some simple benchmarks comparing the new backend to pandas at:
[https://github.com/Vindaar/ggplotnim/tree/arraymancerBackend/benchmarks/pandas_compare](https://github.com/Vindaar/ggplotnim/tree/arraymancerBackend/benchmarks/pandas_compare)
Note that I ran the code on a default pandas
Oh yes, I could have made that more clear.
Indeed, the default type is untyped. Both for the arguments as well as the
return type.
And yes, untyped is required to make this work. Essentially untyped is just
considered as a raw Nim identifier (nnkIdent in macro terms). If you used
string as an
result = toColumn res_47816024)
Run
which is indeed a little slower than a manual map_inline, but still pretty
fast. Compare the first plot from here:
[https://github.com/Vindaar/ggplotnim/tree/arraymancerBackend/benchmarks/pandas_compare](https://github.com/Vindaar/ggplotnim/
Aside from putting that shebang line at the top of the file you want to run as
a script, the file has to be saved as a NimScript file, namely use a .nims file
ending.
someScript.nims
#!/usr/bin/env nim
echo "Hello from NimScript!"
echo defined(NimScript)
Ok, so I just merged the arraymancer backend PR, which includes the PR for
version v0.2.0.
v0.2.0 was mainly ridgeline plots and scale_*_reverse. Note that due to there
is currently no recipe for a ridgeline plot. That will be added in the next few
days. Also they are not as nice as they should
The reason it doesn't work is that N .. M in the context of a for loop
implicitly calls countup.
You need to explicitly call countdown:
for i in countdown(high(seqStr), low(seqStr)):
echo seqStr[i]
Run
I'm on my phone right now, so I won't try to find the correct issues.
This is a problem of toSeq in combination with method UFCS. Call the keys
iterator as a normal function call to toSeq and it should work.
Can you share a more complete example on
[https://play.nim-lang.org](https://play.nim-lang.org)?
The proc you want to return shouldn't have a name. So this line:
result = proc differentiate(c: int): int =
Run
should be
result = proc (c: int): int =
Run
If all of your procs are going to look like newFooBar above there, it's
possible to generate with a macro.
import macros, tables
type
Tensor[T] = object
discard
Model = object
field1: string
field2: string
field3: int
> I'll look into your solution since I may need to adapt a few things (I've
> simplified the real uses cases to summarize it into a single problems). The
> goal is also to learn Nim's macro as well. I've now spent probably as much
> time on macros than it would have took to write the solution it
First of all see of course the docs here:
[https://nim-lang.github.io/Nim/macros.html#quote%2Ctyped%2Cstring](https://nim-lang.github.io/Nim/macros.html#quote%2Ctyped%2Cstring)
and the macro tutorial, specifically:
[https://nim-lang.github.io/Nim/tut3.html#introduction-generating-code](https://n
I'm happy to say that facet_wrap is finally back with version v0.3.5.
Normal classification by a (in this case 2) discrete variable(s):
Classification by discrete variable with free scales:
See the code for these two here:
[https://github.com/Vindaar/ggplotnim/blob/master/recipes.org#
Sorry about that. When I started writing this I had no idea cairo would be such
a pain on Windows.
There's an issue about it here:
[https://github.com/Vindaar/ggplotnim/issues/57](https://github.com/Vindaar/ggplotnim/issues/57)
I haven't updated the README yet, mostly because I do
principle as easy as providing these procs:
[https://github.com/Vindaar/ginger/blob/master/src/ginger/backendDummy.nim](https://github.com/Vindaar/ginger/blob/master/src/ginger/backendDummy.nim)
And see the actual cairo backend:
[https://github.com/Vindaar/ginger/blob/master/src/ginger/backendCairo.nim
I haven't had a use for this so far, but this is amazing!
You have a typo in your URL there. Missing the y at the end. :)
To be honest the comment by the guy who talks about the JSON representation is
just... well.
The numbers there are just what stringification of floats looks like. Consider
the value in the middle e-16, which is just 0. Or rather supposed to
be. If the JSON conversion were done by Nim, I'd say t
59 matches
Mail list logo