Hi folks!
Ok, so Maya is playing with a friend which means that I got some time "on my own" in the sofa with my laptop :) Thus I have done the following: 1. Added code to serialize/deserialize map using SmartRefStream. It seems to be just as fast and small as an ImageSegment, almost even faster! As a quick fix this seems the way to go. Any thoughts on that is welcome. 2. Fixed several bugs in the SqueakMap code in trunk - it has evidently rotted away! Downloading was broken by a refactoring done in january but it was also broken due to changes in the HTTP code etc. Trival things to fix though. So now I have a working SqueakMap package loader in the rc2 image using current unix VM. This relies on map files that are SmartRefStreams instead called ".rgz" instead of ".sgz". In order to be "all happy" we need to changet the code on the server running at map.squeak.org so that it produces and hands out SmartRefStream maps instead. With a bit of luck I think we can make this switch for ALL images out there using SqueakMap - SqueakMap has a version protocol so outdated clients can react and autoupdate themselves. I will try this late tonight. The executive summary: We should be able to have a working SqueakMap in a few days. regards, Göran |
Hi all!
Göran Krampe wrote: > The executive summary: We should be able to have a working SqueakMap in > a few days. And I should take this chance to cleanse the codebase quite a bit too - ripping out old crap. The SM codebase is not ALL bad, it is actually quite fine in many areas - but some bits should be removed, because they were never followed through. regards, Göran |
In reply to this post by Göran Krampe
On Wed, Apr 07, 2010 at 02:38:03PM +0200, G?ran Krampe wrote:
> > The executive summary: We should be able to have a working SqueakMap in > a few days. G?ran, Thank you for doing this!!! Dave |
In reply to this post by Göran Krampe
<rant> Why on earth are you fixing SqueakMap? How is this at all a good or useful thing? If I understand correctly, you want to make the Squeak Map Package Loader work.
Is there some kind of if-it's-broken-I-must-fix-it pathology going on here? If I were the king of Squeak I'd take hunt down both the Squeak Map Package Loader and the Universes Browser, get down with my bad Canadian self, and beat them to death like baby seals.
Three ways to find code for Squeak. Only one is updated with regularity and you're fixing a tool to feed the problem. Is there something I don't get here or is that what you're doing: making the location of code more of a problem for beginners coming to Squeak? Ensuring they find a seemingly working solution only to find that nobody updates the RFB on SqueakMap.
There should only be one way to get code for Squeak. One. All other should be chased across the ice and turned into coats. </rant> Chris
|
2010/4/7 Chris Cunnington <[hidden email]>:
> > Three ways to find code for Squeak. Only one is updated with regularity and > you're fixing a tool to feed the problem. I was glad to read about what Göran did. I like when there is buzz around the community and a lot of activity. It's an healthy sign. However, you've got a strong point here and it expresses the lack of focus as a community. I believe there have been some improvements in this area since 2009 but it's good that we are all reminded once in a while. > Is there something I don't get here or is that what you're doing: making the > location of code more of a problem for beginners coming to Squeak? Ensuring > they find a seemingly working solution only to find that nobody updates the > RFB on SqueakMap. This is the Great Squeak Paradox: it is entirely beginners unfriendly. :) Ian. -- http://mecenia.blogspot.com/ |
In reply to this post by Chris Cunnington
On Wed, Apr 07, 2010 at 09:38:08PM -0400, Chris Cunnington wrote:
> > Why on earth are you fixing SqueakMap? Because SqueakMap maintains a catalogue of packages that have been developed over the last ten years or so, many of which are not readily accessible through any other mechanism. SqueakMap is the original package catalogue for Squeak. It was and still is a useful resource. Goran had the vision to see that SqueakMap was needed, and took the initiative to create it before any other such tools existed. > How is this at all a good or useful thing? It is useful because if you cannot find something or load it, then it may as well not exist. It is also useful because new Squeakers who explore the contents of SqueakMap will find interesting artifacts to pique their interest, whereas new Squeakers to encounter a broken SqueakMap will find only frustration and confusion. > Is there some kind of if-it's-broken-I-must-fix-it pathology going on here? I certainly hope so. Dave |
In reply to this post by Göran Krampe
David T. Lewis said: "Because SqueakMap maintains a catalogue of packages that have been developed over the last ten years or so, many of which are not readily accessible through any other mechanism." I don't think that there are many packages that are of use to anybody on SqueakMap. If there is anything useful, it's found on squeaksource.com. If they haven't been moved to squeaksource.com, they've been abandoned. "It is also useful because new Squeakers who explore the contents of SqueakMap will find interesting artifacts to pique their interest, whereas new Squeakers to encounter a broken SqueakMap will find only frustration and confusion." Beginners suffer most often from too much noise and not enough signal. And that's what perpetuating this tool does. Their interest will not be piqued, but there confusion will be. We will have made things unclear by providing too many options. Beginners need not be confused by a broken Squeak Map: it should be removed. I know that's not going to happen. I know there's no will in the community to do this. It doesn't make it any less wrong. And with all due respect, David, I know a lot more about beginner-hood in dealing with Squeak than you do. You're an expert. You're pretty far removed from this problem. I can't believe I'm saying this, but Pharo is right on this point. SqueakMap must be destroyed. Chris |
In reply to this post by David T. Lewis
Le 08/04/2010 04:29, David T. Lewis a écrit :
> On Wed, Apr 07, 2010 at 09:38:08PM -0400, Chris Cunnington wrote: >> >> Why on earth are you fixing SqueakMap? > > Because SqueakMap maintains a catalogue of packages that have been > developed over the last ten years or so, many of which are not readily > accessible through any other mechanism. exactly. plus, SqueakMap has a functional web front-end that make it easy to look for existing packages, see what's there and what it does. in my experience SqueakSource is very opaque and next to impossible to navigate: you only have a huge projects list strangely sorted taking 99 pages, and a list of tags somewhat more useful but still very clumsy to browse. so, long live SqueakMap, and if it has to be deprecated, let it be deprecated by something better, not just something else. (my rant now: again an occurrence of this silly "my stuff is better than yours, yours should die" shit... when will people learn to respect other's ways ?) Stef |
In reply to this post by Chris Cunnington
> If they haven't been moved tosqueaksource.com <http://squeaksource.com>, they've been abandoned.
all my stuff is on SqueakMap, none of it is abandoned: http://map.squeak.org/accountbyid/5f9bef44-1fbb-4dd6-8f10-a69862ad5674 how can you be so confident you're right when you're so obviously wrong ? Stef |
In reply to this post by Chris Cunnington
> Beginners suffer most often from too much noise and not enough signal. Beginners have to understand that the Squeak way is a way of variety; it is messy, it is full of strange things, some old, some broken, it's colorfoul and lively. So by trying to help beginners by showing them something ordered and clean you actually deserve them, because you cultivate unfounded expectations. Also, lots of different people with different views of Squeak are there. By stating what you know better how things should be, you seem to imply there is one clear way to go that everybody agrees on, and so here again you deserve beginners if you make them believe that. Thank you for your interest in beginners, but I don't think they need a Savior. Stef |
2010/4/8 Stéphane Rollandin <[hidden email]>:
> >> Beginners suffer most often from too much noise and not enough signal. > > Beginners have to understand that the Squeak way is a way of variety; it is > messy, it is full of strange things, some old, some broken, it's colorfoul > and lively. > > So by trying to help beginners by showing them something ordered and clean > you actually deserve them, because you cultivate unfounded expectations. > > Also, lots of different people with different views of Squeak are there. By > stating what you know better how things should be, you seem to imply there > is one clear way to go that everybody agrees on, and so here again you > deserve beginners if you make them believe that. > > Thank you for your interest in beginners, but I don't think they need a > Savior. > google projects, github) etc, is plagued by a very same thing: they are full of half-done, broken and non-working stuff. But this not twarts users from using them, so why it should twart us from squeakmap? I think that any attempt to put an order in this mess is doomed to fail, because there's no anybody (and its physically impossible) to keep an eye on every submission and mark it outdated or do some quality check. It is up to users to concern about quality of projects which they publishing, not squeakmap itself. Btw, i never used squeakmap to publish my stuff. But i don't see why it should be forfeit and closed. Because, in same sense, one might say: hey, i'm using google code, so lets close sourceforge.. > > Stef > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Chris Cunnington
Hi!
First I would like to say that I am not sure how to respond to this post, given your tone! I will try to just make my remarks as "factual" as possible. Chris Cunnington wrote: > <rant> > > Why on earth are you fixing SqueakMap? How is this at all a good or > useful thing? > > If I understand correctly, you want to make the Squeak Map Package > Loader work. > Is there some kind of if-it's-broken-I-must-fix-it pathology going on here? If the SqueakMap Package Loader is still in the 4.0/4.1 image - then surely having it *work* is better than having it *not work*, right? Deciding if the SqueakMap Package Loader should be *removed* from the image is another thing - and that is not up to me. I just want to help maintain it, since I wrote it. > If I were the king of Squeak I'd take hunt down both the Squeak Map > Package Loader and the Universes Browser, get down with my bad Canadian > self, and beat them to death like baby seals. > > Three ways to find code for Squeak. No, not really. Universes and SqueakMap are indeed direct "competitors" and I did argue hard for merging them when Lex wrote Universes - but he was not interested in that. Now Lex is not AFAIK active anymore so perhaps that path could easily be taken by the rest of us. When Squeaksource was born I also noted that it overlaps with SqueakMap. BUT it is NOT the same thing. Squeaksource is ONE (of many actually) repository hubs that actually hosts code - and in only one format, MC. SqueakMap is a catalog - and not a hub. It is also a singularity, there is only one SqueakMap. > Only one is updated with regularity I can't really comment on how regular/irregular these three "portals" are used, updated. I don't have numbers. But since most projects use MC these days, and most developers do the least possible amount of work - then they end up using Squeaksource and don't bother with adding/maintaining an entry at SqueakMap. This can however be automated/fixed if we would like to - and I think we should. > and you're fixing a tool to feed the problem. No, I am not fixing it in order to feed a problem. I have no malicious intent. > Is there something I don't get here or is that what you're doing: making > the location of code more of a problem for beginners coming to Squeak? SqueakMap is a catalog, not a repository. And let's see - either it is something you do not understand *or* I am actively with malicious intent trying to make it harder for beginners.... hmmm, which one can it be... > Ensuring they find a seemingly working solution only to find that nobody > updates the RFB on SqueakMap. > > There should only be one way to get code for Squeak. One. No. There should be multiple sources and multiple formats for code. If we could have *one* catalog for finding stuff, then sure, that was the original intent of SqueakMap you know - but I have since a long time given up on trying to create monopolies. Currently, if you want to host a Changeset or a SAR-file or a .st file you can not do that on SS. You can do it using SqueakMap, and yes, SqueakMap also offers hosting capability, but it does NOT try to be Squeaksource. In fact, it doesn't even have a suitable MC repo protocol for storing directly into it, because it was always meant to be a catalog that played well with others. Interestingly, when SS came to the scene and I warned people about *some* of the consequences from the fact that we now had two partially overlapping tools - then people did not consider it a problem. ;) > All other should be chased across the ice and turned into coats. An interesting perspective - especially in an open source community. regards, Göran |
In reply to this post by Stéphane Rollandin
Stéphane Rollandin wrote:
>> If they haven't been moved tosqueaksource.com >> <http://squeaksource.com>, they've been abandoned. > > all my stuff is on SqueakMap, none of it is abandoned: > http://map.squeak.org/accountbyid/5f9bef44-1fbb-4dd6-8f10-a69862ad5674 > > how can you be so confident you're right when you're so obviously wrong ? Thanks Stéphane! regards, Göran |
In reply to this post by Göran Krampe
I can see from the tone I've used that I've got people's backs up. One the one hand I have no desire to create personal animosity. On the other hand I'm glad some people are frothing mad, because this is in my mind a serious problem. We are creating a new image and we're bringing an outdated design attitude with us. We've been ruthless in cutting out some things and some perspectives, but not here it seems.
"SqueakMap is a catalog, not a repository. And let's see - either it is something you do not understand *or* I am actively with malicious intent trying to make it harder for beginners.... hmmm, which one can it be..."
Yea, you're right I don't make this distinction, but that doesn't matter. If I open up one menu I see three code getting options. For all intents and purposes they are the same however they work.
"Deciding if the SqueakMap Package Loader should be *removed* from the image is another thing - and that is not up to me." This makes me totally insane. You're saying you're not responsible. Clearly nobody is. This is one of the banes of open source projects: stuff is just going to carry on into the future by inertia.
"No, I am not fixing it in order to feed a problem. I have no malicious intent." I know that. I know your personality and nothing is going to convince me you have any malicious intent. Due to the tone I've been using this is the kind of escalation that is a peril. Let's not go there.
"Now Lex is not AFAIK active anymore so perhaps that path could easily be taken by the rest of us." OK, how about this. How about we kill Universes and SqueakMap lives another day.
Or, we can have all three, but not on the same menu. How about we prioritize places to get code. SS and SM and UB are in the same image, but not the same menu. Experts will know where to find what they are looking for.
Chris |
Hello,
Am 2010-04-08 um 13:25 schrieb Chris Cunnington: > Or, we can have all three, but not on the same menu. How about we prioritize places to get code. "Places to get code" is a very fuzzy word. „Über einen Kamm scheren“ we say in Germany. I.e. You cannot. compare Squeaksource with (SqMap and Universes) (whilst comparing Universes and SqMap can be compared). Look at This: Debian Squeak http://ftp.debian.org (i.e, the package repository) squeaksource.com dselect SqueakMap aptitude Universes apt-get Installer I know this comparison does not hold completely (something like dpkg is heavily missnig; cf. Metacello or Sake) yet, I hope you understand my point. So Long, -Tobias (who actually is Happy about SqMap) |
In reply to this post by Chris Cunnington
Hi!
Sorry for the long post here. Chris Cunnington wrote: > I can see from the tone I've used that I've got people's backs up. One > the one hand I have no desire to create personal animosity. So far your tone is borderline for creating "personal animosity", I still give you the benefit of the doubt though. :) > On the other > hand I'm glad some people are frothing mad, because this is in my mind a > serious problem. We are creating a new image and we're bringing an > outdated design attitude with us. We've been ruthless in cutting out > some things and some perspectives, but not here it seems. Btw, for some historical note - SqueakMap was from the beginning NOT in the image. It was installable using a small snippet of code. There is no big reason for not going back to that, but then we would need some easy way to install it to begin with and... well, you see my point. But Installer from Keith in combination with some nice menu with "These are tools you probably would want to install - just pick one" that uses Installer to pull these tools in might be nice. Again, just brainstorming. > "SqueakMap is a catalog, not a repository. And let's see - either it is > something you do not understand *or* I am actively with malicious intent > trying to make it harder for beginners.... hmmm, which one can it be..." > > Yea, you're right I don't make this distinction, but that doesn't > matter. For personal animosity it matters to me. If you are accusing me of malicious intent, it matters to me. > If I open up one menu I see three code getting options. For all > intents and purposes they are the same however they work. Hmmm, well, Universes and SqueakMap - yes, clear (and historically unfortunate) overlap. Universes is AFAIK abandoned, feel free to correct me on that people. SqueakMap is not abandoned. If the third is Monticello Browser (as I guess you mean) then that is actually an SCM tool - not a package loader. Quite a bit of difference in fact, both in intent and purposes. Although the *simplest* use case is similar. I can give you lots of use cases which shows the differences. And oh, Filelist and Changesorters etc are also tools to "get code"... :) > "Deciding if the SqueakMap Package Loader should be *removed* from the > image is another thing - and that is not up to me." > > This makes me totally insane. You're saying you're not responsible. > Clearly nobody is. This is one of the banes of open source projects: > stuff is just going to carry on into the future by inertia. No, I was not saying that I am "not responsible" - I was saying that it is not *up to me* - I mean that I can't decide on my own. Further down in this post I give a proposal for a way forward, let's see if you are willing to help me out with it? Because that is what it all comes down to - someone willing and with time to actually *do* something. > "No, I am not fixing it in order to feed a problem. I have no malicious > intent." > > I know that. I know your personality and nothing is going to convince me > you have any malicious intent. Due to the tone I've been using this is > the kind of escalation that is a peril. Let's not go there. Ok, fine, let *us* not go there. ;) > "Now Lex is not AFAIK active anymore so > perhaps that path could easily be taken by the rest of us." > > OK, how about this. How about we kill Universes and SqueakMap lives > another day. > > Or, we can have all three, but not on the same menu. How about we > prioritize places to get code. SS and SM and UB are in the same image, > but not the same menu. Experts will know where to find what they are > looking for. Yeah, something along those lines. Here is my proposal (from the hip): 1. Include some instructions in the image regarding "how to get stuff" into the image. Seems like a good short term thing to do for 4.1. We can easily explain the difference between SS and SM. PU (as it was called earlier - Package Universes) is ... well, see below. 2. Possibly throw out Universes in 4.1 *iff* it does not work anymore and noone can fix it. I haven't even tried it. Does it work? 3. Regardless of when we throw out Universes we should improve SM to cover the "loss" of it. I have a rather simple idea on how to do that I think, but it needs some coding help. And ideally we would "move the content" too so that the stuff in PU that actually is used and works (given that there is such stuff) can continue to work in SM. Chris? Others? 4. Improve SqueakMap. There is a loooong list of things we could do. One thing of immediate interest given this discussion is to make it "mirror" SS somehow so that packages hosted on SS are searchable and installable from SqueakMap Package Loader and listed on map.squeak.org etc etc. We could also revive the "Make release on SqueakMap"-button that used to be in SS so that it can be used for *real* releases and not just for all new versions. Chris? Others? 5. ...rewrite SM according to the rest of the looooong list of ideas/improvements to it. Chris? Others? Well, something like that. One important aspect of SqueakMap that people seem to not "get" (and I don't blame them, it is not obvious) is that it actually is more than a catalog of packages. It is also a list of people. And it has a *model* that is *inside your image*! This means you can *do stuff* with this model. That was one of the real interesting aspects of it! Like for example this: (SMSqueakMap default packageWithName: 'muO') owner email I even have code somewhere that never got in which from the Changesorter can take a changeset, split it into multiple changesets based on PackageInfo boundaries, compose an email with all these sub changesets and then send it to all maintainers of affected packages. And this was possible because with SM we have a full model all the way: method->class->PI->SqueakMap package->maintainers/co-maintainers I should really dig out that code again.... regards, Göran |
In reply to this post by Stéphane Rollandin
>>>>> "Stéphane" == Stéphane Rollandin <[hidden email]> writes:
Stéphane> plus, SqueakMap has a functional web front-end that make it Stéphane> easy to look for existing packages, see what's there and what Stéphane> it does. Stéphane> in my experience SqueakSource is very opaque and next to Stéphane> impossible to navigate: you only have a huge projects list Stéphane> strangely sorted taking 99 pages, and a list of tags somewhat Stéphane> more useful but still very clumsy to browse. Or, to put it another way: SqueakSource is a building full of offices and luxury condos. SqueakMap is an address and telephone directory. You need both. It'd be silly to get rid of the directory, just as it would be silly to get rid of the building itself. :) Put another way yet: Not everything in SqueakSource is in SqueakMap (some things are just semi-private repos). Not everything in SqueakMap is in SqueakSource (many things live on other repos, because SM is multilinking). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
In reply to this post by Göran Krampe
>>>>> "Göran" == Göran Krampe <[hidden email]> writes:
Göran> No, not really. Universes and SqueakMap are indeed direct Göran> "competitors" and I did argue hard for merging them when Lex Göran> wrote Universes - but he was not interested in that. Now Lex is Göran> not AFAIK active anymore so perhaps that path could easily be Göran> taken by the rest of us. Universes solved the problem of dependencies, though, and I don't think there much (yet?) in SqueakMap to fix that. Now that we have Gofer and Metacello... SqueakMap would be pretty useful if it could point to those descriptions. We could make it the source of one-stop-shopping again. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Randal L. Schwartz wrote:
>>>>>> "Göran" == Göran Krampe <[hidden email]> writes: > > Göran> No, not really. Universes and SqueakMap are indeed direct > Göran> "competitors" and I did argue hard for merging them when Lex > Göran> wrote Universes - but he was not interested in that. Now Lex is > Göran> not AFAIK active anymore so perhaps that path could easily be > Göran> taken by the rest of us. > > Universes solved the problem of dependencies, though, and I don't > think there much (yet?) in SqueakMap to fix that. True, I started on my ideas for that (slightly too ambitious) and then ... Michal wrote Kabungu (dependencies for SM) but I never got it deployed. If we "nuke" PU, then we really should add *some* kind of dependencies to SM. Perhaps. > Now that we have Gofer and Metacello... SqueakMap would be pretty useful > if it could point to those descriptions. We could make it the source of > one-stop-shopping again. Indeed, that is a really good idea. I like. SqueakMap was always meant to be "package agnostic" and Metacello/Gofer - fine by me, just whip up an SMInstaller subclass to deal with them! :) regards, Göran |
In reply to this post by Göran Krampe
On 4/8/2010 5:23 AM, Göran Krampe wrote:
> 1. Include some instructions in the image regarding "how to get stuff" > into the image. Seems like a good short term thing to do for 4.1. We can > easily explain the difference between SS and SM. PU (as it was called > earlier - Package Universes) is ... well, see below. If you write it, I'll add it to the welcome notes (or perhaps in the help menu). > 2. Possibly throw out Universes in 4.1 *iff* it does not work anymore > and noone can fix it. I haven't even tried it. Does it work? It does. So does SM. Barring catastrophic circumstances, the set of packages for 4.1 hopefully won't have to change at this point. Remember, I want to ship this puppy next week :-) Cheers, - Andreas > 3. Regardless of when we throw out Universes we should improve SM to > cover the "loss" of it. I have a rather simple idea on how to do that I > think, but it needs some coding help. And ideally we would "move the > content" too so that the stuff in PU that actually is used and works > (given that there is such stuff) can continue to work in SM. Chris? Others? > > 4. Improve SqueakMap. There is a loooong list of things we could do. One > thing of immediate interest given this discussion is to make it "mirror" > SS somehow so that packages hosted on SS are searchable and installable > from SqueakMap Package Loader and listed on map.squeak.org etc etc. We > could also revive the "Make release on SqueakMap"-button that used to be > in SS so that it can be used for *real* releases and not just for all > new versions. Chris? Others? > > 5. ...rewrite SM according to the rest of the looooong list of > ideas/improvements to it. Chris? Others? > > > Well, something like that. > > One important aspect of SqueakMap that people seem to not "get" (and I > don't blame them, it is not obvious) is that it actually is more than a > catalog of packages. It is also a list of people. And it has a *model* > that is *inside your image*! > > This means you can *do stuff* with this model. That was one of the real > interesting aspects of it! Like for example this: > > (SMSqueakMap default packageWithName: 'muO') owner email > > I even have code somewhere that never got in which from the Changesorter > can take a changeset, split it into multiple changesets based on > PackageInfo boundaries, compose an email with all these sub changesets > and then send it to all maintainers of affected packages. > > And this was possible because with SM we have a full model all the way: > > method->class->PI->SqueakMap package->maintainers/co-maintainers > > I should really dig out that code again.... > > regards, Göran > > |
Free forum by Nabble | Edit this page |