Re: write-byte-sequence, build problems, ...

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

> * Don Cohen <qba...@vf...3-vap.pbz> [2003-09-24 15:45:11 -0700]:
>
>  > > I get the feeling that in order to do this properly we need at least
>  > > one more standard function, something like write-byte-will-hang-p
>  > > which is yet another thing I don't know how to implement.
>  > I am afraid you will need a whole bunch of listen() analogues.
> Yes, but I now view that as "future work".  What I have now seems
> sufficient for speeding up my "shared socket server".
> 
>  > >  # WRITE-BYTE-ARRAY - Pseudo-Function for Broadcast-Streams:
>  ...
>  > > +  /* what happens if different streams write different amounts? *** */
>  > >    while (streamlist = STACK_0, consp(streamlist)) {
>  > >      STACK_0 = Cdr(streamlist);
>  > >      pushSTACK(Car(streamlist));
>  > > -    write_byte_array(&STACK_0,bytearray_,start,len);
>  > > +    result = write_byte_array(&STACK_0,bytearray_,start,len,no_hang);
>  > >      skipSTACK(1);
>  > >    }
>  > >    skipSTACK(1);
>  > > +  return result;
>  > >  }
>  > 
>  > I think you should return the minimum of all the write_byte_array()
>  > values, i.e., the total number of character that were printed to every
>  > stream.
> 
> Not very good.  The problem is that you generally use no-hang to print
> a sequence, then you find out how far you got and try again starting
> from there.  Your solution would result in writing some parts multiple
> times.  Right now I think I prefer the current solution where I just
> say that the operation is illegal/unsupported for certain types of
> streams.

you might consider the following approach: for BROADCAST-STREAMs,
:NO-HANG would apply to the _first_ stream only and then it will send
to the other streams only what it could send to the first one.
then one would be able to make a BROADCAST-STREAM of a  socket stream
and a file stream (for logging) and it will work exactly as intended.

>  > note that full_write is used in bindings/glibc/linux.lisp
> Thanks for mentioning that.
> Is it possible to make trailing arguments optional in c?
> I've already changed a bunch of calls to full-write to add the
> extra argument.  Is it ok to just change the one above also?

I would prefer that full_write and full_read were as close as possible.
I make full_read a macro calling read_helper.
I would prefer that either full_write called write_helper or that you
replace read_helper with full_read.

>  > please try building --with-debug and CC=g++ too.
> Ok, easy enough.  What's this supposed to do?  Help me debug in gdb?
> Catch extra problems at compile time?  At run time?  

CC=g++ would catch many more type errors at compile time and "GC-safety
bugs" at run time.
<http://clisp.cons.org/impnotes/gc-safety.html>.

>  > >  #<OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 8) #P"/tmp/foobar">
>  > > [currently no support for buffered]
>  > 
>  > that should not be too hard.
>  > I think read/no-hang _is_ supported on buffered streams.
> Right.  I think of that as future work since I don't need it right now.

buffered stream are _much_ faster than unbuffered ones.
it is crucial that they work too.

>  > please work with the CVS head.
>  > I cannot incorporate patches that are not made against the CVS head -
>  > too much work (if Joerg will do that, it is fine with me).
> The flip side (for me) is that cvs is a fast moving target.

not really (at least, not now).

> There were lots of cvs updates in the time it took me to get this
> working.  I hope if I get a cvs today and submit diffs tomorrow you'll
> be satisfied.

you can announce on this list that you are working on such and such
files and then people will abstain from making large changes to them.
(small changes will be painlessly merged in for you by "cvs up")
in fact, you _must_ do that because otherwise your patches will become
un-merge-able.

> Another concern - I imagine that the last release is more reliable
> than cvs.  You think that's true?  I want to build a version that I
> can use in a lot of places for a significant time.  It seems more
> reasonable to build that from the last release.  Of course, I can do
> that and still send you diffs from cvs to incorporate.

1. right now, CVS is _more_ stable than the release because many
   bugs have been fixed and nothing new was done.  I do not expect any
   changes to stability in the near future.

2. only diffs against CVS head will ever be incorporated by me.

>  > libsigsegv is linked statically, so it is always in the binary
>  > distribution.
> only if the binary distribution is built with it, I presume
> (Hmm, I thought I saw a report that suggested the opposite -
> downloaded a 2.31 binary then had to install libsigsegv to use it.
weird.
> Should I try to track this down and find out what really happened?)
:NO-HANG has priority.

>  > it is not in the source distribution because it is a totally separate
>  > project and is a configure-time dependency of CLISP.
> Still, if it's highly recommeded it seems like it should be included.
> The possibility that some day not every version of clisp will work
> with every version of libsigsegv is an even better argument for doing so.

I welcome help from people, especially with packaging.
If you (or anyone else) whats to take over release issues, like
building binaries for various platforms, RPMs, cygwin packages &c &c, I
would be more than happy.

If you want to include libsigsegv in the distribution, just go ahead!

>  > > First, I welcome ideas about how to debug such things.
>  > 
>  > $ ./configure --with-debug build-g
>  > $ cd build-g
>  > $ gdb
>  > (gdb) run -B . -norc -m 750KW -i init.lisp
> Whoa! Without even make?

:-)
I forgot the --build argument to ./configure.

> The only new switch I see is -DDEBUG_OS_ERROR. 
> Is that supposed to cure segfaults?

no (look at lispbibl.d for how it is used).

>  > >  open("/usr/lib/libreadline.so.3", O_RDONLY) = 4
>  > >
>  > > For some reason still reading libreadline!
>  > > Any idea why?
>  > 
>  > you'd need to look at config.log and unixconf.h.
> But this shouldn't matter if I use --without-readline, should it?

in theory, yes.  some software has bugs, you know :-)

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Life is like a diaper -- short and loaded.