clisp-devel digest, Vol 1 #1067 - 7 msgs

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

[I begin to see the problem with subscribing to the digest - the
 messages all go to the digest (no replies to me) so I end up not
 seeing them until I get the digest.]

 > From: Bruno Haible <br...@cl...>
 > Subject: Re: next set of questions
 > 
 > > > Is there some way to determine from an image which memory model it uses?
 > 
 > spvw_memfile.d has a constant 'memflags' which gets compared to the
Unfortunately that's not a solution to my problem.
I answered the question for myself by adding something to spvw.d that
prints at startup under DEBUG_SPVW along with the stack and sp depth.
It had to be done early since I get the segfault shortly after that.

 > I know no other valid uses of these _memflags.
 > 
 > > > Is there an approved way of selecting the memory model you want?
 > > > It looks like I could add the c flag -DSPVW_MIXED_BLOCKS_STAGGERED
 > > > but I don't see anything that would then prevent SPVW_PURE_BLOCKS
 > > > from also being defined, and it seems this sort of thing could have
 > > > serious bad consequences.
 > 
 > When you're doing experiments for yourself, you can change or comment
 > out as many SPVW_* definitions as you want.
Again this doesn't really answer the question.  I was trying to figure
out which flags to pass in order to get a given model and it seems
that I have to read a lot of code to find out.
What I'd like is a flag to select the model (or one flag for each
model) that would cause an error if more than one were selected or
if the one selected can't be accommodated.

 > Subject: Re: write-byte-sequence, build problems, ...
 > From: Sam Steingold <sd...@gn...>

 > >  > >  # WRITE-BYTE-ARRAY - Pseudo-Function for Broadcast-Streams:

 > >  > 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.
So the non-first ones hang?

 > 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.
This would be the first time as far as I know where the order of
streams in a broadcast stream matters.  I assume the order in which
they're passed is to be maintained.
I can see that this one case has some use, but there are lots of 
other cases where this behavior would be worse than the current 
error.

 > buffered stream are _much_ faster than unbuffered ones.
I don't think that's true of socket streams.
 > it is crucial that they work too.
I'm most eager for someone to carefully review what I have submitted
already.  If that's ok then the buffered should be easy enough for
either you or me to add.

 > >  > 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.
glad to hear it

 > If you want to include libsigsegv in the distribution, just go ahead!
Ah, it hadn't occurred to be that this was a choice.

 > >  > >  open("/usr/lib/libreadline.so.3", O_RDONLY) = 4
 ...
 > > But this shouldn't matter if I use --without-readline, should it?
 > in theory, yes.  some software has bugs, you know :-)
Ok, then you agree that it's a bug.
Good.  We can postpone it for now.