bittercode / pyrrhic-ree

pyrrhic regular expression editor
GNU General Public License v2.0
9 stars 1 forks source link

Some Menu entries aren't implemented. #6

Open PythonicChemist opened 11 years ago

PythonicChemist commented 11 years ago

This is just a list of menu entries, which are listed but not implemented:

bittercode commented 11 years ago

Yes - the open and save is the one that will take some coding. It's to save the settings and such.

If I remember right the help stuff was mostly links to on-line docs. There is also a set of instructions and screen shots that are a part of Kodos that could be used (or not) as a guide to creating some documentation for the program itself. I just hadn't gotten around to any of that yet.

bahostetterlewis commented 11 years ago

you could implement a save function really easily for settings and state by just saving a json object and the open could read it in. It wouldn't be very hard to do and would work exactly as intended.

PythonicChemist commented 11 years ago

Links to online docs should be easy to implement. We just need to check which python version is installed and use the proper link to the docs, which url only changes a tiny bit per version. Is saving regex with a description planned? I thought "regex library" was meant for it, but if it isn't, it would be a neat feature. I should try out the original kodos... Clearly we will have to wait until thebearbear has finished his refactor to further improve this program. I'll code the online doc functions tomorrow. If I get it working I will push it as an extra module for now, so thebearbear can include it in his refactor.

PythonicChemist commented 11 years ago

I would use the following for library: http://docs.python.org/3.3/library/re.html and this link for guide: http://docs.python.org/3.3/howto/regex.html I'm not quite sure what to use for "Python Regex Help". Maybe writing a cheatsheet for a quick look?

bahostetterlewis commented 11 years ago

I think the help section depends on what we mean by help. On the Python regex docs you linked there is a huge section talking about special characters. That could be considered part of the help at least. We should define exactly what should be in the help section and go from there.

bahostetterlewis commented 11 years ago

One thing that might be cool is a recipe book. Users could add regex recipes, and quick load them.

PythonicChemist commented 11 years ago

This is definitely something I would like to implement in the future. I had the idea of distributing a default recipe book which can be modified from the user or the user creates a whole new one for different purposes etc. If we implement it, I think it will be our killer feature. If done right it will be just too useful to simply pass on it. Layout maybe: Regex|Example|Comment

maybe add a column for examples which will NOT be matched to further clarify the regex. I love your idea definitely +1 from me!

PythonicChemist commented 11 years ago

So I finally installed Kodos and looked up what the helping section is all about.

"Python Regex Help" is the official documentation about the module.

"Python Reference Guide" is pretty much just a cheat sheet. We may want to provide a quick cheat sheet so that a new regex user can keep it open if he is quite uncertain about syntax. I think a cheat sheet would be great especially if we bind it to a shortcut.

"Regex Library" is similiar to what we want to achieve with the cookbook feature just that it isn't configurable by the user.

So my proposal is that we have a link to the official howto and library documentation plus an entry for a quick cheat sheet. Personally I would call the entries:

Python Regex Cheatsheet ---> syntax in a nutshell for quick review Python Regex HowTo ---> link to the official regex howto Python Regex Library ---> link to the official regex library documentation

What do you think? Also the functions of "undo" and "redo" are missing. I'll edit my first post to make a checklist.

bahostetterlewis commented 11 years ago

I was interested in undo and redo and built a proof of concept system that we can use soon. proof of concept

It doesn't require the view code to change anything but integrates it seamlessly into the controller. Really clean implementation - not much code - and replicates the type of undo in most programs (includeing chrome).

PythonicChemist commented 11 years ago

The proof of concept looks great. You seem to have some ideas up your sleeves for this project. :)

bahostetterlewis commented 11 years ago

Yeah it is the reason I'm putting so much time into the refactor, it makes a TON of stuff possible, like the undo/redo. It could be done before hand but it wouldn't have been as simple to implement. There is a lot of potential to this project (especially because I've wanted something like this for so long!) :smile:

PythonicChemist commented 11 years ago

I really like regex and I like python so this is a very good project for me. :)

I am interested in addressing basic stuff after refactor: unittesting, pep8, automatic documentation, restructuring, setup.py for pip, versioning and milestones for said versions ...

I am new to programming so I would like to use this chance to learn these basics. :)

bahostetterlewis commented 11 years ago

Restructuring is what the refactor is so I can explain any steps there if you are interested. Most of those things I can answer as I do most of them for work and personal projects. If you have general questions I can show you some examples and such. I have been programming for a while so I would be glad to pass on any info.

PythonicChemist commented 11 years ago

Can you send me an email at mercya@web.de it is my spam mail. I will contact you with my personal email then. :)

I meant with restructuring the folders (core,gui etc) so we have a more clear structure where certain things are. Right now for the size of the project it may be a bit too much, but as this projects grows I think it will be handy.

bahostetterlewis commented 11 years ago

Undo and Redo are implemented on my branch off of refactor if you want to check it out. We can work on optimizing it in the future if needed, it is just a beta version. I need someone to plug it into a GUI because I don't have a QT window editor and the pregened code is nasty to read.

PythonicChemist commented 11 years ago

I can't plug it into the GUI since I have no clue about QT. I can try to bind your refactor into my beta gui though.

PythonicChemist commented 11 years ago

how about a keybinding to test it? Sorry cant edit post from my tablet.

bahostetterlewis commented 11 years ago

I redid undo to be a function decorator. This makes it trivial to add undo and redo to anywhere we want. I would like any comments on it.

PythonicChemist commented 11 years ago

So to be clear that I understand everything:

The actual undo and redo functions are just throwing exceptions and the magic is happening in the decorators? Also you return a function object with the reverting, but the function object is never executed as far as I can see. How will you implement a limit history? I think that there should be a limit for the list of redoable and undoable actions. Personally I would have put the undo and redo logic in their functions and used the decorators to cache the actions to the self._undo and self._redo lists.

I haven't fully grasped the interactions with function objects, so I will try some coding with it and build similiar code like yours to play around. I still have a lot to learn. :)

I'm pretty sure I missed a lot of the functionalities of your design so be free to explain further and comment.

bahostetterlewis commented 11 years ago

The decorator causes state to be saved via a command pattern-esque function before a function executes. These are functions that use a closure to maintain the state. These dynamic functions, when run, revert the state of the object back to what it was when the function was created. Thus we have undo. The decorator is basically a state cacher. Any function it decorates will have the state saved and added to the undo stack before it is executed. The undo functions are called during the self._undo.pop()(). That pops off a function from the stack and then calls it immediately. We can limit history in the decorators if we want to. Memory is so cheap though that I think this is a premature opt, at this point as our program has almost 0 mem footprint so I don't think we are in danger.

The actual undo and redo functions dont throw exceptions. They are EAFP style. They just pretend they can pop (the general case) and ignore the empty list error.

#current way, assumes can pop, ignores failures but dosn't do anything
try:
    stack.pop()
catch IndexError:
    pass

#Other - kind of valid but not as simple
if stack:
    stack.pop()
PythonicChemist commented 11 years ago

Okay then the only thin I missed was double () in the undo/redo function. Now everythin is perfectly clear.

When it is implemented and merged into master, I will see how much memory will be occupied. Note: I usually have a uptime of 60+ days, so we will see how much memory usage is accumulating. You will be probably correct with the premature optimization though.

bahostetterlewis commented 11 years ago

When you say uptime of 60 days, do you mean you run this program for 60 days without ever exiting or do you mean that your computer runs 60 days without turning off?

PythonicChemist commented 11 years ago

60 days of not turning my computer off, but usually I do not close programs if I do not need to. If I run out of my 1gb ram, I usually just close firefox. I normally use 120-300mb of ram without firefox. So I rarely close my programs.

bahostetterlewis commented 11 years ago

Well i guess that is pretty extreme usecase so if there is an issue we can change it. Try it out and see what happens.

PythonicChemist commented 11 years ago

I wouldn't consider it extreme. I'm sometimes at a local computer group and some guys are restarting twice a year. Suspending and Hibernation are so much faster than rebooting plus you never need to bother about starting your applications. In the linux world it is quite common to prefer suspend/hibernation over shutdown.

But oh well let's see how it turns out when it hits master. :)

bahostetterlewis commented 11 years ago

By extreme I mean running the regex debugger for 60 days is probably not the normal usecase for our system.

PythonicChemist commented 11 years ago

Yep.

Well how are we going to implement new functionality into the gui, when bittercode is currently unavailable. I'm currently busy with oop, tk and university so I do not have time to learn pyqt.

bahostetterlewis commented 11 years ago

If I get the GUI creator he was using I can start working on it. I just don't want to read the xml that it generated. Right now I'm just building the api system so honestly you could attach your TK View onto the system without needing oop other than what is required by TK. Just call the functions available and it will return everything you need to display all the data available in the Qt gui.