… that is possible fix. Or fix of one of the problems…
In the old bytecode, block creation was done with a message send, so
#stepToSendOrReturn never run across a block creation boundary. Now, with the
block creation bytecode, if you step, it will run until the first send of
access in the
Branch: refs/heads/3.0
Home: https://github.com/pharo-project/pharo-core
Commit: dfb2a225c77d44a402ec8a816641dec7f1d8666c
https://github.com/pharo-project/pharo-core/commit/dfb2a225c77d44a402ec8a816641dec7f1d8666c
Author: Jenkins Build Server bo...@pharo-project.org
Date:
Branch: refs/tags/30583
Home: https://github.com/pharo-project/pharo-core
Among the many messages sent automatically by our magic systems, this one
strikes me as useless. It basically says that the monkey is doing something,
without being specific: no issue number, nothing.
Begin forwarded message:
From: Pharo Issue Tracker do-not-re...@pharo.fogbugz.com
Subject:
On 18 Nov 2013, at 23:12, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com
wrote:
The tests pass with this hack PEGInfinityadaptToInteger: anInteger
andCompare: selector
This makes optimized inlining of timesRepeat: work.
^#( = ~= ) includes: selector
I asked Marcus for the
less noise = better
Thx!
On 19 Nov 2013, at 17:37, Camillo Bruni camillobr...@gmail.com wrote:
I think I fixed them by skipping a test.
On 2013-11-19, at 13:43, Camillo Bruni camillobr...@gmail.com wrote:
I presume one of the FogBugz API test cases does this. Though not sure.
I
On 19 Nov 2013, at 17:48, Esteban Lorenzano esteba...@gmail.com wrote:
On Nov 19, 2013, at 5:40 PM, b...@openinworld.com wrote:
So does that mean that Xtreams might go into the Pharo 3 Release as a
technology preview in parallel with the existing streams, with the aim of
replacing
