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

[ANN] Pharo Consortium New Academic Member: ÃTS MontrÃ©al
by Marcus Denker Jan. 24, 2020

Jan. 24, 2020

The Pharo Consortium is very happy to announce that ÃTS MontrÃ©al has joined the Consortium as an Academic Member. About - ÃTS MontrÃ©al: https://www.etsmtl.ca/en/Home - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

1 0

UK Smalltalk User Group meeting: Beers and Pharo 8 - 29 January 2020
by Giovanni Corriga Jan. 23, 2020

Jan. 23, 2020

The next meeting of the UK Smalltalk User Group will be on Wednesday, January 29th. We'll meet at our usual venue, The City Pride ( https://www.cityprideclerkenwell.co.uk/ ), from 7pm onwards. For this monthâs meeting, weâll explore the new release 8.0 of Pharo, which was announced a few weeks ago. If you'd like to join us, you can show up at the pub. You can also sign up in advance on the meeting's Meetup page https://www.meetup.com/UKSTUG/events/cbklbrybccbdc/ . Donât forget to bring your laptop!

1 0

Re: [Pharo-users] Embedding pharo in C++
by Pierce Ng Jan. 22, 2020

Jan. 22, 2020

On Tue, Jan 21, 2020 at 08:20:48PM +0100, Roland PlÃ¼ss via Pharo-users wrote: > The first mode is the "runtime mode". This would be the mode used for > the released products and does not allow to "directly modify" the image. > This mode would only require basic set of classes (frameworks) since the > game engine provides a large set of functionality in the module layer so > the script layer provides the logic, UI and things like that. This image > would not require to be enriched with a lot of things. This is doable currently. The Pharo image is embedded into the executable and used in read-only mode. Although personally I'd implement as much of the app logic in Pharo as possible simply because of the high productivity. > The second mode is the "development mode". For this one I thought about > exposing a Pharo VM image acting as the Coding and Debugging IDE. Here I > would opt to expose the full power of Pharo/Smalltalk to the developer. I envisage doing this via some kind of data exchange between the host program and Pharo, which seems doable for both the embedded and 'over the wire' development cases. Pablo recently published an example of embedding a headless-but-GUI Pharo image inside a C program via the Windows resource mechanism. As it happens, I have just implemented the same example that works on Linux and MacOS from one source code. Didn't test on Windows, but I'm sure it'll work there too. In a day or two I will publish the code and blog post. Attached teaser screenshot. :-) Pierce

3 5

[ANN] SmalltalkCI now supports Pharo 9
by Gabriel Cotelli Jan. 22, 2020

Jan. 22, 2020

Hi, Just to let you know that smalltalkCI was updated to include Pharo 9, 32 and 64 bits as available versions to be used, and stable/alpha were updated to be Pharo 8 and Pharo 9. Thanks Pablo Tesone & Fabio Niephaus for helping in getting this updates ready. Regards, Gabriel

1 0

voyage mongo and transactionality
by Jonathan van Alteren Jan. 22, 2020

Jan. 22, 2020

Hello all, We are having some issues with using Voyage/Mongo for a customer project that I'd like to get your feedback on. The customer application is a form based business web application using Seaside with object persistence using Voyage with MongoDBÂ on Pharo 7.0. The application is deployed on a dedicated Linux production server running MongoDB version 4.2. The application is used to manage meeting agendas and minutes. After opening the agenda view of a future meeting, the user can add an item to the agenda by clicking a button. This calls an item editor component which answers when a Save or Cancel button is clicked. The agenda view component itself also has a Save button, which performs a Voyage save of the object aggregate (agenda + items). We've encountered an issue where a user makes changes to an agenda, but does not click the Save button. Instead, the user closes the browser or uses the navigation to go to a different part of the application. When navigating back to the original agenda, the changes made previously (e.g. items added) are still being displayed, even though they were never explicitly saved. It does not matter if we select the agenda aggregate object instance using Voyage or access it in a different way. Changes to the state of the object are retained, even though a Voyage save was never sent to the agenda instance. The cause seems to be that the Voyage repository caches the object instance and thus on select, it returns an object that is in a different state than how it was persisted. This all seems to come down to object transactionality. We have a need to 'cancel' changes made to an object instance. Before working with Pharo/Smalltalk in a non-image based environment, I was used to do this by retrieving the original object from persistence again. This also allowed for a convenient way to detect changes to an object's state, which we are missing at the moment too. We know that moving to GemStone can help us with these issues, but our current planning of customer projects does not allow us to do this within the next 3 months. And we really need to find a way to tackle these issues . Your feedback is greatly appreciated! Kind regards, Jonathan van Alteren Founding Member | Object Guild jvalteren(a)objectguild.com

9 25

Re: [Pharo-users] Embedding pharo in C++
by ponyatov Jan. 22, 2020

Jan. 22, 2020

Good day Is it a variant to implement an embeddable Little Smalltalk-like engine that does not use bytecode but uses LLVM JIT for direct machine code compilation? Or maybe can we use a less aggressive approach with the same embedded engine which interprets bytecode? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

1 0

Re: Embedding pharo in C++
by Roland PlÃ¼ss Jan. 21, 2020

Jan. 21, 2020

Hi StÃ©phane, In the GnuSmalltalk PoC I could init the VM and then I run functions in it like this: Â Â gst_perform(pObjGame, selector); Then I created some native test functions in C like this: Â Â gst_define_cfunc("DECanvas.setPosition", (void*)funcSetPosition);" I then added in smalltalk a function definition calling the c-function like this: position: aDEPoint [ Â Â "Set position in parent canvas view units." Â Â <cCall: 'DECanvas.setPosition' returning: #void args: #(#self #smalltalk)> ] If PharoVM would provide a mechanis like this then this would be all I need to pull it off. That said though I don't know how the PharoVM works on the inside. I just read somewhere that there is an FFI with cCall so that sounds like basically half the job done. Just tossing thoughts around here though. On 1/21/20 10:13 PM, StÃ©phane Ducasse wrote: > Hi roland,Â > >> *From: *Roland PlÃ¼ss <roland(a)rptd.ch <mailto:roland@rptd.ch>> >> *Subject: **Re: Embedding pharo in C++* >> *Date: *21 January 2020 at 20:20:48 CET >> *To: *Pharo-users(a)lists.pharo.org <mailto:Pharo-users@lists.pharo.org> >> >> >> Looks like you always meet twice in life I guess. You won't remember >> me but I've been a student of yours once upon time. Nice to see you >> again, Prof. Ducasse, >> > Oh niceâ¦. > Long time :) > I was younger :) > >> I had in mind to have the VM running in two modes actually. >> >> The first mode is the "runtime mode". This would be the mode used for >> the released products and does not allow to "directly modify" the >> image. This mode would only require basic set of classes (frameworks) >> since the game engine provides a large set of functionality in the >> module layer so the script layer provides the logic, UI and things >> like that. This image would not require to be enriched with a lot of >> things. >> > What is nice there is that it is also a safer path because it may be > less complex.Â > > Theo is working onÂ > - exposing an interface of the VM so that we can query it from the > outside.Â > - I would love to be able to say to the VM to run a number of steps so > that we could test it from outside > But this is really brainstorming.Â >> >> The second mode is the "development mode". For this one I thought >> about exposing a Pharo VM image acting as the Coding and Debugging >> IDE. Here I would opt to expose the full power of Pharo/Smalltalk to >> the developer. >> > The second scenario is what is used in woden and thales used it to > developed the proof of concept with their boats.Â > https://www.youtube.com/watch?v=b4nNtN7XBi8 > >> Does this sound feasible in the way PharoVM is designed? >> > I think that you can really have bindings and drive them from Pharo.Â > Now what is complex is more the reverse control, in the sense that you > want your application to drive Pharo. > I will let VM experts reply to you.Â > > In any case we are really interesting in helping you and getting > information about our lacks and limits.Â >> >>> >>>> On 21 Jan 2020, at 18:29, Roland PlÃ¼ss <roland(a)rptd.ch >>>> <mailto:roland@rptd.ch>> wrote: >>>> >>>> >>>> *From: *Roland PlÃ¼ss <roland(a)rptd.ch <mailto:roland@rptd.ch>> >>>> *Subject: **Embedding pharo in C++* >>>> *Date: *21 January 2020 at 18:29:04 CET >>>> *To: *Pharo-users(a)lists.pharo.org <mailto:Pharo-users@lists.pharo.org> >>>> >>>> >>>> As the topic title mentions I would like to embed pharo into a >>>> GPL/L-GPL licenses software. >>>> >>>> >>> from the license point of view you can do it freely/Â >>>> >>>> I experimented before with a PoC based on GnuSmalltalk which allows >>>> embedding and this worked but GnuSmalltalk is kinda outdated and >>>> even fails to properly compile since some time. >>>> >>>> For this reason I would like to do another PoC but with Pharo to >>>> see if this would be a candidate to use in the project. >>>> >>> >>> We are really interesting in this experiment.Â >>> We would love that it is possible (I have some doubts but this is >>> important that we learn).Â >>> For exampleÂ >>> -Â you can have an image without UI and it will remove a lot of >>> burden (events and others) >>> - we worked on making Pharo silent (not reading, writing to files - >>> there are certainly some problemsÂ >>> but we should improve).Â >>>> >>>> The application is C++ based but a C interface is fine with me too. >>>> Important is that the Pharo VM is fully controlled by the >>>> application not running a pharo image with a VM binary or things >>>> like that. >>>> >>>> Is this possible and if yes how does it work? >>>> >>> I will let the expert reply to you.Â >>> But what I can tell you is that all the work around the headless vm >>> and the idle are steps in that direction.Â >>> We may not be fully ready now but we would love.Â >>> >>> S.Â >>>> >>>> >>>> -- >>>> Yours sincerely >>>> PlÃ¼ss Roland >>>> >>>> Leader and Head Programmer >>>> - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) >>>> - Game Engine: Drag[en]gine ( >>>> http://www.indiedb.com/engines/dragengine , >>>> http://dragengine.rptd.ch/wiki ) >>>> - As well as various Blender export scripts und game tools >>>> >>>> >>> >>> -------------------------------------------- >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / >>> http://www.pharo.org <http://www.pharo.org/>Â >>> 03 59 35 87 52 >>> Assistant: Julie JonasÂ >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley,Â >>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >> >> -- >> Yours sincerely >> PlÃ¼ss Roland >> >> Leader and Head Programmer >> - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) >> - Game Engine: Drag[en]gine ( >> http://www.indiedb.com/engines/dragengine , >> http://dragengine.rptd.ch/wiki ) >> - As well as various Blender export scripts und game tools >> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.orgÂ > 03 59 35 87 52 > Assistant: Julie JonasÂ > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley,Â > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Yours sincerely PlÃ¼ss Roland Leader and Head Programmer - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine , http://dragengine.rptd.ch/wiki ) - As well as various Blender export scripts und game tools

1 0

Re: [Pharo-users] [Pharo-dev] Short Survey about automatic deprecation rewrites
by ducasse Jan. 21, 2020

Jan. 21, 2020

Thanks! Martin milton juraj should do it too :) S. > On 21 Jan 2020, at 21:34, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > From: Alexandre Bergel <alexandre.bergel(a)me.com> > Subject: Re: [Pharo-dev] Short Survey about automatic deprecation rewrites > Date: 21 January 2020 at 21:34:58 CET > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Just answered! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On 21-01-2020, at 13:23, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Hi all, >> >> We would like to share with you a short survey about the automatic deprecation rewrites that have been around since Pharo 6. >> It will be super useful for us to enhance the support for migrations. >> We estimate it will take ~< 3 minutes to fill. >> >> This survey is aimed at people both *using* Pharo, or writing libraries and frameworks for Pharo. >> If youâre a library/framework maintainer and you know people using your library, would you mind share it with them? >> >> Link to the survey: https://sondages.inria.fr/index.php/133442?lang=en >> >> Thanks a lot! >> Guille, in behalf of the Pharo consortium > > > >

1 0

Short Survey about automatic deprecation rewrites
by Guillermo Polito Jan. 21, 2020

Jan. 21, 2020

Hi all, We would like to share with you a short survey about the automatic deprecation rewrites that have been around since Pharo 6. It will be super useful for us to enhance the support for migrations. We estimate it will take ~< 3 minutes to fill. This survey is aimed at people both *using* Pharo, or writing libraries and frameworks for Pharo. If youâre a library/framework maintainer and you know people using your library, would you mind share it with them? Link to the survey: https://sondages.inria.fr/index.php/133442?lang=en <https://sondages.inria.fr/index.php/133442?lang=en> Thanks a lot! Guille, in behalf of the Pharo consortium

2 1

Re: Embedding pharo in C++
by Roland PlÃ¼ss Jan. 21, 2020

Jan. 21, 2020

Looks like you always meet twice in life I guess. You won't remember me but I've been a student of yours once upon time. Nice to see you again, Prof. Ducasse, I had in mind to have the VM running in two modes actually. The first mode is the "runtime mode". This would be the mode used for the released products and does not allow to "directly modify" the image. This mode would only require basic set of classes (frameworks) since the game engine provides a large set of functionality in the module layer so the script layer provides the logic, UI and things like that. This image would not require to be enriched with a lot of things. The second mode is the "development mode". For this one I thought about exposing a Pharo VM image acting as the Coding and Debugging IDE. Here I would opt to expose the full power of Pharo/Smalltalk to the developer. Does this sound feasible in the way PharoVM is designed? > >> On 21 Jan 2020, at 18:29, Roland PlÃ¼ss <roland(a)rptd.ch >> <mailto:roland@rptd.ch>> wrote: >> >> >> *From: *Roland PlÃ¼ss <roland(a)rptd.ch <mailto:roland@rptd.ch>> >> *Subject: **Embedding pharo in C++* >> *Date: *21 January 2020 at 18:29:04 CET >> *To: *Pharo-users(a)lists.pharo.org <mailto:Pharo-users@lists.pharo.org> >> >> >> As the topic title mentions I would like to embed pharo into a >> GPL/L-GPL licenses software. >> >> > from the license point of view you can do it freely/Â >> >> I experimented before with a PoC based on GnuSmalltalk which allows >> embedding and this worked but GnuSmalltalk is kinda outdated and even >> fails to properly compile since some time. >> >> For this reason I would like to do another PoC but with Pharo to see >> if this would be a candidate to use in the project. >> > > We are really interesting in this experiment.Â > We would love that it is possible (I have some doubts but this is > important that we learn).Â > For exampleÂ > -Â you can have an image without UI and it will remove a lot of burden > (events and others) > - we worked on making Pharo silent (not reading, writing to files - > there are certainly some problemsÂ > but we should improve).Â >> >> The application is C++ based but a C interface is fine with me too. >> Important is that the Pharo VM is fully controlled by the application >> not running a pharo image with a VM binary or things like that. >> >> Is this possible and if yes how does it work? >> > I will let the expert reply to you.Â > But what I can tell you is that all the work around the headless vm > and the idle are steps in that direction.Â > We may not be fully ready now but we would love.Â > > S.Â >> >> >> -- >> Yours sincerely >> PlÃ¼ss Roland >> >> Leader and Head Programmer >> - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) >> - Game Engine: Drag[en]gine ( >> http://www.indiedb.com/engines/dragengine , >> http://dragengine.rptd.ch/wiki ) >> - As well as various Blender export scripts und game tools >> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.orgÂ > 03 59 35 87 52 > Assistant: Julie JonasÂ > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley,Â > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Yours sincerely PlÃ¼ss Roland Leader and Head Programmer - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine , http://dragengine.rptd.ch/wiki ) - As well as various Blender export scripts und game tools

1 0