November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Accessing Virtual machine internal?

by Nicolai Hess

2016-11-07 13:37 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Is there a way to get access to the VM internals? For example the size of > the method cache and the number of JIT-compiled methods? > I don't know about the method cache siize, but for the number of JIT-Compiled methods is a primitive (a VMParameter) > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Nov. 7, 2016

Accessing Virtual machine internal?

by Alexandre Bergel

Hi! Is there a way to get access to the VM internals? For example the size of the method cache and the number of JIT-compiled methods? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 7, 2016

Re: [Pharo-dev] [Pharo-users] About balkanisation

by Esteban Lorenzano

> On 7 Nov 2016, at 11:28, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On 11/7/16 4:52 AM, Esteban Lorenzano wrote: >> btw this is pharo-dev discussion, redirecting there. >> >> Esteban >> >>> On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> We are developing Icebergâ¦ and I know is not enough :) >>> Which âunifying toolsâ are you referring ? > The main unifying tool is a Metacello Project Browser (or something like the tODE project list). > > You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ... > > There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level > > From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ... > > This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): > - save > - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) > - diff -- project level diff over a collection of packages > - commit log -- For ConfigurationOf, list the commit history of the Configuration. > For a BaselineOf list the commit log for the git repository > > The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with â¦ this is what is provided by icebergâ¦ it still needs some work, but this is precisely what is supposed to do :) (and btw, this is why I disagree with Thierry some mails below). > > The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately... > > The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par â¦ also, this is supposed to be provided by iceberg. > > The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git â¦ Iceberg is not package-oriented. It just show repositories/packages/classes/methodsâ¦ this is a good way to do it and I do not thing anything is lost like this. You need to take a second look at Iceberg :) > > Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together this is something to thinkâ¦ I do not get what catalog browser can do here (but yes, a way to browse local repositories needs to be provided). > > I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think â¦ I do not think we are so far from your vision. I think you did not get it Iceberg rightâ¦ please, take a second look :) nowâ¦ is true that now everything you say is already doneâ¦ but this is general orientation :) Esteban ps: all of this is *clearly* not pharo-users but pharo-dev discussion, letâs move there. >>> >>> I have followed very close your TOdE developmentâ¦ in a moment I was planning a migration of it for pure-pharo, justâ¦ lack of time as always and then later we started iceberg. > Yes, I have intended to do a port of tODE to Pharo, but of time is the killer :) >>> now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. > Yes but the two boat environment will last years ... it has taken almost 5 years for filetree to start to be used regularly ... and with the Metacello Project Browser approach the transition will not be nearly as painful, besides I think that the project-centric tools set is required when work with git.... >>> >>> What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose oneâ¦ right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticelloâ¦ > As I say, I think that monticello/filetree can be abstracted away at the Metacello Project Browser level ... a commit of dirty packages writes all the dirty packages for the project in the appropriate repository ... BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take a whole lot of code to smoothly handle both projects --- as I've said, I have code in tODE that can be looked at for the key trickery and then re-implemented within Pharo without too much trouble ... > > Then the choice does not have to be made between supporting ConfigurationOf and BaselineOf as both are supported ... eventually a developer may choose to build an image that does not include ConfigurationOf and Monticello support --- but both are needed for at least the next several years > > >>> and that way of doing has a limit. A limit I think we already passed. >>> >>> Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) > the presentation that I made last Wednesday really covers the most critical things that I think are required ... Metacello Project Browser and load specs are the big ones ... presumably a Project Browser/code browser that allows you to read code at the project level to augment the existing package level code browsers with the commit history integrated at project/package/class/method level ... project level diff tool -- multi-package diffs in one window ... and a git merge tool that does a three-way merge within the image ... > > Dale >

Nov. 7, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Denis Kudriashov

Hi Esteban. 2016-11-06 17:51 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > height > "This method was automatically generated" > ^handle doubleAt: 17 > > height: anObject > "This method was automatically generated" > handle doubleAt: 17 put: anObject > > which of course does not work. > with my idea this will become like this: > > height > "This method was automatically generated" > ^handle doubleAt: HEIGHT_OFFSET > > height: anObject > "This method was automatically generated" > handle doubleAt: HEIGHT_OFFSET put: anObject > I have feeling that Slots could solve this problem really well and also improve the way how we work with external structures. If you saw how Ronie describes external structures then you could imaging what I am talking about. For now on class side we always have #fieldDesc: method like: SDL_Point>>fieldsDesc " self initializeAccessors " ^#( int x; int y; ) where code in comments generates accessors. And with Ronie approach this description will go directly to class definition: NativeStructure subclass : #SDL_Point layout : StructureLayout slots: { #x &=> #int. #y &=> #int} ... (I got example of Ronie definition from his paper https://hal.inria.fr/hal-01353884/document) So all offsets logic will go to one place StructureLayout and slots. And also we will not forced to use accessors anymore. What you think? Best regards, Denis

Nov. 7, 2016

Re: [Pharo-dev] why sparta depends on Taskit?

by Tudor Girba

Hi, > On Nov 7, 2016, at 8:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 7 Nov 2016, at 07:41, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Hi >> >> It is a library :) Even that there is an important difference between plugin and library we always refer to library in this thread. >> > I was thinking that but then Doru mentioned âMoz2D pluginâ and I got confused :) I am a bit at a loss with the naming given that libMoz2D.dylib library lies in the Plugins folder of the VM :). But, the good thing is that we talk about the same thing :). Cheers, Doru > Esteban >> Cheers >> Alex >> >> >> On Nov 6, 2016 22:31, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >> >> > On 6 Nov 2016, at 21:47, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > >> > Hi, >> > >> >> On Nov 6, 2016, at 9:43 PM, stepharo <stepharo(a)free.fr> wrote: >> >> >> >> I tried to open the image that glenn gave me and I can browse the code (I got an FFI problem due to the fact that the lib is not present). >> >> >> >> I tried and I could open the image from the ci with the vm glenn sent me. >> >> >> >> So I will update my vm. >> > >> > Thanks! >> > >> > So, the default Pharo VM does not have the Moz2D plugin, and likely that is what Glenn gave you. Could you try with that VM to run 2 examples? I still have a funky issue with my machine that I can only run one example, and then I get a black screen for the second one. >> >> why do you need a plugin and not just a regular library? >> >> Esteban >> >> > >> > Cheers, >> > Doru >> > >> >> Stef >> >> >> >> >> >> >> >> Le 6/11/16 Ã 20:19, Tudor Girba a Ã©crit : >> >>> Hi, >> >>> >> >>> It does not work to run the Bloc examples with the regular VM, but it does work to browse the code. Stef is saying that he cannot browse code in the Bloc image. >> >>> >> >>> This is a significant problem, but I just do not see why this is so. So, it would be very useful for us to learn where this problem could come from. >> >>> >> >>> Doru >> >>> >> >>> >> >>>> On Nov 6, 2016, at 7:01 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >>>> >> >>>> Hi >> >>>> >> >>>> Just taking Bloc image from CI does not work. Don't forget that you need Sparta plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to ship plugin with image, sorry... >> >>>> >> >>>> It can be downloaded from bintray https://bintray.com/syrel/Moz2D/libMoz2D. >> >>>> >> >>>> Cheers >> >>>> Alex >> >>>> >> >>>> >> >>>> On Nov 6, 2016 4:58 PM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: >> >>>> Hi, >> >>>> >> >>>> I think there are a couple of thinks that are mixed up. >> >>>> >> >>>> First, the image from CI: >> >>>> - download the latest image built on October 12 on Jenkins: >> >>>> https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=developmen… >> >>>> - run it either with the stable of the latest VM >> >>>> ==> you should get no crash when opening the image (I just checked again) >> >>>> >> >>>> The code loading is a bit strange. I just tried and I do now know why this does not work from the command line on Mac. For me it somehow hanged while loading PetitCSS. There is something strange with Metacello and projects that depend on Glamour that I could not quite fully understand yet and I am looking at it since a month. Dale, I need your help, but I will follow up on this :). >> >>>> >> >>>> At the same time, I can reliably load the code using this script from a fresh Pharo image and the latest VM: >> >>>> >> >>>> Gofer it >> >>>> smalltalkhubUser: 'Pharo' project: 'Bloc'; >> >>>> configuration; >> >>>> loadDevelopment. >> >>>> >> >>>> Can you please try this one? >> >>>> >> >>>> Cheers, >> >>>> Doru >> >>>> >> >>>> >> >>>> >> >>>>> On Nov 6, 2016, at 11:24 AM, stepharo <stepharo(a)free.fr> wrote: >> >>>>> >> >>>>> I got to the ci and I click on the image and download and drop it on my vm=> crash. >> >>>>> Why doing a video? >> >>>>> >> >>>>> open a shell >> >>>>> >> >>>>> wget -O - http://get.pharo.org/60+vm | bash >> >>>>> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc --install=development >> >>>>> >> >>>>> And it fails loading taskit. >> >>>>> >> >>>>> Stef >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Le 6/11/16 Ã 11:01, Aliaksei Syrel a Ã©crit : >> >>>>>> The best would be if you could make a video of how you install Bloc and send to Glenn. Because it works for us and for Travis CI. Sound like you face a strange and not so easy to catch issue. >> >>>>>> >> >>>>>> Cheers >> >>>>>> Alex >> >>>>>> >> >>>>>> >> >>>>>> On Nov 5, 2016 6:54 PM, "stepharo" <stepharo(a)free.fr> wrote: >> >>>>>> why sparta depends on Taskit? >> >>>>>> >> >>>>>> >> >>>>>> Since I cannot load it I cannot try to understand. I find strange that a graphical canvas depends on a concurrent task management system. >> >>>>>> >> >>>>>> I tried to follow the instruction given by glenn and it failed. So so far I could not see any recent versions of Bloc. >> >>>>>> >> >>>>>> I do not understand why the image produced by the jenkins job crashes my vm. >> >>>>>> >> >>>>>> >> >>>>>> Stef >> >>>>>> >> >>>>>> >> >>>>>> wget -O - http://get.pharo.org/60+vm | bash >> >>>>>> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc --install=development >> >>>>>> >> >>>>>> >> >>>>>> just failed yesterday for me. >> >>>>>> >> >>>>>> >> >>>> -- >> >>>> www.tudorgirba.com >> >>>> www.feenk.com >> >>>> >> >>>> "What we can governs what we wish." >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> -- >> >>> www.tudorgirba.com >> >>> www.feenk.com >> >>> >> >>> "Not knowing how to do something is not an argument for how it cannot be done." >> >>> >> >>> >> >>> >> >> >> >> >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "In a world where everything is moving ever faster, >> > one might have better chances to win by moving slower." >> > >> > >> > >> > >> > >> >> > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

Nov. 7, 2016

Re: [Pharo-dev] [Pharo-users] About balkanisation

by Esteban Lorenzano

btw this is pharo-dev discussion, redirecting there. Esteban > On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > We are developing Icebergâ¦ and I know is not enough :) > Which âunifying toolsâ are you referring ? > > I have followed very close your TOdE developmentâ¦ in a moment I was planning a migration of it for pure-pharo, justâ¦ lack of time as always and then later we started iceberg. > now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. > > What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose oneâ¦ right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticelloâ¦ and that way of doing has a limit. A limit I think we already passed. > > Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) > > Esteban > >> On 7 Nov 2016, at 06:30, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> >> On 11/6/16 1:12 PM, Tudor Girba wrote: >>> Hi Stef, >>> >>> I think that you are raising a valid point, and I actually agree with it. >>> >>> But I think there is another side of the coin as well. >>> >>> I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. >> Doru, there are also holes in the tool set that are not being addressed ... there are a number of critical tools that need to be created and I don't see anyone working on them .... >> >> I went through this transition 5 years ago with my tool set and with the proper set of tools approach the difficult transition will be a bit easier ... >> >> As it stands Pharo is standing with one foot in two boats ... there are the old Monticello tools and the new Git/Filetree tools and what is needed is a tool or two that can unify to both tool sets so that the transition between the two can be seamless ... these two sets of tools are not complicated and there working implementations that can be adapted to Pharo or used as a fairly detailed guide ... >> >> The confusion and frustration that I see now is not a surprise to me ... I wrote" the emails" at the beginning of this year because I saw that Pharo was finally reaching a critical point in its move to integrate git into the mainstream development environment and I knew that these types of issues were going to come up where Monticello and Git were going to create friction --- friction that can be reduced by creating some simple "unifying tools" ... >> >> I want to help, I have tried to help and I am still willing to help, but I cannot write the tools for Pharo ... >> >> Dale >> >

Nov. 7, 2016

Re: [Pharo-dev] why sparta depends on Taskit?

by Esteban Lorenzano

> On 7 Nov 2016, at 07:41, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi > > It is a library :) Even that there is an important difference between plugin and library we always refer to library in this thread. > I was thinking that but then Doru mentioned âMoz2D pluginâ and I got confused :) Esteban > Cheers > Alex > > > On Nov 6, 2016 22:31, "Esteban Lorenzano" <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > On 6 Nov 2016, at 21:47, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > > > > Hi, > > > >> On Nov 6, 2016, at 9:43 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > >> > >> I tried to open the image that glenn gave me and I can browse the code (I got an FFI problem due to the fact that the lib is not present). > >> > >> I tried and I could open the image from the ci with the vm glenn sent me. > >> > >> So I will update my vm. > > > > Thanks! > > > > So, the default Pharo VM does not have the Moz2D plugin, and likely that is what Glenn gave you. Could you try with that VM to run 2 examples? I still have a funky issue with my machine that I can only run one example, and then I get a black screen for the second one. > > why do you need a plugin and not just a regular library? > > Esteban > > > > > Cheers, > > Doru > > > >> Stef > >> > >> > >> > >> Le 6/11/16 Ã 20:19, Tudor Girba a Ã©crit : > >>> Hi, > >>> > >>> It does not work to run the Bloc examples with the regular VM, but it does work to browse the code. Stef is saying that he cannot browse code in the Bloc image. > >>> > >>> This is a significant problem, but I just do not see why this is so. So, it would be very useful for us to learn where this problem could come from. > >>> > >>> Doru > >>> > >>> > >>>> On Nov 6, 2016, at 7:01 PM, Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: > >>>> > >>>> Hi > >>>> > >>>> Just taking Bloc image from CI does not work. Don't forget that you need Sparta plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to ship plugin with image, sorry... > >>>> > >>>> It can be downloaded from bintray https://bintray.com/syrel/Moz2D/libMoz2D <https://bintray.com/syrel/Moz2D/libMoz2D>. > >>>> > >>>> Cheers > >>>> Alex > >>>> > >>>> > >>>> On Nov 6, 2016 4:58 PM, "Tudor Girba" <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > >>>> Hi, > >>>> > >>>> I think there are a couple of thinks that are mixed up. > >>>> > >>>> First, the image from CI: > >>>> - download the latest image built on October 12 on Jenkins: > >>>> https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=developmen… <https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=developmen…> > >>>> - run it either with the stable of the latest VM > >>>> ==> you should get no crash when opening the image (I just checked again) > >>>> > >>>> The code loading is a bit strange. I just tried and I do now know why this does not work from the command line on Mac. For me it somehow hanged while loading PetitCSS. There is something strange with Metacello and projects that depend on Glamour that I could not quite fully understand yet and I am looking at it since a month. Dale, I need your help, but I will follow up on this :). > >>>> > >>>> At the same time, I can reliably load the code using this script from a fresh Pharo image and the latest VM: > >>>> > >>>> Gofer it > >>>> smalltalkhubUser: 'Pharo' project: 'Bloc'; > >>>> configuration; > >>>> loadDevelopment. > >>>> > >>>> Can you please try this one? > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>> > >>>>> On Nov 6, 2016, at 11:24 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > >>>>> > >>>>> I got to the ci and I click on the image and download and drop it on my vm=> crash. > >>>>> Why doing a video? > >>>>> > >>>>> open a shell > >>>>> > >>>>> wget -O - http://get.pharo.org/60+vm <http://get.pharo.org/60+vm> | bash > >>>>> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main <http://www.smalltalkhub.com/mc/Pharo/Bloc/main> ConfigurationOfBloc --install=development > >>>>> > >>>>> And it fails loading taskit. > >>>>> > >>>>> Stef > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Le 6/11/16 Ã 11:01, Aliaksei Syrel a Ã©crit : > >>>>>> The best would be if you could make a video of how you install Bloc and send to Glenn. Because it works for us and for Travis CI. Sound like you face a strange and not so easy to catch issue. > >>>>>> > >>>>>> Cheers > >>>>>> Alex > >>>>>> > >>>>>> > >>>>>> On Nov 5, 2016 6:54 PM, "stepharo" <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > >>>>>> why sparta depends on Taskit? > >>>>>> > >>>>>> > >>>>>> Since I cannot load it I cannot try to understand. I find strange that a graphical canvas depends on a concurrent task management system. > >>>>>> > >>>>>> I tried to follow the instruction given by glenn and it failed. So so far I could not see any recent versions of Bloc. > >>>>>> > >>>>>> I do not understand why the image produced by the jenkins job crashes my vm. > >>>>>> > >>>>>> > >>>>>> Stef > >>>>>> > >>>>>> > >>>>>> wget -O - http://get.pharo.org/60+vm <http://get.pharo.org/60+vm> | bash > >>>>>> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main <http://www.smalltalkhub.com/mc/Pharo/Bloc/main> ConfigurationOfBloc --install=development > >>>>>> > >>>>>> > >>>>>> just failed yesterday for me. > >>>>>> > >>>>>> > >>>> -- > >>>> www.tudorgirba.com <http://www.tudorgirba.com/> > >>>> www.feenk.com <http://www.feenk.com/> > >>>> > >>>> "What we can governs what we wish." > >>>> > >>>> > >>>> > >>>> > >>>> > >>> -- > >>> www.tudorgirba.com <http://www.tudorgirba.com/> > >>> www.feenk.com <http://www.feenk.com/> > >>> > >>> "Not knowing how to do something is not an argument for how it cannot be done." > >>> > >>> > >>> > >> > >> > > > > -- > > www.tudorgirba.com <http://www.tudorgirba.com/> > > www.feenk.com <http://www.feenk.com/> > > > > "In a world where everything is moving ever faster, > > one might have better chances to win by moving slower." > > > > > > > > > > > >

Nov. 7, 2016

Re: [Pharo-dev] why sparta depends on Taskit?

by Aliaksei Syrel

Hi It is a library :) Even that there is an important difference between plugin and library we always refer to library in this thread. Cheers Alex On Nov 6, 2016 22:31, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > > On 6 Nov 2016, at 21:47, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > >> On Nov 6, 2016, at 9:43 PM, stepharo <stepharo(a)free.fr> wrote: > >> > >> I tried to open the image that glenn gave me and I can browse the code > (I got an FFI problem due to the fact that the lib is not present). > >> > >> I tried and I could open the image from the ci with the vm glenn sent > me. > >> > >> So I will update my vm. > > > > Thanks! > > > > So, the default Pharo VM does not have the Moz2D plugin, and likely that > is what Glenn gave you. Could you try with that VM to run 2 examples? I > still have a funky issue with my machine that I can only run one example, > and then I get a black screen for the second one. > > why do you need a plugin and not just a regular library? > > Esteban > > > > > Cheers, > > Doru > > > >> Stef > >> > >> > >> > >> Le 6/11/16 Ã 20:19, Tudor Girba a Ã©crit : > >>> Hi, > >>> > >>> It does not work to run the Bloc examples with the regular VM, but it > does work to browse the code. Stef is saying that he cannot browse code in > the Bloc image. > >>> > >>> This is a significant problem, but I just do not see why this is so. > So, it would be very useful for us to learn where this problem could come > from. > >>> > >>> Doru > >>> > >>> > >>>> On Nov 6, 2016, at 7:01 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >>>> > >>>> Hi > >>>> > >>>> Just taking Bloc image from CI does not work. Don't forget that you > need Sparta plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to ship > plugin with image, sorry... > >>>> > >>>> It can be downloaded from bintray https://bintray.com/syrel/ > Moz2D/libMoz2D. > >>>> > >>>> Cheers > >>>> Alex > >>>> > >>>> > >>>> On Nov 6, 2016 4:58 PM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: > >>>> Hi, > >>>> > >>>> I think there are a couple of thinks that are mixed up. > >>>> > >>>> First, the image from CI: > >>>> - download the latest image built on October 12 on Jenkins: > >>>> https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO= > 60,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/Bloc.zip > >>>> - run it either with the stable of the latest VM > >>>> ==> you should get no crash when opening the image (I just checked > again) > >>>> > >>>> The code loading is a bit strange. I just tried and I do now know why > this does not work from the command line on Mac. For me it somehow hanged > while loading PetitCSS. There is something strange with Metacello and > projects that depend on Glamour that I could not quite fully understand yet > and I am looking at it since a month. Dale, I need your help, but I will > follow up on this :). > >>>> > >>>> At the same time, I can reliably load the code using this script from > a fresh Pharo image and the latest VM: > >>>> > >>>> Gofer it > >>>> smalltalkhubUser: 'Pharo' project: 'Bloc'; > >>>> configuration; > >>>> loadDevelopment. > >>>> > >>>> Can you please try this one? > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>> > >>>>> On Nov 6, 2016, at 11:24 AM, stepharo <stepharo(a)free.fr> wrote: > >>>>> > >>>>> I got to the ci and I click on the image and download and drop it on > my vm=> crash. > >>>>> Why doing a video? > >>>>> > >>>>> open a shell > >>>>> > >>>>> wget -O - http://get.pharo.org/60+vm | bash > >>>>> ./pharo Pharo.image config http://www.smalltalkhub.com/ > mc/Pharo/Bloc/main ConfigurationOfBloc --install=development > >>>>> > >>>>> And it fails loading taskit. > >>>>> > >>>>> Stef > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Le 6/11/16 Ã 11:01, Aliaksei Syrel a Ã©crit : > >>>>>> The best would be if you could make a video of how you install Bloc > and send to Glenn. Because it works for us and for Travis CI. Sound > like you face a strange and not so easy to catch issue. > >>>>>> > >>>>>> Cheers > >>>>>> Alex > >>>>>> > >>>>>> > >>>>>> On Nov 5, 2016 6:54 PM, "stepharo" <stepharo(a)free.fr> wrote: > >>>>>> why sparta depends on Taskit? > >>>>>> > >>>>>> > >>>>>> Since I cannot load it I cannot try to understand. I find strange > that a graphical canvas depends on a concurrent task management system. > >>>>>> > >>>>>> I tried to follow the instruction given by glenn and it failed. So > so far I could not see any recent versions of Bloc. > >>>>>> > >>>>>> I do not understand why the image produced by the jenkins job > crashes my vm. > >>>>>> > >>>>>> > >>>>>> Stef > >>>>>> > >>>>>> > >>>>>> wget -O - http://get.pharo.org/60+vm | bash > >>>>>> ./pharo Pharo.image config http://www.smalltalkhub.com/ > mc/Pharo/Bloc/main ConfigurationOfBloc --install=development > >>>>>> > >>>>>> > >>>>>> just failed yesterday for me. > >>>>>> > >>>>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> www.feenk.com > >>>> > >>>> "What we can governs what we wish." > >>>> > >>>> > >>>> > >>>> > >>>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Not knowing how to do something is not an argument for how it cannot > be done." > >>> > >>> > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "In a world where everything is moving ever faster, > > one might have better chances to win by moving slower." > > > > > > > > > > > > >

Nov. 7, 2016

Re: [Pharo-dev] http://pharo.org/files/pharo.png

by Sven Van Caekenberghe

> On 6 Nov 2016, at 22:04, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 6 Nov 2016, at 19:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I am not upset, but you did not explain what you did up until now. >> >> Still, this URL was/is used everywhere as an example (in comments and books) and tests. >> >> It looks silly if we break our own links. And a year or so ago I already changed all those links once. If I have to do it again, I will move everything away from infrastructure that I cannot control myself. > > I didnât know I was breaking anythingâ¦ otherwise I would have fixed it, is not that I looked at it and I said âhey, letâs break thisâ¦ who cares?â > Now, I need to fix itâ¦ as many other things that we may break without knowingâ¦ thatâs why I said, and I repeat: âwe all make mistakes time to timeâ. OK, of course you did not do this on purpose. And it is good that you maintain the main website. Now, it is common/good practice to front Seaside with nginx (or apache). If you do, you can export the Seaside files to the file system (using #deployFiles) to serve them faster/better when found. Like this: upstream my-seaside { ip_hash; server localhost:9090; ... } server { ... location /files { alias /home/pharo/my-files; try_files $uri @seaside; gzip on; gzip_types application/x-javascript text/css; expires 30d; } location / { proxy_pass http://my-seaside; add_header X-Server Pharo; } location @seaside { proxy_pass http://my-seaside; add_header X-Server Pharo; } } With this scheme you should be able to add any statically served file manually. (Here only under /files, but you could add more handlers). Sven > Esteban > >> >>> On 6 Nov 2016, at 19:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> It is not removedâ¦ I moved the backend from amber to seaside and there is a problem because standard installation of seaside uses /files to his own file server. >>> now, I want to move that but I didnât had the time. >>> In the mean time, in fact real address of that file was before and still is: https://pharo.org/web/files/pharo.png >>> and file can still be found there. >>> >>> Iâm sorry if I messes up something, but I see no reason to be so upsetâ¦ we all make mistakes time to time :P >>> >>> Esteban >>> >>>> On 6 Nov 2016, at 18:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Who removed http://pharo.org/files/pharo.png ? >>>> >>>> Why ? >>>> >>>> It is used in tests/examples. >>>> >>>> Could it be put back please, even it is not used (it does do no harm) ? >>>> >>>> A basic rule of the Web is not to break existing stuff. >>>> >>>> Sven

Nov. 6, 2016

Re: [Pharo-dev] [how about] Exceptions as first class objects *in Debugger*

by Bernardo Ezequiel Contreras

+1, with that information you could describe or show the cause of the exception On Sun, Nov 6, 2016 at 6:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Indeed this has bothered me a lot as well. > > At least an 'Inspect Exception' would be useful. > > It would also encourage people to put more useful information inside > exception objects. > > > On 6 Nov 2016, at 10:38, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > Hi, > > > > we have this supercool exception handling mechanism, but as soon as we > open a debugger the exception object is goneâ¦ I understand that we didnât > need this in old times, but now with a moldable debugger, we could create > hooks to allow exceptions to define how they should be addressed (and > objects are really powerful). > > > > Cheers. > > Uko > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Nov. 6, 2016