@JackboyPlay "like the project is on a server or something else": We call it Saros Server, see http://www.saros-project.org/ongoing-work (under "dormant work"). Feel free to get in touch if you're interested in furthering that development.
OK, the XMPP problem has to do with our build-server migration a while back. Changed the secondary host-name of the machine running the XMPP server, which said server did not take too well. This problem did not surface before probably because this was the first system reboot after the hostname change.
Hi, I would like to introduce a code of conduct in the saros project. The "Contributor Covenant" is very common, simple and contains all necessary information. What do you think?
@m273d15 Could you provide a way of setting the base path for the IntelliJ sandboxes through an environmental variable? The default option to use the build directory if no path is set is fine, but it really annoys me to always have to set up the settings for sandboxes again after cleaning the project.
http://saros-build.imp.fu-berlin.de/sarosDoc/interfacede_1_1fu__berlin_1_1inf_1_1dpp_1_1filesystem_1_1_i_folder.html Do we have an updated version of this ?
http://saros-build.imp.fu-berlin.de/sarosDoc/interfacede_1_1fu__berlin_1_1inf_1_1dpp_1_1filesystem_1_1_i_folder.html Do we have an updated version of this ?
I don't think so. You can try to create the current javadoc with ./gradlew javadoc, but my first try was not successful. Probably the configuration is not correct or we have errors in our documentation. We should fix it.
@m273d15 Would it be possible to cache a version of the google java formatter? Some format builds run more than 6 minutes: https://travis-ci.com/saros-project/saros/jobs/177809507
As others finish in about a minute, I would guess that the actual formatting should not take more than about 45 seconds. My guess would be that the download is inconsistent, which sometimes slows down the build unnecessary.
As others finish in about a minute, I would guess that the actual formatting should not take more than about 45 seconds. My guess would be that the download is inconsistent, which sometimes slows down the build unnecessary.
@tobous Yes, travis provides a caching mechanism for arbitrary directories. This should lead to a consistent download time.
It would be also possible to cache the gradle dependencies, but I never enabled this feature, because I was not sure how the invalidation mechanism works ... and we know
It would be also possible to cache the gradle dependencies, but I never enabled this feature, because I was not sure how the invalidation mechanism works ... and we know
There are only two hard things in Computer Science: cache invalidation and naming things.
We recently merged a large scale refactoring of the directory/package structure of the saros repository. This mail on our developer mailing list gives some information about needed steps for your local development environment after the refactoring and on how to resolve the merge conflicts when rebasing.
Is somebody available for a debug-session? I having problems while working on the requested changes in #444.
I can't running (and writing) stf tests like https://github.com/saros-project/saros/blob/master/eclipse/test/stf/saros/stf/test/session/DerivedResourcesTest.java by simple click on "run Junit-Test" in Eclipse. Which set up is necessary? Is there available any help/manual ?
If the new guide is not sufficient, please add the missing information from the old documentation :wink: .
Hey there 👋So I submitted my first PR to the Saros project and also addressed feedback of the initial review round. (Thanks for providing the feedback that quick!) Now I wondered about the expected commit message style for those commits where I address review remarks. Since the PR is probably squashed upon merging (is this the case?) the commit message tags (INTERNAL, DOCS, etc.) are probably not all that relevant. What's common here? Sticking to the format just for aiding during review, or is this not defined that exact?
Here's the PR as reference: saros-project/saros#482
Hello David, welcome and thanks for your first PR!
Since the transition to github is more or less in progress, the new guidelines page is not yet actively published, but contains information about the tags used for commit messages and the review process description is here.
So the guidelines state that every commit message should be formatted accordingly, but this is a child of the Gerrit Review era when squash was not used. As you suspected, your commits are candidates for squashing and since your messages are meaningful enough for review, it looks good for me.
Since the transition to github is more or less in progress, the new guidelines page is not yet actively published, but contains information about the tags used for commit messages and the review process description is here.
So the guidelines state that every commit message should be formatted accordingly, but this is a child of the Gerrit Review era when squash was not used. As you suspected, your commits are candidates for squashing and since your messages are meaningful enough for review, it looks good for me.
Hey, is somebody available to take a look at #212. For unknown reason the build is queued forever. I need a review, too.
Is there any consensus on whether we want to be able to handle dropped network activities? (e.g. an activity is correctly send by one participant but never received by the others). @stefaus do you know which kind of network protocols we are using and whether they have any protection against package loss? I am asking because package loss is still a case that is not correctly handled by the new vector time reset logic
From my current point of view, it is the only issue (handling the loss of deletion activities or ACKs) holding back the PR saros-project/saros#714 from my side (besides a minor outstanding adjustment filtering out certain checksum activities)
From skimming the code: ActivitySequencer is adding sequence numbers and checks them executeActivities(...).
As for the direct connection, TCP is used, so package loss is handled low level and retransmissions are tried.
For IBB Connections depends on the error type, if network drops, than again its TCP Handled and again retransmissions are tried.
If the Server drops single messages, than ActivitySequencer should handle this and simply drops the user.
@stefaus @m273d15 Time to test saros-project/saros#714 in a multi-user session? I created the branch https://github.com/saros-project/saros/tree/test_branch_714 for this purpose. It just add some logging and artificially increases the log level to make the important ones easier to spot.
There is documentation on how to compile for Eclipse. Just make sure you run the gradle script with prepareEclipse option. Afterwards you can compile the project through the Eclipse IDE. Starting Tobias modification it simple. Checkout the patch, compile, and select a run configuration on simply launch it. A second Eclipse instance will open in which the plugin is already running.
@tobous I can join the session if you like. Please send me an email with the specific time.
@srossbach Yeah, you just missed it :wink: But we didn't really get far testing the patch as we found other issues regarding deleting files in Saros/E. When other users are actively typing in an editor while its file is deleted, it can happen that the editor stays open after the file was deleted on disk/from the workspace (even for the user that deleted the file in the first place). The issue seems to be that the editor is in a modified state when the file is deleted. But I haven't had time to investigate this further.
Actually, now that I think about it, the first issue should theoretically also be fixed by the activity filter introduced with the vector time fix if the issue is really edit activities received after the deletion. If, however, the issue is the modified state of the editor on deletion, this would not be the case. We moved away from testing the vector time patch relatively quickly as we wanted to make sure that the issues couldn't be reproduced on the master. I am not sure whether the editor issue was present with the vector time patch. Either way, I will have a closer look at the logs. @srossbach if you are interested, I can also create an issue for it later this evening and upload the logs so that you can have a look at it as well.
Well, normally, the editor also gets closed automatically. This seems to be dependent on the editor state as far as I can tell. My guess would be that the editor doesn't get closed automatically when the local editor is in an unsaved state (maybe to avoid information loss?).
This is important for the consistency check, as it is based on open editors. During our tests, the editor did not stay open for all participants (maybe only for the host?), leading to inconsistency state triggers for other participants whose editor was correctly closed. This inconsistency was triggered even though the content on disk should have been consistent (as the file was also no longer present on disk on the host's side as well).
This is important for the consistency check, as it is based on open editors. During our tests, the editor did not stay open for all participants (maybe only for the host?), leading to inconsistency state triggers for other participants whose editor was correctly closed. This inconsistency was triggered even though the content on disk should have been consistent (as the file was also no longer present on disk on the host's side as well).
Maybe an explicit handling of the editor would fix the issue. In Saros/I, the logic closes the editor, disables the save listener (to ensure that no unnecessary activities are created), saves the file to disk and then deletes the file (and re-enables the listeners). This ensures that there aren't any inconsistent states between the representation of the file on disk and as a "document" (loaded content modifiable in the editor).
Also, Eclipse seems to try to handle this. It warns the user when an unsaved file is deleted. Maybe this warning causes the editor to be saved to avoid such issues. Of course, this would not work when the editor is edited in parallel by incoming activities. Is there any blocking logic or can such a parallel access (i.e. an editor is modified while the local deletion triggered by the user is processed) happen? The warning dialog does not appear to be modal (i.e. the Eclipse seems to run unhindered in the background while the window is open), so maybe that is an issue as well.
We execute any activity regardless if there is a modal dialog present or not as Eclipse has no support for this and I am will not install my own synchronizer into the SWT display. The whole Eclipse stuff is a little bit more complicated. Especially the change on how the content for editors is retrieved has broken many things regarding the watchdog. The problem is that we hold a reference for each user on the buffer of the editor. If these references are not cleared, i.e no editor close event is send, the content of the editor is still present on the host although the file that belong to the editor is already deleted. Last time I did a test the watchdog did not detect anything although this was working at some point. Open a file. Modify it and then set the remote user to read-only and close the file. You will not get an inconsistency warning. Even if you reopen the file on the host you still will not get an inconsistency warning although you can see that the content did not match. Only after you insert at least 1 character an inconsistency is detected.
While having a look at the log files, I notices that the log files for Saros/E are still ASCII encoded, while log files for Saros/I use UTF8. I only notices this as they displayed umlaut characters as their encoding instead of the character itself (i.e. 'ö' as '\u00F6'), so this isn't really an issue, it just seems weird to me.
Is there a reason to use ASCII (besides the reduced file size)?
Is there a reason to use ASCII (besides the reduced file size)?
@Flowdalic Uff, its been a while. I think the smack stuff just got lost in the chaos. :sweat_smile: But we are still very much interested in updating smack. We have been working hard on updating our outdated libraries along with our build infrastructure and smack is one of the big ones, especially since it provides a central functionality of the plugin and is in a somewhat messy state with all of the patch stuff we added. So we really appreciate your efforts.
I had a short look at your branch but didn't really get far. (But I am also not that well-versed in the network part of Saros, so that doesn't really mean that much :wink:) As @srossbach already mentioned, formatting the code with our formatter (google java format 1.6) reduces the PR size considerably (from +3300 -4800 LOC to +1000 LOC - 2700 LOC, which is still a lot, but more manageable).
The patch seems like a WIP (judging from the compiler errors). Are you still interested in working on the migration? If so, what are your general plans? Maybe we can work out some sort of cooperation to make the migration easier. :smile: Do you have a general estimate on how much work still is necessary to complete the migration?