@pvanni Basically as i read, "::function" in c++ , mean to call function outside of any namespaces, so in our case i assume it call socket's one (imho done like this just to be 100 sure that socket's one are called). There just few sends in some classes in webcore, so they do it like this only for send() and not for recv() for example.
But now question is why it fail and why lengthSend = -1. Just like socket descriptor wrong or kind.
Which it's the value of socket after the curl_easy_getinfo call? All send that i can find in internet has the first parameter "int" but curl_easy_getinfo take a pointer to long, but it doesnt compile without an explicit cast, so probabily I havent found the right send() over the net. From the libcurl documentation if I understand right curl_easy_getinfo return CURLE_OK if the call was successful but socket can be -1 if it's no longer valid
He was the first person to make a usable port of the WebKit engine on any Amiga-like platform, which was no small feat considering the size & complexity of the source code.
No, he wasn't... Marcik brought WebKit to an amiga-like platform years before that, and with a usable GUI, too. And it was much more work at that time, because there weren't SDL or Cairo backends that made WebKit so easy to port.
@kas1e
I won't even comment on Joerg's nonsense about malware and naming. You can rename if you want, but you're on your own if you have issues later with software depending on that, because i'll keep OWB on my side.
And about your actual issue, it's rather suspicious send() fails if connect() really succeeded. All this happens in main thread context, so unless the socket was already closed before or that the socket descriptor value got changed, i fail to see how it could happen. Maybe your CURL port has an impact on that somehow, though, to be checked.
Anyway, you can askJoerg now, i'm sure he will help. :) But just for your information, since June 2010 (i.e the WebKit revision OWB Reaction is based on), WebKit got more than 100000 revisions. There were *many* API changes in backends as well.
Maybe your CURL port has an impact on that somehow, though, to be checked.
All i do with curl port, its only add to it changes realted to URI you send me years ago (that file.c), and to make threaded resolver works add for each get_host_byname opening of new instanse of bsdsocket.library. And that change related to ssl cert to have PROGDIR: for. And that all.
But as i say, curl binary which i build from that library, works fine with websockets.
Quote:
And about your actual issue, it's rather suspicious send() fails if connect() really succeeded. All this happens in main thread context, so unless the socket was already closed before or that the socket descriptor value got changed, i fail to see how it could happen. Maybe your CURL port has an impact on that somehow, though, to be checked.
Yes, its clear now that send() fail, and seems because of "bad socket".
I go further and add more debug, my current whole platformsend():
int SocketStreamHandle::platformSend(const char* data, int length)
{
D(kprintf("platformSend %p\n", this));
LOG(Network, "SocketStreamHandle %p platformSend", this);
if (!m_curlHandle)
return 0;
RefPtr<SocketStreamHandle> protect(this);
long socket;
D(kprintf("platformSend socket before curl_easy_getinfo = %08x\n", socket));
D(kprintf("platformSend data before curl_easy_getinfo = [%s]\n", data));
CURLcode result = curl_easy_getinfo(m_curlHandle, CURLINFO_LASTSOCKET, &socket);
D(kprintf("platformSend socket after curl_easy_getinfo = %08x\n", socket));
D(kprintf("platformSend data after curl_easy_getinfo = [%s]\n", data));
D(kprintf("platformSend curl_easy_getinfo result ='%s'\n", curl_easy_strerror(result)));
So, as far as i can see, "data" ok before and after (so we pass it ok). Length is ok too. curl_easy_getinfo also says no error (but as google says: The curl_easy_getinfo processing for CURLINFO_LASTSOCKET returns the last socket without regard to its current status, so our socket can be closed already or kind).
And in end of all, with what we now its that socket is bugged. I.e. that one, to which we trying to send are wrong one. We connects , prepare everything to send, and then send just fail with "bad file number" which again can mean bad socket handle (or right one, just closed already by some reasons).
Its like error in the whole logic, and just looks like socket is closed somewhere somehow before. And curl_easy_getinfo didn't fail, as "socket without regard to its current status". And socket's handles also looks ok too.
@pvanni Quote:
From the libcurl documentation if I understand right curl_easy_getinfo return CURLE_OK if the call was successful but socket can be -1 if it's no longer valid
Google says that "The curl_easy_getinfo processing for CURLINFO_LASTSOCKET returns the last socket without regard to its current status", so socket can be bad already, just last one, curl_easy_getinfo didn't check if it open and still valid as i see
Edited by kas1e on 2014/2/25 11:47:54 Edited by kas1e on 2014/2/25 12:26:28 Edited by kas1e on 2014/2/25 12:27:57 Edited by kas1e on 2014/2/25 12:28:45
That "ThreadableWebSocketChannel" can't be something which trash socket (and so we need still to open there ISocket on os4 always for each call to this?)
@kas1e Unless the socket descriptor is trashed, the code probably calls newlib's send instead of the one from bsdsocket.library. You might want to call ISocket->send instead of ::send, just to make sure you are not calling the newlib one.
Unless the socket descriptor is trashed, the code probably calls newlib's send instead of the one from bsdsocket.library. You might want to call ISocket->send instead of ::send, just to make sure you are not calling the newlib one.
No, his bug is the other way round (using ISocket->send() instead of newlib send() because he is compiling with __USE_INLINE__), libcurl is using the C library sockets. The reason for the bug is the same as for 90% of the bugs in his builds: He is simply trying to compile MorphOS code with -D__USE_INLINE__ instead of porting Odyssey to AmigaOS. In this case for example #ifdef __morphos__/#endif is missing around #include proto/socket.h.
when he was very well paid for a pretty crappy browser.
I wasn't paid for the OWB port. If you think it was crappy you should have complained to sand-labs/pleyo, I always made it 100% clear that it's an AmigaOS port of OWB and that I wont implement a complete desktop browser around it. If you didn't like that you could have done something else yourself with it, it's open source and the AmigaOS parts were on the OWB SVN (unlike for example the AROS ones).
I think its just better if we just let past be the past here, it serves no one to start arguing about it again. I don't know who deserves a apology here, but many things where was said, that should not haven been said, and that I think include everyone including Joerg and Me.
I don't know if there is a lesson to be learned here or not, but maybe we should be more polite to word etch other, arguing about things, name calling and so on, never made things better.
@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
@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.
@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
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.
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:
All is fine here, however if you decide to close that drop menu, for example clicking on other area of the program
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:
--> 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 ..
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:
- 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 ..
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
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
