| wolfspraul | TESTING | 00:07 |
|---|---|---|
| wolfspraul | the keyboard patches caused quite a stir on the list | 00:07 |
| wolfspraul | I cannot immediately respond to this now | 00:07 |
| wolfspraul | seems all sorts of conflicts there :-) | 00:07 |
| wpwrak | keyboard patches ? looking ... | 00:08 |
| wolfspraul | some people have no time, wish they had more, push feature-adoption to infinity, etc. | 00:08 |
| wolfspraul | I will just wait a little and uptick again - it's easier now | 00:08 |
| wolfspraul | the KiCad core team first has to sort out some internal things | 00:08 |
| wolfspraul | what Wayne had responded with initially would have made any politician proud | 00:09 |
| wolfspraul | I think for now the patches will be moving nowhere | 00:09 |
| wpwrak | nice reaction by Hoteev Sergey ;-) | 00:10 |
| wpwrak | "It is FUTURE!" :) | 00:10 |
| wolfspraul | yeah but there seem to be serious conflicts internally | 00:10 |
| wolfspraul | that would also explain the inconsistent renames I'm seeing | 00:10 |
| wpwrak | (wayne) you mean the reply from last year ? | 00:11 |
| wolfspraul | and that separation vaguely described there will never happen, I don't even need to ask for specifics because it's obvious they just want to make the issue go away | 00:11 |
| wolfspraul | no, the new stuff | 00:11 |
| wolfspraul | some people seem to have too much time/commitment to officially call it quits, yet too little to make solid changes | 00:12 |
| wpwrak | hmm, don't see it in the thread | 00:12 |
| wolfspraul | and they cannot decide which way to go ;-) | 00:12 |
| wpwrak | which subject ? | 00:12 |
| wolfspraul | Jan 20, same subject | 00:12 |
| wolfspraul | "I apologize for not responding sooner" (not really needed when I needed a year to respond :-)) | 00:13 |
| wpwrak | ah, he broke the thread | 00:13 |
| wolfspraul | "hold off until we separate the underlying object code from the UI code and implement it as a DLL/SO" | 00:13 |
| wolfspraul | that must be from the "how can I talk my dumb manager into leaving me alone hacking" seminar | 00:13 |
| wolfspraul | later in the thread he admits that that magic "separation" is at least 1 year out | 00:14 |
| wolfspraul | "at least" :-) | 00:14 |
| wolfspraul | yeah | 00:14 |
| wpwrak | "It is at best a year out." ;-) | 00:14 |
| wpwrak | yeah | 00:14 |
| wolfspraul | I could restructure the patches in many ways, but there is no guidance/leadership at this moment. | 00:14 |
| wolfspraul | yet the magic 'separation' will still not fall from the sky... | 00:15 |
| wolfspraul | so I plan to do nothing right now | 00:15 |
| wolfspraul | uplevel once in a while | 00:15 |
| wpwrak | yeah, that may be the best approach | 00:16 |
| wolfspraul | it's a bit worrisome at least the way Wayne describes it that the "other lead developers" (all?) seem to all want to push this out a year or more? | 00:16 |
| wpwrak | there's a lot of things they plan to change. e.g., the board file format. that's been pending for well over a year as well | 00:17 |
| wolfspraul | that could make someone think KiCad development has haltet... | 00:17 |
| wolfspraul | halted | 00:17 |
| wolfspraul | yes but maybe all those things are actually in "x years" status | 00:17 |
| wolfspraul | makes me proud of the Ben NanoNote :-) | 00:17 |
| wpwrak | i guess if people get too restless, a fork may happen at some point in time | 00:17 |
| wolfspraul | it cannot survive a fork, because there is already geda | 00:17 |
| wolfspraul | the footprint library is in abysmal state | 00:18 |
| wpwrak | so far, it hasn't, but there's been noises several times already | 00:18 |
| wpwrak | oh, i don't see a problem with a fork, as long as there are people who are motivated to keep it going | 00:18 |
| wolfspraul | I think the osmo-sdr guys switched from kicad to geda because of better scriptability somewhere, but I think it was inside the design (not sure). | 00:18 |
| wolfspraul | yeah, but this is too distracting for me | 00:18 |
| wolfspraul | so I can only uplevel, a bit more regularly than before | 00:19 |
| wolfspraul | I can't get into the kicad thing now | 00:19 |
| wpwrak | (distracting) we can just wait and see. if someone forks and doesn't fall over his or her own feet too quickly, we can join the new crowd | 00:19 |
| wolfspraul | well yeah, but this needs an active developer base of multiple people really intensively hacking on | 00:20 |
| wolfspraul | at least | 00:20 |
| wpwrak | i guess it needs people who can really sink 100% of their time into it | 00:21 |
| wolfspraul | yes | 00:21 |
| wolfspraul | isn't it funny how he describes the 'separation'? | 00:21 |
| wolfspraul | and that is after a talk with other lead devs? | 00:21 |
| wolfspraul | what separation? | 00:21 |
| wpwrak | for dick, wayne, etc., it's basically a weekend project | 00:21 |
| wolfspraul | a bunch of C++ classes directly through the dynamic library? | 00:21 |
| wolfspraul | and then - which ones? | 00:21 |
| wolfspraul | the GUI classes? | 00:22 |
| wolfspraul | the entire current code structure doesn't lean itself towards any kind of 'separation' | 00:22 |
| wolfspraul | it's just handwaving really | 00:22 |
| wolfspraul | "please go away and don't ask us details. and come back as late as possible" | 00:22 |
| wolfspraul | actually I think the current code structure is not bad, I would just leave it like that and gradually cleanup further | 00:23 |
| wpwrak | i think they want to separate the data model better from the GUI. right now, it's all mixed together | 00:23 |
| wolfspraul | but the separation as it is described there will never happen, 100% wishful thinking | 00:23 |
| wpwrak | of course, whether a cleaner separation really improves things in the end also remains to be seen | 00:24 |
| wolfspraul | sure, but they haven't gotten beyond the "we should really have this" level | 00:24 |
| wolfspraul | yes | 00:24 |
| wolfspraul | because that's a quite well known problem | 00:24 |
| wpwrak | sometimes, a hundred ugly lines are better than five million beautifully structured ones | 00:24 |
| wolfspraul | sure | 00:24 |
| wolfspraul | but there is nothing I can do, really. just uplevel. | 00:24 |
| wolfspraul | the patches will stay outside. | 00:24 |
| wpwrak | yeah. we can try to piss them off a little. make them feel their control might slip if they don't integrate those features :) | 00:25 |
| wpwrak | well, a few of the responses already went in this direction ;-) | 00:26 |
| wolfspraul | it's a design program, so the focus will always be GUI | 00:26 |
| wpwrak | yes and no. there is a deeper layer that's not GUI-centric | 00:26 |
| wolfspraul | if the focus is completely scripted, one could write an entirely separate engine that directly modifies the files | 00:26 |
| wolfspraul | ok I'm just starting to think for them | 00:26 |
| wpwrak | yes. that's what we currently do. and i don't mind doing that. | 00:27 |
| wolfspraul | so if the main focus of Kicad is to be a (manual) design program, then naturally it's ok that a few command-line options are being 'inserted' into the otherwise integrated codes, as the patches are doing | 00:27 |
| wolfspraul | we could cleanup that 'insertion' to a really nice level | 00:27 |
| wpwrak | the files are not extremely pretty but i've worked with worse | 00:27 |
| wolfspraul | like I said, if the focus of the entire binary is 90% manual visual editing, and 10% at most some (few) extracted codepaths accessible via command line, then that is just fine | 00:27 |
| wolfspraul | the cmdline gives you access to maybe 1% of what kicad can do in the GUI | 00:28 |
| wpwrak | yes, the problem of the command-line patches is that they try to reuse a lot of what kicad has. that's why there's a conflicht | 00:28 |
| wolfspraul | that's not a problem, that's by design | 00:28 |
| wpwrak | e.g., fped just ignores all the kicad code base | 00:28 |
| wolfspraul | the command line options just auto-execute the GUI for you | 00:28 |
| wolfspraul | oh sure, that's a separate tool | 00:28 |
| wpwrak | yes, but it's that design property that creates the conflict for the command-line patches, while i can dodge that with fped. | 00:29 |
| wolfspraul | actually the patches are quite clean | 00:29 |
| wolfspraul | there's a global, and some ugliness in some dialogs, but these things could all be cleaned up easily | 00:29 |
| wolfspraul | without waiting for a separation that will never happen | 00:29 |
| wolfspraul | but like I said, I will do nothing | 00:30 |
| wolfspraul | just uplevel | 00:30 |
| wolfspraul | not my battle | 00:30 |
| wpwrak | naw, their problems seems to be that you talk to their old code, while they'd wish you to talk to their new code instead | 00:30 |
| wolfspraul | new code? | 00:30 |
| wpwrak | alas, the lack of a time machine makes itself noticed once more ... | 00:30 |
| wolfspraul | ah, ok | 00:30 |
| wolfspraul | yes | 00:30 |
| wolfspraul | that separatoin is really nonsense | 00:30 |
| wolfspraul | it will not happen | 00:31 |
| wpwrak | it may not be nonsense | 00:31 |
| wpwrak | that's a possibility | 00:31 |
| wolfspraul | well then it's already there | 00:31 |
| wolfspraul | they have it all nicely in dialog classes | 00:31 |
| wolfspraul | it's all fine | 00:31 |
| wolfspraul | it's a GUI app | 00:31 |
| wolfspraul | sure they could move non-gui stuff in one corner, and gui stuff in another corner - but that is already happening | 00:32 |
| wolfspraul | any practical insertion of a few cmdline switches would still go right through this | 00:32 |
| wpwrak | sure. it's just mismatched perfectionism. | 00:34 |
| wpwrak | the argument would be perfectly valid if they'd be working on a massive redesign that's to be completed soon. but there's no "soon" in there. | 00:34 |
| wpwrak | maybe they're just old and slow ;-) clone sebastien, run a global FPGA to EDA substitute on the clone, and then let him loose on kicad, and we'll have a fork that outperforms all our wishes in a few weeks ;-) | 00:36 |
| wpwrak | anyway, i agree with your conclusion that upleveling is the best we can do at the moment | 00:37 |
| wpwrak | just outsitting it doesn't work, because changes are happening in the code base | 00:37 |
| wpwrak | but the future perfect code isn't a realistic target either. i.e., you can't do anything today to make your patches work with that | 00:38 |
| wpwrak | it's also good to have the functionality around, so that people can get a taste of what it is like | 00:40 |
| kristianpaul | wow i see now why other people uses geda :) | 01:55 |
| kristianpaul | better i dint tried learn kicad yet :) | 01:55 |
| kristianpaul | good that geda have its BOM :) | 01:57 |
| wpwrak | hmm ? what did you see ? and what BOM ? | 03:39 |
| DocScrutinizer | wpwrak: kicad broke ??I ? | 05:35 |
| DocScrutinizer | rather [A-Z]{1;2}I | 05:36 |
| DocScrutinizer | IE API|ABI|UI|GUI|... | 05:37 |
| DocScrutinizer | CLI | 05:37 |
| wpwrak | wolfspraul: ah, kicad ... bzr release 3551 ? i get eeschema/netlist_control.h:99: error: ISO C++ forbids declaration of 'wxNotebook' with no type | 10:50 |
| wolfspraul | yes, strange | 10:51 |
| wolfspraul | someone else reported that already | 10:51 |
| wpwrak | was there a solution ? | 10:53 |
| wolfspraul | ah, typical kicad | 11:01 |
| wolfspraul | between 3351 and 3378, they changed a massive amount of includes from #include "" to #include <> | 11:02 |
| wolfspraul | before it wasn't thought through or clean, and neither it is now | 11:02 |
| wolfspraul | but someone must feel better with <> now | 11:02 |
| wpwrak | ;-) | 11:10 |
| wpwrak | so i should use 3378 instead of 3351 ? or is this unrelated ? | 11:10 |
| wolfspraul | one moment | 11:11 |
| qi-bot | [commit] Wolfgang Spraul: upleveled to bzr3378 (master) http://qi-hw.com/p/eda-tools/e192246 | 11:32 |
| wolfspraul | can you try this against 3378? | 11:32 |
| wolfspraul | but you may still run into some problem, it seems you see the same kind of issues as someone else reported to me already, which unfortunately I don't see on my system | 11:33 |
| wpwrak | ah, and i had a typo in my checkout command. 3551 instead of 3351. | 11:49 |
| wpwrak | so 3351 would probably have been fine. trying 3378 now ... | 11:50 |
| wpwrak | interesting changes in your patch :) +-SET(CMAKE_RELATIVE_PATH_TOP_BINARY "/home/user/kicad/kicad.3378") | 11:51 |
| wpwrak | etc. | 11:51 |
| wpwrak | 286 out of 286 hunks FAILED -- rejects in file common/Makefile | 11:51 |
| wpwrak | let's go back to 3351 ... | 11:52 |
| wpwrak | ah, typo was elsewhere. i did check out 3351, not try to check out 3551 | 11:58 |
| wpwrak | so i'll just wait for the corrected 3378 patch set :) | 11:58 |
| wolfspraul | something wrong, hmm | 12:00 |
| wolfspraul | one sec | 12:00 |
| wpwrak | no rush. i still have the working old installation :) | 12:04 |
| qi-bot | [commit] Wolfgang Spraul: again, this time with correct diff (master) http://qi-hw.com/p/eda-tools/626e111 | 12:20 |
| wolfspraul | try that against 3378 (but like I said, I still do expect problems) | 12:20 |
| wpwrak | patch set applies. already a good start :) | 12:26 |
| wpwrak | make is running ... | 12:26 |
| wpwrak | build was successful ! | 12:32 |
| wpwrak | interesting. eeschema looks quite different now. | 12:33 |
| wolfspraul | ok great | 12:33 |
| wpwrak | the new logos look a bit odd ... but at least the BOM is now really easy to find ;-))) | 12:35 |
| wpwrak | the rest seems mainly window dressing | 12:38 |
| wpwrak | but great that it works. thanks ! | 12:39 |
| qi-bot | [commit] Werner Almesberger: kicad-patches/README: updated for bzr 3378 (master) http://qi-hw.com/p/eda-tools/b8ab60a | 12:40 |
| wolfspraul | do you think they are doing substantial development, aside from moving code around? | 12:55 |
| wpwrak | dunno | 12:59 |
| wpwrak | two minor enhancement this year, it seems: the track width adjustment and the electra .ses files support, whatever they are | 13:08 |
| whitequark | sigh. damned flash. they introduced a lookupswitch opcode (a jump target lookup table), only to compute indices for it with this: http://pastie.org/3249683 | 13:16 |
| whitequark | I am especially amused by the bottom of the construct. | 13:16 |
| wpwrak | whitequark: if you take a job at the sewers, why do you complain about the smell of feces ? :) | 13:17 |
| whitequark | oh, my job is to draw a map of pipes. employer never said anything about feces :/ | 13:18 |
| whitequark | ;) | 13:18 |
| whitequark | this is quite fun actually, and the code can and will be reused (most bytecode stack-based VMs are surprisingly similar) | 13:19 |
| whitequark | http://pastie.org/3250093 Y U NO CONSTANT FOLDING? | 14:39 |
| larsc | sometimes you really have to wonder | 14:47 |
| whitequark | about what? | 14:47 |
| larsc | about flash | 14:48 |
| whitequark | constant folding is ~150 lines in ruby, including opcode type inference | 14:49 |
| whitequark | why the hell cannot they do that. | 14:49 |
| larsc | do they do any compile time optimizations at all? | 14:50 |
| whitequark | nope | 14:50 |
| whitequark | Alchemy (LLVM AS3 backend) beats their AS3 compiler in, well, most of cases. | 14:50 |
| whitequark | and it uses things like virtual stack and RAM. | 14:50 |
| larsc | maybe their vm does all the optimizations? | 14:52 |
| wpwrak | maybe they simply don't care ? ;-) | 15:19 |
| whitequark | larsc: the vm (tamarin) sucks quite a bit too | 15:23 |
| kristianpaul | wpwrak: about BOM i just read that from geda webpage | 15:42 |
| wpwrak | you mean they only recently added BOM generation ? | 15:44 |
| kristianpaul | dunno if recenlty just did a grep to its website | 15:45 |
| kristianpaul | curl www.gpleda.org/ | grep BOM | 15:45 |
| kristianpaul | no more :9 | 15:45 |
| kristianpaul | actually i tought you already knew it about it | 15:46 |
| wpwrak | i'm not tracking geda | 15:52 |
| kristianpaul | interesting http://geda.seul.org/wiki/geda:bom_readmeok | 15:54 |
| kristianpaul | ah | 15:54 |
| kristianpaul | ok | 15:54 |
| wpwrak | thanks ! | 15:54 |
| wpwrak | "Eventually I'd like to integrate this with some sort of a database" hehe :) | 15:55 |
| wpwrak | well, every journey of a thousand miles begins with the first step ... | 15:55 |
| tedious | Hi, been looking around the wiki, and web searched a bit, but couldn't find the answer. Forgive me if it's obvious or easily found. - Does the Ben NanoNote require any non-free(non-libre) software? | 19:21 |
| viric | tedious: no | 19:42 |
| viric | tedious: I wrote a small distro for it - zero blobs, as far as I understand | 19:43 |
| viric | the sound driver is somehow 'big', but it's in the linux kernel tree, so I imagine it's free. | 19:43 |
| tedious | viric: Thank you for the response, this is great to know. - May I get the sound drivers name? | 19:44 |
| viric | jz47xx is the SoC | 19:44 |
| viric | then, audio for that | 19:44 |
| viric | tedious: the kernel options are: SND_JZ4740_SOC and SND_JZ4740_SOC_QI_LB60 | 19:45 |
| viric | now that I check, they are not very big | 19:47 |
| tedious | Hmm, being a newbie, not entirely sure how to ask this, and if I ask it incorrectly, I do apologize. - How would I check the license for the drivers? :o | 19:54 |
| viric | tedious: read the acompaning licence in the header of C files of linux sound/soc/jz4740 | 20:03 |
| viric | I'd do that. | 20:04 |
| tedious | viric: Thank you. :-) | 20:54 |
| tedious | As for the driver needed for the video portion, what would it be called? | 21:34 |
| viric | the frame buffer | 21:35 |
| viric | what is this investigation about? :) | 21:35 |
| whitequark | look for jz4740_fb.c | 21:35 |
| tedious | viric: I want to be _certain_ that the next hardware I purchase doesn't require non-free software. :-) | 21:37 |
| tedious | whitequark: Thank you. | 21:37 |
| viric | ahh | 21:37 |
| viric | I built the distro I told you from source. | 21:38 |
| viric | I couldn't see any magic in the path | 21:38 |
| kristianpaul | viric:can i boot your marvelous distro by micro-sd? | 21:39 |
| viric | it will give you a mingetty and then a bash :) | 21:40 |
| viric | what does it mean, by microsd? | 21:40 |
| viric | will it load the kernel from the microsd? | 21:40 |
| kristianpaul | memory card | 21:40 |
| tedious | viric: Not that I didn't believe you, but I wanted to seek it myself as well. :3 - Also was curious about the licenses. - What is your distro name, by the way? | 21:40 |
| kristianpaul | no the distro i mean, full userland | 21:40 |
| viric | tedious: world famous nanonixos | 21:40 |
| viric | kristianpaul: I don't think it will boot with an openwrt kernel | 21:41 |
| kristianpaul | hmm | 21:41 |
| viric | I use /init as boot. | 21:41 |
| viric | instead of /new-path-thought-by-openwrt | 21:41 |
| viric | kristianpaul: that, imagine said "con rintintÃn" | 21:41 |
| viric | :) | 21:42 |
| kristianpaul | je ;) | 21:45 |
| viric | http://vicerveza.homeunix.net/~viric/cgi-bin/nanonixos/doc/trunk/doc/boot.wiki | 21:46 |
| viric | ah, it loads the kernel from the sd | 21:46 |
| viric | kristianpaul: so I could try to prepare a tarball to unpack into a sd, rigth? | 21:48 |
| kristianpaul | :o) | 21:49 |
| viric | well, there isn't much to see, really... in the best case, it will boot and offer you a bash. | 21:50 |
| viric | you'll type lynx, and you'll see lynx | 21:50 |
| viric | kristianpaul: the nanonote web page has a section "Is this for me?" : | 21:51 |
| kristianpaul | hmm | 21:51 |
| viric | :) | 21:51 |
| kristianpaul | lol | 21:51 |
| tedious | So, is there any hope for an external keyboard on the ben nanonote? (Been looking around online and not getting much to go off of) | 21:54 |
| viric | tedious: if you could find a sdio keyboard.. :) | 21:55 |
| xakh | hey, just a small question | 21:55 |
| xakh | I keep hearing rumours that the Ya is like, in production. | 21:55 |
| xakh | is this true? | 21:55 |
| xakh | wolfspraul: you know anything about the timeline of Ya nanonote? | 21:57 |
| xakh | zear: you know anything about the Ya Nanonote? | 22:06 |
| wolfspraul | wow we have rumors like at Apple - cool | 22:09 |
| wolfspraul | what do we do to make the rumors get bigger? we say nothing | 22:10 |
| wolfspraul | oh wait, we are not Apple | 22:10 |
| wolfspraul | xakh: the rumor is wrong. I think the Ya will not happen in 2012, at least my full focus is on Milkymist One now, whose technology may well be merged with the NanoNote (then Ya) later. | 22:10 |
| wolfspraul | until then it's all about Ben NanoNote, which is very much alive, shipping, software being improved, etc. | 22:11 |
| xakh | good | 22:11 |
| wolfspraul | thanks for asking! | 22:12 |
| xakh | I have mine, and my friend was eying one | 22:12 |
| xakh | alright, thanks for clearing that up! | 22:13 |
| kristianpaul | i want it ya ;) | 22:13 |
| wpwrak | ya ya ;-) | 22:19 |
| tedious | viric: Having no luck finding an sdio keyboard. :p | 22:43 |
| tedious | Know of anyone making/using one successfully? | 22:44 |
| mstevens | I should dig my nanonote out again and play with it | 22:45 |
| mstevens | update the build | 22:45 |
| viric | no, I don't know any | 22:49 |
| viric | but I never searched | 22:49 |
| viric | mstevens: all fine with the fuloong? | 22:49 |
| mstevens | viric: various minor problems | 22:50 |
| viric | fixed problems? | 22:51 |
| mstevens | not yet | 22:51 |
| viric | I finally booted the kernel.... enabling VGA_CONSOLE hangs it early at boo | 22:51 |
| viric | t | 22:51 |
| mstevens | viric: worst problem is extremely poor DVI video quality | 22:51 |
| viric | I've never had a dvi cable | 23:05 |
| viric | the vga has some problems at very high resolutions | 23:05 |
| viric | some trembling | 23:05 |
| viric | isn't dvi a digital link? What can be bad there? | 23:06 |
| viric | maybe you use the analog signals of the DVI? | 23:06 |
| mstevens | I'm seeing weird stuff | 23:06 |
| mstevens | incorrect colours | 23:06 |
| mstevens | moving texture in what should be solid colour blocks | 23:07 |
| viric | and the vga is fine? | 23:07 |
| mstevens | yes | 23:07 |
| viric | how weird then. maybe noone used the dvi. | 23:07 |
| mstevens | viric: I'm wondering if it's software, I'm wishing I'd tested more carefully with openrays or whatever it is before I wiped it | 23:11 |
| viric | :) | 23:12 |
| viric | write to the list | 23:12 |
| viric | loongson-dev | 23:12 |
| mstevens | it's hard to see what it could be though | 23:12 |
| mstevens | viric: I may try that | 23:12 |
| --- Thu Jan 26 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!