I want to implement UNDO and REDO option(as we see in MS word etc). Can you suggest me a data structure for it, and how can i implement it.?
It isn't a data structure but a design pattern. You're looking for the Command Pattern.
The standard is to keep the Command objects in a stack to support multi level undo. In order to support redo, a second stack keeps all the commands you've Undone. So when you pop the undo stack to undo a command, you push the same command you popped into the redo stack. You do the same thing in reverse when you redo a command. You pop the redo stack and push the popped command back into the undo stack.
Actually, the standard pattern for this functionality (Gang of Four, even) is Memento.
Also, while most programs use Undo/Redo stacks, afficionados of certain text editors prefer Undo/Redo trees so that they don't lose their entire history if they undo a few commands, try a new one, and change their minds.
Objective-C Cocoa has a well documented anwser named NSUndoManager.
You can use Command Pattern to achive Undo/Redo
Check these samples:
http://www.codeproject.com/csharp/undoredobuffer.asp
http://www.dofactory.com/Patterns/PatternCommand.aspx
This is a classic case of Command Pattern. Following is a sample implementation of undo feature in Python :
from os import rename
class RenameFileCommand(object):
def __init__(self, src_file, target_file):
self.src_file=src_file
self.target_file=target_file
def execute(self):
rename(self.src_file, self.target_file)
def undo(self):
rename(self.target_file,self.src_file)
class History(object):
def __init__(self):
self.commands=list()
def execute(self, command):
command.execute()
self.commands.append(command)
def undo(self):
self.commands.pop().undo()
if __name__=='__main__':
hist=History()
hist.execute(RenameFileCommand( 'test1.txt', 'tmp.txt', ))
hist.undo()
hist.execute(RenameFileCommand( 'tmp2.txt', 'test2.txt',))
Related
I am working on a solution for technical drawings (svg/ruby). I want to manipulate rectangles, and have an add! method in this class:
class Rect
def add!(delta)
#x1+=delta
... # and so on
self
end
end
I also need an add method returning a Rect, but not manipulating self:
def add(delta)
r=self.dup/clone/"copy" # <-- not realy the 3 and no quotes, just in text here
r.add! delta
end
dup and clone don't do my thing but:
def copy; Marshal.load(Marshal.dump(self)); end
does.
Why does such a basic functionality not exist in plain Ruby? Please just don't tell me that I could reverse add and add!, letting add do the job, and add! calling it.
I'm not sure why there's no deep copy method in Ruby, but I'll try to make an educated guess based on the information I could find (see links and quotes below the line).
Judging from this information, I could only infer that the reason Ruby does not have a deep copy method is because it's very rarely necessary and, in the few cases where it truly is necessary, there are other, relatively simple ways to accomplish the same task:
As you already know, using Marshal.dump and Marshal.load is currently the recommended way to do this. This is also the approach recommended by Programming Ruby (see excerpts below).
Alternatively, there are at least 3 available implementations found in these gems: deep_cloneable, deep_clone and ruby_deep_clone; the first being the most popular.
Related Information
Here's a discussion over at comp.lang.ruby which might shed some light on this. There's another answer here with some associated discussions, but it all comes back to using Marshal.
There weren't any mentions of deep copying in Programming Ruby, but there were a few mentions in The Ruby Programming Language. Here are a few related excerpts:
[…]
Another use for Marshal.dump and Marshal.load is to create deep copies
of objects:
def deepcopy(o)
Marshal.load(Marshal.dump(o))
end
[…]
… the binary format used by Marshal.dump and Marshal.load is
version-dependent, and newer versions of Ruby are not guaranteed to be
able to read marshalled objects written by older versions of Ruby.
[…]
Note that files and I/O streams, as well as Method and Binding
objects, are too dynamic to be marshalled; there would be no reliable
way to restore their state.
[…]
Instead of making a defensive deep copy of the array, just call
to_enum on it, and pass the resulting enumerator instead of the array
itself. In effect, you’re creating an enumerable but immutable proxy
object for your array.
Forget marshalling. The deep_dive gem will solve your problems.
https://rubygems.org/gems/deep_dive
Why can't you use something like this:
new_item = Item.new(old_item.attributes)
new_item.save!
This would copy all the attributes from existing item to new one, without issues. If you have other objects, you can just copy them individually.
I think it's the quickest way to copy an object
I am trying to keep my classes encapsulated as much as possible. Any reason that I should not use the send method like this?
class MyClass
def self.join_two_strings(first, second)
new.send(:join_two_strings, first, second)
end
def join_two_strings(first, second)
first + second
end
private :join_two_strings
end
Since #join_two_strings doesn't actually need any instance state, it should just be a class method.
class MyClass
def self.join_two_strings(first, second)
first + second
end
end
Yes, there is reason not to do that. It is because it is verbose. To achieve what you want, you should code like in Chris Heald's answer. (Chris Heald suggests what you should do, but does not answer your question).
To call the problem with your use of #send even more precisely, it is not verbosity, but obscuring of the design intent. Sometimes verbosity (such as using full words, rather than abbreviations) serves to reveal the design intent and shorten the time reader needs to understand your code. With your code example, the reader does not believe that what you want to achieve is mere joining of 2 strings, they keep searching for deeper meaning, before conceding that it is just a complicated method to do a simple thing (and possibly refactoring your code as Chris did). As for #send itself, do not fear it, do not fear to use it. Though #send should not be used as a tool to arbitrarily disrespect privacy of methods, on the other hand, Ruby methods are messages and you don't have to worry to be explicit about it, where there is a reason for it.
I am working on a code parser that is built on Rexx. It is a single file script with around 5000 lines of code or more. I've never worked on Rexx before. Adding to that, the readability issue is making my life even tougher. So,
Are there are any tools to debug and understand Rexx code?
Use the trace statement? The most simple mode of tracing is 'A'. This causes each instruction to be displayed before it is executed. Your instruction is displayed with a line number and the three characters - preceding it, so that you can identify it as a line in your script.
Wikipedia has a pretty good article on Rexx, which should help you understand Rexx syntax and program structure. And almost any Rexx book will apply to your environment, because Rexx is extremely cross-system (similar in that way to the younger Perl and Python languages). There aren't a lot of online books, because almost everything written about Rexx was written before the web existed, but the reference manual for the Regina implementation is, and it's a particularly good reference work.
The date on this question is old, but I'll share what I have found helpful for the next person who pulls this up.
Already mentioned is the TRACE option. I've found this can be overwhelming in a small set of code let alone 5,000 lines or more.Here are some options I've found useful:
Use an "if" to turn the trace on only in certain situations.if counter < 25 then trace "A" Be sure to turn the trace off with:else trace "OFF"
Use say followed by pull. What is said will stay on the screen until you hit enter.
Add a subroutine:
AskIt:
parse pull comment
say comment
say 'enter "X" to exit program'
pull continueif Continue \= "X" then returnexit
This is invoked with call AskIt "In routine that loops, counter=" counter and would display: In routine that loops counter='##enter "X" to exit programThe tester chooses to return to the code by hitting enter or exit the program with X to edit the source.Temporarily inserting return on the line following the routine label will allow you to run the code uninterrupted without removing all the calls.
I have written an edit macro for z/OS which inserts a say *routine name* after every routine label. It inserts the code with a /* comment */ containing a readily identified phrase to simplify cleanup.The audience for this would be small, so I'll not include the code here.
Hope this helps someone.
This seems to me to be a novel idea (since i haven't found any solutions or anyone having implemented it)...
A shell script that automatically runs whenever you git commit or whatever that will let you know if you forgot to delete any debugging or development env specific lines of code in your project.
For example:
Often times (in my Ruby projects) I'll leave lines of code to output variables like
puts params.inspect
or
raise params.inspect
Also, sometimes I'll use different methods so I can easily see the effects such as in cases like using delayed_job where I'd rather call the method without a delay during development.
The problem is sometimes I forget to change those methods back or forget to delete a call to raise params.inspect and I'll inadvertently push that code.
So I thought maybe the simplest solution was to add a comment to any such debugging line such as
raise params.inspect #debug
In essence flagging that line as a development only/debug line. Then in a shell script that runs before some other command like git commit it can use awk or grep to search through all the latest modified files for that #debug comment and stop execution and alert you. However i don't know much about shell scripting so I thought I'd ask for help :)
Although I whole-heartedly recommend following cdeszaq'a advice and discourage doing this sort of thing, it is pretty easy to write a git hook that will prevent you from committing any lines with a particular string. For simplicity, I'm not showing the git rev-parse --verify HEAD that you should use to make this hook work on an initial commit, but if you simply put the following in .git/hooks/pre-commit (and make it executable), you will not be able to commit any lines of code that contain the string '#debug':
#!/bin/sh
if git diff-index -p -M --cached HEAD | grep '#debug' > /dev/null; then
echo 'debug lines found in commit. Aborting' >&2
exit 1
fi
Rather than having to remember to do additional work (removing lines of code) only to have to do more work later when things break again (re-adding that code), why not put in sensible debugging statements from the beginning?
Most languages have fairly expressive and often cheap logging libraries that will allow you to write out various levels of information (error, info, debug, trace) to a number of different locations (a file, a database). Many of these libraries will even let you adjust the logging level for a specific chunk of the code at runtime or even while the program is running.
So, rather than try to bandage up brute-force debugging by scripting away the problem, why not do yourself, and the rest of the world that has to use what you produce, a favor and use an actual logging framework for logging?
As I said in my comment, you can use any programming language you feel comfortable with.
Anyway, searching for other commit hooks, I think this one could be a good one to start with. It basically looks for some words in your files and can be customized just changing the checks array in the top of the file.
#cdeszaq is correct about the logging part.
For behaviour that differs depending on environment, the common way to achieve this is to make the behaviour configurable. delayed_job should read a value from the config file to decide how long to delay. For production environments the config would have one value and for development environments the config would have a different value.
I'm considering how to do automatic bug tracking and as part of that I'm wondering what is available to match source code line numbers (or more accurate numbers mapped from instruction pointers via something like addr2line) in one version of a program to the same line in another. (Assume everything is in some kind of source control and is available to my code)
The simplest approach would be to use a diff tool/lib on the files and do some math on the line number spans, however this has some limitations:
It doesn't handle cross file motion.
It might not play well with lines that get changed
It doesn't look at the information available in the intermediate versions.
It provides no way to manually patch up lines when the diff tool gets things wrong.
It's kinda clunky
Before I start diving into developing something better:
What already exists to do this?
What features do similar system have that I've not thought of?
Why do you need to do this? If you use decent source version control, you should have access to old versions of the code, you can simply provide a link to that so people can see the bug in its original place. In fact the main problem I see with this system is that the bug may have already been fixed, but your automatic line tracking code will point to a line and say there's a bug there. Seems this system would be a pain to build, and not provide a whole lot of help in practice.
My suggestion is: instead of trying to track line numbers, which as you observed can quickly get out of sync as software changes, you should decorate each assertion (or other line of interest) with a unique identifier.
Assuming you're using C, in the case of assertions, this could be as simple as changing something like assert(x == 42); to assert(("check_x", x == 42)); -- this is functionally identical, due to the semantics of the comma operator in C and the fact that a string literal will always evaluate to true.
Of course this means that you need to identify a priori those items that you wish to track. But given that there's no generally reliable way to match up source line numbers across versions (by which I mean that for any mechanism you could propose, I believe I could propose a situation in which that mechanism does the wrong thing) I would argue that this is the best you can do.
Another idea: If you're using C++, you can make use of RAII to track dynamic scopes very elegantly. Basically, you have a Track class whose constructor takes a string describing the scope and adds this to a global stack of currently active scopes. The Track destructor pops the top element off the stack. The final ingredient is a static function Track::getState(), which simply returns a list of all currently active scopes -- this can be called from an exception handler or other error-handling mechanism.