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
> 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.
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: 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: 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
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
