Why do we get [...] when Opal is not active? Why can't we keep the old behavior? Thanks, Sean ----- Cheers, Sean -- View this message in context: http://forum.world.st/Block-Printing-in-3-0-tp4693116.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 13 Jun 2013, at 14:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Why do we get [...] when Opal is not active? Why can't we keep the old behavior?
Thanks, Sean
I understood it was either/or - there is an issue somewhere. And Opal will be enabled by default in 3.0 anyway. Sven
On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Why do we get [...] when Opal is not active? Why can't we keep the old behavior?
Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-) We where a bit distracted last week so there was no progress on those⦠soon. Marcus
On Jun 13, 2013, at 2:48 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Why do we get [...] when Opal is not active? Why can't we keep the old behavior?
Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-) We where a bit distracted last week so there was no progress on those⦠soon.
Blocks are now pretty-printed again. In addition, the new bytecode->AST->source mapping is active, this should speed up the Debugger a bit and should fix some long standing highlighting bugs. (But due to the inherent complexity of the whole thing, it fire sure will have some problems, we will see. The good thing is that problems should be easy to debug due to the explicit AST/IR based mapping) Marcus
On 19 Jun 2013, at 08:52, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jun 13, 2013, at 2:48 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Why do we get [...] when Opal is not active? Why can't we keep the old behavior?
Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-) We where a bit distracted last week so there was no progress on those⦠soon.
Blocks are now pretty-printed again.
In addition, the new bytecode->AST->source mapping is active, this should speed up the Debugger a bit and should fix some long standing highlighting bugs.
(But due to the inherent complexity of the whole thing, it fire sure will have some problems, we will see. The good thing is that problems should be easy to debug due to the explicit AST/IR based mapping)
Marcus
Yes, for end users, improving the debugger based on Opal should be the next step. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On Wed, Jun 19, 2013 at 9:35 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, for end users, improving the debugger based on Opal should be the next step.
when do we activate the new debugger by default? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
2013/6/19 Damien Cassou <damien.cassou@gmail.com>
On Wed, Jun 19, 2013 at 9:35 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, for end users, improving the debugger based on Opal should be the next step.
when do we activate the new debugger by default?
We cannot activate both Opal and the new debugger at the same time or we will not know from which of the 2 the highlighting / temp names bugs come from. So in at least a month. Moreover, the new debugger relies also on the new inspectors. So first the new inspectors should be activated by default (I will do that with Camillo in a few days / weeks), then 1 month after the new debugger can be activated.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Asc*
On Jun 19, 2013, at 9:58 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Wed, Jun 19, 2013 at 9:35 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, for end users, improving the debugger based on Opal should be the next step.
when do we activate the new debugger by default?
We really need to take care to not enable too many things at once. For the Debugger, the next step is to enable by default the new Inspector implementation⦠Marcus
On Jun 19, 2013, at 9:35 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Jun 2013, at 08:52, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jun 13, 2013, at 2:48 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Why do we get [...] when Opal is not active? Why can't we keep the old behavior?
Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-) We where a bit distracted last week so there was no progress on those⦠soon.
Blocks are now pretty-printed again.
In addition, the new bytecode->AST->source mapping is active, this should speed up the Debugger a bit and should fix some long standing highlighting bugs.
(But due to the inherent complexity of the whole thing, it fire sure will have some problems, we will see. The good thing is that problems should be easy to debug due to the explicit AST/IR based mapping)
Marcus
Yes, for end users, improving the debugger based on Opal should be the next step.
So what we already have is a first step towards "per AST Node" break/watch/inspect points. Together with the new debugger implementation and the new editor this will allow some quite fancy debugger improvements. Marcus
participants (5)
-
Clément Bera -
Damien Cassou -
Marcus Denker -
Sean P. DeNigris -
Sven Van Caekenberghe