Make the reload form that does dependency graph recompile&reload of any changed files #422

New issue

vyzo · 2019-12-09T14:54:54Z

adam-7 commented

2019-12-09 14:54:54 +00:00

(Migrated from github.com)

This feature has been waiting for many weeks:

Make the reload form that does dependency graph recompile&reload of any changed files.

The purpose is to enable incremental development, without restarting the whole gerbil environment. This means the latest version of modules will be reloaded so that they in a relatively dirty or blunt fashion overload their own old version. This will not work for all modules, but it will tend to work and this way serve as a quick and dirty code injection facility.

For use from repl, no idea if this would be relevant from some ide.

Looking forward to test ASAP, thanks!

This feature has been waiting for many weeks: Make the reload form that does dependency graph recompile&reload of any changed files. The purpose is to enable incremental development, without restarting the whole gerbil environment. This means the latest version of modules will be reloaded so that they in a relatively dirty or blunt fashion overload their own old version. This will not work for all modules, but it will tend to work and this way serve as a quick and dirty code injection facility. For use from repl, no idea if this would be relevant from some ide. Looking forward to test ASAP, thanks!

vyzo commented

2019-12-09 16:18:45 +00:00

(Migrated from github.com)

Please be more considerate when asking for features.
Demanding stuff like that doesn't make them implement themselves; all it achieves is pissing off the developers.

Please be more considerate when asking for features. Demanding stuff like that doesn't make them implement themselves; all it achieves is pissing off the developers.

👍 3

adam-7 commented

2019-12-13 08:12:48 +00:00

(Migrated from github.com)

Yes sure. Your original promise was you'd make this one two months ago. I totally see how priorities swamp and sometimes schedules grow totally unexpectedly, all fine.

I keep coming back to this one as it is the point where Gerbil has become an incremental dev tool.

(At least outside Emacs, could imagine there's some trick in Emacs for the same effect.)

If I got you right it's relatively low complexity for you who know the codebase, to implement.

Thanks again for Gerbil and can't wait to feed it with lots of code soon 😊

Yes sure. Your original promise was you'd make this one two months ago. I totally see how priorities swamp and sometimes schedules grow totally unexpectedly, all fine. I keep coming back to this one as it is the point where Gerbil has become an incremental dev tool. (At least outside Emacs, could imagine there's some trick in Emacs for the same effect.) If I got you right it's relatively low complexity for you who know the codebase, to implement. Thanks again for Gerbil and can't wait to feed it with lots of code soon 😊

adam-7 commented

2020-01-02 15:11:18 +00:00

(Migrated from github.com)

@vyzo hi Vyzo could you implement this before the holiday is over now or next days anyhow?

original plan was mid Oct right

@vyzo hi Vyzo could you implement this before the holiday is over now or next days anyhow? original plan was mid Oct right

adam-7 commented

2020-02-13 13:18:31 +00:00

(Migrated from github.com)

@vyzo hi Vyzo, we've been waiting about four months now, if you'd like to implement it would be wonderful! Any ETA?

adam-7 commented

2020-03-31 02:23:22 +00:00

(Migrated from github.com)

@vyzo bump on this one 👍

@vyzo bump on this one :+1:

adam-7 commented

2020-05-09 23:49:16 +00:00

(Migrated from github.com)

@vyzo Hi Vyzo, have you looked at this one? Would be awesome, best regards

fare commented

2020-05-10 03:41:40 +00:00

(Migrated from github.com)

Not going to happen soon. It would require some deep rewiring of the system. Also, the dependency graph may change, and then—what to load or not load?

On the other hand, you could use the data from your build.ss to rebuild all the things that need to be rebuilt for your desired targets—and make.ss is indeed incremental now. So the question is whether you can make things more like CL's ASDF and rebuild "the system"—and then also its dependencies?—when source code changes.

Not going to happen soon. It would require some deep rewiring of the system. Also, the dependency graph may change, and then—what to load or not load? On the other hand, you could use the data from your `build.ss` to rebuild all the things that need to be rebuilt for your desired targets—and `make.ss` is indeed incremental now. So the question is whether you can make things more like CL's ASDF and rebuild "the system"—and then also its dependencies?—when source code changes.

vyzo commented

2020-05-10 07:20:43 +00:00

(Migrated from github.com)

You can implement it in userland by specifying a custom import hook; this way you can take complete control of the import process and implement fancy recompliation and reloading that suits you needs.

You can implement it in userland by specifying a custom `import` hook; this way you can take complete control of the import process and implement fancy recompliation and reloading that suits you needs.

👍 1

fare commented

2020-05-10 20:22:25 +00:00

(Migrated from github.com)

^ Even that is a lot of work, and not likely to happen soon. But at least it's a well-defined task, with well-known implementation strategies.

Other note: because systems get built on one machine then updated on another, using different timestamps, with race conditions when multiple processes may be compiling them, it would be nice if a fast cryptographic function like BLAKE3 were used instead of flaky timestamps to identify the inputs of the file loaded in the current (or being-debugged) image. This would necessitate the hash being made available early on via FFI, before the stdlib itself is compiled.

^ Even that is a lot of work, and not likely to happen soon. But at least it's a well-defined task, with well-known implementation strategies. Other note: because systems get built on one machine then updated on another, using different timestamps, with race conditions when multiple processes may be compiling them, it would be nice if a fast cryptographic function like BLAKE3 were used instead of flaky timestamps to identify the inputs of the file loaded in the current (or being-debugged) image. This would necessitate the hash being made available early on via FFI, before the stdlib itself is compiled.

vyzo referenced this issue

2026-10-05 21:41:04 +00:00

Pin Gambit with safe-context internal primitive inlining #1511

vyzo referenced this issue from a commit

2026-10-09 18:33:05 +00:00

Pin Gambit with safe-context internal primitive inlining (#1511)

Sign in to join this conversation.