@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
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).
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.
@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.
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.
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 ...
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
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 ?
This is exactly what Jörg wrote. Peeking at address 4 is in fact causing a DSI exception, but this is handled silently by the kernel. The point is that exceptions cause a major performance penalty, even if they don't become visible.
Peeking at address 4 must be supported, because this was documented to be valid since day zero of Amiga history. But there are lots of other ways to get a valid ExecBase address which don't require this kind of a big wooden hammer and hence don't cause any further performance penalty.
Please, better to understand why we need to replace it at all and not remove it :)
After talking with Thore in mail, suitable there is not have it at all as startup code already deal with. I also do search on all the os4codes i have, and on wiki/os4coding/hp forum, and no one assign Sysbase directly at all, everyone just have "extern struct ExecBase *SysBase;" and leave it to system to decide what is it.
Yes, this is suitable and the (IMHO) best solution.
We needed to replace it, because SysBase = *((struct ExecBase **) 4); does a zeropage access (from "user space"), which shouldn´t have been done at all...
Removing is impossible, because sometimes you need an anchor to access OS functions. On other systems this is done e.g. using an interrupt.
I don´t know why it is used in this part of code, but I don´t think that it´s done just for fun
“extern” does not make sense, this is what you use when, you want to tell the compiler that we have variable, but sense its a global, we can't declare it here. But its declared else where.
So drop the "extern", it does not make sense inside TimerFunc()
When you have more then one .o file, you can get linking error, saying the variable is declared more then once, this when you use “extern”.
besides, processes created by CreateNewProc, should call functions and it this agreements.
Removing is impossible, because sometimes you need an anchor to access OS functions. On other systems this is done e.g. using an interrupt.
Removing from os ? From odyssey we can remove it (i assume) because startup code already deal with SysBase, its always on the need it value, and no needs to set it at all for us.
Quote:
I don´t know why it is used in this part of code, but I don´t think that it´s done just for fun
Like i know it :) All i know that SysBase automatically initialized by the startup code, and there no needs for us to have that "SysBase = anything".
What i mean is that even if Fab put it here for reason, for us it not need it as startup code deal with it already.
@LveForIt
Yeah, already removed it all and already tested all is fine.
What i mean is that even if Fab put it here for reason, for us it not need it as startup code deal with it already.
Since it's not explicity referenced, the only reason must be allow exec.library calls, but that seems odd as if this is in the main code you allready have it set up (even in Morphos I would guess) perhaps it's just got coppied over from another project by accident?
If this were in a loadable module of somekind with no startup code then it would need to be followed by code obtaining IExec from it, but doesn't appear to be the case.
One way you can manage the process is by a counter.
Count up when process start, count down when process ends, so at end of program you can see if count is 0 or not, and you know if process has stoped, then maybe you should do a IDOS->Delay(5), to make shore they are really stooped.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
