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:[email protected] | 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 <[email protected]>wrote: > > On 12 nov. 2013, at 23:54, Clément Bera <[email protected]> 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 <[email protected]> > >> you want as less as possible thing in the vm. >> >> Stef >> >> On Nov 12, 2013, at 8:46 PM, Alexandre Bergel <[email protected]> >> 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 >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> > >
