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

IMHO, this is not the time to go to a new version number. The book
will correspond to version 3.2 and it would be self-defeating for the
community to release 3.2.1 or 3.3 before the book is out. The "glitch
in GUI classvar skins" has never affected me and IMHO will not affect
many people - for those who find it a problem, they can decide whether
to use the bleeding-edge development version, which indeed many people
do.

The development version includes many many changes, including much
more prominent ones. Some of them are currently brand-new and
unpolished (e.g. the help search) and so it's not right to solidify on
a point release yet.

Dan


2008/5/12 Iannis Zannos <zannos@...>:

>
> 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
>
>

--
http://www.mcld.co.uk

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel