[Pharo-project] in anybody out there? who uses 2.0?
Hi, Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it? Cheers, Esteban
Hi, On 27 Mar 2013, at 15:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it?
Cheers, Esteban
Of course there are still (mostly undiscovered) bugs, but overall I find 2.0 really solid. I really think that all the hard work in the last couple of months/weeks did pay off. Thanks ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
As far as I am concerned, I report what I do find. But needing to put bread on the table, I can do that a few days a week. More to expect as I started the development of a seaside-rest / amber app (getting inspiration from STH). Other than that, the system looks like okay from a usage perspective. Phil 2013/3/27 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it?
Cheers, Esteban
I use 2.0 for development of FileSystem-Git and Fuel but it will be quite a while before we'll have a critical application working on 2.0, so in that respect: no we don't use 2.0 in production. Max On 27.03.2013, at 15:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it?
Cheers, Esteban
I don't use it yet. But you can bet you'll hear about it:D Let things come to you and keep the great work. sebastian o/ On Mar 27, 2013, at 11:24 AM, Esteban Lorenzano wrote:
Hi,
Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it?
Cheers, Esteban
Am 27.03.2013 um 15:24 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it?
Most of my stuff is still on 1.4. As there is no big reason to move, I don't move because it takes time I can't spend at the moment. It will take some time to get used to the new environment, too. That means I need to figure out how to reestablish most of the 1.4 behavior (keyboard shortcuts, etc..) first. I will move on a project by project basis to 2.0 and for the time I need to work in a mixed environment I'm not ready to use two different UI/keyboard/mouse/whatever systems. So mimicking 1.4 behavior in 2.0 is first and getting used to the new ways comes after. Getting used to new things does not include keyboard shortcuts. I don't like them and I fear the day the support for 1.x shortcuts will be treated as legacy burden. It's just that there are people that hate emacs and everything that is like it :) But I'm in progress to move a project to 2.0. We'll see! Norbert
EstebanLM wrote
So... I wonder... is that because we made a really cool release, or just because nobody is using it?
I've ported most of my projects to 2.0, but I've been on holidays for a few weeks, so I haven't updated to the released version. I'll know better this week, but IIRC most of the bugs I noticed have been fixed. ----- Cheers, Sean -- View this message in context: http://forum.world.st/in-anybody-out-there-who-uses-2-0-tp4678552p4678640.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Did anybody manage to load Magritte 2 at least? When running this: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagritte2'; load. (ConfigurationOfMagritte2 project version: '2.0.6') load: #('Magritte-Seaside') I get the following error: This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: magritteDynamicObject Esteban A. Maringolo 2013/3/27 Sean P. DeNigris <sean@clipperadams.com>:
EstebanLM wrote
So... I wonder... is that because we made a really cool release, or just because nobody is using it?
I've ported most of my projects to 2.0, but I've been on holidays for a few weeks, so I haven't updated to the released version. I'll know better this week, but IIRC most of the bugs I noticed have been fixed.
----- Cheers, Sean -- View this message in context: http://forum.world.st/in-anybody-out-there-who-uses-2-0-tp4678552p4678640.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Magritte2 is a bit old. Magritte3 loads fine (we are using it in Moose). Doru On Mar 28, 2013, at 3:11 AM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
Did anybody manage to load Magritte 2 at least?
When running this: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagritte2'; load.
(ConfigurationOfMagritte2 project version: '2.0.6') load: #('Magritte-Seaside')
I get the following error: This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: magritteDynamicObject
Esteban A. Maringolo
2013/3/27 Sean P. DeNigris <sean@clipperadams.com>:
EstebanLM wrote
So... I wonder... is that because we made a really cool release, or just because nobody is using it?
I've ported most of my projects to 2.0, but I've been on holidays for a few weeks, so I haven't updated to the released version. I'll know better this week, but IIRC most of the bugs I noticed have been fixed.
----- Cheers, Sean -- View this message in context: http://forum.world.st/in-anybody-out-there-who-uses-2-0-tp4678552p4678640.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- www.tudorgirba.com "What we can governs what we wish."
Any hints on how to load the Magritte-Seaside package? Regards, Esteban A. Maringolo 2013/3/28 Tudor Girba <tudor@tudorgirba.com>:
Magritte2 is a bit old. Magritte3 loads fine (we are using it in Moose).
Doru
On Mar 28, 2013, at 3:11 AM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
Did anybody manage to load Magritte 2 at least?
When running this: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagritte2'; load.
(ConfigurationOfMagritte2 project version: '2.0.6') load: #('Magritte-Seaside')
I get the following error: This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: magritteDynamicObject
Esteban A. Maringolo
2013/3/27 Sean P. DeNigris <sean@clipperadams.com>:
EstebanLM wrote
So... I wonder... is that because we made a really cool release, or just because nobody is using it?
I've ported most of my projects to 2.0, but I've been on holidays for a few weeks, so I haven't updated to the released version. I'll know better this week, but IIRC most of the bugs I noticed have been fixed.
----- Cheers, Sean -- View this message in context: http://forum.world.st/in-anybody-out-there-who-uses-2-0-tp4678552p4678640.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- www.tudorgirba.com
"What we can governs what we wish."
Yep, seems BlockContext is gone. Ran into that as well. No idea on how to fix tough. Throwing in BlockClosure instead makes me feel like playing russian roulette. Maybe Lukas repository has updates (as for Seaside) Phil 2013/3/28 Esteban A. Maringolo <emaringolo@gmail.com>:
Did anybody manage to load Magritte 2 at least?
When running this: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagritte2'; load.
(ConfigurationOfMagritte2 project version: '2.0.6') load: #('Magritte-Seaside')
I get the following error: This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: magritteDynamicObject
Esteban A. Maringolo
2013/3/27 Sean P. DeNigris <sean@clipperadams.com>:
EstebanLM wrote
So... I wonder... is that because we made a really cool release, or just because nobody is using it?
I've ported most of my projects to 2.0, but I've been on holidays for a few weeks, so I haven't updated to the released version. I'll know better this week, but IIRC most of the bugs I noticed have been fixed.
----- Cheers, Sean -- View this message in context: http://forum.world.st/in-anybody-out-there-who-uses-2-0-tp4678552p4678640.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 27/03/13 10:24 AM, Esteban Lorenzano wrote:
Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it?
Just before the release I loaded up my project, and did a quick check to find that everything looked fine - except that I would have to migrate to Fuel-1.9. I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4. The slowness is not just an annoyance, because I actually compile code in my application - it's just compiling getters and setters. I've not got enough working yet to see whether it's going to adversely affect the usability (it could make startup time too slow). Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost. The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner. Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: Deprecation raiseWarning: false. Deprecation showWarning: false. so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure. Are these bugs, or just me getting used to the new release?
On Mar 28, 2013, at 4:56 AM, Yanni Chiu <yanni@rogers.com> wrote:
I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4.
Yes, this is known and we should analyze it⦠one thing we need to get rid of os the #become: when updating the source pointer. There seems to be something slow with announcing changes, too.
Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost.
I have not seen that one.
The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner.
Odd in which sense? related to the progress bar?
Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: Deprecation raiseWarning: false. Deprecation showWarning: false. so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure.
Can you add a bug tracker entry for that one? Marcus
we should plit that in bug entries and take actions collectively :) On Mar 28, 2013, at 4:56 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 27/03/13 10:24 AM, Esteban Lorenzano wrote:
Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... So... I wonder... is that because we made a really cool release, or just because nobody is using it?
Just before the release I loaded up my project, and did a quick check to find that everything looked fine - except that I would have to migrate to Fuel-1.9.
I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4.
The slowness is not just an annoyance, because I actually compile code in my application - it's just compiling getters and setters. I've not got enough working yet to see whether it's going to adversely affect the usability (it could make startup time too slow).
Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost.
The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner.
Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: Deprecation raiseWarning: false. Deprecation showWarning: false. so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure.
Are these bugs, or just me getting used to the new release?
participants (12)
-
Esteban A. Maringolo -
Esteban Lorenzano -
Marcus Denker -
Max Leske -
Norbert Hartl -
phil＠highoctane.be -
Sean P. DeNigris -
Sebastian Sastre -
stephane ducasse -
Sven Van Caekenberghe -
Tudor Girba -
Yanni Chiu