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

Pharo vm, launcher and pillar packages

by Markus Fritsche

Hi, I created the vm packages for trusty at: https://launchpad.net/~fritsche-markus-z/+archive/ubuntu/pharo as a test. If you are on ubuntu or have access to an ubuntu 14.04 installation, can you please test these packages and provide feedback by replying to this mail? Thank you in advance, Markus

Nov. 30, 2014

tests coverage of minimal Pharo

by Pavel Krivanek

Hi, I set the job for tests coverage testing of the mimimal Pharo using Hapao: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2… To load results you should load ConfigurationOfSUnit and ConfigurationOfKernelTests from Pharo/SystemConfigurations repository into an image with Hapao. Then inspect: FLMaterializer materializeFromFileNamed: 'hapao.fuel'. Do not try to visualise it ;-) Currently blacklisted classes are: Array Association ArrayedCollection Behavior BlockClosure ByteSymbol ByteString ClassDescription CompiledMethod Class Dictionary Hapao2Package HashedCollection IdentityDictionary Integer LookupKey FileStream Magnitude Object ProtoObject Process ProcessLocalVariable ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage SmalltalkImage SequenceableCollection Set Semaphore SmallInteger Symbol String SourceFileArray VirtualMachine OCCompilerTest SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack S2StringNewPlugin S2TestException S2Tester S2TesterClass S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod S2pySenderStubPackage Cheers, -- Pavel

Nov. 30, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Eliot Miranda

Hi Dale, On Nov 30, 2014, at 8:14 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios(a)gmail.com> wrote: >> So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. > > Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ... > > The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history. > > When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too. > > I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ... > > As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ... Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello? > Dale

Nov. 30, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by kilon alios

ok Dale thanks for the explanation it makes things much clearer right now. I am glad it works well for you that means it will work well for me too and thus I am now much less reluctant to recommend it. Will give it a try and make a nice tutorial about it , together with gitfiletree. On Sun, Nov 30, 2014 at 6:14 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> So far all I knew that using git for binary files was a no go, doable >> but not recommended. Thus I found strange that filetree uses binary files. >> >> > Well the files are text files, but because the text represents structured > data, the line-based auto-merge used by git is not correct ... > > The monticello version files have been included in FileTree to make it > possible to move the packages seamlessly between Filetree-based > repositories and mcz based repositories ... without that meta data, once > you move a package to FileTree it could not be moved back into an mcz > repository without losing all of the package history. > > When I was first introducing FileTree, I thought it was important that > folks be able to test out the git waters without making an "irreversible > commitment to git." Even today I find myself needing to move packages back > and forth between git and mcz repositories, so Thierry's merge-tools has > made it possible for me to have my cake and eat it too. > > I have been threatening to remove the monticello meta data from FileTree > (or at least make it optional), but I just haven't had the time or > motivation to do so ... again Thierry's merge-tool means that I never have > to deal with a manual merge of the version file, so for me I never have to > think about it ... > > As the tool sets for supporting git improve and as the community begins to > use git-based repos as their primary repository, it will make sense to > remove the monticello meta data from FileTree ... > > Dale >

Nov. 30, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Dale Henrichs

On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > So far all I knew that using git for binary files was a no go, doable but > not recommended. Thus I found strange that filetree uses binary files. > > Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ... The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history. When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too. I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ... As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ... Dale

Nov. 30, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Dale Henrichs

Actually, SS3 and smalltalkhub appeared about the same time. Tobias Pape had been slowly improving the GemStone version of SqueakSource3 and I got tired of waiting 2-3 days for SqueakSource to come back from a crash, so I pushed SS3 up as an Alpha to get something up that was more stable than SqueakSource. About the same time, SmalltalkHub was made available and I didn't want to compete with SmalltalkHub and at the time it seemed to have potential, so I backed off on my plans to go beyond the Alpha release of SS3. There were several sets of known bugs and performance issues ... but it was and still is Alpha and was never intended to go into production. After several months of development, SmalltalkHub had not quite made it to be production ready and Stef asked me to start backing up SS3 so that it could be used for production apps ... I reluctantly agreed, because at the time SqueakSource was very unstable and something was needed ... Unfortunately the time window for me to have time to devote time to SS3 had passed and Tobias was busy with his work as well. And it took longer than originally anticipated for SmalltalkHub to be ready for prime time. Tobias has continued to work on the SqueakSource3 code base and bring it way beyond the Alpha version that is in production. The folks at Hasso Plattner Institute are using Tobias' SqueakSource3 in production for their Smalltalk repos. But it seemed to not be worth the effort to try to compete with SmalltalkHub ... the original intent of SS3 being brought into production was to be a stopgap measure until SmalltalkHub was ready... Today, I am using GitHub for all of my projects ([1], [2], [3], and [4]) so again I just don't have the time to devote to SS3 to incorporate the improvements that Tobias has had (for years now) .... Neither SqueakSource3 nor SmalltalkHub comes close to the collaborative feature set of GitHub and I personally would rather devote my own time and effort to new Smalltalk projects than trying to duplicate GitHub in Smalltalk. We continue to host SS3, with all of its Alpha warts because is very stable and a number of folks use it on a daily basis... Dale [1] https://github.com/GsDevKit [2] https://github.com/glassdb [3] https://github.com/dalehenrich [4] https://github.com/CampSmalltalk On Sun, Nov 30, 2014 at 4:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> btwâ¦ historic reference: sthub was never intended to be there for stay. I >> remember talking about it with Nico and Stef, more than two years ago, >> before sthub came online, and our conclusion at the time was: âyes, the >> future it will be git, but until we get there, letâs put sthub online >> because sqsource cannot handle more projects" > > > And why you not choose squeaksource3 which maintained by gemstone team and > includes all features from old squeaksource? Why you instead develop sthub > if you not believe in it? > > >

Nov. 30, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by kilon alios

I dont disagree but when it comes to me making a tutorial about something then foremost I want to know exactly what I am talking about. So its pointless for me to talk about merges using filetree and gitfiletree unless I understand these specific topic inside out. I dont have a problem getting a phd, I am a bookworm by nature anyway and I love learning. I am not saying also that tools are not needed to make things easier, obviously if tools make life easier then I am all for using them. But I need to make sure first that the tools you guys make work well in practice to recommend them to my viewers. Thats how serious teaching works. So I think for now would be better if I get more experience with merges as Thierry said and study more the internals of git. So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. On Sun, Nov 30, 2014 at 5:20 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> >> "The important take-away from this is that when working with git and >> Smalltalk you must track the SHA that has been loaded into the image (the >> latest version of Metacello tracks this information in the project >> registry) and you must have in-image tool support for recognizing SHA skew. >> It's not absolutely necessary to provide a tool for `skew save`, but it >> _is_ tedious to "merge your way out of trouble" manually and in-image tools >> make this situation much more tolerable ..." >> >> well I have to confess all this is way out of my league :D >> > > Haha ... and that's the point ... with tool support you don't have to be > "in that league":) > > >> As I said before I have done some merges with git, but nothing so complex >> to require knowing all this stuff. But then I work mostly on my own small >> projects and not in large teams. >> > > FWIW, I was getting myself into this trouble, by working in multiple > images that were distributed over time ... I would come back to an older > image and discover that I'd updated one of my shared projects and I had > modifications to that project that I wanted to save ... > > Tools are supposed to help people who do not have a PHD in git and not get > in the way of those who do:) > > Dale > >

Nov. 30, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Dale Henrichs

On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > "The important take-away from this is that when working with git and > Smalltalk you must track the SHA that has been loaded into the image (the > latest version of Metacello tracks this information in the project > registry) and you must have in-image tool support for recognizing SHA skew. > It's not absolutely necessary to provide a tool for `skew save`, but it > _is_ tedious to "merge your way out of trouble" manually and in-image tools > make this situation much more tolerable ..." > > well I have to confess all this is way out of my league :D > Haha ... and that's the point ... with tool support you don't have to be "in that league":) > As I said before I have done some merges with git, but nothing so complex > to require knowing all this stuff. But then I work mostly on my own small > projects and not in large teams. > FWIW, I was getting myself into this trouble, by working in multiple images that were distributed over time ... I would come back to an older image and discover that I'd updated one of my shared projects and I had modifications to that project that I wanted to save ... Tools are supposed to help people who do not have a PHD in git and not get in the way of those who do:) Dale

Nov. 30, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Esteban Lorenzano

> On 30 Nov 2014, at 13:41, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > btwâ¦ historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects" > > And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it? Smalltalkhub was already there. Question was if we put it online or not, not if we develop it or not. ss3 was there but Dale always said (at the time) that was a proof of concept and that having time for work on it was complicated (and search was severely broken, and it was slow and we were having *real* problems when doing massive downloads). both situations are probably fixed now, but at the time having a 3rd solution for the community looked like a good idea. and I believe it was. Even if you plan, in the future, to provide something else that you believe is better, when you are developing something like Pharo you have certain responsibilities with your community, you cannot drop something without having already a good replacement. We needed a solution soon, we had sthub, so it was a good match. and look nowâ¦ I still believe the future is using Git as our central source management system, but we are still not there, tools are still not good enough and then, we still need to have tools like sthub. Esteban > >

Nov. 30, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Denis Kudriashov

2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > btwâ¦ historic reference: sthub was never intended to be there for stay. I > remember talking about it with Nico and Stef, more than two years ago, > before sthub came online, and our conclusion at the time was: âyes, the > future it will be git, but until we get there, letâs put sthub online > because sqsource cannot handle more projects" And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?

Nov. 30, 2014