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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40392 Home: https://github.com/pharo-project/pharo-core

Dec. 1, 2014

[pharo-project/pharo-core] 8be654: 40392

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 8be654fa95e7a5c6d96607b7513e3dde8a1ffb74 https://github.com/pharo-project/pharo-core/commit/8be654fa95e7a5c6d96607b7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-01 (Mon, 01 Dec 2014) Changed paths: A Kernel.package/Float.class/class/instance creation/fromIEEE64Bit_.st A Kernel.package/Float.class/instance/printing/binaryLiteralString.st A Kernel.package/Float.class/instance/printing/printBinaryLiteralOn_.st A KernelTests.package/FloatTest.class/instance/tests - printing/testBinaryLiteralString.st A Manifest-Core.package/extension/RBExplicitRequirementMethodsRule/instance/category.st A Nautilus.package/CodeSearchingAcceptor.class/README.md A Nautilus.package/CodeSearchingAcceptor.class/definition.st A Nautilus.package/CodeSearchingAcceptor.class/instance/protocol/accept_notifying_.st A NautilusRefactoring.package/CodeSearchingRule.class/README.md A NautilusRefactoring.package/CodeSearchingRule.class/definition.st A NautilusRefactoring.package/CodeSearchingRule.class/instance/accessing/matcher_.st A NautilusRefactoring.package/CodeSearchingRule.class/instance/accessing/name.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/rewrite code/searchCode.st A NautilusRefactoring.package/extension/NautilusUI/instance/searchCode_.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/README.md A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/definition.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/accessing/name.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/accessing/rationale.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/running/checkClass_.st M SUnit-Core.package/TestCase.class/instance/printing/printOn_.st A SUnit-Core.package/TestCase.class/instance/printing/printTestSelectorDefiningClass_on_.st A SUnit-Core.package/TestCase.class/instance/printing/printTestSelectorOn_.st M SUnit-Tests.package/SUnitTest.class/instance/testing/testFileOutResult.st M SUnit-UI.package/TestRunner.class/instance/browsing/browseSelectedTest_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script392.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40392.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeFloatInspector.class/instance/list/addSpecialFields_.st Log Message: ----------- 40392 14550 testTraitExplicitRequirementMethodsMustBeImplementedInTheClassOrInASuperclass failing 200 times https://pharo.fogbugz.com/f/cases/14550 14288 Show binary literal for Floats in inspectors https://pharo.fogbugz.com/f/cases/14288 14551 Pharo 4.0: Fix "Search Code" refactoring menu item in Nautilus https://pharo.fogbugz.com/f/cases/14551 14546 Failed inherited tests should show home class (in TestRunner, like the debugger) https://pharo.fogbugz.com/f/cases/14546 http://files.pharo.org/image/40/40392.zip

Dec. 1, 2014

Re: [Pharo-dev] merge conflict (issue validator)

by Marcus Denker

> On 01 Dec 2014, at 11:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 29 Nov 2014, at 23:04, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> I don't understand this merge conflict in hte issue validation for case 14288 <https://pharo.fogbugz.com/default.asp?14288> >> I can manually load the slice and it does not show any conflicts. >> > > I actually looked at it when the same time it failed with the monkye, and I got the > same conflicts. > > I think this is a bug that might be related to MC not getting the right file to diff sometimes > from SmalltalkHub. > > I have put it back to review needed to see if it works now. This time it worked fine, I will integrate it now. Marcus

Dec. 1, 2014

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

by Tudor Girba

+1 Doru On Mon, Dec 1, 2014 at 11:19 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hello, > > From my experience point of view with SmalltlakHub, I found this tool > remarkably stable, useful, feature complete and quite well integrated > with Monticello. > I want to say thank you guys for the energy you spend to keep it running. > > Hilaire > > > > Le 27/11/2014 11:14, Noury Bouraqadi a Ã©crit : > > SmalltalkHub is slow, so donât click too fast :-( > > > > While Iâm grateful to developers of SmalltalkHub and previously > > SqueakSource, I believe as a small community, we cannot afford > > developing everything by ourselves. We donât have enough man-power. We > > can see the symptoms since SmalltalkHub is in beta stage since way too > > long... > > > > Itâs better to use some mainstream platform such as github. > > Weâll we have support for it in Pharo 4? > > > > It would be interesting also from the communication point of view to > > make the world a little bit more aware of Pharo. > > > > Noury > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 1, 2014

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

by kilon alios

No of course not. That would have been a deal braker. Personally I prefer using Sourcetree to browser history of commits than using the pharo on board tools. Pharo is good on that respect, but sourcetree is better and smartgit I have used in the past. It also has nice visualisation for branches , merges etc. I have not shown these features in my video tutorial as I was planning to show them to a separate tutorial. I would not mind bypassing monticello completely since its usage is unnecessary at least to me with all these git tools that one can download and use for free. The same is true for other IDEs out there , generally people prefer using dedicate tools. Usually dedicate tools are hard to beat this is why I believe modularising Pharo is extremely important as will make integrating external tools way easier. I think however that Roassal can be used to visualise in similar way the history as Sourcetree does. So pharo is not far from it but as always its a matter of someone doing the hard work. On Mon, Dec 1, 2014 at 12:21 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Le 27/11/2014 11:29, kilon alios a Ã©crit : > > My personal opinion on Github and Pharo is that it already works great > > with Pharo. The workflow with filetree is exactly the same as other > > languages that gives the added advantage that you can use all the > > powerful tools you use with other languages for commiting to git and > > github. I have not experienced any kind of issue of problem using github > > with Pharo nor my experience has been any worse than other languages. > > > > With git, don't you lost the capability to browse the history of changes > in your code? > > Hilaire > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > >

Dec. 1, 2014

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

by Thierry Goubier

2014-12-01 11:21 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > Le 27/11/2014 11:29, kilon alios a Ã©crit : > > My personal opinion on Github and Pharo is that it already works great > > with Pharo. The workflow with filetree is exactly the same as other > > languages that gives the added advantage that you can use all the > > powerful tools you use with other languages for commiting to git and > > github. I have not experienced any kind of issue of problem using github > > with Pharo nor my experience has been any worse than other languages. > > > > With git, don't you lost the capability to browse the history of changes > in your code? > Not with GitFileTree. You get an as good or even better history (i.e. garanteed merge: its common to see long project histories in mcz with missing versions in history, with sometimes merge failures in Monticello as a consequence). You can also browse changes in subsets: all versions of a method across hundreds of packages versions, you could track all versions of a class, etc... All this is local and synchronized to the remote: you have a complete local history, which makes querying the history a lot easier (than downloading hundreds of mcz(s) from smalltalkhub). It is also convenient to be able to commit properly without an internet connection. A true competitor to Pharo+git is a database-based system with replication / merge. I think the Squeak side has it (I remember Eliot talking about that). Thierry > > Hilaire > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > >

Dec. 1, 2014

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

by Denis Kudriashov

Thank's Dale and Esteban for explanation 2014-11-30 18:58 GMT+03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > 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? >> >> >> >

Dec. 1, 2014

Re: [Pharo-dev] tests coverage of minimal Pharo

by Guillermo Polito

ignorant question: What is a black listed class? :) On Sun, Nov 30, 2014 at 7:21 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 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 > >

Dec. 1, 2014

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

by Esteban Lorenzano

> On 01 Dec 2014, at 09:51, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > someone did not watch my video tutorial about github ;D > > go to your github repo front page on the right side you will see an icon labeled settings click on it and the first setting will you see is how to rename the repo. > > On Sun, Nov 30, 2014 at 9:51 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > great now I can compile :) > About your question about moving > > PharoWebStack should be renamed PharoWeb: a Tutorial > > EntreprisePharo should be renamed PharoWebStack > But I do not know how to do that on github. it is quite simple: go to the project, go to settings (in the right side), then rename repository. â¦ and of course you will need to do a new clone (with the new name) Esteban > > Stef > > Le 29/11/14 23:22, Luc Fabresse a Ã©crit : >> >> now I can compile. >> I've pushed some fixes on github, we will see if it now breaks for other ;-) >> >> @Stef: >> $ luatex -v >> This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_3) (rev 4971) >> >> do a macport update if you do not have this version. >> $ sudo port selfupdate >> $ sudo port update outdated >> >> Then, you should be able to compile the latest version on github. >> >> Cheers, >> >> #Luc >> >> 2014-11-29 9:23 GMT+01:00 Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>>: >> >> can one of you just give me the result of: >> >> luatex -v >> >> that works compiling the chapter. >> then, I will investigate. >> >> #Luc >> >> 2014-11-29 8:55 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: >> The problem is not related to that. >> To display the full encoding the guys here (damien * damien) only found luaTex working. >> But LuaTex does not work well on our machines apparently. >> >> Le 29/11/14 02:38, Ben Coman a Ã©crit : >> >> kilon alios wrote: >> have you tried MacTex ? >> >> https://tug.org/mactex/ <https://tug.org/mactex/> >> >> its what I use with my iMac and so far has been working for me without any issues. >> >> I also ended up using MaxTex fairly easily. (I can't remember which other one originally tried that had some issues.) >> cheers -ben >> >> >> On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com> <mailto:luc.fabresse@gmail.com <mailto:luc.fabresse@gmail.com>>> wrote: >> >> Hi All, >> >> I cannot compile the latest version in >> SquareBracketAssociates/EnterprisePharo.git >> My problem is that the "FiraSans" cannot be found. >> But in common.tex, the font path is correctly set up and the font is >> there. >> >> So on CI which version of luatex is used? >> I did not find it in the Jenkins log. >> >> I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts >> 2014_1) (rev 4971) >> >> Cheers, >> >> #Luc >> >> >> >> >> >> >> >> >> > >

Dec. 1, 2014

Fwd: [squeak-dev] IdentitySet>>collect:

by Sven Van Caekenberghe

> Begin forwarded message: > > From: Bert Freudenberg <bert(a)freudenbergs.de> > Subject: Re: [squeak-dev] IdentitySet>>collect: > Date: 1 Dec 2014 11:35:00 CET > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 01.12.2014, at 07:35, Colin Putney <colin(a)wiresong.com <mailto:colin@wiresong.com>> wrote: >> >> On Sun, Nov 30, 2014 at 6:20 AM, Bert Freudenberg <bert(a)freudenbergs.de <mailto:bert@freudenbergs.de>> wrote: >> >> How would you define âtypeâ here? Same class? >> >> Yes, same class. It might be reasonable to answer instances of analogous classes for weak collections, and expect the caller to use #collect:as: if they want to retain weakness. >> >> Colin > > > Thatâs certainly simple: > > âcollect: returns a collection of the same class as the receiver, except for weak collections, which answer non-weak equivalents. To return a collection of a different class, use collect:as:" > > - Bert - The above definition makes perfect sense to me. The default should be simple and predictable, the more complex and special cases can be handled by a more convoluted API. And we should change callers that depend on the old behaviour. Sven

Dec. 1, 2014