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

Re: [Pharo-project] [squeak-dev] Re: [Esug-list] Google Summer Of Code 2010 news!!!

by Julian Fitzell

On Sat, Mar 6, 2010 at 12:54 PM, Paolo Bonzini <bonzini(a)gnu.org> wrote: >> We think that one of the most important reasons why we failed in 2009 is >> that Google was looking for bigger communities that Squeak. This is why >> this year we all go under the ESUG umbrella. We present ESUG as the >> mentor organization and we cover ALL open-source Smalltalk dialects, not >> only Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all >> invited to participate. Also cross platform projects like Seaside, >> AidaWeb, Magma, etc are welcome. > > Here is a list of ideas from me, all more or less involving cross-dialect > pollination. Â These are based on my preferences, from most to least > preferred > > 1) GNU Smalltalk includes a refactored version of Swazoo that supports SCGI > and is also faster in general. Â Start from there and backport the changes to > Squeak/Pharo. Â Use Seaside's Grease cross-dialect compatibility layer to get > rid of (most of) the Sport dependency. > > 2) Convert existing cross-platform projects to use Grease. Â Demonstrate them > using two-three dialects (VW, Squeak, GST). Â Discuss possible extensions to > Grease and implement them. Â Document Grease extension based on the formalism > of the ANSI standard. > > 3) I agreed with the FSF to relicense GNU Smalltalk's file system classes > under MIT license. Â Port them to at least two other dialects (Squeak/Pharo > count as one). Â Think of cool ways to use them. Â Possibly work out how to > integrate them into Grease and make Seaside use them. I think I'd be willing to be a mentor for anything Grease- or Seaside-related, though I might need to run that by my new employer depending on what the project ends up being. The above are good ideas. Also, off the top of my head: + Take the best parts of Seaside and Swazoo's HTTP protocol classes and create an HTTP package that could be optionally loaded with Grease and used by multiple projects. + Someone else suggested porting Monticello to Smalltalk/X. The same could be done for VA Smalltalk and a full port with UI for VW. + I'd really love to see a single RefactoringBrowser package that could be loaded on all the platforms using Grease. I have no idea if there's any chance of buy-in from the vendors on that one; maybe it would need a new class name prefix so it could be loaded in parallel... Those are just random mind wanderings... Julian

March 6, 2010

Re: [Pharo-project] About using initialize

by Chris Muller

Even though Object>>#initialize doesn't do anything, I still recommend calling "super initialize" just for. If you're doing an allocation anyway, one super call ot a method that does nothing will not be a performance issue. But I feel is it is better-form to call super. On Sat, Mar 6, 2010 at 3:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I browsed a lot of code with jb friday and I saw that lot of classes that predate the automatic initialize > introduction (squeak 3.7) do not have a nice initialize methods. Â In particular old tools, have a particular style. > I wanted to raise this point. I would really like to have classes that take responsibilities to initialize objects with > decent/default instance variables. It will make the code easier to understand and evolve. > If you have some (counter) arguments I'm all ears. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 6, 2010

Re: [Pharo-project] [update 1.1] #11247

by StÃ©phane Ducasse

argh I will check that. Stef > Don't forget that dragging a picture file into the Pharo main window > makes a new SketchMorph... > > Reards, Gary > > On Sat, 2010-03-06 at 22:10 +0100, StÃ©phane Ducasse wrote: >> 11247 >> ----- >> >> - Issue 2102: Fix the fact that local temp can shadow silently instance variable CompilerTests Tx lukas and jorge >> >> - Issue 2117: methodComment (good idea laurent) >> >> - Convert logo from sketchMorph to imageMorph for SketchMorphRemoval next step. >> >> 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

March 6, 2010

[Pharo-project] [update 1.1] #11249

by stephane ducasse

11249 ----- - Issue 2114: Enhance SqNumberParser error handling inside Compiler. Tx nicolas - Issue 2116: Compiler sometimes return nil rather than diagnosing the problem. Tx nicolas - Issue 2118: 1) Let unicode leading Char be zero (only 2 methods). Arbitrarily solve the Russian/Nepalese environment conflict. -- SOMEONE HAS TO CHECK WHAT SHOULD THE POLICY BE... -- (I guess a non issue except for OLPC Etoys) 2) Prepare a TextStopConditions object for handling endOfRun/crossedX without breaking a macron. 3) After loading, you should execute: EncodedCharSets initialize. Thanks nicolas Stef

March 6, 2010

Re: [Pharo-project] Trying to build alien plugin in linux

by Eliot Miranda

2010/3/4 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > Also I have the theory that the problem may be related to some > -fomit-frame-pointer hidden in some place that forces code to use references > relative to esp instead of ebp. Ah, that's *very* important. The plugin must *not* be built with -fomi-frame-pointer. In fact it needs -fno-omit-frame-pointer adding to Makefile.inc et al to ensure it always includes the frame pointer. > > > On Fri, Mar 5, 2010 at 1:20 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > >> Wiiiiiii. All tests passing now!! >> >> You were right, this func had so many variables that gcc was reserving >> some local space to do some intermediate calculations. >> >> To make the story short defining >> # define STACK_ALIGN_BYTES 16 >> solved it. >> >> After a lot of debugging I discovered that alloca was aligning the stack, >> allocating more space than necesary, and placing the args not starting from >> esp but from esp plus some offset. Adding getsp(argvec) to move argvec to >> the top of the stack didn't solve the problem because the code that pushes >> the args also overwrites it (don't know why, it's like alloca augmented the >> frame in the middle?). >> >> So, that define fixed everything, and >> >> #if __APPLE__ && __MACH__ && __i386__ >> # define STACK_ALIGN_BYTES 16 >> #endif >> >> should be changed accordingly (to something I don't know what). In my case >> I'm using gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1. >> >> Thanks for all the help! >> >> Regards, >> Javier. >> >> >> >> On Wed, Mar 3, 2010 at 2:36 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: >> >>> Exactly, that's what confuses me most! The function doesn't even have >>> locals: >>> >>> EXPORT(LONGLONG) ffiTestLongLong10a2(char c1, char c2, char c3, char c4, >>> char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG >>> i2) { >>> return c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+i1 + i2; >>> } >>> >>> I'm quite sure it's substracting because I see the memory contents, and >>> the disassembly is this (notice how it accumulates the result in edx): >>> >>> 0x75d32725 <ffiTestLongLong10a2+308>: movsbl -0x1c(%ebp),%edx >>> 0x75d32729 <ffiTestLongLong10a2+312>: movsbl -0x20(%ebp),%eax >>> 0x75d3272d <ffiTestLongLong10a2+316>: add %eax,%edx >>> 0x75d3272f <ffiTestLongLong10a2+318>: movsbl -0x24(%ebp),%eax >>> 0x75d32733 <ffiTestLongLong10a2+322>: add %eax,%edx >>> 0x75d32735 <ffiTestLongLong10a2+324>: movsbl -0x28(%ebp),%eax >>> 0x75d32739 <ffiTestLongLong10a2+328>: add %eax,%edx >>> 0x75d3273b <ffiTestLongLong10a2+330>: movsbl -0x2c(%ebp),%eax >>> 0x75d3273f <ffiTestLongLong10a2+334>: add %eax,%edx >>> 0x75d32741 <ffiTestLongLong10a2+336>: movsbl -0x30(%ebp),%eax >>> 0x75d32745 <ffiTestLongLong10a2+340>: add %eax,%edx >>> 0x75d32747 <ffiTestLongLong10a2+342>: movsbl -0x34(%ebp),%eax >>> 0x75d3274b <ffiTestLongLong10a2+346>: add %eax,%edx >>> 0x75d3274d <ffiTestLongLong10a2+348>: movsbl -0x38(%ebp),%eax >>> 0x75d32751 <ffiTestLongLong10a2+352>: add %eax,%edx >>> 0x75d32753 <ffiTestLongLong10a2+354>: movsbl -0x3c(%ebp),%eax >>> 0x75d32757 <ffiTestLongLong10a2+358>: add %eax,%edx >>> 0x75d32759 <ffiTestLongLong10a2+360>: movsbl -0x40(%ebp),%eax >>> 0x75d3275d <ffiTestLongLong10a2+364>: lea (%edx,%eax,1),%eax >>> 0x75d32760 <ffiTestLongLong10a2+367>: mov %eax,%edx >>> 0x75d32762 <ffiTestLongLong10a2+369>: sar $0x1f,%edx >>> 0x75d32765 <ffiTestLongLong10a2+372>: add -0x48(%ebp),%eax >>> 0x75d32768 <ffiTestLongLong10a2+375>: adc -0x44(%ebp),%edx >>> 0x75d3276b <ffiTestLongLong10a2+378>: add -0x50(%ebp),%eax >>> 0x75d3276e <ffiTestLongLong10a2+381>: adc -0x4c(%ebp),%edx >>> 0x75d32771 <ffiTestLongLong10a2+384>: add $0xbc,%esp >>> 0x75d32777 <ffiTestLongLong10a2+390>: pop %ebx >>> 0x75d32778 <ffiTestLongLong10a2+391>: pop %esi >>> 0x75d32779 <ffiTestLongLong10a2+392>: pop %edi >>> 0x75d3277a <ffiTestLongLong10a2+393>: pop %ebp >>> 0x75d3277b <ffiTestLongLong10a2+394>: ret >>> >>> This is really weird! Why could gcc compiled it flipped? I'll continue >>> looking. >>> >>> Regards, >>> Javier. >>> >>> 2010/3/3 Eliot Miranda <eliot.miranda(a)gmail.com> >>> >>> >>>> >>>> 2010/3/3 Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>>> >>>> Ok, this is way nicer. The line that was missing and that seems to solve >>>>> all this is >>>>> >>>>> self initializeSpecialObjectIndices. >>>>> >>>>> which I think should be placed in Alien>>#initialize just before >>>>> >>>>> self ensureInSpecialObjectsArray. >>>>> >>>>> but then I don't know why it should ensure anything that is done just >>>>> before. >>>>> >>>>> With that I it's really close to work. After a few hours I understood >>>>> the way tests are done. In Alien plugin you integrated a couple of exported >>>>> functions (ffiTest*), which you then call in the tests. These funcs do >>>>> simple stuff like adding and returning the result, so you can compare, am I >>>>> right? >>>>> >>>>> Then I realized that (at least in linux) the tests won't work if you >>>>> compile as internal (there won't be a .so, so you won't be able to load the >>>>> C test functions!). >>>>> >>>>> Now with the small fix I added, and compiling as external, I can see >>>>> that it's actually almost almost working, buuuut I get these test results: >>>>> 36 run, 17 passed, 19 failures, 0 errors (had to remove >>>>> testCallingSquenceString because it crashed the VM). Notice that before I >>>>> got 20 errors and 0 failures. This is because the results are wrong. >>>>> >>>>> >>>>> I debugged the code with ddd to see what's happening, and I can see >>>>> that everything is going nice before the actual function call, that is done >>>>> in dabusiness.h. >>>>> >>>>> funcAlien = interpreterProxy->stackValue(funcOffset); >>>>> f = *(void **)startOfParameterData(funcAlien); >>>>> >>>>> #if STACK_ALIGN_BYTES (in my compiled code it is'nt defined, should >>>>> it?) >>>>> /* cut stack back to start of aligned args */ >>>>> setsp(argstart); >>>>> #endif >>>>> r = f(); >>>>> >>>>> I took as example test #ffiTestLongLong10a2:, which calls >>>>> ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, >>>>> char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2). >>>>> >>>>> dabusiness.h allocated 56 bytes in argvec (10*4 for chars + 2*8 for >>>>> longlong), which then fills correctly (ddd says 1 2 3 4 5 6 7 8 9 10 11 0 12 >>>>> 0). I have to admit that I don't fully understand whats happening with the >>>>> stack then, but ffiTestLongLong10a2 gets its arguments wrong. I'm thinking >>>>> of a calling convention problem. Here it's why: >>>>> >>>>> In some run I have: &argvec[0] is pos 0aa0 (this is actually direction >>>>> inside the stack, near it's top). Just before assembly CALL >>>>> ffiTestLongLong10a2 I have ebp=0b68, and after the call it is pushed and >>>>> replaced with esp, which is 0a88. Then, we have, args at 0aa0, 0aa4, ..., >>>>> and current stack frame starting at 0a88 and going lower, 0a84, etc. That >>>>> may be ok, but when I look into the ffiTestLongLong10a2 assembly it is >>>>> trying to find the arguments by *substracting* to ebp (arg1 in ebp-1c, 2nd >>>>> in ebp-20, ...) when it should adding, looking in greater positions >>>>> (previous stack frame, arg1 is in ebp+18). This has to be some simple >>>>> calling convention stuff, but I don't know how to solve it, any ideas?. >>>>> >>>> >>>> Subtracting from ebp is for accessing locals, adding to ebp for >>>> accessing arguments. Are you sure you're not misinterpreting a local access >>>> as an argument access? >>>> >>>> >>>> >>>>> Thanks for reading, >>>>> Javier. >>>>> >>>>> >>>>> On Mon, Mar 1, 2010 at 9:05 PM, John M McIntosh < >>>>> johnmci(a)smalltalkconsulting.com> wrote: >>>>> >>>>>> It would be missing, propose a change set. >>>>>> >>>>>> I would think people usually don't use VMMaker images as their daily >>>>>> work image. >>>>>> >>>>>> So take image, load vmaker, load vmaker stuff for alien, make alien >>>>>> plugin. >>>>>> >>>>>> got to my work image that doesn't have vmmaker in it, >>>>>> load alien support stuf, you don't need the alien-vmmaker-support >>>>>> btw. >>>>>> run tests. >>>>>> >>>>>> >>>>>> >>>>>> On 2010-03-01, at 3:36 PM, Javier PimÃ¡s wrote: >>>>>> >>>>>> Hi, I'm still trying to advance with this. Don't know what caused the >>>>>> ObjectMemory classPools but it seems to be away now, maybe I did some >>>>>> mistake last time. >>>>>> >>>>>> The thing is that now I have in ObjectMemory classPools all the >>>>>> original ones plus 4 new elements, which I think were added with this >>>>>> Alien-VMMaker-Support override: >>>>>> >>>>>> ObjectMemory>>#initialize >>>>>> initialize >>>>>> #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector >>>>>> #SelectorAttemptToAssign) >>>>>> do: [:c | >>>>>> [ObjectMemory addClassVarName: c] ifError: []]. >>>>>> >>>>>> the thing is that it never assigns them any value, so my theory is >>>>>> that there's some code missing? Then in Interpreter it happens something >>>>>> quite similar. Interpreter>>#initialize does this: >>>>>> >>>>>> ... >>>>>> >>>>>> #(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs >>>>>> #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate >>>>>> #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification >>>>>> #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) >>>>>> do: [:c | >>>>>> [Interpreter addClassVarName: c] ifError: []]. >>>>>> >>>>>> #(#primFailCode) >>>>>> do: [:i | [Interpreter addInstVarName: i] ifError: []]. >>>>>> >>>>>> ... >>>>>> >>>>>> but then never calls initializePrimitiveErrorCodes, which would set >>>>>> the vars to a meaningfull value. >>>>>> >>>>>> >>>>>> In conclusion, the question would be, where is this missing >>>>>> initialization code? >>>>>> >>>>>> Hope you can help, thanks! >>>>>> >>>>>> Javier. >>>>>> >>>>>> On Tue, Feb 23, 2010 at 4:39 PM, Javier PimÃ¡s < >>>>>> elpochodelagente(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < >>>>>>> johnmci(a)smalltalkconsulting.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 2010-02-22, at 6:48 PM, Javier PimÃ¡s wrote: >>>>>>>> >>>>>>>> Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are >>>>>>>> the results: >>>>>>>> >>>>>>>> 37 run, 17 passed, 0 failures, 20 errors. >>>>>>>> >>>>>>>> TestCallingSequenceChar10Long2 >>>>>>>> TestCallingSequenceChar2LongLong2 >>>>>>>> TestCallingSequenceChar8Long2 >>>>>>>> TestCallingSequenceChar9Long2 >>>>>>>> TestCallingSequenceCharLongLong2 >>>>>>>> TestCallingSequenceChars >>>>>>>> TestCallingSequenceDoubles14 >>>>>>>> TestCallingSequenceDoubles2 >>>>>>>> TestCallingSequenceFloats13 >>>>>>>> TestCallingSequenceFloats14 >>>>>>>> TestCallingSequenceFloats2 >>>>>>>> TestCallingSequenceFloats2WithInteger >>>>>>>> TestCallingSequenceFloats2WithInteger2 >>>>>>>> TestCallingSequenceFloats7 >>>>>>>> TestCallingSequenceInt >>>>>>>> TestCallingSequenceInt8 >>>>>>>> TestCallingSequenceIntWithFloatArgs >>>>>>>> TestCallingSequenceLongLong2 >>>>>>>> TestCallingSequenceShort >>>>>>>> TestCallingSequenceString >>>>>>>> >>>>>>>> >>>>>>>> Oh look SUnits, great stuff (*cough* well I wrote most of them). >>>>>>>> >>>>>>>> >>>>>>> Cool, this is really really useful (although I sometimes find wrting >>>>>>> tests boring ;) ). >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It is failing in places where it does primLoadLibrary: 'IA32ABI'. >>>>>>>> Why should it try to load itself, if it's compiled as an internal plugin? I >>>>>>>> compiled it as external too but didn't work either. >>>>>>>> >>>>>>>> >>>>>>>> Well it compiled, but that doesn't mean it works. In fact the error >>>>>>>> means the plugin code is never loaded, or is callable. >>>>>>>> Now one thing to consider is that the plugin load fails, because it >>>>>>>> can't find it. (external usage). >>>>>>>> Or because (internal and external plugin) the VM Version and the >>>>>>>> plugin version don't match. >>>>>>>> >>>>>>>> Look for your definition of >>>>>>>> #define VM_PROXY_MINOR 8 >>>>>>>> >>>>>>>> It should be 8 or higher for compiling BOTH the VM and the Plugin. >>>>>>>> Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is >>>>>>>> mass confusion about which header is being used? >>>>>>>> >>>>>>>> If for example your VM say it's a VM_PROXY_MINOR of 7, then it >>>>>>>> won't work with a plugin compiled with VM_PROXY_MINOR = 8. >>>>>>>> It silently fails... Well actually it gives the primLoadLibrary >>>>>>>> failure, but good luck in guessing why... >>>>>>>> >>>>>>> >>>>>>> Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't >>>>>>> have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined >>>>>>> in any other place? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Other question, can classic FFI and Alien live nicely together (I >>>>>>>> mean have x plugin use classic FFI while y uses Alien)? >>>>>>>> >>>>>>>> >>>>>>>> yes. >>>>>>>> >>>>>>>> One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You >>>>>>>> can't have both in, right? >>>>>>>> >>>>>>>> >>>>>>>> One is a subclass of the other. I use the IA32ABIPluginAttic one. >>>>>>>> >>>>>>> >>>>>>> Ok, what is the difference between them? a performance issue? >>>>>>> everything works the same I choose one or the other? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Syntax highligthing is broken for Alien primitive methods like >>>>>>>> these: >>>>>>>> >>>>>>>> <primitive: 'primUnsignedShortAtPut' error: errorCode module: >>>>>>>> 'IA32ABI'> >>>>>>>> >>>>>>>> Lastly, as I said when I loaded Alien Core the first time, I got >>>>>>>> this error while loading it: >>>>>>>> >>>>>>>> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". >>>>>>>> >>>>>>>> What should I do about that? ignore it? >>>>>>>> >>>>>>>> >>>>>>>> Well it seems to be related to >>>>>>>> >>>>>>>> ((Smalltalk includesKey: #ObjectMemory) >>>>>>>> and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien >>>>>>>> ifAbsent: []) ~~ (index - 1)]) ifTrue: >>>>>>>> [self error: 'index probably wrong']. >>>>>>>> >>>>>>>> Usually people don't have ObjectMemory loaded in their image, and >>>>>>>> I"m not sure what it is check for. >>>>>>>> Why don't you try it in a regular Pharo image versus your VMMaker >>>>>>>> image. >>>>>>>> >>>>>>>> >>>>>>> In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When >>>>>>> I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien >>>>>>> isn't defined inside >>>>>>> >>>>>>> (Smalltalk at: #ObjectMemory) classPool >>>>>>> >>>>>>> Interestingly, after load alien, #ClassAlien gets added as a key, but >>>>>>> all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like >>>>>>> this: >>>>>>> >>>>>>> (Smalltalk at: #ObjectMemory) classPool inspect: >>>>>>> >>>>>>> - size : 119 >>>>>>> [#AllButHashBits] : nil >>>>>>> [#AllButMarkBit] : nil >>>>>>> [#AllButMarkBitAndTypeMask] : nil >>>>>>> [#AllButRootBit] : nil >>>>>>> [#AllButTypeMask] : nil >>>>>>> ... >>>>>>> [#ClassAlien] : nil >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Javier PimÃ¡s >>>>>>> Ciudad de Buenos Aires >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Javier PimÃ¡s >>>>>> Ciudad de Buenos Aires >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> =========================================================================== >>>>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>>>>> squeaker68882 >>>>>> Corporate Smalltalk Consulting Ltd. >>>>>> http://www.smalltalkconsulting.com >>>>>> >>>>>> =========================================================================== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Javier PimÃ¡s >>>>> Ciudad de Buenos Aires >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 6, 2010

Re: [Pharo-project] [update 1.1] #11247

by Gary Chambers

Don't forget that dragging a picture file into the Pharo main window makes a new SketchMorph... Reards, Gary On Sat, 2010-03-06 at 22:10 +0100, StÃ©phane Ducasse wrote: > 11247 > ----- > > - Issue 2102: Fix the fact that local temp can shadow silently instance variable CompilerTests Tx lukas and jorge > > - Issue 2117: methodComment (good idea laurent) > > - Convert logo from sketchMorph to imageMorph for SketchMorphRemoval next step. > > stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 6, 2010

[Pharo-project] About using initialize

by StÃ©phane Ducasse

Hi guys I browsed a lot of code with jb friday and I saw that lot of classes that predate the automatic initialize introduction (squeak 3.7) do not have a nice initialize methods. In particular old tools, have a particular style. I wanted to raise this point. I would really like to have classes that take responsibilities to initialize objects with decent/default instance variables. It will make the code easier to understand and evolve. If you have some (counter) arguments I'm all ears. Stef

March 6, 2010

[Pharo-project] [update 1.1] #11247

by StÃ©phane Ducasse

11247 ----- - Issue 2102: Fix the fact that local temp can shadow silently instance variable CompilerTests Tx lukas and jorge - Issue 2117: methodComment (good idea laurent) - Convert logo from sketchMorph to imageMorph for SketchMorphRemoval next step. stef

March 6, 2010

Re: [Pharo-project] Google Summer Of Code 2010 news!!!

by Mariano Martinez Peck

A little correction. At the beginning I though only open-source Smalltalk dialects were possible, but now Janko let me know that non open-source dialects are welcome too. What really has to be open-source is the project/idea in particular, but the Smalltalk dialect in itself can be non open-source. Sorry for the noise. Mariano On Sat, Mar 6, 2010 at 1:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup > or second admin is Janko MivÅ¡ek. As you may know, Squeak has participated in > GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we > will succeed this year but we will try to do as much as possible. > > We think that one of the most important reasons why we failed in 2009 is > that Google was looking for bigger communities that Squeak. This is why this > year we all go under the ESUG umbrella. We present ESUG as the mentor > organization and we cover ALL open-source Smalltalk dialects, not only > Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all invited to > participate. Also cross platform projects like Seaside, AidaWeb, Magma, etc > are welcome. > > <forThoseWhoDoesntKnowWhatGSoCIs> > It is a Google program that support (money) students to work on different > open-source projects. Google doesn't talk or manage directly to the students > but trough "Mentoring Organisations". Those organizations have to apply to > GSoC. They have to give a lot of information, included a list of > ideas/projects. Each project has a description and a mentor. Then the > students apply for each project. If the organization gets selected by Google > they will tell you how many "slots" they give. Suppose they give 5 but we > have 20 projects....then we vote and the most voted projects win. The > student has to do the project and the mentor has to help and guide him. The > mentor receives 500 USD and the student 4500USD. > For more information read: http://code.google.com/soc/ > </forThoseWhoDoesntKnowWhatGSoCIs> > > The most important thing is the deadlines we have. We started late so we > are very near to the first deadline which is 12/03/2010 (less than one > week). For that deadline we need to submit all the information of the mentor > organization (answering several questions) and give the list of > ideas/projects and the mentors of that. > > We have created a webpage (Thanks Janko!!) where we will put all the > information. We will make this page public soon (we still need to review a > couple of things). > But for the moment we would REALLY appreciate if tell us your ideas. To do > this, just answer to this email. Then we will collect the information and > put in the website. For each idea you need: a short title and a paragraph > (for the moment) explaining the idea. > After, we need that the people that are willing to be mentors start to > apply as mentors...please, consider yourself being mentor. Sometimes it is > not that difficult. I mean, don't be shy as sometimes being helpful, being > aware of the dates, answering emails, etc is more important than the > Smalltalk knoweldege. We can have a lot of ideas, but we need also mentors > for that. We even would need a "substitute" for each mentor... > > Just as an example you can see the ideas of the previous years: > 2007: http://wiki.squeak.org/squeak/5936 > 2008: http://wiki.squeak.org/squeak/6031 > 2009: http://wiki.squeak.org/squeak/6120 > > That's all for the moment. > > Cheers > > Mariano > >

March 6, 2010

Re: [Pharo-project] Having fun with booleans

by csrabak＠bol.com.br

Yes ;-) in fact AndrÃ©s Valloud wrote a book "Fundamentals of Smalltalk Programming Technique" which he discusses the theme of Booleans in Chapter 3 and specifically the optimization you discovered in 3.2.1. -- Cesar Rabak Em 05/03/2010 04:22, Igor Stasenko < siguctua(a)gmail.com > escreveu: Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead. a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ] a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ] and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as: a > b and: [ self foo]; or:[ self bar ] :) -- 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

March 6, 2010