August 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] [BUG] Blink cursor does not work!

by StÃ©phane Ducasse

in latest core 414 Blink cursor does not work and pops up a DNU. Argh I should not have pushed this fix in pharo. Torsten can yo have a look? VM: Mac OS - intel - 1058 - Squeak3.8.1 of '28 Aug 2006' [latest update: #6747] Squeak VM 4.1.1b2 Image: Pharo1.0beta [Latest update: #10414] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/ Pharo Trusted Dir /foobar/tooBar/forSqueak/bogus Untrusted Dir /Users/ducasse/Library/Preferences/Squeak/Internet/My Squeak TextMorphForEditView(Object)>>doesNotUnderstand: #onBlinkCursor Receiver: a TextMorphForEditView(3667) Arguments and temporary variables: aMessage: onBlinkCursor exception: MessageNotUnderstood: TextMorphForEditView>>onBlinkCursor resumeValue: nil Receiver's instance variables: bounds: 0@0 corner: 429@114 owner: a TransformMorph(1088) submorphs: #() fullBounds: 0@0 corner: 429@114 color: Color black extension: a MorphExtension (3610) [other: (blinkStart -> 43651)] borderWidth: 0 borderColor: Color black textStyle: a TextStyle Accuny12(FontSet) text: a Text for 'ScriptLoader new installingInstaller |i| i := Installer mont...etc... wrapFlag: true paragraph: a MultiNewParagraph editor: nil container: nil predecessor: nil successor: nil backgroundColor: nil margins: nil editHistory: a TextMorphCommandHistory editView: a PluggableTextMorph(20) acceptOnCR: false StepMessage(MessageSend)>>value Receiver: StepMessage(#onBlinkCursor -> a TextMorphForEditView(3667)) (a TextMorphForEditView(3667) #...etc... Arguments and temporary variables: Receiver's instance variables: receiver: a TextMorphForEditView(3667) selector: #onBlinkCursor arguments: nil scheduledTime: 622667 numArgs: 0 stepTime: 500 StepMessage(MorphicAlarm)>>value: Receiver: StepMessage(#onBlinkCursor -> a TextMorphForEditView(3667)) (a TextMorphForEditView(3667) #...etc... Arguments and temporary variables: anArgument: 622684 nArgs: 0 Receiver's instance variables: receiver: a TextMorphForEditView(3667) selector: #onBlinkCursor arguments: nil scheduledTime: 622667 numArgs: 0 stepTime: 500 WorldState>>runLocalStepMethodsIn: Receiver: a WorldState Arguments and temporary variables: aWorld: a PasteUpMorph(1622) [world] now: 622684 morphToStep: a TextMorphForEditView(3667) stepTime: nil priorWorld: a PasteUpMorph(1622) [world] Receiver's instance variables: hands: an Array(a HandMorph(3216)) viewBox: 0@0 corner: 1174@762 canvas: a FormCanvas on: DisplayScreen(1174x762x32) damageRecorder: a DamageRecorder stepList: a Heap(StepMessage(#stepAt: -> a SystemWindow(2954))(a SystemWindow(2...etc... lastStepTime: 692461 lastStepMessage: nil lastCycleTime: 692422 commandHistory: a CommandHistory alarms: a Heap() lastAlarmTime: 692461 WorldState>>runStepMethodsIn: Receiver: a WorldState Arguments and temporary variables: aWorld: a PasteUpMorph(1622) [world] queue: a SharedQueue nextInQueue: nil Receiver's instance variables: hands: an Array(a HandMorph(3216)) viewBox: 0@0 corner: 1174@762 canvas: a FormCanvas on: DisplayScreen(1174x762x32) damageRecorder: a DamageRecorder stepList: a Heap(StepMessage(#stepAt: -> a SystemWindow(2954))(a SystemWindow(2...etc... lastStepTime: 692461 lastStepMessage: nil lastCycleTime: 692422 commandHistory: a CommandHistory alarms: a Heap() lastAlarmTime: 692461 PasteUpMorph>>runStepMethods Receiver: a PasteUpMorph(1622) [world] Arguments and temporary variables: Receiver's instance variables: bounds: 0@0 corner: 1174@762 owner: nil submorphs: an Array(a TaskbarMorph(3095) a SystemWindow(2954) a SystemWindow(87...etc... fullBounds: 0@0 corner: 1174@762 color: (Color r: 0.97 g: 0.98 b: 1.0) extension: a MorphExtension (2543) [eventHandler = an EventHandler] [other: (...etc... borderWidth: 0 borderColor: (Color r: 0.03 g: 0.02 b: 0.0) presenter: a Presenter (1246) model: a MorphicModel(1926) cursor: 1 padding: 3 backgroundMorph: nil isPartsBin: nil autoLineLayout: false indicateCursor: nil resizeToFit: nil wantsMouseOverHalos: nil worldState: a WorldState griddingOn: nil WorldState>>doOneCycleNowFor: Receiver: a WorldState Arguments and temporary variables: aWorld: a PasteUpMorph(1622) [world] Receiver's instance variables: hands: an Array(a HandMorph(3216)) viewBox: 0@0 corner: 1174@762 canvas: a FormCanvas on: DisplayScreen(1174x762x32) damageRecorder: a DamageRecorder stepList: a Heap(StepMessage(#stepAt: -> a SystemWindow(2954))(a SystemWindow(2...etc... lastStepTime: 692461 lastStepMessage: nil lastCycleTime: 692422 commandHistory: a CommandHistory alarms: a Heap() lastAlarmTime: 692461 WorldState>>doOneCycleFor: Receiver: a WorldState Arguments and temporary variables: aWorld: a PasteUpMorph(1622) [world] Receiver's instance variables: hands: an Array(a HandMorph(3216)) viewBox: 0@0 corner: 1174@762 canvas: a FormCanvas on: DisplayScreen(1174x762x32) damageRecorder: a DamageRecorder stepList: a Heap(StepMessage(#stepAt: -> a SystemWindow(2954))(a SystemWindow(2...etc... lastStepTime: 692461 lastStepMessage: nil lastCycleTime: 692422 commandHistory: a CommandHistory alarms: a Heap() lastAlarmTime: 692461 PasteUpMorph>>doOneCycle Receiver: a PasteUpMorph(1622) [world] Arguments and temporary variables: Receiver's instance variables: bounds: 0@0 corner: 1174@762 owner: nil submorphs: an Array(a TaskbarMorph(3095) a SystemWindow(2954) a SystemWindow(87...etc... fullBounds: 0@0 corner: 1174@762 color: (Color r: 0.97 g: 0.98 b: 1.0) extension: a MorphExtension (2543) [eventHandler = an EventHandler] [other: (...etc... borderWidth: 0 borderColor: (Color r: 0.03 g: 0.02 b: 0.0) presenter: a Presenter (1246) model: a MorphicModel(1926) cursor: 1 padding: 3 backgroundMorph: nil isPartsBin: nil autoLineLayout: false indicateCursor: nil resizeToFit: nil wantsMouseOverHalos: nil worldState: a WorldState griddingOn: nil [] in Project class>>spawnNewProcess Receiver: Project Arguments and temporary variables: Receiver's instance variables: superclass: Model methodDict: a MethodDictionary(size 167) format: 172 instanceVariables: #('world' 'changeSet' 'transcript' 'parentProject' 'previous...etc... organization: ('*sound') ('accessing' addSubProjectNamesTo:indentation: changeS...etc... subclasses: nil name: #Project classPool: a Dictionary(#AllProjects->an OrderedCollection(a Project(Unnamed)) ...etc... sharedPools: nil environment: Smalltalk category: #'System-Support' traitComposition: {} localSelectors: nil [] in BlockClosure>>newProcess Receiver: [closure] in Project class>>spawnNewProcess Arguments and temporary variables: Receiver's instance variables: outerContext: Project class>>spawnNewProcess startpc: 53 numArgs: 0 --- The full stack --- TextMorphForEditView(Object)>>doesNotUnderstand: #onBlinkCursor StepMessage(MessageSend)>>value StepMessage(MorphicAlarm)>>value: WorldState>>runLocalStepMethodsIn: WorldState>>runStepMethodsIn: PasteUpMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess [] in BlockClosure>>newProcess

Aug. 17, 2009

[Pharo-project] Call for synchronization with OB tools

by StÃ©phane Ducasse

Hi all I'm totally confused about the state of the OB tools and this is not a good point. So which version are loaded in pharo? What is the status of these versions? For the pharo book we are stuck because the chapters were using the package browser but now we cannot load it. Who controls what is loaded as OB tools? Stef (quite worried).

Aug. 17, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Henrik Johansen

On Aug 16, 2009, at 4:57 17PM, Igor Stasenko wrote: > 2009/8/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Sig, >> >> Two UI processes polling for input is probably what has happened. >> I should give some attention to how Dolphin prevents that. Two >> things that come to mind are raising the priority of a new UI >> thread to create a modal event loop, and (which Pharo almost >> certainly does too) starting a new UI thread when needed. >> >> My TimedEvaluator class has headless and "with progres" >> subclasses. The latter will need some porting, and perhaps the >> headless one should simply block, or at least do so in Pharo. >> >> Terminating the UI thread seems a little harsh, but that might be >> what is needed. > > Sure it is what debugger does when you closing its window - it > terminating the process you currently debugging. Nothing harsh or > wrong and nothing to worry about (usually). :) > >> Another option might be to suspend the old UI thread, start the new >> one, and then undo the damage at the end. > > There are is a little damage which is done when you doing that - > mainly the event which is currently handled is lost, but since your > intent to terminate the current process, as a result of event > handling, nothing wrong with it. As for the rest , when you start a > new UI process everything continues to work normally. I don't know if you remember, but there was a DNU bug some months ago (probably) caused by 2 UI-processes being active for a short period of time, one nilling mouse state after the other had initiated mouse handling. At least that was the only explanation I could come up with,nobody replied whether the scenario I described was actually possible :) http://n2.nabble.com/-ANN--MouseOverHandler-refactoring-td3068941.html#a309… Cheers, Henry

Aug. 17, 2009

Re: [Pharo-project] Squeak versus Pharo as application name

by Eagle Offshore

I think that the name has to come from the executable. The idea of Pharo is to have a Smalltalk that can be shipped. So if someone were to create an application and wanted a custom wrapped double clickable file with a name like - oh - Sophie.app - then it would adjust the menus appropriately. On Aug 16, 2009, at 11:37 PM, StÃ©phane Ducasse wrote: > The simplest for you and > > On Aug 17, 2009, at 2:25 AM, John M McIntosh wrote: > >> >> On 16-Aug-09, at 2:50 PM, StÃ©phane Ducasse wrote: >> >>> The point is that pharoers should implement the vision not pharo. >>> We have enough to do. The fact that pharo will succeed depends also >>> on >>> us as >>> a community nor just 5 guys doing an integration of fixes. >>> >>> Stef >> >> Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Ty… >> >> Part of this is the *purge* of the string Squeak from the image, so >> Quit Squeak Vm doesn't fire the quit logic >> >> (a) I'd rather not have to build two VMs, one for Squeak and one for >> Pharo > > agree. Now does the event cleaning and other have no impact on the vm > level? > >> (b) Also I'd rather not have to answer is the Pharo VM different from >> the Squeak VM? > agree > >> (c) If you take the Squeak.app and rename it all to Pharo then >> someone >> has to manage that process and ensure the Pharo clone is cloned >> properly from the Squeak.app > > yes may be we could have a script for that > >> (d) if you have a Pharo.app the question then is where did it come >> from? > > **We** could have a script for transforming squeakvm into pharo vm > >> (e) I do agree having a Pharo app, then seeing quit Squeak VM is very >> confusing, therefore people should be able to change that to suit >> their needs. > > may be we should use platform and extend it to vm or system name >> >> So how would people like to see how this would work. >> >> This of course precludes any discussion of how the linux & windows >> versions behave and give textual feedback. >> >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] Squeak versus Pharo as application name

by StÃ©phane Ducasse

The simplest for you and On Aug 17, 2009, at 2:25 AM, John M McIntosh wrote: > > On 16-Aug-09, at 2:50 PM, StÃ©phane Ducasse wrote: > >> The point is that pharoers should implement the vision not pharo. >> We have enough to do. The fact that pharo will succeed depends also >> on >> us as >> a community nor just 5 guys doing an integration of fixes. >> >> Stef > > Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Ty… > > Part of this is the *purge* of the string Squeak from the image, so > Quit Squeak Vm doesn't fire the quit logic > > (a) I'd rather not have to build two VMs, one for Squeak and one for > Pharo agree. Now does the event cleaning and other have no impact on the vm level? > (b) Also I'd rather not have to answer is the Pharo VM different from > the Squeak VM? agree > (c) If you take the Squeak.app and rename it all to Pharo then someone > has to manage that process and ensure the Pharo clone is cloned > properly from the Squeak.app yes may be we could have a script for that > (d) if you have a Pharo.app the question then is where did it come > from? **We** could have a script for transforming squeakvm into pharo vm > (e) I do agree having a Pharo app, then seeing quit Squeak VM is very > confusing, therefore people should be able to change that to suit > their needs. may be we should use platform and extend it to vm or system name > > So how would people like to see how this would work. > > This of course precludes any discussion of how the linux & windows > versions behave and give textual feedback. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] Question about MD5

by StÃ©phane Ducasse

>> 1) commit the hole package to PharoInbox repo or read the wiki since everything is explained. How to contribute http://code.google.com/p/pharo/wiki/HowToContribute

Aug. 17, 2009

[Pharo-project] swapMouseButtons

by Philippe Marschall

Hi What happened to the swapMouseButtons preference? On Linux the middle and right mouse button are wrong. Cheers Philippe

Aug. 17, 2009

Re: [Pharo-project] Squeak versus Pharo as application name

by Eagle Offshore

Why are the menus not being built from within the image/and/or the path/name of the executable? On Aug 16, 2009, at 5:25 PM, John M McIntosh wrote: > > On 16-Aug-09, at 2:50 PM, StÃ©phane Ducasse wrote: > >> The point is that pharoers should implement the vision not pharo. >> We have enough to do. The fact that pharo will succeed depends also >> on >> us as >> a community nor just 5 guys doing an integration of fixes. >> >> Stef > > Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Ty… > > Part of this is the *purge* of the string Squeak from the image, so > Quit Squeak Vm doesn't fire the quit logic > > (a) I'd rather not have to build two VMs, one for Squeak and one for > Pharo > (b) Also I'd rather not have to answer is the Pharo VM different from > the Squeak VM? > (c) If you take the Squeak.app and rename it all to Pharo then someone > has to manage that process and ensure the Pharo clone is cloned > properly from the Squeak.app > (d) if you have a Pharo.app the question then is where did it come > from? > (e) I do agree having a Pharo app, then seeing quit Squeak VM is very > confusing, therefore people should be able to change that to suit > their needs. > > So how would people like to see how this would work. > > This of course precludes any discussion of how the linux & windows > versions behave and give textual feedback. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by Carlos Crosetti

IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on what goes in and out - I value that some people are acting as gatekeepers. Then a second community, those who develop frameworks that run on top of Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name a few coming from the top of my head) may probably try to ensure their frameworks progresses aligned with the Pharo releases, demanding a rrobust and performant Smalltalk system impementattion. Now, to boost Pharo adoption, beyod smalltalkers, and to capture the attention of new people, probably not familiar with the language, technology, style, the system itself, the paradigm, and (why not) the culture,, a new foundation of spin-off should address the level of effort to envision and manufacture... #1 a rich set of widgets and #2 recipes showing how to combine them to produce high-impact realtime client GUIs As an example I mention what - Swing, AWT and SWT is for Java, - Tk is for Tcl, - GTK+ to C++, (and lots of....) - UIPaainter to VisualWorks, and so on..:) -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de csrabak(a)bol.com.br Enviado el: SÃ¡bado, 15 de Agosto de 2009 01:04 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] ORM for Pharo -- Â½ OFF Mariano, I can understand the goal be Pharo idea and goal as you post. What I'm trying to bring (and hopefully add to this discussion) is how can we arrive there. We need to narrow down the definition of "enterprise application" and see where Pharo can start to thrive. No all encompassing approach would work as notwithstanding how poweful and complete Pharo could become it will not be anytime soon. The notion that Pharo be not assotiated per se to any UI it is a strong (and I vote to maintain it) design goal but in order to push forward Pharo together with robust and clean implementation we'll need a lot of energy and effort to produce enough educational materials like tutorial, manuals, etc., it will be confusing all the time have an example that do not work in another minor variation of UI (to stay in a single topic). So I return to the point: we need to have more clear goals on what particular realm we see Pharo as feasible for enterprise development and be able to enumerate what are the advantages of Pharo versus the other approaches. Hope it is more explicit now ;-) Em 14/08/2009 20:42, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: 2009/8/14 <csrabak(a)bol.com.br> Mariano, I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list: -- They have an "architectural steering committee" that dictates use of some RDBS I've seen this even requiring some ERP used different database engine thas suggested by supplier. . . So if we want to compete with enterprise applications we need to get into some Enterprise: We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support. Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB. So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path). Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk? As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application? I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications. In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs. In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects. Best, Mariano again my 0.01999.... Regards, -- Cesar Rabak Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: 2009/8/14 <csrabak(a)bol.com.br> Esteban, I'm comenting this on philosophical grounds. I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project: I don't see Pharo any time soonÂ® having all the toolset to be able to compete in the CRUDÂ¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there, Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons: - The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB. Best, Mariano a recent and practicall account of this (for Squeak) can be found in http://onsmalltalk.com/simple-image-based-persistence-in-squeak also, AIDA/Web has been able to run only storing thing in the image! See http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3b… Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed. my 0.0199999.... -- Cesar Rabak [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo(a)gmail.com > escreveu: My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it. What are the choices I have for doing ORM in Pharo? Â¿Does GLORP work? Â¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express. Best regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

[Pharo-project] Squeak versus Pharo as application name

by John M McIntosh

On 16-Aug-09, at 2:50 PM, StÃ©phane Ducasse wrote: > The point is that pharoers should implement the vision not pharo. > We have enough to do. The fact that pharo will succeed depends also on > us as > a community nor just 5 guys doing an integration of fixes. > > Stef Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Ty… Part of this is the *purge* of the string Squeak from the image, so Quit Squeak Vm doesn't fire the quit logic (a) I'd rather not have to build two VMs, one for Squeak and one for Pharo (b) Also I'd rather not have to answer is the Pharo VM different from the Squeak VM? (c) If you take the Squeak.app and rename it all to Pharo then someone has to manage that process and ensure the Pharo clone is cloned properly from the Squeak.app (d) if you have a Pharo.app the question then is where did it come from? (e) I do agree having a Pharo app, then seeing quit Squeak VM is very confusing, therefore people should be able to change that to suit their needs. So how would people like to see how this would work. This of course precludes any discussion of how the linux & windows versions behave and give textual feedback. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 17, 2009