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).
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.
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 t
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
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:
> Ov
> 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" PowerShe
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
> 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 offici
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
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/p
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://ni
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
I don't see why pattern matching is necessary for version 1.0. Can you explain
the rationale for it?
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.
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 qu
> 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
> `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.
Yes, they are optional and that's not a bug. I enjoy
type
Foo = enum
valueA ## comment here
valueB ## more documentation
> 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 for
> 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
> 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-profi
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...
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 ->
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
> 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?
25 matches
Mail list logo
