April 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [CfP] DLS'10
by Pascal Costanza April 19, 2010

April 19, 2010

Dynamic Languages Symposium 2010 October 18, 2010 Co-located with SPLASH (OOPSLA) 2010 In cooperation with ACM SIGPLAN John Ascuaga's Nugget, Reno/Tahoe, Nevada, USA http://www.dynamic-languages-symposium.org/dls-10/ ***** Call for papers ***** The 6th Dynamic Languages Symposium (DLS) at the conference formerly known as OOPSLA is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development. DLS 2010 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the ACM Digital Library. Areas of interest include but are not limited to: * Innovative language features and implementation techniques * Development and platform support, tools * Interesting applications * Domain-oriented programming * Very late binding, dynamic composition, and runtime adaptation * Reflection and meta-programming * Software evolution * Language symbiosis and multi-paradigm languages * Dynamic optimization * Hardware support * Experience reports and case studies * Educational approaches and perspectives * Object-oriented, aspect-oriented, and context-oriented programming === Submissions and proceedings === We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Accepted papers will be published in the ACM Digital Library. Papers are to be submitted electronically at http://www.easychair.org/conferences?conf=dls2010 in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html. === Important dates === Submission of papers: June 1, 2010 (hard deadline) Author notification: July 15, 2010 Final versions due: August 13, 2010 DLS 2010: October 18, 2010 SPLASH/OOPSLA 2010: October 17-21, 2010 === Program chair === William Clinger, Northeastern University, Boston, Massachusetts, USA === Program committee === Robby Findler (Northwestern University) Jeffrey S. Foster (University of Maryland) Lars Thomas Hansen (Adobe Systems) Charlotte Herzeel (University of Brussels) S. Alexander Spoon (Google) Eric Tanter (University of Chile) Jan Vitek (Purdue University) Alessandro Warth (Viewpoints Research Institute) [to be completed] -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

1 0

Re: [Pharo-project] Pharo latest announcement
by Sudhakar Krishnamachari April 19, 2010

April 19, 2010

> > > Is it inadvertent for the version is showing up as 1.0 instead of 1.1...? > at > http://pharo-project.org/home > "Version 1.0 (stable) > > Pharo 1.0 was released on April 15, 2010. Download the one-click image and > get Pharo up and running within seconds." > <http://pharo-project.org/pharo-download/release-1-0> > > -Skrish >

2 1

[Pharo-project] Setup package fixes
by Sean P. DeNigris April 19, 2010

April 19, 2010

I sent some fixes to the package owner, but also posted a link to the mcz file http://seandenigris.com/files/Setup-SeanDeNigris.47.mcz here , in case anyone wants it. * Fix - Setup>>installDevelopment - changed from Installer (which is not pre-installed in Pharo 1.0) to Gopher. * Fix - Setup>>installSpecificUser - Changed "Author initials" (depreciated in Pharo 1.0) to "author fullName". - changed all author initials to full names, except jre because I didn't know what it stood for. I tested it against Pharo-Core 1.0 & PharoCore-1.1-11312-UNSTABLE. I tried to port it to Squeak 4.1, but got various errors, so I backed out the changes. But if you are interested, I can send them to you. Sean -- View this message in context: http://n4.nabble.com/Setup-package-fixes-tp2015309p2015309.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 3

[Pharo-project] Issue tracking system
by Torsten Bergmann April 19, 2010

April 19, 2010

Sorry ... have to correct myself: Gjallar is based on Seaside. Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

5 5

Re: [Pharo-project] [Vm-dev] Re: we need help for rome
by Bert Freudenberg April 19, 2010

April 19, 2010

On 18.04.2010, at 20:14, stephane ducasse wrote: > > > Thanks Bert > >> >> I think only the first 4 inst vars are actually used by the plugin: >> >> http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/… >> #define CanvasHandleIndex 0 >> #define CanvasTargetIndex 1 >> #define CanvasFlagsIndex 2 >> #define CanvasStrokeColorIndex 3 >> #define CanvasInstSize 8 > > how did you get that information? from the image side or C code? > Because I tried to see but unsure. It's in the C code I linked above. I just reordered it for better readability. >> So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory). > > Now I understand why alain could remove the instance variable when cleaning the image side. > >> The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore. > > > I browsed a bit the C code and I'm learning so may be my questions are not clever, but > > - do we need the pango primitives for ROME? > Apparently Pango may use Cairo for fonts rendering but do Rome needs that? > So is it simpler to use fonts via pango than cairo. Pango provides word/paragraph layout. Many non-latin scripts (e.g. Devanagari) require "glyph shaping", there is no one-to-one mapping between Unicode characters and glyphs rendered in context. Pango can do that. I'm not aware of any other renderer in Squeak that would support this (Yoshiki added it for OLPC). Well, maybe the Unicode plugin from Scratch could do it too, not sure. > - then what about FormInstSize? > > (interpreterProxy->slotSizeOf(formOop)) < FormInstSize > does it mean Same thing. The instance variables actually used by the plugin should be hard coded. Otherwise the same would happen as in Sophie - some inst vars were added to the Canvas, so the inst size compiled into the plugin became larger than necessary. Btw, by now you probably have guessed that a workaround for the Mac issue would be to add 5 dummy inst vars to RomePluginCanvas just to make the plugin happy. > - the primitives we have access to are listed by > void* RomePlugin_exports[][3] = { Right. > - how do we know that the plugin is somehow in sync with Cairo "latest" version? It doesn't need to be "in sync". But maybe I do not understand the question. - Bert - > Stef > >> >> - Bert - >> >> On 18.04.2010, at 18:45, StÃ©phane Ducasse wrote: >>> >>> John >>> >>> how can I know the order and the iv that are used by the plugin? >>> >>> Stef >>> >>> On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote: >>> >>>> (a) In Sophie >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY' >>>> classVariableNames: 'CachedTarget FlagFill FlagStro >>>> >>>> (b) In Pharo >>>> >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' >>>> classVariableNames: 'FlagFill FlagStroke Registry' >>>> poolDictionaries: '' >>>> category: 'Rome-PluginCanvas' >>>> >>>> Comment warning: >>>> >>>> INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE! >>>> >>>> >>>> So in the plugin we have... >>>> >>>> if (interpreterProxy->slotSizeOf(canvasOop)) < CanvasInstSize) >>>> fail(). >>>> >>>> >>>> where CanvasInstSize is 13 >>>> >>>> but as you see in (b) the number of instance slots for the canvas Oops is 8. >>>> >>>> 8 < 13, oops you fail. >>>> >>>> So where did the instance vars currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt >>>> go? On purpose gone, refactored, old code. etc.... >>>> >>>> >>>> On 2010-04-16, at 1:37 PM, StÃ©phane Ducasse wrote: >>>> >>>>> >>>>> On Apr 16, 2010, at 10:30 PM, John McIntosh wrote: >>>>> >>>>>> Well I'm just as puzzled as you since the primitive gets executed and you are using the same binary that was shipped with Sophie years back. >>>>> >>>>> I like to hear that because I feel less idiot. :) >> >

2 2

Re: [Pharo-project] we need help for rome
by StÃ©phane Ducasse April 19, 2010

April 19, 2010

Ok I will ask cyrille if he can have a look at the c :) Stef On Apr 18, 2010, at 11:23 PM, John M McIntosh wrote: > Well hey I'm just the guy tapping the compile button, er no support agreement here... > > Likely the original plugin code came via > > MCHttpRepository > location: 'http://source.impara.de/Rome' > user: '' > password: '' This is strange because I think that alain took it from there too. May be not. Stef > > If someone wants to make the required fixes to the plugin code, and the smalltalk code I *think* I can build a new plugin.. Likely this won't affect Sophie users (if any) because that's a one click app. However this means an update to the mac vm's and other platforms in order to ensure the smalltalk class in a Pharo image matches expectations. > > On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote: > >> >> I think only the first 4 inst vars are actually used by the plugin: >> >> http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/… >> #define CanvasHandleIndex 0 >> #define CanvasTargetIndex 1 >> #define CanvasFlagsIndex 2 >> #define CanvasStrokeColorIndex 3 >> #define CanvasInstSize 8 >> >> So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory). >> >> The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore. >> >> - Bert - >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > >

2 2

[Pharo-project] Help on collaborator Active book
by laurent laffont April 19, 2010

April 19, 2010

Hi, how to: - upload / display pictures ? - correctly highlight linux commands ? I use == but here http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnLinux it seems that / is a special character so the lines are red. Cheers, Laurent Laffont

7 19

[Pharo-project] Iliad 0.8 released!
by Nicolas Petton April 19, 2010

April 19, 2010

We are happy to announce the release of Iliad version 0.8 for GNU Smalltalk et Pharo. New features include: - Iliad is now using Grease and non portable code has been partially replaced; - The "mark dirty" mechanism has been rewritten to improve support for tabs/windows sharing the same session; - The new Formula package makes it easy to build validated forms; - Control flow has been improved with new widgets (like confirmations, sequences, etc) and widgets can append or prepend other widgets; - In addition to static files served with ILDiskDirectory, they can also be served from the image with ILMemoryDirectory; - Smalltalk code can be evaluated on DOM events with #on<event>Do: ; - Rewrite rules can be applied to the url builder; Last but not least, the release also includes an experimental implementation of Comet using XmlHttpRequest long polling. GNU Smalltalkers can download Iliad with gst-package (using GST 3.2): gst-package -t ~/.st --download iliad Or clone it from github: git clone git://github.com/NicolasPetton/iliad.git Pharo users can download a preconfigured image: http://www.iliadproject.org/resources/lYk5F_GiApFb/ggAMT_HRzRph9Yxp/Iliad-0… Or download Iliad packages from the SqueakSource repository: http://www.squeaksource.com/Iliad.html We would like to thank Steven Costiou for his work on the Pharo version of Iliad. Nicolas Petton & SÃ©bastien Audier

5 10

[Pharo-project] Canvas transform bug when rendering text?
by David Harvey April 19, 2010

April 19, 2010

Hi list, I'm writing a little charting morph, and while playing with rotating text for axis labels came across something which I've noted in Morphs text handling a couple of times. If I apply a transform in a drawing operation, rotated text _appears_ to be drawn twice, slightly offset, giving a scrappy bold look. It seems only to do this when drawing on a form canvas that's backed onto the display: if you pick and drag the morph, the text is rendered beautifully. The test morph attached isolates the problem. The transcript logging is an attempt to see what might be happening: looking at the output it appears that there are circumstances in which the during: block is invoked twice. Any thoughts? David ------------------ David Harvey www.teamsandtechnology.com www.cateams.com @david_harvey

10 28

April 18, 2010

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: April 18, 2010 8:15:05 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Re: [Vm-dev] Re: [Pharo-project] we need help for rome > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: April 18, 2010 8:14:58 PM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Vm-dev] Re: [Pharo-project] we need help for rome > > > Thanks Bert > >> >> I think only the first 4 inst vars are actually used by the plugin: >> >> http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/… >> #define CanvasHandleIndex 0 >> #define CanvasTargetIndex 1 >> #define CanvasFlagsIndex 2 >> #define CanvasStrokeColorIndex 3 >> #define CanvasInstSize 8 > > how did you get that information? from the image side or C code? > Because I tried to see but unsure. > >> >> So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory). > > Now I understand why alain could remove the instance variable when cleaning the image side. > > >> The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore. > > > I browsed a bit the C code and I'm learning so may be my questions are not clever, but > > - do we need the pango primitives for ROME? > Apparently Pango may use Cairo for fonts rendering but do Rome needs that? > So is it simpler to use fonts via pango than cairo. > > - then what about FormInstSize? > > (interpreterProxy->slotSizeOf(formOop)) < FormInstSize > does it mean > > - the primitives we have access to are listed by > void* RomePlugin_exports[][3] = { > > - how do we know that the plugin is somehow in sync with Cairo "latest" version? > > Stef > >> >> - Bert - >> >> On 18.04.2010, at 18:45, StÃ©phane Ducasse wrote: >>> >>> John >>> >>> how can I know the order and the iv that are used by the plugin? >>> >>> Stef >>> >>> On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote: >>> >>>> (a) In Sophie >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY' >>>> classVariableNames: 'CachedTarget FlagFill FlagStro >>>> >>>> (b) In Pharo >>>> >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' >>>> classVariableNames: 'FlagFill FlagStroke Registry' >>>> poolDictionaries: '' >>>> category: 'Rome-PluginCanvas' >>>> >>>> Comment warning: >>>> >>>> INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE! >>>> >>>> >>>> So in the plugin we have... >>>> >>>> if (interpreterProxy->slotSizeOf(canvasOop)) < CanvasInstSize) >>>> fail(). >>>> >>>> >>>> where CanvasInstSize is 13 >>>> >>>> but as you see in (b) the number of instance slots for the canvas Oops is 8. >>>> >>>> 8 < 13, oops you fail. >>>> >>>> So where did the instance vars currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt >>>> go? On purpose gone, refactored, old code. etc.... >>>> >>>> >>>> On 2010-04-16, at 1:37 PM, StÃ©phane Ducasse wrote: >>>> >>>>> >>>>> On Apr 16, 2010, at 10:30 PM, John McIntosh wrote: >>>>> >>>>>> Well I'm just as puzzled as you since the primitive gets executed and you are using the same binary that was shipped with Sophie years back. >>>>> >>>>> I like to hear that because I feel less idiot. :) >> > > > >

1 0