Re: [Kicad-developers] Kicad scripting progress :-)
Thanks for the feedback Wolfgang, What does the command-line argument patch do?, may be when the 2012/3/19 Wolfgang Spraul wolfg...@sharism.cc: But just like the command line argument patch that came in 2 months ago, there will be a better time to merge this all in. Quick note from the guy who wrote most of the command line patch: I saw the scripting patch and I agree with Dick that this is super important and great work! Well done scripting can probably replace the need for command line options. I will continue to maintain the command-line patches out-of-tree and uplevel 'every few months'. But scripting is definitely the better approach and I'm very happy to see it moving forward. It is in our shared interest to keep the KiCad codebase readable maintainable. Cheers, Wolfgang ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad scripting progress :-)
Sorry, somehow my pointer crashed in the Send button to early... I meant that, when the scripting is working somehow I could try to help in porting your patches to scripting. 2012/3/19 Miguel Angel Ajo Pelayo miguelan...@nbee.es: Thanks for the feedback Wolfgang, What does the command-line argument patch do?, may be when the 2012/3/19 Wolfgang Spraul wolfg...@sharism.cc: But just like the command line argument patch that came in 2 months ago, there will be a better time to merge this all in. Quick note from the guy who wrote most of the command line patch: I saw the scripting patch and I agree with Dick that this is super important and great work! Well done scripting can probably replace the need for command line options. I will continue to maintain the command-line patches out-of-tree and uplevel 'every few months'. But scripting is definitely the better approach and I'm very happy to see it moving forward. It is in our shared interest to keep the KiCad codebase readable maintainable. Cheers, Wolfgang ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] component/module search list library display TODO
On 3/18/2012 7:36 PM, lajos kamocsay wrote: Hello- I was going to add a feature to the component/module search dialog to display the library name if the element is found in multiple libraries. But then I noticed that there is a task for this in TODO.txt already. Lajos, The component/module search task is on my to do list. Like most things in KiCad, there are more things to do than people to do them. Is this an active task? Is anyone working on it already? I've have not done any work on this so it is not an active task. I did however lay the ground work by adding searching capability to the CMP_LIBRARY class. The function SearchEntryNames() is used to search for components in a library. There are two versions of this function. One does simple string comparisons and the other does regular expression comparisons. The regular expression version is untested. I am not sure if the same search code exists in the module library class. If it does, I didn't write. If this is not started yet, can I get some information on what you guys envisioned so I can take a stab at it? I was thinking about adding a filter button and filter string combobox control to the component/module list dialog along with the usual persistence mechanisms to save and load the last few filter entries. At some point this may be made completely irrelevant when the new file formats are implemented as Dick mentioned. Wayne Thanks- -lajos ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad scripting progress :-)
But if we actually read what Wolfgang said, he thinks that the command line option version of main() program will not be needed because of your work. He :-) I didn't actually look at the scripting patch sources to find out which actions work today and which not. But 'scripting' in general sounds like the better/bigger step to take to make things right, and I am sure when the scripting patches eventually get merged or pulled into KiCad, I will be able to rewrite the command line options on top of scripting. Command line options are a special case of scripting imho. Cheers, Wolfgang ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad scripting progress :-)
Dick, that's a great benefit for everybody that you spell out your thinking and plans so clearly. Thanks! If the Python scripting has an entry point and way to execute KiCad actions, then that same entry point can be used by a command line processor. If the interface between scripting and KiCad engine is not so clean, the command line processor could piggypack on top of Python. So let's hope for a clean interface, then things will be good. Wolfgang ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad scripting progress :-)
Ok, I fixed that problem on last commit, now it must compile without errors on Release mode, Thanks for reporting!! :) 2012/3/19 lajos kamocsay panka.nos...@gmail.com: Hi Miguel- This sounds pretty awesome! But for some reason I can't build it (revno 3453): ... ... [ 67%] Building CXX object pcbnew/CMakeFiles/_pcbnew.dir/scripting/pcbnewPYTHON_wrap.cxx.o /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx: In function 'PyObject* _wrap_DHEAD_VerifyListIntegrity(PyObject*, PyObject*)': /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:3985:11: error: 'class DHEAD' has no member named 'VerifyListIntegrity' /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx: In function 'PyObject* _wrap_EDA_ITEM_Show(PyObject*, PyObject*)': /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7210:29: error: 'const class EDA_ITEM' has no member named 'Show' /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx: In function 'PyObject* _wrap_EDA_ITEM_ShowDummy(PyObject*, PyObject*)': /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7243:29: error: 'const class EDA_ITEM' has no member named 'ShowDummy' (and lots more) My cmake: cmake ../../scripting -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DUSE_NEW_PCBNEW_LOAD=ON -DUSE_NEW_PCBNEW_SAVE=ON -DKICAD_STABLE_VERSION=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr I have swig 2.0.4 and python 3.2.2. Do I need anything else? Thanks- -lajos On Sun, Mar 18, 2012 at 12:19 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: Hi All, I wanted to share our progress on this, and ask a few questions. At this moment, we're already able to: 1) run scripts (python) from inside pcbnew, pcbnew.GetBoard() must return our current BOARD* in the editor. A little example: from pcbnew import * m = GetBoard().m_Modules x,y=54000,54000 i=1 while m: m.SetPosition(wxPoint(x+i*2000,y)) m.SetReference(C%d%i) i+=1 m = m.Next() 2) run pcbnew classes and objects from inside a standalone python script. #!/bin/env python from pcbnew import * pcb = LoadBoard(/tmp/my.brd) m = pcb.m_Modules x,y=54000,54000 i=1 while m: m.SetPosition(wxPoint(x+i*2000,y+i*1000)) m.SetReference(C%d%i) i+=1 m = m.Next() SaveBoard(/tmp/my.brd,pcb) Same example from commandline: For which I added some functions to easily load or save a PCB file via IO_MGR // KICAD_PLUGIN (as Dick asked, it was the best way) I added typemaps for strings-wxString, and also wrappers for wxPoint and wxRect, which let us to talk to methods depending on this types. We have wrappers for most objects (BOARD, COMPONENT, PAD, segments , tracks, text, etc... ) and lists (DLIST based), but we still miss access to std::vector and std::list objects yet. We already have something quite useful, but testing is very welcome. https://code.launchpad.net/~miguelangel-r/kicad/scripting I only tested it on Linux/x86, and will test on Linux/x64, but testing in other systems is welcome. To build the branch you should compile with: KICAD_SCRIPTING (for embedded scripting support in pcbnew) KICAD_SCRIPTING_MODULES (for module scripting support from python) USE_NEW_PCBNEW_LOAD USE_NEW_PCBNEW_SAVE The problems I facing now are: a) Some pcbnew functionalities are highly coupled with UI, so dependencies from objects to UI are in many places (making the .SO/.DLL module approach very hard), I tried to split in ui and non ui .cpp files, but I ended always with linking problems, so the currently built _pcbnew.so links all the UI items inside, it works prefectly, but most code won't be ever called. b) From a), for example, I'm not able to load a MODULE object from library, without having a PCB_BASE_FRAME object: from loadcmp.cpp: MODULE* PCB_BASE_FRAME::GetModuleLibrary( const wxString aLibraryFullFilename, const wxString aModuleName, bool aDisplayMessageError ) This could be fixed by splitting the library functionality in a different class, and then using it from those functions (and from scripting). c) same for DRC, I thought it could be very helpful to run DRC checkings (automated commandline scripts for DRC checking) , but it also was highly coupled to the UI. d) this is minor, but it's there... if you run pcbnew from the same directory _pcbnew.so is (this is normal when building), then pcbnew will load _pcbnew.so from it's local directory (this is some swig feature...), then GetBoard() won't work (return None) because it's a separeted instance from our running pcbnew..., so if you want to test
