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

TestCoverage magic?

by Yuriy Tymchuk

Hi everyone, Iâm trying to understand how current coverage works and executing "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends #initializeOn: to that nil. Iâll be very thankful for explanation. Uko

Sept. 15, 2014

Re: [Pharo-dev] Tests around Pharo

by Ben Coman

mschepens wrote: > First of all, thank you for your answers, your precious advices and for > having taken time to answer us. > Answers to Ben Coman : > It's our first experience with Pharo, but we'll take more time to learn this > project if it's necessary. > We're a little comfortable with the tool, we already took the time to > discover it, to do the first tutorial which is proposed when pharo is > launched, and to develop first classes and tests for learning about pharo. > We never used the TestRunner previously, we just ran our tests for our > classes yesterday. > We never submitted a code Slice for Intergration before. > > We're still waiting propositions of Test or code to cover, and again thank > you for your attention. > > So there was the "contractTo:" example that I provided. This provides a simple end-to-end practice example for getting "some" code integrated into Pharo. Try that first. Now perhaps no one has a "list" missing tests. Either new tests get written together with new system code, or just when people bump into problems. Open source is about scratching your own itch, and learning how to discover gaps is nearly as important a skill as filling them. Did you try my recipe to find gaps? Report what you found, then it is less of a burden for all to review and advise on those, than for us to do this task for you. Now an alternative recipe to find gaps is in the Browser, scroll down to Collections-** and for various classes look in the "testing" protocol of the third pane, then right-click of various methods and choose "Senders of..." to see if it is sent from a test method. btw, it is just co-incidence the protocol is called "testing". This is the general protocol for method that return a "true or false" result. I'd chose this to start with since it should be simpler to work out what each method does from looking at its Senders, and how to write a test for it, than other infrastructure methods. Now you may find it useful to review.... http://www.catb.org/esr/faqs/smart-questions.html Good luck with it, and I feel free to ask more questions. cheers -ben

Sept. 15, 2014

Re: [Pharo-dev] How often should a uninitializedvariable warning be shown?

by Esteban A. Maringolo

Not strictly related, but I'd love to have notifications about syntax errors without modifying the code. It gets really nasty when there is a missing square bracket or parenthesis. :) Esteban A. Maringolo 2014-09-15 11:47 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > maybe pop up a dialog with the choice for the user to suppress any other > warnings of same kind. > > On Mon, Sep 15, 2014 at 4:28 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Does it make sense to warn more than once for each variable? >> >> Stephan >> >> distibutionMapOn: a >> a roassal2 >> title: 'Distribution map'; >> painting: [:view2 | >> "Simple example of a distribution map. >> Green methods are short. Orange are long. Red are very >> long" >> | view classes d packages | >> self halt. >> packages := self forumPackages. >> classes := OrderedCollection new. >> packages do: [ :p | classes addAll: p classes ]. >> d := IdentityDictionary new. >> classes do: [:aClass | aClass methods do: [:m | d >> at: m put: m getSource lineCount ] ]. >> >> view shape rectangle withoutBorder. >> view nodes: classes forEach: [ :each | >> view shape label. >> view node: each. >> view node: each forIt: [ >> view interaction action: #browse. >> view shape rectangle size: 8; >> if: [:m | (d at: m) < 5 ] >> fillColor: Color green; >> if: [:m | (d at: m) >= 5 >> and: [ (d at: m) < 25 ] ] fillColor: Color orange; >> if: [:m | (d at: m) >= 25 >> ] fillColor: Color red. >> view nodes: (each methods >> sortedAs: [:m | (d at: m) ]). >> view gridLayout gapSize: 1 ]. >> view verticalLineLayout ]. >> >> view gridLayout] > >

Sept. 15, 2014

Re: [Pharo-dev] How often should a uninitializedvariable warning be shown?

by kilon alios

maybe pop up a dialog with the choice for the user to suppress any other warnings of same kind. On Mon, Sep 15, 2014 at 4:28 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Does it make sense to warn more than once for each variable? > > Stephan > > distibutionMapOn: a > a roassal2 > title: 'Distribution map'; > painting: [:view2 | > "Simple example of a distribution map. > Green methods are short. Orange are long. Red are very > long" > | view classes d packages | > self halt. > packages := self forumPackages. > classes := OrderedCollection new. > packages do: [ :p | classes addAll: p classes ]. > d := IdentityDictionary new. > classes do: [:aClass | aClass methods do: [:m | d > at: m put: m getSource lineCount ] ]. > > view shape rectangle withoutBorder. > view nodes: classes forEach: [ :each | > view shape label. > view node: each. > view node: each forIt: [ > view interaction action: #browse. > view shape rectangle size: 8; > if: [:m | (d at: m) < 5 ] > fillColor: Color green; > if: [:m | (d at: m) >= 5 > and: [ (d at: m) < 25 ] ] fillColor: Color orange; > if: [:m | (d at: m) >= 25 > ] fillColor: Color red. > view nodes: (each methods > sortedAs: [:m | (d at: m) ]). > view gridLayout gapSize: 1 ]. > view verticalLineLayout ]. > > view gridLayout] >

Sept. 15, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by kilon alios

hmm no that does not work I am getting this error (Cannot Resolve FreeType) , any solutions ? I also tried loading latest version same error MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: in Block: linearLoadPackageSpec: packageSpec gofer: gofer... MetacelloPharo30Platform(MetacelloPlatform)>>do:displaying: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: MetacelloPackageSpec>>loadUsing:gofer: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: in Block: [ :pkg | pkg loadUsing: self gofer: gofer ] OrderedCollection>>do: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: in Block: [ super linearLoadPackageSpecs: packageSpecs repos...etc... BlockClosure>>ensure: MetacelloLoaderPolicy>>pushLoadDirective:during: MetacelloLoaderPolicy>>pushLinearLoadDirectivesDuring:for: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load MetacelloMCVersionSpecLoader>>load MetacelloMCVersion>>executeLoadFromArray: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ :dict | ^ self executeLoadFromArray: anArray ] MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [ ^ aBlock value: dict ] BlockClosure>>on:do: MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ ... BlockClosure>>ensure: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ ... MetacelloPharo30Platform(MetacelloPlatform)>>do:displaying: MetacelloMCVersion>>fetchRequiredFromArray: MetacelloMCVersion>>doLoadRequiredFromArray: in Block: [ ... BlockClosure>>ensure: MetacelloMCVersion>>doLoadRequiredFromArray: MetacelloMCVersion>>load UndefinedObject>>DoIt On Mon, Sep 15, 2014 at 5:38 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Thanks Damien :) > > so I want to further explore Slang , that means downloading the VMMaker , > I am following the post of Mariano here > https://marianopeck.wordpress.com/tag/vmmaker/ > > and install VMMaker like this > > 1 > 2 > 3 > 4 > 5 > 6 > Deprecation raiseWarning: false. > Gofer new > squeaksource:'MetacelloRepository'; > package:'ConfigurationOfVMMaker'; > load. > ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.5') load. > > > Question does CCodeGenerator contain the entire Slang ? > > I am downloading VMMaker to find how Slang plays with pointers and manual > memory management so if you have any pointer (pun not intended) I will > greatly appreciate it. > > On Mon, Sep 15, 2014 at 4:25 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2014-09-15 15:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> On Mon, Sep 15, 2014 at 2:33 PM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> >>>> >>>> Hum, I would more like SSE and AVX code done this way: matrix >>>> multiplications, bitmap processing, heavily used code, SciSmalltalk stuff >>>> on very large datasets. >>>> >>> >>> Indeed! I'd live to generate some CUDA code from Pharo. But the >>> toolchain goes C code which gets compiled through some "black-hole >>> toolchain" in the NVidia SDK with host and GPU blocks. >>> >> >> You may be interested to contact Bernard Pottier. His NetGen toolkit does >> CUDA code generation. NetGen is VisualWorks only for the moment, even if I >> know someone who would like to have it in Pharo (well, two guys at least). >> >> >>> >>> That's too much to handle for my tastes, so the best is for me to have >>> an engine (or for a better metaphor) and using Pharo to drive/steer/harness >>> it. >>> >> >> Yes. I intended to do things around that, but didn't found the time. >> >> >>> >>> >>> Indeed! CUDA =-) >>> >>> OpenCL, SPIR code generation and link to Cog. >>> >>>> >>>> The ability to generate better code than when targetting C. >>>> >>> >>> True too. But aren't those compilers smart enough already? With current >>> CPUs, well, it takes a strong man to do better things than the compiler it >>> seems. Or am I mistaken? >>> >> >> You are. A lot may be done if your input language is not C, but this is >> not allways relevant to the Pharo situation. >> >> I should know a lot more about LLVM-IR generation in a few months time. >> I'll say if I see easy gains when doing Smalltalk code. >> >> >>> >>>> >>>>> >>>>> Ah, I should have taken the research career :-) >>>>> >>>> >>>> Hum, you know that researchers are allways on the lookout for SMEs to >>>> collaborate on projects :-) >>>> >>> >>> Duly noted :-) Feel free to tickle me :-) >>> >> >> Noted :) >> >> Thierry >> > >

Sept. 15, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by kilon alios

Thanks Damien :) so I want to further explore Slang , that means downloading the VMMaker , I am following the post of Mariano here https://marianopeck.wordpress.com/tag/vmmaker/ and install VMMaker like this 1 2 3 4 5 6 Deprecation raiseWarning: false. Gofer new squeaksource:'MetacelloRepository'; package:'ConfigurationOfVMMaker'; load. ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.5') load. Question does CCodeGenerator contain the entire Slang ? I am downloading VMMaker to find how Slang plays with pointers and manual memory management so if you have any pointer (pun not intended) I will greatly appreciate it. On Mon, Sep 15, 2014 at 4:25 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-15 15:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> On Mon, Sep 15, 2014 at 2:33 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> Hum, I would more like SSE and AVX code done this way: matrix >>> multiplications, bitmap processing, heavily used code, SciSmalltalk stuff >>> on very large datasets. >>> >> >> Indeed! I'd live to generate some CUDA code from Pharo. But the toolchain >> goes C code which gets compiled through some "black-hole toolchain" in the >> NVidia SDK with host and GPU blocks. >> > > You may be interested to contact Bernard Pottier. His NetGen toolkit does > CUDA code generation. NetGen is VisualWorks only for the moment, even if I > know someone who would like to have it in Pharo (well, two guys at least). > > >> >> That's too much to handle for my tastes, so the best is for me to have an >> engine (or for a better metaphor) and using Pharo to drive/steer/harness it. >> > > Yes. I intended to do things around that, but didn't found the time. > > >> >> >> Indeed! CUDA =-) >> >> OpenCL, SPIR code generation and link to Cog. >> >>> >>> The ability to generate better code than when targetting C. >>> >> >> True too. But aren't those compilers smart enough already? With current >> CPUs, well, it takes a strong man to do better things than the compiler it >> seems. Or am I mistaken? >> > > You are. A lot may be done if your input language is not C, but this is > not allways relevant to the Pharo situation. > > I should know a lot more about LLVM-IR generation in a few months time. > I'll say if I see easy gains when doing Smalltalk code. > > >> >>> >>>> >>>> Ah, I should have taken the research career :-) >>>> >>> >>> Hum, you know that researchers are allways on the lookout for SMEs to >>> collaborate on projects :-) >>> >> >> Duly noted :-) Feel free to tickle me :-) >> > > Noted :) > > Thierry >

Sept. 15, 2014

Sprint Friday 26 @ Lille

by stepharo

Hi guys we will organize an official Pharo Sprint at Lille Friday 26 as mentioned in the calendar http://pharo.org/contribute-events Let us know if you plan to join. We will take care of the logistic :) Stef

Sept. 15, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Damien Cassou

On Mon, Sep 15, 2014 at 2:21 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > is this relevant to pharo ? --> http://en.wikipedia.org/wiki/Visitor_pattern yes, this is what they are talking about! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 15, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by kilon alios

thanks for you kind words Ben. No the GUI I am developing for Ephestos is suppose to be separate from Blender , I have no intention of forking Blender and maintaining such fork. Regarding OSWindow that wont be necessary I will most likely use Ephestos to access pyQT which in turn will give me access to QT. So most likely I will be building the futuristic GUI on top of QT. I could also bypass python and do a C++ wrapper for pharo for QT, not full functionality but rather the parts that interest me but that will be a lot more tricky. I have changed my mind, with the advice I have been getting here and in the parser C++ thread it looks like I will keep using pharo for generation of my C code. Afterall Slang is already heavily used so I think I can rely on it. What Slang cannot do I can do it coding manually in C. So I think I can fit Pharo to my workflow quite a lot. Very happy to be proven once more wrong about Pharo :) On Mon, Sep 15, 2014 at 4:21 PM, Ben Coman <btc(a)openinworld.com> wrote: > kilon alios wrote: > > No offense intended but lately the more I dive inside Pharo the more I > feel I waste my time, I love the IDE and the environment and live coding > but using the libraries is a never ending struggle for me. I agree with > Nicolai the landscape is not good, Pharo really lacks mature libraries . > Sure we like to bash Java but Java libs are rock solid and very well > documented. I bring Java as example. Again I am not complaining at all, I > knew when I came to Pharo that I will have to face these limitations. I > also don't feel comfortable asking questions all the time as if I want > others to do my code but I did not have much of a choice. I just cant deal > with the lack of documentation any more. > > > You demonstrated your willingness to contribute and I think that goes a > long way to balance any number of questions. Now you should appreciate that > asking questions actually shows someone making use of a library, which can > be good thing for a developer. And as ESR says [1], "The first thing to > understand is that hackers actually like hard problems and good, > thought-provoking questions about them. [...] If you give us an interesting > question to chew on we'll be grateful to you; good questions are a stimulus > and a gift. Good questions help us develop our understanding, and often > reveal problems we might not have noticed or thought about otherwise." > > [1] http://www.catb.org/esr/faqs/smart-questions.html (yes I know, my > favourite again) > > > I think Pharo as a general idea is great , you definitely have taken the > Squeak fork one big step further but you have a very long road ahead of you > to make Pharo a modern environment. Asking for animating a window with good > performance is one of the very basics of a good GUI API. I know you have > limited resources and once again I am not complaining at all I just present > my opinion. Its clear that Pharo needs a lot more people to contribute and > bring the system forward at least to solve the basic problems. > > Thank you all people who helped me. But I don't think it worths to make > my project in Pharo, too many problems. I feel privileged to have helped > you with my contributions , I wish the Pharo the best. > > > I can definitely understand with your main interest being an existing > application like Blender written in C, then developing in C may give you > the greatest power. Good luck with it! > > > I could return back to Python but I think its time for me to bite the > bullet and learn C/C++, since graphics is an area that deeply interest me > (more as an artist less as a coder), so I don't have much of choice. Maybe > I can brings some of my code back to Pharo with NB wrappers , I definitely > will keep a close eye on Pharo. > > In a few months I will also present to the Pharo community a secret last > contribution ;) > > > I have really appreciated your enthusiasm, your joy of Pharo, and your > honest constructive criticisms. Sometimes it can be suspect that > Smalltalker fanbois are blinded by their world view, but as a newcomer to > Pharo your positive comparisons of Pharo versus languages-you-knew-better > were a nice validation of Pharo, even if there remain things to improve. > Now life is a long and winding road, so maybe opportunity will arise > sometime for you to use Pharo again. I hope you have fun in the meantime! > > btw, just a parting thought that I had regarding your requirement. Rather > than trying to do your Blender graphics rendering on top of some layer in > Pharo, you might** use OSWindow [2] to create a native-window-canvas that > you pass to Blender for it to render directly into. As I understand it, > you could then build a Pharo base GUI around that window. Now if that > happened to be possible, your dive into programming Blender in "C" would > probably be of great benefit. Maybe something to come back to later. > > **Disclaimer, I haven't used OSWindow. Its just an intuitive thought. > [2] http://smalltalkhub.com/#!/~OS/OS-Windows (scroll down to "The > Windows User Interface" and "Graphics") > > cheers -ben > > >

Sept. 15, 2014

Re: [Pharo-dev] About renaming API methods

by stepharo

sounds like a good idea. Now how could we make that as easy as possible for doing it. We should produce two slices one for 3 and one for 4 Stef On 15/9/14 09:16, Marcus Denker wrote: > Hi, > > In case we rename methods that are used as part of the public API, I propose to do > > 1) add the same API to the current stable version (today this would be Pharo3 > 2) add a rule (in a âPort Pharo3 to Pharo4â category that finds the needed senders > (if possible even with a transformation) > > Then depending on the use and importance > > -> deprecate the old API right away > or > -> just tag it as âto be deprecatedâ one version later > or > -> keep the old as âcompatibilityâ > > This should make it possible to clean up API (e.g. when there are typos in the selectorâ¦), > while not disturbing users to much. *And* it will be possible to have affected code running > both in Stable and Development. > > (This should not be a strict rule, more a âbest effortâ one, and there will always be cases > where we can not do this or where it is not needed). > > Marcus > > > > > > > > > > >

Sept. 15, 2014