Gall peek failures should indicate cause of failure somehow about arvo

[philipcmonk]

@was under the impression that clay .^ never crashes unless your state is
corrupt?

On Thu, Mar 17, 2016 at 11:38 AM, Anton Dyudin [email protected]
wrote:

For clay, the semantics of a crashed .^ are fairly straightforward: %y
never crashes, %x crashes if a file does not exist at the desk at this
time. For gall, either can crash, leaving just the path in the stack trace,
regardless of whether:

• The application is not started
• The application detected a formatting error in your path, and
  attempted to report it via ~|
• The request was not made at the current date(currently unchecked,
  but necessary for referential transparency)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#77

[ohAitch]

Quite possibly, I'm not drawing a strong distinction between literal
crashing and [~ ~]. My broader concern is that clay %x semantics are
well-defined, app-specific ones are somewhat more arbitrary and not likely
to be consistent wrt what "this path doesn't exist" entails across apps.

On Thursday, 17 March 2016, Philip Monk [email protected] wrote:

@was under the impression that clay .^ never crashes unless your state is
corrupt?

On Thu, Mar 17, 2016 at 11:38 AM, Anton Dyudin <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

For clay, the semantics of a crashed .^ are fairly straightforward: %y
never crashes, %x crashes if a file does not exist at the desk at this
time. For gall, either can crash, leaving just the path in the stack
trace,
regardless of whether:

• The application is not started
• The application detected a formatting error in your path, and
  attempted to report it via ~|
• The request was not made at the current date(currently unchecked,
  but necessary for referential transparency)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#77

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#77 (comment)

[cgyarvin]

Peek at the kernel level should never crash; the double unit is sufficient.

Sent from my iPhone

On Mar 17, 2016, at 11:43 AM, Philip Monk [email protected] wrote:

@was under the impression that clay .^ never crashes unless your state is
corrupt?

On Thu, Mar 17, 2016 at 11:38 AM, Anton Dyudin [email protected]
wrote:

For clay, the semantics of a crashed .^ are fairly straightforward: %y
never crashes, %x crashes if a file does not exist at the desk at this
time. For gall, either can crash, leaving just the path in the stack trace,
regardless of whether:

• The application is not started
• The application detected a formatting error in your path, and
  attempted to report it via ~|
• The request was not made at the current date(currently unchecked,
  but necessary for referential transparency)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#77

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[ohAitch]

Sure; peek at the application level should, because requesting otherwise is
an unreasonable constraint on the application programmer. Though I suppose
they could be discouraged, and translated as ~, triggering a peer to
investigate what precisely went wrong.

On Thursday, 17 March 2016, cgyarvin <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Peek at the kernel level should never crash; the double unit is sufficient.

Sent from my iPhone

On Mar 17, 2016, at 11:43 AM, Philip Monk [email protected]
wrote:

@was under the impression that clay .^ never crashes unless your state is
corrupt?

On Thu, Mar 17, 2016 at 11:38 AM, Anton Dyudin <[email protected]

wrote:

For clay, the semantics of a crashed .^ are fairly straightforward: %y
never crashes, %x crashes if a file does not exist at the desk at this
time. For gall, either can crash, leaving just the path in the stack
trace,
regardless of whether:

• The application is not started
• The application detected a formatting error in your path, and
  attempted to report it via ~|
• The request was not made at the current date(currently unchecked,
  but necessary for referential transparency)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#77

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#77 (comment)

[galenwp]

As per @cgyarvin 's last comment, is this worth pursuing?

[ohAitch]

Yeah, I was misusing the term "crash" to mean "crash the .^ operation", but the original point about "just the path you tried to scry isn't enough to debug off of" stands. I remember this being particularly unhelpful when getting womb to work; maybe ford should retry with a peer on fail and not just on block?

[cgyarvin]

There's no particular way of using this information in most cases. You don't want to generate error information that won't get used.

[ohAitch]

The particular way I would like to use this information is to get it to the console using whatever means are reasonable, so that the failure in an app being developed isn't entirely opaque. Am I too greedy in my desires?
(I did not just send a pull request with the relevant printf, precisely because of the difficulty of using the information; though it sounds like perhaps I should have)