Fully automatic translation seems (almost?) feasible if you map every value to
a JSON-like universal type, say PyObject. Then you would have
super-non-idiomatic Nim code but you can gradually rewrite it to use more of
Nim's static typing and native types.
Well we can try to learn the lessons from
[https://github.com/metacraft-labs/py2nim_deprecated](https://github.com/metacraft-labs/py2nim_deprecated)
* Python code is more dynamic than it looks and even your code doesn't use
much of Python's dynamic nature, some of your dependencies do.
*
> So it's a pain to rebase... Anyone know what's required to get the base PR
> merged?
Where is your PR?
> Is there a wish to build a compiler's internals documentation or is it a
> knowledge that lives in the compiler hackers' minds?
Well we have the internal documentation and we're always accepting PRs but I
generally assume that compiler contributors have read some book about compiler
> Case 2. Overloading for optimization, to avoid copy/reuse buffers we can have
> 2 versions of a procedure, one with sink and one without, for example
That's not supported by Nim and so far I haven't seen convincing examples. If
you want to take over ownership, you always want to leaving you
Well if you want to know why something works for procs and not for templates,
look at the different handling of `skTemplate` inside `sigmatch.nim` and
elsewhere. Looking at the AST is pointless, no matter how much you look at it
and under which views and wether it's the AST for the proc or for
Please report issues on github so that we track their progress.
Try `cmd.exe` and not bash.
Run `finish.exe` please and install GCC via it.
Interesting, did you compile with `-d:danger --panics:on` ? Also watch out, the
allocator now uses 16 byte alignments iirc and for reasons currently unknown to
me `-d:withRC` uses much more peak memory than ARC.
Also a fun fact: Even without `.acyclic` ORC has the same performance than ARC
on
Another major update: On Nim devel destructors are now scope based, not
function based. This brings Nim's semantics closer to C++/Rust and is a key
enabler for more optimizations. Still left to do:
* Bugfixes, as usual.
* Better inlining for the generated assignment operators and
Something like:
proc newAudioContext*(): AudioContext {.importjs: "new (window.AudioContext
|| window.webkitAudioContext)()".}
Run
Whenever you leave the C code that Python happens to use like actually looping
over an array it's slow. Python is in fact an _abstraction inversion_ ,
primitive operations are slow and high level operations are fast (because they
can avoid Python's slow VM) and so you need to use premade
Yeah and in fact, I considered such an optimization but with ARC/ORC the effect
isn't as big as it used to be so it's better to focus on these.
Good point so probably we should require `ptr T not nil` for auto-deref...
The define to use is `when defined(nimdoc)`.
We didn't develop it further as there were unforeseen interactions where `p !=
nil` would be rewritten to `p[] != nil` or `p != q` to `p[] != q[]` but tbh I
don't remember the details.
This feature needs to be re-designed. Here is my current proposal:
"If overloading resolution in a call using
Since I suspect it'll come up: You can compare it to Java
public class HelloWorld{
public static void main(String []args){
\u0053\u0079\u0073\u0074\u0065\u006D\u002E\u006F\u0075\u0074\u002E\u0070\u0072\u0069\u006E\u0074\u006C\u006E("Hello
World");
> magine swapping out Nim's object variants for Rust's enums. I think that
> would be an improvement.
>
> Araq has explained on several occasions why he designed Nim's object variants
> the way he did.
Well you're both right. :-) The current design has its advantages but Rust
> Is that the plan?
Almost. We need to run the cycle collector before a send already to ensure the
thread local "cycle candidates" list is empty (note that it is always empty
after a cycle collection), otherwise it would interfere with multi-threading.
Alternatively we can make the list global
> How will the iso property be checked dynamically? Well, the object's
> refcounts will be checked, they all have to be zero (or one, depending of how
> we count). Now, the owned ref comes into play.
Nah. I mean, you could do it this way, but there is a much better way: You
traverse the
Nim's strings do a mild form of copy-on-write so that string literals can be
copied in O(1). Probably the logic is flawed.
> I think this kicking the tires has probably uncovered a real problem.
Indeed, there is a high priority bug lurking here, please keep investigating!
> And furthermore, the object you're moving to another thread can't refer to
> any other objects that have references on the current thread ... this sounds
> like something that could accidentally lead to difficult-to-discover race
> conditions if one is not careful!
That is correct but we'll
These are two different mechanisms, so IMHO it shouldn't be merged.
Huh? Tracing GCs should never win this. Something strange is going on... :-)
Memory consumption is usually _much_ better with `--gc:arc`.
> I am not sure why since the rst parser seems to support it, maybe it would be
> fixed by a forum update or maybe I just did something wrong.
Security. You are not allowed to destroy the site's layout. ;-)
Use `.add` instead. We don't optimize `` s = s & 'x'`` because nobody writes it
this way.
We only recently started to care about benchmarking everything against the C
code inside Python's implementation.
Because `write` collects all the arguments in an array? See
[https://nim-lang.org/docs/io.html#write%2CFile%2Cvarargs%5Bstring%2C%5D](https://nim-lang.org/docs/io.html#write%2CFile%2Cvarargs%5Bstring%2C%5D)
Reading the docs can beat "fuzzing".
> I'm writing code that manipulates portions of seq s, and I keep creating proc
> parameter lists that include input: openarray[byte]; inRange: var Slice[int],
> and then inside the proc I keep writing stuff like input[inRange.a + i]
Er, you can slice with `toOpenArray`, no need for the
The error message could be better, of course, but JS has no `getEnv` and Nim's
JS target is **not** NodeJS.
Interesting. Can you outline the learned lessons?
> But it's actually a tricky problem that might not be able to be solved with
> an iteration of Distribution, which is probably why it's not in the stdlib.
distros is for Nimble support, for nothing else. Detecting the distro is
fundamentally flawed anyway, test for features, not for distros or
Once again a big "Thanks you" to every speaker, the quality of the talks were
high throughout and the fact that every speaker was online during the stream
and replied to questions made it even more enjoyable.
Coming soon: A hackathon? How to organize one?
You can use `-d:nimEmulateOverflowChecks` for 1.2.0
There is also [https://github.com/zevv/nimcsp](https://github.com/zevv/nimcsp)
which is better suited for embedded development, it deserves more attention and
development.
Compile with 1.2.2 and if that fails still, compile with
`-d:nimEmulateOverflowChecks`.
> I think you've mentioned Pony elsewhere, though — their approach sounds much
> better; transfer ownership of a heap object between threads without actually
> having to copy the bytes around.
Yes, that's what we're working on.
The move optimizations help but the biggest impact is the fact that Nim's ARC
does **not** use atomic reference counting, instead a complete SCC will be
moved between threads. It's the atomic instructions that kill Swift's
performance, not the refcounting.
I think you should watch my talk at NimConf.
We're scheduling the talks today and will contact the speakers and update the
website afterwards. Sorry for the delay but just today we received 3 more
talks.
Well I can only describe how arc works and I can assure you that Rust/Lobster
work very similarly and none of these languages have "compile-time reference
counting", strictly speaking.
Nim's integers, floats, enums, bools and objects of these and arrays of these
_always_ are "value" based
> Are these things completely unrelated?
They are related, --gc:arc is the evolution of `owned ref`.
> So what will happen to ownership?
It is outlined here,
[https://github.com/nim-lang/RFCs/issues/178](https://github.com/nim-lang/RFCs/issues/178)
A couple of remarks:
* 1.2.2 does away with the runtime's infamous genericReset calls, instead
much faster code is produced.
* The SSL bugs have been fixed. At least that's what I have been told.
* There is a new warning about "Observable Stores". I have yet to see a case
where this
It's dead code and we should remove it.
> If I add the gcsafe pragma to my callback proc, it now compiles without
> errors! Where's my "extended error information"?
There is a phase ordering problem in today's compiler so that in rare cases
`.gcsafe` isn't inferred the way it should be. (Known problem.)
The good news is that when
You can also import the compiler as an API and do the transformation as a
separate compiler pass. Unfortunately
[https://github.com/nim-lang/Nim/blob/devel/tests/compilerapi/tcompilerapi.nim](https://github.com/nim-lang/Nim/blob/devel/tests/compilerapi/tcompilerapi.nim)
only shows how to use
> In all languages (Go, Nim, ...) channels are built either on top of
> Lock+Condition variables or Atomics (reusing queue designs) but I expect we
> will reach the limits of memory coherency at the CPU level and that in the
> future NUMA will become increasingly important and we might see
Nice to see progress here. Maybe we can improve the stdlib's solution too, PRs
are welcome.
Anytime soon now (ha!) we'll improve the error message for this, it's a common
gotcha for newcomers.
Yes, indeed. Thanks!
So far I found "ParaSail" to be most inspiring. It keeps Ada's (and Nim's)
parameter passing modes, throws away pointers completely, adds some mild
aliasing checks and ends up with a system where g and h can and are run in
parallel within f(g(args), h(otherArgs)).
> Does that mean there are problems compiling to these two targets?
No, there are currently problems with the nightly builds but nim devel is green
on all major OSes including BSD.
> I.e. if we uncover showstopper bugs on 1.2 we hope to have a 1.2.4 release
> with the fixes.
Well surely you will get a 1.2.4 if you need one.
It's like this:
1.0 is our long-term support (LTS) stable release. While 1.0.N is in
development the version is 1.0.(N-1). The reason that 1.0.7 exists in our
branch is that there will be a 1.0.8. Because 1.0 is the version we support for
the upcoming X (X = 5?) years.
1.2.0 is the first
Sure, we're working on a fix. No promises on a release date.
Perhaps but omg I wasn't aware the documentation for this tool is already on
our website... :-)
Please don't do that, `ref` exists for aliasing, not for convenience.
> Then all our serialization libraries at Status have a tremendous amount of
> bugs
I don't understand how this follows. So you heavily use `auto`, ok, no worries.
My claim is that `auto` can "almost" always be avoided.
Remove the `nimGC_setStackBottom` and `GC_fullCollect` calls and compile with
`--gc:arc`.
Corner cases aside, `auto` can always be avoided and if it cannot, it's likely
a compiler bug.
> but choosing the right tool for the right purposes.
Nim is the right tool for all purposes. ;-)
The best justification for it is that without it `sugar.=>` would be harder to
write. Or impossible.
> But Go's slices are memory-safe and zero-copy and can be stored, for example.
They are technically memory-safe but prone to aliasing bugs anyway.
It's supposed to work, yes and should be documented in the manual.
Iteration order that depends on runtime values is a design bug.
> Is this a bug, or intentional? If the latter, is there a cleaner workaround
> like a pragma?
It's intentional but it's not part of the spec and we could change it.
The workaround is to add an enum field that is mapped to 0.
It's likely that your code is buggy. Use `setupForeignThreadGC()` in callbacks
that are called from C and run in a different thread.
Fwiw orange is my favorite color.
I completely agree with this proposal. It's time to make implicit result values
a warning. The extra line `result = 0` or similar in the beginning of a proc
won't kill us.
I would use `openarray[uint8]` too. Strictly speaking though Nim uses a Nim
`int` (== `ssize_t`) as the length information and so it's incompatible for
arrays which contain more than 2 billion elements (on a 32 bit machine). Never
happens.
Before we re-publish this as an article on our website, can you explain the
2min14.616s outlier for GCC 10 C++ OpenMP? Or can at least somebody confirm
these numbers? :-)
> I may very well be missing something, ...
Read mratsim's post from the same thread then,
[https://forum.nim-lang.org/t/6352#39200](https://forum.nim-lang.org/t/6352#39200)
> But is this within Nim's capabilities?
Well yes, I think so. But maybe I'm a little biased. ;-)
_shrug_ Not our bug. :-)
It's `cc:clang`.
That's a bug in `dom.nim`, fix is in the works.
You should use `--cc:clang --clang.exe=zig`.
> At this point I'm unclear on how much of this stuff is solid and
> enabled-by-default (in particular, what's the difference between "arc" and
> "orc"?)
ARC is in version 1.2 with significant stability improvements around the corner
in 1.2.2. Many Nimble packages already work with `--gc:arc`.
> For your example ARC makes a gigantic difference.
Yeah, known problem. Method dispatch got super slow for ARC. Not sure yet how
to fix it. I can do it the old way without problems, but where is the fun in
that. ;-)
> P.S. while the "hello world" http server is working, it currently blows up
> after about ~22 requests. Anyone got suggestions?
For stdlib's async you need `--gc:orc` and Nim devel, otherwise it leaks
memory. Sorry, I hope we can get 1.2.2 out soon! The good news is that we're
also planning
> But with a mention of prerecorded talks, I'm now really confused as to
> planned level of interactivity...? Personally, it would be much harder for me
> to present if I could not feel any kind of live connection with the
> audience...
Well for a prerecorded talk the speaker would be
Asking questions here that may or may not be answered in our manuals or
tutorials is fine. But short answers are fine too. ;-)
I'm _very_ interested in this port and would appreciate PRs. Ideally even CI
support.
> I did not want to use json. I wanted to use binary formats .. compressed
> binary formats.
Bummer, I still like them better than json. :-)
Sure, how about:
"Idiomatic Nim code is fast and Nim does not have "optimization walls." "
> It's not that Nim is fast, it's that Nim does not have "optimization walls."
Great quote! Can we put it on the website? It says in one sentence what I've
always tried to express.
No, in fact it's common idiom to do this:
proc test(n: int) =
let n = n - 1 # my indexing starts at 0 or something
echo a[n]
Run
I know why it doesn't compile but my reply would be identical to the compiler's
error message. You need to define your destructor earlier, like so:
when defined(gcDestructors):
proc `=destroy`*(self: var typeof(Event()[])) =
if not self.ignoreFinalizer and self.impl !=
> you can't mix inheritance with un-managed raw pointers.
I can do it. In fact, I did in Nim's allocator.
> you can't mix inheritance with un-managed raw pointers.
I can do it. In fact, I did in Nim's allocator.
> Instead of having multiple small macros that don't play well together and
> have only a local context, I'll apply a visitor-like pattern and I can
> control the scopes in the DSL.
Yes! Now you're cooking.
I think more things will work after a redeploy of nimforum. :-)
Boring: Simply "idiomatic". The context "for Nim" is usually implied.
Fun: "nimish".
We're always improving the documentation but here is a good rule of thumb:
**Whenever you need to analyse the AST, you need a macro.**
The oids module doesn't work for the JS backend, that's why.
> I think you confuse nim templates with template from another language.
Maybe not, but writing DSLs without learning macros is simply not a good idea.
Fixed with `--gc:arc`.
1 - 100 of 1662 matches
Mail list logo
