- Pharo-dev - lists.pharo.org

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

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

by Mariano Martinez Peck

Indeed, we have a world record guiness 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] [update 2.0] #20025

by Guillermo Polito

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

[Pharo-project] [update 2.0] #20025

by Marcus Denker

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] VNC for pharo 1.3 or 1.4

by GastÃ³n Dall' Oglio

Hi. Look that you can do with a front-end for xpra, named Win Switch: http://winswitch.org/video/ Regards. El 27 de abril de 2012 17:09, Paul DeBruicker <pdebruic(a)gmail.com> escribiÃ³: > > Yanni Chiu wrote > > > > On 26/04/12 10:45 PM, Paul DeBruicker wrote: > >> You could also consider using 'xrpa' which is like screen but for X > >> applications. See Bernat Romagosa description here: > >> > >> > http://www.asmalltalkbytheseaside.com/#remotedevelopmentonpharowithoutvnc > > > > In that article, the steps are: > > > > % xpra attach :5 > > % DISPLAY=:5 ./pharo.sh > > > > which seems to imply that the 5-th DISPLAY port is occupied by the image. > > > > When I have several images running, using VNC, I can start/stop the VNC > > display in each image (and specify the portno) using a Seaside interface. > > > > So, I only have to open one firewall port for the X Display port (I'm > > probably doing something wrong here; maybe I should be using ssh), and I > > can operate each image GUI as necessary, as long as I only operate on > > one image at a time. > > > > Can a similar thing be done using xpra? > > > > If you run them through ssh then you only need the ssh port (22) open. > > Multiple Pharo apps can run at the same time by starting xpra on multiple > displays then starting your Pharo instances on those displays e.g.: > > xpra attach :5 > DISPLAY=:5 ~/pharoApp1/pharo.sh > xpra attach :6 > DISPLAY=:6 ~/pharoApp2/pharo.sh > > Then they just run and you can attach to and detach from (from the same or > different clients) them without affecting the Pharo process. I don't > think > you can put a currently running Pharo process inside the xpra process. The > 'DISPLAY=:5' bit just tells the X11 app you're starting which display to > use. > > https://help.ubuntu.com/community/Xpra > > > -- > View this message in context: > http://forum.world.st/VNC-for-pharo-1-3-or-1-4-tp4590152p4593664.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 27, 2012