6 kyu
mkdir -p
189 of 982xcthulhu
Loading description...
Fundamentals
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Lua translation!
JS testing framework is SEVERELLY outdated (8.1.3) and needed to be upgraded up to 18.x
This comment has been hidden.
In the previous discourse / Python solution discussion, author mentioned that recursion is actually not mandatory & has a different meaning in this context.
Perhaps this kata is still salvageable?
Dunno, but why did they put the word "recursively" in the description if there's no check for that
Honestly, I think this kata has the right to exist but it needs some reworking imo
upgraded to Node 18.
the usage of the word "recursive" in the context of file systems has a specific meaning and does not imply that the user's solution should use recursion
@trashy_incel tfw you overthought about one meaning but forgot about other meanings :skull:
This comment has been hidden.
This comment has been hidden.
C translation with random tests (author gone)
The second
itblock has no tests, and the group is marked with red color as if a test failed.fixed
No random tests.
Good kata. Keep going with such ones based on Node API.
I'm stuck on where to begin; for example, should I start at the head and work backwards? Any feedback or hint would be helpful.
Am I allowed to import os module in python script. If yes, it is not allowing me to do so. It is throwing NameError for 'os' name.
I don't understand why but the os can't be imported for the tests
Seems like I have the only recursive solutions, so sad that is does not even appear on the solution site - just 100 ways to not do the work as recommanded
The question is not to make a recursive function, the question is to make a recursive directory creation.
We call that recursive because it gets deeper and deeper in the structure: http://unix.stackexchange.com/questions/49263/recursive-mkdir
But to be honest the option -p in mkdir doesn't stand for recursive but "parent" which means, create the parents directory if they don't exist.
Ok I think technically you are right IVBakker but i was also disappointed. As I am still at the beginning of my learning I figured out a recursive solution and was pretty proud of it because its also the first time I used the OS module, so two new things tackled!
I hoped to check others submissions for different approaches to solving this kata with a recursive function. Unfortunately i could not find one :/.
This comment has been hidden.
As I've said elsewhere, you shouldn't be using recursion. It's not best practices. It makes your code slower. Sure, it's cute, but so is a giant my little pony.
You wouldn't want to see your family crushed under a giant my little pony, would you? No, you would not.
And neither should you want them crushed under a callstack by some runaway directory making program.
In alfe's defense, the description states: "Write a synchronous function that makes a directory and recursively makes all of its parent directories as necessary".
Does the word "recursively" mean something different here than a direction on how to solve the problem? Maybe something related to unix file system commands?
This comment has been hidden.
I think using recursive programming is also a good choice if you are sure that the stack usage and the performance aren't issues. If it makes the code more elegant it is easier to understand and less likely to have bugs like off-by-ones (generally speaking, not related to this kata). There's a reason why recursive functions can quickly be proven while iterations need some ugly bastards like the horrific Hoare logic (http://en.wikipedia.org/wiki/Hoare_logic) for the same task.
@alfe I agree that understanding recursion is important and there may be times when it is the best solution. However, it is more important to know when to use it or when not to use it. In this kata what would be the advantage recursion? In this example the recursive solution I was able to find was far more complex then the simplest iterative solutions which didn't rely on any fancy library functions.
The simple iterative solutions I know (also the ones given here) all have drawbacks (like raising errors in case you have paths with unreadable parts in the beginning (what no test case checks) or being uselessly complex in case you had extremly long paths, maybe on very slow file systems like sshfs over a very slow line). As I said elsewhere in this thread, there's a reason the offcial library solution (the mkdirs() in the os module) is implemented recursively. To catch all the problems would be much more complex in an iterative solution. So people tend to ignore them, and if the test cases here do not check for them, people feel they've got a good solution. But ignoring unfound errors ist nothing more than an illusion.
If you disagree and like to go on with the discussion, you can point out to me a concrete iterative solution here and I will tell you concretely what aspects on it I don't like.
alfe, I'm a bit confused by what you're trying to say.
Sometimes that's not the case. I haven't heard of a Javascript engine that implements tail-end recursion optimizations. I have also seen incredibly pointless code in widely-distributed libraries.
I'm trying to say that in this case there is a good reason why the solution in the standard library (os module) is a recursive one. Of course this is far from a mathematical proof for this approach being the best, but it is a hint. The recursion solves a lot of special cases very elegantly which would be hard to address in an iterative way. For example, I haven't seen an elegant iterative solution which omits investigating the leftmost path parts.
And, btw, tail-recursion is relevant if you have very deep recursions (to avoid the stack overflow) or if you intend to pass very large data structures (to avoid copying performance loss). In this case, however, you will have a depth in the dozens or less, and creation of directories typically isn't done very often. With such numbers, readability and compactnes (if leading to obvious correctness) always beats performance, IMHO.
Description should also contain some links to
fs&&fs.mkdir..I mentioned
fsin the description, and I also gave instructions for pythonresolving then
Description should contain information which arguments are passed to function And description states
Write an asynchronous function ..., but function is synchronous.Thanks for the feedback! It means a lot that you help me out with the feedback process.
I added an example... does that make things clearer?
Yes, that's OK