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

Re: [Pharo-users] How to use frameworks like SDL2, GTK+ with Pharo?

by phil＠highoctane.be

Image environment is not running on SDL2. SDL2 is a binding that is in image. An SFML binding is cool to do, especially CSFML. https://www.sfml-dev.org/download/csfml/ I want to do these in Bloc https://www.youtube.com/playlist?list=PLB_ibvUSN7mzUffhiay5g5GUHyJRO4DYr But CSFML is cool to do too. And I also want a binding to https://github.com/cmatsuoka/libxmp Phil On Tue, Jun 13, 2017 at 6:55 PM, Daniel Passaro <danpassaro(a)gmail.com> wrote: > Even if the image environment runs on SDL2, I want an SDL2 window I have > free reign to draw on. I don't want to destroy the usability of the Pharo > workspace when programming an application. If that is still too > contentious, then I want SFML instead. > > The story of GTK+ is what I'm interested in. > > On Tue, Jun 13, 2017 at 12:48 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> SDL2 is built in. >> >> GTK+ is another story. >> >> Phil >> >> On Tue, Jun 13, 2017 at 6:38 PM, Daniel Passaro <danpassaro(a)gmail.com> >> wrote: >> >>> I'm a Pharo newbie. How can I use libraries like SDL2 or GTK+ from >>> Pharo? Should this be done through FFI or a VM plugin? And in either case >>> is there a guide to how to implement things using that technique? >>> >> >> >

June 13, 2017

Re: [Pharo-users] How to use frameworks like SDL2, GTK+ with Pharo?

by Dimitris Chloupis

On Tue, Jun 13, 2017 at 7:39 PM Daniel Passaro <danpassaro(a)gmail.com> wrote: > I'm a Pharo newbie. How can I use libraries like SDL2 or GTK+ from Pharo? > Should this be done through FFI or a VM plugin? And in either case is > there a guide to how to implement things using that technique? > If you know python, because python has wrappers for pretty much any library out there, i made a pharo library that allows for remote and local execution of python code from inside pharo. Its not perfect but it will give you access to pretty much any library out there because python is very popular. The library is called Atlas , its available from the Package/Catalog browser and requires that you have installed the library you want to use , python 3 and wrappers for python for that library. Third one may be optional because some library come with python wrappers included. If you need any help , I am here. You can use also Atlas as the basis for supporting other languages all you need is a language that can dynamically execute code (usually dynamic languages like python) and support for sockets (sockets are supported in almost all languages). UFFI is the official way of interfacing with C libraries , but C is difficult to manage , very difficult to debug but gives top performance. If the library is made in C++ UFFI cannot access it immediately the library has to be compiled without name mangling.

June 13, 2017

Re: [Pharo-users] How to use frameworks like SDL2, GTK+ with Pharo?

by Ben Coman

On Wed, Jun 14, 2017 at 12:38 AM, Daniel Passaro <danpassaro(a)gmail.com> wrote: > I'm a Pharo newbie. How can I use libraries like SDL2 or GTK+ from Pharo? > Should this be done through FFI or a VM plugin? And in either case is > there a guide to how to implement things using that technique? > I'm nto familiar with the interface from Pharo, but I believe the dark window opened in this video... https://www.youtube.com/watch?v=lABfEmToHLQ is a native window via SDL2, outside of the standard Pharo window - if that is what you are lookign for. Probably FFI is the easier path. Its how Pharo uses SDL2. There is an incomplete tutorial here... http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-1-preamble/ btw, I just noticed the "UniffiedFFI chapter" link from that post has broke. I guess the doc has moved here... https://github.com/SquareBracketAssociates/Booklet-uFFI but I can't find a PDF there. cheers -ben

June 13, 2017

Re: [Pharo-users] How to use frameworks like SDL2, GTK+ with Pharo?

by Daniel Passaro

Even if the image environment runs on SDL2, I want an SDL2 window I have free reign to draw on. I don't want to destroy the usability of the Pharo workspace when programming an application. If that is still too contentious, then I want SFML instead. The story of GTK+ is what I'm interested in. On Tue, Jun 13, 2017 at 12:48 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > SDL2 is built in. > > GTK+ is another story. > > Phil > > On Tue, Jun 13, 2017 at 6:38 PM, Daniel Passaro <danpassaro(a)gmail.com> > wrote: > >> I'm a Pharo newbie. How can I use libraries like SDL2 or GTK+ from Pharo? >> Should this be done through FFI or a VM plugin? And in either case is >> there a guide to how to implement things using that technique? >> > >

June 13, 2017

Re: [Pharo-users] How to use frameworks like SDL2, GTK+ with Pharo?

by phil＠highoctane.be

SDL2 is built in. GTK+ is another story. Phil On Tue, Jun 13, 2017 at 6:38 PM, Daniel Passaro <danpassaro(a)gmail.com> wrote: > I'm a Pharo newbie. How can I use libraries like SDL2 or GTK+ from Pharo? > Should this be done through FFI or a VM plugin? And in either case is > there a guide to how to implement things using that technique? >

June 13, 2017

How to use frameworks like SDL2, GTK+ with Pharo?

by Daniel Passaro

I'm a Pharo newbie. How can I use libraries like SDL2 or GTK+ from Pharo? Should this be done through FFI or a VM plugin? And in either case is there a guide to how to implement things using that technique?

June 13, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by Esteban A. Maringolo

2017-06-13 7:39 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > Phil - to be clear, I think your underlying implementation is great - it > provides a great building block. > > However, just as with databases, when you build something higher level on > top - the question comes up about how much you hide that retrieval > mechanism. The GTInspector argument is an interesting one from a pure domain > understanding - and possibly armed with the underlying piping you have > provided, it is then up to me to layer my understanding of the higher level > model on top. > > I perhaps should look at glorp a bit more carefully as maybe there is > inspiration there. Let's talk on the Discourse chat about this, but as a short description, Glorp has a Facade object (the GlorpSession) that knows how to delegate most actions to internal parts. But objects don't "know" the session they belong to, because the ORM is orthogonal to the domain model. Esteban A. Maringolo

June 13, 2017

Re: [Pharo-users] PharoDays17 Slides and some Videos

by Marcus Denker

We have now 9 more videos in the playlist: https://www.youtube.com/playlist?list=PL4actYd6bfnw7ous5We-XnWq0NZquP3gM > On 7 Jun 2017, at 16:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > I have uploaded the Slides and Videos of PharoDays2017. Slides are complete (minus those > talks that were due demos). For the Videos we have right now 8 talks and the âShow Us Your > Projectâ session. More might come in the future (I need to check). > > Slides: > - https://www.slideshare.net/pharoproject/presentations > - http://files.pharo.org/conferences/2017PharoDays/ > > PlayList: https://www.youtube.com/playlist?list=PL4actYd6bfnw7ous5We-XnWq0NZquP3gM >

June 13, 2017

Re: [Pharo-users] Test request

by Hilaire

Thanks John, it is useful. Regarding the French in Dr. Geo, I guess you mean the activity in the canvas is written in French but the Dr. Geo's UI should be in English. Hilaire Le 13/06/2017 Ã 05:21, john pfersich a Ã©crit : > I followed the steps in your mail and it seems to work fine in Ubuntu > 16.04 LTS, though I've never tried Dr Geo and the app is mostly in > French. It's been 47 years since I've used French extensively, so YMMV. > Let you know if I have problems. > -- Dr. Geo http://drgeo.eu

June 13, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by Tim Mackinnon

Phil - to be clear, I think your underlying implementation is great - it provides a great building block. However, just as with databases, when you build something higher level on top - the question comes up about how much you hide that retrieval mechanism. The GTInspector argument is an interesting one from a pure domain understanding - and possibly armed with the underlying piping you have provided, it is then up to me to layer my understanding of the higher level model on top. I perhaps should look at glorp a bit more carefully as maybe there is inspiration there. Tim > On 12 Jun 2017, at 20:53, phil(a)highoctane.be wrote: > > A dynamic variable could work too. > > But domain objects are somewhat hard to do in my view because we are dealing with an API that has tons of options and customizability in its results + people can define their own types and fields. > > That's why I went for a JiraBuilder thing that has a reference to a Jira instance. > That builder is allowing one to make higher level queries for the users (like doing Epics, Stories, links, custom fields resolution, meta data grabbing, prototype creation etc). > > I didn't want to have an Epic class, a Story class, etc. Because my idea of an Epic may not be your idea, so we may end up with a PluggableEpic etc and it will never end. > > My take is that it is better to use the vocabulary of the domain in the method names but still work with dynamic structures like dictionaries and some helpers. > > I am still curious to see those domain objects because I understand that they would ease inspection etc. > > Maybe we should have a generator for these so that we can regenerate the classes based on the metadata provided by Jira. > > Phil > > On Mon, Jun 12, 2017 at 9:28 PM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > Hello Tim, > > 2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > > Hi - Iâm after some ideas or maybe previous examples that might guide me in the best approach of wrapping a low level library (essentially the Jira connector that Phil demoâd at Pharo days this year). > > > > There are some low level commands that will fetch json arrays for you given a âliraâ instance- e.g: > > > > board := JiraBoard fromJira: jira named: âProject'. > > sprints := board sprintsFrom: jira. > > > > My question is related to building on top of this - and its a style question. > > > > I want model objects that wrap the json arrays and let me navigate things a bit more simply, and query details more naturally - however I canât decide whether my model objects should âcontainâ a jira when you instantiate them - which can be re-used for subsequent queries - OR - whether I should view jira as a from of context, and keep passing it to methods when I need to retrieve more details, or child objects? > > > > e.g. > > myBoard := ModelBoard fromJira: jira named: âProjectâ. > > mySprints := myBoard sprints. âNo need to pass the jira againâ. > > > > vs. > > > > mySprints :- myBoard sprintsIn: jira. > > > > > > Iâm wondering if anything might guide me one way or the other? Is one more tasteful/elegant than the other? > > > I'd go for the first option. It is, every JIRA object knows the "jira" > it belongs to. > > Although the second option is better for decoupling, not having to > pass objects around to obtain properties allows you to better > integrate with the tools (think GTInspector with specific inspector > for cards). > > I don't understand what the "jira" is exactly, if a whole JSON object > (a Dictionary) containing everything, a connection to JIRA API, or > just the JSON object/Dictionary branch containing the attributes > specific of the "wraping" object (the board, in this case). > > Regards! > > Esteban A. Maringolo > > >

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by phil＠highoctane.be

On Tue, Jun 13, 2017 at 11:34 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil(a)highoctane.be wrote: > > I need to upgrade to 16.04 now :-) > > :-) > > Don't forget you can install snapd on Ubuntu 14.04: > > https://snapcraft.io/docs/core/install-ubuntu > > Ah, wasn't aware of that. Thx Alistair! Phil > Cheers, > Alistair > > > > Phil > > > > On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > > > > THANKS A LOT ALISTAIR. > > I mean it :) > > > > On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant < > akgrant0710(a)gmail.com> > > wrote: > > > Hi Everyone, > > > > > > I've updated the Pharo 6 snap package for Ubuntu. > > > > > > The major advantages of using the snap package are: > > > > > > - No need to install all the 32 bit dependencies on a 64 bit > system, > > > they're all contained and isolated within the snap package. > > > - Automagically distinguish between 32 bit and 64 bit images and > run the > > > appropriate VM (as with the ZeroConf package, the 64 bit VM still > > > needs more testing). > > > > > > > > > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > > > > > # Install Pharo > > > $ sudo snap install --candidate pharo --classic > > > # If your system isn't configured for threaded heartbeat: > > > $ sudo pharo.config > > > # Download the latest Pharo 6 image > > > $ pharo.getimage > > > # Go... > > > $ pharo.ui Pharo.image > > > # or: > > > $ pharo Pharo.image eval 4+3 > > > > > > To get a list of available commands: > > > > > > $ snap info pharo > > > > > > > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, > see > > > https://snapcraft.io/docs/core/install > > > > > > > > > The VM is the threaded heartbeat, dated 201705310241. > > > > > > The installation flags are: > > > > > > --candidate - The edge and beta channels are for development > versions. > > > It progresses to candidate and then stable. > > > --classic - Snap packages are normally sandboxed for security > > > reasons. Since Pharo is a development environment > > > in which we want to be able to run any executable, > > > or load any library, it is installed with access to > > > the entire system (as the running user). > > > > > > Why use snap packages? > > > > > > - They include all dependencies. In particular, for the 32 bit > > > versions, this means that it isn't necessary to install all the > 32 bit > > > architecture and associated dependencies. > > > - Including dependencies means that there shouldn't be any > problems with > > > incompatible library versions when upgrading. > > > > > > Why not use snap packages? > > > > > > - It's a relatively new technology, with a number of rough edges. > > > - There may still be issues with its sandboxing that I haven't > > > discovered yet. > > > - Because the package uses classic confinement, it isn't > > > cross-distribution in practice (unfortunately). > > > > > > Please let me know of any other advantages or disadvantages you > think > > > should be listed here. > > > > > > If you don't trust me to configure your system correctly (which > requires > > > sudo): > > > > > > - All the scripts that make up the sub-commands are visible, e.g. > > > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > > > > > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > > > > > > > Cheers, > > > Alistair > > >

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by Alistair Grant

On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil(a)highoctane.be wrote: > I need to upgrade to 16.04 now :-) :-) Don't forget you can install snapd on Ubuntu 14.04: https://snapcraft.io/docs/core/install-ubuntu Cheers, Alistair > Phil > > On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > THANKS A LOT ALISTAIR. > I mean it :) > > On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > Hi Everyone, > > > > I've updated the Pharo 6 snap package for Ubuntu. > > > > The major advantages of using the snap package are: > > > > - No need to install all the 32 bit dependencies on a 64 bit system, > > they're all contained and isolated within the snap package. > > - Automagically distinguish between 32 bit and 64 bit images and run the > > appropriate VM (as with the ZeroConf package, the 64 bit VM still > > needs more testing). > > > > > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > > > # Install Pharo > > $ sudo snap install --candidate pharo --classic > > # If your system isn't configured for threaded heartbeat: > > $ sudo pharo.config > > # Download the latest Pharo 6 image > > $ pharo.getimage > > # Go... > > $ pharo.ui Pharo.image > > # or: > > $ pharo Pharo.image eval 4+3 > > > > To get a list of available commands: > > > > $ snap info pharo > > > > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > > https://snapcraft.io/docs/core/install > > > > > > The VM is the threaded heartbeat, dated 201705310241. > > > > The installation flags are: > > > > --candidate - The edge and beta channels are for development versions. > > It progresses to candidate and then stable. > > --classic - Snap packages are normally sandboxed for security > > reasons. Since Pharo is a development environment > > in which we want to be able to run any executable, > > or load any library, it is installed with access to > > the entire system (as the running user). > > > > Why use snap packages? > > > > - They include all dependencies. In particular, for the 32 bit > > versions, this means that it isn't necessary to install all the 32 bit > > architecture and associated dependencies. > > - Including dependencies means that there shouldn't be any problems with > > incompatible library versions when upgrading. > > > > Why not use snap packages? > > > > - It's a relatively new technology, with a number of rough edges. > > - There may still be issues with its sandboxing that I haven't > > discovered yet. > > - Because the package uses classic confinement, it isn't > > cross-distribution in practice (unfortunately). > > > > Please let me know of any other advantages or disadvantages you think > > should be listed here. > > > > If you don't trust me to configure your system correctly (which requires > > sudo): > > > > - All the scripts that make up the sub-commands are visible, e.g. > > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > > > > Cheers, > > Alistair

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by Alistair Grant

On Tue, Jun 13, 2017 at 08:58:31AM +0000, Alistair Grant wrote: > Hi Everyone, > > I've updated the Pharo 6 snap package for Ubuntu. > > The major advantages of using the snap package are: > > - No need to install all the 32 bit dependencies on a 64 bit system, > they're all contained and isolated within the snap package. > - Automagically distinguish between 32 bit and 64 bit images and run the > appropriate VM (as with the ZeroConf package, the 64 bit VM still > needs more testing). > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > # Install Pharo > $ sudo snap install --candidate pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage I should have added if you want the 32 bit image: $ pharo.getimage32 the rest remains the same > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201705310241. > > The installation flags are: > > --candidate - The edge and beta channels are for development versions. > It progresses to candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > Please let me know of any other advantages or disadvantages you think > should be listed here. > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > Cheers, > Alistair

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by phil＠highoctane.be

I need to upgrade to 16.04 now :-) Phil On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > THANKS A LOT ALISTAIR. > I mean it :) > > On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > Hi Everyone, > > > > I've updated the Pharo 6 snap package for Ubuntu. > > > > The major advantages of using the snap package are: > > > > - No need to install all the 32 bit dependencies on a 64 bit system, > > they're all contained and isolated within the snap package. > > - Automagically distinguish between 32 bit and 64 bit images and run the > > appropriate VM (as with the ZeroConf package, the 64 bit VM still > > needs more testing). > > > > > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > > > # Install Pharo > > $ sudo snap install --candidate pharo --classic > > # If your system isn't configured for threaded heartbeat: > > $ sudo pharo.config > > # Download the latest Pharo 6 image > > $ pharo.getimage > > # Go... > > $ pharo.ui Pharo.image > > # or: > > $ pharo Pharo.image eval 4+3 > > > > To get a list of available commands: > > > > $ snap info pharo > > > > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > > https://snapcraft.io/docs/core/install > > > > > > The VM is the threaded heartbeat, dated 201705310241. > > > > The installation flags are: > > > > --candidate - The edge and beta channels are for development versions. > > It progresses to candidate and then stable. > > --classic - Snap packages are normally sandboxed for security > > reasons. Since Pharo is a development environment > > in which we want to be able to run any executable, > > or load any library, it is installed with access to > > the entire system (as the running user). > > > > Why use snap packages? > > > > - They include all dependencies. In particular, for the 32 bit > > versions, this means that it isn't necessary to install all the 32 bit > > architecture and associated dependencies. > > - Including dependencies means that there shouldn't be any problems with > > incompatible library versions when upgrading. > > > > Why not use snap packages? > > > > - It's a relatively new technology, with a number of rough edges. > > - There may still be issues with its sandboxing that I haven't > > discovered yet. > > - Because the package uses classic confinement, it isn't > > cross-distribution in practice (unfortunately). > > > > Please let me know of any other advantages or disadvantages you think > > should be listed here. > > > > If you don't trust me to configure your system correctly (which requires > > sudo): > > > > - All the scripts that make up the sub-commands are visible, e.g. > > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > > > > Cheers, > > Alistair > > > > >

June 13, 2017

Re: [Pharo-users] [ANN] Pharo 6.0 released!

by Stephane Ducasse

Us too :) On Wed, Jun 7, 2017 at 8:20 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Great news! Thanks to Esteban and the 80+ contributors. > > I have multiple patches waiting for the 7.0 dev cycle to begin. Can't > wait... :-) > > Cheers, > Alistair > > > On 6 June 2017 at 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Dear World, >> >> The time has come for Pharo 6.0! >> >> Pharo is a pure object-oriented programming language and a powerful >> environment, focused on simplicity and immediate feedback. >> >> This is our most significant release yet. Here are some highlights: >> >> - Pharo is now provided in 64-bit version in Linux and OSX and brings even >> better performance and stability (beware, 64bits version is a new technology >> and a small amount of tests is still failing) >> - A new code changes management system named Epicea for easier reviewing and >> recovering of your code easily >> - Integrated support for Git through an easy-to-use tool for repositories >> and commits management named Iceberg (as a preview for Pharo 6, it will be >> the default in Pharo 7) >> - The unified foreign function interface (UnifiedFFI) for interfacing with >> the outside world is significantly improved >> - The PharoVM is now part of OpenSmalltalk initiative >> - Introduction of object immutability, alternative bytecode sets and block >> closures independent of outer context >> - Pharo can now be bootstrapped from source code managed by Git >> - Pharo modularity is improved >> - Pharo is faster >> - The Dark Theme was improved and set as default color theme of Pharo >> >> >> These are just the more prominent highlights, but the details are just as >> important. We have closed 1474 issues in Pharo 6.0 (a more complete >> changelog can be found at >> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60Change…) >> >> While the technical improvements are significant (starting the transition to >> 64bits is a remarkable achievement), still the most impressive fact is that >> the new code that got in the main Pharo 6.0 image was contributed by more >> than 80 people. >> >> Pharo is more than code. It is an exciting project involving energetic >> people. We thank all the contributors of this release: >> >> Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, >> Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard Pieber, >> Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, Dale >> Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, Dirk >> Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan >> Donahue, Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo >> Polito, Gustavo Santos, Henrik Johansen, Henrik Nergaard, Hilaire Fernandes, >> Holger Hans, Jan Kurs, Jan van de Sandt, Johan Fabry, Juraj Kubelka, K. K. >> Subramaniam, Ken Causey, Kris Gybels, Lionel Akue, Luc Fabresse, Lucas >> Godoy, Marcus Denker, Mariano Martinez Peck, Marion Noirbent, Martin Dias, >> Max Leske, Maxime Roelandt, Merwan Ouddane, Matteo Bellotto, Miguel >> Campusano, Milton Mamani, Myroslava Romaniuk, Nicolai Hess, Nicolas Cellier, >> Nicolas Passerini, Norbert Hartl, Offray Luna, Pablo Tesone, Paul De >> Bruicker, Pavel Krivanek, Peter Uhnak, Philippe Back, Roger Stebler, Ronie >> Salgado, Sean DeNigris, Serge Stinckwich, Skip Lentz, Sophie Kaleba, Stefan >> Reichhart, Stephan Eggermont, Stephane Ducasse, Sven Van Caekenberghe, >> Thibault Arloing, Thibault Arloing, Thibault Raffaillac, Thierry Goubier, >> Thomas Heniart, Tommaso Dal Sasso, Torsten Bergmann, Tudor Girba, Udo >> Schneider, Valentin Ryckewaert, Vincent Blondeau, Werner Kassens, Yuriy >> Tymchuk >> >> (If you contributed with Pharo 6.0 development in any way and we missed your >> name, please send us a mail and we will add you). >> >> Enjoy! >> >> The Pharo Team >> >> Try Pharo: http://pharo.org/download >> Learn Pharo: http://pharo.org/documentation >

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by Stephane Ducasse

THANKS A LOT ALISTAIR. I mean it :) On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Everyone, > > I've updated the Pharo 6 snap package for Ubuntu. > > The major advantages of using the snap package are: > > - No need to install all the 32 bit dependencies on a 64 bit system, > they're all contained and isolated within the snap package. > - Automagically distinguish between 32 bit and 64 bit images and run the > appropriate VM (as with the ZeroConf package, the 64 bit VM still > needs more testing). > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > # Install Pharo > $ sudo snap install --candidate pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201705310241. > > The installation flags are: > > --candidate - The edge and beta channels are for development versions. > It progresses to candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > Please let me know of any other advantages or disadvantages you think > should be listed here. > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > Cheers, > Alistair >

June 13, 2017

Pharo 6 snap package

by Alistair Grant

Hi Everyone, I've updated the Pharo 6 snap package for Ubuntu. The major advantages of using the snap package are: - No need to install all the 32 bit dependencies on a 64 bit system, they're all contained and isolated within the snap package. - Automagically distinguish between 32 bit and 64 bit images and run the appropriate VM (as with the ZeroConf package, the 64 bit VM still needs more testing). To get Pharo up and running on Ubuntu 16.04 or later: # Install Pharo $ sudo snap install --candidate pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3 To get a list of available commands: $ snap info pharo If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install The VM is the threaded heartbeat, dated 201705310241. The installation flags are: --candidate - The edge and beta channels are for development versions. It progresses to candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user). Why use snap packages? - They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading. Why not use snap packages? - It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately). Please let me know of any other advantages or disadvantages you think should be listed here. If you don't trust me to configure your system correctly (which requires sudo): - All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG The packaging code is at: https://github.com/akgrant43/pharo-snap Cheers, Alistair

June 13, 2017

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by aryehof

Consider that in Java, one can /only /achieve polymorphic behavior across objects by using /interfaces /or /inheritance/. In Smalltalk one can achieve polymorphic behavior across objects just by *having them understand the same message*. The need to have complex schemes for the wiring of objects in Java is a consequence of this. -- View this message in context: http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4951… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 13, 2017

Re: [Pharo-users] Help in thinking about how to save a "program"

by Ben Coman

On Mon, Jun 12, 2017 at 7:22 AM, Glenn Hoetker <ghoetker(a)me.com> wrote: > Hi all. Iâm new to Pharo and loving it. As I transition from a text-file > based mindset, Iâm a little stuck and would appreciate help in how to think > about a situation in a Pharonic (Pharo-ish, Pharoc?) way. > > Iâm crafting a short program to help me process a large text file > (specifically: extract, sorting, and regularizing the âkeywordâ fields of a > large BibTex file). Especially since I donât really know what Iâm doing, > working in a Playground has been a great development environment. Now that > the program is complete (under 30 lines, wonderful), I want to be able to > save it for future reference (and perhaps for future use). If Iâd written > a shell script, Iâd just save âfixBibDeskKeyWords.shâ to a directory. Iâm > not sure what to do in the Pharo environment, thought. > > At the moment, it just lives in the Playground Iâve developed it on. I > could save the image and leave that Playground open, but Iâm just positive > thatâs not a best practice. I also worry about what happens if I > closed/cleared that Playground by accident. > > I think I understand that, if I created a new package, I could use > Monticello to save it to a local cache and load it into a new image > whenever I needed it. But, given that itâs short, highly specialized and > fairly linear, the idea of creating a âGHBibDeskStuffâ package with one > class (âGBibDeskKeywordFixerâ containing a single âFixFileâ method seems > really heavy and awkward. > > Can one save the contents of a Playground in a Pharonic way? Is there a > better approach? > > Thank you to all involved in this wonderful programming ecosystem. I > appreciate any advice. > Great to hear you are enjoying Pharo. The heavy part of saving to disk as a Monticello package is an optional secondary step, but to make you code "permanent" in the image you do need a class to hang it on, and a package to hold that. Doing this only in-Image is quite light and quick to do, and makes it easy to find later. In a System Browser create package "GHBibDeskStuff", class GBibDeskKeywordFixer. Create your method so you can use it from playground like this... GBibDeskKeywordFixer new fixFile. Then to the class side of GBibDeskKeywordFixer also add a method #fixFile like this... GBibDeskKeywordFixer class >> fixFile self new fixFile. so that from playground you can drop the "new" and use it like this... GBibDeskKeywordFixer fixFile Feels like you've added a new command to Pharo? Note that "GBibDeskKeywordFixer class >>" is just a documentation convention indicating you should click the <Class> button to add a method to the class-side. cheers -ben

June 13, 2017

Re: [Pharo-users] Help in thinking about how to save a "program"

by Benoit St-Jean

Hi Glenn, Another very useful tool you can use to save/manipulate/store Smalltalk scripts is ScriptManager (http://catalog.pharo.org/catalog/project/ScriptManager) Â There are plenty of similar tools but this one is very easy to use and simple and has been doing the job for years for me. hthÂ ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) From: Glenn Hoetker <ghoetker(a)me.com> To: pharo-users(a)lists.pharo.org Sent: Sunday, June 11, 2017 7:23 PM Subject: [Pharo-users] Help in thinking about how to save a "program" Hi all. Â Iâm new to Pharo and loving it. Â As I transition from a text-file based mindset, Iâm a little stuck and would appreciate help in how to think about a situation in a Pharonic (Pharo-ish, Pharoc?) way. Iâm crafting a short program to help me process a large text file (specifically: extract, sorting, and regularizing the âkeywordâ fields of a large BibTex file). Especially since I donât really know what Iâm doing, working in a Playground has been a great development environment. Â Now that the program is complete (under 30 lines, wonderful), I want to be able to save it for future reference (and perhaps for future use). Â If Iâd written a shell script, Iâd just save âfixBibDeskKeyWords.shâ to a directory. Iâm not sure what to do in the Pharo environment, thought. At the moment, it just lives in the Playground Iâve developed it on. Â I could save the image and leave that Playground open, but Iâm just positive thatâs not a best practice. I also worry about what happens if I closed/cleared that Playground by accident. I think I understand that, if I created a new package, I could use Monticello to save it to a local cache and load it into a new image whenever I needed it. Â But, given that itâs short, highly specialized and fairly linear, the idea of creating a âGHBibDeskStuffâ package with one class (âGBibDeskKeywordFixerâ containing a single âFixFileâ method seems really heavy and awkward. Can one save the contents of a Playground in a Pharonic way? Â Is there a better approach? Thank you to all involved in this wonderful programming ecosystem. I appreciate any advice. Glenn Glenn Hoetkerghoetker@me.comhttp://hoetker.faculty.asu.edu

June 13, 2017

Re: [Pharo-users] Test request

by john pfersich

I followed the steps in your mail and it seems to work fine in Ubuntu 16.04 LTS, though I've never tried Dr Geo and the app is mostly in French. It's been 47 years since I've used French extensively, so YMMV. Let you know if I have problems. On Mon, Jun 12, 2017 at 12:59 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > > A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do > not meet on my 12.04 config. It seems related to Cairo or FreeType. I > will likely update my system on 16.04 later this summer, but I can't > just tweak it as this is the end of the school year with several admin > tasks to conduct. > > Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and > report to me any problem? > > If so, here is what to do: > > 1. Download and unzip > https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip > > 2. Adjust system to 32 bits compatibility if necessary, follow > instructions at > http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 > > 3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the > zip file at > https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0 > > Does it went fine? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >

June 13, 2017

Test request

by Hilaire

Hi, A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do not meet on my 12.04 config. It seems related to Cairo or FreeType. I will likely update my system on 16.04 later this summer, but I can't just tweak it as this is the end of the school year with several admin tasks to conduct. Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and report to me any problem? If so, here is what to do: 1. Download and unzip https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip 2. Adjust system to 32 bits compatibility if necessary, follow instructions at http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the zip file at https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0 Does it went fine? Thanks Hilaire -- Dr. Geo http://drgeo.eu

June 12, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by phil＠highoctane.be

A dynamic variable could work too. But domain objects are somewhat hard to do in my view because we are dealing with an API that has tons of options and customizability in its results + people can define their own types and fields. That's why I went for a JiraBuilder thing that has a reference to a Jira instance. That builder is allowing one to make higher level queries for the users (like doing Epics, Stories, links, custom fields resolution, meta data grabbing, prototype creation etc). I didn't want to have an Epic class, a Story class, etc. Because my idea of an Epic may not be your idea, so we may end up with a PluggableEpic etc and it will never end. My take is that it is better to use the vocabulary of the domain in the method names but still work with dynamic structures like dictionaries and some helpers. I am still curious to see those domain objects because I understand that they would ease inspection etc. Maybe we should have a generator for these so that we can regenerate the classes based on the metadata provided by Jira. Phil On Mon, Jun 12, 2017 at 9:28 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hello Tim, > > 2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > > Hi - Iâm after some ideas or maybe previous examples that might guide me > in the best approach of wrapping a low level library (essentially the Jira > connector that Phil demoâd at Pharo days this year). > > > > There are some low level commands that will fetch json arrays for you > given a âliraâ instance- e.g: > > > > board := JiraBoard fromJira: jira named: âProject'. > > sprints := board sprintsFrom: jira. > > > > My question is related to building on top of this - and its a style > question. > > > > I want model objects that wrap the json arrays and let me navigate > things a bit more simply, and query details more naturally - however I > canât decide whether my model objects should âcontainâ a jira when you > instantiate them - which can be re-used for subsequent queries - OR - > whether I should view jira as a from of context, and keep passing it to > methods when I need to retrieve more details, or child objects? > > > > e.g. > > myBoard := ModelBoard fromJira: jira named: âProjectâ. > > mySprints := myBoard sprints. âNo need to pass the jira againâ. > > > > vs. > > > > mySprints :- myBoard sprintsIn: jira. > > > > > > Iâm wondering if anything might guide me one way or the other? Is one > more tasteful/elegant than the other? > > > I'd go for the first option. It is, every JIRA object knows the "jira" > it belongs to. > > Although the second option is better for decoupling, not having to > pass objects around to obtain properties allows you to better > integrate with the tools (think GTInspector with specific inspector > for cards). > > I don't understand what the "jira" is exactly, if a whole JSON object > (a Dictionary) containing everything, a connection to JIRA API, or > just the JSON object/Dictionary branch containing the attributes > specific of the "wraping" object (the board, in this case). > > Regards! > > Esteban A. Maringolo > > >

June 12, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by Esteban A. Maringolo

Hello Tim, 2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > Hi - Iâm after some ideas or maybe previous examples that might guide me in the best approach of wrapping a low level library (essentially the Jira connector that Phil demoâd at Pharo days this year). > > There are some low level commands that will fetch json arrays for you given a âliraâ instance- e.g: > > board := JiraBoard fromJira: jira named: âProject'. > sprints := board sprintsFrom: jira. > > My question is related to building on top of this - and its a style question. > > I want model objects that wrap the json arrays and let me navigate things a bit more simply, and query details more naturally - however I canât decide whether my model objects should âcontainâ a jira when you instantiate them - which can be re-used for subsequent queries - OR - whether I should view jira as a from of context, and keep passing it to methods when I need to retrieve more details, or child objects? > > e.g. > myBoard := ModelBoard fromJira: jira named: âProjectâ. > mySprints := myBoard sprints. âNo need to pass the jira againâ. > > vs. > > mySprints :- myBoard sprintsIn: jira. > > > Iâm wondering if anything might guide me one way or the other? Is one more tasteful/elegant than the other? I'd go for the first option. It is, every JIRA object knows the "jira" it belongs to. Although the second option is better for decoupling, not having to pass objects around to obtain properties allows you to better integrate with the tools (think GTInspector with specific inspector for cards). I don't understand what the "jira" is exactly, if a whole JSON object (a Dictionary) containing everything, a connection to JIRA API, or just the JSON object/Dictionary branch containing the attributes specific of the "wraping" object (the board, in this case). Regards! Esteban A. Maringolo

June 12, 2017

A question of style - pass a context or embed one?

by Tim Mackinnon

Hi - Iâm after some ideas or maybe previous examples that might guide me in the best approach of wrapping a low level library (essentially the Jira connector that Phil demoâd at Pharo days this year). There are some low level commands that will fetch json arrays for you given a âliraâ instance- e.g: board := JiraBoard fromJira: jira named: âProject'. sprints := board sprintsFrom: jira. My question is related to building on top of this - and its a style question. I want model objects that wrap the json arrays and let me navigate things a bit more simply, and query details more naturally - however I canât decide whether my model objects should âcontainâ a jira when you instantiate them - which can be re-used for subsequent queries - OR - whether I should view jira as a from of context, and keep passing it to methods when I need to retrieve more details, or child objects? e.g. myBoard := ModelBoard fromJira: jira named: âProjectâ. mySprints := myBoard sprints. âNo need to pass the jira againâ. vs. mySprints :- myBoard sprintsIn: jira. Iâm wondering if anything might guide me one way or the other? Is one more tasteful/elegant than the other? Tim

June 12, 2017