Wednesday, July 28, 2010

More Fixes and Features for Paladin

I spent a great deal of time today doing more hacking on Paladin, a trend I've had the last week or so when I wasn't working on getting my book out the door. The Code Library feature, for now, has been withdrawn until I can get it working well, which it just doesn't right now -- everything works the right way except for synchronization, which is the entire point behind the feature. The code for it is still there, but it won't be enabled for the next release. I fixed several really annoying bugs, including workarounds for two bugs in Haiku which took a lot of effort to find but were trivial to work around once found. One of them is project files being mistakenly identified as plain text files.

Source control is the star feature for the next release. I intend to make it about as easy as possible to integrate source control into a developer's workflow as possible. It took me a long time to really "get it," but now that I do, I want others to have an easy time using it without having to learn command line syntax until they're ready to do so. The only thing that I currently have on the to-do list before the release is to polish and test the different ways that source control is used. Once that's done, I'll be putting out a release. I really love this project -- the rewards are incredibly satisfying. :)

5 comments:

  1. While lurking your latest changesets, I saw that you take care to wrap any path or filename between quote before running an external command.

    That's great, but will still break if the path or file have one or more quote in it. Think about a project folder named [It's Urgent] for instance.

    You must escape any quote (' -> \' ) in argument before wrapping in quote.

    Another (better if you ask me) solution will to switch to strings array for holding commands and their arguments. But that requires to update far more code...

    ReplyDelete
  2. I didn't think of that. With all of the use that I get out of system() in my projects, I think I'll write (or find) something to make stuff like that a lot less headache. Thanks for pointing this out. :)

    ReplyDelete
  3. Quick question. I am writing a program that uses a sqlite db. If I run my program from paladin using "Run" and call a select, it says the table doesn't exist. If I run my program from paladin using "Run Logged", the table exists and the select returns the expected results. What is the difference between "Run" and "Run Logged" so I can try to figure out this issue? thanks.

    ReplyDelete
  4. Try running Paladin from the Terminal in debug mode like this:

    $ Paladin -d

    and then try each way. Debug mode spits out a lot of stuff to the console about what it's doing internally and is very helpful for when you're not sure if you're doing something wrong or if Paladin is. When you run your program regularly, Paladin will print a line that starts with "Run command: " and running logged will print a line starting with "Terminal run command: ". Let me know if that doesn't help.

    ReplyDelete
  5. Yeah, that helps a lot. When I ran "Run", it runs the app from the absolute path and stays in the directory it is in. when I ran "Run Logged...", it cd's to the app directory and runs it. The db is stored in the app directory, and if it doesn't exist, sqlite creates an empty one. So i need to change my code to catch the error where it doesn't exist and try to stop it from being created, or create one with all the table structure done as well. And improve the location of the db string structure so its pointed to the absolute path where it should be rather than the relative path. Thanks again, I never would have figured that out without the -d mode.

    ReplyDelete