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

[Pharo-project] Tester for Dr. Geo Android

by Hilaire Fernandes

For those interested to test Dr. Geo on Android, write me privately at hilaire [AT] drgeo.eu Hilaire -- Dr. Geo -- http://www.drgeo.eu

April 18, 2012

Re: [Pharo-project] I need Pharo 1.4 for PowerPC

by Hilaire Fernandes

Le 18/04/2012 11:04, Edgar J. De Cleene a Ã©crit : > The CogDroid starts and when you select the xxxx.image do some and then > gives up with a error message. Strange indeed. > So I have a ARM one as suppose the x86 don't install or not start. > The reason I choose my tablet was have a ARM and I know this could have a > VM. > > Very thanks for all and I keep trying. > Any change I could get and try DrGeo on the device ? Write me privately at hilaire(a)drgeo.eu Hilaire -- Dr. Geo -- http://www.drgeo.eu

April 18, 2012

Re: [Pharo-project] Broken link on release-1.3

by Marcus Denker

On Apr 18, 2012, at 1:20 PM, Serge Stinckwich wrote: > The following link: > https://gforge.inria.fr/frs/download.php/30563/Pharo-1.3-13328-OneClick.zip > on http://www.pharo-project.org/pharo-download/release-1-3 does not work for me. > Ok, fixed. -- Marcus Denker -- http://marcusdenker.de

April 18, 2012

[Pharo-project] Broken link on release-1.3

by Serge Stinckwich

The following link: https://gforge.inria.fr/frs/download.php/30563/Pharo-1.3-13328-OneClick.zip on http://www.pharo-project.org/pharo-download/release-1-3 does not work for me. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 18, 2012

[Pharo-project] [update 1.4] #14436

by Esteban Lorenzano

14436 ----- yet another fix on newocompletion (no associated number)

April 18, 2012

Re: [Pharo-project] How to globals that are NOT classes or traits?

by HwaJong Oh

Mariano, Rejecting all classes and traits might give you global variables. Smalltalk globals size. "2188" (Smalltalk globals copyWithoutAll: Smalltalk allClasses) size. "95" ((Smalltalk globals copyWithoutAll: Smalltalk allClasses) copyWithoutAll: Smalltalk allTraits) size. "14" Regards, HwaJong -- View this message in context: http://forum.world.st/How-to-globals-that-are-NOT-classes-or-traits-tp45643… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2012

Re: [Pharo-project] How to globals that are NOT classes or traits?

by drush66

Igor Stasenko wrote > > I think that we missing a way to determine to which package some > global belongs to. > When you loading a package it can declare new global, but there is no > reflective mechanisms in system to tell, to which package it belongs. > If we could have that, then clearly, if you serialize the package, you > would want to serialize its globals as well, > and if not, you can just leave a reference to it, which will be > rewired at materialization. > For what is worth and as reference, Dolphin Smalltalk packages includes a list of globals that belong to it Davorin Rusevljan ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/How-to-globals-that-are-NOT-classes-or-traits-tp45643… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2012

Re: [Pharo-project] Long click on pluggeable button

by Hilaire Fernandes

Responding to myself as it may be useful to other: btn showSelectionFeedback: false. btn changed. but well. Hilaire Le 18/04/2012 11:32, Hilaire Fernandes a Ã©crit : > Hello, > > Don't know if any of you tried to use long click event with pluggable > button. > > At first it looks pretty easy, as: > > btn on: #mouseStillDown send: #hello to: self. > > does the job. > > The hell is comming because btn aspect is changed but it states is not > changed. This is what I want but the aspect changed, but not the state, > so it get unsynchronized. > > I cannot find how to get the btn back to its aspect reflected by its > sate (#getModelState). I look at #update: but did not find. > > Of course it will be even better if its aspect is not changed when > #mouseStillDown event is triggered, but only at mouseUp. > > > Thanks > > Hilaire > > > PS: > - I found state to be misleading, should not it be selected? > - Also the use of symbol to describe the morph is a hell > - the morph extension add a layer of obscurity > - update/change is catastrophic in term of readability to maintain large > application > > Yes, I fell Morph does not scale when you get large application. At > least I got lost in my own code only when dealing with this specific part. > > -- Dr. Geo -- http://www.drgeo.eu

April 18, 2012

Re: [Pharo-project] SmallLint and manifest

by Simon Allier

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] [update 1.4] #14435

by Esteban Lorenzano

14435 ----- fix on newocompletion (no associated number)

April 18, 2012