Re: [bug-mdk] Bug in gmixvm

2009-10-05 Thread Stjepan Gros
On Sun, Oct 4, 2009 at 7:36 PM, Jose Antonio Ortega Ruiz j...@gnu.org wrote:

 Hi again, Stjepan. I've got another guess of what can be causing the
 initial disk scans, but, since i cannot reproduce them in my system, i
 would need your help, if you have the time.

I'll help, no problem...

 Could you comment out line number 14 in the file
 mixgtk/mixgtk_external.c (the one with a call to update_config_()) and
 see if that makes the problem go away?

I tried it and it was the same.

I also tried to recompile package on CentOS 5.2 and gmixvm there come
instantly. Turns out that this is something specific for fedora 11.

Stjepan

 Thanks a lot!
 jao
 --
 Like punning, programming is a play on words.
  - Alan Perlis, Epigrams in Programing



___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk


Re: [bug-mdk] Bug in gmixvm

2009-10-05 Thread Jose Antonio Ortega Ruiz
Stjepan Gros sgros...@gmail.com writes:

 I tried it and it was the same.

 I also tried to recompile package on CentOS 5.2 and gmixvm there come
 instantly. Turns out that this is something specific for fedora 11.

Looks like that. It's not happening to me either on a Debian sid with
gtk 2.18. Please, tell me if i can be of any further help chasing this
problem. As an aside, there're some mostly unrelated and minimal changes
in the git repo that will make the 1.2.5 release one of these days. I'm
not sure what's the best way of coordinating here.

jao
-- 
Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music.
 - Kristian Wilson, Nintendo Inc.


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk


Re: [bug-mdk] Bug in gmixvm

2009-10-04 Thread Jose Antonio Ortega Ruiz

Hi again, Stjepan. I've got another guess of what can be causing the
initial disk scans, but, since i cannot reproduce them in my system, i
would need your help, if you have the time.

Could you comment out line number 14 in the file
mixgtk/mixgtk_external.c (the one with a call to update_config_()) and
see if that makes the problem go away?

Thanks a lot!
jao
-- 
Like punning, programming is a play on words.
  - Alan Perlis, Epigrams in Programing


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk


Re: [bug-mdk] Bug in gmixvm

2009-09-30 Thread Stjepan Gros
On Tue, Sep 29, 2009 at 1:18 PM, Jose A. Ortega Ruiz j...@gnu.org wrote:

 Hi Stjepan,

 Stjepan Gros sgros...@gmail.com writes:

 Hi!

 I'm trying to package mdk for Fedora and I'm almost there. :)

 Excellent!

 The problem is that after running gmixvm it consumes much of disk and
 CPU resources. I managed to find out that it's scanning the whole
 directory tree (either /usr/bin or home directory, depending how it is
 started).

 What are the two ways of starting gmixvm? Do you have the same problem
 starting (in a terminal) mixvm?

Yes, it is the same no matter if I start it from CLI or from a menu entry.

 Attached is gdb stack trace. Do you know what could be the exact
 problem?

 Hmmm... it's a bit difficult to tell, but i have a guess. It could be
 one of the gnome daemons looking for a path, or something like that. To
 check, could you edit ~/.mdk/gmixvm.config (creating it if necessary)
 and ensure that it contains the lines:

 Assembler=/usr/bin/mixasm -l %s
 Mixasm=/usr/bin/mixasm -l %s
 Editor=/usr/bin/xterm -e vi %s

 where, in all of them, the paths are to exisiting executables?

I added those lines to gmixvm.config (and created it) but it is still
scanning the /usr/bin directory. And just now I found out that it also
stat's/lstat's many other files of which some do not exist. Here are
some excerpts from the strace output:

access(/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-sans.conf, R_OK) = 0
stat(/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-sans.conf,
{st_mode=S_IFREG|0644, st_size=864, ...}) = 0
open(/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-sans.conf, O_RDONLY) = 8
read(8, ?xml version=\1.0\ encoding=\UTF..., 8192) = 864
read(8, ..., 8192)= 0
close(8)= 0

stat(/home/zavod/sgros/.thumbnails/normal/43e5d4fbf671883fe309ae41d335cd4d.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat(/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/43e5d4fbf671883fe309ae41d335cd4d.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat(/usr/bin/latencytest, {st_mode=S_IFREG|0755, st_size=110760, ...}) = 0
open(/usr/bin/latencytest, O_RDONLY)  = 13
read(13, 
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0\0\1\0\0\0\340\...@\0\0\0\0\0@...,
4096) = 4096
close(13)   = 0
stat(/home/zavod/sgros/.thumbnails/normal/a710091ca4edfb17e916eced9711f33f.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat(/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/a710091ca4edfb17e916eced9711f33f.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat(/usr/bin/pdftoppm, {st_mode=S_IFREG|0755, st_size=21448, ...}) = 0
open(/usr/bin/pdftoppm, O_RDONLY) = 13
read(13, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0\0\1\0\0\0\340...@\0\0\0\0\0@...,
4096) = 4096
close(13)   = 0
stat(/home/zavod/sgros/.thumbnails/normal/ffd35f2016dcc3c3e310a75b7eff6c09.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat(/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/ffd35f2016dcc3c3e310a75b7eff6c09.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat(/usr/bin/sbiload, {st_mode=S_IFREG|0755, st_size=18080, ...}) = 0
open(/usr/bin/sbiload, O_RDONLY)  = 13
read(13, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0\0\1\0\0\0\24...@\0\0\0\0\0@...,
4096) = 4096
close(13)   = 0

open(/usr/bin/ntfsmove, O_RDONLY) = 13
read(13, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0\0\1\0\0\0\320...@\0\0\0\0\0@...,
4096) = 4096
close(13)   = 0
stat(/home/zavod/sgros/.thumbnails/normal/ae0e5905f16b8c56928372e0b9a5e39a.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat(/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/ae0e5905f16b8c56928372e0b9a5e39a.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat(/usr/bin/veusz_listen, {st_mode=S_IFREG|0755, st_size=1082, ...}) = 0
open(/usr/bin/veusz_listen, O_RDONLY) = 13
read(13, #!/usr/bin/python\n\n#Runs veus..., 4096) = 1082
close(13)   = 0
stat(/home/zavod/sgros/.thumbnails/normal/69d160f964a7fa71e2c3cfee29f449f6.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat(/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/69d160f964a7fa71e2c3cfee29f449f6.png,
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat(/usr/bin/lpq, {st_mode=S_IFLNK|0777, st_size=27, ...}) = 0

Stjepan

P.S. Bugzilla entry for Fedora package is here:

https://bugzilla.redhat.com/show_bug.cgi?id=520637

 Thanks!
 jao
 --
 Dealing with failure is easy: Work hard to improve. Success is also
 easy to handle: You've solved the wrong problem. Work hard to improve.
  - Alan Perlis, Epigrams in Programing



___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk


Re: [bug-mdk] [bug #13661] gmixvm appears unresponsive

2005-09-18 Thread Baruch Even
Jose A. Ortega Ruiz wrote:
 Baruch Even [EMAIL PROTECTED] writes:
 
 
I can see no patch or anything to test. Do you have a snapshot or CVS
repository to test it from?

 
 
 Sure. It's in the savannah CVS repository:
 
 http://savannah.gnu.org/cgi-bin/viewcvs/mdk/mdk/mixgtk/Makefile.am.diff?r1=1.18r2=1.19

I'm not getting the warnings anymore.

I'd appreciate it if you could release a new bug fix release for me to
package.

Baruch


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk