IRC log for #qi-hardware on 20121008

00:15.17*** join/#qi-hardware guanucoluis (~luis@200.127.180.65)
00:21.48*** join/#qi-hardware nikescar (~nikescar@114.199.131.108)
01:09.29*** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com)
02:02.01*** join/#qi-hardware nikescar (~nikescar@114.199.131.108)
02:56.34qi-bot[commit] Xiangfu: debian: cleanup on control file (master) http://qi-hw.com/p/fped/d2daaf8
03:04.02*** join/#qi-hardware DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg)
03:26.51rohwpwrak: http://reprap.org/wiki/MetalicaRap
03:29.32*** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::1119)
03:48.22qi-bot[commit] Xiangfu: debian: cleanup changelog, include debian build flags (master) http://qi-hw.com/p/fped/d76f7d1
03:49.01*** join/#qi-hardware guanucoluis (~luis@200.127.180.65)
04:12.58qi-bot[commit] Xiangfu: transfer build flags from outside (master) http://qi-hw.com/p/fped/5b21495
04:27.52kyakmth: jz-3.5, Windows 7, infamous error code 10 :(
04:28.05kyaki'll be waiting for 3.6 then
04:29.40kyakmth: 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 boot
04:30.20mthI only changed the a320 defconfig, not the qi_lb60 defconfig
04:30.54kyakoh, sorry
04:31.20kyaklarsc: could you make this change to qi_lb60_defconfig?
05:37.17*** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::d17)
06:20.51qi-bot[commit] Paul Cercueil: Fix a bug where only some parameters were read from the links files. (packages) http://qi-hw.com/p/gmenu2x/876f2cf
06:20.52qi-bot[commit] Paul Cercueil: Update to use the latest libopk API. (packages) http://qi-hw.com/p/gmenu2x/909fef2
06:20.52qi-bot[commit] Paul Cercueil: Mount the OPK packages in order to execute the binary included. (packages) http://qi-hw.com/p/gmenu2x/f6c19d0
06:23.34*** join/#qi-hardware jluis|work (~jpddb@2001:5c0:1000:a::1323)
08:06.47*** join/#qi-hardware jekhor (~jek@46.53.195.142)
08:33.46*** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::671)
08:35.44wpwrakroh: hmm, pretty ambitious
08:38.33wpwrakroh: 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:39.03wpwrakyou can probably also grow heavy duty machines from light duty parts
08:43.52whitequarkform printing?
08:44.21whitequarkalso: http://opensourceecology.org/
08:49.27wpwrakan ad hoc name :) i mean 3d printing where the form is the most important result, not mechanical strength or special material properties
08:51.22wpwraki 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:52.09wpwrakthat sort of stuff may be interesting some day when it comes to colonializing distant planets. but that's still a while out :)
08:55.24whitequarkwpwrak: well, I like the idea of self-sustainability
08:55.31whitequarkthrough it is years behind being achieved
08:55.47whitequarkI also dislike the idea of cloud computing for some reason, and all cool kids love cloud computing, so...
08:56.25wpwraki don't see the point of cloud computing either :)
08:56.59wpwrakit feels like 1960es mainframe thinking transplanted into the internet age
08:59.54viric:)
09:00.25viricI think that for me "all cool kids love ..." is an indicator of a bad thing, usually
09:01.24wpwrakindeed :) it means it stopped being avantgarde a decade ago
09:02.03wpwrakwhich kinda fits, thinking of it ;-)
09:15.23rohwpwrak: well.. what i still miss is 'hacking injection molding'
09:15.43rohi am just yet to stupid and moneyless to actively figure it out
09:16.30rohmy 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 environments
09:16.48rohand since there is/was mold-o-rama ...
09:19.09whitequarkwpwrak: well, there are two kinds of "cloud computing"
09:19.40whitequarkthe first is "let's put ten underutilized virtual servers on a single hardware", it was done by IBM in 1960s and it's really good
09:19.56whitequarkthe second is "let's deprive user from their data and force them to use our remote interface"
09:20.13whitequarkwhich was also done by IBM in 1960s but is nowhere as good
09:21.19whitequarkspeaking 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 fashion
09:21.43whitequarkwell, JVM/V8
09:22.12whitequarkboth are Lars Bak's Strongtalk implementations gone wrong :)
09:43.53*** join/#qi-hardware paul_boddie (~paulbodd@hfaistos.uio.no)
09:45.08paul_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:46.03paul_boddiewhitequark: I saw that you were doing a Ruby compiler or something similar. How is that coming along?
10:07.20rohpaul_boddie: true
10:08.16rohpaul_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 fun
10:09.39rohalso 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:14.05paul_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:16.05rohyep. 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:18.21paul_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 t
10:21.07rohtrue
10:21.23rohyou've seen the lunar lander tape recovery project?
10:22.19rohsomebody stored the original magnetic tapes from back then, and now they recover the data to compare to current measurements
10:23.00rohquite some reverse engineering endeveaur
10:25.52paul_boddieYes, another lesson about maintaining the expertise to do something. I guess NASA is a classic case of loss of organisational memory.
10:52.17rohpaul_boddie: yeah. sad to see.. they were leading the field in developing organisational things at one point in history
10:53.53paul_boddieInteresting related story: https://en.wikipedia.org/wiki/FOGBANK
11:10.59rohwell.. some stuff.. can be forgotten.. how to build nukes for example ;)
11:11.20rohmaybe its important to develop ethics at the same speed as technology
11:17.26paul_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:31.04whitequarkroh: (conservative OSS) look at the present state of so-called linux desktop
11:31.38whitequarksystemd, policykit, udev, wayland, dbus-based notifications, ...
11:33.01rohwhitequark: wait it out.
11:33.14rohsome of that makes sense. the rest will not make it on the long run
11:33.21whitequarkroh: exactly what I wanted to say
11:33.49whitequarkstill, I won't call it "conservative". "no change for the sake of change", maybe, but that's more to simple human laziness
11:34.02whitequarkyou won't do bullshit all day unless a manager forces you :)
11:34.10paul_boddieI think there's a continuous opposition between conservative and crazy, well-researched and reinvented, old and new.
11:34.48whitequarkI find it quite funny that we had devfs, then we had udev, and now we have devfs again
11:34.54whitequarkwaits for the next iteration
11:36.22paul_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:37.18whitequarkpaul_boddie: I'd say it is more due to the fact that OSS development model is close to evolutionary one
11:37.28paul_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.35whitequarkpeople do stuff; good stuff evolves, forks and lives on.
11:37.55whitequarkMicrosoft still does the same wrong thing as they did in the past
11:37.58whitequarkthey never stopped
11:38.26paul_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.43whitequarkpaul_boddie: that's perfectly normal
11:39.06whitequarkeach programming language in the last 20 years reiterated histories of ALGOL and Lisp, in differently twisted fashion
11:39.52whitequarkwhich 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 languages
11:40.33paul_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:41.11*** join/#qi-hardware wej (~j@se1x.mullvad.net)
11:41.18paul_boddieAbout language evolution, I agree. Witness all the people using Lisp who can't understand why people use those "dirty imitations".
11:41.56whitequarkthe problem with Lisp is that it's too powerful
11:42.17whitequarklambda calculus, the purest form of computation, can represent everything, but cannot represent anything actually useful:)
11:42.50whitequarkand 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 concepts
11:43.17whitequarkI've heard that back 50 years ago, function calls were a design pattern
11:43.33whitequarkprologue, epilogue, arguments on stack...
11:43.51whitequarkif Lispers designed C, every programmer would have to define his own ABI
11:44.17whitequarkslightly incompatible but effectively having the same power as the every other one
11:44.33whitequarkthis is also C++ is very wrong.
11:44.35paul_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.35whitequark*why
11:45.35whitequarkpaul_boddie: the main language designer rule is: simple things should be simple, and complex things possible
11:45.42whitequarkand the notion of "simple things" changes with time
11:45.50whitequarkin 1970, procedures were simple
11:45.56whitequarkin 2000, closures are already simple
11:46.33whitequark(I'm 19 year old, so the dates might be a bit off.)
11:47.16whitequarkyou don't need to define your own way to make closures in language, it should be builtin.
11:48.44whitequarkthe problem is, everyone dislikes _something_ in any existing language
11:48.59whitequarkand if the language allows everything to be overridden, then it will be, and the code will become pretty unusable
11:49.13paul_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.31whitequarkpaul_boddie: python closures aren't, well, proper closures
11:49.35whitequarkRuby ones are
11:49.54paul_boddieAnd it's not worth listening to the Lisp crowd, anyway. They won't use your language after making their demands.
11:50.05whitequarkthey add very much to the language. I can't really imagine writing something without the expressive power of closures
11:50.39whitequarkbesides that, language designers and implementors aren't the people anyone needs to care about.
11:50.58paul_boddieHow are Python closures not proper? I don't remember, myself.
11:51.15whitequarkwell, there are no anonymous functions in Python
11:51.35paul_boddieThere are no multi-statement anonymous functions, you mean.
11:51.49whitequarkthere is so-called "lambda" keyword, which defines a "function" which can only have a certain subset of expressions inside
11:52.13whitequarkand which isn't actually very useful
11:52.19paul_boddielambda provides a single expression, yes, not one or more statements.
11:53.10whitequarkthe best part of Ruby's closures is that they're very easy to use and manipulate
11:53.21whitequarkmeth { i_am_a_closure }. done.
11:53.49paul_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.56whitequarktherefore you are encouraged to write composable code, which happens to be much cleanier and easier to read
11:54.51whitequarkFile.open("something") { |io| io.write "hello" }, for example, automatically closes the handle
11:55.08paul_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.08whitequarkiterators and lazy generators are implemented via the same simple syntax
11:55.31whitequark(1..2).each { |x| puts x } # iterator
11:55.46whitequark(1..2).map { |x| x * x }.each { |x| puts x } # two chained ones
11:56.08whitequarkgen = (1..2).map { |x| x * x }.each # create a generator and pass it around
11:56.24whitequarkor:
11:56.52paul_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.53whitequarksum = line.split(" ").map(&:to_i).map(&:abs).reduce(:+)
11:57.10whitequarkpaul_boddie: yeah, this is one of the most common PL-related fallacies
11:57.25whitequarksyntax doesn't actually give you anything if your language is Turing-complete
11:57.53whitequarkthe way you define the syntax affects the way people will use your language heavily
11:59.00whitequarkit 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.15whitequarkeven Java has closures already (Java 8)
11:59.53whitequarkand if you've ever tried to write code with callbacks, you'll easily understand why
12:00.22whitequarkspeaking about that, void (*cb)(void*) is NOT an acceptable way to implement closures.
12:01.05paul_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.33whitequarkindeed, there are lots of possible but not very clever things to do in Ruby either
12:01.33*** join/#qi-hardware cladamw (~adamwang@host-174.163-235-182.cable.dynamic.kbtelecom.net)
12:01.58whitequark5 years ago it was cool to extend standard classes, it isn't anymore. There are better conventions now
12:02.12whitequarkbest of these conventions are now being integrated to the core language
12:02.34whitequarkor, for example, Ruby has recently gained syntactic keyword arguments
12:03.06whitequark1.8 used an "options hash" and a syntactic sugar which allowed you to omit {} for the last function argument if it was a hash
12:03.24whitequark1.9 added a sugar which mapped `a: expr' to `:a => expr'
12:03.48whitequark2.0 finally allows you to write `def meth(kwarg: default_value)'
12:04.36whitequarki.e. it does hash decomposition and mandatory argument checking in the core
12:05.01paul_boddieIs this not like Python's **kw support?
12:05.35whitequarkyeah, it now works like in Python, except that no one removed positional arguments
12:07.27paul_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.47paul_boddieOr as Wikipedia states, "The term closure is often mistakenly used to mean anonymous function."
12:08.02whitequarkpaul_boddie: you are correct
12:08.53*** join/#qi-hardware jekhor (~jek@178.121.176.4)
12:09.03whitequarkI meant blocks, indeed.
12:12.01paul_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:13.05paul_boddieIn other words, people carry over assumptions like "this is function f" instead of thinking "this function currently known as f".
12:13.19whitequarkyes
12:13.37whitequarkJava requires you to create a class and a method to keep a chunk of code
12:13.54whitequarkPython requires you to create a method (well, named function to be precise)
12:14.01whitequarkRuby just allows you to write a chunk of code.
12:14.18larscso does PHP ;)
12:14.46whitequarklarsc: PHP does not have closures at all :)
12:15.02whitequarkits "lambdas" are named and non-GC'd methods
12:15.06larscwhitequark: sorry, just saw the last 2 lines
12:15.27whitequarkahh
12:15.32whitequarkI see your point then :)
12:16.03whitequarkwell, you have toplevel code in Ruby and ERB (php-like interleaved script interpreter) is in standard library
12:16.06paul_boddiePython would have anonymous blocks if there would be an agreement on syntax, but nobody ever reached agreement.
12:16.18whitequarkbut for some reason no one writes in Ruby like in PHP...
12:17.49whitequarkpaul_boddie: well, either there was not enough pressure to add closures
12:18.01whitequarkor that's a typical flaw of design by commitee
12:18.36paul_boddieThere *are* closures. There just aren't anonymous blocks.
12:18.59whitequarksorry, I did that again. Ruby doesn't have non-anonymous closures, so the terms are mixed up there
12:19.14paul_boddieClosures were added in something like Python 2.2. I don't remember the precise details, but I could look it up.
12:20.15whitequarkI know
12:21.44paul_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:22.37whitequarkpaul_boddie: every modern language has closures :)
12:22.56paul_boddieClever answer. :-)
12:23.05whitequarkevery JVM one, every CLR one, Lua, Ruby, Python, C++ [C++11], JS, whatnot
12:23.24whitequarkso I guess the former group won :)
12:23.40whitequarkseriously, closures aren't hard to implement compared to, for example, continuations
12:23.57whitequarkand continuations are a huge win in some interesting cases
12:24.12paul_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.39whitequarkmeh, I prefer to start arguments on my blog
12:24.40paul_boddieBut, anyway, how is that compiler of yours coming along?
12:24.53whitequark50% of my dayjob time is allocated for it:)
12:25.15whitequarkwell, there is some progress, but nothing particularly interesting
12:25.23whitequarkI'll probably write an article in a few days
12:25.35whitequarkon the architectural choices
12:27.01paul_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.27whitequarkthis is more of a side effect
12:28.12whitequarkevery 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 machine
12:28.22whitequarki.e. C++ compiles to x86, Java compiles to JVM
12:28.34whitequarkif a compiler then tries to optimize the code, it obviously works on that IR
12:29.07whitequarkI'm writing an implementation where IR accurately captures the semantics of Ruby, not some existing VM like LLVM
12:29.26whitequarkthe point is, LLVM doesn't know much about the Ruby semantics and therefore it's unable to do some interesting optimizations
12:29.35whitequarkit doesn't have enough information in its IR to argue about the code
12:29.58paul_boddieDidn't Parrot already try this? ;-)
12:29.58whitequarkit _can_ insert run-time guards to check for types, etc, but JITs are generally slow and very expensive
12:30.14whitequarkyou won't use a JIT on an ARM with 8K of RAM
12:30.32whitequarkbut everything changes if I make an IR specifically for Ruby
12:30.46whitequarkI can derive a lot of information about types, or about control flows
12:31.18whitequarkI 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.41whitequarkI can inline method calls if I can guarantee that the methods won't be redefined
12:32.08whitequarkthe current implementations assume that every bit of the Ruby semantics should be accessible at every point of time
12:32.25whitequarki.e. they assume that you will redefine methods at runtime just because you can
12:32.52whitequarkthis requires you to use JIT in your implementation, and even with JIT, some things become way more expensive than they should be
12:32.55whitequarkarithmetics, for example
12:33.02paul_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:34.37whitequarkwell, that's how optimization works :)
12:34.54whitequarkthe whole point is to produce IR which can be easily operated with
12:35.00paul_boddieYes, but it's the assumptions that underlie the optimisations that are the important part.
12:35.06whitequarkRubinius produces LLVM IR, which is easily manipulated with LLVM
12:35.35whitequarkbut 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.46whitequarkbasically the same with Java
12:35.52whitequarkand JRuby
12:35.59paul_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:36.27whitequarkit's a time-memory tradeoff
12:36.44paul_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.50whitequarkruntime observations pay for themselves when you have unlimited memory
12:36.59whitequarki.e. JVM heap reaches obscene sizes
12:37.06paul_boddieWhat interests me a lot more is the analysis, and not just for the optimisations.
12:37.31whitequarkyes. there are more interesting things to do when you have this IR
12:37.38whitequarkbasically this IR is a normalized representation of Ruby
12:37.51whitequarkwithout all complexity of its syntax and with ease of manipulation
12:38.20paul_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.49whitequarkit was over a year ago, and I thought that Rubinius' bytecode suits my needs for a source better
12:38.53whitequarkit's not
12:38.58whitequarkI'm using ASTs now
12:40.18whitequarkthis 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.48whitequarks,either,two of the three,
12:41.47whitequarkmy implementation also has truly meta-circular architecture
12:41.53whitequarki.e. it's a Ruby VM written in Ruby
12:42.26whitequarkif I would want to write a fully-fledged, general purpose implementation (which I don't), I could just compile it with itself eventually
12:43.06whitequarkyou won't get most of the runtime optimizations, but as Squeak's history shows, it could still be beneficial as of itself
12:43.10paul_boddieHeh! At last, someone actually writes a Ruby VM in Ruby instead of *claiming* to do so. :-)
12:43.26whitequarkhehe
12:44.35whitequarkit 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 implementation
12:44.46whitequarkit should have become an OS routine years ago
12:45.27lindi-whitequark: hmm, if you make explicit assertions for the arguments then llvm could do compile-time optimizations too?
12:46.32whitequarklindi-: 1) it requires you to have the aforementioned IR to derive the assertions
12:46.51whitequark2) not if your method lookup path looks like this: http://whitequark.org/images/static-ruby/ruby-eigenclass.png
12:47.18whitequarkand note that everything in that path could be overridden
12:47.19lindi-whitequark: I don't know about ruby but I have used llvm
12:47.52whitequarklindi-: it's less of an LLVM issue and more of Ruby one
12:48.15whitequarkyou need an invokedynamic-like primitive to represent Ruby's semantics
12:49.39whitequarkhttp://blog.headius.com/2008/09/first-taste-of-invokedynamic.html (long but interesting)
12:50.15whitequarkand JRuby slowly but definitely gains the IR just like the one I'm talking about
12:50.26whitequark*but certainly
12:50.34whitequarkfor the precisely same reasons
12:51.57whitequarkor this, shorter one: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/multiple-language-support.html
12:52.05whitequarkit even lists the examples in Ruby
13:06.43*** join/#qi-hardware jekhor (~jek@178.121.176.4)
13:53.03*** part/#qi-hardware paul_boddie (~paulbodd@hfaistos.uio.no)
14:14.04*** join/#qi-hardware aisa (~a@173-10-243-253-Albuquerque.hfc.comcastbusiness.net)
14:25.24*** join/#qi-hardware kristoffer (~kristoffe@c-b6dce555.010-30-6c6b7012.cust.bredbandsbolaget.se)
14:58.09larschttp://www.kickstarter.com/projects/18182218/freesoc-and-freesoc-mini ... unfortunately the name is very misleading :(
15:02.21viricsummer of code
15:03.35*** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::2cc3)
15:18.42*** join/#qi-hardware guanucoluis (~luis@200.127.180.65)
15:20.47*** join/#qi-hardware heberth (~heberth@186.116.59.96)
15:21.04whitequarkhah, a nice board
15:23.23wpwrakisn't that IDE still closed source ?
15:24.45whitequarkwpwrak: doesn't matter
15:24.50whitequarkcan be programmed with C and Verilog
15:25.02whitequarkit's a Cortex M3 paired with 24 PLD's
15:25.17whitequarkthis is a _very_ impressive hybrid chip
15:25.26whitequarkI think I'll certainly get one for myself
15:25.34wpwrakoh, i know the psocs ;) well, the psoc 1
15:26.15wpwrak3 and 5 are much better, of course. 1 doesn't have the programmable logic and it has a weird core (m8c)
15:28.27lindi-but the verilog compiler is closed source?
15:28.40wpwrakone problem is that you really need some tools for resource planning. things aren't trivial.
15:29.01wpwraklindi-: as far as i remember, the PLDs are fully documented. so you could write your own.
15:29.16whitequarkhas backed the project
15:30.32lindi-whitequark: oh
15:31.05lindi-sounds promising but still problematic if I don't have the time to write a compiler :)
15:32.25whitequarklindi-: well, I'm fine with evaluating it with closed-source tools and such
15:32.40whitequarkif it proves to be worthwhile, resources can always be allocated
15:33.01whitequarkthis is also really cool
15:33.02whitequarkhttp://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone?ref=thanks
15:33.09whitequarkbut I probably won't have time to play with the board
15:33.22whitequarkI'm not a SIMD guy really :)
15:34.30larscI think their price tag is very ambitious.
15:34.55whitequarkindeed.
15:35.22larscthe ZED board on which they want to base their design already costs twice as much
15:35.28wpwraklindi-: 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:36.23wpwrakit was a very rough ride back then ...
15:56.07*** join/#qi-hardware pcercuei (~paul@190.162.199.66)
15:58.11pcercueihi
15:58.16pcercueihttp://www.phoronix.com/scan.php?page=news_item&px=MTIwMTU
15:58.37pcercueirun-time power management for the audio subsystem, finally
16:04.54larscfor HDA device, ASoC had runtime PM for ages
16:08.39pcercueiok.
16:08.55pcercueimaybe we could enable it on OD's config then
16:10.15larscthere is no config option to disable it
16:12.44pcercueiyes
16:12.47pcercueithere's one
16:13.01larscwhere?
16:13.35larscASoCs runtime pm does not depend on CONFIG_PM_RUNTIME
16:14.03pcercueiah, was thinking of that one
16:14.24pcercueilarsc, can't you be wrong just for once? ;)
16:15.20larscI'm wrong all the time, the trick is not let anybody notice it ;)
16:17.56wpwrakand he has a very efficient "black ops" task force :)
16:24.41*** join/#qi-hardware kristoffer (~kristoffe@c-b6dce555.010-30-6c6b7012.cust.bredbandsbolaget.se)
16:28.14*** join/#qi-hardware kristianpaul (~kristianp@cl-50.mia-01.us.sixxs.net)
16:28.14*** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul)
17:07.54*** join/#qi-hardware heberth (~heberth@186.116.59.96)
17:37.30*** join/#qi-hardware jekhor (~jek@46.53.195.142)
17:44.32qi-bot[commit] Paul Cercueil: Fix build when libopk is not present. (packages) http://qi-hw.com/p/gmenu2x/ef18841
17:49.25qi-bot[commit] Paul Cercueil: configure.in: update libopk check to match latest libopk API (packages) http://qi-hw.com/p/gmenu2x/c58c726
18:16.19*** join/#qi-hardware kristoffer (~kristoffe@c-b6dce555.010-30-6c6b7012.cust.bredbandsbolaget.se)
19:02.36*** join/#qi-hardware lekernel_ (~lekernel@g231251063.adsl.alicedsl.de)
19:11.44*** join/#qi-hardware jurting (~jurting@ip-164-15-72-178.dialup.ice.net)
20:00.15*** join/#qi-hardware heberth (~heberth@186.116.59.96)
21:02.43*** join/#qi-hardware pcercuei (~paul@190.162.199.66)
22:06.16*** join/#qi-hardware jurting (~jurting@ip-164-15-72-178.dialup.ice.net)
22:15.25*** join/#qi-hardware aisa (~a@209.234.140.58)
22:20.42mthkyak: I tested the Dingoo A320 (JZ4740) with Linux 3.5 with Win7 tonight... doesn't work
22:20.59mththe same Win7 machine with GCW Zero (JZ4770) and Linux 3.6 works fine
22:21.24mthso it's either Linux 3.5 vs 3.6 or something in the 4740's USB stack that is preventing it from working
22:22.10pcercueiI'd say USB stack
22:22.33pcercueimass storage mode won't work with the current jz4740 stack
22:36.16*** join/#qi-hardware heberth (~heberth@190.6.162.167)
22:46.17*** join/#qi-hardware aisa (~a@209.234.140.58)
22:49.05*** join/#qi-hardware heberth_ (~heberth@190.6.162.167)
23:03.53*** join/#qi-hardware aisa (~a@209.234.140.58)
23:25.03*** join/#qi-hardware aisa (~a@209.234.140.58)
23:34.43*** join/#qi-hardware urandom__ (~user@p548A2163.dip.t-dialin.net)
23:42.20qi-bot[commit] Paul Cercueil: Load the OPK in the section defined by their "Categories" parameter (packages) http://qi-hw.com/p/gmenu2x/4a60aa0

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.