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

Re: [Pharo-project] files.pharo.org yielding a 502

by Marcus Denker

On Feb 11, 2013, at 8:22 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > We get these fairly often: > > -------------------------------------------------------------------------------- > Resolving files.pharo.org (files.pharo.org) 192.31.186.143 > Connecting to files.pharo.org (files.pharo.org)|192.31.186.143|:80... connected. > HTTP request sent, awaiting response... 502 Bad Gateway > 2013-02-11 20:18:41 ERROR 502: Bad Gateway. > -------------------------------------------------------------------------------- > > is it the pharo.org domain? or the gforge? no idea.. we should do it for realâ¦ we need to check what the status is with that fileserverâ¦ Marcus

Feb. 11, 2013

[Pharo-project] files.pharo.org yielding a 502

by Camillo Bruni

We get these fairly often: -------------------------------------------------------------------------------- Resolving files.pharo.org (files.pharo.org) 192.31.186.143 Connecting to files.pharo.org (files.pharo.org)|192.31.186.143|:80... connected. HTTP request sent, awaiting response... 502 Bad Gateway 2013-02-11 20:18:41 ERROR 502: Bad Gateway. -------------------------------------------------------------------------------- is it the pharo.org domain? or the gforge?

Feb. 11, 2013

Re: [Pharo-project] New Issue Tracker

by Camillo Bruni

On 2013-02-11, at 16:47, Benjamin Pollack <benjamin(a)bitquabit.com> wrote: > On Sat, Feb 9, 2013, at 12:47 PM, stephane ducasse wrote: >> thanks a lot ben. >> I'm busy migrating on 10.7 to 10.8 on a new machine and bumping into >> wellâ¦. glitches :) >> I will sync with the team monday. > > Good timing! The FogBugz team rolled pharo.fogbugz.com over to the beta > this morning. Each person can opt into or out of the beta individually; > to avoid disrupting you (the account seems very active at the moment), I > did *not* preemptively move everyone. To engage the beta UI, in the > toolbar at the top, you should see a link that says "FogBugz Beta UI is > disabled. [Enable it.]" Click the link, and, after a full-page refresh, > you should notice that suddenly everything runs *much* faster. > Specifically, the new UI speeds up list pages, case/email navigation, > case/email creation, and the search system. indeed looks nice and quite a bit faster ;) > While we think the new version is solid, and have been using it > internally for several months, there may be a bug or two. It's a beta; > that's the point. If you do hit an issue, you should find a link to go > back to the "slow" version in the same location, as well as a feedback > form where you can tell us what we need to fix. > > Again, please feel free to bug me if you have any questions, either on > the list, on IRC (bmp), or directly, and I'll be happy to answer them. > And, if all of you feel like FogBugz just isn't the right tool for > Pharo, that's fine, too. I just wanted you to have it as an option. So far I think it looks good ;). we started implementing the API to work on FogBugz. I guess we will decide this week whether or not to migrate to FogBugz. Am I right that you have a tool to migrate the issues from google code? Otherwise we might look into using our google code API to migrate issues...

Feb. 11, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by Eliot Miranda

On Sun, Feb 10, 2013 at 8:42 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 10 February 2013 16:25, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > Why does SystemNavigation >> #allSelect: return strings of the form > 'Array at:' instead of the real methods? > > Probably because the things that use SystemNavigation - Browsers, > MessageSets and the like - want to render lists of things to the user. > > There is one advantage to dumb strings, which is that it's easy to > make a SystemNavigation that works against a remote image. But that's > not much to go on. Changing these kinds of methods to return > MethodReferences might be a useful middle ground (and permit easy > extension to remote tools). > No, dumb strings are dumb. A className, selector pair (which is what MethodReference is) is the right thing (and what systemNavigation methods return). The dumb strings are a pain in the ass to parse (endlessly looking for ' class' to spot meta classes etc). Whereas the class,selector p[air approach is extensible, e.g. to include a pointer to a specific external entity (be it Monticello package or remote image). MethodReference is what the system has provided for a decade and they're convenient. There are multiple versions of these and I could care less about whether one uses MethodReference or RBMethodDefinition. But that they have a consistent API is really important. Programmatic uses of these things for code editing is something I've depended upon in the VMMaker, and I'm anxious that Pharo and Squeak don't diverge hopelssly on this level of the system. In my own work I've ended up with three kinds of code reference object a) MethodReference that points to a class,selector pair b) ClassReference that points to a class c) TextReference that holds onto a text So if one wants to check out a refactoring/edit before applying it one compares a sequence of MethodReference objects and a matching sequence of TextReference objects that hold onto the edited source to a comparison engine. If one wants to have a look at all uses of a SharedPool one can supply a list of ClassReference objects to a list browser. If one wanted to build a "compare two images" or "compare arbitrary package versions: facility one can extend the reference objects with pointers to specific packages or remote images. etc. Lots of stuff in the system depends on these kinds of pointer; message list browsers, Monticello's loader, etc. What's insane is a) not having a standard set of facilities common between Pharo and Squeak with a well-defined API (e.g. isCodeReference, isMethodReference, isClassReference), b) having some of the API in extension methods in e.g. Monticello. This is core reflection protocol and it needs to be well-defined and in what ever package contains base reflection protocol. excuse my ranting. > I mention remote tools because I hacked up a proof of concept a while > back that turned a Browser into one that could access a suitably > prepared image through an HTTP API. Development stalled because the > reflection machinery's API is a bit... involved, and it was dog slow, > but I could browse anything I liked. I should really wrap up the work > a bit so I can spread the love. > > frank > > -- best, Eliot

Feb. 11, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by Eliot Miranda

On Sun, Feb 10, 2013 at 8:25 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > Why does SystemNavigation >> #allSelect: return strings of the form 'Array > at:' instead of the real methods? > Because its broken. But it shouldn't return real methods. It should return MethodReference instances (or their equivalent, RBMethodDefinition), as do all the other systemNavigation facilities. -- best, Eliot

Feb. 11, 2013

Re: [Pharo-project] Experience using multiple images as a distributed datastore?

by Stephan Eggermont

Hi Martin, Hmm, through google it works, and removing the ? isn't enough. It is a paper on resilient distributed datasets. Lazy distributed collections, basically. http://www.cs.berkeley.edu/~matei/papers/2012/nsdi_spark.pdf Stephan

Feb. 11, 2013

Re: [Pharo-project] Experience using multiple images as a distributed datastore?

by Martin Dias

Hi Stephan, I got "Page not found" with that url. Cheers, Martin On Mon, Feb 11, 2013 at 12:15 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi, > > I'm looking at alternative ways to break through the 4G 1 core border. > Does anyone have recent experience storing data in multiple images > and parallelizing calculations, perhaps similar to > https://www.usenix.org/system/files/.../nsdi12-final138.pdf? > > With Ghost, Fuel and Zinc the building blocks seem to be there. > > Stephan >

Feb. 11, 2013

Re: [Pharo-project] New Issue Tracker

by Esteban A. Maringolo

Is there a way to have public access to issues? I mean, read only access to see the backlog of issues, what's being done, etc. With FogBugz all I see at pharo.fogbugz.com is a login page, whilst with Google Issue Tracking I was able to see the milestones, etc. Regards! Esteban A. Maringolo 2013/2/11 Benjamin Pollack <benjamin(a)bitquabit.com>: > On Sat, Feb 9, 2013, at 12:47 PM, stephane ducasse wrote: >> thanks a lot ben. >> I'm busy migrating on 10.7 to 10.8 on a new machine and bumping into >> wellâ¦. glitches :) >> I will sync with the team monday. > > Good timing! The FogBugz team rolled pharo.fogbugz.com over to the beta > this morning. Each person can opt into or out of the beta individually; > to avoid disrupting you (the account seems very active at the moment), I > did *not* preemptively move everyone. To engage the beta UI, in the > toolbar at the top, you should see a link that says "FogBugz Beta UI is > disabled. [Enable it.]" Click the link, and, after a full-page refresh, > you should notice that suddenly everything runs *much* faster. > Specifically, the new UI speeds up list pages, case/email navigation, > case/email creation, and the search system. > > While we think the new version is solid, and have been using it > internally for several months, there may be a bug or two. It's a beta; > that's the point. If you do hit an issue, you should find a link to go > back to the "slow" version in the same location, as well as a feedback > form where you can tell us what we need to fix. > > Again, please feel free to bug me if you have any questions, either on > the list, on IRC (bmp), or directly, and I'll be happy to answer them. > And, if all of you feel like FogBugz just isn't the right tool for > Pharo, that's fine, too. I just wanted you to have it as an option. > > Cheers, > --Benjamin >

Feb. 11, 2013

Re: [Pharo-project] New Issue Tracker

by Benjamin Pollack

On Sat, Feb 9, 2013, at 12:47 PM, stephane ducasse wrote: > thanks a lot ben. > I'm busy migrating on 10.7 to 10.8 on a new machine and bumping into > wellâ¦. glitches :) > I will sync with the team monday. Good timing! The FogBugz team rolled pharo.fogbugz.com over to the beta this morning. Each person can opt into or out of the beta individually; to avoid disrupting you (the account seems very active at the moment), I did *not* preemptively move everyone. To engage the beta UI, in the toolbar at the top, you should see a link that says "FogBugz Beta UI is disabled. [Enable it.]" Click the link, and, after a full-page refresh, you should notice that suddenly everything runs *much* faster. Specifically, the new UI speeds up list pages, case/email navigation, case/email creation, and the search system. While we think the new version is solid, and have been using it internally for several months, there may be a bug or two. It's a beta; that's the point. If you do hit an issue, you should find a link to go back to the "slow" version in the same location, as well as a feedback form where you can tell us what we need to fix. Again, please feel free to bug me if you have any questions, either on the list, on IRC (bmp), or directly, and I'll be happy to answer them. And, if all of you feel like FogBugz just isn't the right tool for Pharo, that's fine, too. I just wanted you to have it as an option. Cheers, --Benjamin

Feb. 11, 2013

[Pharo-project] [update 2.0] #20538

by Marcus Denker

20538 ----- Issue 7487: Testrunner calls #pragmas a class not implementing it http://code.google.com/p/pharo/issues/detail?id=7487 Issue 7341: Failing test: ReleaseTest>>#testInstalledMethodsWithIncorrectTrailerKind http://code.google.com/p/pharo/issues/detail?id=7341 Issue 7485: Make SmalltalkImage>>#downloadSources behavior an optional setting and default to false http://code.google.com/p/pharo/issues/detail?id=7485 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.506.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.782.diff http://ss3.gemstone.com/ss/Pharo20/Settings-System-MarcusDenker.23.diff

Feb. 11, 2013