December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [OT]: Looking for Bill Schwab

by Sebastian Sastre

Indeed, I have pleasant memories of the Dolphin Smalltalk days and his comments on the list He did many cool things On Dec 26, 2013, at 1:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks. This is surprising, he was really young and this is sad. > > Stef > > I used to enjoy Bill's perspective on things coming to Pharo from Dolphin. It would seem there is unfortunate news. >> http://www.legacy.com/obituaries/gainesville/obituary.aspx?pid=159883187 >> >> Wilhelm "Bill" K. Schwab Ph.D., 48, of Gainesville, Florida, died Friday September 7, 2012 at a friend's home, after a determined battle with cancer. >> [...] His software was far more reliable than the commercial operating systems on which it ran. He even wrote his own "object request broker," a specialized networking software tool, using Smalltalk, an exotic computer language. With his tool, he created, implemented and maintained a fully functional handwriting-capable anesthesia medical record system that was well ahead of its time, and was used for years in actual patient care in multiple operating rooms. His software never required "downtime." >> >> regards -ben >> >

Dec. 26, 2013

Nautilus: tab key change focus

by Juraj Kubelka

Hi, Can someone give me any glue how tab-key-order and handling works in Nautilus? I am trying to fix the tab order in Nautilus but I do not see how it is implemented. Thanks, Jura

Dec. 26, 2013

Re: [Pharo-dev] [OT]: Looking for Bill Schwab

by StÃ©phane Ducasse

Thanks. This is surprising, he was really young and this is sad. Stef I used to enjoy Bill's perspective on things coming to Pharo from Dolphin. It would seem there is unfortunate news. > http://www.legacy.com/obituaries/gainesville/obituary.aspx?pid=159883187 > > Wilhelm "Bill" K. Schwab Ph.D., 48, of Gainesville, Florida, died Friday September 7, 2012 at a friend's home, after a determined battle with cancer. > [...] His software was far more reliable than the commercial operating systems on which it ran. He even wrote his own "object request broker," a specialized networking software tool, using Smalltalk, an exotic computer language. With his tool, he created, implemented and maintained a fully functional handwriting-capable anesthesia medical record system that was well ahead of its time, and was used for years in actual patient care in multiple operating rooms. His software never required "downtime." > > regards -ben >

Dec. 26, 2013

Re: [Pharo-dev] PackageTreeNautilus (undestroyable?)

by StÃ©phane Ducasse

https://pharo.fogbugz.com/default.asp?12513 On 19 Dec 2013, at 22:25, Nicolai Hess <nicolaihess(a)web.de> wrote: > Hi, > > I recently noticed a awful big number of Announcer instances (thousends). > I traced them back to PackageTreeNautilus. I closed the unsaved image > and reopened pharo. > I couldn't reproduce this but found out, that if you opened Nautilus once, > there will allways be one instance of PackageTreeNautilus > even if you close all windows. > > How to reproduce: > Load a freshly image. > > Announcer allInstances size.-> 155 > PackageTreeNautilus allInstances size. -> 0 > > Open and close Nautilus. > > SmalltalkImage current garbageCollect. > Announcer allInstances size. -> 1261 > PackageTreeNautilus allInstances size. -> 1 > > This instance of PackageTreeNautilus won't go away. > Is this intended? > > > Nicolai

Dec. 26, 2013

Re: [Pharo-dev] [squeak-dev] Re: Why Color rgb components are on 10 bits?

by StÃ©phane Ducasse

> > Absolutely no idea. > BitBlt is rich enough (color maps or direct color components, depths, endianness) to make this unpredictable by simply analyzing sender chain in source code (it's too deep and convoluted). > The best way is to try it, but then one must choose a benchmark, and here again it is a difficult decision, because maybe you didn't bench a path that some other use intensively, how to guess without above analysis? > > I saw those un-necessary mismatch while analyzing Graphics code... > By a principle of economy, I suggest to remove them. > Simplifying code a little bit is already a win. > > BTW, did you see that scaled rgb components use 10bits while scaled alpha uses 8? No :) because Iâm totally ignorant of this part and I need time to learn and Iâm too busy and too sick because I work too much. > This was in Squeak already and has been perpetuated in Pharo refactoring...

Dec. 26, 2013

Re: [Pharo-dev] [squeak-dev] Re: Why Color rgb components are on 10 bits?

by StÃ©phane Ducasse

> > Thanks for the discussion. Now do you have an idea about the speed gain? > > Absolutely no idea. > BitBlt is rich enough (color maps or direct color components, depths, endianness) to make this unpredictable by simply analyzing sender chain in source code (it's too deep and convoluted). > The best way is to try it, but then one must choose a benchmark, and here again it is a difficult decision, because maybe you didn't bench a path that some other use intensively, how to guess without above analysis? > > I saw those un-necessary mismatch while analyzing Graphics code... > By a principle of economy, I suggest to remove them. > Simplifying code a little bit is already a win. > > Then, les petits ruisseaux font les grandes riviÃ¨res, cumulated micro optimizations may pay. Ok yes We are doing that since years. > > > > > Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats... > > > > Thoughts?

Dec. 26, 2013

Re: [Pharo-dev] float printing glitch?

by StÃ©phane Ducasse

On 25 Dec 2013, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2013/12/25 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > > 2013/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > thanks nicolas. > I will give a try. > > > I just made a quick pass in Squeak, analyzed senders of roundTo: and modified a few whose sole intention was printing. > This need to be redone in Pharo. > > Ah, but Squeak has Number>>printOn:maxDecimalPlaces: and printShowingMaxDecimalPlaces: and Stream>>print:maxDecimalPlaces: I somehow understand why and I think that this is ok to add them to pharo. > > It would be required to add those messages first. > > > On 24 Dec 2013, at 18:15, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Yes, you should change the tickPrintBlock because it probably incorrectly use (aFloat roundTo: 0.1) printString. >> There is no guaranty that this return the nearest Float to the aimed decimal fraction. >> Since this is not the nearest Float, you have additional digits displayed. >> The print block should use a selector like printShowingDecimalPlaces: (Squeak) or something equivalent in Pharo (can't remember if the selectors are 100% compatible). >> >> For completeness, do test these expressions: >> (0 to: 10) collect: [:i | (i/10) asFloat]. >> versus >> (0 to: 10) collect: [:i | i*0.1]. >> versus >> (0 to: 10) collect: [:i | (i/10) roundTo: 0.1]. >> >> Only the first one is correct. Trying to roundTo: 0.1 spoils thing because 0.1 is not exactly 1/10 and thus introduce small errors... >> >> >> 2013/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Hi (nicolas :)) >> >> I was fixing the sound package and the EnvelopeEditorMorph shows a strange glitch >> >> EnvelopeEditorMorph openOn: (FMSound brass1) copy title: 'brass1' >> >> See ^^^^^^^^^^^^^^^^ below >> >> I have the impression that this related to float printString. Any idea how to fix it? >> >> >> >> >> >> buildLabels >> | scale x1 y1 y2 captionMorph loopStart offset | >> majorTickLength * minorTickLength < 0 >> ifTrue: [ minorTickLength := 0 - minorTickLength ]. >> self removeAllMorphs. >> caption ifNotNil: >> [ captionMorph := StringMorph contents: caption. >> offset := captionAbove >> ifTrue: [majorTickLength abs + captionMorph height + 7] >> ifFalse: [2]. >> captionMorph >> align: captionMorph bounds bottomCenter >> with: self bounds bottomCenter - (0 @ offset). >> self addMorph: captionMorph]. >> tickPrintBlock ifNotNil: >> ["Calculate the offset for the labels, depending on whether or not >> 1) there's a caption >> below, 2) the labels are above or below the ticks, and 3) the >> ticks go up or down" >> offset := labelsAbove >> ifTrue: [majorTickLength abs + minorTickLength abs + 2] >> ifFalse: [2]. >> caption >> ifNotNil: [captionAbove ifFalse: [offset := offset + captionMorph height + 2]]. >> scale := (self innerBounds width - 1) / (stop - start) asFloat. >> x1 := self innerBounds left. >> y1 := self innerBounds bottom. >> y2 := y1 - offset. >> "Start loop on multiple of majorTick" >> loopStart := (start / majorTick) ceiling * majorTick. >> loopStart to: stop >> by: majorTick >> do: >> [ :v | | x tickMorph | >> x := x1 + (scale * (v - start)). >> tickMorph := StringMorph contents: (tickPrintBlock value: v). >> ^^^^^^^^^^^^^^^^ printString? >> >> tickMorph align: tickMorph bounds bottomCenter with: x @ y2. >> tickMorph left < self left >> ifTrue: [ tickMorph position: self left @ tickMorph top ]. >> tickMorph right > self right >> ifTrue: [ tickMorph position: (self right - tickMorph width) @ tickMorph top]. >> self addMorph: tickMorph ]] >> > > >

Dec. 26, 2013

Re: [Pharo-dev] float printing glitch?

by StÃ©phane Ducasse

On 25 Dec 2013, at 23:39, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2013/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > thanks nicolas. > I will give a try. > > > I just made a quick pass in Squeak, analyzed senders of roundTo: and modified a few whose sole intention was printing. > This need to be redone in Pharo. If you do it and publish the code we will happily integrate that in Pharo because so far we do not have much expertise in this domain. Stef > > On 24 Dec 2013, at 18:15, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Yes, you should change the tickPrintBlock because it probably incorrectly use (aFloat roundTo: 0.1) printString. >> There is no guaranty that this return the nearest Float to the aimed decimal fraction. >> Since this is not the nearest Float, you have additional digits displayed. >> The print block should use a selector like printShowingDecimalPlaces: (Squeak) or something equivalent in Pharo (can't remember if the selectors are 100% compatible). >> >> For completeness, do test these expressions: >> (0 to: 10) collect: [:i | (i/10) asFloat]. >> versus >> (0 to: 10) collect: [:i | i*0.1]. >> versus >> (0 to: 10) collect: [:i | (i/10) roundTo: 0.1]. >> >> Only the first one is correct. Trying to roundTo: 0.1 spoils thing because 0.1 is not exactly 1/10 and thus introduce small errors... >> >> >> 2013/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Hi (nicolas :)) >> >> I was fixing the sound package and the EnvelopeEditorMorph shows a strange glitch >> >> EnvelopeEditorMorph openOn: (FMSound brass1) copy title: 'brass1' >> >> See ^^^^^^^^^^^^^^^^ below >> >> I have the impression that this related to float printString. Any idea how to fix it? >> >> >> >> >> >> buildLabels >> | scale x1 y1 y2 captionMorph loopStart offset | >> majorTickLength * minorTickLength < 0 >> ifTrue: [ minorTickLength := 0 - minorTickLength ]. >> self removeAllMorphs. >> caption ifNotNil: >> [ captionMorph := StringMorph contents: caption. >> offset := captionAbove >> ifTrue: [majorTickLength abs + captionMorph height + 7] >> ifFalse: [2]. >> captionMorph >> align: captionMorph bounds bottomCenter >> with: self bounds bottomCenter - (0 @ offset). >> self addMorph: captionMorph]. >> tickPrintBlock ifNotNil: >> ["Calculate the offset for the labels, depending on whether or not >> 1) there's a caption >> below, 2) the labels are above or below the ticks, and 3) the >> ticks go up or down" >> offset := labelsAbove >> ifTrue: [majorTickLength abs + minorTickLength abs + 2] >> ifFalse: [2]. >> caption >> ifNotNil: [captionAbove ifFalse: [offset := offset + captionMorph height + 2]]. >> scale := (self innerBounds width - 1) / (stop - start) asFloat. >> x1 := self innerBounds left. >> y1 := self innerBounds bottom. >> y2 := y1 - offset. >> "Start loop on multiple of majorTick" >> loopStart := (start / majorTick) ceiling * majorTick. >> loopStart to: stop >> by: majorTick >> do: >> [ :v | | x tickMorph | >> x := x1 + (scale * (v - start)). >> tickMorph := StringMorph contents: (tickPrintBlock value: v). >> ^^^^^^^^^^^^^^^^ printString? >> >> tickMorph align: tickMorph bounds bottomCenter with: x @ y2. >> tickMorph left < self left >> ifTrue: [ tickMorph position: self left @ tickMorph top ]. >> tickMorph right > self right >> ifTrue: [ tickMorph position: (self right - tickMorph width) @ tickMorph top]. >> self addMorph: tickMorph ]] >> > >

Dec. 26, 2013

Re: [Pharo-dev] Transparent colors with NBOpenGL?

by StÃ©phane Ducasse

This sounds really exciting :) > That sounds very interesting. I dream of a virtual world environment such as Second Life, highly dynamic and completely open source. Croquet was going in that direction and this is good to improve the infrastructure of Pharo in that direction. Better interaction with C and C++ is definitively a big plus. > But currently I would like to do a simple video game, with toon like graphic, using bullet for physics. I think that making an actual game development pipeline would be very interesting. Yes :) Now let us start small and focus on key elements. Clement was suggesting that we could even launch a kick starter :) > I would not create a full level editor, modeling software because it takes too much time, and there is Blender which is open source and very complete. > > Some tasks required are as follow: > - An easy way to make bindings for C++ libraries. For this I am going to start extending SWIG(http://www.swig.org/) so it can generate bindings for Pharo NativeBoost. > - Bindings for the Bullet physics engine(http://bulletphysics.org/wordpress/). With the extensions for swig, this is trivial. Did you see that esteban and JB did a binding to another physic engine (forgot his name). > - An importer for COLLADA. COLLADA is a XML based asset exchange format, with a wide support in different 3d model editors, such as Blender. We could turn that into a student project. > - For Linux, a new VM display module is required. The current that uses just X11 suffers of severe tearing and flickering. I would like to make a display module for the VM that uses SDL2, which is a cross platform library that supports hardware accelerated graphics, or cross platform creation of an OpenGL context. Iâm sure that igor wants to have a look at that. > - I think that garbage collection would require some determinism/time constraint or write some guidelines to avoid triggering the gargbage collector. When I'm testing the particles, I can see some noticeable pause, that I attribute to the garbage collector. Eliot Miranda is working a new GC and it is much much much better. No global GC needed anymore. So for Pharo 40 we will get a lot of improvements from this part. We are really excited because it opens a lot of space > > Greetings, > Ronie Salgado > > > 2013/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Ronie > > I was talking about 3D with Igor (because Igor came to Smalltalk because he wanted to use it as a game engine and built rendering > engine in Pascal long long time ago :). > So I was brainstorming to see what you could do. > > the last time alex show roassal 3D we were thinking that it would be good to build a kickstarter show case on something > sexy (maybe bridging a physical model to 3D)â¦. > > Now what would like to build with NBOpenGL? What are your dreams and how > could we slice them into tasks that could be reached in a limited amount of time. > > Stef >

Dec. 26, 2013

Re: [Pharo-dev] [OT]: Looking for Bill Schwab

by btc＠openinworld.com

Dec. 26, 2013