- Pharo-dev - lists.pharo.org

Re: [Pharo-project] No matter what I do today...

by phil＠highoctane.be

Esteban +1000! (that's a factorial) Phil 2013/3/14 Igor Stasenko <siguctua(a)gmail.com>: > Miracle. > > (One more and we can declare you saint! ) :) > > Thanks for the hard work, Esteban. > > -- > Best regards, > Igor Stasenko. >

March 14, 2013

Re: [Pharo-project] No matter what I do today...

by Sven Van Caekenberghe

On 14 Mar 2013, at 14:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > Miracle. > > (One more and we can declare you saint! ) :) Let's keep our fingers crossed. > Thanks for the hard work, Esteban. Indeed, thank you ! > -- > Best regards, > Igor Stasenko. >

March 14, 2013

Re: [Pharo-project] Phexample official repository?

by Frank Shearar

On 14 March 2013 13:22, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi: > > On 13 Mar 2013, at 15:38, Frank Shearar wrote: > >> Cool, thanks Stefan. I only found out about the confusion of >> repositories after I sent you Phexample-fbs.64 - did it pass all tests >> on Pharo 1.4? If so, and you're OK with the change, I'll rebase my >> work off the latest version and resubmit. I'll also edit the >> ConfigurationOf to add a #squeak section. > > I finally got around to solve the includesSub[sS]tring issue. > I also fixed the #isTest: on the class side of Phexample and use it. > All together with tests documenting the desired behavior. > > I chose to use packages for the platform specific stuff: > - PhexamplePlatform-Pharo14 (should also work with Squeak 4.4 and 4.5) > - PhexamplePlatform-Pharo20 > > The tests do not completely run on Squeak 4.4, Frank, if you need that, please have a look. > I did not tests with Squeak 4.5. Sorry, I should have replied here too: I rebased my fix (loosening the requirement on the error message) and pushed Phexample-fbs.69. It works on Pharo 1.4 and Squeak 4.5 (so should also work on Pharo 2.0 and Squeak 4.4 but haven't verified either). I'm trying to tweak the ConfigurationOf, but haven't managed to get past some Metacello stuff. (I'm trying to actually read the docs on specifying other projects before complaining about it!) Once I have a ConfigurationOf working, I'll add CI jobs for Phexample on Squeak 4.5. (I also need to set up CI jobs for running these on 4.4, but that's a more general problem.) frank > On my machine, tests pass for Pharo 1.4 and Pharo 2.0 > > Camillo, you set up the Jenkins project? > https://ci.inria.fr/pharo-contribution/job/Phexample/ > > I tried to be patient, but it does not look like the build got triggered. > Is there anything I need to do other then publish in the code in: http://smalltalkhub.com/#!/~Phexample/Phexample? > > Thanks > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

March 14, 2013

Re: [Pharo-project] No matter what I do today...

by Igor Stasenko

Miracle. (One more and we can declare you saint! ) :) Thanks for the hard work, Esteban. -- Best regards, Igor Stasenko.

March 14, 2013

[Pharo-project] [update 2.0] #20591

by Marcus Denker

20591 ----- 10014 World menu > System > Switch User serves no purpose https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-serve… 10004 SmalltalkImage current reportCPUandRAM > DNU https://pharo.fogbugz.com/f/cases/10004/SmalltalkImage-current-reportCPUand… Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1059.diff http://ss3.gemstone.com/ss/Pharo20/KeyChain-MarcusDenker.30.diff

March 14, 2013

Re: [Pharo-project] Phexample official repository?

by Stefan Marr

Hi: On 13 Mar 2013, at 15:38, Frank Shearar wrote: > Cool, thanks Stefan. I only found out about the confusion of > repositories after I sent you Phexample-fbs.64 - did it pass all tests > on Pharo 1.4? If so, and you're OK with the change, I'll rebase my > work off the latest version and resubmit. I'll also edit the > ConfigurationOf to add a #squeak section. I finally got around to solve the includesSub[sS]tring issue. I also fixed the #isTest: on the class side of Phexample and use it. All together with tests documenting the desired behavior. I chose to use packages for the platform specific stuff: - PhexamplePlatform-Pharo14 (should also work with Squeak 4.4 and 4.5) - PhexamplePlatform-Pharo20 The tests do not completely run on Squeak 4.4, Frank, if you need that, please have a look. I did not tests with Squeak 4.5. On my machine, tests pass for Pharo 1.4 and Pharo 2.0 Camillo, you set up the Jenkins project? https://ci.inria.fr/pharo-contribution/job/Phexample/ I tried to be patient, but it does not look like the build got triggered. Is there anything I need to do other then publish in the code in: http://smalltalkhub.com/#!/~Phexample/Phexample? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 14, 2013

Re: [Pharo-project] No matter what I do today...

by Martin Dias

Nice! now it is working. Thank you. Now, we have 2 tests failing that were not failing with the "old" NBCog vm. But may be fault of Fuel, I will check. On Thu, Mar 14, 2013 at 2:09 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed, the Moose tests run both on Ubuntu and on Mac. > > Good job! > > Doru > > > On Thu, Mar 14, 2013 at 2:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> yep... I will promote the vm I'm testing as "stable" (even if it need >> still some tweaks, I think). >> so we can see :) >> >> On Mar 14, 2013, at 2:03 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> > >> > On Mar 14, 2013, at 2:01 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> > >> >> I guess latest fuel build crashes the vm: >> >> https://ci.inria.fr/rmod/job/Fuel/151/console >> > >> > But it uses a VM build a wee ago: >> > >> > pharo VM version: 3.9-7 #1 Thu Mar 7 14:32:07 CET 2013 gcc 4.4.3 >> > Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 >> > uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 7 2013 >> > With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 7 2013 >> > Revision: git://gitorious.org/cogvm/blessed.git Commit: >> > 7473ca83a257cfb9e20eedc568f31f0437b9be39 Date: 2013-03-06 14:23:07 +0100 By: >> > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14533 >> > Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed >> > Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux >> > plugin path: /builds/workspace/Fuel/vm/ [default: >> > /builds/workspace/Fuel/vm/] >> > >> >> >> >> On Thu, Mar 14, 2013 at 1:54 PM, Esteban Lorenzano >> >> <estebanlm(a)gmail.com> wrote: >> >>> ... I cannot crash the VM :) >> >>> >> >>> So it looks like we are almost ready to release! >> >>> >> >>> Esteban >> >>> >> >> >> > >> > >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

March 14, 2013

Re: [Pharo-project] rpackage transition

by Tudor Girba

Hi, I am sorry to have wasted your time. Cheers, Doru On Thu, Mar 14, 2013 at 1:06 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Can we please first release 2.0 before we waste all our energy in useless > discussions? > > On Mar 14, 2013, at 1:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 14 March 2013 11:25, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Igor, > >> > >> Please, let's keep the discussion at the level of arguments. > >> > > > > sorry.. we had conversations about that multiple times with Stef and > Marcus. > > And it was sounded like we came to some consensus. > > But your statements actually an invitation to restart from where we come > from.. > > > >> The original reasons for developing RPackage were: > >> - to offer a first class package object in the image and to remove the > >> category-string-based-solution, and > >> - to get rid of Monticello-magic-mapping, and potentially offer the > option > >> of adding tags as an orthogonal mechanism. > >> > >> At this moment, we have RPackage mapped one-to-one to categories, but > the > >> core implementation still relies on categories. So, at the very least, > we > >> should find a way to remove categories and directly rely on RPackage. > >> > > > > yes. > > I was not part of development of RPackage.. and i still don't understand > why > > it is so hard to make it map 1:1 to MC package instead of 1:1 to > category. > > > > Category is nothing.. it is thin air.. it is the arbitrary name chosen > > by developer > > which he can change at any moment. > > It does not influencing anything at all (except from sorting the lists > > in browser).. > > > > A very simple rule: when you defining new class or recategorizing it, > > it will be added to package which name matching the category name (or > > first parts of it).. > > Does that sounds like technically impossible to implement? > > > > newclassCategory := 'Foo-Bugz' > > packageToAddTo := packages detect:[:ea | newclassCategory beginsWith: ea > name ] > > ? > > > > I simply cannot find a good justification, why instead of doing small > > change in single place, > > we want to force numerous people do a lot of changes over whole world > > of packages. > > It doesn't sounds like a smart move. > > Especially if there would be clear benefit.. But there's not. At least > > i don't see one. > > > >> The Monticello mapping is there only for historical reasons. To > eliminate it > >> we need a strategy. For this, I see two options: > >> - either we go with simply removing categories altogether and just > relying > >> on RPackages with 1-to-1 mappings to Monticello packages, > >> - we introduce another mechanism (such as tags) that allows us to map > >> categories on this. > >> > > yes this was added.. so we need last bit - make tags play role of > categories. > > and make MC directly interact with RPackage for loading/snapshotting > stuff. > > > > but since we cannot make everything at once, i hope gradually we will > > come there. > > > >> Perhaps there are other options, too. > >> > >> Btw, I thought that in Pharo, backward compatibility is secondary to > sound > >> engineering :). > >> > > > > From machine's perspective , a package is just a collection of > > objects. Machine don't needs any naming > > there in order to make it run. Names are meaningful only to humans. > > So, categories/tags is extra metainformation which should be kept by > > package to make sure humans can understand it. > > Because if going to extreme, if you strip all names away, then you > > turning a package into unsorted set of objects, without any means to > > distinguish one from another by developers.. > > > > Does that sounds like 'sound engineering'? > > :) > > > > > >> Cheers, > >> Doru > >> > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 14, 2013

Re: [Pharo-project] No matter what I do today...

by Tudor Girba

Indeed, the Moose tests run both on Ubuntu and on Mac. Good job! Doru On Thu, Mar 14, 2013 at 2:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > yep... I will promote the vm I'm testing as "stable" (even if it need > still some tweaks, I think). > so we can see :) > > On Mar 14, 2013, at 2:03 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > On Mar 14, 2013, at 2:01 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > >> I guess latest fuel build crashes the vm: > >> https://ci.inria.fr/rmod/job/Fuel/151/console > > > > But it uses a VM build a wee ago: > > > > pharo VM version: 3.9-7 #1 Thu Mar 7 14:32:07 CET 2013 gcc 4.4.3 > > Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 > uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 7 2013 > > With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 7 2013 > > Revision: git://gitorious.org/cogvm/blessed.git Commit: > 7473ca83a257cfb9e20eedc568f31f0437b9be39 Date: 2013-03-06 14:23:07 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14533 > > Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed > Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux > > plugin path: /builds/workspace/Fuel/vm/ [default: > /builds/workspace/Fuel/vm/] > > > >> > >> On Thu, Mar 14, 2013 at 1:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>> ... I cannot crash the VM :) > >>> > >>> So it looks like we are almost ready to release! > >>> > >>> Esteban > >>> > >> > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 14, 2013

Re: [Pharo-project] Pharo on the command line

by Pavel Krivanek

Hi, there is a very simple REPL example based on Pharo Kernel. https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-2.0/job/PharoKerne… The script that makes the image is here: http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker… -- Pavel On Thu, Mar 14, 2013 at 12:54 PM, Damir Majer <damir(a)majcon.de> wrote: > Hi NG, > > IÂ´m searching for an Pharo command line execution (like REPL). > IÂ´ve heard about coral. > > Is this still the option to go or is another Tool available in Pharo 2.0? > > Cheers, > Damir > > > > ----- > -- > Damir Majer > ... be agile: www.majcon.de > -- > View this message in context: http://forum.world.st/Pharo-on-the-command-line-tp4676717.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 14, 2013