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

Re: [Pharo-project] native boost is the best thing since COGVM

by StÃ©phane Ducasse

Igor what is the link between pango cairo and the work you did on the text model in athens? Because I have the impression that you work on text modeling is important. Stef > A taste of what will be available: rendering the same GLabel (the > gaucho equivalent to StringMorph), scaling the CairoCanvas. > > Pesudo Code: > > "create a label" > label := GLabel on : 'hello Pango-Cairo'. > > "draw it on the canvas" > label drawOn: canvas. > > "scale the canvas" > canvas translateBy: aDelta ; scaleBy: aScale. > > "draw it on the canvas" > label drawOn: canvas. > > "repeat"

Dec. 12, 2011

Re: [Pharo-project] Waiting for deferred UI messages

by StÃ©phane Ducasse

if the symptoms continue you should stop :) I knew pharo was a strong drug but not at this level :) Stef > Thanks Gary! I actually had a dream about this last night (I obviously need > a vacation or another hobby). I visualized myself flying through the path of > execution and realized exactly that. > > -- > View this message in context: http://forum.world.st/Waiting-for-deferred-UI-messages-tp4179541p4186571.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 12, 2011

Re: [Pharo-project] Morphic Cleanup Status

by Sean P. DeNigris

Fernando olivero-2 wrote > > my overall impression , was that we need to stop being backward > compatible in order to create a simple Morphic-like framework for > Pharo, and start from scratch Having worked with all three (Morphic, SimpleMorphic, and your from-scratch version), what are the tradeoffs with each? Is the complexity of SimpleMorphic, and more still Morphic, essential [1] or accidental [2]? What I'm really asking is: do you envision your version to offer similar features and power as either of the others? I (totally ignorantly) feel like we could squeeze most of the awesome power of Morphic into a *much* smaller package. Also, it'd be great to read the original Morphic papers (if you haven't already) for inspiration to let the intended liveness and directness shine through in this new project. This work that you're doing is incredibly important. In the hallways at every conference, I hear dreams of amazing tools people have in mind (myself included), which are put on hold due to the mind-boggling complexity and uncertainty of Morphic and its future. Let me know when there's anything I can do. Sean [1] http://en.wikipedia.org/wiki/Essential_complexity [2] http://en.wikipedia.org/wiki/Accidental_complexity -- View this message in context: http://forum.world.st/Morphic-Cleanup-Status-tp4106566p4186864.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2011

Re: [Pharo-project] Scat - Public Release and announcement

by StÃ©phane Ducasse

Hi bernat Excellent! do you have code that we removed and changed that you would like to be in the system? Stef On Dec 12, 2011, at 4:56 PM, Bernat Romagosa wrote: > Hi list, > > Joan GÃ¼ell and I have been working on Scat -the Scratch port to Pharo- quite a lot recently. We wanted to push it to a point where we could release the first reasonably working version, which we've just managed today. > > Please take a look at the release announcement (which should be read in a bit of a humorous tone), in which we explain what's up with the project and what future is left for it. > > For the tl;dr version, please read: > â¢ Many things are working, many aren't, but the state of the project allows us to move into more interesting stuff based on the graphic programming metaphor. > â¢ Scat is a time-consuming, brain-smashing, life sucking-project. > â¢ We no longer will be maintaining this massive unmaintainable code. > â¢ Suddenly: free time for other projects! > Cheers everyone! > > -- > Bernat Romagosa.

Dec. 12, 2011

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo

by StÃ©phane Ducasse

http://www.famfamfam.com/ ? > Hi Fernando, > > oops... I forgot your icon importer, sorry :P > > I would like âfor a futureâ to integrate it to pharo and replace current ThemeIcons with an icon strategy based on your package... maybe that is the best "future scenario" for icons. > > best, > Esteban > > El 11/12/2011, a las 8:49a.m., Fernando Olivero escribiÃ³: > >> Hi Esteban, nice work! >> For importing the icons you can use the toolset i've developed: it >> automates completely the process of importing a complete set of icons >> of a given family. >> >> ExternalIconFamily @ squeaksource. >> I've used it for importing the Oxygen icon set, and others (you can >> google the list for previous related emails). >> >> Fernando >> >> On Sun, Dec 11, 2011 at 10:38 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Esteban >>> I know that feeling :) >>> >>> :) >>> Now I'm not sure that I would like to carry the Eclipse License around in Pharo :) >>> What are the other icons sets we could use with a nice license and we do it :). >>> famfam? >>> >>> We should clean also the old icons because some are really old. >>> Thanks for pushing that. I would love to have new icons for Pharo. >>> Stef >>> >>> >>> >>> On Dec 11, 2011, at 3:15 AM, Esteban Lorenzano wrote: >>> >>>> Hi, >>>> >>>> Today I was bored and not wanting to think too much... but I wanted to do something for Pharo... and I never liked the current Pharo icons, so I took one icon library I really like and changed all needed icons (well... all that I saw). >>>> Here a couple of screen shots: >>>> >>>> <Captura de pantalla 2011-12-10 a la(s) 23.05.55.png> >>>> <Captura de pantalla 2011-12-10 a la(s) 23.06.20.png> >>>> >>>> Of course, I don't think they are perfect (also maybe I didn't pick the best icons), but I think they look a lot better than the older. >>>> >>>> If you want to see how they look, this are the packages: >>>> >>>> for Pharo 1.3: >>>> >>>> <Eclipse-Icons-EstebanLorenzano.2.mcz> >>>> >>>> for Pharo 1.4: >>>> >>>> <Eclipse-Icons-EstebanLorenzano.4.mcz> >>>> >>>> >>>> Then you execute: >>>> >>>> ThemeIcons initializeIcons. >>>> World resetWorldMenu. >>>> >>>> ... and enjoy your new icons :) >>>> >>>> btw... this icons are in an open-source license, the EPL: http://www.eclipse.org/legal/epl-v10.html >>>> so, maybe âif all agreeâ, we can add this icons to regular distribution :) >>>> >>>> best, >>>> Esteban >>>> >>> >>> >> > >

Dec. 12, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by Igor Stasenko

On 12 December 2011 17:16, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > ok, i see your point. I will refactor back to Javier's approach. > My rationale was to reify the Cairo library as it is, luckily all the > other examples work. Well, it makes sense to do things like that, when you want a fast and dirty working stuff. But a good wrapping makes a lot of difference: there is no need to indicate that you using a library through 'self cairo' everywhere. It is just an indirection without any benefit. Wrapper classes and their instances should provide a required functionality through well defined protocols, and then from user's standpoint it is really makes no difference who implements them. That's why we need Athens. > > If i add the shared pool NBCairoTypes to the NBCairo then NativeBoost > automatically associates the type? Because i've been putting directly > "int". Would be nice to have a couple of examples of NB (whenever the > time is enough for you guys, i know you are busy) > Yes, but these examples were written specifically to show how to wrap a library in object-oriented way :) Look at pharo by example book [1], there you can find an explanation how to use shared pools. Of course it is far from complete, but my opinion that your refactoring gives a bad example to future developers. They should think in terms of objects and place callouts in corresponding classes with nicely formed protocol(s). I am looking forward for you to come, so i can explain things more directly and easier :) [1] https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Ali… > thanks for the feedback, > Fernando > > > > On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> CairoSamplePrograms>>rectangleAndText >> does not works, because it uses a following method: >> >> NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext >> Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> Â Â Â Â ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext, >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â String aFamily, >> >> cairo_font_slant_t slant, >> >> cairo_font_weight_t aWeight) ) >> >> >> and during code generation it barks that it unable to resolve >> 'cairo_font_slant_t' Â type. >> Because NBCairo class does not includes a corresponding shared pool >> (NBCairoTypes). >> >> Also, Fernando, i don't like that you put everything into a single >> class (NBCairo). >> This is wrong, not object-oriented. The original organization made by >> Javier was much more closer to my tastes. >> >> This approach to wrapping a library is too mechanical. It is much >> better to place calls at proper place(s) in proper classes, >> rather than putting everything into a single one. Which means that in >> this way you are at least 1 message send farther from >> real function call. >> But in your case its not even that.. >> >> NBCairoPattern>>status >> Â Â Â Â ^ self cairo patternStatusOf: self >> >> cairo >> Â Â Â Â ^ NBCairo default >> >> so , it is 2 extra message sends, instead of direct call to foreign function! >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Dec. 12, 2011

Re: [Pharo-project] Waiting for deferred UI messages

by Sean P. DeNigris

Gary Chambers-4 wrote > > This will get stuck if running in the UI process itself... > Thanks Gary! I actually had a dream about this last night (I obviously need a vacation or another hobby). I visualized myself flying through the path of execution and realized exactly that. -- View this message in context: http://forum.world.st/Waiting-for-deferred-UI-messages-tp4179541p4186571.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by Fernando Olivero

ok, i see your point. I will refactor back to Javier's approach. My rationale was to reify the Cairo library as it is, luckily all the other examples work. If i add the shared pool NBCairoTypes to the NBCairo then NativeBoost automatically associates the type? Because i've been putting directly "int". Would be nice to have a couple of examples of NB (whenever the time is enough for you guys, i know you are busy) thanks for the feedback, Fernando On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > CairoSamplePrograms>>rectangleAndText > does not works, because it uses a following method: > > NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext > Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > Â Â Â Â ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext, > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â String aFamily, > > cairo_font_slant_t slant, > > cairo_font_weight_t aWeight) ) > > > and during code generation it barks that it unable to resolve > 'cairo_font_slant_t' Â type. > Because NBCairo class does not includes a corresponding shared pool > (NBCairoTypes). > > Also, Fernando, i don't like that you put everything into a single > class (NBCairo). > This is wrong, not object-oriented. The original organization made by > Javier was much more closer to my tastes. > > This approach to wrapping a library is too mechanical. It is much > better to place calls at proper place(s) in proper classes, > rather than putting everything into a single one. Which means that in > this way you are at least 1 message send farther from > real function call. > But in your case its not even that.. > > NBCairoPattern>>status > Â Â Â Â ^ self cairo patternStatusOf: self > > cairo > Â Â Â Â ^ NBCairo default > > so , it is 2 extra message sends, instead of direct call to foreign function! > > > -- > Best regards, > Igor Stasenko. >

Dec. 12, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by Igor Stasenko

CairoSamplePrograms>>rectangleAndText does not works, because it uses a following method: NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext, String aFamily, cairo_font_slant_t slant, cairo_font_weight_t aWeight) ) and during code generation it barks that it unable to resolve 'cairo_font_slant_t' type. Because NBCairo class does not includes a corresponding shared pool (NBCairoTypes). Also, Fernando, i don't like that you put everything into a single class (NBCairo). This is wrong, not object-oriented. The original organization made by Javier was much more closer to my tastes. This approach to wrapping a library is too mechanical. It is much better to place calls at proper place(s) in proper classes, rather than putting everything into a single one. Which means that in this way you are at least 1 message send farther from real function call. But in your case its not even that.. NBCairoPattern>>status ^ self cairo patternStatusOf: self cairo ^ NBCairo default so , it is 2 extra message sends, instead of direct call to foreign function! -- Best regards, Igor Stasenko.

Dec. 12, 2011

[Pharo-project] Scat - Public Release and announcement

by Bernat Romagosa

Hi list, Joan GÃ¼ell and I have been working on Scat -the Scratch port to Pharo- quite a lot recently. We wanted to push it to a point where we could release the first reasonably working version, which we've just managed today. Please take a look at the release announcement<http://code.google.com/p/scat/wiki/PublicRelease> (which should be read in a bit of a humorous tone), in which we explain what's up with the project and what future is left for it. For the tl;dr version, please read: - Many things are working, many aren't, but the state of the project allows us to move into more interesting stuff based on the graphic programming metaphor. - Scat is a time-consuming, brain-smashing, life sucking-project. - We no longer will be maintaining this massive unmaintainable code. - Suddenly: free time for other projects! Cheers everyone! -- Bernat Romagosa.

Dec. 12, 2011