- Pharo-dev - lists.pharo.org

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

by Esteban Lorenzano

+1 > On 16 Aug 2017, at 02:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > 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] [Pharo-users] including Pillar in Pharo image by default

by Esteban Lorenzano

Hi, In general (you all know me), I have the policy of âdo not go alien just becauseâ which means we do not need to reinvent the wheel all the time and we need to stick with what is already there and known (I have pushed many changes in pharo following this direction, iceberg being just the latest), but we need to keep also the basis of what we are (which means: when we need to stay alien, we need to embrace it too). Said that: while I would LOVE to have a markdown compatible format, the amount of effort put on pillar to make it *what we need* and is a format used not just for doing README.md but to write books, etc., then replacing it would be complicated. butâ¦ I think we can do pillar syntax more âmarkdown alikeâ (and we can even have a stripped-pillar with would be even more like md), I would salute such change. cheers, Esteban > On 15 Aug 2017, at 19:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > >> >> >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> You hit several birds with one single mail. >> >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> > Jimmie et al. nicely reasoned arguments - and Doru's point about controlling >> > the syntax is an interesting one that I hadnât thought about. >> > >> > Personally, I find having too many similar syntaxâs confusing - contributing >> > to things is hard enough - having to remember that its !! Instead of ## and >> > ââ instead of ** is just frustrating for me. >> >> +1 >> >> Not only for docs, most platforms like Slack/Discord share the syntax, >> so now I'm getting "muscle memory" when typing literals using the >> backtick (`) character, quoting with > or pasting snippets using ``` >> >> +1. So I've posted this before... >> https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac…> >> describing that "The only strategy in getting people to switch to your product is to eliminate barriers" >> >> But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... >> >> So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." >> Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). > > +1! > >> >> cheers -ben >> >> >> > Sure, maybe we were first with Pillar, but for me, lots of programming is in >> > other languages, and I use Smalltalk where I can, and a hybrid of multiple >> > languages and projects is often the reality - so a lowest common denominator >> > of Markdown is just easier. The fact that we are quite close to what our >> > colleagues in other languages use (regardless of what Python has chosen), is >> > quite interesting. >> >> This helps building "bridges" with other communities. >> >> >> >> >> >> >> The language as a means of exchange is always the lowest common denominator. >> As long as it's "efficient enough" then I vote to use what other >> communities use. >> >> > That said, if the community wants to stick to its gunâs thats fine - I will >> > probably still investigate how to use Commonmark for myself, and will still >> > contribute to Pillar docs where I can (and curse history) - but I think we >> > are long better off trying to join emerging standards where we can >> > particularly if they arenât our core language thing. And it just makes it >> > less frictionless for ourselves and newcomers. >> >> The "Not Invented Here" syndrome is strong among Smalltalkers, it's >> important to be aware of this bias and think more than once whether >> eating our own dogfood adds value to the core of what Pharo brings. >> >> I think we missed some good years fighting with our own SCM and in the >> end git (or any other file based SCM) prevailed, even when it has >> limitations. >> >> Pareto (80-20) for everything non-core business should be a guide. >> >> > Of course, if we were to move, we would need to translate a lot of quality >> > docs to a new format - but I would be up for contributing to that if that >> > was a deciding factor. >> >> There are some Markdown exporters AFAIK, or it could be written. >> >> >> Esteban A. Maringolo

Aug. 16, 2017

Raffle Results of "Live Programming in Smalltalk development environments survey + raffle"

by Juraj Kubelka

Dear Smalltalkers, thank you again for participating in our survey. We are currently analyzing the results. Here, we would like to announce winners of the survey raffleâ¦ and winners are: - Craig Latta, and - Gabriel Omar Cotelli Congratulations! :-) The raffle draw was recorded and is available at: https://youtu.be/cRfPAAeF-xw <https://youtu.be/cRfPAAeF-xw> We will contact the winners in a private email in order to deliver the books to them. Regards, Juraj Kubelka, Romain Robbes, and Alexandre Bergel

Aug. 16, 2017

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

by henry

Sorry, I will figure out a host site and let you know. - HH > -------- Original Message -------- > Subject: Re: [squeak-dev] [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20 > Local Time: August 16, 2017 10:40 AM > UTC Time: August 16, 2017 2:40 PM > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > Pharo Development List <pharo-dev(a)lists.pharo.org>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Alright, here is my outline in a bit more detail. I would welcome any comments. > > - HH > >> -------- Original Message -------- >> Subject: Re: [squeak-dev] [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20 >> Local Time: August 16, 2017 9:56 AM >> UTC Time: August 16, 2017 1:56 PM >> From: henry(a)callistohouse.club >> To: henry <henry(a)callistohouse.club> >> Pharo Development List <pharo-dev(a)lists.pharo.org>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> >> >> Here would be my abstract. Perhaps I will continue, though the running system is incomplete, at least the rational and design could be discussed. >> >> - HH >> >>> -------- Original Message -------- >>> Subject: Re: [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20 >>> Local Time: August 16, 2017 6:48 AM >>> UTC Time: August 16, 2017 10:48 AM >>> From: henry(a)callistohouse.club >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> >>> >>> 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] [squeak-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20

by henry

Alright, here is my outline in a bit more detail. I would welcome any comments. - HH > -------- Original Message -------- > Subject: Re: [squeak-dev] [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20 > Local Time: August 16, 2017 9:56 AM > UTC Time: August 16, 2017 1:56 PM > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > Pharo Development List <pharo-dev(a)lists.pharo.org>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Here would be my abstract. Perhaps I will continue, though the running system is incomplete, at least the rational and design could be discussed. > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20 >> Local Time: August 16, 2017 6:48 AM >> UTC Time: August 16, 2017 10:48 AM >> From: henry(a)callistohouse.club >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> >> >> 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] @About posting here

by phil＠highoctane.be

I don't know why you think that anybody would silence you. Just the fact that you bother mentioning that is just a huge internal insecurity showcase to me. Come on, if we cared about popular opinions, this would be a javascript or nodejs list, not a Pharo list. I do not care a bit about popularity. I care about my customers being happy and accounts receivable clearing up on time so that I can provide for people who depend on me. As far as I am concerned, you actively contributed to your channel volume being set to mute on my side. That's how you come across and get on my nerves. Not because of what you write. Because of how. I do not have a problem with critics against Pharo, I am cursing daily in front of it. So far, my level of cursing is lower when working with Pharo than with other tool chains. Pharo is there, I am happy for it to be around. Since the 1.x era, this thing has massively improved. Pharo 7 will be wonderful. Bootstrapping, how great. Massively great. Vector graphics, super. VM seeing major improvements and speedup. Roassal: awesome. GT: nothing can touch it. Community: packed to the gills with people who actually deliver working and innovative code. Want to be part of it? Your loss if you choose not to. Otherwise, welcome. Contribute whatever you can. Docs are in a bad state? Grab the docker image for book production at https://github.com/cdlm/docker-texlive Clone something like https://github.com/SquareBracketAssociates/Booklet-Glorp, make a book about some stuff and push. It is all tears in the rain anyway. As if I cared. Phil 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. > >

Aug. 16, 2017

Re: [Pharo-dev] @Dimitris - Smalltalk the best IDE

by Frank-B

Dimitris, the case you refer to was closed on my side: I won't comment. But there was one false quotation on your side: > I never heard or read any pharoer to refer to Pharo as the best IDE. I did not write that! I referred to *Smalltalk in general* and I am deeply convinced that for o-o development *Smalltalk in general* has by far the "best" development environment based on objective features: It's the only one to tell instantly all senders, implementors, locally or globally, class refs and a lot of other things that others don't even dream of. BUT: I made not a single judgement on Pharo (except on it's UI for end-user products), simply because I don't know it sufficiently. And I agree, that Delphi was an extremely good product in my opinion primarily for the UI. I managed a project in Delhi many years ago but I did not code myself. My intend for writing here was beyond asking for the status of Smalltalk to JavaScript translators and alike to perhaps help to improve this and possibly a few other points. This is primarily concerning *my mid-range plans for a much better user interface*. My plans say that my UI will very easily support different Smalltalk dialects simoultaneously and it will be targeting professional business applications both in the browser and for the desk-top based on ONE code-base. But I am about to continue to do this ONLY in direct correspondance with writers here. I think this is much more productive and successful than having to fight ignorant, discriminatory and almost rasist postings from people who hate any critical and diverting opioins expressed in straight-forward but still correct language or who feel "insulted", because somebody does not agree with what they have been using. Being "pseudo-insulted" is the currently popular retorical attempt to suppress other people's opinions. Won't work on me! 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] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20

by henry

Here would be my abstract. Perhaps I will continue, though the running system is incomplete, at least the rational and design could be discussed. - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20 > Local Time: August 16, 2017 6:48 AM > UTC Time: August 16, 2017 10:48 AM > From: henry(a)callistohouse.club > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 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] FileSystem fix integration

by Alistair Grant

Hi Stef, On Wed, Aug 16, 2017 at 12:16:52PM +0200, Stephane Ducasse wrote: > I'm integrating 20307 and I would like to really thank you for > - the bug entry description > - all the comments > - and tests in the PR. > > Tx!!! Thanks for your kind words. And for integrating the PR :-) I've re-submitted 20165 Support segment path printing. So the open list is: - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing - https://github.com/pharo-project/pharo/pull/210 Note that this is a different PR from before, see the comments in the issue. - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile https://github.com/pharo-project/pharo/pull/133 - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… https://github.com/pharo-project/pharo/pull/137 - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… This is the first step in fixing FileReference>>isSymlink and extending support for all file attributes returned by stat() and lstat(). The parent issue is: https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… Still to be closed (won't fix): - https://pharo.fogbugz.com/f/cases/18042 - https://github.com/pharo-project/pharo/pull/75 And waiting on FFI / kernel resolution: - https://pharo.fogbugz.com/f/cases/5723/ - https://github.com/pharo-project/pharo/pull/92 Cheers, Alistair

Aug. 16, 2017

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

by Ben Coman

On Wed, Aug 16, 2017 at 7:46 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > 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... > okay. My response was a just reflex to not assume what some third-party developer might do. I'm not familiar with the startup/shutdown and had not considered it deeply. > 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? > That is not how I understand it works. The DelayScheduler process is not terminated, just suspended by DelayMicrosecondScheduler>>shutdown. #stopTimerEventLoop is not called during shutdown. > > 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. > That is effectively only called when changing which between different DelayScheduler-implementations. > 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? > I'm not completely happy with how the DelayScheduler shutdown happens now, whether some case might cause timingSemaphore to be triggered to run, and how #save/#restoreResumptionTimes are called from low-priority code which feels susceptible to race conditions (although I've not identified any). A while a go I was playing with the idea that to **ensure** the timerEventLoop doesn't run, you add another semaphore in middle activated by #shutDown, - but it was near a Pharo 5 release so I didn't push it in, and then failed to get back to it. From memory something like... DelayScheduler>>handleTimerEventLoop: microsecondNowTick .... suspendDelaysSemaphore ifNotNil: [ self saveResumptionTimes. suspendDelaysSemaphore wait. suspendDelaysSemaphore := nil. self restoreResumptionTimes. ]. DelayScheduler>>shutDown suspendDelaysSemaphore := Semaphore new. DelayScheduler>>startUp suspendDelaysSemaphore signal. I feel a dedicated sempahore would be more robust to control of the suspension of the DelayScehduler during shutdown/start, rather than leaving it waiting on the timingSemaphore that several things interact with and hoping none signal it. Maybe it time for me to try for my first Pharo 7 contribution. cheers -ben > 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