I think you may be confused about the following:
type
NodeConcept* = concept n # LINE A
$n is string
GraphConcept*[NodeConcept] = concept g # LINE B
type NodeType = NodeConcept
g.nodes() is seq[NodeType]
Run
The `NodeConcept` on lin
@yatesco I've made a PR to your repo with the fixes!
[https://github.com/yatesco/docker-nim-dev-example/pull/1](https://github.com/yatesco/docker-nim-dev-example/pull/1)
Oddly, if I change part to
NodeConcept* = concept n
$n is string
n.foo() is string
Run
Then it _still_ works. But why? `n.foo()` does not exist. I thought these were
constraints. And in fact, I can call any method on the `GraphConcept` that
actually ex
Somewhat related to this, and perhaps I'm only thinking about it because I
haven't yet used an editor with good integration (I'm on Sublime and it didn't
work out of the box), perhaps it would be useful in the HTML documentation to
list all the procs that apply to a type. For instance, if I have
Wow. I don't know now.
Slightly modifying your example, here is closer to what I want:
type
NodeConcept* = concept n
$n is string
GraphConcept*[NodeConcept] = concept g
type NodeType = NodeConcept #type(g.node())
g.nodes() is seq[NodeType]
N
You should be able to replace your call for the linux build with:
nim c --cpu:amd64 --os:linux --opt:speed --embedsrc --threads:on
--checks:on -d:release src/*.nim
cp src/docker_nim_dev_example $my_pwd/dist/linux.exe
Run
(notice the `-c` removal)
Similarly, you ca
Thanks @dom96. I am definitely stumbling around in the dark :-).
The reason I used `nimble` was because of your comment in
[https://forum.nim-lang.org/t/4014](https://forum.nim-lang.org/t/4014) ;-). I
also thought `nim` would struggle to find the dependencies?
I guess I have a bit more reading
I don't think my proposal is just about the syntax, the underlying semantics
change significantly. As I've mentioned, the specification becomes more
concrete and less prone to surprises, i.e. _semantically_ concepts become
simpler.
@cdunn2001 I'm not sure why you think it doesn't work. I typed up your example
and the following works (I'm using Nim 0.18.1):
type GraphConcept* = concept g
type NodeType = type(g.node())
type Node* = object
n*: int
type Graph* = object
nodes*: se
@cdunn2001 I just replied to your other thread about concepts. I'm not seeing
the issue you were mentioning.
[https://forum.nim-lang.org/t/2999#25214](https://forum.nim-lang.org/t/2999#25214)
You have to resort to LoadLibrary indeed, but you could also patch
`lib/pure/dynlib.nim` and a Windows specific extension. And create a PR please.
:-)
@arnetheduck, regarding run-time polymorphism, there is a planned feature
called "VTable types". You can read the spec here:
[https://github.com/nim-lang/Nim/blob/5491f1f53b4011785b41b30897b73538d564fd55/doc/manual.rst#L4764](https://github.com/nim-lang/Nim/blob/5491f1f53b4011785b41b30897b73538d5
@cdome, there is simple way to ensure that your type conforms to a concept.
After defining the type and all its procs, put a static assert near the end of
the module:
static:
assert Foo is SomeConcept
Run
Future versions of Nim will produce a nice error message descr
**Excellent news!**
(Does everyone still think I'm crazy for [pushing Nim on the license freedom
front](https://archive.fo/E77TN#selection-989.0-1009.452)?)
Okay, so the issue is that you're trying to compile the .c code yourself using
gcc. But whatever the Nim compiler does seems to be working fine.
I would suggest taking a look at `nimcache/docker_nim_dev_example.json`, it
will contain information about how to compile the C sources. That should he
This news has been picked up by two websites, their write ups are worth a read.
The Register:
[https://www.theregister.co.uk/2018/08/07/nim_funding_ethereum_cryptocurrency](https://www.theregister.co.uk/2018/08/07/nim_funding_ethereum_cryptocurrency)/
EthNews:
[https://www.ethnews.com/ethereums
Hi, I would like to call the following Windows DLL function from Nim (here the
declaration for C#):
> [DllImport("uxtheme.dll", EntryPoint = "#96", CharSet = CharSet.Unicode,
> PreserveSig = true)] internal static extern uint
> GetImmersiveColorTypeFromName(
string name);
The problem is, the
Well but we can tweak the semantics endlessly to make it fit ever more varying
concept descriptions we might want to write, but we will be stuck with the
syntax. It's not foolish to strive for a good syntax.
The concept syntax has been discussed already ad nauseam. The current syntax is
inspired by the ConceptsLite proposal that will eventually make its way into
C++, so in a distant future it should be familiar to a lot of people.
Considering that the concept definitions will be roughly 0.0005% of a
I presume you mean
[https://github.com/unicredit/nimcuda](https://github.com/unicredit/nimcuda)
You are quite right - that was left over from before.
Absolutely fantastic - I can only imagine how validating and exciting this must
be after all of the hard work Nim must have required to get where it is today.
Well done, all of you (whoever 'all of you' is :-).
Onwards and upwards!
P.S. Er, um, v1.0?, um, yeah :-).
it would be great if we could get a simple summary of how to get autocomplete
and go-to-def working with Nim + Vim. I'm unable to get it working.
The problem with `concept` is that it doesn't work with `seq[C]`. If you're not
aware of that, you can spend a huge amount of time debugging. After you're
aware, you have to modify your API in potentially difficult ways.
Other than that, I think they're awesome. Not kidding. I love the syntax.
@timothee, yes, we could use a whole suite of tools similar to **goimports** ,
**gofmt** , etc.
Brilliant news, very excited to see what lies ahead!
how about a tool, maybe based on nimsuggest or nim doc, that renders source
code to html or another nim file with fully qualified symbols (ie
module.symbol)?
Congratulations! I am very happy to hear about this partnership with the very
talented Status team!!
Fantastic news! :D Status has been really amazing for Nim
By the way, if you want to talk (convert?) the dev community at large, you're
very welcome to interact on Hacker News and /r/programming/
*
[https://news.ycombinator.com/item?id=17707238](https://news.ycombinator.com/item?id=17707238)
*
[https://www.reddit.com/r/programming/comments/95ce7n/
Following [Nimbus announce](https://forum.nim-lang.org/t/4097) some of you may
have figured that [Status](https://status.im/) is fully invested in Nim.
Here is the partnership announcement:
[https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim](https://our.stat
This is amazing. I love how Nim is finally getting some support financially!
Congrats! :D
Any ideas on who the 2 new full time developers will be?
> We’re incredibly excited to announce the new partnership between Status and
> Nim. Status is developing an open source mobile DApp browser and messenger
> for Ethereum.
—
[https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html](https://nim-lang.org/blog/2018/08/07/nim-partners-wit
> Firstly, that you "know" where stuff comes from in dynamically typed Python
> is a pure myth. In obj.methodCall you don't know obj's type, so you don't
> "know" where methodCall comes from at all. It's far worse than in Nim.
True, but t's about transparency, not language guarantees. I'm intere
You are right. Duh. I forgot the implications of the second part of my answer
in the first one...
I still prefer the 0 ..< iterations as we usually iterate from zero with
non-inclusive upper bound in nim. If he changes the code at some point to use
that counter, my range will probably already b
There is some discussion in github on this subject
[https://github.com/nim-lang/Nim/issues/7917](https://github.com/nim-lang/Nim/issues/7917)
Ah OK. I did put a great big "NEWBIE" warning ;-). Unfortunately though, the
linux build still doesn't work as it errors out with:
/tmp/ccb40CFm.o: In function `nimLoadLibrary':
stdlib_system.c:(.text+0x6b6c): undefined reference to `dlopen'
/tmp/ccb40CFm.o: In function `nimG
Right, but that error you posted is for the Windows build. The linux build
should work after the libzip addition if you put -ldl like so:
gcc -o linux.exe nimcache/*.c -ldl
Run
The windows build is a bit more tricky. You'll have to cross compile zlib for
windows as we
IMO, Concept syntax is great from the user perspective. It clearly describes
what concept can do. From the implementer pointer of view it look like it is
far too easy to miss concept requirement and you are not sure while writing the
code you are matching the concept or not.
I don't think what
Are uninitialized variables a problem?
in c and similar, the variable space is filled with random or memory data, and
may lead to false calculations and corrupt state.
C# and Java use default and null to initialize structs and class-type instance
variables.
This partially solves the issue, but
> What if < is implemented with a template?
What if I don't want the concept to match in that case? The syntax I propose
makes the specification significantly more concrete and therefore more reliable.
But by far the most significant advantage is that it makes the implementation
far simpler. Co
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, y:
IMO there are good reasons for the current syntax. What if < is implemented
with a template? What if it has a third argument with a default value? What if
only `<`(x, y: int): bool` exists, but there's a converter for `T` -> `int`?
Since Nim has so much flexibility in how to implement things, co
43 matches
Mail list logo