April 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Which packages are loaded in the image?

by Sean P. DeNigris

It took a bit of time to figure it out... I finally came up with: MCPackage allInstances asSet collect: [ :e | e name ]. I started with three seemingly equivalent operations which all returned different results in 1.3 (not in 1.4): packageNames := MCPackage allInstances collect: [ :e | e name ] as: Set. all := MCPackage allInstances. set := MCPackage allInstances asSet. packageNames size. "235" all size. "236." set size. "234." It turned out to be the 'bogus' and 'bogusext' packages that were throwing the results off (the first is duplicated in the image and the second is duplicated with case differences). Given the names, I'm guessing it's not too important, but still confusing. What's the best way to do the above? How do we prevent future queriers from this confusion? Thanks. Sean -- View this message in context: http://forum.world.st/Which-packages-are-loaded-in-the-image-tp4568092p4568… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2012

Re: [Pharo-project] Final 1.4 images...

by Stefan Marr

Hi: On 18 Apr 2012, at 16:57, Herby VojÄÃk wrote: > It is not green (one-click on Windows 7 Starter 32-bit). Here on OSX 10.6, only MirrorPrimitiveTests >> #testMirrorSize is an unexpected pass. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 18, 2012

[Pharo-project] [JOB] Young Engineer: Smalltalk VM related

by Marcus Denker

2 year Young Engineer Position =============================== INRIA RMoD is looking for a full-time young engineer for helping with developing our research infrastructure. Young engineer means someone who finished with a degree (Master or Engineer) not longer than 2 years ago. The engineer position is focussed on virtual machine related work. As researchers, we need a system to explore new ideas with. The job of the engineer is to help us by improving the infrastructure we use for our daily work. What this of course means is that it's kind of a cool job: work in a research lab, but no paper writing, no teaching, no administration. In addition: - live in France (one hour from Paris, 1h20 from London, 35 min from Brussels) - try a lot of good beers (our office is just 10km from the border to Belgium) - french food - Smalltalk! (in the form of Pharo) Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). The idea of the job is to strengthen RMoD with regard to virtual machine development and improve our research infrastructure. In research we are often faced with doing experiments that need VM changes. We want to be able to make these changes as easy as possible so researchers can focus on trying out new ideas. In particular we are working on an easy to understand and modify research virtual machine that is implemented in Smalltalk. The goal here is not a fast production VM but instead infrastructure that is easy to learn and extend for research experiments. The job will include working on the research VM as well as helping with Pharo related VM level development: - extend and develop the research VM. - implement a simple GC in Smalltalk for this VM. - help with Pharo VM related development (build system, fixes, improvements) - improvement of the NativeBoost native code backend. Therefore we are looking for a candidate with some prior experience with Smalltalk (Pharo/Squeak) and possibly some background in implementation of dynamic languages. - Knowledge in Dynamic Languages, preferably Smalltalk - Compiler construction - Implementation of dynamic langauges (Virtual Machines) - Good knowledge in low-level programming (C, Asm) - English Duration: 24 months Starting date: 2012 October or later Sallary: 2 527,74 euros brut / month Location: Lille (no remote job possible) Needed: - degree (Master or Engineering, 5 years) - need to have finished the degree max 2 years ago. More about INRIA RMOD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille/ INRIA in General: http://www.inria.fr Engineers at INRIA: http://www.inria.fr/travailler/metiers/accompagnement/dev_applications.en.h… Lille: http://en.wikipedia.org/wiki/Lille http://www.mairie-lille.fr/en http://wikitravel.org/en/Lille Do not hesitate to contact us for more information. Link to this offer: http://rmod.lille.inria.fr/web/pier/blog/2012-04-18 More RMoD Jobs: http://rmod.lille.inria.fr/web/pier/Jobs -- Marcus Denker -- http://marcusdenker.de

April 18, 2012

Re: [Pharo-project] Final 1.4 images...

by Herby VojÄÃk

It is not green (one-click on Windows 7 Starter 32-bit). Herby Marcus Denker wrote: > Hi, > > final images: > > One-Click: > > https://gforge.inria.fr/frs/download.php/30615/Pharo-1.4-14437-OneClick.zip > > Just image: > https://gforge.inria.fr/frs/download.php/30613/Pharo-1.4-14437.zip > > already linked on > > http://www.pharo-project.org/pharo-download/release-1-4 > > > -- > Marcus Denker -- http://marcusdenker.de > >

April 18, 2012

Re: [Pharo-project] Help with RPackage and FuelPackageLoader

by StÃ©phane Ducasse

On Apr 16, 2012, at 3:22 PM, Mariano Martinez Peck wrote: > Hi guys. I have spent several hours trying to find a problem with Fuel and RPackage and I couldn't. We have a test where we create a package, we create a class and we compiled some methods. Then we serialize the package, we remove it, and then we materialize it. In a clean Pharo 1.4 image this works PERFECT. No problem. Now, if I run it in the Nautilus image (where RPackage is loaded) I have lots of problems. > > I am completly lost of what is happening. But it is reproducible. So I really appreaciate any help. To reproduce: > > 1) Take a Nautilus image from: https://ci.lille.inria.fr/pharo/view/Nautilus/job/Nautilus-Release/ > > 2) Install Fuel: > > Gofer it > url: 'http://ss3.gemstone.com/ss/Fuel'; > package: 'ConfigurationOfFuel'; > load. > > (ConfigurationOfFuel project version: #bleedingEdge) load: 'DevelopmentGroup'. > > 3) Open a TestRunner and just run the test class FLPackageLoaderTest. > > Once that finish, you will have like 20 debuggers opened. In addition, like 4 error test. Without Nautilus I have only ONE red test and no debuggers. > > The debuggers are all in the line: > > self flag: 'should not arrive there now'. self halt. > > from CompiledMethod >> packageFromOrganizer: This is probably because PackageOrganizer is full of dirts and we use this information to create Package and the system gets confused. I do not have the time to check but I should. > > Thanks for any help, > > > -- > Mariano > http://marianopeck.wordpress.com >

April 18, 2012

Re: [Pharo-project] SmallLint and manifest

by Marcus Denker

On Apr 18, 2012, at 4:32 PM, StÃ©phane Ducasse wrote: > Thanks simon. > I will try on citizen and Kozen then after on all the packages I can find and I know :) > > Gofer > new > url: 'http://www.squeaksource.com/PharoTaskForces'; > package: 'ConfigurationOfManifest'; > load. > ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load > I will use it for Opal. Marcus -- Marcus Denker -- http://marcusdenker.de

April 18, 2012

Re: [Pharo-project] SmallLint and manifest

by StÃ©phane Ducasse

Thanks simon. I will try on citizen and Kozen then after on all the packages I can find and I know :) Gofer new url: 'http://www.squeaksource.com/PharoTaskForces'; package: 'ConfigurationOfManifest'; load. ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load On Apr 18, 2012, at 11:39 AM, Simon Allier wrote: > Hi, > > i have published a new version: > - the package Manifest-Core is split in two packages: Manifest-Core and Manifest-CriticBrowser. > - the unique identifier for a rule is now a string, not a number. For example, in the manifest we have ruleBadMessageRuleV1FalsePositive rather than ruleBadMessageRuleV1FalsePositive. > > Simon > > On Apr 10, 2012, at 9:57 PM, Tudor Girba wrote: > >> Hi, >> >> On 10 Apr 2012, at 21:31, StÃ©phane Ducasse wrote: >> >>>> >>>> I do not get it. You want an identifier. Why is a brittle and >>>> obfuscated number better than the name of the class, which is already >>>> a proper identifier? If you do not want to rely directly on a class >>>> reference, you can store it as a symbol. >>> >>> sure this is not the problem numbers solve. We want to have no impact because of class name change. >>> >>>> If you keep the numbering, >>>> you will immediately get into numbering issues as soon as people will >>>> start writing their own rules. >>> >>> Normally not because number should be unique and should never change. But I see your point >>> After we have a version number when we change a rule >>> for example rule 1 version 1 is different from rule 1 version 2 >>> >>> How you scenario behave in presence of class renaming? >>> Our is stable but indeed people can add number that clashes with existing ones. Now we should have a rule stating that rule should have unique id. >> >> Rules are effective when they are like specific, not when they are generic. So, we should expect (and encourage) people to write their own rules for their own context. There is no way in which you could get a numbering scheme to fit a hundred different projects and still have an understandable situation. >> >> In my scenario, if someone renamed a SmallLint rule but the false positives still refer to the old one, the false positives from the manifest would simply get ignored. On top of that, we could add a meta-rule that says that all manifest rules should have a corresponding SamllLint rule. >> >> >>>>>> - In the rule methods, you are storing strings. This means that when someone renames a rule, the code in there will not be updated. Why not store this information as normal code and use symbols that can be queried? >>>>> >>>>> I do not get it? It is normal code no? >>>>> You mean symbols instead of strings. >>>> >>>> I mean you are currently storing the following in a rule exception: >>>> rule24V1FalsePositive >>>> ^ #(#('(RGMethodDefinition className: ''RGClassDefinitionTest'' >>>> selector: #testReadFrom isMetaSide: false)' >>>> #'2012-04-02T11:31:59.933+02:00') ) >>>> >>>> This an array of strings, not code. I was wondering why it would not >>>> be possible to be code directly. >>> >>> because we do not want to store information that force us to have ring loaded. >> >> Why not: >> >> '(RGMethodDefinition className: ''RGClassDefinitionTest'' selector: #testReadFrom isMetaSide: false)' >> >> ==> >> >> (Smalltalk at: #RGMethodDefinition) className: ''RGClassDefinitionTest'' selector: #testReadFrom isMetaSide: false >> >> Cheers, >> Doru >> >> >>> Cheers, >>>> Doru >>>> >>>> >>>>> We will the issues. >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> On 6 Apr 2012, at 09:51, Simon Allier wrote: >>>>>> >>>>>>> Hi pharoers >>>>>>> >>>>>>> Since a couple of months the Pharo team has been working on improving the support for rules checking and in particular the handling of false positives (there is nothing more boring that to get all the time the same warnings that we know are not adequate). >>>>>>> We added a manifest mechanism to manage the false/true positive of SmallLint, the rule checker of Pharo. A manifest is a class that contains meta data. In the future we may add package license and package documentation. This data is stored in methods on the meta side of the class. So, manifest can be versioned in Monticello and not lost. There is one manifest per package. >>>>>>> >>>>>>> It possible to use SmallLint with Manifest using the Critics Browser (menuWorld > Tool > CriticBrowser). With the Critics browser you can inspect violations of rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. >>>>>>> In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. >>>>>>> We will continue to improve the Browser. In addition we will run SmallLint rules to all the Pharo packages and the rules checking will be part of the package validation. We want the community to use rule checking for real so that we all improve. >>>>>>> >>>>>>> Simon and Stef >>>>>>> >>>>>>> Gofer >>>>>>> new >>>>>>> url: 'http://www.squeaksource.com/PharoTaskForces'; >>>>>>> package: 'ConfigurationOfManifest'; >>>>>>> load. >>>>>>> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Not knowing how to do something is not an argument for how it cannot be done." >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> > >

April 18, 2012

[Pharo-project] [1.4] Website updated

by Marcus Denker

Hi, So now http://www.pharo-project.org is updated for 1.4 Release. What is missing -> The list of changes should be finished http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotFour -> We need an announcement for the News section Marcus -- Marcus Denker -- http://marcusdenker.de

April 18, 2012

[Pharo-project] Pharo Kernel Reload Tests-Unix - Build # 73 - Still unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

April 18, 2012

[Pharo-project] Final 1.4 images...

by Marcus Denker

Hi, final images: One-Click: https://gforge.inria.fr/frs/download.php/30615/Pharo-1.4-14437-OneClick.zip Just image: https://gforge.inria.fr/frs/download.php/30613/Pharo-1.4-14437.zip already linked on http://www.pharo-project.org/pharo-download/release-1-4 -- Marcus Denker -- http://marcusdenker.de

April 18, 2012