clisp-devel — closed list for developers and testers

New Swedish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

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 Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/sv.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:

    http://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:

    http://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...>

New Swedish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

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 Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/sv.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:

    http://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:

    http://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...>

Re: GSoC 2017: we have a slot

[Vladimir T. <vtz...@gm...>]

Compro, try to follow the items outlined in you proposal.

31-May to 11-Jun: Writing the lisp code to make simple threads and find out
where the hash table hits a corner case. Get ready with enough tests
09-Jun to 30-Jun: Write/Improve functions/macros to handle the thread
safety in the hash tables.

The preferred communication channel is this mailing list - feel free to
post code here.

At that stage I would expect to see tests hitting the problem and
ideas/plans/code trying to resolve the observed issues.



On Thu, Jun 15, 2017 at 11:00 PM, Sam Steingold <sd...@gn...> wrote:

> > * Sam Steingold <fq...@ta...t> [2017-04-26 10:38:10 -0400]:
> >
> > I am not sure what you mean by "joining us", but the next critical date
> > on the timeline is June 26.
> > By this date you need to have most of the work either done or in a state
> > where we will be confident that you _will_ finish it on time.
>
> Looks like this date is closer than it appeared just a few weeks ago.
> In 10 days we will have to see most of the work done.
>
> So far I have not seen any code.
>
> --
> Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
> http://steingoldpsychology.com http://www.childpsy.net http://memri.org
> http://americancensorship.org http://www.dhimmitude.org
> Beliefs divide, doubts unite.
>

Re: GSoC 2017: we have a slot

[Compro P. <com...@gm...>]

Do I have to provide the full diff in email? If so, what options to
diff would be necessary?
Or is it good to go with hg? Should I start off by creating any branch
or something else?
Are you requesting a huge change or an xyz is good enough to start with?
Because the code seems a bit more involved than I thought. Too many
identifiers and tasks trying to do similar things in different ways.
Just studying threads won't suffice so was looking through stacks,
objects, etc. and their modifications using different functions
and macros.

Re: GSoC 2017: we have a slot

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

> * Sam Steingold <fq...@ta...t> [2017-04-26 10:38:10 -0400]:
>
> I am not sure what you mean by "joining us", but the next critical date
> on the timeline is June 26.
> By this date you need to have most of the work either done or in a state
> where we will be confident that you _will_ finish it on time.

Looks like this date is closer than it appeared just a few weeks ago.
In 10 days we will have to see most of the work done.

So far I have not seen any code.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
http://americancensorship.org http://www.dhimmitude.org
Beliefs divide, doubts unite.

clisp-cvs Digest, Vol 78, Issue 4

[<cli...@li...>]

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: Regenerated. (cli...@li...)
   2. clisp: Update to the newest gnulib, and import module
      'noreturn'. (cli...@li...)
   3. clisp: Avoid warning about restartf_t.
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Thu, 15 Jun 2017 11:20:40 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Regenerated.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/4e8adc02aaba
changeset: 15930:4e8adc02aaba2db053ae73f1e9d4ea9b81c5bda2
user:      Bruno Haible <br...@cl...>
date:      2017-06-15 13:06:09 +0200
description:
Regenerated.

diffstat:

 src/ari80386.msvc.c |  4 ++++
 src/sp80386.msvc.c  |  4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)



------------------------------

Message: 2
Date: Thu, 15 Jun 2017 11:20:41 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Update to the newest gnulib, and import module
	'noreturn'.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2dc4ce786745
changeset: 15931:2dc4ce786745ec61abd0194b47ae1e45f9c1c951
user:      Bruno Haible <br...@cl...>
date:      2017-06-15 13:14:12 +0200
description:
Update to the newest gnulib, and import module 'noreturn'.

diffstat:

 Makefile.devel             |    2 +-
 src/ChangeLog              |   11 ++++
 src/aclocal.m4             |   26 ++++++++--
 src/build-aux/config.guess |   13 ++++-
 src/config.h.in            |    6 ++
 src/configure              |   27 +++++++++-
 src/gllib/Makefile.am      |    9 +++-
 src/gllib/Makefile.in      |   28 +++++-----
 src/gllib/noreturn.h       |  111 +++++++++++++++++++++++++++++++++++++++++++++
 src/glm4/gnulib-cache.m4   |    3 +-
 src/glm4/gnulib-comp.m4    |    2 +
 src/glm4/host-cpu-c-abi.m4 |   19 ++++++-
 src/glm4/sys_types_h.m4    |    5 +-
 13 files changed, 229 insertions(+), 33 deletions(-)



------------------------------

Message: 3
Date: Thu, 15 Jun 2017 11:20:43 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Avoid warning about restartf_t.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1d0da6e590af
changeset: 15932:1d0da6e590afe9076bd48ee4be003850d49e0473
user:      Bruno Haible <br...@cl...>
date:      2017-06-15 13:20:07 +0200
description:
Avoid warning about restartf_t.

diffstat:

 src/ChangeLog  |   9 +++++++++
 src/eval.d     |   4 ++--
 src/lispbibl.d |  14 +++++---------
 src/spvw.d     |   2 +-
 4 files changed, 17 insertions(+), 12 deletions(-)



------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


------------------------------

End of clisp-cvs Digest, Vol 78, Issue 4
****************************************

Re: TAGS in clisp d-mode.el

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

Compro Prasad asks:
> What else do others depend upon if not clisp's d-mode.el ?

I use 'kate' as text editor, and 'grep -n ... *.d' to find the declaration and
definition of a specific function or macro. A bit archaic, I know, but it
works for me.

Bruno

Re: TAGS in clisp d-mode.el

[Compro P. <com...@gm...>]

What else do others depend upon if not clisp's d-mode.el ?

> On Wed, Jun 14, 2017 at 11:39 PM, Sam Steingold <sd...@gn...> wrote:
>> * Compro Prasad <pbzcebcenfnq@tznvy.pbz> [2017-06-14 10:18:44 +0500]:
>>
>> I use GNU global for C/C++ source files ....
>> .... Is it GNU global or d-mode.el itself?
>
> I am probably the only user of d-mode.el and I do not use GNU global.

Re: TAGS in clisp d-mode.el

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

> * Compro Prasad <pbzcebcenfnq@tznvy.pbz> [2017-06-14 10:18:44 +0500]:
>
> I use GNU global for C/C++ source files ....
> .... Is it GNU global or d-mode.el itself?

I am probably the only user of d-mode.el and I do not use GNU global.

> If none then what is your config to get through the process?

I use exuberant ctags (https://ctags.io/).

> I saw https://sourceforge.net/p/clisp/mailman/message/13043278/ where
> Sam is saying about dropping comment5 and *.d which is from 2003. Why
> they haven't been dropped yet?

http://www.cygwin.com/acronyms/#PTC

seriously though, this is not such a simple step, alas.
it will touch MANY files, non-trivially.


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
https://jihadwatch.org http://www.memritv.org http://mideasttruth.com
What garlic is to food, insanity is to art.

clisp-cvs Digest, Vol 78, Issue 3

[<cli...@li...>]

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: Don't declare the need for an executable stack on
      Linux a... (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Wed, 14 Jun 2017 09:24:17 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Don't declare the need for an executable stack on
	Linux a...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/221883a34c39
changeset: 15929:221883a34c3944190da8d2b98bfbc73cd5da286f
user:      Bruno Haible <br...@cl...>
date:      2017-06-14 11:23:52 +0200
description:
Don't declare the need for an executable stack on Linux and FreeBSD.

diffstat:

 src/ChangeLog    |  12 ++++++++++++
 src/ari80386.d   |   4 ++++
 src/ariarm.d     |   4 ++++
 src/arihppa.d    |   3 +++
 src/arisparc.d   |   4 ++++
 src/arisparc64.d |   4 ++++
 src/arivaxunix.d |   4 ++++
 src/sp68000.d    |   4 ++++
 src/sp80386.d    |   4 ++++
 src/spsparc.d    |   4 ++++
 src/spsparc64.d  |   4 ++++
 11 files changed, 51 insertions(+), 0 deletions(-)



------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


------------------------------

End of clisp-cvs Digest, Vol 78, Issue 3
****************************************

TAGS in clisp d-mode.el

[Compro P. <com...@gm...>]

I use GNU global for C/C++ source files which I was using till now for
the clisp sources too but I find everything a bit over complicated in
the source files with the *.c and *.h . I always have to go back to
*.d to refer to the actual definitions. But when I load the clisp
specific d-mode.el for the purpose I see that GNU global doesn't work
for it. Is it GNU global or d-mode.el itself?
If none then what is your config to get through the process?
I saw https://sourceforge.net/p/clisp/mailman/message/13043278/ where
Sam is saying about dropping comment5 and *.d which is from 2003. Why
they haven't been dropped yet?

New Swedish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

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 Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/sv.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:

    http://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:

    http://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...>

clisp-cvs Digest, Vol 78, Issue 2

[<cli...@li...>]

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: Update Swedish translation.
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Sun, 11 Jun 2017 10:10:43 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Update Swedish translation.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/9514359b2ef2
changeset: 15928:9514359b2ef22ce508346fb21e147ffadd4883f2
user:      Bruno Haible <br...@cl...>
date:      2017-06-11 12:10:09 +0200
description:
Update Swedish translation.

diffstat:

 src/ChangeLog          |    6 +
 src/po/clisplow_sv.gmo |  Bin 
 src/po/clisplow_sv.po  |  144 +++++-----
 src/po/sv.gmo          |  Bin 
 src/po/sv.po           |  607 ++++++++++++++++++++++++------------------------
 5 files changed, 382 insertions(+), 375 deletions(-)



------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


------------------------------

End of clisp-cvs Digest, Vol 78, Issue 2
****************************************

New Swedish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

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 Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/sv.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:

    http://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:

    http://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...>

Re: misnomers

[Reini U. <rei...@gm...>]

> On Jun 2, 2017, at 7:32 PM, Bruno Haible <br...@cl...> wrote:
> 
> Hi all,
> 
> There are a couple of wrong terms in the source code:
> 
> * NESTED_IBLOCK/ITAGBODY_frame_info, nest_fun, nest_env:
>  I'll rename "nested" to "captured".
>  Because what it does is to move values from the stack
>  (where they will disappear when the stack frame is unwound)
>  to other locations (where they cannot disappear, other
>  than being GCed).
> 
> * How to call the result of capturing a stack frame?
>  It's a simple-vector consisting of binding cells.
>  The previous term "closure" is wrong (see [1]).
>  I'm hesitating between
>    - "a capture" - because of the verb "capture" above,
>      but still a misnomer [2],
>    - "a prison" - because it's a container for *cell*s,
>      and contains *capture*d values.
> 
> Opinions? Objections?

nest_fun was originally Schachtelung (before 2001), then translated to nested.
nested means the stacked structure of the captures. Maybe stacked 
is better then as nested.
capture is mostly something else.

even the old german description was not good.
e.g.
nest_fun(env)
# UP: "nestet" ein FUN-Environment, d.h. schreibt alle aktiven Bindungen
# aus dem Stack in neu allozierte Vektoren.
=> /* UP: "nests" a FUN-Environment, i.e. writes all active bindings
 from the Stack into freshly allocated vectors.

maybe this is better: “adds a new stack frame of the fun-environment, 
 i.e. writes all active bindings from the stack into freshly allocated vectors."


> 
> Bruno
> 
> [1] https://en.wikipedia.org/wiki/Closure_(computer_programming)
> [2] http://wordnetweb.princeton.edu/perl/webwn?s=capture&sub=Search+WordNet&o2=&o0=1&o8=1&o1=1&o7=&o5=&o9=&o6=&o3=&o4=&h=

Reini Urban
ru...@cp...

Re: misnomers

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

> * Bruno Haible <oe...@py...t> [2017-06-08 00:00:25 +0200]:
>
> This is far enough away from clisp's internals
> that it won't lead to confusion.

Famous last words. :-(

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
http://islamexposedonline.com http://camera.org http://think-israel.org
To iterate is human; to recurse, divine.

Re: misnomers

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

Hi Sam,

> Note that "capture" already has a meaning in the computer domain.

You mean, screen capture? This is far enough away from clisp's internals
that it won't lead to confusion.

> You are looking for https://en.wiktionary.org/wiki/seiner ;-)

Hmm, still not quite there.

Is there some English term for a "row of cells"? "gallery of cells"?

Bruno

Re: misnomers

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

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2017-06-06 22:55:04 +0200]:
>
>> What you are doing is _fishing_ stuff from stack and storing it into
>> heap - how about "haul"?
>
> Thanks for the suggestion.
>
> "haul" means "pulling with force" or "steal".[1][2]

And "capture" means "a seizing by force or stratagem".

> It doesn't fit very well with the NESTED_IBLOCK/ITAGBODY_frame_info,
> nest_fun, nest_env situation, IMO.

I respectfully disagree.

>> "Capture" fails the grep test above.
>
> Hardly:
> $ grep -ri capture src/*.{d,lisp} | wc -l
> 5

Don't cheat. ;-)

$ grep -ri capture . | wc -l
      79

> I think 5 random occurrences of the same word in the code are acceptable.

I respectfully disagree.

> I'm looking for a word for a building that consists of several
> interconnected rows of cells. Gulags and KZs consisted of barracks,
> not rows. Maybe "palace" is better than "prison"?

You are looking for https://en.wiktionary.org/wiki/seiner ;-)

Note that "capture" already has a meaning in the computer domain.
Haul, seiner &c do not.

I urge you to take the `grep -ri .` test more seriously.
You are about to make the same mistake you made years ago when you
commented your code in German and introduced gratuitous changes to C
syntax.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://think-israel.org https://ffii.org http://honestreporting.com
Never argue with an idiot, listeners may not be able to tell the difference.

[PATCH] Improve support for Hurd: define IS_EINVAL_EXTRA and avoid using MAXPATHLEN

[Flavio C. <fla...@gm...>]

diff -r 2b929ec66611 -r a93e57b79b04 modules/syscalls/calls.c
--- a/modules/syscalls/calls.c	Fri Jun 02 19:05:29 2017 +0200
+++ b/modules/syscalls/calls.c	Wed Jun 07 01:17:30 2017 -0400
@@ -5877,12 +5877,15 @@
   /* if DATEMSK is not set, set it to the clisp-supplied value */
   if (NULL == getenv("DATEMSK")) {
     with_string_0(physical_namestring(GLO(lib_dir)),GLO(pathname_encoding),ldz,{
-        char datemsk[MAXPATHLEN];
+        /* use enough space for datemsk */
+        const size_t datemsk_len = ldz_len + 1 + strlen("/syscalls/datemsk");
+        char *datemsk = malloc(sizeof(char) * datemsk_len);
         strcpy(datemsk,ldz);
         if (ldz[ldz_len-1] == '/')
           strcat(datemsk,"syscalls/datemsk");
         else strcat(datemsk,"/syscalls/datemsk");
         setenv("DATEMSK",datemsk,0);
+        free(datemsk);
       });
   }
 }
diff -r 2b929ec66611 -r a93e57b79b04 src/stream.d
--- a/src/stream.d	Fri Jun 02 19:05:29 2017 +0200
+++ b/src/stream.d	Wed Jun 07 01:17:30 2017 -0400
@@ -3501,6 +3501,8 @@
   #define IS_EINVAL_EXTRA  ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV))
 #elif defined(UNIX_SUNOS5)
   #define IS_EINVAL_EXTRA  ((errno==ENXIO))
+#elif defined(UNIX_HURD)
+  #define IS_EINVAL_EXTRA  ((errno==EOPNOTSUPP)||(errno==EMIG_BAD_ID))
 #else
   #define IS_EINVAL_EXTRA  0
 #endif

Re: misnomers

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

Hi Sam,

> What you are doing is _fishing_ stuff from stack and storing it into
> heap - how about "haul"?

Thanks for the suggestion.

"haul" means "pulling with force" or "steal".[1][2] It doesn't fit
very well with the NESTED_IBLOCK/ITAGBODY_frame_info, nest_fun,
nest_env situation, IMO.

> "Capture" fails the grep test above.

Hardly:
$ grep -ri capture src/*.{d,lisp} | wc -l
5

I think 5 random occurrences of the same word in the code are acceptable.

> > * How to call the result of capturing a stack frame?
> >   It's a simple-vector consisting of binding cells.
> >   The previous term "closure" is wrong (see [1]).
> >   I'm hesitating between
> >     - "a capture" - because of the verb "capture" above,
> >       but still a misnomer [2],
> >     - "a prison" - because it's a container for *cell*s,
> >       and contains *capture*d values.
> 
> gulag? kz? ;-)

I'm looking for a word for a building that consists of several interconnected
rows of cells. Gulags and KZs consisted of barracks, not rows. Maybe "palace"
is better than "prison"?

Bruno

[1] https://en.wiktionary.org/wiki/haul
[2] https://www.merriam-webster.com/dictionary/haul

Re: misnomers

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

Hi Jörg,

> I remember the term "display closure" from Scheme compilers / compilation techniques.
> 
> The Development of Chez Scheme
> R. Kent Dybvig
> https://www.cs.indiana.edu/~dyb/pubs/hocs.pdf
> 
> "While researching
> how other systems had coped with similar problems, I ran across
> a book on the implementation of Algol 60 by Brian Randell and
> Lawford Russell [46], which described the use of displays for
> speeding access to the free variables of a local function. A display is
> a bank of memory locations or registers, each pointing to one of the
> frames whose variables make up the current lexical environment.
> Displays weren't directly usable for my purposes, but I was able
> to make several adjustments and from the display model derived
> the notion of a display closure, a heap-allocated vector-like object
> holding a code pointer and the values of the free variables [16]."

Thanks for the pointer. This "display closure" is a special case of closure
(since it contains a code pointer). And the "display" (what a term!) is a
vector-like arrangement, whereas in clisp we have a tree/forest-like
arrangement.

=> I won't use these terms.

Bruno

Re: misnomers

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

> * Bruno Haible <oe...@py...t> [2017-06-02 19:32:43 +0200]:
>
> There are a couple of wrong terms in the source code:

In addition to being semantically correct, an important requirement is
that it should never be used anywhere in any other sense.
Ideally, it should be a new term in the source tree (`grep -ri new-term .`
should print nothing in the top directory).

> * NESTED_IBLOCK/ITAGBODY_frame_info, nest_fun, nest_env:
>   I'll rename "nested" to "captured".
>   Because what it does is to move values from the stack
>   (where they will disappear when the stack frame is unwound)
>   to other locations (where they cannot disappear, other
>   than being GCed).

"Capture" fails the grep test above.

What you are doing is _fishing_ stuff from stack and storing it into
heap - how about "haul"?

It appears in the tree as LOOP-SYNTAX-OVERHAUL:REPAIR in docs and in a
FIXME note in sources.

> * How to call the result of capturing a stack frame?
>   It's a simple-vector consisting of binding cells.
>   The previous term "closure" is wrong (see [1]).
>   I'm hesitating between
>     - "a capture" - because of the verb "capture" above,
>       but still a misnomer [2],
>     - "a prison" - because it's a container for *cell*s,
>       and contains *capture*d values.

gulag? kz? ;-)

You store your haul in a freezer.

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org
http://no2bds.org http://mideasttruth.com http://memri.org
What garlic is to food, insanity is to art.

clisp-cvs Digest, Vol 78, Issue 1

[<cli...@li...>]

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: Rename frame type CHANDLER to C_HANDLER.
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Fri, 02 Jun 2017 17:17:01 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Rename frame type CHANDLER to C_HANDLER.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2b929ec66611
changeset: 15927:2b929ec66611c31218c6b531db6fdfa8e129edf0
user:      Bruno Haible <br...@cl...>
date:      2017-06-02 19:05:29 +0200
description:
Rename frame type CHANDLER to C_HANDLER.

diffstat:

 src/ChangeLog         |  15 +++++++++++++++
 src/eval.d            |   2 +-
 src/io.d              |   6 +++---
 src/lispbibl.d        |  44 ++++++++++++++++++++++----------------------
 src/pathname.d        |  14 +++++++-------
 src/spvw_garcol.d     |   2 +-
 src/spvw_garcol_old.d |   2 +-
 src/spvw_update.d     |   2 +-
 src/stream.d          |  30 +++++++++++++++---------------
 9 files changed, 66 insertions(+), 51 deletions(-)



------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


------------------------------

End of clisp-cvs Digest, Vol 78, Issue 1
****************************************

Re: misnomers

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

Hi,

Bruno asked:

>There are a couple of wrong terms in the source code:

>* How to call the result of capturing a stack frame?
>  It's a simple-vector consisting of binding cells.
>  The previous term "closure" is wrong (see [1]).
>  I'm hesitating between
>    - "a capture" - because of the verb "capture" above,
>      but still a misnomer [2],
>    - "a prison" - because it's a container for *cell*s,
>      and contains *capture*d values.

I remember the term "display closure" from Scheme compilers / compilation techniques.

The Development of Chez Scheme
R. Kent Dybvig
https://www.cs.indiana.edu/~dyb/pubs/hocs.pdf

"While researching
how other systems had coped with similar problems, I ran across
a book on the implementation of Algol 60 by Brian Randell and
Lawford Russell [46], which described the use of displays for
speeding access to the free variables of a local function. A display is
a bank of memory locations or registers, each pointing to one of the
frames whose variables make up the current lexical environment.
Displays weren't directly usable for my purposes, but I was able
to make several adjustments and from the display model derived
the notion of a display closure, a heap-allocated vector-like object
holding a code pointer and the values of the free variables [16]."

Regards,
	Jörg

Re: xmutex vs xlock

[Vladimir T. <vtz...@gm...>]

On Mon, Jun 5, 2017 at 12:24 AM, Compro Prasad <com...@gm...>
wrote:

> I don't see the point in having "xmutex_t" defined as "xlock_t" and
> "xmutex_raw_t" defined as "pthread_mutex_t". I mean how is xmutex_t
> related to xmutex_raw_t ? I see it as a redundant definition which
> makes the real definition look clumsy.
>


xlock_t helps to implement THREAD-INTERRUPT (and thus CALL-WITH-TIMEOUT,
THREAD-KILL) in safe way. THREAD-INTERRUPT is implemented by sending
SIGUSR1 to the thread which then is interrupted at so called GC_SAFE
regions. Waiting with pthread_mutex_lock is such GC_SAFE region but
interrupting it may/will leave the pthread_mutex_t internals in
inconsistent state.

xlock_t helps with unblocking threads waiting on mutexes when interrupt
should be handled.