- Pharo-dev - lists.pharo.org

Re: [Pharo-project] eCompletion tweak for smart characters

by Serge Stinckwich

If you register as a developper on the Google code website, you could modify the wiki by yourself ;-) 2010/8/3 Tim Mackinnon <tamackinnon(a)gmail.com>: > > always create an issue else we forget.... too much stuff to do. > Then conversation is always good. Because we build a shared mindset and we > all learn together > > OK - done (2743) - I followed the instructions > onÂ http://code.google.com/p/pharo/wiki/HowToContributeÂ - which are great (by > the way there are a few typos in that text, and here areÂ simple corrections > - i think its fairly easy to spot the sections they replace): > You can find the license that you should sign > here:Â http://code.google.com/p/pharo/wiki/LicenseAgreement. > We value your fixes and we always try to look at them and give feedback to > you, this works best if you create a bug entry in the bug tracker. Without > it we may have problem giving you feedback or letting you know that there is > another fix. > The most important point is that you check your fix in a fresh (probably > latest) image. There are two alternatives to packaging your code: You can > send a changeset or a set of packages. For complex changes that involves > several packages use a slice as there is a much better merging support. > While we prefer packages, if it is easier for you send changesets, then we > accept those too. > Prepare a changeset with your changes. File it out. Important: Put your Full > name instead of your initials, as it will help up to contact you which is > often necessary. Only alphabetical characters, andÂ Do Not use any spaces. > > > Tim > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Aug. 3, 2010

Re: [Pharo-project] Refactor source method is grayed out?

by Tim Mackinnon

Lucas, which image are you using - and I will load it up and try again (I am using the seaside 3.0rc image - although I did unload oCompletion from it and then load eCompletion - maybe that makes a difference?). I appreciate your patience on this by the way - often I'm not sure which things are supposed to work (or work differently from how I expect). Tim On 3 Aug 2010, at 11:24, Lukas Renggli wrote: > I played a bit with the selection an the enabling of the menus this > morning, however I found it quite confusing if the closest matching > expression is automatically picked. > > I could not reproduce the issue you report with the spaces. In my > image when I select a full expression whitespaces at start and end do > not matter. > > Lukas > > On Tuesday, August 3, 2010, Tim Mackinnon <tamackinnon(a)gmail.com> > wrote: >> Lukas - I logged it as issue 2742 (now that I know its a bit picky, >> I'll select extra spaces as a workaround). >> >> Some day I will learn how some of this works so that I can try and >> help out (from my time spent in Dolphin where RB is tightly >> integrated, it was cool messing around with parse nodes to drive >> better UI tools). >> >> Tim >> >> >> >> I don't see that difference with the space, but it is true that you >> need to select a valid expression to get the menu items enabled. In >> that regard, the conditions could probably be relaxed a bit. >> >> Lukas >> >> -- >> Lukas Renggli >> 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 >> > > -- > Lukas Renggli > 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

Aug. 3, 2010

Re: [Pharo-project] eCompletion tweak for smart characters

by Tim Mackinnon

> > always create an issue else we forget.... too much stuff to do. > Then conversation is always good. Because we build a shared mindset > and we all learn together OK - done (2743) - I followed the instructions on http://code.google.com/p/pharo/wiki/HowToContribute - which are great (by the way there are a few typos in that text, and here are simple corrections - i think its fairly easy to spot the sections they replace): You can find the license that you should sign here: http://code.google.com/p/pharo/wiki/LicenseAgreement . We value your fixes and we always try to look at them and give feedback to you, this works best if you create a bug entry in the bug tracker. Without it we may have problem giving you feedback or letting you know that there is another fix. The most important point is that you check your fix in a fresh (probably latest) image. There are two alternatives to packaging your code: You can send a changeset or a set of packages. For complex changes that involves several packages use a slice as there is a much better merging support. While we prefer packages, if it is easier for you send changesets, then we accept those too. Prepare a changeset with your changes. File it out. Important: Put your Full name instead of your initials, as it will help up to contact you which is often necessary. Only alphabetical characters, and Do Not use any spaces. Tim

Aug. 3, 2010

Re: [Pharo-project] Problem with InstructionPrinter?

by James Ladd

Is that example the recommended way to see a dump of the bytecodes for a method? > Because there are special primitives for that. Try this: > > String streamContents: [ :stream | > (YourClass >> #first) longPrintOn: stream indent: 0 ]. > > > Levente

Aug. 3, 2010

Re: [Pharo-project] eCompletion tweak for smart characters

by StÃ©phane Ducasse

Thanks tim. > Guys - this is my first attempt at a contribution - and I'm not sure how literally to take the advice on "how to contribute to Pharo" for a small change. Should I create an issue, and post it here (happy to do that, but wondered if conversation might be useful first as I'm new to this). always create an issue else we forget.... too much stuff to do. Then conversation is always good. Because we build a shared mindset and we all learn together Now since this is for an external package you can add lukas on the field and he will get notified. > Given that I'm not sure what the relationship between eCompletion and oCompletion is (someone mentioned the latter is built on top of the former?) - so maybe I'm barking up the wrong tree, however I was impressed with how much quicker Lucas' Hudson built pharo image was with eCompletion so I've been trying that for a few days (although I've noticed some mails on oCompletion but haven't gone back to retry it). > > Anyway - I have attached a change set that changes how smart characters work - instead of turning them off because half of the time they do the wrong thing for me and I madly press delete, I wanted to preserve the other half of the time when I'm entering new code and they give me a helpful template. > > My proposed fix is for the following scenario - if I go to add an extra bracket around an expression (becuase I later realise that I need to designate a keyword expression) I get two brackets - and then I backspace and they both go, so then I do it again and press delete... Instead I think there is a heuristic which says that says if you type a smart character with the cursor next to a non-whitespace item, you probably don't want the matching character. e.g. > > 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4 (or the 5) to put the bracket and I get 2, and I really only want one. > > My patch tries to address this. > > I also didn't see any test cases for this stuff (and possibly some could be written - should I try to do that too?). > > Tim<ECControllerTimMackinnon.1.cs> Excellent improving the interface to code is key. Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 3, 2010

Re: [Pharo-project] Something I don't see in ImageSegment

by Mariano Martinez Peck

2010/6/4 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/6/4 Mariano Martinez Peck <marianopeck(a)gmail.com> > > >> >> 2010/6/3 Eliot Miranda <eliot.miranda(a)gmail.com> >> >> Hi Mariano, Hi All, >>> >>> response below. But does anyone have any tests for the image segment >>> primitives? I'm refactoring them and would like some tests. >>> >> >> Hi Eliot. First, congratulations!! I though several times to refactor >> the primitives what I was not brave enough. I was not confidence of myself >> hahaha >> >> Originally, ImageSegment didn't have a single test. Only some class side >> examples that in Pharo at least were not even working. Adrian Lienhard wrote >> the first 2 or 3 tests for them. Then I needed to understand ImageSegment >> for my PhD, and the best way to understand them were writing unit tests ;) >> >> So, now if you take a Pharo 1.1 image you will see there are 26 tests. The >> classes are ImageSegmentTest, ImageSegmentTestExport and >> ImageSegmentTestSwap. The tests are quite simple and cover not too much. >> They can be improved and there are more to write. They may be even not >> completly correct as I wrote them to understand ImageSegment, not because I >> already understood them ;) >> >> In addition, there is one failing that I yet don't understand why: >> #testOutPointers3 >> I asked in mailing list but not really an answer in my opinion: >> >> http://forum.world.st/Something-I-don-t-understand-with-ImageSegments-tp129… >> If you know why it is failing, tell me :) >> > > Its to do with compact classes. > > 'mariano' class indexIfCompact 11 > Object new indexIfCompact 0 > > > The store segment primitive does not consider class references from objects > with compact class as external pointers. Arguably this is a bug because it > means an image segment is only safely loadable into an image with the same > compact classes, but that's a restriction we're willing to live with. > > Thanks Eliot for the hints. But still I don't understand. I didn't understand your comment: "The store segment primitive does not consider class references from objects with compact class as external pointers" In addition, look this example: testOutPointersWithSpecialSharedObjects | anObject segment root a| anObject := TestResult basicNew. anObject timeStamp: Date dateAndTimeNow asString. root := Array with: anObject. segment := ImageSegment new copyFromRoots: root sizeHint: 5000 areUnique: false. self assert: segment outPointers size = 1. self assert: (segment outPointers includes: nil) Of course, this is failing, and the outPointers is: {TestResult. nil}. I don't understand why the CLASS TestResult is there. So..for every simple object I store, it will also store its class? I really really read the primitive to store and try to understand the very low levels. But I cannot see where (image side or primitives) the class can be added to outPointer, nor why. I think it shouldn't be included. Because it is NOT referenced from inside my subgraph. Maybe there is something I am not seeing. I am getting nervous hahahah Now, another question. Date dateAndTimeNow asString answer a ByteString something like this: 'an Array(3 August 2010 12:40:17 pm)' It is ok that this variable is NOT in the outPointers, because it is ONLY accesible from the subgraph. But now, if I change to this: anObject timeStamp: 'an Array(3 August 2010 12:40:17 pm)'. Then outPointers size is 3 and it is: {TestResult. 'an Array(3 August 2010 12:40:17 pm)'. nil} grrrrrrr is that when building string in this way it is referenced from some other place? Thanks!! Mariano > HTH > Eliot > > >> continue answering above... >> >> >>> >>> 2010/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> .... >>>> >>>> But here I see it is only marking Interpreter oops, not all objects. And >>>> I don't see where all objects are marked even in the code that follows this >>>> little piece. >>>> >>> >>> markInterpreterOops marks all objects accessible from the interpreter >>> oops, including the specialObjectsArray, recursively marking any unmarked >>> objects and their referents. i.e. it marks all objects reachable from the >>> roots of the system. >>> >> >> Ok...but where is the roots of the system? it is the instVar rootTable of >> ObjectMemory? so all the root table is also marked? >> >> At the beginning I though it was this that you are saying. But then I >> check in the senders of markAndTraceInterpreterOops and you can see in >> ObjectMemory >> markPhase that it does: >> >> "trace the interpreter's objects, including the active stack >> and special objects array" >> self markAndTraceInterpreterOops. >> statSpecialMarkCount := statMarkCount. >> "trace the roots" >> 1 to: rootTableCount do: [:i | >> oop := rootTable at: i. >> self markAndTrace: oop]. >> 1 to: extraRootCount do:[:i| >> oop := (extraRoots at: i) at: 0. >> (self isIntegerObject: oop) ifFalse:[self markAndTrace: oop]]. >> >> So...it is manually iterating the table. Why? shouldn't be done as you >> told me? >> >> In summary, my question is: is these code doing this (iterating the >> table) even if it is not necessary or ImageSegment should also do it? >> >> >> >>> This would mark all objects in the system were it not for the fact that >>> the primitive marks the rootArray and so markInterpreterOops does not marl >>> objects /only/ reachable from the rootArray. So once the rootArray objects >>> have been unmarked, only those objects that should go in the image segment >>> are unmarked. >>> >>> So the primitive works by >>> - marking the objects in rootArray, preventing marking of objects >>> reachable from them in the next step >>> - recursively marking all objects reachable from the roots (except those >>> already marked) >>> - unmarking root objects, leaving the transitive closure of objects >>> accessible from the roots and no where else unmarked >>> - writing the unmarked objects to an image segment >>> >>> >> yes, this is clear :) >> >> Thanks for the help. >> >> Mariano >> >> >>> >>> HTH >>> Eliot >>> >>> >>>> You can see the comment: "Then do a mark pass over all objects" and even >>>> without the comment it makes sense to mark all objects in order to detect >>>> outPointers. >>>> >>>> Does anyone has a hint? >>>> >>>> Thanks >>>> >>>> Mariano >>>> >>>> _______________________________________________ >>>> 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 >

Aug. 3, 2010

Re: [Pharo-project] Refactor source method is grayed out?

by Lukas Renggli

I played a bit with the selection an the enabling of the menus this morning, however I found it quite confusing if the closest matching expression is automatically picked. I could not reproduce the issue you report with the spaces. In my image when I select a full expression whitespaces at start and end do not matter. Lukas On Tuesday, August 3, 2010, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: > Lukas - I logged it as issue 2742 (now that I know its a bit picky, I'll select extra spaces as a workaround). > > Some day I will learn how some of this works so that I can try and help out (from my time spent in Dolphin where RB is tightly integrated, Â it was cool messing around with parse nodes to drive better UI tools). > > Tim > > > > I don't see that difference with the space, but it is true that you > need to select a valid expression to get the menu items enabled. In > that regard, the conditions could probably be relaxed a bit. > > Lukas > > -- > Lukas Renggli > 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 > -- Lukas Renggli www.lukas-renggli.ch

Aug. 3, 2010

Re: [Pharo-project] eCompletion tweak for smart characters

by Lukas Renggli

Hi Tim, Thank you for the contribution. I will definitely look at it as soon as I get access to a computer again (i am a few days away right now). Testing this would be definitely cool, especially given all the edge cases. It is certainly testable, but kind of tricky to setup everything. Lukas On Tuesday, August 3, 2010, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: > Guys - this is my first attempt at a contribution - and I'm not sure how literally to take the advice on "how to contribute to Pharo" for a small change. Should I create an issue, and post it here (happy to do that, but wondered if conversation might be useful first as I'm new to this). > > Given that I'm not sure what the relationship between eCompletion and oCompletion is (someone mentioned the latter is built on top of the former?) - so maybe I'm barking up the wrong tree, however I was impressed with how much quicker Lucas' Hudson built pharo image was with eCompletion so I've been trying that for a few days (although I've noticed some mails on oCompletion but haven't gone back to retry it). > > Anyway - I have attached a change set that changes how smart characters work - instead of turning them off because half of the time they do the wrong thing for me and I madly press delete, I wanted to preserve the other half of the time when I'm entering new code and they give me a helpful template. > > My proposed fix is for the following scenario - if I go to add an extra bracket around an expression (becuase I later realise that I need to designate a keyword expression) I get two brackets - and then I backspace and they both go, so then I do it again and press delete... Instead I think there is a heuristic which says that says if you type a smart character with the cursor next to a non-whitespace item, you probably don't want the matching character. e.g. > > 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4 (or the 5) to put the bracket and I get 2, and I really only want one. > > My patch tries to address this. > > I also didn't see any test cases for this stuff (and possibly some could be written - should I try to do that too?). > > Tim -- Lukas Renggli www.lukas-renggli.ch

Aug. 3, 2010

Re: [Pharo-project] Refactor source method is grayed out?

by Tim Mackinnon

Lukas - I logged it as issue 2742 (now that I know its a bit picky, I'll select extra spaces as a workaround). Some day I will learn how some of this works so that I can try and help out (from my time spent in Dolphin where RB is tightly integrated, it was cool messing around with parse nodes to drive better UI tools). Tim > > I don't see that difference with the space, but it is true that you > need to select a valid expression to get the menu items enabled. In > that regard, the conditions could probably be relaxed a bit. > > Lukas > > -- > Lukas Renggli > 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

Aug. 3, 2010

[Pharo-project] eCompletion tweak for smart characters

by Tim Mackinnon

Guys - this is my first attempt at a contribution - and I'm not sure how literally to take the advice on "how to contribute to Pharo" for a small change. Should I create an issue, and post it here (happy to do that, but wondered if conversation might be useful first as I'm new to this). Given that I'm not sure what the relationship between eCompletion and oCompletion is (someone mentioned the latter is built on top of the former?) - so maybe I'm barking up the wrong tree, however I was impressed with how much quicker Lucas' Hudson built pharo image was with eCompletion so I've been trying that for a few days (although I've noticed some mails on oCompletion but haven't gone back to retry it). Anyway - I have attached a change set that changes how smart characters work - instead of turning them off because half of the time they do the wrong thing for me and I madly press delete, I wanted to preserve the other half of the time when I'm entering new code and they give me a helpful template. My proposed fix is for the following scenario - if I go to add an extra bracket around an expression (becuase I later realise that I need to designate a keyword expression) I get two brackets - and then I backspace and they both go, so then I do it again and press delete... Instead I think there is a heuristic which says that says if you type a smart character with the cursor next to a non-whitespace item, you probably don't want the matching character. e.g. 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4 (or the 5) to put the bracket and I get 2, and I really only want one. My patch tries to address this. I also didn't see any test cases for this stuff (and possibly some could be written - should I try to do that too?). Tim

Aug. 3, 2010