July 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20230

by Marcus Denker

20230 ----- Issue 6432: fix date and time parsing http://code.google.com/p/pharo/issues/detail?id=6432 Issue 3665: asStringOrText should invoke asString http://code.google.com/p/pharo/issues/detail?id=3665 Issue 6414: Failing Test on Mac: FileDialogWindowTest.testIssue6406 http://code.google.com/p/pharo/issues/detail?id=6414 -- Marcus Denker -- http://marcusdenker.de

July 22, 2012

Re: [Pharo-project] fuelized test failures

by Marcus Denker

On Jul 22, 2012, at 10:00 AM, StÃ©phane Ducasse wrote: > I love that scenario :) > This is great that powerful tools let us imagine and build solutions that would not be possible > before. Power to imaginationâ¦ > And it is an example for a building block that helps to build things. Things that are *impossible* without it. Another way to view Fuel is that of a scientific experiment: We empirically study the existing (ImageSegment). Without pre-concived notions to replace it! (We actually thought ImageSegments would turn out to be the greatest thing ever and just needed some documentation/more understandable implementation). -> You study the existing -> You claim that you can do better -> You do better. And then the next step is *extremeley* importnat: -> You prove that it is better for real by *replacing* ALL the existing subsystems that do the same. That last part is very essential: in the end, you often see that it is actually not that easy. So *replacing* is important. The other thing important is to realize that it enables things that are impossible without. There are people that claim that instead of Pharo, what we should have done is to just do our research on top of an unchanged Squeak. (While not even trying to improve Squeak itself). But I really wonder... just project Pharo some more years in the Future. Will that what we will be able to do even be *thinkable* in the context of an unchanged Squeak 3.8? Marcus -- Marcus Denker -- http://marcusdenker.de

July 22, 2012

Re: [Pharo-project] athens for strikefonts

by Tudor Girba

Hi Igor, First of all, how was your holidays? :) A while ago, you said that supporting StrikeFonts would not be that difficult. For me it would be important to have this support in order to have a smooth transition to Athens even without Cairo. So, what would it take for this support to happen? Cheers, Doru On 11 Jul 2012, at 09:04, Tudor Girba wrote: > Aha. Ok. I will wait. > > Doru > > > On Wed, Jul 11, 2012 at 8:43 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Good idea if possible. >> Igor like me is on vacation until 19 of july. >> >> On Jul 10, 2012, at 7:07 AM, Tudor Girba wrote: >> >>> Hi Igor, >>> >>> I just wanted to ask: is the little fix of having Athens work with StrikeFont still on the roadmap :)? >>> >>> As I mentioned before, this would make the adoption easier, because we can switch the Athens even with the regular CogVMs. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "It's not what we do that matters most, it's how we do it." >>> >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

July 22, 2012

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

by StÃ©phane Ducasse

Phil Sorry for the state of the system. We are cleaning slowly. Now what would be good is that if you could enhance the class comments. Igor started to write a new paragraph (or text representation) I guess that he needs some help/feedback. Igor should be back from holiday so ping him please :). Stef > Ah, the morass into which I am currently digging... > > Well, if we look at it for a while, it becomes a tad clearer. > > PluggableTextMorph is just a shell for a TextMorph. > > The TextMorph basically displays a Text (which can be styled with TextAttributes) > > When moving into edition, there is an editor known by the TextMorph but this is not an editor like I understood it, but rather a helper object that will come handy with TextMorph>>handleInteraction: interactionBlock > > Inside handleInteraction, there is that editor and paragraph and then a call to interaction blockValue. > > And the interactionBlock is containing a bunch of various things that delegate the real editing work to the editor. > > Like in aTextMorph>>handleInteraction: [editor mouseUp: evt] > > If you then look into the editor (mostly SmalltalkEditor right now in the image), you see a quite large method for that mouseUp: evt handling. And lots of other things. > > There should be a cleanup occuring in the Editor -> TextEditor -> SmalltalkEditor hierarchy. > > The TextEditor knows a bit too much and I am currently implementing a child of TextEditor to have a simple, clean editor that does only the basics for my purpose. Once I am please with it, it may become an interesting child of Editor (maybe the TextEditor itself, with TextEditor renamed to something else (for example, TextEditor has something with codeCompletionAround). > > TextEditor and friends do have a ton of class side methods with all the commands, keystrokes, and menu entries. Very important to grasp how that works. > > The TextMorph>>editorClass returns the editor class to use. Currently the SmalltalkEditor (yikes!) > > If gets taken in TextMorph>>installEditorToReplace: priorEditor, where we get editor := self editorClass forMorph: self. > > digging further, we get TextEditor>>forMorph: aMorph returning > > ^self basicNew initWithMorph: aMorph. > > and ... we'll get there! ... TextEditor>>initWithMorph: aMorph > > super initialize. > morph := aMorph. > self resetState. > > So, we now have both linked. > > That dance occurs everytime we get something occuring to the TextMorph. > > >>handleEvent: anEvent will do anEvent sendTo: self and then the usual: > > evt sendTo: anObject, which will handle the event with ^anObjject handleMouseUp, donw, ... > > That is where we get back to the self handleInteraction: evt which calls the [editor mouseUp: evt] through the TextMorph handleInteraction. > > An interesting bit occurs with the TextMorph>>yellowActivity; shiftKeyState for the menus (and the PragmaMenuBuilder and strings like 'smalltalkMenu' looking into SmallTalk editor for menu entries (Class side, yellowButtonMenu and shifted friend). > > That's it for editor, except we need to say a word on its lifecyle: > > It gets created and destroyed all the time: created with TextMorph>>hasFocus, going away with keyBoardFocusChange > > > Then for Paragraph, just realize that Paragraphis something to be used like; > > Paragraph new > compose: text "Coming from the TextMorph" > style: textStyle copy "always copy these beasties" > from: 1 > in (0@0 extent: extX@extY); > adjustRightX; > ... > > So, the Paragraph is composing the text into an area, taking into account the styles that are in the text The TextStyle is the default style, it can be overriden by some TextAttribute. > > And that's where the TextMorph>>drawOn: aCanvas comes into play. > > if will invoke Canvas>>paragraph: which will draw the text. > > This will lead us to CharacterScanner and friends (CompositionScanner) and TextComposer depending on it. > > look for composeLineFrom: to: .... or composeAllLines. > > This will call Paragraph>>composeAll > > ^self multiComposeLinesFrom: firstCharIndex > to: text size > delta: 0 > into: OrderedCollection new "Ah, there we will end up into" > priorLines: Array new > atY: container top. > > > So, it may be interesting to see how Paragraph works, but paragraph has nothing to do with Editor. > > Paragraph renders the text if an editing change has to be shown display wise. But doesn't know about the Editor. > > TextMorph uses TextMorph>>updateFromParagraph and >>fit to do the stuff. > > In CharacterScanner you can find interesting display code: > > CharacterScanner>>basicScanCharactersFrom: startIndex > to: stopIndex > in: sourceString > rightX: rightX > stopConditions: stops "this one still a tad foggy to me" > kern: kernDelta > > There is a primitive rendering a char down there. This is all for StrikeFont. I don't know how TrueType is supported but there are > > As you are doing Vim keystrokes, check TextMorph>>basicKeyStroke that does the same dance as the mouse events but invokes > > self handleInteraction: [editor keystroke evt] > self updateFromParagraph. > super keystroke: evt. > > So, hope this makes it all a bit clearer. > > All of the PluggableTextMorph story builds upon all of the above to ensure a scrolling window and widget pluggability. Which I do not care at this point since I am designing a specific UI for a game. > > Phil > > 2012/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 16, 2012, at 9:38 PM, Sean P. DeNigris wrote: > > > For VimPharo, I want to have a different cursor depending on whether a tool > > is in insert or normal mode. > > > > I tried a handful of ways, but they all failed or worked > > partially/inconsistently. Here's some of them: > > * add the state to the paragraph, but the entire paragraph gets replaced > > during the life of the tool, so the state gets lost > > * add the state to the editor, but the situation is the same > > * add the state to PluggableTextMorph, override and access it from > > TextMorphForEditView>>updateFromParagraph. This was an extreme PITA and got > > me very acquainted with the emergency evaluator. It "worked", but only after > > using the arrows a bit. > > > > Does anyone have any idea where I might hook in? > > > > <rant>I find the whole text system very confusing. What the heck does a > > paragraph know about insertion points?? A view has one paragraph object, > > even if there are several paragraphs (as understood by the rest of humanity > > as a block of text with breaks between the adjoining ones. Editors and > > Paragraphs are thrown out and replaced on a whim. I'm finding it very hard > > to understand and modify</rant> > > I got burned by that when I worked on my botanics envâ¦. > it was terrible. > > > > > Thanks, > > Sean > > > > -- > > View this message in context: http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tp46402… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > >

July 22, 2012

Re: [Pharo-project] Brain storming request: Semantic zooming for Roassal

by StÃ©phane Ducasse

Zooming is interesting and since Athens canvas is opening the vectorial space we should definitively try. I have serious doubt that this can of modeling will go anyway. It may be a fun master or bachelor topics. Now I would like to be able to build the same with Pharo: clean event nice support for zoom and we are getting closer and closer. Stef On Jul 19, 2012, at 10:33 PM, Alexandre Bergel wrote: > Hi! > > I've just found this video: > http://cel.inf.usi.ch/index.php?action=gallery > > I am not sure I really want to program a tetris that way, but the tool they have is interesting. It intensively use zooming in and out. When you zoom in, you see different objects and when you zoom out they disappear or they change their visual representation. > > For Roassal, we are thinking about adding new graphical elements when a particular height of the camera is reached. The elements will then disappear when the camera is getting altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario for a better mechanism? > > Is there anything else you guys want to see in this zooming ability? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

July 22, 2012

Re: [Pharo-project] [NativeBoost] fxch instruction not working... crash

by Igor Stasenko

Most probably it generates invalid opcode. Need to check that with disassembler. On 22 July 2012 05:27, Lawson English <lenglish5(a)cox.net> wrote: > Still playing with Native Boost assembler. > > This code instantly crashes Pharo 1.4 with NB installed: > > TestAssem swapDoubFirst: 1.0 withSecond: 2.0. > > > > TestAssem>>swapDoubFirst: r1 withSecond: r2 > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ NBFFICallout cdecl: #( double ( double r1, double r2 )) > emitCall: [:gen | | asm proxy smpfr scnt| > asm := gen asm. > proxy := gen proxy. > > asm pop: asm ECX. > asm fld: asm ESP ptr64 . > asm fld: asm ESP ptr64 + 8 . > > > asm fxch: asm ST0. > ] > > -- > Squeak from the very start (introduction to Squeak and Pharo Smalltalk for > the (almost) complete and compleate beginner). > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > -- Best regards, Igor Stasenko.

July 22, 2012

Re: [Pharo-project] fuelized test failures

by StÃ©phane Ducasse

I love that scenario :) This is great that powerful tools let us imagine and build solutions that would not be possible before. Power to imaginationâ¦ It fits perfectly with one of the motto of Pharo: Inventing the future. On Jul 20, 2012, at 6:09 PM, Camillo Bruni wrote: > From now on all the test-failures are serialized on the build server. > > This allows us to quickly find the cause of a failing test: > - download the .fuel file for the failing test > - materialize the .fuel in the image and debug the code > | aContext | > aContext := FLMaterializer materializeFromFileNamed: 'PharoDebug.fuel'. > Debugger openContext: aContext label: 'This is the new debugger!' contents: nil > > The serialized stack trace is very limited (generally only 2 contexts) but they > are enough to get a decent view on what the variables are

July 22, 2012

[Pharo-project] [NativeBoost] fxch instruction not working... crash

by Lawson English

Still playing with Native Boost assembler. This code instantly crashes Pharo 1.4 with NB installed: TestAssem swapDoubFirst: 1.0 withSecond: 2.0. TestAssem>>swapDoubFirst: r1 withSecond: r2 <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout cdecl: #( double ( double r1, double r2 )) emitCall: [:gen | | asm proxy smpfr scnt| asm := gen asm. proxy := gen proxy. asm pop: asm ECX. asm fld: asm ESP ptr64 . asm fld: asm ESP ptr64 + 8 . asm fxch: asm ST0. ] -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

July 22, 2012

[Pharo-project] [ANN] humane assessment / moose courses

by Tudor Girba

Hi, Humane assessment is a method for making software engineering decisions. Assessing software systems to make decisions is a critical activity that needs to be approached explicitly during development. Humane assessment is made possible by the Moose analysis platform. I am organizing a couple of courses in Bern that might be of interest to people on this list: Humane Assessment Primer (August 17) - This course is relevant for both managers and engineers. It covers assessment economics and the means to integrate humane assessment in the development process and in the organization - http://www.humane-assessment.com/courses/humane-assessment-primer Moose Apprentice (September 6-7) - This course is relevant for engineers. This is an introductory hands-on course on using the Moose analysis platform for putting humane assessment into practice - http://www.humane-assessment.com/courses/moose-apprentice If you are interested in participating, please contact me directly. Cheers, Doru -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

July 21, 2012

Re: [Pharo-project] fuelized test failures

by Mariano Martinez Peck

On Sat, Jul 21, 2012 at 3:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Wow! This is truly science fiction. > > hehehe yes, but there are still some problems when serializing contexs/debuggers. I would like to clarify the possible problems. When you serialize a context, we serialize all the context state together with its sender, and the sender has a sender, and a sender...so you end up serializing the whole list of contexts. That means that: 1) the object graph that you serialize, and hence, the stream size can be REALLY large depending on what the contexts have. Sometimes a context end up in the UI, so you end up serializing lots of morphs, colors, forms, etc. So..if everything is fine, it should be a couple hundred or thousands KB in the file. If it start to be in MB...then you may be serializing too much. 2) the same problem of 1) is that not only the graph is too big, but also that you incorporate objects (mostly when these are objects from the UI) that CHANGE while being serialized. This will cause Fuel to throw an error saying the graph has changed during serialization. 3) if 2) happens, then depending where you trigger the fuel serialization, you may end up in a loop. For example, say you want to serialize each error with Fuel. So you change SmalltalkImage>>logError:inContext: to write the context with Fuel. Now, if 2) happens and Fuel throws an error, you will try to log that again, causing again the serialization.... infinitive loop. So...some workarounds you may try to do (still, not sure if will help in all cases): 1) Deep copy the context before serializing it. 2) If you want to serialize particular contexts (for example, particular domain exceptions) then you may know WHERE to hook to make some instVars transient and therefore avoid serializing things you don't want and that may cause 2). 3) Copy the context, and actually serialize a PART of it. Cheers, > Cheers, > Doru > > > On 20 Jul 2012, at 18:09, Camillo Bruni wrote: > > > From now on all the test-failures are serialized on the build server. > > > > This allows us to quickly find the cause of a failing test: > > - download the .fuel file for the failing test > > - materialize the .fuel in the image and debug the code > > | aContext | > > aContext := FLMaterializer materializeFromFileNamed: > 'PharoDebug.fuel'. > > Debugger openContext: aContext label: 'This is the new debugger!' > contents: nil > > > > The serialized stack trace is very limited (generally only 2 contexts) > but they > > are enough to get a decent view on what the variables are > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > -- Mariano http://marianopeck.wordpress.com

July 21, 2012