- Pharo-dev - lists.pharo.org

Pharo-4.0-Update-Step-3-Minimal versus MCWorkingCopyBrowser

by Ben Coman

I am checking why the .10 slice for Issue-14261-Delay-refactoring-part-1 is breaking build of the Jenkins > Pharo-4.0-Update-Step-3-Minimal. As an aside, I discovered opening (and closing) Monticello in the image prior to running shrink.st makes it fragile. With the scripts for build 40384 from... https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-3-Minimal/243/ 1. I opened the 40384.image with pharo-ui 2. Opened Monticello and browsed to the .10 slice of issue 14261 but did not load it 3. Saved the image 4. Ran my cobbled ./shrink.sh shown here... #!/bin/bash -x IMAGE=Pharo-minimal # wget -O - http://get.pharo.org/vm | bash ./pharo *.image save $IMAGE --delete-old ./pharo $IMAGE.image unloadNB.st ./pharo $IMAGE.image cleanAfterNB.st ./pharo $IMAGE.image prepareShrink.st ./pharo $IMAGE.image shrink.st which fails with... 11 IndentingListItemMorph(Object)>>doesNotUnderstand: #theme 12 IndentingListItemMorph(StringMorph)>>defaultColor 13 IndentingListItemMorph(Morph)>>initialize ... 23 MCWorkingCopyBrowser(Object)>>changed: shrink.st is more robust with the following... MCWorkingCopyBrowser allInstances do: [ :mcwcb | SystemAnnouncer uniqueInstance unsubscribe: mcwcb ]. added to shrink.st. I put it after existing line... SystemAnnouncer uniqueInstance unsubscribe: NOCCompletionTable. HTH, cheers -ben

Nov. 26, 2014

Re: [Pharo-dev] Athens Repository (NativeBoost)

by Nicolai Hess

2014-11-26 14:54 GMT+01:00 Igor Stasenko <siguctua(a)gmail.com>: > > > On 26 November 2014 at 08:33, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> On 25 Nov 2014, at 23:39, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> >> >> 2014-11-24 23:34 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> both are integrated into the image. >>> while NB has been maintained directly, athens should still be loadable >>> (if not the caseâ¦ we have a problem for the future :P). >>> >> >> what does that mean for athens, yes unload and loadable from the image or >> loadable from the sthub repository? >> >> >> > The process is simple: > - Athens has own repository where its sources are maintained and updated > etc.. > - an updates then can be loaded into Pharo image(s), so it can come with > Pharo distribution by default. > > It is important to keep this project in separate repository, that helps > with managing it and producing predictable results. > Ah, that is what I wanted to know. > The fact that Athens are part of Pharo distribution don't means, that its > repository should be abandoned and all updates should come directly to > Pharo. That would be a huge mistake. > That's how I've done it recently. I'll merge the changes from pharo -> athens repository. > Doing everything in a monolithic image is a planning mess, and works fine > only for bug fixing or small refactorings. > > Anything which requires sizable planning and designing, should have own > line of development and maintenance, > like that there's a clear separation of the responsibility for maintaining > the project in healthy state and less bottlenecks. > > > no ideaâ¦ I guess is the same case, but I have no control over that area. >> Igor will know better :) >> >> Esteban >> >> >> > > -- > Best regards, > Igor Stasenko. >

Nov. 26, 2014

class variable slots?

by Tudor Girba

Hi, As far as I see, the class variables are not slots. Is that correct? If not, how do I get the slots? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 26, 2014

Re: [Pharo-dev] Athens Repository (NativeBoost)

by Igor Stasenko

On 26 November 2014 at 08:33, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 25 Nov 2014, at 23:39, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2014-11-24 23:34 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> both are integrated into the image. >> while NB has been maintained directly, athens should still be loadable >> (if not the caseâ¦ we have a problem for the future :P). >> > > what does that mean for athens, yes unload and loadable from the image or > loadable from the sthub repository? > > > The process is simple: - Athens has own repository where its sources are maintained and updated etc.. - an updates then can be loaded into Pharo image(s), so it can come with Pharo distribution by default. It is important to keep this project in separate repository, that helps with managing it and producing predictable results.The fact that Athens are part of Pharo distribution don't means, that its repository should be abandoned and all updates should come directly to Pharo. That would be a huge mistake. Doing everything in a monolithic image is a planning mess, and works fine only for bug fixing or small refactorings. Anything which requires sizable planning and designing, should have own line of development and maintenance, like that there's a clear separation of the responsibility for maintaining the project in healthy state and less bottlenecks. no ideaâ¦ I guess is the same case, but I have no control over that area. > Igor will know better :) > > Esteban > > > -- Best regards, Igor Stasenko.

Nov. 26, 2014

Re: [Pharo-dev] Pharo is mine

by Esteban Lorenzano

(sorry, headers messedâ¦ damn you Mail) > On 26 Nov 2014, at 08:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 25 Nov 2014, at 23:31, kilon alios <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> >> >> 2014-11-24 23:34 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> both are integrated into the image. >> while NB has been maintained directly, athens should still be loadable (if not the caseâ¦ we have a problem for the future :P). >> >> what does that mean for athens, yes unload and loadable from the image or loadable from the sthub repository? > > no ideaâ¦ I guess is the same case, but I have no control over that area. > Igor will know better :) > > Esteban > >> >> >> >> yes, we are slowly moving in the opposite direction of âall maintained in the imageâ, and eventually we plan/dream to have a small kernel and a bunch of configurations to produce Pharo. >> >> now, about NB, we do not have special plans. >> it is in the image and it will be maintained as part of Pharo. >> >> now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a âunified FFIâ, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo). >> Againâ¦ this are just ideas for the future :) >> >> Esteban >> >> >> >>> On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> >>> 2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>>: >>> Hi, >>> >>> were is NB currently maintained? Only within the image as it is integrated >>> or still with an external config and on STHub? >>> >>> The reason why I ask: when I load the latest NB-Core package >>> from STHub it looks like this one is outdated and back from Pharo3 day >>> (trying to load it gives problems from changes in Pharo 4). >>> >>> So it looks like NB was originally developed external using STHub, then integrated >>> into standard image and now it is only internally in-image managed. OK. >>> >>> But the future goal is as far as I understood to manage more and >>> more packages using external configs again. >>> >>> What is the status and future plan for NB? Will the repo get >>> synchronized? Or will it stay internal only? >>> >>> Thx >>> T. >>> >>> >>> I was about to ask the same question for Athens, the packages in pharo4 and sthub diverge. >>> I can merge the sthub and pharo4 version for Athens (and mabe NB), I just don't know what >>> is the plan for the feauture, manage packages for Athens and NB in the image or on sthub. >>> >> >> >

Nov. 26, 2014

Re: [Pharo-dev] Athens Repository (NativeBoost)

by Esteban Lorenzano

> On 25 Nov 2014, at 23:39, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2014-11-24 23:34 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > both are integrated into the image. > while NB has been maintained directly, athens should still be loadable (if not the caseâ¦ we have a problem for the future :P). > > what does that mean for athens, yes unload and loadable from the image or loadable from the sthub repository? no ideaâ¦ I guess is the same case, but I have no control over that area. Igor will know better :) Esteban > > > > yes, we are slowly moving in the opposite direction of âall maintained in the imageâ, and eventually we plan/dream to have a small kernel and a bunch of configurations to produce Pharo. > > now, about NB, we do not have special plans. > it is in the image and it will be maintained as part of Pharo. > > now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a âunified FFIâ, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo). > Againâ¦ this are just ideas for the future :) > > Esteban > > > >> On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> 2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>>: >> Hi, >> >> were is NB currently maintained? Only within the image as it is integrated >> or still with an external config and on STHub? >> >> The reason why I ask: when I load the latest NB-Core package >> from STHub it looks like this one is outdated and back from Pharo3 day >> (trying to load it gives problems from changes in Pharo 4). >> >> So it looks like NB was originally developed external using STHub, then integrated >> into standard image and now it is only internally in-image managed. OK. >> >> But the future goal is as far as I understood to manage more and >> more packages using external configs again. >> >> What is the status and future plan for NB? Will the repo get >> synchronized? Or will it stay internal only? >> >> Thx >> T. >> >> >> I was about to ask the same question for Athens, the packages in pharo4 and sthub diverge. >> I can merge the sthub and pharo4 version for Athens (and mabe NB), I just don't know what >> is the plan for the feauture, manage packages for Athens and NB in the image or on sthub. >> > >

Nov. 26, 2014

Re: [Pharo-dev] Pharo is mine

by Esteban Lorenzano

> On 25 Nov 2014, at 23:31, kilon alios <kilon.alios(a)gmail.com> wrote: > > > > 2014-11-24 23:34 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > both are integrated into the image. > while NB has been maintained directly, athens should still be loadable (if not the caseâ¦ we have a problem for the future :P). > > what does that mean for athens, yes unload and loadable from the image or loadable from the sthub repository? no ideaâ¦ I guess is the same case, but I have no control over that area. Igor will know better :) Esteban > > > > yes, we are slowly moving in the opposite direction of âall maintained in the imageâ, and eventually we plan/dream to have a small kernel and a bunch of configurations to produce Pharo. > > now, about NB, we do not have special plans. > it is in the image and it will be maintained as part of Pharo. > > now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a âunified FFIâ, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo). > Againâ¦ this are just ideas for the future :) > > Esteban > > > >> On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> 2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>>: >> Hi, >> >> were is NB currently maintained? Only within the image as it is integrated >> or still with an external config and on STHub? >> >> The reason why I ask: when I load the latest NB-Core package >> from STHub it looks like this one is outdated and back from Pharo3 day >> (trying to load it gives problems from changes in Pharo 4). >> >> So it looks like NB was originally developed external using STHub, then integrated >> into standard image and now it is only internally in-image managed. OK. >> >> But the future goal is as far as I understood to manage more and >> more packages using external configs again. >> >> What is the status and future plan for NB? Will the repo get >> synchronized? Or will it stay internal only? >> >> Thx >> T. >> >> >> I was about to ask the same question for Athens, the packages in pharo4 and sthub diverge. >> I can merge the sthub and pharo4 version for Athens (and mabe NB), I just don't know what >> is the plan for the feauture, manage packages for Athens and NB in the image or on sthub. >> > >

Nov. 26, 2014

Re: [Pharo-dev] NativeBoost

by Esteban Lorenzano

> On 25 Nov 2014, at 20:27, Markus Fritsche <mfritsche(a)reauktion.de> wrote: > > > > On Tue, Nov 25, 2014 at 5:06 AM, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > Please enlighten me as well. I also do not yet understand the idea of this unification layer. > > "Unification layer" is just a name. IMO Ronie is doing something much more useful. He is architecting the marshalling layer of the FFI so that it can > - be portable > - work in both the Cog JIT and the Interpreter > This is effectively an abstract instruction set for executing low-level machine intsructions. It can be used for FFI call-out marshalling, but it can also be used for low-level code generation, and we are using it in Sista. COnsequently Ronie's "Low code" as it is properly called can be an integral component to both a high-quality FFI and a fast VM. > > For me this is a useful substrate for an FFI that can be high quality. But note that it is only one component. The other components are > - an image-level ABI compiler whose job it is to generate the correct marshalling code for different platforms. The FFI for processors such as IA64/x86-64 is complex, and a compiler is the only performant way to generate correct marshalling code > - callback machinery. I have already designed and implemented this in the context of Alien. The architecture is portable; it can function correctly on x86-64 and ARM, not just x86. > > > So far we have > 1. FFI -> not maintained very well, no callbacks > > This is simply false. The FFI was in active use at Qwaq where Cog was first implemented. I have continued to maintain and enhance it, reimplementing it so that it is a pure Smalltalk plugin with no assembler support code, so that it is reentrant. Recently Doug McPherson has implemented the ARM version alongside my original x86 version. yep, Iâm aware and I was trying to have time to bring those changes into Pharo. Hopefully soon. > > 2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination > > Every Cog VM supports Alien callbacks. The Alien package Alien-eem.24 at http://www.squeaksource.com/Alien <http://www.squeaksource.com/Alien> "jsut works", at least in Squeak. Try it. it works. We have ConfigurationOfOldAlien that loads all required (Is a bad name I choose because there was your sources and a fork from Luc and there were not in sync, so I took your sources and made a Configuration for them :P) > > 3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2. > > I disagree. NativeBoost has not been designed with portability in mind, nor has it been designed with interpretive VMs in mind. Further Igor made no attempt to work with me in providing the support he needs from Cog to integrate NativeBoost when I visited Rmod early this year. > > > According to my knowledge it was the goal to continue with NB, integrate it (which is done) > and move it forward as the single solution for external calls and callbacks. > > So why do we need another layer (and mixed approach with still old FFI) instead of working > on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there > already work for AsmJit for ARM? > > We have a functional FFI at the moment, FFI + Alien for callbacks. This is in industrial use, both at Terf (nee Qwaq) and Cadence. We have NativeBoost that does not work on ARM. We have Ronie's work on low code that fits both with a well-architected FFI and with Sista. > > I am frustrated that there is no coherence in our work here. I have a clear understanding of what architecture can work, a clear vision, and yet other than Ronie, all I see is FUD ("Alien doesn't work", "FFI doesn't work", "Alien callbacks don't work"; all false). I wish this wasn't the case. I do not have time right now to work on all of Spur, Spur 64, Sista and find time to architect the FFI. But I know how this stuff works (I've implemented what works now) and as the leads VM architect isn't it right that the community try and work with me rather than without me? Honestly, Iâm quite frustrated too. And I cannot agree with you more. But hopefully we will start to work on this problem and remove all discordances soon (I know in all other VM aspects we already did it and now we work aligned, so we can do this for FFI tooâ¦ in fact last month I wanted to work on it but then other work became more urgent). Esteban > > > Thx > T. > > > Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr > > Von: "Markus Fritsche" <mfritsche(a)reauktion.de <mailto:mfritsche@reauktion.de>> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > > Betreff: Re: [Pharo-dev] NativeBoost > > > > On 2014-11-24 23:34, Esteban Lorenzano wrote: > > > > > now, since the most common use of NB is for FFI, and NB is not present > > > in all platforms, we are working (Ronie, in this case) in a âunified > > > FFIâ, which will provide a common abstraction layer for several FFI > > > frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one > > > of the frameworks we use depending on the situation (but ideally, we > > > will maintain just one, the one that fits better in Pharo). > > > > I feel that providing a common abstraction layer on top of the various > > approaches to interface to C/ C++ libraries won't be useful and should > > be considered a waste of resources. From what I understood from the > > documentation, NativeBoost seems to be the most complete interface > > technology yet. I would rather (as in: If I was capable) try to get > > NativeBoost into Squeak and add the functionality missing that still > > justifies the existence of FFI and Alien than creating an abstraction > > layer that can't cope with the differences in the tools (which was the > > reason for their first creation despite the available ones). > > > > I tried to play around with FFI and creating plugins in Squeak and > > failed (I didn't try very hard though). NativeBoost was the first thing > > I was able to wrap a DLL myself and understand how to do it. The only > > thing that I wasn't able to wrap my mind around was finalization, but > > that is also due to the fact that I couldn't find understandable (read: > > understandable to me) documentation about the underlying concept in > > Pharo. > > > > (OT: Finalization and concurrency probably is more about the concept > > rather than the implementation in Pharo?) > > > > This is a piece of opinion. We all know, that unfortunately, one doesn't > > have to have knowledge to have an opinion, so if my opinion is wrong due > > to lack of knowledge, please ignore it. > > > > Best regards, > > Markus > > > > > > > > > > > -- > best, > Eliot

Nov. 26, 2014

Re: [Pharo-dev] Athens Repository (NativeBoost)

by Nicolai Hess

2014-11-24 23:34 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > both are integrated into the image. > while NB has been maintained directly, athens should still be loadable (if > not the caseâ¦ we have a problem for the future :P). > what does that mean for athens, yes unload and loadable from the image or loadable from the sthub repository? > > yes, we are slowly moving in the opposite direction of âall maintained in > the imageâ, and eventually we plan/dream to have a small kernel and a bunch > of configurations to produce Pharo. > > now, about NB, we do not have special plans. > it is in the image and it will be maintained as part of Pharo. > > now, since the most common use of NB is for FFI, and NB is not present in > all platforms, we are working (Ronie, in this case) in a âunified FFIâ, > which will provide a common abstraction layer for several FFI frameworks > (NB, OldFFI, Alienâ¦). With that, we can choose which one of the frameworks > we use depending on the situation (but ideally, we will maintain just one, > the one that fits better in Pharo). > Againâ¦ this are just ideas for the future :) > > Esteban > > > > On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares(a)gmx.de>: > >> Hi, >> >> were is NB currently maintained? Only within the image as it is integrated >> or still with an external config and on STHub? >> >> The reason why I ask: when I load the latest NB-Core package >> from STHub it looks like this one is outdated and back from Pharo3 day >> (trying to load it gives problems from changes in Pharo 4). >> >> So it looks like NB was originally developed external using STHub, then >> integrated >> into standard image and now it is only internally in-image managed. OK. >> >> But the future goal is as far as I understood to manage more and >> more packages using external configs again. >> >> What is the status and future plan for NB? Will the repo get >> synchronized? Or will it stay internal only? >> >> Thx >> T. >> >> > I was about to ask the same question for Athens, the packages in pharo4 > and sthub diverge. > I can merge the sthub and pharo4 version for Athens (and mabe NB), I just > don't know what > is the plan for the feauture, manage packages for Athens and NB in the > image or on sthub. > > >

Nov. 25, 2014

Re: [Pharo-dev] Pharo is mine

by kilon alios

>> Yes. It records where you go, per window, and you can navigate back and forth with Cmd â and Cmd â (they are called Back/Forward in the context menu). This was for me a very important feature to have. Feels great to have it, I tested , it works fine. >> Yes! I think trying themes is nice and may answer practical needs as well (including improving that part of the code and tracking all those hardcoded values). The default Pharo3 and Pharo4 themes have serious issues on my laptops, because the scrollbar lack so much contrast that it is unreadable most of the time :( yeap , I find blue soothing. When you stare at the screen for hours at least for , looking good is way more than just cosmetics. I had the same problem as you but with the Glamour theme with the Moose image. Nireas allow you to choose the background color for scrollbar but I have not implemented yet the color for the scrollbar handle itself. Nireas can create also light themes but unfortunately I have not dealt with the syntax highlighting colors yet but is certainly the next step. >> It seems I have a bug floating somewhere: some nodes may apparently loose their children (i.e. they appear as empty even if something is in there). have not experienced such a problem so far, but its ok, bugs are part of coding. On Wed, Nov 26, 2014 at 12:11 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Le 25/11/2014 22:53, kilon alios a Ã©crit : > >> yeap works like a charm now on Pharo4 and I have loaded development. I >> have also set up the SSH key so I am ready to rock. >> > > Cool. I'm still learning that Baseline + Git stuff, and it really seems > very convenient. I'll end up doing proper Configurations one day ;) > > I was also successful in following your instructions on finding the >> shortcuts. >> > > I saw that some usefull may be missing, and that I still can get some > default ones even so I tried to block them :( > > The one thing I miss from the original Browser is that history drop >> down, it help me avoid opening new windows. Ideally I would like >> something like bookmarks so I can navigate quickly back to classes that >> I have visted before. Does your browser do anything like that ? >> > > Yes. It records where you go, per window, and you can navigate back and > forth with Cmd â and Cmd â (they are called Back/Forward in the context > menu). > > looks like it works fine with themes I linked a blue theme I am testing >> for Nireas >> https://www.dropbox.com/s/ohr5jltw1x29vxo/Screenshot% >> 202014-11-25%2023.48.15.png?dl=0 which >> is a big plus for me . >> > > Yes! I think trying themes is nice and may answer practical needs as well > (including improving that part of the code and tracking all those hardcoded > values). The default Pharo3 and Pharo4 themes have serious issues on my > laptops, because the scrollbar lack so much contrast that it is unreadable > most of the time :( > > >> Will dive into code now and see what I can steal. I will keep you posted. >> > > I'll be listening. > > It seems I have a bug floating somewhere: some nodes may apparently loose > their children (i.e. they appear as empty even if something is in there). > > Thierry > > On Tue, Nov 25, 2014 at 8:42 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Kilon, >> >> I updated the configurations (and the Readme as well). It should >> load an up to date version on Pharo3 and Pharo4, whether in stable >> or in development mode. >> >> Note, I use baselines in with both github:// urls (stable) and >> gitfiletree:// urls (development). >> >> Thierry >> >> Le 25/11/2014 00:00, kilon alios a Ã©crit : >> >> >> >> >> I'm slowly learning to use baselines and github:// urls..., >> but the >> gitfiletree ones are so convenient for development. >> >> I used baseline for Nireas because it allows other users to >> install my >> app without the need to install git, I have not used gitfiletree >> because >> I heard that some people have corrupt commits with it or something >> similar and I am not experienced enough with git to deal with such >> issues plus filetree allowed me to use my familiar workflow that >> I had >> with python with command line git and github. But a tool like >> gitfieltree or gitfiletree itself is definetly the future of >> Pharo and >> git. Users like me that love git and github need a tool that >> offers >> close integration with git and I am certainly glad gitfiletree >> is around >> . I think I will give gitfiletree another try as well. >> >> Select the abstract class for commands, its >> AlTreeCommand (in >> >> Al-TreeMorph package). >> >> no idea where that is, I also used find class and cant find such >> class. >> Where is the Al-TreeMorph package ? >> >> also I tried some shortcuts CTRL+F does not work for me, it does >> nothing. I can open finder manually though. >> >> >> >> >> > >

Nov. 25, 2014