2013-09-15 01:25 dos1 has quit [Ping timeout: 256 seconds]
2013-09-15 04:26 xiangfu has joined #qi-hardware
2013-09-15 04:43 Luke-Jr has quit [Ping timeout: 245 seconds]
2013-09-15 04:46 Luke-Jr has joined #qi-hardware
2013-09-15 05:40 viric has quit [Ping timeout: 240 seconds]
2013-09-15 05:44 viric has joined #qi-hardware
2013-09-15 07:14 FDCX_ has joined #qi-hardware
2013-09-15 07:36 jekhor has joined #qi-hardware
2013-09-15 07:50 FDCX has quit [Remote host closed the connection]
2013-09-15 07:53 FDCX has joined #qi-hardware
2013-09-15 07:55 wolfspraul has joined #qi-hardware
2013-09-15 08:07 FDCX has quit [Remote host closed the connection]
2013-09-15 08:10 FDCX has joined #qi-hardware
2013-09-15 08:45 lekernel has joined #qi-hardware
2013-09-15 08:47 kilae has joined #qi-hardware
2013-09-15 09:00 pcercuei has joined #qi-hardware
2013-09-15 09:14 <larsc> wpwrak: we have that CapTouch family of devices, even with Linux drivers
2013-09-15 09:29 <viric> mh this zswap thing may be nice in the nanonote.
2013-09-15 09:34 <pcercuei> it was nice on the Dingoo with LZO
2013-09-15 09:34 <larsc> didn't we already had it long time ago?
2013-09-15 09:34 <pcercuei> it may even be nicer with Snappy or LZ4
2013-09-15 09:35 <viric> larsc: maybe. I've seen it in 3.11
2013-09-15 09:35 <viric> there was that zram thing, before
2013-09-15 09:36 <larsc> it's all the same
2013-09-15 09:37 <viric> auhm is it?
2013-09-15 09:37 <viric> I thought zram made a block device compressed in ram
2013-09-15 09:40 <larsc> http://stackoverflow.com/questions/18437205/difference-between-zram-and-zswap
2013-09-15 09:42 <larsc> so for zswap you need some kind of physical swap space
2013-09-15 09:42 <larsc> for zram you don't
2013-09-15 09:42 <larsc> so yea, me saying 'it's all the same' was wrong
2013-09-15 09:43 <larsc> but zswap + ramfs = zram
2013-09-15 09:43 <larsc> well not exactly
2013-09-15 09:43 <larsc> but kind of
2013-09-15 09:45 <viric> :)
2013-09-15 09:45 <viric> right, that's how I saw it
2013-09-15 09:57 FDCX_ has quit [Ping timeout: 264 seconds]
2013-09-15 10:40 jekhor has quit [Quit: Leaving]
2013-09-15 10:43 wolfspraul has quit [Ping timeout: 260 seconds]
2013-09-15 10:44 wolfspraul has joined #qi-hardware
2013-09-15 10:59 <wpwrak> larsc: hmm, if going cap, i would hope to do it with the resources already in the mcu. all you really need is an ADC.
2013-09-15 11:02 <larsc> and some magic
2013-09-15 11:02 <wpwrak> the main problems i found are material thickness, sensor size, and robustness against voltage swings and maybe other components in the system distorting the capacitance
2013-09-15 11:02 <wpwrak> e.e.g, diodes :)
2013-09-15 11:03 <wpwrak> viric: zsawp is what made my ubb-jtag work :) urtag is very memory-hungry with xilinx
2013-09-15 11:04 <wpwrak> or was is zram ? checking ...
2013-09-15 11:05 <larsc> zram
2013-09-15 11:05 <cde> I sense a great disturbance in the capacitance
2013-09-15 11:06 <wpwrak> yeah, ZRAM. though it is swap ...
2013-09-15 11:08 <whitequark> y u no fix ur jtag
2013-09-15 11:08 <larsc> with zram the compression happens in the block device code, with zswap the compression happens in the swap code
2013-09-15 11:09 <larsc> the end result is very similar though
2013-09-15 11:09 <larsc> if you are going form ram based swap
2013-09-15 11:10 <wpwrak> whitequark: a fix may get a little deep. and it really was just a weekend hack.
2013-09-15 11:10 viric has quit [Remote host closed the connection]
2013-09-15 11:11 <whitequark> wpwrak: it was just word play on the name :)
2013-09-15 11:13 viric has joined #qi-hardware
2013-09-15 11:14 <whitequark> by the way... https://gist.github.com/whitequark/182569b68f3910248c31 and http://imgur.com/PNMhVPJ
2013-09-15 11:15 <whitequark> oh and the resulting assembly: https://gist.github.com/whitequark/b122443b9c83c7ad10f3
2013-09-15 11:15 <whitequark> so my compiler works, and does it quite well :)
2013-09-15 11:16 <wpwrak> which stm32 ?
2013-09-15 11:16 <cde> very cool! I've always wanted to design & build a compiler too :)
2013-09-15 11:16 <whitequark> wpwrak: it's maple leaf... stm32f103cb
2013-09-15 11:16 <cde> whitequark: how long did it took you?
2013-09-15 11:17 <whitequark> cde: it depends on how you measure it
2013-09-15 11:17 <whitequark> the original idea was born two years ago; I knew absolutely nothing about compilers back then
2013-09-15 11:17 <whitequark> so it took a lot of research
2013-09-15 11:18 <whitequark> the latest, hopefully production-quality, iteration of the software itself, written in ocaml, took me about two months of full-time work to write
2013-09-15 11:18 <whitequark> I've tweaked some language features and fixed my type inferencer in that time, too, but mainly it was just a rewrite of Ruby prototype code in ocaml
2013-09-15 11:19 <cde> do you plan on self-hosting-ness at some point? then you could have a self-hosting OS
2013-09-15 11:19 <whitequark> cde: not really, ocaml is OK
2013-09-15 11:19 <whitequark> besides, it uses LLVM as its low-level optimizer and code generator
2013-09-15 11:20 <cde> oh
2013-09-15 11:20 <whitequark> the compiler, which includes an interpreter and type checker/inferencer itself, is 8400LOC
2013-09-15 11:20 <whitequark> tiny
2013-09-15 11:21 <cde> so you feed llvm the ast and it spoouts asm?
2013-09-15 11:21 <whitequark> no, I have my own SSA IR
2013-09-15 11:22 <cde> ah cool. I guess this is where you enforces the types and so on?
2013-09-15 11:22 <whitequark> yes
2013-09-15 11:22 <cde> do you do boundary checking or is it like C?
2013-09-15 11:23 <whitequark> it's safe by default: the language doesn't prohibit direct memory access (it's not java), but all the simple actions, say iterating over an array, are safe
2013-09-15 11:24 <whitequark> in case of iteration, you don't even need bounds checking most of the time
2013-09-15 11:24 <cde> yes true
2013-09-15 11:24 <whitequark> if you have closures, yeah
2013-09-15 11:24 <whitequark> foo[idx] would do checking; foo.unsafe_get(idx) won't.
2013-09-15 11:25 <cde> very cool! btw why the choice of OCaml over say Haskell?
2013-09-15 11:26 <whitequark> ocaml is practical
2013-09-15 11:26 <whitequark> haskell... uh... well if you listen to haskell programmers, sure :)
2013-09-15 11:27 <cde> yeah ocaml is great for parsing
2013-09-15 11:27 <whitequark> *nod*
2013-09-15 11:27 <whitequark> ocaml also has very simple (and I mean C-level simple) runtime representation and native compiler
2013-09-15 11:28 <cde> so you made a safe language that can be used for system programming, is very lightweight and easy to use
2013-09-15 11:28 <whitequark> yes
2013-09-15 11:28 <cde> it kinda sounds too good to be true ;)
2013-09-15 11:28 <whitequark> I had to invent a bag of tricks. :)
2013-09-15 11:32 <whitequark> for example there isn't really a meaningful separate compilation mode
2013-09-15 11:32 <cde> you mean debug/release?
2013-09-15 11:32 <whitequark> no, think of how you can compile several .o files with clang and then link them
2013-09-15 11:33 <cde> ah you mean you compile everything at once
2013-09-15 11:33 <whitequark> it works fine if you have C-like (not C++-like, though) type system
2013-09-15 11:33 <whitequark> it also works fine if you have complete signatures on module (think .o file) boundaries
2013-09-15 11:34 <cde> so no type abstractions I guess?
2013-09-15 11:34 FDCX_ has joined #qi-hardware
2013-09-15 11:34 <whitequark> hmm
2013-09-15 11:34 <whitequark> elaborate?
2013-09-15 11:34 <cde> well, headers defining abstract types that are then implemented
2013-09-15 11:35 <whitequark> ah. yes. I have value types
2013-09-15 11:35 <whitequark> this means that the code using those value types must at least know their size
2013-09-15 11:35 <whitequark> things get much more interesting when you throw automatic memory management into the mix: now code may need to know contents as well
2013-09-15 11:36 <cde> hmm. you could have an opaque type system with a kind of identifier + size
2013-09-15 11:36 <cde> and a module for resolving identifiers to actual code, sort of like a vtable
2013-09-15 11:36 <cde> I'm not sure it would be very efficient though
2013-09-15 11:36 <whitequark> that's unacceptable if it means runtime overhead
2013-09-15 11:37 <whitequark> right now, all calls in foundry are fully static (no indirection) unless explicitly declared as dynamic
2013-09-15 11:37 <whitequark> the result is very strong IPO
2013-09-15 11:37 <whitequark> and I need to keep that
2013-09-15 11:37 <cde> yeah my proposal was more like rtti
2013-09-15 11:37 <cde> it's not really needed for systems programming
2013-09-15 11:37 <whitequark> well it's dumb to have dynamic dispatch over everything
2013-09-15 11:38 <whitequark> too slow.
2013-09-15 11:38 <cde> I think it has some use cases though. consider Qt's slots, it's very flexible and allows connecting objects at runtime
2013-09-15 11:38 <cde> true that Qt does not recommend using it for everything, because of the overhead
2013-09-15 11:39 <whitequark> sure, but you can easily do that within my type system. method(:foo) -> returns a closure with the corresponding signature
2013-09-15 11:40 <cde> oh, you have closures. nice :)
2013-09-15 11:40 dos1 has joined #qi-hardware
2013-09-15 11:40 <whitequark> they're also rather efficient
2013-09-15 11:40 <whitequark> the runtime representation is like struct { e* env; void(*)(e*, ...); }
2013-09-15 11:40 <whitequark> so, two words
2013-09-15 11:41 <whitequark> and liveness of the environment is verified with region inference
2013-09-15 11:41 <whitequark> in fact, with the representation being so simple, LLVM has zero problems inlining such closures, so for example all iterators just naturally get inlined and are as efficient as C loops
2013-09-15 11:41 <whitequark> I didn't even have to do anything :)
2013-09-15 11:45 <cde> it all sounds really cool! you should write a book on your experience creating a language and interfacing with llvm. a lot of people would be interested
2013-09-15 11:46 <whitequark> eh, just grab reference manuals for ocaml and llvm, and dragon book and appel's compiler implementation in ml
2013-09-15 11:46 <whitequark> that's about it :)
2013-09-15 11:46 <cde> oh. ok :)
2013-09-15 11:55 <larsc> in short: RTFM
2013-09-15 11:55 <larsc> ;)
2013-09-15 11:56 <wpwrak> RTFL ;-) L for Library
2013-09-15 12:01 <larsc> wpwrak: I see you don't like parenthesis of any sort
2013-09-15 12:02 <larsc> s/wpwrak/whitequark/
2013-09-15 12:02 <qi-bot> larsc meant: "whitequark: I see you don't like parenthesis of any sort"
2013-09-15 12:08 pcercuei has quit [Read error: Connection reset by peer]
2013-09-15 12:09 pcercuei has joined #qi-hardware
2013-09-15 12:13 <whitequark> larsc: hm?
2013-09-15 12:13 <whitequark> not sure what you mean
2013-09-15 12:14 <larsc> LCD.setup\n
2013-09-15 12:15 <whitequark> ah, good old syntax holy war :)
2013-09-15 12:16 <whitequark> since I don't have field accesses (e.g. "backlight=" is a method), it doesn't make sense to require parentheses here
2013-09-15 12:17 <whitequark> perhaps you're interested in the implementation of that LCD class: https://gist.github.com/whitequark/40447e26eb3be8132ab1
2013-09-15 12:18 <whitequark> and the GPIO register block: https://gist.github.com/whitequark/17cad7fec8dbcb632014
2013-09-15 12:19 <whitequark> and the metaprogramming which defines register field accessors: https://gist.github.com/whitequark/e2b75c8f125097f1a851
2013-09-15 12:20 <wpwrak> larsc: would apply to me, too :)   ((a == 1) || (b == 2))  makes me angry
2013-09-15 12:31 xiangfu has quit [Ping timeout: 264 seconds]
2013-09-15 12:33 xiangfu has joined #qi-hardware
2013-09-15 12:44 <ysionneau> 13:14 < whitequark> by the way... https://gist.github.com/whitequark/182569b68f3910248c31 and http://imgur.com/PNMhVPJ       kilae
2013-09-15 12:46 <ysionneau> oops
2013-09-15 12:55 <whitequark> oh?
2013-09-15 13:12 rz2k has joined #qi-hardware
2013-09-15 13:19 xiangfu has quit [Remote host closed the connection]
2013-09-15 13:23 xiangfu has joined #qi-hardware
2013-09-15 13:31 jekhor has joined #qi-hardware
2013-09-15 14:00 qwebirc61921 has joined #qi-hardware
2013-09-15 14:00 qwebirc61921 is now known as rjeffries
2013-09-15 14:01 <rjeffries> wpwrak said yesterday: or the jog wheel, i have two options: a 22 mm wheel with rotation and a center button. or a 32 mm wheel with rotation, center button, and four "cursor keys"
2013-09-15 14:02 <rjeffries> IMO the 2nd option would be more useable. the extra size is worth having cursor keys. ymmv
2013-09-15 14:14 jekhor has quit [Ping timeout: 264 seconds]
2013-09-15 14:21 FDCX_ has quit [Remote host closed the connection]
2013-09-15 14:24 FDCX_ has joined #qi-hardware
2013-09-15 14:31 <wpwrak> dunno. first, the size increase is substantial: more than +1/3. and it also gets a little thicker. second, with so many functions crammed into a single device one may trigger other movements than the one intended.
2013-09-15 14:31 <rjeffries> Today is Sunday, in USA. Quiet.
2013-09-15 14:32 <wpwrak> but i've ordered a few of the big wheels, too, so i can experiment :)
2013-09-15 14:32 <rjeffries> cool
2013-09-15 14:32 <rjeffries> which display did you choose, remind me pls
2013-09-15 14:34 <wpwrak> i'll first evaluate this one: http://www.buy-display.com/default/oled-graphic-display.html
2013-09-15 14:34 <wpwrak> no choice has been made yet :) i first have to see it
2013-09-15 14:39 <whitequark> oled ones are quite expensive and degrade, no?
2013-09-15 14:44 <wpwrak> whitequark: about 170% the price of an LCD the same size. dunno if they all degrade or only some. in any case, that one should at least not suffer aging due to excessive use :)
2013-09-15 14:44 <wpwrak> i have LCDs as plan B: http://www.buy-display.com/default/128x64-st7565p-lcd-module.html
2013-09-15 14:44 <whitequark> oh, they got cheaper since I last looked
2013-09-15 14:44 <whitequark> (which is to be expected)
2013-09-15 14:45 <wpwrak> big disadvantage of most LCDs is that they always draw maximum power for the backlight
2013-09-15 14:45 <whitequark> transflective lcds?
2013-09-15 14:47 <whitequark> i.e. what about transflective lcds? they can be used without backlight.
2013-09-15 14:49 <wpwrak> unsure about sourcing. also, they usually have poor contrast.
2013-09-15 14:52 <whitequark> yeah, true
2013-09-15 14:52 <whitequark> talking about degrading
2013-09-15 14:52 <whitequark> I had a phone with an OLED display
2013-09-15 14:52 <whitequark> degrading *is* noticeable (especially if it heats up, which it *of course* does), but unless you look at photos, it doesn't make a difference
2013-09-15 14:52 <whitequark> no idea how much different your display will be
2013-09-15 14:54 <wpwrak> we'll see :) i should get it this week
2013-09-15 14:57 <rjeffries> (high) contrast is your friend in this use case. and this display will almost always be OFF so wear is unimportant IMO
2013-09-15 14:59 <whitequark> >Interface 6800 8-bit Parallel , 8080 8-bit Parallel , I2C, 3-Wire Serial SPI, 4-Wire Serial SPI
2013-09-15 14:59 <whitequark> do *all* displays have the same set of interfaces?
2013-09-15 15:00 <whitequark> I recently had an, uh, pleasure to write a few drivers and they look almost exactly alike.
2013-09-15 15:00 <larsc> there aren't that many display controller vendors
2013-09-15 15:00 <wpwrak> yeah, that's pretty much identical for all displays
2013-09-15 15:01 <wpwrak> 6800 and 8080 look kinda suckish. i'll just go with 4-wire SPI
2013-09-15 15:01 <whitequark> it's fine if you don't need fast updates.
2013-09-15 15:01 <wpwrak> annoyingly, they don't bring out the frame sync signal, so there will be tearing
2013-09-15 15:01 <whitequark> though, this one is b&w... could work regardless
2013-09-15 15:06 <rjeffries> wpwrak for the safe to work in conjunction with a mobile phone or tablet, that device must support (???) USB OTG that allows external keyboard?
2013-09-15 15:10 xiangfu has quit [Remote host closed the connection]
2013-09-15 15:13 <wpwrak> yes. well, for now via an external box. so you don't see it if you don't use it. (it's just a micro-AB receptacle instead of micro-B)
2013-09-15 15:29 lekernel has quit [Read error: Connection reset by peer]
2013-09-15 15:42 <rjeffries> I need to investigate (I am ignorant) how widely the popular mobile phones implement OTG, It's not a universal, I'm pretty sure. will look into this point.
2013-09-15 15:43 <wpwrak> i'm thinking of just implementing A/B detection. not the fancy negotiation protocol
2013-09-15 15:44 lekernel has joined #qi-hardware
2013-09-15 15:47 <wpwrak> hmm, pcb gets mightly crowded
2013-09-15 15:49 <rjeffries> you do not need complications at this stage. KISS rules. having said that...
2013-09-15 15:50 <rjeffries> a future possibly derivative product targeted squarely at mobile devices woudl have appeal. USB in that case may not be preferred connection between safe and mobile
2013-09-15 15:52 <rjeffries> blue sky... NFC or Bluetooth Low Energy might be attractive to users, but may also be way outside teh scope of what you wish to attempt. that's fair.
2013-09-15 15:53 <whitequark> uh, nfc is easily hijacked from afar
2013-09-15 15:55 <wpwrak> BT would be nice. is there a chip/module that's flexible enough, can be sourced, and has publicly-accessible documentation ?
2013-09-15 15:55 <rjeffries> is that true when power levels are REALLY low? physics is on our side. LOL  but my point (for 2014 maybe) is MOBILE is the majority computing device now, period. one eventually want to solve password issue for tablets and smartphones
2013-09-15 15:57 <rjeffries> wpwrak those are great questions, while you focus on USB (wisely) others including me can poke at BLE devices. Your requirment on open documentation may or may not be met, I dunno
2013-09-15 15:58 <wpwrak> that requirement is pretty crucial ... :)
2013-09-15 15:58 <rjeffries> I get it
2013-09-15 15:58 <whitequark> wpwrak: define "documentation"
2013-09-15 15:59 <whitequark> pretty much all BT modules I've seen had docs in public
2013-09-15 16:13 <wpwrak> and did they implement more than just UART ? :)
2013-09-15 16:14 <rjeffries> whitequark: that's useful to know! re BT technical documentation. BT chip cost must also be VERY (!) low these days. although high volume stuff is prolly buried in an SoC that also does e.g. wi-fi and more
2013-09-15 16:14 <roh> wpwrak: on bt you usually have the choice between hci via usb or serial and 'stack in the module' via serial where you use AT-commands to configure the stack and only get a 'serial via bt' link
2013-09-15 16:15 <roh> some can also do audio feats on the module, but thats not the point for your app.
2013-09-15 16:15 <wpwrak> USB .. the idea low-power interface :)
2013-09-15 16:16 <roh> wpwrak: usb is often choosen not because of simplicity or power needs, but because there is nothing which has real serialports on it around
2013-09-15 16:17 <roh> also serialports never had a power-line and some negot. for that with it... and 'multi-link bundling'.
2013-09-15 16:18 <roh> if there'd be a serial conn, which is smaller than sub-d9, widely used (doesnt exist) and has power, people whould use that.
2013-09-15 16:18 Luke-Jr has quit [Excess Flood]
2013-09-15 16:18 <roh> ah.. and also serial usually maxes out at 1-2 mbit.... usb doesnt. thats why its often used in addition to serials too. from 3g on, serial is too slow, also for audio out of a bt module (when decompressed there)
2013-09-15 16:18 Luke-Jr has joined #qi-hardware
2013-09-15 16:19 <whitequark> also protocols
2013-09-15 16:19 <whitequark> everyone invents their own on serial
2013-09-15 16:26 jekhor has joined #qi-hardware
2013-09-15 16:31 FDCX_ has quit [Remote host closed the connection]
2013-09-15 16:47 jekhor has quit [Ping timeout: 264 seconds]
2013-09-15 16:47 jekhor has joined #qi-hardware
2013-09-15 16:48 <roh> whitequark: yes. and sometimes no. i mean.. some hdlc usually should be ok
2013-09-15 16:48 <roh> thats how the people i know do it ;)
2013-09-15 17:12 <rjeffries> whitequark: can you suggest some BT modules that might be candidates?
2013-09-15 17:25 pcercuei has quit [Ping timeout: 278 seconds]
2013-09-15 17:31 pcercuei has joined #qi-hardware
2013-09-15 17:36 Luke-Jr has quit [Excess Flood]
2013-09-15 17:38 luke-jr_ has joined #qi-hardware
2013-09-15 17:51 luke-jr_ is now known as Luke-Jr
2013-09-15 18:25 rjeffries has quit [Ping timeout: 250 seconds]
2013-09-15 18:47 <qi-bot> [commit] Werner Almesberger: modules/qfn.fpd: add QFN48-Freescale for KL25 chips (draft) (master) http://qi-hw.com/p/kicad-libs/e8e6813
2013-09-15 18:47 <qi-bot> [commit] Werner Almesberger: components/: add Freescale Kinetis KL25 in 48 pin package (master) http://qi-hw.com/p/kicad-libs/38cb8de
2013-09-15 18:48 <qi-bot> [commit] Werner Almesberger: add EastRising OLED FPC-30 connector (symbol and footprint) (master) http://qi-hw.com/p/kicad-libs/2c26373
2013-09-15 18:48 <qi-bot> [commit] Werner Almesberger: components/memcard8.lib: add MEMCARD8-SHIELD3-SW1 for Amphenol 10100660 (master) http://qi-hw.com/p/kicad-libs/4a9b06e
2013-09-15 18:48 <qi-bot> [commit] Werner Almesberger: modules/memcard8-amp-10100660.fpd: Amphenol 10100660 footprint (draft) (master) http://qi-hw.com/p/kicad-libs/81c2a48
2013-09-15 18:48 <qi-bot> [commit] Werner Almesberger: flip er-oled-fpc30.fpd; add new footprints to Makefile; fix comp ref in kl25-48.lib (master) http://qi-hw.com/p/kicad-libs/2aa3233
2013-09-15 18:53 pcercuei_ has joined #qi-hardware
2013-09-15 18:56 pcercuei has quit [Ping timeout: 264 seconds]
2013-09-15 18:57 FDCX_ has joined #qi-hardware
2013-09-15 19:07 pcercuei_ is now known as pcercuei
2013-09-15 19:19 <qi-bot> [commit] Werner Almesberger: add C&K TSWA series switch with 22 mm wheel (master) http://qi-hw.com/p/kicad-libs/3f1b978
2013-09-15 19:19 <qi-bot> [commit] Werner Almesberger: HIERARCHY: change QFN32-Freescale to QFN48-Freescale (master) http://qi-hw.com/p/kicad-libs/a6aca6e
2013-09-15 19:34 porchao has quit [Quit: Leaving...]
2013-09-15 19:34 jekhor has quit [Ping timeout: 264 seconds]
2013-09-15 19:58 <whitequark> huh http://www.caravan.net/ec2plus/
2013-09-15 20:18 <wpwrak> removes templates, inheritance, and all that nonsense ?
2013-09-15 20:26 <larsc> yeay, party like it is 1999
2013-09-15 20:32 <whitequark> yeah
2013-09-15 20:32 <whitequark> what is the point of using C++ if you don't have any of that?..
2013-09-15 20:35 heberth has joined #qi-hardware
2013-09-15 20:42 <larsc> From their Q&A 'Why is X removed? X it is too new to be used widely.'
2013-09-15 20:43 <larsc> but given that the page was last updated 2002 I think it is safe to assume that the project is dead
2013-09-15 20:43 wolfspraul has quit [Quit: leaving]
2013-09-15 20:44 <whitequark> that is a strange rationale nevertheless
2013-09-15 20:44 <whitequark> if we've followed this logic, we'd still be writing assembly :)
2013-09-15 21:07 rz2k has quit []
2013-09-15 21:40 viric has quit [Ping timeout: 240 seconds]
2013-09-15 21:46 viric has joined #qi-hardware
2013-09-15 21:51 kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]]
2013-09-15 22:01 viric has quit [Ping timeout: 240 seconds]
2013-09-15 22:02 arossdotme has joined #qi-hardware
2013-09-15 22:03 viric has joined #qi-hardware
2013-09-15 22:08 zear_ has joined #qi-hardware
2013-09-15 22:10 zear has quit [Ping timeout: 240 seconds]
2013-09-15 22:11 zear_ has quit [Read error: Connection reset by peer]
2013-09-15 22:17 zear has joined #qi-hardware
2013-09-15 22:25 arossdotme has quit [Ping timeout: 245 seconds]
2013-09-15 22:30 lekernel has quit [Quit: Leaving]
2013-09-15 22:30 arossdotme has joined #qi-hardware
2013-09-15 22:53 FDCX_ has quit [Ping timeout: 260 seconds]