cb321

49 ms·

511.
by cb321 4y ago
In more recent versions of Nim than covered by that 2015 tutorial you can, in fact, simplify that to `nim r helloworld` (without the .nim extension). Dropping the `r` part entirely would require (at least) not dropping the `.nim` part. Oth
512.
by cb321 4y ago
I am a bit surprised with all this commentary that no one has yet mentioned the two variants of Planck's constant - the original one in terms of cycles (turns, here) and the hBar=h/(2pi) that winds up being more common. Questions
513.
by cb321 4y ago
FWIW, I did a straightforward impl in Nim that was ~10X faster than the Python version in your repo.
514.
by cb321 4y ago
As in so many measurement/benchmarking situations, "compared to what?" is indeed The Big Question. For example, you can also compare to a C program not doing much, overhead-wise: /usr/bin/time bash -c &#x
515.
by cb321 4y ago
There is also even a vim-like editor written in Nim called "moe": https://editor.moe/
516.
by cb321 4y ago
Hrm... $ qlop -tvm|head -n1 2007-01-18T19:50:33 >>> x11-base/xorg-server-1.1.1-r4: 9′23″
517.
by cb321 4y ago
For what it's worth, you need only type "nim r n". If "n.nim" is marked executable and begins with "#!/usr/bin/nim r" then you also need only type "n.nim".
518.
by cb321 4y ago
Nim has for a long time had automatically managed `ref` as well as manually managed `ptr` which is similar to (perhaps directly inspired?) your last comment, and has several options for Auto Mem Mgmt.
519.
by cb321 4y ago
I like your focus on better questions. "those topics and any other that come up" was especially vague as was "semi-unknown". ;-) FWIW, I doubt anyone was suggesting "large scale applications programming in C".
520.
by cb321 4y ago
Most well vetted material you will find on this will use regular old C, not Nim, like that Bryant & O'Halloran Computer Systems from a Programmer's Perspective mentioned in a sibling comment. It probably won't rely on C
521.
by cb321 4y ago
You/the abstract round down - deeper table in the paper says 1750X faster. :-) But really it's a big 1650X..2020X range for the 25th to 75th percentiles.
522.
by cb321 4y ago
You aren't merely "disagreeable" as you exhibit yet again. Feeding trolls is also against guidelines. So, good bye.
523.
by cb321 4y ago
> Python hack doesn't do what you thought it did Your rate of misreading & over-attribution with the seeming intent to inflame is high. Trying to be enough of a troll to rollback a bit the perception Rust has a welcoming communi
524.
by cb321 4y ago
>> one problem {i.e. "insufficiency of arsenal" in your lingo} > Erm, no [..needless snark, insinuates I'm confused.. proceeds to largely restate Smith's article and himself, though a little better this time; G
525.
by cb321 4y ago
As I said, others complain about break & return. Defanged to you is not defanged to others no matter how often/consistently you say so. The statement & many of its claimed problems persist. Call the remaining problems claws
526.
by cb321 4y ago
I never said "should" . Really. All I said was descriptive not normative. I explicitly gave examples where trade-offs could shake out various ways. My strongest positive claim in this whole subthread might be "lack of co
527.
by cb321 4y ago
I am no expert on Ada, but it was probably inspired by Dijkstra's 1965 Cooperating Sequential Processes with his "parbegin/parend" additions to Algol 60. Or perhaps by the wildly popular Communicating Sequential Processe
528.
by cb321 4y ago
> flexibility you desire so much .. (aside from you apparently) Not only did I never advocate for broad usage, I explicitly said I didn't (as did @_ph_) and never expressed some love for goto or even "keeping it" whatever
529.
by cb321 4y ago
I'm not sure what your point is other than to elaborate constraints upon my examples. I never said it was "safe", "well defined", or even a "good idea". Only "available" and that this is an imp
530.
by cb321 4y ago
setjmp & longjmp still exist in C/C++. A great many latter day prog.langs also still allow assembly with its jump-oriented constructs. Lack of possibility is simply not the same as lack of use. Lack of use or even just lack of c
531.
by cb321 4y ago
In support of your point, this largely tracks way the "goto statement" shakeout has largely gone down in a number of programming languages over the decades - "available but discouraged" as in " Please do not write
532.
by cb321 4y ago
TL;DR - the article seems to invent its own terminology for what many others might know as (roughly) "OMP parallel for" or a fork-join pattern [1] or even in POSIX shell a "a & b & c & wait" pattern. IIRC, t
533.
by cb321 4y ago
As with most things, "it depends". If you compile very macro compile-time virtual-machine heavy code that can be slow. If you compile to the c++ backend then that backend process can be slow. If you invoke some macro that gener
534.
by cb321 4y ago
For HN folk, it may not be so obvious from the blog post, but the author of this book is the Nim originator/technical lead/primary author to this day { since before 2008 publicly and I believe 2005..2006 privately }.
535.
by cb321 4y ago
The link imbalance section of the HotOS paper discussed in the blog post reminds me of issues with regular old TCP discussed in, e.g. https://dl.acm.org/doi/pdf/10.1145/633025.633035 (as does the mention of c
536.
by cb321 4y ago
Ah. I misunderstood your "persistence" to mean "persistence of logs" not "of code/illicit powers". Sorry - I read too quickly. I do think the defense mentality, as evidenced by many comments in this thre
537.
by cb321 4y ago
I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B. https://github.com/c-blake/kslog has maybe
538.
by cb321 4y ago
Most writing style rules are context-dependently apt. The quote by Disruptive_Dave of Gary Provost rings true for artistic writing. Sentence length limits are more helpful for technical writing like papers/documentation, with its man
539.
by cb321 4y ago
Not sure what you want to test, though I'd bet that if you post questions on forum.nim-lang.org then you will get good help. Anyway, to maybe get you started, Nim compile speed is usually best with a tcc backend (nim c --cc:tcc or set
540.
by cb321 4y ago
https://github.com/c-blake/cligen can make the CLI integration part pretty frictionless.

More ›