start thinking on summer release of Pharo 1.4
Locked
1234
1234
Re: start thinking on summer release of Pharo 1.4
 
Administrator
|
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.
Cheers,
Sean |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by philippeback
On Jun 15, 2012, at 11:36 PM, [hidden email] 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 <[hidden email]>: >> >> 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-tp4634589p4635007.html >> 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: > [hidden email] | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Schwab,Wilhelm K
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: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]] > Sent: Friday, June 15, 2012 2:49 PM > To: [hidden email] > 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-tp4634589p4635009.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > |
|
|
In reply to this post by philippeback
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, [hidden email] 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 <[hidden email]>: >> >> 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-tp4634589p4635007.html >> 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: > [hidden email] | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by EstebanLM
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 |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Stéphane Ducasse
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: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] Sent: Saturday, June 16, 2012 4:24 AM To: [hidden email] 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: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]] > Sent: Friday, June 15, 2012 2:49 PM > To: [hidden email] > 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-tp4634589p4635009.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by EstebanLM
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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]] Sent: Saturday, June 16, 2012 6:20 AM To: [hidden email] 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, [hidden email] 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 <[hidden email]>: >> >> 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-tp4634589p4635007.html >> 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: > [hidden email] | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Philippe Marschall-2-3
On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <[hidden email]> wrote:
+1 to simply call it 1.4.1 -- Mariano http://marianopeck.wordpress.com |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Schwab,Wilhelm K
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: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] > Sent: Saturday, June 16, 2012 4:24 AM > To: [hidden email] > 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: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]] >> Sent: Friday, June 15, 2012 2:49 PM >> To: [hidden email] >> 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-tp4634589p4635009.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > |
Re: start thinking on summer release of Pharo 1.4
|
|
On Sat, Jun 16, 2012 at 10:06 PM, Stéphane Ducasse <[hidden email]> wrote:
They are :)
|
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Mariano Martinez Peck
We are closing the gap with Java versions... Pharo 1.6.3_047 nearing...
2012/6/16 Mariano Martinez Peck <[hidden email]>: > > > On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <[hidden email]> 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Mariano Martinez Peck
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 <[hidden email]>: > > > On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <[hidden email]> 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
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, [hidden email] <[hidden email]> wrote: http://en.wikipedia.org/wiki/Java_version_history isn't too bad either |
|
|
In reply to this post by Sean P. DeNigris
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... >> >> >> 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' > > 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 > > > |
Re: start thinking on summer release of Pharo 1.4
|
|
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 <[hidden email]>: > 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
|
|
In reply to this post by Ben Coman
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 |
Re: start thinking on summer release of Pharo 1.4
|
|
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 <[hidden email]>: > > 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by EstebanLM
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 <[hidden email]>: > > 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
PharoScreenshot.1.png (91K)
Re: 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. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |