- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [COTDC] 27 - DropEvent

by Fernando Olivero

I model the event produced when a hand drops a (grabbed) morph into another morph. I know the position of the drop, the dropped morph and the hand that produced me. See HandMorph>>dropMorph:event: for an example of usage. On Wed, Mar 9, 2011 at 8:07 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Please .... > Laurent > On Tue, Mar 8, 2011 at 7:27 PM, laurent laffont <laurent.laffont(a)gmail.com> > wrote: >> >> Anyone ? >> Laurent >> >> On Mon, Mar 7, 2011 at 6:38 PM, laurent laffont >> <laurent.laffont(a)gmail.com> wrote: >>> >>> Today: Â DropEvent >>> >>> Comment Of The Day Contest - One Day One Comment >>> Rules: >>> #1: Each day a not commented class is elected. Each day the best comment >>> will be integrated with name of the author(s). >>> #2: If you cannot comment it, deprecate it. >>> Results:Â http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >>> Laurent > >

March 9, 2011

Re: [Pharo-project] [COTDC] 27 - DropEvent

by laurent laffont

Please .... Laurent On Tue, Mar 8, 2011 at 7:27 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Anyone ? > > Laurent > > > On Mon, Mar 7, 2011 at 6:38 PM, laurent laffont <laurent.laffont(a)gmail.com > > wrote: > >> Today: DropEvent >> >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> > >

March 9, 2011

[Pharo-project] Issue 3794 in pharo: FinderUI gets out of sync when more than one Finder open

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3794 by DougEdmu...(a)gmail.com: FinderUI gets out of sync when more than one Finder open http://code.google.com/p/pharo/issues/detail?id=3794 Finder v.34 If a Finder window is open, it adds new typed-in entries to the top of the drop-down list. If a second Finder window is opened, the new entries are added to the top of the list. If you go back to the first Finder window, it will still show the entries as used by the first Finder window, but the index is now out of sync. If you select from the drop-down list from the first Finder window, Finder will look for the wrong item (presumably whatever is indexed at that position in the list). I think the problem has to do with using a class variable (SearchedTextList) for the drop down list.

March 9, 2011

Re: [Pharo-project] InterpreterSimulator reloaded

by David T. Lewis

Pavel, Thank you! I am CC'ing the vm-dev list with a copy of your change set to update the interpreter simulator. Dave On Tue, Mar 08, 2011 at 11:25:21PM +0100, Pavel Krivanek wrote: > I collected the changes from the image. See the attachment. > > To load the simulator in Pharo 1.3 do: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfVMMaker'; > load. > > (ConfigurationOfVMMaker project version: '1.5') load. > > proceed all deprecation warnings... > load the attached fix. > run the simulator: > > (InterpreterSimulator new openOn: 'cuis.image') test > > A good option is the Juan's small Cuis image (1.9MB with some next > shrinking). The classical mini.image doesn't work on this version of > the interpreter. > > Cheers, > -- Pavel > > > > On Tue, Mar 8, 2011 at 10:47 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > > > I tried to make the IneterpreterSimulator working on and with latest > > images. The result is a Pharo image that you can download here: > > > > https://gforge.inria.fr/frs/shownotes.php?release_id=5897 > > > > It is still far from perfect however it can be used for simulations of > > small headless images etc. It would be great if some VM guy will help > > with integration of the changes. > > > > Cheers, > > -- Pavel > >

March 9, 2011

Re: [Pharo-project] [ANN] Cocoa Squeak VM 5.7.4.1 (non-Cog) released

by Tudor Girba

Small steps are way better than no steps :). Thanks for your steady work. Doru On 8 Mar 2011, at 19:33, Esteban Lorenzano wrote: > Hi, > I'm releasing a version for Cocoa Squeak VM, version 5.7.4.1 > This is just a small bugfix version to make OSProcess plugin works. > > You can download it from here: Squeak 5.7.4.1 > (This version includes the OSProcess plugin as an external plugin) > > yes... small steps, I'm sorry for that. > > Cheers, > Esteban -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

March 8, 2011

Re: [Pharo-project] InterpreterSimulator reloaded

by Pavel Krivanek

I collected the changes from the image. See the attachment. To load the simulator in Pharo 1.3 do: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfVMMaker'; load. (ConfigurationOfVMMaker project version: '1.5') load. proceed all deprecation warnings... load the attached fix. run the simulator: (InterpreterSimulator new openOn: 'cuis.image') test A good option is the Juan's small Cuis image (1.9MB with some next shrinking). The classical mini.image doesn't work on this version of the interpreter. Cheers, -- Pavel On Tue, Mar 8, 2011 at 10:47 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I tried to make the IneterpreterSimulator working on and with latest > images. The result is a Pharo image that you can download here: > > https://gforge.inria.fr/frs/shownotes.php?release_id=5897 > > It is still far from perfect however it can be used for simulations of > small headless images etc. It would be great if some VM guy will help > with integration of the changes. > > Cheers, > -- Pavel >

March 8, 2011

Re: [Pharo-project] Issue 1064 in pharo: There are still problem with keyboard shortcuts in Windows

by pharo＠googlecode.com

Comment #15 on issue 1064 by happy.lo...(a)gmail.com: There are still problem with keyboard shortcuts in Windows http://code.google.com/p/pharo/issues/detail?id=1064 The workaround on Comment 11 is for only Windows. I do not know well how the workaround works on other platforms. Probably some shortcuts may not work.

March 8, 2011

[Pharo-project] PharoOneClick .lnk file

by Torsten Bergmann

>.. and this should probably be Pharo.exe with a nice Pharo icon :) I already created a custom Pharo VM (a standard one and a Cog VM, both with Pharo icon and resource section) and gave this to Marcus. I guess he just has to find the time to include it in the One click. As a windows user when I extract a ZIP I typically would expect the launcher exe at the root level and not in /Contents/Windows. Download Eclipse and you know what I mean. I understand that this folder structure was choosen due to the multiplatform nature of the one click. The .bat file solution would make us look really old style ;) However - when Pharo 1.2 is ready I try to find the time to build a setup again (as I already provided on the download page for previous Pharo versions) I expect a windows user to be more satisfied with a typicall installer that also set up program group, ... and allows also to uninstall. And this installer download is also smaller than the OneClick since Linux/Mac VMs are not necessary. Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

March 8, 2011

[Pharo-project] InterpreterSimulator reloaded

by Pavel Krivanek

Hi, I tried to make the IneterpreterSimulator working on and with latest images. The result is a Pharo image that you can download here: https://gforge.inria.fr/frs/shownotes.php?release_id=5897 It is still far from perfect however it can be used for simulations of small headless images etc. It would be great if some VM guy will help with integration of the changes. Cheers, -- Pavel

March 8, 2011

[Pharo-project] Fwd: [squeak-dev] sustainable Monticello

by Janko MivÅ¡ek

-------- 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

March 8, 2011