List with numbers #18

Closed
opened 2025-02-07 18:04:51 +00:00 by vincent · 3 comments

Hi James!

Thank you for tricu!
It helps me a lot with getting familiar with triage calculus!

A list containing only numbers is not decoded correctly:

tricu < [ (1) (2) ]
tricu > ""

But this works:

tricu < [ (1) (2) ("e") ]
tricu > [1, 2, "e"]
Hi James! Thank you for tricu! It helps me a lot with getting familiar with triage calculus! A list containing only numbers is not decoded correctly: ```haskell tricu < [ (1) (2) ] tricu > "" ``` But this works: ```haskell tricu < [ (1) (2) ("e") ] tricu > [1, 2, "e"] ```
Owner

Hey @vincent , thanks for opening this! I'm quite early in development here so many features aren't properly documented.

You can work around this using the !decode command in the REPL for now which disables decoding entirely. This allows you to see the full Tree forms of your outputs.

The reason this happens is because strings are encoded as lists of numbers, so when the decoder function encounters [ (1) (2) ] , it believes that the value is a string containing the ASCII characters mapped to 1 and 2. The decoding function was a rushed implementation and can handle these situations much more intelligently, so I'll leave this issue open until I am able to make some changes so that it handles this better.

Hey @vincent , thanks for opening this! I'm quite early in development here so many features aren't properly documented. You can work around this using the `!decode` command in the REPL for now which disables decoding entirely. This allows you to see the full Tree forms of your outputs. The reason this happens is because strings are encoded as lists of numbers, so when the decoder function encounters [ (1) (2) ] , it believes that the value is a string containing the ASCII characters mapped to `1` and `2`. The [decoding function was a rushed implementation and can handle these situations much more intelligently]([url](https://git.eversole.co/James/tricu/src/branch/main/src/Research.hs#L163)), so I'll leave this issue open until I am able to make some changes so that it handles this better.
James self-assigned this 2025-02-07 18:24:47 +00:00
James added the
bug
label 2025-02-07 18:24:50 +00:00
Author

Thank you!
I will try out the !decode command.

I use the nix flake, which works great, even in https://github.com/noamraph/nixsa.
The released binaries don't seem to work for me (I am on Fedora Silverblue Atomic Desktop.)
Here is the strace output:

strace ./tricu                                                                                          
execve("./tricu", ["./tricu"], 0x7ffe21c54b00 /* 55 vars */) = 0
open("/proc/self/exe", O_RDONLY)        = 3
mmap(NULL, 3117, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f63d1635000
mprotect(0x7f63d1635000, 3117, PROT_READ|PROT_EXEC) = 0
readlink("/proc/self/exe", "/var/home/v/Downloads/tricu", 4095) = 27
mmap(0x400000, 4700968, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400000
mmap(0x400000, 4404888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400000
mprotect(0x400000, 4404888, PROT_READ|PROT_EXEC) = 0
mmap(0x835000, 276600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0x434000) = 0x835000
mprotect(0x835000, 276600, PROT_READ|PROT_WRITE) = 0
mmap(0x879000, 11048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x879000
open("/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/ld-linux-x86-64.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
exit(127)                               = ?
+++ exited with 127 +++

Thank you again for tricu!

Thank you! I will try out the !decode command. I use the nix flake, which works great, even in https://github.com/noamraph/nixsa. The released binaries don't seem to work for me (I am on Fedora Silverblue Atomic Desktop.) Here is the strace output: ```shell strace ./tricu execve("./tricu", ["./tricu"], 0x7ffe21c54b00 /* 55 vars */) = 0 open("/proc/self/exe", O_RDONLY) = 3 mmap(NULL, 3117, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f63d1635000 mprotect(0x7f63d1635000, 3117, PROT_READ|PROT_EXEC) = 0 readlink("/proc/self/exe", "/var/home/v/Downloads/tricu", 4095) = 27 mmap(0x400000, 4700968, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400000 mmap(0x400000, 4404888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400000 mprotect(0x400000, 4404888, PROT_READ|PROT_EXEC) = 0 mmap(0x835000, 276600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0x434000) = 0x835000 mprotect(0x835000, 276600, PROT_READ|PROT_WRITE) = 0 mmap(0x879000, 11048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x879000 open("/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/ld-linux-x86-64.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) exit(127) = ? +++ exited with 127 +++ ``` Thank you again for tricu!
Owner

Thank you @vincent for that additional feedback regarding the binaries; they're meant to be statically linked. I have some test builds running and if everything pans out, I'll update my pipelines here so that the next release works properly. Until then, I'll hold off on distributing further binaries as they're not going to be useful to anyone else. I'm tracking this in #20 and will tag you there when that is resolved.

As for the issue in this ticket, it's resolved in commit e6e18239a7 available now on main.

tricu < [(1) (2) (99) (300) (35)]
tricu > [1, 2, 99, 300, 35]

Lists that only contain the numbers 9, 10, 13, and 32...126 will still decode as strings:

tricu < [(32) (33) (34) (35) (9) (10) (13)]
tricu > " !"#
"

This looks to be an improvement. Let me know if you have any thoughts on further improvements for this behavior.

That commit also replaces the !decode REPL command I just mentioned to you with !output so that you can choose from the different output formats already implemented for the -t flag on tricu eval.

I really appreciate you reporting these problems to me. If you run into any others or have suggestions, please feel free to open another issue!

Thank you @vincent for that additional feedback regarding the binaries; they're meant to be statically linked. I have some test builds running and if everything pans out, I'll update my pipelines here so that the next release works properly. Until then, I'll hold off on distributing further binaries as they're not going to be useful to anyone else. I'm tracking this in #20 and will tag you there when that is resolved. As for the issue in this ticket, it's resolved in commit e6e18239a7 available now on main. ```haskell tricu < [(1) (2) (99) (300) (35)] tricu > [1, 2, 99, 300, 35] ``` Lists that only contain the numbers `9`, `10`, `13`, and `32...126` will still decode as strings: ```haskell tricu < [(32) (33) (34) (35) (9) (10) (13)] tricu > " !"# " ``` This looks to be an improvement. Let me know if you have any thoughts on further improvements for this behavior. That commit also replaces the `!decode` REPL command I just mentioned to you with `!output` so that you can choose from the different output formats already implemented for the `-t` flag on `tricu eval`. I really appreciate you reporting these problems to me. If you run into any others or have suggestions, please feel free to open another issue!
James closed this issue 2025-02-07 21:25:09 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees James
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: James/tricu#18
No description provided.