Closed baryluk closed 8 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) ->
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.
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.
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?
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.
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).