September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

by Sean P. DeNigris

Sean P. DeNigris wrote > MAJOR API CHANGE: > - change matcher #= to #equal: e.g. "1 should = 1" would now be written "1 > should equal: 1" > - update all code to use new API > > Motivation: the #= magic made it impossible to store matchers in > dictionaries, and #hash was implemented to signal an error explaining as > much. Unfortunately, #= and #hash are deeply ingrained Smalltalk concepts, > and are assumed to work as expected. In Pharo 3.0, the debugger tried to > put matchers in a dictionary, causing an infinite error loop whenever a > matcher failed. I bumped the version from 1.2 -> 2.0 per semantic versioning (non-backward-compatible bumps major) and copied the config to MetaRepFor30 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Des… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 25, 2014

Re: [Pharo-dev] Monticello commit hook

by Chris Muller

MCRepository>>#storeVersion:.

Sept. 25, 2014

Re: [Pharo-dev] Monticello commit hook

by Thierry Goubier

Le 25/09/2014 20:54, Eliot Miranda a Ã©crit : > Hi All, > > I was about to respond to Franco;s question by suggesting he start a > commit, to open up the commit dialog, and then use halos to explore the > window, from where he'd find what he was looking for and learn a > strategy he could use for the long-term to explore this wonderfully > reflective and open system we call Smalltalk. But on opening a Pahro > 3.0 image to make sure that halos were available I couldn't find them > So what's a person to do if they want to explore the system from the > UI? It used to be that one could quickly look behind the curtain and > find riches there. Why has this avenue been cut off? Is there an > alternative? Hi Eliot, what you do in Pharo is to get the control UI menu, with Ctrl+Shift+Mouse Right Click. > On Thu, Sep 25, 2014 at 11:14 AM, Franco Musi <fmusi33(a)gmail.com > <mailto:fmusi33@gmail.com>> wrote: > > Hey guys, I'm new here with Pharo and Monticello and I want to > extend the commit's functionality. Can you lead me to which classes > or methods do I have to start looking for making Monticello execute > some code of mine whenever it does a commit? What you are asking depends on what you want to do. Do you want all commits to be trapped, or just some on a certain repository, or just the ones done via a save in the Monticello Browser? The last one would be the easy one, but it isn't the only one. Thierry

Sept. 25, 2014

Re: [Pharo-dev] Monticello commit hook

by Eliot Miranda

Hi All, I was about to respond to Franco;s question by suggesting he start a commit, to open up the commit dialog, and then use halos to explore the window, from where he'd find what he was looking for and learn a strategy he could use for the long-term to explore this wonderfully reflective and open system we call Smalltalk. But on opening a Pahro 3.0 image to make sure that halos were available I couldn't find them So what's a person to do if they want to explore the system from the UI? It used to be that one could quickly look behind the curtain and find riches there. Why has this avenue been cut off? Is there an alternative? On Thu, Sep 25, 2014 at 11:14 AM, Franco Musi <fmusi33(a)gmail.com> wrote: > Hey guys, I'm new here with Pharo and Monticello and I want to extend the > commit's functionality. Can you lead me to which classes or methods do I > have to start looking for making Monticello execute some code of mine > whenever it does a commit? > > Thanks in advance. > -- best, Eliot

Sept. 25, 2014

Monticello commit hook

by Franco Musi

Hey guys, I'm new here with Pharo and Monticello and I want to extend the commit's functionality. Can you lead me to which classes or methods do I have to start looking for making Monticello execute some code of mine whenever it does a commit? Thanks in advance.

Sept. 25, 2014

Re: [Pharo-dev] can not compile pharo-vm on linux

by Nicolai Hess

2014-09-24 9:55 GMT+02:00 Damien Cassou <damien.cassou(a)gmail.com>: > On Wed, Sep 24, 2014 at 1:21 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > How it comes, this one does not have the libgit2 and libssh2 as > dependencies > > entries in the CMakeLists.txt file? > > > the job that creates this file execute a different VM Maker recipe: > > CogNativeBoostPlugin setTargetPlatform: #Linux32PlatformId. > > PharoUnixConfig new > addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); > addInternalPlugins: #( UnixOSProcessPlugin ); > generateSources; > generate. > > > Check the following for the full script: > > https://github.com/pharo-project/pharo-ci/blob/master/ci-jobs/pharo/Pharo-v… > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > Problem solved! Ubuntu 10.04 uses cmake 2.8.0 and for some reason the add_custom_command does not work in that version. I was finally able to build a vm on linux with cmake 2.8.10.2

Sept. 25, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 8cce4c: 40254

by Sean P. DeNigris

GitHub wrote > 14071 OSWindow integration part1 Can we get a short status update? What can be done on which platforms? Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-8cce4c-40254-tp4780221p47802… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 25, 2014

Re: [Pharo-dev] Threaded #anySatisfy:

by Henrik Johansen

On 25 Sep 2014, at 6:23 , Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Henry, > > On Thu, Sep 25, 2014 at 8:25 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Just read an old blogpost of Nicolas Cellier's today that suggested something like this, and thought it sounded interesting. > It's use would be for parallell operations that involve IO delays (the example in the post was MCRepositoryGroup >> #includesVersionNamed:) > An important assumption would be that the blocks are free of side-effects, so evaluation completion/order is not relied upon for further correct operation. > > The goal would be to be able to write the method in question like this: > > includesVersionNamed: aString > " check for existing version name in parallel over all repositories " > > ^self repositories threadedAnySatisfy: [:repository | repository includesVersionNamed: aString ] > > while preserving the important property of anySatisfy: that is returns as soon as an element evaluates true. > > Here's a sample implementation: > > Collection >> #threadedAnySatisfy: aBlock > Cool. But please call it parallelAnySatisfy: or anySatisfyInParallel:. I agree, parallelAnySatisfy: is a better name. (In Norwegian it's written parallell , I guess I was subconsciously trying to prevent a high rate of spelling errors, at the cost of an inferior name ;) ) > Are you sure there are no parallel hazards in the includesVersionNamed code? Good question, I would imagine it might do some caching that could lead to inconsistent state if arbitrarily terminated as in the example implementation, but I haven't checked closely*... Cheers, Henry * I'm don't think it's used, but this might be a candidate: cacheAllFileNamesDuring: aBlock cacheFileNames == true ifTrue: [ ^ aBlock value ]. allFileNames := nil. cacheFileNames := true. <-- If this is a suspension point, if terminated, the file names would be static from the next call to allFileNames until the next time cacheAllFiles... is used --> ^ aBlock ensure: [ allFileNames := nil. cacheFileNames := false] If the need is guarding against arbitrary termination, not just errors in the block itself, I think it would have to be: ^[allFileNames := nil. cacheFileNames := true. aBlock value ] ensure: [allFileNames := nil. cacheFileNames := false] Of the actually called methods from includesVersionNamed:, I stopped checking after stumbling into, and spending too much time wondering why the code did what it did: MCFileBasedRepository >> #readableFileNames | all cached new emptyFilenamelength | "<hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz" emptyFilenamelength := 'P-i.c.mcz' size. all := self allFileNames. "from repository" all := all reject: [ :each | each size < emptyFilenamelength]. "first stupid way to filter first level broken files. Ideally we should remove any files not following the naming pattern: PackageName-author.number[(branch)].mcz" cached := self cachedFileNames. "in memory" new := all difference: cached. ^ (cached asArray, new) select: [:ea | self canReadFileNamed: ea] Removing cached entries from all entries, then iterating on the remaining + cached? That's an aweful lot of nonsense for the clearly essential capability to say you are able to read files that have recently been deleted from the file system...

Sept. 25, 2014

Re: [Pharo-dev] Threaded #anySatisfy:

by Eliot Miranda

Hi Henry, On Thu, Sep 25, 2014 at 8:25 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Just read an old blogpost of Nicolas Cellier's today that suggested > something like this, and thought it sounded interesting. > It's use would be for parallell operations that involve IO delays (the > example in the post was MCRepositoryGroup >> #includesVersionNamed:) > An important assumption would be that the blocks are free of side-effects, > so evaluation completion/order is not relied upon for further correct > operation. > > The goal would be to be able to write the method in question like this: > > includesVersionNamed: aString > " check for existing version name in parallel over all > repositories " > > ^self repositories threadedAnySatisfy: [:repository | repository > includesVersionNamed: aString ] > > while preserving the important property of anySatisfy: that is returns as > soon as an element evaluates true. > > Here's a sample implementation: > > Collection >> #threadedAnySatisfy: aBlock > "Evaluate aBlock with the elements of the receiver. > If aBlock returns true for any element return true. > Otherwise return false." > > | threads results processed | > threads := OrderedCollection new: self size. > results := AtomicSharedQueue new. > processed := 0. > self > do: [ :each | > threads > add: > ([ results nextPut: (aBlock value: > each) ] > newProcess > priority: Processor > activeProcess priority - 1) ]. > threads do: #resume. > [ processed = self size ] > whileFalse: [ > results next > ifTrue: [ > threads do: #terminate. > ^ true ]. > processed := processed + 1 ]. > ^ false > > Test: > > [test := #(2000 1000 ). > test threadedAnySatisfy: [:each | (Delay forMilliseconds: each) wait. > each = 1000]] timeToRun 1000 > test anySatisfy: [:each | (Delay forMilliseconds: each) wait. > each = 1000]] timeToRun 3000 > Cool. But please call it parallelAnySatisfy: or anySatisfyInParallel:. Are you sure there are no parallel hazards in the includesVersionNamed code? If one considers referencing AtomicSharedQueue in a Collection method bad > form, one could also use Arrays + explicit Semaphore, along the lines of: > > threadedAnySatisfy: aBlock > "Evaluate aBlock with the elements of the receiver. > If aBlock returns true for any element return true. > Otherwise return false." > > | threads results processed semaphore| > threads := Array new: self size. > results := Array new: self size withAll: false. > processed := 0. > self > inject: 1 into: [:index :each | > threads > at: index put: > ([ results at: index put: (aBlock > value: each) ] > newProcess > priority: Processor > activeProcess priority - 1). > index + 1 ]. > threads do: #resume. > [ processed = self size ] > whileFalse: [ semaphore wait. > (results anySatisfy: #yourself) > ifTrue: [ > threads do: #terminate. > ^ true ]. > processed := processed + 1 ]. > ^ false > > The cost of that is needing an anySatisfy: per signal received. (on an > array of booleans, so the cost isn't large, but still). > IMHO, the better option would be the version using a shared queue, but > putting it in a non-core package, say, Collections - Parallell. > > Anyone else think it'd be a useful addition? > > Cheers, > Henry > -- best, Eliot

Sept. 25, 2014

new VMs promoted ad stable

by Esteban Lorenzano

Hi, I promoted latest VMs to stable. Not many changes, but at least infamous SmallInteger bug should not be there anymore. cheers, Esteban

Sept. 25, 2014