From ron at flownet.com  Sun May  1 12:26:45 2016
From: ron at flownet.com (Ron Garret)
Date: Sun, 1 May 2016 12:26:45 -0700
Subject: [Openmcl-devel] CCL kernel coding style question
Message-ID: <CF9D80D8-1618-4C58-9AF0-0ED1B1FD3B57@flownet.com>

The CCL kernel C code is written in this style

return_type
function_name(args?)
{
  code?

Instead of what has always seemed to me to be the much more readable (and conservative of screen real estate):

return_type function_name(args) {
  code?

Because I hold the CCL developers in the highest regard I thought I would ask: is there a reason you chose the first style over the second?

rg



From pjb at informatimago.com  Sun May  1 12:47:32 2016
From: pjb at informatimago.com (Pascal J. Bourguignon)
Date: Sun, 01 May 2016 21:47:32 +0200
Subject: [Openmcl-devel] CCL kernel coding style question
References: <CF9D80D8-1618-4C58-9AF0-0ED1B1FD3B57@flownet.com>
Message-ID: <87d1p55zmz.fsf@kuiper.lan.informatimago.com>

Ron Garret <ron at flownet.com> writes:

> The CCL kernel C code is written in this style
>
> return_type
> function_name(args?)
> {
>   code?
>
> Instead of what has always seemed to me to be the much more readable
> (and conservative of screen real estate):
>
> return_type function_name(args) {
>   code?
>
> Because I hold the CCL developers in the highest regard I thought I
> would ask: is there a reason you chose the first style over the
> second?

Obviously you've never programmed in Pascal.

C is a loony and twisted language.
Who puts the type first and the variable second?

The place of the return type of a function obviously is AFTER the
function signature.

The consequence of putting types and modifiers first, is that their size
having a high variance, the function names and parameters cannot easily
be aligned anymore.

    export t1 foo(?);
    export ttttttyyyyyyppppppeeeeee22222 bar(?);

or:

    export t1                            foo(?);
    export ttttttyyyyyyppppppeeeeee22222 bar(?);

both are ugly.


Instead, in a sane programming language:

    function foo(?):t1;
    function bar(?):ttttttyyyyyyppppppeeeeee22222;

things are nicely aligned.


So one way to recover some sanity in C, to the cost of having to ignore
every other line, is to put the return type on its own line.


    export t1
    foo(?);
    export ttttttyyyyyyppppppeeeeee22222
    bar(?);

(You may use grep -v export).


An alternative is to align this way:

    export t1                            foo(?);
    export ttttttyyyyyyppppppeeeeee22222 bar(?);

but when you start doing it for parameter types too, it gives lines that
are really too wide.  And it's difficult to be consistent in all
sections of code.

Another alternative that I used when I still programmed in C was to use
macros:

    PROCEDURE(foo,(?),t1)
    PROCEDURE(bar,(?),ttttttyyyyyyppppppeeeeee22222)

and with different definitions of the macro in header and in source
files, to paper over the required syntactic differences.  But the
problem with C macros is that they're not taken into account by editors
and IDEs, and few C programmer use them (I notice heavy use of C macros
only in lisp implementation sources written by lispers).


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
?The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.? -- Carl Bass CEO Autodesk



From arthur.cater at ucd.ie  Sun May  1 13:50:07 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Sun, 1 May 2016 21:50:07 +0100
Subject: [Openmcl-devel] CCL kernel coding style question
In-Reply-To: <87d1p55zmz.fsf@kuiper.lan.informatimago.com>
References: <CF9D80D8-1618-4C58-9AF0-0ED1B1FD3B57@flownet.com>
 <87d1p55zmz.fsf@kuiper.lan.informatimago.com>
Message-ID: <EB7048C8-E6D7-412D-B3CD-05BB83CF4633@ucd.ie>


> On May 1, 2016, at 8:47 PM, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
<snip>

> and IDEs, and few C programmer use them (I notice heavy use of C macros
> only in lisp implementation sources written by lispers).

Interesting remark!  Here?s one (counter?)example:
http://fileadmin.cs.lth.se/cs/Personal/Tomas_Akenine-Moller/code/opttritri.txt <http://fileadmin.cs.lth.se/cs/Personal/Tomas_Akenine-Moller/code/opttritri.txt>

Arthur

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160501/5ef2eab7/attachment.htm>

From ron at flownet.com  Sun May  1 13:55:26 2016
From: ron at flownet.com (Ron Garret)
Date: Sun, 1 May 2016 13:55:26 -0700
Subject: [Openmcl-devel] CCL kernel coding style question
In-Reply-To: <87d1p55zmz.fsf@kuiper.lan.informatimago.com>
References: <CF9D80D8-1618-4C58-9AF0-0ED1B1FD3B57@flownet.com>
 <87d1p55zmz.fsf@kuiper.lan.informatimago.com>
Message-ID: <BEACFE2B-1AE8-49D6-9E25-7FA091040485@flownet.com>


On May 1, 2016, at 12:47 PM, Pascal J. Bourguignon <pjb at informatimago.com> wrote:

> Ron Garret <ron at flownet.com> writes:
> 
>> The CCL kernel C code is written in this style
>> 
>> return_type
>> function_name(args?)
>> {
>>  code?
>> 
>> Instead of what has always seemed to me to be the much more readable
>> (and conservative of screen real estate):
>> 
>> return_type function_name(args) {
>>  code?
>> 
>> Because I hold the CCL developers in the highest regard I thought I
>> would ask: is there a reason you chose the first style over the
>> second?
> 
> Obviously you've never programmed in Pascal.

Why is that obvious?  (Because in point of fact I have coded in Pascal, though not for a long time.)

> C is a loony and twisted language.
> Who puts the type first and the variable second?
> 
> The place of the return type of a function obviously is AFTER the
> function signature.

No argument from me there.  But that?s kind of beside the point.

> The consequence of putting types and modifiers first, is that their size
> having a high variance, the function names and parameters cannot easily
> be aligned anymore.
> 
>    export t1 foo(?);
>    export ttttttyyyyyyppppppeeeeee22222 bar(?);
> 
> or:
> 
>    export t1                            foo(?);
>    export ttttttyyyyyyppppppeeeeee22222 bar(?);
> 
> both are ugly.
> 
> 
> Instead, in a sane programming language:
> 
>    function foo(?):t1;
>    function bar(?):ttttttyyyyyyppppppeeeeee22222;
> 
> things are nicely aligned.
> 
> 
> So one way to recover some sanity in C, to the cost of having to ignore
> every other line, is to put the return type on its own line.
> 
> 
>    export t1
>    foo(?);
>    export ttttttyyyyyyppppppeeeeee22222
>    bar(?);

Vertical alignment only helps if the things that are vertically aligned with each other are all associated with each other.  If you don?t follow that rule then vertical alignment doesn?t help very much.

Also, I?m talking about .c files here, not .h files, so the function definition lines are separated by blocks of code.  Seeing two function definitions close enough to each other to even tell that (let alone care if) they are vertically aligned is pretty rare in a .c file.

The .h files are all written in the more compact style where the function name and the type are on the same line.  This includes things like typedef structs, which are syntactically similar to a function definition in that they consist of an initial declaration followed by a curly-brace-delimited block.

> (You may use grep -v export).

How is that supposed to help?

In fact, one of the reasons that the more compact style is useful is that you can find the definition of a function by doing:

 grep function_name | grep ?{?

The ccl kernel style makes it much harder to find the place where a given function is defined.

rg



From pjb at informatimago.com  Sun May  1 13:59:03 2016
From: pjb at informatimago.com (Pascal J. Bourguignon)
Date: Sun, 01 May 2016 22:59:03 +0200
Subject: [Openmcl-devel] CCL kernel coding style question
References: <CF9D80D8-1618-4C58-9AF0-0ED1B1FD3B57@flownet.com>
 <87d1p55zmz.fsf@kuiper.lan.informatimago.com>
 <BEACFE2B-1AE8-49D6-9E25-7FA091040485@flownet.com>
Message-ID: <878tzt5wbs.fsf@kuiper.lan.informatimago.com>

Ron Garret <ron at flownet.com> writes:

>> (You may use grep -v export).
>
> How is that supposed to help?

For headers, it gives the list of functions with signatures.


> In fact, one of the reasons that the more compact style is useful is that you can find the definition of a function by doing:
>
>  grep function_name | grep ?{?
>
> The ccl kernel style makes it much harder to find the place where a given function is defined.

you can use grep -e ^function_name to find it.  All non-toplevel code
being indented, there should be a single match.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
?The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.? -- Carl Bass CEO Autodesk



From rme at clozure.com  Sun May  1 15:08:48 2016
From: rme at clozure.com (R. Matthew Emerson)
Date: Sun, 1 May 2016 18:08:48 -0400
Subject: [Openmcl-devel] CCL kernel coding style question
In-Reply-To: <CF9D80D8-1618-4C58-9AF0-0ED1B1FD3B57@flownet.com>
References: <CF9D80D8-1618-4C58-9AF0-0ED1B1FD3B57@flownet.com>
Message-ID: <2E703101-5E3D-4FF3-8B6C-29AB85769B54@clozure.com>


> On May 1, 2016, at 3:26 PM, Ron Garret <ron at flownet.com> wrote:
> 
> The CCL kernel C code is written in this style
> 
> return_type
> function_name(args?)
> {
>  code?
> 
> Instead of what has always seemed to me to be the much more readable (and conservative of screen real estate):
> 
> return_type function_name(args) {
>  code?
> 
> Because I hold the CCL developers in the highest regard I thought I would ask: is there a reason you chose the first style over the second?

I wasn't there when it all started, but it's a common traditional style.

https://en.wikipedia.org/wiki/Kernel_Normal_Form




From max at mr.gy  Thu May 12 07:19:53 2016
From: max at mr.gy (Max Rottenkolber)
Date: Thu, 12 May 2016 14:19:53 +0000 (UTC)
Subject: [Openmcl-devel] I made simple swank helper.
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
Message-ID: <nh23e9$b34$2@ger.gmane.org>

On Fri, 22 Apr 2016 19:32:04 +0900, Park SungMin wrote:

> currently slime (swank) support only :spawn *commuication-style* in ccl.
> so every eval in lisp-buffer, create new thread.
> sometimes it uncomfortable in ccl (i.e `(random 10)` always return same value...)
> 
> so I just implementation other *communication-style* ...
> https://github.com/byulparan/swank-helper
> 
> I used it about 10 days...and it seems works well.

Kudos!

Can we get this into the CCL somehow, e.g. enable this to be loaded using

 (require 'swank-helper)

in ~/.ccl-init.lisp?




From gb at clozure.com  Thu May 12 10:01:28 2016
From: gb at clozure.com (Gary Byers)
Date: Thu, 12 May 2016 11:01:28 -0600
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <nh23e9$b34$2@ger.gmane.org>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org>
Message-ID: <5734B6E8.9060101@clozure.com>

FWIW, I vote YES.

I don't claim to have though much (or at all) about what this means in 
practice, but I think
that anything that would allow people to use SLIME in CCL without the 
problems related to
spawning a new thread every tine they use (e.g.) C-M-X in Emacs is 
likely a very good thing

On 05/12/2016 08:19 AM, Max Rottenkolber wrote:
> On Fri, 22 Apr 2016 19:32:04 +0900, Park SungMin wrote:
>
>> currently slime (swank) support only :spawn *commuication-style* in ccl.
>> so every eval in lisp-buffer, create new thread.
>> sometimes it uncomfortable in ccl (i.e `(random 10)` always return same value...)
>>
>> so I just implementation other *communication-style* ...
>> https://github.com/byulparan/swank-helper
>>
>> I used it about 10 days...and it seems works well.
> Kudos!
>
> Can we get this into the CCL somehow, e.g. enable this to be loaded using
>
>   (require 'swank-helper)
>
> in ~/.ccl-init.lisp?
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel



From dfigrish at gmail.com  Thu May 12 13:50:25 2016
From: dfigrish at gmail.com (Dmitry Igrishin)
Date: Thu, 12 May 2016 23:50:25 +0300
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <5734B6E8.9060101@clozure.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
Message-ID: <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>

2016-05-12 20:01 GMT+03:00 Gary Byers <gb at clozure.com>:

> FWIW, I vote YES.
>
> I don't claim to have though much (or at all) about what this means in
> practice, but I think
> that anything that would allow people to use SLIME in CCL without the
> problems related to
> spawning a new thread every tine they use (e.g.) C-M-X in Emacs is likely
> a very good thing

BTW. I'm unhappy how the maintainers of SLIME merging pull requests. My
pull request
related to CCL https://github.com/slime/slime/pull/285 opened 5 months ago
still unmerged.
Does it mean that CCL is not first class implementation for SLIME
maintainers, and how
to deal with it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160512/6ae2923f/attachment.htm>

From max at mr.gy  Fri May 13 02:43:25 2016
From: max at mr.gy (Max Rottenkolber)
Date: Fri, 13 May 2016 09:43:25 +0000 (UTC)
Subject: [Openmcl-devel] I made simple swank helper.
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
Message-ID: <nh47jt$ccr$1@ger.gmane.org>

On Thu, 12 May 2016 23:50:25 +0300, Dmitry Igrishin wrote:

> 2016-05-12 20:01 GMT+03:00 Gary Byers <gb at clozure.com>:
> 
>> FWIW, I vote YES.
>>
>> I don't claim to have though much (or at all) about what this means in
>> practice, but I think that anything that would allow people to use SLIME in
>> CCL without the problems related to spawning a new thread every tine they
>> use (e.g.) C-M-X in Emacs is likely a very good thing
> 
> BTW. I'm unhappy how the maintainers of SLIME merging pull requests. My pull
> request related to CCL https://github.com/slime/slime/pull/285 opened 5
> months ago still unmerged.

I would assume that they simply forgot about it. Try pinging @luismbo in the PR
thread, and ask for what is preventing it from being merged? It is very easy to
loose track of GitHub issues... :-)

> Does it mean that CCL is not first class implementation for SLIME
> maintainers, and how to deal with it?

If that really was the case?which I doubt?the proper way to deal with it would
be to become a SLIME maintainer yourself and ?adopt? CCL support.




From gb at clozure.com  Fri May 13 10:02:38 2016
From: gb at clozure.com (Gary Byers)
Date: Fri, 13 May 2016 11:02:38 -0600
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <nh47jt$ccr$1@ger.gmane.org>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org>
Message-ID: <573608AE.2070406@clozure.com>

I don't use SLIME at all, largely because of the :COMMUNICATION-STYLE 
:SPAWN issues
that Park Sungmin's patch tries to address and avoid.  I have always 
assumed that people
who do use SLIME with CCL either don't notice those issues or don't care 
about them as much
as I do, and that people who use SLIME with other implementations don't 
experience the same
issues because of (possibly very subtle) implementation-dependent 
details related to how
threads and dynamic/special variable bindings interact with each other.  
People do run into
those issues fairly often, and my explanations of those issues seem to 
fall on deaf (or at
least very bored) ears.

I'd be glad to get swank-helper into the CCL distribution, and will try 
to do that as soon
as I can.  Sometimes, things can get lost in the shuffle for very 
mundane reasons.  I almost
missed this message thread because of problems with the spam filtering 
service that I use,
and when I say "as soon as I can", I naturally mean "as soon as all of 
those lonely attractive women
who want to meet me" stop sending me as much email as they have been 
sending me lately.


On 05/13/2016 03:43 AM, Max Rottenkolber wrote:
> On Thu, 12 May 2016 23:50:25 +0300, Dmitry Igrishin wrote:
>
>> 2016-05-12 20:01 GMT+03:00 Gary Byers <gb at clozure.com>:
>>
>>> FWIW, I vote YES.
>>>
>>> I don't claim to have though much (or at all) about what this means in
>>> practice, but I think that anything that would allow people to use SLIME in
>>> CCL without the problems related to spawning a new thread every tine they
>>> use (e.g.) C-M-X in Emacs is likely a very good thing
>> BTW. I'm unhappy how the maintainers of SLIME merging pull requests. My pull
>> request related to CCL https://github.com/slime/slime/pull/285 opened 5
>> months ago still unmerged.
> I would assume that they simply forgot about it. Try pinging @luismbo in the PR
> thread, and ask for what is preventing it from being merged? It is very easy to
> loose track of GitHub issues... :-)
>
>> Does it mean that CCL is not first class implementation for SLIME
>> maintainers, and how to deal with it?
> If that really was the case?which I doubt?the proper way to deal with it would
> be to become a SLIME maintainer yourself and ?adopt? CCL support.
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel



From dfigrish at gmail.com  Fri May 13 14:58:14 2016
From: dfigrish at gmail.com (Dmitry Igrishin)
Date: Sat, 14 May 2016 00:58:14 +0300
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <nh47jt$ccr$1@ger.gmane.org>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org>
Message-ID: <CAP+w2Go3cKXFT8=Cy7ig39PLzV9RahgGBv+DyG6qELV5ajDY4A@mail.gmail.com>

2016-05-13 12:43 GMT+03:00 Max Rottenkolber <max at mr.gy>:

> On Thu, 12 May 2016 23:50:25 +0300, Dmitry Igrishin wrote:
>
> > 2016-05-12 20:01 GMT+03:00 Gary Byers <gb at clozure.com>:
> >
> >> FWIW, I vote YES.
> >>
> >> I don't claim to have though much (or at all) about what this means in
> >> practice, but I think that anything that would allow people to use
> SLIME in
> >> CCL without the problems related to spawning a new thread every tine
> they
> >> use (e.g.) C-M-X in Emacs is likely a very good thing
> >
> > BTW. I'm unhappy how the maintainers of SLIME merging pull requests. My
> pull
> > request related to CCL https://github.com/slime/slime/pull/285 opened 5
> > months ago still unmerged.
>
> I would assume that they simply forgot about it. Try pinging @luismbo in
> the PR
> thread, and ask for what is preventing it from being merged? It is very
> easy to
> loose track of GitHub issues... :-)
>
Well, okay, I'll try.

>
> > Does it mean that CCL is not first class implementation for SLIME
> > maintainers, and how to deal with it?
>
> If that really was the case?which I doubt?the proper way to deal with it
> would
> be to become a SLIME maintainer yourself and ?adopt? CCL support.
>
How to became a maintainer? The only way I know is a fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160514/f0e4687b/attachment.htm>

From dfigrish at gmail.com  Fri May 13 15:03:52 2016
From: dfigrish at gmail.com (Dmitry Igrishin)
Date: Sat, 14 May 2016 01:03:52 +0300
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <573608AE.2070406@clozure.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
Message-ID: <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>

2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com>:

> I don't use SLIME at all, largely because of the :COMMUNICATION-STYLE
> :SPAWN issues
> that Park Sungmin's patch tries to address and avoid.  I have always
> assumed that people
> who do use SLIME with CCL either don't notice those issues or don't care
> about them as much
> as I do, and that people who use SLIME with other implementations don't
> experience the same
> issues because of (possibly very subtle) implementation-dependent details
> related to how
> threads and dynamic/special variable bindings interact with each other.
> People do run into
> those issues fairly often, and my explanations of those issues seem to
> fall on deaf (or at
> least very bored) ears.
>
Gary, could you explain please your workflow on hacking Lisp without using
the SLIME? I've
always considered it as a de facto standard free IDE for Lisp.

>
> I'd be glad to get swank-helper into the CCL distribution, and will try to
> do that as soon
> as I can.  Sometimes, things can get lost in the shuffle for very mundane
> reasons.  I almost
> missed this message thread because of problems with the spam filtering
> service that I use,
> and when I say "as soon as I can", I naturally mean "as soon as all of
> those lonely attractive women
> who want to meet me" stop sending me as much email as they have been
> sending me lately.

:-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160514/6643586d/attachment.htm>

From gb at clozure.com  Sat May 14 08:19:04 2016
From: gb at clozure.com (Gary Byers)
Date: Sat, 14 May 2016 09:19:04 -0600
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
 <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
Message-ID: <573741E8.8020202@clozure.com>



On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>
>
> 2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com 
> <mailto:gb at clozure.com>>:
>
>     I don't use SLIME at all, largely because of the
>     :COMMUNICATION-STYLE :SPAWN issues
>     that Park Sungmin's patch tries to address and avoid.  I have
>     always assumed that people
>     who do use SLIME with CCL either don't notice those issues or
>     don't care about them as much
>     as I do, and that people who use SLIME with other implementations
>     don't experience the same
>     issues because of (possibly very subtle) implementation-dependent
>     details related to how
>     threads and dynamic/special variable bindings interact with each
>     other.  People do run into
>     those issues fairly often, and my explanations of those issues
>     seem to fall on deaf (or at
>     least very bored) ears.
>
> Gary, could you explain please your workflow on hacking Lisp without 
> using the SLIME? I've
> always considered it as a de facto standard free IDE for Lisp.
>
I usually us ilisp. which only works at all under xemacs.  ilisp 
development nominally stopped about
10-12 years ago, and whether or not xemacs is still being developed is 
unclear.  I don't think that
using ilisp is a desirable  option for anyone (including me)There have 
been other things that have bothered me about
SLIME (as well the communication-style/spawn issues), but I would move 
away from ilisp in a heartbeat
if not for those issues.

I -think- that most people would agree that selecting and executing a 
set of lisp forms from an editor buffer
should ideally be equivalent to (though perhaps more convenient than) 
executing the same set of forms by typing
them directly into a REPL in some sort of terminal window.  When the 
forms in question depend on and/or modify
the dynamic execution context (thread, and thread-specific dynamic 
variable bindings) in which they are executed, this
may not be true
Whether or not someone is affected by these issues and the degree to 
which they are likely depends on their editing
style and habits; people may find that it simply works better to select 
and execute an entire PROGN than it does to
select and execute each of that PROGN's subforms, even if they may not 
be entirely clear on on why this is the case.
see (for instance) 
<https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>, 
where that
message was part of a discussion about apparent differences between what 
the language spec says and what some
widely-used QuickLisp package expects.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160514/2a78440a/attachment.htm>

From wws at clozure.com  Sat May 14 08:37:00 2016
From: wws at clozure.com (Bill St. Clair)
Date: Sat, 14 May 2016 11:37:00 -0400
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <573741E8.8020202@clozure.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
 <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
 <573741E8.8020202@clozure.com>
Message-ID: <CAARJRB6byHRHgcoLdJm+SvLh37ZU9QNRjTe0v+d+nAgNZbhuEA@mail.gmail.com>

I finally looked at the swank-helper package, and played with my Slime a
little bit to determine why I?ve never noticed the problem. It?s my style
of using Slime. I evaluate random forms in the *slime-repl ccl* buffer,
which uses a single thread. The only evaluation I do from other lisp
buffers is recompiling defining forms in file buffers. For that it very
rarely matters that a new thread is spawned each time. So rarely that I
have never had a problem with it.

On Sat, May 14, 2016 at 11:19 AM, Gary Byers <gb at clozure.com> wrote:

>
>
> On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>
>
>
> 2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com>:
>
>> I don't use SLIME at all, largely because of the :COMMUNICATION-STYLE
>> :SPAWN issues
>> that Park Sungmin's patch tries to address and avoid.  I have always
>> assumed that people
>> who do use SLIME with CCL either don't notice those issues or don't care
>> about them as much
>> as I do, and that people who use SLIME with other implementations don't
>> experience the same
>> issues because of (possibly very subtle) implementation-dependent details
>> related to how
>> threads and dynamic/special variable bindings interact with each other.
>> People do run into
>> those issues fairly often, and my explanations of those issues seem to
>> fall on deaf (or at
>> least very bored) ears.
>>
> Gary, could you explain please your workflow on hacking Lisp without using
> the SLIME? I've
> always considered it as a de facto standard free IDE for Lisp.
>
> I usually us ilisp. which only works at all under xemacs.  ilisp
> development nominally stopped about
> 10-12 years ago, and whether or not xemacs is still being developed is
> unclear.  I don't think that
> using ilisp is a desirable  option for anyone (including me)There have
> been other things that have bothered me about
> SLIME (as well the communication-style/spawn issues), but I would move
> away from ilisp in a heartbeat
> if not for those issues.
>
> I -think- that most people would agree that selecting and executing a set
> of lisp forms from an editor buffer
> should ideally be equivalent to (though perhaps more convenient than)
> executing the same set of forms by typing
> them directly into a REPL in some sort of terminal window.  When the forms
> in question depend on and/or modify
> the dynamic execution context (thread, and thread-specific dynamic
> variable bindings) in which they are executed, this
> may not be true
> Whether or not someone is affected by these issues and the degree to which
> they are likely depends on their editing
> style and habits; people may find that it simply works better to select
> and execute an entire PROGN than it does to
> select and execute each of that PROGN's subforms, even if they may not be
> entirely clear on on why this is the case.
> see (for instance)
> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>
> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>,
> where that
> message was part of a discussion about apparent differences between what
> the language spec says and what some
> widely-used QuickLisp package expects.
>
>
>
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160514/0db1a0b3/attachment.htm>

From dfigrish at gmail.com  Sat May 14 16:23:28 2016
From: dfigrish at gmail.com (Dmitry Igrishin)
Date: Sun, 15 May 2016 02:23:28 +0300
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <573741E8.8020202@clozure.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
 <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
 <573741E8.8020202@clozure.com>
Message-ID: <CAP+w2GrMGNFynu4KwBRZ6wgA4YhTYN+quqSkepBrxVjdNANC7Q@mail.gmail.com>

2016-05-14 18:19 GMT+03:00 Gary Byers <gb at clozure.com>:

>
>
> On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>
>
>
> 2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com>:
>
>> I don't use SLIME at all, largely because of the :COMMUNICATION-STYLE
>> :SPAWN issues
>> that Park Sungmin's patch tries to address and avoid.  I have always
>> assumed that people
>> who do use SLIME with CCL either don't notice those issues or don't care
>> about them as much
>> as I do, and that people who use SLIME with other implementations don't
>> experience the same
>> issues because of (possibly very subtle) implementation-dependent details
>> related to how
>> threads and dynamic/special variable bindings interact with each other.
>> People do run into
>> those issues fairly often, and my explanations of those issues seem to
>> fall on deaf (or at
>> least very bored) ears.
>>
> Gary, could you explain please your workflow on hacking Lisp without using
> the SLIME? I've
> always considered it as a de facto standard free IDE for Lisp.
>
> I usually us ilisp. which only works at all under xemacs.  ilisp
> development nominally stopped about
> 10-12 years ago, and whether or not xemacs is still being developed is
> unclear.  I don't think that
> using ilisp is a desirable  option for anyone (including me)There have
> been other things that have bothered me about
> SLIME (as well the communication-style/spawn issues), but I would move
> away from ilisp in a heartbeat
> if not for those issues.
>
> I -think- that most people would agree that selecting and executing a set
> of lisp forms from an editor buffer
> should ideally be equivalent to (though perhaps more convenient than)
> executing the same set of forms by typing
> them directly into a REPL in some sort of terminal window.  When the forms
> in question depend on and/or modify
> the dynamic execution context (thread, and thread-specific dynamic
> variable bindings) in which they are executed, this
> may not be true
> Whether or not someone is affected by these issues and the degree to which
> they are likely depends on their editing
> style and habits; people may find that it simply works better to select
> and execute an entire PROGN than it does to
> select and execute each of that PROGN's subforms, even if they may not be
> entirely clear on on why this is the case.
> see (for instance)
> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>
> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>,
> where that
> message was part of a discussion about apparent differences between what
> the language spec says and what some
> widely-used QuickLisp package expects.
>
Thank you, Gary, for explanation. Sincere human communication now
deficiency, and this is sad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160515/ff768c66/attachment.htm>

From dfigrish at gmail.com  Sat May 14 16:47:54 2016
From: dfigrish at gmail.com (Dmitry Igrishin)
Date: Sun, 15 May 2016 02:47:54 +0300
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <CAARJRB6byHRHgcoLdJm+SvLh37ZU9QNRjTe0v+d+nAgNZbhuEA@mail.gmail.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
 <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
 <573741E8.8020202@clozure.com>
 <CAARJRB6byHRHgcoLdJm+SvLh37ZU9QNRjTe0v+d+nAgNZbhuEA@mail.gmail.com>
Message-ID: <CAP+w2Gpt=aLK_4xtKtQJZoKc-3j-KWMKS_yHDSM4+o5Y3EcQow@mail.gmail.com>

Hi Bill,

2016-05-14 18:37 GMT+03:00 Bill St. Clair <wws at clozure.com>:

> I finally looked at the swank-helper package, and played with my Slime a
> little bit to determine why I?ve never noticed the problem. It?s my style
> of using Slime. I evaluate random forms in the *slime-repl ccl* buffer,
> which uses a single thread. The only evaluation I do from other lisp
> buffers is recompiling defining forms in file buffers. For that it very
> rarely matters that a new thread is spawned each time. So rarely that I
> have never had a problem with it.
>
I don't tried the another IDE for Lisp called SLY -
https://github.com/capitaomorte/sly
but it looks interesting at the first glance. I'll try it at leisure.

>
> On Sat, May 14, 2016 at 11:19 AM, Gary Byers <gb at clozure.com> wrote:
>
>>
>>
>> On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>>
>>
>>
>> 2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com>:
>>
>>> I don't use SLIME at all, largely because of the :COMMUNICATION-STYLE
>>> :SPAWN issues
>>> that Park Sungmin's patch tries to address and avoid.  I have always
>>> assumed that people
>>> who do use SLIME with CCL either don't notice those issues or don't care
>>> about them as much
>>> as I do, and that people who use SLIME with other implementations don't
>>> experience the same
>>> issues because of (possibly very subtle) implementation-dependent
>>> details related to how
>>> threads and dynamic/special variable bindings interact with each other.
>>> People do run into
>>> those issues fairly often, and my explanations of those issues seem to
>>> fall on deaf (or at
>>> least very bored) ears.
>>>
>> Gary, could you explain please your workflow on hacking Lisp without
>> using the SLIME? I've
>> always considered it as a de facto standard free IDE for Lisp.
>>
>> I usually us ilisp. which only works at all under xemacs.  ilisp
>> development nominally stopped about
>> 10-12 years ago, and whether or not xemacs is still being developed is
>> unclear.  I don't think that
>> using ilisp is a desirable  option for anyone (including me)There have
>> been other things that have bothered me about
>> SLIME (as well the communication-style/spawn issues), but I would move
>> away from ilisp in a heartbeat
>> if not for those issues.
>>
>> I -think- that most people would agree that selecting and executing a set
>> of lisp forms from an editor buffer
>> should ideally be equivalent to (though perhaps more convenient than)
>> executing the same set of forms by typing
>> them directly into a REPL in some sort of terminal window.  When the
>> forms in question depend on and/or modify
>> the dynamic execution context (thread, and thread-specific dynamic
>> variable bindings) in which they are executed, this
>> may not be true
>> Whether or not someone is affected by these issues and the degree to
>> which they are likely depends on their editing
>> style and habits; people may find that it simply works better to select
>> and execute an entire PROGN than it does to
>> select and execute each of that PROGN's subforms, even if they may not be
>> entirely clear on on why this is the case.
>> see (for instance)
>> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>
>> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>,
>> where that
>> message was part of a discussion about apparent differences between what
>> the language spec says and what some
>> widely-used QuickLisp package expects.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160515/774ef846/attachment.htm>

From gb at clozure.com  Sun May 15 11:37:56 2016
From: gb at clozure.com (Gary Byers)
Date: Sun, 15 May 2016 12:37:56 -0600
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <CAP+w2Gpt=aLK_4xtKtQJZoKc-3j-KWMKS_yHDSM4+o5Y3EcQow@mail.gmail.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
 <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
 <573741E8.8020202@clozure.com>
 <CAARJRB6byHRHgcoLdJm+SvLh37ZU9QNRjTe0v+d+nAgNZbhuEA@mail.gmail.com>
 <CAP+w2Gpt=aLK_4xtKtQJZoKc-3j-KWMKS_yHDSM4+o5Y3EcQow@mail.gmail.com>
Message-ID: <5738C204.30003@clozure.com>

Bill:

I didn't see the message from you (presumably because of problems with 
my spam filter), but I did
see (and hopefully can reply to) this reply.

As far as you know, would people who use SLIME with CCL and want to 
avoid at least many of the
problems with :communication-style :spawn be able to do so by using 
SLIME-REPL, at least until
someone cam figure out how to make SWANK-HELPER easier to load?

(asked in very genuine ignorance of what "SLIME-REPL" is ..)

On 05/14/2016 05:47 PM, Dmitry Igrishin wrote:
> Hi Bill,
>
> 2016-05-14 18:37 GMT+03:00 Bill St. Clair <wws at clozure.com 
> <mailto:wws at clozure.com>>:
>
>     I finally looked at the swank-helper package, and played with my
>     Slime a little bit to determine why I?ve never noticed the
>     problem. It?s my style of using Slime. I evaluate random forms in
>     the *slime-repl ccl* buffer, which uses a single thread. The only
>     evaluation I do from other lisp buffers is recompiling defining
>     forms in file buffers. For that it very rarely matters that a new
>     thread is spawned each time. So rarely that I have never had a
>     problem with it.
>
> I don't tried the another IDE for Lisp called SLY - 
> https://github.com/capitaomorte/sly
> but it looks interesting at the first glance. I'll try it at leisure.
>
>
>     On Sat, May 14, 2016 at 11:19 AM, Gary Byers <gb at clozure.com
>     <mailto:gb at clozure.com>> wrote:
>
>
>
>         On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>>
>>
>>         2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com
>>         <mailto:gb at clozure.com>>:
>>
>>             I don't use SLIME at all, largely because of the
>>             :COMMUNICATION-STYLE :SPAWN issues
>>             that Park Sungmin's patch tries to address and avoid.  I
>>             have always assumed that people
>>             who do use SLIME with CCL either don't notice those
>>             issues or don't care about them as much
>>             as I do, and that people who use SLIME with other
>>             implementations don't experience the same
>>             issues because of (possibly very subtle)
>>             implementation-dependent details related to how
>>             threads and dynamic/special variable bindings interact
>>             with each other.  People do run into
>>             those issues fairly often, and my explanations of those
>>             issues seem to fall on deaf (or at
>>             least very bored) ears.
>>
>>         Gary, could you explain please your workflow on hacking Lisp
>>         without using the SLIME? I've
>>         always considered it as a de facto standard free IDE for Lisp.
>>
>         I usually us ilisp. which only works at all under xemacs. 
>         ilisp development nominally stopped about
>         10-12 years ago, and whether or not xemacs is still being
>         developed is unclear.  I don't think that
>         using ilisp is a desirable  option for anyone (including
>         me)There have been other things that have bothered me about
>         SLIME (as well the communication-style/spawn issues), but I
>         would move away from ilisp in a heartbeat
>         if not for those issues.
>
>         I -think- that most people would agree that selecting and
>         executing a set of lisp forms from an editor buffer
>         should ideally be equivalent to (though perhaps more
>         convenient than) executing the same set of forms by typing
>         them directly into a REPL in some sort of terminal window. 
>         When the forms in question depend on and/or modify
>         the dynamic execution context (thread, and thread-specific
>         dynamic variable bindings) in which they are executed, this
>         may not be true
>         Whether or not someone is affected by these issues and the
>         degree to which they are likely depends on their editing
>         style and habits; people may find that it simply works better
>         to select and execute an entire PROGN than it does to
>         select and execute each of that PROGN's subforms, even if they
>         may not be entirely clear on on why this is the case.
>         see (for instance)
>         <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>
>         <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>,
>         where that
>         message was part of a discussion about apparent differences
>         between what the language spec says and what some
>         widely-used QuickLisp package expects.
>
>
>
>
>
>
>         _______________________________________________
>         Openmcl-devel mailing list
>         Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>         https://lists.clozure.com/mailman/listinfo/openmcl-devel
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160515/0de5d7fb/attachment.htm>

From fabrice.popineau at gmail.com  Sun May 15 14:03:55 2016
From: fabrice.popineau at gmail.com (Fabrice Popineau)
Date: Sun, 15 May 2016 23:03:55 +0200
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
Message-ID: <CAFgFV9P08c1vxyYp6bXk_vb5bH=P4=2T3UDcXkN7crnXha6SHQ@mail.gmail.com>

2016-04-22 12:32 GMT+02:00 Park SungMin <byulparan_eng at icloud.com>:

> currently slime (swank) support only :spawn *commuication-style* in ccl.
> so every eval in lisp-buffer, create new thread.
> sometimes it uncomfortable in ccl (i.e `(random 10)` always return same
> value...)
>
> so I just implementation other *communication-style* ...
> https://github.com/byulparan/swank-helper
>
> I used it about 10 days...and it seems works well.
>
>
I tried it with the current version of CCL (1.12-dev) for Win64 and
I had to kill it every time I tried to C-x C-e from a lisp buffer.
I don't have much time to find and offer a fix, but I can try to help
to fix it if you want more information.

Regards,

Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160515/fdca10d5/attachment.htm>

From wws at clozure.com  Mon May 16 07:52:13 2016
From: wws at clozure.com (Bill St. Clair)
Date: Mon, 16 May 2016 10:52:13 -0400
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <5738C204.30003@clozure.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
 <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
 <573741E8.8020202@clozure.com>
 <CAARJRB6byHRHgcoLdJm+SvLh37ZU9QNRjTe0v+d+nAgNZbhuEA@mail.gmail.com>
 <CAP+w2Gpt=aLK_4xtKtQJZoKc-3j-KWMKS_yHDSM4+o5Y3EcQow@mail.gmail.com>
 <5738C204.30003@clozure.com>
Message-ID: <CAARJRB4HN6HXfyqrJHVds+wrH+fS6MxOkD-MY7tSCanfp05K_Q@mail.gmail.com>

At worst, when you want to evaluate a form in a lisp buffer that would
tickle the bug, you?d have to do an (in-package ?) in the Slime-REPL, to
match the buffer, copy the form from the buffer, paste it into the
slime-repl, and press <enter>. So yes, that is a reasonable workaround.

Slime, the way most of us use it, comes with a Slime Read-Eval-Print loop
buffer. Typing a form in that buffer sends it over to the connected lisp
process for evaluation, and prints the result, just as you would expect
from a REPL. It tends to be very slow if the result string is very long,
but that happens for me only rarely. The Slime-REPL, just like any other
Slime lisp-mode buffer, supports symbol completion, meta-. for definition
lookup, and connection to the slime inspector.

Bill

On Sun, May 15, 2016 at 2:37 PM, Gary Byers <gb at clozure.com> wrote:

> Bill:
>
> I didn't see the message from you (presumably because of problems with my
> spam filter), but I did
> see (and hopefully can reply to) this reply.
>
> As far as you know, would people who use SLIME with CCL and want to avoid
> at least many of the
> problems with :communication-style :spawn be able to do so by using
> SLIME-REPL, at least until
> someone cam figure out how to make SWANK-HELPER easier to load?
>
> (asked in very genuine ignorance of what "SLIME-REPL" is ..)
>
> On 05/14/2016 05:47 PM, Dmitry Igrishin wrote:
>
> Hi Bill,
>
> 2016-05-14 18:37 GMT+03:00 Bill St. Clair <wws at clozure.com>:
>
>> I finally looked at the swank-helper package, and played with my Slime a
>> little bit to determine why I?ve never noticed the problem. It?s my style
>> of using Slime. I evaluate random forms in the *slime-repl ccl* buffer,
>> which uses a single thread. The only evaluation I do from other lisp
>> buffers is recompiling defining forms in file buffers. For that it very
>> rarely matters that a new thread is spawned each time. So rarely that I
>> have never had a problem with it.
>>
> I don't tried the another IDE for Lisp called SLY -
> <https://github.com/capitaomorte/sly>https://github.com/capitaomorte/sly
> but it looks interesting at the first glance. I'll try it at leisure.
>
>>
>> On Sat, May 14, 2016 at 11:19 AM, Gary Byers < <gb at clozure.com>
>> gb at clozure.com> wrote:
>>
>>>
>>>
>>> On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>>>
>>>
>>>
>>> 2016-05-13 20:02 GMT+03:00 Gary Byers < <gb at clozure.com>gb at clozure.com>:
>>>
>>>> I don't use SLIME at all, largely because of the :COMMUNICATION-STYLE
>>>> :SPAWN issues
>>>> that Park Sungmin's patch tries to address and avoid.  I have always
>>>> assumed that people
>>>> who do use SLIME with CCL either don't notice those issues or don't
>>>> care about them as much
>>>> as I do, and that people who use SLIME with other implementations don't
>>>> experience the same
>>>> issues because of (possibly very subtle) implementation-dependent
>>>> details related to how
>>>> threads and dynamic/special variable bindings interact with each
>>>> other.  People do run into
>>>> those issues fairly often, and my explanations of those issues seem to
>>>> fall on deaf (or at
>>>> least very bored) ears.
>>>>
>>> Gary, could you explain please your workflow on hacking Lisp without
>>> using the SLIME? I've
>>> always considered it as a de facto standard free IDE for Lisp.
>>>
>>> I usually us ilisp. which only works at all under xemacs.  ilisp
>>> development nominally stopped about
>>> 10-12 years ago, and whether or not xemacs is still being developed is
>>> unclear.  I don't think that
>>> using ilisp is a desirable  option for anyone (including me)There have
>>> been other things that have bothered me about
>>> SLIME (as well the communication-style/spawn issues), but I would move
>>> away from ilisp in a heartbeat
>>> if not for those issues.
>>>
>>> I -think- that most people would agree that selecting and executing a
>>> set of lisp forms from an editor buffer
>>> should ideally be equivalent to (though perhaps more convenient than)
>>> executing the same set of forms by typing
>>> them directly into a REPL in some sort of terminal window.  When the
>>> forms in question depend on and/or modify
>>> the dynamic execution context (thread, and thread-specific dynamic
>>> variable bindings) in which they are executed, this
>>> may not be true
>>> Whether or not someone is affected by these issues and the degree to
>>> which they are likely depends on their editing
>>> style and habits; people may find that it simply works better to select
>>> and execute an entire PROGN than it does to
>>> select and execute each of that PROGN's subforms, even if they may not
>>> be entirely clear on on why this is the case.
>>> see (for instance)
>>> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>
>>> <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>,
>>> where that
>>> message was part of a discussion about apparent differences between what
>>> the language spec says and what some
>>> widely-used QuickLisp package expects.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160516/e914c0db/attachment.htm>

From gb at clozure.com  Mon May 16 10:53:23 2016
From: gb at clozure.com (Gary Byers)
Date: Mon, 16 May 2016 11:53:23 -0600
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <CAARJRB4HN6HXfyqrJHVds+wrH+fS6MxOkD-MY7tSCanfp05K_Q@mail.gmail.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <nh23e9$b34$2@ger.gmane.org> <5734B6E8.9060101@clozure.com>
 <CAP+w2GorymXb4-otjE-dFgOm+QitbXeNTxx_cBnzfq0R0ey+Bw@mail.gmail.com>
 <nh47jt$ccr$1@ger.gmane.org> <573608AE.2070406@clozure.com>
 <CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com>
 <573741E8.8020202@clozure.com>
 <CAARJRB6byHRHgcoLdJm+SvLh37ZU9QNRjTe0v+d+nAgNZbhuEA@mail.gmail.com>
 <CAP+w2Gpt=aLK_4xtKtQJZoKc-3j-KWMKS_yHDSM4+o5Y3EcQow@mail.gmail.com>
 <5738C204.30003@clozure.com>
 <CAARJRB4HN6HXfyqrJHVds+wrH+fS6MxOkD-MY7tSCanfp05K_Q@mail.gmail.com>
Message-ID: <573A0913.5000309@clozure.com>

let me try again ...

If one wanted to use SLIME with CCL and did not want to experience the 
effects of :communication-style :spawn,
would using the SLIME-REPL Emacs package avoid those effects?

As far as I know, that Emacs package is used if one's .emacs file does

(slime-setup '(slime-fancy))
which is actually what 
<http://trac.clozure.com/ccl/wiki/InstallingSlime> suggests.

As your earlier message said. SLIME-REPL does indeed create a persistent 
lisp
thread, and forms read from that buffer are executed in that thread

a simpler way of demonstrating the problem is to simply create a lisp 
buffer , type
a few forms (e.g., a few calls to (RANDOM 100)) into that buffer, and 
note how things
like C-X C-E create a new thread to execute each of them in succession.  
When I last
tried to use SLIME, there was no slime-repl buffer or slime-repl thread, 
and all
interaction with SLIME took place (in a buffer named SLIME IIRC) in 
freshly-created
threads (via :communication-style :spawn).  I think that everyone agrees 
that this
is undesirable in many cases; I'm tired of seeing bug reports from 
people who claim
that executing a sequence of calls to (RANDOM 100) - and having them all 
return the
same value - indicates a bug in RANDOM, and more tired of subtler cases 
that people
still run into and  seem to rarely understand


On 05/16/2016 08:52 AM, Bill St. Clair wrote:
> At worst, when you want to evaluate a form in a lisp buffer that would 
> tickle the bug, you?d have to do an (in-package ?) in the Slime-REPL, 
> to match the buffer, copy the form from the buffer, paste it into the 
> slime-repl, and press <enter>. So yes, that is a reasonable workaround.
>
> Slime, the way most of us use it, comes with a Slime Read-Eval-Print 
> loop buffer. Typing a form in that buffer sends it over to the 
> connected lisp process for evaluation, and prints the result, just as 
> you would expect from a REPL. It tends to be very slow if the result 
> string is very long, but that happens for me only rarely. The 
> Slime-REPL, just like any other Slime lisp-mode buffer, supports 
> symbol completion, meta-. for definition lookup, and connection to the 
> slime inspector.
>
> Bill
>
> On Sun, May 15, 2016 at 2:37 PM, Gary Byers <gb at clozure.com 
> <mailto:gb at clozure.com>> wrote:
>
>     Bill:
>
>     I didn't see the message from you (presumably because of problems
>     with my spam filter), but I did
>     see (and hopefully can reply to) this reply.
>
>     As far as you know, would people who use SLIME with CCL and want
>     to avoid at least many of the
>     problems with :communication-style :spawn be able to do so by
>     using SLIME-REPL, at least until
>     someone cam figure out how to make SWANK-HELPER easier to load?
>
>     (asked in very genuine ignorance of what "SLIME-REPL" is ..)
>
>     On 05/14/2016 05:47 PM, Dmitry Igrishin wrote:
>>     Hi Bill,
>>
>>     2016-05-14 18:37 GMT+03:00 Bill St. Clair <wws at clozure.com
>>     <mailto:wws at clozure.com>>:
>>
>>         I finally looked at the swank-helper package, and played with
>>         my Slime a little bit to determine why I?ve never noticed the
>>         problem. It?s my style of using Slime. I evaluate random
>>         forms in the *slime-repl ccl* buffer, which uses a single
>>         thread. The only evaluation I do from other lisp buffers is
>>         recompiling defining forms in file buffers. For that it very
>>         rarely matters that a new thread is spawned each time. So
>>         rarely that I have never had a problem with it.
>>
>>     I don't tried the another IDE for Lisp called SLY -
>>     https://github.com/capitaomorte/sly
>>     but it looks interesting at the first glance. I'll try it at
>>     leisure.
>>
>>
>>         On Sat, May 14, 2016 at 11:19 AM, Gary Byers <gb at clozure.com
>>         <mailto:gb at clozure.com>> wrote:
>>
>>
>>
>>             On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>>>
>>>
>>>             2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com
>>>             <mailto:gb at clozure.com>>:
>>>
>>>                 I don't use SLIME at all, largely because of the
>>>                 :COMMUNICATION-STYLE :SPAWN issues
>>>                 that Park Sungmin's patch tries to address and
>>>                 avoid. I have always assumed that people
>>>                 who do use SLIME with CCL either don't notice those
>>>                 issues or don't care about them as much
>>>                 as I do, and that people who use SLIME with other
>>>                 implementations don't experience the same
>>>                 issues because of (possibly very subtle)
>>>                 implementation-dependent details related to how
>>>                 threads and dynamic/special variable bindings
>>>                 interact with each other.  People do run into
>>>                 those issues fairly often, and my explanations of
>>>                 those issues seem to fall on deaf (or at
>>>                 least very bored) ears.
>>>
>>>             Gary, could you explain please your workflow on hacking
>>>             Lisp without using the SLIME? I've
>>>             always considered it as a de facto standard free IDE for
>>>             Lisp.
>>>
>>             I usually us ilisp. which only works at all under
>>             xemacs.  ilisp development nominally stopped about
>>             10-12 years ago, and whether or not xemacs is still being
>>             developed is unclear.  I don't think that
>>             using ilisp is a desirable option for anyone (including
>>             me)There have been other things that have bothered me about
>>             SLIME (as well the communication-style/spawn issues), but
>>             I would move away from ilisp in a heartbeat
>>             if not for those issues.
>>
>>             I -think- that most people would agree that selecting and
>>             executing a set of lisp forms from an editor buffer
>>             should ideally be equivalent to (though perhaps more
>>             convenient than) executing the same set of forms by typing
>>             them directly into a REPL in some sort of terminal
>>             window. When the forms in question depend on and/or modify
>>             the dynamic execution context (thread, and
>>             thread-specific dynamic variable bindings) in which they
>>             are executed, this
>>             may not be true
>>             Whether or not someone is affected by these issues and
>>             the degree to which they are likely depends on their editing
>>             style and habits; people may find that it simply works
>>             better to select and execute an entire PROGN than it does to
>>             select and execute each of that PROGN's subforms, even if
>>             they may not be entirely clear on on why this is the case.
>>             see (for instance)
>>             <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>
>>             <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>,
>>             where that
>>             message was part of a discussion about apparent
>>             differences between what the language spec says and what some
>>             widely-used QuickLisp package expects.
>>
>>
>>
>>
>>
>>
>>             _______________________________________________
>>             Openmcl-devel mailing list
>>             Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>>             https://lists.clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160516/bc603037/attachment.htm>

From gb at clozure.com  Mon May 16 12:10:57 2016
From: gb at clozure.com (Gary Byers)
Date: Mon, 16 May 2016 13:10:57 -0600
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <CAFgFV9P08c1vxyYp6bXk_vb5bH=P4=2T3UDcXkN7crnXha6SHQ@mail.gmail.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <CAFgFV9P08c1vxyYp6bXk_vb5bH=P4=2T3UDcXkN7crnXha6SHQ@mail.gmail.com>
Message-ID: <573A1B41.6040709@clozure.com>

Note that swank-helper uses the "select" system call which tries to wait 
until
some members of some sets of Unix file descriptors are ready to do some 
kinds of I/O
Some Windows C libraries may try to emulate some parts of what select 
tries to
do, but IIRC CCL on Windows mostly tries to do I/O without involving any 
C libraries.
The closest Windows analogue to select() might be 
WaitForMultipleObjects, and I don't
believe that you can generally wait for Windows file handles unless you 
know a lot
about what I/O operations are awaiting completion on that handle.

More generally, if swank-helper doesn't work on Windows, that is not 
surprising.
I don't know whether or not it could be made to work on Windows, or what 
would
be involved in that.


On 05/15/2016 03:03 PM, Fabrice Popineau wrote:
>
>
> 2016-04-22 12:32 GMT+02:00 Park SungMin <byulparan_eng at icloud.com 
> <mailto:byulparan_eng at icloud.com>>:
>
>     currently slime (swank) support only :spawn *commuication-style*
>     in ccl.
>     so every eval in lisp-buffer, create new thread.
>     sometimes it uncomfortable in ccl (i.e `(random 10)` always return
>     same value...)
>
>     so I just implementation other *communication-style* ...
>     https://github.com/byulparan/swank-helper
>
>     I used it about 10 days...and it seems works well.
>
>
> I tried it with the current version of CCL (1.12-dev) for Win64 and
> I had to kill it every time I tried to C-x C-e from a lisp buffer.
> I don't have much time to find and offer a fix, but I can try to help
> to fix it if you want more information.
>
> Regards,
>
> Fabrice
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160516/ec4cd9c7/attachment.htm>

From fabrice.popineau at gmail.com  Mon May 16 12:57:21 2016
From: fabrice.popineau at gmail.com (Fabrice Popineau)
Date: Mon, 16 May 2016 21:57:21 +0200
Subject: [Openmcl-devel] I made simple swank helper.
In-Reply-To: <573A1B41.6040709@clozure.com>
References: <D461B169-191A-4C68-86F9-B7C2AB70B464@icloud.com>
 <CAFgFV9P08c1vxyYp6bXk_vb5bH=P4=2T3UDcXkN7crnXha6SHQ@mail.gmail.com>
 <573A1B41.6040709@clozure.com>
Message-ID: <CAFgFV9P5L9hiua=s-rtJFBn2nWSTqXw5o+1vR=LR-a7o9qSMxw@mail.gmail.com>

2016-05-16 21:10 GMT+02:00 Gary Byers <gb at clozure.com>:

> Note that swank-helper uses the "select" system call which tries to wait
> until
> some members of some sets of Unix file descriptors are ready to do some
> kinds of I/O
> Some Windows C libraries may try to emulate some parts of what select
> tries to
> do, but IIRC CCL on Windows mostly tries to do I/O without involving any C
> libraries.
> The closest Windows analogue to select() might be WaitForMultipleObjects,
> and I don't
> believe that you can generally wait for Windows file handles unless you
> know a lot
> about what I/O operations are awaiting completion on that handle.
>
> More generally, if swank-helper doesn't work on Windows, that is not
> surprising.
> I don't know whether or not it could be made to work on Windows, or what
> would
> be involved in that.
>
>
In swank-helper/serve-event function, there is this call to  #_select that
I suppose will be resolved to the select() function
from winsock2. The main difference between this select() and the Unix one
is that the Unix one works with
both network sockets and file sockets whereas it does work only on network
sockets for Windows (IIRC).

When I tried swank-helper, it went into a loop consuming 100% CPU.

BTW, from what I tried, neither slime + repl nor sly are able to reuse the
same thread for C-x C-e.
Several calls in a row on (random 100) always return the same value for
both, at least under Windows.

Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160516/3166175d/attachment.htm>

From eric.marsden at free.fr  Fri May 20 09:21:06 2016
From: eric.marsden at free.fr (Eric Marsden)
Date: Fri, 20 May 2016 18:21:06 +0200
Subject: [Openmcl-devel] ARM32 compiler bug in ARM2-MAX-NFP-DEPTH
Message-ID: <87futc4s5p.fsf@free.fr>

Hello,

This is on ARM32/Linux.


? (lisp-implementation-version)
"Version 1.12-dev-r16739M-trunk  (LinuxARM32)"
? (defun foo (a)
   (declare (optimize (speed 0)))
   ((lambda (x y) (typep x (type-of y)))
      1
      (the (complex single-float) a)))
> Error: Array index 2 out of bounds for NIL .
> While executing: CCL::ARM2-MAX-NFP-DEPTH, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > :b
*(B6C632A8) : 0 (ARM2-MAX-NFP-DEPTH) 124
 (B6C632B8) : 1 (FUNCALL #'#<(:INTERNAL CCL::PARSE-OPERAND-FORM CCL::ARM2-EXPAND-VINSN)> (CCL::ARM2-MAX-NFP-DEPTH)) 660
 (B6C632D0) : 2 (FUNCALL #'#<(:INTERNAL CCL::EVAL-PREDICATE CCL::ARM2-EXPAND-VINSN)> (:PRED > (CCL::ARM2-MAX-NFP-DEPTH) 0)) 208
 (B6C632F8) : 3 (FUNCALL #'#<(:INTERNAL CCL::EXPAND-FORM CCL::ARM2-EXPAND-VINSN)> ((:PRED > # 0) (# #) (# # #) (# #) (# #) ...)) 468
 (B6C63308) : 4 (ARM2-EXPAND-VINSN #<@0 SAVE-NFP> #<DLL-HEADER #x144F82B6> #(#<DLL-HEADER #x144F82B6> #<DLL-HEADER #x144F829E>)) 1588
 (B6C63328) : 5 (ARM2-EXPAND-VINSNS #<VINSN-LIST #x144F9F0E> #<DLL-HEADER #x144F82B6> #(#<DLL-HEADER #x144F82B6> #<DLL-HEADER #x144F829E>)) 340
 (B6C63338) : 6 (ARM2-COMPILE #<CCL::AFUNC #x144FAD2E> NIL T) 2788
 (B6C63458) : 7 (COMPILE-NAMED-FUNCTION (LAMBDA (A) (DECLARE #) (DECLARE #) (BLOCK FOO #)) :NAME FOO :ENV #<CCL::LEXICAL-ENVIRONMENT #x144FAE1E> :FUNCTION-NOTE #<SOURCE-NOTE Interactive "(defun foo (a) (declare (optimize (speed 0))) ((lambda (x y) (typep x (type-of y))) 1 (the (complex single-float) a)))"> :KEEP-LAMBDA NIL :KEEP-SYMBOLS T :SOURCE-NOTES #<HASH-TABLE :TEST EQ size 26/60 #x144FE1A6>) 1956


-- 
Eric Marsden
https://risk-engineering.org/



From eric.marsden at free.fr  Sun May 22 14:26:43 2016
From: eric.marsden at free.fr (Eric Marsden)
Date: Sun, 22 May 2016 23:26:43 +0200
Subject: [Openmcl-devel] Compiler bug on ARM32 during
	ARM::INSERT-SHIFTER-CONSTANT
Message-ID: <87twhpzsvg.fsf@free.fr>

Hi,

More random-testing on ARM32.


? (lisp-implementation-version)
"Version 1.12-dev-r16742M-trunk  (LinuxARM32)"
? (defun foo (a)
   (- (the (eql 2230933738) a) 2770))
> Error: Can't encode ARM constant 2770.
> While executing: ARM::INSERT-SHIFTER-CONSTANT, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > :b
 (B6C392E8) : 0 (INSERT-SHIFTER-CONSTANT 2770 #<LAP-INSTRUCTION #x144F940E>) 600
 (B6C392F8) : 1 (FUNCALL #'#<(:INTERNAL CCL::EXPAND-INSN-FORM CCL::ARM2-EXPAND-VINSN)> ((57408 . 0) (3 0) (2 1) (6 2))) 1204
 (B6C39308) : 2 (ARM2-EXPAND-VINSN #<@0 0 := %NATURAL--C 0 2770> #<DLL-HEADER #x144F9A9E> #(#<DLL-HEADER #x144F9A9E> #<DLL-HEADER #x144F9A86>)) 1588
 (B6C39328) : 3 (ARM2-EXPAND-VINSNS #<VINSN-LIST #x144FA1B6> #<DLL-HEADER #x144F9A9E> #(#<DLL-HEADER #x144F9A9E> #<DLL-HEADER #x144F9A86>)) 340
 (B6C39338) : 4 (ARM2-COMPILE #<CCL::AFUNC #x144FB0CE> NIL T) 2788
 (B6C39458) : 5 (COMPILE-NAMED-FUNCTION (LAMBDA (A) (DECLARE #) (BLOCK FOO #)) :NAME FOO :ENV #<CCL::LEXICAL-ENVIRONMENT #x144FB1BE> :FUNCTION-NOTE #<SOURCE-NOTE Interactive "(defun foo (a) (- (the (eql 2230933738) a) 2770))"> :KEEP-LAMBDA NIL :KEEP-SYMBOLS T :SOURCE-NOTES #<HASH-TABLE :TEST EQ size 14/60 #x144FE1A6>) 1956
 (B6C394C8) : 6 (CHEAP-EVAL-FUNCTION FOO (LAMBDA (A) (DECLARE #) (BLOCK FOO #)) #<CCL::LEXICAL-ENVIRONMENT #x144FB1BE>) 172


-- 
Eric Marsden
https://risk-engineering.org/