<wpwrak>
tomorrow. fedex didn't feel like leaving the warmth of their station today, it seems
<wpwrak>
if i'm lucky, it'll arrive together with something i've ordered from digi-key. one day less of twiddling my thumbs.
<wolfspraul>
oh I see
<wolfspraul>
Adam finished 20 boards fix2 -> fix2b
<wolfspraul>
plus the one that caused a problem (0x4D)
<wolfspraul>
another 26 fix2 -> fix2b to go
<wolfspraul>
so there was a total of 204 render cycles, one failed
<wpwrak>
so the plan is to finish the fix2b rework first ? then go though the fallout ?
<wolfspraul>
I leave it to Adam, I don't want to kick him around all the time.
<wolfspraul>
I think he feels better first finishing that batch, yes.
<wpwrak>
okay. just want to know for my own planning.
<wolfspraul>
yes. so if he does that, all of today will be fix2->fix2b.
<wolfspraul>
and part of tomorrow. he calculates with a rate of 15 / day.
<wolfspraul>
xiangfu: you there? should we get the new flterm with logging to Adam?
<wolfspraul>
it could save him a little effort
<wolfspraul>
what does he have to do? build flterm from source? how did he get the flterm binary he is using right now?
<xiangfu>
wolfspraul, yes.  we should get new flterm to Adam.
<xiangfu>
he build th flterm from source.
<xiangfu>
all he do is 'git pull' and make again.
<wolfspraul>
ok that's easy
<wolfspraul>
let's see whether we can sneak it in :-)
<wolfspraul>
and then he needs a new command line?
<xiangfu>
yes.
<xiangfu>
now he is manually input 'flterm --port /dev/ttyUSB0 --kernel boot.bin', needs to add '--log m1.log'
<xiangfu>
I guess
<xiangfu>
wolfspraul, by the way I am uploading the Xilinx folder and license files to buildhost. it's myabe needs 2 days to finish upload. then let's see it it work out of tar ball :)
<xiangfu>
s/it it/if it
<wolfspraul>
ok good [xilinx]
<wolfspraul>
does the --log option append to the log file? or overwrite it?
<xiangfu>
append
<wolfspraul>
ah yes, just saw a+
<wolfspraul>
ok, then he will probably do "--log m1rc3_0x57.log" or so
<wolfspraul>
very good
<wolfspraul>
I think it will help him a little
<xiangfu>
yes
<wolfspraul>
aw: hi good morning! :-)
<aw>
wolfspraul, good morning.
<wolfspraul>
xiangfu: let's help Adam get the new flterm...
<aw>
xiangfu not here
<xiangfu>
here :)
<xiangfu>
is jumping :)
<wolfspraul>
aw: do you remember where the flterm sources are? (in your folder structure)
<wolfspraul>
you need to 'cd' to that folder, then 'git pull' then 'make' (I think)
<xiangfu>
aw you can run 'which flterm'
<aw>
xiangfu, /usr/bin/flterm
<xiangfu>
delete it first by 'sudo rm /usr/bin/flterm'
<aw>
xiangfu, done
<xiangfu>
aw, then as wolfgang said find the milkymist.git folder. and goto the 'tools' folder
<xiangfu>
run 'git pull' and 'make'
<aw>
flterm is new now
<aw>
so next, what the command i should type? to record ?
<xiangfu>
try ./flterm see if '--log' in the help message
<wolfspraul>
aw: if you see the --log command in the help message, that means you can now use the new --log option, for example
<wolfspraul>
xiangfu: wow, it seems you are writing each character separately and call fflush after each character? :-)
<wolfspraul>
at least that makes it easy to skip 0x00
<xiangfu>
kristianpaul, you install it in fidelio.qi-hardware.com?
<aw>
xiangfu, yes, 'xedit' can read it
<kristianpaul>
xiangfu: oh yeah, time ago
<wolfspraul>
xiangfu: I think just don't log 0x00: if (c) {fwrite/fflush}
<xiangfu>
kristianpaul, update xilinx, then we can setup dailybuild soc :)
<wolfspraul>
flushing after each character is a bit extreme too I think, but I'm not sure about all buffers and whether they are flushed at ctrl-c etc.
<kristianpaul>
xiangfu: just tell where you want it isntalled
<xiangfu>
kristianpaul, /opt/Xilinx
<kristianpaul>
xiangfu: i installed on my personal folder to not disturb system, but builhost looks more generic
<kristianpaul>
xiangfu: okay on my way..
<xiangfu>
kristianpaul, ssh -Y extreme slow here :(
<kristianpaul>
i cant image uploading then... :)
<xiangfu>
kristianpaul, well, it's not hurry. so I just uploading from my server to buildhost. :) (since my server stand there only for my blog service)
<kristianpaul>
no problem i can do it right now or neber ;)
<kristianpaul>
never*
<wolfspraul>
xiangfu: can you not log 0x00 ?
<wolfspraul>
that should solve the problem
<wolfspraul>
you should also think about the flush after each character
<aw>
xiangfu, help me on my flterm_adam.sh since my previous file named already "52-results", so i just want flterm --log can append directly on those 'existed files'. ;-)
<wolfspraul>
you can leave it in for now but I think it's too extreme
<xiangfu>
wolfspraul,  yes.
<xiangfu>
wolfspraul, (fflush) maybe every line.
<xiangfu>
if(c = '\n') fflush
<xiangfu>
wolfspraul, I just write those code follow 'flerm.c' , needs improve.
<wolfspraul>
yes sure but if you fix the 0x00 now then Adam can use gedit again (I hope)
<kristianpaul>
xiangfu: configure.ac:5: error: Autoconf version 2.68 or higher is required
<kristianpaul>
is it know?
<kristianpaul>
known*
<kristianpaul>
I'm rebuilding my toolchain as seems last disk failure truncated my /opt partition :(
<kristianpaul>
rtems toolchain
<wolfspraul>
aw: what do you want to know about flterm_adam.sh ?
<wolfspraul>
looks good
<aw>
xiangfu, i keep testing...just ping me if you have new one
<aw>
wolfspraul, No, must be path to be correctly, well.. i don't know
<kristianpaul>
after make -C compile-flickernoise flickernoise.fbi
<kristianpaul>
steps 1 to 6 went okay it seems..
<kristianpaul>
just telling :)
<kristianpaul>
i decide to clone that scripts folder today
<aw>
xiangfu, when used a normal command, i got err: adam@adam-laptop:~/m1_adam/snapshots/2011-07-13/for-rc3$ flterm --port /dev/ttyUSB0 --kernel boot.4e53273.bin
<aw>
[FLTERM] Starting...
<aw>
Segmentation fault
<stekern>
kristianpaul: that pastebin paste seems to be incomplete
<kristianpaul>
hum..
<kristianpaul>
damn
<wolfspraul>
xiangfu: calling fwrite with a 0 file descriptor is not a good idea
<xiangfu>
wolfspraul, my fault. :(
<wolfspraul>
maybe you fix that too then Adam can do a git pull and make/install
<kristianpaul>
hum the end-of-line in flterm is just fun :)
<xiangfu>
git am 0001-tools-flterm-check-logfd-not-log-0x00-flush-each-lin.patch
<xiangfu>
aw, and make again.
<wolfspraul>
xiangfu: how about he just uses --log /dev/null for now
<wolfspraul>
xiangfu: can you test whether that works?
<xiangfu>
wolfspraul, yes. /dev/null works fine
<wolfspraul>
so no git am/make etc. waste of time. get a working software into the repository, until then Adam can use a workaround such as --log /dev/null to fix the latest crash
<xiangfu>
should not write any C code before sleep
<aw>
xiangfu, so I keep using this new 'flterm' patch...later you fix that which can use gedit. just ping me, thanks.
<wpwrak>
xiangfu: solution: don't sleep after writing code ! ;-)
<xiangfu>
aw, about 'gedit' just select one code and click 'retry'
<xiangfu>
encode like ISO or whateven and click 'retry'
<aw>
xiangfu, oah..yes, after select "Western" and clicked 'retry', then 'gedit' can read it then. thanks you! ;-)
<xiangfu>
stekern, we should try this: [Fallenoulekernel: I copied CVS HEAD cpukit/zlib/zconf.h.in to a fresh git clone of milkymist rtems, it builds properly, do I commit & push ?]
<stekern>
xiangfu: CVS HEAD of rtems mainline I presume?
<kristianpaul>
yes
<wolfspraul>
xiangfu: I can reproduce the gedit problem. the warning goes away when I delete two 0xf7 characters in the log.
<wolfspraul>
some garbage from the serial console somewhere
<xiangfu>
wolfspraul, yes. when poweron/off the milkymist one
<wolfspraul>
so what are the solutions
<stekern>
what's up with the rtems people not using a sane vcs
<wolfspraul>
we could not log anything 0x80 or higher
<xiangfu>
wolfspraul, I think just leave them. garbage from serial is very normal
<stekern>
I mean, svn is bad enough, but cvs... common
<wolfspraul>
yes true
<wolfspraul>
but then maybe a marker at the beginning? should we write proper utf-8?
<xiangfu>
kristianpaul,  stekern, I will add the patch to my script.git until it fixed. :)
<wpwrak>
stekern: hey, it surely beat the stone tablets they used before ! ;-)
<stekern>
wpwrak: :)
<kristianpaul>
xiangfu: i dont think my current issue is related to zlib,,
<wolfspraul>
maybe convert any character above 0x80 to a utf-8 sequence?
<xiangfu>
kristianpaul, I don't see the error from your pastebin
<kristianpaul>
me either..
<kristianpaul>
is just that auto¨
<kristianpaul>
***
<kristianpaul>
agh
<kristianpaul>
wpwrak: nah, stone no, may be type writer?
<wolfspraul>
we assume the 8-bit incoming characters to be iso-8859-1 and write utf-8? that could make the warning go away
<wolfspraul>
xiangfu: can you reproduce the gedit warning?
<xiangfu>
wolfspraul, yes. that will be one solution.
<xiangfu>
wolfspraul, yes. I can,
<wolfspraul>
here's a snippet I found to go from 8859-1 to utf-8: if (*in<128) *out++=*in++; else *out++=0xc2+(*in>0xbf), *out++=(*in++&0x3f)+0x80;
<wolfspraul>
basically a c >= 0x80 becomes two fwrite
<wolfspraul>
then we write utf-8, and depending on Adam's locale settings and gedit assumptions/defaults, it may open without a warning
<wolfspraul>
MAY
<wolfspraul>
:-)
<wolfspraul>
but utf-8 is a good start I think
<wolfspraul>
I guess the 0xf7 we write into the file now confuses gedit. if it assumes the file to be utf-8 (and there is no marker at the beginning), then it's a strange character. if it's not utf-8, then gedit won't know which 8-bit standard it is.
<xiangfu>
stekern, I am apply the patch, compiling now. if everything fine , I will push my commit to scripts.git for keep the patch
<xiangfu>
wolfspraul, ok. will try that code
<stekern>
xiangfu: sounds good
<kristianpaul>
xiangfu: my problem is with boostraping, i always got configure.ac:5: error: Autoconf version 2.68 or higher is required
<xiangfu>
kristianpaul, do you have autoconf 2.68 installed?
<kristianpaul>
no
<kristianpaul>
think in me like same debian as buildhost
<kristianpaul>
my autoconf is 2.67-2
<xiangfu>
kristianpaul, have to update to 2.68 since Sebastien sync the rtems.git with upstream.
<xiangfu>
kristianpaul, then the buildhost will not compile either.
<kristianpaul>
hum...
<xiangfu>
kristianpaul, the solutions is add openwrt staging host bin to your PATH,
<kristianpaul>
*sigh*
<xiangfu>
kristianpaul, if you in buildhost that will easy, there are openwrt-xburst.full_system under /home/xiangfu.
<xiangfu>
:)
<kristianpaul>
no no, more mixes of openwrt with this..
<xiangfu>
wolfspraul, the code [: if (*in<128) *out++=*in++; else *out++=0xc2+(*in>0xbf), *out++=(*in++&0x3f)+0x80;] not working :(
<wolfspraul>
well
<wolfspraul>
of course that's just the numbers for the 0x80..0xFF to utf-8 conversion
<kristianpaul>
is not locales good for that convertion? (jsut a guess)
<GitHub59>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/cIaHYw
<GitHub59>
[scripts/master] compile-flickernoise: fix zlib compile error - Xiangfu Liu
<wolfspraul>
so 0xf7 would become 0xc3 0xb7. If I could find a binary editor I should try real quick whether the gedit warning goes away :-)
<wolfspraul>
which editor can give me a hex editing view?
<xiangfu>
vim :!xxd
<kristianpaul>
phew seems installing autoconf_2.68-1_all.deb solves this problem :)
<xiangfu>
sorry
<kristianpaul>
hexedit i guess
<xiangfu>
wolfspraul, %!xxd
<kristianpaul>
oh, nice xiangfu :)
<xiangfu>
:%!xxd to convert to hex, :%!xxd -r to convert back
<kristianpaul>
but it actually is not updating ascii view after edit the hex equivalent is it?
<xiangfu>
kristianpaul,  :%!xxd -r to convert back then save
<wolfspraul>
xiangfu: ok worked. and I can confirm that after I convert the two 0xf7 characters in there to 0xc3 0xb7 (the utf-8 equivalent), my gedit opens it without warning
<wolfspraul>
my default console is utf-8 thought, so Adam may still get warnings depending which gedit version he has, his locale, etc.
<wolfspraul>
but I think we should write utf-8, why not
<wolfspraul>
xiangfu: is that 0xc2/0xc3 stuff clear?
<wolfspraul>
the line was meant to give you the numbers, not to copy/paste into your sources 1:1
<xiangfu>
wolfspraul, ok.
<wolfspraul>
in your sources, it's something like if (c >= 0x80) { fwrite(0xc2+(c>0xbf)); fwrite(0x80+(c&0x3f)); }
<wolfspraul>
not to be copied 1:1 :-)
<stekern>
xiangfu: nice one, I'll pull and test
<xiangfu>
wolfspraul, not copied 1:1 but I forget 0x00 again. now it works fine. thanks. (my serial console garbage is much more then Adam's :)
<wolfspraul>
can your gedit open the resulting files without warnings now?
<xiangfu>
yes. without any  warnings now
<wolfspraul>
nice
<kristianpaul>
okay i need that zlib patch now :)
<xiangfu>
my fault the flterm patch goes to Version V3 :(
<stekern>
xiangfu: that worked for me
<kristianpaul>
hum..
<kristianpaul>
all
<kristianpaul>
ok
<kristianpaul>
bye
<lekernel>
xiangfu, what is that "utf-8" patch doing?
<xiangfu>
just convert the > 0x80 ASCII to utf-8. for avoid the editor can not open it. (like gedit)
<lekernel>
if(c >= 0x80) ... isn't char signed?
<lekernel>
also, is that really UTF8?
<lekernel>
why not simply drop those characters instead?
<xiangfu>
lekernel, yes. that is a solution, simple and clean. :)
<lekernel>
ok, please send a new patch
<lekernel>
and I guess you should check for c < 0 instead of c >= 0x80... no? (maybe I'm wrong)
<lekernel>
or use unsigned char ... I'm usually trying to avoid those corner cases :)
<xiangfu>
lekernel, I use 'if(isascii(c))'
<lekernel>
ok
<xiangfu>
sent out
<wpwrak>
fwiw, "char" can default to signed or unsigned.
<kristianpaul>
"or" dint sounded as default..
<kristianpaul>
how you force it?
<wpwrak>
well, that depends on the compiler :)
<wpwrak>
e.g., in gcc, you have -fsigned-char, -funsigned-char, and also the equivalent -fno-unsigned-char and -fno-signed-char
<wpwrak>
hmm, can't quite remember where I saw "char" default to "unsigned'. i thought it was sdcc, bit now i see that it has "--funsigned-char", which suggests the built-in default is signed
<kristianpaul>
he, i was about to make a joke a bout sdcc xD
<kristianpaul>
s/bout/about
<kristianpaul>
wow sdcc is version 3 now
<wpwrak>
still buggy, though :-(
<wpwrak>
but better than before
<lekernel>
wpwrak, most programs assume char is signed (and of course it was unsigned with some early versions of lm32-gcc, which meant more problems ...)
<Fallenou>
I didn't know, usually I assume char is signed
<lekernel>
yeah, that's the right thing to do
<Fallenou>
I thought by default all the types were signed by default unless you say (unsigned)
<lekernel>
this mess with the C types is just stupid and wasting everyone's time
<Fallenou>
clearly
<Fallenou>
I guess that's why people use uint8_t and such instead of primitif types
<lekernel>
the standard should simply say things like int = 32 bits, short int = 16 bits, char = 8 bits, and all types are signed by default
<Fallenou>
char = 8 bits is usually the case (don't know of any exception), but short int ... I think it depends, and that sucks
<stekern>
char = 16 bit with TI C2000 compiler
<Fallenou>
nice !
<wpwrak>
lekernel: that's why we have int32_t, uint16_t, etc. they're good. use them ;-)
<lekernel>
but they're not integrated in the compiler and sometimes result in a include file mess
<stekern>
I wonder how many programs written for x86 have got bitten by bugs when assuming unsigned long = 32 bits
<stekern>
or just plain long for that matter
<stekern>
isn't stdint.h part of C99 btw?
<wpwrak>
it's been well over a decade since I last saw problems with stdint.h, so i'd consider it rather safe. of course, maybe you visit tougher neighbourhoods than i do ;-)
<wpwrak>
M1 arrived ! :)
<kristianpaul>
Good !!
<kristianpaul>
Does it boot? ;)
<wpwrak>
assembling the case ...
<wpwrak>
case design feedback for the next version: the power input should also mention how much current it draws
<wpwrak>
now, find a power supply ...
<kristianpaul>
hum..
<kristianpaul>
i still wondering why you dont pay taxes for it
<wpwrak>
oh, i had to. they somehow got that wrong. but it wasn't much, about USD 15. (declared value was USD 50)
<wpwrak>
makes valiant attempt of locating one of the nice high-quality 5 V supplied remaining from the OQO days
<wpwrak>
locates power supply :-)
<wpwrak>
removes dust, spiders, ...
<wpwrak>
checks idle output of power supply. 5.12 V, perfect
<wpwrak>
hopes 2500 mA are enough
<wpwrak>
wikipedia says 5 W. excellent. that's plenty.
<wpwrak>
it gets as far as "press Esc for console"
<wpwrak>
locating keyboard ...
<wpwrak>
aah, effects ! :)
<wpwrak>
just have to wait before it does somethign, it seems ;-)
<wpwrak>
marvels at the coolness of the video effects
<wpwrak>
"esc for console", when exactly does this work ? when the Milkymist logo with that message is shown ? or also later ?
<kristianpaul>
clap clap !
<wpwrak>
still haven't gotten it to talk to anything USB yet
<wpwrak>
eeh, kewl. of all devices, my little wireless remote keyboard works ;-)
<wpwrak>
at least with the console. no response under FN
<wpwrak>
the handling of the screen when booting is rather confusing. first the welcome screen, then it's powered down (no signals), then blue screen, and finally some action
<wpwrak>
the "stricken" aircrash looks cool
<wpwrak>
and the one following it has very nice colors
<wpwrak>
(the wiggling square) just the white line in the middle looks like a rendering error
<wpwrak>
can USB hot-plug ? or do i have to power-cycle for new devices to be recognized ?
<lekernel>
usb hotplug works
<lekernel>
both the console and FN use the same code for USB, so you have probably spotted one of those pesky intermittent bugs
<wpwrak>
;-))
<wpwrak>
or maybe i'm just not using it right
<lekernel>
you shouldn't see the splash screen with "press esc for console", unless you are in rescue mode or pressed the power button for > ~1s
<wpwrak>
when i press the first button, i get a screen saying "Update" ... "Failed". mouse cursor is in the upper left corner. it there any keyboard input that should do something ?
<lekernel>
blue screen is probably missing camera input
<wpwrak>
(i don't get a mouse response, but that may be just a problem of my RF keyboard)
<lekernel>
use ESC to leave render mode, not update ...
<lekernel>
or enter
<wpwrak>
aah, Esc also works in render mode. i see
<wpwrak>
hmm, this keyboard doesn't have a meta key. and none of the "unusual" keys  (Fn+something) seem to work as the kind of modifier FN expects. but i also don't know what the keyboard really sends in this case. may be nonsense
<wpwrak>
ah, i have better luck with some cheap crap keyboard
<wpwrak>
it doesn't like my kensington mouse, though
<wpwrak>
works with a Microsoft mouse. you should watch the company your child keeps ! :)
<wpwrak>
okay, looking good so far. now i have to leave for a bit. more experimenting later.
<lekernel>
meta key = windows key
<wpwrak>
win = fn+ctrl on that kbd. and fn+cursor is also some magic. so maybe there's the conflict.
<GitHub92>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/0NDl_w
<GitHub92>
[milkymist/master] tools: flterm: check logfd, check ascii, flush each line - Xiangfu Liu
<kristianpaul>
win 19
<wpwrak>
will M1s be sold as fully assembled kits or is there a plan to also sell a significant number of them as kits ? in the latter case, perhaps the case assembly instructions should mention that each acrylic parts has two protective sheets, a discreet transparent one and a white one to draw people's attention away from the former :)
<wpwrak>
(i only noticed the transparent one when i got to the sidewalls. before, i had thought the bottom plate simply had some scratches on what then must be the inside)
<wpwrak>
roh: should i expect any trouble when gluing the buttons with regular superglue ? (liquid, not the messy gel)
<roh>
wpwrak: its messy and tends to break if you put on mechanical stress
<roh>
;)
<roh>
wpwrak: but the buttons on the new parts i shipped in the last batch are already glued
<wpwrak>
the ones i got are in parts. well, so maybe double-faced tape then
<lekernel>
if you go for the superglue, the most important thing is not to use too much
<lekernel>
otherwise it leaks from the sides and creates a mess