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

Re: [Pharo-project] [ANN] Some love to NBOpenGL (making it up-to-date with pharo 2.0)

by Igor Stasenko

Confirmed on: Windows 7 64 bit. Works like a charm :) Now only linux is left. -- Best regards, Igor Stasenko.

March 15, 2013

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

by Sean P. DeNigris

Damir Majer wrote > IÂ´m searching for an Pharo command line execution (like REPL). Also see https://gist.github.com/seandenigris/2604215 , TSTTCPW ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-on-the-command-line-tp4676717p4676872.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 15, 2013

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

by Sean P. DeNigris

Damir Majer 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 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-on-the-command-line-tp4676706p4676870.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 15, 2013

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

by Esteban Lorenzano

but Behavior doesn't throws an "cannot be changed" error? so you are hacking... you need to remove it from "too dangerous classes"... :) On Mar 14, 2013, at 10:06 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I still got one: > > Add a new instance variable at end in Behavior => Image hangs after migrating ~420 classes ;) > The same goes for Set => image hangs > > Yes I know, highly common use-cases :P > > On 2013-03-14, at 21:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> On 14 Mar 2013, at 17:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> OK, I will give it a shake down later tonight ! >> >> Super ! >> >> I redid a couple of my long builds that used to fail before and I had zero crashes. >> >> Thanks a lot. > >

March 14, 2013

Re: [Pharo-project] how to use "Shared smalltalk workspaces"?

by Esteban Lorenzano

very cool Sven, thank you very much! On Mar 14, 2013, at 10:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Esteban, > > On 14 Mar 2013, at 13:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> I'll see what I can do... > > I added a simple web interface to create a new Shared Smalltalk Workspace to http://ws.stfx.eu > > From the homepage follow the New link, http://ws.stfx.eu/new > > Here is a screenshot: > > <Screen Shot 2013-03-14 at 20.46.39.png> > > I plan to add a simple 'trusted' config to make the loading of the ZnWorkspace client code a one-click experience as well. > > Sven > > PS: Of course, all this is running on the latest VM and 2.0 image ;-) > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill >

March 14, 2013

Re: [Pharo-project] [bug] window graphical leftovers

by Ben Coman

Same on Windows with a freshly downloaded 20504 image - at least when the progress bar is running... https://code.google.com/p/pharo/issues/detail?id=7413&q=drag&colspec=ID%20T… Serge Stinckwich wrote: > No related to Moose, same problem with last Pharo 2.0 image (20591). > What model of mac do you have Doru ? > > Regards, > > On Thu, Mar 14, 2013 at 9:33 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 14 March 2013 21:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> On Mac, when I move a window downwards I get some leftovers on the background (see picture from https://dl.dropbox.com/u/18323746/Tmp/window-graphical-leftovers.png) >>> >>> I am using the latest Pharo 2.0 and Pharo VM (updated every day). >>> >>> Am I the only one to see this? >>> >>> >> Not me.. just today i took and using a fresh image. >> >> Pharo2.0 >> Latest update: #20590 >> >> no any leftovers.. >> Can i guess it is because of extra stuff you installed with moose? >> Some override/extension? >> And i really doubt this is VM related. >> >> >> >>> Cheers, >>> Doru >>> -- >>> www.tudorgirba.com >>> >>> "If you interrupt the barber while he is cutting your hair, >>> you will end up with a messy haircut." >>> >>> >>> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > >

March 14, 2013

Re: [Pharo-project] Monticello cross-repository confusion?

by Frank Shearar

On 14 March 2013 22:22, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-03-14, at 22:59, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> I had a bit of an unusual state where I had an mcz in my Pharo 2.0 >> package-cache and another mcz with the same name & version in another >> directory repo, squeak-package-cache. A bit like if you were hacking >> on your release process in git and had to repeatedly git reset --soft >> HEAD^ to adjust your commit. >> >> I tried to load the _new_ mcz from squeak-package-cache, but Pharo >> insisted that that mcz was the mcz in package-cache. I only resolved >> the issue when I _deleted_ the mcz from package-cache. >> >> Has anyone else seen this before? It's frustrating and wrong: I think >> that the browser got confused because the two mczs were "the same" by >> virtue of having the same package-initials.version name. I say "wrong" >> because when viewing the squeak-package-cache repository I should see >> only those versions - regardless of name - that are in that >> repository. > > yes, this is the intended behavior under Pharo. Why? Because everything > else makes Monticello unacceptably slow. > > Monticello is "wrong" in this case by relying on a "unique" version name, > which it approximates by checking known repositories (works well for small > projects, but does not scale at all, nor does it give any guarantee of > being uniqe). > > That is the first report of such an issue since I changed the code there. > Hence I don't see an urge to change it. OK, so (a) I wasn't going crazy and (b) that's a perfectly acceptable answer. What I was doing is _not_ typical Monticello behaviour. I'll just bear this in mind for next time. Thanks! frank

March 14, 2013

Re: [Pharo-project] Monticello cross-repository confusion?

by Camillo Bruni

On 2013-03-14, at 22:59, Frank Shearar <frank.shearar(a)gmail.com> wrote: > I had a bit of an unusual state where I had an mcz in my Pharo 2.0 > package-cache and another mcz with the same name & version in another > directory repo, squeak-package-cache. A bit like if you were hacking > on your release process in git and had to repeatedly git reset --soft > HEAD^ to adjust your commit. > > I tried to load the _new_ mcz from squeak-package-cache, but Pharo > insisted that that mcz was the mcz in package-cache. I only resolved > the issue when I _deleted_ the mcz from package-cache. > > Has anyone else seen this before? It's frustrating and wrong: I think > that the browser got confused because the two mczs were "the same" by > virtue of having the same package-initials.version name. I say "wrong" > because when viewing the squeak-package-cache repository I should see > only those versions - regardless of name - that are in that > repository. yes, this is the intended behavior under Pharo. Why? Because everything else makes Monticello unacceptably slow. Monticello is "wrong" in this case by relying on a "unique" version name, which it approximates by checking known repositories (works well for small projects, but does not scale at all, nor does it give any guarantee of being uniqe). That is the first report of such an issue since I changed the code there. Hence I don't see an urge to change it.

March 14, 2013

Re: [Pharo-project] Phexample official repository?

by Frank Shearar

On 14 March 2013 13:53, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi: > > On 14 Mar 2013, at 14:47, Frank Shearar wrote: > >> 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). > > Just for clarification, that fix is included in the latest version. > >> 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.) > > Ok, thanks! OK, done. ConfigurationOfPhexample-fbs.7 loads cleanly in Pharo 1.4, 2.0 and Squeak 4.5. All tests are green. It's a bit sneaky in that since Squeak doesn't ship with a regex library I've piggy-backed on Pharo's. The sneaky part is that in the #squeak part of the spec I say `spec package: 'Phexample' with: [spec requires: 'Regex-Core']` which of course you don't need to do with Pharo. (In fact, if you do that requires in the #common section the configuration _breaks_ on Pharo 2.0. That might be because the repository won't have any such package, because it's loaded in the image? Although I thought that Metacello wouldn't attempt to load a package in that case. Ah well, it works now.) frank > Best regards > 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

[Pharo-project] Monticello cross-repository confusion?

by Frank Shearar

I had a bit of an unusual state where I had an mcz in my Pharo 2.0 package-cache and another mcz with the same name & version in another directory repo, squeak-package-cache. A bit like if you were hacking on your release process in git and had to repeatedly git reset --soft HEAD^ to adjust your commit. I tried to load the _new_ mcz from squeak-package-cache, but Pharo insisted that that mcz was the mcz in package-cache. I only resolved the issue when I _deleted_ the mcz from package-cache. Has anyone else seen this before? It's frustrating and wrong: I think that the browser got confused because the two mczs were "the same" by virtue of having the same package-initials.version name. I say "wrong" because when viewing the squeak-package-cache repository I should see only those versions - regardless of name - that are in that repository. frank

March 14, 2013