Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
123 user(s) are online (70 user(s) are browsing Forums)

Members: 0
Guests: 123

more...

Headlines

 
  Register To Post  

« 1 ... 14 15 16 (17) 18 19 20 ... 72 »
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
Quote:

Any ideas what it can be ?


No but AmiDock runs with WBrun (or at least OpenWorkbenchObject()) I think and shell obviously with shell

So check behaviour when starting with WBRun from shell / starting direct from workbench.

If it still doesn't crash from WBrun and WB then examine the differnces between the shell startup and workbench startup code.


Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
What i also notice now, that when that crash from shell on second run happens, and i ignore it (ignore dsi errors), then i have in serial:

newlib.library error: exit() of process 250 called from wrong process 0, using IExec->RemTask(NULL)


@Andy
Quote:

So check behaviour when starting with WBRun from shell / starting direct from workbench.


for "wbrun owb" from shell - no crashes (tried 5 times in row run/exit)
for dbl-click from WB - no crashes too , also tried 5 times run/exit
directly from shell - right on second run crashes

Quote:

If it still doesn't crash from WBrun and WB then examine the differnces between the shell startup and workbench startup code.


Strange why it start to happens only with 1.23, and not with previous ones, will check now maybe there something new changed

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
Likelihood of a weekend release?

AmigaOne X1000.
Radeon RX550

http://www.tinylife.org.uk/
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
At this moment you dind't close it, but just put it under the main owb window by making main owb window active (move it away, and you will see that this dropdown menu still here).


Ok 100% understand now, to solve that i just opened a new ticket in MUI4 asking for a specific enhancement request. Let's see if we can improve this!

See ticket 19

Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@kas1e

Probably your threading backend has an issue with the startup/end message handling. It might only appear now in 1,23 because more threads are involved (garbage collector thread, localstorage thread and, all the mediaplayer threads and so on...).

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@samo79

Quote:

Quote:


Quote:
At this moment you dind't close it, but just put it under the main owb window by making main owb window active (move it away, and you will see that this dropdown menu still here).


Ok 100% understand now, to solve that i just opened a new ticket in MUI4 asking for a specific enhancement request. Let's see if we can improve this!


The popup doesn't close the moment the url gadget becomes inactive. (As it does in Joergs OWB ) so you can end up withit behind the window if you do click to front (especially if you have ClickToFront set to a single click). Depth gadget will do that to. But as soon as you move the window the popudown list snaps back to it's correct position. This suggests the handler for that menu needs to listen to some more window events that just the movement related ones. Particularly depth changes.

Or Odyssey should be modified to close it if the url gadget becomes inactive (and the menu itself is not active).



Go to top
Re: Odyssey 1.23 progress
Quite a regular
Quite a regular


See User information
@kas1e

and if you disable the stack raiser ?

Quote:
#ifdef __amigaos4__
static const char * __attribute__((used)) stackcookie = "$STACK: 2000000";
#endif


and try to run from shell? without and with manual stack command?

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:
What i also notice now, that when that crash from shell on second run happens, and i ignore it (ignore dsi errors), then i have in serial:

newlib.library error: exit() of process 250 called from wrong process 0, using IExec->RemTask(NULL)
Although anything you get after ignoring DSI errors is useless most of the time make sure you don't call exit() anywhere from a child process, it can only be used from the main process.

If there are any threads not started by pthreads but by dos.library make sure you ported the MorphOS code to AmigaOS, for example you have to add NP_Child, TRUE to the IDOS->CreateNewProcTags() tags and wait until all child processes completed before returning from main() or calling exit() in the parent, check the dos.library CreateNewProc() autodoc for example code on how to do that.

The main difference between running it from Workbench or using run in a shell and directly starting it in a shell is that in a shell it's using the shell process, after it quits the shell process is still there. With run/Workbench starting it again creates a new process. In the shell it's using the same shell process again - and if you are using dos.library processes and something is wrong in your code waiting for the childs there may still be child processes running of the old Odyssey when starting the new one ...

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
Quote:

and if you are using dos.library processes and something is wrong in your code waiting for the childs there may still be child processes running of the old Odyssey when starting the new one ...


I wondered about that possibility mysefl, using ranger should anable kas1e to chack if all Odysey processes has closed after program quit.


Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@tlosm

Quote:

@kas1e

and if you disable the stack raiser ?

Quote:
#ifdef __amigaos4__
static const char * __attribute__((used)) stackcookie = "$STACK: 2000000";
#endif

and try to run from shell? without and with manual stack command?

Re: Odyssey 1.23 progress



That's a pointless experiment. Less stack will never make a program work better, nore sdtack can alwatys be added with the stack command. Stack usage can be checked with Ranger.




Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@broadblues

Quote:
The popup doesn't close the moment the url gadget becomes inactive.


Just now Thore still working on it, he fixed the GUI lockup in case OWB will be uniconified, see comment:

https://muidev.de/ticket/19


Go to top
Re: Odyssey 1.23 progress
Quite a regular
Quite a regular


See User information
@broadblues

was i just a test, some times bug come from two side :P

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@tlosm
Such test is pointless 100%, more stack never (never-never) cause problems. Only when there is not enough stack.

@samo
Thore currently works on calltips class in that bz and 1.16 which you have don't use it. There indeed was some bug , but you ask in BZ not for that. What you ask in BZ its imho outside of mui, its how odyssey done. And, basically, and at least in 1.23, everything logic for me. You just type anythng for have dropdown menus of url-string or of quicksearch, and then, to get rid of it without hitting enter, you press on any area of odyssey (so it deactivates), but then :

1). if you move window, its back so you can see where you now
2). if you start to use another parts of odyssey (pressing buttons, typing urls, whatever) all previous drop down menus auto-closes , what is ok too.

In other words, imho, that BZ is not BZ , but at least Thore accidentally found bug in calltips class because of that which is good, but it not related to what you ask.

Because, you ask "i want windowses autocloses when i press outside of them". And that imho question to Fab, but for me even as it now is fine and good. Even if you don't know that its "deactivated", it make no problems for usage (at least on 1.23).

But to say more about need to note that at least calltips class (i.e. any auto-fill form dropdown menus) just "closes" when you press outside of window on main odyssey window, and not deactivates as url-history or as quick-search. What mean its again related to odyssey's code, not mui.


Edited by kas1e on 2014/2/27 5:30:29
Edited by kas1e on 2014/2/27 5:38:44
Edited by kas1e on 2014/2/27 5:43:03
Edited by kas1e on 2014/2/27 5:50:52
Edited by kas1e on 2014/2/27 6:01:00
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@Joerg
Quote:

make sure you don't call exit() anywhere from a child process, it can only be used from the main process.


Just do search in whole sources on "exit(" and on "exit;" : nothing like exit from process at end.

Quote:

If there are any threads not started by pthreads but by dos.library make sure you ported the MorphOS code to AmigaOS, for example you have to add NP_Child, TRUE to the IDOS->CreateNewProcTags() tags and wait until all child processes completed before returning from main() or calling exit() in the parent, check the dos.library CreateNewProc() autodoc for example code on how to do that.


Sure that what we do even few years ago in first port (without such rewrite nothing can works at all of course, we deal with it at first place when start worry about port).

Search for __amigaos4__ ifdef in those files:

That how threading done:

http://kas1e.mikendezign.com/temp/threading/BCThreadingMorphOS.cpp
http://kas1e.mikendezign.com/temp/threading/BCThreadingWTF.cpp

That how timing done:

http://kas1e.mikendezign.com/temp/thr ... /BCSharedTimerMorphOS.cpp

That how fresh mediaplayer code adapted (but that imho in no use for that bug, as we just run/quit odyssey, without going to youtube or anything):

http://kas1e.mikendezign.com/temp/thr ... aPlayerPrivateMorphOS.cpp

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:
Sure that what we do even few years ago in first port (without such rewrite nothing can works at all of course, we deal with it at first place when start worry about port).

Search for __amigaos4__ ifdef in those files:
NP_Child, TRUE is there for starting the child processes, but I don't see any code in the #ifdef __amigaos4__/#endif parts which waits in the parent process until the child processes completed. That might have to be done in main() instead anyway.

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:
@joerg
JavaScript yep, almost not have specific amiga code, but in Bal / webcore there pretty much of it (not a lot, but still). Instead of adding manually __use_inline__ everywhere i just make assumption from beginning (few years ago when we do first port) that better do everything for newlib , so it all will be the same, and deal later with such kind of bugs. In general there i think for now only 2 or 3 places where newlib usage make difference (clipboard hook usage about which we talk in mails, that websocket's thing and something else don't remember now).
The differences between newlib and the C library used on MorphOS are your smallest problem, and you are confirming what I wrote: You simply compile the MorphOS code and just hope that it works on AmigaOS as well, without even checking it, let alone porting it to AmigaOS. Only if something crashes or doesn’t work at all you check the MorphOS code and port it to AmigaOS, but for porting Odyssey to AmigaOS you have to check all OS functions calls and every single function argument to make sure it’s AmigaOS compatible and if not fix it.

Without using -D__USE_INLINE__ you’d at least be forced to look at the MorphOS/AmigaOS specific parts because of the compiler errors. Not everything is in the #?MorphOS.(cpp|h) files, and not everything is as obvious as missing NP_Child, TRUE in IDOS->CreateNewProc() and waiting for the child processes in the parent, the missing charsets (in the clipboard data, OC_WantedCodeSet, 106 in ILocal->OpenCatalog(), etc.), the MorphOS memory allocator you have to disable or replace (FastMalloc), or at least fix the most serious bugs in it, etc.
Not using -D__USE_INLINE__ doesn’t catch everything, for example data only parts like the wrong RawKey codes in the keyboard input, but most of it.

With your current try&error method it will take you several years to port Odyssey 1.23 completely to AmigaOS.

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:
http://kas1e.mikendezign.com/temp/thr ... /BCSharedTimerMorphOS.cpp
Why are you causing DSI exceptions (handled by the kernel, but all exceptions are very slow) by using
SysBase = *((struct ExecBase **) 4);

SysBase isn't even used anywhere in the function.

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:Are you sure the MorphOS NP_StartupMsg is 100% compatible to the AmigaOS NP_NotifyOnDeathMessage?
I don't know anything about current MorphOS versions, but StartupMsg sounds like the opposite of DeathMessage ...

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@joerg
Quote:

That might have to be done in main() instead anyway.

My current main.cpp:

http://kas1e.mikendezign.com/temp/threading/main.cpp

Quote:

the missing charsets (in the clipboard data, OC_WantedCodeSet, 106 in ILocal->OpenCatalog(),


my current clipboard.cpp:

http://kas1e.mikendezign.com/temp/threading/clipboard.cpp

Quote:

With your current try&error method it will take you several years to port Odyssey 1.23 completely to AmigaOS.


With that method we at least have 1.9 and 1.16 (with some bugs, yes, but even in that form it usable and better than nothing). Also by that "method" i port mui mplayer, vpdf (almost, need to fix small bug) and bunch of other small tools from morphos: and they all works. Sure, there can be bugs of course, but at least it not so incompatible between newlib/clib from os to os. Some parts sure, but its faster and easy way to have something for users _today_, not "we works on it, when its done" way. Of course i never-ever want to do all of this, if there left any aos4 devs who motivated enough to do browsers from scratch with modern core (so all that JS and co) to make it all native an fancy-fast looking/working, but as there none, then ppls like me who have only basic skills do it. Your one was really good, fast and stable, but lacking of gui kill it in end. But now its imho too late to make our new gui from scratch after odyssey in develop for years.

And now after fixing that one bug about crash in shell, its all will works pertty fine for end users already and will be much better than previous 1.16. Sure, everything can be done better, but as no one want to do it, then its me (who do not know programming) do it, sadly. And now its even late to make our guis on top of webkit, as Fab do it already with Odyssey. Doing the same again and spend years on it make no sense anymore, better to port it normally with help from everyone who still here :)


Quote:

Why are you causing DSI exceptions (handled by the kernel, but all exceptions are very slow) by using
SysBase = *((struct ExecBase **) 4);


I don't have any DSIs there for those ones (and i am on debug kernel with munge). Or you mean they invisibly ?


Quote:

Are you sure the MorphOS NP_StartupMsg is 100% compatible to the AmigaOS NP_NotifyOnDeathMessage?
I don't know anything about current MorphOS versions, but StartupMsg sounds like the opposite of DeathMessage ...


Not 100% sure, but when Fab explain us what it do, we understand that is it , and do it like this. At least for 1.9 and 1.16 it was fine enough.


Edited by kas1e on 2014/2/27 9:15:07
Edited by kas1e on 2014/2/27 9:22:49
Edited by kas1e on 2014/2/27 9:25:18
Edited by kas1e on 2014/2/27 9:30:00
Edited by kas1e on 2014/2/27 9:46:29
Edited by kas1e on 2014/2/27 9:48:48
Edited by kas1e on 2014/2/27 9:49:59
Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@kas1e

you wrote:
With that method we at least have 1.9 and 1.16 (with some bugs, yes, but even in that form it usable and better than nothing).


Yes you're right, i agree with you Roman ! But if it can do better it will be welcome, only a word: cooperation !

thanks to everyone who is contributing or who will contribute.


Sam 460EX, 2Gb Ram, Radeon R7 250, AmigaOS4.1 FE
A4000 PPC604@233, Mediator
A1200 PPC603@160, Mediator
uA1 G3@800, 512 Mb [sold]
Go to top

  Register To Post
« 1 ... 14 15 16 (17) 18 19 20 ... 72 »

 




Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project