January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] roadmap

by Tudor Girba

+1 On Wed, Jan 4, 2012 at 1:45 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Can we lower tension a bit? To me it sounds as you are pretty much in sync. > > Am 03.01.2012 um 09:09 schrieb StÃ©phane Ducasse: > >> >>>>> >>>>> Then my question is: How can anybody use Pharo that does not want to >>>>> use your changes of AST and FS? >>>> >>>> Normally we talk and we reach a consensus. >>> >>> The issue here is that FS was a separately maintained package that was (and apparently still is) loaded into different places. Adding the FS packages to Pharo amounts to a fork of FS. In hindsight, there should have been a discussion at that point. >> >> Apparently you did not browse enough the archive because it was mentioned and mentioned and mentioned and and mentioned again. >> We even stopped to fork it and published our changes to a common repository. instead of PharoTaskForces. >> > So if the FS in pharo is exactly the FS in the repository then there is no fork and no problem for others. And maybe you (Stef) could add that at a later time when the tiny kernel is present there would be only FS that is loaded as a module to the system, right? At this point I can see an agreement of all participating parties. > >>> Is it possible to maintain FS as a separate package, >> >> yes now what would be the key reason? >> Did you ever see a smalltalk without its own file system? >> The same question goes for the compiler. Can OPAL work without its own AST? >> Now if you read carefully my emails you will see that the door is always open but so far >> I did not hear anything about possible collaboration and as its latin root probably indicate >> to collaborate we should be two willing to do it. >> >> Let us take a concrete example: Â Pinocchio for example developed a large set of registry allocation for assembly generation and other analysis. Pinocchio people released the code under MIT and camillo spent time to make sure that their >> analyses work on our system. So should we throw away this effort because we cannot add nodes to AST? >> Frankly? What I asked is a discussion and so far I did not get anything concrete. >> > Adding nodes means adding classes. That should be no problem at all. The question is if those changes are valuable for all. Then the extension nodes should go in the AST package. If the extra nodes are for special purpose than they should go in a extra package that is to be loaded in order to use OPAL. I can't see here a single problem except negotiation and communication. > > my 2 things, > > Norbert > >>> and use it for Pharo core? I think the answer is yes, because it is possible to run without .sources and .changes files. >> >> Do you think that the system works without files? >> >>> IMHO, the right way forward is to make it a priority to build the "core" from PharoKernel, and the modularity everyone wants will be a natural outcome. >> >> Did you check the FS repository recently to see the changes we are talking about? >> May be this is not 100% published in fs but this is easy to do it :) >> Why somebody does not merge in both way? >> We spent time commenting the code that we do not know because they was no serious comments. damien improved some part, camillo spent some time to fix some other problems. Now the code is there so what? >> >> Stef >> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 4, 2012

Re: [Pharo-project] glamour and pharo (& roadmap)

by Henrik Sperre Johansen

On 03.01.2012 15:44, Igor Stasenko wrote: > On 3 January 2012 15:21, Ben Coman<btc(a)openinworld.com> wrote: >> I am reminded of an article "Things You Should Never Do" [1] by one of my >> favourite authors. This is not to discourage the clean out and >> re-architecture of Pharo which is overall a good thing, but just to consider >> the downside and risk as a counter-point. Certainly Pharo is more evolving >> than starting from scratch... >> And then I got sucked into reading another (perhaps offtopic) article >> "Painless Functional Specifications" [2] that some may find interesting >> >> [1] http://www.joelonsoftware.com/articles/fog0000000069.html >> [2] http://www.joelonsoftware.com/articles/fog0000000036.html >> >> > yes, a new is not necessary better than old. In the case of - Announcements vs Events, - FileSystem vs. FileDirectory&Friends - Opal vs. current Compiler I would say there's a strong case for considering the new alternative "better". > And if you ask me, i never throw away stuff, just because it is 'old'. > if its in good condition and still can be used, > why we should throw it away? > Why should be throw the old ones away you ask? We shouldn't. We should, however: a) Migrate code in core to use new systems. b) Repackage old systems to be unloadable/reloadable for external projects who still rely on them. c) Remove them from core, leaving one choice by default for building code using such systems, reducing confusion. d) Introduce namespaces, so folks who don't like the versions of those systems existing in core capable of loading alternate versions without a massive renaming effort. As for the question, what belongs in a Core image? Well, I for one would like compiler/decompiler in there. I'd also like an easily modifiable/understandable one. Haven't really read the current one, nor Opal enough to have an educated opinion on which is "better" in those regards, but others seem to. If that Compiler requires an AST, yes, it should be in Core. I'd also like the ability to write a sources file, but decoupled from the presence of a Compiler in a way which make me able to unload it if I don't need it. (say, for a minimal image) Doing so in a clean way sort of requires an event-system, my choice for that would be Announcements. It also requires interacting with the file system. So I'd like a system doing that in Core as well. A graphical framework? Sure. Tools written in the GUI to modify/inspect the system from within the image? Absolutely. Refactoring? While I like it, I don't think it's important enough to necessarily include in a "Core" image. (Full image? Absolutely) Syntax highlighting? Same as refactoring. As for dealing with systems also existing as external packages, in addition to d) above, I 100% agree with Nortbert's mail. I don't see why one could not work out solutions for synching with external repositories in addition to the Pharo-specific one, and/or introduce extensions used in Pharo as just that, extensions. Cheers, Henry IOW; A bit late perhaps, but I don't think the merge of Full and Core was a good thing, and would rather if the image builder took care of such tasks... As long as the packages are "pure" in the sense they contain no overrides, there is no reason one could not work on/commit fixes to the Core parts of the system from a "Full" image if one felt the tools/functionality included in Full are worth it.

Jan. 4, 2012

Re: [Pharo-project] roadmap

by Norbert Hartl

Can we lower tension a bit? To me it sounds as you are pretty much in sync. Am 03.01.2012 um 09:09 schrieb StÃ©phane Ducasse: > >>>> >>>> Then my question is: How can anybody use Pharo that does not want to >>>> use your changes of AST and FS? >>> >>> Normally we talk and we reach a consensus. >> >> The issue here is that FS was a separately maintained package that was (and apparently still is) loaded into different places. Adding the FS packages to Pharo amounts to a fork of FS. In hindsight, there should have been a discussion at that point. > > Apparently you did not browse enough the archive because it was mentioned and mentioned and mentioned and and mentioned again. > We even stopped to fork it and published our changes to a common repository. instead of PharoTaskForces. > So if the FS in pharo is exactly the FS in the repository then there is no fork and no problem for others. And maybe you (Stef) could add that at a later time when the tiny kernel is present there would be only FS that is loaded as a module to the system, right? At this point I can see an agreement of all participating parties. >> Is it possible to maintain FS as a separate package, > > yes now what would be the key reason? > Did you ever see a smalltalk without its own file system? > The same question goes for the compiler. Can OPAL work without its own AST? > Now if you read carefully my emails you will see that the door is always open but so far > I did not hear anything about possible collaboration and as its latin root probably indicate > to collaborate we should be two willing to do it. > > Let us take a concrete example: Pinocchio for example developed a large set of registry allocation for assembly generation and other analysis. Pinocchio people released the code under MIT and camillo spent time to make sure that their > analyses work on our system. So should we throw away this effort because we cannot add nodes to AST? > Frankly? What I asked is a discussion and so far I did not get anything concrete. > Adding nodes means adding classes. That should be no problem at all. The question is if those changes are valuable for all. Then the extension nodes should go in the AST package. If the extra nodes are for special purpose than they should go in a extra package that is to be loaded in order to use OPAL. I can't see here a single problem except negotiation and communication. my 2 things, Norbert >> and use it for Pharo core? I think the answer is yes, because it is possible to run without .sources and .changes files. > > Do you think that the system works without files? > >> IMHO, the right way forward is to make it a priority to build the "core" from PharoKernel, and the modularity everyone wants will be a natural outcome. > > Did you check the FS repository recently to see the changes we are talking about? > May be this is not 100% published in fs but this is easy to do it :) > Why somebody does not merge in both way? > We spent time commenting the code that we do not know because they was no serious comments. damien improved some part, camillo spent some time to fix some other problems. Now the code is there so what? > > Stef > > > >

Jan. 4, 2012

[Pharo-project] why World Menu > System > Software Update missing from Pharo 1.3

by Ben Coman

Milan Mimica wrote: > Hello! > > I can quite easily crash the VM when updating pharo 1.4 image (Right click > -> System -> Software Update). It crashes almost always. VM is Cog r2522. > As an aside, I actually went looking for a Software Update menu item in Pharo 1.3 yesterday and could not find it. I notice that it is there in Pharo 1.2.1 and 1.4. Why is it gone from 1.3? btw, I assume that this updates to the latest trunk ?

Jan. 4, 2012

[Pharo-project] VM crash on update

by Milan Mimica

Hello! I can quite easily crash the VM when updating pharo 1.4 image (Right click -> System -> Software Update). It crashes almost always. VM is Cog r2522. (gdb) bt #0 markAndTrace (oop=-7168) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20994 #1 0x080602c2 in markAndTraceStackPage (thePage=0xffffaa8c) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20887 #2 0x0806036d in markAndTraceStackPages (fullGCFlag=<value optimized out>) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20777 #3 markAndTraceInterpreterOops (fullGCFlag=<value optimized out>) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20648 #4 0x080746b1 in markPhase (fullGCFlag=-2139637670) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:21333 #5 0x08074d3e in incrementalGC () at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:17530 #6 0x080751ff in sufficientSpaceAfterGC (minFree=-2139637670) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:43517 #7 0x08078081 in checkForEventsMayContextSwitch (mayContextSwitch=1) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:11257 #8 0x0807a6e0 in ceCheckForInterrupts () at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:10012 #9 0xb79886eb in ?? () #10 0x08082164 in initStackPagesAndInterpret () at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:18088 #11 0x0805c49a in main (argc=Cannot access memory at address 0x8077b85a ) at /home/eliot/oscogvm/platforms/unix/vm/sqUnixMain.c:1769 -- Milan Mimica http://sparklet.sf.net

Jan. 4, 2012

Re: [Pharo-project] Happy new year!

by Norbert Hartl

Am 02.01.2012 um 11:09 schrieb StÃ©phane Ducasse: > >>> Hi guys >>> >>> I wish you good health (because at the end this is the most important and when we are going well we do not >>> estimate how cool it is). >> >> I read: >> >> " Health is like freedom, we understand their importance when we lost it " > > Yes. > My younger sister got a cancer two years ago and if that does not make me think about life then I would be > a real idiot. :) > Don't be too hard to yourself. It is really hard to think about it until you develop some severe illness yourself. Or you decide to become a buddhist. Norbert

Jan. 4, 2012

Re: [Pharo-project] Keyboard navigation and Settings browser

by Gary Chambers

As long as you have a reference to the window at the time... aWindow rememberKeyboardFocus: aMorph Then, upon opening the window, aMorph should have keyboard focus. Regards, Gary ----- Original Message ----- From: "Alain Plantec" <alain.plantec(a)yahoo.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, January 03, 2012 9:23 PM Subject: Re: [Pharo-project] Keyboard navigation and Settings browser > Le 03/01/2012 21:00, Sean P. DeNigris a Ã©crit : >> A few observations inspired by using the Settings browser: >> >> * Is there a way to exclude a submorph from tabbing? In the settings >> browser, if you keep tabbing, you eventually focus on the statusView, >> which >> is a text editor, and you start inserting tabs into the text instead of >> continuing to navigate > in 1.4, the keyboard focus is token by the tree, so that you can directly > navigate with the keyboard inside the tree. > This is explicitely programmed by sending #takeKeyboardFocus to the tree > morph but after the window is opened. > (see SettingBrowser>>open) > It can be easily changed to make the search field take the focus on open > if it is the desired behavior. > but I don't know if there is a way to declare the focus owner before > opening the window. > >> >> * a disabled text editor should pass keyboard focus on tab instead of >> doing nothing (the current behavior) > yes it should >> >> * how do you say which is the default widget? just set the keyboard >> focus >> manually? This would be hard using the Polymorph workflow as in the >> examples/Pharocasts/etc. because: >> - you'd have to store a reference to the morph instance, so you can >> set >> the focus after the window has been opened (will not work otherwise). >> - tools like the Settings browser build the UI in an instance >> method, so >> now a morph would have to be stored in the model - yuck >> Dialog window has #defaultFocusMorph. Maybe this should be added to >> SystemWindow? > I agree >> >> * EditableDropListMorphs should pass keyboard focus to their >> contentMorph. >> Right now it takes two tabs to activate. The first one just highlights >> the >> EditableDropListMorph, but does not let you type into it > yes > > Cheers > Alain >> >> What do you think? >> >> Sean >> >> p.s. this exploration started because I thought it'd be more useful if >> the >> Settings browser opened with the search field active >> >> -- >> View this message in context: >> http://forum.world.st/Keyboard-navigation-and-Settings-browser-tp4258311p42… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

Jan. 4, 2012

[Pharo-project] Suggestion Note:

by S Krish

Should raise this as a separate artifact and probably send out my fixes ( currently these are hacks). Many of the other logics do not work as per standard practices... from other comp usage.. windows/ linux.. * FileOut is silent and saves to the resources folder ... no chance of intervention while it goes out.. also overwrites silently.. Simple save/ saveas popup menu would help .. when reqd. * Image saveAs : only image name is taken.. no folder selection... though one can give a full path in the text editor. * remember the last navigated path in file open/ save dialogs * Monticello save is incremental and quickly builds up a huge stack of files.. need to optimize this.. autosave packages marked to a given default single file overwriting it.. reduce multiple mc saves to the minimum when you really need to version a new base. Oddball issues: * Morph/ dialog window onClick opens another dialog, sends this parent down right back in the stack of windows.. not just push the new dialog as top window. So when this new dialog closes.. you may have to dig out your old morph back if its gone behind code windows.. etc.. On Wed, Jan 4, 2012 at 11:31 AM, S Krish <krishnamachari.sudhakar(a)gmail.com>wrote: > No. > > > On Tue, Jan 3, 2012 at 9:02 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> But the interface should bark instead of forgetting a change silently >> when we open/close a preference (Oups setting) node... >> Does it now ? >> >> Nicolas >> >> 2012/1/3 S Krish <krishnamachari.sudhakar(a)gmail.com>: >> > Thats already there.. >> > >> > it does show the highlighted background and also a tip on the text area >> > below to accept on cr. But as lazy as we are we do not notice hints >> obvious >> > in the face of habits. >> > >> > >> > On Tue, Jan 3, 2012 at 6:27 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> Mariano Martinez Peck wrote: >> >>> >> >>> On Tue, Jan 3, 2012 at 1:11 PM, Alain Plantec >> >>> <alain.plantec(a)yahoo.com>wrote: >> >>> >> >>> >> >>>> >> >>>> Le 03/01/2012 11:57, S Krish a Ã©crit : >> >>>> >> >>>> This works... >> >>>> >> >>>>> >> >>>>> Guess I should have tried that.. >> >>>>> >> >>>>> >> >>>> >> >>>> thanks. >> >>>> but you are not the first one to forget to enter a cr. >> >>>> >> >>>> >> >>> >> >>> >> >>> Yes, I was the first one!!! I remember I have reported the same ;) >> >>> >> >>> >> >> >> >> A small thought - the field background might be made to change colour >> >> during entry until it is accepted by <cr>. >> >> >> > >> >> >

Jan. 4, 2012

Re: [Pharo-project] Monticello trickery: pointers needed

by Frank Shearar

On 25 December 2011 22:18, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Hi, > > The background to the question is that I'm trying to repackage > LanguageBoxes so that both the Squeak and Pharo community can use its > features (or just parts of it). > > Cutie-Helvetia defines a class, CURaisedToExample. Among others, it > defines two methods: CURaisedToExample class >> #raise:to and > CURaisedToExample >> testSplice. > > The latter makes use of QQCompiler's splice operation (just like > Common Lisp's) - @foo will replace 'foo' with whatever 'foo' evaluates > to, so compiling 'a := @(3 + 4)' means the same thing as 'a := 7'. Now > testSplice says > > Â self assert: `@(self raise: 2 to: -3) = (1/8). > > which means that, _at_compile_time_, testSplice will invoke #raise:to: > (the self refers to the class-side method)... and at this point in > time #raise:to: has been compiled, but not installed. Compiling > #testSplice fails with a MessageNotUnderstood, and package loading > aborts. > > My question is this: how can I work around this? Can I move the > installation of #raise:to: to a preload step? > > Some hacks that spring to mind, and don't seem very pleasant, are: > * introduce a new superclass defining the method, put that in a > seperate package, and load that package before Cutie-Helvetia > * move the definition of CURaisedToExample and #raise:to: to a > separate package, and make all the tests extensions to that package. My general question still stands, but I worked around the issue by moving the fixtures - #raise:to: - to a superclass CURaisedToFixtures, and put that superclass in its own package. frank

Jan. 4, 2012

Re: [Pharo-project] TWM Bug - different world menu

by laurent laffont

On Fri, Dec 30, 2011 at 4:01 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > When I access the world menu through the TWM bar, some of the items I have > registered do not show up. Maybe items added after TWM was loaded do not > show up. Anyone else notice this? > Yes I can reproduce it. The problem comes from TWMBar>>newWorldMenu. This is executed when the TWMBar is built and associate current world menu that is not updated when an entry is added. A solution that needs cleanup: TWMBar>>newWorldMenu ^ MenuItemMorph new contents: ''; subMenu: (UpdatingMenuMorph new updater: self updateSelector: #updateWorldMenu:); icon: self openWorldMenuIcon; setBalloonText: 'Open World menu'. TWMBar>>updateWorldMenu: aMenu self windowManager world worldMenu items do: [:aMenuItem| aMenu addMenuItem: aMenuItem]. Laurent > Sean > > -- > View this message in context: > http://forum.world.st/TWM-Bug-different-world-menu-tp4244649p4244649.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 4, 2012