A REPL #138

melsman · 2023-10-12T16:37:31Z

The purpose of this PR is to build a REPL for MLKit. Whereas the static aspects are mostly working, we need to decide on a mechanism for the dynamic aspects.

A Proposal

Separate the compiler and the dynamic executing code into two OS processes (by fork and child execute).
Have the two processes communicate via two named pipes (file descriptors).
The child process (to be completely implemented in C) should first load initialisation code that allocates the global regions. It should then wait for a command:
- PRINT ty L: On succes, reply with STR N s, where s is the result of pretty-printing the value of type ty located at location L and where N is the size of s.
- LOADRUN so-file L : Load the shared library file specified by so-file into the process and run its code specified by L. Before running the code, setup an exception handler that will print "Uncaught exception" in case of an uncaught exception. Reply with DONE on success and with EXN if an exception was raised.
- TERMINATE : Terminate the child process. Reply with DONE on success and with FAIL on failure.

An important design benefit of this approach is that the implementation is portable across Standard ML compilers, meaning that the Standard ML code involved does not depend on implementation details and dynamic linking support of a particular Standard ML compiler (the POSIX api will suffice). More specifically, the ML parent process, which hosts the compiler, will not need to perform any dynamic linking...

Progress

Open Questions

How do we generate shared object files from the generated assembly code. Answer: After generating position-independent object files (which MLKit does now), just generate a corresponding so-file with gcc -shared -o file.so file.o -l....
The type ty given to PRINT may be somewhat complex as the type needs to describe all datatypes used and the implementation details of each value constructor (i.e., boxity and tag). A nice aspect is that we can provide the "elaboration type" for shallow printing (without proceeding below abstract types) and the "implementation type" for deep printing (revealing the details of values with abstract types).
We would like to have C-level REPL support built into the existing runtime system (e.g., runtimeSystem.a). The entry point of the runtime system is the function main, which parses command-line arguments and calls the function code. For non-REPL code generation, link-code is generated, which defines the function code. For REPL code generation, we link in initialisation code generated with CodeGenX64.generate_repl_init_code(), which declares the code function.

The Child Process

The child process is a program (started with a fork/exec pattern) that consists of the relevant runtime system (in fact, runtimeSystemX.a contains the main function), generated assembler code for allocating global regions, and a message loop that waits for messages from the parent (see above) and reacts accordingly.

A Mini Proof of Concept (https://gist.github.com/melsman/f3e8f587140fc1b8c82f630255b24169)

Below is a mini proof of concept in terms of a Makefile and a bunch of C-files illustrating the idea. The main.c function acts as the loading driver and runtime.c is the runtime system (region management, C-level wrappers for ML code, etc). The files a.c, b.c, and c.c reflect toplevel declarations. Whereas a.c can refer to identifiers (labels) in runtime.c, b.c can also refer to identifiers (labels) declared in a.c. Notice that each toplevel declaration is compiled into a shared library that is loaded by main.c. Whereas the proof of concept just loads these shared libraries explicitly with calls to dlopen and runs the initialisation code for each toplevel declaration using calls to dlsym, the real implementation will include an interpreter that loads and initialises shared libraries as a result of LOADRUN calls.

File `Makefile`

CC=/usr/local/bin/gcc-12

all: main.exe libruntime.so liba.so libb.so libc.so

main.exe: main.c libruntime.so
	$(CC) -o $@ $< -L . -lruntime

libruntime.so: runtime.o
	$(CC) -shared -o $@ $<

liba.so: a.o
	$(CC) -shared -o $@ $< -L . -lruntime

libb.so: b.o liba.so
	$(CC) -shared -o $@ $< -L . -lruntime -la

libc.so: c.o liba.so libb.so
	$(CC) -shared -o $@ $< -L . -lruntime -la -lb

# ...

%.o: %.c
	$(CC) -c -fPIC -o $@ $<

.PHONY: clean
clean:
	rm -rf *~ *.o *.so main.exe

File `main.c`

#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>

void* loadrun(char* lib, char* run) {
  void* hndl = dlopen(lib, RTLD_NOW);
  if ( !hndl ) {
    fprintf(stderr, "load: Error loading %s - %s", lib, dlerror());
    exit(EXIT_FAILURE);
  }
  void (*f)() = (void(*)())dlsym(hndl,run);
  if ( !f ) {
    fprintf(stderr, "dlsym: Error resolving %s - %s", run, dlerror());
    exit(EXIT_FAILURE);
  }
  f();
  return hndl;
}

void print_int(void* hndl, char* id) {
  int v = *(int*)dlsym(hndl,id);
  printf("val %s : int = %d\n", id, v);
}

int main() {
  void* a_hndl = loadrun("liba.so", "a_run");
  print_int(a_hndl, "a_it");
  void* b_hndl = loadrun("libb.so", "b_run");
  print_int(b_hndl, "b_it");
  void* c_hndl = loadrun("libc.so", "c_run");
  print_int(c_hndl, "c_it");
  return 0;
}

File `runtime.c`

int neg(int a) { return -a; }

File `a.c`

int add(int a, int b) { return a + b; }   // local in fun add(a,b) = a+b
int a_it;                                 //          val it = add(8,2)
void a_run() { a_it = add(8,2); }         // end

File `b.c`

extern int neg(int a);           // in runtime
extern int add(int a, int b);    // in unit a
extern int a_it;
int muladd(int a, int b, int c) { return neg(neg(add(a * b, c))); }
int b_it;
void b_run() { b_it = add(a_it, muladd(a_it,2,100)); }

File `c.c`

extern int add(int a, int b);             // in unit a
extern int muladd(int a, int b, int c);   // in unit b
extern int a_it;
extern int b_it;
int muladdadd(int a, int b, int c) { return add(muladd(a, b, c),c); }
int c_it;
void c_run() { c_it = muladdadd(add(a_it,3),b_it,b_it); }

Running this program yields the following output:

bash-3.2$ ./main.exe 
val a_it : int = 10
val b_it : int = 130
val c_it : int = 1950

athas · 2023-10-13T09:58:24Z

Interesting model. Will code ever be unloaded again? I suppose resetting the REPL could be done simply by restarting the subprocess.

melsman · 2023-10-13T10:14:40Z

I cannot imagine good alternatives to the suggested model. The plan would be to allow code to grow in the child process with more and more dynamic libraries being loaded. One could of course imagine a kind of GC for discovering unreachable dynamic loaded libraries... Also mlb-file loading could be cached if there are no dependency breaks... I also think I need to use named pipes in order for the child process to read and write from and to the standard file descriptors... Do you have other (model) suggestions?

athas · 2023-10-13T10:35:37Z

I think this is a decent model. Here are the disadvantages I can think of:

Unclear when code/data can be freed.
Relatively high overhead for entering small expressions.
Unclear how value definitions will work in the LOADRUN model.
More movable parts (child process executable must be findable, must ensure it does not linger).

I don't think (1) is a big problem. Just make resetting the state (by resetting the process) an expected part of the workflow; e.g. by doing so whenever a file is freshly loaded. This is like ghci and futhark repl does it. The hyper-dynamic mutable environment model used by e.g. MosML is somewhat less common today.

(2) is probably also not a problem with the speed of modern computers, and the speed of MLKit. The delay will likely be noticeable (maybe 0.5 seconds?), but I don't think it will significantly impede productivity.

I think (3) is a bigger problem. My model for working with REPLs often involve doing a few value bindings and then poking at them. I suppose I could put them in files instead.

I suspect this goal is too optimistic:

An important design benefit of this approach is that the implementation is portable across Standard ML compilers.

Which Standard ML compilers could possibly be used this way? Except for MLKit, they all depend on heavy runtime systems, and e.g. MLton only supports whole program compilation. Also, most of them already have perfectly serviceable REPLs. While there is nothing wrong with a portable REPL per se, I don't think it is worth complicating the design in order to support portability.

melsman · 2023-10-13T12:02:03Z

The way MLKit generates code for toplevel value bindings is that it generates a fresh labeled slot (64 bit) (in the data segment), binds the variable name to the label, and execute code that fills the slot. All this fits very well with the `LOADRUN` model, which will usually be followed by a `PRINT`... My plan was to make everything work like MosML and SML/NJ with the property that the dynamic basis (value environment) is extended only if the topdec does not raise an exception, which is also why it is not sound to group-compile multiple toplevel declarations like ``` val a = 5; val _ = raise Div; ``` With respect to portability, what I meant was that the MLKit REPL could be compiled both with MLton and MLKit as the solution does not require special MLKit features at the ML level (e.g,. `Dynlib` : `DYNLIB`). Instead, all dynamic loading happens at the C level...

melsman · 2023-10-15T10:11:38Z

I have now updated the description with a mini proof of concept, which demonstrates how value declarations and linking will work...

athas · 2023-10-19T16:03:50Z

The diff is a bit hard for me to grasp, but I'm very much looking forward to trying this out! When do you think a runnable prototype is ready?

melsman · 2023-10-19T16:32:44Z

It already works: ``` bash-3.2$ rm -rf MLB && SML_LIB=. ./bin/mlkit MLKit v4.7.4 (v4.7.4-8-gd0770db9-dirty - 2023-10-06T13:44:36+02:00) [X64 Backend] Disabling garbage collection - it is not supported with the REPL . infix + - <; fun sum (n:int) : int = if n < 0 then 0 else n + sum(n-1); infix 0 + infix 0 - infix 0 < val sum = fn : int->int . exception MyExn . structure A = struct val a = 4.3 val b = sum 23 type t = bool end; structure A = struct type t = bool val a = 4.300000 : real val b = 276 : int end exception MyExn . ``` The next step is to load already compiled MLB-files... Not too hard, I think...

athas · 2023-10-23T10:03:50Z

Is this expected to work under Linux yet? I get a very long list of dynamic linker errors when starting bin/mlkit:

$ SML_LIB=. ./bin/mlkit
MLKit v4.7.5 (v4.7.5-9-g4bc3e018 - 2023-10-23T02:18:01+02:00) [X64 Backend]
Disabling garbage collection - it is not supported with the REPL
Type :help; for help...
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_muldi3.o): in function `__multi3':
(.text+0x0): multiple definition of `__multi3'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_muldi3.o):(.text+0x0): first defined here
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_negdi2.o): in function `__negti2':
(.text+0x0): multiple definition of `__negti2'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_negdi2.o):(.text+0x0): first defined here
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_lshrdi3.o): in function `__lshrti3':
(.text+0x0): multiple definition of `__lshrti3'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_lshrdi3.o):(.text+0x0): first defined here
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_ashldi3.o): in function `__ashlti3':
(.text+0x0): multiple definition of `__ashlti3'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_ashldi3.o):(.text+0x0): first defined here
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_ashrdi3.o): in function `__ashrti3':
(.text+0x0): multiple definition of `__ashrti3'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_ashrdi3.o):(.text+0x0): first defined here
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_cmpdi2.o): in function `__cmpti2':
(.text+0x0): multiple definition of `__cmpti2'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_cmpdi2.o):(.text+0x0): first defined here
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_ucmpdi2.o): in function `__ucmpti2':
(.text+0x0): multiple definition of `__ucmpti2'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_ucmpdi2.o):(.text+0x0): first defined here
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_clear_cache.o): in function `__clear_cache':
(.text+0x0): multiple definition of `__clear_cache'; /nix/store/h5kvfrjmpw792v8jg7nrzfkffmn0iyy8-gcc-12.3.0/lib/gcc/x86_64-unknown-linux-gnu/12.3.0/libgcc.a(_clear_cache.o):(.text+0x0): first defined here
...
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: ./lib/runtimeSystem.a(Runtime.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
/nix/store/74y3751gsixaz9797ib0hp7c658sp1y5-binutils-2.40/bin/ld: cannot find -lruntime: No such file or directory
collect2: error: ld returned 1 exit status
uncaught exception SysErr exec failed: No such file or directory

melsman · 2023-10-23T11:09:34Z

It seems that only my local Makefile (not Makefile.in) was setup to compile the runtime system with -fPIC. I'll run some tests and checkin a new version of Makefile.in...

melsman · 2023-10-23T15:52:40Z

There seems to be some issues with the dynamic linking under Linux (Ubuntu) that I cannot fix before having access to a physical machine or at least some development machine I can login to... @athas : any good suggestions for a machine I can login to at DIKU? The old gpu0x-servers mentioned at http://github.com/diku-dk/howto don't seem to work anymore and I have limited success with the hendrix cluster (I'm awaiting some approval on identity.ku.dk, I think)...

athas · 2023-10-23T16:41:13Z

You should have access to these.

melsman · 2023-10-24T19:03:21Z

It works now under linux to some extend:

mael@borg:~/mlkit$ uname -a
Linux borg 6.2.0-32-generic #32-Ubuntu SMP PREEMPT_DYNAMIC Mon Aug 14 10:03:50 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
mael@borg:~/mlkit$ rm -rf MLB && LD_LIBRARY_PATH=MLB/RI SML_LIB=. ./bin/mlkit
MLKit v4.7.5 (v4.7.5-13-ge7c3d35b - 2023-10-23T14:25:48+02:00) [X64 Backend]
Disabling garbage collection - it is not supported with the REPL
Type :help; for help...
. :load basis/basis.mlb;
/usr/bin/ld: warning: type and size of dynamic symbol `D.exn_DIV_aEVvxkLlDOnB1Tid8reifn' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `TopLevelHandlerLab' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `D.exn_SIZE_plABblGdISSt0pxClkLYIr' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `exnameCounter' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `D.exn_SUBSCRIPT_dpELiXqdrK4rAJtB3aGcNp' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `D.exn_OVERFLOW_b2uexLVzE8IkeyIStvA5Oa' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `D.exn_MATCH_3EbfP0vTHygkqnCyrZnRYe' are not defined
. print(IntInf.toString (23423423423423423423432432 * 45345345345345345) ^ "\n");
/usr/bin/ld: warning: type and size of dynamic symbol `D.cc1484_lab134_yqJZtbBlpSHLSNZBeKjYhj' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `TopLevelHandlerLab' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol `D.cc95_lab28_VDYTM6oj13TjPDYR4nHagr' are not defined
1062143224305386459459867956475394313229040
> val it = () : unit
.

Dynamic linking and position independent code works annoyingly differently with elf and mach-o... I still need to get rid of the ld warnings and to do something about having to set LD_LIBRARY_PATH...

athas · 2023-10-25T08:06:45Z

The sign bit in a nan is not meaningful. Does SML really require that you print it like that?

melsman · 2023-10-25T08:12:36Z

According to the Standard ML Basis Library manual, IEEEReal.toString should prepend the sign bit whereas Real.toString should collapse all nans to nan, which apparently leads to differences on different architectures...

melsman · 2023-10-25T08:15:15Z

Also notice that the REPL pretty-printer is not finalised and therefore does wrong things...

athas · 2023-10-31T11:41:48Z

Cool, it works!

I suggest terminating parsing at every newline. I also supported multi-line input in the Futhark REPL for a while, but I ditched it because it is ultimately too confusing for users. It is also annoying to have to type a semicolon after every input.

athas · 2023-10-31T12:01:19Z

If you enter EOF (Ctrl-d), the REPL will go into an infinite loop. This is because the PE.FAILURE case in Repl.sml calls repl recursively to "clear the state", which will itself enter the EOF condition, and so on.

melsman · 2023-10-31T14:53:19Z

I suggest terminating parsing at every newline. I also supported multi-line input in the Futhark REPL for a while, but I ditched it because it is ultimately too confusing for users. It is also annoying to have to type a semicolon after every input.

I kind of like the multi-line input support, which allows for general pasting of source code with newlines...

athas · 2023-10-31T16:07:27Z

It's your call, but you can look forward to spending the rest of your life answering questions from users as to why nothing happens when they enter an expression.

melsman · 2023-10-31T16:10:09Z

It's your call, but you can look forward to spending the rest of your life answering questions from users as to why nothing happens when they enter an expression.

I'll just ask them to try out the example with MosML... ;)

kfl · 2023-11-01T08:42:43Z

I'm sure that the well-oiled Moscow ML support team can handle the torrent of MLKit REPL users.

Beside, SML users seems to be rather proficient using a REPL. It has been at least a decade since I got a question like the one @athas is worried about.

athas · 2023-11-01T08:47:57Z

That is because there have been no new SML users since then.

athas · 2023-11-02T09:57:01Z

Hooray, the day of interactive MLKit is upon us!

initial work on repl

02a5cf8

melsman added the enhancement label Oct 12, 2023

melsman self-assigned this Oct 12, 2023

melsman marked this pull request as draft October 12, 2023 17:06

melsman mentioned this pull request Oct 12, 2023

REPL? #123

Closed

melsman added 3 commits October 19, 2023 16:49

progress

5bea724

fix

8737db9

parse end fixes

e2f7022

melsman added 5 commits October 20, 2023 17:36

support for commands

a31a169

menu support and support for flags with arguments

8cf0229

mlb-file loading

7941493

fix

d19c888

:load help

4bc3e01

melsman added 4 commits October 23, 2023 13:24

position independet code and Repl inclusion

727147e

repl testing

02d1ee1

fix

95ba1b5

new fix

e7c3d35

melsman added 2 commits October 24, 2023 18:41

cleanup

2c7db9a

fix

82c13f5

melsman added 5 commits October 24, 2023 21:06

fix

c968bf0

avoid LD_LIBRARY_PATH on Linux

88eb1e1

adding types to global labels to avoid linker warnings

9551f2c

fix repl linker issue on linux by adding rpath

2b64d37

fix pretty-printing of negative nans on Linux

0d7a324

melsman added 5 commits October 30, 2023 14:28

repl pretty-printing first go

6881c73

some fixes

58a107c

fix

ea8b5fd

bug fix

bfb780b

debug

cddad62

fix Control-d (eof) problem and other cleanup

33cea95

melsman added 2 commits November 1, 2023 01:23

robust type printing for REPL type-indexed pretty-printing

ffd9f32

no-pretty fix

a63cfcc

melsman added 3 commits November 1, 2023 11:58

buffer resizing

5a4622f

support for control of printing depth and string printing cutoff

bf19e91

support for multiple concurrent REPL sessions

261b6fd

melsman marked this pull request as ready for review November 1, 2023 23:16

melsman merged commit 685fe42 into master Nov 2, 2023
4 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A REPL #138

A REPL #138

melsman commented Oct 12, 2023 •

edited

Loading

athas commented Oct 13, 2023

melsman commented Oct 13, 2023 via email •

edited

Loading

athas commented Oct 13, 2023

melsman commented Oct 13, 2023 via email •

edited

Loading

melsman commented Oct 15, 2023 via email •

edited

Loading

athas commented Oct 19, 2023

melsman commented Oct 19, 2023 via email •

edited

Loading

athas commented Oct 23, 2023

melsman commented Oct 23, 2023

melsman commented Oct 23, 2023

athas commented Oct 23, 2023

melsman commented Oct 24, 2023

athas commented Oct 25, 2023

melsman commented Oct 25, 2023 via email •

edited

Loading

melsman commented Oct 25, 2023 via email •

edited

Loading

athas commented Oct 31, 2023

athas commented Oct 31, 2023

melsman commented Oct 31, 2023

athas commented Oct 31, 2023

melsman commented Oct 31, 2023

kfl commented Nov 1, 2023

athas commented Nov 1, 2023

athas commented Nov 2, 2023

A REPL #138

A REPL #138

Conversation

melsman commented Oct 12, 2023 • edited Loading

A Proposal

Progress

Open Questions

The Child Process

A Mini Proof of Concept (https://gist.github.com/melsman/f3e8f587140fc1b8c82f630255b24169)

File Makefile

File main.c

File runtime.c

File a.c

File b.c

File c.c

athas commented Oct 13, 2023

melsman commented Oct 13, 2023 via email • edited Loading

athas commented Oct 13, 2023

melsman commented Oct 13, 2023 via email • edited Loading

melsman commented Oct 15, 2023 via email • edited Loading

athas commented Oct 19, 2023

melsman commented Oct 19, 2023 via email • edited Loading

athas commented Oct 23, 2023

melsman commented Oct 23, 2023

melsman commented Oct 23, 2023

athas commented Oct 23, 2023

melsman commented Oct 24, 2023

athas commented Oct 25, 2023

melsman commented Oct 25, 2023 via email • edited Loading

melsman commented Oct 25, 2023 via email • edited Loading

athas commented Oct 31, 2023

athas commented Oct 31, 2023

melsman commented Oct 31, 2023

athas commented Oct 31, 2023

melsman commented Oct 31, 2023

kfl commented Nov 1, 2023

athas commented Nov 1, 2023

athas commented Nov 2, 2023

melsman commented Oct 12, 2023 •

edited

Loading

File `Makefile`

File `main.c`

File `runtime.c`

File `a.c`

File `b.c`

File `c.c`

melsman commented Oct 13, 2023 via email •

edited

Loading

melsman commented Oct 13, 2023 via email •

edited

Loading

melsman commented Oct 15, 2023 via email •

edited

Loading

melsman commented Oct 19, 2023 via email •

edited

Loading

melsman commented Oct 25, 2023 via email •

edited

Loading

melsman commented Oct 25, 2023 via email •

edited

Loading