Feature - Implemented print()++

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
dump doesn't act as an unknown command in the gCLI, but isn't in help.

ash dump() works as expected, but it shouldn't be callable the way I did it in the first instance. It probably doesn't make sense if you don't have records to dump.

Isn't this the same behaviour as running any ASH function in the CLI?
 

fredg1

Member
No, this is specific to dump (and to_json, for that matter)

The issue boils down to this: Code_ng2Z9cfSP1-1.png

See that null? That's the "issue" itself.


Explanation

Now to understand "how" this is the issue:
First, take a look at the expected data type of the dump function:Code_jglKlPqy75.png
You'll notice that dump expects "ANY_TYPE". This is because, while there is a way to tell a function to accept "any aggregate", it's not, as far as I know, possible to tell a function to accept "any record".

(Actually, even if it was possible, all this would do is make it so that "the problem doesn't affect dump". The problem is still there regardless, also affecting to_json specifically:Code_Aj0mjfT1NN.pngjavaw_aDCXTtop6C.png)


So the issue is how line 140 of DataTypes.java lists null instead of... anything else.
I actually noticed this when making dump, but left it there because I didn't know if there would be unknown implications to this change (which, in fact, there is/was, since I originally thought the only purpose of that argument was to tell what to print in the GCLI when using ashref, but here, we can see it has an actual impact on functions when called directly from the GCLI).
 

Rinn

Developer
It looks like none objects like $item[none] are written to data files as [-1]null instead of [-1]none now. I haven't noticed any adverse effects from this but it seems worth reporting because it's probably unintentional and when I mentioned it to gausie and he speculated this was probably caused by r20381.
 
Top