|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
|
|
[commit?] Server.sendQuit optionHiho,
would it be ok to add an option to Server to whether or not it should be sent a quit message, when using quitAll? This would prevent remote servers from being quit, upon class recompilation, which is desirable when the server runs remotely (e.g. in another city). (Stefan Kersten originally (back in 2005) made this addition for a sound installation of ours, but it never got proposed or committed, maybe it has be solved already by another option?) sincerely, Marije Index: build/SCClassLibrary/Common/Control/Server.sc =================================================================== --- build/SCClassLibrary/Common/Control/Server.sc (revision 7516) +++ build/SCClassLibrary/Common/Control/Server.sc (working copy) @@ -135,7 +135,7 @@ classvar <>local, <>internal, <>default, <>named, <>set, <>program; var <name, <addr, <clientID=0; - var <isLocal, <inProcess; + var <isLocal, <inProcess, <>sendQuit; var <serverRunning = false, <serverBooting=false, bootNotifyFirst=false; var <>options,<>latency = 0.2,<dumpMode=0, <notified=true; var <nodeAllocator; @@ -550,7 +550,13 @@ } *quitAll { - set.do({ arg server; if(server.isLocal or: {server.inProcess} ) {server.quit}; }) + set.do({ arg server; + if ((server.sendQuit === true) + or: {server.sendQuit.isNil and: {server.isLocal or: {server.inProcess}}}) { + server.quit + }; + }) + // set.do({ arg server; if(server.isLocal or: {server.inProcess} ) {server.quit}; }) } *killAll { // if you see Exception in World_OpenUDP: unable to bind udp socket _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionCurrently Server.quitAll should not try to quit remote servers. Do you find that it does otherwise? I tested on my machine by doing (substituting my real machine name for "my-computer") z = Server(\test, NetAddr("my-computer.local", 57109)); z.isLocal answered false, so I started scsynth at the command line with scsynth -u 57109 -b 1026. Quitting SuperCollider.app did not stop the scsynth instance. So at this point I don't see the benefit of this change -- it might give a bit more control, or allow you to specify a local server that should not be quit automatically, but for the stated purpose (protecting remote servers from autoquit) the app already handles that. hjh On Apr 19, 2008, at 6:09 PM, nescivi wrote:
: H. James Harkins : http://www.dewdrop-world.net .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionHi,
On Sunday 20 April 2008 12:17:19 James Harkins wrote: > Currently Server.quitAll should not try to quit remote servers. Do > you find that it does otherwise? Ah, I just remembered why exactly we needed it... we were using a tunneling ruby script to escape any firewalls we might have along the way, so the ruby script was pretending to be a local server. So actually the feature would be to have local servers not sent quit, which can be beneficial also in another situation, e.g. when you have to recompile the lang during a performance, and want to keep the sound running, so no one notices. sincerely, Marije > I tested on my machine by doing (substituting my real machine name > for "my-computer") > > z = Server(\test, NetAddr("my-computer.local", 57109)); > > z.isLocal answered false, so I started scsynth at the command line > with scsynth -u 57109 -b 1026. > > Quitting SuperCollider.app did not stop the scsynth instance. So at > this point I don't see the benefit of this change -- it might give a > bit more control, or allow you to specify a local server that should > not be quit automatically, but for the stated purpose (protecting > remote servers from autoquit) the app already handles that. > > hjh > > On Apr 19, 2008, at 6:09 PM, nescivi wrote: > > Hiho, > > > > would it be ok to add an option to Server to whether or not it > > should be sent > > a quit message, when using quitAll? > > > > This would prevent remote servers from being quit, upon class > > recompilation, > > which is desirable when the server runs remotely (e.g. in another > > city). > > > > (Stefan Kersten originally (back in 2005) made this addition for a > > sound > > installation of ours, but it never got proposed or committed, maybe > > it has be > > solved already by another option?) > > > > sincerely, > > Marije > > > : H. James Harkins > : jamshark70@... > : http://www.dewdrop-world.net > > .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: > > "Come said the Muse, > Sing me a song no poet has yet chanted, > Sing me the universal." -- Whitman _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionBut how would the lang know then that the server is running after re-
compile? I like the idea, but I think there will have to be some way to handle book-keeping (especially since there are a number of classes that keep track of things on a server). Best, Josh On Apr 20, 2008, at 11:09 AM, nescivi wrote: > Hi, > > On Sunday 20 April 2008 12:17:19 James Harkins wrote: >> Currently Server.quitAll should not try to quit remote servers. Do >> you find that it does otherwise? > > Ah, I just remembered why exactly we needed it... we were using a > tunneling > ruby script to escape any firewalls we might have along the way, so > the ruby > script was pretending to be a local server. > > So actually the feature would be to have local servers not sent > quit, which > can be beneficial also in another situation, e.g. when you have to > recompile > the lang during a performance, and want to keep the sound running, > so no one > notices. > > sincerely, > Marije > >> I tested on my machine by doing (substituting my real machine name >> for "my-computer") >> >> z = Server(\test, NetAddr("my-computer.local", 57109)); >> >> z.isLocal answered false, so I started scsynth at the command line >> with scsynth -u 57109 -b 1026. >> >> Quitting SuperCollider.app did not stop the scsynth instance. So at >> this point I don't see the benefit of this change -- it might give a >> bit more control, or allow you to specify a local server that should >> not be quit automatically, but for the stated purpose (protecting >> remote servers from autoquit) the app already handles that. >> >> hjh >> >> On Apr 19, 2008, at 6:09 PM, nescivi wrote: >>> Hiho, >>> >>> would it be ok to add an option to Server to whether or not it >>> should be sent >>> a quit message, when using quitAll? >>> >>> This would prevent remote servers from being quit, upon class >>> recompilation, >>> which is desirable when the server runs remotely (e.g. in another >>> city). >>> >>> (Stefan Kersten originally (back in 2005) made this addition for a >>> sound >>> installation of ours, but it never got proposed or committed, maybe >>> it has be >>> solved already by another option?) >>> >>> sincerely, >>> Marije >>> >> : H. James Harkins >> : jamshark70@... >> : http://www.dewdrop-world.net >> >> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: >> >> "Come said the Muse, >> Sing me a song no poet has yet chanted, >> Sing me the universal." -- Whitman > > > _______________________________________________ > Sc-devel mailing list > Sc-devel@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel ****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/ “Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono */ _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionHi Josh,
On Sunday 20 April 2008 14:38:24 Josh Parmenter wrote: > But how would the lang know then that the server is running after re- > compile? hmmm... it could look for it using zeroconf (or rendezvous, or whatever it is called). > I like the idea, but I think there will have to be some way to handle > book-keeping (especially since there are a number of classes that keep > track of things on a server). Sure, you'd have to be prepared for it, somehow... (maybe read your history log and try and find back all the synths to the server?) If I were to use the option, I would surely find some way to do it, given time. sincerely, Marije > > Best, > > Josh > > On Apr 20, 2008, at 11:09 AM, nescivi wrote: > > Hi, > > > > On Sunday 20 April 2008 12:17:19 James Harkins wrote: > >> Currently Server.quitAll should not try to quit remote servers. Do > >> you find that it does otherwise? > > > > Ah, I just remembered why exactly we needed it... we were using a > > tunneling > > ruby script to escape any firewalls we might have along the way, so > > the ruby > > script was pretending to be a local server. > > > > So actually the feature would be to have local servers not sent > > quit, which > > can be beneficial also in another situation, e.g. when you have to > > recompile > > the lang during a performance, and want to keep the sound running, > > so no one > > notices. > > > > sincerely, > > Marije > > > >> I tested on my machine by doing (substituting my real machine name > >> for "my-computer") > >> > >> z = Server(\test, NetAddr("my-computer.local", 57109)); > >> > >> z.isLocal answered false, so I started scsynth at the command line > >> with scsynth -u 57109 -b 1026. > >> > >> Quitting SuperCollider.app did not stop the scsynth instance. So at > >> this point I don't see the benefit of this change -- it might give a > >> bit more control, or allow you to specify a local server that should > >> not be quit automatically, but for the stated purpose (protecting > >> remote servers from autoquit) the app already handles that. > >> > >> hjh > >> > >> On Apr 19, 2008, at 6:09 PM, nescivi wrote: > >>> Hiho, > >>> > >>> would it be ok to add an option to Server to whether or not it > >>> should be sent > >>> a quit message, when using quitAll? > >>> > >>> This would prevent remote servers from being quit, upon class > >>> recompilation, > >>> which is desirable when the server runs remotely (e.g. in another > >>> city). > >>> > >>> (Stefan Kersten originally (back in 2005) made this addition for a > >>> sound > >>> installation of ours, but it never got proposed or committed, maybe > >>> it has be > >>> solved already by another option?) > >>> > >>> sincerely, > >>> Marije Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionOn Apr 20, 2008, at 11:46 AM, nescivi wrote:
> Hi Josh, > > On Sunday 20 April 2008 14:38:24 Josh Parmenter wrote: >> But how would the lang know then that the server is running after re- >> compile? > > hmmm... > it could look for it using zeroconf (or rendezvous, or whatever it > is called). > >> I like the idea, but I think there will have to be some way to handle >> book-keeping (especially since there are a number of classes that >> keep >> track of things on a server). > > Sure, you'd have to be prepared for it, somehow... > (maybe read your history log and try and find back all the synths to > the > server?) > If I were to use the option, I would surely find some way to do it, > given > time. > set, if can poll the status of there Server (is it running, collect nodeIDs, allocated buffer ids, etc) and, after the recompile, reset these states for Objects that need it (nodeAllocator, bufferAllocator, etc.). This can probably actually be done on the Lang side itself. Since it is a special case, it shouldn't break anyone's code. Josh > sincerely, > Marije > > >> >> Best, >> >> Josh >> >> On Apr 20, 2008, at 11:09 AM, nescivi wrote: >>> Hi, >>> >>> On Sunday 20 April 2008 12:17:19 James Harkins wrote: >>>> Currently Server.quitAll should not try to quit remote servers. Do >>>> you find that it does otherwise? >>> >>> Ah, I just remembered why exactly we needed it... we were using a >>> tunneling >>> ruby script to escape any firewalls we might have along the way, so >>> the ruby >>> script was pretending to be a local server. >>> >>> So actually the feature would be to have local servers not sent >>> quit, which >>> can be beneficial also in another situation, e.g. when you have to >>> recompile >>> the lang during a performance, and want to keep the sound running, >>> so no one >>> notices. >>> >>> sincerely, >>> Marije >>> >>>> I tested on my machine by doing (substituting my real machine name >>>> for "my-computer") >>>> >>>> z = Server(\test, NetAddr("my-computer.local", 57109)); >>>> >>>> z.isLocal answered false, so I started scsynth at the command line >>>> with scsynth -u 57109 -b 1026. >>>> >>>> Quitting SuperCollider.app did not stop the scsynth instance. So at >>>> this point I don't see the benefit of this change -- it might >>>> give a >>>> bit more control, or allow you to specify a local server that >>>> should >>>> not be quit automatically, but for the stated purpose (protecting >>>> remote servers from autoquit) the app already handles that. >>>> >>>> hjh >>>> >>>> On Apr 19, 2008, at 6:09 PM, nescivi wrote: >>>>> Hiho, >>>>> >>>>> would it be ok to add an option to Server to whether or not it >>>>> should be sent >>>>> a quit message, when using quitAll? >>>>> >>>>> This would prevent remote servers from being quit, upon class >>>>> recompilation, >>>>> which is desirable when the server runs remotely (e.g. in another >>>>> city). >>>>> >>>>> (Stefan Kersten originally (back in 2005) made this addition for a >>>>> sound >>>>> installation of ours, but it never got proposed or committed, >>>>> maybe >>>>> it has be >>>>> solved already by another option?) >>>>> >>>>> sincerely, >>>>> Marije > _______________________________________________ > Sc-devel mailing list > Sc-devel@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel ****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/ “Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono */ _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionHiho,
On Sunday 20 April 2008 14:49:22 you wrote: > > On Sunday 20 April 2008 14:38:24 Josh Parmenter wrote: > >> But how would the lang know then that the server is running after re- > >> compile? > > > > hmmm... > > it could look for it using zeroconf (or rendezvous, or whatever it > > is called). > > > >> I like the idea, but I think there will have to be some way to handle > >> book-keeping (especially since there are a number of classes that > >> keep > >> track of things on a server). > > > > Sure, you'd have to be prepared for it, somehow... > > (maybe read your history log and try and find back all the synths to > > the > > server?) > > If I were to use the option, I would surely find some way to do it, > > given > > time. > > Perhaps if a Server has the isLocalDontForTheLoveOfAllThingsQuit flag > set, if can poll the status of there Server (is it running, collect > nodeIDs, allocated buffer ids, etc) and, after the recompile, reset > these states for Objects that need it (nodeAllocator, bufferAllocator, > etc.). This can probably actually be done on the Lang side itself. > Since it is a special case, it shouldn't break anyone's code. indeed. Don't you think that the name you propose for the flag is a bit long though? ;) sincerely, marije > > Josh > > > sincerely, > > Marije > > > >> Best, > >> > >> Josh > >> > >> On Apr 20, 2008, at 11:09 AM, nescivi wrote: > >>> Hi, > >>> > >>> On Sunday 20 April 2008 12:17:19 James Harkins wrote: > >>>> Currently Server.quitAll should not try to quit remote servers. Do > >>>> you find that it does otherwise? > >>> > >>> Ah, I just remembered why exactly we needed it... we were using a > >>> tunneling > >>> ruby script to escape any firewalls we might have along the way, so > >>> the ruby > >>> script was pretending to be a local server. > >>> > >>> So actually the feature would be to have local servers not sent > >>> quit, which > >>> can be beneficial also in another situation, e.g. when you have to > >>> recompile > >>> the lang during a performance, and want to keep the sound running, > >>> so no one > >>> notices. > >>> > >>> sincerely, > >>> Marije > >>> > >>>> I tested on my machine by doing (substituting my real machine name > >>>> for "my-computer") > >>>> > >>>> z = Server(\test, NetAddr("my-computer.local", 57109)); > >>>> > >>>> z.isLocal answered false, so I started scsynth at the command line > >>>> with scsynth -u 57109 -b 1026. > >>>> > >>>> Quitting SuperCollider.app did not stop the scsynth instance. So at > >>>> this point I don't see the benefit of this change -- it might > >>>> give a > >>>> bit more control, or allow you to specify a local server that > >>>> should > >>>> not be quit automatically, but for the stated purpose (protecting > >>>> remote servers from autoquit) the app already handles that. > >>>> > >>>> hjh > >>>> > >>>> On Apr 19, 2008, at 6:09 PM, nescivi wrote: > >>>>> Hiho, > >>>>> > >>>>> would it be ok to add an option to Server to whether or not it > >>>>> should be sent > >>>>> a quit message, when using quitAll? > >>>>> > >>>>> This would prevent remote servers from being quit, upon class > >>>>> recompilation, > >>>>> which is desirable when the server runs remotely (e.g. in another > >>>>> city). > >>>>> > >>>>> (Stefan Kersten originally (back in 2005) made this addition for a > >>>>> sound > >>>>> installation of ours, but it never got proposed or committed, > >>>>> maybe > >>>>> it has be > >>>>> solved already by another option?) > >>>>> > >>>>> sincerely, > >>>>> Marije Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionOn Apr 20, 2008, at 11:56 AM, nescivi wrote:
> Don't you think that the name you propose for the flag is a bit long > though? ;) It will certainly keep people from setting it accidently. Josh ****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/ “Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono */ _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionOn Apr 20, 2008, at 2:46 PM, nescivi wrote:
Starting the aliveThread should be sufficient. If it sends /status to the server and gets a reply, it knows the server is running. hjh : H. James Harkins : http://www.dewdrop-world.net .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionOn Apr 20, 2008, at 2:09 PM, nescivi wrote:
Another way to handle this is, if you know the name or IP address of the local machine, create the NetAddr using that instead of the usual 127.0.0.1. Server decides whether an instance is local or not by comparing the address to 127.0.0.1. It doesn't check whether other IP addresses actually point to the local machine or not. So it's already possible to have a "non-local" server that sends messages to a process running on the local machine. I do kind of see what you're after, but I'm not totally convinced it's necessary because there is still a way to do what's needed in this special case. I wouldn't stand in the way if others decide it's a definitely-needed new feature. hjh : H. James Harkins : http://www.dewdrop-world.net .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit option2008/4/20, James Harkins <jamshark70@...>:
> > On Apr 20, 2008, at 2:09 PM, nescivi wrote: > > On Sunday 20 April 2008 12:17:19 James Harkins wrote: > Currently Server.quitAll should not try to quit remote servers. Do > you find that it does otherwise? > > Ah, I just remembered why exactly we needed it... we were using a tunneling > ruby script to escape any firewalls we might have along the way, so the ruby > script was pretending to be a local server. > > Another way to handle this is, if you know the name or IP address of the > local machine, create the NetAddr using that instead of the usual 127.0.0.1. > Server decides whether an instance is local or not by comparing the address > to 127.0.0.1. It doesn't check whether other IP addresses actually point to > the local machine or not. > > So it's already possible to have a "non-local" server that sends messages to > a process running on the local machine. > > I do kind of see what you're after, but I'm not totally convinced it's > necessary because there is still a way to do what's needed in this special > case. I wouldn't stand in the way if others decide it's a definitely-needed > new feature. To me it all sounds tricky/messy to implement, and not very well-motivated, sorry. Hopefully JH's IP address trick caters for the (unusual) situation. Dan _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionOn Monday 21 April 2008 06:51:27 Dan Stowell wrote:
> 2008/4/20, James Harkins <jamshark70@...>: > > On Apr 20, 2008, at 2:09 PM, nescivi wrote: > > > > On Sunday 20 April 2008 12:17:19 James Harkins wrote: > > Currently Server.quitAll should not try to quit remote servers. Do > > you find that it does otherwise? > > > > Ah, I just remembered why exactly we needed it... we were using a > > tunneling ruby script to escape any firewalls we might have along the > > way, so the ruby script was pretending to be a local server. > > > > Another way to handle this is, if you know the name or IP address of the > > local machine, create the NetAddr using that instead of the usual > > 127.0.0.1. Server decides whether an instance is local or not by > > comparing the address to 127.0.0.1. It doesn't check whether other IP > > addresses actually point to the local machine or not. > > > > So it's already possible to have a "non-local" server that sends messages > > to a process running on the local machine. > > > > I do kind of see what you're after, but I'm not totally convinced it's > > necessary because there is still a way to do what's needed in this > > special case. I wouldn't stand in the way if others decide it's a > > definitely-needed new feature. > > To me it all sounds tricky/messy to implement, and not very > well-motivated, sorry. Hopefully JH's IP address trick caters for the > (unusual) situation. Hmm... with a small fix to NetLib this would work, I guess... (this fix is necessary anyway for myIP to work on Linux, since normally ifconfig is not in the path for the normal user, but lies in /sbin/). I'll commit it to the quarks if there is no objection. + NetAddr{ *myIP { |prefix=""| var j, k, res, bc; res = Pipe.findValuesForKey(prefix++"ifconfig", "inet"); ... sincerely, Marije _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: [commit?] Server.sendQuit optionOn Monday 21 April 2008 18:03:30 nescivi wrote:
> On Monday 21 April 2008 06:51:27 Dan Stowell wrote: > > 2008/4/20, James Harkins <jamshark70@...>: > > > On Apr 20, 2008, at 2:09 PM, nescivi wrote: > > > > > > On Sunday 20 April 2008 12:17:19 James Harkins wrote: > > > Currently Server.quitAll should not try to quit remote servers. Do > > > you find that it does otherwise? > > > > > > Ah, I just remembered why exactly we needed it... we were using a > > > tunneling ruby script to escape any firewalls we might have along the > > > way, so the ruby script was pretending to be a local server. > > > > > > Another way to handle this is, if you know the name or IP address of > > > the local machine, create the NetAddr using that instead of the usual > > > 127.0.0.1. Server decides whether an instance is local or not by > > > comparing the address to 127.0.0.1. It doesn't check whether other IP > > > addresses actually point to the local machine or not. > > > > > > So it's already possible to have a "non-local" server that sends > > > messages to a process running on the local machine. > > > > > > I do kind of see what you're after, but I'm not totally convinced it's > > > necessary because there is still a way to do what's needed in this > > > special case. I wouldn't stand in the way if others decide it's a > > > definitely-needed new feature. > > > > To me it all sounds tricky/messy to implement, and not very > > well-motivated, sorry. Hopefully JH's IP address trick caters for the > > (unusual) situation. > > Hmm... > with a small fix to NetLib this would work, I guess... > (this fix is necessary anyway for myIP to work on Linux, since normally > ifconfig is not in the path for the normal user, but lies in /sbin/). ok, it works. I'll commit the necessary changes to NetLib for retrieving the IP of the host. sincerely, Marije _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
| Free Forum Powered by Nabble | Forum Help |