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

Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)

by Pavel Krivanek

On Thu, Oct 11, 2012 at 11:11 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Oct 11, 2012, at 11:04 PM, Pavel Krivanek wrote: > >> Unfortunately it is not only about a layer between Morphic and Spec. >> Whole Spec design is greatly conforming to Morphic. Check out Spec >> definitions, they look almost like transcription of Morphic calls >> >> MethodToolbar class >> defaultSpec >> <spec> >> ^ { #Panel. >> #changeTableLayout. >> #listDirection:. #rightToLeft. >> #addMorph:. {#model. #browseModel.}. >> #addMorph:. {#model. #sendersModel.}. >> #addMorph:. {#model. #implementorsModel.}. >> #addMorph:. {#model. #versionModel. }. >> #addMorph:. {#model. #dropListModel.}. >> #hResizing:. #spaceFill. >> #vResizing:. #shrinkWrap. } > > This is because this method is out dated, it shold be now > > ^ SpecLayout composed > newRow:[: r | > r > add: #browseModel; > add: #sendersModel; > add: #implementorsModel; > add: #versionsModel; > add: #dropListModel ] > height: 25 Well, at least from the perspective of UI independence it looks much better. -- Pavel > >> >> Of course these methods are implemented only in Morphic classes. Whole >> layout management is directly taken from Morphic. And the Spec >> definitions are unclear and hard to read. They are composed almost >> solely from symbols so it is hard to work with and analyze them with >> our development tools. We have such beautiful metalanguage where to >> create DSL is so easy... >> >> In comparison with OmniBrowser the Spec is big step back. Sorry, I do >> not want to be ugly but I started this impression when I was working >> on Periscope and since that time it is deeper and deeper. >> >> Cheers, >> -- Pavel >> >> >> >> >> >> On Thu, Oct 11, 2012 at 10:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> This method is actually the only one from ComposableModel with direct Morphic binding :) >>>> >>>> >>>> I am still trying to move that away, but I needed the rebuild to work >>>> >>> i think you can introduce own protocol (and put it as extension to >>> morphic, if you want to) >>> so, instead of saying >>> >>> widget removeAllMorphs >>> >>> you will use own extension method ,like: >>> >>> widget specRemoveAllChilds >>> >>> etc (spec here is namespacing prefix for a method, to indicate that it >>> belongs to spec package >>> and to indicate that it is a contract implied between spec and widget) >>> >>>> Ben >>>> >>>> On Oct 11, 2012, at 8:49 PM, Pavel Krivanek wrote: >>>> >>>>> Hi Ben, >>>>> >>>>> I really would like to write Spec binding for Phobos (Esteban will >>>>> want to do it for Mars etc.). But, how to say that, Spec was not >>>>> written with UI Independence in mind :-) Very basic example of that >>>>> fact: >>>>> >>>>> ComposableModel>>buildWithSpec: aSpec >>>>> "Build the widget using the spec name provided as argument" >>>>> | widget | >>>>> >>>>> (self spec notNil and: [ self needRebuild not ]) >>>>> ifTrue: [ | old | >>>>> self needRebuild: true. >>>>> old := self widget. >>>>> old removeAllMorphs. >>>>> self ensureExtentFor: old. >>>>> widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. >>>>> widget submorphs do:[ :e | old addMorphBack: e ]. >>>>> self spec instance: old. >>>>> ^ old ] >>>>> ifFalse: [ widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. ]. >>>>> >>>>> self ensureExtentFor: widget. >>>>> >>>>> ^ widget >>>>> >>>>> Can you please do at least basic steps in the architecture of Spec to >>>>> make it more independent on Morphic? >>>>> >>>>> Cheers, >>>>> -- Pavel >>>>> >>>>> On Wed, Oct 10, 2012 at 12:10 AM, Benjamin >>>>> <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>>> It was part of my battle plan to rule the world ;) >>>>>> >>>>>> We wanted with Nico to part it to Amber to get the Javascript part for free, then generate some XUL :) >>>>>> >>>>>> Anyway, really cool job, and impressive as well :) >>>>>> >>>>>> Ben >>>>>> >>>>>> On Oct 9, 2012, at 11:07 PM, StÃ©phane Ducasse wrote: >>>>>> >>>>>>> It looks really nice. >>>>>>> I imagine that Spec could generate XUL too. >>>>>>> >>>>>>> Stef >>>>>>> On Oct 9, 2012, at 9:48 PM, Pavel Krivanek wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I would like to introduce you Phobos - the XULRunner based Smalltalk >>>>>>>> framework for development of native GUI with standard look&feel for >>>>>>>> Linux, Mac OS X and Windows. >>>>>>>> >>>>>>>> It is based on Zinc, WebSockets and Seaside continuations. For more >>>>>>>> information including more screenshots see the project page: >>>>>>>> >>>>>>>> http://code.google.com/p/phobos-framework/ >>>>>>>> >>>>>>>> You should pay attentions to FAQ too: >>>>>>>> http://code.google.com/p/phobos-framework/wiki/FAQ >>>>>>>> >>>>>>>> Phobos has Seaside-like components and rendering style, can combine >>>>>>>> XUL with HTML or SVG, supports printing etc. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> -- Pavel >>>>>>>> <01.png> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > >

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Alexandre Bergel

This is a great news Alexandre On Oct 12, 2012, at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 12 October 2012 15:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi Igor, >> >> The only reason we were thinking of the bitmap font support was that there >> was no ready-made vm to get people to use the new canvas. >> >> But, if you are getting the vms ready ... this is fantastic. I would say >> that as soon as they are ready Moose will likely move to Athens. >> > Today we got a meeting a one of the decisions made is that > Pharo 2.0 will be shipped with Athens-ready VMs. > As well as Athens will be included as a technology-preview in release. > > This is what people want from me, and i need to deliver :) > >> Cheers, >> Doru >> >> > > > > -- > Best regards, > Igor Stasenko. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2012

Re: [Pharo-project] Some progress on Athens

by Igor Stasenko

On 12 October 2012 17:44, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-10-12, at 14:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 12 October 2012 14:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> It looks nice! Everything on the screen is rendered by Athens? Or only >>> the color bars? >>> >> everything. > > The color bars are transparent images loaded into pharo to show that > alpha blending works properly... > yet those images are still rendered by athens on desktop screen :) -- Best regards, Igor Stasenko.

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Igor Stasenko

On 12 October 2012 15:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > The only reason we were thinking of the bitmap font support was that there > was no ready-made vm to get people to use the new canvas. > > But, if you are getting the vms ready ... this is fantastic. I would say > that as soon as they are ready Moose will likely move to Athens. > Today we got a meeting a one of the decisions made is that Pharo 2.0 will be shipped with Athens-ready VMs. As well as Athens will be included as a technology-preview in release. This is what people want from me, and i need to deliver :) > Cheers, > Doru > > -- Best regards, Igor Stasenko.

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Igor Stasenko

On 12 October 2012 15:28, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 12.10.2012 14:42, Igor Stasenko wrote: >> >> On 12 October 2012 13:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> Athens would indeed be great. And I am happy that this investment has >>> high >>> priority in the team. But, I think for the usages that I see, we would >>> need >>> font support. Is there any progress on this front? >>> >> Font support is there. I currently working on Morphic rendering (see >> screenshot) and getting VMs for all 3 platforms Athens-ready. >> >> As i said previously, don't expect Athens to support raster fonts. It >> doesn't makes any sense. >> With athens, you can always render number of glyphs into bitmaps and >> draw them as bitmaps later, if you want it, >> but i wouldn't call it 'font support', it is bitmap support. :) >> >> For Cairo backend i did integration with freetype (which already in >> pharo as you know), which means that you can >> render any scalable fonts. >> >> And if you may know, freetype package supports embedded fonts (i.e. >> font data loaded from memory), >> which means you don't even need to have a separate font file along the >> image, you can keep font in image itself. >> As for amount of memory, needed to hold truetype font in image: >> we did a small experiment with Camillo few days ago , we took single >> font (Deja Vu sans mono), >> and edited it to have only ascii character set (0..127). The resulting >> font file size is just 30Kb! >> >> Now compare it with following: >> >> (StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory >> ]) sum >> 1504444 >> >> 1.5 Mb of bitmap data for only single raster font with couple fixed sizes. >> >> For same size, you could have 1500/30 = 50 various vector fonts (if >> only ascii character range of course). > > 25 then, StrikeFonts cover all of latin1 range :) > How is the rendering performance compared to Bitmap and FT fonts done > without athens/cairo? > Bitmapped FT fonts were somewhat of a hog both memory and performance-wise > iirc, due to the combination of sub-pixel accurate glyph bitmap cache and > glyph-by-glyph rendering... > According to my measurement, which i did a while ago, a freetype glyph rendering roughly takes 1/3 of total time for delivering glyph to the screen. Which means a worst slowdown if you do it without any caching is +1/3 total rendering time for text. This actually shows that rendering is memory bound. Freetype producing grayscale glyphs 8 bit per pixel, and blitting it on screen uses 32 bit bitmap . That's the only one reasonable explanation to my observations i found. > Impressive progress! > > Cheers, > Henry > -- Best regards, Igor Stasenko.

Oct. 12, 2012

Re: [Pharo-project] Some progress on Athens

by Camillo Bruni

On 2012-10-12, at 14:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 12 October 2012 14:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> It looks nice! Everything on the screen is rendered by Athens? Or only >> the color bars? >> > everything. The color bars are transparent images loaded into pharo to show that alpha blending works properly...

Oct. 12, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 400 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 12, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 399 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Henrik Sperre Johansen

On 12.10.2012 14:42, Igor Stasenko wrote: > On 12 October 2012 13:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> Athens would indeed be great. And I am happy that this investment has high >> priority in the team. But, I think for the usages that I see, we would need >> font support. Is there any progress on this front? >> > Font support is there. I currently working on Morphic rendering (see > screenshot) and getting VMs for all 3 platforms Athens-ready. > > As i said previously, don't expect Athens to support raster fonts. It > doesn't makes any sense. > With athens, you can always render number of glyphs into bitmaps and > draw them as bitmaps later, if you want it, > but i wouldn't call it 'font support', it is bitmap support. :) > > For Cairo backend i did integration with freetype (which already in > pharo as you know), which means that you can > render any scalable fonts. > > And if you may know, freetype package supports embedded fonts (i.e. > font data loaded from memory), > which means you don't even need to have a separate font file along the > image, you can keep font in image itself. > As for amount of memory, needed to hold truetype font in image: > we did a small experiment with Camillo few days ago , we took single > font (Deja Vu sans mono), > and edited it to have only ascii character set (0..127). The resulting > font file size is just 30Kb! > > Now compare it with following: > > (StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory ]) sum > 1504444 > > 1.5 Mb of bitmap data for only single raster font with couple fixed sizes. > > For same size, you could have 1500/30 = 50 various vector fonts (if > only ascii character range of course). 25 then, StrikeFonts cover all of latin1 range :) How is the rendering performance compared to Bitmap and FT fonts done without athens/cairo? Bitmapped FT fonts were somewhat of a hog both memory and performance-wise iirc, due to the combination of sub-pixel accurate glyph bitmap cache and glyph-by-glyph rendering... Impressive progress! Cheers, Henry

Oct. 12, 2012

[Pharo-project] [update 2.0] #20336

by Esteban Lorenzano

20336 ----- Issue 6684: Failing tests related to RPackage http://code.google.com/p/pharo/issues/detail?id=6684 Issue 6744: Failing Test: TraitTest>>#testTraitsUsersSanity http://code.google.com/p/pharo/issues/detail?id=6744 Issue 6733: Failing Test: RPackageSetTest.testPolymorphicWithPackageInfo http://code.google.com/p/pharo/issues/detail?id=6733 Issue 6792: restore ocompletion and smartchars enabling http://code.google.com/p/pharo/issues/detail?id=6792

Oct. 12, 2012