-
-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exercises for #48in24 #940
Comments
Thanks for the heads up. I'll pick up some as I get time. If anyone would like to grab one, please leave a note here first so that no one else starts work on the same exercise. |
I will try to contribute kindergarten-garden. |
I'm going to grab spiral-matrix |
I'm also going to grab protein-translation |
Somebody on the forum wanted to help with that. Although they didn't reply in the last two days. |
Thanks for the heads up. I'll give them another few days to respond. |
Opened a PR for |
I'm going to grab knapsack |
I've given the zebra-puzzle a shot (#959) |
Put me down for yacht. I will probably get around to implement something next week. |
This was quicker than expected: #972 |
I also gave rotational-cipher a shot: #975 |
Feel free to also put me down for dnd-character and food-chain. |
About parallel-letter-frequency and bank-account, I wonder what approaches we want to support there, since both are about some form of parallelism and there's nothing in the C standard (library) to support this. pthreads would probably be the most natural, but OpenMP could also be an option? The latter would also work natively on Windows with MSVC, although the instructions about working locally sound like we don't want to support this anyways. What do you think? |
Threading is not really in my wheelhouse so I have more questions than answers 😄
|
Alright, implementing bank-account without the parallel aspect is probably fine. That's what the Python track does. The C++ track expects proper locking and has a test that spawns multiple threads, so chances are without locking this will fail. That's at least somewhat easily testable. We could do the same in C, no matter how we implement this. parallel-letter-frequency, on the other hand, without parallel processing would be quite boring. And also IMHO be against the spirit of the exercise. After all, it has "parallel" in the name! Some tracks (e.g., Python) explicitly don't want this exercise implemented. I implemented this exercise for the C++ track. To experiment with the performance aspect of the parallelism, it's nice to provide a benchmark students can run locally. For the test runner, we settled on having that only check the correctness of the result, but doing the actual computation sequentially. However, that led to confusion about solutions passing that would actually fail with true parallel execution. So I'd say we should make sure that the experience working locally is as similar as possible to what the online test runner does.
I don't believe the test library has any support for this. But it also doesn't need much. For bank-account, we would manually spawn a couple of threads to call functions in parallel. The student has to implement proper locking, but not create any threads themselves. So except for the library that is used for multithreading the test wouldn't give away much. For parallel-letter-frequency, you wouldn't see anything special in the tests, because all the parallel processing needs to be implemented by the student.
When we go with pthreads, we would be limited to POSIX platforms. For native Windows, one would have to use native Windows threads. However, the makefiles we currently use make things somewhat platform-dependent already, since MSVC wouldn't understand the flags used in there. The documentation suggests to use WSL2 when working under Windows. So there pthreads would work just fine. The only option I'm aware of that works natively on Windows (with MSVC) is OpenMP. I have used OpenMP pragmas in C++ code. That's much less low level than pthreads and would be similar in spirit to what you do in C++17 with parallel algorithms. However, I think I would find manual thread management more appropriate for a C exercise. I think that's also what the Rust example does: divide the texts into a number of blocks and have a worker thread for each block.
For bank-account, the parallelism would come from the test. Without proper locking, the test would fail. So that's fairly easy to ensure. For parallel-letter-frequency, on the other hand, I don't see any option (just like the other tracks, they all only test for correctness; so also a sequential implementation would pass). |
Sounds good @ahans ! |
Dear maintainers,
Jeremy posted an overview of the exercises that will be featured in #48in24:
http://forum.exercism.org/t/which-exercises-for-48in24/8970/19
The following featured exercises have not been translated to C yet:
I'm posting them here as a reminder.
I hope I will find the time to translate a few of them, and perhaps others will help, too.
Feel free to close or remove this issue if you do not find it helpful.
Edit:
There is now a dedicated matrix with the status of all exercises in #48in24, which tracks have implemented them, and which exercises are featured on a specific track:
https://exercism.org/challenges/48in24/implementation_status
The text was updated successfully, but these errors were encountered: