On Tuesday, November 06, 2007, at 01:36PM, "Juan Manuel Palacios" <jmpp@macports.org> wrote:
Hello Ryan!
I'm not aware that Ryan has done any work on Pallet either. That said, if he wants to, he's welcome to.
I think this question is long overdue, and in a way I would like to apologize for apparently having ignored your seemingly interesting work on Pallet thus far! But trust me, I haven't ;-)
Right now, development on Pallet is mostly stopped. Development on a Cocoa Framework wrapped around the MacPorts API is proceeding, albeit slowly, as I have maybe a couple of hours a week that I can devote to it, and am learning to read Tcl in the process. The MacPorts Framework (https://svn.macosforge.org/projects/macports/browser/users/rhwood/MacPorts.F... or port MacPorts_Framework) has the following major issues: 1) It does not adequately pass notifications or respond to passed notifications (if an MPPort object's state changes it needs to send a notification so that any other MPPort objects for that same port can sync states - note this is a system wide requirement, not just a single task requirement) 2) It does not throw exceptions when things do not go quite right. Part of this problem is laziness on my part, part of it is inconsistencies in the MacPorts API (different functions return failure/error states differently) 3) The framework remains API incomplete 4) Creating an MPPort object is very expensive 5) The entire thing is basically undocumented - if anyone wants to headerdoc this framework, I'll work with you to figure out what's going on in the code.
So, mind filling us in on what you're doing with Pallet? What's the scope of your project? Tying into the existing MacPorts API to provide a Cocoa front end...? Or are you all the way out there rewriting us entirely? ;-)
I'm tying into the MacPorts API, although if I can get significant performance improvements by not using the API, I might rewrite in Cocoa. (For example, until I began using MPPort objects that each made a call against the MacPorts API when initialized, a pure Cocoa method to read the PortIndex was noticeably faster than using the MacPorts API--however it turns out that I lost all those advantages when I wrote the MPPort objects. I'm thinking of rewriting them to make any and all calls against the API lazily (i.e.: only when absolutely required), but I am also aware that the MPIndex needs to figure out the URI to the portfile for an MPPort and pass that in.
How's Pallet shaping up? Do you have any demonstrations? roadmap? ETA?
I think that Pallet builds from the port Pallet, but as you can see there is a problem with the UI gumming itself up that I can't figure out. I have not really been working on it other than ripping out parts that have been superseded by using methods from the Framework.
Very interested in finding out more about your work, tell us all about it!
I am very close (planning on starting this weekend) on rewriting the MacPorts Notifier (its distributed via MacPorts) to use the Framework for syncing and then for upgrading ports and once I am satisfied that the Framework is usable in a real-world scenario, in getting it officially into the project and versioning and bundling it for distribution. Maybe I should just document all this on Trac... -- Randall Wood rhwood@mac.com "The ball is round. The game lasts ninety minutes. The rest is theory..."