On Fri, Aug 04, 2000 at 08:49:20PM -0700, John Gerth wrote:
> I tried Rudi's patch (and the mouse patch in todo.py) but it
> still blew up trying to write the X config file later on.
Ooops! I thought I had posted a follow-up describing what had happened
during the final test (my mail was sent while I was burning the CD),
but obviously I haven't. I probably was distracted by the (now fixed)
"mutt trashes my mailbox when I run out of disk space" bug.
> Anyway, my wizard said that the problem was not with line 174,
> but with the line 170 which Rudi had also noted. It reads
> self.vidCards = [card]
> and line 174 should be replaced so as to read:
> self.vidCards = [self.cards(card)]
> which creates the array needed in line 174 (and also later on).
I myself had problems later on. Debugging Anaconda 6.2 has turned out to
be quite painful, as the test mode doesn't seem to test that much [on my
system it only changes the clock settings for real - while I'd expect it
not to! - after which it chokes on something. Of course, when you're
testing something, most of the times you enter random data, so all I was
actually doing was setting a random value for my machine's clock... but I
digress as usual]. The only real way to make tests seems to be burning
CDs. May everlasting happiness reward whoever gave us CD-RWs.
Anyway, as soon as I removed the problem I mentioned, it turned out that
my modification broke some code which gets executed later (ouch).
Apparently setVidcard gets called from two different places, with two
different types of arguments: IIRC, once "card" is passed as a string and
once as an array. Oh, the joys of dynamically typed languages!
Here's what I eventually used, which (apply standard disclaimers here)
works fine for me. Note the "if type(card) etc. etc.".
def setVidcard (self, card):
if type(card) is StringType:
self.vidCards = [self.cards (card)]
else:
self.vidCards = [card]
self.primary = 0
if self.vidCards:
self.devID = self.vidCards[self.primary]["NAME"]
self.server = self.vidCards[self.primary]["SERVER"]
I suppose a Python wizard, after a quick look at the code above and the
two places where it gets called, might come up with the definitive
solution. I can't give more details, as this occurred a couple of weeks
ago and I had to face even more puzzling problems in the meantime - has
anybody found unresolved dependencies in module "emu10k1.o" when
rebuilding the kernel-2.2.16-3 package? It literally drove me insane
before I could nail it down...
--
"Con onor muore chi non puo' serbar vita con onore" (Madama Butterfly)
Rudi Chiarito SGML/XML, user interface, i18n Amiga Inc.
[EMAIL PROTECTED] http://amiga.com/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
