Igor Stasenko wrote:
> The main purpose to be able to handle nils in sets as an elements is to make
Set
> be able to hold _any_ potentially existing objects in image.

Absolutely not. The main purpose of having nil be included in sets is to
remove a particular restriction (namely that Sets cannot contain nil),
not to "be able to hold _any_ potentially existing objects in an image".
What is being proposed is trading one restriction (Sets cannot contain
nil) against another one (Sets cannot contain their internal private
marker) which is deemed advantageous as it allows us to convert many
collections that contain nil into sets without blowing up. *That* is the
main purpose.

The goal of "be able to hold _any_ potentially existing objects in an
image" is neither achievable nor worthwhile. Try this for starters:

    (s := Set new) add: s; add: s.

Without having to do anything like reflection and picking arbitrary
objects I can create an (undetected) problem that no proposal addresses.
If you actually mean what you say above I think there are more
problematic issues to solve (problems similar to the above have actually
caused random lockups in the wild).

The point here is that Sets *do* have limitations and what we're trying
to do is to be more helpful in the set of limitations that we require.
Not being able to say "Set with: nil" is silly; not being able to say
"(s := Set new) add: (s instVarAt: 3)" is a much more reasonable
restriction.

BTW, even having said all of the above I'm still not fully convinced
that Randal's proposal is the best way to go. It might be simpler to
just have a flag that says "this set contains nil" like you were
proposing. Whether that needs to be done by using a negative tally or
whether it is better to just add an ivar "hasNil" is yet another question.

It would be rather more interesting to me to discuss the practical
tradeoffs of the choosing one way (marker instead of nil) over the other
(flag indicating nil containment) in terms of implementation and
performance costs.

Cheers,
    - Andreas

2009/11/12 Randal L. Schwartz <merlyn@...>:
>>>>>> "Igor" == Igor Stasenko <siguctua@...> writes:
>
> Igor> But your solution could be described as:
> Igor> a) we having a basket full of differently colored balls.
> Igor> b) while counting balls in basket lets count all balls, except
> Igor> transparent ones.
> Igor> ..and your idea:
> Igor> rewrite b:  while counting balls in basket lets count all balls,
> Igor> except red ones.
>
> No, it *does* solve the problem, because "red" is very very very local
> to this set.
>
It is, and inspector will show us this very very very local object , and
#instVarAt: as well as #someInstance and #allInstances and many others
(debugger, OODBs etc).
Then at some point it could become not so very very very local, and
then you will meet the same problem
as we currently having with inability to have a nils in Set.

> The only problem would be if you have a set add itself's instance vars.  And
> that would be problematic for other issues.
>
> But it would always be able to represent *every* other set in the image.
>

indeed, that's why i don't like it and treat it similar to current
implementation without strong reasons why we would
want to employ it.

A simple illustration:

  set := Set new.
  Object allInstancesDo: [:obj | set add: obj ]   "using 'Object new'
as filler, right?"

we could argue very long why one would want to do that, but the fact
is clear: your proposal have nothing
to offer to developer how to get around that.



--
Best regards,
Igor Stasenko AKA sig.

>>>>> "Igor" == Igor Stasenko <siguctua@...> writes:

Igor> But your solution could be described as:
Igor> a) we having a basket full of differently colored balls.
Igor> b) while counting balls in basket lets count all balls, except
Igor> transparent ones.
Igor> ..and your idea:
Igor> rewrite b:  while counting balls in basket lets count all balls,
Igor> except red ones.

No, it *does* solve the problem, because "red" is very very very local
to this set.

The only problem would be if you have a set add itself's instance vars.  And
that would be problematic for other issues.

But it would always be able to represent *every* other set in the image.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@...> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

2009/11/12 Randal L. Schwartz <merlyn@...>:
>>>>>> "Andreas" == Andreas Raab <andreas.raab@...> writes:
>
> Andreas> Seriously, how *would* you address this problem if you weren't trying
to make
> Andreas> it fit exactly?
>
> I like the proposal that each set have an additional instance var that gets an
> "Object new" stuffed in it to indicate what "nil" does today, for that
> *particular* set.  That seems relatively cost effective *and* space
effective.
> Every "isNil" for "this slot is empty" just becomes "== myEmptyVal".
>

Sorry, didn't commented earlier.
Such proposal make little difference comparing to currently existing
implementation,
  and i'd prefer to not having it, and leave things as they are, given
an additional costs which it implies.

The main purpose to be able to handle nils in sets as an elements is to make Set
be able to hold _any_ potentially existing objects in image.

But your solution could be described as:
a) we having a basket full of differently colored balls.
b) while counting balls in basket lets count all balls, except
transparent ones.
..and your idea:
rewrite b:  while counting balls in basket lets count all balls,
except red ones.



> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn@...> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
>
>



--
Best regards,
Igor Stasenko AKA sig.

2009/11/12 Andreas Raab <andreas.raab@...>:
> Igor Stasenko wrote:
>>>
>>> Seriously, how *would* you address this problem if you weren't trying to
>>> make it fit exactly?
>>
>> err.. you don't mind, if i remind you that there a lot of ugly hacks
>> around , like compact classes,
>> implicit message sends (#class , #==) and nobody saying a word against
>> them, #ifTrue:ifFalse: inlining
>> instead of true message send and finally immediate objects -
>> smallintegers which you can't subclass?!?!
>>
>> Do you really think that way how to represent the presence of nil in
>> set worst than the listed above?
>
> No, but that's not my point.

Ok, then, sorry for above :)

> There are reasons why the hacks you refer to
> are there (performance, compactness) but we measure those tradeoffs against
> a "canonical" implementation, i.e., one that does not require these hacks.
> I'm trying to do the same - I am asking for how a Set with nil would look
> like if you'd start it from scratch so that we can compare and contrast
> between the proposals.
>
i think it will look similar unless you introduce a discrimination,
that set could contain
any object except some filler. Be it nil or some other unique object
not really matters, because
the main condition not met:
- pick any existing, or create a new Set

- pick any object in object memory, no matter where it comes from and
try to put it in that Set.
If set is able to handle all such objects without discrimination, it
is good set.. if not - bad.

Does that sounds reasonable?

> For example, the tradeoff in Randal's proposal (having a flag) is that we a)
> add a variable to all sets (the flag) b) change the implementation from
> comparing with nil to comparing with the flag and c) that Sets cannot
> contain the flag element itself. That sounds quite reasonable to me.
>
> Cheers,
>  - Andreas
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
>> Seriously, how *would* you address this problem if you weren't trying to
>> make it fit exactly?
>
> err.. you don't mind, if i remind you that there a lot of ugly hacks
> around , like compact classes,
> implicit message sends (#class , #==) and nobody saying a word against
> them, #ifTrue:ifFalse: inlining
> instead of true message send and finally immediate objects -
> smallintegers which you can't subclass?!?!
>
> Do you really think that way how to represent the presence of nil in
> set worst than the listed above?

No, but that's not my point. There are reasons why the hacks you refer
to are there (performance, compactness) but we measure those tradeoffs
against a "canonical" implementation, i.e., one that does not require
these hacks. I'm trying to do the same - I am asking for how a Set with
nil would look like if you'd start it from scratch so that we can
compare and contrast between the proposals.

For example, the tradeoff in Randal's proposal (having a flag) is that
we a) add a variable to all sets (the flag) b) change the implementation
from comparing with nil to comparing with the flag and c) that Sets
cannot contain the flag element itself. That sounds quite reasonable to me.

Cheers,
    - Andreas

On Tue, Nov 10, 2009 at 09:04:57AM -0800, Andreas Raab wrote:
> David T. Lewis wrote:
> >On Mon, Nov 09, 2009 at 08:56:01PM -0800, Andreas Raab wrote:
> >>
> >>I think we should nuke enterForEmergencyRecovery and those parts in
> >>Project that deal with isolated changes. This is one of the projects
> >>that never got to a conclusion and there is no point in keeping all
> >>these hooks for stuff that is unused. If you want to keep the interface,
> >>just raise an error if you ever see a revert == true or so.
> >
> >Oh, good, that explains it. I was rather nervous about modifying a method
> >when I did not even know what it was being used for.
>
> It was used in an experimental project that tried to isolate changes
> done in a project by un-applying them when you would enter another
> project. Unfortunately, the approach taken (making copies of the methods
> and applying/unapplying them when entering leaving projects) was fraught
> with perils and didn't work very well in practice. So nuke it ;-)

I marked #enterForEmergencyRecovery with a "self flag: #toRemove" and
explanatory comment. There are two senders of #enterForEmergencyRecovery
and I don't understand the implications, so I won't nuke it just yet.

Thanks,
Dave

David T. Lewis uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-dtl.164.mcz

==================== Summary ====================

Name: System-dtl.164
Author: dtl
Time: 11 November 2009, 10:20:21 am
UUID: d2f70c3a-4bcb-4ca8-b29f-72b040525c4a
Ancestors: System-dtl.163

Factor Project>>saveState into MVCProject and MorphicProject.

Flag Project>>enterForEmergencyRecovery for later removal, per discussion:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140762.html


=============== Diff against System-dtl.163 ===============

Item was changed:
+ ----- Method: Project>>saveState (in category 'enter') -----
- ----- Method: Project>>saveState (in category 'menu messages') -----
   saveState
  	 "Save the current state in me prior to leaving this project"

+  self subclassResponsibility!
-  changeSet := ChangeSet current.
-  thumbnail ifNotNil: [thumbnail hibernate].
-  Smalltalk isMorphic
- 	 ifTrue:
- 		 [world := World.
- 		 world sleep.
- 		 ActiveWorld := ActiveHand := ActiveEvent := nil]
- 	 ifFalse:
- 		 [world := ScheduledControllers.
- 		 ScheduledControllers unCacheWindows].
-  Sensor flushAllButDandDEvents. "Will be reinstalled by World>>install"
-  transcript := Transcript.
- !

Item was changed:
   ----- Method: Project>>enterForEmergencyRecovery (in category 'enter') -----
   enterForEmergencyRecovery
  	 "This version of enter invokes an absolute minimum of mechanism.
  	 An unrecoverable error has been detected in an isolated project.
  	 It is assumed that the old changeSet has already been revoked.
  	 No new process gets spawned here.  This will happen in the debugger."
+
+  self flag: #toRemove. "dtl Nov 2009: Per guidance from ar, this is part of an
experimental
+ 	 project and should be removed (along with #setWorldForEmergencyRecovery).
+ 	 Currently there are senders that must be resolved prior to removal.
Reference:
+ 	
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140762.html\
"

  	 self isCurrentProject ifTrue: [^ self].
  	 CurrentProject saveState.
  	 CurrentProject := self.
  	 Display newDepthNoRestore: displayDepth.
  	 ChangeSet  newChanges: changeSet.
  	 TranscriptStream newTranscript: transcript.
  	 World pauseEventRecorder.
  	 self setWorldForEmergencyRecovery.
  	 UIProcess := Processor activeProcess
   !

David T. Lewis uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-dtl.225.mcz

==================== Summary ====================

Name: Morphic-dtl.225
Author: dtl
Time: 11 November 2009, 10:16:33 am
UUID: dc79931f-c0ac-42d6-9384-5f17b78269d3
Ancestors: Morphic-dtl.224

Factor Project>>saveState into MVCProject and MorphicProject.

=============== Diff against Morphic-dtl.224 ===============

Item was added:
+ ----- Method: MorphicProject>>saveState (in category 'enter') -----
+ saveState
+  "Save the current state in me prior to leaving this project"
+
+  changeSet := ChangeSet current.
+  thumbnail ifNotNil: [thumbnail hibernate].
+  world := World.
+  world sleep.
+  ActiveWorld := ActiveHand := ActiveEvent := nil.
+  Sensor flushAllButDandDEvents. "Will be reinstalled by World>>install"
+  transcript := Transcript
+ !

David T. Lewis uploaded a new version of ST80 to project The Trunk:
http://source.squeak.org/trunk/ST80-dtl.65.mcz

==================== Summary ====================

Name: ST80-dtl.65
Author: dtl
Time: 11 November 2009, 10:14:32 am
UUID: 9ec4eaac-47af-4c13-8ab5-35d2d8c64f3a
Ancestors: ST80-dtl.64

Factor Project>>saveState into MVCProject and MorphicProject.

=============== Diff against ST80-dtl.64 ===============

Item was added:
+ ----- Method: MVCProject>>saveState (in category 'enter') -----
+ saveState
+  "Save the current state in me prior to leaving this project"
+
+  changeSet := ChangeSet current.
+  thumbnail ifNotNil: [thumbnail hibernate].
+  world := ScheduledControllers.
+  ScheduledControllers unCacheWindows.
+  Sensor flushAllButDandDEvents. "Will be reinstalled by World>>install"
+  transcript := Transcript
+ !

2009/11/12 Andreas Raab <andreas.raab@...>:
> Eliot Miranda wrote:
>>
>> Neat.  It might be even easier to use floating point to indicate nil :)
>> So if
>>        tally class = SmallInteger
>> it doesn't include nil, but if
>>        tally class = Float
>> it does.  Once tally has been set to a Double all the loops still work,
>> increasing the tally still works, etc.
>
> Ouch! Can we please step back a little and instead of coming up with ever
> more clever hacks think a bit about how we'd solve the problem if we would
> address it from first principles? Nothing against cool hacks but that is
> getting so obscure that I'd rather not have nil in sets at all than having
> to live with the hacks that have been proposed.
>
> Seriously, how *would* you address this problem if you weren't trying to
> make it fit exactly?
>

err.. you don't mind, if i remind you that there a lot of ugly hacks
around , like compact classes,
implicit message sends (#class , #==) and nobody saying a word against
them, #ifTrue:ifFalse: inlining
instead of true message send and finally immediate objects -
smallintegers which you can't subclass?!?!

Do you really think that way how to represent the presence of nil in
set worst than the listed above?

In attachment a changeset which allow nils to have sets.. or sets to
have nils.. whatever :)

All tests in CollectionTests are green except one unrelated
(ArrayTest>>testPrinting)

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

>>>>> "Andreas" == Andreas Raab <andreas.raab@...> writes:

Andreas> Seriously, how *would* you address this problem if you weren't trying
to make
Andreas> it fit exactly?

I like the proposal that each set have an additional instance var that gets an
"Object new" stuffed in it to indicate what "nil" does today, for that
*particular* set.  That seems relatively cost effective *and* space effective.
Every "isNil" for "this slot is empty" just becomes "== myEmptyVal".

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@...> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Eliot Miranda wrote:
> Neat.  It might be even easier to use floating point to indicate nil :)
> So if
>         tally class = SmallInteger
> it doesn't include nil, but if
>         tally class = Float
> it does.  Once tally has been set to a Double all the loops still work,
> increasing the tally still works, etc.

Ouch! Can we please step back a little and instead of coming up with
ever more clever hacks think a bit about how we'd solve the problem if
we would address it from first principles? Nothing against cool hacks
but that is getting so obscure that I'd rather not have nil in sets at
all than having to live with the hacks that have been proposed.

Seriously, how *would* you address this problem if you weren't trying to
make it fit exactly?

Cheers,
    - Andreas

2009/11/12 Eliot Miranda <eliot.miranda@...>:
>
>
> On Wed, Nov 11, 2009 at 3:56 PM, Igor Stasenko <siguctua@...> wrote:
>>
>> @Levente..
>> there is no need to introduce a 'containsNil' flag, nor use other than
>> nil filler object.
>> The tally ivar, which is already there can be used to reflect if set
>> contains nil:
>>
>> tally >= 0  - set contains tally number of elements without nil
>> tally == -1 - set contains only single element - nil
>> tally < -1  - set contains a (tally abs) number of elements including nil
>>
>
> Neat.  It might be even easier to use floating point to indicate nil :)
> So if
>         tally class = SmallInteger
> it doesn't include nil, but if
>         tally class = Float
> it does.

Hehe.. just another way. But it having certain risks, i think, because
  5.0 is quite same as 5
from arithmetic POV while 5 and -5 are distinct values from all POV,
which can't be mixed unintentionally.

A test if set contains nil, then could be just
  tally isInteger  ifFalse: [... contains nil ]

(its faster & we don't care about particular class, isn't?)

> Once tally has been set to a Double all the loops still work,
> increasing the tally still works, etc.

Loops do not refer to tally (all iterations using array ivar and its
size), so there no iterations in sets which may require floating point
value, and hence producing a lot of garbage & waste cycles on it.

Tally comes into play only when you adding or removing objects, and
testing if element is included in set.

>From this point i even consider it could be better than using negative
values, if you provide a little more arguments
that there are no any risks :)

>>
>> i can implement it, if you want.
>>
>> The number of changes is quite minimal, and won't make image to die
>> violently, because:
>>  - currently all sets having tally >=0, so even if you change things
>> to support nils as i proposing, no existing sets having chances to
>> behave differently
>>  - currently all sets can't meaningfully include nil, and there is no
>> code which intentionally puts nil in sets, because it leads to error.
>>
>> 2009/11/12 Eliot Miranda <eliot.miranda@...>:
>> >
>> >
>> > On Wed, Nov 11, 2009 at 3:14 PM, Russell N Hyer
>> > <hrothgar.ofstingan@...> wrote:
>> >>
>> >> I still don't comprehend the purpose behind having more than one
>> >> flavour of empty in regards to empty set based mathematics.
>> >
>> > nil is an object like any other, and Sets can contain arbitrary objects.
>> > An empty Set contains no objects.  The fact that internally an empty Set
>> > has
>> > some slots intialized to nil is an implementation detail that in no way
>> > implies that it contains nil.
>> > So if sets are capable of including arbitrary objects they should be
>> > able to
>> > contain nil.  There are lots of contexts in which having collections
>> > that
>> > can include nil is useful.  The compiler is one.  Storing and
>> > reconstituting
>> > object graphs is another.
>> > Or in summary nil ~~ #isEmpty.
>> > HTH
>> > Eliot
>> >>
>> >> 2009/11/11, Igor Stasenko <siguctua@...>:
>> >> > Just want to add that enabling a set to contain nils already
>> >> > discussed
>> >> > before.
>> >> >
>> >> >
>> >> >
>> >> >
http://n4.nabble.com/squeak-dev-Letting-Set-contain-nils-td69437.html#a69437
>> >> >
>> >> > ... and as you may guess, i supporting Levente in this :)
>> >> >
>> >> > --
>> >> > Best regards,
>> >> > Igor Stasenko AKA sig.
>> >> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

On Wed, 2009-11-11 at 09:54 -0600, Chris Muller wrote:
> > This morning the magma list had a report that a recent pharo change had
> > broken magma (slightly), with the maintainer indicating he needs some
> > help in dealing with such changes now and in the future.
>
> I think even with "(slightly)" your words are (slightly) too strong.
> :)  Perhaps actually MY words in the original post were too strong
> too.
>
> It's just a Monticello informative "warning" Ross, indicating three
> extension methods for serializing/materializing the global EventSensor
> will not be loaded.
>
> 99% of applications would not ever want to try to serialize that, so
> it won't be a real problem for them.
>
> Regards,
>   Chris
>
I thought the issue was not that someone would want to serialize a
sensor, but that with the rename it might get persisted as part of an
object graph, with weird results if it ever came back from the database
into, e.g., a different image (or maybe even the same image).

Equivalently, I thought the methods on EventSensor kept it from being
persisted, and that the new InputEventSensor (?) in pharo will lack such
protection.

My understanding may well be incorrect.

Ross

@Levente..
there is no need to introduce a 'containsNil' flag, nor use other than
nil filler object.
The tally ivar, which is already there can be used to reflect if set
contains nil:

tally >= 0  - set contains tally number of elements without nil
tally == -1 - set contains only single element - nil
tally < -1  - set contains a (tally abs) number of elements including nil

i can implement it, if you want.

The number of changes is quite minimal, and won't make image to die
violently, because:
  - currently all sets having tally >=0, so even if you change things
to support nils as i proposing, no existing sets having chances to
behave differently
  - currently all sets can't meaningfully include nil, and there is no
code which intentionally puts nil in sets, because it leads to error.

2009/11/12 Eliot Miranda <eliot.miranda@...>:
>
>
> On Wed, Nov 11, 2009 at 3:14 PM, Russell N Hyer
> <hrothgar.ofstingan@...> wrote:
>>
>> I still don't comprehend the purpose behind having more than one
>> flavour of empty in regards to empty set based mathematics.
>
> nil is an object like any other, and Sets can contain arbitrary objects.
> An empty Set contains no objects.  The fact that internally an empty Set has
> some slots intialized to nil is an implementation detail that in no way
> implies that it contains nil.
> So if sets are capable of including arbitrary objects they should be able to
> contain nil.  There are lots of contexts in which having collections that
> can include nil is useful.  The compiler is one.  Storing and reconstituting
> object graphs is another.
> Or in summary nil ~~ #isEmpty.
> HTH
> Eliot
>>
>> 2009/11/11, Igor Stasenko <siguctua@...>:
>> > Just want to add that enabling a set to contain nils already discussed
>> > before.
>> >
>> >
>> >
http://n4.nabble.com/squeak-dev-Letting-Set-contain-nils-td69437.html#a69437
>> >
>> > ... and as you may guess, i supporting Levente in this :)
>> >
>> > --
>> > Best regards,
>> > Igor Stasenko AKA sig.
>> >



--
Best regards,
Igor Stasenko AKA sig.

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2009-November/001769.html

Name: Tools-nice.141
Ancestors: Tools-nice.140

Correct http://code.google.com/p/pharo/issues/detail?id=1425
an inspector wouldn't handle a variableSubclass with instance variables
correctly

Also change a ((select:) detect:) construct, to rather use (detect: [and: []])
As said in the comment, the code already is ugly enough.

=============================================

I still don't comprehend the purpose behind having more than one
flavour of empty in regards to empty set based mathematics.

2009/11/11, Igor Stasenko <siguctua@...>:
> Just want to add that enabling a set to contain nils already discussed
> before.
>
> http://n4.nabble.com/squeak-dev-Letting-Set-contain-nils-td69437.html#a69437
>
> ... and as you may guess, i supporting Levente in this :)
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Just want to add that enabling a set to contain nils already discussed before.

http://n4.nabble.com/squeak-dev-Letting-Set-contain-nils-td69437.html#a69437

... and as you may guess, i supporting Levente in this :)

--
Best regards,
Igor Stasenko AKA sig.

2009/11/11 Russell N Hyer <hrothgar.ofstingan@...>:
> Sets already contain nil,
>
> Evaluate this, for example:
>
> | badger |
>
> badger := Set new.
> badger add: 1.
> badger inspect
>
> and you'll see there are already nils!
>
No no. This is cheating. Nobody is interested in the ways how object
manages its internal state. The most interesting is
how good its public interface.
The right test to check if set contains nil is to send:

badger includes: nil.

and what Levente proposing is obviously that such test should return
true, if you send

badger add: nil

before.

> 2009/11/11, Levente Uzonyi <leves@...>:
>> Hi!
>>
>> On Wed, 11 Nov 2009, Russell N Hyer wrote:
>>
>>> So you're really talking about having two types of null?
>>>
>> No. I'm talking about letting a set contain nil. Try evaluating Set with:
>> nil. and you will see what my problem is.
>>
>>> nil being the set that contains nothing
>>>
>> nil is not a set. Set new gives you an empty set.
>>
>> Cheers,
>> Levente
>>
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Hi!

On Wed, 11 Nov 2009, Russell N Hyer wrote:

> Sets already contain nil,
>
> Evaluate this, for example:
>
> | badger |
>
> badger := Set new.
> badger add: 1.
> badger inspect
>
> and you'll see there are already nils!

Not exactly. Just because you see nils in the inspector it doesn't mean
the set contains it. Try this: Set new add: 1; includes: nil.
Nils in the inspector only mean that empty slots in array are
marked with nil. You may find the class comment of Set helpful.

Cheers,
Levente

Sets already contain nil,

Evaluate this, for example:

| badger |

badger := Set new.
badger add: 1.
badger inspect

and you'll see there are already nils!

2009/11/11, Levente Uzonyi <leves@...>:
> Hi!
>
> On Wed, 11 Nov 2009, Russell N Hyer wrote:
>
>> So you're really talking about having two types of null?
>>
> No. I'm talking about letting a set contain nil. Try evaluating Set with:
> nil. and you will see what my problem is.
>
>> nil being the set that contains nothing
>>
> nil is not a set. Set new gives you an empty set.
>
> Cheers,
> Levente
>
>

Hi,

I uploaded a new version of MC which includes some speedup for
MCFileRepositoryInspector which greatly affects the ui experience
if you have more than a few packages and versions.

Cheers,
Levente

Nicolas Cellier uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-nice.141.mcz

==================== Summary ====================

Name: Tools-nice.141
Author: nice
Time: 11 November 2009, 7:27:03 am
UUID: 53223aaf-29e0-4ae8-88ae-7595b9d0645f
Ancestors: Tools-nice.140

Correct http://code.google.com/p/pharo/issues/detail?id=1425
an inspector wouldn't handle a variableSubclass with instance variables
correctly

Also change a ((select:) detect:) construct, to rather use (detect: [and: []])
As said in the comment, the code already is ugly enough.

=============== Diff against Tools-nice.140 ===============

Item was changed:
   ----- Method: Debugger>>getTextMorphWithSelection (in category 'tally
support') -----
   getTextMorphWithSelection
  	 "This is extremely ugly... We I need to get a reference of the code pane,
which is not easily accessible"
+  ^self dependents
+ 	 detect: [:m| (m isKindOf: PluggableTextMorph)
+ 		 and: [m selectionInterval first > 1]]
+ 	 ifNone: [nil]!
-  ^ (self dependents select: [:m| m isKindOf: PluggableTextMorph])
- 	 detect: [:m| m selectionInterval first > 1] ifNone: [nil]!

Item was changed:
   ----- Method: Inspector>>replaceSelectionValue: (in category 'selecting')
-----
   replaceSelectionValue: anObject
  	 "The receiver has a list of variables of its inspected object. One of these
  	 is selected. The value of the selected variable is set to the value,
  	 anObject."
+  | basicIndex si instVarIndex |
-  | basicIndex si |
  	 selectionIndex <= 2 ifTrue: [
  		 self toggleIndex: (si := selectionIndex).
  		 self toggleIndex: si.
  		 ^ object].
+  instVarIndex := selectionIndex - 2.
+  instVarIndex > object class instSize
+ 	 ifFalse: [^ object instVarAt: instVarIndex put: anObject].
+  object class isVariable or: [self error: 'Cannot replace selection'].
-  object class isVariable
- 	 ifFalse: [^ object instVarAt: selectionIndex - 2 put: anObject].
  	 basicIndex := selectionIndex - 2 - object class instSize.
  	 (object basicSize <= (self i1 + self i2)  or: [basicIndex <= self i1])
  		 ifTrue: [^object basicAt: basicIndex put: anObject]
  		 ifFalse: [^object basicAt: object basicSize - (self i1 + self i2) +
basicIndex
  					 put: anObject]!

Hi!

On Wed, 11 Nov 2009, Russell N Hyer wrote:

> So you're really talking about having two types of null?
>
No. I'm talking about letting a set contain nil. Try evaluating Set with:
nil. and you will see what my problem is.

> nil being the set that contains nothing
>
nil is not a set. Set new gives you an empty set.

Cheers,
Levente

So you're really talking about having two types of null?

nil being the set that contains nothing

and nil & null being the set that contains nothing and an unknown.

How are we meant to do mathematical operations on those two sets ?

and isn't nil the same as the empty set ?

{} ?

2009/11/11, Levente Uzonyi <leves@...>:
> Hi,
>
> Here are some ideas that I would like to see in the trunk:
> - create a common superclass (HashedCollection) for Set and Dictionary
> - since #valuesDo: is the same as #do: in dictionaries, we should only
> implement one of them. I'd go for implementing #do: and #valuesDo:
> would send #do:
> - add Andres' changes (or something similar)
> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/015464.html
>
> which help with weak hash values (#identityHash).
> - enable Sets to contain nil by using another object for marking empty slots
> - review/add tests
> - review/add class/method comments
> - since Dictionary >> #keys returns an Array, dictionaries could
> implement #keySet which would return a set with the dictionary's keys,
> the implementation could be nearly as fast as #keys
> - harvest fixes/tweaks from mantis
>
> Some of these would affect other parts of the system, some may not be
> useful, so I'm interested about your opinion before I start commiting.
>
> Cheers,
> Levente
>
>
>

> This morning the magma list had a report that a recent pharo change had
> broken magma (slightly), with the maintainer indicating he needs some
> help in dealing with such changes now and in the future.

I think even with "(slightly)" your words are (slightly) too strong.
:)  Perhaps actually MY words in the original post were too strong
too.

It's just a Monticello informative "warning" Ross, indicating three
extension methods for serializing/materializing the global EventSensor
will not be loaded.

99% of applications would not ever want to try to serialize that, so
it won't be a real problem for them.

Regards,
   Chris

Hi,

Here are some ideas that I would like to see in the trunk:
- create a common superclass (HashedCollection) for Set and Dictionary
- since #valuesDo: is the same as #do: in dictionaries, we should only
implement one of them. I'd go for implementing #do: and #valuesDo:
would send #do:
- add Andres' changes (or something similar)
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/015464.html
which help with weak hash values (#identityHash).
- enable Sets to contain nil by using another object for marking empty slots
- review/add tests
- review/add class/method comments
- since Dictionary >> #keys returns an Array, dictionaries could
implement #keySet which would return a set with the dictionary's keys,
the implementation could be nearly as fast as #keys
- harvest fixes/tweaks from mantis

Some of these would affect other parts of the system, some may not be
useful, so I'm interested about your opinion before I start commiting.

Cheers,
Levente