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

Re: [Pharo-project] FFI & Python

by Chris Cunningham

On Wed, Sep 5, 2012 at 3:58 PM, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > Hi all! > > I'm currently working in a project related with ROS (robot operative > system), which already have a library to develop in C++ and other to do the > same at Python. So, there a lot of variables to contrast to make a choice > (performance, code-easy-to-prototype, flexibility, and a lot more), but the > main variable is the accessibility from Pharo, then the question is, is > there any project that use python from pharo? Or, if i select python i > should write a library in C that bootstrap python and give access to pharo > via FFI? > > I looked in the list's mails and in google without any success. > > Thanks in advance! > > Santiago. > Not in Pharo (that I know of), but in OpenQwaq (a derivative of Squeak - from Pharo's past, I believe) it does include Python scripting: * Python Scripting of 2d applications and 3d objects (taken from the wikipedia on OpenQwaq). I'm not sure how they did it - not being a Python guy myself. -Chris

Sept. 5, 2012

[Pharo-project] FFI & Python

by Santiago Bragagnolo

Hi all! I'm currently working in a project related with ROS (robot operative system), which already have a library to develop in C++ and other to do the same at Python. So, there a lot of variables to contrast to make a choice (performance, code-easy-to-prototype, flexibility, and a lot more), but the main variable is the accessibility from Pharo, then the question is, is there any project that use python from pharo? Or, if i select python i should write a library in C that bootstrap python and give access to pharo via FFI? I looked in the list's mails and in google without any success. Thanks in advance! Santiago.

Sept. 5, 2012

Re: [Pharo-project] Process browser: next generation

by phil＠highoctane.be

An ability to jump to the process code right away. 2012/9/6 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hello! > > We are currently working on a new process browser (codename: Loom). You have probably noticed that the Process Browser is not exactly the tool you want to use to understand how processes behave. The process browser may be one of the oldest piece of Pharo code that has not been touched for a long long time. > > We are going toward something that looks like the Activity Monitor (e.g., [*]), useful to find out which programs is heating up your laptop. We will have nice curves that shows you the CPU consumption. Something that the process browser has never been able to do. > > What are the features you would like to see in it? > > Cheers, > Alexandre > > [*] http://media.tumblr.com/tumblr_lb4161Ehpr1qarbgx.png > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Sept. 5, 2012

Re: [Pharo-project] SystemVersion majorMinor

by Camillo Bruni

On 2012-09-06, at 00:39, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > > Camillo Bruni-3 wrote >> >> ok now I get it :P totally confused why CI would no longer work... >> > > - remove #majorMinor, which returns the same thing as > #dottedMajorMinor > > I guess I should've deprecated it... let's hope nobody relies on it :P

Sept. 5, 2012

Re: [Pharo-project] SystemVersion majorMinor

by Sean P. DeNigris

Camillo Bruni-3 wrote > > ok now I get it :P totally confused why CI would no longer work... > - remove #majorMinor, which returns the same thing as #dottedMajorMinor I guess I should've deprecated it... -- View this message in context: http://forum.world.st/SystemVersion-majorMinor-tp4646247p4646272.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 5, 2012

[Pharo-project] Process browser: next generation

by Alexandre Bergel

Hello! We are currently working on a new process browser (codename: Loom). You have probably noticed that the Process Browser is not exactly the tool you want to use to understand how processes behave. The process browser may be one of the oldest piece of Pharo code that has not been touched for a long long time. We are going toward something that looks like the Activity Monitor (e.g., [*]), useful to find out which programs is heating up your laptop. We will have nice curves that shows you the CPU consumption. Something that the process browser has never been able to do. What are the features you would like to see in it? Cheers, Alexandre [*] http://media.tumblr.com/tumblr_lb4161Ehpr1qarbgx.png -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 5, 2012

Re: [Pharo-project] latam mirror down?

by Dale Henrichs

----- Original Message ----- | From: "Frank Shearar" <frank.shearar(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, September 5, 2012 1:41:00 PM | Subject: Re: [Pharo-project] latam mirror down? | | On 5 September 2012 19:18, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Frank, | > | > overrideRepositories: overrides all of the repositories used during | > the load ... it was primarily intended to be used by folks wanting | > to isolate their development environment from the turbulent | > internets .... it is not quite as useful for trying to switch | > between multiple mirrors, you have to provide a complete set of | > repositories that are up and contain the packages ... | | Do you mean that Metacello will choose, for an entire load, a | repository? I'd imagined that it would, for each load of each | package, | try the repositories in order. But if it's per entire load, then | you'd | need each repo-containing server to have the full set of packages. | That would be more awkward. Metacello will choose from the entire list of repositories ... Metacello uses Gofer and Gofer does not scan in order... Supplying multiple repositories will kinda work, but as I said, the overrideRepositories feature was not intended as a solution for repositories going off-line. | | > Each project can specify primary and mirror repositories in their | > own configuration. | | Yes, which is the problem: how many ConfigurationOfs out there say | "SS, but fall back to LatAM", or "use the canonical, but fall back to | SS"? I know _yours_ do, but I suspect most won't. | | > Of course the problem comes up when the mirror repository is down, | > or the project is only hosted on one repository... | | If a package is hosted on SS, it will be on LatAm too, so all | SS-hosted packages can now come from either. This is the desired effect, methinks. | | frank Dale

Sept. 5, 2012

Re: [Pharo-project] SystemVersion majorMinor

by Camillo Bruni

ok now I get it :P totally confused why CI would no longer work... On 2012-09-05, at 22:39, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > since today > it was a cleanup by Sean... ask him why :) > > On Sep 5, 2012, at 10:31 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> since when is SystemVersion>>#majorMinor gone? and why? >> since there is still SystemVersion>>#majorMinor: >> >> best >> cami >> > >

Sept. 5, 2012

Re: [Pharo-project] latam mirror down?

by Frank Shearar

On 5 September 2012 19:18, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Frank, > > overrideRepositories: overrides all of the repositories used during the load ... it was primarily intended to be used by folks wanting to isolate their development environment from the turbulent internets .... it is not quite as useful for trying to switch between multiple mirrors, you have to provide a complete set of repositories that are up and contain the packages ... Do you mean that Metacello will choose, for an entire load, a repository? I'd imagined that it would, for each load of each package, try the repositories in order. But if it's per entire load, then you'd need each repo-containing server to have the full set of packages. That would be more awkward. > Each project can specify primary and mirror repositories in their own configuration. Yes, which is the problem: how many ConfigurationOfs out there say "SS, but fall back to LatAM", or "use the canonical, but fall back to SS"? I know _yours_ do, but I suspect most won't. > Of course the problem comes up when the mirror repository is down, or the project is only hosted on one repository... If a package is hosted on SS, it will be on LatAm too, so all SS-hosted packages can now come from either. frank > Dale > > ----- Original Message ----- > | From: "Frank Shearar" <frank.shearar(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, September 5, 2012 3:42:55 AM > | Subject: Re: [Pharo-project] latam mirror down? > | > | On 22 August 2012 21:59, Frank Shearar <frank.shearar(a)gmail.com> > | wrote: > | > On 22 August 2012 21:08, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | >> > | >> > | >> ----- Original Message ----- > | >> | From: "Frank Shearar" <frank.shearar(a)gmail.com> > | >> | To: Pharo-project(a)lists.gforge.inria.fr > | >> | Sent: Wednesday, August 22, 2012 11:56:12 AM > | >> | Subject: Re: [Pharo-project] latam mirror down? > | >> | > | >> | On 22 August 2012 19:33, Dale Henrichs <dhenrich(a)vmware.com> > | >> | wrote: > | >> | > Frank, > | >> | > > | >> | > You can already do this in your configuration by supplying a > | >> | > list > | >> | > of repositories instead of a single repository: > | >> | > > | >> | > spec > | >> | > repository: 'http://seaside.gemstone.com/ss/metacello'; > | >> | > repository: 'http://www.squeaksource.com/metacello'. > | >> | > > | >> | > Gofer is used to do the loads in Metacello, so I don't think > | >> | > that > | >> | > Gofer necessarily processes repositories in order , but this > | >> | > is > | >> | > the technique I use to insulate Metacello loads from > | >> | > repository > | >> | > outages... > | >> | > | >> | Sure, but I can't do that for ConfigurationOfFFI, for example. I > | >> | can't > | >> | do that for ObjectsAsMethodWrappers, to talk about what's > | >> | currently > | >> | causing our builds to fail. > | >> | > | >> | > My latam hack for travis ci had to do with compensating for > | >> | > configurations that are "single sourced"... > | >> | > | >> | Sure, and the presence of the latam mirror _ought_ to mean that > | >> | any > | >> | single-sourced thing on SS would no longer be single source. > | >> | Surely > | >> | it > | >> | would be easier all round if travisCI.st (if I remember the name > | >> | correctly) defined where to find these packages? (I can hear > | >> | Chris & > | >> | Chris saying "it should look on SM") > | >> | > | >> | I'll see if I can't hack up something we can pick over. > | >> > | >> Frank, > | >> > | >> If you're talking about what I did in builderCI ... then I agree > | >> wholeheartedly that a failover of some sort is called for when > | >> trying to bootstrap the latam mirror support ... squeaksource was > | >> dead at the time and I was in a hurry ... (haven't we heard that > | >> before) ... I'd welcome improvements there.... > | > > | > I'm trying a hack there now: basically, revert to using SS for > | > finding > | > ObjectsAsMethodWrappers and MontiRedirect, and selectively add the > | > LatAm redirect. Not great, because we're _still_ using a single > | > point > | > of failure. > | > > | >> A fail-over scheme for FFI or any arbitrary projects (is that what > | >> you're getting at?) is a bit more difficult, but I'd definitely > | >> be interested in seeing what you're thinking ... > | > > | > This is what I'm getting at. I'll see what I can think up. > | > | Well, it does seem to work, even though it's a stinky hack. I wrote a > | wrapper that inspects the package you're trying to load, and adds a > | few possible places where you might find it, and installed the > | wrapper > | on MetacelloLoaderPolicy >> #overrideRepositories. > | > | Hm. "Seems to work" might actually not be meaningful: is it the case > | that #overrideRepositories always returns the list of repos to > | search? > | Or is there a flag that says "use the config's repos, unless there > | are > | overrides"? If #overrideRepositories is always used, this _should_ > | work. > | > | Take a look at the wrapper [1] and the builderCI changes [2] and let > | me know what you think. > | > | frank > | > | [1] > | http://ss3.gemstone.com/ss/Scratchpad-fbs/MetacelloBuildOverrides-fbs.2.mcz > | [2] > | https://github.com/frankshearar/builderCI/commit/e1aec187d3d4ca5ec919886d88… > | > | > frank > | > > | >> Dale > | >> > | > | >

Sept. 5, 2012

Re: [Pharo-project] SystemVersion majorMinor

by Esteban Lorenzano

since today it was a cleanup by Sean... ask him why :) On Sep 5, 2012, at 10:31 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > since when is SystemVersion>>#majorMinor gone? and why? > since there is still SystemVersion>>#majorMinor: > > best > cami >

Sept. 5, 2012