Topic/refactor server status #1547

telephon · 2015-06-15T21:03:56Z

This PR is still being developed, but it shouldn't break and can be tested.

This fixes #774 and fixes #889: instead of just assuming that the server is dead, it is taken to be unresponsive. It also fixes #1484.

It factors out all statusWatcher and recording functionality to a separate class (ServerStatusWatcher and Recorder). This branch also implements the updating of recording display in the IDE.

There is some more refactoring, in the server code itself, the Volume class, and also the allocation of buffers in Buffer.

While I took care to keep the old interface, this refactor may break code that relies on instance variables in Server, these problems are usually easy to solve, by writing, e.g. this.avgCPU instead of avgCPU.

…asleep

Some refactoring of the serverRunning_ method. This method is now really used to set the state if known. If unknown, like from the aliveThread, we call updateRunningState instead. This method will not change serverRunning if false, but will mark the server as unresponsive. Only if we quit the server from sclang explicitly, we call serverRunning_ directly.

…t for them to close down. They won't reply anyway.

…is for efficiency to keep at least serverRunning in Server, because this method is called all the time

crucialfelix · 2015-06-16T07:12:51Z

SCClassLibrary/Common/Control/Server.sc

-			aliveThread
-		}
+
+	/* backward compatibility */


I wouldn't refer to this as "backward compatibility". the statusWatcher should be considered a private object and people should not be encouraged to use it or to think that its the new way to do things.

these methods are the correct way IMO to expose the api. so I suggest removing the "backward" comment

Ah yes. I was wondering whether it is OK to have the getter to the watcher. I used it once:

*resumeThreads { set.do { |server| server.statusWatcher.resumeThread } }

I could of course add a method to Server that isolates it. What do you think?

crucialfelix · 2015-06-16T07:20:07Z

useful to clean up Server, its a mess. I would also move the gui into a separate class, but please call it ServerGUI and not ServerGui as there is already one in crucial-library.

agree: 3.8

Because CmdPeriod calls resumeThreads, all registered servers, if booted or not, have aliveThreads. This patch fixes that impolite misbehavior.

telephon · 2015-06-16T20:41:35Z

useful to clean up Server, its a mess. I would also move the gui into a separate class, but please call it ServerGUI and not ServerGui as there is already one in crucial-library.

OK, that is a good idea. I'll also write a Recorder, which can be separately refined.

Now new allocators are created after the server app is booted to protect from invalid ids.

telephon · 2015-07-08T13:49:42Z

@timblechmann I have tried to correctly implement pauseRecording in the IDE, which turned out to be difficult. After a couple of days trying I have over time resolved many issues, but still it's not doing what it should - maybe you could have a look? The PauseRecording menu entry shouldn't trigger the sclang message all the time, e.g.

telephon · 2015-07-08T13:51:37Z

@crucialfelix uh, yes, no big hurry!

timblechmann · 2015-07-08T14:12:21Z

@crucialfelix https://github.com/crucialfelix
I would also move the gui into a separate class, but please call it
ServerGUI and not ServerGui as there is already one in crucial-library.
It would be good to do a ServerView class that uses Qt properly. But I
am not very patient at this, maybe this could be fixed later. The code
is messy currently, but at least separate from the rest in
|ServerPlusGui|, and only three methods, so we can live with it in the
meantime.

do use Qt "properly" one should probably implement a QML view and move
all the gui code to qml.
if i understand jakob's qtcollider architecture correctly, it should be
quite straight-forward to implement a sc/qml bridge using
doesNotUnderstand to map selectors to qml properties ...

then one would have a gui system with modern features (delarative,
constraint-driven layouts, 60hz, vsync driven animations)

btw, @telephon: it makes sense to split a PR of 52 commit to functional
units, which can be reviewed and merged individually ...

…didn't

telephon · 2015-07-08T20:03:03Z

btw, @telephon: it makes sense to split a PR of 52 commit to functional units, which can be reviewed and merged individually ...

Yes, agreed. Unfortunately, it's a big refactoring and the commits all build on top of each other – so I'm not sure of how to do this. I've reduced and reshuffled as much as possible with rebase -i but there is a limit to what can you do here. I may be missing a trick here though.

Maybe it would have been even easier to just make one commit that removes the whole Sever class and then add things step by step ...

telephon · 2015-07-08T20:05:55Z

do use Qt "properly" one should probably implement a QML view and move all the gui code to qml.

yes, very much so. Maybe the best way to specify views would then be to embed QML in sclang directly as a string? It is very readable and adequately representing its objects in sclang would be overly complicated.

scztt · 2015-07-08T20:58:57Z

do use Qt "properly" one should probably implement a QML view and move all the gui code to qml.

yes, very much so. Maybe the best way to specify views would then be to embed QML in sclang directly >as a string? It is very readable and adequately representing its objects in sclang would be overly >complicated.

This would be cool for sure, and is probably a better match for the state-of-the-art of Qt - but, I'm unclear what the concrete gains would be... Doing even complex layouts in SC now is, for the most part, very simple and clear. Declarative layouts are powerful, but are there GUI-building tasks in SC that are currently difficult / impossible because of limitations in the layout implementation? Do we have bugs that would be fixed by vsync animation? Are there QML widgets that would be a big improvement to existing options in SC?

I don't mean to sound too skeptical (I'd love to hear other benefits of qml), but in the list of features that would have a big user-impact when UI-building in SuperCollider, I think it's down the list (refactoring .action's to a proper event-based / signal-slot pattern? exposing unexposed Qt functionality on existing widgets? WYSIWYG layout-ing? SynthDef graph display? Improved scopes? Better high-DPI & multitouch support?)

scztt · 2015-07-08T21:03:13Z

@telephon, re commits: This seems like a fine granularity? Reading through, I don't see a huge benefit to testing this in too many separate pieces. At that point, the only real impact of the commit organization is what you see in blame - which, as it's structured now, is useful enough. The one thing I would say is - given the amount of functional change, a unit test that defines how the Server API's should work (especially in terms of notifications) should absolutely be a part of this.

timblechmann · 2015-07-09T01:19:37Z

    do use Qt "properly" one should probably implement a QML view
    and move all the gui code to qml.

yes, very much so. Maybe the best way to specify views would then be
to embed QML in sclang directly >as a string? It is very readable
and adequately representing its objects in sclang would be overly
>complicated.

it would be possible to pass the qml code as string or as a QUrl (which
could be local or remote files)

This would be cool for sure, and is probably a better match for the
state-of-the-art of Qt - but, I'm unclear what the concrete gains would
be... Doing even complex layouts in SC now is, for the most part, very
simple and clear. Declarative layouts are powerful, but are there
GUI-building tasks in SC that are currently difficult / impossible
because of limitations in the layout implementation? Do we have bugs
that would be fixed by vsync animation? Are there QML widgets that would
be a big improvement to existing options in SC?

Pen is slow
animations need to be done in sclang code (no vsynced 60 hz)
guis in qml are declarative, much less update bugs
sc's current guis have hardcoded pixel sizes all over the place, which
horribly breaks on linux with variable-sized DPI, where you end up
having cropped texts ...
gui building is currently slow and error-prone ... many guis come from
a time before constraint-based layouting was invented
one could even use opengl shaders embedded in qml embedded in sclang

just a few thoughs ... jakob was already proposing this years ago ...

crucialfelix · 2015-07-09T08:06:56Z

um ... shouldn't you people be making music ?

timblechmann · 2015-07-09T08:36:53Z

i was always surprised that once you write code people think that you are not a musician ...

crucialfelix · 2015-07-09T08:48:29Z

that's not what I meant. I was referring to the endless amount of discussion about GUI that happens in supercollider development.

muellmusik · 2015-07-09T09:21:14Z

i was always surprised that once you write code people think that you are not a musician ...

And the opposite! :-)

telephon · 2015-07-09T15:38:29Z

I have to say that it would simplify a lot if we could do something like this.

Pen is slow * animations need to be done in sclang code (no vsynced 60 hz)

This is a major issue, I think: it is also low resolution. Many people are using sc to do graphics with their music, or well, visual music.

scztt · 2015-07-10T01:34:18Z

I'd love to see a proof-of-concept QML implementation of something that's better suited to QML than regular SC. Not sure what a good candidate is - maybe an animated version of Plot? I'd love to see what the performance difference is, as well as how easy it is to get data connected to the requisite drawing code in a SC vs QML version. It would be a good use-case for driving (and justifying) QML features.

scztt · 2015-07-10T01:35:23Z

This is a major issue, I think: it is also low resolution. Many people are using sc to do graphics with their music, or well, visual music.

What do you mean by low resolution? Meaning, high dpi bugs, or something else?

crucialfelix · 2015-07-10T07:21:26Z

there's this: https://github.com/jleben/quickcollider

On Fri, Jul 10, 2015 at 3:34 AM scztt notifications@github.com wrote:

I'd love to see a proof-of-concept QML implementation of something that's
better suited to QML than regular SC. Not sure what a good candidate is -
maybe an animated version of Plot? I'd love to see what the performance
difference is, as well as how easy it is to get data connected to the
requisite drawing code in a SC vs QML version. It would be a good use-case
for driving (and justifying) QML features.

—
Reply to this email directly or view it on GitHub
#1547 (comment)
.

telephon · 2015-07-10T08:46:55Z

This is a major issue, I think: it is also low resolution. Many people are using sc to do graphics with their music, or well, visual music.

What do you mean by low resolution? Meaning, high dpi bugs, or something else?

On retina screens, aliasing is broken and looks bad, even number boxes. I once added an issue, but couldn't find it anymore now.

bootNotifyFirst was implemented in a way that seemed not to work properly. This is also undocumented, so it may need someone who knows how it was supposed to work. This is why I commented it out and factored out a clearer message for server.

miguel-negrao · 2015-07-10T10:46:41Z

then one would have a gui system with modern features (delarative, constraint-driven layouts, 60hz, vsync driven animations)

Possibly I already mentioned this, in which case I apologize for re-posting, just mentioning in the interest of comparing approaches. I have a declarative system implemented in FPLib which can be used for GUI time-dependent logic. It is similar to http://elm-lang.org/. I also implemented a declarative Pen interface, although it probably makes Pen drawing even slower. Possibly QML + an FRP system on sclang's side could be interesting, although FRP causes some cognitive dissonance to imperative programmers which might be insurmountable.

https://github.com/miguel-negrao/FPLib/blob/master/Examples/FRP/ENdef-jitlib_style.scd
https://github.com/miguel-negrao/FPLib/blob/master/Examples/FRP/mouse_and_drawing.scd

telephon · 2015-09-16T19:41:55Z

Closing it, moving to branch refactoring-server-clean

telephon added 14 commits June 14, 2015 22:48

class library: server is marked as unresponsive instead of dead when …

67f3139

…asleep

class library: server - fix update server running state

b4af841

class library: scide - remove debug postings

7eb002d

class library: when killing all servers on the commandline, don't wai…

fe1d8da

…t for them to close down. They won't reply anyway.

class library: move out status updater functionality

73d5cb9

class library: server notify via status

8996b08

class library: move serverRunning methods to server. On the whole it …

f1b76d4

…is for efficiency to keep at least serverRunning in Server, because this method is called all the time

class library: server clientID setter is protected

08fbde7

class library: rename ServerStatus to ServerStatusWatcher

561e496

class library: move most status to the server status watcher class

cab4a17

class library: move more state to ServerStatusWatcher

e520626

scide: if unresponsive, label yellow independent of running or not

146e731

class library: fix update call, remove postings.

267f04c

telephon added the waiting for testing label Jun 15, 2015

telephon self-assigned this Jun 15, 2015

telephon added this to the 3.8 milestone Jun 15, 2015

crucialfelix reviewed Jun 16, 2015
View reviewed changes

telephon added 3 commits June 16, 2015 10:27

class library: avoid erroneous thread creation on cmd-period

bac80e7

Because CmdPeriod calls resumeThreads, all registered servers, if booted or not, have aliveThreads. This patch fixes that impolite misbehavior.

class library: remove unrelated debugging statements

80324c1

class library: server: fix typos and comment

0a609cb

telephon added 6 commits June 16, 2015 23:05

server: move recording specs to options and refactor boot

a3bc380

Now new allocators are created after the server app is booted to protect from invalid ids.

class library: move recording functions to Recorder class

09bc541

class library: server code cosmetics

d9e3912

class library: server watcher code cosmetics

88c9cd8

class library: server-status - simplify syntax

2cfcf90

class library: standardize code formatting

38f12c8

ide: band-aid for retriggered pausedRecording method: don't do if it …

dd3ee1c

…didn't

telephon added 4 commits July 9, 2015 16:14

class library: refactor server quit for TCP

1ed3bf6

class library: server status - use clearer method name, but keep old one

6074f91

class library: allow and protect server name changes

7e62c43

class library: don't try to connect shm-interface of remote server

6be371e

telephon added 3 commits September 13, 2015 13:50

ide: make record time reliable

e873ded

help: 3.7 news updated and reformatted

1b22283

help: improve 3.7 news. Fixes #1516

c6ee52e

telephon closed this Sep 16, 2015

telephon deleted the topic/refactor-server-status branch September 16, 2015 19:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Topic/refactor server status #1547

Topic/refactor server status #1547

telephon commented Jun 15, 2015

crucialfelix Jun 16, 2015

telephon Jun 16, 2015

crucialfelix commented Jun 16, 2015

telephon commented Jun 16, 2015

telephon commented Jul 8, 2015

telephon commented Jul 8, 2015

timblechmann commented Jul 8, 2015

telephon commented Jul 8, 2015

telephon commented Jul 8, 2015

scztt commented Jul 8, 2015

scztt commented Jul 8, 2015

timblechmann commented Jul 9, 2015

crucialfelix commented Jul 9, 2015

timblechmann commented Jul 9, 2015

crucialfelix commented Jul 9, 2015

muellmusik commented Jul 9, 2015

telephon commented Jul 9, 2015

scztt commented Jul 10, 2015

scztt commented Jul 10, 2015

crucialfelix commented Jul 10, 2015

telephon commented Jul 10, 2015

miguel-negrao commented Jul 10, 2015

telephon commented Sep 16, 2015

Topic/refactor server status #1547

Topic/refactor server status #1547

Conversation

telephon commented Jun 15, 2015

crucialfelix Jun 16, 2015

Choose a reason for hiding this comment

telephon Jun 16, 2015

Choose a reason for hiding this comment

crucialfelix commented Jun 16, 2015

telephon commented Jun 16, 2015

telephon commented Jul 8, 2015

telephon commented Jul 8, 2015

timblechmann commented Jul 8, 2015

telephon commented Jul 8, 2015

telephon commented Jul 8, 2015

scztt commented Jul 8, 2015

scztt commented Jul 8, 2015

timblechmann commented Jul 9, 2015

crucialfelix commented Jul 9, 2015

timblechmann commented Jul 9, 2015

crucialfelix commented Jul 9, 2015

muellmusik commented Jul 9, 2015

telephon commented Jul 9, 2015

scztt commented Jul 10, 2015

scztt commented Jul 10, 2015

crucialfelix commented Jul 10, 2015

telephon commented Jul 10, 2015

miguel-negrao commented Jul 10, 2015

telephon commented Sep 16, 2015