April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Re: Status of Pharo VM for FreeBSD

by Esteban Lorenzano

> On 03 Apr 2015, at 13:04, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > Am 03.04.15 11:13, schrieb Esteban Lorenzano: >> >>> On 02 Apr 2015, at 19:20, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>> >>> Hi Andreas, >>> >>> sorry to be late in replying. This has been a busy month (I moved house). >>> >>> On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz <a.wacknitz(a)gmx.de <mailto:a.wacknitz@gmx.de>> wrote: >>> >>> Hi Eliot, >>> >>>> Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >>>> >>>> HI Andreas, >>>> >>>> On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz(a)gmx.de <mailto:a.wacknitz@gmx.de>> wrote: >>>> >>>> Hi Clement, >>>> >>>>> Am 11.03.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >>>>> >>>>> Hello, >>>>> >>>>> About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working. >>>> Thatâs my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated). >>>> >>>>> >>>>> About your NativeBoost bug on openSolaris, need more information: >>>>> >>>>> - Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor. >>>>> >>>> Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300). >>>> >>>>> - Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere... >>>>> >>>> PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm>" (thus Cog VM). >>>> >>>> I would like to fold back any changes into the svn master repository for Cog. What are the diffs? (If you have time to send me the diffs that would save me a lot of time). >>> I donât know whether there is much to harvest from what I did. As far as I remember most of my work was hacking the generator image created by the pharo vm scripts (for my Mac) in order to make >>> the resulting C code to compile under openindiana. The basis for Solaris was already there (and as far as I can see it is also in the Squeak VM sources). I only tweaked some definitions and includes. >>> I will look at my notes tomorrow and will post if I will find something relevant. >>> >>> I am curios about the future of the PharoVM. The main development of the VM seem to happen in the SqueakVM (by you). Getting the Spur changes into the PharoVM seem to be a lot of work. >>> >>> Note that this will happen (or is already happening). Esteban is working on building the Spur version of Pharo, so he is doing this work. But actually it *isn't* that much work. There is basically a trio of new memory management files for each platform, e.g. platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the spur vm, spursrc/vm. The system is already set up to build multiple VMs (at least the svn tree is). >> >> >> Yes, this is already done. We are building spur VMs and images since awhile now. You can find all the related jobs here: >> >> https://ci.inria.fr/pharo/view/4.0-VM-Spur/ <https://ci.inria.fr/pharo/view/4.0-VM-Spur/>If I follow this link and what is being used there brings me to the ordinary PharoVm project on github: > https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> > There are three branches: master, develop and spur64. Which one is being used to build PharoVM-spur32? yes, I still didnât merged with master. master still builds a regular cog vm. Iâm working on spur64 branch now, here: https://github.com/estebanlm/pharo-vm/tree/spur64 <https://github.com/estebanlm/pharo-vm/tree/spur64> the spur jobs are built against my repository for the moment. > >> >> And as Eliot saysâ¦ is not *much* workâ¦ except when it is :) >> In fact, we were planning to release Pharo 4 (next week) with a Spur VM, but we didnât finish all the small things around. So we will release next July (or around) a Pharo 4S (S, for Spur) with âofficialâ spur support. We do not want to stay to much time in older versions. Also, our development process is different > This explanation irritates me: Pharo 4 will be released soon with a Spur VM? And then around summer Pharo 4S? Isn't it a contradiction? no, Pharo 4 will be released *without* spur, then we will release a 4S *with* spur. > >> than squeak, AFAIKâ¦ we drop backward compatibility in a regular basis. Which basically means we will move to spur and we will drop support for older versions. > That's OK, but I am still, hmm say confused, because Eliot is changing A LOT (just look at what has been released during the last days), but PharoVM hasn't been > changed for some days (I am following the master branch closely). So there is a rapid development in the Cog branch of the SqueakVM. The changes in the PharoVM are much slower (at least as I recognise it). just because you checked the master repository, not mineâ¦ mine changed yesterday :) > > I have more questions but I am reluctant to disturb you further as you must be quite busy atm. ask, I will answer when I can :) > > Best regards > Andreas >> >>> >>> >>> Wouldnât it be better to move back the changes of the PharoVM into the SqueakVM and have a united development? >>> >>> Well, I don't think the Pharo community will be willing to move to svn. SOme time I may be able to move to git. But yes, I *would* like to see important fixes merged back into the SqueakVM. I think this is very important. I'm too overloaded to look at the pharovm so I'm dependent on those working on the pharovm in giut to send me changes for integration. >> >> Right, we are happy with our process and I do not see it fitting with svn. We changed a lot of âorganisationalâ stuff to ensure traceability and âbuildabilityâ (if such word existsâ¦). And we have made a lot of progress in that area using git and github infrastructure at a point most of the time to incorporate a change we just accept a pull request. >> To be able to do that: >> - we have to be sure what version of each component (vm, plugin, platform source) is part of the commit info. Thatâs why we keep together both platform sources and image sources (using filetree monticello format). That way each commit has everything we need to build the new vm. In factâ¦ I have a script â./newVM <commit>â that does a clone, prepares an image, generates sources and builds the vmâ¦ then I can test if a pull request is valid. But most of the time that is not needed, because: >> - for each pull request, we fire a travis job that creates a vm from scratch and then runs all tests we have in Pharo (and we have improved a lot in that area latest years). They are not âvm specific testsâ, but since they tests all the system, if vm does not crashes and tests are run, we can be sure is working (this wouldnât be possible without right traceability). >> - we also build the vm using CMake, but not directly, we use CMakeMaker which allow us to define the build in smalltalk. >> - finally, we would like to use the other capabilities (for documentation, etc.) we gain for free by using github. Not that we are already using itâ¦ but we would like, in the future. >> > Is there an up-to-date documentation of the processes? Especially if I want to add more platform support (like openindiana or FreeBSD)? the process, noâ¦ for now we accept pull requestsâ¦ and we handle issues using the pharo issue tracker. This is not good, I would like to have a centralised issue trackerâ¦ but well, we will talk with Eliot about it soon (I suppose having alll sources in github also could lead us to us the issue tracker of github) the build process is explained in the README.md. > My time is very limited (my day job is quite different from what I do in my spare time + my family and my house also need a lot attention + next to my Smalltalk interets I am also interested in operating systems) so my reaction time is sometimes quite slow :) > >> Soâ¦ obviously all of this can be achieved without using git and githubâ¦ but there the infrastructure is already done. >> >> Said that. Even if we actually have a different process, we (Myself, particularly) are trying to reduce the gap between both VMs. And right now this is the status: >> - in the VM itself there is almost no change. AFAIR, just two small things: >> a) I include setjmp.h somewhere, because compiler was asking for it (We use different versions than Eliot) >> b) the macro to read the image is changed, because we needed to change it for allow build an iOS image. This is just one line in the image and the addition of one macro in 4 platform sources (Linux, Win and Mac redirects to old macro, but iOS implements something different) >> - In the platforms we have the most important difference, because we deprecated the âMac OSâ branch in favor of âiOSâ, which in fact should be called OSX, because is the Cocoa version. I understand Eliot want to go in that direction soon so we will align in that area too (btw, that branch has growth organically so we'll need to do some reorganisation to clarify it, eventually) >> - in the plugins, we try to adopt a different approach than the previous one: instead using particularities of the platform, we want to align sources as much as possible, so we use the posix libraries. Again, thatâs just when is possible (and when we have time). The most important change we produced here is with FilePlugin: we changed it to provide posix-permissions (and soon we will add primitives to retrieve also ownership). To allow that, we changed a lot in the windows version of the plugin, because instead windows functions we use MinGW. We would like to see this changes merged. >> >> After that, I think there will be some other minor changesâ¦ not many, and most probably we can remove those differences. >> >> hope this clarify all :) > That's a nice explanation at least. > But I am still confused. Especially because you didn't mention NativeBoost :) Nativeboost is just a plugin (and a cpp flag in generated sources to allocate executable memory). > The ffi area also seem to be different and i a flux. but we are going to align that also (already half way from there) :) we want to be as close as possibleâ¦ there is no point on keeping not needed divergences. > > And still: How to integrate more platforms? depends on the platform. regular process would be: 1) create a /platform directory, for example /platform/freebsd but since freebsd is a unix, probably you do not need to do that and you can handle it in same /platform/unix directory 2) create a PharoSpur32FreeBSDConfig, taking CogFreeBSDConfig and PharoSpur32UnixConfig (already there) as models. no idea what changes you need to have. we could probably get a freebsd slave to add the build to our building process, I donât know :) cheers, Esteban > > Regards > Andreas >

April 3, 2015

Re: [Pharo-dev] Playground opening issue

by Jigyasa Grover

Hey Tudor I checked it , works fine for me :) Thanks and Regards Jigyasa Grover On Fri, Apr 3, 2015 at 4:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > The same issue happens with the inspector. > > And it also concerns maximization (so, once maximized, the next window > also starts with the maximized size). > > I opened another issue and committed associated fixes: > > https://pharo.fogbugz.com/f/cases/15294/Playground-and-Inspector-should-not… > > Could you test this as well? > > Cheers, > Doru > > > > On Thu, Apr 2, 2015 at 10:51 PM, Jigyasa Grover <grover.jigyasa1(a)gmail.com > > wrote: > >> Hi ! >> It works for me too :) >> I checked it in Pharo4.0 (Latest update: #40592) >> Thanks >> >> On Fri, Apr 3, 2015 at 1:30 AM, Franck Warlouzet < >> franck.warlouzet(a)hotmail.fr> wrote: >> >>> Nice it works, thank you ! >>> >>> Cheers, >>> Franck >>> >>> ------------------------------ >>> Date: Thu, 2 Apr 2015 21:34:11 +0200 >>> From: tudor(a)tudorgirba.com >>> To: pharo-dev(a)lists.pharo.org >>> Subject: Re: [Pharo-dev] Playground opening issue >>> >>> >>> Ok. A fix is committed: >>> >>> Name: GT-Playground-TudorGirba.102 >>> Author: TudorGirba >>> Time: 2 April 2015, 9:32:45.226868 pm >>> UUID: 4f8af56e-4904-443d-8e04-2d4e464efc22 >>> Ancestors: GT-Playground-AndreiChis.101 >>> >>> 15281 Playground opening issue >>> >>> do not react on minimization >>> >>> >>> Cheers, >>> Doru >>> >>> >>> On Thu, Apr 2, 2015 at 9:28 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>> This is a fun one. I will take a look. >>> >>> Cheers, >>> Doru >>> >>> On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet < >>> franck.warlouzet(a)hotmail.fr> wrote: >>> >>> I opened a Fogbugz entry : >>> >>> https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue >>> >>> ------------------------------ >>> From: franck.warlouzet(a)hotmail.fr >>> To: pharo-dev(a)lists.pharo.org >>> Date: Thu, 2 Apr 2015 15:26:31 +0200 >>> Subject: [Pharo-dev] Playground opening issue >>> >>> >>> Hello, >>> >>> Open a new Playground when one of the others is already opened is ok, >>> but if all of the Playgrounds are minimalized, the new one will be opened >>> very very small (Too small to be used). >>> >>> Cheers, >>> Franck >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

April 3, 2015

Re: [Pharo-dev] FileUrl: Removal Rationale

by Norbert Hartl

> Am 02.04.2015 um 23:55 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > Sven Van Caekenberghe-2 wrote >> Having subclasses for each scheme is hard to maintain (there are hundreds >> of schemes)... It also makes little sense implementation wise. > > Iâm not understanding. For one thing, in Core, weâre not interested in all > of the hundreds of schemes but just the few most common (http, file) - > although users interested in the specifics of other schemes could easily add > those subclasses in their apps. Since subclassing is just a way to share > code, wouldnât a ZnFileUrl merely consist of exactly the methods weâre > talking about - but more simply implemented? For one thing, it seems it > would make extension easier. If I wanted to handle FileUrls and HttpUrls > polymorphically with separate classes, no problem - implement two methods. > But as it is now, IIUC I have to either implement two operation classes or > have a method with a budding switch statement. Also, IMHO implementing a > custom multiple dispatch seems exotic enough (i.e. takes extra effort to > understand) to require a large benefit to justify. > I think the problem is that URI structure/format and interpretation are mixed together generating that problem. Sven is right about not having additional classes for URIs. An URI is an URI regardless how it looks like foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose The authority is optional, so URI wise there is no difference between a file URI and another one. The difference is in the interpretation of them. The interpreting part (the handler) is selected by the scheme. Having scheme as a registry would enable one to register his own handler for dealing with certain schemes. The downside is that dealing with URIs would be harder because you would need to use an extra selector between all calls that does the dispatch over the handler. A anZnUrl handler asFileReference This way there would be a FileHandler that implements #asFileReference. Other handlers might give a DNU. I understand the wish to keep the usage of ZnUrl simple not having to use extra selectors. But that wish turns out to be the problem IMHO and subclassing ZnUrl is not a cure for it just a way to make it worse. my 2 cents, Norbert

April 3, 2015

Re: [Pharo-dev] Playground opening issue

by Tudor Girba

The same issue happens with the inspector. And it also concerns maximization (so, once maximized, the next window also starts with the maximized size). I opened another issue and committed associated fixes: https://pharo.fogbugz.com/f/cases/15294/Playground-and-Inspector-should-not… Could you test this as well? Cheers, Doru On Thu, Apr 2, 2015 at 10:51 PM, Jigyasa Grover <grover.jigyasa1(a)gmail.com> wrote: > Hi ! > It works for me too :) > I checked it in Pharo4.0 (Latest update: #40592) > Thanks > > On Fri, Apr 3, 2015 at 1:30 AM, Franck Warlouzet < > franck.warlouzet(a)hotmail.fr> wrote: > >> Nice it works, thank you ! >> >> Cheers, >> Franck >> >> ------------------------------ >> Date: Thu, 2 Apr 2015 21:34:11 +0200 >> From: tudor(a)tudorgirba.com >> To: pharo-dev(a)lists.pharo.org >> Subject: Re: [Pharo-dev] Playground opening issue >> >> >> Ok. A fix is committed: >> >> Name: GT-Playground-TudorGirba.102 >> Author: TudorGirba >> Time: 2 April 2015, 9:32:45.226868 pm >> UUID: 4f8af56e-4904-443d-8e04-2d4e464efc22 >> Ancestors: GT-Playground-AndreiChis.101 >> >> 15281 Playground opening issue >> >> do not react on minimization >> >> >> Cheers, >> Doru >> >> >> On Thu, Apr 2, 2015 at 9:28 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> This is a fun one. I will take a look. >> >> Cheers, >> Doru >> >> On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet < >> franck.warlouzet(a)hotmail.fr> wrote: >> >> I opened a Fogbugz entry : >> >> https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue >> >> ------------------------------ >> From: franck.warlouzet(a)hotmail.fr >> To: pharo-dev(a)lists.pharo.org >> Date: Thu, 2 Apr 2015 15:26:31 +0200 >> Subject: [Pharo-dev] Playground opening issue >> >> >> Hello, >> >> Open a new Playground when one of the others is already opened is ok, but >> if all of the Playgrounds are minimalized, the new one will be opened very >> very small (Too small to be used). >> >> Cheers, >> Franck >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

April 3, 2015

Re: [Pharo-dev] Pharo sprint on Friday, 3rd April

by Jigyasa Grover

Hey Marcus Anything up there for the beginners ? On Fri, Apr 3, 2015 at 4:35 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Mar 2015, at 09:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > This means having a look at the issue tracker to find some issue that are > interesting to work on could be an idea. > > Maybe a trello board could be used to sync for the remote sprinters. > > > https://trello.com/b/OQ2k210W > > It is public for viewing, for editing I think we need to add people. > > > I started to add cases that people can look at. > > Marcus >

April 3, 2015

Re: [Pharo-dev] Pharo sprint on Friday, 3rd April

by Marcus Denker

> On 28 Mar 2015, at 09:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> This means having a look at the issue tracker to find some issue that are >> interesting to work on could be an idea. >> >> Maybe a trello board could be used to sync for the remote sprinters. >> > > https://trello.com/b/OQ2k210W <https://trello.com/b/OQ2k210W> > > It is public for viewing, for editing I think we need to add people. > I started to add cases that people can look at. Marcus

April 3, 2015

Re: [Pharo-dev] [Vm-dev] Re: Status of Pharo VM for FreeBSD

by Andreas Wacknitz

Am 03.04.15 11:13, schrieb Esteban Lorenzano: > >> On 02 Apr 2015, at 19:20, Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Andreas, >> >> sorry to be late in replying. This has been a busy month (I >> moved house). >> >> On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz <a.wacknitz(a)gmx.de >> <mailto:a.wacknitz@gmx.de>> wrote: >> >> >> Hi Eliot, >> >>> Am 11.03.2015 um 23:15 schrieb Eliot Miranda >>> <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >>> >>> HI Andreas, >>> >>> On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz >>> <a.wacknitz(a)gmx.de <mailto:a.wacknitz@gmx.de>> wrote: >>> >>> >>> Hi Clement, >>> >>>> Am 11.03.2015 um 09:23 schrieb ClÃ©ment Bera >>>> <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >>>> >>>> Hello, >>>> >>>> About the FreeBSD VM, Holger Freyther worked on it so he's >>>> the best person to answer. I think some people used it and >>>> it was at least partially working. >>> Thatâs my impression. The VMMaker contains some FreeBSD >>> classes but I have the impression that they are not complete >>> (and probably outdated). >>> >>>> >>>> About your NativeBoost bug on openSolaris, need more >>>> information: >>>> >>>> - Can you confirm that you use an intel processor on your >>>> openSolaris machine ? I assume that yes but I ask because >>>> solaris were typically running on other processors. >>>> NativeBoost, as of today, works only with intel processor. >>>> >>> Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300). >>> >>>> - Do you build the Cog VM or Stack VM ? I mean PharoVMBuild >>>> or PharoSVMBuild ? I think the PharoSVMBuild does not >>>> include NativeBoost by default, that may be your problem. >>>> There's a fix somewhere... >>>> >>> PharoVM from "branch 'master' of >>> https://github.com/pharo-project/pharo-vm" (thus Cog VM). >>> >>> >>> I would like to fold back any changes into the svn master >>> repository for Cog. What are the diffs? (If you have time to >>> send me the diffs that would save me a lot of time). >> I donât know whether there is much to harvest from what I did. As >> far as I remember most of my work was hacking the generator image >> created by the pharo vm scripts (for my Mac) in order to make >> the resulting C code to compile under openindiana. The basis for >> Solaris was already there (and as far as I can see it is also in >> the Squeak VM sources). I only tweaked some definitions and includes. >> I will look at my notes tomorrow and will post if I will find >> something relevant. >> >> I am curios about the future of the PharoVM. The main development >> of the VM seem to happen in the SqueakVM (by you). Getting the >> Spur changes into the PharoVM seem to be a lot of work. >> >> >> Note that this will happen (or is already happening). Esteban is >> working on building the Spur version of Pharo, so he is doing this >> work. But actually it *isn't* that much work. There is basically a >> trio of new memory management files for each platform, e.g. >> platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the >> spur vm, spursrc/vm. The system is already set up to build multiple >> VMs (at least the svn tree is). > > > Yes, this is already done. We are building spur VMs and images since > awhile now. You can find all the related jobs here: > > https://ci.inria.fr/pharo/view/4.0-VM-Spur/ If I follow this link and what is being used there brings me to the ordinary PharoVm project on github: https://github.com/pharo-project/pharo-vm There are three branches: master, develop and spur64. Which one is being used to build PharoVM-spur32? > > And as Eliot saysâ¦ is not *much* workâ¦ except when it is :) > In fact, we were planning to release Pharo 4 (next week) with a Spur > VM, but we didnât finish all the small things around. So we will > release next July (or around) a Pharo 4S (S, for Spur) with âofficialâ > spur support. We do not want to stay to much time in older versions. > Also, our development process is different This explanation irritates me: Pharo 4 will be released soon with a Spur VM? And then around summer Pharo 4S? Isn't it a contradiction? > than squeak, AFAIKâ¦ we drop backward compatibility in a regular basis. > Which basically means we will move to spur and we will drop support > for older versions. That's OK, but I am still, hmm say confused, because Eliot is changing A LOT (just look at what has been released during the last days), but PharoVM hasn't been changed for some days (I am following the master branch closely). So there is a rapid development in the Cog branch of the SqueakVM. The changes in the PharoVM are much slower (at least as I recognise it). I have more questions but I am reluctant to disturb you further as you must be quite busy atm. Best regards Andreas > >> >> Wouldnât it be better to move back the changes of the PharoVM >> into the SqueakVM and have a united development? >> >> >> Well, I don't think the Pharo community will be willing to move to >> svn. SOme time I may be able to move to git. But yes, I *would* >> like to see important fixes merged back into the SqueakVM. I think >> this is very important. I'm too overloaded to look at the pharovm so >> I'm dependent on those working on the pharovm in giut to send me >> changes for integration. > > Right, we are happy with our process and I do not see it fitting with > svn. We changed a lot of âorganisationalâ stuff to ensure traceability > and âbuildabilityâ (if such word existsâ¦). And we have made a lot of > progress in that area using git and github infrastructure at a point > most of the time to incorporate a change we just accept a pull request. > To be able to do that: > - we have to be sure what version of each component (vm, plugin, > platform source) is part of the commit info. Thatâs why we keep > together both platform sources and image sources (using filetree > monticello format). That way each commit has everything we need to > build the new vm. In factâ¦ I have a script â./newVM <commit>â that > does a clone, prepares an image, generates sources and builds the vmâ¦ > then I can test if a pull request is valid. But most of the time that > is not needed, because: > - for each pull request, we fire a travis job that creates a vm from > scratch and then runs all tests we have in Pharo (and we have improved > a lot in that area latest years). They are not âvm specific testsâ, > but since they tests all the system, if vm does not crashes and tests > are run, we can be sure is working (this wouldnât be possible without > right traceability). > - we also build the vm using CMake, but not directly, we use > CMakeMaker which allow us to define the build in smalltalk. > - finally, we would like to use the other capabilities (for > documentation, etc.) we gain for free by using github. Not that we are > already using itâ¦ but we would like, in the future. > Is there an up-to-date documentation of the processes? Especially if I want to add more platform support (like openindiana or FreeBSD)? My time is very limited (my day job is quite different from what I do in my spare time + my family and my house also need a lot attention + next to my Smalltalk interets I am also interested in operating systems) so my reaction time is sometimes quite slow :) > Soâ¦ obviously all of this can be achieved without using git and > githubâ¦ but there the infrastructure is already done. > > Said that. Even if we actually have a different process, we (Myself, > particularly) are trying to reduce the gap between both VMs. And right > now this is the status: > - in the VM itself there is almost no change. AFAIR, just two small > things: > a) I include setjmp.h somewhere, because compiler was asking for it > (We use different versions than Eliot) > b) the macro to read the image is changed, because we needed to change > it for allow build an iOS image. This is just one line in the image > and the addition of one macro in 4 platform sources (Linux, Win and > Mac redirects to old macro, but iOS implements something different) > - In the platforms we have the most important difference, because we > deprecated the âMac OSâ branch in favor of âiOSâ, which in fact should > be called OSX, because is the Cocoa version. I understand Eliot want > to go in that direction soon so we will align in that area too (btw, > that branch has growth organically so we'll need to do some > reorganisation to clarify it, eventually) > - in the plugins, we try to adopt a different approach than the > previous one: instead using particularities of the platform, we want > to align sources as much as possible, so we use the posix libraries. > Again, thatâs just when is possible (and when we have time). The most > important change we produced here is with FilePlugin: we changed it to > provide posix-permissions (and soon we will add primitives to retrieve > also ownership). To allow that, we changed a lot in the windows > version of the plugin, because instead windows functions we use MinGW. > We would like to see this changes merged. > > After that, I think there will be some other minor changesâ¦ not many, > and most probably we can remove those differences. > > hope this clarify all :) That's a nice explanation at least. But I am still confused. Especially because you didn't mention NativeBoost :) The ffi area also seem to be different and i a flux. And still: How to integrate more platforms? Regards Andreas

April 3, 2015

Re: [Pharo-dev] editing in Spotter code pane

by Tudor Girba

Hi, On Fri, Apr 3, 2015 at 10:56 AM, Ben Coman <btc(a)openinworld.com> wrote: > I've just started trying to make more use of the code pane in Spotter. It > seemed ideal for the case when I want to add "self haltOnce" to a dozen > methods. However when I hit <enter> to get a new line, Spotter closes. > > Additionally the Browser that opens doesn't contain the change I made in > Spotter - they've been thrown away. > > I propose that when the cursor is inside the code pane, it doesn't close > Spotter. Even at this late stage, could this be done for Pharo 4? Only > because I am guessing this since Spotter is a core tool, this might end up > a common complaint as people adapt their workflow to use Spotter more. > Spotter is primarily a search tool that has no modes. Editing in place is certainly an important use case, but we should not treat it lightly. For example, Enter is the keybinding for triggering the default action on the selected item. Allowing the editor to take precedence in handling it will introduce a mode and this will change the core of Spotter. And there is something else. Right now, the editor shows you the whole method including the signature because that is the default. What happens when I change the name of the method in the preview? This would require updating the search list, which is not a use case Spotter is made for at this point. All in all, I would not add this support now, because it requires more thinking. > Would it be safer at this late stage prior to Release that this be done as > a Slice, to limit other changes that might come through the Spotter > Configuration? > There will be another integration of GT before the release. Cheers, Doru > > cheers -ben > -- www.tudorgirba.com "Every thing has its own flow"

April 3, 2015

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

by kilon alios

I did not know that, thanks On Fri, Apr 3, 2015 at 12:39 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 02 Apr 2015, at 18:16, phil(a)highoctane.be wrote: > > Welcome to the club of GT is awesome and sometimes freezes it all. > > Happened to me once or twice this morning as well. > Switched back to basic inspector for a couple things. > > Having both options available would be nice (like inspect = basic /explore > = gt). > > > you *have* both options > (i) inspect = GT > (I) basic inspect = basic inspect :) > > Esteban > > > Phil > > On Thu, Apr 2, 2015 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: > >> This morning GTInspector was so slow that it blocked the complete system >> on the machine of Cyril. :( >> We can tell him that he is stupid to have a bad machine or we could try >> to use this to see how >> we can help our users. >> >> So we had to use basicInspect to get our job done (once we ctrl-. to >> escape the render hell) >> because raw uses a tree morph. >> >> Why raw cannot reproduce the old simple and working basicInspect >> then we could have a "basic" inspect on double click to avoid to use this >> bad tree and that we can work. >> >> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even >> on my superfast machine is >> is sluggish. >> >> I really think that we should support backdoors. >> We need to have a mini browser, a mini debugger and a working inspector. >> >> Setf >> >> > > > > > >

April 3, 2015

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

by Esteban Lorenzano

> On 02 Apr 2015, at 18:16, phil(a)highoctane.be wrote: > > Welcome to the club of GT is awesome and sometimes freezes it all. > > Happened to me once or twice this morning as well. > Switched back to basic inspector for a couple things. > > Having both options available would be nice (like inspect = basic /explore = gt). you *have* both options (i) inspect = GT (I) basic inspect = basic inspect :) Esteban > > Phil > > On Thu, Apr 2, 2015 at 5:30 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > This morning GTInspector was so slow that it blocked the complete system on the machine of Cyril. :( > We can tell him that he is stupid to have a bad machine or we could try to use this to see how > we can help our users. > > So we had to use basicInspect to get our job done (once we ctrl-. to escape the render hell) > because raw uses a tree morph. > > Why raw cannot reproduce the old simple and working basicInspect > then we could have a "basic" inspect on double click to avoid to use this bad tree and that we can work. > > just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even on my superfast machine is > is sluggish. > > I really think that we should support backdoors. > We need to have a mini browser, a mini debugger and a working inspector. > > Setf > > > > > >

April 3, 2015