April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo conf. Social Event

by StÃ©phane Ducasse

Hello pharoers I contacted the restaurant and book the places for 19h30-20h00. The restaurant is the sylmar 2 Pce Sebastopol, 59000 Lille 03 20 57 14 39 â http://www.yelp.fr/biz/the-sylmar-restaurant-lille http://maps.google.fr/maps/place?client=safari&rls=en&oe=UTF-8&redir_esc=&u… Now since the cook is cooking everything on the spot it is better if he knows how much we are. He told me that he will prepare two starters, two main dishes and two desserts so that we do not have to wait too long. So I'm sure that some of you did not registered yet on that page: so please do it http://www.doodle.com/sb2x77xk978zdkw2 Stef On Apr 23, 2012, at 7:25 PM, StÃ©phane Ducasse wrote: > Hi, > > For the conference, the lunches and coffee breaks are covered by INRIA and EMD. > > Now I would like to organize the social event for the thursday evening. Now our team cannot cover it because our budget is tight but I can have a really good restaurant (I know personally the cook). We could have a really good diner for around 30-35 Euros (with a cook cooking everything live in the back). Now I need to know who would like to join. You can come with your partners. > > So please let me know because like that I can book the restaurant. > > Stef > > >

April 28, 2012

[Pharo-project] [update 2.0] #20026

by Marcus Denker

20026 ----- Issue 5722: Be able to remove traits from class definition http://code.google.com/p/pharo/issues/detail?id=5722 Issue 5715: Enhance the Slice Maker so that is gets the issue title automatically http://code.google.com/p/pharo/issues/detail?id=5715 Issue 5580: MCOrganization unload correctly http://code.google.com/p/pharo/issues/detail?id=5580 -- Marcus Denker -- http://marcusdenker.de

April 28, 2012

Re: [Pharo-project] CompiledMethod>>origin, traits, and bug in RPackage

by StÃ©phane Ducasse

We should check that what we described in http://marcusdenker.de/publications/Duca09bTraitsAPI.pdf Stef On Apr 28, 2012, at 1:02 AM, Guillermo Polito wrote: > For example, the trait TPureBehavior has the method #traitComposition, which is an explicit requirement, and I can do > I have that: > > (TPureBehavior>>#traitComposition) origin. --> TPureBehavior > > which is nice. > Now lets suppose I create: > > Object subclass: #AAA > uses: TPureBehavior > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Guille' > > without creating the required traitComposition method > > (AAA>>#traitComposition) origin. --> AAA ?????????? shouldn't the origin be TPureBehavior? > > > The question is: Which is the intended behavior for the #origin of a method? Because that's causing an issue in RPackage :). > > > I've traced this, and it comes that if I have a trait method marked as explicitRequiriment, the following method answers just false > > CompiledMethod>>isProvided: marker > marker ifNil: [^ true]. > ^ (self isRequired: marker) not and: [(self isDisabled: marker) not] > > and then a magic ifNone: [ self ] return the receiver on the behavior, and that's why in both examples the method's behavior is returned instead of the origin. > Then we probably should have two methods > - #isProvided to see if an implementation is provided > - #isDefined if a definition for the method exists > but those names do not make me happy. > > Guille

April 28, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Sean P. DeNigris

Schwab,Wilhelm K wrote > > Put another way, if it's that simple, why all the contrary instructions > over time? > I understand your frustration. We are like parents watching a child grow up... For one thing, the API has been evolving as we've learned. From loadLast/Latest, to bleedingEdge/development, now to symbolic versions (which were sorely needed). The other impediment was that Metacello couldn't be assumed to have preloaded any base classes. Thus, ConfigurationOfXxx classes rely on someone manually (or automatically via tools) adding convenience methods. Without these, the API is hidden away in the project class. Recently, there seemed to be some agreement between Squeak and Pharo to load some base Metacello classes. If Configs had a common subclass, I think the system browser would be much more helpful. Dale, what do you think about all this? HTH, Sean p.s. of course ultimately, success depends on people testing projects and updating the configs... -- View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visi… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 28, 2012

Re: [Pharo-project] CompiledMethod>>origin, traits, and bug in RPackage

by Camillo Bruni

Hi guillermo.... I somehow fixed that by putting the origin in the method properties themselves. this seems to be rather simple and so far worked :D => check slice http://code.google.com/p/pharo/issues/detail?id=5696 which solves quite some issue on that front => maybe you can address the two left issue with this slice? On 2012-04-28, at 01:02, Guillermo Polito wrote: > For example, the trait TPureBehavior has the method #traitComposition, which is an explicit requirement, and I can do > I have that: > > (TPureBehavior>>#traitComposition) origin. --> TPureBehavior > > which is nice. > Now lets suppose I create: > > Object subclass: #AAA > uses: TPureBehavior > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Guille' > > without creating the required traitComposition method > > (AAA>>#traitComposition) origin. --> AAA ?????????? shouldn't the origin be TPureBehavior? > > > The question is: Which is the intended behavior for the #origin of a method? Because that's causing an issue in RPackage :). > > > I've traced this, and it comes that if I have a trait method marked as explicitRequiriment, the following method answers just false > > CompiledMethod>>isProvided: marker > marker ifNil: [^ true]. > ^ (self isRequired: marker) not and: [(self isDisabled: marker) not] > > and then a magic ifNone: [ self ] return the receiver on the behavior, and that's why in both examples the method's behavior is returned instead of the origin. > Then we probably should have two methods > - #isProvided to see if an implementation is provided > - #isDefined if a definition for the method exists > but those names do not make me happy. > > Guille

April 27, 2012

[Pharo-project] CompiledMethod>>origin, traits, and bug in RPackage

by Guillermo Polito

For example, the trait TPureBehavior has the method #traitComposition, which is an explicit requirement, and I can do I have that: (TPureBehavior>>#traitComposition) origin. --> TPureBehavior which is nice. Now lets suppose I create: Object subclass: #AAA uses: TPureBehavior instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Guille' without creating the required traitComposition method (AAA>>#traitComposition) origin. --> AAA ?????????? shouldn't the origin be TPureBehavior? The question is: Which is the intended behavior for the #origin of a method? Because that's causing an issue in RPackage :). I've traced this, and it comes that if I have a trait method marked as explicitRequiriment, the following method answers just false CompiledMethod>>isProvided: marker marker ifNil: [^ true]. ^ (self isRequired: marker) not and: [(self isDisabled: marker) not] and then a magic *ifNone: [ self ]* return the receiver on the behavior, and that's why in both examples the method's behavior is returned instead of the origin. Then we probably should have two methods - #isProvided to see if an implementation is provided - #isDefined if a definition for the method exists but those names do not make me happy. Guille

April 27, 2012

Re: [Pharo-project] [update 2.0] #20025

by Camillo Bruni

indeed we should have somehow a more sophisticated update feed - show all logs - show all diffs! ... and of course tons of phancy pharo graphs :) On 2012-04-28, at 00:16, Guillermo Polito wrote: > 32 integrations in one day :P. > > We should trace them from now on and make fancy graphics for the website (?). > > On Sat, Apr 28, 2012 at 12:12 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20025 > ----- > > Issue 5728: Add voidCogVMState primitives > http://code.google.com/p/pharo/issues/detail?id=5728 > > Issue 5727: add how to use comment to SystemProgressBarMorph > http://code.google.com/p/pharo/issues/detail?id=5727 > > Issue 5704: speed-up unwind-protects a little. > http://code.google.com/p/pharo/issues/detail?id=5704 > > Issue 5605: DateAndTimeTest>>testPrintStringNoOffset fails on pharo-one-click > http://code.google.com/p/pharo/issues/detail?id=5605 > > Issue 5653: SystemNavigation has unused class variable Default > http://code.google.com/p/pharo/issues/detail?id=5653 > > > -- > Marcus Denker -- http://marcusdenker.de > > >

April 27, 2012

Re: [Pharo-project] [update 2.0] #20025

by Guillermo Polito

On Sat, Apr 28, 2012 at 12:32 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Indeed, we have a world record guiness > Yes, but because of that Marcus was more integrating than hacking. Next time is Esteban's (?). > > > On Sat, Apr 28, 2012 at 12:16 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> 32 integrations in one day :P. >> >> We should trace them from now on and make fancy graphics for the website >> (?). >> >> >> On Sat, Apr 28, 2012 at 12:12 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> 20025 >>> ----- >>> >>> Issue 5728: Add voidCogVMState primitives >>> http://code.google.com/p/pharo/issues/detail?id=5728 >>> >>> Issue 5727: add how to use comment to SystemProgressBarMorph >>> http://code.google.com/p/pharo/issues/detail?id=5727 >>> >>> Issue 5704: speed-up unwind-protects a little. >>> http://code.google.com/p/pharo/issues/detail?id=5704 >>> >>> Issue 5605: DateAndTimeTest>>testPrintStringNoOffset fails on >>> pharo-one-click >>> http://code.google.com/p/pharo/issues/detail?id=5605 >>> >>> Issue 5653: SystemNavigation has unused class variable Default >>> http://code.google.com/p/pharo/issues/detail?id=5653 >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

April 27, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Camillo Bruni

On 2012-04-27, at 20:38, Schwab,Wilhelm K wrote: > I'm simply saying that we have a problem. When I first saw the config browser, I had hoped that it would bring the problem to light and spur a fix. As it is now, there are too many quirks and caveats for the browser to have any meaning beyond a few well-behaved items. > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopolito(a)gmail.com] > Sent: Friday, April 27, 2012 2:20 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > > > On Fri, Apr 27, 2012 at 8:11 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I know it's not a popular opinion, but overall, they don't work. It is so bad that any effort on my part to fix one here or there would simply be sticking a finger in a collapsing Hoover dam. "Yelling in general" is a mis-characterization of my apparently being the only person willing to characterize the emperor's new clothes. contrary to what you experience, I have almost never had issues with Configurations(only with mine in the beginning when learning on how to use Metacello) have you read the Metacello chapter of pharo by example? maybe you want improve that here and there so the information persists! > There are wide-spread problems. Either the configs need to be fixed, or we need a common location for the latest incantation that is thought to work with a given version of Pharo. > > But then you have the same problem if people commit packages that do not work. :S > > Providing working versions and tagging them, right now is a people problem, not a tool problem. And the same happens with python, java, javascript, .net, ruby, the OS software... > > > > I don't know how else to put it. > > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopolito(a)gmail.com] > Sent: Friday, April 27, 2012 1:37 PM > > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > On Fri, Apr 27, 2012 at 7:25 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > It's nice that there are examples that work, but the vast majority of configs are not so well organized. > > I'm not the mantainer of the majority of configs so I do not know. What I explained before is how they are supposed to work and be managed. If the person who mantains the config does not ensure you that, It's not the problem of the configuration :). > > Now, if there are configs not working as expected, it would be good to: > - know them > - tell the mantainers > - try to fix one? > - not yelling in general because that does not work :S. > > From my side, this week I fixed the configurations of: > - Glamour > - OpenDBXDriver > - Glorp + GlorpDBX > - ScriptManager > > so they can load in latest 1.4. But I can't be everywhere yet :P. > > Also, 1.4 is has just been released, so I expect most users are moving their stuff soon. > > Cheers, > Guille > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopolito(a)gmail.com] > Sent: Friday, April 27, 2012 12:26 PM > > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > I meant: > > Example of 1) is you loading OmniBrowser or Nautilus. > Example of 2) is your project using a specific version of XmlSupport or seaside. > Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. > > :P > > On Fri, Apr 27, 2012 at 6:26 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Wat? Probably there was a misunderstood... > > 1) if you are an user of the project, stable should be enough and fine. > 2) if your project is coupled to the project, probably you are coupled to an specific version. Thus, in your configuration you better put the specific number :). > 3) if your project is not coupled to the project, just inteded to load it, using stable should be enough and fine. > > Example of 1) is you loading OmniBrowser or Nautilus. > Example of 2) is your project using a specific version of XmlSupport or seaside. > Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. > > Guille > > > On Fri, Apr 27, 2012 at 5:06 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Put another way, if it's that simple, why all the contrary instructions over time? > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Camillo Bruni [camillobruni(a)gmail.com] > Sent: Thursday, April 26, 2012 7:40 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: > > > Can they really download stuff? How much? Until the configurations are truly self-describing and "know" what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. > > > > Bill > > > > [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) > > seems like you missed something (Metacello Configurations)? it's done like this in st-code: > > ConfigurationOfXYZ project load: #stable > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > > Sent: Thursday, April 26, 2012 6:17 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > > > Ok for me. > > Package Maps Loader > > > > Stef > > > >> What about naming it "Package Loader" or "Package center" or something like that? > >> And putting it in the main menu instead of inside of Tools? > >> > >> I want people who open pharo for the first time to say "Hey, here I can download stuff!!!" > >> > >> Guille

April 27, 2012

Re: [Pharo-project] SSL plugin for linux

by Camillo Bruni

cool! thanks igor :) On 2012-04-27, at 21:13, Sven Van Caekenberghe wrote: > Hey Igor, > > Thanks a lot for looking into this. > > I did a quick test (on a server) and yes it seems to work as expected. > > But someone has to run all the tests, I will try myself if I have time. > > Regards, > > Sven > > On 27 Apr 2012, at 19:29, Igor Stasenko wrote: > >> hi, i built ssl plugin >> >> i didn't tested but at least it find it and loads and i were able to >> run 1st primitive: >> >> primitiveSSLCreate >> "Primitive. Creates and returns a new SSL handle in the VM plugin" >> >> <primitive: 'primitiveCreate' module: 'SqueakSSL'> >> >> ^ self primitiveFailed >> >> >> i updated the configuration & added missing source files in this commit: >> >> https://gitorious.org/cogvm/blessed/commit/59ef1cb1c70a93ed3c974b5d6beea0e4… >> >> to build SSL plugin you must have ssl, and ssl-dev libs installed: >> >> >> sudo apt-get install openssl >> sudo apt-get install libssl-dev >> >> >> You can download prebuilt plugin from here: >> >> http://code.google.com/p/cog/downloads/detail?name=libSqueakSSL.so.gz&can=2… >> >> (it is with debug info, since i used debug config to build it) >> >> To build it, you shoud use >= CMakeVMMaker-IgorStasenko.157 >> and >> >> CogUnixConfig new >> addExternalPlugins: #( ... yours ... SqueakSSLPlugin ) >> generateSources; generate. >> >> >> please try plugin, if it works, so we can include it in standard build >> and be built automatically on jenkins server. >> >> -- >> Best regards, >> Igor Stasenko. >> > >

April 27, 2012