Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 12 20:40

    PombeirP on android-api

    nix: Add support for cross-comp… fixup! nix: Add support for cro… (compare)

  • Dec 12 18:52
    kdeme opened #437
  • Dec 12 18:41

    kdeme on waku-node

    Start implementation of waku no… (compare)

  • Dec 12 16:51
    acolytec3 closed #436
  • Dec 12 16:17
    mratsim synchronize #641
  • Dec 12 16:17

    mratsim on nbench

    slots-processing allow benching state_transition… Add Attestations processing (wo… and 2 more (compare)

  • Dec 12 15:55
    mratsim commented #641
  • Dec 12 15:54
    mratsim commented #641
  • Dec 12 11:12
    stefantalpalaru commented #640
  • Dec 12 09:47
    kdeme commented #436
  • Dec 12 08:51
    arnetheduck commented #640
  • Dec 12 08:42
    arnetheduck commented #547
  • Dec 12 01:35

    stefantalpalaru on devel

    bump nim-eth & nim-nat-traversal (compare)

  • Dec 12 01:30
    acolytec3 opened #436
  • Dec 12 01:09

    stefantalpalaru on master

    bump nim-eth & nim-nat-traversal (compare)

  • Dec 12 01:06
    stefantalpalaru reopened #431
  • Dec 12 01:05
    acolytec3 commented #431
  • Dec 11 23:51
    zah commented #641
  • Dec 11 23:41
    zah commented #641
  • Dec 11 23:38
    zah commented #641
Autobot
@status-im-auto
Kayaba@discord: If you manually build every step of the way and get some extra libraries, it's usable. When you throw it at a CMake script or nimc + FFI...
Autobot
@status-im-auto
mratsim@discord: our windows CI use mingw, the most annoying stuff is explaining to users how to get it and setup the environment variables
mratsim@discord: but then I looked at Go install on windows and it seems like they are also struggling
Autobot
@status-im-auto
zahary@discord: Visual Studio Community Edition is quite feature-rich nowadays
zahary@discord: And CMake is gaining grounds everywhere, so I think it's actually easier than ever to target the native SDKs on Windows
Autobot
@status-im-auto
cheatfate@discord: @zahary it doesn't matter you using MinGW, VS or Intel compiler on Windows all of the target native SDKs on Windows.
Autobot
@status-im-auto
arnetheduck@discord: @zahary I don't understand raises[Defect] - it seems like an oxymoron - can you elaborate? "I raise an exception that is not part of the abi and that may and should not be caught".. raises[] says the same thing, without confusion as to why Defect is being explicitly mentioned, because it's never mentioned anywhere else (ie + for integers and all the other things that randomly raise defects)

arnetheduck@discord: from nim manual:

Exceptions that indicate programming bugs inherit from system.Defect (which is a subtype of Exception) and are stricly speaking not catchable as they can also be mapped to an operation that terminates the whole process.

arnetheduck@discord: pointing out that something may raise a defect is misleading - it doesn't provide any new information since practically anything in nim may raise a defect because of that definition
zahary@discord: At the moment, Defect is tracked like any other exception. In my proposal, I've suggested an alternative pragma called errors that specifies only the recoverable errors and includes Defect implicitly
arnetheduck@discord: so it's still not ignored?
zahary@discord: yes, it's tracked
Autobot
@status-im-auto
arnetheduck@discord: ...which is a bug then, since they're not catchable
zahary@discord: well, they are (under rare circumstances). btw, even in Rust, you can handle panics
mratsim@discord: CI for FreeBSD and OpenBSD are merged in Nim master: nim-lang/Nim@c5c6bae
zahary@discord: they are handled through stack unwinding as well
arnetheduck@discord: so... hm...
proc f(): int {.raises: [].} =
  24 + 44

echo f()
arnetheduck@discord: + raises a defect, why does this compile?
Autobot
@status-im-auto
zahary@discord: I might have missed some change in the compiler, let me try it myself
Autobot
@status-im-auto
arnetheduck@discord: if I were to guess, it would be because it's a compiler magic that is not introducing the effect as part of its impl, but there might be deeper reasons - the whole exception-defect-catchableerror thing is quite the mess in general, there's no way to form a logically consistent strategy around it
arnetheduck@discord: the fact that it's optional and an afterthought keeps reappearing
zahary@discord: This is the relevant issue and I don't see progress on it:
https://github.com/nim-lang/RFCs/issues/77#issuecomment-445760456
arnetheduck@discord: which brings us back to raises[Defect] and what it means - ie how to soundly explain it.. "sometimes raises some defects that maybe are tracked"?
zahary@discord: Tracking Defect is OK for me, it's mostly an inconvenience that you must include it everywhere, but it does provide more accuracy in the tracking in return
Autobot
@status-im-auto
zahary@discord: I could also live with it being untracked, but the current situation where it's tracked sometimes is obviously a bug
Autobot
@status-im-auto
arnetheduck@discord: so actually, it's "maybe raises Defect that sometimes is tracked and maybe can be caught" - sounds like a strong guarantee 🙂

zahary@discord: These issues should be filed and fixed, but I wouldn't label them as critical since we don't intend to handle Defects. Their faulty tracking doesn't bother us that much.

We should still use raises: [Defect] though, because otherwise, a more manual non-faulty use of a Defect exception will create problems. Here is a problem that demonstrates this:

proc foo(x: seq[int], i: int): int {.raises: [].} =
  if i > 10:
    raise newException(IndexEror, "index out of bounds")
  x[i]
Autobot
@status-im-auto
zahary@discord: I meant to say Here is a program
Autobot
@status-im-auto
mratsim@discord: Well if you run out of memory at a low-level, the OS will just return a nil pointer for a malloc. But IMO this is a defect. It can be catched though
mratsim@discord: a div by zero will just crash the program with SIGFPE however (except on the weird platform that returns zero)
tersec
@tersec
Zahary, are CaseTransition warnings relevant to building nim-beacon-chaingiven that it uses old case object definitions, which AFAICT is all that warning's really about?
Andreas Rumpf
@Araq
what's the value in tracking Defects? If the proc doesn't use '+' already it might change its implementation to use '+' anytime soon, so every proc can always potentially raise a Defect. nothing to track, it's always true
I would love to fix this issue if we could agree on that one but last time there was no agreement iirc
zah
@zah

@Araq, whether Defects should be tracked is certainly debatable. We can definetely live with a rule saying that they are not tracked.

If they are tracked, my plan was introducing a different macro pragma that inserts Defect implicitly. Using such a pragma in our codebase seems necessary anyway, because we want to enforce another rule - the recoverable errors of a proc must always be handled at the call-site. I can do that with some clever tricks using distinct return types.

The argument for tracking Defects is that this is ultimately slighly more accurate (gives you more expressive power). This certainly comes at a convenience cost for less experienced users who would have to learn to include it everywhere properly
Andreas Rumpf
@Araq
well the "slighly more accurate" is a liability for evolving code
zah
@zah

If a future version of Nim can prove that code like

if i < list.len:
  return list[i]

... is safe and we have similar mechanisms to statically rule out overflows in certain situations, then Defect-free becomes an interesting property of the code that you might care about (in some programs or libraries)

another way to spell defect-free is panic-free
Andreas Rumpf
@Araq
I think that's only realistic with saturated arithmetic
(which I'm a big friend of)
Ștefan Talpalaru
@stefantalpalaru
Aren't you supposed to tackle these kind of guarantees by building your language on a proper type system based on the Curry–Howard isomorphism with dependent types like Idris has? Exception tracking using effects is done like this: http://docs.idris-lang.org/en/latest/effects/simpleeff.html#exceptions
zah
@zah
Ada SPARK can prove pre-conditions (e.g. for the indexing operator) with a type system that's very close to Nim's

if you really want to ensure that something like x + y > 100 won't overflow, you can write convoluted code like this:

if  y < 100 and x > 100 - y:
   ...

Then it should be possible for the compiler to prove that no overflow is possible

zah
@zah
oops, my bad, this is not the same check
it should be if (int.high - x) > y and (x + y) > 100
Alexander Ivanov
@alehander92
can't the current range infrastrucure help: e.g. express x as int in 0 .. 50_000 and y in 0 .. 200 (int<size> is too rough estmate for most values: often a way more limited domain makes sense and this can make most overflow detections easier)
i read such an argument several days ago (range constraint in Ada/Pascal etc family of languages are overlooked in the c/rust family for no obvious reason) and i wondered about that
Andreas Rumpf
@Araq
well @zah but you left out the else:
what to do if there was an overflow? doing nothing works when you don't have to return a value
Andreas Rumpf
@Araq
in the end you then return an Option[T], with saturated arithmetic the option sinks into the involved arithmetic like NaN. it's an alternative design, in the end both ensure that your function is total. and not much else wrt correctness