Hi,
- The Editor hierarchy in Cuis has been updated in a very nice way
(event dispatch) but there are lots of changes compared with Squeak. Menus are different also. Making SimpleMorphic loadable as a project type makes it easy to compare the two. I renamed some of the event handling methods (e.g. Editor>>backspace: becomes Editor>>backspaceEvent: so the original Editor>>backspace: method remains in place for use by Morphic and MVC).
What do you think about copying Cuis' Editor hierarchy for SimpleMorphic instead of adapting the current Editor hierarchy to cope in both environments?
Balázs
On 3/28/11 8:10 AM, "Balázs Kósi" rebmekop@gmail.com wrote:
Hi,
- The Editor hierarchy in Cuis has been updated in a very nice way
(event dispatch) but there are lots of changes compared with Squeak. Menus are different also. Making SimpleMorphic loadable as a project type makes it easy to compare the two. I renamed some of the event handling methods (e.g. Editor>>backspace: becomes Editor>>backspaceEvent: so the original Editor>>backspace: method remains in place for use by Morphic and MVC).
What do you think about copying Cuis' Editor hierarchy for SimpleMorphic instead of adapting the current Editor hierarchy to cope in both environments?
Balázs
Currently i try to have SimpleMorphic in 4.3 helping David Lewis. Learning from Cuis 3.1, also think having all Cuis' Editor hierarchy is good.
Wondering if we could have Enviroments and a Cuis compatible hierarchy inside.
Edgar
Wouldn't that be sweet?
On Mar 28, 2011, at 4:31 AM, "Edgar J. De Cleene" edgardec2005@gmail.com wrote:
On 3/28/11 8:10 AM, "Balázs Kósi" rebmekop@gmail.com wrote:
Hi,
- The Editor hierarchy in Cuis has been updated in a very nice way
(event dispatch) but there are lots of changes compared with Squeak. Menus are different also. Making SimpleMorphic loadable as a project type makes it easy to compare the two. I renamed some of the event handling methods (e.g. Editor>>backspace: becomes Editor>>backspaceEvent: so the original Editor>>backspace: method remains in place for use by Morphic and MVC).
What do you think about copying Cuis' Editor hierarchy for SimpleMorphic instead of adapting the current Editor hierarchy to cope in both environments?
Balázs
Currently i try to have SimpleMorphic in 4.3 helping David Lewis. Learning from Cuis 3.1, also think having all Cuis' Editor hierarchy is good.
Wondering if we could have Enviroments and a Cuis compatible hierarchy inside.
Edgar
Hi,
I'm done with copying the Editor classes from Cuis, and made some other minor advancements too.
You can load it with:
Installer mc http: 'http://leves.web.elte.hu/squeak'; install: 'SimpleMorphic-kb.10.mcz'; install: 'SMx-kb.18.mcz'
I think we should use the ToolBuilder for tools instead of SimpleMorphic-Tools (eg. SMxBrowserWindow). In this new version you can evaluate Browser open, and get a functional but a bit ugly browser.
Balázs
SimpleMorphic-kb.10 - use SMxEditors instead of squeak Editors - SMxLayoutFrame missed some accessors - Use ToolBuilder version of Inspector in SMxMorph >> inspecInMorphic: - Use squeak protocol of styling in SMXPluggableTextMorph - added: SMxPluggableTextMorph >> select, sent by the parser when correcting variables - Use ToolBuilder version of Browser in SMXTheWorldMenu
SMx-kb.18 - copied Cuis' Editor hierarchy: SMxEditor, SMxTextEditor, SMxSmalltalkEditor. - removed extensions from Squeak's Editor hierarchy - rewrote Editor/TextEditor/SmalltalkEditor class references to their SMx versions. - commented out some OSProcess trace sends - fiddled with SimpleMorphicToolBuilder >> setLayout:in: to do something.
On 3/30/11 11:57 AM, "Balázs Kósi" rebmekop@gmail.com wrote:
Hi,
I'm done with copying the Editor classes from Cuis, and made some other minor advancements too.
You can load it with:
Installer mc http: 'http://leves.web.elte.hu/squeak'; install: 'SimpleMorphic-kb.10.mcz'; install: 'SMx-kb.18.mcz'
I think we should use the ToolBuilder for tools instead of SimpleMorphic-Tools (eg. SMxBrowserWindow). In this new version you can evaluate Browser open, and get a functional but a bit ugly browser.
Balázs
SimpleMorphic-kb.10
- use SMxEditors instead of squeak Editors
- SMxLayoutFrame missed some accessors
- Use ToolBuilder version of Inspector in SMxMorph >> inspecInMorphic:
- Use squeak protocol of styling in SMXPluggableTextMorph
- added: SMxPluggableTextMorph >> select, sent by the parser when
correcting variables
- Use ToolBuilder version of Browser in SMXTheWorldMenu
SMx-kb.18
- copied Cuis' Editor hierarchy: SMxEditor, SMxTextEditor,
SMxSmalltalkEditor.
- removed extensions from Squeak's Editor hierarchy
- rewrote Editor/TextEditor/SmalltalkEditor class references to their
SMx versions.
- commented out some OSProcess trace sends
- fiddled with SimpleMorphicToolBuilder >> setLayout:in: to do something.
This works well.
In particular , like dnu in SimpleMorphic world raise a debugger, a step forward for me.
Is possible you, David Lewis, me , others Squeakers work together for having full functional SimpleMorphic into Squeak 4.3 ?
Edgar
On Thu, Mar 31, 2011 at 08:02:51AM -0300, Edgar J. De Cleene wrote:
On 3/30/11 11:57 AM, "Bal?zs K?si" rebmekop@gmail.com wrote:
Hi,
I'm done with copying the Editor classes from Cuis, and made some other minor advancements too.
You can load it with:
Installer mc http: 'http://leves.web.elte.hu/squeak'; install: 'SimpleMorphic-kb.10.mcz'; install: 'SMx-kb.18.mcz'
I think we should use the ToolBuilder for tools instead of SimpleMorphic-Tools (eg. SMxBrowserWindow). In this new version you can evaluate Browser open, and get a functional but a bit ugly browser.
Bal?zs
SimpleMorphic-kb.10
- use SMxEditors instead of squeak Editors
- SMxLayoutFrame missed some accessors
- Use ToolBuilder version of Inspector in SMxMorph >> inspecInMorphic:
- Use squeak protocol of styling in SMXPluggableTextMorph
- added: SMxPluggableTextMorph >> select, sent by the parser when
correcting variables
- Use ToolBuilder version of Browser in SMXTheWorldMenu
SMx-kb.18
- copied Cuis' Editor hierarchy: SMxEditor, SMxTextEditor,
SMxSmalltalkEditor.
- removed extensions from Squeak's Editor hierarchy
- rewrote Editor/TextEditor/SmalltalkEditor class references to their
SMx versions.
- commented out some OSProcess trace sends
- fiddled with SimpleMorphicToolBuilder >> setLayout:in: to do something.
This works well.
In particular , like dnu in SimpleMorphic world raise a debugger, a step forward for me.
Is possible you, David Lewis, me , others Squeakers work together for having full functional SimpleMorphic into Squeak 4.3 ?
Edgar
Hi Bal?zs,
I've been away and have not had a chance to look at your work (sorry). Meanwhile I added you as developer on the SqueakSource project:
MCHttpRepository location: 'http://www.squeaksource.com/SimpleMorphicSqueak' user: '' password: ''
If anyone else is working on this, please speak up and I'll add you to the SqueakSource project.
Thanks, Dave
Hi,
On Thu, Mar 31, 2011 at 1:02 PM, Edgar J. De Cleene edgardec2005@gmail.com wrote:
Is possible you, David Lewis, me , others Squeakers work together for having full functional SimpleMorphic into Squeak 4.3 ?
I think SimpleMorphic for Squeak should remain a loadable package. Maybe we can revive the Community Supported Packages idea. [1] But other than that, count me in!
What I hope the Trunk will gain from adapting SimpleMorphic to Squeak is a cleaned up Project infrastructure, and a better ToolBuilder.
Balázs
[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
On Mar 31, 2011, at 9:00 AM, Balázs Kósi rebmekop@gmail.com wrote:
Hi,
On Thu, Mar 31, 2011 at 1:02 PM, Edgar J. De Cleene edgardec2005@gmail.com wrote:
Is possible you, David Lewis, me , others Squeakers work together for having full functional SimpleMorphic into Squeak 4.3 ?
I think SimpleMorphic for Squeak should remain a loadable package. Maybe we can revive the Community Supported Packages idea. [1] But other than that, count me in!
What I hope the Trunk will gain from adapting SimpleMorphic to Squeak is a cleaned up Project infrastructure, and a better ToolBuilder.
Balázs
[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Balázs
Hah! Agreed, if only we could solve the problem of "stuff can be unloaded easily." Modularity can help with that in the longer term, when people use it. Er, and if you support modularity. I just hijacked a thread. Sorry!
On Mar 31, 2011, at 11:00 AM, Balázs Kósi rebmekop@gmail.com wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Balázs
On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Bal?zs
Yes!
Dave
On 31.03.2011, at 21:15, David T. Lewis wrote:
On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Bal?zs
Yes!
Dave
Not quite a plan yet, but great idea!
The old FullMorphic could be maintained as part of Etoys.
- Bert -
Bert, that's a fantastic idea!!
On Apr 1, 2011, at 1:29 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 31.03.2011, at 21:15, David T. Lewis wrote:
On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Bal?zs
Yes!
Dave
Not quite a plan yet, but great idea!
The old FullMorphic could be maintained as part of Etoys.
- Bert -
On Fri, 1 Apr 2011, Bert Freudenberg wrote:
On 31.03.2011, at 21:15, David T. Lewis wrote:
On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Bal?zs
Yes!
Dave
Not quite a plan yet, but great idea!
The old FullMorphic could be maintained as part of Etoys.
Another possible solution is to implement Andreas' idea about Community Supported Packages* (which slight modifications) and maintain it there. Of course, it has to be made unloadable/loadable first.
Levente
*http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html
- Bert -
This is also a great idea. Andreas decided he didn't like his implementation and we haven't really followed up since. I actually think it wouldn't hurt to use the same underlying system that Pharo is using (Metacello) if it works today, but I may be in the Minority on this one.
Chris Muller has made some pretty compelling arguments about using SqueakMap, which is also worth mentioning as a possible solution.
On Apr 1, 2011, at 4:42 PM, Levente Uzonyi leves@elte.hu wrote:
On Fri, 1 Apr 2011, Bert Freudenberg wrote:
On 31.03.2011, at 21:15, David T. Lewis wrote:
On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Bal?zs
Yes!
Dave
Not quite a plan yet, but great idea!
The old FullMorphic could be maintained as part of Etoys.
Another possible solution is to implement Andreas' idea about Community Supported Packages* (which slight modifications) and maintain it there. Of course, it has to be made unloadable/loadable first.
Levente
*http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html
- Bert -
Anything is fine as long as SimpleMorphic will be the default in the future and the FullMorphic may be loaded on top of it (or by replacing it).
I think at this very moment it is not so much a discussion Metacello vs. Squeakmap but rather: Is it possible to load SimpleMorphic and what needs to be done to make it good enough for carrying the workload for developing in Squeak. And then the next question: can we put FullMorphic into squeaksource and make it possible to reload it from there.
BTW what do I need to do to load SimpleMorphic as of now?
--Hannes
On 4/2/11, Casey Ransberger casey.obrien.r@gmail.com wrote:
This is also a great idea. Andreas decided he didn't like his implementation and we haven't really followed up since. I actually think it wouldn't hurt to use the same underlying system that Pharo is using (Metacello) if it works today, but I may be in the Minority on this one.
Chris Muller has made some pretty compelling arguments about using SqueakMap, which is also worth mentioning as a possible solution.
On Apr 1, 2011, at 4:42 PM, Levente Uzonyi leves@elte.hu wrote:
On Fri, 1 Apr 2011, Bert Freudenberg wrote:
On 31.03.2011, at 21:15, David T. Lewis wrote:
On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Bal?zs
Yes!
Dave
Not quite a plan yet, but great idea!
The old FullMorphic could be maintained as part of Etoys.
Another possible solution is to implement Andreas' idea about Community Supported Packages* (which slight modifications) and maintain it there. Of course, it has to be made unloadable/loadable first.
Levente
*http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html
- Bert -
On 4/2/11 6:48 AM, "Hannes Hirzel" hannes.hirzel@gmail.com wrote:
Anything is fine as long as SimpleMorphic will be the default in the future and the FullMorphic may be loaded on top of it (or by replacing it).
I think at this very moment it is not so much a discussion Metacello vs. Squeakmap but rather: Is it possible to load SimpleMorphic and what needs to be done to make it good enough for carrying the workload for developing in Squeak. And then the next question: can we put FullMorphic into squeaksource and make it possible to reload it from there.
BTW what do I need to do to load SimpleMorphic as of now?
David Lewis start a project into SqueakSource Balázs Kósi send his own to this list some days ago and also I is working on it. For now and until all was merged, you could download SimpleMorphic-kb.10 from http://www.squeaksource.com/SimpleMorphicSqueak
And SMx-edc.20
You could open SMxMorphicProject, navigate from SimpleMorphic to LegacyMorphc worlds and in SimpleMorphic
All windows via open works and text could be copied in Workspace via clipboard.
Edgar
On Sat, Apr 02, 2011 at 07:24:10AM -0300, Edgar J. De Cleene wrote:
On 4/2/11 6:48 AM, "Hannes Hirzel" hannes.hirzel@gmail.com wrote:
Anything is fine as long as SimpleMorphic will be the default in the future and the FullMorphic may be loaded on top of it (or by replacing it).
I think at this very moment it is not so much a discussion Metacello vs. Squeakmap but rather: Is it possible to load SimpleMorphic and what needs to be done to make it good enough for carrying the workload for developing in Squeak. And then the next question: can we put FullMorphic into squeaksource and make it possible to reload it from there.
BTW what do I need to do to load SimpleMorphic as of now?
David Lewis start a project into SqueakSource Bal?zs K?si send his own to this list some days ago and also I is working on it. For now and until all was merged, you could download SimpleMorphic-kb.10 from http://www.squeaksource.com/SimpleMorphicSqueak
And SMx-edc.20
You could open SMxMorphicProject, navigate from SimpleMorphic to LegacyMorphc worlds and in SimpleMorphic
All windows via open works and text could be copied in Workspace via clipboard.
Edgar
One note of caution: Don't save your image from a SimpleMorphic world, because there are still issues with image restart. Instead, return to Morphic or MVC and then save.
Dave
On 4/2/11 8:39 AM, "David T. Lewis" lewis@mail.msen.com wrote:
One note of caution: Don't save your image from a SimpleMorphic world, because there are still issues with image restart. Instead, return to Morphic or MVC and then save.
Dave
Having MonticelloBrowser window opwn in SimpleMorphic, still some dnu, see attached
Method scheduledWindowControllers is implemented in ControlManager , not in Controller
Also, for fileIn some Cuis methods, Juan have a different Compiler.
Must Cuis and Squeak 4.3 Compiler merge ?
Here is raining and nice for squeaking....
Edgar
Edgar J. De Cleene wrote:
On 4/2/11 8:39 AM, "David T. Lewis" lewis@mail.msen.com wrote:
One note of caution: Don't save your image from a SimpleMorphic world, because there are still issues with image restart. Instead, return to Morphic or MVC and then save.
Dave
Having MonticelloBrowser window opwn in SimpleMorphic, still some dnu, see attached
Method scheduledWindowControllers is implemented in ControlManager , not in Controller
Also, for fileIn some Cuis methods, Juan have a different Compiler.
Must Cuis and Squeak 4.3 Compiler merge ?
Here is raining and nice for squeaking....
Edgar
Hi Edgar,
Cuis doens't have a different compiler. It uses the same compiler as Squeak, and I keep it updated. I'm pretty sure any problems you might find is not because of the compiler.
What specific problems have you found?
Cheers, Juan Vuletich
Ps. Let me repeat that I support the initiatives to use SimpleMorphic on Squeak and Pharo, and I'm willing to answer any questions.
On 4/2/11 11:21 AM, "Juan Vuletich" juan@jvuletich.org wrote:
Hi Edgar,
Cuis doens't have a different compiler. It uses the same compiler as Squeak, and I keep it updated. I'm pretty sure any problems you might find is not because of the compiler.
What specific problems have you found?
Cheers, Juan Vuletich
From Cuis 3.1
Object subclass: #Compiler instanceVariableNames: 'sourceStream requestor class category context parser sourceStreamGetter' classVariableNames: '' poolDictionaries: '' category: 'Compiler-Kernel'
From Squeak4.3-11203.image updated to this morning
Object subclass: #Compiler instanceVariableNames: 'sourceStream requestor class category context parser' classVariableNames: '' poolDictionaries: '' category: 'Compiler-Kernel'
I found in Cuis reference to sourceStreamGetter and must fileOut and fileIn in Squeak
'From Cuis 3.1 of 4 March 2011 [latest update: #850] on 28 March 2011 at 8:40:12 am'!
!Compiler methodsFor: 'public access' stamp: 'jmv 3/18/2010 22:38'! sourceStreamGetter: aSymbol sourceStreamGetter _ aSymbol! !
'From Cuis 3.1 of 4 March 2011 [latest update: #850] on 1 April 2011 at 7:47:49 am'!
!Parser methodsFor: 'public access' stamp: 'jmv 8/28/2010 10:47'! sourceStreamGetter: aSymbol "Cuis specific. Do not remove!!" sourceStreamGetter _ aSymbol! !
Just now not remember the cause of the dnu, but hope you see the difference....
Edgar
Edgar J. De Cleene wrote:
On 4/2/11 11:21 AM, "Juan Vuletich" juan@jvuletich.org wrote:
Hi Edgar,
Cuis doens't have a different compiler. It uses the same compiler as Squeak, and I keep it updated. I'm pretty sure any problems you might find is not because of the compiler.
What specific problems have you found?
Cheers, Juan Vuletich
From Cuis 3.1
Object subclass: #Compiler instanceVariableNames: 'sourceStream requestor class category context parser sourceStreamGetter' classVariableNames: '' poolDictionaries: '' category: 'Compiler-Kernel'
From Squeak4.3-11203.image updated to this morning
Object subclass: #Compiler instanceVariableNames: 'sourceStream requestor class category context parser' classVariableNames: '' poolDictionaries: '' category: 'Compiler-Kernel'
I found in Cuis reference to sourceStreamGetter and must fileOut and fileIn in Squeak
'From Cuis 3.1 of 4 March 2011 [latest update: #850] on 28 March 2011 at 8:40:12 am'!
!Compiler methodsFor: 'public access' stamp: 'jmv 3/18/2010 22:38'! sourceStreamGetter: aSymbol sourceStreamGetter _ aSymbol! !
'From Cuis 3.1 of 4 March 2011 [latest update: #850] on 1 April 2011 at 7:47:49 am'!
!Parser methodsFor: 'public access' stamp: 'jmv 8/28/2010 10:47'! sourceStreamGetter: aSymbol "Cuis specific. Do not remove!!" sourceStreamGetter _ aSymbol! !
Just now not remember the cause of the dnu, but hope you see the difference....
Edga
Yes, there are some minor differences like that. But they don't affect source code compatibility. It still accepts the same source code and generates the same bytecodes.
Cheers, Juan Vuletich
On 4/2/11 11:21 AM, "Juan Vuletich" juan@jvuletich.org wrote:
Hi Edgar,
Cuis doens't have a different compiler. It uses the same compiler as Squeak, and I keep it updated. I'm pretty sure any problems you might find is not because of the compiler.
What specific problems have you found?
Cheers, Juan Vuletich
Also I found in classes exported from Cuis
'From Cuis 3.1 of 4 March 2011 [latest update: #850] on 27 March 2011 at 10:00:03 am'! !classDefinition: #Debugger category: #'Tools-Debugger'!
I follow in Cuis and learn, but this avoid direct fileOut and fileIn, need BBEdit
Still a lot to learn, be patient....
Edgar
Edgar J. De Cleene wrote:
On 4/2/11 11:21 AM, "Juan Vuletich" juan@jvuletich.org wrote:
Hi Edgar,
Cuis doens't have a different compiler. It uses the same compiler as Squeak, and I keep it updated. I'm pretty sure any problems you might find is not because of the compiler.
What specific problems have you found?
Cheers, Juan Vuletich
Also I found in classes exported from Cuis
'From Cuis 3.1 of 4 March 2011 [latest update: #850] on 27 March 2011 at 10:00:03 am'! !classDefinition: #Debugger category: #'Tools-Debugger'!
I follow in Cuis and learn, but this avoid direct fileOut and fileIn, need BBEdit
Still a lot to learn, be patient....
Edgar
Yes, in Cuis ClassDefinition is a proper change and not a doIt as in Squeak. This way you can view differences, 'remove all to date' and such, the same as with methods. Anyway, it is not a big deal at all. Cuis fileouts also include the doIt for the class definition. I did this only to ease exporting code for Squeak and Pharo. So, you can open the changes brower, and remove all the classDefinitions. Just ignore them.
Or better yet, add support for classDefinition in Squeak, it is a great enhancement.
Cheers, Juan Vuletich
Hi Juan,
Ps. Let me repeat that I support the initiatives to use SimpleMorphic on Squeak and Pharo, and I'm willing to answer any questions.
IIUC, Cuis' Morphic progressed quiet a bit compared to SimpleMorphic. So we're experimenting with tearing Morphic out from Cuis 3.1 and squeezing it into Squeak.
One thing I noted is that PasteUpMorph code never sets its worldState ivar, but the sole PasteUpMorph instance has a WorldState. How's that?
Our approach is that we fileOut classes from Cuis. Then load it applying some transformations, to rename classes, categories and class references. Then - at least that's the plan - the SMx support package should take care of the rest. What do you think?
Balázs
Hi Balázs,
Balázs Kósi wrote:
Hi Juan,
Ps. Let me repeat that I support the initiatives to use SimpleMorphic on Squeak and Pharo, and I'm willing to answer any questions.
IIUC, Cuis' Morphic progressed quiet a bit compared to SimpleMorphic. So we're experimenting with tearing Morphic out from Cuis 3.1 and squeezing it into Squeak.
One thing I noted is that PasteUpMorph code never sets its worldState ivar, but the sole PasteUpMorph instance has a WorldState. How's that?
That would be historic reasons... I guess. I don't really know if Squeak has or had code for setting the worldState ivar. In any case, that is indeed needed to be able to create new worlds.
Our approach is that we fileOut classes from Cuis. Then load it applying some transformations, to rename classes, categories and class references. Then - at least that's the plan - the SMx support package
should take care of the rest. What do you think?
Balázs
Sounds very good. It is quite like I did the first version of SimpleMorphic.
Maybe it is easier if you first load the current version of SimpleMorphic, and then compare with the code you bring from Cuis 3.1, to see the differences... I did need to tweak a lot of details to make it load in Pharo, and I guess David did further changes to load into Squeak. If you just compare differences it will be easier to tell which are changes done for Pharo/Squeak compatibility and which ones are stuff that was later updated in Cuis...
Good luck!
Cheers, Juan Vuletich
Juan Vuletich wrote:
... Sounds very good. It is quite like I did the first version of SimpleMorphic.
Maybe it is easier if you first load the current version of SimpleMorphic, and then compare with the code you bring from Cuis 3.1, to see the differences... I did need to tweak a lot of details to make it load in Pharo, and I guess David did further changes to load into Squeak. If you just compare differences it will be easier to tell which are changes done for Pharo/Squeak compatibility and which ones are stuff that was later updated in Cuis...
Good luck!
Cheers, Juan Vuletich
I forgot to say: Start with the latest code for Cuis. The latest, still unreleased code is at http://www.jvuletich.org/Cuis/Cuis3.1-0892.zip . On top of this load http://www.jvuletich.org/Cuis/0893a0895.zip .
Cheers, Juan Vuletich
On 02.04.2011, at 01:42, Levente Uzonyi wrote:
On Fri, 1 Apr 2011, Bert Freudenberg wrote:
On 31.03.2011, at 21:15, David T. Lewis wrote:
On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
I think we could do even better: Make all the ui frameworks loadable and unloadable, and make it easy to implement your own.
Bal?zs
Yes!
Dave
Not quite a plan yet, but great idea!
The old FullMorphic could be maintained as part of Etoys.
Another possible solution is to implement Andreas' idea about Community Supported Packages* (which slight modifications) and maintain it there. Of course, it has to be made unloadable/loadable first.
Levente
*http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html
Yes, that's basically what I meant. Etoys should become such a package too, and it would go together with the full Morphic package because it needs it.
The only progress we made so far to the goal of folding Etoys back into Squeak was to switch to Monticello packages. But eventually that's where I see the future of Etoys, rather than as a fork.
- Bert -
On 3/31/11 2:46 PM, "Casey Ransberger" casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
+1 This is my view also. I push the idea of unloadable / loadable packages in 3.10.
Once we have SimpeMorphic working not only like in Cuis , also all tools like PackageBrowser, MonticelloBrowser, etc, we could unload LegacyMorphic (like this name)
And learn enough for my proposal of Traslator package, something taking LegacyMorphic and convert to SimpleMorphic.
Edgar
On 4/1/11, Edgar J. De Cleene edgardec2005@gmail.com wrote:
On 3/31/11 2:46 PM, "Casey Ransberger" casey.obrien.r@gmail.com wrote:
I'd like to reverse this statement. In the longer term I'd like to see SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or whatever we'd call it out of the core and into Squeaksource.
+1 This is my view also.
+1
--Hannes
I'd like to see it adopted, but my time is currently pretty limited. If there's anything specific that you want help with, let me know and I'll see what I can do.
On Mar 31, 2011, at 4:02 AM, "Edgar J. De Cleene" edgardec2005@gmail.com wrote:
On 3/30/11 11:57 AM, "Balázs Kósi" rebmekop@gmail.com wrote:
Hi,
I'm done with copying the Editor classes from Cuis, and made some other minor advancements too.
You can load it with:
Installer mc http: 'http://leves.web.elte.hu/squeak'; install: 'SimpleMorphic-kb.10.mcz'; install: 'SMx-kb.18.mcz'
I think we should use the ToolBuilder for tools instead of SimpleMorphic-Tools (eg. SMxBrowserWindow). In this new version you can evaluate Browser open, and get a functional but a bit ugly browser.
Balázs
SimpleMorphic-kb.10
- use SMxEditors instead of squeak Editors
- SMxLayoutFrame missed some accessors
- Use ToolBuilder version of Inspector in SMxMorph >> inspecInMorphic:
- Use squeak protocol of styling in SMXPluggableTextMorph
- added: SMxPluggableTextMorph >> select, sent by the parser when
correcting variables
- Use ToolBuilder version of Browser in SMXTheWorldMenu
SMx-kb.18
- copied Cuis' Editor hierarchy: SMxEditor, SMxTextEditor,
SMxSmalltalkEditor.
- removed extensions from Squeak's Editor hierarchy
- rewrote Editor/TextEditor/SmalltalkEditor class references to their
SMx versions.
- commented out some OSProcess trace sends
- fiddled with SimpleMorphicToolBuilder >> setLayout:in: to do something.
This works well.
In particular , like dnu in SimpleMorphic world raise a debugger, a step forward for me.
Is possible you, David Lewis, me , others Squeakers work together for having full functional SimpleMorphic into Squeak 4.3 ?
Edgar
On Wed, Mar 30, 2011 at 04:57:29PM +0200, Bal?zs K?si wrote:
Hi,
I'm done with copying the Editor classes from Cuis, and made some other minor advancements too.
You can load it with:
Installer mc http: 'http://leves.web.elte.hu/squeak'; install: 'SimpleMorphic-kb.10.mcz'; install: 'SMx-kb.18.mcz'
Hi Bal?zs,
I took the liberty of copying your SimpleMorphic-kb.10.mcz and SMx-kb.18.mcz into the SimpleMorphic for Squeak project on SqueakSource. I have not tried to merge the changes, so there may be conflicts.
You have developer access on the SqS project, so please feel free to commit directly.
Thanks! Dave
On Mon, Mar 28, 2011 at 01:10:22PM +0200, Bal?zs K?si wrote:
Hi,
- The Editor hierarchy in Cuis has been updated in a very nice way
(event dispatch) but there are lots of changes compared with Squeak. Menus are different also. Making SimpleMorphic loadable as a project type makes it easy to compare the two. I renamed some of the event handling methods (e.g. Editor>>backspace: becomes Editor>>backspaceEvent: so the original Editor>>backspace: method remains in place for use by Morphic and MVC).
What do you think about copying Cuis' Editor hierarchy for SimpleMorphic instead of adapting the current Editor hierarchy to cope in both environments?
Bal?zs,
That might be a good approach. I am not really sure which is better. The nice thing about the Project environment in Squeak is that we can try things like this fairly easily and see which approach we like better :)
I have to say that I more or less fumbled my way through this so far, so there is no guarantee that anything I did is the right approach.
One thing I did learn in this process is that some ToolBuilder layout support will be needed to get the debugger to open correctly (note the missing buttons). I have a suspicion that this is the exactly same problem that is affecting MVC (try a self halt in an MVC project and you will see the same thing). So I hope that once we figure out how to make a debugger open properly in a SMxMorphicProject, we will be able to apply a similar fix to MVC.
Dave
Hi,
One thing I did learn in this process is that some ToolBuilder layout support will be needed to get the debugger to open correctly (note the missing buttons). I have a suspicion that this is the exactly same problem that is affecting MVC (try a self halt in an MVC project and you will see the same thing). So I hope that once we figure out how to make a debugger open properly in a SMxMorphicProject, we will be able to apply a similar fix to MVC.
I've fiddled with the SimpleMorphicToolBuilder >> setLayout:in: a bit, and the Debugger is functional, you can try it. I think the problem is with the implementation of this method in the MVCToolBuilder, I've tried to debug it, but I don't know enough yet.
Balázs
On 3/31/11, Balázs Kósi rebmekop@gmail.com wrote:
Hi,
One thing I did learn in this process is that some ToolBuilder layout support will be needed to get the debugger to open correctly (note the missing buttons). I have a suspicion that this is the exactly same problem that is affecting MVC (try a self halt in an MVC project and you will see the same thing). So I hope that once we figure out how to make a debugger open properly in a SMxMorphicProject, we will be able to apply a similar fix to MVC.
I've fiddled with the SimpleMorphicToolBuilder >> setLayout:in: a bit, and the Debugger is functional, you can try it. I think the problem is with the implementation of this method in the MVCToolBuilder, I've tried to debug it, but I don't know enough yet.
Balázs
Balázs,
Which file should I use to get your version?
http://www.squeaksource.com/SimpleMorphicSqueak/
Or shall I go for the version of Edgar? SimpleMorphic-edc.11.mcz
Did you have a look at his changes?
--Hannes
On 4/8/11 11:46 AM, "Hannes Hirzel" hannes.hirzel@gmail.com wrote:
Or shall I go for the version of Edgar? SimpleMorphic-edc.11.mcz
Did you have a look at his changes?
--Hannes
Wait a little and you have Monticello Browser inside SimpleMorphic. Still fighting and learning, all need test and reshape.
Edgar
squeak-dev@lists.squeakfoundation.org
-
Balázs Kósi -
Bert Freudenberg -
Casey Ransberger -
David T. Lewis -
Edgar J. De Cleene -
Hannes Hirzel -
Juan Vuletich -
Levente Uzonyi