Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource

Damien Pollet
On Thu, Mar 19, 2009 at 22:46, Keith Hodges <[hidden email]> wrote:
> I have long been frustrated that there is no place in squeaksource for
> documenting what is in a repository, and offering feedback as to what
> works where.

Yes, and the MC tools should support that IMHO.
BTW I'd also add: no nice support for named/tagged branches (I mean,
in a big project there should be released/working/devel/in-progress
branches, or at least documented sequences of snapshots for stable
versions, and we have
package-developerUniversallyKnownToNotRegularlyBreakThings.biggestNumber.mcz)

> I have started to use Sake/Packages as a kind of micro "universe" for my
> Seaside "Client" UI & Backend Component Framework. Having seen how
> useful this is I thought that this might be useful for pier, and of
> course seaside and other projects.

Yup, I like the idea.

> Some have reservations about Sake/Packages because they say it is not
> declaritive.

Huh… it's a rule system, right ? The alternative I know about being
scripts that explicitly load snapshots in sequence, I fail to see
where sake is not declarative.

From my discussions on the subject, problems are more about the
perception of what level of predictability and control one would get
by using sake. Questions like "how do I know what will get installed
if I pull this one" or "how do I install this, but with this
particular version of that", and so on. Maybe it's a problem of
polishing the DSL, of documentation, maybe of tools, I'm not sure;
that could be investigated a bit more.

For me it's clear that automatic dependancy management is the way to
go, though the squeak/pharo community does not have resources or
organization like debian's, so I think we need a more decentralized
and agile way of managing dependancies, detecting and resolving
incoherencies, etc.

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource

keith1y
Damien Pollet wrote:
> On Thu, Mar 19, 2009 at 22:46, Keith Hodges <[hidden email]> wrote:
>  
>> I have long been frustrated that there is no place in squeaksource for
>> documenting what is in a repository, and offering feedback as to what
>> works where.
>>    
>
> Yes, and the MC tools should support that IMHO.
>  
It was one of the first ideas I was going to add to MC, even just to
have a simple text file explaining what is going on in a repo.

I put a lot of effort into MC to bring the forks together, and make it
maintained and able to move forward with one voice. That failed, so my
motivation for hacking MC anymore is pretty low.
> BTW I'd also add: no nice support for named/tagged branches (I mean,
> in a big project there should be released/working/devel/in-progress
> branches, or at least documented sequences of snapshots for stable
> versions, and we have
> package-developerUniversallyKnownToNotRegularlyBreakThings.biggestNumber.mcz)
>  
My brain struggles with branches. Perhaps not having them is a good idea?
>> I have started to use Sake/Packages as a kind of micro "universe" for my
>> Seaside "Client" UI & Backend Component Framework. Having seen how
>> useful this is I thought that this might be useful for pier, and of
>> course seaside and other projects.
>>    
>
> Yup, I like the idea.
Great!
>> Some have reservations about Sake/Packages because they say it is not
>> declaritive.
>>    
>
> Huh… it's a rule system, right ? The alternative I know about being
> scripts that explicitly load snapshots in sequence, I fail to see
> where sake is not declarative.
>  
Its because the rules to load: a package can be blocks executing an
arbitrary script. In normal use the #defaultAction is to process the
given "declared" url to find the package to load.
> From my discussions on the subject, problems are more about the
> perception of what level of predictability and control one would get
> by using sake. Questions like "how do I know what will get installed
> if I pull this one"
(Package named: 'SomePackage) what explore.

This could be improved to ask Installer exactly what it will install,
perhaps -

(Package named: 'SomePackage) whatUsingDryRun explore.

Also with DeltaStreams integration with Installer, we might have the
ability to load into a "Delta/SystemEditor" rather than actually in to
the image.
>  or "how do I install this, but with this
> particular version of that", and so on. Maybe it's a problem of
>  
Interesting point. I cant think of how to do that. Unless you use sake
to generate a script or a task data scructure, and then you manually
edit it.

How about merging two dependency trees like so:

(Packages current named: 'Seaside) using: (Packages beta named: 'Pier)
> polishing the DSL, of documentation, maybe of tools, I'm not sure;
> that could be investigated a bit more.
>  
Can never get enough Documentation!
> For me it's clear that automatic dependancy management is the way to
> go, though the squeak/pharo community does not have resources or
> organization like debian's, so I think we need a more decentralized
> and agile way of managing dependancies, detecting and resolving
> incoherencies, etc.
>  
Bob might be able to do something like that in the future. He is sitting
there monitoring a number of repositories, he could periodically process
contributions and derive dependencies because he has some knowledge of
the big picture.

Keith



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Göran Krampe
Hi!

Keith Hodges wrote:
> Also with DeltaStreams integration with Installer, we might have the
> ability to load into a "Delta/SystemEditor" rather than actually in to
> the image.

Ah! There's my queue! :)

Yes, although I only read casually what you are talking about I do agree
with the general notions expressed. And yes, hopefully we will soon have
Deltas in a useful form.

Quick status again, followed with some questions:

- Lots of tests are now green, still lots of tests not green but most of
them are "wishful thinking"-tests and not really broken tests.
- I am refactoring and cleaning right now, as a pre-cursor to adding the
new file format.
- I am also just beginning to try out Tirade as a file format. For more
info on Tirade, see my first article:

    http://goran.krampe.se/blog/Squeak/Tirade.rdoc

So in a relatively short timeperiod I hope we have code to load and save
Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would these
two file extensions work? Or should we use convention *.d and *.d.gz?

Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas - I
would also like to hear advice on how to build that in order to:

- Be compatible with as many Squeak forks as possible.
- Get a clean nice simple tool.

Just copy plain dual change sorter? Use Toolbuilder? Use MC codebase?
Omnibase?

The end goal would be to fully replace Dual Change Sorter - which means
that I would also like to have some support for loading a cs as a Delta
and to save a Delta as a plain cs.

...and as always, if you like to join us in moving Deltastreams forward,
just holler!

regards, Göran


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Stéphane Ducasse
Hi goran

I did not get at all why you need a new format.
Without self.
I think that if you want adoption of deltastream do not mix them with  
a file format.

Stef

On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote:

> Hi!
>
> Keith Hodges wrote:
>> Also with DeltaStreams integration with Installer, we might have the
>> ability to load into a "Delta/SystemEditor" rather than actually in  
>> to
>> the image.
>
> Ah! There's my queue! :)
>
> Yes, although I only read casually what you are talking about I do  
> agree
> with the general notions expressed. And yes, hopefully we will soon  
> have
> Deltas in a useful form.
>
> Quick status again, followed with some questions:
>
> - Lots of tests are now green, still lots of tests not green but  
> most of
> them are "wishful thinking"-tests and not really broken tests.
> - I am refactoring and cleaning right now, as a pre-cursor to adding  
> the
> new file format.
> - I am also just beginning to try out Tirade as a file format. For  
> more
> info on Tirade, see my first article:
>
>    http://goran.krampe.se/blog/Squeak/Tirade.rdoc
>
> So in a relatively short timeperiod I hope we have code to load and  
> save
> Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would  
> these
> two file extensions work? Or should we use convention *.d and *.d.gz?
>
> Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas  
> - I
> would also like to hear advice on how to build that in order to:
>
> - Be compatible with as many Squeak forks as possible.
> - Get a clean nice simple tool.
>
> Just copy plain dual change sorter? Use Toolbuilder? Use MC codebase?
> Omnibase?
>
> The end goal would be to fully replace Dual Change Sorter - which  
> means
> that I would also like to have some support for loading a cs as a  
> Delta
> and to save a Delta as a plain cs.
>
> ...and as always, if you like to join us in moving Deltastreams  
> forward,
> just holler!
>
> regards, Göran
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Igor Stasenko
i wonder, wouldn't it be better to adopt a new smalltalk scripting
format, which annouced here lately?
IMO it is better to use single format for many different purposes than
use multiple formats.
What you think?

2009/3/20 Stéphane Ducasse <[hidden email]>:

> Hi goran
>
> I did not get at all why you need a new format.
> Without self.
> I think that if you want adoption of deltastream do not mix them with
> a file format.
>
> Stef
>
> On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote:
>
>> Hi!
>>
>> Keith Hodges wrote:
>>> Also with DeltaStreams integration with Installer, we might have the
>>> ability to load into a "Delta/SystemEditor" rather than actually in
>>> to
>>> the image.
>>
>> Ah! There's my queue! :)
>>
>> Yes, although I only read casually what you are talking about I do
>> agree
>> with the general notions expressed. And yes, hopefully we will soon
>> have
>> Deltas in a useful form.
>>
>> Quick status again, followed with some questions:
>>
>> - Lots of tests are now green, still lots of tests not green but
>> most of
>> them are "wishful thinking"-tests and not really broken tests.
>> - I am refactoring and cleaning right now, as a pre-cursor to adding
>> the
>> new file format.
>> - I am also just beginning to try out Tirade as a file format. For
>> more
>> info on Tirade, see my first article:
>>
>>    http://goran.krampe.se/blog/Squeak/Tirade.rdoc
>>
>> So in a relatively short timeperiod I hope we have code to load and
>> save
>> Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would
>> these
>> two file extensions work? Or should we use convention *.d and *.d.gz?
>>
>> Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas
>> - I
>> would also like to hear advice on how to build that in order to:
>>
>> - Be compatible with as many Squeak forks as possible.
>> - Get a clean nice simple tool.
>>
>> Just copy plain dual change sorter? Use Toolbuilder? Use MC codebase?
>> Omnibase?
>>
>> The end goal would be to fully replace Dual Change Sorter - which
>> means
>> that I would also like to have some support for loading a cs as a
>> Delta
>> and to save a Delta as a plain cs.
>>
>> ...and as always, if you like to join us in moving Deltastreams
>> forward,
>> just holler!
>>
>> regards, Göran
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Stéphane Ducasse
the same :)
I like coral scripting format.
this is just a better chunk format :)

But I do not want to open a war again. So better do it "alone" than  
fight with others.
This is also my motto.

Stef



> i wonder, wouldn't it be better to adopt a new smalltalk scripting
> format, which annouced here lately?
> IMO it is better to use single format for many different purposes than
> use multiple formats.
> What you think?
>
> 2009/3/20 Stéphane Ducasse <[hidden email]>:
>> Hi goran
>>
>> I did not get at all why you need a new format.
>> Without self.
>> I think that if you want adoption of deltastream do not mix them with
>> a file format.
>>
>> Stef
>>
>> On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote:
>>
>>> Hi!
>>>
>>> Keith Hodges wrote:
>>>> Also with DeltaStreams integration with Installer, we might have  
>>>> the
>>>> ability to load into a "Delta/SystemEditor" rather than actually in
>>>> to
>>>> the image.
>>>
>>> Ah! There's my queue! :)
>>>
>>> Yes, although I only read casually what you are talking about I do
>>> agree
>>> with the general notions expressed. And yes, hopefully we will soon
>>> have
>>> Deltas in a useful form.
>>>
>>> Quick status again, followed with some questions:
>>>
>>> - Lots of tests are now green, still lots of tests not green but
>>> most of
>>> them are "wishful thinking"-tests and not really broken tests.
>>> - I am refactoring and cleaning right now, as a pre-cursor to adding
>>> the
>>> new file format.
>>> - I am also just beginning to try out Tirade as a file format. For
>>> more
>>> info on Tirade, see my first article:
>>>
>>>    http://goran.krampe.se/blog/Squeak/Tirade.rdoc
>>>
>>> So in a relatively short timeperiod I hope we have code to load and
>>> save
>>> Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would
>>> these
>>> two file extensions work? Or should we use convention *.d and  
>>> *.d.gz?
>>>
>>> Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas
>>> - I
>>> would also like to hear advice on how to build that in order to:
>>>
>>> - Be compatible with as many Squeak forks as possible.
>>> - Get a clean nice simple tool.
>>>
>>> Just copy plain dual change sorter? Use Toolbuilder? Use MC  
>>> codebase?
>>> Omnibase?
>>>
>>> The end goal would be to fully replace Dual Change Sorter - which
>>> means
>>> that I would also like to have some support for loading a cs as a
>>> Delta
>>> and to save a Delta as a plain cs.
>>>
>>> ...and as always, if you like to join us in moving Deltastreams
>>> forward,
>>> just holler!
>>>
>>> regards, Göran
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Igor Stasenko
2009/3/20 Stéphane Ducasse <[hidden email]>:
> the same :)
> I like coral scripting format.
> this is just a better chunk format :)
>
> But I do not want to open a war again. So better do it "alone" than
> fight with others.
> This is also my motto.
>
I looking at it at different angle:
  why inventing own wheel, when there is already existing solutions.
I'm not sure if Coral fits well with DS (looks like it depends on
NewCompiler),  i just gave Goran a links, so he could decide if it is.

> Stef
>
>
>
>> i wonder, wouldn't it be better to adopt a new smalltalk scripting
>> format, which annouced here lately?
>> IMO it is better to use single format for many different purposes than
>> use multiple formats.
>> What you think?
>>
>> 2009/3/20 Stéphane Ducasse <[hidden email]>:
>>> Hi goran
>>>
>>> I did not get at all why you need a new format.
>>> Without self.
>>> I think that if you want adoption of deltastream do not mix them with
>>> a file format.
>>>
>>> Stef
>>>
>>> On Mar 20, 2009, at 9:42 AM, Göran Krampe wrote:
>>>
>>>> Hi!
>>>>
>>>> Keith Hodges wrote:
>>>>> Also with DeltaStreams integration with Installer, we might have
>>>>> the
>>>>> ability to load into a "Delta/SystemEditor" rather than actually in
>>>>> to
>>>>> the image.
>>>>
>>>> Ah! There's my queue! :)
>>>>
>>>> Yes, although I only read casually what you are talking about I do
>>>> agree
>>>> with the general notions expressed. And yes, hopefully we will soon
>>>> have
>>>> Deltas in a useful form.
>>>>
>>>> Quick status again, followed with some questions:
>>>>
>>>> - Lots of tests are now green, still lots of tests not green but
>>>> most of
>>>> them are "wishful thinking"-tests and not really broken tests.
>>>> - I am refactoring and cleaning right now, as a pre-cursor to adding
>>>> the
>>>> new file format.
>>>> - I am also just beginning to try out Tirade as a file format. For
>>>> more
>>>> info on Tirade, see my first article:
>>>>
>>>>    http://goran.krampe.se/blog/Squeak/Tirade.rdoc
>>>>
>>>> So in a relatively short timeperiod I hope we have code to load and
>>>> save
>>>> Deltas as xxx.d (Delta Tirade format) and xxx.dgz (Gzipped). Would
>>>> these
>>>> two file extensions work? Or should we use convention *.d and
>>>> *.d.gz?
>>>>
>>>> Next step IMHO is to write a Dual Change Sorter-ish tool for Deltas
>>>> - I
>>>> would also like to hear advice on how to build that in order to:
>>>>
>>>> - Be compatible with as many Squeak forks as possible.
>>>> - Get a clean nice simple tool.
>>>>
>>>> Just copy plain dual change sorter? Use Toolbuilder? Use MC
>>>> codebase?
>>>> Omnibase?
>>>>
>>>> The end goal would be to fully replace Dual Change Sorter - which
>>>> means
>>>> that I would also like to have some support for loading a cs as a
>>>> Delta
>>>> and to save a Delta as a plain cs.
>>>>
>>>> ...and as always, if you like to join us in moving Deltastreams
>>>> forward,
>>>> just holler!
>>>>
>>>> regards, Göran
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Göran Krampe
In reply to this post by Stéphane Ducasse
Hi!

Stéphane Ducasse wrote:
> Hi goran
>
> I did not get at all why you need a new format.
> Without self.
> I think that if you want adoption of deltastream do not mix them with  
> a file format.

I am sorry, perhaps you haven't followed the reasoning, a quick recap:

1. Deltas are not bound to a specific format on disk. You can store them
in any way you like. They are "self contained object graphs" in the
image and can trivially be serialized.

2. Matthew made a format called "Interleaved ChangeSet" which combines
binary data with the chunk format meaning that a Delta can be stored
both as a changeset (loosing lots of info) and a Delta embedded inside
it. This means an old image can "file it in" just like a cs.

3. I think the Interleaved format is a bit too complex and while it is
"cool" I don't think the use case is *that* important (being backward
compatible for images that don't know what a Delta is). It is probably
simpler to include easy conversion delta2cs and cs2delta. These
conversions are not lossless however.

4. Since I wanted a readable, simple, fast, editable, and secure format
for Deltas - I came up with Tirade. Chunk format is readable, simple and
editable but it is not fast nor secure. It is also less "declarative" in
nature IMHO.

Tirade is well defined, small and simple. The Tirade package is just a
few classes and it is intended to work in "all Squeaks" - no
dependencies on any advanced stuff.

Tirade is a "data format" - it is NOT "Smalltalk code", it just happens
to match a lot of syntax and concepts. It is "merely" a sequence of
keyword messages with "data" as arguments (String, Symbol, Arrays,
Associations and Numbers - nested however you like). That is it. No
assignment, no variables, no globals, no expressions etc etc. It is NOT
Smalltalk. Adding "self" to it has no purpose, well, the ONLY purpose
would be to make it "look" like Smalltalk.

Now... this is repeating stuff I have already written elsewhere - but
there ya go. :)

regards, Göran


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

keith1y
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:

> the same :)
> I like coral scripting format.
> this is just a better chunk format :)
>
> But I do not want to open a war again. So better do it "alone" than  
> fight with others.
> This is also my motto.
>
> Stef
>  
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Göran Krampe
In reply to this post by Igor Stasenko
Hi guys!

Igor Stasenko wrote:
> 2009/3/20 Stéphane Ducasse <[hidden email]>:
>> the same :)
>> I like coral scripting format.
>> this is just a better chunk format :)

If you by that mean a really nice serialization format that fits to
serialize objects dealing with Smalltalk source code - then yes.

This is where the comparison with Coral probably breaks - correct me if
I am wrong, but Coral is a "better" .st format, right? Or in other words
- a format for typing in Smalltalk code in files.

Tirade is meant to *serialize* Delta and Change objects. It is not a
"fileout" format, it is much more a readable *serialization* format.

>> But I do not want to open a war again. So better do it "alone" than
>> fight with others.
>> This is also my motto.
>>
> I looking at it at different angle:
>   why inventing own wheel, when there is already existing solutions.
> I'm not sure if Coral fits well with DS (looks like it depends on
> NewCompiler),  i just gave Goran a links, so he could decide if it is.

I haven't seen a description of Coral yet - and no, I haven't installed
it and looked at it. I wanted a description first :). But given the
little I have read it seems to be a format for Smalltalk classes in
files. Period.

Again, this is not at all what Tirade is nor something suitable for
serializing Deltas, or am I missing something?

And yes, Tirade works fine today in 3.6->3.10.2 + Pharo. It's 500 lines
of code and independent of Compiler and has no other dependencies.

This is important for the use cases. :)

regards, Göran


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Stéphane Ducasse

On Mar 20, 2009, at 3:24 PM, Göran Krampe wrote:

> Hi guys!
>
> Igor Stasenko wrote:
>> 2009/3/20 Stéphane Ducasse <[hidden email]>:
>>> the same :)
>>> I like coral scripting format.
>>> this is just a better chunk format :)
>
> If you by that mean a really nice serialization format that fits to
> serialize objects dealing with Smalltalk source code - then yes.

coral is a reabable chunk format
not serialization of objects.


> This is where the comparison with Coral probably breaks - correct me  
> if
> I am wrong, but Coral is a "better" .st format, right? Or in other  
> words
> - a format for typing in Smalltalk code in files.

Yeap.

> Tirade is meant to *serialize* Delta and Change objects. It is not a
> "fileout" format, it is much more a readable *serialization* format.

Ok did you check SRP?

>
>
>>> But I do not want to open a war again. So better do it "alone" than
>>> fight with others.
>>> This is also my motto.
>>>
>> I looking at it at different angle:
>>  why inventing own wheel, when there is already existing solutions.
>> I'm not sure if Coral fits well with DS (looks like it depends on
>> NewCompiler),  i just gave Goran a links, so he could decide if it  
>> is.
>
> I haven't seen a description of Coral yet - and no, I haven't  
> installed
> it and looked at it. I wanted a description first :). But given the
> little I have read it seems to be a format for Smalltalk classes in
> files. Period.

yeap

>
>
> Again, this is not at all what Tirade is nor something suitable for
> serializing Deltas, or am I missing something?
>
> And yes, Tirade works fine today in 3.6->3.10.2 + Pharo. It's 500  
> lines
> of code and independent of Compiler and has no other dependencies.
>
> This is important for the use cases. :)
>
> regards, Göran
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Stéphane Ducasse
In reply to this post by keith1y
>>
> Perhaps you need healing from your fear of conflict. Ask your mind to
> reveal to you where it was you learned this emotional pattern. (its  
> not
> one I have ;-) )

keith this is much more simple than that.
I'm doing pharo just to avoid the endless discussions on "I need arrow  
for assignment".
I have nearly 20 years of brain cells now if I do not die before so I  
do not want to
spend my time on boring stuff when I can avoid it.

> Another case in point, on my to do list for squeak is "a registration
> mechanism for menus/flaps etc". There is absolutely NO reason why  
> such a
> mechanism shouldnt be specced out and developed as a loadable module  
> for
> all squeak forks to adopt.

Exact. Now the point is that we do not want to keep extra layer of  
compatibility for the sake
of it.

> Do we have to have 2 of absolutely everything?

No but we have the right to choose and consider if we like it or not.

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Igor Stasenko
2009/3/20 Stéphane Ducasse <[hidden email]>:

>>>
>> Perhaps you need healing from your fear of conflict. Ask your mind to
>> reveal to you where it was you learned this emotional pattern. (its
>> not
>> one I have ;-) )
>
> keith this is much more simple than that.
> I'm doing pharo just to avoid the endless discussions on "I need arrow
> for assignment".
> I have nearly 20 years of brain cells now if I do not die before so I
> do not want to
> spend my time on boring stuff when I can avoid it.
>
>> Another case in point, on my to do list for squeak is "a registration
>> mechanism for menus/flaps etc". There is absolutely NO reason why
>> such a
>> mechanism shouldnt be specced out and developed as a loadable module
>> for
>> all squeak forks to adopt.
>
> Exact. Now the point is that we do not want to keep extra layer of
> compatibility for the sake
> of it.
>
+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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Stéphane Ducasse
>>
> +1
> i think making squeak compatible with outer world (use ascii ':='
> instead of unicode '<-' and enable to use '_' in selectors and
> variables) is better than trying to be 'compatible' with 20 years old
> dusty stuff.

Yeap.

I dream about a Smalltalk that we can script, embed into c application,
talk well to c libraries, have nice libraries, tested....with nice mop,
So let us try to focus on that
Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

keith1y
In reply to this post by Stéphane Ducasse
>
> I have nearly 20 years of brain cells now if I do not die before so I  
> do not want to
> spend my time on boring stuff when I can avoid it.
>  
But you are throwing the baby out with the bath water.
> No but we have the right to choose and consider if we like it or not.
>
>  
Actually I disagree.

You are mixing two completely different things here.

1. Squeak, an open source project with lots of stake holders that may
cramp your style.
2. Any other completely open sub-project which you are invited to
contribute to and further your aims by participating with (i.e. Monticello)

When you forked pharo you understandably forked 1. There was no need to
fork any external projects (2)

Every sub-project (2) has its own developers, and its own culture, and
attitude towards participation and change. When you treat other -sub
projects and their communities with the same contempt that you
understandably have towards the squeak community, you result in
insulting those communities.

The initiative I started on MC has a culture of participation and
collaboration, together with an ethos of being as responsive as possible
to feedback and suggestions. When you ignore this, you insult everyone
that has put time and effort into that project.

In a similar manner, any initiative or sub-project that you undertake
within pharo, can have an ethos following either of two options.

A). Pharo team specific developed for pharo speced for pharo only.
B). A completely open sub-project which anyone is invited to support and
to further your aims by participating with.

When you pick option A, or fork option 2, you are actually insulting
every project that was offered to you on the basis of option 2 above.
Because you are saying, that you are happy to take from the other OSS
efforts but you are not happy to give back, or contribute back to them
on a similarly open basis. (and "you can port it if you want it" doesn't
count)

The clearest example of this continues to be Monticello.

When I do months of work and suffer considerably for the good of
"everyone that wants change" of which you were one person at the top of
the list. I do the work out of the goodness of my heart because I expect
in the ethos of open source software that there is some give and take.
"Take" because I build on the work of others that freely contributed to
me, and "give" because I contribute to the furtherment of the vision
that they started, and "take" again because I anticipate others
continuing the good fight in the long run on everyones behalf.

Given a completely open independent project, that you are invited to
support and contribute to, on which much work has already been done "on
YOUR behalf", in the direction of "YOUR goals". I consider it to be
extremely rude and insulting, for you not to join in and further your
own aims by contributing positively back to that project.

The reason that I have no interest in participating in pharo, is not
that I dont agree with the vision. Its the fact that I find the attitude
of the pharo team (with a couple of notable exceptions) to be extremely
rude. Perhaps its a cultural thing.

I consider the attitude conveyed by the words "No but we have the right
to choose and consider if we like it or not."  to be tantamount to
snobbery, when the option and invitation is completely open for you to
participate and make it as likeable as you wish.

It is perfectly possible for the following projects to be initiated as
loadable modular sub-projects, developed with an ethos of participation
for anyone to contribute and for anyone to use.

1. Registration for menus and UI features
2. Improvements to Streams
3. HTTPSocket
4. Alternatives to Changesets
5. Replace the changes file mechanism with something else
6. Atomic loading (including traits)
7. Replacements for Morphic, MVP
8. Compiler
9. Network.
10. Compression.
11. Files
12. SSpec
13. SUnit
14. Code Browsers/Tools

I am seriously considering licencing Rio under something other than MIT,
so that you cant use it, until you change your attitude towards your
potential benefactors.

Keith




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Igor Stasenko
2009/3/20 Keith Hodges <[hidden email]>:

>>
>> I have nearly 20 years of brain cells now if I do not die before so I
>> do not want to
>> spend my time on boring stuff when I can avoid it.
>>
> But you are throwing the baby out with the bath water.
>> No but we have the right to choose and consider if we like it or not.
>>
>>
> Actually I disagree.
>
> You are mixing two completely different things here.
>
> 1. Squeak, an open source project with lots of stake holders that may
> cramp your style.
> 2. Any other completely open sub-project which you are invited to
> contribute to and further your aims by participating with (i.e. Monticello)
>
> When you forked pharo you understandably forked 1. There was no need to
> fork any external projects (2)
>
> Every sub-project (2) has its own developers, and its own culture, and
> attitude towards participation and change. When you treat other -sub
> projects and their communities with the same contempt that you
> understandably have towards the squeak community, you result in
> insulting those communities.
>
> The initiative I started on MC has a culture of participation and
> collaboration, together with an ethos of being as responsive as possible
> to feedback and suggestions. When you ignore this, you insult everyone
> that has put time and effort into that project.
>
> In a similar manner, any initiative or sub-project that you undertake
> within pharo, can have an ethos following either of two options.
>
> A). Pharo team specific developed for pharo speced for pharo only.
> B). A completely open sub-project which anyone is invited to support and
> to further your aims by participating with.
>
> When you pick option A, or fork option 2, you are actually insulting
> every project that was offered to you on the basis of option 2 above.
> Because you are saying, that you are happy to take from the other OSS
> efforts but you are not happy to give back, or contribute back to them
> on a similarly open basis. (and "you can port it if you want it" doesn't
> count)
>
> The clearest example of this continues to be Monticello.
>
> When I do months of work and suffer considerably for the good of
> "everyone that wants change" of which you were one person at the top of
> the list. I do the work out of the goodness of my heart because I expect
> in the ethos of open source software that there is some give and take.
> "Take" because I build on the work of others that freely contributed to
> me, and "give" because I contribute to the furtherment of the vision
> that they started, and "take" again because I anticipate others
> continuing the good fight in the long run on everyones behalf.
>
> Given a completely open independent project, that you are invited to
> support and contribute to, on which much work has already been done "on
> YOUR behalf", in the direction of "YOUR goals". I consider it to be
> extremely rude and insulting, for you not to join in and further your
> own aims by contributing positively back to that project.
>
> The reason that I have no interest in participating in pharo, is not
> that I dont agree with the vision. Its the fact that I find the attitude
> of the pharo team (with a couple of notable exceptions) to be extremely
> rude. Perhaps its a cultural thing.
>
> I consider the attitude conveyed by the words "No but we have the right
> to choose and consider if we like it or not."  to be tantamount to
> snobbery, when the option and invitation is completely open for you to
> participate and make it as likeable as you wish.
>
> It is perfectly possible for the following projects to be initiated as
> loadable modular sub-projects, developed with an ethos of participation
> for anyone to contribute and for anyone to use.
>
> 1. Registration for menus and UI features
> 2. Improvements to Streams
> 3. HTTPSocket
> 4. Alternatives to Changesets
> 5. Replace the changes file mechanism with something else
> 6. Atomic loading (including traits)
> 7. Replacements for Morphic, MVP
> 8. Compiler
> 9. Network.
> 10. Compression.
> 11. Files
> 12. SSpec
> 13. SUnit
> 14. Code Browsers/Tools
>
> I am seriously considering licencing Rio under something other than MIT,
> so that you cant use it, until you change your attitude towards your
> potential benefactors.
>

There is one problem with Squeak, that it grew out to something
amorphous, up to the point that its really hard to tell where ends one
package/module and starts another one.
I sense the future of squeak is to make a cleaning to cut-out many
interdependencies, for getting to the point where all code is clearly
falls into separate modules. From this point, different modules can be
improved separately, but not sooner. And Pharo team is doing a lot for
making this happen.
For example, i wouldn't buy the Compression framework which fails to
work without Morphic/Etoys. And i don't think that making sure  it
doesn't have such interdependencies is a rude. I think its rude to
keep thing in such state by honing the swamp which equally sucks the
energy from everyone and suppressing progress.

You can't plant the wheat in the forest, first you have to cut down
the trees and get rid of stumps.
I think its too early to say that Pharo went too far from Squeak to
make it hard to backport any changes/improvements. I appreciate
Stephane's attempts to chop down some old rotten trees in forest to
make more space for growing a new sprouts.

There's another aspect of same thing: a lot of Squeak code/packages
having no maintainers.
People expect that someone takes care of code which is released with
image. But let us be realistic: there is no such developers/teams who
could take a grasp of such big code base and maintain it.
And there is choice: keep using old code (mostly w/o changes),
sacrificing the potential of having a lot of code bloat, or cut it out
and then reintegrate/reimplement it in a more modular style.

> Keith
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Stéphane Ducasse
In reply to this post by keith1y
Geeeee.

MC is not any project, it is our key infrastructural element. So we  
must control it.
Because it took us a lot of energy to build our infrastructure: I  
remember 3.9 endeavor.

>> The initiative I started on MC has a culture of participation and
> collaboration, together with an ethos of being as responsive as  
> possible
> to feedback and suggestions. When you ignore this, you insult everyone
> that has put time and effort into that project.
>
> When you pick option A, or fork option 2, you are actually insulting
> every project that was offered to you on the basis of option 2 above.
> Because you are saying, that you are happy to take from the other OSS
> efforts but you are not happy to give back, or contribute back to them
> on a similarly open basis. (and "you can port it if you want it"  
> doesn't
> count)

this is totally wrong. You can take our code and port it back to  
anything you like.
All our code is 100% MIT so what?
Some people are also just stealing/copying our ideas but this is life.

> The clearest example of this continues to be Monticello.

It is not since MC is not any project, it is our key infrastructural  
element.
So we must control it.

> When I do months of work and suffer considerably for the good of
> "everyone that wants change" of which you were one person at the top  
> of
> the list. I do the work out of the goodness of my heart because I  
> expect
> in the ethos of open source software that there is some give and take.
> "Take" because I build on the work of others that freely contributed  
> to
> me, and "give" because I contribute to the furtherment of the vision
> that they started, and "take" again because I anticipate others
> continuing the good fight in the long run on everyones behalf.

keith are you telling me that I did not give to this community.
Frankly? Are you serious? or blind?
I will not make a list of what I did and I'm doing because I do not do  
it
to enumerate it in public.

> Given a completely open independent project, that you are invited to
> support and contribute to, on which much work has already been done  
> "on
> YOUR behalf", in the direction of "YOUR goals". I consider it to be
> extremely rude and insulting, for you not to join in and further your
> own aims by contributing positively back to that project.

But of what are you talking? That you introduced traits support and  
atomic loading on MC
and that we do not consider it? But you know several people privately  
asked us not to
include your code. So we pay attention.

When I took the time to give feedback on kernel extensions or rio this  
was because I
considered your work and I wanted to help you improving your code.
But you can also think that I was whatever you want.

> The reason that I have no interest in participating in pharo, is not
> that I dont agree with the vision. Its the fact that I find the  
> attitude
> of the pharo team (with a couple of notable exceptions) to be  
> extremely
> rude. Perhaps its a cultural thing.

Do you think that I'm rude because I reply to you or when I do not  
reply?

> I consider the attitude conveyed by the words "No but we have the  
> right
> to choose and consider if we like it or not."  to be tantamount to
> snobbery,

this has nothing to do with snobbery. This has to do with freedom.
You as anybody else on this earth cannot get  a free check with what  
we are doing.
You saw how we worked with the settings and preference discussion with  
alain.
I like that way of doing things, we discuss and learn from each other.
This is one solution and first it should work well in pharo.
Of course this may not scale for more complex projects.

> when the option and invitation is completely open for you to
> participate and make it as likeable as you wish.

I do not ask for that. I do not see why I would have the right to come  
and change
think in your project.

> It is perfectly possible for the following projects to be initiated as
> loadable modular sub-projects, developed with an ethos of  
> participation
> for anyone to contribute and for anyone to use.
>
> 1. Registration for menus and UI features
> 2. Improvements to Streams
> 3. HTTPSocket
> 4. Alternatives to Changesets
> 5. Replace the changes file mechanism with something else
> 6. Atomic loading (including traits)
> 7. Replacements for Morphic, MVP
> 8. Compiler
> 9. Network.
> 10. Compression.
> 11. Files
> 12. SSpec
> 13. SUnit
> 14. Code Browsers/Tools

Probably. Now if we do not like the code quality we will not use that.
This has nothing with snobbery this has to do with credibility on the  
long run.

> I am seriously considering licencing Rio under something other than  
> MIT,
> so that you cant use it, until you change your attitude towards your
> potential benefactors.

Do it if you need, we will just not use it.
Note that some people do not like rio design, so the fact that it is  
MIT does not mean that
we will use it.  I looked at it because files are so bad in Squeak.
Now I can understand your frustration but there are few stuff I can do.
I do not have the time to do all the things I would like to do.

Stef





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Stéphane Ducasse
In reply to this post by Igor Stasenko
Yes. Sometimes I'm sad of removing fun stuff. But this is the way it is.

Igor I think that the point of keith was not about that goal (even if  
his process
implies been able to plant new trees everywhere and not cutting that  
much rotten trees).
I think that keith was frustrated that we could give feedback or  
threshold for
package inclusion in pharo and that he worked on them and that we  
neglected
them.
Now everybody has the right to stand up for or against a package and  
make a point.
Of course stating publicly that a given piece of code is great is  
easier than the inverse
especially when you want to pay attention to the human at the other  
end of the line.
Stef

On Mar 20, 2009, at 9:20 PM, Igor Stasenko wrote:

> 2009/3/20 Keith Hodges <[hidden email]>:
>>>
>>> I have nearly 20 years of brain cells now if I do not die before  
>>> so I
>>> do not want to
>>> spend my time on boring stuff when I can avoid it.
>>>
>> But you are throwing the baby out with the bath water.
>>> No but we have the right to choose and consider if we like it or  
>>> not.
>>>
>>>
>> Actually I disagree.
>>
>> You are mixing two completely different things here.
>>
>> 1. Squeak, an open source project with lots of stake holders that may
>> cramp your style.
>> 2. Any other completely open sub-project which you are invited to
>> contribute to and further your aims by participating with (i.e.  
>> Monticello)
>>
>> When you forked pharo you understandably forked 1. There was no  
>> need to
>> fork any external projects (2)
>>
>> Every sub-project (2) has its own developers, and its own culture,  
>> and
>> attitude towards participation and change. When you treat other -sub
>> projects and their communities with the same contempt that you
>> understandably have towards the squeak community, you result in
>> insulting those communities.
>>
>> The initiative I started on MC has a culture of participation and
>> collaboration, together with an ethos of being as responsive as  
>> possible
>> to feedback and suggestions. When you ignore this, you insult  
>> everyone
>> that has put time and effort into that project.
>>
>> In a similar manner, any initiative or sub-project that you undertake
>> within pharo, can have an ethos following either of two options.
>>
>> A). Pharo team specific developed for pharo speced for pharo only.
>> B). A completely open sub-project which anyone is invited to  
>> support and
>> to further your aims by participating with.
>>
>> When you pick option A, or fork option 2, you are actually insulting
>> every project that was offered to you on the basis of option 2 above.
>> Because you are saying, that you are happy to take from the other OSS
>> efforts but you are not happy to give back, or contribute back to  
>> them
>> on a similarly open basis. (and "you can port it if you want it"  
>> doesn't
>> count)
>>
>> The clearest example of this continues to be Monticello.
>>
>> When I do months of work and suffer considerably for the good of
>> "everyone that wants change" of which you were one person at the  
>> top of
>> the list. I do the work out of the goodness of my heart because I  
>> expect
>> in the ethos of open source software that there is some give and  
>> take.
>> "Take" because I build on the work of others that freely  
>> contributed to
>> me, and "give" because I contribute to the furtherment of the vision
>> that they started, and "take" again because I anticipate others
>> continuing the good fight in the long run on everyones behalf.
>>
>> Given a completely open independent project, that you are invited to
>> support and contribute to, on which much work has already been done  
>> "on
>> YOUR behalf", in the direction of "YOUR goals". I consider it to be
>> extremely rude and insulting, for you not to join in and further your
>> own aims by contributing positively back to that project.
>>
>> The reason that I have no interest in participating in pharo, is not
>> that I dont agree with the vision. Its the fact that I find the  
>> attitude
>> of the pharo team (with a couple of notable exceptions) to be  
>> extremely
>> rude. Perhaps its a cultural thing.
>>
>> I consider the attitude conveyed by the words "No but we have the  
>> right
>> to choose and consider if we like it or not."  to be tantamount to
>> snobbery, when the option and invitation is completely open for you  
>> to
>> participate and make it as likeable as you wish.
>>
>> It is perfectly possible for the following projects to be initiated  
>> as
>> loadable modular sub-projects, developed with an ethos of  
>> participation
>> for anyone to contribute and for anyone to use.
>>
>> 1. Registration for menus and UI features
>> 2. Improvements to Streams
>> 3. HTTPSocket
>> 4. Alternatives to Changesets
>> 5. Replace the changes file mechanism with something else
>> 6. Atomic loading (including traits)
>> 7. Replacements for Morphic, MVP
>> 8. Compiler
>> 9. Network.
>> 10. Compression.
>> 11. Files
>> 12. SSpec
>> 13. SUnit
>> 14. Code Browsers/Tools
>>
>> I am seriously considering licencing Rio under something other than  
>> MIT,
>> so that you cant use it, until you change your attitude towards your
>> potential benefactors.
>>
>
> There is one problem with Squeak, that it grew out to something
> amorphous, up to the point that its really hard to tell where ends one
> package/module and starts another one.
> I sense the future of squeak is to make a cleaning to cut-out many
> interdependencies, for getting to the point where all code is clearly
> falls into separate modules. From this point, different modules can be
> improved separately, but not sooner. And Pharo team is doing a lot for
> making this happen.
> For example, i wouldn't buy the Compression framework which fails to
> work without Morphic/Etoys. And i don't think that making sure  it
> doesn't have such interdependencies is a rude. I think its rude to
> keep thing in such state by honing the swamp which equally sucks the
> energy from everyone and suppressing progress.
>
> You can't plant the wheat in the forest, first you have to cut down
> the trees and get rid of stumps.
> I think its too early to say that Pharo went too far from Squeak to
> make it hard to backport any changes/improvements. I appreciate
> Stephane's attempts to chop down some old rotten trees in forest to
> make more space for growing a new sprouts.
>
> There's another aspect of same thing: a lot of Squeak code/packages
> having no maintainers.
> People expect that someone takes care of code which is released with
> image. But let us be realistic: there is no such developers/teams who
> could take a grasp of such big code base and maintain it.
> And there is choice: keep using old code (mostly w/o changes),
> sacrificing the potential of having a lot of code bloat, or cut it out
> and then reintegrate/reimplement it in a more modular style.
>
>> Keith
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Igor Stasenko
2009/3/20 Stéphane Ducasse <[hidden email]>:
> Yes. Sometimes I'm sad of removing fun stuff. But this is the way it is.
>
> Igor I think that the point of keith was not about that goal (even if
> his process
> implies been able to plant new trees everywhere and not cutting that
> much rotten trees).

Well, i tried to describe your motives, as i see it, to show that
often its not possible to build a new thing without breaking an old
one.
Again, as i said, lets say you improved/changed the package X to suit
your vision, and this package is no longer maintained by any other
party. So does it makes such change evil of some sort? I don't think
so.
Consider a Morphic. Can anyone tell who is maintaining it? No one!
Gary did a lot of hard work balancing between good and stinky code
trying to improve things in his Polymorph package without breaking
things in Morphic. Now think, how easier/faster it would be it we
would have an official Morphic package/module and official
maintainer(s) who continuously improving the code & maintaining it.

> I think that keith was frustrated that we could give feedback or
> threshold for
> package inclusion in pharo and that he worked on them and that we
> neglected
> them.
> Now everybody has the right to stand up for or against a package and
> make a point.
> Of course stating publicly that a given piece of code is great is
> easier than the inverse
> especially when you want to pay attention to the human at the other
> end of the line.

I think you have a full right to decide what [not] to include in Pharo.
Keith mentioned that you making many changes to many different parts
of system , which supposed to be maintained by original authour(s) or
currently active team(s), without giving a feedback or credit or
consulting with them about promoting such changes.
Okay, i think you're not stepping into other's domain.. it would be rude..
But its going to be tricky, when you change the package X (not
maintained by anyone), from which depends a lot of work, which doing
in parallel by other team for package Y, which depends on X.
Here lies the problem, which can be solved by communicating with
people. Of course it requires the good will of both sides :)

> Stef
>
> On Mar 20, 2009, at 9:20 PM, Igor Stasenko wrote:
>
>> 2009/3/20 Keith Hodges <[hidden email]>:
>>>>
>>>> I have nearly 20 years of brain cells now if I do not die before
>>>> so I
>>>> do not want to
>>>> spend my time on boring stuff when I can avoid it.
>>>>
>>> But you are throwing the baby out with the bath water.
>>>> No but we have the right to choose and consider if we like it or
>>>> not.
>>>>
>>>>
>>> Actually I disagree.
>>>
>>> You are mixing two completely different things here.
>>>
>>> 1. Squeak, an open source project with lots of stake holders that may
>>> cramp your style.
>>> 2. Any other completely open sub-project which you are invited to
>>> contribute to and further your aims by participating with (i.e.
>>> Monticello)
>>>
>>> When you forked pharo you understandably forked 1. There was no
>>> need to
>>> fork any external projects (2)
>>>
>>> Every sub-project (2) has its own developers, and its own culture,
>>> and
>>> attitude towards participation and change. When you treat other -sub
>>> projects and their communities with the same contempt that you
>>> understandably have towards the squeak community, you result in
>>> insulting those communities.
>>>
>>> The initiative I started on MC has a culture of participation and
>>> collaboration, together with an ethos of being as responsive as
>>> possible
>>> to feedback and suggestions. When you ignore this, you insult
>>> everyone
>>> that has put time and effort into that project.
>>>
>>> In a similar manner, any initiative or sub-project that you undertake
>>> within pharo, can have an ethos following either of two options.
>>>
>>> A). Pharo team specific developed for pharo speced for pharo only.
>>> B). A completely open sub-project which anyone is invited to
>>> support and
>>> to further your aims by participating with.
>>>
>>> When you pick option A, or fork option 2, you are actually insulting
>>> every project that was offered to you on the basis of option 2 above.
>>> Because you are saying, that you are happy to take from the other OSS
>>> efforts but you are not happy to give back, or contribute back to
>>> them
>>> on a similarly open basis. (and "you can port it if you want it"
>>> doesn't
>>> count)
>>>
>>> The clearest example of this continues to be Monticello.
>>>
>>> When I do months of work and suffer considerably for the good of
>>> "everyone that wants change" of which you were one person at the
>>> top of
>>> the list. I do the work out of the goodness of my heart because I
>>> expect
>>> in the ethos of open source software that there is some give and
>>> take.
>>> "Take" because I build on the work of others that freely
>>> contributed to
>>> me, and "give" because I contribute to the furtherment of the vision
>>> that they started, and "take" again because I anticipate others
>>> continuing the good fight in the long run on everyones behalf.
>>>
>>> Given a completely open independent project, that you are invited to
>>> support and contribute to, on which much work has already been done
>>> "on
>>> YOUR behalf", in the direction of "YOUR goals". I consider it to be
>>> extremely rude and insulting, for you not to join in and further your
>>> own aims by contributing positively back to that project.
>>>
>>> The reason that I have no interest in participating in pharo, is not
>>> that I dont agree with the vision. Its the fact that I find the
>>> attitude
>>> of the pharo team (with a couple of notable exceptions) to be
>>> extremely
>>> rude. Perhaps its a cultural thing.
>>>
>>> I consider the attitude conveyed by the words "No but we have the
>>> right
>>> to choose and consider if we like it or not."  to be tantamount to
>>> snobbery, when the option and invitation is completely open for you
>>> to
>>> participate and make it as likeable as you wish.
>>>
>>> It is perfectly possible for the following projects to be initiated
>>> as
>>> loadable modular sub-projects, developed with an ethos of
>>> participation
>>> for anyone to contribute and for anyone to use.
>>>
>>> 1. Registration for menus and UI features
>>> 2. Improvements to Streams
>>> 3. HTTPSocket
>>> 4. Alternatives to Changesets
>>> 5. Replace the changes file mechanism with something else
>>> 6. Atomic loading (including traits)
>>> 7. Replacements for Morphic, MVP
>>> 8. Compiler
>>> 9. Network.
>>> 10. Compression.
>>> 11. Files
>>> 12. SSpec
>>> 13. SUnit
>>> 14. Code Browsers/Tools
>>>
>>> I am seriously considering licencing Rio under something other than
>>> MIT,
>>> so that you cant use it, until you change your attitude towards your
>>> potential benefactors.
>>>
>>
>> There is one problem with Squeak, that it grew out to something
>> amorphous, up to the point that its really hard to tell where ends one
>> package/module and starts another one.
>> I sense the future of squeak is to make a cleaning to cut-out many
>> interdependencies, for getting to the point where all code is clearly
>> falls into separate modules. From this point, different modules can be
>> improved separately, but not sooner. And Pharo team is doing a lot for
>> making this happen.
>> For example, i wouldn't buy the Compression framework which fails to
>> work without Morphic/Etoys. And i don't think that making sure  it
>> doesn't have such interdependencies is a rude. I think its rude to
>> keep thing in such state by honing the swamp which equally sucks the
>> energy from everyone and suppressing progress.
>>
>> You can't plant the wheat in the forest, first you have to cut down
>> the trees and get rid of stumps.
>> I think its too early to say that Pharo went too far from Squeak to
>> make it hard to backport any changes/improvements. I appreciate
>> Stephane's attempts to chop down some old rotten trees in forest to
>> make more space for growing a new sprouts.
>>
>> There's another aspect of same thing: a lot of Squeak code/packages
>> having no maintainers.
>> People expect that someone takes care of code which is released with
>> image. But let us be realistic: there is no such developers/teams who
>> could take a grasp of such big code base and maintain it.
>> And there is choice: keep using old code (mostly w/o changes),
>> sacrificing the potential of having a lot of code bloat, or cut it out
>> and then reintegrate/reimplement it in a more modular style.
>>
>>> Keith
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

Igor Stasenko
Concenrning Monticello, i think it would be nice to split it on parts, like:
Monticello-Core
Monticello-Persistance (Files/Sockets etc)
Monticello-UI (Morphic/another framework)

now, make sure that Core part could work well with any squeak fork,
while rest of stuff can be easily replaced by different
implementations.

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12