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

Re: [Pharo-project] A point a.k.a excuse to you

by Keith Hodges

Schwab,Wilhelm K wrote: > Keith, > > Call it Squeak or Pharo, I (and apparently many others here) want a clean Smalltalk. Kernel+packages is fine; I could also live with a well-factored big image from which I simply chop out things I do not need. If the system is good, I will adapt to the ways people chose to give it to me. > > You apparently want Squeak. No I dont want squeak, I want an environment in which contributions and concepts are appreciated, and shareable. I want this "not invented here" attitude scrapped. To be clear, I wrote SUnit-improved 3 years ago. I wasn't so arrogant as to say it is "The" SUnit. that everyone should use, I offered it as an alternativeand it has remained loadable from universes. The code may not be perfect but the concepts were perfectly reasonable: 1. Non GUI Test Runner, for use in an automated remote build system. 2. Classification of tests - for a world in which there are different forks images etc so that test suites can be a shared knowledge base of what works where. 3. A flexible test suite building interface that can be used to run other test suites like SSpec within the same tools. 4. A Cleaner Organisation under the category "Testing" e.g. "Testing-Common, Testing-Commmon-GUI, Testing-SUnit-Tests, Testing-SSpec-Tests etc. So... along comes pharo, and without any discussion at all in the general SUnit users forum, starts to "do their own thing with SUnit". Well thanks for nothing, it really makes you feel like contributing. Its not squeak that is the black hole, squeak isn't actively snubbing contributions. Keith

March 4, 2009

Re: [Pharo-project] New Compiler

by Igor Stasenko

2009/3/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I would love to have one compilerContext object so that we do not have > to > pass all these parameters plague > > It would be nice to have > Â Â Â Â compile: 'text' context: (aCompilerContext) > > Â Â Â Â aCompilerContext > Â Â Â Â Â Â Â Â in: aClass ; > Â Â Â Â Â Â Â Â silently: true ; > Â Â Â Â Â Â Â Â inCategory: 'zork' > > But this is something we should do after :) This is something i'm already done in own implementation of parser. I have a context object which role is to respond to such things like silently/interactive, class etc.. > - Show quoted text - > On Mar 4, 2009, at 10:59 AM, Lukas Renggli wrote: > >> Hi Jorge, >> >> great to hear. I have two things that I wish you add to your list: >> >> 1. My first wish also affects the old compiler, but that should be >> easy to fix in Pharo. Currently there are dozens of selectors in >> Behavior that hardcode the currently used compiler #parseClass, >> #compilerClass, #evaluatorClass, #decompilerClass, >> #subclassDefinerClass, ... I would prefer to have exactly one entry >> point, for example under the name #compiler. This object could act >> like a compiler MOP on the receiving class and set through a >> preference for all classes of the system that do not override this >> method themselves. This would make it much cleaner to have different >> compilers in the image, swap them on the fly, get rid of various hacks >> and overrides and even allow to unload the old compiler. >> >> 2. My second wish is only about the new compiler. One thing stroke me >> when working on transactional memory and domain specific languages, is >> that the new compiler isn't as extensible as it advertises. The >> problem is there is no central place where the different phases >> (parsing, annotation, bytecode generation) of the compilation is >> triggered. Currently this happens at various places throughout the >> system. This has not only the problem that extending the compiler is >> difficult without patching it, but also makes it nearly impossible to >> get certain information at a particular place of the process. For >> example, during parsing it is not know in what class the method is >> supposed to be compiled, or during bytecode generation I don't know >> the source code anymore, etc. I suggest to introduce a compilation >> context, that is accessible anywhere and that can pass necessary >> information through the compilation phases. Furthermore I suggest to >> implement the delegation to the different parts of the compiler in a >> deticated object that can be subclassed and used for example if >> somebody wants to cleanly replace, customize or extend certain parts >> of the compiler. >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 4, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by StÃ©phane Ducasse

Plonk >> But Bill, > > you are criticising the OLD process, which is the process that Stef > and > Marcus were custodians of for two years. It was they who made it more > difficult to process by managing the image in packages without the > needed tools. > > The pharo process is exactly the same black hole with exactly the same > "not invented here attitude". > > In squeak land we have an all new process and some of us have been > working on that all new process for 2+ years, > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Mariano Martinez Peck

> > > > I have random segmentation faults trough FFI which I don't have in > > Squeak. I didn't want to spend many time trying to see what the > > problem is till 1.0 is releases. At that moment, I will look for the > > problem. When this is fixed, I will then really start using pharo > > 100%. > > Sure. > Can you report your problem on FFI :) > and add a bug report on pharo > I have being doing some tests with SqueakDBX and now It seems to work perfect. cheers, Mariano

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by Alain Plantec

Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version, no problem but tell me that I stop working on this. The set of system preferences constitutes a tree of preferences. The model for the tree is implemented by the PreferenceNode hierarchy. (see PrefCore2). This is the only mandatory part. The tree can be visualized with a PreferenceTree UI built on top of PrefCore2 (see PrefTool2 and snapshot). Examples of preference declaration are given in PrefProvider2. in order to open the tree: PreferenceTree open. Thank to Gary for its help. cheers alain StÃ©phane Ducasse a Ã©crit : > Thanks > this is strange that exactly the same week where we talk about that > and where > we discuss about announcements, such topics got interesting from some > other people. > We are probably not that wrong. ;) > Thanks cedric keep us informed. > > Stef > > On Mar 4, 2009, at 11:26 AM, CÃ©drick BÃ©ler wrote: > > >> As some of us are unregistered, I thought it could be of interest ;) >> >> >> ---------- Forwarded message ---------- >> From: Andreas Raab <andreas.raab(a)gmx.de> >> Date: 2009/3/4 >> Subject: [squeak-dev] [ANN] Preference pragmas >> To: The general-purpose Squeak developers list >> <squeak-dev(a)lists.squeakfoundation.org> >> >> >> Folks - >> >> I wanted to make the property whether to show individual processes in >> MessageTally a preference and couldn't recall any of the three >> gazillion methods to create one ;-) So I decided enough is enough and >> added the ability to register a preference via Pragma. In other words, >> you specify two class side accessors (using MessageTally as example): >> >> showProcesses >> "Indicates whether to show each process separately or >> cumulatively." >> <preference: 'Show Processes in MessageTally' >> category: 'debug' >> balloonHelp: 'If enabled, each profiled process is >> shown individually in MessageTally' >> type: #Boolean> >> ^ShowProcesses >> >> showProcesses: aBool >> "Indicates whether to show each process separately or >> cumulatively." >> ShowProcesses := aBool. >> >> and then register the preference in the class initialization method >> via: >> >> initialize >> "MessageTally initialize" >> "By default, show each process separately" >> ShowProcesses := true. >> "Register preferences" >> Preferences addPreferencesFor: self. >> >> The nice thing about this scheme is that the preference is local to >> the code where it's used and that there are no more generated >> accessors which mess up Monticello packages etc. What could probably >> be improved is the self-registration; I left it that way for now since >> I don't know how expensive it would be to scan all classes for new >> preferences when one opens a preference browser. There is also an >> example class PreferenceExample that illustrates the different types >> of preferences (textual, numeric, color, boolean) you can use. >> >> To install, just execute the following from Squeak 3.10.2: >> >> Installer mantis fixBug: 7306. >> >> Enjoy! >> - Andreas >> >> >> >> >> -- >> CÃ©drick >> >> _______________________________________________ >> 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 > > >

March 4, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Keith Hodges

Schwab,Wilhelm K wrote: > Keith, > > I respectfully disagree on one fundamental point: the processes fed into a black hole. Ideas were ignored, well intentioned people were ridiculed. What Stef et al. have done (beyond a lot of great work) is fix that problem. > > Bill > But Bill, you are criticising the OLD process, which is the process that Stef and Marcus were custodians of for two years. It was they who made it more difficult to process by managing the image in packages without the needed tools. The pharo process is exactly the same black hole with exactly the same "not invented here attitude". In squeak land we have an all new process and some of us have been working on that all new process for 2+ years, Keith

March 4, 2009

Re: [Pharo-project] What's the problem people? :)

by StÃ©phane Ducasse

> Hi Pharaos (and Squeak-dev)! :) Hi goran are you planning to come finally to esug that we drink beer together? This year there will be a wine tasting social event :) > Alert to Pharaos: This is a cross post! (hehe) > > I just wanted to say (for whatever that is worth) that I like Pharo. > And > I like Squeak.org. And I like everyone doing stuff in/for/on > Squeak/Pharo/Smalltalk/Huemul whatever. > > I have Pharo on my disk. I just started playing in it for a toy > project > involving RB AST, RoelTyper etc. I got (not tested) a new visitor for RB AST (elf on squeaksource) > But I do all Gjallar work on 3.10.2/LPF right now, it takes time > moving > a large project to a different baseline, so Gjallar will probably be > on > 3.10.2 for a while. But nothing prevents us from testing out Pharo > later > on - whatever works the best I say. Gjallar is also 95% ported to GS > these days. sounds good. > I agree with Keith/Matthew that making good tools that can *span* > different forks/communities *must* be a good thing for us all to have. > All tools don't need to be spanning, but it doesn't hurt if *some* > are - > right? Exact. This is why I wrote a chapter on Installer for the new pharo book :) > I *also* agree with Pharo people that hey, Pharo is a fork - we/you > can > do whatever we/you like! And that is good - it's the strength of > Pharo. > If Pharo diverts too much in "base stuff" it might turn into a > weakness > - but we just don't know these things, it is still to be seen. Exact > It is all about balance, benefits, etc. And we don't need to get angry > with each other do we? :) Trust me, it just burns your energy! Exact this is why we did pharo :) to stop arguing but doing instead: but you know us :) > I have code that seems to be doing fine in Pharo - SocketStream > comes to > mind. :) the power of MIT :) In fact I do not know. > I know Pharo seem to be more inclined to use Universes than SM - > fine with me, no problem. > > I hope to move SM forward in some way, and I hope it can still be > loaded/used from within Pharo - even if it gets thrown out soon (I > think > I read something about that). Yes I read that too :) > I also intend to use both Pharo, Squeak or > whatever works best for my different tasks. Ok if you want to have some feedback on SM we can take that offline. > And finally I hope to revive DeltaStreams and make that work in > Pharo as > well as most other Squeak flavors. > > We are all Squeakers, right? :) > > regards, GÃ¶ran > > PS. I am not sure why I am so damn cheerful, May be you were always like that ;) I do not know I was kind not that cheerful most of the time :) > perhaps it is the SURGE I > seem to feel in the Squeak community - so many things going on all > over > the place... ;) I do not know. We just started to move and to move at our pace with a shared vision built on our past experience and communication. Even our name and logo means what we want to build: a warm beam of light in dark tempest nights where any Smalltalker can find a place if he wants.

March 4, 2009

Re: [Pharo-project] Fwd: about adding chasing pointers and friends in the debug menu

by CÃ©drick BÃ©ler

done I hope correctly... http://code.google.com/p/pharo/issues/detail?id=628 initials are CB, is it ok or do I need to change to full name ? 2009/3/4 Adrian Lienhard <adi(a)netstyle.ch>: > What you can also do is to create a changeset and attach it to the > issue in the bug tracker. > In the comment, please also note the initialization that is required. > > Adrian > > On Mar 4, 2009, at 16:34 , CÃ©drick BÃ©ler wrote: > >> I just tried... >> >> Don't really know how to do slices >> >> also, one need to do "ParagraphEditor initialize" >> >> see joined >> >> 2009/3/4 Alexandre Bergel <alexandre(a)bergel.eu>: >>>>>>> I'd prefer a shortcut for "debug it" >>>> >>>> I also suggest to change "alt shift d". I think it's the best >>>> shortcut. I've never used the old behavior, and never seen anybody >>>> else using it. >>> >>> >>> Would be great yes. Anyone working on it? I could do it if nobody is >>> working on it. >>> >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel Â http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> CÃ©drick >> <ParagraphEditor-debugIt.st><ParagraphEditor class- >> initializeShiftCmdKeyShortcuts >> .st>_______________________________________________ >> 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 > -- CÃ©drick

March 4, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by StÃ©phane Ducasse

may be we should slowly think that we should get some people On Mar 4, 2009, at 4:25 PM, Bruce O'Neel wrote: > Hi, > > There seem to be three solutions (in best to worst order). > > - someone (Ian maybe) needs to rebuild the Unix VM with a VMMaker > from within the last two years. Apparently the bug has been fixed > for a > while. > > - pass a fixed memory size to the VM > > -memory 200m > > or so does the trick. > > - patch the existing C source code. > > cheers > > bruce > > On Tue, Mar 03, 2009 at 09:19:13AM +0100, Tudor Girba wrote: >> Hi, >> >> I am not sure I got the summary of the discussion related to the >> problem of deploying a Pharo-based image to seasidehosting. Is there >> any conclusion? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> >> _______________________________________________ >> 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 >

March 4, 2009

Re: [Pharo-project] Seaside working on Pharo

by Bruce O'Neel

Hi, My, possibly wrong, understanding is that it is fixed if you get a somewhat recent version of vm-maker. It's the lack of a '.' in a method. The problem seems to be that Ian, the generator of the unix vm, uses and older vm-maker. I don't know why this would be, but, surely he has his reasons. A simple fix is: The code is (from the gnu-interp.c file, though interp.c is the same): if (((((usqInt) ((longAt(foo->freeBlock)) & AllButTypeMask))) < (((usqInt) foo->growHeadroom))) && +(foo->gcBiasToGrow > 0)) { /* begin biasToGrow */ /* HERE's the new line! */ growSize = (((sqInt) (foo->growHeadroom * 3) >> 1)) - ((longAt(foo- >freeBlock)) & AllButTypeMask); /* begin growObjectMemory: */ foo->statGrowMemory += 1; limit = sqGrowMemoryBy(foo->memoryLimit, growSize); if (!(limit == foo->memoryLimit)) { foo->memoryLimit = limit - 24; initializeMemoryFirstFree(foo->freeBlock); } weDidGrow = 1; } and all should be good. The problem is that growSize isn't set, and, newer versions gcc seem to set it to 0, rather than some random number not 0. If the above code doesn't work justset growSize to something, say, 50000000 should do the job. Ie, each grow would be 50meg. cheers bruce On Wed, Mar 04, 2009 at 04:21:07PM +0100, Damien Cassou wrote: > On Wed, Mar 4, 2009 at 4:17 PM, Bruce O'Neel <squeak(a)pckswarms.ch> wrote: > > If you want to patch your linux VM and rebuild from source I can > > tell you where to fix it. > > Why not, but I would prefer to see the bug fixed in svn. Do you know > why it isn't there already? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2009