> @evacchi, you're absolutely right; thanks for the reminder re cython.
hey nothing against what you're doing, but remember a strong motivation (same
applies to nimpylib)
well, if you're objective is to try and appeal to the Python community, I think
they might wonder what's the benefit of using Nim rather than,say, Cython,
which maps more closely to "real" Python
overloading may be an option as well:
proc a(x:int) =
discard
proc a() =
discard
a()
a(1)
to be fair, I feel that (in general) the critical approach to OOP that people
tend to have nowadays is refreshing. c.f., Stroustrup's [OOP without
inheritance](https://www.youtube.com/watch?v=xcpSLRpOMJM)
IMO, what most people need from OOP is dot notation I really like Nim's
uniform function
>
> # a.f() == f(a)==> I don't use it. Unnecessary parentheses hurt
> readability. Note that in languages such as Eiffel, this is normal.
>
personally, I like the Scala convention:
* if it does side effects, and/or mutate state, then use parens:
f.read()
also, what should Nim do when you `discard` the return value ?
> New Indented Modula-3.
oh I _like_ that!
@Araq:
> Looks ok but suffers from the usual problem that allocations/deallocations
> are ignored and these too can block. (In pretty much every allocator that is
> used in production. Note that Nim's is particularly bad since it uses a
> single global lock in allocShared...)
Dang it ! What
sure, I have updated the code with the following example:
proc producer(q: ptr SharedQueue[int]) =
q[].enqueue(10)
q[].enqueue(20)
q[].enqueue(30)
q[].enqueue(20)
proc consumer(q: ptr SharedQueue[int]) =
echo q[].dequeue()
sure, I have updated the code with the following example:
proc producer(q: ptr SharedQueue[int]) =
q[].enqueue(10)
q[].enqueue(20)
q[].enqueue(30)
proc consumer(q: ptr SharedQueue[int]) =
echo q[].dequeue()
echo
Hi all,
I have translated into Nim a [simple shared
queue](https://gist.github.com/evacchi/0c059d71955aab2fb9ac892d914f838a) based
on [this blog
post](https://idea.popcount.org/2012-09-11-concurrent-queue-in-c/). Please
share feedback on how you would improve it memory/performance-wise
congrats!
> Often times they don't even have a project. Creating a .nimble file just to
> play around with a package would be tedious.
it isn't, as long as it's just a nimble init away. AFAIK
[stack](https://docs.haskellstack.org/en/stable/README/) and other modern build
tools work this way and they're
I'm sorry Libman, but I don't think this attitude is very good publicity for
the (already tiny) Nim community. This has nothing to do with censorship.
news: no changes on the surface, a few internal changes. New API: support for
"actor channels" a thin wrapper around shared channels
let t = createTopology()
let sink1 = allocActorChannel[int]()
let sink2 = allocActorChannel[int]()
# declare output sinks
let
impressive results!
news: featuring super-experimental support for [actor
topologies](https://github.com/evacchi/nimoy#topologies)
import future, nimoy, nimoy/topologies
#
# source ~> map1 ~> fanIn ~> map3 ~> broadcast ~> sink1
#+> map2 ~^
news: an improved (i.e., slightly less dumb) executor strategy, and a few new
examples, such as [an async, multithreaded
"loader"](https://github.com/evacchi/nimoy/blob/master/examples/loader.nim)
> I know Nimoy, but it isn't suitable for my project because it creates threads
> in the background.
actually it uses an abstract Executor which as a default implementation happens
to uses threads
> Also it has the same problem as almost every event system I saw, it requires
> to wrap the
I think it's too early right now, it really is a handful of lines of code; but
I probably will if there is enough interest.
RIght now, actors run on a thread pool (not Nim's _threadpool_) that can be
configured.
The execution strategy and migration of an actor across threads is pretty dumb,
As a newcomer, I decided to try and write a small actor library as an excuse to
learn Nim. It does need more work, especially on the scheduler, but I'd love
feedback from the community. This is definitely something I might want to use
in the future.
[https://github.com/evacchi/nimoy](https
I've reported the issue
[https://github.com/nim-lang/Nim/issues/5630](https://github.com/nim-lang/Nim/issues/5630)
that is correct. yet
template foo(p: untyped): auto = (block:
1
)
let x = foo:
discard
won't compile, while this will
let x = (block:
1
)
in fact, this compiles as well:
template foo(p: untyped): auto
> Is it possible to return value from template which the last of argument is
> untyped?
pretty sure you can:
[https://nim-lang.org/docs/manual.html#templates](https://nim-lang.org/docs/manual.html#templates)
if I understand correcly what you mean I'd expect it to compile with:
template foo(p: untyped): auto = (block:
1
)
but it won't
Hi, i'm trying to assign the result of a template, but apparently the compiler
gets confused unless I surround the template with (block: ...)
template foo(p: untyped): auto =
1
let x = (block:
foo:
discard)
let y =
@Fungi: you clone it from github then cd into the dir and run jekyll serve
(provided you already did gem install jekyll – ruby required)
love the new website design!
I don't love the typeface, but I definitely like it more than current, it looks
much more current and fresh. Any ETA for seeing it live ?
(not sure about the mascot idea, but the prototype is definitely too aggressive)
@xyz32: I had a few problems with making nimsuggest work on macOS with VSCode.
I ended up compyling nim from sources, then adding /path/to/Nim/sources/bin to
my $PATH.
FYI: previously I had Nim installed from brew and it couldn't find the binary
(possibly because of problems resolving
I'm not sure this is relevant but [the manual
says](https://nim-lang.org/docs/manual.html#parallel-spawn-spawn-statement) :
> Due to technical limitations not every type T is possible in a data flow
> variable: **T has to be of the type ref, string, seq or of a type that
> doesn't contain a
30 matches
Mail list logo
