AmigaOS 3.2 released!

[mfilos]

Originally Posted by EctoOne

I've noticed the jumping cursor as well and was curious if MagicMenu was causing this for me as well. I just tried a fresh installation where I re-added my settings file by file and for now I can't seem to reproduce this. This is so weird. Sadly I don't have a backup of the system where the issue happened so I can't see if removing MagicMenu actually helps.

It certainly does cause you can try it easily if you enter the Failsafe startup from Early Startup Menu...
Just start it, and run manually MagicMenu from your disk and voila... jumping cursor :P

[EctoOne]

Originally Posted by mfilos

It certainly does cause you can try it easily if you enter the Failsafe startup from Early Startup Menu...
Just start it, and run manually MagicMenu from your disk and voila... jumping cursor :P

Um no. It's not happening for me when I try it. Maybe it's a certain MagicMenu setting that's causing it? I've deleted my settings and still didn't get it. I don't think I've changed anything major between the installation where I had issues and the current one.

Edit: Well, the issue returned...

[Thomas Richter]

Originally Posted by kamelito

It is just a question don’t need to take it personally. MagicMenu do the job.

No, it does not, because it cannot. MagicMenu can, due to the way of how intuition operates, not possibly work correctly.

Originally Posted by kamelito

Olsen worked on MagicMenu so I guess it is good enough for me.

If a crashing or haning system is good enough for you... Again, it's not Olaf's fault (or anyone's fault) that MagicMenu cannot work. It is a very general problem neither you (nor Olaf, nor myself) can solve from outside intuition. The intuition even system does not allow interaction from tools from outside intuition. No matter how much you like it, it is broken by design.

[EctoOne]

Does that mean there is no good way to get at least a one click to show the menu? I could live without popup menus but I since I mostly do stuff on my android tablet, I can't hold RMB because it causes uae4arm to open its GUI.

I just tried ClickToMenu and StickyRMB and both work worse than MagicMenu.

[ShK]

If you're going to improve RMB behavior, please remove block for intuition tasks to access the same screen where menu is drawn on, that the screen can kept updated also while mouse button is pressed.

[mfilos]

Ok I found out that the issue with TextEdit is created if you select the "Sticky Mouse Button" under "Usage" option.
I reverted to "Intuition compatible" and problem doesn't exists!

I can live with that until we have it embedded in the OS. Cursor jumping in TextEdit (that I use a lot) is more annoying than having to hold RMB on Pull-Down-Menus.
On Pop-Up-Menu I still used the Sticky option :P

[Olaf Barthel]

Originally Posted by kamelito

Why don’t you provide the OS with functionalities like MagicMenu?

This is really tough going. MagicMenu duplicates functionality which is already present in Intuition, and because MagicMenu was developed with public information on how Intuition works, there are gaps in the implementation which are not easily closed without opening up APIs or creating new ones.

This is what happened, sort of, for AmigaOS4 which integrated the MagicMenu functionality into Intuition. But then AmigaOS4 systems have a lot more memory to spare than the humble Amiga 600. Such constraints bite for AmigaOS 3.

We also still have our hands full reworking the ReAction classes and the tools which build upon them. They need the time which is currently devoted to them much more than MagicMenu does, which basically works and does not cause too much trouble during daily use.

That said, things can change. We are still a small group of developers. If there are more minds and hands at work, there might be progress in areas which are currently not a major focus.

[aros-sg]

Originally Posted by Thomas Richter

No, it does not, because it cannot. MagicMenu can, due to the way of how intuition operates, not possibly work correctly. If a crashing or haning system is good enough for you..

Regarding deadlock it's not worse/different than what for example Workbench does/needs to do during lasso selection or drag and drop (btw: does this hang too, if this p96 move mouse from one screen to other screen commodity is running and you drag an icon and move mouse over screen edge?).

"Such programs" (Workbench, MagicMenu) can detect deadlock (and actually do have code that does that) and abort operation if one is detected, which should resolve the hang. If it does not then problem may be because of how ~mainloop during dangerous state (~while layers are locked) maybe looks like:

DANGER_ON; // locklayers();
while(!done || !abort)
{
  if (deadlock_detected) break;
  do_stuff();
}
DANGER_OFF; // unlocklayers();

This relies on do_stuff() to not ever deadlock and if it does it's bad because the deadlock detection code is locked out, too. Maybe it's an RTG-only issue where some calls may end up needing certain (sem) locks which are normally (non-RTG) not there/needed. Like maybe screen switching (ScreenToFront) on RTG also locks out rendering functions which one typically (non-RTG) would expect to be safe calls inside that dangerous_loop in do_stuff().

In some other "such program" I did things differently. Deadlock detection was done in a separate task which just did that and nothing else. If it detected deadlock if aborted the operation in that same deadlock detection task (so task unlocking the layers is not the same as one who locked them, but that is no problem). And "do_stuff()" ran in inputhandler so in ~cooperation with "Intuition". If "it" ran, then Intuition didn't. And if "Intuition" ran, then "it" didn't.

[aros-sg]

Originally Posted by mfilos

Cursor jumping in TextEdit

This sounds like the text edit gadgetclass may doing something like this in GM_HANDLEINPUT:

If class == rawmouse
{
   if (code = NOBUTTON)
   {
       // mousemove;

   }
   else
   {
      // assume LMB mouse click.

   }

}

And MagicMenu maybe not filtering out the RMB click.

[Olaf Barthel]

Originally Posted by kamelito

It is just a question don’t need to take it personally. MagicMenu do the job. The community have always improved the OS and some of those improvements have been added to the OS. For example one of my dirty hack removed the border around the icons because I didn’t like that back in the day. It has been copied by many and now it is part of the OS.
Olsen worked on MagicMenu so I guess it is good enough for me.

Martin Korndörfer created MagicMenu. I took over development duties around 1998, if I remember correctly. I used it daily and thought that I might be able to make it more stable. By then I knew a thing or two about Intuition and what not to do if you want to avoid deadlocking its state machine, or cause conflicts with layer locking. Those were the days, with bug fixes and frequent releases. But by 2002 I had run out of rope to hang myself with, and the AmigaOS4 project was just about starting Stephan Rupprecht took over development and it eventually became an open source project.

[mfilos]

What I found out is that while putting "Intuition compatible" on Pull-Down Menu fixes the issue while keeping the "Sticky Mouse Button" on Pop-up Menu still doesn't produce any cursor jumping EVEN @ copy-pasting.
No worries case dismissed for now :P

[boemann]

Originally Posted by aros-sg

This sounds like the text edit gadgetclass may doing something like this in GM_HANDLEINPUT:

If class == rawmouse
{
   if (code = NOBUTTON)
   {
       // mousemove;

   }
   else
   {
      // assume LMB mouse click.

   }

}

.

No, and if it did then intuition menus would not work either:

                    case MENUDOWN:
                    case MENUUP:
                        result = GMR_REUSE;

[Thomas Richter]

Originally Posted by aros-sg

Regarding deadlock it's not worse/different than what for example Workbench does/needs to do during lasso selection or drag and drop.

It is a lot worse! When workbench draws a lasso, it only locks the layers of the screen and then renders into the bitmap of the screen. This is not problematic since no other semaphores are involved - it just goes to graphics. If the rastport contains no layer, nothing else is locked. If, however, MagicMenu is in place, it *needs* to call intuition functions while holding a lock, and that is causing a lot of trouble.


Thus, there is no need to "detect deadlocking" for the workbench - it cannot deadlock by design.


A deadlock with semaphores cannot be "worked around" by another task checking - it is a logical problem because the dependencies of the objects protected by the semaphores is not linear (or not a tree). If you "break" such a circle by (externally) releasing a semaphore, it means that you defeat the purpose of the semaphore.

Originally Posted by aros-sg

"Such programs" (Workbench, MagicMenu) can detect deadlock (and actually do have code that does that) and abort operation if one is detected, which should resolve the hang.

I would not know why (or where) workbench has such code. The "crawling ants" as such are safe. MagicMenu has such problem, but this is because its logic is not correct (or rather, cannot be correct). If something deadlocks, then this is because MagicMenu attempts to use intuition functions while holding some intuition locks - and the intuition even machine cannot proceed then. If you unlock from the outside, you break the promises the semaphore makes.

Originally Posted by aros-sg

If it does not then problem may be because of how ~mainloop during dangerous state (~while layers are locked) maybe looks like:

DANGER_ON; // locklayers();
while(!done || !abort)
{
  if (deadlock_detected) break;
  do_stuff();
}
DANGER_OFF; // unlocklayers();

Sorry, but this code makes no sense. The deadlock is not "in the loop", but in some functions called in the loop, e.g. some higher-level intuition function such as OpenWindow() (used to render the "menu"), and then the deadlock is within an ObtainSemaphore() (or similar) function. Thus, a task "deadlocks" because "task 1" first locks semaphore A, then B, while "task 2" holds semaphore B, and then attempts to get semaphore A. This surely cannot work, and such "deadly circles" can happen if the semaphore hiearchy is not clear (is not a tree) because you are calling some function that attempts to lock something (indirectly) while you are explicitly holding a lock.


You can check for "Locksmith" in Aminet as a debugging tool - it can help to find such conditions and print some debugging information if you are in a deadlock.

Originally Posted by aros-sg

In some other "such program" I did things differently. Deadlock detection was done in a separate task which just did that and nothing else. If it detected deadlock if aborted the operation in that same deadlock detection task (so task unlocking the layers is not the same as one who locked them, but that is no problem). And "do_stuff()" ran in inputhandler so in ~cooperation with "Intuition". If "it" ran, then Intuition didn't. And if "Intuition" ran, then "it" didn't.

I'm sorry, but that is all pretty improper handling - "deadlock detection" is solving the problem from the wrong end. Actually, it is not solving things at all. The right end is to understand the dependencies between the semaphores in first place and not calling functions under improper conditions. There are huge warning signs in the intuition API *what not to do* when holding an intuition lock, for example.


Unfortunately, there are many improper examples of programs that seem to give promises on things that just "cannot work" by playing havoc with the intuition system. "screennotify.library" is another prime example of something "broken by design" - this thing cannot work reliably. The right design is to use public screens.

[aros-sg]

Originally Posted by Thomas Richter

Thus, there is no need to "detect deadlocking" for the workbench - it cannot deadlock by design.

Wrong!

#include <intuition/intuitionbase.h>
#include <proto/exec.h>
#include <proto/intuition.h>
#include <proto/dos.h>

int main(void)
{
    Delay(5 * 50);
    MoveWindow(IntuitionBase->ActiveWindow, 5, 5);
}

Compile and run from a shell. Then quickly pick up an icon from a wb drawer window and keep dragging around. After short time you will see a short deadlock and then workbench aborting the drag & drop operation, resolving the deadlock situation.



Deadlock detection can be something as simple as checking if no intuitick intuimessage has arrived in the last second or so.

[aros-sg]

Originally Posted by Thomas Richter

It is a lot worse! When workbench draws a lasso, it only locks the layers of the screen and then renders into the bitmap of the screen. This is not problematic since no other semaphores are involved - it just goes to graphics. If the rastport contains no layer, nothing else is locked.

With "deadlock detection" I mean "dectect if Intuition=input.device is deadlocked" == blocked waiting for a sempahore (layer lock) that my task (wb, magicmenu) is currently holding, because Intuition may be trying to do something while I do my stuff (icon dragging, menu showing) which requires that lock (like window=layer operation).

Sorry, but this code makes no sense. The deadlock is not "in the loop", but in some functions called in the loop, e.g. some higher-level intuition function such as OpenWindow() (used to render the "menu")

MagicMenu would use windows for menu (rendering) only in non-blocking mode. And therefore in non-blocking mode it does not need LockLayers(). It's only in blocking mode that it neesd LockLayers(), but then will of course not use windows for menu (rendering).

What MagicMenu (in blocking mode) does while holding layerslock will be very similiar to what other programs like WB or other others libs/apps implementing drag&drop like MUI will do. Regarding gfx/intuition functions it calls.

[aros-sg]

Originally Posted by aros-sg

"dectect if Intuition=input.device is deadlocked"

So when talking about deadlock I do not necessarily only refer to the case where task1 = stuck in ObtainSem(sem1) while task2 = stuck in ObtainSem(sem2), but some situation where:

task1 (MagicMenu, wb) is still running, but it and the user is "stuck in a deadlocked situation" because it does not get anymore events (mouse move/press) which would allow it to progress, because task2 (input.device) is stuck waiting on a semaphore which task1 holds, but which task1 would normally give up only after the end of the operation (drag&drop, menu). And the end of the operation would normally (without "deadlock detection") never occure if no events come in.

[torturedutopian]

Hi everyone ! I hope this was not reported before :-)
I use 3.2.1 on my A1230 ATM (because it fails to boot with the 3.2.2 probably due to my custom 3.2.1 ROMs).

Did you people notice that when your rename a file while being in "list" mode, the whole files listing flickers for a few seconds ? (more or less probably depending on the machine speed & number of files)

Does not occur in icons view mode.

cheers

[mfilos]

Originally Posted by torturedutopian

Hi everyone ! I hope this was not reported before :-)
I use 3.2.1 on my A1230 ATM (because it fails to boot with the 3.2.2 probably due to my custom 3.2.1 ROMs).

I recommend updating. You can always keep your ROM and current Startup-Sequence (as 3.2.2 puts it's own default one, keeping a backup of yours under SYS:OLD/ drawer).
Also since you use a custom ROM you can edit Startup-Sequence and comment the lines from:
Version exec.library version 47 >NIL
until...
EndIf (right before SetPatch).

Originally Posted by torturedutopian

Did you people notice that when your rename a file while being in "list" mode, the whole files listing flickers for a few seconds ? (more or less probably depending on the machine speed & number of files)

I reproduced it as well. It's barely noticeable (at least on my Vampire) but it's more of an update filename flicker like crackto loading (lol). Nice find :P

[torturedutopian]

> I reproduced it as well. It's barely noticeable (at least on my Vampire) but it's more of an > update filename flicker like crackto loading (lol). Nice find :P

Thanks for reproducing it ! It can take 5-10 seconds on my A1230 on some directories

Also I noticed another issue (mentioned on another thread) : if you rename some very long files so that the appended .info cannot fit, you get no error message - the file is renamed but the old .info remains leading to a ghost entry.

[mfilos]

Have you tried raising the filename length in Workbench Prefs?