January 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Trying to test Phantom / aspects in Pharo

by alvaro piorno

You should have received a mail from my partner. I hope that helped you. 2018-01-15 17:40 GMT-03:00 Steven Costiou <steven.costiou(a)kloum.io>: > Hi, thanks for the info :) > > Is your version for pharo 6.0 somewhere i can download it ? > > > > Steven. > > > > Le 2018-01-15 19:17, alvaro piorno a Ã©crit : > > Hi, > A friend and i worked on phatom to make it work on actual pharo > versions(at that momento was 6.0 or 6.1) and could make examples work and > lot of tests to pass. > My partner went deeper into this, maybe she can help. ( > sosa.ines.m(a)gmail.com) > > > 2018-01-14 21:31 GMT-03:00 Miguel Campusano <m.campusano.araya(a)gmail.com>: > >> As far as I know, this is a project for an undregard thesis and I believe >> it is discontinued. If you contact Johan I will be glad to collaborate on >> this for a good cause >> >> On Sat, Jan 13, 2018 at 10:24 AM Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> You should ask Johan Fabry. >>> Now working at Raincode in belgium. >>> >>> Stef >>> >>> On Sat, Jan 13, 2018 at 1:06 PM, Steven Costiou <steven.costiou(a)kloum.io> >>> wrote: >>> > Hi, >>> > >>> > i am trying to test PHANtom but so far i can't get it to work. >>> > >>> > I found an image here https://pleiad.cl/research/software/phantom and >>> i made >>> > it run on a vm from 2013. >>> > >>> > But the examples crashes (PhantomDemo), and i cannot make my own >>> examples >>> > work either (simple object interception). >>> > >>> > >>> > >>> > Which vm should i use ? >>> > >>> > Is the image available in the link above still ok ? >>> > >>> > By any chance, is there a version for Pharo 6 ? >>> > >>> > >>> > >>> > Steven. >>> > >>> > >>> >>

Jan. 22, 2018

Re: [Pharo-users] [JOB] Engineer 1 year: Pharo IoT platform

by Miguel Campusano

On Mon, Jan 22, 2018 at 6:17 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > Inria RMoD are looking for a full-time engineer for helping with > developing Pharo in the context of IoT. The focus of this job is "Pharo on > embedded and mobile devices for the internet of things" > > With Pharo, we have developed over the last two years an interactive, > remote development environment. It allows embedded, headless software > running on typical raspberry pi class hardware to be developed and debugged > in an interactive way. It allows programmers to explore and change running > headless embedded programs from their desktop development machine. > > The next step will be to extend this infrastructure to cover the use case > of industrial use: Deployment. We want to build a middle-ware to manage, > authenticate and script deployed Pharo embedded installations. > > The engineer will help to develop the Pharo IoT infrastructure, especially > with a focus on industrial use: > > â¢ Improve Pharo for a platform with an industrial focus. > â¢ Work on a middleware to manage deployed Pharo instances. > â¢ Realize two small demos: First, as an industrial IoT example, a > demo deployed on 20+ devices. > Demo 2: Pharo deployed on multiple mobile autonomous robots. > â¢ Help with creating a website for PharoIOT. > > > We are looking for a candidate with some prior experience with Pharo. > In addition: > > â¢ Knowledge in Dynamic Languages (Pharo is a plus but not required) > â¢ Experience with embedded development is a plus but not required > â¢ English > > Work in a research lab, but no paper writing, no teaching, no > administration. In addition: > > â¢ Centrally located (one hour from Paris, 1h20 from London, 35 min > from Brussels) > â¢ Try a lot of good beer (our office is just 10km from the border > to Belgium) > â¢ Program with Pharo all day! > â¢ Lille is an active city but not expensive (lot of students...), > centrally located with good connections by train to everywhere (including > CDG and Brussels airports). > â¢ Duration: 12 Month > â¢ Starting date: As soon as possible (Spring 2018) > â¢ Salary: 2600-3200 euros brut / month, depending on experience > â¢ Explanation Salary: french brutto = money after social charges > (and base health insurance) before income tax, which is max one month > income payed > yearly, depending on family situation (can be 0 for a family > with kids) > â¢ Location: Lille (no remote job possible)) > > More about > > â¢ Pharo: http://www.pharo.org > â¢ PharoThings: https://github.com/pharo-iot/PharoThings > â¢ INRIA RMOD: http://rmod.lille.inria.fr > â¢ INRIA Lille: http://www.inria.fr/lille > â¢ INRIA in General: http://www.inria.fr > â¢ Lille: > â¢ http://en.wikipedia.org/wiki/Lille > â¢ http://wikitravel.org/en/Lille > > Do not hesitate to contact us for more information. > Permanent Link to this call: https://rmod.inria.fr/web/blog/2017-10-20 >

Jan. 22, 2018

Re: [Pharo-users] calypso modularity

by Denis Kudriashov

Hi Peter. Calypso is modular but maybe not in the parts which you need. There are two core packages which are not related to the "Smalltalk navigation": - navigation model based on first class queries. - UI components for possible browsers And I imagine how I would use them in particular business applications which I built in may career. Now the only example is "Smalltalk navigation" which is packaged in multiple "SystemQueries" and "SystemTools" packages. 2018-01-20 21:40 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > how modular is Calypso in respect to: > > * taking the UI apart and compositing it in a different manner > Calypso is not a browser framework like Glamour. So the UI part is restricted by the required browsers controlfow in the abstract class ClyBrowser: - top half of window is used to place navigation panes which should be defined by subclasses - bottom half of window is used by tabs. - and toolbar at the middle. Tabs, toolbar items, context menu and shortcuts are all pluggable. They all extended by annotating required classes with context where they should be used. So they are not hardcoded and reusable. Navigation panes are defined as instances of ClyQueryView which is reusable widget to show result of any calypso query. It implements correct updating after system changes, maintains item selection and provide menus and shortcuts. * reusing parts of it in a different place/application (e.g. just the code > editor, or just the method list, ...) > It is in todo. But now these tools are required to be in browser tabs, they know about tab. But I want to be able annotate arbitrary widget that it should be shown as browser tab. > * using alternative abstractions to just package/class/protocol/method > * e.g. instead of showing classes SomeSubject, SomeSubjectTest it would > show "Some Subject" (a string returned by SomeSubject class>>myName) and > clicking on it would show the combined methods from both the SomeSubject > and SomeSubjectTest. > So as I said these panes are based on ClyQueryView. Whatever query you would pass it will show result items. Query can return mixed items. For example QueryBrowser shows together methods, classes and class comments. All menus and shortcuts are continue work with known types. And you can implement new commands for new items type. Only questions is how inject special queries to the required panes. It is now hardcoded. And there is hardcoded logic how to handle selection changes. For example FullBrowser knows that it should show methods for selected classes. It expects that class pane will provide classes and not something else. But there is already system of browser plugins and we can delegate some logic to them. The question is what use cases we need. For example to support optional trait methods visibility I will need to allow plugins decorate default scope for methods. Trait plugin will extends with inherited traits (when trait visibility is enabled by default). In addition it could provide possibility to implement mixed instance side and class side mode. > Also would such alternate usecases be considered a feature of Calypso (so > it is intentional in building Calypso to use it in a different manner), or > purely coincidental (as in, if it is possible, Calypso is built for > different purpose and I cannot expect that some property will not disappear > in the future). > Yes. I think it is important to be able experiment. > > Thanks a lot! > Peter >

Jan. 22, 2018

Re: [Pharo-users] Aare questions

by CÃ©drick BÃ©ler

> > > Ok so we redid everything in parallel. Too bad anyway I will continue > and my changes are in my clone. Ok. At least we converge :) I thought I explained it in the book. > I will update the booklet once I get it. Cool. Iâll join soon. Cheers, CÃ©drick Side note: I like to extract class comment from pillar. First loading the workflow package : [[[eval=true (Smalltalk hasClassNamed: 'WfWorkflow') ifFalse: [ "should save not to load again >> update" Metacello new baseline: #Workflow; repository: 'github://Netstyle/Workflow:master/src'; load. SmalltalkImage current saveSession] ]]] Then: [[[eval=true stream nextPutAll: '__WfManagedObject comment:__ ' ; nextPutAll: WfManagedObject comment; cr; lf. ]]] Fun :)

Jan. 22, 2018

Workflow/Aare design - distribution or not ? And how ? (Was Re: (Aare questions))

by CÃ©drick BÃ©ler

Just change the subject to discuss on one point. => How make workflow application (in one image) delegate activation (and/or subworkflow) to another image. >> Yes sure. But at this is an important requirement for me, I prefer to >> talk about it first :) > > Distributed systems design is a different subject. Different constraints, > different solutions. I donât really agree. Of course youâre right but I see little interest in having a process engine in a centralized manner (today is more about decentralized solution than ever and we have smalltalk heritage about message passing). Because, in centralized workflow, complexity is the proper use of the tool. You work in a decentralized world with a centralized tool. You have to plug to existing IS through mails, sms, REST API or whateverâ¦ All workflow systems Iâve seen (Iâm not expert though) are that way and quite boring to use by the wayâ¦ Then, we enter the real of model transformation so as to be interoperable. Whereas I kind of like the concepts, I find itâs like programming in C vs. in Smalltalk fo information exchangeâ¦ Slow, couter intuitive, web based most of the timeâ¦ So to come back to the subject, to me, to have a powerful workflow engine, one has first to consider actors on several applications hence images (at starts). Of course several actors on the same image can be interesting, so doing it first has sense. To me, but I know I see things superficially (Iâm not a programmer), we could have something quite simple that does the job. Of course it raises questions like we had with Max. I copy below as my response (see PS). But to sumup, the simple version I need will be one person runs a workflow in a RootFrame. Then he has activities he is responsible but I can delegate some other. Itâs possible to have subworkflows (but again associated to him or an actor in the image). We could Â« just add Â» the possibility to activate a distant step (or a distant subworkflow). Me (Alice) ask someone else (Bob) to do an activity (a step). Here is how I see it: -My process activate this task (image Alice). I send a signal, a message to the appropriate actor (image of Bob). I just wait until I receive other signals (progression metadata, resources, deliverablesâ¦). Of course cancelling an activation is useful there as Bob can never answer. - I (image Alice) have not a lot of responsibility except waiting. - An interesting option would be to be able to ping for completion. -The distant image manager (and scheduler) receive a signal, a message so that a step has to be done. -Bob does the job on its own. Send progressively elements (eventually). He has to send at least when the job is over (eventually devliverables as documents, informations, â¦). The key to me is to consider systems that are distributed (decentralized actually) not in computer terms but in human termsâ¦ It changes everything as less complex. Look at workflow right now, it only allows manual completion of activations (step being realized)â¦. So itâs basically a human clicking on a button to tell the system the activity is over ! I would prefer having this functionality in a distributed/decentralized manner than having workflow more powerful in a centralized manner. So to me we need to extend and reify better the possibility to delegate and clicks on buttons (regarding questions) and of course in a decentralized manner. I hope you understand what I mean. I hope too not being to naive about such a design. But to me, we need two basic building blocks to provide what I (we?) need: - the possibility to inform to someone or to a group (wait no response - but eventually information on status like reception, first reading, complete reading) - the possibility to request someone or to a group (I wait for a response) Donât hesitate to criticize, discuss, Iâm all ears ;-) Cheers, CÃ©drick PS: The discussion about this point with Max >> Announcements would certainly be an interesting way to decouple Workflow from other parts of the system. >> >> > > Yes an important design decision. > > >>> >>> Iâd like to have an incomingMessageBox for each user and eventually transform these message in concrete action (user i/o) ? Or dispatch in JobQueues (each user being a distant worker thread). Again, the distinction between Scheduler and BPEngin is fuzzy to me. >> >>> >>> Does it make sense to you ? >> >> Yes, it does :) What I've asked myself (out of curiosity) is whether you want to have >> >> - a dedicated instance for executing workflows >> >> - a distributed workflow with autonomous synchronisation (parts of a workflow could run on every uses instance, others would need to be executed through agreement) >> >> - a partially distributed workflow with one or more managing nodes that control the core steps (e.g. you could designate parts of a workflow as independant) >> >> > > Iâm not really sure what I want :) . > I think the 3 are possible/interesting. What I donât want is a centralized approach (if it exists, it has to be a very special case). > > My project is about having autonomous personnel systems. My system have a priori several nodes (one application per device). Itâs a decentralized (federated/distributed) network of nodes. > My system interact (exchange information basically through messages) with other species having an equivalent node-based system. > All is about keeping version history of the information (yes it looks like GIT that I try not to use ^^ - GITHUB could probably be a special kind of node BTW). > > So I was thinking that one of the exchanged Â« messages Â» type could be Â« activations Â» sent by someone responsible of the workflow. So : > > At first, I want each personal system to have the BP Engine and be able to execute workflow alone (personal routine, planification, suggestions, â¦) => normal usage > Soon, it becomes distributed, for instance if the person have several devices that share the system and the activations. > > And if we consider interactions with other persons (and organisations which are group of persons), then we quickly have distributed (or partially distributed) workflows. > Not crystal clear I guess :-) > This is a subject Iâd like to propose a PhD on. I try to convince a web dev company to develop such a distributed organizational tool butâ¦ no positive answer for now). I need to push more ! > So I give it a try by mysel and here we are. > > To better respond to you question, here is a simple use case I imagine: > - Iâm the responsible of the workflow execution. > - When I assign a task A to someone (or an organization, or something like a smart object), I delegate the realization and then it would be a special case of SubWorkflow that is distant. > 1) once activated, I send a special message to the other personal system. > + deadline/metadata + interaction contracts (do I only wait or can I see the actual progression ? To which level?) > 2) I wait. > â I'm able to ask for the realization status, a degree of completion, > ââ Depending on the contract (level of agreement), I can have more or less right on seing the realization but that's not the point here. First, I want to delegate and have information about the realization degree (+eventual bad event that could have arose) > 3) I received the completion message + eventual document, artefacts, summarized information (note that the system respect privacy by defaults - all exchange is under control). > 4) my workflow continues > > So itâs a bit of a distributed workflow under a central control node but with distributed sub-workflows. It seems doable without too much effort. Maybe declaring DistantSubFlow and having proper history (using messaging functionalities to get status update) > But again, quickly, that would be very interesting to consider several managing nodes (I guess another PHD on itself for this one).

Jan. 22, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

Yes, I was considering this in the context of some approximation algorithms. Maybe one of the VM experts here could comment on the possibility to implement that? Am .01.2018, 10:00 Uhr, schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Mon, Jan 15, 2018 at 12:27 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> Hi, >> >> is there any way to set the rounding mode for IEEE floating point >> operations? Maybe something like >> >> Double roundToMinusInfWhile: [... code goes here ...]Double >>> roundToZeroWhile: [... more code here ...] >>> >> >> If not, is it possible to add this behavior, e.g., via a custom >> primitive? >> >> > âThis might interesting to have something like that for PolyMath, but > I'm a > little worried of subtle consequences > that might appear in UI if you use points for examples.â

Jan. 22, 2018

Re: [Pharo-users] looking for another iterator :)

by Steffen MÃ¤rcker

Hi! this is straightforward with Transducers, e.g., > (Take n: 5) <~ #(1 2 3 4 5 6 7 8). or > #(1 2 3 4 5 6 7 8) transduce take: 5. The different primitives like take, drop, map, filter, etc. are composable and do not generate intermediate representations. The bad news are, that the Pharo port is incomplete and I won't have the time until April to finish it. Best, Steffen Am .01.2018, 10:57 Uhr, schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > 5

Jan. 22, 2018

Re: [Pharo-users] looking for another iterator :)

by Sven Van Caekenberghe

yes, we need composition to avoid API explosion (things are already very bad in this respect) > On 22 Jan 2018, at 10:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > In most collection libraries I know there is the "take" function coming from the functional world that does that: > > #(1 2 3 4 5 6 7 8) take: 5 > => #(1 2 3 4 5) > > #(1 2 3 4) take: 5 > => #(1 2 3 4) > > Now, I understand there are two different things in here. > - First is the fact that we would like to apply this iterator to more than sequenceable collections. I think that the name "take" is order agnostic in that sense. > - The other thing is that people would like to not calculate the sub-collection... The problem is that we will end up with ugly combinations of selectors like > > take:thenDo: > take:thenCollect: > take:thenSelect: > ... > > And that pattern already exists also for: > > select:thenCollect: > select:thenDo: > > collect:as: > select:as: > > ... > > I think I would like to have a more composable kind of iterators/collections. There are Transducers that make "iterators" kind of command objects that you can apply on a collection. Personally I don't like the API choice but the idea behind is nice: > > https://github.com/Pharophile/Transducers > > sum := #+ init: 0. > sum1 := #(1 1 1) reduce: sum. > sum2 := (1 to: 1000) transduce: #odd filter reduce: sum. > > > And there are XTreams that allows one to work on a collection as a stream and then compose decorators on top. This means however that we need to create a stream and "close" it to obtain the resulting collection on every manipulation. > > https://github.com/mkobetic/Xtreams > https://code.google.com/archive/p/xtreams/wikis/Core.wiki > > ((aCollection reading collect: [ ... ]) select: [ ... ]) rest. > > Guille > > On Mon, Jan 22, 2018 at 4:11 AM, Ben Coman <btc(a)openinworld.com> wrote: > On 22 January 2018 at 00:47, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi Ben and Clement > > > > I have a collection (a dictionary in my case) and I want to get > > maximum 5 bindings out of it and iterate on them. > > I want keysAndValuesDo: or do: but only up to 5 elements. > > > > aDict atMax: 5 do: [:each | ] > > "atMax" sound a bit like comparison rather than counting. Perhaps > better would be... > aDict atMost: 5 do: [:each | ] "or" > aDict for: 5 do: [:each | ] > > but rather than introduce three or more messages... > aDict atMost: 5 do: [:each| ... ] > aDict atMost: 5 select: [:each| ... ] > aDict atMost: 5 collect: [:each| ... ] > > why not introduce just one method?.... > (aDict any: 5) do: [:each| ... ] > (aDict any: 5) select: [:each| ... ] > (aDict any: 5) collect: [:each| ... ] > > > cheers -ben > > > > So I learned from:to:do: > > > > aCollection atMax: 5 do: [:each | ] > > > > Does it make sense? > > > > Stef > > > > On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> I don't think we do. Do you need it on SequenceableCollection or > >> HashedCollection too ? > >> > >> Recently I was trying to iterate over the first N elements of a collection > >> and since there was no #first:do: I used #from:to:do:. I guess you could use > >> that too: > >> > >> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock > >> > >> Which guarantees you iterate at max over 1000 elements. But that API is > >> SequenceableCollection specific. > >> > >> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > >>> > >>> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com> > >>> wrote: > >>> > Hi > >>> > > >>> > I would like to iterate at max on a certain amount of elements in a > >>> > collection. > >>> > And I was wondering if we have such iterator. > >>> > >>> I'm not clear what functionality your asking for. Could you present > >>> it as code & result if you assumed the iterator you want was > >>> available? > >>> > >>> cheers -ben > >>> > >> > >> > >> > >> -- > >> ClÃ©ment BÃ©ra > >> Pharo consortium engineer > >> https://clementbera.wordpress.com/ > >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > > -- > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Jan. 22, 2018

Re: [Pharo-users] looking for another iterator :)

by Guillermo Polito

In most collection libraries I know there is the "take" function coming from the functional world that does that: #(1 2 3 4 5 6 7 8) take: 5 => #(1 2 3 4 5) #(1 2 3 4) take: 5 => #(1 2 3 4) Now, I understand there are two different things in here. - First is the fact that we would like to apply this iterator to more than sequenceable collections. I think that the name "take" is order agnostic in that sense. - The other thing is that people would like to not calculate the sub-collection... The problem is that we will end up with ugly combinations of selectors like take:thenDo: take:thenCollect: take:thenSelect: ... And that pattern already exists also for: select:thenCollect: select:thenDo: collect:as: select:as: ... I think I would like to have a more composable kind of iterators/collections. There are Transducers that make "iterators" kind of command objects that you can apply on a collection. Personally I don't like the API choice but the idea behind is nice: https://github.com/Pharophile/Transducers sum := #+ init: 0. sum1 := #(1 1 1) reduce: sum. sum2 := (1 to: 1000) transduce: #odd filter reduce: sum. And there are XTreams that allows one to work on a collection as a stream and then compose decorators on top. This means however that we need to create a stream and "close" it to obtain the resulting collection on every manipulation. https://github.com/mkobetic/Xtreams https://code.google.com/archive/p/xtreams/wikis/Core.wiki ((aCollection reading collect: [ ... ]) select: [ ... ]) rest. Guille On Mon, Jan 22, 2018 at 4:11 AM, Ben Coman <btc(a)openinworld.com> wrote: > On 22 January 2018 at 00:47, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > Hi Ben and Clement > > > > I have a collection (a dictionary in my case) and I want to get > > maximum 5 bindings out of it and iterate on them. > > I want keysAndValuesDo: or do: but only up to 5 elements. > > > > aDict atMax: 5 do: [:each | ] > > "atMax" sound a bit like comparison rather than counting. Perhaps > better would be... > aDict atMost: 5 do: [:each | ] "or" > aDict for: 5 do: [:each | ] > > but rather than introduce three or more messages... > aDict atMost: 5 do: [:each| ... ] > aDict atMost: 5 select: [:each| ... ] > aDict atMost: 5 collect: [:each| ... ] > > why not introduce just one method?.... > (aDict any: 5) do: [:each| ... ] > (aDict any: 5) select: [:each| ... ] > (aDict any: 5) collect: [:each| ... ] > > > cheers -ben > > > > So I learned from:to:do: > > > > aCollection atMax: 5 do: [:each | ] > > > > Does it make sense? > > > > Stef > > > > On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> I don't think we do. Do you need it on SequenceableCollection or > >> HashedCollection too ? > >> > >> Recently I was trying to iterate over the first N elements of a > collection > >> and since there was no #first:do: I used #from:to:do:. I guess you > could use > >> that too: > >> > >> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock > >> > >> Which guarantees you iterate at max over 1000 elements. But that API is > >> SequenceableCollection specific. > >> > >> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> > wrote: > >>> > >>> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com > > > >>> wrote: > >>> > Hi > >>> > > >>> > I would like to iterate at max on a certain amount of elements in a > >>> > collection. > >>> > And I was wondering if we have such iterator. > >>> > >>> I'm not clear what functionality your asking for. Could you present > >>> it as code & result if you assumed the iterator you want was > >>> available? > >>> > >>> cheers -ben > >>> > >> > >> > >> > >> -- > >> ClÃ©ment BÃ©ra > >> Pharo consortium engineer > >> https://clementbera.wordpress.com/ > >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > -- 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

Jan. 22, 2018

[JOB] Engineer 1 year: Pharo IoT platform

by Marcus Denker

Inria RMoD are looking for a full-time engineer for helping with developing Pharo in the context of IoT. The focus of this job is "Pharo on embedded and mobile devices for the internet of things" With Pharo, we have developed over the last two years an interactive, remote development environment. It allows embedded, headless software running on typical raspberry pi class hardware to be developed and debugged in an interactive way. It allows programmers to explore and change running headless embedded programs from their desktop development machine. The next step will be to extend this infrastructure to cover the use case of industrial use: Deployment. We want to build a middle-ware to manage, authenticate and script deployed Pharo embedded installations. The engineer will help to develop the Pharo IoT infrastructure, especially with a focus on industrial use: â¢ Improve Pharo for a platform with an industrial focus. â¢ Work on a middleware to manage deployed Pharo instances. â¢ Realize two small demos: First, as an industrial IoT example, a demo deployed on 20+ devices. Demo 2: Pharo deployed on multiple mobile autonomous robots. â¢ Help with creating a website for PharoIOT. We are looking for a candidate with some prior experience with Pharo. In addition: â¢ Knowledge in Dynamic Languages (Pharo is a plus but not required) â¢ Experience with embedded development is a plus but not required â¢ English Work in a research lab, but no paper writing, no teaching, no administration. In addition: â¢ Centrally located (one hour from Paris, 1h20 from London, 35 min from Brussels) â¢ Try a lot of good beer (our office is just 10km from the border to Belgium) â¢ Program with Pharo all day! â¢ Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). â¢ Duration: 12 Month â¢ Starting date: As soon as possible (Spring 2018) â¢ Salary: 2600-3200 euros brut / month, depending on experience â¢ Explanation Salary: french brutto = money after social charges (and base health insurance) before income tax, which is max one month income payed yearly, depending on family situation (can be 0 for a family with kids) â¢ Location: Lille (no remote job possible)) More about â¢ Pharo: http://www.pharo.org â¢ PharoThings: https://github.com/pharo-iot/PharoThings â¢ INRIA RMOD: http://rmod.lille.inria.fr â¢ INRIA Lille: http://www.inria.fr/lille â¢ INRIA in General: http://www.inria.fr â¢ Lille: â¢ http://en.wikipedia.org/wiki/Lille â¢ http://wikitravel.org/en/Lille Do not hesitate to contact us for more information. Permanent Link to this call: https://rmod.inria.fr/web/blog/2017-10-20

Jan. 22, 2018