- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by stepharo

his is LuaTeX, Version beta-0.79.1 (TeX Live 2014) (rev 4971) Execute 'luatex --credits' for credits and version details. There is NO warranty. Redistribution of this software is covered by the terms of the GNU General Public License, version 2 or (at your option) any later version. For more information about these matters, see the file named COPYING and the LuaTeX source. Copyright 2014 Taco Hoekwater, the LuaTeX Team. Le 29/11/14 09:23, Luc Fabresse a Ã©crit : > luatex -v

Nov. 30, 2014

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

by stepharo

Tx dale. Yes it was like that :) Le 30/11/14 16:58, Dale Henrichs a Ã©crit : > 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 <mailto:dionisiydk@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? > > >

Nov. 30, 2014

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

by stepharo

+1 It was like that. > >> On 30 Nov 2014, at 13:41, Denis Kudriashov <dionisiydk(a)gmail.com >> <mailto:dionisiydk@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] Video Tutorial - Github for Pharo using Sourcetree

by Dale Henrichs

Eliot, If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ... `adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ... My statement about "as the community begins to use git-based repos as their primary repository" includes a broad definition of community, in my mind:) Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ... So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?) Dale On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > 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

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