Who's Online |
15 user(s) are online ( 9 user(s) are browsing Forums)
Members: 0
Guests: 15
more...
|
|
|
|
Re: Qt Native News
|
Posted on: 2010/11/8 14:08
#1361
|
Just can't stay away 
|
@kas1e Quote: Btw, did QtOpenGL module works in AmyCygnix setup ? Nope. I don't think there is opengl for Amicygnix available anywhere. I tried compiling it just for fun, but ran into naming conflicts with graphics.library (Layer and Region as I remember). A lot of Qt apps use the opengl module, so that is definetely high on my list to get it running.
|
|
|
|
Re: Qt Native News
|
Posted on: 2010/11/7 16:23
#1362
|
Just can't stay away 
|
@mausle
Well, theoretically it might be possible, it should be possible for qmake to handle any kind of host/target system. I'm probably not going to try, though, since my skills with Windoze/linux are very limited.
|
|
|
|
Re: Qt Native News
|
Posted on: 2010/11/7 14:47
#1363
|
Just can't stay away 
|
@kas1e Quote: Maybe still some help except testing we can do ?  For now just sit tight, and I will do an upload asap.
|
|
|
|
Re: Qt Native News
|
Posted on: 2010/11/7 13:43
#1364
|
Just can't stay away 
|
News: The event dispatcher in libQtCore is now running fully native with help gathered from the timer.device thread. Now all I need to do is sockets and processes, and I have a fully native Qt corelib.  Yay!
|
|
|
|
Re: Timer.device problem
|
Posted on: 2010/11/7 12:44
#1365
|
Just can't stay away 
|
@TSK & thomas Thanks guys, that's a lot of great info right there  . And sorry for being such a dumbass, these are still my very first steps with device programming. @TSK What exactly is the reason for using AllocSysObjectsTags intsead of CreateIORequest? Is it smth with the type of memory allocated or...?
|
|
|
|
Re: Timer.device problem
|
Posted on: 2010/11/6 17:39
#1366
|
Just can't stay away 
|
@salass00 Ahh... Thank you very much!  To justify my lack of knowledge, I can tell, that my source of information for the above code was "The programmers guide to the Amiga" from 1987...
|
|
|
|
Timer.device problem
|
Posted on: 2010/11/6 16:26
#1367
|
Just can't stay away 
|
Hey guys, what is wong with the following code?? I'm trying to make it wait for 10 seconds then print timeout and exit. Instead it just returns imidiately. Quote: #include <proto/exec.h> #include <devices/timer.h> #include <stdio.h>
int main (int argc, char **argv) { //open timer.device struct MsgPort *timerPort = IExec->CreatePort (NULL, 0L); uint32 timerSignalMask = (1 << timerPort->mp_SigBit); struct TimeRequest *timerRequest = (struct TimeRequest *) IExec->CreateIORequest (timerPort, sizeof (struct TimeRequest));
IExec->OpenDevice (TIMERNAME, UNIT_MICROHZ, (struct IORequest *)timerRequest, 0L);
//set timeval and start IO timerRequest->Time.Seconds = 10; timerRequest->Time.Microseconds = 0; IExec->SendIO ((struct IORequest *)timerRequest);
//await result IExec->WaitPort (timerPort); printf("timeout!\n");
//close timer.device IExec->CloseDevice ((struct IORequest *)timerRequest); IExec->DeleteIORequest ((struct IORequest *)timerRequest); IExec->DeletePort (timerPort);
return (0); }
Help! EDIT: I have tried with BeginIO and DoIO as well, same result.
|
|
|
|
Re: Qt Native News
|
Posted on: 2010/11/3 21:08
#1368
|
Just can't stay away 
|
@virgola Quote: (can you imagine going at the QT Developer Day showing off an Amiga?!?!?!?) Well, technically you can already do that with the Amicygnix port if you want  . @all Thanks for the encouragement 
|
|
|
|
Qt Native News
|
Posted on: 2010/11/3 18:25
#1369
|
Just can't stay away 
|
Here's the new repository: http://sourceforge.net/projects/qtamigaosnative/Current state of affairs is, that qmake has been built (completely native) and I'm working on the rest of the command line tools (moc etc). Once this is done, I will continue to try and do a completely native version of libQtCore.so with no amicygnix utils and no glib. This should be "fairly simple". Once all this is over, I can continue to the hard part, namely to do libQtGui.so. This is not going to be easy... All help and encouragement is welcome! 
|
|
|
|
Re: New Qt SVN repository
|
Posted on: 2010/10/30 16:39
#1370
|
Just can't stay away 
|
@gregthecanuck Quote: Is there anything in 4.7 that makes its port easier than 4.6.2? Nope, just more up to date.
|
|
|
|
Re: New Qt SVN repository
|
Posted on: 2010/10/29 16:03
#1371
|
Just can't stay away 
|
@DAX Yeah, I wonder also. But at least, I'm going to try  .
|
|
|
|
New Qt SVN repository
|
Posted on: 2010/10/29 12:58
#1372
|
Just can't stay away 
|
A new repository for Qt 4.6.2 under Amicygnix has been started: http://sourceforge.net/projects/qtamicygnix/Feel free to join in! Currently my plans are to try and start developing a truely native version of Qt based on the new version 4.7. This doesn't mean that the current repository is dead, though.
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/24 12:53
#1373
|
Just can't stay away 
|
@kas1e Could be possible. I'm a little tired right now, though, so maybe next week some time  Also, there are higher priority stuff like getting the typedef stuff to actually work correctly. It't pretty hard, since I have to invent everything from scratch.
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/23 17:31
#1374
|
Just can't stay away 
|
A fresh version of db101 has been uploaded. See original post.
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/10 15:23
#1375
|
Just can't stay away 
|
@kas1e
get_symbols() bug should be fixed now (see original post).
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/8 13:07
#1376
|
Just can't stay away 
|
@kas1e
I think I know what the problem is... I'll fix it as soon as I get back home!
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/7 13:18
#1377
|
Just can't stay away 
|
@kas1e Quote: Your three wishes have been resolved  . Hexview is now functional again, root path is recognized and you can de-attach yourself from a running task by simply exiting db101. Hope this helps. About your issue with AmiFig and SuperTuxKart I have no idea what is causing this. The relocation code is stolen from GDB, which means I don't really know how it is supposed to work. Also it is very strange, that you have section names like ".debug_smthsmth" and ".rela.debug_smthsmth"...?? This is definitely not stabs info, so what is it? About finding tasks in the process list, you are probably looking for a process named "Background CLI", since that seems to be the default name for cli processes started from the Workbench.
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/6 19:24
#1378
|
Just can't stay away 
|
A fresh version (0.8) of db101 has been uploaded. See original post.
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/6 19:23
#1379
|
Just can't stay away 
|
@kas1e Yes, what I _meant_ to say was this: Quote: gcc -gstabs <the whole project> -o myproject
...which is what my makefile is saying. I'm pretty sure it's a bug in the liner, anything else wouldn't make sense.
|
|
|
|
Re: DEbug 101
|
Posted on: 2010/10/6 17:05
#1380
|
Just can't stay away 
|
@kas1e & ssolie
-gstabs is already there, the problem is, that the linker leaves out any info from include files except for the very first file to be linked. Ot at least that's what I think is happening...
First I do this:
gcc -gstabs -S somefile.c
... and all the info is right there in place. Then I
gcc <the whole project> -o myproject
... and then I load myproject into db101. Then I print every stabstr there is, and all the include file data is now gone. Gone is therefore also any typedefs (and structures), that might occur inside one of the include files. This is nasty, and I sincerely hope, that someone can fix it...
|
|
|
|