date:20160209


Agreed :)
But I was easy to convince :)


Le 9/2/16 19:09, Sven Van Caekenberghe a écrit :

On 09 Feb 2016, at 17:35, Ben Coman  wrote:

On Tue, Feb 9, 2016 at 11:53 PM, stepharo  wrote:


Le 9/2/16 09:58, Sven Van Caekenberghe a écrit :

I can do the integration too, but I need some people to say go ahead.
I vote for replacing everything, there is no need for a plugin.


me too.
Less plugin!

This is a good general philosophy, but we should benchmark in-image
versus plugin so we can make an informed analytical decision on how
much performance we are willing to trade for the convenience of it
being all in-image, and whether we want to maintain a separate CI job
for keeping the plugin tested.  Overriding that is providing a quick
fix so other development is not blocked, which however Guille's
solution seems sufficient for the code freeze of Pharo 5.

 From a comment in

===
Speedwise, in Pharo 5 Spur on my machine, the new implementation is just as 
fast as the primitive, or so it seems:

[ UUIDGenerator next ] bench. "'1,235,356 per second'"

[ UUID nilUUID primMakeUUID ] bench. "'1,237,213 per second'"
===

But even if it were slower (like half or quarter speed), there is a *HUGE* 
benefit to in image code.

C code will always win, performance wise, but if that is all that counts, why 
do we program in Pharo at all.

Please read << Design Principles Behind Smalltalk >>

   http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

Principle 1:

Personal Mastery: If a system is to serve the creative spirit, it must be 
entirely comprehensible to a single individual.

Further on:

Operating System: An operating system is a collection of things that don't fit 
into a language. There shouldn't be one.

Not that this document is an axiom or anything, but it articulates well some 
very relevant principles.

For all these years, you nor I ever knew what took place in that silly plugin 
(1 method), while a confusing UUIDGenerator made some of us believe that it was 
used or somehow identical to the plugin (that was probably not true), now you, 
me and 99% of all other Pharo developers can read clean code.

For me, Pharo is much more than the next scripting language that links to OS 
libraries. Pharo makes software (development) tangible, understandable in one 
single language/environment.

When is the last time you looked into the open source C code of any library of 
your OS, let alone the kernel itself or one of its drivers ? Probably never. 
But in Pharo we can all look under the hood, everywhere, seamlessly.

Sven


cheers -ben




On 09 Feb 2016, at 09:25, Guille Polito 
wrote:

Sven, just to answer your last question. The UUID generation right now
generates the UUID fields like this:

UUIDGenerator>>generateFieldsVersion4

timeLow := self generateRandomBitsOfLength: 32.
timeMid := self generateRandomBitsOfLength: 16.
timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength:
12).
clockSeqHiAndReserved := 16r80 bitOr: (self
generateRandomBitsOfLength: 6).
clockSeqLow := self generateRandomBitsOfLength: 8.
node := self generateRandomBitsOfLength: 48.

So... It's basically completely random. There is no part of the UUID that
is actually based on the node, the clock or the time. It is actually a
random string of bits that are generated using a number from /dev/urandom as
seed (in linux).

Does the mac VM include the plugin? (I do not have a mac any more to test
fast ^^)

I'll work on the integration of NeoUUID now, I hope this is the kind of
issues that got integrated in code-freeze :)

Guille

On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:

Here is a new version, in preparation of possible integration in the
main image:

===
Name: Neo-UUID-SvenVanCaekenberghe.2
Author: SvenVanCaekenberghe
Time: 8 February 2016, 8:33:04.141334 pm
UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
Ancestors: Neo-UUID-SvenVanCaekenberghe.1

Streamline UUID generation

Add a current, shared instance

Added better class and method comments

Add more tests

As suggested by Henrik Johansen, change to a version 0 UUID to indicate
that we follow a custom approach
===

The class comments now reads as follows:

===
I am NeoUUIDGenerator, I generate UUIDs.

An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit
number that can be used for identification purposes. Concretely, a UUID is a
16 element byte array.

The intent of UUIDs is to enable distributed systems to uniquely
identify information without significant central coordination. In this
context the word unique should be taken to mean "practically unique" rather
than "guaranteed unique".
  I generate UUIDs similar, in spirit, to those defined in RFC4122,
though I use version 0 to indicate that I follow none of the defined
versions. This does not matter much, if at all, in practice.

I try to conform to the following aspects:
  - each 'node' (machine, image,

Re: [Pharo-dev] Bloc Documentation

Bloc does not have examples yet.
What classes/methods do you need to be commented first to understand the
system?
On Feb 9, 2016 4:46 AM, "Sean P. DeNigris"  wrote:

> I realize it's a fast-moving work in progress, but what's the best way to
> try
> to understand the system?
>
> For example, I saw class comments, some of which seem to be out of date,
> and
> I no longer see many of the examples I remember from last year - maybe I
> have to load them separately?
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Bloc-Documentation-tp4876448.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Yes, go on. I think it is the easiest.

Right now, to check if a slice is good or not I have to commit, browse
Smalltalkhub's UI, and if it not good I have to delete the mcz manually...

On 02/09/2016 10:10 AM, Sven Van Caekenberghe wrote:

You want me to do it then ?

I don't want us to do double work ...

On 09 Feb 2016, at 10:09, Guillermo Polito wrote:

Sad and true... :'(

On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe wrote:
Beside, you can't make slices ;-)

On 09 Feb 2016, at 09:58, Sven Van Caekenberghe wrote:

I can do the integration too, but I need some people to say go ahead.
I vote for replacing everything, there is no need for a plugin.

On 09 Feb 2016, at 09:25, Guille Polito wrote:

Sven, just to answer your last question. The UUID generation right now
generates the UUID fields like this:

UUIDGenerator>>generateFieldsVersion4

timeLow := self generateRandomBitsOfLength: 32.
timeMid := self generateRandomBitsOfLength: 16.
timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12).
clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 6).
clockSeqLow := self generateRandomBitsOfLength: 8.
node := self generateRandomBitsOfLength: 48.

So... It's basically completely random. There is no part of the UUID that is
actually based on the node, the clock or the time. It is actually a random
string of bits that are generated using a number from /dev/urandom as seed (in
linux).

Does the mac VM include the plugin? (I do not have a mac any more to test fast
^^)

I'll work on the integration of NeoUUID now, I hope this is the kind of issues
that got integrated in code-freeze :)

Guille

On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:

Here is a new version, in preparation of possible integration in the main image:

===
Name: Neo-UUID-SvenVanCaekenberghe.2
Author: SvenVanCaekenberghe
Time: 8 February 2016, 8:33:04.141334 pm
UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
Ancestors: Neo-UUID-SvenVanCaekenberghe.1

Streamline UUID generation

Add a current, shared instance

Added better class and method comments

Add more tests

As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we
follow a custom approach
===

The class comments now reads as follows:

===
I am NeoUUIDGenerator, I generate UUIDs.

An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number
that can be used for identification purposes. Concretely, a UUID is a 16
element byte array.

The intent of UUIDs is to enable distributed systems to uniquely identify information without
significant central coordination. In this context the word unique should be taken to mean
"practically unique" rather than "guaranteed unique".
I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use
version 0 to indicate that I follow none of the defined versions. This does not
matter much, if at all, in practice.

I try to conform to the following aspects:
- each 'node' (machine, image, instance) should generate unique UUIDs
- even when generating UUIDs at a very fast rate, they should remain unique
- be fast and efficient

To achieve this goal, I
- take several aspects into account to generate a unique node ID
- combine a clock, a counter and some random bits
- hold a state, protected for multi user access

I can generate about 500K UUIDs per second.

Implementation:

Although a UUID should be seen as totally opaque, here is the concrete way I
generate one:
- the first 8 bytes are the millisecond clock value with the smallest quantity
first; this means that the later of these 8 bytes will be identical when
generated with small(er) timespans; within the same millisecond, the full first
8 bytes will be identical
- the next 2 bytes represent a counter with safe overflow, held as protected
state inside me; after 2*16 this value will repeat; the counter initalizes with
a random value
- the next 2 bytes are simply random, based on the system PRNG, Random
- the final 4 bytes represent the node ID; the node ID is unique per instance
of me, across OS environments where the image might run; the node ID is the MD5
hash of a string that is the concatenation of several elements (see
#computeNodeIdentifier)
Some bits are set to some predefined value, to indicate the variant and version
(see #setVariantAndVersion:)

Usage:

NeoUUIDGenerator next.
NeoUUIDGenerator current next.
NeoUUIDGenerator new next.

Sharing an instance is more efficient and correct.
Instances should be reset whenever the image comes up.

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

I can do the integration too, but I need some people to say go ahead.
I vote for replacing everything, there is no need for a plugin.

> On 09 Feb 2016, at 09:25, Guille Polito  wrote:
> 
> Sven, just to answer your last question. The UUID generation right now 
> generates the UUID fields like this:
> 
> UUIDGenerator>>generateFieldsVersion4
> 
>timeLow := self generateRandomBitsOfLength: 32.
>timeMid := self generateRandomBitsOfLength: 16.
>timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12).
>clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 6).
>clockSeqLow := self generateRandomBitsOfLength: 8.
>node := self generateRandomBitsOfLength: 48.
> 
> So... It's basically completely random. There is no part of the UUID that is 
> actually based on the node, the clock or the time. It is actually a random 
> string of bits that are generated using a number from /dev/urandom as seed 
> (in linux).
> 
> Does the mac VM include the plugin? (I do not have a mac any more to test 
> fast ^^)
> 
> I'll work on the integration of NeoUUID now, I hope this is the kind of 
> issues that got integrated in code-freeze :)
> 
> Guille
> 
> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
>> Here is a new version, in preparation of possible integration in the main 
>> image:
>> 
>> ===
>> Name: Neo-UUID-SvenVanCaekenberghe.2
>> Author: SvenVanCaekenberghe
>> Time: 8 February 2016, 8:33:04.141334 pm
>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1
>> 
>> Streamline UUID generation
>> 
>> Add a current, shared instance
>> 
>> Added better class and method comments
>> 
>> Add more tests
>> 
>> As suggested by Henrik Johansen, change to a version 0 UUID to indicate that 
>> we follow a custom approach
>> ===
>> 
>> The class comments now reads as follows:
>> 
>> ===
>> I am NeoUUIDGenerator, I generate UUIDs.
>> 
>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number 
>> that can be used for identification purposes. Concretely, a UUID is a 16 
>> element byte array.
>> 
>> The intent of UUIDs is to enable distributed systems to uniquely identify 
>> information without significant central coordination. In this context the 
>> word unique should be taken to mean "practically unique" rather than 
>> "guaranteed unique".
>>  I generate UUIDs similar, in spirit, to those defined in RFC4122, though I 
>> use version 0 to indicate that I follow none of the defined versions. This 
>> does not matter much, if at all, in practice.
>> 
>> I try to conform to the following aspects:
>>  - each 'node' (machine, image, instance) should generate unique UUIDs
>>  - even when generating UUIDs at a very fast rate, they should remain unique
>> - be fast and efficient
>> 
>> To achieve this goal, I
>> - take several aspects into account to generate a unique node ID
>> - combine a clock, a counter and some random bits
>> - hold a state, protected for multi user access
>> 
>> I can generate about 500K UUIDs per second.
>> 
>> Implementation:
>> 
>> Although a UUID should be seen as totally opaque, here is the concrete way I 
>> generate one:
>> - the first 8 bytes are the millisecond clock value with the smallest 
>> quantity first; this means that the later of these 8 bytes will be identical 
>> when generated with small(er) timespans; within the same millisecond, the 
>> full first 8 bytes will be identical
>> - the next 2 bytes represent a counter with safe overflow, held as protected 
>> state inside me; after 2*16 this value will repeat; the counter initalizes 
>> with a random value
>> - the next 2 bytes are simply random, based on the system PRNG, Random
>> - the final 4 bytes represent the node ID; the node ID is unique per 
>> instance of me, across OS environments where the image might run; the node 
>> ID is the MD5 hash of a string that is the concatenation of several elements 
>> (see #computeNodeIdentifier)
>>  Some bits are set to some predefined value, to indicate the variant and 
>> version (see #setVariantAndVersion:)
>> 
>> Usage:
>> 
>>   NeoUUIDGenerator next.
>>   NeoUUIDGenerator current next.
>>   NeoUUIDGenerator new next.
>> 
>> Sharing an instance is more efficient and correct.
>> Instances should be reset whenever the image comes up.
>> 
>> See also:
>> 
>>   http://en.wikipedia.org/wiki/UUID
>>   https://tools.ietf.org/html/rfc4122
>> ===
>> 
>> If we integrate this, I think we should replace the old generator and the 
>> use of the primitive/plugin. But that requires at least some support apart 
>> from me.
>> 
>> And although I think that we should integrate this generator and get rid of 
>> the plugin, I think there is probably an underlying problem here (why did 
>> the generator fail ?) that could be important to find.
>> 
>> Sven
>> 
>>> On 08 Feb 2016, at 10:38, Henrik Johansen  
>>> wrote:
>>> 
 On 08 Feb 2016, at 10:29

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

You want me to do it then ?

I don't want us to do double work ...

> On 09 Feb 2016, at 10:09, Guillermo Polito  wrote:
> 
> Sad and true... :'(
> 
> On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe  wrote:
> Beside, you can't make slices ;-)
> 
> > On 09 Feb 2016, at 09:58, Sven Van Caekenberghe  wrote:
> >
> > I can do the integration too, but I need some people to say go ahead.
> > I vote for replacing everything, there is no need for a plugin.
> >
> >> On 09 Feb 2016, at 09:25, Guille Polito  wrote:
> >>
> >> Sven, just to answer your last question. The UUID generation right now 
> >> generates the UUID fields like this:
> >>
> >> UUIDGenerator>>generateFieldsVersion4
> >>
> >>   timeLow := self generateRandomBitsOfLength: 32.
> >>   timeMid := self generateRandomBitsOfLength: 16.
> >>   timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12).
> >>   clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 
> >> 6).
> >>   clockSeqLow := self generateRandomBitsOfLength: 8.
> >>   node := self generateRandomBitsOfLength: 48.
> >>
> >> So... It's basically completely random. There is no part of the UUID that 
> >> is actually based on the node, the clock or the time. It is actually a 
> >> random string of bits that are generated using a number from /dev/urandom 
> >> as seed (in linux).
> >>
> >> Does the mac VM include the plugin? (I do not have a mac any more to test 
> >> fast ^^)
> >>
> >> I'll work on the integration of NeoUUID now, I hope this is the kind of 
> >> issues that got integrated in code-freeze :)
> >>
> >> Guille
> >>
> >> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
> >>> Here is a new version, in preparation of possible integration in the main 
> >>> image:
> >>>
> >>> ===
> >>> Name: Neo-UUID-SvenVanCaekenberghe.2
> >>> Author: SvenVanCaekenberghe
> >>> Time: 8 February 2016, 8:33:04.141334 pm
> >>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
> >>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1
> >>>
> >>> Streamline UUID generation
> >>>
> >>> Add a current, shared instance
> >>>
> >>> Added better class and method comments
> >>>
> >>> Add more tests
> >>>
> >>> As suggested by Henrik Johansen, change to a version 0 UUID to indicate 
> >>> that we follow a custom approach
> >>> ===
> >>>
> >>> The class comments now reads as follows:
> >>>
> >>> ===
> >>> I am NeoUUIDGenerator, I generate UUIDs.
> >>>
> >>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit 
> >>> number that can be used for identification purposes. Concretely, a UUID 
> >>> is a 16 element byte array.
> >>>
> >>> The intent of UUIDs is to enable distributed systems to uniquely identify 
> >>> information without significant central coordination. In this context the 
> >>> word unique should be taken to mean "practically unique" rather than 
> >>> "guaranteed unique".
> >>> I generate UUIDs similar, in spirit, to those defined in RFC4122, though 
> >>> I use version 0 to indicate that I follow none of the defined versions. 
> >>> This does not matter much, if at all, in practice.
> >>>
> >>> I try to conform to the following aspects:
> >>> - each 'node' (machine, image, instance) should generate unique UUIDs
> >>> - even when generating UUIDs at a very fast rate, they should remain 
> >>> unique
> >>> - be fast and efficient
> >>>
> >>> To achieve this goal, I
> >>> - take several aspects into account to generate a unique node ID
> >>> - combine a clock, a counter and some random bits
> >>> - hold a state, protected for multi user access
> >>>
> >>> I can generate about 500K UUIDs per second.
> >>>
> >>> Implementation:
> >>>
> >>> Although a UUID should be seen as totally opaque, here is the concrete 
> >>> way I generate one:
> >>> - the first 8 bytes are the millisecond clock value with the smallest 
> >>> quantity first; this means that the later of these 8 bytes will be 
> >>> identical when generated with small(er) timespans; within the same 
> >>> millisecond, the full first 8 bytes will be identical
> >>> - the next 2 bytes represent a counter with safe overflow, held as 
> >>> protected state inside me; after 2*16 this value will repeat; the counter 
> >>> initalizes with a random value
> >>> - the next 2 bytes are simply random, based on the system PRNG, Random
> >>> - the final 4 bytes represent the node ID; the node ID is unique per 
> >>> instance of me, across OS environments where the image might run; the 
> >>> node ID is the MD5 hash of a string that is the concatenation of several 
> >>> elements (see #computeNodeIdentifier)
> >>> Some bits are set to some predefined value, to indicate the variant and 
> >>> version (see #setVariantAndVersion:)
> >>>
> >>> Usage:
> >>>
> >>>  NeoUUIDGenerator next.
> >>>  NeoUUIDGenerator current next.
> >>>  NeoUUIDGenerator new next.
> >>>
> >>> Sharing an instance is more efficient and correct.
> >>> Instances should be

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

2016-02-09 Thread Guillermo Polito

Sad and true... :'(

On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe  wrote:

> Beside, you can't make slices ;-)
>
> > On 09 Feb 2016, at 09:58, Sven Van Caekenberghe  wrote:
> >
> > I can do the integration too, but I need some people to say go ahead.
> > I vote for replacing everything, there is no need for a plugin.
> >
> >> On 09 Feb 2016, at 09:25, Guille Polito 
> wrote:
> >>
> >> Sven, just to answer your last question. The UUID generation right now
> generates the UUID fields like this:
> >>
> >> UUIDGenerator>>generateFieldsVersion4
> >>
> >>   timeLow := self generateRandomBitsOfLength: 32.
> >>   timeMid := self generateRandomBitsOfLength: 16.
> >>   timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength:
> 12).
> >>   clockSeqHiAndReserved := 16r80 bitOr: (self
> generateRandomBitsOfLength: 6).
> >>   clockSeqLow := self generateRandomBitsOfLength: 8.
> >>   node := self generateRandomBitsOfLength: 48.
> >>
> >> So... It's basically completely random. There is no part of the UUID
> that is actually based on the node, the clock or the time. It is actually a
> random string of bits that are generated using a number from /dev/urandom
> as seed (in linux).
> >>
> >> Does the mac VM include the plugin? (I do not have a mac any more to
> test fast ^^)
> >>
> >> I'll work on the integration of NeoUUID now, I hope this is the kind of
> issues that got integrated in code-freeze :)
> >>
> >> Guille
> >>
> >> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
> >>> Here is a new version, in preparation of possible integration in the
> main image:
> >>>
> >>> ===
> >>> Name: Neo-UUID-SvenVanCaekenberghe.2
> >>> Author: SvenVanCaekenberghe
> >>> Time: 8 February 2016, 8:33:04.141334 pm
> >>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
> >>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1
> >>>
> >>> Streamline UUID generation
> >>>
> >>> Add a current, shared instance
> >>>
> >>> Added better class and method comments
> >>>
> >>> Add more tests
> >>>
> >>> As suggested by Henrik Johansen, change to a version 0 UUID to
> indicate that we follow a custom approach
> >>> ===
> >>>
> >>> The class comments now reads as follows:
> >>>
> >>> ===
> >>> I am NeoUUIDGenerator, I generate UUIDs.
> >>>
> >>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit
> number that can be used for identification purposes. Concretely, a UUID is
> a 16 element byte array.
> >>>
> >>> The intent of UUIDs is to enable distributed systems to uniquely
> identify information without significant central coordination. In this
> context the word unique should be taken to mean "practically unique" rather
> than "guaranteed unique".
> >>> I generate UUIDs similar, in spirit, to those defined in RFC4122,
> though I use version 0 to indicate that I follow none of the defined
> versions. This does not matter much, if at all, in practice.
> >>>
> >>> I try to conform to the following aspects:
> >>> - each 'node' (machine, image, instance) should generate unique UUIDs
> >>> - even when generating UUIDs at a very fast rate, they should remain
> unique
> >>> - be fast and efficient
> >>>
> >>> To achieve this goal, I
> >>> - take several aspects into account to generate a unique node ID
> >>> - combine a clock, a counter and some random bits
> >>> - hold a state, protected for multi user access
> >>>
> >>> I can generate about 500K UUIDs per second.
> >>>
> >>> Implementation:
> >>>
> >>> Although a UUID should be seen as totally opaque, here is the concrete
> way I generate one:
> >>> - the first 8 bytes are the millisecond clock value with the smallest
> quantity first; this means that the later of these 8 bytes will be
> identical when generated with small(er) timespans; within the same
> millisecond, the full first 8 bytes will be identical
> >>> - the next 2 bytes represent a counter with safe overflow, held as
> protected state inside me; after 2*16 this value will repeat; the counter
> initalizes with a random value
> >>> - the next 2 bytes are simply random, based on the system PRNG, Random
> >>> - the final 4 bytes represent the node ID; the node ID is unique per
> instance of me, across OS environments where the image might run; the node
> ID is the MD5 hash of a string that is the concatenation of several
> elements (see #computeNodeIdentifier)
> >>> Some bits are set to some predefined value, to indicate the variant
> and version (see #setVariantAndVersion:)
> >>>
> >>> Usage:
> >>>
> >>>  NeoUUIDGenerator next.
> >>>  NeoUUIDGenerator current next.
> >>>  NeoUUIDGenerator new next.
> >>>
> >>> Sharing an instance is more efficient and correct.
> >>> Instances should be reset whenever the image comes up.
> >>>
> >>> See also:
> >>>
> >>>  http://en.wikipedia.org/wiki/UUID
> >>>  https://tools.ietf.org/html/rfc4122
> >>> ===
> >>>
> >>> If we integrate this, I think we should replace the old generator and
> the use of the primitive/plugin. But that

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Sven, just to answer your last question. The UUID generation right now
generates the UUID fields like this:

UUIDGenerator>>generateFieldsVersion4

timeLow := self generateRandomBitsOfLength: 32.
timeMid := self generateRandomBitsOfLength: 16.
timeHiAndVersion := 16r4000 bitOr: (self
generateRandomBitsOfLength: 12).
clockSeqHiAndReserved := 16r80 bitOr: (self
generateRandomBitsOfLength: 6).

clockSeqLow := self generateRandomBitsOfLength: 8.
node := self generateRandomBitsOfLength: 48.

So... It's basically completely random. There is no part of the UUID
that is actually based on the node, the clock or the time. It is
actually a random string of bits that are generated using a number from
/dev/urandom as seed (in linux).

Does the mac VM include the plugin? (I do not have a mac any more to
test fast ^^)

I'll work on the integration of NeoUUID now, I hope this is the kind of
issues that got integrated in code-freeze :)

Guille

On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:

Here is a new version, in preparation of possible integration in the main image:

===
Name: Neo-UUID-SvenVanCaekenberghe.2
Author: SvenVanCaekenberghe
Time: 8 February 2016, 8:33:04.141334 pm
UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
Ancestors: Neo-UUID-SvenVanCaekenberghe.1

Streamline UUID generation

Add a current, shared instance

Added better class and method comments

Add more tests

As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we
follow a custom approach
===

The class comments now reads as follows:

===
I am NeoUUIDGenerator, I generate UUIDs.

An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number
that can be used for identification purposes. Concretely, a UUID is a 16
element byte array.

I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use version 0 to indicate that I follow none of the defined versions. This does not matter much, if at all, in practice.

To achieve this goal, I
- take several aspects into account to generate a unique node ID
- combine a clock, a counter and some random bits
- hold a state, protected for multi user access

I can generate about 500K UUIDs per second.

Implementation:

Some bits are set to some predefined value, to indicate the variant and version (see #setVariantAndVersion:)

Usage:

NeoUUIDGenerator next.
NeoUUIDGenerator current next.
NeoUUIDGenerator new next.

Sharing an instance is more efficient and correct.
Instances should be reset whenever the image comes up.

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Beside, you can't make slices ;-)

> On 09 Feb 2016, at 09:58, Sven Van Caekenberghe  wrote:
> 
> I can do the integration too, but I need some people to say go ahead.
> I vote for replacing everything, there is no need for a plugin.
> 
>> On 09 Feb 2016, at 09:25, Guille Polito  wrote:
>> 
>> Sven, just to answer your last question. The UUID generation right now 
>> generates the UUID fields like this:
>> 
>> UUIDGenerator>>generateFieldsVersion4
>> 
>>   timeLow := self generateRandomBitsOfLength: 32.
>>   timeMid := self generateRandomBitsOfLength: 16.
>>   timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12).
>>   clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 6).
>>   clockSeqLow := self generateRandomBitsOfLength: 8.
>>   node := self generateRandomBitsOfLength: 48.
>> 
>> So... It's basically completely random. There is no part of the UUID that is 
>> actually based on the node, the clock or the time. It is actually a random 
>> string of bits that are generated using a number from /dev/urandom as seed 
>> (in linux).
>> 
>> Does the mac VM include the plugin? (I do not have a mac any more to test 
>> fast ^^)
>> 
>> I'll work on the integration of NeoUUID now, I hope this is the kind of 
>> issues that got integrated in code-freeze :)
>> 
>> Guille
>> 
>> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
>>> Here is a new version, in preparation of possible integration in the main 
>>> image:
>>> 
>>> ===
>>> Name: Neo-UUID-SvenVanCaekenberghe.2
>>> Author: SvenVanCaekenberghe
>>> Time: 8 February 2016, 8:33:04.141334 pm
>>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
>>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1
>>> 
>>> Streamline UUID generation
>>> 
>>> Add a current, shared instance
>>> 
>>> Added better class and method comments
>>> 
>>> Add more tests
>>> 
>>> As suggested by Henrik Johansen, change to a version 0 UUID to indicate 
>>> that we follow a custom approach
>>> ===
>>> 
>>> The class comments now reads as follows:
>>> 
>>> ===
>>> I am NeoUUIDGenerator, I generate UUIDs.
>>> 
>>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number 
>>> that can be used for identification purposes. Concretely, a UUID is a 16 
>>> element byte array.
>>> 
>>> The intent of UUIDs is to enable distributed systems to uniquely identify 
>>> information without significant central coordination. In this context the 
>>> word unique should be taken to mean "practically unique" rather than 
>>> "guaranteed unique".
>>> I generate UUIDs similar, in spirit, to those defined in RFC4122, though I 
>>> use version 0 to indicate that I follow none of the defined versions. This 
>>> does not matter much, if at all, in practice.
>>> 
>>> I try to conform to the following aspects:
>>> - each 'node' (machine, image, instance) should generate unique UUIDs
>>> - even when generating UUIDs at a very fast rate, they should remain unique
>>> - be fast and efficient
>>> 
>>> To achieve this goal, I
>>> - take several aspects into account to generate a unique node ID
>>> - combine a clock, a counter and some random bits
>>> - hold a state, protected for multi user access
>>> 
>>> I can generate about 500K UUIDs per second.
>>> 
>>> Implementation:
>>> 
>>> Although a UUID should be seen as totally opaque, here is the concrete way 
>>> I generate one:
>>> - the first 8 bytes are the millisecond clock value with the smallest 
>>> quantity first; this means that the later of these 8 bytes will be 
>>> identical when generated with small(er) timespans; within the same 
>>> millisecond, the full first 8 bytes will be identical
>>> - the next 2 bytes represent a counter with safe overflow, held as 
>>> protected state inside me; after 2*16 this value will repeat; the counter 
>>> initalizes with a random value
>>> - the next 2 bytes are simply random, based on the system PRNG, Random
>>> - the final 4 bytes represent the node ID; the node ID is unique per 
>>> instance of me, across OS environments where the image might run; the node 
>>> ID is the MD5 hash of a string that is the concatenation of several 
>>> elements (see #computeNodeIdentifier)
>>> Some bits are set to some predefined value, to indicate the variant and 
>>> version (see #setVariantAndVersion:)
>>> 
>>> Usage:
>>> 
>>>  NeoUUIDGenerator next.
>>>  NeoUUIDGenerator current next.
>>>  NeoUUIDGenerator new next.
>>> 
>>> Sharing an instance is more efficient and correct.
>>> Instances should be reset whenever the image comes up.
>>> 
>>> See also:
>>> 
>>>  http://en.wikipedia.org/wiki/UUID
>>>  https://tools.ietf.org/html/rfc4122
>>> ===
>>> 
>>> If we integrate this, I think we should replace the old generator and the 
>>> use of the primitive/plugin. But that requires at least some support apart 
>>> from me.
>>> 
>>> And although I think that we should integrate this generator and get rid of 
>>> the plugin, I think there is probably an underlying

Re: [Pharo-dev] Bloc Documentation

2016-02-09 Thread Esteban Lorenzano


> On 09 Feb 2016, at 09:15, Aliaksei Syrel  wrote:
> 
> Bloc does not have examples yet.
> What classes/methods do you need to be commented first to understand the 
> system?
> 
mmm… that’s a bad question because I would answer “all of them”, but I 
understand you want to do a step to make easy for us to understand so my answer 
has to be “the important ones”, but since there is no documentation/class 
comments/examples I just cannot know which  them, so is up to you (and people 
doing bloc) to tell us which are “the important ones”… by adding class comments 
and examples! :D

Esteban

> On Feb 9, 2016 4:46 AM, "Sean P. DeNigris"  > wrote:
> I realize it's a fast-moving work in progress, but what's the best way to try
> to understand the system?
> 
> For example, I saw class comments, some of which seem to be out of date, and
> I no longer see many of the examples I remember from last year - maybe I
> have to load them separately?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Bloc-Documentation-tp4876448.html 
> 
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Re: [Pharo-dev] Bloc Documentation

On Tue, Feb 9, 2016 at 11:39 AM, Esteban Lorenzano 
wrote:

> mmm… that’s a bad question because I would answer “all of them”, but I
> understand you want to do a step to make easy for us to understand so my
> answer has to be “the important ones”, but since there is no
> documentation/class comments/examples I just cannot know which  them, so is
> up to you (and people doing bloc) to tell us which are “the important
> ones”… by adding class comments and examples! :D

It depends :) There are a lot of obvious places in Bloc that do not
necessarily need documentation to understand them. For example
events. BlLostMouseFocusEvent does not need any "serious" documentation in
first place. If you want to find out when it is being sent it is much
faster to do cmd+n then read long class doc. I don't want to say that we
don't need documentation.. I just want to say that with amount of available
man-power we can't instantly add documentation to everything in bloc.

So I'm asking: what parts of Bloc do you find especially complicated to
understand. so we could concentrate on them? Root class BlElement(methods)
has good doc, so please use it to start your exploration journey.

Cheers,
Alex

Re: [Pharo-dev] Getting coherent shortcuts

2016-02-09 Thread Cyril Ferlicot Delbecque



On 09/02/2016 15:50, Guille Polito wrote:
> Hi all,
> 
> Since a week, I'm back to using linux (debian) due to a new job. And it
> became S evident that the shortcuts are wrongly configured, that I
> actually cannot work!
> 
> Sometimes windows are closed with ctrl w, sometimes with alt w. Nautilus
> is used with alt, playgrounds with ctrl...
> 
> So, since today I was able to commit again, I decided to make a couple
> of slices/new configurations fixing the majority of shortcuts in the
> image. Like this, mac shortcuts will remain in cmd, but linux and
> windows shortcuts will be with ctrl, as expected by the vast majority of
> users :). The changes I made should fix 97.8882% of the shortcut
> experience in linux and windows, without degrading the one in mac. Of
> course, if you see any glitch, just tell.
> 
> I had to touch several packages, which some are not in the Pharo
> repository. For this I prepared several issues for the monkey:
> 
> *Slice -
> SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2
> 
> https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-some-others-ctrl
> 
> 
> *Rubric - 2.7
> https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcuts-use-alt-some-others-ctrl
> 
> 
> *DependencyAnalyzer - 1.15
> https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-some-shortcuts-use-alt-some-others-ctrl
> 
> 
> *FastTable - 0.10
> https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shortcuts-use-alt-some-others-ctrl
> 
> 
> *TxText - 2.12.2
> https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcuts-use-alt-some-others-ctrl
> 
> 
> 
> Also, I did some changes in Glamour and GTSpotter, but I have no
> permissions to commit there. How do we do to commit in those packages?
> Should I ask for permissions or is there any other process in place?
> 
> Guille
> 

You even made the configurations yourself! Perfect :)

Thank you!

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Getting coherent shortcuts

Hi all,

Since a week, I'm back to using linux (debian) due to a new job. And it
became S evident that the shortcuts are wrongly configured, that I
actually cannot work!

Sometimes windows are closed with ctrl w, sometimes with alt w. Nautilus
is used with alt, playgrounds with ctrl...

So, since today I was able to commit again, I decided to make a couple
of slices/new configurations fixing the majority of shortcuts in the
image. Like this, mac shortcuts will remain in cmd, but linux and
windows shortcuts will be with ctrl, as expected by the vast majority of
users :). The changes I made should fix 97.8882% of the shortcut
experience in linux and windows, without degrading the one in mac. Of
course, if you see any glitch, just tell.

I had to touch several packages, which some are not in the Pharo
repository. For this I prepared several issues for the monkey:

*Slice -
SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2

https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-some-others-ctrl

*Rubric - 2.7
https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*DependencyAnalyzer - 1.15
https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*FastTable - 0.10
https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*TxText - 2.12.2
https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcuts-use-alt-some-others-ctrl

Also, I did some changes in Glamour and GTSpotter, but I have no
permissions to commit there. How do we do to commit in those packages?
Should I ask for permissions or is there any other process in place?

Guille

Re: [Pharo-dev] Getting coherent shortcuts

2016-02-09 Thread Nicolai Hess

2016-02-09 15:50 GMT+01:00 Guille Polito :

> Hi all,
>
> Since a week, I'm back to using linux (debian) due to a new job. And it
> became S evident that the shortcuts are wrongly configured, that I
> actually cannot work!
>
> Sometimes windows are closed with ctrl w, sometimes with alt w. Nautilus
> is used with alt, playgrounds with ctrl...
>
> So, since today I was able to commit again, I decided to make a couple of
> slices/new configurations fixing the majority of shortcuts in the image.
> Like this, mac shortcuts will remain in cmd, but linux and windows
> shortcuts will be with ctrl, as expected by the vast majority of users :).
> The changes I made should fix 97.8882% of the shortcut experience in linux
> and windows, without degrading the one in mac. Of course, if you see any
> glitch, just tell.
>
> I had to touch several packages, which some are not in the Pharo
> repository. For this I prepared several issues for the monkey:
>
> *Slice -
> SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2
>
> https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-some-others-ctrl
>
> *Rubric - 2.7
>
> https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcuts-use-alt-some-others-ctrl
>

With this, ctrl+m for sendersOfIt will not work in Rubric components in
Nautilus / MessageBrowser for windows, because the current windows (spur-)
vm
does not recognized ctrl+m as a keachar event.




>
> *DependencyAnalyzer - 1.15
>
> https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-some-shortcuts-use-alt-some-others-ctrl
>
> *FastTable - 0.10
>
> https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shortcuts-use-alt-some-others-ctrl
>
> *TxText - 2.12.2
>
> https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcuts-use-alt-some-others-ctrl
>
>
> Also, I did some changes in Glamour and GTSpotter, but I have no
> permissions to commit there. How do we do to commit in those packages?
> Should I ask for permissions or is there any other process in place?
>
> Guille
>
>

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

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

[Pharo-dev] [pharo-project/pharo-core] 94b774: 50573

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 94b7749d57060689f8e2e88dbf472ce504f15289
  
https://github.com/pharo-project/pharo-core/commit/94b7749d57060689f8e2e88dbf472ce504f15289
  Author: Jenkins Build Server 
  Date:   2016-02-09 (Tue, 09 Feb 2016)

  Changed paths:
A 
Rubric.package/RubShoutStylerDecorator.class/instance/composition/recomposeFrom_to_delta_.st
M Rubric.package/RubTextComposer.class/instance/private 
composition/recomposeFrom_to_delta_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50572.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50573.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50572.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50573.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
System-Sources.package/ChangesLog.class/instance/event-listening/registerToAnnouncements.st

  Log Message:
  ---
  50573
17551 random fail on RubTextComposer>>recomposeFrom:to:delta:
https://pharo.fogbugz.com/f/cases/17551

17549 ChangesLog should subscribe weakly to SystemAnnouncer
https://pharo.fogbugz.com/f/cases/17549

17538 Remove dead SystemAnnouncer subscriptions
https://pharo.fogbugz.com/f/cases/17538

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

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

2016-02-09 Thread Peter Uhnák

The widget becomes available only once the UI is built, however when you
are configuring Spec it is not yet built so it's not available and thus the
ugly nil check (well, one of the reasons anyway).

This is a big problem with morphic/spec ui elements. You never know for sure
>> what code this
>> self update ---> search through all (dynamicly added) dependents and
>> notify
>> will finally call.
>>
>  I don't think there is any way around it. You have to decouple view(s)
> from model(s), and, hence have those propagation constraints by way of
> notifications.


About a year ago we were discussing this with Stef and one of the options
was to expose all value holders (which has happened in the meantime) and
have adapter just connect Spec with Morphic.
This is a bit older and needs updating, but I think it still holds somewhat
https://gist.github.com/peteruhnak/0fc752d0cea9bde69315 (the idea was to to
connect Morphic directly to observe Spec and therefore not have Adapter at
all during runtime).

Peter


On Tue, Feb 9, 2016 at 1:46 PM, stepharo  wrote:

> Hi nicolai
>
> I agree. I will have a look at the Calipso experience of Alain.
> Because may be Calipso + Spec layout format would be much nicer.
> Did you look at it?
> Alain just brainstormed but this is interesting for thinking.
>
> Stef
>
> What I hate also is that the
>
>  AbstractApdate>>update: aSymbol
>
> self changed: aSymbol
>
> This is a bit terrible because the adpater should not exist at runtime
> and adapter should just encapsulate how to create and set the
> communication
> between the model and the view. Now it is in the middle and this is not
> good.
>
> stef
>
>
> Le 8/2/16 11:31, Nicolai Hess a écrit :
>
>
>
> 2016-02-08 10:37 GMT+01:00 stepharo :
>
>> Hi guys
>>
>> I should say that I'm sick (gift from my little boy) so may be this is
>> obvious.
>>
>> I'm looking at the code of Spec and I hate this code :)
>>
>> widgetDo: aBlock
>>
>> ^ self widget ifNotNil: aBlock
>>
>>
>> I do not see why widgetDo: has to test for nil
>> So I transformed
>>
>> widgetDo: aBlock
>>
>> ^ self widget ifNotNil: aBlock
>>
>> into
>>
>>
>> widgetDo: aBlock
>>
>> ^ aBlock cull: self widget
>>
>> BTW I hate all the cull: call. They are connected with sloppiness). It is
>> far too easy to use cull:
>> I do not know how many arguments, I do not care I use cull:
>> cull: is slow slow and help producing messing API.
>>
>> And it broke. The methodBrowser example did not work anymore and many
>> others.
>> Debugger felt down
>> I feel sad. Now my brain is dead so I cannot concentrate more.
>>
>>
>> Stef
>>
>>
> This is a big problem with morphic/spec ui elements. You never know for
> sure
> what code this
> self update ---> search through all (dynamicly added) dependents and notify
> will finally call.
> In this example we are about to *built* the widgets and in this run , we
> change a component that
> will update all dependents goes back and forth between model, adapter and
> widget. And all
> before the widget is actually accessible for the widgetDo: call.
>
> (and, REALLY we need to clean this up. This is really bad code if we
> announce a textChanged announcement for
> a text component, if we *initialize* an *empty textcomponent* with an
> *empty text*!).
>
>
>
>

Re: [Pharo-dev] Bloc Documentation


On 09/02/16 11:53, Aliaksei Syrel wrote:

So I'm asking: what parts of Bloc do you find especially complicated to
understand. so we could concentrate on them? Root class
BlElement(methods) has good doc, so please use it to start your
exploration journey.


A lot of confusing comes from BlMorphXX things still being around all 
over the place. I prefer good examples as a starting point. Making 
Bloc-DragPanels work again?


Stephan

Re: [Pharo-dev] Some questions

2016-02-09 Thread Esteban Lorenzano


> On 09 Feb 2016, at 13:38, Stéphane Ducasse  wrote:
> 
>> 
>> p.s. To all who see this email: Bloc needs more complains
>> 
>> :)
>> 
>> Some random thoughts:
>> BlWorldElement and BlSpaceElement sounds like this is for elements *in* 
>> space or *in* world, not like
>> *the* WorldElement.
> 
> I agree
> I think that BlWorldEllement should be BlWorld and BlSpaceElement should be 
> BlSpace

in general, using “element” seems to be just as using “object” :P

> 
> 
>> Looking at BlElement definition:
>> 
>> Object subclass: #BlElement
>> uses: TBlPropertiesOwner
>> instanceVariableNames: 'ownerReference visible properties 
>> layoutProperties zIndex spaceReference eventListener errorOnDraw locked 
>> extent shape layoutStrategy children nextElementReference 
>> previousElementReference measuredExtent requestingLayout 
>> oldExtentMeasurementSpec transformation'
>> classVariableNames: ''
>> package: 'Bloc-Core-!Core-Basic'
>> 
>> The properties visible and locked, somehow they don't fit in the structure a 
>> BlElement provides, I don't know why but it looks strange. 
>> zIndex: what defines the order of elements, its zIndex or *are*  they in 
>> different Bloc-Layers and a zIndex would be superfluous?
>> 
>> Are measuredExtent requestingLayout oldExtentMeasurementSpec attributes, a 
>> BlElement always has and needs, or are they only used during layouting?
>> 
>> children ownerReference nextElementReference previousElementReference, would 
>> it make sense to encapsulate this in one new class, something like a 
>> treeNode/structureNode?
>> 
>> 
>>  
>> 
>> Cheers,
>> Alex
>> 
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr 
> http://www.synectique.eu  / http://www.pharo.org 
>  
> 03 59 35 87 52
> Assistant: Julie Jonas 
> 03 59 57 78 50
> 03 59 35 86 16
> 
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France

Re: [Pharo-dev] Bloc Documentation


Please add a comment in the method stating it.
People are not reading your mind.

Stef

Le 9/2/16 13:25, Aliaksei Syrel a écrit :


formerOwner: anElementOrNil
"Set my former or remove property of argument is nil"

anElementOrNil
ifNil: [ self removeProperty: #formerOwner ]
ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]


I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, 
ctrl+v)
Basically it should be removed after reimplementation of drag 
mechanism. Current one was copied from morphic to support compatibility.
We will need to find better solution. Drag is not so easy to do 
right. Help from community is appreciated :)


Cheers,
Alex

On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont > wrote:


formerOwner: anElementOrNil
"Set my former or remove property of argument is nil"

anElementOrNil
ifNil: [ self removeProperty: #formerOwner ]
ifNotNil: [ self setProperty: #formerOwner
toValue: anElementOrNil ]

I'd prefer to see a #setProperty:toValueOrRemove: there,
as that pattern is used a lot.

Stephan

Re: [Pharo-dev] Bloc Documentation

>
> A lot of confusing comes from BlMorphXX things still being around all over
> the place. I prefer good examples as a starting point. Making
> Bloc-DragPanels work again?

Exactly! :) We just physically can't do everything so fast. It will come!
Patience, patience :)
Nevertheless pointing to issues is very helpful, keep doing it

Cheers,
Alex

On Tue, Feb 9, 2016 at 1:24 PM, Stephan Eggermont  wrote:

> On 09/02/16 11:53, Aliaksei Syrel wrote:
>
>> So I'm asking: what parts of Bloc do you find especially complicated to
>> understand. so we could concentrate on them? Root class
>> BlElement(methods) has good doc, so please use it to start your
>> exploration journey.
>>
>
> A lot of confusing comes from BlMorphXX things still being around all over
> the place. I prefer good examples as a starting point. Making
> Bloc-DragPanels work again?
>
> Stephan
>
>
>
>

Re: [Pharo-dev] Bloc Documentation

>
> Please add a comment in the method stating it.
> People are not reading your mind.


I know :) I'm arguing that some classes/method could wait. We need to
concentrate on most important ones. And then come to the rest.

On Tue, Feb 9, 2016 at 1:52 PM, stepharo  wrote:

> Please add a comment in the method stating it.
> People are not reading your mind.
>
> Stef
>
> Le 9/2/16 13:25, Aliaksei Syrel a écrit :
>
> formerOwner: anElementOrNil
>> "Set my former or remove property of argument is nil"
>>
>> anElementOrNil
>> ifNil: [ self removeProperty: #formerOwner ]
>> ifNotNil: [ self setProperty: #formerOwner toValue:
>> anElementOrNil ]
>
>
> I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c,
> ctrl+v)
> Basically it should be removed after reimplementation of drag
> mechanism. Current one was copied from morphic to support compatibility.
> We will need to find better solution. Drag is not so easy to do
> right. Help from community is appreciated :)
>
> Cheers,
> Alex
>
> On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont < 
> step...@stack.nl> wrote:
>
>> formerOwner: anElementOrNil
>> "Set my former or remove property of argument is nil"
>>
>> anElementOrNil
>> ifNil: [ self removeProperty: #formerOwner ]
>> ifNotNil: [ self setProperty: #formerOwner toValue:
>> anElementOrNil ]
>>
>> I'd prefer to see a #setProperty:toValueOrRemove: there,
>> as that pattern is used a lot.
>>
>> Stephan
>>
>>
>>
>
>

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name


NNNDDD! It looks I found the real cause of this!

- I tested an image pre-new session manager, and an image post-new 
session manager. The issue only appeared in the latter.


- Checking, it seems that UUIDGenerator is not subscribed to the new 
startup list. This means that the UUIDGenerator is not being 
reinitialized on every startup. This means, moreover, that every person 
that is loading the latest Pharo image is using the same UUIDGenerator 
instance, with the same random seed => same generated UUIDs.


So, adding UUIDGenerator to the list would be the simplest solution and 
the integration of NeoUUIDGenerator can be moved to Pharo6 maybe.


However, now that we found that something was missing in the startup 
list, we should check for others...


Guille

On 02/09/2016 10:36 AM, Guille Polito wrote:

Yes, go on. I think it is the easiest.

Right now, to check if a slice is good or not I have to commit, browse 
Smalltalkhub's UI, and if it not good I have to delete the mcz 
manually...


On 02/09/2016 10:10 AM, Sven Van Caekenberghe wrote:

You want me to do it then ?

I don't want us to do double work ...

On 09 Feb 2016, at 10:09, Guillermo Polito 
 wrote:


Sad and true... :'(

On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe 
 wrote:

Beside, you can't make slices ;-)


On 09 Feb 2016, at 09:58, Sven Van Caekenberghe  wrote:

I can do the integration too, but I need some people to say go ahead.
I vote for replacing everything, there is no need for a plugin.

On 09 Feb 2016, at 09:25, Guille Polito 
 wrote:


Sven, just to answer your last question. The UUID generation right 
now generates the UUID fields like this:


UUIDGenerator>>generateFieldsVersion4

   timeLow := self generateRandomBitsOfLength: 32.
   timeMid := self generateRandomBitsOfLength: 16.
   timeHiAndVersion := 16r4000 bitOr: (self 
generateRandomBitsOfLength: 12).
   clockSeqHiAndReserved := 16r80 bitOr: (self 
generateRandomBitsOfLength: 6).

   clockSeqLow := self generateRandomBitsOfLength: 8.
   node := self generateRandomBitsOfLength: 48.

So... It's basically completely random. There is no part of the 
UUID that is actually based on the node, the clock or the time. It 
is actually a random string of bits that are generated using a 
number from /dev/urandom as seed (in linux).


Does the mac VM include the plugin? (I do not have a mac any more 
to test fast ^^)


I'll work on the integration of NeoUUID now, I hope this is the 
kind of issues that got integrated in code-freeze :)


Guille

On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
Here is a new version, in preparation of possible integration in 
the main image:


===
Name: Neo-UUID-SvenVanCaekenberghe.2
Author: SvenVanCaekenberghe
Time: 8 February 2016, 8:33:04.141334 pm
UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
Ancestors: Neo-UUID-SvenVanCaekenberghe.1

Streamline UUID generation

Add a current, shared instance

Added better class and method comments

Add more tests

As suggested by Henrik Johansen, change to a version 0 UUID to 
indicate that we follow a custom approach

===

The class comments now reads as follows:

===
I am NeoUUIDGenerator, I generate UUIDs.

An RFC4122 Universally Unique Identifier (UUID) is an opaque 
128-bit number that can be used for identification purposes. 
Concretely, a UUID is a 16 element byte array.


The intent of UUIDs is to enable distributed systems to uniquely 
identify information without significant central coordination. In 
this context the word unique should be taken to mean "practically 
unique" rather than "guaranteed unique".
I generate UUIDs similar, in spirit, to those defined in RFC4122, 
though I use version 0 to indicate that I follow none of the 
defined versions. This does not matter much, if at all, in practice.


I try to conform to the following aspects:
- each 'node' (machine, image, instance) should generate unique 
UUIDs
- even when generating UUIDs at a very fast rate, they should 
remain unique

- be fast and efficient

To achieve this goal, I
- take several aspects into account to generate a unique node ID
- combine a clock, a counter and some random bits
- hold a state, protected for multi user access

I can generate about 500K UUIDs per second.

Implementation:

Although a UUID should be seen as totally opaque, here is the 
concrete way I generate one:
- the first 8 bytes are the millisecond clock value with the 
smallest quantity first; this means that the later of these 8 
bytes will be identical when generated with small(er) timespans; 
within the same millisecond, the full first 8 bytes will be 
identical
- the next 2 bytes represent a counter with safe overflow, held 
as protected state inside me; after 2*16 this value will repeat; 
the counter initalizes with a random value
- the next 2 bytes are simply random, based on the system PRNG, 
Random
- the final 4 bytes represent the node ID; the node ID is

Re: [Pharo-dev] Some questions

>
> The properties visible and locked, somehow they don't fit in the structure
> a BlElement provides, I don't know why but it looks strange.
> zIndex: what defines the order of elements, its zIndex or *are*  they in
> different Bloc-Layers and a zIndex would be superfluous?

Don't worry they are deprecated :) That is why all methods related to
locking/visibility/sticking packaged in *Bloc-Core-*Ugly*.
>From zIndex: setter:

> self flag: 'It should not be just magic number but maybe elevation
>   or z position in pixels or any other material value'.

I was planning to replace it with something stored layout properties.

Are measuredExtent requestingLayout oldExtentMeasurementSpec attributes, a
> BlElement always has and needs, or are they only used during layouting?

only during layout. They should be moved to layout strategy inst vars.
Thanks for pointing :)

children ownerReference nextElementReference previousElementReference,
> would it make sense to encapsulate this in one new class, something like a
> treeNode/structureNode?

I agree. Don't like so many inst vars in BlElement. They should be somehow
encapsulated in the end. Nice catch!

BlWorldElement and BlSpaceElement sounds like this is for elements *in*
> space or *in* world, not like
> *the* WorldElement.

The same for me... Besides SpaceElement there is BlSpace which is a model.
Doru suggested to rename:

BlWorldElement -> BlWorld
BlSpace -> BlSpaceModel
BlSpaceElement -> BlSpace

Would such naming by more self-describing for you?


Cheers,
Alex

On Tue, Feb 9, 2016 at 12:50 PM, Nicolai Hess  wrote:

>
>
> 2016-02-05 11:33 GMT+01:00 Aliaksei Syrel :
>
>> Nice questions :) I will not able to address all mentioned issues today,
>> but at least will try some. Answers inlined.
>>
>> - What are package-tags starting with !
>>
>> To force Nautilus show most used core packages first in the list. Without
>> "!" they are floating somewhere in the middle of the lists and it takes few
>> microseconds more to find them + eye concentration. Of course before
>> release they will be renamed.
>>
>>  - Why BlLayoutProperties is named like that?
>>> I do not like the ies at the end in particular
>>
>> I wanted to rename to BlLayoutParams. If you like Params then I will
>> rename.
>>
>> - Why UndefinedObject defines vertical?/horizontal?
>>> to me it looks like the auto method generation encountered a nil.
>>
>>  That is to make Bloc compatible with morphic. (
>> https://pharo.fogbugz.com/f/cases/17502) LayoutProperties of Morph can
>> be nil. So I decided to add extension methods to nil instead of making
>> architecture of Bloc ugly :) Don't see any better solution.
>>
>> - I cannot close the debugger because I get a DNU askOkToClose
>>
>> I too. I also can't close Implementors/Senders browser for the same
>> reason. No idea why.
>>
>>  - Why BlMargin is not polymorphic with Margin?
>>
>> Please, don't take next sentence as joke, but I think it is Margin that
>> is not polymorphic with BlMargin...
>> In Bloc we have padding and margin. They both modify bounds. I don't like
>> to use existing Margin class to describe padding.. Still BlMargin has
>> similar, not identical api as Margin.
>> Also check Margin's api.. It has #rightBottom method - which is the only
>> one to return Point. Where is leftBottom or rightTop? wat.
>>
>>
>>
>>> - what is BlPaint and what are its collaborators.
>>
>> is used for filling and stroking shapes.
>> Milestone is Bloc-beta.
>>
>> - What is a coordinateHolder? Why don’t we use a point?
>>
>> Kind of helper. It is used in events and event listeners. I still didn't
>> invest time in revising events..
>>
>>  - Events needs some class comments:
>>> - API?
>>> -
>>
>> Milestone is Bloc-beta.
>>
>> - Why do we have brickValue: in BlAnimation? to me it looks like a layer
>>> violation.
>>
>> yes. BlAnimation should be deleted.
>>
>> - in BlPath: I have no diea what is a sparta shapes :)
>>> I got confused by
>>> "I'm responsible for building shape path on passed athens path builder.”
>>
>> Well, yes :)
>>
>> Oops the vm crashed :)
>>
>> Oho! It took so long to crash! =^.^=
>>
>> p.s. To all who see this email: Bloc needs more complains
>>
>
> :)
>
> Some random thoughts:
> BlWorldElement and BlSpaceElement sounds like this is for elements *in*
> space or *in* world, not like
> *the* WorldElement.
>
> Looking at BlElement definition:
>
> Object subclass: #BlElement
> uses: TBlPropertiesOwner
> instanceVariableNames: 'ownerReference visible properties
> layoutProperties zIndex spaceReference eventListener errorOnDraw locked
> extent shape layoutStrategy children nextElementReference
> previousElementReference measuredExtent requestingLayout
> oldExtentMeasurementSpec transformation'
> classVariableNames: ''
> package: 'Bloc-Core-!Core-Basic'
>
> The properties visible and locked, somehow they don't fit in the structure
> a BlElement provides, I don't know why but it looks strange.
>

Re: [Pharo-dev] Bloc Documentation

>
> formerOwner: anElementOrNil
> "Set my former or remove property of argument is nil"
>
> anElementOrNil
> ifNil: [ self removeProperty: #formerOwner ]
> ifNotNil: [ self setProperty: #formerOwner toValue:
> anElementOrNil ]

I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c,
ctrl+v)
Basically it should be removed after reimplementation of drag
mechanism. Current one was copied from morphic to support compatibility.
We will need to find better solution. Drag is not so easy to do right.
Help from community is appreciated :)

Cheers,
Alex

On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont  wrote:

> formerOwner: anElementOrNil
> "Set my former or remove property of argument is nil"
>
> anElementOrNil
> ifNil: [ self removeProperty: #formerOwner ]
> ifNotNil: [ self setProperty: #formerOwner toValue:
> anElementOrNil ]
>
> I'd prefer to see a #setProperty:toValueOrRemove: there,
> as that pattern is used a lot.
>
> Stephan
>
>
>

Re: [Pharo-dev] Bloc Documentation




Le 9/2/16 11:53, Aliaksei Syrel a écrit :
On Tue, Feb 9, 2016 at 11:39 AM, Esteban Lorenzano 
> wrote:


mmm… that’s a bad question because I would answer “all of them”,
but I understand you want to do a step to make easy for us to
understand so my answer has to be “the important ones”, but since
there is no documentation/class comments/examples I just cannot
know which  them, so is up to you (and people doing bloc) to tell
us which are “the important ones”… by adding class comments and
examples! :D


It depends :) There are a lot of obvious places in Bloc that do not 
necessarily need documentation to understand them. For example 
events. BlLostMouseFocusEvent does not need any "serious" 
documentation in first place. If you want to find out when it is being 
sent it is much faster to do cmd+n then read long class doc. I don't 
want to say that we don't need documentation.. I just want to say that 
with amount of available man-power we can't instantly add 
documentation to everything in bloc.



Sorry but if the class has an example and a comment stating.
If you want to react to LostMouseFocus do it like that

self eventListener: #LostMouseFocus

Then this is just great. So a comment is not only about what the class 
does but how to use it.


Stef



So I'm asking: what parts of Bloc do you find especially complicated 
to understand. so we could concentrate on them? Root class 
BlElement(methods) has good doc, so please use it to start your 
exploration journey.


Cheers,
Alex

Re: [Pharo-dev] Bloc Documentation

2016-02-09 Thread Ben Coman

On Tue, Feb 9, 2016 at 4:15 PM, Aliaksei Syrel  wrote:
> Bloc does not have examples yet.
> What classes/methods do you need to be commented first to understand the
> system?
>
> On Feb 9, 2016 4:46 AM, "Sean P. DeNigris"  wrote:
>>
>> I realize it's a fast-moving work in progress, but what's the best way to
>> try
>> to understand the system?
>>
>> For example, I saw class comments, some of which seem to be out of date,
>> and
>> I no longer see many of the examples I remember from last year - maybe I
>> have to load them separately?

Maybe... How about starting with some old fashioned hand sketches,
scanned, with maybe some audio attached to the static image describing
the architecture would give people the quickest start.  Just like you
were introducing someone new who was sitting next to you -- but for
those of us aroudn the world who can't make there ;).

Or maybe (??) do an adhoc whiteboard presentation to a few people
locally that you video. It doesn't need to be nicely edited.

These might be quicker than sitting down to write class comments - and
maybe others can assist by extracting class comments from this
material.

cheers -ben

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

2016-02-09 Thread Christophe Demarey


Le 9 févr. 2016 à 14:12, Guille Polito a écrit :

> However, now that we found that something was missing in the startup list, we 
> should check for others...

There are currently 3 classes not registered in the startup list: 
#SystemSettingsPersistence #MCGitBasedNetworkRepository #UUIDGenerator
A slice is ready to fix that: 
https://pharo.fogbugz.com/f/cases/17553/missing-classes-in-startup-list

Re: [Pharo-dev] Bloc Documentation

--- Begin Message ---
Hello,
yes, #formerOwner: and #formerPosition: are here for compatibility with Morphic.
and it will be like that for a while :)
The bloc drag mechanism is implemented differently with the help of events.
Cheers
Alain

> On 9 févr. 2016, at 13:25, Aliaksei Syrel  wrote:
> 
> formerOwner: anElementOrNil
> "Set my former or remove property of argument is nil"
> 
> anElementOrNil
> ifNil: [ self removeProperty: #formerOwner ]
> ifNotNil: [ self setProperty: #formerOwner toValue: 
> anElementOrNil ]
> 
> I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, ctrl+v)
> Basically it should be removed after reimplementation of drag mechanism. 
> Current one was copied from morphic to support compatibility.
> We will need to find better solution. Drag is not so easy to do right. 
> Help from community is appreciated :)
> 
> Cheers,
> Alex
> 
> On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont  wrote:
> formerOwner: anElementOrNil
> "Set my former or remove property of argument is nil"
> 
> anElementOrNil
> ifNil: [ self removeProperty: #formerOwner ]
> ifNotNil: [ self setProperty: #formerOwner toValue: 
> anElementOrNil ]
> 
> I'd prefer to see a #setProperty:toValueOrRemove: there,
> as that pattern is used a lot.
> 
> Stephan
> 
> 
> 


--- End Message ---

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

2016-02-09 Thread Ben Coman

On Tue, Feb 9, 2016 at 9:12 PM, Guille Polito  wrote:
> NNNDDD! It looks I found the real cause of this!
>
> - I tested an image pre-new session manager, and an image post-new session
> manager. The issue only appeared in the latter.
>
> - Checking, it seems that UUIDGenerator is not subscribed to the new startup
> list. This means that the UUIDGenerator is not being reinitialized on every
> startup. This means, moreover, that every person that is loading the latest
> Pharo image is using the same UUIDGenerator instance, with the same random
> seed => same generated UUIDs.
>
> So, adding UUIDGenerator to the list would be the simplest solution and the
> integration of NeoUUIDGenerator can be moved to Pharo6 maybe.
>
> However, now that we found that something was missing in the startup list,
> we should check for others...
>
> Guille

Good find.  How can we make a test for this? Maybe it needs to be done
from outside the image?
cheers -ben

>
>
> On 02/09/2016 10:36 AM, Guille Polito wrote:
>>
>> Yes, go on. I think it is the easiest.
>>
>> Right now, to check if a slice is good or not I have to commit, browse
>> Smalltalkhub's UI, and if it not good I have to delete the mcz manually...
>>
>> On 02/09/2016 10:10 AM, Sven Van Caekenberghe wrote:
>>>
>>> You want me to do it then ?
>>>
>>> I don't want us to do double work ...
>>>
 On 09 Feb 2016, at 10:09, Guillermo Polito 
 wrote:

 Sad and true... :'(

 On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe 
 wrote:
 Beside, you can't make slices ;-)

> On 09 Feb 2016, at 09:58, Sven Van Caekenberghe  wrote:
>
> I can do the integration too, but I need some people to say go ahead.
> I vote for replacing everything, there is no need for a plugin.
>
>> On 09 Feb 2016, at 09:25, Guille Polito 
>> wrote:
>>
>> Sven, just to answer your last question. The UUID generation right now
>> generates the UUID fields like this:
>>
>> UUIDGenerator>>generateFieldsVersion4
>>
>>timeLow := self generateRandomBitsOfLength: 32.
>>timeMid := self generateRandomBitsOfLength: 16.
>>timeHiAndVersion := 16r4000 bitOr: (self
>> generateRandomBitsOfLength: 12).
>>clockSeqHiAndReserved := 16r80 bitOr: (self
>> generateRandomBitsOfLength: 6).
>>clockSeqLow := self generateRandomBitsOfLength: 8.
>>node := self generateRandomBitsOfLength: 48.
>>
>> So... It's basically completely random. There is no part of the UUID
>> that is actually based on the node, the clock or the time. It is 
>> actually a
>> random string of bits that are generated using a number from 
>> /dev/urandom as
>> seed (in linux).
>>
>> Does the mac VM include the plugin? (I do not have a mac any more to
>> test fast ^^)
>>
>> I'll work on the integration of NeoUUID now, I hope this is the kind
>> of issues that got integrated in code-freeze :)
>>
>> Guille
>>
>> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
>>>
>>> Here is a new version, in preparation of possible integration in the
>>> main image:
>>>
>>> ===
>>> Name: Neo-UUID-SvenVanCaekenberghe.2
>>> Author: SvenVanCaekenberghe
>>> Time: 8 February 2016, 8:33:04.141334 pm
>>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
>>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1
>>>
>>> Streamline UUID generation
>>>
>>> Add a current, shared instance
>>>
>>> Added better class and method comments
>>>
>>> Add more tests
>>>
>>> As suggested by Henrik Johansen, change to a version 0 UUID to
>>> indicate that we follow a custom approach
>>> ===
>>>
>>> The class comments now reads as follows:
>>>
>>> ===
>>> I am NeoUUIDGenerator, I generate UUIDs.
>>>
>>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit
>>> number that can be used for identification purposes. Concretely, a UUID 
>>> is a
>>> 16 element byte array.
>>>
>>> The intent of UUIDs is to enable distributed systems to uniquely
>>> identify information without significant central coordination. In this
>>> context the word unique should be taken to mean "practically unique" 
>>> rather
>>> than "guaranteed unique".
>>> I generate UUIDs similar, in spirit, to those defined in RFC4122,
>>> though I use version 0 to indicate that I follow none of the defined
>>> versions. This does not matter much, if at all, in practice.
>>>
>>> I try to conform to the following aspects:
>>> - each 'node' (machine, image, instance) should generate unique UUIDs
>>> - even when generating UUIDs at a very fast rate, they should remain
>>> unique
>>> - be fast and efficient
>>>
>>> To achieve this goal,

Re: [Pharo-dev] Some questions

--- Begin Message ---
> 
> The same for me... Besides SpaceElement there is BlSpace which is a model.
> Doru suggested to rename:
> 
> BlWorldElement -> BlWorld
> BlSpace -> BlSpaceModel
> BlSpaceElement -> BlSpace
> 
> Would such naming by more self-describing for you?

yes
Alain



--- End Message ---

Re: [Pharo-dev] Bloc Documentation


formerOwner: anElementOrNil
"Set my former or remove property of argument is nil"

anElementOrNil
ifNil: [ self removeProperty: #formerOwner ]
ifNotNil: [ self setProperty: #formerOwner toValue: 
anElementOrNil ]

I'd prefer to see a #setProperty:toValueOrRemove: there,
as that pattern is used a lot.

Stephan

[Pharo-dev] [pharo-project/pharo-core] 328356: 50572

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 328356dc854a25a48d3fd46972fe68bc410df50e
  
https://github.com/pharo-project/pharo-core/commit/328356dc854a25a48d3fd46972fe68bc410df50e
  Author: Jenkins Build Server 
  Date:   2016-02-09 (Tue, 09 Feb 2016)

  Changed paths:
A 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/baselines/baseline0%5F12_.st
M 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F11%5F3_.st
A 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F12%5F1_.st
A 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F12_.st
R FFI-Tests.package/FFIPluginTests.class/README.md
R FFI-Tests.package/FFIPluginTests.class/definition.st
R FFI-Tests.package/FFIPluginTests.class/instance/external form 
tests/testBlitToAndFromExternalForm.st
R FFI-Tests.package/FFIPluginTests.class/instance/other 
tests/testLoadSymbolFromModule.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testConstructedCharCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testConstructedDoubleCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testConstructedFloatCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testConstructedIntCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testConstructedPrintString.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testConstructedShortCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericCharCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericDoubleCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericDoubleCall2.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericFloatCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericIntCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericMixedDoublesIntAndStruct.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericMixedFloatsAndDouble.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericPrintString.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testGenericShortCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLibraryCharCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLibraryDoubleCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLibraryFloatCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLibraryIntCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLibraryPrintString.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLongLongA1.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLongLongA3.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testLongLongs.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple 
tests/testUlongRange.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure 
tests/testMixedIntAndStruct.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure 
tests/testMixedIntAndStruct2.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure 
tests/testMixedIntAndStruct3.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure 
tests/testPoint2.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure 
tests/testPoint4.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure 
tests/testPointers.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure 
tests/testSmallStructureReturn.st
R FFI-Tests.package/FFISmallStruct1.class/README.md
R FFI-Tests.package/FFISmallStruct1.class/class/as yet 
unclassified/fields.st
R FFI-Tests.package/FFISmallStruct1.class/definition.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/x.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/x_.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/y.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/y_.st
R FFI-Tests.package/FFITestLibrary.class/README.md
R FFI-Tests.package/FFITestLibrary.class/class/accessing/moduleName.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiPrintString_.st
R 
FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestChar_with_with_with_.st
R

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

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

Re: [Pharo-dev] Bloc Documentation

--- Begin Message ---

> On 9 févr. 2016, at 13:24, Stephan Eggermont  wrote:
> 
> On 09/02/16 11:53, Aliaksei Syrel wrote:
>> So I'm asking: what parts of Bloc do you find especially complicated to
>> understand. so we could concentrate on them? Root class
>> BlElement(methods) has good doc, so please use it to start your
>> exploration journey.
> 
> A lot of confusing comes from BlMorphXX things still being around all over 
> the place. I prefer good examples as a starting point. Making Bloc-DragPanels 
> work again?

yes, it should be easy to adapt it to the current Bloc implementation.
I will reimplement examples.
And you will see that things are nearly the same regarding Bloc user point of 
view.
Cheers
Alain


> 
> Stephan
> 
> 
> 


--- End Message ---

Re: [Pharo-dev] Bloc Documentation

--- Begin Message ---
and please, do not ask too much to Alex.
Alex is doing a pass (great job), and (I guess) he is doing it alone.
I will come back to Pharo and Bloc in two weeks, reimplement examples 
and adapt the first Bloc documentation that we did with Stephane.
Then it will be easier for the community to help.
Cheers
Alain

> On 9 févr. 2016, at 14:26, Alain Plantec  wrote:
> 
> 
>> On 9 févr. 2016, at 13:24, Stephan Eggermont  wrote:
>> 
>> On 09/02/16 11:53, Aliaksei Syrel wrote:
>>> So I'm asking: what parts of Bloc do you find especially complicated to
>>> understand. so we could concentrate on them? Root class
>>> BlElement(methods) has good doc, so please use it to start your
>>> exploration journey.
>> 
>> A lot of confusing comes from BlMorphXX things still being around all over 
>> the place. I prefer good examples as a starting point. Making 
>> Bloc-DragPanels work again?
> 
> yes, it should be easy to adapt it to the current Bloc implementation.
> I will reimplement examples.
> And you will see that things are nearly the same regarding Bloc user point of 
> view.
> Cheers
> Alain
> 
> 
>> 
>> Stephan
>> 
>> 
>> 
> 


--- End Message ---

Re: [Pharo-dev] newFrom: vs. withAll:




Hi guys

I was looking at the Collection chapter and I stumbled upon newFrom: 
and I wonder what is the real

difference between newFrom: and withAll:.
I have the impression that there is not much difference. There are 
only 47 senders of newFrom: in the default Pharo image.


Dictionary class>>withAll: interprets its argument as a collection of 
values,

whereas Dictionary class>>newFrom: expects a collection of associations.

I would really deprecate newFrom: in the future.

Stef

I can understand using anObject newFrom: anotherObject

newFrom: aSimilarObject
"Create an object that has similar contents to aSimilarObject. If 
the classes have any instance variables with the same names, copy them 
across. If this is bad for a class, override this method."


^ (self isVariable
ifTrue: [self basicNew: aSimilarObject basicSize]
ifFalse: [self basicNew]) copySameFrom: aSimilarObject

copySameFrom: otherObject
"Copy to myself all instance variables named the same in otherObject.
This ignores otherObject's control over its own inst vars."

| myInstVars otherInstVars |
myInstVars := self class allInstVarNames.
otherInstVars := otherObject class allInstVarNames.
myInstVars doWithIndex: [:each :index | | match |
(match := otherInstVars indexOf: each) > 0 ifTrue:
[self instVarAt: index put: (otherObject instVarAt: match)]].
1 to: (self basicSize min: otherObject basicSize) do: [:i |
self basicAt: i put: (otherObject basicAt: i)].

but I do not see the point to use this protocol over withAll: for 
collection.


And in general I would prefer to call it cloneFrom:

Stef

Re: [Pharo-dev] Getting coherent shortcuts

Le 9/2/16 15:50, Guille Polito a écrit :

Hi all,

Since a week, I'm back to using linux (debian) due to a new job. And
it became S evident that the shortcuts are wrongly configured,
that I actually cannot work!

Sometimes windows are closed with ctrl w, sometimes with alt w.
Nautilus is used with alt, playgrounds with ctrl...

So, since today I was able to commit again, I decided to make a couple
of slices/new configurations fixing the majority of shortcuts in the
image.

THANKS!

Like this, mac shortcuts will remain in cmd, but linux and windows
shortcuts will be with ctrl, as expected by the vast majority of users
:). The changes I made should fix 97.8882% of the shortcut experience
in linux and windows, without degrading the one in mac. Of course, if
you see any glitch, just tell.

I had to touch several packages, which some are not in the Pharo
repository. For this I prepared several issues for the monkey:

*Slice -
SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2
https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-some-others-ctrl

*Rubric - 2.7
https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*DependencyAnalyzer - 1.15
https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*FastTable - 0.10
https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*TxText - 2.12.2
https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcuts-use-alt-some-others-ctrl

Guille

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name


I love the class comment!
This is because of such class comment that I love also pharo

Le 8/2/16 20:39, Sven Van Caekenberghe a écrit :

Here is a new version, in preparation of possible integration in the main image:

===
Name: Neo-UUID-SvenVanCaekenberghe.2
Author: SvenVanCaekenberghe
Time: 8 February 2016, 8:33:04.141334 pm
UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
Ancestors: Neo-UUID-SvenVanCaekenberghe.1

Streamline UUID generation

Add a current, shared instance

Added better class and method comments

Add more tests

As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we 
follow a custom approach
===

The class comments now reads as follows:

===
I am NeoUUIDGenerator, I generate UUIDs.

An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number 
that can be used for identification purposes. Concretely, a UUID is a 16 
element byte array.

The intent of UUIDs is to enable distributed systems to uniquely identify information without 
significant central coordination. In this context the word unique should be taken to mean 
"practically unique" rather than "guaranteed unique".
  
I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use version 0 to indicate that I follow none of the defined versions. This does not matter much, if at all, in practice.


I try to conform to the following aspects:
  - each 'node' (machine, image, instance) should generate unique UUIDs
  - even when generating UUIDs at a very fast rate, they should remain unique
- be fast and efficient

To achieve this goal, I
- take several aspects into account to generate a unique node ID
- combine a clock, a counter and some random bits
- hold a state, protected for multi user access

I can generate about 500K UUIDs per second.

Implementation:

Although a UUID should be seen as totally opaque, here is the concrete way I 
generate one:
- the first 8 bytes are the millisecond clock value with the smallest quantity 
first; this means that the later of these 8 bytes will be identical when 
generated with small(er) timespans; within the same millisecond, the full first 
8 bytes will be identical
- the next 2 bytes represent a counter with safe overflow, held as protected 
state inside me; after 2*16 this value will repeat; the counter initalizes with 
a random value
- the next 2 bytes are simply random, based on the system PRNG, Random
- the final 4 bytes represent the node ID; the node ID is unique per instance 
of me, across OS environments where the image might run; the node ID is the MD5 
hash of a string that is the concatenation of several elements (see 
#computeNodeIdentifier)
  
Some bits are set to some predefined value, to indicate the variant and version (see #setVariantAndVersion:)


Usage:

   NeoUUIDGenerator next.
   NeoUUIDGenerator current next.
   NeoUUIDGenerator new next.

Sharing an instance is more efficient and correct.
Instances should be reset whenever the image comes up.

See also:

   http://en.wikipedia.org/wiki/UUID
   https://tools.ietf.org/html/rfc4122
===

If we integrate this, I think we should replace the old generator and the use 
of the primitive/plugin. But that requires at least some support apart from me.

And although I think that we should integrate this generator and get rid of the 
plugin, I think there is probably an underlying problem here (why did the 
generator fail ?) that could be important to find.

Sven


On 08 Feb 2016, at 10:38, Henrik Johansen  wrote:


On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe  wrote:


2) Misrepresenting the way the UUID was generated (a combination of node 
identifier + timestamp + random value, similar to type 3, but with differently 
sized/ordered fields) by marking it as being of type 4, which is defined to be 
UUID consisting of random bytes.
IOW, I think it should be marked as type 0 instead of 4, so for the 1 person in 
each country who might be found to assume something about the implementation 
based on the type field, won't later feel he's been duped when checking the 
generator.

OK, I certainly want to change the type. Thing is, I cannot find a reference to 
type 0 anywhere that I am looking (I mostly used 
https://en.wikipedia.org/wiki/Universally_unique_identifier). Where did you 
find a definition of type 0 ? Or would that be a way to say 'no specific type' 
then ?

My rationale was that it is currently unassigned, and the least likely number 
to be chosen as identifier by new versions of the standard.
IOW, for those who care, it might raise a "hmm, this is strange, better check the 
source", upon which they will discover it is generated in a non-standard fashion 
(but can verify for themselves it is generated in a way still pretty much guaranteed to 
be unique), and the rest... well, they can (most probably) keep on living happily without 
ever seeing a collision.

Cheers,
Henry

[Pharo-dev] newFrom: vs. withAll:


Hi guys

I was looking at the Collection chapter and I stumbled upon newFrom: and 
I wonder what is the real

difference between newFrom: and withAll:.
I have the impression that there is not much difference. There are only 
47 senders of newFrom: in the default Pharo image.


Dictionary class>>withAll: interprets its argument as a collection of 
values,

whereas Dictionary class>>newFrom: expects a collection of associations.

I would really deprecate newFrom: in the future.

Stef

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Le 9/2/16 09:58, Sven Van Caekenberghe a écrit :

I can do the integration too, but I need some people to say go ahead.
I vote for replacing everything, there is no need for a plugin.

me too.
Less plugin!

On 09 Feb 2016, at 09:25, Guille Polito wrote:

Sven, just to answer your last question. The UUID generation right now
generates the UUID fields like this:

UUIDGenerator>>generateFieldsVersion4

Does the mac VM include the plugin? (I do not have a mac any more to test fast
^^)

I'll work on the integration of NeoUUID now, I hope this is the kind of issues
that got integrated in code-freeze :)

Guille

On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:

Here is a new version, in preparation of possible integration in the main image:

===
Name: Neo-UUID-SvenVanCaekenberghe.2
Author: SvenVanCaekenberghe
Time: 8 February 2016, 8:33:04.141334 pm
UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
Ancestors: Neo-UUID-SvenVanCaekenberghe.1

Streamline UUID generation

Add a current, shared instance

Added better class and method comments

Add more tests

As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we
follow a custom approach
===

The class comments now reads as follows:

===
I am NeoUUIDGenerator, I generate UUIDs.

An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number
that can be used for identification purposes. Concretely, a UUID is a 16
element byte array.

The intent of UUIDs is to enable distributed systems to uniquely identify information without
significant central coordination. In this context the word unique should be taken to mean
"practically unique" rather than "guaranteed unique".
I generate UUIDs similar, in spirit, to those defined in RFC4122, though I
use version 0 to indicate that I follow none of the defined versions. This does
not matter much, if at all, in practice.

To achieve this goal, I
- take several aspects into account to generate a unique node ID
- combine a clock, a counter and some random bits
- hold a state, protected for multi user access

I can generate about 500K UUIDs per second.

Implementation:

Usage:

NeoUUIDGenerator next.
NeoUUIDGenerator current next.
NeoUUIDGenerator new next.

Sharing an instance is more efficient and correct.
Instances should be reset whenever the image comes up.

Re: [Pharo-dev] Getting coherent shortcuts

Esteban was telling me that he is going to re-integrate the VM fixes to
the shortcuts for windows soon.

On 02/09/2016 04:48 PM, stepharo wrote:

Le 9/2/16 15:50, Guille Polito a écrit :

Hi all,

Since a week, I'm back to using linux (debian) due to a new job. And
it became S evident that the shortcuts are wrongly configured,
that I actually cannot work!

Sometimes windows are closed with ctrl w, sometimes with alt w.
Nautilus is used with alt, playgrounds with ctrl...

So, since today I was able to commit again, I decided to make a
couple of slices/new configurations fixing the majority of shortcuts
in the image.

THANKS!

Like this, mac shortcuts will remain in cmd, but linux and windows
shortcuts will be with ctrl, as expected by the vast majority of
users :). The changes I made should fix 97.8882% of the shortcut
experience in linux and windows, without degrading the one in mac. Of
course, if you see any glitch, just tell.

I had to touch several packages, which some are not in the Pharo
repository. For this I prepared several issues for the monkey:

*Slice -
SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2
https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-some-others-ctrl

*Rubric - 2.7
https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*DependencyAnalyzer - 1.15
https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*FastTable - 0.10
https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shortcuts-use-alt-some-others-ctrl

*TxText - 2.12.2
https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcuts-use-alt-some-others-ctrl

Also, I did some changes in Glamour and GTSpotter, but I have no
permissions to commit there. How do we do to commit in those
packages? Should I ask for permissions or is there any other process
in place?

Guille

Re: [Pharo-dev] Spec Experience in Need for Feedback :)


Hi peter :)

If I recall, one of the key problem is that the state of certain widgets 
does not let the adpater do its job nicely and disappear

after the bridging.

Stef


Le 9/2/16 16:31, Peter Uhnák a écrit :
The widget becomes available only once the UI is built, however when 
you are configuring Spec it is not yet built so it's not available and 
thus the ugly nil check (well, one of the reasons anyway).


This is a big problem with morphic/spec ui elements. You never
know for sure
what code this
self update ---> search through all (dynamicly added)
dependents and notify
will finally call.

I don't think there is any way around it. You have to decouple
view(s) from model(s), and, hence have those propagation
constraints by way of notifications.


About a year ago we were discussing this with Stef and one of the 
options was to expose all value holders (which has happened in the 
meantime) and have adapter just connect Spec with Morphic.
This is a bit older and needs updating, but I think it still holds 
somewhat https://gist.github.com/peteruhnak/0fc752d0cea9bde69315 (the 
idea was to to connect Morphic directly to observe Spec and therefore 
not have Adapter at all during runtime).


Peter

On Tue, Feb 9, 2016 at 1:46 PM, stepharo > wrote:


Hi nicolai

I agree. I will have a look at the Calipso experience of Alain.
Because may be Calipso + Spec layout format would be much nicer.
Did you look at it?
Alain just brainstormed but this is interesting for thinking.

Stef

What I hate also is that the

 AbstractApdate>>update: aSymbol

self changed: aSymbol

This is a bit terrible because the adpater should not exist at
runtime
and adapter should just encapsulate how to create and set the
communication
between the model and the view. Now it is in the middle and this
is not good.

stef


Le 8/2/16 11:31, Nicolai Hess a écrit :



2016-02-08 10:37 GMT+01:00 stepharo >:

Hi guys

I should say that I'm sick (gift from my little boy) so may
be this is obvious.

I'm looking at the code of Spec and I hate this code :)

widgetDo: aBlock

^ self widget ifNotNil: aBlock


I do not see why widgetDo: has to test for nil
So I transformed

widgetDo: aBlock

^ self widget ifNotNil: aBlock

into


widgetDo: aBlock

^ aBlock cull: self widget

BTW I hate all the cull: call. They are connected with
sloppiness). It is far too easy to use cull:
I do not know how many arguments, I do not care I use cull:
cull: is slow slow and help producing messing API.

And it broke. The methodBrowser example did not work anymore
and many others.
Debugger felt down
I feel sad. Now my brain is dead so I cannot concentrate more.


Stef


This is a big problem with morphic/spec ui elements. You never
know for sure
what code this
self update ---> search through all (dynamicly added) dependents
and notify
will finally call.
In this example we are about to *built* the widgets and in this
run , we change a component that
will update all dependents goes back and forth between model,
adapter and widget. And all
before the widget is actually accessible for the widgetDo: call.

(and, REALLY we need to clean this up. This is really bad code if
we announce a textChanged announcement for
a text component, if we *initialize* an *empty textcomponent*
with an *empty text*!).

Re: [Pharo-dev] Getting coherent shortcuts

2016-02-09 Thread Damien Cassou

Guille Polito  writes:

> So, since today I was able to commit again, I decided to make a couple 
> of slices/new configurations fixing the majority of shortcuts in the 
> image. Like this, mac shortcuts will remain in cmd, but linux and 
> windows shortcuts will be with ctrl, as expected by the vast majority of 
> users :). The changes I made should fix 97.8882% of the shortcut 
> experience in linux and windows, without degrading the one in mac. Of 
> course, if you see any glitch, just tell.

thank you very much!

-- 
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] [Need help with Monkey] Removing Object>>name

2016-02-09 Thread Ben Coman

On Tue, Feb 9, 2016 at 11:53 PM, stepharo  wrote:
>
>
> Le 9/2/16 09:58, Sven Van Caekenberghe a écrit :
>>
>> I can do the integration too, but I need some people to say go ahead.
>> I vote for replacing everything, there is no need for a plugin.
>
>
> me too.
> Less plugin!

This is a good general philosophy, but we should benchmark in-image
versus plugin so we can make an informed analytical decision on how
much performance we are willing to trade for the convenience of it
being all in-image, and whether we want to maintain a separate CI job
for keeping the plugin tested.  Overriding that is providing a quick
fix so other development is not blocked, which however Guille's
solution seems sufficient for the code freeze of Pharo 5.

cheers -ben

>
>
>>
>>> On 09 Feb 2016, at 09:25, Guille Polito 
>>> wrote:
>>>
>>> Sven, just to answer your last question. The UUID generation right now
>>> generates the UUID fields like this:
>>>
>>> UUIDGenerator>>generateFieldsVersion4
>>>
>>> timeLow := self generateRandomBitsOfLength: 32.
>>> timeMid := self generateRandomBitsOfLength: 16.
>>> timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength:
>>> 12).
>>> clockSeqHiAndReserved := 16r80 bitOr: (self
>>> generateRandomBitsOfLength: 6).
>>> clockSeqLow := self generateRandomBitsOfLength: 8.
>>> node := self generateRandomBitsOfLength: 48.
>>>
>>> So... It's basically completely random. There is no part of the UUID that
>>> is actually based on the node, the clock or the time. It is actually a
>>> random string of bits that are generated using a number from /dev/urandom as
>>> seed (in linux).
>>>
>>> Does the mac VM include the plugin? (I do not have a mac any more to test
>>> fast ^^)
>>>
>>> I'll work on the integration of NeoUUID now, I hope this is the kind of
>>> issues that got integrated in code-freeze :)
>>>
>>> Guille
>>>
>>> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:

 Here is a new version, in preparation of possible integration in the
 main image:

 ===
 Name: Neo-UUID-SvenVanCaekenberghe.2
 Author: SvenVanCaekenberghe
 Time: 8 February 2016, 8:33:04.141334 pm
 UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
 Ancestors: Neo-UUID-SvenVanCaekenberghe.1

 Streamline UUID generation

 Add a current, shared instance

 Added better class and method comments

 Add more tests

 As suggested by Henrik Johansen, change to a version 0 UUID to indicate
 that we follow a custom approach
 ===

 The class comments now reads as follows:

 ===
 I am NeoUUIDGenerator, I generate UUIDs.

 An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit
 number that can be used for identification purposes. Concretely, a UUID is 
 a
 16 element byte array.

 The intent of UUIDs is to enable distributed systems to uniquely
 identify information without significant central coordination. In this
 context the word unique should be taken to mean "practically unique" rather
 than "guaranteed unique".
   I generate UUIDs similar, in spirit, to those defined in RFC4122,
 though I use version 0 to indicate that I follow none of the defined
 versions. This does not matter much, if at all, in practice.

 I try to conform to the following aspects:
   - each 'node' (machine, image, instance) should generate unique UUIDs
   - even when generating UUIDs at a very fast rate, they should remain
 unique
 - be fast and efficient

 To achieve this goal, I
 - take several aspects into account to generate a unique node ID
 - combine a clock, a counter and some random bits
 - hold a state, protected for multi user access

 I can generate about 500K UUIDs per second.

 Implementation:

 Although a UUID should be seen as totally opaque, here is the concrete
 way I generate one:
 - the first 8 bytes are the millisecond clock value with the smallest
 quantity first; this means that the later of these 8 bytes will be 
 identical
 when generated with small(er) timespans; within the same millisecond, the
 full first 8 bytes will be identical
 - the next 2 bytes represent a counter with safe overflow, held as
 protected state inside me; after 2*16 this value will repeat; the counter
 initalizes with a random value
 - the next 2 bytes are simply random, based on the system PRNG, Random
 - the final 4 bytes represent the node ID; the node ID is unique per
 instance of me, across OS environments where the image might run; the node
 ID is the MD5 hash of a string that is the concatenation of several 
 elements
 (see #computeNodeIdentifier)
   Some bits are set to some predefined value, to indicate the variant
 and version (see #setVariantAndVersion:)

 Usage:

Re: [Pharo-dev] Getting coherent shortcuts

2016-02-09 Thread Tudor Girba

This is great!

Doru


> On Feb 9, 2016, at 7:10 PM, Sven Van Caekenberghe  wrote:
> 
> 
>> On 09 Feb 2016, at 17:31, Damien Cassou  wrote:
>> 
>> Guille Polito  writes:
>> 
>>> So, since today I was able to commit again, I decided to make a couple 
>>> of slices/new configurations fixing the majority of shortcuts in the 
>>> image. Like this, mac shortcuts will remain in cmd, but linux and 
>>> windows shortcuts will be with ctrl, as expected by the vast majority of 
>>> users :). The changes I made should fix 97.8882% of the shortcut 
>>> experience in linux and windows, without degrading the one in mac. Of 
>>> course, if you see any glitch, just tell.
>> 
>> thank you very much!
> 
> + 10 !
> 
>> -- 
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>> 
>> "Success is the ability to go from one failure to another without
>> losing enthusiasm." --Winston Churchill
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com 

“Live like you mean it."

Re: [Pharo-dev] Getting coherent shortcuts


On 09/02/16 15:50, Guille Polito wrote:

Also, I did some changes in Glamour and GTSpotter, but I have no
permissions to commit there. How do we do to commit in those packages?
Should I ask for permissions or is there any other process in place?


There's a magical process by which you complain in the mailing list and 
then suddenly are able to commit.


Stephan

Re: [Pharo-dev] Getting coherent shortcuts

2016-02-09 Thread Tudor Girba

Thanks Stephan :).

@Guille: Stephan just added you to the SmalltalkHub repository.

Could you ping me when you commit so that I can review?

Cheers,
Doru


> On Feb 9, 2016, at 11:25 PM, Stephan Eggermont  wrote:
> 
> On 09/02/16 15:50, Guille Polito wrote:
>> Also, I did some changes in Glamour and GTSpotter, but I have no
>> permissions to commit there. How do we do to commit in those packages?
>> Should I ask for permissions or is there any other process in place?
> 
> There's a magical process by which you complain in the mailing list and then 
> suddenly are able to commit.
> 
> Stephan
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name


On 09/02/16 14:12, Guille Polito wrote:

NNNDDD! It looks I found the real cause of this!

- I tested an image pre-new session manager, and an image post-new
session manager. The issue only appeared in the latter.

- Checking, it seems that UUIDGenerator is not subscribed to the new
startup list. This means that the UUIDGenerator is not being
reinitialized on every startup. This means, moreover, that every person
that is loading the latest Pharo image is using the same UUIDGenerator
instance, with the same random seed => same generated UUIDs.

So, adding UUIDGenerator to the list would be the simplest solution and
the integration of NeoUUIDGenerator can be moved to Pharo6 maybe.

However, now that we found that something was missing in the startup
list, we should check for others...


So, which image versions do we need to mark as broken, don't use?

Stephan

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

> On 09 Feb 2016, at 17:35, Ben Coman  wrote:
> 
> On Tue, Feb 9, 2016 at 11:53 PM, stepharo  wrote:
>> 
>> 
>> Le 9/2/16 09:58, Sven Van Caekenberghe a écrit :
>>> 
>>> I can do the integration too, but I need some people to say go ahead.
>>> I vote for replacing everything, there is no need for a plugin.
>> 
>> 
>> me too.
>> Less plugin!
> 
> This is a good general philosophy, but we should benchmark in-image
> versus plugin so we can make an informed analytical decision on how
> much performance we are willing to trade for the convenience of it
> being all in-image, and whether we want to maintain a separate CI job
> for keeping the plugin tested.  Overriding that is providing a quick
> fix so other development is not blocked, which however Guille's
> solution seems sufficient for the code freeze of Pharo 5.

From a comment in 

===
Speedwise, in Pharo 5 Spur on my machine, the new implementation is just as 
fast as the primitive, or so it seems:

[ UUIDGenerator next ] bench. "'1,235,356 per second'"

[ UUID nilUUID primMakeUUID ] bench. "'1,237,213 per second'"
===

But even if it were slower (like half or quarter speed), there is a *HUGE* 
benefit to in image code. 

C code will always win, performance wise, but if that is all that counts, why 
do we program in Pharo at all.

Please read << Design Principles Behind Smalltalk >>

  http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

Principle 1:

Personal Mastery: If a system is to serve the creative spirit, it must be 
entirely comprehensible to a single individual.

Further on:

Operating System: An operating system is a collection of things that don't fit 
into a language. There shouldn't be one.

Not that this document is an axiom or anything, but it articulates well some 
very relevant principles.

For all these years, you nor I ever knew what took place in that silly plugin 
(1 method), while a confusing UUIDGenerator made some of us believe that it was 
used or somehow identical to the plugin (that was probably not true), now you, 
me and 99% of all other Pharo developers can read clean code.

For me, Pharo is much more than the next scripting language that links to OS 
libraries. Pharo makes software (development) tangible, understandable in one 
single language/environment.

When is the last time you looked into the open source C code of any library of 
your OS, let alone the kernel itself or one of its drivers ? Probably never. 
But in Pharo we can all look under the hood, everywhere, seamlessly. 

Sven

> cheers -ben
> 
>> 
>> 
>>> 
 On 09 Feb 2016, at 09:25, Guille Polito 
 wrote:

 Sven, just to answer your last question. The UUID generation right now
 generates the UUID fields like this:

 UUIDGenerator>>generateFieldsVersion4

timeLow := self generateRandomBitsOfLength: 32.
timeMid := self generateRandomBitsOfLength: 16.
timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength:
 12).
clockSeqHiAndReserved := 16r80 bitOr: (self
 generateRandomBitsOfLength: 6).
clockSeqLow := self generateRandomBitsOfLength: 8.
node := self generateRandomBitsOfLength: 48.

 So... It's basically completely random. There is no part of the UUID that
 is actually based on the node, the clock or the time. It is actually a
 random string of bits that are generated using a number from /dev/urandom 
 as
 seed (in linux).

 Does the mac VM include the plugin? (I do not have a mac any more to test
 fast ^^)

 I'll work on the integration of NeoUUID now, I hope this is the kind of
 issues that got integrated in code-freeze :)

 Guille

 On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
> 
> Here is a new version, in preparation of possible integration in the
> main image:
> 
> ===
> Name: Neo-UUID-SvenVanCaekenberghe.2
> Author: SvenVanCaekenberghe
> Time: 8 February 2016, 8:33:04.141334 pm
> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
> Ancestors: Neo-UUID-SvenVanCaekenberghe.1
> 
> Streamline UUID generation
> 
> Add a current, shared instance
> 
> Added better class and method comments
> 
> Add more tests
> 
> As suggested by Henrik Johansen, change to a version 0 UUID to indicate
> that we follow a custom approach
> ===
> 
> The class comments now reads as follows:
> 
> ===
> I am NeoUUIDGenerator, I generate UUIDs.
> 
> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit
> number that can be used for identification purposes. Concretely, a UUID 
> is a
> 16 element byte array.
> 
> The intent of UUIDs is to enable distributed systems to uniquely
> identify information without significant central coordination. In this
> context the word unique should be

Re: [Pharo-dev] Getting coherent shortcuts