When I moved GPSApp out of the /programs0 drive (I put in in /drive0/var/gpsapp instead), it still worked as before, except now it doesn't find the ROUTES subfolder any more. I made sure that I created the /drive0/var/gpsapp/routes folder and populated it, but I think GPSapp is hard coded to get the files from /programs0/routes instead.

Can it either (a) look for a subfolder called "routes" from the current app location or (b) get spec'd in config.ini?

How about this (defines routedir option)

Ewww, that's that messy "source code" stuff.

(Thanks a million-- Looking forward to trying it out once I can get my hands on a binary.)

Whine whine whine

Thanks! Just put it in place, adding routedir= to config.ini, and...

Argh, I'm getting a "Checking Disk Integrity" pass when trying to synch the config.ini with emplode. I coulda SWORN that I put the thing back in RO mode each and every time I did something today.

Oh well. I'll post the results in about two hours...

Okay, I get "No Routes Found" despite a folder populated with routes.

Current syntax of my config.ini, verified with FTP, is:

[gpsapp]
track=false
scale=false
routedir=/drive0/var/gpsapp/routes

And that is the correct folder name. Should that also have another slash at the end or what?

I also tried:

routedir=drive0/var/gpsapp/routes
routedir=/drive0/var/gpsapp/routes/
routedir=/drive0/var/gpsapp

No dice...

I did:
[gpsapp]
track=1
routedir=programs1/route

And it opened the directory. A leading slash should also be ok (for you, not for me, I'm testing using gpsapp_host)

And I tried routedir=drive0/var/gpsapp/routes after making that directory, and it also worked. Not on the player, yet. Perhaps I should install this there also.

Sanity-check - I assume that your route population is fairly new, have you checked that the routes have readable permissions? (Oh, and directory too..)

Nah, I can reproduce it, but... only on the player.

Nope, I lied. The "reproducible" problem was actually a NULL embedded in my config.ini. Here's the neat thing. I did:
cat >> /empeg/var/config.ini
and pasted into it on the player. The NULL appeared in the text I pasted (as ^@ of course).

How bloody annoying.

This is literally the binary I'm running on my player.

And here's the diff, slightly different from the last.

Sanity-check - I assume that your route population is fairly new, have you checked that the routes have readable permissions? (Oh, and directory too..)

Yes, owner is tagged as RWX and group/all are tagged as R.

I tried uploading a fresh route and that one didn't show up either. Still get No Routes Found. And no null characters in my config.ini as far as I can tell.

This is literally the binary I'm running on my player.

Tried this one as well, which is a a few bytes different from the earlier one. No difference in behavior on my end.

And I tried routedir=drive0/var/gpsapp/routes after making that directory, and it also worked.

And there was no /programs0 partition and even if there was, there was nothing in it?

See, my goal was to remove the need for /programs0 and preinit completely. So one of the things I made sure to do was to get rid of that partition (or at least make sure it wasn't mounted). At first I thought GPSapp was working in the new folder, until I realized I'd still left /programs0 lying around as-is. This all started going bad after I removed preinint and /programs0....

I also tried converting my config.ini from CR/LFs to just LFs and that didn't change the behavior...

I keep expecting there to be a typo in the path name, but I've quadruple-checked it and made sure it was a zero and not the letter O.

I assume that your route population is fairly new

Hang on a bit. Define why "fairly new" is important. I uploaded a fresh route today, just to test. But it was created using a python script that's a few months old. Did the script change, or did file format of the routes change in the last few months without me knowing about it? Or did the expected file names of the routes change?

And there was no /programs0 partition and even if there was, there was nothing in it?

Long before opening the route directory it does chdir("/"), so where the binary lives really doesn't matter. drive0/var/gpsapp/routes is the same as /drive0/var/gpsapp/routes, and both are the same regardless of where you run the binary from. I'm not planning to move my binaries, or my data, for now, but I did make a separate routes directory and populate it with a different set of routes, to demonstrate that it opened the right one. It did. So I added some printf code and ran it by hand on the empeg. It opened *only* the right directory.

The expected filenames of the routes? They're expected to be named whatever you want to name them.

And I can give you such a binary but in order to be useful you have to
not run it from hijack, but instead either telnet to the player (assuming telnetd) or connect to the serial port, and run gpsapp by hand, because otherwise the output from printfs doesn't go anywhere useful.

So I added some printf code and ran it by hand on the empeg. It opened *only* the right directory.

May I borrow that and try it?

Warning: very verbose.

Where do the printF's appear? on the serial console or on the empeg screen?

(I'm getting neither with that file...)

Okay, well, going to bed so maybe things will be clearer tomorrow.

Hang on a bit. Define why "fairly new" is important.


Well, not that the routes themselves were new, but that their install location to the empeg was...hence leading to the question of permissions.

I can't think of any other reason why route date would make a difference.

Hijack v307 now connects exec'd programs to the serial console for output (and input!).

-ml

All right, I've got "why" GPSapp isn't working. After Mark released version 307 of Hijack, the error output now properly appears on my serial console.

And what GPSapp is doing, if I understand what it's telling me, is not parsing config.ini right. But I don't know why. I tried reducing the size of config.ini (from 4k to 2k) and it still didn't help.

I get a whole bunch of stuff like this on the serial console:

match routedir inside 0 passed
flag12=Wendy flag 13
flag11=Wendy flag 12
flag10=Wendy flag 11
flag9=Wendy flag 10
flag8=Wendy flag 9
flag7=Wendy flag 8
flag6=Wendy flag 7
flag5=Wendy flag 6
flag4=Wendy flag 5
flag3=Wendy flag 4
flag2=Test Wendy Flag
flag1=Tod Likes
flag0=Jenny Hates

[Options]
Name=Tony's Mark 2

[User Info]
Email=tfabris@oro.net
Phone=
Name=Tony Fabris

[Network]
Gateway=0.0.0.0
Netmask=255.255.255.0
IPAddress=10.99.2.43
DHCP=1

It does this for a bunch of possible parameters, not just routedir. It seems that it's trying to locate the value for "routedir" and instead of finding a nice little path string, it finds most of the rest of config.ini in the string, but NOT the string I carefully put there. Incidentally, I moved
the GPSapp section to the top of my config.ini, like this:

[gpsapp]
routedir=drive0/var/gpsapp/routes
track=false
scale=false

With the Hijack section just below it, in case there was something funky about the parsing of later elements screwing it up, it didn't change the behavior.

Question: You're not reproducing my bug, but are you running the latest hijack and are you running GPSapp his new way?

I can send a copy of my whole config.ini in a private message, if you think that would help.

Oh! Mmm.. I have an idea here..

The point where Hijack EXECs GPSapp is during the first read() call by the player for the config.ini file.

So Hijack has not yet finished parsing config.ini, or applying macros etc..
Which should not affect GPSapp (assuming it's not using AC/DC/.HOME/WORK macros etc..).

But.. perhaps this causes Hijack to muck up when somebody else (GPSapp) reads config.ini at the same time..

I'll look into this ASAP.

I already explained that how you run gpsapp is irrelevant. It still is. It's conceivable new Hijack matters. Send your config.ini anyway.

Well, obviously it doesn't matter now, but I did explain that you needed to not run gpsapp from the kernel and run it either in a shell after telnetting in, or in a shell after connecting to the serial port.

Okay, sent.

I did explain that you needed to not run gpsapp from the kernel and run it either in a shell after telnetting in, or in a shell after connecting to the serial port.

sorry about that.

I'll try doing that now, see if it fixes the bug.

Well, it shouldn't. The point was before Mark did what he did in v307 it would have gotten you the output.

If it fixes the bug I will be sad.

If it fixes the bug I will be sad.

It didn't.

Reason I tried is what Mark said about simultaneous reads of config.ini...

The README doesn't suggest use of any macros.

For kicks, can you run it by hand once, redirecting the output to a file, and send me that?
something like:

ps auxww|grep gpsapp|grep -v grep|awk '{print $2}'|xargs kill
rw
/drive0/var/gpsapp/gpsapp>/usr/tmp/mumble
ro

Arg, I can't right this instant. I'm in the middle of doing three things at once, and my serial port just started mucking up and I'd have to reboot the PC to get it to work again (it does this sometimes).

I will do it as soon as I can.

You don't have the ability to run telnetd from hijack???

Is that built into hijack?

No, no telnetd (or remote SITE EXEC yet) in Hijack.

But v308 is out, and clears up any config.ini conflicts.

Note that at present, config.ini Hijack macros (;@HOME et al) work only for the player app, not for add-ons. I may "fix" this shortly, but for now that's how it works.

EDIT:
No, never mind.. I won't be fixing this. Add-on apps will have to do their own macro equivalents if they need them (dubious).

-ml

Yeah, actually, I agree with your edited sentiment.

Never mind. .. v308 is fscked.

v309 shortly (ugh!)

Yeah, I was gonna say... heh...

I should figure out why the network to my empeg died, so I can be experiencing this fun in real time

No, you install the telnetd binary which I'm sure has been posted here and run it from config.ini. I have your config.ini which proves you know how to run programs and it's just a program...

I should figure out why the network to my empeg died, so I can be experiencing this fun in real time

That was the problem with 308...

I hadn't put 308 on it. The problem was last night I appear to have whacked a network cable while fixing one of the registers on a furance duct.

Youch! Sorry about that. Good luck getting it fixed. (Been there, done that.)

All I did was knock it out of the hub, it's already fixed. The wiring isn't in the ducts. When I bought the house we did it right. The knob and tube electric is gone and the walls got romex, cat 5 and coax in copious quantity.

Ah, that's cool. For my house, the wiring is ad-hoc, whereever I can stuff a cat-5 cable from under the house, and I've cut cables on heating ducts before (sharp edges of aluminum plates etc).

v309 shortly (ugh!)

Hmmmm. Been a while. Uncharacteristically.

I can picture the scene...

Mark's coding away, voice of Significant Other in the background: "MARK!!!! You still haven't taken out the garbage like you said you would!!!!"

"But I'm fixing Hijack!!!"

"NOW, MARK!!!!"

<Mark runs out and does the garbage>

"And what about the dishes?! You said you'd do those yesterday!!"

"But..."

"NOW!"

(Etc...)

And note that I only say that because I'm procrastinating on doing the weekly garbage run myself right now.

(We live so far out in cow-country that we don't even have garbage service and have to actually run it to the dump ourselves.)

No, wait, I've got a better one.

"Mister Mark Lord?"

"Yes, that's me."

"The government of Canada needs you for a top-secret project of utmost importance. The very planet itself is at stake. You're the only person with the skills necessary to do the job."

<20 minutes later>

"Wow, that was quick. Thanks!"

Funny guys..

Okay, got it finally. My notebook is rebuilding it all now for you folks.

Should be about 5mins or so now.

-ml

Actually, it was MUCH BETTER than taking out the garbage, though some people do call it "doing the dishes" or something similar when discussing in front of children..

-ml

Actually, it was MUCH BETTER than taking out the garbage

"MARK!!!! You still haven't rocked my world like you said you would!!!!"

Or even better:

<20 minutes later>

"Wow, that was quick. Thanks!"

Well, it was good for me, so I hope it's good for you, too!

Putting 309 on the player now, thanks.

Do you think this might solve the problem GPSapp is having with parsing the config.ini?

Yes, it should.

If not, then send me that output. I'm going off-network for a while but I'll take the Treo and the cable (and my laptop) with me and "dial in" (not really, and it's better than 56k anyway) after I eat.

It didn't, so I'm going to send you that output now. Do you need it from the regular version of gpsapp, or from the verbose-debug version of gpsapp?

I don't think it worked...

Switching to shell-player loop
Starting bash.
empeg:/empeg/bin# ps auxww|grep gpsapp|grep -v grep|awk '{print $2}'|xargs kill
bash: awk: command not found
bash: xargs: command not found
empeg:/empeg/bin# rw
empeg:/empeg/bin# /drive0/var/gpsapp/gpsapp>/usr/tmp/mumble
bash: /usr/tmp/mumble: No such file or directory
empeg:/empeg/bin# /drive0/var/gpsapp/gpsapp>ro
empeg:/empeg/bin#

Remember, I know nothing about Linux, I need hand-holding...

This line: /drive0/var/gpsapp/gpsapp>ro just ran gpsapp and wrote it's output to a file called "ro".

-ml

/empeg/bin# ps auxww|grep gpsapp|grep -v grep|awk '{print $2}'|xargs kill

The above failes cuz there's no "xargs" or "awk" on the player.

Do it this way instead:

ps eaux|grep -i gpsapp

If that command returns a line or more of output, just take the second value printed and use that value as a parameter for "kill", as in "kill 11"

Then you can restart gpsapp and capture output:

rw
/drive0/var/gpsapp/gpsapp >/mumble
ro

The output is now in /mumble

Actually, an even better way to capture output is to use &> instead of >, as in:

/drive0/var/gpsapp/gpsapp &>/mumble

The difference is that &> catches the error messages and regular output, whereas > by itself only catches the regular output.

-ml

Why yes, it did. Thanks.

Icky thing I typed. I think I meant to have it do something else that didn't work, and I accidentally typed RO there when I didn't know that it was still at the end of the other line.

Still didn't get the output that he wanted me to get, because the other commands failed. The output looked the same as what I reported up above, like this:

match protocol inside 0 passed [gpsapp]
routedir=drive0/var/gpsapp/routes
track=false
scale=false

(Except it lists a huge chunk of config.ini after the word "passed" and then goes onto the next match...)

The regular version doesn't really output anything.

Which it should. I need all the output to tell you anything.

Remember, I know nothing about Linux
After having your empeg for how long, now?

The empeg has taught me that I know only enough about Linux to make me dangerous.

It's actually a good thing, because it allows me to be able to see things from an end-user perspective and be able to straddle the line between "Linux expert" and "Joe Sixpack". So I can make good FAQ entries.

Okay, I'm back for a little while. How do I make those commands work so that I can get you the output you need? I got those errors saying that those commands don't exist. Do you need those commands to make it work? If not, can you give me more instructions on exactly what I should type to *not* induce those errors?

Mark told you what to run. (Which is good, because I don't hand-hold, I ridicule and point people at documentation, which is why I don't do tech support anymore You know what they say, light a man a fire and he's warm for a day, light a man on fire and he's warm for the rest of his life)

Run it and send me the file you create (hopefully not "ro" this time)

And actually if you're using a terminal program that supports capturing a session, you can just run gpsapp from your serial terminal, capture the output, and not bother creating a file (get rid of the rw, ro and the ">/somefile" redirect.

Okay, I ran it and I have the "mumble" file and I'm emailing it to you.

But ARGH, I just found out why I keep having to FSCK...

It's just as I feared. Whenever GPSApp is running, I can't set the hard disk to read-only. At the shell, I did RW, created the Mumble file, and then when I do RO, it says

mount: / is busy

And never sets the drive RO again. This counts even for using the Hijack commands to set things RO again. Nothing ever goes back to RO as long as GPSapp is running. So that's why I keep having to FSCK, because I keep rebooting the player with the root directory in readwrite mode.

How do I kill the GPSapp task so I can set things back again?

Mark also told you how to use ps, and that answer also still applies.

The output indicates it's working:
[serial
set routedir drive0/var/gpsapp/routes (strlen 24)
match visual inside 0 passed [gpsapp]
routedir=drive0/var/gpsapp/routes

the line including "(strlen 24)" says it's correctly parsing the config.ini and setting routedir

from the shell, again, what does

ls -ld /drive0 /drive0/var /drive0/var/gpsapp /drive0/var/gpsapp/routes
give?

I can make another version with different debugging but it's not a config parsing problem.

Ah, that worked. Wish I knew what it was that I did, but it worked. I was able to get the PID of GPSapp and kill it, then RO worked.

Did the file I emailed have the information you needed?

You killed gpsapp (which had open files) and then ro was able to succeed again. You can't unmount or remount a partition which is "busy", e.g. with open files.

The information I needed was there: the config.ini parsing is not at fault.

from the shell, again, what does
ls -ld /drive0 /drive0/var /drive0/var/gpsapp /drive0/var/gpsapp/routes
give?

empeg:/drive0/var/gpsapp# ls -ld /drive0 /drive0/var /drive0/var/gpsapp /drive0/
var/gpsapp/routes
drwxr-xr-x 6 0 0 1024 Jan 26 08:01 /drive0
drwxr-xr-x 6 0 0 1024 Jan 26 08:48 /drive0/var
drwxr-xr-x 3 0 0 1024 Jan 27 01:16 /drive0/var/gpsapp
drwxr-xr-x 2 0 0 1024 Jan 26 07:52 /drive0/var/gpsapp/route
s
empeg:/drive0/var/gpsapp#

Note that the dangling S is just a wrap-around in hyperterminal at 80 columns. The directory really is named "routes".

the line including "(strlen 24)" says it's correctly parsing the config.ini and setting routedir

If you say so. I just don't see any debug output saying "The routedir variable was set to /drive0/var/gpsapp/routes", I only see debug output that's spitting out the entire contents of my config.ini back at me. Since I don't know how the internal code works, I don't know how to interpret that debug output. I don't know what variables it's supposed to be showing me.

I wrote the code, so I know what it's saying. It's showing you the config.ini variable it's looking for a match for, whether or not we were already inside a [gpsapp] section before the chunk we're looking at now, and the chunk we're looking at, which is either the whole file or up to 512 bytes if it's larger than that. The "inside" test is necessary as gpsapp will parse consecutive chunks and remember if it was already inside the [gpsapp] section when it gets into the next section. It will also rewind enough before moving to the next chunk to ensure the [gpsapp] tag wasn't broken into 2 pieces over the chunk boundary.

This new binary will tell you routedir instead of telling you it's "waiting for gps input" in the popup.

Shell output says:

set routedir drive0/var/gpsapp/routes (strlen 24)
GPS app started

And the empeg screen says, clearly:

drive0/var/gpsapp/routes

So it's got the config.ini data just fine, then.

And the folder exists, and it's populated with perfectly good route files. I just copied them from their original locations on /programs0/routes, and also added one new one there since then.

This one has shell output again, when you try to load routes.

Giving that a try now. Before I do, proof that I really do have proper files in that folder:

empeg:/empeg/bin# ls -l /drive0/var/gpsapp/routes
total 16
-rwxr--r-- 1 0 0 3106 Jan 25 19:36 Home_to_Virginia_Way_Hou
se
-rw-r--r-- 1 0 0 2792 Jan 26 04:18 Home_to_Work
-rwxr--r-- 1 0 0 3268 Jan 25 19:36 Virginia_Way_House_to_Ho
me
-rwxr--r-- 1 0 0 1412 Jan 25 19:36 Work_to_Emagic
-rwxr--r-- 1 0 0 826 Jan 25 19:36 Work_to_KFC
-rwxr--r-- 1 0 0 1055 Jan 25 19:36 Work_to_Uptown_Burrito
empeg:/empeg/bin#

This one has shell output again, when you try to load routes.

Okay, I put that file in place, started it from the shell, then exited back into the player app so I could select GPSapp from the Hijack menu:

empeg:/empeg/bin# /drive0/var/gpsapp/gpsapp
empeg:/empeg/bin# GPS app started
exit
logout
Shell exit
Starting player

player.cpp : 385:empeg-car 2.00-rc1 2003/01/15.
Prolux 4 empeg car - 2.1434 Jan 15 2003
Vcb: 0x4054d000
hijack: removed menu entry: "GPSapp"

And I selected "Load Route" from the player's front panel, and it said "no routes found", and I got NOTHING on the serial port. Nothing at all. Only what you see above.

Just for kicks, name one all lowercase with no underscores. I doubt it will change anything but I'm curious about something.

Actually I think I just found the problem.Try this.

Odd, but I guess I don't care, since I think the binary I just sent will fix your problem. Doh.

Okay, changed the name of one file, didn't change behavior. Still "no routes found" and no output on the serial.

Here's the diff corresponding to it.

I just realized I've been building binaries with the debug screen I never finished. Not relevant, but, oops.

Actually I think I just found the problem.Try this.

Okay, yeah, that worked! It's loading routes now!

Enqiring minds want to know: What was it?

Made it open the directory you specified, but not actually open the route files in it. And I kept not seeing it because:
1) I was grepping strace output for the wrong thing
2) I did clean up the old routedir on my empeg, and then kept testing it (with gpsapp_host) on my laptop, where the old directory was still there (as was the new directory) with the same files.

Duh. This is what happens when you do things on several machines at once and aren't concentrating on any of them.

Well, the important thing is it all works now.

THANK YOU ALL!!!!

Well, at least the thing I was debugging on another machine wasn't a fluke also, but sadly that means I still am actively having the problem I'm trying to kill.

It's way too hard trying to simulate something going into I/O wait.