[Pharo-project] [ANN] Closures for beta testers
Hi all I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures? Stef
Is the image available for download? Rob On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane stef On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks...I'll give it a try for you on Windows... Rob On Sun, Mar 22, 2009 at 1:37 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane
stef
On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pay attention you need a closureVM. Stef On Mar 22, 2009, at 6:40 PM, Rob Rothwell wrote:
Thanks...I'll give it a try for you on Windows...
Rob
On Sun, Mar 22, 2009 at 1:37 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane
stef
On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yep...since it came out, I've just been using it to see if it caused any problems! Rob On Sun, Mar 22, 2009 at 1:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Pay attention you need a closureVM.
Stef
On Mar 22, 2009, at 6:40 PM, Rob Rothwell wrote:
Thanks...I'll give it a try for you on Windows...
Rob
On Sun, Mar 22, 2009 at 1:37 PM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote: yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane
stef
On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Excellent! On which OS are you? Syeg On Mar 22, 2009, at 6:48 PM, Rob Rothwell wrote:
Yep...since it came out, I've just been using it to see if it caused any problems!
Rob
On Sun, Mar 22, 2009 at 1:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Pay attention you need a closureVM.
Stef
On Mar 22, 2009, at 6:40 PM, Rob Rothwell wrote:
Thanks...I'll give it a try for you on Windows...
Rob
On Sun, Mar 22, 2009 at 1:37 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane
stef
On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Well, I don't have any "tough, real world examples," but the example Bert gave me: multiply := Array new: 4. 1 to: 4 do: [:i | multiply at: i put: [:x | x * i]. ]. (multiply at: 3) value: 5. Resulted in the appropriate answer 15!!! Rob On Sun, Mar 22, 2009 at 1:40 PM, Rob Rothwell <r.j.rothwell@gmail.com>wrote:
Thanks...I'll give it a try for you on Windows...
Rob
On Sun, Mar 22, 2009 at 1:37 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane
stef
On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Rob Rothwell writes:
Well, I don't have any "tough, real world examples," but the example Bert gave me:
multiply := Array new: 4. 1 to: 4 do: [:i | multiply at: i put: [:x | x * i]. ].
(multiply at: 3) value: 5.
Resulted in the appropriate answer 15!!!
I tried this on Linux, and it works. Poking around a bit more brought up the emergency evaluator because BlockClosure doesn't understand #isValid:. Bryce P.S I'm not going to have much time in April as we have family staying and our second son is due.
Yes I fixed that and asMinimalRepresentation already. Stef On Mar 22, 2009, at 9:57 PM, <bryce@kampjes.demon.co.uk> wrote:
Rob Rothwell writes:
Well, I don't have any "tough, real world examples," but the example Bert gave me:
multiply := Array new: 4. 1 to: 4 do: [:i | multiply at: i put: [:x | x * i]. ].
(multiply at: 3) value: 5.
Resulted in the appropriate answer 15!!!
I tried this on Linux, and it works.
Poking around a bit more brought up the emergency evaluator because BlockClosure doesn't understand #isValid:.
Bryce
P.S I'm not going to have much time in April as we have family staying and our second son is due.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is the closure boostrap zip? I ran it under Bryce's recent expupery vm (win32) and was fine up until UIThemeVistary beCurrent. I backtracked to try 'hello' at:200 and got a very similar stack trace. I do not know the correct jargon, but it is not a notifier or debugger, just text in the upper left corner of the main window. Hitting a key clears it, as promised. Something is very upset about BlockClosure>>isValid. Is there something I might be too ignorant to have done to get the image ready for use? Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Rob Rothwell Sent: Sunday, March 22, 2009 12:41 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Closures for beta testers Thanks...I'll give it a try for you on Windows... Rob On Sun, Mar 22, 2009 at 1:37 PM, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane stef On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I guess not. Normally if Bryce support closure the rest should flow. :) Stef On Mar 22, 2009, at 7:02 PM, Schwab,Wilhelm K wrote:
This is the closure boostrap zip? I ran it under Bryce's recent expupery vm (win32) and was fine up until
UIThemeVistary beCurrent.
I got the same on mac so this is good
I backtracked to try
'hello' at:200
and got a very similar stack trace. I do not know the correct jargon, but it is not a notifier or debugger, just text in the upper left corner of the main window. Hitting a key clears it, as promised.
Something is very upset about BlockClosure>>isValid. Is there something I might be too ignorant to have done to get the image ready for use?
Bill
--- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Rob Rothwell Sent: Sunday, March 22, 2009 12:41 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Closures for beta testers
Thanks...I'll give it a try for you on Windows...
Rob
On Sun, Mar 22, 2009 at 1:37 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: yes at https://gforge.inria.fr/frs/?group_id=1299 then files pane
stef
On Mar 22, 2009, at 6:23 PM, Rob Rothwell wrote:
Is the image available for download?
Rob
On Sun, Mar 22, 2009 at 1:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi all
I did the following: - loaded john adaptation layer - loaded install - followed the instructions - saved - load tempVariable fix - saved I did not saved the dirty packages for now. This release is to make sure that the image can be viable and that VM are working once we move to the closure. So can you check and let us know if this is working on the new VM 40 for the closures?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit. BlockContext defined isValid (a polymoprph-EventEnhancements) sent by BlockContext>>isValid "Answer true so we can be used in event dispatching." ^true WeakActionSequence>>asMinimalRepresentation | valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem of course this is a shitty way to answer the problem. Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems [closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation BlockContext>>asMinimalRepresentation "Answer the receiver." ^self I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing. stef
probably doing a difference between the interface of BlockContext and BlockClosure will help. Stef On Mar 22, 2009, at 7:34 PM, Stéphane Ducasse wrote:
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid "Answer true so we can be used in event dispatching."
^true
WeakActionSequence>>asMinimalRepresentation
| valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation "Answer the receiver."
^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Another thing that is missing in ContextPart is #methodSelector, used by the debugger. Fix attached. On Sun, Mar 22, 2009 at 7:44 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
probably doing a difference between the interface of BlockContext and BlockClosure will help.
Stef On Mar 22, 2009, at 7:34 PM, Stéphane Ducasse wrote:
 UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid    "Answer true so we can be used in event dispatching."
   ^true
WeakActionSequence>>asMinimalRepresentation
   | valid |    valid := self select: [:e | e isValid ].    valid size = 0        ifTrue: [^nil].    valid size = 1        ifTrue: [^valid first].    ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation    "Answer the receiver."
   ^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Excellent I created an issue. what I will do is to run the tests before and after. http://code.google.com/p/pharo/issues/detail?id=685 Stef On Mar 22, 2009, at 8:01 PM, Lukas Renggli wrote:
Another thing that is missing in ContextPart is #methodSelector, used by the debugger.
Fix attached.
On Sun, Mar 22, 2009 at 7:44 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
probably doing a difference between the interface of BlockContext and BlockClosure will help.
Stef On Mar 22, 2009, at 7:34 PM, Stéphane Ducasse wrote:
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid "Answer true so we can be used in event dispatching."
^true
WeakActionSequence>>asMinimalRepresentation
| valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation "Answer the receiver."
^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch <FixDebugger.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Apparently Traits do not understand variablesAndOffsetsDo: invoked indirectly from parse: sourceStream class: class category: aCategory noPattern: noPattern context: ctxt notifying: req ifFail: aBlock EncoderForV3PlusClosure>>init: aClass context: aContext notifying: req requestor := req. class := aClass. nTemps := 0. supered := false. self initScopeAndLiteralTables. class variablesAndOffsetsDo: [:variable "<String|CFieldDefinition>" :offset "<Integer|nil>" | offset isNil ifTrue: [scopeTable at: variable name put: ((Smalltalk at: #FieldNode ifAbsent: [self error: 'FiledNode is missing']) new fieldDefinition: variable)] ifFalse: [scopeTable at: variable put: (offset >= 0 ifTrue: [InstanceVariableNode new name: variable index: offset] ifFalse: [MaybeContextInstanceVariableNode new name: variable index: offset negated])]]. aContext ~~ nil ifTrue: [| homeNode | homeNode := self bindTemp: self doItInContextName. "0th temp = aContext passed as arg" aContext tempNames withIndexDo: [:variable :index| scopeTable at: variable put: (MessageAsTempNode new receiver: homeNode selector: #namedTempAt: arguments: (Array with: (self encodeLiteral: index)) precedence: 3 from: self)]]. sourceRanges := Dictionary new: 32. globalSourceRanges := OrderedCollection new: 32
run the tests - with the four fixes so far isValid, asMiniRepresentation methodSelector, variablesAndOffsetsDo: 2941 run, 2875 passes, 2 expected failures, 15 failures, 49 errors, 0 unexpected passes vs. in 10259 2929 run, 2908 passes, 2 expected failures, 12 failures, 7 errors, 0 unexpected passes Investigating the tests show that BlockContextTest PCCByCompilationTest ClosureCompilerTest are producing a lot of errors. I can post the two images somewhere if this helps. Stef
On Sun, Mar 22, 2009 at 10:11 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I can post the two images somewhere if this helps.
Please provide a new image or update the stream. -- Damien Cassou http://damiencassou.seasidehosting.st
For the moment I do not want to do that before we have some fixes ready. Eliot should produce a new version. So what I can do is to publish two images with the test run so that people can help to check the problem. stef On Mar 23, 2009, at 9:50 AM, Damien Cassou wrote:
On Sun, Mar 22, 2009 at 10:11 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I can post the two images somewhere if this helps.
Please provide a new image or update the stream.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
There is a DNU after trying to open the SqueakMap Package Loader- Tool... VM: Squeak 3.11.1 (alpha) - (The above "multiply" test ^^ succeded) IMG: 10259-ClosureBootstrap OS: Windows Vista x64 2009/3/22 Stéphane Ducasse <stephane.ducasse@inria.fr>
probably doing a difference between the interface of BlockContext and BlockClosure will help.
Stef On Mar 22, 2009, at 7:34 PM, Stéphane Ducasse wrote:
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid "Answer true so we can be used in event dispatching."
^true
WeakActionSequence>>asMinimalRepresentation
| valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation "Answer the receiver."
^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
did it work in the nonclosure version? Stef On Mar 22, 2009, at 8:06 PM, Marco Schmidt wrote:
There is a DNU after trying to open the SqueakMap Package Loader- Tool...
VM: Squeak 3.11.1 (alpha) - (The above "multiply" test ^^ succeded) IMG: 10259-ClosureBootstrap OS: Windows Vista x64
2009/3/22 Stéphane Ducasse <stephane.ducasse@inria.fr> probably doing a difference between the interface of BlockContext and BlockClosure will help.
Stef On Mar 22, 2009, at 7:34 PM, Stéphane Ducasse wrote:
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid "Answer true so we can be used in event dispatching."
^true
WeakActionSequence>>asMinimalRepresentation
| valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation "Answer the receiver."
^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
<SqueakDebug - Kopie.log>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, Adding #isValid got me a little further along. I was able to select the new theme and can at least open a debugger, though _using_ it stirs up trouble over #asMinimalRepresentation (or similar method). In trying to evaluate 'hello' at:200, I was faced with some message boxes claiming there was no such method; that seemed to happen w/ vistary and not watery2??? I too had problems closing windows. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, March 22, 2009 1:35 PM To: Pharo-project@lists.gforge.inria.fr Cc: Eliot Miranda Subject: Re: [Pharo-project] [ANN] Closures for beta testers
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit. BlockContext defined isValid (a polymoprph-EventEnhancements) sent by BlockContext>>isValid "Answer true so we can be used in event dispatching." ^true WeakActionSequence>>asMinimalRepresentation | valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem of course this is a shitty way to answer the problem. Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems [closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation BlockContext>>asMinimalRepresentation "Answer the receiver." ^self I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing. stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
http://code.google.com/p/pharo/issues/detail?id=337 I believe the resolution then was Gary moving the two methods to Polymorph-Overrides. Probably some house-cleaning which caused them to be lost this time. I still stand by my OR: suggestion from back then, isValid is a terrible method name, imo ;) Cheers, Henry Schwab,Wilhelm K wrote:
Stef,
Adding #isValid got me a little further along. I was able to select the new theme and can at least open a debugger, though _using_ it stirs up trouble over #asMinimalRepresentation (or similar method). In trying to evaluate 'hello' at:200, I was faced with some message boxes claiming there was no such method; that seemed to happen w/ vistary and not watery2??? I too had problems closing windows.
Bill
--- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, March 22, 2009 1:35 PM To: Pharo-project@lists.gforge.inria.fr Cc: Eliot Miranda Subject: Re: [Pharo-project] [ANN] Closures for beta testers
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid "Answer true so we can be used in event dispatching."
^true
WeakActionSequence>>asMinimalRepresentation
| valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation "Answer the receiver."
^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
My bad, meant Polymorph-EventEnhancements. Some more details for those interested (hope I remember correctly this time): The two methods are needed if one wants to be able to use something as argument for the evaluate part of Object when: #XYZ evaluate: myBlock, due to ActionSequence implementation details... For Polymorph, in the createXYZBoxFor: methods in the Vistary themes, addUpAction: does just that with blocks, thus the methods are needed for it. Cheers, Henry Henrik Johansen wrote:
http://code.google.com/p/pharo/issues/detail?id=337
I believe the resolution then was Gary moving the two methods to Polymorph-Overrides. Probably some house-cleaning which caused them to be lost this time. I still stand by my OR: suggestion from back then, isValid is a terrible method name, imo ;)
Cheers, Henry
Schwab,Wilhelm K wrote:
Stef,
Adding #isValid got me a little further along. I was able to select the new theme and can at least open a debugger, though _using_ it stirs up trouble over #asMinimalRepresentation (or similar method). In trying to evaluate 'hello' at:200, I was faced with some message boxes claiming there was no such method; that seemed to happen w/ vistary and not watery2??? I too had problems closing windows.
Bill
--- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, March 22, 2009 1:35 PM To: Pharo-project@lists.gforge.inria.fr Cc: Eliot Miranda Subject: Re: [Pharo-project] [ANN] Closures for beta testers
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid "Answer true so we can be used in event dispatching."
^true
WeakActionSequence>>asMinimalRepresentation
| valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation "Answer the receiver."
^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
ok for now I patched that :) On Mar 23, 2009, at 11:56 AM, Henrik Johansen wrote:
My bad, meant Polymorph-EventEnhancements. Some more details for those interested (hope I remember correctly this time): The two methods are needed if one wants to be able to use something as argument for the evaluate part of Object when: #XYZ evaluate: myBlock, due to ActionSequence implementation details... For Polymorph, in the createXYZBoxFor: methods in the Vistary themes, addUpAction: does just that with blocks, thus the methods are needed for it.
Cheers, Henry
Henrik Johansen wrote:
http://code.google.com/p/pharo/issues/detail?id=337
I believe the resolution then was Gary moving the two methods to Polymorph-Overrides. Probably some house-cleaning which caused them to be lost this time. I still stand by my OR: suggestion from back then, isValid is a terrible method name, imo ;)
Cheers, Henry
Schwab,Wilhelm K wrote:
Stef,
Adding #isValid got me a little further along. I was able to select the new theme and can at least open a debugger, though _using_ it stirs up trouble over #asMinimalRepresentation (or similar method). In trying to evaluate 'hello' at:200, I was faced with some message boxes claiming there was no such method; that seemed to happen w/ vistary and not watery2??? I too had problems closing windows.
Bill
--- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Sunday, March 22, 2009 1:35 PM To: Pharo-project@lists.gforge.inria.fr Cc: Eliot Miranda Subject: Re: [Pharo-project] [ANN] Closures for beta testers
UIThemeVistary beCurrent.
what is nice is that the VM does not crash. I cannot open any browser. So in another image I checked a bit.
BlockContext defined isValid (a polymoprph-EventEnhancements)
sent by
BlockContext>>isValid "Answer true so we can be used in event dispatching."
^true
WeakActionSequence>>asMinimalRepresentation
| valid | valid := self select: [:e | e isValid ]. valid size = 0 ifTrue: [^nil]. valid size = 1 ifTrue: [^valid first]. ^valid
I do not really know the code of gary. As a pure hack I added isValid to blockClosure to return true and I did not get the problem
of course this is a shitty way to answer the problem.
Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems
[closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation
BlockContext>>asMinimalRepresentation "Answer the receiver."
^self
I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far so that we can go faster to fix the problems https://gforge.inria.fr/frs/?group_id=1299 and files Stef
Here's a fix for the BlockContext test. Basically, the error message had changed format, so the test that the correct error message was reported failed. I changed the test to check for the (new) error format (which adds argument(s) at the end of the sentence), and changed the error message to not call printstring, since this resulted in the string containing '1' instead of 1. For some reason (which I'm not aware of) the printstring of numbers seem to include quotes. On a totally unrelated note, (didn't include it in the cs since it's not remotely related) Debugger contents:notifying contains a call to Smalltalk>> isMorphic which should probably be removed, comes up everytime you try to save a method edit in the debugger. Cheers, Henry Stéphane Ducasse wrote:
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far
so that we can go faster to fix the problems
https://gforge.inria.fr/frs/?group_id=1299 and files
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10259] on 23 March 2009 at 1:47:53 pm'! !BlockClosure methodsFor: 'error handing' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! numArgsError: numArgsForInvocation | printNArgs | printNArgs := [:n| n printString, ' argument', (n = 1 ifTrue: [''] ifFalse:['s'])]. self error: 'This block accepts ', (printNArgs value: numArgs), ', but was called with ', (printNArgs value: numArgsForInvocation), '.'! ! !BlockContextTest methodsFor: 'tests - evaluating' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! testValueWithArguments self should: [aBlockContext valueWithArguments: #(1 )] raise: Error. self shouldnt: [aBlockContext valueWithArguments: #()] raise: Error. [aBlockContext valueWithArguments: #(1 )] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 0 arguments, but was called with 1 argument.']. [[:i | 3 + 4] valueWithArguments: #(1 2)] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 1 argument, but was called with 2 arguments.']! !
excellent!!!! can you post cs to the Bugtracker so that we can reload all the fixes in a couple of click? http://code.google.com/p/pharo/issues/detail?id=685 I'm busy writing something else right now Stef On Mar 23, 2009, at 1:53 PM, Henrik Johansen wrote:
Here's a fix for the BlockContext test. Basically, the error message had changed format, so the test that the correct error message was reported failed. I changed the test to check for the (new) error format (which adds argument(s) at the end of the sentence), and changed the error message to not call printstring, since this resulted in the string containing '1' instead of 1. For some reason (which I'm not aware of) the printstring of numbers seem to include quotes.
On a totally unrelated note, (didn't include it in the cs since it's not remotely related) Debugger contents:notifying contains a call to Smalltalk>> isMorphic which should probably be removed, comes up everytime you try to save a method edit in the debugger.
Cheers, Henry
Stéphane Ducasse wrote:
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far
so that we can go faster to fix the problems
https://gforge.inria.fr/frs/?group_id=1299 and files
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10259] on 23 March 2009 at 1:47:53 pm'!
!BlockClosure methodsFor: 'error handing' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! numArgsError: numArgsForInvocation
| printNArgs | printNArgs := [:n| n printString, ' argument', (n = 1 ifTrue: [''] ifFalse:['s'])]. self error: 'This block accepts ', (printNArgs value: numArgs), ', but was called with ', (printNArgs value: numArgsForInvocation), '.'! !
!BlockContextTest methodsFor: 'tests - evaluating' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! testValueWithArguments self should: [aBlockContext valueWithArguments: #(1 )] raise: Error. self shouldnt: [aBlockContext valueWithArguments: #()] raise: Error. [aBlockContext valueWithArguments: #(1 )] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 0 arguments, but was called with 1 argument.']. [[:i | 3 + 4] valueWithArguments: #(1 2)] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 1 argument, but was called with 2 arguments.']! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Done and done. I'd rather not make a .cs for the ClosureCompilerTest >>testInjectIntoDecompilations failure though, as I neither feel comfortable messing around with Scanner, nor particularily feel like it would be a good idea to change the test to assume _ instead of := ... Cheers, Henry Stéphane Ducasse wrote:
excellent!!!! can you post cs to the Bugtracker so that we can reload all the fixes in a couple of click?
http://code.google.com/p/pharo/issues/detail?id=685
I'm busy writing something else right now
Stef On Mar 23, 2009, at 1:53 PM, Henrik Johansen wrote:
Here's a fix for the BlockContext test. Basically, the error message had changed format, so the test that the correct error message was reported failed. I changed the test to check for the (new) error format (which adds argument(s) at the end of the sentence), and changed the error message to not call printstring, since this resulted in the string containing '1' instead of 1. For some reason (which I'm not aware of) the printstring of numbers seem to include quotes.
On a totally unrelated note, (didn't include it in the cs since it's not remotely related) Debugger contents:notifying contains a call to Smalltalk>> isMorphic which should probably be removed, comes up everytime you try to save a method edit in the debugger.
Cheers, Henry
Stéphane Ducasse wrote:
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far
so that we can go faster to fix the problems
https://gforge.inria.fr/frs/?group_id=1299 and files
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10259] on 23 March 2009 at 1:47:53 pm'!
!BlockClosure methodsFor: 'error handing' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! numArgsError: numArgsForInvocation
| printNArgs | printNArgs := [:n| n printString, ' argument', (n = 1 ifTrue: [''] ifFalse:['s'])]. self error: 'This block accepts ', (printNArgs value: numArgs), ', but was called with ', (printNArgs value: numArgsForInvocation), '.'! !
!BlockContextTest methodsFor: 'tests - evaluating' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! testValueWithArguments self should: [aBlockContext valueWithArguments: #(1 )] raise: Error. self shouldnt: [aBlockContext valueWithArguments: #()] raise: Error. [aBlockContext valueWithArguments: #(1 )] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 0 arguments, but was called with 1 argument.']. [[:i | 3 + 4] valueWithArguments: #(1 2)] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 1 argument, but was called with 2 arguments.']! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I saw thanks. I hope to get some times continuing to explore the possible fixes. Stef On Mar 23, 2009, at 4:49 PM, Henrik Johansen wrote:
Done and done. I'd rather not make a .cs for the ClosureCompilerTest >>testInjectIntoDecompilations failure though, as I neither feel comfortable messing around with Scanner, nor particularily feel like it would be a good idea to change the test to assume _ instead of := ...
Cheers, Henry
Stéphane Ducasse wrote:
excellent!!!! can you post cs to the Bugtracker so that we can reload all the fixes in a couple of click?
http://code.google.com/p/pharo/issues/detail?id=685
I'm busy writing something else right now
Stef On Mar 23, 2009, at 1:53 PM, Henrik Johansen wrote:
Here's a fix for the BlockContext test. Basically, the error message had changed format, so the test that the correct error message was reported failed. I changed the test to check for the (new) error format (which adds argument(s) at the end of the sentence), and changed the error message to not call printstring, since this resulted in the string containing '1' instead of 1. For some reason (which I'm not aware of) the printstring of numbers seem to include quotes.
On a totally unrelated note, (didn't include it in the cs since it's not remotely related) Debugger contents:notifying contains a call to Smalltalk>> isMorphic which should probably be removed, comes up everytime you try to save a method edit in the debugger.
Cheers, Henry
Stéphane Ducasse wrote:
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far
so that we can go faster to fix the problems
https://gforge.inria.fr/frs/?group_id=1299 and files
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10259] on 23 March 2009 at 1:47:53 pm'!
!BlockClosure methodsFor: 'error handing' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! numArgsError: numArgsForInvocation
| printNArgs | printNArgs := [:n| n printString, ' argument', (n = 1 ifTrue: [''] ifFalse:['s'])]. self error: 'This block accepts ', (printNArgs value: numArgs), ', but was called with ', (printNArgs value: numArgsForInvocation), '.'! !
!BlockContextTest methodsFor: 'tests - evaluating' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! testValueWithArguments self should: [aBlockContext valueWithArguments: #(1 )] raise: Error. self shouldnt: [aBlockContext valueWithArguments: #()] raise: Error. [aBlockContext valueWithArguments: #(1 )] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 0 arguments, but was called with 1 argument.']. [[:i | 3 + 4] valueWithArguments: #(1 2)] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 1 argument, but was called with 2 arguments.']! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
And another one, for the ByteArrayWithinArray test, the compiled array there was missing a # for the first ByteArray. 'array ^ #( [1] #[2] )' -> 'array ^ #( #[1] #[2] )'. Cheers, Henry Stéphane Ducasse wrote:
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far
so that we can go faster to fix the problems
https://gforge.inria.fr/frs/?group_id=1299 and files
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10259] on 23 March 2009 at 1:57:53 pm'! !ArrayLiteralTest methodsFor: 'tests' stamp: 'Henrik Sperre Johansen 3/23/2009 13:55'! testByteArrayWithinArray self class compile: 'array ^ #( #[1] #[2] )'. self assert: (self array isKindOf: Array). self assert: (self array size = 2). self assert: (self array first isKindOf: ByteArray). self assert: (self array first first = 1). self assert: (self array last isKindOf: ByteArray). self assert: (self array last first = 2) ! !
What is a good test? The image seems to run ok on windows. Mike On 3/23/09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far
so that we can go faster to fix the problems
https://gforge.inria.fr/frs/?group_id=1299 and files
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
ClosureCompilerTest >>testInjectIntoDecompilations fails since Scanner translates := to _, so the test array does not match. ( Test-array has := ). "Offending" method is Scanner >> xColon. Stéphane Ducasse wrote:
I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far
so that we can go faster to fix the problems
https://gforge.inria.fr/frs/?group_id=1299 and files
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (9)
-
bryce＠kampjes.demon.co.uk -
Damien Cassou -
Henrik Johansen -
Lukas Renggli -
Marco Schmidt -
Michael Roberts -
Rob Rothwell -
Schwab,Wilhelm K -
Stéphane Ducasse