Tweak progress report.

After days of hunting down a class/object/method bug in TweakCostume, we have hit an area, that I as a programmer, have never encountered before...and its fun...



compilerClass => CCompiler

== recompiling setupCostume ==

== literals after recompile ==

  1: #setupCostume  (ByteSymbol)

  2: #extent:depth:  (ByteSymbol)

  3: #Form=>Form  (ClassBinding)

  4: #fillWhite  (ByteSymbol)

  5: #form  (ByteSymbol)

  6: 8.0  (SmallFloat64)

  7: #fill:fillColor:  (ByteSymbol)

  8: #corner:  (ByteSymbol)

  9: #gray  (ByteSymbol)

  10: #Color=>Color  (ClassBinding)

  11: #graphic:  (ByteSymbol)

  12: #graphicFit:  (ByteSymbol)

  13: #tile  (ByteSymbol)

  14: #extent:  (ByteSymbol)

  15: 40.0  (SmallFloat64)

  16: #setupCostume  (ByteSymbol)

  17: #CSpriteCostume=>CSpriteCostume  (ClassBinding)

== symbolic after recompile ==

145 <4C> self

146 <EB 00> superSend: setupCostume

148 <D8> pop

149 <12> pushLitVar: #Form=>Form

150 <E8 08> pushConstant: 8

152 <E8 08> pushConstant: 8

154 <6B> send: @

155 <25> pushConstant: 8.0

156 <84> send: form

157 <83> send: fillWhite

158 <A1> send: extent:depth:

159 <D0> popIntoTemp: 0



   the bug is in...





155 <25> pushConstant: 8.0

156 <84> send: form

157 <83> send: fillWhite

158 <A1> send: extent:depth:





that should not be there...that is what causes the "Morphic" bug...i.e. the dang screen go blank and the vm to crash.





Hunting that down now. should be fun. The KEY INSIGHT to me is that "THE VM IS JUST MORE SOFTWARE" therefore, demystifying it for me.



I have been an application/db sort of programmer for decades and to run into this is fascinating and invaluable...


Now that I have that key insight, my noob question to myself is  "Is the VM just a state machine that reacts to those codes?"  (to be  answered in due time...get the dang Tweak running is job one)





Taking the time to get the 32 bit compat libs installed so that I can compare to a working compiler chain has been the key to this.  




One final thought...it appears the Tweak uses a method similar to the Croquet using a DNU to do a "lookup" to get the right OpenGL primitive to call...I cannot state the exact mechanics yet, but it was interesting to see it...



Here is an example flow..."The statefulness is the lazy-init path, not caching magic. fill calls the costume getter; on a fresh instance the costume slot is nil, so costume runs wearDefaultCostume → setupCostume, which faults. The slot gets populated along the way, so a second call on the same instance finds a costume already there, skips wearDefaultCostume, and returns NoFill cleanly"





I have not browsed, but not studied  the document , but inside the CProject Builder is a TCARS document  pasted below...is probably a description of that design.



Anyway, back to the AST  (?) I suspect senders of "emit" is the first place to look.



cordially




















https://claude.ai/projects 


Croquet64SDK






Project for building the many parts of this large project. Context from previous, non-project chats has been imported..










How can I help you today?




































https://claude.ai/chat/c1aa3e80-0aed-47db-bd91-d66d0fd9667a 



https://claude.ai/chat/f28b98d6-be6e-437a-a3c2-242cda689571 



https://claude.ai/chat/000e4b12-3052-4a8d-8114-4e5f5cc802a3 



https://claude.ai/chat/8a162461-30a4-437b-9452-6e6ddf50a9e3 



https://claude.ai/chat/5fbb221f-43f5-4992-98fe-da8707aa0cfd 



https://claude.ai/chat/74dbbabe-fe18-4a64-b07c-1c84a23f272b 



https://claude.ai/chat/28b5d24a-cd51-4992-9e07-a64e7f9c93c6 



https://claude.ai/chat/56a22943-97e1-4137-a62a-9f9fcd62500b 



https://claude.ai/chat/93a3ab29-7479-4ee0-942b-cc1029c7795c 



https://claude.ai/chat/561dcfa4-dd1f-4310-ba16-ffb5b794d082 



https://claude.ai/chat/4800ecbf-959e-4bfd-9632-92bb1a8c26d7 



https://claude.ai/chat/26669e5b-2932-4585-ad29-afc858ddbd8a 



https://claude.ai/chat/807a21e8-bba9-4bae-be67-364b96f14fd4 



https://claude.ai/chat/314317a0-f23e-4b09-a3c1-d9a109f2f895 



https://claude.ai/chat/59f1e09a-6187-4905-b145-46a719474ef2 



https://claude.ai/chat/a977fb9f-2c21-46f6-ba28-2cb033f269a8 



https://claude.ai/chat/9d56e919-5de8-453f-b9cc-4cf2a4d2f77a 



https://claude.ai/chat/f6f1f7bc-1cd1-46c9-9f6a-b8983a9913d4 



https://claude.ai/chat/64213374-8dc0-4e25-9adc-dce77a2b51ee 



https://claude.ai/chat/0ebe43d7-5533-4291-a84c-2edda19166df 



https://claude.ai/chat/28325a93-6b0c-4200-a45e-c57930f835e3 



https://claude.ai/chat/360498db-75e5-46e7-ba94-7244eec33957 



https://claude.ai/chat/91246288-e7ff-4a66-8dc0-a9935ca7b946 







Memory




Only you


Purpose & context Timothy is engaged in an ongoing, multi-session technical project porting the Tweak/Croquet GUI framework from 32-bit to 64-bit in Squeak 6.1 alpha 64-bit headless (Xvfb :99). The working image lives at /home/wm/usr/src/smalltalk/ClaudeTweak/shared/ClaudeTweak.image. The collaboration involves three parties: Timothy (human operator with machine access), Claude (claude.ai, acting as planning and reasoning partner), and Claude Code via GPTEL/Emacs (executing all MCP and bash commands on Timothy's machine). Claude has no direct machine access and writes verbatim Smalltalk/bash for Claude Code or Timothy to run, then interprets pasted output. Established project shorthand: "horse" = sanity check CCompiler evaluate: '3 + 4' → 7 "train" = image healthy "julep" = a hard-won win "myths" = inherited claims proven false on contact "milestone N" = a banked, boot-verified image snapshot Current state The image is at milestone 24, reached in Session 12. That session accomplished: Target B resolved: Clean Monticello load of Tweak-Basic-tty.131.mcz brought in 36 previously absent classes (1916 total definitions), vindicating Timothy's hypothesis that the original partial load hard-aborted mid-stream because CCompiler wasn't ready — busting Myth #5 ("minimal core, GUI never loaded"). nameForDisplay print bug fixed: Surgically lifted Class>>nameForDisplay ^self name from the unloaded Tweak-Hacks package (which must never be loaded wholesale due to 64-bit landmines). Target C (white screen) root cause identified but not yet fixed: CCompiler is not resolving bare field references in compiled methods. Field-referencing methods (color:, fill getter, costume references) compile field names as undeclared variables, so all virtual field accesses read nil at runtime and the entire color/fill/costume layer is inert. The precise mechanism: CPlayer fieldNamed: #fill returns nil even though allFields contains fill — the two views of the field set disagree. Prior states preserved as old/22., old/22-preimport., old/23., old/24.. The MCP server runs on port 9877. The snapshot:andQuit: path is sound (Target E resolved by understanding in Session 11); the existing snapshotPrimitive shim is declared sound, not a kludge. On the horizon Target C (field-resolution mismatch) is the open problem entering Session 13, explicitly designated as deserving its own fresh context. Leading suspects: Symbol-vs-String comparison mismatch in the fieldNamed: implementation Two field registries out of sync Missing field-resolution support from the unloaded Tweak-Hacks package The Session 13 Handoff Briefing is at /mnt/user-data/outputs/TweakPortSession13HandoffBriefing.md. Key learnings & principles Myth discipline: Never trust an inherited causal claim without re-deriving it from observation. Multiple "obvious" root causes (Integer>>color: stub → white screen; defineField:colorName: as culprit; shutdown list broken) have collapsed on contact with structured probes. Tweak-Hacks is radioactive: The package contains known 64-bit landmines; individual methods may be surgically extracted but the package must never be loaded wholesale. Trust structured probe output over narrative: Claude Code's prose narration has misread inner-nil DNUs as "new returning nil" — raw pasted output takes precedence over agent summaries. CCompiler readiness is a prerequisite: The original load failure pattern (hard-abort mid-stream) was caused by CCompiler not being ready, not by intentional minimalism. Field registry split is real: allFields and fieldNamed: consult different or inconsistent data — this is the live unsolved problem. Approach & patterns Read-mostly before any mutation: Diagnostic chains are exhausted before any destructive action; one variable changed at a time. Strict save/backup discipline: Prepare → save → cp old/N.* → fresh-boot verify, never quit before the copy. Session handoff documents: Each session closes with a written handoff briefing capturing open targets, myth-busts, and the precise entry point for the next session. Terse, decisive communication: Timothy pastes raw shell/tool output directly and flags agent looping or framing errors quickly; corrections are accepted and integrated without re-litigation. Hypothesis ownership: Timothy holds and tracks hypotheses explicitly; vindication or falsification is noted as part of the record. Tools & resources Squeak 6.1 alpha-23584 64-bit headless, Xvfb :99 Monticello (.mcz package loading) MCP TCP server on port 9877 Claude Code via GPTEL/Emacs (executes all commands; Timothy pastes output back) Project knowledge at /mnt/project/ (view tool uses double-underscore-prefixed filenames; projectknowledge_search accepts natural-language queries) Session outputs at /mnt/user-data/outputs/

Last updated 1 day ago





Instructions




Add instructions to tailor Claude’s responses







Files









15% of project capacity used



Search mode






# Tweak Port — Session 17 Handoff Briefing

144 lines


text















Tweak Core Architecture Release (TCAR)

80 lines


text















ttysource.st

1 line


text















coresource.st

1 line


text















# Tweak Port — Session 16 Handoff Briefing

221 lines


text















# Tweak Port — Session 15 Handoff Briefing

211 lines


text















# Tweak Port — Session 14 (Conceptual) Handoff

167 lines


text















# Tweak Port — Session 13 Handoff Briefing

151 lines


text















# Tweak Port — Session 12 Handoff Briefing

144 lines


text















# Tweak Port — Session 11 Handoff Briefing

158 lines


text















# Tweak Port — Session 10 Handoff Briefing

199 lines


text















# Tweak Port — Session 9 Handoff Briefing

183 lines


text















# Tweak Port — Session 8 Handoff Briefing

145 lines


text















Tweak_Port_Session_7_Handoff.md

146 lines


md















Tweak_Port_Session_5_Handoff.md

216 lines


md















howto.text

1 line


text















Tweak Port Session (x) handoff...

142 lines


text















CCompiler mileston...

4 lines


text















PragmasHelp.md

473 lines


md















Machado's five questions we must answer as we proceed...

7 lines


text















Tweak Port Milestone Summary before new Architectural strategy

139 lines


text















tweaklog.1

6,993 lines


text















🗒️ Tweak Port — Session 2 Briefing

86 lines


text















CroquetSDK.dia

38 lines


text















Croquet64-Level0-SolarSystem.dia

19 lines


text















Croquet64_ProjectSummary.md

106 lines


md















Croquet64 SDK Developers Guide

55 lines


text















Chat Summary — Croquet64: Avatar Bug Fix & Project Vision

36 lines


text















🗒️ Tweak Port — Next Session Briefing

16 lines


text















TimmyAndClaudeLearnSqueak — Chat Summary

49 lines


text















Croquet64 — Project Summary

105 lines


text















Chat Summary: Sperg Machine + Squeak Knowledge Base

72 lines


text
































Tweak Core Architecture Release (TCAR)




8.28 KB •80 lines•Formatting may be inconsistent from source

Tweak Core Architecture Release (TCAR)
        -- "Don't do it if it hurts!"


About this Release:
The TCAR is the release of the core parts of the Tweak architecture. It is NOT an end-user release, it is intended for early adopters and participants who wish learn the architecture early on and actively contribute. If you are looking for the end-user release, this isn't it (yet).

Mailing list:
A mailing list exists at http://impara.de/mailman/listinfo/tweak  What is in this release:

This release contains the following parts:

* The Tweak Compiler
Since I couldn't any longer manage the changes to the existing compiler in the form of hacks, this release simply contains a copy of the existing compiler (see category 'Tweak-Compiler'). The compiler supports method annotations (which are critical for some aspects of Tweak), positional arguments (critical for interfacing some of the scripting languages that will be supported in the future), support for "fields" (which are a carefully controlled form of implicit self) and some more.

NOTE: If you are interesting in writing a decent compiler rather than this hacked-together piece of junk, please do! I'd be more than happy to throw the existing crap away.

* The asynchronous event architecture
This is one of the fundamental parts of Tweak, allowing us to provide multi-threading with clearly defined default-synchronization semantics (if you are curious, open a process browser, turn on auto-updating and watch what happens when you move over the menubar on top). The threading semantics is PRECISELY the same that we have in Morphic's steps. Here is a little example (which will not work because the editor doesn't support code evaluation yet ho hum, and I haven't got the <doit> text attribute back to work...):

    button := CPushButton new.
    button label: 'Button'.
    button open.
    button waitUntil: #click.
    Smalltalk beep.

The event architecture can be found (due to historical reasons) under the 'Scripting-*' categories.

NOTE: This stuff is currently fairly inefficient. Really there isn't any need whatsoever to throw around as many processes as I'm doing right now - it was my way to make sure this stuff absolutely works but there's a lot of low-hanging fruit for optimization here. So if something seems to go slowly don't optimize on the wrong end because you see "all these processes" - they will go away as soon as it "hurts enough" to become a worthwhile target for optimization (and if you complain loudly enough it will raise to the top of the priority list much faster).

* The graphical object representation
In Tweak, all graphical objects are an assembly of a (pretty large) set of so-called "costume aspects". These aspects cover all of the areas that a graphical object may have such as:

    * their geometry
    * their fill
    * their border
    * their text
    * their graphic
    * their layout
    * ... (many others omitted) ...

The "aspects" are a fundamental part of Tweaks graphical object representation because they allow us to narrow down a broad set of interfaces into a very small one and allow delegation of this specific aspect (check out how the fill, border, or text attributes are implemented in CPlayer). Also, by the end of the day there is only "one kind" of graphical object which carries all of these aspects around - this is CPrimitiveCostume and this is one of the guys which is really off-limits. You can look but you cannot touch, but go ahead and study the aspects you find in the "Tweak-Costumes" categories.

NOTE: Some aspects are still missing or aren't fully formed yet. If you need something that isn't there yet, feel free to help out.

* The core Tweak architectural objects
These are found in the "Tweak-User-Kernel" category. Only six of them? No, really there is only one ;-) Most of the guys you find there have been defined because many programmers prefer to think in terms of "types" rather than "roles" and the classes found in the kernel category are intended to help them a little along those lines. But really "The One And Only" object to look at is CPlayer. It's the center of the architecture and everything else evolves around it.

Also, there are some interim objects in the "Tweak-User-Media" category which I defined to occupy the names in the global namespace - these will be filled in as we work out the interfaces which we want to expose to these media objects.

* Tweak Widgets
There is an (almost complete) set of widgets by this time, but note that some of them are probably not structured quite right, lack some good notions so please, please, please - don't take them for a given, I am REALLY interested in finding fundamentally good and useful notions for these widgets and if you find something that seems obscure and in the wrong place, let me know.

To give an example, after some discussion with Bert I completely changed the way buttons work because it just seemed so much more useful to have them be "state-based" - the message here is that I am interested in useful notions more than anything else.

Finally, keep in mind that the widgets have been built in the "second order theory" of Tweak rather than its first order theory (which is entirely reasonable to use - see the ColorTool for an example for first-order theory Tweak use). The reason for using the second-order theory for the widgets is because it is certain that we will want to have completely different widget sets (including native widgets) and the architecture allows for this easily.

* Tweak Tiles
The core architecture release contains the basic tile framework for Tweak. This framework has been built based on "the lessons from eToys" so that they we will be able to support various looks and feels but share the (essential) models across a wide variety of authoring environments.

Because of this, the tile framework is yet another example of the second-order theory of Tweak and you should be careful to copy what you see here "for the wrong reasons". There is no need for 90% of all user-code to make use of an advanced theory if the naive approach works likewise (often better).

* A first (somewhat rudimentary) run at the authoring environment
This what ColorTool, ProjectBuilder and friends provide. There is still a lot of work to be done and if you want to build something useful and learn about the architecture, that's a good place to start. Just find yourself a little tool which you would find useful to have for authoring and start building it.

* An (extremely rudimentary) first run at programming tools
If it weren't for the programming tools, Tweak would put both Morphic and MVC to its final rest - there is no reason to have any of them, Tweak doesn't need them and being able to get rid of both is one of the ultimate goals here.

This would be another good place to start: Just take whatever tool you know from Morphic and make it work with Tweak. The rudimentary start I did on the workspace and the (not-quite-working) browser should give you a pretty good start here.

What is NOT in this release:

When I decided to ship this release for real I had to make a really hard decision between taking all of the previous stuff from alpha1 with the TCAR or not. I decided against it for a single reason: People who would look at stuff from alpha1 wouldn't see the things they ought to see. While there were some good things in alpha1 I decided to leave them out for the single reason to make this release as concise as possible - you get only things that I have explicitly reviewed and found "good enough" to be looked at.

That's partly why this release is poor on the "end-user notions" - all of the stuff which was in alpha1 was aimed at the end-user space, but in making (and refining) the TCAR I had to change some fundamental things and looking at any of the former stuff would just get into your way of understanding what Tweak is all about. These things will come back - based on a stronger foundation than they were and in about 1/10th of the time it took to build them originally.

Also, there is one major aspect that is missing in this release simply because I wanted to get it out - that's the part of "constructing user interfaces". At this point one still has to "program" the user interface very much like in Morphic but the architectural hooks are there and one of the next steps will be to bring in the interactive construction back in. Until then, you are no better or worse off then with Morphic.

Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]