Log from #neuros IRC channel

<MattJ>

It means another patch to dokuwiki

I was just about to ask if it was all written in lua

:)

<MattJ>

It was going to be :)

<MattJ>

Then I realised I simply didn't have time

[09:52]

<MattJ>

Despite the fact that having it in Lua would have cut down on the time I spend fighting with PHP

[09:53]

<MattJ>

Grr, this is mad

[09:53]

<MattJ>

A few more requests and it stops working again

[09:54]

<MattJ>

and it seems I am the only person with this problem

[09:54]

fine for me

[09:55]

<MattJ>

Starting to suspect my browser... wget appears to work

[11:52]

crweb: you there?

[11:53]

is the updater for AZ working properly now?

[13:35]

<crweb>

JoeBorn: I'm at the moment not really sure what is up with the updater. I'm 100% dedicated to the NTSC/PAL bug

[13:36]

<crweb>

JoeBorn: there is still a few issues that I'm unclear about. Like, TORFU 9.0 "upgrade" automatically force a user to AZ

[13:36]

<crweb>

or will we leave room for a TORFU 9.1. So TORFU "upgrade" looks for new torfu's and user must actualy click upgrade to AZ

[13:36]

ok, well nevermind then, I'll figure it out.

[13:37]

<crweb>

I know we don't want to think about a TORFU 9.1, and we don't want one. Reality is though, there is always that one last little bug that a community member could fix

[13:37]

<crweb>

i'd hate to see us just flat out block the whole TORFU line. Even if unsupported now

[13:39]

I'd rather have more specialized users on the more manual upgrade path

[13:39]

and more mainstream users on the more automatic path

[13:39]

so I think making the automatic path to AZ makes sense.

[13:43]

<crweb>

i dunno... if we didn't have external requirements that would make sense. However, if everytime a user boots and it says "please upgrade to AZ" "oh wait you can't no CF card" thats going to get annoying. I would think it would be better for the auto upgrade path to exist and a user phsycially choose the switch so they know everything involved.

[13:44]

<crweb>

there will be a 9.1 and a torfu user would expect to beable to upgrade to it.

[13:44]

<crweb>

it may not be by us, it is open source. If community put together a 9.1 we should support them.

[13:48]

<MattJ_>

It won't be me :P

[13:48]

<MattJ_>

I'll be glad to see the back of it :)

[16:00]

crweb: yeah, I'm not sure the nuex has much love for it in the community

[16:01]

I think it's more important to make sure more of our users come along on the QT journey

[16:01]

if we make them manually upgrade, we'll be leaving them behind, at least many of them.

[16:02]

<gremlin[it]>

hi JoeBorn, crweb

[16:02]

gremlin[it]: greetings

[16:30]

hi

[16:30]

<[g2]>

hi

[16:57]

MattJ: you there?

[16:59]

<MattJ>

JoeBorn: I am

[16:59]

do you know anything about this widescreen issue?

[17:00]

<MattJ>

JoeBorn: I don't, I have only 4:3

[17:01]

ok.

[17:01]

<MattJ>

All I can say is that 4:3 works fine :)

[17:39]

JoeBorn, what is the widescreen issue?

[17:43]

vmarks: well, check out the mailling list more recent postings

[17:44]

which mailing list? I'm only subbed to one.

[17:44]

<crweb>

uhh.. i think that i just ported osd to gcc 4

crweb: sorry?

<MattJ>

crweb: Oooh :)

[17:44]

<crweb>

i was just messing around and got gcc4 to work

<crweb>

kernel won't build cause ingenient did a lot of stupid crap

<MattJ>

I was about to say, don't you have some binary modules?

<crweb>

like specifying arm926ej-s when it already exists as arm926ejs

<MattJ>

or you have the source to those at Neuros?

<crweb>

no i have to patch gcc to do arm926ej-s

<crweb>

or change every instance to the real value in source

<crweb>

freaking dumb.

<crweb>

MattJ i have the source.

<MattJ>

:)

<crweb>

dunno if it will compile yet though

[17:49]

<crweb>

why would they do that..

[17:49]

<crweb>

the only patch they made in gcc and glibc is adding the string arm926ejs

[17:50]

<crweb>

it already had arm926ej-s...

[17:58]

Spammer on the Wiki: wiki.neurostechnology.com

[18:36]

crweb: sorry for being nosey, am just curious as to what "shellcommandscheduleplugin" is supposed to do. It looks like it just executes /usr/local/bin/shellcommand. This sounds a bit cron-ish :)

[18:36]

<crweb>

that is what it does yes

<crweb>

it runs that command, at specified time..

Shellcommand then does...?

<crweb>

or do you mean it litterally runs /usr/local/bin/shellcommand ?

that's what it looks like to me

[18:38]

<crweb>

well... gaaaahhhhhhh...

<crweb>

no its correct

<crweb>

Shellcommand is a QProcess object

<crweb>

Shellcommand.execute(SHELLCOMMAND_PATH) is the application that runs

<crweb>

which is stored in the db's data field

Hmm, I saw #define SHELLCOMMAND_PATH "/usr/local/bin/shellcommand" and figured it just ran that

<crweb>

i didn't see that...

in the header file

<crweb>

are you freaking kidding me..

[18:41]

lost in translation? :)

[18:41]

<crweb>

wtf...

[18:41]

* crweb holds head in neuros shame and walks away

[18:42]

* greyback beckons crweb back, offers shot of vodka

<crweb>

ok, great news

<crweb>

now a few things need to happen.

Also, while I'm noticing stuff, "libhelptexts" are being placed in /usr/local/bin by mistake

<crweb>

first, report this on the ML

<crweb>

each problem you find, report on ML. quote code that you see.

ok

<crweb>

this is prime example of how opening up patch review will help us

<crweb>

so.. might as well up the bar and show them we mean it

[18:46]

<crweb>

bug reports stay a little to internal. business folk can't really see those

[18:46]

<crweb>

and we are going to be moving patch review to another read-only list, and users can comment on patches in main list

[18:47]

<crweb>

business folk don't really get to see the contributions, so this will bring to light user contributions :)

[18:47]

Sounds good

[18:49]

<crweb>

i personally don't think some hold the weight of user contribs high enough..

[18:49]

<crweb>

i mean like theres doubt how much community will really do

[18:49]

<crweb>

but, its being overlook that nero and I were _from_ the community.

<crweb>

AND, i just compiled the kernel with gcc4

<crweb>

had to rewrite a few ingenient drivers though..

<crweb>

pain in the ass

<crweb>

nobody had regards for C90 and C99

<crweb>

and gcc4 is very strict

[18:53]

<crweb>

*holy freaking cow i just rewrote a driver!*

[18:53]

fuck yeah, well done.

<crweb>

theres no way ingenient's closed stuff is going to build with gcc4...

With luck, there's be more interest if the Dev process is opened up just a bit more

<crweb>

might have to do a kernel+imedia with gcc3, then everything with gcc4

<crweb>

greyback: thats what we are saying

<crweb>

it takes a very specific interest to get involved _right now_

[18:55]

<crweb>

like, braking osd main into smaller apps.. or making boot scripts correct

[18:55]

I agree, there's many small things that can be done, and as time goes on, that person can take on bigger things

[18:56]

But it's hard to see exactly what there is to be done at the moment. You need to be around for a while to see the bits worth trying

[18:57]

Oh, while I've got you, do ye have gdbserver working for the OSD? webkit is segfaulting on me:(

[18:58]

<crweb>

i don't no.

[18:58]

<crweb>

last time i even saw it mentioned was nero in 2006 saying he tried it but hated it

[19:01]

I don't know how you code so much without one

[19:14]

<crweb>

i dunno...

[19:15]

<crweb>

i rarely need one for gui programming..

[19:15]

<MattJ>

I agree, the whole point of open-source is community involvement, and I don't think the OSD is/was hackable enough for people to get started

[19:15]

<MattJ>

(replying to crweb some messages up)

[19:22]

night all!

[19:25]

<MattJ>

crweb: Is qApp some magic global that all Qt apps have?

[19:54]

<crweb>

MattJ yes it is some sort of magic

[19:56]

<MattJ>

crweb: Thanks, I guessed it must be. Guess nobody told them that globals are evil :)

<crweb>

its not a global

<crweb>

think of it more as a parent of all classes

<crweb>

its a member of QObject i believe

<MattJ>

Ah, hmm

[19:59]

<MattJ>

I guess the code I saw then was wrong

[19:59]

<crweb>

ok nvrmind

<crweb>

its a global pointer to the unique application object

<crweb>

its the same as QApplication::instance()

<MattJ>

Ah

<crweb>

its a Macro

[20:04]

<crweb>

hah.. almost got the firmware built with gcc4

[20:04]

<MattJ>

Nice

[20:10]

<crweb>

yeah, ingenients closed framework is definitely not compat with gcc4

[20:11]

<crweb>

implicit declaration of function EVERYWHERE

[20:11]

<MattJ>

Part of their master plan? :)

<crweb>

no just <insert bad word here> developers

<MattJ>

lazy? :)

<crweb>

no wonder theyd on't want to open it

<MattJ>

lol

<crweb>

its not to protect data. nobody would buy it if they saw it

[20:13]

<MattJ>

Someone would probably fork it

[20:13]

<crweb>

it just needs thrown away... really

[20:16]

<crweb>

oh my gosh.. its working!

[20:16]

<MattJ>

:o

[20:16]

<crweb>

holy crap

[20:17]

<crweb>

one last build-helper.sh all, and I'll beable to boot

[20:20]

<crweb>

had to turn off warnings are errors though

[20:43]

<crweb>

I have to give it to them. There was only one gcc4 non compatible section of code Xiamen wrote.

[20:43]

<MattJ>

:)

[20:43]

<crweb>

the rest was ingenient

<crweb>

there is one error that hits us over and over. but after googling, most developers feel this shouldn't even be a warning

<crweb>

char * pointer doesn't match assigned signedness

<MattJ>

You managed to patch up ingenient's, or?