[Mm10s] 2020-01-06
Locked
 
|
Hello, last week was a short one but some things have been done:
- [VM] Porting the GC fix to Pharo 7 / 8 VM - [VM] Building for the different Platforms - [VM] Signing for OSX - [VM] The versions will be available today to start testing it before promoting them to stable. - [Pharo8] Fixing Issues before the release - [VM Dev] Starting to work in improving tests in JIT and GC. -- Pablo Tesone. [hidden email] |
|
|
Thanks Pablo
Last Week - Working on concurrent programming booklet - Enlumineur - Better iceberg explanation with Pablo - Fluid class parser This week - Fluid class parser - Enlumineur - Consortium meeting - PBE80 - Working on concurrent programming booklet > Hello, last week was a short one but some things have been done: > > - [VM] Porting the GC fix to Pharo 7 / 8 VM > - [VM] Building for the different Platforms > - [VM] Signing for OSX > - [VM] The versions will be available today to start testing it before > promoting them to stable. > - [Pharo8] Fixing Issues before the release > - [VM Dev] Starting to work in improving tests in JIT and GC. > > -- > Pablo Tesone. > [hidden email] > |
|
|
Hi Stef. What is Fluid class parser? Is it the name of currently integrated parser? вт, 7 янв. 2020 г. в 19:48, ducasse <[hidden email]>: Thanks Pablo |
|
|
Hello Denis
This is the name of the class definition we sketched and presented at Maribor. The idea is how to fight the combinatory explosion of parameters (tags, ephemerons, traits, slots, ….) For now I’m putting in place the structure to be able to create a tree of definition nodes for a class definition Superclass < #MyObject uses: #MyTrait; slots: { #a. #b }; classVariables: { #A. #B }; tags: #(Core) ; package: #MyPackage The minimal class definition is the following one: Superclass < #MyObject package: #MyPackage or Superclass < #MyObject Like that we get closer to ruby and other language that have a compact class definition. One of the key constraints is that we do not want to break the syntax. So everything is message based and consistent with the syntax and our motto. But we will see. I prefer talking with something running. When I worked on the package I rewrote everything three times. The idea is that this class definition parser should replace the ClassDefinitionParser (which we will keep for the traditional class definition but that in a couple of years from now should vanish). S.
|
Re: [Mm10s] 2020-01-06
|
|
It sounds wrong to call this a parser, it is a builder, no ?
It is plain Pharo syntax that builds a representation, IIUC. > On 7 Jan 2020, at 21:32, ducasse <[hidden email]> wrote: > > Hello Denis > > >> >> What is Fluid class parser? > > This is the name of the class definition we sketched and presented at Maribor. > The idea is how to fight the combinatory explosion of parameters (tags, ephemerons, traits, slots, ….) > For now I’m putting in place the structure to be able to create a tree of definition nodes for a class definition > > Superclass < #MyObject > uses: #MyTrait; > slots: { #a. #b }; > classVariables: { #A. #B }; > tags: #(Core) ; > package: #MyPackage > > The minimal class definition is the following one: > > Superclass < #MyObject > package: #MyPackage > > or > Superclass < #MyObject > > Like that we get closer to ruby and other language that have a compact class definition. > One of the key constraints is that we do not want to break the syntax. > So everything is message based and consistent with the syntax and our motto. > > But we will see. > I prefer talking with something running. > When I worked on the package I rewrote everything three times. > > The idea is that this class definition parser should replace the ClassDefinitionParser (which we will keep for the > traditional class definition but that in a couple of years from now should vanish). > > S. > > > > > >> Is it the name of currently integrated parser? >> >> вт, 7 янв. 2020 г. в 19:48, ducasse <[hidden email]>: >> Thanks Pablo >> >> >> Last Week >> - Working on concurrent programming booklet >> - Enlumineur >> - Better iceberg explanation with Pablo >> - Fluid class parser >> >> This week >> - Fluid class parser >> - Enlumineur >> - Consortium meeting >> - PBE80 >> - Working on concurrent programming booklet >> >> >> >> > Hello, last week was a short one but some things have been done: >> > >> > - [VM] Porting the GC fix to Pharo 7 / 8 VM >> > - [VM] Building for the different Platforms >> > - [VM] Signing for OSX >> > - [VM] The versions will be available today to start testing it before >> > promoting them to stable. >> > - [Pharo8] Fixing Issues before the release >> > - [VM Dev] Starting to work in improving tests in JIT and GC. >> > >> > -- >> > Pablo Tesone. >> > [hidden email] >> > >> >> >> > |
|
|
Hi Sven. It was an example of definition format which new parser targets. вт, 7 янв. 2020 г. в 22:20, Sven Van Caekenberghe <[hidden email]>: It sounds wrong to call this a parser, it is a builder, no ? |
|
|
In reply to this post by ducasse
вт, 7 янв. 2020 г. в 20:34, ducasse <[hidden email]>:
Interesting to know why superclass is chose for the receiver in new class definition. It does not cover the proxy classes with nil superclass.
|
Re: [Mm10s] 2020-01-06
|
|
In reply to this post by ducasse
It is a very interesting effort.
The following: Superclass < #MyObject uses: #MyTrait; slots: { #a. #b }; classVariables: { #A. #B }; tags: #(Core) ; package: #MyPackage Seems more complex to implement than: Superclass < (#MyObject uses: #MyTrait; slots: { #a. #b }; classVariables: { #A. #B }; tags: #(Core) ; package: #MyPackage) The reason is that in the first class definition, the binary operator has precedence over keyword messages, which means that it is equivalent to: (Superclass < #MyObject) uses: #MyTrait; slots: { #a. #b }; classVariables: { #A. #B }; tags: #(Core) ; package: #MyPackage And as such, the code assume that it modifies the class _after_ its creation, which could be tricky if one want to have it fast. But maybe there is something obvious that I did not see... Cheers, Alexandre > On 07-01-2020, at 21:32, ducasse <[hidden email]> wrote: > > Hello Denis > > >> >> What is Fluid class parser? > > This is the name of the class definition we sketched and presented at Maribor. > The idea is how to fight the combinatory explosion of parameters (tags, ephemerons, traits, slots, ….) > For now I’m putting in place the structure to be able to create a tree of definition nodes for a class definition > > Superclass < #MyObject > uses: #MyTrait; > slots: { #a. #b }; > classVariables: { #A. #B }; > tags: #(Core) ; > package: #MyPackage > > The minimal class definition is the following one: > > Superclass < #MyObject > package: #MyPackage > > or > Superclass < #MyObject > > Like that we get closer to ruby and other language that have a compact class definition. > One of the key constraints is that we do not want to break the syntax. > So everything is message based and consistent with the syntax and our motto. > > But we will see. > I prefer talking with something running. > When I worked on the package I rewrote everything three times. > > The idea is that this class definition parser should replace the ClassDefinitionParser (which we will keep for the > traditional class definition but that in a couple of years from now should vanish). > > S. > > > > > >> Is it the name of currently integrated parser? >> >> вт, 7 янв. 2020 г. в 19:48, ducasse <[hidden email]>: >> Thanks Pablo >> >> >> Last Week >> - Working on concurrent programming booklet >> - Enlumineur >> - Better iceberg explanation with Pablo >> - Fluid class parser >> >> This week >> - Fluid class parser >> - Enlumineur >> - Consortium meeting >> - PBE80 >> - Working on concurrent programming booklet >> >> >> >> > Hello, last week was a short one but some things have been done: >> > >> > - [VM] Porting the GC fix to Pharo 7 / 8 VM >> > - [VM] Building for the different Platforms >> > - [VM] Signing for OSX >> > - [VM] The versions will be available today to start testing it before >> > promoting them to stable. >> > - [Pharo8] Fixing Issues before the release >> > - [VM Dev] Starting to work in improving tests in JIT and GC. >> > >> > -- >> > Pablo Tesone. >> > [hidden email] >> > >> >> >> > |
|
Administrator
|
In reply to this post by ducasse
ducasse wrote
> The idea is how to fight the combinatory explosion of parameters Cool!!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |