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
You guys are all too cool and we are in awe :-) As for my case, I sadly have not really had any time to play with it yet :-( Is Seaside running on 2.0? I need to do an update to a web app soon and I'd love to do it that way ... On Mar 27, 2013, at 10:33 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
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
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
2013/3/27 Johan Fabry <jfabry@dcc.uchile.cl>:
You guys are all too cool and we are in awe :-)
As for my case, I sadly have not really had any time to play with it yet :-( Is Seaside running on 2.0? I need to do an update to a web app soon and I'd love to do it that way ...
I don't have a full coverage scenario, but for what I could test yesterday it is working. Seaside-REST included. Regards, Esteban A. Maringolo
I wanted to move to 2.0, but Iliad's not loading in it (yet), so I can't use it for my real-world projects at the moment... :( 2013/3/27 Esteban A. Maringolo <emaringolo@gmail.com>
2013/3/27 Johan Fabry <jfabry@dcc.uchile.cl>:
You guys are all too cool and we are in awe :-)
As for my case, I sadly have not really had any time to play with it yet :-( Is Seaside running on 2.0? I need to do an update to a web app soon and I'd love to do it that way ...
I don't have a full coverage scenario, but for what I could test yesterday it is working. Seaside-REST included.
Regards,
Esteban A. Maringolo
-- Bernat Romagosa.
On Mar 27, 2013, at 11:01 AM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
2013/3/27 Johan Fabry <jfabry@dcc.uchile.cl>:
You guys are all too cool and we are in awe :-)
As for my case, I sadly have not really had any time to play with it yet :-( Is Seaside running on 2.0? I need to do an update to a web app soon and I'd love to do it that way ...
I don't have a full coverage scenario, but for what I could test yesterday it is working. Seaside-REST included.
Cool, that's good enough for me to give it a try! Can you point me to instructions on how you installed it? ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
2013/3/27 Johan Fabry <jfabry@dcc.uchile.cl>:
On Mar 27, 2013, at 11:01 AM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
2013/3/27 Johan Fabry <jfabry@dcc.uchile.cl>: As for my case, I sadly have not really had any time to play with it yet :-( Is Seaside running on 2.0? I need to do an update to a web app soon and I'd love to do it that way ...
I don't have a full coverage scenario, but for what I could test yesterday it is working. Seaside-REST included.
Cool, that's good enough for me to give it a try! Can you point me to instructions on how you installed it?
Sure. I used this script: https://github.com/renggli/builder/blob/master/scripts/seaside31-pharo2.st Regards!
Thanks for the link to the script Esteban. No errors was nice. I don't have the Seaside Control Panel. Is there something else I need to do to get that? Thanks, Jeff -- View this message in context: http://forum.world.st/in-anybody-out-there-who-uses-2-0-tp4678551p4680258.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Yesterday I moved my ongoing pet-project to 2.0. It feels slicker than 1.4, which is great. I was stuck because I didn't know how to properly load Seaside 3.x in 2.0, but I found a script in the Seaside mail-list. So far it works, but for some reason I can't see my categories in the browser. They are, ie: Project-Backend-Seaside Project-Backend-Websockets Project-Backend-Tests And I only see "Project" in the Browser, with a different Icon, but no class whatsoever. If I browse the class, they have the proper Category. I fixed Seaside WAExternalFileLibrary to work with the new FS, it wasn't working (relied on SpFilename and GRPlatform a lot). As a newcomer to Pharo/Squeak I have to say, it is not easy to get started... lots of respositories, versions, keybindings, etc... I know this might be ignored because I don't contribute back, but I need to say it. :-/ Once everything works it is a pleasure, though. Regards! Esteban A. Maringolo 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 am using it to develop the latest Moose 4.8 (and everyone else working on the latest Moose). Everything works fine, except for the usability issues induced by the mix of default kebindings (a new set in Nautilus, and an old set in the other tools). I am also migrating right now our in-company Moose-based tools, and these will be used in production scenarios (developers and consultants). Cheers, Doru On Wed, Mar 27, 2013 at 3:24 PM, 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
-- www.tudorgirba.com "Every thing has its own flow"
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?
As a side note I would say it happens with any major release (See Python 3 or Ruby 2 during the last months, or even PHP4/PHP5 years ago). The upgrade to anything that's not backward compatible by design, IMHO, is more a matter of confidence than features. But sooner or later they will come :) Regards! Esteban A. Maringolo
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
How to report bugs? I tried to register at http://bugs.pharo.org. But nothing happens. BTW the bug-tracker link at https://pharo.fogbugz.com/default.asp?W43 is wrong: http://www.bugs.pharo.org/ should be: http://bugs.pharo.org/ regards Nicolai
On Mar 27, 2013, at 5:58 PM, Nicolai Hess <nicolaihess@web.de> wrote:
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
How to report bugs? I tried to register at http://bugs.pharo.org. But nothing happens.
BTW the bug-tracker link at https://pharo.fogbugz.com/default.asp?W43 is wrong: http://www.bugs.pharo.org/ should be: http://bugs.pharo.org/
Fixed, Thanks! Marcus
there is a bug about the registration and names with dots (my.name@someplace.st)... it will be fixed soon, sorry for the inconvenience. Esteban On Mar 27, 2013, at 5:58 PM, Nicolai Hess <nicolaihess@web.de> wrote:
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
How to report bugs? I tried to register at http://bugs.pharo.org. But nothing happens.
BTW the bug-tracker link at https://pharo.fogbugz.com/default.asp?W43 is wrong: http://www.bugs.pharo.org/ should be: http://bugs.pharo.org/
regards Nicolai
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
I normally wait a few weeks after a release before having a bit of a look myself. I did try loading Seaside in it and it complained about OmniBrowser, and then tried Gitocello and that didn't load either. I guess it's only natural that people take some time to update their projects to a new version but given how key Seaside is to Pharo, I think that needs to work out of the box (I'm sure it does with the right version to be fair but was just pretending to be a newbie and using the configuration browser) Nautilus is going to be a bit of a learning curve for me as well. My automatic typing into that top box on 1.4 is going to take some overcoming!
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
O tried it, it works pretty well overall, just a bit sluggish in the UI side of things, also some issued with editing code and then moving between characters and words in code, sometimes the cursor just to unexpected places, like the beginning of the file, for some reason... going to try to keep an eye on it and see if I can come up with a more reproducible description. Thanks for all the hard work, as I said, in general pretty solid. Victor Stan Schedule me: http://quicklyschedule.quicklyschedule.me/victor Add me to your address book - it's easy! http://contactmonkey.com/victor On Wed, Mar 27, 2013 at 3:54 PM, Chris <cpmbailey@btinternet.com> wrote:
I normally wait a few weeks after a release before having a bit of a look myself. I did try loading Seaside in it and it complained about OmniBrowser, and then tried Gitocello and that didn't load either. I guess it's only natural that people take some time to update their projects to a new version but given how key Seaside is to Pharo, I think that needs to work out of the box (I'm sure it does with the right version to be fair but was just pretending to be a newbie and using the configuration browser)
Nautilus is going to be a bit of a learning curve for me as well. My automatic typing into that top box on 1.4 is going to take some overcoming!
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
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?
which os do you use? 2013/3/28 Yanni Chiu <yanni@rogers.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
On 28/03/13 3:11 AM, Marcus Denker wrote:
On Mar 28, 2013, at 4:56 AM, Yanni Chiu <yanni-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> wrote:
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.
After some more usage I'll pinpoint where it's happening, since it interrupts the train of thought otherwise.
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?
The TestRunner was sluggish when selecting test cases. This was the case in Pharo-1.4 too, but a little worse in Pharo-2.0. I had some tests that caused the UI to stop responding (had to kill the image, but the image's cpu usage was normal). Once the test cases passed, I've not seen the problem again. The main problem is that if I see a test failure in the TestRunner. Then when I try to browse that test case, the actual test code is in a superclass. But, it's unclear how to invoke that test case for the subclass through Nautilus, and it's not clear where the test result is shown in Nautilus (i.e. where is the green icon when the actual test method is in the superclass).
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?
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?
2013/3/28 Yanni Chiu <yanni@rogers.com>
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.
For me some clicks are counted double (or wrong).
From the welcome-workspace hightlight MetacelloConfigurationBrowser open. and use the Mouse and context-menu for "do it". It opens the configuration browser, but it reopens the menu as well. The same happens for other mouse interactions as well. Open a Browser. Click on the codepane, open context menu, use left-mouse button in another browser pane -> the context menu closes and reopens again at the new mouse position.
Nicolai
Le 27/03/2013 15:24, Esteban Lorenzano a écrit :
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, I've started to load things in 2.0 (SmaCC, some of my current work) but then the current work caught me back and I'm finishing it on 1.4 at the moment. Oh, I think I also stopped because I couldn't load FileTree in 2.0 and I need it for a git-based workflow. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I am developing MathsOntologie under Pharo 2.0 beta, and testing it under Pharo 1.4; when the test is OK I distribute MathsOntologie with Pharo 1.4 as "all in one". Don't know if it is the best way to do but I became used to it... By the way, I am ashamed that I never made a unit test... Also, when I wanted to translate in French the method "add: anObject times: aNumber" to a Collection, I found that it didn't work, so I created it with something like Collection>add: anObject times: aNumber aNumber timesRepeat: [self add: anObject]. I don't know if it was intended or a bug, and and did not find it very difficult to create this method but I asked myself why this method did not work. And I could not test it afterwards because I could not update Pharo 2.0 beta (conflicts between consecutive updates); I have to download Pharo 2.0 and transfer MathsOntologie inside the new version; I just did not have the time... Alain On Thu, Mar 28, 2013 at 12:34 PM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Le 27/03/2013 15:24, Esteban Lorenzano a écrit :
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,
I've started to load things in 2.0 (SmaCC, some of my current work) but then the current work caught me back and I'm finishing it on 1.4 at the moment.
Oh, I think I also stopped because I couldn't load FileTree in 2.0 and I need it for a git-based workflow.
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Hello alain
I am developing MathsOntologie under Pharo 2.0 beta, and testing it under Pharo 1.4; when the test is OK I distribute MathsOntologie with Pharo 1.4 as "all in one". Don't know if it is the best way to do but I became used to itâ¦
Why not under 20? I would stick with the latest version since 1.4 is one year old.
By the way, I am ashamed that I never made a unit testâ¦
Just start :) this is easy.
Also, when I wanted to translate in French the method "add: anObject times: aNumber" to a Collection, I found that it didn't work,
what did not work?
so I created it with something like
Collection>add: anObject times: aNumber aNumber timesRepeat: [self add: anObject].
may be to be consistent with add:
Collection>add: anObject times: aNumber aNumber timesRepeat: [self add: anObject]. ^ anObject
I don't know if it was intended or a bug, and and did not find it very difficult to create this method but I asked myself why this method did not work. And I could not test it afterwards because I could not update Pharo 2.0 beta (conflicts between consecutive updates); I have to download Pharo 2.0 and transfer MathsOntologie inside the new version; I just did not have the timeâ¦
What you should always make sure is that you can rebuild your system everyday. This will make your life easier. What kind of problems did you encounter? Stef
Alain
On Thu, Mar 28, 2013 at 12:34 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote: Le 27/03/2013 15:24, Esteban Lorenzano a écrit :
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,
I've started to load things in 2.0 (SmaCC, some of my current work) but then the current work caught me back and I'm finishing it on 1.4 at the moment.
Oh, I think I also stopped because I couldn't load FileTree in 2.0 and I need it for a git-based workflow.
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 27 March 2013 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?
I know you must be starving for feedback on Pharo 2.0, so here is mine. I ported my app to it, from Pharo 1.4. The app uses Glorp, Seaside, RFB and HPDF, so it took me an afternoon. The overall impression is great. Unlike 1.4, it didn't crash a single time. Another great thing is that you didn't make that many backward incompatible changes as I though you would. Of course, I had to patch almost all of the above (their dependencies include FFI, OpenDBX etc.) and rewrite some little bits of my code, but it was worth it. The new FS classes are must better.
From user's point of view there is no much difference to 1.4, which is a good thing. I know you revamped things internally.
Keep the good work, and I hope I will be able to provide you with feedback from real production environment soon. -- Milan Mimica http://sparklet.sf.net
Hi Milan, On 07 Apr 2013, at 08:43, Milan Mimica <milan.mimica@gmail.com> wrote:
On 27 March 2013 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?
I know you must be starving for feedback on Pharo 2.0, so here is mine.
I ported my app to it, from Pharo 1.4. The app uses Glorp, Seaside, RFB and HPDF, so it took me an afternoon. The overall impression is great. Unlike 1.4, it didn't crash a single time. Another great thing is that you didn't make that many backward incompatible changes as I though you would. Of course, I had to patch almost all of the above (their dependencies include FFI, OpenDBX etc.) and rewrite some little bits of my code, but it was worth it. The new FS classes are must better. From user's point of view there is no much difference to 1.4, which is a good thing. I know you revamped things internally.
Keep the good work, and I hope I will be able to provide you with feedback from real production environment soon.
That is really great to hear. Thanks! Sounds like an impressive application that you got there. We value success stories and/or great use cases a lot, when you are ready. Sven
-- Milan Mimica http://sparklet.sf.net
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
this really cool, thanks! btw... if you needed to update configurations... could you commit the new configurations to the repository for Pharo2.0? thanks, Esteban On Apr 7, 2013, at 8:43 AM, Milan Mimica <milan.mimica@gmail.com> wrote:
On 27 March 2013 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?
I know you must be starving for feedback on Pharo 2.0, so here is mine.
I ported my app to it, from Pharo 1.4. The app uses Glorp, Seaside, RFB and HPDF, so it took me an afternoon. The overall impression is great. Unlike 1.4, it didn't crash a single time. Another great thing is that you didn't make that many backward incompatible changes as I though you would. Of course, I had to patch almost all of the above (their dependencies include FFI, OpenDBX etc.) and rewrite some little bits of my code, but it was worth it. The new FS classes are must better. From user's point of view there is no much difference to 1.4, which is a good thing. I know you revamped things internally.
Keep the good work, and I hope I will be able to provide you with feedback from real production environment soon.
-- Milan Mimica http://sparklet.sf.net
The only configuration I changed was ConfigurationOfGlorpDBX, it was trivial, just to make it load. I added spec for: #'pharo2.x' version: '2.5'. to ConfigurationOfGlorpDBX >> stable: Some tests failed, but AFAIR, they also failed on 1.4. Other changes include fixing Seaside's WAImageStatus, which was also trivial but has been broken for ages. Not sure how to push these changes, especially because these are only for Pharo2.0. On 7 April 2013 11:47, Esteban Lorenzano <estebanlm@gmail.com> wrote:
this really cool, thanks!
btw... if you needed to update configurations... could you commit the new configurations to the repository for Pharo2.0?
thanks, Esteban
On Apr 7, 2013, at 8:43 AM, Milan Mimica <milan.mimica@gmail.com> wrote:
On 27 March 2013 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?
I know you must be starving for feedback on Pharo 2.0, so here is mine.
I ported my app to it, from Pharo 1.4. The app uses Glorp, Seaside, RFB and HPDF, so it took me an afternoon. The overall impression is great. Unlike 1.4, it didn't crash a single time. Another great thing is that you didn't make that many backward incompatible changes as I though you would. Of course, I had to patch almost all of the above (their dependencies include FFI, OpenDBX etc.) and rewrite some little bits of my code, but it was worth it. The new FS classes are must better. From user's point of view there is no much difference to 1.4, which is a good thing. I know you revamped things internally.
Keep the good work, and I hope I will be able to provide you with feedback from real production environment soon.
-- Milan Mimica http://sparklet.sf.net
-- Milan Mimica http://sparklet.sf.net
I think that you should publish the change for DBX in the DBX repo and the metaRepoForPharo20. Stef On Apr 7, 2013, at 4:47 PM, Milan Mimica <milan.mimica@gmail.com> wrote:
The only configuration I changed was ConfigurationOfGlorpDBX, it was trivial, just to make it load. I added spec for: #'pharo2.x' version: '2.5'. to ConfigurationOfGlorpDBX >> stable: Some tests failed, but AFAIR, they also failed on 1.4.
Other changes include fixing Seaside's WAImageStatus, which was also trivial but has been broken for ages. Not sure how to push these changes, especially because these are only for Pharo2.0.
On 7 April 2013 11:47, Esteban Lorenzano <estebanlm@gmail.com> wrote: this really cool, thanks!
btw... if you needed to update configurations... could you commit the new configurations to the repository for Pharo2.0?
thanks, Esteban
On Apr 7, 2013, at 8:43 AM, Milan Mimica <milan.mimica@gmail.com> wrote:
On 27 March 2013 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?
I know you must be starving for feedback on Pharo 2.0, so here is mine.
I ported my app to it, from Pharo 1.4. The app uses Glorp, Seaside, RFB and HPDF, so it took me an afternoon. The overall impression is great. Unlike 1.4, it didn't crash a single time. Another great thing is that you didn't make that many backward incompatible changes as I though you would. Of course, I had to patch almost all of the above (their dependencies include FFI, OpenDBX etc.) and rewrite some little bits of my code, but it was worth it. The new FS classes are must better. From user's point of view there is no much difference to 1.4, which is a good thing. I know you revamped things internally.
Keep the good work, and I hope I will be able to provide you with feedback from real production environment soon.
-- Milan Mimica http://sparklet.sf.net
-- Milan Mimica http://sparklet.sf.net
thanks for the feedback We would like to migrate all the libraries we all use to SmalltalkHub and start to have a process so that we can validate the project. So if people want to help you are welcome. Stef On Apr 7, 2013, at 8:43 AM, Milan Mimica <milan.mimica@gmail.com> wrote:
On 27 March 2013 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?
I know you must be starving for feedback on Pharo 2.0, so here is mine.
I ported my app to it, from Pharo 1.4. The app uses Glorp, Seaside, RFB and HPDF, so it took me an afternoon. The overall impression is great. Unlike 1.4, it didn't crash a single time. Another great thing is that you didn't make that many backward incompatible changes as I though you would. Of course, I had to patch almost all of the above (their dependencies include FFI, OpenDBX etc.) and rewrite some little bits of my code, but it was worth it. The new FS classes are must better. From user's point of view there is no much difference to 1.4, which is a good thing. I know you revamped things internally.
Keep the good work, and I hope I will be able to provide you with feedback from real production environment soon.
-- Milan Mimica http://sparklet.sf.net
participants (18)
-
Alain Busser -
Bernat Romagosa -
Chris -
Esteban A. Maringolo -
Esteban Lorenzano -
Goubier Thierry -
Jeff Gray -
Johan Fabry -
Marcus Denker -
Milan Mimica -
Nicolai Hess -
Norbert Hartl -
smalltalk -
stephane ducasse -
Sven Van Caekenberghe -
Tudor Girba -
Victor Stan -
Yanni Chiu