ok, getting just the non errors by:
> (#~ _1000 >: 4&T.) f
1 1
should this be unboxed though, and effectively unprocessable? (it is not text #
returns 1, $/L. returns blank. lr returns error)
0 { f
|domain error
datatype > 0 { f
|domain error
| datatype >0{f
datatype 0 { f
boxed
I prefer this though:
2 + E&.> ('a';1;2) < mkerr t.'' &> 1 2 3
┌───────────────────┬─┬─┐
│┌┬─┬──────────────┐│3│3│
│││3│|domain error ││ │ │
│└┴─┴──────────────┘│ │ │
└───────────────────┴─┴─┘
though processing for non errors with just t. is possible as:
> 1 { 10 +each^:(_1000 >: 4 T. ])"0 f
11
On Monday, April 11, 2022, 01:20:41 p.m. EDT, Henry Rich <[email protected]>
wrote:
No bug; check the type of f. When you 'display' it, you are seeing the
error, not the value.
I'm sure we will talk more about better error reporting as we get
experience.
Henry Rich
On 4/11/2022 1:16 PM, 'Pascal Jasmin' via Beta wrote:
> 'a' < t.'' 1 2 3
>
> |domain error
>
> 'a' < 1 2 3
>
> |domain error
>
> | 'a' <1 2 3
>
>
> When a pyx returns an error, the content of the pyx appears unboxed? which
> seems like a bug
>
> 2 < t.'' 1 2 3
>
> ┌─────┐
>
> │0 0 1│
>
> └─────┘
>
> f =. ('a';1;2) < t.'' &> 1 2 3
>
> f
>
> |domain error
>
> 4 T. ('a';1;2) < t.'' &> 1 2 3
>
> _3 10 8
>
> 4 T. f
>
> _3 _1000 _1000
>
> the result for f should be 3 boxes with the first holding the error text
> (preferably the 2 line version). The same format as if no error
>
>
> (3;1;2) < t.'' &> 1 2 3
>
> ┌─┬─┬─┐
>
> │0│1│1│
>
> └─┴─┴─┘
>
>
> My request is to be able to "decorate (with metadata)" an ordinary box such
> that it responds to 4&T. with an error number (instead of _1001), and the
> content is likely to be error text.
>
>
> On Monday, April 11, 2022, 12:39:28 p.m. EDT, Henry Rich
> <[email protected]> wrote:
>
>
>
>
>
> Look at 13!:8 for your mkerr.
>
> Good point about having more error info; but maybe debug would give even
> more?
>
> Henry Rich
>
> On 4/11/2022 12:33 PM, 'Pascal Jasmin' via Beta wrote:
>> Could there be a foreign that generates an "error pyx"?
>>
>> A functional/debugless error handing/processing model.
>>
>> f error = error passed through.
>>
>> raising error function y = above error state ; < f ; y ; x (or last 2-3
>> boxes in ar format suitable for `:6. boxed to make 1 item for consistency
>> with monad dyad function shapes)
>>
>> A way to unify pyx and sequential code for "later consumption" with simple
>> error management/awareness is (a cruder version of this non pyx)
>>
>> t =: t.''
>> P =: 1 : ('(u y) (;<) (u ar) ` (y ar) '; ':'; '(x u y) (;<) (x ar) ` (u ar)
>> ` (y ar)')
>>
>> ERROR =: 0 1 0 $ _
>> isErr =: ((< ERROR) -: {.@{.@:])
>> E =: (`])(@.isErr)
>> mkerr =: 1 : 'u :: ((ERROR ; 13!:11 ; 13!:12)@:(''''"_))'
>>
>>
>>
>> 2 + E 'a' < mkerr 1 2 3
>>
>> ┌┬─┬──────────────────────────────────────────┐
>>
>> ││3│|domain error | 2+E'a' <mkerr3 1 2 3 │
>>
>> └┴─┴──────────────────────────────────────────┘
>>
>>
>> With boxes/pyxes having metadata returning an error code, being able to use
>> that "internal J metadata" would be preferable to this "roll my own
>> functional error handling".
>>
>> Note that some info (error position/line) in error handling in a thread
>> gets disabled:
>>
>> > 'a' < mkerr t. '' 1 2 3
>>
>> ┌┬─┬──────────────┐
>>
>> ││3│|domain error │
>>
>> └┴─┴──────────────┘
>>
>> I mentioned, user building the "calling code" along side the pyx. This is
>> for the ultra rare condition where a retry on the code might be fruitful.
>> An alternative would be 41&T. pyx(es) returning the "full" 13!:12 info
>> instead of this shorter one. 13!:12 linear copy of (error) text includes
>> indent hints of where in the code caused the error.
>>
>> Async code is going to manage a list of pyxes for further processing, often
>> ignoring (leaving in queue or removing to add to an error reporting queue)
>> those that returned errors. The code that caused the errors is useful info,
>> because it probably has a bug. A foreign that adds the same metadata to
>> boxes such that 4&T. can filter for "general functional errors (return
>> values)" is needed/good if only because sequential boxes can be added to
>> pyxes "further processing lists"
>>
>>
>> On Monday, April 11, 2022, 09:01:29 a.m. EDT, Henry Rich
>> <[email protected]> wrote:
>>
>>
>>
>>
>>
>> Correct that 'boxes' not 'pyxes' is what 4 T. operates on. (A pyx is
>> also a box).
>>
>> Incorrect that a pyx turns into a box when it completes. It's still a
>> pyx, as you will see if you open it and it contains error - the error is
>> signaled to you on the opening.
>>
>> Henry Rich
>>
>> On 4/10/2022 9:49 PM, 'Pascal Jasmin' via Beta wrote:
>>> The argument is a box or array of boxes as documented. _1001 is return
>>> value if not a pyx, and _1000 (completed pyx) is I think not a pyx anymore.
>>>
>>>
>>>
>>>
>>>
>>> On Sunday, April 10, 2022, 09:33:37 p.m. EDT, Elijah Stone
>>> <[email protected]> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Sun, 10 Apr 2022, Joe Bogner wrote:
>>>
>>>> It would be more clear I think if it said "A pyx or array of pyxes" -
>>>> https://code.jsoftware.com/wiki/Vocabulary/tcapdot#dyadic. I'm not
>>>> comfortable updating the wiki with this recommendation unless others
>>>> agree.
>>> I think that change is sensible. I might even shorten to simply 'array of
>>>
>>> pyxes'.
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
