clisp-devel

build-porting64-gcc-debug_gcsafety

[Sam S. <sd...@gn...>]

Hi Bruno,
This is my first attempt to use your new multibuild targets.
I did this:

--8<---------------cut here---------------start------------->8---
$ make -f Makefile.devel multibuild-porting64-gcc
...
./comment5 ../src/aridecl.d | ./gctrigger | ./varbrace > aridecl.c
End of comment outside comment in line 154
End of comment outside comment in line 199
g++ -I/home/sds/src/clisp/current/src -I/home/sds/src/clisp/current/build-porting64-gcc-debug_gcsafety/gllib -I/home/sds/src/clisp/current/src/gllib -g -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wno-sign-compare -Wno-format-nonliteral -Wno-invalid-offsetof -fno-strict-aliasing -ggdb -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DDEBUG_GCSAFETY -DENABLE_UNICODE -DDYNAMIC_FFI -c spvw.c
In file included from ../src/spvw.d:23:0:
../src/lispbibl.d:323:83: fatal error: intparam.h: No such file or directory
   #include "intparam.h"  /* integer-type characteristics created by the machine */
                                                                                   ^
compilation terminated.
Makefile:1066: recipe for target 'spvw.o' failed
make[1]: *** [spvw.o] Error 1
make[1]: Leaving directory '/home/sds/src/clisp/current/build-porting64-gcc-debug_gcsafety'
--8<---------------cut here---------------end--------------->8---

This is a vanilla ubuntu 16.10 (Linux 4.8.0-40-generic x86_64
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005).



-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://palestinefacts.org
http://memri.org http://www.memritv.org http://ffii.org
Any connection between your reality and mine is purely coincidental.

Re: build-porting64-gcc-debug_gcsafety

[Bruno H. <br...@cl...>]

Hi Sam,

> $ make -f Makefile.devel multibuild-porting64-gcc
> ...
> ../src/lispbibl.d:323:83: fatal error: intparam.h: No such file or directory
>    #include "intparam.h"  /* integer-type characteristics created by the machine */

I've now added a message to configure that, in this case, tell you to look in
config.log.

Errors at this stage frequently come from unsuitable values in the environment
variables CC, CXX, and MULTIBUILD_64_OPTIONS.

Bruno

Re: build-porting64-gcc-debug_gcsafety

[Bruno H. <br...@cl...>]

Hi Sam,

> okay, build-porting64-gcc-spvw_pure_blocks failed _silently_ (IOW, the
> above command kept going despite the failure).
> The config.log is appended.

This config.log succeeded and produced intparam.h and floatparam.h.

> When I rerun it, it failed with
> 
> --8<---------------cut here---------------start------------->8---
> ../src/lispbibl.d:5572:36: warning: left shift of negative value [-Wshift-negative-value]
>      objectplus(obj, (soint)(delta) << oint_data_shift)
>                                     ^
> ../src/lispbibl.d:501:47: note: in definition of macro ‘designated_init’
>    #define designated_init(field,value) .field=value
>                                                ^~~~~
> ../src/lispbibl.d:3218:35: note: in expansion of macro ‘as_object’
>    #define objectplus(obj,offset)  as_object(as_oint(obj)+(soint)(offset))
>                                    ^~~~~~~~~
> ../src/lispbibl.d:5572:5: note: in expansion of macro ‘objectplus’
>      objectplus(obj, (soint)(delta) << oint_data_shift)
>      ^~~~~~~~~~
> ../src/spvw_weak.d:886:51: note: in expansion of macro ‘fixnum_inc’
>              TheWeakHashedAlist(obj)->whal_count = fixnum_inc(TheWeakHashedAlist(obj)->whal_count,-1);
>                                                    ^~~~~~~~~~
> Makefile:1068: recipe for target 'spvw.o' failed
> make[1]: *** [spvw.o] Error 1
> make[1]: Leaving directory '/home/sds/src/clisp/current/build-porting64-gcc-spvw_pure_blocks'
> --8<---------------cut here---------------end--------------->8---

The 'note' and 'warning' diagnostics are irrelevant for the failure here.

So I still cannot guess what produced these "missing intparam.h and floatparam.h"
errors in your build.

Bruno

Re: build-porting64-gcc-debug_gcsafety

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-10 14:37:23 +0100]:
>
>> ../src/lispbibl.d:5572:36: warning: left shift of negative value [-Wshift-negative-value]
>>      objectplus(obj, (soint)(delta) << oint_data_shift)
>>                                     ^

shouldn't it be 

     objectplus(obj, (soint)(delta << oint_data_shift))

instead?

> So I still cannot guess what produced these "missing intparam.h and
> floatparam.h" errors in your build.

I hope to have time to dig more tomorrow night.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://jij.org https://ffii.org http://no2bds.org http://memri.org
Yellow wine is called "white" because it is made out of green grapes.

Re: build-porting64-gcc-debug_gcsafety

[Bruno H. <br...@cl...>]

Hi Sam,

> > * Bruno Haible <oe...@py...t> [2017-03-10 14:37:23 +0100]:
> >
> >> ../src/lispbibl.d:5572:36: warning: left shift of negative value [-Wshift-negative-value]
> >>      objectplus(obj, (soint)(delta) << oint_data_shift)
> >>                                     ^
> 
> shouldn't it be 
> 
>      objectplus(obj, (soint)(delta << oint_data_shift))
> 
> instead?

Definitely no. 'delta' can be a simple 'int' (i.e. 32 bits wide),
and we have configurations with oint_data_shift = oint_addr_shift = 32.

As I said on 2017-02-08, diagnostics from -Wshift-negative-value are
most probably just noise.

Bruno

Re: build-porting64-gcc-debug_gcsafety

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-10 18:19:40 +0100]:
>
> As I said on 2017-02-08, diagnostics from -Wshift-negative-value are
> most probably just noise.

Why not disable them then?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://jihadwatch.org
http://thereligionofpeace.com http://islamexposedonline.com
Binaries die but source code lives forever.

Re: -Wshift-negative-value

[Bruno H. <br...@cl...>]

Hi Sam,

> > As I said on 2017-02-08, diagnostics from -Wshift-negative-value are
> > most probably just noise.
> 
> Why not disable them then?

Feel free to do so. Good idea.

My priority for the moment is to fix build errors.
Therefore, warnings are lower priority for me, right now.

Bruno

Re: -Wshift-negative-value

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-10 19:42:20 +0100]:
>
> My priority for the moment is to fix build errors.

Does this include the "make check-image" failure?
https://sourceforge.net/p/clisp/bugs/687/

> Therefore, warnings are lower priority for me, right now.

Noise makes it harder for us to create meaningful reports.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://jihadwatch.org
http://think-israel.org http://jij.org http://thereligionofpeace.com
The dark past once was the bright future.

Re: -Wshift-negative-value

[Karsten P. <Kar...@gm...>]

On 10.03.17 19:54, Sam Steingold wrote:
> Hi Bruno,
>
>> * Bruno Haible <oe...@py...t> [2017-03-10 19:42:20 +0100]:
>>
>> My priority for the moment is to fix build errors.
>
> Does this include the "make check-image" failure?
> https://sourceforge.net/p/clisp/bugs/687/

Hello,

in my builds make check fails only in make check-exec-image with the 
same message as in the referred bug.

Macos Sierra 10.12.03

[1]> (software-version)
"GNU C 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)"
[2]> (software-type)
"gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type 
-Wmissing-declarations -Wimplicit -Wno-sign-compare 
-Wno-format-nonliteral -O -fno-strict-aliasing -DUNIX_BINARY_DISTRIB 
-DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT  libgnu.a 
-L/usr/local/opt/readline//lib -lreadline -lncurses 
/usr/local//lib/libavcall.a /usr/local//lib/libcallback.a 
/usr/local//lib/libsigsegv.a -lc  -L/usr/X11/lib
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED 
TRIVIALMAP_MEMORY
libsigsegv 2.11
libreadline 7.0
libffcall 1.13"

Anything I can do to help debug this (My lisp is a lot better than my c)?

regards

Karsten

Re: -Wshift-negative-value

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...t> [2017-03-10 19:42:20 +0100]:
>
>> > As I said on 2017-02-08, diagnostics from -Wshift-negative-value are
>> > most probably just noise.
>> 
>> Why not disable them then?
>
> Feel free to do so. Good idea.

Done.


> My priority for the moment is to fix build errors.

here is what I see at the tip (./configure --with-debug --cbc on macosx)

--8<---------------cut here---------------start------------->8---
Warning: overwriting existing memory mappings in the address range 0x3fffffedd000...0x3fffffeddfff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x200262000...0x200262fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffedc000...0x3fffffedcfff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffedb000...0x3fffffedbfff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffeda000...0x3fffffedafff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x200263000...0x200263fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed9000...0x3fffffed9fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed8000...0x3fffffed8fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x200264000...0x200264fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed7000...0x3fffffed7fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x200265000...0x200265fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed6000...0x3fffffed6fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed5000...0x3fffffed5fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed4000...0x3fffffed4fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x200266000...0x200266fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed3000...0x3fffffed3fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed2000...0x3fffffed2fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x200267000...0x200267fff. clisp will likely crash soon!!
Warning: overwriting existing memory mappings in the address range 0x3fffffed1000...0x3fffffed1fff. clisp will likely crash soon!!
--8<---------------cut here---------------end--------------->8---



> Therefore, warnings are lower priority for me, right now.
>
> Bruno
>
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://americancensorship.org https://jihadwatch.org http://www.dhimmitude.org
Do the arithmetic or be doomed to talk nonsense. --John McCarthy

Re: -Wshift-negative-value

[Bruno H. <br...@cl...>]

Hi Sam,

> here is what I see at the tip (./configure --with-debug --cbc on macosx)
> 
> --8<---------------cut here---------------start------------->8---
> Warning: overwriting existing memory mappings in the address range 0x3fffffedd000...0x3fffffeddfff. clisp will likely crash soon!!
> Warning: overwriting existing memory mappings in the address range 0x200262000...0x200262fff. clisp will likely crash soon!!
> Warning: overwriting existing memory mappings in the address range 0x3fffffedc000...0x3fffffedcfff. clisp will likely crash soon!!

Oops. mincore() on Mac OS X is apparently not usable for detecting whether a
page is mapped: it returns 0 in either case. Seen on Mac OS X 10.11 through
the attached program.

Fixed now.

Bruno

Re: make check-exec-image failure

[Bruno H. <br...@cl...>]

Hi Sam,

> > My priority for the moment is to fix build errors.
> 
> Does this include the "make check-image" failure?
> https://sourceforge.net/p/clisp/bugs/687/

No. (savemem ... :executable t) is based on
spvw_memfile.d:savemem_with_runtime, which consists in *appending*
a memory image to an *executable file*.

This is precisely the hack which delayed the port of AKCL to Linux
by 1 year in 1992/1993 (which is why then clisp became more popular
than AKCL on Linux) [1]. I had ported clisp to Linux in 1 day.

And it is because of this lesson that I decided to create 'clisp-link'
based on the notion of a "linking set" [2] where the memory image
is *separate* from the executable.

I certainly won't spend time digging in the internals of the Mach-O
object format in order to find out how to port this to Mac.

Instead, I would better see
  1) the doc clearly state in [3] that this is a platform-dependent
     feature (and list the OSes on which it works),
  2) adjust makemake.in so that this feature gets tested only on
     those platforms where it works.

Additional background:
There is now a general move away from "pack everything into one file"
to "create separate file for different purposes".

* Distros have in fact started to distribute the debug information for binaries
  in separate files. So, instead of having a file 'foo' that may or may not
  contain debug information, you have a file 'foo' without debug information
  and optionally a file '/var/debug/foo' with only the debug information.
  What is the benefit? You can install the debug information on the fly, when
  you need it, for example once the binary crashed for the first time.

* Similarly, in old Windows, executable code and resources were packed in the
  same .exe file. In OS X, which is more modern, the executable code and the
  resources are just normal files in a single 'foo.app' directory.

Bruno

[1] http://www.ibiblio.org/pub/historic-linux/ftp-archives/sunsite.unc.edu/Sep-29-1996/devel/lang/lisp//akcl.README
[2] http://clisp.org/impnotes/modules.html#mod-overview
[3] http://clisp.org/impnotes/image.html

Re: -Wshift-negative-value

[Bruno H. <br...@cl...>]

Hi Sam,

> >> > As I said on 2017-02-08, diagnostics from -Wshift-negative-value are
> >> > most probably just noise.
> >> 
> >> Why not disable them then?
> >
> > Feel free to do so. Good idea.
> 
> Done.

On OpenBSD 6, with gcc 4.2.1, I now get the build error:
cc1: error: unrecognized command line option "-Wno-shift-negative-value"

Please, can you limit the use of this option to the compilers that support it?
Just tried it (I have all gcc releases installed separately): it's supported
starting with gcc 4.4.0, unsupported for older versions.

Using the same idiom that I used to protect the use of -Wno-invalid-offsetof:

    # g++ 3.4 introduced an annoying warning, but has a workaround:
    case "$XCC_GCC_VERSION" in
      2.* | 3.[1-3]*) ;;
      *)
        XCFLAGS=$XCFLAGS' -Wno-invalid-offsetof'
        ;;
    esac

Btw, why did you remove this version check? It is needed:

$ /arch/x86-linux/gnu-inst-gcc/3.4.4/bin/gcc -x c++ -Wno-invalid-offsetof -S hello.c

succeeds but

$ /arch/x86-linux/gnu-inst-gcc/3.3.6/bin/gcc -x c++ -Wno-invalid-offsetof -S hello.c
cc1plus: error: unrecognized option `-Wno-invalid-offsetof'

I tend to assume a gcc version >= 3.1.

Bruno

Re: -Wshift-negative-value

[Daniel J. <dan...@gm...>]

> > > As I said on 2017-02-08, diagnostics from -Wshift-negative-value are
> > > most probably just noise.
> >
> > Why not disable them then?
>
> Feel free to do so. Good idea.

Actually, this is is a very (very) bad idea. Applying a (left) shift to a
negative value (or shifting by a negative value) is undefined behavior
since (AFAIK) C99 (which is what we - at least in September - wanted to
target).

Quote from (C11) standard (draft) [1]:

"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
are filled with zeros. [..] If E1 has a signed type and nonnegative value
[..] otherwise, the behavior is undefined."
N1570 §6.5.7/4

Thus every single one of those warnings is a possible Heisenbug.
Any random optimizer pass of any compiler could horribly break our code. We
could force compilation without any optimization to reduce the risk of
hitting such a case, but that's not really reasonable.

[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Re: -Wshift-negative-value

[Bruno H. <br...@cl...>]

Hi Daniel,

> > > > As I said on 2017-02-08, diagnostics from -Wshift-negative-value are
> > > > most probably just noise.
> > >
> > > Why not disable them then?
> >
> > Feel free to do so. Good idea.
> 
> Actually, this is is a very (very) bad idea. Applying a (left) shift to a
> negative value (or shifting by a negative value) is undefined behavior
> since (AFAIK) C99 (which is what we - at least in September - wanted to
> target).
> 
> Quote from (C11) standard (draft) [1]:
> 
> "The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
> are filled with zeros. [..] If E1 has a signed type and nonnegative value
> [..] otherwise, the behavior is undefined."
> N1570 §6.5.7/4

It is undefined because ISO C supports not only two's complement representation
of signed integers, but also one's complement and sign-magnitude. Quote from
[1] § J.3.5:
  "The following are implementation-defined:
   ...
   — Whether signed integer types are represented using sign and magnitude, two’s
     complement, or ones’ complement, and whether the extraordinary value is a trap
     representation or an ordinary value (6.2.6.2)."

But clisp will never support anything else than two's complement arithmetic.
I haven't heard of any machine with one's complement or sign-magnitude in use
since 1980, and even gnulib - which caters to old and traditional systems -
now no longer attempts to support these odd systems [2].

> Thus every single one of those warnings is a possible Heisenbug.
> Any random optimizer pass of any compiler could horribly break our code.

Indeed. In order for this not to happen, I'm adding the gcc option "-fwrapv"
to the CFLAGS.

If, at some point, we want to get rid of this option and let the C compiler
optimize all it can, we'll need to revisit clisp's uses of signed integer
types with the help of -fsanitize=undefined (which is the successor of
the -ftrapv option [3]. -ftrapv does not catch all situations, see attached
file).

Bruno

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
[2] http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=67d133ee7b512af59a392f533b17302d71e937db
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68046#c1

Re: make check-exec-image failure

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-11 00:54:35 +0100]:
>
>> > My priority for the moment is to fix build errors.
>> 
>> Does this include the "make check-image" failure?
>> https://sourceforge.net/p/clisp/bugs/687/
>
> No. (savemem ... :executable t) is based on
> spvw_memfile.d:savemem_with_runtime, which consists in *appending*
> a memory image to an *executable file*.

I know, I wrote it.

> I certainly won't spend time digging in the internals of the Mach-O
> object format in order to find out how to port this to Mac.

this is a regression on _all_ platforms.

> There is now a general move away from "pack everything into one file"
> to "create separate file for different purposes".

Users, nevertheless, do ask for a "single executable" option.

CLISP, being a developer's tool - as opposed to a user's tool, needs, in
addition to "vendor model" you describe: a team of seasoned
professionals building distributions to be used by many people, a
"custom exec" model, when a lisp hacker throws together a quick solution
and gives is to his 1 or 2 ad hoc users.

E.g., I want to run something on a box in which I cannot install anything.
An executable image - as opposed to two files (runtime + image) - is
easier to distribute.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://palestinefacts.org http://honestreporting.com
http://islamexposedonline.com http://www.dhimmitude.org http://ffii.org
A snake who stung your enemy is not necessarily your friend.

Re: make check-exec-image failure

[Bruno H. <br...@cl...>]

Hi Sam,

> > There is now a general move away from "pack everything into one file"
> > to "create separate file for different purposes".
> 
> Users, nevertheless, do ask for a "single executable" option.
> 
> CLISP, being a developer's tool - as opposed to a user's tool, needs, in
> addition to "vendor model" you describe: a team of seasoned
> professionals building distributions to be used by many people, a
> "custom exec" model, when a lisp hacker throws together a quick solution
> and gives is to his 1 or 2 ad hoc users.
> 
> E.g., I want to run something on a box in which I cannot install anything.
> An executable image - as opposed to two files (runtime + image) - is
> easier to distribute.

This is not a sound argument. When a file is transferred to a machine,
whether by ftp, scp, the browser, or whatever, it is by default not executable.
This is means, it needs some "post-install" command to really make it
usable. Whether this command is a "chmod a+x" or "tar xfz" or "unzip -x",
does not make a big difference in practice.

Additionally, most users want to transfer binaries in a compressed way,
to save bandwidth.

Now, when you accept "tar xfz" or "unzip -x" as a post-install command,
there is no reason to insist on just 1 file.

So, when users ask for a "single executable" option, tell them that this
option would buy them nothing.

> > No. (savemem ... :executable t) is based on
> > spvw_memfile.d:savemem_with_runtime, which consists in *appending*
> > a memory image to an *executable file*.
> 
> I know, I wrote it.

The only way of generating an executable that does not cause portability
problems - and thus endless maintenance hassles - is through the compiler
($CC), that invokes the linker, or through the linker directly ($LD).

> > I certainly won't spend time digging in the internals of the Mach-O
> > object format in order to find out how to port this to Mac.
> 
> this is a regression on _all_ platforms.

No, it's not a regression if we tell people that a certain feature cannot
work on specific platforms, such as Mac OS X and MirBSD.

If you want the complete list of platforms where it works vs. does not work,
I can determine this list for you over time by running "make check-exec-image"
as part of my testing in the next few weeks.

But what I need is that "make check" does not abort prematurely, because
a "make check" failure means - to everyone - "the package is broken, you
should better not proceed with 'make install'".

Bruno

Re: make check-exec-image failure

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-13 01:12:19 +0100]:
>
> So, when users ask for a "single executable" option, tell them that this
> option would buy them nothing.

I see your point, but I find it unconvincing.

It sounds like "I cannot give you what you came to expect from C, so I
will try to convince you that you should not ask for it in the first
place".

You are a smart guy and you can build a convincing sounding argument.

However, it boils down to "the whole world is wrong, I am right".
The same story was with FP contagion 20 years ago - I understand the
subject and I implemented what the world thinks is right.
The same story with ignoring GCC warnings today - I don't understand the
subject and I am leaving it to you (the problem is that if you step
away again, CLISP will be dead in the water because finding someone
shares your views would be impossible.)


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000
http://www.childpsy.net/ http://islamexposedonline.com http://camera.org
http://openvotingconsortium.org http://www.memritv.org http://ffii.org
Money does not "play a role", it writes the scenario.

Re: make check-exec-image failure

[<Joe...@t-...>]

Hi,

>But what I need is that "make check" does not abort prematurely, because a "make check" failure
>means - to everyone - "the package is broken, you should better not proceed with 'make install'".
I've always wondered whether distros use "make check" before releasing a package.
I have some doubts though, because I remember reading bugs that one would think impossible
had people used make check as a prerequisite.
Of course, make check probably works only on the target platform, not the cross-compiler build farm?

IMHO "make check" is important, because it ensures that basic CLISP functions work,
including GC and sockets (even some FFI tests).


I find a maintainer's attitude reasonable: Each and every warning is puzzling and costs
time ("is it or not the sign of a problem?"). As such, supplying options to force the
desired semantics, such as -fwrapv -fno-strict-aliasing and *not* silencing warnings
(assuming -fwrapv will silence those related to overflows) is an approach that should
satisfy both maintainers, developers as well as users occasionally compiling code. The
compile log will contain few warnings *and* the program will not crash from GCC
"optimizations" in obscure (rarely used) areas of the code.

Forcing the desired semantics should also have the additional benefit of allowing GCC's
highest optimization levels (-O3 to -O6), but that's another story.


>So, when users ask for a "single executable" option, tell them that this option would buy them nothing.

Maybe we could differentiate user expectations by target platform?
- MS-Windows: single file mostly welcome (think "portable executable (PE)"). 
Self-extracting and executing archives are common.

- trad. UNIX: used to packages and support files in /lib /usr /etc
Yet Sam put in effort to support that too, several years ago...
(I remember other tricks, like a file beginning as a tiny shell script,
 then exit, followed by binary stuff).

A single file is nice because sometimes you lose track of what .mem belongs to what lisp.run.

- MacOSX: People are used to foo.app for GUI apps.
Some know that they can invoke apps on the CLI via e.g. /Applications/VLC.app/Contents/MacOS/VLC
I have no idea whether a CLISP.app structure would make sense for a program that
only lives on the command line, i.e. whether an .app is expected to follow some
protocol, such as opening an event loop and responding to a WM startup notification message?

My expectation: When starting CLISP.app, (Saveinitmem ... :executable t) would
create another .app, somewhere else.

Another approach (involving several files): I've often created clickable files named
*.desktop (on Linux) and *.command (OSX) that start a terminal and a program therein.
The icon file is separate (.desktop) or in the resource fork (.command).
That's all I need, but others did not seem impressed by my approach ;-)

Regards,
	Jörg

Re: shrink-wrapped distribution

[Bruno H. <br...@cl...>]

Hi Jörg,

> Maybe we could differentiate user expectations by target platform?
> - MS-Windows: single file mostly welcome (think "portable executable (PE)"). 
> Self-extracting and executing archives are common.

OTOH, nowadays the "File Explorer" can unzip .zip files right away, I think.
Right?

> - trad. UNIX: ... 
> (I remember other tricks, like a file beginning as a tiny shell script,
>  then exit, followed by binary stuff).

A shell script is also what GNU 'shar' produces.

In KDE, when you click on a .zip file in dolphin, it opens 'ark', which
allows the user to extract the zip into a target directory, without any use
of command-line.

But when I click on a .sh file in dolphin, it opens it in an editor by default.
It also offers the option to execute it in a terminal emulator, but this does
not work (and avoiding the command-line was one of the purposes of the exercise).

> - MacOSX: People are used to foo.app for GUI apps.
> Some know that they can invoke apps on the CLI via e.g. /Applications/VLC.app/Contents/MacOS/VLC
> I have no idea whether a CLISP.app structure would make sense for a program that
> only lives on the command line

Can you find out?

Bruno

Re: make check-exec-image failure

[Karsten P. <Kar...@gm...>]

On 13.03.17 01:12, Bruno Haible wrote:
> But what I need is that "make check" does not abort prematurely, because
> a "make check" failure means - to everyone - "the package is broken, you
> should better not proceed with 'make install'".

While the issue with check-exec-image is being discussed (and the 
discussion is outside of my skillset) can't you do something like the 
following in src/makemake.in

   # don’t run check-exec-image on Darwin
   # CHECK_DEPS="check-recompile check-fresh-line check-script 
check-exec-image check-tests"
   case "$host_os"  in
     darwin* )
        CHECK_DEPS="check-recompile check-fresh-line check-script 
check-tests"
       ;;
     * )
         CHECK_DEPS="check-recompile check-fresh-line check-script 
check-exec-image check-tests"
       ;;
   esac

Works at least for me, don't know how others check result

Karsten

Re: make check-exec-image failure

[Bruno H. <br...@cl...>]

Hi Sam,

> > So, when users ask for a "single executable" option, tell them that this
> > option would buy them nothing.
> 
> I see your point, but I find it unconvincing.
> ...
> However, it boils down to "the whole world is wrong, I am right".

It's not "the whole world". Read again my argument
<<There is now a general move away from "pack everything into one file"
  to "create separate file for different purposes"...>>

Bruno

Re: make check-exec-image failure

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-03-13 09:41:35 +0100]:
>
>> > So, when users ask for a "single executable" option, tell them that this
>> > option would buy them nothing.
>> 
> <<There is now a general move away from "pack everything into one file"
>   to "create separate file for different purposes"...>>

This is true for skilled vendors distributing well-polished packages to
many users.

This is not true for someone like me who threw together a quick hack to
be run by my wife. It is much easier for me to email her an executable
image which she will copy to her desktop and click to run than create a
tgz which she has to unpack, install &c &c.

The only alternative to `(saveinitmem :executable t)` is
`(make-distribution)` which will create an executable installer.

Until we have it, we should support executable images.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://no2bds.org http://camera.org http://mideasttruth.com http://iris.org.il
Can I do it in Lisp, or would you rather wait an extra couple of months?

Re: gcc warnings

[Bruno H. <br...@cl...>]

Hi Sam,

> The same story with ignoring GCC warnings today - I don't understand the
> subject and I am leaving it to you

I will deal with these GCC warnings. But to keep the story short:

  1) It is better to start with all warnings and disable the warnings
     on case-by-case basis, than to start with no warnings and enable them
     selectively. Reason: GCC keeps adding new, useful warnings for a number
     of years already. [1]

  2) clang has become a compiler to care about as well, and clang has also
     a number of useful (and a small number of not useful) warnings.

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

Re: gcc warnings

[Sam S. <sd...@gn...>]

Hi Bruno,

My general attitude to compiler warnings is that each such warning is a bug.
Either it is a bug in the code being compiled, or it is a bug in the compiler.
Thus disabling a warning is merely closing one's eyes.
It can be a stop-gap (let's disable warning A while we are working on
warning B), but never permanent.
I know you disagree, and I doubt that I will convince you or vv.
Thanks for dealing with the issue.


> * Bruno Haible <oe...@py...t> [2017-03-13 09:47:49 +0100]:
>
> Hi Sam,
>
>> The same story with ignoring GCC warnings today - I don't understand the
>> subject and I am leaving it to you
>
> I will deal with these GCC warnings. But to keep the story short:
>
>   1) It is better to start with all warnings and disable the warnings
>      on case-by-case basis, than to start with no warnings and enable them
>      selectively. Reason: GCC keeps adding new, useful warnings for a number
>      of years already. [1]
>
>   2) clang has become a compiler to care about as well, and clang has also
>      a number of useful (and a small number of not useful) warnings.
>
> Bruno
>
> [1] https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://camera.org
http://iris.org.il http://mideasttruth.com http://islamexposedonline.com
Stupidity, like virtue, is its own reward.