Blocking nmap scans

Can you be more specific? What os? What do you want to relay? TCP or UDP? Is your server program crashing? why do you restart the server? I can give you a vague answer for a vague question: when you want to proxy tcp connections, then you could have a udp socket, which never sends data but list

Experimenting with a FreeRTOS OS Port

Sorry for the wait, but finally got around to fixing up the PR for this: If anyone could try it out, that'd be great! There's work to do on wrapping other things on FreeRTOS like tasks/queue's and semaphores/locks.

Alternative to float

I stand corrected. You are right, a "too large" number returns `inf`. import strutils echo $parseFloat("1.8e+308") Run So, it might only be invalid strings like "xyz" that generate `ValueError` s. I did not know that C's `float` supported infinity. Looking at `IEEE

Blocking nmap scans

Currently I'm working on a relay server and I'm wondering if software methods within Nim would help mitigate scans. So far I can detect them and I'll restart the server after a timing defense. But then upon a second scan it crashes there server

Alternative to float

This is explained by the 32-bit vs 64-bit effect. If you change the rounding to 8 digits, you get: `1.1993 != 1.1998` C's `atof` returns a double, but by casting it to 32-bit, you are getting a single so it fails to store the final `8` in 32 bits. And of course, when rounding to 7 digi

Nimble package structure and interop changes

* Rolling Release support. * Git short hash as version.

Alternative to float

> However, parsing to binary shouldn't raise an exception fault unless the > number is too big ... or is not a valid float format. Yes, and that is the reason why I wonder why people say they have trouble. > Do you have an idea what the problem with echo &"{atof(num):.7f} != {pars

Alternative to float

Philisophically, a CSV file is written in decimal (base 10) but float64 is binary (base 2), so conversion problems are not uncommon. But for most tasks, it doesn't make a real difference. A true decimal number type is slower and is typically reserved for finance and science. I go into this with

is it possible to rename a key in an orderedtable while retaining the order?

That's also true. :-) You probably mean the aforementioned `OLSet` / `CompactTable` which do that. That can get a lot of space savings since the sparse hash table part can be an array of much smaller objects - just the index. Those smaller objects should really become a little larger `(index,

is it possible to rename a key in an orderedtable while retaining the order?

> Fixing that requires the intrusively merged linked list to go from singly- to > doubly- linked and @Araq does not like to charge "non-delete workload" cases > for things only needed by mixed workloads. (In this case the charge is space > for the 2nd link.) That's true but I think a more radic

How to wrap JavaScript library

:)

Alternative to float

Also, the failure you are seeing may be some latent corner case bug in `lib/system/strmantle.nim:nimParseBiggestFloat`. If you can log any parse failures that would have translated to exceptions to some log file then you can probably help get such a bug fixed.

Alternative to float

If you want no exceptions raised you can use `parseutils.parseFloat` instead of `strutils.parseFloat`. If you are parsing CSV data you probably do want to handle bad inputs _somehow_. E.g., you can convert the "parsed too few bytes" condition into a NaN/zero/.. based on `parseutils.parseFloat`

Alternative to float

I wish I still had the example to hand. But well, it was basically parseFloat(0.4145341") throwing an exception. To be fair, this is one failed instance out of many thousands of passes. I'd just prefer to avoid any exceptions at all.

Alternative to float

I can construct a rounding error with 32 bit floats: import strformat,strutils proc atof(s:cstring):float32{.header:"stdlib.h",import.} let num= "1.1998" echo &"{atof(num):.7f} != {parseFloat(num):.7f}" Run produces 1.199 != 1.200

Alternative to float

> so often with float, a valid string won't be parsed. Can you give some examples? I have still no idea about your exact problem, and I never had problems with float in all the languages I have ever used.

Alternative to float

> is correct, float and float64 are identical in Nim That is the case in the current Araq Nim implementation. But it is not really defined in the Nim language specification for all Nim implementations.

Alternative to float

Okay, float64 it is then. I'm not really worried about precision, it's more the exceptions. That is to say that every so often with float, a valid string won't be parsed. If I'm totally up the private bytes of 10 fields, I don't want to have 9 instead, and wonder about what caused a blip.

Alternative to float

@Varriount is correct, `float` and `float64` are identical in Nim, which you can see [here in system.nim](https://github.com/nim-lang/Nim/blob/bf320ed172f74f60fd274338e82bdc9ce3520dd9/lib/system.nim#L30)

Alternative to float

Nim's float64 is equivalent to double (And I believe float is always a float64 too). What kind of bugs are you afraid of? While standard floating point types are not exact, it is usually only an issue in programming domains that require exact results, like finance.

Alternative to float

float64 is the equivalent to double in nim if you truly want to avoid float errors, perhaps consider using a decimal library, there should be a few of those on github