May 2021 - Pharo-users - lists.pharo.org

P3 connection error
by Bernhard Pieber May 18, 2021

May 18, 2021

Hi, I have a PostgreSQL database on a remote host which I want to access using P3. I do have a username and a password and can connect via SQuirreL and DBeaver. Both use a JDBC driver. However, when I try to access it via Pharo and P3 I get the infamous "no pg_hba.conf entry for host <my IP address>â error. The thing is that I cannot change the pg_hba.conf file as the server does not belong to me. I wonder why the JDBC driver does not run into this problem when connecting from my IP address? It must do something differently. As I have just started playing with P3 (and PostgreSQL to be honest) I may be missing something fundamental. Using #setSSL did not help, by the way. Any other ideas I could try? Cheers, Bernhard

2 1

ODBCDriver adapted to uFFI
by TomaÅ¾ Turk May 14, 2021

May 14, 2021

Dear all, I solved a couple of issues in https://github.com/apiorno/ODBCDriver. Until Alvaro finds the time to check the proposed PR, you can play with my clone: https://github.com/eftomi/ODBCDriver. A simple example of connecting to the data source is in ODBC-Tests. It connects and returns data on Pharo 8.0 32 and 64 on Win10 64 bit with remote SQL Server. More extensive tests are to be done. Best wishes, Tomaz

3 3

NeoCSVReader and wrong number of fieldAccessors
by jtuchel＠objektfabrik.de May 13, 2021

May 13, 2021

Happy new year to all of you! May 2021 be an increasingly less crazy year than 2020... I have a question that sounds a bit strange, but we have two effects with NeoCSVReader related to wrong definitions of the reader. One effect is that reading a Stream #upToEnd leads to an endless loop, the other is that the Reader produces twice as many objects as there are lines in the file that is being read. In both scenarios, the reason is that the CSV Reader has a wrong number of column definitions. Of course that is my fault: why do I feed a "malformed" CSV file to poor NeoCSVReader? Let me explain: we have a few import interfaces which end users can define using a more or less nice assistant in our Application. The CSV files they upload to our App come from third parties like payment providers, banks and other sources. These change their file structures whenever they feel like it and never tell anybody. So a CSV import that may have been working for years may one day tear a whole web server image down because of a wrong number of fieldAccessors. This is bad on many levels. You can easily try the doubling effect at home: define a working CSV Reader and comment out one of the addField: commands before you use the NeoCSVReader to parse a CSV file. Say your CSV file has 3 lines with 4 columns each. If you remove one of the fieldAccessors, an #upToEnd will yoield an Array of 6 objects rather than 3. I haven't found the reason for the cases where this leads to an endless loop, but at least this one is clear... I *guess* this is due to the way #readEndOfLine is implemented. It seems to not peek forward to the end of the line. I have the gut feeling #peekChar should peek instead of reading the #next character form the input Stream, but #peekChar has too many senders to just go ahead and mess with it ;-) So I wonder if there are any tried approaches to this problem. One thing I might do is not use #upToEnd, but read each line using PositionableStream>>#nextLine and first check each line if the number of separators matches the number of fieldAccessors minus 1 (and go through the hoops of handling separators in quoted fields and such...). Only if that test succeeds, I would then hand a Stream with the whole line to the reader and do a #next. This will, however, mean a lot of extra cycles for large files. Of course I could do this only for some lines, maybe just the first one. Whatever. But somehow I have the feeling I should get an exception telling me the line is not compatible to the Reader's definition or such. Or #readAtEndOrEndOfLine should just walk the line to the end and ignore the rest of the line, returnong an incomplete object.... Maybe I am just missing the right setting or switch? What best practices did you guys come up with for such problems? Thanks in advance, Joachim

7 24

Looking for more non-trivial example application based on Spec2 to learn from...
by mark.odonoghue.2010＠gmail.com May 13, 2021

May 13, 2021

Iâm trying to return to Smalltalk after a 15+ year break (VisualAge, ENfin/2 ST-80 etc), and have been trying to get back into the saddle with Pharo 8 and Pharo 9. Since I have no legacy code - Iâve opted for Pharo 9 knowing a stable release isnât far away. My goal is to produce several applications for private use, and regain some competence in Smalltalk along the way. The apps are business accounting/investing style apps - not too technical. Iâm really not keen on the prospect of using any of the other âmainstreamâ alternatives we have today. Iâm confident I can build a domain model easily enough, but the Pharo environment is my stumbling point - especially building the GUI with Spec2. Iâm really spinning my wheels trying to get a useful Spec2 application built. It needs to have menus, a toolbar, tabbed notebooks, tree lists etc - plus a dozen or so tabular panes (to view/maintain my domain model). Ideally it would also be able to use ODBC or UDBC or Excel etc for transaction storage. Iâve been through all the building blocks in SpDemo but there a just too many concepts to familiarise with and test bit by bit as I buildup a more realistic functioning application. It has been very frustraing and time consuming. I understand why there are not yet solid guides available (book, tutorial, examples) , so I thought the best way would be to use an existing Spec2 application to help me get it going. I think this would save me many weeks of effort. Could anyone point me to at a working non-trivial application that I could share and use a starting point. Any suggestions to help me get into the heart of my application would be most welcomeâ¦!

9 22

CFP: SLE 2021 - 14th ACM SIGPLAN International Conference on Software Language Engineering
by Andrei Chis May 13, 2021

May 13, 2021

------------------------------------------------------------------------ 14th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2021) October 17-19, 2021 Chicago, Illinois https://conf.researchr.org/home/sle-2021 http://www.sleconf.org/2021 Follow us on twitter: https://twitter.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 14th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2021), held in conjunction with SPLASH, GPCE and SAS 2021. Based on the future developments the conference will be hosted in Chicago, Illinois, United States on October 17-19, 2021 or will be held as a virtual event. --------------------------- Scope --------------------------- The ACM SIGPLAN International Conference on Software Language Engineering (SLE) is devoted to the principles of software languages: their design, their implementation, and their evolution. With the ubiquity of computers, software has become the dominating intellectual asset of our time. In turn, this software depends on software languages, namely the languages it is written in, the languages used to describe its environment, and the languages driving its development process. Given that everything depends on software and that software depends on software languages, it seems fair to say that for many years to come, everything will depend on software languages. Software language engineering (SLE) is the discipline of engineering languages and their tools required for the creation of software. It abstracts from the differences between programming languages, modelling languages, and other software languages, and emphasizes the engineering facet of the creation of such languages, that is, the establishment of the scientific methods and practices that enable the best results. While SLE is certainly driven by its metacircular character (software languages are engineered using software languages), SLE is not self-satisfying: its scope extends to the engineering of languages for all and everything. Like its predecessors, the 14th edition of the SLE conference, SLE 2021, will bring together researchers from different areas united by their common interest in the creation, capture, and tooling of software languages. It overlaps with traditional conferences on the design and implementation of programming languages, model-driven engineering, and compiler construction, and emphasizes the fusion of their communities. To foster the latter, SLE traditionally fills a two-day program with a single track, with the only temporal overlap occurring between co-located events. --------------------------- Topics of Interest --------------------------- SLE 2021 solicits high-quality contributions in areas ranging from theoretical and conceptual contributions, to tools, techniques, and frameworks in the domain of software language engineering. Broadly speaking, 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 * 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 --------------------------- Important Dates --------------------------- All dates are Anywhere on Earth. * Mon 5 Jul 2021 - Abstract Submissions * Fri 9 Jul 2021 - Paper Submissions * Wed 1 Sep 2021 - Review Notification * Wed-Fri 1-3 Sep 2021 - Author Response Period * Mon 13 Sep 2021 - Notification * Wed 15 Sept 2021 - Artifact Submissions * Tue 28 Sep 2021 - Artifact Kick-the-tires Author Response * Tue 12 Oct 2021 - Artifact Notification * Sun-Tue 17-19 Oct 2021 - SLE Conference --------------------------- Types of Submissions --------------------------- SLE 2021 solicits three types of papers: * Research papers These are "traditional" papers detailing research contributions to SLE. These papers have a limit of 12 pages, and may optionally include 8 further pages of 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. The title of a Tool paper must start with "Tool Demo:". *New ideas / vision papers These are papers on forward-looking, innovative research in software language engineering. Our aim here is to accelerate the exposure of the software language engineering community to early yet potentially ground-breaking research results, or to techniques and perspectives that challenge the status quo in the discipline. New ideas / vision papers must not exceed 5 pages, and may optionally include 1 further page of bibliography / appendices. The title of a new ideas / vision papers must start with "New Ideas:" or "Vision:". --------------------------- Artifact Evaluation --------------------------- For the sixth 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 papers are invited to submit artifacts. For more information, please have a look at the Artifact Evaluation page (http://www.sleconf.org/2021/ArtifactEvaluation.html) --------------------------- Submission --------------------------- 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/consolidated-tex-t…) 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. 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. Submission Site: Submissions will be accepted at https://sle21.hotcrp.com/ --------------------------- 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. 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. --------------------------- Awards --------------------------- * Distinguished paper: Award for most notable paper, as determined by the PC chairs based on the recommendations of the programme committee. * Distinguished reviewer: Award for distinguished reviewer, as determined by the PC chairs. * 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. --------------------------- Organisation --------------------------- Chairs: * General chair: Eelco Visser, Delft University of Technology, Netherlands * Program co-chair: Dimitris Kolovos, University of York, United Kingdom * Program co-chair: Emma SÃ¶derberg, Lund University, Sweden * Artefact Evaluation co-chair: Elias Castegren, KTH, Sweden * Artefact Evaluation co-chair: Andreas Wortmann, RWTH Aachen University, Germany Program Committee: Vincent Aranega, University of Lille, France Mikhail Barash, University of Bergen, Norway Melanie Bats, Obeo, France David Broman, KTH, Sweden Shigeru Chiba, University of Tokyo, Japan Alfonso de la Vega, University of York, United Kingdom Juan De Lara, Universidad AutÃ³noma de Madrid, Spain Davide Di Ruscio, University of L'Aquila, Italy Marcos Didonet del Fabro, Universidade Federal do ParanÃ¡, Brazil Juergen Dingel, Queen's University, Canada Michalis Famelis, University of Montreal, Canada Bernd Fischer, Stellenbosch University, South Africa Niklas Fors, Lund University, Sweden Antonio Garcia Dominguez, Aston University, United Kingdom Esther Guerra, Universidad AutÃ³noma de Madrid, Spain GÃ¶rel Hedin, Lund University, Sweden Stuart Hutchesson, Independent, United Kingdom Adrian Johnstone, Royal Holloway, United Kingdom Paddy Krishnan, Oracle Labs, Australia James Noble, Victoria University of Wellington, New Zealand Carlos Olarte, ECT UFRN, Brazil JoÃ£o Saraiva, HASLab / INESC TEC and Universidade do Minho, Portugal Anthony Sloane, Macquarie University, Australia Daniel StrÃ¼ber, Radboud University , Netherlands Ulyana Tikhonova, CWI, Netherlands Mark van der Brand, TU Eindhoven, Netherlands Juan Manuel Vara, Universidad Rey Juan Carlos, Spain Ran Wei, Dalian University of Technology, China Bahman Zamani, University of Isfahan, Iran --------------------------- Contact --------------------------- For additional information, clarification, or answers to questions, please contact the Program Chairs (Emma SÃ¶derberg and Dimitris Kolovos).

1 0

uFFI ffiCall return value
by TomaÅ¾ Turk May 10, 2021

May 10, 2021

Dear all, Should the method that calls Object>>#ffiCall: and variants always return the result of this call? For instance, in uFFI book, there is a method abs: defined as FFITutorial class >> abs: n [ ^ self ffiCall: #( int abs (int n) ) ] on page 16, however FFITutorial >> abs: n [ self ffiCall: #( int abs (int n) ) ] on page 52 doesn't have an explicit return ^. The book, however, in most of the examples uses the explicit return. What is the recommended approach? Thanks, Tomaz

2 2

[ANN] Camp Smalltalk Supreme
by Richard Kenneth Eng May 9, 2021

May 9, 2021

I have the green light to proceed with *Camp Smalltalk Supreme*, the 2022 50th anniversary edition of Camp Smalltalk. It's scheduled for June 10-12, 2022 at Ryerson University in Toronto, Canada. I've confirmed Adele Goldberg and FAST President Leandro Caniglia as keynote speakers for this very special event. Here is the official website: https://campsmalltalksupreme.wordpress.com/. Here is the promo video: https://youtu.be/ygsqpuSnR-4. Here is the GoFundMe campaign: https://gofund.me/225341e3. I'm also seeking corporate sponsorship. I hope many people will attend this event. It should be a blast. Richard

1 0

May 6, 2021

> Begin forwarded message: > > From: Johan Brichau <johan(a)inceptive.be> > Subject: [Esug-list] We are hiring a new software engineer (full time vacancy) > Date: 6 May 2021 at 19:42:00 CEST > To: list ESUG Mailing <esug-list(a)lists.esug.org> > > ï»¿ > Hi fellow Smalltalkers, > > Do you like working with Smalltalk (Pharo, GemStone/S, Seaside, â¦) and you are also not afraid of spending time in other technologies like JavaScript (ReactJs), Java and devops aspects of running Smalltalk environments in production? > Then read on... > > At Yesplan (www.yesplan.be <http://www.yesplan.be/>), we are looking for a motivated and inspiring new colleague to join our ambitious software engineering team. > > Yesplan is an intuitive venue management web application. We are the leading software system for small and large theaters, concert halls and event venues in the Benelux and currently expanding in Europe and beyond. We strive for our users to enjoy using Yesplan, through intuitive and attractive design. Yesplan is continuously evolving software; we integrate with key apps and have an open API. > > As a software engineer at Yesplan, you work with the entire team on our entire technology stack: from the database and the backend to the front-end and integrations with other products. In addition to the technical implementation, you also participate in the analysis and design of product extensions and improvements. You also contribute to all devops processes, technical support and operational standby. > > We strive to deliver high quality through agile software development. If you've already done pair programming, code reviews, and daily stand-ups, and are committed to a devops culture with shared responsibilities, you'll probably fit right in. > We're looking for a team player who isn't afraid to express their opinion. It's through the continuous exchange of ideas and the occasional constructive discussion that we reach the best decisions for our product, our customers, and our team. > > Check out the full vacancy attached or at https://yesplan.be/en/vacancy/full-stack-software-engineer <https://yesplan.be/en/vacancy/full-stack-software-engineer> > > > Interested or just have same questions? > Send me an email at johan(a)yesplan.be <mailto:johan@yesplan.be> > > > Best regards > Johan > > > > _______________________________________________ > Esug-list mailing list -- esug-list(a)lists.esug.org > To unsubscribe send an email to esug-list-leave(a)lists.esug.org -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

1 0

Class hierarchy diagram
by Sanjay Minni May 6, 2021

May 6, 2021

Is there any way to display the Class Hierarchy as a Diagram or a indented list. Even for all the classes in a package will do. ----- cheers, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

5 8

[fus] Early march sync
by hogoww May 5, 2021

May 5, 2021

Hello, In today's sync we talked about the idea, progress, paper planing. Idea: Basically the same as the previous mail so I'll not detail it here. The Slides are trying to give some details & a global view. They are, however not well ordered, and an inlining problem is missing. I'll update them quickly this afternoon, and send them back, hopefully this will help. Progress: I've done the poc to extract & graft a method. (details in slides/mail) Paper planning. 2 papers planned (possibly 3 If I were to dream a bit) First paper for GPCE on Transpiling & mutating tests. I'm putting a very short description to see that we all agree and that I'm not mistaken. The point is to test *Slang*. We are translating the tests and looking for asynchronicity for the test execution between the simulation & binary. This allows that the Slang compiler preserve the semantics. 2nd Paper on incremental compiler development see Slides & previous mail. A possible title would be: "Test driven incremental development of a compiler using a software" 3d Test prioritization Possible heuristic on test prioritization One is hinted in the last slide. Noury offered another one which is to focus on getting fast green tests. However this would require a new state of the art for a different domain. Next up: - Work on paper - Finding some mutations to apply on tests and classify them - Try to get some numbers on results ! Pierre

1 1