On 1/7/22 06:03, chopchop wrote:

> I am actually asking the community for code review

I've just looked at this.

> - correct any mistake you could find

It looks fine to me. There are a few places that made me think:

In general, adding two Coordinates is suspicious to me:

  https://github.com/Fr3nchK1ss/SnakeD/blob/master/source/coordinate.d#L37

However, subtracting two Coordinates makes sense and should return a Distance object.

The following invariant check might be a 'static assert':

  https://github.com/Fr3nchK1ss/SnakeD/blob/master/source/ground.d#L26

(invariant has runtime cost.)

Accounting for the walls with +1, -1, etc. looks scary to me. I wonder whether the playground could be detached from the walls and you could use the familiar 0 indexed access. Perhaps by slicing inside a bigger area or by a special type that hides that logic from us.

A random thought about 'in' and 'out' contract blocks: Instead of adding statements inside these blocks, one can use functions to give a name to the check and also use the new contract syntax:

  https://github.com/Fr3nchK1ss/SnakeD/blob/master/source/snake.d#L78

So, instead of the following:

    in {
        // The snake shall not backtrack on itself
        assert(body[0] + unitMotion[direction] != body[1]);
    }

Something like this:

  bool updateBody(Direction direction)
  in (!doesBackTrack(direction), "Snake backtracks")
  {
    // The body of the function ...
  }

(Note 'do' is not used with the new syntax.)

> Important note: I discovered there are 2 levels of contract testing.
> 1. Checking that the code is sound, like verifying func param, etc

That is also a responsibility of unit testing.

> 2. Ensuring that the game will work as a standard snake game! Think
> win/loose conditions, etc.

That part is definitely outside of unit testing and is handled both by contract programming and by functional testing.

> I am from the aero industry [...] Buffer overflow on board a plane [...]
> I had been wondering for a while if D could be a part of the solution,
> hence this project.

What do you think? Can the industry guidelines be sufficient to make D safe enough? Otherwise, a D program can spend a long time during a GC cycle. (So can other languages where destruction of even a single object can spend a lot of time but nobody pays attention to that.) Also, the program can run out of memory unless run-time dynamic allocation is banned by guidelines.

Ali

On Tuesday, 11 January 2022 at 17:40:48 UTC, Ali Cehreli wrote:
> In general, adding two Coordinates is suspicious to me:
You are right, there should be Coordinate and Vector somehow

> Accounting for the walls with +1, -1, etc. looks scary to me. I wonder whether the playground could be detached from the walls and you could use the familiar 0 indexed access. Perhaps by slicing inside a bigger area or by a special type that hides that logic from us.
Yes, that's a bit disturbing at first. I just re-read Ground, in fact there is a lack of consistency in the use of those +1, which is probably confusing. I will work on it.
But I kept the walls as part of the playground, because indeed they are, and the snake can reach "into" the wall. This is of course a GameOver condition, but perfectly legit! I realized with those "+1" that loosing is part of the game :)
I discovered that the real problem is when the snake tries to reach "beyond" the wall, which is then a programming error, and there is a contract on that.

>use the new contract
I did not know about the new syntax! I am definitely going to use it.

> What do you think? Can the industry guidelines be sufficient to make D safe enough? Otherwise, a D program can spend a long time during a GC cycle. (So can other languages where destruction of even a single object can spend a lot of time but nobody pays attention to that.) Also, the program can run out of memory unless run-time dynamic allocation is banned by guidelines.
>
> Ali
I would say, planes don't do sharp turn :) Maybe small UAVs (drones) would be more sensitive to delays. Reliability is more a factor. But how much delay are we talking about? More like 1ms, 10ms, 100ms, 1sec? I mean, if you can give an example of a program and its delay, it's interesting.

Then my project has limited focus, GC is another thing. A lot of components for aero subsystems are in C, and BetterC retains unittesting... and contract if I am not mistaken? Also those subsystems have very precise requirements which can most often translate into static arrays, etc. There would be so much to explore...

On 1/23/22 07:33, chopchop wrote:

> it took me a while to find the documentation about the new
> "expression-based" syntax that Ali is talking about:
>
> https://dlang.org/changelog/2.081.0.html#expression-based_contract_syntax

Yeah, coming late to the party, that syntax gets just a brief mention here:


http://ddili.org/ders/d.en/contracts.html#ix_contracts.expression-based%20contracts

Ali

On Friday, 7 January 2022 at 14:03:23 UTC, chopchop wrote:
> Hi guys,
>
> I am working on a personal - and FOSS - project, available here:
> https://tinyurl.com/kv62kr7t
> (Tiny url => becoz of results ranking on search engines)

btw. please.. use full urls.

https://safecomputing.umich.edu/be-aware/phishing-and-suspicious-email/shortened-url-security

On Tuesday, 11 January 2022 at 17:40:48 UTC, Ali Cehreli wrote:
> The following invariant check might be a 'static assert':
>
>   https://github.com/Fr3nchK1ss/SnakeD/blob/master/source/ground.d#L26
>
> (invariant has runtime cost.)
>
> Ali

Does the compiler not rewrite `assert`s into `static assert`s if there is no dependence on runtime values? Maybe this is a worthwhile optimization to implement.

On Monday, 24 January 2022 at 12:41:40 UTC, Mark wrote:
> On Tuesday, 11 January 2022 at 17:40:48 UTC, Ali Cehreli wrote:
>> The following invariant check might be a 'static assert':
>>
>>   https://github.com/Fr3nchK1ss/SnakeD/blob/master/source/ground.d#L26
>>
>> (invariant has runtime cost.)
>>
>> Ali
>
> Does the compiler not rewrite `assert`s into `static assert`s if there is no dependence on runtime values? Maybe this is a worthwhile optimization to implement.

https://d.godbolt.org/z/46q6osKjK The assertions must still happen at runtime, however if the compiler can prove (as it does with *any* function) that it cannot be called then it will elide the assert.

Hi guys,

I finished this little project about contract programming. Not much, but interesting to do.

This is a link to the github project (tinyed for google referencing)

https://tinyurl.com/yc8yvj6n

cheers