@trixie

Excellent news, and thanks for taking this on! I suppose this will mean less frequent updates for your other stuff like Rave, but that's a small price to pay for new OS4 development.

@turbo41

Version 1.4 of the MouseDriver package also fixes my problem with the scroll wheel not working (see post #62). Thanks!

It would be great if the latest driver could also be uploaded to OS4Depot, as the version there is quite old.

@Tuvok

Thanks! I saw the older version of that package on OS4Depot, but didn't think to check Aminet for a newer one.

Unfortunately, per the source code the only change in the new version was to add support for another mouse; the Logitech driver is still from 2019, and is essentially identical to the xeromouse driver. I tried it anyway, but wasn't surprised when it didn't work any better than the xeromouse version.

At least someone seems to still be maintaining the drivers, so if I'm able to figure out how to make it work, there's a path to a new version.

For many years I've used the xeromouse driver with the A-Eon/Logitech mouse that came with my X1000 in order to get horizontal scrolling by tilting the scroll wheel. I don't use horizontal scrolling nearly as much as vertical, but it comes in handy sometimes.

Unfortunately, this driver no longer works correctly under Update 3. The basic mouse functions work fine -- movement and buttons, including the middle mouse button -- but the scroll wheel does nothing, and won't scroll vertically or horizontally (in developer terms, RAWMOUSE events work, but MOUSEWHEEL events do not).

The driver comes with source, so I may be able to add some debugging code to try and figure out where it's going wrong. Until then, I've had to remove the driver and go back to the OS4 HID driver. It only has vertical scrolling, but that's better than no scrolling at all.

Per the AmigaOS Documentation wiki:

Quote:
Edit: smf beat me to it by two minutes!

@Capehill

Quote:
As Profyler's author, I'm pleased to hear that. It's nice to get feedback on one's work, especially when people are finding it useful.

@ktadd

Quote:
I second that, especially with regard to VideoClipper. It has something of a learning curve, and when I first started to play with it I struggled to understand how to use it. Because of that I found it more frustrating than useful, and ended up setting it aside for some time.

I later took another shot at it, and with some more playing started to get a better feel for how it works and how to use it. At that point it started to become useful. Though I suspect I'm still making use of only a small portion of its capabilities, and that there may be better ways to do what I'm trying to do, if only I knew what they were.

Other potential users may have the same problem, and may not realize that VideoClipper can already do what they're asking for.

Quote:
The VideoClipper manual covers the individual controls reasonably well; for me the problem is understanding the high-level concepts behind what the program is doing (such as what actually happens when you create clips and then join them together).

The "usage" section of the manual could be enhanced to add more detail on how to perform some of the basic editing tasks that users might be attempting. Not at the level of detailing every button press, but more along the lines of describing the necessary steps (how to load the source video, what kind of edits can be made, how to create the clips and what can be done with them, etc.).

@nbache

Quote:
I second that as well. When I retired some years back I thought I'd have more Amiga time than before, but it hasn't worked out that way.

@redfox

Quote:
Some of the lines in jabirulo's post are really long, which causes the page to become very wide in IBrowse (note the scroll bar at the bottom). This in turn pushes most of the posts off to the right, which may be beyond the edge of your screen. Try scrolling the page to the right.

Newer browsers like Odyssey don't have this problem, as they put the listing in jabirulo's post in a separate text box where the long lines are wrapped; IBrowse doesn't do this.

@trixie

Quote:
It's the middle of summer and kind of quiet here, but I don't want you to think that no one's interested in your announcement. So I'll say, great news! Thank you for taking on this project, and I look forward to seeing what you come up with.

As you noted, you have plenty of ideas for new classes to create, and you're well suited to know what's feasible to do. But still, I'll toss out a couple of ideas I came up with:

1) A spreadsheet-like grid class that looks much like a multi-column listbrowser. But unlike a listbrowser, each cell is independent, and may be read, written, and configured without affecting any other cells.

2) A line chart and bar chart class (or two classes) to go along with Enhancer's pie chart class.

@kas1e

Quote:
One argument -- the one you're leaning towards -- is that it's a programmer's tool, and programmers are supposed to know what they're doing, so you should let them do what they want with it, even if it doesn't seem to make sense.

Another option -- one I'm kind of leaning towards -- would be to restrict the format specifiers to ones that make sense for the argument type. A string pointer, for instance, might be displayed as a hex (or even decimal) value or as a string, but not as a tag list. A decimal value might be displayed as decimal or as hex, but not as a string or a tag list. A tag list pointer could also be displayed as a hex value, but not as a string.

The downside of this approach is that the code would have to know what the type of every argument of every function is, so it would know which specifiers to allow. That's more work and larger code size, especially as more libraries are added.

Quote:
If you're using the option to snoop on one specific program then there's no real need to show the program's name, as you already know what program it is. But if you're not using that option, it seems like you'd want to see what program was making the call, otherwise you wouldn't know whether it was the program you're trying to debug, or some other program.

As far as the return value, it would be consistent to let you disable it with '-' if you're not interested, just as you can any of the arguments.

@kas1e

Quote:
I wrote my original comment back before you switched to IPC. Now that you're copying all the arguments anyway, you're right, it's no big deal to wait until the call returns so you can report the return code as well. Snork is getting better and better!

@Hans

Quote:
I think it's new that's important; new software (or hardware, but there's not much most of us can do about that) is what stirs interest. But new games are of interest mainly to gamers, new development tools are of interest mainly to developers, and so on, while a new version of the OS is of interest to everyone.

Since there's not much most of us can do about the OS either, I'll second the vote for more end-user software. Though development tools are also important, to make it easier to create new end-user software.

@trixie

Quote:
Does this mean we might see a new version of Rave this summer?

@kas1e

Quote:
I don't understand what was going wrong there. I can see strings disappearing after the patched call returns, since the calling program would be free to delete or modify them, and anything stack-based would of course go away. But it doesn't seem like that should happen if DebugPrintF() is called before the patch returns (assuming I'm correct that DebugPrintF() doesn't return until the entire string has been sent).

Quote:
Sounds like a plan. There are some functions that return 64-bit values too, if you get to the point of reporting on return codes.

@joerg

Quote:
To prevent that you have to call the original version of any patched function that's called from within the patch. That would also apply to CopyMem(), PutMsg(), etc. And of course DebugPrintF(), if you call that from the patch.

@kas1e

Quote:
I've been thinking about this, and since no one else has jumped in, here are my thoughts.

Typically, your current approach -- doing as little as possible in the patch, and postponing the formatting and output to Snork itself -- is the recommended way to handle such things. But I wonder if in this case your original approach -- doing everything, including the DebugPrintF(), in the patch -- isn't a better idea.

One drawback to the current approach is that logging the function call is asynchronous to the function call itself- by the time Snork gets the message and outputs the log, the call has already occurred. So if the call crashes due to a bad argument, the crash occurs before the call can be logged (and if the crash takes down the system, the log will never be written).

A bigger problem comes up when you start logging exec.library calls. I presume you allocate memory in the patch to hold all the copies of arguments, and memory allocation can break a Forbid() that might be in effect when Exec is called. It looks like that can be prevented by using the AVT_Wait, FALSE tag with AllocVecTags().

An even bigger problem is that some exec.library calls may be made from interrupts, and memory allocation can't be done from within an interrupt. (I'd guess that TypeOfMem() isn't safe to use from an interrupt, either.)

Calling DebugPrintF() from within the patch eliminates both of those problems, while also making the logging synchronous to the function calls. And there's no need to copy anything except strings (where you're also filtering out unprintable characters), and those could be buffered on the stack (though you're using the caller's stack, so you have to be careful how much you use).

As far as I'm aware, there's no public information on the internal workings of DebugPrintF(). But given its intended purpose, I'd speculate that it depends as little as possible on the rest of the system (and presumably is okay to use from within an interrupt), and likely writes directly to the serial port (in SERIAL mode) with no buffering, and so doesn't return until the entire string has been sent.

If this is in fact the case it will be slow (especially when logging a tag list), as it takes 87 us for every character written at 115.2 kbps (it should be much faster if writing to the debug buffer or if using Sashimi). But the advantages of doing it this way may outweigh the reduced speed.

@kas1e

Quote:
I think the idea behind using TypeOfMem() is to catch cases where the string pointer points to something that is not a valid RAM address, where trying to read the characters of the string will probably cause a DSI.

Of course, if the string pointer is invalid the function you're calling will probably cause a DSI itself as soon as you call it. Still, there's some value to Snork not causing the DSI, even if there's going to be one an instant later anyway.

If TypeOfMem() returns zero you can print the string pointer as a hex value, which lets the user see what value was passed and perhaps provides a clue as to what went wrong (assuming the ensuing crash doesn't take down the system).

@kas1e

Quote:
Thanks for implementing them!

Quote:
For dealing with buggy pointers to something that's not a NUL-delimited string, I was thinking of something simple, like limiting the length that's printed to something reasonable, so you won't potentially get thousands of random characters until it happens to encounter a NUL.

In addition, you could filter the string to turn unprintable characters into periods (or some other character), so you won't possibly print an escape code or control character that interferes with the display of the snooped data. That would require making a copy of the string, since you don't want to alter the original.

Quote:
Nice; I hadn't even thought of that one. Looking forward to the next update!

@kas1e

Sounds like a cool tool (love the name!). I like that you can decide which parameters of each function to snoop on, rather than having to see them all, whether you're interested in them or not.

Quote:
It would be nice to be able to see the return value from the patched calls, though that will be a bit more complex as you need to report twice, once before the call and once after.

It would also be nice if it showed the name of the program making the call like OS4 Snoopy does, so you can see which calls are made by the program being debugged (and once you can do that, the option to snoop only on a specified program would help filter out clutter from other programs).

A good deal of caution should be employed when displaying a string parameter. Since one of the uses of the program is debugging, you have to consider that in some cases string pointers may not be valid (illegal values other than NULL or -1), or may not point at a real NUL-terminated string.

Somewhere down the road a standalone GUI tool -- something like MPlayer-GUI -- could be created to build the script files and send them to Snork for processing. But that can wait until all the basics are working.

Quote:
Those would be my choices.

Quote:
I re-read this thread after it accidentally got bumped, and it started me thinking- since the A1222 seems to have newer versions of many system components than other editions of OS4, what version of exec.library does it have?