kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/06/2010 01:41 AM, Lorenzo Marcantonio wrote:
> On Thu, 5 Aug 2010, Dick Hollenbeck wrote:
>
>   
>> Good question!  We were told recently that there are a number of
>> projects "out there" that might come under an umbrella of contrib.  I
>> wonder if we opened that gate how many would arrive carrying their own
>> language and tool requirements?  Own programming styles, own tool-sets,
>> own user interface standards?
>>     
> No problem for a contrib... if someone wants a, dunno, matlab interface,
> of course it can impose its own devel requirement. But for a core
> component (like the BOM processor) IMO we should limit to something very
> available (and I think python *is* very available, but without some
> strange UI component).
>
>   
>> *** I think we share the same concern, if we open the gates.  I don't
>> want to even look at C code written by somebody that thinks the linux
>> kernel source looks good, complete with tabs.  I would not want to have
>> my grep tools even go down in there while searching for a function name.
>>     
> I find kernel sources actually very readable... and cscope grep them
> pretty well too :D OTOH my main business is programming MCU and DSP so
> it's mostly a (little) C and assembler affair.
>   
>> Had we had a tool/utility language standard in place, then perhaps
>> things like Oyvind's part library would have been done in that up front,
>> rather than in perl.  The speculation is that with an published open
>> door policy, then folks could work in a particular scripting language
>> under the advance understanding that the tool has a place to live later,
>> and not die on the vine.
>>     
> I could never script in python (well, I *could* but I absolutely hate
> the indentation stuff without braces to % in vi). My part libraries are
> built with zsh script, anyway... but, we're talking about contribs.
> I someone wish to use it, it need to install the relevant requirements.
>
> But for the core parts I'd stick to a restricted set of tools. I would
> hope for something like POSIX but for UIs :D
>
>   
>> made, if only because of the platform independence of the JVM and all
>> the languages that run on top of it.
>>
>> Frankly, I cannot see why cvpcb could not be written entirely in PyQt4,
>> and be a central ram resident real-time interface between eeschema and
>>     
> I my world cvpcb simply wouldn't exist and only be a dialog box in
> eeschema (right click on the part, choose package). It's the only
> fricking thing it does!
>
>   
>> pcbnew, like we talked about for D-BUS.  Also, I am not sure why a
>> person needs both kicad AND cvpcb programs.  Seems that one could do the
>>     
> I think it is something like an 'industry standard', both orcad and
> eagle have a 'launcher/project manager'. Also it somewhat sets the
> environment so that eeschema/pcbnew can pick the right files (at least
> I think... if I do an eeschema file.sch it never find the libraries...)
>   

Good points, all of them. 

Some projects are adverse to using higher level languages.  Python is
not hard to learn.  Generally I have always been willing to move up to a
higher level language where I can.  The first language I learned was Z80
machine code.  Yes, hex machine code, not even assembler.  Z80 assembler
came next, then C, then C++, then Java, then python, then groovy. 
Curious about scala now.  Later I came to refer to the lower level
languages as "programming on your hands and knees".  Each has their
place, but this is determined by the platform.  The fact that the linux
kernel is written in C, is a perfect language choice.  It should be in
C.  But when you move up into the application space, and have enough
disk space, and infrastructure, and still write in C, you are now
"programming on your hands and knees" IMO.

I'm not sure we fully understand the big python program in the middle,
because I'm not sure I understand it yet either.  (You made a reference
to the project manager as if you had thought I was removing this
functionality.)

Basically the big python program in the middle, call it a server with a
rich graphical UI, would manage the large data structures in RAM, i.e.
BOARDs and SCHEMATICS both, in something like an XML document tree.  It
would have a UI to launch eeschema and pcbnew from there just like a
project manager.  The difference is that these child processes would run
asynchronously, would be clients to the python server, and would get
their stuff as a client from the python server, rather than from a file
system.  This way the clients are compelled to write their edits back to
big daddy, who can do back annotation, realtime updates between multiple
client programs, etc.  There would be a "DBUS like" API between
processes, and actual real DBUS could be used if it made sense. 
Something like XPATH could be used within the client/server API to
"navigate" the various datatrees within the server. So for example an
API function might take a BOARD handle, but if you want access to a
specific track, you'd have to additionally provide a "navigational
ticket", like an XPATH expression to identify the track you want,
RELATIVE to the BOARD handle.  You could also get a handle to a more
localized scope, rather than coming in with the BOARD handle.  Model the
navigational ticket design on XPATH.  The clients might need to cache
(or API facade) some of the structures for crispness of things like
dragging a track, and then return the moved track back to the server
when done.  Resynchronization points could be many or few, probably
fewer to keep the speed up at the client.  Giving more than one copy of
PCBNEW access to the same BOARD would entail the usage of tree segment
locking.

DBUS uses a separate daemon process to act like a post office.  Under
windows DBUS is not prevalent.  It may be that the server program could
use some of the python-dbus language binding technology to build the
marshalling packets, but then actually become the dbus post office
itself.  This would mean no dbus installation requirement on windows.

XPATH might fit especially well if you loaded a BOARD into an XML
document tree within the python server.  These are concepts/foundations
for something that might take man-years to do, but in python who knows? 
A bright younger person with lots of free time might nail it in short
order.  Sometimes the architectural concept or vision is the missing
part, and here is one.

Might be some commercial competitors out there reading this also.  (We
have to be on the radar at this point.)  I write software like this for
a living.  Designing boards is a side show for me.  So I don't lead any
charge on library parts, you don't want me leading that parade.


Dick