Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 09:03:33PM +0200, Marcus Brinkmann wrote: But there seem to be enough C++ deevelopers around here, and more and more C++ is mostly popular because microsoft is using it, ... will follow (if you haven't noticed, on universities they teach Scheme, Java , Perl and C++, depends on which faculty you are looking, AI, linguistics or math/computer science). yes sadly, no haskell, or sml, ... Friendly, Sven LUTHER
NDN: Re: Time to rewrite dpkg
Sorry. Your message could not be delivered to: Jorge Araya (Mailbox or Conference is full.)
NDN: Re: Time to rewrite dpkg
Sorry. Your message could not be delivered to: Jorge Araya (Mailbox or Conference is full.)
NDN(2): Re: Time to rewrite dpkg
Sorry. Your message could not be delivered to: Jorge Araya (Mailbox or Conference is full.)
Re: NDN: Re: Time to rewrite dpkg
Why am i continually getting this stupid message: Post Office wrote: Sorry. Your message could not be delivered to: Jorge Araya (Mailbox or Conference is full.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ed Breen Informatics Research Leader Proteome Systems Ltd (www.proteomesystems.com) +61-2-98891823 (5) [EMAIL PROTECTED] ---
Re: Time to rewrite dpkg
Marek Habersack [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] * Marcus Brinkmann said: On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote: 3. Most programmers would write code in C Yeah, uh. But that's the point isn't it? No, that's the reality. The current dpkg is written in C. How many programmers are working on it? Again, that's not an argument. People come and people go, and more of them know C than C++. Besides, ech..., how can you draw an argument like this??? Is that a reason to write dpkg in Heskell, because the current maintainer fancies that? And what if he gets tired maintainig it? And what about compatibility? Extensibility? Interoperability? They don't matter at all, right? Its the reason that validates it all. If the maintainer wants to write dpkg in heskell, he may do so. You don't have to use it. :) The only contributions to our packaging systems today are done with C++ (apt), and perl (install methods). Yes, yes. But you won't be able to use perl with C++ libraries. So what, if everyting is provided with the c++ libs we don't need perl. Time will tell if a dpkg in C++ is better than the one we have now. If someone writes one in C and it prooves more reliable, everyone can switch again. May the Source be with you. Goswin PS: It doesn't matter in what language its written, as long as it is written.
Re: Time to rewrite dpkg
[EMAIL PROTECTED] writes: Go for it. Have fun. Document and read. There has been quite some discussion on this subject. My only comment is that apt will likely be on a boot disk near you real soon so libc++ is there too. Great, I just love apt. Make not of dpkg's short comings. Aim for compatibility. Remember the creed of debian always has clean upgrades. Yes, I had big troubles with that on redhat. rpm was just too old to install a package and also to old to install a newer rpm and also to old to install rpm sources. There was just no way to update. And place a cvs somewhere so interested parties can join in the fray. I'm certainly intrested, even if its only de^H^Hconstructive critics. :) May the Source be with you. Goswin
Re: Time to rewrite dpkg
Marek Habersack [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (7bit)] * Aaron Van Couwenberghe said: Notably, I'm going to be writing it in C++. This will add about 270k to the boot disks' root image, but as the floppy install methods are for the most part phasing out under the shadow of easier methods, I'm not going to Also I'm sure bootdisk won't be a problem. They need a bit tweaking around to fit more onto them, but if theres not enough space on one disk, take two. There should be space on the drivers disk anyway. Are you sure about that? If yes, the you probably don't install debian very often. In serveral places, including my own company, which have a few linux workstations and at least one server I like to put the Debian dist CD into the server, mount it in the anon ftp tree and install/upgrade the workstations using FTP - that way I can cut down on costs of the equipment, I can simultaneously install linux on several machines - from ONE source instead of having a dozen copies of the Debian CDs. And, yes, I install from FLOPPIES - now you're telling me the new dpkg won't fit on floppies, right? It won't sell... as I'm sure I'm not the only one installing Linux on workstations this way. For cases like your pool, have a look at ftp://mirjam.informatik.uni-tuebingen.de/debian/* If you install Debian often, this proposal comes in real handy, cause you can configure one host and clone that config across a pool. Why C++? Well, personally, I have been seeing all of these applications pop recently that are for package management, aside from dpkg. Examples include dconfig and apt. Other ideas have been floating about, like source dependencies and binary diffs. What does it have to do with the actual code? Language chosen is mostly a matter of preference, more often of compatibility and compactness of the produced code. C++ doesn't have the two latter issues... Take a look at what's happening with egcc's support for C++ - it's constantly gaining new features, according to the official standards - to name only one, rtti. Every new language feature in some way changes the way of mangling C++ names, and RTTI will also add entry points for various checking procedures etc. And you will surely have compatibility (binary) problems as the time passes. And code is as good as it's structure and design and not the language used. C programs can be constructed in a very clean, modular and extensible way and they still remain COMPATIBLE and COMPACT. Yeah, but C programs can be real ugly dirty bitches as well. Also you can write C in C++ if you like, so everything speaking for C speaks for C++ also. With C++ the compiler is more strict and can do much more error checking, especially when using OO design and well designed classes. As to the binary problems, you have the same with any language. Just look at the libc5/6 transition or glibc2.0/2.1 problems. I like the idea of using C++, because I know it and I know how to write well structured and clean programs in it. To me it has a nice lookfeel, if one can say that about a language. ... Consider the benefits. First, dpkg comes as a 350k executable, containing nothing but basic logic for commandline arguments and a static link of libstdc++. Apart from that, libdpkg is required for dpkg to function properly; This library defines all behavior for operations on packages and the package/status databases. And you call a 350k monster a BENEFIT?? If you have a shared library with ALL the functionality in it, then the DRIVER executable can be as small as 35k - and that's what I call a benefit. Plus, you can do it in C, you can't in C++ - the latter will always be much larger. So you have 100K dpkg-lib + 35 K prog + 500 K libc or what? I think 350K is quite small, probably smaller than it is now. ... Once again, this doesn't justify C++... All of this can be done in much cleaner (binary-wise) way in C. Also, you even once didn't mention any feature that's C++ specific and that would justify selection of C++. If you The most important reason to use C++ is that he wants to. Also C++ has nice OO features that are dirty in C. In C you would have to care about pointer conversions to get propper OO features, why not let g++ do the dirty stuff and do extra error checking for us. were talking about a hierarchy of classes, encapsulation, polymorphism - then you would justify C++ as THE language for dpkg. I can imagine a hierarchy of classes, each of them designed for a specific task, each of them deriving features from it's parents - and all that in a modular way. Yes, that can be done - but why? It can be done in C equally well... Thats what he is talking about aktually, or at least thats what he is thinking. ... May the Source be with you. Goswin
Re: Time to rewrite dpkg
Joey Hess [EMAIL PROTECTED] writes: Goswin Brederlow wrote: I think its a bad idea to say You want to access to dpkg, programm in XXX. All interaction should be via a call to dpkg itself. Also modules should be programs by itself and not linked. dpkg would then call dpkg-download-ftp to download a package via ftp, or it could call dpkg-download-apt to use apt and so on. That way all modules can be written in any language. They only must share a common interface via commandline options, which all programs can provide easily. Library interfaces can be much richer and let you do a lot of things that are a royal pain with a command line interface. They also have less overhead. C libraries are quite usable from other languages. For modules that download stuff and many other the interface is real easy and the most time is spend on waiting anyway. There is no need to make a library for those stuff. The problem with libraries is that you can't just create or exchange one easily. You have to know a lot about the structure and code behind it. Also you have to recompile programs to use new libraries. Take binary diffs of deb packages for example. Via a command interface to download packages, its a matter of seconds to write a script that downloads the binary diff of a package and patches the already existing package to the new version and return that for installation. With a library you have to write C (or other language) code, compile that, link that and recompile dpkg to use it. That takes far more time. Of cause for the database that controls whats installed and what state packages are in and so, speed is vital. Esspecially one doesn't want to parse the database again and again. Maybe for that a database interface that starts automatically when first used and keeps runnig for some time in the background would be best. May the Source be with you. Goswin
NDN: Re: Time to rewrite dpkg
Sorry. Your message could not be delivered to: Jorge Araya (Mailbox or Conference is full.)
Re: Time to rewrite dpkg
Goswin Brederlow wrote: I think its a bad idea to say You want to access to dpkg, programm in XXX. All interaction should be via a call to dpkg itself. Also modules should be programs by itself and not linked. dpkg would then call dpkg-download-ftp to download a package via ftp, or it could call dpkg-download-apt to use apt and so on. That way all modules can be written in any language. They only must share a common interface via commandline options, which all programs can provide easily. Library interfaces can be much richer and let you do a lot of things that are a royal pain with a command line interface. They also have less overhead. C libraries are quite usable from other languages. -- see shy jo
Re: Time to rewrite dpkg
Marek == Marek Habersack [EMAIL PROTECTED] writes: Marek * Antti-Juhani Kaijanaho said: On Wed, May 19, 1999 at 03:01:12PM -0700, Aaron Van Couwenberghe wrote: Polymorphism is such an obvious pillar of structured programming that I can't understand how anybody could live without it. Agreed. Too bad C++ does not support parametric polymorphism too well. Templates come close, so the hope is not lost. Marek But the problem is that templates, nor exceptions or rtti Marek (which are all elements of MODERN C++ programming) don't Marek work well enough on the GNU platform... So someone should learn enough about that to implement it in the GNU compiler, huh. I plan to make that my area of study... maybe if noone beats me to it, I'll work on that in five or six years. ;-) -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Re: Installing on old computers (WAS: Re: Time to rewrite dpkg)
Please -- all replies to [EMAIL PROTECTED] Eduardo == E O Fredrik Liljegren [EMAIL PROTECTED] writes: Eduardo On a computer without CD-ROM one has to start by Eduardo disk, but that's ok. Do you mean floppy, or the hard-disk option? Eduardo Then you get the option of NFS, but not Eduardo FTP! Huh? Sure... use the apt method. There are 3 discreet different install phases: installing kernel + modules, installing base, and installing the rest. You really have to be a more clear. I assume, actually, you're talking about installing base. In this case, I suggest you make a little DOS area on the computer you are installing, and put base2_1.tgz on there (installing base from harddisk option). Eduardo Since the other computers are all MS Windows... NFS is Eduardo not an option, That's not true, but point taken. Eduardo so we went on with the base disks (having to Eduardo rewrite half of them because of read errors). After that, you Eduardo off course get ftp-opportunity. But then, if you ftp from a Eduardo windows-machine that simply reads the CD or a copy of it on Eduardo the HD, it will all fail, because of the symlinks Eduardo disappearing! On Red Hat, you can use one disk to get the Eduardo ftp opportunity, and symlinks wont destroy it! So, what Eduardo could I tell him, to grab each package by hand??? No, use the apt installation option. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Time to rewrite dpkg IN IDL! :)
On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote: Besides, any advantage in a nice OO design is lost by implementing it in C++! There is no need to do it in C++. My whole point is that I think an OO methodology would work well in this case simply due to the maintainability factor. gasp We could do it in .ADA!/gasp daniel
Re: Time to rewrite dpkg IN IDL! :)
And thus spake Daniel James Patterson, on Fri, May 21, 1999 at 09:30:31AM +1000: On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote: Besides, any advantage in a nice OO design is lost by implementing it in C++! There is no need to do it in C++. My whole point is that I think an OO methodology would work well in this case simply due to the maintainability factor. gasp We could do it in .ADA!/gasp One thing that people seem to be forgetting (not necessarily you, but I figured this was a good time to pipe in) is that it is desirable for dpkg to 1) have a small footprint and 2) have few depencies. I see the second as more important, because fewer dependencies mean fewer chances to screw something up that will break dpkg (as we've seen with C++ libraries breaking apt, etc). -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 01:20:20AM -0700, Aaron Van Couwenberghe wrote: Argo-UML. It's a UML design tool, designed to export Java; however, its nature makes it useful for any (distributed or otherwise) OO design project. I don't have a URL with me. http://www.ics.uci.edu/pub/arch/uml/index.html found that on freshmeat. daniel
Re: Time to rewrite dpkg
Marcus Brinkmann writes: We all are blinded by dpkg. It works, yes. How long? The current sources don't even build properly out of the box. Problems are cropping up without people knowing how to fix them (see the bug list). Even very simple patches and changes need months to get into yet another non-maintainer release. While I couldn't get the published source to build, IWJ's source tree builds for me. Perhaps you should encourage him to make it more widely available? ttfn/rjk
Installing on old computers (WAS: Re: Time to rewrite dpkg)
methods are phasing out is just plainly wrong. Currently we have three ways of booting the installation system: bootable CDs (requires a modern BIOS), floppy disk and bootp (requires a netword card with the proper ROM, and a bootp+tftp server on the same network). Our bootable CDs use a floppy image for booting, the same resc1440.bin floppy image that's used on a floppy based installation. That means two of our three methods (and I dare to say the third one is used on 5% of Debian installations) use the same rescue floppy disk. I won't say that's pashing out. ;-) I think the installation still lacks some.. I have a friend using 3 computers at home, and I got him to try installing Debian at one of them (instead of Red Hat that he tried earlier). On a computer without CD-ROM one has to start by disk, but that's ok. Then you get the option of NFS, but not FTP! Since the other computers are all MS Windows... NFS is not an option, so we went on with the base disks (having to rewrite half of them because of read errors). After that, you off course get ftp-opportunity. But then, if you ftp from a windows-machine that simply reads the CD or a copy of it on the HD, it will all fail, because of the symlinks disappearing! On Red Hat, you can use one disk to get the ftp opportunity, and symlinks wont destroy it! So, what could I tell him, to grab each package by hand??? .../EOF --- mailto:[EMAIL PROTECTED] Educational Free Software - http://hem.fyristorg.com/edufs/
Re: Time to rewrite dpkg IN IDL! :)
On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote: I think a good object-oriented design can be easier to follow too. In circumstances where there is naturally some use for inheritance it is very useful indeed. I don't see any natural inheritance in managing packages, though. Well just because you don't see one doesn't mean there isn't any. For example, we can have different package formats (and different versions of our own format, compatibility!) represented by classes derived from a common abstract class. This makes adding support for additional formats (or changing the exisiting format while adding compatibility mode) very easy and painless. OO is not only useful for natural inheritance, or, to put it another way, there are lots of inheritances were you don't see them at first glance. I think that forcing a procedural program into classes just for the sake of it would destroy the clarity you're looking for. Absolutely. Happily, package management is not procedural at all. It can be implemented in a procedural way of course (anything can). But object management will be useful. The recognition for Object Oriented languages has still a long way to go. Mathematicians are way ahead of programmers with this respect (you see, math is an OO modelling of the whole world and even more. Math is also descriptive, but this is orthogonal to this discussion :). Thanks, Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
[mttrader@access.mountain.net: Re: Time to rewrite dpkg]
Just FYI, this is the response I got from swim's author. There's the URL I didn't have in my last mail ... Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/ ---BeginMessage--- On Wed, 19 May 1999, Raphael Hertzog wrote: Le Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe écrivait: constructive feedback and ideas is encouraged to respond, but negative responses will be ignored. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. And what about swim ? It's a dpkg-compatible package manager. I didn't take a look to its sources but maybe you could simply improve swim if it's well written. I don't have an URL right now, but the author is reading this list and he may supply additional informations. You can download swim from http://the.netpedia.net/the-download.html This program is written in Perl. Originally, both dpkg and rpm were written in Perl. Swim can run without dpkg by using ar from gcc; it uses the Berkeley DB to create databases. These databases could run independently of status, available and info/*, but my approach has been to allow both of the best worlds - text databases and binary databases. So, on a Debian system it uses dpkg, apt, the binary databases and provides powerful command-line options (which in a sense are OO because of all the writing they save you :*}). In /usr/doc/apt/cache.html/ch4.html the possibility of using cache to speed up dpkg is mentioned. I was actually thinking of modifying dpkg to use swim's databases to speed things up. It will be interesting to see what happens now that Ben Collins mentioned a formal plan to create a new dpkg. Ofcourse, this project may want to use my program as a prototype because I would imagine there is a need for some sort of hash database. Ofcourse, a lot of development time would be saved if Perl, not C/C++ was used. Give swim a try, I've added a history for swim's shell and search capabilities. Swim allows experienced users, people who can RTFM, or power-users from the RPM sect to manage and make decisions about packages more effeciently from the command-line. I've found it extremely useful. Eventually, I would like to add the capability to manage archives all from databases - the beginnings of this are already apparent. I hope you are using a version of DB_File compiled for db2 not the buggy db 1.85. You can examine the databases using db_dump to view their structure. In the sources I wrote a little text explaining the structure. Make sure you have libterm-readline-gnu-perl | libterm-readline-perl-perl installed so that --stdin works properly. Please send me feedback! Jonathan ---End Message---
Re: Time to rewrite dpkg
Anthony Towns aj@azure.humbug.org.au writes: [1 text/plain; us-ascii (7bit)] On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote: ... In particular, there are established ways of linking programs written in any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. I think its a bad idea to say You want to access to dpkg, programm in XXX. All interaction should be via a call to dpkg itself. Also modules should be programs by itself and not linked. dpkg would then call dpkg-download-ftp to download a package via ftp, or it could call dpkg-download-apt to use apt and so on. That way all modules can be written in any language. They only must share a common interface via commandline options, which all programs can provide easily. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. Good luck, FWIW. I've no doubt you'll need it. May the Source be with you. Goswin
Re: Time to rewrite dpkg
* Ossama Othman said:
Why? Tell me how I pass a C++ object to C, Fortran or Pascal.
The same way you pass fortran to C: use wrappers, for example. Here is
one way of passing a static C++ method to a C function (e.g. signal
system call) in C++ code:
extern C void
Base_cleanup (void *object, void *)
{
Base::cleanup (object, 0);
}
Simple. :-)
Perhaps, but not clean. And doesn't make sense in this particular case...
Remember the rule of the Ockham's Razor I think it should be obeyed
here...
marek
pgpfz06ecaYYx.pgp
Description: PGP signature
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 01:37:53AM +0300, Antti-Juhani Kaijanaho wrote: As far as writing it, no. As far as getting something like this accepted, it's going to take time, no question about it. I think I'll be looking forward to seeing your code. Oh, um, I didn't mean to downplay the largeness of this project. I MEANT to say that it would be a matter of time, while the latter issue would take more than just that... -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: Time to rewrite dpkg
Hi,
extern C void
Base_cleanup (void *object, void *)
{
Base::cleanup (object, 0);
}
Simple. :-)
Perhaps, but not clean. And doesn't make sense in this particular case...
Remember the rule of the Ockham's Razor I think it should be obeyed
here...
What's not clean about it? It's a very simple wrapper? Also, what
doesn't make sense? It has been taken out of context so you don't know
what it is used for but it conveys the general idea, I think. I'm
afraid I don't recall what Ockham's Razor says. :-) Could you please
let me know?
Thanks,
-Ossama
--
Ossama Othman [EMAIL PROTECTED]
Center for Distributed Object Computing, Washington University, St. Louis
58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Time to rewrite dpkg
Hi Marek, On 19 May, Marek Habersack wrote: * Ossama Othman said: , but rather to it's implementation on the GNU platform, which is now in its young days - it's constantly changing, the features are being added, standard being implemented in more and more detail. This situation will no doubt incurr many changes both in the source code of the programs (new keywords, syntax changed at places, library classes etc.) but also in the generated binaries interfaces - esp in the shared libraries. I don't believe that the situation is nearly as bad as you depict it. A few years ago I would agree with you but the fact that there is now a standard means that the standard C++ APIs/keywords/syntax will generally not change. fairly stable in terms of existing language feature support. Stuff like RTTI and exception handling aren't major issues since they can easily be disabled. But it DOES change the binary representation of the program, esp. name mangling - which is the major headache with C++ right now. Again, I don't think the name mangling issue is so bad. Then again, I program exclusively in C++ so I am admittedly biased toward it. -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Time to rewrite dpkg
* Ossama Othman said:
Simple. :-)
Perhaps, but not clean. And doesn't make sense in this particular case...
Remember the rule of the Ockham's Razor I think it should be obeyed
here...
What's not clean about it? It's a very simple wrapper? Also, what
doesn't make sense? It has been taken out of context so you don't know
what it is used for but it conveys the general idea, I think. I'm
Oh, you got me wrong :)) I wasn't talking about the code itself :)). I just
don't see any point in creating a C++ library just to create a C wrapper, so
that C programs and, say, scripting languages can use it. It is MUCH easier
to write it in C at once, especially when nothing justifies using C++. I
mean, you can buy a small car - a shopping bag on wheels and then buy a
new engine just to be able to tow a trailer :)) - it is possible, but not
cost-effective and sensible - you can buy a larger and stronger car at once
:)). Maybe the example isn't perfect, but it shows what I have in mind :)).
In other words - why create TWO libraries instead of one? Writing the code
in C++ would result in:
1. having a c++ library
2. having a C-wrapper library to interface the C++ one ('cause it doesn't
make sense to put the C wrappers inside the C++ library)
3. Most programmers would write code in C, linking against the wrapper library
wich, in turn, would load the C++ library and the latter would pull in
libstdc++ and whatever else is needed. Imagine how much memory space is
wasted? The C program that starts the chain, doesn't need all the C++
bloat behind the scenes...
afraid I don't recall what Ockham's Razor says. :-) Could you please
let me know?
It's a rule created in XVII-th century that says that, in simple words,
every theory, experiment or research should be as simple as possible -
without adding too much unnecessary stuff. It may be possible to achieve a
goal in two ways, but always one of them is simpler and equally correct as
the second one - Ockham's Rule says chose the simpler approach, the simpler
the better
regards,
marek
pgpQLvjOCmSKz.pgp
Description: PGP signature
RE: Time to rewrite dpkg
* Ossama Othman said:
Why? Tell me how I pass a C++ object to C, Fortran or Pascal.
The same way you pass fortran to C: use wrappers, for
example. Here is
one way of passing a static C++ method to a C function (e.g. signal
system call) in C++ code:
extern C void
Base_cleanup (void *object, void *)
{
Base::cleanup (object, 0);
}
Simple. :-)
Perhaps, but not clean. And doesn't make sense in this
particular case...
Remember the rule of the Ockham's Razor I think it should
be obeyed
here...
I think the real problem is in trying to export a language-specific
construct to another language which does not support it. C does not support
objects. Yes, yes. I realize that a good C programmer can bliff and
blaff, etc., to achieve an object-oriented design that will be worthy of a
Nobel prize and the Pulitzer prize simultaneously, etc. etc..
However, the fact is that C is designed primarily for procedural style
programming, and does not have features in place to handle
C++/Java/Python/etc. objects.
A better question is how a revised C++-ish library might interoperate with
an object-oriented language designed to make use of polymorphism,
abstraction, etc. Say, how Python might work as a front end, or how you
might use Java, etc.
Asking how to pass a C++ object to C is like asking how to cast a float to a
byte field in assembly.
Ideally, a library would (in addition to it's C++ functionality) have a C
interface that doesn't really deal with the issue of objects. Say,
something that would accept some standard C types and structs, and return
same.
-Brent
Re: Time to rewrite dpkg
* Ossama Othman said: Hi, Ossama implementation on the GNU platform, which is now in its young days - it's constantly changing, the features are being added, standard being implemented in more and more detail. This situation will no doubt incurr many changes both in the source code of the programs (new keywords, syntax changed at places, library classes etc.) but also in the generated binaries interfaces - esp in the shared libraries. I don't believe that the situation is nearly as bad as you depict it. A few years ago I would agree with you but the fact that there is now a standard means that the standard C++ APIs/keywords/syntax will generally not change. The standards don't change that fast, but I'm talking about the _implementation_. The g++ compiler still has problems and unimplemented standard C++ elements - again, rtti and exceptions come to mind, not to mention templates. And I remember how did the C++ interface, in binary libraries, changed when Borland added exceptions, rtti and templates to their compilers. One had to recompile everything to link against the code produced with the new tools. fairly stable in terms of existing language feature support. Stuff like RTTI and exception handling aren't major issues since they can easily be disabled. But it DOES change the binary representation of the program, esp. name mangling - which is the major headache with C++ right now. Again, I don't think the name mangling issue is so bad. Then again, I program exclusively in C++ so I am admittedly biased toward it. You said it :))) - it's really a pain in the neck to interface the C++ libs from C or any other language for that matter... Especially if you want your C code to be cross-platform. All the major vendors use different mangling schemes AFAIR - Borland, WATCOM, Micro$oft and last, but certainly not least - the GNU compiler. regards, marek pgpzdHBgIh8SP.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Brent Fulgham said: Simple. :-) Perhaps, but not clean. And doesn't make sense in this particular case... Remember the rule of the Ockham's Razor I think it should be obeyed here... I think the real problem is in trying to export a language-specific construct to another language which does not support it. C does not support objects. Yes, yes. I realize that a good C programmer can bliff and blaff, etc., to achieve an object-oriented design that will be worthy of a Nobel prize and the Pulitzer prize simultaneously, etc. etc.. Oh, no! :)) Let us not start a language flame war :))) This is not the point. The issue is, whether this particular problem REQUIRES C++ from the conceptual and implementational(sp??) point of view... However, the fact is that C is designed primarily for procedural style programming, and does not have features in place to handle C++/Java/Python/etc. objects. Of course it doesn't - it is possible, but not practical :)) A better question is how a revised C++-ish library might interoperate with an object-oriented language designed to make use of polymorphism, abstraction, etc. Say, how Python might work as a front end, or how you might use Java, etc. The answer is - you can't... All the languages you mentioned have clean C interacing methods, but no C++ ones. The reason is that C++ is not interoperable. Asking how to pass a C++ object to C is like asking how to cast a float to a byte field in assembly. :)) Ideally, a library would (in addition to it's C++ functionality) have a C interface that doesn't really deal with the issue of objects. Say, something that would accept some standard C types and structs, and return same. And that's an overkill - you end up writing two libraries and, undoubtedly, putting too much effort into the C part than the result is worth. A waste of time and talent, I'd say... regards, marek pgptThd15Dx3K.pgp Description: PGP signature
Re: Time to rewrite dpkg
On 20 May, Marek Habersack wrote: * Ossama Othman said: What's not clean about it? It's a very simple wrapper? Also, what doesn't make sense? It has been taken out of context so you don't know what it is used for but it conveys the general idea, I think. I'm Oh, you got me wrong :)) I wasn't talking about the code itself :)). I just don't see any point in creating a C++ library just to create a C wrapper, so that C programs and, say, scripting languages can use it. It is MUCH easier to write it in C at once, especially when nothing justifies using C++. I mean, you can buy a small car - a shopping bag on wheels and then buy a new engine just to be able to tow a trailer :)) - it is possible, but not cost-effective and sensible - you can buy a larger and stronger car at once :)). Maybe the example isn't perfect, but it shows what I have in mind :)). Oh boy, here we go again. :-) The fact of the matter is that we can go on debating endlessly about C/C++ virtues. There are many reasons why rewriting dpkg in C++ instead of C would be good, and there are many reasons to stick with C. It just so happens that I believe that the advantages of implementing a dpkg rewrite in C++ outweigh the disadvantages, IMHO. For an excellent and huge example of a C++ wrapper library in use take a look at ACE. Doug Schmidt's web site (papers, etc.) also provides many advantages of using C++ libraries, in addition to why C++ wrapper libraries have advantages. The ACE web site is: http://www.cs.wustl.edu/~schmidt/ACE.html the second one - Ockham's Rule says chose the simpler approach, the simpler the better Thanks! :-) -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: time to rewrite dpkg
* Aaron Van Couwenberghe said: Yes, I see everyone's points. I know what you're saying. I'll keep it in mind; you've made your arguments. I just would like to see an end to this fledgling flamefest ;P Well, I saw no flames... Just a discussion but, hey, who am I to judge...? marek pgpzkc6FITwKF.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Ossama Othman said: mean, you can buy a small car - a shopping bag on wheels and then buy a new engine just to be able to tow a trailer :)) - it is possible, but not cost-effective and sensible - you can buy a larger and stronger car at once :)). Maybe the example isn't perfect, but it shows what I have in mind :)). Oh boy, here we go again. :-) The fact of the matter is that we can go on debating endlessly about C/C++ virtues. There are many reasons why Of course we can :)) I, personally, like both languages and just use them as a tool - I have nothing against C++ and I'm not a sworn C fan :)) - I'm just trying to find a proper way in this case :)) rewriting dpkg in C++ instead of C would be good, and there are many reasons to stick with C. It just so happens that I believe that the advantages of implementing a dpkg rewrite in C++ outweigh the disadvantages, IMHO. Well, if we are talking from the purely conceptual point of view, then you have my vote for C++, but when we are talking about environment and conditions where dpkg is used, C has it all. You have to admit that the *nix wold is rather conservative about programming languages : - C wins :) For an excellent and huge example of a C++ wrapper library in use take a look at ACE. Doug Schmidt's web site (papers, etc.) also I remember seeing it on some CD, it's an Asynchronous Communications Environment, or does my memory fail? :))) provides many advantages of using C++ libraries, in addition to why C++ wrapper libraries have advantages. The ACE web site is: http://www.cs.wustl.edu/~schmidt/ACE.html Thanks for the pointer, I will surely read the pages!! Thanks again. the second one - Ockham's Rule says chose the simpler approach, the simpler the better Thanks! :-) Anytime :))) marek pgpucs146aogJ.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 04:12:51PM -0700, Brent Fulgham wrote: Ideally, a library would (in addition to it's C++ functionality) have a C interface that doesn't really deal with the issue of objects. Say, something that would accept some standard C types and structs, and return same. in other words, the sensible thing to do is to write a C library and also write a C++ wrapper for it (as well as perl, python, java, scheme, guile, or whatever wrappers). this is a never-ending debate, it pops up again and again but IMO, C is the common language which can be interfaced to from any other language, so C is the language of choice for general purpose libraries. for example: this, and related reasons, is why GNOME chose C rather than C++ as the base language for GNOME projects. Their decision was sound, and their reasons were sound. craig -- craig sanders
Re: time to rewrite dpkg
Hi Arron, On Wed, May 19, 1999 at 04:16:15PM -0700, Aaron Van Couwenberghe wrote: I'm closing this discussion for now. What you started you can't really stop now. You started a C vs. C++ debate, and it will be a few more posts away until everyone calms down. I know what I have in mind, and why C++ is better in this scenario than C. But I don't want to incite any more flamage; once again I say that I won't be forcing anyone to use this thing. It's only a personal project, and if anyone wants to use it after I'm finished, they'll be free to. Well your subject says it all Time to rewrite dpkg. I'm assuming that you want to completely rewrite dpkg as a replacement for the current dpkg. A sort of dpkg2 persay. If your dpkg does eventually become the new standard, then the language you decide to use is very important. The interoperability subject isn't really a big issue; the base libraries could still be done in C for all I care, and I may just do so. But C++ is compatible with C, and as such anything that can be wrapped into C can be wrapped into C++, or vice versa. In addition, we have CORBA, which is extremely friendly towards C++ implementations, and much more powerful than common interop mechanisms with conventional languages such as RPC. IMHO. What the best thing to do is write your libdpkg in C. Remember C is still the standard language for Unix. And it will also allow a larger number of languages to possibily use those library calls. If this library were written in C++ you'll end up writing C wrappers, just so languages like perl can interface with it cleanly. It's your project and you can do what you like, but I believe that libdpkg should definately be written in C. If you want to use C++ for he actual dpkg, then you can make C++ wrappers around libdpkg for that. C++ has problems, its size is one of them. The other is, C++ is in a constant state of flux. -- Dan Nguyen | It is with true love as it is with ghosts; [EMAIL PROTECTED] | everyone talks of it, but few have seen it. [EMAIL PROTECTED]| -La Rochefocauld, Maxims 25 2F 99 19 6C C9 19 D6 1B 9F F1 E0 E9 10 4C 16
Re: time to rewrite dpkg
Hi Aaron, I would be interested in seeing your design. It may clear up some concerns as to why you are picking your language (which seems to have generated quite a discussion). More importantly, you may receive suggestions as to ways to improve the design. If you are lucky, you may even have a few volunteers to help with the coding or specific parts. I guess I'm just a big fan of getting the design right since the resulting code of a bad design is much more difficult to fix than bad code with a good design. Bravo for volunteering to code this yourself, I hope to do the same one day. Brandon +--- ---+ | Brandon Mitchell [EMAIL PROTECTED] http://bmitch.dhis.org/ ICQ 30631197 | | Throughout history, UNIX systems have regularly been broken into, beaten, | | brutalized, corrupted, commandeered, compromised, and illegally fscked. | |-- UNIX System Administration Handbook |
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 01:22:28AM +0200, Marek Habersack wrote: A better question is how a revised C++-ish library might interoperate with an object-oriented language designed to make use of polymorphism, abstraction, etc. Say, how Python might work as a front end, or how you might use Java, etc. The answer is - you can't... All the languages you mentioned have clean C interacing methods, but no C++ ones. The reason is that C++ is not interoperable. No, no, no! one word for everyone. CORBA! -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 01:15:00AM +0200, Marek Habersack wrote: The standards don't change that fast, but I'm talking about the _implementation_. The g++ compiler still has problems and unimplemented standard C++ elements - again, rtti and exceptions come to mind, not to mention templates. And I remember how did the C++ interface, in binary This was certainly true in g++ 2.7.x, but egcs seems much better. (Exceptions and templates anyway; I don't know what rtti is.) Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome. pgp1oeIwXB9yJ.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 03:01:12PM -0700, Aaron Van Couwenberghe wrote:
On Thu, May 20, 1999 at 12:50:19AM +1000, Anthony Towns wrote:
That seems... the wrong way around.
see comments below ;P
Perhaps I should expand on that. The `Unix way' (yes, you can stop reading
this paragraph here, if you like) always seems to me to have been more along
the lines of build a simple tool, then, if you want some grander, integrate
that into something grander. So you take grep and sed, and write a shell
script that uses them to get your `find the name of all users on the system'
program to work.
As opposed to writing a plugin to grep.
That's not to say plugins are bad, just that the alternative *does* work,
and *does* result in useful, expandable systems.
One alternative that's probably worth considering is improving libdpkg, so
that Apt and friends can make use of dpkg that way, and provide their own
front ends however they see fit.
This isn't nearly the same scenario as I have in mind.
Yes, I realise this. That's why it's an alternative.
Polymorphism is such an obvious pillar of structured programming that I
can't understand how anybody could live without it.
You mean, I presume, that polymorphism is an obvious pillar of object
oriented programming.
Anyway. I'm not so convinced dpkg's core functionality (the grep part
of it, so to speak), really *needs* polymorphism all that much.
You have to process dependencies, you have to unpack and build .deb's, you
have to keep track of everything that's on the system, and be able to
install and remove stuff.
Now, one thing you can do is to replace `deb' with `package', and have
`deb' and `rpm' be two subclasses of package, each of which can be
installed and queried and unpacked and whatever. You could then add
`debdiff' or something to cope with bindiffs, and see where you go
from there. [0] That could be really useful.
Now sure -- that's polymorphism, you want to be able to do all the same
operations on a couple of completely different objects. But it's not
particularly complicated: you've got a single level of inheritance,
and an abstract base class.
struct PackageInfo {
enum PackageType;
char *name;
void *PackageDetails;
DependsList *getDependencies(struct PackageInfo *foo);
void addDependency(struct PackageInfo *foo, struct PackageInfo *bar);
...
};
struct Deb {
...
};
Package myDebDetails = { ... };
Package myDeb = { DEB, my, myDebDetails, ... };
No, it's not pretty. But it's also not that ugly or that inconvenient in
this case. It's also trivially usable directly from C.
Note that you can probably also get away with keeping all of the
DebDetails completely private -- as long as libdpkg knows it's an rpm or
a bindiff and can cope, dpkg(1) doesn't really have to care *that* much.
But I dunno. Perhaps a better thing to do would be to write a
library in C++, but just limit its exported symbols to be `extern C'
functions. Then have a nice C++ based program like Apt that has its own
inheritance and whatever else to cope with access methods, and selection
preferences and whatever else.
In particular, there are established ways of linking programs written in
any language against C based libraries. As far as I'm aware doing the same
to C++ (or other object-oriented languages) is a pain in the neck.
This is simply not true.
If it's not true, you won't have any problem countering all the problems then,
will you?
How do you propose cope with the fragile base class problem? (ie, having
to recompile every C++ app that uses a library everytime a base class in
that library changes -- for example you decide that Versioned Provides
needs a different function prototype than the old Provides did)
How do you cope with differences in name-mangling? Or are we simply
willing to say `you'll use egcs' name mangling. If egcs decides to do
different name mangling later, we'll do a major revision of libdpkg so
new programs can link to it'?
How do you integrate C++ objects with C, Objective-C, Python, Perl, etc?
With C, you either don't export your structures, or you have enough
control over how your structures are used that you can avoid having
fragile base classes entirely exactly where necessary; and people have
already written all the wrapper functionality and integrated it with
their languages, so that `linking to C' is generally a documented feature.
And I don't particularly think it's much of a gain to say You want
access to dpkg's internals? Just use C++!. C++ is all well and good,
but it's not *that* good.
No, there are leaps and bounds to be made by this sort of organization.
Basically, any one feature or behavioural pragma need only be implemented in
one component; afterwards it's applicable to all future setups.
Object orientated design does not imply C++. It doesn't even imply
a language that natively supports object oriented programming, just
as structured programming doesn't require a language with control
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote: [...] Notably, I'm going to be writing it in C++. This will add about 270k to the boot disks' root image, but as the floppy install methods are for the most part phasing out under the shadow of easier methods, I'm not going to lose any sleep over this. libstdc++ can be minimized for static linkage anyway. dpkg is not on the boot disks' root image (thanks god). It's on the base system, with dselect, apt and, of course, libstdc++. You won't have to add it. (Let's call that luck). :-) OTOH, your opinion that adding 200k to the boot disks' root image, thus breaking the rescue floppy, doesn't matter because the floppy install methods are phasing out is just plainly wrong. Currently we have three ways of booting the installation system: bootable CDs (requires a modern BIOS), floppy disk and bootp (requires a netword card with the proper ROM, and a bootp+tftp server on the same network). Our bootable CDs use a floppy image for booting, the same resc1440.bin floppy image that's used on a floppy based installation. That means two of our three methods (and I dare to say the third one is used on 5% of Debian installations) use the same rescue floppy disk. I won't say that's pashing out. ;-) -- Enrique Zanardi[EMAIL PROTECTED]
Re: Time to rewrite dpkg IN IDL! :)
Aaron Van Couwenberghe [EMAIL PROTECTED] writes: I have grown increasingly aware of FUD of this type about C++ and OO languages. OO is designed to *increase* interoperability, flexibility, and extensibility -- definately not the other way around. OO isn't limited to C++, and C++ isn't limited to OO. The two overlap, but they are far from identical. Some people dislike C++ because it's not OO *enough*! C is generally far more interoperable with other languages (even other OO languages) than C++ is. C++ is great if you're *only* using C++, but if you're using a different language, with a different object model (or none), you're in trouble. References to alien, polymorphic, multiply-inherited objects are scary, especially when much of their structure and behavior is officially defined as implementation defined by the language standard. But C has its own problems, not least of which is that it's a primitive procedural language with no built-in OO features to speak of. And with emphasis on primitive. I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Time to rewrite dpkg (please do)
Aaron Van Couwenberghe [EMAIL PROTECTED] writes: Hello, esteemed members of the Debian enthusiast community! Hi ... So, whether or not I recieve the approval of this community, I'm going to be working on a complete rewrite of dpkg. No, it won't even *resemble* the old dpkg; I guarantee it to become contraversial. I'll let the masses decide whether it warrants trashing the old for the new. ... Good, somebody willing to write the thing. I'm already waiting for some code. :) While your at it, please have a look at ftp://mirjam.informatik.uni-tuebingen.de/pub/debian/ There's a proposal and implementation about a better way to configure packages. Features are: - non-interactive installation possible - default and package default answeres can be chosen - variable amount of questions depending on the users experience - various frontends and lookfeels (console/menu/x/www/...) - configuration can be done with dpkg-question alone (2K script) - reconfigure at any time - configure as user (where packages allow it), e.g. for windowmanagers All dpkg or your replacement needs to do is call the configure script, if existent, contained in the package, so its real easy to adapt to it. Also it would be nice if the following features could be implemented: - install source (with dependencies) - check for space via a du tree file. May the Source be with you. Goswin \
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) I don't see why not. Software is becomming more and more complex, people are expecting more and more out of it. The more modern and advanced things Debian can tout, the cooler we'll look. I don't have any experience in industry working with OO, but I have a little knowledge from what I work on at uni. A proper OO approach could produce a highly maintainable and extensible (and non-language specific) design that could be implemented easily enough in _many_ languages. There are a few OO tools (I'm thinking Rational Rose in particular) that can do code generation from UML work, which could mean that we could decide on a design before decending to our baser instincts to argue about what language it should be implemented in :) daniel
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: There are a few OO tools (I'm thinking Rational Rose in particular) that can do code generation from UML work, which could mean that we could decide on a design before decending to our baser instincts to argue about what language it should be implemented in :) Speaking of baser instincts, Rationale Rose isn't free software, is it? Are there any nice (or even not-nice) OO design tools that are? Apart from xfig, I mean. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgp86pUKDMA8S.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 12:44:02AM +0200, Marek Habersack wrote: * Aaron Van Couwenberghe said: Polymorphism is such an obvious pillar of structured programming that I can't understand how anybody could live without it. Is it? AFAICS none of the traditional languages like Pascal or C has polimorphism at its base... What you call polymorphism is just function name overloading, isn't it ? or does C++ implement true polymorphism this days, like what ML does ? Friendly, Sven LUTHER
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 12:47:59AM +0200, Marek Habersack wrote: * Antti-Juhani Kaijanaho said: On Wed, May 19, 1999 at 03:01:12PM -0700, Aaron Van Couwenberghe wrote: Polymorphism is such an obvious pillar of structured programming that I can't understand how anybody could live without it. Agreed. Too bad C++ does not support parametric polymorphism too well. Templates come close, so the hope is not lost. But the problem is that templates, nor exceptions or rtti (which are all elements of MODERN C++ programming) don't work well enough on the GNU platform... Is that true, I have heard this agrument often, but is it true, and is it still so today ? Is there effort made to fix this ? how far are they ? I just want to be sure this is true before people start using this as argument without even checking if things still are like that. Friendly, Sven LUTHER
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 12:44:02AM +0200, Marek Habersack wrote: 1. you create a C library with all the dpkg functionality inside 2. you compile and link it as a shared library 3. you write several simple drivers to interface the user to that library 4. the .so is loaded only ONCE - that's what shared libraries are for But you still have to parse the database, because you load the library only once don't mean that you will keep the database as is between two invocation of the front-end that uses the library. Sure it can be done, but it is not automatic, ... Or åm i missing something ... Friendly, Sven LUTHER
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:44:39PM +1000, Anthony Towns wrote: Speaking of baser instincts, Rationale Rose isn't free software, is it? Are there any nice (or even not-nice) OO design tools that are? No unfortunatley it isnt. There is a solaris version, which is a bad port of the win32 version, and the win32 version doesn't run under wine. I have found dia useful, but only from a diagram drawing point of view, unlike Rose which does all the extra bits as well. daniel
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) I don't see why not. How about it's complete overkill? (and non-language specific) design that could be implemented easily enough in _many_ languages. There are a few OO tools (I'm thinking Rational Rose in particular) that can do code generation from UML work, which could mean that we could decide on a design before decending to our baser instincts to argue about what language it should be implemented in :) I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 09:14:26PM +1000, Hamish Moffatt wrote: How about it's complete overkill? I don't think so. Yes you can write maintainable code with plain C, but with the number of developers moving in and out of Debian, I think that a decent OO approach for core software could make it more maintainable for _everyone_. I often feel that I'd like to help contribute code to some things, but, not being an overly confident programmer, I am daunted by code that takes a long time to understand. I personally find OO design much easier to follow. This is personal preference however. I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Perhaps there should be then? After the little work I've done (yes, and _you_ know just how much Hamish :P), I do see advantages behind the OO approach. Besides, as I said, at this stage, do the analysis, not the coding. It can always be scrapped if it looks like it would be pointless, but I'd like to see some non-emotive reasons not to even _consider_ it. daniel
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 12:53:23PM +0200, Sven LUTHER wrote: But the problem is that templates, nor exceptions or rtti (which are all elements of MODERN C++ programming) don't work well enough on the GNU platform... Is that true, I have heard this agrument often, but is it true, and is it still so today ? Is there effort made to fix this ? how far are they ? I haven't used RTTI, but in my experience templates work without problems and exceptions work most of the time (the problems I have may well be my bugs, not egcs'). Namespaces need work: for example, there is no clear separation between global namespace and the std namespace. EGCS has contributed much to the progress. A year ago I didn't feel like C++ was ready for my use on the GNU platform. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Good Times are back again! http://www.iki.fi/gaia/zangelding/
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 04:00:43PM +0300, Antti-Juhani Kaijanaho wrote: On Thu, May 20, 1999 at 12:53:23PM +0200, Sven LUTHER wrote: But the problem is that templates, nor exceptions or rtti (which are all elements of MODERN C++ programming) don't work well enough on the GNU platform... Is that true, I have heard this agrument often, but is it true, and is it still so today ? Is there effort made to fix this ? how far are they ? I haven't used RTTI, but in my experience templates work without problems I also heard that templates bloat the code, not just that they don't work, what about it, what size are your executable compared to equivalent C stuff, what speed do you loose by using C++ templates. Friendly, Sven LUTHER
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:54:45PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 08:44:39PM +1000, Anthony Towns wrote: Speaking of baser instincts, Rationale Rose isn't free software, is it? Are there any nice (or even not-nice) OO design tools that are? No unfortunatley it isnt. There is a solaris version, which is a bad port of the win32 version, and the win32 version doesn't run under wine. Argo-UML. It's a UML design tool, designed to export Java; however, its nature makes it useful for any (distributed or otherwise) OO design project. I don't have a URL with me. -Aaron
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 01:14:31AM -0700, Aaron Van Couwenberghe wrote: On Thu, May 20, 1999 at 12:45:45PM +0200, Sven LUTHER wrote: On Thu, May 20, 1999 at 12:44:02AM +0200, Marek Habersack wrote: * Aaron Van Couwenberghe said: Polymorphism is such an obvious pillar of structured programming that I can't understand how anybody could live without it. Is it? AFAICS none of the traditional languages like Pascal or C has polimorphism at its base... What you call polymorphism is just function name overloading, isn't it ? or does C++ implement true polymorphism this days, like what ML does ? C++ has offered true polymorphism for some time, complete component interchangeability. Something like --- bash-2.02$ ocaml Objective Caml version 2.02 # let id x = x ;; val id : 'a - 'a = fun # id 0 ;; - : int = 0 # id 1.2 ;; - : float = 1.2 # id hello ;; - : string = hello # id id ;; - : '_a - '_a = fun --- Not sure, but i think we are not talking with the same definition of the same word ? Friendly, Sven LUTHER
Re: Time to rewrite dpkg
Enrique Zanardi [EMAIL PROTECTED] writes: On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote: [...] Notably, I'm going to be writing it in C++. This will add about 270k to the boot disks' root image, but as the floppy install methods are for the most part phasing out under the shadow of easier methods, I'm not going to lose any sleep over this. libstdc++ can be minimized for static linkage anyway. dpkg is not on the boot disks' root image (thanks god). It's on the base system, with dselect, apt and, of course, libstdc++. You won't have to add it. (Let's call that luck). :-) OTOH, your opinion that adding 200k to the boot disks' root image, thus breaking the rescue floppy, doesn't matter because the floppy install methods are phasing out is just plainly wrong. Currently we have three ways of booting the installation system: bootable CDs (requires a modern BIOS), floppy disk and bootp (requires a netword card with the proper ROM, and a bootp+tftp server on the same network). Our bootable CDs use a floppy image for booting, the same resc1440.bin floppy image that's used on a floppy based installation. That means two of our three methods (and I dare to say the third one is used on 5% of Debian installations) use the same rescue floppy disk. I won't say that's pashing out. ;-) Why would this add 200k to the root disk? We don't have dpkg on the root disk, it's in the base image. Steve [EMAIL PROTECTED]
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 03:34:27PM +0200, Sven LUTHER wrote:
Something like
Objective Caml version 2.02
# let id x = x ;;
val id : 'a - 'a = fun
---
Not sure, but i think we are not talking with the same definition of
the same word ?
C++ isn't a pure object-oriented language -- not everything is an
object by any means. Nor are all classes subclasses of a single Object
superclass, which is what you're making use of above.
But yes, you can write an id() function which behaves differently depending
on what is passed to it. Either:
class foo { virtual int id() { return 1; } };
class bar : foo { virtual int id() { return 2; } };
foo f;
bar b;
cout f.id();// 1
cout b.id();// 2
// So yours would be:
int id2(foo x) { return x.id(); }
or:
int id(int i) { return 1; };
int id(double d) { return 2; };
cout id(1); // 1
cout id(1.0);// 2
Cheers,
aj, who isn't sure this is particularly relevant to debian-devel anymore.
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. PGP encrypted mail preferred.
``There's nothing worse than people with a clue.
They're always disagreeing with you.''
-- Andrew Over
Re: Time to rewrite dpkg
* Sven LUTHER said: Polymorphism is such an obvious pillar of structured programming that I can't understand how anybody could live without it. Is it? AFAICS none of the traditional languages like Pascal or C has polimorphism at its base... What you call polymorphism is just function name overloading, isn't it ? or Yes, function and operator overloading. does C++ implement true polymorphism this days, like what ML does ? No, to my knowledge it doesn;t :)) regards, marek pgpguwIYUQLjs.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Sven LUTHER said: Agreed. Too bad C++ does not support parametric polymorphism too well. Templates come close, so the hope is not lost. But the problem is that templates, nor exceptions or rtti (which are all elements of MODERN C++ programming) don't work well enough on the GNU platform... Is that true, I have heard this agrument often, but is it true, and is it still so today ? Is there effort made to fix this ? how far are they ? Yes, it is true. Moreover, AFAIK the g++ 2.7.2.x and egcs differ substantialy in that matter - and that's another problem. I just want to be sure this is true before people start using this as argument without even checking if things still are like that. For what it's worth, egcs is still in active development - thus you shouldn't rely upon it too strongly (yes, potato uses egcs as a standard compiler, but it still has problems) and g++ 2.7.2.x doesn't support the advanced features of C++ very well... marek pgpLDWHFytWal.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Sven LUTHER said: On Thu, May 20, 1999 at 12:44:02AM +0200, Marek Habersack wrote: 1. you create a C library with all the dpkg functionality inside 2. you compile and link it as a shared library 3. you write several simple drivers to interface the user to that library 4. the .so is loaded only ONCE - that's what shared libraries are for But you still have to parse the database, because you load the library only once don't mean that you will keep the database as is between two invocation of the front-end that uses the library. Sure it can be done, but it is not That's true. But it can be overcome by either using a database access daemon (wasteful) that all programs communicate with in order to access the database - it has the advantage that all the consistency checks are performed on one level - by the daemon and it's the daemon who serializes the database access. Second, the database itself could be optimized by using a different format (perhaps, as RPM does, a DB database?) to speed up searching it. regards, marek pgpa0696Ld8bo.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Antti-Juhani Kaijanaho said: Is that true, I have heard this agrument often, but is it true, and is it still so today ? Is there effort made to fix this ? how far are they ? I haven't used RTTI, but in my experience templates work without problems and exceptions work most of the time (the problems I have may well be Yes, most of the time..., but you can't rely on them working all the time. my bugs, not egcs'). Namespaces need work: for example, there is no clear separation between global namespace and the std namespace. The namespace concept, as documented in the standards, is not implemented even in half on the GNU platform, IMO. EGCS has contributed much to the progress. A year ago I didn't feel like C++ was ready for my use on the GNU platform. That's true, but it will take some more time before it is fully working. marek pgpjjD7Pdpr2p.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Sven LUTHER said: Is that true, I have heard this agrument often, but is it true, and is it still so today ? Is there effort made to fix this ? how far are they ? I haven't used RTTI, but in my experience templates work without problems I also heard that templates bloat the code, not just that they don't work, what about it, what size are your executable compared to equivalent C stuff, what speed do you loose by using C++ templates. I don't know about the overhead on GNU, but from what I remember Borland added about 30KB to every C++ executable whether it used exceptions or not (it was mostly the startup and stack unwinding code). As to the speed, it shouldn't affect it - as long as you don't use the try/catch blocks in your code. marek pgpvC4oHpSIea.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Hamish Moffatt said: mention templates. And I remember how did the C++ interface, in binary This was certainly true in g++ 2.7.x, but egcs seems much better. Much better, yes, but it's still not finished. (Exceptions and templates anyway; I don't know what rtti is.) RTTI stands for RunTime Type Identification marek pgpduorjGLesk.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Aaron Van Couwenberghe said: The answer is - you can't... All the languages you mentioned have clean C interacing methods, but no C++ ones. The reason is that C++ is not interoperable. No, no, no! one word for everyone. CORBA! I'm sorry to say that, but dream on... marek pgpEM6prF0cPa.pgp Description: PGP signature
Re: time to rewrite dpkg
* Brandon Mitchell said: Hi Aaron, I would be interested in seeing your design. It may clear up some concerns as to why you are picking your language (which seems to have I would like to see it as well. So far, not even a single argument has been presented to justify the selection of C++ - and namely, what advantages it gives here. guess I'm just a big fan of getting the design right since the resulting code of a bad design is much more difficult to fix than bad code with a good design. Holy words! The design in such an important project is the primary objective - the more thought over, the better will be the code. marek pgpgEZ2HkN2BQ.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 03:07:03PM +0200, Sven LUTHER wrote: I also heard that templates bloat the code Depends on how you use them. Templates work by duplicating code. what size are your executable compared to equivalent C stuff, Equivalent C code? For every template in C++ the equivalent code parametrised with macro expanion? About the same. what speed do you loose by using C++ templates. Runtime speed? None. Templates are optimised for speed. In fact, one of the design goals of C++ is that all features must be implementable affordably (from a systems programming point of view). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Good Times are back again! http://www.iki.fi/gaia/zangelding/
Re: Time to rewrite dpkg
On Fri, May 21, 1999 at 12:25:58AM +1000, Anthony Towns wrote:
But yes, you can write an id() function which behaves differently depending
on what is passed to it.
You misunderstand. id is the identity function, defined for all types
and returns what it is given. In C++ terms, then:
template class T
T id (T t)
{
return t;
}
and in Haskell
id x = x
with the optional type signature
id :: a - a
OO people speak of polymorphism. FP people call that polymorphism
ad-hoc polymorphism, while the parametric polymorphism commonly
seen in functional languages is usually regarded as superior in most
application areas.
In parametric polymorphism, functions always behave the same way
independent of what data type it is passed. Functions operate on as
many types is possible: id, for example, does nothing to its argument
so it can be applied to any type.
In ad-hoc polymorphism, you never know what a function does unless you
know the exact type of the argument. In parametric polymorphism, you
always know what a function does, regardless of what it is applied to.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Good Times are back again!
http://www.iki.fi/gaia/zangelding/
Re: time to rewrite dpkg
Hi, This mail is ignoring Aaron's request for peace over this topic, but I am not the person who can keep silent if there are obvious mistakes to point out. On Thu, May 20, 1999 at 12:39:39AM -0400, Dan Nguyen wrote: Well your subject says it all Time to rewrite dpkg. I'm assuming that you want to completely rewrite dpkg as a replacement for the current dpkg. A sort of dpkg2 persay. If your dpkg does eventually become the new standard, then the language you decide to use is very important. Think of egcs. We really should be happy that someone is actually deciding to work on our package managment. Even if Aarons dpkg will not be the one used in future Debian releases, it will have affect on the current dpkg. Everyone should be upset about the current state of dpkg. The reason we are not is because w are frightened, too. The interoperability subject isn't really a big issue; the base libraries could still be done in C for all I care, and I may just do so. But C++ is compatible with C, and as such anything that can be wrapped into C can be wrapped into C++, or vice versa. In addition, we have CORBA, which is extremely friendly towards C++ implementations, and much more powerful than common interop mechanisms with conventional languages such as RPC. IMHO. What the best thing to do is write your libdpkg in C. Remember C is still the standard language for Unix. dpkg is not Unix. Do I have to say more? Dpkg is a package manager, and any language can be chosen. If Aaron had said he would write it in Scheme, I would have applauded it. If you tell me you want to write one, too, but in Pascal, more power to you. Of course, I am exagerrating. There are pros and contras for any language, but it is silly to rule out anything beside C for historical reasons. And it will also allow a larger number of languages to possibily use those library calls. Who will write all these programs? Will you? The current libdpkg is written in C, how many programs use it? If you say, that YOU are going to write something in a language you need support for, you would have a point. It's your project and you can do what you like, but I believe that libdpkg should definately be written in C. Of course, you are entitled to your opinion. But the decisions are made by people who to do the work. If you want to use C++ for he actual dpkg, then you can make C++ wrappers around libdpkg for that. C++ has problems, its size is one of them. The size of the language or the size of the binaries? The language was carefully designed to avoid bloat of the binaries. C++ does not enforce any language feature on the programmer. The biggest size concern are exceptions. But exceptions will make error handling oh so much simpler and cleaner. About 50 percent of code is error handling. Use of exception can reduce the amount of actual program code tremendously, which does decrease the size of the program code (hence the binary). AND it is easier to understand. Did you take a look at the error handling code of dpkg? Use of the standard library is another point. The standard library makes the program code easier, and really does not increase the overall code, because if you don't use it, you have to replace it with your own code, which is a source of errors, too. The other is, C++ is in a constant state of flux. This is plain wrong. Your knowledge of the C++ language is a few years behind of current standards and implementation. Thanks, Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: time to rewrite dpkg
On Thu, May 20, 1999 at 08:02:09PM +0200, Marcus Brinkmann wrote: This mail is ignoring Aaron's request for peace over this topic, [...] but it should have not. Please ignore my last mail on this topic. I just noticed that the general discussions was vastly ahead of your contribution. Thanks, Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: time to rewrite dpkg
* Marcus Brinkmann said: This mail is ignoring Aaron's request for peace over this topic, but I am I just can't resist writing it: there was NO war on this subject, so why do you and Aaron want to make peace? become the new standard, then the language you decide to use is very important. Think of egcs. We really should be happy that someone is actually deciding egcs is a compiler which is not finished yet, it is (at least in respect with C++) incompatible with gcc... to work on our package managment. Even if Aarons dpkg will not be the one used in future Debian releases, it will have affect on the current dpkg. Of course, and nobody denies it. extremely friendly towards C++ implementations, and much more powerful than common interop mechanisms with conventional languages such as RPC. IMHO. What the best thing to do is write your libdpkg in C. Remember C is still the standard language for Unix. dpkg is not Unix. Do I have to say more? Dpkg is a package manager, and any language can be chosen. If Aaron had said he would write it in Scheme, I would have applauded it. If you tell me you want to write one, too, but in Pascal, more power to you. Wrong. You're getting it all wrong. dpkg is a vital component of the Debian distribution and, as such, it should be written with future in mind! And future can bring a dozen of programmers who can extend dpkg in some way and using a dozen differend languages. Then CAN interface with a C library without any problems, then CANNOT interface a C++ library. Point. So, if you want dpkg to be interoperable, extensible and following the rule everyone uses what language s/he likes, keep small size - you have to do it in C (all disscusions about which language is better put aside, ok?). Of course, I am exagerrating. There are pros and contras for any language, but it is silly to rule out anything beside C for historical reasons. You get it wrong again. It is not for HISTORICAL reasons, it's for the current status quo and the FACTS that speak in C's favor. And it will also allow a larger number of languages to possibily use those library calls. Who will write all these programs? Will you? The current libdpkg is written in C, how many programs use it? If you say, that YOU are going to write something in a language you need support for, you would have a point. Now, now! Those arguments are pretty inadequate, I'd say. Tell me, how many programs use libcap? Is that a reason why libcap should be dumped? And, I'm sure, there will be someone who will want to write the programs IF the library is well-designed, well-written and INTEROPERABLE. And the hypothaetical person will be free to chose the preferred language for his work - but it will not be possible when the library is in C++. It's your project and you can do what you like, but I believe that libdpkg should definately be written in C. Of course, you are entitled to your opinion. But the decisions are made by people who to do the work. Not in this case. This is not their graduate project, nor an experiment. It's a package which the entire Debian distribution relies on - and that makes it a COMMON EFFORT no matter who writes the program. The decisions how to design and write the program should come from the developer community - a common sense is what we need. wrappers around libdpkg for that. C++ has problems, its size is one of them. The size of the language or the size of the binaries? binaries, of course. Who cares about the language? The language was carefully designed to avoid bloat of the binaries. C++ does Dream. C++ does bloat programs. not enforce any language feature on the programmer. The biggest size concern are exceptions. But exceptions will make error handling oh so much simpler Not only. The IO library is really HUGE and you have to use it to be 100% C++. and cleaner. About 50 percent of code is error handling. Use of exception can reduce the amount of actual program code tremendously, which does decrease the size of the program code (hence the binary). AND it is easier to understand. You would be surprised what problems people have with all the try/catch blocks. Use of the standard library is another point. The standard library makes the program code easier, and really does not increase the overall code, because if you don't use it, you have to replace it with your own code, which is a source of errors, too. You are talking about things like STL or other template-based libraries? Then they will increase the binary size, and they will do it significantly. The other is, C++ is in a constant state of flux. This is plain wrong. Your knowledge of the C++ language is a few years behind of current standards and implementation. C++ isn't in state of flux anymore, true, but egcs (and it's the only compiler around on the GNU platform which can be used to do serious C++ programming) is. Speaking of which, are you going to
Re: time to rewrite dpkg
* Marcus Brinkmann said: [...] but it should have not. Please ignore my last mail on this topic. I just noticed that the general discussions was vastly ahead of your contribution. Too late :))) I just responded :) marek pgpHQENkp6Wkz.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote: 3. Most programmers would write code in C Yeah, uh. But that's the point isn't it? The current dpkg is written in C. How many programmers are working on it? The only contributions to our packaging systems today are done with C++ (apt), and perl (install methods). Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 12:47:59AM +0200, Marek Habersack wrote: But the problem is that templates, nor exceptions or rtti (which are all elements of MODERN C++ programming) don't work well enough on the GNU platform... It would be silly to try to use all features of such a complex language as C++ in a single program. The features exist to support your style of OO programming, whatever this is. Only very complicated projects would want to make use of such features in a way that current egcs can't handle. And note that development will just start. By the time this project enters a critical stage, egcs will be improved again. Thanks, Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg
* Marcus Brinkmann said: On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote: 3. Most programmers would write code in C Yeah, uh. But that's the point isn't it? No, that's the reality. The current dpkg is written in C. How many programmers are working on it? Again, that's not an argument. People come and people go, and more of them know C than C++. Besides, ech..., how can you draw an argument like this??? Is that a reason to write dpkg in Heskell, because the current maintainer fancies that? And what if he gets tired maintainig it? And what about compatibility? Extensibility? Interoperability? They don't matter at all, right? The only contributions to our packaging systems today are done with C++ (apt), and perl (install methods). Yes, yes. But you won't be able to use perl with C++ libraries. marek pgphVH7alp65y.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Marcus Brinkmann said: On Thu, May 20, 1999 at 12:47:59AM +0200, Marek Habersack wrote: But the problem is that templates, nor exceptions or rtti (which are all elements of MODERN C++ programming) don't work well enough on the GNU platform... It would be silly to try to use all features of such a complex language as Templates, exceptions, polymorphism, encapsulation, multiple inheritance, method and operator overloading - they all should be used in ANY modern C++ program. And at the very least, templates and exceptions still don't work well enough in egcc. And note that development will just start. By the time this project enters a critical stage, egcs will be improved again. No, the development shouldn't start yet. A project should be presented to the iterested people and a discussion should take place. Only THEN the actual development should start. By that time many things can change, yes. But if you start to write your code and base it on some feature which will change in the egcs, then what? Simple - you will have to rewrite all your code. marek pgpQPPTsW3lkG.pgp Description: PGP signature
Re: Time to rewrite dpkg IN IDL! :)
On Fri, May 21, 1999 at 12:27:32AM +1000, Craig Sanders wrote: C++ may be OO, but it's not very good OOand it tends to compile into code which is both bloated and slow. dpkg is already far too slow on old hardware...hell, it's too slow on a P200 with 200MB of RAM, now that the status and available files have over 3300 packages detailed in them. Yeah, it's slow, and it's written in C. And you want to cinvince me by your un-emotional argumentation that it will be even slower in C++? Strange. Last time I took a look at Stroustrups language it seemed that it would be carefully designed to not enforce too much overhead on language features, and no overhead on language features not used. Stroustrups book goes into detail, and always mentions which run time overhead you have to expect when you use a certain language feature. Most features are only one function call away. Exceptions are the single exception. Use of them will reduce the amount of code you have to write, and improves error handling drastically. Some functions that have a lot of error conditions to check that are fourty lines of C code with deep nesting are reduced to four or five lines of flat C++ code. The speed of dpkg has little to do with the language (as long as you use a compiled and not interpreted language). The number of packages is the cause of the speed problem, and the involved algorithms (parsing the ASCII file and putting it into a data structure). I am sure there is really room of improvement here. Picking one compiled language in favour of another for speed consideration but ignoring things like maintenability and development of code looks simple-minded to me. The difference in speed will be unnoticable if the same algorithms are used. Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: time to rewrite dpkg
On Thu, May 20, 1999 at 08:39:32PM +0200, Marek Habersack wrote: Of course, you are entitled to your opinion. But the decisions are made by people who to do the work. Not in this case. This is not their graduate project, nor an experiment. It's a package which the entire Debian distribution relies on You're wrong, reread what Aaron said. The CURRENT dpkg is what the entire distribution relies on. The CURRENT dpkg is written in C. You should be happy. If you believe it would be better to rewrite dpkg in C, go for it. More power to you! The size of the language or the size of the binaries? binaries, of course. Who cares about the language? Interesting. So you prefer bloated program code instead of bloated binaries? The time a human needs to understand and maintain a program is less valuaable to you than a few kilobytes of source code? People read program code, but they almost never read binaries directly. The language was carefully designed to avoid bloat of the binaries. C++ does Dream. C++ does bloat programs. Some compiler bloat. The language does not. And bloat is put a bit too simple. I don't care about a few kilobytes if it has direct and noticeable positive effect in the source code. and cleaner. About 50 percent of code is error handling. Use of exception can reduce the amount of actual program code tremendously, which does decrease the size of the program code (hence the binary). AND it is easier to understand. You would be surprised what problems people have with all the try/catch blocks. You would be surprised what problems people have with all this pointer arithmetic. You would be surprised what problems people have with all these regular expressions. You would be surprised what problems people have with all these parentheses. You would be surprised what problems people have with all these gotos. You would be surprised what problems people have with all these mnemonics. Did I get my point across? Use of the standard library is another point. The standard library makes the program code easier, and really does not increase the overall code, because if you don't use it, you have to replace it with your own code, which is a source of errors, too. You are talking about things like STL or other template-based libraries? Then they will increase the binary size, and they will do it significantly. How scary. What exactly is the problem with a bigger binary? The other is, C++ is in a constant state of flux. This is plain wrong. Your knowledge of the C++ language is a few years behind of current standards and implementation. C++ isn't in state of flux anymore, true, but egcs (and it's the only compiler around on the GNU platform which can be used to do serious C++ programming) is. See, I am the maintainer of libgtkmm. This is a huge wrapper library around Gtk, which uses a lot of templates, classes, derivation, whatever. The maintainer (currently about three people are actively working on the code) were able to maintain compatibility even with g++ 2.7.2.3 (which is horribly broken in every respect) until recently. I don't see them rewriting their code everytime with another egcs release. Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 08:47:00PM +0200, Marek Habersack wrote: The current dpkg is written in C. How many programmers are working on it? Again, that's not an argument. People come and people go, and more of them know C than C++. Besides, ech..., how can you draw an argument like this??? I can because I see what's happening to dpkg and it worries me. We all are blinded by dpkg. It works, yes. How long? The current sources don't even build properly out of the box. Problems are cropping up without people knowing how to fix them (see the bug list). Even very simple patches and changes need months to get into yet another non-maintainer release. Your argument is that there would be a lot of more hypothetical programmers for a C version. This is irrelevant as long as the real number of C programmers willing to do this is 0 == NULL and the number of C++ programmers is at least 2, if not more. Is that a reason to write dpkg in Heskell, because the current maintainer fancies that? You're exaggerating. What if someone would propose doing it in ZX 80 assembler and running it on an emulator? Yeah. Bad idea. But there seem to be enough C++ deevelopers around here, and more and more will follow (if you haven't noticed, on universities they teach Scheme, Java , Perl and C++, depends on which faculty you are looking, AI, linguistics or math/computer science). And what if he gets tired maintainig it? I am absolutely sure that it would take me less effort to learn Huskell from scratch and work on a very clean and well written Huskell version of dpkg than to work on the current dpkg in C. Yes, I have taken a deep look into the dpkg source. I even worked on some things. And what about compatibility? Extensibility? Interoperability? They don't matter at all, right? In my book, yes. But compatibility which what? Extensible to where? Your arguments are not really good ones, you can write good and bad code in any language. But even if they were, they are hypothetical anyway. My proof: The current dpkg is written in C. Is it compatible? No. I needed to fix a lot of stuff to make it work on the Hurd, and it was a pain to find out how to fix things. Is it exensible? Not easily, because the code is difficult to follow. Is it interoperable? With what? I don't want to make dpkg bad here. But you tell me how wonderful C code can be, and how bad C++ code alwas can be, but I see dpkg, which is in C, and I see apt, which is in C++, and I don't understand how you can be so sure about that. Using C does not grant you immediate success. It does not give you compatibility for free. It does not give you extensibilty and operability. Neither does C++. You have to code it. The only contributions to our packaging systems today are done with C++ (apt), and perl (install methods). Yes, yes. But you won't be able to use perl with C++ libraries. Big deal. The current perl code does usually not use C libraries. They call the executable. Great, eh? Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 08:50:26PM +0200, Marek Habersack wrote: And note that development will just start. By the time this project enters a critical stage, egcs will be improved again. No, the development shouldn't start yet. A project should be presented to the iterested people and a discussion should take place. Only THEN the actual development should start. By that time many things can change, yes. But if you start to write your code and base it on some feature which will change in the egcs, then what? Simple - you will have to rewrite all your code. It's hardly to respond anything reasonable to that. This is such a gross exaggeration, and such a demanding and arrogant attitude, that I can simply stop just as well. Sorry, but you seem to be trapped in your argumentation. Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg
* Marcus Brinkmann said: Again, that's not an argument. People come and people go, and more of them know C than C++. Besides, ech..., how can you draw an argument like this??? I can because I see what's happening to dpkg and it worries me. We all are blinded by dpkg. It works, yes. How long? The current sources don't even build properly out of the box. Problems are cropping up without people knowing how to fix them (see the bug list). Even very simple patches and changes need months to get into yet another non-maintainer release. I aggree. I have looked into dpkg code and it scared me, yes... Your argument is that there would be a lot of more hypothetical programmers for a C version. This is irrelevant as long as the real number of C programmers willing to do this is 0 == NULL and the number of C++ programmers is at least 2, if not more. You can count me in both groups - I have NO personal preference as to the language used, none at all. The tool doesn't matter that much, the effect does - and the more commonly acceptable, the better in that case. Is that a reason to write dpkg in Heskell, because the current maintainer fancies that? You're exaggerating. What if someone would propose doing it in ZX 80 assembler and running it on an emulator? Yeah. Bad idea. But there seem to be enough C++ deevelopers around here, and more and more will follow (if you haven't noticed, on universities they teach Scheme, Java , Perl and C++, depends on which faculty you are looking, AI, linguistics or math/computer science). Don't talk about universities. I've seen too many university graduates that know nothing about real-world programming... And what about compatibility? Extensibility? Interoperability? They don't matter at all, right? In my book, yes. But compatibility which what? Extensible to where? Compatibility with everything used to program - meaning, easy interfacing with other programming languages. Extensible to other environments, or simply put - creating frontends and utilities to easily manage the packages - vide gnomeapt for apt. Your arguments are not really good ones, you can write good and bad code in any language. But even if they were, they are hypothetical anyway. My proof: The current dpkg is written in C. Is it compatible? No. I needed to fix a lot of stuff to make it work on the Hurd, and it was a pain to find out how to fix things. Is it exensible? Not easily, because the code is difficult to follow. Is it interoperable? With what? Once again: I DON'T CARE WHAT LANGUAGE IS USED HERE. I just see that blind faith in any language can lead to a product which can be extended only in that language. And why to do that when you can a) DESIGN good procjec b) CODE it in C c) EXTEND it with virtually every other programming language Can't you see that C is simply a BASIS on wich you can build everything you imagine. Someone said C is primitive - true, but that's why it's so powerful. There are better designed languages out there, which have better theory behind them, true, but no language is so common as C, and as such (!!) it should be chose to create tools which are to be extended, either now or in the future. Look, how many years dpkg has been virtually in the center of the Debian dist??? And that's why you have to THINK ABOUT THE FUTURE and not discuss about what language is better for THEORETICAL reasons. We deal with practice, not with theory here. I don't want to make dpkg bad here. But you tell me how wonderful C code can be, and how bad C++ code alwas can be, but I see dpkg, which is in C, and I see apt, which is in C++, and I don't understand how you can be so sure about that. I'm starting to lose my nerve... I NEVER said that C is better or C++ is better IN GENERAL. I just think that C is better for THIS task and so far nobody convinced me that it cannot be done in C. It's all a matter of design, when we speak about the program/library itself, and not of the language chosen. But from the point of view of the final product, the language choice appears to be important since it will affect what tools can be used to FURTHER extend dpkg. Using C does not grant you immediate success. It does not give you compatibility for free. It does not give you extensibilty and operability. I never said it. (apt), and perl (install methods). Yes, yes. But you won't be able to use perl with C++ libraries. Big deal. The current perl code does usually not use C libraries. They call Big deal you say? ^^^you said it. If the library is written well in C, then code in perl, tcl, scheme, elisp, java, whatever will use it because it will be EASIER this well. It all comes down to GOOD DESIGN. marek pgp93xNXekGoa.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Marcus Brinkmann said: On Thu, May 20, 1999 at 08:50:26PM +0200, Marek Habersack wrote: And note that development will just start. By the time this project enters a critical stage, egcs will be improved again. No, the development shouldn't start yet. A project should be presented to the iterested people and a discussion should take place. Only THEN the actual development should start. By that time many things can change, yes. But if you start to write your code and base it on some feature which will change in the egcs, then what? Simple - you will have to rewrite all your code. It's hardly to respond anything reasonable to that. This is such a gross exaggeration, and such a demanding and arrogant attitude, that I can simply stop just as well. I'm sorry, but you seem to be arrogant here. You cut the DISCUSSION with statements like this instead of saying anything reasonable. So you think that design and project don't matter right? That what developers and people who are to use dpkg thing doesn't matter, right? Well, I think you have worked for Micro$oft then. marek pgphafRDfTGfa.pgp Description: PGP signature
Re: Time to rewrite dpkg IN IDL! :)
Hamish Moffatt [EMAIL PROTECTED] writes: On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) I don't see why not. How about it's complete overkill? Sure, and without complete overkill, how will we take full advantage of the second-system effect? :-) I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Then you're not looking very carefully. It's overkill may turn out to be a valid objection, but it couldn't benefit from OO is, IMO, completely false. Elisp packages spring to mind. We *do* have different classes of package; we just force them all into the same mold. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: time to rewrite dpkg
* Marcus Brinkmann said: Of course, you are entitled to your opinion. But the decisions are made by people who to do the work. Not in this case. This is not their graduate project, nor an experiment. It's a package which the entire Debian distribution relies on You're wrong, reread what Aaron said. The CURRENT dpkg is what the entire distribution relies on. The CURRENT dpkg is written in C. You should be happy. If you believe it would be better to rewrite dpkg in C, go for it. More power to you! I have just one question to you - have you read the ENTIRE thread??? Or just several lines? If so, then please go back AND READ IT. Only then you have a right to jump upon me like that. Before you joined the discussion, we were DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you. The size of the language or the size of the binaries? binaries, of course. Who cares about the language? Interesting. So you prefer bloated program code instead of bloated binaries? The time a human needs to understand and maintain a program is less valuaable to you than a few kilobytes of source code? People read program code, but they almost never read binaries directly. Yeah, yeah. Go back to one of your previous postings and read what you said: language doesn't guarantee anything. You have to code it. These are your words and right now you are contradicting yourself. IF you design the code well and implement it well, then it doesn't matter what language you use. You seem to me a little bit fanatic, because what you suggest in the statement above is that C cannot be used to write clear programs. That's a bag of moonshine. C, C++, Python, Lisp, Scheme, Smalltalk - you name it, all can be used to write awfully complicated code which nobody understands. The design is what matters when you talk about readibility of the code. Look at the linux sources, they are in C and theay readable and clear. Point taken? The language was carefully designed to avoid bloat of the binaries. C++ does Dream. C++ does bloat programs. Some compiler bloat. The language does not. Yes, but you use a compiler to produce a binary, not the language... And bloat is put a bit too simple. I don't care about a few kilobytes if it has direct and noticeable positive effect in the source code. You don't care, good. I do care. You would be surprised what problems people have with all the try/catch blocks. You would be surprised what problems people have with all this pointer arithmetic. You would be surprised what problems people have with all these regular expressions. You would be surprised what problems people have with all these parentheses. You would be surprised what problems people have with all these gotos. You would be surprised what problems people have with all these mnemonics. Did I get my point across? yes, now I know you understand it well. But I don't know why are you trying to pick up a flamewar? What are you so angry about? Why can't you discuss instead of flaming? You are talking about things like STL or other template-based libraries? Then they will increase the binary size, and they will do it significantly. How scary. What exactly is the problem with a bigger binary? Hmm... what exactly? If we have 10 programs written in C that have to fit on one diskette and each of them adds extra 30KB, plus several dozens of kilobytes for the libraries, then what has to fit on one diskette is at the very least 300KB, and that's the problem I see. Your knowledge of the C++ language is a few years behind of current standards and implementation. C++ isn't in state of flux anymore, true, but egcs (and it's the only compiler around on the GNU platform which can be used to do serious C++ programming) is. See, I am the maintainer of libgtkmm. This is a huge wrapper library around Gtk, which uses a lot of templates, classes, derivation, whatever. The maintainer (currently about three people are actively working on the code) were able to maintain compatibility even with g++ 2.7.2.3 (which is horribly broken in every respect) until recently. I don't see them rewriting their code everytime with another egcs release. I never said every time. Once again, please, read the entire thread. marek pgp07ybzJmR4r.pgp Description: PGP signature
Re: Time to rewrite dpkg IN IDL! :)
* Marcus Brinkmann said: dpkg is already far too slow on old hardware...hell, it's too slow on a P200 with 200MB of RAM, now that the status and available files have over 3300 packages detailed in them. Yeah, it's slow, and it's written in C. Linux is slow. It's written in C. Yeah... And you want to cinvince me by your un-emotional argumentation that it will be even slower in C++? [snip] ignoring things like maintenability and development of code looks simple-minded to me. The difference in speed will be unnoticable if the same algorithms are used. Now you've proven it. You're a fanatic. And you offend people. Thanks. marek pgpHDpoQLf95Z.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 09:55:59PM +0200, Marek Habersack wrote: I'm sorry, but you seem to be arrogant here. You cut the DISCUSSION with statements like this instead of saying anything reasonable. I said that I don't agree with you, and that I think your arguments against C++ are invalid. I even said why I think so, and you just have to believe me because you can't control what I think. You don't need to agree with me. So you think that design and project don't matter right? No, I don't think so. That what developers and people who are to use dpkg thing doesn't matter, right? Yes and No. Yes, because we don't speak about changing dpkg. No, because I think that some developers and uses have actually some useful contributions to do. I didn't saw that from you. Well, I think you have worked for Micro$oft then. You are putting an immediate end to the discussion. Thank you for that, I was already trying to find a way out. Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) Wowch! Nothing against CORBA, I love it, but if I think about the overhead. I recently compiled the 2.2 Kernel: 6 minutes, I compiled MICO: 2 hours!!! Ok, I know, handling the complexity of today computing needs powerful tools, and CORBA is jsut the way to go, but i do not think, the world is ripe for that in the *very basic* tool on any system. If you have to run a server like that just to install Debian, you can well double the minimum amount of needed memory. So, having a way to access dpkg via CORBA would be a great thing, but still it has to work without as well. Should be possible to have a simple C++ library but have IDLs for it as well in some way, so the objects can be shared. Ciao, Nobbi -- __ -- JESUS CHRIST IS LORD! -- To Him, even that machine here has to obey... -- -- _Norbert Nobbi Nemec -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany -- eMail: [EMAIL PROTECTED]Tel: +49-(0)-911-204180
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 09:27:10PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 09:14:26PM +1000, Hamish Moffatt wrote: How about it's complete overkill? I don't think so. Yes you can write maintainable code with plain C, but with the number of developers moving in and out of Debian, I think that a decent OO approach for core software could make it more maintainable for _everyone_. I often feel that I'd like to help contribute code to some things, but, not being an overly confident programmer, I am daunted by code that takes a long time to understand. I personally find OO design much easier to follow. This is personal preference however. I think a good object-oriented design can be easier to follow too. In circumstances where there is naturally some use for inheritance it is very useful indeed. I don't see any natural inheritance in managing packages, though. I think that forcing a procedural program into classes just for the sake of it would destroy the clarity you're looking for. Besides, any advantage in a nice OO design is lost by implementing it in C++! Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 01:02:00PM -0700, Chris Waters wrote: Hamish Moffatt [EMAIL PROTECTED] writes: I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Then you're not looking very carefully. It's overkill may turn out to be a valid objection, but it couldn't benefit from OO is, IMO, completely false. Elisp packages spring to mind. We *do* have different classes of package; we just force them all into the same mold. Can you expand the Elisp example? Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:45:09PM +0200, Marcus Brinkmann wrote: On Fri, May 21, 1999 at 12:27:32AM +1000, Craig Sanders wrote: C++ may be OO, but it's not very good OOand it tends to compile into code which is both bloated and slow. dpkg is already far too slow on old hardware...hell, it's too slow on a P200 with 200MB of RAM, now that the status and available files have over 3300 packages detailed in them. Yeah, it's slow, and it's written in C. And you want to cinvince me by your un-emotional argumentation that it will be even slower in C++? Strange. Last time I took a look at Stroustrups language it seemed that it would be carefully designed to not enforce too much overhead on language features, and no overhead on language features not used. Stroustrups book goes into detail, and always mentions which run time overhead you have to expect when you use a certain language feature. Most features are only one function call away. in theory, theory and practice are the same. in practise, they're different. i've always favoured practical considerations over nice theories. In practice, C++ programs are larger and slower than they ought to be. craig -- craig sanders
Re: time to rewrite dpkg
On Thu, May 20, 1999 at 10:07:09PM +0200, Marek Habersack wrote: I have just one question to you - have you read the ENTIRE thread??? Or just several lines? If so, then please go back AND READ IT. Only then you have a right to jump upon me like that. Before you joined the discussion, we were DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you. What is there to discuss with you? Your entire position can be boiled down to a paraphrase of Henry Ford: You can rewrite dpkg in any language you want, as long as it's C. You've made your point clear. You (and Marcus, to a large degree) have become completely sidetracked by arguing tiresome C++ pros and cons. But Marcus also grasps that He Who Writes the Code Makes the Rules. I'm sorry it offends your aesthetic that Aaron plans to reimplement dpkg in C++. But it is not your decision to make. The best support you can provide for your arguments is to redesign and reimplement the Debian packaging system yourself (or with people you recruit to the task). So get to work. If you reply to this message, do not be surprised if I don't to yours. -- G. Branden Robinson |A committee is a life form with six or Debian GNU/Linux |more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein cartoon.ecn.purdue.edu/~branden/ | pgpiWAPjveWiw.pgp Description: PGP signature
Re: time to rewrite dpkg
* Branden Robinson said: several lines? If so, then please go back AND READ IT. Only then you have a right to jump upon me like that. Before you joined the discussion, we were DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you. What is there to discuss with you? Your entire position can be boiled down Probably nothing... to a paraphrase of Henry Ford: You can rewrite dpkg in any language you want, as long as it's C. Oh no I never said it... You're the next person to accuse me of it. I think I really have nothing to say then... I'm sorry, I wasted your time. I'm sorry it offends your aesthetic that Aaron plans to reimplement dpkg in NO IT DOESN'T! Have I made myself clear THIS TIME? It doesn't as I myself program in BOTH languages - I just try to forsee what MIGHT be better. That's what discussion is for. And if Aarond didn't want to discuss his idea why would he send this posting? Wasn't it better to write the code and then show it?? I think I'm getting wrong all of it here, maybe I'm just stupid... C++. But it is not your decision to make. Gosh... The best support you can provide for your arguments is to redesign and reimplement the Debian packaging system yourself (or with people you recruit to the task). So get to work. I'm sorry, why are you attacking me? I wasn't the one who said he wants to redesign the package. I responded to a posting posted to a PUBLIC mailing list, that's it. Not even once I said here that I want to redesign it. I just had my doubts and wanted to share them with you all - if that's a crime, then I'm sorry - I'm guilty. It seems that one can express his ideas and doubts as long as they are the same as of the original poster... sorry for wasting your time, just ignore postings with my name on them regards, marek pgpYeHFrG6pMM.pgp Description: PGP signature
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 10:09:34PM +0200, Marek Habersack wrote: Now you've proven it. You're a fanatic. And you offend people. Thanks. there's no excuse for personal attacks. if you have a point to make, then make it but don't stoop to ad hominem attacks. i think i'll just ignore the rest of the thread now...it probably isn't worth reading if it's got down to this level. craig -- craig sanders
Re: Time to rewrite dpkg
*Marcus Brinkmann wrote: On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote: 3. Most programmers would write code in C Yeah, uh. But that's the point isn't it? The current dpkg is written in C. How many programmers are working on it? I've often wondered about that. Occaisionally I see people getting involved, or offering patches, and it seems that IWJ is not interested. I will not speculate on what may be going on, but I have always found the development of dpkg to be rather curious. Anyone know what is going on ? The only contributions to our packaging systems today are done with C++ (apt), and perl (install methods). -- John Lapeyre [EMAIL PROTECTED], [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Time to rewrite dpkg
*Marek Habersack wrote: Yes, yes. But you won't be able to use perl with C++ libraries. If you use the C interface to the C++ libraries, and reimplement OO in perl, yes you can. And the C++ wrapping has improved to the point that people are using it directly for some projects. -- John Lapeyre [EMAIL PROTECTED], [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote: Why C++? Well, personally, I have been seeing all of these applications pop recently that are for package management, aside from dpkg. Examples include dconfig and apt. Other ideas have been floating about, like source dependencies and binary diffs. I say that most of these applications would benefit greatly from having access to all of dpkg's functionality and variables, so nobody has to reinvent the wheel. I want to make all of these a part of dpkg. That seems... the wrong way around. One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. In particular, there are established ways of linking programs written in any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. Good luck, FWIW. I've no doubt you'll need it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpzMyPSf54ij.pgp Description: PGP signature
Re: Time to rewrite dpkg
Hello, esteemed members of the Debian enthusiast community! So, whether or not I recieve the approval of this community, I'm going to be working on a complete rewrite of dpkg. No, it won't even *resemble* the old dpkg; I guarantee it to become contraversial. I'll let the masses decide whether it warrants trashing the old for the new. Go for it. Have fun. Document and read. There has been quite some discussion on this subject. My only comment is that apt will likely be on a boot disk near you real soon so libc++ is there too. Make not of dpkg's short comings. Aim for compatibility. Remember the creed of debian always has clean upgrades. And place a cvs somewhere so interested parties can join in the fray.
Re: Time to rewrite dpkg
Hellow Aaron and fellow Debian enthusiasts. :-) Aaron, I would like to get involved with your attempt at rewriting dpkg, especially since it is something I've considered attempting. -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Time to rewrite dpkg
Hi Anthony, On 20 May, Anthony Towns wrote: One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. I don't think that is a complete solution. Improving libdpkg would be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. In particular, there are established ways of linking programs written in any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. C++ libraries aren't bad once you get to know them. If you are concerned about linking other languages to a C++ library then you can always provide C wrappers around C++ library functions. This isn't an optimal solution. And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Using object oriented design patterns (see any good book on OO design patterns), for example, makes code much easier to understand and/or implement. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. Good luck, FWIW. I've no doubt you'll need it. Indeed. It is an ambitious endeavor but a worthy one nevertheless, IMHO. Aaron, you've got my support. :) -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Time to rewrite dpkg
* Aaron Van Couwenberghe said: Notably, I'm going to be writing it in C++. This will add about 270k to the boot disks' root image, but as the floppy install methods are for the most part phasing out under the shadow of easier methods, I'm not going to Are you sure about that? If yes, the you probably don't install debian very often. In serveral places, including my own company, which have a few linux workstations and at least one server I like to put the Debian dist CD into the server, mount it in the anon ftp tree and install/upgrade the workstations using FTP - that way I can cut down on costs of the equipment, I can simultaneously install linux on several machines - from ONE source instead of having a dozen copies of the Debian CDs. And, yes, I install from FLOPPIES - now you're telling me the new dpkg won't fit on floppies, right? It won't sell... as I'm sure I'm not the only one installing Linux on workstations this way. Why C++? Well, personally, I have been seeing all of these applications pop recently that are for package management, aside from dpkg. Examples include dconfig and apt. Other ideas have been floating about, like source dependencies and binary diffs. What does it have to do with the actual code? Language chosen is mostly a matter of preference, more often of compatibility and compactness of the produced code. C++ doesn't have the two latter issues... Take a look at what's happening with egcc's support for C++ - it's constantly gaining new features, according to the official standards - to name only one, rtti. Every new language feature in some way changes the way of mangling C++ names, and RTTI will also add entry points for various checking procedures etc. And you will surely have compatibility (binary) problems as the time passes. And code is as good as it's structure and design and not the language used. C programs can be constructed in a very clean, modular and extensible way and they still remain COMPATIBLE and COMPACT. I say that most of these applications would benefit greatly from having access to all of dpkg's functionality and variables, so nobody has to reinvent the wheel. I want to make all of these a part of dpkg. This also dosen't justify the selection of C++ as the language... On the contrary - I'd reccomend NOT to use C++ to create the shared components of dpkg. Remember, most programmers program in C for various reasons, not the very least of them being compatibility. Also, C has the nice feature that libraries written in C can nicely be linked with programs written in almost every other popular language - be it interpreted or compiled - perl, tcl, java, javascript, C++, lisp, scheme - you name it. Most of those interpreted languages have interfaces to use C as the extension language, while they DON'T support (nor they ever will, I presume - again, compatibility) C++... So, if you want't your new dpkg be really extensible, modular and modern - do it in C, but do it it a cleaner way. called modular software, and we have this capability in linux today. dpkg should be able to accept addons at runtime, or to override default behavior by a configuration file explaining where important methods exist. Again, C does it for you, C++ isn't really useful here. Consider the benefits. First, dpkg comes as a 350k executable, containing nothing but basic logic for commandline arguments and a static link of libstdc++. Apart from that, libdpkg is required for dpkg to function properly; This library defines all behavior for operations on packages and the package/status databases. And you call a 350k monster a BENEFIT?? If you have a shared library with ALL the functionality in it, then the DRIVER executable can be as small as 35k - and that's what I call a benefit. Plus, you can do it in C, you can't in C++ - the latter will always be much larger. Now, consider: If I want dpkg to be able to install files via http, I can just plug in the appropriate module and supply the necessary arguments. Now, consider if apt were a module: both dpkg and every frontend written for it would inherit functionality for all available file retrieval methods. This would eliminate much of the kludgery involved with coming up with installation methods for dselect. Once again, this doesn't justify C++... All of this can be done in much cleaner (binary-wise) way in C. Also, you even once didn't mention any feature that's C++ specific and that would justify selection of C++. If you were talking about a hierarchy of classes, encapsulation, polymorphism - then you would justify C++ as THE language for dpkg. I can imagine a hierarchy of classes, each of them designed for a specific task, each of them deriving features from it's parents - and all that in a modular way. Yes, that can be done - but why? It can be done in C equally well... Consider again something more complicated, like bindiffs. Supplying the appropriate arguments (--unpack-bindiff
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 10:03:12AM -0500, Ossama Othman wrote: Hi Anthony, And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Using object oriented design patterns (see any good book on OO design patterns), for example, makes code much easier to understand and/or implement. Please don't go into the C++ vs C flamewar here, ... it is as possible to do bad and unmaintainable code in C++ as it is possible to do good and maintainable code in C or another not OO language. what you need is good design, not some magic language to write nice code. Friendly, Sven LUTHER
Re: Time to rewrite dpkg
* Ossama Othman said: One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. I don't think that is a complete solution. Improving libdpkg would be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. Well, a complete rewrite and redesign in C would help... any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. C++ libraries aren't bad once you get to know them. If you are It isn't about C++ libraries being bad, or C++ being bad language, but about compatibility and an issue of C++ still being in a state of flux in a GNU world... And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Using object oriented design patterns (see any good book on OO design patterns), for example, makes code much easier to understand and/or implement. That's true, but again, the compatibility and unstability of the C++ implementation on the GNU platform is an obstacle. OTOH, we have Objective C... Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. Good luck, FWIW. I've no doubt you'll need it. Indeed. It is an ambitious endeavor but a worthy one nevertheless, IMHO. Aaron, you've got my support. :) I'm not convinced this is a good way, but I admire the courage - g'luck from me as well :)) regards, marek pgpM0iAcvc1no.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 10:03:12AM -0500, Ossama Othman wrote: On 20 May, Anthony Towns wrote: One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. I don't think that is a complete solution. Improving libdpkg would be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. I was thinking more along the lines of `replacing', than improving. Basically, implementing the fundamental operations dpkg does as a library, then coding a simple, dumb dpkg(1) that links to that library but does little or no more than argument parsing itself. Having C++ wrapper classes around it for Apt and dpkg's convenience maybe, but being just another C-based library at heart. And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Oh sure, I've got nothing against OO design/analysis/programming. I don't even have all that much against C++ -- but I don't like the idea of locking any later apps into using C++ if it's /reasonably/ avoidable. In particular, if you find that you're not using too much inheritance/polymorphism for the core functionality of dpkg, you can get most of the benefits of OO programming without contorting C and friends all that much. But at least for the moment, I'm not doing any coding, so it's not my decision. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpVQ5qLDF3Q8.pgp Description: PGP signature
