I suppose I have missed something, the question is what?
The VM crashes when I try to install BabySRE-TRee39 package from SqueakMap. The VM also crashes when I try to install Balloon3D 1.0.4 package from SqueakMap.
OS: WinXP version 5.1, SP 2 Image: Squeak3.10beta.7158 VM: SqueakVM-3.10.6
What's wrong?
Thanks --Trygve
Hi!
Trygve Reenskaug trygver@ifi.uio.no wrote:
I suppose I have missed something, the question is what?
The VM crashes when I try to install BabySRE-TRee39 package from SqueakMap. The VM also crashes when I try to install Balloon3D 1.0.4 package from SqueakMap.
OS: WinXP version 5.1, SP 2 Image: Squeak3.10beta.7158 VM: SqueakVM-3.10.6
What's wrong?
I just installed that package into my 7158 image - but on Linux using an older VM. So my guess is that it is not SM related, possibly VM related - dunno.
regards, Göran
El 10/25/07 11:31 AM, "Trygve Reenskaug" trygver@ifi.uio.no escribió:
The VM crashes when I try to install BabySRE-TRee39 package from SqueakMap. The VM also crashes when I try to install Balloon3D 1.0.4 package from SqueakMap.
For your excellent code, I could always load from 3.10 release start, (I admire this !!) All you need is drag and drop on the image from previous saved .mcz. Of course, you need Connectors, also works in 3.10. Don't know about if you have a Package Universes for it, remember this is the prefered choice now. Maybe SqueakMap version is broken ?
For Ballon3D I see Orphanage from SqueakMap. And 3.6 Squeak. I have it in the FunSqueak version , and also Wonderland, but is causing collateral troubles.
Edgar
On Thu, Oct 25, 2007 at 04:31:55PM +0200, Trygve Reenskaug wrote:
I suppose I have missed something, the question is what?
The VM crashes when I try to install BabySRE-TRee39 package from SqueakMap. The VM also crashes when I try to install Balloon3D 1.0.4 package from SqueakMap.
OS: WinXP version 5.1, SP 2 Image: Squeak3.10beta.7158 VM: SqueakVM-3.10.6
What's wrong?
One problem I have seen with SqueakMap in 7158 came from change 7142. Some code in DataStream, which is used to read the ImageSegments used by SqueakMap was broken by replacing several object identity comparisons with equality. I have not seen a crash, but I would suspect the problems are related. For this reason, I am sticking with image version 7137 until I or someone else resolve the bugs introduced in 7142.
El 10/27/07 2:05 PM, "Matthew Fulmer" tapplek@gmail.com escribió:
One problem I have seen with SqueakMap in 7158 came from change 7142.
Nope. I repeat recipe I give a month ago.
Some verbose , but clear how to rid of old versions files disturbing normal 3.10 peace.
| directoryName directory filesToErase | directoryName := (FileDirectory default pathName ,FileDirectory slash, 'sm'). directory := FileDirectory on: directoryName. filesToErase := directory fileNamesMatching: '*.sgz'. filesToErase do:[:filename| directory deleteFileNamed: filename]
And the answer why fail is Goran use ImageSegments (he have many to me to learn) and the classes in 3.9 or earlier was different.
That's why many .pr fails to load
Hope this helps.
Edgar
I am sticking with image version 7137 until I or someone else resolve the bugs introduced in 7142.
You could use any Squeak you like. I was the guilty of trust Dan and someone which do the change before me and I decide doing for 3.10 The bad news is 98% of 172 methods Dan code change are right and only a few need ==. I send proposal how to deal with this, but still no decision.
And for the last time, you should use Universes. If your wished code is not in Universes, means author is not active this days. SqueakMap was a very valuable tool, like any good library is. But don't guaranties of code in SM works in 3.10, if not say so. And if say works , must be in Universes.
Edgar
And for the last time, you should use Universes. If your wished code is not in Universes, means author is not active this days. SqueakMap was a very valuable tool, like any good library is. But don't guaranties of code in SM works in 3.10, if not say so. And if say works , must be in Universes.
Edgar, you are sounding way too tyrannical here. As the developer of the "next Squeak" please find the idea of "software freedom" in your heart asap. Help people integrate what they need and want, don't tell them they're wrong for wanting something you don't care about.
And for the last time...
I truly hope this *is* the last time we hear something so ridiculous from you. There are many avid Squeakers who do not use Universes. I happen to be one of them. SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
Thanks.
On 10/28/07, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
El 10/27/07 2:05 PM, "Matthew Fulmer" tapplek@gmail.com escribió:
One problem I have seen with SqueakMap in 7158 came from change 7142.
Nope. I repeat recipe I give a month ago.
Some verbose , but clear how to rid of old versions files disturbing normal 3.10 peace.
| directoryName directory filesToErase | directoryName := (FileDirectory default pathName ,FileDirectory slash, 'sm'). directory := FileDirectory on: directoryName. filesToErase := directory fileNamesMatching: '*.sgz'. filesToErase do:[:filename| directory deleteFileNamed: filename]
And the answer why fail is Goran use ImageSegments (he have many to me to learn) and the classes in 3.9 or earlier was different.
That's why many .pr fails to load
Hope this helps.
Edgar
I am sticking with image version 7137 until I or someone else resolve the bugs introduced in 7142.
You could use any Squeak you like. I was the guilty of trust Dan and someone which do the change before me and I decide doing for 3.10 The bad news is 98% of 172 methods Dan code change are right and only a few need ==. I send proposal how to deal with this, but still no decision.
And for the last time, you should use Universes. If your wished code is not in Universes, means author is not active this days. SqueakMap was a very valuable tool, like any good library is. But don't guaranties of code in SM works in 3.10, if not say so. And if say works , must be in Universes.
Edgar
On 10/31/07, Chris Muller asqueaker@gmail.com wrote:
SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
I'm confused here. As far as I know:
SqueakMap is a tool that allows one to load a package into an image Universes is a tool that allows one to load a package into an image, but is more sophisticated (e.g. understands dependencies).
Please correct me if I'm wrong, because by that definition SqueakMap appears to be clearly obsolete from a technical point of view.
Note, I'm only speaking to your statement about Universes being misguided and not rendering SqueakMap obsolete. The nostalgia of SM and the purpose it serves as a record of anything ever done in Squeak are a separate concern.
On Wed, 2007-10-31 at 06:01 +0100, Jason Johnson wrote:
On 10/31/07, Chris Muller asqueaker@gmail.com wrote:
SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
I'm confused here. As far as I know:
SqueakMap is a tool that allows one to load a package into an image Universes is a tool that allows one to load a package into an image, but is more sophisticated (e.g. understands dependencies).
Please correct me if I'm wrong, because by that definition SqueakMap appears to be clearly obsolete from a technical point of view.
Note, I'm only speaking to your statement about Universes being misguided and not rendering SqueakMap obsolete. The nostalgia of SM and the purpose it serves as a record of anything ever done in Squeak are a separate concern.
I'm a user of universes but I cannot agree with the statement of squeakmap being obsolete. Squeakmap is a good tool to install packages. It has proven that it works for exactly that need. To say a tool which manages dependencies is more sophisticated is problematic in my opinion. At first dependencies introduce complexity which isn't always good. The upside of having dependencies has the downside to be hussled by dependencies. With dependencies it is easy to install software in first place. If I have my own set of module versions I don't want to have a tool which decides to install other versions than the ones I like. I know this can be prevented but it stays problematic.
I know the success story of such a system quite well. It is called debian. There you are forced to use dependencies (most of the time). In the debian world this is a good thing because a lot of work goes into the management of these dependencies and into the inter- operability of the packages which depend on each other. Please do not ignore this extra effort. In my opinion I don't have a problem with this system in debian because I know I can trust them.
Maybe there will be a time when universes split into more universes of stability (or other categories) where a lot of people have an eye on the interoperability and the dependencies. At this time having a browser which lets me override dependencies would be very good. I think at this time I would reconsider squeakmap being obsolete :)
At the end I learned something valuable from this list: Something is obsolete if nobody wants to use it anymore. And it doesn't seem to be the case right now.
Norbert
First off, I didn't mean completely obsoleted, in that it can be deleted or something. It does serve a purpose still, just what I perceive as it's previous main functionality is obsolete imo.
That's not a bad thing, that just means things changed. If you look around and see northing's changing, then check your pulse, you must be dead. SM has carved out a perfectly good niche of being the catalog of Squeak, and will likely continue to do this indefinitely.
On 10/31/07, Norbert Hartl norbert@hartl.name wrote:
To say a tool which manages dependencies is more sophisticated is problematic in my opinion. At first dependencies introduce complexity which isn't always good. The upside of having dependencies has the downside to be hussled by dependencies. With dependencies it is easy to install software in first place. If I have my own set of module versions I don't want to have a tool which decides to install other versions than the ones I like. I know this can be prevented but it stays problematic.
On Wed, Oct 31, 2007 at 06:01:44AM +0100, Jason Johnson wrote:
On 10/31/07, Chris Muller asqueaker@gmail.com wrote:
SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
I'm confused here. As far as I know:
SqueakMap is a tool that allows one to load a package into an image Universes is a tool that allows one to load a package into an image, but is more sophisticated (e.g. understands dependencies).
Please correct me if I'm wrong, because by that definition SqueakMap appears to be clearly obsolete from a technical point of view.
Yes, you are confused. SqueakMap is a catalogue of available stuff that may or may not be appropriate for the image you are running. Universes define collections of stuff from SqueakMap (and elsewhere) that will probably work with the image you are running. These are completely different goals, and the two are complementary.
Portraying SqueakMap and Universes as competitors is very unhelpful. It is likely to discourage much-needed improvements to SqueakMap, and it comes across (at least to me) as unappreciative of the work of the people who have developed and supported it.
Dave
On 10/31/07, David T. Lewis lewis@mail.msen.com wrote:
Yes, you are confused. SqueakMap is a catalogue of available stuff that may or may not be appropriate for the image you are running. Universes define collections of stuff from SqueakMap (and elsewhere) that will probably work with the image you are running. These are completely different goals, and the two are complementary.
Well, that may be, but I'm pretty sure that most people use it as a way of loading packages into their system. And that functionality is clearly less functional then universes.
Portraying SqueakMap and Universes as competitors is very unhelpful. It is likely to discourage much-needed improvements to SqueakMap, and it comes across (at least to me) as unappreciative of the work of the people who have developed and supported it.
Dave
Do people in other fields get so emotionally attached to their tools? It's hard to imagine someone holding a hammer getting offended if I say that it's easier to cut boards in half with a saw.
Of course I appreciate the work that has been done and the people who have made this all possible. And I appreciate that SqueakMap remains a good catalog of everything ever made for Smalltalk. But as a "I'm new to Squeak and want to load packages into my image" solution, it's no longer the best option.
Jason Johnson wrote:
On 10/31/07, David T. Lewis lewis@mail.msen.com wrote:
Yes, you are confused. SqueakMap is a catalogue of available stuff that may or may not be appropriate for the image you are running. Universes define collections of stuff from SqueakMap (and elsewhere) that will probably work with the image you are running. These are completely different goals, and the two are complementary.
Well, that may be, but I'm pretty sure that most people use it as a way of loading packages into their system. And that functionality is clearly less functional then universes.
For me, Universes are useless. Since I don't run the latest Squeak versions I always go to SM when I need to find a particular package. Since it has a web interface I (or Google) can find things there. Since it lists the versions for which a package is available I can choose one that is closest to what I need for porting. Universes are no replacement for this.
Do people in other fields get so emotionally attached to their tools? It's hard to imagine someone holding a hammer getting offended if I say that it's easier to cut boards in half with a saw.
You must be new here ;-) If people were less attached to their tools, then Universes would have been built *on top of* SM so that it actually increases the value of SM as a global repository of "all things squeak" instead of having isolated, inaccessible repositories that decrease the value of SM. SM and Universes are complementary; one serves the role of a global repository for all Squeak code ever written and one serves the purpose of defining versions of packages that work together. They could easily enhance each other if people were less attached to their tools.
Cheers, - Andreas
On 10/31/07, Andreas Raab andreas.raab@gmx.de wrote:
For me, Universes are useless. Since I don't run the latest Squeak versions I always go to SM when I need to find a particular package. Since it has a web interface I (or Google) can find things there. Since it lists the versions for which a package is available I can choose one that is closest to what I need for porting. Universes are no replacement for this.
True, SM is certainly the best option for older images. Universes have the version of the package as well, not that does you any good. :)
You must be new here ;-)
I've only got around 10 years in the field, but I've never fully understood this emotional part. :)
If people were less attached to their tools, then Universes would have been built *on top of* SM so that it actually increases the value of SM as a global repository of "all things squeak" instead of having isolated, inaccessible repositories that decrease the value of SM.
Good point, I haven't heard/read why it was chosen to be a separate thing, but I would guess it was the usual: it seemed easier to make something from scratch then add functionality to an existing system.
Hi!
"Jason Johnson" jason.johnson.081@gmail.com wrote:
On 10/31/07, Andreas Raab andreas.raab@gmx.de wrote:
If people were less attached to their tools, then Universes would have been built *on top of* SM so that it actually increases the value of SM as a global repository of "all things squeak" instead of having isolated, inaccessible repositories that decrease the value of SM.
Good point, I haven't heard/read why it was chosen to be a separate thing, but I would guess it was the usual: it seemed easier to make something from scratch then add functionality to an existing system.
You would have to ask Lex. I have always argued for merging them and as I hinted in some post - I and Brian proposed it too at one point. I can not see either why we couldn't have done Universes "on top of" SM, but I am partial in all this.
regards, Göran
Hi folks!
On Wed, Oct 31, 2007 at 06:01:44AM +0100, Jason Johnson wrote:
On 10/31/07, Chris Muller asqueaker@gmail.com wrote:
SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
I'm confused here. As far as I know:
SqueakMap is a tool that allows one to load a package into an image Universes is a tool that allows one to load a package into an image, but is more sophisticated (e.g. understands dependencies).
Please correct me if I'm wrong, because by that definition SqueakMap appears to be clearly obsolete from a technical point of view.
Yes, you are confused. SqueakMap is a catalogue of available stuff that may or may not be appropriate for the image you are running. Universes define collections of stuff from SqueakMap (and elsewhere) that will probably work with the image you are running. These are completely different goals, and the two are complementary.
Portraying SqueakMap and Universes as competitors is very unhelpful. It is likely to discourage much-needed improvements to SqueakMap, and it comes across (at least to me) as unappreciative of the work of the people who have developed and supported it.
Dave
I am at large staying out of this discussion I think, but a few comments:
- Yes, they are different and should be complementary as they stand today. - Yes, they also do overlap in many ways and could possibly be merged into a single system, this has by the way been proposed by me and Brian Rice at at least one point. - I have had very little time moving SM forward and have also repeatedly tried to round up interest in helping out on that "new SM" (not much luck there though). - I *personally* have some slight doubts about maintaining multiple universes. I think most package maintainers have just energy enough to maintain their package in ONE place, not multiple. I don't have a good answer to that problem other than that if I had endless time to spend I would make a new SM3 that "does Universes too" and thus could theoretically replace both SM and Universes. But I don't have that time. :)
regards, Göran
Il giorno mer, 31/10/2007 alle 21.33 +0100, Göran Krampe ha scritto:
- Yes, they are different and should be complementary as they stand today.
- Yes, they also do overlap in many ways and could possibly be merged into
a single system, this has by the way been proposed by me and Brian Rice at at least one point.
- I have had very little time moving SM forward and have also repeatedly
tried to round up interest in helping out on that "new SM" (not much luck there though).
As I said a couple of times on #squeak, I have some ideas on how a SM3 could possibly work, and how it could be used as a lower-level layer for Universes. If anyone wants to help, feel free to contact me.
Giovanni
Giovanni Corriga wrote:
Il giorno mer, 31/10/2007 alle 21.33 +0100, Göran Krampe ha scritto:
- Yes, they are different and should be complementary as they stand today.
- Yes, they also do overlap in many ways and could possibly be merged into
a single system, this has by the way been proposed by me and Brian Rice at at least one point.
- I have had very little time moving SM forward and have also repeatedly
tried to round up interest in helping out on that "new SM" (not much luck there though).
As I said a couple of times on #squeak, I have some ideas on how a SM3 could possibly work, and how it could be used as a lower-level layer for Universes. If anyone wants to help, feel free to contact me.
I have a feature request here: It would be nice to browse squeaksource.com and other squeaksource repositories from within Squeak. I find I must use a external webbrowser to get project / url info most of the time. There seem to be something missing between Universes/SqueakMap and the monticello browser. Karl
Hi Giovanni!
Giovanni Corriga giovanni@corriga.net wrote:
Il giorno mer, 31/10/2007 alle 21.33 +0100, Göran Krampe ha scritto:
- Yes, they are different and should be complementary as they stand today.
- Yes, they also do overlap in many ways and could possibly be merged into
a single system, this has by the way been proposed by me and Brian Rice at at least one point.
- I have had very little time moving SM forward and have also repeatedly
tried to round up interest in helping out on that "new SM" (not much luck there though).
As I said a couple of times on #squeak, I have some ideas on how a SM3 could possibly work, and how it could be used as a lower-level layer for Universes. If anyone wants to help, feel free to contact me.
Giovanni
I am interested and will gladly chat with you. :) I have tons of "SM3 writeups" laying around with ideas and concepts.
regards, Göran
SqueakMap supports SAR files, which can do *anything*. Therefore it, too, supports dependencies.
To me, the process of building an image is something that always needs to be done with care. A tool that tries to pick "the most recent versions" of prerequisite packages, to me, is "gunslinger" style of building an image.
What exactly does "guaranteed to work together" mean? This is a notion I never really followed about Universes. Does it simply mean what SqueaMap already tells us? That neither of the packages does any modifications to the base image? "Work" has different means for different people depending on the needs. If loading one package causes a slow-down in the performance of the other that matters to me, how can it be said "guaranteed to work?"
This is why I used the strong word "misguided". It is not intended as a criticism of the technology, maybe more of the marketing..
Stef wrote:
the intention being universes is to have a kind of certified release which is really valuable.
By "certiifed" do you mean an assessment of the level of quality? If so, SqueakMap has this too ("Solid as a rock" ... "Full of bugs for developers only).
Since lot of squeakmap packages do not indicate really if they work on not in a given version.
A given version of Squeak? Yes it does. They all indicate what versions of Squeak they are for, and when you load it you get a warning if your version of Squeak does not match, but still allowing to proceed at your risk.
On 10/31/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/31/07, Chris Muller asqueaker@gmail.com wrote:
SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
I'm confused here. As far as I know:
SqueakMap is a tool that allows one to load a package into an image Universes is a tool that allows one to load a package into an image, but is more sophisticated (e.g. understands dependencies).
Please correct me if I'm wrong, because by that definition SqueakMap appears to be clearly obsolete from a technical point of view.
Note, I'm only speaking to your statement about Universes being misguided and not rendering SqueakMap obsolete. The nostalgia of SM and the purpose it serves as a record of anything ever done in Squeak are a separate concern.
On Oct 31, 2007, at 7:51 PM, Chris Muller wrote:
SqueakMap supports SAR files, which can do *anything*. Therefore it, too, supports dependencies.
To me, the process of building an image is something that always needs to be done with care. A tool that tries to pick "the most recent versions" of prerequisite packages, to me, is "gunslinger" style of building an image.
What exactly does "guaranteed to work together" mean? This is a notion I never really followed about Universes. Does it simply mean what SqueaMap already tells us? That neither of the packages does any modifications to the base image? "Work" has different means for different people depending on the needs. If loading one package causes a slow-down in the performance of the other that matters to me, how can it be said "guaranteed to work?"
Hi Chris - I think you are missing one of the main points of the Universe model. Universes do not pick the "most recent version of anything. A particular universe has pointers to specific code packages, i.e. specific mcz files which represent one and only one version of that piece of code. There is nothing dynamic about it, so it is really like a freebsd port or debian package - you have to have specific version of the dependencies that port or package needs, not just the "latest".
"Guaranteed to work together" means that the author of the Universe has ostensibly tested that the specific package versions in that Universe do in fact work together. Since it is NOT grabbing "the latest code", that is a claim a Universe can make.
Of course, nothing prevents someone from creating a Universe and putting incompatible packages in it and not testing it; the purpose, however, is define a cohesive set of code that does work together.
I think the fact that most Universes published have a great deal of code in them is a bit misleading as to the purpose of Universes - for example, if I have a seaside web app that I want to deploy, building a universe that contains the specific version of Kom, Seaside, Scriptaculous, Magritte, etc. that is a working, stable application makes great sense. Someone can load that Universe and expect it to work.
Later I can create a newer version of Universe with newer packages in it - someone can load the new one or the old one, it's there choice.
This is why I used the strong word "misguided". It is not intended as a criticism of the technology, maybe more of the marketing..
Stef wrote:
the intention being universes is to have a kind of certified release which is really valuable.
By "certiifed" do you mean an assessment of the level of quality? If so, SqueakMap has this too ("Solid as a rock" ... "Full of bugs for developers only).
Since lot of squeakmap packages do not indicate really if they work on not in a given version.
A given version of Squeak? Yes it does. They all indicate what versions of Squeak they are for, and when you load it you get a warning if your version of Squeak does not match, but still allowing to proceed at your risk.
On 10/31/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/31/07, Chris Muller asqueaker@gmail.com wrote:
SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
I'm confused here. As far as I know:
SqueakMap is a tool that allows one to load a package into an image Universes is a tool that allows one to load a package into an image, but is more sophisticated (e.g. understands dependencies).
Please correct me if I'm wrong, because by that definition SqueakMap appears to be clearly obsolete from a technical point of view.
Note, I'm only speaking to your statement about Universes being misguided and not rendering SqueakMap obsolete. The nostalgia of SM and the purpose it serves as a record of anything ever done in Squeak are a separate concern.
Brian Brown wrote:
Hi Chris - I think you are missing one of the main points of the Universe model. Universes do not pick the "most recent version of anything. A particular universe has pointers to specific code packages, i.e. specific mcz files which represent one and only one version of that piece of code. There is nothing dynamic about it, so it is really like a freebsd port or debian package - you have to have specific version of the dependencies that port or package needs, not just the "latest".
That is *definitely* not true. The code in UUniverseBrowser>>allPackagesNeededToInstall:orIfImpossible: explicitly uses the *latest* version of a package; the basic loop goes like this:
package depends do: [ :depName | "... some code omitted for brevity ..." (universe hasPackageNamed: depName) ifTrue: [ packagesToConsider add: (universe newestPackageNamed: depName) ].
and #newestPackageNamed: does just what it says:
newestPackageNamed: name | potentials sorted | potentials _ self packagesNamed: name. sorted _ potentials asSortedCollection: [ :p1 :p2 | p1 version < p2 version ]. ^sorted last
"Guaranteed to work together" means that the author of the Universe has ostensibly tested that the specific package versions in that Universe do in fact work together. Since it is NOT grabbing "the latest code", that is a claim a Universe can make.
Given the above, how can it?
Cheers, - Andreas
On Nov 1, 2007, at 12:26 AM, Andreas Raab wrote:
Brian Brown wrote:
Hi Chris - I think you are missing one of the main points of the Universe model. Universes do not pick the "most recent version of anything. A particular universe has pointers to specific code packages, i.e. specific mcz files which represent one and only one version of that piece of code. There is nothing dynamic about it, so it is really like a freebsd port or debian package - you have to have specific version of the dependencies that port or package needs, not just the "latest".
That is *definitely* not true. The code in UUniverseBrowser>>allPackagesNeededToInstall:orIfImpossible: explicitly uses the *latest* version of a package; the basic loop goes like this:
package depends do: [ :depName | "... some code omitted for brevity ..." (universe hasPackageNamed: depName) ifTrue: [ packagesToConsider add: (universe newestPackageNamed: depName) ].
and #newestPackageNamed: does just what it says:
newestPackageNamed: name | potentials sorted | potentials _ self packagesNamed: name. sorted _ potentials asSortedCollection: [ :p1 :p2 | p1 version < p2 version ]. ^sorted last
Well, obviously a gross misunderstanding on my part, based on Lex's initial discussions and further clarifications on what Universes are supposed to be. I did not look at the code to verify that, but was arguing from what I had gathered from the discussion.
In light of the actual code, I have to retract what I said, with apologies.
Thanks for pointing this out!
"Guaranteed to work together" means that the author of the Universe has ostensibly tested that the specific package versions in that Universe do in fact work together. Since it is NOT grabbing "the latest code", that is a claim a Universe can make.
Given the above, how can it?
Agreed ;)
Cheers,
- Andreas
On Nov 1, 2007, at 7:43 , Brian Brown wrote:
On Nov 1, 2007, at 12:26 AM, Andreas Raab wrote:
Brian Brown wrote:
Hi Chris - I think you are missing one of the main points of the Universe model. Universes do not pick the "most recent version of anything. A particular universe has pointers to specific code packages, i.e. specific mcz files which represent one and only one version of that piece of code. There is nothing dynamic about it, so it is really like a freebsd port or debian package - you have to have specific version of the dependencies that port or package needs, not just the "latest".
That is *definitely* not true. The code in UUniverseBrowser>>allPackagesNeededToInstall:orIfImpossible: explicitly uses the *latest* version of a package; the basic loop goes like this:
package depends do: [ :depName | "... some code omitted for brevity ..." (universe hasPackageNamed: depName) ifTrue: [ packagesToConsider add: (universe newestPackageNamed: depName) ].
and #newestPackageNamed: does just what it says:
newestPackageNamed: name | potentials sorted | potentials _ self packagesNamed: name. sorted _ potentials asSortedCollection: [ :p1 :p2 | p1 version < p2 version ]. ^sorted last
Well, obviously a gross misunderstanding on my part, based on Lex's initial discussions and further clarifications on what Universes are supposed to be. I did not look at the code to verify that, but was arguing from what I had gathered from the discussion.
In light of the actual code, I have to retract what I said, with apologies.
Thanks for pointing this out!
"Guaranteed to work together" means that the author of the Universe has ostensibly tested that the specific package versions in that Universe do in fact work together. Since it is NOT grabbing "the latest code", that is a claim a Universe can make.
Given the above, how can it?
Agreed ;)
You're forgetting there are multiple Universes. Inside one Universe, you get the latest version. Changes that break backwards- compatibility have to go into the next Universe.
- Bert -
On Wed, Oct 31, 2007 at 11:26:27PM -0700, Andreas Raab wrote:
Brian Brown wrote:
Hi Chris - I think you are missing one of the main points of the Universe model. Universes do not pick the "most recent version of anything. A particular universe has pointers to specific code packages, i.e. specific mcz files which represent one and only one version of that piece of code. There is nothing dynamic about it, so it is really like a freebsd port or debian package - you have to have specific version of the dependencies that port or package needs, not just the "latest".
That is *definitely* not true. The code in UUniverseBrowser>>allPackagesNeededToInstall:orIfImpossible: explicitly uses the *latest* version of a package; the basic loop goes like this:
Certainly, but this refers to the handling of multiple versions of a package within the universe (which should generally be discouraged BTW). On the other hand, if you have versions 2 and 3 of FooPackage in your universe, and next year someone adds versions 4, 5, and 6 of FooPackage to SqueakMap, your universe will still point at version 3. This is probably exactly what you want, particularly if the new and improved FooPackage V6.0 has been updated to use some annoying new feature that breaks your image and that you didn't want in the first place ;)
Dave
David T. Lewis wrote:
Certainly, but this refers to the handling of multiple versions of a package within the universe (which should generally be discouraged BTW). On the other hand, if you have versions 2 and 3 of FooPackage in your universe, and next year someone adds versions 4, 5, and 6 of FooPackage to SqueakMap, your universe will still point at version 3. This is probably exactly what you want, particularly if the new and improved FooPackage V6.0 has been updated to use some annoying new feature that breaks your image and that you didn't want in the first place ;)
I don't get it. What you say above is in every way true for Squeakmap. First, I don't think you actually meant what you said above because it's trivially true in reverse: When putting v2 and v3 on SM and v4...v6 in Universes then SM would (obviously) still point at v3.
The only way this makes sense is if you say that when you put v2 and v3 into universe A and v4 ... v6 into universe B that universe A still points to v3. Okay. SM does that by using version tags - if you mark v2 and v3 for vX.y and v4...v6 for vX.z then you'll load v3 if you are in vX.y and v6 in vX.z. Where is the difference?
Cheers, - Andreas
On Thu, Nov 01, 2007 at 09:43:58AM -0700, Andreas Raab wrote:
David T. Lewis wrote:
Certainly, but this refers to the handling of multiple versions of a package within the universe (which should generally be discouraged BTW). On the other hand, if you have versions 2 and 3 of FooPackage in your universe, and next year someone adds versions 4, 5, and 6 of FooPackage to SqueakMap, your universe will still point at version 3. This is probably exactly what you want, particularly if the new and improved FooPackage V6.0 has been updated to use some annoying new feature that breaks your image and that you didn't want in the first place ;)
I don't get it. What you say above is in every way true for Squeakmap. First, I don't think you actually meant what you said above because it's trivially true in reverse: When putting v2 and v3 on SM and v4...v6 in Universes then SM would (obviously) still point at v3.
The only way this makes sense is if you say that when you put v2 and v3 into universe A and v4 ... v6 into universe B that universe A still points to v3. Okay. SM does that by using version tags - if you mark v2 and v3 for vX.y and v4...v6 for vX.z then you'll load v3 if you are in vX.y and v6 in vX.z. Where is the difference?
I meant it in the sense of how I as a package maintainer would expect SqueakMap and Universes to work. I don't mean to comment on the implementations, or whether the two should be integrated.
For example, there are various releases of the OSProcess package listed on SqueakMap that claim to support images back to Squeak 2.8. If I release something new, I will expect to register it on SqueakMap. Any of these versions of the package might end up being registered in a Universe, possibly with my knowledge and possibly not (this has actually happened already, so it's not a theoretical example).
It's already enough of a hassle for me to keep SqueakMap entries up to date, so I don't want to be responsible for figuring out all of the possible Universes that might need to point to various versions of my package. In a few cases I might have enough time and interest to keep track of this and do the necessary testing, but in general I will not.
On the other hand, if I download a new Squeak image and want to load OSProcess, I like being able to do this with the Universe loader. As a Squeak user, it's simply a very convenient way to do this, and as the package maintainer it's a good way for me to make sure that I load the same version of the package that other users of this Universe are seeing.
As a user of SqueakMap and Universes, a loose coupling between the two of them works perfectly fine for me. Having them be more integrated sounds like a good thing, but it does not matter to me one way or the other as long as they both work and serve their intended purposes.
Dave
Andreas Raab writes:
That is definitely not true. The code in UUniverseBrowser>>allPackagesNeededToInstall:orIfImpossible: explicitly uses the latest version of a package; the basic loop goes like this:
You are both correct. This method grabs the latest version within the current universe. Many universes are static, for example the stable releases, and thus that version is fixed for all time. Other universes, such as the development universe, change over time. The precise policy is up to the maintainers of the universe.
I don't get it. What you say above is in every way true for Squeakmap. First, I don't think you actually meant what you said above because it's trivially true in reverse: When putting v2 and v3 on SM and v4...v6 in Universes then SM would (obviously) still point at v3.
A motivating example would be the 3.7 stable universe. If you want to work with a 3.7-ish set of Squeak code, then you can still download the 3.7u2 image. That image, released years ago, is a 3.7 image plus a pointer to the "squeak3.7" stable universe. That stable universe has 200 packages that you can still load and work, years after the release was made.
-Lex
The misunderstanding here is that it is the latest version of the *configured* package. So if someone releases a new version of a dependency you have, you have to explicitly make a pointer to the new version. If you don't, the Universe wont load it because it doesn't know about it.
On 11/1/07, Andreas Raab andreas.raab@gmx.de wrote:
Brian Brown wrote:
Hi Chris - I think you are missing one of the main points of the Universe model. Universes do not pick the "most recent version of anything. A particular universe has pointers to specific code packages, i.e. specific mcz files which represent one and only one version of that piece of code. There is nothing dynamic about it, so it is really like a freebsd port or debian package - you have to have specific version of the dependencies that port or package needs, not just the "latest".
That is *definitely* not true. The code in UUniverseBrowser>>allPackagesNeededToInstall:orIfImpossible: explicitly uses the *latest* version of a package; the basic loop goes like this:
package depends do: [ :depName | "... some code omitted for brevity ..." (universe hasPackageNamed: depName) ifTrue: [ packagesToConsider add: (universe newestPackageNamed: depName) ].
and #newestPackageNamed: does just what it says:
newestPackageNamed: name | potentials sorted | potentials _ self packagesNamed: name. sorted _ potentials asSortedCollection: [ :p1 :p2 | p1 version < p2 version ]. ^sorted last
"Guaranteed to work together" means that the author of the Universe has ostensibly tested that the specific package versions in that Universe do in fact work together. Since it is NOT grabbing "the latest code", that is a claim a Universe can make.
Given the above, how can it?
Cheers,
- Andreas
Jason Johnson wrote:
The misunderstanding here is that it is the latest version of the *configured* package. So if someone releases a new version of a dependency you have, you have to explicitly make a pointer to the new version. If you don't, the Universe wont load it because it doesn't know about it.
I don't understand this. What does "configured package" mean? The way I understand it, it goes like this: * You post a couple of versions of the Graphics package into the 3.10 universe. * I post a couple of versions of the Balloon package into the 3.10 universe. The Balloon package depends on Graphics, but since I use the Graphics package there is a good chance that I've tested it so it should be okay. * Later, you post a new version of the Graphics package. Since you don't depend on the Balloon package there is absolutely no guarantee that you've ever tested it together (and how could you - every second package will depend on Graphics).
The way I read the code, my Balloon package will *automatically* pick up the latest version of the Graphics package, without any further explicit intervention.
If I'm mistaken, please correct me.
Cheers, - Andreas
On 11/1/07, Andreas Raab andreas.raab@gmx.de wrote:
I don't understand this. What does "configured package" mean?
Configured for that specific Universe. Each universe has it's own separate configuration about the packages it contains. Just creating a package and putting it on Squeak Source wont make the Universe aware of it.
The way I understand it, it goes like this:
- You post a couple of versions of the Graphics package into the 3.10
universe.
- I post a couple of versions of the Balloon package into the 3.10
universe. The Balloon package depends on Graphics, but since I use the Graphics package there is a good chance that I've tested it so it should be okay.
- Later, you post a new version of the Graphics package. Since you don't
depend on the Balloon package there is absolutely no guarantee that you've ever tested it together (and how could you - every second package will depend on Graphics).
Well, this *can* be a way it works but this is not how it is *supposed* to work. The only people who are supposed to publish packages to a Universe are the package maintainers, and they are not supposed test everything when they bring a new package in. It was my understanding that this was part of the goal of having an "all tests green" 3.10. To make it faster verifying packages in the 3.10 Universe.
The way I read the code, my Balloon package will *automatically* pick up the latest version of the Graphics package, without any further explicit intervention.
Yes, that's true. If someone comes along and adds a new version of a package to the universe that doesn't work with other packages that will cause a breakage. But this is using the system in a way it wasn't intended.
If I'm mistaken, please correct me.
You are technically correct. There is a social aspect required with Universes to make them work, but the benefit is that when I go get the latest "Seaside" universe, and I work in it for 3 weeks off line, then I get back on the internet and click "update" it can automatically upgrade every package that is behind and I *should* be able to have confidence that these upgrades wont break existing packages. Provided people didn't do what you just described. :)
On 11/1/07, Jason Johnson jason.johnson.081@gmail.com wrote:
The only people who are supposed to publish packages to a Universe are the package maintainers, and they are not supposed test everything when they bring a new package in.
Ugh, what an embarrassing typo. I need to upgrade my proof reader! :)
Jason Johnson wrote:
On 11/1/07, Jason Johnson jason.johnson.081@gmail.com wrote:
The only people who are supposed to publish packages to a Universe are the package maintainers, and they are not supposed test everything when they bring a new package in.
Ugh, what an embarrassing typo. I need to upgrade my proof reader! :)
I figured it was a typo ;-) So the basic difference between SM and Universes is that the latter uses a community policy (you "ought" not to put bad things there) right? This sounds reasonable but can we then please drop the silly nonsense about "guaranteed to work together"? If you need a catchy marketing phrase, how about "community tested"? (in the best of all worlds this is just what it would be)
Also, this only seems to emphasize the complementary nature of Universes and SM. If, say, Universes would use SM as their "backend-storage" you could have your cake and eat it too: Sets of community-tested packages that are available for one-click install, and "all code ever written for Squeak" available on SM for historical or porting purposes.
Cheers, - Andreas
Hi!
Andreas Raab andreas.raab@gmx.de wrote:
Also, this only seems to emphasize the complementary nature of Universes and SM. If, say, Universes would use SM as their "backend-storage" you could have your cake and eat it too: Sets of community-tested packages that are available for one-click install, and "all code ever written for Squeak" available on SM for historical or porting purposes.
I have always viewed a Universe to be "more or less" a sub collection (a list really) of specific *releases* of packages that is collectively maintained by a smaller (smaller than the whole Squeak community - and possibly just being a few people) team.
Given that definition I always felt it could be represented by a new co-maintained SM artifact that is simply just such a list. If I an Giovanni (plus hopefully one or two more?) get around doing SM3 then I suspect we would include such a concept.
regards, Göran
On 11/1/07, Andreas Raab andreas.raab@gmx.de wrote:
I figured it was a typo ;-) So the basic difference between SM and Universes is that the latter uses a community policy (you "ought" not to put bad things there) right?
Yep.
This sounds reasonable but can we then please drop the silly nonsense about "guaranteed to work together"?
Fine with me. Anything in software "guaranteed" sounds like propaganda anyway. :)
If you need a catchy marketing phrase, how about "community tested"? (in the best of all worlds this is just what it would be)
Also, this only seems to emphasize the complementary nature of Universes and SM. If, say, Universes would use SM as their "backend-storage" you could have your cake and eat it too: Sets of community-tested packages that are available for one-click install, and "all code ever written for Squeak" available on SM for historical or porting purposes.
With the newer versions of Universes it can do this in fact. SM is one of the sources for a package.
I'm personally looking forward to what Göran has to propose with SM3.
On 11/1/07, Chris Muller ma.chris.m@gmail.com wrote:
SqueakMap supports SAR files, which can do *anything*. Therefore it, too, supports dependencies.
By writing scripts? In this case I think we can do better. I mean, if someone wanted to modify SM to expose some interface for adding dependencies and then implement that interface by creating a script inside the SAR then that's good enough. Just not the ad hoc scripts that are done today that fight with each other and so on.
Having full power is good, but in these cases when a common use case is identified we should "DSL-ize" it imo, and that is basically what you get with the Universes.
And by the way, I got in this thread only in reaction to your earlier comment. I don't want SM to be removed from the standard image either. There are plenty of other things that would be higher priority imo.
To me, the process of building an image is something that always needs to be done with care. A tool that tries to pick "the most recent versions" of prerequisite packages, to me, is "gunslinger" style of building an image.
As explained in another mail, it doesn't do this. If you add a package to a universe, then add an upgraded version of that package to the universe later, of course it picks the most up to date version that you have claimed works.
I suppose you could argue that the act of adding the new version should remove the old one from the universe, but I believe it is there for the "upgrade" functionality.
What exactly does "guaranteed to work together" mean? This is a notion I never really followed about Universes. Does it simply mean what SqueaMap already tells us? That neither of the packages does any modifications to the base image? "Work" has different means for different people depending on the needs. If loading one package causes a slow-down in the performance of the other that matters to me, how can it be said "guaranteed to work?"
It's the same concept as they have with the Debian apt-get system, though obviously there are more people, and therefor more rigor in the Debian system.
By "certiifed" do you mean an assessment of the level of quality? If so, SqueakMap has this too ("Solid as a rock" ... "Full of bugs for developers only).
Doesn't everyone just pick "Full of bugs" so they don't get blamed if it breaks? :)
A given version of Squeak? Yes it does. They all indicate what versions of Squeak they are for, and when you load it you get a warning if your version of Squeak does not match, but still allowing to proceed at your risk.
But the issue is that no one is updating and saying "yes this does work in 3.9/3.10". I have seen plenty of times where I read about some package I should get, it's the latest version, so I go to SM and it says the package is for 3.7.
The "advantage" of Universes is that nothing can be loaded until it's put in the Universe, so no one can tell me to go load some package without setting it up to be in 3.9/etc.
Dear All,
Knowing that the base image is going to get smaller, I thought that we had already established that the release base image is not supposed to be the end user image, but a basis for making published images for end use-cases. Of which squeak-dev is but one example and Edgars promised FunSqueak would be another.
If I am putting together a release image tailored to my needs it becomes difficult if I have to first remove the packages that I dont want. I think that this could improve eventually, but right now, removing is harder than adding. So the image should be distributed as minimally as possible. The whole point of pulling things out of 3.10 is to make it smaller. I think 40 classes is quite a lot, 1% is a lot. Its only 1% because there is so much other stuff still to be removed.
If I am wanting to deploy a minimal image I do not want to duplicate functionality, SqueakMap is duplicate functionality, because Installer can load from squeakmap and Installer is one class!
Ok it may not be the best design or code out there but making it one class was an initial goal for this reason. On the basis that other larger-code would be removed in order to minimize the image footprint, Installer should be small enough to remain in a minimal image while having sufficient functionality to install whatever you might like from whatever source.
cheers
Keith
p.s. The biggest problem with Universes that I see is a social one, rather than a technical one. I think that they need to be in the control of one "body" of maintainers. Either they need to have one master to be in charge, or they need to be open so that the community can perform the role colaboratively. Having different parts of the universe under different control cultures makes it harder to make a coherent story.
Hi!
Keith Hodges keith_hodges@yahoo.co.uk wrote:
If I am wanting to deploy a minimal image I do not want to duplicate functionality, SqueakMap is duplicate functionality, because Installer can load from squeakmap and Installer is one class!
Ok it may not be the best design or code out there but making it one class was an initial goal for this reason. On the basis that other
Note that the reason SM is larger is because you get the full domain model of SM inside your image. This means that you can easily write snippets of code interrogating it, you can use it offline (yes you can) etc etc.
AFAIK Installer (while being a nice concept) operates by web scraping, which is fine BUT it thus "works around" the SM model and does not work offline and does not offer the domain model and does not give you client side caching (?) and does also not have code to use the server side cache (I am guessing).
So even though I like Installer, don't simplify it for people who know less - it is NOT a drop in replacement of the SM code.
But yes, if you WANT to skip all the above parts - then fine, it works.
regards, Göran
goran@krampe.se wrote:
Hi!
Keith Hodges keith_hodges@yahoo.co.uk wrote:
If I am wanting to deploy a minimal image I do not want to duplicate functionality, SqueakMap is duplicate functionality, because Installer can load from squeakmap and Installer is one class!
Ok it may not be the best design or code out there but making it one class was an initial goal for this reason. On the basis that other
Note that the reason SM is larger is because you get the full domain model of SM inside your image.
indeed.
This means that you can easily write snippets of code interrogating it,
Installer search: 'Author:Bob'.
you can use it offline (yes you can) etc etc.
AFAIK Installer (while being a nice concept) operates by web scraping,
indeed it does if SM is not loaded.
which is fine BUT it thus "works around" the SM model and does not work offline and does not offer the domain model and does not give you client side caching (?) and does also not have code to use the server side
No client side caching indeed, but for building an image for distribution I am not going to distribute the cache.
I am not saying whether or not SM should be given to end users for all of these great features. I personally think that SM should be in the standard distribution.
I am talking specifically about the minimal image that is the stated deliverable of 3.10. The image from which you can build images for specific domains. Should this image have SM in it or not? Actually it shouldn't have universes either, since universes can be loaded from SqueakMap.
Monticello can go. SUnit-GUI can go too.
Then we might have the actual possibility if loading what we want to load.
For example choosing Monticello 1.5 is actually hindered by the fact that Monticello is already present in the "3.10 release" image. I have to jump through hoops in the Universes release of MC1.5 in order to overwrite MC1.0.
(The update stream should use Installer to load its Monticello packages in case Monticello is not present)
cache (I am guessing). So even though I like Installer, don't simplify it for people who know less - it is NOT a drop in replacement of the SM code.
But it is capable of bootstrapping a minimum image into the form you want, and many developers will want SM.
For deployment I am happy to build from an Installer script without Universes or SM.
But yes, if you WANT to skip all the above parts - then fine, it works.
regards, Göran
If I want those parts it is only one line away...
Installer wsm install: 'SqueakMap'.
all the best
Keith
Hi!
Keith Hodges keith_hodges@yahoo.co.uk wrote: [SNIP of all good points]
Yes, I agree with everything you said. :)
regards, Göran
On 11/1/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 11/1/07, Chris Muller ma.chris.m@gmail.com wrote:
SqueakMap supports SAR files, which can do *anything*. Therefore it, too, supports dependencies.
By writing scripts? In this case I think we can do better. I mean, if someone wanted to modify SM to expose some interface for adding dependencies and then implement that interface by creating a script inside the SAR then that's good enough. Just not the ad hoc scripts that are done today that fight with each other and so on.
C'mon Jason, I did that a long time ago. I just added a button to Monticello Configurations browser called, "Build SAR". It makes a one-click self-installing SAR.
It took all of about one hour to implement, and I knew nothing about Monticello beforehand (still don't).
As explained in another mail, it doesn't do this. If you add a package to a universe, then add an upgraded version of that package to the universe later, of course it picks the most up to date version that you have claimed works.
So if it's always picking "the most up to date" branches are unsupported then? If so, how is this "better"?
I suppose you could argue that the act of adding the new version should remove the old one from the universe, but I believe it is there for the "upgrade" functionality.
Monticello already supports "upgrade". I see nothing new here.
What exactly does "guaranteed to work together" mean? ... how can it be said "guaranteed to work?"
It's the same concept as they have with the Debian apt-get system,
I'm not familiar with that, so that doesn't mean anything to me.
By "certiifed" do you mean an assessment of the level of quality? If so, SqueakMap has this too ("Solid as a rock" ... "Full of bugs for developers only).
Doesn't everyone just pick "Full of bugs" so they don't get blamed if it breaks? :)
I don't. That seems like a pretty chicken-shit thing to do. That has little to do with the (SqueakMap) technology anyway? No software can stop GIGO.
A given version of Squeak? Yes it does. They all indicate what versions of Squeak they are for, and when you load it you get a warning if your version of Squeak does not match, but still allowing to proceed at your risk.
But the issue is that no one is updating and saying "yes this does work in 3.9/3.10". I have seen plenty of times where I read about some package I should get, it's the latest version, so I go to SM and it says the package is for 3.7.
How can it be updated if no one has tried it? The fact that it is not updated every time a new Squeak comes out is USEFUL because it means it hasn't been tested.
Again, I ask you to define the meaning of "works". This is a non-issue.
The "advantage" of Universes is that nothing can be loaded until it's put in the Universe, so no one can tell me to go load some package without setting it up to be in 3.9/etc.
Sounds like the computer controlling the user. I only believe in the opposite.
It sounds like great legacy stuff like MorphicWrappers will never be
Ok, so for MorphicWrappers and other great stuff available on SqueakMap, "Universes can't do it". Fine. I won't be using it.
El 11/2/07 11:37 AM, "Chris Muller" ma.chris.m@gmail.com escribió:
It sounds like great legacy stuff like MorphicWrappers will never be
MorphicWrappers and MathMorphs works on 3.10, Milan Zimmermann and I port to 3.9. Is on SqueakSource and in FunSqueak 3.10. When I complete redoing 3.10.1 (the blue pill) I publish new FunSqueak.
I hope next Smalltalks 2007 - Primer Congreso Argentino de Smalltalk I could meet Leandro Caniglia and some others original workers,
Edgar
It sounds like your mind is already made up on this, so I wont bother replying anymore except one comment below.
On 11/2/07, Chris Muller ma.chris.m@gmail.com wrote:
Doesn't everyone just pick "Full of bugs" so they don't get blamed if it breaks? :)
I don't. That seems like a pretty chicken-shit thing to do. That has little to do with the (SqueakMap) technology anyway? No software can stop GIGO.
Notice the smile? I wasn't pointing this out as a critical flaw. It was half a joke, and half just to point out that the field doesn't really mean that much in my experience.
chris
the intention being universes is to have a kind of certified release which is really valuable. Since lot of squeakmap packages do not indicate really if they work on not in a given version.
Stef
On 31 oct. 07, at 02:22, Chris Muller wrote:
And for the last time, you should use Universes. If your wished code is not in Universes, means author is not active this days. SqueakMap was a very valuable tool, like any good library is. But don't guaranties of code in SM works in 3.10, if not say so. And if say works , must be in Universes.
Edgar, you are sounding way too tyrannical here. As the developer of the "next Squeak" please find the idea of "software freedom" in your heart asap. Help people integrate what they need and want, don't tell them they're wrong for wanting something you don't care about.
And for the last time...
I truly hope this *is* the last time we hear something so ridiculous from you. There are many avid Squeakers who do not use Universes. I happen to be one of them. SqueakMap is a great Squeak legacy and allows stuff to be loaded into a clean image. Universes, to me, sounds a bit misguided, and far from making rendering SqueakMap obsolete.
Thanks.
On 10/28/07, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
El 10/27/07 2:05 PM, "Matthew Fulmer" tapplek@gmail.com escribió:
One problem I have seen with SqueakMap in 7158 came from change 7142.
Nope. I repeat recipe I give a month ago.
Some verbose , but clear how to rid of old versions files disturbing normal 3.10 peace.
| directoryName directory filesToErase | directoryName := (FileDirectory default pathName ,FileDirectory slash, 'sm'). directory := FileDirectory on: directoryName. filesToErase := directory fileNamesMatching: '*.sgz'. filesToErase do:[:filename| directory deleteFileNamed: filename]
And the answer why fail is Goran use ImageSegments (he have many to me to learn) and the classes in 3.9 or earlier was different.
That's why many .pr fails to load
Hope this helps.
Edgar
I am sticking with image version 7137 until I or someone else resolve the bugs introduced in 7142.
You could use any Squeak you like. I was the guilty of trust Dan and someone which do the change before me and I decide doing for 3.10 The bad news is 98% of 172 methods Dan code change are right and only a few need ==. I send proposal how to deal with this, but still no decision.
And for the last time, you should use Universes. If your wished code is not in Universes, means author is not active this days. SqueakMap was a very valuable tool, like any good library is. But don't guaranties of code in SM works in 3.10, if not say so. And if say works , must be in Universes.
Edgar
El 10/30/07 10:22 PM, "Chris Muller" asqueaker@gmail.com escribió:
Edgar, you are sounding way too tyrannical here. As the developer of
the
"next Squeak" please find the idea of "software freedom" in your
heart asap.
Help people integrate what they need and want, don't tell
them they're wrong
for wanting something you don't care about.
And for the last time...
I
truly hope this *is* the last time we hear something so ridiculous
from you.
There are many avid Squeakers who do not use Universes. I
happen to be one of
them. SqueakMap is a great Squeak legacy and
allows stuff to be loaded into a
clean image. Universes, to me,
sounds a bit misguided, and far from making
rendering SqueakMap
obsolete.
I never said SquekMap is obsolete or you don't could use it.
The question is :
People want a smaller image (less packages in base) as we have now ? And this smaller image could load any Squeak code from past and future ?
If the answer is not, people should download ready to use images , like the excellent of Damien for 3.10. Or 3.8.2 full if this suits his needs.
If the answer is yes, people should encourage guys trying to reach this. Meaning some sacrifices are needed.
Today you could use SqueakMap , Universes , Installer and Monticello as ways to load code into 3.10.
I hope in futures Squeak you don't have any (image could don't have this 4 packages) .
And still you should have a way to load again one or all this plus any you wish.
In the distant future, Squeak become Spoon, all you need is type "I want mp3" for cite some people request recently and not more into 3.10.
And this NeXtqueak could intellingent load any needed code.
Like my vision ?
Edgar
Hi,
People want a smaller image (less packages in base) as we have now ? And this smaller image could load any Squeak code from past and future ?
Yes, this is a good vision. But the base 3.9 Squeak has 4077 classes, of which 40, 40!, are for SqueakMap. This is less than 1%.
So, what do we pay for that 1% savings in number of classes in the image? SqueakMap.
This is not a bargain! There are many old packages which are not present on Universes which have a chance of resurrection if they are visible.
If the answer is not, people should download ready to use images , like the excellent of Damien for 3.10.
Oh, does Damiens 3.10 have SqueakMap ready to go? If so, he should be able to help you get into the standard 3.10.
Or 3.8.2 full if this suits his needs.
But that's not 3.10,which is what we're talking about. There are those of us who want the *possibility* of benefitting from all of your hard work.
If the answer is yes, people should encourage guys trying to reach this. Meaning some sacrifices are needed.
I do encourage you, but the whole point of a tiny image is to be able to build it to what I need. SqueakMap, for the cost of a mere 40 classes, gives me the ability to take my image in 100 million additional directions than I could/would with ONLY Universes.
So it's more than worth it. Purge other stuff, leave SqueakMap for now.
Today you could use SqueakMap , Universes , Installer and Monticello as ways to load code into 3.10.
The code-loading tools should all be included *standard* in the 3.10 image. Purge other stuff if you need smaller.
I hope in futures Squeak you don't have any (image could don't have this 4 packages) .
Absolutely. To me this is the Spoon dream.
In the distant future, Squeak become Spoon, all you need is type "I want mp3" for cite some people request recently and not more into 3.10.
We're together man. Just disagreeing about *this point in time* of evolution for Squeak. I think it's too early to purge SqueakMap from the standard image.
- Chris
Hi edgar
can you explain exactly what you did because this is totally opaque to me? It is amazing that lot of changes in squeak 3.10 were not advertise and got feedback from the community.
I am sticking with image version 7137 until I or someone else resolve the bugs introduced in 7142.
You could use any Squeak you like.
no this is not a good answer.
I was the guilty of trust Dan and someone which do the change before me and I decide doing for 3.10 The bad news is 98% of 172 methods Dan code change are right and only a few need ==. I send proposal how to deal with this, but still no decision.
And for the last time, you should use Universes. If your wished code is not in Universes, means author is not active this days. SqueakMap was a very valuable tool, like any good library is. But don't guaranties of code in SM works in 3.10, if not say so. And if say works , must be in Universes.
Edgar
El 10/31/07 6:22 AM, "stephane ducasse" stephane.ducasse@free.fr escribió:
Hi edgar
can you explain exactly what you did because this is totally opaque to me? It is amazing that lot of changes in squeak 3.10 were not advertise and got feedback from the community.
I think you was in the 3dot10 list.
I am sticking with image version 7137 until I or someone else resolve the bugs introduced in 7142.
If you mean this is http://bugs.squeak.org/view.php?id=2788 and have a long history. The short story is my work around to have the 172 methods the Dan fix touch don't change the timestamp showing I mess some. And the fix is only 98% correct, meaning sometimes we need == anyway as Jerome and others discover. I send proposals to how to deal with this, none was choose to this day.
SqueakMap troubles was no related to this or any other 3.10 bug. Is related , as I said in before mail to ImageSegments Goran use to store the map in user computer. My trick rip all old files and lets SqueakMap works as ever.
I like SqueakMap, admire any Goran do and hope one day I could learn some from he. If I itching people trying to realize Squeak should move the smaller images ways, sorry gus, is how I see the future.
Maybe some have the new CrystalBall Leopard compatible ? :=)
Edgar
On 10/31/07, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
I send proposals to how to deal with this, none was choose to this day.
I thought we had decided that you would take out those changes, and that other people would gradually reintroduce them, after they had looked at the changes and decided that they were correct.
-Ralph
did you report this bug?
Stef
On 27 oct. 07, at 19:05, Matthew Fulmer wrote:
On Thu, Oct 25, 2007 at 04:31:55PM +0200, Trygve Reenskaug wrote:
I suppose I have missed something, the question is what?
The VM crashes when I try to install BabySRE-TRee39 package from SqueakMap. The VM also crashes when I try to install Balloon3D 1.0.4 package from SqueakMap.
OS: WinXP version 5.1, SP 2 Image: Squeak3.10beta.7158 VM: SqueakVM-3.10.6
What's wrong?
One problem I have seen with SqueakMap in 7158 came from change 7142. Some code in DataStream, which is used to read the ImageSegments used by SqueakMap was broken by replacing several object identity comparisons with equality. I have not seen a crash, but I would suspect the problems are related. For this reason, I am sticking with image version 7137 until I or someone else resolve the bugs introduced in 7142.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Brian Brown -
Chris Muller -
Chris Muller -
David T. Lewis -
Edgar J. De Cleene -
Giovanni Corriga -
goran＠krampe.se -
Göran Krampe
-
Jason Johnson -
karl -
Keith Hodges -
Lex Spoon -
Matthew Fulmer -
Norbert Hartl -
Ralph Johnson -
stephane ducasse -
Trygve Reenskaug