Merged exeFactories back to master #6

Closed
wants to merge 18 commits into
from

Projects

None yet

1 participant

@bscottm
Contributor
bscottm commented Oct 27, 2010

I played with EclipseFP for a while, didn't encounter any significant issues other than the existing completion bug. I think this is reasonably stable... (famous last words...)

This also has all of your commits merged, so the difference should just be my changes.

Scott Michel added some commits Oct 21, 2010
Scott Michel Deal with scion-server abnormal termination and recovery. 1d8dc3b
Scott Michel Merge branch 'master' of http://github.com/JPMoresmau/eclipsefp 9e7ee3c
Scott Michel Merge branch 'master' of git://github.com/JPMoresmau/eclipsefp 765812d
Scott Michel interim_101022
Revamp scion command processing because JP runs into problems with thread
deadlocks and other anamolies (which is wierd, because I don't see anything
similar.)
b560ba3
Scott Michel Merge branch 'master' of github:bscottm/eclipsefp 5af1b8a
Scott Michel Merge branch 'master' into exeFactories
Conflicts:
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/internal/commands/ThingAtPointCommand.java
088d5c9
Scott Michel Merge branch 'master' of http://github.com/JPMoresmau/eclipsefp into …
…exeFactories
83ad382
Scott Michel scionserver_101025
- Completely eliminate ICommandContinuation. We can do better
  with a list of Job classes instead of using an interface if we want
  to run something after a command receives a response.
- Add support for continuations that are based on the Eclipse Job
  class. Easier to debug because they show up in the Progress
  pane.
- Convert some of the current commands back to their original
  asynchronous form.
- Make sure that command processing is more robust than it was
  originally.
8412fb3
Scott Michel Prevent multiple built-in scion server build jobs from being
spawned.
e3cd4f7
Scott Michel More stability fixes. This also has a built-in test case for sync
and async command processing. Successor command processing
is probably correct, but since this isn't actually used, it is untested.
57b3824
Scott Michel Merge branch 'master' of http://github.com/JPMoresmau/eclipsefp into …
…exeFactories

Conflicts:
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/internal/servers/ScionServer.java
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/internal/servers/StdStreamScionServer.java
f21e763
Scott Michel merge_101026
- Merge branch 'master' of http://github.com/JPMoresmau/eclipsefp into
  exeFactories, incorporate the OutputWriter code to prevent UI thread
  nastiness.

Conflicts:
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/internal/servers/ScionServer.java
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/internal/servers/StdStreamScionServer.java

- If scion-server returns an error, ensure that no further command
  processing is done. This prevents later NPEs.

- Move the code that sends a quit command to the scion-server into
  ScionServer so that we don't block indefinitely waiting for a
  response.
b936bdc
Scott Michel merge_101027
Merge branch 'master' of http://github.com/JPMoresmau/eclipsefp into exeFactories

Conflicts:
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/client/ScionInstance.java
0498aa0
Scott Michel merge_101027_exeFactories
Merge branch 'exeFactories' of github:bscottm/eclipsefp into exeFactories

Conflicts:
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/internal/servers/ScionServer.java
	net.sf.eclipsefp.haskell.scion.client/src/net/sf/eclipsefp/haskell/scion/internal/servers/StdStreamScionServer.java
75c2b0f
Scott Michel scionserver_101027
Ensure that the command queue is emptied before taking any
actions during shutdown.
63e881e
Scott Michel scionserver_101027a
Make the command queue monitor's output for a stalled queue more informative,
printing the commands and request ids that are stalled.

Also changed my mind regarding successor commands in buildProject(). Still
wondering why successor commands still need to exist if they're never used
and the program's control flow really determines what command is next
executed.
32cf5e4
Scott Michel Remove gratuitous Job around a reloadFile. 631dc5e
Scott Michel Minor tweak for style. 79722ff
@bscottm
Contributor
bscottm commented Oct 28, 2010

Should be a 19th commit that deals with a persistent quit command that triggers stalled queue messages (which shows that the monitor works, but not quite for the right reason.)

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment