A point a.k.a excuse to you

Hi guys

I probably should not have forwarded to you the email I replied to  
matthew
but I was thinking that other people can know that I was personally  
touched
by the situation in Squeak.
I'm sorry about.

We got a lot of bird names and others. Recently somebody was implying  
that
marcus was bashing squeak because he sent an email on the pharo  
mailing-list stating that the situation
for keyboard was worse in squeak.
I'm fed up. I'm interested in pharo because I want to create free and  
good energy.
We did a lot in the past and I want to continue. Now I unregistered  
from the squeak mailing-list
and I will not justify anymore why I quit. Now I want pharo to be cool.

Stef

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

On 01.03.2009, at 22:29, Stéphane Ducasse wrote:

Someone send a question to both squeak-dev and pharo-list... my mail  
program
then puts both adresses in the reply. Normally I remember to delete  
the squeak-dev
list, but I forgot it in that case (really, only realized it later).

Then, for the question of the bug-tracking, yes, I could not resist...

It would be nice if people would *not* send emails to both pharo and  
squeak lists.

        Marcus


--
Marcus Denker  --  [hidden email]
http://www.marcusdenker.de


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

Stéphane Ducasse-2 wrote

... and I will not justify anymore why I quit. Now I want pharo to be cool.
Stef

Good on ya mate! :)

Hi Stephane, I would not take it that seriously. Just focus that good energy you
have and use it in getting things done in pharo and adding real value to it.
Much it will receiver in return I'm sure of that.
best,
sebastian



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

I have the blame of it. I am who send emails to both list. So...this is my fault.

Sorry about it. The main problem I have is that when I have questions, suggestions, ideas or whatever, I really don't know where to post it: if in squeak-dev or pharo. I really don't know If what I want to say depends on the VM, or the image or to packages that are shared between both of them. In addition, I think there are important people that are only in one of the list. So, perhaps I miss an answer If I only send emails in one list. And probably, the same discussion could be useful for both lists.

What you think I should do ? which would be the better way so that not to cause the problem mentioned above?

I am following Pharo very near because this really interest me. I really want to LIVE AND EAT using an open source smalltalk. I don't want smalltalk to play. I want to WORK with it. So, I think Pharo is the better approach for my intention.

But, 90% the time I spend in Squeak is for SqueakDBX. And SqueakDBX doesn't work well in pharo. I have random segmentation faults trough FFI which I don't have in Squeak. I didn't want to spend many time trying to see what the problem is till 1.0 is releases. At that moment, I will look for the problem. When this is fixed, I will then really start using pharo 100%.

Cheers,

Mariano




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

tx

Stef

On Mar 1, 2009, at 10:46 PM, Sebastian Sastre wrote:


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

On Mar 1, 2009, at 11:32 PM, Mariano Martinez Peck wrote:

> I have the blame of it. I am who send emails to both list. So...this  
> is my fault.

No don't be sorry. The situation is stupid.

> Sorry about it. The main problem I have is that when I have  
> questions, suggestions, ideas or whatever, I really don't know where  
> to post it: if in squeak-dev or pharo. I really don't know If what I  
> want to say depends on the VM, or the image or to packages that are  
> shared between both of them. In addition, I think there are  
> important people that are only in one of the list. So, perhaps I  
> miss an answer If I only send emails in one list. And probably, the  
> same discussion could be useful for both lists.

Continue like you did it.
We will pay attention.

Excellent you will be able to say that ESUG pay you to produce code  
for Squeak :)

> I have random segmentation faults trough FFI which I don't have in  
> Squeak. I didn't want to spend many time trying to see what the  
> problem is till 1.0 is releases. At that moment, I will look for the  
> problem. When this is fixed, I will then really start using pharo  
> 100%.

Sure.
Can you report your problem on FFI :)
and add a bug report on pharo

Stef




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

2009/3/1 Stéphane Ducasse <[hidden email]>:
Stephane, i don't know who were tempting your patience, but this is
not really matters.
I don't think that such little noise should be a reason for quitting
from the list.
Smalltalkers are few, and most of them are kind people. I think you
are interesting in things which happening around. And you willingly
losing a source of information  just because someone put blames on
marcus. Come on.. just ignore it.

I was a witness of quitting a Tim Rowledge from squeak community and
from squeak board.. We were discussed one little thing, arguing with
each other.. and then boom.. he says that he fed up and quits.  And
since then i feel a responsibility for starting a discussion which was
led to such outcome.
I think that decision whether quit or not and why, should be based on
more pragmatic matters and should be well weightened, rather than
based on a mere random insult :)


> 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

Stef,

If you need a break from the noise, I would probably encourage you to "take a vacation" from Squeak rather than to "quit."  I still wonder whether I have found everything that was said, which I mention only to excuse myself if I'm missing something important.

My sense is that Matthew is doing the right thing, with the best of intentions, but might be trying it too soon.  Either way, I think the major flaw in Squeak's evolution has been a desire to control others: "you can't do that because I think it's ugly."  Pharo, in large part thanks to the efforts of Pinesoft, is allowing meaningful themes/policies to be applied to the GUI.  Other problems in Squeak (underscores, FFI) can be traced back to obstruction.  Pharo is establishing a spirit of finding the common problem and solving it such that we can all have what we want.

Should Smalltalk contain a GUI?  I think the answer is an emphatic yes.  That GUI should be willing to go away in application (I really like Dolphin's session managers in this context), but it should be there, and should serve its master, which means it must be flexible.  We are well on the way to that goal.

Since I brought them up, hijacking underscores was in fact a way to get single-key assignment; an editor option would have provided the functionality while avoiding the whole mess.  I recently learned (here) that FFI can be easily and reliably controlled via command line options, which would be a better solution than leaving it out and hoping the VM does not see a plugin.  There are no doubt more examples, and the list will grow.

As Gandhi put it, "First they ignore you, then they ridicule you, then they fight you, then you win."  Some of those pressuring you have probably just moved on from ridicule.  Making Pharo the best it can be will be a win for everyone, even if some do not see it that way at the time.

Thanks for doing this!

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Sunday, March 01, 2009 4:29 PM
To: Pharo Development
Subject: [Pharo-project] A point a.k.a excuse to you

Hi guys

I probably should not have forwarded to you the email I replied to  
matthew
but I was thinking that other people can know that I was personally  
touched
by the situation in Squeak.
I'm sorry about.

We got a lot of bird names and others. Recently somebody was implying  
that
marcus was bashing squeak because he sent an email on the pharo  
mailing-list stating that the situation
for keyboard was worse in squeak.
I'm fed up. I'm interested in pharo because I want to create free and  
good energy.
We did a lot in the past and I want to continue. Now I unregistered  
from the squeak mailing-list
and I will not justify anymore why I quit. Now I want pharo to be cool.

Stef

_______________________________________________
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

On Sun, Mar 01, 2009 at 08:47:53PM -0500, Schwab,Wilhelm K wrote:
> My sense is that Matthew is doing the right thing, with the best of intentions, but might be trying it too soon.  

I would appreciate it if you would expand on that.

> Pharo is establishing a spirit of finding the common problem and solving it such that we can all have what we want.

I believe you are correct, but not everybody sees Pharo that
way. Edgar and Keith in particular, sometimes see it as
non-appreciation of their work, which is similar in spirit, but
not as well managed.

Others have more vague objections I don't yet understand.

> As Gandhi put it, "First they ignore you, then they ridicule
> you, then they fight you, then you win."  Some of those
> pressuring you have probably just moved on from ridicule.

Let me apologize on behalf of the squeak-dev community. Not all
of us feel so harshly toward you, but I did not speak up enough to
convince you of our appreciation. You deserve better, and I'm
sorry we did not deliver it.

> Making Pharo the best it can be will be a win for everyone, even if some do not see it that way at the time.

I plan to work with Pharo soon, probably once summer starts and
school is out, to get Keith's tools debugged and working in the
context of Pharo, especially Monticello 1.6 (My patches to MC1.5
to enable real atomic loading (= no more problems upgrading
Polymorph), and Bob (the automated image builder and regression
tester).

I know this is deep stuff, but I believe an automated image
builder will have several advantages, both for you, as Pharo
developers, and for me, as an enthusiast for cross-squeak
compatibility:
- making releases is faster
- Regression bugs are caught faster
- the scripts serve as poor-man's code sharing between squeak
  distributions until we have real package-level sharing of core
  code between core

You may or may not know, but I am a core Cobalt developer, and I
hope to bring Pharo and Cobalt much closer together. These two
projects are hosting many core changes to the image, with little
regard to backward compatibility. We may even get tweak to the
level where it is a compelling replacement for Morphic, and I
want Pharo to benefit from that if it does indeed happen. Too
many improvements to Squeak happen in the dark (Newspeak,
Spoon), and we can ill afford to estrange the truly open
projects from each other (Pharo and Cobalt, IMO).

> Thanks for doing this!

Yes, thank you Stef and Marcus for rekindling the passion for
Smalltalk in many people. With luck, squeak.org may be a free,
open, and useful product again. Too long has it been stuck, with
nobody to bring it forward. Pharo has done much to re-awaken the
love of smalltalk in many people, and that, if nothing else, is
a gift beyond measure. As Squeak.org release team leader, you
have my goodwill and my support. I will do what I can to spread
the gifts of your efforts to the rest of squeak, and bring their
efforts to you.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

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

On Sun, Mar 01, 2009 at 11:12:23PM -0500, Matthew Fulmer wrote:
> I know this is deep stuff, but I believe an automated image
> builder will have several advantages, both for you, as Pharo
> developers, and for me, as an enthusiast for cross-squeak
> compatibility:
> - making releases is faster
> - Regression bugs are caught faster
> - the scripts serve as poor-man's code sharing between squeak
>   distributions until we have real package-level sharing of core
>   code between core

That should have been "sharing of core code between squeak
distributions"

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

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

Matthew,

By the right thing too soon, I think there are influential people who are not yet ready to allow Squeak to change.  I do not necessarily agree that Stef et al. have rekindled interest in Smalltalk so much as they have given many new hope for Squeak to realize its potential to be a clean fast and robust open source Smalltalk.

Bill




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthew Fulmer
Sent: Sunday, March 01, 2009 11:12 PM
To: [hidden email]
Subject: {Spam?} Re: [Pharo-project] A point a.k.a excuse to you

On Sun, Mar 01, 2009 at 08:47:53PM -0500, Schwab,Wilhelm K wrote:
> My sense is that Matthew is doing the right thing, with the best of intentions, but might be trying it too soon.  

I would appreciate it if you would expand on that.

> Pharo is establishing a spirit of finding the common problem and solving it such that we can all have what we want.

I believe you are correct, but not everybody sees Pharo that
way. Edgar and Keith in particular, sometimes see it as
non-appreciation of their work, which is similar in spirit, but
not as well managed.

Others have more vague objections I don't yet understand.

> As Gandhi put it, "First they ignore you, then they ridicule
> you, then they fight you, then you win."  Some of those
> pressuring you have probably just moved on from ridicule.

Let me apologize on behalf of the squeak-dev community. Not all
of us feel so harshly toward you, but I did not speak up enough to
convince you of our appreciation. You deserve better, and I'm
sorry we did not deliver it.

> Making Pharo the best it can be will be a win for everyone, even if some do not see it that way at the time.

I plan to work with Pharo soon, probably once summer starts and
school is out, to get Keith's tools debugged and working in the
context of Pharo, especially Monticello 1.6 (My patches to MC1.5
to enable real atomic loading (= no more problems upgrading
Polymorph), and Bob (the automated image builder and regression
tester).

I know this is deep stuff, but I believe an automated image
builder will have several advantages, both for you, as Pharo
developers, and for me, as an enthusiast for cross-squeak
compatibility:
- making releases is faster
- Regression bugs are caught faster
- the scripts serve as poor-man's code sharing between squeak
  distributions until we have real package-level sharing of core
  code between core

You may or may not know, but I am a core Cobalt developer, and I
hope to bring Pharo and Cobalt much closer together. These two
projects are hosting many core changes to the image, with little
regard to backward compatibility. We may even get tweak to the
level where it is a compelling replacement for Morphic, and I
want Pharo to benefit from that if it does indeed happen. Too
many improvements to Squeak happen in the dark (Newspeak,
Spoon), and we can ill afford to estrange the truly open
projects from each other (Pharo and Cobalt, IMO).

> Thanks for doing this!

Yes, thank you Stef and Marcus for rekindling the passion for
Smalltalk in many people. With luck, squeak.org may be a free,
open, and useful product again. Too long has it been stuck, with
nobody to bring it forward. Pharo has done much to re-awaken the
love of smalltalk in many people, and that, if nothing else, is
a gift beyond measure. As Squeak.org release team leader, you
have my goodwill and my support. I will do what I can to spread
the gifts of your efforts to the rest of squeak, and bring their
efforts to you.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

_______________________________________________
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

I know you are right.
But I will take some holidays :)
I saw that you are bold to discuss with some people.

Yes you are right.
I'm impulsing and the flue does not help me but right now I'm calm.
lot of people did not understand how difficult it was to do squeak3.9
trying to do the best we could and then be bashed by people that did  
not want
to see the situation changes or mere idiots.

Anyway. you are right.

Stef

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

>> Let me apologize on behalf of the squeak-dev community. Not all
> of us feel so harshly toward you, but I did not speak up enough to
> convince you of our appreciation. You deserve better, and I'm
> sorry we did not deliver it.

Don't worry. I did not react because of harsh statements. I reacted
because I could send your email while I should not and this indicating  
me that
I was influenced by my reading on squeak-dev (you see this was meta).
We have been there and we know what it is.

Yes we know.
BTW matthew could you run SmallLint on Installer. I was thinking
to do that and fix what I could. May be we could pair on this one.


> You may or may not know, but I am a core Cobalt developer, and I
> hope to bring Pharo and Cobalt much closer together. These two
> projects are hosting many core changes to the image, with little
> regard to backward compatibility. We may even get tweak to the
> level where it is a compelling replacement for Morphic, and I
> want Pharo to benefit from that if it does indeed happen. Too
> many improvements to Squeak happen in the dark (Newspeak,
> Spoon), and we can ill afford to estrange the truly open
> projects from each other (Pharo and Cobalt, IMO).

Cobalt is the open version of Croquet?
You are working with Julian?
We would be happy to evaluate changes made in Cobalt and retrofit them
into pharo. Now for Tweak this is another story.


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

>
> I believe you are correct, but not everybody sees Pharo that
> way. Edgar and Keith in particular, sometimes see it as
> non-appreciation of their work, which is similar in spirit, but
> not as well managed.
>  
Matthew,

My response to pharo is based upon the ironic situation.

I say for 3.11 "Lets promote a process to enable integration and sharing
of the contributions of the community, accross the diverse range of
images that we use" Pharo team says "Lets go off and do our own thing",
and Edgar says the same. I find this totally ironic and sad, since you
couldn't create more fragmentation of the main squeak protagonists if
you tried.

Now of course the whole point of the tools we have been working on, for
3.11 Bob etc, is to allow diversification, so we should welcome all of
pharos efforts and innovations, and any like it. You seem puzzled as to
why I don't appreciate pharo.

The problem arises when no-sharing is done of the fundamental components
that make the sharing possible. For example SUnit needs to be a common
piece. It has to be there is no option. So if you do a fork and within
your fork you fork your own version of SUnit, you are snubbing the rest
of the community, and any possibility of working with the rest of the
community, either by ignorance or on purpose.

This has to be a managed policy decision, from the top. It is precisely
because the pharo project is not managed and planned with any such
principles in mind, that I stress my point, and will continue to do so.

It took me 25 years to understand that I had been hacking code for 25
years! I did a large test driven project, following some XP principles,
and realised that it is possible to plan, and to release professionally
developed code. I know the difference between hacked up code and a
planned managed process.

To be honest I prefer the hacking approach for first iterations, and
most of my squeak work has been hacked up due to time constraints. Rio,
planned as a replacement for FileDirectory is now two years old! It is
managed by tests, and reached perhaps 70% of the way there just this
weekend, in terms of professionality. The current 170+ tests should be
reviewed, code coverage and feature coverage checked, and the regression
suite needs to be run automated on at least three platforms. I am saying
that it takes a lot of effort to make a new module without hacking, and
that module once defined should be potentially adoptable by all
Smalltalks. (Rio is a bit squeak specific at present).

In reference to recent discussions about Preferences how am I going to
write any common code between pharo and squeak, if the preferences api
is different, between squeak and pharo?  Note that the tools and
preference system can be as different as you like, but the API has to be
common at some level for any sharing to be possible. We either keep the
same api we have, or design a new one, and provide a basic specification
that can be implemented in both environments.

What we cant accept is any proposals or discussion about such an
important API without appreciating that it will be expected to support
code that comes from both environments.

The fact that 'Author' exists only as a global in the Pharo environment
and prevents code which uses it from loading in squeak is all the proof
I need that the pharo process needs a rethink.

cheers

Keith


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

On Mon, Mar 02, 2009 at 11:46:47AM +0000, Keith Hodges wrote:
Well, for one thing, our tools were not ready for mainstream use
when Pharo/Sapphire was announced. From what I can tell, the
tools are just now coming to that point. We cannot expect that
everybody will stop what they are doing just to alpha-test our
tools. If they do, great, but if not, don't be mellow over it.

> Now of course the whole point of the tools we have been working on, for
> 3.11 Bob etc, is to allow diversification, so we should welcome all of
> pharos efforts and innovations, and any like it. You seem puzzled as to
> why I don't appreciate pharo.

Do you appreciate Pharo?

> The problem arises when no-sharing is done of the fundamental components
> that make the sharing possible. For example SUnit needs to be a common
> piece. It has to be there is no option. So if you do a fork and within
> your fork you fork your own version of SUnit, you are snubbing the rest
> of the community, and any possibility of working with the rest of the
> community, either by ignorance or on purpose.

Not everything needs to be "for the community". If we insist
that it be so, we lose developers due to restrictive policy. It
is more important that those who are good at fixing code (Pharo)
do so, and leave the "giving it back to the community" to those
who really care about it, like you and me. Pharo is providing a
valuable service as a test-bed for new ideas and things that are
not backward compatible. We will be providing a service to bring
more commonality to the community. Both are important, and
neither should halt on behalf of the other.

> This has to be a managed policy decision, from the top. It is precisely
> because the pharo project is not managed and planned with any such
> principles in mind, that I stress my point, and will continue to do so.

The lack of such concern is a good thing.

> In reference to recent discussions about Preferences how am I going to
> write any common code between pharo and squeak, if the preferences api
> is different, between squeak and pharo?  Note that the tools and
> preference system can be as different as you like, but the API has to be
> common at some level for any sharing to be possible. We either keep the
> same api we have, or design a new one, and provide a basic specification
> that can be implemented in both environments.

Or, put both in for a release or two, where the old is
deprecated, then remove the old after a release or two.

> What we cant accept is any proposals or discussion about such an
> important API without appreciating that it will be expected to support
> code that comes from both environments.

Such a restrictive policy is the best way to ensure that nothing
will ever change, and that somebody will fork to get away from
such management overhead.

> The fact that 'Author' exists only as a global in the Pharo environment
> and prevents code which uses it from loading in squeak is all the proof
> I need that the pharo process needs a rethink.

It can be backported, or ported in full, if it is a win. Traits
are a win, and we backported them to 3.8 for Monticello 1.5. I
don't see why we can't do that again.

We can provide the service of backporting good ideas to other
distributions. It will be easier when Pharo adopts Bob to some
degree, but nothing prevents us from doing it now.

There is a reason that Linux distributions are made of packages
that are not maintained by the original coders, and that is
because distribution of packages takes time. If somebody is
better at coding, they should code. If somebody is better at
packaging, they should package. Specialization is a good thing;
everybody is more productive in the end, and has more fun,
because each one is adding value while doing what they love.

Always have fun. If you have fun on Pharo, than do Pharo. If you
have fun on tools, then do tools. There are enough people in the
world that somebody will have fun working with both, and will
bridge whatever gap has formed. I believe I am such a person.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

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

Keith, your email implies that you believe Pharo should be backwards
compatible at some level with Squeak.  Part of the Pharo manifesto is
not to be compatible.  So if you want to write code or have apis that
work in a backwards direction from Pharo to Squeak, that's great.  I
don't believe it's a goal for Pharo though.  The pharo process doesn't
need a rethink at all as far as I'm concerned.

thanks,

Mike

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

Michael Roberts wrote: No that is not what I am saying at all. Perhaps examples would help.

Take Rio. Rio was designed from ground up to be a replacement for a the
present non-modular kernel facility FileDirectory. It is a discrete
loadable module.

Wild and horrible uses of FileDirectory are spread around the image in
lots of places, so one thing that Rio tries to do is to anticipate use
cases, so that the users of Rio dont have to implement File handling
code in their stuff, and so we help to keep the module boundary clear.
For example you can ask Rio to get you the next version of a file -
'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in
itself potentially lightens SmalltalkImage.  If you want to read Xml
files, you can subclass File, with FileXML, define the #validExtensions
that it handles, and implement contents/contents: This means that your
code only needs to send, 'myfile.xml' asFile contents, to get the model.
There are all sorts of things like that.

With Rio as a front end to File and Socket streams it is perfectly
possible to innovate on them without users of Rio being any the wiser.
If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it was
Squeak streams Nile or Flow behind the scenes. 'http://www.google.com'
asFile contents, now means that I dont have to care about whether
HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or
HTTPClient returning a MultiByteStream thingy in 3.8 or some other new
facility.

So, Rio demonstrates that it is possible to innovate, on a kernel
module, and you dont need to break anything to do it. Secondly by
thinking about APIs and module interface abstractions in this way, you
can define specific interfaces and bottlenecks, that potentially turn
the ball of tangled string into something designed and architected.
There are perhaps hundreds of other modules that could use the same
treatment.

Rio loads into all squeak images I have tried it in, so this then means
that any of my file handling code will work in all images. This benefit
comes from managing Rio as module external to the main image. Rio also
comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller images in
mind.

Having done this, the question of moving the kernel over to make use of
the new code arises, this also can be achieved without breaking anything
for users that have had Rio available for 2 years in every image that
their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar,
Magma, Etoys, can all migrate their file handling code to the new Rio
API now, even if they are using Squeak 3.7/3.8, without having to
upgrade to the latest squeak. When they do update, they will be pleased
to find that their file handling code works, as well as their
gzipping/archiving/remote file handling/and website accessing code.

Installer follows the same principles, abstracting an api, freeing the
backend to be either old code or new code. If you dont have Universes
loaded, then defining Installer>>#universes to call #sake as a fall back
would use Sake/Packages and get identical results, your users would be
none the wiser. If you dont have SqueakMap loaded, then defining
Installer>>#squeakmap to call #websqueakmap instead, would again give
your users identical results. and you thought that Installer was just
for loading things. Edgar has pointed out that you could use CodeLoader
for that, but thats not the point of installer, Installer is providing a
DSL for loading things that provides an architectural layer of
isolation, and thus both inherrent forward and backward compatibility. I
expect my image building scripts to work identically with Monticello2 in
squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7.

Scripter (who here even knows that Scripter exists?) does the same, if
you want to write code to close or tile all the windows, after the
installing process has left a mess. Scripter can be the interface to
whatever backend GUI there happens to be whether it is
ToolBuilder/Tweak/Morphic.

Same again with Logging, is a front end abstraction to all of the three+
logging backends out there. I can remove the hardwired calls to
Transcript that scatter the image and replace them with a single api to
multiple backends, both past (Transcript) present (Syslog) and future
(seaside per-user session logging framework).

Oh, and again with Sake/Packages.... why does Sake/Packages define class
tasks? You can write a task that depends upon a task which removes
certain method selectors. You could just call Behaviour direct. Its
another  architectural layer, that frees up the back end to be old or
new code as far as Sake task writers are concerned. I can write a task
that says, "if you find this Class with a method categorised as so, then
it needs to be recategorised as such", in such a way as this task would
run in all images.

Oh and again SystemEditor... another layer of abstraction for compiling
and loading code atomically.

So if you think about it, those who know about the compiler could be
considering how to write their stuff, so that it logs to the Kernel
Logging API (which is valid even if Logging isnt Loaded). They might
consider connecting to SystemEditor in preference to providing a direct
api, and another abstracted pluggable Module is needed to handle source
code files (replacing RemoteString/ChangeSets etc), with Rio as the
local/remote file API.

Do you get the idea now?

For the same treatment to be available for more significant chunks of
squeak, we would need atomic loading to work. Now the code to provide
atomic loading for everyone has been available for over a year, and it
works if you dont use traits. So where is the expertise to really get it
working for everyone with traits?

The only difficulty with this approach is that you might need slightly
different bits to make your NEW code load into older images. This
problem is reasonably easily addressed with Installer-Scripts
(LevelPlayingField+) and Sake/Packages.

I fully agree with Matthew about core packages like Collections. BUT and
this is the big but. If you are going to do that kind of thing, you need
to think about it, plan it, and create and participate in a process that
supports everyone is diverse images using and testing that package. From
what I have seen there is only one person on the Pharo team that
understands what LevelPlayingField is for, and how to use it.

The biggest risk to this approach is if some other folks decide to fork
some significant architectural component in a completely incompatible
manner, without thinking about any bigger picture at all.

Matthew's comment about how our tools are only just getting there isnt
that relevant to the point that I am making. I didnt need a test and
build server to innovate Rio for everyone rather than just for the image
I am using (trouble was I was using 3 different images), all I needed
was an inclusive attitude rather than an exclusive attitude.

cheers

Keith










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

> build server to innovate Rio for everyone rather than just for the image
> I am using (trouble was I was using 3 different images), all I needed
> was an inclusive attitude rather than an exclusive attitude.
>  
Dear All,

I was trying to implement FileHttpExecutive in Rio today, I wanted to
perform a GET, and have Rio informed of the File size as soon as the
headers have been downloaded. As an alternative it would also be nice to
be able to send a HEAD request prior to getting the whole file. I also
want to read the stream as it is coming in, since Rio already can buffer
ftp reads direct to a file, or other destination.

About 5 minutes looking at the code showed me that this was pretty
impossible. There was no clean way to subclass HTTPSocket and have it
hold a handle on my file instance and report that information to me,
since most of the business is performed on the class side (why do people
do that?) My only option is probably to subclass HTTPSocket, inserting
some Notifications in there, and use exception handlers to collect the data.

So... would anyone out there be willing to rewrite HTTPSocket/Client
from scratch so that it is well designed and so on from the ground up?
Assuming that Socket will remain common between Squeak/Pharo etc, it
could also provide an abstraction onto the Curl plugin as well. This new
module would of course be for the benefit of all.

Has anyone done/is anyone doing this already?

thanks in advance

Keith


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

I suggest making the socket as pluggable as possible, because I suspect we will see SSL sooner rather than later.  Call it a hunch.  Another thing that I would like to see is #readStream and #writeStream to lazily initialize appropriate streams on sockets.  Dolphin has had that for a long time, and it works very nicely.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Keith Hodges
Sent: Monday, March 02, 2009 9:17 PM
To: [hidden email]; The general-purpose Squeak developers list
Subject: Re: [Pharo-project] A point a.k.a excuse to you


> build server to innovate Rio for everyone rather than just for the image
> I am using (trouble was I was using 3 different images), all I needed
> was an inclusive attitude rather than an exclusive attitude.
>  
Dear All,

I was trying to implement FileHttpExecutive in Rio today, I wanted to
perform a GET, and have Rio informed of the File size as soon as the
headers have been downloaded. As an alternative it would also be nice to
be able to send a HEAD request prior to getting the whole file. I also
want to read the stream as it is coming in, since Rio already can buffer
ftp reads direct to a file, or other destination.

About 5 minutes looking at the code showed me that this was pretty
impossible. There was no clean way to subclass HTTPSocket and have it
hold a handle on my file instance and report that information to me,
since most of the business is performed on the class side (why do people
do that?) My only option is probably to subclass HTTPSocket, inserting
some Notifications in there, and use exception handlers to collect the data.

So... would anyone out there be willing to rewrite HTTPSocket/Client
from scratch so that it is well designed and so on from the ground up?
Assuming that Socket will remain common between Squeak/Pharo etc, it
could also provide an abstraction onto the Curl plugin as well. This new
module would of course be for the benefit of all.

Has anyone done/is anyone doing this already?

thanks in advance

Keith


_______________________________________________
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