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

Re: [Pharo-project] OSProcess under Pharo

by Bill Schwab

Bryce, Thanks for your reply. Actually, I mentioned FFI etc. because that appeared to be a way to get what OSProcess wanted in terms of dependencies; using Universes should handle that part for me. FFI would be of interest on its own, but appears to make people nervous. Is that for good reason? Put another way, if I want to make some calls into a dll/so, do I really need to mess around with creating/compiling/distributing a plugin? It seems like a lot of overhead, especially since Dolphin does such a nice job based on a mechanism very similar (in apperance at least) to FFI. That said, I am interested in candid opinions; maybe things really are different in Squeak/Pharo. Thanks! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> bryce(a)kampjes.demon.co.uk 9/30/2008 2:12 PM >>> Bill Schwab writes: > Before doing something I might regret, I wanted to check with you about > installing OSProcess, VMMaker(?), FFI, etc. Do you have anything to say > "try it and report any problems?" I load OSProcess and FFI from universes, it works loading into a recent pharo-dev image. There's an issue with CommandShell as it subclasses off some MVC classes, I think it's safe to ignore. I'd load VMMaker from SqueakSource directly, but it depends on what you want to do. I've merged the FreeType changes into the Exupery VM's and will add closure support in the next few days. Loading Exupery-dev from the universes will load all the packages you listed. (Though, there's an incompatibility between Exupery and the stricter instance variable checks in Pharo, will be fixed in the next release.) Bryce _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 30, 2008

[Pharo-project] OSProcess under Pharo

by bryce＠kampjes.demon.co.uk

Bill Schwab writes: > Before doing something I might regret, I wanted to check with you about > installing OSProcess, VMMaker(?), FFI, etc. Do you have anything to say > "try it and report any problems?" I load OSProcess and FFI from universes, it works loading into a recent pharo-dev image. There's an issue with CommandShell as it subclasses off some MVC classes, I think it's safe to ignore. I'd load VMMaker from SqueakSource directly, but it depends on what you want to do. I've merged the FreeType changes into the Exupery VM's and will add closure support in the next few days. Loading Exupery-dev from the universes will load all the packages you listed. (Though, there's an incompatibility between Exupery and the stricter instance variable checks in Pharo, will be fixed in the next release.) Bryce

Sept. 30, 2008

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

StÃ©phane Ducasse wrote: > > On Sep 30, 2008, at 10:20 AM, David RÃ¶thlisberger wrote: > >> >>> why the down cyan arrow is not a down cyan arrow with a down orange >>> arrow? (may be this is ugly but it would be >>> more consistent). >> >> well, we have a cyan square for an abstract method without >> sub-implementation, so for those with sub-impl., we could have a small >> cyan square with an orange down arrow. >> But I think the current cyan down arrow looks much better. > > but what does mean down arrow? > I have subclass implementing it (when the arrow is orange). > Am I correct? yes. Any down arrow means that at least one subclass is implementing a method with the same name. Orange down arrow means just that, a cyan down arrow additionally means that the method you are looking at is abstract, but subclasses do implement the method. David

Sept. 30, 2008

[Pharo-project] Re: Installer

by StÃ©phane Ducasse

Hi keith Since I'm more in doing than talking.... I read the code of Installer I reformatted the code and publish it. I did not change anything so far. I suggest you to consider formatting as an important code readibility issue. Often I cannot see the complete method or I cannot understand its flow. Stef Now here is a list of questions/suggestions ============================== Installer class>>classes ^ Smalltalk not invoked seems bogus ============================== Entities seems a bad name for html elements mapping. ============================== history seems obsolete Installer class>>mczInstall is misclassified ============================== Installer class>>sake ^ self sake: (Sake ifNil: [ self classPackages current ]) Does not make sense to me if Sake is not loaded. setSakeToUse: aClass Sake := aClass is missing a comment to indicate what is the purpose of Sake? On the instance side ============================== user ^ user ifNil: [ '' ] user: anObject user := anObject user is undefined, thanks shout! ============================== classMCMczReader ^Smalltalk at: #MCMczReader ifAbsent: [ nil ] classMCReader ^Smalltalk at: #MCReader ifAbsent: [ nil ] classMczInstaller ^Smalltalk at: #MczInstaller ifAbsent: [ nil ] why nil and not error as all the others? ============================== createRBforBug: aBugNo | aStream fileList selFile aFileName | self setBug: aBugNo. fileList := self maFiles keys asOrderedCollection. fileList addLast: 'none'. ReleaseBuilderFor3dot10 clear. [selFile := UIManager default chooseFrom: fileList title: 'Choose what files load '. selFile = fileList size ifFalse:[ aFileName := fileList at: selFile. self logCR: 'obtaining ', aFileName, '...'. aStream := self maStreamForFile: aFileName . ReleaseBuilderFor3dot10 current packagesInfluenced: aStream named: aFileName. self installCS: aFileName from: aStream].selFile = fileList size]whileFalse. ReleaseBuilderFor3dot10 current newUpdateFor: aBugNo ReleaseBuilderFor3dot10 does not exist. ============================== installMCcs: aFileName from: stream | reader | reader := MCCsReader on: stream. should use self MCCsReader because MCCsReader may not exist ============================== skipTests is empty

Sept. 30, 2008

[Pharo-project] SIF working - needs a small fix

by Bill Schwab

Hello, I would like to tell you all the incredible things I did to get SIF going - truth is, it loaded and just worked. The only gripe I have is that the Pharo browsers are displaying a large number of LF or other non-printable characters as boxes in the Pharo browsers. I have seen Squeak do this many times, and either just ignored it or deleted them, as my need to view the code and tolerance level allowed. It will get old with the amount of code I plan to move. How would YOU fix this? Is it a SIF problem (dumping out things it should not from Dolphin), a SIF problem (not supressing characters as they are loaded in Pharo), or something missing in the browsers that is expected to be fixed in Pharo? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Sept. 30, 2008

[Pharo-project] OSProcess under Pharo

by Bill Schwab

Before doing something I might regret, I wanted to check with you about installing OSProcess, VMMaker(?), FFI, etc. Do you have anything to say "try it and report any problems?" Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Sept. 30, 2008

Re: [Pharo-project] Fwd: Strange bug

by StÃ©phane Ducasse

Yes I can believe you. The mechanism in fact hijack the organisation field to put the method dict and the method dict field is nilled. Then the idea is that the virtual machine when it gets nil in the method dictionary will not crash but it will restore the method dict this way you can see how much classes a certain function uses. Now what we saw with mathieu is that when a browser is open all the classes are used: it means that all the methoddict are accessed somehow and we wanted to know why this was like that but we could not find it. And we found this bug that fucked up the image of mathieu. Stef On Sep 30, 2008, at 10:30 AM, Michael Roberts wrote: > http://code.google.com/p/pharo/issues/detail?id=207 > > I couldn't figure it out but managed to make a mess of my my image... > > Mike > > On Mon, Sep 29, 2008 at 3:58 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> >> >> >> Hi >> >> ImageSegment discoverActiveClasses. >> is cool and it lets you (by swapping method dict behind your back) >> knowing >> which classes >> have been involved in a certain action. >> >> as follow >> Now ImageSegment discoverActiveClasses. >> -- do something typical -- >> ImageSegment activeClasses size printString , ' classes were active >> out of ' >> , >> Smalltalk allClasses size printString. >> >> Now if following >> recoverFromMDFaultWithTrace >> >> you put >> >> Smalltalk at: #MDFaultDict put: Dictionary new. >> >> you get a strange error, tell you that there is syntax error >> >> Stef >> >> >> >> >> >> _______________________________________________ >> 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 >

Sept. 30, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

On Sep 30, 2008, at 10:20 AM, David RÃ¶thlisberger wrote: > >> why the down cyan arrow is not a down cyan arrow with a down orange >> arrow? (may be this is ugly but it would be >> more consistent). > > well, we have a cyan square for an abstract method without sub- > implementation, so for those with sub-impl., we could have a small > cyan square with an orange down arrow. > But I think the current cyan down arrow looks much better. but what does mean down arrow? I have subclass implementing it (when the arrow is orange). Am I correct? I'm confused with a down up inconsistency. Stef > > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

On Sep 30, 2008, at 10:18 AM, David RÃ¶thlisberger wrote: > >> So I miss the pane showing the comment under the class def. > > yes, true. I need to how to to that. > What we have in the multiple selection browser is the mechanism to > automatically get the class comment on the right of the class def > panel in a second panel. > >> May be a good way also would be to have the question mark with a >> different color when there is a comment. > > Or in red when there's no comment. > >> David we are starting to use manifesto for package so it would be >> also great to show them. > > Ok. Do you have an example of a package using it? Moose? Yes we started with Moose. In FAMIX2-Importer for example/ But have a look at the comment of the class in the DrDoc package. Stef > > > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2008

[Pharo-project] Senders and implementors list with package

by StÃ©phane Ducasse

Hi david in the latest version of pharo when you browse the senders of a message you get the usual list but the items show in addition the package in the item after the category (which is useless to my eye). Could you add that to OB senders and implementors? Stef

Sept. 30, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by StÃ©phane Ducasse

Keith could you make sure that the tests can run when we load the installer and its tests? I do not know what is the classcloner... Stef

Sept. 30, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by StÃ©phane Ducasse

Yes I like it too. This is why I want to invest on it. On Sep 30, 2008, at 4:27 AM, Igor Stasenko wrote: > I like the Installer. > Its a simple tool to break your work onto multiple stages/packages. > It is very useful for making automatic builds. > No manual image hacking - instead you have to fix the scripts or > packages. > This will guarantee that every time you will load the same code as > before, w/o losing or forgetting something. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by StÃ©phane Ducasse

> > Thanks Marcus (and Stef) - glad there's a fix, and now I know in > future where to look for bugs that I may find, and to report them. > Sure this is important Marcus I will harvest it. Stef

Sept. 30, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by StÃ©phane Ducasse

> > >> A few fast-hit alt-. efforts can bring up a debugger on the current >> process, but it too is frozen. >> >> Don't know if this was already something knew about. Sorry for the >> duplication if so. > > No report no problem. I was sorry I typed something stupid.... when you cannot control your fingers it is time to go to bed :) > > It also shows that we have to clean this menu. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2008

Re: [Pharo-project] [OB] Implementor

by David RÃ¶thlisberger

> instClass wiresong > project: 'ob'; > install: 'OB-TraitsIntegration-dc.34'. Maybe it's because of this line. OB-Enhancements does now contain OB-TraitsIntegration, so loading it a second time could lead to strange behavior. Besides that I use almost the same versions, with these two differences: OB-Morphic-dr.58 OB-Enhancements-dr.219 David

Sept. 30, 2008

Re: [Pharo-project] [OB] Implementor

by Alexandre Bergel

I did a ScriptLoader class>>loadTools -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= loadOB "self loadOB" | instClass | instClass := self environment at: #Installer ifAbsent: [self new installingInstaller]. instClass ss project: 'AST'; install: 'AST-lr.158'. instClass ss project: 'RefactoringEngine'; install: 'RefactoringEngine-ab.51'. instClass wiresong project: 'ob'; install: 'OmniBrowser-dr.419'; install: 'OB-Standard-dr.355'; install: 'OB-Morphic-dr.57'; install: 'OB-Enhancements-dr.217'; install: 'OB-Refactory-lr.100'; install: 'OB-SUnitIntegration-dc.9'. instClass wiresong project: 'ob'; install: 'OB-TraitsIntegration-dc.34'. loadShout "self loadShout" | instClass | instClass := self environment at: #Installer ifAbsent: [self new installingInstaller]. instClass ss project: 'shout'; install: 'Shout.3.15-tween.72'. instClass ss project: 'shout'; install: 'ShoutWorkspace.1-tween.2'. instClass ss project: 'shout'; install: 'ShoutOmniBrowser-dc.5.mcz' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I can provide an image if necessary. Alexandre On 30 Sep 2008, at 15:57, David RÃ¶thlisberger wrote: > Hi Alex, > >> Pressing alt-m on a method that is implemented on a class-side >> prevents from opening a implementor method. > > I cannot reproduce this - which version of OB are you using? > > David > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 30, 2008

Re: [Pharo-project] [OB] Implementor

by David RÃ¶thlisberger

Hi Alex, > Pressing alt-m on a method that is implemented on a class-side prevents > from opening a implementor method. I cannot reproduce this - which version of OB are you using? David

Sept. 30, 2008

Re: [Pharo-project] OB's icon support improved

by Oscar Nierstrasz

Why not put that information in the ? button itself? E.g., bold font if there is something there, and italic if there is nothing. - on On Sep 29, 2008, at 18:57, StÃ©phane Ducasse wrote: > You know I would really like to see if this is worth pressing the ? > > So I miss the pane showing the comment under the class def. > May be a good way also would be to have the question mark with a > different color > when there is a comment. > > David we are starting to use manifesto for package so it would be > also great to show them. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 30, 2008

[Pharo-project] [OB] Implementor

by Alexandre Bergel

Hi! Pressing alt-m on a method that is implemented on a class-side prevents from opening a implementor method. I will open an issue. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 30, 2008

Re: [Pharo-project] Fwd: Strange bug

by Michael Roberts

http://code.google.com/p/pharo/issues/detail?id=207 I couldn't figure it out but managed to make a mess of my my image... Mike On Mon, Sep 29, 2008 at 3:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > > Hi > > ImageSegment discoverActiveClasses. > is cool and it lets you (by swapping method dict behind your back) knowing > which classes > have been involved in a certain action. > > as follow > Now ImageSegment discoverActiveClasses. > -- do something typical -- > ImageSegment activeClasses size printString , ' classes were active out of ' > , > Smalltalk allClasses size printString. > > Now if following > recoverFromMDFaultWithTrace > > you put > > Smalltalk at: #MDFaultDict put: Dictionary new. > > you get a strange error, tell you that there is syntax error > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Sept. 30, 2008

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

> why the down cyan arrow is not a down cyan arrow with a down orange > arrow? (may be this is ugly but it would be > more consistent). well, we have a cyan square for an abstract method without sub-implementation, so for those with sub-impl., we could have a small cyan square with an orange down arrow. But I think the current cyan down arrow looks much better. David

Sept. 30, 2008

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

> So I miss the pane showing the comment under the class def. yes, true. I need to how to to that. What we have in the multiple selection browser is the mechanism to automatically get the class comment on the right of the class def panel in a second panel. > May be a good way also would be to have the question mark with a > different color when there is a comment. Or in red when there's no comment. > David we are starting to use manifesto for package so it would be > also great to show them. Ok. Do you have an example of a package using it? Moose? David

Sept. 30, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Igor Stasenko

I like the Installer. Its a simple tool to break your work onto multiple stages/packages. It is very useful for making automatic builds. No manual image hacking - instead you have to fix the scripts or packages. This will guarantee that every time you will load the same code as before, w/o losing or forgetting something. -- Best regards, Igor Stasenko AKA sig.

Sept. 30, 2008

[Pharo-project] Integrate early and release often and tests was: Installer was: Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Simon Kirk

Hi all. Apropos of the conversation this subject line evolved from, I was thinking about this from Marcus: "Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible." This lead me to think various comments recently from Stef (I think - I apologise if I'm miss-paraphrasing, but I can't find the exact messages) about how to tell which tests have failed/passed etc as the versions go by. I submit that in order for early integration and regular release to work, it needs to be an "all tests green or nothing" situation. Of course, it's very difficult to make sure all the tests are passing, but I just ran *all* the tests in the system, and there's only one error and one failure. This is fantastic work! Not only that but the error is down to BookMorph (due for removal iirc?) and a #printString problem with Array, the latter of which *has* to be simple to fix. If this level of passing tests (or even better, all of them; not necessarily possible as various things like EToys are stripped out I imagine) is maintained, there's no need to tell what tests have changed state from version to version; moreover Pharo will be far the better for it, imho. Just my â¬0.02 :) Cheers, Simon ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 29, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Simon Kirk

FWIW I am 100% behind "release often, integrate as soon as possible". Not only this but you only have to do a small amount of googling to begin to realise that *finally* the computing world is getting the sea change required to make this approach the main stream, rather than the BUF* (release planning in this case). I'm not trying to invalidate people taking other approaches: I simply don't think they're the best way to do things. If those people working hard on Pharo can stick to the guns of this approach (and it's not an easy approach), I think it will be the right one. I'm sorry I don't have more time to give myself, but I try to keep myself useful from time to time. Cheers, Simon On 29 Sep 2008, at 20:55, Keith Hodges wrote: > >> Release image? that means, you will not close *any* bug-report until >> you release >> 3.11? Wow. But you sure close at least duplicated bug-reports? > Wow what? The release will know which bug fixes are included and > provide > a list of fixes which can be closed, when the release is actually > ready > and available. >>> Everything that I have been developing loads into "all" existing >>> images, >>> so for example, LPF may want to load fixes into 3.7 if it needs >>> something. >> >> So does this make sense? I think there is not enough manpower to >> even get >> *one* stable and *one* development branch going. Beeing backtward >> compatible to >> such old releases makes no sense. > So why does Seaside, Magma etc run in older images? > > Please think sensibly, we are not trying to make "everything" work in > all images. Just to enable the things that we want to work when > necessary. > > Last year I found myself working in 3.8, 3.9 and 3.10, maintaining > different packages in different images. For example I would have to > have > an image especially configured just for developing contributions to > Seaside. I ended up running about 12 different images. Simply > because MC > would not handle method extensions and overrides correctly. > > So essential step... "make MC run identically in all images, and make > overrides and extensions work"... in the process benefit the whole > community. >> Especially as 3.7 is very different to 3.9 >> (just the I18N stuff will kill you). > It wont kill me since I am not using it. > > The point is that there are people actually using 3.7 and 3.8 for > things. Up until recently Gjallar was using 3.8. The transition to > 3.10 > was achieved by building the image in 3.8 using an installer script, > then migrating that script and the packages involved to work with both > 3.8 and 3.10. Finally the script was run to generate a 3.10 image. >> In the end, what you are doing will result in kind of re-doing 3.8 >> for >> 3.7, >> 3.9 for 3.8... and so on, > Not really. > > To get Monticello 1.5 working in 3.7 requires something like 5-6 > methods > to be added to the base image. Necessary changes to Kernel are usually > very minimal. >> in addition to actually doing 3.11. >> Is that realistic? >>> Previously fixes are ONLY available by waiting for the >>> release team to harvest, or by manually loading a changeset in >>> yourself. >>> Now the harvesters can make a fix readily available for everyone >>> through >>> Installer. >>> >>> This attitude of supporting all users of squeak, while moving things >>> forward for everyone, is a core-value of the 3.11 team. >> >> This is *the* recipe for failure. > There is no need to be so dramatic. > > We have been doing this for a while now and have seen nothing but > success. LPF is useful it works and has worked for lots of people, > whereas before the Croquet community and the XO community were > destined > to be out on their own. I now know that I can load my website up on my > XO, and I fully expect to be able to try Rio out in Croquet. >> You can not do anything even remotely >> complex if any changeset that fixes something in 3.11 needs to work >> on >> 3.7, too. > I never said that it would "have to", but it can if necessary. >> However, the old way, fixes are applied to a moving target, since the >> >> But this can not work: fixes depend on each other. It is *one of >> the most >> important principles* to let the submitter of fixes do the work of >> merging >> his fix with the latest fix applied to the image. Else you will die. > That's a bit dramatic, I am not planning on dying any time soon. >> You can never manage the amount of changes submitted if you can >> just say: >> "rejected. reason: conflicts with current version. Please resubmit". > We dont need to say that at all. We can say, here is an image, (or > here > is a script which builds the image) in which your fix is loaded and > needs further work. >> Another very important principle is to close reports on the >> bugtracker as >> soon as possible to keep it managable. > I don't see that, but then I am not looking at the BugTracker to read > bug reports. I periodically export reports into squeak, so I am look > at > them in my class browser where each report is a method that I can > categorize. >> This even means that once a changeset >> is harvested, the report is closed *and not re-opend* if there is a >> new bug >> after applying. That is a *new* report, for a *new* bug (the report >> then will >> of course refrence the faulty closed report). > Sounds fair enough. But I dont think you are understanding the > "release" > is an atomic event. Fixes can get tweaked improved up until the > release. >> Overall, I am 100% sure that your idea how to manage 3.11 is >> fundamentally wrong >> (sorry). > Your approach is based around small incremental changes to an image, > performed by a single person. In particular it is easier to add things > than to remove things. Overall it results in an adhoc process that > lacks > planning. It lacks control over the big picture. Everyone ends up > following the one person doing the release. The release team do what > they want in whatever order they want to do it. No one knows what the > plan is in advance and there is no mechanism provided for people to > contribute into the work. > > We have 3.11 fully planned, the script to generate the test-candidate > runs, from end to end. Contributors can add their fix-tasks to that > script. >> And Pharo will do it completely differently: release often, integrate >> as soon >> as possible, keep the bugtracker down to managable levels and do not >> be religiously >> backwards-compatible. > This is a cop out, it is taking a process that could be a slope and > making it a step, but you are pretending that it will be a slope by > saying nice things like "release often" and "integrate asap". Squeak > has > never been release often or integrate as soon as possible. The reason > for this is nothing to do with squeak, it is to do with PROCESS. The > Squeak 3.7 3.8 3.9 PROCESS did not support these ideals. So unless the > Pharo process has changed, the pharo process will not be any > different. > > However, the 3.11 development has been entirely about creating a > process > that will support "release often" and that we could do monthly time > boxed releases with. >> We will see at the end what was the better Idea ;-) > I have always maintained that Pharo's goals and 3.11's goals are > essentially the same. > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 29, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by Simon Kirk

Thanks Marcus (and Stef) - glad there's a fix, and now I know in future where to look for bugs that I may find, and to report them. On 29 Sep 2008, at 20:34, Marcus Denker wrote: > > On 29.09.2008, at 21:29, StÃ©phane Ducasse wrote: > >> Good catch, if I press proceed then my image gets blocked >> can you enter a bug entry? >> And really another menu with lot of things to clean or we should >> simply get rid of it. >> > > Fix: http://code.google.com/p/pharo/issues/detail?id=191 > > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 29, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

StÃ©phane Ducasse wrote: > > >> We will see at the end what was the better Idea ;-) > > Good challenge :) > I will integrate a bit more etoys now. > > Stef Not a challenge I am taking up, I have a ball joint to replace on my car, and no time to input into this at the moment. Keith

Sept. 29, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

> Release image? that means, you will not close *any* bug-report until > you release > 3.11? Wow. But you sure close at least duplicated bug-reports? Wow what? The release will know which bug fixes are included and provide a list of fixes which can be closed, when the release is actually ready and available. >> Everything that I have been developing loads into "all" existing images, >> so for example, LPF may want to load fixes into 3.7 if it needs >> something. > > So does this make sense? I think there is not enough manpower to even get > *one* stable and *one* development branch going. Beeing backtward > compatible to > such old releases makes no sense. So why does Seaside, Magma etc run in older images? Please think sensibly, we are not trying to make "everything" work in all images. Just to enable the things that we want to work when necessary. Last year I found myself working in 3.8, 3.9 and 3.10, maintaining different packages in different images. For example I would have to have an image especially configured just for developing contributions to Seaside. I ended up running about 12 different images. Simply because MC would not handle method extensions and overrides correctly. So essential step... "make MC run identically in all images, and make overrides and extensions work"... in the process benefit the whole community. > Especially as 3.7 is very different to 3.9 > (just the I18N stuff will kill you). It wont kill me since I am not using it. The point is that there are people actually using 3.7 and 3.8 for things. Up until recently Gjallar was using 3.8. The transition to 3.10 was achieved by building the image in 3.8 using an installer script, then migrating that script and the packages involved to work with both 3.8 and 3.10. Finally the script was run to generate a 3.10 image. > In the end, what you are doing will result in kind of re-doing 3.8 for > 3.7, > 3.9 for 3.8... and so on, Not really. To get Monticello 1.5 working in 3.7 requires something like 5-6 methods to be added to the base image. Necessary changes to Kernel are usually very minimal. > in addition to actually doing 3.11. > Is that realistic? >> Previously fixes are ONLY available by waiting for the >> release team to harvest, or by manually loading a changeset in yourself. >> Now the harvesters can make a fix readily available for everyone through >> Installer. >> >> This attitude of supporting all users of squeak, while moving things >> forward for everyone, is a core-value of the 3.11 team. > > This is *the* recipe for failure. There is no need to be so dramatic. We have been doing this for a while now and have seen nothing but success. LPF is useful it works and has worked for lots of people, whereas before the Croquet community and the XO community were destined to be out on their own. I now know that I can load my website up on my XO, and I fully expect to be able to try Rio out in Croquet. > You can not do anything even remotely > complex if any changeset that fixes something in 3.11 needs to work on > 3.7, too. I never said that it would "have to", but it can if necessary. > However, the old way, fixes are applied to a moving target, since the > > But this can not work: fixes depend on each other. It is *one of the most > important principles* to let the submitter of fixes do the work of > merging > his fix with the latest fix applied to the image. Else you will die. That's a bit dramatic, I am not planning on dying any time soon. > You can never manage the amount of changes submitted if you can just say: > "rejected. reason: conflicts with current version. Please resubmit". We dont need to say that at all. We can say, here is an image, (or here is a script which builds the image) in which your fix is loaded and needs further work. > Another very important principle is to close reports on the bugtracker as > soon as possible to keep it managable. I don't see that, but then I am not looking at the BugTracker to read bug reports. I periodically export reports into squeak, so I am look at them in my class browser where each report is a method that I can categorize. > This even means that once a changeset > is harvested, the report is closed *and not re-opend* if there is a > new bug > after applying. That is a *new* report, for a *new* bug (the report > then will > of course refrence the faulty closed report). Sounds fair enough. But I dont think you are understanding the "release" is an atomic event. Fixes can get tweaked improved up until the release. > Overall, I am 100% sure that your idea how to manage 3.11 is > fundamentally wrong > (sorry). Your approach is based around small incremental changes to an image, performed by a single person. In particular it is easier to add things than to remove things. Overall it results in an adhoc process that lacks planning. It lacks control over the big picture. Everyone ends up following the one person doing the release. The release team do what they want in whatever order they want to do it. No one knows what the plan is in advance and there is no mechanism provided for people to contribute into the work. We have 3.11 fully planned, the script to generate the test-candidate runs, from end to end. Contributors can add their fix-tasks to that script. > And Pharo will do it completely differently: release often, integrate > as soon > as possible, keep the bugtracker down to managable levels and do not > be religiously > backwards-compatible. This is a cop out, it is taking a process that could be a slope and making it a step, but you are pretending that it will be a slope by saying nice things like "release often" and "integrate asap". Squeak has never been release often or integrate as soon as possible. The reason for this is nothing to do with squeak, it is to do with PROCESS. The Squeak 3.7 3.8 3.9 PROCESS did not support these ideals. So unless the Pharo process has changed, the pharo process will not be any different. However, the 3.11 development has been entirely about creating a process that will support "release often" and that we could do monthly time boxed releases with. > We will see at the end what was the better Idea ;-) I have always maintained that Pharo's goals and 3.11's goals are essentially the same. Keith

Sept. 29, 2008

Re: [Pharo-project] SqueakMap Packae Loader - nil object

by Marcus Denker

On 29.09.2008, at 21:16, Dan Corneanu wrote: > Hi, > there is an exception when trying to open SqueakMap Package Loader in > the latest pharo/pharo-dev images with the latests updates. > The object instance variable of SMSqueakMap is nil. > I'm not sure if I should have put an issue on the tracker or not. http://code.google.com/p/pharo/issues/detail?id=193 (even though it will be removed... but even if the world endet tomorrow, one should plant a tree or so someone famous once said) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by Marcus Denker

On 29.09.2008, at 21:29, StÃ©phane Ducasse wrote: > Good catch, if I press proceed then my image gets blocked > can you enter a bug entry? > And really another menu with lot of things to clean or we should > simply get rid of it. > Fix: http://code.google.com/p/pharo/issues/detail?id=191 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by StÃ©phane Ducasse

Good catch, if I press proceed then my image gets blocked can you enter a bug entry? And really another menu with lot of things to clean or we should simply get rid of it. I do not know what is the configuration option. Stef On Sep 29, 2008, at 9:00 PM, Simon Kirk wrote: > Hi all. > > Not sure where I should report this. If I use the middle/right > (depending on one's preferences) click World menu (the one with > Project and Configuration sub-menus down towards the bottom third of > the menu), when my mouse goes over the "Configuration" menu section, > the entire image freezes irrevocably, at least on OSX (my VM). > > A few fast-hit alt-. efforts can bring up a debugger on the current > process, but it too is frozen. > > Don't know if this was already something knew about. Sorry for the > duplication if so. > > Cheers, > Simon > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

Re: [Pharo-project] Total image lockup when using middle/right click menu on world

by StÃ©phane Ducasse

On Sep 29, 2008, at 9:00 PM, Simon Kirk wrote: > Hi all. > > Not sure where I should report this. If I use the middle/right > (depending on one's preferences) click World menu (the one with > Project and Configuration sub-menus down towards the bottom third of > the menu), when my mouse goes over the "Configuration" menu section, > the entire image freezes irrevocably, at least on OSX (my VM). Did you check if you have the preference to warn deprecated method on? Because when I do the same as you I get a currentProjectRefactoring.... > A few fast-hit alt-. efforts can bring up a debugger on the current > process, but it too is frozen. > > Don't know if this was already something knew about. Sorry for the > duplication if so. No report It also shows that we have to clean this menu.

Sept. 29, 2008

Re: [Pharo-project] SqueakMap Packae Loader - nil object

by StÃ©phane Ducasse

this is not clear yet, but SqueakMap will not be kept as a way to load code. So this is normal that your code does not load with squeakmap. stef On Sep 29, 2008, at 9:16 PM, Dan Corneanu wrote: > Hi, > there is an exception when trying to open SqueakMap Package Loader in > the latest pharo/pharo-dev images with the latests updates. > The object instance variable of SMSqueakMap is nil. > I'm not sure if I should have put an issue on the tracker or not. > > Best regards, > Dan Corneanu. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

[Pharo-project] SqueakMap Packae Loader - nil object

by Dan Corneanu

Hi, there is an exception when trying to open SqueakMap Package Loader in the latest pharo/pharo-dev images with the latests updates. The object instance variable of SMSqueakMap is nil. I'm not sure if I should have put an issue on the tracker or not. Best regards, Dan Corneanu.

Sept. 29, 2008

Re: Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by StÃ©phane Ducasse

> We will see at the end what was the better Idea ;-) Good challenge :) I will integrate a bit more etoys now. Stef

Sept. 29, 2008

Re: [Pharo-project] How do we manage todos?

by StÃ©phane Ducasse

ok but there are todos :) Stef On Sep 29, 2008, at 8:16 PM, Norbert Hartl wrote: > On Mon, 2008-09-29 at 10:51 +0200, Marcus Denker wrote: >> On 28.09.2008, at 21:40, StÃ©phane Ducasse wrote: >> >>> I would prefer a bugtraker with a tag todo that are not bug fixes. >> >> Ok. Then we can split up the one entry that has all the TODOs. >> > Ok, there are things that are more _to do_ than others? :)) > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

[Pharo-project] Total image lockup when using middle/right click menu on world

by Simon Kirk

Hi all. Not sure where I should report this. If I use the middle/right (depending on one's preferences) click World menu (the one with Project and Configuration sub-menus down towards the bottom third of the menu), when my mouse goes over the "Configuration" menu section, the entire image freezes irrevocably, at least on OSX (my VM). A few fast-hit alt-. efforts can bring up a debugger on the current process, but it too is frozen. Don't know if this was already something knew about. Sorry for the duplication if so. Cheers, Simon ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 29, 2008

Re: [Pharo-project] How do we manage todos?

by Norbert Hartl

On Mon, 2008-09-29 at 10:51 +0200, Marcus Denker wrote: > On 28.09.2008, at 21:40, StÃ©phane Ducasse wrote: > > > I would prefer a bugtraker with a tag todo that are not bug fixes. > > Ok. Then we can split up the one entry that has all the TODOs. > Ok, there are things that are more _to do_ than others? :)) Norbert

Sept. 29, 2008

Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Marcus Denker

>> >> So fixes are not integrated into the image anymore and the report >> then >> closed? > When a release image is released the fixes are integrated into the > image > as normal, and can be closed or marked "fixed". > Release image? that means, you will not close *any* bug-report until you release 3.11? Wow. But you sure close at least duplicated bug-reports? > Everything that I have been developing loads into "all" existing > images, > so for example, LPF may want to load fixes into 3.7 if it needs > something. So does this make sense? I think there is not enough manpower to even get *one* stable and *one* development branch going. Beeing backtward compatible to such old releases makes no sense. Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). In the end, what you are doing will result in kind of re-doing 3.8 for 3.7, 3.9 for 3.8... and so on, in addition to actually doing 3.11. Is that realistic? > Previously fixes are ONLY available by waiting for the > release team to harvest, or by manually loading a changeset in > yourself. > Now the harvesters can make a fix readily available for everyone > through > Installer. > > This attitude of supporting all users of squeak, while moving things > forward for everyone, is a core-value of the 3.11 team. This is *the* recipe for failure. You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too. > >> What I don't understand with the use of Installer with mantis >> entries: >> From my >> experience from 3.6 to 3.9, there is quite some dependency between >> fixes. > Nothing is automatic, if you or some script loads the wrong fix in the > wrong order then that is a problem. And of course this means that nobody can load any other order, so it makes no sense to have all the fixes as entities on their own at all. >> >> to build "your own release". This just can't work with all the >> dependencies between >> fixes. > However, the old way, fixes are applied to a moving target, since the > alpha image is continuously being updated. Yes, this is very important. As loading a fix for 3.10 into the developement version of 3.11 will almost never work, as other fixes already changed the sytem. This is true even with the installer. So you will end up in using the "moving target" of 3.10+ Intaller as your "HEAD" system that people use when doing changes. Else you will end up in many changesets that have conflicts, and, very annoyting, hundreds of douple-reports of bugs. > With this approach fixes > applied to 3.10 (a fixed target) are used to create a 3.11 unstable > until the combination of fixes is deemed "stable" But this can not work: fixes depend on each other. It is *one of the most important principles* to let the submitter of fixes do the work of merging his fix with the latest fix applied to the image. Else you will die. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. This even means that once a changeset is harvested, the report is closed *and not re-opend* if there is a new bug after applying. That is a *new* report, for a *new* bug (the report then will of course refrence the faulty closed report). Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). And Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible. We will see at the end what was the better Idea ;-) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

another point why the down cyan arrow is not a down cyan arrow with a down orange arrow? (may be this is ugly but it would be more consistent). Stef

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

You know I would really like to see if this is worth pressing the ? So I miss the pane showing the comment under the class def. May be a good way also would be to have the question mark with a different color when there is a comment. David we are starting to use manifesto for package so it would be also great to show them. Stef

Sept. 29, 2008

[Pharo-project] Fwd: Strange bug

by StÃ©phane Ducasse

> > > > Hi > > ImageSegment discoverActiveClasses. > is cool and it lets you (by swapping method dict behind your back) > knowing which classes > have been involved in a certain action. > > as follow > Now ImageSegment discoverActiveClasses. > -- do something typical -- > ImageSegment activeClasses size printString , ' classes were active > out of ' , > Smalltalk allClasses size printString. > > Now if following > recoverFromMDFaultWithTrace > > you put > > Smalltalk at: #MDFaultDict put: Dictionary new. > > you get a strange error, tell you that there is syntax error > > Stef > > >

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Lukas Renggli

> > One quick suggestion: classes without a comment need to have an icon, and > really really ugly one, for obvious reason: to get rid of it by writing a > comment ASAP :) > > Indeed, this is something we should add. The reason to not add it so far > was that almost every class would get this icon in most packages. ;) > But we will prepare an icon for it. Please don't add such an icon. This is the most horrible thing in VisualWorks, I always disable it as a first action. There will always be tons of classes in the system that have not been commented and that you don't want to comment, because this is not your library. Nothing will change that. Adding another icon there will just add a horrible noise and is totally orthogonal to the kind-icon that classes already have. Again (as I did for the method icons) I vote not to mix different concerns in a single icon. If really needed, add an exclamation mark to the question mark button for example. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Damien Cassou

On Mon, Sep 29, 2008 at 3:31 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > In that case, how can I load OB? ScriptLoader new universalInstaller universe install: 'OB-Enhancements' If it does not install the very latest version, it's because David does not think it is ready yet. You can still update using monticello if you want. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Alexandre Bergel

> Hi Alex. You should stop doing that manually. I already maintain the > universe version. Please update your method to look like > ScriptLoader>>installingRB. Moreover, future pharo releases will > contain OB. Excellent! In that case, how can I load OB? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Damien Cassou

On Mon, Sep 29, 2008 at 2:25 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > I made a new version of Scriptloader that reflect the new version of OB Hi Alex. You should stop doing that manually. I already maintain the universe version. Please update your method to look like ScriptLoader>>installingRB. Moreover, future pharo releases will contain OB. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

Hi Janko, > One quick suggestion: classes without a comment need to have an icon, > and really really ugly one, for obvious reason: to get rid of it by > writing a comment ASAP :) Indeed, this is something we should add. The reason to not add it so far was that almost every class would get this icon in most packages. ;) But we will prepare an icon for it. David > David RÃ¶thlisberger wrote: >> Hi there, >> >> taking the suggestions from the "On icons" thread, I have now changed >> and extended >> the icons in columns like this: >> >> - Removed icons for extension methods ('+'), instead use italic font >> for the method >> name label if it's a extension method and additionally red color if >> it's an override >> (as Lukas suggested) >> >> - Use new icons for abstract method and super send (credits to Stef >> who did the hard >> work of drawing them). >> The new icons make clear whether an abstract method or a method >> sending super is >> redefined in subclasses or not (they get an additional triangle >> pointing down if they >> are redefined). >> For a complete list of supported icons see: >> http://smallwiki.unibe.ch/hermion/icons/ >> There are still some icons missing for rare situations, if someone >> volunteers to draw >> them, we'd be happy. ;) >> >> - Explaining labels for all icons (keep the mouse over them) >> >> - Most icons are clickable: Clicking on a super send icon brings you >> to the method in >> the superclass, clicking on a triangle down icon brings you to the >> overridding method >> in the subclass or gives you a list of candidates if there are several >> sub-implementations. >> This I consider as a very convenient extension. >> >> - Classes or Traits can implement the method #browserIcon (answering a >> symbol for the >> icon name) to define the icon they will get in the class column >> themselves >> >> >> If you have more suggestions or wishes concerning icons (or anything >> else), let me know. >> Current ideas include to introduce icons for trait classes and methods >> (trait methods >> are shown in italic right now, hence somehow conflicting with >> extension methods), or >> to have an icon for methods without any additional implementor. >> I would be interested to know whether you consider these ideas as >> valuable. >> >> >> To load the latest version of OB, you can use this Installer script: >> >> >> Installer wiresong >> project: 'ob'; >> install: 'OmniBrowser-dr.419'; >> install: 'OB-Standard-dr.355'; >> install: 'OB-Morphic-dr.57'; >> install: 'OB-Enhancements-dr.217'. >> >> >> Cheers, >> David > >

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

Hi Bill, thanks for your feedback! We will try to pay attention to the points you mentioned, in particular those concerning color blind people. David > I apologize for not paying more attention to this thread. Visual > feedback in the browser is very much appreciated, and you seem to be > doing a very nice job! Had I been paying attention, I'd have said > things like the following: > > (1) Red is probably not the best choice to have lurking on the screen. > Maroon/purple/clay rose or just about any "muted" or muddy red IMHO is a > much better choice for most things. It might help to add a small amount > of blue to the greens too for the same reason. I recommend trying for > the psychological benefit with as little eye strain potential as > possible. > > (2) For collections, consider something like a circle drawn a few times > from right to left to give an overlapping effect, maybe ... thrown in > there if there is room. > > (3) For exceptions, I like the icon, but two concerns: it might be a > little faint/bland; it might work better if its implied movement were > upward. Dolphin 5 uses an explosion icon in some situations. That > might work well for exceptions and errors. > > (4) Do we have any color blind people among us? IIRC, something around > 12-14% of the population is affected to some degree, so we will > encounter it. The test icons will be lost on some of the more extreme > red/green sufferers. An alternative would be a boxed check, X or ?. > The box (or other border shape) being the suggestion of the test, and > the symbol indicating the state. It is fine to add color too, but we > should give the red/green crowd a way to see what is going on. > > > Not meaning to jab anyone in the eye, the Installer script is just the > kind of thing I'd hope to be able to exchange in situations like this. > I do not care so much that it is Installer that we use, but _something_ > that can cope with the various publication methods and cope with the > details is much needed. > > Bill

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Alexandre Bergel

I made a new version of Scriptloader that reflect the new version of OB ScriptLoader-AlexandreBergel.516 is now in the Pharo rep (and not PharoInBox). Cheers, Alexandre On 29 Sep 2008, at 11:36, David RÃ¶thlisberger wrote: > Hi there, > > taking the suggestions from the "On icons" thread, I have now > changed and extended > the icons in columns like this: > > - Removed icons for extension methods ('+'), instead use italic font > for the method > name label if it's a extension method and additionally red color if > it's an override > (as Lukas suggested) > > - Use new icons for abstract method and super send (credits to Stef > who did the hard > work of drawing them). > The new icons make clear whether an abstract method or a method > sending super is > redefined in subclasses or not (they get an additional triangle > pointing down if they > are redefined). > For a complete list of supported icons see: http://smallwiki.unibe.ch/hermion/icons/ > There are still some icons missing for rare situations, if someone > volunteers to draw > them, we'd be happy. ;) > > - Explaining labels for all icons (keep the mouse over them) > > - Most icons are clickable: Clicking on a super send icon brings you > to the method in > the superclass, clicking on a triangle down icon brings you to the > overridding method > in the subclass or gives you a list of candidates if there are several > sub-implementations. > This I consider as a very convenient extension. > > - Classes or Traits can implement the method #browserIcon (answering > a symbol for the > icon name) to define the icon they will get in the class column > themselves > > > If you have more suggestions or wishes concerning icons (or anything > else), let me know. > Current ideas include to introduce icons for trait classes and > methods (trait methods > are shown in italic right now, hence somehow conflicting with > extension methods), or > to have an icon for methods without any additional implementor. > I would be interested to know whether you consider these ideas as > valuable. > > > To load the latest version of OB, you can use this Installer script: > > > Installer wiresong > project: 'ob'; > install: 'OmniBrowser-dr.419'; > install: 'OB-Standard-dr.355'; > install: 'OB-Morphic-dr.57'; > install: 'OB-Enhancements-dr.217'. > > > Cheers, > David > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

this is good point I shared my office with two daltonians So we should come up with a nice set of icons. Stef On Sep 29, 2008, at 1:33 PM, Stefan Schmiedl wrote: > On Mon, 29 Sep 2008 07:03:39 -0400 > "Bill Schwab" <BSchwab(a)anest.ufl.edu> wrote: > >> (4) Do we have any color blind people among us? > > http://www.vischeck.com/vischeck/ > > s. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Stefan Schmiedl

On Mon, 29 Sep 2008 07:03:39 -0400 "Bill Schwab" <BSchwab(a)anest.ufl.edu> wrote: > (4) Do we have any color blind people among us? http://www.vischeck.com/vischeck/ s.

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Bill Schwab

I apologize for not paying more attention to this thread. Visual feedback in the browser is very much appreciated, and you seem to be doing a very nice job! Had I been paying attention, I'd have said things like the following: (1) Red is probably not the best choice to have lurking on the screen. Maroon/purple/clay rose or just about any "muted" or muddy red IMHO is a much better choice for most things. It might help to add a small amount of blue to the greens too for the same reason. I recommend trying for the psychological benefit with as little eye strain potential as possible. (2) For collections, consider something like a circle drawn a few times from right to left to give an overlapping effect, maybe ... thrown in there if there is room. (3) For exceptions, I like the icon, but two concerns: it might be a little faint/bland; it might work better if its implied movement were upward. Dolphin 5 uses an explosion icon in some situations. That might work well for exceptions and errors. (4) Do we have any color blind people among us? IIRC, something around 12-14% of the population is affected to some degree, so we will encounter it. The test icons will be lost on some of the more extreme red/green sufferers. An alternative would be a boxed check, X or ?. The box (or other border shape) being the suggestion of the test, and the symbol indicating the state. It is fine to add color too, but we should give the red/green crowd a way to see what is going on. Not meaning to jab anyone in the eye, the Installer script is just the kind of thing I'd hope to be able to exchange in situations like this. I do not care so much that it is Installer that we use, but _something_ that can cope with the various publication methods and cope with the details is much needed. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Janko MivÅ¡ek

David, Very nice indeed! One quick suggestion: classes without a comment need to have an icon, and really really ugly one, for obvious reason: to get rid of it by writing a comment ASAP :) Janko David RÃ¶thlisberger wrote: > Hi there, > > taking the suggestions from the "On icons" thread, I have now changed > and extended > the icons in columns like this: > > - Removed icons for extension methods ('+'), instead use italic font for > the method > name label if it's a extension method and additionally red color if it's > an override > (as Lukas suggested) > > - Use new icons for abstract method and super send (credits to Stef who > did the hard > work of drawing them). > The new icons make clear whether an abstract method or a method sending > super is > redefined in subclasses or not (they get an additional triangle pointing > down if they > are redefined). > For a complete list of supported icons see: > http://smallwiki.unibe.ch/hermion/icons/ > There are still some icons missing for rare situations, if someone > volunteers to draw > them, we'd be happy. ;) > > - Explaining labels for all icons (keep the mouse over them) > > - Most icons are clickable: Clicking on a super send icon brings you to > the method in > the superclass, clicking on a triangle down icon brings you to the > overridding method > in the subclass or gives you a list of candidates if there are several > sub-implementations. > This I consider as a very convenient extension. > > - Classes or Traits can implement the method #browserIcon (answering a > symbol for the > icon name) to define the icon they will get in the class column themselves > > > If you have more suggestions or wishes concerning icons (or anything > else), let me know. > Current ideas include to introduce icons for trait classes and methods > (trait methods > are shown in italic right now, hence somehow conflicting with extension > methods), or > to have an icon for methods without any additional implementor. > I would be interested to know whether you consider these ideas as valuable. > > > To load the latest version of OB, you can use this Installer script: > > > Installer wiresong > project: 'ob'; > install: 'OmniBrowser-dr.419'; > install: 'OB-Standard-dr.355'; > install: 'OB-Morphic-dr.57'; > install: 'OB-Enhancements-dr.217'. > > > Cheers, > David -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Alexandre Bergel

This is an excellent news. Cheers, Alexandre On 29 Sep 2008, at 11:36, David RÃ¶thlisberger wrote: > Hi there, > > taking the suggestions from the "On icons" thread, I have now > changed and extended > the icons in columns like this: > > - Removed icons for extension methods ('+'), instead use italic font > for the method > name label if it's a extension method and additionally red color if > it's an override > (as Lukas suggested) > > - Use new icons for abstract method and super send (credits to Stef > who did the hard > work of drawing them). > The new icons make clear whether an abstract method or a method > sending super is > redefined in subclasses or not (they get an additional triangle > pointing down if they > are redefined). > For a complete list of supported icons see: http://smallwiki.unibe.ch/hermion/icons/ > There are still some icons missing for rare situations, if someone > volunteers to draw > them, we'd be happy. ;) > > - Explaining labels for all icons (keep the mouse over them) > > - Most icons are clickable: Clicking on a super send icon brings you > to the method in > the superclass, clicking on a triangle down icon brings you to the > overridding method > in the subclass or gives you a list of candidates if there are several > sub-implementations. > This I consider as a very convenient extension. > > - Classes or Traits can implement the method #browserIcon (answering > a symbol for the > icon name) to define the icon they will get in the class column > themselves > > > If you have more suggestions or wishes concerning icons (or anything > else), let me know. > Current ideas include to introduce icons for trait classes and > methods (trait methods > are shown in italic right now, hence somehow conflicting with > extension methods), or > to have an icon for methods without any additional implementor. > I would be interested to know whether you consider these ideas as > valuable. > > > To load the latest version of OB, you can use this Installer script: > > > Installer wiresong > project: 'ob'; > install: 'OmniBrowser-dr.419'; > install: 'OB-Standard-dr.355'; > install: 'OB-Morphic-dr.57'; > install: 'OB-Enhancements-dr.217'. > > > Cheers, > David > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

this is cool! Works well. Stef > Hi there, > > taking the suggestions from the "On icons" thread, I have now > changed and extended > the icons in columns like this: > > - Removed icons for extension methods ('+'), instead use italic font > for the method > name label if it's a extension method and additionally red color if > it's an override > (as Lukas suggested) > > - Use new icons for abstract method and super send (credits to Stef > who did the hard > work of drawing them). > The new icons make clear whether an abstract method or a method > sending super is > redefined in subclasses or not (they get an additional triangle > pointing down if they > are redefined). > For a complete list of supported icons see: http://smallwiki.unibe.ch/hermion/icons/ > There are still some icons missing for rare situations, if someone > volunteers to draw > them, we'd be happy. ;) > > - Explaining labels for all icons (keep the mouse over them) > > - Most icons are clickable: Clicking on a super send icon brings you > to the method in > the superclass, clicking on a triangle down icon brings you to the > overridding method > in the subclass or gives you a list of candidates if there are several > sub-implementations. > This I consider as a very convenient extension. > > - Classes or Traits can implement the method #browserIcon (answering > a symbol for the > icon name) to define the icon they will get in the class column > themselves > > > If you have more suggestions or wishes concerning icons (or anything > else), let me know. > Current ideas include to introduce icons for trait classes and > methods (trait methods > are shown in italic right now, hence somehow conflicting with > extension methods), or > to have an icon for methods without any additional implementor. > I would be interested to know whether you consider these ideas as > valuable. > > > To load the latest version of OB, you can use this Installer script: > > > Installer wiresong > project: 'ob'; > install: 'OmniBrowser-dr.419'; > install: 'OB-Standard-dr.355'; > install: 'OB-Morphic-dr.57'; > install: 'OB-Enhancements-dr.217'. > > > Cheers, > David > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

[Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

Hi there, taking the suggestions from the "On icons" thread, I have now changed and extended the icons in columns like this: - Removed icons for extension methods ('+'), instead use italic font for the method name label if it's a extension method and additionally red color if it's an override (as Lukas suggested) - Use new icons for abstract method and super send (credits to Stef who did the hard work of drawing them). The new icons make clear whether an abstract method or a method sending super is redefined in subclasses or not (they get an additional triangle pointing down if they are redefined). For a complete list of supported icons see: http://smallwiki.unibe.ch/hermion/icons/ There are still some icons missing for rare situations, if someone volunteers to draw them, we'd be happy. ;) - Explaining labels for all icons (keep the mouse over them) - Most icons are clickable: Clicking on a super send icon brings you to the method in the superclass, clicking on a triangle down icon brings you to the overridding method in the subclass or gives you a list of candidates if there are several sub-implementations. This I consider as a very convenient extension. - Classes or Traits can implement the method #browserIcon (answering a symbol for the icon name) to define the icon they will get in the class column themselves If you have more suggestions or wishes concerning icons (or anything else), let me know. Current ideas include to introduce icons for trait classes and methods (trait methods are shown in italic right now, hence somehow conflicting with extension methods), or to have an icon for methods without any additional implementor. I would be interested to know whether you consider these ideas as valuable. To load the latest version of OB, you can use this Installer script: Installer wiresong project: 'ob'; install: 'OmniBrowser-dr.419'; install: 'OB-Standard-dr.355'; install: 'OB-Morphic-dr.57'; install: 'OB-Enhancements-dr.217'. Cheers, David

Sept. 29, 2008

Re: [Pharo-project] How do we manage todos?

by Marcus Denker

On 28.09.2008, at 21:40, StÃ©phane Ducasse wrote: > I would prefer a bugtraker with a tag todo that are not bug fixes. Ok. Then we can split up the one entry that has all the TODOs. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

Re: [Pharo-project] About Network-YM.44.mcz

by Damien Cassou

On Sun, Sep 28, 2008 at 9:44 PM, Yann Monclair <yann.monclair(a)smalltalk.fr> wrote: > I found a few senders in Universe, but I couldn't publish the changes, the > project is ReadOnly and I haven't time to chase up the admins about it yet. Philippe and I fixed them. Thanks -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 29, 2008

RE: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside2.9 alphauniverse

by Ramon Leon

> > If it uses overrides, the MC1.5 should be able to uninstall it. > > However > > MC1.5 probably depends upon it. So you are probably stuck there. > > > > keep in mind that uninstall can not work in general... > overrides are evil. My feelings exactly. I don't want an MC that tries to be smart, I want packages who's authors recognize that overrides are pure evil and don't use overrides. If the built in method doesn't work for you, then create an extension that does with a prefix that suites your package. It might not be pretty, but it's better that changing core code and breaking other peoples packages. Ramon Leon http://onsmalltalk.com

Sept. 29, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

Marcus Denker wrote: > > On 28.09.2008, at 22:16, Keith Hodges wrote: > >> >>> considering that mantis now has >1000 open entries... >>> >>> Marcus >>> >> ?? >> >> The difference being, that we dont create a mantis entry so that it can >> languish unused. We use mantis as a vessel for holding snippets of code >> and collecting feedback. >> >> Installer collects a list of fixes applied, and Sake/Tasks has a task >> for documenting those fixes in the image. >> > > So fixes are not integrated into the image anymore and the report then > closed? When a release image is released the fixes are integrated into the image as normal, and can be closed or marked "fixed". Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something. Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer. This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team. > What I don't understand with the use of Installer with mantis entries: > From my > experience from 3.6 to 3.9, there is quite some dependency between fixes. Nothing is automatic, if you or some script loads the wrong fix in the wrong order then that is a problem. > Thas means: two fixes are overriding the same method, to harvest both, > the second > one applied can not be added but needs to be redone to take the > changes of the first > into account. > > I really can't imagine how you can automatically apply changesets from > the bugtracker Nothing is automatic. > > to build "your own release". This just can't work with all the > dependencies between > fixes. However, the old way, fixes are applied to a moving target, since the alpha image is continuously being updated. With this approach fixes applied to 3.10 (a fixed target) are used to create a 3.11 unstable until the combination of fixes is deemed "stable" Keith

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by Norbert Hartl

On Sun, 2008-09-28 at 21:41 +0200, StÃ©phane Ducasse wrote: > Now it is working for me. > For me, too. Thanks! Norbert

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Marcus Denker

On 28.09.2008, at 22:16, Keith Hodges wrote: > >> considering that mantis now has >1000 open entries... >> >> Marcus >> > ?? > > The difference being, that we dont create a mantis entry so that it > can > languish unused. We use mantis as a vessel for holding snippets of > code > and collecting feedback. > > Installer collects a list of fixes applied, and Sake/Tasks has a task > for documenting those fixes in the image. > So fixes are not integrated into the image anymore and the report then closed? What I don't understand with the use of Installer with mantis entries: From my experience from 3.6 to 3.9, there is quite some dependency between fixes. Thas means: two fixes are overriding the same method, to harvest both, the second one applied can not be added but needs to be redone to take the changes of the first into account. I really can't imagine how you can automatically apply changesets from the bugtracker to build "your own release". This just can't work with all the dependencies between fixes. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

> considering that mantis now has >1000 open entries... > > Marcus > ?? The difference being, that we dont create a mantis entry so that it can languish unused. We use mantis as a vessel for holding snippets of code and collecting feedback. Installer collects a list of fixes applied, and Sake/Tasks has a task for documenting those fixes in the image. Keith

Sept. 28, 2008

Re: [Pharo-project] About Network-YM.44.mcz

by StÃ©phane Ducasse

thanks. Stef On Sep 28, 2008, at 9:44 PM, Yann Monclair wrote: > I replaced the only sender I found in the base Pharo image > (HttpUrl>>#askNamePassword). > > I found a few senders in Universe, but I couldn't publish the > changes, the project is ReadOnly and I haven't time to chase up the > admins about it yet. > > I'll send my agreement next week. > > Cheers, > > Yann > > On Sun, Sep 28, 2008 at 8:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > But what did you get from the senders of Url>>#toText? > Because indeed Url>>#toText will be removed. > > Ok I will check what you did and wait for your agreement :) > > Stef > > > On Sep 28, 2008, at 9:09 PM, Yann Monclair wrote: > > Hi list, > > I figured I'd explain my commit here, since I don't know how you > handle your issue tracker. > > While I was loading some code in my image (Universes iirc), I got a > lot of warnings pop up, about Url>>#toText being deprecated. > After taking a look at it, I saw that the deprecation comment > recommended using instead Url>>#asText. Which I tried, but it broke > most of the SUnits and also the expected behaviour. > Looking at the code, I saw that Url>>#toText simply did ^self > asString, when Url>>#asText does ^self asString asText. The semantic > leap between Text and String is too big (imo) to force that change > on users. > I thought it would be better to replace the deprecation comment to > recommend replacing the obsolote Url>>#toText by Url>>#asString > (which is what this method actually does). > > I would rather have removed the method, since it has been marked for > obsolete for more than 3 years now! But I don't know what the > approach is to deleting methods, and how to communicate to people > that this isn't a missing method but an intentional removal. > > I hope this helps understand this version. > > Cheers, > > Yann > _______________________________________________ > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2008

Re: [Pharo-project] About Network-YM.44.mcz

by Yann Monclair

I replaced the only sender I found in the base Pharo image (HttpUrl>>#askNamePassword). I found a few senders in Universe, but I couldn't publish the changes, the project is ReadOnly and I haven't time to chase up the admins about it yet. I'll send my agreement next week. Cheers, Yann On Sun, Sep 28, 2008 at 8:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > But what did you get from the senders of Url>>#toText? > Because indeed Url>>#toText will be removed. > > Ok I will check what you did and wait for your agreement :) > > Stef > > > On Sep 28, 2008, at 9:09 PM, Yann Monclair wrote: > > Hi list, >> >> I figured I'd explain my commit here, since I don't know how you handle >> your issue tracker. >> >> While I was loading some code in my image (Universes iirc), I got a lot of >> warnings pop up, about Url>>#toText being deprecated. >> After taking a look at it, I saw that the deprecation comment recommended >> using instead Url>>#asText. Which I tried, but it broke most of the SUnits >> and also the expected behaviour. >> Looking at the code, I saw that Url>>#toText simply did ^self asString, >> when Url>>#asText does ^self asString asText. The semantic leap between Text >> and String is too big (imo) to force that change on users. >> I thought it would be better to replace the deprecation comment to >> recommend replacing the obsolote Url>>#toText by Url>>#asString (which is >> what this method actually does). >> >> I would rather have removed the method, since it has been marked for >> obsolete for more than 3 years now! But I don't know what the approach is to >> deleting methods, and how to communicate to people that this isn't a missing >> method but an intentional removal. >> >> I hope this helps understand this version. >> >> Cheers, >> >> Yann >> _______________________________________________ >> 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 >

Sept. 28, 2008

Re: [Pharo-project] How do we manage todos?

by Tudor Girba

You can always use the built in Enhancement tag. Cheers, Doru On Sep 28, 2008, at 9:40 PM, StÃ©phane Ducasse wrote: > I would prefer a bugtraker with a tag todo that are not bug fixes. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com www.tudorgirba.com/blog "Problem solving efficiency grows with the abstractness level of problem understanding."

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

Now it is working for me. Stef

Sept. 28, 2008

[Pharo-project] How do we manage todos?

by StÃ©phane Ducasse

I would prefer a bugtraker with a tag todo that are not bug fixes. Stef

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by StÃ©phane Ducasse

I sent an email a while back on checkeing Kernel Extensions. I know added an entries in the bgtracker. Stef On Sep 28, 2008, at 7:01 PM, Keith Hodges wrote: > >> Now, the code may work perfectly fine, and Keith's done a lot of >> work, but >> it's just not community friendly code. A package should have a clear >> responsibility, few dependencies, not too many extensions, no >> overrides if >> at all possible, and must install and uninstall cleanly without >> hosing my >> system. If it doesn't meet those criteria, I don't consider it >> safe to even >> experiment with. >> >> Ramon Leon >> http://onsmalltalk.com >> > If it uses overrides, the MC1.5 should be able to uninstall it. > However > MC1.5 probably depends upon it. So you are probably stuck there. > > Kernel-Extensions are not supposed to be removed, they are supposed to > be integrated into the main image. We have two ways of doing this. > > We are slowly breaking it down into bug fixes on mantis, however these > are changesets and are not removeable either. > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by StÃ©phane Ducasse

On Sep 28, 2008, at 6:50 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Hi Damien >> >> I can give you an explanation but keith will not like it. >> Note that I like the ideas that he is pushing and that I started to >> write a chapter for the next book on installer. >> - Keith idea that everybody can build its own distribution is not >> something that everybody like > It is what the community has been talking about and doing for the past > few years. I started by providing a Seaside-Magma-Pier image, now > instead I can provide a Seaside-Magma-Pier entry in Sake/Packages > which > will work in any image that the squeak community typically uses. > > There are people now building one-click Pier images, and one click > Seaside images, but this is going back to doing it the old way, and it > will not be generally useful, since every major project builds their > own > image. For example Gjallar, Sophie, WebStore (my Project) etc. >> - For example I would like to have a real look at MC1.6 but the >> message around it is blurry > I am sure that Matthew will be able to make the message clearer, in > the > meantime please do not overlook the months of work that have gone into > MC1.5. I will look do not worry. :) I'm just slow > >> I tried LFP and it broke on me. > That was simply the wiki complaining that it was being hit too hard. > LPF > has been working for many people for months, you just got unlucky. It > may be fixed. >> - I like installer but when I look at the code I would like to >> refactor it. > Of course, Installer is designed with that future refactoring in mind. > Keeping everything in one class was an initial design goal for the > purpose of "looking slim" and gaining acceptance. Now that Installer > has > gained some acceptance it may be time to tidy up the code. I still > like > the one class feature, but at some point the maintainability will > suffer > too much. Ok I could do a pass on that then. > >> - There is no document in a nice format that explain why and how >> (i'm fixing that for installer > Installer has a class comment and this is available on the squeak > wiki, > and http://installer.pbwiki.com/Installer what more do you want? >> and I was waiting because I will refactor it else I do not publish >> the chapter but I did not want to >> insult keith since this is not the point since I like installer). >> - unknown is strnage :) >> - So if you want to help me I would love to have a >> - Installer code refactored >> - Installer chapter >> - Sake (have a look at the code) >> - Sake Chapter for the book > Sounds good to me! > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2008

Re: [Pharo-project] About Network-YM.44.mcz

by StÃ©phane Ducasse

But what did you get from the senders of Url>>#toText? Because indeed Url>>#toText will be removed. Ok I will check what you did and wait for your agreement :) Stef On Sep 28, 2008, at 9:09 PM, Yann Monclair wrote: > Hi list, > > I figured I'd explain my commit here, since I don't know how you > handle your issue tracker. > > While I was loading some code in my image (Universes iirc), I got a > lot of warnings pop up, about Url>>#toText being deprecated. > After taking a look at it, I saw that the deprecation comment > recommended using instead Url>>#asText. Which I tried, but it broke > most of the SUnits and also the expected behaviour. > Looking at the code, I saw that Url>>#toText simply did ^self > asString, when Url>>#asText does ^self asString asText. The semantic > leap between Text and String is too big (imo) to force that change > on users. > I thought it would be better to replace the deprecation comment to > recommend replacing the obsolote Url>>#toText by Url>>#asString > (which is what this method actually does). > > I would rather have removed the method, since it has been marked for > obsolete for more than 3 years now! But I don't know what the > approach is to deleting methods, and how to communicate to people > that this isn't a missing method but an intentional removal. > > I hope this helps understand this version. > > Cheers, > > Yann > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

argh I have to check.... sorry Stef On Sep 28, 2008, at 9:26 PM, StÃ©phane Ducasse wrote: > Thanks I will fix that. > This is strange since I tested it on my working Moose image. > > Stef > > On Sep 28, 2008, at 8:43 PM, Norbert Hartl wrote: > >> In 10082 the script is buggy. script174 contains a line >> with only >> >> .mcz >> >> and one line with an archive >> >> Pinesoft-Removals-EToys-stephane.ducasse.1.mcz >> >> that is not in the repository. >> >> Norbert >> >> >> _______________________________________________ >> 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 >

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

normally this is fixed. I will try to reload it. Stef On Sep 28, 2008, at 8:43 PM, Norbert Hartl wrote: > In 10082 the script is buggy. script174 contains a line > with only > > .mcz > > and one line with an archive > > Pinesoft-Removals-EToys-stephane.ducasse.1.mcz > > that is not in the repository. > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

Thanks I will fix that. This is strange since I tested it on my working Moose image. Stef On Sep 28, 2008, at 8:43 PM, Norbert Hartl wrote: > In 10082 the script is buggy. script174 contains a line > with only > > .mcz > > and one line with an archive > > Pinesoft-Removals-EToys-stephane.ducasse.1.mcz > > that is not in the repository. > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Marcus Denker

On 28.09.2008, at 19:01, Keith Hodges wrote: > >> Now, the code may work perfectly fine, and Keith's done a lot of >> work, but >> it's just not community friendly code. A package should have a clear >> responsibility, few dependencies, not too many extensions, no >> overrides if >> at all possible, and must install and uninstall cleanly without >> hosing my >> system. If it doesn't meet those criteria, I don't consider it >> safe to even >> experiment with. >> >> Ramon Leon >> http://onsmalltalk.com >> > If it uses overrides, the MC1.5 should be able to uninstall it. > However > MC1.5 probably depends upon it. So you are probably stuck there. > keep in mind that unsinstall can not work in gereral... overrides are evil. So just think you installed some packate that has an override. Now you install a second, that overrides again. Ups, broken. So we change the new override to take into account the change done in the first. Now when de-installing the first package, what should happen? > Kernel-Extensions are not supposed to be removed, they are supposed to > be integrated into the main image. We have two ways of doing this. > > We are slowly breaking it down into bug fixes on mantis, considering that mantis now has >1000 open entries... Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 28, 2008

[Pharo-project] About Network-YM.44.mcz

by Yann Monclair

Hi list, I figured I'd explain my commit here, since I don't know how you handle your issue tracker. While I was loading some code in my image (Universes iirc), I got a lot of warnings pop up, about Url>>#toText being deprecated. After taking a look at it, I saw that the deprecation comment recommended using instead Url>>#asText. Which I tried, but it broke most of the SUnits and also the expected behaviour. Looking at the code, I saw that Url>>#toText simply did ^self asString, when Url>>#asText does ^self asString asText. The semantic leap between Text and String is too big (imo) to force that change on users. I thought it would be better to replace the deprecation comment to recommend replacing the obsolote Url>>#toText by Url>>#asString (which is what this method actually does). I would rather have removed the method, since it has been marked for obsolete for more than 3 years now! But I don't know what the approach is to deleting methods, and how to communicate to people that this isn't a missing method but an intentional removal. I hope this helps understand this version. Cheers, Yann

Sept. 28, 2008

[Pharo-project] Update 10082

by Norbert Hartl

In 10082 the script is buggy. script174 contains a line with only .mcz and one line with an archive Pinesoft-Removals-EToys-stephane.ducasse.1.mcz that is not in the repository. Norbert

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

> > 100% agree. This is why I'm saying that we want to integrate extensions > or reject them. > >> If it doesn't meet those criteria, I don't consider it safe to even >> experiment with. However, if the base system doesnt support loading and unloading of things in the first place, its a bit unfair to expect a package to be unloadable, when its purpose is to fix the base package so as to be able to support loading and unloading. Once everything we use has LPF (or equivalent) then it is reasonable to expect loading an unloading to work. I admit that Kernel-Extensions has become bloated with more than just the minimum, however it has the advantage of being version controlled which changesets are not. Keith

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

> Now, the code may work perfectly fine, and Keith's done a lot of work, but > it's just not community friendly code. A package should have a clear > responsibility, few dependencies, not too many extensions, no overrides if > at all possible, and must install and uninstall cleanly without hosing my > system. If it doesn't meet those criteria, I don't consider it safe to even > experiment with. > > Ramon Leon > http://onsmalltalk.com > If it uses overrides, the MC1.5 should be able to uninstall it. However MC1.5 probably depends upon it. So you are probably stuck there. Kernel-Extensions are not supposed to be removed, they are supposed to be integrated into the main image. We have two ways of doing this. We are slowly breaking it down into bug fixes on mantis, however these are changesets and are not removeable either. Keith

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Keith Hodges

> I agree that Universes is not the ultimate solution, but at least it > seems to work reasonably well. I like the declarative way to > specifying package dependencies. > > Cheers, > Lukas > > Sake/Packages has been changed to be declarative for the most part, though it isn't restricted to that. Keith

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Keith Hodges

StÃ©phane Ducasse wrote: > Hi Damien > > I can give you an explanation but keith will not like it. > Note that I like the ideas that he is pushing and that I started to > write a chapter for the next book on installer. > - Keith idea that everybody can build its own distribution is not > something that everybody like It is what the community has been talking about and doing for the past few years. I started by providing a Seaside-Magma-Pier image, now instead I can provide a Seaside-Magma-Pier entry in Sake/Packages which will work in any image that the squeak community typically uses. There are people now building one-click Pier images, and one click Seaside images, but this is going back to doing it the old way, and it will not be generally useful, since every major project builds their own image. For example Gjallar, Sophie, WebStore (my Project) etc. > - For example I would like to have a real look at MC1.6 but the > message around it is blurry I am sure that Matthew will be able to make the message clearer, in the meantime please do not overlook the months of work that have gone into MC1.5. > I tried LFP and it broke on me. That was simply the wiki complaining that it was being hit too hard. LPF has been working for many people for months, you just got unlucky. It may be fixed. > - I like installer but when I look at the code I would like to > refactor it. Of course, Installer is designed with that future refactoring in mind. Keeping everything in one class was an initial design goal for the purpose of "looking slim" and gaining acceptance. Now that Installer has gained some acceptance it may be time to tidy up the code. I still like the one class feature, but at some point the maintainability will suffer too much. > - There is no document in a nice format that explain why and how > (i'm fixing that for installer Installer has a class comment and this is available on the squeak wiki, and http://installer.pbwiki.com/Installer what more do you want? > and I was waiting because I will refactor it else I do not publish > the chapter but I did not want to > insult keith since this is not the point since I like installer). > - unknown is strnage :) > - So if you want to help me I would love to have a > - Installer code refactored > - Installer chapter > - Sake (have a look at the code) > - Sake Chapter for the book Sounds good to me! Keith

Sept. 28, 2008

Re: [Pharo-project] who is YM

by StÃ©phane Ducasse

Hi Yann Yann you should - sign the agreement - then explain your commits because else we cannot really guess and this is important that other people can follow and may be contradict you. Stef On Sep 28, 2008, at 6:11 PM, Yann Monclair wrote: > Sorry, I'll make sure I set my fullname in my new images. > > Cheers, > > Yann > > On Sun, Sep 28, 2008 at 11:39 AM, Damien Pollet <damien.pollet(a)gmail.com > > wrote: > Yann I guess > > On Fri, Sep 26, 2008 at 9:12 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > because there is a package Network YM 44 > > > > Please please avoid to use initials. > > > > Stef > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > 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

Sept. 28, 2008

Re: [Pharo-project] who is YM

by Yann Monclair

Sorry, I'll make sure I set my fullname in my new images. Cheers, Yann On Sun, Sep 28, 2008 at 11:39 AM, Damien Pollet <damien.pollet(a)gmail.com>wrote: > Yann I guess > > On Fri, Sep 26, 2008 at 9:12 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > because there is a package Network YM 44 > > > > Please please avoid to use initials. > > > > Stef > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Sept. 28, 2008

[Pharo-project] [ANN] 10082 More etoy cleaning

by StÃ©phane Ducasse

Hi all I'm slowing going over gary's fixes and cleaning etoy. Etoy cleaning from gary (continued) Removed UndefinedObjectTest>>testNewTileMorphRepresentative Removed BooleanTest>>testNewTileMorphRepresentative Removed BookMorph>>chooseAndRevertToVersion Removed BookMorph>>revertToCheckpoint: secsSince1901 BookMorph>>installRollBackButtons BookMorph>>methodHolderVersions BookMorph>>methodHolders BookMoprh>>goToPageMorph: transitionSpec: runTransitionScripts: BookMorph>>goToPageMorph: transitionSpec: TabbedPalette>>selectTab: cleaned Removed TabbedPalette>>becomeStandPalette Removed>>currentPlayerDo: and fixed sender EncodedCharSet fixed initialize stef

Sept. 28, 2008

Re: [Pharo-project] what about squeakPage

by StÃ©phane Ducasse

:) I'm somehow sad to see all this good energy turned out that way. I'm going over the etoy removal. Marcus do yo have a chance to put back the mneu items windows (a bit cleaned up) and changes (a bit clean up too). Because recovering from changes is important. Stef On Sep 28, 2008, at 4:02 PM, Marcus Denker wrote: > > On 28.09.2008, at 15:27, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I was browsing some etoy cleans of gary and I found somewhere >> sqPage and SqueakPage. >> Apparently we can save on disc a bookmorph. >> Any ideas if this is working/useful/fun? > > I think this is partly not used anymore: now projects are stored to > disk, the SqueakPage > was from before that, I think. > > I would remove it. And the whole bookmorph, too. ;-) > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2008

Re: [Pharo-project] what about squeakPage

by Marcus Denker

On 28.09.2008, at 15:27, StÃ©phane Ducasse wrote: > Hi guys > > I was browsing some etoy cleans of gary and I found somewhere sqPage > and SqueakPage. > Apparently we can save on disc a bookmorph. > Any ideas if this is working/useful/fun? I think this is partly not used anymore: now projects are stored to disk, the SqueakPage was from before that, I think. I would remove it. And the whole bookmorph, too. ;-) -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside2.9alphauniverse

by Bill Schwab

Damien, Sounds good. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 09/28/08 9:16 AM >>> On Sun, Sep 28, 2008 at 3:07 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, > > Now I'm confused :) If installing Seaside is easy, then the web image > is not all that necessary, agreed. With PolyMorph in Pharo, every image > gets better. No worries so far. > > You said "we want one image for Pharo." That is probably a good goal. > Will the RB go into Pharo, or will you continue to produce the developer > images? Yes, RB will be part of the official Pharo release and I won't generate specific pharo-dev images anymore. The list of packages in Pharo is maintained at: http://code.google.com/p/pharo/wiki/Packages -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 28, 2008

[Pharo-project] what about squeakPage

by StÃ©phane Ducasse

Hi guys I was browsing some etoy cleans of gary and I found somewhere sqPage and SqueakPage. Apparently we can save on disc a bookmorph. Any ideas if this is working/useful/fun? Stef

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9alphauniverse

by Damien Cassou

On Sun, Sep 28, 2008 at 3:07 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, > > Now I'm confused :) If installing Seaside is easy, then the web image > is not all that necessary, agreed. With PolyMorph in Pharo, every image > gets better. No worries so far. > > You said "we want one image for Pharo." That is probably a good goal. > Will the RB go into Pharo, or will you continue to produce the developer > images? Yes, RB will be part of the official Pharo release and I won't generate specific pharo-dev images anymore. The list of packages in Pharo is maintained at: http://code.google.com/p/pharo/wiki/Packages -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9alphauniverse

by Bill Schwab

Damien, Now I'm confused :) If installing Seaside is easy, then the web image is not all that necessary, agreed. With PolyMorph in Pharo, every image gets better. No worries so far. You said "we want one image for Pharo." That is probably a good goal. Will the RB go into Pharo, or will you continue to produce the developer images? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 09/28/08 5:38 AM >>> Hi Bill, I'm not sure I understand your email completly. Please tell me if it is not the case. On Sat, Sep 27, 2008 at 5:44 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, I suspect you put a lot of work into preparing your images, so please do not view this as anything other than gratitude driving some suggestions. With proper selection of browser and (sorry<g>) deactivating eCompletion, I very much enjoy your web image as a starting point. Whether I continue using it will depend on how hard it is to install Polymorph and the RB vs. Seaside and friends. Polymorph is going to be included in all Pharo images so you don't have to worry. RB as been in all my images from the beginning and will continue to be. I think I will stop generating web images for Pharo because we want only one image for Pharo. I will try to find a way to make installing Seaside easy. > Call me demanding, I want it all :) Installer can probably (either now or with some refinement) reduce Polymorph (which appears to be on its way into the Pharo base anyway???) and Seaside to one-liners in a script. Ditto cryptography. Add some lines to load .cs or whatever files I create on my own, and I should be able to download an image, and then run one script that builds the new image. > > I will stop short of asking you to manually keep up with the small releases, as I probably would end up waiting for the October release before building a new image. It would however be great to either reduce what you do to a simple script, or have it aggressively track updates once Pharo is officially released. I'm sorry but I do not understand this paragraph. > >From a gradually decreasing distance at least, Installer looks like it is trying to fill a gap. As always, I would like to see Pharo sprout an ability to apply multiple categories per method; Dolphin has done that from (almost?) the beginning, and it is quite addictive. My point being that however clever, systems that take the one available category to package methods make the restriction all the more obvious. > > I hope that makes some sense. Thanks to all for what is shaping up to be a nice system! > > Bill > > >

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Damien Cassou

On Sun, Sep 28, 2008 at 12:36 PM, <bryce(a)kampjes.demon.co.uk> wrote: > Damien Cassou writes: > > Polymorph is going to be included in all Pharo images so you don't > > have to worry. RB as been in all my images from the beginning and will > > continue to be. I think I will stop generating web images for Pharo > > because we want only one image for Pharo. I will try to find a way to > > make installing Seaside easy. > > I install Seaside into squeak-dev images using Universes, it's a > one-click install. It won't be for long, see the first post of this thread. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 28, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by bryce＠kampjes.demon.co.uk

bryce(a)kampjes.demon.co.uk writes: > Marcus Denker writes: > > > > On 24.09.2008, at 23:16, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > > For now, I just used the vm from the seaside package and copied all th > > dll's in > > from the freetype package. This seems to work... > > > > The recompiling gets really more important as soon as we go for > > example for > > Eliot's closure implementation... that I would want to have in as soon > > as possible. > > What platforms do you have to work with? The Linux build now runs. > I've a few loose ends to tidy up. I still haven't finished reviewing > the changes. Sorry, I should have added, I'd prefer not to integrate the image changes. Someone else should be able to do that. Bryce

Sept. 28, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by bryce＠kampjes.demon.co.uk

Marcus Denker writes: > > On 24.09.2008, at 23:16, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > For now, I just used the vm from the seaside package and copied all th > dll's in > from the freetype package. This seems to work... > > The recompiling gets really more important as soon as we go for > example for > Eliot's closure implementation... that I would want to have in as soon > as possible. What platforms do you have to work with? The Linux build now runs. I've a few loose ends to tidy up. I still haven't finished reviewing the changes. Bryce

Sept. 28, 2008

Re: [Pharo-project] who is YM

by Damien Pollet

Yann I guess On Fri, Sep 26, 2008 at 9:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > because there is a package Network YM 44 > > Please please avoid to use initials. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by bryce＠kampjes.demon.co.uk

Damien Cassou writes: > Polymorph is going to be included in all Pharo images so you don't > have to worry. RB as been in all my images from the beginning and will > continue to be. I think I will stop generating web images for Pharo > because we want only one image for Pharo. I will try to find a way to > make installing Seaside easy. I install Seaside into squeak-dev images using Universes, it's a one-click install. Bryce

Sept. 28, 2008

Re: [Pharo-project] Compression question

by Damien Cassou

On Sat, Sep 27, 2008 at 5:59 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > BTW, as further evidence of the accumulated effort, to check the jargon > above, I just fired up an early 3.9 image that was handy, and the > differences are striking! Maybe I do want to lean on Damien for an > updated web image :) Latest Pharo web can always be downloaded from http://code.google.com/p/pharo/wiki/Downloads?tm=2. I will try to generate a new one soon. Bye -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 28, 2008

Re: [Pharo-project] possible TODOs...

by Damien Cassou

On Sun, Sep 21, 2008 at 6:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> - Integrating Monticello commands directly into code browser, in >> right-click menu over packages. This really helps with code management, I >> know that from VW. > > you should use the package browser and ask for improvement because you can > start to do what you want with it. StÃ©phane is right. Just download a Pharo dev image and the default browser has these features. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Damien Cassou

Hi Bill, I'm not sure I understand your email completly. Please tell me if it is not the case. On Sat, Sep 27, 2008 at 5:44 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, I suspect you put a lot of work into preparing your images, so please do not view this as anything other than gratitude driving some suggestions. With proper selection of browser and (sorry<g>) deactivating eCompletion, I very much enjoy your web image as a starting point. Whether I continue using it will depend on how hard it is to install Polymorph and the RB vs. Seaside and friends. Polymorph is going to be included in all Pharo images so you don't have to worry. RB as been in all my images from the beginning and will continue to be. I think I will stop generating web images for Pharo because we want only one image for Pharo. I will try to find a way to make installing Seaside easy. > Call me demanding, I want it all :) Installer can probably (either now or with some refinement) reduce Polymorph (which appears to be on its way into the Pharo base anyway???) and Seaside to one-liners in a script. Ditto cryptography. Add some lines to load .cs or whatever files I create on my own, and I should be able to download an image, and then run one script that builds the new image. > > I will stop short of asking you to manually keep up with the small releases, as I probably would end up waiting for the October release before building a new image. It would however be great to either reduce what you do to a simple script, or have it aggressively track updates once Pharo is officially released. I'm sorry but I do not understand this paragraph. > >From a gradually decreasing distance at least, Installer looks like it is trying to fill a gap. As always, I would like to see Pharo sprout an ability to apply multiple categories per method; Dolphin has done that from (almost?) the beginning, and it is quite addictive. My point being that however clever, systems that take the one available category to package methods make the restriction all the more obvious. > > I hope that makes some sense. Thanks to all for what is shaping up to be a nice system! > > Bill > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> damien.cassou(a)gmail.com 09/26/08 11:03 AM >>> > On Fri, Sep 26, 2008 at 8:26 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> - For example I would like to have a real look at MC1.6 but the >> message around it is blurry > > MC1.6 is not the topic here. > >> I tried LFP and it broke on me. > > It worked fine for me. You may want to try again and send bug report > to Keith who answered all my emails. > >> - I like installer but when I look at the code I would like to refactor it. > > > The code may not be perfect but it works fine. I don't think Keith > would ignore our enhancements to his code. > > >> - There is no document in a nice format that explain why and how (i'm >> fixing that for installer and I was waiting because I will refactor it else I do not publish the chapter but I did not want to insult keith since this is not the point since I like installer). > > > This is not fair. There is "no document in a nice format that > explains" most of the tools you use everyday. But you still use them. > The more people use a tool, the best chance you have to get > documentation. Moreover, Keith and Matthew wrote a lot of things in > pbwiki, squeak wiki and mailing lists. > > >> - unknown is strange :) > > Should not be for us Squeakers and Pharoers. > >> - So if you want to help me I would love to have a >> - Installer code refactored >> - Installer chapter >> - Sake (have a look at the code) >> - Sake Chapter for the book > > I would love that too > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 28, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by StÃ©phane Ducasse

Hi simon This is what I meant. I wanted to understand the problem because when we merge this is important to see the diff. stef On Sep 27, 2008, at 10:07 PM, Simon Kirk wrote: > Hmm, OK, I've had a dig around. > > I tried with a Pharo0.1-10074-oneclick package, and I think I see > what you mean: viewing changes via the MC browser on the package I > attached simply shows the entire method in red - even though if I go > and find the equivalent method in the image it exists and should be > showing changes instead. > > I then tried with a Pharo0.1-PolymorphTT package, as I'm more > familiar with the diff tool from Gary's work. Again, the same problem. > > However, if I load the MCZ into the package, then pick, say, > BrowserCommentTextMorph>>#hidePane and view the versions of the > method, I can then see both the original method (sd 11/20/2005 > 21:26) and Gary's new version, and the differences between the two. > > So, perhaps the problem is that the Monticello browser can't show > you differences between methods when one method is in the image > under one class category, while the one in the Monticello package to > be loaded is under a different one (the method in this case is an > extension, so the method category for #hidePane would change from > "displaying" to "*Pinesoft-Fixes-Misc" > > I hope that makes sense. I would have thought you would want to keep > the original method categories, just keeping the method source from > the MCZ. > > Unfortunately my knowledge of managing such changes falls well short > of knowing how to go about that :( > > Hope this has all made sense and is helpful > Cheers, > S > > On 27 Sep 2008, at 06:58, StÃ©phane Ducasse wrote: > >> >> On Sep 26, 2008, at 10:07 PM, Simon Kirk wrote: >> >>> hi Stef. >>> >>> Hmm, strange. How are you viewing the diffs? If I browse the MCZ >>> in a Monticello browser I see extensions to these classes: >>> >>> BrowserCommentTextMorph >>> BrowserRequestor >>> CanvasCharacterScanner >>> Character >>> ConnectionQueue >>> GrafPort >>> MultiCanvasCharacterScanner >>> NaturalLanguageTranslator >>> Random >>> RemoteString >>> TranscriptStream >>> >>> Is this the diffs you're talking about? If so, I think they're >>> correct. It's possible my rough list below may have missed some >>> changes. >> >> >> I see the same but I cannot see the diff between the changes and >> what is in the image (for example in the merge >> tools I do not (changed) and the like. >> >> Stef >> >>> >>> >>> Cheers, >>> Simon >>> >>> On 26 Sep 2008, at 20:20, StÃ©phane Ducasse wrote: >>> >>>> Simon >>>> >>>> with which machine did you create you mcz? >>>> Because apparently I can see the diffs for other packages. >>>> >>>> Can somebody else check the pinesoft package I put in the >>>> pharoInbox? >>>> >>>> Stef >>>> >>>> >>>> >>>>> Hi all. >>>>> >>>>> Gary and I decided we ought to give out an MCZ of our fixes that >>>>> we've put together over the last two years. >>>>> >>>>> Obviously some of those we found have been pulled into Pharo >>>>> already, but the attached MCZ represents those that we think are >>>>> still relevant :) >>>>> >>>>> This is a rough list of the fixes: >>>>> >>>>> 1. Fixed flaky borwser comment text area sometime not showing. >>>>> >>>>> 2. Added getArgumentPermutation to support RefactoringEngine. >>>>> >>>>> 3. Fixes to CanvasCharacterScanner and >>>>> MultiCanvasCharacterScanner to correctly align the first line of >>>>> text when centered/justifed etc. >>>>> >>>>> 4. Added more constant names to Character class. >>>>> >>>>> 5. Modified ConnectionQueue to not accept connections when queue >>>>> is full. >>>>> >>>>> 6. Changed GrafPort to answer a MultiDisplayScanner when >>>>> appropriate (allows subclasses of MultiNewParagraph). >>>>> >>>>> 7. NaturalLanguageTranslator startup postion move to after >>>>> PasteUpMorph since it will show a progress bar. >>>>> >>>>> 8. Fix to Random>>nextInt: to allow large numbers which would be >>>>> out of range if using Floats (as mentioned recently on dev, use >>>>> of Floats is dodgy anyway...) >>>>> >>>>> 9. Changed TranscriptStream>>clear to use a new buffer (was just >>>>> reset which could leave a massive collection). >>>>> >>>>> 10. Changed RemoteString to handle concurrent processes safely. >>>>> This one's particularly interesting: we were load-testing our >>>>> Seaside app here and getting lots of syntax errors when hitting >>>>> the image with around the 20 concurrent processes due to source >>>>> file access. After this change we were hitting it with >>>>> approximately 500 concurrent processes, and the failure was in >>>>> the Java load tester (it timed out). >>>>> >>>>> Hope just submitting a .mcz is OK! :) >>>>> >>>>> Cheers, >>>>> Simon and Gary >>>>> >>>>> >>>>> >>>>> ****************************************************************************************************************************************** >>>>> This email is from Pinesoft Limited. Its contents are >>>>> confidential to the intended recipient(s) at the email >>>>> address(es) to which it has been addressed. It may not be >>>>> disclosed to or used by anyone other than the addressee(s), nor >>>>> may it be copied in anyway. If received in error, please contact >>>>> the sender, then delete it from your system. Although this email >>>>> and attachments are believed to be free of virus, or any other >>>>> defect which might affect any computer or IT system into which >>>>> they are received and opened, it is the responsibility of the >>>>> recipient to ensure that they are virus free and no >>>>> responsibility is accepted by Pinesoft for any loss or damage >>>>> arising in any way from receipt or use thereof. >>>>> ******************************************************************************************************************************************* >>>>> >>>>> >>>>> Pinesoft Limited are registered in England, Registered number: >>>>> 2914825. Registered office: 266-268 High Street, Waltham Cross, >>>>> Herts, EN8 7EA >>>>> <Pinesoft-Fixes-Misc-gvc.24.mcz> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> ****************************************************************************************************************************************** >>> This email is from Pinesoft Limited. Its contents are confidential >>> to the intended recipient(s) at the email address(es) to which it >>> has been addressed. It may not be disclosed to or used by anyone >>> other than the addressee(s), nor may it be copied in anyway. If >>> received in error, please contact the sender, then delete it from >>> your system. Although this email and attachments are believed to >>> be free of virus, or any other defect which might affect any >>> computer or IT system into which they are received and opened, it >>> is the responsibility of the recipient to ensure that they are >>> virus free and no responsibility is accepted by Pinesoft for any >>> loss or damage arising in any way from receipt or use thereof. >>> ******************************************************************************************************************************************* >>> >>> >>> Pinesoft Limited are registered in England, Registered number: >>> 2914825. Registered office: 266-268 High Street, Waltham Cross, >>> Herts, EN8 7EA >>> >>> _______________________________________________ >>> 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 > > > > ******************************************************************************************************************************************* > > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > > ******************************************************************************************************************************************* > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2008

Re: [Pharo-project] Linux VM building - Where's Eliots closure code?

by bryce＠kampjes.demon.co.uk

Nikolay Suslov writes: > Here is the link to files: http://www.mirandabanda.org/cogblog/downloads/ Thanks, I'm looking into merging this in. It'll take a little work as Eliot built off an old VM. Just importing his change set breaks the build. Bryce P.S. I've got a makefile modification that works a little better. It doesn't require edits for each build, but I've hardcoded the path to the freetype include files into the makefile.

Sept. 27, 2008