option to detect whether a port is already taken?

[timotheecour]

when running 2 different instances of this, the 2nd instance doesn't crash but instead waits for 1st instance to die before handling requests. I could see how that's a useful behavior in some cases; however in other cases we may just want to assert instead of waiting in case port is already taken (that's the behavior in vibe.d)

can test with: curl http://0.0.0.0:9200 (maybe something simple more nim-esque without curl?)

import pkg/[jester]

proc test*()=
  settings:
      port = 9200.Port
  routes:
    get "/":
      resp "Hello world"
  runForever()
test()

proposal

• add an API that returns whether a port is already in use (then user can choose to assert if he wants before runForever, as described above)
• add an API that finds (efficiently, ie not by calling repeatedly previous API) the next available port among a range a..b

[dom96]

Sure, this would be nice.

As a side note:

import pkg/[jester]

I really wish you would just use import jester.

[timotheecour]

I really wish you would just use import jester.

that's to avoid symbol clashes (cf rationale why std and pkg were introduced)

related: this is how it's done in $nimc_D/nimsuggest/nimsuggest.nim

proc connectToNextFreePort(server: Socket, host: string): Port =
  server.bindaddr(Port(0), host)
  let (_, port) = server.getLocalAddr
  result = port

it's only part of the answer, but still some progress

[dom96]

that's to avoid symbol clashes (cf rationale why std and pkg were introduced)

All new modules in the stdlib are added to a mandatory std dir. You don't need this.

[timotheecour]

• does nimble (not necessarily published nimble pkg but for a local one) enforce that a pkg foo doesn't clash with an existing module in stdlib? eg would it error on a pkg called strutils ?
• same question for a published nimble pkg

if the answer is yes to both (especially to 2nd item), then I'm happy :)

[dom96]

Nope. But I won't allow such packages to be published.

On Thu, 1 Nov 2018, 21:50 Timothee Cour, [email protected] wrote:

• does nimble (not necessarily published nimble pkg) enforce that a pkg foo doesn't clash with an existing module in stdlib?
• same question for a published nimble pkg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dom96/jester/issues/175#issuecomment-435199281, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPDe8e5UGM4Q3L5RWSa-n1xX59UDruSks5uq2yRgaJpZM4X87aC .

[timotheecour]

=> programmatically prevent a package to be published that could clash with a stdlib module · Issue #576 · nim-lang/nimble