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

Re: [Pharo-project] Some notes we took during our experience

by Mariano Martinez Peck

On Thu, Jan 7, 2010 at 4:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi > > marcus jannik and me got fun and fixed some cycles. > > Here are some extra notes I took > > - PreferenceBrowserMorph and friends should be removed. > - MethodReference could be closer to CompiledMethod (to avoid cycle > with tools when in fact people > just wanted to report aCompiled method list and return a > methodReference list). > - Services -> split into Services-Morphic and Services-Core -> but > services should be removed for now > > - Symbol could has its own scanning function (isLiteralSymbol) to > avoid to depend on Scanner > - URL should be replaced by URI > - WordArrayForSegment -> ImageSegment > I will try to look for this. I have several things in my ImageSegment to-do list :) > - FilePackage -> Tools > - TextDiffBuilder -> in its own package. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2010

Re: [Pharo-project] Some notes we took during our experience

by Nicolas Cellier

2010/1/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi > > marcus jannik and me got fun and fixed some cycles. > > Here are some extra notes I took > > Â Â Â Â - PreferenceBrowserMorph and friends should be removed. > Â Â Â Â - MethodReference could be closer to CompiledMethod (to avoid cycle with tools when in fact people > Â Â Â Â just wanted to report aCompiled method list and return a methodReference list). > Â Â Â Â - Services -> split into Services-Morphic and Services-Core -> but services should be removed for now > > Â Â Â Â - Symbol could has its own scanning function (isLiteralSymbol) to avoid to depend on Scanner Anyway, st-80 did have support for several Compiler, so asking to Symbol rather than Compiler/parser was a bad idea. Nicolas > Â Â Â Â - URL should be replaced by URI > Â Â Â Â - WordArrayForSegment -> ImageSegment > Â Â Â Â - FilePackage -> Tools > Â Â Â Â - TextDiffBuilder -> in its own package. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2010

Re: [Pharo-project] About my recursive blues :)

by StÃ©phane Ducasse

;) Thanks! you got it right On Jan 7, 2010, at 7:11 AM, Miguel Enrique CobÃ¡ Martinez wrote: > Hey Stef, > > isn't anything wrong with having a bad mood day, or even thinking that > the path chosen wasn't right. All of us have that kind of feelings > sometimes. You are human, we are all. But don't let one day override the > good days. > > Glad to see that you had a time with your family, because that always > gives you a strong support. And new energy to keep the work going. > > I, as many others, are very proud about the way Pharo is going. Pharo is > also an important and strategic part of many new project and business. > This is something we are very grateful. To you and every other people > involved with Pharo some way. > > A big thank you all. We are commited to Pharo and we will follow > contributing to it as we can, even little things. > > Respect to Squeak, I seriously began to write a reply to the mail from > Andreas announcing the removal of Etoys, I was absolutely enraged. Not > because the change itself that has evident technical merits but for the > absolutely lack of seriousness and touch from Andreas. > Lets be clear, I have lost my respect for him, why?, because he isn't a > leader. He is pushing Squeak to where he wants. It is his own Squeak. He > stated before, and even fought several times with people that suggested > that etoys should be removed from squeak, that etoys is a fundamental > distinctive, unseparated part of squeak, to the point that squeak > without etoys isn't squeak. Similar bad karma for him for burning Stef > et al for criticized the way that Squeak was being at the time, for > burning Keith and installing his own process (that if you review the > commit logs, just half dozen of people are actively using to commit to > trunk). Then he goes and does everything that several people told it > that must be done as if were a novice idea. As if the opinion of others > weren't worth. But when he implements the very same idea, then it is the > logical next step for Squeak and the change that Squeak was waiting for. > This really irritates me. Besides, when I asked what are the middle-term > and long-term goals for squeak they said that there was no one. And that > appears to be right. The changes respond to mood of Andreas and are more > than random without a previous stated plan. The plan is created day to > day, depending of the desires of Andreas. > In the end I discarded the mail. It didn't worth the time. I let it > rest. > Honestly I don't know how the board will support this random change > occurring in Squeak. The board can barely state that their only goal > right now, and in fact the full last year was to be comply with the SFC > requirements. Now, de facto, the goals are minimal kernel with a mixture > of cuis + mc + m17n, everything unloadable, no etoys, new text editor, > new trails for changes files, and a lot of small changes that I suppose > are trying to speed up the image. But the board can't show a list of > goals. All or most of this changes, made, approved, selected and decided > by a single person. What if tomorrow some organization offers some > unrefusable amount to Andreas to let Squeak behind and go to work in X. > What will happen to current Andreas' Squeak? Who nows? Not even the > board. > > Well that was some of the feelings I wanted to express to the squeak > list and opted not to. But now, with your mail, I must say that I can > imagine what you must felt. Not only anger, but sad. A deep sad at > watching this happen. So sad to see so many intelligent people forget so > easily the previous and exhausting discussions. Well, Stef I support you > and the full Pharo people. This community is more honest and more > humble. That worths a lot for me. > > So, don't let yourself down. > We are a great and heterogeneous community. We can do it. > > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2010

Re: [Pharo-project] About my recursive blues :)

by StÃ©phane Ducasse

Now we will :) >> From this newbee, what you and the Pharo-dev guys are doing is > of great value and inspiration. That this kind of work can be done > this way is amazing, and fun, and, please keep doing what you're > doing :) > > Cheers, > Sheri Mahoney > > -- > View this message in context: http://n2.nabble.com/About-my-recursive-blues-tp4262984p4264916.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2010

[Pharo-project] Some notes we took during our experience

by StÃ©phane Ducasse

Hi marcus jannik and me got fun and fixed some cycles. Here are some extra notes I took - PreferenceBrowserMorph and friends should be removed. - MethodReference could be closer to CompiledMethod (to avoid cycle with tools when in fact people just wanted to report aCompiled method list and return a methodReference list). - Services -> split into Services-Morphic and Services-Core -> but services should be removed for now - Symbol could has its own scanning function (isLiteralSymbol) to avoid to depend on Scanner - URL should be replaced by URI - WordArrayForSegment -> ImageSegment - FilePackage -> Tools - TextDiffBuilder -> in its own package. Stef

Jan. 7, 2010

Re: [Pharo-project] Finalization quirk

by StÃ©phane Ducasse

+1 On Jan 7, 2010, at 11:12 AM, Adrian Lienhard wrote: > > On Jan 6, 2010, at 22:09 , John M McIntosh wrote: > >> Oh sure Bill you're violating rule (a). In squeak a full >> finalization pass is require to finalize all objects. >> This runs in to the Pharo's desire to only do incremental GCs and >> avoid a full GC. >> >> SystemDictionary>>setGCParameters >> >> Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. >> Smalltalk setGCBiasToGrow: 1. >> >> Which means that the image is happy to lurch around with a 16MB >> working space. Once that is exceeded then a full GC will occur. >> (yes yes, it's more complex that that, but it's just easier to say >> that's kinda what happens). The trade is deferring a full GC at the >> cost >> of deferring some finalized objects.... >> >> Frankly the default values for vmParameterAt: 5,6,24,25 I think >> are quite fictional based on desktop/laptop machines used in this >> decade, >> those values come from the era of 16Mhz 68030 macintosh SE/30 >> machines. However I do see that in >> initializeMemorySettingsProfileSeaSide >> someone picked more rational numbers but I think it's time that we >> clean those up this whole area. > > Where can I find #initializeMemorySettingsProfileSeaSide? Could you > propose new parameters for these settings? It's time to adjust them > for the new decade ;) > > Cheers, > Adrian > > > [...] > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2010

Re: [Pharo-project] DNU in dev image freezes my image

by StÃ©phane Ducasse

this is a known problem due to weakdictionary fix Stef On Jan 6, 2010, at 9:33 PM, Danie Roux wrote: > All, > > I downloaded pharo1.1-11112-alphadev09.12.2.zip, opened a Workspace > and caused a DNU. This froze my image. > > Bug report: http://code.google.com/p/pharo/issues/detail?id=1750 > > -- > Danie Roux *shuffle* Adore Unix - http://danieroux.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2010

Re: [Pharo-project] Printing???

by Schwab,Wilhelm K

This is something that has my attention as a future stumbling block. I don't share your concern for Windows, nor do I expect to make it consistent with unix-like systems. However, printing is something that Windows does fairly well, and I will eventually need to replace that functionality; please let us know what you find. Re generating pdf files, have a look at http://seaside.st/documentation/pdfs Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guido Stepken Sent: Thursday, January 07, 2010 6:11 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Printing??? I would like to know, how i print on all available platforms .... PS, EPS output ... hmmm, doesn't really work ... Apple uses CUPS, LINUX uses CUPS, Windows .... GDI and CUPS possible ... How can i generate e.g. PDF output and send that platform independent to printer? tnx in advance, Guido Stepken _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Gary Chambers

Fair enough. Perhaps the "global" announcer could be accessed via the class-side of SystemWindow. Lots of evil ways of manipulating morphs too. Just thought about hide/show etc. Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, January 07, 2010 1:28 PM Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > > On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: > >> That is one option, though it does seem to be burdensome on the >> announcement >> consumers to (depending upon requirements) possibly have to track all >> windows themselves. >> >> Regards, GaryI am not talking about Announcers, but where the >> Announcement is created. > > I'm not talking about letting the window be the announcer, but where the > announcement is made. > > So you'd do > openAsIsIn: aWorld > "current implementation" > someAnnouncer announce: (WindowOpened for: self in: self world) > > someAnnouncer could be a global announcer for all window events. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Henrik Johansen

NVM this, I only read the top and thought it was in reply to my last mail, not Simons :) On Jan 7, 2010, at 2:28 31PM, Henrik Johansen wrote: > > On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: > >> That is one option, though it does seem to be burdensome on the announcement >> consumers to (depending upon requirements) possibly have to track all >> windows themselves. >> >> Regards, GaryI am not talking about Announcers, but where the Announcement is created. > > I'm not talking about letting the window be the announcer, but where the announcement is made. > > So you'd do > openAsIsIn: aWorld > "current implementation" > someAnnouncer announce: (WindowOpened for: self in: self world) > > someAnnouncer could be a global announcer for all window events. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2010