kicad-developers team mailing list archive

[Edwin van den Oetelaar <oetelaar.automatisering@xxxxxxxxx>]

Hello Dick,

I would hate to see you leave the project, you are the top contributor.
Thanks,
Edwin van den Oetelaar



On Mon, Apr 21, 2014 at 7:30 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> 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.
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>