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

baryluk opened this Issue Dec 27, 2011 · 5 comments


None yet
2 participants

baryluk commented Dec 27, 2011

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 Dec 27, 2011


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),
-    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),
@@ -644,6 +644,7 @@
 save_line_buffer(Line, [Line|_Lines]=Lines) ->
 save_line_buffer(Line, Lines) ->
+    group_history:add(Line),

 save_line_buffer(Lines) ->

ferd commented Dec 30, 2011

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 Dec 30, 2011

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 Feb 8, 2012

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 Jun 22, 2016

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.

@ferd ferd closed this Jun 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment