Intro

So … as we learn rust, exercises and puzzles are obviously valuable (at least in the early stages).

But IMO, jumping into just trying to write actually functional and useful programs can be very valuable.

I’ve been away for a bit and was wondering what I should do to start up rust learning again and figured that trying to power through some simple but not trivial program would be great. Then I figured people learning rust here might find the process worthwhile too.

The Idea of the Challenge

  • Pose a challenge in a post, outlining roughly what sort of program should be written, and at roughly what level it’s pitched.
  • Propose a time period during which people can try to write the program, while having as much of a discussion as they like about it of course
  • When the time period is up, make another post inviting everyone to post where they got up to, posting code so we can discuss and provide feedback.

Any thoughts on this?

If you’ve got ideas for other challenges, feel free to post them. If there are a number of ideas it might be best to catalogue them and run them every week or month so as not to clog things.

The Challenge

A file diff program. Basically something like git diff or diff/colordiff.

git diff --no-index A B
  • Takes two files/paths as inputs, “A” and “B”.
  • Determines the differences between them, or rather, what changes have been made to “B” relative to “A”.
  • Changes are measured on a line by line bases (generally like git).
  • Provides some sort of output showing these changes.

Discussion

As I see it (not being an expert in this sort of program), there are three kinds of changes:

  • Addition
  • Deletion
  • Alteration

The difference between them depends, as far as I can understand right now, on whether lines surrounding the changed lines are duplicated in the reference file (file “A” lets say) and where they occur in the reference file relative to the changes.

I’ve got rough ideas about how this could work (which may be very wrong!) but I suspect working out the logic (if you haven’t done it before) is a good part of the challenge as you then have to map that to rust.

We can talk about the logic in the comments here though, of course.

Also, an alteration here is really a deletion + addition, so not necessary, but it makes sense to me so I might try to implement it.

Otherwise, the output is open ended I’d say … whatever makes sense to you. My first thought is JSON (which presents a chance to maybe try serde?). Something like:

[
  {
    "start_line_no": 0,
    "end_line_no": 1,
    "lines": ["this is a line of text", "and another"],
    "type": "unchanged"
  },

  {
    "start_line_no": 2,
    "end_line_no": 3,
    "lines": ["an added line",],
    "type": "addition"
  },

  ...
]

Probably a few complications there I haven’t thought about, but you get the idea. You could even go further and supplement the program with a renderer that takes this JSON and produces HTML or something else.

Time

I’d say we can have a decent shot at this in a week. So how about I post again in a week asking how we all did.

  • JayjaderM
    link
    fedilink
    English
    arrow-up
    3
    ·
    7 months ago

    Some thoughts:

    • file diff-ing can be a great project, but it can also be a never-ending recursive nest of special cases and problems - especially if you want structured output beyond a list of byte offsets. It’s important to not start out thinking “I can design a program that will always find all of the differences between 2 arbitrary files”. A good list of assumptions to start with could include “files are always UTF-8 encoded”, “files are never empty”, “lines are always separated by \n” (or \n\r if you’re on Windows?), “files are never larger than 250Mib [arbitrarily chosen small enough to fit in RAM on any modern-ish personal computing device]”.

    • the timed constraint for the challenges might not be the best approach, long-term. Granted, given how young this community is right now, it could be better to “keep us focused on the same thing” for now. Story time: when I was in engineering school, the computer club operated a CTF leaderboard. The challenges were all designed to introduce you to different aspects of cybersecurity, and they all remained permanently available (akin to Codingame, LeetCode, and similar websites). Coming back to Rust for Lemmings, we could at least maintain a list of past challenges (as its own meta-post, for ex, to be easily linked in the sidebar). That way, at some point, anyone not feeling up to the “current” challenge can attempt a previous challenge instead, and know that sharing their results will still be explicitly welcomed.

    • maegul (he/they)@lemmy.mlOPM
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 months ago

      All great points!

      And yea, on the points about presumptions … yes! I wouldn’t focus on the diffing side of stuff at all, make whatever simplifying presumptions you need to and get writing would be my approach.

      Moreover, “failure”, or not making a program that works is definitely an option! If you’re stuck somewhere, the idea at least, is that that’s helpful and informative, and if you want you can let us know where you got stuck and see if we can work it out.