Re: [Pharo-project] [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource
On Thu, Mar 19, 2009 at 22:46, Keith Hodges <keith_hodges@yahoo.co.uk> 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
Damien Pollet wrote:
On Thu, Mar 19, 2009 at 22:46, Keith Hodges <keith_hodges@yahoo.co.uk> 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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/3/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Hi guys! Igor Stasenko wrote:
2009/3/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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
On Mar 20, 2009, at 3:24 PM, Göran Krampe wrote:
Hi guys!
Igor Stasenko wrote:
2009/3/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 ;-) ) 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
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
2009/3/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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.
+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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
+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
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
2009/3/20 Keith Hodges <keith_hodges@yahoo.co.uk>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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 <keith_hodges@yahoo.co.uk>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/3/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 <keith_hodges@yahoo.co.uk>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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.
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 :)
Igor, I am not understanding your logic. You appear to be saying that if package X has got current maintainers, then it is not rude to make your own version of Package X. And that if you fork a package that has no maintainer then you will be in trouble. I am saying the opposite - that if you fork a package that has got current maintainers, you a) insult the maintainers, b) you undermine the progress that they may have made, c) you undermine any efforts thay have made to build a team and communication around that project. d) you prevent future progress by the existing team e) you make extra work for the exisiting team because you dont communicate with them and they are forced to play catch up to you all the time f) you send out the message that volunteering to maintain any part of the kernel is a hapless task, and will ultimately be a waste of time and effort. Keith
2009/3/21 Keith Hodges <keith_hodges@yahoo.co.uk>:
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 :)
Igor,
I am not understanding your logic.
You appear to be saying that if package X has got current maintainers, then it is not rude to make your own version of Package X. And that if you fork a package that has no maintainer then you will be in trouble.
no, i meant package X having no maintainers and it should be ok to make fork of it. The trouble begins when another package - Y is maintained, but it depends on X. What you suppose to do with such situation?
I am saying the opposite - that if you fork a package that has got current maintainers, you
a) insult the maintainers, b) you undermine the progress that they may have made, c) you undermine any efforts thay have made to build a team and communication around that project. d) you prevent future progress by the existing team e) you make extra work for the exisiting team because you dont communicate with them and they are forced to play catch up to you all the time f) you send out the message that volunteering to maintain any part of the kernel is a hapless task, and will ultimately be a waste of time and effort.
i agree with you on that.. just read my message more carefully :)
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
2009/3/21 Keith Hodges <keith_hodges@yahoo.co.uk>:
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 :)
Igor,
I am not understanding your logic.
You appear to be saying that if package X has got current maintainers, then it is not rude to make your own version of Package X. And that if you fork a package that has no maintainer then you will be in trouble.
no, i meant package X having no maintainers and it should be ok to make fork of it. The trouble begins when another package - Y is maintained, but it depends on X. What you suppose to do with such situation?
You mean the exact situation that many of us have been in for the past 3+ years! At a lower level, you have to have some kind of buffer package. Thats what Kernel-Extensions was for, it was the buffer covering the multitude of sins in the unmaintained Kernel. This can also be achieved with more intelligent installation tools that can install things according to rules "if this class is missing then apply this fix/changeset/package". (btw coincidentally (or not) Sake implements such rules in it's ClassTasks) That's what "Installer mantis ensureFix:" is all about, its a dumb way of acheiving the same goal. The next level up in intelligence is Installer-Scripts (which includes the current implementation of LevelPlayingField). It can install things specific to product/image version. (Pharo's ScriptLoader is somewhat equivalent, for pharo only.) If everyone who is maintaining packages A,B,C,Y that depends upon X, manages their fixes to X in a co-ordinated manner with tools such as Installer-Scripts, or Sake/Packages, this documents all use cases in detail. Then the future maintainer of X has simply to look at all of the package load definitions, and the list of fixes to his package that they require, his work is practically done for him. Please note that was also the explicit intention and purpose behind allowing Sake/Packages to be non-declarative if need be. If a user has to add a script to get a package to work in their specific context, then Sake/Packages is providing a knowledge capture service for the developer of X, showing exactly what is needed to get X working in all the contexts in which it has been applied. At a higher level, you need to consider architecting your code to be modular and to have interface/protocol definitions, and at the highest level you can consider doing interface/protocol negotiations, either statically (at package load time, or dynamically at run time. Statically is easiest - if they have version 1 of the database use interface A... etc, all of which Sake/Packages can do. For example I have written a number of modules for seaside28, called the "Client Framework", these will need to be reimplemented for Seaside29, but should still provide the same API. Dynamically is doable, but there is so much irrational feeling against use of #respondsTo: #askFor:, Null, and other facilities for making this work on a generic basis. For example Null needs to be in the kernel, because it must be maintained in sync with the kernel and IDE, otherwise the Kernel/IDE developers keep doing things which ruin Null's day. (stef please take note - I know you hate Null, but it is not intended to be a replacement for nil, it is most useful as a replacement for an entire missing interface on a macro scale) Going the other way, there is also help for maintaining a single package that can be deployed in muliple different contexts. The new PackageInfo in MC1.5 has more facilities for exporting a package, and deploying it in different contexts. For example, you can mark methods as "squeak only", "gemstone", "VW only" for example. So while you code and maintain "MyPackage" in your repository, when you save "MyPackage.squeak" it will filter out any vw only methods, or pharo only methods. When you save MyPackage.vw it will not include classes in MyPackage-Squeak. MyPackage.impl filters out the tests, and MyPackage.test saves the tests only. ...btw Igor in response to your other email about splitting up MC. MC1.5 has already been organised into categories for potential splitting up. For example separation of Model and GUI. The tests have already departed. The Monticello-Orphanage is intended to be unloadable. I was planning to split out the PasswordManager into a system project "System-Passwords". Keith
Guys, Let me say few words from my experience, because such fork actually happened to Swazoo, which maintainer I am. So, was I insulted? Well, I was surely not happy, but insulted? No! I took that as a competitive pressure to be even better with main Swazoo line. To prove therefore with deeds that our branch is the best. So please, don't mix competition with insulting. Use the competitive pressure (anger if you wish) to ride on it and be even better! Prove yourself with your work! Community is wise enough to be able to choose the best contender at the end. If you are chosen, celebrate, if you are not, analyze situation and be better next time, but don't give up, and specially don't feel insulted! Best regards Janko Keith Hodges pravi:
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 :)
Igor,
I am not understanding your logic.
You appear to be saying that if package X has got current maintainers, then it is not rude to make your own version of Package X. And that if you fork a package that has no maintainer then you will be in trouble.
I am saying the opposite - that if you fork a package that has got current maintainers, you
a) insult the maintainers, b) you undermine the progress that they may have made, c) you undermine any efforts thay have made to build a team and communication around that project. d) you prevent future progress by the existing team e) you make extra work for the exisiting team because you dont communicate with them and they are forced to play catch up to you all the time f) you send out the message that volunteering to maintain any part of the kernel is a hapless task, and will ultimately be a waste of time and effort.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Janko Mivšek wrote:
Guys,
Let me say few words from my experience, because such fork actually happened to Swazoo, which maintainer I am. So, was I insulted? Well, I was surely not happy, but insulted? No!
I took that as a competitive pressure to be even better with main Swazoo line. To prove therefore with deeds that our branch is the best.
So please, don't mix competition with insulting. Use the competitive pressure (anger if you wish) to ride on it and be even better! Prove yourself with your work!
Community is wise enough to be able to choose the best contender at the end. If you are chosen, celebrate, if you are not, analyze situation and be better next time, but don't give up, and specially don't feel insulted!
Best regards Janko
Again its not about the technical choice, its about the philosophical principle. Let me make this clear. "I spent a year of my time on tools and ideas that may benefit all, only only only only only only only if all choose in principle to use those ideas." (we sort out the technical details in the end). Check through my last email, and look at what it means to the community if Pharo doesnt adopt MC1.5 and SUnit improved ideas (notice I said ideas, its not just limited to code). 1. You/I will have to manage a separate project JUST for pharo. The new(1 year old) PackageInfo-Base would allow you to export. MyPackage.pharo from your main distribution. 2. You will have to manage a separate test suite JUST for Pharo. The SUnit-improved is designed to allow tests to be marked and categorised as to what should work where. This scheme should also apply to other testing frameworks as they are integrated (SSpec). 3. You will have to manage a separate load script/universe for your pharo code, and users will not have a place to tweak their load scripts for pharo. Thus to support pharo you are forced to actually try loading your code in pharo regularly. Remember pharo is a moving target, so you will have to test it every month/week or so. IF your code ever fails to load you will get a black mark of incompetence from the community, so you had better keep on top of it. Meanwhile the squeak users can upload their feedback of what is needed to make your package work in squeak into the load scripts in Sake/Packages. Then on your next iteration you can go and pick up the required changes, at your leisure. If you wonder why I keep banging on about this, I have over 40 packages that I maintain both publically and as part of my work. I have gone to an extreme amount of effort to try and minimise the pain, and the pharo guys are ignoring the IDEAS and the code, and therefore making unnecessary work for everyone. Keith
2009/3/21 Keith Hodges <keith_hodges@yahoo.co.uk>:
Janko Mivšek wrote:
Guys,
Let me say few words from my experience, because such fork actually happened to Swazoo, which maintainer I am. So, was I insulted? Well, I was surely not happy, but insulted? No!
I took that as a competitive pressure to be even better with main Swazoo line. To prove therefore with deeds that our branch is the best.
So please, don't mix competition with insulting. Use the competitive pressure (anger if you wish) to ride on it and be even better! Prove yourself with your work!
Community is wise enough to be able to choose the best contender at the end. If you are chosen, celebrate, if you are not, analyze situation and be better next time, but don't give up, and specially don't feel insulted!
Best regards Janko
Again its not about the technical choice, its about the philosophical principle. Let me make this clear.
"I spent a year of my time on tools and ideas that may benefit all, only only only only only only only if all choose in principle to use those ideas." (we sort out the technical details in the end).
Check through my last email, and look at what it means to the community if Pharo doesnt adopt MC1.5 and SUnit improved ideas (notice I said ideas, its not just limited to code).
1. You/I will have to manage a separate project JUST for pharo. The new(1 year old) PackageInfo-Base would allow you to export. MyPackage.pharo from your main distribution.
2. You will have to manage a separate test suite JUST for Pharo. The SUnit-improved is designed to allow tests to be marked and categorised as to what should work where. This scheme should also apply to other testing frameworks as they are integrated (SSpec).
3. You will have to manage a separate load script/universe for your pharo code, and users will not have a place to tweak their load scripts for pharo. Thus to support pharo you are forced to actually try loading your code in pharo regularly. Remember pharo is a moving target, so you will have to test it every month/week or so. IF your code ever fails to load you will get a black mark of incompetence from the community, so you had better keep on top of it. Meanwhile the squeak users can upload their feedback of what is needed to make your package work in squeak into the load scripts in Sake/Packages. Then on your next iteration you can go and pick up the required changes, at your leisure.
If you wonder why I keep banging on about this, I have over 40 packages that I maintain both publically and as part of my work. I have gone to an extreme amount of effort to try and minimise the pain, and the pharo guys are ignoring the IDEAS and the code, and therefore making unnecessary work for everyone.
Keithy, what you proposing is change the development process pattern which people used to do for a years now, to a new, not yet clearly evaluated paradigms. I think you should be aware that forcing people to change their development style will meet a certain oppression. From your side, as an evangelist of a new approach, it very important to show how easy & painless the new process is going comparing to old one. Write tutorials , show simple 1.2.3. steps etc etc. Blaming the people that they keep using old development techniques is not the way to go. I think that Stephane clearly understands a different problems of software development , packaging, maintaining & distributing. What he maybe not clearly sees is a big win from using approach proposed by you. I hope you will find a meeting points to make interchange between Squeak & Pharo (and other forks) be painless, fun and productive.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Keithy, what you proposing is change the development process pattern which people used to do for a years now, to a new, not yet clearly evaluated paradigms.
Igor, I don't see any change in development process at all, because there is no existing development process for writing a package that is supported in multiple forks of squeak.
I think you should be aware that forcing people to change their development style will meet a certain oppression. From your side, as an evangelist of a new approach, it very important to show how easy & painless the new process is going comparing to old one. Write tutorials , show simple 1.2.3. steps etc etc. Blaming the people that they keep using old development techniques is not the way to go.
I am not forcing people to change their development style, the issue here has nothing to do with development style. The issue here is that I started a dialog, and I made an effort to move what was unmaintained proprietary getting-ever-more-bespoke-per-image code, into loadable packages, not tied to any one image, and into the public arena, owned by the whole community, and maintained on behalf of the whole community. This was in response to the visionary direction expressed by all parties, to work for smaller leaner and meaner kernel images. The pharo team are actively and purposefully working in the opposite direction, that's the problem. I made a lot of effort to make that dialog possible. For SUnit that dialog was initiated three years ago by making the repositories for SUnit available on squeaksource with open access, and providing a dummy SUnit that can be used to make SUnit unloadable from the main image, and by inviting participation. For Monticello it involved a lot of work merging all of the existing forks. My complaint is that the pharo guys are not participating in that dialog at all they have made no commits to that open repository. They have rudely forked a maintained code base, and they are "we have to maintain/take control" of code that is now community owned. The issue has nothing to do with the code quality or otherwise, it has nothing to do with a change in development style. The issue is one of philosophical choices being made by the leadership of the pharo team, as evidenced by daily contributions to the mailing list, which promote and demonstrate an exclusive rather than participatory attitude. Keith
Keith, Interestingly, I could make only minor modifications, and write that same paragraph with Squeak as the stone wall. The Squeak community ignored many wonderful ideas over a period of years of maintenance and incremental development; IMHO, look there to explain the numerous forks. Pharo has a stated objective of breaking what needs to be broken to make progress, and it's not even at a first release yet. You seem to think that the world will be a great place if all the Squeak forks can share code. What about VW, Dolphin, X, etc.? In the spirit of cooperation that you demand from the alpha versions of Pharo, Squeak could have, years ago, done something about its isolation of users of other dialects via its unique handling of underscores. The Pharo team is not being rude; they are focused on a huge task for the good of research, developers, users/customers, and Smalltalk. There is no animosity toward Squeak; there is determination to eliminate incompatibilities and cruft in general. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Keith Hodges Sent: Saturday, March 21, 2009 5:43 AM [snip] If you wonder why I keep banging on about this, I have over 40 packages that I maintain both publically and as part of my work. I have gone to an extreme amount of effort to try and minimise the pain, and the pharo guys are ignoring the IDEAS and the code, and therefore making unnecessary work for everyone. Keith
Schwab,Wilhelm K wrote:
Keith,
Interestingly, I could make only minor modifications, and write that same paragraph with Squeak as the stone wall. The Squeak community ignored many wonderful ideas Which is why we have finally got to a stage where the paradigm has shifted, even up to board level.
We started with LevelPlayingField, and that enabled progress in spite of the release team. Since that took off, Squeak hasnt been standing still or closed to new ideas. Nor have those that needed fixes to the image been left stranded, with "Installer mantis". What we have lacked is a new release in image form.
over a period of years of maintenance and incremental development; When I fully joined the squeak community, who was running the release team? Yes it was exactly the same guys as are the pharo team, namely Stef, and Marcus. IMHO, look there to explain the numerous forks. Pharo has a stated objective of breaking what needs to be broken to make progress, and it's not even at a first release yet.
And so has LevelPlayingField, it enables you to break what needs to be broken, because you can put the compatibility back into LevelPlayingField if you need to.
You seem to think that the world will be a great place if all the Squeak forks can share code. No, but I do think it will be a horrible place if we cant, and you have to think these things through and plan. "If you fail to plan, you plan to fail", I think it goes. For a start if projects like Pier and Seaside go Pharo only, then I am really up a creek. What about VW, Dolphin, X, etc.? In the spirit of cooperation that you demand from the alpha versions of Pharo, Squeak could have, years ago, done something about its isolation of users of other dialects via its unique handling of underscores.
Agreed. Underscores has been first on my list (waiting for when I get time to hack the kernel) for three years.
The Pharo team is not being rude; they are focused on a huge task for the good of research, developers, users/customers, and Smalltalk. There is no animosity toward Squeak; there is determination to eliminate incompatibilities and cruft in general.
What is your definition of rude then? ( http://www.everything2.org/title/Americans%2520are%2520rude ) If I make a fix to a package that someone else is maintaining, I attempt to contact the maintainer and talk the change through with them. At the very least I attempt to check my fix into their repo so that they can benefit from it. Before making Sake/Packages, I discussed with the 3.10 release team, and the creator of Universes to see if we could adapt Universes to provide the needed functionality. Lex refused to relax the openness of universes or to compromise on the purely declarative approach, so Sake/Packages was born. Its called communication and recognising that some one else put their time and effort into solving the problem before on my behalf, and also the antithesis of "not invented here". Keith
over a period of years of maintenance and incremental development; When I fully joined the squeak community, who was running the release team? Yes it was exactly the same guys as are the pharo team, namely Stef, and Marcus.
booooohhhhh we are the "vilain"..... We were trying to break as much as possible and we did a robust release that integrated more than 625 bug fixes. So please respect that. And yes you are insulting us. Stef
Stéphane Ducasse wrote:
over a period of years of maintenance and incremental development;
When I fully joined the squeak community, who was running the release team? Yes it was exactly the same guys as are the pharo team, namely Stef, and Marcus.
booooohhhhh we are the "vilain".....
I didn't say that. I was apparently being told that I shouldn't criticise you because you are the "champions of the new way" and that the old squeak days were far worse. When in actual fact from my perspective the old old squeak days are irrelevant (I was using ST/X) and the recent-old squeak days were run by you, so you are not "champions of a new way" after all, you are champions of "your way", which is the same way that you did 3.9, but with less stake holders. I am not saying that "your way" is villainous. I am saying that it is a complete straw man to use the "old old ways" of the past to justify how wonderful "your way" is, when actually "your present way" is just the same, Keith
janko did we do a fork of swazoo? I mean in pharo? I was not aware of that. Stef On Mar 21, 2009, at 10:24 AM, Janko Mivšek wrote:
Guys,
Let me say few words from my experience, because such fork actually happened to Swazoo, which maintainer I am. So, was I insulted? Well, I was surely not happy, but insulted? No!
I took that as a competitive pressure to be even better with main Swazoo line. To prove therefore with deeds that our branch is the best.
So please, don't mix competition with insulting. Use the competitive pressure (anger if you wish) to ride on it and be even better! Prove yourself with your work!
Community is wise enough to be able to choose the best contender at the end. If you are chosen, celebrate, if you are not, analyze situation and be better next time, but don't give up, and specially don't feel insulted!
Best regards Janko
Keith Hodges pravi:
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 :)
Igor,
I am not understanding your logic.
You appear to be saying that if package X has got current maintainers, then it is not rude to make your own version of Package X. And that if you fork a package that has no maintainer then you will be in trouble.
I am saying the opposite - that if you fork a package that has got current maintainers, you
a) insult the maintainers, b) you undermine the progress that they may have made, c) you undermine any efforts thay have made to build a team and communication around that project. d) you prevent future progress by the existing team e) you make extra work for the exisiting team because you dont communicate with them and they are forced to play catch up to you all the time f) you send out the message that volunteering to maintain any part of the kernel is a hapless task, and will ultimately be a waste of time and effort.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Stef, Stéphane Ducasse pravi:
did we do a fork of swazoo? I mean in pharo? I was not aware of that.
No, not on Pharo and not by you the Pharo guys. Fork named Hyper was done on VW and Gemstone. Sorry for misunderstanding, I made a general example to show and to recommend, what to do in such case. Best regards Janko
Stef
On Mar 21, 2009, at 10:24 AM, Janko Mivšek wrote:
Guys,
Let me say few words from my experience, because such fork actually happened to Swazoo, which maintainer I am. So, was I insulted? Well, I was surely not happy, but insulted? No!
I took that as a competitive pressure to be even better with main Swazoo line. To prove therefore with deeds that our branch is the best.
So please, don't mix competition with insulting. Use the competitive pressure (anger if you wish) to ride on it and be even better! Prove yourself with your work!
Community is wise enough to be able to choose the best contender at the end. If you are chosen, celebrate, if you are not, analyze situation and be better next time, but don't give up, and specially don't feel insulted!
Best regards Janko
Keith Hodges pravi:
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 :)
Igor,
I am not understanding your logic.
You appear to be saying that if package X has got current maintainers, then it is not rude to make your own version of Package X. And that if you fork a package that has no maintainer then you will be in trouble.
I am saying the opposite - that if you fork a package that has got current maintainers, you
a) insult the maintainers, b) you undermine the progress that they may have made, c) you undermine any efforts thay have made to build a team and communication around that project. d) you prevent future progress by the existing team e) you make extra work for the exisiting team because you dont communicate with them and they are forced to play catch up to you all the time f) you send out the message that volunteering to maintain any part of the kernel is a hapless task, and will ultimately be a waste of time and effort.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
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
Stéphane Ducasse wrote:
Geeeee.
MC is not any project, it is our key infrastructural element. So we must control it.
I disagree, its key to all users of squeak. So you must ensure that it is looked after and maintained. There is absolutely no need to control it. You can control it by contributing to it and participating in its future development. By competing you kill it, and you are killing it stone dead, because no one can add a feature without being held back by the users of the other fork(s).
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. What kind of people are you working with? How rude can people get? This is open source for goodness sake. You aint paying for this stuff, on the contrary, its costing me a fortune.
I have a 1977 camper van that I am currently restoring, someone once said to me "anything you do to it, will be an improvement", well that was the state of MC1.0. It's about teamwork, and merging of talents. I never said I was qualified to take on maintenance of MC, I never wanted to do it. The fact is that MC1 is unusable, and someone had to fix it. The future of MC depends entirely upon the contribution of a team of people, but your attitude and the attitude of these myopic individuals precludes it, because none of you will contribute to the team effort required. You have a community full of people who write great code and dont write a single class comment, and yet their often unusable contributions are accepted without being completely insulted!
So we pay attention.
Those people have not contributed to MC either therefore their input is completely mute and irrelevant. I have said many times before, the code is not relevant it is the attitude that is important. If you dont like the code then the repo is open to fix it, and the forums are available to comment on it. Some people have found their feedback incorporated within the hour! People who cant be bothered to offer feedback or participate, have no right to criticise. Ok the tests are not up to scratch, I cant help it if whoever wrote the tests made them incomprehensible. When lukas loaded MC1.5 an installation error didnt completely unload the previous version of MC1 then he complained that there were lots of unsent messages. I don't have time to work on MC1.5 anymore, so those who say "dont use keiths code", are sending a huge message to anyone who cant make a perfect contribution to the community not to bother, your contribution will be discarded.
When I took the time to give feedback on kernel extensions or rio this
But you never even understood what the reason behind kernel-extension was, you criticised it and refused to use anything that depended on it, because it wasn't perfectly what you wanted, and it contained method overrides. That was the whole point, it was supposed to contain method overrides. If you put all of the method overrides for the kernel in one place, then multiple overlapping method overrides from different packages do not occur, there will be no conflicts. Having them in Kernel-Extensions gives you a place to manage them and participate in the discussion over what would be accepted or not. You didn't really participate in that discussion, you simply said things along the line of Kernel-Extensions includes Null therefore we dont like it, full stop. Again you threw the baby out with the bath water. When I stopped using Kernel-Extensions, and started using changesets to publish exactly the same code without method overrides, all of a sudden the same code became magically acceptable! You might be interested to know that more than 80-90% of what was Kernel-Extensions has already been added to pharo, so there wasnt so much wrong with it after all.
Do you think that I'm rude because I reply to you or when I do not reply?
Its got nothing to do with replying or not. Its all to do with your team having the expertise to get SystemEditor working with Traits, for the good of all, but instead you spend time and effort forking MC, for the good of yourselves, and in the process trash a lot of time and effort expended for your benefit. Its to do with your team forking SUnit unnecessarily etc etc
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, You saw how we worked with the settings and preference discussion with alain.
So Alain is external to your team? He had the courtesy of discussing the preferences ideas with the wider community, and for that I thanked him, and added him to my "non-rude" list.
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.
Hang on... this is a list of projects, most of which dont have any code yet, and you are talking about rejecting stuff that doesnt meet your standards! That's exactly what I mean. If you spec out a project, plan it, and "contribute" to the team that works on it, then it will meet your standards by definition. Therefore there is no need to prejudice anything with such comments as "if 'their' work its not up to 'our' standards". That's my whole point, you get the standards you want by participating in the process, not by looking down your nose at the contributions being hacked by some poor old stressed out full time carer.
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
These "some people", are more folks who have never sent me a single email discussing the design. And by the way Rio has had three complete redesigns since it was first written, incorporating various feedback and ideas. Thankfully I have "some emails" from "some people" who like it Keith
But you never even understood what the reason behind kernel-extension was, you criticised it and refused to use anything that depended on it, because it wasn't perfectly what you wanted, and it contained method overrides.
This was feedback and explanation for YOU of why we did not include it.
That was the whole point, it was supposed to contain method overrides. If you put all of the method overrides for the kernel in one place, then multiple overlapping method overrides from different packages do not occur, there will be no conflicts.
You didn't really participate in that discussion, you simply said things along the line of Kernel-Extensions includes Null therefore we dont like it, full stop.
No I gave you feedback. Who else by the way? **I** sat with damien and we together read the code and sent it.
When I stopped using Kernel-Extensions, and started using changesets to publish exactly the same code without method overrides, all of a sudden the same code became magically acceptable! You might be interested to know that more than 80-90% of what was Kernel-Extensions has already been added to pharo, so there wasnt so much wrong with it after all.
Not that much. I checked.
Its got nothing to do with replying or not.
Yes it is because I can ignore you completely too.
Its all to do with your team having the expertise to get SystemEditor working with Traits, for the good of all, but instead you spend time and effort forking MC, for the good of yourselves, and in the process trash a lot of time and effort expended for your benefit.
We are not doing that. We are running after time.
Its to do with your team forking SUnit unnecessarily etc etc
It is not my team, it is people with busy agenda not having the time to look at other packages
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, You saw how we worked with the settings and preference discussion with alain.
So Alain is external to your team? He had the courtesy of discussing the preferences ideas with the wider community, and for that I thanked him, and added him to my "non-rude" list.
Good!
Hang on... this is a list of projects, most of which dont have any code yet, and you are talking about rejecting stuff that doesnt meet your standards! That's exactly what I mean.
No I just warn you so that you do not get frustrated again.
If you spec out a project, plan it, and "contribute" to the team that works on it, then it will meet your standards by definition. Therefore there is no need to prejudice anything with such comments as "if 'their' work its not up to 'our' standards".
Exact! Keith hold on a moment. you are spining on yourself. We have a lot of deadlines, a lot of administration, I do pharo on my free time often the evening, I have no time to code what I want for my research, I fight all the time to get money, I have a huge pile of unfinished todos. So we all have more or less the same. So my contributions to something will be nearly null. Do you think that lukas can do more than seaside pier, phd, paper and books? Do you think that alex can do more than a start up, writing paper, fixing our code base on moose?
That's my whole point, you get the standards you want by participating in the process, not by looking down your nose at the contributions being hacked by some poor old stressed out full time carer.
But with the time constraints I have give feedback is the only thing I can do right now. Else I would have wrote another rio and lot more.
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
These "some people", are more folks who have never sent me a single email discussing the design. And by the way Rio has had three complete redesigns since it was first written, incorporating various feedback and ideas.
Thankfully I have "some emails" from "some people" who like it
I imagine that too.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
participants (7)
-
Damien Pollet -
Göran Krampe -
Igor Stasenko -
Janko Mivšek -
Keith Hodges -
Schwab,Wilhelm K -
Stéphane Ducasse