June 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [UFFI] Call a function where argument type is char ** (argv)

by Julien Delplanque

Hello, I asked a simililar question some days ago, maybe this [1] can help. Regards, Julien Links: [1]: http://forum.world.st/Unified-FFI-pointer-of-String-as-function-parameter-t… On 31/05/16 16:28, Blondeau Vincent wrote: > TL;DR: How to pass as argument an array of Strings (char **) with Unified-FFI? > > Vincent > > De : Blondeau Vincent > EnvoyÃ© : mercredi 25 mai 2016 13:58 > Ã : Pharo Development List > Objet : [UFFI] Call a function where argument type is char ** (argv) > > Hello, > > I have written a R bridge in Pharo and I would like to migrate it from NativeBoost to UFFI. > Most of the changes are easy to do but I am stuck to a double pointer problem. > I have to call the function: int Rf_initEmbeddedR(int argc, char ** argv). I know how to give the int but the char ** is a problem. It is an array of Strings. > > With NB, I managed to have this (working) code: > "This is 32bit... too bad..." > strings := OrderedCollection new. > par := NativeBoost allocate: 4 * params size. > params > keysAndValuesDo: [ :i :each | > | str | > str := each asNBExternalString. > strings add: str. > par nbUInt32AtOffset: (i - 1) * 4 put: str value ]. > self prim_initEmbeddedRargc: params size argv: par ] > ensure: [ > "Free the memory we allocated" > par ifNotNil: [ par free ]. > strings ifNotNil: [ strings do: [ :each | each free ] ] ] > > With a primitive call: > Self nbCall: #(int Rf_initEmbeddedR(int argc, char *argv)) > > Do I still need to create my own array of strings or FFI creates it for me? How? > > Thanks in advance for your answers, > > Vincent > > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" >

June 1, 2016

2nd CfP: SLE 2016 (9th ACM SIGPLAN International Conference on Software Language Engineering)

by Andrei Chis

**Call for Papers** ======================================================================== 9th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2016) Oct 31-Nov 1, 2016, Amsterdam, Netherlands (Co-located with SPLASH 2016) General chair: Tijs van der Storm, CWI, Netherlands Program co-chairs: DÃ¡niel Varro, Budapest University of Technology and Economics, Hungary Emilie Balland, Sensational AG, Switzerland http://conf.researchr.org/track/sle-2016/sle-2016-papers http://www.sleconf.org/2016/ Follow us on twitter: https://twitter.com/sleconf ======================================================================== Software Language Engineering (SLE) is the application of systematic, disciplined, and measurable approaches to the development, use, deployment, and maintenance of software languages. The term "software language" is used broadly, and includes: general-purpose programming languages; domain-specific languages (e.g. BPMN, Simulink, Modelica); modeling and metamodeling languages (e.g. SysML and UML); data models and ontologies (e.g. XML-based and OWL-based languages and vocabularies). ### Important Dates Fri 17 Jun 2016 - Abstract Submission Fri 24 Jun 2016 - Paper Submission Fri 26 Aug 2016 - Notification Fri 2 Sep 2016 - Artifact submission Fri 16 Sep 2016 - Artifact notification Fri 16 Sep 2016 - Camera ready deadline Mon 31 Oct 09:00 - Tue 1 Nov 18:00 2016 Conference ### Topics of Interest SLE aims to be broad-minded and inclusive about relevance and scope. We solicit high-quality contributions in areas ranging from theoretical and conceptual contributions to tools, techniques, and frameworks in the domain of 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 principled engineering approaches and techniques in the following areas: * Language Design and Implementation * Approaches and methodologies for language design * Static semantics (e.g., design rules, well-formedness constraints) * Techniques for behavioral / executable semantics * Generative approaches (incl. code synthesis, compilation) * Meta-languages, meta-tools, language workbenches * Language Validation * Verification and formal methods for languages * Testing techniques for languages * Simulation techniques for languages * Language Integration * Coordination between of heterogeneous languages and tools * Mappings between languages (incl. transformation languages) * Traceability between languages * Deployment of languages to different platforms * 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 ### 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 (in ACM SIGPLAN conference style (http://www.sigplan.org/Resources/Author/)) * **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 in SIGPLAN proceedings style (see above), with 1 optional additional page for bibliographic references, and a demonstration outline including screenshots of up to 4 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 4-page demonstration outline will be used by the program committee only for evaluating the submission. ### Artifact evaluation Authors of accepted papers at SLE 2016 are encouraged to submit their experiment results used for underpinning research statements to an artifact evaluation process carried out in early September 2016. This submission is voluntary and will not influence the final decision regarding the papers. Papers that go through the Artifact Evaluation process successfully receive a seal of approval printed on the first page of the paper in the proceedings. Authors of papers with accepted artifacts are encouraged to make these materials publicly available upon publication of the proceedings, by including them as "source materials" in the ACM Digital Library. ### Publications All submitted papers will be reviewed by at least three members of the program committee. All accepted papers, including tool papers will be published in ACM Digital Library. Authors of distinguished papers from the conference will be invited to revise and submit extended versions of their papers for a Journal special issue. ### Awards * Distinguished paper. Award for most notable paper, as determined by the PC chairs based on the recommendations of the program committee. * Distinguished reviewer. Award for distinguished reviewer, as determined by the PC chairs using feedback from the authors. ### Program Committee Emilie Balland (co-chair), Sensational AG (SUI) Daniel Varro (co-chair), BME (HUN) Anya Helene Bagge, Univ. Bergen (NOR) Ruth Breu, Univ. Innsbruck (AUT) Jordi Cabot, Univ. Oberta de Catalunya (ESP) Marsha Chechik, Univ. Toronto (CAN) Marcus Denker, INRIA (FRA) Davide Di Ruscio, Univ. LâAquila (ITA) Martin Erwig, Oregon State Univ. (USA) Bernd Fischer, Stellenbosch University (RSA) Sebastian Gerard, CEA (FRA) Jeremy Gibbons, Oxford Univ. (UK) Holger Giese, Hasso Plattner Inst. (GER) Martin Gogolla, Univ. Bremen (GER) Jeff Gray, Univ. Alabama (USA) Esther Guerra, Autonomous Univ. of Madrid (ESP) Gorel Hedin, Lund Univ. (SWE) Michael Homer, Victoria Univ. Wellington (NZL) Dimitris Kolovos, Univ. York (UK) Ralf LÃ¤mmel, Univ. Koblenz (GER) Julia Lawall, LIP6 (FRA) Tihamer Levendovszky, Microsoft (USA) Heather Miller, EPFL (SUI) Pierre-Etienne Moreau, Loria (FRA) GÃ¼nter Mussbacher, McGill Univ. (CAN) Bruno Oliveira, Univ. of Hong Kong (HKG) Terence Parr, Univ. San Francisco (USA) IstvÃ¡n RÃ¡th, IncQuery Labs (HUN) Julia Rubin, MIT (USA) Bernhard Schatz, Fortiss (GER) Sibylle Schupp, Univ. Hamburg (GER) Anthony Sloane, Macquarie Univ. (AUS) Emma SÃ¶derberg, Google (USA) Eugene Syriani, Univ. MontrÃ©al (CAN) Gabi Taentzer, Univ. Marburg (GER) Eric Van Wyk, Univ. Minnesota (USA) Hans Vangheluwe, Univ. Antwerp (BEL) Jurgen Vinju, CWI (NED) Guido Wachsmuth, TU Delft (NED) Eric Walkingshaw, Oregon State Univ. (USA) Andrzej WÄsowski, ITU (DEN) Manuel Wimmer, TU Wien (AUT) Tian Zhang, Nanjing Univ. (CHN)

June 1, 2016

Re: [Pharo-users] Changes file without

by Valentin Ryckewaert

Hello, Here is a script to make the exception happend Go where you want the folder to be created and copy paste this: mkdir testPharo cd testPharo mkdir files cd files echo Transcript show:'test' >test.st cd .. mkdir curl cd curl curl get.pharo.org/50+vm | bash cd .. sudo chmod -R -w curl curl/pharo-ui curl/Pharo.image -st ../files/test.st Execute this to clean what the script did : cd .. sudo rm -r testPharo Valentin

June 1, 2016

Language Workbench Challenge 2016: Call for Solutions

by Tijs van der Storm

############################################################# Language Workbench Challenge 2016 @ SLE: Call for Solutions Collocated with SPLASH'16 in Amsterdam, The Netherlands Deadline: Mon 1 Aug 2016 Notification: Mon 5 Sep 2016 Workshop: Tue 1 Nov 2016 http://2016.splashcon.org/track/lwc2016 ############################################################# Language workbenches are tools that lower the development costs of implementing new languages and their associated tools (IDEs, debuggers etc.). As well as easing the development of traditional stand-alone languages, language workbenches also make multi-paradigm and language-oriented programming environments practical. The Language Workbench Challenge (LWC) aims to bring together language workbench users and implementers, to discuss the state-of-the-art in language workbenches and explore future directions. LWCâ16 solicits solutions to 3 benchmark problems proposed in Section 6.5 of the following paper: Sebastian Erdweg, Tijs van der Storm, Markus VÃ¶lter, Laurence Tratt, et al. **Evaluating and comparing language workbenches: Existing results and benchmarks for the future**, Computer Languages, Systems & Structures, Volume 44, Part A, December 2015, Pages 24â47. DOI: http://dx.doi.org/10.1016/j.cl.2015.08.007 Preprint: http://homepages.cwi.nl/~storm/publications/lwc13-comlan.pdf The benchmark problems are categorized in the following categories: - Notation: challenges dealing with the appearance of source code, including support for tabular notation, mathematical symbols, code in prose etc. - Evolution and reuse: challenges related to modularity, composition, language versions and migration. - Editing: challenges exercising how the language user interacts with code. The goal of the workshop is to demonstrate, discuss and foster improvements in tools, as well as encourage the collaboration between and learning among different teams developing different (kinds of) editors. To this end, we emphasize the implementation of the challenges, not writing about them. Submissions should be short documents (in PDF format) describing each solution using the following structure: - Assumptions: Are there any assumptions or prerequisites relevant to the implementation of the solution? - Implementation: What are the important building blocks for defining the solution? What does it take to implement the solution to the problem? - Variants: Are there any interesting and insightful variants of the implementation? What small change(s) to the challenge would make a big difference in the implementation strategy or effort? - Usability: What is the resulting user experience? Is it convenient to use? Is it similar to other kinds of notations? Does it feel âforeignâ to experienced users of the particular editor? - Impact: Which artifacts have to be changed to make the solution work? Are changes required to (conceptually) unrelated artifacts? How modular is the solution? - Composability: To what degree does the solution support composition with solutions to other benchmark problems other instances of the same problem (e.g., same challenge problem, different language feature)? - Limitations: What are the limitations of this implementation? - Uses and Examples: Are there examples of this problem in real-world systems? Where can the reader learn more? - Effort (best-effort): How much effort has been spent to build the solution, assuming an experienced user of the technology? - Other Comments: Anything that does not fit within the other categories. - Artifact: a publicly accessible URL to the source code of the submission. The paper cited above includes two example descriptions for inspiration, Submissions should furthermore use the ACM SIGPLAN Conference Format, 10 point font, using the font family Times New Roman and numeric citation style. The PC will review the submissions for inclusion in the workshop program, based on criteria of providing interest for discussion, conformance to the challenges, and whether the submission is on-topic (e.g., is using a language workbench). The PDFs of accepted submissions will be published on this website before the workshop. Organization - Meinte Boersma (Mendix) - Eugen Schindler (Oce) - Tijs van der Storm (CWI) - Markus Voelter (itemis AG) Program Committee - Lorenzo Bettini (DISIA) - Sebastian Erdweg (TU Delft) - Pablo Inostroza (CWI) - TamÃ¡s SzabÃ³ (itemis AG / TU Darmstadt)

June 1, 2016