SGI: Development

ClassicHasClass wrote: That's actually a really good idea ...

Even a dumb pig can find an acorn once in a while

I have a bunch of html stuff, a lot from techpubs, that I use for docs locally. I just set dillo up to access that and it works nicely. Unfortunately a few pages don't render correctly but mostly it's good. Fast.

Buuuut ... this brings up my never-ending string of bitches again. The fonts for me are all screwed up. I can set the pages to 1.8 fontsize but the rest of dillo stays tiny. Now we have to go look at the fltk settings.

This is just WRONG. From the beginning the web was designed to be display-agnostic. You use points and the dpi setting to determine font sizes. You don't fuck around with these stupid-ass goddamned pixels. This ain't CGA and DOS 3. Jesus, can people figure out the BASICS, PLEASE ??!!

Yes, I'm yelling. About to blow an aneurism, even. After forty-five fucking years can't people even figure out the most elementary requirements ? Developers ! Go stand in the corner. Put on the dunce cap. I don't want to hear a word from you for the next fifteen minutes.

a quick update here although not a good one. dillo3 for 5.3 might not happen because it seems it requires pthreads

foetz wrote: a quick update here although not a good one. dillo3 for 5.3 might not happen because it seems it requires pthreads

I have found this reference to an MIT team possibly getting pthreads onto 5.2 and 5.3?

http://web.mit.edu/databases/mysql/mysq ... hreads/FAQ

(2.1) What platforms does proven's Pthreads run on?

Lot's! It should run on the following platforms; the i386 processor
running NetBSD-1.x, FreeBSD-2.x, BSDOS-2.0, Linux-1.2 and Linux-1.3;
the r2000 (DECstation) running Ultrix-4.2; the Sparc running NetBSD-1.x,
SunOS-4.1.3, Solaris-2.3, and Solaris-2.4; the alpha running OSF-2.3 and
OSF-3.x; the SGI running IRIX-5.2 ; and the HPPA running HP/UX-9.x.

I think these are the source files: https://stuff.mit.edu/afs/sipb/project/pthreads/

Some other files mention irix 5.x (e.g. https://stuff.mit.edu/afs/sipb/project/ ... iff-951012 )


I will do some more digging around to see if pthreads is real on 5.3 ???

Found pthreads for Irix 5.3 here:

https://stuff.mit.edu/afs/sipb/project/ ... ch/sgi_53/

https://stuff.mit.edu/afs/sipb/project/ ... gi_53/lib/

Will this do ?

Maybe. Maybe not.

That's a userspace implementation of pthreads, using setjmp/longjmp. It's a cool effort, but it's like multitasking in Windows 3.1. A proper threads implementation requires kernel support.

Also, IIRC, some things like per-thread signal masking and handling are not possible (I think, it's been a while).

IRIX has had it's own sproc() based threads since IRIX 3, but again this uses different concepts, and you can't mix it with IRIX pthreads in a single binary, nor can you implement a 100% compliant pthreads implementation using sproc primitives.

the current status on 5.3. tried gnu pth were accepted but there seems to be an issue with X itself:

foetz wrote: the current status on 5.3. tried gnu pth were accepted but there seems to be an issue with X itself:

Code: Select all

Process 18138 (dillo) started
paths: Cannot open file '//.dillo/dillorc': No such file or directory
paths: Cannot open file '/usr/local/etc/dillo/dillorc': No such file or directory
paths: Using internal defaults...
paths: Cannot open file '//.dillo/keysrc': No such file or directory
paths: Cannot open file '/usr/local/etc/dillo/keysrc': No such file or directory
paths: Using internal defaults...
paths: Cannot open file '//.dillo/domainrc': No such file or directory
paths: Cannot open file '/usr/local/etc/dillo/domainrc': No such file or directory
paths: Using internal defaults...
dillo_dns_init: Here we go! (not threaded)
Disabling cookies.
** WARNING **: preferred sans-serif font "DejaVu Sans" not found.
** WARNING **: preferred serif font "DejaVu Serif" not found.
** WARNING **: preferred monospace font "DejaVu Sans Mono" not found.
** WARNING **: preferred cursive font "URW Chancery L" not found.
** WARNING **: preferred fantasy font "DejaVu Sans" not found.
Process 18138 (dillo) stopped on signal SIGSEGV: Segmentation violation (default) [XimCompResetStatus:1127 ,0xf5d37e4]
Source (of imComp.c) not available for Process 18138
(dbx) where
>  0 XimCompResetStatus(0x1003bc7c, 0x0, 0x0, 0x230) ["imComp.c":1127, 0xf5d37e4]
1 _XimCompMbReset(0x1003bc7c, 0x0, 0x0, 0x230) ["imCompIc.c":94, 0xf5cf7a4]
2 XmbResetIC(0x1003bc7c, 0x0, 0x0, 0x230) ["ICWrap.c":437, 0xf56d8ec]
3 <stripped>() [<stripped>, 0x57e5b8]


Did you used g++ to compile it? If so could you recompile with -ggdb in $CFLAGS and get a backtrace from gdb?

vishnu wrote: Did you used g++ to compile it?

of course, no way the mips c++ 4.0 of 5.3 could deal with that

If so could you recompile with -ggdb in $CFLAGS and get a backtrace from gdb?

which might not help because the issues are part of X11 and i have no gdb either but the next thing on my list is running dillo through again with -g and maybe only -O2.

things take time in this case because i have to use an actual 5.3 for that and g++ is slow as hell

Well, the guys who know say if you're compiling for debugging to leave optimization off completely, because otherwise the code you're debugging isn't the code you compiled, the optimizer can change a lot...

vishnu wrote: Well, the guys who know say if you're compiling for debugging to leave optimization off completely, because otherwise the code you're debugging isn't the code you compiled, the optimizer can change a lot...

yup, unless it's something that doesn't occur without optimization so usually i go with -O2 first and if the result isn't helpful the next run is with -O0


EDIT: anyway -g without optimization didn't show any more so i assume the related files are system stuff

Can you get a backtrace with dbx?

vishnu wrote: Can you get a backtrace with dbx?

sure, i posted it already

Ha ha sorry I didn't read all the way to the bottom.

Anyway that's not a very good backtrace it's not showing the whole stack, or at least it should show what part of dillo calls X which eventually calls XmbResetIC, it looks like something is stripped that shouldn't be?

yeah the trace could be better and the stripped part is likely from irix