<wolfspraul> wpwrak: did you get your m1?
<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> flterm --port /dev/ttyUSB0 --kernel boot.bin --log m1rc3_0x63.log
<wolfspraul> --log will _append_ to the log file, so it will not overwrite it
<wolfspraul> xiangfu: doesn't adam also have to run make install?
<xiangfu> no, have to manually copy it to /usr/bin/
<aw> yes, i saw '--log' under /milkymist/tools, but how i can use it under different folder?
<xiangfu> aw, just 'sudo cp flterm /usr/bin/' :)
<aw> xiangfu, i need to copy it into /usr/bin?
<aw> good it can be typed under different folder. second...take one board to log
<aw> xiangfu, the log file can't be opened by 'gedit' after I used 'ctrl+C' to stop flterm, doesn't flterm accept 'ctrl +C'?
<xiangfu> what is the error when you use 'gedit' ?
<aw> edit has not been able to detect the character encoding.
<aw> Please check that you are not trying to open a binary file.
<aw> Select a character encoding from the menu and try again.
<aw> xiangfu, but log can be opened by GNU Emacs 23 and GVim that I am not used them.
<xiangfu> hmm... gedit have a 'tools' --> 'set languages'  try that.
<xiangfu> aw, I can open the log file without any problem. just 'gedit a.log'
<aw> xiangfu, set to which? 'English'?
<xiangfu> yes set to English and try again.
<aw> btw, if Emacs & GVim can open it, i think now i am ok
<aw> still can't open after set English
<wolfspraul> aw: email that log file to xiangfu, cc me. We'll find the reason.
<aw> btw, I am writing a small script for flterm, moment, you can help
<wolfspraul> but yes, it seems you can use flterm --log now
<wolfspraul> oh, I see you uploaded the log file already :-)
<wolfspraul> installing gedit right now...
<xiangfu> aw, there are some garbage characters, "telnetd started with stacksize = 81920 and priority = 9
<xiangfu> ¿·6& "
<xiangfu> but I don't have those characters in my log file.
<xiangfu> strange
<wolfspraul> xiangfu: I see two 0x00 bytes at the end of the file.
<wolfspraul> that's probably triggering the gedit problem. also I'm not sure what happens if you append. some text editors may choke on the 0x00
<aw> xiangfu, the garbage was done by usb-jtag board which once I powered off, it was that
<xiangfu> aw, ok. then you can try exit the flterm before you you poweroff the usb-jtag :)
<aw> i have to power-cycle 10 times without "ctrl+C" in 'flterm'
<aw> xiangfu, NO
<xiangfu> ok.
<aw> that was ineffciency
<wolfspraul> no no, of course not. the software has to be fixed, the workaround is not on the human side :-)
<wolfspraul> aw: you are right
<aw> well..if gedit can't read it well...let still do it. since Emacs and GVim can read it
<wolfspraul> yes
<wolfspraul> maybe xiangfu can avoid logging 0x00 in flterm?
<wolfspraul> 0x00 should not really be in a text file and serves no purpose
<kristianpaul> xiangfu: why uploading xilinx stuff?
<wolfspraul> I think once we take the two 0x00 at the end out gedit will not complain anymore.
<kristianpaul> I installed mine from server and download from xilinx serves too
<kristianpaul> just a ssh -Y and run ./xsetup
<xiangfu> aw, you can try 'xedit' :)
<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
<wolfspraul> wait
<wolfspraul> try this line
<xiangfu> oh
<xiangfu> kristianpaul, it's known. :)
<xiangfu> kristianpaul, there is one line in my .bashrc : PATH=/home/xiangfu/workspace/PanGu/openwrt-xburst/staging_dir/host/bin:$PATH
<wolfspraul> sudo flterm --port /dev/ttyUSB0 --kernel ~/m1_adam/snapshots/2011-07-13/for-rc3/boot.4e53273.bin --log ~/m1_adam/snapshots/2011-07-13/results/$1-results
<wolfspraul> you have to run flterm with sudo, no?
<xiangfu> kristianpaul, which have autoconf 2.68 :)
<aw> xiangfu, thanks a lot! ;-) try it later, i am reflashing another board
<kristianpaul> xiangfu: 2.67-2 debian squeeze
<kristianpaul> damn debian old stuf.. :/
<kristianpaul> oh well :)
<xiangfu> kristianpaul, upload to 2.68 is conflict with pkc-config
<wolfspraul> ah yes, xiangfu's is nicer
<aw> wolfspraul, yes, seems same as xingfu's one. thanks!
<wolfspraul> aw: xiangfu will fix the gedit problem too
<kristianpaul> xiangfu: so stay with 2.67-2 and try your PATH right?
<aw> wolfspraul, alright, i go for other boards firstly, i think xiangfu will ping me later, thank you all.
<xiangfu> kristianpaul, yes.
<kristianpaul> xiangfu: oh wait, that line from your batch is about openwrt-xburst..
<kristianpaul> bashrc*
<xiangfu> kristianpaul, yes :)
<kristianpaul> hum??
<kristianpaul> and it solves my boostraping problem around rtems?
<kristianpaul> he, i shall be more precise
<xiangfu> kristianpaul, not sure. maybe. I only have zlib problem when compile rtems now.
<kristianpaul> hum.. i think i'll try manually better
<kristianpaul> btw you run buildhost scripts as root?
<xiangfu> aw, you can avoid 'sudo' by add this file [http://downloads.qi-hardware.com/people/xiangfu/tmp/72-qi-hardware.rules] to folder '/etc/udev/rules.d'
<kristianpaul> okay i'll install ise as root too
<xiangfu> aw, and change the GROUP to [GROUP="adam"]
<xiangfu> kristianpaul, no. I am not use 'root', I scare 'root' user always.
<xiangfu> kristianpaul, I change the '/opt' to mine :) for compile milkymist one stuff
<kristianpaul> ah
<kristianpaul> ok so..
<kristianpaul> i'll install as root you can rever permission later then
<kristianpaul> revert*
<kristianpaul> hum no space left..
<kristianpaul> on /opt
<xiangfu> kristianpaul, you installing ISE on buildhost now? if you install. I dont' think I needs do that again.
<xiangfu> only one ISE is enough.
<xiangfu> kristianpaul, what version you using? 13.2?
<kristianpaul> sure, of corse 13.2
<kristianpaul> yes installing on buildhost now
<kristianpaul> so..
<kristianpaul> i install on /home/xilinx..
<kristianpaul> ;-)
<kristianpaul> okay installing now
<xiangfu> kristianpaul, thanks. I will use that one /home/xilinx
<kristianpaul> btw i'm lost, should i use rtems from the unoffial git repo in milkymist organizational page or rtems-old?
<xiangfu> not rtems-old.
<xiangfu> kristianpaul, use rtems.git and 'mmstaging' branch
<kristianpaul> I'm using your script :)
<kristianpaul> hum wheezy have autoconf 1.68-1
<kristianpaul> 2.68-1*
<kristianpaul> arghhh i should had stay on fedora....
<kristianpaul> xiangfu: http://pastebin.com/wYpaddG3
<xiangfu> ?
<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
<xiangfu> sending new patch now
<kristianpaul> fulllog http://pastebin.com/bhkgMyTy
<stekern> kristianpaul: I think something is still missing
<aw> xiangfu, so i can do git pull and make now?
<xiangfu> aw, no. I don't have write access to milkymist.git. have to wait Sebastien apply the patch
<aw> oah... i can use neither normal flterm command nor --log now..too bad. :(
<kristianpaul> done, ISE 13.2 installed at /home/Xilinx/13.2 @ fidelio
<xiangfu> aw, but you can manually apply it for temp.
<kristianpaul> already licensed and smalltalk disabled
<wolfspraul> how about --log /dev/null ?
<wolfspraul> aw: try --log /dev/null
<aw> xiangfu, yes, just no gedit support now
<kristianpaul> xiangfu: i'll start over again rtems toolchain process
<xiangfu> aw, under milkmist.git folder run:
<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
<xiangfu> kristianpaul, the error I have is like: http://pastebin.com/aaE6PTGM
<aw> xiangfu, just applied, now normal 'flterm' cmd can work, and the new log appended it but gedit still can't open it: http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/56-results
<stekern> xiangfu: yeah, that's what I get too
<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> 0x80..0bf becomes 0xc2 + 0x80..0xbf
<xiangfu> stekern, ^
<wolfspraul> 0xc0 .. 0xff becomes 0xc3 + 0x80..0xbf
<wolfspraul> if I read that snippet correctly...
<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> booting again
<lekernel> you can move the mouse cursor with the keyboard, see http://www.milkymist.org/leaflets/run3_leaflet.pdf
<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
<lekernel> there won't be kits I think
<xiangfu> lekernel, Hi