Re: [Fink-devel] Proposal new Fink engine (Finch?)
I just got back from my trip, I will work on my code over the next week (Yay, vacation!) and hopefully have some prototype material by then. 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.)
Re: [Fink-devel] gettext upgrade
Am Mittwoch, 06.08.03 um 18:21 Uhr schrieb David R. Morrison: Hi Max. I need your help in figuring out the correct strategy for upgrading gettext. There are two issues, which I will keep separate so as not to confuse things. As I've mentioned before, the major version number in libintl.dylib has changed in recent versions of gettext, so we need a new gettext2 package. Indeed. BTW an unrelated question: why are the man pages in the -bin splitoff, not in the -dev splitoff ? man3 is documentation for the developer APi after all. Constructing gettext2-shlibs and gettext2-dev is no problem, and these will obviously coexist with existing packages. (I remind you that "gettext" contains the shlibs, for backwards compatibility, and is an Essential package, while "gettext-dev" is not an Essential package and can be swapped in and out with gettext2-dev.) The problem arises with the executables, like /sw/bin/gettext. At the moment, they are in "gettext-bin" which is an Essential package. I'm having a hard time finding an upgrade strategy when this package is Essential. If it weren't Essential, I could just create "gettext2" to contain v.2 of the executables, and swap it back and forth with "gettext-bin". But I can't do that with an Essential package. However, I am a bit nervous about removing the "Essential" tag from gettext-bin. There might be some packages that depend on this, right? Not too likely, but possible. I am actually not sure if it's that unlikely. I am not a gettext pro, so somebody else will probably know better; but a quick check reveals that the configure sycripts of many gettext using apps refer to various of the tools in gettext-bin (like msgfmt, xgettext etc.). I am not sure in how far those are only used in maintainer mode, or if they are actually used during normal configure/make runs, too... That is something we need to know definitely. I suppose one thing I could do is to add "BuildDepends: gettext-bin" to every package which currently says "BuildDepends: gettext-dev". But would that be enough? I'd hope it should be enough. Strictly spoken, I am not sure if it's a good idea to have -dev and -bin separated (are there scenarios were one would want/need to use one without the other?) In any case, it'd be vital that the -bin and -dev version match; i.e. if an app builds against gettext2-dev, it should "see" the gettext2-bin, and if it uses gettext-dev, then gettext-bin. Which presumably would be the case if we specify explicit BuildDepends The other option I thought of was to continue keeping the gettext executables in a package called "gettext-bin", which would now become a splitoff of "gettext2" and get a later version number. The newer versions of gettext-bin would depend on gettext2-shlibs not gettext. The problem with this approach is that iw would be difficult to "go back" to earlier versions. (It's particularly hard for apt-get users, since I don't believe apt-get will recognize the older versions.) Not only that, it would mean that developers would be forced to develop their apps against the new gettext. If somebody for some reasons wishes to develop apps based on the old gettext, they won't be able to do that anymore with Fink, because they can't access the older tools anymore (unless the newer tools are 100% compatible to the old ones. I don't know if that's the case or not, but a simple way to find out the answer to this and my above question would be to contact the gettext developers, I'd think) This would also mean that we have to make gettext2-shlibs into an Essential package immediately, since the latest version of the Essential package gettext-bin would depend on it. This should not be rushed. It can be annoying to remove the essential status from a package again, so let's make sure we know we are right. Your thoughts on this would be most welcome. I have packages for gettext2 ready to go, except for getting the depedency issues sorted out. I also have a package for the latest texinfo ready to go, which depends on gettext2-shlibs. Fine :-) Oh yes, I mentioned that there are two issues. The second issue is that the upstream maintainers of gettext are now recommending that packagers separate gettext into "gettext-runtime" and "gettext-tools". I'm planning to do this with gettext2 unless you think it's a bad idea. It means six total packages for fink (gettext2, gettext2-shlibs, gettext2-dev, gettext2-tools, gettext2-tools-shlibs, gettext2-tools-dev) but a smaller installation requirement for bootstrapping and for most users. You mean they can be compiled separately? I.e. you are not talking about splitoffs, but gettext-tools really would be a 100% independent package? Some of the executables which are currently in "gettext-bin" will end up in "gettext2-tools" rather than "gettext2", so this affects the earlier discussion of dependencies as well. OK. Max --- This SF.Net
[Fink-devel] glut, X11 1.0 and Panther
I just thought i'd let y'all know that X11 1.0 in the panther preview is built FAT just like everything else and so the Imake files that glut uses to configure itself have '-arch i386' in them all over the place so it won't work on a normal osx box. :-) either a custom version of this file is needed or apple needs to be killed or maybe some patch to glut or maybe our own version of Imake? :-) JP -- Every time you share on a P2P network, God kills a kitten. Please think of the kittens. --- 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
