- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Moose-dev] Re: the impact of moldability
by Tudor Girba June 4, 2016

June 4, 2016

Hi, > On Jun 4, 2016, at 7:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > > Nice read and some interesting statistics. Thanks > It makes sense when laid > out like that, but its a question of internalising the knowledge to > make use of moldability more often. Indeed. This is a challenge. In this regard, picking specific scenarios and asking questions about how to deal with them could help us build tutorials. > > One small edit... > We are the beginning > ==> We are at the beginning Fixed. Doru > > cheers -ben > > On Sun, Jun 5, 2016 at 12:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> There were a couple of emails in the recent period that questioned the usefulness of moldability (the ability of developers to customize their tools deeply and inexpensively). More specifically, the question was about the moldability of the GTDebugger. >> >> I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: >> http://www.humane-assessment.com/blog/the-impact-of-moldability/ >> >> Please read it and provide feedback. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

1 0

Re: [Pharo-users] [UFFI] Call a function where argument type is char ** (argv)
by Blondeau Vincent June 4, 2016

June 4, 2016

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.!!!"

3 4

SandstoneDB for Pharo maintainer?
by Udo Schneider June 3, 2016

June 3, 2016

All, I noticed that the most recent SandstoneDB fails most tests when using a disk based store. I have fixed the issue so that all tests are green again. I'm not sure how to proceed now though. I noticed that the StHub repository is public write. But I'm not sure if it's okay to simply push the changes/config. So who's the current maintainer or is there any other process? Thanks, Udo

3 3

Some annotations on the Pharo MOOC
by Offray Vladimir Luna CÃ¡rdenas June 2, 2016

June 2, 2016

Hi all, After a short and energizing internship at Chile with the Object Profile people, I'm back in Colombia with more time to start my Pharo MOOC. I'm making annotations on it as I advance to the sessions (BTW I tried using hypothesis for annotations but it didn't work[2]). Here is the first one[1]: [1] https://offray.withknown.com/2016/indirect-halo-menu-from-the-pharo-web-ima… [2] http://hypothes.is/ Cheers, Offray

2 2

What should I name my nested packages?
by Evan Donahue June 2, 2016

June 2, 2016

Hello, Just a quick question as I work on refactoring and cleaning up a project I've been working on. I notice that packages like Fuel appear in nice, nested hierarchies in my code browser, with 'Core' nested under 'Fuel' even though 'Core's package name is actually Fuel-Core. I'm wondering what I have to do to get my own packages to nest similarly in the code browser beyond just naming them accordingly. Thank you, Evan

3 3

Pharo job offer @ Lille
by stepharo June 2, 2016

June 2, 2016

Begin forwarded message: From: Usman Bhatti <usman.bhatti(a)gmail.com> Subject: [Esug-list] Pharo Job in Lille Date: 2 Jun 2016 11:51:18 BST To: esug-list(a)lists.esug.org Hi all, Synectique provides comprehensive and sophisticated analysis tools to improve the quality of software, reduce maintenance costs, and thus enable easier software evolution. The company was created in 2013 and already got some renowned customers. To sustain our growth we are looking for a full-time Smalltalk (Pharo) developer with some additional non Smalltalk skills. 2+ years experience or equivalent talent, with strong emphasis on front-end JavaScript and back-end Seaside/Pharo. The ideal candidate should be comfortable with client-side web technologies: HTML, CSS, and JavaScript, be familiar with code parsing and master different languages (Java, C++, C#, ADA, Smalltalk). The job is based in Lille, which is centrally located with good connections by train to everywhere (one hour from Paris, 1h20 from London, 35 min from Brussels). Duration: Permanent Starting date: September 2016 Salary: depending on skill set/experience Ready to travel if needed. Additional Skills: Object-oriented design/programming Agile Methodologies Fluent in French and/or English Please send your applications to philippe.valenza(a)synectique.eu. best regards. Usman Bhatti _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

1 0

Re: [Pharo-users] QCMagritte & Voyage
by Stephan Eggermont June 2, 2016

June 2, 2016

We mostly deployed QCMagritte on Gemstone, so have not done much work on persistency hooks. Please feel free to insert them at appropriate places. Stephan Verstuurd vanaf mijn iPhone

2 1

2nd CfP: SLE 2016 (9th ACM SIGPLAN International Conference on Software Language Engineering)
by Andrei Chis June 1, 2016

June 1, 2016

**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)

1 0

Changes file without
by Valentin Ryckewaert June 1, 2016

June 1, 2016

Hello everyone, I'm trying to execute a script from a .st file on a image whose changes file isn't writable. When i do this, I'm getting a bug with primSize... It looks like get size of the file need write access ? The exception : Primitive failed: primitive #primsize: in MultiByteFileStream Does someone have an idea of the reason of this problem please? Valentin

4 5

Language Workbench Challenge 2016: Call for Solutions
by Tijs van der Storm June 1, 2016

June 1, 2016

############################################################# 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)

1 0