[Cuis] 4.1 to 4.2 migration question

[Juan Vuletich]

Well. Squeak has #parserClass, #compilerClass and #decompilerClass. It 
seems this is to enable packages to define their own Compiler, etc. Do 
you need this for OpenGL.pck? If not, then I'd rather not add them.

Cheers,
Jaun Vuletich


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