- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] fuelized test failures

by Tudor Girba

Wow! This is truly science fiction. 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."

July 21, 2012

[Pharo-project] glamorous inspector - extensions

by Tudor Girba

Hi, I see that there is a bit of an interest in the GTInspector, so here are some extra info about it. Beyond the things you can do out-of-the-box with it, the true power of the inspector comes from its extensibility. The idea is to offer each object an easy way to exhibit its own characteristics. This changes the way you can think of interacting with objects. Some more details here: http://www.humane-assessment.com/blog/equal-browsing-opportunity-for-every-… A new feature is the ability to edit code directly in the methods presentation. Combined with the possibility of executing a method in place and previewing the result, this opens the door for a prototype-like programming style. The GTInspector is part of the Glamorous Toolkit. It is still in its infancy, but I think it shows that there is a great deal of possibilities to improve the IDE and to depart from the what we might think is a given. I am still looking for people interested in joining this effort (remember the idea of the ide taskforce). It would be great to get more people interested in improving this part of Pharo. Cheers, Doru p.s. You can get the Glamorous Inspector in the following ways: - download the Moose image: http://www.moosetechnology.org/download/4.7 - download Pharo 1.4 (summer) with the Glamorous Inspector: http://ci.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessf… - load it in Pharo 1.4: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. ((Smalltalk at: #ConfigurationOfGlamoroust) project version: #development) load: 'GT-Inspector' -- www.tudorgirba.com "Live like you mean it."

July 21, 2012

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

by Fernando Olivero

Hi Phil. Excellent summary of the current mess! Yes, TextMorphs are the "views" , Editors handle the insertion/selection/menu logic, and Paragraphs lay out the text. I've replaced Paragraph, with Pango Layouts to reuse a more customizable layout engine, until some kind soul rewrites completely Paragraph (and friends) to be as easy to use (and powerfull) as Pango (which i doubt it will happen in the next decade). Denis, unfortunately i had to handle other stuff related to my phd, and still couldn't release Gaucho/Shapes, I'm working on it now again. Here's a presentation i gave @ the pharo conf [1]. Glad to hear that you want to try to use it for Presently, will be out soon. [1] http://app.sliderocket.com:80/app/FullPlayer.aspx?id=fcff251e-29cd-49eb-89b… On Fri, Jul 20, 2012 at 4:26 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > So, there is the damn caret drawing code: > > Paragraph>>displaySelectionInLine: line on: aCanvas > | leftX rightX w caretColor | > selectionStart ifNil: [^self]. "No selection" > aCanvas isShadowDrawing ifTrue: [ ^self ]. "don't draw selection with shadow" > selectionStart = selectionStop > ifTrue: > ["Only show caret on line where clicked" > > selectionStart textLine ~= line ifTrue: [^self]] > ifFalse: > ["Test entire selection before or after here" > > (selectionStop stringIndex < line first > or: [selectionStart stringIndex > (line last + 1)]) ifTrue: [^self]. "No selection on this line" > (selectionStop stringIndex = line first > and: [selectionStop textLine ~= line]) ifTrue: [^self]. "Selection ends on line above" > (selectionStart stringIndex = (line last + 1) > and: [selectionStop textLine ~= line]) ifTrue: [^self]]. "Selection begins on line below" > leftX := (selectionStart stringIndex < line first > ifTrue: [line ] > ifFalse: [selectionStart ])left. > rightX := (selectionStop stringIndex > (line last + 1) or: > [selectionStop stringIndex = (line last + 1) > and: [selectionStop textLine ~= line]]) > ifTrue: [line right] > ifFalse: [selectionStop left]. > selectionStart = selectionStop > ifTrue: > [rightX := rightX + 1. > w := self caretWidth. > caretRect := (leftX-w) @ line top corner: (rightX+w)@ line bottom. > self showCaret ifFalse:[^self]. > caretColor := self insertionPointColor. > 1 to: w > do: > [:i | > "Draw caret triangles at top and bottom" > > aCanvas fillRectangle: ((leftX - w + i - 1) @ (line top + i - 1) > extent: ((w - i) * 2 + 3) @ 1) > color: caretColor. > aCanvas fillRectangle: ((leftX - w + i - 1) @ (line bottom - i) > extent: ((w - i) * 2 + 3) @ 1) > color: caretColor]. > aCanvas fillRectangle: (leftX @ line top corner: rightX @ line bottom) > color: caretColor] > ifFalse: > [caretRect := nil. > aCanvas fillRectangle: (leftX @ line top corner: rightX @ line bottom) > color: self selectionColor] > > > > > Paragraph class>>insertionPointColor has the color. I was fed up of blue, turned it red :-) > This one is hardcoded and could take a hint from the selection color twiceDarker for example. > > Phil > > 2012/7/20 Denis Kudriashov <dionisiydk(a)gmail.com<mailto:dionisiydk@gmail.com>> > Hello > > 2012/7/20 Fernando Olivero <fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>> > Hi Sean, you can take a look at Athens-PangoCairo (in squeaksource). > > Using NativeBoost, i'm using the Pango layout library [1], and the > Pango-Cairo binding [2], to avoid laying out text using the outdated > (and messy) stuff in the image. > > Check out the classes: ParagraphDescription & AthensPangoCairoParagraph. > > I'm using them as the basis for the TextShape,LabelShape, and > EditableTextShape in Shapes / Gaucho ( using TextEditor, > SingleLineEditor ). > > Maybe somebody can do the same for Morphic? use Pango to layout the > text, and code a new TextMorph on top of it? > > How I can try your code? > Do you have ready image to play with it? > > I am very interested with clean and simple alternative to morphic. I want it for Presenty framework. > > (But I really like morphic as live user interface environment) > > Best regards, > Denis > > > > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be<mailto:phil@highoctane.be> | Web: http://philippeback.eu | Blog: http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium

July 21, 2012

Re: [Pharo-project] [ANN] Alternative view of a system browser

by Fernando Olivero

Hi, nice work. Looking forward to play with it. Is it similar to the Newspeak browser? Where methods expand in place. Fernando On Wed, Jul 18, 2012 at 7:36 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I do not have a connection to look at it. > But I LOVE the idea. I love the idea that we can prototype fast new tools and rethink how processesâ¦. > Spec is one way to enable that. For example I love the GlamourInspector and it would be great to rewrite it with Spec. > Thanks a lot. > Stef > > On Jul 17, 2012, at 3:12 PM, Goubier Thierry wrote: > >> I believe that the traditional SystemBrowser of Smalltalk of old has been made unusable by the amount of code (and structure) you find in today's Smalltalk images. >> >> So this is to show you an alternative, a different way to browse through packages / classes and methods and code. This is Spec-based. >> >> https://picasaweb.google.com/lh/photo/ic_fRnBXXdyqbiJ5NRP9YtMTjNZETYmyPJy0l… >> >> What is missing / targeted ? >> * Drag and drop reorganisation of the tree as preferred / or as package / category reuse. >> * A good search facility in the tree. It is already keyboard navigation friendly (since the tree view is). >> * Most / All menu methods of a complete System Browser. I'm planning on reusing the OmniBrowser command structure as much as possible (to make it faster). >> * Funny ideas on how to use the tree structure : group / selection display, queries, metrics ... >> ** There is probably a lot more to be done here, but it would probably require Mondrian or other graph visualisation tools. >> >> Expect the code sometime by the end of the week, in a Pharo 2.0 / Pharo 1.4 version. >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> > >

July 21, 2012

[Pharo-project] fuelized test failures

by Camillo Bruni

>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 20, 2012