Am Sonntag, 20.07.03 um 16:02 Uhr schrieb Benjamin Reed:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Randal L. Schwartz wrote:
Kyle> I would like to propose a new internal engine for fink, based around
Kyle> an Objective C library that I will call Finch in this email.
Why objective-C? Perl would get the job done faster, cheaper, and
with a larger installed base of people who can make contributions.
I'm with Randal on this. Keep in mind that while performance is certainly important, the larger number of people who can contribute is the biggest reason to stick with perl. We've just now started getting enough people who are not only are capable of working on the fink code base, but willing. Now is not the time to abandon that. =)
And while you may be able to embed a perl interpreter into your ObjC code, it's much easier to mix-and-match from the perl end, as far as I'm aware. It would be a lot more work, I think, to be able to arbitratily use perl in an OjbC program than the other way around.
Personally, I don't consider Perl a holy grail, I must say. However I also don't get why one would write this in Objective C. Don't get me wrong, I love Objective C - it rocks when used with Cocoa. But esp. when talking about performance, it's dynamic nature makes it slower than C++ in general (not that I really think this is a limiting factor, I just find it funny that somebody says Perl is not good enough but Objective C is better.. hum :-). Anyway, the real problem is that there are only few programmers who know Objective C (and even less who know it *well* and code well in it). A much better choice would be plain C or C++, because far more people are able to code in it. For our purposes, I simply see no advantages in using Objective C. Oh, and don't forget that it limits portability, too - ObjC works on less platforms than C/Perl/C++. And the GNU ObjC runtime differs from the Apple one. Etc.
There are definite performance problems with the current implementation of fink, and it's a known issue, but starting from scratch is gonna be a lot more work than you think. And, for that matter, it's not the dep engine, it's data-access (reading/scanning info files).I don't think any of our performance problems are due to perl anyway, and so far nobody (including Kyle) has been able to prove otherwise. All bottlenecks I see so far are disk I/O related, or due to suboptimal algorithms (i.e. our abuse of storable is becoming a speed issue, the data involved simply is to big for it). Fixing that will require a rewrite of parts in any case; but of course rewriting a (well modularized) part of code is much easier than rewriting everything from scratch, so I am still skeptic.
Now, if you can write a fink/dpkg/apt compatible dependency engine that can drop into the existing Fink code, *that* would be great. But otherwise, there's a *lot* of stuff to implement that isn't the dep engine, otherwise. I'm not saying what you're doing is impossible, or unappreciated, but there's a lot more to Fink than the dep engine, and reinventing the wheel because one spoke is off is generally a bad > idea.
Well as I said, I don't think there is a point in us discussing Kyle's plan (even though he asked us to do it) before he can't show us a running prototype which proves that a) his concept works, b) it is compatible with the dependency engines in the dpkg/apt, and c) it actually has any advantages over what we have now. Until then, any discussion is pretty pointless. *If* we have something (and I mean a prototype, not a complete engine, of course), then we can take a look at it, and see how feasible it is to base anything on it.
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
