2011-05-19 02:05 <qi-bot> [commit] Werner Almesberger: tools/atrf-xtal/: new option -b for relative result; -p for pass/fail http://qi-hw.com/p/ben-wpan/ff6c834
2011-05-19 02:05 <qi-bot> [commit] Werner Almesberger: prod/doc/analysis.html: added precision clock measurement for atben http://qi-hw.com/p/ben-wpan/d2fda37
2011-05-19 02:05 <qi-bot> [commit] Werner Almesberger: prod/Makefile (ben): used simplified setup with only one atben and one atusb http://qi-hw.com/p/ben-wpan/6446a6e
2011-05-19 02:05 <qi-bot> [commit] Werner Almesberger: prod/doc/setup.html: corrected mangled sentence http://qi-hw.com/p/ben-wpan/dc40ff6
2011-05-19 02:21 <qi-bot> [commit] Neil Stockbridge: libsdl-doc-man has been renamed to libsdl-dev and now includes header files http://qi-hw.com/p/openwrt-packages/1460a79
2011-05-19 02:24 <xiangfu> Hi unclouded 
2011-05-19 02:24 <unclouded> hi
2011-05-19 02:24 <xiangfu> which version you using in your nanonote now?
2011-05-19 02:24 <unclouded> rootfs is the latest
2011-05-19 02:24 <unclouded> kernel is still from December
2011-05-19 02:25 <xiangfu> can you give me the output of 'wget --version', 
2011-05-19 02:25 <unclouded> that's when I run from MMC, which I do most of the time
2011-05-19 02:25 <unclouded> NAND has latest kernel and rootfs and works fine
2011-05-19 02:25 <unclouded> wget: unrecognized option `--version'
2011-05-19 02:25 <unclouded> looks like busybox is handling wget
2011-05-19 02:26 <xiangfu> thanks. can you make sure it. ? 
2011-05-19 02:26 <unclouded> although I have built my own busybox so the busybox package might have been mangled to include wget whether the release version does or not
2011-05-19 02:27 <unclouded> sure.  my NAND is pristine, so I'll boot that and do the test there instead
2011-05-19 02:27 <xiangfu> thanks.
2011-05-19 02:30 <unclouded> different result.  I must have elected for busybox to include wget when I rebuilt it
2011-05-19 02:31 <unclouded> NAND says GNU Wget 1.12
2011-05-19 02:32 <xiangfu> unclouded: ok. what about ` wget --version | grep iri`
2011-05-19 02:32 <unclouded> simply says "-iri"
2011-05-19 02:32 <unclouded> nothing else
2011-05-19 02:32 <xiangfu> ok.
2011-05-19 02:33 <unclouded> would you like me to do any other tests on the NAND or can I boot back to MMC?
2011-05-19 02:34 <xiangfu> maybe the libidn is build after 'wget' build. that is why 'wget' not detect the libidn, but recently the packages build order changed, 
2011-05-19 02:34 <xiangfu> unclouded: thanks. just back to MMC, '-iri' is enough :)
2011-05-19 02:36 <unclouded> hey xiangfu, can I get a folder at http://downloads.qi-hardware.com/people/ so I can make available some man-tiny .ipk files for testing?
2011-05-19 02:37 <xiangfu> sure. 
2011-05-19 02:37 <xiangfu> do you have account on downloads.qi-hardware.com?
2011-05-19 02:37 <xiangfu> real user in server?
2011-05-19 02:38 <unclouded> don't think so.  I have two Qi accounts: wiki and projects.  it's not either of those is it?
2011-05-19 02:41 <xiangfu> unclouded: ok. just send your ssh public key to me. I will setup account in downloads.qi-hardware.com
2011-05-19 02:43 <unclouded> the key is on its way to you now
2011-05-19 02:58 <xiangfu> unclouded: just ssh to downloads.qi-hardware. I setup a symlink in your home folder name 'people.unclouded' point to downloads.qi-hardware.com/people/unclouded/
2011-05-19 02:59 <xiangfu> wolfspraul: I found the folder under people/ is all www-data.www-data, only my folder is xiangfu.xiangfu, I always using 'scp' to copy files to downloads.qi-hardware.com, should I also using 'www-data'?
2011-05-19 03:07 <wolfspraul> don't know, I doubt there is much difference
2011-05-19 03:11 <xiangfu> unclouded: some feedback, if install both busybox man and your man-tiny, by default it's busybox, since the /sbin/ at a front of /usr/bin,  
2011-05-19 03:12 <xiangfu> unclouded: there are some example : http://dpaste.com/544114/ just FYI.
2011-05-19 03:13 <unclouded> that's pretty cool.  so packages can patch themselves over the busybox versions and then restore the busybox version if the extended package is removed?
2011-05-19 03:16 <xiangfu> unclouded: another thing, you may also want re-package 'manpages-dev_3.27-1_all.deb' to openwrt package.
2011-05-19 03:17 <xiangfu> :)
2011-05-19 03:17 <unclouded> that would make it easier for people to get the dev man pages on to the NanoNote for sure.  will add to list
2011-05-19 03:18 <unclouded> I couldn't find an upstream tarball for manpages-dev.  I think the collection actually originates at Debian
2011-05-19 03:18 <xiangfu> unclouded: ok. 
2011-05-19 03:19 <xiangfu> then we can just download the deb package. and then write 'define Package/manpagers-dev/postinst  opkg isntall manpages.deb'
2011-05-19 04:55 <kyak> it would be nice to have some openwrt hack to be able to generate these *-dev packages automagically
2011-05-19 04:56 <kyak> just having a look at libsdl-dev by Neil.. everything is already there in build root, it's just a matter of copying of headers/libs/man pages
2011-05-19 04:57 <kyak> xMff: do you think it is possible to do somehow?
2011-05-19 05:00 <xiangfu> kyak: include $(INCLUDE_DIR)/man.mk ?
2011-05-19 05:00 <xiangfu> then add  CONFIG_MANPAGE ?
2011-05-19 05:01 <xiangfu> maybe no man.mk, just CONFIG_MANPAGE.
2011-05-19 05:02 <kyak> xiangfu: yes, maybe some global flag whether to include manpages/dev libs or not.. But i was thinking about separate packages for that
2011-05-19 05:03 <xiangfu> kyak: you mean every package like:  wget, wget-dev?
2011-05-19 05:03 <kyak> maybe, if this flag is set, then build system will generate according separate pacakges..
2011-05-19 05:03 <kyak> yeah: wget, wget-dev, wget-manpages
2011-05-19 05:04 <kyak> i think it's done in lime like that
2011-05-19 05:04 <kyak> and all localization files are also splitted
2011-05-19 05:05 <kyak> like wget-locales-ru 
2011-05-19 05:05 <xiangfu> not sure if OpenWrt users will like wget-dev, wget-manpages.
2011-05-19 05:05 <kyak> openwrt users won't need it, for sure
2011-05-19 05:05 <kyak> so they won't set the flag :)
2011-05-19 05:06 <xiangfu> kyak: another idea is , after all package compiled,  search all manpages in build_dir/... then create a package for all package man page :)
2011-05-19 05:06 <kyak> that would be a lot of information i think..
2011-05-19 05:07 <kyak> and i'm not even sure opkg running on Ben is capable of isntalling it
2011-05-19 05:08 <kyak> it will run out of memory, and then diskspace :)
2011-05-19 05:09 <kyak> another option is just to create there -dev and -man packages by hand, when necessary
2011-05-19 05:09 <kyak> just like Neil did
2011-05-19 05:10 <kyak> someone need to develop ncurses app on Ben? let's package ncurses-dev
2011-05-19 05:10 <xiangfu> my system is 40M /usr/share/man
2011-05-19 05:10 <kyak> mine is 63M :)
2011-05-19 05:10 <xiangfu> kyak: then the package-dev.mk is better.
2011-05-19 05:16 <wolfspraul> one day we need to do the 'next big repartitioning'
2011-05-19 05:16 <kyak> xiangfu: so this package-dev.mk will be a helper to package -dev and -man packages?
2011-05-19 05:17 <kyak> and magic will happen there?
2011-05-19 05:17 <xiangfu> wolfspraul: yes. we should thinking about it when we start switch to trunk I guess.
2011-05-19 05:18 <xiangfu> kyak: (package-dev.mk) I guess so.
2011-05-19 05:19 <xiangfu> kyak: something like rewrite 'Build/Compile/Default' , just an idea. 
2011-05-19 05:19 <xiangfu> kyak: for example the cmake.mk. 
2011-05-19 05:20 <xiangfu> kyak: hmm... maybe not. then we need change so many packages. that is not good
2011-05-19 05:56 <unclouded> will the size of the man pages matter much?  only those who wish to write C on the NanoNote would install a lot of -dev packages
2011-05-19 05:57 <unclouded> I was thinking the -dev packages could include the man pages ( no need for a seperate -man package) although that would waste disc space for a C developer who wants to read all their documentation in HTML
2011-05-19 05:57 <unclouded> but how likely is that?  and just how much space would the man pages consume?
2011-05-19 06:12 <kyak> hm
2011-05-19 06:13 <kyak> the total size of all manpages under build_dir is 6293699 bytes
2011-05-19 06:13 <kyak> but it might be due to the fact that most packages are not confgiured to generate manpages
2011-05-19 06:14 <kyak> i also wonder if i calculate correctly: find ~/openwrt-xburst.full_system/build_dir -name "*.man" -printf %s+ | sed 's/+$/\n/g' | bc -l
2011-05-19 06:16 <kyak> yeah, the assumption that manpages are named as "*.man" is not correct :)
2011-05-19 06:20 <kyak> -regex ".*\.man\|.*\.[1-9]" seems better
2011-05-19 06:20 <kyak> but then, it accounts for uncompressed man pages
2011-05-19 06:20 <kyak> he-he, and also some libs :)
2011-05-19 06:43 <unclouded> I would have expected man pages to compress well but the SDL ones only went from about 720K to 680K or something.  not much compression
2011-05-19 08:06 <xMff> kyak: yes, I think so
2011-05-19 08:06 <xMff> kyak: with a bit of work
2011-05-19 08:19 <kyak> xMff: what is your idea?
2011-05-19 08:19 <xMff> hijack Build/InstallDev somehow
2011-05-19 08:21 <kyak> hm.. so not even necessary to create additional makefiles in include/ and modify package Makefiles
2011-05-19 08:21 <xMff> yeah
2011-05-19 08:21 <xMff> since InstallDev typically installs what a -dev package would contain
2011-05-19 08:21 <kyak> exactly..
2011-05-19 08:22 <xMff> and its always relative
2011-05-19 08:22 <xMff> target path is passed as $(1)
2011-05-19 08:22 <xMff> not coded in the define
2011-05-19 08:22 <xMff> but its just a crazy idea for now
2011-05-19 08:23 <xMff> one has to dig through rules.mk, include/package*.mk and package/Makefile
2011-05-19 08:23 <xMff> to implement it
2011-05-19 08:23 <xMff> or to find out howto create corresponding -dev packages "out if thin air"
2011-05-19 08:25 <kyak> so it's not so simple after all..
2011-05-19 08:25 <xMff> well, its advanced makefile changes
2011-05-19 08:25 <xMff> but they  have to be done once only
2011-05-19 08:25 <xMff> not for each package
2011-05-19 08:26 <xMff> ok
2011-05-19 08:27 <xMff> the BuildPackage macro should be expanded
2011-05-19 08:27 <xMff> problem is when multiple binary packages share one source bundle
2011-05-19 08:27 <xMff> how do you name the -dev package?
2011-05-19 08:29 <kyak> binaries are usually separated from libraries?
2011-05-19 08:29 <kyak> like, curl and libcurl and libcurl-dev
2011-05-19 08:30 <kyak> but all build from the same tarball
2011-05-19 08:33 <xMff> right
2011-05-19 08:34 <xMff> and progrqammatically you can't decide whether it should be curl-dev or libcurl-dev without additional hints
2011-05-19 08:34 <xMff> you could only take the source package name and append -dev
2011-05-19 08:34 <xMff> which would be "curl-dev" in this case
2011-05-19 08:34 <xMff> or "glib2-dev" for libglib2
2011-05-19 08:36 <kyak> so you are saying that we can only peek at PKG_NAME
2011-05-19 08:36 <xMff> yes, more or less
2011-05-19 08:37 <kyak> maybe just prepend "lib" to the name
2011-05-19 08:37 <xMff> because source:ipk relation is 1:n
2011-05-19 08:37 <kyak> that would be a more or less correct guess
2011-05-19 08:37 <xMff> not sure
2011-05-19 08:38 <xMff> for example libsocks
2011-05-19 08:38 <kyak> having it as $(PKG_NAME)-dev is not so bad after all
2011-05-19 08:38 <xMff> the source is called dante
2011-05-19 08:38 <xMff> the dev package would be libdante-dev
2011-05-19 08:38 <kyak> though confusing :)
2011-05-19 08:38 <xMff> which makes no sense
2011-05-19 08:39 <kyak> maybe an argument to InstallDev to override that?
2011-05-19 08:39 <xMff> I fear nobody is going to maintain that
2011-05-19 08:40 <kyak> there won't be a lot of packages with confusing names
2011-05-19 08:40 <xMff> the extra argument I mean
2011-05-19 08:40 <xMff> we can consider it
2011-05-19 08:40 <xMff> something like  PKG_DEV_NAME
2011-05-19 08:40 <xMff> with fallback to $(PKG_NAME)-dev
2011-05-19 08:41 <kyak> then if someone decides that he is not happy with libdante-dev, he would add that PKG_DEV_NAME into makefile..
2011-05-19 08:41 <xMff> however I would not add the lib by default
2011-05-19 08:41 <xMff> that would be liblibtorrent-dev then :P
2011-05-19 08:41 <kyak> yeah..
2011-05-19 08:41 <kyak> exactly what i was going to say :)
2011-05-19 08:42 <kyak> though it can be considered
2011-05-19 08:42 <xMff> thats details after the actual implementation is there
2011-05-19 08:43 <kyak> are you interested in implementing this for openwrt? I fear i'm not capable, deep knowledge of openwrt internals is required
2011-05-19 08:43 <xMff> I'll take a stab at it
2011-05-19 08:45 <kyak> nice! :) call me anytime you need a hand at testing. .that's the best i can do
2011-05-19 08:49 <xMff> interesting
2011-05-19 08:49 <xMff> apparently one can overlay package makefiles
2011-05-19 08:49 <xMff> $(eval -include $(wildcard $(TOPDIR)/overlay/*/$(PKG_NAME).mk))
2011-05-19 08:49 <xMff> just a side-note
2011-05-19 08:50 <xMff> found it while checking the makefiles
2011-05-19 09:22 <wpwrak> Jay7: btw, where was the home page of your kexec-based boot loader again ?
2011-05-19 09:35 <kyak> xMff: what does "overlaying makefiles" mean?
2011-05-19 09:35 <xMff> apparently you can override certain sections of existing makefiles with overlay makefiles
2011-05-19 09:35 <xMff> to e.g. redefien the description without patching it
2011-05-19 09:36 <xMff> it was new to me so I was excited
2011-05-19 09:38 <kyak> i see.. are you looking into exploiting this somehow?
2011-05-19 09:39 <xMff> no not really, I will somehow generate a -dev package definition from within the BuildPackage macro
2011-05-19 09:41 <xMff> one funny thing is that it will produce a lot of new entries in menuconfig
2011-05-19 09:41 <kyak> oh yea.. maybe make all of those dependant on CONFIG_PKG_DEV
2011-05-19 09:42 <kyak> so it won't appear for someone who is not interested to see it :)
2011-05-19 09:43 <xMff> yes, that for granted
2011-05-19 09:43 <xMff> but it will still look like
2011-05-19 09:43 <xMff> libfoo
2011-05-19 09:43 <xMff> libfoo-dev
2011-05-19 09:43 <xMff> libbar
2011-05-19 09:43 <xMff> libbar-dev
2011-05-19 09:43 <xMff> ...
2011-05-19 09:43 <xMff> in menuconfig
2011-05-19 09:43 <kyak> do you think it's bad?
2011-05-19 09:44 <xMff> it looks unclean
2011-05-19 09:44 <kyak> mayeb these could be hidden
2011-05-19 09:44 <xMff> but maybe it can be relocated into a new category "Development Headers"
2011-05-19 09:44 <kyak> but still built if CONFIG_PKG_DEV is set
2011-05-19 09:44 <xMff> with all -dev packages lumped together
2011-05-19 09:44 <xMff> then its out of sight
2011-05-19 09:45 <kyak> separate category also sounds nice
2011-05-19 09:48 <xMff> I have to relocate to the workplace, will hack on it from there. bbl
2011-05-19 09:55 <kyak> jow_laptop comes into play :)
2011-05-19 14:26 <whitequark> Jay7: no problem, in russian: http://lanc.bcmg.ru/wiki/index.php/IP_HDTV_%22LANC003%22_-_open_software_camera_project
2011-05-19 15:17 <wpwrak> DocScrutinizer: hmm, should shorting an antenna to ground be safe or could this damage amplifier/balun ? considering that all the power that goes into the antenna should also leave this way, i would expect that it's safe. but i'm not sure if i can trust this theory ;-)
2011-05-19 15:22 <ron_> wpwrak have you heard any progress/status re: SMT run for the ATben and ATusb?
2011-05-19 15:23 <wpwrak> rjeffries: only that tuxbrain said last week that he'd make sure he'll set a day aside for going through the testing process this week.
2011-05-19 15:26 <Jay7> wpwrak: kexecboot.org
2011-05-19 15:27 <Jay7> whitequark: nice project :)
2011-05-19 15:28 <wpwrak> Jay7: ah, kinda obvious, in retrospect ;-) thanks !
2011-05-19 15:28 <Jay7> wpwrak: np :) what is context behind that question? ;)
2011-05-19 15:34 <wpwrak> Jay7: ah, there's a discussion of boot loaders on heise.de, and i wanted to mention one active project using a kexec-based boot loader
2011-05-19 15:34 <DocScrutinizer> wpwrak: depending on amp/tx, band, antenna, point of shortening it, you can create a SWR that's so abysmal that it blows your TX power amp. Not on <500mW TX pwr of course
2011-05-19 15:34 <Jay7> wpwrak: seems we (kexecboot) are last active project :)
2011-05-19 15:34 <Jay7> qi-bootmenu is stalled
2011-05-19 15:34 <wpwrak> DocScrutinizer: i have 2 mW ;-) safe enough then ?
2011-05-19 15:34 <Jay7> all other was stalled even early
2011-05-19 15:34 <DocScrutinizer> probably
2011-05-19 15:35 <wpwrak> Jay7: we should call them "mature" ;-)
2011-05-19 15:35 <Jay7> wpwrak: hehe ;)
2011-05-19 15:39 <xiangfu> http://kexecboot.org/screenshots nice 
2011-05-19 15:53 <Jay7> yeah.. I should update screenshots
2011-05-19 15:53 <Jay7> font and icons was changed
2011-05-19 17:31 <qi-bot> [commit] Werner Almesberger: prod/doc/analysis.html: more material on checking the supply voltages http://qi-hw.com/p/ben-wpan/47b710d
2011-05-19 17:31 <qi-bot> [commit] Werner Almesberger: atusb: varistor Vdc was off by 100 mV; made it clearer that we use Vdc, not Vb http://qi-hw.com/p/ben-wpan/926ed26
2011-05-19 18:04 <methril_work> wpwrak, i'm almost going to FISL, do you have a MMOne?
2011-05-19 18:06 <wpwrak> methril_work: no, just a bunch of bens (and an avt2)
2011-05-19 18:06 <methril_work> ok
2011-05-19 18:06 <methril_work> i've my ben, and a MMOne
2011-05-19 18:07 <wpwrak> methril_work: rejon said he'll bring an mm1 to fisl
2011-05-19 18:07 <methril_work> rejon is going to FISL!! this is new to me :)
2011-05-19 18:07 <wpwrak> i need to clean up ubb-vga a little. would be nice to do the presentation with my ben ;-)
2011-05-19 18:08 <methril_work> how many ubb's do you have?
2011-05-19 18:09 <rejon> yeah, i'll be there
2011-05-19 18:09 <methril_work> i would like to buy 1 or two :)
2011-05-19 18:09 <rejon> i'm catching up today
2011-05-19 18:09 <rejon> excellent!
2011-05-19 18:11 <wpwrak> methril_work: yeah, i could part with one or two :)
2011-05-19 18:12 <methril_work> we'll try to pass brz taxes ;)
2011-05-19 18:32 <wpwrak> they still have RA taxes on them. but they're only about half of yours :)
2011-05-19 18:32 <roh> wpwrak: seen this? http://www.nxp.com/campaigns/greenchip/pages/smartlighting.php
2011-05-19 18:36 <wpwrak> roh: using ieee 802.15.4 for domotics. nice :)
2011-05-19 18:36 <wpwrak> roh: the next step should be to combine energy harvesting with all this ;-)
2011-05-19 18:36 <roh> not that neccessary
2011-05-19 18:37 <roh> most energy is eaten by displays not wifi or other radios
2011-05-19 18:37 <wpwrak> roh: hey, smart lighting that doesn't need a power supply ? don't you think that would sell like crazy ? ;-)
2011-05-19 19:56 <lunavorax_mini> I came up to the conclusion that the Raspberry Pi was a total faillure from start.
2011-05-19 19:57 <wpwrak> ;-))
2011-05-19 19:57 <lunavorax_mini> Poor kids need a ZX-Spec desing-like computer, small keyboard (with normal keys, not rubber ;) ) and composite out for video and SD card slot for storage (plus some USB in for devices) and that's IT. No wireless crap, no extra stuff, only maybe a mono speaker or audio in + audio out.
2011-05-19 19:57 <wpwrak> lunavorax_mini: lekernel will be happy to read this :)
2011-05-19 19:58 <lunavorax_mini> imho, I'm not a computer specialist/designer
2011-05-19 19:58 <lunavorax_mini> Haha
2011-05-19 19:58 <Jay7> yes! let's reinvent ZX :)
2011-05-19 19:58 <mstevens> lunavorax_mini: have you seen http://sites.google.com/site/libby8dev/fignition ?
2011-05-19 19:58 <Jay7> like that idea :)
2011-05-19 19:59 <lunavorax_mini> mstevens, the first line makes me liking the idea :)
2011-05-19 19:59 <wpwrak> easy. i'm quite sure you could generate composite video with a ben. instant zx2011, and it's even mobile ;-)
2011-05-19 19:59 <lunavorax_mini> :)
2011-05-19 19:59 <lunavorax_mini> And letting kids playing with Python, no need to discourage them with C/C++.
2011-05-19 20:00 <lunavorax_mini> [troll] I think C# is better for kids as a first programming language [/troll]
2011-05-19 20:00 <lunavorax_mini> (no, I'm actually not thinking this)
2011-05-19 20:01 <lunavorax_mini> mstevens, that's really insteresting !
2011-05-19 20:01 <wpwrak> mipsel-linux-gas will do nicely
2011-05-19 20:01 <lunavorax_mini> gas ?
2011-05-19 20:03 <wpwrak> assembler
2011-05-19 20:03 <lunavorax_mini> Oh ok
2011-05-19 20:04 <lunavorax_mini> I think some kids should start with Python or other high level language first
2011-05-19 20:04 <lunavorax_mini> I don't know much about Lua or Ruby.
2011-05-19 20:07 <wpwrak> bah. i started with the ti-57. 50 program steps. 10 variables. no persistent storage. all those friendly languages will just spoil them :)
2011-05-19 20:07 <lunavorax_mini> Yeah I don't know
2011-05-19 20:07 <lunavorax_mini> I feel stupid when I heard someone saying "I was programming in ASM at 13yrs old"
2011-05-19 20:08 <lunavorax_mini> And I still can't make a functionnal (and interesting) C program.
2011-05-19 20:14 <mth> I was programming in asm at 11 years old ;)  although I wasn't very good back then
2011-05-19 20:17 <mth> I think I was about 15 before I actually could do useful things in asm
2011-05-19 20:18 <wpwrak> bah, at 11, i was designing my own computer :) (not that it would have worked ... i hadn't quite grasped the concept behind the R in "RAM" back then)
2011-05-19 20:18 <lunavorax_mini> Oh come on guys, now how should I feel ? :(
2011-05-19 20:19 <wpwrak> mth: four years of nothing but frustrating failure ? that's a rough childhood
2011-05-19 20:19 <mth> wpwrak: no, I went back to using BASIC in the mean time
2011-05-19 20:20 <mth> the main problem was that I had an asm book that wasn't written for beginners
2011-05-19 20:21 <mth> back then I wanted to learn asm because BASIC was really slow (interpreted on Z80)
2011-05-19 20:21 <mth> I don't know how it is for today's young
2011-05-19 20:21 <lunavorax_mini> Well I think I can answer
2011-05-19 20:22 <lunavorax_mini> And that's why I was defending the use of Python as it is simple to understand for a beginner and not that slow for simple things.
2011-05-19 20:23 <lunavorax_mini> (still I am planning to learn asm this summer)
2011-05-19 20:23 <mth> I do know that people from the Informatics Olympiad were trying to teach me a LISP-like Logo dialect with little success
2011-05-19 20:23 <mth> although that was more because of the weird structure editor rather than because of the language itself
2011-05-19 20:24 <lunavorax_mini> Haven't you forgot a ) ? ;)
2011-05-19 20:24 <mth> ah no, it was derived from Scheme, not LISP
2011-05-19 20:25 <mth> well, it is LISP-like
2011-05-19 20:26 <Jay7> I was programming ASM about 15 years old
2011-05-19 20:26 <Jay7> because I had zx spectrum :)
2011-05-19 20:27 <Jay7> like mth :)
2011-05-19 20:27 <mth> I guess the structure editor was designed to avoid parenthesis problems, but I couldn't get over the fact that the cursor would move through the program tree rather than just going up/down/left/right one position
2011-05-19 20:27 <mth> Jay7: actually MSX for me, but pretty similar hardware
2011-05-19 20:31 <mth> my first attempt at learning C also failed, I tried learning it from a book during a holiday (no laptop in that time, so holiday meant a few weeks without a computer)
2011-05-19 20:31 <mth> I think I don't learn from books very well, I have to be able to try things out
2011-05-19 20:33 <mth> lunavorax_mini: MIPS asm would be a good candidate then, it's much more elegant than x86
2011-05-19 20:41 <wpwrak> mth: naw, VAX assembler would be so much better. nothing illustrates better where the complexity in CISC lies than a little MOVC5 or a POLYH ;-)
2011-05-19 20:54 <lunavorax_mini> mth, actually, I'm aiming at learning x86 asm. I need it in order to understand disassembly of some x86 software I want to try to reverse-engineer
2011-05-19 20:55 <lunavorax_mini> In the other hand, I have 3 of the 4 only existing books about Z80 asm :)
2011-05-19 20:56 <lunavorax_mini> I'm also aiming to learn it at some point, I have a lot of Z80 devices here (gameboy, ti-83, VG5000, ZX-Spec)
2011-05-19 20:56 <lunavorax_mini> only existing French* books
2011-05-19 20:57 <mth> if you've never done asm before, Z80 might be a good way to learn
2011-05-19 20:57 <mth> it's CISC, but not as complex as x86
2011-05-19 20:57 <graphitemaster> the cool part about asm is you only need to know the basic fundementals of it, then you can plug in any type of instruction assuming the hardware supports it and it'll work
2011-05-19 20:58 <graphitemaster> most instruction sets are highly documents and can be found with a small google search.
2011-05-19 20:58 <graphitemaster> *documented
2011-05-19 21:02 <lunavorax_mini> mth, CISC ?
2011-05-19 21:03 <mth> complex instruction set computing
2011-05-19 21:03 <mth> as opposed to RISC
2011-05-19 21:03 <mth> in RISC instructions do very little work and are highly orthogonal
2011-05-19 21:04 <lunavorax_mini> graphitemaster, yeah I heard someone saying to me "I only know the instruction set and I can do whatever I want". Also a University teacher told me "I don't know any language that is simpler than asm"
2011-05-19 21:04 <mth> while in CISC instructions do more work and are specialized
2011-05-19 21:04 <mth> for example, on Z80 there is the DJNZ instruction, which does "decrement B, jump if non-zero" in one instruction
2011-05-19 21:04 <graphitemaster> RISC instructions are no good for anything but battery life and embedded platforms, with exception to ARMv6 which I think is the only sane RISC route these days.
2011-05-19 21:05 <lunavorax_mini> Battery life ? That means ultra precise programming then, no ?
2011-05-19 21:06 <mth> graphitemaster: RISC might be easier for compilers to generate code for as well
2011-05-19 21:06 <mth> since the registers are interchangeable
2011-05-19 21:06 <graphitemaster> well I would never reccomend a CISC set for an embedded platform because it's just too complex and pointless in that type of situation
2011-05-19 21:06 <mth> when writing Z80 asm, good register allocation is probably the most important factor for performance
2011-05-19 21:08 <graphitemaster> well I think the worst is RISC does a fine job at splitstreaming instructions to a fair common selection, but does a horrible job at doing a select task in the fewest instructions possible
2011-05-19 21:08 <mth> most C compilers that target Z80 will pass arguments via the stack rather than registers, making the generated code a lot slower than hand-written asm
2011-05-19 21:08 <graphitemaster> with exception to ARMv6
2011-05-19 21:09 <mth> maybe not the actual stack via SP, but some kind of program-managed stack using IX or IY
2011-05-19 21:12 <graphitemaster> I think my biggest issue is most of the older RISC chips has no microcode so they where forced down the pipeline into logical control singnals for the datapaths _directly_ from each instruction bit.  Now take a rather obstruisve program that requires a lot of decodes and the branches will slow down and take FOREVER to resolve and you ruin performance not for the whole program but everything
2011-05-19 21:13 <graphitemaster> I think ARM was the chip that actually broke away from this method which is primarly the reason I like ARM chips these days.
2011-05-19 21:14 <mth> I haven't written any ARM asm yet
2011-05-19 21:14 <mth> last thing I did in asm was MMX and SSE versions of video scaling algorithms
2011-05-19 21:14 <graphitemaster> MMX is pretty useless
2011-05-19 21:14 <graphitemaster> it's deprecated in all newer generation AMD chips
2011-05-19 21:15 <mth> this was over 5 years ago though :)
2011-05-19 21:15 <graphitemaster> well that acounts for something then :)
2011-05-19 21:15 <graphitemaster> I have worked on ARM code before, I find it a delight to work with it's well documented too.
2011-05-19 21:15 <mth> today I probably wouldn't bother with MMX indeed and go straight for SSE2 or GLSL or OpenCL
2011-05-19 21:16 <graphitemaster> SSE4 is pretty suboptimal
2011-05-19 21:16 <graphitemaster> GLSL again does the card support shaders?
2011-05-19 21:17 <graphitemaster> 5 years ago ARB was really the only choice :)
2011-05-19 21:17 <mth> most cards do nowadays
2011-05-19 21:17 <graphitemaster> and ARB was not all that different from ASM the syntax was but the thinking was and still is the same.
2011-05-19 21:17 <graphitemaster> erm thinking was the same the syntax was different *
2011-05-19 21:18 <mth> actually my first GLSL shaders are from 2006 :)
2011-05-19 21:19 <mth> but back then it would only work on certain cards
2011-05-19 21:19 <mth> especially Intel didn't support OpenGL 2.0 for a long time
2011-05-19 21:19 <graphitemaster> Intel still doesn't support half of GL :P
2011-05-19 21:20 <graphitemaster> I've herd cases where you can get better gfx using llvmpipe over Intel then using the native Intel GMA crap :P
2011-05-19 21:20 <graphitemaster> software rasterization at it's finest :)
2011-05-19 21:20 <Jay7> remember LDIR instruction
2011-05-19 21:20 <Jay7> was very useful for graphics :)
2011-05-19 21:21 <mth> on MSX VRAM was not shared with the Z80, so you had to use OTIR instead
2011-05-19 21:22 <graphitemaster> there where quickerways then using LDI LDIR
2011-05-19 21:23 <graphitemaster> usually save the stack pointer, load the hl register pair with zero.  massive loop pushing HL onto the stack, then the stack moves up screen and down through memory and in the process and clears the screen :)
2011-05-19 21:24 <roh> meh
2011-05-19 21:24 <roh> you guys make me feel old.
2011-05-19 21:24 <graphitemaster> I'm 16 years old :P
2011-05-19 21:24 <roh> will be 30 in august and its evil to hear stuff you did when it was new and fancy
2011-05-19 21:25 <graphitemaster> I own a ZX Spectrum I've played with Z80 before :P
2011-05-19 21:25 <roh> my 2 cents: ignore the current seperation of 'X'PU(s)
2011-05-19 21:25 <mth> roh: I'm 35, these are stories from the good old days ;)
2011-05-19 21:26 <roh> there will be cpus which just have N cores and units which will look remarkably like some merge of cpu, gpu, crypto-accel, dsp and maybe we will get even some pld-esque units
2011-05-19 21:27 <roh> all that syncronisation stuff just eats away most of the gain by offloading anyways.
2011-05-19 21:27 <graphitemaster> I think what would be neat is if someone interlocked varations of CPUS from mixed CISC it mixes RISC then made a common interface that could translate op code and offload work on each cpu equally
2011-05-19 21:27 <mth> roh: but will it have a shared memory like current CPUs or local memories like the Cell?
2011-05-19 21:28 <roh> e.g. dma not being faster than simple loops etc. (cloggs memory bus, set up partially complex and needed too often etc)
2011-05-19 21:28 <graphitemaster> generally you can just plugin anything into this core and as many as you wanted and it would work
2011-05-19 21:28 <roh> mth: modern computers are numa cubes anyways. atleast amd based ones since... well.. nearly 10 years now
2011-05-19 21:29 <roh> means every 'cpu' has its own local memory, maybe shared by 2 or more local cores, and there is a shitload of bandwith with low latency to 'other stuff' .. maybe cpus, maybe io (mostly differs in cache coherency)
2011-05-19 21:30 <roh> also i think that these nice products like cell will vanish. their special feats will become mainstream. but specialized cpus like that just make no sense economically
2011-05-19 21:30 <Jay7> is 32 :)
2011-05-19 21:31 <roh> thus.. my bet is on 'we will have fun with new instructions' and lots of cores.
2011-05-19 21:32 <wpwrak> roh: agreed on xPUs. those specialized co-processors come and go. they always end up being absorbed into the principal core sooner or later.
2011-05-19 21:32 <roh> wpwrak: if they make sense, yes
2011-05-19 21:32 <mth> what will we use to program them though?
2011-05-19 21:33 <roh> mth: more uniform than this gpu, dsp, cpu madness right now (which needs specialized tools and knowledge for every sub-arch)
2011-05-19 21:33 <roh> basically: think 'gcc' (replace with clang or what you wish when they finally make it complete)
2011-05-19 21:34 <mth> I don't know C + threads is going to work
2011-05-19 21:34 <mth> threads are horrible things anyway
2011-05-19 21:34 <roh> mth: sure. have a better idea?
2011-05-19 21:34 <mth> not really, that's the problem
2011-05-19 21:35 <graphitemaster> forking
2011-05-19 21:35 <mth> GLSL parallizes very well, because it's basically a functional language with a C-like syntax
2011-05-19 21:35 <mth> but not every algorithm is easy to express in GLSL
2011-05-19 21:36 <mth> *parallellizes (?)
2011-05-19 21:36 <roh> my point is: try syncing 3 of the current cores in a pipeline working on some data... then imagine the cpu is also running a multitasking os with preemtion. then imagine every of these cores using a different compiler from a different company... can you imagine that c-threads somehow sound quite nice compared to the hell you will be in now?
2011-05-19 21:37 <roh> its all nice and shiny as long as you dont need to glue 2 vendor-sdks into one project
2011-05-19 21:39 <roh> also lots of stuff mis-optimized (depending on usecase) isnt in your way anymore. e.g. writing stuff to gpu memory is fast (optimized) .. try reading something back to the cpu memory... takes aeons
2011-05-19 21:40 <roh> compared to a write. has been that way since agp times. so sometimes it even makes sense to do steps on the cpu instead of using the fast way into gpu mem, do some op there (do sync), fetch slowly, do next op which the cpu can but the gpu is too stupid for.
2011-05-19 21:41 <mth> iirc AGP was very asymmertrical with the bandwidth, but on PCI Express the direction shouldn't make much of a difference
2011-05-19 21:41 <roh> so in the end one ends up with optimizing the own usecase, which could mean: do more steps on the cpu even if the gpu is faster not not get your advantage eaten up by slowness in unoptimized memory transfers (which one cannot speed up)
2011-05-19 21:41 <roh> mth: pci-e still is multiple times slower than memory access or a hypertransport link
2011-05-19 21:42 <mth> yes, but CPU->VRAM and VRAM->CPU are both about equally slow
2011-05-19 21:43 <roh> my point is: nowadays gpus arent much more like 5-10 years ago. its mostly a block of shaders with some minimal memory copying logic and a display-readout and fast memory. add the shaders and the memory interface bandwith to the main cpu and you dont loose anything, you only gain
2011-05-19 21:43 <mth> but it's true that fast processing is useless if you can't get the data in/out in time
2011-05-19 21:43 <roh> mth: gpus are optimized for gaming, not your usecase neccessarily.
2011-05-19 21:44 <roh> e.g. all the video and multimedia blitting units are gone. because you can also program a shader to do colorspace conversion
2011-05-19 21:46 <roh> but when it comes to e.g. implementing complex stuff which isnt just doing fast math but assembling packets, shaders suck. not built for that. so compressing data or so isnt their best deed. they can do some steps but the gruntwork usually is done in specialized hw or the cpu and not a programmed shader.
2011-05-19 21:46 <roh> amd is on the right way there. lets hope they dont die from intels constant nagging
2011-05-19 21:47 <roh> and keep supporting free drivers.
2011-05-19 21:48 <mth> I hope that at some point driver support will just be an LLVM backend for a new chip rather than a full driver
2011-05-19 21:48 <roh> i hope we dont need new archs that often
2011-05-19 21:49 <roh> and that llvm gains more working backends. last time i tried it couldnt even generate properly working arm code, not speaking of booting kernels
2011-05-19 21:49 <mth> Apple allows LLVM-compiled apps to be submitted, so it must work most of the time nowadays
2011-05-19 21:50 <mth> I recently managed to compile openMSX (pretty complex C++ code, crashes quite a few GCC versions) with Clang++ and libcxx on x86_64
2011-05-19 21:50 <mth> so it's starting to become useful in production
2011-05-19 21:51 <roh> is there a avr backend?
2011-05-19 21:51 <mth> afaik only x86, x86_64 and ARM are mature backends, the others are experimental
2011-05-19 21:52 <mth> I don't know about AVR support; MIPS support exists but may or may not be usable
2011-05-19 21:52 <roh> meh. that needs to change. multi-arch is the most important feat of gcc.
2011-05-19 21:52 <roh> atleast to me. compilers are annoying enough that i dont want more than one kind to know personally ;)
2011-05-19 21:53 <roh> well.. in the end ist all just a fancy macroassembler, so if you do nice code, the backend shouldnt matter that much nowadays
2011-05-19 21:54 <mth> they have reduced the arch-specific code to a minimum, so that should help in getting more archs supported
2011-05-19 21:54 <mth> I've heard people complain about GCC support for Alpha, so it's not paradise either
2011-05-19 21:55 <roh> alpha is dead. really dead for some time now
2011-05-19 21:55 <roh> all thats nice in there went into x86-64 anyways. and into the design of amd cpus
2011-05-19 21:56 <roh> thats where hypertransport and the numa concept come from.
2011-05-19 21:56 <mth> yep
2011-05-19 21:56 <roh> hppa is also dead. i think mostly mips arm x86-64, x86 and some mcu platforms are important right now
2011-05-19 21:57 <roh> the problem is the sheer number. msp430, avr, infineon has its own 16bit arch... the hitachi stuff.. renesas...  etc
2011-05-19 21:58 <roh> avr is to inprecise. there are 8bit and now also 32bit ones (different arch, avr32)
2011-05-19 22:02 <mth> afk now
2011-05-19 23:53 <qi-bot> [commit] Neil Stockbridge: There is now a libncurses-dev package http://qi-hw.com/p/openwrt-packages/b9ee6f4