I am not sure about the current status of Arraymancer, but I believe it
supports most of your requests. Neo, instead, supports only:
* Slicing, concatenation, transposing... these sorts of array operations.
* Broadcast basic math functions to any array.
* Linear algebra (e.g. matrix
> for new projects I wouldn't use anything else because the tooling is so much
> better
That would be great, but it requires an introduction that explains to users
what ARC is, how to make use of it, how it impacts multithreading, the new sync
and lent parameters, how to design collections and
I am trying to understand ARC, which seems to be promised as the future for
Nim. That, in turn, redirects to [this
document](https://nim-lang.org/docs/destructors.html), so I am reading that,
but I cannot make head or tails of the whole document.
It starts with a motivating example, which I
By the way, if Nim 1.2 requires a specific version of OpenSSL, this should be
mentioned in
[https://nim-lang.org/blog/2020/04/03/version-120-released.html](https://nim-lang.org/blog/2020/04/03/version-120-released.html)
Isn't OpenSSL a system library? I am not sure how to update it without breaking
a lot of things. I am using MacOS Sierra, this is probably why I am having
trouble
I am now getting the error
could not import: X509_check_host
Run
every time I invoke nimble :-(
There's this
[https://github.com/nim-lang/Nim/issues/7370](https://github.com/nim-lang/Nim/issues/7370)
I think it would be better to give your objects ids and use those as keys to
the table. Pointers, by design, can be moved
There's nothing wrong in this in my opinion. It just means that `T` is an
opaque type. You can get it from exported functions, and pass it to other
exported functions, but you can't create one yourself or manipulate one without
using one of the functions in the module that exports it. I would
Do you produce your AST at runtime? Because macros are run at compile time, so
that's too late. It sounds like you are trying to use Nim macros like a JIT, if
I understand correctly
Are you sure you used write and not`writeLine`? write does exactly that,
without adding newlines
[https://play.nim-lang.org/#ix=2bvn](https://play.nim-lang.org/#ix=2bvn)
write(stdout, someString)
One thing to keep in mind is that having FFI in the VM allows it to also work
in the secret interpreter. This ensures that one can try out more things
interactively, such as anything that needs `times` for instance.
> there is no reason to despair and stop developing Nim libraries.
Thank you, I ensure you that I do not despair, but I feel a little lost with
all the recent changes :-)
The issue for me is that posts about `--gc:arc` still reference concepts like
`sink` and `lent` parameters. These are described in [the post about
destructors](https://github.com/nim-lang/Nim/blob/devel/doc/destructors.rst#nim-destructors-and-move-semantics),
but, well, that document is not
How can I validate if computing 2^500 is safe without, you know, asking the
computer to compute 2^500 and dealing with the overflow?
Or even when compiling - just use `nimble c` in place of `nim c` and so on.
Even better, write a nimble task and call that
> I'm not sure what would be a reasonable way to handle an out of bounds
> exceptions or an overflow even if it were catchable. It's not like a file not
> found where we can expect user interaction behind.
For an HTTP server, output an error 500 and go on processing other requests
(the point
> In the "goto based exceptions" mode checked runtime errors like "Index out of
> bounds" or integer overflows are not catchable and terminate the process.
Hard to love the new exceptions if one cannot defensively protect against out
of bounds errors and risk to see their process terminated...
I actually find these error messages very very helpful. Sure, sometimes they
are a little verbose, but it is nice to see all existing overloads with the
corresponding mismatch
[https://github.com/unicredit/csvtools](https://github.com/unicredit/csvtools)
relies on type definitions to automatically generate a CSV parser
[https://github.com/andreaferretti/memo](https://github.com/andreaferretti/memo)
defines a `memoized` macro that performs memoization of a function.
Great, thank you
omials, tlinear, tprimality, tintegers_modulo, tfinite_fields,
tnormal_forms
Run
The problem is that I get a lot of warnings like
/Users/andrea/progetti/emmy/tests/all.nim(16, 8) Warning: imported and not
used: 'tstructures' [UnusedImport]
/Users/andrea/progetti/emmy
> They are not gone. They are frozen
Good to know, I had assumed the repo was frozen because building csources was
deprecated
I am wondering as well... maybe it didn't? :-D
In any case, I have updated memo per @mratsim's suggestion, it seems the best
approach for now
I used to rely on CSources to bootstrap Nim, but I just realized that [the
repository](https://github.com/nim-lang/csources) has been archived.
I have a custom script called
[MyNim](https://gist.github.com/andreaferretti/d40af6a276fb3275d97d0f9585d8197e)
to manage Nim versions, as well as
Yeah, I agree it works, and this is probably the solution I am going to take. I
just don't like much the fact that I am generating a function whose name never
appears anywhere, but I don't see any better solution
@cdome: the problem of using gensym is that - well, users have to be able to
call this function, they could not with a generated name.
@mratsim Your solution should work. It is not really optimal to generate a
function with a magic name such as `resetCacheFib()` but if there are no other
In Nim 1.0, a fix was made to disallow declaring a template of an untyped
parameter more than once. That is, this is now disallowed
template foo(x: untyped) = discard
template foo(x: untyped) = discard
Run
This is correct, and one may wonder why it was
Hi Royi, as I have written in the README,
[linear-algebra](https://github.com/unicredit/linear-algebra) is now
discontinued in favor of its sequel [neo](https://github.com/unicredit/neo).
But be sure to also check [ArrayMancer](https://github.com/mratsim/Arraymancer)
which is much more
@bobd
> There's one package, for example, that I was planning to use that gets a 2
> for code quality
That's precisely my point! You are making a decision based on a cursory
assessment by a person who has looked at hundreds of packages in a month. You
should **not** reconsider using that
I don't know, I have never mixed middleware from different libraries even using
python - I always used Django, or Flask, or Bottle on their own. The existence
of a basic HTTP server in the standard library can be used as a common ground
on which one can develop frameworks (this is what
Since handlers are nested, you should be able to see outer variables in the
inner handlers. For instance something like
scope do:
let user = getUserData()
return someHandler[
someOtherHanderl[
ok(user)
]
]
Run
I
I published
[bindings]([https://github.com/andreaferretti/react.nim](https://github.com/andreaferretti/react.nim))
to actually use React in frontend Nim applications. I can't say it is very
actively maintained, but I accept PRs
Wow, @spip, you made a great work! As you mention, it will be complex to keep
this up to date, but already having this information as of today is a great
start!
I use some Fortran bindings to the LAPACK library in
[neo]([https://github.com/unicredit/neo/blob/master/neo/dense.nim#L1086)](https://github.com/unicredit/neo/blob/master/neo/dense.nim#L1086\)).
Here I make use of a [fortran
That's sad :-( But it shows the power of advertising...
@cdome It can be implemented with 100 lines of code, but can it be implemented
**transparently** for users, or will GC users have to write more convoluted
code than today? Moreover, can **deferred** RC be implemented with 100 lines of
code (I guess not, one has to distinguish between local
I see that different people really have different priorities. :-) For instance,
the standard library, documentation and tooling have been really good enough
for me for a long time, but I keep seeing people complain about those.
> That's all there is to it, the important questions are: > Is this annoying to
> use in practice? > Does it produce catastrophic crashes in practice long
> after the code has been tested extensively?
Agreed.
> Come on, that's a terrible argument.
Well, sort of. Things always evolve, but work
> seem to be implying that the GC is going to be completely removed for 1.0
Sorry, I am not implying this at all. I am just saying that 1.0 will be
released with a mechanism for memory management (GC) which is already in the
stage of being replaced. This is bad for two reasons:
* people will
I have used Nim for many small experiments, but the main reason why I am not
using Nim as my main programming language is that it is not popular enough. I
know this is circular, but where I work I am the Nim person. If anything should
go wrong on a project where Nim fails to deliver on some
The fact is that `entry` is a tuple, hence the type of `entry[i]` depends on
`i`: for `i < 5` it is `float`, while for `i == 6` it is `string`. The type
checker, to perform its work, must be able to evaulate `i`` at compile time.
If, say, ``i` was a constant, what you did would be ok.
The
> concepts were deemed to experimental yet to build another key feature on top
Uh that's sad, it would have been nice to have static and runtime polymorphism
coexist nicely within the same mechanism
> do you have any links providing examples on how to do it in Nim?
I am not sure what you are asking. It is an optimization, and as such it should
be invisible in frontend (i.e Nim) code. It is the task of a compiler backend
to implement it, not something you do by hand. Or maybe I just
> even lowly shr is still in process of being changed to be more in line with
> other languages (a good thing IMO)
which completely broke
[cello]([https://github.com/unicredit/cello](https://github.com/unicredit/cello))
:-(
> the latest memory management model eliminating GC is huge and
Thank you for the explanation. I am still curious, though, since it is not
difficult to create a variant of the problem where one needs to actually keep a
thing into two different collections. For instance, say I am designing a cache
where I keep objects of type `ref T`. I want to be able to
I have read the new spec, and I have one more question. With the new model,
most collections in the stdlib will be written to use sink paramaters and take
ownership of the objects that they contain.
Many algorithms require to keep the same object in more than one collection at
a time. For
@cdome There is a point in discussing this now, otherwise we will end up with
something unsatisfactory in 2020. The post by @GordonBGood \- while having
problems with the benchmark, as pointed out by @Jehan \- discusses some
shortcomings of the new runtime that are worth debating for me.
The
Try putting explicitly rosencrantz.delete, I think there may be an issue
because the function delete is overloaded
> it sounds for me like proc[urrent] not like proc[essor]
Actually, it is short for proc[edure]. What does procurrent even mean?
Type1 and Type2 are not distinct types, they are just aliases. You are
declaring a different name for the same type uint32, there is no subtyping here
https://github.com/wicast/nim-docset
Well, in any case a trivial implementation will have no chance to succeed
whatsoever, Nim, C or Assembly. If you want to replicate the result, you should
at the very least use the methods described in the paper
Yes, please! The weird semantics for immutability is my number one issue with
Nim! :-)
> Limiting the official Nimble module list to just the code with acceptable
> licenses.
Please. You haven't contributed a single library to Nim's ecosystem, I made 18
(including wrappers), all under Apache2. But for some reason, you keep talking
as if this was a threat to the purity of Nim's
The situation is not as dire as described, I use them quite extensively in
[emmy](https://github.com/unicredit/emmy)
Still, I find some issues with them, they are not completely stable right now
Well, if there is no directory, then there are no files inside it to iterate
on. Makes sense to me, I would not want an exception there
I generally find Nim's documentation ok, so it is not my top priority. That
said, the areas that are not well-documented are:
* the various modes of GC: which one are available? how do they differ? which
external requirements do they have - bohem, go libs etc. Especially, it is not
clear how
I am not sure about the rationale for this design. Why don't you just export
type PostalCode* = distinct string
Run
and then use this type elsewhere? In this way, you can leverage Nim type system.
I am not really familiar with Clojure, but it looks like this design
Constraining types and variables to have different namespaces would be a
solution. The only issue with that is that sometimes types can be used as
values (typedesc) and in that case there could be a clash (unlikely, but still).
@preempalver It used to be the case that the first letter was also insensitive.
That was changed because many people - me included - like to do something like
let person: Person = ...
Run
Great if that works for you! In any case, the constraint on types comes from
the fact that the only way to construct an HCons is with the cons function
(because the h and t fields are private) and the only two exported overloads
only allow valid constructions
In any case, I think that in Nim a more idiomatic solutions would to use tuples
instead, which are of course isomoprhic. One cannot used recursion with tuples,
but that can be easily circumvented with macros.
Uh? I just proposed a solution that implements HLists. Is there anything
missing?
Yes, since the list is heterogeneous, the type changes according to the various
parameters. It is very similar to a tuple - as explained in the blog post I
linked - but it behaves like a list in certain respects and this helps in
writing generic procedures that would otherwise require a macro
@alehander42 What @trtt is trying to implement is called an HList, and is a
common construction in, say, Haskell or Scala.
This is an [example of implementation in
@trtt Here it is
# hlist.nim
type
HNil* = object
HCons*[H, T] = ref object
h: H
t: T
HList = HNil or HCons
let hNil* = HNil()
proc cons*[H; T: HList](hd: H; tl:T): auto =
HCons[H, T](h: hd, t: tl)
template
I am on my phone now, I will try to give an example tomorrow
No, you don't need parameters there, you can leave them unspecified. HCons is
just the existential type HCons[H, T] for some H and T
If you want to prevent T to be anything other than HNil or HCons, just make the
constructor private and expose two overloads of cons
@trtt Ok, I have a version that works
type
HNil = object
HCons*[H, T] = ref object
head*: H
tail*: T
let hNil = HNil()
proc cons*[H; T](hd: H; tl:T): auto =
HCons[H, T](head: hd, tail: tl)
let l = cons("hi", cons(2, hNil))
@trtt I agree that the code I posted is not working. But I am convinced that it
**should** work, and the fact that is not working is a bug of Nim. It is true
that a generic T does not have fields like head and tail. On the other hand,
all concrete types T which are ever used in specializing
@trtt You can add such a constraint with `T: HList` if you want. It seems not
to work very well now, maybe I will try to figure out why.
But there is another point which is important. You **do not** lose the generic
type information if you don't specify T. This is because the type checking and
@trtt Apart from using solutions for pattern matching such as gara, you can
iterate recursively over HLists and use if/case statements
This is how I would write a barebone HList, but for some reason the recursive
printAll does not seem to work
type
HListKind = enum hkNil,
@miran thank you, I did not think of that! :-D
What's a FE lib?
@gemath Actually, a pure Nim library could not respect NEP1 and follow a
different naming style. If I use such library, I will call it using NEP1
identifiers - no importc in sight.
I think it could make sense to add a warning in the compiler for the case where
mixed styles are used **inside**
@allochi that experiment does not really make much sense, because you are not
supposed to use style insensitivity to mix styles inside a codebase, unless you
are masochistic. Style insensitivity is used to take a library written in a
different style and use inside your project without having to
@moerm I think the misunderstanding stems from your claims
> To be frank, almost everything seems to be faster than Nim in the techempower
> benchmark. > A quick look at Single query, Multiple queries, Fortunes, Data
> updates (all "physical"), each with all sub-categories, showed that Nim was
@moerm Nim was not in the results for these categories because - well, probably
no entry for Nim was submitted :-)
Style insensitivity is my least favourite feature. That said, I also don't want
a vote. I'd rather have a stable 1.0 sooner instead of another language change
Nim does not have a REPL (well, there is one but it does not work very well),
but it has an interpreter, which is used, among other things, to compile macros
and to scripts Nimble.
You can embed the interpreter in your application - a starting point could be
In fact, \--clang.cpp.options.linker = "-Oz -s ASM_JS=1 --separate-asm" would
do as well, if not for the dots in the option name. Options without dots will
be configured ina way that is almost equal to nim.cfg
I guess
switch("clang.cpp.options.linker", "-Oz -s ASM_JS=1 --separate-asm")
Run
and so on
> Deprecation of the old config system is tough as long as the new config
> system is so slow. :-(
Anecdotally I have yet to experience any difference whatsoever. This may be due
to the fact that I build using Nimble anyway, so the only point where I have to
use config.nims/nim.cfg is to
I don't know which solution I would appreciate most, but I should mention that
have also frequently incurred in 1), 2), 3), 4)
It's not only about compiler, in any case: most PRs are actually for the stdlib
If you have ever tried to write some complex JSON structure in a typed
language, you will quickly realize that such shortcuts are indeed very useful.
Now, this is true especially for %, which will be repeated often, while %* is
only used once per structure. That said, I find %* consistent with
When you write `var a = a`, there is no local variable `a` in scope yet, so the
(new) `a` gets assigned the value of the parameter `a`.
When you write `var a: int`, you introduce a local variable `a` that shadows
the parameter, and then `a = a` is a no-op
I am really happy to see a complete pattern matching library for Nim!
Congratulations for your efforts!
I don't think it is a good idea to be explicit about `<` being a proc. For me
concepts are about (static) duck typing: if it supports `<`, then it satisfies
the concept. This is good, because I will want to call `<` on members of the
type. I see concepts as a promise that the code I write next
Yup, that's it
Congratulations! I am very happy to hear about this partnership with the very
talented Status team!!
Agreed with GULPF: the imperative syntax of concepts makes it more suited to
some kind of duck typing. Moreover, I find
type
Comparable = concept x, y
(x < y) is bool
Run
simpler than
type
Comparable[T] = concept
proc `<`(x,
I have done wrappers for BLAS, LAPACK and CUDA using only c2nim and some manual
work.
BLAS and LAPACK are ok and they are unlikely to change, but it would be nice if
my CUDA wrappers could be automated using Nimgen (ideally in a backward
compatible way), so that they could be kept up to date
I'd say both are needed. Testament certainly works well for the compiler, but a
standard library unit testing module is very useful and enough for most
libraries
The simplest way is to use an editor with nimsuggest support - for instance I
am happy with Visual studio code and its Nim extension, but many other editors
support Nim integration
This discussion was rather strange until now because the first post was not
visible.
Now that we have more context, my impression is that the feature makes sense,
but maybe it would need more use cases. recur is one, and another one I can
think of is adding unobstrusive serialization support.
Agreed with what @Araq said. Mantaining a sort of enlarged standard library
seems a lot of opinionated work. And this can be done externally with a small
tool that just takes a list of Nimble packages and `nimble install` them all
1 - 100 of 236 matches
Mail list logo
