On Sunday, Jul 20, 2003, at 03:58 US/Eastern, Randal L. Schwartz wrote:
Why objective-C? Perl would get the job done faster, cheaper, and with a larger installed base of people who can make contributions.
I chose Objective-C not because of speed, but because it contains the cross-language compatibility that would be useful in the library. Writing XS around Obj-C is not that difficult (Not that XS is difficult for anything else), and C callbacks are simple. If someone really wanted a C++ wrapper to something, that could easily be implemented in Obj-C++ (How horrid! But that is just my personal opinion). If we tried to do this in Perl, we would need to call Perl from C, C++, Obj-C, etc, which is somewhat clumsy with the need to maintain a global Perl instance, but not difficult. On the other hand, Obj-C is better than C or C++ for this because of its dynamism and flexibility.
On Sunday, Jul 20, 2003, at 10:02 US/Eastern, Benjamin Reed wrote:
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. =)
I am not thinking that we should code the interface in any C-type language anyway, they are far too clumsy for command line "UI" anyway. I was thinking of abstracting away an Obj-C library that would just provide the engine and package interface. The actual package implementation for enumerating and reading files, etc, could still be Perl.
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.
Yes, that is true. It is probably easier to have a C-type language library with XS stubs that call in to the functions, register callbacks, etc, than to have a C-type program use a Perl library. I originally referred to a C-type library anyway, without anyy
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 am not really concerned with speed, just the weird internal node errors and other problematic symptoms, but that could be fixed as a side effect of this. Do we really need to read the entire info file every time? Could we not just have a list of certain fields to cache, and stop parsing when we have found all of them? Then only put those fields in the database. It is just as easy to read the file for the install instructions as it is to extract it from a file.
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.
Yes, that is kind of what I was thinking. I want to abstract out the dep logic into the "Finch" library (Obj-C) so that it can be used by any program.
On Sunday, Jul 20, 2003, at 10:32 US/Eastern, Max Horn wrote:
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 :-).
Why do minor language speed quibbles matter when the file access patterns themselves are simply not efficient enough? :-)
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.
But the GNU Obj-C Foundation is interchangeable with Apple's. (Mostly) (BTW, have you ever looked at the number of emails per day on the cocoa-dev list? In the last 5 weeks, I have 2547 new email on that list.) Also, Obj-C/Foundation is far easier to learn completely than C++/STL. I have studied C++ for several years, and parts of the design still baffle me.
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.
I have long since realized the error of my ways :-)
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).
Why store everything anyway? Why not just put engine essential info in the cache, and leave the rest in the file to be read when the user requests action on the package?
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.
I just want to abstract out the package system, kind of like pkg-order, but into a Obj-C library with C/C++ callbacks that can be used from other programs.
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.
I am working on it :-)
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a16 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP? t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
