<div dir="ltr"><div><div>Oops !<br></div>It seems that I updated from 5.0 repository rather than trunk.<br></div><div>I've been away too long, let me redo it...<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-23 23:34 GMT+02:00 <span dir="ltr"><<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nicolas Cellier uploaded a new version of Kernel to project The Trunk:<br>
<a href="http://source.squeak.org/trunk/Kernel-nice.939.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/trunk/Kernel-nice.939.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Kernel-nice.939<br>
Author: nice<br>
Time: 23 April 2016, 11:32:52.246 pm<br>
UUID: 4bdcd7ec-9c52-4b77-94e1-cf87a2ee35d5<br>
Ancestors: Kernel-mt.938<br>
<br>
Accelerate bitAnd: in case of negative small integer receiver and LargePositiveInteger operand.<br>
<br>
The timings before and after are:<br>
<br>
[(-1234 bitAnd: 5678)] bench.<br>
161,000,000 per second. 6.22 nanoseconds per run.<br>
161,000,000 per second. 6.2 nanoseconds per run.<br>
[(-1234 bitAnd: 5678125641253)] bench.<br>
1,120,000 per second. 892 nanoseconds per run.<br>
5,020,000 per second. 199 nanoseconds per run.<br>
[(-1234 bitAnd: -5678125641253)] bench.<br>
1,830,000 per second. 547 nanoseconds per run.<br>
1,790,000 per second. 557 nanoseconds per run.<br>
[(-1234 bitAnd: 567812564128976768553)] bench.<br>
984,000 per second. 1.02 microseconds per run.<br>
2,320,000 per second. 431 nanoseconds per run.<br>
[(-1234 bitAnd: -567812564128976768553)] bench.<br>
1,790,000 per second. 559 nanoseconds per run.<br>
1,690,000 per second. 593 nanoseconds per run.<br>
<br>
=============== Diff against Kernel-cmm.937 ===============<br>
<br>
Item was changed:<br>
----- Method: Process>>stepToHome: (in category 'changing suspended state') -----<br>
stepToHome: aContext<br>
"Resume self until the home of top context is aContext. Top context may be a block context.<br>
Catch any UnhandledErrors that are created while stepping, answering the relevant signalerContext<br>
if so. Note that this will cause weird effects if using through to step through UnhandledError<br>
code, but as the doctor ordered, don't do that; use over or into instead."<br>
<br>
^Processor activeProcess<br>
evaluate:<br>
[| home anError |<br>
home := aContext home.<br>
[suspendedContext := suspendedContext step.<br>
home == suspendedContext home or: [home isDead]] whileFalse:<br>
[(suspendedContext selector == #signalForException:<br>
+ and: [(suspendedContext receiver isBehavior and: [<br>
+ suspendedContext receiver includesBehavior: UnhandledError])<br>
- and: [suspendedContext receiver == UnhandledError<br>
and: [anError := suspendedContext tempAt: 1.<br>
((suspendedContext objectClass: anError) includesBehavior: Exception)<br>
and: [anError canSearchForSignalerContext]]]) ifTrue:<br>
[anError signalerContext ifNotNil:<br>
[:unhandledErrorSignalerContext|<br>
[unhandledErrorSignalerContext == suspendedContext] whileFalse:<br>
[self completeStep: suspendedContext].<br>
"Give a debugger a chance to update its title to reflect the new exception"<br>
Notification new<br>
tag: {unhandledErrorSignalerContext. anError};<br>
signal.<br>
^unhandledErrorSignalerContext]]].<br>
suspendedContext]<br>
onBehalfOf: self!<br>
<br>
Item was changed:<br>
----- Method: SmallInteger>>bitAnd: (in category 'bit manipulation') -----<br>
bitAnd: arg<br>
"Primitive. Answer an Integer whose bits are the logical OR of the<br>
receiver's bits and those of the argument, arg.<br>
Numbers are interpreted as having 2's-complement representation.<br>
Essential. See Object documentation whatIsAPrimitive."<br>
<br>
<primitive: 14><br>
self >= 0 ifTrue: [^ arg bitAnd: self].<br>
+ ^ arg < 0<br>
+ ifTrue: [(arg bitInvert bitOr: self bitInvert) bitInvert]<br>
+ ifFalse: [arg bitClear: self bitInvert]!<br>
- ^ (self bitInvert bitOr: arg bitInvert) bitInvert!<br>
<br>
Item was changed:<br>
Exception subclass: #UnhandledError<br>
instanceVariableNames: 'exception'<br>
classVariableNames: ''<br>
poolDictionaries: ''<br>
category: 'Kernel-Exceptions'!<br>
+<br>
+ !UnhandledError commentStamp: 'mt 8/25/2015 14:42' prior: 0!<br>
+ This is a wrapper for an unhandled error. Having this, process stepping is able to correctly fire other unhandled errors. See Process >> #stepToHome: for further explanations.!<br>
<br>
Item was changed:<br>
----- Method: UnhandledError class>>signalForException: (in category 'as yet unclassified') -----<br>
signalForException: anError<br>
+ "Very important entry point for analysis stack when stepping in a debugging session. See Process >> #stepToHome: for further explanations."<br>
+<br>
-<br>
^ self new<br>
exception: anError;<br>
signal!<br>
<br>
Item was changed:<br>
+ ----- Method: UnhandledError>>exception (in category 'accessing') -----<br>
- ----- Method: UnhandledError>>exception (in category 'as yet unclassified') -----<br>
exception<br>
<br>
^ exception!<br>
<br>
Item was changed:<br>
+ ----- Method: UnhandledError>>exception: (in category 'accessing') -----<br>
- ----- Method: UnhandledError>>exception: (in category 'as yet unclassified') -----<br>
exception: anError<br>
<br>
exception := anError!<br>
<br>
Item was added:<br>
+ UnhandledError subclass: #UnhandledWarning<br>
+ instanceVariableNames: ''<br>
+ classVariableNames: ''<br>
+ poolDictionaries: ''<br>
+ category: 'Kernel-Exceptions'!<br>
<br>
<br>
</blockquote></div><br></div>