[squeak-dev] Letting Set contain nils?
Locked
12
12
Re: [squeak-dev] Letting Set contain nils?
 
|
Eliot Miranda writes:
> Depends. In an Interpreter obj == self likely to be slightly faster than > obj == nil since nil must be fetched either form the specialObjectsArray (if > bytecode set has pushNl, as it does) or from the method's literal frame. In > a JIT they're liely the same because self is a read through the frame > pointer and nil is a constant embedded in the instruction stream. These are > likely to be of similar cost. > > obj isNil will either be the same cost as == nil or slower depending on > whether the bytecode compiler inlines it. > But the difference between obj == self & obj == nil/obj isNil will be in the > noise. > > You should make the decision on convenience. > > what is faster/slower? > > > anArray asSet size is faster than any of the alternatives because it is > easier to thunk about ;) Faster thought is much more valuable than faster > processing, c.f. Smalltalk programs vs C++ programs ;) In Exupery at the moment obj == self is likely to be the fastest as self is held in a register. obj == nil would involve going to either the method's literal frame or the special object array. Exupery doesn't hold direct references to objects in native code outside of it's PICs, this is to simplify interaction with the GC. But it's possible to add reasonably generic optimisations that make other versions as fast. Don't worry too much about it, unless you really need the speed, then benchmark yourself. Bryce |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by Igor Stasenko
When Sets are created the array holding the values is of course filled
with nils by the VM. Using any other object to signify 'this slot is empty' would of course cost time to iterate over the array and fill each slot. Then for every grow it would cost more time to fill the new slots with this other distinguished value. If you really, really, need a form of Set that can include nil as a useful object (for want of a better word) then make a new SetWithNils class or similar. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- AMICUS PURIAE - Platonic friend |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
On Sat, Aug 9, 2008 at 10:25 AM, tim Rowledge <[hidden email]> wrote: When Sets are created the array holding the values is of course filled with nils by the VM. Using any other object to signify 'this slot is empty' would of course cost time to iterate over the array and fill each slot. Then for every grow it would cost more time to fill the new slots with this other distinguished value. No it _would not_. With a primitive that took the argument to fill with it would take no extra time. e.g. Behavior methods for instance creation
basicNew: sizeRequested withAll: defaultValue "Primitive. Answer an instance of this class with the number of indexable
variables specified by the argument, sizeRequested, initialized with defaultValue. Fail if this class is not indexable or if the argument is not a positive Integer, or if
there is not enough memory available. Essential. See Object documentation whatIsAPrimitive." <primitive: NNN>
self isVariable ifFalse: [self error: self printString, ' cannot have variable sized instances'].
(sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: ["arg okay; space must be low."
OutOfMemory signal. ^ self basicNew: sizeRequested withAll: defaultValue "retry if user proceeds"].
self primitiveFailed
new: sizeRequested withAll: defaultValue "Answer an initialized instance of this class with the number of indexable
variables specified by the argument, sizeRequested, and all indexable slots filled with defaultValue." ^ (self basicNew: sizeRequested withAll: defaultValue) initialize
Set methods for private init: n "Initialize array to an array size of n"
array := Array new: n withAll: self. tally := 0 and delete ArrayedCollection class>>new:withAll:
Throughout these conversations I'm reminded of the song Little Boxes... It would be nice to think outside of them occasionally...
If you really, really, need a form of Set that can include nil as a useful object (for want of a better word) then make a new SetWithNils class or similar. Indeed. But before the standards committee comes down on us hard can we not discuss the concept first? Or are you still venting over _ being replaced with :=, or with:......with: being replaced with, gasp, horror, *curly braces* argh!!!! Ohhhh noooo, mister bill......
Fractured Idiom:- AMICUS PURIAE - Platonic friend |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
On 9-Aug-08, at 12:15 PM, Eliot Miranda wrote: > > > On Sat, Aug 9, 2008 at 10:25 AM, tim Rowledge <[hidden email]> > wrote: > When Sets are created the array holding the values is of course > filled with nils by the VM. Using any other object to signify 'this > slot is empty' would of course cost time to iterate over the array > and fill each slot. Then for every grow it would cost more time to > fill the new slots with this other distinguished value. > > No it _would not_. With a primitive that took the argument to fill > with it would take no extra time. e.g. Oh sure, add a prim to support a tacky idea. At least extend it to improve interrupt response time, like we did at Interval. First step is to create a suitably sized WordArray without bothering to set the contents to anything, which is ok since it won't be scanned for GC. Then fill with suitable value words. Then convert to originally wanted class of array. Then return the finished object. Each step is either very quick or easily and safely interrupted/ resumed so as to allow interrupt response times helpful to media systems even in the face of very large arrays. > > Indeed. But before the standards committee comes down on us hard > can we not discuss the concept first? Or are you still venting over > _ being replaced with :=, or with:......with: being replaced with, > gasp, horror, *curly braces* argh!!!! Ohhhh noooo, mister bill...... Oh for fuck's sake. I've really had enough of this. Bye. |
|
|
In reply to this post by Giovanni Corriga
> > Could it be that you're possibly missing an abstraction here? why not > use a different object, specialized for your needs, to represent your > null value? > > Giovanni > Because as mentioned before, the most typical use case/failure mode is due to the fact that.... anArray asSet cannot be guaranteed to work for all arrays. The solution whereby a Set uses itself as a null-marker solves this problem completely. The only reason for not doing this before was the supposed speed penalty, now that Eliot says this is irrelevant this "fix" should be retro fitted, or at least a candidate for spoon. Keith |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by Eliot Miranda-2
Eliot
It would be great if we could have such nice primitive. Do you plan to add it in COG. I hope so. Stef On Aug 9, 2008, at 9:15 PM, Eliot Miranda wrote: > > > On Sat, Aug 9, 2008 at 10:25 AM, tim Rowledge <[hidden email]> > wrote: > When Sets are created the array holding the values is of course > filled with nils by the VM. Using any other object to signify 'this > slot is empty' would of course cost time to iterate over the array > and fill each slot. Then for every grow it would cost more time to > fill the new slots with this other distinguished value. > > No it _would not_. With a primitive that took the argument to fill > with it would take no extra time. e.g. > > Behavior methods for instance creation > basicNew: sizeRequested withAll: defaultValue > "Primitive. Answer an instance of this class with the number of > indexable > variables specified by the argument, sizeRequested, initialized > with defaultValue. > Fail if this class is not indexable or if the argument is not a > positive Integer, or if > there is not enough memory available. Essential. See Object > documentation whatIsAPrimitive." > > <primitive: NNN> > self isVariable ifFalse: > [self error: self printString, ' cannot have variable sized > instances']. > (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: > ["arg okay; space must be low." > OutOfMemory signal. > ^ self basicNew: sizeRequested withAll: defaultValue "retry if > user proceeds"]. > self primitiveFailed > > new: sizeRequested withAll: defaultValue > "Answer an initialized instance of this class with the number of > indexable > variables specified by the argument, sizeRequested, and all > indexable slots filled with defaultValue." > > ^ (self basicNew: sizeRequested withAll: defaultValue) initialize > > Set methods for private > init: n > "Initialize array to an array size of n" > array := Array new: n withAll: self. > tally := 0 > > and delete ArrayedCollection class>>new:withAll: > > > Throughout these conversations I'm reminded of the song Little > Boxes... It would be nice to think outside of them occasionally... > > If you really, really, need a form of Set that can include nil as a > useful object (for want of a better word) then make a new > SetWithNils class or similar. > > Indeed. But before the standards committee comes down on us hard > can we not discuss the concept first? Or are you still venting over > _ being replaced with :=, or with:......with: being replaced with, > gasp, horror, *curly braces* argh!!!! Ohhhh noooo, mister bill...... > > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Fractured Idiom:- AMICUS PURIAE - Platonic friend > > > > > |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
2008/8/10 stephane ducasse <[hidden email]>:
> Eliot > > It would be great if we could have such nice primitive. Do you plan to add > it in COG. I hope so. > This would require a little changes i think. All allocations end up with a method: allocate: byteSize headerSize: hdrSize h1: baseHeader h2: classOop h3: extendedSize doFill: doFill with: fillWord as you see, there is already a #doFill:with: in the tail, so it would need simply to accept an extra argument higher in the chain of invocations which serving to allocate object(s). > Stef > > On Aug 9, 2008, at 9:15 PM, Eliot Miranda wrote: > >> >> >> On Sat, Aug 9, 2008 at 10:25 AM, tim Rowledge <[hidden email]> wrote: >> When Sets are created the array holding the values is of course filled >> with nils by the VM. Using any other object to signify 'this slot is empty' >> would of course cost time to iterate over the array and fill each slot. Then >> for every grow it would cost more time to fill the new slots with this other >> distinguished value. >> >> No it _would not_. With a primitive that took the argument to fill with >> it would take no extra time. e.g. >> >> Behavior methods for instance creation >> basicNew: sizeRequested withAll: defaultValue >> "Primitive. Answer an instance of this class with the number of >> indexable >> variables specified by the argument, sizeRequested, initialized >> with defaultValue. >> Fail if this class is not indexable or if the argument is not a >> positive Integer, or if >> there is not enough memory available. Essential. See Object documentation >> whatIsAPrimitive." >> >> <primitive: NNN> >> self isVariable ifFalse: >> [self error: self printString, ' cannot have variable sized >> instances']. >> (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: >> ["arg okay; space must be low." >> OutOfMemory signal. >> ^ self basicNew: sizeRequested withAll: defaultValue "retry >> if user proceeds"]. >> self primitiveFailed >> >> new: sizeRequested withAll: defaultValue >> "Answer an initialized instance of this class with the number of >> indexable >> variables specified by the argument, sizeRequested, and all >> indexable slots filled with defaultValue." >> >> ^ (self basicNew: sizeRequested withAll: defaultValue) initialize >> >> Set methods for private >> init: n >> "Initialize array to an array size of n" >> array := Array new: n withAll: self. >> tally := 0 >> >> and delete ArrayedCollection class>>new:withAll: >> >> >> Throughout these conversations I'm reminded of the song Little Boxes... >> It would be nice to think outside of them occasionally... >> >> If you really, really, need a form of Set that can include nil as a useful >> object (for want of a better word) then make a new SetWithNils class or >> similar. >> >> Indeed. But before the standards committee comes down on us hard can we >> not discuss the concept first? Or are you still venting over _ being >> replaced with :=, or with:......with: being replaced with, gasp, horror, >> *curly braces* argh!!!! Ohhhh noooo, mister bill...... >> >> >> >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> Fractured Idiom:- AMICUS PURIAE - Platonic friend >> >> >> >> >> > > > -- Best regards, Igor Stasenko AKA sig. |
[squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by Igor Stasenko
Hi Igor,
How about creating a new class called #MetaUndefinedObject or #MetaNil. Stick it between #Object and #UndefinedObject. By definition it would never be used as an object, it would only be used as a filler for collections like #Set, indicating that no "real" object is present. This would allow nil to be used in sets and elsewhere and allow it to be placed in a set from a database row where a column is null without changing other code. This would not solve the recursive collection problem but that could be solved at it source. Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:[hidden email] http://www.Keystone-Software.com |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
2008/8/10 Louis LaBrunda <[hidden email]>:
> Hi Igor, > > How about creating a new class called #MetaUndefinedObject or #MetaNil. Stick > it between #Object and #UndefinedObject. By definition it would never be used > as an object, it would only be used as a filler for collections like #Set, > indicating that no "real" object is present. > > This would allow nil to be used in sets and elsewhere and allow it to be placed > in a set from a database row where a column is null without changing other code. > > This would not solve the recursive collection problem but that could be solved > at it source. This is nothing better than current sets, because you allowing sets to contain nil, but at the same time disallow MetaNil instance to be included into a set as an element. My point is to make sets which can contain ANY object without discrimination. > > Lou > ----------------------------------------------------------- > Louis LaBrunda > Keystone Software Corp. > SkypeMe callto://PhotonDemon > mailto:[hidden email] http://www.Keystone-Software.com > -- Best regards, Igor Stasenko AKA sig. |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
Igor Stasenko schrieb:
> > My point is to make sets which can contain ANY object without discrimination. > this topic has probably already been beaten to death, but here's another idea: Since sets need to mark unused slots and use nil for that purpose, they cannot contain nil directly. But it would be simple to just add an instance variable 'includesNil' which gets set to true when nil is added, and which would be used for enumeration and inclusion testing. Regarding the fear that making sets accept nil would break existing code: it would not, but it would probably encourage users to write code which won't work on other Smalltalk systems where this is not supported, so in the interest of easier code interchange I'd leave it out, even though it would make some sense in certain situations. Cheers, Hans-Martin |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
2008/8/10 Hans-Martin Mosner <[hidden email]>:
> Igor Stasenko schrieb: >> >> My point is to make sets which can contain ANY object without discrimination. >> > this topic has probably already been beaten to death, it is certain that your post putting last nail to its coffin, because what you proposing is already described early in this topic :) > but here's another > idea: > Since sets need to mark unused slots and use nil for that purpose, they > cannot contain nil directly. > But it would be simple to just add an instance variable 'includesNil' > which gets set to true when nil is added, and which would be used for > enumeration and inclusion testing. > > Regarding the fear that making sets accept nil would break existing > code: it would not, but it would probably encourage users to write code > which won't work on other Smalltalk systems where this is not supported, > so in the interest of easier code interchange I'd leave it out, even > though it would make some sense in certain situations. > > Cheers, > Hans-Martin > > -- Best regards, Igor Stasenko AKA sig. |
[squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by Igor Stasenko
>This is nothing better than current sets, because you allowing sets to
>contain nil, but at the same time disallow MetaNil instance to be >included into a set as an element. >My point is to make sets which can contain ANY object without discrimination. Not exactly. Yes, MetaNil is an object, since everything in Smalltalk is an object. But by definition MetaNil should not be used anywhere other than as this place holder in Sets (or other collection objects that may need it). MetaNils should never find there way outside of these collections. If someone is foolish enough to use them elsewhere, they get what they deserve. Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:[hidden email] http://www.Keystone-Software.com |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by Igor Stasenko
Igor Stasenko schrieb:
> > it is certain that your post putting last nail to its coffin, because > what you proposing is already described early in this topic :) > > Oh well, shows how well I've followed the thread... not! |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by Louis LaBrunda
One thing we discussed at some length in VisualWorks is a polymorphic solution for empty slots and "expired" weak references. In Squeak a WeakArray's references to reclaimed objects are replaced with nil. In VisualWorks they are replaced with 0. Replacing with 0 allows a weak collection to identify the references just dropped. A typical weak collection will be finalized and in its finalization code will scan for 0's and process corresponding entries for those indices held off to the side (e.g. finalizable copies). As each 0 is encountered it will be replaced with nil.
THis obviously poses a problem for e.g. hashed collections as these can either no longer contain 0 or must be made thread-safe and have the finlaization code effectively atomically set all 0's to nil. But the thread-safe solution works only for uses less than the finalization process's priority. The sketch solution we came up with is to introduce two singletons, unbound and tombstone which both answer true to isUnbound and all other objects answer false. tombstone answers true to isTombstone and all other objects answer false. Expired weak references are overwritten with tombstone and hashed collections check for an unbound slot with isUnbound and an expired reference with isTombstone. This has support code in the VM but has yet to be implemented in the image. The VM's tombstone remains set to 0. Hopefully this bites fewer users than nil as an unbound marker but there will still be system contexts where unbound is a value that needs to be dealt with (SystemTracer et al). So the catch is that one has introduced more complexity with its own attendant problems.
On Sun, Aug 10, 2008 at 8:16 AM, Louis LaBrunda <[hidden email]> wrote: Hi Igor, |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by stephane ducasse
On Sun, Aug 10, 2008 at 2:29 AM, stephane ducasse <[hidden email]> wrote: Eliot I shall do. It is straight-forward.
|
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
In reply to this post by Igor Stasenko
On Sun, Aug 10, 2008 at 5:24 PM, Igor Stasenko <[hidden email]> wrote:
> 2008/8/10 Louis LaBrunda <[hidden email]>: >> Hi Igor, >> >> How about creating a new class called #MetaUndefinedObject or #MetaNil. Stick >> it between #Object and #UndefinedObject. By definition it would never be used >> as an object, it would only be used as a filler for collections like #Set, >> indicating that no "real" object is present. >> >> This would allow nil to be used in sets and elsewhere and allow it to be placed >> in a set from a database row where a column is null without changing other code. >> >> This would not solve the recursive collection problem but that could be solved >> at it source. > > This is nothing better than current sets, because you allowing sets to > contain nil, but at the same time disallow MetaNil instance to be > included into a set as an element. > My point is to make sets which can contain ANY object without discrimination. He said explicitly that MetaNil wouldn't be an object, therefor no one could try to put it in anything. Think of something like "unbound" in Lisp. Of course this would likely be a huge change. |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
>>>>> "Jason" == Jason Johnson <[hidden email]> writes:
Jason> He said explicitly that MetaNil wouldn't be an object, therefor no one Jason> could try to put it in anything. Think of something like "unbound" in Jason> Lisp. Of course this would likely be a huge change. To create the first non-object in a sea of objects will likely break every bit of inspection, introspection, copying, storing, and what not that we already have. This sounds far scarier than the "fill with self" strategies or the "includesNil" strategies already described. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <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 |
Re: [squeak-dev] Re: Letting Set contain nils?
|
|
> Jason> He said explicitly that MetaNil wouldn't be an object, therefor no one > Jason> could try to put it in anything. Think of something like "unbound" in > Jason> Lisp. Of course this would likely be a huge change. > > To create the first non-object in a sea of objects will likely break every bit > of inspection, introspection, copying, storing, and what not that we already > have. This sounds far scarier than the "fill with self" strategies or the > "includesNil" strategies already described. > it would just not be Smalltalk anymore... Stef |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |