With some modifications I succesfully managed to compile giFT-Zombie on my Irix 6.2.
"flvw" is really buggy on my IRIX. When there are to many options listed it gets really slow and a core dump will occure. I didn't have this problem with the older version "halo".
I think the problem can be solved by adding a "stop" function.. so i can break off the searching before the core dump will occure :)
great work!
Sander
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hum, that would partially explain why I started getting HUGE memory grabs (I normally don't see this but I ran the clint just after startup. X and related apps take up a footprint of about 5-700 megs and quite suddenly the memory graph applet showed another 700 or so being eaten (until I ran out of ram...) over a period of about 10 seconds before my system would either lock or the app would crash.
I normally wouldn't see this. It would be really nice if I knew exactly what to run to develop a crashdump report for you... the author of pan had something like that on their page...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it's a problem with the TCPSocket class when we try to read from the socket when their is no connectivity with the giFT daemon. I'm looking into it. We also changed the search results data struct to be a bit more memory effiecient in a yet to be released version(check cvs if you'd like).
I definatly agree we need to setup some standard way of catching and posting bugs. I'll take a look at what some of the other projects are doing and try to incorporate that into Zombie.
Thanks for the feedback.
-Seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With some modifications I succesfully managed to compile giFT-Zombie on my Irix 6.2.
"flvw" is really buggy on my IRIX. When there are to many options listed it gets really slow and a core dump will occure. I didn't have this problem with the older version "halo".
I think the problem can be solved by adding a "stop" function.. so i can break off the searching before the core dump will occure :)
great work!
Sander
Hum, that would partially explain why I started getting HUGE memory grabs (I normally don't see this but I ran the clint just after startup. X and related apps take up a footprint of about 5-700 megs and quite suddenly the memory graph applet showed another 700 or so being eaten (until I ran out of ram...) over a period of about 10 seconds before my system would either lock or the app would crash.
I normally wouldn't see this. It would be really nice if I knew exactly what to run to develop a crashdump report for you... the author of pan had something like that on their page...
I think it's a problem with the TCPSocket class when we try to read from the socket when their is no connectivity with the giFT daemon. I'm looking into it. We also changed the search results data struct to be a bit more memory effiecient in a yet to be released version(check cvs if you'd like).
I definatly agree we need to setup some standard way of catching and posting bugs. I'll take a look at what some of the other projects are doing and try to incorporate that into Zombie.
Thanks for the feedback.
-Seth