| 00:31.21 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 00:40.47 | wolfspraul | wpwrak: did someone else already update the m1 sheet order in schhist? |
| 00:40.58 | wolfspraul | I'm just going through to update to what you wrote but it seems we have that already :-) |
| 00:42.14 | wolfspraul | but strange, in the web view it's different somehow. I will rebuild the history |
| 00:42.53 | wpwrak | yeah. maybe it just wasn't built with the right order yet. |
| 00:43.22 | wolfspraul | rebuilding now |
| 00:51.15 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 00:55.34 | wpwrak | running a local build too, to compare |
| 00:57.35 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:12.11 | cladamw | (variable's value undefined) wpwrak if shows up a value is undefined when i used variable to set, but i'm very sure those variables defined in other frame, does this mean a variable in current frame must to referred to its parent frame ? |
| 01:13.23 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host171-91-dynamic.54-79-r.retail.telecomitalia.it) |
| 01:16.25 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 01:30.45 | wpwrak | cladamw: variables are visible in the frame in which they are defined and in all the child frames. they are not visible in frames that are parents of the frame in which the variables are defined. |
| 01:34.19 | cladamw | wpwrak, can i imagine as they child (visible) are local variables for child frame, invisible one are global variables to related parents of frames ? |
| 01:35.12 | wpwrak | what i mean is that a variable defined in a frame can be used in that frame and in all child frames. it doesn't exist in frames that are parents of the frame in which it is defined. |
| 01:35.44 | wpwrak | however, those parents may define variables of the same name. but they would be distinct items. |
| 01:37.22 | wpwrak | you could call a variable "global" if it is defined in the root frame. however, that's no different from how all other variables work. |
| 01:38.30 | wpwrak | wolfspraul: 41:20 minutes later ... there's indeed something wrong with the order :-( |
| 01:38.33 | wpwrak | digging .... |
| 01:45.48 | cladamw | wpwrak, interesting ... now i just felt that if a vector C (in B frame) pointed to A frame, if I defined (X, Y) for C, and there's X includes variables in A, then it's okay. If I let vector pointed to C, then shows up X's value is undefined. btw, I need to practice more. :-) |
| 01:48.26 | wpwrak | vectors can't cross frames |
| 01:49.12 | roh | wpwrak: you are developing your own cad now? |
| 01:49.37 | cladamw | yeah ... i meant when i set (X, Y) for a vector. :-) |
| 01:49.38 | wpwrak | roh: just the footprint editor, fped |
| 01:49.38 | roh | thinks the world needs better foss cam first ;) |
| 01:49.50 | roh | wpwrak: hrhr.. i see |
| 01:50.43 | wpwrak | roh: but you can use it as CAD as well. for 2D, it's actually pretty good if you don't need overly fancy things. (not that it would be hard to add more features, but i like to keep it simple) |
| 01:51.21 | wpwrak | roh: i'm even experimenting with 2.5D, but i'm less pleased with the results there |
| 01:51.48 | roh | wpwrak: check out 'cambam' |
| 01:52.05 | roh | there is a version which runs on linux now too. its in .net, so mono then |
| 01:53.05 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 01:53.22 | cladamw | wpwrak, btw, playing your Fped needs strong Mathematics on: geometry, algebra; and hierarchical conceipts. |
| 01:53.56 | wpwrak | cladamw: see, those long hours at school were good for something ;-))) |
| 01:54.10 | wpwrak | roh: is it open source ? |
| 01:54.17 | roh | wpwrak: sadly not. |
| 01:54.51 | wpwrak | roh: sigh |
| 01:55.11 | roh | wpwrak: the functions heekscad used via heekscam in libkurve and so on are foss |
| 01:55.24 | roh | also stuff like the adaptive roughing algos etc |
| 01:55.54 | roh | so.. the code is there in principle.. but nobody made a reasonable useable app out of it |
| 01:56.03 | wpwrak | roh: meanwhile, cameo (that's my CAM data conditioning system) can now do polygons inside polygons correctly. i'm using CGAL for the tricky offsetting operation. |
| 01:56.51 | roh | i would really like to have somthing which i can use to make gcode from dxf |
| 01:57.03 | roh | defining how the different elements should be used |
| 01:58.19 | wpwrak | cladamw: you should normally not need a log of algebra. but geometry and hierarchy, definitely yes. the main difficulty is in breaking down the reference design in a way that makes sense. the reference drawings have their own logic, but it's never explicitly stated. so you have to first solve that puzzle. after that, making fped produce it is relatively easy. |
| 01:58.46 | cladamw | wpwrak, the 'Variables' section i think you are too busy to introduce it in details -> http://people.openmoko.org/werner/fped/gui.html |
| 01:59.27 | wpwrak | roh: that i have is something that takes gerber/gnuplot and produces gnuplot (and i have a gnuplot to rml-1 converter. shouldn't be too hard to write a gnuplot to g-code converter as well) |
| 02:00.02 | wpwrak | cladamw: yeah, the manual still needs work :) right now, it's more a teaser ... |
| 02:00.31 | roh | wpwrak: well.. i didnt want to go into that low-level you seem to use that much. |
| 02:00.32 | cladamw | wpwrak, yeah ... no problems, i like very much on this tool: easy to figure background knowledges from school and how they( math ) applies in this tool. :-) |
| 02:00.55 | wpwrak | roh: still lacking a nice parametric 3D cad :) |
| 02:01.18 | cladamw | the problems for me now is that I need to get used to each icons and relationships in GUI, etc ... |
| 02:01.21 | roh | i usually design in qcad and then have different steps to test the design (laser in plywood, iterate till fit) and generate gcode from the result of that |
| 02:01.36 | roh | wpwrak: autocad *veg* |
| 02:02.00 | roh | propably also rhino, solidworks and whattheyareallnamed |
| 02:02.01 | wpwrak | roh: my 2.5D is basically a set of layers with Z information. i hacked fped to allow vectors to cross frame boundaries, so one can set up the basic geometry in the root frame and then build on that. but it's not very pretty. |
| 02:02.32 | wpwrak | roh: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/bacon/case/case.fpd |
| 02:03.02 | roh | wpwrak: doesnt help me at all. i need stuff i can work with visually. |
| 02:03.11 | wpwrak | cladamw: (case.fpd is where fped shows its full power ;-) |
| 02:04.08 | wpwrak | roh: the 2.5D stuff is semi-visual. the fped gui can visualize it, but you can't edit everything there at the moment (because of the hacked vectors) |
| 02:04.23 | roh | wpwrak: you know that basically all grown up cad tools do constraint handling as well, right? |
| 02:04.35 | roh | which in the end is nothing but parametric working |
| 02:04.54 | wpwrak | roh: not more than four or five wars at a time ;-) |
| 02:05.07 | roh | hehe |
| 02:05.34 | roh | i still hope somebody will add cam features to librecad at some point (what was qcad once) |
| 02:05.39 | cladamw | wpwrak, what's bacon ? |
| 02:06.14 | cladamw | wpwrak, okay, add its case to my full example. :-) |
| 02:06.51 | wpwrak | cladamw: (get used to icons, etc.) mastering fped is mainly a questions of developing a workflow. like with most other tools. once you made a few footprints, you'll find it easy to make more. |
| 02:07.25 | wpwrak | (bacon) a case design for a small battery-powered device |
| 02:11.37 | roh | We found it out when an Ukrainian hacker sent a message to our mailing list. His English was very poor and we couldn't figure out what he meant until he replied with a code snippet in C. |
| 02:11.43 | roh | wonderful snippet |
| 02:15.17 | *** join/#qi-hardware rlifchitz (~rlifchitz@unaffiliated/rlifchitz) |
| 02:20.38 | wpwrak | cladamw: this is what it looks like (with an unpopulated pcb inside, and the bottom side not yet finished): http://downloads.qi-hardware.com/people/werner/tmp/bacon-top.jpg |
| 02:20.43 | wpwrak | http://downloads.qi-hardware.com/people/werner/tmp/bacon-bot.jpg |
| 02:23.58 | wpwrak | wolfspraul: seems that the problem is that i forgot to put FPGA_ before each of the BANKn in SCHHIST_ORDER. rerunning ... |
| 02:26.39 | cladamw | wpwrak, tks. :) |
| 02:28.37 | wpwrak | roh: the role of my "low-level stuff" varies. i the case of 2D, it's mainly machine setup and toolpath generation. the actual design happens in fped or kicad and is reasonably friendly. e.g., this is an fped-made 2D design: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/case/case.fpd |
| 02:30.19 | wpwrak | roh: for 2.5D, things turn considerably darker, though. for example, here you can see the whole pipeline for that plastic case: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/bacon/case/Makefile |
| 02:30.48 | roh | wpwrak: hm. well.. i guess my designs are simply some factors more complex then |
| 02:30.53 | wpwrak | the actual toolpath generation and machine setup is pretty straightforward, though: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/bacon/case/cam.sh |
| 02:31.37 | roh | and my toolpathes have toolchanges in them nowadays.. so i usually have some ops only on parts of the file. |
| 02:31.37 | wpwrak | yeah, if you have complex curves, then fped and such reach their limits |
| 02:31.52 | roh | not even that. but drilling cycles, pockets etc. |
| 02:32.31 | roh | stuff like 'my millhead looks like that, this is what i want to do, and thats how the object looks like to do it on. ah.. and $foo is your safe-height |
| 02:32.32 | wpwrak | i have toolchanges as well. for pcbs, i generate a drill and a mill path. (could be multiple drills, but i try to avoid that) |
| 02:33.05 | wpwrak | my mills are all cylindrical :) |
| 02:33.33 | roh | heh. well.. i have only used the ballmills once now, but they make nice watelines possible |
| 02:33.41 | roh | eh waterline |
| 02:34.51 | wpwrak | what's a waterline ? |
| 02:35.42 | roh | think of you want to mill a riverbed |
| 02:35.57 | roh | and now push everything down below the waterline and slowly let it come up |
| 02:36.05 | wpwrak | non-cylindrical mills could be interesting for undercuts (without rotating the workpiece) |
| 02:36.45 | wpwrak | ah, you mean that you get smoother "steps" |
| 02:36.52 | roh | one can remove material with cylindric ones to save time, but in the end one takes a ball and does zigzag or waterline over the surface to remove material |
| 02:51.01 | cladamw | wpwrak, http://dpaste.com/751367/ I'll add those texts into http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/modules/INFO |
| 02:51.41 | cladamw | wpwrak, is it okay to you ? i see a "F" is to define name for Footprint name. |
| 02:56.21 | wpwrak | looks good, yes |
| 02:56.42 | wpwrak | we can later add these things to BOOKSHELF as well, and link them with the N: tag |
| 02:57.02 | cladamw | okay, i see. |
| 02:57.07 | *** join/#qi-hardware rejon_ (~rejon@li408-40.members.linode.com) |
| 03:00.54 | qi-bot | [commit] Adam Wang: INFO: added tag F: mdip (master) http://qi-hw.com/p/kicad-libs/d18ba26 |
| 03:05.13 | *** join/#qi-hardware rejon_ (~rejon@li408-40.members.linode.com) |
| 03:25.20 | *** join/#qi-hardware rejon_ (~rejon@li408-40.members.linode.com) |
| 04:25.11 | *** join/#qi-hardware Martix (~martix@4.177.broadband3.iol.cz) |
| 04:50.12 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 04:53.48 | qi-bot | [commit] Werner Almesberger: schhist/schhist2web: correct handling of deferred columns (master) http://qi-hw.com/p/eda-tools/78bcb8d |
| 05:23.45 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 05:39.17 | *** join/#qi-hardware phirsch__ (~smuxi@xdsl-78-35-60-178.netcologne.de) |
| 06:31.36 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 06:32.50 | *** join/#qi-hardware jurting (~jommpa90_@ip-68-223-241-92.dialup.ice.net) |
| 06:46.10 | *** join/#qi-hardware jluis|work (~jpddb@83.247.136.72) |
| 06:48.19 | qi-bot | [commit] Adam Wang: mdip.fpd: added. (master) http://qi-hw.com/p/kicad-libs/ba2a95b |
| 06:54.01 | cladamw | wpwrak, just finished my first module by your Fped. :) Not just copy-and-paste art, from zero text to gradually added instances and objects. So pls kindly help to comment it. Meanwhile still learning your some useful 'table' and other magic math. |
| 06:57.13 | cladamw | wpwrak, this one I didn't add any 'measurements' as it's a 'generic' MDIP package for a 'side' = 2 ... 6 |
| 07:41.10 | wpwrak | (build from scratch) very good ! let's see how it works ... |
| 07:42.14 | wpwrak | meaurements are a bit tricky. you'll notice that fped doesn't always let you pick the things you want. so this takes a bit of experimenting. |
| 07:45.05 | wpwrak | looks pretty good. it's nicely structured, too |
| 07:45.27 | *** join/#qi-hardware wolfspraul (~wolfsprau@221.220.191.67) |
| 07:46.07 | wpwrak | wolfspraul: this should do the trick: SCHHIST_ORDER=m1:POWER:FPGA_Dec:FPGA_BANK0:FPGA_BANK1:FPGA_BANK2:FPGA_BANK3:EXPANSION_RESET:DRAM:NOR_FLASH:AUDIO:DVI-I:VIDEO_IN:MISC_CONTROL:ETHERNET:USB_A-B:USB_C-D:USB_E-F:MISC |
| 07:47.46 | wpwrak | wolfspraul: you'll also want to pull the latest eda-tools. there were a few bugs in an earlier change to populate the table, which messed up the columns. if you rebuild, you can run from the cache. |
| 07:51.19 | wpwrak | cladamw: one slight improvement would be to assign pitch*(i-(side-1)/2) to a variable (e.g., x) in the "pins" frame, and then use x in the vector. instead of doing all the calculation there. |
| 07:54.46 | cladamw | wpwrak, tks ! which x ? Doesn't I use math expression ? :-) |
| 07:55.42 | wpwrak | you could add a variable "x" in frame "pins" and assign the value pitch*(i-(side-1)/2) to it |
| 07:56.17 | wpwrak | then the vector that's currently (pitch*(i-(side-1)/2), 0mm) becomes simply (x, 0mm) |
| 07:56.59 | wpwrak | oh, and i would specify the pad sizes in mil, since those components have an imperial heritage |
| 07:58.56 | wpwrak | when you add measurements, you'll see that your land pattern is too narrow |
| 08:00.16 | wpwrak | you can change the unit fped uses when displaying dimensions by clicking on the little white box in the lower right corner |
| 08:01.18 | wpwrak | "mm" and "mil" so what you'd expect. "auto" makes fped look for the simplest value for each dimension, and then pick the corresponding unit |
| 08:02.19 | cladamw | nice remind, i didn't notice there's option to change unit, good. :) |
| 08:02.40 | wpwrak | e.g., after changing Px and Py to mil, measurements of the pad sizes will yield distances in mil when set to "auto", since, for example, 360 mil is simpler (less non-zero digits) than 9.144 mm |
| 08:03.35 | *** join/#qi-hardware xiangfu (~xiangfu@123.115.10.11) |
| 08:04.03 | wpwrak | here's a version with a few measurements: http://downloads.qi-hardware.com/people/werner/tmp/mdip-meas.fpd |
| 08:06.44 | wpwrak | when adding measurements, you normally have to specify the offset from the line between the endpoints (or one endpoint some projection of the other, depending on what sort of measurement it is) and the line with arrows on which the value is displayed |
| 08:08.01 | wpwrak | e.g., for the measurement of the distance between the outer pad edges (360 mil), i've set an offset of 5 mm |
| 08:08.34 | wpwrak | offsets can also be negative |
| 08:15.01 | cladamw | nice ! so Fped can accept like 70.07874mil(1.78mm), but you usually let it be 70mil; and 59.84252mil(1.52mm) to be 60mil ? |
| 08:16.17 | cladamw | yeah ... my land pattern doesn't meet 10.54mm. :( |
| 08:18.43 | cladamw | okay, so measurements still can be done in one vertical side, but horizontal side can't. |
| 08:21.46 | wpwrak | (horizontal) sure it can ;-) you just have to pick the right pair of points |
| 08:23.16 | wpwrak | e.g., upper left corner of pad 1 to lower right corner of pad N/2+1 |
| 08:24.58 | cladamw | oah ? i was thought horizontal one can't since 'loop side'. Nice ! |
| 08:25.15 | wpwrak | (70.078774mil) just following the specification in http://www.fairchildsemi.com/ds/6N/6N138.pdf |
| 08:25.44 | wpwrak | there, the sizes in mil are nice round numbers |
| 08:26.49 | cladamw | yeah ... so i meant it's good to use 'round' or exact right 70.07874mil ? |
| 08:27.51 | wpwrak | (loop side) that's why the measurements have somewhat odd semantics. see http://projects.qi-hardware.com/index.php/p/fped/source/tree/master/README#L570 |
| 08:28.14 | wpwrak | the "right" value is 70 mil, not 70.07874 mil |
| 08:29.34 | wpwrak | you get 70.07874 mil only if you take a design that is based on mil, use the value in mm (which has been translated from mil), and then calculate back to mil |
| 08:36.40 | wpwrak | if you can't find good points for taking a measurement, you can also add a vector just for that purpose. e.g., for measuring Py, the only points available are the lower right corner of pad 1 and the upper left corner of pad 2. if you don't like that, you can add, say a vector to -Px/2, -Py2 and then measure everything on the left side |
| 08:42.43 | wpwrak | you can get even finer control over the measurements by editing the .fpd file: http://projects.qi-hardware.com/index.php/p/fped/source/tree/master/README#L619 |
| 08:45.09 | cladamw | good. i found my mistakes on calculation, width should be 355mil. :-) |
| 08:46.05 | cladamw | okay .... tks for pointing the measurements, need to practice more. :-O |
| 08:46.05 | wpwrak | and the outline may need a separate width parameter |
| 08:46.23 | wpwrak | you'll have fun :) |
| 08:53.21 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 09:30.30 | qi-bot | [commit] Adam Wang: mdip.fpd: 1) set mil unit 2) added measurements 3) set width = 355 mil (master) http://qi-hw.com/p/kicad-libs/c1811e3 |
| 09:30.39 | *** join/#qi-hardware panda|x201 (~hzhang@123.112.96.237) |
| 09:31.52 | cladamw | wpwrak, check out for latest. yeah ! lots fun in measurements. :-) |
| 09:33.20 | cladamw | wpwrak, but i still didn't add width parameter in 'outline' frame. :) as go for other topic to learn. :-O |
| 09:36.32 | *** join/#qi-hardware jurting (~jommpa90_@ip-68-223-241-92.dialup.ice.net) |
| 09:38.33 | cladamw | wpwrak, btw, the unit setting is powerful then could quickly confirm dimensions with datasheet. i think this was a motive to develop Fped, bravo ! |
| 09:55.21 | wpwrak | yeah, now it looks quite good |
| 09:56.32 | wpwrak | (confirm dimensions) thanks ;-) yes, making reviews easy is one of the main design goals. |
| 09:58.04 | wpwrak | another one is to take care of repetitive tasks. things like iterating over all the pins or iterating over several package sizes. |
| 10:19.32 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-199-31.w83-115.abo.wanadoo.fr) |
| 10:24.21 | *** join/#qi-hardware pabs3 (~pabs@d122-111-252-61.per801.wa.optusnet.com.au) |
| 11:26.08 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 11:42.15 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 11:55.17 | *** join/#qi-hardware zear_ (~zear@2001:0:5ef5:79fd:2c6e:260b:2abe:b43b) |
| 12:02.21 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 12:30.10 | *** join/#qi-hardware jivs_ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 13:05.58 | *** join/#qi-hardware jivs__ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 13:19.55 | *** join/#qi-hardware jivs__ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 13:20.24 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host171-91-dynamic.54-79-r.retail.telecomitalia.it) |
| 14:04.17 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 14:09.04 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 14:19.45 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 14:36.04 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 15:13.36 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-199-31.w83-115.abo.wanadoo.fr) |
| 15:47.51 | *** join/#qi-hardware Martix (~martix@4.177.broadband3.iol.cz) |
| 16:08.11 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 18:32.52 | *** join/#qi-hardware phirsch_ (~smuxi@xdsl-89-0-96-118.netcologne.de) |
| 19:11.13 | *** join/#qi-hardware zear (~zear@2001:0:5ef5:79fd:2c6e:260b:2abe:b43b) |
| 21:43.30 | qi-bot | [commit] Werner Almesberger: b2/subex.c (compose): use stralloc_n instead of open-coding its functionality (master) http://qi-hw.com/p/eda-tools/db279b7 |
| 21:43.31 | qi-bot | [commit] Werner Almesberger: b2/boom.c (usage): -Q wasn't mentioned; explain -q and -Q (master) http://qi-hw.com/p/eda-tools/7c8fc30 |
| 21:43.32 | qi-bot | [commit] Werner Almesberger: b2/: add parsing of KiCad eeschema BOMs (option -b) (master) http://qi-hw.com/p/eda-tools/ddd22ba |
| 21:43.34 | qi-bot | [commit] Werner Almesberger: b2/bom.c (bom_parse_line): check that components reference are unique (master) http://qi-hw.com/p/eda-tools/9445f2c |
| 21:43.36 | qi-bot | [commit] Werner Almesberger: b2/util.c: new function unique_n for strings limited by length and not NUL (master) http://qi-hw.com/p/eda-tools/b9066c6 |
| 21:43.38 | qi-bot | [commit] Werner Almesberger: b2/subst.c (parse_var): use unique_n (master) http://qi-hw.com/p/eda-tools/a537cc5 |
| 21:43.40 | qi-bot | [commit] Werner Almesberger: b2/: add parsing of supplemental symbol information (option -X) (master) http://qi-hw.com/p/eda-tools/f223789 |
| 21:43.42 | qi-bot | [commit] Werner Almesberger: b2/bom.h (struct bom): remove unused "next" pointer (master) http://qi-hw.com/p/eda-tools/4fb17f6 |
| 21:43.44 | qi-bot | [commit] Werner Almesberger: b2/: run variable substitution on BOM entries (untested) (master) http://qi-hw.com/p/eda-tools/ec04163 |
| 21:43.46 | qi-bot | [commit] Werner Almesberger: b2/: add BOM dumping; dump processed BOM entries (master) http://qi-hw.com/p/eda-tools/66aea07 |
| 22:26.38 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 22:49.21 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 23:09.59 | wolfspraul | wpwrak: good morning :-) |
| 23:10.10 | wolfspraul | schhist reran entirely with latest eda-tools, and I think it looks good now |
| 23:10.19 | wolfspraul | nice! |
| 23:31.55 | wpwrak | whee ! victory ! :) |
| 23:59.53 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
