The work never stops

As you all know I been working on NoGuru (NoYellow), so I have been busy whit that for some time, but now I'm back on Excalibur.

I have been working on new menu editor as seen in right window, some work is needed, but its shaping up.

Left windows shows the new prefs program, as you can see I'm now using tabs, some was complained about size of old prefs window being too big.

On Excalibur (toolbar), the screen buttons has been rounded, and so has memory bar, the clock text as been centered, and I have also updated the virtual positioning.

Some at my job asked med create rounded corner on some buttons, as result I came up whit good idea for doing that, its not so often there is synergy between work and hobby.

 

An other project I have been working on, it has stuck on my hard drive for long time, is PublicPaint, I don't know if ever shown you this before, I don't know what to do with it yet..

But did some changes to the source code, so works tiny bit better.

As you can see from screenshot it needs a lot of love, I can't believe how tiny it all looks, most have been using smaller resolution back in 2002/2003.

It says in the about window SDL but its running directly on border less Workbench windows.

I hoping composition can help whit displaying preview graphics like brushes/cut outs, I did not have that when it was ported it to AmigaOS4.

To keep you computer girls updated.

Well to keep you computer girls updated on whats going on whit NoYellow, first of all I have been bit annoyed lately, about two things whit this project.

Comment from Broadblues on Amigaworld:

Quote: “imagine if you memlists are corrupted and another application can happily carry on accessing them, because of the lack of forbid? “

This has been worrying me I can't get it out of my mind, I use PutMsg() and it should be wrapped around a Permit() Forbid() according to the autodocs, I have not to prevent forbid being broken, and as some of you know Message list are based on struct list, and so struct list might get corrupted, I have been thinking about protecting the PutMsg() whit a Mutx instead, but I know if I do and its in a forbid the Mutex will never be

released by the other task, so I can't use any Semaphore or Mutex.

So I have started working on a workaround, a forbid free message que, that can't bring down your computer, its based on static table instead of dynamic list, so next previews pointers can't be in a incomplete state. this also means the buffer can be exhausted because it can only contain a limited number of records, resulting in some message not being displayed, don't worry all he error will be written to debug buffer using DebugPrintF (this is some thing I'm working on), how quickly the message que is emptyied depends on how fast I can display the messages.

 

The second issue that has been annoying me is how the Ringho messages look, so I have opened a tread at Amigans.net about that issue.

And it looks like the issue about not supporting line shift will be resolved in an upcoming OS update, to thanks Max Tretene of Acube System, for doing that, I'm shore there are many more developers that are interested getting that fixed.

Killing the Hydra

Every time you cut a head of a new one grows back.

Exec.library/Alert() was taken care of... but.... wait... what is that.....

its Initiation.library()/DisplayAlert... ha ha ha... says the Hydra.

Chop, chop, chop.

I have dreadful hydra head in my hand, oh no the poor thing does have head, lets replace it :-)

 Oh it looks better not so deagurs now are you, now that I can press your buttons :-)

The Guru has been taking in riddles again.

A few days ago I created a tool called NoYellow, it hack that is supposed to prevent the yellow guru mediation, from displaying, in the stone age when this guru meditations where created it was only Red Guru meditation, all crashes resulted back then in computer crash, in Workbench 2.0/AmigaOS2.0 or maybe later 3.0, the Yellow guru mediation was introduced, this was recoverable crash, well acutely many of the errors are not that critical as you might thing, many devices and libraries have there own error codes.

The left code is the error code, the right code is where application/task exists in memory.

During a Guru mediation the system is stopped including multitasking so you read the message, and then you just clicked away the error, but recent AmigaOS4.0 from 2004 introduced the USB standard a software driven protocol, now its no more possible click away the errors.

 The Guru has been taking in riddles again.

The Hex code of error message is not so understandable, you don't really know what happened unless you lookup the errors codes.

bits of hex error code is divided like this

msb

1 bit - Dead end massage

7 bit - General Error

16 bit - Sub system specific errors.

 lsb

  

But this not really true, some errors code have decide it was cool to mix General error bits whit Sub System specific errors bits, the result is that NoYellow V1.0 can print out many false positives, I'm working on improving this.

have also revived a few comments, about the project on OS4Depot.net.

@Chris

First of all a error requester can't be used because you never know what that state you got a Alert message, it might have been in a forbid, and you do not wont lots alerts you most click away, and sense there no built in error event log in AmigaOS, putting the messages there is not possible, ringhio pop up was next best ting, but also gave me a opportunity to experiment whit a new API, I have not used until now, cool thing about ringhio is that its displayed on all public screens.

@TSK

its more important for developers to understand the guru messages then users, note it does not privet a crash it only gets past the point of mouse click.