- Pharo-dev - lists.pharo.org

Where to download Viva?

by Alexandre Bergel

Viva is an animation framework for Athens -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 13, 2013

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Igor Stasenko

According to its manual ( http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a0a12735ac191200f6… ) stream The address of a PaStream pointer which will receive a pointer to the newly opened stream. So, what you need to pass is a pointer to location where pointer will be stored. The simplest way how to do it (without explaining you how to use NBExternalValue) just do a following: PaError Pa_OpenDefaultStream(NBExternalAddress * stream ... ) then your call site will look like following: streamHandle := NBExternalAddress new. self Pa_opendefaultBlah: streamHandle ... The 'NBExternalAddress *' type treated specially, because usually for most cases if you pass an instance of NBExternalAddress to any function which expects some pointer, NB will pass the value of NBExternalAddress, however if type is NBExternalAddress * , then NB will pass a pointer where pointer value is stored (which effectively means pointer to pointer) that should do the trick. But hold on, next thing you will stuck with is callback ... hehe :) ah.. ok, according to manual, you can simply skip this one by passing NULL (nil) for that, again you can just change the function signature and instead of putting PaStreamCallback<http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a8a60fb2a5ec9cbade…>* *streamCallback* put nil. (yes, nil literal) On 13 November 2013 06:11, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sean P. DeNigris wrote > > I'll let you know how it turns out. > > Okay, I got a little further. I can initialize and terminate the library. > Yahoo!! > > To load the very basic spike: > Gofer it > smalltalkhubUser: 'SeanDeNigris' project: 'PortAudio'; > package: 'PortAudio'; > load. > > My next task is to call... > PaError Pa_OpenDefaultStream(PaStream ** stream, "PaStream > is typedef for > void" > int numInputChannels, > int numOutputChannels, > ulong sampleFormat, > double sampleRate, > ulong framesPerBuffer, > PaStreamCallback streamCallback, > void * userData) (see > http://portaudio.com/docs/v19-doxydocs/open_default_stream.html) > > The first argument is most perplexing to me. I haven't seen any NativeBoost > examples of pointers to pointers. In fact, with pointers to values, it > seems > random whether they are derefenced when described in NB. > > For example: > cairo_t* cairo_create (cairo_surface_t *target); > becomes (from the IWST paper): > self nbCall: #( > AthensCairoCanvas cairo_create ( > AthensCairoSurface cairoSurface)) > > Notice the argument is dereferenced in the NB version. > > But (also from the IWST paper): > "void cairo_matrix_multiply ( > cairo_matrix_t *result, > const cairo_matrix_t *a, > const cairo_matrix_t *b );" > becomes: > self nbCall: #(void cairo_matrix_multiply (AthensCairoMatrix * self, > AthensCairoMatrix * m , AthensCairoMatrix * self ) ) > > In this case, none of the arguments are defererenced. > > Anyway, I'd reeeeeally appreciate it if someone would load the code and see > what the problem is. > > "PortAudio example" will run the demo script I'm translating from the > library docs into Pharo. > > Thanks in advance... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

Stef, what is the advantages of writing it in Pier compared to markdown ? Ben

Nov. 13, 2013

Re: [Pharo-dev] Questions about Athens

by Igor Stasenko

I doubt it is related to Athens. I think it is initialization problem. If morph's extent depends on external factors, you should properly initialize them before computing it. It could be that you calling #checkSession before.. which leads to DNU, because no extent can be computed at given point yet. On 12 November 2013 12:59, kilon alios <kilon.alios(a)gmail.com> wrote: > Igor just for the record, I still have not figure out why I had this > problem in the first place. I was using self extent and that was giving me > a NB error as I posted in the first stack trace. I changed it to self > defaultExtent that returns a point with the default size of the area of the > Morph and voila it worked. I checked the Hierachy and Morph which is the > super class of Hyperion has an extent method so this should work. So I > think this may be an Athens bug after all. > > So i changed the method from > > checkSession > session == Smalltalk session ifFalse: [surface := AthensCairoSurface > extent: self extent . session := Smalltalk session ] > > to > > checkSession > session == Smalltalk session ifFalse: [surface := AthensCairoSurface > extent: self defaultExtent . session := Smalltalk session ] > > and now it works properly for some strange reason. At first I thought it > was because there was no self extent method but now I see thats not the > case. > > > On Tue, Nov 12, 2013 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 11 November 2013 21:47, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> 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. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

Ben On 13 Nov 2013, at 12:43, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi, > > I have some questions: > > 1/ Before the removal of morphic dependencies in spec, I used aNode selectedNode parentNode item to get the parent of the selected item. What is the new way to do that? I think I forgot about this one :) The fix is easy though. Can you open an issue, I will have a look this evening :) > 2/ I also defined specific nodes for a Tree model. These nodes overrode the childrenItems method to provide children elements. It looks like this method is not used anymore in TreeNodeModel. What should I now use to provide children elements in a TreeNodeModel? You used to have Morphic node specific classes. Now there is only TreeNodeModel. So instead of creating a subclass, you will have to specify the TreeNodeModels you want (and specifying children is #children:) It is also possible that I forgot some scenarios, in this case, you can send another email, or wait tip next week so we can sit together :) Ben > > Thanks, > Christophe.

Nov. 13, 2013

Re: [Pharo-dev] PharoV20.source

by Marcus Denker

On 13 Nov 2013, at 12:02, phil(a)highoctane.be wrote: > Very exciting developments. > > How would you keep "sources" and "changes" segregated BTW? (if we can still call them like that). > changes are modelled by Martinâs system (EPICEA). Marcus

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by Christophe Demarey

Hi, I have some questions: 1/ Before the removal of morphic dependencies in spec, I used aNode selectedNode parentNode item to get the parent of the selected item. What is the new way to do that? 2/ I also defined specific nodes for a Tree model. These nodes overrode the childrenItems method to provide children elements. It looks like this method is not used anymore in TreeNodeModel. What should I now use to provide children elements in a TreeNodeModel? Thanks, Christophe.

Nov. 13, 2013

Re: [Pharo-dev] PharoV20.source

by StÃ©phane Ducasse

> > Anyway, even if at the end it takes more memory than the current source file, we should not forget that having persistant ASTs that you can freely annotate brings far more than compression, it opens *many* doors :) > The annotations on the nodes would take memory too. Well, at least for the annotation one wants to be persistant. > Even with compression, storing all the annotations one would want to have would take too much memory. > Imagine that you want to stores additional comments and discussions (instead of "self flag:" everywhere), statistics like code coverage, about which class a variable had across different executions, type annotations for many different kind of type systems (and remember its annotations, not intrusive, no syntax change, pluggable)... > That's why I want to have repositories for storing node annotations across network. > Like this we would have a compressed AST format in the image (called Bonsai) and a mechanism for storing and sharing node annotations on repositories (project's name: Baobab) Camille can you describe these projects in the Pharo topics on github We should find a guy to work on them. Stef

Nov. 13, 2013

Re: [Pharo-dev] PharoV20.source

by phil＠highoctane.be

Very exciting developments. How would you keep "sources" and "changes" segregated BTW? (if we can still call them like that). --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Wed, Nov 13, 2013 at 11:55 AM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > > On 12 nov. 2013, at 23:54, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > Currently the idea is to put the source file as a compressed AST in the > image. > > The status is: > - standard AST is 300Mb for the whole image, which is too much > - standard AST with nodes shared between RBMethodNodes (made by Camille) > is 16Mb, so already half the size of the current source > > > In fact 16 Mb is a lucky guess too. > It currently takes 13Mb without indentation and comments. > > - same as last one but with additional bit compression: not done yet ! It > should be around 4Mb (but that's a lucky guess), growing the size of the > image from 16Mb to 20Mb, which is okay. > > > Pablo is currently working on AST compression. > We could use Huffman coding or something else. > > Anyway, even if at the end it takes more memory than the current source > file, we should not forget that having persistant ASTs that you can freely > annotate brings far more than compression, it opens *many* doors :) > The annotations on the nodes would take memory too. Well, at least for the > annotation one wants to be persistant. > Even with compression, storing all the annotations one would want to have > would take too much memory. > Imagine that you want to stores additional comments and discussions > (instead of "self flag:" everywhere), statistics like code coverage, about > which class a variable had across different executions, type annotations > for many different kind of type systems (and remember its annotations, not > intrusive, no syntax change, pluggable)... > That's why I want to have repositories for storing node annotations across > network. > Like this we would have a compressed AST format in the image (called > Bonsai) and a mechanism for storing and sharing node annotations on > repositories (project's name: Baobab) > > The source file should not be in the VM. One image can use only 1 source > file, but 1 VM can run several images using different source files. > Therefore you would need to add multiple source files in the VM, which ends > up nowhere. > > > > 2013/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> you want as less as possible thing in the vm. >> >> Stef >> >> On Nov 12, 2013, at 8:46 PM, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> >> > Hi! >> > >> > Why not to include this file in the VM? >> > It often happens to me that this place is wrongly placed. When this >> happens, Pharo just shows a white screen, without letting what is the error. >> > >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> > >

Nov. 13, 2013

Re: [Pharo-dev] PharoV20.source

by Camille Teruel

On 12 nov. 2013, at 23:54, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > Currently the idea is to put the source file as a compressed AST in the image. > > The status is: > - standard AST is 300Mb for the whole image, which is too much > - standard AST with nodes shared between RBMethodNodes (made by Camille) is 16Mb, so already half the size of the current source In fact 16 Mb is a lucky guess too. It currently takes 13Mb without indentation and comments. > - same as last one but with additional bit compression: not done yet ! It should be around 4Mb (but that's a lucky guess), growing the size of the image from 16Mb to 20Mb, which is okay. Pablo is currently working on AST compression. We could use Huffman coding or something else. Anyway, even if at the end it takes more memory than the current source file, we should not forget that having persistant ASTs that you can freely annotate brings far more than compression, it opens *many* doors :) The annotations on the nodes would take memory too. Well, at least for the annotation one wants to be persistant. Even with compression, storing all the annotations one would want to have would take too much memory. Imagine that you want to stores additional comments and discussions (instead of "self flag:" everywhere), statistics like code coverage, about which class a variable had across different executions, type annotations for many different kind of type systems (and remember its annotations, not intrusive, no syntax change, pluggable)... That's why I want to have repositories for storing node annotations across network. Like this we would have a compressed AST format in the image (called Bonsai) and a mechanism for storing and sharing node annotations on repositories (project's name: Baobab) > The source file should not be in the VM. One image can use only 1 source file, but 1 VM can run several images using different source files. Therefore you would need to add multiple source files in the VM, which ends up nowhere. > > > > 2013/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > you want as less as possible thing in the vm. > > Stef > > On Nov 12, 2013, at 8:46 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > Hi! > > > > Why not to include this file in the VM? > > It often happens to me that this place is wrongly placed. When this happens, Pharo just shows a white screen, without letting what is the error. > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Nov. 13, 2013