Re: high(int) works, high(uint) does not
Thanks. I'll wait (and of course just like you have an interim work around). Nice work btw. (NimCrypto).
Fedora-based Nim Docker images
[https://quay.io/repository/refi64/nim-fedora](https://quay.io/repository/refi64/nim-fedora)/ This is basically just a Fedora image with nim, nim-tools, and fedpkg installed. I made it to make building personal projects for Fedora Silverblue a bit easier.
[New Year Bitcoin BONUS] Free gift 0.02 bitcoin in honor of the New Year.
Verified service gives a free bonus of 0.02 bitcoin instantly to your bitcoin wallet. The bonus is issued exclusively in honor of the New Year and only for new users. The bonus will be credited to you when you sign up. REGISTRATION: [https://vk.cc/8NbMzH](https://vk.cc/8NbMzH) The service is completely legal and makes payments automatically. Screenshot: [https://imgur.com/LHfRGWr](https://imgur.com/LHfRGWr) You can withdraw your bonus to your bitcoin address. Blockchain screenshot: [https://imgur.com/CXWidgv](https://imgur.com/CXWidgv) You can also play crypto roulette using this bonus. Many users won good money playing roulette. Some users won about 0.85 bitcoins per game one session. But I managed to win a maximum of 0.31 bitcoins. After creating the withdrawal, I successfully received bitcoins to my bitcoin wallet automatically. Blockchain screenshot: [https://imgur.com/J2LvOeW](https://imgur.com/J2LvOeW)
Re: OOP macro - problems with import
You need to change your methods from
method init*(value: int) {.base.} =
self.value = value
method print*() {.base.} =
echo self.value
Run
to
method init*(value: int) {.base.} =
self.x = value
method print*() {.base.} =
echo self.x
Run
Re: high(int) works, high(uint) does not
Well you're not alone in wanting high(uint64). The easiest is proc high(T: type uint64): uint64 = not 0'u64 Run Make sure to check the works done at Status for crypto in Nim: * [https://github.com/cheatfate/nimcrypto](https://github.com/cheatfate/nimcrypto) -> crypto primitives (AES, SHA2-3, Blake, HMAC, pbkdf, ...) * We also have some elliptic curve wrappers (secp256k1, BN and BLS, including pairing for the last 2). * Also a start on constant-time bigint though it's mostly something I do on the side: [https://github.com/status-im/nim-constantine](https://github.com/status-im/nim-constantine). A couple of others have implemented HKDF and an alternative wrapper to BLS as well.
Re: OOP macro - problems with import
Thank you, that looks like what i was searching for.
Re: Nimsuggest not responding through sockets
I appended a n but still nothing.
Re: Nimsuggest not responding through sockets
I think you need to end the line, for nimsuggest to pick up the command. I once wrote a minimal test program, because of an issue with vscode-nim, which interfaces with nimsuggest via sockets. Idk if it still compiles, but it might help you: [https://github.com/pragmagic/vscode-nim/issues/44](https://github.com/pragmagic/vscode-nim/issues/44)
Nimsuggest not responding through sockets
Hi, > I started nimsuggest like nimsuggest --address=localhost --port=6000 > /home/user/projects/$projects/main.nim. I used a simple tcp socket from net > but after sending sug $file:$line:$column I'm not getting any response: both > hasDataBuffered() and readLine()`(with a timeout) fail. It works with `echo > 'sug $file:$line:$column' | nimsuggest --stdin but it's too slow.
FOSDEM 2019
FOSDEM 2019 is happening in Brussels soon (2&3 Feb 2019). Even though [we won't have a stand this year](https://forum.nim-lang.org/t/4324) I will still be there and I know some others will too, so I figured now would be the time to coordinate ourselves and see who actually is coming. And also to give you a reminder to start booking flights/trains/hotels if you do intend to come. So, who's coming? :) I'll definitely be bringing some Nim stickers, so if nothing else that's at least an excuse to come :D
Re: Unknown cause of AssertionError
I don't think the problem is with Nim. It's highly likely with floating point. Unless you want to play with arbitrary precision FP you'll have to live with the fact that while FP can represent mildly large integers it doesn't offer precision with fractions. Btw, that you use only up to 2 decimal places in your code suggests that your project might be about finance/trading or similar, i.e. about currency values. Should that be the case I strongly advise you to use integer arithmetic and to work with cents (or, should it be required as in some financial fields, with tenths of cents).
Re: let not always properly copying string?
The new semantics (available with gc:destructors) are detailed here: [https://github.com/nim-lang/Nim/wiki/Destructors](https://github.com/nim-lang/Nim/wiki/Destructors)
Re: Unknown cause of AssertionError
I'm just learning nim (above is only a practice exercise) and wasn't aware of the difficulties with floating point arithmetic. Thanks for clarifying and investigating the issue. I'll keep it in mind for future situations.
Re: let not always properly copying string?
I think the new assignation semantic for strings and seqs is always copy (no distinction between let and var). Copies are avoided whenever a move or passing a const ref is possible. Can someone confirm this?
Re: high(int) works, high(uint) does not
Thanks. I mentioned it (uint.high) mostly for general interest anyway because I almost always use specific intXX and uintXX types. What I said does hold true, however, also for and specifically for `uint64`. `echo "max uint32: " & uint32.high` (and smaller sizes) does compile/work but `echo "max uint64: " & uint64.high` does _not_ compile. Note that `int64.high` also compiles and works. It seems hence that the uint64 case is simply a forgotten one that can and should be easily fixed. As for int/uint I'm bewildered by the argument (not an ordinal) because one would assume that Nim (like most languages) has those defined to be whatever the bit size of a system happens to be, i.e. int is either int32 or int64 and the same for uint.
Re: Unknown cause of AssertionError
I wonder that you are surprised by your results. I assume that you know that float arithmetic is generally not absolutely exact in computers. One reason is, that not every fractional decimal number can be exactly represented in binary floating point format. So when we have three floating point numbers a, b, b then generally (a + b) + c != a + (b + c). See > [https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems](https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems) So it can not surprise that the rounding proc does not always give the exactly same result as the value which is obtained from the string representation. I don't know what your concrete problem is in real life application. When you do rounding, and print the result with a limited number of digits I guess it should be fine, as the error is in the very tiny places which generally are not printed at all. Always converting the rounded result to string and back to float may help when the same proc is used as Nim compiler use internally for processing float literals, but that is slow. Maybe you can tell us where exactly you got problems in your real life application.
Input/Output Manipulator
How does one manipulates the output of nim program just like the C++
standard class? in the case of precision, spacing width and othersC++ program
example|
---|---
#include #include
using namespace std;
int main() {
> cout << setprecision(2)
> << setiosflag(ios::showpos) << setiosflag(ios::showpoint)
> ...
}
Re: ptr arithmetics?
Thank you so much, Nim is a wonderful language. Wow. Creating tools with it is so simple! I find the power of C without the ugliness.
Unknown cause of AssertionError
I ran across this rather strange failure in one of my tests and am at a loss as to what's causing it. Can someone please enlighten me? For the purposes of this post the filename is roundxxx.nim. I left in a bunch of extra assertions just to show it otherwise works as expected. import math proc round*(n: float, d: int = 0): float = floor(n * pow(10, (d.float * -1)) + 0.5) * pow(10, d.float) when isMainModule: block: doAssert round(0.1) == 0.0 doAssert round(0.1, 0) == 0.0 doAssert round(0.1, -1) == 0.1 doAssert round(1.49) == 1.0 doAssert round(1.49, 0) == 1.0 doAssert round(1.49, -1) == 1.5 doAssert round(1.49, -2) == 1.49 doAssert round(1.5) == 2.0 doAssert round(1.9) == 2.0 doAssert round(1.79, -1) == 1.8 doAssert round(1.95, -1) == 2.0 doAssert round(1.95, -2) == 1.95 doAssert round(1.955, -2) == 1.96 doAssert round(1, 0) == 1.0 doAssert round(1, 1) == 0.0 doAssert round(9, 1) == 10.0 doAssert round(149) == 149.0 doAssert round(149, 0) == 149.0 doAssert round(149, 1) == 150.0 doAssert round(149, 2) == 100.0 doAssert round(150, 2) == 200.0 doAssert round(499, 2) == 500.0 doAssert round(499, 3) == 0.0 doAssert round(15) == 15.0 doAssert round(19) == 19.0 doAssert round(19, 1) == 20.0 doAssert round(195, 1) == 200.0 doAssert round(195, 2) == 200.0 doAssert round(195.4) == 195.0 doAssert round(195.5) == 196.0 # XXX this is some strangeness going on here doAssert round(1.89, -1) == 1.9 # XXX I've no clue why this fails let n = round(1.89, -1) # XXX when the exact same values if doAssert $n == "1.9"# XXX casted to strings pass just fine Run The result of nim c -r roundxxx.nim is as follows roundxxx.nim(39) roundxxx system.nim(3790) failedAssertImpl system.nim(3783) raiseAssert system.nim(2830) sysFatal Error: unhandled exception: [redacted]/roundxxx.nim(39, 14) `round(1.89, -1) == 1.9` [AssertionError] Error: execution of an external program failed: '[redacted]/roundxxx ' Run FYI: nim --version Nim Compiler Version 0.19.0 [Linux: amd64] Compiled at 2018-09-26 Copyright (c) 2006-2018 by Andreas Rumpf git hash: f6c5c636bb1a1f4e1301ae0ba5a8afecef439132 active boot switches: -d:release Run
Re: ptr arithmetics?
NESM comes in handy for data [de]serialization [https://github.com/xomachine/NESM](https://github.com/xomachine/NESM)
Re: Advent of Code 2018 megathread
> Do you guys have a favorite so far? My favourites so far are probably: 1. day 5 (polymers) 2. day 8 (nodes and metadata) 3. day 9 (marbles)
Re: startProcess alternative with lossless output stream
New sample:
a.nim:
import osproc, streams, threadpool
from strutils import contains
from os import sleep
let p = startProcess("./b")
var channel: Channel[seq[string]]
open(channel)
proc listen(ous: Stream) {.thread.} =
while true:
var buffer: seq[string]
var line: string
while not line.contains("#done"):
line = ous.readLine()
echo "READ: " & line
buffer.add(line)
channel.send(buffer)
proc getOrWait() =
while true:
let (received, msg) = tryRecv(channel)
if received:
echo $msg
break
sleep(10)
spawn listen(p.outputStream)
echo "MSG1"
p.inputStream.writeLine("A")
echo "Listening for MSG1 answer..."
getOrWait()
echo "MSG2"
p.inputStream.writeLine("B")
echo "Listening for MSG2 answer..."
getOrWait()
Run
b.nim:
from os import sleep
#SECTION A
sleep(100)
echo("AAA")
sleep(100)
echo("BBB")
sleep(100)
echo("CCC")
sleep(100)
#/SECTION A
let x = stdin.readLine()
writeFile("l.log", x)
sleep(100)
echo("Got it: " & x)
sleep(100)
echo("#done")
sleep(100)
let y = stdin.readLine()
echo("Got another one: " & y)
echo("#done")
Run
Even if I delete SECTION A the l.log file won't exist - which probably means
that startProcess's input doesn't even work.
Re: high(int) works, high(uint) does not
`high(uint)` is not defined. PR pending [#6620](https://github.com/nim-lang/Nim/issues/6620) `div` is only defined for integers while `/` is float only. This is because Nim is statically typed and dividing it to get floats should be a deliberate choice and not a due to programming reflex. Note that there is a `lenientops` module for relaxed type checking when mixing integers and float operations: [https://nim-lang.org/docs/lenientops.html](https://nim-lang.org/docs/lenientops.html)
Re: startProcess alternative with lossless output stream
The program is not time sensitive(well, it is but it can be late for a few seconds) - but Process's outputStream and outputHandle are and that's the issue.
