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

Re: [Pharo-users] [Pharo-dev] [ann] bloc & cairo+morphic

by Torsten Bergmann

When I try to download on OSX the #dev version as outlined on Tudors blog the download of the Moz2D lib for OSX fails: code tries to #download in class MozLibraryMacInstaller from http://syrel.ch/download.php?url=https://dl.bintray.com/syrel/Moz2D/osx/dev… which just hangs as it is not receiving a response. Any comments? Thx T. > Gesendet: Dienstag, 09. Mai 2017 um 14:04 Uhr > Von: "Alexandre Bergel" <alexandre.bergel(a)me.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: "Moose-related development" <moose-dev(a)list.inf.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] [ann] bloc & cairo+morphic > > This is amazing! I gave a try an it really looks great! > > Alexandre > > > > On May 8, 2017, at 6:00 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > We are happy to announce that based on the work of Glenn, Alex extended Bloc (Sparta) to work directly in the Morphic world using Cairo as a backend. > > > > Cairo is less powerful than Moz2D (see the screenshot below for an example), but the implementation addresses a concern that the community raised regarding a perceived increased liability due to the dependency to Moz2D. Essentially this means that Bloc can be treated as another graphical library that can coexist with Morphic without requiring any external VM plugin. > > > > <bloc-two-backends-morphic-host-figures.png> > > > > I would also like to point out that adding a new backend and host was possible because of the many iterations (including throwing away whole implementations) that Alex and Glenn went through. I think they did an amazing job. > > > > You can find a bit more details about Bloc here: > > http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/ > > > > Another issue raised regarding Bloc was that of the engineering effort required to make it a reality. That is why I would also like to announce that Alex joined feenk.com where he is primarily working on the graphical stack for Pharo. > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "To lead is not to demand things, it is to make them happen." > > > > > > > > > > >

May 10, 2017

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

by Steven Costiou

Le 2017-05-10 11:28, Steven Costiou a Ã©crit : > While configuring my local and remote images to work with the remote debugger, there was a bug with the menu in the remote browser. So i wanted to try the debugger and figure out what was the problem using it, but i do not understand how to proceed. When the debugger opens, all i see is the fact that there was a remote problem, and that the proxy was unable to return a proper value. > > I used a local image connected with a headless remote image. To reproduce the bug, go for example in ByteString >> at:put:, right click after the first dot and click "debug". See suggs-menu-bug.png. > > When doing that i get debug-win.png and suggs-debug.png and as you can see i just know there was an error and what it was but i don't have an open debugger as i would normally expect in Pharo. How can i see the real problem occuring in the remote image ? How can i remotely fix this considering that my remote image is headless and it seems to be a problem tied to the remote thing, because locally it doesn't happen ? (or maybe it is a Calypso problem but anyway i cannot debug it...) > > Steven. Hem, i forgot to say that i did that in a remote browser after sending openBrowser to a PRRemotePharo

May 10, 2017

Working with remote debugger: how to debug something happening in the remote image ?

by Steven Costiou

While configuring my local and remote images to work with the remote debugger, there was a bug with the menu in the remote browser. So i wanted to try the debugger and figure out what was the problem using it, but i do not understand how to proceed. When the debugger opens, all i see is the fact that there was a remote problem, and that the proxy was unable to return a proper value. I used a local image connected with a headless remote image. To reproduce the bug, go for example in ByteString >> at:put:, right click after the first dot and click "debug". See suggs-menu-bug.png. When doing that i get debug-win.png and suggs-debug.png and as you can see i just know there was an error and what it was but i don't have an open debugger as i would normally expect in Pharo. How can i see the real problem occuring in the remote image ? How can i remotely fix this considering that my remote image is headless and it seems to be a problem tied to the remote thing, because locally it doesn't happen ? (or maybe it is a Calypso problem but anyway i cannot debug it...) Steven.

May 10, 2017

Re: [Pharo-users] Remote Debugger bugs ?

by Steven Costiou

> I found the issue. Debugging remote UI process is not supported well. When you close debugger remote UI process is terminated which makes remote image unresponsive. > But it is not completely frozen. You can spawn new UI process remotely: > >> remotePharo evaluate: [ UIManager default spawnNewProcess ]. > > Or from remote playground just evaluate it directly: > >> UIManager default spawnNewProcess Thanks, it works :) > I will think how to support it properly. > I wondering do you just play or you have real requirements for this scenario? (I not thought it is important) No i am playing with it while configuring my images. It's easier to test things on both images with the uis when doing that. In the end i will embed the remote image in a raspberry pi and access it remotely, so the ui will (absolutely) not be needed. However, it is conceivable to have a desktop app that i want to connect to for example if a remote user experiences problems and i want to query things or to ask the user to perform operations. If i do such queries i can make mistakes and i would have to proceed/abandon/close debug windows. In this case both will need a ui.

May 10, 2017

Re: [Pharo-users] Intro to git-only Pharo

by Norbert Hartl

Hi Joachim, I think your timing is quite good. We had some changes in the last years and it is getting better now. Before we had only monticello. Monticello is a zip container that contains a version number in the filename and prior version pointer inside the repository. Regarding dependencies there was nothing that was used widely. Then Metacello appeared and solved the problem by providing dependency management and versioning of dependencies. Dependency management works good, the integrated versioning has issues. Especially when you look at a system like git you can see that versioning is solved there. Filetree is needed because git and other vcs systems are file based so you need to layout your code in files (how quaint!) To make a long story short: The best thing to use is git with Metacello Baselines. Filetree is used to store code. Versioning you do with git tags that can be used in Baselines. Now we have a decent UI (iceberg) that supports the most needed workflow items. We have a UI for the dependency management as well (versionner) but it sadly targets ConfigurationOfs and not BaselineOfs. That needs to be changed. my 2 cents, Norbert > Am 10.05.2017 um 07:56 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: > > Hi guys, > > please forgive me if this mail is a sign of ignorance. I am not a regular Pharo user and one of the reasons for this is that I didn't like most of the source management tools around Monticello. Coming from an envy background, it feels like not being ready for prime time. Of course you guys have been proving you can work with these tools quite well, but still I'd be interested in using Pharo in a pure git-based environment, as it most closely resembles some of the most-beloved features of envy. > > Over the years there was a lot of work and discussion on filetree, gitfiletree, iceberg, cypress and maybe quite a few other projects that sounded promising and interesting. But I must admit I lost track of what was really done and how far things went in the last years. > > So are there any pointers to info material that I could look at to see what the current status of source control in Pharo 5 and Pharo 6 is and/or will be soon? > > I am mostly interested in these topics: > > git only - no monticello meta info any more - possible? > tools like merge/diff, committing from within the image > dependencies within my own project as well as dependencies on external code in - possibly multiple - external repositories > what is the current "most official" source repository for open source code? > best practices for managing complex projects and keeping old versions reproducible at any time > tutorial for git newbies in a Pharo context? (Like, how do I start with a new packege - create folder first and do git init, or start in the image and push into repo later? as I said: beginners' stuff) > Thanks for pointers and help > > Joachim >

May 10, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Dimitris Chloupis

Just to remind people here that all languages with long compile times can be avoided live coding style through the use of dynamically linked libraries known as DLLs on windows, shared libraries on linux (*.so) and macos (*.dylib) . Also Swift in particular comes with a live coding environment called "Playgrounds" which is also very flexible. Haskell do not know if they have something similar to Playgrounds but I will be surprise if they do not have something at least inferior. All languages support DLLs including ours. Live coding is actually super easy to implement and believe me I was sceptical about it at first and if I had read this post I am making now I would call me crazy. But after implementing live coding in python, C and C++ , now I am a believer. Of course the real question here is if its that easy why people do not use it . From what I have found out, it has not occurred to them as it did not occur to me. Why C++ coders still endure long compile times when they could test code in an instant through live coding ? Well in games C++ live coding is actually very popular, so some are already aware of the huge advantages of live coding. I think this is an advantage of Pharo , that introduces to live coding, a so simple idea yet so essential without you having to think about it yourself or be already aware of it. With other language you will have to find a tutorial or article that mentions this ability. Another shock for me is how simple it is to implement an image file format for other languages. The shock was that the OS already uses image files like pharo image that calls them "memory mapped files" they are used for sharing memory which in turn is what is used for DLLs. The advantage over the pharo image is that it crash prone, because it is handled by the OS and not the language or the VM. Which means that even if your app crashes the image is still saved and you lose no live data which is not the case with pharo image. The disadvantage is that of course they are not OOP friendly as the pharo image is and they are not language specific as pharo image is. Again I would not have known any of this if I had not been playing with shared memory as an IPC and I also see coders rarely if ever mentioning them. On Wed, May 10, 2017 at 4:09 AM Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: > > I don't know. I do know that I can't use something with the > > ridiculous compile times of Haskell or Swift. That just kills flow > > and productivity. > > You could hop onto an office chair and engage your colleague in sword > fighting. > That's a plus! :-) > > Pierce > >

May 10, 2017

Re: [Pharo-users] Intro to git-only Pharo

by jtuchel＠objektfabrik.de

Peter, thanks for your view and links. Helps me sort things out and find what's remained and keeps being relevant ;-) Joachim Am 10.05.17 um 10:08 schrieb Peter Uhnak: > Hi, > > this is my (=not canonical) perspective > > On Wed, May 10, 2017 at 07:56:19AM +0200, Joachim Tuchel wrote: >> Hi guys, >> >> please forgive me if this mail is a sign of ignorance. I am not a >> regular Pharo user and one of the reasons for this is that I didn't >> like most of the source management tools around Monticello. Coming >> from an envy background, it feels like not being ready for prime >> time. Of course you guys have been proving you can work with these >> tools quite well, but still I'd be interested in using Pharo in a >> pure git-based environment, as it most closely resembles some of the >> most-beloved features of envy. >> >> Over the years there was a lot of work and discussion on filetree, >> gitfiletree, iceberg, cypress and maybe quite a few other projects >> that sounded promising and interesting. But I must admit I lost >> track of what was really done and how far things went in the last >> years. >> >> So are there any pointers to info material that I could look at to >> see what the current status of source control in Pharo 5 and Pharo 6 >> is and/or will be soon? >> >> I am mostly interested in these topics: >> >> * git only - no monticello meta info any more - possible? > first of all -- filetree is an export format which stores Pharo code in an organized fashion on disk... a folder for every package, folder for every class, file for every method... e.g. https://github.com/peteruhnak/pharo-changes-builder/tree/master/repository/… > this format makes it easier for git to manage the code. > > There however two variants of filetree... one containing metacello metadata, e.g. the red here https://github.com/peteruhnak/IconFactory/commit/729da03653d527bd6ca34e0a51… - which caused a lot of pains during merging (because you are almost guaranteed a merge conflict)... so a new variant emerged which doesn't use this metadata and instead determines it directly from git versioning. > > neither GitFileTree (which is a filetree that performs git commits on the background) nor Iceberg use monticello metadata. > > GFT is still managed via Monticello tools, but the metadata is derived from git commits. This is what I've been using for ~two years until recently (now I've switched to Iceberg). > I wrote a guide about GFT some time ago https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… > > Iceberg uses the same filetree format as GFT (so they are compatible), but the tooling inside Pharo has changed. Now there is dedicated iceberg interface for managing git repositories and projects. Although Iceberg is not in stable yet, so it breaks from time to time, but when it works I am really happy with it. (Thanks Esteban & Nico!). > > >> * tools like merge/diff, committing from within the image > Committing from within the image is handled with both GFT and Iceberg; merging is not yet. (And of course you see diff when committing/comparing versions) > >> * dependencies within my own project as well as dependencies on >> external code in - possibly multiple - external repositories > With git came also the switch from ConfigurationOf to BaselineOf, which somewhat simplified version and dependency management. The Baseline is no longer filled with methods for each version, as this is handled by git. > > >> * what is the current "most official" source repository for open >> source code? > for Monticello naturally SmalltalkHub/ss3; for git GitHub, however you are not restricted from other git sites (gitlab, bitbucket, your own server, ...) > >> * best practices for managing complex projects and keeping old >> versions reproducible at any time > well, this is quite general question... I'd say semver.org is a good start, however most people depend on #stable and #development, which are not actually versions, so reproducibility is not possible... but there is work being done iirc regarding better dependency management (Cargo iirc) > > >> * tutorial for git newbies in a Pharo context? (Like, how do I start >> with a new packege - create folder first and do git init, or start >> in the image and push into repo later? as I said: beginners' stuff) > Chapter 8 of Pharo by example, https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… and possibly other resources. > > Peter > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

May 10, 2017

Re: [Pharo-users] Intro to git-only Pharo

by Peter Uhnak

Hi, this is my (=not canonical) perspective On Wed, May 10, 2017 at 07:56:19AM +0200, Joachim Tuchel wrote: > Hi guys, > > please forgive me if this mail is a sign of ignorance. I am not a > regular Pharo user and one of the reasons for this is that I didn't > like most of the source management tools around Monticello. Coming > from an envy background, it feels like not being ready for prime > time. Of course you guys have been proving you can work with these > tools quite well, but still I'd be interested in using Pharo in a > pure git-based environment, as it most closely resembles some of the > most-beloved features of envy. > > Over the years there was a lot of work and discussion on filetree, > gitfiletree, iceberg, cypress and maybe quite a few other projects > that sounded promising and interesting. But I must admit I lost > track of what was really done and how far things went in the last > years. > > So are there any pointers to info material that I could look at to > see what the current status of source control in Pharo 5 and Pharo 6 > is and/or will be soon? > > I am mostly interested in these topics: > > * git only - no monticello meta info any more - possible? first of all -- filetree is an export format which stores Pharo code in an organized fashion on disk... a folder for every package, folder for every class, file for every method... e.g. https://github.com/peteruhnak/pharo-changes-builder/tree/master/repository/… this format makes it easier for git to manage the code. There however two variants of filetree... one containing metacello metadata, e.g. the red here https://github.com/peteruhnak/IconFactory/commit/729da03653d527bd6ca34e0a51… - which caused a lot of pains during merging (because you are almost guaranteed a merge conflict)... so a new variant emerged which doesn't use this metadata and instead determines it directly from git versioning. neither GitFileTree (which is a filetree that performs git commits on the background) nor Iceberg use monticello metadata. GFT is still managed via Monticello tools, but the metadata is derived from git commits. This is what I've been using for ~two years until recently (now I've switched to Iceberg). I wrote a guide about GFT some time ago https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… Iceberg uses the same filetree format as GFT (so they are compatible), but the tooling inside Pharo has changed. Now there is dedicated iceberg interface for managing git repositories and projects. Although Iceberg is not in stable yet, so it breaks from time to time, but when it works I am really happy with it. (Thanks Esteban & Nico!). > * tools like merge/diff, committing from within the image Committing from within the image is handled with both GFT and Iceberg; merging is not yet. (And of course you see diff when committing/comparing versions) > * dependencies within my own project as well as dependencies on > external code in - possibly multiple - external repositories With git came also the switch from ConfigurationOf to BaselineOf, which somewhat simplified version and dependency management. The Baseline is no longer filled with methods for each version, as this is handled by git. > * what is the current "most official" source repository for open > source code? for Monticello naturally SmalltalkHub/ss3; for git GitHub, however you are not restricted from other git sites (gitlab, bitbucket, your own server, ...) > * best practices for managing complex projects and keeping old > versions reproducible at any time well, this is quite general question... I'd say semver.org is a good start, however most people depend on #stable and #development, which are not actually versions, so reproducibility is not possible... but there is work being done iirc regarding better dependency management (Cargo iirc) > * tutorial for git newbies in a Pharo context? (Like, how do I start > with a new packege - create folder first and do git init, or start > in the image and push into repo later? as I said: beginners' stuff) Chapter 8 of Pharo by example, https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… and possibly other resources. Peter

May 10, 2017

Re: [Pharo-users] Intro to git-only Pharo

by jtuchel＠objektfabrik.de

Stef, thanks for answering. Am 10.05.17 um 08:59 schrieb Stephane Ducasse: > Hi joachim > > There is a distinction between managing projects and pharo. Pharo 60 > is managed with Monticello. > Pharo 70 will not. Okay, I came from the perspective of an application developer and not so much as a contributor (which may, of yourse, change for bug reports and such)... > > * git only - no monticello meta info any more - possible? > > Yes people use that everyday. But Pharo is not manage like that (even > if we follow since years a git flow). > In Pharo 70 Pharo itself will be manage with iceberg with git as a > back end (notice the difference) > So that will sure be a showcase for it being ready for prime time ;-) > * tools like merge/diff, committing from within the image > > You have all the diff merge tools within pharo including local commits and oushes to the central repo? > > * dependencies within my own project as well as dependencies on > external code in - possibly multiple - external repositories > > Metacello handles this since year. > There is a chapter on deep into pharo since ages Okay, thanks! I'll definitely take a look at deep into Pharo. > * what is the current "most official" source repository for open > source code? > > SmalltalkHub and SS3, I'm not surprised by these two, but I am surprised github is not in this list... > * best practices for managing complex projects and keeping old > versions reproducible at any time > > Use Metacello and use versions > or symbolic versions to your own projects if you want to minimize changes. Okay, thanks. > * tutorial for git newbies in a Pharo context? (Like, how do I start > with a new packege - create folder first and do git init, or start > in the image and push into repo later? as I said: beginners' stuff) > > There is one on the the github of iceberg. IIRC, iceberg will be in the Pharo 6 images by default..? So iceberg is what people are/will be using. Again, thanks a lot for the pointers! Joachim > > Stef > > On Wed, May 10, 2017 at 7:56 AM, Joachim Tuchel > <jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de>> wrote: > > Hi guys, > > please forgive me if this mail is a sign of ignorance. I am not a > regular Pharo user and one of the reasons for this is that I > didn't like most of the source management tools around Monticello. > Coming from an envy background, it feels like not being ready for > prime time. Of course you guys have been proving you can work with > these tools quite well, but still I'd be interested in using Pharo > in a pure git-based environment, as it most closely resembles some > of the most-beloved features of envy. > > Over the years there was a lot of work and discussion on filetree, > gitfiletree, iceberg, cypress and maybe quite a few other projects > that sounded promising and interesting. But I must admit I lost > track of what was really done and how far things went in the last > years. > > So are there any pointers to info material that I could look at to > see what the current status of source control in Pharo 5 and Pharo > 6 is and/or will be soon? > > I am mostly interested in these topics: > > * git only - no monticello meta info any more - possible? > * tools like merge/diff, committing from within the image > * dependencies within my own project as well as dependencies on > external code in - possibly multiple - external repositories > * what is the current "most official" source repository for open > source code? > * best practices for managing complex projects and keeping old > versions reproducible at any time > * tutorial for git newbies in a Pharo context? (Like, how do I > start with a new packege - create folder first and do git > init, or start in the image and push into repo later? as I > said: beginners' stuff) > > Thanks for pointers and help > > > Joachim > > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

May 10, 2017

Re: [Pharo-users] Epicea vs RB refactorings

by Stephane Ducasse

Nonsense Epicea has nothing to do with RB goals. Epicea is to replace the changes file because we want a better change file and separate the code management from the version recording (micro commits). Source code could be managed in a separate database and microchanges can be managed to recover changes but not actually showing the latest version of a method. Stef Stef On Wed, Apr 26, 2017 at 11:19 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > I'm under the impression that Epicea is supposed to replace RB > refactorings at some point. > > If that is true, is it currently possible to build refactorings by hand? > > For example in RB I often do: > > ``` > model := RBNamespace new. > > model defineClass: ('<1s> subclass: #<2s><n><t>instanceVariableNames: > <3p><n><t>classVariableNames: ''''<n><t>poolDictionaries: > ''''<n><t>category: <4p>' expandMacrosWith: 'Object' with: 'MySomething' > with: 'var1 var2' with: 'MyPackage'). > cls := model classNamed: #MySomething. > cls compile: 'var1 > ^ var1' classified: 'accessing'. > > (ChangesBrowser changes: model changes changes) open > ``` > > or > > (removing a method from a class) > ``` > model := RBNamespace new. > model removeMethod: #testTrimRight from: StringTest. > (ChangesBrowser changes: model changes changes) open > ``` > > Thanks, > Peter > >

May 10, 2017