Mail Archives: geda-user/2016/07/23/10:18:57
On Sat, Jul 23, 2016 at 11:54:46AM +0200, gedau AT igor2 DOT repo DOT hu wrote:
>
>
> On Sat, 23 Jul 2016, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
>
> >If the alternative you are trying to offer is C, you're off the
> >point. It is already in, and it adds nothing. See, my recently
> >done contributions are mostly done in Scheme. While the code there
> >is not touching the C code we have, it does some attractive work
> >(I hope).
>
> Nope.
>
> The alternative I try to offer is a core implementation in plain C _and_
> user extensibility through multiple scripting languages. My offer is that
> the core is compilable and executable on a wide range of systems without
> largish dependencies that are often hassle to get to work. My offer is that
> the end user doesn't need to learn scheme or awk or python to create a new
> menu if he already happens to know one of the ~10 languages gpmi supports.
Hey, nobody objects if you would implement a function you need in
C or ask to include gpmi because you know its functionality is
already done in some other language.
OTOH, ha-ha (sorry), I know that some functions that are available
in various LISPs for decades (fifty years?) people now start to
implement in the modern versions of such old languages as C or C++
(I've read of that but I'm not sure which of them had been
mentioned). Those functions are 'map' and 'fold', IIRC.
>
> >
> >If you're writing about Python or some other interpreted language,
> >I should say that I feel it is non-pragmatic to `rewrite it all'
> >as some people offer. I see there is not enough contributions for
> >every language people are suggesting for our project. Basically,
> >we have one Scheme contributor (me), one Python contributor
> >(Roland) and one C glib/gtk contributor (Edward), though I'm
> >trying to work on the glib/C part too. Peter Brett and Peter
>
> A major point in my reasoning that is being missed here: I strongly believe
> in separating core functionality and user scripting.
Agreed.
However, do you know what the abbreviation GUILE means?
> Core is written in the language the most active contributors/main developers
> chose. To the end user this language matters very little. To potential
> contributors it does matter a lot, tho: languages more widespread and more
> popular pose less burden to new joiners.
Agreed, and now the main language for geda-gaf is C (yet ;)).
>
> Users should be able to chose from a wider set of languages. If they can do
> so, it's more likely they start scripting to solve their problems which in
> turn may result in more user contribution. On that side, there should be no
> preferred language or arbitrary limitations.
We already have many languages in our code base. However it only
leads to dead pieces of code that nobody want to support.
I see your point and gaf already supports the 'system' calls and
several other functions which may be (and are) used to call other
language programs.
> >Clifton, who both did an immence amount of work before, are now
> >busy with other things, so they cannot help much. Anyway, I don't
> >want to discourage Roland or Edward. Therefore I do most of my
> >work in Scheme trying to not touch the C code they rely on. Now, I
> >like Scheme very much, though I can say, if it all is written in
> >Python, I would continue to work on it (I believe).
>
> It is reasonable to chose language according to the _current_ situation, the
> current number of contributors and langauge spectrum if you want to conserve
> the current state.
I don't want to conserve the current state.
> I do not want to. Thus in cschem I take another direction.
I have only two demands to the software I use:
1) If I use it, it should do the work I need.
2) If I program it, it should make me fun.
Otherwise it is not worth of it.
> This does not do anything bad to gschem or geda. If I didn't consider
> working on cschem, I sure wouldn't be contributing to gschem, so nothing is
> lost.
This is your right.
>
> >>
> >>I believe having alternatives does not subtract but add. Don't assume that
> >>the time some of those "my way" guys would have been spent on "your way"
> >>automatically if the given person didn't invest it in an alternative.
> >>
> >>Instead, there are very high chances that that time would have been spent on
> >>some other project. In which case that time is totally lost from geda point
> >>of view.
> >>
> >>Thus bashing people for not following your way does not do any good. This
> >>sort of behaviour contributes in getting poor more than forks or
> >>alternatives. I know relaizing that "their way for them is as true as your
> >>way for you" is hard, but you could maybe try.
> >
> >This all is why I'm tolerating xorn in geda-gaf, and probably our
>
> Sorry, but "tolerance" is not the word that pops in mind reading your
> mailing list activity. It's more like "try to use any opportinuty to
> advertise how xorn is a bad idea, and maybe try to convince users to turn it
> off". Just my impression.
Sorry, if it sounds so. I just have no time to support side
projects like xorn or your cschem. Even if some things in them are
valuable enough. I'm not Peter the Great and even not Vladimir
Putin ;-)
>
> >pcb developers are tolerating your ads while you seem to break our
> >(not so large) community. I see your and Roland's great work, but
> >the attitude you have chosen is not consolidating. BTW, there is
>
> And this is where we totally disagree. What I am doing with pcb-rnd is not
> breaking the community. Have you been following pcb mainline recently? It's
> not like there's a prospecting, fast paced development there and I'm
> trolling users to accidentally download my software instead of
> mainline.
While you're thinking so, I see the pcb community is waiting and
the people are wanting to know what will happen and where to
contribute. In order to support pcb you should to head its
development. I am sure, all other developers (including me) will
support you. It however requires you to make some work on yourself
(stop hating and start learning git and probably something
else ;-)).
>
> Your point of view is that alternatives are bad, and you have the key, you
> know the One True Way. I totally see how xorn or pcb-rnd is bad in that
> model of the world. Others models differ, and it's a very common model to
> provide alternatives and let users decide what to use. I am happy to see pcb
> devs tolerate this.
No, I have five children, and I cannot say there is One True Way
:-).
My point of view is that collaboration is good.
>
> About my "ads": from my point of view, you are doing the same with scheme,
> advertising scripts and addons to keep the thing alive, to maybe convince
> some user that scheme is what they should love after all, via posting
> scripts. Others post their success stories about how they used some
> misfeature of gschem in their $$$ projects. And the community tolerates all
> this. And it's all fine: the users can chose at the end.
I don't understand, what's wrong with this? Should I shut up about
gschem extensions I write and use?
>
> >another side of the coin. Xorn still fails in various places and
> >on different machines for me (at home or at work), and I have no
> >time to work on it, so I wouldn't release it as is now. OTOH, it
> >prevents me to release the new version of the whole geda-gaf
> >because it needs much more work than if it wouldn't be in. I tried
>
> Like if guile was not failing for different users. Like if guile was not one
> of the reasons gschem didn't have a working windows port for a long time
> (correct me if I am wrong).
You know (I hope), that I'm that man who has built gschem 1.9.2
for Windows, and while some people are whining (and I consider
this to be very well, because otherwise we would have to admit our
project is dead), I have to state that I had not any support and
any feedback while doing this. Only Peter Brett has made some work
afterwards. Now, what are you trying to learn? If our users help us?
> Honestly, I am not a python fan either, but as an user, I would go for
> python+xorn instead of scheme any time. The size of the python ecosystem is
> probably comparable with guile's, but I see much less problems with getting
> python working on random systems. It well may be that python would be the
> next guile in a 10 or 15 years time scale (e.g. in popularity). Maybe it'd
Yes, there is no problem. I considered guile the same way when I
first tried to work with it and to read its documentation. Now,
after reading first bits of SICP, and after working in Emacs
Geiser I feel it very good for me. Yes, it is a program an it has
bugs. I've already mentioned bugs (here or somewhere else) which
users can have if they would use such things as
e.g. libpango. Yes, you could rewrite the library, but how many
time and forces it would require?
> be C. We don't know. What we know is that guile is not easier to set up than
> python today.
And other way around ;-)
--
Vladimir
- Raw text -