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

[Pharo-project] "fixed" AbstractLauncher missing for loading Cog
by Mariano Martinez Peck Dec. 22, 2011

Dec. 22, 2011

Hi guys. I have just "fixed" the problem that we cannot load clean Cog in Pharo 1.4/1.3 because AbstractLauncher was removed. I have created a package CogVMMakerPharoCompatibility in the repo PharoVM of SqueakSource and I have commited a nuked version of AbstractLauncher. It is nuked because the method #activate is sent by Cog's CommandLineLauncher class >> initialize. So...it seems CommandLineLauncher is only used for scripting, so if you DO want to use that class, it won't work in Pharo. But at least Cog will load without problems and you will be able to build a VM. Of course a better solution would be to put 'Cog-Scripting' in a separate package and from ConfigurationOfCog do not loas such separated package if we are in Pharo but do load it if we are in Squeak. If someone (Eliot) publishes such a change, I don't have a problem to rollback this one. But I was tired of this error so I proceeded with this workarround. So...this was done in ConfigurationOfCog new baseline 2.0 and new version 3.7. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load. ((Smalltalk at: # ConfigurationOfCog) project version: '3.7') load Cheers -- Mariano http://marianopeck.wordpress.com

2 1

[Pharo-project] 1.3, PBE and lab setups
by Dave Mason Dec. 22, 2011

Dec. 22, 2011

I am trying to get our local admins to set up labs so students can use the latest Pharo. Currently we have 1.2 and PBE .image files and by removing the field in the INI file that specified the image, if you clicked on Pharo, you'd get a dialogue asking which image you wanted. All of these are on read-only mounts, so if you want to save to the image, you need to copy the image to your home directory and then you could navigate to that image file on startup. Dropping an image on the executable works fine, though. Additionally, the PBE book doesn't play well with 1.3 (things that the book says die when you try them). Apparently you can't open the PBE image from the 1.3 binary without it crashing, either. So I have 3 questions: 1) is 1.3 the system to use, or will 1.4 be stable soon? 2) is the PBE book getting updated to work with a vanilla 1.3/1.4 image? 3) what is the timeline on these, as our semester starts Jan 10. Thanks ../Dave

4 4

[Pharo-project] External web browser
by Hilaire Fernandes Dec. 22, 2011

Dec. 22, 2011

Hello, What is the status of external web browser use. Last time I checked several months ago I can't use it with Linux. Anyone using it successfully recently? Thanks Hilaire -- Dr. Geo -- http://www.drgeo.eu

2 1

[Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307
by Johan Brichau Dec. 22, 2011

Dec. 22, 2011

Hi, I have been running Pharo 1.3 (#13315) with a pre-built Cog VM's downloaded from Eliot's site in a reliable manner (i.e. very few crashes) for many months. Just last week, I decided to try the Cog VM that is served from the Pharo website (Cog VM Mac-13307) and I am experiencing continuous crashes of the image. I am attaching a dump to this email. Once I switched back to the latest VM served on Eliot's site (VM.r2522), I stopped experiencing these crashes. If I experience this, probably other are tooâ¦ cheers, Johan

6 17

[Pharo-project] gt inspector
by Tudor Girba Dec. 21, 2011

Dec. 21, 2011

Hi, Just out of curiosity: Does any of you use the GTInspector? For those that wonder what that is, here is a demo:http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk This is available in any recent Moose image mapped as Explorer (CMD+I). You can load it in a Pharo 1.3 image by:Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load.(Smalltalk at: #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: #GTInspector) registerToolsOn: Smalltalk tools. Cheers,Doru -- www.tudorgirba.com "Every thing has its own flow"

4 6

Re: [Pharo-project] gt inspector
by Fernando Olivero Dec. 21, 2011

Dec. 21, 2011

Doru, nice tool! When using it, do you ever go back to a GT system browser? Seems that one tool such as this, would suffice ..kind of the SELF outliner. A breadcrumb would be helpful, to provide some reference when you start spawning panes to the right. Currently since Gaucho is broken (in the middle of the port to Athens/Cairo), i'm using the standard tools..i definitely will start using GT now. Fernando On Wed, Dec 21, 2011 at 9:01 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > Just out of curiosity: Does any of you use the GTInspector? > For those that wonder what that is, here is a > demo:http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk > This is available in any recent Moose image mapped as Explorer (CMD+I). > You can load it in a Pharo 1.3 image by:Gofer new Â Â Â squeaksource: > 'glamoroust'; Â package: 'ConfigurationOfGlamoroust'; Â load.(Smalltalk > at: #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: > #GTInspector) registerToolsOn: Smalltalk tools. > > Cheers,Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

2 3

Re: [Pharo-project] decoupling the vm: UI and interpretation
by Fernando Olivero Dec. 21, 2011

Dec. 21, 2011

YES!,the current VM was devised on 90's, maybe its time to alter it a bit now.. Esteban, in your opinion would this be feasible, in decent amount of time? Moving Display to a separate plugin. Yet remains a question, how would the "UI-pluggable VM" talk with the headless vm. I will implement a proof of concept, using some kind of IPC (for the MAc), so we can measure the responsiveness of such scheme. Fernando On Tue, Dec 20, 2011 at 1:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I wanting the same long time :) > > Having a VM which handling a platform-specific nuances and providing a > uniform interface > to language side is a great advantage. > But of course it not comes without drawbacks: you have a minimal > common functionality, > provided over all supported platforms. > > It would be cool to change the situation. > A first step would be to make a Display/events primitives optional > (move them into a separate plugin, > outside of core VM). > Like that a "default" VM without such plugin will be headless without > obligation to support graphical user interface. > The next step is, like you said, think about how to encode events > without losing flexibility and pass them to language side. > > On 20 December 2011 13:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Ok, i'm in favor of having everything in smalltalk too. >> >> The problem i have is the following: Â i want to change Â "how" the VM >> should announce events "were" the vm should draw >> >> Regarding the "were", currently the VM has a primitive from which you >> can specify which Form will act as the Display. But what if i want to >> render to something else than a form? >> Esteban: how does the COCOA VM draw the Display? Does it create a >> NSWindow, with a custom view, which copies the bits from the Display >> Form, into a drawing context (Quartz? OpenGL?). >> >> If we are moving towards a vectorial framework( AthensCanvas rendering >> to OpenGL or Cairo), we dont need to hardcode a "Display" a primitive >> in the vm. there's no need for such primitive. >> We just need access to the drawing context of the Pharo window, and >> render whatever we want there. >> >> We need the following: (using COCOA as an example) >> an OS window =>NSWindow >> with a custom view ==> subclass of NSView >> that creates a Cairo surface to a quartz backend, from which in the >> image side i can tell the AthensCanvas to draw into. >> >> For the event part, i should directly change the platform specific >> code for the Cocoa VM's? >> Cocoa provides higher level events and the VM is encoding them into >> Arrays, that in the image are decoded back into high level events ( >> see HandMorph>>generateEvt:from:). Which makes it hard to add new kind >> of events, specifically those originated from the trackpad (pinch, >> swipe, etc). (another BIG Â problem is that Â currently, all the VMs >> arent encoding EXACTLY the same OS events into the VM Arrays of >> events). I would like to play with the OS event encoding/decoding, to >> not loose so much in the translation. >> >> Please let me know wether i explained myself clearly, i'm still in the >> process of understanding how to detach the VM from the Bitmapped >> forms. >> >> Fernando >> >> >> On Tue, Dec 20, 2011 at 12:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> El 20/12/2011, a las 7:30a.m., Igor Stasenko escribiÃ³: >>>> >>>> I think what would be easier is to make a language side to handle everything. >>>> Unfortunately in practice this means moving substantial parts implemented in C >>>> and putting in smalltalk. >>> >>> +1 >>> It takes time... but in the long way is the best approach, I think. >>> >>>> I also don't see how separating it into 2 processes make things easier. >>>> I think it will complicate things even more, because now you will need to >>>> invent own communication schemes , which is also platform specific. >>>> And possibly it will work slower because of IPC overhead. >>> >>> They are not easier... but can be better for applications. That's the "default" behavior for mac and that's the reason why you usually don't have UI freezes while doing stuff (of course, not all applications -nor our vm, I changed it to single process- Â works that way... because is harder to maintain) >>> >>> best, >>> Esteban >>> >> > > > > -- > Best regards, > Igor Stasenko.

4 3

[Pharo-project] Enhancing Athens: about lines caps and joins
by Fernando Olivero Dec. 21, 2011

Dec. 21, 2011

Hi Igor and Stef, Im NBCairo i reified CairoLineCaps, and CairoLineJoin. In Athens is missing, should AthensLineSegment hold this information?, so when then canvas visits the line segment, it should change the cairo context accordingly. ( AthensCairoCanvas>>visitLineSegment: line) Fernando

2 2

[Pharo-project] Application settings
by Hilaire Fernandes Dec. 21, 2011

Dec. 21, 2011

I want to use drgeo specific setting and let the user browser drgeosettings only. As documented in the SettingBrowser comment, I defined: drgeoSettingsOn: aBuilder <drgeosettings> (aBuilder group: #drgeo) label: 'Dr. Geo'; description: 'All Dr. Geo related settings' translated; noOrdering; with: [ Then to browse drgeo specific settings I evaluate; (SettingBrowser forKeywords: #('drgeosettings')) open I got a MNU SettingTreeBuilder>>drgeosettings Do I need to implement it? Hilaire -- Dr. Geo -- http://www.drgeo.eu

3 5

Re: [Pharo-project] Athens and Cairo, first baby steps
by Fernando Olivero Dec. 21, 2011

Dec. 21, 2011

You are using the last approach, using getData, nice that is already implemented. Yes, i will move to Athens now. Up to now i've been playing with NBCairo, to render all the Gaucho shapes. I see that all NBCairo classes are replicated in Athens, NBCairoSurface=AthensCairoSurface, AthenCairoCanvas = NBCairoContext. Does it make sense to refactor Athens to use NBCairo? Currently there are two ways of interfacing with Cairo, maybe Athens should just reuse NBCairo. Athens should simply be "an adapter" from the Athens API, to the actual Cairo wrapper (NBCairo). Fernando On Wed, Dec 21, 2011 at 10:04 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 21, 2011, at 8:52 AM, Fernando Olivero wrote: > >> Igor, what does newSurface: do?, in the context of Cairo. > > I just create a cairo Surface > >> How do you render the contents of the Cairo surface to the Display? Or >> are you using the >> writeToPng->readFromPng to Form->Display Form mechanism. > > Copy from buffer to a form. > Have a look at the implementation. > > >> I was planning to use, NBCairoSurface>>getData:, which returns a >> pointer to the data, and simply update the Display contents with the >> surface's data. > > What would be good is that you use Athens? > > >> >> >> Fernando >> >> On Tue, Dec 20, 2011 at 11:09 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Alex normally you will just use athens and you will get a zoomable canvas :). >>> So mondrian should not use Cairo (just athens. Athens defines an API and you will be able to have multiple back ends >>> and your code should run the same on cairo or balloon (may be degraded in balloon). but your code will not be different. >>> >>> Stef >>> >>>> Your work is truly important! >>>> I plan in the long term to make Mondrian and Roassal use Cairo. This has been on my todo list for quite some time already... >>>> >>>> Alexandre >>>> >>>> On 20 Dec 2011, at 14:56, Igor Stasenko wrote: >>>> >>>>> We binding an Athens API for Cairo library. It fits pretty well as a >>>>> backend to API. >>>>> >>>>> Today i got some basics working. >>>>> Mostly, the functionality covered by: >>>>> >>>>> AthensCairoSurfaceExamples example1 >>>>> and >>>>> AthensCairoSurfaceExamples example2 >>>>> >>>>> which drawing nothing fancy but just rectangle(s) with solid color. >>>>> >>>>> example2 >>>>> " >>>>> self example2 >>>>> " >>>>> >>>>> Â Â Â | surf | >>>>> >>>>> Â Â Â surf := self newSurface: 100@100. >>>>> >>>>> Â Â Â surf drawDuring: [:can | >>>>> Â Â Â Â Â Â Â surf clear. >>>>> >>>>> Â Â Â Â Â Â Â can setPaint: Color blue. >>>>> >>>>> Â Â Â Â Â Â Â can drawShape: ( >>>>> Â Â Â Â Â Â Â Â Â Â Â can createPath: [:path | >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â path >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â absolute; >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â lineTo: 50@0; >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â lineTo: 50@50; >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â lineTo: 0@50 >>>>> Â Â Â Â Â Â Â Â Â Â Â ]) >>>>> >>>>> Â Â Â ]. >>>>> >>>>> Â Â Â Display getCanvas drawImage: Â Â surf asForm Â at: 0@0 >>>>> >>>>> >>>>> P.S. Stef says that Athens API is quite cool :) >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> <Screen Shot 2011-12-20 at 6.56.22 PM.png><Screen Shot 2011-12-20 at 6.57.04 PM.png> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel Â http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >

3 3