You can subscribe to this list here.
2000 |
Jan
(81) |
Feb
(55) |
Mar
(459) |
Apr
(159) |
May
(126) |
Jun
(69) |
Jul
(48) |
Aug
(29) |
Sep
(106) |
Oct
(76) |
Nov
(155) |
Dec
(161) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(122) |
Feb
(150) |
Mar
(294) |
Apr
(124) |
May
(197) |
Jun
(266) |
Jul
(111) |
Aug
(259) |
Sep
(163) |
Oct
(142) |
Nov
(101) |
Dec
(86) |
2002 |
Jan
(187) |
Feb
(108) |
Mar
(274) |
Apr
(157) |
May
(346) |
Jun
(242) |
Jul
(345) |
Aug
(187) |
Sep
(263) |
Oct
(69) |
Nov
(30) |
Dec
(76) |
2003 |
Jan
(125) |
Feb
(191) |
Mar
(87) |
Apr
(69) |
May
(107) |
Jun
(66) |
Jul
(112) |
Aug
(161) |
Sep
(184) |
Oct
(137) |
Nov
(28) |
Dec
(61) |
2004 |
Jan
(148) |
Feb
(99) |
Mar
(365) |
Apr
(225) |
May
(311) |
Jun
(204) |
Jul
(95) |
Aug
(214) |
Sep
(256) |
Oct
(290) |
Nov
(239) |
Dec
(152) |
2005 |
Jan
(253) |
Feb
(183) |
Mar
(178) |
Apr
(88) |
May
(175) |
Jun
(195) |
Jul
(122) |
Aug
(81) |
Sep
(119) |
Oct
(200) |
Nov
(110) |
Dec
(179) |
2006 |
Jan
(154) |
Feb
(64) |
Mar
(55) |
Apr
(69) |
May
(66) |
Jun
(64) |
Jul
(80) |
Aug
(59) |
Sep
(62) |
Oct
(90) |
Nov
(132) |
Dec
(106) |
2007 |
Jan
(58) |
Feb
(51) |
Mar
(59) |
Apr
(19) |
May
(33) |
Jun
(52) |
Jul
(15) |
Aug
(50) |
Sep
(41) |
Oct
(259) |
Nov
(323) |
Dec
(136) |
2008 |
Jan
(205) |
Feb
(128) |
Mar
(203) |
Apr
(126) |
May
(307) |
Jun
(166) |
Jul
(259) |
Aug
(181) |
Sep
(217) |
Oct
(265) |
Nov
(256) |
Dec
(132) |
2009 |
Jan
(104) |
Feb
(81) |
Mar
(27) |
Apr
(21) |
May
(85) |
Jun
(237) |
Jul
(243) |
Aug
(199) |
Sep
(178) |
Oct
(151) |
Nov
(64) |
Dec
(39) |
2010 |
Jan
(33) |
Feb
(146) |
Mar
(125) |
Apr
(109) |
May
(52) |
Jun
(135) |
Jul
(103) |
Aug
(68) |
Sep
(99) |
Oct
(88) |
Nov
(45) |
Dec
(56) |
2011 |
Jan
(19) |
Feb
(32) |
Mar
(50) |
Apr
(105) |
May
(46) |
Jun
(22) |
Jul
(101) |
Aug
(80) |
Sep
(52) |
Oct
(16) |
Nov
(10) |
Dec
(29) |
2012 |
Jan
(8) |
Feb
(22) |
Mar
(17) |
Apr
(68) |
May
(19) |
Jun
(19) |
Jul
(12) |
Aug
(6) |
Sep
(13) |
Oct
(5) |
Nov
(5) |
Dec
(5) |
2013 |
Jan
(6) |
Feb
(4) |
Mar
(3) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
(16) |
Apr
(1) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(8) |
Mar
(23) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
(5) |
2016 |
Jan
|
Feb
|
Mar
(16) |
Apr
(6) |
May
(53) |
Jun
(19) |
Jul
(3) |
Aug
(39) |
Sep
(24) |
Oct
(2) |
Nov
(19) |
Dec
|
2017 |
Jan
(13) |
Feb
(44) |
Mar
(208) |
Apr
(12) |
May
(94) |
Jun
(54) |
Jul
(18) |
Aug
(52) |
Sep
(12) |
Oct
(22) |
Nov
(27) |
Dec
(93) |
2018 |
Jan
(85) |
Feb
(28) |
Mar
(16) |
Apr
(47) |
May
(16) |
Jun
(15) |
Jul
(10) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
|
2019 |
Jan
(4) |
Feb
(6) |
Mar
(12) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2022 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(5) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <don...@is...> - 2019-11-07 17:26:35
|
First, in spite of no changes to soure, the nightly build last night did not reproduce the error I reported yesterday. The doc in impnotes: 25.3.4. Function LISP-IMPLEMENTATION-VERSION LISP-IMPLEMENTATION-VERSION returns the numeric version (like 3.14), and the release date (like "1999-07-21"). When running on the same machine on which CLISP was built, it appends the binary build and memory image dump date in universal time (like 3141592654). When running on a different machine, it appends the MACHINE-INSTANCE of the machine on which it was built. One question is how it decides whether running on the same machine. Another is where it gets this thing that looks like an ip address "2.49.93+ (2018-02-18) (built on number15.don-eve [198.105.244.228])" I don't believe that this was ever the ip address of this machine. |
From: <don...@is...> - 2019-11-06 15:00:18
|
==> cbcstep3.log <== Test failed: -rw-r--r--. 1 don don 899 Nov 6 03:05 socket.erg To see which tests failed, type cat /home/don/clisp/build-dir/tests/*.erg Makefile:34: recipe for target 'compare' failed make[1]: *** [compare] Error 1 make[1]: Leaving directory '/home/don/clisp/build-dir/tests' Makefile:2218: recipe for target 'check-tests' failed make: *** [check-tests] Error 2 ===> make check FAILED ... cat /home/don/clisp/build-dir/tests/socket.erg Form: (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((IS (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS '("-q" "-q" "-x" " (let ((se (socket:socket-server))) (write-line (princ-to-string (socket:socket-server-port se))) (with-open-stream (so (socket:socket-accept se)) (write-line (lisp-implementation-version) so)) (socket:socket-server-close se)) ")) :INPUT NIL :OUTPUT :STREAM)) LOCAL REMOTE) (LOOP :UNTIL (DIGIT-CHAR-P (PEEK-CHAR NIL IS)) :DO (READ-LINE IS)) (WITH-OPEN-STREAM (SO (SOCKET-CONNECT (READ IS) "localhost" :TIMEOUT 10)) (OR (STRING= (SETQ LOCAL (LISP-IMPLEMENTATION-VERSION)) (SETQ REMOTE (READ-LINE SO))) (LIST :LOCAL LOCAL :REMOTE REMOTE))))) CORRECT: T CLISP : (:LOCAL "2.49.93+ (2018-02-18) (built 3782026988) (memory 3782027047)" :REMOTE "2.49.93+ (2018-02-18) (built on number15.don-eve [23.217.138.107])") |
From: Bruno H. <br...@cl...> - 2019-06-29 15:37:13
|
Sam Steingold wrote: > Sorry about not replying earlier - I thought that you were actually > planning to work more on your patch. Very good point. My initial reaction to Kaz' patch in <https://sourceforge.net/p/clisp/mailman/message/36601264/> was "who needs the generic case, the frequent case is that the keywords are known at compile time". The only thing I did not like about it was the (not (constantp ev-argform)) - the error checking of the keywords should be done by DEFSETF, not in GET-SETF-EXPANSION. But you are absolutely right: When writing compilers (and macroexpansion code), one should strive for maximum generality, and the optimizations of common cases are only special cases. So, looking at http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_5-1-1-2.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_get-setf-expansion.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defsetf.html there is even an example regarding computed keywords: (defsetf xy (&key ((x x) 0) ((y y) 0)) (store) `(set-xy ,store 'x ,x 'y ,y)) => XY (get-setf-expansion '(xy a b)) => (#:t0 #:t1), (a b), (#:store), ((lambda (&key ((x #:x)) ((y #:y))) (set-xy #:store 'x #:x 'y #:y)) #:t0 #:t1), (xy #:t0 #:t1) This example gives an important clue: How to use a LAMBDA for keyword matching. But this example is wrong. It ignores the keyword init forms. The correct result is: (get-setf-expansion '(xy a b)) => (#:t0 #:t1), (a b), (#:store), ((lambda (&key ((x #:x)) ((y #:y))) (set-xy #:store 'x #:x 'y #:y)) #:t0 #:t1 'x 0 'y 0), (xy #:t0 #:t1 'x 0 'y 0) or => (#:t0 #:t1), (a b), (#:store), ((lambda (&key ((x #:x) 0) ((y #:y) 0)) (set-xy #:store 'x #:x 'y #:y)) #:t0 #:t1), (xy #:t0 #:t1 'x 0 'y 0) Things get more hairy when we think of keyword init forms that are not constant forms. In which environment do they get evaluated? Example: (defun zero () 0) (flet ((default-form-for-y () '(zero))) (defsetf xy (&key ((x x) '(zero)) ((y y) (default-form-for-y))) (store) `(set-xy ,store 'x ,x 'y ,y))) => XY There are two evaluations: 1. At macro expansion time, i.e. during get-setf-expansion, (default-form-for-y) gets evaluated, in the lexical environment of the DEFSETF form. => (ZERO). 2. At runtime, (ZERO) gets evaluated. => 0. So, DEFSETF needs to store a closure that will evaluate (default-form-for-y). The other thing is: How should the desired result of GET-SETF-EXPANSION look like? Let's take an example with keywords arguments that are not in the keyword package, non-constant keyword init forms, and with a required argument as well. > (defsetf xy (r &key ((x x) '(zero)) ((y y) '(zero))) (store) `(set-xy ,store ,r 'x ,x 'y ,y)) XY The simple case, when all keywords are specified as constants, is: > (get-setf-expansion '(xy 3 'x 0 'y 0)) (#:G1 #:G2 #:G3) ; (3 0 0) ; (#:G4) ; (SET-XY #:G4 #:G1 'X #:G2 'Y #:G3) ; (XY #:G1 'X #:G2 'Y #:G3) The general case, when all keyword arguments are non-constant, requires the LAMBDA trick, and the mechanism for using the keyword init form shown above: > (get-setf-expansion '(xy 3 a 0)) (#:G1 #:G2 #:G3 #:G4 #:G5) ; (3 A 0 (ZERO) (ZERO)) ; (#:G6) ; ((LAMBDA (&KEY ((X #:G7)) ((Y #:G8))) (SET-XY #:G6 #:G1 'X #:G7 'Y #:G8)) #:G2 #:G3 'X #:G4 'Y #:G5) ; (XY #:G1 #:G2 #:G3 'X #:G4 'Y #:G5) In the mixed case, when some of the keyword arguments are constant, the corresponding expansion can be optimized to omit the init forms that are not needed: > (get-setf-expansion '(xy 3 a 0 'y 0)) (#:G1 #:G2 #:G3 #:G4 #:G5) ; (3 A 0 0 (ZERO)) ; (#:G6) ; ((LAMBDA (&KEY ((X #:G7)) ((Y #:G8))) (SET-XY #:G6 #:G1 'X #:G7 'Y #:G8)) #:G2 #:G3 'Y #:G4 'X #:G5) ; (XY #:G1 #:G2 #:G3 'Y #:G4 'X #:G5) This was the hard part. Actually implementing it was easy, then. Done and pushed (including your test case). Bruno |
From: Translation P. R. <ro...@tr...> - 2019-06-03 23:17:17
|
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'clisp' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/clisp/de.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/clisp/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/clisp.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. <coo...@tr...> |
From: Reini U. <rei...@gm...> - 2019-04-04 17:49:40
|
> On Mar 22, 2019, at 3:09 PM, KIRIYAMA Kazuhiko <ki...@kx...> wrote: > > checking whether mknod can create fifo without root privileges... configure: error: in `/var/ports/work/var/ports/jdtpkx/lang/clisp/work/clisp-df3b9f6fdcff22832898e89a989eb499c0f842ed-df3b9f6fdcff22832898e89a989eb499c0f842ed/src': > configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check) > See `config.log' for more details > ===> Script "configure" failed unexpectedly. > Please report the problem to kiri@TrueFC.org [maintainer] and attach the > "/var/ports/work/var/ports/jdtpkx/lang/clisp/work/clisp-df3b9f6fdcff22832898e89a989eb499c0f842ed-df3b9f6fdcff22832898e89a989eb499c0f842ed/config.log" > including the output of the failure of your make command. Also, it might be > a good idea to provide an overview of all packages installed on your system > (e.g. a /usr/local/sbin/pkg-static info -g -Ea). > *** Error code 1 > > Stop. > make: stopped in /var/ports/jdtpkx/lang/clisp > root@jdtpkx:/var/ports/jdtpkx/lang/clisp # > > > My build environment is: > > FreeBSD jdtpkx 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r339677M: Fri Oct 26 14:56:49 JST 2018 root@msrvkx:/usr/obj/usr/src/amd64.amd64/sys/XIJ amd64 > > config.log is in [2] and my working clisp port is on [3]. > > Is there any suggestions? Sure, read the error message and act accordingly. --- Reini Urban ru...@cp... |
From: <Joe...@t-...> - 2019-03-26 09:03:08
|
Hi, Don Cohen wrote: >This suggests that someone who actually wants to plant malware >into a system should concentrate on the configuration scripts. Indeed. And that's what has been done/exploited during the last years. That's also why distributions react promptly to package signature issues. But there's much more to it than just signatures. See what happens in the JavaScript ocean. >So if the entire process were inside a chroot or vm or container >you wouldn't mind root access, right? Yes. My focus was reliability, not security. For instance, Common Lisp allows :if-[not-]exists :rename etc. Would you really want a root Lisp to rename some devices in /dev/XYZ? Likewise, configuration scripts have been known to change or delete more than they were supposed to do. Don't help them by running as root. If your jail ends up in a bad state following the build process, it doesn't matter, just throw it away. Always. Also, think about how the clisp binary is covered by lots of tests. How are configuration scripts tested? I solely see field testing, i.e. angry users report that the stupid thing did bad things to their environment (or gentle distribution maintainers report that it doesn't work as expected). From a security POV: many configuration scripts do really weird things. Running them as root appears insane to me. >I'd include running the tests as part of build, and I recall a few >tests that do require root in order to pass. To me that's a second level. Think about cross-compilation. One the first system you can at most compile. Running tests requires a second system. Perhaps one should install first, then run the tests? Wouldn't that be more relevant? To me, running tests is part of QA, a necessary step prior to releasing a package, but not necessarily on the compilation host. >I suppose you'd recommend never running lisp as root. No, the caveat is as above. Then I trust our good old clisp more than perl or CPython. And those others run constantly as root on many distributions. >For that matter, you probably don't recommend running anything else >as root (which I also do all the time). My Linux TV-HDD-recorder runs nearly everything as root. I feel it's not ideal, but that's how the designers conceived it. >I think in at least one case that user has only ever been used >to do one thing: build clisp because the script doesn't want to run as root! :-) Probably many people think: "it works (or appears to), so why not do it?" And "why are the maintainers restricting my freedom of choice?" Regards, Jörg |
From: Pascal B. <pj...@in...> - 2019-03-25 19:45:13
|
> On 25 Mar 2019, at 15:28, Don Cohen <don...@is...> wrote: > > Joe...@t-... writes: > >> - During configuration, compilation & build NOTHING should require >> root access. > > I'm not sure how to interpret "should" or "build" in that sentence. > I'd include running the tests as part of build, and I recall a few > tests that do require root in order to pass. > (One that comes to mind is creating raw sockets.) > >> Generally, you configure and build SW as a low-privilege user, best >> inside a jail, > > So if the entire process were inside a chroot or vm or container > you wouldn't mind root access, right? Perhaps this would be a > good way to at least run the tests above. > >> so the poor configuration scripts can't destroy your system >> inadvertently. Once that is over, you install, i.e. copy few >> selected files to privileged locations as root. > > It's interesting that we're supposed to trust the software that > was built from the scripts that we're not supposed to trust. > I do get your point that the configuration scripts are likely > to be written with less attention than the code intended to run > in the built system. This suggests that someone who actually > wants to plant malware into a system should concentrate on the > configuration scripts. > > I suppose the testing code falls somewhere between the configuration > script code and the code intended to run in the built system in terms > of attention. If that testing code has to run as root, that would > make it a good target as well. > > I suppose you'd recommend never running lisp as root. > (It turns out I do that all the time.) > For that matter, you probably don't recommend running anything else > as root (which I also do all the time). > Perhaps this view makes more sense in the case where a single machine > is shared by many users who all rely on it - the common case before > computers became "personal" (starting about 40 years ago). Yes. You can run system processes under system accounts. Only a few programs need to be started as root, but they will fallback to a user account as soon as they’re done initializing (eg. listening on a reserved port). > Many of the machines I use now have users other than root only because > they were created by default. I think in at least one case that > user has only ever been used to do one thing: build clisp because > the script doesn't want to run as root! You could do that when computed didn’t have interfaces to the exterior world. When you typed each byte of all the programs you ran on your computer. But as soon as you started to load programs coming from somewhere else (eg. as punched cards or magnetic tapes), and much more when the computer is connected to the internet, you cannot trust the code anymore. You would have to audit all the sources, and all the compiler binaries! see: http://cm.bell-labs.com/ who/ken/trust.html and: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf <https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf> -- __Pascal J. Bourguignon__ |
From: <don...@is...> - 2019-03-25 14:28:46
|
Joe...@t-... writes: > - During configuration, compilation & build NOTHING should require > root access. I'm not sure how to interpret "should" or "build" in that sentence. I'd include running the tests as part of build, and I recall a few tests that do require root in order to pass. (One that comes to mind is creating raw sockets.) > Generally, you configure and build SW as a low-privilege user, best > inside a jail, So if the entire process were inside a chroot or vm or container you wouldn't mind root access, right? Perhaps this would be a good way to at least run the tests above. > so the poor configuration scripts can't destroy your system > inadvertently. Once that is over, you install, i.e. copy few > selected files to privileged locations as root. It's interesting that we're supposed to trust the software that was built from the scripts that we're not supposed to trust. I do get your point that the configuration scripts are likely to be written with less attention than the code intended to run in the built system. This suggests that someone who actually wants to plant malware into a system should concentrate on the configuration scripts. I suppose the testing code falls somewhere between the configuration script code and the code intended to run in the built system in terms of attention. If that testing code has to run as root, that would make it a good target as well. I suppose you'd recommend never running lisp as root. (It turns out I do that all the time.) For that matter, you probably don't recommend running anything else as root (which I also do all the time). Perhaps this view makes more sense in the case where a single machine is shared by many users who all rely on it - the common case before computers became "personal" (starting about 40 years ago). Many of the machines I use now have users other than root only because they were created by default. I think in at least one case that user has only ever been used to do one thing: build clisp because the script doesn't want to run as root! |
From: <Joe...@t-...> - 2019-03-25 10:49:38
|
Hi, I'm not familiar with *BSD build environment. >> Yes. Don 't run configure as root. >Why ? In FreeBSD install target set to DESTDIR which would be local working directory so called "STAGEDIR". You should dissociate configuration & build from INSTALL. - Installing typically requires root authorizations to write to protected directories. - During configuration, compilation & build NOTHING should require root access. Listen, do you really trust generally poorly written shell scripts, M4 macros, or all those write-once-throw-away programs to be able to behave correctly in a root environment? Do you trust upstream well enough to test and debug the poor detection SW well enough to not produce a rm -rf /"" when e.g. some path is empty or contains spaces? Trusting configuration scripts is essentially very naïve. Would you ever execute `curl http://random.com... | sudo sh` ? Generally, you configure and build SW as a low-privilege user, best inside a jail, so the poor configuration scripts can't destroy your system inadvertently. Once that is over, you install, i.e. copy few selected files to privileged locations as root. Back then, I'd even read the install script and install executable and manpages by hand, without ever executing `make` as root. Of course, that doesn't scale and it's not how distributions or automated install processes work. Regards, Jörg |
From: KIRIYAMA K. <ki...@kx...> - 2019-03-23 01:28:07
|
At Fri, 22 Mar 2019 15:27:34 +0100, Pascal Bourguignon wrote: > > [1 <text/plain; utf-8 (quoted-printable)>] > > [2 <text/html; utf-8 (quoted-printable)>] > > > > > > On 22 Mar 2019, at 15:09, KIRIYAMA Kazuhiko <[[ki...@kx...]]> wrote: > > > > Hi all, > > I try to build clisp port on FreeBSD 13.0-CURRENT. I > download latest clisp code from gitlab [1] and configure > with that but failed: > > root@jdtpkx:/var/ports/jdtpkx/lang/clisp # make configure > […] > configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment > to bypass this check) > […] > Is there any suggetions? > > > > > > > Yes. Don’t run configure as root. Why ? In FreeBSD install target set to DESTDIR which would be local working directory so called "STAGEDIR". Is there any stuffs installed to public direcitories like /etc or /usr/* in configure stage ? > > > > -- > > __Pascal J. Bourguignon__ > > > > > --- KIRIYAMA Kazuhiko |
From: Pascal B. <pj...@in...> - 2019-03-22 14:28:02
|
> On 22 Mar 2019, at 15:09, KIRIYAMA Kazuhiko <ki...@kx...> wrote: > > > Hi all, > > I try to build clisp port on FreeBSD 13.0-CURRENT. I > download latest clisp code from gitlab [1] and configure > with that but failed: > > root@jdtpkx:/var/ports/jdtpkx/lang/clisp # make configure > […] > configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check) > […] > Is there any suggetions? Yes. Don’t run configure as root. -- __Pascal J. Bourguignon__ |
From: KIRIYAMA K. <ki...@kx...> - 2019-03-22 14:09:51
|
Hi all, I try to build clisp port on FreeBSD 13.0-CURRENT. I download latest clisp code from gitlab [1] and configure with that but failed: root@jdtpkx:/var/ports/jdtpkx/lang/clisp # make configure ===> License GPLv2 accepted by the user ===> clisp-2.49.93+ depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by clisp-2.49.93+ for building ===> Extracting for clisp-2.49.93+ => SHA256 Checksum OK for gnu-clisp-clisp-df3b9f6fdcff22832898e89a989eb499c0f842ed_GL0.tar.gz. ===> Patching for clisp-2.49.93+ ===> Applying FreeBSD patches for clisp-2.49.93+ ===> clisp-2.49.93+ depends on file: /usr/local/lib/libavcall.a - found ===> clisp-2.49.93+ depends on executable: gcc7 - found ===> clisp-2.49.93+ depends on file: /usr/local/bin/as - found ===> clisp-2.49.93+ depends on shared library: libreadline.so - found (/usr/local/lib/libreadline.so) ===> clisp-2.49.93+ depends on shared library: libsigsegv.so - found (/usr/local/lib/libsigsegv.so) ===> Configuring for clisp-2.49.93+ executing ../src/configure --prefix=/usr/local --mandir=/usr/local/man --elispdir=/usr/local/share/clisp/emacs --vimdir=/usr/local/share/clisp/vim --docdir=/usr/local/share/doc/clisp --with-libiconv=/usr --disable-mmap --disable-nls --with-module=rawsock --with-module=wildcard --with-module=zlib configure: creating cache config.cache checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes configure: ** check for host type checking build system type... x86_64-unknown-freebsd13.0 checking host system type... x86_64-unknown-freebsd13.0 checking how to remove colons from paths... echo $x configure: ** checks for programs checking for gcc... gcc7 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc7 accepts -g... yes checking for gcc7 option to accept ISO C89... none needed checking whether gcc7 understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of gcc7... gcc3 checking how to run the C preprocessor... cpp7 checking for windres... no checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking for Minix Amsterdam compiler... no checking for ar... ar checking for ranlib... ranlib checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for ld used by gcc7... /usr/local/bin/ld checking if the linker (/usr/local/bin/ld) is GNU ld... yes checking whether make sets $(MAKE)... (cached) yes checking how to make hard links... ln checking whether ln -s works... yes checking how to make hard links to symlinks... ln checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for ld used by gcc7... /usr/local/bin/ld checking if the linker (/usr/local/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/local/bin/nm -B checking the name lister (/usr/local/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking how to convert x86_64-unknown-freebsd13.0 file names to x86_64-unknown-freebsd13.0 format... func_convert_file_noop checking how to convert x86_64-unknown-freebsd13.0 file names to toolchain format... func_convert_file_noop checking for /usr/local/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... dlltool checking how to associate runtime and link libraries... printf %s\n checking for archiver @FILE support... no checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/local/bin/nm -B output from gcc7 object... ok checking for sysroot... no checking for a working dd... /bin/dd checking how to truncate binary pipes... /bin/dd bs=4096 count=1 checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if gcc7 supports -fno-rtti -fno-exceptions... no checking for gcc7 option to produce PIC... -fPIC -DPIC checking if gcc7 PIC flag -fPIC -DPIC works... yes checking if gcc7 static flag -static works... yes checking if gcc7 supports -c -o file.o... yes checking if gcc7 supports -c -o file.o... (cached) yes checking whether the gcc7 linker (/usr/local/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... freebsd13.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for groff... no checking for ps2pdf... no checking for gzip... gzip configure: ** checks for system features checking for special C compiler options needed for large files... (cached) no checking for _FILE_OFFSET_BITS value needed for large files... (cached) no checking whether using GNU C... yes checking whether using SUNPRO C... no checking whether using C++... no checking whether CPP likes empty macro arguments... yes checking whether C symbols are prefixed with underscore at the linker level... no checking whether CC works at all... yes configure: ** check for add-ons checking for sys/socket.h... yes checking for arpa/inet.h... yes checking for features.h... no checking for unistd.h... (cached) yes checking for wctype.h... yes checking for sys/param.h... yes checking for netdb.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for langinfo.h... yes checking for limits.h... yes checking for xlocale.h... yes checking for sys/mman.h... yes checking for malloc.h... no checking for sys/select.h... yes checking for sys/stat.h... (cached) yes checking for wchar.h... yes checking for stdint.h... (cached) yes checking for strings.h... (cached) yes checking for sys/ioctl.h... yes checking for sys/uio.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for crtdefs.h... no checking whether the preprocessor supports include_next... yes checking whether system header files limit the line length... no checking whether <sys/socket.h> is self-contained... yes checking for shutdown... yes checking whether <sys/socket.h> defines the SHUT_* macros... yes checking for struct sockaddr_storage... yes checking for sa_family_t... yes checking for struct sockaddr_storage.ss_family... yes checking whether socket is declared without a macro... yes checking whether connect is declared without a macro... yes checking whether accept is declared without a macro... yes checking whether bind is declared without a macro... yes checking whether getpeername is declared without a macro... yes checking whether getsockname is declared without a macro... yes checking whether getsockopt is declared without a macro... yes checking whether listen is declared without a macro... yes checking whether recv is declared without a macro... yes checking whether send is declared without a macro... yes checking whether recvfrom is declared without a macro... yes checking whether sendto is declared without a macro... yes checking whether setsockopt is declared without a macro... yes checking whether shutdown is declared without a macro... yes checking whether accept4 is declared without a macro... yes checking for size_t... yes checking for working alloca.h... no checking for alloca... yes checking whether <wchar.h> uses 'inline' correctly... yes checking for btowc... yes checking for _set_invalid_parameter_handler... no checking for symlink... yes checking for isblank... yes checking for iswctype... yes checking for mbsrtowcs... yes checking for mempcpy... no checking for wmemchr... yes checking for wmemcpy... yes checking for wmempcpy... no checking for gettimeofday... yes checking for readlink... yes checking for lstat... yes checking for mbsinit... yes checking for mbrtowc... yes checking for mprotect... yes checking for mkfifo... yes checking for mknod... yes checking for mkstemp... yes checking for tzset... yes checking for nl_langinfo... yes checking for setenv... yes checking for strdup... yes checking for strerror_r... yes checking for __xpg_strerror_r... no checking for catgets... yes checking for snprintf... yes checking for strptime... yes checking for localtime_r... yes checking for timegm... yes checking for mquery... no checking for pstat_getprocvm... no checking for wcrtomb... yes checking for iswcntrl... yes checking for nl_langinfo and CODESET... yes checking for a traditional french locale... fr_FR.ISO8859-1 checking whether byte ordering is bigendian... no checking if environ is properly declared... no checking for complete errno.h... yes checking for working fcntl.h... no (bad O_NOATIME) checking for pid_t... yes checking for mode_t... yes checking for mbstate_t... yes checking for C/C++ restrict keyword... __restrict checking for struct timeval... yes checking for wide-enough struct timeval.tv_sec member... yes checking whether gettimeofday is declared without a macro... yes checking host CPU and C ABI... x86_64 checking for shared library run path origin... done checking for the common suffixes of directories in the library search path... lib,lib checking for iconv... yes checking for working iconv... yes checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for IPv4 sockets... yes checking for IPv6 sockets... yes checking whether included libunistring is requested... no checking for libunistring... no, consider installing GNU libunistring checking whether limits.h has ULLONG_WIDTH etc.... no checking whether getc_unlocked is declared... yes checking whether we are using the GNU C Library >= 2.1 or uClibc... no checking for wchar_t... yes checking for max_align_t... yes checking whether NULL can be used in arbitrary expressions... yes checking whether imported symbols can be declared weak... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for pthread_kill in -lpthread... yes checking for multithread API to use... posix checking whether lstat correctly handles trailing slash... yes checking whether malloc, realloc, calloc are POSIX compliant... yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for unsigned long long int... yes checking for long long int... yes checking for a traditional japanese locale... ja_JP.eucJP checking for a transitional chinese locale... zh_CN.GB18030 checking for a french Unicode locale... fr_FR.UTF-8 checking for mmap... yes checking for MAP_ANONYMOUS... yes checking whether memchr works... yes checking whether time_t is signed... yes checking whether alarm is declared... yes checking for working mktime... no checking whether struct tm is in sys/time.h or time.h... time.h checking for struct tm.tm_zone... yes checking for struct tm.tm_gmtoff... yes checking for inline... inline checking whether <sys/select.h> is self-contained... yes checking whether pselect is declared without a macro... yes checking whether select is declared without a macro... yes checking for library containing setsockopt... none needed checking whether setenv is declared... yes checking search.h usability... yes checking search.h presence... yes checking for search.h... yes checking for tsearch... yes checking for sigset_t... yes checking for uid_t in sys/types.h... yes checking whether stat file-mode macros are broken... no checking for nlink_t... yes checking whether fchmodat is declared without a macro... yes checking whether fstat is declared without a macro... yes checking whether fstatat is declared without a macro... yes checking whether futimens is declared without a macro... yes checking whether lchmod is declared without a macro... yes checking whether lstat is declared without a macro... yes checking whether mkdirat is declared without a macro... yes checking whether mkfifo is declared without a macro... yes checking whether mkfifoat is declared without a macro... yes checking whether mknod is declared without a macro... yes checking whether mknodat is declared without a macro... yes checking whether stat is declared without a macro... yes checking whether utimensat is declared without a macro... yes checking for stdbool.h that conforms to C99... yes checking for _Bool... yes checking for wint_t... yes checking whether wint_t is too small... no checking whether stdint.h conforms to C99... yes checking whether stdint.h predates C++11... no checking whether stdint.h has UINTMAX_WIDTH etc.... no checking whether strdup is declared... yes checking whether strerror(0) succeeds... yes checking for strerror_r with POSIX signature... yes checking whether strerror_r works... yes checking whether strerror_r is declared... yes checking whether ffsl is declared without a macro... yes checking whether ffsll is declared without a macro... yes checking whether memmem is declared without a macro... yes checking whether mempcpy is declared without a macro... no checking whether memrchr is declared without a macro... yes checking whether rawmemchr is declared without a macro... no checking whether stpcpy is declared without a macro... yes checking whether stpncpy is declared without a macro... yes checking whether strchrnul is declared without a macro... yes checking whether strdup is declared without a macro... yes checking whether strncat is declared without a macro... yes checking whether strndup is declared without a macro... yes checking whether strnlen is declared without a macro... yes checking whether strpbrk is declared without a macro... yes checking whether strsep is declared without a macro... yes checking whether strcasestr is declared without a macro... yes checking whether strtok_r is declared without a macro... yes checking whether strerror_r is declared without a macro... yes checking whether strsignal is declared without a macro... yes checking whether strverscmp is declared without a macro... no checking whether ffs is declared without a macro... yes checking whether strcasecmp is declared without a macro... yes checking whether strncasecmp is declared without a macro... yes checking for struct timespec in <time.h>... yes checking whether unsetenv is declared... yes checking whether inet_ntop is declared without a macro... no checking whether inet_pton is declared without a macro... no checking whether btowc(0) is correct... yes checking whether btowc(EOF) is correct... yes checking for __builtin_expect... yes checking for strtod_l... yes checking whether dup2 works... yes checking whether fcntl is declared without a macro... yes checking whether openat is declared without a macro... yes checking for flexible array member... yes checking for working GNU fnmatch... no checking whether isblank is declared... yes checking whether isblank is declared... (cached) yes checking for gethostname... yes checking for HOST_NAME_MAX... 256 checking for getloadavg... yes checking sys/loadavg.h usability... no checking sys/loadavg.h presence... no checking for sys/loadavg.h... no checking whether getloadavg is declared... yes checking for getpagesize... yes checking whether getpagesize is declared... yes checking whether gettimeofday clobbers localtime buffer... no checking for gettimeofday with POSIX signature... almost checking for library containing inet_ntop... none required checking whether inet_ntop is declared... yes checking for library containing inet_pton... none required checking whether inet_pton is declared... yes checking for ioctl... yes checking for ioctl with POSIX signature... no checking whether langinfo.h defines CODESET... yes checking whether langinfo.h defines T_FMT_AMPM... yes checking whether langinfo.h defines ALTMON_1... yes checking whether langinfo.h defines ERA... yes checking whether langinfo.h defines YESEXPR... yes checking whether nl_langinfo is declared without a macro... yes checking for libsigsegv... yes checking how to link with libsigsegv... /usr/local/lib/libsigsegv.so -Wl,-rpath -Wl,/usr/local/lib checking whether to use the included libunistring... yes checking for __xpg4... no checking whether link(2) dereferences a symlink... yes checking whether locale.h conforms to POSIX:2001... yes checking whether locale.h defines locale_t... yes checking whether struct lconv is properly defined... yes checking whether setlocale is declared without a macro... yes checking whether duplocale is declared without a macro... yes checking for pthread_rwlock_t... yes checking whether pthread_rwlock_rdlock prefers a writer to a reader... yes checking whether mbrtowc handles incomplete characters... yes checking whether mbrtowc works as well as mbtowc... yes checking whether mbrtowc handles a NULL pwc argument... yes checking whether mbrtowc handles a NULL string argument... yes checking whether mbrtowc has a correct return value... yes checking whether mbrtowc returns 0 when parsing a NUL character... yes checking whether mbrtowc works on empty input... yes checking whether the C locale is free of encoding errors... yes checking whether mbrtowc handles incomplete characters... (cached) yes checking whether mbrtowc works as well as mbtowc... (cached) yes checking whether mbrtowc handles incomplete characters... (cached) yes checking whether mbrtowc works as well as mbtowc... (cached) yes checking whether mbsrtowcs works... yes checking for mkdtemp... yes checking whether mkfifo rejects trailing slashes... yes checking whether mknod can create fifo without root privileges... configure: error: in `/var/ports/work/var/ports/jdtpkx/lang/clisp/work/clisp-df3b9f6fdcff22832898e89a989eb499c0f842ed-df3b9f6fdcff22832898e89a989eb499c0f842ed/src': configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check) See `config.log' for more details ===> Script "configure" failed unexpectedly. Please report the problem to kiri@TrueFC.org [maintainer] and attach the "/var/ports/work/var/ports/jdtpkx/lang/clisp/work/clisp-df3b9f6fdcff22832898e89a989eb499c0f842ed-df3b9f6fdcff22832898e89a989eb499c0f842ed/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make: stopped in /var/ports/jdtpkx/lang/clisp root@jdtpkx:/var/ports/jdtpkx/lang/clisp # My build environment is: FreeBSD jdtpkx 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r339677M: Fri Oct 26 14:56:49 JST 2018 root@msrvkx:/usr/obj/usr/src/amd64.amd64/sys/XIJ amd64 root@jdtpkx:~ # config.log is in [2] and my working clisp port is on [3]. Is there any suggetions? Regards [1] https://gitlab.com/gnu-clisp/clisp [2] http://www.truefc.org/~kiri/freebsd/ports/config.log [3] https://github.com/TrueFC/ports/blob/486173/lang/clisp |
From: <Joe...@t-...> - 2019-03-19 10:47:06
|
Hi, Regarding ASDF, I remember that Faré (François-René ÐVB Rideau) wrote about it here, cf. 2017-01-23, but I can't remember the details, e.g. whether he asked for the integration of a newer version or to leave it out of the core, so users can update it independently, without conflicts about locked packages. Sorry, Jörg |
From: <don...@is...> - 2019-03-18 19:41:08
|
Pascal Bourguignon writes: > ;;; This is ASDF 2.26: Another System Definition Facility. > Perhaps I downloaded it from the asdf repository, I don't remember. Part of my complaint is that when I look up asdf on line I really SHOULD find a link to download the current asdf.lisp file. I don't. The best I was able to find was downloading a zip file, unzipping it and doing make to produce this file. And finding the zip file to download and determining what to do were not all that easy either. |
From: <don...@is...> - 2019-03-18 17:31:45
|
Pascal Bourguignon writes: > > I don't observe any problem: > [1]> (load "quicklisp/asdf.lisp") Where did this quicklisp/asdf.lisp file come from? |
From: <don...@is...> - 2019-03-18 16:24:22
|
When I went searching for how to get asdf in clisp I ran across https://clisp.sourceforge.io/beta/impnotes/ for CLISP version 2.49.93+ Whereas, in my git directory what I see is impnotes for version 2.49.60+ Even though version.sh says VERSION_NUMBER=2.49.93+ RELEASE_DATE=2018-02-18 # in "date +%F" format Is there a beta branch, or beta repo? Should I be using it? Also, is there some intent (in beta code that I don't yet have) to include asdf in clisp? I notice in sbcl, for example, (require "ASDF") works. Currently it seems to me (now that I've managed to do it) unreasonably difficult to get asdf into clisp. (But I think that's the fault of asdf.) |
From: <don...@is...> - 2019-03-14 00:09:02
|
I'm finally about to try this, and I realize that I don't know what to do with these sanitize settings. I'm guessing this line: ./configure CC='gcc -m64' --with-threads=POSIX_THREADS --disable-maintainer-mode --with-debug --with-module=rawsock build-mt should be changed with some additional stuff in the CC=... ? Also, was this for some particular shell? If I'm using bash what should I do? And is the sanitize_ld a gcc flag or does it go somewhere else? And finally, I'm guessing that the result is going to be thousands of warnings that I probably won't understand or know how to fix. Is that right? (There are already plenty of warnings in the build transcript BTW. I've been assuming those don't have to be fixed.) So should I post the output on this list? Pascal Bourguignon wrote (almost a month ago): > Now, perhaps it would be a little difficult to apply to the sources > of clisp, (would valgrind be appliable?), but I would start by > compiling with a recent gcc (eg. gcc-8.2) using a whole complement > of -fsanitize options, and correct all the problems found there > first. I'd suggest the following as a basis. > > sanitize_ld=( > -fsanitize=leak > ) > > sanitize_cc=( > -fsanitize=address > -fsanitize=null > -fsanitize=bounds > -fsanitize=vla-bound > -fsanitize=object-size > > -fsanitize=unreachable > -fsanitize=return # C++ only > > -fsanitize=shift > -fsanitize=shift-exponent > -fsanitize=shift-base > -fsanitize=integer-divide-by-zero > -fsanitize=signed-integer-overflow > > -fsanitize=float-divide-by-zero > -fsanitize=float-cast-overflow > -fsanitize=nonnull-attribute > -fsanitize=returns-nonnull-attribute > -fsanitize=bool > -fsanitize=enum > -fsanitize=vptr # C++ only > > > -fsanitize-address-use-after-scope > -fsanitize-undefined-trap-on-error > -fstack-protector-all > -fstack-check > ) > > > Once the program can be compiled and run successfully with those correction, to debug the remaining segfault, you would run it under gdb to be able to inspect the stack when the segfault occur, and try to locate the place in the source where it occured. This may also be done on the core file, but it is easier to debug in a live process. > > -- > __Pascal J. Bourguignon__ > > > > |
From: Pascal B. <pj...@in...> - 2019-02-14 23:54:15
|
> On 14 Feb 2019, at 21:20, Don Cohen <don...@is...> wrote: > > Pascal Bourguignon writes: > >> Specifically, any function in the CL package can be called >> internally thru other mechanisms than provided to the user code: >> the C code can call directly the C implementation of the CL >> functions, without passing thru the CL API. Hence TRACE is allowed >> NOT to work in those cases! > ... > >> Instead, you can use gdb to break on those C functions. > > I suppose that further, internal functions could be called from other > functions, e.g., intern might call internal functions in hashtabl.d, > so it wouldn't be good enough to break only the external functions. > > Is the current theory that only the file hashtabl.d has to be fixed > for MT ? Would it be worth while to try my test with a gdb break on > every function in that file? > > Does anyone have any other suggestions for trying to track down the > cause of a segfault once I can reproduce it? Now, perhaps it would be a little difficult to apply to the sources of clisp, (would valgrind be appliable?), but I would start by compiling with a recent gcc (eg. gcc-8.2) using a whole complement of -fsanitize options, and correct all the problems found there first. I’d suggest the following as a basis. sanitize_ld=( -fsanitize=leak ) sanitize_cc=( -fsanitize=address -fsanitize=null -fsanitize=bounds -fsanitize=vla-bound -fsanitize=object-size -fsanitize=unreachable -fsanitize=return # C++ only -fsanitize=shift -fsanitize=shift-exponent -fsanitize=shift-base -fsanitize=integer-divide-by-zero -fsanitize=signed-integer-overflow -fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -fsanitize=nonnull-attribute -fsanitize=returns-nonnull-attribute -fsanitize=bool -fsanitize=enum -fsanitize=vptr # C++ only -fsanitize-address-use-after-scope -fsanitize-undefined-trap-on-error -fstack-protector-all -fstack-check ) Once the program can be compiled and run successfully with those correction, to debug the remaining segfault, you would run it under gdb to be able to inspect the stack when the segfault occur, and try to locate the place in the source where it occured. This may also be done on the core file, but it is easier to debug in a live process. -- __Pascal J. Bourguignon__ |
From: <don...@is...> - 2019-02-14 20:20:57
|
Pascal Bourguignon writes: > Specifically, any function in the CL package can be called > internally thru other mechanisms than provided to the user code: > the C code can call directly the C implementation of the CL > functions, without passing thru the CL API. Hence TRACE is allowed > NOT to work in those cases! ... > Instead, you can use gdb to break on those C functions. I suppose that further, internal functions could be called from other functions, e.g., intern might call internal functions in hashtabl.d, so it wouldn't be good enough to break only the external functions. Is the current theory that only the file hashtabl.d has to be fixed for MT ? Would it be worth while to try my test with a gdb break on every function in that file? Does anyone have any other suggestions for trying to track down the cause of a segfault once I can reproduce it? |
From: Pascal B. <pj...@in...> - 2019-02-14 00:30:24
|
> On 14 Feb 2019, at 00:50, Don Cohen <don...@is...> wrote: > > > I just followed the procedure described in the message sent to this > list on 2018-09-20 with one addition: > before the defun causing the segfault I trace every function in the > hash table section of the hyperspec. > (MAKE-HASH-TABLE HASH-TABLE-P HASH-TABLE-COUNT HASH-TABLE-REHASH-SIZE > HASH-TABLE-REHASH-THRESHOLD HASH-TABLE-SIZE HASH-TABLE-TEST GETHASH REMHASH > MAPHASH CLRHASH SXHASH WITH-HASH-TABLE-ITERATOR) > > None of these appear to be called when I do the defun and get the segfault. > > Does that show that this problem is unrelated to hashing or is there still > some way hashing could be involved? I’ve not looked at the hash table code, but in general for implementations written in C (eg. emacs lisp), you have to consider two levels: the lisp level at which CL:TRACE will work, and the C level. That’s where the rules from 11.1.2.1.2 come into play http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm <http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm> Specifically, any function in the CL package can be called internally thru other mechanisms than provided to the user code: the C code can call directly the C implementation of the CL functions, without passing thru the CL API. Hence TRACE is allowed NOT to work in those cases! http://www.lispworks.com/documentation/HyperSpec/Body/m_tracec.htm#trace Instead, you can use gdb to break on those C functions. -- __Pascal J. Bourguignon__ |
From: <don...@is...> - 2019-02-13 23:50:11
|
I just followed the procedure described in the message sent to this list on 2018-09-20 with one addition: before the defun causing the segfault I trace every function in the hash table section of the hyperspec. (MAKE-HASH-TABLE HASH-TABLE-P HASH-TABLE-COUNT HASH-TABLE-REHASH-SIZE HASH-TABLE-REHASH-THRESHOLD HASH-TABLE-SIZE HASH-TABLE-TEST GETHASH REMHASH MAPHASH CLRHASH SXHASH WITH-HASH-TABLE-ITERATOR) None of these appear to be called when I do the defun and get the segfault. Does that show that this problem is unrelated to hashing or is there still some way hashing could be involved? |
From: Reini U. <rei...@gm...> - 2019-02-11 18:38:16
|
Other concurrency issues than with hashtables can generally occur with setting non-primitive values which exceed a native word. eg setting a 64bit value on a 32bit architecture, which is internally split into two setters. Or setting unaligned values, which also need to update two words. But out of my head I don't see such problems, and they can easily fixed by locks. Don Cohen <don...@is...> schrieb am Mo., 11. Feb. 2019, 17:19: > > I seem to be the one most interested in getting MT to work. > Sometimes I think maybe the only one interested. > > Here's my next idea: > > My impression is that developers think the ONLY problem left > is hashtables. I propose to test that by replacing hash > tables with alists. > > If that stopped the crashing I'd consider more seriously > trying to solve the hashing problem. > Otherwise I's hope to convince one of the current MT experts > to find (and fix?) whatever other problems I discover, or at > least help me to do so. > > My first question is whether the experts on this list think > that's a good idea, or have any alternate suggestions. > > I was hoping that the hashtable implementation contained a > special case that used alists for very small tables, and that > I could convert to alists by simply redefining "very small". > I started looking at the source in hashtabl.d and so far I > don't see what I was hoping for. > > My second question is (if the first one seems a good idea) > whether any experts have any advice on the easiest way to > go about the implementation. > > > _______________________________________________ > clisp-devel mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-devel > |
From: <don...@is...> - 2019-02-11 16:19:12
|
I seem to be the one most interested in getting MT to work. Sometimes I think maybe the only one interested. Here's my next idea: My impression is that developers think the ONLY problem left is hashtables. I propose to test that by replacing hash tables with alists. If that stopped the crashing I'd consider more seriously trying to solve the hashing problem. Otherwise I's hope to convince one of the current MT experts to find (and fix?) whatever other problems I discover, or at least help me to do so. My first question is whether the experts on this list think that's a good idea, or have any alternate suggestions. I was hoping that the hashtable implementation contained a special case that used alists for very small tables, and that I could convert to alists by simply redefining "very small". I started looking at the source in hashtabl.d and so far I don't see what I was hoping for. My second question is (if the first one seems a good idea) whether any experts have any advice on the easiest way to go about the implementation. |
From: Wolfgang D. <wol...@da...> - 2019-01-09 07:55:09
|
On 07.01.19 12:46, Reini Urban wrote: > not speaking for the maintainers: The main reason is that the GC changes > broke many platforms, and Win64 misses a libsigsegv port, 64bit. > Some month ago the main windows regressions were fixed, with some > additional fixes of mine, but it broke recently again. Thanks for the reply. A 32 bit version (the 'current' release is 32 bit only) is not possible too? It seems that the reason for my crosscompiling problems (that make boot works, but make with modules enabled not) is somewhere in my scripts, that needs more work; if I fix that and can create a full - working - Windows installer, would someone be interested in the code? > See my smokes at https://travis-ci.org/rurban/clisp/builds > and https://ci.appveyor.com/project/rurban/clisp/history > with my branches, and Don has also some regular smoking service. Sounds interesting, thanks for the link. Best regards, Wolfgang |
From: Vladimir S. <va...@on...> - 2019-01-07 19:27:12
|
With respect to CLISP maintainership, have things changed from the situation in 2015? https://sourceforge.net/p/clisp/mailman/message/34092572/ I know it takes a lot of effort to keep up with the constant breaking changes in Microsoft Windows and Mac OS X. Vladimir |