January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] source.lukas-renggli.ch is down

by Lukas Renggli

Looks like it takes 1 or 2 weeks more, because during office hours I am (normally) not at home :-( Lukas On 2 January 2011 09:47, Max Leske <maxleske(a)gmail.com> wrote: > You will probably have to wait at least till tomorrow. Lukas' provider wont fix his line outside office hours. > > Max > > > On 02.01.2011, at 00:35, GermÃ¡n Arduino wrote: > >> Seems that it remains down still. A lot of things depending of the >> Lukas server are not working :( >> >> >> 2010/12/29 Torsten Bergmann <astares(a)gmx.de>: >>> and it is one of the reasons why the hudson build fails :( >>> >>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastFailedBui… >>> >>> Even when Lukas restores the server it would be good to use >>> community controlled squeaksource servers in the future instead >>> of personal servers (the "truck factor" - you know) >>> >>> Bye >>> T. >>> >>> >>> -- >>> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! >>> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail >>> >>> >> > > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2011

Re: [Pharo-project] Issue 3502 in pharo: DNU while parsing

by pharo＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 3502 by aplantec: DNU while parsing http://code.google.com/p/pharo/issues/detail?id=3502 since the requestor passed to a parser is the textMorph and no more the editor. The error protocol has to be fully implemented in textMorph. Normally, only #notify:at:in: is missing. SLICE-Issue-3502-DNU-while-parsing in InBox

Jan. 2, 2011

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

by StÃ©phane Ducasse

On Jan 2, 2011, at 1:33 AM, csrabak(a)bol.com.br wrote: > I would like to add to the tally. Changing Object>>copyFrom: to Object>>copyStateFrom: makes for me a lot more sense that changing (in fact by the creation of) OrderedCollection>>copyFrom: to OrderedCollection>>copyFromIndex: > > Except we do agree /in limine/ that OrderedCollection>>copyFrom:to: should be changed to > OrederedCollection>>copyFromIndex:toEndIndex: This is the problem I thought about it. so I think that we will have to stay with copyFrom: > > > > > > Em 01/01/2011 17:48, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: > 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 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. 2, 2011

Re: [Pharo-project] source.lukas-renggli.ch is down

by Max Leske

You will probably have to wait at least till tomorrow. Lukas' provider wont fix his line outside office hours. Max On 02.01.2011, at 00:35, GermÃ¡n Arduino wrote: > Seems that it remains down still. A lot of things depending of the > Lukas server are not working :( > > > 2010/12/29 Torsten Bergmann <astares(a)gmx.de>: >> and it is one of the reasons why the hudson build fails :( >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastFailedBui… >> >> Even when Lukas restores the server it would be good to use >> community controlled squeaksource servers in the future instead >> of personal servers (the "truck factor" - you know) >> >> Bye >> T. >> >> >> -- >> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! >> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail >> >> >

Jan. 2, 2011

Re: [Pharo-project] new Cog VMs

by Philippe Marschall

On 01.01.2011 21:38, Eliot Miranda wrote: > Hi All, > > there are new versions of both the SimpleStackBasedCogit and the > StackToRegisterMappingCogit Cog VMs in VM.r2337/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2337/> & VM.r2338/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2338/> respectively. > These contain fixes for another bad pc mapping bug that could cause > hard crashes when jitting on a backward branch in a looping interpreted > method. If you're trying to reproduce Cog crashes please upgrade to one > of tthese two VMs. > > TIA > and happy new 2011, P.S. according to an FBF > RT @dpp RT @giuliodeluise 2011 is a prime number & the sum of 11 > consecutive prime numbers: 2011=157+163+167+173+179+181+191+193+197+199+211 Crashes right at start up: Segmentation fault Smalltalk stack dump: 0xff8aafb4 M Error class(Exception class)>handles: -1246542340: a(n) Error class 0xff8aafdc M MethodContext(ContextPart)>handleSignal: -1220670568: a(n) MethodContext 0xff8aaffc M MethodContext(ContextPart)>handleSignal: -1216945468: a(n) MethodContext 0xff8ab020 I UnhandledError(Exception)>signal -1216945236: a(n) UnhandledError 0xff8ab040 I UnhandledError class>signalForException: -1246541380: a(n) UnhandledError class 0xff8ab064 I MessageNotUnderstood(Error)>defaultAction -1216945688: a(n) MessageNotUnderstood 0xff8ab084 I MessageNotUnderstood>defaultAction -1216945688: a(n) MessageNotUnderstood 0xff8ab0a8 I UndefinedObject>handleSignal: -1247481852: a(n) UndefinedObject 0xff8ab0cc I MessageNotUnderstood(Exception)>pass -1216945688: a(n) MessageNotUnderstood 0xff8ab0f8 I [] in PasteUpMorph>becomeActiveDuring: -1245846436: a(n) PasteUpMorph 0xff8ab11c I BlockClosure>valueWithPossibleArgs: -1221000224: a(n) BlockClosure 0xff8ab13c M [] in MethodContext(ContextPart)>handleSignal: -1220670568: a(n) MethodContext 0xff8ab15c M BlockClosure>ensure: -1216945284: a(n) BlockClosure 0xff8ab17c M MethodContext(ContextPart)>handleSignal: -1220670568: a(n) MethodContext 0xff8ab1a4 I MethodContext(ContextPart)>handleSignal: -1216945468: a(n) MethodContext 0xff8ab1c8 I MessageNotUnderstood(Exception)>signal -1216945688: a(n) MessageNotUnderstood 0xff8ab1f0 I ProcessorScheduler(Object)>doesNotUnderstand: >= -1247476532: a(n) ProcessorScheduler 0xff8ab210 M Process>priority: -1216945752: a(n) Process 0xff8ab238 I BlockClosure>forkAt: -1216945972: a(n) BlockClosure 0xff8ab25c I InputEventPollingFetcher(InputEventFetcher)>installEventLoop -1246030580: a(n) InputEventPollingFetcher 0xff8ab280 I InputEventPollingFetcher(InputEventFetcher)>startUp -1246030580: a(n) InputEventPollingFetcher 0xff8ab2a0 I InputEventFetcher class>startUp -1246046280: a(n) InputEventFetcher class 0xff8ab2b8 M InputEventFetcher class(Behavior)>startUp: -1246046280: a(n) InputEventFetcher class 0xff8ab2e0 M [] in SmalltalkImage>send:toClassesNamedIn:with: -1242015264: a(n) SmalltalkImage 0xff8ab2fc M BlockClosure>on:do: -1216946688: a(n) BlockClosure 0xff8ab32c M [] in SmalltalkImage>send:toClassesNamedIn:with: -1242015264: a(n) SmalltalkImage 0xff8ab354 I OrderedCollection>do: -1241999736: a(n) OrderedCollection 0xff8ab37c I SmalltalkImage>send:toClassesNamedIn:with: -1242015264: a(n) SmalltalkImage 0xff8ab3a8 I SmalltalkImage>processStartUpList: -1242015264: a(n) SmalltalkImage 0xff8ab3d4 I SmalltalkImage>snapshot:andQuit:embedded: -1242015264: a(n) SmalltalkImage -1220672224 s SmalltalkImage>snapshot:andQuit: -1220672132 s WorldState class>saveAndQuit -1220672040 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: -1220671948 s BlockClosure>ensure: -1220999860 s CursorWithMask(Cursor)>showWhile: -1220999972 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: -1220671856 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: -1220671764 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: -1220671672 s MouseButtonEvent>sentTo: -1220671580 s ToggleMenuItemMorph(Morph)>handleEvent: -1220671488 s MorphicEventDispatcher>dispatchDefault:with: -1220671396 s MorphicEventDispatcher>dispatchEvent:with: -1220671304 s ToggleMenuItemMorph(Morph)>processEvent:using: -1220671212 s MorphicEventDispatcher>dispatchDefault:with: -1220671120 s MorphicEventDispatcher>dispatchEvent:with: -1220671028 s MenuMorph(Morph)>processEvent:using: -1220670936 s MenuMorph(Morph)>processEvent: -1220670844 s MenuMorph>handleFocusEvent: -1220670752 s [] in HandMorph>sendFocusEvent:to:clear: -1220670660 s [] in PasteUpMorph>becomeActiveDuring: -1220670568 s BlockClosure>on:do: -1221000336 s PasteUpMorph>becomeActiveDuring: -1221000456 s HandMorph>sendFocusEvent:to:clear: -1220670476 s HandMorph>sendEvent:focus:clear: -1221000572 s HandMorph>sendMouseEvent: -1221000664 s HandMorph>handleEvent: -1220670384 s HandMorph>processEvents -1220670292 s [] in WorldState>doOneCycleNowFor: -1220670200 s Array(SequenceableCollection)>do: -1220670108 s WorldState>handsDo: -1221001008 s WorldState>doOneCycleNowFor: -1220670016 s WorldState>doOneCycleFor: -1220669924 s PasteUpMorph>doOneCycle -1221589100 s [] in Project class>spawnNewProcess -1221602884 s [] in BlockClosure>newProcess Most recent primitives basicNew size at: basicNew: decompress:fromByteArray:at: beCursorWithMask: vmParameterAt:put: vmParameterAt:put: setGCBiasToGrowGCLimit: setGCBiasToGrow: ensure: valueNoContextSwitch wait value specialObjectsArray new: at:put: value signal basicNew new: at: value: basicIdentityHash on:do: value perform:with: millisecondClockValue signal value: size size bitShift: \\ \\ \\ \\ \\ perform:with: shallowCopy subclasses new: new: new: // value: value: value: = = value: value: at:put: value: at:put: addAll: - + + + size at: do: do: value: getSystemAttribute: compare:with:collated: value: value: platformName = = value: value: getSystemAttribute: compare:with:collated: determineActivePlatformStartingAt: determineActivePlatformStartingAt: basicNew value: value: value: value: perform:with: actualScreenSize species species supportsDisplayDepth: new: basicNew beDisplay value: perform:with: isMemberOf: value: perform:with: basicNew critical: critical: wait wait specialObjectsArray species new: replaceFrom:to:with:startingAt: specialObjectsArray at:put: at:put: primSetInputSemaphore: suspend findNextUnwindContextUpTo: value: bottomContext objectAt: basicNew: basicNew basicNew findNextHandlerContextStarting tempAt: nextHandlerContext handleSignal: isKindOf: tempAt:put: tempAt:put: tempAt:put: valueWithArguments: findNextHandlerContextStarting basicNew findNextHandlerContextStarting tempAt: findNextHandlerContextStarting tempAt: Abgebrochen Cheers Philippe

Jan. 2, 2011

Re: [Pharo-project] new Cog VMs

by mkobetic＠gmail.com

I'm probably doing something obviously wrong, but I have no luck with the Cog VM. It crashes immediately on startup even with the stock OneClick image. I downloaded the Pharo-1.1.1 OneClick images. Fetched the latest coglinux.tgz (r2340), untarred it into the pharo directory and just trying to run it from the top-level pharo directory as: coglinux/squeak Contents/Resources/pharo.image crashes immediately (with or without the -vm-display-X11 option). This is on latest Fedora 14. The old VM seems to have no problem when I try to run it the same way: Contents/Linux/squeakvm Contents/Resources/pharo.image seems to start just fine. I can copy the stack dump from the crash, but since most seem to be running fine, I suspect I'm just not doing it right. What am I missing ? Thanks, Martin "Eliot Miranda"<eliot.miranda(a)gmail.com> wrote: > there are new versions of both the SimpleStackBasedCogit and the > StackToRegisterMappingCogit Cog VMs in > VM.r2339/<http://www.mirandabanda.org/files/Cog/VM/VM.r2339/> > & VM.r2340/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2340/> respectively. > These contain fixes for rounding bug causing underestimate of openPICSize > and resultant hard crashes, seen e.g. by trying to recover lost changes in a > Pharo 1.2 image installed on c:\pharo. If you're trying to reproduce Cog > crashes please upgrade to one of tthese two VMs.

Jan. 2, 2011

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

by mkobetic＠gmail.com

"Francisco Ortiz PeÃ±aloza"<patchinko(a)gmail.com> wrote: > Hi Martin, thanks i'll try it later! > > It would help if you could provide a Metacello configuration for it. Yes, something like that is clearly needed, but I'm still finding my way around the environment. However at the moment Xtreams don't have any prerequisites, so something like the gofer expression below should do it (you can skip the tests if you want). Gofer new squeaksource: 'Xtreams'; package: 'Xtreams-VWCompatible'; package: 'Xtreams-Core'; package: 'Xtreams-Terminals'; package: 'Xtreams-Transforms'; package: 'Xtreams-Substreams'; package: 'Xtreams-SqueakExternals'; package: 'Xtreams-SqueakTextConverter'; package: 'Xtreams-CoreTests'; package: 'Xtreams-TerminalTests'; package: 'Xtreams-TransformsTests'; package: 'Xtreams-SubstreamsTests'; load But we'll likely want a metacello config eventually, especially when we bring in FFI for calling things like zlib and libcrypto. Cheers, Martin

Jan. 2, 2011

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

by Francisco Ortiz PeÃ±aloza

Hi Martin, thanks i'll try it later! It would help if you could provide a Metacello configuration for it. Cheers, Francisco On Sat, Jan 1, 2011 at 6:03 PM, <mkobetic(a)gmail.com> wrote: > 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. 2, 2011

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

by csrabak＠bol.com.br

I would like to add to the tally. Changing Object>>copyFrom: to Object>>copyStateFrom: makes for me a lot more sense that changing (in fact by the creation of) OrderedCollection>>copyFrom: to OrderedCollection>>copyFromIndex: Except we do agree /in limine/ that OrderedCollection>>copyFrom:to: should be changed to OrederedCollection>>copyFromIndex:toEndIndex: Em 01/01/2011 17:48, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: 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 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. 2, 2011

Re: [Pharo-project] source.lukas-renggli.ch is down

by GermÃ¡n Arduino

Seems that it remains down still. A lot of things depending of the Lukas server are not working :( 2010/12/29 Torsten Bergmann <astares(a)gmx.de>: > and it is one of the reasons why the hudson build fails :( > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastFailedBui… > > Even when Lukas restores the server it would be good to use > community controlled squeaksource servers in the future instead > of personal servers (the "truck factor" - you know) > > Bye > T. > > > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > >

Jan. 1, 2011