-
Notifications
You must be signed in to change notification settings - Fork 195
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
[Obsolete] Introduce Commenting Feature and Simultaneous Coding Environment. #551
base: master
Are you sure you want to change the base?
Conversation
…HC i.e. remove unused libraries and overshadowing of variables Rearranges the code to make it more readable. Fixes the warnings of GHC i.e. remove unused libraries and overshadowing of variables
…and backend are not compatible.(Comment and Folder modules may not compile. Yet to complete certain handlers)
…ers with codeworld-server
Parv, I started to take a look, but before I get much further, let me address a few high-level questions:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a start to the review. I will need to look more at this later, but I don't think I'm able to understand it until I can see it running. So let's prioritize getting a test server running (whether it's yours or mine)
build.sh
Outdated
@@ -43,9 +43,11 @@ run codeworld-api cabal haddock --hoogle | |||
|
|||
# Build codeworld-server from this project. | |||
|
|||
run . cabal_install ./codeworld-server \ | |||
run . cabal_install ./third_party/ot.hs \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this even do? You're passing an individual Haskell source file to cabal_install?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait which file? That is a directory. It contains the source code for operational transformations.
@@ -24,20 +24,30 @@ Executable codeworld-server | |||
cryptonite, | |||
data-default, | |||
directory, | |||
engine-io, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the multi-player gaming API, we decided to separate the game server from the web server, because it was less critical and more susceptible to denial-of-service or other failures. I believe that the same thing applies here, as well. Relaying real-time messages to other clients is dangerous, and if collaborative editing fails for a bit, it's better than the web site being down.
Instead of adding yet another server, can you rename codeworld-game-server, and add this functionality there, instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure would make the required changes!
filepath, | ||
filesystem-trees, | ||
funblocks-server, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear to me why this is a separate library. What's up here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file structure for funblocks and codeworld are different. So, the handlers for handling files in both have different logic. I thought it would be best to have a separate library for the same. Any other suggestions over how to accommodate this?
|
||
module Collaboration (module Collaboration__) where | ||
|
||
import Collaboration_ as Collaboration__ hiding (getFrequentParams) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh? Can you explain what you're doing here? Why not just put the code in Collaboration instead of aliasing a second (and hideously named) module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was used as a way to get around the fact that haskell requires you to explicitly export functions you want to export. This allows to hide the functions you do not want to export. But now I can see that looks kind of a hack and ugly. So, I will change that.
user <- getUser clientId | ||
mode <- getBuildMode | ||
case getType of | ||
1 -> do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, no! At least, use the type system. This is Haskell. But better yet, decompose the problem in a way that's less arbitrary.
file = userProjectDir mode (userId user) </> finalDir </> projectFile projectId | ||
case length path' of | ||
0 -> return (user, mode, file) | ||
_ -> case path' !! 0 of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not capture the first element in the top-level case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I don't why I didn't do that. Lazy evaluation should allow that. Will update that.
|
||
funblockRoutes :: ClientId -> [(B.ByteString, Snap ())] | ||
funblockRoutes clientId = | ||
[ ("floadProject", loadProjectHandler clientId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is extremely unfortunate. Why should all the blocks UI stuff be so separate?
I feel like if I merge this change, that will be the day that Blocks starts to bitrot. All of a sudden, it will share almost no code with the main site, and so its code will get further behind over time, until it's an unmaintainable mess. I am not ready to give up on it yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you on this but new file structure for collaboration would require this to happen. A solution would be to let even funblocks use that but then it will only create some unnecessary files. Any suggestions for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like most of the file manipulation should be the same. The blocks UI should have no trouble supporting folders and such. The only change should be disabling collaborative editing. (In theory, that could eventually be implemented too; it would just require a different OT model and integration with Blockly!) My hope would be that they would mostly share code, with a few buttons being disabled. But I don't understand the functionality yet, so it's hard for me to propose a specific answer.
third_party/ot.hs/.ghci
Outdated
@@ -0,0 +1,4 @@ | |||
:set -fwarn-unused-binds -fwarn-unused-imports |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot review your changes to the ot library, because I have no way to tell what's yours, and what is part of the original. And, sorry, I can't do a complete code review for the third party ot library.
Is it possible to see a diff for your changes somehow? Have you submitted your changes upstream, so that CodeWorld isn't maintaining a fork of this library indefinitely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for this. There were no changes made by me over here. I will remove this and add a dynamic installation of ot.hs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait as a matter of fact I did made changes to the cabal file. The dependencies specified were not being resolved.
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: ot-0.2.1.0 (user goal)
next goal: ghc (dependency of ot-0.2.1.0)
rejecting: ghc-8.0.1/installed-8.0... (conflict: ghc =>
binary==0.8.3.0/installed-0.8..., ot => binary>=0.5.1.1 && <0.8)
Dependency tree exhaustively searched.
Resolving this still gave more dependency errors. So I removed the versions. The only change is the following:
25,32c25,32
< Build-depends: base,
< text,
< aeson,
< attoparsec,
< QuickCheck,
< binary,
< either,
< mtl,
---
> Build-depends: base >= 4 && < 5,
> text >= 1.0 && < 1.3,
> aeson >= 0.7 && < 0.11,
> attoparsec >= 0.10.1.1 && < 1,
> QuickCheck >= 2.7 && < 2.9,
> binary >= 0.5.1.1 && < 0.9,
> either >= 4.1.2 && < 5,
> mtl >= 2.1.3.1 && < 3,
Using --allow-newer
should resolve this.
As I mentioned the migration script we cannot(or preferable not to) add an offline migration script because user identifiers are need to be associated which each file. So, one way would be ask a common user identifier once and for all or to prompt for a user identifier whenever a file that doesn't has a user identifier associated with it. Which one do you prefer? Also, I do not have a demo server that you would be able to access. I agree you should test them before merging. As of right now I do not have access to any server on which I can host. Can you try to setup one?(I will see if I can arrange one if possible. Having exams next week) |
Not being able to migrate users to the new directory structure is definitely a problem. This dooms the project to maintaining code for the legacy file structure, basically forever. If this is just about the user choosing a nickname to identify themselves in comments, then let's assign one ("anonymous"?) that's always used, and they can change it later if desired. |
I still need to set up a test server and try this out. Unfortunately, the last week has been very busy for me. I'll try to get to this ASAP. |
Sorry for being so late in sending the PR. Some of the key highlights of the changes made are:
Note: Please do merge this right now. I would post a script here to migrate existing users files to the new file structure. Or else if you want users to be migrated online as and when required I can make the required changes.
The new file structure:
commentables
, which contains all the projects user can comment on but cannot edit. Note that user will not be able to make changes so in such a case I have a introduced aTest Code
button which will generate a test environment.commentables
into the editable category of project. Such copying will only preserve source codes. One cannot copy in tocommentables
directory.commentables
intocommentables
and not outside of that.data/mode/projectContents
independent of which user they belong to. The project would be stored with a filename which is a hash ofdata/mode/projects/userId/userPath
. Here userId will be chosen randomly from one of the many users that can edit this file.Simultaneous coding:
Collaborate
button and whoever accesses this link will be given complete access to edit.Current Owners
button.Commenting:
Note: For funblocks I have created a new server as it had conflicting handlers due to different file structures.
If I have missed anything new I will comment it below. Suggesstions are welcome. If any problems occur with this PR I will be glad to fix them.