<mwcampbell>
Is there a way to programmatically adjust the CPU's clock speed?
<pcercuei>
yes, through the sysfs interface
pcercuei has quit [Ping timeout: 260 seconds]
unclouded has joined #qi-hardware
pcercuei has joined #qi-hardware
liuqi has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
pcercuei has quit [Ping timeout: 258 seconds]
<mwcampbell>
On the Ben, is there any reason why an SDL-based UI would be much more efficient than a Qt-based one?
pcercuei has joined #qi-hardware
wolfspraul has joined #qi-hardware
pcercuei has quit [Ping timeout: 260 seconds]
pcercuei has joined #qi-hardware
pcercuei has quit [Read error: No route to host]
pcercuei has joined #qi-hardware
pcercuei has quit [Ping timeout: 258 seconds]
pcercuei has joined #qi-hardware
xiangfu has joined #qi-hardware
pcercuei has quit [Quit: Bye]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
guanucoluis has quit [Ping timeout: 260 seconds]
xiangfu has quit [Ping timeout: 276 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Ping timeout: 240 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Ping timeout: 252 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #qi-hardware
baba has quit [Ping timeout: 246 seconds]
xiangfu has quit [Ping timeout: 276 seconds]
xiangfu has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
baba has joined #qi-hardware
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #qi-hardware
dlan^ has quit [Ping timeout: 258 seconds]
jluis has joined #qi-hardware
apelete has joined #qi-hardware
dlan^ has joined #qi-hardware
jekhor has joined #qi-hardware
xiangfu has quit [Ping timeout: 260 seconds]
rz2k has quit [Read error: Connection reset by peer]
xiangfu has joined #qi-hardware
vignesh885 has joined #qi-hardware
<vignesh885>
hi i have a seagate 1tb external harddisk and it is not being detected by the computer
<vignesh885>
anoyne there??
<valhalla>
vignesh885: which computer? is it related to the nanonote, milkymist or other projects from http://qi-hardware.com ?
<valhalla>
(which is what this channel is about)
lekernel has joined #qi-hardware
vignesh885 has quit [Quit: irc2go]
dlan^ has quit [Remote host closed the connection]
unclouded has quit [Ping timeout: 245 seconds]
jekhor has quit [Ping timeout: 256 seconds]
Calyp has joined #qi-hardware
woakas has quit [Ping timeout: 255 seconds]
woakas has joined #qi-hardware
LunaVorax has joined #qi-hardware
jekhor has joined #qi-hardware
paroneayea has joined #qi-hardware
pcercuei has joined #qi-hardware
LunaVorax has quit [Read error: Connection reset by peer]
jekhor has quit [Ping timeout: 264 seconds]
xiangfu has quit [Ping timeout: 246 seconds]
xiangfu has joined #qi-hardware
pcercuei has quit [Ping timeout: 260 seconds]
xiangfu has quit [Ping timeout: 260 seconds]
xiangfu has joined #qi-hardware
gbraad has quit [Ping timeout: 256 seconds]
megha has joined #qi-hardware
baba has quit [Ping timeout: 264 seconds]
erikkugel has joined #qi-hardware
emeb has joined #qi-hardware
pcercuei has joined #qi-hardware
jekhor has joined #qi-hardware
megha has quit [Ping timeout: 256 seconds]
megha has joined #qi-hardware
Calyp has quit [Ping timeout: 246 seconds]
erikkugel has quit [Quit: Leaving.]
erikkugel has joined #qi-hardware
rz2k has joined #qi-hardware
jluis has quit [Ping timeout: 245 seconds]
xiangfu has quit [Remote host closed the connection]
<kristianpaul>
mwcampbell: i think QT one could be more efficient
<kristianpaul>
in terms of UI and such, also more responsive i think
<larsc>
well qt is not that lightweight
<lekernel>
qt is mega bloat
<lekernel>
use efl
<lekernel>
it's the least sucky toolkit around imo
<mwcampbell>
Can EFL use the framebuffer device directly?
<lekernel>
theoretically yes
<lekernel>
there is code for this, don't know about its bug rate
<whitequark>
lekernel: please, don't spread fud
<whitequark>
qt embedded is very lightweight for such an advanced framework
<lekernel>
oh yeah, it's advanced: it has lists, threads, networking, and what not
<lekernel>
so you end up very easily with code having 2 or more implementations of lists, threads, sockets, etc.
<whitequark>
yes, it's better to write your own shims for various components which were never intended to be used together in each application from scratch
<whitequark>
honestly, I'm not even going to discuss this
<lekernel>
a GUI toolkit should not have threads, networking, etc. - period!
<whitequark>
though I do agree that the set of abstractions provided by UNIX-like OSes is exceptionally shitty
<whitequark>
lekernel: well, it doesn't have an alternative.
<lekernel>
and face it, a statically linked hello world application using qt is over 20MB, lol
<whitequark>
lekernel: um, no, I don't think it is (if you don't link everything there is in Qt, including QtWebkit), or that this even matters
<lekernel>
besides, qt looks ugly, takes times to refresh stuff which causes flashes and transient visual chaos, and uses c++
<whitequark>
my builds of Qt Embedded have had about 8 MB of shared code, which was not duplicated between the applets
<lekernel>
look at the ipad... and then look at qt
<whitequark>
um, you mean look at Cocoa, a gui toolkit which has threads, networking, etc. ?
<lekernel>
can't comment on the internal APIs since I have never tried to use them, but it looks good and it's responsive
<lekernel>
much better than anything else
<whitequark>
this is a bullshit argument, honestly
<whitequark>
do you know the single trick which is required for your app to be that responsible on touchscreen devices?
<whitequark>
do everything GUI-related on a dedicated thread and give it the highest priority.
<whitequark>
this is why android 2.x was slow. this is why android 3/4 isn't anymore. this is the sole reason iOS feels responsive.
<whitequark>
it has absolutely zero things to do with framework design and whatnot
<whitequark>
(ugliness is subjective. I'd rather not touch the glossy shit ever in my life.)
<mwcampbell>
whitequark: Your rebuttal makes sense.
<whitequark>
hehe thanks
<mwcampbell>
So is Qt a reasonable choice for a UI that will be usable on a device with no mouse or touchscreen, like the NanoNote?
<whitequark>
mwcampbell: considering the most recent qt snapshot still fits in the RAM of NN and leaves enough space to run the applications, yes
<lekernel>
if you want to make a shitty GUI "open source always get a second class seat" yes
<whitequark>
lekernel: besides, what do you think one should use instead of C++?
<whitequark>
(please don't say python. for the love of everything good in this world. for kittens.)
<mwcampbell>
lekernel: I don't care about surface aesthetics, as long as I can make the UI responsive. My only concern in that area is whether a framebuffer without GPU acceleration is going to be too inefficient.
<lekernel>
well, lua looks interesting
<whitequark>
mwcampbell: Qt Embedded was originally designed for devices without GPU, well, because when it was designed, there were no such devices.
<lekernel>
and btw "surface" aesthetics is the purpose of a GUI, otherwise use command line
<whitequark>
aestethics has nothing to do with usability. taking your ipad, I can make every corner straight and paint it black&white. it won't get less convenient.
<mwcampbell>
lekernel: The purpose of a GUI is usability. Gradients versus solid backgrounds, 3D versus flat UI, is only skin-deep, and isn't something worth considering IMO when choosing a foundational technology.
<whitequark>
that being said, open source guis probably have the most shitty usability of all software ever written
<whitequark>
be it KDE, GNOME with snake-oil HIG, or whatever
<lekernel>
why should the UI toolkit be a "foundational" technology? they should not have threads, database access, networking, etc.
<whitequark>
lekernel: because it had, and mostly, still has, nothing to be based on.
<whitequark>
pthreads is not a sensible API, BSD sockets is not a sensible API, and so on.
<whitequark>
just as string.h is not a sensible API.
<lekernel>
but how about decoupling the rendering part from sockets, threads, etc.?
<whitequark>
lekernel: it's not coupled?
<lekernel>
well it is: you have QThread, QMYSQL ...
<whitequark>
so?
<lekernel>
why should you need any of this to define what a button looks like, and how it responds to a given event?
<whitequark>
you don't need that?
<mwcampbell>
lekernel: Those are separate libraries.
<whitequark>
don't link QMySQL, don't get it
<mwcampbell>
And if you're linking statically, modern toolchains can even eliminate dead code on a per-function basis
<lekernel>
last time I checked, gcc/binutils still didn't - but don't get me started on that ...
<whitequark>
gcc is not modern :p
<whitequark>
gold has some support for LTO but it never really worked for me
<larsc>
you can put each function in it's own section with gcc
<whitequark>
MSVC can do that, LLVM can do that, ICC can do that, IAR can do that...
<lekernel>
yeah there's -ffunction-sections, but it's a bit messy
<mwcampbell>
combine that with the -gc-sections linker option, and there you have it, dead-code elimination
<mwcampbell>
LTO is better still, of course, since then you can have cross-module inlining
<whitequark>
IPSCCP also
<whitequark>
and DAE
<lekernel>
-ffunction-sections/-gc-sections take forever on a moderately sized program, which I guess is why those options aren't turned on by default
<mwcampbell>
What are IPSCCP and DAE?
<whitequark>
interprocedural sparse conditional constant propagation and dead argument elimination
<whitequark>
well, linking webkit with LTO takes ~8 hours on a 12-core desktop i7, or that's what I've been told
<whitequark>
webkit is also enourmous
<whitequark>
(that was MSVC IIRC)
<mwcampbell>
but apparently the Chrome project considers it worthwhile to do so
<whitequark>
it is.
<whitequark>
especially for Webkit, which is a huge C++ codebase with lots of small, often hot functions.
<mwcampbell>
whitequark: I know I'm getting a bit off-topic here, but can current LTO implementations also detect virtual functions that only have one implementation and turn them into plain functions, to avoid the indirection of a vtable dispatch?
<whitequark>
mwcampbell: no, because you might load alternative implementations at runtime
<larsc>
well, you probably wouldn't do this during development, but for release binaries it makes sense. since you only compile once, but run it quite often
<whitequark>
mwcampbell: though if they're module-internal, then yes, LLVM can do that in some cases
<mwcampbell>
I wonder if the Linux kernel would benefit much from LTO. Of course, that would only be effective if one disabled loadable modules.
<larsc>
there are some people experimenting with lto for the kernel
<whitequark>
mwcampbell: not necessarily
<whitequark>
unless you override existing functions, you still can keep the uninlined version and export the same symbol for modules
<whitequark>
trading off size for performance, of course
<mwcampbell>
I imagine one could achieve another performance boost by combining the application and the OS in one binary, as some RTOSes do, and applying LTO to that. But of course such a system is much less hackable than a general-purpose OS like Linux.
<mwcampbell>
I vaguely remember Qt Embedded having its own windowing system of sorts, so one could at least flip between applications without having to run each one on its own virtual console.
paul_boddie has joined #qi-hardware
<whitequark>
mwcampbell: yeah it has its own framebuffer compositor
<whitequark>
there isn't a way to share a framebuffer otherwise. DFB has its own, GTK... I've no idea but probably the same
<mwcampbell>
Does the version of Qt on the NanoNote have that compositor?
<paul_boddie>
If you want to reduce the "bloat" in Qt, configure it without WebKit.
<paul_boddie>
Besides, the whole reason for providing threading, database stuff in Qt is because somebody has to: C++ doesn't have high-level libraries for that stuff out of the box. Also, the data types in Qt date from a time when the STL wasn't ready for prime time, and I think they're trying to reconcile all that in Qt 5.
<paul_boddie>
Of course, Qt should be more modular and that was a goal of the developers, but they got carried away and made Qt larger and often more reliant on the peripheral libraries because they didn't finish the job (as far as I understand it).
<paul_boddie>
And then some bright spark decided to suck in WebKit and duplicate half the stack (multiple JavaScript, XML libraries), but that may have been in the Nokia era where targeting Symbian was seen as a "good idea".
Calyp has joined #qi-hardware
<mwcampbell>
I observe that the version of Qt in the NanoNote image doesn't have WebKit, so that's not an issue.
<paul_boddie>
You'd have to leave WebKit out of any build for the NanoNote purely for memory exhaustion reasons. I guess you could try and configure it aggressively to only have the fundamental UI stuff. In fact, this is one of the things that Python developers found weird about Qt: that it "duplicated" libraries that you'd normally use instead in Python.
<mwcampbell>
I have no interest in trying to port WebKit to the NanoNote.
<paul_boddie>
Then again, there were benefits to wrapping qtxml or KHTML in Python and having a proper DOM, the latter even with support for stuff like ranges, mostly because of the continuous whining in the Python community about the DOM and their scorched earth retreat from the interactive Web.
<paul_boddie>
s/the interactive Web/supporting and developing client technology for the Web/
<qi-bot>
paul_boddie meant: "Then again, there were benefits to wrapping qtxml or KHTML in Python and having a proper DOM, the latter even with support for stuff like ranges, mostly because of the continuous whining in the Python community about the DOM and their scorched earth retreat from supporting and developing client technology for the Web."
<paul_boddie>
BTW, I read on LWN today that in the Raspberry Pi talk at PyCon, Eben Upton says that they use Python to develop and verify their opaque Broadcom silicon.