kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/21/2014 12:16 PM, Lorenzo Marcantonio wrote:
> On Mon, Apr 21, 2014 at 11:26:53AM -0500, Dick Hollenbeck wrote:
>> 1) I can decide where I expect to find the KIFACEs, your strategy relies on the OS to tell
>> the loader.  This is a user PITA issue, and reliability of the install.
> 
> In the same way it finds the wx libraries, in /usr/lib[64] or whatever.
> 
>> 2) I can set the LD_ENV_VAR environment variable programmitically in my program which
>> tells where the libs that the KIFACEs need are.  People do not know how to do this on
>> their own.
> 
> LD_LIBRARY_PATH, the same
> 
>> 3) Your way, the program won't load at all if ALL the DSOs are not found immediately.  And
>> all dependencies they may have.
> 
> Same for the wx modules if not monolithic. Also AFAIK there is no plan
> of a 'partial' kicad installation. If you want to do 'eeschema without
> pcb', then your approach would be the only one working.
> 
>> 4) It will load slower, and load some KIFACEs not of interest to someone just wanting to
>> work in schematic.
> 
> Partially true, but it only needs to relocate, since executable paging
> is on demand, but many people prelink these days. Also the UNO model in
> openoffice actually slowed it down a lot, when it was introduced (but
> maybe loading was not the issue there).
> 
>> 5) You will have possible name collisions in the link process of the top *.exe.
> 
> *This* would be a good thing, since these collision would happen at
> runtime (probably undetected). Had many crashes from dynamically loading
> a library using a different libjpeg version:P The global issue we talked
> about before. In fact this is my primary reason for preferring a link instead
> of a load. One process core => one symbol namespace
> 
>> 6) It is not as flexible moving forward, the above arguments only get more pronounced as
>> should you add additional KIFACEs.
> 
> *If* you want to cater to 'arbitrary' interfaces (like the mozilla
> plugin loader) then I agree your design is better. For the current and
> near future I don't see an improvement.
> 
>> So no, I do not agree, again.   File a bug report if you have problems.
>>
>> Or take it up with the core development team, which is now lead by Wayne.
>>
>> They have conversations among themselves, and have chosen people in that group in part by
>> how easy they are to work with.  I noticed you are not in the group.
> 
> I'm just discussing the design, not forcing opinion on how to do things.



> It's called 'reviewing' and 'suggesting'. If the core team don't want to
> discuss the best way to do thing too bad for them. I'd have preferred
> keeping different processes with a better IPC (M0Q, corba, soap, xmlrpc,
> dcerpc, whatever) but I agree that the portability issues were serious
> in that case.
> 
> Potential problems I have on mind about the current implementation:
> 
> - One 'window' crashes, everything go down, obviously :P of course
>   crashing is undesired anyway, so it's not an issue :D (even windows
>   explorer has the 'open window in another process' for that, but see
>   below for the reason)
> 
> - SIGINT (or xkill) to eeschema pull down the associated pcbnew (or
>   viceversa if pcbnew gets an open schematic button), if I got this
>   correctly... this is not very nice (I agree it's a minor issue).  In
>   fact I *never* use the open pcb button in eeschema or the kicad
>   project manager because wx messes up the process group management
>   creating a similar issue.
> 
>   Sadly many modern programs don't follow the 'one toplevel window for
>   process' guideline, too bad. I'd actually have split the
>   module/library viewers/editors in different processes... but then
>   process creation in Windows is a *very* heavy operation, while a fork
>   itself is lighter than opening a file. So a compromise is needed.
> 
> - What if I open the schematic in one instance and the board in another
>   one? Do I lose cross probing? 
> 
> - Somewhat related to the above: what if I have two different boards
>   implemented for the same schematic? We do this regularly for the same
>   circuit for different clients... so i use circuit.sch,
>   circuit-c1.kicad_brd and circuit-c2.kicad_brd; if the 'open board' can't be
>   customized in some way (instead of always opening circuit.kicad_brd)
>   it would be difficult to handle. Possible workaround: a file open from
>   the pcbnew windows would keep the connection?


I have $10,000 of my time into the design.  The only thing I want to hear at this point is
thank you.  Re-imburse me, and we'll have the conversation.


All the rest is pretty demotivating, and only that.  File a fucking bug report.


Click, delete.


This is why I am leaving the project.  A bunch of ingrates, who think software grows on
trees.  It only takes a few.  The rest are good guys.


Perfect example for the future though.