ferd / erlang-history

Hacks to add shell history to Erlang's shell
493 stars 30 forks source link

erlang-history should include patches, not actual files #4

Closed baryluk closed 8 years ago

baryluk commented 12 years ago

I think it is better, or additionally to have synchronized patch files, so it is easier to apply them to newer kernel app versions.

Another issue, is to allow different code search path, so old files doesn't need to be overwritten.

The best way would be to allow dynamic patching of modules, but this would probably be hard to achive (especially considering performance and code-reloading). I guess, other possibility is to tell OTP team, to provide required hooks, so we can plug in (with elegant behaviour/callbacks description).

baryluk commented 12 years ago

BTW.

Here is patch version

--- /usr/lib/erlang/lib/kernel-2.14.5/src/group.erl 2011-10-25 16:13:43.000000000 +0200
+++ src/group.erl   2011-12-27 23:47:20.000000000 +0100
@@ -32,7 +32,7 @@
 server(Drv, Shell, Options) ->
     process_flag(trap_exit, true),
     edlin:init(),
-    put(line_buffer, proplists:get_value(line_buffer, Options, [])),
+    put(line_buffer, proplists:get_value(line_buffer, Options, group_history:load())),
     put(read_mode, list),
     put(user_drv, Drv),
     put(expand_fun,
@@ -644,6 +644,7 @@
 save_line_buffer(Line, [Line|_Lines]=Lines) ->
     save_line_buffer(Lines);
 save_line_buffer(Line, Lines) ->
+    group_history:add(Line),
     save_line_buffer([Line|Lines]).

 save_line_buffer(Lines) ->
ferd commented 12 years ago

Sorry, the holidays are a busy time for me.

I kind of think the whole thing is rather useless though because unless line numbers do not change along with the different versions, the diff file should be broken in the same way the group.erl file will be. Am I wrong there? If I am, I'll try and work on a system that lets you make a file based on a patch for the auto-installer, using the diff file. If I'm not, then I won't really re-work things because there would be no use.

I guess ideally we'd have files based on each version to gain full support, and the auto-install script would detect the version it's installing to and pick the right files based on that.

baryluk commented 12 years ago

Patch files are relativly immune to small line number changes. It is called fuzzy matching. Most patch utilis will try to patch file anyway, but with warning and how big offset from original position was.

ferd commented 12 years ago

I've just added a scheme where I've got different files for each version of the kernel application. This hopefully allows more flexibility as versions change, and I can maintain a general backward compatibility on more than one level.

The code above for patches was different for R13B04- and R14B+, so patches still needed versioning.

Do you think patches are still needed?

ferd commented 8 years ago

Inactive for years. Probably not gonna happen since the current scheme works pretty well for me, even though patches would objectively be lighter of a process.