Re: Iterating over a Structured Type?
@dponyatov, following the links in the StackOverflow conversation you pointed out, I've found mentioned the Kaitai Struct (open source) tool: [http://kaitai.io](http://kaitai.io) That seems a good solution, with YAML-like definitions — and, from what I understood, you'd only have to write/port Nim support for Kaitai once, and then it could be used anywhere. Right now, Nim is not officially supported, but I'm sure that they'd welcome a Nim adaptation to include Nim in the officially supported langs.
Re: Iterating over a Structured Type?
Thanks @cdome, this worked liked a charm.
Iterating over a Structured Type?
Hi, I was hoping that someone might help me with this. Is there a smart way to iterate through a custom structured type and the determine the size of each of its elements? In practice, what I need to do is this: I have defined a rather big custom structured type which is going to hold data loaded from an external file. Depending on the OS endianess, I might have to change the byte order of its elements — this being the reason why I need to find a way to determine the byte size of each element. Ideally, I'd like to implement endianess correction with a loop of some kind, instead of having to manually fix the bytes of each element of the structured type, one after the other, which would result in a rather long code. Also, an iteration loop would still work if the structured type changes in the future, whereas the manual approach would have to be tweaked in this case. I'm trying to adapt some C code to Nim. The original C code does actually reverse the bytes of each element one by one, but I was hoping Nim could provide a smarter approach via some insights into the structured type — after all, Nim is famous for providing some amazing ways to do things which look impossible in other languages. It would be perfectly fine to do so at preprocessing or compile time, in case metaprogramming or Source Code Filters could help here.
Back to Nim vs V
Since the [Nim vs V language](https://forum.nim-lang.org/t/4758) thread was locked, I'll post here my comments, for I just came across it. @Araq: > Or maybe it's because Nim is more effective than V at solving the problems it > was designed to solve. Not everybody believes in programming **language > designer fascism**. Seriously? I come from an Italian family which has fought and suffered huge losses under the fascist regime, and I find your comment rather out of place and inappropriate. What's the political context that justifies using such a comparison? V-lang author is not acting under any mandate of State power that enables him to forcibly impose his ideas and works on anyone. How can you compare his open source efforts to the Italian and Spanish fascist regimes that incarcerated, deported and killed political dissidents and people which were considered unwanted citizens based on their ethnic origins or sexual orientations? Regimes which colonized other countries in the name of "racial superiority", leaving behind a mayhem of corpses, torture and raped women. Whether Alexander Medvednikov's views on what makes a programming language better than others are correct or not, or if he might have misrepresented Nim in comparison to V, can't justify describing his work as fascism. He is, after all, an open source developer devoting his time to a project he believes in, and which he has chosen to share with the world under a permissive license, releasing its source code so that anyone can challenge it, improve it, fork it. @Araq, I was quite surprised by your comment, and I would have expected a better example to be set by the main Nim developer. I'm not sure you realize the impression that reading such comments can create on visitors to the forum, but I invite you to consider the consequences of such stances. No matter how technically good a language might be, in order to become widespread it also needs a strong and harmonious community that thrives around it, where people feel comfortable writing and being associated with. And of course, any language also benefits from being presented at public events, receive funding and positive reviews from magazines and authors. I'm not quite convinced that exploiting highly charged political terms borrowed from history, only to prove a technical point in a dispute, might be the right way to go in terms of public relations with fellow developers in the field. As a general rule, developers tend to avoid political disputes for the sake of peaceful coexistence, and the industry doesn't like to be associated with political stances either, in the name of neutrality. While I do understand that you may feel compelled to defend Nim from any incorrect (or unjust) critiques, in virtue of all the time and love you've dedicated to its development; I can't condone similar comments. For some people terms like "fascism" and "nazism" don't carry a meaning, and they tend to use them lightly. But if you do use them, then you can't expect that people for whom these terms still carry a meaning in their lives, through their personal history, will just standby silently. Actions have consequences, and writing similar statements on a public forum is inappropriate, to say the least, and is going to leave a mark on Nim records if it comes from a Nim developer or is condoned by one. I do not think that Alexander Medvednikov is a fascist, nor that his works has any fascist elements in it, for I can't see any reflection of the horrors of those regimes in his work, quite the contrary. And I'm not going to be silent about this either, for similar comments belittle the magnitude of fascim by transforming it into a generic term to express disapproval. And since the V vs Nim comparison page was removed in the meantime, I couldn't avoid wondering if it this might have anything to do with the fascist labeling — personally, I would have removed the page after a similar reaction. @Araq, is this really the path that Nim forum is willing to take? Labeling other developers in disparaging ways only to affirm Nim superiority — which, by the way, is something on which most users of this forum already agree upon. Then, what next? Where is this attitude going to take the forum in a year time, if it becomes a commonly accepted practice? If we can freely label other developers as fascists, where's the limit? There have been already more than enough posts on Nim vs Rust — some of them of rather dubious constructiveness. Let's at least keep at bay the phenomenon, by at least avoiding to politicize it. Of course, focusing on Nim virtues would be preferable, but this option seems long gone already, for the whole debate of "us better than them" has taken momentum. I have never doubted the excellence of Nim language, from its very early stages it captured my attention, and it doesn't need to magnify itself by belittling other languages, for I believe that
Re: Nim Repository Template for GitHub
Hi @Araq, sorry for the late reply, > Hey, wait a second, I didn't say that! I said git shouldn't touch the > newlines. The reason I said "I've learned that..." is because of tools like c2nim output Nim sources with LF even on Windows (that was the original question on the repository Issue). Since you confirmed to me that using LF as EOL in c2nim is the expected behavior, then it makes sense to set Git to use LF on all Nim sources — otherwise one would have to create separate rules for manually coded Nim sources and sources generated by Nim tools. The EOL problem only affects Windows users, and unless the repository `.giattributes` file is properly set the risk is that Windows users might commit to the repository index files with CRLF EOL — which indeed would be a problem for Linux and macOS users. Unless explicitly set to LF, Git would normalize text files to the native EOL, which under Windows is CRLF. Unfortunately, the Nim documentation doesn't mention best practice regarding source files and EOL usage, so the various Nim editors extensions use different defaults (e.g. Sublime Text uses native EOL) — the whole idea in creating this template was to provide some ready to use presets, so any advise on how to improve it are indeed welcome. Quoting your reply to the original Issue: > The EOL convention is LF-everywhere indeed. And git should always be > configured to "don't touch the newlines" anyway, how else can you write tests > that contain CR-LF for Linux? The above can only be achieved by telling Git to normalize Nim sources to LF — if you use native EOLs then Git will indeed need to touch newlines under Windows and convert them at checkout from LF to CRLF. But the main issue is that sources auto-generated by Nim tools use LF, so it makes more sense to also adopt LF in the editor to avoid a double standard. Does it make sense?
Nim Repository Template for GitHub
I've created a [GitHub repository template](https://help.github.com/en/articles/creating-a-repository-from-a-template) for Nim projects: * [https://github.com/tajmone/nim-repository-template](https://github.com/tajmone/nim-repository-template) * [https://github.com/tajmone/nim-repository-template/wiki](https://github.com/tajmone/nim-repository-template/wiki) The idea is to provide a boilerplate for quickly creating new Nim projects with all the basic settings in place for any cross-platform project. This should be particularly helpful for Nim newbies (like me) who might not know all the Nim related file extensions that could show up in a project. For example, I've also added some GitHub Linguist attributes to indicate that `*.nimf` files should be considered Nim files in project statistic and syntax highlighting (the new SFF extension has not yet been added to Linguist). The template is far for complete, just an initial proposal. >From an exchange with @Araq, I learned that the best practice is to always set >Git to normalize EOLs to LF, even under Windows OS: * [https://github.com/nim-lang/c2nim/issues/171](https://github.com/nim-lang/c2nim/issues/171) Many editors packages for Nim use native EOL for Nim sources, and I haven't find any references in the official documentation regarding best practices for these type of settings in commonly shared projects. So I was hoping that this repository might be useful in this respect — it's Wiki is open to editing and can be used to provide guidelines. My original idea was to create the repository and then transfer ownership to the Nim-Lang GitHub organization, but then I realized you can only transfer repositories to organizations where you have enough privileges to create repositories yourself (I though I could simply request transferal, and the Nim-Lang org could accept or decline). Repository templates are a new GitHub features (June 2019) which I think is quite cool. Beside saving time when creating new repositories, the presets of a well designed template can also cover a variety of work scenarios, different compiler backends, etc.
Re: Extending Enumerations to Support Step and Binary Enums
@leorize: > Nim's version of bit flags is set[T], which is why enum with holes is not > needed here. Ah, I had missed that! Indeed, this is a cleaner approach than ORing and ANDing. Maybe a binary enum could be added as syntactic sugar to define the same in a less verbose manner then (at least, for single byte flags). @Stefan_Salewski: thanks for the exhaustive examples, they're really helpful.
Re: Extending Enumerations to Support Step and Binary Enums
@juancarlospaco: > I dont like the `EndEnumeration` on Nim. these are just examples pasted verbatim from another language, the focus is on how these keyword could simplify automatic steps in the enumeration values. I wouldn't like the enum closing keyword either (I prefer indentation too). @Stefan_Salewski > All your issues seems to be mostly relevant when using extern C libs with > wrappers. Yes, that's the case; and probably these proposed enumerations features are going to be most useful when writing wrappers and interfacing with external libraries. Especially when the enum elements are numerous, and inserting a new element in the middle would require rewriting all values manually (whereas autogenerated values via `steps` or binary enums would require no manual fixes. > Nim enums can behave strange when they have holes or start not by zero. I was > struggling with that for gintro, but we know that Araq recommends using plain > (distinct) int constants for this case. I've read about it, but I guess that it's unavoidable when working with external libraries, some times. The overall idea is to make the syntax friendlier when this is needed. But if this was to be counter to the general Nim philosophy I'd understand it. But I wonder then, aren't enums supposed to be helpful also for working with bit flags? so you can AND and OR together when handling settings parameters? In this case you can't avoid leaving holes in the enumeration. From what I understood from reading the documentation (and I might be wrong) the issue with having holes in enums is that you can't use some iterators with them if you do have holes. Again, it might then be good to have a special binary enumerator type, which would not consider them as holes but expect naturally the progression to be that of bit values (1, 2, 4, etc.), without loosing functionality like iterators, etc. This could be useful in many contexts, so it might be worth to have in core. > For your flags example, there we can use Nim's set[enum], which works fine, I > used that approach in gintro. Could you please provide a link to gintro, so I can look at your example in its context for inspiration? thanks.
Re: Future of Nim ?
@andrea: > It is easy to do TCO for self-recursive function. It is essentially not > doable in general, unless one controls the generated assembly... Tail recursion optimization is an interesting topic, do you have any links providing examples on how to do it in Nim? I wonder ... if Nim were to support labels to mark code positions and some kind of GoTo like statement, maybe tail-recursion could be worked around by them. But I guess this would add potential complications to the language, for you can't just use GoTo to jump in-and-out stack frames wrecklessly. Nevertheless, GoTo has been used to circumvent tail recursions in languages that support the instruction (the debate on the merits and dangers of GoTo have been debated for a long time). But that's a viable (unsafe) alternative to editing the generated Assembly, by jumping to specific position in the code.
Re: Questions about strscans library
The PR mentioned below should have solved it, but yes it seems there was an extra hyphen in the RegEx of the documentation — in `[A-Z-a-z_]` ->instead of just `[A-Za-z_]`, where the middle hyphen didn't represent a range but an hyphen char entity.
Extending Enumerations to Support Step and Binary Enums
It would be nice to extend enumarations by introducing the `step` keyword and binary enumerators. I'm basing this proposal on how enumerations are implemented in the PureBasic language, so I'll just paste a few examples taken from its documentation: [https://www.purebasic.com/documentation/reference/enumerations.html](https://www.purebasic.com/documentation/reference/enumerations.html) The `step` keywords would allow to adjust the step for each new constant found in the enumeration: Enumeration 20 Step 3 #GadgetInfo ; will be 20 #GadgetText ; will be 23 #GadgetOK ; will be 26 EndEnumeration Binary enumarators are practical for working with flags: EnumerationBinary #Flags1 ; will be 1 #Flags2 ; will be 2 #Flags3 ; will be 4 #Flags4 ; will be 8 #Flags5 ; will be 16 EndEnumeration I've found these enumeration variants quite practical to use, so I was wondering if something similar could be added to Nim core language. >From what I gathered from the Nim documentation, currently this can only be >achieved by manually specifying the step values for each ordinal value field — >i.e. unless I'm missing out some obvious way to do this.
Re: Questions about strscans library
PR created (other typos found): [https://github.com/nim-lang/Nim/pull/11408](https://github.com/nim-lang/Nim/pull/11408)
Re: Questions about strscans library
@Araq, a further clarification (might be a bug in the **strscans**
documentation).
The [strscans docs](https://nim-lang.org/docs/strscans.html) state that `$w`
"Matches an ASCII identifier: `[A-Z-a-z_][A-Za-z_0-9]*`.", but looking at the
[source code of
parseutils](https://github.com/nim-lang/Nim/blob/master/lib/pure/parseutils.nim#L23)
it seems that `IdentChars` does not include the hyphen character:
IdentChars = {'a'..'z', 'A'..'Z', '0'..'9', '_'}
IdentStartChars = {'a'..'z', 'A'..'Z', '_'}
Run
(same definition found in **strutils** too). The **strscans** documentation
seems to imply that the hyphen is a valid identifier character, but this might
be inexact — personally, I think the hyphen shouldn't be a valid identifier
character, as in most syntaxes it isn't so. I actually discovered this
discrepancy because I was looking for a way to reimplement it without the
hyphen.
If you confirm me that it's a documentation error I can fix it and make a PR
for it.
Re: Questions about strscans library
Thanks for the precious info @Araq. > Well in the end you have to benchmark but strscans doesn't do anything that > would be "obviously slow". It should be just fine. Then I'll go for it, for I like its syntax. My app being presently an alpha prototype, it should be fine to start with this library. Once it's stable I might try some benchmark comparison with PCRE and other regex libraries (including Oniguruma, which would be nice to create a wrapper for) and see if there is space for speed improvement. But right now I just want to switch language and keep the code simple. Also, I like the **strscans** approach. > nre is a controversial library and was scheduled for deprecation I see. Although I read about some of the bugs (which I though were solved) it looked interesting, its approach seemed simple and flexible. > There is also > [https://github.com/nitely/nim-regex](https://github.com/nitely/nim-regex) > which is a pure Nim implementation without the PCRE dependency. Ah, I didn't realize that, I thought it relied on the **pcre** wrapper. Interesting, I'll have a look at it thenPCRE.
Questions about strscans library
First of all, I'd like to express my gratitude and appreciation for Nim — I've been following the project since Nim v0.10 (more or less), although I've never managed to find enough time to dedicate myself to study the language and experiment with it as I should have (I even bought a very early MEAP of the excellent "Nim in Action" book). Finally, I'm now able to dedicate myself to learning Nim on an almost daily basis, and I'm starting to port to Nim some prototype projects which I had created with some quick-to-use languages, but now deserve to be reimplemented in a solid language. I'm really impressed by the philosophy behind Nim, and the clean syntax it offers. I hope I'll be able to contribute to the project in the course of time. Right now, I'm porting a project which relies on RegExs (the original code uses PCRE). After having looked at the impure **re** library and the **pcre** wrapper, as well as the **nre** library, and having compared them to the **strscans** library, I'm tempted to use the latter for my project, for it seems to cover all the pattern needs of my code (not complex patterns, but quite a lot of them). I like **strscans** because it's extensible, and simpler to use than any of the current PCRE solutions, and most of all is in pure Nim and doesn't require third party dependencies. I have a few questions though... Performance wise, how does **strscans** compare to PCRE based libraries? My project has to perform a huge quantity of pattern matching, so performance might be a concern if the difference is huge. Overall, I'd like to prioritize code usability over performance right now, but being a CLI tool that is used to process many input text files, I can't afford a significant degrade in performance, but I it's OK if the difference is marginal. Also, I wanted to ask about the **nre** library status. I've looked at its documentation and the GitHub issues linked therein, and learned that it's now part of the Nim Standard Library, but couldn't really work out its current status. What I don't understand is: why it's not linked in the documentation page for the StdLib? and why it resides in a subfolder of its own (`lib\impure\nre\private\`)? Thanks
Re: Question About Nim Grammar
Thanks @Araq, this was really useful info. > Specifically for Nim but it's generally useful, I hope. If I were to write a grammar-based parser generator, I'd definitely go for Nim's native grammar — Araq-BNF (I like the name!).
Question About Nim Grammar
I wanted to ask a couple of questions about the doc/grammar.txt file: * Is this the complete grammar of Nim? I've read on the forum that this is a custom grammar that was introduced to replace a previous EBNF grammar. * Has this grammar definition got a name? * Was it created specifically for Nim, or is it used in other contexts too? * Can anyone describe me its properties (e.g. context-free grammar, typology, etc.)? Since Nim uses this grammar, I'd like to learn more about it for it could be used to create custom languages in Nim too. The presentation of this grammar in the Nim Manual is very brief, so I was wondering if there are other resources dedicated to it, which I could study to learn more about it. Thanks
Re: Creating DLL With Nim Without nimrtl.dll?
Thanks a lot @Araq, I'll test this. Hopefully GC is not going to be an issue for the DLL is going to handle small data in memory. In worst case scenario, since it's a Windows only app I'll try to use the WinAPI to manage any problems.
Creating DLL With Nim Without nimrtl.dll?
Hi, I wanted to enquire about the creation of DLLs in Nim and the requirement to include nimrtl.dll in the final project. I've read in the compiler documentation that: > Nim supports the generation of DLLs. However, there must be only one instance > of the GC per process/address space. This instance is contained in > nimrtl.dll. This means that every generated Nim DLL depends on nimrtl.dll. [https://nim-lang.org/docs/nimc.html#dll-generation](https://nim-lang.org/docs/nimc.html#dll-generation) I was wondering if it's possible to create a standalone 32 bit DLL (no thread safety required) by tweaking the GC options — and, in case it was possible, at what price this could be achieved in terms of extra work to do. The usecase I have in mind is rather simple, the DLL is intended to communicate with the invoking app to exchange short messages via string pointers, and carry out some file operations and in-memory image data manipulation. Basically, the DLL is intended as an extension to an existing image application to add support for other image formats (save and load). I'd prefer not having to ship an extra DLL with it, so if there was a way to do without nimrtl.dll it would preferable. Thanks for all the support (please, bare in mind that I'm a Nim absolute beginner).
Re: Nim 1.17.2: nimble test Fails
Thanks @Araq. I tried out `nimble test` because it showed up in the commands help. As I said, so far most sources that I've tried to compile worked out. But I was worried about the koch tests showing a high number of failures for the Cpp tests.
Re: Question About Nim 32/64-bits
> Multilib IS supported thanks! So I did remember right (it's been really long I haven't used Nim, so I forgot most of what I learned). Basically, having Nim/MinGW x64 is the best choice, and I shall be able to compile x64 (natively) and x32 with options? But what about the Nimble example I gave above, and the fact that with Nim x64 you can't install Aporia? Isn't there a way to also tell Nimble to compile for x86? From Nimble documentation page I couldn't find any references on this.
Re: Nim 1.17.2: nimble test Fails
> Yeah, choosenim currently does not support 64bit. Then I'll have to wait. Is there an estimate about when it might support it? As for my setup, I'm really confused. I did follow all instructions, and GCC is available on PATH, and Nim too — and really, there isn't much to the setup to be done. I've compiled quite a few code examples, and they seem to work. Nimble succesfully installed dependencies. It's only the tests that fail (both Nimble and koch, the latter with Cpp tests mainly). So, somehow (from koch tests) it looks like there are quite a lot of test failures when it comes to C++. I'm not sure how bad this can be, but I guess that sooner or later I'll be banging against some limits. Could it just be that the tests are not tuned for Win 10 x64? Or, I wonder, if the Fall Creators Update introduced breaking changes... Anyhow, for now I'll play around with Nim some more, and go over the book exercises again; I'll still be benefiting from learning the basics. Of course, I can just move to my other Linux machine, but I was hoping to use Nim to create DLLs to use with other languages. To be honest, my worry is just that in the past I came across quite a few great and robust languages (like Haskell, to name one) that never seem to work 100% under Windows (there are always problems with some libs, dependencies, or compiling DLLs, etc.) despite the years they've been around in stable release. In the last years many huge leaps have been achieved in cross-platformness, and this is really great; but with Windows there are always pitfalls round the corner, and often cross compiling from Linux seems the better choice. Learning a new language (especially if it involves a shift in paradigms from the languages one has worked with) is already a challange, but when there are issues related to the environment then it's difficult to pinpoint if the problems are due to one's lack of knowledge or to issues with the OS. Thanks for the help Dom!
Re: Question About Nim 32/64-bits
> then I guess multilib it's not supported That's bad news! In theory, on Windows one could avoid adding Nim's `bin` folder to the PATH, and have different batch scripts to add it to the PATH for the current CMD env at usage time, this would allow to chose between Nim 32- and 64-bit. But the problem would remain for the `~\.nimble\` folder though! If there is a way to configure each Nim setup to have Nimble handle packages in custom folders, then maybe dual setup would be possible. I haven't found any references in Nim documentation regarding this; I would though it was a crucial question — If one wishes to publish a DLL for both x86 and x86-64 how is he going to do it? Maybe it's just me that I'm missing out something.
Question About Nim 32/64-bits
The other day I came across an Issure regarding Aporia failing to install via nimble on x64 machines (due to lack of x64 dependencies for Windows). This made me think: is it possible to have on the same machine Nim 32 and 64 bits? I thought that the compiling bitness was handled by GCC, ie: that you could compile both 32 and 64 bit binaries by choosing the architecture options to pass to GCC. But the above Aporia issue made me think that there are no such options when it comes to Nimble. So, is it possible to build both 32 and 64 bits binaries with Nim? Does is it require a dual Nim installation? And how can one handle that? Side note: I haven't put my hands on Nim for quite a long time: since v0.17.0 came out. I started out with quite some entusiasm with v0.15 (bought the book _Nim In Action_ and wanted to have a go at it), but then since v0.17 the installers weren't provided any longer, and had experienced trouble setting it up, so I gave up. This week I've decided to give it another try, and am facing again problems with the setup on Win 10 x64 (yes, I've followed all the instructions, installed all the files from the Windows download page, including MinGW, and did run `finish.exe`: Nim does compile, but if I run the tests they fail). Therefore, the question above is from a year-old newby, still struggling to get Nim up and running.
Re: Nim 1.17.2: nimble test Fails
Hi dom, > How did you install it btw? I've donwloaded all the x86-64 Zip files from the download page (including MinGW-w64). I've setup MinGW in "C:\MinGW\" and added it's "bin" folder to the path, then unpacked Nim in "C:\Nim\" and run "finish.exe". As I said, it can compile source alright. I've alsp run "chock tests" (not to the end, it took ages so after about an hour I had to stop it's execution). Most tests passed, a few skipped, but I noticed that many of the C++ tests where failing. > If not via choosenim then I suggest you give it a go. I didn't use choosemin because I'm not sure how it actually works. I've noticed in the source code that it seems to download only the x86 version of MinGW: [https://github.com/dom96/choosenim/blob/master/src/choosenim/download.nim#L15](https://github.com/dom96/choosenim/blob/master/src/choosenim/download.nim#L15) const # Windows-only mingwUrl = "http://nim-lang.org/download/mingw32.tar.gz"; dllsUrl = "http://nim-lang.org/download/dlls.tar.gz"; Does it always install MinGW? And only 32 bit? I'd like to have MinGW 64 bit, and available system wide, not only within Nim environment; I haven't understood how choosenim handles this.
Nim 1.17.2: nimble test Fails
I've just setup Nim v1.17.2 on Win10 x64, using the MinGW-w64 package downloaded from Nim download page. I've tested compiling various Nim examples, and the Nim compiler works fine so far. (before I had Nim v1.16.0, which came with an installer, so I've just uninstalled it and setup v1.17.2 manually, so chances are that I might have got something wrong). I've also added `%USERPROFILE%\.nimble\bin\` to my User Path — but I think this might not be required on Windows, since I've tried using Nimble without that on the PATH and it seemed to work just fine. Is it necessary on Windows? When I try `nimble test` I get this error: C:\Nim>nimble test Executing task test in C:\Nim\compiler.nimble Verifying dependencies for compiler@0.17.2 Compiling C:\Nim\tests\benchmark.nim (from package compiler) using c backend Hint: used config file 'C:\Nim\config\nim.cfg' [Conf] Hint: system [Processing] system\alloc.nim(4, 1) Error: undeclared identifier: 'assert' Error: Execution failed with exit code 1 Is the above Error something I should worry about? does it mean my setup is not good? But Nimble seems to be able to carry out all other operations fine, I've even downloaded some packages without problems. Also, from the [Nimble documentation](https://github.com/nim-lang/nimble#configuration) it seems that I should find Nimble configuration file here: C:\Users\\AppData\Roaming\nimble\nimble.ini ... but there is no `nimble` folder inside `\AppData\Roaming` .
Re: Installation on 64-bit Windows
I've managed to find a link I knew I had in some folder. Now, no one specified if this solution had to be FOSS or could be commercial, so don't take it the wrong way if I'm posting a link to a commercial software: [http://www.deploymaster.com](http://www.deploymaster.com)/ I remember that I had a very good impression of this tool, and its developers are known for some other very well known software tools. Now, if the issue is making life easier for Nim maintainers, and what is needed is just a tool to create and maintain good Windows installers without headaches, and there are no problems regarding using a non FOSS software, I would be happy to sustain Nim and contribute buying a license for this app for the maintainer of Nim setup generator (if I've understood correctly, that would be @Araq). Right now its a diffcult moment for me, and I can't go to the length of covering the full price (€80), but I could cover a third of it and I'd be happy to. Of course, this could be a temporary solution, until a Nim-based setup manager will be ready. But the priority being right now to reach Nim 1.0, using this tool could provide some respite and lesse headches. Also, I'm rather confident that Nim being a FOSS project, we could expect some discount on this product. Worth asking. (of course, assuming it suits the needs of the maintainers)
Re: Installation on 64-bit Windows
I totally agree with keeping the number of official ways to install Nim to a minimum. And I also believe that unofficial solutions might be detrimental in the long run (for example, the unmaintained Choco Nim package didn't bring much good to those who installed through it). @dom96 wrote: > Over time this [setup] wizard has become more and more complex, NSIS and Inno > setup are simply too much of a PITA to maintain properly so I'm not surprised > that Araq wants to get rid of it. [...] > I would really love to write a > custom setup generator for Windows in Nim. This may even be a killer feature > for Nim because the current solutions are just plain crap. and @Varriount: > The old installer used NSIS, which is a headache to deal with (the installer > is built using the NSIS language, which closely resembles assembly and a > declarative language). > > Anyway, does anyone know some alternative that we might try out? I know that > we've tried WiX (too much XML), NSIS (too much assembly), and Inno (way, way > too much programming needed). Any others? So (just trying to understand and see if I could help here), the problem has to do with the software used to build the installers, right? I could so some research in this and see if something more user friendly could be used, taking in consideration that new features/components should be easily integrated. Dom's idea of creating a setup generator in Nim is far the coolest. Surely, it will add maintainance of the generator itself, but sounds worth it since it would taylored to Nim's needs (and, of course, a reason of pride for Nim itself). > The alternative ways to install Nim might grow a new feature (e.g. choose > between Aporia and VS Code Plugin) I personally think that Aporia should have a separate setup. True, for the first-timer it's nice to have a single setup, but they are two separate products and they might update at different intervals. If we are speaking of an installer "the Windows way" it should then also provide an uninstaller, and the catch might be that to uninstall just Aporia you end up uninstalling Nim or, worst, the manually overwritten files (in one or the other) get busted because of an update that affects both.
Re: Installation on 64-bit Windows
I only partly agree with some of your points, though. True, Chocolatey is not part of Windows, but it was the first attempt (that I know of) of creating some packages manager for Windows, like apt-get on Linux, and similar. So the statement: > The main feature of Windows is that software can be installed without much > trouble. is true only for software that comes with an installer and has some update mechanism. But I think that Chocolatey success is also due to the fact that it provides a centralized place to check if installed software packages are up-to-date (again, on Linux distros like Ubuntu you have this feature with package manager frontend). As far as I know, Microsoft has no plans (and never had) to implement any third party packages manager (they only invest in their own products). True, the proposed solution will mainly help Chocolatey users, and **will** introduce a new burden on Nim developers. But, if I understood correctly this thread, the issue rotates around the recent news that Nim might no longer ship as a Windows installer in the nearby future, only as a ZIP archive. An there was mentioning of the fact that developers are currently struggling maintaining the setup version (NSIS et als). So, really you should contextualize better my proposal. > But I don't want to write PowerShell scripts. As I wrote, I was happy to contribute to the first "original" PowerShell script (note the singular), and my proposal was centered around the idea that the Choco package should be automated and self-update with new Nim releases, requiring no further scripting. > Every officially sanctioned way to install Nim needs to be tested, for every > single release. But this is true for _any_ solution, whether Nim script, Chocolatey, or else! > Right now we support: > > * installation via the installer.exe. Again, the question ensued from the official announcement that has been placed along the latest release of Nim: > Note that these installers have some known issues and so will unlikely to be > provided further in the future So, ok --- Chocolatey being a big "No!No!" for some reason I can't phatom ---, we get back to the point of the future of Nim packages for Windows. > ... I'd rather write Nim programs instead. Makes a lot of sense (I'm afraid I can't contribute here though), I just didn't know there were plans in that direction. All I've read on the download page is that installers might soon stop being released, and that the official guidelines are: > We now encourage you to install via the provided zipfiles Again, I don't want to insist but I must: this whole thread started from end users' considerations that presently setting up Nim through zip archive does pose some complications (to _real_ and _unreal_ programmers alike, apparently). I can't avoid thinking that my proposal was dismissed a bit too hastly. I too, like @mindplay have a some programming experience behind (35 years), which if it taught me anything at all that would be that computing is a wide field and there are paths which one might simply never cross if he works in a given field "X" rather than fileds "Y" and "Z". I've started only recently to use Linux software that has been ported to Windows, and I don't have problems admiting that sometimes seting up the right working environment can be puzzling. And I don't think it has anything to do with being _real_ or _bogus_/_wannabies_ programmers --- often it has to do with lack of field-specific experience, or lack of well written documentation. Anyhow ... it's fine. I'll just go for the zip archives and whatever Nim shall offer in the future — frankly, I don't have all these problems seting up Nim from a zip archive. I have more difficulties handling scattered updates (Chocolatey took away 1/2 of the burden through a single GUI that notifies me of new updates for dozens of packages) — but of course, this is _me_, my likes and dislikes, my problems and views.
Nim for Windows: MinGW vs TDM-GCC
I want to start a long-lasting thread that could gather info on choosing a GCC compiler — including information on GCC updates. * [MinGW.org](http://www.mingw.org/) * [MinGW-w64.org](http://mingw-w64.org/) * [TDM-GCC](http://tdm-gcc.tdragon.net/) * [GCC.GNU.org](https://gcc.gnu.org/) I've more than once found suggestions that using TDM-GCC has advantages over MinGW. I've installed TDM-GCC x64, and so far so good it's working fine, but admitedly it comes with a rather old version of GCC: 5.1.0! Currently, official GCC is in v6.3 [2016-12-21]. TDM-GCC was last updated in July 2015, and ships with GCC v5.1.0. But what about MinGW? I find it confusing that there two separate MinGW projects, and from what I understood there isn't much comunication between the two projects (for historical reasons). My guess is that MinGW-w64 is presently the most widely used version, but I find its website (both actually) not so friendly to the "uninitiated" \--- I've spent quite some time reading through it, doing research and taking notes, but when it comes to choose which package to download I'm never quite sure about. Currently, MinGW-x64 lateste release is v5.0.1 (2017-01-06). Does the 5.0.1 point to the GCC version? If so, it would mean that it lags behind TDM-GCC by one minor version. I would also like to see here some explanation of the advantages of TDM-GCC over MinGW — ie: that was in 2015, are these advantages still relevant today, or do the new versions of MinGW64 already solve the issues that TDM-GCC proposed to solve? Was the TDM-GCCproject abbandoned because its reasons d'etre ceased to be due to some changes in MinGW64? If I've understood correctly, one of the main advantages of TDM-GCC was that your final compiled binaries would need no dependencies (MinGW DLL's, etc). Is that right? Is it still so with current versions of MinGW? Can someone provide here some more information about similar issues, and also explain better which version of MinGW/GCC Nim setup for Windows offers to install. Hopefully this thread could become a reference to dissipate confusion regarding GCC on Windows, for Nim. I could even edit this post as new packages are released, so that the the head of the thread always provides updated info.
Re: Installation on 64-bit Windows
As I've posted elsewhere ([http://forum.nim-lang.org/t/2679#16589)](http://forum.nim-lang.org/t/2679#16589\)), I think that a good solution would be to use Chocolatey. There is already a Nim Choco package, but it's way unmaintained: [https://chocolatey.org/packages/nim](https://chocolatey.org/packages/nim) The advantages of Cholocolatey are that its already a well-established app for installing updating all sort of packages that don't come with an installer, and offer the final user a single interfact (ChocoGUI) from which to update all packages. I use it to update Ruby, Node, Go, and other langs, which is much better than having to manually check via the browser if a new release is available, and then go through the whole setup process. Since Choco packages are executed silently, there is no clicking YES, YES, YES ... YES at each update to confirm existing settings. But his also means that a Nim package would have to be thought over carefully, for example: I think tha Aporia IDE and MinGW shouldn't be in the main Nim package because in silent installation the user is not given a choice over these. Maybe multiple Nim packages could be created: Nim 32bit, Nim 64bit, Aporia, and even a Nim package for installing MinGW or TDM-GCC --- which would solve the main issue that started this thread, ie: offer users help on setting up a GCC environment on Windows. I believe that we need an official Nim packages on Chocoloatey, to avoid having yet another umaintained package. Also, since Choco packages are just Powershell scripts, usually hosted on GitHub, the whole process could be integrated into Nim's release cycle: when a new version of Nim is released, some script could automatically edit the strings in the choco-package to the new release number and download link, and push a commit to GitHub and (I guess) even update the package on Choco website. I am convinced that Choco is the easiest solution to maintain, and since it is normal that a software has different choco packages, it would allow to create different setup scripts, covering all possibile needs.
Re: Installation on 64-bit Windows
I've downloaded the old Nim Chocolatey package (this on isn't on GitHub), unpacked it and peeked inside it. This is the core of the package (chocolateyInstall.ps1 script) $packageName = 'nim' $version = '0.11.2' $fileType = 'exe' $installArgs = '/S' $url = 'http://nim-lang.org/download/nim-0.11.2_x32.exe' $url64 = 'http://nim-lang.org/download/nim-0.11.2_x64.exe' Install-ChocolateyPackage $packageName $fileType $installArgs $url $url64 As you can see it's not a great deal of code. Of course, this one relies on Nim setup, but Chocolatey can handle unpacking archives and do all sorts of operations with it — PowerShell does a good job at setting env-vars, registering apps, and anything else Windows-related. Creating a template and implement some preprocessor that updates the strings for Nim version, the various download URL, ecc., should be a piece of cake. Using GitHub to host the Choco Nim package might also make sense, because GitHub API could be used to further automate the process of updating the package(s). But in my opinion it only makes sense if it's going to be an officially maintained package, strictly integrated into the release chain. I'm no Choco/PowerShell expert, but I've enough experience on Windows OS to say I could look into Chocolatey documentation and contribute to create and test a base Nim package that installs Nim from archives instead of an installer. But all the rest -- intergrating it into the release chain, implement a template system to autoupdate the packages, ecc, -- would have to be taken on by someone from Nim's dev team. Also, most important of all, the registration of such a Nim package on Chocolatey (and its correspective GitHub repo) would have to taken on from dev team. What do you say, does it make sense?
Re: Chocolatey Package for Nim?
I think that it would have to be some kind of "official" package, maintained by the same group that maintain Nim releases — that is to guarantee that it doesn't get abandoned. I also have the impression that this would speed up the process of having Choco-packages updates approved sooner by the admins. Possibly, maintaining the Choco package could be automated with some scripts — some strings changes, like version and download links. For Nim maintainers it should be possible to integrate it in the Nim release chain, having the new Choco package updated and pushed on a GitHub repo, and so on.
Chocolatey Package for Nim?
I've Nim 0.15.2 announcement I've read that: > For Windows we now provide zipfiles in addition to the NSIS based installer > which proves to be hard to maintain and after all these months still has > serious issues. So we encourage you download the .zip file instead of the > .exe file! and in the download page: > You can download an installer for both 32 bit and 64 bit versions of Windows > below. Note that these installers have some known issues and so will unlikely > to be provided further in the future. I was wondering ... it's been a while that I've installed Chocolotey and use ChocoloteyGUI to update a number of software packages which don't provide a self-updater — included some languages, like Ruby, Node.js, Go, and others. I've found a Nim package on Chocolatey, but it hasn't been updated in a while, and it's still at Nim v.0.11.2: [https://chocolatey.org/packages/nim](https://chocolatey.org/packages/nim) But I think that the idea of maintaining an official Nim-Chocolatey package could be a good idea for Window versions of Nim. The only issues at hand here would be: 1. Who's going to create/maintain it 2. Which default setting to use in a silent installation As for point (1), I think what we need is that there should be either an "official" package (maintained by Nim devs) or at least a package which has the official blessing of Nim devs. Point (2) is a bit more tricky though. I think that a Nim package should only install Nim, its docs, ecc. Aporia and MinGW should be taken care by the users. For example, I don't install MinGW, I use TDM-GCC (might be a bit old, but seems better configured). Chocolatey does a good job at telling users there's a new version of the package, installing it silently and taking care of all the boring stuff. What's the general view on this? And, does anyone know who created the Nim package linked above? The only info I've found is that it was maintained by a user called "pine613", but his GitHub account has been discontinued. Anyhow, the counter on Nim-Chocolatey package says it was downloaded 117 time for Nim 0.10.2, and 106 times for Nim 0.11.2 -- a total of over 200 downloads, which is rather promising if you think it was a short-lived and unmaintained package.
Re: Nim in Action is now available!
Hi @dom96, I bought _Nim In Action_ a few monthes ago (it was still MEAP v.8), a few days after install Nim. I didn't yet find the needed time to study it inside out — too many project to finish to dedicate myself full time to Nim — but from a first reading I have to say that the book is really great. And I really advice everyone interested in Nim to go ahead and get it. Hopefully, now I'm getting a few projects out of the way and I shall dedicate myself to seriously explore Nim. Can't really imagine doing it without _Nim In Action_ though! Best regards, Tristano (Italy)
Re: Help With Nim Static Libs on Windows
Thanks Araq. In the end I guessed it was related to stdin/out because I grepped "fileno" into GCC's header files and it came up in the context of filesystem related constants. Mhhh ... so I might be getting away with a simple Fibonacci function, but get a crash with more complex stuff! I've read many posts of people having problems importing static libs into PureBASIC under Windows, and that using DLL is always simpler. But in this case I was trying to experiment with static libs. I've seen on PureBASIC forums that often errors similar to the ones I got were related to a missing system DLL (like some specific version of MS Visual Studio redistributables, ecc.) and was solved by importing the required DLLs along with the static libs I guess that I'll eventually get a grip on this, with more practice and insight into the nebulous world of all these trans-compiler operations --- I mean: s many options just for GCC compiler alone! it's east to get lost in this configuration/compatibility jungle. ;)
Re: Help With Nim Static Libs on Windows
SOLVEEED! I've solved it by telling PureBASIC compiler to pass this option to polink: /EXPORT:fileno I haven't yet understood what was going on. But I do understand that his option exports the "fileno" symbol, which was the only one left in the error reports. Can anyone help understand why this symbol was missing, what it refers to? Shouldn't Nim have taken care of it? Or does Nim give for granted that some C code importing the header files will handle it? It seems such a small issue, yet it kept me turning in circles for quite a long time...
Re: Help With Nim Static Libs on Windows
Hi @Krux02, No, I didnt. PureBASIC only uses "polink" and "porc" and "polib" from the Pelles C -- and they seem to be from different version releases also. PureBASIC has its own compiler + a FASM compiler. Unfortunately the documentation doesn't provide much help (actually: none) when it comes to these deatails. But it says it should handle any C library alright -- but then, again, PureBASIC is cross-platform but has a single documentation, so it might be referring actually to Linux or Mac. But I'll try to look into Pelles C documentation, hoping it might help. Would you have any idea what this 'fileno' unresolved symbol might refer to? The other two went away when I disable debugger support in the final lib, so maybe this symbol could also be resolved by either including and extra (required) lib, or by an extra compiler option of sorts... B.R.
Help With Nim Static Libs on Windows
Hi everybody,
this is my first post here — nice to be onboard!
I've been experimenting with Nim and I really enjoy it.
I'm working under Win 10 x64. I don't use MinGw compiler suggerst by Nim
installer, I instead use TDM-GCC, which is working very well.
I've tried to create libraries with Nim to use with another language:
PureBASIC. So I started with the Fibonacci example from the documentation.
With the DLL everything went fine: compiled, imported the DLL in my PureBASIC
code and I've accesed the fib() function from the DLL easily.
With the static library I'm experiencing some difficoulties and I really don't
know what else to try. I am no C expert, nor I know deeply GCC, but so far I've
managed to compiler quite a few C projects without problems.
PureBASIC can include C libraries with either stdcall (the default) as well as
not stdcall -- it auto-decorates them, the former as _FunctionName@callsize,
the latter as _FunctionName. But on x64, it has only one calling convention
(stdcall, I seem to understand).
It can import function from a library (.lib) or an object (.obj) file.
When I try to import the static lib functions I get an error from Pelles C
polink (used by PureBASIC compiler):
POLINK: Unresolved external symbol 'fdopen'
POLINK: Unresolved external symbol 'fileno'
POLINK: Unresolved external symbol ''__strtod'
I am compiling the Fibonacci Nim example with:
nim c --app:staticLib --noMain --header fib.nim
And I get a "fib.lib" file -- which I gather should be the static lib, not
needing any dependencies.
I've tried changin in the Nim source the "exportc" pragma:
proc fib(a: cint): cint {.cdecl, exportc.} =
if a <= 2:
result = 1
else:
result = fib(a - 1) + fib(a - 2)
and:
proc fib(a: cint): cint {.stdcall, exportc.} =
But both failed...
What am I missin out/doing wrong?
Any hints to unlock the situation and set me in the right direction would
really help!
Thanks
Tristano (Italy)
