- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Serge Stinckwich

On Mon, Apr 4, 2011 at 4:16 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 03 Apr 2011, at 09:35, Marcus Denker wrote: > >> Â Â Â https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip >> >> >> Â Â Â Marcus > > Marcus et al, > > I have to agree with Laurent: you and the rest of Pharo are being way too modest here. Like most users I have been waiting for 1.2.x to be announced with a big splash. I know and understand how it has been a long and boring process at the end. > > Like you said, a release is just a release: a group of developers deciding that the current state of the system is 'good enough'. I have been using a #12333 hudson/jenkins built Seaside 3.0.3 image for more than a month for development and server deployment and it has been a very nice experience (in other words, it worked perfectly). > > So, from my part: thank you for all the efforts, the results are fantastic! > > So please, organize some kind of splash! +1 Yes i agree, we need to release Pharo 1.2. This is not perfect but this is usuable without too much problems. The next release will be better ;-) A big applause for the Pharo core team !!! -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 4, 2011

Re: [Pharo-project] Pharo sprint at Brussels Friday 15th of April

by Sven Van Caekenberghe

On 04 Apr 2011, at 11:41, Johan Brichau wrote: > Place: Software Languages Lab, 10th floor of building F, Vrije Universiteit Brussel, Belgium And the timeframe ?

April 4, 2011

Re: [Pharo-project] Pharo sprint at Brussels Friday 15th of April

by Johan Brichau

Hi guys, Time flies... I had forgotten all about it ;-) So here is the info: Place: Software Languages Lab, 10th floor of building F, Vrije Universiteit Brussel, Belgium Directions: http://www.vub.ac.be/english/infoabout/campuses/index.html#etterbeek Map: http://www.vub.ac.be/english/infoabout/campuses/etterbeek.html In case you have trouble finding it, please phone Andy: +32 494 42 32 56 or Johan: +32 476 78 64 45 If you are coming by car, you will need a barcode to access the campus. I will send that in a following email. cheers Johan On 04 Apr 2011, at 09:21, Sven Van Caekenberghe wrote: > > On 02 Apr 2011, at 09:31, StÃ©phane Ducasse wrote: > >> Johan Brichau and Andy Kellens are organizing a sprint at VUB. >> Please let us know who will join. >> I will join > > That's an offer I can't refuse: so yes, I'll be joining too. > > What are the details, timeframe & place ?

April 4, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by Stuart Herring

On Mon, Apr 4, 2011 at 3:56 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Rather than abandon core vs full, here's a thought on a slightly different approach... > > Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ... > > Use the build server to run tests against the CORE and the set of CORE tools... > This is what makes the most sense to me as a user - and one that uses both core and dev. Dev is what I spend 99% of my time in, and of course core is what I actually deploy my applications on. But pretty much all of my impression of Pharo comes from Dev. The worry I would have about having only core releases, or core + untested Dev script would be that given the "clean design over backward compatibility" philosophy, none of the development tools would ever keep up with the changes in Core. You'd effectively have a product that was unusable to a developer (or at least, not a fair representation of how good Smalltalk can be for development). It basically comes down to this: Either you want to provide developer tools with Pharo or you do not. If you do not, then ditch Dev entirely, and make it very clear that Pharo is just a platform, and the third party developers of development tools will need to support Pharo specifically. If you do, then the Development tools need to be first class citizens. You need to develop in Dev - which is built from Core. And Dev needs to benefit from the same sorts of refactorings and cleanings as Core does, and tests in Dev must always be green (blue). Given that the webpage currently states that providing excellent development tools is a primary goal of Pharo, I feel that Dale's approach is what makes the most sense. Regards, Stuart

April 4, 2011

Re: [Pharo-project] SMx ToDo

by Fernando Olivero

I've started from the latest implementation of SMx, from the latest CUIS image. Juan did many differences, specially in the layout. For the ToDo list, i went thru the system categories of Morphic, detecting changed classes and additions. For the importing i'm also looking at the SMx in the latest Pharo Core image. People in the Squeak community, started a similar project. They chose to import the editor hierarchy as well, i prefer to go merge Pharo and CUIS, to detect the needed behavior of current Text-based morphs, and the new ones. I will start the (initial) port today, and hope to get it done before a couple of days. Maybe, when you have time we could discuss how to plug the EditorState behavior into the (new) PluggableTextMorph. Fernando On Fri, Apr 1, 2011 at 11:50 PM, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > Hi Farnando, > > maybe I've missed something, do you want to merge > cuis morphic with Morphic of with SMxMorphic ? > another question, SMxMorphic is really out-to-date regarding current cuis ? > Alain > > Le 01/04/2011 16:04, Fernando Olivero a Ã©crit : >> >> Alain, this is the notes i gathered so far. >> >> I list the Cuis morphs i believe we should integrate, and those which >> we shouldn't. >> >> "Kernel" >> LayoutMorph. >> LayoutSpec. >> Morph. >> BorderedMorph. >> PluggableMorph. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "Common: merge?" >> MouseClickState. "check". >> MorphExtension. >> GrafPort. >> FormCanvas. >> DamageRecorder. >> EllipseMidpointTracer "for the GrafPort, check in Pharo?". >> HandMorph. >> PasteUpMorph. >> WorldState. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "basic Morphs" >> ImageMorph. >> RectangleMorph. >> PolygonMorph. >> StringMorph. >> TransformMorph. >> EllipseMorph. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "basic widgets-cuis" >> PluggableButtonMorph. >> PluggableMessageCategoryListMorph. >> BareTextMorph. >> TextModelMorph. >> >> "basic widgets-common" >> PluggableListMorph. >> LazyListMorph. >> PluggableListMorphByItem. >> PluggableListMorphOfMany. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "extra widgets" >> SketchMorph. >> FillInTheBlankMorph. >> >> "CUIS-extra-widgets" >> OneLineEditorMorph. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "Menus" >> MenuItemMorph. >> MenuLineMorph. >> MenuMorph. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "windows-common" >> ScrollPane. >> ScrollBar. >> ScrollbarButton. >> SystemWindow. >> >> "windows-new" >> BrowserCommentTextMorph. >> LayoutAdjustingMorph. >> WindowEdgeAdjustingMorph. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "other widgets" >> ColorPickerMorph. >> ProgressMorph. >> ProgressBarMorph. >> TranscriptMorph. >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "MorphicEvents" >> "the same?" >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "ENHANCEMENTS" >> "EditorState: Alains work that uses UndoManager, to provide unlimited >> undos, and visual feedback or search and replace in the proper Text >> presentation morphs" >> "Add the icon management to THEME" >> "Evaluate the polymorph features that are missing from (Cuis) Theme". >> "more ?" >> >> "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" >> "ommitted or removed" >> HaloMorph. " and family, no halos for now" >> BalloonMorph. "remove or replaced by a tooltip morph?, do we need a >> special morph?" >> MenuIcons. "moved to the themes in Pharo, themes own the icons to use" >> UpdatingMenuItemMorph. "?" >> TheWorldMenu. "pragma menu building on the WorldState in Pharo" >> MinimalStringMorph. "no usage for now, omit until a real usage appears" >> CurveMorph. "redundant maybe" >> MVCMenuMorph. "removed MVC-morphic integration" >> LimitedHeightTextMorph. "not used, only in examples, omit until a real >> usage appears". >> "LineMorph". "redundant: doesnt add behavior: remove?: replace by >> PolygonMorph lineFrom:to: color: width:" >> >> > > >

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Sven Van Caekenberghe

On 03 Apr 2011, at 09:35, Marcus Denker wrote: > https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip > > > Marcus Marcus et al, I have to agree with Laurent: you and the rest of Pharo are being way too modest here. Like most users I have been waiting for 1.2.x to be announced with a big splash. I know and understand how it has been a long and boring process at the end. Like you said, a release is just a release: a group of developers deciding that the current state of the system is 'good enough'. I have been using a #12333 hudson/jenkins built Seaside 3.0.3 image for more than a month for development and server deployment and it has been a very nice experience (in other words, it worked perfectly). So, from my part: thank you for all the efforts, the results are fantastic! So please, organize some kind of splash! Regards, Sven

April 4, 2011

Re: [Pharo-project] Issue 3948 in pharo: Transcript and ThreadedTranscript needs to be merged

by pharo＠googlecode.com

Comment #1 on issue 3948 by fernando...(a)gmail.com: Transcript and ThreadedTranscript needs to be merged http://code.google.com/p/pharo/issues/detail?id=3948 Transcript is designed to be thread safe. Regarding the merge, i've replaced every use of ThreadedTranscript with (new) Transcript. Maybe i've omitted something?

April 4, 2011

Re: [Pharo-project] [ANN] For testing: 1.2.1 One-Click

by Geert Claes

Marcus Denker-4 wrote: > > And a Cog version: > > > https://gforge.inria.fr/frs/download.php/28439/Pharo-1.2.1-CogOneClick.zip > It would be great if this Windows VM would also have a nice Pharo name/icon -- View this message in context: http://forum.world.st/ANN-For-testing-1-2-1-One-Click-tp3423709p3424962.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 4, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by Tudor Girba

Hi, I fully agree with Marcus. Cheers, Doru On 4 Apr 2011, at 09:18, Igor Stasenko wrote: > On 3 April 2011 19:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. >> >> 1) We don't develop the system using the tools that we tell people to use. >> -> bugs don't get fixed >> -> there is no pressure on improving the tools >> -> we can't use the advanced tools while developing the Core. >> >> 2) We integrate *far* too late. >> -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested. >> >> 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. >> -> People even expect to be able to shrink it more, which in turn we do not test. >> >> 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... >> getting them fixed for the release if they are not touched for a year is nearly impossible. >> >> 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. >> e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. >> >> 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. >> >> The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly >> not working. >> >> So I vote for abandoning Core vs. Dev for 1.3. >> > > Marcus, i think that full or 'dev' images just need to have a > configurations which people could load on top of core image. > The responsibility of core team is to define what is included in those > configurations on next release and > making sure that they can be loaded in latest core images. > > But don't mix 'can be loaded' with 'works without bugs' :) This is > another story. This is where community has to be involved and people > who interested in > using full image(s) need to help with it. > Otherwise, if nobody using it, then why wasting an effort with > maintaining and fixing such a large codebase? > > I know it by myself, that bugs are discovered and fixed only when you > using some tool(s). But if something lies there unattended, then it > will definitely > break at some point, and it is not really matters how hard you try to > keep backwards compatibility or making sure all tests are green. > >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Every thing should have the right to be different."

April 4, 2011

[Pharo-project] Issue 3950 in pharo: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation)

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3950 by sven.van...(a)gmail.com: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation) http://code.google.com/p/pharo/issues/detail?id=3950 Pharo 1.2 #12333 There is something wrong with how some of the exceptionBlocks of SequenceableCollection>>#findBinary and friends work. Some of them expect no arguments (as most #ifNone: exception blocks do), while others expect 2 arguments here (a low & a high bounds). Delegation among them is also strange as there seem to be two implementations. Some refactoring could be done. Unit tests are also missing. Some users are also vulnerable. As an example, try these: #(1 3 5 7 11 15 23) findBinary: [ :arg | 11 - arg ] #(1 3 5 7 11 15 23) findBinary: [ :arg | 8 - arg ] #(1 3 5 7 11 15 23) findBinary: [ :arg | 11 - arg ] ifNone: [ nil ] #(1 3 5 7 11 15 23) findBinary: [ :arg | 8 - arg ] ifNone: [ nil ] I could propose a fix, but I don't understand the reason behind the strange exception block: how could passing the low/high bounds be useful here ? Sven

April 4, 2011