February 2018 - Pharo-users

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

by Andrei Chis

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

Feb. 16, 2018

Re: [Pharo-users] global exception handler mechanism

by Henrik Sperre Johansen

You can also override #defaultAction on Exception, and install a custom UIManager subclass implementing unhandledErrorDefaultAction: (sent by UnhandledError #defaultAction, receives the error as argument). Would be nice(r) if UIManager had a defaultUnhandledErrorActionBlock: setter, but it's not too bothersome creating a subclass. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 16, 2018

Re: [Pharo-users] Pillar questions

by Stephane Ducasse

Pay attention that there is a pharo bug. The downloaded image has a minimal window of 10 pixels height and 5 width. On Thu, Feb 15, 2018 at 9:02 PM, Arturo Zambrano <arturo.zambrano(a)gmail.com> wrote: > Thanks for your support! > > The image seems to be successfully built. > When running it, it seems to be headless but I'm sure I'm not running it > in headless mode. > Is there any specific parameter for building or running it with UI? (I > also tried the pharo-ui launch script). > > > > > On Thu, Feb 15, 2018 at 3:16 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi arturo >> >> I do not really get how you do it. :) >> >> $ git clone git@github.com:pillar-markup/pillar.git -b newpipeline >> $ ./pillar/scripts/build.sh >> >> >> should load and then you get an image with pillar loaded. >> Now you can also just clone the branch and add with iceberg the project >> and load should work. >> >> May be you should enable the metacello settings to true. >> >> Stef >> >> >> On Thu, Feb 15, 2018 at 5:32 PM, Arturo Zambrano < >> arturo.zambrano(a)gmail.com> wrote: >> >>> I found the baseline menu entry.. sorry >>> >>> [image: Inline image 1] >>> >>> installations fails when I choose Install baseline of Pillar (default) >>> [image: Inline image 2] >>> >>> On Thu, Feb 15, 2018 at 12:50 PM, Arturo Zambrano < >>> arturo.zambrano(a)gmail.com> wrote: >>> >>>> Thanks Stef & Guillermo. >>>> >>>> Sorry, I'm a bit confused with Icerberg and GIT support. >>>> I'm using Iceberg and works fine for my small project without handling >>>> dependencies in github. >>>> >>>> I don't understand how dependencies are managed in this case. >>>> >>>> What I understand is that Pillar7 lives in Github, I cloned that repo, >>>> moved to the indicated branch >>>> when I try to install the packages (Icerber ->load package) it, as >>>> expected, >>>> asks for its dependencies. That's why I tried ConfigurationOfPillar >>>> loadXYZ >>>> >>>> @Stef, I'm trying to load Pillar packages into my image (pharo 6.1) >>>> for development. I tried the readme of that branch, I will report the >>>> errors I got in a separate thread. >>>> >>>> @Guillermo do you mean to manually clone each dependency github repo >>>> with iceberg? I think I'm missing something, some documentation maybe, any >>>> pointer is welcome. >>>> >>>> Thanks >>>> >>>> >>>> On Thu, Feb 15, 2018 at 6:01 AM, Guillermo Polito < >>>> guillermopolito(a)gmail.com> wrote: >>>> >>>>> And you should load baselines with iceberg (and git). >>>>> >>>>> On Thu, Feb 15, 2018 at 8:25 AM, Stephane Ducasse < >>>>> stepharo.self(a)gmail.com> wrote: >>>>> >>>>>> No you should use iceberg. The newpipeline is managed on github. >>>>>> Have a look at the readme of the that branch >>>>>> Before executing the build scripts check what it is doing. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> On Wed, Feb 14, 2018 at 10:00 PM, Arturo Zambrano < >>>>>> arturo.zambrano(a)gmail.com> wrote: >>>>>> >>>>>>> Hi Guillermo >>>>>>> >>>>>>> I'd recommend to use the latest pillar version in this branch: >>>>>>>> >>>>>>>> https://github.com/pillar-markup/pillar/tree/newpipeline >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I cloned that repo (using Iceberg on 6.1 image), moved to that >>>>>>> branch and then tried >>>>>>> ConfigurationOfPillar load{stable|bleedingEdge| etc} >>>>>>> >>>>>>> To get all the dependencies. >>>>>>> I got an error (see below) regarding magritte. >>>>>>> >>>>>>> Any advice? >>>>>>> >>>>>>> TIA >>>>>>> >>>>>>> [image: Inline image 1] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Arturo >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Guille Polito >>>>>>>> >>>>>>>> Research Engineer >>>>>>>> >>>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>>> >>>>>>>> CRIStAL - UMR 9189 >>>>>>>> >>>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>>>> <http://www.cnrs.fr>* >>>>>>>> >>>>>>>> >>>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>>> >>>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Guille Polito >>>>> >>>>> Research Engineer >>>>> >>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>> >>>>> CRIStAL - UMR 9189 >>>>> >>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>> <http://www.cnrs.fr>* >>>>> >>>>> >>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>> >>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>> >> >

Feb. 16, 2018

TechTalk Feb18: Recording is online

by Marcus Denker

Hi, The Video of yesterday's TechTalk is online! Topic: Contributing to Pharo 7, We Show: - How to submit issue tracker entries to the Pharo Issue Tracker - How to do a Pull Request if you want to do a fix or enhancment - How to review and comment other peoples fixes. Recoding Youtube: https://www.youtube.com/watch?v=VW7XrFjnbyw The slides are minimal but contain all links: - SlideShare: https://www.slideshare.net/MarcusDenker/pharotechtalk-contributing-to-pharo - PDF: http://files.pharo.org/media/techtalk/2018-TechTalk-Contribute.pdf The TechTalk has been added to the archvie, too: https://pharo.org/TechTalk Next Talks 2018: March 29: Report 2017 Pharo Consortium and Association. April 12: Pillar. May 17: TBA. June 14 TBA. You can subscribe and download calendar entries here: https://association.pharo.org/events

Feb. 16, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Esteban Lorenzano

hi, âcastingâ is not necessary in general since is just a way to tell the C compiler that a pointer is form a certain type (but is always a pointer, and in machine code is always the same). So, here you will do something like this: Iterator >> asCollectionOfType: aTypeName | result address typeClass | result := OrderedCollection new. address := ExternalAddress new. typeClass := FFIExternalType resolveType: aTypeName. [self iterator_next: address] whileTrue: [ result add: (typeClass fromHandle: address) ]. ^result Iterator >> iterator_next: data ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) nowâ¦ you have a problem if your type if your type is an âatomicâ type, like int, long, etc. because those values are passed âby valueâ and not by pointer, so you will need to decode them. in this case, I would implement a method extension (probably it worths to add it to UFFI): FFIExternalType class >> valueFromHandle: anAddress ^ self new handle: anAddress at: 1 âThis is used for structures, but we can reuse them :)" FFIExternalReference class >> valueFromHandle: anAddress ^ self fromHandle: anAddress FFIExternalStructure class >> valueFromHandle: anAddress ^ self fromHandle: anAddress So your function will be like something like this: Iterator >> asCollectionOfType: aTypeName | result address typeClass | result := OrderedCollection new. address := ExternalAddress new. typeClass := FFIExternalType resolveType: aTypeName. [self iterator_next: address] whileTrue: [ result add: (typeClass valueFromHandle:: address) ]. ^result and voilÃ , you have your cast :) Esteban ps: (some errors can be found here, since Iâm âprogramming at mail clientâ, but you get the idea ;) ) > On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com> wrote: > > 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 >

Feb. 16, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Torsten Bergmann

>but unfortunately its hard to find any docs or examples. PDF Docu: https://github.com/SquareBracketAssociates/Booklet-uFFI (this should be added to http://books.pharo.org) Examples: load OSWindows, OSLinuxUbuntu, ... or GlorpSQlite from catalog They all use UFFI.

Feb. 16, 2018

Call for Posters: <Programming> 2018

by Sylvia Grewe

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

Feb. 15, 2018

Re: [Pharo-users] Pillar questions

by Arturo Zambrano

Thanks for your support! The image seems to be successfully built. When running it, it seems to be headless but I'm sure I'm not running it in headless mode. Is there any specific parameter for building or running it with UI? (I also tried the pharo-ui launch script). On Thu, Feb 15, 2018 at 3:16 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi arturo > > I do not really get how you do it. :) > > $ git clone git@github.com:pillar-markup/pillar.git -b newpipeline > $ ./pillar/scripts/build.sh > > > should load and then you get an image with pillar loaded. > Now you can also just clone the branch and add with iceberg the project > and load should work. > > May be you should enable the metacello settings to true. > > Stef > > > On Thu, Feb 15, 2018 at 5:32 PM, Arturo Zambrano < > arturo.zambrano(a)gmail.com> wrote: > >> I found the baseline menu entry.. sorry >> >> [image: Inline image 1] >> >> installations fails when I choose Install baseline of Pillar (default) >> [image: Inline image 2] >> >> On Thu, Feb 15, 2018 at 12:50 PM, Arturo Zambrano < >> arturo.zambrano(a)gmail.com> wrote: >> >>> Thanks Stef & Guillermo. >>> >>> Sorry, I'm a bit confused with Icerberg and GIT support. >>> I'm using Iceberg and works fine for my small project without handling >>> dependencies in github. >>> >>> I don't understand how dependencies are managed in this case. >>> >>> What I understand is that Pillar7 lives in Github, I cloned that repo, >>> moved to the indicated branch >>> when I try to install the packages (Icerber ->load package) it, as >>> expected, >>> asks for its dependencies. That's why I tried ConfigurationOfPillar >>> loadXYZ >>> >>> @Stef, I'm trying to load Pillar packages into my image (pharo 6.1) for >>> development. I tried the readme of that branch, I will report the errors I >>> got in a separate thread. >>> >>> @Guillermo do you mean to manually clone each dependency github repo >>> with iceberg? I think I'm missing something, some documentation maybe, any >>> pointer is welcome. >>> >>> Thanks >>> >>> >>> On Thu, Feb 15, 2018 at 6:01 AM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> And you should load baselines with iceberg (and git). >>>> >>>> On Thu, Feb 15, 2018 at 8:25 AM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> wrote: >>>> >>>>> No you should use iceberg. The newpipeline is managed on github. >>>>> Have a look at the readme of the that branch >>>>> Before executing the build scripts check what it is doing. >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Wed, Feb 14, 2018 at 10:00 PM, Arturo Zambrano < >>>>> arturo.zambrano(a)gmail.com> wrote: >>>>> >>>>>> Hi Guillermo >>>>>> >>>>>> I'd recommend to use the latest pillar version in this branch: >>>>>>> >>>>>>> https://github.com/pillar-markup/pillar/tree/newpipeline >>>>>>> >>>>>>> >>>>>> >>>>>> I cloned that repo (using Iceberg on 6.1 image), moved to that branch >>>>>> and then tried >>>>>> ConfigurationOfPillar load{stable|bleedingEdge| etc} >>>>>> >>>>>> To get all the dependencies. >>>>>> I got an error (see below) regarding magritte. >>>>>> >>>>>> Any advice? >>>>>> >>>>>> TIA >>>>>> >>>>>> [image: Inline image 1] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> Thanks! >>>>>>>> Arturo >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> Guille Polito >>>>>>> >>>>>>> Research Engineer >>>>>>> >>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>> >>>>>>> CRIStAL - UMR 9189 >>>>>>> >>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>>> <http://www.cnrs.fr>* >>>>>>> >>>>>>> >>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>> >>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >

Feb. 15, 2018

UFFI correct way to cast void*

by Egor Scorik

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

Feb. 15, 2018

Re: [Pharo-users] Pillar questions

by Stephane Ducasse

Hi arturo I do not really get how you do it. :) $ git clone git@github.com:pillar-markup/pillar.git -b newpipeline $ ./pillar/scripts/build.sh should load and then you get an image with pillar loaded. Now you can also just clone the branch and add with iceberg the project and load should work. May be you should enable the metacello settings to true. Stef On Thu, Feb 15, 2018 at 5:32 PM, Arturo Zambrano <arturo.zambrano(a)gmail.com> wrote: > I found the baseline menu entry.. sorry > > [image: Inline image 1] > > installations fails when I choose Install baseline of Pillar (default) > [image: Inline image 2] > > On Thu, Feb 15, 2018 at 12:50 PM, Arturo Zambrano < > arturo.zambrano(a)gmail.com> wrote: > >> Thanks Stef & Guillermo. >> >> Sorry, I'm a bit confused with Icerberg and GIT support. >> I'm using Iceberg and works fine for my small project without handling >> dependencies in github. >> >> I don't understand how dependencies are managed in this case. >> >> What I understand is that Pillar7 lives in Github, I cloned that repo, >> moved to the indicated branch >> when I try to install the packages (Icerber ->load package) it, as >> expected, >> asks for its dependencies. That's why I tried ConfigurationOfPillar >> loadXYZ >> >> @Stef, I'm trying to load Pillar packages into my image (pharo 6.1) for >> development. I tried the readme of that branch, I will report the errors I >> got in a separate thread. >> >> @Guillermo do you mean to manually clone each dependency github repo >> with iceberg? I think I'm missing something, some documentation maybe, any >> pointer is welcome. >> >> Thanks >> >> >> On Thu, Feb 15, 2018 at 6:01 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> And you should load baselines with iceberg (and git). >>> >>> On Thu, Feb 15, 2018 at 8:25 AM, Stephane Ducasse < >>> stepharo.self(a)gmail.com> wrote: >>> >>>> No you should use iceberg. The newpipeline is managed on github. >>>> Have a look at the readme of the that branch >>>> Before executing the build scripts check what it is doing. >>>> >>>> Stef >>>> >>>> >>>> On Wed, Feb 14, 2018 at 10:00 PM, Arturo Zambrano < >>>> arturo.zambrano(a)gmail.com> wrote: >>>> >>>>> Hi Guillermo >>>>> >>>>> I'd recommend to use the latest pillar version in this branch: >>>>>> >>>>>> https://github.com/pillar-markup/pillar/tree/newpipeline >>>>>> >>>>>> >>>>> >>>>> I cloned that repo (using Iceberg on 6.1 image), moved to that branch >>>>> and then tried >>>>> ConfigurationOfPillar load{stable|bleedingEdge| etc} >>>>> >>>>> To get all the dependencies. >>>>> I got an error (see below) regarding magritte. >>>>> >>>>> Any advice? >>>>> >>>>> TIA >>>>> >>>>> [image: Inline image 1] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>> Thanks! >>>>>>> Arturo >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>> >>>>>> CRIStAL - UMR 9189 >>>>>> >>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>> <http://www.cnrs.fr>* >>>>>> >>>>>> >>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>> >>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> >

Feb. 15, 2018