Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
xiangfu has joined #qi-hardware
nerd has joined #qi-hardware
panda|x201 has joined #qi-hardware
guanucoluis has joined #qi-hardware
rodgort has joined #qi-hardware
DocScrutinizer05 has joined #qi-hardware
<kyak>
test1
<kyak>
test2
<kyak>
no live updates for me -\
<kyak>
btw. what's the point of live updates for previous dates?
<kyak>
yeah, it updates.. takes around a minutes
_0bitcount has joined #qi-hardware
xiangfu has joined #qi-hardware
jekhor has joined #qi-hardware
panda|x201 has joined #qi-hardware
xiangfu has joined #qi-hardware
wolfspra1l has joined #qi-hardware
kilae has joined #qi-hardware
kuribas has joined #qi-hardware
<whitequark>
kyak: yeah, irc can be quite slow sometimes
<whitequark>
(for the previous dates) oh, that's an UI bug :)
<whitequark>
kyak: actually no, irc has nothing to do with it
<whitequark>
for some reason the stream is not flushed when it should. tcp buffers? I've no idea
<larsc>
in the javascript console i get "streamFailed to load resource" and nothing more
<whitequark>
hmmm
<larsc>
but it does sent a request
<whitequark>
I might figure out the problem if you'd send me a wireshark dump, but I doubt I can do anything about it, actually.
<whitequark>
the "proper" way would be to add one of the huge, bloated libraries with tons of fallbacks
<whitequark>
I don't see any 500's in my log, so the problem is probably with the UA
<larsc>
test
<larsc>
chromium 20 works fine
<larsc>
it's not that important anyway
<viric>
never heard of SSE before
<whitequark>
viric: it's a very neat alternative to websockets where you don't really need bidirectional communication with all of its complexity
<viric>
I see
<viric>
sounds well, yes.
<whitequark>
basically you send out "data: (bytes)\n" lines from the server, and that's it
<viric>
does firefox like it?
<viric>
how much does that irclog stream send? It doesn't stop :)
<viric>
ouch, timestamp 2010. I ctrl-c :)
<whitequark>
viric: ow, I should've placed some limit on that
<whitequark>
viric: yeah, works with FF, as well as other major browsers
<viric>
make it stream the daily log
<viric>
or last 24h
<whitequark>
viric: by default it streams from the last message in the chat. that isn't a public interface technically
<whitequark>
but yeah, last 24h it is
<viric>
why do I see 2010?
<whitequark>
because I've just implemented that :)
<viric>
curl exits
<viric>
502 bad gateway now
<whitequark>
yeah, was upgrading the frontend
<whitequark>
now it works properly
<viric>
Let's see
<viric>
looks fine.
<viric>
does it have keepalive? :)
<whitequark>
viric: nay. the connection drops after 30s of inactivity
<whitequark>
not sure of which reason exactly. there's ruby, nginx, and chromium in the stack
<viric>
becasue it is your will, right?
<viric>
ouch
<whitequark>
I was too lazy to implement keepalive
<viric>
I write all web things in c or go.
<viric>
I can't stand all those piles.
<viric>
I want to attach a gdb and see all.
<viric>
:)
<viric>
Of course, I don't implement much web things.
<whitequark>
the only go program (3rd-party) I've ever used segfaulted like hell
<whitequark>
and as a language it's a step backwards
<viric>
never trust others code.
<whitequark>
so I avoid go.
<whitequark>
ruby, especially as used in webdev, is a huge time-memory tradeoff
<viric>
luckily different preferences can coexist :)
<whitequark>
programmer's time vs RAM
<viric>
well, if the programmer is tuned to ruby, I guess so.
<whitequark>
as it turns out, server RAM is really cheap
<whitequark>
viric: you don't need much time to begin writing good ruby. you don't have to care about a lot of stuff.
<viric>
I've lots of prejudices
<viric>
I'm unable to learn it.
<whitequark>
manual memory management, buffer overflows, threading (because it's single-threaded. perfectly fine for webdev.)
<viric>
due to / thanks to the prejudices
<whitequark>
well, too much handwaving. it's concurrent, albeit most basic operations are atomic, but not parallel. so on the one hand you need to care about synchronization and race conditions IF you write threaded code, but on the other one there isn't much sense in writing in in the first place.
<whitequark>
s,in in,it in,
<viric>
I have a sense of joy when the code I write can run fast and using little resources.
<viric>
And I feel dirty if don't.
<viric>
so it's a matter of religion
<whitequark>
viric: for some people coding is a matter of solving a real problem
<whitequark>
I guess you're not one of them :)
<viric>
that's quite pretentious :)
<viric>
problems can be chosen at will.
<larsc>
it's an art ;)
<whitequark>
I absolutely can't stand huge, bloated JavaScript "webapps". precisely because they waste MY resources for nothing
<viric>
yes. It's important to choose the right problems to solve
<whitequark>
but, in much the same way, I have nothing against using however huge frameworks with literally hundreds of dependencies on OUR servers if it means that we can ship a feature in a day instead of a month.
<whitequark>
the user doesn't see that anyway. for him, it's fast.
<whitequark>
servers are meant to execute huge software, for that matter.
<viric>
it's not my style
<viric>
I'm still not out of the market, despite my preferences :)
<whitequark>
well, market has lots of people who can't program at all
<whitequark>
so that's not a way to measure it :)
<viric>
I mean that I still know people who can pay for my work ;)
<whitequark>
the market for programmers is incredibly heterogenous
<DocScrutinizer51>
m. xmess!
<viric>
yes, that's what I meant at the beginning; that there is a place for all of us
<whitequark>
I know people who write server management software in Haskell
<whitequark>
presumably as a way of intellectual property protection, as it's even more write-only than perl
<whitequark>
which is itself quite an achievement.
<whitequark>
DocScrutinizer51: sounds like an X11 applet name
<viric>
and there, by 'embedded' you mean what? :)
<whitequark>
viric: 32-bit (possibly also 16-bit) micros with von Neumann architecture and however small amounts of RAM you'd like
<whitequark>
8K is perfectly fine.
<viric>
do you run ruby in the nanonote?
<whitequark>
viric: no, because I wasn't able to come up with a task which is best solved by using NN, and no, that's not a good idea
erikkugel has joined #qi-hardware
<viric>
would you write a mp3 player for the nanonote with that?
<whitequark>
viric: in fact mp3 player could work on a NN with current ruby as-is, but that's a different topic
<whitequark>
with my dialect, yes, and even more
<whitequark>
I'd happily write an mp3 decoder
<viric>
ok
<viric>
you'll have to start the show first, before I join :)
<whitequark>
indeed, that's what I'm working on right now
<viric>
ah nice.
<whitequark>
the first target is Maple Leaf: 32-bit ARM Cortex-M3 w/ 8K RAM, 128K ROM and amount of peripherals which would make atmegas envious
<viric>
aha
<whitequark>
the nice thing about that board is that it's swappable with Arduino, which means I'd instantly get access to an ecosystem (of toys, but even toy feedback can be valuable)
<whitequark>
well, almost swappable, sans 5V/3V3 levels
<whitequark>
most of the arduino peripherals are 3V3-safe nowadays
<DocScrutinizer05>
abusing random regulator in LCD as main PSU
<DocScrutinizer05>
for several Ampere @ 5V
<DocScrutinizer05>
haha suuuuure
<DocScrutinizer05>
I mean, that thing is as clumsy and ugly from the outside as it's on schematics ;-D
wej has joined #qi-hardware
<kristianpaul>
let then be happy :-)
<wpwrak>
let me contribute a language rant as well: most of the supposedly "friendly" programming languages are implemented in C. by people who - when done - have learned C well enough that they realize that their effort was wasted. at that point, most will silently bury their work. only those who still don't get it, or who lack the moral strength to admit their mistakes push on. now, gives this background, does it make it a good idea to trust