[Pharo-project] Workspace API
http://bugs.squeak.org/view.php?id=5669 I requested then implemented a reasonable API for opening Workspaces on strings and files. I now find that pharo has implemented incompatible versions of the same. Workspace openContents: 'blah'. or Workspace new contents: 'blah'; label: 'Title'; open. Keith
What do you suggest? On Tue, Feb 10, 2009 at 3:49 PM, Keith Hodges <keith_hodges@yahoo.co.uk> wrote:
http://bugs.squeak.org/view.php?id=5669
I requested then implemented a reasonable API for opening Workspaces on strings and files. I now find that pharo has implemented incompatible versions of the same.
Workspace openContents: 'blah'.
or
Workspace new contents: 'blah'; label: 'Title'; open.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Damien Cassou http://damiencassou.seasidehosting.st
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:
http://bugs.squeak.org/view.php?id=5669
I requested then implemented a reasonable API for opening Workspaces on strings and files. I now find that pharo has implemented incompatible versions of the same.
Workspace openContents: 'blah'.
or
Workspace new contents: 'blah'; label: 'Title'; open.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
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
On Feb 11, 2009, at 7:34 PM, Keith Hodges wrote:
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.
no idea.
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.
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
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.
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
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
On Feb 12, 2009, at 1:47 PM, Keith Hodges wrote:
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.
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.
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.
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 :)
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?
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
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
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).
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
On Feb 12, 2009, at 1:47 PM, Keith Hodges wrote:
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.
no this is not the reason. Really few people were fixing it and paying attention to making sure we could remove the cruft.
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
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.
time time time have you seen that adrian is working on trait sharing and that we are waiting for that since a couple of months or more. Stef
No idea
time time time have you seen that adrian is working on trait sharing and that we are waiting for that since a couple of months or more.
Stef
Will it load into 3.10?
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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:
http://bugs.squeak.org/view.php?id=5669
I requested then implemented a reasonable API for opening Workspaces on strings and files. I now find that pharo has implemented incompatible versions of the same.
Workspace openContents: 'blah'.
or
Workspace new contents: 'blah'; label: 'Title'; open.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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:
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:
http://bugs.squeak.org/view.php?id=5669
I requested then implemented a reasonable API for opening Workspaces on strings and files. I now find that pharo has implemented incompatible versions of the same.
Workspace openContents: 'blah'.
or
Workspace new contents: 'blah'; label: 'Title'; open.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I average about once a year (saving contents to a file). However, I regularly open a workspace on strings.
Around the same... usually when I rebuild my image. Loading from file happens more often (preference and appearance settings mostly). Regards, Gary ----- Original Message ----- From: Chris Cunningham To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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
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:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
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
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
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:
Stéphane Ducasse wrote:
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
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 Pharo-project@lists.gforge.inria.fr 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:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
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
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.
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
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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Alexandre Bergel -
Chris Cunningham -
Damien Cassou -
Gary Chambers -
Keith Hodges -
Stéphane Ducasse