| Re: [hatari-devel] Recent Hatari change problems |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
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?
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.
But if it isn't, yes, some feedback doesn't hurt. Especially
when it isn't quite straight forward what the option does or
how it works.
VDI width & height is an example of this. There isn't space
in Hatari --help output to tell that width & height need to be
divisible by a resolution specific number, so it's good for user
to see what is the actual resolution that Hatari will use.
Like this:
VDI screen: request = 333x244@4, result = 320x240@4
User can also accidentally put option multiple times on
the command line, with different values, but only last of
them will be valid. That has happened few times to me when
copy pasting long command lines, and option output has helped
me to notice that issue.
[...]
I have to say that I'm normally rather annoyed if programs spam my
console window with debug messages unless I've told them to do so.
Btw. I just noticed that you had hidden also CPU core warnings
e.g. about things like illegal instructions. Why?
IMHO it's important information when something is failing, but user
is very unlikely to find out that he needs to add "--log-level debug"
to get Hatari now to tell about CPU related problems.
I think the average user of Hatari even does not know what an illegal
instruction message means - and in some cases these are also part of
the normal operation and not a problem. Analyzing the output of the CPU
core normally requires at least basic understanding of the 68k CPUs
already, so we really rather should not present that stuff to the
normal users by default.
User can mention those when he's reporting a problem with Hatari.
It makes our work easier.
I do agree that CPU core outputs a bit too much though, especially
as it happens always. :-)
Well, even if we decide that the "important" messages should be shown
by default, the main problem here is that the UAE core does not know
about log levels, or rather differences in importance of messages. It
just writes out all kind of messages with one function (write_log()), no
matter whether it's rather a debug message or rather a emulation-error
related message. So it's all-or-nothing for the messages here. I
consider most of the messages from the CPU core rather to be debug
messages, so mapping all of them to LOG_DEBUG sounds like the right
level to me here. But I might be convinced that we could also increase
the log level of these messages to LOG_INFO instead - if others think
that this is useful. Nicolas, Laurent, others on the list, what do you
think?
>
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.
(If these would run Hatari over network, feedback would need to go
over a network channel, but I don't see any point in doing that.
There are much better & secure ways to run thing over network,
like ssh, and it can be used together with hconsole & python-ui.)
[...]>>>> * "--fast-boot yes" when TOS memory detection isn't needed
* "--timer-d yes" when tests don't depend on timer-D interval
Tests run without TOS, so I'd also not expect any difference with
these.
Right, I forgot that.
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).
and for this test, you also need "--bios-intercept on" of course.
Thanks. I was mislead by things crashing after Gemdos_Boot()
when using "--trace gemdos". I forgot that "--tos none"
loads & executes the given program directly, so I won't
see Pexec() etc. when it's launched...
Without "--mousewarp off" option, Hatari centers the mouse to its
window on startup, even if one uses "SDL_AUDIODRIVER=dummy" and
"--disable-video yes".
[...]
Again, the tests are not run with a window (also not with
"--disable-video yes"), but with SDL_VIDEODRIVER=dummy. In this
mode, SDL simply ignores all UI related things, so mouse or
resolution changes simply do not matter.
Sorry, I must have typoed SDL_VIDEODRIVER=dummy somehow yesterday.
Everything works fine.
[...]
I think everything below 10kB is fine for inclusion into the Hatari
repository. I'm just a little bit afraid that with C code, people will
then be tempted to include binaries that have been compiled with GCC +
mintlib. And these are huge, e.g.:
$ echo 'main(){}' > tst.c
$ m68k-atari-mint-gcc tst.c -o tst.prg
$ ls -l tst.prg
-rwxrwxr-x. 1 thomas thomas 230901 14. Apr 15:17 tst.prg
$ m68k-atari-mint-strip tst.prg
$ ls -l tst.prg
-rwxrwxr-x. 1 thomas thomas 117730 14. Apr 15:17 tst.prg
The problem with C is the startup code - it can be very large
It's MiNTlib specific problem, all the unixy stuff makes things depend
on quite a lot of stuff. Startup code brings in printf which is large,
any file operation (maybe even isatty()) brings in timezone code etc.
However, there are other C-libs for gcc, and all the other compilers
have smaller C-libraries.
VBCC could be a bit too buggy (when I was testing it ~5 years ago,
I found even m68000 code generation bugs, but I'm sure Frank has
fixed those long time ago).
-> standardize on AHCC? It's pretty small.
and you don't know which OS functions it depends on
Not a problem. C startup code doesn't really change, and you find
out the OS functions just by tracing the program startup once.
- and we only have a very small amount of GEMDOS functions
available in the "--tos none" mode.
That is the problem.
Regarding the NatFeats tests...
* You could add something like "--run-vbls 5000" to make sure
the Hatari exits in case NatFeats for some reason didn't get
enabled. Or does CTest already have some timeout for tests?
The natfeats test already uses --run-vbls, see the run_test.sh script
there.
ctest also seems to have a "--test-timeout" option, but the man page
says that it is "internal only".
Any idea why?
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. :-/
* the nf_vbcc.tos binary in the repo is old build, it's missing
debugger invocation in the latest natfeats.c version.
Which would make it unsuitable for automation, as there's
currently no way to automatically continue emulation from
debugger, it requires user interaction.
I noticed that the binary does not quite match the C file anymore, so
at one point in time, we should indeed update it...
Debugger invokation is not a real problem, that happens in the xbios
Dbmsg test, too. We just have to feed some "c" characters into the
stdin of Hatari - see tests/xbios/run_test.sh for an example.
Ok, great! Debugger invocation is probably most second most
used NatFeats API after print one, so it's good to test it.
* 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.
C-lib startup code is fixed, so for AHCC it would be enough just
to implement the isatty() Fseek() support.
After this is decided, I can send you new binary.
(I don't currently have VBCC install, only AHCC and old GCC.)
- Eero
[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).