- Pharo-users - lists.pharo.org

multi-threading with websocket
by Ben Coman Feb. 18, 2018

Feb. 18, 2018

The websockets guide here.... https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/ lastSuccessfulBuild/artifact/book-result/WebSockets/WebSockets.html says "Reading and sending are completely separate and independent" and the class comment says its "full-duplex". From these I presume sending and receiving are okay to occur in separate threads, but this is not explicitly stated, so can someone confirm this? So for the given example.... | webSocket | webSocket := ZnWebSocket to: 'ws://echo.websocket.org'. [ webSocket sendMessage: 'Pharo Smalltalk using Zinc WebSockets !'; readMessage ] ensure: [ webSocket close ]. re-implementing as follows seems to work... webSocket := ZnWebSocket to: 'ws://echo.websocket.org'. [ webSocket runWith: [ :msg | Transcript crShow: msg ] ] forkAt: 35. webSocket sendMessage: 'Pharo Smalltalk using Zinc WebSockets !'. webSocket sendMessage: 'Another multi-thread echo'. webSocket close but that could just be by luck, so I ask. btw, if I don't send the #close in the last line, after ~30 seconds I get an error ConnectionClosed: Cannot write data which seems reasonable that the other end timed out and closed the connection, but when I send the #close, after ~30 seconds I get an error... PrimitiveFailed: primitive #primSocketReceiveDataAvailable: in Socket failed which is unfriendly. What is the best way to neatly stop trying to receive data when we explicitly close the websocket? cheers -ben P.S. I wonder if when a ZnWebSocket is closed, it might be worthwhile to do "role:=#closed" to provide some visibility of its state in its GTInspector [Raw] tab..

2 1

UFFI correct way to cast void*
by Egor Scorik Feb. 17, 2018

Feb. 17, 2018

Hi, I'm trying to play with new UFFI system. It looks much easier then NativeBoost, but unfortunately its hard to find any docs or examples. I have problem with casting void* (ExternalAddress) into smalltalk object if there is no hardcoded type in ffi method. And I really dislike the idea of making many ffi methods, one for each required type. In this example i can't understand how to make something like `address castTo: type` FFIExternalObject subclass: #Iterator Iterator >> asCollectionOfType: aTypeName | result address type | result := OrderedCollection new. address := ExternalAddress new. type := FFIExternalType resolveType: aTypeName. [self iterator_next: address] whileTrue: [ result add: (address castTo: type). ]. ^result Iterator >> iterator_next: data ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

5 8

Pillar questions
by Arturo Zambrano Feb. 16, 2018

Feb. 16, 2018

Hi All, Q1 Is there a way of adding page headers/footers in pillar? header = image + short legend. footer = line + section name + page number. Q2 My plan is to use Pillar programmatically, are you aware of some projects that use Pillar in that way? Most of the documentation I found is regarding Pillar syntax. The testcases are good examples, but I would like to see something more complex if possible. Thanks! Arturo

3 14

Web scrapping with Pharo Chrome
by Offray Vladimir Luna CÃ¡rdenas Feb. 16, 2018

Feb. 16, 2018

Hi, I have been finally able to install and use properly Pharo Chrome. The issues I reported in other thread, were caused by conflicts between OSProcess and OSSubProcess on Linux. Now I'm able to launch Chrome, point it to particular addresses and get some info from there. I would like to continue the conversation related with web scraping using Pharo Chrome, which comes handy now that there is a lot of React and other technologies making the web more and more opaque for digital citizenship and data activism endeavors. So, as an starting example, I would like to scrap the Grafoscopio's own page [1]. It makes use of Material Design Light [2]. [1] http://mutabit.com/grafoscopio/index.en.html [2] http://getmdl.io/ An starting example would be fine to kickstart myself (from the ones I'm reading, there is still something I don't get). Let's say I want to get all cards in [1] , as shown in the screenshot below. I know the div class of each one, and the div class where they are located. Which could be a minimal example of a scraper, to start with? Thanks, Offray

3 6

global exception handler mechanism
by Peter UhnÃ¡k Feb. 16, 2018

Feb. 16, 2018

Hi, is there a way to install a global handler for exceptions? Right now if I want to log all exceptions, I use approach from ShoreLine and create a PreDebugAction which is activated when any "unhandled" exception occurs. That would be good enough, however the Debugger has zero knowledge of the exception that is actually occuring, as Exception>>debug passes on only the title. So if I want to get back to the original exception and maybe log it with beacon, I need to do a lot of stack and context shenanigans: MyPreDebugAction>>logException MyLogger runDuring: [ (debugger session interruptedProcess suspendedContext stack detect: [ :context | context receiver isKindOf: Exception ]) receiver emit ] Is there a better way to approach this? Thanks, Peter

6 5

First Call for Papers: 11th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2018)
by Andrei Chis Feb. 16, 2018

Feb. 16, 2018

------------------------------------------------------------------------ Call for Papers: 11th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2018) co-located with SPLASH 2018 November 5-6, 2018 Boston, Massachusetts, United States https://conf.researchr.org/track/sle-2018/papers ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 11th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2018), held in conjunction with SPLASH 2018 at Boston, Massachusetts on November 5-6, 2018. --------------------------- Scope --------------------------- 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 11th edition of the SLE conference, SLE 2018, 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 2018 solicits high-quality contributions in areas ranging from theoretical and conceptual contributions, to tools, techniques, and frameworks in the domain of software language engineering. Topics relevant to SLE cover generic aspects of software languages development rather than aspects of engineering a specific language. In particular, SLE is interested in contributions from the following areas: * 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. * Fri 29 June 2018 - Abstract Submission * Fri 6 July 2018 - Paper Submission * Fri 24 August 2018 - Author Notification * Fri 31 August 2018 - Artifact Submission * Fri 5 October 2018 - Camera Ready Deadline * Wed 10 October 2018 - Artifact Notification * Fri 12 October 2018 - Deadline for Artifact-Related Paper Updates * Sun 4 Nov 2018 - SLE Workshops * Mon 5 Nov - Tue 6 Nov 2018 - SLE Conference --------------------------- Types of Submissions --------------------------- * Research papers These should report a substantial research contribution to SLE or successful application of SLE techniques or both. Full paper submissions must not exceed 12 pages excluding bibliography. * Tool papers Because of SLEâs interest in tools, we seek papers that present software tools related to the field of SLE. Selection criteria include originality of the tool, its innovative aspects, and relevance to SLE. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must provide a tool description of 4 pages excluding bibliography, and a demonstration outline including screenshots of up to 6 pages. Tool demonstrations must have the keywords âTool Demoâ or âTool Demonstrationâ in the title. The 4-page tool description will, if the demonstration is accepted, be published in the proceedings. The 6-page demonstration outline will be used by the program committee only for evaluating the submission. * New ideas / vision papers New ideas papers should describe new, non-conventional SLE research approaches that depart from standard practice. They are intended to describe well-defined research ideas that are at an early stage of investigation. Vision papers are intended to present new unifying theories about existing SLE research that can lead to the development of new technologies or approaches. New ideas / vision papers must not exceed 4 pages excluding bibliography. 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 2018 Website: https://conf.researchr.org/track/splash-2018/splash-2018-Workshops. --------------------------- Artifact Evaluation --------------------------- For the third 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. More information will be announced on the Website. --------------------------- 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,screen]{acmart}. Do not make any changes to this format! Using the Word template is strongly discouraged. 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. SLE follows a single-blind review process. Thus, you do not have to blind your submission. 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://sle18.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. --------------------------- Program Committee --------------------------- Andrew Black, Portland State University, USA Erwan Bousse, TU Wien, Austria Marco Brambilla, Politecnico di Milano, Italy Ruth Breu, University of Innsbruck, Austria Walter Cazzola, University of Milan, Italy Marsha Chechik, University of Toronto, Canada Tony Clark, Sheffield Hallam University, UK Juan de Lara, Universidad Autonoma de Madrid, Spain Thomas Degueule, CWI Amsterdam, Netherlands Juergen Dingel, Queen's University, Canada Tom Dinkelaker, Ericsson, Germany Sebastian Erdweg, Delft University of Technology, Netherlands Bernd Fischer, Stellenbosch University, South Africa Esther Guerra, Autonomous University of Madrid, Spain Daco Harkes, Delft University of Technology, Netherlands Robert Hirschfeld, University of Potsdam, Germany Michael Homer, Victoria University of Wellington, New Zealand Dimitris Kolovos, University of York, UK Ralf LÃ¤mmel, University of Koblenz-Landau, Germany Marjan Mernik, University of Maribor, Slovenia Gunter Mussbacher, McGill University, Canada James Noble, Victoria University of Wellington, New Zealand Bruno Oliveira, University of Hong Kong, China Christoph Reichenbach, Lund University, Sweden Jan Oliver Ringert, University of Leicester, UK Bernhard Rumpe, RWTH Aachen University, Germany Anthony Sloane, Macquarie University, Australia Emma SÃ¶derberg, Google, Denmark Mark van den Brand, TU Eindhoven, Netherlands Tijs van der Storm, CWI Amsterdam, Netherlands Eelco Visser, Delft University of Technology, Netherlands Eric Walkingshaw, Oregon State University, USA Andreas Wortmann, RWTH Aachen University, Germany Vadim Zaytsev, Rain Code, Belgium --------------------------- Contact --------------------------- For additional information, clarification, or answers to questions, please contact the organizers by email: sle2018(a)googlegroups.com.

1 0

Call for Posters: <Programming> 2018
by Sylvia Grewe Feb. 15, 2018

Feb. 15, 2018

----------------------------------------------------------------------------------- <Programming> 2018 : The Art, Science, and Engineering of Programming Mon 9 - Thu 12 April 2018 Nice, France http://2018.programming-conference.org/ ******************************************************** CALL FOR POSTERS ******************************************************** Important dates: - Poster abstract submission: Sunday, March 4th - Notification: Friday, March 9th - Poster Presentation: Tuesday, April 10th Posters are an integral part of <Programming>. We are soliciting quality contributions for the regular Poster Session of <Programming> (submissions due March 4th). The Poster Session aims at showcasing very recent or ongoing work, clarifying problem statements, vetting solutions, or identifying evaluation methods in an interactive way. It will offer an excellent opportunity for authors to receive feedback from the <Programming> community and encourage one-to-one and small group discussions on a technical topic. Students are especially encouraged to submit their ongoing work and to introduce it to peer researchers. Accepted poster abstracts will beÂ made available on the conference Web site. The <Programming> Posters track will take place on Tuesday, April 10th and will be organized jointly with the ACM Student Research Competition Poster track, thus fostering interactions between all presenters and attendees. Poster author(s) are required to attend the scheduled poster session, so that they can discuss their work with conference attendees. Poster Submission Guidelines: Posters will be evaluated based on their contribution and relevance to <Programming>. Poster submissions should be sent to<Yves.Roudier(a)i3s.unice.fr>as a 1-2 page extended abstract in PDF format. This document should contain: Â - the poster title; Â - names and affiliations of the authors (one of whom should be named as a contact person); Â - motivation and the addressed problem, proposed solution, and/or novel contributions of the proposal. ----------------------------------------------------------------------------------

1 0

Techtalk Today: Link
by Marcus Denker Feb. 15, 2018

Feb. 15, 2018

Hi, TechTalk today at 17:00 Local European time (in 45 minutes) https://association.pharo.org/event-2797065 <https://association.pharo.org/event-2797065> https://www.youtube.com/c/MarcusDenker/live <https://www.youtube.com/c/MarcusDenker/live> Marcus

1 0

Object configuration idioms
by Peter UhnÃ¡k Feb. 14, 2018

Feb. 14, 2018

Hi, are there any best practices/idioms in regards to object configuration/building? Let's say I want to configure a TwitterClient that requires a username and a password that is stored in a separate object TwitterConfiguration a) the basic approach (either separate sends or via cascade, that is not relevant here) client := TwitterClient new. client configuration username: 'XX'. client configuration password: 'YY'. b) #in: ... It feels a bit more organized as it basically groups related operations together. Also maybe avoiding demeter a bit? client := TwitterClient new. client configuration in: [ :config | config username: 'XX'. config password: 'YY'. ]. c) custom #somethingDo: method that basically does #in: Again, feels more organized. Additionally one could perform some validation afterwards (to make sure the credentials are ok or whatever). client := TwitterClient new. client configurationDo: [ :config | config username: 'XX'. config password: 'YY' ]. Any thoughts on this? Thanks, Peter

9 11

[ANN] Pharo Consortium New Platinum Member: ENSTA Bretagne
by Marcus Denker Feb. 13, 2018

Feb. 13, 2018

The Pharo Consortium is very happy to announce that ENSTA Bretagne has joined the Consortium as a Platinum Member. About - ENSTA Bretagne: http://www.ensta-bretagne.fr - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

1 0