<Jay7>
I see no way to get FTDI-based cable easily
<kristianpaul>
hmm
<kristianpaul>
not locally?
<kristianpaul>
May be wolfspraul can sell you a multi funcional jtag-serial board ;-)
<Jay7>
hehe
<kristianpaul>
I think you can re-use the other cable if you can force it to work at 5v..
<Jay7>
hm.. seems kexec isn't working
<Jay7>
after kernel selection nothing happens
<kristianpaul>
(5v) you can then make an voltage shifter http://ur1.ca/3cpv8
<kristianpaul>
But i recomend that as the last option
<tuxbrain>
no way of make qemu-system-mips work:( ... I will try those recomended by mth tomorrow , .... man I have spend tooo much time trying to have this avr stuff on NN ... tomorrow really is the last chance ....
<Jay7>
tuxbrain: seems native compilation was faster way :\
<kristianpaul>
tuxbrain: why not cross compile? or bad things happen when trying that..?
<kristianpaul>
tuxbrain: btw fedora mips may have som rpm for arduino stuff i think
<kristianpaul>
you can take a look, just in case..
<tuxbrain>
kristianpaul on cross(cross) compilation (aka Canadian compilation) I can't rid of configure check of default name gcc output check and fails
<tuxbrain>
btw if some one see something wrong here let me know :
<GNUtoo|htcdream>
and I wondered what was the differences between them
<kristianpaul>
You mentioned you're interested in Wifi networks debuging, right?
<kristianpaul>
he, you just turned on all your gadgets it seems ;-)
<GNUtoo|htcdream>
lol
<GNUtoo|htcdream>
the dream oomed when lookin at an usrp-nuradio pdf
<kristianpaul>
GNUtoo|htcdream: i think wpwrak is in a "asado", so may take a while to reply
<GNUtoo-n900>
what's that?
<GNUtoo-n900>
and I lack some notification system on SHR...
<GNUtoo-n900>
I think i should add one
<GNUtoo-n900>
kristianpaul, what do you know about gps-sdr?
<kristianpaul>
GNUtoo-n900: wich part exactly?
<GNUtoo-n900>
does it work yet?
<kristianpaul>
GNUtoo-n900: you mean gps-sdr.com ?
<kristianpaul>
or my atemtp og doing gps-sdr on the nanonote?
<GNUtoo-n900>
yes
<GNUtoo-n900>
sdr.com
<kristianpaul>
GNUtoo-n900: it basically read the i/q data from serveral devices as usrp gn3s dongle, and well,correlate the data and give you a fix point, and navigation
<kristianpaul>
It can read from a file, but i really dint get a fix point in that way, a a proper sample file from usrp is kind of big..
<kristianpaul>
(1Gb or so i think)
<GNUtoo-n900>
yes i saw that
<kristianpaul>
I written in C++ and required SIMD..
<GNUtoo-n900>
600M for 1 fix
<kristianpaul>
yup
<kristianpaul>
but
<kristianpaul>
you can cheap and just put a small file, and track just PRN
<kristianpaul>
cheat also using gpredict to catch the gps satellites on the sky at  the time you take the sample
<kristianpaul>
GNUtoo-n900: my focus about a fully sdr process,  is not this gps-sdr.com software
<kristianpaul>
There is one project called osgps.
<GNUtoo-n900>
ok
<kristianpaul>
it worked with an old flahsion acquisition module (PCI bus)
<kristianpaul>
But the code is portable, no SIMD required.
<GNUtoo-n900>
the sparkfun gps stuff need windows anyway....so not usable
<kristianpaul>
gn3s dongle?
<kristianpaul>
no windows !
<GNUtoo-n900>
yes
<kristianpaul>
no no
<GNUtoo-n900>
ah?
<kristianpaul>
that dongle basically re-use the usb comunication module from the USRP
<GNUtoo-n900>
sparkfun comments talked about a windows aquisition program
<kristianpaul>
I mean is a cypress mcu
<GNUtoo-n900>
ah ok
<GNUtoo-n900>
so no windows needed
<kristianpaul>
I mean is a cypress mcu, you can code it with sdcc and sadly it required a pre generated blob froma cypress tool
<GNUtoo-n900>
but the dongle is not cheap.....for a single purpose chip
<kristianpaul>
check osgps code on SF.net they have a driver for that dongle
<kristianpaul>
indeed, no cheap..
<GNUtoo-n900>
i would prefer a gnuradio
<kristianpaul>
of course
<kristianpaul>
ah well that dongle is supported by gps-sdr.com software
<GNUtoo-n900>
you've got that dongle?
<kristianpaul>
nah
<GNUtoo-n900>
ok
<GNUtoo-n900>
I thought as the images sounded similar
<kristianpaul>
i have a EVB from a similar IF chip from sige
<kristianpaul>
no acquisition hardware, just the EVB
<GNUtoo-n900>
what is evb?
<GNUtoo-n900>
devboard?
<GNUtoo-n900>
evaluation board...right
<kristianpaul>
yes
<GNUtoo-n900>
ok
<kristianpaul>
of course sige is not the only ic manufacture for rf fronted, there are more
<wpwrak>
wolfspraul: oh, one more very important news item: now we have statistics in the IRC channel ;-) (!stat !top10 !seen and such)
<wolfspraul>
wpwrak: the length of the upward-pointing usb cable we include with the jtag-serial duaghterboard
<wpwrak>
wolfspraul: what's the issue with the cable ? too long ? too short ?
<wolfspraul>
no issue, it just turns out kristian paul thought for a long time 'cables from sharism are too short', and ew didn't realize
<wpwrak>
aah, i see
<kyak>
i thought "the shorter the more reliable", Moreover, Ben is usually near the laptop, so shortness is good to make it all compact
<kyak>
if i really needed, i could go a buy 5m extension cable
<kyak>
and now, do you really think you can easily find that short USB cables in shops?
<wpwrak>
you can probably find a few different lengths in most well-stocked
<wpwrak>
shops
<wpwrak>
for fancy choices, you can try places like digi-key ;-)
<kyak>
always forgets to put the strongest arguments at the end of the statement
<kyak>
:)
<wpwrak>
those (active, i hope) 5 m extension cables may be potentially troublesome. shorter - passive - ones, too. so think it's good to have a usable cable that comes with the machine. particularly in a case where it's not just the standard mini USB cable. (e.g., micro-usb, angled, and so on)
<wpwrak>
by the way, needing an angled cable sounds like a bit of a design flaw to me ;)
<kyak>
what can i say? i definitely have more than one (or even more than 5) spare mini-USB cables, but i'm using the one shipped with Ben. It's short and compact. Less wires on my table
<wpwrak>
i don't even know which cable i'm using :) i tend to favour slightly longer cables, though, because my pc's front usb socket is the bottom, and my devices are usually on top of a table adjacent to the desk. so that's at least ~70 cm up and ~50 cm to the side. everybody's setup is unique.
<xiangfu>
have 10cm usb cable :)
<wpwrak>
xiangfu: and some people have a very unique setup ;-)
<wpwrak>
aw_: i'm thinking about a production test plan for the wpan boards. when you mass-produce a board, do you normally test the connectivity of capacitors ? (i.e., if they've been properly soldered)
<panda|x201>
xiangfu, wow, good patches for u-boot merge
<xiangfu>
panda|x201: oh. you are in u-boot mailing list :)
<panda|x201>
xiangfu, yeah, I also maintain u-boot for our board
<aw_>
wpwrak, good question; this is depends on if automated program that testing/verifying the functionality of that concerned capacitor!
<xiangfu>
panda|x201: great. then you can help me review our code. and give us some advice.
<aw_>
wpwrak, some test equipment I met/used before. Like ATE system or ICT machine can measure dedicated smd capacitor by probing test points of that concerned capacitor.
<wpwrak>
aw_: atben and atusb have the usual bypass caps around the chips, the two load capacitors for the crystal, and 2-3 DC blocking caps for RF
<wpwrak>
aw_: (test points) ah, so they put extra test points into the layout ? or can the ate "grab" the terminals of the capacitor directly ?
<wpwrak>
aw_: in the case of atben/atusb, some cap malfunctions can be easily detected by a functional test. e.g., if the ones carrying the RF signal aren't connected, the resulting signal will be very weak (although you may still have reception over a short distance). also, if analog bypassing is very bad, then the signal amplitude will change during a packet transmission. this should also be detectable by software.
<aw_>
wpwrak, be noticed (such test points) is all simulated in advance not like you did on atben and atusb. This close knowledge are surely i used before to probe/'grab' the terminals of capacitor directly without supplying power.
<wpwrak>
aw_: if the crystal load caps are unconnected/missing, the frequency will be a little off. about 250 ppm if both caps are missing. haven't measured what happens if only one is connected.
<aw_>
you could imagine that ICT machine is a active multimeter as capacitor measurement.
<wpwrak>
aw_: what is simulated in advance ?
<aw_>
wpwrak, agreed your idea on detecting by a gunctional test. that's the conceipt of ATE machine/industry.
<wpwrak>
aw_: (250 ppm) this may be difficult to detect in a functional test. need to try. you should be able to see the error in the carrier frequency, though (with a spectrum analyzer)
<aw_>
wpwrak, yes, normally 250ppm malfunction which should be recognized on functional test stage if watch out carefully. :-)
<wpwrak>
aw_: there is also one test point for clock output. on atusb, it's very ATE-friendly. on atben, i didn't have enough room, so it's a bit smaller. you can still reach it with a probe, but it may be difficult with pogo pins (at least the kind i have. i've seen a catalog with better ones at openmoko.)
<wpwrak>
i think i'll abuse some of the older board for fault simulation. take a known to be good board (even if a bit different from the current ones), they rip out components and see what happens :)
<wpwrak>
s/they/then/
<aw_>
wpwrak, you don't need to let atben/stusb be as a good design of ATE-friendly or ICT. surely you can see many such knowledges introduced on internet. Unfortunately i didn't involve a responsibility in om.
<tuxbrain_away>
zrafa mth take a look on the line 339 from the config log http://pastebin.com/QMYcSfY7 seems ther is some hardcoded path /mnt/sda6/programas/stuff/tmp/work/i686-mipsel-sdk-linux/gcc-cross-sdk-4.4.2-r2.1/gcc-4.4.2/configure --build=i686-linu [...] this can be the cause of the problem? don't know how to solve it.
<wpwrak>
aw_: yeah, my goal is to have a quick functional tests that finds as many issues as possible. not sure what failure rate to expect for smt there
<aw_>
wpwrak, you could survey ADS (advanced design system) on web for studying simulation. Unfortunately it's not open source /free then.
<wpwrak>
aw_: heh, i think i'll just improvise :)
<aw_>
maybe some other same idea has been discovered out to do same idea on free s/w. don't know. ;-)
<aw_>
wpwrak, i think using a functional test which is good enough...
<wpwrak>
aw_: i mean, the basic principle should be easy enough. remove component, measure what happens, then try to construct an automated test for it.
<aw_>
always will have a potential failure rate during smt!
<wpwrak>
aw_: yeah, just sending a few packets should already tell us a lot. plus a look at the spectrum to see if it's nice and clean
<wpwrak>
(smt) yeah. i just wonder how many things could go wrong there that wouldn't be caught by visual inspection.
<wpwrak>
well, we'll certainly find out :)
<aw_>
when i dealt with Motorola for mass production: there's  a lot of validation system review like your questions on what failures will be? how to prevent?....tons of them.
<aw_>
well...good that you always has have solid precautions, studies before productions. :-)
<wpwrak>
aw_: yeah, it's so much easier to fix a problem before MP than on a few million units afterwards ;-))
<aw_>
such thinking as you is rare and commendable. ;-)
<wpwrak>
thanks ;-)
<aw_>
wpwrak, if u like, later u can survey HP Momentum which is the Simulation of Power Amplifier Bias, Match and Housing Effects.
<aw_>
well..it's CLOSE!
<wpwrak>
sigh. microwave design simulation. how i'd love to have something like that ...
<wpwrak>
since i couldn't find any useful simulation tools, i had to do everything by trial and error :-(
<aw_>
wpwrak, we know. ;-)
<kyak>
xiangfu: yesterday, i tried adding "C" to gmenu2x icons. It looks more than ugly.. What do you think about changing the name instead? E.g. "[c]abook" or "[abook]". This also has an advantage that console apps will be grouped in gmenu2x
<kyak>
since they are sorted by name
<wpwrak>
hmm, interesting. i could actually have made the atben clock accessible to the ben, by putting a ~100k resistor between CLKM (clock output) and SCLK. well, there's not enough room on the pcb to do this easily (i would have to make it quite a bit bigger for this)
<wpwrak>
(or use microvias and place the resistor on the backside, to make production even more fun ;-)
<xiangfu>
kyak: hmm... how you adding "C" got gmenu2x icons?
<xiangfu>
kyak: just found one command: convert -size 32x32 xc:transparent -channel RGBA -blur 0x6 -fill darkred -stroke magenta -draw "text 4,25 'C'" console_c.png
<xiangfu>
can create on C png. then we can merge the console_c.png and icon. I don't know how to merger too pictures.
<kyak>
xiangfu: i was playing manually with gimp so far
<kyak>
tried various options
<xiangfu>
kyak: I think 'ImageMagick' can do this.
<kyak>
it sure can
<kyak>
the first question is what to do :)
<kyak>
all icons are different. It is hard to find a combination of right size/background color/ foreground color and transparency of "C" to match every icon
<wpwrak>
if all else fails, you can use pnmcomp (from netpbm)
<kyak>
convert should know how to merge. But again, the question is what to do, not how to do :)
<xiangfu>
kyak: asking in #imagemagic irc. :)Â Â I think we first test "C" or "Console" first.
<xiangfu>
hope I can get answer soon.
<aw_>
xiangfu, is GPC27 in NN as an input now?
<kyak>
xiangfu: ok, seems you are aimed at adding this letter :) you'll see its ugliness eventually, or, if it looks great somehow, i will be glad
<xiangfu>
aw_: output.
<xiangfu>
aw_: sorry. it's input
<wpwrak>
kyak: you could also try draw a large terminal symbol, shrink the existing icons, and put them inside the terminal.
<kyak>
E<
<aw_>
xiangfu, wow...it's not useful to configure it as output. :-(
<wolfspraul>
maybe a [c] prefix is even easier?
<kyak>
this could work :)
<kyak>
need to see how it looks like.
<kyak>
square brackets could also be a good indication of console app
<wpwrak>
or maybe a different font then ?
<kyak>
wpwrak: or, developing your idea, just to use terminal.png for all console apps :)
<wpwrak>
hehe ;-)
<kyak>
it is also fair because most console apps jsut don't have official icons
<kyak>
different font - won't work without gmenu code midification
<xiangfu>
kyak: all console apps using terminal.png. sound better.
<kyak>
yeah, this sounds good to me, too
<aw_>
xiangfu, later you could try to let it as input, then s/w side to monitor this pin: if detects Low, means NN is in a charge cycle; it's strong pull-down (~10mA) by charge IC itself.
<xiangfu>
aw_: it's input now.
<xiangfu>
aw_: the LED is controlled by hardware.
<aw_>
xiangfu, this is thus led ON. yes...LED is controlled by charge ic itself not s/w.
<aw_>
xiangfu, but as s/w side, surely NN can detect GPC27 to know if it acts in chargin cycle. ;-)
<xiangfu>
kyak: then we will have a lot of terminal.png . like vim, emacs :(
<Jay7>
xiangfu: do you have now other icons for vim/emacs/other console apps?
<kyak>
xiangfu: maybe we can make exception for some of them? But actually, by seeing vim icon people could get wrong impression that they are about to see gvim
<kyak>
maybe we could find a nicer terminal.png, some scale of grey. It won't be so black and eye-catching
<Jay7>
use svg of gnome's one or konsole's one
<Jay7>
to create template
<Jay7>
then just use 24x24 icons to place inside :)
<Jay7>
iirc, you are using 32x32 now
<kyak>
this is what wpwrak suggested
<kyak>
you won't know how it will look like until you try
<Jay7>
kyak: don't ever say me.. I've spent a lot of time trying to choose right icons for kexecboot actions :)
<xiangfu>
Jay7: it's Faenza. from gnome.org. I am using the same in my pc. :)
<Jay7>
I've finished with oxygen
<xiangfu>
aw_: if the changing finished. if the LCD will change?
<aw_>
xiangfu, not follow your meaning. ;-) are you saying that before today I mentioned, NN's GPC27 is output? now changes to input..then s/w side will get that what's happening?
<xiangfu>
aw_: no. I am if the battery is full. the LED will change?  sorry.
<xiangfu>
s/sm/mean
<aw_>
xiangfu, yes, if charge ic acts that as a finished charge on battery. charge ic's CHRG pin will go high impedance so that it lets LED OFF. Meanwhile it's thus GJC27 is as a INPUT high. then s/w should can be realized NN is known as a fully charged.
<xiangfu>
kyak: how about shrink the terminal.png to the left corner of icon. maybe is better then just a "C"
<kyak>
xiangfu: you can try. But i now have a strong feeling it won't work. Due to different icons - it will cause different contrast levels, and will look ugly
<xiangfu>
aw_: ok. understand. thanks
<kyak>
xiangfu: soem screeshots, i made yesterday:
<Jay7>
but you should notice users that apps in [] are console apps :)
<kyak>
yeah, i wonder if they will figure that out
<kyak>
should be obvious, no?
<Jay7>
after 2-3 runs should be :)
<tuxbrain_away>
zrafa mth I have tried to rid off this paths with --with-build-time-tools=/usr/local/jlime-2010.1/mipsel/bin --with-mpfr=/usr/local/jlime-2010.1/mipsel/usr when calling configure  but it didn't help :( the ugly path still there like I have not put nothing
<xiangfu>
as long as we make different with GUI icons.
<kyak>
ah, so you want to change both icons and names?
<xiangfu>
kyak: no. no. I almost give up change icons. it's need too much time.
<kyak>
well, i counted 27 console apps icons :)
<tuxbrain_away>
xiangfu kiak , the idea of [name] looks nice and easy, once we got a user manual we can also clarify in advance but as has been said after start two [names] apps people can figure out it selfs
<xiangfu>
kyak: Jay7 let's start with "[terminal_apps]" the only problem is the GUI apps will always at the end.
<kyak>
xiangfu: i agree. For the gui apps at the end, could we prefix them with a "space"?
<kyak>
to move them up
<tuxbrain_away>
or patch gcc to ignore [] on shorting
<Jay7>
hm.. thats may be problem..
<tuxbrain_away>
sorry gcc->gmenu I kind of obsesed this days
<kyak>
it 's a good point. gui apps must be higher
<kyak>
maybe we should put [] on gui apps? :)
<Jay7>
{}
<kyak>
hehe
<kyak>
Jay7: {[ look pretty much the same on Ben's LCD :)
<Jay7>
other good idea to have some mark in configs that app is console app
<Jay7>
then gmenu2x will add [] automagically
<kyak>
sounds like an extra work :)
<kyak>
but a good idea
<Jay7>
yeah..
<xiangfu>
Jay7: as long as the patch accept by upstream :)
<Jay7>
shouldn't be very hard
<Jay7>
iirc, yesterday we was announced as upstream ;)
<Jay7>
should look into gmenu2x code one time :)
<kyak>
hm, i wonder if we can use one of utf-8's square brackets. Not the ascii one
<Jay7>
may be there is something good for kexecboot
<Jay7>
or vice versa
<kyak>
Jay7: i heard that gmenu2x's code is am awefull piece of shit. Besides, it's using SDL
<kyak>
as far as i know, are drawing directly to FB :)
<kyak>
*you are
<Jay7>
yes, we are..
<Jay7>
have some kind of own UI library already..
<kyak>
Jay7: but what you should look into sometime is the new openwrt image :)
<kyak>
you'll like it!
<Jay7>
kyak: yeah, I should :)
<Jay7>
I should spend more time to playing with NN anyway
<Jay7>
at least to find why kexec is not happens
<Jay7>
ah.. I should make nice pics for news :)
<kyak>
Jay7: what is the flow with kexecboot? Is it u-boot -> uImage+kexecboot+kexec-tools (the boot menu) -> uImage ?
<Jay7>
interface is working ok
<Jay7>
but when I choose image to boot (kexec) it freeze
<Jay7>
I suspect kexec-tools vs uImage
<kyak>
is kexecboot kind of a small layer between u-boot and the uImage you want to boot?
<Jay7>
yes, just kernel + initramfs + kexecboot binary, which is UI to select partition and run kexec on choosen kernel image
<kyak>
so kexec must also be present in this small image?
<Jay7>
yes, we have it inside initramfs
<Jay7>
both (kexecboot and kexec) are compiled with klibc
<Jay7>
but you may run kexecboot as standalone binary as well
<tuxbrain_away>
wpwrak: maybe I start to understand the aversion of the "autocrap club" to GNU building system...
<Jay7>
this way I will try to debug it
<kyak>
running it as binary is similar to supplying command-line arguments to kexec?
<Jay7>
with UI :)
<kyak>
sure :)
<kyak>
ok, it's inetersting to give it a try
<Jay7>
you may port it to openwrt ;)
<kyak>
yes, i had a look into OE recipy for kexecboot - shouldn't be very hard
<Jay7>
but currently we have no recent tarball release
<Jay7>
we are using git versions to build for OE
<kyak>
yeah, saw that
<Jay7>
is it ok for OpenWRT?
<kyak>
sure
<Jay7>
nice :)
<kyak>
ok, dinner time :)
<tuxbrain_away>
Jay7: can I suggest that that menu only comes up with a certain power+letter combination? if not let NN boot on a default kernel/rootfs
<Jay7>
tuxbrain_away: it is possible but should be implemented :)
<tuxbrain_away>
Jay7: whatever , the idea of finally a multibooting system on NN is cool :)
<Jay7>
I hope one time I'll extend it to make nfs/loop boot possible as well
<Jay7>
at least I have this in long-term todo
<xiangfu>
tuxbrain_away: already support in new u-boot. POWER + F1/2/3/4
<xiangfu>
POWER + F1/F2/F3/F4/m, we have five now :) and we can change it in user space by using fw_setenv
<tuxbrain_away>
xiangfu: I didn't notice this,! what correspondacies are
<xiangfu>
tuxbrain_away: by default F1/2/3 . I setup them to sd-card partition 1/2/3
<xiangfu>
F4 will try to load the kernel inside rootfs.
<tuxbrain_away>
xiangfu:f1/2/3 share same kernel?
<tuxbrain_away>
mmmm or share same rootfs?
<xiangfu>
tuxbrain_away: no.
<xiangfu>
tuxbrain_away: F1/2/3 will load kernel at sd card partition 1/2/3Â Â /boot/uImage
<tuxbrain_away>
ok f4 = Nand+rootfs kernel
<xiangfu>
yes.
<tuxbrain_away>
f1/2/3 sd+sdrootfs kenel cool
<tuxbrain_away>
so I can have Nanowar edition/jlime beta4/jlime devel and openwrt in same device :)
<xiangfu>
yes.
<xiangfu>
dinner time :)
<tuxbrain_away>
any one with a debian rootfs in sd?
<tuxbrain_away>
please any one with building knowledge that can help me on the crossbuild of crossbuilding tools will be appreciated? zrafa maybe you have to regenerate the toolchain with corrected paths the only solution?
<mth>
tuxbrain_away: what if you remove the jlime tools dir from your PATH?
<mth>
it seems mipsel-linux-gcc has problems compiling a small test program that does nothing special
<mth>
I don't know if GCC will build the compiler that runs on x86_64 and produces mipsel code automatically if it is not found
<mth>
it is also possible it will just abort then
<tuxbrain_away>
fuck
<tuxbrain_away>
it pass
<tuxbrain_away>
lets see how it compiles :P
<Jay7>
tuxbrain_away: so you have your canadian cross now? :)
<tuxbrain_away>
lets see...
<tuxbrain_away>
I'm near to cry.... it's compiling.... it's DAMN compiling.... AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGH!
<tuxbrain_away>
fuck
<Jay7>
tuxbrain_away: only 2 days of wasted your and CPU time :)
<tuxbrain_away>
mipsel-linux-ar: Program not found :(
<tuxbrain_away>
is actual stamping his head on the keyboqjwlefpqoeuv qqopwieyamvñ apoqhppnf
<Jay7>
well.. may be 3 then :)
<tuxbrain_away>
so I guess I have to create a mipsel-linux toolchain  first?
<xMff>
yes
<xMff>
a working one :)
<tuxbrain_away>
:_(
<xMff>
did you try to locate the libmpfr.so in your current broken one?
<tuxbrain_away>
yes it's there...
<xMff>
I cannot imagine someone just forgot to package it up
<tuxbrain_away>
I even make a ls -s and create that path but it didn't found it if I pont to the toolchain it sais wrong ELF something if I point to my buildinghost (/usr)
<xMff>
you mean /mnt/sda6/programas/stuff/tmp/staging/i686-linux/usr ?
<tuxbrain_away>
yep
<kristianpaul>
wpwrak: (cable) yes
<xMff>
and which mpfr.so did you put there?
<xMff>
there may be several, one for the target (mips binary) and one for the host (ix86)
<tuxbrain_away>
all them
<tuxbrain_away>
same result
<xMff>
thats bad
<xMff>
did you try to install mpfr on your host? My ubuntu calls it "libmpfr1ldbl"
<kristianpaul>
wpwrak: (cable setup) uniquite indeed, actually i think your PC setup is similar to what i have here too
<Jay7>
kyak: can you try to kexec' that kernel by hands?
<kyak>
Jay7: it did something to my keyboard (repeat rate has changed) and the ethernet gadget driver is not working :) i had to reboot
<kyak>
nope
<Jay7>
ah, yes.. it changes keyboard rate
<kyak>
i mean, yeah, i can try :) but haven't tried yet
<Jay7>
I should make it configurable as well
<kyak>
why would it change the repeat rate?
<Jay7>
it was unusable on Z's
<Jay7>
I'll switch it off for stand-alone mode
<kyak>
Jay7: hm, when using kexec directly, should i mount the partition?
<Jay7>
yes
<Jay7>
kexec -l /mnt/boot/uImage
<Jay7>
kexec -x -e
<Jay7>
iirc
<kyak>
root@ben:~# kexec -l /card/boot/uImage
<kyak>
Cannot determine the file type of /card/boot/uImage
<Jay7>
:\
<kyak>
# file /card/boot/uImage
<kyak>
/card/boot/uImage: u-boot/PPCBoot image
<Jay7>
seems kexec-tools have no support of uImage..
<kyak>
yeah..
<Jay7>
but we have tried to boot uImage on arm
<kyak>
need to have a look at kexec-tools makefile
<Jay7>
and it was ok
<Jay7>
iirc, from 2.0.x there was support of uImage
<kyak>
PKG_VERSION:=2.0.1
<Jay7>
have you zImage or vmlinux.bin somewhere?
<tuxbrain_away>
zrafa : nop from qi-hardware
<wolfspraul>
dvdk: I don't think anybody has such plans at the moment.
<wolfspraul>
The closest would be Tuxbrain, but Berlin is quite a trip for him and I think he said something about it being too expensive, and hackable devices also not attending? something like that
<kyak>
Jay7: have both of them
<Jay7>
kyak: try with zImage then
<Jay7>
I mean kexec -l
<kyak>
hm, exactly the same message
<Jay7>
:(
<kyak>
/boot/zImage: ACB archive data
<Jay7>
have your kernel CONFIG_KEXEC=y?
<kyak>
i hope it's the right zImage i found..
<kyak>
# CONFIG_KEXEC is not set
<Jay7>
hehe
<kyak>
is it it?
<Jay7>
it seems
<kyak>
lemme correct this
<kyak>
any other relevant options?
<Jay7>
iirc, no
<kyak>
Jay7: when being in a kernel with CONFIG_KEXEC, can i boot into another kernel that doesn't have CONFIG_KEXEC?
<Jay7>
kyak: imho, yes
<Jay7>
but not 100% sure :)
<kyak>
ok, we'll se :)
<tuxbrain_away>
zrafa: confirmed I was using the qi-hardware one
<zrafa>
tuxbrain_away: okey.. and you are having problems with configure of avr tools right?
<tuxbrain_away>
zrafa: yep
<zrafa>
tuxbrain_away: have you the proper PATHS in environment setup.. have you ran ". /blabla/environment-setup" before ./configure?
<tuxbrain_away>
zrafa: yep, I have installed the toolchain in /usr/local/
<tuxbrain_away>
(well) tar -xjz on /
<zrafa>
okey.. and did you run ". /blabla/environmentsetup" before configure?
<tuxbrain_away>
yep , checked that $PATH contains the blablabla mipsel/blabla/bin
<kyak>
Jay7: hm. i booted into the new kernel, tried to kexec the /card/uboot/uImage, /boot/uImage (the one i'm booted in), /boot/zImage - same result
<tuxbrain_away>
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
<tuxbrain_away>
I think I have found the trick :)
<zrafa>
tuxbrain_away: can you try this? :Â Â - use another shell without the environment-setup ran. Just set the PATH var manually using this way : export PATH=$PATH:/usr/local/jlime-2010.1/mipsel/bin/
<zrafa>
tuxbrain_away: and then run : ./configure --host=mipsel-linux ?
<zrafa>
ah.. okey :)
<tuxbrain_away>
.\configure without your enviroment
<zrafa>
tuxbrain_away: let me know if your trick is working. Maybe is not a trick
<tuxbrain_away>
then make with enviroment set up
<tuxbrain_away>
now is building
<zrafa>
tuxbrain_away: hehe .. no sure if that would work. In fact I am suggesting set PATH and run configure without the toolchain environment.. but with --host at least
<zrafa>
tuxbrain_away: but if you are seeing that it is using the toolchain to build .. great ;)
<zrafa>
tuxbrain_away: some time it is just okey setting PATH manually (so shell can find the mipsel-linux-* binaries and running the configure with --host
<zrafa>
tuxbrain_away: and for kernel environment setup is not needed neither.. just make with ARCH and CROSS_COMPILE.
<tuxbrain_away>
I run configure with the build host target config, so Makefile is generate to crosscompile, then I setup the toolchain variables to buid... binutils compiled :)
<tuxbrain_away>
next gcc
<zrafa>
wow fast
<tuxbrain_away>
yeah confirmed the trick is to \configure without the enviroment variables and build with enviroment variables
<tuxbrain_away>
gcc is happily Canadian crosscompiling
<zrafa>
he ;)
<tuxbrain_away>
ups error on make install?
<tuxbrain_away>
/usr/bin/install: no se puede efectuar `stat' sobre «build/fix-header»: No existe el fichero o el directorio
<tuxbrain_away>
but avr-gcc seems in place so I will take is as valid....
<GNUtoo|laptop>
wpwrak, hi, kristianpaul told me that you knew the USRP,I wondered what was the difference between all the models, are there stuff that you can't do with lower end models, like 80211g debugging?
<wpwrak>
GNUtoo|laptop: there are basically three generations: USRP1, USRP2, and the N2xx series
<GNUtoo|laptop>
what about N1xxx that has an omap inside?
<GNUtoo|laptop>
oops
<GNUtoo|laptop>
I meant E100
<wpwrak>
GNUtoo|laptop: usrp1 uses USB, the others use gigabit ethernet. N2xx and USRP2 are quite similar.
<GNUtoo|laptop>
ah ok, I know for usrp1 vs usrp2 but not for the others
<wpwrak>
GNUtoo|laptop: ah, the embedded thingy. yes, that exists too, but seems to be a lot less powerful. consider that you have to do the numbercrunching on that slow CPU and not on your PC
<GNUtoo|laptop>
usb2 is too slow for some stuff like 80211
<GNUtoo|laptop>
ah ok ouch
<GNUtoo|laptop>
armv7 with neon vs core i7.....
<wpwrak>
GNUtoo|laptop: yup :) so the real choices are only USRP2 and N2xx, where USRP2 is nearing EOL, with N2xx as the replacement
<GNUtoo|laptop>
core i7 is way faster...
<wpwrak>
(alas, it's also more expensive than the USRP2)
<GNUtoo|laptop>
ok
<wpwrak>
yeah, your PC will run circles around anything embedded ;-)
<GNUtoo|laptop>
and between N210 and N200?
<wpwrak>
hmm, need to check ...
<tuxbrain_away>
with tears in his eyes looks at console seeing avr-tools finally completed....
<GNUtoo|laptop>
tuxbrain_away, avr-tools in oe?
<tuxbrain_away>
not GNUtoo|laptop manually crosscompiled
<wpwrak>
GNUtoo|laptop: oky, that's easy: there is no N200 device ;-) N200 is the series, N210 its first member
<tuxbrain_away>
I will let others to do such distro integration
<wpwrak>
M_Rojas: good morning ! :)
<M_Rojas>
Good morning :-)
<tuxbrain_away>
if my tar.gz works , for me is far than enough... I have wasted a looooot of time on this, I can afford waste more.
<tuxbrain_away>
call me coward if you want :P surelly I am
<xiangfu>
kyak: I can reproduce the 'flite' issue. [flite  -t "hello world" a.wav && aplay  a.wav] is better then just [flite  -t "hello world"]
<xiangfu>
kyak: in release 2011-02-23
<kyak>
xiangfu: good :) seems we have the same problem then
<wpwrak>
GNUtoo|laptop: then you have to choose carefully which RF daughterboards you want. e.g., which frequency range, and so on
<wpwrak>
GNUtoo|laptop: also, some can do full-duplex while others can't
<GNUtoo|laptop>
bascally I don't have the money yet
<GNUtoo|laptop>
but I wanted to know how much I needed to save...
<GNUtoo|laptop>
and was curious also
<GNUtoo|laptop>
I bet I will also need to work for radioham licenses
<wpwrak>
GNUtoo|laptop: you'll need about USD 2200. and if you don't have RF items in your lab yet (adapters, antennas, cables), then expect to spend a few more hundred USD on these. RF stuff is expensive :-(
<GNUtoo|laptop>
ok
<GNUtoo|laptop>
Basically if I can find a good job this summer, it may accelerate the savings
<wpwrak>
GNUtoo|laptop: (license) as long as you keep your emissions low enough, nobody will notice ;-) also, you may be able to avoid going over the air
<wpwrak>
GNUtoo|laptop: an influx of money always helps :)
<tuxbrain_away>
now I have to follow the avrdude tutos of wpwrak and pack also the Arduino libs to have the full basic package to start ot think in a front end for all this (well I will start with a Makefile and tutorial :P)
<wpwrak>
wolfspraul: quite  a lot of stuff this months, eh ? ;-)
<wpwrak>
s/months/month/
<wolfspraul>
tuxbrain_away: can you reply to David's idea about linuxtag on the list?
<wolfspraul>
I think you said nobody would go, bearstech also won't.
<wolfspraul>
I'm not sure what David plans or how we could support him.
<wolfspraul>
the 'other' David :-)
<wolfspraul>
wpwrak: I hope it's still readable.
<wolfspraul>
I kept with a simple layout so it's easy to browse/glance over it
<tuxbrain_away>
wolfspraul: will check the list and see what can we do
<kyak>
jow_laptop: nice hint.. need to check it from build logs..
<wolfspraul>
but the uart board has an uart ic on it, no?
<wolfspraul>
that is not actually needed?
<tuxbrain_away>
GNUtoo|laptop: need the wpwrak patch
<M_Rojas>
wpwrak: about the picture, thanks! :-D
<GNUtoo|laptop>
just qdd it in oe
<wpwrak>
GNUtoo|laptop: you need the driver for the nanonote's GPIOs
<GNUtoo|laptop>
ahh ok
<jow_laptop>
kyak: #ifdef CST_AUDIO_LINUX defaults to oss and there's an explicit #ifdef CST_AUDIO_ALSA
<tuxbrain_away>
yes maybe I will add that patch to the receipt and build , but it's  on alpha but workable state
<wpwrak>
wolfspraul: the UART board has just an ATmega48. i use the in-circuit programming signals also for communication with the ben, so there's no need for an extra programming cable
<jow_laptop>
uhm, where's flite hosted? cannot find it in the qi repo
<kyak>
jow_laptop: seems it can be fixed with --with-audio=ALSA,,,
<wpwrak>
GNUtoo|laptop: also, for atusb, you need an entry for the ATmega32U2 in avrdude.conf
<GNUtoo|laptop>
ok
<wpwrak>
GNUtoo|laptop: there are still a few loose ends, e.g., for programming the UART board with the "real" firmware (right now, i just have a trivial led-blinking thingy), you'll need to supply a clock. the driver doesn't do that yet. once all this is done, i'll send the patches upstream and things should trickle down after a while
<kyak>
jow_laptop: seems that it's in openwrt feeds
<kyak>
not in qi-;s
<jow_laptop>
oh :)
<kyak>
yeah, i was surprised , to :))
<jow_laptop>
yeah... --with-audio="oss"
<jow_laptop>
I think this explains it
<kyak>
hehe
<kyak>
so. can we rely on you to fix it? :)
<xiangfu>
kyak: oh. then why I can not reprocude the error in 2010-12-14. because I am using my port version which is 1.4. and don't have those configures.
<tuxbrain_away>
wow reflash.sh has a progress bar :) (as you might guess) I have not use it for long time :), may be I will do a fork with a distro selector : 1)Qi, 2)jlime 3)debian? 4)librewrt?
<kyak>
hm.. first of all, seems that i misunderstood the kexec utility. Does it mean to be used in two commands?
<xMff>
apparently
<xMff>
the first one sets up the env
<xMff>
and the -e executes it
<kyak>
interesting. i need to experiment more..
<kyak>
for now i see the "Bye..."
<kyak>
and then all hangs
<xMff>
heh
<rjeffries>
wpwrak: is the following list comprehensive
<rjeffries>
wpwrak BEN 8:10 port UBB (no electronics, simple extension of signals so a ribbon cable can be attached)
<rjeffries>
wpwrak 2) atBen 8:10 card with 802.15.4 radio and (later) 6LoWPAN protocol stack)
<rjeffries>
wpwrak 3) ??? UART implemented with AVR chip, 8:10 card for Ben ???
<rjeffries>
4) atUSB 802.15.4 radio on USB stick for Linux PC
<rjeffries>
end of list. ;))
<rjeffries>
tuxbrain_away 's work to get AVR tools working on Ben NN should yied significant new interest and Ben sales
<tuxbrain_away>
rjeffries: after the hell of fustration I have passed (basically for my ignorance on the matter) I hope you where true, I hope in a week or so I have a easy to use enviroment (console based) with some examples to attack(sorry attract) Arduino lovers. of course if all work as expected. Once with this base we can start to think on a graphical onekeypress arduino frontend as his java big brother but thinked to fit on NN
<tuxbrain_away>
regarding the list, I will rise one pos the atUSB and down the UART.
<zrafa>
tuxbrain_away: what should the arduino GUI on nn do?
<tuxbrain_away>
load/save/edit/compile/upload scketches , and a SPI console to send/recieve messages from/to Arduino
<tuxbrain_away>
also containing examples, and select the destination (board/atmega)
<rjeffries>
tuxbrain_away GUI would be nice, but a good design console program with that functionality would be ok/fine
<tuxbrain_away>
rjeffries: I have in mind to clone the look and feel of the caracteristic arduino env to make beguinners feel familiar with it, the pro can directly edit the make file or even piss off on Arduino API
<tuxbrain_away>
from here multiple items on todo list... integrate this tools on OpenWrt & OE, finish and upstream avrdude patches, make demos interacting with gnuplot , and send keypresses to Arduino  to demostrate interaction with platform beyond pure compilation, and of course the gui
<tuxbrain_away>
so due there is an quite presentable todo list, I was thinking to aglutinate them all on a ardunote project which have the aim on make NN the perfect portable Atmega related front end... focused on Arduino but taking advantage that is attacks directly to SPIÂ Â instead of serial we an use chips directly without need of board at all.
<tuxbrain_away>
wpwrak: how many free gpios has UBB if is used to flash a atmega chip? due the free gpios can be used as some kind of proves to test in/outs of the chip to cheeck the uploaded program ...
<tuxbrain_away>
well in fact once flashed you can use the 6 gpios as some what of digital analizer.... so a cronogram in gui can be also usefull for the pros :)
<tuxbrain_away>
but again ... as Wolfsaid let focus... and step by step
<kyak>
xMff: could it be that vmlinux.elf and uImage have different entry points?
<kyak>
i boot into uImage, as usual, and then kexec vmlinux.elf (cause kexec only know elf-mips)
<xMff>
kyak: maybe
<kyak>
it call the new kernel at some address..
<kyak>
"Will call new kernel at 00014350" and then "Bye ..."
<kyak>
this is basically what's described in the bug report and in forum
<kyak>
but i'm sure i applied the patch...
<kyak>
the kernel command line is taken from the current kernel
<xMff>
kyak: I know very little about kexec myself, I need to research it first
<Jay7>
is in doubt wrt adding kexecboot port to news page
<Jay7>
we have kexecboot ported and working but we have no working kexec :)
<kyak>
yeah
<Jay7>
but we have nice screenshots ;)
<kyak>
Entry point 0x80014350
<kyak>
this is said by readelf -l /boot/vmlinux.elf
<kyak>
but it kexec tries to boto from address 0x00014350
<kyak>
the problem??
<Jay7>
may be
<tuxbrain_away>
I miss those package in openwrt  gcc gcc-symlinks cpp g++ g++-symlinks binutils binutils-symlinks linux-libc-headers-dev libc6-dev autoconf make libz-dev libz1 perl perl-dev perl-modules tcl tcl-dev python-modules distcc coreutils
<kyak>
"miss"?
<tuxbrain_away>
sorry this is all I try to install this is what I miss Unknown package 'gcc'.
<tuxbrain_away>
Unknown package 'gcc-symlinks'.
<tuxbrain_away>
Unknown package 'cpp'.
<tuxbrain_away>
Unknown package 'g++'.
<tuxbrain_away>
Unknown package 'g++-symlinks'.
<kyak>
first of all, there are no *dev packages, as i know.
<kyak>
for the others, you should opkg update and opkg list |grep for what you need
<kyak>
if you need development files, you'll copy it from your build tree.
<xMff>
kyak: the kexec manpage states hat kexec does shutdown if -f is not given
<xMff>
kyak: maybe this causes issues on the NN
<kyak>
xMff: kexec -l -f /boot/vmlinux.elf has the same effect - it all hangs
<kyak>
so i added 023-mips-fix-kexec.patch and removed 931-crashlog.patch
<kyak>
building now..
<xMff>
it is not included?
<xMff>
023 I mean
<kyak>
nope
<xMff>
was added 11 months ago
<kyak>
023 is not backported
<xMff>
ah
<xMff>
I assumed this is already done :)
<kyak>
hm, good idea.. maybe there are other patches for 2.6.32, which are not backported yet.?
<xMff>
probably but I doubt there are that many which would affect kexec
<kyak>
right
<kyak>
xMff: i see no changes
<xMff>
kyak: :(
<tuxbrain_away>
I think I had break somthing trying to install bin-utils... reflashing
<tuxbrain_away>
a question: sure there is a wise reason but why isn't dev packages part of the repositories?
<tuxbrain_away>
on openwrt
<wpwrak>
tuxbrain_away: you "lose" one signal for reset (if you support the in-circuit programming interface and don't do the "trapdoor" change of reset as gpio)
<kyak>
xMff: thanks for support anyway! Someone from #kexecboot suggested using 2.6.37. Do you think it would hlep?
<wpwrak>
tuxbrain_away: with the rest, you're free to do as you please. for spi, you need four signals: sclk, mosi, miso, and also nSS
<xMff>
kyak: certainly worth a try
<xMff>
tuxbrain_away: due to openwrts history, it always was made for devices that cannot host a toolchain, therfore very little effort was put into making such dev packages
<tuxbrain_away>
xMff: roger
<kyak>
xMff: guess i will wait for that openwrt release in May, when we catch up with the latest trunk and therefore the kernel
<xMff>
tuxbrain_away: do you try to install gcc etc. on openwrt?
<xMff>
*on NN
<tuxbrain_away>
I'm trying to get as close as my own previous devian tutorial to compile and flash to NN, so the only reference to have a building system using opkg was the jlime one, but it fails miserably on openwrt
<tuxbrain_away>
debian (my apologizes to all debianites)
<xMff>
I don't know this tutorial, is there a link somewhere?
<tuxbrain_away>
but re reading the Arduino Makefile template, I thing only my toolchain is needed
<xMff>
are there major obstacles with compilation of the avr toolchain?
<xMff>
if not, it should be easy to package it so it can be compiled like a regular package for openwrt
<tuxbrain_away>
I have some strange problem on make install part of the gcc
<tuxbrain_away>
it miss a file during the proccess but the build goes fine.
<xMff>
hm ok
<tuxbrain_away>
xMff:Â Â if you do this you will have my eternal gratitude and hate in same qty: love due will sweet the rest of the "ardunote" project , and hate due if you have done tree days before you had save me (an part of this community due my annoyance ) a tree days of headaches :P
<xMff>
I'll give it a try
<tuxbrain_away>
wpwrak: I have to start to decipher your messages sooner than later,  due the moment to apply their content is becoming very near... :P, when you mean the reset, you mean to reserve one signal to do what I done manually when I work with NN serial... to push reset just before trying to upload,  isn't it?
<kyak>
xMff: your queue must be sooo long by now :)
<tuxbrain_away>
this include some patches to reduce bin size and include lastest atmega chips (like atmega2560)
<xMff>
are those patches required to compile the toolchain or are they just optimizations?
<tuxbrain_away>
don't know... I just a howto follower, the 90% of time I don't know what I'm really doing
<xMff>
:)
<xMff>
okay, I'll try my luck with vanilla stuff first
<tuxbrain_away>
atleast try to use same versions :) then we can apply patches and we can detect if some one breaks the thing
<wpwrak>
tuxbrain_away: to hold the avr in reset during programming
<tuxbrain_away>
wpwrak: roger due I will not mess with you insight of the black magick you are doing on avrdude, your words are dogma for me. one gpio reserved for reset :)
<wpwrak>
tuxbrain_away: it's actually not so much avrdude magic ;-) if you look at the "serial programming algorithm" under "memory programming" in about any avr data sheet, you'll find the protocol there
<wpwrak>
tuxbrain_away: you basically have to hold reset low while programming. you could this with an external switch, of course. e.g., a reset button. but it's nicer if everything con be controlled from the ben.
<tuxbrain_away>
wpwrak: I agree, this will give even a more near "arduinic" experience :)
<tuxbrain_away>
the need of presing reset manually has being removed since USB Duemilanove
<wpwrak>
tuxbrain_away: what's not so nice is that this means that you have only one gpio left after reset and spi. that one could be used for avr-to-ben interrupts or for a ben-to-avr clock.
<wpwrak>
tuxbrain_away: alas, if you need both, things will get messy
<wpwrak>
tuxbrain_away: (2009) wow, you had to do that ? how rustic
<tuxbrain_away>
but you only need this while programing isn't it?
<wpwrak>
tuxbrain_away: the reset ? yes
<tuxbrain_away>
and Arduino boards had their own clocl
<tuxbrain_away>
clock
<wpwrak>
(own clock) good. then you can have interrupts :)
<tuxbrain_away>
mmmmmm...... I guess the following tellme if I'm wrong... I guess it will be better while programing  use ben-clock so then we can program arduino board or a nude atmega chip. but while runing if is an arduino board use the arduino clock, talking from absolutly ignorace
<tuxbrain_away>
those thinkg is what I want to contron from a gui selecting target.
<tuxbrain_away>
the gui can also have the wiring schema to work with that target.
<tuxbrain_away>
well time to time flash finished let's try again
<wpwrak>
tuxbrain_away: your avr only needs a clock from the ben during programming if it doesn't have a clock of its own. this can happen if you set the fuses to, say, extrnal clock or crystal but you only have the internal oscillators
<wpwrak>
tuxbrain_away: mosr avrs come with the fuses set to the internal clock, so that's fine then
<wpwrak>
rjeffries: (list of projects) correct. uart still needs a better name ;-)
<tuxbrain_away>
attty
<tuxbrain_away>
atben, atusb, attty
<tuxbrain_away>
the last openwrt image is an amazing step forward in the soft part.... intuitive, good looking and full of apps.. jlime guys hurry up due the Openwrt has taking you advantage :)
<dvdk>
hi
<dvdk>
just testing jo-philipp's patches to emacs, libggi, gforth, octave, plplot and going to commit soon.  just letting you know to prevent any collisions on commit :)
<zrafa>
tuxbrain_away: hurry : ;-)).. Nah, jlime has already apps users want. When nn users becomes 10.000 surely they will ask for new applications. There we can do more work ;) For now, Blizzard is doing the proper work to do.. merging ideas to OE.
<zrafa>
we can do more work= we can work another week more :P
<tuxbrain_away>
zrafa:just kidding :) both jlime an openwrt have make gigantic steps in estethic and usability great work dudes
<xMff>
hmm, where should such an avr toolchain be placed? /usr/local/avr ?
<tuxbrain_away>
xMff, nice place :)
<xMff>
local sounds stupid if its a package anyway, so I guess just /usr/avr is okay
<tuxbrain_away>
also ok
<tuxbrain_away>
at the end the avr toolchain is setup on Makefile
<tuxbrain_away>
do you know if gnuplot can draw on line data?
<zrafa>
tuxbrain_away: btw, B_Lizzard has some ideas for some new stuff using a new toolkit as well (we were thinking to do a new widgets kit just for jornadas and nn). Maybe we do something on that land as well
<B_Lizzard>
Well, it would be nice if I had anything to show
<B_Lizzard>
We should work on some specs, zrafa
<B_Lizzard>
Define the file-format for the parser, function interfaces etc
<zrafa>
tuxbrain_away: and like you know he has "that" thing with drugs.. and I have with drinks... so the real work takes time :D
<B_Lizzard>
ITS A HERB NOT A DRUG
<B_Lizzard>
*gets stoned*
<zrafa>
B_Lizzard: specs: yes, you are right. I will be next week moved, so we can continue ;)
<B_Lizzard>
OK
<B_Lizzard>
See ya tomorrow then
<tuxbrain_away>
XD  B_Lizzard sat yes, if it comes from ground it can't  be so bad  is some kind of vegetable :P
<tuxbrain_away>
I suggest to change the worm icon.. I feel very dissapointed waiting for some kind of port of worms!, but well disappoint disapears after first hundred score :P
<kristianpaul>
tuxbrain_away: yeah,new icons may cause some random feelings
<kristianpaul>
tuxbrain_away: he, you get caught at the end, thats important !
<tuxbrain_away>
yeah is the clear example of  " bah what a silly game, I will catch one more number and I let it go" on a while 1=1 bucle :P