MUT2 buggy edition

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
ecomoney
Posts: 2178
Joined: Fri 25 Nov 2005, 07:00
Location: Lincolnshire, England
Contact:

Interesting

#21 Post by ecomoney »

Sounds interesting..does it automount, what is the usage like? A screenshot and a description of how it works would be great.

P.S. Jesse hello! Ive used your previous program at least every day for the last two years!!
Puppy Linux's [url=http://www.murga-linux.com/puppy/viewtopic.php?p=296352#296352]Mission[/url]

Sorry, my server is down atm!

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#22 Post by Lobster »

I should really clarify that statement.
Image

And the cructacean is in!

Jesse - the problem was
the icons need to be in a subdirectory called icon (see pic)
all the .ppm files went in there . . .
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

Re: Interesting

#23 Post by Jesse »

Hi ecomoney,

Sorry, no automounting at this stage, unless you'd like to write a script for that?
I've never really been sure on how everyone expects automounting to be working, theres lots of options when you think about it, and different people have different expectations.
MUT2 is quite good at detecting usb storage devices, and can be used via scripts.
Its user interface is very similar visually to the original MUT that you are very familiar with, but it has a whole different set of bugs, possibly some common bugs too.
MUT2 differs from the original in that you aren't supposed to have to click on 'refresh' icon, any hardware changes appear when the system is ready for them. The refresh button is supplied in case there is some unknown bug lurking in there.
MUT2 differs from the original in that there is a drive/disk service that runs in the background, and the client connects to that for a hardware/status list.
The server and client is the mut executable file, but it is a multi-application, in a very similar way that busybox is.
If you wanted to write a script that interfaced with mut, you would shell to "mut mutclient" and parse the output from that to obtain your hardware information. The execution time of "mut mutclient" is very short, as it only takes a few ms to read the data from the mut server. If you look at the code in mut2.tcl you will see some examples of how mut is invoked, and some output samples, its a bit messy though.
Any invocation of mut will usually start the server going if its needed, unless its a command for other things like for example stoping the mut server "./mut --exit".

Jesse

JB4x4
Posts: 256
Joined: Sun 30 Jul 2006, 22:44
Contact:

#24 Post by JB4x4 »

Hi Jesse,

I am running Puppy 3.01, and the drives are both IDE.

JB

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

#25 Post by Jesse »

Lobster wrote:
I should really clarify that statement.
And the cructacean is in!
Yay, that looks really good :D
I doubt you'll have problems with the nice simple setup like that, perhaps installing was the right thing for you to do.
You can resize the window to make it smaller if you need to, but it'll probably forget for when you relaunch it.
Jesse

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

#26 Post by Jesse »

Hi JB,

Could you please send me some debug output from mut2.
From a command line run these commands and then pm or post the results:

close the mut2.tcl gui program
stop the mut server with this command:
./mut --exit
start the mut server in debug with this command:
./mut mutclient --foreground --debug --nothreads > test1.txt
this command stays running till mut server exits.

From another terminal window run these scripts, replace hda with your cd drives node name.
./mut mutclient --debug --nothreads --drivecmd eject hda > test2.txt
./mut mutclient --debug --nothreads --drivecmd close hda > test3.txt
./mut --exit

The last command will stop output of the first command by stopping the mut server.

I've noticed a few bugs in the cd controls myself, but, still the drive ejects and closes on my pc, so hopefully I can spot the issues from the output files.

Jesse

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

mutt2 commandline interface/yasr etc

#27 Post by mcewanw »

Jesse wrote:Hi Trobin,

I think I understand the problem, is that espeak and yasr use alphanumeric displays so that they can scan for the words to read aloud
yasr isn't exactly a screen scraper, but generally you have the right idea about it. It actually simply reads everything passing through /dev/tty and passes it on (in the discussed case) via speech-dispatcher to the espeak synthesiser.

What licence does mutt2 come with? If it is GPL, I wouldn't mind looking at the C source code for the server to see how to interface to it from the commandline.

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

#28 Post by Jesse »

Hello,

I've posted an update in first message, build 1058 http://www.murga-linux.com/puppy/viewtopic.php?t=26336.
The Audio controls, play/next/stop seem to have started working too, Yay! :)

Wolf Pup,
can you please check to see if audio lockup is fixed?
Does mut audio controls now work for you?

JB4x4,
can you see if the latest build corrects your eject/close buttons?
If it works you can ignore those tests. I found and fixed a handle leak that would have caused your eject/close to not work.

mcewanw,
the code is GPL, the command line interface is via "./mut mutclient" it prints out machine readable output, to send a command "./mut mutclient --drivecmd eject hda" sort of thing. When I wrote the mutclient I gave it the unreasonable expectation that it should complete within 70ms, and it usually does, so that isn't a slow method. One page of confusing symbols might be easier than 288Kb source code. If you'd like the src anyway, send me your email address in an PM, and I'll email it.

Jesse

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

interfacing to mut2

#29 Post by mcewanw »

Jesse wrote: MUT2 communicates to itself (client) via a tcp/ip socket on a 127.0.0.2 address
. . .
The MUT2 comes with a graphical front end, similar to the original MUT, but you don't have to use this, if you remove the grapical user interface, there is only one file remaining, the mut binary executable file.
The MUT2 binary file (called mut) that does all the background magick also has several front-end command line interfaces , , , The MUT2 binary is written in C . . . The GUI is only supposed to be a GUI, so its theoretically possible to have other front ends to it written in other languages, MUT2 was written with this in mind. . . . If you wanted to write a script that interfaced with mut, you would shell to "mut mutclient" and parse the output from that to obtain your hardware information. The execution time of "mut mutclient" is very short
Jesse wrote: One page of confusing symbols might be easier than 288Kb source code. If you'd like the src anyway, send me your email address in an PM, and I'll email it.
Thanks Jesse, that would be useful.

Coincidentally, I've not only also been working with yasr and espeak etc., a program I've written related to that project, which is particularly designed with the visually impaired or even totally blind user in mind, krecspk, works in a similar manner, philisophically at least, from what I understand of your client/server description of mutt2 above (making the client just a User Interface). I also have a background of C socket programming, having been a data comms engineer writing tcp/ip socket client/server programs to interrogate snmp MIB databases, and similar little socket-based client server programs (udp and tcp) for performance testing of tcp/ip satellite links. I'm thus interested in you program from two aspects: the interprocess communication aspects, and the interfacing with yasr aspect.

Indeed, an IPC communication shell program I use [wiak] to provide some of krecspk's functionality, is also being designed to handle socket communications (both UNIX sockets and TCP/IP sockets), as a means of expanding the comms capabilities of applications such as krecspk, as this extract from my homepage for it describes:

"wiak provides IPC facilities . . . to languages that don't have easy, flexible or any access to them (such as bash script). It also works well with the likes of gtkdialog to create event driven GUI or commandline user interfaces. . . . It is intended that wiak will eventually provide UNIX and INET socket capability
. . . [wiak] facilitates the creation of different clients for the same backend server(s), or indeed, different backend server(s) for the same GUI-client. Different versions of any wiakapp can thus be created relatively easily for different systems; the GUI-client, for example, being a separate component, can be simply re-implemented using alternative coding languages and GUI toolkits, and take different design forms, to match the needs of the user or the particular OS distribution. . . . The use of wiak thus liberates the programmer in many ways, simplifies the programming task, and helps to future-proof the application's code. " (from: http://wiakapps.freehostia.com/wiak.html)"

It may thus even be possible, that I might find the socket-capable wiak a convenient client for "talking" to your mut2 backend server as part of a yasr-compatible interface, such as Trobin is requesting. Maybe not, but I feel that it would be worth my having a look at your code to see if wiak could be made compatible with it.

I'm just about to crash, but I'll PM you later.

mcewanw

Wolf Pup
Posts: 637
Joined: Fri 28 Apr 2006, 01:37

#30 Post by Wolf Pup »

Jesse wrote:Hello,
Wolf Pup,
can you please check to see if audio lockup is fixed?
Does mut audio controls now work for you?
MUT2 makes puppy go real slow when play is clicked, at first i thought puppy frooze but it just went real slow, but no audio is played.
[img]http://img230.imageshack.us/img230/8595/ubd6467dp2.png[/img]
[url=http://www.tinyurl.com/54tu74]Visit The Repository[/url] - Helpful and hard-to-find treats for Puppy 3.
[url=http://www.tinyurl.com/c5a68f]Click Here for Puppy Support Chat, + Helpful Links.[/url]

Knuke
Posts: 1
Joined: Thu 14 Feb 2008, 21:11

Another MUT problem

#31 Post by Knuke »

Ahoy There!

The other day I was working in the Wobbly version of NOP301. I used MUT to mount my Vista partition so I could read some files. Normally, I immediately unmount the partition and close MUT when I am done with it, but I forgot this time, and I switched to another desktop to do some other work. After a time, I realized that I needed to read those files again, so I opened up MUT in the second desktop to mount the Vista partition. MUT reported that the partition was still mounted (as it should have done), so I read the files, unmounted the partition, and closed MUT.

I did some more work in that second desktop, and then switched back to the first desktop. There was MUT, still running, and still reporting that the Vista partition was mounted. I hit the unmount button, and my computer went into doorstop mode - black screen, no keyboard, no mouse, nothing to do but turn it off and back on.

When I booted up the machine, Wobbly reported that I had shut it down improperly, and that I needed to run the Xorgwizard again. I tried this, but immediately after choosing Xorg, the machine went into doorstop mode again. Fortunately I had Puppy301 on another partition, so I booted into that, mounted the Wobbly partition, copied xconfig.bak into xconfig, and successfully restored my Xorg settings. I rebooted into Wobbly, and all was fine except for the sound.

I tested the behavior of MUT on Puppy301, and it does not allow for 2 instances of MUT to be running simultaneously - which is a good idea. If it is running on one desktop, and you try to start another instance of MUT in another desktop, it simply moves the first instance of MUT into the current desktop.

I think that the bug in Wobbly could be easily fixed with a short Bash launcher script that checks to see if MUT is already running before launching another instance. I would write one myself, but it has been a couple of decades since I have done any programming of any sort, and it would take me some time to read up on all of that again. I'm pretty busy these days doing other stuff. I know that there are people who do that sort of thing on a daily basis, and this would be a five minute hack to write and test.

I think that Wobbly is a fantastic achievement for such a small distro, and well worth the effort to fix. It might save a new user from hosing their config files, and not knowing how to recover.

All the best! -Knuke

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

script

#32 Post by raffy »

I guess Mozilla Seamonkey has that script in /usr/local/bin - making sure that there is only one instance of Mozilla running (am using Firefox now).

MUT2 acts as a daemon and consumes 3-4% of power of my 800 mhz Celeron CPU.
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].

JB4x4
Posts: 256
Joined: Sun 30 Jul 2006, 22:44
Contact:

#33 Post by JB4x4 »

Jesse,

Sorry, but no-go on CD/DVD eject controls. I have attached the output from the tests you have asked about.

JB
Attachments
mut-test-1.tar.gz
(8.5 KiB) Downloaded 368 times

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

conceptually identical

#34 Post by mcewanw »

Code: Select all

./mut mutclient --foreground --debug --nothreads > test1.txt
I realise looking above that what you call the "mutclient" is conceptually identical to my IPC program "wiak", so I probably don't need a copy of your source code to interface wiak to your mut server. In terms of interprocess comms, mutt works in exactly the same way as any of the backend servers I write when creating a wiak application. It writes to stdout, allowing the other parts of the program to pick up the data from there. So it is wiak-compatible in my parlance.

In other words, the programming model is the same as what I use writing wiakapps. A UI/GUI which is used as no more than a user interface sends events to an interprocess comms client (pipe, or message queue or socket) and the receiving daemon/backend server, processes the received command, and responds accordingly; it then communicates back, when required, by simply writing to stdout. In mutt2 you combine two of the functions into mutt itself, whereas I call wiak twice for the same effect in my wiakapps.

Even the way mutt is terminated is the same conceptually; your IPC client sends an option to the server:

Code: Select all

./mut --exit
In such a system, using wiak, it looks like this:

Code: Select all

./wiak --quit
Interesting. I haven't seen that exact model used before I published wiakrecord (the first wiak offering, which also uses a backend server written in C - which can be run as a daemon too). In fact, I have been advocating this methodology of writing system apps on my wiak pages, because of its flexibility in terms of allowing alternative user interfaces to be written or coded in an alternative coding languages; using stdout for comms output, as used here, and in wiakapps allows even bash to interface easily with the backend server, as in wiakrecord and mut2, even when that is written in C.

Anyway, if I am correct in how your system communicates/operates, I could certainly interface with it easily with wiak for the purposes of Speakpup or whatever. I wouldn't need the source code for that, simply the output codes your server writes out to stdout and their translation in terms of action/purpose.

Code: Select all

mut2 GUI in tcl/tk, keypress event sending to backend server:

   "play" {    ;# Play the stopped audio CD
          catch "exec  $::mut/mut mutclient --drivecmd play $dev"
          }
  "pause" {    ;# Pause the playing the audio CD
          catch "exec  $::mut/mut mutclient --drivecmd pause $dev"
          }
   "stop" {    ;# stop Playing the audio CD
          catch "exec  $::mut/mut mutclient --drivecmd stop $dev"
          }

				
wiakrecord GUI in gtkdialog3, keypress event sending to backend server:

   <button>
      <input file stock=\"gtk-media-record\"></input>
      <action>\"wiakmv --zid 40006 --send go -l 3\"</action>
   </button>
   <button>
      <input file stock=\"gtk-media-pause\"></input>
      <action>\"wiakmv --zid 40006 --send pause -l 3\"</action>
      <action>\"wiakmv --zid 40006 --type 2 --send pause -l 3\"</action>
   </button>
   <button>
      <input file stock=\"gtk-media-stop\"></input>
      <action>\"wiakmv --zid 40006 --send stop -l 3\"</action>
      <action>\"wiakmv --zid 40006 --type 2 --send stop -l 3\"</action>
   </button>
   <button>
      <input file stock=\"gtk-media-play\"></input>
      <action>\"wiakmv --zid 40006 --type 2 --send stop -l 3\"</action>
      <action>\"wiakmv --zid 40006 --type 2 --send go -l 3\"</action>
   </button>

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

Re: conceptually identical

#35 Post by Jesse »

Hi mcewanw,

I think I actually had a look at waik when I was considering the IPC for mut client and mut server. But what I wanted to achieve was slightly outside the waik box, and using an external app for the comms would have introduced a small extra delay, and I also wanted interactive sessions, and the ability to send C structures across in a compatible method, for that I used some aspects of xml tags that I have heard about in soap, but soap was way way an overkill for what I needed.
But yes, you're right there are very similar fundamentals about the IPC used in MUT2 and waik.
As you're a seasoned C programmer, you might quite enjoy having a look at MUT2's simple IPC, its actually quite a small piece of code, if I recell correctly.
MUT2's IPC strategy is that the MUT2 server maintains a list of C structures that describe the hardware list/state, and when the client connects, it can issue commands or request a copy of the structure data to be sent over, its an interactive session, so the client can do all the steps it needs to perform a conceptual operation.
The client and server are all compiled in one binary, so all the structure parameters are always identical, and then the client can just directly access all the parameters in the structures for each of the mut client interfaces.

Jesse

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Re: conceptually identical

#36 Post by mcewanw »

Jesse wrote: The client and server are all compiled in one binary, so all the structure parameters are always identical, and then the client can just directly access all the parameters in the structures for each of the mut client interfaces.
Jesse
wiak is actually a child of morfi (which I have only published in binary form as yet); there is a copy of wiak embedded inside morfi. I also embed wiak inside morfi to avoid the delay of also using the external wiak and both share identical structure parameters for the same reason you have adopted that strategy in mut2 (indeed, morfi can be used a "big" wiak). However, though wiak can send C structures over to morfi (or two morfi's to each other) I didn't need that facility in wiakrecord and haven't decided what I want the C structure passing for yet - I just recognised that it would be useful for some complex data passing purposes.

Anyway, I'm happy to see you building your project in the manner you are. It opens doors in terms of making it easy to interface with. The only thing about it that I wonder about, is your developing the server as a daemon in order to maintain state information. It may not consuming much in the way of system resources, but it is a small continuous drain. Since I imagined that mut would not be called regularly, I thought you might have been able to store status info in a structured file or small database of somesort allowing mut only to be started when required. But I haven't thought much about the issues involved in such a utility, so I'm sure you have your reasons for making it a daemon.

I used to play chess quite well as a school boy, but later, at university I finally started reading chess books and my own chess playing style went to hell. Though I am curious about your own code therefore, at this moment, when I am still developing the wiak family, I prefer therefore to look as little as possible at others code (unless I hit the blank page of vanished inspiration)! I know that may not make much sense, but its just a theory I have. Once my projects are all going to my satisfaction, then I like to look at alternative similar projects for renewed inspiration and ideas (it is probably only at that stage that my own work becomes any good).

I would, however, always acknowledge, in my distributions, using any portion of another projects code, algorithm, or more important and fundamental than these, any conceptual idea; the latter is the main creative part really. Using a special inter-process communication client, such as in the wiak-driven applications and now mutclient in mut2, to simplify and enhance the button-press event handling of the GUI/UI in a client/server arrangement is quite new and unique from my explorations. It separates the main processing into a separate backend server and allows a great deal of flexibility in User Interface client design. I'm glad I noticed this thread.

I might however be interested at this stage in the response codes sent out by mut2 daemon to the mutclient so that I can experiment with interfacing to it. That would indeed be easier than sifting through your source code looking for what is written out and when. Whether I'd get round to writing a possible commandline client is another matter; too few hours in the day at present! :-)
Last edited by mcewanw on Sun 17 Feb 2008, 01:30, edited 3 times in total.

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#37 Post by cb88 »

jesse how distro independant is MUT2? if you think it is worth a try i could give it a go on slackware... and is running it as a user supported? would a pop up to allow permissions be needed to mount things?
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

#38 Post by Jesse »

Hi cb88,

The mut executable is statically linked, so there are no library requirements for it, but the gui component requires everything attached to tcl/tk to be present.
The mut executable gets a lot of its information from the /sys which is a Linux Kernel 2.6 only thing, so that rules out some early Puppy distros that used 2.4, and other non- 2.6 Kernel distros.

MUT2 does not attempt to do anything about username permissions. It is programmed with the assumption that it can use and access what is allowed by the kernel, running it under another distro like slackware and as a non-root user will limit its functionalty, for example mut will not be able to read partition tables from the hard disk, so there will be no partition information to display on drives.

I just tried now on my work machine which is Fedora 6, and you can see the names of the drives, but that is about it. Running as root user allows it to see all the information.

MUT2 would probably be considered as a serious security risk by security experts, theres no user permissions to speak of, and another program on the same computer with evil intent could ask mut to unmount the root filesystem, which is very bad for any Linux box. The MUT2 communicates with itself on a TCP/IP address 127.0.0.2, I'm not sure if those can be fudged on a network to get into a Linux Box.

MUT2 pretty much has to be run as root for it to provide any useful information. You'll probably be ok running it on other distros as root user. You only need the background daemon running as root, the gui will work with it from any username. This is another security risk.
I'm interested to know how it works for you on slackware?

Jesse

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

Re: Another MUT problem

#39 Post by Jesse »

Hi Kune,

Yes there were quite a few design issues with the first MUT.
And I think there are less design issues with the MUT2, but its still buggy at the moment.

I've been thinking about the problem you mentioned about MUT, (0.1.1?) that you had problems with, I think what happened to kill your system dead was the fuser commad that it issues before attempting to unmount the partition on the second attempt.
I think that fuser command is the culpret, and as you found out quite a bad strategy, as the fuser command refering to an umounted mount point refers to the underlying filesystem, the root filesystem in your case, and all processes using a file on that filesystem got told a signal SIGKILL, which kills them outright, including X and all X applications with a window open.

I am steering clear of that fuser comand with MUT2, but I havn't yet determined how to report a problem that the server encounters, like the unmount command failing. Perhaps that is what I should investigate next, reporting on problems is a very important step in getting them resolved.

The MUT 0.1.1 didn't autorefresh when mount points change by other programs, it did auto refresh on usb events and button clicks. The MUT2 is constantly refreshing and updating on all the aspects that it presents while the gui is open, this does use some cpu sure, but there should be virtually minimal penalty closing the gui and opening it later when you need it.

I hope that helps

Jesse

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

Re: script

#40 Post by Jesse »

Hi raffy,

I wonder what it is doing to use that much, I get about 0.1% to 0.4% cpu use on average when the gui is open, and that drops to 0.0% when the gui is closed. I have a CD/DVD drive and an IDE disk, and an AMD Athlon(tm) 64 X2 Dual Core Processor 4800+. Hmm, maybe thats it.
I guess the cpu load would be proportional to how many disks/drives that you have?

Jesse

Post Reply