January 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Mm10s] 2020-01-06

by Sean P. DeNigris

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

Jan. 9, 2020

Re: [Pharo-dev] [ANN] Sysmel, another experimental low-level language implemented in Pharo

by Sean P. DeNigris

Ronie Salgado wrote > In a farther future, a higher performance > version of the Woden Engine will be made by using Sysmel, mostly because > it > seems to be much easier to support real multi-threading in Sysmel by > making > a completely new system. Congrats! But... sad that Pharo may eventually lose Woden. Is there no other way? E.g. optimizing? Also, do you think "yet another programming language" to learn will discourage a wide audience for Woden? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 9, 2020

Re: [Pharo-dev] Little challenge

by Sean P. DeNigris

ducasse wrote > it looks like a real plague. What is the real effect on performance? There is a cost to the complexity of e.g. caching too, no? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 9, 2020

Re: [Pharo-dev] Stand fosdem 2020

by Santiago Bragagnolo

Great! We were discussing today with Pablo Guillermo pierre gordana Theo and Angela about fosdem during lunch. We want to order at least 5 t-shirts (eye catching, turquoise or orange) for the stand people and presenter :). We also want to print stickers ,maybe pens, have two screens rolling videos and maybe some robotic demos . And to print the report you did on pharo. And of course the posters. El lun., 6 de ene. de 2020 09:35, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > I got a talk acccepted in micro languages sunday morning. > > S > > > On 6 Jan 2020, at 08:59, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > > > > Hi all, we got a stand position for the Sunday 2 February in fosdem. > This week I am going to be organising all the goodies slides etc . I would > like as well to know if any of the companies working with photo is > interested in being shown , and if you have goodies or any mean of helping > to share do not hesitate in contacting me. > > > > > > I'll try to get some good photos from the place for sharing later :) > > > > Santiago > > > > > > > > >

Jan. 9, 2020

Re: [Pharo-dev] about signal

by ducasse

here is what Iâm writing in the book. Let us image that we have the following two processes and one semaphore. [[[ | semaphore p1 p2 | semaphore := Semaphore new. p1 := [ semaphore wait. 'p1' crTrace ] fork. p2 := [ semaphore signal. 'p2' crTrace ] fork. ]]] - The first process is waiting on the semaphore. As soon as the semaphore will be signalled, ==p1== is signal also the semaphore. - The second process is just signalling the semaphore and printing. Now the question is to understand what is the generated trace which is ==p2== then ==p1==. Let us explain why. - ==p1== is scheduled and its execution starts to wait on the semaphore, so it is removed from the run queue of the scheduler and added to the waiting list of the semaphore. - ==p2== is scheduled and it signals the semaphore. The semaphore takes the first waiting process (==p1==) and reschedules it by adding it to the end of the suspended lists. ==p2== continues its execution. Let us slightly change the example to show how priorities are involved during the signalling process. [[[ | semaphore p1 p2 | semaphore := Semaphore new. p1 := [ semaphore wait. 'p1' crTrace ] forkAt: 30. p2 := [semaphore signal. 'p2' crTrace ] forkAt: 20. ]] As a conclusion when the semaphore is signalled, the first waiting process of the semaphore is removed from the semaphore list, and resumed following the preemption rules of the scheduler. > On 9 Jan 2020, at 13:01, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. > 'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like explain clearly but it depends on the semantics of signal. > > > - ==p1== is scheduled and its execution starts to wait on the semaphore, so it is removed from the run queue of the scheduler and added to the waiting list of the semaphore. > - ==p2== is scheduled and it signals the semaphore. The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists. > > > Now this sentence "The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists.â is super naive. Is the semaphore signalling scheduled? or not? > > > signal > "Primitive. Send a signal through the receiver. If one or more processes > have been suspended trying to receive a signal, allow the first one to > proceed. If no process is waiting, remember the excess signal. Essential. > See Object documentation whatIsAPrimitive." > > <primitive: 85> > self primitiveFailed > > "self isEmpty > ifTrue: [excessSignals := excessSignals+1] > ifFalse: [Processor resume: self removeFirstLink]" > > > I wanted to know what is really happening when a semaphore is signalled. > Now resume: does not exist on Processor. > > I will look in the VM code. > > > S > > > > > > S.

Jan. 9, 2020

[Pharo 9.0] Build #3: 5450-Add-executable-comments-in-SequenceableCollection---sorting-shuffling-split-protocol

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #3 was: FAILURE. The Pull Request #5461 was integrated: "5450-Add-executable-comments-in-SequenceableCollection---sorting-shuffling-split-protocol" Pull request url: https://github.com/pharo-project/pharo/pull/5461 Issue Url: https://github.com/pharo-project/pharo/issues/5450 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 9, 2020

about signal

by ducasse

Hi I wanted to explain | semaphore p1 p2 | semaphore := Semaphore new. p1 := [ semaphore wait. 'p1' crTrace ] fork. p2 := [semaphore signal. 'p2' crTrace ] fork. displays p2 and p1. but I would like explain clearly but it depends on the semantics of signal. - ==p1== is scheduled and its execution starts to wait on the semaphore, so it is removed from the run queue of the scheduler and added to the waiting list of the semaphore. - ==p2== is scheduled and it signals the semaphore. The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists. Now this sentence "The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists.â is super naive. Is the semaphore signalling scheduled? or not? signal "Primitive. Send a signal through the receiver. If one or more processes have been suspended trying to receive a signal, allow the first one to proceed. If no process is waiting, remember the excess signal. Essential. See Object documentation whatIsAPrimitive." <primitive: 85> self primitiveFailed "self isEmpty ifTrue: [excessSignals := excessSignals+1] ifFalse: [Processor resume: self removeFirstLink]" I wanted to know what is really happening when a semaphore is signalled. Now resume: does not exist on Processor. I will look in the VM code. S S.

Jan. 9, 2020

Re: [Pharo-dev] [Mm10s] 2020-01-06

by Alexandre Bergel

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 <stepharo(a)netcourrier.com> 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 <stepharo(a)netcourrier.com>: >> 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. >> > tesonep(a)gmail.com >> > >> >> >> >

Jan. 9, 2020

Re: [Pharo-dev] [ANN] Sysmel, another experimental low-level language implemented in Pharo

by Tudor Girba

Nice work! Doru > On Jan 9, 2020, at 4:59 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hi All, > > I am finally announcing an initial release of my new experimental low-level programming language which I am calling Sysmel (For SYStem MEtaprogramming Language). > > GitHub Page: https://github.com/ronsaldo/sysmel > Short native game demo: https://www.youtube.com/watch?v=tRoPMbPvqH0 > > Sysmel is designed to be a flexible language, and a flexible compiler front-end. The support for garbage collection in Sysmel is an optional feature by design, and the support for dynamic objects and dynamic message lookup it is also optional. If garbage collection is disabled, the code written in Sysmel is mostly equivalent to C/C++ code (only single inheritance is supported for now), but with a hybrid syntax between Smalltalk and C++. > > For the final code generation I am using my custom SSA intermediate representation (the same one that I used in Lowtalk, and in) which it is currently tested with the following two backends: > - LLVM textual IR backend. This is used for generating native object files by reusing the LLVM infrastructure. This backend also supports emitting DWARF debugging information so the resulting programs can be debugged with gdb. > - Spir-V backend, for generating shaders for Vulkan and executing them in the GPU. > > One of the objectives of Sysmel is to support the full Smalltalk object model without a VM and with real multi-threading support. So far message lookup is already implemented, but there is still many basic primitives missing, and the implementation of a proper GC that allows implementing #allInstances and #become: . As a quick workaround, currently only the Boehm conservative GC is supported for having an initially working environment. > > In the near future, Woden Engine will adopt Sysmel at least as its shading language for programming the GPU. In a farther future, a higher performance version of the Woden Engine will be made by using Sysmel, mostly because it seems to be much easier to support real multi-threading in Sysmel by making a completely new system. > > I am also re-implementing my previous experiment for converting Pharo block closures into shaders by reusing the Sysmel intermediate level AST, and its type inference machinery. The current version of this new Block -> to Shader infrastructure can only perform basic Map and Reduce operations with blocks that do not define local variables (they will be supported in a future version) in linear arrays. > > Best regards, > Ronie -- feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Jan. 9, 2020

[ANN] Sysmel, another experimental low-level language implemented in Pharo

by Ronie Salgado

Hi All, I am finally announcing an initial release of my new experimental low-level programming language which I am calling Sysmel (For SYStem MEtaprogramming Language). GitHub Page: https://github.com/ronsaldo/sysmel Short native game demo: https://www.youtube.com/watch?v=tRoPMbPvqH0 Sysmel is designed to be a flexible language, and a flexible compiler front-end. The support for garbage collection in Sysmel is an optional feature by design, and the support for dynamic objects and dynamic message lookup it is also optional. If garbage collection is disabled, the code written in Sysmel is mostly equivalent to C/C++ code (only single inheritance is supported for now), but with a hybrid syntax between Smalltalk and C++. For the final code generation I am using my custom SSA intermediate representation (the same one that I used in Lowtalk, and in) which it is currently tested with the following two backends: - LLVM textual IR backend. This is used for generating native object files by reusing the LLVM infrastructure. This backend also supports emitting DWARF debugging information so the resulting programs can be debugged with gdb. - Spir-V backend, for generating shaders for Vulkan and executing them in the GPU. One of the objectives of Sysmel is to support the full Smalltalk object model without a VM and with real multi-threading support. So far message lookup is already implemented, but there is still many basic primitives missing, and the implementation of a proper GC that allows implementing #allInstances and #become: . As a quick workaround, currently only the Boehm conservative GC is supported for having an initially working environment. In the near future, Woden Engine will adopt Sysmel at least as its shading language for programming the GPU. In a farther future, a higher performance version of the Woden Engine will be made by using Sysmel, mostly because it seems to be much easier to support real multi-threading in Sysmel by making a completely new system. I am also re-implementing my previous experiment for converting Pharo block closures into shaders by reusing the Sysmel intermediate level AST, and its type inference machinery. The current version of this new Block -> to Shader infrastructure can only perform basic Map and Reduce operations with blocks that do not define local variables (they will be supported in a future version) in linear arrays. Best regards, Ronie

Jan. 9, 2020