Re: [help needed] nim version of: COMPARING PYTHAGOREAN TRIPLES IN C++, D, AND RUST
My first thought would be to make a simple infinite iterator function for z. the boilerplate of that iterator code aside, I think this solves the scope problem and the cognitive load problem and makes it look more elegant, but I know iterators are expensive. I wonder how expensive for this case...
it is hard to load forum.nim-lang.org for months
I have tried IE, Firefox and Chrome on my Win7 64bits with and without proxy, but in these months it is very hard for me to load [https://forum.nim-lang.org](https://forum.nim-lang.org)/ or any posts url. No error is displayed, all these web browsers just finished with a blank page but the title can be read from the tab. I have to reload the pages several times, sometime the forum can be shown after many reloads, but sometime I just can't load the web page whole day. So how can I fix it? Thanks
Re: Passing data prom one thread to another
[há hắng]ư)[http://forum.gamevn.com/forums/cac-quang-cao-khac.394/create-thread](http://forum.gamevn.com/forums/cac-quang-cao-khac.394/create-thread))
When's GCunref() necessary
I noticed the following example in the nim manual to demonstrate how to use an untraced object: type Data = tuple[x, y: int, s: string] # allocate memory for Data on the heap: var d = cast[ptr Data](alloc0(sizeof(Data))) # create a new string on the garbage collected heap: d.s = "abc" # tell the GC that the string is not needed anymore: GCunref(d.s) # free the memory: dealloc(d) Run But when I test the code, I found that even if I've commented `GCunref(d.s)` out, no memory leak will happen (according to memory usage by `top`). Below is my full test code: proc foobar(i:int) = type Data = tuple[x, y: int, s: string] # allocate memory for Data on the heap: var d = cast[ptr Data](alloc0(sizeof(Data))) # create a new string on the garbage collected heap: # use a different string everytime to prevent any "cache" if possible d.s = $i # tell the GC that the string is not needed anymore: #GCunref(d.s) # free the memory: dealloc(d) for i in 0..10: foobar(i) Run I've tried to find out what happend by looking at definations of functions like `unsureAsgnRef` etc. in the source code, but they all give me the impression that memory leak should happen here. Have I got something wrong? Or GCunref() isn't necessary in this case?
Re: Happy New Year! Version 0.19.2 released!
Happy new year and many thanks to the contributors!
Re: [help needed] nim version of: COMPARING PYTHAGOREAN TRIPLES IN C++, D, AND RUST
Nim + Intel's proprietary C/C++ compiler == easy benchmark wins over languages married to LLVM.
[help needed] nim version of: COMPARING PYTHAGOREAN TRIPLES IN C++, D, AND RUST
original article: [https://atilanevesoncode.wordpress.com/2018/12/31/comparing-pythagorean-triples-in-c-d-and-rust](https://atilanevesoncode.wordpress.com/2018/12/31/comparing-pythagorean-triples-in-c-d-and-rust)/ here's nim version I proposed: see [https://github.com/atilaneves/pythagoras/pull/4](https://github.com/atilaneves/pythagoras/pull/4) sample results from the article for simple version: Simple CT (ms) RT (ms) clang debug 59 599 clang release69 154 dmd debug11 369 dmd release 11 153 ldc debug31 599 ldc release 38 153 rustc0 debug100 8445 rustc0 release 103 349 rustc1 debug 6650 rustc1 release217 Run looks like nim release version of simple.d compiles faster and runs a tiny bit faster than D version ldc release of simple.d # note one thing I don't like about the way I wrote nim version of simple.d is how I translated this: for (int z = 1; ; ++z) foo Run into this: var z = 1 while true: foo z.inc Run it's bad for 2 reasons: * z is in outer scope instead of in a nested scope * z.inc is AFTER foo; this is bad both for cognitive load and correctness, especially when foo gets complex (eg if it has break inside it, etc)
Re: Nim is showing version 0.19.0 after updating to version 0.19.2
I had a similar issue, a windows install prior to installing choosenim, so after updating with choosenim, nim -v was unchanged. I deleted the old install and their paths and then it showed the choosenim version ok.
Re: Type instantiation for `==` func
Having thought about this for a while, I am not advocating for a fix. I was hesitant to define the == func at all since it is comparing keys but not values, It is called set-equal? in MIT/Scheme wttree, not equal?. I only considered adding it to make the unit tests line up with other Nim set library unit tests. For that purpose, I've defined =?= instead . It's reasonable for Nim to refuse to consider this func a true == if it can't unify U and V given a reasonable definition of equal, I just don't understand what language mechanism is preventing it.
Nim is showing version 0.19.0 after updating to version 0.19.2
Hi all, I have updated nim using "choosenim". CMD showed me that update was successful. But printing "NimVersion" shows "0.19.0". Do i miss anything ?
Re: Convincing my friend about Nim
He has a different opinion to you, it doesn't matter. Jut have a little laugh if he complains about Nim. It's not worth losing a friendship over.
Re: Convincing my friend about Nim
The one and only advantage of C# and VB.Net is the best in class IDE visual studio. If Nim has an IDE like visual studio, then Nim is the king among all languages. Really.
Re: Convincing my friend about Nim
Oh funny, one reason I was attracted to Nim was because it _was_ immediately readable to me, that its focus was about readability and representation. This, compared to rust, for example, which makes me start clenching my teeth. If a language goes down that rabbit hole, then it should just be like APL and actually be a new language with new symbols and everything so as to remain concise. /rant Okay, so what does that mean about your friend? Well, sounds like they just haven't used many languages, so they don't have the experience to really judge.
Re: Type instantiation for `==` func
Seems like a compiler bug. Workaround:
func `==`*(s1: BBTree, s2: BBTree): bool {.inline.} =
## Returns true if both `s1` and `s2` have the same keys and set size.
result = isSubset(s1, s2) and len(s1) == len(s2)
Run
Re: Type instantiation for `==` func
Sure, here are the relevant bits: type BBTree*[K,V] = ref object # BBTree is a generic type with keys and values of types K, V ## `BBTree` is an opaque immutable type. left: BBTree[K,V] # left subtree; may be nil right: BBTree[K,V] # right subtree; may be nil size: int # the size of the (sub-)tree rooted in this node key: K# the search key; must suppprt the generic ``cmp`` proc val: V# the data value associated with the key, and stored in a node Run func isSubset*[K,U,V](tree1: BBTree[K,U], tree2: BBTree[K,V]): bool = Run You can find the complete repo at [github](https://github.com/dcurrie/nim-bbtree)
Re: Convincing my friend about Nim
Pardon me but it seems that you should change friends rather than language. What your friend said about Nim being incomprehensible for people who don't know Nim is simply ridiculous BS. If I were in your place -[and](https://forum.nim-lang.org/postActivity.xml#and) \- for whatever weird reason - wanted to keep that friend I's simply tell him "You are right. Thanks, I've seen the light. But as I'm a weird guy I'll play a bit more with that language Nim although c# is so so much better". That should help as it would address and sooth both major factors, namely your friends cluelessness and his urgent desire to be "right". (But then, neither am I in your place nor would I hesitate a split second to tell such a moron Adios...).
Re: Convincing my friend about Nim
First, I'd like to thank you for all the answers. You really gave me some good knowledge about how I could approach my friend. However, he's found another argument I really can't beat with my own knowledge. He says Nim's unreadable for programmers coming from other languages. My main contr-argument was that you can always read the documentation; heck, the tutorial for the language is well-written and easy to understand. But he keeps bragging that he doesn't want to read any docs; he just wants to understand code in any language. For me, that really shows his ignorance and lazyness. It's not really hard to deduce Nim's language features, some may be easier to deduce than others, but if I wouldn't know Nim and read the codebase of, for example, `nimforum`, as @Araq suggested, I'd at least try to understand the code using my knowledge from other languages. I probably wouldn't understand what `proc` means, or ``*`, or how generics are written, but by looking at more source code I'd be able to deduce what at least 2 of those 3 examples do (can you guess which is the hardest to deduce?). But the fact is, every developer is different, some may be too lazy to even look at something's source code, or too lazy to try and deduce the functions of different operators. You cannot develop software without the use of documentation, and that's what he doesn't understand and keeps bragging about. Again, thank you for all the answers, and happy new year!
Re: Convincing my friend about Nim
I had a similar gang of "friends" a couple of years ago. We used to hang out on an IRC network that they ran, eventually I decided to just leave it because having them complain about Nim every time I wanted to discuss one of my projects became far too tiring. Many of the languages they were proponents of were niche too, one example was [ooc](https://ooc-lang.org/). They didn't stay loyal to these languages for long and the language's themselves were abandoned by their authors. So yeah... you likely won't be able to get through to your friend. If possible, just ignore them.
Re: Type instantiation for `==` func
I don't see a reason why it would fail to compile. Can you also add your BBTree and isSubSet type declaration so that we can reproduce a minimal working example?
Porting MSWin to Linux
sorry to reply in this old posts. but I am still (I almost have spent one year) looking for GUI solution(s) which have already exposed many widgets/controls for windows OS. So I really want to know 1\. which is the latest sciter binding for nim? Google finds https://github.com/oskca/nsciter which is released in 2016 and there is only one demo. Is there anymore demos? 2\. @OderWat, has METATEXX GmbH released your wxWidget bindings? Thanks
seek for help on porting VB lib to nim
in the VB lib, which calls functions in 32bits DLL, there are something I am
not very sure
1\. many arguments are declared as LONG in the VB files. I found that LONG is
signed 64-bit integers on
[https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/data-types/long-data-type](https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/data-types/long-data-type)
. But var a:int64 can't be compiled with nim 32bits
So, what can we use in nim to replace the long in VB?
2\. in the VB version, strings are wrapped by a function
Private Function L(data As String) As String
L = StrConv(data, vbUnicode)
End Function
hBtn = XBtn_Create(8, 30, 100, 20, L("button"), hWindow)
Run
How can we represented this convertor in nim? When I use string directly, the
displayed characters are not what I expected. I also tried +$(string) in
winimwinstr.nim, but the displayed character is wrong too.
3\. in the VB version, an argument is the address of function
Public Function OnClick(ByRef bHandle As Long) As Long
bHandle = True
OnClick = 0
End Function
XEle_RegEventC hBtn, XE_BNCLICK, AddressOf OnClick
Run
how can we do that in nim?
Thanks
Re: Default value for missing JSON fields
Sadly you have to use an `Option` in this case. I'm afraid the to macro doesn't support anything else.
Re: Happy New Year! Version 0.19.2 released!
@novikov You ran into this because you've attempted to reinstall choosenim. You already have it installed so just run `choosenim update stable` like the release blog post says: [https://nim-lang.org/blog/2018/12/31/version-0192-released.html#installing-0192](https://nim-lang.org/blog/2018/12/31/version-0192-released.html#installing-0192). @Araq I've edited your post to include a link to it...
Re: Happy New Year! Version 0.19.2 released!
> choosenim supplies 0.19.0 Until this is fixed, after the installation run: $ choosenim update stable Run
Re: Happy New Year! Version 0.19.2 released!
**choosenim** supplies 0.19.0 [https://nim-lang.org/install_unix.html](https://forum.nim-lang.org/postActivity.xml#https-nim-lang-org-install-unix-html)
Re: Happy New Year! Version 0.19.2 released!
> Many thanks to all the contributors who made these releases possible and Nim > thrive. Here are some quick numbers: * 237 backported[1] commits since `v0.19.0` tag (September 26th), more than 2.5 commits per day on average * 48 contributors > there are rumors that with this release the `nimpretty` tool finally became > useful I've been toying a bit with nimpretty and it was (surprisingly) pleasant experience. If you haven't already — give it a try, your code deserves to be pretty :) Without further ado, I invite everybody to use v0.19.2 (I've switched from `devel` to it) and report bugs and regressions (even though there aren't any :P). Happy new year! * * * [1] The total number of commits since `v0.19.0` is 849 (almost 10 commits per day on average).
import statement suggestion
Not sure if it's correct to place suggestions... But if collective imports from a directory could be nested it were more consistent in my opinion. [https://nim-lang.org/docs/manual.html#modules-import-statement](https://forum.nim-lang.org/postActivity.xml#https-nim-lang-org-docs-manual-html-modules-import-statement) As of Nim 0.19.0 import mocknim/[ # <-- it works name, procedure/procedure, module/[ # <-- it doesn't word directory, module ] ] Run
Re: Convincing my friend about Nim
> First of all, he states that not having such an indentation-based syntax
> allows for more freedom ...
He is right in that but only in one regard: Having explicit block markers (like
{ and } or `begin` and `end`) allows for (visually largely unstructured)
"streams" of code. If that were really, really needed, one could however
introduce a "3 spaces" symbol, say '°'.
It might be noteworthy that quite some studies, typically made in the context
of some entity seriously needing that question answered, have clearly shown
that readability _is_ important, in fact _very_ important. While I know of no
study addressing indentation based blocks vs marker based blocks it seems
reasonable to assume that both are clearly on the good side (remember: The
issue is (only) readability). The studies that were made all and consistently
demonstrated that "curly blocks" are clearly the worst approach (~ worst
readability) and introduce significantly more errors and are significantly
worse to maintain.
> First of all, he really dislikes the lack of brackets, and the "misuse" of
> them
I would (mildly) agree. It _does_ make sense to have `[]` meaning "something
array like" always (although I personally and subjectively - and unreasonably -
prefer [] over <>). More importantly however I reject your friends criticism
because It's basically just based on "it's not c# like and hence it's bad!".
That's, Pardon me, just stupid.
> Next up, an "invalid" argument. He says macros are dumb, and you could just
> write code normally without them.
Very wrong. Obviously your friend, like so many in the curly braces camp, fails
to understand the concept of readability which is closely linked to
maintainability and probability of errors. Probably your friend has become a
victim of the (utterly stupid) "fun" paradigm (Typical statements are "It's fun
to develop in XYZ" or "I'm a developer because it's fun") - that camp has been
found to be responsible to a very large degree for the major clusterf_ck we're
in today (e.g. funny bug of the month in SSL).
They are, Pardon my french, braindead morons. Here is the truth and the only
one in that regard: software development is an _engineering_ discipline - and a
very complex one at that. If the "fun" camp guys were also in bridge building,
railroads, air traffic etc. humanity probably would be largely extinguished by
now (the survivors living deep in the woods, far away from killing
"civilization" with tech).
Just like with bridges or railroads the relevant factor is absolutely _not_
whether those who designed and built it felt it was "fun" to do but whether the
result was reliable, meeting the needs, etc.
Macros not only allow for comfort but more importantly they allow for
"centralized code fragments". And that is directly linked to probability of
error as well as to maintainability. Just have a look at crypto code; you'll
almost invariably find (long) macros. Often the very core of an algorithm is
implemented in one or more macros. And I think even your friend would accept
that the people who gave us AES or Blake2 certainly aren't stupid.
Whenever some halfway responsible entity _really, really_ needed reliable and
bug free software they turned to languages like Ada, Eiffel, Ocaml, etc. (along
with _formal_ spec., modelling, and verification) as soon as and when such
options were available. Hell, even Pascal was used because it might not have
been a "nice" language but it offered many of the features high reliability
scenarios required.
So, to summarize it somewhat rudely: why would you even care about the opinion
of someone who doesn't have even the slightest clue what he talking about? You
are like some engineer debating with an idiot whose arguments basically are "my
(make shifted wannabe) crap is "cool" and "fun" while your (properly working
and reliable) bridges and railroad systems are boring and uncool!.
Btw, I myself am not at all against .Net (any more). For one it incl. Mono
(nowadays) offers reasonably good and wide linux support, too and isn't a pure
Windows world thingie any more. More importantly though, Microsoft (funnily
unknown to many) has invested tons and tons of money in safety, reliability,
and security research and has really done a lot of work and has created much
progress in that field. Just think of Z3 ( _the_ solver), Boogie (an "easy"
interface language for Z3), code contracts (i.a. for c#!), Dafny (a safety
targeting language that actually works) and more. With their async/await work
they have tried to make .Net also useable for servers but although they seem to
have done it well I personally and subjectively limit my .Net use for business
applications.
Well noted this comes from someone whose first (and then beloved) language was
C (and, I have to admit it, then I also was a "coolness" obsessed idiot) and
who taught C. In fact I still sometimes implement certain tricky things in C
because Nim does
