[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lightning] Verifying Toolchain Semantics
From: |
Philip Herron |
Subject: |
Re: [Lightning] Verifying Toolchain Semantics |
Date: |
Tue, 7 Oct 2014 20:24:05 +0100 |
I think what we want is your posts really are not 100% related to
development of the respective development. Its flooding mailboxes.
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.
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
- Re: Verifying Toolchain Semantics, (continued)
- Re: Verifying Toolchain Semantics, Mike Gerwitz, 2014/10/05
- Re: Verifying Toolchain Semantics, Ian Grant, 2014/10/05
- Re: Verifying Toolchain Semantics, Mike Gerwitz, 2014/10/06
- Re: Verifying Toolchain Semantics, Ian Grant, 2014/10/07
- Re: Verifying Toolchain Semantics, Mark H Weaver, 2014/10/07
- Re: Verifying Toolchain Semantics, Ian Grant, 2014/10/07
- Re: [Lightning] Verifying Toolchain Semantics,
Philip Herron <=
- Re: [Lightning] Verifying Toolchain Semantics, Ian Grant, 2014/10/07
- Re: Verifying Toolchain Semantics, Mark H Weaver, 2014/10/08
- Re: Verifying Toolchain Semantics, Mike Gerwitz, 2014/10/07
Re: Verifying Toolchain Semantics, Ian Grant, 2014/10/05
Re: Verifying Toolchain Semantics, Ian Grant, 2014/10/05