4.1 to 4.2 migration question

>
> --C
>
> On Mon, Feb 16, 2015 at 7:15 PM, Phil (list) <[hidden email]>
> wrote:
>         On Mon, 2015-02-16 at 18:49 -0800, Casey Ransberger wrote:
>         > I think parserClass was there to give everyone a hook to
>         implement
>         > their own parsers, because Smalltalk was (in part) a prog
>         language
>         > research platform. Given that Cuis aims to be a minimal
>         system,
>         > someone may have removed it as unnecessary. Also, when Juan
>         changes
>         > some critical behavior, he tends to prefer coming up with a
>         new name
>         > for the method and associated variables, so that folks with
>         existing
>         > code aren't confused when their dependencies start behaving
>         in
>         > unexpected ways; this might also be what happened.
>        
>         I'm fine with it being removed... just wanted to understand
>         why it was
>         removed.  I know there's been a lot of cog/compiler/vm stuff
>         going on
>         recently that I haven't kept up on so thought I'd check in
>         before just
>         making the minimal changes to get it working again if
>         something bigger
>         is going on.
>        
>         > It would be interesting to look at what wants to refer to
>         parserClass.
>         > Could be one of those packages is doing something very, very
>         > interesting:)
>         >
>         >
>         It's from OGLExtManager...
>        
>         forwardExtMethod: aSelector
>                 "Compile a forwarder method in OpenGL"
>                 | code parser fwdCode |
>                 code := self class sourceCodeAt: aSelector.
>                 parser := self parserClass new.
>                 parser parseSelector: code.
>                 code := code copyFrom: 1 to: (parser endOfLastToken
>         min: code size).
>                 fwdCode := String streamContents:[:s|
>                         s nextPutAll: code.
>                         s newLineTab: 1; nextPutAll: '"This method was
>         automatically
>         generated"'.
>                         s newLineTab: 1; nextPutAll: '^glExt ';
>         nextPutAll: code.
>                 ].
>                 (OpenGL sourceCodeAt: aSelector ifAbsent:['']) =
>         fwdCode
>         ifTrue:[^self]. "no change"
>                 OpenGL compile: fwdCode classified: (self class
>         organization
>         categoryOfElement: aSelector).
>        
>        
>        
>        
>         _______________________________________________
>         Cuis mailing list
>         [hidden email]
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>        
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

>> This *is* interesting. Is that Igor's generated code? Stasenko, he
>> might be someone who'd know what was supposed to be going on here.
>> Odds are, if we can figure out what sort of parser is supposed to be
>> answered, we can make it work in Cuis.
> I think it predates Igor's stuff (isn't his all that newfangled
> NativeBoost stuff or am I thinking of something else?).  This package
> was based on some old Squeak FFI-based packages that I managed to track
> down ~5 years ago IIRC (before that I had a hacky extract from an old
> Croquet image.. it was ugly)
>
>> I'm interested in this stuff myself, because Cuis would be a great
>> platform to make games on if we had some solid support for OpenGL,
>> mainly because it wastes less time on the Morphic loop than the other
>> dialects.
> I've had OpenGL running in Cuis since 1.0 (OK, maybe not 1.0, but pretty
> sure it was early 1.x :-)
>>
>> --C
>>
>> On Mon, Feb 16, 2015 at 7:15 PM, Phil (list) <[hidden email]>
>> wrote:
>>        On Mon, 2015-02-16 at 18:49 -0800, Casey Ransberger wrote:
>>> I think parserClass was there to give everyone a hook to
>>        implement
>>> their own parsers, because Smalltalk was (in part) a prog
>>        language
>>> research platform. Given that Cuis aims to be a minimal
>>        system,
>>> someone may have removed it as unnecessary. Also, when Juan
>>        changes
>>> some critical behavior, he tends to prefer coming up with a
>>        new name
>>> for the method and associated variables, so that folks with
>>        existing
>>> code aren't confused when their dependencies start behaving
>>        in
>>> unexpected ways; this might also be what happened.
>>
>>        I'm fine with it being removed... just wanted to understand
>>        why it was
>>        removed.  I know there's been a lot of cog/compiler/vm stuff
>>        going on
>>        recently that I haven't kept up on so thought I'd check in
>>        before just
>>        making the minimal changes to get it working again if
>>        something bigger
>>        is going on.
>>
>>> It would be interesting to look at what wants to refer to
>>        parserClass.
>>> Could be one of those packages is doing something very, very
>>> interesting:)
>>        It's from OGLExtManager...
>>
>>        forwardExtMethod: aSelector
>>                "Compile a forwarder method in OpenGL"
>>                | code parser fwdCode |
>>                code := self class sourceCodeAt: aSelector.
>>                parser := self parserClass new.
>>                parser parseSelector: code.
>>                code := code copyFrom: 1 to: (parser endOfLastToken
>>        min: code size).
>>                fwdCode := String streamContents:[:s|
>>                        s nextPutAll: code.
>>                        s newLineTab: 1; nextPutAll: '"This method was
>>        automatically
>>        generated"'.
>>                        s newLineTab: 1; nextPutAll: '^glExt ';
>>        nextPutAll: code.
>>                ].
>>                (OpenGL sourceCodeAt: aSelector ifAbsent:['']) =
>>        fwdCode
>>        ifTrue:[^self]. "no change"
>>                OpenGL compile: fwdCode classified: (self class
>>        organization
>>        categoryOfElement: aSelector).
>>
>>
>>
>>
>>        _______________________________________________
>>        Cuis mailing list
>>        [hidden email]
>>        http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> One comment inline.
>
> > On Feb 16, 2015, at 8:09 PM, "Phil (list)" <[hidden email]> wrote:
> >
> >> On Mon, 2015-02-16 at 19:26 -0800, Casey Ransberger wrote:
> >> What is self parserClass expected to answer when one happens to be an
> >> instance of OGLExtManager?
> > In Cuis 4.1 it answers with Parser
>
> Hmm. And that worked with this stuff in 4.1? Seems odd to explicitly call out the default parser. Might be worth looking at what comes back in Squeak and (gut says) Pharo to be sure.
>

> On Feb 16, 2015, at 9:24 PM, "Phil (list)" <[hidden email]> wrote:
>
>> On Mon, 2015-02-16 at 20:37 -0800, Casey Ransberger wrote:
>> If memory serves (and it may not) Igor mentioned having automatically generated bindings based on the API at one point when I asked about it. The comment in there made me suspect that you might be adapting generated code that he'd had his hands in. Might be worth asking him.
>
> I think the code I'm currently using was indirectly the result of the
> Croquet work.  I believe it was a package that Andreas Raab originally
> generated (the code to do so was lost to the sands of time way back when
> I had asked about it)  The package had been last touched by John Dougan
> and I merged in some later fixes from Bert Freudenberg.
>
>> One reason I'm interested here is, the Croquet stuff isn't just tangled up with a synched messaging model, it's also written in a style of GL that doesn't really seem to be supported anymore. So automatically generating bindings for something like e.g. OpenGL ES on the Pi is really compelling right now.
>
> Tell me about it... I had to untangle that crap before I eventually
> found a Squeak package for OpenGL that worked.  Yes, this is old
> immediate mode code.  I had planned to switch over to a subset of OpenGL
> (i.e. OpenGL ES as supported by OpenGL 4.1 iirc) but haven't had the
> right combination of time and need.  If I do (before someone else does
> it), I'll definitely be looking to regenerate it from the OpenGL XML
> spec files from scratch rather than modifying what I currently have.
>
> Unfortunately, most of the more recent OpenGL work by others appears to
> be happening in Pharo and was based on Alien, now NativeBoost (next
> month probably something else)... so on top of porting the OpenGL code,
> you've got to port the code that it depends on (which in turn often
> depends on yet more stuff) plus dealing with another plugin.  Feel free
> to do this if you want :-)  I was just starting to sort out Alien when
> NB came along and... I got weary of chasing these undocumented moving
> targets, hence the older code I'm using.
>
>> One comment inline.
>>
>>>> On Feb 16, 2015, at 8:09 PM, "Phil (list)" <[hidden email]> wrote:
>>>>
>>>> On Mon, 2015-02-16 at 19:26 -0800, Casey Ransberger wrote:
>>>> What is self parserClass expected to answer when one happens to be an
>>>> instance of OGLExtManager?
>>> In Cuis 4.1 it answers with Parser
>>
>> Hmm. And that worked with this stuff in 4.1? Seems odd to explicitly call out the default parser. Might be worth looking at what comes back in Squeak and (gut says) Pharo to be sure.
>
> Yes.  I was originally using it in Squeak 3.x / Pharo 1.x (I think... it
> might have been Pharo 2.x) and it's been working in Cuis since 1.x.
>
> For the time being I've just gone and used Parser directly which works
> around the immediate error so I can see what else needs fixing.
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> On Mon, 2015-02-16 at 18:49 -0800, Casey Ransberger wrote:
>> I think parserClass was there to give everyone a hook to implement
>> their own parsers, because Smalltalk was (in part) a prog language
>> research platform. Given that Cuis aims to be a minimal system,
>> someone may have removed it as unnecessary. Also, when Juan changes
>> some critical behavior, he tends to prefer coming up with a new name
>> for the method and associated variables, so that folks with existing
>> code aren't confused when their dependencies start behaving in
>> unexpected ways; this might also be what happened.
> I'm fine with it being removed... just wanted to understand why it was
> removed.  I know there's been a lot of cog/compiler/vm stuff going on
> recently that I haven't kept up on so thought I'd check in before just
> making the minimal changes to get it working again if something bigger
> is going on.
>

>> It would be interesting to look at what wants to refer to parserClass.
>> Could be one of those packages is doing something very, very
>> interesting:)
>>
>>
> It's from OGLExtManager...
>
> forwardExtMethod: aSelector
> "Compile a forwarder method in OpenGL"
> | code parser fwdCode |
> code := self class sourceCodeAt: aSelector.
> parser := self parserClass new.
> parser parseSelector: code.
> code := code copyFrom: 1 to: (parser endOfLastToken min: code size).
> fwdCode := String streamContents:[:s|
> s nextPutAll: code.
> s newLineTab: 1; nextPutAll: '"This method was automatically
> generated"'.
> s newLineTab: 1; nextPutAll: '^glExt '; nextPutAll: code.
> ].
> (OpenGL sourceCodeAt: aSelector ifAbsent:['']) = fwdCode
> ifTrue:[^self]. "no change"
> OpenGL compile: fwdCode classified: (self class organization
> categoryOfElement: aSelector).
>
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> Ah. One wild idea. We have a working PetitParser for Cuis, I think. Making the jump from XML to bindings might be expedited using that.
>
> Anyway let me know what you decide to do. I'd *love* to do some 3D stuff on the Pi, so this is relevant to my interests.
>
>> On Feb 16, 2015, at 9:24 PM, "Phil (list)"<[hidden email]>  wrote:
>>
>>> On Mon, 2015-02-16 at 20:37 -0800, Casey Ransberger wrote:
>>> If memory serves (and it may not) Igor mentioned having automatically generated bindings based on the API at one point when I asked about it. The comment in there made me suspect that you might be adapting generated code that he'd had his hands in. Might be worth asking him.
>> I think the code I'm currently using was indirectly the result of the
>> Croquet work.  I believe it was a package that Andreas Raab originally
>> generated (the code to do so was lost to the sands of time way back when
>> I had asked about it)  The package had been last touched by John Dougan
>> and I merged in some later fixes from Bert Freudenberg.
>>
>>> One reason I'm interested here is, the Croquet stuff isn't just tangled up with a synched messaging model, it's also written in a style of GL that doesn't really seem to be supported anymore. So automatically generating bindings for something like e.g. OpenGL ES on the Pi is really compelling right now.
>> Tell me about it... I had to untangle that crap before I eventually
>> found a Squeak package for OpenGL that worked.  Yes, this is old
>> immediate mode code.  I had planned to switch over to a subset of OpenGL
>> (i.e. OpenGL ES as supported by OpenGL 4.1 iirc) but haven't had the
>> right combination of time and need.  If I do (before someone else does
>> it), I'll definitely be looking to regenerate it from the OpenGL XML
>> spec files from scratch rather than modifying what I currently have.
>>
>> Unfortunately, most of the more recent OpenGL work by others appears to
>> be happening in Pharo and was based on Alien, now NativeBoost (next
>> month probably something else)... so on top of porting the OpenGL code,
>> you've got to port the code that it depends on (which in turn often
>> depends on yet more stuff) plus dealing with another plugin.  Feel free
>> to do this if you want :-)  I was just starting to sort out Alien when
>> NB came along and... I got weary of chasing these undocumented moving
>> targets, hence the older code I'm using.
>>
>>> One comment inline.
>>>
>>>>> On Feb 16, 2015, at 8:09 PM, "Phil (list)"<[hidden email]>  wrote:
>>>>>
>>>>> On Mon, 2015-02-16 at 19:26 -0800, Casey Ransberger wrote:
>>>>> What is self parserClass expected to answer when one happens to be an
>>>>> instance of OGLExtManager?
>>>> In Cuis 4.1 it answers with Parser
>>> Hmm. And that worked with this stuff in 4.1? Seems odd to explicitly call out the default parser. Might be worth looking at what comes back in Squeak and (gut says) Pharo to be sure.
>> Yes.  I was originally using it in Squeak 3.x / Pharo 1.x (I think... it
>> might have been Pharo 2.x) and it's been working in Cuis since 1.x.
>>
>> For the time being I've just gone and used Parser directly which works
>> around the immediate error so I can see what else needs fixing.
>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> On Mon, 2015-02-16 at 20:37 -0800, Casey Ransberger wrote:
>> If memory serves (and it may not) Igor mentioned having automatically generated bindings based on the API at one point when I asked about it. The comment in there made me suspect that you might be adapting generated code that he'd had his hands in. Might be worth asking him.
>>
> I think the code I'm currently using was indirectly the result of the
> Croquet work.  I believe it was a package that Andreas Raab originally
> generated (the code to do so was lost to the sands of time way back when
> I had asked about it)  The package had been last touched by John Dougan
> and I merged in some later fixes from Bert Freudenberg.
>
>> One reason I'm interested here is, the Croquet stuff isn't just tangled up with a synched messaging model, it's also written in a style of GL that doesn't really seem to be supported anymore. So automatically generating bindings for something like e.g. OpenGL ES on the Pi is really compelling right now.
>>
> Tell me about it... I had to untangle that crap before I eventually
> found a Squeak package for OpenGL that worked.  Yes, this is old
> immediate mode code.  I had planned to switch over to a subset of OpenGL
> (i.e. OpenGL ES as supported by OpenGL 4.1 iirc) but haven't had the
> right combination of time and need.  If I do (before someone else does
> it), I'll definitely be looking to regenerate it from the OpenGL XML
> spec files from scratch rather than modifying what I currently have.
>
> Unfortunately, most of the more recent OpenGL work by others appears to
> be happening in Pharo and was based on Alien, now NativeBoost (next
> month probably something else)... so on top of porting the OpenGL code,
> you've got to port the code that it depends on (which in turn often
> depends on yet more stuff) plus dealing with another plugin.  Feel free
> to do this if you want :-)  I was just starting to sort out Alien when
> NB came along and... I got weary of chasing these undocumented moving
> targets, hence the older code I'm using.
>
>> One comment inline.
>>
>>> On Feb 16, 2015, at 8:09 PM, "Phil (list)"<[hidden email]>  wrote:
>>>
>>>> On Mon, 2015-02-16 at 19:26 -0800, Casey Ransberger wrote:
>>>> What is self parserClass expected to answer when one happens to be an
>>>> instance of OGLExtManager?
>>> In Cuis 4.1 it answers with Parser
>> Hmm. And that worked with this stuff in 4.1? Seems odd to explicitly call out the default parser. Might be worth looking at what comes back in Squeak and (gut says) Pharo to be sure.
>>
> Yes.  I was originally using it in Squeak 3.x / Pharo 1.x (I think... it
> might have been Pharo 2.x) and it's been working in Cuis since 1.x.
>
> For the time being I've just gone and used Parser directly which works
> around the immediate error so I can see what else needs fixing.
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> Thanks,
> Juan Vuletich
>
> On 2/17/2015 3:03 AM, Casey Ransberger wrote:
> > Ah. One wild idea. We have a working PetitParser for Cuis, I think. Making the jump from XML to bindings might be expedited using that.
> >
> > Anyway let me know what you decide to do. I'd *love* to do some 3D stuff on the Pi, so this is relevant to my interests.
> >
> >> On Feb 16, 2015, at 9:24 PM, "Phil (list)"<[hidden email]>  wrote:
> >>
> >>> On Mon, 2015-02-16 at 20:37 -0800, Casey Ransberger wrote:
> >>> If memory serves (and it may not) Igor mentioned having automatically generated bindings based on the API at one point when I asked about it. The comment in there made me suspect that you might be adapting generated code that he'd had his hands in. Might be worth asking him.
> >> I think the code I'm currently using was indirectly the result of the
> >> Croquet work.  I believe it was a package that Andreas Raab originally
> >> generated (the code to do so was lost to the sands of time way back when
> >> I had asked about it)  The package had been last touched by John Dougan
> >> and I merged in some later fixes from Bert Freudenberg.
> >>
> >>> One reason I'm interested here is, the Croquet stuff isn't just tangled up with a synched messaging model, it's also written in a style of GL that doesn't really seem to be supported anymore. So automatically generating bindings for something like e.g. OpenGL ES on the Pi is really compelling right now.
> >> Tell me about it... I had to untangle that crap before I eventually
> >> found a Squeak package for OpenGL that worked.  Yes, this is old
> >> immediate mode code.  I had planned to switch over to a subset of OpenGL
> >> (i.e. OpenGL ES as supported by OpenGL 4.1 iirc) but haven't had the
> >> right combination of time and need.  If I do (before someone else does
> >> it), I'll definitely be looking to regenerate it from the OpenGL XML
> >> spec files from scratch rather than modifying what I currently have.
> >>
> >> Unfortunately, most of the more recent OpenGL work by others appears to
> >> be happening in Pharo and was based on Alien, now NativeBoost (next
> >> month probably something else)... so on top of porting the OpenGL code,
> >> you've got to port the code that it depends on (which in turn often
> >> depends on yet more stuff) plus dealing with another plugin.  Feel free
> >> to do this if you want :-)  I was just starting to sort out Alien when
> >> NB came along and... I got weary of chasing these undocumented moving
> >> targets, hence the older code I'm using.
> >>
> >>> One comment inline.
> >>>
> >>>>> On Feb 16, 2015, at 8:09 PM, "Phil (list)"<[hidden email]>  wrote:
> >>>>>
> >>>>> On Mon, 2015-02-16 at 19:26 -0800, Casey Ransberger wrote:
> >>>>> What is self parserClass expected to answer when one happens to be an
> >>>>> instance of OGLExtManager?
> >>>> In Cuis 4.1 it answers with Parser
> >>> Hmm. And that worked with this stuff in 4.1? Seems odd to explicitly call out the default parser. Might be worth looking at what comes back in Squeak and (gut says) Pharo to be sure.
> >> Yes.  I was originally using it in Squeak 3.x / Pharo 1.x (I think... it
> >> might have been Pharo 2.x) and it's been working in Cuis since 1.x.
> >>
> >> For the time being I've just gone and used Parser directly which works
> >> around the immediate error so I can see what else needs fixing.
> >>
> >>
> >>
> >> _______________________________________________
> >> Cuis mailing list
> >> [hidden email]
> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> > _______________________________________________
> > Cuis mailing list
> > [hidden email]
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> Hi Folks,
>
> (apologies for the delay. I was on vacations, and when back home, had
> tons of stuff to take care of. Many of them, Cuis related :)
> (inline)
>
> On 2/17/2015 12:15 AM, Phil (list) wrote:
> > On Mon, 2015-02-16 at 18:49 -0800, Casey Ransberger wrote:
> >> I think parserClass was there to give everyone a hook to implement
> >> their own parsers, because Smalltalk was (in part) a prog language
> >> research platform. Given that Cuis aims to be a minimal system,
> >> someone may have removed it as unnecessary. Also, when Juan changes
> >> some critical behavior, he tends to prefer coming up with a new name
> >> for the method and associated variables, so that folks with existing
> >> code aren't confused when their dependencies start behaving in
> >> unexpected ways; this might also be what happened.
> > I'm fine with it being removed... just wanted to understand why it was
> > removed.  I know there's been a lot of cog/compiler/vm stuff going on
> > recently that I haven't kept up on so thought I'd check in before just
> > making the minimal changes to get it working again if something bigger
> > is going on.
> >
>
> Well, in Cuis it always ended being Parser, so I just removed it. Please
> add it to SqueakCompatibility.pck.st, and send the .cs.st to me, or do a
> pull request, etc.
>
> I apologize for this kind of hiccups, they are somewhat unavoidable when
> cleaning the system. Sometimes it is not obvious whether something must
> be kept, moved to SqueakCompatibility or just deleted. Please tell
> anytime this happens, so we can fix.
>

> Cheers,
> Juan Vuletich
>
> >> It would be interesting to look at what wants to refer to parserClass.
> >> Could be one of those packages is doing something very, very
> >> interesting:)
> >>
> >>
> > It's from OGLExtManager...
> >
> > forwardExtMethod: aSelector
> > "Compile a forwarder method in OpenGL"
> > | code parser fwdCode |
> > code := self class sourceCodeAt: aSelector.
> > parser := self parserClass new.
> > parser parseSelector: code.
> > code := code copyFrom: 1 to: (parser endOfLastToken min: code size).
> > fwdCode := String streamContents:[:s|
> > s nextPutAll: code.
> > s newLineTab: 1; nextPutAll: '"This method was automatically
> > generated"'.
> > s newLineTab: 1; nextPutAll: '^glExt '; nextPutAll: code.
> > ].
> > (OpenGL sourceCodeAt: aSelector ifAbsent:['']) = fwdCode
> > ifTrue:[^self]. "no change"
> > OpenGL compile: fwdCode classified: (self class organization
> > categoryOfElement: aSelector).
> >
> >
> >
> >
> > _______________________________________________
> > Cuis mailing list
> > [hidden email]
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
>

> On Thu, 2015-02-26 at 10:25 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> (apologies for the delay. I was on vacations, and when back home, had
>> tons of stuff to take care of. Many of them, Cuis related :)
>> (inline)
>>
>> On 2/17/2015 12:15 AM, Phil (list) wrote:
>>> On Mon, 2015-02-16 at 18:49 -0800, Casey Ransberger wrote:
>>>> I think parserClass was there to give everyone a hook to implement
>>>> their own parsers, because Smalltalk was (in part) a prog language
>>>> research platform. Given that Cuis aims to be a minimal system,
>>>> someone may have removed it as unnecessary. Also, when Juan changes
>>>> some critical behavior, he tends to prefer coming up with a new name
>>>> for the method and associated variables, so that folks with existing
>>>> code aren't confused when their dependencies start behaving in
>>>> unexpected ways; this might also be what happened.
>>> I'm fine with it being removed... just wanted to understand why it was
>>> removed.  I know there's been a lot of cog/compiler/vm stuff going on
>>> recently that I haven't kept up on so thought I'd check in before just
>>> making the minimal changes to get it working again if something bigger
>>> is going on.
>>>
>> Well, in Cuis it always ended being Parser, so I just removed it. Please
>> add it to SqueakCompatibility.pck.st, and send the .cs.st to me, or do a
>> pull request, etc.
>>
>> I apologize for this kind of hiccups, they are somewhat unavoidable when
>> cleaning the system. Sometimes it is not obvious whether something must
>> be kept, moved to SqueakCompatibility or just deleted. Please tell
>> anytime this happens, so we can fix.
>>
> No need to apologize, I was just giving an example of the kind of things
> I'm running into.  I'm actually quite happy that cruft continues to be
> trimmed from Cuis and for something like this it's simple to just grab
> Parser directly... once I understood that's what I needed to do.  For
> one-off type calls like this, that seems to be the simpler approach than
> starting to pile cruft into SqueakCompatibility. (I'd prefer to see that
> be a collection of things that are frequently called by popular Squeak
> packages rather than every silly edge case as that would result in it
> turning into Squeak over time)
>
> All I'm looking for is a small API surface that I can depend on, and
> communication when that surface needs to change.  That would probably
> have the effect of reducing my migration from what has been a multi-day
> effort to a couple of hours.  I'm not expecting migration to be free,
> just a little less expensive :-)
>
>
>> Cheers,
>> Juan Vuletich
>>
>>>> It would be interesting to look at what wants to refer to parserClass.
>>>> Could be one of those packages is doing something very, very
>>>> interesting:)
>>>>
>>>>
>>> It's from OGLExtManager...
>>>
>>> forwardExtMethod: aSelector
>>> "Compile a forwarder method in OpenGL"
>>> | code parser fwdCode |
>>> code := self class sourceCodeAt: aSelector.
>>> parser := self parserClass new.
>>> parser parseSelector: code.
>>> code := code copyFrom: 1 to: (parser endOfLastToken min: code size).
>>> fwdCode := String streamContents:[:s|
>>> s nextPutAll: code.
>>> s newLineTab: 1; nextPutAll: '"This method was automatically
>>> generated"'.
>>> s newLineTab: 1; nextPutAll: '^glExt '; nextPutAll: code.
>>> ].
>>> (OpenGL sourceCodeAt: aSelector ifAbsent:['']) = fwdCode
>>> ifTrue:[^self]. "no change"
>>> OpenGL compile: fwdCode classified: (self class organization
>>> categoryOfElement: aSelector).
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>
>

>
> On 2/26/2015 5:51 PM, Phil (list) wrote:
> > On Thu, 2015-02-26 at 10:25 -0300, Juan Vuletich wrote:
> >> Hi Folks,
> >>
> >> (apologies for the delay. I was on vacations, and when back home, had
> >> tons of stuff to take care of. Many of them, Cuis related :)
> >> (inline)
> >>
> >> On 2/17/2015 12:15 AM, Phil (list) wrote:
> >>> On Mon, 2015-02-16 at 18:49 -0800, Casey Ransberger wrote:
> >>>> I think parserClass was there to give everyone a hook to implement
> >>>> their own parsers, because Smalltalk was (in part) a prog language
> >>>> research platform. Given that Cuis aims to be a minimal system,
> >>>> someone may have removed it as unnecessary. Also, when Juan changes
> >>>> some critical behavior, he tends to prefer coming up with a new name
> >>>> for the method and associated variables, so that folks with existing
> >>>> code aren't confused when their dependencies start behaving in
> >>>> unexpected ways; this might also be what happened.
> >>> I'm fine with it being removed... just wanted to understand why it was
> >>> removed.  I know there's been a lot of cog/compiler/vm stuff going on
> >>> recently that I haven't kept up on so thought I'd check in before just
> >>> making the minimal changes to get it working again if something bigger
> >>> is going on.
> >>>
> >> Well, in Cuis it always ended being Parser, so I just removed it. Please
> >> add it to SqueakCompatibility.pck.st, and send the .cs.st to me, or do a
> >> pull request, etc.
> >>
> >> I apologize for this kind of hiccups, they are somewhat unavoidable when
> >> cleaning the system. Sometimes it is not obvious whether something must
> >> be kept, moved to SqueakCompatibility or just deleted. Please tell
> >> anytime this happens, so we can fix.
> >>
> > No need to apologize, I was just giving an example of the kind of things
> > I'm running into.  I'm actually quite happy that cruft continues to be
> > trimmed from Cuis and for something like this it's simple to just grab
> > Parser directly... once I understood that's what I needed to do.  For
> > one-off type calls like this, that seems to be the simpler approach than
> > starting to pile cruft into SqueakCompatibility. (I'd prefer to see that
> > be a collection of things that are frequently called by popular Squeak
> > packages rather than every silly edge case as that would result in it
> > turning into Squeak over time)
> >
> > All I'm looking for is a small API surface that I can depend on, and
> > communication when that surface needs to change.  That would probably
> > have the effect of reducing my migration from what has been a multi-day
> > effort to a couple of hours.  I'm not expecting migration to be free,
> > just a little less expensive :-)
> >
> >
> >> Cheers,
> >> Juan Vuletich
> >>
> >>>> It would be interesting to look at what wants to refer to parserClass.
> >>>> Could be one of those packages is doing something very, very
> >>>> interesting:)
> >>>>
> >>>>
> >>> It's from OGLExtManager...
> >>>
> >>> forwardExtMethod: aSelector
> >>> "Compile a forwarder method in OpenGL"
> >>> | code parser fwdCode |
> >>> code := self class sourceCodeAt: aSelector.
> >>> parser := self parserClass new.
> >>> parser parseSelector: code.
> >>> code := code copyFrom: 1 to: (parser endOfLastToken min: code size).
> >>> fwdCode := String streamContents:[:s|
> >>> s nextPutAll: code.
> >>> s newLineTab: 1; nextPutAll: '"This method was automatically
> >>> generated"'.
> >>> s newLineTab: 1; nextPutAll: '^glExt '; nextPutAll: code.
> >>> ].
> >>> (OpenGL sourceCodeAt: aSelector ifAbsent:['']) = fwdCode
> >>> ifTrue:[^self]. "no change"
> >>> OpenGL compile: fwdCode classified: (self class organization
> >>> categoryOfElement: aSelector).
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Cuis mailing list
> >>> [hidden email]
> >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>
> >
> >
>