- Pharo-dev - lists.pharo.org

Re: [Pharo-project] glamour and pharo

by Stephan Eggermont

There are a number of separate problems here, I think. Mixing them up makes the situation a bit complex. I'll try separating them here. At what abstraction level should the basic tools be build. From my point of view, Glamour provides the right level. It is very easy to build browsers and it is easy to keep them maintainable. When the underlying stack is going to be replaced it makes sense to have an abstraction layer that is is easy to implement on both the old and the new stack. The alternatives (Morphic, PolyMorph, OmniBrowser, ToolBuilder) are much less accessible. OmniBrowser looks much more comprehensive, but I don't feel qualified to comment on its usability as abstraction layer. I have taken a look at creating a google issue browser with Glamour (before ssl support) and think the committer workflow should be able to be improved with a few specialized Glamour browsers. But my opinion does not matter so much. That decision should be taken by the people maintaining the core of Pharo. Does Glamour provide enough functionality to build a whole tool chain? The focus of Glamour is on navigation in a single window, the language for updating and editing is limited. Drag-and-drop support is missing. Should the programming style of Glamour be the style to build basic tools in Pharo? Would it be better to use something more similar to the Seaside canvas style? The behavior change based on the number of block parameters is very powerful but imho also confusing. On the other hand I'm pretty sure HelpBrowser initWindow is worse than the equivalent Glamour code would be. At the moment the modularization of Pharo is not yet good enough. It is not easy enough to (de)compose images, so the maintainers need to have in the core image code to create user interfaces (web-based :) or direct). When we can create very small images and work with them using remote tools, this need will disappear. Committing to a tool chain build on top of Glamour would mean either back porting Glamour to earlier versions of Squeak/Pharo, so the new tools can replace the old ones everywhere, or breaking old tools and having to maintain them all ourselves. That is, if current maintainers agree with that. Happy new year, Stephan

Jan. 1, 2012

Re: [Pharo-project] seaside and pharo (was: glamour and pharo)

by Alexandre Bergel

Ah ah! Excellent!! Alexandre Le 1 janv. 2012 Ã 11:55, Lukas Renggli <renggli(a)gmail.com> a Ã©crit : >>> So, before dismissing Seaside, perhaps it would be useful to actually >>> look into it. >> >> rofl, made by day >> Can we turn this into a meme? > > Definitely, http://memegenerator.net/instance/12756821. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 1, 2012

Re: [Pharo-project] seaside and pharo (was: glamour and pharo)

by Philippe Marschall

On 01.01.2012 17:07, StÃ©phane Ducasse wrote: > Hi philippe > > I need a dictionary to read your emails :) > What is a meme? An idea virus [1]. You probably know several Internet memes [2] like lolcats or "Yo dawg". [1] http://en.wikipedia.org/wiki/Meme [2] http://en.wikipedia.org/wiki/Internet_meme Cheers Philippe

Jan. 1, 2012

Re: [Pharo-project] Happy new year..

by StÃ©phane Ducasse

You look like you are having fun lukas. You made me laugh and I wish you a good year. This year I decided that I will more zen and not only related to pharo but to life in general. I have the best position I can dream of as researcher, so I will say no to a lot of things and I will have fun and get where I want to go. So this year I want a new compiler in the system, bootstrapping and learning more about vms. So this is simple. Just a question of time. In french we say that "we cannot do an omelet without breaking eggs and this suits me well." I like food, good food and I have a goal. So we will get there. This is what I like about it. No stress. Stef On Jan 1, 2012, at 4:29 PM, Lukas Renggli wrote: >>> . I find Pharo 1.2 more stable than 1.3 latest... >> >> Me too. But it is not the core which is less stable in 1.3, but the dev >> tools. > > Mariano, this is a logic puzzle for you: > http://memegenerator.net/instance/12757355 > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 1, 2012

Re: [Pharo-project] seaside and pharo (was: glamour and pharo)

by StÃ©phane Ducasse

Hi philippe I need a dictionary to read your emails :) What is a meme? Stef > rofl, made by day > Can we turn this into a meme?

Jan. 1, 2012

Re: [Pharo-project] Happy new year..

by Lukas Renggli

>> . I find Pharo 1.2 more stable than 1.3 latest... > > Me too. But it is not the core which is less stable in 1.3, but the dev > tools. Mariano, this is a logic puzzle for you: http://memegenerator.net/instance/12757355 Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 1, 2012

Re: [Pharo-project] Happy new year..

by Mariano Martinez Peck

> > . I find Pharo 1.2 more stable than 1.3 latest... > Me too. But it is not the core which is less stable in 1.3, but the dev tools. > > . Mechanism to autosave a defined package every method commit to a > packagename.mcz by default to ease crash recovery, use monticello only when > I need to version it as a done base. > > This is done. Every thing you change is recored in .changes file. You can open such file with a text editor to recover lost code or you can even open the recover tool to read it and load back what you lost. > . Debugger stepping through has most times an out of step highlighting. > Any fix on this.. > > This was a known problem: http://code.google.com/p/pharo/issues/detail?id=709 Happy new year -- Mariano http://marianopeck.wordpress.com

Jan. 1, 2012

Re: [Pharo-project] seaside and pharo (was: glamour and pharo)

by Lukas Renggli

>> So, before dismissing Seaside, perhaps it would be useful to actually >> look into it. > > rofl, made by day > Can we turn this into a meme? Definitely, http://memegenerator.net/instance/12756821. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 1, 2012

Re: [Pharo-project] seaside and pharo (was: glamour and pharo)

by Philippe Marschall

On 31.12.2011 18:58, Lukas Renggli wrote: > Let's take this on the Pharo mailing list. > > I do think that Seaside should be considered for being part of the > Pharo infrastructure. At least the Core and the basic HTML rendering > (i.e., without JQuery, Magritte and Pier). > > And I also think your analysis is not accurate. Here is why (I > apologize for the long list): > > 1. Seaside is quite well documented. There are two books describing > it. There are a tone of examples documenting all sorts of features. > There comments are not as good as they could be, but there are lots of > comments. > > 2. It is quite well tested. This part can be improved, but the core > has some 80% coverage. > > 3. I am not the only one that knows how to mingle with it. To give > some examples, more than 30 people helped fixing some intricate bugs > directly in the core (http://www.seaside.st/community/contributors) I > would also mention that countless student projects are on > Squeaksource. So, maybe it's not that difficult. > > 4. The core is quite stable since more than 10 years. There were > changes, but they were mostly related to new features and bug fixes. > > 5. The main point of using this infrastructure is not to replace > Morphic, and to empower more people to build more applications. For > example, the Seaside counter has less than 5 lines of code in total > (and one instance variable only). This is really tiny for the amount > of things it offers (you can even step through it with a debugger). > And it is highly extensible (subclassing), too. > > 6. It's actually not that large: the core has 152 classes, and if you > consider all the other packages, helper classes and specialized > frameworks (but without the example code), you get some 1162 classes. > > 7. But, perhaps the most important part is that there have been > literally thousands of applications built on top of it. Not all of > them are useful now, but they were when they were built. And it seems > that people can build one quite fast without much knowledge of the web > either. That is the whole point of this infrastructure. Esteban even > used it for building commercial applications. I built a couple, too. > The whole of Pier (SmallWiki) is now using this infrastructure, too. > > I am not saying that Seaside is perfect. There are quite a couple of > things I would like to enhance (for example, the AJAX ideas from Reef, > or the components from ExtJS), but it has proved to be quite solid > until now. > > So, before dismissing Seaside, perhaps it would be useful to actually > look into it. rofl, made by day Can we turn this into a meme? Cheers Philippe

Jan. 1, 2012

Re: [Pharo-project] Happy new year..

by StÃ©phane Ducasse

Excellent! Stef On Jan 1, 2012, at 10:36 AM, Krishsmalltalk wrote: > > >> What I would like is that you take each of these points and send one mail for each with a detailed description. so that we can answer, turn them into bug entries.. > > > I do intend doing this in a while thru the week ahead. > > > Thx,... For other answers... > > > On Jan 1, 2012, at 1:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >>> Wishing all Pharoer's a very warm n happy new year >>> >>> Since last few weeks, I have been experimenting with Pharo as a tablet interface inside a tiny core Linux. The dev though happens on ubuntu. Some more playing around for a group of trainees with pharo on windows 7, platform I do not very much like. >> Sounds really interesting. >> Tell us more. >> >>> >>> How far is it a nice to have framework that provides for a complete UI, IDE like a tablet interface and behaves akin to android that has it's own AppStore, and application launcher in full screen on icon click. >>> >>> Anyone can download the base, and proceed to download the app source, files archive thru an app installer, that verifies , validates and installs as well as creates a launcher icon ( I will provide the screenshots once I have them fine tuned) >>> >>> Rest of ideas and process are similar to android marketplace or iStore, with definite controls on absolute stability and experience of the apps >>> >>> Some observations i will like the veterans to clue me on forward >>> >>> . I find Pharo 1.2 more stable than 1.3 latest... >> >> - Can you give some specific examples? Because like that this this is useless. >> >>> . Is morphic capable of supporting error free runtime GUI >> >> Yes >> I do not see why it would not. Now if you are changing and adding method with funny behavior then it makes sense that you get >> strange red square. >> >>> I enjoy it's capabilities, but feel it demands more intrinsic Pharo, debugging ability to keep hacking n fixing. Crashes , damaged rectangle painting are just few of the troubles >> >> When I use Pharo and I just code my application without tweaking and cleaning Morph I do not get damaged rectangles. >> I imagine that Polymoprh/pinesoft, DRGeoIIâ¦. people would not deliver production software if this would be the case. >> >>> >>> I expect a simple answer, not necessarily a longer explanation of morphic and it's issues with global coordinates, polling event handling which are nuisances. I have read thru as much of links, docs on morphic as i could find, little working on it, but not enough to get an expert hang of it. >> >> For polling we can now switch to events. After two years the windows VM got the input semaphore fix integrated. >> We will probably do that once we find a problem we saw while rewriting completely the event generation in HandMorph. >> >> >>> . Is system browser the best to study for morphic or should I look through any other package..Debug n learn.. >> NOOOOOOOOOO! >> >>> . Simple way to get an embedded submorph from it's chain by it's name, #subMorphNamed: does help but only in a limited way.. For those that it digs. >> >> Named morph and looking for them is a bad concept. >> Instance variables is the way to go. >> >> >>> . Simpler way to bar extensions from a contributed older package >> every package can add its own menu entry. >> >>> , overriding base class methods, not really the final as in java but at least prevent overwriting methods. A listing post file in of uncompiled methods of this kind. Hacking in FilePackage does help.. But anything better and more complete...and part of a base system. >> >> Sorry I could not get what you mean. >> >> >>> . Mechanism to autosave a defined package every method commit to a packagename.mcz by default to ease crash recovery, use monticello only when I need to version it as a done base. >> This is done. You have a crash recovery >> Any change you do is logged. >> >> >>> . Event handling of mouseLeave mouseEnter of a PluggableTextMorph, the on:send: did not work, not that I have dug into it... But would like to link it to the models methods directly in the builder method interface like we do for PluggableButtonMorph clickâ¦. >> >> You should provide a real example because we do not have a crystal ball. >> >> >>> . Color of a morph is not updated when selecting it thru the halo. Minor hack i have here, to get thru. >>> >>> . Why is extent attribute not updated when we use addMorph:fullFrame: which changes the bounds for the submorphs in some cases at least as i have noticed in debug step thru. >>> >>> . What are clear do not do rules in using morphic framework as it exists today, as people have already experienced and attempted. >> >> I would love to know that too :) >> First basic OO programming. >> >> >>> . Debugger stepping through has most times an out of step highlighting. Any fix on this.. >> >> This is a pending bug and when Athens is out, Igor will really look at this one. >> >> >>> . Settings window seems to have glitches in network settings, font updates from OS... >> Be more precise. >> >> >>> . Autocompletion in windows seems to work on cr, but in Linux you have to type thru. >> Be more precise >> >> >> >>> . The easiest way to have a core Pharo runtime image stripped of all dev tools, classes, size is not the limitation here, but stable n bug free base is a must. >> >> But there is no magic. Just work. And everybody can help. >> >> >>> . Tools n tips to make Pharo base with its loaded apps crash proof, just isolate and close the app that causes the problem rest of the image should continue to run. >> Yes that we want but this is really not simple. >> >> >>> issue not directly related: >>> . Windows support for OSProcess, i have read the threads and the note from Eliot that it works on windows for cadence, but I cannot get it to work, the ProcessWrapper works but is limited. If I do get it working does it support interactive shell, viz i invoke a command that enters into it's own loop of inputs n output till you send a quit. >>> >>> Lots more i will come up with in the next couple of weeks as I bring out what i have. >> >> What I would like is that you take each of these points and send one mail for each with a detailed description. so that we can answer, turn them into bug entries... >> >>> >>> >>> Sudhakar krishnamachari >>> >>> Extn 91-40403012 >>> Cell 9902104814 >>> >>> >>> >> >> >

Jan. 1, 2012