Re: tools documentation link is broken
Thank you once more. Fixed.
Re: Big integer litterals
> I have issued the majority of reports at this time Yes, indeed I remembered your name a short period after sending my post -- so I removed the question about GTK a few days ago already.
Re: Nim's status discussion
I wouldn't say that "corporations suck" \- they are a means to an end. They need to make things work in a cost-effective and dependable way, without making themselves dependent on genius. Average-IQ programmers are the base, the bread and butter of the industry, and so they are the standard. Nim is a really beautiful language. It can be very scary...
Re: tools documentation link is broken
in the same page, backend integration link is broken [https://nim-lang.org/docs/backends.html](https://nim-lang.org/docs/backends.html) All other links seems to work
Re: Big integer litterals
Thank you all for your answers. Is seems that my first replies are still blocked . @Stefan_Salewski I didn't remember this paragraph, but indeed the compiler does what is written in the manual. However, in "Numerical constants" is is said that "Literals without a type suffix are of the type **int** , unless the literal contains a dot or **E|e** in which case it is of type **float**. " So, there is a contradiction or, at least, an imprecision here. Not a big deal but this has confused me. Now, to define an **int** literal greater of 2^32-1 or less than -2^32, we have to apply a conversion, whereas it is possible to define directly a literal with the right type for other integer types. So, it should be logical to add a prefix **' i** for this purpose. Not that I think it should be something with high priority . @Stefan Salewski again. To answer your first question, I have use **gintro** when converting a program from **gtk2** to **gtk3** (running on my Linux Manjaro 64 bits). I have been one of your first users and I have issued many reports about bugs or wishes (in fact, I have issued the majority of reports at this time ). Incidentally, it is a great work you have done.
Re: compiler error in 0.18.0 ??
Stafan_Salewski, yes, thanks for reminding about that again. The twinprimes code is old (almost a year, using 0.17.x), when I was just getting seriously into converting C++ code into Nim. Using the original construct for that loop worked, because I always compiled with `gc` on. Then I started playing with compiling with `--gc:none` to see the difference. If you open a terminal window with `htop` while the program ran you can see memory being eaten up in real time - fascinating. I ultimately found that problem too, and all current versions of all my code has corrected that implementation. But when 0.18.0 came out, I realized I had never updated THAT original code, and used it to update with (it works fine doing a default compile). As soon as you showed me that I looked at my current codebase and they all had the correction, so they can run without `gc` and not eat up memory. But to the original issue, I `think` I've traced it to the differences in `gcc` versions. My base system on my laptop is old, and I've never (yet) gotten around to updating it. It uses `gcc 4.9.2`. So what I observed occurred on that configuration. Today I installed 0.18.0 in a VB with the updated distro of my base system, which uses `gcc 7.3.0` and voila! the programs run with-or-without compiling with `gc` on|off. So that `seems` to be the cause of the different behaviors in runtimes (as they all compile on both systems). (Actually, this is one reason|excuse I keep my old configuration around, to see what stuff breaks on it.) One lesson learned: don't change the compiler option settings I put in my code for the exact reason why it's there. I'm going to run tests in other VB distro instances, to make sure the code runs on those systems too. But this makes me feel better that its not 0.18.0 per se, but which compiler is used with it. If I really feel motivated to experiment, I may see what the behavior is on both systems compiling with `clang`.
Re: Unable to reply?
Seems OK, now
Re: Unable to reply?
New users are in moderation mode by default so that's probably what the issue was.
Re: Unable to reply?
Thank you. I will wait until my messages appear in the thread.
Unable to reply?
Hi. I submitted my first post some time ago without any problem, but my replies do not appear in the thread. To reply, I click on "reply", type my message, click on "preview" (to check if anything is OK) then on "submit". The window closes, but that's all. I have tried three times, first with the initial reply, second with a new reply some time later, the third with the same reply after deactivating "NoScript". Without success. What am I doing wrong?
Re: Big integer litterals
@lscrd Nim 0.18 is correct indeed -- see language manual: Pre-defined integer types These integer types are pre-defined: int the generic signed integer type; its size is platform dependent and has the same size as a pointer. This type should be used in general. An integer literal that has no type suffix is of this type if it is in the range low(int32)..high(int32) otherwise the literal's type is int64.
Re: Big integer litterals
I just wish to say that I'm not sure of how nim behaves, but as of the C standard, nothing is said about the size of types, and definitely, the fact that int should be the natural machine's word size is an urban legend. What the C standard says about type, is the following: sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(stuff*) <= sizeof(long) nothing more. And in fact, all implementations I've encountered make int 32 bits, even on x64.
Re: compiler error in 0.18.0 ??
jzakiya, you may wonder why your program eats that much memory. I had just looked at you code, and tried this: #for byt in seg[0..Kn-1]: # count the twin primes in the segment # primecnt += uint(pbits[byt]) # count the '0' bit pairs as twin primes for jj in 0 .. Kn-1: # count the twin primes in the segment primecnt += uint(pbits[seg[jj]]) $ nim c --cc:gcc --d:release --gc:none h.nim $ ./h Enter integer number: 500_000_000_000 segment has 262144 bytes and residues groups prime candidates = 1333; resgroups = 167 create nextp[6x57081] array perform Twin Prime Segmented SoZ last segment = 75435 resgroups; segment slices = 63579 total twins = 986222314; last twin = 4062+/-1 total time = 205.109 secs Seems to work now, so that part of your code seems to generate a copy of the seq for each call.
Re: compiler error in 0.18.0 ??
Hello, I tested your code on a similar configuration (Linux 64-bit i7-2675QM 2.20GHz). With an input of 500 billions, the system had to make use of the swap and then crashed. Moreover for 50 billions, with `--gc:none`: $ /usr/bin/time ./twinprimes_ssozp5a2a Enter integer number: 500 segment has 262144 bytes and residues groups prime candidates = 133; resgroups = 17 create nextp[6x19907] array perform Twin Prime Segmented SoZ last segment = 217259 resgroups; segment slices = 6358 total twins = 118903682; last twin = 4999590+/-1 total time = 30.972 secs elapsed = 0:33.04 s user = 30.37 s system = 0.66 s CPU = 93% Mem = 0 kB Mmax= 1659060 kB inputs = 0 outputs = 0 swaps = 0 With default gc: Enter integer number: 500 segment has 262144 bytes and residues groups prime candidates = 133; resgroups = 17 create nextp[6x19907] array perform Twin Prime Segmented SoZ last segment = 217259 resgroups; segment slices = 6358 total twins = 118903682; last twin = 4999590+/-1 total time = 29.736 secs elapsed = 0:32.34 s user = 29.73 s system = 0.00 s CPU = 91% Mem = 0 kB Mmax= 6980 kB inputs = 0 outputs = 0 swaps = 0 1659060 kB max memory without gc, 6980 kB with gc. 500 billions, with default GC: Enter integer number: 5000 segment has 262144 bytes and residues groups prime candidates = 1333; resgroups = 167 create nextp[6x57081] array perform Twin Prime Segmented SoZ last segment = 75435 resgroups; segment slices = 63579 total twins = 986222314; last twin = 4062+/-1 total time = 361.130 secs elapsed = 6:10.44 s user = 361.12 s system = 0.01 s CPU = 97% Mem = 0 kB Mmax= 6376 kB inputs = 0 outputs = 0 swaps = 0 I can speculate that the new memory allocator introduced in the 0.18.0 release explains the difference of behaviour between 0.17.2 and 0.18.0. Anyway, it seems you can't afford to not use the GC for this program, or you would have to manually manage memory.
Re: need an explanation of strings/add behavior
Thanks for pointing that out. So we don't know what the extent of the 's' bug was, but the Playground is now at 0.18.0 and it's gone.
Re: compiler error in 0.18.0 ??
@jzakiya what do you mean exactly with the word "process"? I do not see usage of osproc module in your code... Also, what is an input value for which you get that error?
Re: compiler error in 0.18.0 ??
> Turn of your OS's memory overcommitment. I have no idea what this means. Giving an example would be helpful next time. Unfortunately, 0.18.0 has some bigtime regressions. I compiled the same code in 0.17.2, and not only does it compile and run correctly for all input values, the compiled binary went from ~ 112K bytes to ~85K bytes. So I guess I'm sticking with 0.17.2 for awhile. Below are the source files: **twinprimes_ssozp5a2.nim** \- sieve as single process [https://gist.github.com/jzakiya/8f7f4f0dc8c9efd70870a1b3449c60cc](https://gist.github.com/jzakiya/8f7f4f0dc8c9efd70870a1b3449c60cc) **twinprimes_ssozp5a2a.nim** \- sieve separated into 2 processes [https://gist.github.com/jzakiya/308b20892013f41d808c926b30e9b94d](https://gist.github.com/jzakiya/308b20892013f41d808c926b30e9b94d) Compile as (directions in beginning of file comments) $ nim c --cc:gcc --d:release --gc:none twinprimes_ssozp5a2|a.nim and run and enter big number e.g. 500 billion (500_000_000_000) $ ./twinprimes_ssozp5a2|a Enter integer number: 500 this takes ~246 secs (4 minutes, single thread), on my I7, 3.5GHz, 64-bit Linux distro laptop Large values like this crash twin...5a2a with 0.18.0, but both programs run perfectly with 0.17.2.
