pharo vision

> pg. 4
>        * "based on an integreation server" should be integration
>        * "test them and notify its results" should be "tests them and notifies its
> results"
>        * "We will also put in place another level of checks based on integration
> servers as well." -> To me this sentence adds nothing. Either explain more
> or remove it.
>        * "We will not do that for the sake of changing." I think you mean "We will
> not change for the sake of change."
>        * "expressing in a more com- pact form all kind of information" would be
> more clear as "expressing all kinds of information in a more compact form"
>        * "optimization at compiler level" -> "optimization at the compiler level"
>        * "Not only we want that people build" -> "Not only do we want people
> build"
> pg. 5
>        * "We want that both users and the system general quality, benefit from the
> best libraries." -> "We want both users and the general quality of the
> system to benefit from the best libraries."
>        * "we want to have validated packages running check rules and automated
> tests automatically validated." is unclear, but I don't understand it well
> enough to change it
>        * "*a* good interaction with the rest of the world" should be "good
> interaction with the rest of the world"
>        * "The list *if* not exhaustive but should allow *one* to structure the
> development effort." -> "The list is not exhaustive but should allow us to
> structure the development effort."
>        * "New IDES" -> "New IDEs"
>        * "but also new *way* of handling" -> "but also new ways of handling"
>        * "of new *kind* of IDEs, desktop metaphor and" -> "of new kinds of IDEs,
> desktop metaphor and:" (added colon at end, subsequent bullets are children)
> pg. 6
>        * "proved that it was worth." Sentence fragment, I'm not clear enough to
> fix it
>        * "and complex *applications*" -> "and complex application"
>        * "Obviously everybody prefer to use a fast library than a slow one. We
> should develop rule checking that include speed regression testing." ->
> "Obviously everybody prefers using a fast library over a slow one. We should
> develop rule checking that includes speed regression testing."
>        * "64 bits. For managing large amount of data" -> "64 bits. For managing a
> large amount of data"
>        * "Even if theoretically with a 32 bits VM we should be able to run images
> of at least 2 GBs, this is not the case of current available VMs. For
> example, the Windows VM does not support images bigger than 512 MB." ->
> "Although a 32 bit VM can theoretically run images of up to 2 GB, the
> currently available VMs are more limited. For example, the Windows VM does
> not support images bigger than 512 MB."
> pg. 7
>        * "Large applications" section is repeated
>        * "OpenSophie proved that Smalltalk and Squeak in particular, the ancestor
> of Pharo, are good platforms for building advanced multimedia applications.
> We believe that Pharo can be used in such situation." -> "OpenSophie proved
> that Smalltalk, and Squeak (Pharo's ancestor) in particular, are good
> platforms for building advanced multimedia applications. We believe that
> Pharo is well-suited for this."
>
> Sean
>
> --
> View this message in context: http://forum.world.st/pharo-vision-tp4340345p4341249.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

> On 30 January 2012 16:17, Sean P. DeNigris <[hidden email]> wrote:
>> Thanks Steph! This is much-needed to focus our community and avoid
>> unnecessary confusion and chatter.
>>
>> A few minor edits to Ch. 1:
>> pg. 1
>>        "curved in stone" should be carved
>
> No. It is now part of history. It is curved, not carved.
> There was a postings in mailing list somewhere, discussing that :))

>> pg. 4
>>        * "based on an integreation server" should be integration
>>        * "test them and notify its results" should be "tests them and notifies its
>> results"
>>        * "We will also put in place another level of checks based on integration
>> servers as well." -> To me this sentence adds nothing. Either explain more
>> or remove it.
>>        * "We will not do that for the sake of changing." I think you mean "We will
>> not change for the sake of change."
>>        * "expressing in a more com- pact form all kind of information" would be
>> more clear as "expressing all kinds of information in a more compact form"
>>        * "optimization at compiler level" -> "optimization at the compiler level"
>>        * "Not only we want that people build" -> "Not only do we want people
>> build"
>> pg. 5
>>        * "We want that both users and the system general quality, benefit from the
>> best libraries." -> "We want both users and the general quality of the
>> system to benefit from the best libraries."
>>        * "we want to have validated packages running check rules and automated
>> tests automatically validated." is unclear, but I don't understand it well
>> enough to change it
>>        * "*a* good interaction with the rest of the world" should be "good
>> interaction with the rest of the world"
>>        * "The list *if* not exhaustive but should allow *one* to structure the
>> development effort." -> "The list is not exhaustive but should allow us to
>> structure the development effort."
>>        * "New IDES" -> "New IDEs"
>>        * "but also new *way* of handling" -> "but also new ways of handling"
>>        * "of new *kind* of IDEs, desktop metaphor and" -> "of new kinds of IDEs,
>> desktop metaphor and:" (added colon at end, subsequent bullets are children)
>> pg. 6
>>        * "proved that it was worth." Sentence fragment, I'm not clear enough to
>> fix it
>>        * "and complex *applications*" -> "and complex application"
>>        * "Obviously everybody prefer to use a fast library than a slow one. We
>> should develop rule checking that include speed regression testing." ->
>> "Obviously everybody prefers using a fast library over a slow one. We should
>> develop rule checking that includes speed regression testing."
>>        * "64 bits. For managing large amount of data" -> "64 bits. For managing a
>> large amount of data"
>>        * "Even if theoretically with a 32 bits VM we should be able to run images
>> of at least 2 GBs, this is not the case of current available VMs. For
>> example, the Windows VM does not support images bigger than 512 MB." ->
>> "Although a 32 bit VM can theoretically run images of up to 2 GB, the
>> currently available VMs are more limited. For example, the Windows VM does
>> not support images bigger than 512 MB."
>> pg. 7
>>        * "Large applications" section is repeated
>>        * "OpenSophie proved that Smalltalk and Squeak in particular, the ancestor
>> of Pharo, are good platforms for building advanced multimedia applications.
>> We believe that Pharo can be used in such situation." -> "OpenSophie proved
>> that Smalltalk, and Squeak (Pharo's ancestor) in particular, are good
>> platforms for building advanced multimedia applications. We believe that
>> Pharo is well-suited for this."
>>
>> Sean
>>
>> --
>> View this message in context: http://forum.world.st/pharo-vision-tp4340345p4341249.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

> a comment on Mariano's comment:
> "I am not sure if Pharo could be the best language for security....the fact
> of being able to play as god goes in contrary to security also. I
> would let all this
> security stuff for the javascript guys.
> "
>
> in fact, straightly opposite.
> think in terms that you want to develop/model/research a secure system
> on top of Pharo.
> And you're a God, of course, and you should be able to do that, and
> Pharo should help you investigating your problem space.
> Now, if pharo is underpowered, so you as well, and then you leave
> "security stuff for the javascript guys."
> :)
>
> --
> Best regards,
> Igor Stasenko.
>

> a little digression here: nobody knows that steps towards systems security is needed and always welcome, even more in this internet days... but I always found that by "security", most security systems are being constructed against the programmers, not against the possible violations. IMHO, things like "don't touch this class behavior", as a way to ensure system security is oppressive, and is against the paradigm enforced by smalltalk.
> I don't think a programmer should be in a jail to program secure things... when we (pharoers) start this task, please, please, take this into account.
>
> yep... always someone mentions security, I run to see if my rights are being violated :P
>
> best,
> Esteban
>
> El 30/01/2012, a las 12:45p.m., Igor Stasenko escribió:
>
>> a comment on Mariano's comment:
>> "I am not sure if Pharo could be the best language for security....the fact
>> of being able to play as god goes in contrary to security also. I
>> would let all this
>> security stuff for the javascript guys.
>> "
>>
>> in fact, straightly opposite.
>> think in terms that you want to develop/model/research a secure system
>> on top of Pharo.
>> And you're a God, of course, and you should be able to do that, and
>> Pharo should help you investigating your problem space.
>> Now, if pharo is underpowered, so you as well, and then you leave
>> "security stuff for the javascript guys."
>> :)
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>

> best,
> Esteban
>
> El 30/01/2012, a las 12:45p.m., Igor Stasenko escribió:
>
>> a comment on Mariano's comment:
>> "I am not sure if Pharo could be the best language for security....the fact
>> of being able to play as god goes in contrary to security also. I
>> would let all this
>> security stuff for the javascript guys.
>> "
>>
>> in fact, straightly opposite.
>> think in terms that you want to develop/model/research a secure system
>> on top of Pharo.
>> And you're a God, of course, and you should be able to do that, and
>> Pharo should help you investigating your problem space.
>> Now, if pharo is underpowered, so you as well, and then you leave
>> "security stuff for the javascript guys."
>> :)
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>

>
> On Jan 30, 2012, at 9:24 14AM, Stéphane Ducasse wrote:
>
> <main.pdf>
>
> Nice!
>
> Some comments on the parts I'm most familiar with:
> 3.2
> I agree, the nice parts in FS to me is the path manipulation API.
> Going back to pure ANSI-streams as provided by FSFileStream is not really an
> option.
> Since it's a clean break from FileDirectory & friends though, it might be
> the perfect time to introduce XTreams; -or it might be too much hassle to
> have to change both parts in existing code at once.
>
> A good compromise would be to make it pluggable, using the existing
> Standard/MultiByteFileStreams by default, but making XStreams pluggable (on
> a use--by-use basis, so you can write new code with XStreams while
> maintaining old code where you have only had time to rewrite the path
> handling)
>
> 3.3
> "Using ephemerons we can then simplify the Announcement and make sure that
> clients do not have to worry about weak or not registration."
> You still have to worry about whether you want weak or strong registration.
> "Do I have strict requirements for when the announcement should stop being
> delivered in relation to subscriber lifespan?" is still a valid question.
> What you don't have to worry about, is what _type_ of subscription (action
> blocks or message sends), you are allowed to use when registering weakly.
>
> Ends with "In addition, " then nothing :)
>
> Cheers,
> Henry

>
> A few minor edits to Ch. 1:
> pg. 1
> "curved in stone" should be carved
> pg. 4
> * "based on an integreation server" should be integration
> * "test them and notify its results" should be "tests them and notifies its
> results"
> * "We will also put in place another level of checks based on integration
> servers as well." -> To me this sentence adds nothing. Either explain more
> or remove it.
> * "We will not do that for the sake of changing." I think you mean "We will
> not change for the sake of change."
> * "expressing in a more com- pact form all kind of information" would be
> more clear as "expressing all kinds of information in a more compact form"
> * "optimization at compiler level" -> "optimization at the compiler level"
> * "Not only we want that people build" -> "Not only do we want people
> build"
> pg. 5
> * "We want that both users and the system general quality, benefit from the
> best libraries." -> "We want both users and the general quality of the
> system to benefit from the best libraries."
> * "we want to have validated packages running check rules and automated
> tests automatically validated." is unclear, but I don't understand it well
> enough to change it
> * "*a* good interaction with the rest of the world" should be "good
> interaction with the rest of the world"
> * "The list *if* not exhaustive but should allow *one* to structure the
> development effort." -> "The list is not exhaustive but should allow us to
> structure the development effort."
> * "New IDES" -> "New IDEs"
> * "but also new *way* of handling" -> "but also new ways of handling"
> * "of new *kind* of IDEs, desktop metaphor and" -> "of new kinds of IDEs,
> desktop metaphor and:" (added colon at end, subsequent bullets are children)
> pg. 6
> * "proved that it was worth." Sentence fragment, I'm not clear enough to
> fix it
> * "and complex *applications*" -> "and complex application"
> * "Obviously everybody prefer to use a fast library than a slow one. We
> should develop rule checking that include speed regression testing." ->
> "Obviously everybody prefers using a fast library over a slow one. We should
> develop rule checking that includes speed regression testing."
> * "64 bits. For managing large amount of data" -> "64 bits. For managing a
> large amount of data"
> * "Even if theoretically with a 32 bits VM we should be able to run images
> of at least 2 GBs, this is not the case of current available VMs. For
> example, the Windows VM does not support images bigger than 512 MB." ->
> "Although a 32 bit VM can theoretically run images of up to 2 GB, the
> currently available VMs are more limited. For example, the Windows VM does
> not support images bigger than 512 MB."
> pg. 7
> * "Large applications" section is repeated
> * "OpenSophie proved that Smalltalk and Squeak in particular, the ancestor
> of Pharo, are good platforms for building advanced multimedia applications.
> We believe that Pharo can be used in such situation." -> "OpenSophie proved
> that Smalltalk, and Squeak (Pharo's ancestor) in particular, are good
> platforms for building advanced multimedia applications. We believe that
> Pharo is well-suited for this."
>
> Sean
>
> --
> View this message in context: http://forum.world.st/pharo-vision-tp4340345p4341249.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

> Thanks stef for this . The document informed me  of things I was not aware of and now after reading it I like Pharo even more .
>
> From: Henrik Johansen <[hidden email]>
> To: [hidden email]
> Sent: Monday, 30 January 2012, 18:10
> Subject: Re: [Pharo-project] pharo vision
>
>
> On Jan 30, 2012, at 9:24 14AM, Stéphane Ducasse wrote:
>
>> <main.pdf>
> Nice!
>
> Some comments on the parts I'm most familiar with:
> 3.2
> I agree, the nice parts in FS to me is the path manipulation API.
> Going back to pure ANSI-streams as provided by FSFileStream is not really an option.
> Since it's a clean break from FileDirectory & friends though, it might be the perfect time to introduce XTreams; -or it might be too much hassle to have to change both parts in existing code at once.
>
> A good compromise would be to make it pluggable, using the existing Standard/MultiByteFileStreams by default, but making XStreams pluggable (on a use--by-use basis, so you can write new code with XStreams while maintaining old code where you have only had time to rewrite the path handling)
>
> 3.3
> "Using ephemerons we can then simplify the Announcement and make sure that clients do not have to worry about weak or not registration."
> You still have to worry about whether you want weak or strong registration.
> "Do I have strict requirements for when the announcement should stop being delivered in relation to subscriber lifespan?" is still a valid question.
> What you don't have to worry about, is what _type_ of subscription (action blocks or message sends), you are allowed to use when registering weakly.
>
> Ends with "In addition, " then nothing :)
>
> Cheers,
> Henry
>
>

> On 30 January 2012 15:34, Igor Stasenko <[hidden email]> wrote:
>> On 30 January 2012 16:17, Sean P. DeNigris <[hidden email]> wrote:
>>> Thanks Steph! This is much-needed to focus our community and avoid
>>> unnecessary confusion and chatter.
>>>
>>> A few minor edits to Ch. 1:
>>> pg. 1
>>>        "curved in stone" should be carved
>>
>> No. It is now part of history. It is curved, not carved.
>> There was a postings in mailing list somewhere, discussing that :))
>
> Sean's right. There is no English idiom like "curved in stone".
> "Curved in stone" makes no sense.
>

> frank
>
>>> pg. 4
>>>        * "based on an integreation server" should be integration
>>>        * "test them and notify its results" should be "tests them and notifies its
>>> results"
>>>        * "We will also put in place another level of checks based on integration
>>> servers as well." -> To me this sentence adds nothing. Either explain more
>>> or remove it.
>>>        * "We will not do that for the sake of changing." I think you mean "We will
>>> not change for the sake of change."
>>>        * "expressing in a more com- pact form all kind of information" would be
>>> more clear as "expressing all kinds of information in a more compact form"
>>>        * "optimization at compiler level" -> "optimization at the compiler level"
>>>        * "Not only we want that people build" -> "Not only do we want people
>>> build"
>>> pg. 5
>>>        * "We want that both users and the system general quality, benefit from the
>>> best libraries." -> "We want both users and the general quality of the
>>> system to benefit from the best libraries."
>>>        * "we want to have validated packages running check rules and automated
>>> tests automatically validated." is unclear, but I don't understand it well
>>> enough to change it
>>>        * "*a* good interaction with the rest of the world" should be "good
>>> interaction with the rest of the world"
>>>        * "The list *if* not exhaustive but should allow *one* to structure the
>>> development effort." -> "The list is not exhaustive but should allow us to
>>> structure the development effort."
>>>        * "New IDES" -> "New IDEs"
>>>        * "but also new *way* of handling" -> "but also new ways of handling"
>>>        * "of new *kind* of IDEs, desktop metaphor and" -> "of new kinds of IDEs,
>>> desktop metaphor and:" (added colon at end, subsequent bullets are children)
>>> pg. 6
>>>        * "proved that it was worth." Sentence fragment, I'm not clear enough to
>>> fix it
>>>        * "and complex *applications*" -> "and complex application"
>>>        * "Obviously everybody prefer to use a fast library than a slow one. We
>>> should develop rule checking that include speed regression testing." ->
>>> "Obviously everybody prefers using a fast library over a slow one. We should
>>> develop rule checking that includes speed regression testing."
>>>        * "64 bits. For managing large amount of data" -> "64 bits. For managing a
>>> large amount of data"
>>>        * "Even if theoretically with a 32 bits VM we should be able to run images
>>> of at least 2 GBs, this is not the case of current available VMs. For
>>> example, the Windows VM does not support images bigger than 512 MB." ->
>>> "Although a 32 bit VM can theoretically run images of up to 2 GB, the
>>> currently available VMs are more limited. For example, the Windows VM does
>>> not support images bigger than 512 MB."
>>> pg. 7
>>>        * "Large applications" section is repeated
>>>        * "OpenSophie proved that Smalltalk and Squeak in particular, the ancestor
>>> of Pharo, are good platforms for building advanced multimedia applications.
>>> We believe that Pharo can be used in such situation." -> "OpenSophie proved
>>> that Smalltalk, and Squeak (Pharo's ancestor) in particular, are good
>>> platforms for building advanced multimedia applications. We believe that
>>> Pharo is well-suited for this."
>>>
>>> Sean
>>>
>>> --
>>> View this message in context: http://forum.world.st/pharo-vision-tp4340345p4341249.html
>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>

>
> On Jan 30, 2012, at 9:24 14AM, Stéphane Ducasse wrote:
>
>> <main.pdf>
> Nice!
>
> Some comments on the parts I'm most familiar with:
> 3.2
> I agree, the nice parts in FS to me is the path manipulation API.
> Going back to pure ANSI-streams as provided by FSFileStream is not really an option.