The collected works of diegel - Page 4

hamei wrote: Remove that old cruft from the configure script ! Irix, HP-UX, NeXT, all worthless old trash from before we were born ! Old coots know nothing !

We have to accept that we are legacy. If you don't drop support for old systems we still would deal with 64k memory bounderies. Compared with NeXT or HP-UX our situation is still quite comfortable.

foetz wrote: hmm, what's wrong with hp-ux?

Possibly I don't know the right source. Is there any freeware library for hp-ux comparable with nekochan?

hamei wrote:

nongrato wrote: If this package is installed, Thunderbird crashes ...

Once neko_sqlite3 is removed, Thunderbird functions normally again.

This happened with firefox, too. Firefox eventually built its own internal sqlite. Not sure exactly where the problem is but it's not exclusive to neko sqlite

The problem is fixed (linked with rpath) in the thunderbird and seamonkey versions in beta. I think it's a good idea to move these beta versions after more than two years to current. The problem is also fixed in all current versions of firefox.

First I would try to boot the system in single user mode.

Trippynet wrote: Only problem I've noticed with it so far is that the menus appear to be a bit screwed up. Any idea what could be causing this?

I'm still examining this problem, it only happens if you are using antialiased fonts. You can avoid it by enabling a theme in your dillorc. By default there is no dillorc in your .dillo directory. You can copy or edit the system dillorc file: /usr/nekoware/etc/dillo/dillorc.

I think it would be a good idea to make the subsilver2 theme the default.

There is an updated dillo package in beta now.

I was never happy with the current nekoware fontconfig, so I build a new one. I also updated libfreetype. For me the result works much better and faster than the current versions. Please test neko_fontconfig-2.8.0.tardist and neko_freetype2-2.4.12.tardist.

Thank you for testing. I would be nice if some more have a look at this, since it is a noticeable performance improvement for gtk2 tools like firefox3. I really like to see this packages in current.

hamei wrote: A long time ago there was a sort of general agreement that any gcc-built nekoware would show that in the title ... could we continue that ?

I can do so, what is the correct package name in this case? neko_fontconfig-2.8.0_gcc.tardist? We have to rename a lot of packages then.

gtk2 performance depends much on cairo. I made some tests with different cairo versions and cairo 1.8.8 seems to be the fastest cairo version that works on Irix. A downgrade from nekoware current 1.10.2 works without problem for me. I build a highly optimized version with Mips Pro. If you are interested in this you can download it here: ftp://3b1.de/diegel/neko_cairo-1.8.8.tardist

If you use this cairo version with firefox3 you may delete libcairo.so.3 in /usr/nekoware/lib/firefox-3.0.19. I had to install an older cairo lib in this directory, because firefox3 is not compatible with cairo 1.10.2 in nekoware current.

foetz wrote: oh nice, you switched to mipspro now

In this case mipspro is significantly faster than gcc.

nekonoko wrote: Yeah, I'm pretty sure neko_gcc has that library statically linked so people won't run into situations like this.

This is correct for gcc 4.7 but not for gcc 3.4. Installing neko_gcc-3.4.6 and set a proper library path should fix the problem.

gijoe77 wrote: I just double checked and I have neko_gcc-3.4.6 installed

Sorry I was wrong. I was sure I had this problem in the past, but possibly I see the missing library problem during a build process. In this case I guess it is a tgcware gcc he was using. You can find tgcware packages at http://jupiterrise.com/tgcware/irix6.2/stable/ tgcware is build for Irix 6.2, but it should run on 6.5 also. You can find a libstdc++ library in libstdcxx_7-4.3.3-1.tgc-irix6.2-mips3-tgcware.tardist for example.

Axatax_ wrote: I didn't get no love for MAME here so I totally forgot about this thread...

Yes this is typically for the SGI community. You find a lot of threads about beta testing a lack of response in this forum. I think we would have a lot more ported software if the participants of this forums would help or simply give any feedback.

foetz wrote: either way if the package does conform to the nekoware guidelines and didn't show issues after some testing i see no reason not to declare it current. in doubt leave the previous version in place or move it somewhere else so no harm done. in fact imho nothing should be deleted. there's always the odd case where you need to go 2 versions back or something so for example an "archive" dir where all previous ones go would be a good idea i think

There is an archive. Nothing is deleted but moved to obsolete/archive. I benefit from the archive by examining patches and release notes from earlier ports.There are some packages in current that are ported by just commenting every code out that doesn't compile wit mipspro. In these cases earlier ports were made much better.

gijoe77 wrote: I was able to compile xmame v0.106 with gcc

Nice, thank you.

You get this type of error if you use -Ofast for optimization. In this case optimization takes place at linking stage and you need -IPA as a linker option. Often things are put together using libtool and I never figured out how you can use -IPA with libtool, also I never was able to link a shared library using -IPA. I would check for -Ofast in the make and config files and change it in -O3 .

These are my preferred mipspro optimization options:

gijoe77 wrote:

foetz wrote: don't unless you know what each of them does. you might want something else or have a different machine or a different compiler version etc.

best part of learning is falling down

Since we are talking about mame this should be no problem.

Code: Select all

OPT:Olimit=0:roundoff=3:alias=TYPED

kinda lost me to be honest

man opt and man inline will explain the options.

I did a rebuild of firefox and some depending packages with more optimization and disabling useless features. Just in case anyone is interested in this you can find it on my ftp server: ftp://3b1.de/diegel/fastfox/

If you install firefox you have to install also cairo, since firefox will not work with the current nekoware cairo version.

foetz wrote: i remember in the other thread you said this cairo was mipspro so how about the other one in that dir?

Cairo, gtk and xrender are mipspro the rest is gcc.

From the optimization will benefit R10000 ore better, on R5000 it may be worse and the firefox version does not run on R7000.

Added mipspro build pixman and pagno also a gcc build firefox-3.0.19pre with more useless features disabled and additional optimization.

Axatax_ wrote: Yeah, kinda, but it's *really* bad on SGI. I have a 200MHz PentiumPro sh*tbox with a Matrox Millennium I (remember that thing -- it pre-dates the incorporation of 3Dfx by three years...). This system will slap my 2x600 Octane left and right running GTK2 apps. Something doesn't compute with GTK2... Missing X extension or Intel-optimized SIMD?? Something 'aint right.

We don't have any support of antialiasing in our hardware, cairo and xrender have to calculate this on your main cpu. I am quite sure your Matrox Millennium can do this in hardware.

55cancri wrote: It feels like browsing is now much faster, I think twice as fast. I have an 400MHz V8 Octane and browse through ebay with 200 articles on screen. Well, my claims are not particulary high, but I never did that with the old firefox3, because that would have taken half an hour, or so

Thank you for testing.I am still surprised about the difference, I didn't change anything of the code, I just added some optimizing options to the compilers:

for gcc this option seems to make a difference:

for mipspro I am using the following options. The INLINE part makes it much better:

TeamBlackFox wrote: Speaking of FF, what are the roadblocks with the 3.5 series?

I spend some time working on firefox3.5 but I still have no idea whats going wrong.

updated:

neko_firefox-3.0.19pre.tardist
neko_fontconfig-2.8.0.tardist
neko_freetype2-2.4.12.tardist
neko_glib-2.28.8-11.tardist

ftp://3b1.de/diegel/fastfox

You can use g_vasprintf and g_strndup form glib.

eudatux23 wrote: Any idea how to do this? Is it enough to just change the words in the source code? I can try it this evening.

You have to include glib.h and change the source. The code is linked with glib already, so you don't need to change anything for linking.

TeamBlackFox wrote: I actually found the email CEO of the new SGI/Rackable Systems: Jorge.titinger@sgi.com .....

What do you want with the Irix source? We are not able to port a current firefox version to Irix , do you really think we have the skills to do serious kernel hacking? The open source community folks have the skills but I am sure this will end in another Linux distribution. I am very happy that we don't have a systemd discussion at this place.

alexott wrote: IRIX correlates more with *BSD than with Linux. So I expect *BSD folks to take over this. And there is nothing to afraid then, as they know how to do sane quality things.

Irix is Unix System Vr4 and that was the opposite of BSD in the past.

An updated libXft-2.3.2 is in beta now. It is a mipspro build. If you have installed the previous build please update, the former package is faulty.

Both packages in beta are replaced by faster builds with more optimization now. They are gcc 4.7 build since both packages run not stable with mipspro -O3 optimization.

duck wrote: Is this a known problem? I just upgraded from some previous non-optimized build of firefox 3.0.19 and got this:

Code: Select all

Removing orphaned directories
neko_firefox3.sw.eoe: ( if test -r $rbase/usr/lib/filetype/Makefile ; then chroot $rbase /sbin/sh -c "cd /usr/lib/filetype ; make -u > /dev/null" )
/bin/sh: syntax error at line 1 : `)' unexpected
ERROR: Command "( if test -r $rbase/usr/lib/filetype/Makefile ; then chroot $rbase /sbin/sh -c "cd /usr/lib/filetype ; make -u > /dev/null" )" failed (return status 2, subsystem neko_firefox3.sw.eoe 4)


This is the script to run the filetype makefile. It's only used for the icons. I don't see the problem here but I will check this.

mapesdhs wrote: Btw, what's the difference between the pre and non-pre files? And is one better off using
the slightly newer glib? (which I'm assuming is built with MIPS Pro instead of gcc?)

I removed the non pre build now. The pre build is the faster one. You can use the glib of your choice gcc or mipspro. I will upload the packages to nekoware beta after I checked every package again.

ClassicHasClass wrote: I'd still like to take a shot at 3.6, at least, but my time is being consumed by TenFourFox (which has higher priority) and my Master's degree (which the job insists I finish). Perhaps I shall do this around the time my marriage to Scarlett Johansson is nigh.

I can prepare a firefox3.6 patch for you. The only thing you have to do is debugging.

Trippynet wrote: Slow on an old R10000, but sometimes slow is better than nothing

When I remember the 90th with Internet backbone capacities of 2 mbit or less and dialin modems with 33,6kbit/s, compared with that even a ff3 running on an old R10000 is fast. With today's technology everything is much faster of course, but is it also better? Some days ago I used the web without noscript and adblocker with a current system and I was shocked about poor performance and the amount of advertising, I love entering a time capsule by using my old computers.

foetz wrote: that's on diegel's ftp. although having a typo in the name

What is the typo?

Oskar45 wrote: :?:

No, I don't watch TV. Thats the reason why I have time to build Nekoware packages.

surrealdeal wrote: It seems like a scam to create something that has some plausible but undeliverable value in order to cheat investors out of their money and line the pockets of CEOs and friends while doing so.

I think you got it. In the past a statup was a starting business, but for today your description is much better.

TeamBlackFox wrote: On another note, neko_gcc47 doesn't want to play nice so I'll have to build it too >.>

What's wrong with neko_gcc47? It works without any problem here.