> I am on Windows 10, Nim Compiler Version 0.18.0 [Windows: i386], MinGW GCC.
I don't know if that is just for windows 10, I am on ubuntu with 0.18.0 and I
am getting the same thing though my code is a little different
{.experimental.}
type thing = object
x:int
Stass, the original program err messgae was "not all cases are covered" and
pointed to the start of the case statement which included the expression and it
was around 30 lines from the actual error. It was hard to find because it is
legal syntax in c++, python etc. It is something that I will
> scientists are also using Python and for any kind of data munching, a repl
> and a data visualization package are non-negotiable.
As a (wannabe) scientist, I can confirm.
Jupyter Notebooks are the tool of trade and they are very very helpful when
prototyping. I was pleasantly surprised when
> Since vscode doesn't work on all platforms
Wait, what?
[https://code.visualstudio.com/Download](https://code.visualstudio.com/Download)
\- you can have it on Windows, Linux, and Mac.
And I would like to add that I would be fine if the mailing list address is
added somewhere in the official nim site and/or to change it (for example to
use a nim-lang.org subdomain). The GMane address is also public for anybody to
use and thus can be listed publicly.
As I stated, it's
I'm already doing that. nim-general@thregr.org is live and working. The gmane
nntp group I gave is also live and working for anybody interested.
You can't reply to questions that people don't ask, to get more people asking,
we need to attract them.
Also you might not need a REPL but you cannot generalize your case with the
need of the millions of Python developers in the world.
Besides you have to look beyond devs, scientists are also
This is a setter proc:
[https://nim-lang.org/docs/manual.html#procedures-properties](https://nim-lang.org/docs/manual.html#procedures-properties)
@andrea: Thanks! I'll check it out.
> My real problem was the bad error message pointing to the wrong statement.
I'm not sure what you mean by "pointing to the wrong statement". They point to
the line where the error occurs, and correctly tell you what the failure is. In
the first case, the compiler tells you that the `for`
Hi have been working with nim/ui for a month or so now. I can see a peice of
code in which I dnt understand in the wrapper.
proc `margined=`*(t: Tab; page: int; x: bool) =
tabSetMargined(t.impl, page.cint, cint(x))
and how to use it. The signature resembles to operator
Thanks for the explanation. I saw the release note about ..< but I didn't know
about the ..number shortcut. I figured nim saw -1 in x -1 as a negative 1. My
real problem was the bad error message pointing to the wrong statement.
you can also busy poll the result of the spawned proc in an async proc like
that:
import os, asyncdispatch, threadpool
proc doWork(): bool =
# staff use sql
echo "starting..."
sleep(5000)
# complete the future var
echo "... ok"
Didn't try it yet, but is that a REPL is 140 lines of code?
[https://github.com/AndreiRegiani/INim](https://github.com/AndreiRegiani/INim)
wavexx: for some time the forum was able to mirror posts to dedicated mailing
list. Unfortunately the SMTP integration has been shut down.
There was also an attempt at receiving messages from the mlist using POP - see
[https://github.com/nim-lang/nimforum](https://github.com/nim-lang/nimforum)
This is not my work, butif you are interested, I had already collected
something by @Krux02 similar to your work and published as a nimble package,
now improved by @RSDuck
[https://github.com/andreaferretti/interfaced](https://github.com/andreaferretti/interfaced)
I have developed a Tool for managing my driver using nim/ui. There two options
below which i used to compile my tool on linux.
1\. nim c --cc:gcc --threads:on driver.nim
2\. nim c --threads:on driver.nim
option 2 works but option 1 doesnt compile the libui library.
Its strange anyways gcc
@2vg asyncpg is good, thank you!
`..2` is a shortcut for `0..2`, so to the parser it looks like you have two
expressions following the `in`, and it tells you there should be a colon after
the first one. In your second example, `-10` is the literal for "minus ten", so
again, you have two expressions after the `=`.
IMO, what appeal most I think is OOP, although to be honest I think OOP is
overrated.
Crystal, which same as Ruby, seems emphasizing OOP.
To really appeal to Python programmers, Nim would have to support dynamic
compilation and a REPL. The lack of it makes a much bigger difference to a
programmer's workflow than superficial syntax changes, or even stricter typing
rules.
Code: interface
type
TForm2 = class(TForm)
procedure Shaders(var aShaderProgram: glUInt);
...
implementation
procedure TForm2.Shaders; How come it is possible that I can compile and run
this?
@boia01: Oh, I wasn't trying to imply you're dissing it. Just wasn't sure what
you meant, but now I'm also looking forward to the built-in solution, which is
always preferable for this sort of thing. Nim is still the only language I know
of that has all the elements needed to implement it on
[https://insights.stackoverflow.com/survey/2018](https://insights.stackoverflow.com/survey/2018)
^ I'd like to propose this as a discussion topic.
Some brief thoughts:
* **Python 's popularity is growing** (and all other measures seem to
confirm).
* I still think it would benefit Nim to
Find a way to solve the problem. Here is the code:
proc doWork(evt: AsyncEvent) {.gcsafe.} =
sleep(3000)
evt.trigger()
echo "work over"
proc waitEvent(ev: AsyncEvent): Future[void] =
var fut = newFuture[void]("waitEvent")
proc cb(fd:
Have you tried this? [asyncpg](https://github.com/cheatfate/asyncpg)
To wait for some result of Spawn's task, you can confirm by using isReady()
function.
For example,
[ChatApp#L38](https://github.com/dom96/nim-in-action-code/blob/master/Chapter3/ChatApp/src/client.nim#L38)
@StasB - Sorry didn't mean to diss your hack - it's very cool and very similar
to the upcoming vtrefs. Concepts should support field access too. Being an OO
junky, I'm just looking forward to this kind of stuff supported as a
first-class feature in Nim.
I _think_ so. This may have changed recently (since 0.18.0).
[Here is the
changelog](https://nim-lang.org/blog/2018/03/01/version-0180-released.html).
One of the breaking changes listed says that "The unary < is now deprecated,
for .. < use ..< for other usages use the ` pred` proc". So, I am
BTW, I realize this isn't involving the `<`, but maybe it is the same parser
change that made it no longer work.
@Araq I got the RTTI error when using "x of A" when A was a type that contained
an unused field of a ref type of a forward declared type. That shouldn't affect
RTTI, right? I'll try to replicate it with a small example. Anyways, I guess
I'll just start filing bugs
30 matches
Mail list logo
