Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource
Locked
12
12
Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource
 
|
On Thu, Mar 19, 2009 at 22:46, Keith Hodges <[hidden email]> wrote:
> I have long been frustrated that there is no place in squeaksource for > documenting what is in a repository, and offering feedback as to what > works where. Yes, and the MC tools should support that IMHO. BTW I'd also add: no nice support for named/tagged branches (I mean, in a big project there should be released/working/devel/in-progress branches, or at least documented sequences of snapshots for stable versions, and we have package-developerUniversallyKnownToNotRegularlyBreakThings.biggestNumber.mcz) > I have started to use Sake/Packages as a kind of micro "universe" for my > Seaside "Client" UI & Backend Component Framework. Having seen how > useful this is I thought that this might be useful for pier, and of > course seaside and other projects. Yup, I like the idea. > Some have reservations about Sake/Packages because they say it is not > declaritive. Huh… it's a rule system, right ? The alternative I know about being scripts that explicitly load snapshots in sequence, I fail to see where sake is not declarative. From my discussions on the subject, problems are more about the perception of what level of predictability and control one would get by using sake. Questions like "how do I know what will get installed if I pull this one" or "how do I install this, but with this particular version of that", and so on. Maybe it's a problem of polishing the DSL, of documentation, maybe of tools, I'm not sure; that could be investigated a bit more. For me it's clear that automatic dependancy management is the way to go, though the squeak/pharo community does not have resources or organization like debian's, so I think we need a more decentralized and agile way of managing dependancies, detecting and resolving incoherencies, etc. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Damien Pollet wrote:
> On Thu, Mar 19, 2009 at 22:46, Keith Hodges <[hidden email]> wrote: > >> I have long been frustrated that there is no place in squeaksource for >> documenting what is in a repository, and offering feedback as to what >> works where. >> > > Yes, and the MC tools should support that IMHO. > It was one of the first ideas I was going to add to MC, even just to have a simple text file explaining what is going on in a repo. I put a lot of effort into MC to bring the forks together, and make it maintained and able to move forward with one voice. That failed, so my motivation for hacking MC anymore is pretty low. > BTW I'd also add: no nice support for named/tagged branches (I mean, > in a big project there should be released/working/devel/in-progress > branches, or at least documented sequences of snapshots for stable > versions, and we have > package-developerUniversallyKnownToNotRegularlyBreakThings.biggestNumber.mcz) > My brain struggles with branches. Perhaps not having them is a good idea? >> I have started to use Sake/Packages as a kind of micro "universe" for my >> Seaside "Client" UI & Backend Component Framework. Having seen how >> useful this is I thought that this might be useful for pier, and of >> course seaside and other projects. >> > > Yup, I like the idea. Great! >> Some have reservations about Sake/Packages because they say it is not >> declaritive. >> > > Huh… it's a rule system, right ? The alternative I know about being > scripts that explicitly load snapshots in sequence, I fail to see > where sake is not declarative. > Its because the rules to load: a package can be blocks executing an arbitrary script. In normal use the #defaultAction is to process the given "declared" url to find the package to load. > From my discussions on the subject, problems are more about the > perception of what level of predictability and control one would get > by using sake. Questions like "how do I know what will get installed > if I pull this one" (Package named: 'SomePackage) what explore. This could be improved to ask Installer exactly what it will install, perhaps - (Package named: 'SomePackage) whatUsingDryRun explore. Also with DeltaStreams integration with Installer, we might have the ability to load into a "Delta/SystemEditor" rather than actually in to the image. > or "how do I install this, but with this > particular version of that", and so on. Maybe it's a problem of > Interesting point. I cant think of how to do that. Unless you use sake to generate a script or a task data scructure, and then you manually edit it. How about merging two dependency trees like so: (Packages current named: 'Seaside) using: (Packages beta named: 'Pier) > polishing the DSL, of documentation, maybe of tools, I'm not sure; > that could be investigated a bit more. > Can never get enough Documentation! > For me it's clear that automatic dependancy management is the way to > go, though the squeak/pharo community does not have resources or > organization like debian's, so I think we need a more decentralized > and agile way of managing dependancies, detecting and resolving > incoherencies, etc. > Bob might be able to do something like that in the future. He is sitting there monitoring a number of repositories, he could periodically process contributions and derive dependencies because he has some knowledge of the big picture. Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
Hi!
Keith Hodges wrote: > Also with DeltaStreams integration with Installer, we might have the > ability to load into a "Delta/SystemEditor" rather than actually in to > the image. Ah! There's my queue! :) Yes, although I only read casually what you are talking about I do agree with the general notions expressed. And yes, hopefully we will soon have Deltas in a useful form. Quick status again, followed with some questions: - Lots of tests are now green, still lots of tests not green but most of them are "wishful thinking"-tests and not really broken tests. - I am refactoring and cleaning right now, as a pre-cursor to adding the new file format. - I am also just beginning to try out Tirade as a file format. For more info on Tirade, see my first article: http://goran.krampe.se/blog/Squeak/Tirade.rdoc So in a relatively short timeperiod I hope we have code to load and save Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would these two file extensions work? Or should we use convention *.d and *.d.gz? Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas - I would also like to hear advice on how to build that in order to: - Be compatible with as many Squeak forks as possible. - Get a clean nice simple tool. Just copy plain dual change sorter? Use Toolbuilder? Use MC codebase? Omnibase? The end goal would be to fully replace Dual Change Sorter - which means that I would also like to have some support for loading a cs as a Delta and to save a Delta as a plain cs. ...and as always, if you like to join us in moving Deltastreams forward, just holler! regards, Göran _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
Hi goran
I did not get at all why you need a new format. Without self. I think that if you want adoption of deltastream do not mix them with a file format. Stef On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote: > Hi! > > Keith Hodges wrote: >> Also with DeltaStreams integration with Installer, we might have the >> ability to load into a "Delta/SystemEditor" rather than actually in >> to >> the image. > > Ah! There's my queue! :) > > Yes, although I only read casually what you are talking about I do > agree > with the general notions expressed. And yes, hopefully we will soon > have > Deltas in a useful form. > > Quick status again, followed with some questions: > > - Lots of tests are now green, still lots of tests not green but > most of > them are "wishful thinking"-tests and not really broken tests. > - I am refactoring and cleaning right now, as a pre-cursor to adding > the > new file format. > - I am also just beginning to try out Tirade as a file format. For > more > info on Tirade, see my first article: > > http://goran.krampe.se/blog/Squeak/Tirade.rdoc > > So in a relatively short timeperiod I hope we have code to load and > save > Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would > these > two file extensions work? Or should we use convention *.d and *.d.gz? > > Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas > - I > would also like to hear advice on how to build that in order to: > > - Be compatible with as many Squeak forks as possible. > - Get a clean nice simple tool. > > Just copy plain dual change sorter? Use Toolbuilder? Use MC codebase? > Omnibase? > > The end goal would be to fully replace Dual Change Sorter - which > means > that I would also like to have some support for loading a cs as a > Delta > and to save a Delta as a plain cs. > > ...and as always, if you like to join us in moving Deltastreams > forward, > just holler! > > regards, Göran > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
i wonder, wouldn't it be better to adopt a new smalltalk scripting
format, which annouced here lately? IMO it is better to use single format for many different purposes than use multiple formats. What you think? 2009/3/20 Stéphane Ducasse <[hidden email]>: > Hi goran > > I did not get at all why you need a new format. > Without self. > I think that if you want adoption of deltastream do not mix them with > a file format. > > Stef > > On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote: > >> Hi! >> >> Keith Hodges wrote: >>> Also with DeltaStreams integration with Installer, we might have the >>> ability to load into a "Delta/SystemEditor" rather than actually in >>> to >>> the image. >> >> Ah! There's my queue! :) >> >> Yes, although I only read casually what you are talking about I do >> agree >> with the general notions expressed. And yes, hopefully we will soon >> have >> Deltas in a useful form. >> >> Quick status again, followed with some questions: >> >> - Lots of tests are now green, still lots of tests not green but >> most of >> them are "wishful thinking"-tests and not really broken tests. >> - I am refactoring and cleaning right now, as a pre-cursor to adding >> the >> new file format. >> - I am also just beginning to try out Tirade as a file format. For >> more >> info on Tirade, see my first article: >> >> http://goran.krampe.se/blog/Squeak/Tirade.rdoc >> >> So in a relatively short timeperiod I hope we have code to load and >> save >> Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would >> these >> two file extensions work? Or should we use convention *.d and *.d.gz? >> >> Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas >> - I >> would also like to hear advice on how to build that in order to: >> >> - Be compatible with as many Squeak forks as possible. >> - Get a clean nice simple tool. >> >> Just copy plain dual change sorter? Use Toolbuilder? Use MC codebase? >> Omnibase? >> >> The end goal would be to fully replace Dual Change Sorter - which >> means >> that I would also like to have some support for loading a cs as a >> Delta >> and to save a Delta as a plain cs. >> >> ...and as always, if you like to join us in moving Deltastreams >> forward, >> just holler! >> >> regards, Göran >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
the same :)
I like coral scripting format. this is just a better chunk format :) But I do not want to open a war again. So better do it "alone" than fight with others. This is also my motto. Stef > i wonder, wouldn't it be better to adopt a new smalltalk scripting > format, which annouced here lately? > IMO it is better to use single format for many different purposes than > use multiple formats. > What you think? > > 2009/3/20 Stéphane Ducasse <[hidden email]>: >> Hi goran >> >> I did not get at all why you need a new format. >> Without self. >> I think that if you want adoption of deltastream do not mix them with >> a file format. >> >> Stef >> >> On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote: >> >>> Hi! >>> >>> Keith Hodges wrote: >>>> Also with DeltaStreams integration with Installer, we might have >>>> the >>>> ability to load into a "Delta/SystemEditor" rather than actually in >>>> to >>>> the image. >>> >>> Ah! There's my queue! :) >>> >>> Yes, although I only read casually what you are talking about I do >>> agree >>> with the general notions expressed. And yes, hopefully we will soon >>> have >>> Deltas in a useful form. >>> >>> Quick status again, followed with some questions: >>> >>> - Lots of tests are now green, still lots of tests not green but >>> most of >>> them are "wishful thinking"-tests and not really broken tests. >>> - I am refactoring and cleaning right now, as a pre-cursor to adding >>> the >>> new file format. >>> - I am also just beginning to try out Tirade as a file format. For >>> more >>> info on Tirade, see my first article: >>> >>> http://goran.krampe.se/blog/Squeak/Tirade.rdoc >>> >>> So in a relatively short timeperiod I hope we have code to load and >>> save >>> Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would >>> these >>> two file extensions work? Or should we use convention *.d and >>> *.d.gz? >>> >>> Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas >>> - I >>> would also like to hear advice on how to build that in order to: >>> >>> - Be compatible with as many Squeak forks as possible. >>> - Get a clean nice simple tool. >>> >>> Just copy plain dual change sorter? Use Toolbuilder? Use MC >>> codebase? >>> Omnibase? >>> >>> The end goal would be to fully replace Dual Change Sorter - which >>> means >>> that I would also like to have some support for loading a cs as a >>> Delta >>> and to save a Delta as a plain cs. >>> >>> ...and as always, if you like to join us in moving Deltastreams >>> forward, >>> just holler! >>> >>> regards, Göran >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
2009/3/20 Stéphane Ducasse <[hidden email]>:
> the same :) > I like coral scripting format. > this is just a better chunk format :) > > But I do not want to open a war again. So better do it "alone" than > fight with others. > This is also my motto. > I looking at it at different angle: why inventing own wheel, when there is already existing solutions. I'm not sure if Coral fits well with DS (looks like it depends on NewCompiler), i just gave Goran a links, so he could decide if it is. > Stef > > > >> i wonder, wouldn't it be better to adopt a new smalltalk scripting >> format, which annouced here lately? >> IMO it is better to use single format for many different purposes than >> use multiple formats. >> What you think? >> >> 2009/3/20 Stéphane Ducasse <[hidden email]>: >>> Hi goran >>> >>> I did not get at all why you need a new format. >>> Without self. >>> I think that if you want adoption of deltastream do not mix them with >>> a file format. >>> >>> Stef >>> >>> On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote: >>> >>>> Hi! >>>> >>>> Keith Hodges wrote: >>>>> Also with DeltaStreams integration with Installer, we might have >>>>> the >>>>> ability to load into a "Delta/SystemEditor" rather than actually in >>>>> to >>>>> the image. >>>> >>>> Ah! There's my queue! :) >>>> >>>> Yes, although I only read casually what you are talking about I do >>>> agree >>>> with the general notions expressed. And yes, hopefully we will soon >>>> have >>>> Deltas in a useful form. >>>> >>>> Quick status again, followed with some questions: >>>> >>>> - Lots of tests are now green, still lots of tests not green but >>>> most of >>>> them are "wishful thinking"-tests and not really broken tests. >>>> - I am refactoring and cleaning right now, as a pre-cursor to adding >>>> the >>>> new file format. >>>> - I am also just beginning to try out Tirade as a file format. For >>>> more >>>> info on Tirade, see my first article: >>>> >>>> http://goran.krampe.se/blog/Squeak/Tirade.rdoc >>>> >>>> So in a relatively short timeperiod I hope we have code to load and >>>> save >>>> Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would >>>> these >>>> two file extensions work? Or should we use convention *.d and >>>> *.d.gz? >>>> >>>> Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas >>>> - I >>>> would also like to hear advice on how to build that in order to: >>>> >>>> - Be compatible with as many Squeak forks as possible. >>>> - Get a clean nice simple tool. >>>> >>>> Just copy plain dual change sorter? Use Toolbuilder? Use MC >>>> codebase? >>>> Omnibase? >>>> >>>> The end goal would be to fully replace Dual Change Sorter - which >>>> means >>>> that I would also like to have some support for loading a cs as a >>>> Delta >>>> and to save a Delta as a plain cs. >>>> >>>> ...and as always, if you like to join us in moving Deltastreams >>>> forward, >>>> just holler! >>>> >>>> regards, Göran >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
In reply to this post by Stéphane Ducasse
Hi!
Stéphane Ducasse wrote: > Hi goran > > I did not get at all why you need a new format. > Without self. > I think that if you want adoption of deltastream do not mix them with > a file format. I am sorry, perhaps you haven't followed the reasoning, a quick recap: 1. Deltas are not bound to a specific format on disk. You can store them in any way you like. They are "self contained object graphs" in the image and can trivially be serialized. 2. Matthew made a format called "Interleaved ChangeSet" which combines binary data with the chunk format meaning that a Delta can be stored both as a changeset (loosing lots of info) and a Delta embedded inside it. This means an old image can "file it in" just like a cs. 3. I think the Interleaved format is a bit too complex and while it is "cool" I don't think the use case is *that* important (being backward compatible for images that don't know what a Delta is). It is probably simpler to include easy conversion delta2cs and cs2delta. These conversions are not lossless however. 4. Since I wanted a readable, simple, fast, editable, and secure format for Deltas - I came up with Tirade. Chunk format is readable, simple and editable but it is not fast nor secure. It is also less "declarative" in nature IMHO. Tirade is well defined, small and simple. The Tirade package is just a few classes and it is intended to work in "all Squeaks" - no dependencies on any advanced stuff. Tirade is a "data format" - it is NOT "Smalltalk code", it just happens to match a lot of syntax and concepts. It is "merely" a sequence of keyword messages with "data" as arguments (String, Symbol, Arrays, Associations and Numbers - nested however you like). That is it. No assignment, no variables, no globals, no expressions etc etc. It is NOT Smalltalk. Adding "self" to it has no purpose, well, the ONLY purpose would be to make it "look" like Smalltalk. Now... this is repeating stuff I have already written elsewhere - but there ya go. :) regards, Göran _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:
> the same :) > I like coral scripting format. > this is just a better chunk format :) > > But I do not want to open a war again. So better do it "alone" than > fight with others. > This is also my motto. > > Stef > reveal to you where it was you learned this emotional pattern. (its not one I have ;-) ) Another case in point, on my to do list for squeak is "a registration mechanism for menus/flaps etc". There is absolutely NO reason why such a mechanism shouldnt be specced out and developed as a loadable module for all squeak forks to adopt. Do we have to have 2 of absolutely everything? Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
In reply to this post by Igor Stasenko
Hi guys!
Igor Stasenko wrote: > 2009/3/20 Stéphane Ducasse <[hidden email]>: >> the same :) >> I like coral scripting format. >> this is just a better chunk format :) If you by that mean a really nice serialization format that fits to serialize objects dealing with Smalltalk source code - then yes. This is where the comparison with Coral probably breaks - correct me if I am wrong, but Coral is a "better" .st format, right? Or in other words - a format for typing in Smalltalk code in files. Tirade is meant to *serialize* Delta and Change objects. It is not a "fileout" format, it is much more a readable *serialization* format. >> But I do not want to open a war again. So better do it "alone" than >> fight with others. >> This is also my motto. >> > I looking at it at different angle: > why inventing own wheel, when there is already existing solutions. > I'm not sure if Coral fits well with DS (looks like it depends on > NewCompiler), i just gave Goran a links, so he could decide if it is. I haven't seen a description of Coral yet - and no, I haven't installed it and looked at it. I wanted a description first :). But given the little I have read it seems to be a format for Smalltalk classes in files. Period. Again, this is not at all what Tirade is nor something suitable for serializing Deltas, or am I missing something? And yes, Tirade works fine today in 3.6->3.10.2 + Pharo. It's 500 lines of code and independent of Compiler and has no other dependencies. This is important for the use cases. :) regards, Göran _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
On Mar 20, 2009, at 3:24 PM, Göran Krampe wrote: > Hi guys! > > Igor Stasenko wrote: >> 2009/3/20 Stéphane Ducasse <[hidden email]>: >>> the same :) >>> I like coral scripting format. >>> this is just a better chunk format :) > > If you by that mean a really nice serialization format that fits to > serialize objects dealing with Smalltalk source code - then yes. coral is a reabable chunk format not serialization of objects. > This is where the comparison with Coral probably breaks - correct me > if > I am wrong, but Coral is a "better" .st format, right? Or in other > words > - a format for typing in Smalltalk code in files. Yeap. > Tirade is meant to *serialize* Delta and Change objects. It is not a > "fileout" format, it is much more a readable *serialization* format. Ok did you check SRP? > > >>> But I do not want to open a war again. So better do it "alone" than >>> fight with others. >>> This is also my motto. >>> >> I looking at it at different angle: >> why inventing own wheel, when there is already existing solutions. >> I'm not sure if Coral fits well with DS (looks like it depends on >> NewCompiler), i just gave Goran a links, so he could decide if it >> is. > > I haven't seen a description of Coral yet - and no, I haven't > installed > it and looked at it. I wanted a description first :). But given the > little I have read it seems to be a format for Smalltalk classes in > files. Period. yeap > > > Again, this is not at all what Tirade is nor something suitable for > serializing Deltas, or am I missing something? > > And yes, Tirade works fine today in 3.6->3.10.2 + Pharo. It's 500 > lines > of code and independent of Compiler and has no other dependencies. > > This is important for the use cases. :) > > regards, Göran > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
In reply to this post by keith1y
>>
> Perhaps you need healing from your fear of conflict. Ask your mind to > reveal to you where it was you learned this emotional pattern. (its > not > one I have ;-) ) keith this is much more simple than that. I'm doing pharo just to avoid the endless discussions on "I need arrow for assignment". I have nearly 20 years of brain cells now if I do not die before so I do not want to spend my time on boring stuff when I can avoid it. > Another case in point, on my to do list for squeak is "a registration > mechanism for menus/flaps etc". There is absolutely NO reason why > such a > mechanism shouldnt be specced out and developed as a loadable module > for > all squeak forks to adopt. Exact. Now the point is that we do not want to keep extra layer of compatibility for the sake of it. > Do we have to have 2 of absolutely everything? No but we have the right to choose and consider if we like it or not. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
2009/3/20 Stéphane Ducasse <[hidden email]>:
>>> >> Perhaps you need healing from your fear of conflict. Ask your mind to >> reveal to you where it was you learned this emotional pattern. (its >> not >> one I have ;-) ) > > keith this is much more simple than that. > I'm doing pharo just to avoid the endless discussions on "I need arrow > for assignment". > I have nearly 20 years of brain cells now if I do not die before so I > do not want to > spend my time on boring stuff when I can avoid it. > >> Another case in point, on my to do list for squeak is "a registration >> mechanism for menus/flaps etc". There is absolutely NO reason why >> such a >> mechanism shouldnt be specced out and developed as a loadable module >> for >> all squeak forks to adopt. > > Exact. Now the point is that we do not want to keep extra layer of > compatibility for the sake > of it. > i think making squeak compatible with outer world (use ascii ':=' instead of unicode '<-' and enable to use '_' in selectors and variables) is better than trying to be 'compatible' with 20 years old dusty stuff. >> Do we have to have 2 of absolutely everything? > > No but we have the right to choose and consider if we like it or not. > > Stef > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
>>
> +1 > i think making squeak compatible with outer world (use ascii ':=' > instead of unicode '<-' and enable to use '_' in selectors and > variables) is better than trying to be 'compatible' with 20 years old > dusty stuff. Yeap. I dream about a Smalltalk that we can script, embed into c application, talk well to c libraries, have nice libraries, tested....with nice mop, So let us try to focus on that Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
>
> I have nearly 20 years of brain cells now if I do not die before so I > do not want to > spend my time on boring stuff when I can avoid it. > But you are throwing the baby out with the bath water. > No but we have the right to choose and consider if we like it or not. > > Actually I disagree. You are mixing two completely different things here. 1. Squeak, an open source project with lots of stake holders that may cramp your style. 2. Any other completely open sub-project which you are invited to contribute to and further your aims by participating with (i.e. Monticello) When you forked pharo you understandably forked 1. There was no need to fork any external projects (2) Every sub-project (2) has its own developers, and its own culture, and attitude towards participation and change. When you treat other -sub projects and their communities with the same contempt that you understandably have towards the squeak community, you result in insulting those communities. The initiative I started on MC has a culture of participation and collaboration, together with an ethos of being as responsive as possible to feedback and suggestions. When you ignore this, you insult everyone that has put time and effort into that project. In a similar manner, any initiative or sub-project that you undertake within pharo, can have an ethos following either of two options. A). Pharo team specific developed for pharo speced for pharo only. B). A completely open sub-project which anyone is invited to support and to further your aims by participating with. When you pick option A, or fork option 2, you are actually insulting every project that was offered to you on the basis of option 2 above. Because you are saying, that you are happy to take from the other OSS efforts but you are not happy to give back, or contribute back to them on a similarly open basis. (and "you can port it if you want it" doesn't count) The clearest example of this continues to be Monticello. When I do months of work and suffer considerably for the good of "everyone that wants change" of which you were one person at the top of the list. I do the work out of the goodness of my heart because I expect in the ethos of open source software that there is some give and take. "Take" because I build on the work of others that freely contributed to me, and "give" because I contribute to the furtherment of the vision that they started, and "take" again because I anticipate others continuing the good fight in the long run on everyones behalf. Given a completely open independent project, that you are invited to support and contribute to, on which much work has already been done "on YOUR behalf", in the direction of "YOUR goals". I consider it to be extremely rude and insulting, for you not to join in and further your own aims by contributing positively back to that project. The reason that I have no interest in participating in pharo, is not that I dont agree with the vision. Its the fact that I find the attitude of the pharo team (with a couple of notable exceptions) to be extremely rude. Perhaps its a cultural thing. I consider the attitude conveyed by the words "No but we have the right to choose and consider if we like it or not." to be tantamount to snobbery, when the option and invitation is completely open for you to participate and make it as likeable as you wish. It is perfectly possible for the following projects to be initiated as loadable modular sub-projects, developed with an ethos of participation for anyone to contribute and for anyone to use. 1. Registration for menus and UI features 2. Improvements to Streams 3. HTTPSocket 4. Alternatives to Changesets 5. Replace the changes file mechanism with something else 6. Atomic loading (including traits) 7. Replacements for Morphic, MVP 8. Compiler 9. Network. 10. Compression. 11. Files 12. SSpec 13. SUnit 14. Code Browsers/Tools I am seriously considering licencing Rio under something other than MIT, so that you cant use it, until you change your attitude towards your potential benefactors. Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
2009/3/20 Keith Hodges <[hidden email]>:
>> >> I have nearly 20 years of brain cells now if I do not die before so I >> do not want to >> spend my time on boring stuff when I can avoid it. >> > But you are throwing the baby out with the bath water. >> No but we have the right to choose and consider if we like it or not. >> >> > Actually I disagree. > > You are mixing two completely different things here. > > 1. Squeak, an open source project with lots of stake holders that may > cramp your style. > 2. Any other completely open sub-project which you are invited to > contribute to and further your aims by participating with (i.e. Monticello) > > When you forked pharo you understandably forked 1. There was no need to > fork any external projects (2) > > Every sub-project (2) has its own developers, and its own culture, and > attitude towards participation and change. When you treat other -sub > projects and their communities with the same contempt that you > understandably have towards the squeak community, you result in > insulting those communities. > > The initiative I started on MC has a culture of participation and > collaboration, together with an ethos of being as responsive as possible > to feedback and suggestions. When you ignore this, you insult everyone > that has put time and effort into that project. > > In a similar manner, any initiative or sub-project that you undertake > within pharo, can have an ethos following either of two options. > > A). Pharo team specific developed for pharo speced for pharo only. > B). A completely open sub-project which anyone is invited to support and > to further your aims by participating with. > > When you pick option A, or fork option 2, you are actually insulting > every project that was offered to you on the basis of option 2 above. > Because you are saying, that you are happy to take from the other OSS > efforts but you are not happy to give back, or contribute back to them > on a similarly open basis. (and "you can port it if you want it" doesn't > count) > > The clearest example of this continues to be Monticello. > > When I do months of work and suffer considerably for the good of > "everyone that wants change" of which you were one person at the top of > the list. I do the work out of the goodness of my heart because I expect > in the ethos of open source software that there is some give and take. > "Take" because I build on the work of others that freely contributed to > me, and "give" because I contribute to the furtherment of the vision > that they started, and "take" again because I anticipate others > continuing the good fight in the long run on everyones behalf. > > Given a completely open independent project, that you are invited to > support and contribute to, on which much work has already been done "on > YOUR behalf", in the direction of "YOUR goals". I consider it to be > extremely rude and insulting, for you not to join in and further your > own aims by contributing positively back to that project. > > The reason that I have no interest in participating in pharo, is not > that I dont agree with the vision. Its the fact that I find the attitude > of the pharo team (with a couple of notable exceptions) to be extremely > rude. Perhaps its a cultural thing. > > I consider the attitude conveyed by the words "No but we have the right > to choose and consider if we like it or not." to be tantamount to > snobbery, when the option and invitation is completely open for you to > participate and make it as likeable as you wish. > > It is perfectly possible for the following projects to be initiated as > loadable modular sub-projects, developed with an ethos of participation > for anyone to contribute and for anyone to use. > > 1. Registration for menus and UI features > 2. Improvements to Streams > 3. HTTPSocket > 4. Alternatives to Changesets > 5. Replace the changes file mechanism with something else > 6. Atomic loading (including traits) > 7. Replacements for Morphic, MVP > 8. Compiler > 9. Network. > 10. Compression. > 11. Files > 12. SSpec > 13. SUnit > 14. Code Browsers/Tools > > I am seriously considering licencing Rio under something other than MIT, > so that you cant use it, until you change your attitude towards your > potential benefactors. > There is one problem with Squeak, that it grew out to something amorphous, up to the point that its really hard to tell where ends one package/module and starts another one. I sense the future of squeak is to make a cleaning to cut-out many interdependencies, for getting to the point where all code is clearly falls into separate modules. From this point, different modules can be improved separately, but not sooner. And Pharo team is doing a lot for making this happen. For example, i wouldn't buy the Compression framework which fails to work without Morphic/Etoys. And i don't think that making sure it doesn't have such interdependencies is a rude. I think its rude to keep thing in such state by honing the swamp which equally sucks the energy from everyone and suppressing progress. You can't plant the wheat in the forest, first you have to cut down the trees and get rid of stumps. I think its too early to say that Pharo went too far from Squeak to make it hard to backport any changes/improvements. I appreciate Stephane's attempts to chop down some old rotten trees in forest to make more space for growing a new sprouts. There's another aspect of same thing: a lot of Squeak code/packages having no maintainers. People expect that someone takes care of code which is released with image. But let us be realistic: there is no such developers/teams who could take a grasp of such big code base and maintain it. And there is choice: keep using old code (mostly w/o changes), sacrificing the potential of having a lot of code bloat, or cut it out and then reintegrate/reimplement it in a more modular style. > Keith > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
In reply to this post by keith1y
Geeeee.
MC is not any project, it is our key infrastructural element. So we must control it. Because it took us a lot of energy to build our infrastructure: I remember 3.9 endeavor. >> The initiative I started on MC has a culture of participation and > collaboration, together with an ethos of being as responsive as > possible > to feedback and suggestions. When you ignore this, you insult everyone > that has put time and effort into that project. > > When you pick option A, or fork option 2, you are actually insulting > every project that was offered to you on the basis of option 2 above. > Because you are saying, that you are happy to take from the other OSS > efforts but you are not happy to give back, or contribute back to them > on a similarly open basis. (and "you can port it if you want it" > doesn't > count) this is totally wrong. You can take our code and port it back to anything you like. All our code is 100% MIT so what? Some people are also just stealing/copying our ideas but this is life. > The clearest example of this continues to be Monticello. It is not since MC is not any project, it is our key infrastructural element. So we must control it. > When I do months of work and suffer considerably for the good of > "everyone that wants change" of which you were one person at the top > of > the list. I do the work out of the goodness of my heart because I > expect > in the ethos of open source software that there is some give and take. > "Take" because I build on the work of others that freely contributed > to > me, and "give" because I contribute to the furtherment of the vision > that they started, and "take" again because I anticipate others > continuing the good fight in the long run on everyones behalf. keith are you telling me that I did not give to this community. Frankly? Are you serious? or blind? I will not make a list of what I did and I'm doing because I do not do it to enumerate it in public. > Given a completely open independent project, that you are invited to > support and contribute to, on which much work has already been done > "on > YOUR behalf", in the direction of "YOUR goals". I consider it to be > extremely rude and insulting, for you not to join in and further your > own aims by contributing positively back to that project. But of what are you talking? That you introduced traits support and atomic loading on MC and that we do not consider it? But you know several people privately asked us not to include your code. So we pay attention. When I took the time to give feedback on kernel extensions or rio this was because I considered your work and I wanted to help you improving your code. But you can also think that I was whatever you want. > The reason that I have no interest in participating in pharo, is not > that I dont agree with the vision. Its the fact that I find the > attitude > of the pharo team (with a couple of notable exceptions) to be > extremely > rude. Perhaps its a cultural thing. Do you think that I'm rude because I reply to you or when I do not reply? > I consider the attitude conveyed by the words "No but we have the > right > to choose and consider if we like it or not." to be tantamount to > snobbery, this has nothing to do with snobbery. This has to do with freedom. You as anybody else on this earth cannot get a free check with what we are doing. You saw how we worked with the settings and preference discussion with alain. I like that way of doing things, we discuss and learn from each other. This is one solution and first it should work well in pharo. Of course this may not scale for more complex projects. > when the option and invitation is completely open for you to > participate and make it as likeable as you wish. I do not ask for that. I do not see why I would have the right to come and change think in your project. > It is perfectly possible for the following projects to be initiated as > loadable modular sub-projects, developed with an ethos of > participation > for anyone to contribute and for anyone to use. > > 1. Registration for menus and UI features > 2. Improvements to Streams > 3. HTTPSocket > 4. Alternatives to Changesets > 5. Replace the changes file mechanism with something else > 6. Atomic loading (including traits) > 7. Replacements for Morphic, MVP > 8. Compiler > 9. Network. > 10. Compression. > 11. Files > 12. SSpec > 13. SUnit > 14. Code Browsers/Tools Probably. Now if we do not like the code quality we will not use that. This has nothing with snobbery this has to do with credibility on the long run. > I am seriously considering licencing Rio under something other than > MIT, > so that you cant use it, until you change your attitude towards your > potential benefactors. Do it if you need, we will just not use it. Note that some people do not like rio design, so the fact that it is MIT does not mean that we will use it. I looked at it because files are so bad in Squeak. Now I can understand your frustration but there are few stuff I can do. I do not have the time to do all the things I would like to do. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
In reply to this post by Igor Stasenko
Yes. Sometimes I'm sad of removing fun stuff. But this is the way it is.
Igor I think that the point of keith was not about that goal (even if his process implies been able to plant new trees everywhere and not cutting that much rotten trees). I think that keith was frustrated that we could give feedback or threshold for package inclusion in pharo and that he worked on them and that we neglected them. Now everybody has the right to stand up for or against a package and make a point. Of course stating publicly that a given piece of code is great is easier than the inverse especially when you want to pay attention to the human at the other end of the line. Stef On Mar 20, 2009, at 9:20 PM, Igor Stasenko wrote: > 2009/3/20 Keith Hodges <[hidden email]>: >>> >>> I have nearly 20 years of brain cells now if I do not die before >>> so I >>> do not want to >>> spend my time on boring stuff when I can avoid it. >>> >> But you are throwing the baby out with the bath water. >>> No but we have the right to choose and consider if we like it or >>> not. >>> >>> >> Actually I disagree. >> >> You are mixing two completely different things here. >> >> 1. Squeak, an open source project with lots of stake holders that may >> cramp your style. >> 2. Any other completely open sub-project which you are invited to >> contribute to and further your aims by participating with (i.e. >> Monticello) >> >> When you forked pharo you understandably forked 1. There was no >> need to >> fork any external projects (2) >> >> Every sub-project (2) has its own developers, and its own culture, >> and >> attitude towards participation and change. When you treat other -sub >> projects and their communities with the same contempt that you >> understandably have towards the squeak community, you result in >> insulting those communities. >> >> The initiative I started on MC has a culture of participation and >> collaboration, together with an ethos of being as responsive as >> possible >> to feedback and suggestions. When you ignore this, you insult >> everyone >> that has put time and effort into that project. >> >> In a similar manner, any initiative or sub-project that you undertake >> within pharo, can have an ethos following either of two options. >> >> A). Pharo team specific developed for pharo speced for pharo only. >> B). A completely open sub-project which anyone is invited to >> support and >> to further your aims by participating with. >> >> When you pick option A, or fork option 2, you are actually insulting >> every project that was offered to you on the basis of option 2 above. >> Because you are saying, that you are happy to take from the other OSS >> efforts but you are not happy to give back, or contribute back to >> them >> on a similarly open basis. (and "you can port it if you want it" >> doesn't >> count) >> >> The clearest example of this continues to be Monticello. >> >> When I do months of work and suffer considerably for the good of >> "everyone that wants change" of which you were one person at the >> top of >> the list. I do the work out of the goodness of my heart because I >> expect >> in the ethos of open source software that there is some give and >> take. >> "Take" because I build on the work of others that freely >> contributed to >> me, and "give" because I contribute to the furtherment of the vision >> that they started, and "take" again because I anticipate others >> continuing the good fight in the long run on everyones behalf. >> >> Given a completely open independent project, that you are invited to >> support and contribute to, on which much work has already been done >> "on >> YOUR behalf", in the direction of "YOUR goals". I consider it to be >> extremely rude and insulting, for you not to join in and further your >> own aims by contributing positively back to that project. >> >> The reason that I have no interest in participating in pharo, is not >> that I dont agree with the vision. Its the fact that I find the >> attitude >> of the pharo team (with a couple of notable exceptions) to be >> extremely >> rude. Perhaps its a cultural thing. >> >> I consider the attitude conveyed by the words "No but we have the >> right >> to choose and consider if we like it or not." to be tantamount to >> snobbery, when the option and invitation is completely open for you >> to >> participate and make it as likeable as you wish. >> >> It is perfectly possible for the following projects to be initiated >> as >> loadable modular sub-projects, developed with an ethos of >> participation >> for anyone to contribute and for anyone to use. >> >> 1. Registration for menus and UI features >> 2. Improvements to Streams >> 3. HTTPSocket >> 4. Alternatives to Changesets >> 5. Replace the changes file mechanism with something else >> 6. Atomic loading (including traits) >> 7. Replacements for Morphic, MVP >> 8. Compiler >> 9. Network. >> 10. Compression. >> 11. Files >> 12. SSpec >> 13. SUnit >> 14. Code Browsers/Tools >> >> I am seriously considering licencing Rio under something other than >> MIT, >> so that you cant use it, until you change your attitude towards your >> potential benefactors. >> > > There is one problem with Squeak, that it grew out to something > amorphous, up to the point that its really hard to tell where ends one > package/module and starts another one. > I sense the future of squeak is to make a cleaning to cut-out many > interdependencies, for getting to the point where all code is clearly > falls into separate modules. From this point, different modules can be > improved separately, but not sooner. And Pharo team is doing a lot for > making this happen. > For example, i wouldn't buy the Compression framework which fails to > work without Morphic/Etoys. And i don't think that making sure it > doesn't have such interdependencies is a rude. I think its rude to > keep thing in such state by honing the swamp which equally sucks the > energy from everyone and suppressing progress. > > You can't plant the wheat in the forest, first you have to cut down > the trees and get rid of stumps. > I think its too early to say that Pharo went too far from Squeak to > make it hard to backport any changes/improvements. I appreciate > Stephane's attempts to chop down some old rotten trees in forest to > make more space for growing a new sprouts. > > There's another aspect of same thing: a lot of Squeak code/packages > having no maintainers. > People expect that someone takes care of code which is released with > image. But let us be realistic: there is no such developers/teams who > could take a grasp of such big code base and maintain it. > And there is choice: keep using old code (mostly w/o changes), > sacrificing the potential of having a lot of code bloat, or cut it out > and then reintegrate/reimplement it in a more modular style. > >> Keith >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
2009/3/20 Stéphane Ducasse <[hidden email]>:
> Yes. Sometimes I'm sad of removing fun stuff. But this is the way it is. > > Igor I think that the point of keith was not about that goal (even if > his process > implies been able to plant new trees everywhere and not cutting that > much rotten trees). Well, i tried to describe your motives, as i see it, to show that often its not possible to build a new thing without breaking an old one. Again, as i said, lets say you improved/changed the package X to suit your vision, and this package is no longer maintained by any other party. So does it makes such change evil of some sort? I don't think so. Consider a Morphic. Can anyone tell who is maintaining it? No one! Gary did a lot of hard work balancing between good and stinky code trying to improve things in his Polymorph package without breaking things in Morphic. Now think, how easier/faster it would be it we would have an official Morphic package/module and official maintainer(s) who continuously improving the code & maintaining it. > I think that keith was frustrated that we could give feedback or > threshold for > package inclusion in pharo and that he worked on them and that we > neglected > them. > Now everybody has the right to stand up for or against a package and > make a point. > Of course stating publicly that a given piece of code is great is > easier than the inverse > especially when you want to pay attention to the human at the other > end of the line. I think you have a full right to decide what [not] to include in Pharo. Keith mentioned that you making many changes to many different parts of system , which supposed to be maintained by original authour(s) or currently active team(s), without giving a feedback or credit or consulting with them about promoting such changes. Okay, i think you're not stepping into other's domain.. it would be rude.. But its going to be tricky, when you change the package X (not maintained by anyone), from which depends a lot of work, which doing in parallel by other team for package Y, which depends on X. Here lies the problem, which can be solved by communicating with people. Of course it requires the good will of both sides :) > Stef > > On Mar 20, 2009, at 9:20 PM, Igor Stasenko wrote: > >> 2009/3/20 Keith Hodges <[hidden email]>: >>>> >>>> I have nearly 20 years of brain cells now if I do not die before >>>> so I >>>> do not want to >>>> spend my time on boring stuff when I can avoid it. >>>> >>> But you are throwing the baby out with the bath water. >>>> No but we have the right to choose and consider if we like it or >>>> not. >>>> >>>> >>> Actually I disagree. >>> >>> You are mixing two completely different things here. >>> >>> 1. Squeak, an open source project with lots of stake holders that may >>> cramp your style. >>> 2. Any other completely open sub-project which you are invited to >>> contribute to and further your aims by participating with (i.e. >>> Monticello) >>> >>> When you forked pharo you understandably forked 1. There was no >>> need to >>> fork any external projects (2) >>> >>> Every sub-project (2) has its own developers, and its own culture, >>> and >>> attitude towards participation and change. When you treat other -sub >>> projects and their communities with the same contempt that you >>> understandably have towards the squeak community, you result in >>> insulting those communities. >>> >>> The initiative I started on MC has a culture of participation and >>> collaboration, together with an ethos of being as responsive as >>> possible >>> to feedback and suggestions. When you ignore this, you insult >>> everyone >>> that has put time and effort into that project. >>> >>> In a similar manner, any initiative or sub-project that you undertake >>> within pharo, can have an ethos following either of two options. >>> >>> A). Pharo team specific developed for pharo speced for pharo only. >>> B). A completely open sub-project which anyone is invited to >>> support and >>> to further your aims by participating with. >>> >>> When you pick option A, or fork option 2, you are actually insulting >>> every project that was offered to you on the basis of option 2 above. >>> Because you are saying, that you are happy to take from the other OSS >>> efforts but you are not happy to give back, or contribute back to >>> them >>> on a similarly open basis. (and "you can port it if you want it" >>> doesn't >>> count) >>> >>> The clearest example of this continues to be Monticello. >>> >>> When I do months of work and suffer considerably for the good of >>> "everyone that wants change" of which you were one person at the >>> top of >>> the list. I do the work out of the goodness of my heart because I >>> expect >>> in the ethos of open source software that there is some give and >>> take. >>> "Take" because I build on the work of others that freely >>> contributed to >>> me, and "give" because I contribute to the furtherment of the vision >>> that they started, and "take" again because I anticipate others >>> continuing the good fight in the long run on everyones behalf. >>> >>> Given a completely open independent project, that you are invited to >>> support and contribute to, on which much work has already been done >>> "on >>> YOUR behalf", in the direction of "YOUR goals". I consider it to be >>> extremely rude and insulting, for you not to join in and further your >>> own aims by contributing positively back to that project. >>> >>> The reason that I have no interest in participating in pharo, is not >>> that I dont agree with the vision. Its the fact that I find the >>> attitude >>> of the pharo team (with a couple of notable exceptions) to be >>> extremely >>> rude. Perhaps its a cultural thing. >>> >>> I consider the attitude conveyed by the words "No but we have the >>> right >>> to choose and consider if we like it or not." to be tantamount to >>> snobbery, when the option and invitation is completely open for you >>> to >>> participate and make it as likeable as you wish. >>> >>> It is perfectly possible for the following projects to be initiated >>> as >>> loadable modular sub-projects, developed with an ethos of >>> participation >>> for anyone to contribute and for anyone to use. >>> >>> 1. Registration for menus and UI features >>> 2. Improvements to Streams >>> 3. HTTPSocket >>> 4. Alternatives to Changesets >>> 5. Replace the changes file mechanism with something else >>> 6. Atomic loading (including traits) >>> 7. Replacements for Morphic, MVP >>> 8. Compiler >>> 9. Network. >>> 10. Compression. >>> 11. Files >>> 12. SSpec >>> 13. SUnit >>> 14. Code Browsers/Tools >>> >>> I am seriously considering licencing Rio under something other than >>> MIT, >>> so that you cant use it, until you change your attitude towards your >>> potential benefactors. >>> >> >> There is one problem with Squeak, that it grew out to something >> amorphous, up to the point that its really hard to tell where ends one >> package/module and starts another one. >> I sense the future of squeak is to make a cleaning to cut-out many >> interdependencies, for getting to the point where all code is clearly >> falls into separate modules. From this point, different modules can be >> improved separately, but not sooner. And Pharo team is doing a lot for >> making this happen. >> For example, i wouldn't buy the Compression framework which fails to >> work without Morphic/Etoys. And i don't think that making sure it >> doesn't have such interdependencies is a rude. I think its rude to >> keep thing in such state by honing the swamp which equally sucks the >> energy from everyone and suppressing progress. >> >> You can't plant the wheat in the forest, first you have to cut down >> the trees and get rid of stumps. >> I think its too early to say that Pharo went too far from Squeak to >> make it hard to backport any changes/improvements. I appreciate >> Stephane's attempts to chop down some old rotten trees in forest to >> make more space for growing a new sprouts. >> >> There's another aspect of same thing: a lot of Squeak code/packages >> having no maintainers. >> People expect that someone takes care of code which is released with >> image. But let us be realistic: there is no such developers/teams who >> could take a grasp of such big code base and maintain it. >> And there is choice: keep using old code (mostly w/o changes), >> sacrificing the potential of having a lot of code bloat, or cut it out >> and then reintegrate/reimplement it in a more modular style. >> >>> Keith >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)
|
|
Concenrning Monticello, i think it would be nice to split it on parts, like:
Monticello-Core Monticello-Persistance (Files/Sockets etc) Monticello-UI (Morphic/another framework) now, make sure that Core part could work well with any squeak fork, while rest of stuff can be easily replaced by different implementations. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |