Meeting Report for 8/18/2010
Locked
123
123
Re: Meeting Report for 8/18/2010
 
|
On 8/24/10 12:23 PM, "Pavel Krivanek" <[hidden email]> wrote: > I still think that Squeakers should entertaint the possibility to > adopt PharoCore (or PharoKernel?) some way as the base. The reasons > are clearly practical - and not only for Smalltalk programmers. Squeak > hardly can keep pace with Pharo. Moreover Pharo starts to have several > full-timers now. And original goals of Squeak are very different from > duplicating of effort already done somewhere else. Squeak has to face > to competition of Pharo and EToys. Squeakers can "fight" them or use > them. Please do not let personal disagreements blind you... > > Cheers > -- Pavel My poor SqueakLight3 wish have the best of Cuis, Pharo and Squeak plus some ideas I have, but clearly can't sell ... If we rip Polymorph and do it unloadable/loadable and let cosmetics to user, my vote is for PharoCore. But if you have some more documented of your current PharoKernel somewhere I don't found/know and this could be used on Mac, my vote is for PharoKernel. Edgar |
Re: Meeting Report for 8/18/2010
|
|
On 8/25/10, Edgar J. De Cleene <[hidden email]> wrote:
> > > > On 8/24/10 12:23 PM, "Pavel Krivanek" <[hidden email]> wrote: > >> I still think that Squeakers should entertaint the possibility to >> adopt PharoCore (or PharoKernel?) some way as the base. The reasons >> are clearly practical - and not only for Smalltalk programmers. Squeak >> hardly can keep pace with Pharo. Moreover Pharo starts to have several >> full-timers now. And original goals of Squeak are very different from >> duplicating of effort already done somewhere else. Squeak has to face >> to competition of Pharo and EToys. Squeakers can "fight" them or use >> them. Please do not let personal disagreements blind you... >> >> Cheers >> -- Pavel > > My poor SqueakLight3 wish have the best of Cuis, Pharo and Squeak plus some > ideas I have, but clearly can't sell ... I assume there is not enough 'marketing'. I assume at least you need more presence on a website where you explain what you are doing. I pretty sure that there are people who will be willing to help you with that. It means that you maintain your own fork which is fine. Please continue with it.... Is your SqueakLight3 based on Squeak4.1 trunk? Or Pharo? I ask this because I'd like to know if it is under the MIT license. I assume that some of the things you load in addition are not but in this case I would not bother too much. Where it the download link? Do you have a read-me.txt with the version history? Cheers --Hannes |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Hannes Hirzel
On Wed, Aug 25, 2010 at 12:21 PM, Hannes Hirzel <[hidden email]> wrote:
> On 8/25/10, Pavel Krivanek <[hidden email]> wrote: >> 2010/8/25 Levente Uzonyi <[hidden email]>: >>> On Tue, 24 Aug 2010, Pavel Krivanek wrote: >>> >>>> On Tue, Aug 24, 2010 at 1:53 PM, Juan Vuletich <[hidden email]> >>>> wrote: >>>>> >>>>> Andreas Raab wrote: >>>>>> >>>>>> On 8/23/2010 4:28 AM, Pavel Krivanek wrote: >>>>>>> >>>>>>> Hi Andreas, >>>>>>> >>>>>>> the latest KernelImage based on Squeak 3.10 is here: >>>>>>> http://comtalk.cz/public/pub/KernelImage/current/ >>>>>>> I continuously compared the image to Squeak and commented the changes. >>>>>>> For more information see http://www.squeaksource.com/KernelImage.html. >>>>>> >>>>>> Thanks Pavel, that's *hugely* helpful. I'm seriously wondering how I >>>>>> could >>>>>> have missed that - the only explanation I have is that this must have >>>>>> happened when I didn't pay any attention to Squeak :-) >>>>>> >>>>>> One thing that I'm not sure about is how to interpret the scripts at >>>>>> the >>>>>> above URL - are they used to create the package structure in the >>>>>> KernelImage >>>>>> repository or are they for something different? >>>>>> >>>>>> In any case, I think that's very good starting point. I'm curious, >>>>>> Juan, >>>>>> how does that stack up to Cuis? Is that similar to the structure you've >>>>>> ended up with or very different? >>>>> >>>>> I have only looked at Pavel's work very briefly, so my comments might be >>>>> wrong. The main focus of KernelImage is about modularization, while the >>>>> main >>>>> focus of Cuis is cleaning. >>>>> >>>>> This means that Cuis doesn't provide a set of packages to build a >>>>> "bigger >>>>> image", and therefore doesn't have a clear structure of how those >>>>> packages >>>>> might be like. On the other hand, it means that KernelImage doesn't >>>>> provide >>>>> simple, efficient, clean code. I mean, with KernelImage you have either >>>>> just >>>>> a headless system, or a a bigger image, with more stuff loaded, but >>>>> without >>>>> significant improvements in code quality. >>>>> >>>>> It seems that there is a lot to learn from KernelImage about the >>>>> modularization of the image. If you want to start with a headless image, >>>>> may >>>>> be you can even start building on top of it. >>>> >>>> With shrinking and cleaning of the system it was always easy to reach >>>> the state where you create a new fork. I wanted to beware it so I >>>> spent lot of time on maintaining of the binding to the original system >>>> (for example see KernelImageOverride on mantis). It was more important >>>> than the next polishing. Unfortunately I cannot say I was really >>>> successful ;-) >>>> >>>>> Cuis is useful if you want to start with a complete, working ST-80 like >>>>> system, including a GUI, dev tools, etc. >>>>> >>>>> As a side note, headless KernelImage is about 2Mb. Cuis (reducing fonts >>>>> to a >>>>> usable minimum) is about 2.9Mb. This might suggest that Cuis has bigger >>>>> "bang for the buck", and this could mean simpler, better code. This >>>>> would >>>>> be >>>>> consistent with the huge amount of hours I've spent cleaning Cuis. >>>>> Somebody >>>>> could try to do a fair comparison between them, though. When I realized >>>>> that >>>>> KernelImage is headless, and therefore, not a easy to browse and study, >>>>> I >>>>> just didn't spend any more time on it. >>>>> >>>>>>> There are several possible approaches: >>>>>>> - take the original KernelImage and adopt it for the latest Squeak. It >>>>>>> should be quite easy. >>>>>>> - do the similar remodularization and patches as the Pharo did. The >>>>>>> package structure of Pharo and Squeak then will be very similar. >>>>>>> - Pharo did a lot of important work on the cleanup of the system, it >>>>>>> has wider and motivated community of developers and its goals are >>>>>>> subset of goals of Squeak. What about to use whole Pharo as the basic >>>>>>> system for Squeak and let Pharo people to finish its modularization >>>>>>> and focus on tasks important for Squeak? Give me week or two and I >>>>>>> will show you that it's possible to load EToys and other Squeak >>>>>>> specific stuff to Pharo... >>>>>> >>>>>> I'm sure it's possible given enough effort. But it won't matter. The >>>>>> issue >>>>>> isn't technical, the rift between Squeak and Pharo is something that is >>>>>> the >>>>>> result of both personal as well philosophical differences. Contrary to >>>>>> which >>>>>> Cuis is much closer to Squeak; not only is Juan a Squeak board member, >>>>>> but >>>>>> the idea of having a system that a single person can understand is dear >>>>>> to >>>>>> all of us, I think :-) >>>>>> >>>>>> Cheers, >>>>>> - Andreas >>>>> >>>>> I fully agree, but I see a clear technical issue. Current Pharo has too >>>>> much >>>>> 'optional stuff' to be considered the basic system. If the Pharo >>>>> modularization efforts lead to a much smaller kernel (perhaps the size >>>>> of >>>>> Cuis or KernelImage), then that could be the basic system. >>>>> >>>>> So it seems that Squeak and Pharo might be walking a similar path to >>>>> system >>>>> modularization. So, personal and social issues aside, what would be nice >>>>> is >>>>> some form of cooperation between those efforts. >>>>> >>>> >>>> I still think that Squeakers should entertaint the possibility to >>>> adopt PharoCore (or PharoKernel?) some way as the base. The reasons >>>> are clearly practical - and not only for Smalltalk programmers. Squeak >>>> hardly can keep pace with Pharo. Moreover Pharo starts to have several >>> >>> Sorry, but I totally don't get what you're talking about. IMHO Pharo's >>> Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think >>> Pharo >>> lacks developers who have enough knowledge to touch those parts of the >>> system and are willing to spend their time on it. But I may be wrong, so >>> please let me know how is PharoKernel/Core better than Squeak. > > > >> Pharoers are preparing Opal and Ocean so at least it is not right that >> they don't have enough courage and skills to touch this parts. As >> someone who tried to be in touch with Pharo development from the >> perspective of my previous modularization effort I had to say that the >> amount of important changes in Pharo is really huge. > > Could you please elaborate on this? Some kind of metrics? (I.e. take > all classes and method names in Squeak with the last change date and > the same thing in Pharo and give some indication what has changed? - > Of course this will be very rough as it does not really show what has > been changed. Touching a method to replace the underscore assignment > by := will show up), maybe you have better idea of metrics. Ok, I'll try to do something. >>>> full-timers now. And original goals of Squeak are very different from >>> >>> Hiring more people doesn't mean it will be better. > Yes > > >>>> duplicating of effort already done somewhere else. Squeak has to face >>> >>> What are the original goals of Squeak besides being a general purpose free >>> Smalltalk? >> >> >From Back to the future: "In December of 1995, the authors found >> themselves wanting a development environment in which to build >> educational software that could be used—and even programmed—by >> non-technical people, and by children. We wanted our software to be >> effective in mass-access media such as PDAs and the Internet, where >> download times and power considerations make compactness essential, >> and where hardware is diverse, and operating systems may change or be >> completely absent. Therefore our ideal system would be a small, >> portable kernel of simple and uniform design that could be adapted >> rapidly to new delivery vehicles." >> >> Smalltalk was only an instrument. >> >>>> to competition of Pharo and EToys. Squeakers can "fight" them or use >>> >>> How is EToys competition to Squeak? Is EToys a free general purpose >>> Smalltalk? >> > > EToys is not a competition to Squeak. Bert Freudenberg says that they > want to move over the Squeakland image to Squeak 4.1 trunk. I assume > that he would appreciate your help, Pavel in this. In particular as > you say such an effort would only take about 2 weeks. I consider this > to be an amazing statement and we are interested in learning from you > how such a thing can be done. Well, if EToys really want to be based on Squeak then it changes everything. >> Of course not. But for people who want to use EToys, the EToys image >> is more natural choice. That was the main reason why Pharoers stopped >> to support it because it was only a dead weight. > For them but not for others that's the point. We still have a common > base and on top of that different distributions. > > For them the concept >> of general purpose Smalltalk (of the Sqeuak's way) is antiquated. > > OK, for them but please note that it is not for other kinds of people. That is not about the beauty of the idea. EToys need a lot of deep refactorings and the existence of EToys fork would disvalue it because people who really use EToys are somewhere else. >> The KernelImage project tried to show that it is possible to have a >> modular Smalltalk with EToys support. But I did it only because it was >> possible not because I really trusted it is a vital concept. > > This is interesting. Could you please elaborate why you think it is > not a vital concept? See above. If EToys will join forces with Squeak than we are in the different situation. -- Pavel > I >> supposed that the fact that we will have EToys in a separate package >> will probably show that nobody cares about its support (however I >> didn't wanted that). > > As far as I understand the situation EToys is supported by the > Squeakland people and they are happy to put it onto Squeak 4.1. But > this question is better answered by Bert Freudenberg. > > >> Please, can you tell me for what target group of users the Squeak is >> and how it differs from Pharo and EToys? Because I'm confused in that. > > Still the original thing - personal digital media plus re-emphasized - > to be a common basis for forks. More details on request. Maybe we > should open another thread where we re-hearse the goals for Squeak 4.2 > (or re-activate an older one). > > >> Cheers, >> -- Pavel > > Again - thank you Pavel for rejoining and contributing in various ways. > > --Hannes > > >>> Levente >>> >>>> them. Please do not let personal disagreements blind you... >>>> >>>> Cheers >>>> -- Pavel >>>> >>> >>> >>> >>> >> >> > > |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Hannes Hirzel
On 8/25/10 2:40 AM, "Hannes Hirzel" <[hidden email]> wrote: > Is SqueakLight or FunSqueak of Edgard maintained? Probably yes, though > on a more occasional basis. Edgar tries to preserve the original > Squeak flavor. Yes, I have it but, seems no people likes. SqueakLight goes for his third life, begins some days before Andreas do the first SqueakCore. I could have up to date with trunk, cleaning from time to time the Experiments folder on ftp, but having all on my own LAN. Having a good set of Mac Intel and PPC, Windoze in all his evil flavours and Ubuntu Linux and doing experiments daily (The iPad still wainting) Through http://www.squeakros.com.ar you can see a Spanish list of links going to computers, not all run all the time for economic reasons. The trade off is build on top the MinimalMorphic Pavel create long time ago ånd I re take some months ago. On top a 7.3 Mb image i can run real life Aida, Seaside+Pier, and some more |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Pavel Krivanek
On 8/25/10, Pavel Krivanek <[hidden email]> wrote:
> On Wed, Aug 25, 2010 at 12:21 PM, Hannes Hirzel <[hidden email]> > wrote: >> On 8/25/10, Pavel Krivanek <[hidden email]> wrote: >>> 2010/8/25 Levente Uzonyi <[hidden email]>: >>>> On Tue, 24 Aug 2010, Pavel Krivanek wrote: >>>> >>>>> On Tue, Aug 24, 2010 at 1:53 PM, Juan Vuletich <[hidden email]> >>>>> wrote: >>>>>> >>>>>> Andreas Raab wrote: >>>>>>> >>>>>>> On 8/23/2010 4:28 AM, Pavel Krivanek wrote: >>>>>>>> >>>>>>>> Hi Andreas, >>>>>>>> >>>>>>>> the latest KernelImage based on Squeak 3.10 is here: >>>>>>>> http://comtalk.cz/public/pub/KernelImage/current/ >>>>>>>> I continuously compared the image to Squeak and commented the >>>>>>>> changes. >>>>>>>> For more information see >>>>>>>> http://www.squeaksource.com/KernelImage.html. >>>>>>> >>>>>>> Thanks Pavel, that's *hugely* helpful. I'm seriously wondering how I >>>>>>> could >>>>>>> have missed that - the only explanation I have is that this must have >>>>>>> happened when I didn't pay any attention to Squeak :-) >>>>>>> >>>>>>> One thing that I'm not sure about is how to interpret the scripts at >>>>>>> the >>>>>>> above URL - are they used to create the package structure in the >>>>>>> KernelImage >>>>>>> repository or are they for something different? >>>>>>> >>>>>>> In any case, I think that's very good starting point. I'm curious, >>>>>>> Juan, >>>>>>> how does that stack up to Cuis? Is that similar to the structure >>>>>>> you've >>>>>>> ended up with or very different? >>>>>> >>>>>> I have only looked at Pavel's work very briefly, so my comments might >>>>>> be >>>>>> wrong. The main focus of KernelImage is about modularization, while >>>>>> the >>>>>> main >>>>>> focus of Cuis is cleaning. >>>>>> >>>>>> This means that Cuis doesn't provide a set of packages to build a >>>>>> "bigger >>>>>> image", and therefore doesn't have a clear structure of how those >>>>>> packages >>>>>> might be like. On the other hand, it means that KernelImage doesn't >>>>>> provide >>>>>> simple, efficient, clean code. I mean, with KernelImage you have >>>>>> either >>>>>> just >>>>>> a headless system, or a a bigger image, with more stuff loaded, but >>>>>> without >>>>>> significant improvements in code quality. >>>>>> >>>>>> It seems that there is a lot to learn from KernelImage about the >>>>>> modularization of the image. If you want to start with a headless >>>>>> image, >>>>>> may >>>>>> be you can even start building on top of it. >>>>> >>>>> With shrinking and cleaning of the system it was always easy to reach >>>>> the state where you create a new fork. I wanted to beware it so I >>>>> spent lot of time on maintaining of the binding to the original system >>>>> (for example see KernelImageOverride on mantis). It was more important >>>>> than the next polishing. Unfortunately I cannot say I was really >>>>> successful ;-) >>>>> >>>>>> Cuis is useful if you want to start with a complete, working ST-80 >>>>>> like >>>>>> system, including a GUI, dev tools, etc. >>>>>> >>>>>> As a side note, headless KernelImage is about 2Mb. Cuis (reducing >>>>>> fonts >>>>>> to a >>>>>> usable minimum) is about 2.9Mb. This might suggest that Cuis has >>>>>> bigger >>>>>> "bang for the buck", and this could mean simpler, better code. This >>>>>> would >>>>>> be >>>>>> consistent with the huge amount of hours I've spent cleaning Cuis. >>>>>> Somebody >>>>>> could try to do a fair comparison between them, though. When I >>>>>> realized >>>>>> that >>>>>> KernelImage is headless, and therefore, not a easy to browse and >>>>>> study, >>>>>> I >>>>>> just didn't spend any more time on it. >>>>>> >>>>>>>> There are several possible approaches: >>>>>>>> - take the original KernelImage and adopt it for the latest Squeak. >>>>>>>> It >>>>>>>> should be quite easy. >>>>>>>> - do the similar remodularization and patches as the Pharo did. The >>>>>>>> package structure of Pharo and Squeak then will be very similar. >>>>>>>> - Pharo did a lot of important work on the cleanup of the system, it >>>>>>>> has wider and motivated community of developers and its goals are >>>>>>>> subset of goals of Squeak. What about to use whole Pharo as the >>>>>>>> basic >>>>>>>> system for Squeak and let Pharo people to finish its modularization >>>>>>>> and focus on tasks important for Squeak? Give me week or two and I >>>>>>>> will show you that it's possible to load EToys and other Squeak >>>>>>>> specific stuff to Pharo... >>>>>>> >>>>>>> I'm sure it's possible given enough effort. But it won't matter. The >>>>>>> issue >>>>>>> isn't technical, the rift between Squeak and Pharo is something that >>>>>>> is >>>>>>> the >>>>>>> result of both personal as well philosophical differences. Contrary >>>>>>> to >>>>>>> which >>>>>>> Cuis is much closer to Squeak; not only is Juan a Squeak board >>>>>>> member, >>>>>>> but >>>>>>> the idea of having a system that a single person can understand is >>>>>>> dear >>>>>>> to >>>>>>> all of us, I think :-) >>>>>>> >>>>>>> Cheers, >>>>>>> - Andreas >>>>>> >>>>>> I fully agree, but I see a clear technical issue. Current Pharo has >>>>>> too >>>>>> much >>>>>> 'optional stuff' to be considered the basic system. If the Pharo >>>>>> modularization efforts lead to a much smaller kernel (perhaps the size >>>>>> of >>>>>> Cuis or KernelImage), then that could be the basic system. >>>>>> >>>>>> So it seems that Squeak and Pharo might be walking a similar path to >>>>>> system >>>>>> modularization. So, personal and social issues aside, what would be >>>>>> nice >>>>>> is >>>>>> some form of cooperation between those efforts. >>>>>> >>>>> >>>>> I still think that Squeakers should entertaint the possibility to >>>>> adopt PharoCore (or PharoKernel?) some way as the base. The reasons >>>>> are clearly practical - and not only for Smalltalk programmers. Squeak >>>>> hardly can keep pace with Pharo. Moreover Pharo starts to have several >>>> >>>> Sorry, but I totally don't get what you're talking about. IMHO Pharo's >>>> Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think >>>> Pharo >>>> lacks developers who have enough knowledge to touch those parts of the >>>> system and are willing to spend their time on it. But I may be wrong, so >>>> please let me know how is PharoKernel/Core better than Squeak. >> >> >> >>> Pharoers are preparing Opal and Ocean so at least it is not right that >>> they don't have enough courage and skills to touch this parts. As >>> someone who tried to be in touch with Pharo development from the >>> perspective of my previous modularization effort I had to say that the >>> amount of important changes in Pharo is really huge. >> >> Could you please elaborate on this? Some kind of metrics? (I.e. take >> all classes and method names in Squeak with the last change date and >> the same thing in Pharo and give some indication what has changed? - >> Of course this will be very rough as it does not really show what has >> been changed. Touching a method to replace the underscore assignment >> by := will show up), maybe you have better idea of metrics. > > Ok, I'll try to do something. > >>>>> full-timers now. And original goals of Squeak are very different from >>>> >>>> Hiring more people doesn't mean it will be better. >> Yes >> >> >>>>> duplicating of effort already done somewhere else. Squeak has to face >>>> >>>> What are the original goals of Squeak besides being a general purpose >>>> free >>>> Smalltalk? >>> >>> >From Back to the future: "In December of 1995, the authors found >>> themselves wanting a development environment in which to build >>> educational software that could be used—and even programmed—by >>> non-technical people, and by children. We wanted our software to be >>> effective in mass-access media such as PDAs and the Internet, where >>> download times and power considerations make compactness essential, >>> and where hardware is diverse, and operating systems may change or be >>> completely absent. Therefore our ideal system would be a small, >>> portable kernel of simple and uniform design that could be adapted >>> rapidly to new delivery vehicles." >>> >>> Smalltalk was only an instrument. >>> >>>>> to competition of Pharo and EToys. Squeakers can "fight" them or use >>>> >>>> How is EToys competition to Squeak? Is EToys a free general purpose >>>> Smalltalk? >>> >> >> EToys is not a competition to Squeak. Bert Freudenberg says that they >> want to move over the Squeakland image to Squeak 4.1 trunk. I assume >> that he would appreciate your help, Pavel in this. In particular as >> you say such an effort would only take about 2 weeks. I consider this >> to be an amazing statement and we are interested in learning from you >> how such a thing can be done. > > Well, if EToys really want to be based on Squeak then it changes everything. Yes, we are talking about basing a product on Squeak 4.1 trunk which runs on 1 to 2 million computers by now. > >>> Of course not. But for people who want to use EToys, the EToys image >>> is more natural choice. That was the main reason why Pharoers stopped >>> to support it because it was only a dead weight. >> For them but not for others that's the point. We still have a common >> base and on top of that different distributions. >> >> For them the concept >>> of general purpose Smalltalk (of the Sqeuak's way) is antiquated. >> >> OK, for them but please note that it is not for other kinds of people. > > That is not about the beauty of the idea. EToys need a lot of deep > refactorings and the existence of EToys fork would disvalue it because > people who really use EToys are somewhere else. > >>> The KernelImage project tried to show that it is possible to have a >>> modular Smalltalk with EToys support. But I did it only because it was >>> possible not because I really trusted it is a vital concept. >> >> This is interesting. Could you please elaborate why you think it is >> not a vital concept? > > See above. If EToys will join forces with Squeak than we are in the > different situation. Yes, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152521.html (Bert Freudenberg says that he want to do the same thing as Andreas. Andreas moved the Cobalt code over so that it is based on Squeak 4.1 trunk) > -- Pavel I'm glad about this conclusion. --Hannes >> I >>> supposed that the fact that we will have EToys in a separate package >>> will probably show that nobody cares about its support (however I >>> didn't wanted that). >> >> As far as I understand the situation EToys is supported by the >> Squeakland people and they are happy to put it onto Squeak 4.1. But >> this question is better answered by Bert Freudenberg. >> >> >>> Please, can you tell me for what target group of users the Squeak is >>> and how it differs from Pharo and EToys? Because I'm confused in that. >> >> Still the original thing - personal digital media plus re-emphasized - >> to be a common basis for forks. More details on request. Maybe we >> should open another thread where we re-hearse the goals for Squeak 4.2 >> (or re-activate an older one). >> >> >>> Cheers, >>> -- Pavel >> >> Again - thank you Pavel for rejoining and contributing in various ways. >> >> --Hannes >> >> >>>> Levente >>>> >>>>> them. Please do not let personal disagreements blind you... >>>>> >>>>> Cheers >>>>> -- Pavel >>>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > |
SqueakLight3 again (was Re: [squeak-dev] Re: Meeting Report for 8/18/2010)
|
|
In reply to this post by Hannes Hirzel
On 8/25/10 7:51 AM, "Hannes Hirzel" <[hidden email]> wrote: > Is your SqueakLight3 based on Squeak4.1 trunk? Or Pharo? I ask this > because I'd like to know if it is under the MIT license. > > I assume that some of the things you load in addition are not but in > this case I would not bother too much. > > Where it the download link? Do you have a read-me.txt with the version > history? > > Cheers > --Hannes At this point SqueakLight3 is trunk unloaded as I said in past mails and with few changes from me so all is MIT. Unlucky us , no time for documentation but I try get and do some. Differences: The set of unloaded packages is suited to what you need later if you wish go to more complex images. Have a modified Monticello and only updates packages into the image. This modified Monticello lets load complex like .sar things (Rompecabezas and TaiPei in SqueakSource), we talked about this some time ago. Also I made "class repositories" into Experiments folder with classes at the time of the first build. The idea is the image is "smarter" and via dnu could load any missed classes from here. As I said, we could go back to point when Closures change the previous system and redo all again more clean. For me, no image with small footprint and less classes worth if we can't grow again to any arbitrary complex image in a documented way. I know Andreas, Juan and Pavel are the Wonderful Masters , ask let me learn from they working... Edgar |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Hannes Hirzel
On 8/25/10, Hannes Hirzel <[hidden email]> wrote:
> On 8/25/10, Pavel Krivanek <[hidden email]> wrote: >> On Wed, Aug 25, 2010 at 12:21 PM, Hannes Hirzel <[hidden email]> >> wrote: >>> On 8/25/10, Pavel Krivanek <[hidden email]> wrote: >>>> 2010/8/25 Levente Uzonyi <[hidden email]>: >>>>> On Tue, 24 Aug 2010, Pavel Krivanek wrote: >>>>> >>>>>> On Tue, Aug 24, 2010 at 1:53 PM, Juan Vuletich <[hidden email]> >>>>>> wrote: >>>>>>> >>>>>>> Andreas Raab wrote: >>>>>>>> >>>>>>>> On 8/23/2010 4:28 AM, Pavel Krivanek wrote: >>>>>>>>> >>>>>>>>> Hi Andreas, >>>>>>>>> >>>>>>>>> the latest KernelImage based on Squeak 3.10 is here: >>>>>>>>> http://comtalk.cz/public/pub/KernelImage/current/ >>>>>>>>> I continuously compared the image to Squeak and commented the >>>>>>>>> changes. >>>>>>>>> For more information see >>>>>>>>> http://www.squeaksource.com/KernelImage.html. >>>>>>>> >>>>>>>> Thanks Pavel, that's *hugely* helpful. I'm seriously wondering how >>>>>>>> I >>>>>>>> could >>>>>>>> have missed that - the only explanation I have is that this must >>>>>>>> have >>>>>>>> happened when I didn't pay any attention to Squeak :-) >>>>>>>> >>>>>>>> One thing that I'm not sure about is how to interpret the scripts >>>>>>>> at >>>>>>>> the >>>>>>>> above URL - are they used to create the package structure in the >>>>>>>> KernelImage >>>>>>>> repository or are they for something different? >>>>>>>> >>>>>>>> In any case, I think that's very good starting point. I'm curious, >>>>>>>> Juan, >>>>>>>> how does that stack up to Cuis? Is that similar to the structure >>>>>>>> you've >>>>>>>> ended up with or very different? >>>>>>> >>>>>>> I have only looked at Pavel's work very briefly, so my comments >>>>>>> might >>>>>>> be >>>>>>> wrong. The main focus of KernelImage is about modularization, while >>>>>>> the >>>>>>> main >>>>>>> focus of Cuis is cleaning. >>>>>>> >>>>>>> This means that Cuis doesn't provide a set of packages to build a >>>>>>> "bigger >>>>>>> image", and therefore doesn't have a clear structure of how those >>>>>>> packages >>>>>>> might be like. On the other hand, it means that KernelImage doesn't >>>>>>> provide >>>>>>> simple, efficient, clean code. I mean, with KernelImage you have >>>>>>> either >>>>>>> just >>>>>>> a headless system, or a a bigger image, with more stuff loaded, but >>>>>>> without >>>>>>> significant improvements in code quality. >>>>>>> >>>>>>> It seems that there is a lot to learn from KernelImage about the >>>>>>> modularization of the image. If you want to start with a headless >>>>>>> image, >>>>>>> may >>>>>>> be you can even start building on top of it. >>>>>> >>>>>> With shrinking and cleaning of the system it was always easy to reach >>>>>> the state where you create a new fork. I wanted to beware it so I >>>>>> spent lot of time on maintaining of the binding to the original >>>>>> system >>>>>> (for example see KernelImageOverride on mantis). It was more >>>>>> important >>>>>> than the next polishing. Unfortunately I cannot say I was really >>>>>> successful ;-) >>>>>> >>>>>>> Cuis is useful if you want to start with a complete, working ST-80 >>>>>>> like >>>>>>> system, including a GUI, dev tools, etc. >>>>>>> >>>>>>> As a side note, headless KernelImage is about 2Mb. Cuis (reducing >>>>>>> fonts >>>>>>> to a >>>>>>> usable minimum) is about 2.9Mb. This might suggest that Cuis has >>>>>>> bigger >>>>>>> "bang for the buck", and this could mean simpler, better code. This >>>>>>> would >>>>>>> be >>>>>>> consistent with the huge amount of hours I've spent cleaning Cuis. >>>>>>> Somebody >>>>>>> could try to do a fair comparison between them, though. When I >>>>>>> realized >>>>>>> that >>>>>>> KernelImage is headless, and therefore, not a easy to browse and >>>>>>> study, >>>>>>> I >>>>>>> just didn't spend any more time on it. >>>>>>> >>>>>>>>> There are several possible approaches: >>>>>>>>> - take the original KernelImage and adopt it for the latest >>>>>>>>> Squeak. >>>>>>>>> It >>>>>>>>> should be quite easy. >>>>>>>>> - do the similar remodularization and patches as the Pharo did. >>>>>>>>> The >>>>>>>>> package structure of Pharo and Squeak then will be very similar. >>>>>>>>> - Pharo did a lot of important work on the cleanup of the system, >>>>>>>>> it >>>>>>>>> has wider and motivated community of developers and its goals are >>>>>>>>> subset of goals of Squeak. What about to use whole Pharo as the >>>>>>>>> basic >>>>>>>>> system for Squeak and let Pharo people to finish its >>>>>>>>> modularization >>>>>>>>> and focus on tasks important for Squeak? Give me week or two and I >>>>>>>>> will show you that it's possible to load EToys and other Squeak >>>>>>>>> specific stuff to Pharo... >>>>>>>> >>>>>>>> I'm sure it's possible given enough effort. But it won't matter. >>>>>>>> The >>>>>>>> issue >>>>>>>> isn't technical, the rift between Squeak and Pharo is something >>>>>>>> that >>>>>>>> is >>>>>>>> the >>>>>>>> result of both personal as well philosophical differences. Contrary >>>>>>>> to >>>>>>>> which >>>>>>>> Cuis is much closer to Squeak; not only is Juan a Squeak board >>>>>>>> member, >>>>>>>> but >>>>>>>> the idea of having a system that a single person can understand is >>>>>>>> dear >>>>>>>> to >>>>>>>> all of us, I think :-) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> - Andreas >>>>>>> >>>>>>> I fully agree, but I see a clear technical issue. Current Pharo has >>>>>>> too >>>>>>> much >>>>>>> 'optional stuff' to be considered the basic system. If the Pharo >>>>>>> modularization efforts lead to a much smaller kernel (perhaps the >>>>>>> size >>>>>>> of >>>>>>> Cuis or KernelImage), then that could be the basic system. >>>>>>> >>>>>>> So it seems that Squeak and Pharo might be walking a similar path to >>>>>>> system >>>>>>> modularization. So, personal and social issues aside, what would be >>>>>>> nice >>>>>>> is >>>>>>> some form of cooperation between those efforts. >>>>>>> >>>>>> >>>>>> I still think that Squeakers should entertaint the possibility to >>>>>> adopt PharoCore (or PharoKernel?) some way as the base. The reasons >>>>>> are clearly practical - and not only for Smalltalk programmers. >>>>>> Squeak >>>>>> hardly can keep pace with Pharo. Moreover Pharo starts to have >>>>>> several >>>>> >>>>> Sorry, but I totally don't get what you're talking about. IMHO Pharo's >>>>> Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think >>>>> Pharo >>>>> lacks developers who have enough knowledge to touch those parts of the >>>>> system and are willing to spend their time on it. But I may be wrong, >>>>> so >>>>> please let me know how is PharoKernel/Core better than Squeak. >>> >>> >>> >>>> Pharoers are preparing Opal and Ocean so at least it is not right that >>>> they don't have enough courage and skills to touch this parts. As >>>> someone who tried to be in touch with Pharo development from the >>>> perspective of my previous modularization effort I had to say that the >>>> amount of important changes in Pharo is really huge. >>> >>> Could you please elaborate on this? Some kind of metrics? (I.e. take >>> all classes and method names in Squeak with the last change date and >>> the same thing in Pharo and give some indication what has changed? - >>> Of course this will be very rough as it does not really show what has >>> been changed. Touching a method to replace the underscore assignment >>> by := will show up), maybe you have better idea of metrics. >> >> Ok, I'll try to do something. >> >>>>>> full-timers now. And original goals of Squeak are very different from >>>>> >>>>> Hiring more people doesn't mean it will be better. >>> Yes >>> >>> >>>>>> duplicating of effort already done somewhere else. Squeak has to face >>>>> >>>>> What are the original goals of Squeak besides being a general purpose >>>>> free >>>>> Smalltalk? >>>> >>>> >From Back to the future: "In December of 1995, the authors found >>>> themselves wanting a development environment in which to build >>>> educational software that could be used—and even programmed—by >>>> non-technical people, and by children. We wanted our software to be >>>> effective in mass-access media such as PDAs and the Internet, where >>>> download times and power considerations make compactness essential, >>>> and where hardware is diverse, and operating systems may change or be >>>> completely absent. Therefore our ideal system would be a small, >>>> portable kernel of simple and uniform design that could be adapted >>>> rapidly to new delivery vehicles." >>>> >>>> Smalltalk was only an instrument. >>>> >>>>>> to competition of Pharo and EToys. Squeakers can "fight" them or use >>>>> >>>>> How is EToys competition to Squeak? Is EToys a free general purpose >>>>> Smalltalk? >>>> >>> >>> EToys is not a competition to Squeak. Bert Freudenberg says that they >>> want to move over the Squeakland image to Squeak 4.1 trunk. I assume >>> that he would appreciate your help, Pavel in this. In particular as >>> you say such an effort would only take about 2 weeks. I consider this >>> to be an amazing statement and we are interested in learning from you >>> how such a thing can be done. >> >> Well, if EToys really want to be based on Squeak then it changes >> everything. > > Yes, we are talking about basing a product on Squeak 4.1 trunk which > runs on 1 to 2 million computers by now. > >> >>>> Of course not. But for people who want to use EToys, the EToys image >>>> is more natural choice. That was the main reason why Pharoers stopped >>>> to support it because it was only a dead weight. >>> For them but not for others that's the point. We still have a common >>> base and on top of that different distributions. >>> >>> For them the concept >>>> of general purpose Smalltalk (of the Sqeuak's way) is antiquated. >>> >>> OK, for them but please note that it is not for other kinds of people. >> >> That is not about the beauty of the idea. EToys need a lot of deep >> refactorings and the existence of EToys fork would disvalue it because >> people who really use EToys are somewhere else. >> >>>> The KernelImage project tried to show that it is possible to have a >>>> modular Smalltalk with EToys support. But I did it only because it was >>>> possible not because I really trusted it is a vital concept. >>> >>> This is interesting. Could you please elaborate why you think it is >>> not a vital concept? >> >> See above. If EToys will join forces with Squeak than we are in the >> different situation. > > Yes, see > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152521.html > (Bert Freudenberg says that he want to do the same thing as Andreas. > Andreas moved the Cobalt code over so that it is based on Squeak 4.1 > trunk) And here http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149923.html Monticello-based updates for Etoys Bert Freudenberg gives the information where the EToys development is heading for and gives the relevant links for the sources. >> -- Pavel > > I'm glad about this conclusion. > > --Hannes > > >>> I >>>> supposed that the fact that we will have EToys in a separate package >>>> will probably show that nobody cares about its support (however I >>>> didn't wanted that). >>> >>> As far as I understand the situation EToys is supported by the >>> Squeakland people and they are happy to put it onto Squeak 4.1. But >>> this question is better answered by Bert Freudenberg. >>> >>> >>>> Please, can you tell me for what target group of users the Squeak is >>>> and how it differs from Pharo and EToys? Because I'm confused in that. >>> >>> Still the original thing - personal digital media plus re-emphasized - >>> to be a common basis for forks. More details on request. Maybe we >>> should open another thread where we re-hearse the goals for Squeak 4.2 >>> (or re-activate an older one). >>> >>> >>>> Cheers, >>>> -- Pavel >>> >>> Again - thank you Pavel for rejoining and contributing in various ways. >>> >>> --Hannes >>> >>> >>>>> Levente >>>>> >>>>>> them. Please do not let personal disagreements blind you... >>>>>> >>>>>> Cheers >>>>>> -- Pavel >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Hannes Hirzel
>>>>> "Hannes" == Hannes Hirzel <[hidden email]> writes:
Hannes> Please note that in the meeting report this thread is about Randal Hannes> says that he wants to contact the other Squeak based projects to talk Hannes> about a minimal core. Nope, that's a meme collision. I'm contacting other Squeak forks (and folks :) about a "users of Squeak et. al." survey, not about a minimal core. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
survey (was: Meeting Report for 8/18/2010)
|
|
Randal L. Schwartz wrote on Wed, 25 Aug 2010 11:29:27 -0700
> >>>>> Hannes Hirzel writes: > > Hannes> Please note that in the meeting report this thread is about Randal > Hannes> says that he wants to contact the other Squeak based projects to talk > Hannes> about a minimal core. > > Nope, that's a meme collision. I'm contacting other Squeak forks (and > folks :) about a "users of Squeak et. al." survey, not about a minimal > core. Just to give a little more detail about this, it was decided that it would be a nice idea to do some kind of survey to find out what people are doing with Squeak. For example, if you are using it for robotics wouldn't it be great to find out that three other groups around the world are also working on this? One simple way to have such a survey would be just to post some questions here and have anyone interested reply. But then we would miss many people who do have a relation with Squeak but don't read squeak-dev. Randal volunteered to try to contact as many other groups as possible (I know a few - we should try to make a list) and see who would like to participate in such a survey and how we should do it (probably using some existing tool somewhere more neutral than squeak.org). -- Jecel |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Pavel Krivanek
On Wed, 25 Aug 2010, Pavel Krivanek wrote:
> 2010/8/25 Levente Uzonyi <[hidden email]>: snip >> >> Sorry, but I totally don't get what you're talking about. IMHO Pharo's >> Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think Pharo >> lacks developers who have enough knowledge to touch those parts of the >> system and are willing to spend their time on it. But I may be wrong, so >> please let me know how is PharoKernel/Core better than Squeak. > > Pharoers are preparing Opal and Ocean so at least it is not right that > they don't have enough courage and skills to touch this parts. As Those are "external" packages. Maybe they will replace the Compiler and Network packages in Pharo someday. But if they can be changed in Pharo, it's very likely that they can be changed in Squeak if needed. I think Ocean won't be succesful for networking with Alien and Opal will hardly have the same performance as the current compiler, though both packages have several other advantages. Anyway, these aren't examples for "Pharo developers enhancing the existing packages" which is what I was talking about. > someone who tried to be in touch with Pharo development from the > perspective of my previous modularization effort I had to say that the > amount of important changes in Pharo is really huge. You mean those changes which weren't taken from Squeak? > >>> full-timers now. And original goals of Squeak are very different from >> >> Hiring more people doesn't mean it will be better. >> >>> duplicating of effort already done somewhere else. Squeak has to face >> >> What are the original goals of Squeak besides being a general purpose free >> Smalltalk? > >> From Back to the future: "In December of 1995, the authors found > themselves wanting a development environment in which to build > educational software that could be used?and even programmed?by > non-technical people, and by children. We wanted our software to be > effective in mass-access media such as PDAs and the Internet, where > download times and power considerations make compactness essential, > and where hardware is diverse, and operating systems may change or be > completely absent. Therefore our ideal system would be a small, > portable kernel of simple and uniform design that could be adapted > rapidly to new delivery vehicles." > > Smalltalk was only an instrument. The goals were to build a portable VM and something like EToys or Scratch? If so, those goals were reached long time ago. > >>> to competition of Pharo and EToys. Squeakers can "fight" them or use >> >> How is EToys competition to Squeak? Is EToys a free general purpose >> Smalltalk? > > Of course not. But for people who want to use EToys, the EToys image > is more natural choice. That was the main reason why Pharoers stopped > to support it because it was only a dead weight. For them the concept > of general purpose Smalltalk (of the Sqeuak's way) is antiquated. > > The KernelImage project tried to show that it is possible to have a > modular Smalltalk with EToys support. But I did it only because it was > possible not because I really trusted it is a vital concept. I > supposed that the fact that we will have EToys in a separate package > will probably show that nobody cares about its support (however I > didn't wanted that). > > Please, can you tell me for what target group of users the Squeak is > and how it differs from Pharo and EToys? Because I'm confused in that. Pharo originally targeted developers(*), but now it has the same target audience as Squeak. Levente (*) Though I didn't see Stephane's presentation at ESUG 2009, but people were fascinated by it and foretold the death of Squeak, even though Pharo wasn't really different from Squeak+Polymorph back then: http://www.cincomsmalltalk.com/userblogs/mls/blogView?entry=3429226129 But they were proven wrong. Pharo 1.0 was beta at that time, while Squeak's "New Community Developement Model" just started. Pharo 1.0 was released on 15 April, 2010, while a week later (on 23 April, 2010) Squeak 4.1 was released which was far ahead of Pharo 1.0. > > Cheers, > -- Pavel > >> Levente >> >>> them. Please do not let personal disagreements blind you... >>> >>> Cheers >>> -- Pavel >>> >> >> >> >> > > |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Miguel Cobá
On Tue, 24 Aug 2010, Miguel Enrique Cobá Martínez wrote:
> El mar, 24-08-2010 a las 20:47 -0700, Andreas Raab escribió: >> On 8/24/2010 8:23 PM, Miguel Enrique Cobá Martínez wrote: >>> El mar, 24-08-2010 a las 17:19 -0700, Andreas Raab escribió: >>>> Don't feed this troll. >>>> >>>> - A. >>> >>> Come on Andreas, what is this attitude of letting your friends to say >>> what they want but jumping to put a troll label to any other that think >>> different, Isn't mature. >> >> I think it's perfectly mature to call a troll a troll while letting >> people who are presenting criticism in good faith (such as Pavel) say >> what they want to say. That is exactly the difference between the two. > > Well, I suppose that Levente's comment about the capabilities of the > pharo developers is in good faith too and that is the reason that it is > permitted in this list. emphasize the part you missed: "I think Pharo lacks developers who have enough knowledge to touch those parts of the system _and_ are willing to spend their time on it." The "and" is very important, it's not "or" as you interpreted it. > >> >> Also, if this were your first troll, I'd give you a bit more leeway. But >> it's not, you have a history of making inflammatory comments on this >> list and I don't want others to fall for your trap. > > Considering your own history of burning very capable developers in the > past and that you were a key player in the events that lead to the Pharo > fork from Squeak, I suppose that I must feel very honored to be called a > troll by you. > >> >> In short, if you're commenting with the purpose of improving Squeak, >> you're welcome. If indeed that was your intention, then I'm looking >> forward to your elaboration and contributions on how to improve Squeak. >> However, if you're commenting with the only purpose of proving the >> superiority of Pharo, you're not. You can post those comments on the >> Pharo list where I'm sure they will be welcome. > > No, I'm not saying that Pharo is better that Squeak, in fact my response > to Levente's comment was, just as his, preceded by IMHO. That is, no > very humble from him nor from me. > > Now, he in fact suggested that the developers on Pharo were lesser > capable (and maybe we are, but that don't stops us from improving Pharo > a little each day) and that even by hiring full time developers, Pharo > couldn't match the level of expertise that the squeak developers have. > That is really not humble at all. > > Finally I was responding to a comment by Levente that seem to me very > offensive to the Pharo developers. Had he say that in any other list I See above. Levente > will have respond all the same, isn't a Squeak list trolling as you put > it. So think what you want. > >> >> Cheers, >> - Andreas >> >>> This is your private club it appears, by invite only. Good luck Pavel! >>> >>>> >>>> On 8/24/2010 4:55 PM, Miguel Enrique Cobá Martínez wrote: >>>>> El mié, 25-08-2010 a las 01:09 +0200, Levente Uzonyi escribió: >>>>> >>>>>> Sorry, but I totally don't get what you're talking about. IMHO Pharo's >>>>>> Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think >>>>>> Pharo lacks developers who have enough knowledge to touch those parts of >>>>>> the system and are willing to spend their time on it. But I may be wrong, >>>>>> so please let me know how is PharoKernel/Core better than Squeak. >>>>> >>>>> >>>>> IMHO Squeak's >>>>> Business penetration/Comercial apps/Look&Feel/Website/Logo/new blood/ is >>>>> (far) behind Pharo's. >>>>> >>>>>>> full-timers now. And original goals of Squeak are very different from >>>>>> >>>>>> Hiring more people doesn't mean it will be better. >>>>> >>>>> This sound like only a few genius are capable of touching those parts, >>>>> very humble indeed. >>>>> >>>>> Now, shoot all you have! :) >>>>> >>>> >>>> >>> >> >> > > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Levente Uzonyi-2
2010/8/26 Levente Uzonyi <[hidden email]>:
> On Wed, 25 Aug 2010, Pavel Krivanek wrote: > >> 2010/8/25 Levente Uzonyi <[hidden email]>: > > snip > >>> >>> Sorry, but I totally don't get what you're talking about. IMHO Pharo's >>> Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think >>> Pharo >>> lacks developers who have enough knowledge to touch those parts of the >>> system and are willing to spend their time on it. But I may be wrong, so >>> please let me know how is PharoKernel/Core better than Squeak. >> >> Pharoers are preparing Opal and Ocean so at least it is not right that >> they don't have enough courage and skills to touch this parts. As > > Those are "external" packages. Maybe they will replace the Compiler and > Network packages in Pharo someday. But if they can be changed in Pharo, it's > very likely that they can be changed in Squeak if needed. I think Ocean > won't be succesful for networking with Alien and Opal will hardly have the > same performance as the current compiler, though both packages have several > other advantages. > Anyway, these aren't examples for "Pharo developers enhancing the existing > packages" which is what I was talking about. > >> someone who tried to be in touch with Pharo development from the >> perspective of my previous modularization effort I had to say that the >> amount of important changes in Pharo is really huge. > > You mean those changes which weren't taken from Squeak? > >> >>>> full-timers now. And original goals of Squeak are very different from >>> >>> Hiring more people doesn't mean it will be better. >>> >>>> duplicating of effort already done somewhere else. Squeak has to face >>> >>> What are the original goals of Squeak besides being a general purpose >>> free >>> Smalltalk? >> >>> From Back to the future: "In December of 1995, the authors found >> >> themselves wanting a development environment in which to build >> educational software that could be used?and even programmed?by >> non-technical people, and by children. We wanted our software to be >> effective in mass-access media such as PDAs and the Internet, where >> download times and power considerations make compactness essential, >> and where hardware is diverse, and operating systems may change or be >> completely absent. Therefore our ideal system would be a small, >> portable kernel of simple and uniform design that could be adapted >> rapidly to new delivery vehicles." >> >> Smalltalk was only an instrument. > > The goals were to build a portable VM and something like EToys or Scratch? > If so, those goals were reached long time ago. > >> >>>> to competition of Pharo and EToys. Squeakers can "fight" them or use >>> >>> How is EToys competition to Squeak? Is EToys a free general purpose >>> Smalltalk? >> >> Of course not. But for people who want to use EToys, the EToys image >> is more natural choice. That was the main reason why Pharoers stopped >> to support it because it was only a dead weight. For them the concept >> of general purpose Smalltalk (of the Sqeuak's way) is antiquated. >> >> The KernelImage project tried to show that it is possible to have a >> modular Smalltalk with EToys support. But I did it only because it was >> possible not because I really trusted it is a vital concept. I >> supposed that the fact that we will have EToys in a separate package >> will probably show that nobody cares about its support (however I >> didn't wanted that). >> >> Please, can you tell me for what target group of users the Squeak is >> and how it differs from Pharo and EToys? Because I'm confused in that. > > Pharo originally targeted developers(*), but now it has the same target > audience as Squeak. > > > Levente > > (*) Though I didn't see Stephane's presentation at ESUG 2009, but people > were fascinated by it and foretold the death of Squeak, even though Pharo > wasn't really different from Squeak+Polymorph back then: > http://www.cincomsmalltalk.com/userblogs/mls/blogView?entry=3429226129 > But they were proven wrong. Pharo 1.0 was beta at that time, while Squeak's > "New Community Developement Model" just started. Pharo 1.0 was released on > 15 April, 2010, while a week later (on 23 April, 2010) Squeak 4.1 was > released which was far ahead of Pharo 1.0. > This is true, but in my sense entirely explained by the fact Pharo barrier to commit is higher... This is due to higher expectations in process quality... ... like filling http://code.google.com/p/pharo/issues/list before any change, and a bit more formal commit procedure (SLICES, test cases etc...) ... and like reduced set of people taking responsibility to control and integrate changes (the process is more demanding than Squeak which is a weak point of Pharo organization so far). Trunk organization is really light with lower expectations in process quality, but is the prefect fit to my own taste, though i deplored several times that important decisions are not really traced... (a mailing list archive is not the ideal repository for these). Nicolas >> >> Cheers, >> -- Pavel >> >>> Levente >>> >>>> them. Please do not let personal disagreements blind you... >>>> >>>> Cheers >>>> -- Pavel >>>> >>> >>> >>> >>> >> >> > > |
Re: Meeting Report for 8/18/2010
|
|
On 8/26/2010 2:03 PM, Nicolas Cellier wrote:
> Trunk organization is really light with lower expectations in process > quality, but is the prefect fit to my own taste, though i deplored > several times that important decisions are not really traced... (a > mailing list archive is not the ideal repository for these). Well, in light of having more and better documentation, should we start a HelpSystem book for documenting such issues as we go? It might actually be a nice journal of the journey we're taking, that we talked about etc. Alternatively, we could use a blog to write summaries of such discussions. Cheers, - Andreas |
Re: Meeting Report for 8/18/2010
|
|
2010/8/26 Andreas Raab <[hidden email]>:
> On 8/26/2010 2:03 PM, Nicolas Cellier wrote: >> >> Trunk organization is really light with lower expectations in process >> quality, but is the prefect fit to my own taste, though i deplored >> several times that important decisions are not really traced... (a >> mailing list archive is not the ideal repository for these). > > Well, in light of having more and better documentation, should we start a > HelpSystem book for documenting such issues as we go? It might actually be a > nice journal of the journey we're taking, that we talked about etc. > Alternatively, we could use a blog to write summaries of such discussions. > > Cheers, > - Andreas > > Yes, two nice alternatives. Of course such effort does not come for free. Maybe the collaborative option would be a bit more sustainable... Nicolas |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Levente Uzonyi-2
On 8/26/2010 12:32 PM, Levente Uzonyi wrote:
> Those are "external" packages. Maybe they will replace the Compiler and > Network packages in Pharo someday. But if they can be changed in Pharo, > it's very likely that they can be changed in Squeak if needed. I think > Ocean won't be succesful for networking with Alien and Opal will hardly > have the same performance as the current compiler, though both packages > have several other advantages. I don't think the two are quite comparable. I haven't looked at the details but isn't Opal basically NewCompiler with a better name? So I would expect it to be fairly practical although probably quite a bit slower. Last time I compared there was a 4x speed difference between NewCompiler and NowCompiler (better name than "Old"Compiler :-) but I don't know if that's still the case and with Cog you get a 3x speedup so it may just work out :-) Ocean on the other hand looks more like a demo than an actual working library. There isn't even a loopback server implemented yet and so far not even a hint about how to address socket notifications. See, the problem is that from what I've seen it looks as if Ocean is making blocking socket calls. Which makes it quite difficult to implement a loopback server if your accept() call is blocking the VM and you simply can't connect() to it. And unfortunately the simple solution to address this (using a delay-driven polling select loop) performs and scales very poorly. Good enough for a demo, sure, but not for production use. The "real" solution to this problem -implementing a threaded FFI and callback interface- on the other hand is *extremely* hard[*]. Eliot has been working on this problem for several months now and we only just got to the point where we can make *some* threaded calls but it's a long way to go before there's going to be a general solution and it will probably include a rewrite of the object memory and a new garbage collector. So while I can see Opal actually being used if one is willing to accept some performance impact, I severely doubt that any Seaside users will be willing to replace the Squeak socket plugin with Ocean any time soon. [*] FWIW, this is also why I don't really buy the argument that porting to new platforms would be easier when using Ocean instead of the socket plugin. In Squeak's plugin interface, anyone who understands C and sockets can implement the support code. Which is not a huge number of people but you can find them. But if the requirement for network support is implementing a threaded callback interface on the underlying ABI and platform, how many people do you know who could *possibly* do that? I know exactly one, and we hired him. What makes Squeak portable is that people can chip away on little bits at a time. The first version of the Android VM didn't have socket support (neither did the initial Windows port btw), but someone found the time to work on it and now the support is there. And so there are people here and there who can help but I don't think anyone of the people who are helping with Android would be up for taking on the task of writing any kind of FFI. In fact, if that had been a requirement I would not even have started the port since I know to little about the underlying ABI. But I *do* know how to use a C compiler, and I do know sockets. Oops. This is too long for a foot note. Apologies for the digression :-) Cheers, - Andreas |
Re: Meeting Report for 8/18/2010
|
|
In reply to this post by Nicolas Cellier
On 8/26/10, Nicolas Cellier <[hidden email]> wrote:
> 2010/8/26 Andreas Raab <[hidden email]>: >> On 8/26/2010 2:03 PM, Nicolas Cellier wrote: >>> >>> Trunk organization is really light with lower expectations in process >>> quality, but is the prefect fit to my own taste, though i deplored >>> several times that important decisions are not really traced... (a >>> mailing list archive is not the ideal repository for these). >> >> Well, in light of having more and better documentation, should we start a >> HelpSystem book for documenting such issues as we go? It might actually be >> a >> nice journal of the journey we're taking, that we talked about etc. >> Alternatively, we could use a blog to write summaries of such discussions. >> >> Cheers, >> - Andreas >> >> > > Yes, two nice alternatives. > Of course such effort does not come for free. > Maybe the collaborative option would be a bit more sustainable... > > Nicolas I'd like to have both. The HelpBook and the blog. In case this needs some copy/pasting to get things from the blog to the HelpBook I am volunteering to do that. --Hannes |
|
|
Am 2010-08-27 um 12:17 schrieb Hannes Hirzel:
> On 8/26/10, Nicolas Cellier <[hidden email]> wrote: >> 2010/8/26 Andreas Raab <[hidden email]>: >>> On 8/26/2010 2:03 PM, Nicolas Cellier wrote: >>>> >>>> Trunk organization is really light with lower expectations in process >>>> quality, but is the prefect fit to my own taste, though i deplored >>>> several times that important decisions are not really traced... (a >>>> mailing list archive is not the ideal repository for these). >>> >>> Well, in light of having more and better documentation, should we start a >>> HelpSystem book for documenting such issues as we go? It might actually be >>> a >>> nice journal of the journey we're taking, that we talked about etc. >>> Alternatively, we could use a blog to write summaries of such discussions. >>> >>> Cheers, >>> - Andreas >>> >>> >> >> Yes, two nice alternatives. >> Of course such effort does not come for free. >> Maybe the collaborative option would be a bit more sustainable... >> >> Nicolas > > I'd like to have both. The HelpBook and the blog. In case this needs > some copy/pasting to get things from the blog to the HelpBook I am > volunteering to do that. Would it be so hard to have a Seaside Application take the HelpBook and display it as a nice blog? No copy-paste then ;) again just 2ct. so long, -Tobias |
Re: Meeting Report for 8/18/2010
|
|
It might need some editing work. The blog would contain the
discussions and the HelpBook what actually has been implemented (including reasons why). The style would be a kind of diary or log book entry style. --Hannes On 8/27/10, Tobias Pape <[hidden email]> wrote: > Am 2010-08-27 um 12:17 schrieb Hannes Hirzel: >> On 8/26/10, Nicolas Cellier <[hidden email]> wrote: >>> 2010/8/26 Andreas Raab <[hidden email]>: >>>> On 8/26/2010 2:03 PM, Nicolas Cellier wrote: >>>>> >>>>> Trunk organization is really light with lower expectations in process >>>>> quality, but is the prefect fit to my own taste, though i deplored >>>>> several times that important decisions are not really traced... (a >>>>> mailing list archive is not the ideal repository for these). >>>> >>>> Well, in light of having more and better documentation, should we start >>>> a >>>> HelpSystem book for documenting such issues as we go? It might actually >>>> be >>>> a >>>> nice journal of the journey we're taking, that we talked about etc. >>>> Alternatively, we could use a blog to write summaries of such >>>> discussions. >>>> >>>> Cheers, >>>> - Andreas >>>> >>>> >>> >>> Yes, two nice alternatives. >>> Of course such effort does not come for free. >>> Maybe the collaborative option would be a bit more sustainable... >>> >>> Nicolas >> >> I'd like to have both. The HelpBook and the blog. In case this needs >> some copy/pasting to get things from the blog to the HelpBook I am >> volunteering to do that. > > > Would it be so hard to have a Seaside Application take the HelpBook > and display it as a nice blog? No copy-paste then ;) > > again just 2ct. > > so long, > -Tobias > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |