February 2022 - Pharo-users

Re: Error when running OSUnixSubprocess - posix_spawn() error

by bajger＠gmail.com

Hi Guille, Thanks for your reply! The problem is not permanent, so I cannot reproduce now :( It usually happens (not always) with fresh image of launcher (after loading Launcher project). Is seems that some file keeps hanging that causes that error. I will confirm if evaluating command directly produce same error, if I will experience this again.

Feb. 9, 2022

Re: Error when running OSUnixSubprocess - posix_spawn() error

by Guillermo Polito

Hi David, What is the function that is actually failing? I would assume itâs something called in #internalRun. I assume you have tried executing the process from the command line (quick check I always do when finding these kind of problems :P). $ echo -n $(pgrep -a -f Pharo | grep ''.image'' | grep -v ''.bash''| grep -v XXX) G > El 4 feb 2022, a las 17:48, bajger(a)gmail.com escribiÃ³: > > Greetings Pharoers! > > I have following problem when using OSSubprocess library. If I run a method that uses code below, it fails: Error: Error: posix_spawn(), code: 9, description: Bad file descriptor > > Any thoughts, hints are welcome! > > My code redirects stdout, stdin in order to catch system outputs from inside of Pharo. > > Subprocess code does following: > OSUnixSubprocess>>runAndWaitWithStdOutput > self > redirectStdout; > redirectStderr; > runAndWaitOnExitDo: [ :termProcess :outString :errString | > termProcess isSuccess > ifTrue: [ ^ outString ] > ifFalse: [ "commands to handle ex message here" ] ] > > Now if I run, it fails: > > Error: Error: posix_spawn(), code: 9, description: Bad file descriptor > OSSUnixSystemAccessor(Object)>>error: > OSSUnixSystemAccessor>>strerror:message: > OSSUnixSubprocess>>internalRun > [ self internalRun ] in OSSUnixSubprocess>>run in Block: [ self internalRun ] > BlockClosure>>ensure: > OSSUnixSubprocess>>run > OSSUnixSubprocess>>runAndWaitOnExitDo: > OSSUnixSubprocess>>runAndWaitWithStdOutput > ... > .. > . > PhLImageProcessListCliCommand(PhLCliCommand)>>executeOSShellCommand > > So it seems that OSUnixSubprocess uses some file that remains opened probably in OS? > Command that is passed to OSSubprocess is generated by args: > ^ Array with: 'echo' with: '-n' with: ('$(pgrep -a -f Pharo | grep ''.image'' | grep -v ''.bash''| grep -v {1})' format: {self currentVMPid asString})

Feb. 9, 2022

Sharing and publishing Pharo powered data stories

by Offray Vladimir Luna CÃ¡rdenas

Hi, We are combining Markdeep and STON in a light format to share and publish Pharo powered data stories and visualizations written/crafted in Glamorous Toolkit's Lepiter. In this link you can find a demo of the published output, that, of course can be imported back to Lepiter: https://mutabit.com/repos.fossil/malleable-systems/doc/trunk/wiki/en/mallea… And below you can find a preview of this data story. Our light format have some differential values over other popular data stories publishing formats, like Jupyter Notebook: a) Its human and browser readable, in contrast IPynb JSON and Python exports are readable by one, but not the other. b) it only requires (3mb) Fossil + (350K) Markdeep to be stored, versioned, shared and published. Other DVCS, web folders can be used and is a big contrast with complicated and/or oligopolistic support to make a format (Ipynb) web renderable. c) The same published document can be imported back to Lepiter. When a Jupyter document is published as HTML, it can not be imported back from there to Jupyter (I imagine something similar happens with RStudio or OrgMode, but I have not experienced data workflows on the last tools by myself). And here is the respective Nitter/Twitter thread with details and alternative narrative: https://nitter.net/offrayLC/status/1490130769603444742#m <https://nitter.net/offrayLC/status/1490130769603444742#m> Cheers, Offray https://i.imgur.com/GhbaSZc.png

Feb. 8, 2022

Pharo GSoC 2022 call for projects

by Sebastian Jordan Montano

Hello to all, We, as Pharo organization, are appliying to the Google Summer of Code (GSoC) 2022 version. More info in: https://summerofcode.withgoogle.com/ >From GSoC Page: "Google Summer of Code is a global, online program focused on bringing new contributors into open source software development. GSoC Contributors work with an open source organization on a 12+ week programming project under the guidance of mentors." Now we are preparing to postulate. We would like to have the most projects as possible. Like that, we will contribute to Pharo and to Open Source in general. If you have any project and you are willing to be a mentor please send us your proposal! We would be happy to work with you. Yours sincerely, Sebastian Jordan GSoC Program Organizer from Pharo Consortium

Feb. 8, 2022

[ANN] Announcing the Winner of the 2022 JRMPC Competition

by horrido.hobbies＠gmail.com

I am pleased to announce the winner of this year's JRMPC competition. The judges reviewed all the submissions and came to the extraordinary decision that onlyÂ **Ana DuCristea**Â of John G. Diefenbaker High School in Calgary, AB was worthy of an award. Her work was outstanding and constituted enormous dedication and enthusiasm for Smalltalk. Unfortunately, none of the other contestants rose to the occasion and there will be no Second or Third Prizes. Therefore, it is my decision that Ana DuCristea will receive the full prize fund of $2,500. My most heart-felt congratulations to Ana. Well done!

Feb. 7, 2022

First Call for Papers: 15th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2022)

by Andrei Chis

------------------------------------------------------------------------ 15th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2022) December 5-10, 2022 Auckland, New Zealand https://conf.researchr.org/home/sle-2022 http://www.sleconf.org/2022 Follow us on twitter: https://twitter.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 15th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2022), held in conjunction with SPLASH, GPCE and SAS 2022. Based on the future developments the conference will be hosted in Auckland, New Zealand on December 5-10, 2022. --------------------------- Topics of Interest --------------------------- SLE covers software language engineering rather than engineering a specific software language. Topics of interest include, but are not limited to: - Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g. design rules, well-formedness constraints) - Techniques for specifying behavioral / executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches - Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages - Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms - Software Language Maintenance - Software language reuse - Language evolution - Language families and variability, language and software product lines - Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) - Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications - "Synergies between Language Engineering and emerging/promising research areas" - AI and ML language engineering (e.g., ML compiler testing, code classification) Quantum language engineering (e.g., language design for quantum machines) - Language engineering for physical systems (e.g., CPS, IoT, digital twins) - Socio-technical systems and language engineering (e.g., language evolution to adapt to social requirements) - Etc. --------------------------- Types of Submissions --------------------------- SLE accepts the following types of papers: - **Research papers**: These are "traditional" papers detailing research contributions to SLE. Papers may range from 6 to 12 pages in length, and may optionally include 2 further pages of bibliography/appendices. Papers will be reviewed with an understanding that some results do not need 12 full pages and may be fully described in fewer pages. - **New ideas / vision papers**: These are papers that may describe new, unconventional software language engineering research positions or approaches that depart from standard practice. They can describe well-defined research ideas that are at an early stage of investigation. They could also provide new evidence to challenge common wisdom, present new unifying theories about existing SLE research that provides novel insight or that can lead to the development of new technologies or approaches, or apply SLE technology to radically new application areas. New ideas / vision papers must not exceed 5 pages, and may optionally include 1 further page of bibliography / appendices. - **SLE Body of Knowledge**: The SLE Body of Knowledge (SLEBoK) is a community-wide effort to provide a unique and comprehensive description of the concepts, best practices, tools and methods developed by the SLE community. To this respect, the SLE conference will accept surveys, essays, open challenges, empirical observations and case study papers on the SLE topics. These can focus on but they are not limited to methods, techniques, best practices and teaching approaches. Papers in this category can have up to 20 pages, including bibliography/appendices. - **Tool papers**: These are papers which focus on the tooling aspects which are often forgotten or neglected in research papers. A good tool paper focuses on practical insights that are likely to be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography / appendices. They may optionally come with an appendix with a demo outline / screenshots and/or a short video/screencast illustrating the tool. **Workshops**: Workshops will be organized by SPLASH. Please inform us and contact the SPLASH organizers if you would like to organize a workshop of interest to the SLE audience. Information on how to submit workshops can be found at the SPLASH 2022 Website. --------------------------- Two submission rounds --------------------------- For the first time, SLE is introducing a two-phase submission and review process. This will give authors submitting to the first round an extra opportunity to improve their work (if needed) based on the comments and feedback by the reviewers. Furthermore, this will increase the quality of SLE accepted papers. Manuscripts can be submitted to any of the two submission rounds. Decisions on the papers submitted to the **first round** will be: accept, reject or re-submit revised version. While rejected papers must not, revised versions may be submitted to the second round, with an accompanying response letter to the reviewers stating the changes made and how the authors addressed the reviewersâ criticisms. Re-submissions will be reviewed by the same reviewers. Decisions on fresh papers submitted to the **second round** will be: accept or reject. The authors of those papers that are likely to be rejected but have at least one reviewer who is championing it will have the chance to respond to the reviewers before the final decision is made. --------------------------- Important Dates --------------------------- All dates are Anywhere on Earth. * 1st round submissions * Abstract submissions: April 6, 2022 * Paper submissions: April 13, 2022 * Notification: May 13, 2022 * 2nd round submissions * Abstract submissions: July 8, 2022 (tentative) * Paper submissions: July 15, 2022 (tentative) * Review notification: September 7, 2022 (tentative) * Author response period: September 12, 2022 (tentative) * Notification: September 19, 2022 (tentative) * Artifact submissions: September 26, 2022 (tentative) * Artifact kick-the-tires Author response: October 10, 2022 (tentative) * Artifact notification: October 24, 2022 (tentative) * Camera-ready (for both rounds): November 4, 2022 (tentative) * Conference: December 5-10, 2022 (TENTATIVE) **COVID-19 Disclaimer** Due to the uncertainties related to the current COVID-19 pandemic, the second round submission deadlines, the artifact evaluation deadlines, the camera-ready deadline and the conference dates are still *preliminary* and will be closed in the next few weeks. --------------------------- Format --------------------------- Submissions have to use the ACM SIGPLAN Conference Format "acmart"(http://sigplan.org/Resources/Author/#acmart-format) please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template(https://www.acm.org/binaries/content/assets/publications/consolida…, and that the document class definition is `\documentclass[sigplan,anonymous,review]{acmart}`. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. In this line, SLE will follow the double-blind process. Author names and institutions should be omitted from submitted papers, and references to the authorsâ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. The submission website is: https://sle22.hotcrp.com --------------------------- Concurrent Submissions --------------------------- Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLANâs Republication Policy (http://www.sigplan.org/Resources/Policies/Republication) Submitters should also be aware of ACMâs Policy and Procedures on Plagiarism (http://www.acm.org/publications/policies/plagiarism_policy) Submissions that violate these policies will be desk-rejected. --------------------------- Policy on Human Participant and Subject Research --------------------------- Authors conducting research involving human participants and subjects must ensure that their research comply with their local governing laws and regulations and the ACMâs general principles as stated in the ACMâs Publications Policy on Research Involving Human Participants and Subjects (https://www.acm.org/publications/policies/research-involving-human-particip…) Submissions that violate this policy will be rejected. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning novelty, correctness, significance, readability, and alignment with the conference call. New ideas/vision papers will be evaluated primarily concerning novelty, significance, readability, and alignment with the conference call. SLEBoK papers will be reviewed on their significance, readability, topicality and capacity of presenting/evaluating/demonstrating a piece of BoK about SLE. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review, at the discretion of the PC chairs. After each review round, authors will get a chance to respond before a final decision is made. --------------------------- Artifact Evaluation --------------------------- For the seventh year, SLE will use an evaluation process for assessing the quality of the artifacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted research papers are invited to submit artifacts. For more information, please have a look at the Artifact Evaluation (http://www.sleconf.org/2022/ArtifactEvaluation.html) page. --------------------------- Special Issue --------------------------- A special issue on the conference topic in a high-impact journal is under negotiation. --------------------------- Awards --------------------------- - **Distinguished paper**: Award for most notable paper, as determined by the PC chairs based on the recommendations of the programme committee. - **Distinguished artifact**: Award for the artifact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artifact evaluation committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. **AUTHORS TAKE NOTE**: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- SLE and Doctoral Students --------------------------- SLE encourages students to submit to the SPLASH doctoral symposium. Authors of accepted papers will have the chance to present their work to the SLE audience, too. --------------------------- Organisation --------------------------- Chairs: * General chair: Bernd Fischer, Stellenbosch University, South Africa * PC co-chair: Lola BurgueÃ±o, Open University of Catalonia, Spain * PC co-chair: Walter Cazzola, UniversitÃ degli Studi di Milano, Italy * Artefact Evaluation co-chair: Thomas KÃ¼hn, Karlsruhe Institute of Technology, Germany * Artefact Evaluation co-chair: Juliana A. Pereira, Pontifical Catholic University of Rio de Janeiro, Brazil Program committee: Shaukat Ali, Simula Research Laboratory, Norway Arvid Butting, Aachen University, Germany Marsha Chechik, University of Toronto, Canada Shigeru Chiba, University of Tokyo, Japan BenoÃ®t Combemale, University of Rennes, France Zhenjiang Hu, Peking University, China JÃ¶rg Kienzle, McGill University, Canada Dimitris Kolovos, University of York, UK Thomas KÃ¼hn, Karlsruhe Institute of Technology, Germany Juan de Lara, Universidad AutÃ³noma de Madrid, Spain Stefan Marr, University of Kent, UK Marjan Mernik, University of Maribor, Slovenia Natsuko Noda, Shibaura Institute of Technology, Japan Juliana A. Pereira, Pontifical Catholic University of Rio de Janeiro, Brazil Elizabeth Scott, University of London, UK Marco Servetto, Victoria University of Wellington, New Zealand Emma SÃ¶derberg, Lund University, Sweden Walid Taha, Halmstad University , Sweden Marco Tullio Valente, Universidade Federal de Minas Gerais, Brazil Erik Van Wyk, University of Minnesota , USA Alfonso de la Vega, University of Cantabria, Spain Ran Wei, Dalian University of Technology, China Andreas Wortmann, Stuttgart University, Germany Vadim Zaytsev, University of Twente, Netherlands Steffen Zschaler, Kingâs College London, UK --------------------------- Contact --------------------------- For additional information, clarification, or answers to questions, please contact the Programme Chairs (Lola BurgueÃ±o and Walter Cazzola) at sle22-chairs _at_ di.unimi.it.

Feb. 7, 2022

[Issue tracker] Please check your older issues

by Marcus Denker

Hi, We are seeing lots of issue that are still open, but already fixed or just not valid anymore. e.g. - the fix that was merged but the issue was not closed (sometimes GitHub has problems doing that) - Bug was fixed independent of the issue - The issue is just not relevant anymore It is often quite time consuming to even find out that an issue is already fixedâ¦ It would be nice if everyone could check the issues that - you submitted yourself - that are assigned to you - [Bonus] where you were part of some discussion https://github.com/pharo-project/pharo/issues Marcus

Feb. 7, 2022

Re: aio event forwarding not supported

by Davide Varvello

Workaround!!! Here I am again. I found a workaround for theÂ PipeableOSProcess and the Big Sur update. It is the usage of LibC, I was not aware of that class, it's useful. I was able to reproduce my logic with LibC, this article (https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html) is recommended. Cheers Davide

Feb. 7, 2022

Re: [Pharo-users] Re: What is "Fluid"?

by contactme＠kathe.in

On Monday, February 07, 2022 09:31 CET, Marcus Denker <marcus.denker(a)inria.fr> wrote: Â Â Â On 7 Feb 2022, at 09:10, contactme(a)kathe.in wrote:Â On Monday, February 07, 2022 08:57 CET, Marcus Denker <marcus.denker(a)inria.fr> wrote: Â > On 7 Feb 2022, at 08:41, contactme(a)kathe.in wrote: > > Hello Marcus, > > Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is; > Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo! > := is I think even ANSI Standard, or not? There are no plans for syntactical changesâ¦ But of course: The *goal* of Pharo is not to be Smalltalk80. I have to admit I kind of misunderstood Squeak back thenâ¦ I really thought the idea if was to take ST80 as a startingoint âto invent the futureââ¦ I still like that idea, I have to sayâ¦ to me what fascinates me is how to take something that is as of a great idea as ST80 and improve itâ¦ for example just consider the resources (in terms of memory or processing power or networking) we have today vs. 1978. The âletâs through it all away and start from scratchâ approach is not great, eitherâ¦ as you need something to buld upon. And: as soon as you finish that âbetterâ system, you would have the same problem: you would be stuck with a âfinishedâ system, while the world continues to evolve. It is a real interesting research question: How an you build Systems that can evolve over a long time ? Systems which evolve over time need to have a very tiny core which is supremely malleable. For one, I would start with a "Forth" and add an object-system to it using the "Metaobject Protocol" along with a Common Lisp like "Condition System". Â Â Forth in the context of the core of an object system is interestingâ¦ someone did in 1979 a Smalltalk and Forth inspired system called âRosetta Smalltalk"Â https://dl.acm.org/doi/10.1145/1113572.1113555Â But: the nice thing of evolving a system is that you *always* can show a real, working result. You can have users, including yourselfâ¦ you can find ways of financingÂ your work that is not just promising something for the future. (which you can only do so often before people get sceptical).Â I think being part of the early Squeak community kind of burned for me the âletâs not improve that (relatively) simple thing A, instead wait for <genius X> to finish <amazing Project Z>.Â Imagine instead you would build a feedback-loop *inside* of your system...Â Â Marcus Agree about what you felt within the Squeak community, I was there too around 1999~2000. There were a bunch of geniuses there, but the way I understand it, geniuses produce the initial spark, but you need strong-willed, perseverent people to kindle the project there-after. The reason I was drawn to Pharo is because of what Ducasse and you and others like you have done with the core spark of Smalltalk-80 based Squeak running Morphic. Though, I've always liked the MVC environment more and fell in love with the "Third-Way" project to deliver a full-blown widget-set for MVC developed by a guy called Gartner (I think) from Germany. Can you elaborate on your feedback-loop *inside* the system idea? Especially in the context of Pharo? Â

Feb. 7, 2022

Re: What is "Fluid"?

by Marcus Denker

> On 7 Feb 2022, at 09:10, contactme(a)kathe.in wrote: > > > On Monday, February 07, 2022 08:57 CET, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> >> > On 7 Feb 2022, at 08:41, contactme(a)kathe.in wrote: >> > >> > Hello Marcus, >> > >> > Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is; >> > Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo! >> > >> := is I think even ANSI Standard, or not? >> >> There are no plans for syntactical changesâ¦ >> >> But of course: The *goal* of Pharo is not to be Smalltalk80. >> >> I have to admit I kind of misunderstood Squeak back thenâ¦ >> >> I really thought the idea if was to take ST80 as a startingoint âto invent the futureââ¦ >> I still like that idea, I have to sayâ¦ to me what fascinates me is how to take something >> that is as of a great idea as ST80 and improve itâ¦ for example just consider the resources (in terms >> of memory or processing power or networking) we have today vs. 1978. >> >> The âletâs through it all away and start from scratchâ approach is not great, eitherâ¦ as you need something to buld >> upon. And: as soon as you finish that âbetterâ system, you would have the same problem: you would be stuck with >> a âfinishedâ system, while the world continues to evolve. >> >> It is a real interesting research question: How an you build Systems that can evolve over a long time ? > > Systems which evolve over time need to have a very tiny core which is supremely malleable. > For one, I would start with a "Forth" and add an object-system to it using the "Metaobject Protocol" along with a Common Lisp like "Condition System". > Forth in the context of the core of an object system is interestingâ¦ someone did in 1979 a Smalltalk and Forth inspired system called âRosetta Smalltalk" https://dl.acm.org/doi/10.1145/1113572.1113555 <https://dl.acm.org/doi/10.1145/1113572.1113555> But: the nice thing of evolving a system is that you *always* can show a real, working result. You can have users, including yourselfâ¦ you can find ways of financing your work that is not just promising something for the future. (which you can only do so often before people get sceptical). I think being part of the early Squeak community kind of burned for me the âletâs not improve that (relatively) simple thing A, instead wait for <genius X> to finish <amazing Project Z>. Imagine instead you would build a feedback-loop *inside* of your system... Marcus

Feb. 7, 2022