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
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*:
@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:
@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
**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
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:
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
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
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.
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)
*
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:
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.
—
> 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
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
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
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
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,
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,
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,
Thanks @jyapayne, I had tried that before, but it didn't make any difference,
it still reports:
zip_zipfiles.o:zip_zipfiles.c:(.text+0xab): undefined reference to
`zip_open'
zip_zipfiles.o:zip_zipfiles.c:(.text+0x408): undefined reference to
`zip_strerror'
@miran: You sound like a Fortran spy ;)
Related RFCs: [#7474](https://github.com/nim-lang/Nim/issues/7474) ([RFC]
standardize constructors as: Foo.New(args) instead of newFoo(args))
And [#7519](https://github.com/nim-lang/Nim/issues/7519) ([meta issue] make all
Nim APIs generic: ctor, init, to, streams, types, etc)
Having those
39 matches
Mail list logo
