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

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by StÃ©phane Ducasse

> > or of course, you start looking at porting XStreams to pharo ;), which on the long run will > solve many more problems. The current situation is not that satisfactory having experience with it and thinking about a plan for the beginning of 40 would be great. I know that nicolas ported XTream to pharo/squeak. Now understanding how integrate it would be nice. Stef

Nov. 11, 2013

Re: [Pharo-dev] Pharo 2.0 and Monticello settings: looks like there is no way to change

by StÃ©phane Ducasse

please enter a bug entry (and fixes) Stef On Nov 12, 2013, at 12:27 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > philippeback wrote >> How comes? > > It looks like it may have been broken with the switch to FileSystem. It > expects FileDirectory types... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-2-0-and-Monticello-settings-looks-like-there-is… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 11, 2013

Re: [Pharo-dev] Pharo 2.0 and Monticello settings: looks like there is no way to change

by Sean P. DeNigris

philippeback wrote > How comes? It looks like it may have been broken with the switch to FileSystem. It expects FileDirectory types... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-2-0-and-Monticello-settings-looks-like-there-is… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 11, 2013

Amber 0.12.0 released!

by Nicolas Petton

After 3 months of work we are pleased to announce the 0.12.0 release of Amber. Besides the usual bug fixes a lot of new features have emerged. The biggest change is the switch to RequireJS to specify Amber package dependencies and to load the packages as AMD modules. Amber is now additionally available as Bower [2] component. Bower is also used to manage required JavaScript libraries which don't have to be kept around in the repository anymore. The repository layout was restructured to provide a cleaner separation of different Amber parts: * Smalltalk code is located in 'st' * Compiled Amber packages are located in 'js' * Supporting JavaScript code is located in 'support' Together with the RequireJS changes the specifying their dependencies the Brickz [3] reconfigurable micro composition system was introduced. On the Smalltalk side support has been added for writing exponential numbers of the form 2e5. Helios (the new IDE) is progressing nicely and has seen a lot of improvements. One of the great parts is the new stepping debugger which is also making progress. To try Helios, open the helios.html page or evaluate in any other amber page `require('amber/helpers').popupHelios()`. The last enhancements target the commandline compiler which can be used as `amberc` (an executable script) or as a Grunt task. The following features have been added: * generation of shebang line (#!/usr/bin/env node) * specification of target namespace (`-n` flag; `amd_namespace` option in Grunt) * specification of additional library directories (`-L` flag; `library_dirs` option in Grunt) The following features have been removed: * creation of *.deploy.js files (`-d` flag; `deploy` option in Grunt) * optimization passes via Closure compiler (`-o`/`-O` flags; `closure_jar` option in Grunt) The same behavior can be achieved by using specific Grunt tasks Additionally, the Grunt task now handles the -v/--verbose flag which triggers the same behavior as the `verbose` option which can be specified in the Gruntfile. Some numbers about this release (starting from 0.11.0): * 660 commits * 10 committers * 66 unit tests added * 152 issues were closed * 379 unit tests in total Commits: https://github.com/amber-smalltalk/amber/compare/0.11.0...0.12.0 Issues: https://github.com/amber-smalltalk/amber/issues?direction=desc&milestone=8&… For the most important API related changes see the file API-CHANGES.txt. * Installing Amber from NPM To install Amber from NPM, run npm install amber * Installing Amber from Bower To install Amber from Bower, run bower install amber * Migration from Amber 0.11.0 First, the loading of JavaScript files must be adapted. The custom loader has been replaced with requirejs for loading files in the browser. New loader code is thouroughly explained in [4]. After updating the loader part, `.st` files need to be recompiled into new AMD `.js` files. During loader changes, a namespace was choosen and will be needed for recompilation. Go to your directory with `.st` files and issue this from the shell: ```sh <path-to-amber>/bin/amberc -l SUnit,Canvas -n <chosen-namespace> -D <path-for-compiled-js-files> *.st ``` In windows, use `\` as path separator, the rest is identical. The `-l SUnit,Canvas` is just a general guess, if your code depends on more (or less) non-kernel packages from amber, list them here accordingly. This migrate scenario only covers simple deployments with your project's code and amber. If your project is more complicated, using libraries and packages from multiple sources, it is hard to give general advices to migrate - you must do it library by library, giving each location its own namespace, and `-L` option of `amberc` comes handy when integrating; ask on the mailing list if problems arise. [1] http://requirejs.org/ [2] http://bower.io/ [3] https://github.com/amber-smalltalk/brikz [4] https://github.com/amber-smalltalk/amber/wiki/How-to-load-amber Happy Amber hacking! The Amber crew

Nov. 11, 2013

Remove Class Category

by Jimmie Houchin

Hello, I am wanting to write a method which uninstalls all of the Classes which I have created. I have one which looks like this: uninstall AllClasses reverse do: [ :c | Smalltalk removeClassNamed: c ] However the class category which was created to install them into still remains. I am having a hard time discovering what method I use to remove the category these classes were in. There are a lot of methods with category in the name. And is quite confusing how category and protocol are sometimes used interchangeably. I can't tell whether or not they are talking about removing the method's protocol categorization or the classes' category categorization. Its not until you go read the source that you might learn which you are looking at. Any help pointing to the method I am looking for is greatly appreciated. Jimmie

Nov. 11, 2013

Spec new release :)

by Benjamin

Hello everyone, I am glad to announce a step has been made in Spec with the introduction of five new models: TreeNodeModel, TreeColumnModel, MenuModel, MenuGroupModel and MenuItemModel. I. Trees The two first models (TreeNodeModel, TreeColumnModel) are used to build and specify trees (in addition with TreeModel). a) TreeNodeModel TreeNode represent a node of the tree, and hold some basic information like what the children of the node are, or which icon to use. Previously, one could use directly subclasses of MorphTreeNodeModel directly. This has been removed to loose the bonds between Spec and Morphic. If you used direct Morphic nodes in your tree, you will need to replace them by TreeNodeModel instances. You could also have used TreeModel methods used to generically describe your nodes. In this case, the only change you will need is how you access the content of a node. The MorphTreeNodeModel method used for this is #item while in TreeNodeModel it is #content. TreeNodeModel also support filtering out of the box with an extensible mechanism. b) TreeColumnModel TreeColumnModel is used to specify the columns used to render the tree nodes. Where one used to use TreeColumnMorph, now TreeColumnModel have to be use. The mainly behave the same, only the API differs to provide a less morphic oriented set of methods. TreeColumnModel also resolve some some updating issue encountered in TreeColumnMorph. II. Menus The three remaining models are used to build menus for the spec models. The way to build menus has been rethink to provide a more natural way to think menus. a) MenuModel A MenuModel is a quite a simple object with only an optional name, an optional icon and a list of menu groups. A MenuModel can also be turned into an auto-refreshing menu. The main method of MenuModel is #addGroup: which takes a block as argument and build a group before adding it to the menu model groups list. Example: aMenu addGroup: [ :aGroup | aGroup addItem: [ :anItem | anItem name: 'Browse Full'; action: [ self browseSelectedObject ]; shortcut: $b command mac | $b alt win | $b alt unix ]. aGroup addItem: [ :anItem | anItem name: 'Browse Class'; action: [ self browseSelectedObjectClass ] ] ]. b) MenuGroupModel A MenuGroupModel represent a set of menu items which belong to a same logical set by providing related actions. A menu group only hold a list of menu items. The main method of MenuGroupModel is #addItem: , as you have seen in the previous example. Example: aGroup addItem: [ :anItem | anItem name: 'Browse Hierarchy'; action: [ self browseSelectedObjectClassHierarchy ]; shortcut: $h command mac | $h alt win | $h alt unix ] c) MenuItemModel A menu item is the core of a menu. It is the object that can actually perform an action. A MenuItemModel holds multiple information related to this action like the name of the menu entry, the optional icon you want to use, if the action is doable in the current context, and the optional shortcut triggering the action. An interesting feature is that by applying a menu to a spec model, the shortcuts of its items will be used to automatically bind the corresponding key combination to the menu item action (taking in account the context to prevent to fire action when it does not make sense). So far, this feature has been introduced only in NewListModel to fix the possible issues before a global deployment. Thanks for reading this long email, thanks for your support and your feedback, and see you soon :) Ben

Nov. 11, 2013

Pharo 2.0 and Monticello settings: looks like there is no way to change

by phil＠highoctane.be

Hello, It looks like that there is no way to set those values (see screenshot). How comes? Phil

Nov. 11, 2013

Re: [Pharo-dev] TextModel

by Alexandre Bergel

Oh... I have noticed if we do this: PluggableTextMorph>>selectionInterval: sel Transcript show: 'selectionInterval: ', sel printString;cr. selectionInterval := sel Is it not enough to send an announcement? Alexandre On Nov 11, 2013, at 5:41 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It is actually an issue. > > The problem comes from the fact the morph does not notify its model when its selection changed. > > > Ben > > On 11 Nov 2013, at 21:18, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Hi Ben, >> >> We have doubt about the getSelection of TextModel. >> >> Execute the following in a Workspace: >> >> model := TextModel new. >> model openWithSpec. >> >> In the window, insert some text, and select something. Evaluate the following: >> model getSelection >> >> It always returns (1 to: 0) for us. >> >> Do you confirm? >> https://pharo.fogbugz.com/f/cases/12144/TextModel-getSelection >> >> Cheers, >> Johan Fabry & Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 11, 2013

help needed with fixing the SpecDebugger

by Tudor Girba

Hi, I need a bit of help with the issue of the SpecDebugger relying on the default inspector being implemented in Spec. I investigated a bit, but now I am stuck. Details here: https://pharo.fogbugz.com/f/cases/12055/ Can anyone look at it? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 11, 2013

Re: [Pharo-dev] Questions about Athens

by kilon alios

Ignore my last messages. Apparently I had an error with my code I just did not understand the error report. Everything works fone now. Î£ÏÎ¹Ï 11 ÎÎ¿Îµ 2013 4:46 Î¼.Î¼., Î¿ ÏÏÎ®ÏÏÎ·Ï "kilon alios" <kilon.alios(a)gmail.com> ÎÎ³ÏÎ±ÏÎµ: > sorry previous stack was for slightly diffirent code this is the correct > one > > UndefinedObject(Object)>>doesNotUnderstand: #drawDuring: > Hyperion>>render > Hyperion>>drawOn: > FormCanvas(Canvas)>>draw: > FormCanvas(Canvas)>>drawMorph: > Hyperion(Morph)>>fullDrawOn: in Block: [ ... > FormCanvas>>roundCornersOf:in:during: > FormCanvas(Canvas)>>roundCornersOf:during: > Hyperion(Morph)>>fullDrawOn: in Block: [ ... > BlockClosure>>on:do: > Hyperion(Morph)>>fullDrawOn: > FormCanvas(Canvas)>>fullDraw: > FormCanvas(Canvas)>>fullDrawMorph: > SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :m | canvas > fullDrawMorph: m ] > Array(SequenceableCollection)>>reverseDo: > SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :canvas | submorphs > reverseDo: [ :m | canvas ful...etc... > FormCanvas>>clipBy:during: > SystemWindow(Morph)>>drawSubmorphsOn: > SystemWindow(Morph)>>fullDrawOn: in Block: [ ... > FormCanvas>>roundCornersOf:in:during: > FormCanvas(Canvas)>>roundCornersOf:during: > SystemWindow(Morph)>>fullDrawOn: in Block: [ ... > BlockClosure>>on:do: > SystemWindow(Morph)>>fullDrawOn: > FormCanvas(Canvas)>>fullDraw: > FormCanvas(Canvas)>>fullDrawMorph: > WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: drawWorld: > aWorld submorphs: submorphs invalidArea...etc... > Rectangle>>allAreasOutsideList:startingAt:do: > Rectangle>>allAreasOutsideList:do: > WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: [ :dirtyRect | > ... > > > > On Mon, Nov 11, 2013 at 4:43 PM, kilon alios <kilon.alios(a)gmail.com>wrote: > >> Igor I am trying your session code but it does not work for me. I still >> get the red box of doom. This is the method >> >> checkSession >> >> session == Smalltalk session ifFalse: [ >> surface := surface := AthensCairoSurface extent: self extent. . >> session := Smalltalk session. >> ] >> >> and This is my full stack >> >> NBFFICallout class>>signalError: >> NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: >> NBFFICalloutAPI>>function:module: >> AthensCairoSurface class(Object)>>nbCall: >> AthensCairoSurface class>>primImage:width:height: >> NBFFICallout class(NBNativeCodeGen class)>>retrySend: >> AthensCairoSurface class>>extent:format: >> AthensCairoSurface class>>extent: >> Hyperion>>mouseDown: >> Hyperion(Morph)>>handleMouseDown: >> MouseButtonEvent>>sentTo: >> Hyperion(Morph)>>handleEvent: >> MorphicEventDispatcher>>dispatchMouseDown:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> Hyperion(Morph)>>processEvent:using: >> MorphicEventDispatcher>>dispatchMouseDown:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> SystemWindow(Morph)>>processEvent:using: >> SystemWindow(Morph)>>processEvent: >> SystemWindow>>mouseDown: in Block: [ ... >> BlockClosure>>ensure: >> SystemWindow>>mouseDown: >> SystemWindow(Morph)>>handleMouseDown: >> MouseButtonEvent>>sentTo: >> SystemWindow(Morph)>>handleEvent: >> MorphicEventDispatcher>>dispatchMouseDown:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> SystemWindow(Morph)>>processEvent:using: >> MorphicEventDispatcher>>dispatchMouseDown:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> >> >> >> On Sat, Nov 2, 2013 at 12:01 PM, kilon alios <kilon.alios(a)gmail.com>wrote: >> >>> and here is the strange MNU that I was talking about earlier >>> >>> here is the full stack >>> >>> Hyperion(Object)>>doesNotUnderstand: #passenger >>> PackageTreeModel>>acceptDroppingMorph:event:inMorph: >>> MorphTreeMorph>>acceptDroppingMorph:event: >>> MorphTreeMorph(Morph)>>handleDropMorph: >>> DropEvent>>sentTo: >>> MorphTreeMorph(Morph)>>handleEvent: >>> MorphicEventDispatcher>>dispatchDropEvent:with: >>> MorphicEventDispatcher>>dispatchEvent:with: >>> MorphTreeMorph(Morph)>>processEvent:using: >>> MorphicEventDispatcher>>dispatchDropEvent:with: >>> MorphicEventDispatcher>>dispatchEvent:with: >>> PanelMorph(Morph)>>processEvent:using: >>> MorphicEventDispatcher>>dispatchDropEvent:with: >>> MorphicEventDispatcher>>dispatchEvent:with: >>> NautilusWindow(Morph)>>processEvent:using: >>> MorphicEventDispatcher>>dispatchDropEvent:with: >>> MorphicEventDispatcher>>dispatchEvent:with: >>> WorldMorph(Morph)>>processEvent:using: >>> WorldMorph(Morph)>>processEvent: >>> HandMorph>>sendEvent:focus:clear: >>> HandMorph>>sendEvent:focus: >>> HandMorph>>dropMorph:event: >>> HandMorph>>dropMorphs: in Block: [ :m | ... >>> Array(SequenceableCollection)>>reverseDo: >>> HandMorph(Morph)>>submorphsReverseDo: >>> HandMorph>>dropMorphs: >>> HandMorph>>handleEvent: >>> HandMorph>>processEvents >>> WorldState>>doOneCycleNowFor: in Block: [ :h | ... >>> Array(SequenceableCollection)>>do: >>> >>> >>> This one happens when I bring up the halos and try to move the morph >>> around.Morphs gets deleted because of MNU. Note it does not happen with >>> just my Class (Hyperion) it happens with any morph using Athens. >>> >>> Hyperion in this case is a partial copy of the AthensDemoMorph. As >>> always I am using Pharo 3 (Latest update: #30534) . >>> >>> >>> On Fri, Nov 1, 2013 at 7:14 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> >>>> >>>> On 1 November 2013 14:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: >>>> >>>>> Ok now the explanation :) >>>>> Spec changed recently in 30. >>>>> >>>>> >>>> then i need help on that.. what is needs to be changed. >>>> btw, i noticed that monticello configuration browser also having >>>> problems with spec. >>>> >>>> >>>>> Stef >>>>> >>>>> >>>>> Again I am following Igor instructions, loaded Athens-Tutorial from >>>>> smalltalkhub , opened a new workspace, AthensTutorial open. I am using a >>>>> pharo 3 that downloaded just yesterday. (Pharo3.0 Latest update: #30532) >>>>> >>>>> here is the full stack >>>>> >>>>> AthensViewMorph(Object)>>doesNotUnderstand: #layout: >>>>> SpecInterpreter>>actionToPerformWithSelector:arguments: >>>>> SpecInterpreter>>performNextSelectorAndIncrementIndex >>>>> SpecInterpreter>>interpretASpec:selector: >>>>> SpecInterpreter>>interpretASpec:model:selector: >>>>> SpecInterpreter class>>private_interpretASpec:model:selector: >>>>> SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ >>>>> :each | self class private_interpretASpec: each ...etc... >>>>> Array(SequenceableCollection)>>collect: >>>>> SpecInterpreter>>performNextSelectorAndIncrementIndex >>>>> SpecInterpreter>>interpretASpec:selector: >>>>> SpecInterpreter>>interpretASpec:model:selector: >>>>> SpecInterpreter class>>private_interpretASpec:model:selector: >>>>> SpecInterpreter class>>interpretASpec:model:selector: in Block: [ >>>>> result := self private_interpretASpec: aPresente...etc... >>>>> BlockClosure>>ensure: >>>>> SpecInterpreter class>>interpretASpec:model:selector: >>>>> SpecInterpreter class>>interpretASpec:model: >>>>> AthensTutorial(ComposableModel)>>buildWithSpecLayout: >>>>> MorphicWindowAdapter>>addModelIn:withSpecLayout: >>>>> MorphicWindowAdapter(AbstractAdapter)>>update:with: >>>>> WindowModel(Object)>>changed:with: in Block: [ :aDependent | >>>>> aDependent update: anAspect with: ...etc... >>>>> DependentsArray>>do: >>>>> WindowModel(Object)>>changed:with: >>>>> WindowModel>>addModelIn:withSpecLayout: >>>>> WindowModel>>buildWithSpecLayout: >>>>> WindowModel>>openWithSpecLayout: >>>>> AthensTutorial(ComposableModel)>>openWithSpecLayout: >>>>> AthensTutorial(ComposableModel)>>openWithSpec: >>>>> AthensTutorial(ComposableModel)>>openWithSpec >>>>> AthensTutorial class>>open >>>>> UndefinedObject>>DoIt >>>>> >>>>> Is that enough ? >>>>> >>>>> I am also getting another error from Athens from time to time, I will >>>>> have to remember to capture it cause it appears randomly. >>>>> >>>>> >>>>> On Fri, Nov 1, 2013 at 1:42 PM, StÃ©phane Ducasse < >>>>> stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> >>>>>> On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> Igor I got Athens-Tutorial but it gives me a MNU: >>>>>> AthensViewMorph>>layout: >>>>>> >>>>>> >>>>>> strange tell us more. >>>>>> You know >>>>>> which image >>>>>> â¦. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 1, 2013 at 10:23 AM, kilon alios <kilon.alios(a)gmail.com>wrote: >>>>>> >>>>>>> ShivaVG looks definitely as a way to ease the pain of porting to >>>>>>> OpenGL. >>>>>>> >>>>>>> Some notes on the matter. The Cairo backend for OpenGL is opengl but >>>>>>> yet its not opengl. What it does is render cairo as a opengl texture. >>>>>>> OpenGL true power is in the shaders so you dont get the kind of hardware >>>>>>> acceleration you would expect. >>>>>>> >>>>>>> Speewise as surprising this may sound opengl is not the ideal >>>>>>> option, because opengl is mainly 3d orientated. The ideal solution from >>>>>>> what I have seen would be something like CUDA or OpenCL, that give direct >>>>>>> access to the GPU cores and allow you to do any kind of computation thus >>>>>>> liberation from the restrictions of APIs. For example Blender takes >>>>>>> advantage of both Opengl and CUDA , the CUDA renderer is phenomenal better >>>>>>> because of its flexibility. >>>>>>> >>>>>>> The problem however is that all that are very technical and it takes >>>>>>> quite some dedication to implement. >>>>>>> >>>>>>> A reason why I abandoned opengl as an idea is that I came to realise >>>>>>> that Cairo was already fast enough for my needs. But I still keep that door >>>>>>> open for the distant future, ShivaVG with OpenCL would be awesome for >>>>>>> really intensive GUIs and complex Graphics and definitely would love to >>>>>>> give it another try eventually. >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 1, 2013 at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)me.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Not sure to fully understand the problem. In what ShivaVG would >>>>>>>>> solve a situation better than with Athens? If I understand well, a then >>>>>>>>> working with Cairo uses the hardware acceleration right? >>>>>>>>> What is it not enough for you need? >>>>>>>>> >>>>>>>>> First, OpenVG is more complete and i would say thoroughly designed >>>>>>>> API than Cairo. >>>>>>>> Second, i don't want to go Athens -> Cairo -> OpenGL >>>>>>>> if i can do directly Athens->OpenGL. >>>>>>>> Putting extra dependency out of the loop is advantageous, OpenGL is >>>>>>>> widely supported industry standard, which today you can find even on >>>>>>>> portable devices, while you cannot say same about Cairo. >>>>>>>> (not mentioning avoiding costs of having multiple layers to get to >>>>>>>> the hardware). >>>>>>>> >>>>>>>> ShivaVG implements OpenVG API using OpenGL, since OpenVG is vector >>>>>>>> graphics framework >>>>>>>> it can serve as a good source to look how to implement OpenGL >>>>>>>> backend for Athens. >>>>>>>> >>>>>>>> >>>>>>>>> Alexandre >>>>>>>>> >>>>>>>>> > Le 31-10-2013 Ã 19:16, Igor Stasenko <siguctua(a)gmail.com> a >>>>>>>>> Ã©crit : >>>>>>>>> > >>>>>>>>> > I cannot say, of course, how it would be for you, but there is >>>>>>>>> ShivaVG[1] open-source >>>>>>>>> > opengl implementation of OpenVG, more or less feature-complete, >>>>>>>>> > so all what is needed is to port this code from C to smalltalk. >>>>>>>>> > Or if not for porting, but using as a source of insights how to >>>>>>>>> implement it. >>>>>>>>> > I think it is fairly doable. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >

Nov. 11, 2013