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

Re: [Pharo-project] Refactoring Browser depenences

by Mariano Martinez Peck

2009/12/28 Lukas Renggli <renggli(a)gmail.com> > > Another question, do you know what Refactoring-Spelling is > > Yes, I wrote it :-) > > It reactors your spell errors away :-P > > mmmmmmm I never seen that working in my code and it seems to be installed in almost all PharoDev images... Do I need to do something to enable it ? how do I use it ? Does it depends on something ? I ask because Stef said that maybe it depends in a library or something like that. I saw there is a SpellingPlugin. Is that compiled in all VMs? do you know ? Sorry, too many questions hahahah > > and who > > depends on it ? > > See attached PDFs. This is what Package-Dependencies produces in a few > second: highlighted cyclic dependencies, it removes transitive > dependencies, and it creates a simple graph that carries all > information to load. > > Lukas > > -- > 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 >

Jan. 11, 2010

Re: [Pharo-project] Presenter and Project will die aren't they ?

by Michael Rueger

On 1/11/2010 10:52 PM, StÃ©phane Ducasse wrote: > It would be nice to keep pharo in the browser now the question is can we do it > without somebody payed to maintain it to be compatible with each version. forget squeak/pharo in the browser. Nobody wants to install a plugin (and a 32MB one to boot) these days and etoys never made it into a lot of schools because of this. Scratch doesn't do it either, they export their projects to Java(!) to make them run in a browser. Michael

Jan. 11, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Stan Shepherd

Mariano Martinez Peck wrote: > > Hi Stan, can you check if there is another package missing from the > previous > dev image ? > > Thanks! > > Mariano > > Hi Mariano, attached is the list of differences from 10502 to 10505. All missing packages seem to relate to O2, except for Spelling. Is this what you meant? Cheers, ...Stan http://n2.nabble.com/file/n4288408/packagesDiff10502to10505.ods packagesDiff10502to10505.ods -- View this message in context: http://n2.nabble.com/BetaTesting-ANN-Pharo1-0-10505-rc1dev10-01-1-tp4278312… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 11, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Lukas Renggli

>> Was there a reason you opted not to include RB spelling? I don't know how >> may people use it- I find it really handy, so my vote would be for >> inclusion. > > if I remember it depends on some mac library No, it does not depend on the mac primitive. I've implemented an alternative that works on all platforms, less performant and of a lesser quality, but it should basically work. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 11, 2010

Re: [Pharo-project] Presenter and Project will die aren't they ?

by StÃ©phane Ducasse

On Jan 11, 2010, at 10:41 PM, Michael Roberts wrote: > CodeLoader is referenced in the ProjectLauncher, but assuming we don't > want to support Pharo in a browser (??) then you could strip out the > HTTPClient checks, leaving the part that reads from disk. It would be nice to keep pharo in the browser now the question is can we do it without somebody payed to maintain it to be compatible with each version. > > cheers, > Mike > > On Mon, Jan 11, 2010 at 2:09 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Jan 11, 2010, at 3:04 PM, Mariano Martinez Peck wrote: >> >>> Ok...and what about CodeLoader? I ask because it seems it uses ImageSegment to export categories and classes to disk. >>> >> >> Anyone uses it? If not --> remove. >> >> I think it's just another lefover experiment. >> >> Marcus >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by StÃ©phane Ducasse

> > Was there a reason you opted not to include RB spelling? I don't know how > may people use it- I find it really handy, so my vote would be for > inclusion. if I remember it depends on some mac library Stef

Jan. 11, 2010

Re: [Pharo-project] Presenter and Project will die aren't they ?

by Michael Roberts

CodeLoader is referenced in the ProjectLauncher, but assuming we don't want to support Pharo in a browser (??) then you could strip out the HTTPClient checks, leaving the part that reads from disk. cheers, Mike On Mon, Jan 11, 2010 at 2:09 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jan 11, 2010, at 3:04 PM, Mariano Martinez Peck wrote: > >> Ok...and what about CodeLoader? Â I ask because it seems it uses ImageSegment to export categories and classes to disk. >> > > Anyone uses it? If not --> remove. > > I think it's just another lefover experiment. > > Â Â Â Â Marcus >

Jan. 11, 2010

Re: [Pharo-project] System -> About in Dev images

by csrabak＠bol.com.br

Em 10/01/2010 18:30, Mariano Martinez Peck <marianopeck(a)gmail.com> escreveu: > On Sun, Jan 10, 2010 at 9:10 PM, <csrabak(a)bol.com.br> wrote: [snipped] > > I'm not so sure if I undertand this in full, so I'll test my > > understanding: Do your assertion above means that an > > hypothetical: > > Pharo1.0-10505-rc1dev10.01.1 > > that after some updates ends up reponding in System->About this: > > > > Pharo1.0-10505-rc1dev10.01.1 > > PharoCore1.0rc1 > > Latest update: #10510 > > You say that it would be *different* than a brand new downloaded: > > Pharo1.0-10510-rc1dev10.01.1 > > PharoCore1.0rc1 > > Latest update: #10510 > > Is it? > > > Exactly. Maybe is just a little detail. I don't know. > > [snipped] > > As an after thought after seeing other posts on the issue, I think > more than a generic warning that "may break the image" the > Monticello comments and/or a simple explanation on the reasons and > affected packages *before* the update starts with an option to > proceed or abort is much in need. > > > Yes, maybe. Then thing is that I am not sure in which cases it > would break. Only in overrides? How many overrides do we have from > external pacakges in Core stuff? I have no idea. Considering both comments above, I would say we're going to have a not cool system. If this non determinism is left in our updating mechanism, more and more we'll have bug reports answered as "could not reproduce" or similar and the perceived quality of Pharo as a programming tool will suffer. I understand the issue isn't small potatoes but we should keep it in mind and find all opportunities to have this streamlined. As a counter measure, a built image could have a kind of history log of changesets zeroed and as one applies updates, slices, and load packages, this info could become available (as an adjunct to the debug trace) to help to backtrack the steps to reproduce the reported issue. HTH -- Cesar Rabak PS.: Before Stef puts a line asking for code, I believe we already have the machinary for this available, if this is not the case, then we'll need to put code in!

Jan. 11, 2010

Re: [Pharo-project] Corrupted Monticello

by John Toohey

Did the cleanUpForRelease, but MC still hangs. Do you know what DEV image is the most stable right now, or is there a way to enable debug output from MC? 2010/1/11 Mariano Martinez Peck <marianopeck(a)gmail.com> > Maybe you can reload the Monticello and MonticelloGUI package from the > repository Pharo. However, I would check in that 10496 image which were the > versions of those two packages and I would download exactly those two > versions. > > Maybe you can also try to remove the package cache and also evaluate > (backup the image first): > > MCFileBasedRepository flushAllCaches. > MCMethodDefinition shutDown. > MCDefinition clearInstances. > > Or even > > ScriptLoader new cleanUpForRelease > > Cheers > > Mariano > > > 2010/1/11 John Toohey <jt(a)parspro.com> > >> Hi, >> I've just built a new image based on PharoCore1.0rc1 Latest update: >> #10496, and MC freezes the image whenever I try to open a package. I can >> view a repo, but not open or load the packages. Is there anyway to rebuild >> MC, without rebuilding the entire image again? There is no debug file >> written out, just the CPU pegged at 99% and an unresponsive image. >> >> -- >> -JT >> >> >> >> _______________________________________________ >> 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 > -- -JT

Jan. 11, 2010

Re: [Pharo-project] Corrupted Monticello

by Mariano Martinez Peck

Maybe you can reload the Monticello and MonticelloGUI package from the repository Pharo. However, I would check in that 10496 image which were the versions of those two packages and I would download exactly those two versions. Maybe you can also try to remove the package cache and also evaluate (backup the image first): MCFileBasedRepository flushAllCaches. MCMethodDefinition shutDown. MCDefinition clearInstances. Or even ScriptLoader new cleanUpForRelease Cheers Mariano 2010/1/11 John Toohey <jt(a)parspro.com> > Hi, > I've just built a new image based on PharoCore1.0rc1 Latest update: #10496, > and MC freezes the image whenever I try to open a package. I can view a > repo, but not open or load the packages. Is there anyway to rebuild MC, > without rebuilding the entire image again? There is no debug file written > out, just the CPU pegged at 99% and an unresponsive image. > > -- > -JT > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 11, 2010