Re: [Pharo-project] new Cog VMs

[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/
>  & 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:
-122072 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>doOn

Re: [Pharo-project] new Cog VMs

[mkobetic]

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" wrote:
>there are new versions of both the SimpleStackBasedCogit and the
> StackToRegisterMappingCogit Cog VMs in
> VM.r2339/
>  & 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.

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

[mkobetic]

"Francisco Ortiz Peñaloza" 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

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

[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,  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
>
>

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

[csrabak]

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 < bsch...@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-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli 
[reng...@gmail.com]
Sent: Saturday, January 01, 2011 2:06 PM
To: Pharo-project@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-boun...@lists.gforge.inria.fr 
> [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse 
> [stephane.duca...@inria.fr]
> Sent: Saturday, January 01, 2011 1:29 PM
> To: 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
>
>copyF

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

[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 :
> and it is one of the reasons why the hudson build fails :(
>
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastFailedBuild/console
>
> 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
>
>

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

[askoh]

Check out JUN for Smalltalk.
http://aokilab.kyoto-su.ac.jp/jun/index.html
-- 
View this message in context: 
http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747p3170556.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] new Cog VMs

[Eliot Miranda]

Hi All,

   there are new versions of both the SimpleStackBasedCogit and the
StackToRegisterMappingCogit Cog VMs in
VM.r2339/
 & 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.

TIA
Eliot

On Thu, Dec 30, 2010 at 6:02 PM, 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: 1 do: [:i|]] timeToRun 691
> StackToRegisterMappingCogit: [1 to: 1 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.
>
> best
> Eliot
>
>

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

[pharo]

Updates:
Cc: stephane.ducasse
Labels: Milestone-1.2

Comment #1 on issue 3502 by torsten@astares.de: DNU while parsing
http://code.google.com/p/pharo/issues/detail?id=3502

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

[pharo]

Comment #5 on issue 3436 by rydier: #copyFrom: is broken
http://code.google.com/p/pharo/issues/detail?id=3436

If we end up deprecating and reimplementing, at least make the "new"  
implementation in SequenceableCollection, where it can be found in STX and  
GnuST.


I still don't think it's a good idea to add to the SequenceableCollection  
API though, because:

- It's not ANSI (VW for instance does not have it)
- There is already copyFrom:to: and allButFirst: filling the same role  
nearly as easy
- It'll break code for no better reason than to increase readability  
(unless you actually look up its implementation, in which case it's quite  
clear what it does)
- There's yet another point of difference if you want to have your code  
running on both Squeak and Pharo

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

[pharo]

Status: Accepted
Owner: torsten@astares.de

New issue 3502 by torsten@astares.de: DNU while parsing
http://code.google.com/p/pharo/issues/detail?id=3502

($A to: $Z) do: [:each |
Transcript show: '|*';
show: each asString;
show: '>Index: ';
show: each asString;
show: '*';  
]

gives a cascade error in squeak and a DNU in recent Pharo:

TextMorphForEditView(Object)>>doesNotUnderstand: #notify:at:in:
Receiver: a TextMorphForEditView(284950528)
Arguments and temporary variables:
		aMessage: 	notify: 'Cascade expected ->' at: 131 in: a  
ReadWriteStream '($A to: ...etc...

exception:  MessageNotUnderstood: 
TextMorphForEditView>>notify:at:in:
resumeValue:nil
Receiver's instance variables:
bounds: 0...@0 corner: 4...@114
owner:  a TransformMorph(182190080)
submorphs:  #()
fullBounds: 0...@0 corner: 4...@114
color:  Color black
		extension: 	a MorphExtension (680787968) [other:  (blinkStart ->  
14517886) (myDe...etc...

borderWidth:0
borderColor:Color black
textStyle:  a TextStyle Bitmap DejaVu Sans 9
text:   a Text for '($A to: $Z) do: [:each |
Transcript show: ''|*'';
show: ea...etc...
wrapFlag:   true
paragraph:  a MultiNewParagraph
editor: a SmalltalkEditor
container:  nil
predecessor:nil
successor:  nil
backgroundColor:nil
margins:nil
editView:   a PluggableTextMorph(123469824)
acceptOnCR: false

Parser>>notify:at:
Receiver: a Parser
Arguments and temporary variables:
string: 'Cascade expected'
location:   131
Receiver's instance variables:
source: a ReadWriteStream '($A to: $Z) do: [:each |
Transcript show: ''|*'';
...etc...
mark:   130
hereChar:   Character arrowUp
aheadChar:  Character arrowUp
token:  #''
tokenType:  #doIt
currentComment: nil
buffer: a WriteStream '*'
		typeTable: 	#(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary  
#xBinary #xB...etc...

here:   #']'
hereType:   #rightBracket
hereMark:   131
hereEnd:130
prevMark:   127
prevEnd:127
encoder:{an EncoderForV3PlusClosures}
requestor:  a TextMorphForEditView(284950528)
parseNode:  {Transcript}
failBlock:  [^ failBlock value]
requestorOffset:0
tempsMark:  1
doitFlag:   true
properties: an AdditionalMethodState
category:   nil

Parser>>expected:
Receiver: a Parser
Arguments and temporary variables:
aString:'Cascade'
Receiver's instance variables:
source: a ReadWriteStream '($A to: $Z) do: [:each |
Transcript show: ''|*'';
...etc...
mark:   130
hereChar:   Character arrowUp
aheadChar:  Character arrowUp
token:  #''
tokenType:  #doIt
currentComment: nil
buffer: a WriteStream '*'
		typeTable: 	#(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary  
#xBinary #xB...etc...

here:   #']'
hereType:   #rightBracket
hereMark:   131
hereEnd:130
prevMark:   127
prevEnd:127
encoder:{an EncoderForV3PlusClosures}
requestor:  a TextMorphForEditView(284950528)
parseNode:  {Transcript}
failBlock:  [^ failBlock value]
requestorOffset:0
tempsMark:  1
doitFlag:   true
properties: an AdditionalMethodState
category:   nil

Re: [Pharo-project] new Cog VMs

[Igor Stasenko]

On 1 January 2011 22:27, Eliot Miranda  wrote:
>
>
> On Sat, Jan 1, 2011 at 1:23 PM, Igor Stasenko  wrote:
>>
>> I built fresh Cog VM using cmake configs.
>>
>> Pharo 1.2 tests still crashing with segfault.
>
> So how exactly do I reproduce this?  Image, OS, action etc...
>

Try running tests in latest pharo 1.2 image
i.e., open image
open test runner and press run.


>>
>> Here the stack dump:
>>
>> 0xbff638f0 M CompiledMethod(Object)>becomeForward: 461278460: a(n)
>> CompiledMethod
>> 0xbff63914 M CompiledMethod>setSourcePointer: 461278460: a(n)
>> CompiledMethod
>> 0xbff63930 M CompiledMethod>setSourcePosition:inFile: 461278460: a(n)
>> CompiledMethod
>> 0xbff63958 M CompiledMethod>putSource:fromParseNode:inFile:withPreamble:
>> 461278460: a(n) CompiledMethod
>> 0xbff63988 M ClassTrait(TraitBehavior)>addTraitSelector:withMethod:
>> 460086116: a(n) ClassTrait
>> 0xbff639b4 M [] in
>> ClassTrait(TraitBehavior)>updateMethodDictionarySelector: 460086116:
>> a(n) ClassTrait
>> 0xbff639d4 M OrderedCollection>do: 461255108: a(n) OrderedCollection
>> 0xbff639f8 M ClassTrait(TraitBehavior)>updateMethodDictionarySelector:
>> 460086116: a(n) ClassTrait
>> 0xbff63a1c M [] in ClassTrait(TraitBehavior)>noteChangedSelectors:
>> 460086116: a(n) ClassTrait
>> 0xbff63a3c M [] in IdentitySet(Set)>do: 461251388: a(n) IdentitySet
>> 0xbff63a60 M Array(SequenceableCollection)>do: 461251400: a(n) Array
>> 0xbff63a7c M IdentitySet(Set)>do: 461251388: a(n) IdentitySet
>> 0xbff63a9c M ClassTrait(TraitBehavior)>noteChangedSelectors:
>> 460086116: a(n) ClassTrait
>> 0xbff63ac4 I
>> ClassTrait(TraitBehavior)>applyChangesOfNewTraitCompositionReplacing:
>> 460086116: a(n) ClassTrait
>> 0xbff63aec I
>> ClassTrait(TraitDescription)>applyChangesOfNewTraitCompositionReplacing:
>> 460086116: a(n) ClassTrait
>> 0xbff63b14 I ClassTrait(TraitBehavior)>setTraitComposition: 460086116:
>> a(n) ClassTrait
>> 0xbff63b40 I ClassTrait>noteNewBaseTraitCompositionApplied: 460086116:
>> a(n) ClassTrait
>> 0xbff63b68 I Trait>applyChangesOfNewTraitCompositionReplacing:
>> 460085756: a(n) Trait
>> 0xbff63b90 I Trait(TraitBehavior)>setTraitComposition: 460085756: a(n)
>> Trait
>> 0xbff63bc0 I Trait class>named:uses:category:env: 437072228: a(n) Trait
>> class
>> 0xbff63bf4 I Trait class>named:uses:category: 437072228: a(n) Trait class
>> 0xbff63c24 I TraitCompositionTest(TraitsTestCase)>createTraitNamed:uses:
>> 456579032: a(n) TraitCompositionTest
>> 0xbff63c4c M TraitCompositionTest>testProvidedMethodBindingsWithConflicts
>> 456579032: a(n) TraitCompositionTest
>> 0xbff63c64 M TraitCompositionTest(TestCase)>performTest 456579032:
>> a(n) TraitCompositionTest
>>
>>
>> Looks like Cog really don't likes when image trying to manipulate with
>> methods using #become:  :)
>>
>> However, running
>>
>> TraitCompositionTest run: #testProvidedMethodBindingsWithConflicts
>>
>> alone, doesn't triggers a crash, which makes me suspect that object
>> memory is damaged by
>> something which runs before it, and this crash is only a consequence of
>> damage.
>>
>> Running the TraitsTestCase also works w/o problems.
>> This bug is really lurky SOAB :)
>>
>> I removed the TraitCompositionTest from system and run the tests
>> again. This time i got crash in different place:
>>
>> (gdb) bt
>> #0  mapForbcpcperformUntilarg (cogMethod=0x19df44c8, startbcpc=104,
>> functionSymbol=0x6de0 , arg=0x92) at
>> /Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12014
>> #1  0x9154 in mcPCForstartBcpcin (bcpc=146, startbcpc=104,
>> cogMethod=0x19df44c8) at
>> /Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12604
>> #2  0x0006c967 in interpret () at
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:5904
>> #3  0x0006dc78 in enterSmalltalkExecutiveImplementation () at
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:14081
>> #4  0x0006ede4 in initStackPagesAndInterpret () at
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:17676
>>
>>
>> (gdb) call (int) printAllStacks()
>> Process 0x1a7e02ac priority 40
>> 0xbff64b34 M [] in
>>
>> FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
>> 455083812: a(n) FileStreamTest
>> 0xbff64b54 M BlockClosure>ensure: 457616488: a(n) BlockClosure
>> 0xbff64b80 I
>> FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
>> 455083812: a(n) FileStreamTest
>> 0xbff64bac M FileStreamTest>testReadIntoStartingAtCountAll 455083812:
>> a(n) FileStreamTest
>> 0xbff64bc4 M FileStreamTest(TestCase)>performTest 455083812: a(n)
>> FileStreamTest
>> 0xbff64bdc M [] in FileStreamTest(TestCase)>runCase 455083812: a(n)
>> FileStreamTest
>> 0xbff64bfc M BlockClosure>ensure: 457616196: a(n) BlockClosure
>> 0xbff64c18 M FileStreamTest(TestCase)>runCase 455083812: a(n)
>> FileStreamTest
>> 0xbff64c34 M [] in TestResult>runCase: 454652328: a(n) TestResult
>> 
>>
>>
>> This is reproducible by running:
>> FileStreamTest run: #testReadIntoStartingAtCountAll
>>
>> but works fine i

Re: [Pharo-project] new Cog VMs

[Stéphane Ducasse]

Mac os

Take 
the latest pharo image here:

https://gforge.inria.fr/frs/download.php/28098/PharoCore-1.2beta-12283.zip
open the test runner
run the tests and boum 

Esteban and igor got the same. but only when the tests are all run not when a 
particular test is run.
The tests pass with a 4.2.5 VM
Stef



On Jan 1, 2011, at 10:27 PM, Eliot Miranda wrote:

> 
> 
> On Sat, Jan 1, 2011 at 1:23 PM, Igor Stasenko  wrote:
> I built fresh Cog VM using cmake configs.
> 
> Pharo 1.2 tests still crashing with segfault.
> 
> So how exactly do I reproduce this?  Image, OS, action etc...
> 
>  
> Here the stack dump:
> 
> 0xbff638f0 M CompiledMethod(Object)>becomeForward: 461278460: a(n)
> CompiledMethod
> 0xbff63914 M CompiledMethod>setSourcePointer: 461278460: a(n) CompiledMethod
> 0xbff63930 M CompiledMethod>setSourcePosition:inFile: 461278460: a(n)
> CompiledMethod
> 0xbff63958 M CompiledMethod>putSource:fromParseNode:inFile:withPreamble:
> 461278460: a(n) CompiledMethod
> 0xbff63988 M ClassTrait(TraitBehavior)>addTraitSelector:withMethod:
> 460086116: a(n) ClassTrait
> 0xbff639b4 M [] in
> ClassTrait(TraitBehavior)>updateMethodDictionarySelector: 460086116:
> a(n) ClassTrait
> 0xbff639d4 M OrderedCollection>do: 461255108: a(n) OrderedCollection
> 0xbff639f8 M ClassTrait(TraitBehavior)>updateMethodDictionarySelector:
> 460086116: a(n) ClassTrait
> 0xbff63a1c M [] in ClassTrait(TraitBehavior)>noteChangedSelectors:
> 460086116: a(n) ClassTrait
> 0xbff63a3c M [] in IdentitySet(Set)>do: 461251388: a(n) IdentitySet
> 0xbff63a60 M Array(SequenceableCollection)>do: 461251400: a(n) Array
> 0xbff63a7c M IdentitySet(Set)>do: 461251388: a(n) IdentitySet
> 0xbff63a9c M ClassTrait(TraitBehavior)>noteChangedSelectors:
> 460086116: a(n) ClassTrait
> 0xbff63ac4 I 
> ClassTrait(TraitBehavior)>applyChangesOfNewTraitCompositionReplacing:
> 460086116: a(n) ClassTrait
> 0xbff63aec I 
> ClassTrait(TraitDescription)>applyChangesOfNewTraitCompositionReplacing:
> 460086116: a(n) ClassTrait
> 0xbff63b14 I ClassTrait(TraitBehavior)>setTraitComposition: 460086116:
> a(n) ClassTrait
> 0xbff63b40 I ClassTrait>noteNewBaseTraitCompositionApplied: 460086116:
> a(n) ClassTrait
> 0xbff63b68 I Trait>applyChangesOfNewTraitCompositionReplacing:
> 460085756: a(n) Trait
> 0xbff63b90 I Trait(TraitBehavior)>setTraitComposition: 460085756: a(n) Trait
> 0xbff63bc0 I Trait class>named:uses:category:env: 437072228: a(n) Trait class
> 0xbff63bf4 I Trait class>named:uses:category: 437072228: a(n) Trait class
> 0xbff63c24 I TraitCompositionTest(TraitsTestCase)>createTraitNamed:uses:
> 456579032: a(n) TraitCompositionTest
> 0xbff63c4c M TraitCompositionTest>testProvidedMethodBindingsWithConflicts
> 456579032: a(n) TraitCompositionTest
> 0xbff63c64 M TraitCompositionTest(TestCase)>performTest 456579032:
> a(n) TraitCompositionTest
> 
> 
> Looks like Cog really don't likes when image trying to manipulate with
> methods using #become:  :)
> 
> However, running
> 
> TraitCompositionTest run: #testProvidedMethodBindingsWithConflicts
> 
> alone, doesn't triggers a crash, which makes me suspect that object
> memory is damaged by
> something which runs before it, and this crash is only a consequence of 
> damage.
> 
> Running the TraitsTestCase also works w/o problems.
> This bug is really lurky SOAB :)
> 
> I removed the TraitCompositionTest from system and run the tests
> again. This time i got crash in different place:
> 
> (gdb) bt
> #0  mapForbcpcperformUntilarg (cogMethod=0x19df44c8, startbcpc=104,
> functionSymbol=0x6de0 , arg=0x92) at
> /Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12014
> #1  0x9154 in mcPCForstartBcpcin (bcpc=146, startbcpc=104,
> cogMethod=0x19df44c8) at
> /Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12604
> #2  0x0006c967 in interpret () at
> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:5904
> #3  0x0006dc78 in enterSmalltalkExecutiveImplementation () at
> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:14081
> #4  0x0006ede4 in initStackPagesAndInterpret () at
> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:17676
> 
> 
> (gdb) call (int) printAllStacks()
> Process 0x1a7e02ac priority 40
> 0xbff64b34 M [] in
> FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
> 455083812: a(n) FileStreamTest
> 0xbff64b54 M BlockClosure>ensure: 457616488: a(n) BlockClosure
> 0xbff64b80 I 
> FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
> 455083812: a(n) FileStreamTest
> 0xbff64bac M FileStreamTest>testReadIntoStartingAtCountAll 455083812:
> a(n) FileStreamTest
> 0xbff64bc4 M FileStreamTest(TestCase)>performTest 455083812: a(n) 
> FileStreamTest
> 0xbff64bdc M [] in FileStreamTest(TestCase)>runCase 455083812: a(n)
> FileStreamTest
> 0xbff64bfc M BlockClosure>ensure: 457616196: a(n) BlockClosure
> 0xbff64c18 M FileStreamTest(TestCase)>runCase 455083812: a(n) FileStreamTest
> 0xbff64c34 M [] in TestResult>runCa

Re: [Pharo-project] new Cog VMs

[Eliot Miranda]

On Sat, Jan 1, 2011 at 1:23 PM, Igor Stasenko  wrote:

> I built fresh Cog VM using cmake configs.
>
> Pharo 1.2 tests still crashing with segfault.


So how exactly do I reproduce this?  Image, OS, action etc...



> Here the stack dump:
>
> 0xbff638f0 M CompiledMethod(Object)>becomeForward: 461278460: a(n)
> CompiledMethod
> 0xbff63914 M CompiledMethod>setSourcePointer: 461278460: a(n)
> CompiledMethod
> 0xbff63930 M CompiledMethod>setSourcePosition:inFile: 461278460: a(n)
> CompiledMethod
> 0xbff63958 M CompiledMethod>putSource:fromParseNode:inFile:withPreamble:
> 461278460: a(n) CompiledMethod
> 0xbff63988 M ClassTrait(TraitBehavior)>addTraitSelector:withMethod:
> 460086116: a(n) ClassTrait
> 0xbff639b4 M [] in
> ClassTrait(TraitBehavior)>updateMethodDictionarySelector: 460086116:
> a(n) ClassTrait
> 0xbff639d4 M OrderedCollection>do: 461255108: a(n) OrderedCollection
> 0xbff639f8 M ClassTrait(TraitBehavior)>updateMethodDictionarySelector:
> 460086116: a(n) ClassTrait
> 0xbff63a1c M [] in ClassTrait(TraitBehavior)>noteChangedSelectors:
> 460086116: a(n) ClassTrait
> 0xbff63a3c M [] in IdentitySet(Set)>do: 461251388: a(n) IdentitySet
> 0xbff63a60 M Array(SequenceableCollection)>do: 461251400: a(n) Array
> 0xbff63a7c M IdentitySet(Set)>do: 461251388: a(n) IdentitySet
> 0xbff63a9c M ClassTrait(TraitBehavior)>noteChangedSelectors:
> 460086116: a(n) ClassTrait
> 0xbff63ac4 I
> ClassTrait(TraitBehavior)>applyChangesOfNewTraitCompositionReplacing:
> 460086116: a(n) ClassTrait
> 0xbff63aec I
> ClassTrait(TraitDescription)>applyChangesOfNewTraitCompositionReplacing:
> 460086116: a(n) ClassTrait
> 0xbff63b14 I ClassTrait(TraitBehavior)>setTraitComposition: 460086116:
> a(n) ClassTrait
> 0xbff63b40 I ClassTrait>noteNewBaseTraitCompositionApplied: 460086116:
> a(n) ClassTrait
> 0xbff63b68 I Trait>applyChangesOfNewTraitCompositionReplacing:
> 460085756: a(n) Trait
> 0xbff63b90 I Trait(TraitBehavior)>setTraitComposition: 460085756: a(n)
> Trait
> 0xbff63bc0 I Trait class>named:uses:category:env: 437072228: a(n) Trait
> class
> 0xbff63bf4 I Trait class>named:uses:category: 437072228: a(n) Trait class
> 0xbff63c24 I TraitCompositionTest(TraitsTestCase)>createTraitNamed:uses:
> 456579032: a(n) TraitCompositionTest
> 0xbff63c4c M TraitCompositionTest>testProvidedMethodBindingsWithConflicts
> 456579032: a(n) TraitCompositionTest
> 0xbff63c64 M TraitCompositionTest(TestCase)>performTest 456579032:
> a(n) TraitCompositionTest
>
>
> Looks like Cog really don't likes when image trying to manipulate with
> methods using #become:  :)
>
> However, running
>
> TraitCompositionTest run: #testProvidedMethodBindingsWithConflicts
>
> alone, doesn't triggers a crash, which makes me suspect that object
> memory is damaged by
> something which runs before it, and this crash is only a consequence of
> damage.
>
> Running the TraitsTestCase also works w/o problems.
> This bug is really lurky SOAB :)
>
> I removed the TraitCompositionTest from system and run the tests
> again. This time i got crash in different place:
>
> (gdb) bt
> #0  mapForbcpcperformUntilarg (cogMethod=0x19df44c8, startbcpc=104,
> functionSymbol=0x6de0 , arg=0x92) at
> /Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12014
> #1  0x9154 in mcPCForstartBcpcin (bcpc=146, startbcpc=104,
> cogMethod=0x19df44c8) at
> /Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12604
> #2  0x0006c967 in interpret () at
> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:5904
> #3  0x0006dc78 in enterSmalltalkExecutiveImplementation () at
> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:14081
> #4  0x0006ede4 in initStackPagesAndInterpret () at
> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:17676
>
>
> (gdb) call (int) printAllStacks()
> Process 0x1a7e02ac priority 40
> 0xbff64b34 M [] in
>
> FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
> 455083812: a(n) FileStreamTest
> 0xbff64b54 M BlockClosure>ensure: 457616488: a(n) BlockClosure
> 0xbff64b80 I
> FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
> 455083812: a(n) FileStreamTest
> 0xbff64bac M FileStreamTest>testReadIntoStartingAtCountAll 455083812:
> a(n) FileStreamTest
> 0xbff64bc4 M FileStreamTest(TestCase)>performTest 455083812: a(n)
> FileStreamTest
> 0xbff64bdc M [] in FileStreamTest(TestCase)>runCase 455083812: a(n)
> FileStreamTest
> 0xbff64bfc M BlockClosure>ensure: 457616196: a(n) BlockClosure
> 0xbff64c18 M FileStreamTest(TestCase)>runCase 455083812: a(n)
> FileStreamTest
> 0xbff64c34 M [] in TestResult>runCase: 454652328: a(n) TestResult
> 
>
>
> This is reproducible by running:
> FileStreamTest run: #testReadIntoStartingAtCountAll
>
> but works fine in older VM(s).
>
>
> I continued attempts to run whole tests after removing
> TraitCompositionTest and FileStreamTest, and here's another one:
>
> (gdb) bt
> #0  0x00040bb7 in mapPointersInObjectsFromto (memStart=455419144,
> memEnd=456751028) at sqMemoryAccess.h:81
>

Re: [Pharo-project] new Cog VMs

[Stéphane Ducasse]

Eliot 

I took r2338

And I run the test of the latest Pharo 1.2 and I get a crash.
Now may be this is related with the problem with the linkedList fix that 
andreas suggested. 

Stef



Process: Croquet [26661]
Path:/Users/ducasse/Desktop/Cog.app/Contents/MacOS/Croquet
Identifier:  com.teleplace.Teleplace
Version: Croquet Cog 3.0.0 (4.0.0)
Code Type:   X86 (Native)
Parent Process:  launchd [110]

Date/Time:   2011-01-01 22:21:14.250 +0100
OS Version:  Mac OS X 10.6.4 (10F569)
Report Version:  6

Interval Since Last Report:  96764 sec
Crashes Since Last Report:   1
Per-App Interval Since Last Report:  673 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:  99B0623E-9CD5-4C95-ACCB-0B118DEF717F

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0xfff76410
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib   0x995d5ef6 __kill + 10
1   libSystem.B.dylib   0x995d5ee8 kill$UNIX2003 + 32
2   libSystem.B.dylib   0x9966862d raise + 26
3   libSystem.B.dylib   0x9967e6e4 abort + 93
4   com.teleplace.Teleplace 0x0006e685 error + 85
5   libSystem.B.dylib   0x995db1fb _sigtramp + 43
6   ??? 0x 0 + 4294967295
7   com.teleplace.Teleplace 0x000e258c becomewithtwoWaycopyHash + 
1292
8   com.teleplace.Teleplace 0x000e290f primitiveArrayBecomeOneWay + 
31
9   ??? 0x1280e149 0 + 310436169
10  com.teleplace.Teleplace 0x001039ba initStackPagesAndInterpret + 
538
11  com.teleplace.Teleplace 0x0005daa4 EventLoopEventHandler + 132
12  com.apple.HIToolbox 0x9644ef2f 
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 
1567
13  com.apple.HIToolbox 0x9644e1f6 
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, 
HandlerCallRec*) + 411
14  com.apple.HIToolbox 0x9644e055 
SendEventToEventTargetWithOptions + 58
15  com.apple.HIToolbox 0x96482bb0 
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, 
void*) + 3006
16  com.apple.HIToolbox 0x9644f380 
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 
2672
17  com.apple.HIToolbox 0x9644e1f6 
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, 
HandlerCallRec*) + 411
18  com.apple.HIToolbox 0x964709bb SendEventToEventTarget + 52
19  com.apple.HIToolbox 0x965f9cc3 ToolboxEventDispatcher + 86
20  com.apple.HIToolbox 0x965f9dfb RunApplicationEventLoop + 243
21  com.teleplace.Teleplace 0x0005d2ea 
RunApplicationEventLoopWithSqueak + 218
22  com.teleplace.Teleplace 0x0006e987 main + 631
23  com.teleplace.Teleplace 0x2c86 start + 54

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib   0x9959b942 kevent + 10
1   libSystem.B.dylib   0x9959c05c _dispatch_mgr_invoke + 215
2   libSystem.B.dylib   0x9959b519 _dispatch_queue_invoke + 163
3   libSystem.B.dylib   0x9959b2be _dispatch_worker_thread2 + 
240
4   libSystem.B.dylib   0x9959ad41 _pthread_wqthread + 390
5   libSystem.B.dylib   0x9959ab86 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib   0x995a3066 __semwait_signal + 10
1   libSystem.B.dylib   0x995cec64 nanosleep$UNIX2003 + 188
2   com.teleplace.Teleplace 0x000b050b beatStateMachine + 139
3   libSystem.B.dylib   0x995a281d _pthread_start + 345
4   libSystem.B.dylib   0x995a26a2 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x  ebx: 0x9967e693  ecx: 0xbff5b2ac  edx: 0x995d5ef6
  edi: 0x13e16b4c  esi: 0xbff5b620  ebp: 0xbff5b2c8  esp: 0xbff5b2ac
   ss: 0x001f  efl: 0x0282  eip: 0x995d5ef6   cs: 0x0007
   ds: 0x001f   es: 0x001f   fs: 0x   gs: 0x0037
  cr2: 0x00108d80

Binary Images:
0x1000 -   0x125fe7 +com.teleplace.Teleplace Croquet Cog 3.0.0 (4.0.0) 
<70DB946B-15AB-28B3-2BBB-F5DF9597AD0B> 
/Users/ducasse/Desktop/Cog.app/Contents/MacOS/Croquet
0x8fe0 - 0x8fe4162b  dyld 132.1 (???) 
 /usr/lib/dyld
0x9001 - 0x90111fe7  libxml2.2.dylib 10.3.0 (compatibility 10.0.0) 
 /usr/lib/libxml2.2.dylib
0x90112000 - 0x9011bff7  com.apple.DiskArbitration 2.3 (2.3) 
<6AA6DDF6-AFC3-BBDB-751A-64AE3580A49E> 
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x90211000 - 0x90252ff7  libRIP.A.dylib 543.50.0 (compatibility 64.0.0) 
<8BAE1FC1-A478-F

Re: [Pharo-project] new Cog VMs

[Igor Stasenko]

I built fresh Cog VM using cmake configs.

Pharo 1.2 tests still crashing with segfault. Here the stack dump:

0xbff638f0 M CompiledMethod(Object)>becomeForward: 461278460: a(n)
CompiledMethod
0xbff63914 M CompiledMethod>setSourcePointer: 461278460: a(n) CompiledMethod
0xbff63930 M CompiledMethod>setSourcePosition:inFile: 461278460: a(n)
CompiledMethod
0xbff63958 M CompiledMethod>putSource:fromParseNode:inFile:withPreamble:
461278460: a(n) CompiledMethod
0xbff63988 M ClassTrait(TraitBehavior)>addTraitSelector:withMethod:
460086116: a(n) ClassTrait
0xbff639b4 M [] in
ClassTrait(TraitBehavior)>updateMethodDictionarySelector: 460086116:
a(n) ClassTrait
0xbff639d4 M OrderedCollection>do: 461255108: a(n) OrderedCollection
0xbff639f8 M ClassTrait(TraitBehavior)>updateMethodDictionarySelector:
460086116: a(n) ClassTrait
0xbff63a1c M [] in ClassTrait(TraitBehavior)>noteChangedSelectors:
460086116: a(n) ClassTrait
0xbff63a3c M [] in IdentitySet(Set)>do: 461251388: a(n) IdentitySet
0xbff63a60 M Array(SequenceableCollection)>do: 461251400: a(n) Array
0xbff63a7c M IdentitySet(Set)>do: 461251388: a(n) IdentitySet
0xbff63a9c M ClassTrait(TraitBehavior)>noteChangedSelectors:
460086116: a(n) ClassTrait
0xbff63ac4 I 
ClassTrait(TraitBehavior)>applyChangesOfNewTraitCompositionReplacing:
460086116: a(n) ClassTrait
0xbff63aec I 
ClassTrait(TraitDescription)>applyChangesOfNewTraitCompositionReplacing:
460086116: a(n) ClassTrait
0xbff63b14 I ClassTrait(TraitBehavior)>setTraitComposition: 460086116:
a(n) ClassTrait
0xbff63b40 I ClassTrait>noteNewBaseTraitCompositionApplied: 460086116:
a(n) ClassTrait
0xbff63b68 I Trait>applyChangesOfNewTraitCompositionReplacing:
460085756: a(n) Trait
0xbff63b90 I Trait(TraitBehavior)>setTraitComposition: 460085756: a(n) Trait
0xbff63bc0 I Trait class>named:uses:category:env: 437072228: a(n) Trait class
0xbff63bf4 I Trait class>named:uses:category: 437072228: a(n) Trait class
0xbff63c24 I TraitCompositionTest(TraitsTestCase)>createTraitNamed:uses:
456579032: a(n) TraitCompositionTest
0xbff63c4c M TraitCompositionTest>testProvidedMethodBindingsWithConflicts
456579032: a(n) TraitCompositionTest
0xbff63c64 M TraitCompositionTest(TestCase)>performTest 456579032:
a(n) TraitCompositionTest


Looks like Cog really don't likes when image trying to manipulate with
methods using #become:  :)

However, running

TraitCompositionTest run: #testProvidedMethodBindingsWithConflicts

alone, doesn't triggers a crash, which makes me suspect that object
memory is damaged by
something which runs before it, and this crash is only a consequence of damage.

Running the TraitsTestCase also works w/o problems.
This bug is really lurky SOAB :)

I removed the TraitCompositionTest from system and run the tests
again. This time i got crash in different place:

(gdb) bt
#0  mapForbcpcperformUntilarg (cogMethod=0x19df44c8, startbcpc=104,
functionSymbol=0x6de0 , arg=0x92) at
/Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12014
#1  0x9154 in mcPCForstartBcpcin (bcpc=146, startbcpc=104,
cogMethod=0x19df44c8) at
/Users/sig/projects/cog/sig-cog/src/vm/cogit.c:12604
#2  0x0006c967 in interpret () at
/Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:5904
#3  0x0006dc78 in enterSmalltalkExecutiveImplementation () at
/Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:14081
#4  0x0006ede4 in initStackPagesAndInterpret () at
/Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:17676


(gdb) call (int) printAllStacks()
Process 0x1a7e02ac priority 40
0xbff64b34 M [] in
FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
455083812: a(n) FileStreamTest
0xbff64b54 M BlockClosure>ensure: 457616488: a(n) BlockClosure
0xbff64b80 I 
FileStreamTest>doTestsForReading:intoBufferWithSize:startingAt:fromFileOfSize:offsetBy:
455083812: a(n) FileStreamTest
0xbff64bac M FileStreamTest>testReadIntoStartingAtCountAll 455083812:
a(n) FileStreamTest
0xbff64bc4 M FileStreamTest(TestCase)>performTest 455083812: a(n) FileStreamTest
0xbff64bdc M [] in FileStreamTest(TestCase)>runCase 455083812: a(n)
FileStreamTest
0xbff64bfc M BlockClosure>ensure: 457616196: a(n) BlockClosure
0xbff64c18 M FileStreamTest(TestCase)>runCase 455083812: a(n) FileStreamTest
0xbff64c34 M [] in TestResult>runCase: 454652328: a(n) TestResult



This is reproducible by running:
FileStreamTest run: #testReadIntoStartingAtCountAll

but works fine in older VM(s).


I continued attempts to run whole tests after removing
TraitCompositionTest and FileStreamTest, and here's another one:

(gdb) bt
#0  0x00040bb7 in mapPointersInObjectsFromto (memStart=455419144,
memEnd=456751028) at sqMemoryAccess.h:81
#1  0x00043acc in becomewithtwoWaycopyHash (array1=456751008,
array2=456751016, twoWayFlag=1, copyHashFlag=1) at
/Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:9410
#2  0x00044268 in primitiveArrayBecome () at
/Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:22887
#3  0x19dc8c31 in ?? ()
#4  0x0006ede4 in initStackPagesAndInte

[Pharo-project] :)

[Stéphane Ducasse]

roel wuyts sent me that nice snippet :)

| wishStream adjectives |
wishStream := WriteStream with: 'For 2011 I wish you '.
adjectives := { 'fun' . 'exotic' . 'brilliant' . 'extraordinary' }.
{ 'research' . 'students' . 'artefacts' . 'conferences'}
do: [:e |
wishStream nextPutAll: adjectives atRandom;
space;
nextPutAll: e]
separatedBy: [wishStream nextPutAll: ', '].
wishStream nextPutAll: ' and of course good health!'.
^wishStream contents

Re: [Pharo-project] new Cog VMs

[Eliot Miranda]

Hi All,

   there are new versions of both the SimpleStackBasedCogit and the
StackToRegisterMappingCogit Cog VMs in
VM.r2337/
 & 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

Eliot

On Thu, Dec 30, 2010 at 6:02 PM, 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: 1 do: [:i|]] timeToRun 691
> StackToRegisterMappingCogit: [1 to: 1 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.
>
> best
> Eliot
>
>

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

[Schwab,Wilhelm K]

+1


From: pharo-project-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse 
[stephane.duca...@inria.fr]
Sent: Saturday, January 01, 2011 2:59 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

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

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

[pharo]

Updates:
Status: Accepted
Labels: Milestone-1.3

Comment #4 on issue 3436 by stephane.ducasse: #copyFrom: is broken
http://code.google.com/p/pharo/issues/detail?id=3436

I suggest to use copyStateFrom: and add copyFrom: in String.

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

[Igor Stasenko]

On 1 January 2011 20:59, Stéphane Ducasse  wrote:
> I like copyStateFrom: as a name
>
> lukas
>        there is copyFrom:to:
>        and copyFrom: make a lot of sense as copyFrom: index until the end.
>

+1
in the presence of #copyFrom:to:
the current implementation of #copyFrom: is misleading.
We should pick another name to reflect a completely different behavior.

> Stef
>
>



-- 
Best regards,
Igor Stasenko AKA sig.

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

[mkobetic]

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

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

[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

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

[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.

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

[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-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli 
[reng...@gmail.com]
Sent: Saturday, January 01, 2011 2:06 PM
To: Pharo-project@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-boun...@lists.gforge.inria.fr 
> [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse 
> [stephane.duca...@inria.fr]
> Sent: Saturday, January 01, 2011 1:29 PM
> To: 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
>
>
>
>



--
Lukas Renggli
www.lukas-renggli.ch

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

[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-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Peter 
Hugosson-Miller [oldmanl...@gmail.com]
Sent: Saturday, January 01, 2011 2:30 PM
To: Pharo-project@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 
mailto:bsch...@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-boun...@lists.gforge.inria.fr
 
[pharo-project-boun...@lists.gforge.inria.fr]
 On Behalf Of Stéphane Ducasse 
[stephane.duca...@inria.fr]
Sent: Saturday, January 01, 2011 1:29 PM
To: 
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

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

[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 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-boun...@lists.gforge.inria.fr [
> pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse
> [stephane.duca...@inria.fr]
> Sent: Saturday, January 01, 2011 1:29 PM
> To: 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
>

Re: [Pharo-project] new Cog VMs

[Eliot Miranda]

Hi Philippe,

On Sat, Jan 1, 2011 at 4:06 AM, Philippe Marschall  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: 1 do: [:i|]] timeToRun 691
> > StackToRegisterMappingCogit: [1 to: 1 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' -> 10 ].
>title := anAssociation key.
>referenceValue := anAssociation value.
>stream := WriteStream on: String new.
>document := builder documentClass
>on: stream
>codec: builder codec.
>context := WARenderContext new.
>co

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

[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  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-boun...@lists.gforge.inria.fr 
> [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse 
> [stephane.duca...@inria.fr]
> Sent: Saturday, January 01, 2011 1:29 PM
> To: 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
>
>
>
>



-- 
Lukas Renggli
www.lukas-renggli.ch

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

[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-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse 
[stephane.duca...@inria.fr]
Sent: Saturday, January 01, 2011 1:29 PM
To: 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

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

[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  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.
> 

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

[Stéphane Ducasse]

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 

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

[Igor Stasenko]

On 1 January 2011 18:15, Sebastian Sastre  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.

Re: [Pharo-project] [squeak-dev] loading of codetalk fails due to

[Enrico Spinielli]

thanks!

On Sat, Jan 1, 2011 at 18:38, Mariano Martinez Peck
 wrote:
> Hi I think it fails because lukas server is down. You can check it on the
> browser.
>
> cheer
>
> mariano
>
> On Sat, Jan 1, 2011 at 6:36 PM, Enrico Spinielli
>  wrote:
>>
>> hi,
>> loading codetalk from potsdam now fails with
>> Error: The spelling dictionary cannot be downloaded from
>> .
>>
>> I think this is due to recent changes in RB (which codetalk loads)
>>
>> http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg24201.html
>>
>> Any suggestions?
>> Bye
>> Enrico
>>
>> --
>> Enrico Spinielli
>> "Do Androids dream of electric sheep?"— Philip K. Dick
>> "Hear and forget; see and remember;do and understand."—Mitchel Resnick
>>
>
>



-- 
Enrico Spinielli
"Do Androids dream of electric sheep?"— Philip K. Dick
"Hear and forget; see and remember;do and understand."—Mitchel Resnick

Re: [Pharo-project] [squeak-dev] loading of codetalk fails due to

[Mariano Martinez Peck]

Hi I think it fails because lukas server is down. You can check it on the
browser.

cheer

mariano

On Sat, Jan 1, 2011 at 6:36 PM, Enrico Spinielli <
enrico.spinie...@googlemail.com> wrote:

> hi,
> loading codetalk from potsdam now fails with
> Error: The spelling dictionary cannot be downloaded from
> .
>
> I think this is due to recent changes in RB (which codetalk loads)
>
> http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg24201.html
>
> Any suggestions?
> Bye
> Enrico
>
> --
> Enrico Spinielli
> "Do Androids dream of electric sheep?"— Philip K. Dick
> "Hear and forget; see and remember;do and understand."—Mitchel Resnick
>
>

[Pharo-project] loading of codetalk fails due to

[Enrico Spinielli]

hi,
loading codetalk from potsdam now fails with
Error: The spelling dictionary cannot be downloaded from
.

I think this is due to recent changes in RB (which codetalk loads)
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg24201.html

Any suggestions?
Bye
Enrico

-- 
Enrico Spinielli
"Do Androids dream of electric sheep?"— Philip K. Dick
"Hear and forget; see and remember;do and understand."—Mitchel Resnick

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

[Sebastian Sastre]

('if this isn''t broken' copyFrom:  15) ~= 'broken' ifTrue:['this is screwed'] 
ifFalse:['this is intuitive']

Evaluate that in any Pharo workspace and it will show you.

Reported here.

Status? invalid

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?

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

[pharo]

Comment #3 on issue 3436 by sebastianconcept: #copyFrom: is broken
http://code.google.com/p/pharo/issues/detail?id=3436

I don't get it.

When you take any non squeak based smalltalk you'll see that #copyFrom: is  
consistent and intuitive.


When you take Pharo you get that:
1. it's broken even for smalltalkers (imagine random citizens)
2. is manipulating (admitedly) dangerously (check implementor comment)
3. is doing something extremely primitive without using the prefix basic  
(or whatever that suggest that this is a thing to use unless you know what  
you're doing)

4. our community response is that reporting this is invalid?

Can we please fix this instead of rationalize?

Suggestion: a rename of the current Object>>copyFrom: will be enough. How  
to rename it? with something that suggest is going to manipulate the  
freaking instance variables)
there is code depending on that? screw it. If they started with the wrong  
foot, they should pay the price of their upgrade (they are guilty of  
creating a dependence on something broken).

Re: [Pharo-project] [squeak-dev] Proper Smalltalk lots of classes

[Jan van de Sandt]

Hello Jimmie,

I had to do something similar a while ago. I had to support a complex XML
schema for a standard message format of the Dutch government (StUF).

The Java implementation used JAXB to generate a few thousand data objects.
Very clumsy.

In Smalltalk I made some code to generate Magritte descriptions for all the
structure and field definitions in the XML schema. Using the Magritte
descriptions it was very easy to read and write messages in the correct
format. I created real classes only for the few message types that required
some logic. For all the other message types I used some generic class that
stores the values in a dictionary.

So my advice is to have a look at Magritte. It can help you handle the type
information without creating/generating lots of classes.

Jan.



On Fri, Dec 31, 2010 at 11:24 PM, Jimmie Houchin wrote:

> Hello,
>
> I am porting the FIX protocol to Squeak/Pharo.
> http://www.fixprotocol.org/
>
> It is the Financial Information eXchange protocol. It is used by many firms
> in the financial industries, stocks, forex, etc.
>
> There is good documentation and also a semi-reference implementation in
> Java.
> http://www.quickfixj.org
>
> I have a partial port started but I wanted a check with those who know more
> than I about proper Smalltalk coding.
>
> In the Java implementation there are over 2000 classes. In the protocol
> there are approximately 90 message types and 956 field types.
>
> I am initially creating the message classes as they form the basis of the
> protocol and the fields are simply instance variables and methods in the
> message classes.
>
> I am not porting the Java library. I am implementing the protocol in
> Smalltalk from the documentation.
>
> Initially I have created a Fix44Field class with its necessary variables.
> There are several versions of the Protocol and FIX 4.4 is the one required
> for my application.
>
> With this Fix44Field class I am creating a Dictionary with the 956
> different field types. I am planning on creating a constructor method which
> will create the desired field from the information in the dictionary about
> the field and its properties.
>
> Am I way off base here? Should I really create the 956 classes necessary to
> for each field in addition to the 90 or so message classes, and then I don't
> know what else I haven't discovered yet. Having 1000+ classes just seems
> unwieldy and naively it just doesn't feel like the Smalltalk way. I could be
> wrong, but I haven't seen such an example to my memory. I don't know enough
> about Java to know if it is good Java form either.
>
> When I have a reasonably fleshed out, tested and working solution, I will
> make the source available under a MIT license. I would love to see
> Squeak/Pharo become an out of the box viable option for trading
> applications.
>
> Advise and wisdom greatly appreciated.
>
> Thanks.
>
> Jimmie
>
>

Re: [Pharo-project] about growing streams and allocating buffers

[Philippe Marschall]

On 01.01.2011 15:07, Stéphane Ducasse wrote:
>> Hi
>>
>> I've been doing some performance work lately in Seaside. Long story
>> short Seaside (and I guess AIDA too) spends of if it's rendering time in
>> WriteStream (#nextPutAll:, #nextPut:).
>>
>> The way WriteStream >> #pastEndPut: behaves is not really ideal for
>> Seaside. It grows the underlying collection by just enough to
>> accommodate the argument collection (or 20 which ever is bigger). Now
>> image the following not very unlikely scenario. You start with a 4k
>> buffer and put on average a 10 element collection (remember all those
>> tags are put individually) until you have a 16k response. You allocate
>> more than a thousand intermediary collections to get there.
>> What would be better suited for Seaside is doubling the required size.
>> In the worst case that would mean wasting 50% of memory but it would
>> make the overhead of creating intermediary collections logarithmic. In
>> the given example that would take us only three allocations to get there.
>> Now I do realize there are other applications for Pharo where this
>> strategy is not ideal and this is not a killer for us. I just wanted to
>> shed some light and this and ask whether other projects are in a similar
>> situation.
> 
> Thanks for the info.
> Do you have an idea in which case allocating more would be a real problem?

Whenever you're memory constrained, I guess. When doubling would put you
past the size limit of the image.

> Because in VW there were some patterns: 
>   turning , into nextPut: to avoid exact the underlying string allocation.

I don't get that.

>   preallocation OrderedCollection new: instead of relying on its growing 
> behavior. 

Right, but you never know how big the response is going to before
actually rendering. Otherwise you could just do Array/String new:
beforehand.

> Final question
> May be we should be able to plug the stream behavior we want. Like that 
> seaside people can 
> get the speed out of it. I think that having fast web app is important.

Oh, it's already way faster than it was previously ;-) And lets not
forget, even when you run Seaside, you will other other code like a
database driver as well, that will need streams as well. Whatever you
plug in, has to work with whatever else you have in your image.

Cheers
Philippe

Re: [Pharo-project] about growing streams and allocating buffers

[Philippe Marschall]

On 01.01.2011 14:39, Levente Uzonyi wrote:
> On Sat, 1 Jan 2011, Philippe Marschall wrote:
> 
>> Hi
>>
>> I've been doing some performance work lately in Seaside. Long story
>> short Seaside (and I guess AIDA too) spends of if it's rendering time in
>> WriteStream (#nextPutAll:, #nextPut:).
>>
>> The way WriteStream >> #pastEndPut: behaves is not really ideal for
>> Seaside. It grows the underlying collection by just enough to
>> accommodate the argument collection (or 20 which ever is bigger). Now
> 
> No it doesn't. The code in #pastEndPut: is
> 
> collection := collection grownBy: ((collection size max: 20) min: 100).
> 
> so the argument of #grownBy: is at least 20, at most 100 and it's
> size of the internal buffer (collection) if it's between 20 and 100.
> So in most practical cases it's the value of [collection size].
> #grownBy: allocates a new collection that has the size of the
> collection's size + the argument, which is 2 * self size in the most
> common case. So the size grows exponentially till it reaches 100 and
> then linearly (with a relatively high constant 100). This guarantees
> that the cost of #nextPut: is constant in most cases.

You're right, I misread the code, that's the behaviour for #nextPut:.
However #nextPutAll: does:

newEnd := position + aCollection size.
newEnd > writeLimit ifTrue:
[self growTo: newEnd + 10].

and #growTo: does then:

  newSize := anInteger + (oldSize // 4 max: 20).
grownCollection := collection class new: newSize.


aCollection is the argument collection, not the underlying collection.
So that's the required size puls ten plus the max of a fourth of the
current size and 20.


>> image the following not very unlikely scenario. You start with a 4k
>> buffer and put on average a 10 element collection (remember all those
>> tags are put individually) until you have a 16k response. You allocate
>> more than a thousand intermediary collections to get there.
> 
> So just 3: one for 4k (the initial), one for 8k and one for 16k.

Yes.

>> What would be better suited for Seaside is doubling the required size.
> 
> That's exactly what's happening in most cases.

In the #nextPut: case, not in the #nextPutAll: case.

>> In the worst case that would mean wasting 50% of memory but it would
>> make the overhead of creating intermediary collections logarithmic. In
> 
> The overhead is constant (amortized) in most cases.
> 
>> the given example that would take us only three allocations to get there.
>> Now I do realize there are other applications for Pharo where this
>> strategy is not ideal and this is not a killer for us. I just wanted to
>> shed some light and this and ask whether other projects are in a similar
>> situation.
>>
>> To get a feel how allocation limited Seaside is: avoiding one allocation
>> of a 16k ByteArray per request can make a difference in throughput
>> between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP
>> Components"). If anybody knows a way to make allocation of large young
>> space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd
>> like to hear it.
> 
> IIRC CogVM's GC is different from SqueakVM's GC in the sense that it is
> activated when a predefined amount of data is allocated, not when the
> number of allocations since the last GC reaches a predefined limit. So
> you have to tune the GC differently on Cog and non-Cog VMs.

Do you know where I can find more information about this?

Cheers
Philippe

Re: [Pharo-project] about growing streams and allocating buffers

[Stéphane Ducasse]

> Hi
> 
> I've been doing some performance work lately in Seaside. Long story
> short Seaside (and I guess AIDA too) spends of if it's rendering time in
> WriteStream (#nextPutAll:, #nextPut:).
> 
> The way WriteStream >> #pastEndPut: behaves is not really ideal for
> Seaside. It grows the underlying collection by just enough to
> accommodate the argument collection (or 20 which ever is bigger). Now
> image the following not very unlikely scenario. You start with a 4k
> buffer and put on average a 10 element collection (remember all those
> tags are put individually) until you have a 16k response. You allocate
> more than a thousand intermediary collections to get there.
> What would be better suited for Seaside is doubling the required size.
> In the worst case that would mean wasting 50% of memory but it would
> make the overhead of creating intermediary collections logarithmic. In
> the given example that would take us only three allocations to get there.
> Now I do realize there are other applications for Pharo where this
> strategy is not ideal and this is not a killer for us. I just wanted to
> shed some light and this and ask whether other projects are in a similar
> situation.

Thanks for the info.
Do you have an idea in which case allocating more would be a real problem?
Because in VW there were some patterns: 
turning , into nextPut: to avoid exact the underlying string allocation.
preallocation OrderedCollection new: instead of relying on its growing 
behavior. 
Final question
May be we should be able to plug the stream behavior we want. Like that seaside 
people can 
get the speed out of it. I think that having fast web app is important.

> 
> To get a feel how allocation limited Seaside is: avoiding one allocation
> of a 16k ByteArray per request can make a difference in throughput
> between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP
> Components"). If anybody knows a way to make allocation of large young
> space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd
> like to hear it.
> 
> Cheers
> Philippe
> 
> 

[Pharo-project] about growing streams and allocating buffers

[Philippe Marschall]

Hi

I've been doing some performance work lately in Seaside. Long story
short Seaside (and I guess AIDA too) spends of if it's rendering time in
WriteStream (#nextPutAll:, #nextPut:).

The way WriteStream >> #pastEndPut: behaves is not really ideal for
Seaside. It grows the underlying collection by just enough to
accommodate the argument collection (or 20 which ever is bigger). Now
image the following not very unlikely scenario. You start with a 4k
buffer and put on average a 10 element collection (remember all those
tags are put individually) until you have a 16k response. You allocate
more than a thousand intermediary collections to get there.
What would be better suited for Seaside is doubling the required size.
In the worst case that would mean wasting 50% of memory but it would
make the overhead of creating intermediary collections logarithmic. In
the given example that would take us only three allocations to get there.
Now I do realize there are other applications for Pharo where this
strategy is not ideal and this is not a killer for us. I just wanted to
shed some light and this and ask whether other projects are in a similar
situation.

To get a feel how allocation limited Seaside is: avoiding one allocation
of a 16k ByteArray per request can make a difference in throughput
between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP
Components"). If anybody knows a way to make allocation of large young
space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd
like to hear it.

Cheers
Philippe

[Pharo-project] [OT] questions answered on stackexchange: Why do good programmers have ugly websites?

[Igor Stasenko]

Funny. Really funny.
Especially this one:
"
Just be thankful there's more than just a command-prompt.
"

I hope that with Pharo we have enough 'bad' programmers, which can
make good designs.. otherwise we're in trouble :)

-- 
Best regards,
Igor Stasenko AKA sig.

Re: [Pharo-project] Issue 3500 in pharo: Create deprecated13

[Igor Stasenko]

looks fine as to me.

On 1 January 2011 12:35,   wrote:
> Status: Fixed
> Owner: stephane.ducasse
>
> New issue 3500 by stephane.ducasse: Create deprecated13
> http://code.google.com/p/pharo/issues/detail?id=3500
>
> We should create a package deprecated13 as one of the first move in 1.3.
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.

Re: [Pharo-project] new Cog VMs

[Philippe Marschall]

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: 1 do: [:i|]] timeToRun 691
> StackToRegisterMappingCogit: [1 to: 1 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 don't know how I can provide more information but I could upload the
image somewhere.


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' -> 10 ].
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 * (1 / runTime)) rounded.
backColor := spi > 100
ifT

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

[pharo]

Updates:
Status: Accepted

Comment #3 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods  
and publish them in a separate package

http://code.google.com/p/pharo/issues/detail?id=3501

we should pay attention that some methods are tagged 1.1 but this is better  
to key them in SmalltalkImage so we should probably just put them in a  
deprecated category but not in the package and add a comment to them

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

[pharo]

Comment #2 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods  
and publish them in a separate package

http://code.google.com/p/pharo/issues/detail?id=3501

http://code.google.com/p/pharo/issues/detail?id=2733

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

[pharo]

Comment #1 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods  
and publish them in a separate package

http://code.google.com/p/pharo/issues/detail?id=3501

related to 2733

[Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

[pharo]

Status: Fixed
Owner: stephane.ducasse
Labels: Milestone-1.3

New issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and  
publish them in a separate package

http://code.google.com/p/pharo/issues/detail?id=3501

1.1 deprecated methods should be packaged in a separate package and  
unloaded from 1.3

[Pharo-project] fixing deprecation process once for all

[Stéphane Ducasse]

I took 5 min and wrote down that
http://code.google.com/p/pharo/wiki/DeprecationProcess

comment if you want.

[Pharo-project] Issue 3500 in pharo: Create deprecated13

[pharo]

Status: Fixed
Owner: stephane.ducasse

New issue 3500 by stephane.ducasse: Create deprecated13
http://code.google.com/p/pharo/issues/detail?id=3500

We should create a package deprecated13 as one of the first move in 1.3.

Re: [Pharo-project] realized and learned something today :)

[Stéphane Ducasse]

Thanks stan :)
If you are looking for a master topic let us know :)
Now my point was more on us getting reality check than students not adoring our 
language.

Stef


> It vastly depends on the way it's presented. I'm a forth year student
> myself, I've been working for several years in java shops (& flex
> recently) and since I've discovered Pharo I started avoiding
> everything else :)
> 
> The image itself, dev tools in the same vm that runs the application,
> excellent frameworks (seaside is much much much more easier to setup
> and also that much easier to use compared to any, any java web
> framework), the really nice api/kernel classes. I DO love it!, and
> I've been exposed to basically everything else popular :)
> 
> However, one has to walk the path of pain (manually editing source
> code without highlight and completion, non-verbose compilers, missing
> debuggers, weird runtime dependencies/dll/jar hells, etc) to fully
> appreciate pharo and smalltalk in general. Otherwise he won't have the
> base to compare.
> Stanislav Paskalev
> 
> 
> 
> On Fri, Dec 31, 2010 at 7:06 PM, Stéphane Ducasse
>  wrote:
>> My point was not about pharo against squeak. I'm not at the microscopic 
>> level
>> I'm just thinking that remembering when is the last we were bold and face a 
>> complete room to students knowing Java, ruby
>> is a good way to get feedback on what we believe is cool.
>> 
>> Stef
> 

Re: [Pharo-project] WeakArray>>isFinalizationSupported

[Stéphane Ducasse]

Eliot I was replying and I throw away the mail :)
I already applied my new year resolution :)

Stef
PS: we know all that we should have better deprecation policy. We apply that 
but deprecation is good for little changes not huge ones.


> 
> 
> On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito 
>  wrote:
> Oh, come on... 
> 
> Levente, we all agree with you.  Pharo is trying to use that deprecation 
> policy since some months ago...  Sometimes people make mistakes (me included) 
> and don't do it, but we agreed that we have to deprecate and remove after two 
> versions of being deprecated.
> 
> I'm tired of this stupid arguments.
> 
> I expect the new year will bring us more doing and less discussing :).
> 
> Unless we are prepared to discuss, discover, admit and correct our mistakes 
> our doing will be of little worth.  I don't see anything stupid in discussing 
>  deprecation policy.  This criticism of Levente is entirely unjustified and 
> reminds me of recent treatment of certain prominent whistle-blowers.  Can we 
> just drop the childish feelings of hurt, and direct ourselves to the 
> substance of arguments rather than our immediate emotional reactions to 
> email?  We should all know by now that email is a particularly inexpressive 
> medium, prone to misinterpretation and therefore it behooves us to take a 
> breath before we reply and try and read beyond our surface perceptions.  [I 
> am a hypocrite in this regard having over-reacted recently over timestamps.]
> 
> Doubtless we are all imperfect in our use of email and can all do better 
> here.  But we won't get any better by lacking objectivity and reacting 
> emotionally to valid criticism.  Can we make one of our new year's 
> resolutions an attempt to be less emotional and more objective in all our 
> email discussions in the broader Squeak community?  Please?
> 
> Happy New Year
> Eliot
> 
> 2010/12/31 Levente Uzonyi 
> 
> On Fri, 31 Dec 2010, Miguel Cobá wrote:
> 
> El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:
> What you describe here is simply bad practice. One should run the tests
> before deploying code (besides testing the complete system thoroughly).
> If you use RFB, you can access the GUI in headless mode. Also when a
> debugger opens with a deprecation warning, the stack trace is written to
> the log file, so you will be notified about the problem even when you
> don't have access to the GUI.
> 
> Yeah, sure. But if it a second level dependency (a package I use that
> uses a package that contains popups deprecation warnings) I have big
> chances of being bite by this problem. I concede, this could be avoided
> by test-running every and whatnot package in the image but for a system
> that updates automatically this will bite.
> 
> So you're saying that it's better to get a DNU instead of a deprecation 
> warning with proper description about what and how to update/change?
> 
> 
> Levente
> 
> 
> Also, even if I can use RFB or read the image logs, I most likely will
> monitor the application logs and will pass a time without me knowing
> that some part of the application is waiting some user input.
> At the end I expect that the maintainer of the package is the
> *responsible* of test the application for the image I use, and not the
> user of the package. That is what I do with magma on Pharo. I test and
> fix the issues generated by the evolution of Pharo and then I release a
> new ConfigurationOfMagma that the user can use without knowing that n
> deprecations were involved in the upgrade of the package.
> 
> 
> 
> Anyway, there's no reason to remove a method (especially an API method)
> without deprecating and keeping it around for a few releases.
> 
> 
> I agree that is better to not forget to mark some method as deprecated
> but, again, I think that this promote the external packages not being
> updated to the current pharo image.
> 
> Cheers
> 
> -- 
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
> 
> 
> 
> 
> 
> 

Re: [Pharo-project] WeakArray>>isFinalizationSupported

[Stéphane Ducasse]

On Dec 31, 2010, at 8:50 PM, Guillermo Polito wrote:

> Oh, come on... 
> 
> Levente, we all agree with you.  Pharo is trying to use that deprecation 
> policy since some months ago...  Sometimes people make mistakes (me included) 
> and don't do it, but we agreed that we have to deprecate and remove after two 
> versions of being deprecated.
> 
> I'm tired of this stupid arguments.
> 
> I expect the new year will bring us more doing and less discussing :).

+ 1
What is interesting is to see that such kind of emails are often coming from 
the same source.

BTW guillermo I reallly deeply appreciate what you are doing on shortcut. I 
will have a look soon.
Now I'm fighting with pomodoro to get rid of an important porposal I keep 
postponing like an idiot.

Stef

Re: [Pharo-project] Proper Smalltalk lots of classes

[Stéphane Ducasse]

> Hello,
> 
> I am porting the FIX protocol to Squeak/Pharo.
> http://www.fixprotocol.org/
> 
> It is the Financial Information eXchange protocol. It is used by many firms 
> in the financial industries, stocks, forex, etc.


Excellent!


> 
> There is good documentation and also a semi-reference implementation in Java.
> http://www.quickfixj.org
> 
> I have a partial port started but I wanted a check with those who know more 
> than I about proper Smalltalk coding.
> 
> In the Java implementation there are over 2000 classes. In the protocol there 
> are approximately 90 message types and 956 field types.
> 
> I am initially creating the message classes as they form the basis of the 
> protocol and the fields are simply instance variables and methods in the 
> message classes.

do you have some examples because replying like that in the blue is difficult. 



> I am not porting the Java library. I am implementing the protocol in 
> Smalltalk from the documentation.
> 
> Initially I have created a Fix44Field class with its necessary variables.
> There are several versions of the Protocol and FIX 4.4 is the one required 
> for my application.
> 
> With this Fix44Field class I am creating a Dictionary with the 956 different 
> field types. I am planning on creating a constructor method which will create 
> the desired field from the information in the dictionary about the field and 
> its properties.

this sounds right. 
or you can have a method that takes a list and fill up

> 
> Am I way off base here? Should I really create the 956 classes necessary to 
> for each field in addition to the 90 or so message classes, and then I don't 
> know what else I haven't discovered yet. Having 1000+ classes just seems 
> unwieldy and naively it just doesn't feel like the Smalltalk way.

For me number of classes has never been a design criteria. Now is the behavior 
different on each of them? what are the variations?
Can we represent them as constant in a classVar somewhere?

> I could be wrong, but I haven't seen such an example to my memory. I don't 
> know enough about Java to know if it is good Java form either.
> 
> When I have a reasonably fleshed out, tested and working solution, I will 
> make the source available under a MIT license. I would love to see 
> Squeak/Pharo become an out of the box viable option for trading applications.

me t :)

> 
> Advise and wisdom greatly appreciated.
> 
> Thanks.
> 
> Jimmie
>