clisp-devel — closed list for developers and testers

status update

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

Daniel,
the mid-term eval is now.
what is your status?
did you manage to build clisp with rawsock on windows?
if yes, please build a binary distribution ("make -f Makefile.devel distrib")
and make the binary available for download.
everyone with access to a windows box: please download and test.
alas, I am on vacation with sporadic internet access at best, so I
would appreciate any help I could get.
thanks

-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

Re: Questions regarding regexp module

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

Pascal wrote:
> Since the name of the C structure is regex_t, and since it contains
> one useful slot (re_nsub), perhaps you could name the type regex,
> and provide a regex-nsub reader.

Done.


Regarding the multiple values: regexp-exec allows to specify the
return type: multiple values, list, vector, boolean.

> IMO, it should always return multiple values, or always return a
> sequence.

I'd say to be consistent then, that is returning multiple values when
they're requested, and to follow what you wrote:

> just limit nmatch to multiple-values-limit or the actual number of
> expected values.

I pushed these changes to my "working fork".

Re: Questions regarding regexp module

[Pascal J. B. <pj...@in...>]

Daniel Jour <dan...@gm...> writes:

> I'm currently working on the regexp module (I'm still here in case
> anyone wondered). I've a few questions / suggestions:
>
> I think it would be good to have regexp-exec fail when there are more
> matches than the number of possible return values and it was specified
> to return the matches as multiple values.

This would go contrary to the CL specification that says that when a
function returns more values than expected, the superfluous values are
just ignored:

     (setf r (truncate 3 2)) ; would fail otherwise…
     
     
> Currently, regexp-exec then
> just returns the results as a list:
>
> // ...
> switch (rettype) {
> case ret_values:
> if (re_count < fixnum_to_V(Symbol_value(S(multiple_values_limit)))) {
> STACK_to_mv(re_count);
> break;
> } /* else FALLTHROUGH */
> case ret_list: VALUES1(listof(re_count)); break;
> // ...
>
> This could lead to surprises, when e.g. calling:
>
> (multiple-value-list (match some-pattern some-string))
>
> When match returns multiple values, one get's a list with the
> matches. But when - because of a different pattern - there are more
> matches then suddenly this returns a list with the list of matches,
> which could confuse code using the result. It's probably not that
> critical as one needs to have a pattern with 127 sub-expressions
> or more, though.

Indeed, this behavior is bad.  IMO, it should always return multiple
values, or always return a sequence.


Returning groups in multiple values
----------------------------------------

In CL, multiple-values-limit is 128.


The maximum number of groupings in POSIX regexp is not limited (only the
maximum number of groupings that can be referenced in posix regexp is
limited to 9).

Furthermore, the caller of regexec specifies the number of matches it
expects.  regexec will not return information about the remaining
groups.


These semantics are very compatible: just limit nmatch to
multiple-values-limit or the actual number of expected values.
(nmatch = 1+nsub, includes the group representing the whole regexp).



Returning groups in sequences
----------------------------------------

However, if we wanted to match regexps with more than 127 groups, we'd
have to get the resulting group matches in vectors.


cl-ppcre returns 4 values, including two vectors to hold the group matches:
http://weitz.de/cl-ppcre/#scan


In emacs lisp, the results are stored in a (hidden) global variable that
can be accessed thru functions such as match-beginning, match-end,
match-string, so basically with an internal sequence of unlimited size.







On one hand multiple values are a little more practical to use, and it's
rare to have more than 127 groups in a regexp.

On the other hand, returning vectors is a common API, and allows for any
number of groups without limitation.  This is also basically what the
underlying C API does.



In conclusion, it might be better to return the same thing as
cl-ppcre:scan: match-start, match-end, reg-starts, reg-ends.



> Next, currently regex-compile returns a foreign-pointer, and
> regex-exec expects a foreign pointer. Thus I could supply regexp-exec
> with a foreign pointer acquire from some other function, resulting in
> undefined behavior (because regexp-exec blindly assumes it to be a
> regex_t * ). AFAIK the policy for CLISP is to not just crash on such
> errors. As solution, I'd wrap the foreign pointer in a (defstruct
> pattern pointer). Are there any objections against this?

Since the name of the C structure is regex_t, and since it contains one
useful slot (re_nsub), perhaps you could name the type regex, and
provide a regex-nsub reader.


-- 
__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

Questions regarding regexp module

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

I'm currently working on the regexp module (I'm still here in case
anyone wondered). I've a few questions / suggestions:

I think it would be good to have regexp-exec fail when there are more
matches than the number of possible return values and it was specified
to return the matches as multiple values. Currently, regexp-exec then
just returns the results as a list:

// ...
switch (rettype) {
  case ret_values:
    if (re_count < fixnum_to_V(Symbol_value(S(multiple_values_limit)))) {
      STACK_to_mv(re_count);
      break;
    } /* else FALLTHROUGH */
  case ret_list:   VALUES1(listof(re_count)); break;
// ...

This could lead to surprises, when e.g. calling:

(multiple-value-list (match some-pattern some-string))

When match returns multiple values, one get's a list with the
matches. But when - because of a different pattern - there are more
matches then suddenly this returns a list with the list of matches,
which could confuse code using the result. It's probably not that
critical as one needs to have a pattern with 127 sub-expressions
or more, though.


Next, currently regex-compile returns a foreign-pointer, and
regex-exec expects a foreign pointer. Thus I could supply regexp-exec
with a foreign pointer acquire from some other function, resulting in
undefined behavior (because regexp-exec blindly assumes it to be a
regex_t * ). AFAIK the policy for CLISP is to not just crash on such
errors.  As solution, I'd wrap the foreign pointer in a (defstruct
pattern pointer). Are there any objections against this?

Re: Compilation on Windows 8 with Visual Studio 2013

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

Loic wrote:
> In the same time I'am trying to port the project on Visual Studios 2015,
> some part of the projects compile for now.

I'd be very interested in the changes you had to make. Please, if you
have the time, share your experiences :)

Loic wrote:
> I'am interested to contribute to the project, but the list of tasks
> (Help wanted), is up to date  ?

I wrote the libmagic module, though - as I did this mainly as a learning
exercise - it's still very rough (also due to that libmagic is not
exactly best documented, sigh).

Re: Compilation on Windows 8 with Visual Studio 2013

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

> * Loïc Maury <yznhel@tznvy.pbz> [2016-05-28 22:29:24 +0200]:
>
> I'am interested to contribute to the project, but the list of tasks
> (Help wanted), is up to date ?

Yes, http://clisp.org/wanted.html is as relevant as ever.
The main task now is to make a release, and Daniel is working on that
now as a GSoC project.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://palestinefacts.org http://jihadwatch.org
http://openvotingconsortium.org http://iris.org.il http://dhimmi.org
If your VCR is still blinking 12:00, you don't want Linux.

Re: Purpose of rawsock module

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

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-05-31 09:26:46 +0200]:
>
> I wonder though, why is this not part of CLISP (i.e. not a module)?
> The socket interface of CLISP could be perfectly well build on top of "rawsock",
> or - if speed is an issue - on the underlying C functions.
> Is the "overhead" of providing access to the functions (i.e. the LISP<->C
> conversions, the additional subrs) really that crucial?

high-level socket interface was written long before the rawsock module.
there was a talk about turning it into a module, but it was deemed too important.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://camera.org http://thereligionofpeace.com
http://mideasttruth.com http://iris.org.il http://truepeace.org
Don't wait for the rain to end. Learn to dance in the rain!

Re: Purpose of rawsock module

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

Sam wrote:
> This module _IS_ that "socket library".

That was exactly what I needed to know :)


Reading the rest of the discussion, as well as what Don wrote:
> TCP/IP uses sockets but not raw sockets.

I think the name of the module is really unfortunate. "rawsock" could
plausibly mean all of the following:

* "raw access" to (the general concept of) sockets (which it actually is)
* access to OS specific sockets
* access to "raw sockets", i.e. SOCK_RAW

A better name would probably be something like BSD sockets, or even
POSIX sockets.


I wonder though, why is this not part of CLISP (i.e. not a module)?
The socket interface of CLISP could be perfectly well build on top of "rawsock",
or - if speed is an issue - on the underlying C functions.
Is the "overhead" of providing access to the functions (i.e. the LISP<->C
conversions, the additional subrs) really that crucial?

Re: Compilation on Windows 8 with Visual Studio 2013

[Loïc M. <lm...@gm...>]

Hello,

On Fri, May 27, 2016 at 7:42 PM, Sam Steingold <sd...@gn...> wrote:

> Hi,
>
> > * Loïc Maury <yznhel@tznvy.pbz> [2016-05-26 10:50:12 +0200]:
> >
> > I'am trying to compile the source code of CLisp on Windows 8.1, but
> without
> > success.
>
> I don't think anyone has ever done that.
>
> > I have installed the third library (ffcall, gettext-runtime, libiconv,
> > libsigsegv),
> >
> > however I'am blocked at CLisp/src when I do nmake (after copied
> >
> > win32msvc to src\makefile, and follow steps).
> >
> > the compiler return to me :
> >
> > cl : Command line error D8022 : cannot open 'CPPFLAGS@' with the command
> >
> > cl @CPPFLAGS@ -I/gllib  -G5 -Os -Oy -Ob1 -Gs -Gf -Gy -U__GNUC__ -DANSI
> > -D_M_IX86=500 -D_WIN32 -I"C:\\Program Files (x86)\\Microsoft Visual
> Studio
> > 12.0\\VC"/include -DENABLE_UNICODE @INCTERMCAP@ -DDYNAMIC_FFI
> -DNO_GETTEXT
> > -I.   ..\utils\comment5.c /Fecomment5.exe
> >
> > Do you have any idea of the error ?
>
> your makefile should have no "@" in it.
> they are supposed to be replaced by configure, but you are not using it
> with msvs.
> this means that you need to edit it and replace all things like
> @CPPFLAGS@ with something appropriate for your situation.
> specifically, @CPPFLAGS@ and @X_LIBS@ can probably be removed.
> @LTLIBSIGSEGV@ should point to the place where you installed libsigsegv.
> &c &c.
>

I will try it, thank you.

In the same time I'am trying to port the project on Visual Studios 2015,
some part of the projects compile for now.

I'am interested to contribute to the project, but the list of tasks (Help
wanted), is up to date  ?

Best

Loic


>
> PS. this will not be a joyride, sorry.
>
> PPS. You might want to consider mingw instead.
>
> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X
> 11.0.11803000
> http://www.childpsy.net/ http://islamexposedonline.com http://dhimmi.org
> http://think-israel.org http://palestinefacts.org http://mideasttruth.com
> Lisp: Serious empowerment.
>


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Garanti
sans virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Compilation on Windows 8 with Visual Studio 2013

[Pascal J. B. <pj...@in...>]

<Joe...@t-...> writes:

> Hi,
>
> Loïc Maury wrote:
>> however I'am blocked at CLisp/src when I do nmake (after copied
>> win32msvc to src\makefile, and follow steps).
>
>> cl @CPPFLAGS@ -I/gllib  -G5 -Os -Oy -Ob1 -Gs -Gf -Gy -U__GNUC__ -DANSI 
>> -D_M_IX86=500 -D_WIN32 -I"C:\\Program Files (x86)\\Microsoft Visual 
>> Studio 12.0\\VC"/include -DENABLE_UNICODE @INCTERMCAP@ -DDYNAMIC_FFI -DNO_GETTEXT
>> -I.   ..\utils\comment5.c /Fecomment5.exe
> Sam>PPS. You might want to consider mingw instead.
>
> Isn't there an ancient Makefile.MSVC5 or MSVC6 in the repository? Maybe that's
> a useful base for the base clisp (pun intended).

I heard MS-Windows 10 supported bash (and actually a whole linux
personality).  Perhaps it could be used as a development environment to
compile the MS-Windows binaries?


Disclaimer: I don't know anything about Microsoft softwares.
-- 
__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

Re: case sensitivity of provide, require and module-provide-asdf

[Raymond T. <toy...@gm...>]

>>>>> "Pascal" == Pascal J Bourguignon <pj...@in...> writes:


    Pascal> Now, all those variables can (and most of them probably should) be set
    Pascal> in the rc file (~/.clisprc.lisp, etc) by the user.

    Pascal> The consequences are that:

    Pascal> 1- as a user, you must know what you've put in the rc file, and
    Pascal> therefore what is the current setting of those variables.  You could
    Pascal> have:
 
    Pascal> (SETF (READTABLE-CASE *READTABLE*) :PRESERVE)

    Pascal> in your rc file, and use  uppercase letters (their real case) for all
    Pascal> the CL symbols.


    Pascal> 2- I would argue that library sources should NOT assume a readtable, and
    Pascal> like they include a IN-PACKAGE form at the start of each source file,
    Pascal> they should also include a form setting the *readtable*, such as:

    Pascal> (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
    Pascal> (SETF *READTABLE* (COPY-READTABLE NIL)))

    Pascal> in each source file, or at the very least, there should be a way in
    Pascal> ASDF (and other similar system definition systems), to specify the
    Pascal> readtable to be used to load and read the sources of the library.

If a user wants to make his life difficult in using other peoples'
code, go for it.  Maybe hack your own load and compile-file function
to change the read table case.

Sane people just use the default and enjoy being able to use other
people's code without problems.

--
Ray

Re: Purpose of rawsock module

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

> * Don Cohen <qba...@vf...3-vap.pbz> [2016-05-27 18:14:37 +0000]:
>
> Sam Steingold writes:
>
>  > Sockets are the OS-level interface to TCP/IP.
>  > Thus all the functions in rawsock can, should(must!) and did work on all
>  > "modern" operating systems (i.e., linux, *bsd including mac os x,
>  > windows xp and later, all other unixes released after 2000 - but not on
>  > atari and amiga).
>
> TCP/IP uses sockets but not raw sockets.
> I agree that TCP/IP should work on windows, but it can do so
> without rawsock working.  
> It did, long before rawsock was added, and I hope still does.

CLISP has "normal" socket interface and the "rawsock" module.
both are cross-platform and both should (and did) work on all platforms
were CLISP works.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://islamexposedonline.com http://ffii.org
http://dhimmi.org http://www.dhimmitude.org http://camera.org
UNIX is a way of thinking.  Windows is a way of not thinking.

Re: Purpose of rawsock module

[<don...@is...>]

Sam Steingold writes:

 > Sockets are the OS-level interface to TCP/IP.
 > Thus all the functions in rawsock can, should(must!) and did work on all
 > "modern" operating systems (i.e., linux, *bsd including mac os x,
 > windows xp and later, all other unixes released after 2000 - but not on
 > atari and amiga).

TCP/IP uses sockets but not raw sockets.
I agree that TCP/IP should work on windows, but it can do so
without rawsock working.  
It did, long before rawsock was added, and I hope still does.

Re: Compilation on Windows 8 with Visual Studio 2013

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

Hi,

Loïc Maury wrote:
> however I'am blocked at CLisp/src when I do nmake (after copied
> win32msvc to src\makefile, and follow steps).

> cl @CPPFLAGS@ -I/gllib  -G5 -Os -Oy -Ob1 -Gs -Gf -Gy -U__GNUC__ -DANSI 
> -D_M_IX86=500 -D_WIN32 -I"C:\\Program Files (x86)\\Microsoft Visual 
> Studio 12.0\\VC"/include -DENABLE_UNICODE @INCTERMCAP@ -DDYNAMIC_FFI -DNO_GETTEXT
> -I.   ..\utils\comment5.c /Fecomment5.exe
Sam>PPS. You might want to consider mingw instead.

Isn't there an ancient Makefile.MSVC5 or MSVC6 in the repository? Maybe that's
a useful base for the base clisp (pun intended).

Rationale: I used it -- over a decade ago -- to build CLISP with MSVC98 (yeah).

However, I can't remember the details, I guess I cheated a little bit and ran
configure first from a Linux machine, with the MS-Windows HD exported over
Samba, so as to generate the basic files like comment5.c, config.h, eval.c
etc.  Then I returned to the MS-Windows machine and had MSVC compile and link
the .c files.  Well, given comment5.exe, ansidecl.exe etc., perhaps MSVC was
able to generate eval.c from eval.d on its own after all.  I definitely
never installed MingW or cygwin on the MS-Windows machine.

Note that I only ever built the base lisp.exe -- without any modules except
the dynamic FFI. These days, I believe the build system creates a separate
executable named clisp.exe that dispatches to the various subdirectories in
which the varying lisp.exe were built including whatever modules (among those
that need C code) were additionally compiled (witness the difference between
the base and the full linking set). The grunge work that the scripts in the
current repository do may be limited to support for MingW or cygwin or UNIX,
I don't know.

Regards,
	Jörg.

Re: Compilation on Windows 8 with Visual Studio 2013

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

Hi,

> * Loïc Maury <yznhel@tznvy.pbz> [2016-05-26 10:50:12 +0200]:
>
> I'am trying to compile the source code of CLisp on Windows 8.1, but without
> success.

I don't think anyone has ever done that.

> I have installed the third library (ffcall, gettext-runtime, libiconv,
> libsigsegv),
>
> however I'am blocked at CLisp/src when I do nmake (after copied
>
> win32msvc to src\makefile, and follow steps).
>
> the compiler return to me :
>
> cl : Command line error D8022 : cannot open 'CPPFLAGS@' with the command
>
> cl @CPPFLAGS@ -I/gllib  -G5 -Os -Oy -Ob1 -Gs -Gf -Gy -U__GNUC__ -DANSI
> -D_M_IX86=500 -D_WIN32 -I"C:\\Program Files (x86)\\Microsoft Visual Studio
> 12.0\\VC"/include -DENABLE_UNICODE @INCTERMCAP@ -DDYNAMIC_FFI -DNO_GETTEXT
> -I.   ..\utils\comment5.c /Fecomment5.exe
>
> Do you have any idea of the error ?

your makefile should have no "@" in it.
they are supposed to be replaced by configure, but you are not using it
with msvs.
this means that you need to edit it and replace all things like
@CPPFLAGS@ with something appropriate for your situation.
specifically, @CPPFLAGS@ and @X_LIBS@ can probably be removed.
@LTLIBSIGSEGV@ should point to the place where you installed libsigsegv.
&c &c.

PS. this will not be a joyride, sorry.

PPS. You might want to consider mingw instead.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://islamexposedonline.com http://dhimmi.org
http://think-israel.org http://palestinefacts.org http://mideasttruth.com
Lisp: Serious empowerment.

Re: Purpose of rawsock module

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

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-05-27 00:40:35 +0200]:
>
> I'm currently working on getting the rawsock module up-to-date and running
> on the major target platforms. I got a bit unsure about the real purpose,
> the "goal" of that module, though:
>
> The documentation suggests that it's providing access to what sys/socket.h
> provides, i.e. "raw" access to sockets.

Indeed, rawsock originated with Fred & Don Cohens, who wrote it for some
very low level access to networking.

> Windows doesn't have sys/socket.h, but rather WinSock2. While there are
> a lot of similarities between those (IIRC that was one of the design goals
> of WinSock) they're certainly different in some parts.

Sockets are the OS-level interface to TCP/IP.
Thus all the functions in rawsock can, should(must!) and did work on all
"modern" operating systems (i.e., linux, *bsd including mac os x,
windows xp and later, all other unixes released after 2000 - but not on
atari and amiga).

Yes, windows is an oddball system, this is why we have a problem now,
and this is precisely the problem this project is supposed to address.

> Unifying both sys/socket.h and WinSock2 behind the same interface
> seems to be a contradiction to the "raw" access to me, though. If
> that's the goal of the module, wouldn't it be much better to have a
> module providing access to some "socket library"?

This module _IS_ that "socket library".

> Or would it be useful to split the rawsock module in platform dependent
> modules, just like it's done with bindings/glibc and bindings/win32?

The idea of the module is to have it working on _all_ modern OS OOTB,
without "os-specific" interfaces all over the place.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://honestreporting.com
http://memri.org http://dhimmi.org http://mideasttruth.com
If you know that you know nothing, you know too much.

Purpose of rawsock module

[<don...@is...>]

Since nobody else seems to be answering this, I'll try to provide 
a little feedback.

Rawsock is used to control the network behavior of a machine, e.g., to
make it act as a non-standard router or a new type of network security
device, or just to make small changes in how an otherwise normal
machine behaves.  It's also useful for writing your own tcpdump,
generating packets for experimenting with network attacks and defenses
or just learning how things work.

I assume that rawsock doesn't currently work on windows.
I don't know that it has ever worked anywhere other than linux.
Making it work anywhere else seems to me far off the track of a
new release.  So I'd say just view it as platform specific.
If it doesn't work in linux then it's worth fixing there.
If it looks like it's on the verge of working somewhere else
it might be worth a small amount of effort, a little more if
there's evidence that it worked there some time before.

Re: case sensitivity of provide, require and module-provide-asdf

[Pascal J. B. <pj...@in...>]

Chris Stacy <cs...@dt...> writes:

>     On May 26, 2016, at 1:48 PM, Pascal J. Bourguignon
>     <pj...@in...> wrote:
>     
>     Raymond Toy <toy...@gm...> writes:
>         I think you meant upcasing. 'ABC and 'abc are both the same
>         symbol
>         whose name is "ABC".
>         
>
>     Wrong:
>     
>     cl-user> (EQ 'ABC 'abc)
>     NIL
>     cl-user> (MAPCAR 'SYMBOL-NAME '(ABC Abc abc))
>     ("ABC" "Abc" "abc”)
>     
>
> I think someone reading this might get confused about case in Common
> Lisp.
> Normally, (eq ‘abc ‘ABC) => T of course, since READ upcases symbols.
> Also (eq #’eq #’EQ) => T for example.
> But symbol names are case-sensitive, and Pascal’s confounding example
> above
> left out the part where he trickily altered the “readtable case” of
> the current reader,
> causing it ti preserve case. Notice that he typed uppercase EQ,
> because the
> symbol-name of EQ is (like all Common Lisp built-ins) actually
> uppercase.
>
> See: http://www.lispworks.com/documentation/lw51/CLHS/Body/23_aba.htm
>
> Don’t want to confuse any readers about the readers…

Yes, I left out the setting of the readtable-case. >:-}

    ; SLIME 2015-06-01
    cl-user> (setf (readtable-case *readtable*) :preserve)
    :PRESERVE
    cl-user> (EQ 'ABC 'abc)
    NIL
    cl-user> (MAPCAR 'SYMBOL-NAME '(ABC Abc abc))
    ("ABC" "Abc" "abc")
    cl-user> (SETF (READTABLE-CASE *READTABLE*) :UPCASE)
    :upcase
    cl-user> (eq 'ABC 'abc)
    t
    cl-user>


The important word in this thread was:


Sam Steingold <sd...@gn...> writes:

>> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-05-15 21:40:41 +0200]:
>>
>> Given the ignorance of case prevalent in Common Lisp,
>
> the only places where this happens are:
> 1. reader is case-converting by default
                               ^^^^^^^^^^

"BY DEFAULT"

The initial value of global variables, and the initial configurations of
the objects they refer to, can be left undefined
(implementation-dependent), for example:

    Variable *PRINT-PRETTY*
    Initial Value:
    implementation-dependent.

or a default initial value can be specified by the standard:

    Variable *READTABLE*
    Initial Value:
    A readtable that conforms to the description of Common Lisp syntax
    in Section 2 (Syntax).


    2.1.1.3 The Initial Readtable

says that the initial *readtable* conforms to the standard syntax, which
is defined by the Standard Readtable, and:

   2.1.1.2 The Standard Readtable

says that:

     The readtable case of the standard readtable is :upcase.


(By the way, my reading of section 2.1.1.3 is that implementations
should not deviate from the standard readtable, eg. they should not
provide implementation specific reader macros in the initial readtable
(as ccl does, for example)).



Now, all those variables can (and most of them probably should) be set
in the rc file (~/.clisprc.lisp, etc) by the user.

The consequences are that:

1- as a user, you must know what you've put in the rc file, and
   therefore what is the current setting of those variables.  You could
   have:
 
         (SETF (READTABLE-CASE *READTABLE*) :PRESERVE)

   in your rc file, and use  uppercase letters (their real case) for all
   the CL symbols.


2- I would argue that library sources should NOT assume a readtable, and
   like they include a IN-PACKAGE form at the start of each source file,
   they should also include a form setting the *readtable*, such as:

        (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
          (SETF *READTABLE* (COPY-READTABLE NIL)))

   in each source file, or at the very least, there should be a way in
   ASDF (and other similar system definition systems), to specify the
   readtable to be used to load and read the sources of the library.


-- 
__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

Purpose of rawsock module

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

I'm currently working on getting the rawsock module up-to-date and running
on the major target platforms. I got a bit unsure about the real purpose,
the "goal" of that module, though:

The documentation suggests that it's providing access to what sys/socket.h
provides, i.e. "raw" access to sockets.

Windows doesn't have sys/socket.h, but rather WinSock2. While there are
a lot of similarities between those (IIRC that was one of the design goals
of WinSock) they're certainly different in some parts.
(I guess this is mostly due to sockets not being guaranteed to be file handles
and the way one does asynchronous IO)

Unifying both sys/socket.h and WinSock2 behind the same interface seems to
be a contradiction to the "raw" access to me, though. If that's the goal
of the module, wouldn't it be much better to have a module providing access
to some "socket library"?

Or would it be useful to split the rawsock module in platform dependent
modules, just like it's done with bindings/glibc and bindings/win32?

Re: case sensitivity of provide, require and module-provide-asdf

[Chris S. <cs...@dt...>]

> On May 26, 2016, at 1:48 PM, Pascal J. Bourguignon <pj...@in...> wrote:
> 
> Raymond Toy <toy...@gm...> writes:
> 
>>>>>>> "Sam" == Sam Steingold <sd...@gn...> writes:
>> 
>>>> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-05-15 21:40:41 +0200]:
>>>> 
>>>> Given the ignorance of case prevalent in Common Lisp,
>> 
>>    Sam> the only places where this happens are:
>>    Sam> 1. reader is case-converting by default
>> 
>> I think you meant upcasing. 'ABC and 'abc are both the same symbol
>> whose name is "ABC".
> 
> Wrong:
> 
> cl-user> (EQ 'ABC 'abc)
> NIL
> cl-user> (MAPCAR 'SYMBOL-NAME '(ABC Abc abc))
> ("ABC" "Abc" "abc”)


I think someone reading this might get confused about case in Common Lisp.
Normally, (eq ‘abc  ‘ABC)  => T  of course, since READ upcases symbols.
Also (eq  #’eq  #’EQ)   => T  for example.
But symbol names are case-sensitive, and Pascal’s confounding example above
left out the part where he trickily altered the “readtable case” of the current reader,
causing it ti preserve case.  Notice that he typed uppercase EQ, because the
symbol-name of EQ is (like all Common Lisp built-ins) actually uppercase.

See:  http://www.lispworks.com/documentation/lw51/CLHS/Body/23_aba.htm

Don’t want to confuse any readers about the readers…

Re: case sensitivity of provide, require and module-provide-asdf

[Pascal J. B. <pj...@in...>]

Raymond Toy <toy...@gm...> writes:

>>>>>> "Sam" == Sam Steingold <sd...@gn...> writes:
>
>     >> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-05-15 21:40:41 +0200]:
>     >> 
>     >> Given the ignorance of case prevalent in Common Lisp,
>
>     Sam> the only places where this happens are:
>     Sam> 1. reader is case-converting by default
>
> I think you meant upcasing. 'ABC and 'abc are both the same symbol
> whose name is "ABC".

Wrong:

cl-user> (EQ 'ABC 'abc)
NIL
cl-user> (MAPCAR 'SYMBOL-NAME '(ABC Abc abc))
("ABC" "Abc" "abc")


-- 
__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

Compilation on Windows 8 with Visual Studio 2013

[Loïc M. <lm...@gm...>]

Hello,

I'am trying to compile the source code of CLisp on Windows 8.1, but without
success.

I have installed the third library (ffcall, gettext-runtime, libiconv,
libsigsegv),

however I'am blocked at CLisp/src when I do nmake (after copied

win32msvc to src\makefile, and follow steps).

the compiler return to me :

cl : Command line error D8022 : cannot open 'CPPFLAGS@' with the command

cl @CPPFLAGS@ -I/gllib  -G5 -Os -Oy -Ob1 -Gs -Gf -Gy -U__GNUC__ -DANSI
-D_M_IX86=500 -D_WIN32 -I"C:\\Program Files (x86)\\Microsoft Visual Studio
12.0\\VC"/include -DENABLE_UNICODE @INCTERMCAP@ -DDYNAMIC_FFI -DNO_GETTEXT
-I.   ..\utils\comment5.c /Fecomment5.exe

Do you have any idea of the error ?

Thank you

Best

Loic Maury

Re: case sensitivity of provide, require and module-provide-asdf

[Raymond T. <toy...@gm...>]

>>>>> "Sam" == Sam Steingold <sd...@gn...> writes:

    >> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-05-15 21:40:41 +0200]:
    >> 
    >> Given the ignorance of case prevalent in Common Lisp,

    Sam> the only places where this happens are:
    Sam> 1. reader is case-converting by default

I think you meant upcasing. 'ABC and 'abc are both the same symbol
whose name is "ABC".

--
Ray

Re: GSoC status report

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

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-05-24 02:03:04 +0200]:
>
> Regarding gnulib and modules: One issue is about linking against
> gnulib both for the main CLISP binary as well as for modules (like
> bindings/glibc).  In https://sourceforge.net/p/clisp/bugs/634/ you
> mention that the increased size is not an issue on linux but possibly
> on other targets. Do you know which targets?

the farther the target is from GNU, the more gnulib will re-implement.
you should probably ask the gnulib list for details, but I suspect that
windows is the prime example.

at any rate, RAM is relatively cheap these days, so I don't think this
is such a big deal now.

> I fear that there's not really a much better solution, though. One could
> try to isolate a set of gnulib modules that are "guaranteed" to be (including
> all unused functions, thus completely) linked with the CLISP binary, so that
> all CLISP modules don't need to link against these parts of gnulib. This
> might be fragile to maintain and keep in synch, though.

this is probably less of a problem than you think, but it is not in
scope.

the problem is that things like rawsock do not run on windows.


> I also remember a post on the gnulib list (I think from Bruno) on
> building part of gnulib as a shared library, but cannot find atm. (I
> think it was MinGW related, too)

this is related to the above issue - they had to make it shared because
it rivals glibc in size :-(


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://iris.org.il http://jihadwatch.org
http://islamexposedonline.com http://palestinefacts.org http://think-israel.org
Time would have been the best Teacher, if it did not kill all its
students.

Re: case sensitivity of provide, require and module-provide-asdf

[Pascal J. B. <pj...@in...>]

Sam Steingold <sd...@gn...> writes:

>> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2016-05-15 23:05:38 +0200]:
>>
>> cl-user> (eq #P"/tmp/Foo" #P"/tmp/foo")
>> nil
>
> you meant equal, not eq, right?

Yes, sorry.

-- 
__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