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

[Pharo-project] Phexample official repository?

by Frank Shearar

Hi, http://smalltalkhub.com/#!/~Phexample/Phexample says that the official repository is on www.squeaksource.com, but contains more recent commits than the SS one. And there's also http://smalltalkhub.com/#!/~PharoExtras/Phexample. The PharoExtras repo _looks_ like it's _sort've_ a copy of the Phexample/Phexample one. What's the real story here? Where do I submit features/fixes? frank

March 12, 2013

[Pharo-project] working moose build

by Tudor Girba

Hi, The Moose build including running tests now works based on the NBCog VM and the latest Pharo 2.0 (built on Ubuntu): https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR… There are 27 test failures. I also tried on OS X using NBCog VM and the there is no crash. This scenario was also confirmed by Stephan although he reported more failures. For reference, we are using the following script on Jenkins: wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20NBCogVM.sh | bash wget http://pharo.gforge.inria.fr/ci/image/PharoV20.sources ./vm.sh Pharo.image save $JOB_NAME REPO=http://smalltalkhub.com/mc/Moose/Moose/main ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./vm.sh $JOB_NAME.image moosetest --junit-xml-output zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

March 12, 2013

Re: [Pharo-project] Getting SoundRecorder to work: how?

by stephane ducasse

I tried too on 2.0 and RecordingControlsMorph new openInWorld (show will not work because it was relying on a soundNamed: 'croak' - do not ask me if this is a good idea or design to define class that cannot initialize themselves) Now it looks like the buffers are not filled up. I should try in 1.4 but now I'm going to sleep. too tired. Stef

March 12, 2013

Re: [Pharo-project] Help with MenuMorph

by stephane ducasse

In fact I did not add an instance method because we always have to invoke the menu invokeAt: ActiveHand position in: ActiveWorld allowKeyboard: true. So in that case I prefer to use chooseFrom: But indeed this is a good experience and probably we should rebuild menu and menuItem one of these days. I think that cleaning again a bit more is needed. I added some entries in fogbugz for that. Stef On Mar 12, 2013, at 4:23 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Jannik > > I'm studying right now chooseâ¦ > So I think that I will add a method add: value: to the instance side to see how it look like. > > Stef > > > chooseFrom: aList lines: linesArray title: queryString > "Choose an item from the given list. Answer the index of the selected item." > "MenuMorph > chooseFrom: #('Hello' 'Pharoers' 'Here' 'We' 'Go') > lines: #(2 4) > title: 'What''s up?'" > > | menu result | > (ProvideAnswerNotification signal: queryString) ifNotNil:[:answer | > 1 to: aList size do:[:i| (aList at: i) = answer ifTrue:[^i]]. > ^0]. > result := 0. > menu := self new. > menu addTitle: queryString. > 1 to: aList size do:[:i| > menu add: (aList at: i) asString target: [:v| result := v] selector: #value: argument: i. > (linesArray includes: i) ifTrue: [menu addLine]]. > > menu invokeAt: ActiveHand position in: ActiveWorld allowKeyboard: true. > ^result

March 12, 2013

Re: [Pharo-project] WhatsUp from: 2013-03-11 until: 2013-03-24

by StÃ©phane Ducasse

On Mar 12, 2013, at 9:04 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > First of all, I think this is a very cool initiative. thanks I really hope that it will improve our sharing and community building :) Stef > >> ### Here's what I've been up to since the last WhatsUp: > > - Working on getting Moose to work on Pharo 2.0 > - Extended (and documented) the CommandLineHandler to run multiple tests based on context specific requirements > - Attracted sponsors for PharoConf + MooseDay to make the event free to attend > - Annoyed people with requests for giving talks and tutorial at PharoConf + MooseDay > - Brainstormed and reviewed with Andrei around a very cool (really :)) and modular debugger model > >> ### What's next, until 2013-03-24 (*): >> >> - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION >> >> (*) we'll be expecting results by then ;) > > - Find a solution for running Moose on a Pharo 2.0-compatible VM > - Organize the PharoConf + MooseDay > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Things happen when they happen, > not when you talk about them happening." > >

March 12, 2013

Re: [Pharo-project] access to pharoextras repository

by StÃ©phane Ducasse

I added a section with this discussion to the Metacello chapter :) Stef On Mar 10, 2013, at 1:33 AM, Ben Coman <btc(a)openInWorld.com> wrote: > stephane ducasse wrote: >>> That is why, either we explicitly put the 'Tests' group in the 'default' group, >>> >> >> - I would go for this behavior because I do not like implicit behavior when this is about configuration >> and I will start to write comments in all the configurations >> "default is used when nothing is specified by default it will load everything but better specify what everything is" >> >> >> So once we agree I will start editing configurations like a mad. >> >> Stef >> >> > In you book chapter about Configurations you might hint "why" it is preferred to include Tests in default. For me... > * people fresh to the package get some examples. > * encourages new tests to be added. Having to find & load a 'Tests' group at a later time would be an impediment to this. > > You might also consider a convention for an 'Examples' group. > > >

March 12, 2013

Re: [Pharo-project] access to pharoextras repository

by StÃ©phane Ducasse

Hi doru I addressed your point in XMLParser XMLWriter OPAX Pastell Soup and I will pay attention that default always load the tests too. Stef

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Eliot Miranda

On Tue, Mar 12, 2013 at 12:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On Mar 12, 2013, at 7:44 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> We use an automated building method that tries to be exactly the same in >> each platform. We decided not to create bundles but dylibs because bundles >> are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >> Our process builds the vm, the plugins and the third party libraries as >> an all-in-one. Eliot builds are hand made, and when there is a process >> (like the autotool for unix builds), they are platform-specific. >> > > That mine are hand-builkt is a straw man. They're not. I kick off the > builds by hand but everything is scripted and reproducible, and included in > the generated source. I don't (yet) have access to Jenkins for all three > platforms. But the VMs at Cadence are now all built via Jenkins (thanks to > Bob Westergaard). What's different is a fork. > > > my bad... I thought it was hand made, I'm sorry. Good to know that it > isn't. > > > 1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the > plugin needed to develop the VM (the x86 simulator BochsIA32Plugin). Pharo > uses the set of plugins it has chosen (several of the same plugins are > internal to the Cog VM, e.g. UUIDPlugin is internal in Cog). > > > yes, as I said there is minimal difference between internal and > external... just a a matter of taste if you want :) > > > 2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so > automake is used (one in a blue moon) on linux, and hand-crafted makefiles > on Mac and Windows (that don't change much). The Pharo way is better > (although I find CMake as incomprehensible and arbitrary as automake), but > both Cog and Pharo have predictable C make systems. > > > yes, I agree that cmake is as incomprehensible as autoconf... a terrible > pain when you need to touch them directly... thatÂ´s why we try to use the > CMakeMaker package, who helps (but not completely) to make the task less > painful. > > > 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and > c) new FileSystem primitives. > a) is cool, but I don't like the x86 specificity. I want a cross-platform > FFI, so I'm not excited enough to include NB in my port. > b) is useful (I fixed the implementation of ephemerons for VisualWorks > done by someone else a while back, and I understand them well), but I don't > like Igor's implementation. IMO the ephemeronness of an object needs to be > reflected in its format field (the 4 bit type field in every object), not > found by indirecting through the class, which is hairy in the current GC > and slow. I've proposed an alternative and Igor is I think in agreement, > but we have to find the time to implement it. > c) I have to find time to port. Its a no-brainer. > > > I do not consider pharo a fork. I think is wrong to think on it like a > separated development. We put some effort on top of your own effort to > match other requirements (like NB, branding, allow some experiments, etc.), > but in essence is the same cog... we just change the cover :) > Most of the changes are now based on: NB, the Cocoa branch and some > plugins not yet integrated... I hardly would consider that a fork (and we > try not to fork in purpose: is dumb to divide the work of the few ppl who > work on the vm level in our community). > Yes, I agree. I didn't choose my words carefully enough. It is a version of Cog, just as the one I build is the Croquet version (soon to be a Squeak version). But it would be nice if there was more agreement on the format of Smalltalk getSystemAttribute: 1009. This is a useful attribute and nice if it were parsed by the Pharo image code. Pharo however has a different vision than other communities in some points, > specifically about the plugins and its place: the plugins should be moved > to inside the image as much as they can (that's why NB is so important for > us). The idea is to allow the community to participate in maintaining the > plugins and keep the vm programmers focused on... well, vm stuff :) > > Esteban > > > >> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >> >> Esteban >> >> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> >> wrote: >> >> > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >> > >> > And worth some explanations :-) Why is it that way? >> > >> > Phil >> > >> > 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >> >>> It would be good to have a parallel job, but the problem is that you >> will >> >>> get a message saying that the VM is too old for the Pharo 2.0 image. >> >> >> >> I started the latest MOOSE image on Eliots latest VM on mac. >> >> It still has the 'old vm' warning. >> >> Adding a monticello repository (directory) doesn't work. >> >> Tests are still running >> >> >> >> Stephan >> >> >> >> >> > <2013-03-12_10-43-37.png> >> >> >> > > > -- > best, > Eliot > > > -- best, Eliot

March 12, 2013

Re: [Pharo-project] Help with MenuMorph

by jannik.laval

Ok, I like the way you use it. Now, I hope to have in future a better menu tool. Jannik On Mar 12, 2013, at 4:23 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Jannik > > I'm studying right now chooseâ¦ > So I think that I will add a method add: value: to the instance side to see how it look like. > > Stef > > > chooseFrom: aList lines: linesArray title: queryString > "Choose an item from the given list. Answer the index of the selected item." > "MenuMorph > chooseFrom: #('Hello' 'Pharoers' 'Here' 'We' 'Go') > lines: #(2 4) > title: 'What''s up?'" > > | menu result | > (ProvideAnswerNotification signal: queryString) ifNotNil:[:answer | > 1 to: aList size do:[:i| (aList at: i) = answer ifTrue:[^i]]. > ^0]. > result := 0. > menu := self new. > menu addTitle: queryString. > 1 to: aList size do:[:i| > menu add: (aList at: i) asString target: [:v| result := v] selector: #value: argument: i. > (linesArray includes: i) ifTrue: [menu addLine]]. > > menu invokeAt: ActiveHand position in: ActiveWorld allowKeyboard: true. > ^result

March 12, 2013

Re: [Pharo-project] Getting SoundRecorder to work: how?

by jannik.laval

After four tries, I can load it. The source provided by phil does not work with PharoSound. Jannik On Mar 12, 2013, at 9:23 PM, "jannik.laval" <jannik.laval(a)gmail.com> wrote: > I can not load it: VM crashes. > With this code: > > Gofer it > url: 'http://smalltalkhub.com/mc/PharoExtras/Sound/main'; > package: 'ConfigurationOfPharoSound'; > load. > (Smalltalk at: #ConfigurationOfPharoSound) project lastVersion load. > > Jannik > > On Mar 12, 2013, at 9:17 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> PharoExtras/Sound >> >> on SmalltalkHub >> >> >> On Mar 12, 2013, at 8:33 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> No, link please? >>> >>> 2013/3/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> did you try with the new Sound configuration I just published on SmalltalkHub? >>>> >>>> On Mar 12, 2013, at 5:11 PM, phil(a)highoctane.be wrote: >>>> >>>>> sr := SoundRecorder new. >>>>> sr startRecording. >>>>> sr stopRecording. >>>>> sr playback. >>>>> >>>>> doesn't seem to do anything properly and gives me a DNU inside the playback... >>>>> >>>>> Clues? >>>>> Phil >>>>> >>>> >>>> >>> >> >> >

March 12, 2013