Re: [Pharo-dev] Remove rule "References an abstract class"

[Peter Uhnák]

You can probably remove it directly from Pharo instead
https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule

Peter

On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk  wrote:

> Hi.
>
> First of all: thank you for the feedback Damien!
> It makes sense, the rule also has higher amount of negative feedback. I
> will remove it from QA, let it stay in the image, it actually can be useful.
>
> Uko
>
>
> > On 17 Sep 2015, at 06:49, Damien Cassou  wrote:
> >
> > This lint rule pops up all the times and my code is always ok. I
> > typically have to reference an abstract class when:
> >
> > - the abstract class takes care of choosing the concrete class to
> >  instantiate
> >
> > - the abstract class takes care of some shared variable for its
> >  subclasses (e.g., a cache or an shared external object)
> >
> > I propose to remove this rule which has never been useful for me.
> >
> > --
> > Damien Cassou
> > http://damiencassou.seasidehosting.st
> >
> > "Success is the ability to go from one failure to another without
> > losing enthusiasm." --Winston Churchill
> >
>
>
>

[Pharo-dev] [pharo-project/pharo-core] feb71a: 50329

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: feb71a8705982cbb829e2678703c07d2131e71d8
  
https://github.com/pharo-project/pharo-core/commit/feb71a8705982cbb829e2678703c07d2131e71d8
  Author: Jenkins Build Server 
  Date:   2015-09-17 (Thu, 17 Sep 2015)

  Changed paths:
M 
CodeImport.package/CodeImporter.class/instance/evaluating/flushChangesFile.st
A CodeImport.package/ManifestCodeImport.class/README.md
A CodeImport.package/ManifestCodeImport.class/class/meta-data - dependency 
analyser/manuallyResolvedDependencies.st
A CodeImport.package/ManifestCodeImport.class/definition.st
M 
ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic 
versions/stable_.st
A 
ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version09_.st
A 
ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/baselines/baseline112_.st
A 
ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic
 versions/development_.st
A 
ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/versions/version112_.st
A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - 
instead/testInsteadBlockSequence.st
M 
Reflectivity.package/RFASTTranslatorForValue.class/instance/visitor-double 
dispatching/visitSequenceNode_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50328.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50329.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50328.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50329.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Tool-Catalog.package/CatalogBrowser.class/instance/actions/installStableVersion_onSuccess_.st
M Tool-Catalog.package/CatalogBrowser.class/instance/private - 
events/onLoadFrom_.st
M 
Tool-Catalog.package/extension/GTSpotter/instance/spotterCatalogProjectsFor_.st

  Log Message:
  ---
  50329
16589 #instead for block sequence
https://pharo.fogbugz.com/f/cases/16589

16588 Integrate Catalog 0.9
https://pharo.fogbugz.com/f/cases/16588

16586 Load latest version of CodeImporter
https://pharo.fogbugz.com/f/cases/16586

http://files.pharo.org/image/50/50329.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [Reflectivity] Support for primitive methods

[Marcus Denker]

Hi,

One thing I added over the last weeks: support to put links on primitives.

1) fail code. You can put links into the smalltalk code that is executed in 
case of primitive failure.
For all primitive methods, we generate code immediately when setting the 
link, we do not wait
till the method is called. (this is in there since a while).

2) links on the method node itself. What we do here is to wrap the original 
method.

It is interesting how simple this was to do:

1) when generating code for a ReflectiveMethod, check if it is a primitive:

compileAndInstallCompiledMethod
"we install the old one as the compiler might need it”
self installCompiledMethod.
compiledMethod isRealPrimitive ifTrue: [ self generatePrimitiveWrapper 
].
self recompileAST.
self installCompiledMethod.


2) compile a wrapper by building an AST by hand:

generatePrimitiveWrapper
| wrappedMethod send wrapperMethod |
ast compilationContext 
semanticAnalyzerClass: RFSemanticAnalyzer;
astTranslatorClass: RFASTTranslator.
ast doSemanticAnalysis. "force semantic analysis"
wrappedMethod := ast generate: compiledMethod trailer.

send := RBMessageNode
receiver: (RBLiteralNode value: wrappedMethod)
selector:  #valueWithReceiver:arguments: 
arguments: {RBVariableNode named: #self . RBArrayNode 
statements: ast variableNodes }.

wrapperMethod := RBMethodNode
selector: ast selector
arguments: ast variableNodes 
body: (RBReturnNode value: send) asSequenceNode.

wrapperMethod methodClass: ast methodClass.
wrapperMethod propertyAt: #wrappedPrimitive put: true.
ast hasMetalink ifTrue: [wrapperMethod propertyAt: #links put: (ast 
propertyAt: #links)].
ast := wrapperMethod.

This means we copy over the links to the new wrapper. the #wrappedPrimitive 
marker is there so that,
when we destroy the twin when the last link is removed, we remember to unwrap.

3) the compiler plugin that takes the links into account ignores links on 
MethodNode if it’s a primitive.

4) when getting rid of the Twin (because we remove the last link), we detect if 
it was a primitive and unwrap:

destroyTwin
(ast hasProperty: #wrappedPrimitive) ifTrue: [  ast :=  compiledMethod 
parseTree].
self recompileAST.
self installCompiledMethod.
compiledMethod reflectiveMethod: nil.
SystemAnnouncer uniqueInstance unsubscribe: self

e.g.

testBeforeMethodPrimitive
| methodNode link |
methodNode := (ReflectivityExamples >> #examplePrimitiveMethod) ast.
link := MetaLink new
metaObject: self;
selector: #tagExec.
self assert: (ReflectivityExamples>>#examplePrimitiveMethod) 
isRealPrimitive.   
methodNode link: link.
self assert: methodNode hasMetalink.
self assert: (ReflectivityExamples >> #examplePrimitiveMethod) class = 
CompiledMethod.
self assert: tag isNil.
self assert: ReflectivityExamples new examplePrimitiveMethod class = 
ByteString.
self deny: (ReflectivityExamples>>#examplePrimitiveMethod) 
isRealPrimitive. 
self assert: tag = #yes.
self assert: (ReflectivityExamples >> #examplePrimitiveMethod) class = 
CompiledMethod.
link uninstall.
self assert: (ReflectivityExamples>>#examplePrimitiveMethod) 
isRealPrimitive.   
ReflectivityExamples recompile: #examplePrimitiveMethod


Marcus

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

[Nicolai Hess]

2015-09-17 1:18 GMT+02:00 John Brant :

> On 9/16/2015 10:34 AM, Ben Coman wrote:
>
>> On Wed, Sep 16, 2015 at 4:56 PM, Nicolai Hess  wrote:
>>
>>> The following method compiles with Opal:
>>>
>>> createRedMorph
>>>  ^ (self new color:Color red); yourself
>>>
>>> but gives a syntax error with the old compilers parser
>>>
>>> createRedMorph
>>>  ^ (self new color:Color red)End of block expected -> ; yourself
>>>
>>>
>>> removing the parenthesis of course works for both.
>>> Who is right ?
>>>
>>
>> What is the result in other dialects?
>>
>
> Dolphin lets you do "self ; yourself" as well as the example above.
> However, both VW & VA don't allow it.
>

Thanks for the info.


>
> This is a potential incompatibility for little gain.
>> Anyway I would guess Opal is wrong.
>>
>
> I don't remember if we allowed this on purpose to be compatible with other
> Smalltalks or if it was a bug we missed. Anyway, a simple fix is to add "
> and: [node parentheses isEmpty]" to the RBParser>>parseCascadeMessage
> method:
>
> parseCascadeMessage
> | node receiver messages semicolons |
> node := self parseKeywordMessage.
> (currentToken isSpecial
> and: [currentToken value = $; and: [node isMessage and:
> [node parentheses isEmpty]]]) ifFalse: [^node].
> ...
>
>
>
> John Brant
>
>
>

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

[Nicolai Hess]

2015-09-16 15:14 GMT+02:00 Thierry Goubier :

> Argh, sent too early:
>
> self new color: Color red; yourself
>
> est bien une cascade, non?
>

Yes, but in

(self new color: Color red); yourself
the expression in parenthesis looks like "this evalulates first, to
'anObject' ", so we send " ; yourself",
a cascaded messages with only one message to "anObject".





>
>
>
> Thierry
>
>
> 2015-09-16 15:12 GMT+02:00 Thierry Goubier :
>
>>
>>
>> 2015-09-16 15:05 GMT+02:00 Nicolai Hess :
>>
>>> OK, I think Sven is right and a cascade needs at least one message send
>>>
>>> "self ; yourself"
>>>
>>> doesn't work too (both parser don't accept this).
>>>
>>
>> But
>>
>>
>>
>>>
>>> There are currently two methods in Pharo 5.0 with this
>>> syntax:
>>>
>>> DAPackageAnalyzerWindow class>>#onPackagesNamed:
>>> DAPackageCycleDetectionTreeModel class>>#onPackagesNamed:
>>>
>>> @Yuri, can you change that.
>>>
>>>
>>> And I think we should fix RBParser.
>>>
>>>
>>> 2015-09-16 11:30 GMT+02:00 Thierry Goubier :
>>>
 Nicolai,

 can you try with the RBParser directly? I believe Opal uses the
 RBParser.

 RBParser parseMethod: 'createRedMorph
 ^ (self new color:Color red); yourself'

 Oh, RBParser sees it as:

 self new
 color: Color red;
 yourself

 :)

 Thierry


 2015-09-16 10:56 GMT+02:00 Nicolai Hess :

> The following method compiles with Opal:
>
> createRedMorph
> ^ (self new color:Color red); yourself
>
> but gives a syntax error with the old compilers parser
>
> createRedMorph
> ^ (self new color:Color red)End of block expected -> ; yourself
>
>
> removing the parenthesis of course works for both.
> Who is right ?
>
>
> (for those who understand the ParseTreeSearcher syntax, how would
> a search expression look, for finding code like:
>
>"(some expression);yourself"
>
>
> nicolai
>
>

>>>
>>
>

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

[Thierry Goubier]

2015-09-17 9:10 GMT+02:00 Nicolai Hess :

>
>
> 2015-09-16 15:14 GMT+02:00 Thierry Goubier :
>
>> Argh, sent too early:
>>
>> self new color: Color red; yourself
>>
>> est bien une cascade, non?
>>
>
> Yes, but in
>
> (self new color: Color red); yourself
> the expression in parenthesis looks like "this evalulates first, to
> 'anObject' ", so we send " ; yourself",
> a cascaded messages with only one message to "anObject".
>

Yes, agreed of course.

In a way, it looks like an error correction type of thing: the parser knows
the parenthesis shouldn't be there or the ; shouldn't be there, so it
chooses one interpretation out of the two: here it is the parenthesis are
unnecessary.

By the way, John found another issue with a fix you did in RBParser
(RBPatternParser>>parseUnaryMessage) which fail some refactoring
expressions. Can you have a look?

Thierry


>
>
>
>
>
>>
>>
>>
>> Thierry
>>
>>
>> 2015-09-16 15:12 GMT+02:00 Thierry Goubier :
>>
>>>
>>>
>>> 2015-09-16 15:05 GMT+02:00 Nicolai Hess :
>>>
 OK, I think Sven is right and a cascade needs at least one message send

 "self ; yourself"

 doesn't work too (both parser don't accept this).

>>>
>>> But
>>>
>>>
>>>

 There are currently two methods in Pharo 5.0 with this
 syntax:

 DAPackageAnalyzerWindow class>>#onPackagesNamed:
 DAPackageCycleDetectionTreeModel class>>#onPackagesNamed:

 @Yuri, can you change that.


 And I think we should fix RBParser.


 2015-09-16 11:30 GMT+02:00 Thierry Goubier :

> Nicolai,
>
> can you try with the RBParser directly? I believe Opal uses the
> RBParser.
>
> RBParser parseMethod: 'createRedMorph
> ^ (self new color:Color red); yourself'
>
> Oh, RBParser sees it as:
>
> self new
> color: Color red;
> yourself
>
> :)
>
> Thierry
>
>
> 2015-09-16 10:56 GMT+02:00 Nicolai Hess :
>
>> The following method compiles with Opal:
>>
>> createRedMorph
>> ^ (self new color:Color red); yourself
>>
>> but gives a syntax error with the old compilers parser
>>
>> createRedMorph
>> ^ (self new color:Color red)End of block expected -> ; yourself
>>
>>
>> removing the parenthesis of course works for both.
>> Who is right ?
>>
>>
>> (for those who understand the ParseTreeSearcher syntax, how would
>> a search expression look, for finding code like:
>>
>>"(some expression);yourself"
>>
>>
>> nicolai
>>
>>
>

>>>
>>
>

Re: [Pharo-dev] Remove rule "References an abstract class"

[Yuriy Tymchuk]

Hi.

First of all: thank you for the feedback Damien!
It makes sense, the rule also has higher amount of negative feedback. I will 
remove it from QA, let it stay in the image, it actually can be useful.

Uko


> On 17 Sep 2015, at 06:49, Damien Cassou  wrote:
> 
> This lint rule pops up all the times and my code is always ok. I
> typically have to reference an abstract class when:
> 
> - the abstract class takes care of choosing the concrete class to
>  instantiate
> 
> - the abstract class takes care of some shared variable for its
>  subclasses (e.g., a cache or an shared external object)
> 
> I propose to remove this rule which has never been useful for me.
> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
> 

[Pharo-dev] [Reflectivity] Links on Block creation vs. execution

[Marcus Denker]

Hi,

For blocks, we now have the correct model to destinguish “block creation” from 
“block execution”:

1) put a link on the block node, it will be called when the block definition 
(creation) is executed.

e.g. when you put a before link on the block in this method, it will be called 
when you execute the method:

TT>>method
^[1 + 2].

2) put a link on the *body* of the block (the sequence of statements), it will 
be called when the block *executes*.

For the example, it would not be called when executing “TT new method”, but 
only when you do “TT new method value”.


Test:

testBeforeBlockSequenceNoValue
| sequence link |
sequence := (ReflectivityExamples >> #exampleBlockNoValue) ast 
statements first value body.
self assert: sequence isSequence.
link := MetaLink new
metaObject: self;
selector: #tagExec.
sequence link: link.
self assert: sequence hasMetalinkBefore.
self assert: (ReflectivityExamples >> #exampleBlockNoValue) class = 
ReflectiveMethod.
self assert: tag isNil.
ReflectivityExamples new exampleBlockNoValue.
self assert: tag isNil.
ReflectivityExamples new exampleBlockNoValue value.
self assert: tag = 'yes'.
self assert: (ReflectivityExamples >> #exampleBlockNoValue) class = 
CompiledMethod.
link uninstall.
ReflectivityExamples recompile: #exampleBlockNoValue



Marcus

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

[Sven Van Caekenberghe]

> On 17 Sep 2015, at 09:32, Thierry Goubier  wrote:
> 
> 
> 
> 2015-09-17 9:10 GMT+02:00 Nicolai Hess :
> 
> 
> 2015-09-16 15:14 GMT+02:00 Thierry Goubier :
> Argh, sent too early:
> 
> self new color: Color red; yourself 
> 
> est bien une cascade, non?
> 
> Yes, but in
> 
> (self new color: Color red); yourself 
> the expression in parenthesis looks like "this evalulates first, to 
> 'anObject' ", so we send " ; yourself",
> a cascaded messages with only one message to "anObject".
> 
> Yes, agreed of course.
> 
> In a way, it looks like an error correction type of thing: the parser knows 
> the parenthesis shouldn't be there or the ; shouldn't be there, so it chooses 
> one interpretation out of the two: here it is the parenthesis are unnecessary.

Hmm, I don't agree. 

We as humans can infer that, from a language/compiler's standpoint it is not 
clear/possible.

  someObject message1; message2 is a pure cascade
  (someObject message1) message2 is not a cascade, message2 being sent to the 
result

the last expression is totally equivalent to

  someObject message1 message2

However

  expression message
  expression ; message 

could be equivalent, like if it said

  expression yourself; message

but the decision to drop the parenthesis cannot be made automatically, IMHO

I would make the spurious ; an error, to avoid confusion

> By the way, John found another issue with a fix you did in RBParser 
> (RBPatternParser>>parseUnaryMessage) which fail some refactoring expressions. 
> Can you have a look?
> 
> Thierry
>  
> 
> 
> 
>  
> 
> 
> 
> Thierry
> 
> 
> 2015-09-16 15:12 GMT+02:00 Thierry Goubier :
> 
> 
> 2015-09-16 15:05 GMT+02:00 Nicolai Hess :
> OK, I think Sven is right and a cascade needs at least one message send
> 
> "self ; yourself"
> 
> doesn't work too (both parser don't accept this).
> 
> But
> 
>  
> 
> There are currently two methods in Pharo 5.0 with this 
> syntax:
> 
> DAPackageAnalyzerWindow class>>#onPackagesNamed:
> DAPackageCycleDetectionTreeModel class>>#onPackagesNamed:
> 
> @Yuri, can you change that.
> 
> 
> And I think we should fix RBParser.
> 
> 
> 2015-09-16 11:30 GMT+02:00 Thierry Goubier :
> Nicolai,
> 
> can you try with the RBParser directly? I believe Opal uses the RBParser.
> 
> RBParser parseMethod: 'createRedMorph
> ^ (self new color:Color red); yourself'
> 
> Oh, RBParser sees it as:
> 
> self new
>   color: Color red;
>   yourself
> 
> :)
> 
> Thierry
> 
> 
> 2015-09-16 10:56 GMT+02:00 Nicolai Hess :
> The following method compiles with Opal:
> 
> createRedMorph
> ^ (self new color:Color red); yourself
> 
> but gives a syntax error with the old compilers parser
> 
> createRedMorph
> ^ (self new color:Color red)End of block expected -> ; yourself
> 
> 
> removing the parenthesis of course works for both.
> Who is right ?
> 
> 
> (for those who understand the ParseTreeSearcher syntax, how would
> a search expression look, for finding code like:
> 
>"(some expression);yourself"
> 
> 
> nicolai

Re: [Pharo-dev] Remove rule "References an abstract class"

[Christophe Demarey]

yes the problem with rules comes when the rule add more noise than is helpful.
If you do not want to remove this rule because it is useful in some cases, 
maybe the rule could check only these specific situations to do not add noise 
in others.

Le 17 sept. 2015 à 10:37, Yuriy Tymchuk a écrit :

> Ok, it can be removed from Pharo… I still find it useful as well as missing 
> yourself, but I can keep track of then individually :)
> 
> 
>> On 17 Sep 2015, at 09:39, Peter Uhnák  wrote:
>> 
>> You can probably remove it directly from Pharo instead
>> https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule
>> 
>> Peter
>> 
>> On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk  wrote:
>> Hi.
>> 
>> First of all: thank you for the feedback Damien!
>> It makes sense, the rule also has higher amount of negative feedback. I will 
>> remove it from QA, let it stay in the image, it actually can be useful.
>> 
>> Uko
>> 
>> 
>> > On 17 Sep 2015, at 06:49, Damien Cassou  wrote:
>> >
>> > This lint rule pops up all the times and my code is always ok. I
>> > typically have to reference an abstract class when:
>> >
>> > - the abstract class takes care of choosing the concrete class to
>> >  instantiate
>> >
>> > - the abstract class takes care of some shared variable for its
>> >  subclasses (e.g., a cache or an shared external object)
>> >
>> > I propose to remove this rule which has never been useful for me.
>> >
>> > --
>> > Damien Cassou
>> > http://damiencassou.seasidehosting.st
>> >
>> > "Success is the ability to go from one failure to another without
>> > losing enthusiasm." --Winston Churchill
>> >
>> 
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] Remove rule "References an abstract class"

[Marcus Denker]

> On 17 Sep 2015, at 12:50, Yuriy Tymchuk  wrote:
> 
> Well, what I am saying is that I agree that people should not be bothered 
> with this rule by QualityAssistant. But why we should remove the rule from 
> the image?
> 
Because it is wrong? If we keep it, people will see it when they use the Critic 
Browser… what would be the reason to keep a rule that everyone things is not 
good?

Marcus

Re: [Pharo-dev] Rubric/Event handling issue?

[Ben Coman]

On Tue, Sep 15, 2015 at 11:49 PM, Stephan Eggermont  wrote:
> There is an interesting bad interaction between my drag-and-drop code and
> Rubric. It kills all Rubric editors at the same time, so it looks
> to me like a problem with the Rubric background thread interacting with
> mouseMove or mouseEnter/Leave.
>
> https://vimeo.com/139353992

It looks like there was meant to be sound, but I didn't hear any
(could just be me)
cheers -ben

>
> To reproduce,
> Load DragPanels from StephanEggermont/DragPanels
> and NewUI from StephanEggermont/Documentation
>
> In a Playground open a panel
> CodePanel new openInWindowLabeled:'Code Panel'
>
> add a few cards (drop them in the panel)
> (CodeCard class: CodeCard selector: #initialize) openInHand
> and expand them by clicking on the arrow
>
> Right click on the empty area in the CodePanel and open the
> colors. A fast drag from the color panel to the rubric area of the
> code card sometimes results in the rubric editors losing their content.
>
> Stephan
>
>

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

[Henrik Nergaard]

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben
Coman
Sent: Wednesday, September 16, 2015 6:39 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] Pedantic on Random>>nextValue method name

On Wed, Sep 16, 2015 at 11:22 PM, Henrik Nergaard  wrote:
>> The method #nextValue actually calculates the next value the seed 
>> should be, the current value can be accessed by sending #seed.

>> I do agree that #nextValue might not be the clearest method name for 
>> its use; perhaps #nextSeed would be a better name?

>Yes. Thats better again.  Now its a private method, so there should be 
>problem changing it ;) ??anyone

Continuing on another Random topic related to..
https://pharo.fogbugz.com/default.asp?16577

I notice that Collection>>atRandom is protected by a mutex but
Collection>>atRandom: is not.  This makes me believe the protection is
for the Random generator and not for the actual picking of the element from
the collection.  So it seems that #atRandom holds the mutex too long - for
both random generation and element picking.
(>
Is there a specific use for the mutex in this case? I tried to use a shared
random without the mutex, and forking a few block closures, worked fine..

If the mutex could be removed we could just add a method in the class side
of Random like this:

globalGenerator
^Generator ifNil: [ Generator := Random new]

<) 

Thus I wonder if rather than copying the existing pattern of
Collection>>atRandom to GlobalSharedRandom>>generateFor:  it might be
better to make a more generic SharedRandom as follows...

(>
Maybe :P

I had a look at the Random Superclass in SciSmalltalk; here #next is used to
create and give the next random value. #seed for seed, and #peek for
checking what the next value would be without changing the current state. 
The peek method could be a good addition in Random -> 
Random>>#Peak
   Self nextValue / m

I would keep the way the #nextValue method behaves since this gives the
option to "peek" at the next value the Ivar seed will have without changing
it (could be useful?), but the name could be improved to be more clear. 
Perhaps the method name #nextSeed might not be so good after all, it might
imply that the method creates a new seed, but what it actually does is to go
to the next state in the random generation? ( so a better name could be
#nextState ?), (perhaps the Ivar seed would also be better called state or
internalState? )

<)

"Old calls to #next changed to private #nextValue"

Random>>nextValue
| lo hi aLoRHi answer |
hi := (seed quo: q) asFloat.
lo := seed - (hi * q).  " = seed rem: q"
aLoRHi := (a * lo) - (r * hi).
seed := (aLoRHi > 0.0)
 ifTrue:  [aLoRHi]
 ifFalse: [aLoRHi + m].
^ seed / m  "this line moved here from old #next"

Random>>next
 ^ self nextValue

Random>>next: anInteger into: anArray
1 to: anInteger do: [:index | anArray at: index put: self nextValue].
^ anArray

Random>>nextInt: anInteger
anInteger strictlyPositive ifFalse: [ self error: 'Range must be
positive' ].
anInteger asFloat isInfinite
ifTrue: [^(self nextValue asFraction * anInteger) truncated + 1].
^ (self nextValue * anInteger) truncated + 1


"SharedRandom protects all calls to private #nextValue"

Random subclass: SharedRandom
 instanceVariableNames: 'mutex'

SharedRandom>>initialize
 mutex := Semaphore forMutualExclusion.

SharedRandom>>next
^ mutex critical: [ self nextValue ]

SharedRandom>>next: anInteger into: anArray
^ mutex critical: [ super next: anInteger into: anArray ].

SharedRandom>>nextInt: anInteger
^ mutex critical: [ nextInt: anInteger ].


Then...

Object subclass: GlobalSharedRandom
classVariables: 'sharedRandom'

GlobalSharedRandom class>>initialize
sharedRandom := SharedRandom new.

GlobalSharedRandom class>>generator
^ sharedRandom


And finally...

Collection>>atRandom
^ self randomAt: GlobalSharedRandom generator. (> +1 <)


What do you think?
cheers, Ben

What do you think?
Best regards,
Henrik





--
View this message in context: 
http://forum.world.st/Pedantic-on-Random-nextValue-method-name-tp4850582p4850743.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Contribution scheme confusing ...

[Marcus Denker]

> On 16 Sep 2015, at 22:17, Torsten Bergmann  wrote:
> 
> We are in a transition to use more and more ConfigurationOf
> to manage packages included in Pharo 5.
> 

Yes, and it is a mess.

> But neither the new help topic "How to contribute to Pharo base code" 
> nor the link it points to http://pharo.org/contribute-propose-fix reflects 
> this.
> 

Yes, I will put it on my TODO to update it.
> Also - how do I know which code has to be managed by a Configuration 
> and where is the original repo if so.
> 
> How will I submit a fix that includes code to change both: somthing that is 
> managed
> vai config and something that is a change on a regular slice managed 
> package...
> 
> Also:
> I did a simple fix on NautilusGroupAutoBuilder package - there is
> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally 
> or externally now?
> 
Even I can not tell you.

Marcus

Re: [Pharo-dev] Remove rule "References an abstract class"

[Yuriy Tymchuk]

Because people can choose in critic browser what they want to see. At least 
this is my opinion. As a sneak peek to the survey results I can say that there 
are people who find the removed of “missing yourself” rule as a negative 
change. Of course they are only a few of them, but as you are not able to set 
up what rules you want to have in QualityAssistant, it makes sense to remove 
ones that the majority does not like. But in critics browser we can specify 
which rules you want to run. So I don’t see a need in a complete removal. Yes, 
maybe form UX perspective critic browser should have some button like: “Run 
only the important ones”…

Uko

> On 17 Sep 2015, at 13:43, Marcus Denker  wrote:
> 
> 
>> On 17 Sep 2015, at 12:50, Yuriy Tymchuk  wrote:
>> 
>> Well, what I am saying is that I agree that people should not be bothered 
>> with this rule by QualityAssistant. But why we should remove the rule from 
>> the image?
>> 
> Because it is wrong? If we keep it, people will see it when they use the 
> Critic Browser… what would be the reason to keep a rule that everyone things 
> is not good?
> 
>   Marcus
> 
> 
> 

Re: [Pharo-dev] Remove rule "References an abstract class"

[Marcus Denker]

> On 17 Sep 2015, at 14:08, Yuriy Tymchuk  wrote:
> 
> Because people can choose in critic browser what they want to see. At least 
> this is my opinion. As a sneak peek to the survey results I can say that 
> there are people who find the removed of “missing yourself” rule as a 
> negative change

When I learned something than this: Whatever you do, someone will think it is 
wrong. The largest mistake that you can do is to only do things that nobody 
objects to… because the only thing that fulfils that is to do nothing.

Marcus

Re: [Pharo-dev] Remove rule "References an abstract class"

[Yuriy Tymchuk]

Well, what I am saying is that I agree that people should not be bothered with 
this rule by QualityAssistant. But why we should remove the rule from the image?

Uko



> On 17 Sep 2015, at 12:11, Christophe Demarey  
> wrote:
> 
> yes the problem with rules comes when the rule add more noise than is helpful.
> If you do not want to remove this rule because it is useful in some cases, 
> maybe the rule could check only these specific situations to do not add noise 
> in others.
> 
> Le 17 sept. 2015 à 10:37, Yuriy Tymchuk a écrit :
> 
>> Ok, it can be removed from Pharo… I still find it useful as well as missing 
>> yourself, but I can keep track of then individually :)
>> 
>> 
>>> On 17 Sep 2015, at 09:39, Peter Uhnák >> > wrote:
>>> 
>>> You can probably remove it directly from Pharo instead
>>> https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule 
>>> 
>>> 
>>> Peter
>>> 
>>> On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk >> > wrote:
>>> Hi.
>>> 
>>> First of all: thank you for the feedback Damien!
>>> It makes sense, the rule also has higher amount of negative feedback. I 
>>> will remove it from QA, let it stay in the image, it actually can be useful.
>>> 
>>> Uko
>>> 
>>> 
>>> > On 17 Sep 2015, at 06:49, Damien Cassou >> > > wrote:
>>> >
>>> > This lint rule pops up all the times and my code is always ok. I
>>> > typically have to reference an abstract class when:
>>> >
>>> > - the abstract class takes care of choosing the concrete class to
>>> >  instantiate
>>> >
>>> > - the abstract class takes care of some shared variable for its
>>> >  subclasses (e.g., a cache or an shared external object)
>>> >
>>> > I propose to remove this rule which has never been useful for me.
>>> >
>>> > --
>>> > Damien Cassou
>>> > http://damiencassou.seasidehosting.st 
>>> > 
>>> >
>>> > "Success is the ability to go from one failure to another without
>>> > losing enthusiasm." --Winston Churchill
>>> >
>>> 
>>> 
>>> 
>> 
> 

Re: [Pharo-dev] Rubric/Event handling issue?

[stepharo]

I forwarded to alain.
Now this is the restart of the university...

Stef

Le 15/9/15 17:49, Stephan Eggermont a écrit :
There is an interesting bad interaction between my drag-and-drop code 
and Rubric. It kills all Rubric editors at the same time, so it looks

to me like a problem with the Rubric background thread interacting with
mouseMove or mouseEnter/Leave.

https://vimeo.com/139353992

To reproduce,
Load DragPanels from StephanEggermont/DragPanels
and NewUI from StephanEggermont/Documentation

In a Playground open a panel
CodePanel new openInWindowLabeled:'Code Panel'

add a few cards (drop them in the panel)
(CodeCard class: CodeCard selector: #initialize) openInHand
and expand them by clicking on the arrow

Right click on the empty area in the CodePanel and open the
colors. A fast drag from the color panel to the rubric area of the
code card sometimes results in the rubric editors losing their content.

Stephan

Re: [Pharo-dev] Rubric/Event handling issue?

[Stephan Eggermont]

ping

On 15-09-15 17:49, Stephan Eggermont wrote:

There is an interesting bad interaction between my drag-and-drop code
and Rubric. It kills all Rubric editors at the same time, so it looks
to me like a problem with the Rubric background thread interacting with
mouseMove or mouseEnter/Leave.

https://vimeo.com/139353992

To reproduce,
Load DragPanels from StephanEggermont/DragPanels
and NewUI from StephanEggermont/Documentation

In a Playground open a panel
CodePanel new openInWindowLabeled:'Code Panel'

add a few cards (drop them in the panel)
(CodeCard class: CodeCard selector: #initialize) openInHand
and expand them by clicking on the arrow

Right click on the empty area in the CodePanel and open the
colors. A fast drag from the color panel to the rubric area of the
code card sometimes results in the rubric editors losing their content.

Stephan

Re: [Pharo-dev] Remove rule "References an abstract class"

[Yuriy Tymchuk]

Ok, it can be removed from Pharo… I still find it useful as well as missing 
yourself, but I can keep track of then individually :)


> On 17 Sep 2015, at 09:39, Peter Uhnák  wrote:
> 
> You can probably remove it directly from Pharo instead
> https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule 
> 
> 
> Peter
> 
> On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk  > wrote:
> Hi.
> 
> First of all: thank you for the feedback Damien!
> It makes sense, the rule also has higher amount of negative feedback. I will 
> remove it from QA, let it stay in the image, it actually can be useful.
> 
> Uko
> 
> 
> > On 17 Sep 2015, at 06:49, Damien Cassou  > > wrote:
> >
> > This lint rule pops up all the times and my code is always ok. I
> > typically have to reference an abstract class when:
> >
> > - the abstract class takes care of choosing the concrete class to
> >  instantiate
> >
> > - the abstract class takes care of some shared variable for its
> >  subclasses (e.g., a cache or an shared external object)
> >
> > I propose to remove this rule which has never been useful for me.
> >
> > --
> > Damien Cassou
> > http://damiencassou.seasidehosting.st 
> > 
> >
> > "Success is the ability to go from one failure to another without
> > losing enthusiasm." --Winston Churchill
> >
> 
> 
> 

Re: [Pharo-dev] Remove rule "References an abstract class"

[Yuriy Tymchuk]

Well, for me it’s ok. Then I don’t have to create a new version in conf :).

> On 17 Sep 2015, at 14:17, Marcus Denker  wrote:
> 
> 
>> On 17 Sep 2015, at 14:08, Yuriy Tymchuk  wrote:
>> 
>> Because people can choose in critic browser what they want to see. At least 
>> this is my opinion. As a sneak peek to the survey results I can say that 
>> there are people who find the removed of “missing yourself” rule as a 
>> negative change
> 
> When I learned something than this: Whatever you do, someone will think it is 
> wrong. The largest mistake that you can do is to only do things that nobody 
> objects to… because the only thing that fulfils that is to do nothing.
> 
>   Marcus

[Pharo-dev] [pharo-project/pharo-core] 7586c2: 50330

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 7586c211f6842acc22a041ac7df29bc8fffbb659
  
https://github.com/pharo-project/pharo-core/commit/7586c211f6842acc22a041ac7df29bc8fffbb659
  Author: Jenkins Build Server 
  Date:   2015-09-17 (Thu, 17 Sep 2015)

  Changed paths:
A Deprecated50.package/extension/SmalltalkImage/instance/logChange_.st
R 
Monticello.package/MCVersionReader.class/class/System-FileRegistry/fileReaderServicesForFile_suffix_.st
R 
Monticello.package/MCVersionReader.class/class/System-FileRegistry/loadVersionFile_.st
R 
Monticello.package/MCVersionReader.class/class/System-FileRegistry/mergeVersionFile_.st
R 
Monticello.package/MCVersionReader.class/class/System-FileRegistry/openVersionFile_.st
R 
Monticello.package/MCVersionReader.class/class/System-FileRegistry/services.st
A Monticello.package/MCVersionReader.class/class/actions - 
file/loadVersionFile_.st
A Monticello.package/MCVersionReader.class/class/actions - 
file/mergeVersionFile_.st
A Monticello.package/MCVersionReader.class/class/actions - 
file/openVersionFile_.st
A 
MonticelloFileServices.package/extension/MCVersionReader/class/fileReaderServicesForFile_suffix_.st
A 
MonticelloFileServices.package/extension/MCVersionReader/class/loadVersionStream_fromDirectory_.st
A 
MonticelloFileServices.package/extension/MCVersionReader/class/mergeVersionStream_.st
A 
MonticelloFileServices.package/extension/MCVersionReader/class/openVersionFromStream_.st
A 
MonticelloFileServices.package/extension/MCVersionReader/class/serviceLoadVersion.st
A 
MonticelloFileServices.package/extension/MCVersionReader/class/serviceMergeVersion.st
A 
MonticelloFileServices.package/extension/MCVersionReader/class/serviceOpenVersion.st
A MonticelloFileServices.package/extension/MCVersionReader/class/services.st
M Nautilus.package/PackageTreeNautilusUI.class/instance/package 
filter/package_matchPackagePattern_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50329.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50330.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50329.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50330.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
R System-Support.package/SmalltalkImage.class/instance/sources%2C change 
log/logChange_.st

  Log Message:
  ---
  50330
16523 Nautilus Regex Search Box borken
https://pharo.fogbugz.com/f/cases/16523

16587 Deprecate SmalltalkImage>>#logChange:
https://pharo.fogbugz.com/f/cases/16587

16573 Monticello should not depend on System-FileRegistry
https://pharo.fogbugz.com/f/cases/16573

http://files.pharo.org/image/50/50330.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

Re: [Pharo-dev] Rubric/Event handling issue?

[Stephan Eggermont]

On 17-09-15 13:59, Ben Coman wrote:

On Tue, Sep 15, 2015 at 11:49 PM, Stephan Eggermont  wrote:

There is an interesting bad interaction between my drag-and-drop code and
Rubric. It kills all Rubric editors at the same time, so it looks
to me like a problem with the Rubric background thread interacting with
mouseMove or mouseEnter/Leave.

https://vimeo.com/139353992


It looks like there was meant to be sound, but I didn't hear any
(could just be me)
cheers -ben


Yes, there is sound, and it is 720p video. I'm probably constructing the 
rubric editor incorrectly, and it would be good if that would only 
interfere with the ones I created...


Stephan

Re: [Pharo-dev] [review needed] speed up RBClassNotReferencedRule

[Paul DeBruicker]

Marcus Denker-4 wrote
> Hi,
> 
> Review needed for
> 
> 
> https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-slower-in-Pharo-4-vs-Pharo-3
> 
> Speedup can be checked with:
> 
> rule:=RBClassNotReferencedRule new.
> environment:=RBBrowserEnvironment new forPackageNames: #('Fuel').
> [RBSmalllintChecker runRule: rule onEnvironment:
> environment] timeToRun 
> 
> 
> Pharo5: "0:00:00:13.526"
> Pharo5 with fix: "0:00:00:00.761"
> Pharo3:  0:00:00:00.547
> 
> Checking all classes for usage:
> 
> [Smalltalk allClassesAndTraits select: [ : each | each isUsed not]]
> timeToRun
> 
> still takes 1:40 to find 600 unused classes.
> 
> This shows that adding a cache for “referenced classes” per environment
> would speed this
> up further. But it should be general, not just for RB or even RB Code
> Critique.
> 
> The nice things is that code environments only change when you add classes
> or methods,
> so adding a very general cache should be quite possible.
> 
> Another thing we should add is a way for classes to define “I am used”.
> E.g this
> now finds all Configurations, all the Manifests and all cases like the RB
> Rules themselves.
> All these should know that they are not useless even though there are no
> references.
> 
>   Marcus

Thanks for working on this.   I have a use for it this week.  

For methods RB allows one to add a pragma e.g.: 



and described here: http://www.lukas-renggli.ch/blog/ignoring-lint-rules. 
Maybe we can hijack that mechanism with a class side method e.g.

rbNotReferenced
 


Do your modifications test sends of subclassesDo: and friends?

OR 

#(#MyClass1 #MyClass2 #MyClass3) collect:[:ea | (Smalltalk at: ea)
doSomething].

The reason I ask is I'm planning to do a bunch of cleanup of a package and
it would be nice to not worry about those cases getting missed







--
View this message in context: 
http://forum.world.st/review-needed-speed-up-RBClassNotReferencedRule-tp4845838p4850824.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Contribution scheme confusing ...

[Marcus Denker]

>> 
>> Also:
>> I did a simple fix on NautilusGroupAutoBuilder package - there is
>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally 
>> or externally now?
>> 
> Even I can not tell you.
> 

I think the rule we should adopt: if there is a dedicated repository defined in 
the image for a package, people should commit
there. If there is non (just the inbox), then this should be used (with the 
Slice mechanism).

The repositories in the image should be already up to date, I think.

Marcus

Re: [Pharo-dev] EncodedCharSets

[Henrik Johansen]

> On 17 Sep 2015, at 4:09 , Christophe Demarey  
> wrote:
> 
> Hi again,
> 
> Does anyone know the rationale behind this?
> 
> declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass atIndex: 
> aNumber
> 
>   EncodedCharSets at: aNumber put: 
> anEncodedCharSetOrLanguageEnvironmentClass
> 
>   "this method is used to modularize the old initialize method:
>   EncodedCharSets at: 0+1 put: Unicode.
>   EncodedCharSets at: 1+1 put: JISX0208.
>   EncodedCharSets at: 2+1 put: GB2312.
>   EncodedCharSets at: 3+1 put: KSX1001.
>   EncodedCharSets at: 4+1 put: JISX0208.
>   EncodedCharSets at: 5+1 put: JapaneseEnvironment.
>   EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment.
>   EncodedCharSets at: 7+1 put: KoreanEnvironment.
>   EncodedCharSets at: 8+1 put: GB2312.
>   EncodedCharSets at: 12+1 put: KSX1001.
>   EncodedCharSets at: 13+1 put: GreekEnvironment.
>   EncodedCharSets at: 14+1 put: Latin2Environment.
>   EncodedCharSets at: 15+1 put: RussianEnvironment.
>   EncodedCharSets at: 17+1 put: Latin9Environment.
>   EncodedCharSets at: 256 put: Unicode.
> 
>   "

If you mean the name EncodedCharSets, and the fact there are Encodings in that 
list, it is a leftover from when WideStrings code points could be in character 
sets other than Unicode.
That made little sense since each WideChar takes 32 bits anyways (other than a 
possibly simpler codePoint -> glyph index translation described below), so 
most/all places where this happened have been removed and we now assume 
WideString code points to be equal to unicode code points.

The goal of the old code was to give parameters to the old StrikeFont string 
display primitive, which is limited to using a table of 256 glyphs for any 
string it wants to render.
The Scanners job was to introduce stops when it encounters a change that makes 
the string it's scanning unable to be displayed by a single call to the 
primitive.
The presence of a leadingChar induced(/s) a stop in the Scanner, which explains 
the mix of encodings and Languages (whose codePoints are in Unicode) in the 
EncodedCharSets table.
This stop let a properly constructed StrikeFontSet swap in a glyph table 
suitable for displaying the leading char, using a custom codePoint -> glyph 
index conversion.

TLDR; It's a relic of a more complex past used in a mechanism that let 
StrikeFonts display other than macroman characters.

Cheers,
Henry

P.S. Funnily enough, the mechanism is somewhat similar to what would be needed 
to swap in fallback fonts for code points not covered by the default font 
efficiently (although the stop would be on missing glyph, rather than leading 
char), instead of the current, doomed-to-fail approach of using a FallbackFont 
in each font.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] Contribution scheme confusing ...

[Torsten Bergmann]

Hi Marcus,

Could work - but is a fragile rule. We should document it somewhere.

What about providing this info directly in the image. Alexandre has already 
added a help topic on how 
to contribute (but yet only for the slice process).

I changed it so we can have the differences of config managed ones described as 
well and 
we can list the configs there. See the attached changeset that you can file in 
into the latest
Pharo5.0 Latest update: #50329

File in and check "How to contribute to Pharo base code" topic in Help -> Help 
Browser

I guess this would be more clear to us and the users and we can simply point to
the help info is someone asks. And look up ourself when we forgot.

Thx
T.

> Gesendet: Donnerstag, 17. September 2015 um 15:40 Uhr
> Von: "Marcus Denker" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] Contribution scheme confusing ...
>
> >> 
> >> Also:
> >> I did a simple fix on NautilusGroupAutoBuilder package - there is
> >> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally 
> >> or externally now?
> >> 
> > Even I can not tell you.
> > 
> 
> I think the rule we should adopt: if there is a dedicated repository defined 
> in the image for a package, people should commit
> there. If there is non (just the inbox), then this should be used (with the 
> Slice mechanism).
> 
> The repositories in the image should be already up to date, I think.
> 
>   Marcus
> 
> 
> 

HowToContributeHelp class.TorstenBergmann.cs
Description: Binary data

Re: [Pharo-dev] About the Unicode class

[Henrik Johansen]

> On 17 Sep 2015, at 2:58 , Christophe Demarey  
> wrote:
> 
> Hi,
> 
> Does anyone know why there are so many class variables in Unicode and what 
> they are used for?
> Most of them have no sender.
> 
> EncodedCharSet subclass: #Unicode
>   instanceVariableNames: ''
>   classVariableNames: 'Cc Cf Cn Co Cs DecimalProperty GeneralCategory Ll 
> Lm Lo Lt Lu Mc Me Mn Nd Nl No Pc Pd Pe Pf Pi Po Ps Sc Sk Sm So ToCasefold 
> ToLower ToUpper Zl Zp Zs'
>   category: 'Multilingual-Encodings'
> 
> Thanks,
> Christophe

A partial / incomplete / broken implementation of querying character 
properties, I'd guess.
See for instance:
http://en.wikipedia.org/wiki/Unicode_character_property
http://www.fileformat.info/info/unicode/category/index.htm 


Cheers,
Henry


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] About the Unicode class

[Nicolas Cellier]

There has been some work on Squeak by Levente in this area, maybe it's time
to harvest...

2015-09-17 18:22 GMT+02:00 Henrik Johansen :

>
> On 17 Sep 2015, at 2:58 , Christophe Demarey 
> wrote:
>
> Hi,
>
> Does anyone know why there are so many class variables in Unicode and what
> they are used for?
> Most of them have no sender.
>
> EncodedCharSet subclass: #Unicode
> instanceVariableNames: ''
> classVariableNames: 'Cc Cf Cn Co Cs DecimalProperty GeneralCategory Ll Lm
> Lo Lt Lu Mc Me Mn Nd Nl No Pc Pd Pe Pf Pi Po Ps Sc Sk Sm So ToCasefold
> ToLower ToUpper Zl Zp Zs'
> category: 'Multilingual-Encodings'
>
> Thanks,
> Christophe
>
>
> A partial / incomplete / broken implementation of querying character
> properties, I'd guess.
> See for instance:
> http://en.wikipedia.org/wiki/Unicode_character_property
> http://www.fileformat.info/info/unicode/category/index.htm
>
> Cheers,
> Henry
>

[Pharo-dev] EncodedCharSets

[Christophe Demarey]

Hi again,

Does anyone know the rationale behind this?

declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass atIndex: 
aNumber

EncodedCharSets at: aNumber put: 
anEncodedCharSetOrLanguageEnvironmentClass

"this method is used to modularize the old initialize method: 
EncodedCharSets at: 0+1 put: Unicode.
EncodedCharSets at: 1+1 put: JISX0208.
EncodedCharSets at: 2+1 put: GB2312.
EncodedCharSets at: 3+1 put: KSX1001.
EncodedCharSets at: 4+1 put: JISX0208.
EncodedCharSets at: 5+1 put: JapaneseEnvironment.
EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment.
EncodedCharSets at: 7+1 put: KoreanEnvironment.
EncodedCharSets at: 8+1 put: GB2312.
EncodedCharSets at: 12+1 put: KSX1001.
EncodedCharSets at: 13+1 put: GreekEnvironment.
EncodedCharSets at: 14+1 put: Latin2Environment.
EncodedCharSets at: 15+1 put: RussianEnvironment.
EncodedCharSets at: 17+1 put: Latin9Environment.
EncodedCharSets at: 256 put: Unicode.

"





smime.p7s
Description: S/MIME cryptographic signature

[Pharo-dev] About the Unicode class

[Christophe Demarey]

Hi,

Does anyone know why there are so many class variables in Unicode and what they 
are used for?
Most of them have no sender.

EncodedCharSet subclass: #Unicode
instanceVariableNames: ''
classVariableNames: 'Cc Cf Cn Co Cs DecimalProperty GeneralCategory Ll 
Lm Lo Lt Lu Mc Me Mn Nd Nl No Pc Pd Pe Pf Pi Po Ps Sc Sk Sm So ToCasefold 
ToLower ToUpper Zl Zp Zs'
category: 'Multilingual-Encodings'

Thanks,
Christophe

Re: [Pharo-dev] Contribution scheme confusing ...

[Tudor Girba]

Exactly!

This is the cheapest way to document the process. We could even try to
automatically remove the inbox if there is another repository associated
with a package. What do you think?

Cheers,
Doru



On Thu, Sep 17, 2015 at 3:40 PM, Marcus Denker 
wrote:

> >>
> >> Also:
> >> I did a simple fix on NautilusGroupAutoBuilder package - there is
> >> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
> >> or externally now?
> >>
> > Even I can not tell you.
> >
>
> I think the rule we should adopt: if there is a dedicated repository
> defined in the image for a package, people should commit
> there. If there is non (just the inbox), then this should be used (with
> the Slice mechanism).
>
> The repositories in the image should be already up to date, I think.
>
> Marcus
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] EncodedCharSets

[Sven Van Caekenberghe]

> On 17 Sep 2015, at 19:26, Eliot Miranda  wrote:
> 
> Hi Christophe,
> 
> On Thu, Sep 17, 2015 at 7:09 AM, Christophe Demarey 
>  wrote:
> Hi again,
> 
> Does anyone know the rationale behind this?
> 
> declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass atIndex: 
> aNumber
> 
> EncodedCharSets at: aNumber put: 
> anEncodedCharSetOrLanguageEnvironmentClass
> 
> "this method is used to modularize the old initialize method:
> EncodedCharSets at: 0+1 put: Unicode.
> EncodedCharSets at: 1+1 put: JISX0208.
> EncodedCharSets at: 2+1 put: GB2312.
> EncodedCharSets at: 3+1 put: KSX1001.
> EncodedCharSets at: 4+1 put: JISX0208.
> EncodedCharSets at: 5+1 put: JapaneseEnvironment.
> EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment.
> EncodedCharSets at: 7+1 put: KoreanEnvironment.
> EncodedCharSets at: 8+1 put: GB2312.
> EncodedCharSets at: 12+1 put: KSX1001.
> EncodedCharSets at: 13+1 put: GreekEnvironment.
> EncodedCharSets at: 14+1 put: Latin2Environment.
> EncodedCharSets at: 15+1 put: RussianEnvironment.
> EncodedCharSets at: 17+1 put: Latin9Environment.
> EncodedCharSets at: 256 put: Unicode.
> 
> "
> 
> what Henrik says is correct.  Here's the relevant definition in Character:
> 
> Character>>leadingChar
>   "Answer the value of the 8 highest bits which is used to identify the 
> language.
>   This is mostly used for east asian languages CJKV as a workaround 
> against unicode han-unification."
>   ^ self asInteger bitShift: -22
> 
> 
> i.e. the top 8 bytes of the leading character in a string is (was?) used to 
> index EncodedCharSets to determine what language the string is in.

Past tense indeed, until someone can explain why we would need this while it 
cannot be found anywhere else.

> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

[Ben Coman]

On Thu, Sep 17, 2015 at 7:56 PM, Henrik Nergaard
 wrote:
>
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben
> Coman
> Sent: Wednesday, September 16, 2015 6:39 PM
> To: Pharo Development List 
> Subject: Re: [Pharo-dev] Pedantic on Random>>nextValue method name
>
> On Wed, Sep 16, 2015 at 11:22 PM, Henrik Nergaard  wrote:
>>> The method #nextValue actually calculates the next value the seed
>>> should be, the current value can be accessed by sending #seed.
>
>>> I do agree that #nextValue might not be the clearest method name for
>>> its use; perhaps #nextSeed would be a better name?
>
>>Yes. Thats better again.  Now its a private method, so there should be
>>problem changing it ;) ??anyone
>
> Continuing on another Random topic related to..
> https://pharo.fogbugz.com/default.asp?16577
>
> I notice that Collection>>atRandom is protected by a mutex but
> Collection>>atRandom: is not.  This makes me believe the protection is
> for the Random generator and not for the actual picking of the element from
> the collection.  So it seems that #atRandom holds the mutex too long - for
> both random generation and element picking.
> (>
> Is there a specific use for the mutex in this case? I tried to use a shared
> random without the mutex, and forking a few block closures, worked fine..

I was going to retort that inter-thread race conditions can be tricky
to invoke with considerations of timing and priorities :P  but then I
had the insight this can be done using the debugger as demonstrated
below.

Presuming that use cases exist that require the repeatable nature of a
PRNG. This feature is dependent on the /seed/ ivar having the same
value in the calculation of both /hi/ and /lo/ in #nextValue.  But
consider this sequence of events...

Priority 40 thread1 enters #next, then #nextValue, and takes the
current value of /seed/ to calculate /hi/. Then before proceeding to
the line, priority 50 thread2 enters #next and updates the value of
/seed/.  Thread1 then proceeds to take calculate /lo/ with a different
value of /seed/  -- thus the algorithm is broken.

This might be addressed by caching /seed/ ivar into a temporary
/safeThreadCopySeed/.

Yet other use cases may exist that expect simultaneous threads don't
receive the same random number (more often than single thread would.)
 So priority 40 thread1 enters #next, then #nextValue, and copies the
current value of /seed/ into /safeThreadCopySeed/.  Then before it can
update /seed/, priority 50 thread2 enters #next, then #nextValue, and
copies the same current value of /seed/ into /safeThreadCopySeed/. So
both threads will receive the same random number. To demonstrate...

| sharedRandom
 context1 process1 thread1 result1
 context2 process2 thread2 result2 |
sharedRandom := Random new.
context1 := [ result1 := sharedRandom next ] asContext.
context2 := [ result2 := sharedRandom next ] asContext.
process1 := Process forContext: context1 priority: 40.
process2 := Process forContext: context2 priority: 40.
thread1 := DebugSession process: process1 context: context1.
thread2 := DebugSession process: process2 context: context2.
100 timesRepeat: [
result1 ifNil: [thread1 stepInto].
result2 ifNil: [thread2 stepInto].  ].
Transcript crShow: result1; tab; tab; show: result2.

>
> If the mutex could be removed we could just add a method in the class side
> of Random like this:
>
> globalGenerator
> ^Generator ifNil: [ Generator := Random new]

I don't think Random should have a global. Instead the same on the
proposed SharedRandom might be suitable using a
class-instance-variable...

SharedRandom class
instanceVariableNames: 'globalGenerator'

SharedRandom>>globalGenerator
^ globalGenerator ifNil: [ globalGenerator := self new].

Then we can have...

Collection>>atRandom
^ self randomAt: SharedRandom globalGenerator.

cheers -ben

> Thus I wonder if rather than copying the existing pattern of
> Collection>>atRandom to GlobalSharedRandom>>generateFor:  it might be
> better to make a more generic SharedRandom as follows...
>
> (>
> Maybe :P
>
> I had a look at the Random Superclass in SciSmalltalk; here #next is used to
> create and give the next random value. #seed for seed, and #peek for
> checking what the next value would be without changing the current state.
> The peek method could be a good addition in Random ->
> Random>>#Peak
>Self nextValue / m
>
> I would keep the way the #nextValue method behaves since this gives the
> option to "peek" at the next value the Ivar seed will have without changing
> it (could be useful?), but the name could be improved to be more clear.
> Perhaps the method name #nextSeed might not be so good after all, it might
> imply that the method creates a new seed, but what it actually does is to 

Re: [Pharo-dev] Rubric/Event handling issue?

[Ben Coman]

On Thu, Sep 17, 2015 at 8:47 PM, Stephan Eggermont  wrote:
> On 17-09-15 13:59, Ben Coman wrote:
>>
>> On Tue, Sep 15, 2015 at 11:49 PM, Stephan Eggermont 
>> wrote:
>>>
>>> There is an interesting bad interaction between my drag-and-drop code and
>>> Rubric. It kills all Rubric editors at the same time, so it looks
>>> to me like a problem with the Rubric background thread interacting with
>>> mouseMove or mouseEnter/Leave.
>>>
>>> https://vimeo.com/139353992
>>
>>
>> It looks like there was meant to be sound, but I didn't hear any
>> (could just be me)
>> cheers -ben
>
>
> Yes, there is sound, and it is 720p video. I'm probably constructing the
> rubric editor incorrectly, and it would be good if that would only interfere
> with the ones I created...

Problem was at my end.
cheers -ben

Re: [Pharo-dev] Contribution scheme confusing ...

[Ben Coman]

On Thu, Sep 17, 2015 at 9:40 PM, Marcus Denker  wrote:
>>>
>>> Also:
>>> I did a simple fix on NautilusGroupAutoBuilder package - there is
>>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
>>> or externally now?
>>>
>> Even I can not tell you.
>>
>
> I think the rule we should adopt: if there is a dedicated repository defined 
> in the image for a package, people should commit
> there. If there is non (just the inbox), then this should be used (with the 
> Slice mechanism).
>
> The repositories in the image should be already up to date, I think.
>
> Marcus
>
>

How would the CI monkey work with Configurations from other repositories?

My workflow for reviewing a submitted fix (e.g. for issue 1)  is
to open the Pharo5Inbox repository and filter on the issue number,
which leaves the SLICE-Issue-1 as the only item.  Having to
discover where fixes are scattered makes it harder to review fixes,
and they will get less review  Now if the Inbox contained
ConfigurationofXyz-Issue-1, it would be simple to identify what
needs to be reviewed.   This might even help the CI monkey to pick up
Configurations for testing.


btw, it would be cool if a package loaded by a Configuration becomes
dirty, then the Configuration also becomes dirty, or is otherwise
flagged somehow.

cheers -ben

Re: [Pharo-dev] PID of VM ?

[stepharo]

nativeboost is not maintained and we need a solution that can be 
maintained by multiple people.
Normally with the new FFI esteban is doing you will be able to use the 
NativeBoost syntax.


Bye
T.

Re: [Pharo-dev] Rubric/Event handling issue?

[Nicolai Hess]

2015-09-17 10:35 GMT+02:00 Stephan Eggermont :

> ping
>
>
> On 15-09-15 17:49, Stephan Eggermont wrote:
>
>> There is an interesting bad interaction between my drag-and-drop code
>> and Rubric. It kills all Rubric editors at the same time, so it looks
>> to me like a problem with the Rubric background thread interacting with
>> mouseMove or mouseEnter/Leave.
>>
>> https://vimeo.com/139353992
>>
>> To reproduce,
>> Load DragPanels from StephanEggermont/DragPanels
>> and NewUI from StephanEggermont/Documentation
>>
>> In a Playground open a panel
>> CodePanel new openInWindowLabeled:'Code Panel'
>>
>> add a few cards (drop them in the panel)
>> (CodeCard class: CodeCard selector: #initialize) openInHand
>> and expand them by clicking on the arrow
>>
>> Right click on the empty area in the CodePanel and open the
>> colors. A fast drag from the color panel to the rubric area of the
>> code card sometimes results in the rubric editors losing their content.
>>
>> Stephan
>>
>>
>>
>>
>
>
>
DragWell
startDrag: evt
WorldState addDeferredUIMessage: [ evt hand grabMorph: self copy ].

calls
Morph>>#copy
and this makes a veryDeepCopy.

I don't know exactly how this affects the other rubric text morphs, but
replacing
self copy
with
self shallowCopy
seems to work.

Re: [Pharo-dev] About the Unicode class

[stepharo]

Le 17/9/15 18:27, Nicolas Cellier a écrit :
There has been some work on Squeak by Levente in this area, maybe it's 
time to harvest...


Thanks nicolas for the information. It is in the Unicode class?



2015-09-17 18:22 GMT+02:00 Henrik Johansen 
>:




On 17 Sep 2015, at 2:58 , Christophe Demarey
> wrote:

Hi,

Does anyone know why there are so many class variables in Unicode
and what they are used for?
Most of them have no sender.

EncodedCharSet subclass: #Unicode
instanceVariableNames: ''
classVariableNames: 'Cc Cf Cn Co Cs DecimalProperty
GeneralCategory Ll Lm Lo Lt Lu Mc Me Mn Nd Nl No Pc Pd Pe Pf Pi
Po Ps Sc Sk Sm So ToCasefold ToLower ToUpper Zl Zp Zs'
category: 'Multilingual-Encodings'

Thanks,
Christophe


A partial / incomplete / broken implementation of querying
character properties, I'd guess.
See for instance:
http://en.wikipedia.org/wiki/Unicode_character_property
http://www.fileformat.info/info/unicode/category/index.htm

Cheers,
Henry

Re: [Pharo-dev] EncodedCharSets

[Eliot Miranda]

Hi Christophe,

On Thu, Sep 17, 2015 at 7:09 AM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi again,
>
> Does anyone know the rationale behind this?
>
> declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass atIndex:
> aNumber
>
> EncodedCharSets at: aNumber put:
> anEncodedCharSetOrLanguageEnvironmentClass
>
> "this method is used to modularize the old initialize method:
> EncodedCharSets at: 0+1 put: Unicode.
> EncodedCharSets at: 1+1 put: JISX0208.
> EncodedCharSets at: 2+1 put: GB2312.
> EncodedCharSets at: 3+1 put: KSX1001.
> EncodedCharSets at: 4+1 put: JISX0208.
> EncodedCharSets at: 5+1 put: JapaneseEnvironment.
> EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment.
> EncodedCharSets at: 7+1 put: KoreanEnvironment.
> EncodedCharSets at: 8+1 put: GB2312.
> EncodedCharSets at: 12+1 put: KSX1001.
> EncodedCharSets at: 13+1 put: GreekEnvironment.
> EncodedCharSets at: 14+1 put: Latin2Environment.
> EncodedCharSets at: 15+1 put: RussianEnvironment.
> EncodedCharSets at: 17+1 put: Latin9Environment.
> EncodedCharSets at: 256 put: Unicode.
>
> "
>

what Henrik says is correct.  Here's the relevant definition in Character:

Character>>leadingChar
"Answer the value of the 8 highest bits which is used to identify the
language.
This is mostly used for east asian languages CJKV as a workaround against
unicode han-unification."
^ self asInteger bitShift: -22


i.e. the top 8 bytes of the leading character in a string is (was?) used to
index EncodedCharSets to determine what language the string is in.

_,,,^..^,,,_
best, Eliot