<larsc>
so for zswap you need some kind of physical swap space
<larsc>
for zram you don't
<larsc>
so yea, me saying 'it's all the same' was wrong
<larsc>
but zswap + ramfs = zram
<larsc>
well not exactly
<larsc>
but kind of
<viric>
:)
<viric>
right, that's how I saw it
FDCX_ has quit [Ping timeout: 264 seconds]
jekhor has quit [Quit: Leaving]
wolfspraul has quit [Ping timeout: 260 seconds]
wolfspraul has joined #qi-hardware
<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.
<larsc>
and some magic
<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
<wpwrak>
e.e.g, diodes :)
<wpwrak>
viric: zsawp is what made my ubb-jtag work :) urtag is very memory-hungry with xilinx
<wpwrak>
or was is zram ? checking ...
<larsc>
zram
<cde>
I sense a great disturbance in the capacitance
<wpwrak>
yeah, ZRAM. though it is swap ...
<whitequark>
y u no fix ur jtag
<larsc>
with zram the compression happens in the block device code, with zswap the compression happens in the swap code
<larsc>
the end result is very similar though
<larsc>
if you are going form ram based swap
<wpwrak>
whitequark: a fix may get a little deep. and it really was just a weekend hack.
viric has quit [Remote host closed the connection]
<whitequark>
wpwrak: it was just word play on the name :)
<whitequark>
so my compiler works, and does it quite well :)
<wpwrak>
which stm32 ?
<cde>
very cool! I've always wanted to design & build a compiler too :)
<whitequark>
wpwrak: it's maple leaf... stm32f103cb
<cde>
whitequark: how long did it took you?
<whitequark>
cde: it depends on how you measure it
<whitequark>
the original idea was born two years ago; I knew absolutely nothing about compilers back then
<whitequark>
so it took a lot of research
<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
<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
<cde>
do you plan on self-hosting-ness at some point? then you could have a self-hosting OS
<whitequark>
cde: not really, ocaml is OK
<whitequark>
besides, it uses LLVM as its low-level optimizer and code generator
<cde>
oh
<whitequark>
the compiler, which includes an interpreter and type checker/inferencer itself, is 8400LOC
<whitequark>
tiny
<cde>
so you feed llvm the ast and it spoouts asm?
<whitequark>
no, I have my own SSA IR
<cde>
ah cool. I guess this is where you enforces the types and so on?
<whitequark>
yes
<cde>
do you do boundary checking or is it like C?
<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
<whitequark>
in case of iteration, you don't even need bounds checking most of the time
<cde>
yes true
<whitequark>
if you have closures, yeah
<whitequark>
foo[idx] would do checking; foo.unsafe_get(idx) won't.
<cde>
very cool! btw why the choice of OCaml over say Haskell?
<whitequark>
ocaml is practical
<whitequark>
haskell... uh... well if you listen to haskell programmers, sure :)
<cde>
yeah ocaml is great for parsing
<whitequark>
*nod*
<whitequark>
ocaml also has very simple (and I mean C-level simple) runtime representation and native compiler
<cde>
so you made a safe language that can be used for system programming, is very lightweight and easy to use
<whitequark>
yes
<cde>
it kinda sounds too good to be true ;)
<whitequark>
I had to invent a bag of tricks. :)
<whitequark>
for example there isn't really a meaningful separate compilation mode
<cde>
you mean debug/release?
<whitequark>
no, think of how you can compile several .o files with clang and then link them
<cde>
ah you mean you compile everything at once
<whitequark>
it works fine if you have C-like (not C++-like, though) type system
<whitequark>
it also works fine if you have complete signatures on module (think .o file) boundaries
<cde>
so no type abstractions I guess?
FDCX_ has joined #qi-hardware
<whitequark>
hmm
<whitequark>
elaborate?
<cde>
well, headers defining abstract types that are then implemented
<whitequark>
ah. yes. I have value types
<whitequark>
this means that the code using those value types must at least know their size
<whitequark>
things get much more interesting when you throw automatic memory management into the mix: now code may need to know contents as well
<cde>
hmm. you could have an opaque type system with a kind of identifier + size
<cde>
and a module for resolving identifiers to actual code, sort of like a vtable
<cde>
I'm not sure it would be very efficient though
<whitequark>
that's unacceptable if it means runtime overhead
<whitequark>
right now, all calls in foundry are fully static (no indirection) unless explicitly declared as dynamic
<whitequark>
the result is very strong IPO
<whitequark>
and I need to keep that
<cde>
yeah my proposal was more like rtti
<cde>
it's not really needed for systems programming
<whitequark>
well it's dumb to have dynamic dispatch over everything
<whitequark>
too slow.
<cde>
I think it has some use cases though. consider Qt's slots, it's very flexible and allows connecting objects at runtime
<cde>
true that Qt does not recommend using it for everything, because of the overhead
<whitequark>
sure, but you can easily do that within my type system. method(:foo) -> returns a closure with the corresponding signature
<cde>
oh, you have closures. nice :)
dos1 has joined #qi-hardware
<whitequark>
they're also rather efficient
<whitequark>
the runtime representation is like struct { e* env; void(*)(e*, ...); }
<whitequark>
so, two words
<whitequark>
and liveness of the environment is verified with region inference
<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
<whitequark>
I didn't even have to do anything :)
<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
<whitequark>
eh, just grab reference manuals for ocaml and llvm, and dragon book and appel's compiler implementation in ml
<whitequark>
that's about it :)
<cde>
oh. ok :)
<larsc>
in short: RTFM
<larsc>
;)
<wpwrak>
RTFL ;-) L for Library
<larsc>
wpwrak: I see you don't like parenthesis of any sort
<larsc>
s/wpwrak/whitequark/
<qi-bot>
larsc meant: "whitequark: I see you don't like parenthesis of any sort"
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #qi-hardware
<whitequark>
larsc: hm?
<whitequark>
not sure what you mean
<larsc>
LCD.setup\n
<whitequark>
ah, good old syntax holy war :)
<whitequark>
since I don't have field accesses (e.g. "backlight=" is a method), it doesn't make sense to require parentheses here
xiangfu has quit [Remote host closed the connection]
xiangfu has joined #qi-hardware
jekhor has joined #qi-hardware
qwebirc61921 has joined #qi-hardware
qwebirc61921 is now known as rjeffries
<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"
<rjeffries>
IMO the 2nd option would be more useable. the extra size is worth having cursor keys. ymmv
jekhor has quit [Ping timeout: 264 seconds]
FDCX_ has quit [Remote host closed the connection]
FDCX_ has joined #qi-hardware
<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.
<rjeffries>
Today is Sunday, in USA. Quiet.
<wpwrak>
but i've ordered a few of the big wheels, too, so i can experiment :)
<rjeffries>
cool
<rjeffries>
which display did you choose, remind me pls
<wpwrak>
no choice has been made yet :) i first have to see it
<whitequark>
oled ones are quite expensive and degrade, no?
<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 :)
<whitequark>
oh, they got cheaper since I last looked
<whitequark>
(which is to be expected)
<wpwrak>
big disadvantage of most LCDs is that they always draw maximum power for the backlight
<whitequark>
transflective lcds?
<whitequark>
i.e. what about transflective lcds? they can be used without backlight.
<wpwrak>
unsure about sourcing. also, they usually have poor contrast.
<whitequark>
yeah, true
<whitequark>
talking about degrading
<whitequark>
I had a phone with an OLED display
<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
<whitequark>
no idea how much different your display will be
<wpwrak>
we'll see :) i should get it this week
<rjeffries>
(high) contrast is your friend in this use case. and this display will almost always be OFF so wear is unimportant IMO
<whitequark>
>Interface 6800 8-bit Parallel , 8080 8-bit Parallel , I2C, 3-Wire Serial SPI, 4-Wire Serial SPI
<whitequark>
do *all* displays have the same set of interfaces?
<whitequark>
I recently had an, uh, pleasure to write a few drivers and they look almost exactly alike.
<larsc>
there aren't that many display controller vendors
<wpwrak>
yeah, that's pretty much identical for all displays
<wpwrak>
6800 and 8080 look kinda suckish. i'll just go with 4-wire SPI
<whitequark>
it's fine if you don't need fast updates.
<wpwrak>
annoyingly, they don't bring out the frame sync signal, so there will be tearing
<whitequark>
though, this one is b&w... could work regardless
<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?
xiangfu has quit [Remote host closed the connection]
<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)
lekernel has quit [Read error: Connection reset by peer]
<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.
<wpwrak>
i'm thinking of just implementing A/B detection. not the fancy negotiation protocol
lekernel has joined #qi-hardware
<wpwrak>
hmm, pcb gets mightly crowded
<rjeffries>
you do not need complications at this stage. KISS rules. having said that...
<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
<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.
<whitequark>
uh, nfc is easily hijacked from afar
<wpwrak>
BT would be nice. is there a chip/module that's flexible enough, can be sourced, and has publicly-accessible documentation ?
<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
<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
<wpwrak>
that requirement is pretty crucial ... :)
<rjeffries>
I get it
<whitequark>
wpwrak: define "documentation"
<whitequark>
pretty much all BT modules I've seen had docs in public
<wpwrak>
and did they implement more than just UART ? :)
<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
<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
<roh>
some can also do audio feats on the module, but thats not the point for your app.
<wpwrak>
USB .. the idea low-power interface :)
<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
<roh>
also serialports never had a power-line and some negot. for that with it... and 'multi-link bundling'.
<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.
Luke-Jr has quit [Excess Flood]
<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)
Luke-Jr has joined #qi-hardware
<whitequark>
also protocols
<whitequark>
everyone invents their own on serial
jekhor has joined #qi-hardware
FDCX_ has quit [Remote host closed the connection]
jekhor has quit [Ping timeout: 264 seconds]
jekhor has joined #qi-hardware
<roh>
whitequark: yes. and sometimes no. i mean.. some hdlc usually should be ok
<roh>
thats how the people i know do it ;)
<rjeffries>
whitequark: can you suggest some BT modules that might be candidates?
<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