- Pharo-dev - lists.pharo.org

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

by Stefan Marr

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 Denis Kudriashov

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. 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> >

Aug. 16, 2017

Re: [Pharo-dev] @About posting here

by philippe.back＠highoctane.be

Because it works. Because GMail is able to make sense of all threads/groupings on a mobile phone. Because of GMail search is awesome on email. Because one can check what is going on in the community quitr fast that way. Discord being cool for more direct interaction. Now, why is it you seem to complain about this or that in about every thread? Content looks like interesting but tone comes across as pretty conflictual. That makes me just label you as a bore and not care about anything, which is contrary to your apparent intent. Lots of people on this list are in the industry for decades and have shipped product on various scales. TL;DR please behave. Phil On Aug 15, 2017 22:11, "Frank-B" <frank.berger.software(a)web.de> wrote: > @about this forum at world.st > > I have a lot of forum experience from studying "forum psychology and > sociology" in three different language and in various forums run by very > different software but I have never come about any system that is *nearly > as > crappy, sick and idiotic as this one here*: > > - various message don't show up here > - masses of emails that I am not interested in are polluting my email > client > (and I will stop this silly downloading tonight by directing them straight > into the delete folder) > - and one is never informed if there is any reply to one's posting, which > is > standard on almost all forums and comment part of blogs > - and there is no chance to directly reply to some post > - thus there is no branching of the subjects > - which makes following a sib-thread most difficult > > I am neither going to write answers in my email clent, not will I continue > to pollute my system with 99% unwanted messages. > > I just ask myself: Why are Smalltalk people with the "best" IDE of all > using > such a crappy system!? > > Mailing lists are something - in my view - soooo much outdated and just a > pain in the....! > > Now: Hunt me, shout at me, call me whatever you want! That's fine by me. It > would be the normal reaction of a crowd if a new sheep dares to criticise > what the crowd has been doing for long. I don't care! > > Regards > Frank > > > > > -- > View this message in context: http://forum.world.st/Anybody- > using-Orca-Smalltalk-to-JavaScript-tp4960519p4961497.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 16, 2017

Re: [Pharo-dev] Ugly smell: really long symbols/selectors

by Guillermo Polito

(ByteSymbol allInstances select: [ :e | e size > 50 ]) size "638" (ByteSymbol allInstances select: [ :e | e size > 50 and: [ e beginsWith: 'test' ] ]) size "200" Still 438 non test selectors. Some of them are class creation methods (#subclass:instanceVariables:...) I'm just saying this is a smell, wanted to share some of my catarsis :). Guille On Wed, Aug 16, 2017 at 9:35 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Guile, > have you inspect-ed the list? > I wouldn't be surprise that these are whole sentence acting as > specification in unit TestCase, > like whenBrowserReceiveOpenItShouldReturnTheWindowMorph... > > 2017-08-16 3:51 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> #'thisIsAVeryLongSelectorAndIfYoureHereWeHaveOnly49ImagineIH >> aveToWriteAllThisToArriveTo87ThenThisTo100' >> >> (ByteSymbol allInstances select: [ :e | e size > 100 ]) size >> => 36 >> >> (ByteSymbol allInstances select: [ :e | e size between: 50 and: 100 ]) >> size >> => 653 >> >> >> -- >> >> >> >> 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] Ugly smell: really long symbols/selectors

by Nicolas Cellier

Hi Guile, have you inspect-ed the list? I wouldn't be surprise that these are whole sentence acting as specification in unit TestCase, like whenBrowserReceiveOpenItShouldReturnTheWindowMorph... 2017-08-16 3:51 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > #'thisIsAVeryLongSelectorAndIfYoureHereWeHaveOnly49ImagineIHav > eToWriteAllThisToArriveTo87ThenThisTo100' > > (ByteSymbol allInstances select: [ :e | e size > 100 ]) size > => 36 > > (ByteSymbol allInstances select: [ :e | e size between: 50 and: 100 ]) size > => 653 > > > -- > > > > 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

@Craig

by Frank-B

Craig, I thought about it and I will send you a personal email with a lot more details. Please give me a few days but you should have it by next weekend. I would appreciate if we could continue the discussion directly and outside this mailing list, because, as you wrote, it is not really a matter of Pharo. Best regards Frank -- 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] Anybody using Orca Smalltalk to JavaScript?

by Frank-B

Good morning Craig, thank you very much for your reply. *Your statements sound very good and most interesting!* Please pardon, if I expressed myself improperly and not clear enough, which seems to have brought you on a wrong track. So, I propose, let's make a total reset to our current conversation and start it all over again! In order to be more successful in this, I would need more details and I will try to acquire them in the next few days. Is there any link and/or doc where I can get more details on your work and plans than there are available on: https://pharojs.github.io ? The cause of your last posting is that my interest in your concepts has grown tremendously. You will soon see why. I will give you a more details about my environment and intentions: - *WebSockets* are available and play an essential part in my UI concepts. - *Pharo* - I don't mind using Pharo for, let's say, some "intermediate code fractions" as long as the existing server image can keep the sources and generate UI definitions for the client from its definition data. The technical code interchange between Pharo and the Smalltalk I use works quite well. It must just be avoided to port >10.000 application and test classes wtih >200K methods and all my own tools to Pharo. No way! - *User Interface* it seems that we are discussing here two levels, which should be seen separately although they closely interact, of course: 1) there is your part, which consists (in my simple words) of some browser add-on 2) there will be another part, which - at least over the next few years - consists of the by far most comprehensive UI library on the market, which is best capable of providing a desk-top look-and-feel and which much later I intend to substitute by a Smalltalk UI library (see below) 3) there partially are already and will soon be much more of my code, which in the near future acts as *middle layer* with these main purposes to: 3a) Generate all of the UI components using 2) only from definition data, whose original resides in my server image and which is serialized and provided to the client - mainly in a start-up batch procedure and to a smaller part also during run-time by responding to user actions and/or events I have been using an earlier version of this UI lib a few years ago based on handwritten JS code (what a nightmare for a Smalltalker to write JS code in these stone-age tools [I used Eclipse]) for a smaller project and from there I have some experience, which as far as this lib is concerned is mostly positive and for JS just the opposite primarily for the almost non-existing IDE and the crap of file-based sources in general Side-remark1: Why don't want these ignorant idiots who develop JavaScript and its primitive tools refuse to learn from Smalltalk?!?! In a JS forum, some of them wanted to explain me what "o-o" means although I made the clear statement that I have mostly Smalltalk experience. Side-remark2: I used Joose.it, a JavaScript extension that uses a somewhat Smalltalk-like syntax. It was developed by a former HPI student in Potsdam who came from the Smalltalk world. Brilliant! 3b) The middle layer will also act as a generic and data-driven message and data exchange interface with the server, whose purpose is to automate and mostly handle in a generic fashion all the required message passing between the "V" in the client and the "M" in the server as in MVC. 3c) The middle layer will also provide some lower-level "C"ontrollers, which again will mostly consist of data as a first and generic user action control system. 3d) Soon later the data-driven middle layer will be the precondition and technical basis of an UI editor, which is to enable low-skilled programmers, consultants and even somewhat trained and motivated end-users to modify or enhance parts (primarily containers, canvasses) of the prepared UI to their taste and needs. This is the logical extension to and it must work closely together with my long existing user-extendable data models, which constitute an important feature of my applications. 4) My long-term but most important plans (again: the UI iS THE decisive part in standard software) go far beyond this scenario. To cut it short, just the core points: 4a) The JS lib must be fully replaced by a mostly compatible Smalltalk lib (that aint no simple work). 4b) There must be a "private" browser, which offers Smalltalk direct access to the DOM without the current limitations (SOP single origin policy being just one of them) and which sends events straight to Smalltalk. 4c) This private browser should ideally become a technically integrated part of the whole Smalltalk scenario. I know that this is feasable. This will make my mass-market applications independent of the big-G evil giant who is about to extend their monopoly to the browser usages also due to FF's incapabilities to keep it's market share and with G's latest intention to regulate the advertising market by setting their rules in their unfortunately most popular browser. A few more general notes: - there is no room for this ugly, insane crap called *html* in most of my scenarios. It'll all go straight to the DOM. - the *browser* in my scenarios comes in two appearances: a) as a classical browser (to which I have lots of good ideas) b) as a desk-top like UI, which does not appear to be a browser but technically still is by 100% - I have lots of concepts and ideas concerning the user interface (those parts that the user really interacts with) and one of my hopes is that in the long-run this will solve Smalltalk's greatest deficiencies, which are in the lack of a really user-friendly and standard-like looking UI. See my posting here above of 13. Aug. 2017 - 22:42. - I do have a neither finished nor yet presentable white paper, size close to 100 pages, about my UI plans but I do not want to disclose this by now. It's far too early. - There is an important caveat in the close integration of the definition data with the UI parts, which mainly are an extension to what already exists in the definition data. It will neither be possible nor make any sense to extract some parts of it and use them separately. It's either all or nothing. Also, the learning curve is quite high, because the existing framework simplifies, standardizes and automates lot's of things, which must otherwise be programmed individually, but this causes a lot of learning requirements of the extemely well documented abstract and generic parts of my class tree - and it's not in Pharo. Best regards Frank -- 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

Ugly smell: really long symbols/selectors

by Guillermo Polito

#'thisIsAVeryLongSelectorAndIfYoureHereWeHaveOnly49ImagineIHaveToWriteAllThisToArriveTo87ThenThisTo100' (ByteSymbol allInstances select: [ :e | e size > 100 ]) size => 36 (ByteSymbol allInstances select: [ :e | e size between: 50 and: 100 ]) size => 653 -- 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

File & Socket Handle Access

by Eliot Miranda

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 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% >> 20Pipeline/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

Aug. 15, 2017