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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
you want as less as possible thing in the vm. Stef On Nov 12, 2013, at 8:46 PM, Alexandre Bergel <alexandre.bergel@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 sources - 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. 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@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@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 12 nov. 2013, at 23:54, Clément Bera <bera.clement@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@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@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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@gmail.com>wrote:
On 12 nov. 2013, at 23:54, Clément Bera <bera.clement@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@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@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2 cents. just want to make a note, it is important to preserve original text (yes i am talking about formatting, spacing, tabs etc).. because without it i can easily imagine you can raise compression ration to the skies.. but as to me the original text is important part of game. On 13 November 2013 12:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 13 Nov 2013, at 12:02, phil@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
-- Best regards, Igor Stasenko.
On 13 nov. 2013, at 14:42, Igor Stasenko <siguctua@gmail.com> wrote:
2 cents. just want to make a note, it is important to preserve original text (yes i am talking about formatting, spacing, tabs etc).. because without it i can easily imagine you can raise compression ration to the skies.. but as to me the original text is important part of game.
Don't worry, formatting information will be stored in Bonsai (as extrinsic information of the flyweight like node properties, not in the flyweights themselves). You won't notice that there is no original text, source will be reconstructed on demand.
On 13 November 2013 12:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 13 Nov 2013, at 12:02, phil@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
-- Best regards, Igor Stasenko.
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
On 13 nov. 2013, at 12:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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.
Yes but you only talk about Baobab right? Because Pablo is already working on AST compression and Bonsai.
Stef
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.
Yes but you only talk about Baobab right? Because Pablo is already working on AST compression and Bonsai.
yes :)
participants (7)
-
Alexandre Bergel -
Camille Teruel -
Clément Bera -
Igor Stasenko -
Marcus Denker -
phil＠highoctane.be -
Stéphane Ducasse