Nice to see it still going. For those unaware, Squeak linage descends directly from the last Xerox Smalltalk-80 images before being bootstraped.
Don't know if it's true, but it makes a fun story: ST80 used reference counting with counts saturating at some low number (like 127), and of course there are problems collecting circular references. A comprehensive analysis of a modern image, with Xerox PARC lineage, discovered garbage that had been uncollected for 20-30 years.
Smalltalk Squeak 6.0
21–30 of 73 posts
Re: Smalltalk Squeak 6.0
#22Earlier quoted context omitted.
Don't know if it's true, but it makes a fun story: ST80 used reference counting with counts saturating at some low number (like 127), and of course there are problems collecting circular references. A comprehensive analysis of a modern image, with Xerox PARC lineage, discovered garbage that had been uncollected for 20-30 years.
It is true, that there is uncollected garbage in the original Xerox ST80 image. I've built some tools to analyze the image and also a VM which can be interrupted at any time to analyze the current state of the image (see https://github.com/rochus-keller/Smalltalk ). There are two zombie processes (OID 6662 and 19ba). There are also a couple of BlockContext and MethodContext which have a nil sender and a reference to…
Re: Smalltalk Squeak 6.0
#23> Switches the default bytecode set to SistaV1. This lays the basis for a new generation of VM optimizations (Sista: Speculative Inlining Smalltalk Architecture). With Sista, blocks are represented by CompiledBlocks and instantiated as FullBlockClosures, the stability of which has been improved in the course of this switch (fixed bugs in FullBlockClosure >> #= and InstructionStream >> #scanForInstructionSequence:). P…
Re: Smalltalk Squeak 6.0
#24Could a developer use Squeak as an emacs replacement?
I have not seen Squeak (or other Smalltalk environments, e.g. Pharo) being used like and IDE, which is what I infer you mean by "developer... emacs replacement". It certainly seems possible and could potentially make for a great IDE foundation, I just haven't seen it done, other than the Glamorous Toolkit - https://gtoolkit.com
Re: Smalltalk Squeak 6.0
#25Earlier quoted context omitted.
It is true, that there is uncollected garbage in the original Xerox ST80 image. I've built some tools to analyze the image and also a VM which can be interrupted at any time to analyze the current state of the image (see https://github.com/rochus-keller/Smalltalk ). There are two zombie processes (OID 6662 and 19ba). There are also a couple of BlockContext and MethodContext which have a nil sender and a reference to…
It's things like this that always made me look a bit askance at Smalltalk. It feels a little like "Document_Final_FINAL_v3_(2).docx", a little like a dirty old whiteboard where you can still see outlines of notes from last year. Might not be a fair assessment, but as an outsider I've always felt this way about image-based systems.
Re: Smalltalk Squeak 6.0
#26Earlier quoted context omitted.
I have not seen Squeak (or other Smalltalk environments, e.g. Pharo) being used like and IDE, which is what I infer you mean by "developer... emacs replacement". It certainly seems possible and could potentially make for a great IDE foundation, I just haven't seen it done, other than the Glamorous Toolkit - https://gtoolkit.com
Interesting statement, given that modern IDEs trace back to Lisp and Smalltalk graphical workstations.
Re: Smalltalk Squeak 6.0
#27Earlier quoted context omitted.
Don't know if it's true, but it makes a fun story: ST80 used reference counting with counts saturating at some low number (like 127), and of course there are problems collecting circular references. A comprehensive analysis of a modern image, with Xerox PARC lineage, discovered garbage that had been uncollected for 20-30 years.
I’m reminded of junk DNA.
Re: Smalltalk Squeak 6.0
#28Could a developer use Squeak as an emacs replacement?
The fact that Emacs has been in use (for decades) as a tool aimed at primarily solving everyday problems, means that it's been optimized for practicality to a ridiculous extent. That's not the case with Squeak, since it still has a very strong academic/research focus and a much smaller userbase than Emacs.
That's not to say that Squeak is useless, I'm a hardcore Emacs user and I do use Squeak too, but it's nowhere near as practical. It does however offer by far the best environment to experiment with Smalltalk and image-based development.
On the other hand, I don't recommend Pharo, as I found it even less practical than Squeak with frequent braking changes and a -seemingly- complete lack of focus that has pulled the project in widely different directions over the years. At least, Squeak is cohesive and hasn't broken with Alan Kay's vision.
Re: Smalltalk Squeak 6.0
#29Earlier quoted context omitted.
I once worked with a guy who did all his coding in Squeak the way some do in Emacs. He shipped enterprise code this way. Implementation language was Perl.
That seems incredibly odd lol. What advantage does that have over Notepad++?
Re: Smalltalk Squeak 6.0
#30Earlier quoted context omitted.
I once worked with a guy who did all his coding in Squeak the way some do in Emacs. He shipped enterprise code this way. Implementation language was Perl.
That's wild. I've been wanting to do the same thing with Ruby for years.