[Cuis] 4.1 to 4.2 migration question

[Phil (list)]

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
> > Cuis at jvuletich.org
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
>