October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?

by Mariano Martinez Peck

> > You run HDCoverageReport exactly the same way as HDTestReport. > > HDCoverageReport uses exactly the same mechanism as the Test Runner to > figure out the code you want calculate the coverage on. That is, you > have to override #packageNamesUnderTest on the class side of one of > your test classes. > Wow....I wasn't aware of that. I always trigger the TestCoverage from the test runner and then I needed to select the package to which it should calculate the coverage... > > I don't know if HDCoverageReport still works, because I stopped using > it when I started with Cog on Jenkins. It definitely works on > traditional VMs. Probably today it works on Cog too. > Yes, latest Cog works ok with test coverage, and HDCoverageReport works!! look the attached screenshot Thanks Lukas > > Lukas > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

Oct. 31, 2011

Re: [Pharo-project] Paradigm change in Smalltalk software engineering visible?

by Guido Stepken

> >> Means: When starts Pharo refactoring its own code or AST parser itself? >> > PetitParser provides exactly that: A parser has a meta-model to be changed at runtime. > > With Opal, we use an AST for everything that has transformation support of the RB. > > >> Maybe a too unclear question, but i hope someone can understand what i mean ... :-) >> > You are always Hi Marcus! PetitParser ... Yes. A paradigm chance already. I was thinking of a data flow analysis parser, that "profiles" through a running system, looking out for relevant and irrelevant "data control & logic structures" (like reducing Pharo source from "unused" code), backtracking the growing of finally thrown or unused data, thus reducing the system to the minimum of relevant code by itself. Means - I see a new paradigm change coming up. Is's like sticking "PetitParser" in its own ass, letting PetitParser analyze its own dataflow, automatically replacing PetitParser by its evolutionary child. What source structures could be generated, that are still readable and changeable by humans?? Guido

Oct. 31, 2011

Re: [Pharo-project] Paradigm change in Smalltalk software engineering visible?

by StÃ©phane Ducasse

On Oct 31, 2011, at 11:16 AM, Guido Stepken wrote: > Hello! > > Some weeks ago i asked, weather code in Smalltalk is an object too or not. The answers were not that clear as i expected! :-( > > Now i would like to put up the question, if there is a paradigm change in software engineering slowly coming up in the Smalltalk community towards class factory, code, that generates code, that is jitted immediately to generate further classes to finally be instantiated? not specially > E.g. the regexp compilercompiler SmaCC. How "dense" has a Smalltalk code system to be that it starts to emerge from itself? > > Means: When starts Pharo refactoring its own code or AST parser itself? But it does. Pharo does not use Smacc. > Maybe a too unclear question, but i hope someone can understand what i mean ... :-) > > tnx in advance, Guido Stepken

Oct. 31, 2011

Re: [Pharo-project] Is RPackage dead?

by StÃ©phane Ducasse

>> >> give me a strong reason why i can't have it, and why i have to waste >> my time with package management, if all i need is single package? > > So now I think you are looking at the problem in a strange way. You seem to argue that we should optimize the system around toy examples. Almost anything meaningful requires more than that. Let's optimize around what matters. > > And regarding wasting time, you will waste much less than now at the moment when Monticello will become transparent as well. In other words, you will simply stay in your code browser and load and publish from there. No mess, no fuss. But to get there easily, we need this 1-to-1 between what is publishable and what is in the image. Yes I would like to simply see packages in any browser. I agree with that :) And igor I added tags to packages: so any class of a package can be associated with any number of tags. so tools can display Package Tag1 ClassA Class B Tag2 Class A (yes) Class C but this tagging has nothing to do with package identification. > Perhaps where you will need some attention is loading order, but when Metacello will get a better integration, many things will be possible. But, we need a stable and simple base. Doru I think that I will continue like we got it. I will work on making sure that we can remove PackageInfo in 1.5 (i.e. controlling the logic and moving it inside, deprecating as much as possible from the interface) same for PackageOrganizer. Syeg

Oct. 31, 2011

Re: [Pharo-project] Is RPackage dead?

by StÃ©phane Ducasse

> Hi, > > Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later. The problem is that we are all talking about different things. - RPackage is fully working: it does not need any category. RPackage is a list of class + a list of method (nicely optimized to be queried efficienly). RPackage is equivalent to MCPackage when MCPackages are limited to top level categories (i.e. Foo and *foo). - Now we have MCPackage and they are overlapping multiple categories and this is the mess. Because they cross multiple PackageInfo andâ¦. > Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run. > > So, I come back to my point. At this point, we can safely load RPackage in the image (actually, in the Moose image, it is always loaded) and have tools be built on top of them. Then in Pharo 1.5 or later we start transitioning by not allowing people to commit more than one Category/RPackage in a Monticello package. I agree now marcus is afraid that it will generate too many packages. For me I would like to have a simple model. > It's a smooth transition that can be spread over a longer period of time. > > Cheers, > Doru > > > > On 30 Oct 2011, at 15:29, StÃ©phane Ducasse wrote: > >> I agree now this is the path to arrive there that is important to me. >> >> Stef >> >> On Oct 30, 2011, at 3:23 PM, Igor Stasenko wrote: >> >>> Stephane, as i said before, i do not see problems with RPackage / naming. >>> These things are orthogonal, as to me. >>> We can keep naming scheme as we use today, but switch to RPackage. >>> >>> A package can keep the list of category names and that's it. They >>> could even be completely different, if people want it. >>> Say, package is named >>> Foo >>> and contain categories: >>> 'Foo-Core' >>> 'Bar' >>> >>> The rationale is simple: >>> it is up to human(s) to decide what a package should contain, and what >>> names to use. Let's just embrace the imperfection and do not dictate >>> people >>> how they should name their categories in order to make sure that >>> classes in that categories will be put into concrete package. >>> If people like to confuse themselves with category names, not matching >>> the package name , it should be their own choice and responsibility. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > >

Oct. 31, 2011

[Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by StÃ©phane Ducasse

Hi guys we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: Build an initial roadmap and refine it based on the input of the community. - A website for the consortium registration (esteban is expert on that). - This is important for INRIA and for the visibility of the consortium. We should get new members :) - Integration with SmalltalkHub - Working on fixing bugs! - Debugger fixes - Continuous bug fixing. - Improving release process: faster, more people involved, simpler. - Working on metacello repositories for each distributions (everything is there but missing last bits) - Metacello tools - Automatic release validations - Automatic validation of fixes Now the free items with probably igor involvement - Multiwindowing support - Fully working multithreaded FFI with ***Documentation*** - Filesystem fix and integration - Integration of OPAL - RPackage integration Igor related - Ephemerons - Object format - VM branding - Use of new canvas - Event cleaning So we are waiting for your suggestions. Stef

Oct. 31, 2011

Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?

by Lukas Renggli

On 31 October 2011 11:02, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Lukas. I was playing with the test coverage, I installed the emma plugin > for Jenkis and I configure everything. However, I don't get any result but > instead a: > > Emma: looking for coverage reports in the provided path: **/*-Coverage.xml > Emma: no coverage files found in workspace. Was any report generated? > Build step 'Record Emma coverage report' changed build result to FAILURE > Finished: FAILURE > > I guess that from my xxx.tests.st I should call HDCoverageReport but I don't > know how and it doesn't have class comments. What should I call from my .st > ? > I thought I could do something likeÂ HDCoverageReport runPackages: > aListofPackagesÂ Â but I don't think that can work, because you need TWO > parameters: the tests packages and the "real" packages. > > Any idea? You run HDCoverageReport exactly the same way as HDTestReport. HDCoverageReport uses exactly the same mechanism as the Test Runner to figure out the code you want calculate the coverage on. That is, you have to override #packageNamesUnderTest on the class side of one of your test classes. I don't know if HDCoverageReport still works, because I stopped using it when I started with Cog on Jenkins. It definitely works on traditional VMs. Probably today it works on Cog too. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 31, 2011

Re: [Pharo-project] Website RSS feed broken?

by Marcus Denker

On Oct 31, 2011, at 10:17 AM, Max Leske wrote: > Concerning the changing GUIDs: We could only reproduce this when a new item is not added "normally", e.g. when an older article was cut and then used as template. It would therefore be really helpful if the person who published the TextLint news entry could tell me exactly what steps he performed when creating the entry. > I go to the news page, edit. Than I add a "Discussion" from the menu, add a text below, fill it in. Than I put the meta tag "All", save. (Then I had to move the whole article up because is was added below the current one, no above). Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 31, 2011

Re: [Pharo-project] Paradigm change in Smalltalk software engineering visible?

by Marcus Denker

On Oct 31, 2011, at 11:16 AM, Guido Stepken wrote: > Hello! > > Some weeks ago i asked, weather code in Smalltalk is an object too or not. The answers were not that clear as i expected! :-( > > Now i would like to put up the question, if there is a paradigm change in software engineering slowly coming up in the Smalltalk community towards class factory, code, that generates code, that is jitted immediately to generate further classes to finally be instantiated? > Would that be good? Meta Programming is powerful, but you need to take care that you can produce an un-understandable mess very easily. > E.g. the regexp compilercompiler SmaCC. Nobody uses SmaCC anymore. > How "dense" has a Smalltalk code system to be that it starts to emerge from itself? > That is another question. > Means: When starts Pharo refactoring its own code or AST parser itself? > PetitParser provides exactly that: A parser has a meta-model to be changed at runtime. With Opal, we use an AST for everything that has transformation support of the RB. > Maybe a too unclear question, but i hope someone can understand what i mean ... :-) > You are always confusing. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 31, 2011

[Pharo-project] Paradigm change in Smalltalk software engineering visible?

by Guido Stepken

Hello! Some weeks ago i asked, weather code in Smalltalk is an object too or not. The answers were not that clear as i expected! :-( Now i would like to put up the question, if there is a paradigm change in software engineering slowly coming up in the Smalltalk community towards class factory, code, that generates code, that is jitted immediately to generate further classes to finally be instantiated? E.g. the regexp compilercompiler SmaCC. How "dense" has a Smalltalk code system to be that it starts to emerge from itself? Means: When starts Pharo refactoring its own code or AST parser itself? Maybe a too unclear question, but i hope someone can understand what i mean ... :-) tnx in advance, Guido Stepken

Oct. 31, 2011