- Pharo-dev - lists.pharo.org

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

by Javier PimÃ¡s

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

March 5, 2010

Re: [Pharo-project] Developing morphic apps with pharo - sorting wheat from chaff

by Michael Forster

Thanks to all those who replied. I will give myself a couple of days to see if I can wrangle what I need out of the simplest Morphic widgets, ignoring ToolBuilder, etc. Mike -- Michael J. Forster <mike(a)sharedlogic.ca>

March 5, 2010

[Pharo-project] O2 does not run on PharoCore 1.1

by Alexandre Bergel

Unfortunately, I spotted some important bugs. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

> and then tried the "format" option in a method that has "^ something", > but it did not remove the extra space. Â In fact, I'm not sure it even > tried to format anything; I didn't have time to debug it. Â In any > case, if Pharo is using RB for formatting then separate solutions for > Squeak and Pharo may be necessary after-all.. Â :( If you use PharoDev it should be used. In PharoCore RB is not loaded. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Chris Muller

Cool, "present" is a start. But how do I use it? In Pharo 10508, I executed: RBConfigurableFormatter stringFollowingReturn: '' "<--- String empty" and then tried the "format" option in a method that has "^ something", but it did not remove the extra space. In fact, I'm not sure it even tried to format anything; I didn't have time to debug it. In any case, if Pharo is using RB for formatting then separate solutions for Squeak and Pharo may be necessary after-all.. :( On Thu, Mar 4, 2010 at 3:18 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> So how does that sound? Â Just dispatching portions of the various >> "printing" methods in subclasses of ParseNode to a Printer that allows >> individual preferences to be specified? > > This thing is called RBConfigurableFormatter and it has been present > for the last decade. > > 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 >

March 4, 2010

Re: [Pharo-project] [Moose-dev] Re: ConfigurationOfMetacello and OB

by Miguel Enrique CobÃ¡ Martinez

El jue, 04-03-2010 a las 21:04 +0100, StÃ©phane Ducasse escribiÃ³: > I'm dead/exhausted going bed now.....pfff cloud of smoke stef disappear from office pffff reappear in bed.... Hey, I want one of that instant-travel devices. Do they sell them on Amazon? :) -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 4, 2010

Re: [Pharo-project] [Moose-dev] Re: Fwd: Re: ConfigurationOfMetacello and OB

by Dale Henrichs

----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > Yes, an OBPlatform for each major version... | | Well, the problem is that ... | | OBPlatform | OBMorphicPlatform | OBShoutPlatform | | That doesn't really work without an explosion of classes and I don't | feel like changing all that :-( There _are_ other ways to skin the cat, but not having to skin the cat at all is even better:) Turning off deprecation warnings isn't that onerous, but it isn't something that you'd live with long term. Dale

March 4, 2010

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

by Jorge Ressia

Hi Adrian, Sorry for the delay, too many things today. Ok, I added 17 test to Tests-Compiler which model the cases of shadowing, at least the ones I could come up with. I also modified the Encoder>>bindTemp: in order to make it a little bit more intention revealing. My changes are in: Compiler-JorgeRessia.144 Tests-JorgeRessia.46 Some comments: - In order to test the not interactive mode I had to mock the Transcript. I could not find a better solution, if anybody has a better one just let me know I'll change it. - There is a special case which is that when you are NOT in interactive mode if the shadowed variable is a temp then the syntax error is triggered as in interactive mode. This is the behavior implemented before I did the changes. Is that what we want? - I added this test to Tests-Compiler package, I would have preferred to add them to Compiler-Tests but there was nothing there. Cheers, Jorge On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Jorge, > > Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! > > Cheers, > Adrian > > On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: > >> Hi Adrian, >> >> Yep, I have the same problem as you. My idea was to make it work as >> before without completely changing it. Basically because I did not >> have the test support to validate my changes. >> Anyhow, what I propose is to write a bunch of tests for every case >> that we know and then if new cases show up add them to the test suite. >> And then play with the code. >> >> I will work on that today, is that ok? >> >> For the explanation of what is going on is that now node can be an >> instance variable node, then the behavior that was there was not >> appropriate in the sense that instance variable nodes do not >> understand #scope. >> However, why this validation "(node isTemp or: [requestor >> interactive])" was there in the first place is not that clear to me, >> but it's been there since 1999. >> >> I'll try to build the tests and come up with a better solution. >> >> Cheers, >> >> Jorge >> >> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> Jorge, >>> >>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>> >>> This is the code: >>> >>> "When non-interactive raise the error only if its a duplicate" >>> (node isTemp or: [requestor interactive]) >>> Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] >>> >>> Cheers, >>> Adrian >>> >>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>> >>>> 11243 >>>> ----- >>>> >>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>> Â Â Â Problem fixed: >>>> We cannot have twice the same block arg in a method >>>> >>>> Â Â Â [:each | each ...] >>>> Â Â Â [:each | each ...] >>>> >>>> THANKS jorge :) >>>> Do you like good bio beer? >>>> >>>> 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 >>> >> >> _______________________________________________ >> 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, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

> So how does that sound? Â Just dispatching portions of the various > "printing" methods in subclasses of ParseNode to a Printer that allows > individual preferences to be specified? This thing is called RBConfigurableFormatter and it has been present for the last decade. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Chris Muller

> A conditional +1; can I simply edit and save code without "benefit" of a formatter? That could probably be via an installable "formatter" that does _nothing_ to my code. Given that option, I'm all in favor of what makes others happy. Of course. I think most agree that the machine doesn't dictate anything to the user. The related preferences are: browseWithPrettyPrint, diffsWithPrettyPrint. If you want to actually alter saved format, you must pretty-print the method and save it. I also agree with Dale others who voiced the sentiment that probably not enough consensus can be reached to avoid the work of needing to make a SmalltalkFormatter or SmalltalkPrinter class of some kind. Sigh.. :) So how does that sound? Just dispatching portions of the various "printing" methods in subclasses of ParseNode to a Printer that allows individual preferences to be specified? I don't see anything too grand or fancy being necessary to gain quite a productivity boost out of all of us if we can have the machine format to our liking. Not too fancy will probably work, verbatim, in both the Pharo and Squeak images.. On Thu, Mar 4, 2010 at 2:40 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > A conditional +1; can I simply edit and save code without "benefit" of a formatter? Â That could probably be via an installable "formatter" that does _nothing_ to my code. Â Given that option, I'm all in favor of what makes others happy. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard > Sent: Thursday, March 04, 2010 2:49 PM > To: Pharo Development > Subject: Re: [Pharo-project] about code formatting in pharo > > +1 > > On Mar 4, 2010, at 19:10 , Dale Henrichs wrote: > >> It is obvious that a consensus will not be reached on the "one and only true format." >> >> If my browser displays code formatted the way I want to see it and the difference tools are format neutral (i.e., the source and target code is formatted using the same rules) there is no need to agree on a standard style. For all intents and purposes each developer's favored format _is the standard_. >> >> We only need to agree to disagree and then figure out how to make it possible to customize the formatter and resolve any other technical details (performance and others) that are deemed important. These are technical problems with technical solutions. >> >> Dale >> ----- "Chris Muller" <asqueaker(a)gmail.com> wrote: >> >> | > Another visual problem with "[" and "]" is that they are but one >> | > character, and if you place them together with something else, >> | > like "[self", they lose their visual identity (btw, we read words >> | > in >> | chunks >> | > not by characters) and get harder to spot. It's true that some >> | > fonts and extra coloring could solve this problem, but whitespace >> | > is >> | always >> | > the best and least invasive design weapon. >> | >> | Tudor, for what its worth, the white-space surrounding the blocks is >> | not really at issue or discussion here. Â It's about formatting >> | blocked code into rectangular shapes. >> | >> | In fact, I agree with you about your point about the whitespace. >> | IOW, I prefer: >> | >> | Â Â someVar = someValue >> | Â Â Â Â Â Â ifTrue: [ self doOneThing ] >> | Â Â Â Â Â Â ifFalse: >> | Â Â Â Â Â Â Â Â Â Â [ self >> | Â Â Â Â Â Â Â Â Â Â Â Â Â Â doOtherThing ; >> | Â Â Â Â Â Â Â Â Â Â Â Â Â Â doYetAnotherThing. >> | Â Â Â Â Â Â Â Â Â Â anotherObject doSomething ] >> | >> | Not: >> | >> | Â Â someVar = someValue >> | Â Â Â Â Â Â ifTrue: [self doOneThing] >> | Â Â Â Â Â Â ifFalse: >> | Â Â Â Â Â Â Â Â Â Â [self >> | Â Â Â Â Â Â Â Â Â Â Â Â Â Â doOtherThing ; >> | Â Â Â Â Â Â Â Â Â Â Â Â Â Â doYetAnotherThing. >> | Â Â Â Â Â Â Â Â Â Â anotherObject doSomething] >> | >> | Perhaps if you looked at a longer method example, with nested >> | blocks, you might be able to "see", visually, the blocks more obviously. >> | Perhaps not, I don't know. >> | >> | Regards, >> | Â Chris >> | >> | > The lines are clearly belonging together, [ is clearly observed >> | > and clicking anywhere on the first line after [ will select the >> | > whole >> | block. >> | > >> | > Yet another thing it solves is the consistency between block and >> | > method. They both define behavior, and thus Â it would be great if >> | they >> | > would be treated similarly. This is better seen in the context of >> | > a block with parameter: >> | > >> | > aCollection do: [ :each | >> | > Â Â Â Â Â Â Â Â self something. >> | > Â Â Â Â Â Â Â Â self somethingElse. ] >> | > >> | > Just like a method has the top line with the signature and the >> | > parameters, a block should be the same. In this case, each is a >> | > parameter and it is clearly distinct from everything else. When >> | there >> | > is no parameter, this is information made very clear, too (because >> | of >> | > the absence of anything following [ ). >> | > >> | > >> | > An argument against this convention was that it looks like C and >> | that >> | > blocks are not dumb {. While I understand the built-in adversity, >> | > we are talking about a visual notation that makes sense for >> | > Smalltalk >> | and >> | > not one that make it different from everything else around us. >> | > >> | > Another option would be to have: >> | > boolean ifTrue: >> | > Â Â Â Â [ Â Â Â self clearCaches. >> | > Â Â Â Â Â Â Â Â self current soleInstance yada yada blah blah >> | > Â Â Â Â Â Â Â Â self recomputeAngle ] >> | > >> | > with everything inside the block being aligned. However, this has >> | the >> | > problem of wasting space. One space can also be used, but only >> | > when the font is monospaced, so it would not work in general. >> | Furthermore, >> | > it would be inconsistent or even more space wasting when it comes >> | > to blocks with parameters. >> | > >> | > Cheers, >> | > Doru >> | > >> | > >> | > On 4 Mar 2010, at 03:38, Chris Muller wrote: >> | > >> | >>>> Â Â ifTrue: [ >> | >>>> Â Â Â Â line1 yo. >> | >>>> Â Â Â Â line2 eh ] >> | >>> >> | >>> Horrible, horrible, horrible ;) Â Poor block. Â The block is an >> | >>> object... >> | >> >> | >> Exactly what I was thinking; and how some of the new editor >> | features >> | >> since 3.9, that seem to reify "statements". Â For example, >> | >> clicking inside parens or square-brackets selects that >> | >> statement(s). Â I also really enjoyed the ability to "surround", >> | >> thereby creating >> | additional >> | >> statement-levels. >> | >> >> | >> The whole interaction becomes much more liked working with tiled >> | code >> | >> rather than a text-editor. >> | >> >> | >>> I think the conclusion has to be (and I can confirm that the >> | >>> VisualWorks team was equally divided) that no one formatting >> | >>> regime will make every one happy and that all regimes will make >> | >>> a substantial minority unhappy. Â So perhaps we should step up to >> | >>> having code formatted automatically according to tailorable >> | >>> preferences. >> | >> >> | >> >> | >> >> | >>> My only concern is comment formatting but the way to deal with >> | that >> | >>> is to >> | >>> use automatic formatting and deal with comment problems as they >> | >>> arise. Â I always used to be concerned about e.g. comments >> | >>> spanning multiple lines. >> | >>> Â But without day to day exposure I don't think one can know how >> | >>> much of an issue it is. >> | >> >> | >> As someone who's logged 5-digits of hours in Squeak these last >> | >> few years, I think the best thing is to just not. Â Let 'em wrap! >> | >> Use shout to turn them light gray, so they don't really intrude >> | >> on the code, but are there if you want focus on the extra prose. >> | >> >> | >> Unfortunately, the real problem with comments within BlockNodes >> | >> is >> | how >> | >> they duplicate themselves within the parse-tree.. ouch! Â I hope >> | that >> | >> is what you and Nicolas were talking about or that you'll have a >> | fix >> | >> for that.. >> | >> >> | >>> One upside will be less effort reformatting when indent levels >> | >>> change. Â Have you noticed that Smalltalk tends to be more >> | >>> difficult to reformat than C syntax languages, I guess because >> | >>> of keywords? Â Not having to >> | worry >> | >>> about >> | >>> this could be great. >> | >> >> | >> Very cool, I hope there'll be enough additional consensus to >> | >> adopt these Beckian formats for Squeaks pretty-print refinement. >> | >> >> | >>> Of course, what format gets written to a source file could still >> | be >> | >>> a source >> | >>> of conflict ;) Â We may all want our syntax to be the Â format of >> | >>> record :) >> | >> >> | >> Absolutely. Â To not, would be the machine dictating to the user. >> | >> Invoking automatic formatting is always the users choice. >> | >> browseWithPrettyPrint allows readers to have it formatted >> | dynamically >> | >> if they wish.. >> | >> >> | >> Cheers.. >> | >> >> | >>> P.S. Â and don't get me started on the trailing period (putrid >> | >>> excressence), or the space between ^ and the return expression >> | >>> (vomitous mass). >> | >> >> | >> _______________________________________________ >> | >> Pharo-project mailing list >> | >> Pharo-project(a)lists.gforge.inria.fr >> | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proje >> | >> ct >> | > >> | > -- >> | > www.tudorgirba.com >> | > >> | > "Live like you mean it." >> | > >> | > >> | > _______________________________________________ >> | > Pharo-project mailing list >> | > Pharo-project(a)lists.gforge.inria.fr >> | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-projec >> | > t >> | > >> | >> | _______________________________________________ >> | 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010