Hello, Rogério Brito said on Tue, Sep 08, 2009 at 10:47:23AM -0300:
> > I'm not a pure expert, but know where I want the code to go. And my > > will is: > > remove useless static memory allocation (tricky) > > I'm not sure about which static memory allocation you mean. Do you mean > "char foo[BIG_SIZE_HERE]"? Yes; It has caused many different issues in the code (strcat without checks leading to seg fault, stupid limitations in sizing, huge allocation of memory where it's not useful, ...) > Depending on the situation, just including > some malloc's/free's are gratuitous artificial complexity. Well if it's done at a sufficiently low level, it's not a problem IMO. It's relatively fast, you use what you need only, and adapt to machine resources, not to fixed barriers (nobody will ever need more than 640KB syndrom ;-) > And, anyway, if said code is not used in a non-standard ways, it is > marked "auto" by the compiler and disposed when the scope of the > function ends. THere were some recursive and interesting usage + some statics. > I usually favor statically compiled languages, but I'm not opposed to > Perl, *if* the programs don't inflate the memory requirements of the > interpreter too much. Will have to measure that. But frankly looking at the code since 8 years now, and more precisely during the last 4, most of what was written in C should never have been written in C !! : The code still contains more than 600 "system" calls ! Or how to use C as a scripting language. There are some parts that could benefit from staying in C, but only a few IMO. > We would like to want the code to work even on small platforms, after > all. Yes but nowadays it's far from being the majority of users. Now we could target netbooks, phones, ... why not. But that would anyway require a good re-architecture/re-write. And perl is available on so many platform it shouldn't be a problem. And I always found the perf great (never looked too much at the memory side). > Sure, but I'd guess that they may not be that interesting, now that the > versions have diverged a bit. > > I'm including it here anyway. Please, note that the patch has already > three patches in it (patch in patch format, to be handled with quilt). I don't know quilt myself. IIUC it aggregates patches. Why not, as Andree can say to you, I tend to prefer single (small ;-) patches in order to study them before inclusion. It seems that the lzma file is not clean: lzma: Decoder error Could you resend it again please ? (start is on control file modifications, and I'll apply them without issue). > Very nice. I am short on space and like to keep my backups under 500MB, > so that I can use dvdisaster (yes, I am a bit paranoid). > > BTW, by using dvdisaster, one can create solid archives (like I > mentioned with you many moons ago). And the backups are smaller > themselves. Sorry forgot about that. Indeed looks very interesting. Will package it for my Mandriva which doesn't seem to have it. Would you like to contribute a mondo extension allowing its joint usage ? > OK, in a slightly tangent comment, it seems that the version 2.2.7 has > problems with Linux images that have not been compressed with gzip > (newer kernels allow bzip2 and lzma compressed images). Do you have > support for that? Humm. Not at the moment. > Right now, mondo dies trying to be smart about the kernel that I > compiled if I use one of those images, but it is wrong in its decision. It's in GetInitrdFilesystemToUse and only supports gziped compressed kernel. Can easily be adapted (this code was made by Andree BTW for Debian originaly and was merged ;-) > And, BTW, why are > there differences regarding burning CDs/CD-RWs? I can't really see the > point (besides the fact that CD-RWs may have to be blanked before > writing them). I know there are diffs for drive that can eject/inject or not but I also never understood why they were considerd separately indeed. Probably more cleanup to do. > I absolutely agree that sane defaults are essential. But letting the > experienced user override the defaults is important to have a good share > of the target "market" for this tool. Which is aplea for config file which are right now missing in mondo. It's in my trunk tree (useless BTW except for taking some ideas I tried). > No problems with postponing things. But I am much more favorable to > gradual changes than to radical changes. +1 ! > Over-engineering is a problem that should be avoided. A certain degree > of generality is good, but not that much. Vast question ;-) > Great. Now that GCC 4.4 has test coverage, we can see which paths are > used and which ones are not. I'm interested if you can give example of how we could apply that to mondo. > Size is still important (and will always be), but 1MB of a 650MB CD > wouldn't make that much difference. It's a bit more today. mindi is around 30MB. It's still less than 10% of a CD and nothing of a DVD/USB key. > > > * cleaning the logs a little bit. > > You mean the project logs or Debian logs ? > The logs generated by mondo. Ah. Iv'e made huge change for 2.2.10 around that as I was fed up with their difficulty of reading :-( > Some sentences could be shortened and replaced by more precise > statements of what is being done. Some formatting should be done to make > them easier to read (and to parse with automatic tools). Of course, improvement is still needed for content, but at least format should looks much better. > I'm religious about the 80 columns limit, but I have been known to be an > heretic from time to time. :-) Oops, so beware that I have a very large screen both at work and home, use gvim and J extensiveley to put everything on a single line I find much more convenient to understand when looking at if/then/else statements ot stuff like that. Well, will see how to deal with that ;-) > Hummm, variable and function names is a hard problem (especially > guaranteeing that they don't collide), but this is also on my list of > things to change. Humm. Do that with care, as i'm now more and more used to the (sometimes ridiculous) function names, so it should be done slowly. I tend to introduce new functions prefixed with mr_ to avoid namespace clashes. And my way of dong code is more obvious in the new libmr.a library if you want to look. > The changes that I'm thinking about are to change from "very hard > dependencies to hard dependencies, which the package manager will still > obey, but that can be overridden by the administrator, as he is the one > that knows best what he needs". No pb. Fien with me. > This seems to be a really small world, as I work with Bdale on another > project. :-) So the first one to see him has to say hello ! However, it's a big world: Andree is from Australia, you from Brazil and I'm from Europe. Quite a large dev team from a geographical perspective ;-) Greetings, Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
