Hi David
On 30. Mar 2023, at 16:09, David Gray dgray@iesl.forth.gr wrote:
I’ve been trying to get a working VM for FreeBSD. However even though I manage to get the system to start and update itself it gives a segmentation error when I open a workspace and type any character at all. I used the latest linux64x64 cog.spur. Both the 6.0 and 5.3 images behaved the same. To get it to compile I had the comment out the Joystick plugin and edit the baud rates inside the serial plugin. I’m a complete beginner with squeak so I don’t know how to proceed from here.
Based on your comments, I went and tried to verify that the VM still builds. I have made similar adjustments and was able to build a VM with the recents commits to the Cog branch of the VM.
Can you please build a debug vm and try to recreate the error? I am very interested in that.
Best regards -Tobias
Hi Folks,
I am reading http://www.esug.org/data/Articles/misc/oopsla99-contexts.pdf%C2%A0 in the hopes of upping my game regarding Smalltalk in general.
From the Abstract in the above link, is this sentence... Smalltalk-80 provides a reification of execution state in the form of context objects which represent procedure activation records.
A search for 'activation records (https://search.brave.com/search?q=procedure+activation+records&source=de... states that they are synonymous with stack-frames.
but the sentence in the abastract suggests a level of abstraction between the actual "stack-frame" and the "reification of execution state in the form of context objects"
is this suggestion true?
Furthermore, pointers for more basic reading on this stuff would be helpful.
cordially
tty
I think the confusion results from believing random pages on the Internet:
states that they are synonymous with stack-frames
If ALL the guy has seen is Algol-68 (which I mean inclusively, i.e. counting dialects like BCPL, C, etc) then yes, because *in those languages* there is no need to be conscious about the difference between activation records and stack frames. But if the language provides reification of execution, activation records are perennial objects, i.e. they can outlive the activation. Therefore they can't be stack frames -- otherwise at the end of the activation they are garbage. So, very old Smalltalks allocated activation records on the heap, these are called "Contexts"; but this is much slower than stack frames. OOPSLA99 talks exactly about how to [internally] represent contexts on the stack but still enjoy them behave correctly as perennial objects.
So, OOPSLA99 is correct.
pointers for more basic reading on this stuff would be helpful
Hmmm... good books on higher-order programming languages count in the hundreds, so I guess it depends on what you are into. Still, one excellent book is "LISP in Small Pieces" by Christian Queinnec. Also the paper "The Essence of Algol" by John C. Reynolds immediately comes to mind.
Thank you for the reply.
Regarding Lisp in Small Pieces .. The didactic approach appeals to me. and I will need LISP to integrate Squeak with Emacs via LSP (?)
Thanks for the heads up.
I also noticed that the bottom of the OOPSLA has a bibliography, but that LISP book looks very good.
Regarding definitions...
"But if the language provides
reification of execution, activation records are perennial objects, i.e.
they can outlive the activation."
There is a lot to unpack there at the basic definition level.
Just guessing, but the "reification of execution" ARE the execution of a method, but stored as Objects in something called an activation record (activation record is distinct from the stack?)
Some assumptions I currently have...
1. there is one stack in Squeak. (I heard Tim complaining about a method call having to go all the way up the stack to be executed...that is the source of that assumption)
2. The activation records are "a table" containing "pointers" to the "perennial objects".
3. I have no idea what an activation is. (the activation records are "chunks of a stack" that can be put on the one stack ?)
Interesting stuff, thank you.
---- On Sun, 24 Sep 2023 12:48:56 -0400 Boris Shingarov boris@shingarov.com wrote ---
I think the confusion results from believing random pages on the Internet:
states that they are synonymous with stack-frames
If ALL the guy has seen is Algol-68 (which I mean inclusively, i.e. counting dialects like BCPL, C, etc) then yes, because *in those languages* there is no need to be conscious about the difference between activation records and stack frames. But if the language provides reification of execution, activation records are perennial objects, i.e. they can outlive the activation. Therefore they can't be stack frames -- otherwise at the end of the activation they are garbage. So, very old Smalltalks allocated activation records on the heap, these are called "Contexts"; but this is much slower than stack frames. OOPSLA99 talks exactly about how to [internally] represent contexts on the stack but still enjoy them behave correctly as perennial objects.
So, OOPSLA99 is correct.
pointers for more basic reading on this stuff would be helpful
Hmmm... good books on higher-order programming languages count in the hundreds, so I guess it depends on what you are into. Still, one excellent book is "LISP in Small Pieces" by Christian Queinnec. Also the paper "The Essence of Algol" by John C. Reynolds immediately comes to mind.
Boris, thanks again for the recommendation.
This should net two skills in one pass: 1. learn lisp (by writing new lisps!) and 1. grok the VM language.
I spent the morning grokking the outline of the book/tasks
* The Basics of Interpretation
* Lisp, 1, 2, ....w
* Escape & Return Continuations
* Assignment and Side Effects
* Denotational Semantics
* Fast Interpretation
* Compilation
* Evaluation and Reflection
* Macros: Their Use and Abuse
* Compiling into C
* Essence of an Object System
The chapter on defining a LISP in Lambda Calculus looks very, very interesting..."if the math works, the program works, if not, not." may be naive, but removing ambiguity appeals to me.
Hopefully, after doing the work I can begin to contribute at a systems level instead of the "application developer level" I am in.
cordially,
t
---- On Sun, 24 Sep 2023 12:48:56 -0400 Boris Shingarov boris@shingarov.com wrote ---
I think the confusion results from believing random pages on the Internet:
states that they are synonymous with stack-frames
If ALL the guy has seen is Algol-68 (which I mean inclusively, i.e. counting dialects like BCPL, C, etc) then yes, because *in those languages* there is no need to be conscious about the difference between activation records and stack frames. But if the language provides reification of execution, activation records are perennial objects, i.e. they can outlive the activation. Therefore they can't be stack frames -- otherwise at the end of the activation they are garbage. So, very old Smalltalks allocated activation records on the heap, these are called "Contexts"; but this is much slower than stack frames. OOPSLA99 talks exactly about how to [internally] represent contexts on the stack but still enjoy them behave correctly as perennial objects.
So, OOPSLA99 is correct.
pointers for more basic reading on this stuff would be helpful
Hmmm... good books on higher-order programming languages count in the hundreds, so I guess it depends on what you are into. Still, one excellent book is "LISP in Small Pieces" by Christian Queinnec. Also the paper "The Essence of Algol" by John C. Reynolds immediately comes to mind.
vm-dev@lists.squeakfoundation.org