MUT2 buggy edition

[Lobster]

Hello Puppy enthusiasts,

I wouldn't advise putting this particular edition on a liveCD version of puppy.

Jesse

It is the only one I got

Mut2 - hooray
Can we have a screenshot?
What is the plan?

OK I am in Phoenix (CommunityEdition pre-alpha)
and moved Mut into usr/local
and tried to run mut2 with the wish tkl runner
but you also have a compiled program 'mut'?

OK can not run from live CD
maybe in the next release . . .

Mut is back! [round of applause]
thanks Jesse

Code: Select all

sh-3.00# wish mut2.tcl
version mut 2 multi-call binary version: mut2_1.0.0.1041
Error in startup script: couldn't open "/usr/local/mut//icon/fd3.ppm": no such file or directory
    while executing
"image create photo ::img::img(fd3)      -file "$::mut/icon/fd3.ppm""
    (file "mut2.tcl" line 691)
sh-3.00# 

[Jesse]

Hi Raffy,

no TCL in Dingo??? thats a shame.

The MUT2 binary is written in C and really ought to run on Dingo, though I havn't tried it.
The MUT2 GUI is writtten in TCL/TK, so that part won't run on Dingo. 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. It might even be possible to have PMount as the front end if you could imagine that.

Perhaps it should say "since 2008"?

Jesse

[Jesse]

Hi Lobster,

Hello Puppy enthusiasts,

I wouldn't advise putting this particular edition on a liveCD version of puppy.

Jesse

It is the only one I got

Um, I should really clarify that statement. What I meant to say was, "this particular download is very likely to have all sorts of obvious and non-obvious bugs, as such please don't publish it in a Puppy ISO to make available to the general population."

MUT2 will run the same way regardless if you have booted either from a live cd, or another boot method like hard disk. There will be minor differences like the root system mount point, but are minor.

The MUT2 gui is very similar to the original MUT, not too much has changed there, with the obvious change of a scroll bar.

Theres no official plan, the current plan is to identify the first round of bugs with people who know how to use a command line interface, several bugs have already popped up.

I havn't tried Phoenix (CommunityEdition pre-alpha), but if its uses a 2.6 kernel and has /sys mounted, and has tcl/tk then it ought to be able to do something.

Please don't try to "propperly install" MUT2, as theres no real advantage. Plus a 'propper install' would be to /usr/bin or /bin with all the symlinks to mut, but that sort of thing is well down the track and I havn't even tried that.

Just extract it to a location like /temp/mut2, change to that directory and run it from there.

The compiled program 'mut' is encapsulates the essence that makes MUT2 different from the original MUT. The 'mut2.tcl' is just a front end.

Code: Select all

 Error in startup script: couldn't open "/usr/local/mut//icon/fd3.ppm": no such file or directory

Um, it is saying that it cannot find the file /usr/local/mut//icon/fd3.ppm, so presumably you installed to /usr/local/mut.
I'm not sure why this is failing, it might well be related to the way you are starting it with the explicit use of 'wish". Try using "./mut2.tcl" instead. The first line in mut2.tcl specifies that it is supposed to be run by wish and bash uses that for you.

Jesse

[Sit Heel Speak]

But before doing ./mut mutclient...please check whether I've placed the unpacked files where they ought to be. See screenshot:
http://i28.tinypic.com/9qws3m.png

Old MUT at lower right shows my actual drives arrangement.

Upper left ROX window shows what unpacked from the archive.

The window below it: I copied the unpacked's to new subdir /usr/lib/mut2 and renamed mut2.tcl to mut.tcl

The window below that, is the original /usr/lib/mut

Window at upper right, I made a copy of /usr/lib/mut2 and added-in the files and additional subdir from the original MUT subdir which were not present in the downloaded archive.

Which of these should I be running the tests from? Should I have kept the name mut2.tcl? Does it need to go in the original MUT's subdir /usr/lib/mut ?

Oh yes, by the way...good to see you here again!

[Jesse]

Hi Sit Heel Speak,

Wow! what a lot of drives!!! and a scsi one in there too.
I'm sure you'll like the scroll bar in MUT2's gui.

Theres no need to "install" mut2, /temp/mut2 is just as good as anywhere, click on the mut2.tcl from rox, or run mut2.tcl from command line.
Your /usr/lib/mut2 looks just fine to me, you can run the tests from there.

There are no missing files in your /usr/lib/mut2 directory, theres just a lot fewer files in MUT2, it has had quite a change in layout strategy since 0.1.1.
All the functionality of the binary executables files in the bin directory for mut 0.1.1 have shifted into the single mut binary file for MUT2, which also contains the mut server and client applications, the mut2.tcl is just a gui front end, and the gui is what uses the icons in the icons directory.

I hope that helps to make things more clear.

Jesse

[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!!

[Lobster]

I should really clarify that statement.

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 . . .

[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]

Hi Jesse,

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

JB

[Jesse]

I should really clarify that statement.

And the cructacean is in!

Yay, that looks really good
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]

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]

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]

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]

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

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]

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.

[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]

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.

[JB4x4]

Jesse,

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

JB

[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]

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