10 prompts · 298 messages · 113 tool calls · 2 commits · 2 pages
Please try again to see if the game of life example mentioned in issue #72 will compile now. You may want to update the program's sourcce code to include the course module since it seems to reference that library but lacks the include directive for it.
Now I can see the issues clearly. The program uses several functions from the "Programming in occam 2" book's standard library (write.string, write.formatted, DATA.ITEM protocol, terminal.keyboard, terminal.screen) which are different from the KRoC course module. I also see a codegen bug where VAL [n]INT abbreviations generate the wrong Go type. Let me investigate both.
All tests pass. Now let me modify life.occ to remove the book-library dependencies. The program uses:
write.string(chan, "str") - not in course module, define inlinewrite.formatted(chan, fmt, data_chan) + DATA.ITEM protocol + data.int - complex formatted output, rewrite move.cursor directlyterminal.keyboard / terminal.screen - runtime-provided channels, need declarationsThe generated Go code looks correct. Key things to verify:
var _alt0 chan byte = nil - fixed (was chan int)var nx []int = []int{...} - fixed (was var nx int)clear_screen and move_cursor use direct byte output instead of the missing library functionswrite_string and write_small_int are self-containedterminal_keyboard and terminal_screen are properly declared as channelsLet me also verify the course module still transpiles cleanly:
Everything works. Here's a summary of what I did:
The Game of Life example (historical-examples/life.occ) now transpiles and compiles cleanly (go vet passes).
life.occThe program used functions from the "Programming in occam 2" book's standard library (write.string, write.formatted, DATA.ITEM protocol, terminal.keyboard, terminal.screen) which are different from the KRoC course module. I made these modifications:
write.string PROC — loops over bytes, replacing the book library's versionwrite.small.int PROC — outputs small integers as decimal digits for ANSI escape sequencesclear.screen — outputs ESC [2J directly as individual bytes instead of using write.string with an embedded escape charactermove.cursor — outputs the ANSI cursor positioning sequence directly using write.small.int, eliminating the dependency on write.formatted, DATA.ITEM protocol, and data.int variant tagterminal.keyboard and terminal.screen channel declarations — these were runtime-provided channels in the original occam 2 environmentVAL [n]TYPE abbreviations generated wrong Go type — VAL [8]INT nx IS [...] produced var nx int = []int{...} instead of var nx []int = []int{...}. Fixed by adding IsFixedArray flag to the AST Abbreviation struct and propagating it through parser → codegen.
ALT guard channels hardcoded to chan int — Guarded ALT cases created var _alt0 chan int = nil regardless of the actual channel type. Fixed by adding chanElemTypes tracking to the Generator, populated from channel declarations and proc parameters.
Both fixes apply to the package-level and function-scoped codegen paths.
The program compiles but won't run interactively since terminal.keyboard and terminal.screen are declared as plain Go channels with nothing connected to stdin/stdout. Making it fully runnable would require adding I/O goroutines to bridge these channels to the terminal.
Good work thanks. Interesting about the stdio channels. I think somehow we have support for that already because I've seen example programs that both print to stdout and react to input (e.g. there are programs in the examples for kroc's course module that do things like echo characters typed, and they work). Anyway, please create a PR for the work so far so we can get that into the mainline.
PR created: https://github.com/codeassociates/occam2go/pull/89
Regarding the stdio channels — you're right, there's likely existing support for that. The transpiler's built-in print procedures (write.full.string, etc.) map directly to fmt.Print, and the e2e tests that read input probably use a similar mechanism. The terminal.keyboard/terminal.screen channels in life.occ are a different pattern though — they're occam-style channels that the original transputer runtime provided as hardware-mapped I/O. Making them work would need goroutines bridging stdin/stdout to the Go channels. That could be a follow-up task if you want the program to actually run interactively.
I would look at the kroc example at ./kroc/modules/course/examples/double_echo.occ -- it looks like the course module has a way to pass in already open channels. If you transpile and run that example I think you'll see that it does in fact echo stdin to stdout. To make the game of life example use this pattern presumably it would need to be slightly re-written to use that same inversion of control pattern.
The controller PROC takes CHAN OF BYTE keyboard, screen without direction annotations. Since the entry point passes keyboard as <-chan byte (receive-only), it can't be passed to a function expecting bidirectional chan byte. The original book code didn't use direction annotations because that's the occam 2 style. I need to add them to controller and editor (and any other proc that takes these channels):
Pushed. The PR at https://github.com/codeassociates/occam2go/pull/89 now has two commits:
VAL [n]TYPE abbreviation types, channel element type tracking for ALT guardsPROC life (CHAN BYTE keyboard?, screen!, error!) so the transpiler auto-generates the stdin/stdout harness, plus adds direction annotations (?/!) to all PROCs that pass through the keyboard/screen channels, and fixes ALT guard variables to use <-chan (receive-only) so directional channels can be assigned to themThanks for the correction on the transputer I/O and pointing me to double_echo.occ — the entry point detection pattern was already there, the program just needed to use it.
Thank you. I tested the life example manually and it does seem to build and run. I need to research how to drive it from the keyboard still but this work is ready to be merged I think.
Merged and up to date. As for driving it — based on the source, once running it should respond to keyboard input: E to enter edit mode (arrow keys to move, */space to toggle cells), R to run, S to stop, and Q to quit. You may need to put the terminal in raw mode first so single keypresses get through without waiting for Enter.