The collected works of dexter1 - Page 10

lynx wrote: Are you two building with sdl1 or 2?

We are using SDL1 : SDL 1.2.13 and 1.2.15 to be exact.

For more info see the Neko_gemrb.txt file which contains the steps and requirements needed to build our version. At the moment necron2600 has the most debugging performed (with BG1).

khalidschofield wrote: I second the command line Spotify client http://despotify.sourceforge.net/ . Or any other client is fine too. Really would love my music on irix

The only despotify audio subsystems which have IRIX support is libao and gstreamer and these are old ports, which is meh.

I think Josehill is indeed right:

Before entering nekoware perl CPAN shell, try to do this first:

This seems to work on my ChallengeS, at least installing a new CPAN. Khalid, can you test this?

[edit] before this, i added extra swap via a swap file, but that didn't help, Maybe the combination of vswap and adding extra swap did the trick. In order to test vswap without extra swap, i have to let CPAN go its course, which takes a rather long time.

Um, how big is your swap? I now have:

My Challenge S only has 192MB ram

[EDIT] i have vswap off to test if an 'install CPAN' fails. Takes a while... Result is inconclusive, but i happen to forget to enable vswap after the chkconfig. The correct command sequence should be:


I now have
More later...

I'm working on:

- neko_tcl 8.6.6 (compile and test done, needs mktime() patch and packaging)
- neko_openssl-1.0.2j (compile and test done, packaging now)
- neko_openssh-7.4p1 (compile done, regression test failed which need investigating)

When openssl is done i can start libffi and Python 2.7.13 and 3.5.2 which is my end goal before easter.

khalidschofield wrote: Ah openssl great! Mine appears to be broken

Well, if you're referring to the Perl CPAN IO::Socket::SSL build fail, the problem is that CPAN always finds the system openssl but not its headers, and if you install the headers for openssl (in openssl.sw.headers) they appear to have compiled kerberos with it but forgot to package krb5.h (nowhere to be seen in kerberos.sw.*) . Apparently this was a common bug in early 2005 with openssl packages.

But you can't uninstall system openssl right away since most need some sort of ssh access to their boxes and openssh is firmly linked with openssl versions, which is why we all need a new openssl/openssh combo from nekoware

I tried to research where perl finds his compile options for the CPAN stuff in order to attempt to sneak in /usr/nekoware paths. It's in config.pm in i think /usr/nekoware/lib/perl/5.24.0/irix-n32 but unfortunately some perlmonks say that hacking that file will not guarantee a proper build. And even my attempts were unfruitful because it still finds the system openssl ...

I do not know if there is a legitimate source for HP/UX 11.11 or whether it is ok to distribute, but please do not trade or barter software like this publicly on the forum.

Locking thread.

For now it appears we have sufficient funds to maintain this site. If the need arises, Neko will open donations again.

Hello all,

I'm currently building my dual mips3/mips4 neko_openssh on both my ChallengeS and Origin 200 (6.5.22m/30m with MPro744+patches) with inclusion of all the unit-tests. While running them, it turns out that one particular openssh regression test fails:


Error code -21 tells me that there is an invalid key being generated or compared. After many evenings of tracing and trying out stuff i found the culprit: ge25519.c Elliptic curve key generation. When compiling this particular file with -O1 i got:


...And it's still running
So this looks like a compiler bug. I'll leave it for now and issue a bug report with the openssh guys. and package the stuff soon with the ge25519.c compiled with -O1. If you guys run a recent homebrew openssh compiled with MIPSPro -O2 or -O3 please make sure you include this fix.

There are other problems with printing size_t types in printf statements across the code as stated by Canavan in https://bugzilla.mindrot.org/show_bug.cgi?id=2301 but i have a workaround patch that fix these printf problems.

I will look into this with other mods. Thank you for reporting.

As a reminder to everybody: Publicly posting offensive and rude remarks to specific forum members or (ebay) resellers about anything will be removed without notification. If it is the first post of that specific user, he or she will be banned.

Chances that the targeted person will see such a post is low, because we have several mods able to handle this.
Don't do it, you're only creating more work for mods.

khalidschofield wrote: How did it go with OpenSSL ? Did is there a new version for irix ready yet?

Both Canavan and me have compiled and tested openSSL 1.0.2j/k succesfully. Unfortunately RealLife got in the way of me working a lot on SGI's, but most of the crap has left my head so i can focus on packaging this for both mips3 and mips4

You can find Canavan's stuff in the /beta/canavan section of Nekoware. It's mips4 only, but his package build and testing procedure is excellent. Try it

Tasty! Where is your food-facebook page?

If mounting or fsck-ing is not possible on that particular disk, your options are very limited:
The only way to get data from it is dd that disk and hope your hexedit skills are good enough that you can repair the dd-image yourself, or extract the necessary license files and other info.

/usr should contain the most important stuff. If you can mount that partition, archive it with tar/cpio. Then find a new drive and reinstall IRIX 5.3 for Indy.

To Raion-Fox and Guardian452, please stay on topic or move to another thread (i can split it for you) and please refrain from making personal comments.

I know both of you feel strongly about the subject of cars and automotive technology, which is absolutely fine. but i am not inclined to make a separate forum-section about automotive tech on this forum

From the dutch Tweakers newssite i've read an article about a HPC speed challenge from NASA to attempt to modernize their CFD FORTRAN code, up to a factor of 10000 (!)

The story is here and the page with details of the challenge is here

Apparently the PLEIADES cluster they want the code to run on has been built by SGI (in its later incarnations obviously).

Challenge is split into an Ideation part and an Architecture part, the former being the generation of ideas about a faster approach to the flow analysis, the latter doing algorithm improvements in individual modules.
The compiler environment is Intel/GNU C++/C/FORTRAN and SGI MPT.

The whole trick lies in integrating decade old FORTRAN CFD code onto a modern hybrid CPU/GPU platform with Infiniband interconnect hardware. This cannot be done easily in a pure code-algorithmic way since the speed will depend on the PBS queue system, placement of data in memory or on disks using the LUSTRE file system.

(Maybe not so) Remarkable is that NASA apparently either does not have the resources to do it themselves or that they think this project is too complex to being handled by a single ICT software company, the reseller (SGI, now HPE), or themselves. And there is an import restriction on the FUN3D software, limiting the code challenge to US citizens.

Well, it does look like the total prize money of USD 55.000 is a damn cheap crowdfundingly steal considering what NASA could get in return

foetz wrote:

dexter1 wrote: prize money of USD 55.000 is a damn cheap crowdfundingly steal

the us government had similar "challenges" not so long ago and the prize money there was not much more. compared to their budget it's a joke

uunix wrote: Sorry, is that a typo? $55 DOT 000 ? I have my long range glasses on and can't see the screen!

Fifty-five thousand dollars in total : We use dots for thousand delimiter marks, the US folks use commas IIRC.

Foetz is right, on a 17 billion USD budget those 55000 USD hardly make a dent in their expenses. You could possibly recruit a programmer fulltime for 6-8 months doing the job.

praetor242 wrote: A buddy of mine works at Ames and is a sysadmin for Pleiades. Right now all their developers are doing other things. If I knew Fortran, this would be alot of fun!

It is but interfacing with C and C++ libraries (probably only GPU, but maybe Lustre/Infiniband) from a FORTRAN program means you have to use Swig or write wrappers which does argument type conversion for each function you use.
Most default types are easy, but complex and zomplex and string types are a different matter: they need careful testing.

Furthermore there is this matter of possible different name mangling between Intel and GNU compilers, which necessitates multiple compiler specific interfaces: Although that can be tested and adjusted if necessary.

Regarding Josehill's comment which crossed my post:

It is true that allocating project-millions for HPC machinery is actually easier than recruiting support and programmers on a project after that initial big budget spend.
For years I am trying to get faculty heads and ICT bosses around the fact that they should change the way projects are budgeted: Not prioritizing acquisition funds of hardware and software from whoever gives you the best deal, but also allocate money for developers who can teach researchers new skills in writing code and new ways of performing computation.

But man, that is frustratingly hard

I'm not sure a kickstarter or crowdfunding would be applicable to getting specific emulation drivers into MESS. The authors of MAME and MESS are quite closed and unapproachable about code development and apart from hacking it yourself, there is not much else one can do besides bugging them.

As a fact, the SGI Indy emulation is on their TODO list, see https://www.mess.org/mess/todo so it might take a bit of friendly poking to get things going.

Hello Pegasus,

The rule exist because in the past the forum was subject to response from SGI about copyright infringement on this site.
Nekonoko, the forum admin, decided to put this rule in effect to avoid any legal issues from any company.

A well groomed Octane2. Bonus points for keeping cookies in a glass jar

It depends on whether the disk contains interesting data for the sake of preservation. If not, upgrade to 6.5.30m or wipe and install fresh.
For an upgrade from 6.5.15m to 6.5.30m you need patch 5086 installed first: http://www.vdheijden-messerli.net/sgist ... 86.tardist

BTW, the sensible choice of IRIX version on a Fuel would be 6.5.30m, but a minimum of 6.5.22m is required to run nekoware. This is because that version is the ultimate version for older SGI systems and a sizeable part of nekoware is built against that version.

The media can be located on Ebay, or downloaded from Archive.org if you don't mind some CD image juggling and setting up DINA or a Linux machine as install server.

Check out Ian's site at http://www.sgidepot.co.uk/sgi.html for extra stuff and information.

japes wrote: Or you can get the impact ready powersupply and if you ever want to run an impact graphics card you'll be ready (well, you need the riser too I guess)

For upgrading to Impact systems you need at least a PROM revision "SGI Version 5.3 Rev E IP22 Sep 28, 1995" or "SGI Version 5.3 Rev E IP22 Jan 29, 1996" which correspond to part# 070-1367-011 and -012

Y888099, allow me to suggest setting up a private Blog about these monologues about ancient software worlds. If you have specific questions about software please ask them here. Otherwise, people will simply ignore your posts if you continue to do this.

itsvince725 wrote: http://www.ebay.com/itm/SGI-Silicon-Graphics-Indigo2-ITT-Power-Systems-PEC4074-6064470-Power-Supply-Used/291817009581?_trksid=p2485497.m4902.l9144

Does that mean this is an Impact PSU?

From the ebay listing i infer type 9430814. Jodeman lists in http://www.oocities.org/siliconvalley/h ... upply.html that this is a PSU for R4K/R8K systems with Express GFX.

Also, the blue impact power cable for the riser is not there, so it's evident from the pictures that this is not an Impact PSU.

OP has deleted topic start post: locking thread

OP has deleted topic start post: locking thread

ftp://ftp.nekochan.net/pub/irix/Development/java/

Version 2 is out, upgraded with even more leds:



It actually runs Basic, Forth and 6502 assembly. It's limited to about 60KHz so no chance to put this in an AppleII

Y888099 wrote: Welcome to the desert truth of reality...

s0ke has decided to part with his machine, that is entirely his decision resulting from his reasoning. I guess everybody else will have some sort of opinion about this, but i have no inclination to see these kinds of discussions in a hardware for sale thread.

If you want to discuss his decision, PM him or start a thread somewhere in everything else.

gijoe77 wrote: were these GIGAchannels the ones where there was a way to put in an Octane Impact graphics card?

Yes, although you have to modify an SI/SE GFX card by replacing the latch mechanism, which you can salvage from e.g. a MSCSI option card.

I think that the word chemist in this context is a bit misleading since i think the OP means creating Pharmaceutical compounds by regular chemistry master students (of which i happen to be one). Or do Americans/Brits use the word "chemist" to designate "pharmaceutist"?

I never came close to creating something fit for human consumption. The laboratory simply is off-limits for anything human consumable. Well, except for perhaps my synthesis of Cinnamon acid assignment. All the folks at the laboratory were sniffing at me and my cabinet.

Looking at the error messages, it appears that canvas is a NULL pointer. It could be that the SDL 1.x binding for creating a canvas goes wrong. I should have a look at SDL2 compile in IRIX, since that is what i want to use for my programs.
Did you poke Lynx via his email yet?

lynx wrote: What are values of things in the line where it breaks in GemRB::Font::RenderText? Did something overflow etc.

The two examples by necron2600 list argument stack values of the member call GemRB::Font::RenderText

Talk to Guard outside Inn door:

Guy in north/top house who comes over to talk/attack:

Both crash at the same font.cpp:254 line. In both cases canvas is a null pointer. I really should check with my O2 running IRIX6.5.30 if this is happening consistently across IRIX releases. I also cannot rule out SDL 1.x involvement in the crash.

But maybe the Linux trace shows some different values.

BTW: is there any use of the this pointer in the RenderText class? I had beef before with using that pointer in IRIX code (open source celestia)

I had to process the photo's a bit because they are quite dark.

I counted 18 different CD's: 4 x 6.5.19 overlay, Base doc, Applications, 4 x Freeware february 2003, 2 x 6.5.12 Demos, 4 x Found1/2/DevFound/DevLib, SNMP access for HP-UX MIB and ONC3/NFS3.

It's been added as an extra AWE revision entry.

You can continue troubleshooting by removing the graphic card and see if it stays powered on for a longer period.

But the most likely scenario is that the power supply needs an overhaul. We just had a thread with tips on how to recap a R4000 Power Supply: viewtopic.php?f=3&t=16731963

Try to read through it and check f.i. if the zener diode C111 needs repair. Better still, get someone to recap that PSU.

Can you make a picture of the damaged cap on the graphic board?

Next to the header files declaring getopt_long, you also need an implementation/definition of getopt_long, most commonly in a separate C-source file which you need to compile yourself (or a library with the symbol defined and implemented)

So you need https://github.com/freebsd/freebsd/blob ... opt_long.c and include that in the goaccess source, or build it separately as static or shared library and link with it.

The other five are blank cover plates. They have a backside made of sheet metal to provide shielding inside the O200 case

It's been a while i disassembled such a unit but i can't remember the procedure anymore.

I believe you need to remove all screws you can access from the bottom and then "slightly" open the aluminium shell to pass those tabs. Don't overdo it, or you bend the aluminium case.

There is also the grounding bolt recession at the very right of the shell. This will prevent you from lifting the shell, so it is possible you need to shift the shell forward or backward a bit.

I'm not sure and if you do, chances are that heat pads are glued between the plate and some controller chips. Be careful with that.
But check the grounding bolt recession first. Maybe by taking that into account you can release the shell without removing the bottom plate.

i haven't ever seen a unit with grounding bolt and cable attached, and your unit doesn't have a grounding bolt either but the fact that there is a recession where the grounding bolt should be makes the shell hard to separate form the bottom plastic.

I think it will be fine. And welcome back Generatrix, long time no see