Hello Ryan! 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 ;-) 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? ;-) How's Pallet shaping up? Do you have any demonstrations? roadmap? ETA? Very interested in finding out more about your work, tell us all about it! Regards,.... -jmpp
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..."
On Nov 7, 2007, at 11:23 AM, Randall Wood wrote:
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'm so sorry *Randall*! I'd just finished sending a message to Ryan at that time and when I started writing yours his name slipped out my fingers... only a few characters difference ;-) ---snip---
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.
Rewriting MacPorts in any language up to any extent is a major, long term endeavor that would naturally spark off a lot of brainstorming around it: -) first and foremost, what language?? (/me phears the holly wars!) -) once that's settled, do we start from scratch with a new design or, on the other hand, try to re-implement the existing one in the new language? -) barring that, how would our new APIs look like? -) and last in this very short list (which could easily be expanded), but certainly by no means least, what do we do to *NOT* loose all the work already invested in our Portfiles? Now, I'm not trying to discourage you in any way.... in fact, I'm more than sure many here would put together a party if we embark on a rewriting endeavor (probably even including me ;-) -- and, in fact, when Landon once considered it, Cocoa was a very strong option -- I am instead asking you to please be most open about it if you are indeed considering a full rewrite of base, as otherwise a solitary effort may result in massive waste of time and resources. ---snip---
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.
If your framework does stand up to the test of a real world application we could of course brainstorm over distributing it as a Cocoa glue for Mac OS X native GUIs for MacPorts. I believe that would be a very interesting project to explore! Can you please let us know of your progress when you reach any milestones?
Maybe I should just document all this on Trac...
That would be sweet!
-- Randall Wood rhwood@mac.com
Kudos for the hard work and energy devoted to the project! Regards,... -jmpp PS: And sorry again for the Randall/Ryan confusion ;-)
On 7 Nov 2007, at 13:34, Juan Manuel Palacios wrote:
On Nov 7, 2007, at 11:23 AM, Randall Wood wrote:
On Tuesday, November 06, 2007, at 01:36PM, "Juan Manuel Palacios" <jmpp@macports.org> wrote:
[snip]
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.
Rewriting MacPorts in any language up to any extent is a major, long term endeavor that would naturally spark off a lot of brainstorming around it:
The only process that I am (re)writing is getting a list of all ports (return [mportsearch]) since it is reportedly significantly faster to parse all of a user's PortIndex files into an NSDictionary than to use the MacPorts Tcl API to do so.
-) first and foremost, what language?? (/me phears the holly wars!)
The Framework is being written to support Cocoa/Objective C GUI programs on Mac OS X, so its in Cocoa/Objective C. Although in a private email, someone did ask if I knew of a Python API for MacPorts.
-) once that's settled, do we start from scratch with a new design or, on the other hand, try to re-implement the existing one in the new language?
I am a firm believer in object orientation, so my Framework does not provide a function-to-function mapping of the Tcl API as sometimes it just hasn't made sense to do things that way in an object oriented Framework.
-) barring that, how would our new APIs look like? -) and last in this very short list (which could easily be expanded), but certainly by no means least, what do we do to *NOT* loose all the work already invested in our Portfiles?
Now, I'm not trying to discourage you in any way.... in fact, I'm more than sure many here would put together a party if we embark on a rewriting endeavor (probably even including me ;-) -- and, in fact, when Landon once considered it, Cocoa was a very strong option -- I am instead asking you to please be most open about it if you are indeed considering a full rewrite of base, as otherwise a solitary effort may result in massive waste of time and resources.
I don't want the work either.
---snip---
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.
If your framework does stand up to the test of a real world application we could of course brainstorm over distributing it as a Cocoa glue for Mac OS X native GUIs for MacPorts. I believe that would be a very interesting project to explore! Can you please let us know of your progress when you reach any milestones?
My only real concern is how do we ensure that we can push the GUI through our systems? Every single GUI that I've seen mentioned on the lists is closed and we can't redistribute through MacPorts (or worse the GUI uses some other mechanism to self update).
Maybe I should just document all this on Trac...
That would be sweet!
-- Randall Wood rhwood@mac.com
Kudos for the hard work and energy devoted to the project! Regards,...
-jmpp
PS: And sorry again for the Randall/Ryan confusion ;-)
Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
participants (3)
-
Juan Manuel Palacios
-
Randall Wood
-
Ryan Schmidt