[Pharo-project] start thinking on summer release of Pharo 1.4
Hi, I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click: - pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser. - pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;) So far, this and the bugfixes we already made (and some more)... What do you think? Esteban
On 13 Jun 2012, at 11:08, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
+ 1
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;)
+ 1
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
Would it be hard to also preload Nautilus, as a preview ? Many people, including myself, really like Nautilus a lot. And it deserves it. The counter indication would be if this would make life harder on Benjamin. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Esteban, Definitely worth doing!!! Install all the stuff I need on new images etc just to the have to discard them for some reason doesn't makes me reinstall anything afterwards. Tried to work the way of Mariano with the "ConfigurationOfXXXX" but frankly, let it fall by the wayside. Just too many problems with loading packages that do work well together etc. And no refactoring out of the box in 1.4 is really lame indeed. As for Nautilus in 2.0, the regular yellow crosses on red background are getting on my nerves, especially since I don't know why they do appear.$ So, yeah: +100000000 Philippe 2012/6/13 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;)
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
-- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
On Jun 13, 2012, at 6:23 AM, phil@highoctane.be wrote:
Esteban,
Definitely worth doing!!!
Install all the stuff I need on new images etc just to the have to discard them for some reason doesn't makes me reinstall anything afterwards.
Tried to work the way of Mariano with the "ConfigurationOfXXXX" but frankly, let it fall by the wayside.
Just too many problems with loading packages that do work well together etc.
And no refactoring out of the box in 1.4 is really lame indeed. As for Nautilus in 2.0, the regular yellow crosses on red background are getting on my nerves, especially since I don't know why they do appear.$
Did you open bug entries ? Send a mail ? Did something ? Ben
So, yeah: +100000000
Philippe
2012/6/13 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;)
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
-- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
My gripe is not so much that configs don't work together, it's that they work (very) differently over time; the work I did "last week" to build an image could be (often is) worthless "today." Configs really need to reflect on versions and do the right thing vs. current complexity. If pre-loading, how about FFI? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Wednesday, June 13, 2012 6:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Esteban, Definitely worth doing!!! Install all the stuff I need on new images etc just to the have to discard them for some reason doesn't makes me reinstall anything afterwards. Tried to work the way of Mariano with the "ConfigurationOfXXXX" but frankly, let it fall by the wayside. Just too many problems with loading packages that do work well together etc. And no refactoring out of the box in 1.4 is really lame indeed. As for Nautilus in 2.0, the regular yellow crosses on red background are getting on my nerves, especially since I don't know why they do appear.$ So, yeah: +100000000 Philippe 2012/6/13 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;)
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
-- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
FFI yes, useful as well. 2012/6/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
My gripe is not so much that configs don't work together, it's that they work (very) differently over time; the work I did "last week" to build an image could be (often is) worthless "today." Â Configs really need to reflect on versions and do the right thing vs. current complexity. Â If pre-loading, how about FFI?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Wednesday, June 13, 2012 6:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Esteban,
Definitely worth doing!!!
Install all the stuff I need on new images etc just to the have to discard them for some reason doesn't makes me reinstall anything afterwards.
Tried to work the way of Mariano with the "ConfigurationOfXXXX" but frankly, let it fall by the wayside.
Just too many problems with loading packages that do work well together etc.
And no refactoring out of the box in 1.4 is really lame indeed. As for Nautilus in 2.0, the regular yellow crosses on red background are getting on my nerves, especially since I don't know why they do appear.$
So, yeah: +100000000
Philippe
2012/6/13 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;)
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
-- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Schwab,Wilhelm K wrote
My gripe is... that configs... work (very) differently over time
With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now. The only hill to climb now is getting the word out about Metacello conventions/best practices. Schwab,Wilhelm K wrote
If pre-loading, how about FFI?
I think "easily loadable" is the correct state, not included by default. -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now. If we can't do that, the config browser is pretty much a dream vs. reality. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Friday, June 15, 2012 2:49 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Schwab,Wilhelm K wrote
My gripe is... that configs... work (very) differently over time
With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now. The only hill to climb now is getting the word out about Metacello conventions/best practices. Schwab,Wilhelm K wrote
If pre-loading, how about FFI?
I think "easily loadable" is the correct state, not included by default. -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Schwab,Wilhelm K wrote
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now.
Absolutely! Two things about that: * Metacello has no magic. Ultimately, what you correctly suggest requires someone to test a project on a new platform and update the config... coming soon and desperately needed: tools to help this process... * we're all learning how to use Metacello... even as it evolves underneath us! If you experience something other than above, please post the specific example so we can examine the configs and see what's going on... -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Digging through my so-called memory<g>, loading both Alien and Citezen required special attention. Alien led to a broken image, and Citezen was simply tricky to load such that it would work. Both required requesting specific versions in order to work. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Friday, June 15, 2012 8:08 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Schwab,Wilhelm K wrote
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now.
Absolutely! Two things about that: * Metacello has no magic. Ultimately, what you correctly suggest requires someone to test a project on a new platform and update the config... coming soon and desperately needed: tools to help this process... * we're all learning how to use Metacello... even as it evolves underneath us! If you experience something other than above, please post the specific example so we can examine the configs and see what's going on... -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
If you provide the script (i.e. version(s)) that you used and the platform(s) you successfully loaded/used the project on, I will update the configs... We should have a central place to share these custom load scripts and results so that they can be mined by config maintainers. prob would crowd the Metacello list too much. maybe Dale will create a special list for it. I'll cc the Metacello list... On Jun 15, 2012, at 8:45 PM, Schwab,Wilhelm K [via Smalltalk] wrote:
Digging through my so-called memory<g>, loading both Alien and Citezen required special attention. Alien led to a broken image, and Citezen was simply tricky to load such that it would work. Both required requesting specific versions in order to work.
________________________________________ From: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]] Sent: Friday, June 15, 2012 8:08 PM To: [hidden email] Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Schwab,Wilhelm K wrote
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now.
Absolutely! Two things about that: * Metacello has no magic. Ultimately, what you correctly suggest requires someone to test a project on a new platform and update the config... coming soon and desperately needed: tools to help this process... * we're all learning how to use Metacello... even as it evolves underneath us!
If you experience something other than above, please post the specific example so we can examine the configs and see what's going on...
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
If you reply to this email, your message will be added to the discussion below: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... To unsubscribe from start thinking on summer release of Pharo 1.4, click here. NAML
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote:
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now.
Bill when do you take the time to have a look at Metacello. Why people like me are spending days on writing 45 pages of documentation to hear you saying that. This scenario is supported since months nearly since Barcelona 2010.
If we can't do that, the config browser is pretty much a dream vs. reality.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Friday, June 15, 2012 2:49 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Schwab,Wilhelm K wrote
My gripe is... that configs... work (very) differently over time
With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now.
The only hill to climb now is getting the word out about Metacello conventions/best practices.
Schwab,Wilhelm K wrote
If pre-loading, how about FFI?
I think "easily loadable" is the correct state, not included by default.
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stef, I have had experts on it tell me exactly the opposite. Things like "always load specific versions" and "never load symbolic versions." They mean well (and have been helpful in the short term), but it is far from a generic solution. The "answer" will invariably be different "every time." Citezen is much appreciated, but your answer to getting it to load was to load a specific numeric version. Ditto Alien/FFI from others. I am simply repeating what I have been told. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, June 16, 2012 4:24 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote:
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now.
Bill when do you take the time to have a look at Metacello. Why people like me are spending days on writing 45 pages of documentation to hear you saying that. This scenario is supported since months nearly since Barcelona 2010.
If we can't do that, the config browser is pretty much a dream vs. reality.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Friday, June 15, 2012 2:49 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Schwab,Wilhelm K wrote
My gripe is... that configs... work (very) differently over time
With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now.
The only hill to climb now is getting the word out about Metacello conventions/best practices.
Schwab,Wilhelm K wrote
If pre-loading, how about FFI?
I think "easily loadable" is the correct state, not included by default.
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Jun 16, 2012, at 8:14 PM, Schwab,Wilhelm K wrote:
Stef,
I have had experts on it tell me exactly the opposite. Things like "always load specific versions" and "never load symbolic versions." They mean well (and have been helpful in the short term), but it is far from a generic solution. The "answer" will invariably be different "every time."
Citezen is much appreciated, but your answer to getting it to load was to load a specific numeric version.
did you read the configuration? Because if there is no symbolic version then load a specific one. Then you have to control what you want to load. I think that symbolic versions are working quite well.
Ditto Alien/FFI from others.
I am simply repeating what I have been told.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, June 16, 2012 4:24 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote:
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now.
Bill when do you take the time to have a look at Metacello. Why people like me are spending days on writing 45 pages of documentation to hear you saying that.
This scenario is supported since months nearly since Barcelona 2010.
If we can't do that, the config browser is pretty much a dream vs. reality.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Friday, June 15, 2012 2:49 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Schwab,Wilhelm K wrote
My gripe is... that configs... work (very) differently over time
With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now.
The only hill to climb now is getting the word out about Metacello conventions/best practices.
Schwab,Wilhelm K wrote
If pre-loading, how about FFI?
I think "easily loadable" is the correct state, not included by default.
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Sat, Jun 16, 2012 at 10:06 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Jun 16, 2012, at 8:14 PM, Schwab,Wilhelm K wrote:
Stef,
I have had experts on it tell me exactly the opposite. Things like "always load specific versions" and "never load symbolic versions." They mean well (and have been helpful in the short term), but it is far from a generic solution. The "answer" will invariably be different "every time."
Citezen is much appreciated, but your answer to getting it to load was to load a specific numeric version.
did you read the configuration? Because if there is no symbolic version then load a specific one. Then you have to control what you want to load.
I think that symbolic versions are working quite well.
They are :)
Ditto Alien/FFI from others.
I am simply repeating what I have been told.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, June 16, 2012 4:24 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote:
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now.
Bill when do you take the time to have a look at Metacello. Why people like me are spending days on writing 45 pages of documentation to hear you saying that.
This scenario is supported since months nearly since Barcelona 2010.
If we can't do that, the config browser is pretty much a dream vs. reality.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com]
Sent: Friday, June 15, 2012 2:49 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Schwab,Wilhelm K wrote
My gripe is... that configs... work (very) differently over time
With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now.
The only hill to climb now is getting the word out about Metacello conventions/best practices.
Schwab,Wilhelm K wrote
If pre-loading, how about FFI?
I think "easily loadable" is the correct state, not included by default.
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
+1 for newcomer consideration. Nautilus is obviously well liked by the more experienced users who can deal better with the odd issue and modification that pops up, but an older code base might be better for new users for now. Thanks for the advance notice. I've just got to the point in the 1.4 review of Pharo By Example that I am taking snapshots of the browser and tossing up which browser to include. I was leaning towards using only the basic 1.4-built-in browser to try to make each chapter independent of previous ones - but much happier to snapshot OB. So unless any objections arise, I will do PBE with OB. These will need redoing for the 2.0 look and feel anyway, and PBE can be changed to Nautilus then.
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code.
That would be me. I'm not familiar with Spotlight but it sounds like I'll like it.
If you still prefer those ways, is up to you ;)
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
Call it SummerRain :). Yes this is a good idea. What we should do also is to push and validate metacello Configs. We should really move on such topic. Stef On Jun 13, 2012, at 11:08 AM, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;)
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
Can't help remember something old... Clipper Summer '87. The name was sticking for a long while. http://en.wikipedia.org/wiki/Clipper_(programming_language) You'll see the Seasonal Versions, which is quite a nice idea in fact as it allows interesting themeing to take place. There was a VM and blocks... A mix of a compiler and an embarked interpreter. Wrote a ton of apps for businesses in order to pay for my university fees. Worked well. :-) Philippe. 2012/6/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Call it SummerRain :).
Yes this is a good idea.
What we should do also is to push and validate metacello Configs. We should really move on such topic.
Stef
On Jun 13, 2012, at 11:08 AM, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click:
- pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser.
- pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;)
So far, this and the bugfixes we already made (and some more)...
What do you think?
Esteban
-- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
EstebanLM wrote
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
Keep us posted on the target date. I want to review bug fixes integrated in 2.0 [1] and see if any should be included for 1.4 per http://forum.world.st/Backporting-fixes-tp4633625p4633635.html EstebanLM wrote
- pre-load Spotlight
+1. No brainer. It's small and really helpful. Re browsers... I would definitely include either OB or Nautilus. The default is just too limiting. Nautilus does seem to be in a pretty usable state now, and it'd be helpful for new users not to have to learn two browsers in two releases... [1] http://code.google.com/p/pharo/issues/list?can=1&q=status%3AIntegrated+Miles... -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Have been using Nautilus and OB and albeit Nautilus is nicer looking, I find my way better with OB. Especially with the top search bar and categorizing into protocols. More buttons under the lists in OB but I do prefer them actually. Phil 2012/6/14 Sean P. DeNigris <sean@clipperadams.com>:
EstebanLM wrote
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
Keep us posted on the target date. I want to review bug fixes integrated in 2.0 [1] and see if any should be included for 1.4 per http://forum.world.st/Backporting-fixes-tp4633625p4633635.html
EstebanLM wrote
- pre-load Spotlight
+1. No brainer. It's small and really helpful.
Re browsers... I would definitely include either OB or Nautilus. The default is just too limiting. Nautilus does seem to be in a pretty usable state now, and it'd be helpful for new users not to have to learn two browsers in two releases...
[1] http://code.google.com/p/pharo/issues/list?can=1&q=status%3AIntegrated+Miles...
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
philippeback wrote
Have been using Nautilus and OB and albeit Nautilus is nicer looking, I find my way better with OB. Especially with the top search bar and categorizing into protocols. More buttons under the lists in OB but I do prefer them actually.
Overall, I like Nautilus' workflow better, but I know what you mean about the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" class-side mode, or I have to hit the button to "get" class-side mode. I was missing the search bar, but with spotlight, it's moot. Sean -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay! But I like to have a view on several classes and typing HOPR¨helps. Same when exploring the system for doing something (like sound-synthesis for example). BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 extract of yours. As of Pharo 1.4 Summer Release, having a somewhat cleaned up Sound-synthesis in it would be nice. I am currently creating a little game in Smalltalk targeting the iPad and a game without sound is not that of a game. For beginners and motivating people to move aboard the platform, sound is important to have. KR Philippe 2012/6/15 Sean P. DeNigris <sean@clipperadams.com>:
philippeback wrote
Have been using Nautilus and OB and albeit Nautilus is nicer looking, I find my way better with OB. Especially with the top search bar and categorizing into protocols. More buttons under the lists in OB but I do prefer them actually.
Overall, I like Nautilus' workflow better, but I know what you mean about the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" class-side mode, or I have to hit the button to "get" class-side mode. I was missing the search bar, but with spotlight, it's moot.
Sean
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
philippeback wrote
BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 extract of yours.
Not that I'm aware of... I rescued a video morph too (IIRC it should play any format that QT can handle). -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Phil, i would be really glad to help with that, but currently my plate is too full. Perhaps there someone who can check it out and fix it if it broken or miss some parts. As Marcus says (and i like to repeat that), when something is not used/tested daily, it only a question of time when you will find it broken. On 15 June 2012 23:36, phil@highoctane.be <phil@highoctane.be> wrote:
Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay!
But I like to have a view on several classes and typing HOPR¨helps.
Same when exploring the system for doing something (like sound-synthesis for example).
BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 extract of yours.
As of Pharo 1.4 Summer Release, having a somewhat cleaned up Sound-synthesis in it would be nice.
I am currently creating a little game in Smalltalk targeting the iPad and a game without sound is not that of a game.
For beginners and motivating people to move aboard the platform, sound is important to have.
KR Philippe
-- Best regards, Igor Stasenko.
On Jun 15, 2012, at 11:36 PM, phil@highoctane.be wrote:
Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay!
But I like to have a view on several classes and typing HOPR¨helps.
Same when exploring the system for doing something (like sound-synthesis for example).
BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 extract of yours.
As of Pharo 1.4 Summer Release, having a somewhat cleaned up Sound-synthesis in it would be nice.
our agenda is more than full. Do not expect anything from us on this side. we have athens FFI/NativeBoost and a lot of other points to fix.
I am currently creating a little game in Smalltalk targeting the iPad and a game without sound is not that of a game.
Load the packages and try.
For beginners and motivating people to move aboard the platform, sound is important to have.
KR Philippe
2012/6/15 Sean P. DeNigris <sean@clipperadams.com>:
philippeback wrote
Have been using Nautilus and OB and albeit Nautilus is nicer looking, I find my way better with OB. Especially with the top search bar and categorizing into protocols. More buttons under the lists in OB but I do prefer them actually.
Overall, I like Nautilus' workflow better, but I know what you mean about the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" class-side mode, or I have to hit the button to "get" class-side mode. I was missing the search bar, but with spotlight, it's moot.
Sean
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Hi, you are asking for two things there: -a sound package for pharo 1.4 (I don't know if it exists, and in any case we cannot add it as a core package, you need to install it and see how it works by yourself) -a working sound plugin for iOS. TBH, while I'm including it in regular compilations, I never tested it, so I don't know if is working properly. Of course, to do games and others, is clear that we need a working sound system into iOS... . Esteban On Jun 15, 2012, at 11:36 PM, phil@highoctane.be wrote:
Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay!
But I like to have a view on several classes and typing HOPR¨helps.
Same when exploring the system for doing something (like sound-synthesis for example).
BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 extract of yours.
As of Pharo 1.4 Summer Release, having a somewhat cleaned up Sound-synthesis in it would be nice.
I am currently creating a little game in Smalltalk targeting the iPad and a game without sound is not that of a game.
For beginners and motivating people to move aboard the platform, sound is important to have.
KR Philippe
2012/6/15 Sean P. DeNigris <sean@clipperadams.com>:
philippeback wrote
Have been using Nautilus and OB and albeit Nautilus is nicer looking, I find my way better with OB. Especially with the top search bar and categorizing into protocols. More buttons under the lists in OB but I do prefer them actually.
Overall, I like Nautilus' workflow better, but I know what you mean about the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" class-side mode, or I have to hit the button to "get" class-side mode. I was missing the search bar, but with spotlight, it's moot.
Sean
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
If it helps at all, I was able (with help) to get sound working on Linux. It's ugly: one has to copy/rename the plugin from another vm (to use cog). Once I got it working, I flagged a copy of the plugin in the hopes of making things easier next time. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm@gmail.com] Sent: Saturday, June 16, 2012 6:20 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Hi, you are asking for two things there: -a sound package for pharo 1.4 (I don't know if it exists, and in any case we cannot add it as a core package, you need to install it and see how it works by yourself) -a working sound plugin for iOS. TBH, while I'm including it in regular compilations, I never tested it, so I don't know if is working properly. Of course, to do games and others, is clear that we need a working sound system into iOS... . Esteban On Jun 15, 2012, at 11:36 PM, phil@highoctane.be wrote:
Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay!
But I like to have a view on several classes and typing HOPR¨helps.
Same when exploring the system for doing something (like sound-synthesis for example).
BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 extract of yours.
As of Pharo 1.4 Summer Release, having a somewhat cleaned up Sound-synthesis in it would be nice.
I am currently creating a little game in Smalltalk targeting the iPad and a game without sound is not that of a game.
For beginners and motivating people to move aboard the platform, sound is important to have.
KR Philippe
2012/6/15 Sean P. DeNigris <sean@clipperadams.com>:
philippeback wrote
Have been using Nautilus and OB and albeit Nautilus is nicer looking, I find my way better with OB. Especially with the top search bar and categorizing into protocols. More buttons under the lists in OB but I do prefer them actually.
Overall, I like Nautilus' workflow better, but I know what you mean about the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" class-side mode, or I have to hit the button to "get" class-side mode. I was missing the search bar, but with spotlight, it's moot.
Sean
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Sean P. DeNigris wrote:
EstebanLM wrote
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
Re browsers... I would definitely include either OB or Nautilus. The default is just too limiting. Nautilus does seem to be in a pretty usable state now, and it'd be helpful for new users not to have to learn two browsers in two releases...
-1 on code name "summer" since it is winter here in Australia. Also, were you considering the full name being: a) only "Summer" b) "Pharo Summer" c) "Pharo 1.4 Summer"
For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Another code name could work. For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1' Also for consideration with using a code name rather than a version number, the two I know off... Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. The underlying platform still uses point numbers. Esteban, Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4. cheers -ben
I prefer codenames and not number because numbering is boring. Just that. 1.4.1 is a stupid number that makes people believe that there will be a 1.4.2, etc... (because our mind is designed that way, inevitably). And if I want to realease an emergency fix, as this version is 1.4.1 next version will be 1.4.1.1 etc. So, no, I prefer codenames over numbering. Also, I'm from southamerica, I know perfectly well than summer here is winter there. I also know something more: nobody cares there :) but if there are complains, I'm willing to change the code name for... I dunno, places where there are Faros. 1.4 Alexandria 1.4 Finistère 1.4 Usuhaia :) as I said... I just don't care which code name, but I don't want numbers. (btw... I'm kinda happy that this is the biggest divergence in my proposal :P) On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Sean P. DeNigris wrote:
EstebanLM wrote
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
Re browsers... I would definitely include either OB or Nautilus. The default is just too limiting. Nautilus does seem to be in a pretty usable state now, and it'd be helpful for new users not to have to learn two browsers in two releases...
-1 on code name "summer" since it is winter here in Australia. Also, were you considering the full name being: a) only "Summer" b) "Pharo Summer" c) "Pharo 1.4 Summer"
For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Another code name could work. For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1' (c) was my idea, but if place-codenames are taken, we can use a different names each times.
Also for consideration with using a code name rather than a version number, the two I know off... Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. The underlying platform still uses point numbers.
Esteban,
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
no, because you can load Nautilus on top of OB, but not the opposite.
cheers -ben
As a tribute to south america, why not pick up places, people, or events? There is for sure a wealth of names and a rich history. Would be great as lots of growth expected in that area of the world! http://en.wikipedia.org/wiki/History_of_Argentina http://en.wikipedia.org/wiki/History_of_Chile Pharo Patagonia anyone? Phil 2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
I prefer codenames and not number because numbering is boring. Just that. 1.4.1 is a stupid number that makes people believe that there will be a 1.4.2, etc... (because our mind is designed that way, inevitably). And if I want to realease an emergency fix, as this version is 1.4.1 next version will be 1.4.1.1 etc. So, no, I prefer codenames over numbering. Also, I'm from southamerica, I know perfectly well than summer here is winter there. I also know something more: nobody cares there :) but if there are complains, I'm willing to change the code name for... I dunno, places where there are Faros.
1.4 Alexandria 1.4 Finistère 1.4 Usuhaia :)
as I said... I just don't care which code name, but I don't want numbers.
(btw... I'm kinda happy that this is the biggest divergence in my proposal :P)
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Sean P. DeNigris wrote:
EstebanLM wrote
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
Re browsers... I would definitely include either OB or Nautilus. The default is just too limiting. Nautilus does seem to be in a pretty usable state now, and it'd be helpful for new users not to have to learn two browsers in two releases...
-1 on code name "summer" since it is winter here in Australia. Â Also, were you considering the full name being: a) only "Summer" b) "Pharo Summer" c) "Pharo 1.4 Summer"
For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Â Another code name could work. For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1' (c) was my idea, but if place-codenames are taken, we can use a different names each times.
Also for consideration with using a code name rather than a version number, the two I know off... Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. Â The underlying platform still uses point numbers.
Esteban,
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
no, because you can load Nautilus on top of OB, but not the opposite.
cheers -ben
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Esteban Lorenzano wrote:
I prefer codenames and not number because numbering is boring. Just that. 1.4.1 is a stupid number that makes people believe that there will be a 1.4.2, etc... (because our mind is designed that way, inevitably). And if I want to realease an emergency fix, as this version is 1.4.1 next version will be 1.4.1.1 etc. So, no, I prefer codenames over numbering. Also, I'm from southamerica, I know perfectly well than summer here is winter there. I also know something more: nobody cares there :) but if there are complains, I'm willing to change the code name for... I dunno, places where there are Faros.
1.4 Alexandria 1.4 Finistère 1.4 Usuhaia :)
as I said... I just don't care which code name, but I don't want numbers.
(btw... I'm kinda happy that this is the biggest divergence in my proposal :P)
Well I was very happy to hear your proposal. You are in the drivers seat so I'll live with whatever outcome - but just a bit more counter-point... Sometimes boring makes the world go round. If you release an emergency fix to '1.4 Alexandria' - what do you call it? Are you going to be tagging in the Issue Tracker the fixes included with maintenance release - what would you use? Looking further into how Ubuntu handle this [1] (since they are most obvious using funky release naming.) Turns out their official release actually remains numeric point-form, but because they include the month of release in the minor point-number they need the codename "during development". Perhaps including the numeric month somewhat addresses your concern of expectations of continuing minor revisions. However since there has been no codename and the release month is unknown to me, I have been thinking about the maintenance release as 1.4.1. I'd be very happy to have a codename to refer to this up until release (and probably for some time afterwards) - but I'd still really like a point form backing, to refer to in a few years time. [1] https://wiki.ubuntu.com/DevelopmentCodeNames cheers -ben
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Sean P. DeNigris wrote:
EstebanLM wrote
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
Re browsers... I would definitely include either OB or Nautilus. The default is just too limiting. Nautilus does seem to be in a pretty usable state now, and it'd be helpful for new users not to have to learn two browsers in two releases...
-1 on code name "summer" since it is winter here in Australia. Also, were you considering the full name being: a) only "Summer" b) "Pharo Summer" c) "Pharo 1.4 Summer"
For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Another code name could work. For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1'
(c) was my idea, but if place-codenames are taken, we can use a different names each times.
Also for consideration with using a code name rather than a version number, the two I know off... Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. The underlying platform still uses point numbers.
Esteban,
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
no, because you can load Nautilus on top of OB, but not the opposite.
cheers -ben
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, I don't know what to do now :) Esteban
OB if we want traction with embarking new people into Pharo. Think about the feeling it would give when faced with incomplete/unstable in such a thing as the Browser for a new comer or someone who wants to convince "the powers" that Pharo is an interesting avenue to invest into. Nautilus is the shiny new thing. But OB has all the important things working and the refactorings do kind of work well. And what's wrong with OB after all? There are docs on how to leverage the thing to do our own extensions, which is good. (Glamour still too far fetched at my level). But OB is okay after going through the docs. Know what? At a minimum, it should be clear that one can load OB from the Configurations with just a DoIt from the initial workspace. The way it is now is too complicated to find out. Same thing with ProfStef, FFI etc And a warning telling about how long it would take and so on may be a great thing (Getting OB from the 1.4 metarepo is just taking a long while... and no one wanting to try things out in an overbusy schedule would be able to spend that time. Another point crossing my mind is that if you try this out during a commute in a train or place, you are stuck without network connection. A primed package-cache would be beneficial for that, at the expense of the release size). Spotlight would also benefit from an explanation (like hit Shift-Enter to invoke. In the beginning I was opening that in World and then had a look at the code to find out about the binding...) Know what, we may want to have a YouTube video going with the release and showing how to do that stuff and what to expect. I am volunteering to do it if you are interested. Phil 2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, Â I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
philippeback wrote
OB if we want traction with embarking new people into Pharo. ...
That makes sense. The only downside is that we will train people on one browser and almost immediately switch to a new one. I remember questions about how to "get the browser from PBE" (it was O2 I think). Although, I guess this is a good tradeoff vs. exposing newbies to a bleeding edge tool under heavy development. Also, about that release date... Sean -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Moved to Nautilus for a week, I am now back to OB. At least I can navigate through everything without weird things popping up in my face everyone in a while (well, even with OB there are quite a bunch.). Just an example with OB (screenshot): Finder > pragma > click click on the tree branch --> bam! error message. Look at the stracktrace, the only thing I want is to close that. Phil 2012/6/17 Sean P. DeNigris <sean@clipperadams.com>:
philippeback wrote
OB if we want traction with embarking new people into Pharo. ...
That makes sense. The only downside is that we will train people on one browser and almost immediately switch to a new one. I remember questions about how to "get the browser from PBE" (it was O2 I think). Although, I guess this is a good tradeoff vs. exposing newbies to a bleeding edge tool under heavy development.
Also, about that release date...
Sean
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
On 17 June 2012 16:36, phil@highoctane.be <phil@highoctane.be> wrote:
Moved to Nautilus for a week, I am now back to OB. At least I can navigate through everything without weird things popping up in my face everyone in a while (well, even with OB there are quite a bunch.).
Just an example with OB (screenshot): Finder > pragma > click click on the tree branch --> bam! error message. Look at the stracktrace, the only thing I want is to close that.
I bet this can take 2 minutes to fix. But since we don't have an OB maintainer, these 2 minutes can be easily stretched to 6 months. I leaving to you, to think how to change that :)
Phil
-- Best regards, Igor Stasenko.
On Sun, Jun 17, 2012 at 4:36 PM, phil@highoctane.be <phil@highoctane.be>wrote:
Moved to Nautilus for a week, I am now back to OB. At least I can navigate through everything without weird things popping up in my face everyone in a while (well, even with OB there are quite a bunch.).
Good luck trying to make OB work in Pharo 2.0!
Just an example with OB (screenshot): Finder > pragma > click click on the tree branch --> bam! error message. Look at the stracktrace, the only thing I want is to close that.
Phil
2012/6/17 Sean P. DeNigris <sean@clipperadams.com>:
philippeback wrote
OB if we want traction with embarking new people into Pharo. ...
That makes sense. The only downside is that we will train people on one browser and almost immediately switch to a new one. I remember questions about how to "get the browser from PBE" (it was O2 I think). Although, I guess this is a good tradeoff vs. exposing newbies to a bleeding edge
tool
under heavy development.
Also, about that release date...
Sean
-- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Mariano http://marianopeck.wordpress.com
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people? And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while. That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?" Phil 2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, Â I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
i for Pharo 1.4.1 no messy naming please. Let's care more about what we put under the hood, than on glossy cover. -- Best regards, Igor Stasenko.
The girl was attractive and that's why I talked to her. Light was faster than sound in her case, so I left. But, I wouldn't have spoken to her in the first place should she have been an ugly betty. That's just the way things go and why marketing focuses so much on packaging, even if it is an ugly mess inside (Microwave food anyone?) 2012/6/17 Igor Stasenko <siguctua@gmail.com>:
i for Pharo 1.4.1 no messy naming please.
Let's care more about what we put under the hood, than on glossy cover.
-- Best regards, Igor Stasenko.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
+1 ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, June 17, 2012 6:48 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 i for Pharo 1.4.1 no messy naming please. Let's care more about what we put under the hood, than on glossy cover. -- Best regards, Igor Stasenko.
yes, Configurations Browser needs a little love too :P On Jun 17, 2012, at 12:44 PM, phil@highoctane.be wrote:
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people?
And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while.
That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?"
Phil
2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium <PharoScreenshot.1.png>
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh. Long delays and hangs are BAD, but that can be addressed using background threads. This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision. The list of configs appearing in the browser is encouraging. I'd hope to see ODBC listed too, but Glorp is there. If all of these configs offer and can load a #stable version, that would be huge progress. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people? And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while. That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?" Phil 2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work. Just that I am running a business and want to make Pharo a cornerstone of my technical tools. This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in. There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it. Phil 2012/6/17 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh.
Long delays and hangs are BAD, but that can be addressed using background threads. Â This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision.
The list of configs appearing in the browser is encouraging. Â I'd hope to see ODBC listed too, but Glorp is there. Â If all of these configs offer and can load a #stable version, that would be huge progress.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people?
And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while.
That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?"
Phil
2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, Â I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Phil just for the record, if we would get 4 engineers working full time during 2 more years you would not recognize Pharo. Now we are making progress but we are nearly all working on our free time. So this is not that we do not have the vision, just not enough money :). Stef On Jun 17, 2012, at 9:42 PM, phil@highoctane.be wrote:
Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work.
Just that I am running a business and want to make Pharo a cornerstone of my technical tools.
This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in.
There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it.
Phil
2012/6/17 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh.
Long delays and hangs are BAD, but that can be addressed using background threads. This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision.
The list of configs appearing in the browser is encouraging. I'd hope to see ODBC listed too, but Glorp is there. If all of these configs offer and can load a #stable version, that would be huge progress.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people?
And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while.
That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?"
Phil
2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Stef, Just a matter of time before the money flows in. I am pretty convinced of that. No kidding. Phil 2012/6/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Phil
just for the record, if we would get 4 engineers working full time during 2 more years you would not recognize Pharo. Now we are making progress but we are nearly all working on our free time. So this is not that we do not have the vision, just not enough money :).
Stef
On Jun 17, 2012, at 9:42 PM, phil@highoctane.be wrote:
Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work.
Just that I am running a business and want to make Pharo a cornerstone of my technical tools.
This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in.
There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it.
Phil
2012/6/17 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh.
Long delays and hangs are BAD, but that can be addressed using background threads. Â This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision.
The list of configs appearing in the browser is encouraging. Â I'd hope to see ODBC listed too, but Glorp is there. Â If all of these configs offer and can load a #stable version, that would be huge progress.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people?
And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while.
That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?"
Phil
2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, Â I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
BTW what did Mozilla FWD told you? https://webfwd.org/ 2012/6/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Phil
just for the record, if we would get 4 engineers working full time during 2 more years you would not recognize Pharo. Now we are making progress but we are nearly all working on our free time. So this is not that we do not have the vision, just not enough money :).
Stef
On Jun 17, 2012, at 9:42 PM, phil@highoctane.be wrote:
Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work.
Just that I am running a business and want to make Pharo a cornerstone of my technical tools.
This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in.
There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it.
Phil
2012/6/17 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh.
Long delays and hangs are BAD, but that can be addressed using background threads. Â This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision.
The list of configs appearing in the browser is encouraging. Â I'd hope to see ODBC listed too, but Glorp is there. Â If all of these configs offer and can load a #stable version, that would be huge progress.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people?
And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while.
That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?"
Phil
2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, Â I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
There is also (http://ycombinator.com) particularly if you can do any of these... (http://ycombinator.com/ideas.html) The first link of the FAQ is very informative but quite long. Not that these startup funds would fund Pharo directly, but perhaps someone using Pharo as a competitive advantage. phil@highoctane.be wrote:
BTW what did Mozilla FWD told you? https://webfwd.org/
2012/6/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Phil
just for the record, if we would get 4 engineers working full time during 2 more years you would not recognize Pharo. Now we are making progress but we are nearly all working on our free time. So this is not that we do not have the vision, just not enough money :).
Stef
On Jun 17, 2012, at 9:42 PM, phil@highoctane.be wrote:
Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work.
Just that I am running a business and want to make Pharo a cornerstone of my technical tools.
This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in.
There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it.
Phil
2012/6/17 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh.
Long delays and hangs are BAD, but that can be addressed using background threads. This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision.
The list of configs appearing in the browser is encouraging. I'd hope to see ODBC listed too, but Glorp is there. If all of these configs offer and can load a #stable version, that would be huge progress.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people?
And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while.
That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?"
Phil
2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Who wants to hit the button? https://webfwd.org/apply/ 2012/6/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Phil
just for the record, if we would get 4 engineers working full time during 2 more years you would not recognize Pharo. Now we are making progress but we are nearly all working on our free time. So this is not that we do not have the vision, just not enough money :).
Stef
On Jun 17, 2012, at 9:42 PM, phil@highoctane.be wrote:
Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work.
Just that I am running a business and want to make Pharo a cornerstone of my technical tools.
This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in.
There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it.
Phil
2012/6/17 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh.
Long delays and hangs are BAD, but that can be addressed using background threads. Â This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision.
The list of configs appearing in the browser is encouraging. Â I'd hope to see ODBC listed too, but Glorp is there. Â If all of these configs offer and can load a #stable version, that would be huge progress.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of phil@highoctane.be [phil@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people?
And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while.
That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?"
Phil
2012/6/17 Esteban Lorenzano <estebanlm@gmail.com>:
On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4.
this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, Â I don't know what to do now :)
Esteban
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Who wants to hit the button?
I read it when you told me but I was confused because pharo is not only about web. I will reread it. Stef
Well, it is web-ish enough to warrant some ca$h heh? Seaside, tODE, Pier, Zn, Monticello, SS3, all that is web. Pharo and the web, distributed coding at its best. Pharo is the core upon which all the rest is built for success and kick-ass delivery! Phil 2012/6/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Who wants to hit the button?
I read it when you told me but I was confused because pharo is not only about web. I will reread it.
Stef
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
I reread the web site and this is more for startups? I passed the message to guys around.
Well, it is web-ish enough to warrant some ca$h heh?
Seaside, tODE, Pier, Zn, Monticello, SS3, all that is web.
Pharo and the web, distributed coding at its best.
Pharo is the core upon which all the rest is built for success and kick-ass delivery!
Phil
2012/6/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Who wants to hit the button?
I read it when you told me but I was confused because pharo is not only about web. I will reread it.
Stef
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
On 2012-06-17, at 21:42, phil@highoctane.be wrote:
Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work.
Just that I am running a business and want to make Pharo a cornerstone of my technical tools.
This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in.
There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it.
Phil
maybe you should try again under 2.0 to load configs. We got some massive speedups in Monticello by caching the right things :P. now 2.0 is alpha so be warned :)
Sean P. DeNigris wrote
I want to review bug fixes integrated in 2.0 [1] and see if any should be included for 1.4 per http://forum.world.st/Backporting-fixes-tp4633625p4633635.html
[1] http://code.google.com/p/pharo/issues/list?can=1&q=status%3AIntegrated+Miles...
I did a first pass on the 2.0 fix list. I created an issue: Issue 6144: Port 2.0 bug fixes to 1.4 for summer release http://code.google.com/p/pharo/issues/detail?id=6144 Each comment contains a port of a fix that was integrated in 2.0 and conforms to Marcus' guidelines for including in 1.4 [2]. The slices were all created with 1.4 #14444. Please add any that I missed... Cheers, Sean [2] guidelines for bug fixes to a released version of Pharo (i.e. 1.4): - No new features. - No cleanups - If a bug was there in Pharo 1.1 already and we lived with it for years, fixing it in the current dev version is (in many cases) enough. (There are exceptions, but is does not happen often). -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp463458... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 13.06.2012 11:08, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
It's only summer in the northern hemisphere. Eclipse renamed their winter releases because it isn't winter in February in half of the world. Cheers Philippe
On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <kustos@gmx.net> wrote:
On 13.06.2012 11:08, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
It's only summer in the northern hemisphere. Eclipse renamed their winter releases because it isn't winter in February in half of the world.
+1 to simply call it 1.4.1 -- Mariano http://marianopeck.wordpress.com
We are closing the gap with Java versions... Pharo 1.6.3_047 nearing... 2012/6/16 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <kustos@gmx.net> wrote:
On 13.06.2012 11:08, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
It's only summer in the northern hemisphere. Eclipse renamed their winter releases because it isn't winter in February in half of the world.
+1 to simply call it 1.4.1
-- Mariano http://marianopeck.wordpress.com
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
http://en.wikipedia.org/wiki/Java_version_history isn't too bad either with Update x suffix. Pharo SE 4 Update 2 ... there is some good marketing touch to that given the popularity of Java. They switched after 1.4 - As an innovative platform, maybe we can switch now :-) 2.0 would become Pharo SE 5 and things like Seaside would be Pharo WE 6 (Web Edition) and moose Pharo DE 4 (Data visualization Edition) Phil 2012/6/16 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <kustos@gmx.net> wrote:
On 13.06.2012 11:08, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number).
It's only summer in the northern hemisphere. Eclipse renamed their winter releases because it isn't winter in February in half of the world.
+1 to simply call it 1.4.1
-- Mariano http://marianopeck.wordpress.com
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
I do not know... Python and Ruby are kind of popular too without needing such kind of prefixes... I thing we should be original in the name :), and that's all... On Sat, Jun 16, 2012 at 10:50 PM, phil@highoctane.be <phil@highoctane.be>wrote:
http://en.wikipedia.org/wiki/Java_version_history isn't too bad either with Update x suffix.
Pharo SE 4 Update 2 ... there is some good marketing touch to that given the popularity of Java.
They switched after 1.4 - As an innovative platform, maybe we can switch now :-)
2.0 would become Pharo SE 5 and things like Seaside would be Pharo WE 6 (Web Edition) and moose Pharo DE 4 (Data visualization Edition)
Phil
2012/6/16 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <kustos@gmx.net>
wrote:
On 13.06.2012 11:08, Esteban Lorenzano wrote:
Hi,
I started thinking on next release of Pharo 1.4 (which will be code
named
"summer", not an ugly number).
It's only summer in the northern hemisphere. Eclipse renamed their winter releases because it isn't winter in February in half of the world.
+1 to simply call it 1.4.1
-- Mariano http://marianopeck.wordpress.com
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
On 13 June 2012 11:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
- pre-load OmniBrowser.
Two things I have noticed don't work well in OB in Pharo 1.4: 1. The chasing browser for senders/implementors - well it's not chasing. 2. When you hit ctrl+f and type something, you cannot use arrow keys to select a class from the list. You have to switch focus with the mouse first. -- Milan Mimica http://sparklet.sf.net
On Jun 18, 2012, at 7:00 PM, Milan Mimica wrote:
On 13 June 2012 11:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
- pre-load OmniBrowser.
Two things I have noticed don't work well in OB in Pharo 1.4: 1. The chasing browser for senders/implementors - well it's not chasing.
check because normally there is a setting or a way to change its behavior.
2. When you hit ctrl+f and type something, you cannot use arrow keys to select a class from the list. You have to switch focus with the mouse first.
-- Milan Mimica http://sparklet.sf.net
Ok... but we are not going to spend time fixing OB. OB maintainers are not anymore in the community (or are not willing to maintain OB for 1.4) and is too much work for us to do it. I think even with that couple of things you are reporting (and maybe some others that may appear), OB is overall working fine with 1.4. We are working on the future browser (Nautilus) and we sorry that is not ready yet, but well... that's life :P Of course, if someone wants to take this issues and do a quick fix, squeaksource.com/PharoOB project is open to accept fixes. Esteban On Jun 18, 2012, at 7:00 PM, Milan Mimica wrote:
On 13 June 2012 11:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
- pre-load OmniBrowser.
Two things I have noticed don't work well in OB in Pharo 1.4: 1. The chasing browser for senders/implementors - well it's not chasing. 2. When you hit ctrl+f and type something, you cannot use arrow keys to select a class from the list. You have to switch focus with the mouse first.
-- Milan Mimica http://sparklet.sf.net
participants (16)
-
Ben Coman -
Benjamin -
btc＠openInWorld.com
-
Camillo Bruni -
Esteban Lorenzano -
Guillermo Polito -
Igor Stasenko -
Mariano Martinez Peck -
Milan Mimica -
phil＠highoctane.be -
Philippe Marschall -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe -
Yanni Chiu