I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
Well... I also disagree with the argument of safeness.
For me, saying that is like saying a mennonite community is safer just because they are isolated. They are not. And in any case, the price payed for that isolation is to stay in the 18th century... I think putting this solution in vm is a poor solution, that prevents adaptation in time... just like a mennonite community, btw :)
Frankly... most important question about having it as a plugin is "who will maintain it?"... because problem is not adding a plugin, problem is keep it in time, and match changing outside technologies.
best, Esteban
On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
2012/7/20 Esteban Lorenzano estebanlm@gmail.com
Well... I also disagree with the argument of safeness.
For me, saying that is like saying a mennonite community is safer just because they are isolated. They are not. And in any case, the price payed for that isolation is to stay in the 18th century... I think putting this solution in vm is a poor solution, that prevents adaptation in time... just like a mennonite community, btw :)
Frankly... most important question about having it as a plugin is "who will maintain it?"... because problem is not adding a plugin, problem is keep it in time, and match changing outside technologies.
+1 to use FFI This time, we will add a plugin for URL, next time we will add another one for XXX, and YYYY. Esteban is right, adding more and more plugins is not the right thing to do IMHO since fewer people can maintain it compared to image side code. Moreover, we must interact easily/fastly with existing world (OS, libraries, ...).
For the subscription of the VM to www.weightwatchers.fr ;-)
Luc
best, Esteban
On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
I disagree in general with extend vm complexity to add things that can
perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI +
ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
For me, it's not about safety. It's about mirroring outside word complexity in the image, including the includes files when it comes to FFI. Even the simpler case of shells is boring. What is the OS-universal command to open a web browser? Does it take user preference into account ? Shall we strip some environment variables when we launch a 64bit app from a 32bit one?
How do ruby/python/java/... open an URL?
The uncontested advantage of in-image code is that you can change-evaluate it in fast loops. The second advantage is simpler distribution of code (rather than VMMaker sources + pre-compiled plugin binaries). Though, plugins should be pluggable.
But what do you gain about factoring and maintaining code working for all OS/versions? How do you avoid hardcoding machine specific stuff (paths, executable names etc...)? You have to plug into rather than re-program existing system capabilities, so you have to reify these capabilities and all query/configuration services. In worst cases, if you have to use FFI, it can take the form of preprocessor directives, you know the kind of boring stuff configure or cmake, try to address...
Opening an URL is a very simple test case though, so I'd say Pharo shoud experiment and recreate an in-image mirror of the plugin (I mean with same capabilities) using OSProcess shells. It will bring more feedback before we can vote.
Nicolas
2012/7/20 Luc Fabresse luc.fabresse@gmail.com:
2012/7/20 Esteban Lorenzano estebanlm@gmail.com
Well... I also disagree with the argument of safeness.
For me, saying that is like saying a mennonite community is safer just because they are isolated. They are not. And in any case, the price payed for that isolation is to stay in the 18th century... I think putting this solution in vm is a poor solution, that prevents adaptation in time... just like a mennonite community, btw :)
Frankly... most important question about having it as a plugin is "who will maintain it?"... because problem is not adding a plugin, problem is keep it in time, and match changing outside technologies.
+1 to use FFI This time, we will add a plugin for URL, next time we will add another one for XXX, and YYYY. Esteban is right, adding more and more plugins is not the right thing to do IMHO since fewer people can maintain it compared to image side code. Moreover, we must interact easily/fastly with existing world (OS, libraries, ...).
For the subscription of the VM to www.weightwatchers.fr ;-)
Luc
best, Esteban
On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
VM is not magically solved, you know? there is people behind that... difference is:
- We have 5 vm maintaners (in their spare time) and 50+ possible image maintainers. And I'm going to ask it again: who is going to maintain it? - is not "mirroring" anything... that sentence assumes that what you are asking for something that already exists... - complexity is exactly the same in vm side... but Smalltalk is better to program and maintain. Who prevent us to hardcode in the VM? and if that happens... who can change it on the fly to match their needs? Seriously, nothing prevents us to have crapy code (and if you see some code around, you'll notice that). But if we have the essential complexity living in the image, at least we can use a language that can manage this complexity in a proper way.
Still... your arguments don't convince me, because essentially, what you asking for is to hide the garbage under the carpet, so you cannot see it. I prefer to expose it, then someone can clean it.
Esteban
ps: Even more seriously, guys: take a look at the existing plugins: many of them are old and kinda obsolete. Nobody has make serious investment on keep them up-to-date and technology changed since last 15 years... this happens because we are not apple or microsoft. We cannot put the needed resources into maintain the VM as it is now. But we can maintain it if it lives in the image... because we are Smalltalk programmers, and our community is about Smalltalk... let the environment rule :)
On Jul 20, 2012, at 1:40 PM, Nicolas Cellier wrote:
For me, it's not about safety. It's about mirroring outside word complexity in the image, including the includes files when it comes to FFI. Even the simpler case of shells is boring. What is the OS-universal command to open a web browser? Does it take user preference into account ? Shall we strip some environment variables when we launch a 64bit app from a 32bit one?
How do ruby/python/java/... open an URL?
The uncontested advantage of in-image code is that you can change-evaluate it in fast loops. The second advantage is simpler distribution of code (rather than VMMaker sources + pre-compiled plugin binaries). Though, plugins should be pluggable.
But what do you gain about factoring and maintaining code working for all OS/versions? How do you avoid hardcoding machine specific stuff (paths, executable names etc...)? You have to plug into rather than re-program existing system capabilities, so you have to reify these capabilities and all query/configuration services. In worst cases, if you have to use FFI, it can take the form of preprocessor directives, you know the kind of boring stuff configure or cmake, try to address...
Opening an URL is a very simple test case though, so I'd say Pharo shoud experiment and recreate an in-image mirror of the plugin (I mean with same capabilities) using OSProcess shells. It will bring more feedback before we can vote.
Nicolas
2012/7/20 Luc Fabresse luc.fabresse@gmail.com:
2012/7/20 Esteban Lorenzano estebanlm@gmail.com
Well... I also disagree with the argument of safeness.
For me, saying that is like saying a mennonite community is safer just because they are isolated. They are not. And in any case, the price payed for that isolation is to stay in the 18th century... I think putting this solution in vm is a poor solution, that prevents adaptation in time... just like a mennonite community, btw :)
Frankly... most important question about having it as a plugin is "who will maintain it?"... because problem is not adding a plugin, problem is keep it in time, and match changing outside technologies.
+1 to use FFI This time, we will add a plugin for URL, next time we will add another one for XXX, and YYYY. Esteban is right, adding more and more plugins is not the right thing to do IMHO since fewer people can maintain it compared to image side code. Moreover, we must interact easily/fastly with existing world (OS, libraries, ...).
For the subscription of the VM to www.weightwatchers.fr ;-)
Luc
best, Esteban
On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
2012/7/20 Esteban Lorenzano estebanlm@gmail.com:
VM is not magically solved, you know? there is people behind that... difference is:
- We have 5 vm maintaners (in their spare time) and 50+ possible image maintainers. And I'm going to ask it again: who is going to maintain it?
- is not "mirroring" anything... that sentence assumes that what you are asking for something that already exists...
- complexity is exactly the same in vm side... but Smalltalk is better to program and maintain. Who prevent us to hardcode in the VM? and if that happens... who can change it on the fly to match their needs? Seriously, nothing prevents us to have crapy code (and if you see some code around, you'll notice that). But if we have the essential complexity living in the image, at least we can use a language that can manage this complexity in a proper way.
Between we can and we did, there's a fair bit of magical occuring too... I say YES, it can be FAR less work to maintain in image FFI than C/Slang VM plugins when functions are portable (case of third party libraries built with this purpose), but in some cases it can be worse. For example, developping interface to Lapack with FFI/DLLCC was at least 5x more productive than writing VW primitives in my experience. I did also try more OS-related things with DLLCC, and though VisualWorks provided an up to date CParser that could parse headers at that time (hardly longer the case now), it did not solve anything for me, I had to reflect implementation details in image for each OS, and for some function points like interfacing with IPC, it was far easier to use the right tools, I mean provide a compatibility layer programmed in C. If you ever dealed with union semun & co, you know what I'm talking of...
If we are speaking of implementing a better cmake/configure, maybe we have better dragons to fight. I also don't buy, we are better and have a better language, Morphic is a good example of what we can come with in term of complexity. Complexity requires a lot of engineering.
I say we must try hard, experiment, use FFI were we gain, but be pragmatic rather than dogmatic. Every other argument thrown in these threads is just wishful thinking.
Nicolas
Still... your arguments don't convince me, because essentially, what you asking for is to hide the garbage under the carpet, so you cannot see it. I prefer to expose it, then someone can clean it.
Esteban
ps: Even more seriously, guys: take a look at the existing plugins: many of them are old and kinda obsolete. Nobody has make serious investment on keep them up-to-date and technology changed since last 15 years... this happens because we are not apple or microsoft. We cannot put the needed resources into maintain the VM as it is now. But we can maintain it if it lives in the image... because we are Smalltalk programmers, and our community is about Smalltalk... let the environment rule :)
On Jul 20, 2012, at 1:40 PM, Nicolas Cellier wrote:
For me, it's not about safety. It's about mirroring outside word complexity in the image, including the includes files when it comes to FFI. Even the simpler case of shells is boring. What is the OS-universal command to open a web browser? Does it take user preference into account ? Shall we strip some environment variables when we launch a 64bit app from a 32bit one?
How do ruby/python/java/... open an URL?
The uncontested advantage of in-image code is that you can change-evaluate it in fast loops. The second advantage is simpler distribution of code (rather than VMMaker sources + pre-compiled plugin binaries). Though, plugins should be pluggable.
But what do you gain about factoring and maintaining code working for all OS/versions? How do you avoid hardcoding machine specific stuff (paths, executable names etc...)? You have to plug into rather than re-program existing system capabilities, so you have to reify these capabilities and all query/configuration services. In worst cases, if you have to use FFI, it can take the form of preprocessor directives, you know the kind of boring stuff configure or cmake, try to address...
Opening an URL is a very simple test case though, so I'd say Pharo shoud experiment and recreate an in-image mirror of the plugin (I mean with same capabilities) using OSProcess shells. It will bring more feedback before we can vote.
Nicolas
2012/7/20 Luc Fabresse luc.fabresse@gmail.com:
2012/7/20 Esteban Lorenzano estebanlm@gmail.com
Well... I also disagree with the argument of safeness.
For me, saying that is like saying a mennonite community is safer just because they are isolated. They are not. And in any case, the price payed for that isolation is to stay in the 18th century... I think putting this solution in vm is a poor solution, that prevents adaptation in time... just like a mennonite community, btw :)
Frankly... most important question about having it as a plugin is "who will maintain it?"... because problem is not adding a plugin, problem is keep it in time, and match changing outside technologies.
+1 to use FFI This time, we will add a plugin for URL, next time we will add another one for XXX, and YYYY. Esteban is right, adding more and more plugins is not the right thing to do IMHO since fewer people can maintain it compared to image side code. Moreover, we must interact easily/fastly with existing world (OS, libraries, ...).
For the subscription of the VM to www.weightwatchers.fr ;-)
Luc
best, Esteban
On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
On 2012-07-20, at 13:40, Nicolas Cellier wrote:
For me, it's not about safety. It's about mirroring outside word complexity in the image, including the includes files when it comes to FFI. Even the simpler case of shells is boring. What is the OS-universal command to open a web browser? Does it take user preference into account ? Shall we strip some environment variables when we launch a 64bit app from a 32bit one?
How do ruby/python/java/... open an URL?
ruby and python both seem not to have a static (vm-side) solution for this problem:
http://stackoverflow.com/questions/152699/open-the-default-browser-in-ruby http://stackoverflow.com/questions/4216985/python-call-to-operating-system-t...
so the solution is language-side, as it should be!
The uncontested advantage of in-image code is that you can change-evaluate it in fast loops. The second advantage is simpler distribution of code (rather than VMMaker sources + pre-compiled plugin binaries). Though, plugins should be pluggable.
But what do you gain about factoring and maintaining code working for all OS/versions? How do you avoid hardcoding machine specific stuff (paths, executable names etc...)?
Obviously you have to do that. But for instance you can rely on FFI and Posix, that cut's down the problem space quite effectively. Of course you'll still have to deal with certain OS specific issues, but that's already the case in 2.0 with FileSystem...
You have to plug into rather than re-program existing system capabilities, so you have to reify these capabilities and all query/configuration services. In worst cases, if you have to use FFI, it can take the form of preprocessor directives, you know the kind of boring stuff configure or cmake, try to address...
not really... I mean you can simply resolve methods using dlsym, and your almost done. Besides you leave out the fact that most plugins are written in SLANG anyway, so there you have your preprocessor written in a pseudo smalltalk. However if you use the full power of ST you get away quite nicely (and in many cases much much faster...)
So even if you have to write a preprocessor like thingy, you're still better off than with VM-side code.
Opening an URL is a very simple test case though, so I'd say Pharo shoud experiment and recreate an in-image mirror of the plugin (I mean with same capabilities) using OSProcess shells. It will bring more feedback before we can vote.
We reimplemented the FileSystem primitives in NativeBoost, which is not simply calling an external function, but holding on to a reference when you loop over the directory.
Outcome? We were 40times faster than the C plugin with 3 classes added to the system...
I don't really think there is something to vote about, at least here at RMoD the mindset is pretty clear :) (on the FFI side of the world).
2012/7/20 Camillo Bruni camillobruni@gmail.com:
On 2012-07-20, at 13:40, Nicolas Cellier wrote:
For me, it's not about safety. It's about mirroring outside word complexity in the image, including the includes files when it comes to FFI. Even the simpler case of shells is boring. What is the OS-universal command to open a web browser? Does it take user preference into account ? Shall we strip some environment variables when we launch a 64bit app from a 32bit one?
How do ruby/python/java/... open an URL?
ruby and python both seem not to have a static (vm-side) solution for this problem:
http://stackoverflow.com/questions/152699/open-the-default-browser-in-ruby http://stackoverflow.com/questions/4216985/python-call-to-operating-system-t...
so the solution is language-side, as it should be!
The uncontested advantage of in-image code is that you can change-evaluate it in fast loops. The second advantage is simpler distribution of code (rather than VMMaker sources + pre-compiled plugin binaries). Though, plugins should be pluggable.
But what do you gain about factoring and maintaining code working for all OS/versions? How do you avoid hardcoding machine specific stuff (paths, executable names etc...)?
Obviously you have to do that. But for instance you can rely on FFI and Posix, that cut's down the problem space quite effectively. Of course you'll still have to deal with certain OS specific issues, but that's already the case in 2.0 with FileSystem...
You have to plug into rather than re-program existing system capabilities, so you have to reify these capabilities and all query/configuration services. In worst cases, if you have to use FFI, it can take the form of preprocessor directives, you know the kind of boring stuff configure or cmake, try to address...
not really... I mean you can simply resolve methods using dlsym, and your almost done. Besides you leave out the fact that most plugins are written in SLANG anyway, so there you have your preprocessor written in a pseudo smalltalk. However if you use the full power of ST you get away quite nicely (and in many cases much much faster...)
Agree. Alas, the devil is in the detail, name it 'almost'. Is the function name the same on every OS ? Where/how do you find the library name, version, path, dependencies ? Is the function a macro in some .h (using internal FILE structure details for example) ? Does it use enum or any other encoded integer ? Are the structures portable (I mean those which are not allocated by a function call) ?
So even if you have to write a preprocessor like thingy, you're still better off than with VM-side code.
Opening an URL is a very simple test case though, so I'd say Pharo shoud experiment and recreate an in-image mirror of the plugin (I mean with same capabilities) using OSProcess shells. It will bring more feedback before we can vote.
We reimplemented the FileSystem primitives in NativeBoost, which is not simply calling an external function, but holding on to a reference when you loop over the directory.
Outcome? We were 40times faster than the C plugin with 3 classes added to the system...
I say this is an encouraging start point, but not enough to prove the concept you must replace a whole plugin. Though, I think that FilePlugin is a very difficult candidate to start with... For non blocking I/O, how do we encode the necessary fcntl flags in a portable manner ? Do we replicate the OS-specific flag encoding in the image ? Or do we use one native thread per function call thru threaded FFI ?
It would also be fair to detail the source of speed-up: - replacing generic FFI typechecking by native boost mechanism ? - using simpler structures than FIle plugin ? - bypassing some safety checks ?
I don't really think there is something to vote about, at least here at RMoD the mindset is pretty clear :) (on the FFI side of the world).
I can only encourage you to continue the hard work and come back with the proof. Though I play the role of Cassandra, I wish you good luck and success.
Nicolas
On 20 July 2012 16:31, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2012/7/20 Camillo Bruni camillobruni@gmail.com:
On 2012-07-20, at 13:40, Nicolas Cellier wrote:
For me, it's not about safety. It's about mirroring outside word complexity in the image, including the includes files when it comes to FFI. Even the simpler case of shells is boring. What is the OS-universal command to open a web browser? Does it take user preference into account ? Shall we strip some environment variables when we launch a 64bit app from a 32bit one?
How do ruby/python/java/... open an URL?
ruby and python both seem not to have a static (vm-side) solution for this problem:
http://stackoverflow.com/questions/152699/open-the-default-browser-in-ruby http://stackoverflow.com/questions/4216985/python-call-to-operating-system-t...
so the solution is language-side, as it should be!
The uncontested advantage of in-image code is that you can change-evaluate it in fast loops. The second advantage is simpler distribution of code (rather than VMMaker sources + pre-compiled plugin binaries). Though, plugins should be pluggable.
But what do you gain about factoring and maintaining code working for all OS/versions? How do you avoid hardcoding machine specific stuff (paths, executable names etc...)?
Obviously you have to do that. But for instance you can rely on FFI and Posix, that cut's down the problem space quite effectively. Of course you'll still have to deal with certain OS specific issues, but that's already the case in 2.0 with FileSystem...
You have to plug into rather than re-program existing system capabilities, so you have to reify these capabilities and all query/configuration services. In worst cases, if you have to use FFI, it can take the form of preprocessor directives, you know the kind of boring stuff configure or cmake, try to address...
not really... I mean you can simply resolve methods using dlsym, and your almost done. Besides you leave out the fact that most plugins are written in SLANG anyway, so there you have your preprocessor written in a pseudo smalltalk. However if you use the full power of ST you get away quite nicely (and in many cases much much faster...)
Agree. Alas, the devil is in the detail, name it 'almost'. Is the function name the same on every OS ? Where/how do you find the library name, version, path, dependencies ? Is the function a macro in some .h (using internal FILE structure details for example) ? Does it use enum or any other encoded integer ? Are the structures portable (I mean those which are not allocated by a function call) ?
So even if you have to write a preprocessor like thingy, you're still better off than with VM-side code.
Opening an URL is a very simple test case though, so I'd say Pharo shoud experiment and recreate an in-image mirror of the plugin (I mean with same capabilities) using OSProcess shells. It will bring more feedback before we can vote.
We reimplemented the FileSystem primitives in NativeBoost, which is not simply calling an external function, but holding on to a reference when you loop over the directory.
Outcome? We were 40times faster than the C plugin with 3 classes added to the system...
I say this is an encouraging start point, but not enough to prove the concept you must replace a whole plugin. Though, I think that FilePlugin is a very difficult candidate to start with... For non blocking I/O, how do we encode the necessary fcntl flags in a portable manner ? Do we replicate the OS-specific flag encoding in the image ? Or do we use one native thread per function call thru threaded FFI ?
It would also be fair to detail the source of speed-up:
- replacing generic FFI typechecking by native boost mechanism ?
- using simpler structures than FIle plugin ?
- bypassing some safety checks ?
in this case the source of speedup was purely about properly using OS functionality. The required functionality was: return all directory entries. A plugin , unfortunately, provides only one primitive suitable for doing that: get n-th entry in file directory. And implementation is very ineffective: open directory, skip entries up to n-th element, return n-th element, close directory.
The plugin doing a nice thing to hide the OS-specific directory handle from the eyes of smalltalkers.. but this comes at cost like having O(n!) instead of O(n) to read all directory entries.
I don't really think there is something to vote about, at least here at RMoD the mindset is pretty clear :) (on the FFI side of the world).
I can only encourage you to continue the hard work and come back with the proof. Though I play the role of Cassandra, I wish you good luck and success.
Nicolas
On 2012-07-20, at 10:23, Esteban Lorenzano wrote:
Well... I also disagree with the argument of safeness.
Exactly, Pharo is inherently "unsafe" so to speak, you can - remove arbitrary methods - add arbitrary new classes - change methods at will - swap any two objects...
so adding FFI / OSProcess won't add much to this list :D Besisdes, Ruby and Python include shell invocation by default
On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
also java, .net, etc...
Runtime.exec or something like that, I don't remember (thankfully :) ) well...
On Jul 20, 2012, at 12:31 PM, Camillo Bruni wrote:
On 2012-07-20, at 10:23, Esteban Lorenzano wrote:
Well... I also disagree with the argument of safeness.
Exactly, Pharo is inherently "unsafe" so to speak, you can
- remove arbitrary methods
- add arbitrary new classes
- change methods at will
- swap any two objects...
so adding FFI / OSProcess won't add much to this list :D Besisdes, Ruby and Python include shell invocation by default
On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
Saying you can do this using FFI/OSProcess is a weak argument. "fopen" could be in the Smalltalk image as well - but we have it in the VM.
We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
But I dont think that is the route for Squeak, Cuis, ... These Smalltalks may profit from an VM implementation without making them "unsafe" or more bound to native OS with FFI and OSProcess.
How can we proceed in the discussion? There are pros and cons for both sides. Should we vote?
According to
http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+O...
"URL within VM" seems to be the winner ;)
Thanks T.
vm-dev@lists.squeakfoundation.org
-
Camillo Bruni -
Esteban Lorenzano -
Igor Stasenko -
Luc Fabresse -
Nicolas Cellier -
Torsten Bergmann