- Pharo-dev - lists.pharo.org

[Pharo-project] Xtreams updates: positioning, slicing and stitching

by mkobetic＠gmail.com

I updated the Xtreams port (http://www.squeaksource.com/Xtreams) over the holidays to catch up with the state on VW side. The primary changes are updates/fixes of the positioning API and a cleanup/extension of the slicing API. The slicers are replaced by much simpler #slicing setup and the inverse, #stitching, was added (the updated documentation can be found in the usual place: http://code.google.com/p/xtreams/wiki/Substreams) More details on the changes below. Enjoy, Martin Positioning updates: * ++/--/+=/-=/position: now return the argument instead of self * they all also skip as far as they can raising Incomplete with the count of the actual amount skipped * this means that the positioning wrapper will advance as far forward as it needs to satisfy the request, in case of -= it means it will advance all the way to the end of the underlying stream. * similarly asking a positioning wrapper for length or available will make it advance to the end * in the other direction, positioning wrapper can't skip past the beginning of its buffer, so if the buffer window moves forward, so does the absolute position; position 0 is always the beginning of the buffer, whereever it is at any given moment * also extended ++ and -- to call the other if the argument is negative (it helps with implementation of the others) All read/write/positioning calls except put:/get/read: now consistently return element counts so that one can use a computation as an argument and then obtain the actual number in response. This simplifies common patterns like: actual := [ stream ++ (x max: y) ] on: Incomplete do: [ :ex | ex count ]. instead of: actual := x max: y. [ stream ++ actual ] on: Incomplete do: [ :ex | actual := ex count ]. Slicing/Stitching updates: Replacing all the -er: slicer creation methods with the new #slicing and adding complementary #stitching. * #slicing is sent to a substream "prototype" and clones it when next slice is needed, e.g. (stream limiting: 3) slicing * #stitching is sent to a read stream of streams and makes it look like one continuous stream [ stream limiting: stream get ] reading stitching * stitching replaces the experimental proto and concatentation streams * ReadStream>>, is now implemented with stitching too

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by StÃ©phane Ducasse

I like copyStateFrom: as a name lukas there is copyFrom:to: and copyFrom: make a lot of sense as copyFrom: index until the end. Stef

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by StÃ©phane Ducasse

right please open a bug entry and provide cs :) Stef > Yes, this method name is unfortunate... > > I think we should just rename the method and tag copyFrom: as deprecated. And some versions later we'll implement copyFrom: as we think is appropriate. > > Cheers, > Adrian > > BTW Sebastian, I think your energy would be better invested into producing a changeset and challenging the "invalid"-tag of Henrik in a rational way than to writing a "are you stupid?"-mail.

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by Schwab,Wilhelm K

Lukas, I must respectfully disagree: it is also quite similar to #copyFrom:to:, and behaves *completely* differently from same. #copyFrom: really should have a more intention-revealing name. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] Sent: Saturday, January 01, 2011 2:06 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: Quite some software (Seaside, Mondrian, Magritte, Pier, ...) depends on the current implementation of #copyFrom:, as it is an extremely efficient way to remember and restore the state of an object: rememberReceiverDuring: aBlock previous := self shallowCopy. ^ aBlock ensure: [ self copyFrom: previous ] I don't think that the name of #copyFrom: is misleading (it derives from #copy). What you are looking for is #allButFirst: that goes along with #allButFirst, #allButLast:, allButLast, #first:, and #last:. Cheers, Lukas On 1 January 2011 19:39, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Wow. In fairness, Dolphin has one or two such oddities. IIRC, the confusion there is that external arrays (DOUBLE, DWORD, etc.) respond to #copyFrom:to: in terms of bytes, not elements. > > The problem in this case appears to be that > > 'a string with some stuff in it' copyFrom:5 > > should blow up because 5 is not a suitable source (a string of some type) from which to copy a string's state. Once it properly reports abuse, we can then move on to asking whether we want a copying selector that can be so easily confused with copying from an index. It might be better named #copyStateFrom:?? > > Sorry to beat the usual drum, but it fits: silent failures need to be hunted down and killed. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, January 01, 2011 1:29 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: > > HI sebastian > > If I remember correctly you are not the only one bitten by it :) so we should do something > > Object>>copyFrom: anotherObject > "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. " > > Now you enumeration is too complex for me :) > >> I ask because, if so, situation goes like this: >> >> A. we think again and decide to do the right thing or we go with the alternative which is >> B. we leave it as invalid, as it is right now, and >> 1. we mislead even to smalltalkers not familiarized to squeak/pharo >> 2. we rationalize some clever way to see it as a feature even if it will mislead everybody (even ourselves in a hurry) >> 3. we lay a foundation to lightly use protocol that is typically used in collections (to do dangerous things like instVar manipulation) >> 4. we break encapsulation and manipulate extremely primitive things in a common sounding selector. >> 5. we work harder on trying to give the impression that we're leaving it like that because we're smarter than the confused people that tried to use it (proving to them that we're dumb) >> 6. we get involved in an unnecessarily complicated way of thinking that will complicate unnecessarily our future (guaranteed) >> 7. we learn how to maintain a screwed attitude in front of people trying to use intuition when using pharo >> 8. we stay comfortable (on the wrong foundation and for the wrong reasons) >> >> That would leave us with this question in the table: >> >> what is compatible with the Pharo's mission? is it A or B? > > My state of mind is always to make the world better :) > > Now > - did you check the senders to copyFrom:? > sounds ok not so many so we could deprecated it easily > > - did you check in other Smalltalk if this method is used or not? > VW not in Object but in probe something > > - did you check the ansi standard? > I guess that this is not there. > > The finder says: > 'if this isn''t broken' . 15 . 'broken' > > no single method, strange.... but indeed > 'if this isn''t broken' . 15 . 20 . 'broken' find copyFrom:to: > > Now what would be a better name > > copyFromObject: > > then > > on String>>copyFrom: ? > > Even if I would prefer (but it sucks) String>>copyFromIndex: but this is more coherent with copyFrom: index to: another > > > Stef > > > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by Schwab,Wilhelm K

Peter, Feel free to beat me to pointing out silent failures; I'm glad I'm not alone in seeing them as something to be found and eliminated, and it never hurts for the truth to be heard from multiple directions. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Peter Hugosson-Miller [oldmanlink(a)gmail.com] Sent: Saturday, January 01, 2011 2:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: Hehehe. While I was considering whether or not to chip in on this thread, two thoughts passed through my mind. The first was that this is one of those annoying silent failures that Wilhelm would surely pick up on (so I didn't need to bring it up). The second was that #copyFrom: really should be called #copyStateFrom: to more accurately reflect what it does, and should be used for. So now this reply is completely redundant, since Wilhelm also suggested the same thing, or maybe I should just stop here and write "+1" instead :-p -- Cheers, Peter On Sat, Jan 1, 2011 at 7:39 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Wow. In fairness, Dolphin has one or two such oddities. IIRC, the confusion there is that external arrays (DOUBLE, DWORD, etc.) respond to #copyFrom:to: in terms of bytes, not elements. The problem in this case appears to be that 'a string with some stuff in it' copyFrom:5 should blow up because 5 is not a suitable source (a string of some type) from which to copy a string's state. Once it properly reports abuse, we can then move on to asking whether we want a copying selector that can be so easily confused with copying from an index. It might be better named #copyStateFrom:?? Sorry to beat the usual drum, but it fits: silent failures need to be hunted down and killed. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: HI sebastian If I remember correctly you are not the only one bitten by it :) so we should do something Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. " Now you enumeration is too complex for me :) > I ask because, if so, situation goes like this: > > A. we think again and decide to do the right thing or we go with the alternative which is > B. we leave it as invalid, as it is right now, and > 1. we mislead even to smalltalkers not familiarized to squeak/pharo > 2. we rationalize some clever way to see it as a feature even if it will mislead everybody (even ourselves in a hurry) > 3. we lay a foundation to lightly use protocol that is typically used in collections (to do dangerous things like instVar manipulation) > 4. we break encapsulation and manipulate extremely primitive things in a common sounding selector. > 5. we work harder on trying to give the impression that we're leaving it like that because we're smarter than the confused people that tried to use it (proving to them that we're dumb) > 6. we get involved in an unnecessarily complicated way of thinking that will complicate unnecessarily our future (guaranteed) > 7. we learn how to maintain a screwed attitude in front of people trying to use intuition when using pharo > 8. we stay comfortable (on the wrong foundation and for the wrong reasons) > > That would leave us with this question in the table: > > what is compatible with the Pharo's mission? is it A or B? My state of mind is always to make the world better :) Now - did you check the senders to copyFrom:? sounds ok not so many so we could deprecated it easily - did you check in other Smalltalk if this method is used or not? VW not in Object but in probe something - did you check the ansi standard? I guess that this is not there. The finder says: 'if this isn''t broken' . 15 . 'broken' no single method, strange.... but indeed 'if this isn''t broken' . 15 . 20 . 'broken' find copyFrom:to: Now what would be a better name copyFromObject: then on String>>copyFrom: ? Even if I would prefer (but it sucks) String>>copyFromIndex: but this is more coherent with copyFrom: index to: another Stef

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by Peter Hugosson-Miller

Hehehe. While I was considering whether or not to chip in on this thread, two thoughts passed through my mind. The first was that this is one of those annoying silent failures that Wilhelm would surely pick up on (so I didn't need to bring it up). The second was that #copyFrom: really should be called #copyStateFrom: to more accurately reflect what it does, and should be used for. So now this reply is completely redundant, since Wilhelm also suggested the same thing, or maybe I should just stop here and write "+1" instead :-p -- Cheers, Peter On Sat, Jan 1, 2011 at 7:39 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Wow. In fairness, Dolphin has one or two such oddities. IIRC, the > confusion there is that external arrays (DOUBLE, DWORD, etc.) respond to > #copyFrom:to: in terms of bytes, not elements. > > The problem in this case appears to be that > > 'a string with some stuff in it' copyFrom:5 > > should blow up because 5 is not a suitable source (a string of some type) > from which to copy a string's state. Once it properly reports abuse, we can > then move on to asking whether we want a copying selector that can be so > easily confused with copying from an index. It might be better named > #copyStateFrom:?? > > Sorry to beat the usual drum, but it fits: silent failures need to be > hunted down and killed. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > [stephane.ducasse(a)inria.fr] > Sent: Saturday, January 01, 2011 1:29 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: > > HI sebastian > > If I remember correctly you are not the only one bitten by it :) so we > should do something > > Object>>copyFrom: anotherObject > "Copy to myself all instance variables I have in common with > anotherObject. This is dangerous because it ignores an object's control > over its own inst vars. " > > Now you enumeration is too complex for me :) > > > I ask because, if so, situation goes like this: > > > > A. we think again and decide to do the right thing or we go with the > alternative which is > > B. we leave it as invalid, as it is right now, and > > 1. we mislead even to smalltalkers not familiarized to squeak/pharo > > 2. we rationalize some clever way to see it as a feature even if it > will mislead everybody (even ourselves in a hurry) > > 3. we lay a foundation to lightly use protocol that is typically > used in collections (to do dangerous things like instVar manipulation) > > 4. we break encapsulation and manipulate extremely primitive things > in a common sounding selector. > > 5. we work harder on trying to give the impression that we're > leaving it like that because we're smarter than the confused people that > tried to use it (proving to them that we're dumb) > > 6. we get involved in an unnecessarily complicated way of thinking > that will complicate unnecessarily our future (guaranteed) > > 7. we learn how to maintain a screwed attitude in front of people > trying to use intuition when using pharo > > 8. we stay comfortable (on the wrong foundation and for the wrong > reasons) > > > > That would leave us with this question in the table: > > > > what is compatible with the Pharo's mission? is it A or B? > > My state of mind is always to make the world better :) > > Now > - did you check the senders to copyFrom:? > sounds ok not so many so we could deprecated it easily > > - did you check in other Smalltalk if this method is used or not? > VW not in Object but in probe something > > - did you check the ansi standard? > I guess that this is not there. > > The finder says: > 'if this isn''t broken' . 15 . 'broken' > > no single method, strange.... but indeed > 'if this isn''t broken' . 15 . 20 . 'broken' find copyFrom:to: > > Now what would be a better name > > copyFromObject: > > then > > on String>>copyFrom: ? > > Even if I would prefer (but it sucks) String>>copyFromIndex: but this is > more coherent with copyFrom: index to: another > > > Stef >

Jan. 1, 2011

Re: [Pharo-project] new Cog VMs

by Eliot Miranda

Hi Philippe, On Sat, Jan 1, 2011 at 4:06 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 31.12.2010 03:02, Eliot Miranda wrote: > > > > > > > > > > Hi All, > > > > I've released a new version of Cog that has a substantially > > improved code generator along the lines of Peter Deutsch's HPS > > (VisualWorks) and various of Ian Piumarta's VMs. These all use a simple > > tecnique to identify constant references in bytecode and to support a > > register-based calling convention. While this does produce faster code > > it tends to accelerate low-level code much more than high-level code as > > you can see by the following benchmarks: > > > > SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 > > StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 > > 192 - 691 / 6.91 -72% > > > > SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; > > 64769127 sends/sec' > > StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; > > 128157989 sends/sec' > > 931756141 - 753495217 / 7534952.17 -24% > > 128157989 - 64769127 / 647691.27 -98% > > > > SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no > > transcript > > StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no > > transcript) > > 43406 - 47013 / 470.13 -7.67234594686576 > > > > The status of this code is essentially beta. The test suite runs the > > same on the new code generator as on the old, but I think there are > > still bugs because I get the occasional transient error. I am therefore > > very interested in any reproducible errors you can find. > > > > The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a > > few other important changes: > > > > - a bug fix to bytecode<->native pc mappng that produced incorrect > > results for methods containing blocks with ^-returns in them. One > > symptom is incorrect highlighting of the pc in the debugger, althoguh > > symptoms could be much serious. > > > > - jitting interpreted methods on backward branches. Currently any > > interpreted method that performs more than 20 backward branches will be > > considered for JIT compilation and if it is suitable (default, <= 60 > > literals) will be compiled to native code. > > > > - new callback support. I need to commit some changes to the Alien > > package to provide access to this but essentially the VM's callback > > support is now able to be ported to architectures with register-based > > calling conventions (ARM, PowerPC, SPARC etc). I'll try and get the > > Alien code released soon, and to back-port the changes to the standard > > VM before the end of the holiday. > > > > One thing that is still /not/ fixed is the lack of a SoundPlugin on > > win32. Apologies. I'll try and get a fix for this before the end of > > the holidays too, but time might be too tight. There are other > > priorities such as harmonising the standard and Cog VMs for the 4.2 > release. > > I gave it a short test with the latest Seaside. > > First the good news, I seem to get an average performance improvement of > about 10%. > > However in some very rare cases the temps seem to be mixed up the very > first time a method is executed and fine afterwards. For example in the > method below when the div 'bench' is created. The very first time it is > executed #div is sent to a BlockClosure, the next time it is fine. This > is reproducible, if I recompile the package or restart the image it > happens again the first time and is fine afterwards. > I'm very interested in this because the way I've implemented the register based calling convention means that arguments and the return pc get rearranged at various places and typically activation code takes an alternate path the first time. So this seems indicative of a bug I would expect. > > I don't know how I can provide more information but I could upload the > image somewhere. > Please do. You can provide me with a URL. But also provide idiot instructions for reproducing the issue, e.g. a workspace expression or a carefully detailed set of user interface actions. Ideally (for me :) ) you'll produce an image that demonstrates the error on startup. e.g. by using the pattern Smalltalk saveAs. MyClass doSomething So that MyClass doSomething gets performed immediately on startup. Thanks! Eliot > > > renderInline: aBlock factor: factor key: key on: html > | startTime endTime count backColor anAssociation title > referenceValue > spi context document renderer stream runTime | > count := 0. > runTime := 200. > anAssociation := referenceDict > at: key > ifAbsent: [ 'Undefined' -> 100000 ]. > title := anAssociation key. > referenceValue := anAssociation value. > stream := WriteStream on: String new. > document := builder documentClass > on: stream > codec: builder codec. > context := WARenderContext new. > context document: document. > context > actionUrl: builder actionUrl; > resourceUrl: builder resourceUrl. > renderer := builder rendererClass context: context. > builder > openDocument: document > context: context. > html div > class: 'bench'; > with: > [ html heading: title. > startTime := Time millisecondClockValue. > endTime := startTime + runTime. > [ Time millisecondClockValue < endTime ] whileTrue: > [ count := count + 1. > renderer > render: aBlock; > flush ] ]. > builder closeDocument: document. > spi := (count / referenceValue * (10000 / runTime)) rounded. > backColor := spi > 100 > ifTrue: [ '#5f5' ] > ifFalse: > [ spi < 50 > ifTrue: [ '#f55' ] > ifFalse: [ '#55f' ] ]. > duration := duration + spi. > html div > style: 'float:left;padding:4px'; > with: > [ html big: spi greaseString , ' SPI'. > html span > class: 'iteration'; > with: '(' , count greaseString , ' > iterations)'. > html break. > html div > class: 'rect'; > style: 'background:' , backColor , ';width:' > , (spi * 2) > greaseString , 'px' ]. > html div style: 'clear:both' > > Cheers > Philippe > > >

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by Lukas Renggli

Quite some software (Seaside, Mondrian, Magritte, Pier, ...) depends on the current implementation of #copyFrom:, as it is an extremely efficient way to remember and restore the state of an object: rememberReceiverDuring: aBlock previous := self shallowCopy. ^ aBlock ensure: [ self copyFrom: previous ] I don't think that the name of #copyFrom: is misleading (it derives from #copy). What you are looking for is #allButFirst: that goes along with #allButFirst, #allButLast:, allButLast, #first:, and #last:. Cheers, Lukas On 1 January 2011 19:39, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Wow. Â In fairness, Dolphin has one or two such oddities. Â IIRC, the confusion there is that external arrays (DOUBLE, DWORD, etc.) respond to #copyFrom:to: in terms of bytes, not elements. > > The problem in this case appears to be that > > Â 'a string with some stuff in it' copyFrom:5 > > should blow up because 5 is not a suitable source (a string of some type) from which to copy a string's state. Â Once it properly reports abuse, we can then move on to asking whether we want a copying selector that can be so easily confused with copying from an index. Â It might be better named #copyStateFrom:?? > > Sorry to beat the usual drum, but it fits: silent failures need to be hunted down and killed. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, January 01, 2011 1:29 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: > > HI sebastian > > If I remember correctly you are not the only one bitten by it :) so we should do something > > Object>>copyFrom: anotherObject > Â Â Â Â "Copy to myself all instance variables I have in common with anotherObject. Â This is dangerous because it ignores an object's control over its own inst vars. Â " > > Now you enumeration is too complex for me :) > >> I ask because, if so, situation goes like this: >> >> A. we think again and decide to do the right thing or we go with the alternative which is >> B. we leave it as invalid, as it is right now, and >> Â Â Â 1. we mislead even to smalltalkers not familiarized to squeak/pharo >> Â Â Â 2. we rationalize some clever way to see it as a feature even if it will mislead everybody (even ourselves in a hurry) >> Â Â Â 3. we lay a foundation to lightly use protocol that is typically used in collections (to do dangerous things like instVar manipulation) >> Â Â Â 4. we break encapsulation and manipulate extremely primitive things in a common sounding selector. >> Â Â Â 5. we work harder on trying to give the impression that we're leaving it like that because we're smarter than the confused people that tried to use it (proving to them that we're dumb) >> Â Â Â 6. we get involved in an unnecessarily complicated way of thinking that will complicate unnecessarily our future (guaranteed) >> Â Â Â 7. we learn how to maintain a screwed attitude in front of people trying to use intuition when using pharo >> Â Â Â 8. we stay comfortable (on the wrong foundation and for the wrong reasons) >> >> That would leave us with this question in the table: >> >> what is compatible with the Pharo's mission? is it A or B? > > My state of mind is always to make the world better :) > > Now > - did you check the senders to copyFrom:? > Â Â Â Â sounds ok not so many so we could deprecated it easily > > - did you check in other Smalltalk if this method is used or not? > Â Â Â Â VW not in Object but in probe something > > - did you check the ansi standard? > Â Â Â Â I guess that this is not there. > > The finder says: > Â Â Â Â 'if this isn''t broken' . 15 . 'broken' > > no single method, strange.... but indeed > Â Â Â Â 'if this isn''t broken' . 15 . 20 . 'broken' find copyFrom:to: > > Now what would be a better name > > Â Â Â Â copyFromObject: > > then > > Â Â Â Â on String>>copyFrom: ? > > Even if I would prefer (but it sucks) String>>copyFromIndex: Â but this is more coherent with copyFrom: index to: another > > > Stef > > > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by Schwab,Wilhelm K

Wow. In fairness, Dolphin has one or two such oddities. IIRC, the confusion there is that external arrays (DOUBLE, DWORD, etc.) respond to #copyFrom:to: in terms of bytes, not elements. The problem in this case appears to be that 'a string with some stuff in it' copyFrom:5 should blow up because 5 is not a suitable source (a string of some type) from which to copy a string's state. Once it properly reports abuse, we can then move on to asking whether we want a copying selector that can be so easily confused with copying from an index. It might be better named #copyStateFrom:?? Sorry to beat the usual drum, but it fits: silent failures need to be hunted down and killed. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: HI sebastian If I remember correctly you are not the only one bitten by it :) so we should do something Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. " Now you enumeration is too complex for me :) > I ask because, if so, situation goes like this: > > A. we think again and decide to do the right thing or we go with the alternative which is > B. we leave it as invalid, as it is right now, and > 1. we mislead even to smalltalkers not familiarized to squeak/pharo > 2. we rationalize some clever way to see it as a feature even if it will mislead everybody (even ourselves in a hurry) > 3. we lay a foundation to lightly use protocol that is typically used in collections (to do dangerous things like instVar manipulation) > 4. we break encapsulation and manipulate extremely primitive things in a common sounding selector. > 5. we work harder on trying to give the impression that we're leaving it like that because we're smarter than the confused people that tried to use it (proving to them that we're dumb) > 6. we get involved in an unnecessarily complicated way of thinking that will complicate unnecessarily our future (guaranteed) > 7. we learn how to maintain a screwed attitude in front of people trying to use intuition when using pharo > 8. we stay comfortable (on the wrong foundation and for the wrong reasons) > > That would leave us with this question in the table: > > what is compatible with the Pharo's mission? is it A or B? My state of mind is always to make the world better :) Now - did you check the senders to copyFrom:? sounds ok not so many so we could deprecated it easily - did you check in other Smalltalk if this method is used or not? VW not in Object but in probe something - did you check the ansi standard? I guess that this is not there. The finder says: 'if this isn''t broken' . 15 . 'broken' no single method, strange.... but indeed 'if this isn''t broken' . 15 . 20 . 'broken' find copyFrom:to: Now what would be a better name copyFromObject: then on String>>copyFrom: ? Even if I would prefer (but it sucks) String>>copyFromIndex: but this is more coherent with copyFrom: index to: another Stef

Jan. 1, 2011

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

by Adrian Lienhard

Yes, this method name is unfortunate... I think we should just rename the method and tag copyFrom: as deprecated. And some versions later we'll implement copyFrom: as we think is appropriate. Cheers, Adrian BTW Sebastian, I think your energy would be better invested into producing a changeset and challenging the "invalid"-tag of Henrik in a rational way than to writing a "are you stupid?"-mail. On Jan 1, 2011, at 19:13 , Igor Stasenko wrote: > On 1 January 2011 18:15, Sebastian Sastre <seb(a)sebastianconcept.com> wrote: >> ('if this isn''t broken' copyFrom: 15) ~= 'broken' ifTrue:['this is >> screwed'] ifFalse:['this is intuitive'] > > my first thought about it was that it should answer own copy , > starting from 15th element :) > > >> Evaluate that in any Pharo workspace and it will show you. >> Reported here. >> Status? invalid > > but then i saw its implementation... ouch... > >> Came on guys. Really? >> I ask because, if so, situation goes like this: >> A. we think again and decide to do the right thing or we go with the >> alternative which is >> B. we leave it as invalid, as it is right now, and >> 1. we mislead even to smalltalkers not familiarized to squeak/pharo >> 2. we rationalize some clever way to see it as a feature even if it will >> mislead everybody (even ourselves in a hurry) >> 3. we lay a foundation to lightly use protocol that is typically used in >> collections (to do dangerous things like instVar manipulation) >> 4. we break encapsulation and manipulate extremely primitive things in a >> common sounding selector. >> 5. we work harder on trying to give the impression that we're leaving it >> like that because we're smarter than the confused people that tried to use >> it (proving to them that we're dumb) >> 6. we get involved in an unnecessarily complicated way of thinking that will >> complicate unnecessarily our future (guaranteed) >> 7. we learn how to maintain a screwed attitude in front of people trying to >> use intuition when using pharo >> 8. we stay comfortable (on the wrong foundation and for the wrong reasons) >> That would leave us with this question in the table: >> what is compatible with the Pharo's mission? is it A or B? >> > > hey. slow down.. > > 8 arguments is too much for it, but i can understand how deeply such > thing could hurt :) > > This is really screwed primitive. > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 1, 2011