Re: [hatari-devel] Recent Hatari change problems

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sun, 15 Apr 2018 02:27:52 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 04/14/2018 04:38 PM, Thomas Huth wrote:
> > Am Fri, 13 Apr 2018 01:43:42 +0300
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:  
> >> On 04/12/2018 01:05 PM, Thomas Huth wrote:  
> >>> On 11.04.2018 22:32, Eero Tamminen wrote:  
> >>>> On 04/11/2018 11:08 AM, Thomas Huth wrote:  
> >>>>> On 11.04.2018 01:23, Eero Tamminen wrote:  
> >> [...]
> >> What's the problem you're solving?  
> > 
> > See my other mail about "make test" - to be able to "diff" the
> > output of Hatari, I need a way to shut up all non-related
> > messages.  
> 
> If you're worried about messages (that you don't care about)
> changing and messing diffing, wouldn't better solution be
> a separate TEST log level, which would have a prefix you
> can match?

No, since for example the output of the Natfeats print function is
nothing you want to print out via a LOG_TEST log level.

> >> When user manually adds an option to Hatari command line, I
> >> consider it interaction, and it's very nice to get feedback for
> >> that.  
> > 
> > Sorry, but that's nuts. If you run "ls -l" on the command line, do
> > you also expect ls to print out something like "Running in long
> > listing format mode" ?? Certainly not.  
> 
> Not, because the "-l" option being used is immediately obvious
> from the "ls" output otherwise.

Well, maybe "ls -l" was the wrong example - but my point still stands,
every normal cli program does *not* tell you again what options you
selected. For example, GCC does not also not tell you again whether you
specified "-O3" or "-O2" etc.

> >> Same as with Debugger, interactive use of Hconsole requires
> >> feedback/acknowledgement on what user requests.  
> > 
> > That's bad design if this is really required here. If Hatari is
> > remote-controlled, > it e.g. can not even know whether stderr is
> > available for printing or not. If you really needed to pass a
> > result string to the calling program, it should be passed via the
> > same channel as the commands, i.e. via the control socket instead.  
> 
> In this context "remote-controlled" means "by other process",
> not "over network", so stderr works just fine.  Hconsole starts
> Hatari itself, so they both use the same console (same thing
> with python-UI).
> 
> The caller can redirect Hatari output if it wants to.  In the case
> of python-ui, it does this by setting Hatari debugger logging file
> to something else (not by redirecting stderr), but I think adding
> an option like that also for command line parsing would be overdoing
> it.

Ok, actually, I really don't care that much about hconsole and
python-ui, since I never use them. If you really think that Hatari
should spam the console here, feel free to change the last parameter of
the Opt_ParseParameters call in change.c so that it runs the option
parsing in verbose mode here again.

[...]
> >> Is that supposed to work now?  For example if I run:
> >>     ./src/hatari  --tos none  tests/xbios/xbiostst.prg
> >>
> >> Or anything else, only thing I get right away is double
> >> bus error & debugger halt.  
> > 
> > You also need to specify "-d tests/xbios/" to enable GEMDOS HD
> > emulation  
> 
> Nope.
> 
> 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.

> -> standardize on AHCC?  It's pretty small.  

Fine for me.

> > ctest also seems to have a "--test-timeout" option, but the man page
> > says that it is "internal only".  
> 
> Any idea why?

I apparently looked not far enough in the man page. There is also a
"--timout" option that can be used for ctest, and you can also specify
individual test timeouts in the CMakeLists.txt files, see:

https://stackoverflow.com/questions/45009595/how-to-overwrite-ctest-default-timeout-1500-in-cmakelists-txt

> If "--natfeats yes" or "--bios-intercept yes" is missing, current
> test programs crash to double bus error and --run-vbls doesn't help
> for that. :-/

Hmm, maybe we should add a check in Dialog_HaltDlg if run-vbls is
active or if SDL_VIDEODRIVER is set to dummy, and exit immediately in
this case?

> >> * Latest AHCC NatFeats build is about same size (<5KB). Compared
> >>     to VBCC build, it does at start several Fseek()s to special
> >>     conin, conout, aux, prn & bioscon handles, with successive
> >>     offsets of 0, 1 and 0. Not sure why.
> >>  
> >> -> Not sure whether I should update the binaries or not.  
> >>
> >> I guess TOS "none" could ignore all Fseek()s to special handles
> >> (0-3 and 0xFFFB-0xFFFF)?  
> > 
> > The cleaner way is maybe to rather provide our own startup code for
> > C, which just does an Mshrink and then immediately jumps to main().
> > That way we could produce real small binaries and can be sure that
> > no non-supported OS calls are being called by the startup code.  
> 
> I wouldn't want to maintain that for multiple [1] compilers /
> C-libraries, it could be subtly broken for some things that one
> might want to do with C.

The startup code would only be necessary if you compile a binary for
the "make test" regression test suite. If you compile a "normal"
binary (e.g. also with another C compiler than AHCC), you can use the
normal startup code of your C compiler.

So we only need to maintain a startup code for AHCC, and for the
well-known C code that we use for the regression tests. No need to
worry that this might break something in other programs.

> C-lib startup code is fixed, so for AHCC it would be enough just
> to implement the isatty() Fseek() support.

And if the next version of AHCC changes its startup code again and uses
additional GEMDOS calls? ... we'll always have to play GEMDOS call
whack-a-mole that way...

> [1] Remember that e.g. NatFeats test-code works also as example for
> Hatari users, so it's nice to support in that test-code main Atari
> compilers (gcc, vbcc, ahcc/pure-c).

Sure, but you don't need that special startup code for these.

 Thomas