[Pharo-project] Pharo and the rest of the ecosystem
Hi guys May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems. We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future. We are spending a lot of time on making the system better. - Fuel - Athens - OPAL - Ghost - Nautilus - Ring - NativeBoost - Zinc - HUGE amount of fixes - Working on a core - Writing a lot of documentation (yes guys) to name a few. We are pushing like hell and getting there. We spent time building our vision and step by step building it. We are getting there. :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future. You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free. Stef
Can you clarify what exactly you are asking here Stef? Are you asking why people work on projects like CUIS and Spoon? -- View this message in context: http://forum.world.st/Pharo-and-the-rest-of-the-ecosystem-tp4582839p4582931.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi Stef, Dne 24. 04. 2012 11:22, piše Stéphane Ducasse:
Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
I see the point behind Cuis/Spoon discussion in a wish to avoid duplication efforts in Smalltalk community. A wish to hear from you a word, something like: "yes we will look in Cuis to see if we can reuse some ideas or even code". To express just a will to look at achievements of others would help here. I think this is what many of us wants to hear. Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
I see the point behind Cuis/Spoon discussion in a wish to avoid duplication efforts in Smalltalk community. A wish to hear from you a word, something like: "yes we will look in Cuis to see if we can reuse some ideas or even code". To express just a will to look at achievements of others would help here. I think this is what many of us wants to hear.
Did you notice that we ***already*** harvested some of the CUIS items? Now it does not make sense to stay compatible for the sake of it. Look CUIS changes the class definition meta data and this is ok. Now nobody went to say to Juan that he should not ⦠blablbalbalba Stef
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Hey, Steph! Thanks! :-) On Tue, Apr 24, 2012 at 2:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems.
We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future.
I see the "point" of Cuis as to have a small, clean, understandable Smalltalk system. It's a *general-purpose* system rather than one geared solely towards business. Pharo, at least to me, feels more like the Java ecosystem -- a platform aiming primarily toward business and generating plenty of marketing "buzz" with frameworks-of-the-month (such as the ones you listed). In Cuis, Smalltalk _is_ the framework and users are expected to build on that directly. In my view, Spoon is about letting the machine generate a small, vertical system from a larger, horizontal system. Pavel, Edgar and you all have been working on making a smaller system for years (good work); but I see the dream of Spoon as delegating that work to the machine, which will do it quickly and accurately. The question at the moment is whether that dream will be realized. Based on Craig's Squeak-Board candidacy announcement, I expect 2012 to be the year Spoon is born into mainstream-use at least in the Squeak community. On Tue, Apr 24, 2012 at 4:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems.
We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future.
We are spending a lot of time on making the system better.     - Fuel     - Athens     - OPAL     - Ghost     - Nautilus     - Ring     - NativeBoost     - Zinc     - HUGE amount of fixes     - Working on a core     - Writing a lot of documentation (yes guys) to name a few. We are pushing like hell and getting there.
We spent time building our vision and step by step building it. We are getting there. Â :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
Stef
Hi Chris, the planed changes in Pharo are not autotelic but in most cases they are replacements of current buggy and unmaintainable subsytems. We also use automatic or semiautomatic tools for shrinking and modularization of the image. For example uMorphic is generated moslty automatically with subsequent hand-made cleanup. The original Squeak KernelImage was generated in the similar way. But we use the results of this tools only as the supporting experimental sources of information. The goals of Cuis, Spoon and Pharo are very very similar. Everyone wants to have the "small, clean, understandable Smalltalk system". But Pharo development is more evolutional and modularity is more valuable than small size. In Smalltalk it is easy to dive into the system and create something like Cuis, Spoon or KernelImage. But this projects were created by a single person and the degree of adoption of this forks is low. You may for example to take the current PharoKernel and withing few days to create a perfect small and clean kernel. It is cool intelectual adventure but to make it generally used stuff is another story. -- Pavel On Wed, Apr 25, 2012 at 6:17 PM, Chris Muller <asqueaker@gmail.com> wrote:
I see the "point" of Cuis as to have a small, clean, understandable Smalltalk system. Â It's a *general-purpose* system rather than one geared solely towards business. Â Pharo, at least to me, feels more like the Java ecosystem -- a platform aiming primarily toward business and generating plenty of marketing "buzz" with frameworks-of-the-month (such as the ones you listed). Â In Cuis, Smalltalk _is_ the framework and users are expected to build on that directly.
In my view, Spoon is about letting the machine generate a small, vertical system from a larger, horizontal system. Â Pavel, Edgar and you all have been working on making a smaller system for years (good work); but I see the dream of Spoon as delegating that work to the machine, which will do it quickly and accurately. Â The question at the moment is whether that dream will be realized. Â Based on Craig's Squeak-Board candidacy announcement, I expect 2012 to be the year Spoon is born into mainstream-use at least in the Squeak community.
On Tue, Apr 24, 2012 at 4:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems.
We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future.
We are spending a lot of time on making the system better.     - Fuel     - Athens     - OPAL     - Ghost     - Nautilus     - Ring     - NativeBoost     - Zinc     - HUGE amount of fixes     - Working on a core     - Writing a lot of documentation (yes guys) to name a few. We are pushing like hell and getting there.
We spent time building our vision and step by step building it. We are getting there. Â :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
Stef
Well said! Norbert Am 26.04.2012 um 10:19 schrieb Pavel Krivanek:
Hi Chris,
the planed changes in Pharo are not autotelic but in most cases they are replacements of current buggy and unmaintainable subsytems. We also use automatic or semiautomatic tools for shrinking and modularization of the image. For example uMorphic is generated moslty automatically with subsequent hand-made cleanup. The original Squeak KernelImage was generated in the similar way. But we use the results of this tools only as the supporting experimental sources of information. The goals of Cuis, Spoon and Pharo are very very similar. Everyone wants to have the "small, clean, understandable Smalltalk system". But Pharo development is more evolutional and modularity is more valuable than small size. In Smalltalk it is easy to dive into the system and create something like Cuis, Spoon or KernelImage. But this projects were created by a single person and the degree of adoption of this forks is low. You may for example to take the current PharoKernel and withing few days to create a perfect small and clean kernel. It is cool intelectual adventure but to make it generally used stuff is another story.
-- Pavel
On Wed, Apr 25, 2012 at 6:17 PM, Chris Muller <asqueaker@gmail.com> wrote:
I see the "point" of Cuis as to have a small, clean, understandable Smalltalk system. It's a *general-purpose* system rather than one geared solely towards business. Pharo, at least to me, feels more like the Java ecosystem -- a platform aiming primarily toward business and generating plenty of marketing "buzz" with frameworks-of-the-month (such as the ones you listed). In Cuis, Smalltalk _is_ the framework and users are expected to build on that directly.
In my view, Spoon is about letting the machine generate a small, vertical system from a larger, horizontal system. Pavel, Edgar and you all have been working on making a smaller system for years (good work); but I see the dream of Spoon as delegating that work to the machine, which will do it quickly and accurately. The question at the moment is whether that dream will be realized. Based on Craig's Squeak-Board candidacy announcement, I expect 2012 to be the year Spoon is born into mainstream-use at least in the Squeak community.
On Tue, Apr 24, 2012 at 4:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems.
We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future.
We are spending a lot of time on making the system better. - Fuel - Athens - OPAL - Ghost - Nautilus - Ring - NativeBoost - Zinc - HUGE amount of fixes - Working on a core - Writing a lot of documentation (yes guys) to name a few. We are pushing like hell and getting there.
We spent time building our vision and step by step building it. We are getting there. :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
Stef
+100 Thanks for putting it so clearly, Pavel. On 26 Apr 2012, at 10:19, Pavel Krivanek wrote:
Hi Chris,
the planed changes in Pharo are not autotelic but in most cases they are replacements of current buggy and unmaintainable subsytems. We also use automatic or semiautomatic tools for shrinking and modularization of the image. For example uMorphic is generated moslty automatically with subsequent hand-made cleanup. The original Squeak KernelImage was generated in the similar way. But we use the results of this tools only as the supporting experimental sources of information. The goals of Cuis, Spoon and Pharo are very very similar. Everyone wants to have the "small, clean, understandable Smalltalk system". But Pharo development is more evolutional and modularity is more valuable than small size. In Smalltalk it is easy to dive into the system and create something like Cuis, Spoon or KernelImage. But this projects were created by a single person and the degree of adoption of this forks is low. You may for example to take the current PharoKernel and withing few days to create a perfect small and clean kernel. It is cool intelectual adventure but to make it generally used stuff is another story.
-- Pavel
On Wed, Apr 25, 2012 at 6:17 PM, Chris Muller <asqueaker@gmail.com> wrote:
I see the "point" of Cuis as to have a small, clean, understandable Smalltalk system. It's a *general-purpose* system rather than one geared solely towards business. Pharo, at least to me, feels more like the Java ecosystem -- a platform aiming primarily toward business and generating plenty of marketing "buzz" with frameworks-of-the-month (such as the ones you listed). In Cuis, Smalltalk _is_ the framework and users are expected to build on that directly.
In my view, Spoon is about letting the machine generate a small, vertical system from a larger, horizontal system. Pavel, Edgar and you all have been working on making a smaller system for years (good work); but I see the dream of Spoon as delegating that work to the machine, which will do it quickly and accurately. The question at the moment is whether that dream will be realized. Based on Craig's Squeak-Board candidacy announcement, I expect 2012 to be the year Spoon is born into mainstream-use at least in the Squeak community.
On Tue, Apr 24, 2012 at 4:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems.
We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future.
We are spending a lot of time on making the system better. - Fuel - Athens - OPAL - Ghost - Nautilus - Ring - NativeBoost - Zinc - HUGE amount of fixes - Working on a core - Writing a lot of documentation (yes guys) to name a few. We are pushing like hell and getting there.
We spent time building our vision and step by step building it. We are getting there. :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
Stef
El 4/26/12 5:19 AM, "Pavel Krivanek" <pavel.krivanek@gmail.com> escribió:
Hi Chris,
the planed changes in Pharo are not autotelic but in most cases they are replacements of current buggy and unmaintainable subsytems. We also use automatic or semiautomatic tools for shrinking and modularization of the image. For example uMorphic is generated moslty automatically with subsequent hand-made cleanup. The original Squeak KernelImage was generated in the similar way. But we use the results of this tools only as the supporting experimental sources of information. The goals of Cuis, Spoon and Pharo are very very similar. Everyone wants to have the "small, clean, understandable Smalltalk system". But Pharo development is more evolutional and modularity is more valuable than small size. In Smalltalk it is easy to dive into the system and create something like Cuis, Spoon or KernelImage. But this projects were created by a single person and the degree of adoption of this forks is low. You may for example to take the current PharoKernel and withing few days to create a perfect small and clean kernel. It is cool intelectual adventure but to make it generally used stuff is another story.
-- Pavel
Again i ask to fellows on all forks adopt the great work of years from Pavel. We should not waste valuable time and instead take PharoKernel and build our beloved pet on top of it. Edgar
Am 26.04.2012 um 14:05 schrieb Edgar De Cleene:
El 4/26/12 5:19 AM, "Pavel Krivanek" <pavel.krivanek@gmail.com> escribió:
Hi Chris,
the planed changes in Pharo are not autotelic but in most cases they are replacements of current buggy and unmaintainable subsytems. We also use automatic or semiautomatic tools for shrinking and modularization of the image. For example uMorphic is generated moslty automatically with subsequent hand-made cleanup. The original Squeak KernelImage was generated in the similar way. But we use the results of this tools only as the supporting experimental sources of information. The goals of Cuis, Spoon and Pharo are very very similar. Everyone wants to have the "small, clean, understandable Smalltalk system". But Pharo development is more evolutional and modularity is more valuable than small size. In Smalltalk it is easy to dive into the system and create something like Cuis, Spoon or KernelImage. But this projects were created by a single person and the degree of adoption of this forks is low. You may for example to take the current PharoKernel and withing few days to create a perfect small and clean kernel. It is cool intelectual adventure but to make it generally used stuff is another story.
-- Pavel
Again i ask to fellows on all forks adopt the great work of years from Pavel. We should not waste valuable time and instead take PharoKernel and build our beloved pet on top of it.
That happens anyway for pharo. How could miss it? Norbert
Chris Muller-3 wrote
generating plenty of marketing "buzz" with frameworks-of-the-month (such as the ones you listed). In Cuis, Smalltalk _is_ the framework and users are expected to build on that directly.
Pavel Krivanek-3 wrote
the planed changes in Pharo are not autotelic but in most cases they are replacements of current buggy and unmaintainable subsytems.
Yes this is the key! It's not "let's build all these great frameworks on top of the system", but "we need a clean, beautiful system that people can use and explore and build on without tearing their hair out in frustration" [1] and some of the components are so messy that the only clear path forward is replacement. This is not a criticism of Squeak. Many parts of Squeak (and Squeak itself was intended as just a "tool to think" about the next evolution) were spikes, not real implementations but experiments. So the usual advice that it's better to clean than to rewrite does not apply. Proofs of concept are meant to be thrown away! Each of these components brings us closer to a clean, beautiful, Smalltalk-inspired system "and users are expected to build on that directly". The Smalltalk-inspired part is crucial also. Until I got that, I was plagued by questions of interoperability and backward-compatibility (which are obviously still nice, but subordinate to evolution). I see Squeak and Pharo's goals aligning more and more and, sure, it is frustrating to duplicate efforts. Although, maybe we'd all be complacent without the friendly rivalry. As the Zen master said, "we'll see..." [2] [1] I can't imagine someone putting FileDirectory and friends through serious use and not praying for something like Filesystem. And a programming environment without built-in support for https?? Zodiac is a fundamental piece of the system. These things are not "buzz", but core components that let us get back to work and play, instead of beating our heads against soul-crushing constructs like "FileDirectory extensionFor: file name" instead of "file extension" [2] A boy is given a horse on his 14th birthday. Everyone in the village says, âOh how wonderful.â But a Zen master who lives in the village says, âWe'll see.â 'The boy falls off the horse and breaks his foot. Everyone in the village says, âOh how awful.â The Zen master says, âWe'll see.â The village is thrown into war and all the young men have to go to war. But, because of the broken foot, the boy stays behind. Everyone says, âOh, how wonderful.â The Zen master says, âWe'll see.â Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-and-the-rest-of-the-ecosystem-tp4582839p4590003.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 26-04-2012 11:31, Sean P. DeNigris wrote:
Yes this is the key! It's not "let's build all these great frameworks on top of the system", but "we need a clean, beautiful system that people can use and explore and build on without tearing their hair out in frustration" [1] and some of the components are so messy that the only clear path forward is replacement. This is not a criticism of Squeak. Many parts of Squeak (and Squeak itself was intended as just a "tool to think" about the next evolution) were spikes, not real implementations but experiments. So the usual advice that it's better to clean than to rewrite does not apply. Proofs of concept are meant to be thrown away!
Yes, that's true: some times replacements are necessary. Thing is that historical smalltalk distros were not devised in modular way. Particularly they didn't have the idea of core system and foundation classes and that lead to a development model that depended on non orthogonal stuff (meaning: at some point it got difficult to insulate causes of trouble and fixing one thing lead to problems in other things). Situation was further complicated by the fact that sometimes problems found in certain areas were "solved" by building new packages to deal with them and these new packages should live side by side with old ones. In terms of maintenance it is pretty like hell. The efforts of generating minimal images (cores) are extremely healthy: to do so it is necessary to eliminate much undesired inter-dependencies. Besides people are minding about the real necessity of having different things to deal with the same stuff (like file and directory management). Another aspect of it is that people are enhancing code where possible or just replacing things that are fubar. I guess that one thing for immediate future of an open source "industry grade" smalltalk is to define foundation classes to deal with core functionality (file and directory management, (inter)networking, multimedia, interfacing with OS, user interface (including seamless use of full screen display and OpenGL), etc, etc, etc. IMO, interfacing with OS and foreign libraries is something that must be seen "with love" because FFI is not well behaved and as VMs were designed for past generation x86-32bit (mono-core single-thread) architectures. There is a lot to do in terms of porting things to the new 64bit multi-core multi-thread hardware architectures. I remember that around 2010 there were hot discussions about having multi-core multi-thread support in VM but now things are quite silent. Also, the last things I saw about 64bit images date from 2010.
Each of these components brings us closer to a clean, beautiful, Smalltalk-inspired system "and users are expected to build on that directly". The Smalltalk-inspired part is crucial also. Until I got that, I was plagued by questions of interoperability and backward-compatibility (which are obviously still nice, but subordinate to evolution).
I see Squeak and Pharo's goals aligning more and more and, sure, it is frustrating to duplicate efforts. Although, maybe we'd all be complacent without the friendly rivalry. As the Zen master said, "we'll see..." [2]
[1] I can't imagine someone putting FileDirectory and friends through serious use and not praying for something like Filesystem. And a programming environment without built-in support for https?? Zodiac is a fundamental piece of the system. These things are not "buzz", but core components that let us get back to work and play, instead of beating our heads against soul-crushing constructs like "FileDirectory extensionFor: file name" instead of "file extension"
[2] A boy is given a horse on his 14th birthday. Everyone in the village says, âOh how wonderful.â But a Zen master who lives in the village says, âWe'll see.â 'The boy falls off the horse and breaks his foot. Everyone in the village says, âOh how awful.â The Zen master says, âWe'll see.â The village is thrown into war and all the young men have to go to war. But, because of the broken foot, the boy stays behind. Everyone says, âOh, how wonderful.â The Zen master says, âWe'll see.â
Cheers, Sean
-- View this message in context: http://forum.world.st/Pharo-and-the-rest-of-the-ecosystem-tp4582839p4590003.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Best regards, CdAB
On Apr 26, 2012, at 5:46 PM, Casimiro de Almeida Barreto wrote:
I guess that one thing for immediate future of an open source "industry grade" smalltalk is to define foundation classes to deal with core functionality (file and directory management, (inter)networking, multimedia, interfacing with OS, user interface (including seamless use of full screen display and OpenGL), etc, etc, etc.
I hope to start to work on RestrictedSmalltalk once we got the bootstrap up and running. RestrictedSmalltalk should be closer to Smalltalk than RestrictedPython is from Python :) but I like the idea that we can understand what is really needed for the core and in particular from the reflective features. Stef
Am 27.04.2012 um 00:12 schrieb Stéphane Ducasse:
On Apr 26, 2012, at 5:46 PM, Casimiro de Almeida Barreto wrote:
I guess that one thing for immediate future of an open source "industry grade" smalltalk is to define foundation classes to deal with core functionality (file and directory management, (inter)networking, multimedia, interfacing with OS, user interface (including seamless use of full screen display and OpenGL), etc, etc, etc.
I hope to start to work on RestrictedSmalltalk once we got the bootstrap up and running. RestrictedSmalltalk should be closer to Smalltalk than RestrictedPython is from Python :) but I like the idea that we can understand what is really needed for the core and in particular from the reflective features.
Yes, knowing the foundation where we standing on can be quite life-sustaining. Ok, it's turtles but even the turtles are made of something. I would love to participate with you guys but that's hard if not present in personal, right? A good sparring-partner will be Craig I think. The last weekend he showed a list of classes and methods that he thinks are essential to do anything useful. A good startpoint for arguing. Norbert
On 4/25/12, Chris Muller <asqueaker@gmail.com> wrote:
I see the "point" of Cuis as to have a small, clean, understandable Smalltalk system.
Which is useful for learning... It's a *general-purpose* system rather than one
geared solely towards business. Pharo, at least to me, feels more like the Java ecosystem -- a platform aiming primarily toward business and generating plenty of marketing "buzz" with frameworks-of-the-month (such as the ones you listed).
And marketing is important as well. Because the general culture of using programming languages is full of it and there is the notion that languages have to be developed and every two or three years there should be something new. In Cuis, Smalltalk _is_ the framework
and users are expected to build on that directly.
Good to spell this out again Smalltalk _is_ the framework However we might need more illustrations for this. --Hannes
In my view, Spoon is about letting the machine generate a small, vertical system from a larger, horizontal system. Pavel, Edgar and you all have been working on making a smaller system for years (good work); but I see the dream of Spoon as delegating that work to the machine, which will do it quickly and accurately. The question at the moment is whether that dream will be realized. Based on Craig's Squeak-Board candidacy announcement, I expect 2012 to be the year Spoon is born into mainstream-use at least in the Squeak community.
On Tue, Apr 24, 2012 at 4:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems.
We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future.
We are spending a lot of time on making the system better. - Fuel - Athens - OPAL - Ghost - Nautilus - Ring - NativeBoost - Zinc - HUGE amount of fixes - Working on a core - Writing a lot of documentation (yes guys) to name a few. We are pushing like hell and getting there.
We spent time building our vision and step by step building it. We are getting there. :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
Stef
On 4/24/12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems.
We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future.
We are spending a lot of time on making the system better.
Good to see this activity list
- Fuel - Athens
Athens is an SVG canvas using Morphic, right? Where is the code?
- OPAL - Ghost
What is Ghost?
- Nautilus - Ring
What is Ring?
- NativeBoost - Zinc - HUGE amount of fixes - Working on a core - Writing a lot of documentation (yes guys)
Is there documentation on Athens yet?
to name a few. We are pushing like hell and getting there.
We spent time building our vision and step by step building it. We are getting there. :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future.
You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free.
Stef
participants (12)
-
blake -
Casimiro de Almeida Barreto -
Chris Muller -
Edgar De Cleene -
Geert Claes -
H. Hirzel -
Janko Mivšek -
Norbert Hartl -
Pavel Krivanek -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe