August 2017 - Pharo-dev - lists.pharo.org

[Pharo 70 ] build 38 - PR 199 FileReference-size-needs-a-comment

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20269/FileReference-size-needs-a-comment https://github.com/pharo-project/pharo/pull/199

Aug. 16, 2017

Re: [Pharo-dev] @About posting here

by Norbert Hartl

> Am 16.08.2017 um 13:21 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi Frank, > > I'll just repeat Stef's message: It's not about being straight or having unpopular opinions. It's about being rude and on the limit of the insult. I feel myself some harshness in your messages, it's like you're saying that everybody but you is stupid. I know that you did not say that "explicitly" but that's the way it feels. And I'm sure I'm not the only one feeling like it. > > Of course, that did not prevent me to answer you politely, but at the end what will happen is that people will not answer you anymore. Just take into account that if many people think already that your mails are aggressive, there may be some fault on your side too. > > That said, this does not mean that I want to "censor" you. Just choose better your words but keep the same content. > > +1 to all you said. And I would like to know why every smalltalk troll is german? That's so sad! Norbert > > On Wed, Aug 16, 2017 at 12:52 PM, Frank-B <frank.berger.software(a)web.de <mailto:frank.berger.software@web.de>> wrote: > Phil, > > nice attempt to drill and silence me! My advise: They all failed! > > If somebody can't cope with straight critics or unpopular opinions that aint > my fault. > > Frank > who never worried about being labeled and > from a country where free speech is still welcome > > > > -- > View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… <http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p…> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Aug. 16, 2017

Re: [Pharo-dev] [squeak-dev] File & Socket Handle Access

by Denis Kudriashov

Hi Eliot. I asked David why he didn't add it to the SocketPlugin in the first place > and he discussed Andreas Rabb's security concerns It would be interesting to read about them because it looks strange that it is secure to manage OS handle from VM but not secure to manage it from image side. Both ways are requested by user directly or indirectly which means that user has OS permissions. So what the difference? 2017-08-16 2:13 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi All, > > recently Denis Kudriashov wanted to access the OS handle of a Socket > from the image to pass through the FFI. David Lewis pointed out that the > AioPlugin provides a primitive to do this. I asked David why he didn't add > it to the SocketPlugin in the first place and he discussed Andreas Rabb's > security concerns. It strikes me > a) that accessing the OS handle of a file or a socket is extremely useful > in some circumstances and invalid in others > b) having handle access in a secondary plugin is inconvenient to say the > least > c) having access only to Socket handles and not to file handles is also > inconvenient. > > So I propose adding a SecurityPlugin facility to control handle access, > which would be granted by default, and to add primitives to both the > SocketPlugin and FilePlugin to answer the native OS handle when the > SecurityPlugin grants permission. > > I also propose adding a compilation flag to the Windows VM to allow > compiling out Andreas' handle management, which consists merely of > maintaining a table of the file handles (not the socket handles) that have > been created by the VM. It strikes me that a much better solution is > merely to encrypt the handle via xoring with a value created at random. I > don't see how Andreas' solution adds value, especially since it is not > implemented on other platforms, and merely adds overhead. > > Thoughts? Objections? > _,,,^..^,,,_ > best, Eliot > > > >

Aug. 16, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Guillermo Polito

On Wed, Aug 16, 2017 at 1:21 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-08-16 12:28 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> >> >> On Wed, Aug 16, 2017 at 12:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> >>> 2017-08-16 12:02 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> >>>> >>>> On Wed, Aug 16, 2017 at 10:50 AM, Denis Kudriashov < >>>> dionisiydk(a)gmail.com> wrote: >>>> >>>>> There is possibility where delay can be used during startup/shutdown. >>>>> Library can clean resources which are managed by kind of pool which >>>>> organizes timeout logic to enter synchronization monitor. >>>>> >>>>> I checked Seamless which manages connections this way. But I not found >>>>> any issue there. >>>>> >>>> >>>> Can you explain this in more detail? I want to know exactly what "clean >>>> resources", "kind of pool" and "timeout logic to enter synchronization >>>> monitor" mean concretely. >>>> >>>> Also, how are you subscribing seamless to the startup list? >>>> >>> >>> Seamless server cleans all opened connections on image save. It >>> registers using: >>> >>> SessionManager default registerNetworkClassNamed: self name >>> >>> I copied this logic from ZnServer. >>> But Seamless manages connections using ObjectPool. So when image save is >>> performed "connectionPool clear" is evaluated. It closes connections and >>> reset all caches. Problem that ObjectPool is protected by Monitor with >>> timeout option. And #clear method enters this monitor. It is possible that >>> at the time of image save monitor will be busy and #clear method will wait >>> for delay to enter critical section. >>> >>> >> Does this means that there may be a timeout while closing connections >> during shutdown? >> Because in that case the session manager will continue shutting down >> things and seamless may be not fully cleaned up upon next startup. >> > > Yes. It is possible. But it looks like very rare case. Interesting if > there is real solution to this. > Well... maybe we need some actions that can "cancel" the shutdown? Like in the operating system, when there is an app that cannot be closed, it asks you to force close or not... Otherwise, I'd advice that at shutdown seamless should be in any case safer and avoid that case. Maybe you want to clear the pool without a timeout? Maybe you want to force kill connections without waiting for them (because they may never end)? > From the other side I am not sure why connections should be closed when > image is saved. In case of Seamless pool is constructed in the way that it > checks if socket is valid before borrow it to user. > Well, that's a seamless issue, isn't it? Did you try not subscribing seamless to the startup to see if it still behaves well? > > >> >> >>> >>> >>>> >>>>> >>>>> >>>>> 2017-08-16 1:46 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com> >>>>> : >>>>> >>>>>> >>>>>> On Tue, Aug 15, 2017 at 3:25 PM, Ben Coman <btc(a)openinworld.com> >>>>>> wrote: >>>>>> >>>>>>> In case any of the shutdown/startup scripts use a delay, now or in >>>>>>> the future, >>>>>>> I'd first try at highestPriority-1 to avoid influence on the >>>>>>> DelayScheduler. >>>>>>> but then Eliot's suggestion to valueUnpreemptively may avoid that >>>>>>> anyway. >>>>>>> >>>>>> >>>>>> Why should a shutdown/startup use a delay? startup and shutdown >>>>>> should be fast and not be blocked... If there is a delay on client code, it >>>>>> should block a client thread, not a system thread... >>>>>> >>>>>> Moreover, I see a series of issues in having the delay process >>>>>> running in higher priority than the startup. If I'm wrong, please correct >>>>>> me because otherwise that means there is something I'm not getting. >>>>>> >>>>>> First, today the Delay scheduling process is being terminated on >>>>>> shutdown and being re-initialized on startup. This means that even if a >>>>>> shutdown/startup action tries to use a delay that will fail/block >>>>>> indefinitely? >>>>>> >>>>>> Second, what happens with race conditions between the startup and the >>>>>> delay process? If the shutdown is in the middle of terminating the delay >>>>>> process and the delay process gets suddenly activated? >>>>>> >>>>>> stopTimerEventLoop >>>>>> "Stop the timer event loop" >>>>>> >>>>>> timerEventLoop ifNotNil: [ timerEventLoop terminate ]. >>>>>> timerEventLoop := nil. >>>>>> >>>>>> Maybe before terminating the timerEventLoop we need to suspend it? >>>>>> That will at least atomically (primitive) remove the process from the ready >>>>>> list and avoid it from being activated again, no? >>>>>> >>>>>> In any case, I see no good in letting a delay work on startup. That >>>>>> is far too low level and the system would be in a far too unstable state to >>>>>> run any code other than the startup itself. >>>>>> >>>>>> >>>>>>> btw, what happens if an error occurs inside valueUnpreemptively? >>>>>>> Does the normal priority debugger still get to run? >>>>>>> >>>>>>> cheers -ben >>>>>>> >>>>>>> On Mon, Aug 14, 2017 at 6:42 PM, Guillermo Polito < >>>>>>> guillermopolito(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm proposing a kind-of critical change that I believe is very good >>>>>>>> for the health of the system: I want that the startup of the system runs in >>>>>>>> maximum priority and becomes non-interruptable. >>>>>>>> >>>>>>>> Right now, when you save your image, the shutdown and startup are >>>>>>>> run in the same priority than the process that triggered the save (usually >>>>>>>> the ui or the command line, priority 40). This can cause lots of problems >>>>>>>> and race conditions: processes with higher priorities can interrupt the >>>>>>>> shutdown/startup and try to do something while the system is unstable. As a >>>>>>>> side effect also, when you use extensively the command line, you start >>>>>>>> stacking startup contexts from old sessions: >>>>>>>> >>>>>>>> ... >>>>>>>> session 3 ctxt 4 <- This guy makes a save and a new session starts >>>>>>>> session 3 ctxt 3 >>>>>>>> session 3 ctxt 2 >>>>>>>> session 3 ctxt 1 >>>>>>>> session 2 ctxt 4 <- This guy makes a save and a new session starts >>>>>>>> session 2 ctxt 3 >>>>>>>> session 2 ctxt 2 >>>>>>>> session 2 ctxt 1 >>>>>>>> session 1 ctxt 4 <- This guy makes a save and a new session starts >>>>>>>> session 1 ctxt 3 >>>>>>>> session 1 ctxt 2 >>>>>>>> session 1 ctxt 1 >>>>>>>> >>>>>>>> Old contexts are never collected, and the objects they referenced >>>>>>>> neither. >>>>>>>> >>>>>>>> To fix these two problems I propose to do every image save/session >>>>>>>> start in a new process in maximum priority. That way, other process should >>>>>>>> not be able to interrupt the startup process. Moreover, every session >>>>>>>> shutdown/startup should happen in a new clean process, to avoid the session >>>>>>>> stacking. >>>>>>>> >>>>>>>> For normal users, this should have no side effect at all. This >>>>>>>> change will have a good impact on people working on the debugger and the >>>>>>>> stack such as fueling-out the stack because they will have a cleaner stack. >>>>>>>> >>>>>>>> There is however a side-effect/design point to consider: startup >>>>>>>> actions should be quick to run. If a startup action requires to run a >>>>>>>> long-running action such as starting a server or managing a command line >>>>>>>> action, that should run in a separate process with lower priority (usually >>>>>>>> userPriority). In other words, the startup action should create a new >>>>>>>> process managing its action. >>>>>>>> >>>>>>>> If you want to review (and I'd be glad) >>>>>>>> >>>>>>>> Pull request: https://github.com/pharo-project/pharo/pull/198 >>>>>>>> Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 >>>>>>>> Current validation going on: https://ci.inria.fr/pharo-ci-j >>>>>>>> enkins2/job/Test%20pending%20pull%20request%20and%20branch%2 >>>>>>>> 0Pipeline/view/change-requests/job/PR-198/ >>>>>>>> >>>>>>>> Guille >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Guille Polito >>>>>>>> >>>>>>>> >>>>>>>> Research Engineer >>>>>>>> >>>>>>>> French National Center for Scientific Research - >>>>>>>> *http://www.cnrs.fr* <http://www.cnrs.fr> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>>> >>>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> French National Center for Scientific Research - *http://www.cnrs.fr* >>>>>> <http://www.cnrs.fr> >>>>>> >>>>>> >>>>>> >>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>> >>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> >>>> Research Engineer >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr* >>>> <http://www.cnrs.fr> >>>> >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 16, 2017

Re: [Pharo-dev] @About posting here

by Guillermo Polito

Hi Frank, I'll just repeat Stef's message: It's not about being straight or having unpopular opinions. It's about being rude and on the limit of the insult. I feel myself some harshness in your messages, it's like you're saying that everybody but you is stupid. I know that you did not say that "explicitly" but that's the way it feels. And I'm sure I'm not the only one feeling like it. Of course, that did not prevent me to answer you politely, but at the end what will happen is that people will not answer you anymore. Just take into account that if many people think already that your mails are aggressive, there may be some fault on your side too. That said, this does not mean that I want to "censor" you. Just choose better your words but keep the same content. Thanks, Guille On Wed, Aug 16, 2017 at 12:52 PM, Frank-B <frank.berger.software(a)web.de> wrote: > Phil, > > nice attempt to drill and silence me! My advise: They all failed! > > If somebody can't cope with straight critics or unpopular opinions that > aint > my fault. > > Frank > who never worried about being labeled and > from a country where free speech is still welcome > > > > -- > View this message in context: http://forum.world.st/Anybody- > using-Orca-Smalltalk-to-JavaScript-tp4960519p4961628.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 16, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Denis Kudriashov

2017-08-16 12:28 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Wed, Aug 16, 2017 at 12:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> >> 2017-08-16 12:02 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> >>> >>> On Wed, Aug 16, 2017 at 10:50 AM, Denis Kudriashov <dionisiydk(a)gmail.com >>> > wrote: >>> >>>> There is possibility where delay can be used during startup/shutdown. >>>> Library can clean resources which are managed by kind of pool which >>>> organizes timeout logic to enter synchronization monitor. >>>> >>>> I checked Seamless which manages connections this way. But I not found >>>> any issue there. >>>> >>> >>> Can you explain this in more detail? I want to know exactly what "clean >>> resources", "kind of pool" and "timeout logic to enter synchronization >>> monitor" mean concretely. >>> >>> Also, how are you subscribing seamless to the startup list? >>> >> >> Seamless server cleans all opened connections on image save. It registers >> using: >> >> SessionManager default registerNetworkClassNamed: self name >> >> I copied this logic from ZnServer. >> But Seamless manages connections using ObjectPool. So when image save is >> performed "connectionPool clear" is evaluated. It closes connections and >> reset all caches. Problem that ObjectPool is protected by Monitor with >> timeout option. And #clear method enters this monitor. It is possible that >> at the time of image save monitor will be busy and #clear method will wait >> for delay to enter critical section. >> >> > Does this means that there may be a timeout while closing connections > during shutdown? > Because in that case the session manager will continue shutting down > things and seamless may be not fully cleaned up upon next startup. > Yes. It is possible. But it looks like very rare case. Interesting if there is real solution to this. >From the other side I am not sure why connections should be closed when image is saved. In case of Seamless pool is constructed in the way that it checks if socket is valid before borrow it to user. > > >> >> >>> >>>> >>>> >>>> 2017-08-16 1:46 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>>> >>>>> >>>>> On Tue, Aug 15, 2017 at 3:25 PM, Ben Coman <btc(a)openinworld.com> >>>>> wrote: >>>>> >>>>>> In case any of the shutdown/startup scripts use a delay, now or in >>>>>> the future, >>>>>> I'd first try at highestPriority-1 to avoid influence on the >>>>>> DelayScheduler. >>>>>> but then Eliot's suggestion to valueUnpreemptively may avoid that >>>>>> anyway. >>>>>> >>>>> >>>>> Why should a shutdown/startup use a delay? startup and shutdown should >>>>> be fast and not be blocked... If there is a delay on client code, it should >>>>> block a client thread, not a system thread... >>>>> >>>>> Moreover, I see a series of issues in having the delay process running >>>>> in higher priority than the startup. If I'm wrong, please correct me >>>>> because otherwise that means there is something I'm not getting. >>>>> >>>>> First, today the Delay scheduling process is being terminated on >>>>> shutdown and being re-initialized on startup. This means that even if a >>>>> shutdown/startup action tries to use a delay that will fail/block >>>>> indefinitely? >>>>> >>>>> Second, what happens with race conditions between the startup and the >>>>> delay process? If the shutdown is in the middle of terminating the delay >>>>> process and the delay process gets suddenly activated? >>>>> >>>>> stopTimerEventLoop >>>>> "Stop the timer event loop" >>>>> >>>>> timerEventLoop ifNotNil: [ timerEventLoop terminate ]. >>>>> timerEventLoop := nil. >>>>> >>>>> Maybe before terminating the timerEventLoop we need to suspend it? >>>>> That will at least atomically (primitive) remove the process from the ready >>>>> list and avoid it from being activated again, no? >>>>> >>>>> In any case, I see no good in letting a delay work on startup. That is >>>>> far too low level and the system would be in a far too unstable state to >>>>> run any code other than the startup itself. >>>>> >>>>> >>>>>> btw, what happens if an error occurs inside valueUnpreemptively? >>>>>> Does the normal priority debugger still get to run? >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> On Mon, Aug 14, 2017 at 6:42 PM, Guillermo Polito < >>>>>> guillermopolito(a)gmail.com> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'm proposing a kind-of critical change that I believe is very good >>>>>>> for the health of the system: I want that the startup of the system runs in >>>>>>> maximum priority and becomes non-interruptable. >>>>>>> >>>>>>> Right now, when you save your image, the shutdown and startup are >>>>>>> run in the same priority than the process that triggered the save (usually >>>>>>> the ui or the command line, priority 40). This can cause lots of problems >>>>>>> and race conditions: processes with higher priorities can interrupt the >>>>>>> shutdown/startup and try to do something while the system is unstable. As a >>>>>>> side effect also, when you use extensively the command line, you start >>>>>>> stacking startup contexts from old sessions: >>>>>>> >>>>>>> ... >>>>>>> session 3 ctxt 4 <- This guy makes a save and a new session starts >>>>>>> session 3 ctxt 3 >>>>>>> session 3 ctxt 2 >>>>>>> session 3 ctxt 1 >>>>>>> session 2 ctxt 4 <- This guy makes a save and a new session starts >>>>>>> session 2 ctxt 3 >>>>>>> session 2 ctxt 2 >>>>>>> session 2 ctxt 1 >>>>>>> session 1 ctxt 4 <- This guy makes a save and a new session starts >>>>>>> session 1 ctxt 3 >>>>>>> session 1 ctxt 2 >>>>>>> session 1 ctxt 1 >>>>>>> >>>>>>> Old contexts are never collected, and the objects they referenced >>>>>>> neither. >>>>>>> >>>>>>> To fix these two problems I propose to do every image save/session >>>>>>> start in a new process in maximum priority. That way, other process should >>>>>>> not be able to interrupt the startup process. Moreover, every session >>>>>>> shutdown/startup should happen in a new clean process, to avoid the session >>>>>>> stacking. >>>>>>> >>>>>>> For normal users, this should have no side effect at all. This >>>>>>> change will have a good impact on people working on the debugger and the >>>>>>> stack such as fueling-out the stack because they will have a cleaner stack. >>>>>>> >>>>>>> There is however a side-effect/design point to consider: startup >>>>>>> actions should be quick to run. If a startup action requires to run a >>>>>>> long-running action such as starting a server or managing a command line >>>>>>> action, that should run in a separate process with lower priority (usually >>>>>>> userPriority). In other words, the startup action should create a new >>>>>>> process managing its action. >>>>>>> >>>>>>> If you want to review (and I'd be glad) >>>>>>> >>>>>>> Pull request: https://github.com/pharo-project/pharo/pull/198 >>>>>>> Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 >>>>>>> Current validation going on: https://ci.inria.fr/pharo-ci-j >>>>>>> enkins2/job/Test%20pending%20pull%20request%20and%20branch%2 >>>>>>> 0Pipeline/view/change-requests/job/PR-198/ >>>>>>> >>>>>>> Guille >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> Guille Polito >>>>>>> >>>>>>> >>>>>>> Research Engineer >>>>>>> >>>>>>> French National Center for Scientific Research - >>>>>>> *http://www.cnrs.fr* <http://www.cnrs.fr> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>> >>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Guille Polito >>>>> >>>>> >>>>> Research Engineer >>>>> >>>>> French National Center for Scientific Research - *http://www.cnrs.fr* >>>>> <http://www.cnrs.fr> >>>>> >>>>> >>>>> >>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>> >>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> >>> Research Engineer >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr* >>> <http://www.cnrs.fr> >>> >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Aug. 16, 2017

[Pharo 70 ] build 37 - PR 206 File names should not be canonicalised by default

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20307/File-names-should-not-be-canonicali… https://github.com/pharo-project/pharo/pull/206

Aug. 16, 2017

Re: [Pharo-dev] @About posting here

by Frank-B

Phil, nice attempt to drill and silence me! My advise: They all failed! If somebody can't cope with straight critics or unpopular opinions that aint my fault. Frank who never worried about being labeled and from a country where free speech is still welcome -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 16, 2017

Re: [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20

by henry

I was thinking of possibly submitting, yet having never done so before, I find the amount of documentation learning just to submit in acceptable format has put me off. I just want to focus on building not talking about building. That that limits the degree of spread of my work, so be it. Thank you anyways, good luck with the conference, - HH > -------- Original Message -------- > Subject: [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20 > Local Time: August 16, 2017 5:08 AM > UTC Time: August 16, 2017 9:08 AM > From: smalltalk(a)stefan-marr.de > To: Pharo Development List <pharo-dev(a)lists.pharo.org>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Call for Papers: Metaâ17 > ======================== > > Workshop on Meta-Programming Techniques and Reflection > > Co-located with SPLASH 2017 > October 22, 2017, Vancouver, Canada > > Twitter @MetaAtSPLASH > http://2017.splashcon.org/track/meta-2017 > > The heterogeneity of mobile computing, cloud applications, multicore > architectures, and other systems leads to increasing complexity of software and > requires new approaches to programming languages and software engineering > tools. To manage the complexity, we require generic solutions that can be > adapted to specific application domains or use cases, making metaprogramming an > important topic of research once more. However, the challenges with > metaprogramming are still manifold. They start with fundamental issues such as > typing of reflective programs, continue with practical concerns such as > performance and tooling, and reach into the empirical field to understand how > metaprogramming is used and how it affects software maintainability. Thus, > while industry accepted metaprogramming on a wide scale with Ruby, Scala, > JavaScript and others, academia still needs to answer a wide range of questions > to bring it to the same level of convenience, tooling, and programming styles > to cope with the increasing complexity of software systems. > > This workshop aims to explore meta-level technologies that help tackling the > heterogeneity, scalability and openness requirements of emerging computations > platforms. > > ### Topics of Interest > > The workshop is a venue for all approaches that embrace metaprogramming: > > - from static to dynamic techniques > - reflection, meta-level architectures, staging, open language runtimes > applications to middleware, frameworks, and DSLs > - optimization techniques to minimize runtime overhead > - contract systems, or typing of reflective programs > reflection and metaobject protocols to enable tooling > - case studies and evaluation of such techniques, e.g., to build applications, > language extensions, or tools > - empirical evaluation of metaprogramming solutions > - security in reflective systems and capability-based designs > - meta-level architectures and reflective middleware for modern runtime > platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) > - surveys, conceptualization, and taxonomization of existing approaches > > In short, we invite contributions to the workshop on a wide range of topics > related to design, implementation, and application of reflective APIs and > meta-programming techniques, as well as empirical studies and typing for such > systems and languages. > > ### Workshop Format and Submissions > > This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. Therefore, we seek the following kinds of publications: > > â¢ technical paper: max. 8 pages, excluding references > â¢ position and work-in-progress paper: 1-4 pages, excluding references > â¢ technology demos or a posters: 1-page abstract > > All papers are to be submitted using the SIGPLAN acmart style. Please use the provided double-column Latex or Word templates. > > For the submission, please use the submission system at: https://meta17.hotcrp.com/ > > The workshop technical papers will be published in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work and wonât be included in the ACM DL proceedings. > > ### Important Dates > > Abstract Submission: 07 August 2017 > Paper Submission: 20 August 2017 > Author Notification: 06 September 2017 > Position/WIP Paper Deadline: 08 September 2017 > Camera Ready Deadline: 18 September 2017 > Position/WIP Notification: 21 September 2017 > > ### Program Committee > > The program committee consists of the organizers and the following reviewers: > > Anya Helen Bagge, University of Bergen, Norway > Daniele Bonetta, Oracle Labs, Austria > Nicolas Cardozo, Universidad de los Andes, Colombia > Sebastian Erdweg, TU Delf, The Nederlands > Robert Hirschfeld, HPI, Germany > Roberto Ierusalimschy, PUC-Rio, Brazil > Pablo Inostroza, CWI, The Nederlands > Kim Mens, Universite Catholique de Louvain, Belgium > Cyrus Omar, Carnegie Mellon University, USA > Guillermo Polito, CNRS, France > Tiark Rompf, Purdue University, USA > Tom Van Cutsem, Nokia Bell Labs, Belgium > Takuo Watanabe, Tokyo Institute of Technology, Japan > > ### Workshop Organizers > > Shigeru Chiba, University of Tokyo > Elisa Gonzalez Boix, Vrije Universiteit Brussel > Stefan Marr, Johannes Kepler University Linz > > ### Contact information > > For further inquires, do not hesitate to contact the organizers via meta AT soft.vub.ac.be > > http://2017.splashcon.org/track/meta-2017 > > -- > Stefan Marr > Johannes Kepler UniversitÃ¤t Linz > http://stefan-marr.de/research/

Aug. 16, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Guillermo Polito

On Wed, Aug 16, 2017 at 12:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-08-16 12:02 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> >> >> On Wed, Aug 16, 2017 at 10:50 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> There is possibility where delay can be used during startup/shutdown. >>> Library can clean resources which are managed by kind of pool which >>> organizes timeout logic to enter synchronization monitor. >>> >>> I checked Seamless which manages connections this way. But I not found >>> any issue there. >>> >> >> Can you explain this in more detail? I want to know exactly what "clean >> resources", "kind of pool" and "timeout logic to enter synchronization >> monitor" mean concretely. >> >> Also, how are you subscribing seamless to the startup list? >> > > Seamless server cleans all opened connections on image save. It registers > using: > > SessionManager default registerNetworkClassNamed: self name > > I copied this logic from ZnServer. > But Seamless manages connections using ObjectPool. So when image save is > performed "connectionPool clear" is evaluated. It closes connections and > reset all caches. Problem that ObjectPool is protected by Monitor with > timeout option. And #clear method enters this monitor. It is possible that > at the time of image save monitor will be busy and #clear method will wait > for delay to enter critical section. > > Does this means that there may be a timeout while closing connections during shutdown? Because in that case the session manager will continue shutting down things and seamless may be not fully cleaned up upon next startup. > > >> >>> >>> >>> 2017-08-16 1:46 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> >>>> On Tue, Aug 15, 2017 at 3:25 PM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>>> In case any of the shutdown/startup scripts use a delay, now or in the >>>>> future, >>>>> I'd first try at highestPriority-1 to avoid influence on the >>>>> DelayScheduler. >>>>> but then Eliot's suggestion to valueUnpreemptively may avoid that >>>>> anyway. >>>>> >>>> >>>> Why should a shutdown/startup use a delay? startup and shutdown should >>>> be fast and not be blocked... If there is a delay on client code, it should >>>> block a client thread, not a system thread... >>>> >>>> Moreover, I see a series of issues in having the delay process running >>>> in higher priority than the startup. If I'm wrong, please correct me >>>> because otherwise that means there is something I'm not getting. >>>> >>>> First, today the Delay scheduling process is being terminated on >>>> shutdown and being re-initialized on startup. This means that even if a >>>> shutdown/startup action tries to use a delay that will fail/block >>>> indefinitely? >>>> >>>> Second, what happens with race conditions between the startup and the >>>> delay process? If the shutdown is in the middle of terminating the delay >>>> process and the delay process gets suddenly activated? >>>> >>>> stopTimerEventLoop >>>> "Stop the timer event loop" >>>> >>>> timerEventLoop ifNotNil: [ timerEventLoop terminate ]. >>>> timerEventLoop := nil. >>>> >>>> Maybe before terminating the timerEventLoop we need to suspend it? That >>>> will at least atomically (primitive) remove the process from the ready list >>>> and avoid it from being activated again, no? >>>> >>>> In any case, I see no good in letting a delay work on startup. That is >>>> far too low level and the system would be in a far too unstable state to >>>> run any code other than the startup itself. >>>> >>>> >>>>> btw, what happens if an error occurs inside valueUnpreemptively? >>>>> Does the normal priority debugger still get to run? >>>>> >>>>> cheers -ben >>>>> >>>>> On Mon, Aug 14, 2017 at 6:42 PM, Guillermo Polito < >>>>> guillermopolito(a)gmail.com> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm proposing a kind-of critical change that I believe is very good >>>>>> for the health of the system: I want that the startup of the system runs in >>>>>> maximum priority and becomes non-interruptable. >>>>>> >>>>>> Right now, when you save your image, the shutdown and startup are run >>>>>> in the same priority than the process that triggered the save (usually the >>>>>> ui or the command line, priority 40). This can cause lots of problems and >>>>>> race conditions: processes with higher priorities can interrupt the >>>>>> shutdown/startup and try to do something while the system is unstable. As a >>>>>> side effect also, when you use extensively the command line, you start >>>>>> stacking startup contexts from old sessions: >>>>>> >>>>>> ... >>>>>> session 3 ctxt 4 <- This guy makes a save and a new session starts >>>>>> session 3 ctxt 3 >>>>>> session 3 ctxt 2 >>>>>> session 3 ctxt 1 >>>>>> session 2 ctxt 4 <- This guy makes a save and a new session starts >>>>>> session 2 ctxt 3 >>>>>> session 2 ctxt 2 >>>>>> session 2 ctxt 1 >>>>>> session 1 ctxt 4 <- This guy makes a save and a new session starts >>>>>> session 1 ctxt 3 >>>>>> session 1 ctxt 2 >>>>>> session 1 ctxt 1 >>>>>> >>>>>> Old contexts are never collected, and the objects they referenced >>>>>> neither. >>>>>> >>>>>> To fix these two problems I propose to do every image save/session >>>>>> start in a new process in maximum priority. That way, other process should >>>>>> not be able to interrupt the startup process. Moreover, every session >>>>>> shutdown/startup should happen in a new clean process, to avoid the session >>>>>> stacking. >>>>>> >>>>>> For normal users, this should have no side effect at all. This change >>>>>> will have a good impact on people working on the debugger and the stack >>>>>> such as fueling-out the stack because they will have a cleaner stack. >>>>>> >>>>>> There is however a side-effect/design point to consider: startup >>>>>> actions should be quick to run. If a startup action requires to run a >>>>>> long-running action such as starting a server or managing a command line >>>>>> action, that should run in a separate process with lower priority (usually >>>>>> userPriority). In other words, the startup action should create a new >>>>>> process managing its action. >>>>>> >>>>>> If you want to review (and I'd be glad) >>>>>> >>>>>> Pull request: https://github.com/pharo-project/pharo/pull/198 >>>>>> Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 >>>>>> Current validation going on: https://ci.inria.fr/pharo-ci-j >>>>>> enkins2/job/Test%20pending%20pull%20request%20and%20branch%2 >>>>>> 0Pipeline/view/change-requests/job/PR-198/ >>>>>> >>>>>> Guille >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> French National Center for Scientific Research - *http://www.cnrs.fr* >>>>>> <http://www.cnrs.fr> >>>>>> >>>>>> >>>>>> >>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>> >>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> >>>> Research Engineer >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr* >>>> <http://www.cnrs.fr> >>>> >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 16, 2017