WAVirtualMachineStatus>>#renderValuesOn:

Another trivial fix for Pharo 3:

In WAVirtualMachineStatus>>#renderValuesOn: the modules lists should be asked using self image vm not self image.

This not an incompatibility between Pharo 2 and 3. Instead of creating a new package, it could also be fixed with a little dynamic hack.

Sven_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hey Sven,

Thank you!

I’m currently building unit tests using Parasol for all the Seaside functional tests. That will help us also detect problems in the web tools.

Johan

On 16 Feb 2014, at 14:07, Sven Van Caekenberghe <[hidden email]> wrote:

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 16 Feb 2014, at 14:17, Johan Brichau <[hidden email]> wrote:

> I’m currently building unit tests using Parasol for all the Seaside functional tests. That will help us also detect problems in the web tools.

Yeah, automated functional tests would be super cool !_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 16 Feb 2014, at 14:38, Johan Brichau <[hidden email]> wrote:

> On 16 Feb 2014, at 14:07, Sven Van Caekenberghe <[hidden email]> wrote:
>
>> This not an incompatibility between Pharo 2 and 3. Instead of creating a new package, it could also be fixed with a little dynamic hack.

The above sentence was wrong: it should read 'This is not compatible...'

> Though I’m always amazed that deprecated methods immediately break things in Pharo.
> They’re supposed to keep working until the next version, but the ‘raise a blocking dialog’ setting that is on by default in Pharo makes it break immediately.

Yes and no: if we would not raise a hard warning, nobody would adjust their code ;-)

One hack is:

[ ... ]
  on: Deprecation
  do: [ :notification | notification resume ].

But then the code will break in Pharo 4. What I meant was more something like:

[ self image listBuiltinModules ]
  on: Deprecation, MessageNotUnderstood
  do: [ self image vm listBuiltinModules ].

But it is still a hack.

> Johan
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Sun, Feb 16, 2014 at 2:38 PM, Johan Brichau <[hidden email]> wrote:
Well we can fix that [1]

 [1] http://code.google.com/p/seaside/issues/detail?id=781

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 16 Feb 2014, at 23:20, Philippe Marschall <[hidden email]> wrote:

there is also a setting in Pharo to disable the blocking dialog.

Deprecation raiseWarning: false.

Esteban

>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 17 Feb 2014, at 09:53, Esteban Lorenzano <[hidden email]> wrote:

> there is also a setting in Pharo to disable the blocking dialog.
>
> Deprecation raiseWarning: false.

We know.
It's just that nobody disables it, so everyone gets errors instead of deprecation warnings.

Johan_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

yeah… that’s kinda annoying… warnings should never be blocking.
but that’s the way they always worked in pharo and I think before too… I would be willing to change that behaviour (for pharo4, we are too close to a release now), if we came up with an idea :)

Esteban

On 17 Feb 2014, at 09:54, Johan Brichau <[hidden email]> wrote:

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev