Log from #neuros IRC channel

that's the C "we let you shoot your feet" philosophy ;)

well, you can use gdbserver

i wrote a page about it in wiki

ok. never tried it. I think I would not have found it for a long time without valgrind

[02:44]

sourcerror: these bugs can be tricky, but i'm not very fond of valgrind. maybe i'm not just able to use it properly

[02:44]

now I'm convinced I have to make sure I can always run in some form on the host

[02:45]

I'm no expert at valgrind. it just has always pointed to my first sin of using uninitialized memory which usually is the culprit.

[02:46]

sourcerror: often that is also spotted as early as gcc (at least i've been sometimes warned of using uninitialized pointers)

[02:46]

plus just being careful ;)

[02:47]

yea, the trouble here was that I first malloc'd the space for the structure that I was writing into so compiler wouldn't help me.

[02:48]

I could have saved myself If I wrapped malloc with a debug mode that zeros the malloc'd memory. that's probably what I'll do now.

[02:49]

good luck :)

[02:51]

I"m working on my plugin API as for an alternative 'osdmain'. my approach is to split osdmain into a base and top. the base provides an api to load plug-ins which register themselves into the top menu structures.

[02:52]

at any point or just an "applications" menu ?

[02:53]

I'm working towards any point. each "screen" will have a symbolic name and you can register into "list screens".

[02:53]

for example the first menu will be something like "main" screen and you can register your entry into the list.

[02:54]

the idea is that much of osdmain functionality can even be a plugin

[02:55]

so far there are these types of screens... LIST, CONFIG, CUSTOM. list is the regular simple list where you either invoke an action or push another screen. I'm working on a meta screen format which can handle all kinds of configs so that we don't have to...

[02:56]

have all these custom config screens you see in the current osdmain.

[02:56]

then custom can be anything similar to what osdmain does for all screens now.

[02:59]

config screen are a good idea, especially since the current ones are a mess

[03:00]

just be sure to check that some have extra bits of checks or do stuff on the data before saving it, so be sure to allow that frexibility

[03:00]

yea. the idea is just create a structure of data types and pointers to where you want the data to go and the special config screen draws it, manages it and writes the data.

[03:01]

although it's easy to go overboard and overengineer this stuff, so beware

[03:02]

yep. the config data types is an enum and the structure is a union so I'm starting with a few types and we can add more.

[03:02]

* TankC is away: Sleep

[03:03]

well my next task is to implement one config screen, one plugin, and the list screen type so I can have something to show before moving on.

[03:03]

to more features.

[03:04]

sourcerror: seems good stuff. just be sure to make it as little cooler-specific as you can. given all the recent talk about cooler we might end up replacing it after all sometimes down the road

[03:05]

I still have not resolved the i18n stuff but I now have copied the API exactly for a few functions and can read a *.po file at runtime (not the .mo binary format)

[03:06]

hmm, maybe put the stuff you use to test the .mo up somewhere so someone else can try to figure it out

[03:06]

if you can get hang of a server admin, you can ask for a hacker/sourcerror svn repo, so you can stash your code in there

[03:06]

yes. I haven't given up on it.

[03:07]

I was wondering about svn. unfortunately, I'm old school CVS and haven't learned svn.

[03:08]

there's a guide on the svn tutorial for people coming from cvs. it's really really simple. at least for basic add, commit, update stuff it's pretty similar to cvs

[03:09]

a couple hours at most and you get the hang of it

[03:10]

by the way, I think I have a good rewrite of the watchdog kicker code and I wrote some shutdown hook code so that parts of the app just register a shutdown hook. I think the current osdmain way of handling shtudown was flawed.

[03:11]

what was wrong with current watchdog code (except the fact it's horribly annoying) ?

[03:12]

...my shutdown hook code catches the signals and calls any registered shutdown hook. so for example, the watchdog kicker registers itself and osdmain registers a hook to disconnect from nms

[03:12]

so anyone that needs action at shutdown registers themselves and osdmain doesn't know anything about it as it should only care about what it is doing.

[03:13]

I don't think it was actually thread safe. I think you could actually exit before the watchdog kicker wrote the special 'V' to appease the watchdog

[03:13]

oh, that is a good idea. making stuff more modular is always a good idea. but i thought there was some real problem, in the sense of bug, that's why i asked

[03:14]

yea. I should look at it again, now I don't remember the corner case that I thought of.

[03:14]

...I just have my rewrite of it now :)

[03:15]

well, when you have it, be sure to post a patch to the ML. it's a good thing, and we can try to make sure someone at neuros reviews and applies it

[03:16]

yea, the issue is now that the watchdog kicker calls into to register a shutdown hook if it is successful at starting so they have to accept the idea of a modular shutdown hook to take my patch too :)

[03:17]

it's ok. unless it adds tons of code and is hard to maintain it should not be a problem to accept that, i think

[03:19]

it is not tons of code just 2 'pages' each. oh yea, one other thing... I wrote logging code too because the debug printouts they use were annoying. it has mutliple levels similar to log4j but very simplified.

[03:19]

...also just 1 page of code.

[03:20]

oh, good idea, even though many of the prints are from nano-x it seems

[03:21]

I'll do a pastebin on several of the files... brb

[03:25]

sorry, be back in a while

[03:26]

here is logging: pastebin.ca

[03:31]

here is shutdown hooks: pastebin.ca

[03:36]

here is watchdog (kickdog) rewrite: pastebin.ca

[03:40]

nerochiaro: no problem. I have to go to sleep myself. if you get a chance to look at it let me know if you see any problems or I'm heading off course.

[03:46]

nerochiaro: ah, now I think I remember what was wrong with the kickdog code. because of the extra thread created by kickdog this interacts with the shutdown hook as written for current osdmain and you end up calling it twice from both threads which caused a race condition.

[03:48]

the race condition might not have mattered but in any case I didn't like hte idea that it was so messy. the code I wrote keeps track of its thread ID so that it only invokes the shutdown on a "primary" thread that owns shutting down.

[03:49]

also the kickdog thread I believe should have used mutexes so I added mutex around the critical section where it shares the file number.

[04:21]

sourcerror: i have not looked at your code, but i recall the shutdown routines get called more than one time in current osmain. no errors, but yeah, not pretty either

[04:21]

turran: were you looking for me ?

[04:50]

yep =)

[04:52]

the thing is that i need two things, build a web server (cross compile it) and install it.

[04:52]

an the second thing build an application to record from a webcam

[04:52]

at different frame rates, etc

[04:53]

ok, the second thing can be more complicated, the first one shouldn't be hard. which web server do you have in mind ?

anyone, (small of course), just need static web pages.

so to crosscompile i need the neuros-osd toolchain

turran: we already have a web server that works on the osd, it's written in lua so not even need to compile anything. to serve static pages should be perfectly fine

brb

[04:55]

ok :)

[04:57]

turran: so let's say the web server is ok ?

[04:57]

as for the webcam, i suppose it's an USB webcam ?

yep, ok =)

wait wait :)

yes ?

how do i upload files? i can do it over nfs, with a compact flash and through the ui, etc

which files ? the web pages that the server should serve ?

yes, for example, or my application, etc.

but i can't connect to the telenet/nfs server, in fact when booting, the osd doesnt sets a correct ip

192.168.0.100 with gw 192.168.1.1, telnet/nfs server 192.168.0.64

or something like this

well, the easiest way is to boot off of the flash and then have your apps on a media card or usb disk

but if you want to fix tftp/nfs, let's see

ok, so still use the ui (osdmain)?

you need to stop uboot and setup some env variables

indeed

when doping a printenv i saw them

doping/doing

:)

it shouldn't be hard to go with nts/tftp if you want

[05:02]

now, which values should the env variables should have? i mean, there are env variables like ip= and ntfs_server= , etc

[05:02]

what variables are useful for the servers? ip configuration?

the ones that matter for you are serverip, nfs_serverip, rootfs_nfs_loc and kernel_loc, i think

ok, ill try to change them

:)

first is the ip of your PC, second is the same as first, and the others should be the path to the nfs shared rootfs, and kernel_loc is the path to get the kernel via tftp

[05:05]

ok, let's say you get these right, or you choose to boot via flash and put your apps on a media card

[05:05]

ok

[05:06]

what about running my app? the osdmain enables a watchdog is it possible to stop it without rebooting? stopping the watchdog?

[05:06]

you can setup the osd to never even start osdmain

perfect =)

how?

1 sec

ok =)

/etc/init.d/rcS, the last line in that file is the runlevel. 5 will start osdmain, 3 will not

[05:09]

you need to boot via nfs to be able to change that, though (in the future i think it will also be made changeable without requiring nfs mount)

[05:10]

ok, great

[05:10]

now about the application itself

or you can just let osdmain start and then shut it down with CTRL+C or the equivalent signal

ok, on to the app

yep, but it will reboot on a couple of seconds because of the watchdog, ill ttry the nfs mount

i guess the apps needs the neuros api to do the work i want right?

open.neurostechnology.com

no, if you kill it with -9 the wdog won't stop, but with the graceful termination signal the wdog will get stopped

[05:12]

ok

[05:12]

i made the ^C and it didnt stop

anyway the app

:)

brb

strange, it stops ok here. maybe you're on a very old version of the firmware ?

[05:13]

anyway

[05:13]

you need the media API if you want to encode or decode video, yes

[05:14]

however the problem here is also the source of such video, which is the web cam. how does that connect to the OSD ? USB or it has video out ?

[05:22]

back

[05:22]

it has a video out, is independent from the osd

[05:23]

ah, great

[05:23]

so in fact the cam isnt a problem, in the application just need to feed the video from "video in"

[05:24]

now in case my firmware is old, is there a quick guide on how to do update it?

[05:24]

i downloaded the neuros_osd.tar.bz

[05:24]

and did a ./build-helper.sh all under neuros-bsp

[05:28]

ok, one step back. "firmware" here can mean 2 things. one is the firmware that resides in flash, and includes uboot+kernel+rootfs. it comes in .upk packages that you get from official releases on the neuros site. then if you're a developer you can also do what you did and build from source, and that will allow you to create a new kernel and rootfs that you can customize and use with nfs+tftp. so the suggestion is: first update to the latest

[05:29]

ok perfect

[05:29]

yes, first the stable thing, then my custom

[05:29]

to build from source, what you did is ok, but before running the build helper, use svn to update your source to a known good "TAG"

[05:30]

ok

[05:30]

yes, the stable thing is always useful, first because of uboot updates and second because if you want to use it only via flash for some reason, you're already ok

[05:30]

brb

[05:33]

ok, the next step to update it is?

[05:34]

[05:34]

these are the official updates

[05:35]

great, once i have an .upk file?

[05:37]

there are instructions on that release pages. in a nutshell, there are 2 ways: if you just want the latest one, osdmain in the settings menu has an option that will download it. or you can put that upk in a media card under /newpackage/r3.up, plug in the media card and reboot, then follow upgrade on tv screen

er, the osdmain option will download and install it

great :)

about the lua web server you told me

open.neurostechnology.com

is it already included on the rootfs?

[05:39]

no. lua is included, the server is not, but it's pretty easy to use from media card, once you update the firmware in flash

[05:39]

[05:40]

jejeje prefect man, thanks :)

[05:41]

:)

[05:42]

try updating the osd and try the web server first, then if all goes well we can move on the the capture app. simple things first :D

[05:42]

indeed =) =)

[06:00]

* nerochiaro is out for luch, see you in an hour or so

[06:19]

can anyone help me with crwebs VM?

[06:41]

brb

[06:56]

Shadow12: give me 20 mins an i try to help

[07:04]

uh

[07:04]

whats the command to restarting wntworking devices?

[07:05]

depends on your distro i think. should be /etc/init.d/vmware restart on debian-like

[07:10]

its running on windos

[07:10]

its just when i try to sudo it asks for password and I dont know the admin password for the neuros vm

[07:11]

its the same password you already use for your username

[07:11]

"neuros2"

[07:12]

indeed =)

[07:12]

nerochiaro, ok i upgrade my firmware, it now works good when doing a ^C to osdmain, the watchdog no longer reboots

the networking is also working great

yeah, you probably had an ancient version on the device

=)

now i need to mount it over nfs, but i remember on the other firmware there was nfsstat, etc. on this there isnt

really I will try again

turran: nfsstat ? what do you mean ?

thanks guys

Shadow12: no problem

nerochiaro, does this new firmware has a nfs daemon to export the fs?

[07:15]

it's the other way around. you export the rootfs from an nfs server that is on your PC

[07:15]

ahhh =)

[07:15]

jejeje ok

[07:16]

where did you download the tarball for the neuros dev environment that you mentioned above ?

[07:16]

like, 2 hours ago

[07:17]

mmm let me check the log

[07:17]

from here: svn.neurostechnology.com

[07:21]

i don't know how old is that,so for good measure do an svn update on that after you unpack it

ok :)

nerochiaro, ping

oi

:)

i tried the nfs thing, but have problems mounting my nfs share from neuros

[09:09]

looks like there is no portmap on the osd

[09:09]

which problems do you have ?

portmap: server localhost not responding, timed out

RPC: failed to contact portmap (errno -5).

on the osd there is no portmap

the share on my pc is working ok, as i can mount it from other place

[09:11]

are you trying to mount it manually or you talking about mounting as rootfs ?

[09:11]

manually, with mount share_ip:share_dir dest_dir

[09:16]

try using -o nolock,udp

[09:19]

or even better -o nolock,tcp,nfsvers=3

[09:22]

well nfsvers=2 instead of 3 did the work =)

[09:23]

depends on your nfs server probably

[09:23]

what are you mounting with nfs ?

[09:24]

my home dir, i want to copy the necessary files for the webserver

[09:24]

ok

[09:28]

um, wait, copy where ?

[09:29]

jejeje i was to ask the same :)

[09:29]

the / is ro (cramfs)

[09:30]

i wanted to copy it under /usr/local/ as the install-kepler.sh does

[09:30]

but i guess this isnt the way

[09:30]

so i should make my own .upk with the kepler thing inside, and then upgrade the firmware again, right?

[09:39]

ok, wait. step back. you have 2 choices here. one is to have the rootfs on you PC and mount it during boot via NFS. that means you have a rw / instead of a ro / and you can go crazy and do whatever you want with it. the other option is using a media card and unionfs. basically when hotplug mounts the card, if you have on the card a dir called osdroot, that dir will be mounted rw over /usr/local

[09:42]

ok, interesting thing

2nd is quicker to try

this should be on the wiki right? =)

so what is the quickest way to test the webserver?

tup

er, yup

the 2nd way is the quickest

the one using a media card and unionfs

ok, i'll try it out

[09:45]

and i the nfs method is surely on the wiki, the unionfs, i'm not sure. i made them add it, but no one basically used it besides me, so i don't think anyone has ever documented it on wiki.

nerochiaro, everything worked ok

cool, so the web server is ok ?

yeah but looking on the cgilua looks they don't support shell scripts, only lua based ones

:/

well, obviously

what web server allows you to have bash scripts ?

boa/apache/etc etc

=)

i just need to do: "echo something > /tmp/mypipe" on the script

ill figure it out with lua

at least i didnt have to crosscompile :)

yeah, i mean, i've never seen these used in any real-life situation. they either go with php or perl, never bash. anyway, i'm sure there's a way in lua to call shell stuff

now the application =)

i need to run away for half an hour, right now

ok, np man!

=)

when i'm back we can see to that

later

later :)

[11:41]

nerochiaro, got to go home, we'll talk tomorrow, thanks for your help :)

[12:18]

<keRa>

hello

[12:18]

<keRa>

there is any way to use .srt subtitles with OSD ?

[12:49]

keRa: not at the moment i think

[13:09]

so will scratchbox allow me to run the osd's user interface on my computer?

[13:42]

shaunm: nope

[14:52]

I guess you'd typically use svn through the vm if needed?

[14:59]

svn to do what ?

[15:00]

well, I guess I'm thinking about two scenarios

[15:00]

svn to download new code, branches whatever and build

[15:00]

and two I'm thinking about svn for docs like this user manual we discussed.

[15:03]

the vm is used to build 3rd part apps on top of pre-built neuros libraries. it's not geneally meant to be used to build the code that is in neuros main svn (bsp, cooler etc).

<sourcerror-m>

but JoeyBorn can still put hte docs under version control

<sourcerror-m>

just not necessary to check out inside VM

yeah, that was a separate question though