SGI: Development

Dillo 3.0.2, so far ...


Looks like just two errors so far but I amn't no C programmer

Huh! Weird. And that's with MipsPRO 7.4 presumably?

Just edit out the dots between the parenthesis in each of those locations in msg.h and it should compile. My SGI is 20 miles away but it just compiled (both ways, with dots and without) using Sun's Studio 11 compiler...

EDIT: here's all of msg.h without the dots, for your cutting and pasting convenience:

Yes, it is ...

One small step for man, one giant leap forward for mankind !

That works, thank you. I suppose there's a reason for that ?

On to the next hurdle ...


Doesn't this C thing have any standards whatsoever ? Tell you what, if I made a wheel that had a 14.5" rim just because I thought that was cool, a hell of a lot of people would be really pissed at me.

Good thing about standards is there is so many to choose from.

R.

I'd like to look at that but presently I'm stuck with Makefile errors in fltk-1.3.0, are you using the Nekoware fltk on your Fool? It's version 1.1.7 or somesuch. If that's what you're using and it will work with this version of Dillo I'll stop trying to fix fltk's broken Makefiles...

Dillo says it needs 1.3, so I just grabbed it and compiled. Went okay as long as I didn't enable shared libraries.


and awaaay we went ... --enable shared didn't get to first base.

Here's my enwironment, if that helps - it's pretty simple :

You must be using a different version of make than me. Mine is puking all over tabs versus spaces on the makefile in src. I cleaned up the first two errors, misplaced tabs, but am stumped at line 235. I'm not a make guru, but then no one should have to be, automake takes care of that but fltk stupidly doesn't use it. My version of make is, by doing `strings /sbin/make` - near the very end:



Yours is?

man cc:

* The gcc compiler allows variadic macros; the MIPSpro 7.4 compilers
support these macros in c99 mode. If you have code that uses
ellipses (...) as part of a macro definition and you are not
compiling with c99, you will need to rewrite the macro. Two possible
approaches are to replace the macro with a new variadic function, or
to create a family of macros, each taking different (fixed) numbers
of arguments.

@(#)$Header: IRIX 6.5:1289662620 built 07/20/06 at splat:/xlv41/6.5.30m/root $

Tell you what : I'll send you fltk, you send me dillo

This really shouldn't happen, you know. I can understand complex pieces of software not being easily portable but this is ridiculous.


Ah. Thank you, monsewer. We'll have to discuss proper use of Mme Guillotine one of these days, I have a few prospective clients . I assume (where is dc_v01 these days, anyhow ?) that this means I could change CC=cc to CC=c99 and it would compile clean ? Will go try that. Maybe t'would be better to do the rest of the source that way as well, just in case.

Here's one of my pet peeves, btw. I know people don't rtfm but these days, even finding the fine manual is a chore. Usually it doesn't exist. It's getting to be difficult to even find the dependency requirements. A lot of places seem to think that documentation means directions for installing binary packages on twelve varieties of Crapnix. It's getting to be quite annoying.

Anyway, anybody got an idear about the

?

C99 can compile C++ code?! Me doubts it...

fewel 2% gmake -ver

GNU Make 3.81

Just as I suspected; I'll have to install gmake.

A macro invocation has too many arguments.

I've not looked at that yet but it shouldn't be too tough. My guess though is that it's used all over the place and thus fixing it will be very tiresome...

Told you I didn't know what I'm doing I'm just doing grunt work, if some famous developers would step up to the plate I could restrict myself to giving lectures about how you idiots are shitting your own bed by sending all the middle class work overseas. But alas ... no rest for the wicked.


Yeah, all this stuff requires gmake. It's an easy fix tho, the gmake in nekoware works well. Then a simple setenv make gmake and you are ready for the brave new world of a thousand eyes, a thousand hands !


Cool ! A newer Dillo might be nice. In the meantime I've started using a proxy and blocking off dozens of googlead addresses and turning off javashit. It helps. Fireflop only crashes once in a while now.

btw, c99 did not fix the problem. Robespierre's citation is probaly accurate but in this case, not a solution. The guillotine part tho, I'm still willing to discuss

I installed nekoware gmake-3.81 and now have a bright shiny new fltk! I am just as happy as though I were in my right mind...

I'm looking at the second problem now, C++ was supposed to rid us of this type of macro nastiness, so I'll delete the macro and try reimplementing it with function overloading. But if it works it may only expose the next bad macro in a potentially unending chain...

EDIT: Just as I feared; dillo uses variadic macros throughout for message handling. The MIPSPro C compiler cranks through it just fine in c99 mode but the C++ compiler doesn't support c99 mode, for reasons that no doubt defy logical explanation...

C++ is pile of crap and the high-tech wizards bringing us this brave new world have the brains of a flea. What a bunch of incompetent morons. High-tech, a giant bowl of pigshit. This is ridiculous.

Indeed, gcc has supported variadic macros in C++ for darn near a decade, I suppose it must not be part of the standard or MIPSPro would have to support it as well.

As proof of principle I reimplemented the macros in css.cc and got it to compile. The first step is always the hardest, right? So doing it 50 more times should be a piece of cake...

A little research finds that Richy Babe is exactly the same as Billy G. Extend ! Embrace ! Exterminate !

Variadic macros were not part of the C++ standard until - 2011 ! By which time, as you say, they had been a gcc "extension" for over ten years. The next time some dork tells me to "just use gcc!" I'm going to punch them right in the mouth. I am well and truly sick of this shit.

Got wxwidgets to compile yesterday, grabbed a few sample apps to check it out. Out of ten, maybe three actually compiled ? The rest threw up error messages ranging from "An unsigned integer is being compared to zero" (even a non-programmer can tell THAT is a stupid idea) to "the function xxx has no corresponding operator "delete" to be called if an error is thrown during initialization of an allocated object". Seems sensible. Quality ? Quality, anybody ? Testing ? Proper coding ? What's that ? It compiles with gcc, it must be fine !

This entire software thing is pretty much a pile of crap. Very discouraging. When I find something that actually compiles and works well these days I am shocked and amazed. This is going to be the high-tech future of the United States ? Crappy software and even crappier javashit-laden ad-driven web pages selling "luxury brand" garbage - anybody looked at the Gucci crap recently ? shit made for $5 in Guangdong, selling in the US for $375 ? Or "social networking" sites suitable for thirteen year olds, this is high-tech ? If somebody doesn't wake up real fast, the US is in deep shit without a paddle.

wxwidgets has an html widget. Seems like a possible for a browser that doesn't crash every five minutes. Maybe. Hope your Dillo alterations go well, you're past my level now

The users of "social networking" are not the customers, they are the product. Same for most anything else on the internet nowadays.

Actually there's plenty else going wrong other than the macro replacements. I just mailed the dillo development list about one, which I will reproduce here just for funzies, line 557 in the nav.c file in the src directory:


(The caret is supposed to be under the word "Client" in a fixed-width font).

I greped around for a while and it looks to me like Client is a pointer. How gcc can get away with compiling this sh1t is a mystery...

Oh and for what it's worth I really like wxwidgets. I even bought the book. Someday I hope to actually learn it. Til then still hacking in the dreaded Motif...

The error "The expression must be a pointer to a complete object type." doesn't say that the expression is not a pointer. It says that the expression is not a pointer to a 'complete type'. I haven't looked at the code, but by guess would be that 'Client' is a class or structure that has been forward declared somewhere and never defined. As in:

This is legal, but when the body of 'foo' is defined, the final structure of 'Client' must be visible to the compiler. I would expect that what's happened here is that some combination of compiler flags, #defines or other shenanigans, that definition has gone AWOL in this particular port. Fixing the error will probably not mean a modification to the quoted code, but to the #includes or #defines in that file (or the Makefile).

This may be a naive suggestion, but couldn't you use a C99 cpp pass using -P and run CC on that?

"A thousand eyes, a thousand hands" ... did he really mean to say "ten thousand monkeys, ten thousand typewriters" ?

wxwidgets might be okay, vish. At least it compiled. I'm just a little disappointed that it isn't what I thought it was (and I dont really see the point of it, if it is what it looks to be.)