smj wrote:
There, fixed that for you.
Thnak yuo. Mai typng iz awefull
SGI: Development
Dillo3 - Page 2
Thnak yuo. Mai typng iz awefull
Ha ha, you guys are
fawwwwny!
Looking at it some more tonight and I have to say I have no idea what the problem is. Maybe MIPSPro 7.4.4. can compile it? I'm using 7.4.3 so it seems a faint hope, but If anyone wants to give it a try, replace the msg.h that's in the lout subdirectory with this:
...and then type `make' - DISCLAIMER: this version of msg.h has only been hacked enough to get past the compiler's attempt to objectify findtext.cc, additional overloaded C++ functions will have to be added to accommodate the rest of the program. One slogging source code file at a time, right?
EDIT: Diddled around with msg.h a bit more and got findtext.cc to compile! Also iterator.cc (fixed version of msg.h is above) So, forging ahead. Will update more status when there's more status to update...
Looking at it some more tonight and I have to say I have no idea what the problem is. Maybe MIPSPro 7.4.4. can compile it? I'm using 7.4.3 so it seems a faint hope, but If anyone wants to give it a try, replace the msg.h that's in the lout subdirectory with this:
Code:
#ifndef __MSG_H__
#define __MSG_H__
#define prefs_show_msg 1
#if defined(__cplusplus) && defined (__sgi)
#include <iostream>
void _MSG () {}
void _MSG (char * str) {}
void _MSG_WARN () {}
void _MSG_ERR () {}
void MSG(char * str)
{
using std::cout;
using std::endl;
if (prefs_show_msg) {
cout << str << endl;
}
}
#else
#define _MSG(...)
#define _MSG_WARN(...)
#define _MSG_ERR(...)
#include <stdio.h>
/*
* You can disable any MSG* macro by adding the '_' prefix.
*/
#define D_STMT_START do
#define D_STMT_END while (0)
#define MSG(...) \
D_STMT_START { \
if (prefs_show_msg){ \
printf(__VA_ARGS__); \
fflush (stdout); \
} \
} D_STMT_END
#define MSG_WARN(...) \
D_STMT_START { \
if (prefs_show_msg) \
printf("** WARNING **: " __VA_ARGS__); \
} D_STMT_END
#define MSG_ERR(...) \
D_STMT_START { \
if (prefs_show_msg) \
printf("** ERROR **: " __VA_ARGS__); \
} D_STMT_END
#endif /* defined(__cplusplus) && defined (__sgi) */
#endif /* __MSG_H__ */
#define __MSG_H__
#define prefs_show_msg 1
#if defined(__cplusplus) && defined (__sgi)
#include <iostream>
void _MSG () {}
void _MSG (char * str) {}
void _MSG_WARN () {}
void _MSG_ERR () {}
void MSG(char * str)
{
using std::cout;
using std::endl;
if (prefs_show_msg) {
cout << str << endl;
}
}
#else
#define _MSG(...)
#define _MSG_WARN(...)
#define _MSG_ERR(...)
#include <stdio.h>
/*
* You can disable any MSG* macro by adding the '_' prefix.
*/
#define D_STMT_START do
#define D_STMT_END while (0)
#define MSG(...) \
D_STMT_START { \
if (prefs_show_msg){ \
printf(__VA_ARGS__); \
fflush (stdout); \
} \
} D_STMT_END
#define MSG_WARN(...) \
D_STMT_START { \
if (prefs_show_msg) \
printf("** WARNING **: " __VA_ARGS__); \
} D_STMT_END
#define MSG_ERR(...) \
D_STMT_START { \
if (prefs_show_msg) \
printf("** ERROR **: " __VA_ARGS__); \
} D_STMT_END
#endif /* defined(__cplusplus) && defined (__sgi) */
#endif /* __MSG_H__ */
...and then type `make' - DISCLAIMER: this version of msg.h has only been hacked enough to get past the compiler's attempt to objectify findtext.cc, additional overloaded C++ functions will have to be added to accommodate the rest of the program. One slogging source code file at a time, right?
EDIT: Diddled around with msg.h a bit more and got findtext.cc to compile! Also iterator.cc (fixed version of msg.h is above) So, forging ahead. Will update more status when there's more status to update...
foetz wrote:vishnu wrote: Now hacking out the accursed variadic macros one by one
why? mipspro does support c99.
to be sure i just ran a quick test and used one from the gcc(!) examples - it worked
Certain headers (stdint.h, for example) are marked as 'C99-only', but only the MIPSpro C compiler supports C99. Try to include <stdint.h> in some C++ code and compiler with MIPSpro to see what I mean
GCC C++ allows C99 features in C++ code.
Now this is a deep dark secret, so everybody keep it quiet
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:
(2x)
In the museum : almost every MIPS/IRIX system.
Wanted : GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:
(2x)
In the museum : almost every MIPS/IRIX system.
Wanted : GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)
ah yes, i ran into that as well sometimes.
anyway i did a quick test build on osx (v3) and i couldn't see much of a difference compared to the one from nekoware. not sure it's worth the trouble unless the changes are more significant
anyway i did a quick test build on osx (v3) and i couldn't see much of a difference compared to the one from nekoware. not sure it's worth the trouble unless the changes are more significant
Biggie for me would be (limited) support for CSS. Neko Dillo doesn't support CSS at all I believe, whereas Dillo 3 does have basic support. And anything that improves rendering of pages without the speed penalties of modern browsers gets a thumbs-up from me!
Systems in use:
-
Lithium
: R14000 600MHz CPU, 4GB RAM, V10 Graphics, 36GB 15k HDD & 300GB 10k HDD, New/quiet fans, IRIX 6.5.30
-
Nitrogen
: R10000 195MHz CPU, 384MB RAM, SolidIMPACT Graphics, 36GB 15k HDD & 300GB 10k HDD, New/quiet fans, IRIX 6.5.22
Other systems in storage:
x 2,
x 2
-
Lithium
: R14000 600MHz CPU, 4GB RAM, V10 Graphics, 36GB 15k HDD & 300GB 10k HDD, New/quiet fans, IRIX 6.5.30
-
Nitrogen
: R10000 195MHz CPU, 384MB RAM, SolidIMPACT Graphics, 36GB 15k HDD & 300GB 10k HDD, New/quiet fans, IRIX 6.5.22
Other systems in storage:
x 2,
x 2
Trippynet wrote: Biggie for me would be (limited) support for CSS. Neko Dillo doesn't support CSS at all I believe, whereas Dillo 3 does have basic support. And anything that improves rendering of pages without the speed penalties of modern browsers gets a thumbs-up from me!
indeed you're right. i had a closer look again. seems last time i tried the wrong pages for testing
thumbs up from me as well then
Soon as I recover my system from my horribly broken attempt to upgrade from MIPSPro 7.4.3 to 7.4.4 I'm going to jump right back on this...
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...
Temporarily lost at sea...
Plan:
World domination! Or something...
great and thanks in advance already
If it wasn't for those cursed variadic macros it would have been done two years ago...
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...
Temporarily lost at sea...
Plan:
World domination! Or something...
I'm getting system header errors, could somebody kindly do me the favor of checking what version of /usr/include/inttypes.h you have? Mine says:
Module: inttypes.h
$Revision: 1.4 $
$Date: 1998/06/23 00:38:11 $
It's failing with:
va_list is defined in varargs.h but that won't compile either:
I'm wondering if my shiny new MIPSPro installation didn't come with a set of outdated system headers...
Module: inttypes.h
$Revision: 1.4 $
$Date: 1998/06/23 00:38:11 $
It's failing with:
Code: Select all
cc-1020 CC: ERROR File = /usr/include/inttypes.h, Line = 188
The identifier "va_list" is undefined.
va_list is defined in varargs.h but that won't compile either:
Code: Select all
cc-1047 CC: WARNING File = /usr/include/varargs.h, Line = 154
Macro "va_arg" (declared at line 126 of "/usr/include/stdarg.h") has an
incompatible redefinition.
# define va_arg(vp,mode) ((mode *)(void *)__VA_STACK_ARG(vp,mode))[-1]
I'm wondering if my shiny new MIPSPro installation didn't come with a set of outdated system headers...
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...
Temporarily lost at sea...
Plan:
World domination! Or something...
could it be that the dillo guys included varargs
and
stdarg?
either way inttypes should be included at some later point but i'll check mine just in case ...
either way inttypes should be included at some later point but i'll check mine just in case ...
foetz wrote: could it be that the dillo guys included varargs and stdarg?
either way inttypes should be included at some later point but i'll check mine just in case ...
They're including stdarg.h and inttypes.h but I don't see them including varargs.h anywhere.
This is weird, I can compile my own C code that includes inttypes.h, it doesn't complain about it at all, but the C++ compiler pukes all over it.
The C code is:
Code: Select all
#include <stdio.h>
#include <inttypes.h>
int main()
{
printf("sizeof uintmax_t is");
printf("%5d\n", sizeof(uintmax_t));
return 0;
}
The C++ code is:
Code: Select all
#include <iostream>
#include <inttypes.h>
int main()
{
using std::cout;
using std::endl;
cout << "size of uintmax_t is " << sizeof(uintmax_t) << endl;
return 0;
}
W, as they say, TF
EDIT: It compiles okay if you use cctype instead of inttypes.h, sooooooo, so much for that! I'll just change the dillo code to use cctype everywhere...
EDIT REDUX: Nope, that's not going to work because cctype doesn't define intptr_t, so I'm right back to square 1.
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...
Temporarily lost at sea...
Plan:
World domination! Or something...
vishnu wrote: I'm getting system header errors, could somebody kindly do me the favor of checking what version of /usr/include/inttypes.h you have? Mine says:
Module: inttypes.h
$Revision: 1.4 $
$Date: 1998/06/23 00:38:11 $
It's failing with:
Code: Select all
cc-1020 CC: ERROR File = /usr/include/inttypes.h, Line = 188
The identifier "va_list" is undefined.
va_list is defined in varargs.h but that won't compile either:
va_list is also defined in stdarg.h which is included by inttypes.h (at least on my system). So I'd suggest checking:
1) Does your version of inttypes.h actually include stdarg.h before any mention of va_list?
2) Does your version of stdarg.h have typedef char *va_list somewhere?
Sun SPARCstation 20, Blade 2500
HP C8000
In the inttypes.h on my system, stdarg.h is included on line 184 and va_list is first mentioned in line 188, which is completely fucked up since when I try to compile dillo's object.cc the error is:
Again leading me to believe my compiler installation is somehow borked...
Code: Select all
cc-1020 CC: ERROR File = /usr/include/inttypes.h, Line = 188
The identifier "va_list" is undefined.
extern int i_vfprintf ( FILE *stream, const char *format, va_list va );
Again leading me to believe my compiler installation is somehow borked...
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...
Temporarily lost at sea...
Plan:
World domination! Or something...
vishnu wrote: This is weird, I can compile my own C code that includes inttypes.h, it doesn't complain about it at all, but the C++ compiler pukes all over it.
The C code is:
...
The C++ code is:
...
i just tried both examples and i'm afraid your installation is indeed messed up. both examples compiled fine here.
my inttypes.h says:
Code: Select all
* Module: inttypes.h
* $Revision: 1.6 $
* $Date: 2002/09/10 02:57:20 $
seems like a reinstall of your dev stuff would be a good idea
foetz wrote:vishnu wrote: This is weird, I can compile my own C code that includes inttypes.h, it doesn't complain about it at all, but the C++ compiler pukes all over it.
The C code is:
...
The C++ code is:
...
i just tried both examples and i'm afraid your installation is indeed messed up. both examples compiled fine here.
my inttypes.h says:
Code: Select all
* Module: inttypes.h
* $Revision: 1.6 $
* $Date: 2002/09/10 02:57:20 $
seems like a reinstall of your dev stuff would be a good idea
Roger that, thanks foetz!
Time to start digging through my monumental pile of IRIX CD's again...
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...
Temporarily lost at sea...
Plan:
World domination! Or something...
Heads up: a new version of Dillo was released yesterday and one of the headlines is "fixed compilation on irix"
reco
195 MHz R10K, 512 MB RAM, CRM, OpenBSD
Plus a lot of other MIPS machines: 2x Lemote Yeeloong (loongson), Lemote Fuloong (loongson), Lemote 3A laptop (loongson), Portwell CAM-0100 (octeon), UBNT EdgeRouter LITE (octeon)
Yes, they included some mips pro related fixes for vishnu. It is and was easy to compile dillo3 with gcc on Irix. It compiles without any serious warnings, but the result doesn't work and I would be very surprised if this will be different with mips pro:ibara wrote: Heads up: a new version of Dillo was released yesterday and one of the headlines is "fixed compilation on irix"
dillo starts up without warnings and renders about:splash correctly. But if you want to follow any link you find out http doesn't work at all.
ftp works without problems.
files show up if the path is very short (less than 32 bytes). If you browse directories and you want to change from /tmp to /tmp/x for example. I changes to /x
I still have no idea what goes wrong here.
however it's nice to see that a software project do add non-linux stuff on their own at all
There was an interesting post on the Dillo-dev mailing list today. The PowerPC OS X guys have the same problem like us. There is hope that someone take care about this problem.