Possible downtime
I will be migrating nim-lang.org to a new server over the course of this weekend. You may see some downtime, especially on this forum (depending how quickly your DNS changes propagate).
Re: Chocolatey Package for Nim?
With the same argument, it would also be necessary for Nim to have an official package for debian, Fedora, Arch, Nix, Homebrew… I think maintaining packages is in better hands with those people who use the package managers.
Re: Chocolatey Package for Nim?
I maintain the [Nim package](https://github.com/lukesampson/scoop/blob/master/bucket/nim.json) for [scoop](http://scoop.sh), which is another package manager for Windows. Unlike Chocolatey, it installs software into homedir therefore does not require admin privileges. Its interface is similar to Homebrew's. I tried both Chocolatey and Scoop and found Scoop much better. Of course, this is just my opinion, so you should try it yourself.
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
> But this is true for any solution, whether Nim script, Chocolatey, or else! Yes, that's an argument for keeping the number of "official" ways to do something to a minimum, not an argument against Chocolatey in particular. > 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. Yes but the work starts after the initial coding phase. It's not about replacing 0.16.0 with $version and have this script generated, that's indeed easy enough. It's about _maintaining_ this in the longer run. Issues might be reported, they need to be handled. The alternative ways to install Nim might grow a new feature (e.g. choose between Aporia and VS Code Plugin) and the Chocolatey package should support that too then. Also you have misunderstood me in various ways. I will accept such a PR, it's just that I am really skeptical.
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.
Re: Installation on 64-bit Windows
> What do you say, does it make sense? Somewhat. I don't mind PRs so that a Chocolatey script becomes part of "core" Nim, but that does not solve anything for us core devs, in fact, it creates more work for us. I certainly don't want the installation to depend on Chocolatey, it's not an official part of Windows, most likely doesn't work on Windows XP etc etc, so the old ways to install Nim would continue to exist. The main feature of Windows is that software can be installed without much trouble. > 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. But I don't want to write PowerShell scripts. Been there, done that, thanks I'd rather write Nim programs instead. **Every officially sanctioned way to install Nim needs to be tested, for every single release.** Right now we support: * installation from tar.xz. * installation from the zips. * installation via the installer.exe. * installation from github. You think we can add "installation via Chocolatey" to this list and it would help us. No, it wouldn't. It would help _you_ as a user of Chocolatey.
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.
Re: New in todo.txt
I don't see why pattern matching is necessary for version 1.0. Can you explain the rationale for it?
Re: messaging - or communicating between GUI's
Thank you **god**. data[][0].addr was what I was looking for, tried to use repr to check but it turned out unreliable and so my confusion. So **Araq** was right, I was trying to send pointer, but I could not find from his answer where I made it wrong.
Re: var param vs tuple as return value
I know. Closed. I am sorry but let me add last quick remark. Such discussions, even when look somewhat as a fight, are not necessarily bad thing. It is good to see some other people opinions as long as they are backed up with constructive arguments. So if it is possible to make section for my questions , maybe it is possible to also create section for more loose discussions? I hate when I see interesting debate on stackoverflow and suddenly it is closed because someone found it not constructive.
Re: New in todo.txt
> To start with a practical example, ... Syntactic issues aside, you start with an example that cannot be checked for exhaustiveness and so is pretty much against the idea of `case`. The reason why pattern matching needs to be built into the language is not convenience (you can get that with a PM macro easily enough even though nobody uses that for macros right now) but safety. Right now Nim's case objects are not safe: type E = enum valA, valB Obj = object case k: E of valA: a: int of valB: b: string proc modify(o: var Obj) = reset(o) o.k = valB o.b = "xx" case x.kind of valA: modify(x) echo x.a of valB: ...
Re: New in todo.txt
> `T?` The syntax for type constructions follows Nim's syntax for expression construction and in expressions there are no postfix operators so `T?` doesn't fit Nim's syntactic framework. In other words I decided against this as this syntax is hard to implement and inconsistent.
Re: Enum types: Commas optional?
Yes, they are optional and that's not a bug. I enjoy type Foo = enum valueA ## comment here valueB ## more documentation
Re: var param vs tuple as return value
> I was not off-topic. This thread got pivoted to discussion of preferred > communication methods by Araq himself before I got here. Oh yeah and I regretted this remark... It's fine to ask newbie questions here, the forum will get a section for this. Now consider this thread **locked** (the forum will soon support this feature too) as this discussion is turning into a pointless fight.
Re: New in todo.txt
> nil ref T. Super. I think this change will turn some heads. I also like the recent work on region collection. Rust and Swift are going all in on doing away with the tracing GC; it's a good thing that Nim can hedge it's bets. > > ML/Rust style pattern matching? > > Oh we might as well start a discussion here about its syntax. Could you expand the example a bit? I'm not following. > > I hope that whichever implementation is sanctioned works well with all of > > the other relevant language features of Nim. > > Well I don't know what that means. How will interfaces interact with generics? Will we have generic interfaces, like in Java and D? What's to be gained by sanctioning or endorsing one approach right now? > > That would be really useful, but as a hard blocker for 1.0? > > Seems easy enough to do though. Sure, but I'd like to see Nim 1.0 sooner rather than later, and this strikes me as an easily compatible change (a feature addition, that shouldn't interfere with much else) that could go in 1.X
Re: var param vs tuple as return value
> StackOverflow is nothing at all like Facebook. Relating them this way is > absurd. There are similarities and differences. [StackOverlow](https://en.wikipedia.org/wiki/Stack_Overflow) (Alexa rank 43) is a part of [Stack Exchange Inc](https://en.wikipedia.org/wiki/Stack_Exchange) (a for-profit corporation which operates several other commercial sites). Stack* and Facebook are both very big, and both make money through tracking and ads. The major difference is the target audience and content structure. Stack* is already [heavily criticized](https://www.google.com/search?q=stack%28exchange%7Coverflow%29+sucks) for having a very rigid moderation / censorship system. > StackOverflow isn't evil at all. I was using the colloquial relative term "lesser evil". I am not against for-profit corporations, but it is in the user's self-interest to weigh the benefits and drawbacks compared to self-hosting an open and decentralized alternative. > It's not subservient to any government. Everyone is entangled with and subservient to [government](http://stackexchange.com/legal/terms-of-service/usg) \- it's just a matter of degree... Facebook has been [banned by the gov't of China](https://en.wikipedia.org/wiki/Censorship_of_Facebook) \- the [world's largest](https://en.wikipedia.org/wiki/List_of_countries_by_GDP_\(PPP\)) and [increasingly dominant](https://en.wikipedia.org/wiki/List_of_countries_by_past_and_projected_GDP_\(PPP\)) economy - something I'm sure its shareholders are pretty unhappy about. StackExchange is [not banned in China *yet*](https://www.quora.com/Is-Stack-Overflow-banned-in-China-If-so-why), but it could be as many technologies (ex. Bitcoin, BitTorrent, BitMessage, IPFS, Tor, etc) pose an inherent danger to government power. It is thus in their business interest to censor anything that could get them banned, to share data with governments, etc. This concern is directly related to Nim. If its community is subject to a [chilling effect](https://en.wikipedia.org/wiki/Chilling_effect) when dealing with libraries, projects, and technologies that Powers That Be don't like, then Nim is at a disadvantage. > The centralization of StackOverflow is good for getting answers to > programming questions, which is what it's for. If Stack* offers some special advantages I've failed to consider, then this is the argument you should focus on to keep this discussion constructive. I think that people who are smart enough to use Nim should also be smart enough to go to the appropriate Web-site. Does this forum offer too steep a learning curve? Then perhaps it should be made better rather than partially replaced by a proprietary site. This forum can integrate with lots of third party sites (ex. via OpenID) without becoming dependent on them. The bridge between Gitter and IRC with an [open log bot](http://irclogs.nim-lang.org) is a great example of this. > You really should consider not injecting your cockamamie political ideology > into this forum. Reminder of context: * I was not off-topic. This thread got pivoted to discussion of preferred communication methods by Araq himself before I got here. People were discussing the relative merits of asking and answering questions via IRC, this forum (examples of open platforms), GitHub / Gitter, and StackOverflow (examples of closed platforms). * Ultimately this is Araq's decision - I am just presenting my input that I hope will be glanced at in this consideration for the good of the project. * I am not pushing a bizarre, obscure, or overly zealous ideology here. On this very thread, Michal had mentioned refusing to join GitHub, Twitter, and Facebook before I got here - lots of people would prefer not to become addicted to proprietary platforms just to get a Nim question answered. * I am a pragmatist. Note for example that I've never brought up replacing GitHub with self-hosted [Fossil](https://en.wikipedia.org/wiki/Fossil_\(software\)) \- that would be a freer solution, but simply too inconvenient for others. And I've "given Facebook a chance" for the past few years, and was the #1 Nim promoter there, with my typical Nim-related post (with much effort given to writing and graphics) getting thousands of impressions on various programming groups. But it got worse and worse over time... * This is not the first time jibal has pounced on me for offering my opinion in a constructive on-topic discussion. On the ["please, can we stop the spams"](http://forum.nim-lang.org/t/2675/2) thread, I was making a point about tying people's accounts to their record of free code contribution accomplishments, including a quote from [esr](https://en.wikipedia.org/wiki/Eric_S._Raymond) \- by all accounts a significant figure in the history of FLOSS. In that instance, I had decided "not to take the bait" and just ignored what he said. I am not here to debate general political issues, and I have never used this forum to discu
Re: Forum rules
I understand. The point is that people can be irritating despite best intentions, and all recommendations listed on this thread thus-far are not sufficient...
Re: messaging - or communicating between GUI's
Ok, a bit messy with the strings and your hard-coded msglen (4) etc, but here's where I got to: * * * There's a couple of superfluous cast[pointer] in my original, in both send and recv message. They were left over from developing (they have no effect because they were just casting pointer -> pointer), code looks a bit cleaner when just directly using the buffer pointer passed in (no cast needed). look for and change: * cast[pointer](buffer) -> buffer (two occurences) * cast[pointer](data) -> data * * * The address of a cstring var is not the same as the data location, you need the allocated memory addr at char[0], so in client prog need: data[][0].addr, # data to send * * * In the server prog I changed the type of Msg to: type Msg = array[50,char] and remove init of var b:Msg #= "ABC" * * * This gets the strings being passed across, but some more understanding and re-factoring are probably in order Hope this helps
Enum types: Commas optional?
Are commas optional when declaring enumerated types? The following compiles and runs fine for me: type Color = enum red blue green purple let col : Color = Color.red echo col
Re: New in todo.txt
> That's great. What's the syntax for declaring possibly nil types? > > nil ref T. [Optional Types](https://en.wikipedia.org/wiki/Option_type) suggests another alternative of `T?` so var v1: int # not nil v2: int? # can be nil proc xyz[T?](): T? = result = nil # <- compile error, since not allowed
