[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: Re: Patches for PCB automake/autoconf system
How is code bloat or perceived language speed argument possible
relevant to a
software installer onto a workstation?
Surely the earlier justification of things like ease of test string
manipulation, and mainly
the authors productivity - are the significant arguments for this class
of application?
John
Gabriel Paubert wrote:
>On Thu, Oct 21, 2004 at 07:29:09AM +0000, Karel Kulhavy wrote:
>
>
>>On Thu, Oct 21, 2004 at 09:16:41AM +0200, Piotr Miarecki wrote:
>>
>>
>>>Hi Stuart and All,
>>>
>>>at first - I compromize everything if you only agree to work together on gEDA installer/setup, including Python. The only condition is that every step should carry a new functionality, not rewriting the existing code nor writing everything from scratch.
>>>
>>>Majority of gEDA tools are one-person-projects. If a developer has no time for gEDA, temporarily or permanently, the tool is not maintained. A good example was setup and gmanager during past time. If you look into setup.cfg you see that it supported pcb, gwave, gtkwave and other tools - but in old, obsoleted versions. Because during past three years I had only few time for gEDA.
>>>
>>>If you start a new installer project - this is what probably happens with your installer in the future as well. I propose that we cooperate. There are many features missing: updating support for non-gaf tools, porting to windows, creating a tool for creating setup.cfg, supporting APT/RPM(/PKG) databases, etc.
>>>
>>>Answering your questions:
>>>* setup HAS BEEN designed using glade, take a look into CVS: ~/glade/setup/setup.glade,
>>>* setup does support ALL gEDA tools (now in obsoleted versions, it needs to be updated),
>>>* setup is written in C, yes, because imo its a gaf standard, as well as guile should be used for scripting (imo it means also: not python, perl, etc.) - but this is a subject that should be separately discussed with Ales.
>>>
>>>
>>I appreciate the fact these tools are in C and not in Perl or Python.
>>C is fast and there's no danger that some new version will come in which
>>something will behave differently.
>>
>>
>
>Besides the run time bloat of Python in some cases. I'm fighting right
>now with somebody who wants me to rewrite something which works and
>occupies (after compilation) 8kbytes (code+data in the executable) with
>a Python script which just after loading the libaries (before adding a
>single line of code of my own) already takes up 6-7Mb, and he wants to
>use an XML parser on top of that (it's buzzword compliant for sure) which
>will take an additional unknown amount of RAM to run. BTW this has to run
>on a diskless machine with 16Mb of RAM...
>
>Now I happen to hate glade. I'm writing a new app in C++ (my first C++
>code so it has rough edges) and gtkmmm. It the first time I use Gtk and
>I reserve my judgement for now, although I have the impression of being
>fighting against the toolkit on each and every line of code (but I tried
>glade and it was worse, I just can't stand a single line of automatically
>generated code in my programs, and that's physical). For small projects like
>this one, I prefer Python+TkInter but in this case it can't provide the
>performance I need.
>
> Regards,
> Gabriel
>
>