#qi-hardware IRC log for Monday, 2012-10-08

qi-bot[commit] Xiangfu: debian: cleanup on control file (master) http://qi-hw.com/p/fped/d2daaf802:56
rohwpwrak: http://reprap.org/wiki/MetalicaRap03:26
qi-bot[commit] Xiangfu: debian: cleanup changelog, include debian build flags (master) http://qi-hw.com/p/fped/d76f7d103:48
qi-bot[commit] Xiangfu: transfer build flags from outside (master) http://qi-hw.com/p/fped/5b2149504:12
kyakmth: jz-3.5, Windows 7, infamous error code 10 :(04:27
kyaki'll be waiting for 3.6 then04:28
kyakmth: perhaps it makes sense to revert the RNDIS commit, since it doesn't work anyway (giving people a chance to use the CDC driver on Windows). Also, qi_lb60_defconfig should be changed to add DEVTMPFS support, otherwise it freezes at boot04:29
mthI only changed the a320 defconfig, not the qi_lb60 defconfig04:30
kyakoh, sorry04:30
kyaklarsc: could you make this change to qi_lb60_defconfig?04:31
qi-bot[commit] Paul Cercueil: Fix a bug where only some parameters were read from the links files. (packages) http://qi-hw.com/p/gmenu2x/876f2cf06:20
qi-bot[commit] Paul Cercueil: Update to use the latest libopk API. (packages) http://qi-hw.com/p/gmenu2x/909fef206:20
qi-bot[commit] Paul Cercueil: Mount the OPK packages in order to execute the binary included. (packages) http://qi-hw.com/p/gmenu2x/f6c19d006:20
wpwrakroh: hmm, pretty ambitious08:35
wpwrakroh: seems that there are two main directions: form printing and heavy duty printing. the former (i love puns :) is the one most likely to yield devices affordable to "the masses". the heavy duty stuff is a lot more difficult.08:38
wpwrakyou can probably also grow heavy duty machines from light duty parts08:39
whitequarkform printing?08:43
whitequarkalso: http://opensourceecology.org/08:44
wpwrakan ad hoc name :) i mean 3d printing where the form is the most important result, not mechanical strength or special material properties08:49
wpwraki think OSE will need a lot of iterations :) and i don't quite see the point. they're solving a non-problem. we already have quite capable industries to do all these things.08:51
wpwrakthat sort of stuff may be interesting some day when it comes to colonializing distant planets. but that's still a while out :)08:52
whitequarkwpwrak: well, I like the idea of self-sustainability08:55
whitequarkthrough it is years behind being achieved08:55
whitequarkI also dislike the idea of cloud computing for some reason, and all cool kids love cloud computing, so...08:55
wpwraki don't see the point of cloud computing either :)08:56
wpwrakit feels like 1960es mainframe thinking transplanted into the internet age08:56
viricI think that for me "all cool kids love ..." is an indicator of a bad thing, usually09:00
wpwrakindeed :) it means it stopped being avantgarde a decade ago09:01
wpwrakwhich kinda fits, thinking of it ;-)09:02
rohwpwrak: well.. what i still miss is 'hacking injection molding'09:15
rohi am just yet to stupid and moneyless to actively figure it out09:15
rohmy measurement is: if if can be done autonomous and unattended. e.g. as vending machine, its not impossible to do it in a hackerspace/homebrew lab under semi-professional environments09:16
rohand since there is/was mold-o-rama ...09:16
whitequarkwpwrak: well, there are two kinds of "cloud computing"09:19
whitequarkthe first is "let's put ten underutilized virtual servers on a single hardware", it was done by IBM in 1960s and it's really good09:19
whitequarkthe second is "let's deprive user from their data and force them to use our remote interface"09:19
whitequarkwhich was also done by IBM in 1960s but is nowhere as good09:20
whitequarkspeaking about it, I'm currently implementing a piece of software using 1970's tech, and I do that because there are no widespread implementations of that, except maybe JVM in a limited fashion09:21
whitequarkwell, JVM/V809:21
whitequarkboth are Lars Bak's Strongtalk implementations gone wrong :)09:22
paul_boddieroh: Hacking injection moulding would be cool, but surely you always return to the problem of making the moulds and tooling, and that is another CAD problem.09:45
paul_boddiewhitequark: I saw that you were doing a Ruby compiler or something similar. How is that coming along?09:46
rohpaul_boddie: true10:07
rohpaul_boddie: on the other side... the hackers world may have shortcomings, but there is also niceness... the openness, the sharing of knowledge.. the 'unconventional' or 'unorthodox' concepts being tried and results being published (sometimes) simply is more fun10:08
rohalso i realized that there seems to be more 'konservative' engineering in opensource. if stuff is figured out to a certain degree of reliability, it seldomly changes without need. but till then there is much more creativity than in what ive seen of the 'old world'10:09
paul_boddieI think people underestimate the amount of "locked in" knowledge in traditional enterprises, too. If you dismantle them, there's no guarantee that something else can just fill the gap left by them.10:14
rohyep. we could see that the last few years with natural disasters in asia... goods which only are produced in few places were unavail and that made prices explode for some stuff (e.g. harddisks)10:16
paul_boddieI think it's important that knowledge be documented in such a way that an endeavour can be repeated. Some people don't like that because it threatens their position - they need their "secret sauce" - and others insist that patents achieve this, which is a complete joke, but the people who deal with obsolete systems have plenty of lessons to teach people about this kind of thing, and I don't think society will always be able to afford to ignore t10:18
rohyou've seen the lunar lander tape recovery project?10:21
rohsomebody stored the original magnetic tapes from back then, and now they recover the data to compare to current measurements10:22
rohquite some reverse engineering endeveaur10:23
paul_boddieYes, another lesson about maintaining the expertise to do something. I guess NASA is a classic case of loss of organisational memory.10:25
rohpaul_boddie: yeah. sad to see.. they were leading the field in developing organisational things at one point in history10:52
paul_boddieInteresting related story: https://en.wikipedia.org/wiki/FOGBANK10:53
rohwell.. some stuff.. can be forgotten.. how to build nukes for example ;)11:10
rohmaybe its important to develop ethics at the same speed as technology11:11
paul_boddieThe lessons from that story are that even large, powerful organisations lose track of how to do things, and that even a supposedly perfected process can still have undocumented parts.11:17
whitequarkroh: (conservative OSS) look at the present state of so-called linux desktop11:31
whitequarksystemd, policykit, udev, wayland, dbus-based notifications, ...11:31
rohwhitequark: wait it out.11:33
rohsome of that makes sense. the rest will not make it on the long run11:33
whitequarkroh: exactly what I wanted to say11:33
whitequarkstill, I won't call it "conservative". "no change for the sake of change", maybe, but that's more to simple human laziness11:33
whitequarkyou won't do bullshit all day unless a manager forces you :)11:34
paul_boddieI think there's a continuous opposition between conservative and crazy, well-researched and reinvented, old and new.11:34
whitequarkI find it quite funny that we had devfs, then we had udev, and now we have devfs again11:34
Action: whitequark waits for the next iteration11:34
paul_boddiePeople have no sense of history, that's why. It's part of a more general depressing phenomenon where you can end up arguing with someone about something that probably happened before they were born, and they have the nerve to doubt that any such thing ever happened.11:36
whitequarkpaul_boddie: I'd say it is more due to the fact that OSS development model is close to evolutionary one11:37
paul_boddieIt's like all those people who don't think that Microsoft ever did anything wrong. Clearly they were born fairly recently and never caught up, or they never bothered to pay attention during, say, the 1990s.11:37
whitequarkpeople do stuff; good stuff evolves, forks and lives on.11:37
whitequarkMicrosoft still does the same wrong thing as they did in the past11:37
whitequarkthey never stopped11:37
paul_boddiewhitequark: Did you ever do anything a while ago and then see someone much more recently announce something very similar as the hot new thing? People are just lazy but want their fame and glory anyway.11:38
whitequarkpaul_boddie: that's perfectly normal11:38
whitequarkeach programming language in the last 20 years reiterated histories of ALGOL and Lisp, in differently twisted fashion11:39
whitequarkwhich doesn't mean they ever did something wrong. Both Algol and Lisp have proven to be unusable by general public. Iterating their useful features in this fashion allows us to have better and better languages11:39
paul_boddieAbout Microsoft, yes, they never stopped, but people either have the view that all the major legal trouble in the 1990s was unmerited (or didn't happen because they never knew about it) and so there's no *real* dirt, or that Microsoft is a changed company. MS is just better at covering their tracks these days, although still incompetent at that, of course.11:40
paul_boddieAbout language evolution, I agree. Witness all the people using Lisp who can't understand why people use those "dirty imitations".11:41
whitequarkthe problem with Lisp is that it's too powerful11:41
whitequarklambda calculus, the purest form of computation, can represent everything, but cannot represent anything actually useful:)11:42
whitequarkand with Lisp it's basically impossible to have large scale projects due to the fact that everyone tends to invent their own slightly different variations of already proven concepts11:42
whitequarkI've heard that back 50 years ago, function calls were a design pattern11:43
whitequarkprologue, epilogue, arguments on stack...11:43
whitequarkif Lispers designed C, every programmer would have to define his own ABI11:43
whitequarkslightly incompatible but effectively having the same power as the every other one11:44
whitequarkthis is also C++ is very wrong.11:44
paul_boddieI can see that, actually. Concepts like functions were probably like everything else: a tradeoff that worked for certain use-cases, but would they work satisfactorily in general, and is it wise to eliminate support for the other cases?11:44
whitequarkpaul_boddie: the main language designer rule is: simple things should be simple, and complex things possible11:45
whitequarkand the notion of "simple things" changes with time11:45
whitequarkin 1970, procedures were simple11:45
whitequarkin 2000, closures are already simple11:45
whitequark(I'm 19 year old, so the dates might be a bit off.)11:46
whitequarkyou don't need to define your own way to make closures in language, it should be builtin.11:47
whitequarkthe problem is, everyone dislikes _something_ in any existing language11:48
whitequarkand if the language allows everything to be overridden, then it will be, and the code will become pretty unusable11:48
paul_boddieI think closures are a luxury, myself. You can model what you need from them in other ways, and they cause complications for the language designer and implementer. The Lisp crowd lobbied hard for closures in Python, and I don't really think that the resulting support is worth having.11:49
whitequarkpaul_boddie: python closures aren't, well, proper closures11:49
whitequarkRuby ones are11:49
paul_boddieAnd it's not worth listening to the Lisp crowd, anyway. They won't use your language after making their demands.11:49
whitequarkthey add very much to the language. I can't really imagine writing something without the expressive power of closures11:50
whitequarkbesides that, language designers and implementors aren't the people anyone needs to care about.11:50
paul_boddieHow are Python closures not proper? I don't remember, myself.11:50
whitequarkwell, there are no anonymous functions in Python11:51
paul_boddieThere are no multi-statement anonymous functions, you mean.11:51
whitequarkthere is so-called "lambda" keyword, which defines a "function" which can only have a certain subset of expressions inside11:51
whitequarkand which isn't actually very useful11:52
paul_boddielambda provides a single expression, yes, not one or more statements.11:52
whitequarkthe best part of Ruby's closures is that they're very easy to use and manipulate 11:53
whitequarkmeth { i_am_a_closure }. done.11:53
paul_boddieAlso, you bind functions to names upon definition in Python, but that doesn't mean that you can only have one such function for every binding.11:53
whitequarktherefore you are encouraged to write composable code, which happens to be much cleanier and easier to read11:53
whitequarkFile.open("something") { |io| io.write "hello" }, for example, automatically closes the handle11:54
paul_boddieAlthough those functions probably still have some notion of a name, they don't need to be available through that name any more. You can make lists of parameterised functions all of which probably think they have a name, but it's irrelevant.11:55
whitequarkiterators and lazy generators are implemented via the same simple syntax11:55
whitequark(1..2).each { |x| puts x } # iterator11:55
whitequark(1..2).map { |x| x * x }.each { |x| puts x } # two chained ones11:55
whitequarkgen = (1..2).map { |x| x * x }.each # create a generator and pass it around11:56
paul_boddieWell, not having to name those blocks is convenient and means that you can write them inline, but they don't give you anything over and above a reference to a function.11:56
whitequarksum = line.split(" ").map(&:to_i).map(&:abs).reduce(:+)11:56
whitequarkpaul_boddie: yeah, this is one of the most common PL-related fallacies11:57
whitequarksyntax doesn't actually give you anything if your language is Turing-complete11:57
whitequarkthe way you define the syntax affects the way people will use your language heavily11:57
whitequarkit doesn't actually makes sense to argue if syntax adds something to the language. it doesn't. syntax adds something to usability, or maybe not, and syntax might make writing good code easier. or, again, might not.11:59
whitequarkeven Java has closures already (Java 8)11:59
whitequarkand if you've ever tried to write code with callbacks, you'll easily understand why11:59
whitequarkspeaking about that, void (*cb)(void*) is NOT an acceptable way to implement closures.12:00
paul_boddieWell, I use a variety of constructs that different groups of other Python programmers frown upon in different ways, but I think that some of these syntax refinements work against their own motivations.12:01
whitequarkindeed, there are lots of possible but not very clever things to do in Ruby either12:01
whitequark5 years ago it was cool to extend standard classes, it isn't anymore. There are better conventions now12:01
whitequarkbest of these conventions are now being integrated to the core language12:02
whitequarkor, for example, Ruby has recently gained syntactic keyword arguments12:02
whitequark1.8 used an "options hash" and a syntactic sugar which allowed you to omit {} for the last function argument if it was a hash12:03
whitequark1.9 added a sugar which mapped `a: expr' to `:a => expr'12:03
whitequark2.0 finally allows you to write `def meth(kwarg: default_value)'12:03
whitequarki.e. it does hash decomposition and mandatory argument checking in the core12:04
paul_boddieIs this not like Python's **kw support?12:05
whitequarkyeah, it now works like in Python, except that no one removed positional arguments12:05
paul_boddieOh, and as I understand it, closures are orthogonal to having anonymous blocks. You can still "close over" the environment even if you have to give a temporary name to the thing doing so.12:07
paul_boddieOr as Wikipedia states, "The term closure is often mistakenly used to mean anonymous function."12:07
whitequarkpaul_boddie: you are correct12:08
whitequarkI meant blocks, indeed.12:09
paul_boddieIn fact, you're not wrong to point out that the naming of things in Python is a potential conceptual hurdle for people if only because languages like Java special-case things like methods. This can lead to flaws in people's reasoning about the behaviour of programs, even to the extent of how one should refer to and reason about program units.12:12
paul_boddieIn other words, people carry over assumptions like "this is function f" instead of thinking "this function currently known as f".12:13
whitequarkJava requires you to create a class and a method to keep a chunk of code12:13
whitequarkPython requires you to create a method (well, named function to be precise)12:13
whitequarkRuby just allows you to write a chunk of code.12:14
larscso does PHP ;)12:14
whitequarklarsc: PHP does not have closures at all :)12:14
whitequarkits "lambdas" are named and non-GC'd methods12:15
larscwhitequark: sorry, just saw the last 2 lines12:15
whitequarkI see your point then :)12:15
whitequarkwell, you have toplevel code in Ruby and ERB (php-like interleaved script interpreter) is in standard library12:16
paul_boddiePython would have anonymous blocks if there would be an agreement on syntax, but nobody ever reached agreement.12:16
whitequarkbut for some reason no one writes in Ruby like in PHP...12:16
whitequarkpaul_boddie: well, either there was not enough pressure to add closures12:17
whitequarkor that's a typical flaw of design by commitee12:18
paul_boddieThere *are* closures. There just aren't anonymous blocks.12:18
whitequarksorry, I did that again. Ruby doesn't have non-anonymous closures, so the terms are mixed up there12:18
paul_boddieClosures were added in something like Python 2.2. I don't remember the precise details, but I could look it up.12:19
whitequarkI know12:20
paul_boddiePersonally, I think that you have two different schools of thought where one school prizes closures and the other says, "Well we can more or less do that more cleanly with structures/objects/explicit state." The former group taunts the latter because they've been writing Lisp since forever, and the latter probably uses languages where closures would add complexity to their implementation that they wouldn't be able to live with.12:21
whitequarkpaul_boddie: every modern language has closures :)12:22
paul_boddieClever answer. :-)12:22
whitequarkevery JVM one, every CLR one, Lua, Ruby, Python, C++ [C++11], JS, whatnot12:23
whitequarkso I guess the former group won :)12:23
whitequarkseriously, closures aren't hard to implement compared to, for example, continuations12:23
whitequarkand continuations are a huge win in some interesting cases12:23
paul_boddieYou should go on LWN and start an argument about programming languages on some article about Android. It would give people some entertainment. :-)12:24
whitequarkmeh, I prefer to start arguments on my blog12:24
paul_boddieBut, anyway, how is that compiler of yours coming along?12:24
whitequark50% of my dayjob time is allocated for it:)12:24
whitequarkwell, there is some progress, but nothing particularly interesting12:25
whitequarkI'll probably write an article in a few days12:25
whitequarkon the architectural choices12:25
paul_boddieAs I recall, you intended to eliminate some of the run-time complexity in favour of making optimisations in the generated program. Is that the idea?12:27
whitequarkthis is more of a side effect12:27
whitequarkevery existing Ruby implementation (or, in fact, most language implementations I'm aware about) compile the source to some IR which captures the semantics of the underlying machine12:28
whitequarki.e. C++ compiles to x86, Java compiles to JVM12:28
whitequarkif a compiler then tries to optimize the code, it obviously works on that IR12:28
whitequarkI'm writing an implementation where IR accurately captures the semantics of Ruby, not some existing VM like LLVM12:29
whitequarkthe point is, LLVM doesn't know much about the Ruby semantics and therefore it's unable to do some interesting optimizations12:29
whitequarkit doesn't have enough information in its IR to argue about the code12:29
paul_boddieDidn't Parrot already try this? ;-)12:29
whitequarkit _can_ insert run-time guards to check for types, etc, but JITs are generally slow and very expensive12:29
whitequarkyou won't use a JIT on an ARM with 8K of RAM12:30
whitequarkbut everything changes if I make an IR specifically for Ruby12:30
whitequarkI can derive a lot of information about types, or about control flows12:30
whitequarkI can trivially inline those anonymous blocks where I can do that (i.e. where the block environment does not live further than the function it was defined in)12:31
whitequarkI can inline method calls if I can guarantee that the methods won't be redefined12:31
whitequarkthe current implementations assume that every bit of the Ruby semantics should be accessible at every point of time12:32
whitequarki.e. they assume that you will redefine methods at runtime just because you can12:32
whitequarkthis requires you to use JIT in your implementation, and even with JIT, some things become way more expensive than they should be12:32
whitequarkarithmetics, for example12:32
paul_boddieWhat you wrote on your blog looked a lot like what someone wrote for Python, but that was more about evaluating the program expressions (the guy didn't say exactly how he did it), and then producing a simplified program. But I guess the two ideas are equivalent as he could easily have been describing a simplified generated program.12:33
whitequarkwell, that's how optimization works :)12:34
whitequarkthe whole point is to produce IR which can be easily operated with12:34
paul_boddieYes, but it's the assumptions that underlie the optimisations that are the important part.12:35
whitequarkRubinius produces LLVM IR, which is easily manipulated with LLVM12:35
whitequarkbut there isn't a way to say to LLVM: "hey, this function will only ever receive Class or Module arguments, optimize for them"12:35
whitequarkbasically the same with Java12:35
whitequarkand JRuby12:35
paul_boddieThe trend in various circles is to not bother with guaranteeing anything before the program is run but instead relying on run-time observations.12:35
whitequarkit's a time-memory tradeoff12:36
paul_boddieI don't necessarily agree with that at all, mostly because, as you say, that has a lot of overhead and rules out 8K RAM environments.12:36
whitequarkruntime observations pay for themselves when you have unlimited memory12:36
whitequarki.e. JVM heap reaches obscene sizes12:36
paul_boddieWhat interests me a lot more is the analysis, and not just for the optimisations.12:37
whitequarkyes. there are more interesting things to do when you have this IR12:37
whitequarkbasically this IR is a normalized representation of Ruby12:37
whitequarkwithout all complexity of its syntax and with ease of manipulation12:37
paul_boddieIt's interesting that in your blog, you start with bytecode and derive something like an AST. Why not start with the AST?12:38
whitequarkit was over a year ago, and I thought that Rubinius' bytecode suits my needs for a source better12:38
whitequarkit's not12:38
whitequarkI'm using ASTs now12:38
whitequarkthis is a problem as of itself. There are at least five separate Ruby parsers, and they either suck at completeness, output format or runtime requirements.12:40
whitequarks,either,two of the three,12:40
whitequarkmy implementation also has truly meta-circular architecture12:41
whitequarki.e. it's a Ruby VM written in Ruby12:41
whitequarkif I would want to write a fully-fledged, general purpose implementation (which I don't), I could just compile it with itself eventually12:42
whitequarkyou won't get most of the runtime optimizations, but as Squeak's history shows, it could still be beneficial as of itself12:43
paul_boddieHeh! At last, someone actually writes a Ruby VM in Ruby instead of *claiming* to do so. :-)12:43
whitequarkit would still have a separate GC because I cannot do everything, but honestly I don't consider automatic memory management as a part of a programming language implementation12:44
whitequarkit should have become an OS routine years ago12:44
lindi-whitequark: hmm, if you make explicit assertions for the arguments then llvm could do compile-time optimizations too?12:45
whitequarklindi-: 1) it requires you to have the aforementioned IR to derive the assertions12:46
whitequark2) not if your method lookup path looks like this: http://whitequark.org/images/static-ruby/ruby-eigenclass.png12:46
whitequarkand note that everything in that path could be overridden12:47
lindi-whitequark: I don't know about ruby but I have used llvm12:47
whitequarklindi-: it's less of an LLVM issue and more of Ruby one12:47
whitequarkyou need an invokedynamic-like primitive to represent Ruby's semantics12:48
whitequarkhttp://blog.headius.com/2008/09/first-taste-of-invokedynamic.html (long but interesting)12:49
whitequarkand JRuby slowly but definitely gains the IR just like the one I'm talking about12:50
whitequark*but certainly12:50
whitequarkfor the precisely same reasons12:50
whitequarkor this, shorter one: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/multiple-language-support.html12:51
whitequarkit even lists the examples in Ruby12:52
larschttp://www.kickstarter.com/projects/18182218/freesoc-and-freesoc-mini ... unfortunately the name is very misleading :(14:58
viricsummer of code15:02
whitequarkhah, a nice board15:21
wpwrakisn't that IDE still closed source ?15:23
whitequarkwpwrak: doesn't matter15:24
whitequarkcan be programmed with C and Verilog15:24
whitequarkit's a Cortex M3 paired with 24 PLD's15:25
whitequarkthis is a _very_ impressive hybrid chip15:25
whitequarkI think I'll certainly get one for myself15:25
wpwrakoh, i know the psocs ;) well, the psoc 115:25
wpwrak3 and 5 are much better, of course. 1 doesn't have the programmable logic and it has a weird core (m8c)15:26
lindi-but the verilog compiler is closed source?15:28
wpwrakone problem is that you really need some tools for resource planning. things aren't trivial.15:28
wpwraklindi-: as far as i remember, the PLDs are fully documented. so you could write your own.15:29
Action: whitequark has backed the project15:29
lindi-whitequark: oh15:30
lindi-sounds promising but still problematic if I don't have the time to write a compiler :)15:31
whitequarklindi-: well, I'm fine with evaluating it with closed-source tools and such15:32
whitequarkif it proves to be worthwhile, resources can always be allocated15:32
whitequarkthis is also really cool15:33
whitequarkbut I probably won't have time to play with the board15:33
whitequarkI'm not a SIMD guy really :)15:33
larscI think their price tag is very ambitious.15:34
larscthe ZED board on which they want to base their design already costs twice as much15:35
wpwraklindi-: at least the core is something sane. when playing with the psoc 1, i had to use assembler. and i had to write my own assembler, too. http://m8cutils.sourceforge.net/15:35
wpwrakit was a very rough ride back then ...15:36
pcercueirun-time power management for the audio subsystem, finally15:58
larscfor HDA device, ASoC had runtime PM for ages16:04
pcercueimaybe we could enable it on OD's config then16:08
larscthere is no config option to disable it16:10
pcercueithere's one16:12
larscASoCs runtime pm does not depend on CONFIG_PM_RUNTIME16:13
pcercueiah, was thinking of that one16:14
pcercueilarsc, can't you be wrong just for once? ;)16:14
larscI'm wrong all the time, the trick is not let anybody notice it ;)16:15
wpwrakand he has a very efficient "black ops" task force :)16:17
qi-bot[commit] Paul Cercueil: Fix build when libopk is not present. (packages) http://qi-hw.com/p/gmenu2x/ef1884117:44
qi-bot[commit] Paul Cercueil: configure.in: update libopk check to match latest libopk API (packages) http://qi-hw.com/p/gmenu2x/c58c72617:49
mthkyak: I tested the Dingoo A320 (JZ4740) with Linux 3.5 with Win7 tonight... doesn't work22:20
mththe same Win7 machine with GCW Zero (JZ4770) and Linux 3.6 works fine22:20
mthso it's either Linux 3.5 vs 3.6 or something in the 4740's USB stack that is preventing it from working22:21
pcercueiI'd say USB stack22:22
pcercueimass storage mode won't work with the current jz4740 stack22:22
qi-bot[commit] Paul Cercueil: Load the OPK in the section defined by their "Categories" parameter (packages) http://qi-hw.com/p/gmenu2x/4a60aa023:42
--- Tue Oct 9 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!