Implements the "to radix" command to quickly and temporary convert a number or the result of an expression to a different radix (for example when working with memory address and segments sizes):

cork> 0xCAFE to dec
51966
cork> 0xCAFE + 2 * 8 * 0x20 to dec
52478
cork> 0xCAFE + 2 * 8 * 0x20
0xccfe
cork> ans to bin
0b1100110011111110
cork> 1234 to hex
0x4d2
cork> (0xCAFE + 2 * 8 * 0x20) to oct
0o146376

If an expression has value 0, you will only see the base (e.g. "0x", or "0b" / ""). This fixed it by adding a '0' character, if the number was 0

This pull request adds support for some bitwise operations:

• AND via "&"
• OR via "|"
• XOR via "^"

What remains unclear to me is how to define operator precedence here. As well, what operations should take precedence over others now that it's possible to mix bitwise operations and "normal" ones. Any feedback or comments you may have would be very appreciated!

Define the format for a file holding the user's configuration preferences and implement the logic to read and parse that file at start-up.

Preferably, the file should be expected to be found under ${XDG_CONFIG_HOME}/cork/, as per the XDG Base Directory Specification.

This seems like a useful little tool! While I was playing with it I tried shifting and noticed shift operations were not implemented yet. It looked easy enough to add them so I threw together a quick PR.

Hi, it would awesome if were possible to make direct operations on a single line, so it can be used with a batch file, something like: cork 0x4DEE72 + 0x18CF5 >filename.txt Actually it outputs :

error: Found argument '0x4DEE72' which wasn't expected, or isn't valid in this context

USAGE:
    cork [OPTIONS]

For more information try --help

Cheers

This Pull Request aims to solve the issue #12.

• New flag added (short = -f, long = --file)
• Refactored the command processing from the interactive, so we wouldn't have code repetition.
• Created a new module to handle the file processing
• New function to be called when the flag -f is passed.

For readability of the numbers, it is sometimes desired to add separators to long numbers (for example, writing 0x3000_0000 to avoid confusion with 0x3000000 or 0x300000000); could this be supported by cork? As long as those separators aren't valid operators, it should simply mean stripping arguments from expected separators before converting them to integers.

As an illustration, consider the following:

cork> 0x3000_0000 + 0x200_0000
Failed to parse "0x3000_0000 + 0x200_0000":  --> 1:7
  |
1 | 0x3000_0000 + 0x200_0000
  |       ^---
  |
  = expected EOI, add, subtract, multiply, divide, rem, lshift, or rshift

Although this is requested for hex numbers, I guess it would also be valid for other bases and characters other than _: for example 10'000'000, 10,000,000? The hex case being the most interesting, of course.

Cork currently ignores command-line arguments; instead, it could be extended to accept an expression, compute and print it, and exit.

For example:

$ cork 0x10 + 0x10
0x20
$ cork
Welcome to cork - a calculator for hex-lovers!
Press Ctrl + D to exit.
cork> 0x10 + 0x10
0x20
cork>

(note that, in the first case, cork returns immediately)

The welcome message is cute:

$ cork
Welcome to cork - a calculator for hex-lovers!
Press Ctrl + D to exit.
cork> 

but is far from being crucial: there should be a way to disable it, if desired.

A good way would be through an option in a config file (see #2).

Lines are interpreted the same way if they had been typed in. Evaluated in order, expressions give outputs. Set directives are evaluated, but emit no output.

• Short arg: "-f"
• Long arg: "--file"

Hi, it would be really useful to have a "to radix" command to quickly and temporary convert a number or the result of an expression to a different radix (for example when working with memory address and segments sizes):

cork> 0xCAFE to dec
51966
cork> 0xCAFE + 2 * 8 * 0x20 to dec
52478
cork> 0xCAFE + 2 * 8 * 0x20
0xccfe
cork> ans to bin
0b1100110011111110
cork> 1234 to hex
0x4d2
cork> (0xCAFE + 2 * 8 * 0x20) to oct
0o146376

It's nice to be able to set of to another base but is still a bit verbose, in particular when done for a single operation.

Could cork be extended to support an operator that temporarily switches of to what makes sense in a "do what I mean" manner?

For example, the ? operator could result in hex values being printed as decimal and decimal as hex, irrespective of of. Consider

cork> set of dec
cork> 1 + 1
2
cork> 42?
0x2a

cork> set of hex
cork> 0x10 + 0x10
0x20
cork> 0x100?
256

instead of having to manually manage of:

cork> set of hex
cork> 42
0x2a
cork> set of dec

cork> set of dec
cork> 0x100
256
cork> set of hex

I can't decide whether ?'s behavior should be dependent on of, though ...

If support for more niche bases is desired (or to disambiguate complex expressions), ? could also take an optional right operand that represents the requested base:

cork> set of hex
cork> 0x20 + 3
0x23
cork> 0x20 + 3?
Failed to parse "0x20 + 3?":  --> 1:9
  |
1 | 0x20 + 3?
  |         ^---
  |
  = ambiguous expression, expected right operand for base
cork> 0x20 + 3?b
0b100011
cork> 0x20 + 3?d
35

Another approach could also be to overload the case of receiving a single literal of the current of by reflecting it in the alternative base:

cork> set of hex
cork> 0x100
256
cork> set of dec
cork> 256
0x100

which is definitely more informative than the current behavior:

cork> set of hex
cork> 0x100
0x100
cork> set of dec
cork> 256
256

If worth the added complexity, support for other alternative bases than the respective "default ones" (i.e. hex for decimal and decimal for hex), could be implemented through a new set property. For example:

cork> set of hex
cork> set alter_of bin
cork> 0x100
0b100000000