Log from #neuros IRC channel

it's a funny thing: even though apple uses the same hardware as the other mfrs, I've had much better performance and reliability since I switched to the apple router.

[21:03]

it's not like they have any special hardware in theirs that isn't in a linksys.

[21:03]

but it works so much better.

[21:03]

/weird

[21:05]

<MP0>

I got much better reliability after I stuck linux on my lintshit router. It was amazing... the stock vmworks firmware locked up every once in a while. Linux is solid.

[21:05]

<MP0>

thank the heavens for DD-WRT

[21:05]

<crweb>

vmarks: its firmware. I have the same results with Buffalo

[21:06]

<crweb>

When linksys switched to that other firmware/OS stability went major down hill

[21:06]

<crweb>

Verlix i think its called?

[21:07]

<MP0>

That was such a bad move for them to make... all to save what? Flash chips?

[21:07]

<crweb>

no, save ram

[21:07]

<crweb>

well, and flash chips i guess

[21:09]

* MP0 shakes his head in disgust... even though it's something the company I work for would probably do.

[21:14]

vxworks?

[21:14]

<crweb>

dd-wrt proves they didn't have to switch anything

[21:14]

I had a very very early buffalo.

[21:14]

300 dollars worth of 802.11b.

[21:15]

<crweb>

hell,dd-wrt interface is way better than the default 8mb linksys version

[21:15]

<crweb>

and the mini version is what .. 3mb

[21:15]

<MattJ>

crweb: and it's magically come back...

[21:15]

<MattJ>

(access to my server)

[21:18]

<crweb>

nice

[21:20]

<MattJ>

crweb: Can you give some pointers on what I need to do to interface with the AZ scheduler?

[21:23]

<crweb>

the app has to be written to take cmdline commands and convert them to neuros-qt-libs/neux/copchannel/nappchannel.h

[21:24]

<crweb>

it would be a console based Qt app. fairly simple. Maybe you can get a community dev to do it? Someone was messing around with Qt code lately can't remember who

[21:24]

<crweb>

ah, greyback

[21:25]

<crweb>

i bet he would be more than happy to contrib

[21:25]

<MattJ>

I'll look at it

[21:25]

* MattJ clears some diskspace and svn up's

[21:26]

<MattJ>

Where is neuros-qt-libs?

[21:27]

<MattJ>

Oh, got it

[21:32]

<MattJ>

crweb: Right, those commands seem to be generic, rather than just for the scheduler?

[21:33]

<crweb>

oh shoot

[21:33]

<crweb>

sorry, wrong one

[21:33]

<crweb>

thats the window manager ;)

[21:33]

<MattJ>

Heh :)

[21:36]

<MattJ>

scheduler/plugins/shellcommandscheduleplugin/ ?

[21:37]

<crweb>

plugins/interface

[21:37]

<crweb>

no dang it

[21:37]

<crweb>

I can't remember!

[21:37]

<crweb>

oh simple

[21:38]

<crweb>

the QCop spec is at the top of the scheduler header. scheduler/src/scheduler.h

[21:38]

<MattJ>

Aha

[21:38]

<crweb>

that spec is exactly what the GUI uses to communicate with scheduler

[21:39]

<crweb>

now, communication with the scheduler plugins is different also

[21:39]

<crweb>

but probably won't be needed by you

[21:39]

<MattJ>

A scheduler plugin is? Something that can handle schedule events?

[21:39]

<crweb>

correct

[21:40]

<crweb>

recorderplugin handles recorder events, updater plugin handles upgrade events, etc

[21:40]

<crweb>

the plugin follows the plugin interface file and it can do anything it wants

[21:40]

<crweb>

scheduler only conflict manages and fires events and cares nothing else

[21:47]

<MattJ>

QCOP is new to me... it looks like I just need to create a QcopChannel object, and use that

[21:47]

<MattJ>

So the scheduler has a QCop channel name?

[21:47]

<crweb>

no you don't even need to do that

[21:48]

<crweb>

oh wait

[21:48]

<crweb>

yes yes.

[21:48]

<crweb>

you create a QCopChannel channel; Then attach it to a slot for the received signal

[21:48]

<MattJ>

or rather I want to use send()?

[21:48]

<crweb>

when a message is received, you look up the message and take action

[21:49]

<crweb>

you need both

[21:49]

<MattJ>

To get the result?

[21:49]

<crweb>

send requires no object. the object/receive to get the result

[21:49]

<MattJ>

Ah, ok

[21:50]

<MattJ>

The scheduler has a QCOP channel name? (I can't see it in the header file)

[21:51]

<MattJ>

Ah

[21:51]

<crweb>

heh.. odd the details i missed...

[21:51]

<MattJ>

It's in the constructor

[21:51]

<crweb>

its all in the .cpp file

[21:57]

<MattJ>

I think I'll make a Lua module

[21:57]

<MattJ>

It avoids the evil shell escaping I would have to do otherwise, and makes things a lot neater

[21:58]

<crweb>

i don't know how to connect lua to the channels

[21:58]

<MattJ>

Can always make an executable out of it for the sh peope

[21:58]

<MattJ>

*people

[21:58]

<crweb>

but maybe you can find the qt4 lua module

[21:58]

<MattJ>

I looked at that, I might see if it will work without modification

[21:59]

<MattJ>

But I think it is easier for me to write my own for the scheduler

[22:01]

<MattJ>

Hmm, is there a scratchbox VM for AZ about, or not finished yet?

[22:02]

<crweb>

well.. its still the same.. I'm not really sure what to do about it..

[22:02]

<crweb>

qt already has an awesome cross compile setup

[22:02]

<MattJ>

I haven't worked that out yet :)

[22:03]

<crweb>

type, source neuros-env

[22:03]

<crweb>

nqmake

[22:03]

<crweb>

this handles all aspects of a qt project

[22:03]

<crweb>

and will automatically compile it for AZ

[22:03]

<MattJ>

So nqmake is an equivalent of qmake, but for Neuros?

[22:04]

<crweb>

its an alias to neuros-bsp/toolchain/Qtopia/bin/qmake

[22:04]

<MattJ>

Aha, gotcha

[22:04]

<MattJ>

Should be simple then

[22:04]

<crweb>

everything else is handled automatically

[22:05]

<crweb>

via qt .pro files

[22:05]

<crweb>

it is a cross-platform toolkit, so the designed it very well to do this

[22:05]

<MattJ>

Except I need to produce a .so, is there some magic flag for that? (I have only ever used Qt in executables)

[22:06]

<crweb>

TARGET = <name>

[22:06]

<crweb>

TEMPLATE = lib

[22:06]

<MattJ>

Right, thanks

[22:09]

<MattJ>

Is QCOP used in many other places?

[22:10]

<MattJ>

I'm thinking maybe I should go the whole way and write just a generic QCOP module, if it is

[22:12]

<crweb>

its used everywhere yes

[22:12]

<crweb>

WM, scheduler, screensaver, etc

[22:12]

<MattJ>

Wow

[22:12]

<MattJ>

That settles it then :)

[22:13]

<MattJ>

er, wow, I have a .so :)

[22:31]

<crweb>

i guess the upside to being the only patch manager on duty is that.. I get to review my own patches and ok them...

[22:31]

<MattJ>

lol

[22:31]

<crweb>

which, is also the down side...

[23:34]

<MattJ>

crweb: are QStrings the only type used as parameters?