Re: What are you writing using nim? :)
> Last time I checked Python's implementation, Python's slices also do copy,
> but it's not a problem because people believe they don't copy and beliefs
> tend to win over facts.
They do copy, as far as I know, but I'd not be so sure about make-it-true
power. For some time I was sure slicing makes a view in Python that I used:
arr[lb:hb].sort()
I was pretty sure it actually will sort a slice until tests failed.
> I think submodules are a strange idea and most languages (Python included) do
> fine without.
Please take a look at the thread about submodules I created. I wrote it after
rewritting a project of mine to use import and export rather that include
(which took me some time as it has many files) and saw the docs look nowhere
like what I would like them to look like.
> Moving is actually easy enough in Nim but zero-copy slices cannot be moved in
> any language since it's pretty much a logical impossibility.
If you mean shallowCopy, it'd love it to actually behave like moving. I was
sure it does but recently I got a runtime error because of this assumption.
Maybe a compiler bug though.
About not being able to move zero-copy slices: logical error here, actually.
Zero-copy slices are views, either mutable or immutable. The view itself can be
moved, it just doesn't move the data it points at. Alternatively, there can be
three kinds of slices defined: immutable view, mutable view, slice-entry. The
last one can do all the mutable view can do and also extend the slice or shrink
it (even to zero length). Of course these operations actually affect original
container, e.x. an seq has to move the data after the slice's end in memory.
Also, Python is not a good example here, I'd say. As you know, it's not really
an efficiency-focused language.
> More importantly, which libraries would you need?
As for now, not so many, actually.
Firstly, hdf5 (and h5part). I know it can be ported but as far as I know, Nim's
VM can't handle non-pure code (or did it change?) and I tend to use
metaprogramming a lot. Today I was frustrated that I couldn't find any way to
access a const passed to a macro (so I could, e.x. access elements of a const
array), so I guess it shows just how weird things I tend to use (maybe you know
the solution?). Here, I'd like to be able to recursively build a type-safe data
structure with fields named and typed after hdf5 files' groups.
Secondly, lots of optimization goodies, like advanced autovectorization. I had
a look at qex ("A talk on HPC" thread) and hope jxy will publish some of his
stuff as it seems a good base.
Re: Nim newbie request/challenge
The problem with installing seems to have to do with executables not in correct bins. I can go through the install process off the website, and compile the executables in the **nim-0.17.0** directory, created by untarring the tarball. Notes about installation from source After downloading the compressed archive, extract its contents into the desired installation directory. Open a new terminal window, cd into the extracted directory, and execute the following commands: sh build.sh bin/nim c koch ./koch tools Configuring the PATH environment variable The compiler and tool binaries live inside the bin directory. It is common for Nim developers to include two directories in their PATH environment variable: the aforementioned bin directory ~/.nimble/bin (where ~ is the home directory) I've had no luck setting the **PATH** that works, because it gives error messages saying it can't see certain files(?). When I set **PATH** like this: $ export PATH=$PATH:~/nim-0.17.0/bin when I try to compile a source file I get this: ~/nim> $ nim c --cc:clang --d:release x.nim Hint: System[Processing] Error: cannot open 'usr/local/lib/nim/system.nim' I can run the nim executable like so, from **nim-0.17.0/bin/**: ~/nim-0.17.0/bin $ ./nim c --cc:clang --d:release ~/nim/ where the **nim** directory holds my nim sources, but this is so inelegant! Luckily, Manjaro and Antergos (both Arch Linux derivatives) have the latest 0.17.0 version in their repos, so I've just been using them (this is using Virtual Box VMs). I even tried moving the executables around in the other distros to match what I see in Manjaro, with no luck. I am willing to help debug this if you give me detailed instructions to follow.
Re: A talk on HPC
Well, all of the ones mentioned in the pdf, that's for sure. I also noticed you use some nice metaprogramming utilities, e.x. the ones from metaUtils.nim file. I didn't read all of your code so I can't really know what functionalities are separable.
Re: Been away for 9 months. What changed? Need some help to get back on track.
Most programming today is incredibly bureaucratic. Nim makes programming fun again and does away with a lot of the beaurucracy, the way Python and Lua do; But unlike Python, you don't have to give up static typing, fast runtime, ease of distribution. For now, compared to Python, you give up some aspects of the REPL, and the ecosystem (many packages, a lot of documentation) but I think both of these have improved tremendously.
Re: Nim newbie request/challenge
Can we get a bug report for (6)?
Re: Nim newbie request/challenge
I've been translating various versions of the SSoZ I did in C++ in 2014 to Nim. Here are a few of my observations as a newbie. 1) Nim is much less noisy to write code in, with much less syntactical requirements to worry about (curly braces for if|for statements, etc). 2) Once I figured it out, it's a (just) little bit easier to satisfy integer type unification for doing math. But why can't you just add an **int** to an **uint** without having to manually explicitly cast the numbers. Can't the compiler figure this out? 3) Nim executables are either approxiamently 4|5x (with clang) or 6|7x (with gcc) larger than for C++ for some programs, though I can make them smaller using **strip** on them. 4) However, the Nim executables produce faster runtimes, and run to completion in some cases (for Nth Primes for example) where the comparable C++ throws a runtime Segfault error for the same inputs. 5) Nim is definitely easier to learn than C++ (because of the lower syntatic noise and more robust language paradigms, such as with **for** loops, etc), if you already know how to program (it's easier to figure out). Being young and growing (not 1.0 yet) it doesn't have the level of documentation you can find for C++, nor example code, etc, but the new book will help with that. I would highly recommend, and urge, a significant effort be put into creating as much (good, helpful, relevant) documentation as possible, especially to answer all the low level newbie questions, to attract people who want to try using Nim for really serious stuff. 6) The Nim installation procedure on the website failed to intall Nim on a number of distros (KDE Neon, LinuxMint, Kubuntu, PCLinuxOS) I tried. Even though the Ubuntu derivatives have Nim in their repos it's version 0.12 (not latest 0.17). Please provide instructions that will work, and/or create an AppImage, Snap, etc package to make installation universally simple. Below are the gists source code for my Nim translations of the original C++ implementations of the Segmented Sieve of Zakiya (SSoZ) using the P5 prime generator in each instance (I've done version with P7 too). These are sequential implementation. The main reason I'm interested in Nim is the potential to (easierly) implement these in parallel (than with C++, Rust, Julia, Python, etc). I've rearchitectured the memory model to make it parallel friendly, and now just need to figure out how to play with Nim pointers (and whatever else) to accomplish this. All in all, I see alot of potential for Nim as it matures. Gist files of Nim code of SSoZ versions, transated from C++. **ssozp5.nim** Find the primes <= N, using sequential implementation of SSoZ with P5 prime generator. [https://gist.github.com/jzakiya/94670e6144735eb0041919f633d6011c](https://gist.github.com/jzakiya/94670e6144735eb0041919f633d6011c) **nthprime_ssozp5.nim** Find nth primes, using sequential implementation of SSoZ with P5 prime generator. [https://gist.github.com/jzakiya/aff4f2e38f9b0f833955b4cc391de3d4](https://gist.github.com/jzakiya/aff4f2e38f9b0f833955b4cc391de3d4) **twinprimes_ssozp5.nim** [https://gist.github.com/jzakiya/776b7aae3126168b4cad90de9adc4961](https://gist.github.com/jzakiya/776b7aae3126168b4cad90de9adc4961) Find twin primes <= N, using sequential implementation of SSoZ with P5 prime generator.
Re: Bug with generic methods?
> These are two models, inheritance and type classes, which are different > answers to the same problem. I can see no good reason to provide both in the > same language.. I see one difference: with concepts the type match is an implicit one, the person creating the matching concrete type doesn't even have to now that the concept exists. With inheritance, it is explicit: the creator of a derived type explicitly mentions the base type in the type definition. This implies that he is aware of the semantics that cannot be checked by a compiler. A concept match checks that, e.g., a certain proc is defined for the matched type. The creator of that proc never promised that this proc will actually do what we think it will.
Re: meta programming a nice SIMD library
Here's a SIMD library [https://github.com/bsegovia/x86_simd.nim](https://github.com/bsegovia/x86_simd.nim)
Re: Been away for 9 months. What changed? Need some help to get back on track.
Leaving aside the discussion about fav lang, One of great additions is this PR, [Fixed “RFC: improving JavaScript FFI” (#4873)](https://github.com/nim-lang/Nim/issues/4873) Not to underestimate other stdlibs, improving JavaScript FFI should yield practical purpose, unrelated to whether people like JavaScript or not. `jsffi` module is very nice lib There's also [bitops](https://github.com/nim-lang/Nim/blob/devel/lib/pure/bitops.nim) module.
Re: Editor profiles fo Nim
Notepad++ from version 7.5 has embedded support for .nim files (syntax highlighting and code folding). NB: in release notes for 7.5 Nim still is called Nimrod
Re: Compile Nim on centos 5
[https://github.com/nim-lang/Nim/pull/6299](https://github.com/nim-lang/Nim/pull/6299) I tried hard to get my company to upgrade the GLIBC that we use when we build for customers, but they want to wait a few months. So we really need this change, or some alternative.
