On Saturday, 10 September 2022 at 19:53:11 UTC, Walter Bright wrote:
> On 9/10/2022 12:15 PM, Patrick Schluter wrote:
>> 8080/8085/Z80 opcodes when expressed in octal are much easier to handle.
>
> I've never seen 8080/Z80 opcodes expressed in octal. I know that the modregrm byte for the x86 is 2,3,3, but I deal with that by using an inline function to manipulate it. It never occurred to me to use octal. Interesting.
>
> ubyte modregrm (uint m, uint r, uint rm)
>     { return cast(ubyte)((m << 6) | (r << 3) | rm); }
>
> https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/code_x86.d#L508
>
> Of course, bit fields might be better :-)

Here a short article explaining the idea (it even works up to AMD64).

https://dercuano.github.io/notes/8080-opcode-map.html#addtoc_2

On 9/10/2022 12:00 PM, Steven Schveighoffer wrote:
> https://github.com/schveiguy/poker/blob/master/source/poker/hand.d#L261
> 
> This was so much easier to comprehend than the equivalent hex.

    assert(beststraight(0b10000000011110) == Rank.Five);
    assert(beststraight(0b10101111111110) == Rank.Ten);

Are you sure the number of digits is correct? Does your card deck really have 14 cards in a suite? :-)

Me, annoying curmudgeon that I am, would write a little parser so I could write such tests as:

   assert(beststraight(hand!"A234567890JQK") == Rank.Five);

and use HCDS for Hearts, Clubs, Diamonds, and Spaces.

D is ideal for creating such micro-DSLs, such as this one:


https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/disasm86.d#L3601

which makes adding test cases for the disassembler dramatically easier to read and compose.

On 9/10/2022 1:12 PM, mw wrote:
> I don't see any advantage of:
> 
> "...._.XX._.XX._.XX._.XX._.XX._.XX._.XX.”

That wasn't my suggestion.

On 9/10/2022 2:13 PM, Dave P. wrote:
> static assert("
>          xxx
>          x.x
>          xxx
>          ".parse == 0b111_101_111);

Nice

On 9/11/2022 12:02 AM, Max Samukha wrote:
> As I said, we could do it differently, but binary literals + comments are just optimal for our use case.

You could do the 7 segment as:

enum ubyte[16] =
[
segment!"
  -
 | |
 | |
  -
",
segment!"
   |
   |
",
segment!"
  -
   |
  -
 |
  -
",
..
];

or even:

enum ubyte[16] = segment!"
 -        -   -
| |    |   |   |
          -   -
| |    | |     |
 -        -   -
";


D is ideal for doing micro-DSLs like this.

On Sunday, 11 September 2022 at 19:55:26 UTC, Walter Bright wrote:
> On 9/10/2022 1:12 PM, mw wrote:
>> I don't see any advantage of:
>> 
>> "...._.XX._.XX._.XX._.XX._.XX._.XX._.XX.”
>
> That wasn't my suggestion.

Then what's your suggestion in this scenario?

And what's your suggestion for the int binary literal => string repr => int round trip example:

https://forum.dlang.org/post/bilqldkymsjgcmbrnqqq@forum.dlang.org

On 9/11/2022 4:00 PM, Steven Schveighoffer wrote:
> Again, the test is easy to compose and understand -- because it's in binary.

For you, I accept that. But the only binary language I understand is that of moisture vaporators.

On Sunday, 11 September 2022 at 20:11:36 UTC, Walter Bright wrote:

> or even:
>
> enum ubyte[16] = segment!"
>  -        -   -
> | |    |   |   |
>           -   -
> | |    | |     |
>  -        -   -
> ";
>
>
> D is ideal for doing micro-DSLs like this.

Nice trolling.)