Re: GUI correction and Buffer cache in 3.2 [Re: GUI.skin nil in 3.2!]

>
> Josh,
> I agree with your formulation - except for the glitch in GUI classvar skins.
> In agreement with your remarks, I would like to rephrase my proposal as
> follows:
>
> My mail addressed 2 points. It would be easier to solve the issue if these
> points are tackled separately.
>
> Point 1: GUI: adding < to classvar skins: This is a glitch that causes an
> incompatibility with the Knob quark and that is so small that it could IMHO
> be replaced in 3.2 with benefit but no harm.
>
> Point 2: Buffer:cache (and any other differences in Wesleyan release deemed
> important by the developer community): For this, a separate version should
> be created. It is beyond me at this point whether this should be 3.2.1 or
> 3.3. A list of items to update would be necessary before any further
> discussion.
>
> Iannis Z.
>
>
> On Sun, May 11, 2008 at 7:02 PM, Josh Parmenter <josh@...>
> wrote:
> >
> > It sounds like Wesleyan is living in a post 3.2 world. 3.2 can't be
> updated since it is a stable release that is tied to a publication. If you
> are using a developer version, it is no longer a stable version, and we
> can't just keep updating a version - then it is no longer a version.
> >
> >
> > We can think about making  3.3 release (or, a 3.2.1 release), but unless
> something comes down from the editors at MIT that we can make changes in
> 3.2, we can't just change the release (imo).
> >
> >
> > How do others feel about this?
> >
> >
> > Josh
> >
> >
> >
> >
> >
> >
> >
> > On May 11, 2008, at 4:32 AM, Iannis Zannos wrote:
> >
> >
> > Hello all,
> >
> > The most recent release at supercollider.wesleyan.edu differs from the 3.2
> release on sourceforge in ways that people (not just me) keep bumping into:
> > 1. Knob does not work because of omitting the accessor to classvar skins.
> > 2. Wesleyan includes a Buffer cache mechanism that is not in 3.2 (see
> Buffer:cache)
> >
> > Could those two aspects be updated in the 3.2 release on sourceforge
> please to avoid further inconsistencies?
> >
> > Iannis Zannos
> >
> > GUI {
> >     classvar <scheme, <schemes, <skin, skins;
> > change to:
> > GUI {
> >    classvar <scheme, <schemes, <skin, <skins;
> > --------------------------
> >
> >
> > On Thu, May 8, 2008 at 12:31 PM, Iannis Zannos <zannos@...> wrote:
> >
> > >
> > > Hello,
> > >
> > > OK I found the mistake:
> > >
> > > GUI {
> > >     classvar <scheme, <schemes, <skin, skins;
> > >
> > > The skins classvar was missing a < accessor constructor.
> > > As a result, because GUI is made to respond to all messages it does not
> understand by looking them up in scheme, skins returned nil, because there
> was nothing stored under 'skins' in the current scheme.
> > >
> > > So the correction is to prepend < to skins:
> > >
> > > GUI {
> > >     classvar <scheme, <schemes, <skin, <skins;
> > >
> > > By the way making a class respond to all messages it does not understand
> by looking them up in some event it contains is a wonderful way to make
> debugging really hard. I do not know if the design pattern under which GUI
> is modelled requires this to be done, if yes, well then so be it, but I
> would like to point out that this kind of pattern should be avoided for
> classes that form part of the SCClassLibrary core.
> > >
> > > Iannis Z.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 7, 2008 at 3:36 PM, ronald kuivila <rkuivila@...>
> wrote:
> > >
> > > >
> > > > Hi all,
> > > >
> > > >
> > > >   GUI:skin is not initialized in the 3.2 release.
> > > >   Is there a way to fix this or add a disclaimer?
> > > >
> > > >
> > > > RJK
> > > >
> > > >
> > > > On May 7, 2008, at 8:30 AM, Iannis Zannos wrote:
> > > >
> > > >
> > > > Hi Ron,
> > > >
> > > > Thanks for the help. I finally tracked it down.
> > > > The problem most likely is that the 3.2 release from sourceforge has
> GUI broken. The Wesleyan release has the GUI class working all right.
> Details:
> > > >
> > > > In the SourceForge release:
> > > > GUI.knob
> > > > returns Knob
> > > > But that is not the problem.
> > > > The problem is that GUI.skin is nil
> > > > So in Knob:init,
> > > > GUI.skin.knob fails because of nil.knob.
> > > >
> > > > So I tried installing a GUI skin. The help file says:
> > > > "You can switch the GUI kit by calling one of the following class
> methods:
> > > > GUI.cocoa;    // use cocoa in subsequent GUI creation procedures"
> > > > So I did that.
> > > > But GUI.skins remains nil.
> > > >
> > > > I removed all quarks and my library, I put debugging messages in
> Meta_GUI:initClass
> > > > and found that, Meta_GUI:initClass actually fills GUI.skins with an
> environment as needed.
> > > > However after compilation, GUI.skins returns magically nil.
> > > >
> > > > I also added debug messages in Meta_CocoaGUI:put and doesNotUnderstand
> > > > But they do not seem to get called.
> > > > Then I did a fresh install of SuperCollider with the extras, one
> without the extras and one from Wesleyan.
> > > > The sourceforge both had GUI.skins nil. ...
> > > > The Wesleyan download from april 08 did the job. Knob works.
> > > > This version appears to differ from the official stable release of 3.2
> in at least one more way:
> > > > Use of Buffer:cache instead of Buffer.waitForBufInfo.
> > > >
> > > > Would it not be time now to update 3.2 or at least do a merge with the
> Wesleyan release in some form?
> > > > Do other people have the problem with Knob on the 3.2 release from
> SourceForge?
> > > >
> > > > Iannis
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, May 7, 2008 at 2:07 PM, ronald kuivila <rkuivila@...>
> wrote:
> > > >
> > > > >
> > > > > Hi Iani,
> > > > >
> > > > >
> > > > > I don't have a problem with the example.
> > > > >
> > > > >
> > > > > It looks like it may be something to do with GUI or GUI.skins on
> your system.
> > > > > I would try a fresh install.
> > > > > But, if you want to try to chase it down, look for the points where
> knob is used as a selector.
> > > > > In Knob, you see:
> > > > >
> > > > >
> > > > >
> > > > > kit = GUI.schemes[ \cocoa ];
> > > > > if( kit.notNil, { kit.knob = Knob });
> > > > > kit = GUI.schemes[ \swing ];
> > > > > if( kit.notNil, { kit.knob = Knob });
> > > > >
> > > > >
> > > > > and
> > > > >
> > > > > skin = GUI.skins.knob.default;
> > > > >
> > > > >
> > > > > For a start, see if GUI.knob returns nil.
> > > > >
> > > > >
> > > > > RJK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On May 7, 2008, at 2:15 AM, Iannis Zannos wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > > I installed the Knob quark and tried the following example from the
> help file:
> > > > >
> > > > > // examples
> > > > > (
> > > > > var window, size = 32; // try different sizes - from 15 to 200 or
> more!
> > > > > window = SCWindow.new("Knob", Rect(640,630,270,70)).front;
> > > > > k = Knob.new(window, Rect(20, 10, size, size));
> > > > > k.action_({|v,x,y,m| postf("action func called: %\n", v.value); });
> > > > > //k.color[1] = Color.gray(alpha:0);
> > > > > )
> > > > >
> > > > > The error message is attached below.
> > > > > Any help in fixing this?
> > > > >
> > > > > Iannis Zannos
> > > > >
> > > > >
> =======================================================================
> > > > >
> > > > > ERROR: Message 'knob' not understood.
> > > > > RECEIVER:
> > > > >    nil
> > > > > ARGS:
> > > > > CALL STACK:
> > > > >     DoesNotUnderstandError:reportError   15E818B0
> > > > >         arg this = <instance of DoesNotUnderstandError>
> > > > >     Nil:handleError   15E81850
> > > > >         arg this = nil
> > > > >         arg error = <instance of DoesNotUnderstandError>
> > > > >     Thread:handleError   15E81AF0
> > > > >         arg this = <instance of Thread>
> > > > >         arg error = <instance of DoesNotUnderstandError>
> > > > >     Object:throw   15E817F0
> > > > >         arg this = <instance of DoesNotUnderstandError>
> > > > >     Object:doesNotUnderstand   15E81610
> > > > >         arg this = nil
> > > > >         arg selector = 'knob'
> > > > >         arg args = [*0]
> > > > >     Knob:init
> > > > > ERROR: Message 'knob' not understood.
> > > > > RECEIVER:
> > > > >    nil
> > > > > ARGS:
> > > > > CALL STACK:
> > > > >     DoesNotUnderstandError:reportError   1600D310
> > > > >         arg this = <instance of DoesNotUnderstandError>
> > > > >     Nil:handleError   1600D2B0
> > > > >         arg this = nil
> > > > >         arg error = <instance of DoesNotUnderstandError>
> > > > >     Thread:handleError   1600D3D0
> > > > >         arg this = <instance of Thread>
> > > > >         arg error = <instance of DoesNotUnderstandError>
> > > > >     Object:throw   1600D370
> > > > >         arg this = <instance of DoesNotUnderstandError>
> > > > >     Object:doesNotUnderstand   1600CE90
> > > > >         arg this = nil
> > > > >         arg selector = 'knob'
> > > > >         arg args = [*0]
> > > > >     Knob:init   164E4630
> > > > >         arg this = <instance of Knob>
> > > > >         arg parent = <instance of SCWindow>
> > > > >         arg bounds = <instance of Rect>
> > > > >         var size = nil
> > > > >         var widthDiv2 = nil
> > > > >         var center = nil
> > > > >     < closed FunctionDef >   1600CEF0
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Sc-devel mailing list
> > > > > Sc-devel@...
> > > > > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> > > > >
> > > > > _______________________________________________
> > > > > Sc-devel mailing list
> > > > > Sc-devel@...
> > > > > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> > > > >
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sc-devel mailing list
> > > > Sc-devel@...
> > > > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> > > >
> > > > _______________________________________________
> > > > Sc-devel mailing list
> > > > Sc-devel@...
> > > > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> > > >
> > > >
> > >
> > >
> >
> > _______________________________________________
> > 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
> >
> >
>
>
> _______________________________________________
>  Sc-devel mailing list
>  Sc-devel@...
>  http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
>