Re: [Pharo-dev] .filetree file?

[Thierry Goubier]

Le 13/01/2016 01:48, Mariano Martinez Peck a écrit :

Hi Alex,

I was wondering the same just minutes ago. I wonder if GitFileTree could
do this for us?


Well, it looks like a bug. It normally writes and commit it by itself, 
but it seems that, in certain conditions, it gets written and committed 
without the expected values with the first package commit, then 
rewritten (without being committed).


I'll have a look.

Thierry




On Sun, Jul 5, 2015 at 7:03 PM, Alexandre Bergel
mailto:alexandre.ber...@me.com>> wrote:

Ok, thanks!

Alexandre


 > On Jul 6, 2015, at 12:02 AM, Sven Van Caekenberghe mailto:s...@stfx.eu>> wrote:
 >
 >
 >> On 05 Jul 2015, at 23:57, Alexandre Bergel
mailto:alexandre.ber...@me.com>> wrote:
 >>
 >> Hi!
 >>
 >> When using Filetree, there is this file .filetree in the git folder.
 >> What should I do with it? add it to the repository or ignore it?
 >
 > You have to add it. It contains meta information.
 >
 >> cheers,
 >> Alexandre
 >> --
 >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 >> Alexandre Bergel http://www.bergel.eu
 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 >>
 >>
 >>
 >>
 >
 >

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







--
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] [Ann] ReadWriteLock

[Ben Coman]

These two read together provide a balanced view.

ReaderWriterLock vs Monitor
http://www.interact-sw.co.uk/iangblog/2004/04/26/rwlockvsmonitor

When to use the ReaderWriterLock
https://www.interact-sw.co.uk/iangblog/2004/05/12/rwlock

cheers -ben

On Wed, Jan 13, 2016 at 6:27 AM, Jan Vrany  wrote:
> Hi Denis, all,
>
> I'm sorry for asking basic questions, but...
>
> I thought of this a little and I failed to see the advantage
> of using ReadWriteLock over monitor / mutex. What's the goal
> of ReadWriteLock? I mean - when should I use it rather than
> monitor / mutex? What practical advantage would it have?
>
> Best, Jan
>
>
> On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote:
>> Hi.
>>
>> I implemented small package ReadWriteLock http://smalltalkhub.com/mc/
>> Pharo/ReadWriteLock/main.
>>
>> Gofer it
>>   smalltalkhubUser: 'Pharo' project: 'ReadWriteLock';
>>   configurationOf: 'ReadWriteLock';
>>   loadStable
>>
>> It is reentral read write lock which described in
>> https://en.wikipedia.org/wiki/Readers–writer_lock. From the article:
>>
>> > An ReadWriteLock allows concurrent access for read-only operations,
>> > while write operations require exclusive access. This means that
>> > multiple threads can read the data in parallel but an exclusive
>> > lock is needed for writing or modifying data. When a writer is
>> > writing the data, all other writers or readers will be blocked
>> > until the writer is finished writing.
>> Public API and Key Messages
>>
>> - lock := ReadWriteLock new
>> - lock criticalRead: aBlock
>> - lock criticalWrite: aBlock
>>
>> Implementation based on two semaphores and readers counter.
>>
>> Main difficulty is carefully handle process termination during
>> execution of critical sections. This problem described in
>> Semaphore>>critical: comment. Same approach is used here. But
>> synchronisation logic around two semaphores for reading and writing
>> complicates things very much. No simple way to decompose logic on
>> multiple methods because information about process interruption
>> become hidden.
>> From the Semaphore comment:
>> > The main trick is assignment right before we go into the wait
>> > primitive (which is not a real send and therefore not interruptable
>> > either). So after we can check that waiting is happen or not.
>> Tests are implemented only for lock scenarios. No tests for described
>> termination process cases. It is not really clear how to write it.
>> I will be appreciate if people review code. Maybe you will suggest
>> simplifications. It is always difficult to implement concurrent
>> code.
>>
>> Best regards,
>> Denis
>

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Ben Coman]

> Le 12/1/16 17:58, Denis Kudriashov a écrit :
>
> Hi
>
> UFFI reminds me UFO which can be translated like Unified Foreign Objects.
> And objects outside image look really like unidentified flying objects. It's 
> just address, blob of bytes and they fly outside smalltalk world
> And it has some relation to Alien name.
> But maybe it is too much funny name

I guess we are considering...

Prefix: UFO   (shorter)
Package: Unified Foreign Objects(longer)

Prefix: UFFI   (longer)
Package: UnifiedFFI(shorter)

I like your thinking, but I have mixed feelings.  Name is cool.  The
shorter prefix may be a benefit (though the "I" doesn't add much).
But it implies more semantics as an external "object" than external
blobs of memory (for example) for C libraries.
I like "Unified" because it brings together parts of several
implementations (if I understand correctly) and fixes a point of
divergence at the VM level making it harder for limited resources to
collaborate there.
So in the end I think I prefer Unified.

cheers -ben

P.S.  As I understand it, NativeBoost performs a bit better than
UnifiedFFI, but it hindered cross-architecture compatibility - but
UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if
its technically feasible for NativeBoost to become a plug-in backend
for UnifiedFFI, that could be used is special circumstances that
super-performance is required only on supported platforms?



>
> 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano :
>>
>> Hi,
>>
>> People has pointed (and they are right) that the name of the new FFI
>> front-end is misleading.
>> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for
>> short) is a better name… and to keep packages prox. to regular FFI I was
>> thinking on rename FFI-NB packages to FFI-Unified… but maybe is better just
>> to rename them as UFFI or UnifiedFFI…
>> what do you think?
>>
>> Esteban
>>
>>
>
>

Re: [Pharo-dev] .filetree file?

[Mariano Martinez Peck]

Hi Alex,

I was wondering the same just minutes ago. I wonder if GitFileTree could do
this for us?



On Sun, Jul 5, 2015 at 7:03 PM, Alexandre Bergel 
wrote:

> Ok, thanks!
>
> Alexandre
>
>
> > On Jul 6, 2015, at 12:02 AM, Sven Van Caekenberghe  wrote:
> >
> >
> >> On 05 Jul 2015, at 23:57, Alexandre Bergel 
> wrote:
> >>
> >> Hi!
> >>
> >> When using Filetree, there is this file .filetree in the git folder.
> >> What should I do with it? add it to the repository or ignore it?
> >
> > You have to add it. It contains meta information.
> >
> >> cheers,
> >> Alexandre
> >> --
> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> Alexandre Bergel  http://www.bergel.eu
> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >>
> >>
> >>
> >>
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] [Ann] ReadWriteLock

[Denis Kudriashov]

Hi.
I am going to bed now. Do you look at wikipedia link?
12 янв. 2016 г. 11:29 PM пользователь "Jan Vrany" 
написал:

> Hi Denis, all,
>
> I'm sorry for asking basic questions, but...
>
> I thought of this a little and I failed to see the advantage
> of using ReadWriteLock over monitor / mutex. What's the goal
> of ReadWriteLock? I mean - when should I use it rather than
> monitor / mutex? What practical advantage would it have?
>
> Best, Jan
>
>
> On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote:
> > Hi.
> >
> > I implemented small package ReadWriteLock http://smalltalkhub.com/mc/
> > Pharo/ReadWriteLock/main.
> >
> > Gofer it
> >   smalltalkhubUser: 'Pharo' project: 'ReadWriteLock';
> >   configurationOf: 'ReadWriteLock';
> >   loadStable
> >
> > It is reentral read write lock which described in
> > https://en.wikipedia.org/wiki/Readers–writer_lock. From the article:
> >
> > > An ReadWriteLock allows concurrent access for read-only operations,
> > > while write operations require exclusive access. This means that
> > > multiple threads can read the data in parallel but an exclusive
> > > lock is needed for writing or modifying data. When a writer is
> > > writing the data, all other writers or readers will be blocked
> > > until the writer is finished writing.
> > Public API and Key Messages
> >
> > - lock := ReadWriteLock new
> > - lock criticalRead: aBlock
> > - lock criticalWrite: aBlock
> >
> > Implementation based on two semaphores and readers counter.
> >
> > Main difficulty is carefully handle process termination during
> > execution of critical sections. This problem described in
> > Semaphore>>critical: comment. Same approach is used here. But
> > synchronisation logic around two semaphores for reading and writing
> > complicates things very much. No simple way to decompose logic on
> > multiple methods because information about process interruption
> > become hidden.
> > From the Semaphore comment:
> > > The main trick is assignment right before we go into the wait
> > > primitive (which is not a real send and therefore not interruptable
> > > either). So after we can check that waiting is happen or not.
> > Tests are implemented only for lock scenarios. No tests for described
> > termination process cases. It is not really clear how to write it.
> > I will be appreciate if people review code. Maybe you will suggest
> > simplifications. It is always difficult to implement concurrent
> > code.
> >
> > Best regards,
> > Denis
>
>

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

[Esteban Lorenzano]

no, I’m quite sure they are bugs :)

I also believe the other tools do not have accept/cancel visible (they are in 
contextual menus), so maybe they should be there.

Esteban

> On 12 Jan 2016, at 23:24, Nicolai Hess  wrote:
> 
> 
> 
> 2016-01-08 11:24 GMT+01:00 Tudor Girba  >:
> Hi,
> 
> We are about to integrate in Pharo a new member of the Glamorous Toolkit: the 
> GTDebugger. As this is a significant change that might affect your workflow, 
> here is some background information to help you deal with the change.
> 
> First, you should know that the change is not irreversible and it is easily 
> possible to disabled the new debugger through a setting. However, please do 
> take the time to provide us feedback if something does not work out for you. 
> We want to know what can be improved and we try to react as fast as we can.
> 
> A practical change comes from the fact that the variables are manipulated 
> through a GTInspector, which makes it cheaper to maintain in the longer run.
> 
> Accept and Cancel buttons shouldn't be there
> or should not act on if the codepane hasn't changed.
> (every press on "accept" writes a new method version, although the contents 
> didn't changed - tested on
> Latest update: #50524 )
> 
> Most (all?) other tools don't have Accept/Cancel buttons.
> 
> - I really miss the "List Methods using 'varname'/List Methods storing into 
> 'varname'
> - is "stackTop" now gone ? I thought you wanted to add it to the stack ?
> - thisContext is gone as well ?
> - the Bytecode/GT button is badly placed, it looks like the "downarrow" 
> window menu icon
>   is a dropdown menu with label "Bytecode" (since when do we put buttons in 
> the title pane?
> - the evaluator pane is shown as "dirty", as it does not make a difference if 
> we
>   accept the text in this pane, there shouldn't be a dirty indicator.
> - you can not use the inspector pane to change inst var values
> - there is no way to refresh the inspector pane
> 
> I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs 
> but 
> features.
> 
> 
> nicolai
> 
>  

Re: [Pharo-dev] [Ann] ReadWriteLock

[Jan Vrany]

Hi Denis, all, 

I'm sorry for asking basic questions, but...

I thought of this a little and I failed to see the advantage 
of using ReadWriteLock over monitor / mutex. What's the goal
of ReadWriteLock? I mean - when should I use it rather than 
monitor / mutex? What practical advantage would it have? 

Best, Jan


On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote:
> Hi.
> 
> I implemented small package ReadWriteLock http://smalltalkhub.com/mc/
> Pharo/ReadWriteLock/main.
> 
> Gofer it 
>   smalltalkhubUser: 'Pharo' project: 'ReadWriteLock';
>   configurationOf: 'ReadWriteLock';
>   loadStable
> 
> It is reentral read write lock which described in 
> https://en.wikipedia.org/wiki/Readers–writer_lock. From the article:
> 
> > An ReadWriteLock allows concurrent access for read-only operations,
> > while write operations require exclusive access. This means that
> > multiple threads can read the data in parallel but an exclusive
> > lock is needed for writing or modifying data. When a writer is
> > writing the data, all other writers or readers will be blocked
> > until the writer is finished writing.
> Public API and Key Messages
> 
> - lock := ReadWriteLock new
> - lock criticalRead: aBlock
> - lock criticalWrite: aBlock
> 
> Implementation based on two semaphores and readers counter. 
> 
> Main difficulty is carefully handle process termination during
> execution of critical sections. This problem described in
> Semaphore>>critical: comment. Same approach is used here. But
> synchronisation logic around two semaphores for reading and writing
> complicates things very much. No simple way to decompose logic on
> multiple methods because information about process interruption
> become hidden.
> From the Semaphore comment:
> > The main trick is assignment right before we go into the wait
> > primitive (which is not a real send and therefore not interruptable
> > either). So after we can check that waiting is happen or not.
> Tests are implemented only for lock scenarios. No tests for described
> termination process cases. It is not really clear how to write it.  
> I will be appreciate if people review code. Maybe you will suggest
> simplifications. It is always difficult to implement concurrent
> code. 
> 
> Best regards,
> Denis

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

[Nicolai Hess]

2016-01-08 11:24 GMT+01:00 Tudor Girba :

> Hi,
>
> We are about to integrate in Pharo a new member of the Glamorous Toolkit:
> the GTDebugger. As this is a significant change that might affect your
> workflow, here is some background information to help you deal with the
> change.
>
> First, you should know that the change is not irreversible and it is
> easily possible to disabled the new debugger through a setting. However,
> please do take the time to provide us feedback if something does not work
> out for you. We want to know what can be improved and we try to react as
> fast as we can.
>
> A practical change comes from the fact that the variables are manipulated
> through a GTInspector, which makes it cheaper to maintain in the longer run.
>

Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the contents
didn't changed - tested on
Latest update: #50524 )

Most (all?) other tools don't have Accept/Cancel buttons.

- I really miss the "List Methods using 'varname'/List Methods storing into
'varname'
- is "stackTop" now gone ? I thought you wanted to add it to the stack ?
- thisContext is gone as well ?
- the Bytecode/GT button is badly placed, it looks like the "downarrow"
window menu icon
  is a dropdown menu with label "Bytecode" (since when do we put buttons in
the title pane?
- the evaluator pane is shown as "dirty", as it does not make a difference
if we
  accept the text in this pane, there shouldn't be a dirty indicator.
- you can not use the inspector pane to change inst var values
- there is no way to refresh the inspector pane

I don't open bugtracker entries now, I 'll wait maybe this issues aren't
bugs but
features.


nicolai

[Pharo-dev] [pharo-project/pharo-core] c496dd: 50524

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: c496dd7263104cfd1ba78ed2098194f9ac989b2e
  
https://github.com/pharo-project/pharo-core/commit/c496dd7263104cfd1ba78ed2098194f9ac989b2e
  Author: Jenkins Build Server 
  Date:   2016-01-12 (Tue, 12 Jan 2016)

  Changed paths:
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/README.md
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/accessing/project.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/development
 support/DevelopmentSupport.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/development
 support/validate.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/loading/load.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/loading/loadBleedingEdge.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/loading/loadDevelopment.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/metacello
 tool support/isMetacelloConfig.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/private/baseConfigurationClassIfAbsent_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/private/ensureMetacello.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/class/private/ensureMetacelloBaseConfiguration.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/definition.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/accessing/customProjectAttributes.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/accessing/project.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/baselines/baseline01_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/baselines/baseline02_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/baselines/baseline03_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/baselines/baseline04_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/baselines/baseline05_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic
 versions/development_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version100_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version101_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version11_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version12_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version13_.st
M 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version04_.st
A 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version05_.st
A 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version06_.st
A 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version07_.st
M 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version23_.st
A 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version24_.st
A 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version25_.st
M 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version24_.st
A 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version25_.st
A 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version26_.st
M 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version15_.st
A 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version16_.st
A 
ConfigurationOfGTSpotter.package/

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

[GitHub]

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

Re: [Pharo-dev] How to get launcher launching Spur images?

[Stephan Eggermont]

On 12-01-16 15:23, Ben Coman wrote:

On Tue, Jan 12, 2016 at 10:03 PM, stepharo  wrote:

I loaded the stable version in Pharo 50 and I saw that it does not have the
Spur special Folder.
So I loaded the latest version of the packages from the repo and I could not
run the launcher anymore.

So could you tell me how you did it?


Err, umm...  looking just now I see only one settable VM path.  So it
seems I did not load the latest, only the version from the Catalog.
So I guess I can only run Spur images.


That is likely. If you load a newer version you get the second path. I 
didn't try, but that should allow you to run both also from a spur 
launcher. In version 84 there is a change in the way the launcher is 
started, that might be incompatible with OS-X?


Stephan

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Esteban A. Maringolo]

2016-01-12 16:49 GMT-03:00 stepharo :

>
>
> Le 12/1/16 17:58, Denis Kudriashov a écrit :
>
> Hi
>
> UFFI reminds me UFO which can be translated like Unified Foreign Objects.
> And it has some relation to Alien name.
> But maybe it is too much funny name
>
>
> Quite cool :)
>


+1

UFFI is concise too.


Esteban A. Maringolo

Re: [Pharo-dev] Bad layoutFrame>>#hash

[stepharo]

Hi david

I rad the wikipedia page you mention and this looks a bit obvious to me. 
I knew this.

now it does not really help fixing the problem you mention.

Stef

Le 11/1/16 10:09, David Allouche a écrit :

Since it's not obvious why xor-ing is a bad way to produce hash, here is a link 
that gives some background

https://en.wikipedia.org/wiki/Hash_function#Uniformity


On 11 Jan 2016, at 10:01, David Allouche  wrote:

I happened to look at the new code for LayoutFrame>>#hash

hash
^self species hash bitXor:
(self leftFraction bitXor:
(self leftOffset bitXor:
(self topFraction bitXor:
(self topOffset bitXor:
(self rightFraction bitXor:
(self rightOffset bitXor:
(self bottomFraction bitXor:
self bottomOffset)))

This is a terrible, terrible way to compute a hash.

0 xor 0 = 1 xor 1 = 2 xor 2 = etc.

NEVER compute hashes with xor, that's wrong, and it causes horrible, hard to 
debug, performance bugs down the road.

SequenceableCollection>>#hash looks more like a correct way of doing it. I do not 
know what is the correct, efficient way to reuse this logic in LayoutFrame>>#hash.

By the way, how do you guys do code reviews for code integrated into the core?

Re: [Pharo-dev] Bad layoutFrame>>#hash

[stepharo]

Ok but be concrete. What will be the solution for this particular case?

Stef

Le 11/1/16 22:30, Nicolas Cellier a écrit :

Yep, a must read if you want to improve the hash methods.

2016-01-11 10:09 GMT+01:00 Sven Van Caekenberghe >:


David,

> On 11 Jan 2016, at 10:01, David Allouche mailto:da...@allouche.net>> wrote:
>
> I happened to look at the new code for LayoutFrame>>#hash
>
> hash
>   ^self species hash bitXor:
>   (self leftFraction bitXor:
>   (self leftOffset bitXor:
>   (self topFraction bitXor:
>   (self topOffset bitXor:
>   (self rightFraction bitXor:
>   (self rightOffset bitXor:
>   (self bottomFraction bitXor:
>   self bottomOffset)))
>
> This is a terrible, terrible way to compute a hash.
>
> 0 xor 0 = 1 xor 1 = 2 xor 2 = etc.
>
> NEVER compute hashes with xor, that's wrong, and it causes
horrible, hard to debug, performance bugs down the road.

Yeah, that doesn't look very good ;-)

> SequenceableCollection>>#hash looks more like a correct way of
doing it. I do not know what is the correct, efficient way to
reuse this logic in LayoutFrame>>#hash.

There is actually a 2 part book just about hashing in Smalltalk:


http://www.lulu.com/shop/andres-valloud/hashing-in-smalltalk-theory-and-practice/paperback/product-3788892.html

It is said to be very good, I sadly have not yet read it ;-)

> By the way, how do you guys do code reviews for code integrated
into the core?

'Pharo is yours' which means: if you encounter something odd, you
are encouraged to improve it. Maybe first discuss it on the ML. If
necessary create an issue. Better provide a fix.

Sven

Re: [Pharo-dev] Bad layoutFrame>>#hash

[stepharo]

You see K. Beck in his book smalltalk best pratices promotes this form.
So can you propose a better solution so that we learn?

Stef

Le 11/1/16 10:09, David Allouche a écrit :

Since it's not obvious why xor-ing is a bad way to produce hash, here is a link 
that gives some background

https://en.wikipedia.org/wiki/Hash_function#Uniformity


On 11 Jan 2016, at 10:01, David Allouche  wrote:

I happened to look at the new code for LayoutFrame>>#hash

hash
^self species hash bitXor:
(self leftFraction bitXor:
(self leftOffset bitXor:
(self topFraction bitXor:
(self topOffset bitXor:
(self rightFraction bitXor:
(self rightOffset bitXor:
(self bottomFraction bitXor:
self bottomOffset)))

This is a terrible, terrible way to compute a hash.

0 xor 0 = 1 xor 1 = 2 xor 2 = etc.

NEVER compute hashes with xor, that's wrong, and it causes horrible, hard to 
debug, performance bugs down the road.

SequenceableCollection>>#hash looks more like a correct way of doing it. I do not 
know what is the correct, efficient way to reuse this logic in LayoutFrame>>#hash.

By the way, how do you guys do code reviews for code integrated into the core?

Re: [Pharo-dev] ifError: implementation is bad

[stepharo]

+^111


We should make a list. Some that should be easy:

- Delay should be splitted

why?


- Chronology should be splitted

One more complicated:

- InstructionClient and InstructionStream should be splitted

And then, we should also review the API of basic objects

Object methods size => 385
Integer methods size => 182
...

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Dimitris Chloupis]

Ah I forgot the name UFFI is also used by the Common Lisp

http://www.cliki.net/UFFI

On Tue, Jan 12, 2016 at 9:50 PM stepharo  wrote:

>
>
> Le 12/1/16 17:58, Denis Kudriashov a écrit :
>
> Hi
>
> UFFI reminds me UFO which can be translated like Unified Foreign Objects.
> And it has some relation to Alien name.
> But maybe it is too much funny name
>
>
> Quite cool :)
>
> Stef
>
>
>
> 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano :
>
>> Hi,
>>
>> People has pointed (and they are right) that the name of the new FFI
>> front-end is misleading.
>> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI,
>> for short) is a better name… and to keep packages prox. to regular FFI I
>> was thinking on rename FFI-NB packages to FFI-Unified… but maybe is better
>> just to rename them as UFFI or UnifiedFFI…
>> what do you think?
>>
>> Esteban
>>
>>
>>
>
>

Re: [Pharo-dev] How to get launcher launching Spur images?

[stepharo]

ok I will retry.

Le 12/1/16 15:23, Ben Coman a écrit :

On Tue, Jan 12, 2016 at 10:03 PM, stepharo  wrote:

I loaded the stable version in Pharo 50 and I saw that it does not have the
Spur special Folder.
So I loaded the latest version of the packages from the repo and I could not
run the launcher anymore.

So could you tell me how you did it?

Err, umm...  looking just now I see only one settable VM path.  So it
seems I did not load the latest, only the version from the Catalog.
So I guess I can only run Spur images.

cheers -ben


Stef

Le 11/1/16 16:48, stepharo a écrit :

Ok I will do the same then ;)


Le 11/1/16 13:09, Ben Coman a écrit :


On Mon, Jan 11, 2016 at 1:49 AM, stepharo  wrote:

Hi

I changed the setting to be the following but I cannot get a spur image
started on mac.
Does anybody succeed?

Stef


I cheated and started with latest Pharo 5 Spur and installed PharoLauncher
from the Catalog Browser.
(I should soon try an image with old vm)
cheers -ben

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[stepharo]

Le 12/1/16 17:58, Denis Kudriashov a écrit :

Hi

UFFI reminds me UFO which can be translated like Unified Foreign 
Objects. And it has some relation to Alien name.

But maybe it is too much funny name


Quite cool :)

Stef



2016-01-12 16:55 GMT+01:00 Esteban Lorenzano >:


Hi,

People has pointed (and they are right) that the name of the new
FFI front-end is misleading.
So yesterday I was talking with Stef and we think UnifiedFFI (or
UFFI, for short) is a better name… and to keep packages prox. to
regular FFI I was thinking on rename FFI-NB packages to
FFI-Unified… but maybe is better just to rename them as UFFI or
UnifiedFFI…
what do you think?

Esteban

[Pharo-dev] Job offer

[stepharo]

Begin forwarded message:

From: Georg Heeg 
Subject: [Esug-list] Looking for Smalltalkers
Date: 12 Jan 2016 17:57:27 GMT+1
To: ESUG Mailing list 

A customer of ours is looking for two Smalltalkers starting not later as 
July 1st, 2016, unlimited work contracts.


Please contact me for details

Georg Heeg


Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812
Baroper Str. 337, 44227 Dortmund, Germany
Tel. +49-3496-214328, Fax +49-231-97599-20



___
Esug-list mailing list
esug-l...@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Re: [Pharo-dev] Redirect bug in Zinc in the recent Pharo 5 images

[Sven Van Caekenberghe]

> On 12 Jan 2016, at 15:05, Sven Van Caekenberghe  wrote:
> 
> Hi Monty,
> 
> Thanks for reporting this issue.
> 
> The problem is that Zn requests 
> http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd using Host: 
> www.oasis-open.org:80 (so with an explicit port) and apparently this server 
> cannot directly deal with that and redirects to the same URL (but without the 
> port) and Zn then does the same thing: ergo, an infinite loop.
> 
> This was probably introduced a while ago when support for HTTPS Connect 
> proxying was added. It will take me a little while to get into why it was 
> added and if/how it can be avoided. 

I committed the following in #bleedingEdge:

===
Name: Zinc-HTTP-SvenVanCaekenberghe.444
Author: SvenVanCaekenberghe
Time: 12 January 2016, 8:31:50.516464 pm
UUID: 231767b6-088c-462b-8c1d-dbcdc9eb5198
Ancestors: Zinc-HTTP-SvenVanCaekenberghe.443

Revert the decision to use #authorityWithPort instead of #authority in 
ZnHeaders>>#request:

A bug reported by Monty shows that some servers are sensitive to the default 
port being added

Another reading of the specs seems to indicate that the default port (80 or 
433) is really not needed (but not forbidden either)

This might interfere with HTTPS proxying using HTTP CONNECT tunneling but that 
is very hard to test (see Zinc-HTTP-SvenVanCaekenberghe.437)
===

All tests remain green and your request now succeeds.

But like I said, it is hard to test the proxying, let's hope I didn't break 
anything.

> In any case, this is the first server that causes this ;-)
> 
> Sven
> 
>> On 12 Jan 2016, at 07:00, monty  wrote:
>> 
>> When you try to retrieve this URL with recent Zinc versions, you get a max 
>> number of redirects exceeded error:
>> 
>> http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd
>> 
>> This is causing an XMLParser test to fail. But you can retrieve the URL fine 
>> in older images (with older versions of Zinc). I tried changing the max 
>> number of redirects to something higher, to no avail. Even when allowing 
>> hundreds of redirects, I still get the error.
>> 
> 

Re: [Pharo-dev] happy lessons from recent talks

[Richard Sargent]

Tudor Girba-2 wrote
> Hi,
> 
> I just wanted to share with you a bit of a different perspective on what
> we do around here.
> 
> Over the past half a year I gave several talks to some 1k technical people
> at industrial events like ArchConf, NDC Oslo and several others. The tour
> will continue this year at OOP, ArchConf and a couple of other places.
> These are places where people talk about mainstream techniques &
> technologies (like Java, JS, C#). For example, ArchConf is a premier
> software architecture conference in the US.
> 
> During these sessions, people get to experience Moose and Pharo through
> live demos. I use these demos as examples of how humane assessment
> (building your own analysis tools) can boost engineering decisions making
> in practice.
> 
> I consistently receive the feedback that the live programming
> possibilities from Pharo/Moose are impressive. But, more recently, there
> is something else worthy of being noted. If in previous years, nobody
> heard about what we do, this year I started to get consistently a couple
> of persons in the room that have heard something about Pharo/Moose before
> the presentation.

Excellent!


> This is huge. While a couple might not sound like much, you should
> remember that information (especially in this technical space) has the
> capability of spreading exponentially. What we have done over the past
> years starts to show results. We have to keep it up.
> 
> Happy New Year!
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving should be focused on describing
> the problem in a way that makes the solution obvious."





--
View this message in context: 
http://forum.world.st/happy-lessons-from-recent-talks-tp4870566p4870941.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Dimitris Chloupis]

Why not "Pharo FFI" ? since it will be the official FFI of Pharo. I also
like like lighthouse references like "LightSpeed"  , "LightForce" ,
"LightWave" , "Lighting", "LightHouse" etc.

On Tue, Jan 12, 2016 at 5:57 PM Esteban Lorenzano 
wrote:

> Hi,
>
> People has pointed (and they are right) that the name of the new FFI
> front-end is misleading.
> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for
> short) is a better name… and to keep packages prox. to regular FFI I was
> thinking on rename FFI-NB packages to FFI-Unified… but maybe is better just
> to rename them as UFFI or UnifiedFFI…
> what do you think?
>
> Esteban
>
>
>

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Torsten Bergmann]

Esteban Lorenzano wrote:
> People has pointed (and they are right) that the name of the new FFI 
> front-end is misleading. 

"People" means more than just a single person (me). Glad that I'm not the only 
one who lamented ;)

> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for 
> short) is a 
>better name… and to keep packages prox. to regular FFI I was thinking on 
>rename FFI-NB 
>packages to FFI-Unified… but maybe is better just to rename them as UFFI or 
>UnifiedFFI… 
> what do you think?

+1

Given that we already have abbreviations in "NB" and "FFI" it's not a problem 
to go
for "UFFI". But "UnifiedFFI" would be fine as well.


Damien Pollet
>UniFFIed ?

Would be funny, but given that some people already have a problem with 
"SmallTalk" 
vs. "Smalltalk" I would not use it.

Thanks
T.

<< THE HARDEST PART IN PROGRAMMING IS FINDING PROPER NAMES >>

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Damien Pollet]

UniFFIed ?

On 12 January 2016 at 17:40, Max Leske  wrote:

> In order of preference:
>
> 1. UnifiedFFI
> 2. FFI-Unified (suggests that there may be multiple FFI implementations)
> 3. UFFI (not clear to me that this is an FFI)
>
> Cheers,
> Max
>
> > On 12 Jan 2016, at 16:55, Esteban Lorenzano  wrote:
> >
> > Hi,
> >
> > People has pointed (and they are right) that the name of the new FFI
> front-end is misleading.
> > So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI,
> for short) is a better name… and to keep packages prox. to regular FFI I
> was thinking on rename FFI-NB packages to FFI-Unified… but maybe is better
> just to rename them as UFFI or UnifiedFFI…
> > what do you think?
> >
> > Esteban
> >
> >
>
>
>


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 980d4d: 50523

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 980d4dfa986e3db8067a7ffc1f4a7b43f6454f91
  
https://github.com/pharo-project/pharo-core/commit/980d4dfa986e3db8067a7ffc1f4a7b43f6454f91
  Author: Jenkins Build Server 
  Date:   2016-01-12 (Tue, 12 Jan 2016)

  Changed paths:
M 
ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version082_.st
M 
Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/calculateChildren.st
A 
Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/getChildren.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTree1.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTree2.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTreeWithAllItemsFilter.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTreeWithAllItemsSearch.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTreeWithRootFilter.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTreeWithRootSearch.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTreeWithVisibleItemsFilter.st
M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree 
examples/exampleTreeWithVisibleItemsSearch.st
A 
Morphic-Widgets-FastTable.package/FTFunction.class/instance/protocol/disable.st
A 
Morphic-Widgets-FastTable.package/FTFunctionWithField.class/instance/protocol/disable.st
A 
Morphic-Widgets-FastTable.package/FTNilFunction.class/instance/protocol/disable.st
M 
Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/drawOn_.st
M 
Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/disableFunction.st
M 
Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/geometry/extent_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50522.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50523.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50522.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50523.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A SmartSuggestions.package/SugsGlamourCodeContext.class/README.md
A SmartSuggestions.package/SugsGlamourCodeContext.class/definition.st
A 
SmartSuggestions.package/SugsGlamourCodeContext.class/instance/refactoring/sourceTextArea.st
A 
SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedClass.st
A 
SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedMethod.st
A 
SmartSuggestions.package/extension/GLMRubricSmalltalkTextModel/instance/sugsContext.st
R 
System-BasicCommandLineHandler.package/BasicCommandLineHandler.class/class/accessing/helpDescription.st
R 
System-BasicCommandLineHandler.package/BasicCommandLineHandler.class/instance/printing/printHelp.st
R Tools-Test.package/DebuggerTest.class/README.md
R Tools-Test.package/DebuggerTest.class/definition.st
R Tools-Test.package/DebuggerTest.class/instance/testing/testBasic.st
A Tools-Test.package/SpecDebuggerTest.class/README.md
A Tools-Test.package/SpecDebuggerTest.class/definition.st
A Tools-Test.package/SpecDebuggerTest.class/instance/testing/testBasic.st

  Log Message:
  ---
  50523
17355 Rename DebuggerTest to SpecDebuggerTest
https://pharo.fogbugz.com/f/cases/17355

17372 New ConfigurationOfFastTable (see description for details)
https://pharo.fogbugz.com/f/cases/17372

17378 Improve command line handler documentation and help
https://pharo.fogbugz.com/f/cases/17378

17146 Suggestions in the playground--> Error
https://pharo.fogbugz.com/f/cases/17146

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

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Thierry Goubier]

2016-01-12 18:08 GMT+01:00 Denis Kudriashov :

>
> 2016-01-12 17:58 GMT+01:00 Denis Kudriashov :
>
>> UFFI reminds me UFO which can be translated like Unified Foreign Objects.
>> And it has some relation to Alien name.
>
>
> And objects outside image look really like unidentified flying objects.
> It's just address, blob of bytes and they fly outside smalltalk world
>

:)

Let's go outside and watch in the starry night UFFI objects !

Thierry

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Denis Kudriashov]

2016-01-12 17:58 GMT+01:00 Denis Kudriashov :

> UFFI reminds me UFO which can be translated like Unified Foreign Objects.
> And it has some relation to Alien name.


And objects outside image look really like unidentified flying objects.
It's just address, blob of bytes and they fly outside smalltalk world

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Denis Kudriashov]

Hi

UFFI reminds me UFO which can be translated like Unified Foreign Objects.
And it has some relation to Alien name.
But maybe it is too much funny name

2016-01-12 16:55 GMT+01:00 Esteban Lorenzano :

> Hi,
>
> People has pointed (and they are right) that the name of the new FFI
> front-end is misleading.
> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for
> short) is a better name… and to keep packages prox. to regular FFI I was
> thinking on rename FFI-NB packages to FFI-Unified… but maybe is better just
> to rename them as UFFI or UnifiedFFI…
> what do you think?
>
> Esteban
>
>
>

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Max Leske]

In order of preference:

1. UnifiedFFI
2. FFI-Unified (suggests that there may be multiple FFI implementations)
3. UFFI (not clear to me that this is an FFI)

Cheers,
Max

> On 12 Jan 2016, at 16:55, Esteban Lorenzano  wrote:
> 
> Hi,
> 
> People has pointed (and they are right) that the name of the new FFI 
> front-end is misleading. 
> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for 
> short) is a better name… and to keep packages prox. to regular FFI I was 
> thinking on rename FFI-NB packages to FFI-Unified… but maybe is better just 
> to rename them as UFFI or UnifiedFFI… 
> what do you think?
> 
> Esteban
> 
> 

[Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Esteban Lorenzano]

Hi,

People has pointed (and they are right) that the name of the new FFI front-end 
is misleading. 
So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for 
short) is a better name… and to keep packages prox. to regular FFI I was 
thinking on rename FFI-NB packages to FFI-Unified… but maybe is better just to 
rename them as UFFI or UnifiedFFI… 
what do you think?

Esteban

Re: [Pharo-dev] [Moose-dev] Re: [Survey] Forking Operating System Proces in Pharo

[Dimitris Chloupis]

Done ! I am very excited about this project. There a lot of gui apps that
offer an interface via command line and I am interested into running Pharo
on multiple cores.
On Tue, 12 Jan 2016 at 17:21, Mariano Martinez Peck 
wrote:

> Dear all,
>
> This is a simple reminder in case someone missed it.
>
> I also wanted to thank everybody that already took the time for filling
> it! Very much appreciated.
>
>
>
> On Sat, Jan 2, 2016 at 10:44 AM, Mariano Martinez Peck <
> marianop...@gmail.com> wrote:
>
>> Dear all,
>>
>> As I mentioned in the thread "Pharo Consortium Sponsored Development
>> Effort" [1] I built a survey about Forking Operating System Processes in
>> Pharo.
>>
>> The idea of the survey is simple: I want to understand what people needs
>> the most, which features would be useful, which ones would not, what is
>> missing, what is wrong, etc etc etc. As always, since we have limited
>> resources, we should optimize them as much as possible.
>>
>> I count with you so that we can make a roadmap together on this project.
>> Please, feel free to forward this survey anywhere where there could be an
>> interest.
>>
>> https://www.surveymonkey.com/r/DHR22TL
>>
>> Best regards,
>>
>> [1]
>> http://forum.world.st/ANN-Pharo-Consortium-Sponsored-Development-Effort-td4867926.html
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

Re: [Pharo-dev] [Survey] Forking Operating System Proces in Pharo

[Mariano Martinez Peck]

Dear all,

This is a simple reminder in case someone missed it.

I also wanted to thank everybody that already took the time for filling it!
Very much appreciated.



On Sat, Jan 2, 2016 at 10:44 AM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

> Dear all,
>
> As I mentioned in the thread "Pharo Consortium Sponsored Development
> Effort" [1] I built a survey about Forking Operating System Processes in
> Pharo.
>
> The idea of the survey is simple: I want to understand what people needs
> the most, which features would be useful, which ones would not, what is
> missing, what is wrong, etc etc etc. As always, since we have limited
> resources, we should optimize them as much as possible.
>
> I count with you so that we can make a roadmap together on this project.
> Please, feel free to forward this survey anywhere where there could be an
> interest.
>
> https://www.surveymonkey.com/r/DHR22TL
>
> Best regards,
>
> [1]
> http://forum.world.st/ANN-Pharo-Consortium-Sponsored-Development-Effort-td4867926.html
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] How to get launcher launching Spur images?

[Ben Coman]

On Tue, Jan 12, 2016 at 10:03 PM, stepharo  wrote:
> I loaded the stable version in Pharo 50 and I saw that it does not have the
> Spur special Folder.
> So I loaded the latest version of the packages from the repo and I could not
> run the launcher anymore.
>
> So could you tell me how you did it?

Err, umm...  looking just now I see only one settable VM path.  So it
seems I did not load the latest, only the version from the Catalog.
So I guess I can only run Spur images.

cheers -ben

>
> Stef
>
> Le 11/1/16 16:48, stepharo a écrit :
>
> Ok I will do the same then ;)
>
>
> Le 11/1/16 13:09, Ben Coman a écrit :
>
>
> On Mon, Jan 11, 2016 at 1:49 AM, stepharo  wrote:
>>
>> Hi
>>
>> I changed the setting to be the following but I cannot get a spur image
>> started on mac.
>> Does anybody succeed?
>>
>> Stef
>>
>
> I cheated and started with latest Pharo 5 Spur and installed PharoLauncher
> from the Catalog Browser.
> (I should soon try an image with old vm)
> cheers -ben
>
>
>

Re: [Pharo-dev] Morphic Migrations gotchas, was Re: Better class comment version2

[Thierry Goubier]

2016-01-12 11:02 GMT+01:00 David Allouche :

> I wonder whether it would be worth reversing this change, to remove an
> unnecessary incompatibility with other dialects.
>
> But maybe there is no development activity outside of Pharo, that would
> justify making any effort to maintain compatibility. I do not know.
>
> Practicality beats purity, if cleaning up existing APIs means cutting out
> Pharo from a wider ecosystem, and introducing painful bitrot, it might not
> be worth the cost.
>

Hum.

That change induced a lot of pain because touching Rectangle is very
invasive (tend to crash the GUI), but I can't avoid thinking that places
creating those strange rectangles were in fact bugs.

For LayoutFrame, a simple refactoring when importing Morphic code would do
the trick.

In practice, a significant amount of code in Pharo 5 still creates wrong
rectangles. A specific package even added an API to Rectangle to be able to
do so.

Thierry


>
>
> On 11 Jan 2016, at 22:25, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
> And it probably won't be integrated in Squeak, because it's not worth the
> pain.
>
> The change was conducted without analyzing all the impacts, because it was
> probably not possible to analyze the huge code base.
> (though it would have been possible to instrument code and collect the
> sender stacks producing degenerated rectangles)
>
> The only motto was to make code more "pure".
> Generally, I tend to be wary...
>
> On the other hand, storing the offsets in a rectangle just because there
> are 4 edges is sort of hackish usage, so while at cleaning...
>
> 2016-01-11 9:42 GMT+01:00 Stephan Eggermont :
>
>> On 10-01-16 23:16, Thierry Goubier wrote:
>>
>>> Hi David,
>>>
>>> this is the bug with LayoutFrame>>#fractions:offsets: we were talking
>>> about relative to that class comment.
>>>
>>> In Pharo, Rectangles are constrained to have the smallest vertical value
>>> as the top, smallest horizontal value as the left, largest vertical
>>> value as bottom and largest horizontal value as right.
>>>
>>
>> Indeed. And there is no Morphic documentation at all that is aware of
>> that, as nearly all of it was written before we changed the behavior of
>> Rectangle in Pharo, and it is a change that is not done in Squeak. The
>> result is that nearly no old Morphic code will run unmodified in Pharo.
>>
>> I would like to collect a list of these gotchas, preferably with
>> solutions, to make it easier for people to update/migrate old morphic code.
>> Post them here, or mail them to me.
>>
>> Stephan
>>
>>
>>
>>
>>
>
>

Re: [Pharo-dev] Morphic Migrations gotchas, was Re: Better class comment version2

[Ben Coman]

On Tue, Jan 12, 2016 at 6:02 PM, David Allouche  wrote:
> I wonder whether it would be worth reversing this change, to remove an
> unnecessary incompatibility with other dialects.

Of course we should not introduce *unnecessary* incompatibilities, but
its be hard to judge the subtle dampening effect of compatibility on
innovation & API cleaning, against the benefits obtained from these.
So Pharo tends to favour the latter over the former.  Equally,
mistakes sometimes aren't apparent until later, so no "improvement"
should be treated as golden goose.  I'm not qualified to have an
opinion in this case, but I remember several people being quite
pleased with the change. You'd probably have to clearly identify other
benefits of reverting.  (Compatibility with existing Morphic examples
noted.)

> But maybe there is no development activity outside of Pharo, that would
> justify making any effort to maintain compatibility. I do not know.

> Practicality beats purity, if cleaning up existing APIs means cutting out
> Pharo from a wider ecosystem, and introducing painful bitrot, it might not
> be worth the cost.

You may find interesting the first three chapters...
https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf

cheers -ben

> On 11 Jan 2016, at 22:25, Nicolas Cellier
>  wrote:
>
> And it probably won't be integrated in Squeak, because it's not worth the
> pain.
>
> The change was conducted without analyzing all the impacts, because it was
> probably not possible to analyze the huge code base.
> (though it would have been possible to instrument code and collect the
> sender stacks producing degenerated rectangles)
>
> The only motto was to make code more "pure".
> Generally, I tend to be wary...
>
> On the other hand, storing the offsets in a rectangle just because there are
> 4 edges is sort of hackish usage, so while at cleaning...
>
> 2016-01-11 9:42 GMT+01:00 Stephan Eggermont :
>>
>> On 10-01-16 23:16, Thierry Goubier wrote:
>>>
>>> Hi David,
>>>
>>> this is the bug with LayoutFrame>>#fractions:offsets: we were talking
>>> about relative to that class comment.
>>>
>>> In Pharo, Rectangles are constrained to have the smallest vertical value
>>> as the top, smallest horizontal value as the left, largest vertical
>>> value as bottom and largest horizontal value as right.
>>
>>
>> Indeed. And there is no Morphic documentation at all that is aware of
>> that, as nearly all of it was written before we changed the behavior of
>> Rectangle in Pharo, and it is a change that is not done in Squeak. The
>> result is that nearly no old Morphic code will run unmodified in Pharo.
>>
>> I would like to collect a list of these gotchas, preferably with
>> solutions, to make it easier for people to update/migrate old morphic code.
>> Post them here, or mail them to me.
>>
>> Stephan
>>
>>
>>
>>
>
>

Re: [Pharo-dev] How to get launcher launching Spur images?

[stepharo]

I loaded the stable version in Pharo 50 and I saw that it does not have 
the Spur special Folder.
So I loaded the latest version of the packages from the repo and I could 
not run the launcher anymore.


So could you tell me how you did it?

Stef

Le 11/1/16 16:48, stepharo a écrit :

Ok I will do the same then ;)


Le 11/1/16 13:09, Ben Coman a écrit :


On Mon, Jan 11, 2016 at 1:49 AM, stepharo > wrote:


Hi

I changed the setting to be the following but I cannot get a spur
image started on mac.
Does anybody succeed?

Stef


I cheated and started with latest Pharo 5 Spur and installed 
PharoLauncher from the Catalog Browser.

(I should soon try an image with old vm)
cheers -ben

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Jan Vrany]

> Maybe it should only lock the threads that were _not_ started by the
> “test thread”? I’m not even sure that is possible,
> just suggesting things.
> 

Have a look at Niall Ross' XProc Patterns. They do the same by - AFAIK
- intercepting process creation and checking whether the creating
process is one of the "tests threads". 

HTH, Jan


> > On Jan 12, 2016, at 11:11 AM, Sven Van Caekenberghe 
> > wrote:
> > 
> > The coverage seems to be implemented by 'locking' the current
> > execution thread exclusively, which would mean no other threads can
> > run, at all. So code depending on multi threading, like
> > client/server code, like HTTP, cannot work. Yes that seems to be a
> > limitation, but an understandable one.
> > 
> > I am trying to help but I don't known anything about the coverage
> > tool, so maybe I should shut up ;-)
> > 
> > > On 12 Jan 2016, at 11:05, Skip Lentz  wrote:
> > > 
> > > You mean as in it can check the coverage effected by the code
> > > running in the other thread?
> > > Or is this not what you mean?
> > > 
> > > Well I mean, at least it can show the coverage done by what was
> > > run in the same thread..
> > > And it will at least not hang or fail.
> > > 
> > > > On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe  > > > eu> wrote:
> > > > 
> > > > I never used that, but it seems coverage can only deal with
> > > > single threaded code, which sounds logical. No ?
> > > > 
> > > > > On 12 Jan 2016, at 10:53, Skip Lentz 
> > > > > wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > When I want to run the coverage of for example Zinc’s Client
> > > > > and Server tests,
> > > > > it will either hang (in the case of Zinc’s test cases) or
> > > > > fail because the coverage
> > > > > uses BlockClosure>>valueUnpreemptively for running the tests.
> > > > > The relevant method is TestRunner>>collectCoverageFor:.
> > > > > 
> > > > > So when a test is run, it is not able to be preempted by
> > > > > another process, like for
> > > > > example a local server which is needed to run the actual test
> > > > > in Zinc’s case.
> > > > > 
> > > > > When I use BlockClosure>>valueUninterruptably it works. Can
> > > > > someone tell me
> > > > > if it is wrong to use that instead? Is valueUnpreemptively
> > > > > necessary in this case,
> > > > > and if so, why?
> > > > > 
> > > > > To reproduce: Load fresh image, select Zinc's ZnClientTests
> > > > > and ZnServerTests,
> > > > > click on “Run Coverage” -> hanging image.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Skip
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Sven Van Caekenberghe]

Ah yes, that is better, thanks!

> On 12 Jan 2016, at 11:54, Blondeau Vincent  
> wrote:
> 
> Agree.
> I open a bug: 
> https://pharo.fogbugz.com/f/cases/17378/Improve-command-line-handler-documentation-and-help
>  that improve the doc.
> I propose:
> Usage: 
> [--no-preferences|--preference-file=][--help|--list|--copyright|--version|--no-quit|
>  ]
>--help   print this help message
>--list   list a description of all active command line handlers
>--copyright  print the copyrights
>--versionprint the version for the image and the vm
>--no-quitkeep the image running without activating any other 
> command line handler
> a valid subcommand in --list
> --help show subcommand help
> 
> Vincent
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>> Sven Van Caekenberghe
>> Envoyé : mardi 12 janvier 2016 11:48
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>> 
>> No, I don't think so, it has a function.
>> 
>> Some people like to configure Pharo images so that they have a running
>> server inside them. In that case, starting your app is a simple as starting 
>> the
>> image, but you would probably need the --no-quit to prevent it from exiting
>> immediately.
>> 
>> (I personally don't like and never use that approach, but I know some people
>> like it).
>> 
>> The confusing aspect is that the same option is used in two places and the
>> first one annihilates the second. But that is documented:
>> 
>> prometheus:pharo5 sven$ ./pharo Pharo.image --help
>> Usage: [--no-preferences|--preference-file=][] [--
>> help] [--copyright] [--version] [--list] [ --no-quit ]
>>  --help   print this help message
>>  --copyright  print the copyrights
>>  --versionprint the version for the image and the vm
>>  --list   list a description of all active command line handlers
>>  --no-quitkeep the image running without activating any other
>> command line handler
>>   a valid subcommand in --list
>> 
>> Documentation:
>> A BasicCommandLineHandler handles default command line arguments and
>> options.
>> 
>> It clearly says "without activating any other command line handler". So using
>> --no-quit BEFORE the subcommand annihilates the subcommand (AFAIU).
>> 
>>> On 12 Jan 2016, at 11:28, Blondeau Vincent
>>  wrote:
>>> 
>>> So --no-quit should be removed from the default line handler?
>>> 
>>> Vincent
>>> 
 -Message d'origine-
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
 de Esteban Lorenzano Envoyé : mardi 12 janvier 2016 11:18 À : Pharo
 Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
 CentOS?
 
 But you cannot use it as a general command.
 If you use a subcommand (most likely) then you do not have it unless
 the subcommand defines it.
 
 Esteban
 
> On 12 Jan 2016, at 11:12, Blondeau Vincent
  wrote:
> 
> 
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
>> part de Sven Van Caekenberghe Envoyé : mardi 12 janvier 2016 10:57 À
>> :
>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works
>> on CentOS?
>> 
>> 
 On 12 Jan 2016, at 10:50, Esteban Lorenzano
>> 
>>> wrote:
>>> 
>>> 
>>> 
 On 12 Jan 2016, at 10:34, Sven Van Caekenberghe 
 wrote:
 
 
> On 12 Jan 2016, at 10:28, Blondeau Vincent
>>  wrote:
> 
> Indeed, it works. Thanks!
> 
> But the command line usage is not clear :
> ./pharo Pharo.image
> Usage: [--no-preferences|--preference-
>> file=][]
> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> 
> Maybe, it can be :
> Usage: [--no-preferences|--preference-
>> file=][]
> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> []
> 
> Moreover, an option can usually be placed anywhere on the
> command
>> line, shouldn't it? Or at least it should raise an error?
 
 Yes it is a bit confusion (but you could try to read/understand
 the Pharo code, it is not very difficult ;-)
 
 But the idea is that the sub-command controls its own options
 (like passing linker options via the compiler to the linker - git
 also has global and per sub command options, no ?)
 
 --no-quit probably also works for the default command ... (I
 haven't
>> looked), so at that point, the option is consumed already.
>>> 
>>> No, it doesn't :)
>> 
>> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version]
>> 5.0
>> #50510
>> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C
>> 
>> The last command 'hangs' (i.e. the imag

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Blondeau Vincent]

Agree.
I open a bug: 
https://pharo.fogbugz.com/f/cases/17378/Improve-command-line-handler-documentation-and-help
 that improve the doc.
I propose:
Usage: 
[--no-preferences|--preference-file=][--help|--list|--copyright|--version|--no-quit|
 ]
--help   print this help message
--list   list a description of all active command line handlers
--copyright  print the copyrights
--versionprint the version for the image and the vm
--no-quitkeep the image running without activating any other 
command line handler
 a valid subcommand in --list
 --help show subcommand help

Vincent

> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
> Sven Van Caekenberghe
> Envoyé : mardi 12 janvier 2016 11:48
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>
> No, I don't think so, it has a function.
>
> Some people like to configure Pharo images so that they have a running
> server inside them. In that case, starting your app is a simple as starting 
> the
> image, but you would probably need the --no-quit to prevent it from exiting
> immediately.
>
> (I personally don't like and never use that approach, but I know some people
> like it).
>
> The confusing aspect is that the same option is used in two places and the
> first one annihilates the second. But that is documented:
>
> prometheus:pharo5 sven$ ./pharo Pharo.image --help
> Usage: [--no-preferences|--preference-file=][] [--
> help] [--copyright] [--version] [--list] [ --no-quit ]
>   --help   print this help message
>   --copyright  print the copyrights
>   --versionprint the version for the image and the vm
>   --list   list a description of all active command line handlers
>   --no-quitkeep the image running without activating any other
> command line handler
>a valid subcommand in --list
>
> Documentation:
> A BasicCommandLineHandler handles default command line arguments and
> options.
>
> It clearly says "without activating any other command line handler". So using
> --no-quit BEFORE the subcommand annihilates the subcommand (AFAIU).
>
> > On 12 Jan 2016, at 11:28, Blondeau Vincent
>  wrote:
> >
> > So --no-quit should be removed from the default line handler?
> >
> > Vincent
> >
> >> -Message d'origine-
> >> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> >> de Esteban Lorenzano Envoyé : mardi 12 janvier 2016 11:18 À : Pharo
> >> Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> >> CentOS?
> >>
> >> But you cannot use it as a general command.
> >> If you use a subcommand (most likely) then you do not have it unless
> >> the subcommand defines it.
> >>
> >> Esteban
> >>
> >>> On 12 Jan 2016, at 11:12, Blondeau Vincent
> >>  wrote:
> >>>
> >>>
> >>>
>  -Message d'origine-
>  De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
>  part de Sven Van Caekenberghe Envoyé : mardi 12 janvier 2016 10:57 À
> :
>  Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works
>  on CentOS?
> 
> 
> >> On 12 Jan 2016, at 10:50, Esteban Lorenzano
> 
> > wrote:
> >
> >
> >
> >> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe 
> >> wrote:
> >>
> >>
> >>> On 12 Jan 2016, at 10:28, Blondeau Vincent
>   wrote:
> >>>
> >>> Indeed, it works. Thanks!
> >>>
> >>> But the command line usage is not clear :
> >>> ./pharo Pharo.image
> >>> Usage: [--no-preferences|--preference-
> file=][]
> >>> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> >>>
> >>> Maybe, it can be :
> >>> Usage: [--no-preferences|--preference-
> file=][]
> >>> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> >>> []
> >>>
> >>> Moreover, an option can usually be placed anywhere on the
> >>> command
>  line, shouldn't it? Or at least it should raise an error?
> >>
> >> Yes it is a bit confusion (but you could try to read/understand
> >> the Pharo code, it is not very difficult ;-)
> >>
> >> But the idea is that the sub-command controls its own options
> >> (like passing linker options via the compiler to the linker - git
> >> also has global and per sub command options, no ?)
> >>
> >> --no-quit probably also works for the default command ... (I
> >> haven't
>  looked), so at that point, the option is consumed already.
> >
> > No, it doesn't :)
> 
>  prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version]
>  5.0
>  #50510
>  prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C
> 
>  The last command 'hangs' (i.e. the image keeps running, just as
> >> advertised).
>  So the default (Pharo, subclass of BasicCommandHandler) interpreted
>  the -- no-quit and acted upon it. No ?
> >>>
> >>> Yes! See: BasicComm

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Sven Van Caekenberghe]

No, I don't think so, it has a function.

Some people like to configure Pharo images so that they have a running server 
inside them. In that case, starting your app is a simple as starting the image, 
but you would probably need the --no-quit to prevent it from exiting 
immediately.

(I personally don't like and never use that approach, but I know some people 
like it).

The confusing aspect is that the same option is used in two places and the 
first one annihilates the second. But that is documented:

prometheus:pharo5 sven$ ./pharo Pharo.image --help
Usage: [--no-preferences|--preference-file=][] [--help] 
[--copyright] [--version] [--list] [ --no-quit ]
--help   print this help message
--copyright  print the copyrights
--versionprint the version for the image and the vm
--list   list a description of all active command line handlers
--no-quitkeep the image running without activating any other 
command line handler
 a valid subcommand in --list

Documentation:
A BasicCommandLineHandler handles default command line arguments and options.

It clearly says "without activating any other command line handler". So using 
--no-quit BEFORE the subcommand annihilates the subcommand (AFAIU).

> On 12 Jan 2016, at 11:28, Blondeau Vincent  
> wrote:
> 
> So --no-quit should be removed from the default line handler?
> 
> Vincent
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>> Esteban Lorenzano
>> Envoyé : mardi 12 janvier 2016 11:18
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>> 
>> But you cannot use it as a general command.
>> If you use a subcommand (most likely) then you do not have it unless the
>> subcommand defines it.
>> 
>> Esteban
>> 
>>> On 12 Jan 2016, at 11:12, Blondeau Vincent
>>  wrote:
>>> 
>>> 
>>> 
 -Message d'origine-
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
 de Sven Van Caekenberghe Envoyé : mardi 12 janvier 2016 10:57 À :
 Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
 CentOS?
 
 
>> On 12 Jan 2016, at 10:50, Esteban Lorenzano 
> wrote:
> 
> 
> 
>> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe 
>> wrote:
>> 
>> 
>>> On 12 Jan 2016, at 10:28, Blondeau Vincent
  wrote:
>>> 
>>> Indeed, it works. Thanks!
>>> 
>>> But the command line usage is not clear :
>>> ./pharo Pharo.image
>>> Usage: [--no-preferences|--preference-file=][]
>>> [--help] [--copyright] [--version] [--list] [ --no-quit ]
>>> 
>>> Maybe, it can be :
>>> Usage: [--no-preferences|--preference-file=][]
>>> [--help] [--copyright] [--version] [--list] [ --no-quit ]
>>> []
>>> 
>>> Moreover, an option can usually be placed anywhere on the command
 line, shouldn't it? Or at least it should raise an error?
>> 
>> Yes it is a bit confusion (but you could try to read/understand the
>> Pharo code, it is not very difficult ;-)
>> 
>> But the idea is that the sub-command controls its own options (like
>> passing linker options via the compiler to the linker - git also
>> has global and per sub command options, no ?)
>> 
>> --no-quit probably also works for the default command ... (I
>> haven't
 looked), so at that point, the option is consumed already.
> 
> No, it doesn't :)
 
 prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version]
 5.0
 #50510
 prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C
 
 The last command 'hangs' (i.e. the image keeps running, just as
>> advertised).
 So the default (Pharo, subclass of BasicCommandHandler) interpreted
 the -- no-quit and acted upon it. No ?
>>> 
>>> Yes! See: BasicCommandLineHandler>>handleArgument:
 
>> 
>>> Vincent
> 
> 
> 
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
> exclusif de ses destinataires. Il peut également être protégé par le secret 
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne 
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra 
> être recherchée quant au contenu de ce message. Bien que les meilleurs 
> efforts soient faits pour maintenir cette transmission exempte de tout virus, 
> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
> saurait être recherchée pour tout dommage résultant d'un virus transmis.
> 
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its integrity 
> cannot be secured on the Internet, the Worldline liability cannot be 
> triggere

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Skip Lentz]

Haha, don’t worry. You don’t have to shut up, in fact I thank you for replying.

I don’t know exactly how it has been implemented, I had a look see and it seems 
to be like this:

It seems to collect all methods that will be checked for coverage, and then 
instantiate a wrapper around each one,
and replace the method with the wrapper in the method dictionary of the class 
(and restore it afterwards, obviously).

Maybe it should only lock the threads that were _not_ started by the “test 
thread”? I’m not even sure that is possible,
just suggesting things.

> On Jan 12, 2016, at 11:11 AM, Sven Van Caekenberghe  wrote:
> 
> The coverage seems to be implemented by 'locking' the current execution 
> thread exclusively, which would mean no other threads can run, at all. So 
> code depending on multi threading, like client/server code, like HTTP, cannot 
> work. Yes that seems to be a limitation, but an understandable one.
> 
> I am trying to help but I don't known anything about the coverage tool, so 
> maybe I should shut up ;-)
> 
>> On 12 Jan 2016, at 11:05, Skip Lentz  wrote:
>> 
>> You mean as in it can check the coverage effected by the code running in the 
>> other thread?
>> Or is this not what you mean?
>> 
>> Well I mean, at least it can show the coverage done by what was run in the 
>> same thread..
>> And it will at least not hang or fail.
>> 
>>> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe  wrote:
>>> 
>>> I never used that, but it seems coverage can only deal with single threaded 
>>> code, which sounds logical. No ?
>>> 
 On 12 Jan 2016, at 10:53, Skip Lentz  wrote:
 
 Hi,
 
 When I want to run the coverage of for example Zinc’s Client and Server 
 tests,
 it will either hang (in the case of Zinc’s test cases) or fail because the 
 coverage
 uses BlockClosure>>valueUnpreemptively for running the tests.
 The relevant method is TestRunner>>collectCoverageFor:.
 
 So when a test is run, it is not able to be preempted by another process, 
 like for
 example a local server which is needed to run the actual test in Zinc’s 
 case.
 
 When I use BlockClosure>>valueUninterruptably it works. Can someone tell me
 if it is wrong to use that instead? Is valueUnpreemptively necessary in 
 this case,
 and if so, why?
 
 To reproduce: Load fresh image, select Zinc's ZnClientTests and 
 ZnServerTests,
 click on “Run Coverage” -> hanging image.
 
 Thanks,
 
 Skip
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Blondeau Vincent]

So --no-quit should be removed from the default line handler?

Vincent

> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
> Esteban Lorenzano
> Envoyé : mardi 12 janvier 2016 11:18
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>
> But you cannot use it as a general command.
> If you use a subcommand (most likely) then you do not have it unless the
> subcommand defines it.
>
> Esteban
>
> > On 12 Jan 2016, at 11:12, Blondeau Vincent
>  wrote:
> >
> >
> >
> >> -Message d'origine-
> >> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> >> de Sven Van Caekenberghe Envoyé : mardi 12 janvier 2016 10:57 À :
> >> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> >> CentOS?
> >>
> >>
>  On 12 Jan 2016, at 10:50, Esteban Lorenzano 
> >>> wrote:
> >>>
> >>>
> >>>
>  On 12 Jan 2016, at 10:34, Sven Van Caekenberghe 
> wrote:
> 
> 
> > On 12 Jan 2016, at 10:28, Blondeau Vincent
> >>  wrote:
> >
> > Indeed, it works. Thanks!
> >
> > But the command line usage is not clear :
> > ./pharo Pharo.image
> > Usage: [--no-preferences|--preference-file=][]
> > [--help] [--copyright] [--version] [--list] [ --no-quit ]
> >
> > Maybe, it can be :
> > Usage: [--no-preferences|--preference-file=][]
> > [--help] [--copyright] [--version] [--list] [ --no-quit ]
> > []
> >
> > Moreover, an option can usually be placed anywhere on the command
> >> line, shouldn't it? Or at least it should raise an error?
> 
>  Yes it is a bit confusion (but you could try to read/understand the
>  Pharo code, it is not very difficult ;-)
> 
>  But the idea is that the sub-command controls its own options (like
>  passing linker options via the compiler to the linker - git also
>  has global and per sub command options, no ?)
> 
>  --no-quit probably also works for the default command ... (I
>  haven't
> >> looked), so at that point, the option is consumed already.
> >>>
> >>> No, it doesn't :)
> >>
> >> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version]
> >> 5.0
> >> #50510
> >> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C
> >>
> >> The last command 'hangs' (i.e. the image keeps running, just as
> advertised).
> >> So the default (Pharo, subclass of BasicCommandHandler) interpreted
> >> the -- no-quit and acted upon it. No ?
> >
> > Yes! See: BasicCommandLineHandler>>handleArgument:
> >>
> 
> > Vincent



Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Esteban Lorenzano]

But you cannot use it as a general command.
If you use a subcommand (most likely) then you do not have it unless the 
subcommand defines it.

Esteban 

> On 12 Jan 2016, at 11:12, Blondeau Vincent  
> wrote:
> 
> 
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>> Sven Van Caekenberghe
>> Envoyé : mardi 12 janvier 2016 10:57
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>> 
>> 
 On 12 Jan 2016, at 10:50, Esteban Lorenzano 
>>> wrote:
>>> 
>>> 
>>> 
 On 12 Jan 2016, at 10:34, Sven Van Caekenberghe  wrote:
 
 
> On 12 Jan 2016, at 10:28, Blondeau Vincent
>>  wrote:
> 
> Indeed, it works. Thanks!
> 
> But the command line usage is not clear :
> ./pharo Pharo.image
> Usage: [--no-preferences|--preference-file=][]
> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> 
> Maybe, it can be :
> Usage: [--no-preferences|--preference-file=][]
> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> []
> 
> Moreover, an option can usually be placed anywhere on the command
>> line, shouldn't it? Or at least it should raise an error?
 
 Yes it is a bit confusion (but you could try to read/understand the
 Pharo code, it is not very difficult ;-)
 
 But the idea is that the sub-command controls its own options (like
 passing linker options via the compiler to the linker - git also has
 global and per sub command options, no ?)
 
 --no-quit probably also works for the default command ... (I haven't
>> looked), so at that point, the option is consumed already.
>>> 
>>> No, it doesn't :)
>> 
>> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] 5.0
>> #50510
>> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C
>> 
>> The last command 'hangs' (i.e. the image keeps running, just as advertised).
>> So the default (Pharo, subclass of BasicCommandHandler) interpreted the --
>> no-quit and acted upon it. No ?
> 
> Yes! See: BasicCommandLineHandler>>handleArgument:
>> 
 
> Vincent
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
>> part de Esteban Lorenzano Envoyé : lundi 11 janvier 2016 19:21 À :
>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works
>> on CentOS?
>> 
>> 
>>> On 11 Jan 2016, at 19:06, Sven Van Caekenberghe 
>> wrote:
>>> 
>>> Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn:
>> 8080'
>>> 
>>> ?
>>> 
>>> I.e. the --no-quit AFTER the eval.
>> 
>> yes, is like that :)
>> 
>>> 
>>> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealclou
>>> dser
>>> ver
>>> 
 On 11 Jan 2016, at 18:46, Blondeau Vincent
>>  wrote:
 
 The .sources are in the vm folder.
 
 And, it is working, but without the –no-quit option and this kind of
>> code :
 [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
 
 The –no-quit option seems to have a bad influence…
 
 Can you tell me which packages you installed?
 
 Thanks
 
 Vincent
 
 
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
 part de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À
>> :
 Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works
 on CentOS?
 
 It does work for me in CentOS.
 Are you sure .sources file is in the correct place?
 
 On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
>>  wrote:
 Thanks for your answer.
 
 However, it seems that the server does not start with:
 ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit
 eval
>> "ZnServer  startOn:  8080."
 Nothing in the terminal and no open port in "netstat -an"
 
 While, this command is writing something in the terminal:
 ./pharo -vm-display-null -vm-sound-null Pharo.image eval
 "ZnServer
>> startOn:  8080."
 a ZnManagingMultiThreadedServer(running 8080)
 
 Vincent
 
> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
> part de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03
>> À :
> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur
> works on CentOS?
> 
> 
>>> On 11 Jan 2016, at 16:51, Blondeau Vincent
>>  wrote:
>> 
>> Hello,
>> 
>> I just wanted to run a latest Pharo image on a CentOS server to
>> run a Zinc
> server.
>> So I did:
>> curl get.pharo.org/50+vm | bash
>> 
>> ./pharo Pharo.im

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Blondeau Vincent]

> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
> Sven Van Caekenberghe
> Envoyé : mardi 12 janvier 2016 10:57
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>
>
> > On 12 Jan 2016, at 10:50, Esteban Lorenzano 
> wrote:
> >
> >
> >
> >> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe  wrote:
> >>
> >>
> >>> On 12 Jan 2016, at 10:28, Blondeau Vincent
>  wrote:
> >>>
> >>> Indeed, it works. Thanks!
> >>>
> >>> But the command line usage is not clear :
> >>> ./pharo Pharo.image
> >>> Usage: [--no-preferences|--preference-file=][]
> >>> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> >>>
> >>> Maybe, it can be :
> >>> Usage: [--no-preferences|--preference-file=][]
> >>> [--help] [--copyright] [--version] [--list] [ --no-quit ]
> >>> []
> >>>
> >>> Moreover, an option can usually be placed anywhere on the command
> line, shouldn't it? Or at least it should raise an error?
> >>
> >> Yes it is a bit confusion (but you could try to read/understand the
> >> Pharo code, it is not very difficult ;-)
> >>
> >> But the idea is that the sub-command controls its own options (like
> >> passing linker options via the compiler to the linker - git also has
> >> global and per sub command options, no ?)
> >>
> >> --no-quit probably also works for the default command ... (I haven't
> looked), so at that point, the option is consumed already.
> >
> > No, it doesn't :)
>
> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] 5.0
> #50510
> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C
>
> The last command 'hangs' (i.e. the image keeps running, just as advertised).
> So the default (Pharo, subclass of BasicCommandHandler) interpreted the --
> no-quit and acted upon it. No ?

Yes! See: BasicCommandLineHandler>>handleArgument:
>
> >>
> >>> Vincent
> >>>
>  -Message d'origine-
>  De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
>  part de Esteban Lorenzano Envoyé : lundi 11 janvier 2016 19:21 À :
>  Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works
>  on CentOS?
> 
> 
> > On 11 Jan 2016, at 19:06, Sven Van Caekenberghe 
> wrote:
> >
> > Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn:
> 8080'
> >
> > ?
> >
> > I.e. the --no-quit AFTER the eval.
> 
>  yes, is like that :)
> 
> >
> > http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealclou
> > dser
> > ver
> >
> >> On 11 Jan 2016, at 18:46, Blondeau Vincent
>   wrote:
> >>
> >> The .sources are in the vm folder.
> >>
> >> And, it is working, but without the –no-quit option and this kind of
> code :
> >> [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
> >>
> >> The –no-quit option seems to have a bad influence…
> >>
> >> Can you tell me which packages you installed?
> >>
> >> Thanks
> >>
> >> Vincent
> >>
> >>
> >> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
> >> part de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À
> :
> >> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works
> >> on CentOS?
> >>
> >> It does work for me in CentOS.
> >> Are you sure .sources file is in the correct place?
> >>
> >> On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
>   wrote:
> >> Thanks for your answer.
> >>
> >> However, it seems that the server does not start with:
> >> ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit
> >> eval
>  "ZnServer  startOn:  8080."
> >> Nothing in the terminal and no open port in "netstat -an"
> >>
> >> While, this command is writing something in the terminal:
> >> ./pharo -vm-display-null -vm-sound-null Pharo.image eval
> >> "ZnServer
>  startOn:  8080."
> >> a ZnManagingMultiThreadedServer(running 8080)
> >>
> >> Vincent
> >>
> >>> -Message d'origine-
> >>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la
> >>> part de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03
> À :
> >>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur
> >>> works on CentOS?
> >>>
> >>>
> > On 11 Jan 2016, at 16:51, Blondeau Vincent
>   wrote:
> 
>  Hello,
> 
>  I just wanted to run a latest Pharo image on a CentOS server to
>  run a Zinc
> >>> server.
>  So I did:
>  curl get.pharo.org/50+vm | bash
> 
>  ./pharo Pharo.image eval “1+1”  evals to 2
> 
>  But,
>  ./pharo Pharo.image --no-quit eval "ZnServer  startOn:  8080."
>  returns:
>  ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so):
>  libfreetype.so.6: cannot open shared object file: No such file
> 

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Sven Van Caekenberghe]

The coverage seems to be implemented by 'locking' the current execution thread 
exclusively, which would mean no other threads can run, at all. So code 
depending on multi threading, like client/server code, like HTTP, cannot work. 
Yes that seems to be a limitation, but an understandable one.

I am trying to help but I don't known anything about the coverage tool, so 
maybe I should shut up ;-)

> On 12 Jan 2016, at 11:05, Skip Lentz  wrote:
> 
> You mean as in it can check the coverage effected by the code running in the 
> other thread?
> Or is this not what you mean?
> 
> Well I mean, at least it can show the coverage done by what was run in the 
> same thread..
> And it will at least not hang or fail.
> 
>> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe  wrote:
>> 
>> I never used that, but it seems coverage can only deal with single threaded 
>> code, which sounds logical. No ?
>> 
>>> On 12 Jan 2016, at 10:53, Skip Lentz  wrote:
>>> 
>>> Hi,
>>> 
>>> When I want to run the coverage of for example Zinc’s Client and Server 
>>> tests,
>>> it will either hang (in the case of Zinc’s test cases) or fail because the 
>>> coverage
>>> uses BlockClosure>>valueUnpreemptively for running the tests.
>>> The relevant method is TestRunner>>collectCoverageFor:.
>>> 
>>> So when a test is run, it is not able to be preempted by another process, 
>>> like for
>>> example a local server which is needed to run the actual test in Zinc’s 
>>> case.
>>> 
>>> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me
>>> if it is wrong to use that instead? Is valueUnpreemptively necessary in 
>>> this case,
>>> and if so, why?
>>> 
>>> To reproduce: Load fresh image, select Zinc's ZnClientTests and 
>>> ZnServerTests,
>>> click on “Run Coverage” -> hanging image.
>>> 
>>> Thanks,
>>> 
>>> Skip
>> 
>> 
> 
> 

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Skip Lentz]

"can NOT check"*, in the first sentence.
> On Jan 12, 2016, at 11:05 AM, Skip Lentz  wrote:
> 
> You mean as in it can check the coverage effected by the code running in the 
> other thread?
> Or is this not what you mean?
> 
> Well I mean, at least it can show the coverage done by what was run in the 
> same thread..
> And it will at least not hang or fail.
> 
>> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe  wrote:
>> 
>> I never used that, but it seems coverage can only deal with single threaded 
>> code, which sounds logical. No ?
>> 
>>> On 12 Jan 2016, at 10:53, Skip Lentz  wrote:
>>> 
>>> Hi,
>>> 
>>> When I want to run the coverage of for example Zinc’s Client and Server 
>>> tests,
>>> it will either hang (in the case of Zinc’s test cases) or fail because the 
>>> coverage
>>> uses BlockClosure>>valueUnpreemptively for running the tests.
>>> The relevant method is TestRunner>>collectCoverageFor:.
>>> 
>>> So when a test is run, it is not able to be preempted by another process, 
>>> like for
>>> example a local server which is needed to run the actual test in Zinc’s 
>>> case.
>>> 
>>> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me
>>> if it is wrong to use that instead? Is valueUnpreemptively necessary in 
>>> this case,
>>> and if so, why?
>>> 
>>> To reproduce: Load fresh image, select Zinc's ZnClientTests and 
>>> ZnServerTests,
>>> click on “Run Coverage” -> hanging image.
>>> 
>>> Thanks,
>>> 
>>> Skip
>> 
>> 
> 

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Skip Lentz]

You mean as in it can check the coverage effected by the code running in the 
other thread?
Or is this not what you mean?

Well I mean, at least it can show the coverage done by what was run in the same 
thread..
And it will at least not hang or fail.

> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe  wrote:
> 
> I never used that, but it seems coverage can only deal with single threaded 
> code, which sounds logical. No ?
> 
>> On 12 Jan 2016, at 10:53, Skip Lentz  wrote:
>> 
>> Hi,
>> 
>> When I want to run the coverage of for example Zinc’s Client and Server 
>> tests,
>> it will either hang (in the case of Zinc’s test cases) or fail because the 
>> coverage
>> uses BlockClosure>>valueUnpreemptively for running the tests.
>> The relevant method is TestRunner>>collectCoverageFor:.
>> 
>> So when a test is run, it is not able to be preempted by another process, 
>> like for
>> example a local server which is needed to run the actual test in Zinc’s case.
>> 
>> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me
>> if it is wrong to use that instead? Is valueUnpreemptively necessary in this 
>> case,
>> and if so, why?
>> 
>> To reproduce: Load fresh image, select Zinc's ZnClientTests and 
>> ZnServerTests,
>> click on “Run Coverage” -> hanging image.
>> 
>> Thanks,
>> 
>> Skip
> 
> 

Re: [Pharo-dev] Morphic Migrations gotchas, was Re: Better class comment version2

[David Allouche]

I wonder whether it would be worth reversing this change, to remove an 
unnecessary incompatibility with other dialects.

But maybe there is no development activity outside of Pharo, that would justify 
making any effort to maintain compatibility. I do not know.

Practicality beats purity, if cleaning up existing APIs means cutting out Pharo 
from a wider ecosystem, and introducing painful bitrot, it might not be worth 
the cost.


> On 11 Jan 2016, at 22:25, Nicolas Cellier 
>  wrote:
> 
> And it probably won't be integrated in Squeak, because it's not worth the 
> pain.
> 
> The change was conducted without analyzing all the impacts, because it was 
> probably not possible to analyze the huge code base.
> (though it would have been possible to instrument code and collect the sender 
> stacks producing degenerated rectangles)
> 
> The only motto was to make code more "pure".
> Generally, I tend to be wary...
> 
> On the other hand, storing the offsets in a rectangle just because there are 
> 4 edges is sort of hackish usage, so while at cleaning...
> 
> 2016-01-11 9:42 GMT+01:00 Stephan Eggermont  >:
> On 10-01-16 23:16, Thierry Goubier wrote:
> Hi David,
> 
> this is the bug with LayoutFrame>>#fractions:offsets: we were talking
> about relative to that class comment.
> 
> In Pharo, Rectangles are constrained to have the smallest vertical value
> as the top, smallest horizontal value as the left, largest vertical
> value as bottom and largest horizontal value as right.
> 
> Indeed. And there is no Morphic documentation at all that is aware of that, 
> as nearly all of it was written before we changed the behavior of Rectangle 
> in Pharo, and it is a change that is not done in Squeak. The result is that 
> nearly no old Morphic code will run unmodified in Pharo.
> 
> I would like to collect a list of these gotchas, preferably with solutions, 
> to make it easier for people to update/migrate old morphic code. Post them 
> here, or mail them to me.
> 
> Stephan
> 
> 
> 
> 
> 

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Sven Van Caekenberghe]

I never used that, but it seems coverage can only deal with single threaded 
code, which sounds logical. No ?

> On 12 Jan 2016, at 10:53, Skip Lentz  wrote:
> 
> Hi,
> 
> When I want to run the coverage of for example Zinc’s Client and Server tests,
> it will either hang (in the case of Zinc’s test cases) or fail because the 
> coverage
> uses BlockClosure>>valueUnpreemptively for running the tests.
> The relevant method is TestRunner>>collectCoverageFor:.
> 
> So when a test is run, it is not able to be preempted by another process, 
> like for
> example a local server which is needed to run the actual test in Zinc’s case.
> 
> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me
> if it is wrong to use that instead? Is valueUnpreemptively necessary in this 
> case,
> and if so, why?
> 
> To reproduce: Load fresh image, select Zinc's ZnClientTests and ZnServerTests,
> click on “Run Coverage” -> hanging image.
> 
> Thanks,
> 
> Skip

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Sven Van Caekenberghe]

> On 12 Jan 2016, at 10:50, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 12 Jan 2016, at 10:28, Blondeau Vincent  
>>> wrote:
>>> 
>>> Indeed, it works. Thanks!
>>> 
>>> But the command line usage is not clear :
>>> ./pharo Pharo.image
>>> Usage: [--no-preferences|--preference-file=][] [--help] 
>>> [--copyright] [--version] [--list] [ --no-quit ]
>>> 
>>> Maybe, it can be :
>>> Usage: [--no-preferences|--preference-file=][] [--help] 
>>> [--copyright] [--version] [--list] [ --no-quit ] []
>>> 
>>> Moreover, an option can usually be placed anywhere on the command line, 
>>> shouldn't it? Or at least it should raise an error?
>> 
>> Yes it is a bit confusion (but you could try to read/understand the Pharo 
>> code, it is not very difficult ;-)
>> 
>> But the idea is that the sub-command controls its own options (like passing 
>> linker options via the compiler to the linker - git also has global and per 
>> sub command options, no ?)
>> 
>> --no-quit probably also works for the default command ... (I haven't 
>> looked), so at that point, the option is consumed already.
> 
> No, it doesn't :)

prometheus:pharo5 sven$ ./pharo Pharo.image printVersion
[version] 5.0 #50510
prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit
^C

The last command 'hangs' (i.e. the image keeps running, just as advertised). So 
the default (Pharo, subclass of BasicCommandHandler) interpreted the --no-quit 
and acted upon it. No ?

>> 
>>> Vincent
>>> 
 -Message d'origine-
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
 Esteban Lorenzano
 Envoyé : lundi 11 janvier 2016 19:21
 À : Pharo Development List
 Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
 
 
> On 11 Jan 2016, at 19:06, Sven Van Caekenberghe  wrote:
> 
> Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 
> 8080'
> 
> ?
> 
> I.e. the --no-quit AFTER the eval.
 
 yes, is like that :)
 
> 
> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealcloudser
> ver
> 
>> On 11 Jan 2016, at 18:46, Blondeau Vincent
  wrote:
>> 
>> The .sources are in the vm folder.
>> 
>> And, it is working, but without the –no-quit option and this kind of 
>> code :
>> [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
>> 
>> The –no-quit option seems to have a bad influence…
>> 
>> Can you tell me which packages you installed?
>> 
>> Thanks
>> 
>> Vincent
>> 
>> 
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
>> de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À :
>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
>> CentOS?
>> 
>> It does work for me in CentOS.
>> Are you sure .sources file is in the correct place?
>> 
>> On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
  wrote:
>> Thanks for your answer.
>> 
>> However, it seems that the server does not start with:
>> ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit eval
 "ZnServer  startOn:  8080."
>> Nothing in the terminal and no open port in "netstat -an"
>> 
>> While, this command is writing something in the terminal:
>> ./pharo -vm-display-null -vm-sound-null Pharo.image eval "ZnServer
 startOn:  8080."
>> a ZnManagingMultiThreadedServer(running 8080)
>> 
>> Vincent
>> 
>>> -Message d'origine-
>>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
>>> de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03 À :
>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
>>> CentOS?
>>> 
>>> 
> On 11 Jan 2016, at 16:51, Blondeau Vincent
  wrote:
 
 Hello,
 
 I just wanted to run a latest Pharo image on a CentOS server to run
 a Zinc
>>> server.
 So I did:
 curl get.pharo.org/50+vm | bash
 
 ./pharo Pharo.image eval “1+1”  evals to 2
 
 But,
 ./pharo Pharo.image --no-quit eval "ZnServer  startOn:  8080."
 returns:
 ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so):
 libfreetype.so.6: cannot open shared object file: No such file or
 directory
 
 So the server is not launched…
 
 What are the libs that should be installed on the machine? Should I
 take
>>> another VM?
 
 BTW, why a headless image needs a freetype lib?
>>> 
>>> Yeah, that should not be the case:
>>> 
>>> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html
>>> 
 Thanks in advance,
 
 Cheers,
 Vincent Blondeau
>> 
>> 
>> 
>> Ce message et les pièces joint

[Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

[Skip Lentz]

Hi,

When I want to run the coverage of for example Zinc’s Client and Server tests,
it will either hang (in the case of Zinc’s test cases) or fail because the 
coverage
uses BlockClosure>>valueUnpreemptively for running the tests.
The relevant method is TestRunner>>collectCoverageFor:.

So when a test is run, it is not able to be preempted by another process, like 
for
example a local server which is needed to run the actual test in Zinc’s case.

When I use BlockClosure>>valueUninterruptably it works. Can someone tell me
if it is wrong to use that instead? Is valueUnpreemptively necessary in this 
case,
and if so, why?

To reproduce: Load fresh image, select Zinc's ZnClientTests and ZnServerTests,
click on “Run Coverage” -> hanging image.

Thanks,

Skip

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Esteban Lorenzano]

> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe  wrote:
> 
> 
>> On 12 Jan 2016, at 10:28, Blondeau Vincent  
>> wrote:
>> 
>> Indeed, it works. Thanks!
>> 
>> But the command line usage is not clear :
>> ./pharo Pharo.image
>> Usage: [--no-preferences|--preference-file=][] [--help] 
>> [--copyright] [--version] [--list] [ --no-quit ]
>> 
>> Maybe, it can be :
>> Usage: [--no-preferences|--preference-file=][] [--help] 
>> [--copyright] [--version] [--list] [ --no-quit ] []
>> 
>> Moreover, an option can usually be placed anywhere on the command line, 
>> shouldn't it? Or at least it should raise an error?
> 
> Yes it is a bit confusion (but you could try to read/understand the Pharo 
> code, it is not very difficult ;-)
> 
> But the idea is that the sub-command controls its own options (like passing 
> linker options via the compiler to the linker - git also has global and per 
> sub command options, no ?)
> 
> --no-quit probably also works for the default command ... (I haven't looked), 
> so at that point, the option is consumed already.

No, it doesn't :)


> 
>> Vincent
>> 
>>> -Message d'origine-
>>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>>> Esteban Lorenzano
>>> Envoyé : lundi 11 janvier 2016 19:21
>>> À : Pharo Development List
>>> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>>> 
>>> 
 On 11 Jan 2016, at 19:06, Sven Van Caekenberghe  wrote:
 
 Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 
 8080'
 
 ?
 
 I.e. the --no-quit AFTER the eval.
>>> 
>>> yes, is like that :)
>>> 
 
 http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealcloudser
 ver
 
> On 11 Jan 2016, at 18:46, Blondeau Vincent
>>>  wrote:
> 
> The .sources are in the vm folder.
> 
> And, it is working, but without the –no-quit option and this kind of code 
> :
> [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
> 
> The –no-quit option seems to have a bad influence…
> 
> Can you tell me which packages you installed?
> 
> Thanks
> 
> Vincent
> 
> 
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À :
> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> CentOS?
> 
> It does work for me in CentOS.
> Are you sure .sources file is in the correct place?
> 
> On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
>>>  wrote:
> Thanks for your answer.
> 
> However, it seems that the server does not start with:
> ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit eval
>>> "ZnServer  startOn:  8080."
> Nothing in the terminal and no open port in "netstat -an"
> 
> While, this command is writing something in the terminal:
> ./pharo -vm-display-null -vm-sound-null Pharo.image eval "ZnServer
>>> startOn:  8080."
> a ZnManagingMultiThreadedServer(running 8080)
> 
> Vincent
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
>> de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03 À :
>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
>> CentOS?
>> 
>> 
 On 11 Jan 2016, at 16:51, Blondeau Vincent
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> I just wanted to run a latest Pharo image on a CentOS server to run
>>> a Zinc
>> server.
>>> So I did:
>>> curl get.pharo.org/50+vm | bash
>>> 
>>> ./pharo Pharo.image eval “1+1”  evals to 2
>>> 
>>> But,
>>> ./pharo Pharo.image --no-quit eval "ZnServer  startOn:  8080."
>>> returns:
>>> ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so):
>>> libfreetype.so.6: cannot open shared object file: No such file or
>>> directory
>>> 
>>> So the server is not launched…
>>> 
>>> What are the libs that should be installed on the machine? Should I
>>> take
>> another VM?
>>> 
>>> BTW, why a headless image needs a freetype lib?
>> 
>> Yeah, that should not be the case:
>> 
>> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html
>> 
>>> Thanks in advance,
>>> 
>>> Cheers,
>>> Vincent Blondeau
> 
> 
> 
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
>>> exclusif de ses destinataires. Il peut également être protégé par le secret
>>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
>>> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
>>> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
>>> être recherchée quant au contenu de ce message. Bien que les meilleurs
>>> efforts soient faits pour maintenir cette transmission exempte de tout 
>>> virus,
>>> l'expédi

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Esteban Lorenzano]

> On 12 Jan 2016, at 10:28, Blondeau Vincent  
> wrote:
> 
> Indeed, it works. Thanks!
> 
> But the command line usage is not clear :
> ./pharo Pharo.image
> Usage: [--no-preferences|--preference-file=][] [--help] 
> [--copyright] [--version] [--list] [ --no-quit ]
> 
> Maybe, it can be :
> Usage: [--no-preferences|--preference-file=][] [--help] 
> [--copyright] [--version] [--list] [ --no-quit ] []
> 
> Moreover, an option can usually be placed anywhere on the command line, 
> shouldn't it? Or at least it should raise an error?

No it can't :)
And is hard to show an error, is not always possible (depends on command line 
handler developer) 
Of course it can be enhanced... But it requires time, as always :)

Esteban 

> 
> Vincent
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>> Esteban Lorenzano
>> Envoyé : lundi 11 janvier 2016 19:21
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>> 
>> 
>>> On 11 Jan 2016, at 19:06, Sven Van Caekenberghe  wrote:
>>> 
>>> Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 8080'
>>> 
>>> ?
>>> 
>>> I.e. the --no-quit AFTER the eval.
>> 
>> yes, is like that :)
>> 
>>> 
>>> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealcloudser
>>> ver
>>> 
 On 11 Jan 2016, at 18:46, Blondeau Vincent
>>  wrote:
 
 The .sources are in the vm folder.
 
 And, it is working, but without the –no-quit option and this kind of code :
 [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
 
 The –no-quit option seems to have a bad influence…
 
 Can you tell me which packages you installed?
 
 Thanks
 
 Vincent
 
 
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
 de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À :
 Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
 CentOS?
 
 It does work for me in CentOS.
 Are you sure .sources file is in the correct place?
 
 On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
>>  wrote:
 Thanks for your answer.
 
 However, it seems that the server does not start with:
 ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit eval
>> "ZnServer  startOn:  8080."
 Nothing in the terminal and no open port in "netstat -an"
 
 While, this command is writing something in the terminal:
 ./pharo -vm-display-null -vm-sound-null Pharo.image eval "ZnServer
>> startOn:  8080."
 a ZnManagingMultiThreadedServer(running 8080)
 
 Vincent
 
> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03 À :
> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> CentOS?
> 
> 
>>> On 11 Jan 2016, at 16:51, Blondeau Vincent
>>  wrote:
>> 
>> Hello,
>> 
>> I just wanted to run a latest Pharo image on a CentOS server to run
>> a Zinc
> server.
>> So I did:
>> curl get.pharo.org/50+vm | bash
>> 
>> ./pharo Pharo.image eval “1+1”  evals to 2
>> 
>> But,
>> ./pharo Pharo.image --no-quit eval "ZnServer  startOn:  8080."
>> returns:
>> ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so):
>> libfreetype.so.6: cannot open shared object file: No such file or
>> directory
>> 
>> So the server is not launched…
>> 
>> What are the libs that should be installed on the machine? Should I
>> take
> another VM?
>> 
>> BTW, why a headless image needs a freetype lib?
> 
> Yeah, that should not be the case:
> 
> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html
> 
>> Thanks in advance,
>> 
>> Cheers,
>> Vincent Blondeau
 
 
 
 Ce message et les pièces jointes sont confidentiels et réservés à l'usage
>> exclusif de ses destinataires. Il peut également être protégé par le secret
>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
>> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
>> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
>> être recherchée quant au contenu de ce message. Bien que les meilleurs
>> efforts soient faits pour maintenir cette transmission exempte de tout virus,
>> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne
>> saurait être recherchée pour tout dommage résultant d'un virus transmis.
 
 This e-mail and the documents attached are confidential and intended
>> solely for the addressee; it may also be privileged. If you receive this 
>> e-mail
>> in error, please notify the sender immediately and destroy it. As its 
>> integrity
>> cannot be secured on the Internet, the Worldline liability cannot be 
>> triggered
>> for

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Esteban Lorenzano]

No, because --no-quit option is an option of eval subcommand (is not present 
for all)

What can be improved is the explanation on how to use the command line, for 
example:

-list list subcommands
subcommand --help show subcommand help 




> On 12 Jan 2016, at 10:28, Blondeau Vincent  
> wrote:
> 
> Indeed, it works. Thanks!
> 
> But the command line usage is not clear :
> ./pharo Pharo.image
> Usage: [--no-preferences|--preference-file=][] [--help] 
> [--copyright] [--version] [--list] [ --no-quit ]
> 
> Maybe, it can be :
> Usage: [--no-preferences|--preference-file=][] [--help] 
> [--copyright] [--version] [--list] [ --no-quit ] []
> 
> Moreover, an option can usually be placed anywhere on the command line, 
> shouldn't it? Or at least it should raise an error?
> 
> Vincent
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>> Esteban Lorenzano
>> Envoyé : lundi 11 janvier 2016 19:21
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>> 
>> 
>>> On 11 Jan 2016, at 19:06, Sven Van Caekenberghe  wrote:
>>> 
>>> Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 8080'
>>> 
>>> ?
>>> 
>>> I.e. the --no-quit AFTER the eval.
>> 
>> yes, is like that :)
>> 
>>> 
>>> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealcloudser
>>> ver
>>> 
 On 11 Jan 2016, at 18:46, Blondeau Vincent
>>  wrote:
 
 The .sources are in the vm folder.
 
 And, it is working, but without the –no-quit option and this kind of code :
 [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
 
 The –no-quit option seems to have a bad influence…
 
 Can you tell me which packages you installed?
 
 Thanks
 
 Vincent
 
 
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
 de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À :
 Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
 CentOS?
 
 It does work for me in CentOS.
 Are you sure .sources file is in the correct place?
 
 On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
>>  wrote:
 Thanks for your answer.
 
 However, it seems that the server does not start with:
 ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit eval
>> "ZnServer  startOn:  8080."
 Nothing in the terminal and no open port in "netstat -an"
 
 While, this command is writing something in the terminal:
 ./pharo -vm-display-null -vm-sound-null Pharo.image eval "ZnServer
>> startOn:  8080."
 a ZnManagingMultiThreadedServer(running 8080)
 
 Vincent
 
> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03 À :
> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> CentOS?
> 
> 
>>> On 11 Jan 2016, at 16:51, Blondeau Vincent
>>  wrote:
>> 
>> Hello,
>> 
>> I just wanted to run a latest Pharo image on a CentOS server to run
>> a Zinc
> server.
>> So I did:
>> curl get.pharo.org/50+vm | bash
>> 
>> ./pharo Pharo.image eval “1+1”  evals to 2
>> 
>> But,
>> ./pharo Pharo.image --no-quit eval "ZnServer  startOn:  8080."
>> returns:
>> ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so):
>> libfreetype.so.6: cannot open shared object file: No such file or
>> directory
>> 
>> So the server is not launched…
>> 
>> What are the libs that should be installed on the machine? Should I
>> take
> another VM?
>> 
>> BTW, why a headless image needs a freetype lib?
> 
> Yeah, that should not be the case:
> 
> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html
> 
>> Thanks in advance,
>> 
>> Cheers,
>> Vincent Blondeau
 
 
 
 Ce message et les pièces jointes sont confidentiels et réservés à l'usage
>> exclusif de ses destinataires. Il peut également être protégé par le secret
>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
>> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
>> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
>> être recherchée quant au contenu de ce message. Bien que les meilleurs
>> efforts soient faits pour maintenir cette transmission exempte de tout virus,
>> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne
>> saurait être recherchée pour tout dommage résultant d'un virus transmis.
 
 This e-mail and the documents attached are confidential and intended
>> solely for the addressee; it may also be privileged. If you receive this 
>> e-mail
>> in error, please notify the sender immediately and destroy it. As its 
>> integrity
>> cannot be secured on the Internet, the Wor

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Sven Van Caekenberghe]

> On 12 Jan 2016, at 10:28, Blondeau Vincent  
> wrote:
> 
> Indeed, it works. Thanks!
> 
> But the command line usage is not clear :
> ./pharo Pharo.image
> Usage: [--no-preferences|--preference-file=][] [--help] 
> [--copyright] [--version] [--list] [ --no-quit ]
> 
> Maybe, it can be :
> Usage: [--no-preferences|--preference-file=][] [--help] 
> [--copyright] [--version] [--list] [ --no-quit ] []
> 
> Moreover, an option can usually be placed anywhere on the command line, 
> shouldn't it? Or at least it should raise an error?

Yes it is a bit confusion (but you could try to read/understand the Pharo code, 
it is not very difficult ;-)

But the idea is that the sub-command controls its own options (like passing 
linker options via the compiler to the linker - git also has global and per sub 
command options, no ?)

--no-quit probably also works for the default command ... (I haven't looked), 
so at that point, the option is consumed already.

> Vincent
> 
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>> Esteban Lorenzano
>> Envoyé : lundi 11 janvier 2016 19:21
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>> 
>> 
>>> On 11 Jan 2016, at 19:06, Sven Van Caekenberghe  wrote:
>>> 
>>> Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 8080'
>>> 
>>> ?
>>> 
>>> I.e. the --no-quit AFTER the eval.
>> 
>> yes, is like that :)
>> 
>>> 
>>> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealcloudser
>>> ver
>>> 
 On 11 Jan 2016, at 18:46, Blondeau Vincent
>>  wrote:
 
 The .sources are in the vm folder.
 
 And, it is working, but without the –no-quit option and this kind of code :
 [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
 
 The –no-quit option seems to have a bad influence…
 
 Can you tell me which packages you installed?
 
 Thanks
 
 Vincent
 
 
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
 de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À :
 Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
 CentOS?
 
 It does work for me in CentOS.
 Are you sure .sources file is in the correct place?
 
 On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
>>  wrote:
 Thanks for your answer.
 
 However, it seems that the server does not start with:
 ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit eval
>> "ZnServer  startOn:  8080."
 Nothing in the terminal and no open port in "netstat -an"
 
 While, this command is writing something in the terminal:
 ./pharo -vm-display-null -vm-sound-null Pharo.image eval "ZnServer
>> startOn:  8080."
 a ZnManagingMultiThreadedServer(running 8080)
 
 Vincent
 
> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03 À :
> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> CentOS?
> 
> 
>> On 11 Jan 2016, at 16:51, Blondeau Vincent
>  wrote:
>> 
>> Hello,
>> 
>> I just wanted to run a latest Pharo image on a CentOS server to run
>> a Zinc
> server.
>> So I did:
>> curl get.pharo.org/50+vm | bash
>> 
>> ./pharo Pharo.image eval “1+1”  evals to 2
>> 
>> But,
>> ./pharo Pharo.image --no-quit eval "ZnServer  startOn:  8080."
>> returns:
>> ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so):
>> libfreetype.so.6: cannot open shared object file: No such file or
>> directory
>> 
>> So the server is not launched…
>> 
>> What are the libs that should be installed on the machine? Should I
>> take
> another VM?
>> 
>> BTW, why a headless image needs a freetype lib?
> 
> Yeah, that should not be the case:
> 
> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html
> 
>> Thanks in advance,
>> 
>> Cheers,
>> Vincent Blondeau
>> 
>> 
 
 
 
 Ce message et les pièces jointes sont confidentiels et réservés à l'usage
>> exclusif de ses destinataires. Il peut également être protégé par le secret
>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
>> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
>> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
>> être recherchée quant au contenu de ce message. Bien que les meilleurs
>> efforts soient faits pour maintenir cette transmission exempte de tout virus,
>> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne
>> saurait être recherchée pour tout dommage résultant d'un virus transmis.
 
 This e-mail and the documents attached are confidential and intended
>> solely for the address

Re: [Pharo-dev] Pharo50 spur works on CentOS?

[Blondeau Vincent]

Indeed, it works. Thanks!

But the command line usage is not clear :
./pharo Pharo.image
Usage: [--no-preferences|--preference-file=][] [--help] 
[--copyright] [--version] [--list] [ --no-quit ]

Maybe, it can be :
Usage: [--no-preferences|--preference-file=][] [--help] 
[--copyright] [--version] [--list] [ --no-quit ] []

Moreover, an option can usually be placed anywhere on the command line, 
shouldn't it? Or at least it should raise an error?

Vincent

> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
> Esteban Lorenzano
> Envoyé : lundi 11 janvier 2016 19:21
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS?
>
>
> > On 11 Jan 2016, at 19:06, Sven Van Caekenberghe  wrote:
> >
> > Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 8080'
> >
> > ?
> >
> > I.e. the --no-quit AFTER the eval.
>
> yes, is like that :)
>
> >
> > http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealcloudser
> > ver
> >
> >> On 11 Jan 2016, at 18:46, Blondeau Vincent
>  wrote:
> >>
> >> The .sources are in the vm folder.
> >>
> >> And, it is working, but without the –no-quit option and this kind of code :
> >> [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait
> >>
> >> The –no-quit option seems to have a bad influence…
> >>
> >> Can you tell me which packages you installed?
> >>
> >> Thanks
> >>
> >> Vincent
> >>
> >>
> >> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> >> de Mariano Martinez Peck Envoyé : lundi 11 janvier 2016 18:27 À :
> >> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> >> CentOS?
> >>
> >> It does work for me in CentOS.
> >> Are you sure .sources file is in the correct place?
> >>
> >> On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent
>  wrote:
> >> Thanks for your answer.
> >>
> >> However, it seems that the server does not start with:
> >> ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit eval
> "ZnServer  startOn:  8080."
> >> Nothing in the terminal and no open port in "netstat -an"
> >>
> >> While, this command is writing something in the terminal:
> >> ./pharo -vm-display-null -vm-sound-null Pharo.image eval "ZnServer
> startOn:  8080."
> >> a ZnManagingMultiThreadedServer(running 8080)
> >>
> >> Vincent
> >>
> >>> -Message d'origine-
> >>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part
> >>> de Sven Van Caekenberghe Envoyé : lundi 11 janvier 2016 17:03 À :
> >>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on
> >>> CentOS?
> >>>
> >>>
>  On 11 Jan 2016, at 16:51, Blondeau Vincent
> >>>  wrote:
> 
>  Hello,
> 
>  I just wanted to run a latest Pharo image on a CentOS server to run
>  a Zinc
> >>> server.
>  So I did:
>  curl get.pharo.org/50+vm | bash
> 
>  ./pharo Pharo.image eval “1+1”  evals to 2
> 
>  But,
>  ./pharo Pharo.image --no-quit eval "ZnServer  startOn:  8080."
>  returns:
>  ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so):
>   libfreetype.so.6: cannot open shared object file: No such file or
>  directory
> 
>  So the server is not launched…
> 
>  What are the libs that should be installed on the machine? Should I
>  take
> >>> another VM?
> 
>  BTW, why a headless image needs a freetype lib?
> >>>
> >>> Yeah, that should not be the case:
> >>>
> >>> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html
> >>>
>  Thanks in advance,
> 
>  Cheers,
>  Vincent Blondeau
> 
> 
> >>
> >>
> >>
> >> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le secret
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
> être recherchée quant au contenu de ce message. Bien que les meilleurs
> efforts soient faits pour maintenir cette transmission exempte de tout virus,
> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne
> saurait être recherchée pour tout dommage résultant d'un virus transmis.
> >>
> >> This e-mail and the documents attached are confidential and intended
> solely for the addressee; it may also be privileged. If you receive this 
> e-mail
> in error, please notify the sender immediately and destroy it. As its 
> integrity
> cannot be secured on the Internet, the Worldline liability cannot be triggered
> for the message content. Although the sender endeavours to maintain a
> computer virus-free network, the sender does not warrant that this
> transmission is virus-free and will not be liable for any damages resulting
> from any virus transmitted.
> >>
> >>
> >>
> >> --
> >> Mariano
> >> http://marianopeck.wordpress.com
> >>
> >>
> >> Ce message et

[Pharo-dev] Shutting down persona.org in November 2016

[Damien Cassou]

Hi,

both pharo.org and pillarhub.pharocloud.com rely on persona.org for
authentication. This service will disappear.

--- Begin Message ---

Hi Everyone,


When the Mozilla Identity team transitioned Persona to community
ownership, we committed resources to operational and security support
throughout 2014 [1], and renewed that commitment for 2015 [2].  Due to
low, declining usage, we are reallocating the project’s dedicated,
ongoing resources and will shut down the persona.org services that we run.

Persona.org and related domains will be taken offline on November 30th,
2016.

If you run a website that relies on Persona, you will need to implement
an alternative login solution for your users.  We have assembled a wiki
page with additional information and guidelines for migration [3], but
here are the important things you need to know:

Between now and November 30th, 2016, Mozilla will continue to support
the Persona service at a maintenance level:

 * Security issues will be resolved in a timely manner and the services
   will be kept online, but we do not expect to develop or deploy any
   new features.

 * Support will continue to be available on the dev-identity mailing
   list [4] and in the #services-dev IRC channel [5].

 * All websites that rely on persona.org will need to migrate to
   another means of authentication during this period.

Beginning on November 30th, 2016, the Persona service hosted by Mozilla
will be decommissioned:

  * All services hosted on the persona.org domain will be shut down.

  * Mozilla will retain control of the persona.org domain and will
not transfer it to a third party.

  * Since the privacy of user data is of utmost importance to Mozilla,
we will destroy all user data stored on the persona.org servers,
and will not transfer it to third parties.

We intentionally designed Persona to expose email addresses rather than
opaque identifiers, which should ease the transition to other systems
that provide verified email addresses.  You can find guidelines on
alternative login solutions on the wiki [3] and we will continue to
update them over the coming year.  We strongly encourage affected teams
to openly discuss and blog about their migrations on the dev-identity
mailing list  so that others can learn from their experience.

Thank you for your support and involvement with Persona. If you have any
questions, please post them to the dev-identity mailing list.


  Ryan


[1]
http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership
[2] https://groups.google.com/forum/#!topic/mozilla.dev.identity/rPIm7GxOeNU
[3]
https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
[4] https://lists.mozilla.org/listinfo/dev-identity
[5] http://irc.mozilla.org/#services-dev
___
Persona-notices mailing list
persona-noti...@mozilla.org
https://mail.mozilla.org/listinfo/persona-notices
--- End Message ---


-- 
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] Atomic commits

[Damien Cassou]

Dimitris Chloupis  writes:

> Most coders that use git rely on a git client of some sort, if you dont
> like guis and prefer emacs, there is also magit that i hear is very good.

totally agree, Magit is awesome.

-- 
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] Understanding Spotter?

[Norbert Hartl]

> Am 12.01.2016 um 09:23 schrieb Sven Van Caekenberghe :
> 
> 
>> On 12 Jan 2016, at 09:19, Christophe Demarey  
>> wrote:
>> 
>> Hi Doru,
>> 
>> Definitely, it would be a great addition.
>> I really like spotter but I still need to open some browser or playground to 
>> search implementors or senders.
>> This feature + a way to perform exact match will avoid to open extra windows 
>> and to loose time.
> 
> Yes, and YES the exact match problem must be fixed (and has been reported 
> before) - it is one of the most frustrating issue with both searching and 
> completion. The shortest closest match must always come first.
> 
+1 (big font)

Norbert

>> Keep pushing,
>> Christophe
>> 
>> 
>> Le 11 janv. 2016 à 23:34, Tudor Girba a écrit :
>> 
>>> Hi,
>>> 
>>> So, I still did not express myself clearly :).
>>> 
>>> #s is not a new shortcut. It’s just a filtering mechanism based on the the 
>>> name of the category. So, you can also write:
>>> 
>>> #s something
>>> #sen something
>>> #senders something
>>> 
>>> On top of this, we are looking for solutions to have a way to use some 
>>> shortcuts.
>>> 
>>> I like the idea of having Cmd+n to add the text #senders to the query text. 
>>> We have to see if this can work.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
 On Jan 11, 2016, at 5:59 PM, stepharo  wrote:
 
 Why #s 
 Senders shortcut is since ages Cmd-n 
 
 Why do you want to force people to remember two different shortcuts. I do 
 not get it?
 
 Sorry but I did not get at all what is & and personnally I'm not sure that 
 I want to understand. 
 
 Stef
 
 Le 10/1/16 22:26, Tudor Girba a écrit :
> Hi Stef,
> 
> Thanks for taking the time. I think I did not express myself properly in 
> the previous mail because we are not really in disagreement :).
> 
> The basic mechanism you talk about exists already in Spotter. Let me 
> explain. When you type: "#e graphs", you will get two examples (and only 
> the example search is being performed).
> 
> 
> 
> This works because the name of the “Examples” category starts with “E”.
> 
> Until now we did not have a top level processor that would search for 
> Senders (only inside a method). So, because of this you could not search 
> for them at the top level. In the meantime Stefan just finished 
> implementing it, the name of the category is Senders. So, you will type 
> “#s something”.
> 
> 
> 
> I now made the category name start with # so that it is closer to the way 
> to query for it. So, when you do not know how, you will just search for 
> “something”. Then you will discover the #Senders category, and then you 
> can learn that you can search for it.
> 
> Now, you seem to be saying that instead of “#s something” you want to 
> type “#n something”. For this we would need to find a solution to 
> reconcile the two. My proposal was to maybe introduce something like “&n 
> something” to distinguish between the string match of a category name and 
> a “shortcut” (I do not know how to call it). I can see how to do this 
> technically, but I still think this is less discoverable then the 
> filtering by the name like described above, and it would be an extra 
> mechanism. We could add this shortcut next to the category name to 
> address this issue. The interesting thing about the shortcut is that we 
> could possibly make it less ambiguous. For example, if you have two 
> categories starting with #S, you will get both when you type “#S 
> something”, which is less ideal for a common case. So, there are pros and 
> cons.
> 
> Now, what is missing is a top level category for References, and I really 
> think we would have what you wanted (and it is a good goal). The cool 
> thing is that we would be solving this problem with a generic mechanism.
> 
> So, what I am suggesting is to invest a bit in categories (#Senders can 
> be integrated now) and then we play with it.
> 
> Is this explanation clearer? Did I misunderstand something? What do you 
> think?
> 
> Cheers,
> Doru
> 
> 
>> On Jan 10, 2016, at 10:23 PM, stepharo  wrote:
>> 
>> Ok my last attempt :( 
>> 
>> When I look for something there are two cases
>> 
>>  - most of the time I NNNOOOWWW*
>>  is it clear? I know I know I know what I look for and I WANT THE FASTER 
>> WAY TO GET IT
>>  => no three clicks and strange navigation.
>> 
>>  I want the sender of this message (not the implementors the sender)
>>  I want that package
>>  I want the references to this class (not the class and the refs that 
>> class)
>>  and I'm ready to learn 
>>  #N for reference 
>>  #n for senders
>>  #m for implementors 
>>  Because they are 

Re: [Pharo-dev] Understanding Spotter?

[Sven Van Caekenberghe]

> On 12 Jan 2016, at 09:19, Christophe Demarey  
> wrote:
> 
> Hi Doru,
> 
> Definitely, it would be a great addition.
> I really like spotter but I still need to open some browser or playground to 
> search implementors or senders.
> This feature + a way to perform exact match will avoid to open extra windows 
> and to loose time.

Yes, and YES the exact match problem must be fixed (and has been reported 
before) - it is one of the most frustrating issue with both searching and 
completion. The shortest closest match must always come first.

> Keep pushing,
> Christophe
> 
> 
> Le 11 janv. 2016 à 23:34, Tudor Girba a écrit :
> 
>> Hi,
>> 
>> So, I still did not express myself clearly :).
>> 
>> #s is not a new shortcut. It’s just a filtering mechanism based on the the 
>> name of the category. So, you can also write:
>> 
>> #s something
>> #sen something
>> #senders something
>> 
>> On top of this, we are looking for solutions to have a way to use some 
>> shortcuts.
>> 
>> I like the idea of having Cmd+n to add the text #senders to the query text. 
>> We have to see if this can work.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jan 11, 2016, at 5:59 PM, stepharo  wrote:
>>> 
>>> Why #s 
>>> Senders shortcut is since ages Cmd-n 
>>> 
>>> Why do you want to force people to remember two different shortcuts. I do 
>>> not get it?
>>> 
>>> Sorry but I did not get at all what is & and personnally I'm not sure that 
>>> I want to understand. 
>>> 
>>> Stef
>>> 
>>> Le 10/1/16 22:26, Tudor Girba a écrit :
 Hi Stef,
 
 Thanks for taking the time. I think I did not express myself properly in 
 the previous mail because we are not really in disagreement :).
 
 The basic mechanism you talk about exists already in Spotter. Let me 
 explain. When you type: "#e graphs", you will get two examples (and only 
 the example search is being performed).
 
 
 
 This works because the name of the “Examples” category starts with “E”.
 
 Until now we did not have a top level processor that would search for 
 Senders (only inside a method). So, because of this you could not search 
 for them at the top level. In the meantime Stefan just finished 
 implementing it, the name of the category is Senders. So, you will type 
 “#s something”.
 
 
 
 I now made the category name start with # so that it is closer to the way 
 to query for it. So, when you do not know how, you will just search for 
 “something”. Then you will discover the #Senders category, and then you 
 can learn that you can search for it.
 
 Now, you seem to be saying that instead of “#s something” you want to type 
 “#n something”. For this we would need to find a solution to reconcile the 
 two. My proposal was to maybe introduce something like “&n something” to 
 distinguish between the string match of a category name and a “shortcut” 
 (I do not know how to call it). I can see how to do this technically, but 
 I still think this is less discoverable then the filtering by the name 
 like described above, and it would be an extra mechanism. We could add 
 this shortcut next to the category name to address this issue. The 
 interesting thing about the shortcut is that we could possibly make it 
 less ambiguous. For example, if you have two categories starting with #S, 
 you will get both when you type “#S something”, which is less ideal for a 
 common case. So, there are pros and cons.
 
 Now, what is missing is a top level category for References, and I really 
 think we would have what you wanted (and it is a good goal). The cool 
 thing is that we would be solving this problem with a generic mechanism.
 
 So, what I am suggesting is to invest a bit in categories (#Senders can be 
 integrated now) and then we play with it.
 
 Is this explanation clearer? Did I misunderstand something? What do you 
 think?
 
 Cheers,
 Doru
 
 
> On Jan 10, 2016, at 10:23 PM, stepharo  wrote:
> 
> Ok my last attempt :( 
> 
> When I look for something there are two cases
> 
>   - most of the time I NNNOOOWWW*
>   is it clear? I know I know I know what I look for and I WANT THE FASTER 
> WAY TO GET IT
>   => no three clicks and strange navigation.
> 
>   I want the sender of this message (not the implementors the sender)
>   I want that package
>   I want the references to this class (not the class and the refs that 
> class)
>   and I'm ready to learn 
>   #N for reference 
>   #n for senders
>   #m for implementors 
>   Because they are the same.
>   #e for example like in the finder
> 
>   - looking around and the system can propose me something
>   and I can navigate and think. 
> 
> But this is ok I just use Spotter to 

Re: [Pharo-dev] Understanding Spotter?

[Christophe Demarey]

Hi Doru,

Definitely, it would be a great addition.
I really like spotter but I still need to open some browser or playground to 
search implementors or senders.
This feature + a way to perform exact match will avoid to open extra windows 
and to loose time.

Keep pushing,
Christophe


Le 11 janv. 2016 à 23:34, Tudor Girba a écrit :

> Hi,
> 
> So, I still did not express myself clearly :).
> 
> #s is not a new shortcut. It’s just a filtering mechanism based on the the 
> name of the category. So, you can also write:
> 
> #s something
> #sen something
> #senders something
> 
> On top of this, we are looking for solutions to have a way to use some 
> shortcuts.
> 
> I like the idea of having Cmd+n to add the text #senders to the query text. 
> We have to see if this can work.
> 
> Cheers,
> Doru
> 
> 
>> On Jan 11, 2016, at 5:59 PM, stepharo  wrote:
>> 
>> Why #s 
>> Senders shortcut is since ages Cmd-n 
>> 
>> Why do you want to force people to remember two different shortcuts. I do 
>> not get it?
>> 
>> Sorry but I did not get at all what is & and personnally I'm not sure that I 
>> want to understand. 
>> 
>> Stef
>> 
>> Le 10/1/16 22:26, Tudor Girba a écrit :
>>> Hi Stef,
>>> 
>>> Thanks for taking the time. I think I did not express myself properly in 
>>> the previous mail because we are not really in disagreement :).
>>> 
>>> The basic mechanism you talk about exists already in Spotter. Let me 
>>> explain. When you type: "#e graphs", you will get two examples (and only 
>>> the example search is being performed).
>>> 
>>> 
>>> 
>>> This works because the name of the “Examples” category starts with “E”.
>>> 
>>> Until now we did not have a top level processor that would search for 
>>> Senders (only inside a method). So, because of this you could not search 
>>> for them at the top level. In the meantime Stefan just finished 
>>> implementing it, the name of the category is Senders. So, you will type “#s 
>>> something”.
>>> 
>>> 
>>> 
>>> I now made the category name start with # so that it is closer to the way 
>>> to query for it. So, when you do not know how, you will just search for 
>>> “something”. Then you will discover the #Senders category, and then you can 
>>> learn that you can search for it.
>>> 
>>> Now, you seem to be saying that instead of “#s something” you want to type 
>>> “#n something”. For this we would need to find a solution to reconcile the 
>>> two. My proposal was to maybe introduce something like “&n something” to 
>>> distinguish between the string match of a category name and a “shortcut” (I 
>>> do not know how to call it). I can see how to do this technically, but I 
>>> still think this is less discoverable then the filtering by the name like 
>>> described above, and it would be an extra mechanism. We could add this 
>>> shortcut next to the category name to address this issue. The interesting 
>>> thing about the shortcut is that we could possibly make it less ambiguous. 
>>> For example, if you have two categories starting with #S, you will get both 
>>> when you type “#S something”, which is less ideal for a common case. So, 
>>> there are pros and cons.
>>> 
>>> Now, what is missing is a top level category for References, and I really 
>>> think we would have what you wanted (and it is a good goal). The cool thing 
>>> is that we would be solving this problem with a generic mechanism.
>>> 
>>> So, what I am suggesting is to invest a bit in categories (#Senders can be 
>>> integrated now) and then we play with it.
>>> 
>>> Is this explanation clearer? Did I misunderstand something? What do you 
>>> think?
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
 On Jan 10, 2016, at 10:23 PM, stepharo  wrote:
 
 Ok my last attempt :( 
 
 When I look for something there are two cases
 
- most of the time I NNNOOOWWW*
is it clear? I know I know I know what I look for and I WANT THE FASTER 
 WAY TO GET IT
=> no three clicks and strange navigation.
 
I want the sender of this message (not the implementors the sender)
I want that package
I want the references to this class (not the class and the refs that 
 class)
and I'm ready to learn 
#N for reference 
#n for senders
#m for implementors 
Because they are the same.
#e for example like in the finder
 
- looking around and the system can propose me something
and I can navigate and think. 
 
 But this is ok I just use Spotter to open the class browser and all the 
 rest I do it with shortcuts.
 I tried to help but I failed.
 
 I will present Spotter as the great tool to open browser because I cannot 
 use it otherwise and 
 nobody around me can show me on the spot something more efficient than a 
 shortcut in a workspace. 
 Or may be I will simply not spend energy doing a videos on Spotter be