March 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13085 new version
by StÃ©phane Ducasse March 13, 2011

March 13, 2011

13085 ----- - Remove Object>>undo. - Issue 3312: [Kernel Dependencies] BlockClosure >> #decompile. - Issue 3313: [Kernel Dependencies] UndefinedObject / Compiler. Stef

1 0

[Pharo-project] [update 1.3] #13084 new version!
by StÃ©phane Ducasse March 13, 2011

March 13, 2011

13084 ----- - Issue 3311: [Kernel Dependencies] Object / Compiler. - Issue 3283: Symbol dependent on Scanner. Part 5, 6 and 7. - FinderUI fixes. Sorry for the corruption. Stef

1 0

[Pharo-project] Update process broken by 13084
by Henrik Sperre Johansen March 13, 2011

March 13, 2011

See title. Probably caused by saving from multiple open copies of the same image so the .changes file source was exported from was corrupted :) Cheers, Henry

4 11

[Pharo-project] About Pharo sprint
by Igor Stasenko March 13, 2011

March 13, 2011

It is easy to tell, when it happens.. because my inbox is flooded with tons of messages :) And that's great :) -- Best regards, Igor Stasenko AKA sig.

2 3

[Pharo-project] [ANN] pharo focused sprint - bern, feb 26
by Tudor Girba March 13, 2011

March 13, 2011

Hi, We would like to organize a Pharo Sprint on Saturday, February 26 at SCG, University of Berne, Switzerland (room 107): http://scg.unibe.ch/contact/maps Unlike other sprints, this would not be about fixing things from the tracker, but about building something new and reviewing the situation around one central topic. For this one, the main topic will be Morphic and the IDE. Why? Because it is time to rethink our day-to-day tools and bring them closer to this century (ok, maybe decade :)). It is Ok if you are not a specialist. It is more important to want to participate and learn. The rest will come in time. ***** Please let us know by mail if you plan to attend and what you would wish to work on (see below). Proposed tasks (other tasks are possible in the same area): - Enhancements of Morphic widgets: --- TabGroupMorph with lazy pages, closable tabs, overflow handling and toolbars (a start exists in Glamour) --- High level support for collapsable panes (based on the input of Gary) --- SearchMorph with multiple groups of items (like in Spotlight) --- MorphTreeMorph integrated with GeneralScrollPane to allow for space filling --- BreadcrumbMorph --- Hyperlinks in TextMorphs - Test and enhance the current IDE - Evaluate TextMorphs: NewTextMorph, PluggableTextMorph, SMxPluggableTextMorph etc - Prototype a new ToolSet solution - Enhancements of Glamour and of the Glamorous Toolkit --- Debugger --- Coder --- Multipage Workspace --- CodeBubbles - Develop WeakAnnouncement (start from the implementation of Lukas) - Evaluate the various keybinding implementations - Evaluate ToolBuilder - Evaluate the path to adopt SimpleMorphic A second working topic is getting Monticello faster, but this will only be tackled if there are enough people for the first one. Cheers, Adrian and Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get."

14 29

[Pharo-project] Fwd: Amiga Longplay [133] Skweek
by stephane ducasse March 13, 2011

March 13, 2011

My first game :) Stef Begin forwarded message: > From: Laurent Arditi <laurent.arditi(a)gmail.com> > Date: March 11, 2011 10:00:44 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)free.fr>, Andrzej Fien <fien112(a)hotmail.com>, Pascal Clarysse <pascal.clarysse(a)gmail.com> > Subject: Amiga Longplay [133] Skweek > > Hi all > > Look at this video: one guy plays Skweek and finishes the game in 2 hours. He is an excellent player! > > http://www.youtube.com/watch?v=WIAOSFD6c1g&feature=youtube_gdata_player > > > Laurent.

2 2

Re: [Pharo-project] Issue 3811 in pharo: Extending MessageSend protocol with cull: and value: protocol
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Issue 3811: Extending MessageSend protocol with cull: and value: protocol http://code.google.com/p/pharo/issues/detail?id=3811 This issue is now blocking issue 3814. See http://code.google.com/p/pharo/issues/detail?id=3814 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

[Pharo-project] Fwd: [squeak-dev] sustainable Monticello
by Janko MivÅ¡ek March 12, 2011

March 12, 2011

-------- Original Message -------- Subject: [squeak-dev] sustainable Monticello Date: Tue, 8 Mar 2011 15:33:19 -0600 From: Chris Muller <asqueaker(a)gmail.com> Reply-To: ma.chris.m(a)gmail.com, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> To: squeak dev <squeak-dev(a)lists.squeakfoundation.org> This will probably be a long post, but I would like to tell you about the Monticello upgrades I'm about to move to the trunk. Monticello has several repository types: MCRepository #('creationTemplate' 'storeDiffs') MCDictionaryRepository #('description' 'dict') MCFileBasedRepository #('cache' 'allFileNames') MCDirectoryRepository #('directory') MCCacheRepository #('packageCaches' 'seenFiles') MCSubDirectoryRepository #() MCFtpRepository #('host' 'directory' 'user' 'password' 'connection') MCHttpRepository #('location' 'user' 'password' 'readerCache') MCSMCacheRepository #('smCache') MCGOODSRepository #('hostname' 'port' 'connection') MCWriteOnlyRepository #() MCSMReleaseRepository #('packageName' 'user' 'password') MCSmtpRepository #('email') but MCFileBasedRepository is the one that has been given all of the focus, the other repository types have been ignored over the years. MCHttpRepository is the one that interfaces with SqueakSource, and MCDirectoryRepository are pretty much the only types being used. I know this because external users of MCRepository API, like the Repository-browser tools and MC-Configurations and Installer; these are all using API's that are specific to MCFileBasedRepository - not generally understood by the other repository-types or the abstract API in MCRepository. This is worthy of concern because of the access-limitations of a MCFileBasedRepository. Unlike a MCGOODSRepository, for example, a file-system-based repository cannot efficiently meet the demands of being a MCRepository without, at some points, needing to enumerating ALL version names (files) in its file-system location. As the number of versions in a repository reaches 1-million and beyond, performance will grind to a halt due to the number of files that must be constantly downloaded into RAM (another area of unscalability and unsustainability related to FileBased Repository's). A purging of old versions could be done, but a philosophy of Monticello, from the outset, has been that repository's are intended to contain "all" of version history. I have therefore reworked the MCRepository API's and external tools to talk using only an API that is understood by any repository that implements the methods identified as #subclassResponsibility in MCRepository. This minimally-required API is now: #allPackageNames - answer a list of package names in this repository. #basicStoreVersion: - add a Version to this repository. #includesVersionNamed: - does a version with this name exist in this repository? #versionNamed: - answer the first Version object with the given name. #versionNamesForPackageNamed: - answer the version names for the given package name. #versionWithInfo:ifAbsent: - answer the Version object with the given unique VersionInfo In deference to the limitations of FileBasedRepository's, we only ask for the _names_ of things rather than the whole object, because the names are all that is needed to satisfy tool requirements, except in cases where we need a single Version object (like loading). FileBased cannot access the Version objects quickly, just the (file)names (incl. author & version-number). During the process of this refactoring, I was able to signficantly improve the coherence of the code. It was really, really bad in some areas. I've also verified the viability of this API by updating MCMagmaRepository, and demonstrating using Magma as a totally-sustainable and scalable MC repository. Employing a Magma-based Repository also affords some additional benefits, which I will describe in a separate follow-up mail. I think SqueakSource will eventually have to change to something more scalable. At least now we have have a viable alternative, and with much cleaner MC code in the process. Please load my latest versions of Monticello, MonticelloConfigurations, Installer and Tests from the Inbox and let me know if you experience any issues. You should not see any difference in day-to-day operations. - Chris

4 4

[Pharo-project] can we add #cleanUpForRelease to hudson?
by Mariano Martinez Peck March 12, 2011

March 12, 2011

Marcus, can we add a "ScriptLoader new cleanUpForRelease" at the end of the Pharo.st that is used to build the PharoDev 1.2? Thanks mariano

2 3

[Pharo-project] Pharo 1.2 builds green :)
by Esteban Lorenzano March 12, 2011

March 12, 2011

Hi, ...well, they are blue, not green, but I can't get used to it :) So... is time to release it, finally? btw, before release it, can't we change default RealEstateAgent usedStrategy to #straggerFor:initialExtent:world:, so windows get a "normal" size? Current one is too small in my screen :( Cheers, Esteban

2 1