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

Re: [Pharo-project] nebraska?

by StÃ©phane Ducasse

Would be really great. Stef On Mar 20, 2010, at 8:34 AM, Hilaire Fernandes wrote: > This is something I will be interested to look at, but not right now yet. > > > Hilaire > > StÃ©phane Ducasse a Ã©crit : >> +1 sad for genie ;( >> may be now with the new event handler if should be esaier to plug > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 20, 2010

Re: [Pharo-project] nebraska?

by Hilaire Fernandes

This is something I will be interested to look at, but not right now yet. Hilaire StÃ©phane Ducasse a Ã©crit : > +1 > > sad for genie ;( > may be now with the new event handler if should be esaier to plug >

March 20, 2010

Re: [Pharo-project] nebraska?

by StÃ©phane Ducasse

+1 sad for genie ;( may be now with the new event handler if should be esaier to plug > Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core. >> >> ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. >> We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it. >> >> Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install. > > So of course this idea of "just load it" is very difficult (impossible) to realize if the software in question was just hacked and put code everywere in the base system.... > I think after Nebraska was removed, we cleaned up the rendering of handmorph, for example. Nebraska complicates a far too complex Morphic system a bit. > > In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: > to learn from them and than build abstractions in the base system to make these things implementable in a nice way. > > I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are > not used is important if we want to move forward. > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 20, 2010

Re: [Pharo-project] [update] 10472

by StÃ©phane Ducasse

Ok thanks but so far this is more than three months that we are in RC and nothing special happened. so this is not a show stopper bug? No? Then when I run it multiple times it is always green. Mariano What do you get when the test is red? in 1.1 this is renamed BlockClosureTest and they are all green even when run multiple times @ elliot methodNodeFormattedAndDecorated: is not found in Pharo1.0 and 1.1 else all the tests are green even when run multiple times. Stef > John is right. This is an important test. In my work image it works fine. That it fails in Pharo is indicative of some problem with the execution simulation machinery and closures. You're missing some changes. > > BTW, in my image the class is BlockTest (see attached) > > 2010/3/19 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Careful, does anyone understand why it works, then why it fails. > Is it because the environment changes? Or some subtle issue in blocks? > Removing it because it fails doesn't seem like a useful criteria if it's attempted to give us a clue? > > On 2010-03-19, at 12:41 PM, StÃ©phane Ducasse wrote: > > > remove it! > > > > Stef > > > > On Mar 19, 2010, at 8:02 PM, Mariano Martinez Peck wrote: > > > >> > >> > >> - Make BlockContextTest>>testTrace run by commenting out broken part > >> of code simulation > >> > >> > >> Adrian: In 10515 this test sometime fails, but then running it again, it works :( > >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <BlockTest.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 20, 2010

Re: [Pharo-project] nebraska?

by Marcus Denker

On Mar 20, 2010, at 12:39 AM, Mariano Martinez Peck wrote: > Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core. > > ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. > We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it. > > Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install. So of course this idea of "just load it" is very difficult (impossible) to realize if the software in question was just hacked and put code everywere in the base system.... I think after Nebraska was removed, we cleaned up the rendering of handmorph, for example. Nebraska complicates a far too complex Morphic system a bit. In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way. I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 20, 2010

Re: [Pharo-project] another gofer question

by StÃ©phane Ducasse

no problem :) Tx Stef On Mar 19, 2010, at 9:36 PM, Lukas Renggli wrote: > Yeah, I explained the reason previously. You have to tell Gofer if > this is a version or package specification. In the beginning I though > that Gofer can guess if the stupd string is a version or just a > package name, but then I run into all those wired non-standard naming > of packages that makes this impossible. > > Lukas > > On 19 March 2010 20:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> thanks! >> >> >> On Mar 19, 2010, at 7:05 PM, Miguel Enrique CobÃ¡ Martinez wrote: >> >>> El vie, 19-03-2010 a las 18:55 +0100, StÃ©phane Ducasse escribiÃ³: >>>> HI lukas >>>> >>>> Gofer new >>>> squeaksource: 'Rio'; package: 'Rio-Kernel-razavi_acm_org.89'; package: 'Rio-Grande-kph.45'; load. >>>> >>>> does not work while the following does and load the same files. >>>> >>>> Gofer new >>>> squeaksource: 'Rio'; package: 'Rio-Kernel'; package: 'Rio-Grande'; load. >>>> >>>> what is the mistake I'm doing? >>> >>> The lateste versions of Gofer use package to specify a package name >>> without version. It takes the greatest version number. To get a given >>> version you use the version: (http://www.lukas-renggli.ch/blog/gofer) >>> method in the current gofer like: >>> Gofer new >>> squeaksource: 'KomHttpServer'; >>> version: 'DynamicBindings-gc.7'; >>> version: 'KomServices-gc.19'; >>> version: 'KomHttpServer-gc.32'; >>> update. >>> >>> The previous versions took the package and number and install that >>> specific version. This works no more. >>> >>> Cheers >>> >>> >>>> >>>> Stef >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 20, 2010

Re: [Pharo-project] nebraska?

by Lawson English

Mariano Martinez Peck wrote: > Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, > because we want a clean, tested and working core. > > ANY package that we don't consider core, should be removed and > loadable. I mean, if you want to use Nebraska, perfect, no problem. > But you should load it by yourself from squeaksource or whatever. In > the core (actually, we still trying) we put ONLY core code. In the > PharoDev we put mostly Core + Dev tools or examples. > We don't believe Nebraska should be neither in PharoDev in my opinion. > Of course, if people think the opposite, we can include it. > > Regardless the above said, I am not sure Nebraska is working on Pharo. > I invite you to try to load it, ask for help, and tell us the results. > Then you can create a Metacello configuration for it and make it easy > to manage and install. > Thanks, I did try to load it. I got various dependency issues which appeared to go back to: PluggableFileList>>morphicOpenLabel:in I found that in http://www.squeaksource.com/Pharo and attempted to load Morphic-MarcusDenker.551 but it had a nifty error that wasn't possible to read clearly because the error window was partly outside the boundries of the Phara desktop window and the interface froze. Although the system window was still dragable, none of the interior windows were. I eventually force-quit and tried again (3 times with same result). Lawson

March 20, 2010

Re: [Pharo-project] nebraska?

by Mariano Martinez Peck

Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core. ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it. Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install. Cheers Mariano On Fri, Mar 19, 2010 at 10:41 PM, Lawson English <lenglish5(a)cox.net> wrote: > I was fooling around and noticed that Nebraska isn't in the Pharo RC image. > Is it compatible at all with pharo, since it is based on Morphic? > > > lawson > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 19, 2010

Re: [Pharo-project] [update] 10472

by Eliot Miranda

John is right. This is an important test. In my work image it works fine. That it fails in Pharo is indicative of some problem with the execution simulation machinery and closures. You're missing some changes. BTW, in my image the class is BlockTest (see attached) 2010/3/19 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Careful, does anyone understand why it works, then why it fails. > Is it because the environment changes? Or some subtle issue in blocks? > Removing it because it fails doesn't seem like a useful criteria if it's > attempted to give us a clue? > > On 2010-03-19, at 12:41 PM, StÃ©phane Ducasse wrote: > > > remove it! > > > > Stef > > > > On Mar 19, 2010, at 8:02 PM, Mariano Martinez Peck wrote: > > > >> > >> > >> - Make BlockContextTest>>testTrace run by commenting out broken part > >> of code simulation > >> > >> > >> Adrian: In 10515 this test sometime fails, but then running it again, it > works :( > >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 19, 2010

[Pharo-project] nebraska?

by Lawson English

I was fooling around and noticed that Nebraska isn't in the Pharo RC image. Is it compatible at all with pharo, since it is based on Morphic? lawson

March 19, 2010