Re: [Lightning] Verifying Toolchain Semantics

[Ian Grant]

On Tue, Oct 7, 2014 at 3:24 PM, Philip Herron
<address@hidden> wrote:
> I think what we want is your posts really are not 100% related to
> development of the respective development. Its flooding mailboxes.

Yes, well, mailboxes get flooded ... Haven't you got a kill list, or a
filter that says "Ian Grant's crap."

The reason it gets flooded is that people keep writing unreasonable
things about me, or about what I've written, on this list, (and
sometimes don't even send them directly to me (I am not subscribed)).
I think I have the right to respond to these things, since they appear
on a public list. If you think otherwise, then you are welcome to tell
me why. If you don't want me to reply to the list, then send me a
_private_ mail, clearly giving the reasons why you think I don't have
this right. If you send it to the list, all the better, but consider
that my reply may also go the list, and thereby be the cause of more
traffic that _others_ may not be interested in reading.

> If you want to contribute, open source is a meritocracy we don't
> really hold meetings talking about ideas. You implement something and
> it goes from there. Your probably a great guy but your posts over the
> last few months irritate my a lot because its just all open ended
> discussion stuff.

You read it all then? A lot of it is "all open ended discussion", and
that is what irritates me too. I posted 8 pages explaining why we need
to have these discussions, so that we can steer separate projects in
mutually beneficial directions. We need to discuss these possible
directions in public, and in a cooperative atmosphere of intelligent
mutual exploration of possibilities, with contributions from all the
different projects.

It's no good just individually "hacking code" and sending in patches,
because the overall direction gets lost, and people don't benefit from
working together, they end up working alone, and competing for
developer attention against other developers on the same project!!

And it's clear to me that compared to how this project worked sixteen
or so years ago, it has completely lost its direction, and it has
hardly progressed at all.  And I daresay this will provoke screams of
outrage from dozens of people that didn't even know what guile was
sixteen years ago, .... but that's "hackers" for you!

Ian

> On 7 October 2014 18:56, Ian Grant <address@hidden> wrote:
>> On Tue, Oct 7, 2014 at 1:28 PM, Mark H Weaver <address@hidden> wrote:
>>> Ian, please stop posting to guile-devel.  You've made your points, and
>>> I've even called attention to what I think is the best exposition of
>>> your ideas.  At this point you're just repeating yourself and hurling
>>> gratuitous insults.  Enough!
>>
>> Well, it's insulting when you speak to me like a child, and when you
>> make childish suggestions about my motives for posting to this list.
>> But I don't complain, and I certainly wouldn't attempt what William
>> calls "silencing tactics".
>> .
>> Remember, we're making a movie about this, and the whole world is
>> watching what we say to each other, and it is all a matter of public
>> record, distributed across thousands of independent machines,
>>
>> I am responding constructively to questions asked me by a guile
>> developer who is also an official representative of the FSF. Will the
>> FSF prevent me from doing so on an FSF forum. And if so, will any
>> guile developers respond to the mails I sent regarding guile? The one
>> about throw-handlers, and the one about block-allocations of cons
>> cells, the one about a liightning interface for guile. (People will
>> want to know why you ignored that.) and the one about 50,000 lines of
>> shell script with no explanation for things like this which are
>> basically setting up for an exploit. Once this sets the environment
>> variable, any programs knows it's on a back-level Solaris install, and
>> can infer a catalogue of exploits. But why is this check necessary
>> anyway? I know this not guile-specific, but it relates to my original
>> suggestion which was to replace autoconf with an abstract prolog
>> database for inferring system properties from formal descriptions, and
>> which wouldn't be vulnerable to this sort of nonsense., This is
>> something to which guile is ideally suited.
>>
>> In short, no I won't stop responding to people who make stupid
>> comments on this list, either about me, or things I've written on this
>> list.
>>
>> Speaking of which, what is the name and version of the program that
>> your emacs uses for "pdf->png" conversion? Your report, blaming me for
>> sending bad PDF, indicates a fairly fundamental misunderstanding of
>> what a program meant to do when it reads a file that supposed to be in
>> a defined format.
>>
>> And lastly, just be happy we're not discussing the FSFs 2013 financial
>> filing, which you presumably haven't read, because it's a PDF file ...
>>
>> Ian
>>
>> as_nl='
>> '
>> export as_nl
>> # Printing a long string crashes Solaris 7 /usr/bin/printf.
>> as_echo='\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'
>> as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo
>> as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo
>> # Prefer a ksh shell builtin over an external printf program on Solaris,
>> # but without wasting forks for bash or zsh.
>> if test -z "$BASH_VERSION$ZSH_VERSION" \
>>     && (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
>>   as_echo='print -r --'
>>   as_echo_n='print -rn --'
>> elif (test "X`printf %s $as_echo`" = "X$as_echo") 2>/dev/null; then
>>   as_echo='printf %s\n'
>>   as_echo_n='printf %s'
>> else
>>   if test "X`(/usr/ucb/echo -n -n $as_echo) 2>/dev/null`" = "X-n $as_echo"; 
>> then
>>     as_echo_body='eval /usr/ucb/echo -n "$1$as_nl"'
>>     as_echo_n='/usr/ucb/echo -n'
>>   else
>>     as_echo_body='eval expr "X$1" : "X\\(.*\\)"'
>>     as_echo_n_body='eval
>>       arg=$1;
>>       case $arg in #(
>>       *"$as_nl"*)
>>     expr "X$arg" : "X\\(.*\\)$as_nl";
>>     arg=`expr "X$arg" : ".*$as_nl\\(.*\\)"`;;
>>       esac;
>>       expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
>>     '
>>     export as_echo_n_body
>>     as_echo_n='sh -c $as_echo_n_body as_echo'
>>   fi
>>   export as_echo_body
>>   as_echo='sh -c $as_echo_body as_echo'
>> fi
>>
>>
>>>      Mark
>>
>> _______________________________________________
>> Lightning mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/lightning