Odyssey 1.23 progress: r5 RC2

@kas1e
I tested Office Online under Outlook and Sharepoint too ...
On Morphos Odyssey 1.23 everything is working , but on AmigaOs 1.16 gave me an SSL error .
When possible check 1.23 under AmigaOs if this SSL issue come or everything goes right

@kas1e when get we a first beta?

@joerg
i do not know why you think that i use __USE_INLINE__ to "compile morphos code". you opinion only based on one (or it was two?) files which i send when we talk in mail (and which was work in progress), but you can be sure that use_inline used to avoid adding of iface names everywhere (a lot of all kind of code, include mediaplayer, gui, bal and co), and not for hope to have it "somehow compiles".


you even dont know how much work we put to port with Deniil and Thore. basically and of course it was mostly about gui (hooks, macroses, mui differences beetwen old 3.8 and 4.0) and -of.course- to make it all works it wasnt "recompile" as some may think. there is bunch of os4 ifdefs already where need it (threads, timers, etc).

just because i ask you in mail about new moment which was work in progress to port, you wrongly make assumption just we "just" recompile it: no. to make port we port it and change many parts for make it works on os4. you only see and heard about problems which we have now, but you dont about those which sorted and replaced for os4.

@tommy
once all bugs gone, then

@tlosm
i cant test now as not at home, but if it works on moss 1.23 it will on os4 port too (as you can seein thread problems with ssl in curl was sorted)

@bszili
yep, ISocket->send was first thing i tried when realise that send fail, but itseems it ad joerg says and it was wrongly already like that, but shouldnt. so if removing of "wrong" include will make another send be in use as joerg says, then that can be cool, will try tomorrow

@kas1e

If you wouldn't use -D__USE_INLINE__ the WebSockets, and maybe some other parts, would simply work and you wouldn't have had these problems. Without using the __USE_INLINE__ macros for obsolete AmigaOS 3.x style function calls 99% of the code (WebCore, JavaScriptCore, etc.) would still build without any changes, and for the rest you'd notice problems easier. Instead of using -D__USE_INLINE__ globally you could add
#ifdef __amigaos4__
#define __USE_INLINE__
#endif
as first lines in the AmigaOS specific parts, but only after checking that using the macros can't cause problems.

Of course that doesn't fix some some other things in the AmigaOS 4.1 version you have to port, like the missing charset in the clipboard functions, but in general it would make everything much easier for you.

@kas1e

Roman can you test a couple of things ?
I wonder to know if the same behaviour happen also on OWB 1.23 under MorphOS

- On the main GUI of Odyssey if you type somethings into the quick search area at some point a drop menu will be opened with some (hints) suggested words.

All is fine here, however if you decide to close that drop menu, for example clicking on other area of the program --> and then you iconify OWB --> when you reopen OWB that drop menu will be reopened automatically and it cannot be closed at 100% until you quit OWB ..

This behaviour is a bit annoying because the drop menu will steal the focus so after you have used it once, then if it will be "unintentionally" reopened you cannot click on the other areas ..

- The up/down arrow keys in side panels work as expected under Odyssey 1.23 (MorphOS) ?
On Odyssey 1.16 (AmigaOS4) still not, of course you can use the mouse wheel to scroll the area, but not the keyboard ..

I wonder if the same happen in MorphOS, or if they are a possible MUI4 issues under OS4

@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).

Anyway thanks for note about socket differences, it works!

@all






@samo

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).

Quote:

Because you didn't close it, but just make it inactive and be under the main window.

Only one way to close it, its hit enter in quick search field, or press that search gadget.

Its the same with URL search window for example: try to write something in when history will spawns, then dbl-click on main owb window: history window will looks like closed, but its not, its just under main window as you make it inactive.

A bit unusual, yep, i also found it strange when we make even first port, but i think its how mui itself works (its the same on morphos's mui too).



Quote:

That one in our mui4, and i already report it to internal os4 BZ when there wasn't muidev.de (so Thore aware, and says there no needs to make duplicate BZs), also i mark it as "in progress" on os4bugs.net

@tlosm

@kas1e

Hehehe we have again Microsoft software on workbench 8)

Super!

@kas1e

after Owb working i think one another great stuff will be have DnsCrypt on AmigaOs :) this two software together will be a great couple .


Plus today i found on aw an interesting post about youtube video is better i think you check this script on Owb 1.23 for more compatible youtube video play

http://userscripts.org/scripts/show/114002

@tlosm
Quote:
Not me, i have enough in pipeline :)

Quote:

You can check it yourself on morphos version, and see if it works.

@all
Another bug which found today:

If i run odyssey1.23 from amidock , then everything fine, i can close/run it as many times as i want, everything as should. No problems, no crashes.

But, if i run it from shell, and then just quit, and trying to run it again, then i have crash with such stack trace:

Stack trace:
(0x649AB950) native kernel module kernel+0x000200a0
(0x649AB980) native kernel module kernel+0x0002012c
(0x649AB9A0) _ZN3WTF19initializeThreadingEv()+0x3a4 (section 1 @ 0x17A9F30)
(0x649ABA10) _ZN3JSC19initializeThreadingEv()+0x64 (section 1 @ 0x150B12C)
(0x649ABA20) _ZL12handleOM_NEWP6IClassPmP5opSet()+0x134 (section 1 @ 0x95F8)
(0x649ABAE0) _ZL8dispatchP6IClassPmP4_Msg()+0x438 (section 1 @ 0xF554)
(0x649ABB20) native kernel module intuition.library.kmod+0x0001824c


While, our threading related changes are the same 1:1 as we do in 1.9 and in 1.16 (which didn't have such problem)

Stack_cookie of course set as before as well.

What is strange, why it didn't crashes at all from amidock (does not matter how many times i run/quit it), but when i do it from shell, then right on second run it crashes.

Any ideas what it can be ?

@kas1e

do you try to raise the stack to 200000 on shell?

if you open from "execute command" menu on the Wb top bar you have the same error?

@tlosm
Quote:

did mean stack ok (stack cookie is piece of code which you include to the program, which automatically set your stack on the value you need, without needs to enter it manually in shell). I.e. code have now:

Quote:

And if it was stack problem, it should't runs for first time too, but it only crashes on second run.

Quote:

Works fine too same as from amidock, but not from shell

@kas1e

Probably can be a bug of the shell and not of Owb or your fault , will better you report this on hyperion support.

@tlosm
1.9 and 1.16 didn't have those problems, only 1.23. Its 99% my fault somewhere.

@kas1e
If you 'RUN OWB/Odyssey' from shell does it crashes too?

Not sure, but maybe AmiDock runs dockies/tools on its ownAmiDock process/task, check it with Ranger.

Maybe some missing shell/cli start tag in OWB/Odyssey?

@jabirulo
"Run owb" from shell works fine too (tried 5 times to run/exit). Only when i just run it directly from shell as it: first run ok, then close, then second run crash. 100% reproducable.

"Run owb" from shell, "execute" from wb, run from amidock : all ok , can do it 10 times in row for test without problems, but just direct run from shell crashes on second run. All registers have all kind of different values (nothing like nulls, or feedface/abadcade/deadbeef), just a 80000003 dsi crash.

ignore DSIs skip error fine and load odyssey, so it should be something trivial or at least not _that_ hardcore.


Whole crashlog:

@kas1e

Typically crashes in sub process/tasks/threads when program quits are because the processes did not quit before the main program.

I don't know what code looks like, but its some thing you should investigate whit DebugPrintF or some thing.

Beside that I'm also thinking about the difference between starting a program from shell and wb, is that in one case you read wbstartup message, and the other you read the shell arguments.

Maybe some different in the initialization code, that comes back to haunt you at the end of the program.