Daily Commit Log

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Daily Commit Log

commits-2
Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007036.html

Name: KernelTests-eem.269
Ancestors: KernelTests-nice.268

Add a test to check that empty blocks evaluate to nil

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007037.html

Name: Compiler-eem.280
Ancestors: Compiler-nice.279

Get rid of the old
        ([:a :b|] value: #first value: #last) == #last
anachronism.  Now all empty blocks answer nil.

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007038.html

Name: Kernel-nice.849
Ancestors: Kernel-nice.848

(Issue http://bugs.squeak.org/view.php?id=7755)

Note that if other letters follow the s, then s is not interpreted as a scale, because it could be a message.
For example, (25sin) is interpreted as (25 sin) like in Pharo rather than (25s0 in) like in VW.
This way, the chances of ambiguous interpretation of existing code base is limited to the sole message #s.

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007039.html

Name: KernelTests-nice.270
Ancestors: KernelTests-eem.269

Document the new possibility to specify a ScaledDecimal with implicit scale like 12.34s
Rather than duplicating NumberParsingTest job, document current behavior of (Integer readFrom: stringOrStream) which is far from obvious
For example:
        (Fraction readFrom: '4e3') -> 4000 but (Integer readFrom: '4e3') -> 4
        (Fraction readFrom: '2r101') -> 5 but (Integer readFrom: '2r101') -> 2
IMO, this should be changed, old behavior is still accessible thru (Integer readFrom: '4e3' base: 10)
Remove other redundant number parsing tests from IntegerTest (a deeper refactoring of number parsing tests would be welcome)

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007040.html

Name: MonticelloConfigurations-nice.126
Ancestors: MonticelloConfigurations-eem.125

Be resilient to a potentially empty secondaryUpdateURL.

=============================================

Reply | Threaded
Open this post in threaded view
|

Re: Daily Commit Log

Nicolas Cellier



2014-05-13 1:55 GMT+02:00 <[hidden email]>:
Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007036.html

Name: KernelTests-eem.269
Ancestors: KernelTests-nice.268

Add a test to check that empty blocks evaluate to nil

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007037.html

Name: Compiler-eem.280
Ancestors: Compiler-nice.279

Get rid of the old
        ([:a :b|] value: #first value: #last) == #last
anachronism.  Now all empty blocks answer nil.

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007038.html

Name: Kernel-nice.849
Ancestors: Kernel-nice.848


Hey, I wrote this:
Authorize implicit specification of ScaledDecimal scale 123s -> 123.s0 , 0.27s -> 0.27s2 like VW and Pharo.
Why did it disappear ?
 
(Issue http://bugs.squeak.org/view.php?id=7755)

Note that if other letters follow the s, then s is not interpreted as a scale, because it could be a message.
For example, (25sin) is interpreted as (25 sin) like in Pharo rather than (25s0 in) like in VW.
This way, the chances of ambiguous interpretation of existing code base is limited to the sole message #s.

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007039.html

Name: KernelTests-nice.270
Ancestors: KernelTests-eem.269

Document the new possibility to specify a ScaledDecimal with implicit scale like 12.34s
Rather than duplicating NumberParsingTest job, document current behavior of (Integer readFrom: stringOrStream) which is far from obvious
For example:
        (Fraction readFrom: '4e3') -> 4000 but (Integer readFrom: '4e3') -> 4
        (Fraction readFrom: '2r101') -> 5 but (Integer readFrom: '2r101') -> 2
IMO, this should be changed, old behavior is still accessible thru (Integer readFrom: '4e3' base: 10)
Remove other redundant number parsing tests from IntegerTest (a deeper refactoring of number parsing tests would be welcome)

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-May/007040.html

Name: MonticelloConfigurations-nice.126
Ancestors: MonticelloConfigurations-eem.125

Be resilient to a potentially empty secondaryUpdateURL.

=============================================