The absence of something like STORE/CPAN that is what is driving me towards CST.
The existence of CPAN is keeping me with Perl ;)
The existence of sake/packages to enable me to consistently build and debug the building of the production image that I want is helping to keep me sane! (after attempting to achieve what I needed with Universes drove me mad for a couple of weeks)
The last thing we need is yet another package management system, when we have hardly started using the features of the existing ones.
I do not think there is need for another package management system, I just think that there should be an agreement on using and expanding _one_, incorporating what is best about all the others. I realize that means stepping on many, many toes and legs and probably even heads, but I think things need to be streamlined a bit.
If push comes to shove, I would even say, lets ditch them all and just use SVN like the rest of the planet (if that is possible). It is hard enough to sell a image-based language with a real IDE to the C-style crowd, the package management systems should not add their grain of salt to the soup.
On 28-Jun-08, at 5:27 AM, Claus Kick wrote:
If push comes to shove, I would even say, lets ditch them all and just use SVN like the rest of the planet (if that is possible). It is hard enough to sell a image-based language with a real IDE to the C-style crowd, the package management systems should not add their grain of salt to the soup.
Been there, done that... <shudder/>
Monticello was created because this turned out not to be feasible in practice. The simple fact is that Smalltalk *is* image based, and that's a feature, not a bug. For those who can't accept that, there's Ruby.
Colin
Colin Putney wrote:
On 28-Jun-08, at 5:27 AM, Claus Kick wrote:
If push comes to shove, I would even say, lets ditch them all and just use SVN like the rest of the planet (if that is possible). It is hard enough to sell a image-based language with a real IDE to the C-style crowd, the package management systems should not add their grain of salt to the soup.
Been there, done that... <shudder/>
Monticello was created because this turned out not to be feasible in practice.
Can you say something more about that? A couple of weeks ago I saw a demo at HPI in Potsdam where students used SVN down to the method level, and it seemed to me that this approach might very well work because the SVN granularity is the same as the in-image granularity. It may also be interesting that this wasn't even trying to deal with source files of any sort - it retained the nature of the image and simply hooked it up directly with SVN. From my perspective this looked like an extraordinarily interesting approach that I am certain to try out as soon as it is available.
Cheers, - Andreas
Am 28.06.2008 um 21:45 schrieb Andreas Raab:
Colin Putney wrote:
On 28-Jun-08, at 5:27 AM, Claus Kick wrote:
If push comes to shove, I would even say, lets ditch them all and just use SVN like the rest of the planet (if that is possible). It is hard enough to sell a image-based language with a real IDE to the C-style crowd, the package management systems should not add their grain of salt to the soup.
Been there, done that... <shudder/> Monticello was created because this turned out not to be feasible in practice.
Can you say something more about that? A couple of weeks ago I saw a demo at HPI in Potsdam where students used SVN down to the method level, and it seemed to me that this approach might very well work because the SVN granularity is the same as the in-image granularity. It may also be interesting that this wasn't even trying to deal with source files of any sort - it retained the nature of the image and simply hooked it up directly with SVN. From my perspective this looked like an extraordinarily interesting approach that I am certain to try out as soon as it is available.
Do you think it would be feasible to exclusively manage an image from SVN sources?
The reason I'm asking is related to the "image" problem I reported earlier, the Linux folks demand the image to be to bootstrapped from sources + media files. Which IMHO would be a major re-engineering effort. E.g.,
http://lists.laptop.org/pipermail/devel/2008-June/015868.html
which is even one of the nicer emails in the thread, there were openly hostile posts, too.
- Bert -
On Sun, Jun 29, 2008 at 01:02:59AM +0200, Bert Freudenberg wrote:
Do you think it would be feasible to exclusively manage an image from SVN sources?
The reason I'm asking is related to the "image" problem I reported earlier, the Linux folks demand the image to be to bootstrapped from sources + media files. Which IMHO would be a major re-engineering effort. E.g.,
Well, it's not a great fit with Squeak, but Smalltalk/X has always worked this way (and probably Gnu Smalltalk too), so clearly it's possible.
But frankly I suspect that a good old fashioned update stream with human-readable change sets applied to some known base system would address most of the perceived problem. If the base system consists of sources plus "media" (a well-recognized image of known heritage), then everything applied subsequently is easily traced, and can be reapplied by anyone interested in doing so.
I would also note that those annoying Linux folks might just have a point here. If we had followed these guidelines consistently over the last few years, we would not have ended up with the mess of lost author initials, untraceable changes, and unidentified licensing that we are faced with today.
I think that Edgar has talked about trying to rebuild Squeak 3.9/10 from changes on top of a solid 3.8 image. I think he has the right idea: fully traceable sources, all in plain text, and easily rebuilt from a known base system. The 3.8 image itself was built from update streams all the way back to an image of known heritage and license status. Really, this is not a bad state of affairs.
Dave
El 6/28/08 11:43 PM, "David T. Lewis" lewis@mail.msen.com escribió:
I think that Edgar has talked about trying to rebuild Squeak 3.9/10 from changes on top of a solid 3.8 image. I think he has the right idea: fully traceable sources, all in plain text, and easily rebuilt from a known base system. The 3.8 image itself was built from update streams all the way back to an image of known heritage and license status. Really, this is not a bad state of affairs.
Dave
Thanks Dave.
Also I wish have a "Class repository" for ages. See what I got from 3.8 in 2005
ftp://squeakros.atspace.com/squeakros.atspace.com/CompressedClasses/
password is squeak
I just build SqueakLightII aka Unofficial 3.11. I plan to have the same thing here.
Its 3.9 with more packages going to live outside the image. About 1400 clases, 2/3 size normal 3.10 All the way until 3.10 is with the same we do in Ralph era, but in easy to follow .cs form.
The image could be updated hitting the load updates of Squeak flap or doing Utilites slUpdates from Workspace.
At the moment you should reach 7183 with one error when image try to load the Matthew version of Monticello 1.6 beta. Close the error and repeat the loading and then save as 7183
I add a page on swiki, all could put any you wish
http://wiki.squeak.org/squeak/6056
And a couple of ready to run
In a Workspace,
|sourceFile | sourceFile := HTTPLoader default retrieveContentsFor: 'http://wiki.squeak.org/squeak/uploads/6056/LightWeb.sar'. sourceFile := RWBinaryOrTextStream with: (sourceFile content). SARInstaller new fileInFrom: sourceFile
|sourceFile | sourceFile := HTTPLoader default retrieveContentsFor: 'http://wiki.squeak.org/squeak/uploads/6056/ SqueakRosDev3dot10.sar'. sourceFile := RWBinaryOrTextStream with: (sourceFile content). SARInstaller new fileInFrom: sourceFile
Not to bad having a server and web page builder and a development set for a pre-alpha ...
Help and we could have a polished system ready for ESUG or Smalltalks 2008
Also at the moment I development crude tools for analyze all in 3.10 Universes, the first output I send to "Discussion about development of Squeak 3.10" v3dot10@lists.squeakfoundation.org
As seems Colin finished Monticello2, I wish try it if someone say the files I should load from http://source.wiresong.ca/mc/
Edgar
I would also note that those annoying Linux folks might just have a point here. If we had followed these guidelines consistently over the last few years, we would not have ended up with the mess of lost author initials, untraceable changes, and unidentified licensing that we are faced with today.
At least this time around, the licencing part isn't question. We are making progress^^;
BTW, there was a discussion about a month ago (I basically read them just recently), and Bert was asking that how hard it is to do bootstrap from source. I know many of you have thought about the actual bootstrapping. That would go something like:
- Write a compiler in another language. That can generates the bits that are same as CompiledMethods. For a class definition, it creates (yes) the network of pointers.
- The compiler sticks the class definitions, method dictionaries, subclass structure, and compiled methods into a big "int*" array. The goal is to make that something just run, so for example, the stuff managed by ClassDescription (instanceVariable names and organization) don't have to be compiled. Stuff like the source pointer is not needed at this stage.
- There should be a support for IdentityDictionary, Array, Symbol and String. and for the latter two, a way to create instances would be needed. SystemDictionary and Undeclared would be the instances of IdentityDictionary that should be created and gets into the int* array. The symbol table that manages the instances of Symbol is needed during the compilation, but it probably doesn't have to go into the int* array, as we can recreate it in the next initialization stage.
- During the compilation, we may have some garbage, but of course we just leave them in the int* array. A class may get many subclasses. The subclasses array of the class may be assigned many times, but we just cr
- In this senario, nil, true, false aren't needed, I believe (as CompiledMethods don't hold onto them). However, it would be nice to "create" them early and store in the int* array.
- A few more necessary instances that go to special objects array is created. Perhaps only Processor and active context would be needed.
- The int* array is saved into a file with the header.
- Now launch the image with a regular VM. The active context goes over a list of classes and initialize them.
- Compile all sources again so that they get proper source pointer. (Or, scan the sources and set the source pointers properly).
- Create a project, enter and save the image normally.
- Load more code. and keep it going.
How feasible is it to do? Or, do somebody have some idea that how many contexts would we need to create "manually"? What other instances are needed? How much code rewriting would be necessary?
Yes, there are other ways of doing it. For example, if we make the kernel part is fairly small (like 500k), we can have a program that holds onto the bytes as constant and write out to disk. This would be enough to persuade these people. We can load all the rest onto it later. (But if this is the case, I'd ask myself that if 300k is ok why not 20MB? That was the artificial distinction Andreas mentioned, I believe.)
-- Yoshiki
Pavel Krivanek http://www.comtalk.eu/Squeak/98
On Sun, Jun 29, 2008 at 4:09 AM, Yoshiki Ohshima yoshiki@vpri.org wrote:
Write a compiler in another language. That can generates the bits that are same as CompiledMethods. For a class definition, it creates (yes) the network of pointers.
The compiler sticks the class definitions, method dictionaries, subclass structure, and compiled methods into a big "int*" array. The goal is to make that something just run, so for example, the stuff managed by ClassDescription (instanceVariable names and organization) don't have to be compiled. Stuff like the source pointer is not needed at this stage.
The compiler doesn't have to be in another language. What is important is that the compiler builds a Squeak image from a text file. The compiler can be written in Smalltalk as long as it uses only the class definitions in the test file, not in the compiler's image.
In face, it would be possible to reuse the existing compiler to build up a standard structure of classes in the image, but to put them all in their own namespace. Thus, an Object class defined in the test file would not be the same as the Object class used in the compiler. Thus, a system that bootstraps images from text files could first read the text file and produce a set of classes in the image, and then write out an image that contains only those classes.
Pavel Krivanek's KernelImage does the second part, but not the first. It creates a parallel class hierarchy by copying part of the existing classes, then it writes out an image that contains only those classes.
So, I think you could make a bootstrapping compiler by hacking the existing compiler to read in a regular .st file into a separate namespace. Then you'd use KernelImage to write out the image. The system would have to make sure that instances of String, CompilerMethod, etc., pointed to the new classes and not the old, but KernelImage has to do something like this already.
Given KernelImage, I don't think that the compiler is all that hard to write. The hard part would be making the text file of all the classes. If I were doing this, I'd hack KernelImage to create the text file for me, so I could at least create something similar to KernelImage.
-Ralph Johnson
On 29-Jun-08, at 5:31 AM, Ralph Johnson wrote:
In face, it would be possible to reuse the existing compiler to build up a standard structure of classes in the image, but to put them all in their own namespace. Thus, an Object class defined in the test file would not be the same as the Object class used in the compiler. Thus, a system that bootstraps images from text files could first read the text file and produce a set of classes in the image, and then write out an image that contains only those classes.
Pavel Krivanek's KernelImage does the second part, but not the first. It creates a parallel class hierarchy by copying part of the existing classes, then it writes out an image that contains only those classes.
Alejandro Reimondo's Fenix stuff read (through some extraordinarily 'creative' and Windows dependant code) source snippets from files and built a parallel object hierarchy and then wrote an image out via a modified tracer. It's a very simple idea but rather less simple to implement correctly. It is however certainly doable.
In principle one could certainly keep a tree of SVN like form, read in the code whilst traversing the tree, create objects to suit and then trace only those objects to create an 'image created from source'.
And you know what? If we put together a system to do that, there would still be objectors; there will always be objectors.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Base 8 is just like base 10, if you are missing two fingers.
tim Rowledge wrote:
And you know what? If we put together a system to do that, there would still be objectors; there will always be objectors.
If you can't edit it in emacs, it's not OpenSource. At least that seems to be the acid test for some people...
So unless we support the four step magic dance ritual - edit in emacs - make config - make - make install we're out by default. After that probably because it's not Python...
Michael
Hi Michael,
On Sun, Jun 29, 2008 at 6:22 PM, Michael Rueger m.rueger@acm.org wrote:
After that probably because it's not Python...
ha! http://pypysqueak.blogspot.com/
scnr,
Michael
tim Rowledge a écrit :
Alejandro Reimondo's Fenix stuff read (through some extraordinarily 'creative' and Windows dependant code) source snippets from files and built a parallel object hierarchy and then wrote an image out via a modified tracer. It's a very simple idea but rather less simple to implement correctly. It is however certainly doable.
In principle one could certainly keep a tree of SVN like form, read in the code whilst traversing the tree, create objects to suit and then trace only those objects to create an 'image created from source'.
And you know what? If we put together a system to do that, there would still be objectors; there will always be objectors.
tim
This is the idea of replacing a "binary blob" (the image) with an automatically generated "textual blob" (a textual description of the object graph, or a script to reconstruct object graph).
Is it usable? A maintainer will use diff tools to check difference between two versions. Unfortunately, a small difference in an Object graph (think graph, not tree) might result in a big difference in textual representation. Such generator should take care to generate minimal textual diffs... That means diffing two general graph, analyzing previous textual representation and producing a textual representation closest to previous one.
What a maintainer would need, is rather a new diff tool able to perform above operation, find the diffs between two images...
A tool that analyzes a foreign image and generates a script able to convert this image to the foreign one...
Not simple, a naive implementation would not work, for example because of sourcePointers, an image is not independant form it's change files...
Nicolas
On Sun, Jun 29, 2008 at 1:35 PM, nicolas cellier ncellier@ifrance.com wrote:
This is the idea of replacing a "binary blob" (the image) with an automatically generated "textual blob" (a textual description of the object graph, or a script to reconstruct object graph).
Is it usable? A maintainer will use diff tools to check difference between two versions. Unfortunately, a small difference in an Object graph (think graph, not tree) might result in a big difference in textual representation. Such generator should take care to generate minimal textual diffs... That means diffing two general graph, analyzing previous textual representation and producing a textual representation closest to previous one.
What a maintainer would need, is rather a new diff tool able to perform above operation, find the diffs between two images...
A tool that analyzes a foreign image and generates a script able to convert this image to the foreign one...
Not simple, a naive implementation would not work, for example because of sourcePointers, an image is not independant form it's change files...
Not simple at all! I know this isn't exactly the same as what you are talking about, but I saw some presentations at Smalltalk Solutions dealing with file-based code storage and/or analysis:
http://www.stic.st/stic?content=sts08Detail#june18Detail
Using VisualWorks Store for GemStone Code Management
Porting experience report
Smalltalk Development Tools: Bringing Smalltalk to Eclipse
I think the consensus was "it's hard!"
Rob
At Sun, 29 Jun 2008 07:31:26 -0500, Ralph Johnson wrote:
Pavel Krivanek http://www.comtalk.eu/Squeak/98
On Sun, Jun 29, 2008 at 4:09 AM, Yoshiki Ohshima yoshiki@vpri.org wrote:
Write a compiler in another language. That can generates the bits that are same as CompiledMethods. For a class definition, it creates (yes) the network of pointers.
The compiler sticks the class definitions, method dictionaries, subclass structure, and compiled methods into a big "int*" array. The goal is to make that something just run, so for example, the stuff managed by ClassDescription (instanceVariable names and organization) don't have to be compiled. Stuff like the source pointer is not needed at this stage.
The compiler doesn't have to be in another language. What is important is that the compiler builds a Squeak image from a text file. The compiler can be written in Smalltalk as long as it uses only the class definitions in the test file, not in the compiler's image.
This is more or less settled but...
If the compiler is written in Smalltalk, we would have a binary image to store the compiler; and some people wouldn't like it. Nonetheless, it can be in Slang and we can just show the translated C code as if it is the "egg".
-- Yoshiki
On Sunday 29 Jun 2008 2:39:42 pm Yoshiki Ohshima wrote:
BTW, there was a discussion about a month ago (I basically read them just recently), and Bert was asking that how hard it is to do bootstrap from source. I know many of you have thought about the actual bootstrapping.
The OOPSLA Squeak paper refers to "Design a new ObjectMemory and image file format". Were these design notes ever published anywhere? They could be included in Squeak package along with the description of chunk file format used for sources and changes.
Subbu
What Linux people proposing looks controversial to me.
Why, bits which was written in early '80 and then forgotten because they don't needed anymore now become important? :) A proposal sounds like: lets forget what we're done in last decades and start it over again. Just because of what? Smalltalk image is a living system. Try load and save new version of image. We could say, its the same image. But we all know, that many objects and states within newly saved image will be different to original image. So how you suppose to convince linux-people that given image is a product of creating from text sources? After few iterations (loading/saving and loading new code) it can be nearly impossible to clearly state that.
On Mon, Jun 30, 2008 at 5:54 AM, Igor Stasenko siguctua@gmail.com wrote:
What Linux people proposing looks controversial to me.
Well, being able to redo the bootstrap from scratch or just to edit an image from a separate tool would also make it simpler to throw stuff away and get *really* minimal image for special purposes. You could generate an image with just kernel plus application code, no UI, no compiler, no reflective stuff...
What Linux people proposing looks controversial to me.
The attitude toward Etoys/Squeak vary widely among *them*, also. Fortunately, the guys who are viciously bashing Etoys on the OLPC devel list aren't the guys who make decisions there. Hopefully a bit by bit, we can make some progress. That thread is great for these decision makers because it is yet another example of how not to discuss stuff^^;
-- Yoshiki
Am 29.06.2008 um 04:43 schrieb David T. Lewis:
On Sun, Jun 29, 2008 at 01:02:59AM +0200, Bert Freudenberg wrote:
Do you think it would be feasible to exclusively manage an image from SVN sources?
The reason I'm asking is related to the "image" problem I reported earlier, the Linux folks demand the image to be to bootstrapped from sources + media files. Which IMHO would be a major re-engineering effort. E.g.,
Well, it's not a great fit with Squeak, but Smalltalk/X has always worked this way (and probably Gnu Smalltalk too), so clearly it's possible.
But frankly I suspect that a good old fashioned update stream with human-readable change sets applied to some known base system would address most of the perceived problem.
No it would not. The main issue for them is that you have to start from what they perceive as "binary blob" which is monkey-patched into newer versions.
- Bert -
If the base system consists of sources plus "media" (a well-recognized image of known heritage), then everything applied subsequently is easily traced, and can be reapplied by anyone interested in doing so.
I would also note that those annoying Linux folks might just have a point here. If we had followed these guidelines consistently over the last few years, we would not have ended up with the mess of lost author initials, untraceable changes, and unidentified licensing that we are faced with today.
I think that Edgar has talked about trying to rebuild Squeak 3.9/10 from changes on top of a solid 3.8 image. I think he has the right idea: fully traceable sources, all in plain text, and easily rebuilt from a known base system. The 3.8 image itself was built from update streams all the way back to an image of known heritage and license status. Really, this is not a bad state of affairs.
Dave
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> No it would not. The main issue for them is that you have to start from what Bert> they perceive as "binary blob" which is monkey-patched into newer versions.
The C compiler would fit the same definition, by that reasoning.
At some point, you have toggle switches. Everything after that is binary blobs building other binary blobs. Do they really need us to trace it back to toggle switches?
Am 29.06.2008 um 16:51 schrieb Randal L. Schwartz:
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> No it would not. The main issue for them is that you have to start from what Bert> they perceive as "binary blob" which is monkey-patched into newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler from text sources only, it does not clone itself.
This is also the difference between using SystemTracer to clone an image into a new format vs. what Ralph suggested, using an image to assemble a new image from scratch, containing only an explicitly defined set of objects.
- Bert -
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> No. You need a C compiler, true, but it builds the next C compiler from text Bert> sources only, it does not clone itself.
Bert> This is also the difference between using SystemTracer to clone an image Bert> into a new format vs. what Ralph suggested, using an image to assemble a Bert> new image from scratch, containing only an explicitly defined set of Bert> objects.
Sorry, I was inadvertently confusing what Ralph suggested (which seems like the C compiler technique) with the objection to the SystemTracer.
At Sun, 29 Jun 2008 18:48:01 +0200, Bert Freudenberg wrote:
Am 29.06.2008 um 16:51 schrieb Randal L. Schwartz:
> "Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> No it would not. The main issue for them is that you have to start from what Bert> they perceive as "binary blob" which is monkey-patched into newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler from text sources only, it does not clone itself.
Come to think of it, we don't have to write the bootstrapper in another language. They already accept Squeak VM, so we can write the Smalltalk-to-CompiledMethod compiler in Slang (even better; write it in OMeta and generate Slang), and generate a modified VM that has different main(). That main() reads the "source" files, compile them (by using the memory management in ObjectMemory), and write the result to file. (Yes, you need a C compiler^^;)
Isn't it sound a bit more doable?
-- Yoshiki
Am 29.06.2008 um 20:08 schrieb Yoshiki Ohshima:
At Sun, 29 Jun 2008 18:48:01 +0200, Bert Freudenberg wrote:
Am 29.06.2008 um 16:51 schrieb Randal L. Schwartz:
>> "Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> No it would not. The main issue for them is that you have to start from what Bert> they perceive as "binary blob" which is monkey-patched into newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler from text sources only, it does not clone itself.
Come to think of it, we don't have to write the bootstrapper in another language. They already accept Squeak VM, so we can write the Smalltalk-to-CompiledMethod compiler in Slang (even better; write it in OMeta and generate Slang), and generate a modified VM that has different main(). That main() reads the "source" files, compile them (by using the memory management in ObjectMemory), and write the result to file. (Yes, you need a C compiler^^;)
Isn't it sound a bit more doable?
A bit. But I suspect getting classes and methods assembled into an image is not even half the work. We'll have to create objects, too, that were manually assembled (I'm thinking of the PaintBox prototype for example). Recreating a full Etoys image would still be a major effort, since many parts would have to be rewritten to actually be bootstrappable.
- Bert -
At Sun, 29 Jun 2008 20:27:33 +0200, Bert Freudenberg wrote:
Am 29.06.2008 um 20:08 schrieb Yoshiki Ohshima:
At Sun, 29 Jun 2008 18:48:01 +0200, Bert Freudenberg wrote:
Am 29.06.2008 um 16:51 schrieb Randal L. Schwartz:
>>> "Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> No it would not. The main issue for them is that you have to start from what Bert> they perceive as "binary blob" which is monkey-patched into newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler from text sources only, it does not clone itself.
Come to think of it, we don't have to write the bootstrapper in another language. They already accept Squeak VM, so we can write the Smalltalk-to-CompiledMethod compiler in Slang (even better; write it in OMeta and generate Slang), and generate a modified VM that has different main(). That main() reads the "source" files, compile them (by using the memory management in ObjectMemory), and write the result to file. (Yes, you need a C compiler^^;)
Isn't it sound a bit more doable?
A bit. But I suspect getting classes and methods assembled into an image is not even half the work. We'll have to create objects, too, that were manually assembled (I'm thinking of the PaintBox prototype for example). Recreating a full Etoys image would still be a major effort, since many parts would have to be rewritten to actually be bootstrappable.
Certainly, the PaintBox is one of the worst examples! The basic part may be able to "take off", but yes, there are stuff build around.
It sounds like I'm not going to do it (of course)...
-- Yoshiki
Bert Freudenberg wrote:
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler from text sources only, it does not clone itself.
Jim Gettys pointed out Ken Thompson's "Trusting trust" paper when this thread was started in the olpc/education lists:
http://cm.bell-labs.com/who/ken/trust.html
Even though you carefully examine the sources for the next version of the C compiler, you can't know for sure what the current binary of the C compiler will do with them. It can insert code not seen in the sources.
The solution is to use more than one C compiler. User your current gcc binary to compile the sources for lcc. Then use the resulting binary to compile the sources for gcc. A Thompson-style Trojan that can handle this situation is still possible, but exponentially more complex than one designed for a single set of sources.
One equivalent in Squeak would be to have image manipulation tools written in some other language, but a simpler alternative would be to port the Smalltalk based tools we are already using to VisualWorks or (better yet) GNU Smalltalk. But since I don't see anyone bothering to do the gcc->lcc->gcc dance I don't see why Squeak should be held to such a high standard.
The binary blob thing is a normal problem for Linux distributions. If I give you the complete sources for some C application but also include some PNG files for button images and a splash screen, it would take about as much effort for me to hide nasty stuff in these as it would to do the same in a Squeak image. If you were aware that I had done this you would easily find the place in the C code where I was using the images as I shouldn't, but otherwise I bet any number of people could look right at the spot and not notice the evil intent.
In the end it is a matter of trusting some people, as Ken pointed out in his paper. There is not way for me to know what the Intel or AMD people put in the processors I am using. I might get the full sources for some Linux system but don't have enough seconds left in my life to read it all myself (I did it in 1994 when it was orders of magnitude smaller). So I have to trust my processor company and I have to trust my software suppliers. Then only alternative is to build my own processor from TTLs and do all the software:
-- Jecel
On 29-Jun-08, at 9:48 AM, Bert Freudenberg wrote:
No. You need a C compiler, true, but it builds the next C compiler from text sources only, it does not clone itself.
This is also the difference between using SystemTracer to clone an image into a new format vs. what Ralph suggested, using an image to assemble a new image from scratch, containing only an explicitly defined set of objects.
This turns to not be the case. I did not suggest using the tracer to clone an image into a new format; I suggested building a clump of new objects in an existing image's memory and then tracing out that clump only. How would one separate this from the operation of a typical C compiler; read source, generate stuff into memory, write it out.
But it really doesn't matter. Nothing we can do will stop some people from making pointless objections and raising a ruckus. They just don't like Smalltalk.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A computer scientist is someone who fixes things that aren't broken.
tim Rowledge wrote:
*snip*
But it really doesn't matter. Nothing we can do will stop some people from making pointless objections and raising a ruckus. They just don't like Smalltalk.
How did my former boss (Smalltalk software development shop) say it: Their loss - why should I help them see the light?
From the list, I gather that they like GNU/Smalltalk, probably because of the prefix. Other than that: Is it that important to get the Debian crowd to accept Etoys?
Claus
Claus Kick wrote:
tim Rowledge wrote:
*snip*
But it really doesn't matter. Nothing we can do will stop some people from making pointless objections and raising a ruckus. They just don't like Smalltalk.
I call this the "Mac slots" syndrome. Back when the Mac was first introduced I was amazed that the most popular excuse by far for rejecting it was "it doesn't have slots and I can't buy a computer that I can't expand as time goes on". I would have expected to hear that it didn't have needed applications or that it was too expensive, but these became common later (and are used to this day). When the Mac II and Mac SE came out in 1987, guess how many of these complainers bought one?
Changing yourself to please people who currently don't like you doesn't always get results.
How did my former boss (Smalltalk software development shop) say it: Their loss - why should I help them see the light?
This is a very important point - they think it is our loss, that their suggestions will add good things to Squeak and won't hurt anything we already have. But as you mention below, other Smalltalks like GNU/Smalltalk already have these features. So an alternative would be to add EToys to one of them.
How about Self? Its VM is hand written C++ code. It includes the compiler so it can build a new image entirely from a set of source files (which happen to be already organized nicely into one-module-per-file chunks divided in several subdirectories). It includes a version of Morphic, which I personally find nicer than Squeak's (but far less complete since it is older). The VM has advanced adaptive compilation technology and performs very well.
So I nominate Self for Debian! Oh... right... the Linux port is very outdated and was never complete in the first place. Why is that? Because of all the "advantages" I listed above. Because of doing everything right from the Linux viewpoint.
There are many things that are just fine in theory but never happen in real life: a good Linux port of Self, an implementation of EToys in Python, Squeak running on the Strongtalk VM and so on. Some of the "flaws" that have pointed out in Squeak are exactly what have made possible in practice for it to have great ports to many OSes and to serve as the platform for EToys.
From the list, I gather that they like GNU/Smalltalk, probably because of the prefix. Other than that: Is it that important to get the Debian crowd to accept Etoys?
Do they want to reject it entirely or just want to lump it in the "non free" repositories? Having Squeak live next to Adobe Acrobat Reader rather than beside GIMP isn't something that worries me very much.
-- Jecel
On Sat, Jun 28, 2008 at 9:45 PM, Andreas Raab andreas.raab@gmx.de wrote:
Colin Putney wrote:
On 28-Jun-08, at 5:27 AM, Claus Kick wrote:
If push comes to shove, I would even say, lets ditch them all and just use SVN like the rest of the planet (if that is possible). It is hard enough to sell a image-based language with a real IDE to the C-style crowd, the package management systems should not add their grain of salt to the soup.
Been there, done that... <shudder/>
Monticello was created because this turned out not to be feasible in practice.
Can you say something more about that? A couple of weeks ago I saw a demo at HPI in Potsdam where students used SVN down to the method level, and it seemed to me that this approach might very well work because the SVN granularity is the same as the in-image granularity. It may also be interesting that this wasn't even trying to deal with source files of any sort - it retained the nature of the image and simply hooked it up directly with SVN. From my perspective this looked like an extraordinarily interesting approach that I am certain to try out as soon as it is available.
Cheers,
- Andreas
Are you sure that was SVN and not something more modern like git, mercuial, darcs or the like? I can't imagine SVN being seen as anything but legacy by anyone but the most die-hard of fans. I suspect integrating with a more modern system would be easier and it would certainly make repositories better since SVN can't even do one of the more common actions on a repository: merging [1].
[1] Well, they do a hack using comments to simulate merging with some of the SVN bolt-on tools, but these days there is just no reason to use a hack when you can just use one of many properly designed systems.
Hi Jason,
On Mon, Jun 30, 2008 at 2:10 PM, Jason Johnson jason.johnson.081@gmail.com wrote:
Are you sure that was SVN
sure it was.
Best,
Michael
"Jason" == Jason Johnson jason.johnson.081@gmail.com writes:
Jason> Are you sure that was SVN and not something more modern like git, Jason> mercuial, darcs or the like? I can't imagine SVN being seen as Jason> anything but legacy by anyone but the most die-hard of fans.
As a big proponent of git, I can tell you that the number of people and companies who are just *now* considering the move from CVS(!) to "something modern" like *SVN* is still staggering.
On Mon, Jun 30, 2008 at 4:57 PM, Randal L. Schwartz merlyn@stonehenge.com wrote:
"Jason" == Jason Johnson jason.johnson.081@gmail.com writes:
As a big proponent of git, I can tell you that the number of people and companies who are just *now* considering the move from CVS(!) to "something modern" like *SVN* is still staggering.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com 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
You're completely right, but having spent most of my career working for big companies, I can say they are *not* the place to see where the industry is moving. Only where it was years ago. :)
On 28-Jun-08, at 12:45 PM, Andreas Raab wrote:
Colin Putney wrote:
On 28-Jun-08, at 5:27 AM, Claus Kick wrote:
If push comes to shove, I would even say, lets ditch them all and just use SVN like the rest of the planet (if that is possible). It is hard enough to sell a image-based language with a real IDE to the C-style crowd, the package management systems should not add their grain of salt to the soup.
Been there, done that... <shudder/> Monticello was created because this turned out not to be feasible in practice.
Can you say something more about that? A couple of weeks ago I saw a demo at HPI in Potsdam where students used SVN down to the method level, and it seemed to me that this approach might very well work because the SVN granularity is the same as the in-image granularity. It may also be interesting that this wasn't even trying to deal with source files of any sort - it retained the nature of the image and simply hooked it up directly with SVN. From my perspective this looked like an extraordinarily interesting approach that I am certain to try out as soon as it is available.
DVS, the precursor to Monticello, stored all the source code to each package in a single text file. Those files were then versioned using CVS. The file format was a modified chunk format, with the chunks sorted to prevent unnecessary textual churn. The usage pattern was to file out, commit, update and file in.
A large part of the problem came from this two step process for dealing with CVS. It was a hassle to keep track of the state of the image relative to the state of the CVS working copy. It was easy to make mistakes - commit when the wc wasn't up to date, develop when the image wasn't up to date, etc. That would lead to weirdness in the code that had to be manually sorted out.
Merge conflicts were another problem. The textual merging done by CVS wasn't smart enough to deal with a lot of the changes that would happen in development. For example, if two developers each added a method that sorted similarly, they'd get a textual conflict even though there was no conflict at the Smalltalk level.
As DVS developed we added functionality to minimize or work around these issues, until it became clear that it would be less effort to just keep our own version history and do our own merges. At that point we ditched CVS and renamed DVS to Monticello.
Now, this idea of using one file per method has come up before, and I believe it would eliminate many of the difficulties we had with DVS. Merging methods would get better, for sure. Merging class definitions would still be hassle, unless each instance variable, class variable, and pool import were defined in separate files. If the sources and changes files were eliminated, that would fix many of the synchronization problems that we had with DVS, since there would be no need to manually decide when to synchronize.
Still, I see two big problems with this approach. One is that the synchronization problems don't entirely go away. What if some other process modifies the files on disk? How does the image find out about the change, and what should it do in response? What if the modification happens while the image isn't running? There are probably answers to these questions, but I doubt they'll be *good* answers.
The other big problem is that tens of thousands of tiny files is a horribly inefficient way to store source code. Yes, disk is cheap. But disk IO is not. I discovered this early in the development of MC2, when I implemented a type of repository that stored each method in a separate file. Loading OmniBrowser from that repository involved opening, reading, and closing over 600 files, and was very slow. I don't remember the exact timing, but I think it was like 5 to 10 minutes, and in any case it was far too slow. Avi wrote a repository that stored every thing in a single indexed file, and now load time is dominated by compilation.
A quick doIt in my working image shows 44682 methods. Now imagine that on start up, the image scans all those files to make sure that all its compiled methods are up to date. That will take a very, very long time.
Colin
On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney cputney@wiresong.ca wrote:
The other big problem is that tens of thousands of tiny files is a horribly inefficient way to store source code. Yes, disk is cheap. But disk IO is not. I discovered this early in the development of MC2, when I implemented a type of repository that stored each method in a separate file. Loading OmniBrowser from that repository involved opening, reading, and closing over 600 files, and was very slow. I don't remember the exact timing, but I think it was like 5 to 10 minutes, and in any case it was far too slow. Avi wrote a repository that stored every thing in a single indexed file, and now load time is dominated by compilation.
It's worth pointing out that file-based version control has advanced significantly since we did this work - CVS and SVN are now far from the state of the art. I haven't used git much, for example, but it seems to be a well layered system, and it may be that we can build an alternative front end to its database which is image-based rather than working directory based. For example, imagine comparing an image directly to this index file rather than to a directory full of files on disk:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index
And look at this description of the workflow:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflo...
I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN.
Avi
2008/6/30 Avi Bryant avi@dabbledb.com:
On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney cputney@wiresong.ca wrote:
The other big problem is that tens of thousands of tiny files is a horribly inefficient way to store source code. Yes, disk is cheap. But disk IO is not. I discovered this early in the development of MC2, when I implemented a type of repository that stored each method in a separate file. Loading OmniBrowser from that repository involved opening, reading, and closing over 600 files, and was very slow. I don't remember the exact timing, but I think it was like 5 to 10 minutes, and in any case it was far too slow. Avi wrote a repository that stored every thing in a single indexed file, and now load time is dominated by compilation.
It's worth pointing out that file-based version control has advanced significantly since we did this work - CVS and SVN are now far from the state of the art. I haven't used git much, for example, but it seems to be a well layered system, and it may be that we can build an alternative front end to its database which is image-based rather than working directory based. For example, imagine comparing an image directly to this index file rather than to a directory full of files on disk:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index
And look at this description of the workflow:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflo...
I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN.
This is quite interesting. Really, if we could just avoid using file-based working directory and make image to be a kind of 'working directory' this would simplify things a lot - no need to make file outs and synchronization is always made between current methods in image and git repository. Interesting, how much coding needed to connect image with git repository in that way.
Avi
On Mon, Jun 30, 2008 at 11:10 AM, Igor Stasenko siguctua@gmail.com wrote:
This is quite interesting. Really, if we could just avoid using file-based working directory and make image to be a kind of 'working directory' this would simplify things a lot - no need to make file outs and synchronization is always made between current methods in image and git repository. Interesting, how much coding needed to connect image with git repository in that way.
Well, I don't know how much coding it would be, but from a *very* cursory look I would say what you need to do is model the index file format in Smalltalk, and reproduce the update-index and checkout-index commands. Once you had that, you could reuse all the normal merge/commit/etc commands from git, because those all operate on the index and on the repository database.
Avi
On Mon, Jun 30, 2008 at 11:18 AM, Avi Bryant avi@dabbledb.com wrote:
Well, I don't know how much coding it would be, but from a *very* cursory look I would say what you need to do is model the index file format in Smalltalk, and reproduce the update-index and checkout-index commands. Once you had that, you could reuse all the normal merge/commit/etc commands from git, because those all operate on the index and on the repository database.
Here's (I think) the equivalent Java code to what you'd need...
http://repo.or.cz/w/egit.git?a=blob;f=org.spearce.jgit/src/org/spearce/jgit/...
On 30-Jun-08, at 11:10 AM, Igor Stasenko wrote:
This is quite interesting. Really, if we could just avoid using file-based working directory and make image to be a kind of 'working directory' this would simplify things a lot - no need to make file outs and synchronization is always made between current methods in image and git repository. Interesting, how much coding needed to connect image with git repository in that way.
One option would be to use FUSE (or something similar) to make the image appear to be a filesystem. That wouldn't be git-specific, and would even appease all the folks that want to edit their code with emacs.
Colin
Colin Putney wrote:
On 30-Jun-08, at 11:10 AM, Igor Stasenko wrote:
This is quite interesting. Really, if we could just avoid using file-based working directory and make image to be a kind of 'working directory' this would simplify things a lot - no need to make file outs and synchronization is always made between current methods in image and git repository. Interesting, how much coding needed to connect image with git repository in that way.
One option would be to use FUSE (or something similar) to make the image appear to be a filesystem. That wouldn't be git-specific, and would even appease all the folks that want to edit their code with emacs.
Colin
It has been done
Keith
2008/7/1 Keith Hodges keith_hodges@yahoo.co.uk:
Colin Putney wrote:
On 30-Jun-08, at 11:10 AM, Igor Stasenko wrote:
This is quite interesting. Really, if we could just avoid using file-based working directory and make image to be a kind of 'working directory' this would simplify things a lot - no need to make file outs and synchronization is always made between current methods in image and git repository. Interesting, how much coding needed to connect image with git repository in that way.
One option would be to use FUSE (or something similar) to make the image appear to be a filesystem. That wouldn't be git-specific, and would even appease all the folks that want to edit their code with emacs.
Colin
It has been done
Haha, really, run a file system adaptor in image. And then run git, or any other file based version control tool on it. The complication is , that most of such tools using subdirectories to maintain own specific info (like CVS in CVS, and .svn with SVN). So, you will need to make it able to store these files somewhere in image , not only methods which are subject of version control.
Keith
Hi Igor,
On Tue, Jul 1, 2008 at 5:34 AM, Igor Stasenko siguctua@gmail.com wrote:
Haha, really, run a file system adaptor in image. And then run git, or any other file based version control tool on it.
that sounds like heresy to die-hard Smalltalk image paracletes, agreed. ;-) The approach taken for SqueakSVN, where the image talks, via a plugin, to the version management libraries directly, is clearly more appreciable.
The complication is , that most of such tools using subdirectories to maintain own specific info (like CVS in CVS, and .svn with SVN). So, you will need to make it able to store these files somewhere in image , not only methods which are subject of version control.
Right, that would be an interesting task for the file system to manage.
Best,
Michael
Keith
-- Best regards, Igor Stasenko AKA sig.
Hi Colin,
On Tue, Jul 1, 2008 at 4:07 AM, Colin Putney cputney@wiresong.ca wrote:
One option would be to use FUSE (or something similar) to make the image appear to be a filesystem. That wouldn't be git-specific, and would even appease all the folks that want to edit their code with emacs.
SqueakFS exists, and is able to make an image available to the outside (file system) world. We're in the process of setting up a development repository (based on SVN, mind you). In the meantime, it's available from www.squeaksource.com/SqueakFS.html in the current version.
Best,
Michael
Hi,
SqueakFS exists, and is able to make an image available to the outside (file system) world. We're in the process of setting up a development repository (based on SVN, mind you). In the meantime, it's available from www.squeaksource.com/SqueakFS.html in the current version.
Do be so kind as to update the Project Description field on SqueakSource to describe this project. It is a tad terse as it stands.
Brent
Hi Brent,
On Tue, Jul 1, 2008 at 8:00 AM, Brent Pinkney brent@zamail.co.za wrote:
Do be so kind as to update the Project Description field on SqueakSource to describe this project. It is a tad terse as it stands.
heh, indeed. :-) The Wiki page has loads of information instead.
I've put it on my to-do list; the description will be updated. Thanks for pointing this out.
Best,
Michael
On 30-Jun-08, at 10:51 PM, Michael Haupt wrote:
Hi Colin,
On Tue, Jul 1, 2008 at 4:07 AM, Colin Putney cputney@wiresong.ca wrote:
One option would be to use FUSE (or something similar) to make the image appear to be a filesystem. That wouldn't be git-specific, and would even appease all the folks that want to edit their code with emacs.
SqueakFS exists, and is able to make an image available to the outside (file system) world. We're in the process of setting up a development repository (based on SVN, mind you). In the meantime, it's available from www.squeaksource.com/SqueakFS.html in the current version.
Ah good. I must have run across it at some point and forgotten about it.
Colin
SqueakFS exists, and is able to make an image available to the outside (file system) world. We're in the process of setting up a development repository (based on SVN, mind you). In the meantime, it's available from www.squeaksource.com/SqueakFS.html in the current version.
Ah good. I must have run across it at some point and forgotten about it.
There is also the FTP server that I wrote together with Ian at ESUG 2005.
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&...
I used it for a while to develop from within an external editor, but in the end the clumsy Squeak environment is still less annoying than an external editor.
Lukas
On 30-Jun-08, at 11:37 PM, Lukas Renggli wrote:
SqueakFS exists, and is able to make an image available to the outside (file system) world. We're in the process of setting up a development repository (based on SVN, mind you). In the meantime, it's available from www.squeaksource.com/SqueakFS.html in the current version.
Ah good. I must have run across it at some point and forgotten about it.
There is also the FTP server that I wrote together with Ian at ESUG 2005.
Yes, it's excellent. I use it for editing Javascript and CSS that live inside the image as part of OB-Web.
Colin
On Mon, Jun 30, 2008 at 10:51 PM, Michael Haupt mhaupt@gmail.com wrote:
Hi Colin,
On Tue, Jul 1, 2008 at 4:07 AM, Colin Putney cputney@wiresong.ca wrote:
One option would be to use FUSE (or something similar) to make the image appear to be a filesystem. That wouldn't be git-specific, and would even appease all the folks that want to edit their code with emacs.
SqueakFS exists, and is able to make an image available to the outside (file system) world. We're in the process of setting up a development repository (based on SVN, mind you). In the meantime, it's available from www.squeaksource.com/SqueakFS.html in the current version.
There's also Stave which is like SqueakFS but uses WebDAV instead of FUSE. http://www.squeaksource.com/Stave.html I've since stopped using Squeak til I can figure out a reasonable thunk between Squeak and perl so I can use CPAN directly.
Josh
On Mon, Jun 30, 2008 at 1:53 PM, Avi Bryant avi@dabbledb.com wrote:
On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney cputney@wiresong.ca wrote:
The other big problem is that tens of thousands of tiny files is a
horribly
inefficient way to store source code. Yes, disk is cheap. But disk IO is not. I discovered this early in the development of MC2, when I
implemented a
type of repository that stored each method in a separate file. Loading OmniBrowser from that repository involved opening, reading, and closing
over
600 files, and was very slow. I don't remember the exact timing, but I
think
it was like 5 to 10 minutes, and in any case it was far too slow. Avi
wrote
a repository that stored every thing in a single indexed file, and now
load
time is dominated by compilation.
It's worth pointing out that file-based version control has advanced significantly since we did this work - CVS and SVN are now far from the state of the art. I haven't used git much, for example, but it seems to be a well layered system, and it may be that we can build an alternative front end to its database which is image-based rather than working directory based. For example, imagine comparing an image directly to this index file rather than to a directory full of files on disk:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index
And look at this description of the workflow:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflo...
I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN.
Avi
I've been using git quite a bit lately and really like its approach (though I've heard good things about Hg too). I liked it so much that I did a Smalltalk version of it a while back. The idea was to do basically what git does, but make it general purpose such that it could be used for managing versions of any object for which you could define the serialization. I started out making it do version control for contacts and later hooked it up to store Monticello packages (and built a new merge tool in the process). I've had it mostly done for several months but have resisted mentioning it, because once you mention something, you're on the hook to get it out. I'll see if I can clean it up enough in the next few days and publish it. I had hoped to record a screencast to show both how to use it and how the code is currently organized...probably won't do that, but I'll try to get the code out soon.
- Stephen
Having tried Hg and looked at git, I have decided that I much prefer bzr, since it offers mor flexibility and a lightweight checkout.
Keith
On 6/30/08, Avi Bryant avi@dabbledb.com wrote:
On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney cputney@wiresong.ca wrote:
I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN.
Avi
+1. If we must chase inferior methodologies, hopefully we can at least not use obsolete variations of them.
Am 03.07.2008 um 17:07 schrieb Jason Johnson:
On 6/30/08, Avi Bryant avi@dabbledb.com wrote:
On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney cputney@wiresong.ca wrote:
I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN.
Avi
+1. If we must chase inferior methodologies, hopefully we can at least not use obsolete variations of them.
Agreed, although git is rather Linux-centric, so Hg might be a better choice for a cross-platform system like Squeak.
- Bert -
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Agreed, although git is rather Linux-centric, so Hg might be a better choice Bert> for a cross-platform system like Squeak.
What makes you think git is Linux-centric? I've worked hard for the last two years to be "the canary in the coal mine" whenever Git failed to work on OSX and OpenBSD, and the git developers have been *very* responsive. In fact, some of the core developers are now exclusively on Macs. :)
The only place git still doesn't feel "at home" is Windows, where it has to run under some unix-layer on windows (not familiar with this, so I'm not explaining it well).
However, for flexibility and raw speed, git is hard to beat, especially at branching and merging, which is the point of having a distributed SCM.
Am 03.07.2008 um 17:43 schrieb Randal L. Schwartz:
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Agreed, although git is rather Linux-centric, so Hg might be a better choice Bert> for a cross-platform system like Squeak.
What makes you think git is Linux-centric? [...]
The only place git still doesn't feel "at home" is Windows
That is exactly my point.
Don't get me wrong, I develop on Linux and OS X only (using svn and git), but I hear git is faster on Linux and Windows users do complain. And no matter how we skin this cat, Windows users are in the majority.
- Bert -
And no matter how we skin this cat, Windows users are in the majority.
- Bert -
The *vast* majority, by far; however, cygwin makes Windows a perfectly acceptable unix as far as the command line goes and git is available as a loadable package so there's no reason say git is Linux centric, rather that it's command line centric. Any developer worth his salt uses the command line regularly, even in Windows.
Ramon Leon http://onsmalltalk.com
Bert Freudenberg wrote:
Am 03.07.2008 um 17:07 schrieb Jason Johnson:
On 6/30/08, Avi Bryant avi@dabbledb.com wrote:
On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney cputney@wiresong.ca wrote:
I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN.
Avi
+1. If we must chase inferior methodologies, hopefully we can at least not use obsolete variations of them.
Agreed, although git is rather Linux-centric, so Hg might be a better choice for a cross-platform system like Squeak.
- Bert -
Having tried Hg, I have found Bzr to be preferable.
Hg doesnt have a lightweight checkout, Bzr does. i.e. you can deploy the latest, without the whole history.
I have setup a public (ish) bzr server at bzr.warwick.st with 160Gb of space. We will be using this for managing and distributing the results of automated image builds in the near future.
best regards
Keith
Keith Hodges wrote:
Having tried Hg, I have found Bzr to be preferable.
Hg doesnt have a lightweight checkout, Bzr does. i.e. you can deploy the latest, without the whole history.
I have setup a public (ish) bzr server at bzr.warwick.st with 160Gb of space. We will be using this for managing and distributing the results of automated image builds in the near future.
Just trying to bring everything back to the core question: What about having something like CPAN (with a CPAN installer) for Squeak?
I am trying to follow the discussions, but to me it seems as if this central question is not really discussed.
Instead, there are interesting topics, like Squeak-To-SVN, advantages/disadvantages of other Versioning Tools (whose names I have not even heard, was in ENVY/Manager, SVN and ClearCase land too long it seems), nameing and so on...
What about the central question? What about having something like CPAN (with a CPAN installer) for Squeak?
On Thu, 2008-07-03 at 21:54 +0200, Claus Kick wrote:
Keith Hodges wrote:
Having tried Hg, I have found Bzr to be preferable.
Hg doesnt have a lightweight checkout, Bzr does. i.e. you can deploy the latest, without the whole history.
I have setup a public (ish) bzr server at bzr.warwick.st with 160Gb of space. We will be using this for managing and distributing the results of automated image builds in the near future.
Just trying to bring everything back to the core question: What about having something like CPAN (with a CPAN installer) for Squeak?
I am trying to follow the discussions, but to me it seems as if this central question is not really discussed.
Instead, there are interesting topics, like Squeak-To-SVN, advantages/disadvantages of other Versioning Tools (whose names I have not even heard, was in ENVY/Manager, SVN and ClearCase land too long it seems), nameing and so on...
What about the central question? What about having something like CPAN (with a CPAN installer) for Squeak?
What makes you think CPAN is a good solution or appropriate for squeak? For me CPAN means a lot of things. Maybe you should go into detail about it to show the good things that would be valuable for squeak.
I personally read a lot of good points in the discussion what could be appropriate for squeak. Especially the tension not to build another tool but to enhance/migrate the existing ones.
Norbert
Hi,
it was mentioned already: We developed SqueakSVN, a project-centric code management tool, as a student project at HPI. It completely integrates SVN, so the workflow is different than the one from DVS. Everything can be controlled from within Squeak.
We are currently cleaning up the code and after we are done, SqueakSVN will be released.
Robert
On Jun 28, 2008, at 9:45 PM, Andreas Raab wrote:
Can you say something more about that? A couple of weeks ago I saw a demo at HPI in Potsdam where students used SVN down to the method level, and it seemed to me that this approach might very well work because the SVN granularity is the same as the in-image granularity. It may also be interesting that this wasn't even trying to deal with source files of any sort - it retained the nature of the image and simply hooked it up directly with SVN. From my perspective this looked like an extraordinarily interesting approach that I am certain to try out as soon as it is available.
Cheers,
- Andreas
On Tue, Jul 1, 2008 at 11:10 AM, Robert Krahn robert.krahn@student.hpi.uni-potsdam.de wrote:
Hi,
it was mentioned already: We developed SqueakSVN, a project-centric code management tool, as a student project at HPI. It completely integrates SVN, so the workflow is different than the one from DVS. Everything can be controlled from within Squeak.
Just curious - how is the integration done? Via a network protocol, or using OSProcess, or some other way?
Avi
Hi Avi,
we communicate with Subversion by using the C-API of SVN and a VMPlugin.
Robert
On Jul 1, 2008, at 8:15 PM, Avi Bryant wrote:
On Tue, Jul 1, 2008 at 11:10 AM, Robert Krahn robert.krahn@student.hpi.uni-potsdam.de wrote:
Hi,
it was mentioned already: We developed SqueakSVN, a project-centric code management tool, as a student project at HPI. It completely integrates SVN, so the workflow is different than the one from DVS. Everything can be controlled from within Squeak.
Just curious - how is the integration done? Via a network protocol, or using OSProcess, or some other way?
Avi
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Avi Bryant -
Bert Freudenberg -
Brent Pinkney -
Claus Kick -
Colin Putney -
Damien Pollet -
David T. Lewis -
Edgar J. De Cleene -
Igor Stasenko -
Jason Johnson -
Jecel Assumpcao Jr -
Joshua ben Jore -
K. K. Subramaniam -
Keith Hodges -
Lukas Renggli -
merlyn＠stonehenge.com -
Michael Haupt -
Michael Rueger -
nicolas cellier -
Norbert Hartl -
Ralph Johnson -
Ramon Leon -
Rob Rothwell -
Robert Krahn -
Stephen Pair -
tim Rowledge -
Yoshiki Ohshima