Re: Workspace API

What do you suggest?

On Tue, Feb 10, 2009 at 3:49 PM, Keith Hodges <[hidden email]> wrote:


--
Damien Cassou
http://damiencassou.seasidehosting.st

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

Where? When?
Keith
in the long run it would be nice that yu do not bash us systematically.
Yes we have a different way of working but normally this is often by  
pure lack of time or information
that we do not check what exist.

Stef

On Feb 10, 2009, at 3:49 PM, Keith Hodges wrote:


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

Then I'm not in favor to load files in workspace or saving contents to  
file.
Workspace snippets are against classes. If you have a nice and fast  
snippets then you put it in a class
and work a bit and you get an little object. And you can even version it

Stef


On Feb 10, 2009, at 3:49 PM, Keith Hodges wrote:


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

I was wondering, how many people saved their workspace content in a  
file?

Cheers,
Alexandre


On 11 Feb 2009, at 08:45, Stéphane Ducasse wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
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

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Wednesday, February 11, 2009 4:41 PM

Subject: Re: [Pharo-project] Workspace API

I average about once a year (saving  contents to a file).

 

However, I regularly open a workspace on strings.

---

_______________________________________________
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

Alexandre Bergel wrote:
> I was wondering, how many people saved their workspace content in a  
> file?
>
> Cheers,
> Alexandre
>  
MC1.5 supports files so if you want to manage scripts and readmes having
a workspace that knows its file, is a good idea.

Also Bob wants a way to (optionally) show you the script that it used to
build the image.

http://bugs.squeak.org/view.php?id=5669

Keith


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

Stéphane Ducasse wrote:
> Where? When?
> Keith
> in the long run it would be nice that yu do not bash us systematically.
> Yes we have a different way of working but normally this is often by  
> pure lack of time or information
> that we do not check what exist.
>
> Stef
>  
I was concerned to find code in Pier that did not seem to be compatible
with squeak, while I thought that the Workspace issue had come up before.

Your different way of working..... as I see it:

You want more tests, you develop more tests, you add more tests to the
image. Are those tests useful to the rest of the squeak community? No.
Should they be? YES.

If there was a way of marking those tests that are pharo only tests, as
such, and also marking those tests that should work in squeak. Then the
squeak/pharo communities could use one testing package for all squeak
images, and pharo.

So to enable this to happen you need to think about testing in a broader
sense and you need improved tools to handle it, and you need to develop
or assess those tools FIRST.

hmm, so August 2006, I thought this through, that to support diversity
in the squeak community we needed something like that, and
SUnit-improved was the result. That was its purpose, to support forks of
squeak, I believe in forking squeak....

All the tools I have worked on for 2 years are to enable working with
diverse images, and to facilitate packages to work in different images.
Thus reducing the dependency upon a specific kernel-image and thus
releasing the kernel-image to be improved.

What I don't believe in was the pharo approach of going your own way
WITHOUT considering anyone else, to the extent that you ignore all of
the extensive work that has been carried out to provide tools that would
enable you to participate. The main goal of the 3.11 effort hasn't been
a particular image, but a tool set, and a process, that would enable
folks to work on diverse projects, while considering each other.

And you are ignoring those tools, because you dont see them as
important. I cant work out why you dont see them as important is because
you have sucessfully harnessed a lot of enthusiasm for improving squeak.
YET you dont have a process for using that enthusiam effectively. You
still have the same old bottlenecked controlled process where there is
no actual plan (you do what you feel like when you get up in the
morning), and two people get to hack at the image day and night and
everyone else is contributing to a moving target.

regards

Keith



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

About MC1.5 here is what I received as a private email.
So I imagine that the person is a bit too negative too but you can  
understand that we pay attention and need time
to ***really*** look at it.

        I hope you don't include Monticello 1.5 in Pharo. All code that we
        have seen so far from Keith cases trouble. I have nothing to support
        this except the people reporting problems with Monticello 1.5.

Stef


On Feb 11, 2009, at 6:55 PM, Keith Hodges wrote:


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

On Feb 11, 2009, at 7:34 PM, Keith Hodges wrote:


no idea.

may be

> So to enable this to happen you need to think about testing in a  
> broader
> sense and you need improved tools to handle it, and you need to  
> develop
> or assess those tools FIRST.

Yes.

> hmm, so August 2006, I thought this through, that to support diversity
> in the squeak community we needed something like that, and
> SUnit-improved was the result. That was its purpose, to support  
> forks of
> squeak, I believe in forking squeak....

I know I should have a look at SUnit-Improved but my time is limited

Our goal is to make progress. Squeak is dying don't see it?


> And you are ignoring those tools, because you dont see them as
> important.

No.
The problem is the noise ratio with them (nul pattern, bad formatting,  
extensive extensions....)

> I cant work out why you dont see them as important is because
> you have sucessfully harnessed a lot of enthusiasm for improving  
> squeak.
> YET you dont have a process for using that enthusiam effectively. You
> still have the same old bottlenecked controlled process where there is
> no actual plan (you do what you feel like when you get up in the
> morning), and two people get to hack at the image day and night and
> everyone else is contributing to a moving target.


I would love to have a buildServer and also run automatically  
SmallLint rules on the code
now either pharo does not exist because we build those tools or pharo  
exist.
So we are going slowly on both side. I was hoping to get such  
buildserver and this is why
we started to write on Installer (and you know that this is not only  
for pharo so you should be happy).

Now you should ask yourself the question why people are not all using  
your tool extensions.
Conservatism? stupidity? lack of time? lack of trust? Dont'care?

Stef






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

Stéphane Ducasse wrote: Well thats incredibly stupid.

I have NO KNOWLEDGE of these so called problems. What are they were are
they?

If the anonymous detracter will tell me what those problems are we can
fix them. We aim to be very responsive.

Keith

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

Stéphane Ducasse wrote: You still dont get it do you. *** really look at it *** means pick over
the carcass. Adopting it means JOINING IN AND MAKING EVERYTHING BETTER
FOR EVERY ONE.

You guys have the expertise to fix things I dont, and test things that I
dont. I dont have the skill  to meet your high coding standards. I am
working on comercial projects and I need something that WORKS not
something that looks pretty. I used a code formatter for 6 years, so
when I see code I dont see that it needs formatting. It looks ok to me.

If you adopt it, then your whole team of testers and experts get to
contribute, and everyone benefits.

The reason I am causing trouble, and raising my voice is not that you
wont use my stuff, its that you will not participate in any
collaborative attitude AT ALL. Monticello IS NOT YOUR PROJECT, it is
EVERYONES. It is the PEOPLES MONTICELLO.  Your approach is killing that
vision, and taking NEEDED (according to you private emailer) expertise
away from that vision.


Keith


p.s. It doesnt matter if the code is crap, un-formatted crap. It cant
possibly be worse than MC1.0 and the amount of cruft I refactored.

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

I know. I just want to tell you that nothing is easy.
Now saying that we do not pay attention is not exact.
But really beside integrating fixes and cleaning etoy I have no time.

Stef

On Feb 12, 2009, at 11:22 AM, Keith Hodges wrote:


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

>> You still dont get it do you. *** really look at it *** means pick  
>> over
> the carcass. Adopting it means JOINING IN AND MAKING EVERYTHING BETTER
> FOR EVERY ONE.

I know.

>
>
> You guys have the expertise to fix things I dont,

I'm not sure :)

> and test things that I
> dont. I dont have the skill  to meet your high coding standards. I am
> working on comercial projects and I need something that WORKS not
> something that looks pretty. I used a code formatter for 6 years, so
> when I see code I dont see that it needs formatting. It looks ok to  
> me.

Ok

I do not think so but I understand what you are saying.
Now this is not that easy.

> p.s. It doesnt matter if the code is crap, un-formatted crap. It cant
> possibly be worse than MC1.0 and the amount of cruft I refactored.

Probably. I'm not against, I just do not have enough cycles and I  
imagine that this
is the same for other people.
Looking/integrating part of Kernel extensions
SUnit +
MC1.5
is still on my stack but my stack is long.

>
>
> _______________________________________________
> 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

> Our goal is to make progress. Squeak is dying don't see it?
>  
The reason it is dying is because once anyone starts a significant
project they are stuck with the same image that they started with. Thus
everyone gets left along the path of progress. They keep up or get left
behind to fork their own little world. Pharo perpetuates and exacerbates
this problem through its philosophy.

You could have picked a slice of squeak, instituted a project to improve
it, and then contributed that improved slice back to everyone, and so on.

The kernel image itself is not that important to getting actual work
done, once you eliminate certain headaches like FileDirectory (Rio was
my choice of the section of the kernel to improve). Sure, if you are
doing academic little projects, you might be constantly irked by the
lack of change in the kernel. If you are working on a big project with
clients breathing down your neck, you just get on with it.

The <i>cause</i> (since captials are deemed to be rude, sorry Paul) of
squeak dying is that those who move it forward are too busy making
progress and they <i>dont</i> think about the users of older images.

How many of our potential millions of future xo users will be taking
their future xo software apart to find Pharo inside?
>> And you are ignoring those tools, because you dont see them as
>> important.
>>    
> I would love to have a buildServer and also run automatically  
> SmallLint rules on the code
> now either pharo does not exist because we build those tools or pharo  
> exist.
So please .... explain this to me.... why cant.

Project A working on the kernel and not the tools, fit together with
project B, working on the tools and not the kernel?  Looks simple on
paper doesn't it. Think it over, A+B = AB, and B + A = BA, hmm it works,
infact its kind of obvious.

Now why is it that this doesn't work I wonder? Please explain this to me?

Correct me if I am wrong, but I think it is because Project A is working
on the kernel, and is for some reason forking the loadable tools (which
should be outside of their remit) thus absorbing all of the expertise,
making things more difficult for everyone.

Project B then gives up and goes off to do something else, because they
realise that 3 years of efforts trying to open up repositories and to
encourage people to contribute collaboratively to tools as shared
resources over the whole community of projects, is a total and utter
waste of time.

All the repo's on Project B are public, and anyone can contribute,
however the majority of Project A contributors don't join in.
> buildserver and this is why
>  
I have been working on the Build server since Feb 2007.  That was where
the idea for Rio originally came from. The ruby version of Bob did work
but it was tricky to set up. The smalltalk one only needs one day of
work to complete, and I said that 3 months ago.

However since no-one from your team seems willing to <i>join</i> on
fixing up MC1.5 etc I was left to spend yesterday fixing an MC1.5 bug.
Perhaps there is no point in doing that one day of work on Bob because
no-one will bother looking at it anyway.
> we started to write on Installer (and you know that this is not only  
> for pharo so you should be happy).
>  
You did?
> Now you should ask yourself the question why people are not all using  
> your tool extensions.
>  
Actually they are. If they were not I wouldn't be here now.
> Conservatism? stupidity? lack of time? lack of trust? Dont'care?
>  
None of the above. Many people load LPF and get on with the job they
have to do.

Keith


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

Stéphane Ducasse wrote:
> I know. I just want to tell you that nothing is easy.
> Now saying that we do not pay attention is not exact.
> But really beside integrating fixes and cleaning etoy I have no time.
>
> Stef
>
>  
I thought that MinimalMorphic was released 2 years ago?

Keith


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

Come on this is not the same....

On Feb 12, 2009, at 1:49 PM, Keith Hodges wrote:


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

>>>
>>>
>>>      
>> I thought that MinimalMorphic was released 2 years ago?
>>
>>    
ok I was mistaken, I meant the etoys removal script

Keith

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

On Feb 12, 2009, at 1:47 PM, Keith Hodges wrote:

no this is not the reason.
Really few people were fixing it and paying attention to making sure  
we could remove
the cruft.

> You could have picked a slice of squeak, instituted a project to  
> improve
> it, and then contributed that improved slice back to everyone, and  
> so on.

No this was not possible. People shouted (may be this was before you  
joined the community)
and were against removal.
no. :) see above.

> How many of our potential millions of future xo users will be taking
> their future xo software apart to find Pharo inside?

No idea but if a smart kid looks at squeak, he will find pharo :)

spaghetti code, hidden dependencies, responsibilities
code ownership, lack of will of one maintainer to integrate changes
We got such a problem with Graphics in the past.
We were called random refactorers by andreas.

>
>
> Correct me if I am wrong, but I think it is because Project A is  
> working
> on the kernel, and is for some reason forking the loadable tools  
> (which
> should be outside of their remit) thus absorbing all of the expertise,
> making things more difficult for everyone.


> Project B then gives up and goes off to do something else, because  
> they
> realise that 3 years of efforts trying to open up repositories and to
> encourage people to contribute collaboratively to tools as shared
> resources over the whole community of projects, is a total and utter
> waste of time.

yes this is why **I**
        loaded SUnitextension
                KernelExtension
                Installer
                Rio

this is not my team.

> seems willing to <i>join</i> on
> fixing up MC1.5 etc I was left to spend yesterday fixing an MC1.5 bug.
> Perhaps there is no point in doing that one day of work on Bob because
> no-one will bother looking at it anyway.

I do not know. Talk to them. Make a simple call in this list


>> we started to write on Installer (and you know that this is not only
>> for pharo so you should be happy).
>>
> You did?

yes this is in PharoByExample (aka Squeak by Example (volume two).

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

Stéphane Ducasse wrote: But the reason that few people were fixing it was....

Andreas forked off Croquet in 3.8
Goran had forked off Gjallar in 3.8
Lots of others forked off Sophie in 3.8
Another group forked off to etoys on the XO,
Not to mention Cobalt, SecrureSqueak, etc etc etc.

Who is left with the expertise to improve the kernel?
Edgar, Myself and Matthew? None of whom are experts.

We stopped fixing the kernel in order to try and facilitate some harmony
through some tools support. One result was LPF, another MC1.6, and of
course the invisible man, Bob.

Now you have all the experts, why doesnt someone who knows about traits
help Matthew to fix SystemEditor to work with traits, then we would all
have atomic loading, and a 3x performance improvement in MC.

regards

Keith


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