@ShInKurO

Quote:

If you want see context menus work on all MUI (included Zune) you have to pass to MUIA_ContextMenu the object menu itself, NOT true/false (as documentation says...)

Documentation just lack necessary info about, but , for mui4 (and even for mui3.8 as i understnd) TRUE/FALSE for contextmenu are works (and should works, just documentation lack it, while sources of mui have it). Its Zune should be updated in that terms, not code rewriten.

Last edited by kas1e on 15-Apr-2011 at 06:59 AM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e @Deniil715
Terrific!

_________________
SamFlex Complete 800Mhz System + AmigaOS 4.1 Update 4
Amiga 2000 DKB 2MB ChipRam GVP G-Force040 Picasso 2 OS3.9 BB2
AmigaCD 32

@kas1e

Nope, even on MUI3.8 you will have a crash (or better, you will not have a crash, only a memory leak of which you could notice with mungwall), and Zune just mimes this behaviour. Probably MUI4 just fix this behaviour, making documentation right...

@kas1e


Damn we need update 3 now! Hyperion please release this damn update!

_________________
ikir

@ShInKurO

Quote:

Probably MUI4 just fix this behaviour, making documentation right...

As far as i see in last 3-4 month of our worring with owb poritng, the whole mui are bad documented at all. And 3.8, and 3.9 and the same as 4. Expectually 4.0 : there are tons of new addons and fixes, but they just not explained in the docs right. Developers just improve functionality more and more, but docs stays still the same, they auto-updates only when some new function was added, but as usual just with:

Quote:

FUNCTION yet undocumented, please complain in mailinglist :)

And there are tons.

For making Zune the same as mui4 (or even for now as 3.9), still need to make all of this the same even without "right notes in documentation", its in end should be easy for developers to build mui4 apps for all the oses, without refering to "that was not documented in mui docs, so sorry, zune not support it". Better just have all the stuff in.


@ikir
Quote:

Damn we need update 3 now! Hyperion please release this damn update!

As i understand , we have for now :
- 1 month of waiting for classic release (i think no more, but can be more as usual)
- 1 month for chiliout and politic stuff inside of hyperion and realise that time to release update3.
- 1 month for beta-testing and preparing of update3 (or even 2 months).

In summary, i think 4-6 months more for update3. Sucky enough yep, but imho not faster.

And x1000 launches can imho increase that timeline as well :)

But if it will too long, then we can release some kind of half-working version for public mui in beetwen.

Last edited by kas1e on 15-Apr-2011 at 01:27 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Well, maybe you could try to negociate a separate update just for the MUI libs/classes. It's a relatively separate component, so it shouldn't be a big issue, in theory.

Anyway, not my decision here. :)

@kas1e

Quote:

Developers just improve functionality more and more, but docs stays still the same, they auto-updates only when some new function was added, but as usual just with: Quote: FUNCTION yet undocumented, please complain in mailinglist :) And there are tons.

This is just so damn lame!
I mean if you develop something internally you can be lazy about docs but for something like a public and well used API you just have to document.

Dudes who write comments like that and then don't fix it for years!!! suck!

I can understand why Hyperion didn't want anything to do with this ####. Or maybe when they asked to use it they actually had *requirements* on MUI (God forbid anyone having anything such on MUI...) which I'm sure noone would have accepted, being closed-source and shareware or whatever at the time.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Quote:

This is just so damn lame! I mean if you develop something internally you can be lazy about docs but for something like a public and well used API you just have to document.

Sure , but its just not the only MUI problem, but any other project :) Just mui indeed a bit ####ed by docs still ..

I think current mui4 developers not so bother about writing "very good autodocs", they just already busy enough with fixing bugs and adding features. But anyway, documentation should be done if some fucntion added, that true. And its also a bit "annoing" work (while all developers lazy :) ).

Quote:

I can understand why Hyperion didn't want anything to do with this ####. Or maybe when they asked to use it they actually had *requirements* on MUI (God forbid anyone having anything such on MUI...) which I'm sure noone would have accepted, being closed-source and shareware or whatever at the time.

Imho the same problems can be with any programms , and even i think in reaction we not have everything documented, and some docs for sure ####ed and have bugs. Its just lazyness and busy-routine work to write normal docs..

ps. found the guilty lines of freezes, will post soon more info about

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@ShInKurO

Quote:

Ahhhhhh marrano! :) If you want see context menus work on all MUI (included Zune) you have to pass to MUIA_ContextMenu the object menu itself, NOT true/false (as documentation says...). This object has to be created at OM_NEW method of your List/Group/whathever subclass even with default values for labels, then you will right set it into MUIM context menu method (I don't remember the right name) which is called when you open fist way context menu (you have to insert a flag to check if it was just right setted), then check what user has selected from another method. Of course, you have to do all these things into a subclass... :)

I know simply setting it to '1' doesn't work for anything but MUI4 and MUI3.9-upd3 but right now, we don't care

If you want to use MUI-OWB you will have to run MOS2+ or OS4.1.3+
Someone else will have to downgrade poor MUI-OWB even further to get it to MUI3.8/Zune standards. I will not be involved in anything like it

I can be an advisor, like Fab has been to us, but noting more.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@all

About freeze and what cause that:

MuiOWB (as and reaction owb) based on webkit , which are have inside tons of code and standarts (JS and others), and all of them (expectually JS) call/use all the time time()/date() calls, which, in our case with mui-owb was implemented by this function:

Quote:

long get_GMT_offset(void) { struct Locale *l = OpenLocale(NULL); LONG ret = 0; if(l) { ret = l->loc_GMTOffset * 60; return ret; }

Somebody can see that there is no "CloseLocale", but as it works fine on morphos we not think about it before.

Then after we comment whole code in the source file which containt that fucntion, and have no freeze, step by step we found that bug exactly in that fucntion.

So for first we add "CloseLocale" and prinfs, so it looks like this:
Quote:

long get_GMT_offset(void) { printf("we in the get_GMT_offset\n"); struct Locale *l = OpenLocale(NULL); LONG ret = 0; if(l) { ret = l->loc_GMTOffset * 60; CloseLocale(l); } printf("get_GMT_offset ret=%d\n",ret); return ret; }

The output for the few hours of usage, show always:

Quote:

get_GMT_offset ret = 1800

And no crashes at all.

Then i remove CloseLocale, but leave prinfs, and guilty #### found ! For the first 10 minuts, i have all the time output "1800" for ret. Then, right after 10 minuts (i.e. when we have freezes) , ret ####ed totally and i have:

Quote:

get_GMT_offset ret = -537716636

That is for sure very-very bad for "ret(-537716636)" , and after few second of ####ed return, we just freezes.

I talk with Fab about, and he say that on morphos it harmless.

So, that bug happens only on aos4.

Some of programmers can say now : YOU SHOULD CLOSE ALL THE STUFF AFER YOU OPEN IT AND STOP USE !!! Sure , maybe you should, but its not very necessary (in end, everything going through the loop in code, and should "refresh the count" ).

On morephos (as check in the locale.library) , OpenLibrary(NULL); allocate nothing, it just uses the libbase default locale when passing null. So for morphos its harmless, but on aos4 looks like not (its not cleary understanable where bug exactly), but all what is undersanabled, its that on some stage, after many-many OpenLocale calls, without closing, its ####ed , and crashes heavy.

The problems i see there 2:

1. first one , why (its all looks like some integer overflow or kind)

2. and second one, why crash NEVER give us normal stack trace, in 90%, and in other 10% of time when stack trace was given, it was always different, and always point on any fucntion, but not on get_GMT_offset();.

Sure, all should be closed, but still i think there is some bug in the os4 realisation of locale.library. Or maybe not bug, but just "done like this" and we need to be carefull, while on morphos its all already harmless.

It was a bit annoing bug, but we found the #### :)

ps. Explaining of "why it crashes with JS faster than without" - because JS use heavy all those time/date. Still , of course, reling on 10 minutes looks a bit out of logic for me .. but maybe some skilled os4 developer can explain the stuff.

Last edited by kas1e on 15-Apr-2011 at 02:52 PM.
Last edited by kas1e on 15-Apr-2011 at 02:51 PM.
Last edited by kas1e on 15-Apr-2011 at 02:22 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Well done, good to see that bug finally squashed.

_________________
If your nose runs and your feet smell, you're upside down.

@kas1e

Great and congrats ! Now you've found that nasty bug and if you can go around requirement of update3 you could release this OWB version !

Of course you close everything you have opened always (no matter what else).

Last edited by Tomppeli on 15-Apr-2011 at 04:53 PM.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@kas1e

@all

What kas1e said.

If OpenLocale increases some kind of opencount like OpenLibrary it may very well #### up when this 16-bit variable flips around to 65536->0.

I have now used MUI-OWB for about 34 minutes and this function has been called 250000 times already! Edit: Ok, 260000 after some pondering...

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

That looks like the kind of thing I would do at startup and cache the value, and then make the function just return the cached value... especially if its called as much as that.

_________________
Playstation Network ID: xeron6

@kas1e

So you open a resource hundreds of thousands of times without closing it after use and eventually the system falls over in an apparently random way? You are suprised by this?

I've no idea what locale.library does when you open it, perhaps it makes a local copy of the locale data, or something similar, consider then what might happen if you did that hundreds of thousands of time, without freeing up on exit. There may be other reasons. But the bottom line is as you siad in CAPS above, close what you open!

For comparison AWeb uses locale for the same function in it's javascript library. awebjs.aweblib dos an OpenLocale exactlty once on library init then closes it on expunge. The result is strored in a libarary global. I can guarantee you it never crashed because of locale.library (wish I could say that it never crashed full stop )

[edit]typos[/edit]

Last edited by broadblues on 15-Apr-2011 at 06:49 PM.
Last edited by broadblues on 15-Apr-2011 at 06:46 PM.
Last edited by broadblues on 15-Apr-2011 at 06:46 PM.
Last edited by broadblues on 15-Apr-2011 at 06:45 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Deniil715

I guess there is a mechanism to deallocate locale automatically when open count reaches zero. Applications using default locale will find only garbage there.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Just to be clear, all other OpenLocale() calls in OWB MUI are matched with CloseLocale(), by the way. This one is probably just a typo.

But as i said, when passing NULL to OpenLocale() in MorphOS, it returns libbase->defaultlocale or so, and thus is harmless for us, which is why it went unnoticed.
There's also some kind of OpenCnt, but it doesn't matter in that case.

@broadblues

Quote:

So you open a resource hundreds of thousands of times without closing it after use and eventually the system falls over in an apparently random way? You are suprised by this?

It was not his code. Such things are not easy to spot especially you have to know those functions from the experience. Not all functions have free/close call.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

It was not his code. Such things are not easy to spot especially you have to know those functions from the experience. Not all functions have free/close call.

Sure I don't 'blame' him for a mistake (or even Fab for his "typo") it's the logic that then claims a a bug in the library that is misued, that sparked my post.

Anyway it's good that the bug is found, well done for tracking it down.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad