stuck at Connecting... phase when in wrong directory
Closed this issue · 10 comments
I waited a while for it to finish "connecting" but eventually cancelled before realising I hadn't CD'd into the right folder
If the tool detects the cwd is the wrong name for the attempted submission it should provide a warning and stop adding dots to the connecting. . .
Actually, it should! Behind the scenes, submit50 is using lib50's push functions, which, in turn, uses the connect function. The connect function should raise an error if not at least one file asked for by the slug you provided is present (as described here).
Did you have, by accident I guess, any file with the same name as one of the requested files by the slug? And, just to make sure, did you have a stable internet connection? In the past I had difficulties with this when GitHub servers experienced issues as well...
@cmlsharp do you have any idea why this could happen?
Yeah, so in the "connecting" phase, one of the things we do is figure out which files you're going to end up pushing. The way submit50 (I'm really talking about lib50 behind the scenes) works is that when you create a problem, you define what kinds of files you want to include in a submission via a series of 'inclusion/exclusion' rules e.g. ("i want to include all .c files, exclude foo.c, etc."). When submti50 runs, it searches recursively through your cwd to find all files that match these rules. If you want to see where exactly we do this, see here and here)
Trouble is, if you accidentally run submit50 in, say, your home directory (which has a lot of files in it), submit50 thinks you want to submit the contents of that folder, so it attempts to apply all these inclusion/exclusion rules to the entire contents of your home directory (unsurprisingly, this takes a long time). That would be my guess as to what happened here.
Not sure what the best way to fix this is tbh. One simple way could be to have submit50 print out the current directory when it begins running and hope the student catches their mistake. Another is to maybe emit a warning if we discover we are in a directory with lots of files/folders.
maybe you can check if the directory name matches the pset#. The instructions in each pset explicitly tell you what folder structure to create.
Well, this could be an option, but I don't think it's a good one. Naming your directories after the psets is just a best-practice proposal, not a requirement. Think of huge workspaces, where users are doing psets besides cs50, e.g. a follow-up course.
What we could indeed do is check whether the directory is the users home directory, and ask a y/n confirmation before starting to match the rules. I guess 90%+ of the times when a user is in the wrong directory, they are in the home directory.
maybe you can check if the directory name matches the pset#. The instructions in each pset explicitly tell you what folder structure to create.
Our PSET instructions might say this, but check50/submit50 is used by other courses, and this seems like a pretty annoying usage constraint to impose.
What we could indeed do is check whether the directory is the users home directory, and ask a y/n confirmation before starting to match the rules. I guess 90%+ of the times when a user is in the wrong directory, they are in the home directory.
This could work also, though I'd prefer a more general solution if possible (e.g. the issue is still going to crop up if, god forbid, someone types cd / first on accident)
I see why this could lead to problems. In the end, I don't think there is one nice solution that will satisfy all sources of problems.
you could optionally store the link in a 'pset file' and distribute them with the psets. Then you instruct cs50 students to use submit50 without the pset link in a command line argument so that it checks the cwd for the 'pset file'. Other courses could continue to pass the command line link and avoid this check.
Yes, that would be a solution for all of CS50's psets, but it would add another step for every pset not already distributing starting files - mind that other courses might don't do this at all now. I guess it work's as good as it should right now, using submit50 on your local machine instead of CS50's cloud IDE actually works like a charm as well. The IDE's performance also differs based on usage, something we can't control.
One thing I could think of is the following: CS50 asks you to create a folder named after the pset. Should the folder name be specified in the .yamlfile defining checks, submit50 could make sure you are in a directory named the same, and if not asking a y/n question. If this folder name isn't specified, we could still fall back to not checking at all. This would only improve the issue by a little bit, but at least your case would have been solved :) Let me know what you think!
sure I believe that would help
I really think a much better solution to this, rather than requiring students (who may not be using CS50's psets/specs) to name their directory something specific, would simply be to pause and display a warning if we begin accumulating too many files. Then we can prompt the student with the name of the directory they are currently in, ask them if they're really trying to submit 1000 files or whatever, and go from there. This seems pretty sure to solve this problem without requiring students to name the directory something specific.