Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

> On 9 Aug 2016, at 00:03, Nicolai Hess wrote: > > > > 2016-08-08 17:35 GMT+02:00 Max Leske >: > >> On 8 Aug 2016, at 17:15, Nicolai Hess > > wrote: >> >> >> >>

Re: [Pharo-dev] Out of ideas...

Hi, have you try with (World>>Help>>Help Browser>>Regular Expressions Framework>>Usage) SUBEXPRESSION MATCHES After a successful match attempt, you can query the specifics of which part of the original string has matched which part of the whole expression. A subexpression is a parenthesized

[Pharo-dev] Out of ideas...

If someone can help me... I'm dealing with the following situation: I may have a string in which matches of the following regex: '[\s.;\:!?]*#\w+' may happen (multiple times). I want to replace the #\w+ part of it by nothing but keep the [\s.;\:!?]* but it seems to be no easy way using

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

2016-08-08 17:35 GMT+02:00 Max Leske : > > On 8 Aug 2016, at 17:15, Nicolai Hess wrote: > > > > 2016-08-08 15:26 GMT+02:00 Max Leske : > >> >> On 8 Aug 2016, at 15:00, Dale Henrichs >> wrote: >> >>

Re: [Pharo-dev] GT-Spotter dive in shortcut

2016-08-07 22:59 GMT+02:00 Tudor Girba : > Hi, > > > On Aug 7, 2016, at 9:15 PM, Nicolai Hess wrote: > > > > > > > > 2016-08-07 19:58 GMT+02:00 Tudor Girba : > > > > > On Aug 7, 2016, at 6:24 PM, Nicolai Hess

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60173 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 4f6532: 60173

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 4f65322e02872435ab25321bfe399c0c5fd166ba https://github.com/pharo-project/pharo-core/commit/4f65322e02872435ab25321bfe399c0c5fd166ba Author: Jenkins Build Server Date:

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

Hi Ben, Sorry, I do not have yet a verdict. The part of the system that reproduces the crash is not used frequently so it takes me quite some time to reproduce it :( Will keep you informed if I see it again or not with the last changes. Thanks for checking with me. On Mon, Aug 8, 2016 at

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60172 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 922d2d: 60172

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 922d2dc6370262484a8c725129e2ae39b5cb2d0c https://github.com/pharo-project/pharo-core/commit/922d2dc6370262484a8c725129e2ae39b5cb2d0c Author: Jenkins Build Server Date:

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

Hi Mariano, How are you going with this problem? On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck wrote: > > > On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman wrote: >> >> >> >> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck >>

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

> On 8 Aug 2016, at 17:15, Nicolai Hess wrote: > > > > 2016-08-08 15:26 GMT+02:00 Max Leske >: > >> On 8 Aug 2016, at 15:00, Dale Henrichs > >

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

2016-08-08 15:26 GMT+02:00 Max Leske : > > On 8 Aug 2016, at 15:00, Dale Henrichs > wrote: > > Max, > > Thanks for looking into this. > > Do you think that this bug will be fixed in Pharo5.0? When I'm debugging > the tests with this fatal

[Pharo-dev] using glorp and active record

Hi, I have been trying to get glorp using active record working in pharo 5. I have a descriptor class for it and the classes inherit from active Record. I describe the table as: tableForAnswer: aTable | vistorId questionId | (aTable createFieldNamed: 'id' type: platform serial) bePrimaryKey.

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

> On 8 Aug 2016, at 15:00, Dale Henrichs > wrote: > > Max, > > Thanks for looking into this. > > Do you think that this bug will be fixed in Pharo5.0? When I'm debugging the > tests with this fatal pattern, my only recourse is to start and stop images >

Re: [Pharo-dev] another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

For the record, I do also continue to see this crash in Pharo 5.0 with it's stable VM. But as Esteban said, it's too random that I don't have more info to share :( On Mon, Aug 8, 2016 at 6:39 AM, Esteban Lorenzano wrote: > damn :( > FreeType bug strikes again… :(( > > to

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

Max, Thanks for looking into this. Do you think that this bug will be fixed in Pharo5.0? When I'm debugging the tests with this fatal pattern, my only recourse is to start and stop images between test runs ... The side effect of not running ensure blocks in tests is that a SharedQueue gets

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

+1 > On 08 Aug 2016, at 11:31, Nicolas Passerini wrote: > > Hi, > > I think that whatever default behavior and shortcuts you decide, it would be > nice to be able to configure it. So, if someone does not feel comfortable > with the default, he has a simple way to

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

+1 On 8/8/16 2:31 AM, Nicolas Passerini wrote: Hi, I think that whatever default behavior and shortcuts you decide, it would be nice to be able to configure it. So, if someone does not feel comfortable with the default, he has a simple way to change it and configure in a way that gets

Re: [Pharo-dev] another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

damn :( FreeType bug strikes again… :(( to be honest, I’m playing with the idea to completely replace it with a UFFI version. I cannot find why/how this happens… in some conditions handle become invalid and pharo has no idea pointer is not valid any more… then crash. Double free was what I

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

Hi, I think that whatever default behavior and shortcuts you decide, it would be nice to be able to configure it. So, if someone does not feel comfortable with the default, he has a simple way to change it and configure in a way that gets better along with his way of using Pharo. Don't you think?

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60171 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] e91f1f: 60171

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e91f1f1217b56f2418bd81f5c65f1febfc0d14da https://github.com/pharo-project/pharo-core/commit/e91f1f1217b56f2418bd81f5c65f1febfc0d14da Author: Jenkins Build Server Date:

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

Thanks Nicolai. I’ve opened an issue on phogbugz: https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed . > On 8 Aug 2016, at 09:03, Nicolai Hess

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

2016-08-08 8:52 GMT+02:00 Max Leske : > Wow, that’s pretty bad. The process termination logic should be taking > care of the ensure blocks. Unfortunately I can’t run any Pharo images at > the moment but if there’s something wrong with process termination then > it’s likely

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

Wow, that’s pretty bad. The process termination logic should be taking care of the ensure blocks. Unfortunately I can’t run any Pharo images at the moment but if there’s something wrong with process termination then it’s likely that me or Ben made some mistake. Could someone please rerun Dale’s