<kristianpaul>
wolfspraul: do you know what the Jz4750L Ingenic board is, and what i have an FPGA ?
<kristianpaul>
i just discover it reading some lines from u-boot changelog
<wolfspraul>
kristianpaul: don't understand your question
<wolfspraul>
I think the 4750L is the low-cost (=cob) version of the 4750
<kristianpaul>
wolfspraul: i found this line in the U-boot source code
<kristianpaul>
2009.05.14
<kristianpaul>
* Add Jz4750L platform: F4750L board(which is a FPGA board).
<kristianpaul>
and the FPGA word call my atention, no more :-)
<wolfspraul>
hmm
<wolfspraul>
I can only guess.
<wolfspraul>
so the 4750 is a 'normal' chip, very much like 4720/40 just with some improvements
<wolfspraul>
'l' is the low-cost version
<wolfspraul>
now, inside the Ingenic office I regularly see _a lot_ of different boards
<wolfspraul>
they are building all kinds of small-volume prototype boards for development, for customers, with customer, by customers, etc.
<wolfspraul>
and I have seen fpgas in combination with Ingenic chips on some of those boards
<wolfspraul>
very much like SIE
<kristianpaul>
I see
<wolfspraul>
probably because Ingenic, and/or their customers, are prototyping or developing something
<wolfspraul>
the support for all these different boards in the u-boot, or Linux kernel, or other kernel sources is messy
<wolfspraul>
because a lot of these boards are only made in a few units, and are superseded by something else quickly, and/or the customer or Ingenic aborts the development, etc.
<wolfspraul>
so maybe that line is connected to such a board
<wolfspraul>
also notice that it says "F4750L"
<wolfspraul>
F = fpga?
<kristianpaul>
dont know
<wolfspraul>
but even then, you will most likely not find information about this board anywhere
<wolfspraul>
they make 10, for whatever reason, learn something from it or not, and move on
<kristianpaul>
yes i realized that before asking you :-)
<zrafa>
wolfspraul: all: some guy was talking me several times because he uses jlime and he was very interested on the wikireader thing and other features... Few days ago he was explaining me that he, and his students (uni) are trying to write a nice GUI, very easy to use (imagine like just one search bar like goolge, or few buttons), to convert the nanonote as a device similar to this : http://www.literacybridge.org/talking-book/ .. But, because nn is a lot more
<zrafa>
wolfspraul: He already has around 30 nns!.. which is a really nice
<zrafa>
if he is really interested on to do that thing.
<zrafa>
I think that his idea is really nice as final target for a device like nn,
<zrafa>
so I am trying to tell him to join community (like this channel :) ) in order to do the whole idea working
<kristianpaul>
wow 30 sounds like a pilot coming?..
<kristianpaul>
s/pilot/small deployment
<wolfspraul>
zrafa: wow he has 30 nanonotes?
<wolfspraul>
sure it sounds good
<wolfspraul>
I think we will see lots of great apps next year...
<kristianpaul>
:D
<wolfspraul>
I am currently hacking up a little script that will let me download ogg music files from wikimedia commons :-)
<kristianpaul>
wow
<zrafa>
wolfspraul: yes, he told me that he and his students has around 30 nns. And maybe they would need more
<zrafa>
wolfspraul: downloader script : nice :) if you do I would add the GUI :)
<wolfspraul>
well they only have classical music there, but it's a start. I also saw the 'spoken wikipedia' project, which made me realize to look for audio books...
<kristianpaul>
wolfspraul:Â Â audio books > a lot of then in the public domain at librivox.org
<zrafa>
wolfspraul: does your script would list on stdout the list of music files available?
<kristianpaul>
had you tught in Gutenberg proyect, i think their format is better to port on nanonote than wiki-* also wikireader startert to incorporate? (maybe people get tired of reading just wikis..)
<kristianpaul>
s/tught/tought
<kristianpaul>
"The software on the Talking Book is the heart of the device. Because it is a computer, we can work with our partners to customize the software to precisely fill their needs. "
<kristianpaul>
well i dint expected something better..
<kristianpaul>
zrafa: i guess they are using your wikipedia-gnudict plugin?
<zrafa>
kristianpaul: about talking book: just a note: he is not wanting to use that software if I understood him corretly. It is just a link to show the idea
<kristianpaul>
arggg i need a good ccc low bandwitch streaming link..
<kristianpaul>
zrafa: (link) sure it points the idea
<zrafa>
kristianpaul: I have no idea exactly which thing they use, but from what he told me he wants to understand how we did the wikireader, no to use it. And he is not going to do a wikireader either, they want to do a new thing easy to use
<kristianpaul>
sure
<zrafa>
so they would not use the current stuff. They want to understand how to play music, video; how to show graphics, pictures, how to do some engine of knowledge, things like that
<Jay7>
wikireader + festival :)
<wolfspraul>
zrafa: yes sure, browse categories and list files. 10 lines php :-)
<wolfspraul>
it's not finished yet, need to find a few hours so that it can download as well. I just want an easy way to download music to my nano.
<wolfspraul>
also for it to work on the NanoNote, the current script uses the HTTP_Request class which I doubt it installed right now.
<wolfspraul>
of course there are other ways like invoking wget, but I like to stay in php
<kristianpaul>
wpwrak: i finally discover the cpu is reading tos fast the ram-like-fpga-setup, so i'm implementing a delay in software.. to avoid repeated data
<kristianpaul>
s/tos/too
<kristianpaul>
hmm i dint work as i spected..
<kristianpaul>
I need an IRQ (glup!)
<kristianpaul>
I found a "IRQ" signal, but it is also LCD_D15 pin.. :/
<wpwrak>
kristianpaul: no free IRQs on SIE ? :-(
<wpwrak>
wolfspraul: (kicad patches) hmm, eeschema-bom-only-mode.patch has a change to eeschema/CMakeLists.txt where the context contains cmp_library_keywords.cpp. my bzr revision 2358 doesn't have this.
<wolfspraul>
wpwrak: he one we 'standardized' upon was 2448?
<wolfspraul>
that was the one you told me you are using...
<wpwrak>
hmm, maybe i got lost myself :) lemme check ...
<wolfspraul>
upticking kicad is another thing, I will not make the first step there, no need right now (for me)
<wolfspraul>
but if you uptick it, feel free to just comment out my -scripted patches, and I am standby to uptick them as well, right away
<wpwrak>
right, 2448. funny. all my notes say 2358. never trust documentation ;-)
<wolfspraul>
well but why do you get the context problem?
<wolfspraul>
you are actually using 2358? but all this time you thought it was 2448?
<kristianpaul>
wpwrak: i just sent a mail to qi (cc: carlos camargo) exmplaining my situation
<wpwrak>
no, i'm using 2448 but the places where i have written down the number (e.g., docs/GETTING-STARTED in gta02-core) say it's 2358
<wolfspraul>
but why do you get the context problem then?
<kristianpaul>
wpwrak: (IRQ) well not free, but i still asking my self why the pin in sharef with LCD, or is just a label..
<wolfspraul>
my 2 patches apply cleanly against 2448, in the quilt series as uploaded
<wpwrak>
(2448) and i lost that kicad source tree with the disk loss a few weeks ago. so i restarted from documentation ... and thus ended up with 2358 :)
<kristianpaul>
wpwrak: (well not free) > not sure if free
<wolfspraul>
as for KiCad upticking, that's a task I can definitely offer to work on, if you want to get rid of it and suspect that some improvements might be worth the work.
<wolfspraul>
I am slowly getting more and more familiar with KiCad, so I can already 'test' a newer version to a certain degree.
<wolfspraul>
it's up to you...
<wolfspraul>
of course I may uptick it to xxxx, and then you find some major problem with xxxx that I just wasn't aware of
<wpwrak>
need to check what the latest version offers. there are a few bugs in 2448 that i wouldn't mind seeing gone.
<wolfspraul>
like I said, I offer to work on this, if that helps you
<wolfspraul>
either you explain to me what the 2448 bugs are, so I can test whether they are gone, or you try yourself. you need to decide what costs you less time...
<wolfspraul>
if we move kicad-patches to eda-tools, I can commit right there and it should be quite efficient for me
<wpwrak>
thanks ! it's mainly a question of running the new stuff on a design you know well and see if anything appears unusual
<wolfspraul>
sure
<wolfspraul>
that's why I think I am only 20% ready for the job now, slowly increasing
<wolfspraul>
maybe by the time we manufacture Xue I'm at 75%? :-)
<wpwrak>
(2442 bugs) they're things that happen occasionally. like kicad running into an internal error if you resize areas. or "create a corner" only being available sometimes.
<wolfspraul>
2448
<wpwrak>
err yes, 2448
<wpwrak>
2448 patched cleanly. building ...
<kristianpaul>
MauroRojas: hola
<MauroRojas>
Hola!
<wpwrak>
MauroRojas: welcome back among the living ! ;-)
<MauroRojas>
thanks :-)
<wpwrak>
nice ... pcbnew --help  ... now it looks like a real program :)
<wpwrak>
wolfspraul: having -print-layers and --print-layers is a bit confusing. if the short option is the same at the long option, there probably shouldn't be a short option at all
<wolfspraul>
yes, eeschema doesn't have that yet, but when I go back to eeschema I'll clean it all up there, and merge your --plot patch as well.
<wolfspraul>
yes but the wx layer has its system
<wolfspraul>
I'm trying to follow KiCad as much as possible, and will do even more so then I start to cleanup
<wpwrak>
wolfspraul: also, the help for ps-pads-drill is confusing. --ps-pads-drill-ops is clear, but what does -ps-pads-drill do ? (supposedly the same as --ps-pads-drill-opts)
<wolfspraul>
-ps-pads-drill is a random 'short name' for the long name
<wolfspraul>
the wx... class has this concept of 'short' and 'long'
<wolfspraul>
I can try to see what happens if I leave the short string empty
<wolfspraul>
maybe it will only display the long one then, that would be better, I agree
<wolfspraul>
these are pecularities of the wxCmdLineParser class I haven't gotten around to yet
<wolfspraul>
wx is support to work well on Mac and Windows too
<wolfspraul>
so they also have this concept that the separator can be != '-'
<wolfspraul>
like / on Windows
<wpwrak>
hmm yes, i see. i think the idea for a "short name" is for it to be just a letter
<wolfspraul>
I have two options in all this. I can try to follow the KiCad classes, design, etc.
<wolfspraul>
and that will produce some 'quirks' when you look at it from a pure Linux/Unix perspective
<wolfspraul>
or I can just do it all Linux-style, but then bringing it to Mac or Windows would be a lot of work
<wolfspraul>
(and most likely never happen)
<wolfspraul>
yes that's the idea, 'just a letter'
<wolfspraul>
something short
<wolfspraul>
I can try to see whether the class accepts an empty/missing short name, haven't tried that yet
<wpwrak>
that would also work on unix
<wpwrak>
i think if you can just change the "short" names - that are actually quite long - to single letters, that would be sufficient
<wolfspraul>
don't you think that's even more confusing?
<wolfspraul>
sure we can do that...
<wpwrak>
the usefulness of a ton of cryptic one-letter abbreviations is somewhat questionable, but at least they wouldn't get in the way
<wolfspraul>
maybe let's see how the parameters evolve first
<wolfspraul>
I suggest to completely ignore the short names right now
<wolfspraul>
let's focus on making the long ones better
<wolfspraul>
I will check whether the class allows disabling of the short ones.
<wpwrak>
yep, if there's a choice for not having short names at all, i think that would be better. we're not exactly optimizing keystrokes here anyway ;-)
<wpwrak>
wolfspraul: since we discussed consistency ... a netlist generation option in eeschema would also be nice
<wpwrak>
wolfspraul: it would also let one run the full build process from files in the repository to the fabrication data
<wolfspraul>
yes definitely, will add netlist to eeschema
<wolfspraul>
together with erc
<wolfspraul>
and merging the current --plot and --bom patches into something cleaner
<wolfspraul>
wpwrak: did you run some of the pcbnew cmdline stuff successfully?
<wolfspraul>
without crash - did it produce usable files?
<wpwrak>
wolfspraul: drill file so far. worked flawlessly
<wolfspraul>
nice!
<wolfspraul>
that makes for a happy flight to Berlin now, thanks for letting me know :-)
<wolfspraul>
so you gave your green-light already for moving the patches to eda-tools, and doing more work on the eeschema side (including merging your --plot patch)
<wolfspraul>
I will try to do this soon, to get over the whole KiCad thing, maybe the next week or so
<wpwrak>
(happy flight) ;-))
<wolfspraul>
first need to get 27c3 behind me, not sure how much spare time I have there
<wolfspraul>
so maybe I'll finish the kicad cmdline stuff when I'm back from there
<wolfspraul>
what I need from you is feedback on whether the current cmdline options work, and whether you need more, or whether you have some ideas for re-layout of the parameters
<wolfspraul>
those kind of things
<wpwrak>
(patches and eda-tools) in fact, i have them sit there already. they're just a git add, commit, and push away :)
<wolfspraul>
but we can do that slowly as we realize more clearly what we need...
<wolfspraul>
he, nice
<wpwrak>
(option names) maybe change --print-layers to --list-layers, considering that we;re in the midst of plotting and printing here
<wolfspraul>
sure
<wpwrak>
also, the help text for -l should say what that list is for :)
<wolfspraul>
I think the options will evolve over time
<wolfspraul>
don't know :-)
<wolfspraul>
it lists the 'enabled' layers
<wolfspraul>
I think it's the same as those that are checked by default in the dialogs
<wpwrak>
let's try somthing harder now ... the postscripts
<wolfspraul>
unless you overwrite those defauls somehow (KiCad seems to save options and option overrides in several places)
<wolfspraul>
I try to make the cmdline options as deterministic as possible
<wolfspraul>
they should not be influenced by anything but the .sch and .brd files
<wpwrak>
the whole options systems is borderline incomprehensible :-(
<wpwrak>
(the one of kicad i mean)
<wolfspraul>
but it is quite possible that they still are influenced by stuff saved locally in KiCad somewhere
<wolfspraul>
if so, that's a bug
<wolfspraul>
I tried to write the codepath in such a way to bypass those 'local' options and option overrides
<wolfspraul>
but we need to see over time, I expect some surprises...
<wolfspraul>
so this --list-layers lists the 'enabled' layers, whatever that is exactly
<wolfspraul>
I hope it's a deterministic on/off switch in the .brd file.
<wolfspraul>
also you may need those strings if you want to specify layers for the svg or plot options
<wpwrak>
maybe it's the ones you select in  pcbnew: Design Rules > Layers Setup ?
<wolfspraul>
yes
<wolfspraul>
and those are the same strings used in the comma separated lists
<wolfspraul>
in --layers=a,b,c
<wpwrak>
aha. the area fill problem hits
<wpwrak>
interestingly, --drc doesn't affect it. --drc also seems unusually fast.
<wpwrak>
the report look good, though. strange.
<wpwrak>
maybe you run just the report generator without recalculating the checks ?
<wpwrak>
run time: 5 s for manual DRC (time during which the dialog is "running", so without pcbnew startup an such). 0.6 s for --drc and --plot
<wolfspraul>
which --plot are you running ?
<wolfspraul>
which .brd file?
<wpwrak>
runing pcbnew, filling the zones, and saving it with the zones filled solves the problem of them not getting plotted. it's a nasty trap, though. (could be something that's fixed in a more recent version, though. it's something that can bite you also without --plot)
<wpwrak>
--plot=ps_a4
<wpwrak>
atusb.brd
<wpwrak>
pcbnew  --plot=ps_a4 -l Front -mirror --ps-pads-drill-opt=real atusb.brd
<wolfspraul>
and you like to mix short and long options, probably to torture me :-)
<wolfspraul>
the short ones are really horrible...
<wolfspraul>
so this plot when run on the cmdline produces a different result from running in the plot dialog?
<wolfspraul>
when you say "running pcbnew, filling the zones, and saving it with the zones filled solves..." what do you mean exactly in KiCad?
<wolfspraul>
what are the steps...
<wpwrak>
hates brown-outs
<kristianpaul>
UPS?
<wpwrak>
i had one - just made the brown-outs worse
<wpwrak>
and another one :-(
<wolfspraul>
wpwrak: I found a bug wrt default line thickness, uploaded a new pcbnew-scripted.patch
<wolfspraul>
I was able to reproduce that with the atusb.brd and options you gave me
<wolfspraul>
so that's good, that's definitely an improvement
<wolfspraul>
I also renamed --print-layers to --list-layers
<kristianpaul>
argg you french is hard to catch ;-)
<kristianpaul>
oh well seems LCD have free pins after all, just was a bit tricy as they keep labeled as LCD and the new functions too.
<kristianpaul>
andres-calderon: the only thing i see sram example is missing is a busrt mode for data transfer from FPGA to Xbusrt ;-)
<kristianpaul>
Is some kind of frustating at first then funny see a fpga as ram :-)
<andres-calderon>
kristianpaul: its just a starting point. There must be room for a lot of optimizations (timing, burst?, dma?..  I do not know ).
<kristianpaul>
dma??
<kristianpaul>
really...
<kristianpaul>
timing still tricky but even if it get optimized (cpu cylces, etc..) i think is mainally oriented to be efficient both with buffer like setup or with not hihg demanding IO transfer setup :-)
<kristianpaul>
andres-calderon: i was checking dma for jz4725 also wpwrak , but seems there is no documentation or feature avaliable for EMC
<kristianpaul>
so far i just realized DMA capabillties with the nanonote and the mmc controller
<andres-calderon>
Some really nice SoC support external DMA.
<kristianpaul>
any hint from your side is very wellcome, o just met SIE when ti was renamed to that name... surelly you had lots of tetchnical discuss with carlos camargo about this topic i guess
<kristianpaul>
andres-calderon: is that really nice SoC the Xbusrt JZ4725? :-)
<kristianpaul>
as i said any help with dma in SIE is apreciate :-)
<andres-calderon>
kristianpaul: nice price
<kristianpaul>
hmm'
<kristianpaul>
?
<kristianpaul>
ah i you meant Xbust chips are cheap, i totally agree :-)
<wpwrak>
(dma) the xburst don't seem to have it :-( the only one where i found a mention in the documentation is the 4720, and there, it's an empty chapter.
<kristianpaul>
btw are you p:anning get a M1? i already order one will be nice have more people in Colombia working around this nice and free SoCÂ Â :-D
<wpwrak>
(dma) there are also no pins marked for DMA request/ack and such. nor are there register values that suggest they could be used for selecting external dma.
<kristianpaul>
(argg tomorrow interesting talks at 27c3Â Â are too early..)
<kristianpaul>
wpwrak: (dma and 4720) hopefully that should be asociated with mmc..
<kristianpaul>
looks easy to use chip :-)
<andres-calderon>
kristianpaul: very easy, i like it
<wpwrak>
andres-calderon: i think low design risk trumps low cost for now :)
<andres-calderon>
wpwrak: i agree
<kristianpaul>
wolfspraul: hi, how looked the M1 case?? (blue one)
<webpower>
hi all
<kristianpaul>
hi wolfspraul
<kristianpaul>
hi webpower
<webpower>
i want to know the differences between LGA 1156 and LGA 1366
<webpower>
socket
<wpwrak>
the chip looks friendly.
<wolfspraul>
he
<wolfspraul>
just arrived in Berlin after an adventurous flight and landing, then Sebastien said he was too tired and now I'm at his place going to crash...
<wpwrak>
wolfspraul: (line width) excellent ! i ran into this, too. you fixed it before i could mention it :)
<kristianpaul>
ok
<wolfspraul>
but the great thing I saw during the 10 minutes I was at 27c3 was the m1 happily crunching away in the lounge, entertaining people
<wpwrak>
wolfspraul: (flight) what happened ?
<wolfspraul>
very nice
<wolfspraul>
if it can handle that for 4 days I feel much better about the quality of the whole thing...
<wolfspraul>
[flight] delays delays delays
<wolfspraul>
nothing to complain though, lots of snow, runway had to be cleaned, we circled in the air longer than the actual flight, etc.
<wpwrak>
wolfspraul: hah, you should try domestic air travel in argentina ;-)
<kristianpaul>
snow snow snow everywhere :-)
<wolfspraul>
anyway, arrived. m1 doing a great show in the lounge.
<wolfspraul>
wpwrak: hmm, OK. so the line width was not the only thing.
<wpwrak>
(m1) great !
<wolfspraul>
you still have the fill zone problem?
<wolfspraul>
I cannot reproduce it, or rather you didn't give me reproduction steps I would understand.
<wpwrak>
wolfspraul: (fill problem) pcbnew: select "Add zones" mode. right-click on a zone. select "Remove Filled Areas in All Zones"
<wpwrak>
(if that item doesn't appear, try again and again)
<wpwrak>
now the filled zones should go from solid to outlines with thin lines
<wpwrak>
then save the board. then exit pcbnew and plot the board. the postscript won't have filled zones.
<wolfspraul>
hmm. when I click on 'remove filled areas in all zones' - I don't see any visible change. I'm in atusb.brd
<wolfspraul>
or I can only see the difference in the .ps ?
<wpwrak>
maybe it's already unfilled
<wpwrak>
if you're using exactly the version in git, without running a DRC or such, then it will be unfilled
<wolfspraul>
ah yes. when I say 'fill' then it will all become green and yellow etc.
<wpwrak>
yup, that's it
<wolfspraul>
ok, so when this gets plotted, in the cmdline version of the plot it doesn't come out right?
<wolfspraul>
in the cmdline version, which one does not come out right - filled or unfilled?
<wpwrak>
the plot won't have the zones. (neither would it if you plotted manually from pcbnew)
<wpwrak>
the problem for non-interactive plots is that this problem makes them quite unpredictable. in manual use, you at least have a chance to spot the problem. not that this is a very happy situation either - i've thrown away some stuff where i didn't notice it in time.
<wolfspraul>
what is the problem?
<wolfspraul>
the plot will never have the filled zones, whether they are filled visually in pcbnew or not?
<wolfspraul>
but you want them to be filled in the .ps plot, when they are filled visually?
<wolfspraul>
or you say the current --plot works fine, it will fill or unfill the zones depending on the settings in the file, but you cannot tell from outside which one it was?
<wpwrak>
yes, you can't tell
<wolfspraul>
in that case, what do you prefer? do you think we should introduce a way to query the fill status from the command line? Or should we automatically do the fill/unfill operation depending on cmdline setting?
<wpwrak>
i don't think you'd ever want a plot with the zones not filled
<wolfspraul>
ok
<wolfspraul>
in the current version, if it's filled in the saved .brd file, it will also be filled in the .ps plot?
<wpwrak>
i think always filling or at least the option of commanding a fill would be highly desirable
<wpwrak>
yes
<wolfspraul>
(when invoked from the cmdline)
<wolfspraul>
ah OK
<wolfspraul>
so the only problem is that you don't know from the outside
<wolfspraul>
is the fill/unfill operation always 'safe'?
<wpwrak>
so your stuff works. it's just a pcbnew usability issue that gets worse if you don't have visual feedback
<wolfspraul>
or would you want to manually check the results?
<wolfspraul>
or is it possible that you would want to fill some zones, and leave others unfilled?
<wpwrak>
it should always be safe, assuming your design has passed DRC
<wpwrak>
of course, if you choose to produce something you haven't checked, well ... ;-)
<wolfspraul>
the fill/unfill setting is always for the whole board? or can it be partially filled/unfilled?
<wpwrak>
you can also partially fill/unfill. not sure when you'd want to do that. some of this may just be optimizations for faster interactive use.
<wolfspraul>
hmm
<wpwrak>
i can't quite imagine that you'd want a partially filled board
<wolfspraul>
so maybe we do this: we leave the current cmdline behavior as it (i.e. we leave the saved .brd settings untouched), and in addition we introduce a new parameter --fill-all-zones
<wolfspraul>
that will override whatever is in the file
<wpwrak>
also considering that DRC will fill everything anyway
<wpwrak>
sounds good to me
<wolfspraul>
drc will fill it?
<wolfspraul>
but if you run --drc from the cmdline, nothing gets saved
<wolfspraul>
ok I think it's clear. I will add a --fill-all-zones option
<wpwrak>
(--drc) yes, don't know why not. it seems that you're not running the entire DRC process
<wolfspraul>
no
<wolfspraul>
I don't save on purpose.
<wolfspraul>
I wouldn't know why printing a drc report should modify the source. that looks very wrong to me.
<wpwrak>
(--drc) e.g., a pcbnew --plot takes about 0.5 s, --drc and --plot takes about 0.6 s. when i do a DRC interactively, it takes about 5 s. so unless you did some very clever optimization, something is missing :)
<wolfspraul>
wait, one by one
<wolfspraul>
I know it's fast, but I do think it checks everything. The GUI is only marginally slower on my notebook.
<wolfspraul>
complaining about 'too high speed' is not a good bug report :-)
<wolfspraul>
so unless we know what's wrong with --drc, I assume it's all fine
<wpwrak>
on my pc, the difference is quite large :)
<wolfspraul>
if you want me to save back the fill-zone side-effect when running --drc, I can add that
<wolfspraul>
I would think that's really ugly.
<wpwrak>
when i put --plot and --drc, which gets done first ? does it depend on the order in the command line ?
<wolfspraul>
also it would cause issues with my plans to run some of those reports on the server, at least I would definitely not automatically commit some of those changes back.
<wpwrak>
(save back) you mean to in-core state ? or to the file ?
<wolfspraul>
ah good point.
<wpwrak>
i don't think you really have a choice about in-core state :)
<wolfspraul>
that's not really thought through. it depends on the order I check the cmdline options in the sources.
<wolfspraul>
maybe we should only support one 'major' command per pcbnew process?
<wpwrak>
when DRC does its filling, then it will mess with in-core state
<wolfspraul>
yes
<wolfspraul>
but we can only accept 1 major command, then exit the process
<wpwrak>
you could. or just put the one(s?) with side-effects first
<wpwrak>
or something :)
<wolfspraul>
no I think I will only support the first major command.
<wolfspraul>
so if you do --plot --drc, it will only plot
<wpwrak>
warn if there are more ?
<wolfspraul>
if you do --drc --plot, it will only run the drc report
<wolfspraul>
yes I can warn, although the wx cmdline parsing class forces me into certain expected behavior
<wolfspraul>
once we move away from that, the code gets ugly (but no problem)
<wolfspraul>
ok, so that's settled too? only 1 major command per process...
<wolfspraul>
1) --fill-all-zones
<wolfspraul>
2) only process first major command, warn if there are more
<wpwrak>
sounds fine
<wpwrak>
a warning would be useful because it may not be obvious for the user what constitutes a "major command". and then you get silent failure.
<wpwrak>
i also expected that wx may not be overly helpful here. that's why i suggested to just make the order deterministic but accept any set of commands. as long as all commands get processed, there's no error to report or warn about ;-)
<wolfspraul>
I rather operate more narrowly. one command per process is enough, then it's cleanup time :-)
<wolfspraul>
yes the wx --help thing is quite limited, they work from a structure and I need to fill my stuff in there.
<wolfspraul>
warning is good
<wolfspraul>
I don't think it's a good idea to run multiple totally different files in one shot anyway.
<wolfspraul>
and it introduces potentially very hard to track down error cases. not worth it! Need to focus...
<wpwrak>
heh, whatever works :) for my Makefiles, one file at a time is nice enough
<wpwrak>
ah nice. today, we had a "subjective" temperature > 40 C
<wolfspraul>
zrafa: you lost some files on the openmoko projects server?
<zrafa>
wolfspraul: yes, the web page of the fatfinger shell. ANd the web page had a copy of the sources as well IIRC
<zrafa>
andres-calderon: I think that the gamepad link I pasted just press keys on qwerty
<zrafa>
andres-calderon: it is not connected to any IO
<andres-calderon>
andres-calderon: wow... so trivial :)
<zrafa>
kristianpaul: kyak: did you see the doxbox for dingoo?.. it seems me that those guys are running dosbox (I tested their binary on nn and it works) like if the screen would have 640x480. It would be interesting to check how them are running an application which uses 640x480 on a 320x240. Of course, surely they are doing some scaling.. but it would be nice to know how, so we can run any 640x480 application on our screens. A new world would appear on our fro
<zrafa>
I have no much free time, that is why I just point the idea :)
<qi-bot>
[commit] Werner Almesberger: atusb/Makefile: targets "front" and "back" to print layers for toner transfer http://qi-hw.com/p/ben-wpan/fe60705
<qi-bot>
[commit] Werner Almesberger: atusb/cam2/: streamlined CAM data processing, added generation of prerequisites http://qi-hw.com/p/ben-wpan/a0b064b