Re: [hatari-devel] Recent Hatari change problems

[ Thread Index | Date Index | More Archives ]

On 19.04.2018 00:08, Eero Tamminen wrote:
> Hi,
> On 04/17/2018 09:33 AM, Thomas Huth wrote:
>> Am Tue, 17 Apr 2018 00:17:16 +0300
>> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
>>> On 04/16/2018 01:53 AM, Eero Tamminen wrote:
>>>> On 04/15/2018 12:33 PM, Thomas Huth wrote:
>>>>> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
>>> [...]
>>>>>> Giving a program to Hatari enables automatically GEMDOS HD
>>>>>> emulation for the directory where that program is (Hatari
>>>>>> autostarting would be pretty stupid feature without that).
>>>>> Not sure, but I think this automatic enablement is bypassed in
>>>>> "--tos none" mode since the program is not loaded by TOS, but by
>>>>> Hatari here.
>>>> Enabling is done in options.c, not TOS handling code.
>>>> (And I tested it, -d is not needed.)
>>> Sorry, my mistake, I was confused by my own GEMDOS tracing
>>> (I forgot that it enables GEMDOS emulation partially now).
>>> Is there some particular reason why your commit disabled
>>> GEMDOS HD enabling in options.c when giving program name
>>> after --tos none option:
>>> ?
>> It was simply not necessary. And for the buserror tester, I needed a
>> GEMDOS hd directory that is different from the PRG directory - since
>> this tester creates a file, and the file should not be put into the
>> source repository directory.
>> But we can change that - you're right, it'd be more consistent. But
>> then you likely have to adapt the tests/buserror/ script
>> accordingly, too.
> Logging needs additional changes too.
> I though it best to change all options.c logging to respect log
> levels, instead of logging being a flag for option parsing. See
> attached patch.

Bad idea. That way, all those "debug" log messages would show up during
normal program start again (with log level == info) and we're back to
where we started. So no, please don't do this.


Mail converted by MHonArc 2.6.19+