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

Re: [Pharo-dev] Little challenge

by Alejandro Infante

The profiler of my master thesis does this (and a lot more). It instruments new on all classes in a package + some other core things like String, Color, Rectangle and Collections and check if some of them have equivalent state and are immutable. If they are the profiler allows you to group the instances by the context where you allocated them (a simple stack trace, nothing fancy). http://repositorio.uchile.cl/bitstream/handle/2250/147381/Discovering-memor… <http://repositorio.uchile.cl/bitstream/handle/2250/147381/Discovering-memor…> It doesnât have a cool ui, but it works :) Alejandro > On Jan 9, 2020, at 7:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Another requirement for caching and sharing instances is that the object is a true read only value object. > >> On 9 Jan 2020, at 22:45, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> Well... the theme having these colors in a table of some sort, even >> keyed by a role name (very much like windows), isn't like a lot of >> work. >> >> Of course, "premature optimization is the root of all evil". But given >> that such "careless" behavior has been around for a while, maybe it is >> not premature any longer. :) >> >> Regards! >> >> Esteban A. Maringolo >> >> On Thu, Jan 9, 2020 at 5:14 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> 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. 10, 2020

Re: [Pharo-dev] about signal

by Sven Van Caekenberghe

Actually, it is just a, albeit concise, description of how Semaphores are implemented. It does not help much in understanding them, in learning how they can/should be used, for what purposes and how code behaves. Understanding of Process, priorities and Scheduling are also needed for a more complete understanding. This is not a simple subject. Read https://en.wikipedia.org/wiki/Semaphore_(programming) and see how well you understand the subject. In short, it does not answer Stef's concrete question(s). > On 10 Jan 2020, at 06:30, Danil Osipchuk <danil.osipchuk(a)gmail.com> wrote: > > Maybe to add this into the class comment, this is the most concise and clear description of how it works i've ever seen > > Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³., 8:13 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Thu, Jan 9, 2020 at 5:03 AM 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. > > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will start to run until something else happens after the execution of p1 := [...] fork. p2 := [...] fork. So for example, if there is Processor yield then p1 can start to run. > > So you need to add code to your example to be able to determine what will happen. The easiest thing would be to delay long enough that both can run. 1 millisecond is more than enough. > > 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? > > I would say these three things, something like this: > > "A semaphore is a queue (implemented as a linked list) and an excess signals count, which is a non-negative integer. On instance creation a new semaphore is empty and has a zero excess signals count. A semaphore created for mutual exclusion is empty and has an excess signals count of one." > > "When a process waits on a semaphore, if the semaphore's excess signals count is non-zero, then the excess signal count is decremented, and the process proceeds. But if the semaphore has a zero excess signals count then the process is unscheduled and added to the end of the semaphore, after any other processes that are queued on the semaphore." > > "When a semaphore is signaled, if it is not empty, the first process is removed from it and added to the runnable processes in the scheduler. If the semaphore is empty its excess signals count is incremented. > > Given these three statements it is easy to see how they work, how to use them for mutual exclusion, etc. > > > > 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. > > > > -- > _,,,^..^,,,_ > best, Eliot

Jan. 10, 2020

[Pharo 8.0] Build #1102: 2854-Pharo-7-Saving-the-settings-breaks-local-directory

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

There is a new Pharo build available! The status of the build #1102 was: SUCCESS. The Pull Request #5431 was integrated: "2854-Pharo-7-Saving-the-settings-breaks-local-directory" Pull request url: https://github.com/pharo-project/pharo/pull/5431 Issue Url: https://github.com/pharo-project/pharo/issues/2854 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 10, 2020

Re: [Pharo-dev] BaselineOfZincHTTPComponents>>baseline:

by Alistair Grant

Hi Sven, My apologies for the slow reply. On Mon, 6 Jan 2020 at 14:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 6 Jan 2020, at 08:16, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > >> What is your particular problem ? > > > > Pavel did some refactoring in > > https://github.com/pharo-project/pharo/commit/45b7de2b6c901112be04230faba48… > > that moved some methods from the FileSystem-Core package to the > > Zinc-Resource-Meta-Core package, and they go missing when loading > > other Zinc packages, e.g. SSO. > > Let's see: this should solve your immediate problem then: > > https://github.com/svenvc/zinc/commit/7d7f55e5654639a81e669b50f196ea4af38b8… > > It will fix the issue in Pharo 8. Looks good, thanks! > It will load uncleanly in Pharo 7, but we could do a back port to it if needed. This doesn't affect us, so no urgency on our side. Thanks again, Alistair

Jan. 10, 2020

Re: [Pharo-dev] about signal

by Danil Osipchuk

Maybe to add this into the class comment, this is the most concise and clear description of how it works i've ever seen Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³., 8:13 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Thu, Jan 9, 2020 at 5:03 AM 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. >> > > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 > will start to run until something else happens after the execution of p1 := > [...] fork. p2 := [...] fork. So for example, if there is Processor yield > then p1 can start to run. > > So you need to add code to your example to be able to determine what will > happen. The easiest thing would be to delay long enough that both can run. > 1 millisecond is more than enough. > > >> 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? >> > > I would say these three things, something like this: > > "A semaphore is a queue (implemented as a linked list) and an excess > signals count, which is a non-negative integer. On instance creation a new > semaphore is empty and has a zero excess signals count. A semaphore > created for mutual exclusion is empty and has an excess signals count of > one." > > "When a process waits on a semaphore, if the semaphore's excess signals > count is non-zero, then the excess signal count is decremented, and the > process proceeds. But if the semaphore has a zero excess signals count > then the process is unscheduled and added to the end of the semaphore, > after any other processes that are queued on the semaphore." > > "When a semaphore is signaled, if it is not empty, the first process is > removed from it and added to the runnable processes in the scheduler. If > the semaphore is empty its excess signals count is incremented. > > Given these three statements it is easy to see how they work, how to use > them for mutual exclusion, etc. > > >> >> 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. >> >> > > -- > _,,,^..^,,,_ > best, Eliot >

Jan. 10, 2020

Re: [Pharo-dev] about signal

by Eliot Miranda

On Thu, Jan 9, 2020 at 5:03 AM 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. > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will start to run until something else happens after the execution of p1 := [...] fork. p2 := [...] fork. So for example, if there is Processor yield then p1 can start to run. So you need to add code to your example to be able to determine what will happen. The easiest thing would be to delay long enough that both can run. 1 millisecond is more than enough. > 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? > I would say these three things, something like this: "A semaphore is a queue (implemented as a linked list) and an excess signals count, which is a non-negative integer. On instance creation a new semaphore is empty and has a zero excess signals count. A semaphore created for mutual exclusion is empty and has an excess signals count of one." "When a process waits on a semaphore, if the semaphore's excess signals count is non-zero, then the excess signal count is decremented, and the process proceeds. But if the semaphore has a zero excess signals count then the process is unscheduled and added to the end of the semaphore, after any other processes that are queued on the semaphore." "When a semaphore is signaled, if it is not empty, the first process is removed from it and added to the runnable processes in the scheduler. If the semaphore is empty its excess signals count is incremented. Given these three statements it is easy to see how they work, how to use them for mutual exclusion, etc. > > 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. > > -- _,,,^..^,,,_ best, Eliot

Jan. 10, 2020

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

by Ben Coman

On Thu, 9 Jan 2020 at 12:00, 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. > > 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. > Side note, for academics needing interesting final projects for students, one would be have this infrastructure for Pharo blocks generate/load code for the Programmable Real-time Units on a Beaglebone - useful for a dynamically programmable hard-real-time system for robotics. https://www.ti.com/lit/ug/tidu461/tidu461.pdf https://www.youtube.com/watch?v=B1DssoXzUXw https://www.youtube.com/results?search_query=beagleboard+pru cheers -ben

Jan. 10, 2020

Re: [Pharo-dev] Little challenge

by Sven Van Caekenberghe

Another requirement for caching and sharing instances is that the object is a true read only value object. > On 9 Jan 2020, at 22:45, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Well... the theme having these colors in a table of some sort, even > keyed by a role name (very much like windows), isn't like a lot of > work. > > Of course, "premature optimization is the root of all evil". But given > that such "careless" behavior has been around for a while, maybe it is > not premature any longer. :) > > Regards! > > Esteban A. Maringolo > > On Thu, Jan 9, 2020 at 5:14 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> 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] Little challenge

by Esteban Maringolo

Well... the theme having these colors in a table of some sort, even keyed by a role name (very much like windows), isn't like a lot of work. Of course, "premature optimization is the root of all evil". But given that such "careless" behavior has been around for a while, maybe it is not premature any longer. :) Regards! Esteban A. Maringolo On Thu, Jan 9, 2020 at 5:14 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > 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] [ANN] Sysmel, another experimental low-level language implemented in Pharo

by Ronie Salgado

> > > > 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? Well, the alternative is C++ which is a lot of worse. But Pharo will keep being the scripting language for Woden, but probably a much more minimalistic and "embedded" version of Pharo in the long term. I am designing Sysmel in a way so it is easy to compile standard Pharo code into the Sysmel run time. El jue., 9 ene. 2020 a las 17:18, Sean P. DeNigris (<sean(a)clipperadams.com>) escribiÃ³: > 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