"Large applications" chapter on pages 6/7 is repeated twice. -- Milan Mimica http://sparklet.sf.net
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 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 <sean@clipperadams.com> 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.
On Mon, Jan 30, 2012 at 4:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
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." :)
Good point :) -- Mariano http://marianopeck.wordpress.com
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.
errrr.... nobody knows must be read as "nobody doubts" :P El 30/01/2012, a las 1:06p.m., Esteban Lorenzano escribió:
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.
On 30 January 2012 16:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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
And you can't even start addressing security until you have a threat model against which to secure! frank
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 30 January 2012 15:34, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 January 2012 16:17, Sean P. DeNigris <sean@clipperadams.com> 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 30 January 2012 18:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 January 2012 15:34, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 January 2012 16:17, Sean P. DeNigris <sean@clipperadams.com> 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.
Let me turn it like that: it makes sense exactly because it doesn't makes sense. This idiom were invented by Stephane, and part of our history now :)
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.
-- Best regards, Igor Stasenko.
On Jan 30, 2012, at 4:17 PM, Sean P. DeNigris wrote:
Thanks Steph! This is much-needed to focus our community and avoid unnecessary confusion and chatter.
You got my message :) Thanks for the copy edit. Stef
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.
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
I think the best option with Xtreams (http://code.google.com/p/xtreams/ ) is to rewrite client code. This is why the designers have chosen a set of new selectors. If we think it's time to remove some cruft, but still have late client adopters, we could also write a wrapper providing old Stream API in Xtreams Something like: 'foo' reading withStreamAPI Then replace ReadStream/WriteStream with such factory... Of course, replicating the whole zoo of specialized selectors of current Stream library is not an option IMO. Nicolas 2012/1/30 Henrik Johansen <henrik.s.johansen@veloxit.no>:
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 Jan 30, 2012, at 5:27 PM, Nicolas Cellier wrote:
I think the best option with Xtreams (http://code.google.com/p/xtreams/ ) is to rewrite client code. This is why the designers have chosen a set of new selectors.
If we think it's time to remove some cruft, but still have late client adopters, we could also write a wrapper providing old Stream API in Xtreams Something like:
'foo' reading withStreamAPI
Then replace ReadStream/WriteStream with such factory...
Of course, replicating the whole zoo of specialized selectors of current Stream library is not an option IMO.
Nicolas
Nicolas my main concern is - we got documentation for Streams and I would like it got adapted. - lack of manpower but if somebody would drive this effort I would survive and accept Xstreams (even if I have some doubts on the API) The document is also to build a common roadmap on which we can gather energy and effort to get some real momentum. This document is to show the vision we got since long time and that we were not able to share. Stef
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 <henrik.s.johansen@veloxit.no> To: Pharo-project@lists.gforge.inria.fr 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
Thanks in fact I wanted to send it to the mailing list of our team because I wanted to gather feedback before sending it to the mailing-list to ask for another set of feedback. So I will finish it now :) Stef On Jan 30, 2012, at 5:46 PM, dimitris chloupis wrote:
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 <henrik.s.johansen@veloxit.no> To: Pharo-project@lists.gforge.inria.fr 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 Jan 30, 2012, at 5:10 PM, Henrik Johansen wrote:
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.
Can you elaborate on your previous sentence? Because the underlying reason is not 100% clear to me.
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.
Yes this is what I wanted to write :) Fixed it.
Ends with "In addition, " then nothing :)
:) Fixed :)
Cheers, Henry
On 30.01.2012 23:02, Stéphane Ducasse wrote:
On Jan 30, 2012, at 5:10 PM, Henrik Johansen wrote:
Going back to pure ANSI-streams as provided by FSFileStream is not really an option. Can you elaborate on your previous sentence? Because the underlying reason is not 100% clear to me. FSFileStreams are pure ansi-protocol compliant streams. No buffering, no optimization, strange concoction of the underlying primitives (like Nicolas mentioned, always pairing seek and read), no "built-in" way to translate using encodings, no other bells, no whistles.
Creating such streams from the FSPath stream creation API makes little to no sense, lest the goal is to provide a simple API for accessing streams in a cross-platform manner, in which case I guess you'd leave the rest of the work to other non-ansi, but cross-platform libraries. Cheers, Henry
excellent! On Jan 30, 2012, at 11:48 PM, Henrik Sperre Johansen wrote:
On 30.01.2012 23:02, Stéphane Ducasse wrote:
On Jan 30, 2012, at 5:10 PM, Henrik Johansen wrote:
Going back to pure ANSI-streams as provided by FSFileStream is not really an option. Can you elaborate on your previous sentence? Because the underlying reason is not 100% clear to me. FSFileStreams are pure ansi-protocol compliant streams. No buffering, no optimization, strange concoction of the underlying primitives (like Nicolas mentioned, always pairing seek and read), no "built-in" way to translate using encodings, no other bells, no whistles.
Creating such streams from the FSPath stream creation API makes little to no sense, lest the goal is to provide a simple API for accessing streams in a cross-platform manner, in which case I guess you'd leave the rest of the work to other non-ansi, but cross-platform libraries.
Cheers, Henry
On Mon, Jan 30, 2012 at 3:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Thank you for this nice vision. I think "Language and Remote IDEs for small devices" and "robotics" could be merge in the same section about "embedded system", because they share more or less the same concerns: small kernel, C/C++ integration, headless system, reliable networking support, remote debugging, customizable real-time gc, ... Having the possibility of mixing several domain-specific languages is also quite interesting in robotics, see for the example the recent series of workshop i organize recently: http://www.doesnotunderstand.org/wikka.php?wakka=DSLRob11 I try to push Smalltalk use in robotics in several projects: 1) SqueakBot (http://wiki.laptop.org/go/Projects/SqueakBot) 2) PlayerST to control Player/Stage robotic simulation (http://www1.ifi.auf.org/mediawiki/index.php/Smalltalk_Player_Client) 3) ROSTalk to connect Smalltalk and ROS (https://github.com/SergeStinckwich/rostalk) but this is still difficult because most of the robotic stuff are written in C/C++ and also the lack of manpower ... It's easier at the moment to use Python or Lua for robots than Smalltalk. Look here: https://github.com/timn/roslua Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Thanks serge I do not know how to help. Now I hope that a small kernel will help. I hope to allocate some time and ben will work three months on it again. Stef On Jan 30, 2012, at 5:24 PM, Serge Stinckwich wrote:
On Mon, Jan 30, 2012 at 3:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Thank you for this nice vision.
I think "Language and Remote IDEs for small devices" and "robotics" could be merge in the same section about "embedded system", because they share more or less the same concerns: small kernel, C/C++ integration, headless system, reliable networking support, remote debugging, customizable real-time gc, ... Having the possibility of mixing several domain-specific languages is also quite interesting in robotics, see for the example the recent series of workshop i organize recently: http://www.doesnotunderstand.org/wikka.php?wakka=DSLRob11 I try to push Smalltalk use in robotics in several projects: 1) SqueakBot (http://wiki.laptop.org/go/Projects/SqueakBot) 2) PlayerST to control Player/Stage robotic simulation (http://www1.ifi.auf.org/mediawiki/index.php/Smalltalk_Player_Client) 3) ROSTalk to connect Smalltalk and ROS (https://github.com/SergeStinckwich/rostalk) but this is still difficult because most of the robotic stuff are written in C/C++ and also the lack of manpower ... It's easier at the moment to use Python or Lua for robots than Smalltalk. Look here: https://github.com/timn/roslua Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Serge, Am 30.01.2012 um 17:24 schrieb Serge Stinckwich:
On Mon, Jan 30, 2012 at 3:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Thank you for this nice vision.
Indeed, thanks, Steph et al.
I think "Language and Remote IDEs for small devices" and "robotics" could be merge in the same section about "embedded system", because they share more or less the same concerns: small kernel, C/C++ integration, headless system, reliable networking support, remote debugging, customizable real-time gc, ... Having the possibility of mixing several domain-specific languages is also quite interesting in robotics, see for the example the recent series of workshop i organize recently: http://www.doesnotunderstand.org/wikka.php?wakka=DSLRob11 I try to push Smalltalk use in robotics in several projects: 1) SqueakBot (http://wiki.laptop.org/go/Projects/SqueakBot) 2) PlayerST to control Player/Stage robotic simulation (http://www1.ifi.auf.org/mediawiki/index.php/Smalltalk_Player_Client) 3) ROSTalk to connect Smalltalk and ROS (https://github.com/SergeStinckwich/rostalk) but this is still difficult because most of the robotic stuff are written in C/C++ and also the lack of manpower ... It's easier at the moment to use Python or Lua for robots than Smalltalk. Look here: https://github.com/timn/roslua
Basically I think you are right that embedded systems are comparable. But there are still two different sizes of computers addressed. The plug computer mentioned is a full capable server computer just without a display. You can use VNC and such easily there because they have enough power and memory (of course a remote ide is way cooler and more powerful). For this size I find it more important to have FFI and JIT for ARM in place to utilize the machine. There is still a kind of machines that have real limited resources and for this it would be necessary to have a tiny core and a remote IDE connection to actively modify the system. If this kind of computers is targetted then it will be a big challenge for the pharo core. If the core is not capable of operating with less resources then I think it'll be hard to achieve much on this platform. Norbert
Stef, I've sent some markup directly, some additional ideas - perhaps only for later and/or more of a library than core functionality. Improved printing subsystem - by which I mean PDF output. Business proposition: Without good PDFs many contemporary business practices are curtailed. For example, multi-page reporting charts being emailed to external clients. Running multiple images on one VM with copy-on-write shared memory. Business proposition: To allow more images (owned by different clients) to be run (presumably) with less resources on resource limited web server platforms. cheers, Ben
On Jan 31, 2012, at 5:13 PM, Ben Coman wrote:
Stef,
I've sent some markup directly, some additional ideas - perhaps only for later and/or more of a library than core functionality.
Improved printing subsystem - by which I mean PDF output. Business proposition: Without good PDFs many contemporary business practices are curtailed. For example, multi-page reporting charts being emailed to external clients.
Are you aware of the open-source library of Christian Haider?
Running multiple images on one VM with copy-on-write shared memory. Business proposition: To allow more images (owned by different clients) to be run (presumably) with less resources on resource limited web server platforms.
Yes we were thinking about that in Objectspaces but Gwenael never delivered (nor talk to us for real during 3 years - his disaster).
cheers, Ben
It took some hunting but I finally found the source located here... http://pdf4smalltalk.origo.ethz.ch/wiki/store_access with MIT License specified here... http://pdf4smalltalk.origo.ethz.ch/ That looks quite promising. cheers, Ben Stéphane Ducasse wrote:
On Jan 31, 2012, at 5:13 PM, Ben Coman wrote:
Stef,
I've sent some markup directly, some additional ideas - perhaps only for later and/or more of a library than core functionality.
Improved printing subsystem - by which I mean PDF output. Business proposition: Without good PDFs many contemporary business practices are curtailed. For example, multi-page reporting charts being emailed to external clients.
Are you aware of the open-source library of Christian Haider?
Running multiple images on one VM with copy-on-write shared memory. Business proposition: To allow more images (owned by different clients) to be run (presumably) with less resources on resource limited web server platforms.
Additionally why not look at using XMLRPC bridge to do Jasper Reports.. or even CrystalReports.. Of course this will require little bit of backend work on a Groovy / Ruby/ Python or Webservice link to JasperServer.. if its commercial.. or Ruby for its fairly workable pdf writer.. Great though to have a fully functional pdf writer in Smalltalk/ Pharo. On 2/1/12, Ben Coman <btc@openinworld.com> wrote:
It took some hunting but I finally found the source located here... http://pdf4smalltalk.origo.ethz.ch/wiki/store_access
with MIT License specified here... http://pdf4smalltalk.origo.ethz.ch/
That looks quite promising.
cheers, Ben
Stéphane Ducasse wrote:
On Jan 31, 2012, at 5:13 PM, Ben Coman wrote:
Stef,
I've sent some markup directly, some additional ideas - perhaps only for later and/or more of a library than core functionality.
Improved printing subsystem - by which I mean PDF output. Business proposition: Without good PDFs many contemporary business practices are curtailed. For example, multi-page reporting charts being emailed to external clients.
Are you aware of the open-source library of Christian Haider?
Running multiple images on one VM with copy-on-write shared memory. Business proposition: To allow more images (owned by different clients) to be run (presumably) with less resources on resource limited web server platforms.
Hi, I'm using libharu with HPDF and is going well... maybe we can build a better smalltalk-side package (HPDF is good, but basic) and rely on an existing library, instead reinvent the wheel this time :) best, Esteban El 01/02/2012, a las 1:22p.m., S Krish escribió:
Additionally why not look at using XMLRPC bridge to do Jasper Reports.. or even CrystalReports..
Of course this will require little bit of backend work on a Groovy / Ruby/ Python
or Webservice link to JasperServer.. if its commercial..
or Ruby for its fairly workable pdf writer..
Great though to have a fully functional pdf writer in Smalltalk/ Pharo.
On 2/1/12, Ben Coman <btc@openinworld.com> wrote:
It took some hunting but I finally found the source located here... http://pdf4smalltalk.origo.ethz.ch/wiki/store_access
with MIT License specified here... http://pdf4smalltalk.origo.ethz.ch/
That looks quite promising.
cheers, Ben
Stéphane Ducasse wrote:
On Jan 31, 2012, at 5:13 PM, Ben Coman wrote:
Stef,
I've sent some markup directly, some additional ideas - perhaps only for later and/or more of a library than core functionality.
Improved printing subsystem - by which I mean PDF output. Business proposition: Without good PDFs many contemporary business practices are curtailed. For example, multi-page reporting charts being emailed to external clients.
Are you aware of the open-source library of Christian Haider?
Running multiple images on one VM with copy-on-write shared memory. Business proposition: To allow more images (owned by different clients) to be run (presumably) with less resources on resource limited web server platforms.
Just wanted to make sure you guys were aware that Bob Nemec is making a PDFReport package for VisualWorks that he intends to present at STIC and port to other smalltalks: http://smalltalk-bob.blogspot.com/2012/01/pdf-report-and-law-of-demeter.html So maybe there's an opportunity for collaboration. Ben Coman wrote
It took some hunting but I finally found the source located here... http://pdf4smalltalk.origo.ethz.ch/wiki/store_access
with MIT License specified here... http://pdf4smalltalk.origo.ethz.ch/
That looks quite promising.
cheers, Ben
-- View this message in context: http://forum.world.st/pharo-vision-tp4340345p4352946.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 02/02/12 4:50 PM, Paul DeBruicker wrote:
Just wanted to make sure you guys were aware that Bob Nemec is making a PDFReport package for VisualWorks that he intends to present at STIC and port to other smalltalks:
http://smalltalk-bob.blogspot.com/2012/01/pdf-report-and-law-of-demeter.html
So maybe there's an opportunity for collaboration.
Bob's stuff is a "report" framework (i.e. print tables and headings nicely, etc.) that uses Christian Haider's PDF framework on VW. So the PDF stuff would still need to be ported to Pharo.
On Feb 2, 2012, at 10:50 PM, Paul DeBruicker wrote:
Just wanted to make sure you guys were aware that Bob Nemec is making a PDFReport package for VisualWorks that he intends to present at STIC and port to other smalltalks:
http://smalltalk-bob.blogspot.com/2012/01/pdf-report-and-law-of-demeter.html
So maybe there's an opportunity for collaboration.
Yes the pharo community should be interested. Now our local plates are rather full. I should say that I regularly pushed christian to open source his project. Stef
Ben Coman wrote
It took some hunting but I finally found the source located here... http://pdf4smalltalk.origo.ethz.ch/wiki/store_access
with MIT License specified here... http://pdf4smalltalk.origo.ethz.ch/
That looks quite promising.
cheers, Ben
-- View this message in context: http://forum.world.st/pharo-vision-tp4340345p4352946.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 30.01.2012 09:24, Stéphane Ducasse wrote: OK, so here's my take. I try to not turn this into a wish list. Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo. FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? "portable plugins"? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me. 64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs. 64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit. 64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images. SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things. Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo. Load balancer I don't think this needs to be part of Pharo. Apache already does this. UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/⦠This is not giving up. This is not fighting battles you cannot win. Plug Computer Really? You have all the other places that need more resources and you want to do even more. Now the things that aren't on your list: VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring. #identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time. Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well. Migration Support Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers. Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable. [1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%2... [2] http://wiki.eclipse.org/Simultaneous_Release [3] http://wiki.eclipse.org/SimRel/Overview Cheers Philippe
thanks Philippe. I worked more on the document but I will integrate your ideas in it and will send it again. Stef On Feb 5, 2012, at 6:43 PM, Philippe Marschall wrote:
On 30.01.2012 09:24, Stéphane Ducasse wrote:
OK, so here's my take. I try to not turn this into a wish list.
Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo.
FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? "portable plugins"? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me.
64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs.
64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit.
64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images.
SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things.
Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo.
Load balancer I don't think this needs to be part of Pharo. Apache already does this.
UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/⦠This is not giving up. This is not fighting battles you cannot win.
Plug Computer Really? You have all the other places that need more resources and you want to do even more.
Now the things that aren't on your list:
VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring.
#identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time.
Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well.
Migration Support Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers.
Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable.
[1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%2... [2] http://wiki.eclipse.org/Simultaneous_Release [3] http://wiki.eclipse.org/SimRel/Overview
Cheers Philippe
My two cents: Pharo Roadmap: Should be a clean, basic kernel, rockstable, IDE that is guaranteed to work most efficiently with its base library, compiler. Perfect and simplest kernel. I do consider a perfect FFI, Collections, Streams ( including File/ Socket ), String, Graphics, UI widget/canvas library as base and some more that are basics. FFI that is non-blocking/ callback supported through all major platforms. Optimization for all the collections hierarchy, clean FS including networking support, cleaner , Morphic widgets.. The IDE that works and never crashes for all newbie interactions, that should be glitch free and offer failsafe error handlers at the image level if something does go wrong to handle it cleanly... Rest everything is secondary or even tertiary at this point. Source Code mgmt: this is an important top level package, ideal if its an external package. No other platform comes loaded with an IDE, debugger, source code mgmt as default.. It is the base kernel + IDE + external pacakges.. Gives options to uses in future to switch between MC/ Git/ SVN as they may want it to be without the noise/ extras. Rich libraries Seriously should we be reinventing the wheel, unless there is luxury in future to do so. Reusing all that we can from all other platfoms: C libs, Java, Ruby, Python.. etc.. is perfectly fine. For turtles down the line, we should simply have any contributor give an interface package for minimal and extensible connection to say: Reports, DBMS, ... etc using something that works viz: C interfaces, XMLRPC ( SOAP aint the best..!) and perhaps some other custom connector through plugin mechanism as is done for DBXSqueak... UI frameworks: This too should remain an outside package not built in.. there can be many lines of thought and processes.. and each one completely acceptable from their usage/ view standpoint.. Usable Pharo base : ( Base: Excellent Kernel + Morphic ) + Source Code Mgmt Package Usable Pharo Web : Pharo Base + Seaside Make a separate workspace/ area for Pharo Foundation supported / approved secondary package, so that download from there is more guaranteed than other user contributed areas/ projects people host/ support on their own. On Sun, Feb 5, 2012 at 11:13 PM, Philippe Marschall <kustos@gmx.net> wrote:
On 30.01.2012 09:24, Stéphane Ducasse wrote:
OK, so here's my take. I try to not turn this into a wish list.
Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo.
FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? "portable plugins"? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me.
64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs.
64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit.
64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images.
SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things.
Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo.
Load balancer I don't think this needs to be part of Pharo. Apache already does this.
UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/⦠This is not giving up. This is not fighting battles you cannot win.
Plug Computer Really? You have all the other places that need more resources and you want to do even more.
Now the things that aren't on your list:
VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring.
#identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time.
Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well.
Migration Support Since you're changing quite a lot of things (SystemDictionary/**SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers.
Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable.
[1] http://www.innoq.com/soa/ws-**standards/poster/innoQ%20WS-** Standards%20Poster%202007-02.**pdf<http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%2...> [2] http://wiki.eclipse.org/**Simultaneous_Release<http://wiki.eclipse.org/Simultaneous_Release> [3] http://wiki.eclipse.org/**SimRel/Overview<http://wiki.eclipse.org/SimRel/Overview>
Cheers Philippe
This is sounding pretty good. When can we have it? :) One thing: re-using existing libraries and tools is generally a good thing (GSL PLplot, gnuplot, etc. are powerful), but *sometimes* one is better off rewriting to gain flexibility or some other freedom. Maybe it is mostly a Windows thing, but I recall becoming radically happier when I ditched MS' http "technology" for something that just did some text transfer and actually, W*O*R*K*E*D. Between thread affinities, completely uninspired error handling/recovery, and generally stupid design, the MS code was more trouble than it was worth. It was "intertwingled" with Internet Explorer in ways that were simply not healthy... We should be able to reinvent or reuse with equal smoothness, and do the right thing in each case. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of S Krish [krishnamachari.sudhakar@gmail.com] Sent: Monday, February 06, 2012 12:31 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] pharo vision My two cents: Pharo Roadmap: Should be a clean, basic kernel, rockstable, IDE that is guaranteed to work most efficiently with its base library, compiler. Perfect and simplest kernel. I do consider a perfect FFI, Collections, Streams ( including File/ Socket ), String, Graphics, UI widget/canvas library as base and some more that are basics. FFI that is non-blocking/ callback supported through all major platforms. Optimization for all the collections hierarchy, clean FS including networking support, cleaner , Morphic widgets.. The IDE that works and never crashes for all newbie interactions, that should be glitch free and offer failsafe error handlers at the image level if something does go wrong to handle it cleanly... Rest everything is secondary or even tertiary at this point. Source Code mgmt: this is an important top level package, ideal if its an external package. No other platform comes loaded with an IDE, debugger, source code mgmt as default.. It is the base kernel + IDE + external pacakges.. Gives options to uses in future to switch between MC/ Git/ SVN as they may want it to be without the noise/ extras. Rich libraries Seriously should we be reinventing the wheel, unless there is luxury in future to do so. Reusing all that we can from all other platfoms: C libs, Java, Ruby, Python.. etc.. is perfectly fine. For turtles down the line, we should simply have any contributor give an interface package for minimal and extensible connection to say: Reports, DBMS, ... etc using something that works viz: C interfaces, XMLRPC ( SOAP aint the best..!) and perhaps some other custom connector through plugin mechanism as is done for DBXSqueak... UI frameworks: This too should remain an outside package not built in.. there can be many lines of thought and processes.. and each one completely acceptable from their usage/ view standpoint.. Usable Pharo base : ( Base: Excellent Kernel + Morphic ) + Source Code Mgmt Package Usable Pharo Web : Pharo Base + Seaside Make a separate workspace/ area for Pharo Foundation supported / approved secondary package, so that download from there is more guaranteed than other user contributed areas/ projects people host/ support on their own. On Sun, Feb 5, 2012 at 11:13 PM, Philippe Marschall <kustos@gmx.net<mailto:kustos@gmx.net>> wrote: On 30.01.2012 09:24, Stéphane Ducasse wrote: OK, so here's my take. I try to not turn this into a wish list. Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo. FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? "portable plugins"? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me. 64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs. 64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit. 64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images. SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things. Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo. Load balancer I don't think this needs to be part of Pharo. Apache already does this. UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/⦠This is not giving up. This is not fighting battles you cannot win. Plug Computer Really? You have all the other places that need more resources and you want to do even more. Now the things that aren't on your list: VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring. #identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time. Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well. Migration Support Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers. Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable. [1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%2... [2] http://wiki.eclipse.org/Simultaneous_Release [3] http://wiki.eclipse.org/SimRel/Overview Cheers Philippe
Obligatory.... You mis-understand the purpose of Microsoft's libraries, which is to suck up several years of potentially competing developer resources before Microsoft change the game by throwing everything away so you are playing catch up again. -ben Schwab,Wilhelm K wrote:
This is sounding pretty good. When can we have it? :)
One thing: re-using existing libraries and tools is generally a good thing (GSL PLplot, gnuplot, etc. are powerful), but *sometimes* one is better off rewriting to gain flexibility or some other freedom.
Maybe it is mostly a Windows thing, but I recall becoming radically happier when I ditched MS' http "technology" for something that just did some text transfer and actually, W*O*R*K*E*D. Between thread affinities, completely uninspired error handling/recovery, and generally stupid design, the MS code was more trouble than it was worth. It was "intertwingled" with Internet Explorer in ways that were simply not healthy...
We should be able to reinvent or reuse with equal smoothness, and do the right thing in each case.
Bill
________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of S Krish [krishnamachari.sudhakar@gmail.com] Sent: Monday, February 06, 2012 12:31 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] pharo vision
My two cents:
Pharo Roadmap:
Should be a clean, basic kernel, rockstable, IDE that is guaranteed to work most efficiently with its base library, compiler. Perfect and simplest kernel. I do consider a perfect FFI, Collections, Streams ( including File/ Socket ), String, Graphics, UI widget/canvas library as base and some more that are basics. FFI that is non-blocking/ callback supported through all major platforms.
Optimization for all the collections hierarchy, clean FS including networking support, cleaner , Morphic widgets..
The IDE that works and never crashes for all newbie interactions, that should be glitch free and offer failsafe error handlers at the image level if something does go wrong to handle it cleanly...
Rest everything is secondary or even tertiary at this point.
Source Code mgmt:
this is an important top level package, ideal if its an external package. No other platform comes loaded with an IDE, debugger, source code mgmt as default.. It is the base kernel + IDE + external pacakges..
Gives options to uses in future to switch between MC/ Git/ SVN as they may want it to be without the noise/ extras.
Rich libraries
Seriously should we be reinventing the wheel, unless there is luxury in future to do so. Reusing all that we can from all other platfoms: C libs, Java, Ruby, Python.. etc.. is perfectly fine. For turtles down the line, we should simply have any contributor give an interface package for minimal and extensible connection to say: Reports, DBMS, ... etc using something that works viz: C interfaces, XMLRPC ( SOAP aint the best..!) and perhaps some other custom connector through plugin mechanism as is done for DBXSqueak...
UI frameworks:
This too should remain an outside package not built in.. there can be many lines of thought and processes.. and each one completely acceptable from their usage/ view standpoint..
Usable Pharo base : ( Base: Excellent Kernel + Morphic ) + Source Code Mgmt Package
Usable Pharo Web : Pharo Base + Seaside
Make a separate workspace/ area for Pharo Foundation supported / approved secondary package, so that download from there is more guaranteed than other user contributed areas/ projects people host/ support on their own.
On Sun, Feb 5, 2012 at 11:13 PM, Philippe Marschall <kustos@gmx.net<mailto:kustos@gmx.net>> wrote: On 30.01.2012 09:24, Stéphane Ducasse wrote:
OK, so here's my take. I try to not turn this into a wish list.
Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo.
FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? "portable plugins"? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me.
64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs.
64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit.
64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images.
SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things.
Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo.
Load balancer I don't think this needs to be part of Pharo. Apache already does this.
UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/⦠This is not giving up. This is not fighting battles you cannot win.
Plug Computer Really? You have all the other places that need more resources and you want to do even more.
Now the things that aren't on your list:
VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring.
#identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time.
Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well.
Migration Support Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers.
Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable.
[1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%2... [2] http://wiki.eclipse.org/Simultaneous_Release [3] http://wiki.eclipse.org/SimRel/Overview
Cheers Philippe
Hi Stef, Similarly to Philippe my feedback is based on a Seaside/web centric view of how I use Pharo. I'd echo Philippe's concern about looking carefully at how much effort is required to rework Morphic vs using an existing UI library or WebView. From a web centric view I'd emphasis building a remote browsing interface over significant Morphic work. At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo? As I develop with Pharo and deploy with Gemstone, maintaining some level of compatibility between Smalltalks is important. I note the problem raised with XML compatibility between dialects [3]. So the ability to maintain a compatibility layer such as Grease is important, as is the ability to re-use packages between Pharo and Gemstone. [1] http://thiscontext.wordpress.com/ [2] http://netjam.org/spoon/naiad/ [3] http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg56924.htm... On 5 February 2012 17:43, Philippe Marschall <kustos@gmx.net> wrote:
On 30.01.2012 09:24, Stéphane Ducasse wrote:
OK, so here's my take. I try to not turn this into a wish list.
Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo.
FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? "portable plugins"? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me.
64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs.
64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit.
64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images.
SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things.
Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo.
Load balancer I don't think this needs to be part of Pharo. Apache already does this.
UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/⦠This is not giving up. This is not fighting battles you cannot win.
Plug Computer Really? You have all the other places that need more resources and you want to do even more.
Now the things that aren't on your list:
VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring.
#identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time.
Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well.
Migration Support Since you're changing quite a lot of things (SystemDictionary/**SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers.
Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable.
[1] http://www.innoq.com/soa/ws-**standards/poster/innoQ%20WS-** Standards%20Poster%202007-02.**pdf<http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%2...> [2] http://wiki.eclipse.org/**Simultaneous_Release<http://wiki.eclipse.org/Simultaneous_Release> [3] http://wiki.eclipse.org/**SimRel/Overview<http://wiki.eclipse.org/SimRel/Overview>
Cheers Philippe
On Feb 6, 2012, at 12:56 PM, Nick Ager wrote:
Hi Stef,
Similarly to Philippe my feedback is based on a Seaside/web centric view of how I use Pharo.
I'd echo Philippe's concern about looking carefully at how much effort is required to rework Morphic vs using an existing UI library or WebView. From a web centric view I'd emphasis building a remote browsing interface over significant Morphic work.
yes but this is a web centric view :). We will have to get decent uibuilder and reuse of logic
At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo?
I do not know. What is clear is that we are working micro kernels and bootstrap for pharo and we will restart our effort on it.
As I develop with Pharo and deploy with Gemstone, maintaining some level of compatibility between Smalltalks is important. I note the problem raised with XML compatibility between dialects [3]. So the ability to maintain a compatibility layer such as Grease is important, as is the ability to re-use packages between Pharo and Gemstone.
Indeed now our goal is to absorb as much as possible grease so that there is no need to load grease for pharo this will proved that our libraries will get better.
[1] http://thiscontext.wordpress.com/ [2] http://netjam.org/spoon/naiad/ [3] http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg56924.htm...
On 5 February 2012 17:43, Philippe Marschall <kustos@gmx.net> wrote: On 30.01.2012 09:24, Stéphane Ducasse wrote:
OK, so here's my take. I try to not turn this into a wish list.
Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo.
FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? "portable plugins"? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me.
64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs.
64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit.
64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images.
SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things.
Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo.
Load balancer I don't think this needs to be part of Pharo. Apache already does this.
UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/⦠This is not giving up. This is not fighting battles you cannot win.
Plug Computer Really? You have all the other places that need more resources and you want to do even more.
Now the things that aren't on your list:
VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring.
#identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time.
Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well.
Migration Support Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers.
Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable.
[1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%2... [2] http://wiki.eclipse.org/Simultaneous_Release [3] http://wiki.eclipse.org/SimRel/Overview
Cheers Philippe
Nick writes:
At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo?
I hope so! By the way, for an inventory of the contents of the kernel I'm using now, see: http://thiscontext.wordpress.com/initial-spoon-modularization thanks, -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
participants (22)
-
Ben Coman -
Craig Latta -
dimitris chloupis -
Edgar J. De Cleene -
Esteban Lorenzano -
Frank Shearar -
Henrik Johansen -
Henrik Sperre Johansen
-
Igor Stasenko -
Mariano Martinez Peck -
Milan Mimica -
Nick Ager -
Nicolas Cellier -
Norbert Hartl -
Paul DeBruicker -
Philippe Marschall -
S Krish -
Schwab,Wilhelm K -
Sean P. DeNigris -
Serge Stinckwich -
Stéphane Ducasse -
Yanni Chiu