<cr1901_modern>
If Raspberry Pi's price point is only possible b/c of Broadcom leverage (i.e. a "normal" SBC project wouldn't have the vendor relationships to negotiate pricing), how can a project claiming to be superior to RPi in every way be able to sell an SBC for half the price?
<sb0>
i guess a combination of: do the same with another vendor, cost of chips falling, chip being a relatively small fraction of the cost of those devices anyway
<cr1901_modern>
Looks like the RAM alone adds $4 to the cost
<cr1901_modern>
if the difference between the 512MB and 1G model is any indication
<sb0>
in more exciting news, whitequark was looking yesterday at MPW ASIC runs, which have become really cheap recently
<cr1901_modern>
Define "really cheap".
<sb0>
raspberry pi et. al. will nicely steal the oxygen of any open source alternative, but for other applications/markets, that can be interesting
<sb0>
iirc ~2k USD for a few mm2 of 350nm
<cr1901_modern>
Well, the price is definitely going down indeed. Still out of *my* range, but that'll probably be fixed soon enough
<cr1901_modern>
I would love to get my own ASICs made, but I don't think I could do it right. I can't even identify transistors when given a picture of a die.
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<cr1901_modern>
John McMaster's site can help me fix that problem I suppose.
<larsc>
well you don't have to etch them by hand
<cr1901_modern>
larsc: I've been told it's "not as simple as" just placing standard cell library entries onto a die, and that fun analog effects come into play.
<larsc>
you probably still have to know what you are doing
<larsc>
developing an application is also more than just calling into standard library functions
<larsc>
but as things progress custom ASICs will eat into a market section where currently only FPGAs are viable
<cr1901_modern>
I've always found studying transistors and how electrons flow through them quite a bit harder than learning how a language maps to assembly instructions XD
<cr1901_modern>
I'm just not good w/ materials :(.
<whitequark>
fun fact: most engineers don't understand how transistors work
<whitequark>
horowitz & hill is quite helpful
<larsc>
you don't have to understand how they work, only how they behave
<sb0>
oh, that reminds me of a discussion about electric charge and capacitors in #qi-hardware years ago...
<whitequark>
larsc: not understanding how they work impedes creating a proper mental model and thus understanding how they behave
<whitequark>
sb0: which one?
<sb0>
DocScrutinizer preaching that EEs should not know anything about charge
<larsc>
whitequark: depends, understanding how it works will allow you to make certain optimizations, but not understanding won't prevent you from using them
<whitequark>
well, you don't have to understand how they behave to use them. just copy-paste well-known usage patterns
<whitequark>
this happens all too often. i was certainly guilty for many years
<larsc>
but then you don't use the element itself, but the pattern
<larsc>
but anyway
<larsc>
lunch break is over
<cr1901_modern>
sb0: Hrm. For circuit models, which are current-based, I'd agree. Definitely not for fabrication tho XD
<sb0>
god do i hate airline yield management and those useless RTW tickets
<cr1901_modern>
I have two electronics books. Horowitz and Hill for general purpose reference. And Sedra and Smith which is a more detailed reference.
<sb0>
useless as in: as expensive as throwaway+hidden city ticketing, except it locks you to one airline alliance plus their booking system proposes you lousy connections so as to reduce the load on normally-booked popular routes
<sb0>
those last two points result in ridiculous layovers and unnecessary flights
<sb0>
i wish i could just call them and tell them to stop playing their games, they're wasting my time and i'm wasting their seats, everyone loses
<whitequark>
i wonder if some kind of travel agent could do exactly that
<whitequark>
of course, most of them are just a human interface to hipmunk.com...
<sb0>
they won't, because airlines will expel them if they do
<sb0>
they also go after passengers sometimes, but that's rare
<cr1901_modern>
^and you know this because... :P?
<sb0>
google
<cr1901_modern>
Fair enough lol
<sb0>
"sort by agony" on hipmunk.com :)
<sb0>
hmm, it doesn't show delta, which has the second-fastest HKG->DEN connection, and unlike the fastest (united) has wifi and power on the long haul...
<sb0>
(and the duration difference is a dozen minutes)
<sb0>
air france are the worst i've seen with that shit, one-ways are more than 3x the price of round trips, they also track your past searches to give you the impression that the prices are continuously rising
<sb0>
plus their subsidiary air france consulting gives seminars about this sort of crap to other companies
<cr1901_modern>
sb0: Qt 4 compat is required, correct? Is that one reason you always import from quamash?
<cr1901_modern>
(quamash seems to be able to in some, but not all, cases, handle incompatibilities between PyQt4 and 5)
<sb0>
cr1901_modern, qt4 compat is nice but not an absolute requirement. though as far as i can tell, it is also easy.
<cr1901_modern>
I'm not sure why, but in artiq/frontend/artiq_gui.py, you subclass QMainWindow using the QtGui module imported from quamash
<cr1901_modern>
When I do the same in my "main" module, I get an AttributeError: PyQt5.QtGui has no attribute QMainWindow
<whitequark>
it's in QtWidgets I think
<whitequark>
oh right, quamas
<cr1901_modern>
It is indeed, in PyQt5
<cr1901_modern>
but in quamash, it does some import magic to make it available in QtGui
<cr1901_modern>
that is somehow failing in my dummy app...
<whitequark>
tbh we'd be better off if we get rid of quamash
<cr1901_modern>
It's not required for PyQt to work?
<sb0>
cr1901_modern, is it also available in QtWidget from Quamash?
<whitequark>
oh, ugh, I misunderstood what quamash did
<whitequark>
why the fuck does it poke around in the global Qt namespace?!
<cr1901_modern>
sb0: QtWidget works fine
<whitequark>
python ecosystem is shit, issue #147
<sb0>
cr1901_modern, we should stick to the original Qt namespace in ARTIQ as well...
<cr1901_modern>
so why does QtGui work fine in artiq_gui? Hrm...
<cr1901_modern>
Alright, that was my follow up q
<cr1901_modern>
whitequark: My guess is b/c quamash supports both PyQt 4 and 5, and wants to provide a unified interface
<cr1901_modern>
that apparently doesn't work properly
<whitequark>
yeah, it should've been split into quamash4 and quamash5
<whitequark>
it's not even large
<sb0>
cr1901_modern, it definitely doesn't, I have places in artiq where I need to try both imports to support both qt versions
<cr1901_modern>
sb0: Okay, so get this bullshit; just for kicks, comment out the pyqtgraph import from artiq_gui.py
<cr1901_modern>
Your QtGui imports will fail
<cr1901_modern>
(Assuming that Python doesn't choke on the lack of dockarea first)
<cr1901_modern>
But adding "from pyqtgraph import dockarea" to my dummy application makes it succeed
<cr1901_modern>
So I'm not sure what to do to make it run on both PyQt4 and 5 if the idea is to remove pyqtgraph, or loosen it's influence as a dependency
<cr1901_modern>
For convenience, I have uploaded my template main as a gist
<sb0>
of course, the pyqtgraph dock size management code is completely dysfunctional, which is why some artiq popup windows have grossly inappropriate sizes right now
<GitHub103>
[artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/v0vld