Menu
▾
▴
clisp-devel — closed list for developers and testers
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
(8) |
Nov
(28) |
Dec
(3) |
| 2025 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Blake M. <bl...@mc...> - 2017-01-01 17:19:50
|
I think step 1 is as follows. Get rid of the .d files! Start with .c files. Use as many macros as needed, but don't use .d files and processors. As a person with more than 25 years C experience, approaching the .d files is an unnecessary barrier. When a C programmer wants to look at CLISP, the first thing he sees is this wacko, foreign .d stuff. It's like having to learn a new language. I'd say: 1. Run it through all of the preprocessors to convert all of the .d files to .c files 2. With macros, clean up the .c files so that they are more reasonable. Then, when a new and interested C programmer first starts getting into CLISP he isn't put off right away. It must be doable and reasonable or most of the other lisp systems wouldn't be written in C. Again, I really like CLISP. I think simplifying the code base and build procedure would go a long way. Other comments about depending on standard libraries are a good next step. Just one guy's opinion. Blake McBride On Tue, Nov 29, 2016 at 1:55 PM, Sam Steingold <sd...@gn...> wrote: > Hi, > > > * Blake McBride <oy...@zp...zr> [2016-11-28 20:52:19 -0600]: > > > > Type 1: This system takes maximum advantage of the underlying platform > > facilities in order to provide the most functionality and be as fast > > as possible on the system it is running on. It achieves "portability" > > through many, many ifdef's or constructs that have the same effect. > > So, while the system is "portable" in the sense that it runs on a lot > > of systems, it only does so through many careful ifdef like facilities > > and complex build procedures. > > I think this is usually called "ported" rather than "portable". > IOW, "the porting work has been done" rather than "porting is easy". > > > Type 2: This system is portable because it only uses standard > > facilities that are broadly available on most platforms. Although > > there are ifdef constructs, they are seldom used. The system is > > simple to build because at largely depends on readily available, > > common facilities. > > I think is what is usually called "portable". > The point, I think, is that the ifdefs only come from autoconf, not from > hand-crafted tweaks. > > I think the general direction is to shift _most_ of the portability work > over to gnulib. > I.e., all the functionality is expected to be standard, maybe provided > by a gnulib layer. > > > 1. Getting every ounce of speed is not important. No one uses CLISP > > if speed is their primary concern. > > What matters is "fast enough" and functionality. > People use python a lot - so CLISP's problem is not speed. > The problem is that we don't have numpy, pandas, sklearn, matplotlib &c. > > > 2. It seems like development and support of CLISP is beginning to > > dwindle. If CLISP doesn't become Type 2, it'll quickly die as soon as > > updates to it cease - due to rapid bit rot. > > I have been whining about this for years. > The problem is that CLISP internals work required a C hacker - > and why would a C hacker be hacking a Lisp? > > > 3. On the other hand, if it does become Type 2, it could live on and > > be useful for a very long time with very minimal work. > > Agreed. > > > Given how far CLISP has come, and the variety of machines it readily > > builds on, rather than a course correction, perhaps CLISP could use a > > Type 2 portability fork. > > We already have this. > See "porting hints" at the end of clisp/unix/PLATFORMS - it explains how > to disable all the "advanced features". > > However, as usual, my general answer is > http://www.cygwin.com/acronyms/#PTC :-) > > > > -- > Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 > http://steingoldpsychology.com http://www.childpsy.net http://jij.org > http://memri.org http://thereligionofpeace.com http://honestreporting.com > Politically Correct Chess: Translucent VS. Transparent. > |
|
From: Blake M. <bl...@mc...> - 2016-11-30 03:07:34
|
On Tue, Nov 29, 2016 at 1:55 PM, Sam Steingold <sd...@gn...> wrote: > ...... > > We already have this. > See "porting hints" at the end of clisp/unix/PLATFORMS - it explains how > to disable all the "advanced features". I like that. Thanks! Blake |
|
From: <don...@is...> - 2016-11-29 22:06:09
|
I have nothing against improving portability, but I was a little surprised not to hear some disagreement on this point: > 2. It seems like development and support of CLISP is beginning to > dwindle. If CLISP doesn't become Type 2, it'll quickly die as soon > as updates to it cease - due to rapid bit rot. History suggests otherwise, in that development was essentially non-existent for several years. If anything it has picked up in the last few years. Of course there's also room for disagreement on what "quickly" means, and I get the impression that some people view clisp (and maybe even lisp) as long dead already. My view is that clisp is in no danger as long as we have virtual machines that can run old OS versions, which I now expect to be as long as there are computers. BTW I have plenty of code even older than clisp that still runs inside clisp (using compatibility layers to interpret older lisp dialects) and I fully expect that code to continue to be used into the distant future. |
|
From: Pascal B. <pj...@in...> - 2016-11-29 20:21:39
|
> On 29 Nov 2016, at 03:52, Blake McBride <bl...@mc...> wrote: > > I do not believe that CLISP is very portable. I know CLISP runs in a great number of environments, but I do not think that makes the system portable for the following reason. Being able to run in a lot of environments, and being portable, are not the same thing. For example, I will describe two different types of systems, both of which run in a lot of environments, but only one is portable in the sense I am trying to convey. > > Type 1: This system takes maximum advantage of the underlying platform facilities in order to provide the most functionality and be as fast as possible on the system it is running on. It achieves "portability" through many, many ifdef's or constructs that have the same effect. So, while the system is "portable" in the sense that it runs on a lot of systems, it only does so through many careful ifdef like facilities and complex build procedures. > > Type 2: This system is portable because it only uses standard facilities that are broadly available on most platforms. Although there are ifdef constructs, they are seldom used. The system is simple to build because at largely depends on readily available, common facilities. > > The advantage of Type 1 is that it runs faster and provides more functionality. > > The disadvantages of Type 1 are that it is really not portable, and it is very fragile. Although it may run on many systems at one point in time, it suffers very significantly from bit rot on nearly a monthly basis - making it high maintenance. It also isn't really portable because the amount of work it would take to get it to work in a new environment is very significant. > > Type 2 systems are really portable in the sense that they can be easily ported to a new environment, and they are much, much less subject to bit rot. > > Now, having said all that, I am of the somewhat ignorant opinion that CLISP is of Type 1. I say that because, over the years, I've seen how fragile and complex the build process is. I also say that because I've seen first hand how the system wouldn't build because I had some arcane library one revision too old or too new. You’re correct, in part. That is, the part of clisp that is written in C (clisp is written half in C, half in (a subset of) Common Lisp). > Speaking for myself alone, I would prefer CLISP to be Type 2 for the following reasons: > > 1. Getting every ounce of speed is not important. No one uses CLISP if speed is their primary concern. > > 2. It seems like development and support of CLISP is beginning to dwindle. If CLISP doesn't become Type 2, it'll quickly die as soon as updates to it cease - due to rapid bit rot. > > 3. On the other hand, if it does become Type 2, it could live on and be useful for a very long time with very minimal work. > > Given how far CLISP has come, and the variety of machines it readily builds on, rather than a course correction, perhaps CLISP could use a Type 2 portability fork. In general, I don't like when forks occur, but in this case, wanting to retain CLISP's current appeal while at the same time building something that can be easier to support and better withstand the changes with time. I agree. I guess we could say that clisp has 4 parts: - a virtual machine (implemented in C), - library (CL) functions written in C, - library (CL) functions written in Common Lisp, - a CL compiler targeting this VM (implemented in Common Lisp). http://www.clisp.org/impnotes/vm.html Only the virtual machine and the library functions written in C need to be portable (the rest is already portable (being more or less conforming Common Lisp code). And then, library functions written in C are not necessarily non “conforming" standard C. Provided with a set of C macros that expand to standard C, ISTM that they could be mostly standard C code. The #if/#ifdef/#ifndef are concentrated on a small number of files, the biggest ones being lispbibl.d, and the actual OS and processor API. for f in *.h *.d *.c *.lisp ; do printf "%5d %s\n" $(grep -e '# *\<if\(\>\|n?def\)' $f |wc -l) $f; done|sort -rn 585 lispbibl.d 259 stream.d 120 pathname.d 93 spvw.d 92 intelem.d 67 foreign.d 63 arisparc.d 53 arisparc64.d 51 eval.d 47 spvw_memfile.d 40 spvw_garcol.d 40 arilev1.d 38 arilev0.d 35 io.d 30 intlog.d 26 spvw_garcol_old.d 24 intmal.d 23 constsym.d 22 unix.d 22 lightning.c 21 charstrg.d 18 unixaux.d 18 spvw_circ.d 18 arimips.d 16 gmalloc.c 16 arimips64.d 13 time.d 13 spvw_global.d 13 socket.d 13 arilev1i.d 13 arilev1c.d 12 lfloat.d 11 spvw_allocate.d 10 intgcd.d 10 genclisph.d 10 constobj.d 10 _clisp.c 9 misc.d 9 intsqrt.d 9 debug.d 9 array.d 8 subr.d 8 spvw_sigsegv.d 8 spvw_mmap.d 8 predtype.d 8 hashtabl.d 8 error.d 8 encoding.d 7 spvw_heap.d 7 ari68020.d 6 win32aux.d 6 spvwtabf.d 6 spvw_space.d 6 spvw_sigwinch.d 6 spvw_sigpipe.d 6 lisparit.d 6 execname.c 6 dfloat.d 5 xthread.d 5 spvwtabs.d 5 spvw_sigcld.d 5 spvw_page.d 5 spvw_fault.d 5 spvw_debug.d 5 intdiv.d 5 int2adic.d 5 control.d 5 ari80386.msvc.c 5 ari80386.d 4 zthread.d 4 intserial.d 4 intprint.d 4 foreign1.lisp 4 bytecode.d 4 asmi386.h 3 weak.d 3 spvw_typealloc.d 3 spvw_sigterm.d 3 spvw_sigint.d 3 spvw_mark.d 3 realelem.d 3 package.d 3 intplus.d 3 flo_rest.d 3 ffloat.d 3 compelem.d 3 built.d 3 arihppa.d 2 spvw_genera3.d 2 sfloat.d 2 record.d 2 pseudofun.d 2 modules.c 2 list.d 2 aridecl.d 2 ariarm.d 1 win32.d 1 w32shell.c 1 symbol.d 1 spvwtabo.d 1 spvw_walk.d 1 spvw_module.d 1 spvw_genera1.d 1 spvw_gcmark.d 1 sp80386.msvc.c 1 sp80386.d 1 realtran.d 1 rational.d 1 floatparam.c 1 flo_konv.d 1 constobj_tl.d 1 arivaxunix.d 1 ari68000.d plus 200 source files without a #if/n/def. When compiling clisp to various targets, I find that the main difficulty is not in the clisp code itself, but rather in its dependencies such as libsigsegv and ffcall. clisp can work without them but with some important drop of features (safety and FFI). I’m not sure you could implement something like ffcall in standard C, much less libsigsegv. > Or, if not a fork, perhaps something like this: > > ./configure real-portable > make real-portable > > What this process leaves us with is a set of source files (not any object or executable files) that are as portable as can be. You can move the files almost anywhere and just type "make". Perhaps it incluses one header file with a small number of define's someone can select from. Would this just add yet another target, making it even more difficult to maintain? ;-) -- __Pascal J. Bourguignon__ |
|
From: Sam S. <sd...@gn...> - 2016-11-29 19:55:39
|
Hi, > * Blake McBride <oy...@zp...zr> [2016-11-28 20:52:19 -0600]: > > Type 1: This system takes maximum advantage of the underlying platform > facilities in order to provide the most functionality and be as fast > as possible on the system it is running on. It achieves "portability" > through many, many ifdef's or constructs that have the same effect. > So, while the system is "portable" in the sense that it runs on a lot > of systems, it only does so through many careful ifdef like facilities > and complex build procedures. I think this is usually called "ported" rather than "portable". IOW, "the porting work has been done" rather than "porting is easy". > Type 2: This system is portable because it only uses standard > facilities that are broadly available on most platforms. Although > there are ifdef constructs, they are seldom used. The system is > simple to build because at largely depends on readily available, > common facilities. I think is what is usually called "portable". The point, I think, is that the ifdefs only come from autoconf, not from hand-crafted tweaks. I think the general direction is to shift _most_ of the portability work over to gnulib. I.e., all the functionality is expected to be standard, maybe provided by a gnulib layer. > 1. Getting every ounce of speed is not important. No one uses CLISP > if speed is their primary concern. What matters is "fast enough" and functionality. People use python a lot - so CLISP's problem is not speed. The problem is that we don't have numpy, pandas, sklearn, matplotlib &c. > 2. It seems like development and support of CLISP is beginning to > dwindle. If CLISP doesn't become Type 2, it'll quickly die as soon as > updates to it cease - due to rapid bit rot. I have been whining about this for years. The problem is that CLISP internals work required a C hacker - and why would a C hacker be hacking a Lisp? > 3. On the other hand, if it does become Type 2, it could live on and > be useful for a very long time with very minimal work. Agreed. > Given how far CLISP has come, and the variety of machines it readily > builds on, rather than a course correction, perhaps CLISP could use a > Type 2 portability fork. We already have this. See "porting hints" at the end of clisp/unix/PLATFORMS - it explains how to disable all the "advanced features". However, as usual, my general answer is http://www.cygwin.com/acronyms/#PTC :-) -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://jij.org http://memri.org http://thereligionofpeace.com http://honestreporting.com Politically Correct Chess: Translucent VS. Transparent. |
|
From: Blake M. <bl...@mc...> - 2016-11-29 02:52:27
|
Greetings,
I have over 30 years experience in C, and many years playing with CLISP
(probably since its initial release). Although I have used CLISP, I have
never really gotten into its internals. Having been exposed to the mailing
list, a bit of experience building CLISP and tracking down rare
difficulties, I have formed some opinions which are not necessarily true.
Not having sufficient time to investigate the facts, I thought I would
share my opinions publicly in the hopes of constructive commentaries.
Let me start by saying that I deeply appreciate CLISP and the contributions
made by Bruno and many others. CLISP is perhaps my favorite lisp system,
and lisp is surely my favorite language.
The following are just impressions:
I do not believe that CLISP is very portable. I know CLISP runs in a great
number of environments, but I do not think that makes the system portable
for the following reason. Being able to run in a lot of environments, and
being portable, are not the same thing. For example, I will describe two
different types of systems, both of which run in a lot of environments, but
only one is portable in the sense I am trying to convey.
Type 1: This system takes maximum advantage of the underlying platform
facilities in order to provide the most functionality and be as fast as
possible on the system it is running on. It achieves "portability" through
many, many ifdef's or constructs that have the same effect. So, while the
system is "portable" in the sense that it runs on a lot of systems, it only
does so through many careful ifdef like facilities and complex build
procedures.
Type 2: This system is portable because it only uses standard facilities
that are broadly available on most platforms. Although there are ifdef
constructs, they are seldom used. The system is simple to build because at
largely depends on readily available, common facilities.
The advantage of Type 1 is that it runs faster and provides more
functionality.
The disadvantages of Type 1 are that it is really not portable, and it is
very fragile. Although it may run on many systems at one point in time, it
suffers very significantly from bit rot on nearly a monthly basis - making
it high maintenance. It also isn't really portable because the amount of
work it would take to get it to work in a new environment is very
significant.
Type 2 systems are really portable in the sense that they can be easily
ported to a new environment, and they are much, much less subject to bit
rot.
Now, having said all that, I am of the somewhat ignorant opinion that CLISP
is of Type 1. I say that because, over the years, I've seen how fragile
and complex the build process is. I also say that because I've seen first
hand how the system wouldn't build because I had some arcane library one
revision too old or too new.
Speaking for myself alone, I would prefer CLISP to be Type 2 for the
following reasons:
1. Getting every ounce of speed is not important. No one uses CLISP if
speed is their primary concern.
2. It seems like development and support of CLISP is beginning to
dwindle. If CLISP doesn't become Type 2, it'll quickly die as soon as
updates to it cease - due to rapid bit rot.
3. On the other hand, if it does become Type 2, it could live on and be
useful for a very long time with very minimal work.
Given how far CLISP has come, and the variety of machines it readily builds
on, rather than a course correction, perhaps CLISP could use a Type 2
portability fork. In general, I don't like when forks occur, but in this
case, wanting to retain CLISP's current appeal while at the same time
building something that can be easier to support and better withstand the
changes with time.
Or, if not a fork, perhaps something like this:
./configure real-portable
make real-portable
What this process leaves us with is a set of source files (not any object
or executable files) that are as portable as can be. You can move the
files almost anywhere and just type "make". Perhaps it incluses one header
file with a small number of define's someone can select from.
Well just some thoughts. I do appreciate CLISP, and I hope I haven't
offended anyone.
Blake McBride
|
|
From: <Joe...@t-...> - 2016-11-18 15:08:32
|
Hi, How comes this pops up now only? I see other SW packages fixed as early as 2009 (e.g. LP#418392 and https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks mentions Ubuntu Karmic and Lucid). How was the offending binary built? How was it tested? Jerry James wrote: >When I build clisp for Fedora, I use the -Wa,--noexecstack approach to keep that flag off, >but it would be great if the ffcall and clisp sources could be modified to include the >proper .note.GNU-stack when GNU tools are in use. Correct. Regards, Jörg |
|
From: Jerry J. <log...@gm...> - 2016-11-17 16:09:49
|
On Wed, Nov 16, 2016 at 9:58 PM, Sam Steingold <sd...@gn...> wrote: > Any chance you know what this means? > http://stackoverflow.com/q/40646703/850781 The GNU assembler assumes that assembly code might need an executable stack unless explicitly told otherwise. Here's how to tell it: https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks When I build clisp for Fedora, I use the -Wa,--noexecstack approach to keep that flag off, but it would be great if the ffcall and clisp sources could be modified to include the proper .note.GNU-stack when GNU tools are in use. Regards, -- Jerry James http://www.jamezone.org/ |
|
From: Sam S. <sd...@gn...> - 2016-11-17 04:59:02
|
Hi, Any chance you know what this means? http://stackoverflow.com/q/40646703/850781 Thanks -- Sam Steingold <http://sds.podval.org> <http://www.childpsy.net> <http://steingoldpsychology.com> |
|
From: Bruno H. <br...@cl...> - 2016-11-14 17:41:53
|
Jörg asked for explanations of this change.
2016-11-09 Bruno Haible <br...@cl...>
Fix a relevant gcc warning of type -Wclobbered.
* pathname.d (direntry_to_string): Use 'volatile' to disallow a
dangerous compiler optimization.
The function direntry_to_string contains a call to make_HANDLER_entry_frame
which expands to something that contains a setjmp() call. GCC does not guarantee
that the values of all C local variables of the function are the same when
the setjmp() call returns the second time. Therefore, if GCC detects that
our code uses some of these variables _after_ the setjmp() call, it warns
us about it.
Declaring a local variable 'volatile' is a way to tell GCC to allocate it in
the stack (rather than in registers), so that it will be preserved across
longjmp().
The set of warnings that we see depends on the platform. I.e. on x86 we might
get a warning for a variable, for which we don't get a warning on SPARC.
Or vice versa.
For this reason, it is important to reduce the amount of warnings from GCC,
so that we have a chance to notice when new or unusual warnings appear.
Bruno
> -----Ursprüngliche Nachricht-----
> Von: CLISP - an ANSI Common Lisp Mercurial repository [mailto:no...@cl...]
> Gesendet: Mittwoch, 9. November 2016 17:52
> An: CLISP - an ANSI Common Lisp Mercurial repository
> Betreff: [clisp:clisp] New commit [7181ad] by Bruno Haible
>
> <div class="markdown_content"><p>Fix a relevant gcc warning of type -Wclobbered.</div>
>
> By Bruno Haible on 11/09/2016 16:08
> [**View Changes**](https://sourceforge.net/p/clisp/clisp/ci/7181ad2064e9a4720b1e56c4d21dda33d96ab183/)
>
|
|
From: <cli...@li...> - 2016-11-12 15:31:46
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: Modernize: Remove support for SINIX. (cli...@li...) 2. clisp: Modernize: Remove support for Unix SYSV from around 1995. (cli...@li...) 3. clisp: Modernize: Remove support for Apple A/UX. (cli...@li...) 4. clisp: Modernize: Remove support for Amiga UNIX. (cli...@li...) 5. clisp: Modernize: Remove support for Data General DG/UX. (cli...@li...) 6. clisp: Modernize: Remove support for IRIX. (cli...@li...) 7. clisp: Modernize: Remove support for long dead platforms. (cli...@li...) 8. clisp: Modernize: Remove support for mc680x0 CPUs before mc68020. (cli...@li...) 9. clisp: Modernize: Remove support for mc680x0 CPUs on HP-UX. (cli...@li...) 10. clisp: Modernize: Assume intDsize >= 16. (cli...@li...) 11. clisp: Fix Makefile.devel syntax error introduced on 2011-04-21. (cli...@li...) 12. clisp: Modernize: Update to automake-1.15, libtool-2.4.6, the ne... (cli...@li...) 13. clisp: Update from libtool-2.4.6. (cli...@li...) 14. clisp: Update from Automake git. (cli...@li...) 15. clisp: Update from gnulib git. (cli...@li...) 16. clisp: Update from GNOME git. (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Sat, 12 Nov 2016 03:56:17 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for SINIX. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/5bbb3e42499e changeset: 15688:5bbb3e42499ef03fc5f800ee16f1c926e5c9d9ca user: Bruno Haible <br...@cl...> date: 2016-11-12 04:55:39 +0100 description: Modernize: Remove support for SINIX. diffstat: src/ChangeLog | 7 +++++++ src/lispbibl.d | 10 ++-------- src/spvw_mmap.d | 2 -- 3 files changed, 9 insertions(+), 10 deletions(-) ------------------------------ Message: 2 Date: Sat, 12 Nov 2016 04:27:37 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for Unix SYSV from around 1995. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/9a86ade97aa5 changeset: 15689:9a86ade97aa5be9c8050fccb9a40ad078c2c0a1d user: Bruno Haible <br...@cl...> date: 2016-11-12 05:01:07 +0100 description: Modernize: Remove support for Unix SYSV from around 1995. diffstat: src/ChangeLog | 6 ++++++ src/lispbibl.d | 17 +---------------- 2 files changed, 7 insertions(+), 16 deletions(-) ------------------------------ Message: 3 Date: Sat, 12 Nov 2016 04:27:38 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for Apple A/UX. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/d52daad87a5e changeset: 15690:d52daad87a5ed65372ddbb9a4c46320866f37208 user: Bruno Haible <br...@cl...> date: 2016-11-12 05:03:47 +0100 description: Modernize: Remove support for Apple A/UX. diffstat: src/ChangeLog | 6 ++++++ src/lispbibl.d | 3 --- src/unix.d | 3 --- 3 files changed, 6 insertions(+), 6 deletions(-) ------------------------------ Message: 4 Date: Sat, 12 Nov 2016 04:27:40 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for Amiga UNIX. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/c6b15b5cf44f changeset: 15691:c6b15b5cf44f68b3d9c059ff7332c91d4b057c88 user: Bruno Haible <br...@cl...> date: 2016-11-12 05:06:28 +0100 description: Modernize: Remove support for Amiga UNIX. diffstat: src/ChangeLog | 5 +++++ src/lispbibl.d | 5 +---- 2 files changed, 6 insertions(+), 4 deletions(-) ------------------------------ Message: 5 Date: Sat, 12 Nov 2016 04:27:41 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for Data General DG/UX. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1cec9f4dcbed changeset: 15692:1cec9f4dcbedcc4767bb7bc724192d8d02e75158 user: Bruno Haible <br...@cl...> date: 2016-11-12 05:08:41 +0100 description: Modernize: Remove support for Data General DG/UX. diffstat: src/ChangeLog | 5 +++++ src/lispbibl.d | 5 +---- 2 files changed, 6 insertions(+), 4 deletions(-) ------------------------------ Message: 6 Date: Sat, 12 Nov 2016 04:27:43 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for IRIX. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/08997673f41f changeset: 15693:08997673f41fb749f50eaa396fd7bd0a8c542213 user: Bruno Haible <br...@cl...> date: 2016-11-12 05:16:47 +0100 description: Modernize: Remove support for IRIX. diffstat: src/ChangeLog | 10 ++++++++++ src/lispbibl.d | 11 +---------- src/pathname.d | 4 +--- src/spvw_mmap.d | 5 ----- src/spvw_sigsegv.d | 6 ------ src/stream.d | 4 +--- 6 files changed, 13 insertions(+), 27 deletions(-) ------------------------------ Message: 7 Date: Sat, 12 Nov 2016 14:06:30 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for long dead platforms. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/27054f1b2453 changeset: 15694:27054f1b2453ec71cc2f8c2cb2dcd7de8e5b4cc8 user: Bruno Haible <br...@cl...> date: 2016-11-12 13:16:12 +0100 description: Modernize: Remove support for long dead platforms. diffstat: src/ChangeLog | 10 +++++ src/makemake.in | 103 ++++++++++--------------------------------------------- utils/txt2c.c | 8 ---- 3 files changed, 30 insertions(+), 91 deletions(-) ------------------------------ Message: 8 Date: Sat, 12 Nov 2016 14:06:32 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for mc680x0 CPUs before mc68020. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b5f9685191ce changeset: 15695:b5f9685191ce384605cd662becc0a4efe621d221 user: Bruno Haible <br...@cl...> date: 2016-11-12 14:03:18 +0100 description: Modernize: Remove support for mc680x0 CPUs before mc68020. diffstat: doc/impbyte.xml | 3 - src/ChangeLog | 10 + src/ari68000.d | 711 ----------------------------------------------------- src/arilev0.d | 78 +---- src/arilev1.d | 10 +- src/eval.d | 8 +- src/foreign.d | 2 +- src/intelem.d | 6 - src/intlog.d | 6 +- src/lispbibl.d | 88 ++---- src/makemake.in | 8 +- utils/d2c/Makefile | 1 - 12 files changed, 71 insertions(+), 860 deletions(-) ------------------------------ Message: 9 Date: Sat, 12 Nov 2016 14:06:34 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for mc680x0 CPUs on HP-UX. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/ce443769f9b2 changeset: 15696:ce443769f9b20277a5d7452360db28360c5333a6 user: Bruno Haible <br...@cl...> date: 2016-11-12 14:07:48 +0100 description: Modernize: Remove support for mc680x0 CPUs on HP-UX. diffstat: src/ChangeLog | 5 +++++ src/lispbibl.d | 8 ++++---- 2 files changed, 9 insertions(+), 4 deletions(-) ------------------------------ Message: 10 Date: Sat, 12 Nov 2016 14:06:35 +0000 From: cli...@li... Subject: clisp: Modernize: Assume intDsize >= 16. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/aad4fdd32e94 changeset: 15697:aad4fdd32e9420f4ecc70be5308b5aec48ac663d user: Bruno Haible <br...@cl...> date: 2016-11-12 15:04:13 +0100 description: Modernize: Assume intDsize >= 16. diffstat: src/ChangeLog | 14 ++ src/arilev1.d | 20 +--- src/dfloat.d | 14 +-- src/hashtabl.d | 14 -- src/intelem.d | 302 +-------------------------------------------------------- src/intlog.d | 51 --------- src/intprint.d | 37 ------ 7 files changed, 21 insertions(+), 431 deletions(-) ------------------------------ Message: 11 Date: Sat, 12 Nov 2016 15:31:36 +0000 From: cli...@li... Subject: clisp: Fix Makefile.devel syntax error introduced on 2011-04-21. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/f5d3c9dcd229 changeset: 15698:f5d3c9dcd229b12cc9f25f29658c2341e1eb68af user: Bruno Haible <br...@cl...> date: 2016-11-12 15:37:19 +0100 description: Fix Makefile.devel syntax error introduced on 2011-04-21. diffstat: Makefile.devel | 3 ++- src/ChangeLog | 5 +++++ 2 files changed, 7 insertions(+), 1 deletions(-) ------------------------------ Message: 12 Date: Sat, 12 Nov 2016 15:31:37 +0000 From: cli...@li... Subject: clisp: Modernize: Update to automake-1.15, libtool-2.4.6, the ne... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/bd69eb7edcf2 changeset: 15699:bd69eb7edcf21ffecb56d4ee638391889852e4d8 user: Bruno Haible <br...@cl...> date: 2016-11-12 16:22:55 +0100 description: Modernize: Update to automake-1.15, libtool-2.4.6, the newest gnulib. diffstat: Makefile.devel | 18 ++++++++++-------- src/ChangeLog | 11 +++++++++++ 2 files changed, 21 insertions(+), 8 deletions(-) ------------------------------ Message: 13 Date: Sat, 12 Nov 2016 15:31:39 +0000 From: cli...@li... Subject: clisp: Update from libtool-2.4.6. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/c80bd6253fdd changeset: 15700:c80bd6253fdd1150307f90b361abdab0aaffa402 user: Bruno Haible <br...@cl...> date: 2016-11-12 16:24:03 +0100 description: Update from libtool-2.4.6. diffstat: src/ChangeLog | 7 + src/build-aux/ltmain.sh | 7243 +++++++++++++++++++++++++++++++--------------- src/m4/libtool.m4 | 3460 ++++++++++++++-------- src/m4/ltoptions.m4 | 140 +- src/m4/ltsugar.m4 | 7 +- src/m4/ltversion.m4 | 14 +- src/m4/lt~obsolete.m4 | 7 +- 7 files changed, 7142 insertions(+), 3736 deletions(-) ------------------------------ Message: 14 Date: Sat, 12 Nov 2016 15:31:40 +0000 From: cli...@li... Subject: clisp: Update from Automake git. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b4fedcc6e342 changeset: 15701:b4fedcc6e3427532d0a65c7bb5023e5b193fce6d user: Bruno Haible <br...@cl...> date: 2016-11-12 16:24:39 +0100 description: Update from Automake git. diffstat: src/ChangeLog | 4 + src/build-aux/compile | 235 ++++++++++++++++++++++++- src/build-aux/missing | 457 ++++++++++++++++--------------------------------- src/build-aux/ylwrap | 200 +++++++++++---------- 4 files changed, 477 insertions(+), 419 deletions(-) ------------------------------ Message: 15 Date: Sat, 12 Nov 2016 15:31:41 +0000 From: cli...@li... Subject: clisp: Update from gnulib git. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b13b80902e85 changeset: 15702:b13b80902e850c7281c6596fe0de0f29b6d06bc8 user: Bruno Haible <br...@cl...> date: 2016-11-12 16:25:24 +0100 description: Update from gnulib git. diffstat: src/ChangeLog | 6 + src/build-aux/config.guess | 704 +++++++++++++++++++++----------------------- src/build-aux/config.rpath | 20 +- src/build-aux/config.sub | 310 ++++++++++++------ src/build-aux/depcomp | 540 +++++++++++++++++++++------------- src/build-aux/install-sh | 369 +++++++++++------------ 6 files changed, 1053 insertions(+), 896 deletions(-) ------------------------------ Message: 16 Date: Sat, 12 Nov 2016 15:31:43 +0000 From: cli...@li... Subject: clisp: Update from GNOME git. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/46879c77fe5b changeset: 15703:46879c77fe5bd43b562b4df9e2b735f808d02be5 user: Bruno Haible <br...@cl...> date: 2016-11-12 16:26:28 +0100 description: Update from GNOME git. diffstat: src/ChangeLog | 3 + src/m4/gtk-2.0.m4 | 17 +--- src/m4/gtk-3.0.m4 | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 223 insertions(+), 14 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 73, Issue 3 **************************************** |
|
From: <cli...@li...> - 2016-11-12 03:56:18
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: Fix gcc warnings of type -Wparentheses. (cli...@li...) 2. clisp: Fix gcc warning of type -Wformat. (cli...@li...) 3. clisp: Fix gcc warnings of type -Wc++0x-compat. (cli...@li...) 4. clisp: Fix compilation error of OBJECT_STRUCT mode with g++ vers... (cli...@li...) 5. clisp: Support for memory models with oint_data_len >= 55. (cli...@li...) 6. clisp: Prepare for GENERIC64_HEAPCODES object model. (cli...@li...) 7. clisp: New memory model GENERIC64_HEAPCODES, for 64-bit machines. (cli...@li...) 8. clisp: Update expected test results for memory model GENERIC64_H... (cli...@li...) 9. clisp: Remind user to use -falign-functions=8 with GENERIC64_HEA... (cli...@li...) 10. clisp: Fix compilation error of DEBUG_BACKTRACE feature with C++... (cli...@li...) 11. clisp: Make GENERIC64A_HEAPCODES work again after the type predi... (cli...@li...) 12. clisp: Fix a "No more room for LISP objects" error when building... (cli...@li...) 13. clisp: Fix weird errors when rebuilding 'base' after having chan... (cli...@li...) 14. clisp: Make GENERIC64{A,B}_HEAPCODES work with -falign-functions=4. (cli...@li...) 15. clisp: Comment. (cli...@li...) 16. clisp: Modernize blurbs and comments. (cli...@li...) 17. clisp: Modernize: Remove support for Ultrix. (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Wed, 09 Nov 2016 16:55:40 +0000 From: cli...@li... Subject: clisp: Fix gcc warnings of type -Wparentheses. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/0170a4a85b7c changeset: 15671:0170a4a85b7c23e6f36a65aed8a2f95dfc3f282d user: Bruno Haible <br...@cl...> date: 2016-11-09 17:52:29 +0100 description: Fix gcc warnings of type -Wparentheses. diffstat: src/ChangeLog | 10 +++ src/charstrg.d | 9 ++- src/flo_rest.d | 54 +++++++++++++------- src/intelem.d | 132 ++++++++++++++++++++++++++++++++++----------------- src/pathname.d | 9 +- src/spvw_language.d | 29 +++++++--- 6 files changed, 162 insertions(+), 81 deletions(-) ------------------------------ Message: 2 Date: Wed, 09 Nov 2016 16:55:41 +0000 From: cli...@li... Subject: clisp: Fix gcc warning of type -Wformat. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/634e6cab5e9d changeset: 15672:634e6cab5e9d3568dbfa656ecf634b44f017fe8a user: Bruno Haible <br...@cl...> date: 2016-11-09 17:54:58 +0100 description: Fix gcc warning of type -Wformat. diffstat: src/ChangeLog | 5 +++++ src/spvw.d | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-) ------------------------------ Message: 3 Date: Wed, 09 Nov 2016 17:53:22 +0000 From: cli...@li... Subject: clisp: Fix gcc warnings of type -Wc++0x-compat. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/0dfe4383fcec changeset: 15673:0dfe4383fcec0b2f923176d6b77c6c90037d7fb3 user: Bruno Haible <br...@cl...> date: 2016-11-09 18:17:35 +0100 description: Fix gcc warnings of type -Wc++0x-compat. diffstat: src/ChangeLog | 6 ++++++ src/control.d | 32 ++++++++++++++++---------------- src/eval.d | 8 ++++---- 3 files changed, 26 insertions(+), 20 deletions(-) ------------------------------ Message: 4 Date: Thu, 10 Nov 2016 00:54:03 +0000 From: cli...@li... Subject: clisp: Fix compilation error of OBJECT_STRUCT mode with g++ vers... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/4ec9cd85fb58 changeset: 15674:4ec9cd85fb580159918f3b9df71a28f061879691 user: Bruno Haible <br...@cl...> date: 2016-11-09 20:58:59 +0100 description: Fix compilation error of OBJECT_STRUCT mode with g++ versions < 4.7. diffstat: src/ChangeLog | 10 +++++++++- src/lispbibl.d | 25 +++++++++++++++++++------ 2 files changed, 28 insertions(+), 7 deletions(-) ------------------------------ Message: 5 Date: Thu, 10 Nov 2016 23:07:44 +0000 From: cli...@li... Subject: clisp: Support for memory models with oint_data_len >= 55. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b4301c04b30b changeset: 15675:b4301c04b30b027c01aba96462db58ae5d3a95ca user: Bruno Haible <br...@cl...> date: 2016-11-11 00:06:54 +0100 description: Support for memory models with oint_data_len >= 55. diffstat: src/ChangeLog | 5 +++++ src/dfloat.d | 15 ++++++++++++++- 2 files changed, 19 insertions(+), 1 deletions(-) ------------------------------ Message: 6 Date: Fri, 11 Nov 2016 00:14:44 +0000 From: cli...@li... Subject: clisp: Prepare for GENERIC64_HEAPCODES object model. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/0f736beb9ab8 changeset: 15676:0f736beb9ab8eb0c47d09981674a9ac909e8d4f4 user: Bruno Haible <br...@cl...> date: 2016-11-11 00:15:50 +0100 description: Prepare for GENERIC64_HEAPCODES object model. diffstat: src/ChangeLog | 8 ++++++++ src/lispbibl.d | 22 +++++++++++----------- 2 files changed, 19 insertions(+), 11 deletions(-) ------------------------------ Message: 7 Date: Fri, 11 Nov 2016 00:14:45 +0000 From: cli...@li... Subject: clisp: New memory model GENERIC64_HEAPCODES, for 64-bit machines. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e5f9b0bc59d4 changeset: 15677:e5f9b0bc59d4cf249a7688c3ef0ca08b31b5527e user: Bruno Haible <br...@cl...> date: 2016-11-11 01:11:30 +0100 description: New memory model GENERIC64_HEAPCODES, for 64-bit machines. diffstat: src/ChangeLog | 30 +++++ src/built.d | 3 + src/io.d | 2 +- src/lightning.c | 2 +- src/lispbibl.d | 285 ++++++++++++++++++++++++++++++++++++++++++++++++++-- src/spvw.d | 12 ++ src/spvw_gcmark.d | 5 +- src/spvw_memfile.d | 6 +- 8 files changed, 326 insertions(+), 19 deletions(-) ------------------------------ Message: 8 Date: Fri, 11 Nov 2016 01:06:18 +0000 From: cli...@li... Subject: clisp: Update expected test results for memory model GENERIC64_H... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/365cbdf858d7 changeset: 15678:365cbdf858d79e2eaaa51becb393768f32333992 user: Bruno Haible <br...@cl...> date: 2016-11-11 02:03:11 +0100 description: Update expected test results for memory model GENERIC64_HEAPCODES. diffstat: tests/ChangeLog | 6 ++++++ tests/alltest.tst | 6 ++++++ 2 files changed, 12 insertions(+), 0 deletions(-) ------------------------------ Message: 9 Date: Fri, 11 Nov 2016 01:06:19 +0000 From: cli...@li... Subject: clisp: Remind user to use -falign-functions=8 with GENERIC64_HEA... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/7f50c9d7b9ac changeset: 15679:7f50c9d7b9acc84f35bedda8e6c78cc62f4e5a48 user: Bruno Haible <br...@cl...> date: 2016-11-11 02:05:37 +0100 description: Remind user to use -falign-functions=8 with GENERIC64_HEAPCODES. diffstat: src/ChangeLog | 6 ++++++ src/lispbibl.d | 9 +++++++++ 2 files changed, 15 insertions(+), 0 deletions(-) ------------------------------ Message: 10 Date: Fri, 11 Nov 2016 17:24:26 +0000 From: cli...@li... Subject: clisp: Fix compilation error of DEBUG_BACKTRACE feature with C++... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/3e5919c338db changeset: 15680:3e5919c338dba64528808faefa5a455ba9ef5c74 user: Bruno Haible <br...@cl...> date: 2016-11-11 18:19:42 +0100 description: Fix compilation error of DEBUG_BACKTRACE feature with C++ compiler. diffstat: src/ChangeLog | 6 ++++++ src/debug.d | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-) ------------------------------ Message: 11 Date: Fri, 11 Nov 2016 19:59:11 +0000 From: cli...@li... Subject: clisp: Make GENERIC64A_HEAPCODES work again after the type predi... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a0c549d6c2d9 changeset: 15681:a0c549d6c2d9ed0bc081e9d0ea53e21fda56acde user: Bruno Haible <br...@cl...> date: 2016-11-11 20:08:08 +0100 description: Make GENERIC64A_HEAPCODES work again after the type predicates change diffstat: src/ChangeLog | 11 +++++ src/lispbibl.d | 111 +++++++++++++++++++++++++------------------------------- 2 files changed, 61 insertions(+), 61 deletions(-) ------------------------------ Message: 12 Date: Fri, 11 Nov 2016 19:59:12 +0000 From: cli...@li... Subject: clisp: Fix a "No more room for LISP objects" error when building... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/638499469679 changeset: 15682:6384994696792dfb1f4d4fdc5706f160f9af9ee1 user: Bruno Haible <br...@cl...> date: 2016-11-11 20:58:29 +0100 description: Fix a "No more room for LISP objects" error when building syscalls. diffstat: modules/syscalls/Makefile.in | 2 +- src/ChangeLog | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletions(-) ------------------------------ Message: 13 Date: Fri, 11 Nov 2016 22:24:12 +0000 From: cli...@li... Subject: clisp: Fix weird errors when rebuilding 'base' after having chan... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/3e07992373fe changeset: 15683:3e07992373fe55fe855f11a653d7cc8d32c91147 user: Bruno Haible <br...@cl...> date: 2016-11-11 21:13:18 +0100 description: Fix weird errors when rebuilding 'base' after having changed CFLAGS. diffstat: src/ChangeLog | 5 +++++ src/makemake.in | 1 + 2 files changed, 6 insertions(+), 0 deletions(-) ------------------------------ Message: 14 Date: Fri, 11 Nov 2016 22:24:13 +0000 From: cli...@li... Subject: clisp: Make GENERIC64{A,B}_HEAPCODES work with -falign-functions=4. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2b7b6ff78f14 changeset: 15684:2b7b6ff78f1425448246174b454849f9b123626e user: Bruno Haible <br...@cl...> date: 2016-11-11 23:23:04 +0100 description: Make GENERIC64{A,B}_HEAPCODES work with -falign-functions=4. diffstat: src/ChangeLog | 11 ++++ src/lispbibl.d | 153 ++++++++++++++++++++++++++++---------------------------- 2 files changed, 88 insertions(+), 76 deletions(-) ------------------------------ Message: 15 Date: Fri, 11 Nov 2016 22:24:14 +0000 From: cli...@li... Subject: clisp: Comment. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1e36ee4b0478 changeset: 15685:1e36ee4b04783fb9f451e96d0b66deafc1bee074 user: Bruno Haible <br...@cl...> date: 2016-11-11 23:23:30 +0100 description: Comment. diffstat: src/lispbibl.d | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ------------------------------ Message: 16 Date: Sat, 12 Nov 2016 03:56:14 +0000 From: cli...@li... Subject: clisp: Modernize blurbs and comments. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/5b4f97e83baa changeset: 15686:5b4f97e83baab951735de3db036d917e1deb84e4 user: Bruno Haible <br...@cl...> date: 2016-11-12 04:37:16 +0100 description: Modernize blurbs and comments. diffstat: COPYRIGHT | 2 +- SUMMARY | 22 +- src/ChangeLog | 9 + src/lispbibl.d | 57 ---- unix/PLATFORMS | 667 +-------------------------------------------------------- 5 files changed, 27 insertions(+), 730 deletions(-) ------------------------------ Message: 17 Date: Sat, 12 Nov 2016 03:56:15 +0000 From: cli...@li... Subject: clisp: Modernize: Remove support for Ultrix. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/8ba6337ddbd9 changeset: 15687:8ba6337ddbd9e2168b6fadde5aa07f97e2fb71cb user: Bruno Haible <br...@cl...> date: 2016-11-12 04:49:02 +0100 description: Modernize: Remove support for Ultrix. diffstat: src/ChangeLog | 8 ++++++++ src/array.d | 27 ++++++++------------------- src/control.d | 2 -- src/flo_rest.d | 5 +---- src/lispbibl.d | 8 +------- 5 files changed, 18 insertions(+), 32 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 73, Issue 2 **************************************** |
|
From: Sam S. <sd...@gn...> - 2016-11-11 19:07:08
|
Hi Bruno, > * Bruno Haible <oe...@py...t> [2016-11-11 01:20:33 +0100]: > >> Florian Weimer asked in https://sourceforge.net/p/clisp/mailman/message/35478071/: >> > What's the easiest way to port CLISP to a 64-bit architecture which >> > does not have any reserved bits in pointers? That is, you could use >> > only the bits you get from aligning objects (e.g., 3 bits for 8-byte >> > alignment). > > I have now implemented such a memory model. It should help to reduce the > portability effort to new 64-bit platforms. Please mention this in src/NEWS unix/PLATFORMS (porting hints) it would be nice if you also reviewed and updated doc/impbytes.xml. thanks. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://memri.org http://jij.org https://jihadwatch.org http://thereligionofpeace.com Send $10 for a brochure on how to make money selling brochures. |
|
From: Bruno H. <br...@cl...> - 2016-11-11 00:20:56
|
Hello Florian, > Florian Weimer asked in https://sourceforge.net/p/clisp/mailman/message/35478071/: > > What's the easiest way to port CLISP to a 64-bit architecture which > > does not have any reserved bits in pointers? That is, you could use > > only the bits you get from aligning objects (e.g., 3 bits for 8-byte > > alignment). I have now implemented such a memory model. It should help to reduce the portability effort to new 64-bit platforms. Thank you for the good suggestion!! Which platform do you have in mind? I have only tested it on Linux/x86_64. If you want to test it, check out the sources from the 'hg' repository and simply add -DGENERIC64_HEAPCODES to the CFLAGS. Bruno |
|
From: Bruno H. <br...@cl...> - 2016-11-10 16:36:40
|
Hi Sam,
> > The reason is that it introduces compilation errors when one attempts to use
> > DEBUG_GCSAFETY with g++ < 4.7.
>
> The current GCC version is 6.
> Are you sure we need to support any version of GCC older than, say, 5?
RHEL 5.11 is supported until March 2017 and ships with G++ 4.1.x.
Ubuntu 12.04 is supported until April 2017 and ships with G++ 4.6.3.
> > The syntax one_o:(o)
> > is only documented in the GCC doc [2] and is marked as "obsolete since GCC 2.5".
> > But with G++ 4.6.4 and older it's the only available syntax.
>
> Am I the only one who finds this ironic? ("obsolete since 2.5, but the
> only option for 4.6.4 and older")
No. I find it strange too that they declared something "obsolete" and the
replacement was not available for 19 years.
> So what are you going to do?
> (obviously, I have no objections to whatever change you want to push)
I pushed it already. You should have received the automatic notification mail.
Bruno
|
|
From: Sam S. <sd...@gn...> - 2016-11-10 15:59:42
|
Hi Bruno,
> * Bruno Haible <oe...@py...t> [2016-11-10 01:54:20 +0100]:
>
> I need to correct your change of
>
> 2016-08-28 Sam Steingold <sd...@gn...>
>
> avoid the clang -Wgnu-designator warning
> * lispbibl.d (as_object, as_chart): use the new {.one_o=???}
> syntax instead of GNU old-style field designator extension {one_o:???}
> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Designated-Inits.html
>
> The reason is that it introduces compilation errors when one attempts to use
> DEBUG_GCSAFETY with g++ < 4.7.
The current GCC version is 6.
Are you sure we need to support any version of GCC older than, say, 5?
(Okay, I am using an AWS server with gcc (GCC) 4.8.3 20140911 (Red Hat
4.8.3-9)).
> With G++ 4.6.4 and older:
> $ g++ -c foo.cc
> foo.cc: In Funktion »gcv_object_t bar()«:
> foo.cc:21:30: Fehler: expected primary-expression before »)« token
> foo.cc:21:30: Fehler: expected »)« before »{« token
> foo.cc:21:30: Fehler: expected »;« before »)« token
> foo.cc:21:30: Fehler: expected primary-expression before »)« token
> foo.cc:21:30: Fehler: expected »;« before »)« token
>
> The syntax .one_o=(o)
> appears to be more standard: it is described in Wikipedia [1] and the GCC
> documentation [2].
I wonder if the C++ standard has anything to say about it.
> The syntax one_o:(o)
> is only documented in the GCC doc [2] and is marked as "obsolete since GCC 2.5".
> But with G++ 4.6.4 and older it's the only available syntax.
Am I the only one who finds this ironic? ("obsolete since 2.5, but the
only option for 4.6.4 and older")
> [1] https://en.wikipedia.org/wiki/C_syntax#Designated_initializers
> [2] https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Designated-Inits.html
So what are you going to do?
(obviously, I have no objections to whatever change you want to push)
--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://iris.org.il http://camera.org http://thereligionofpeace.com
In C you can make mistakes, while in C++ you can also inherit them!
|
|
From: Bruno H. <br...@cl...> - 2016-11-10 00:54:43
|
Hi Sam,
I need to correct your change of
2016-08-28 Sam Steingold <sd...@gn...>
avoid the clang -Wgnu-designator warning
* lispbibl.d (as_object, as_chart): use the new {.one_o=???}
syntax instead of GNU old-style field designator extension {one_o:???}
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Designated-Inits.html
The reason is that it introduces compilation errors when one attempts to use
DEBUG_GCSAFETY with g++ < 4.7.
DEBUG_GCSAFETY requires a C++ compiler and defines OBJECT_STRUCT.
Look at this test program:
================================= foo.cc =================================
typedef unsigned long uintP;
typedef signed long sintP;
typedef struct { uintP one_o; } gcv_object_t;
typedef uintP oint;
typedef sintP soint;
typedef gcv_object_t object;
#define as_oint(expr) ((expr).one_o)
// Works with any GCC but only with G++ >= 4.7. With clang no warning.
#define as_object(o) ((object){.one_o=(o)})
// Works with any GCC and any G++. With clang it gives "warning: use of GNU old-style field designator extension"
//#define as_object(o) ((object){one_o:(o)})
extern gcv_object_t a;
extern oint b;
oint foo () { return as_oint(a); }
gcv_object_t bar () { return as_object(b); }
==========================================================================
With G++ 4.6.4 and older:
$ g++ -c foo.cc
foo.cc: In Funktion »gcv_object_t bar()«:
foo.cc:21:30: Fehler: expected primary-expression before »)« token
foo.cc:21:30: Fehler: expected »)« before »{« token
foo.cc:21:30: Fehler: expected »;« before »)« token
foo.cc:21:30: Fehler: expected primary-expression before »)« token
foo.cc:21:30: Fehler: expected »;« before »)« token
The syntax .one_o=(o)
appears to be more standard: it is described in Wikipedia [1] and the GCC
documentation [2].
The syntax one_o:(o)
is only documented in the GCC doc [2] and is marked as "obsolete since GCC 2.5".
But with G++ 4.6.4 and older it's the only available syntax.
Bruno
[1] https://en.wikipedia.org/wiki/C_syntax#Designated_initializers
[2] https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Designated-Inits.html
|
|
From: <cli...@li...> - 2016-11-09 16:52:12
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: bind the globals at the right level (cli...@li...) 2. clisp: (lexical-analysis): ignore //-comments inside /*-comments (cli...@li...) 3. clisp: formatting (cli...@li...) 4. clisp: (clisp-bug-reference-url-format): string-match invalidate... (cli...@li...) 5. clisp: updated (cli...@li...) 6. clisp: debug->production (cli...@li...) 7. clisp: remove WIDE_AUXI (obsolete) (cli...@li...) 8. clisp: (c)year (cli...@li...) 9. clisp: test.tst is no longer linked over to the build directory (cli...@li...) 10. clisp: mention bug#677 (cli...@li...) 11. clisp: comment (cli...@li...) 12. clisp: update SF links: Mercurial & group_id=1355 --> project/clisp (cli...@li...) 13. clisp: fix dead links (cli...@li...) 14. clisp: * utils/fix-perms.sh (root): replace obsolete "-perm +111... (cli...@li...) 15. clisp: remove podval (cli...@li...) 16. clisp: Fix compilation error introduced on 2007-11-26. (cli...@li...) 17. clisp: Fix a relevant gcc warning of type -Wclobbered. (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Mon, 29 Aug 2016 17:10:08 +0000 From: cli...@li... Subject: clisp: bind the globals at the right level To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/4abd03a03e1f changeset: 15654:4abd03a03e1f2fa5f769ed3ff6906711cf6d8977 user: Sam Steingold <sd...@gn...> date: 2016-08-29 13:05:07 -0400 description: bind the globals at the right level * utils/modprep.lisp (modprep): bind *module-name*, *module-line*, *module-package*, *package-properties* here ... (parse): ... not here diffstat: src/ChangeLog | 6 ++++++ utils/modprep.lisp | 4 ++-- utils/modpreptest.m.c | 5 ++--- 3 files changed, 10 insertions(+), 5 deletions(-) ------------------------------ Message: 2 Date: Mon, 29 Aug 2016 17:10:09 +0000 From: cli...@li... Subject: clisp: (lexical-analysis): ignore //-comments inside /*-comments To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/dbec45b9e89e changeset: 15655:dbec45b9e89e9a968f67210b19674b7d3b475e2d user: Sam Steingold <sd...@gn...> date: 2016-08-29 13:09:55 -0400 description: (lexical-analysis): ignore //-comments inside /*-comments diffstat: src/ChangeLog | 1 + utils/modprep.lisp | 6 +++--- utils/modpreptest.c | 1 + utils/modpreptest.m.c | 1 + 4 files changed, 6 insertions(+), 3 deletions(-) ------------------------------ Message: 3 Date: Mon, 29 Aug 2016 19:06:50 +0000 From: cli...@li... Subject: clisp: formatting To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/793332b8120b changeset: 15656:793332b8120be86de927e10ba0ea2ee3f6f44ae9 user: Sam Steingold <sd...@gn...> date: 2016-08-29 15:06:04 -0400 description: formatting diffstat: src/ChangeLog | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) ------------------------------ Message: 4 Date: Mon, 29 Aug 2016 19:06:51 +0000 From: cli...@li... Subject: clisp: (clisp-bug-reference-url-format): string-match invalidate... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/fbeb91155bf7 changeset: 15657:fbeb91155bf74e69cb8f39f752244621dbf3d847 user: Sam Steingold <sd...@gn...> date: 2016-08-29 15:06:40 -0400 description: (clisp-bug-reference-url-format): string-match invalidates match data diffstat: emacs/misc.el | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) ------------------------------ Message: 5 Date: Mon, 29 Aug 2016 19:33:45 +0000 From: cli...@li... Subject: clisp: updated To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/968454905c2c changeset: 15658:968454905c2c3c19a78ea8f9cdb706d3ba372282 user: Sam Steingold <sd...@gn...> date: 2016-08-29 15:33:38 -0400 description: updated diffstat: tests/ChangeLog | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) ------------------------------ Message: 6 Date: Mon, 29 Aug 2016 23:13:44 +0000 From: cli...@li... Subject: clisp: debug->production To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/783af9c985c7 changeset: 15659:783af9c985c766f0db7f6fb98ae7cd076fe3dd5e user: Sam Steingold <sd...@gn...> date: 2016-08-29 18:40:49 -0400 description: debug->production diffstat: utils/modprep.lisp | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) ------------------------------ Message: 7 Date: Mon, 29 Aug 2016 23:13:45 +0000 From: cli...@li... Subject: clisp: remove WIDE_AUXI (obsolete) To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/6b992fc65385 changeset: 15660:6b992fc653852a16289b638ffa4471f723ca3763 user: Sam Steingold <sd...@gn...> date: 2016-08-29 19:13:19 -0400 description: remove WIDE_AUXI (obsolete) * src/lispbibl.d, src/built.d, src/spvw.d, src/spvw_garcol.d, src/spvw_garcol_old.d: * src/spvw_mark.d: remove the obsolete object representation WIDE_AUXI diffstat: src/ChangeLog | 5 + src/built.d | 2 - src/lispbibl.d | 129 ++++++++----------------------------------------- src/spvw.d | 6 +- src/spvw_garcol.d | 21 +++----- src/spvw_garcol_old.d | 21 +++----- src/spvw_mark.d | 6 +- 7 files changed, 48 insertions(+), 142 deletions(-) ------------------------------ Message: 8 Date: Mon, 29 Aug 2016 23:20:21 +0000 From: cli...@li... Subject: clisp: (c)year To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2d1aedc0b550 changeset: 15661:2d1aedc0b5500ae5c38e60082ef60a36826c5eed user: Sam Steingold <sd...@gn...> date: 2016-08-29 19:20:13 -0400 description: (c)year diffstat: src/built.d | 2 +- src/spvw.d | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) ------------------------------ Message: 9 Date: Wed, 31 Aug 2016 03:56:19 +0000 From: cli...@li... Subject: clisp: test.tst is no longer linked over to the build directory To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/bb23fd0915fa changeset: 15662:bb23fd0915fa5961a6c28f6b9f750ce98c31a560 user: Sam Steingold <sd...@po...> date: 2016-08-30 22:45:08 -0400 description: test.tst is no longer linked over to the build directory diffstat: modules/berkeley-db/test.tst | 2 +- modules/bindings/glibc/test.tst | 2 +- modules/bindings/win32/test.tst | 2 +- modules/clx/new-clx/test.tst | 2 +- modules/dbus/test.tst | 2 +- modules/gdbm/test.tst | 2 +- modules/i18n/test.tst | 2 +- modules/libsvm/test.tst | 2 +- modules/matlab/test.tst | 2 +- modules/pari/test.tst | 2 +- modules/postgresql/test.tst | 2 +- modules/rawsock/test.tst | 2 +- modules/readline/test.tst | 2 +- modules/regexp/test.tst | 2 +- modules/zlib/test.tst | 2 +- 15 files changed, 15 insertions(+), 15 deletions(-) ------------------------------ Message: 10 Date: Thu, 01 Sep 2016 23:25:11 +0000 From: cli...@li... Subject: clisp: mention bug#677 To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e49a6bc03615 changeset: 15663:e49a6bc03615cdf2747393c5fb232806f0cbfd6f user: Sam Steingold <sd...@gn...> date: 2016-09-01 19:25:04 -0400 description: mention bug#677 diffstat: src/NEWS | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) ------------------------------ Message: 11 Date: Fri, 02 Sep 2016 03:42:23 +0000 From: cli...@li... Subject: clisp: comment To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b458f1d5e2bd changeset: 15664:b458f1d5e2bdfbb84fcd9bc02a85899d1ca8c903 user: Sam Steingold <sd...@po...> date: 2016-09-01 23:42:15 -0400 description: comment diffstat: utils/modprep.lisp | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) ------------------------------ Message: 12 Date: Sun, 04 Sep 2016 19:53:01 +0000 From: cli...@li... Subject: clisp: update SF links: Mercurial & group_id=1355 --> project/clisp To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/8c640ff45355 changeset: 15665:8c640ff453550ea1670cbc5d10d3887fafe64393 user: Sam Steingold <sd...@gn...> date: 2016-09-04 11:50:40 -0400 description: update SF links: Mercurial & group_id=1355 --> project/clisp diffstat: doc/common.xsl | 10 +++++----- doc/faq.xml | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) ------------------------------ Message: 13 Date: Sun, 04 Sep 2016 19:53:02 +0000 From: cli...@li... Subject: clisp: fix dead links To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/ee51659340a3 changeset: 15666:ee51659340a3494fe25a79df758d5d4f9b389af6 user: Sam Steingold <sd...@gn...> date: 2016-09-04 14:06:22 -0400 description: fix dead links diffstat: doc/cl-ent.xml | 21 ++++++++++----------- doc/clisp.xml.in | 3 ++- doc/common.xsl | 16 ++++------------ doc/faq.xml | 12 ++++++------ doc/impbody.xml | 6 +++--- doc/impent.xml | 5 ++--- doc/impext.xml | 5 ++--- 7 files changed, 29 insertions(+), 39 deletions(-) ------------------------------ Message: 14 Date: Sun, 04 Sep 2016 20:54:18 +0000 From: cli...@li... Subject: clisp: * utils/fix-perms.sh (root): replace obsolete "-perm +111... To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1b974200f7a8 changeset: 15667:1b974200f7a89676741fadde07f084889408fe93 user: Sam Steingold <sd...@po...> date: 2016-09-04 16:50:00 -0400 description: * utils/fix-perms.sh (root): replace obsolete "-perm +111" with "-perm /111" and .cvsignore with .hgignore diffstat: src/ChangeLog | 5 +++++ utils/fix-perms.sh | 9 +++++---- 2 files changed, 10 insertions(+), 4 deletions(-) ------------------------------ Message: 15 Date: Sun, 04 Sep 2016 20:54:19 +0000 From: cli...@li... Subject: clisp: remove podval To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/01c69ac1e332 changeset: 15668:01c69ac1e332bea02fdb5c0ed333407f83b76fbd user: Sam Steingold <sd...@po...> date: 2016-09-04 16:54:10 -0400 description: remove podval diffstat: doc/Makefile | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) ------------------------------ Message: 16 Date: Wed, 09 Nov 2016 15:17:44 +0000 From: cli...@li... Subject: clisp: Fix compilation error introduced on 2007-11-26. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/ec2f860aee78 changeset: 15669:ec2f860aee78e6b4ec83b155e3639325bb8c63b6 user: Bruno Haible <br...@cl...> date: 2016-11-09 13:13:54 +0100 description: Fix compilation error introduced on 2007-11-26. diffstat: src/ChangeLog | 8 +++++++- src/spvw_allocate.d | 18 +++++++++--------- 2 files changed, 16 insertions(+), 10 deletions(-) ------------------------------ Message: 17 Date: Wed, 09 Nov 2016 16:52:09 +0000 From: cli...@li... Subject: clisp: Fix a relevant gcc warning of type -Wclobbered. To: cli...@li... Message-ID: <hg....@sf...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/7181ad2064e9 changeset: 15670:7181ad2064e9a4720b1e56c4d21dda33d96ab183 user: Bruno Haible <br...@cl...> date: 2016-11-09 17:08:38 +0100 description: Fix a relevant gcc warning of type -Wclobbered. diffstat: src/ChangeLog | 6 ++++++ src/pathname.d | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 73, Issue 1 **************************************** |
|
From: Bruno H. <br...@cl...> - 2016-11-09 00:31:12
|
Florian Weimer asked in https://sourceforge.net/p/clisp/mailman/message/35478071/: > What's the easiest way to port CLISP to a 64-bit architecture which > does not have any reserved bits in pointers? That is, you could use > only the bits you get from aligning objects (e.g., 3 bits for 8-byte > alignment). Assume your platform is denoted by FOO64. You edit these lines of lispbibl.d: #if defined(DECALPHA) || defined(MIPS64) || defined(SPARC64) || defined(IA64) || defined(AMD64) || defined(FOO64) #define WIDE_HARD #endif to include your platform. Also, edit these lines of lispbibl.d: #if (defined(WIDE_HARD) && !defined(UNIX_DARWIN) && !defined(FOO64)) || defined(WIDE_SOFT) || defined(MC68000) || ((alignment_long < 4) && !defined(GNU)) #define TYPECODES #else #define HEAPCODES #endif As a consequence, the following macros will be defined: WIDE_HARD HEAPCODES Define #define GENERIC_64_HEAPCODES Then look for all occurrences of LINUX_NOEXEC_HEAPCODES and create similar definitions for GENERIC_64_HEAPCODES (very similar, just with 64-bit masks instead of 32-bit masks). Bruno |
|
From: Florian W. <fw...@de...> - 2016-11-08 10:23:20
|
What's the easiest way to port CLISP to a 64-bit architecture which does not have any reserved bits in pointers? That is, you could use only the bits you get from aligning objects (e.g., 3 bits for 8-byte alignment). |
|
From: Bruno H. <br...@cl...> - 2016-10-02 20:51:38
|
Sam writes: > > The larger part of the BeOS-specific code in clisp (unix.d, unixaux.d, > > stream.d) deals with the fact that they did not fully integrate > > sockets into the file-descriptor system. > > ... > > No other OS does this, and I bet that no other OS will do the same > > mistake. > > windows? No, Windows has sockets already integrated into the system of Handles and file descriptors. It may have some flaws when you try to pass a socket as stdin or stdout to a new process, but that's nothing clisp has ever run into. For clisp's purpose, the Windows sockets are just fine (apart from the fact that you have to initialize some Windows subsystem and that the errno is not well integrated). Bruno |
|
From: Sam S. <sd...@gn...> - 2016-10-02 17:55:59
|
> * Bruno Haible <oe...@py...t> [2016-09-18 12:05:48 +0200]: > > The larger part of the BeOS-specific code in clisp (unix.d, unixaux.d, > stream.d) deals with the fact that they did not fully integrate > sockets into the file-descriptor system. I wonder why they did this. > No other OS does this, and I bet that no other OS will do the same > mistake. windows? -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404 http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org http://islamexposedonline.com http://camera.org http://jij.org http://www.dhimmitude.org A PC without Windows is like ice cream without ketchup. |
|
From: <Joe...@t-...> - 2016-09-22 15:47:24
|
Hi, All languages I know with good enough documentation disallow modifying hash-tables while iterating over them. CLHS: http://www.lispworks.com/documentation/HyperSpec/Body/f_maphas.htm#maphash "The consequences are unspecified if any attempt is made to add or remove an entry from the hash-table while a maphash is in progress, with two exceptions...[setf current and remhash current entry]" The technical reason is that iterators typically embed pointers into the complicated hash-table structure; destructive modification of said structure would break havoc. Yesterday I talked with Bruno and the idea arose to have CLISP signal an error in that case, given that the CLISP philosophy has always been to minimize unspecified behaviour. The curious & adventurous might try and see how the various Lisp implementations reacting to modifications of various elements of a hash-table while its being walked through (incl. nested walks): which crashes, which behaves? We discussed plausible implementations and Bruno mentioned stack frames like those known from unwind-protect or let that would a) link one iterator on the stack to the next (both maphash and loop::%hash-table-iterator) and b) help locate the current entry whose modification is allowed. I believe no modification is allowed at all if 2 iterators are active (on the same table) and they are currently processing different entries. Thinking again about this, an alternative implementation comes to mind: check within the iterator whether a modification took place. I have no idea how much these checks would slow down (SETF GETHASH) and REMHASH or iteration. The outcome: this might help people using clisp find complex and hard to trace bugs in code that uses maphash/loop a lot with non-trivial code. Signaling an error is a very reasonable choice. Of course, if clisp's internal hash-table implementation were changed to better support MT, introducing a data structure that allows concurrent updates would perhaps also support nested updates, then that would not be an error condition any more. Regards, Jörg Höhle |
|
From: Bruno H. <br...@cl...> - 2016-09-18 10:17:44
|
Hi, If anyone wants to work on that: Newer Linux kernels have a facility calls 'userfaultfd'. Basically, it's a more efficient way to do memory page protection tricks, compared to the PROT_NONE + SIGSEGV trick. [1][2] The SBCL people are about to make use of this for SBCL. [3] It could also make clisp's memory handling a bit more efficient. Unfortunately it won't reduce the code size, since the PROT_NONE + SIGSEGV approach is still the best one for Unix systems other than Linux. Bruno [1] https://www.kernel.org/doc/Documentation/vm/userfaultfd.txt [2] https://lwn.net/Articles/644532/ [3] https://medium.com/@MartinCracauer/generational-garbage-collection-write-barriers-write-protection-and-userfaultfd-2-8b0e796b8f7f#.efabjqnqj |
|
From: Bruno H. <br...@cl...> - 2016-09-18 10:06:07
|
Sam Steingold asked: > Should we remove BEOS/HAIKU support? Would be fine with me. BeOS itself is no longer in use since probably 2003 or so. Haiku, the free-software clone of BeOS, is being developed by a small group of hackers. Running clisp on Haiku is probably not a priority for anyone in the world. The larger part of the BeOS-specific code in clisp (unix.d, unixaux.d, stream.d) deals with the fact that they did not fully integrate sockets into the file-descriptor system. No other OS does this, and I bet that no other OS will do the same mistake. => Feel free to ditch that BeOS-specific code. Bruno |
32 messages has been excluded from this view by a project administrator.
