headers
Marco Baringer | 1 Aug 2002 02:14
Picon

Re: [PATCH] copy-file

Sam Steingold <sds <at> gnu.org> writes:

> > > 4. it's UNIX-only even though file copying is quite platform
> > >    independent.
> > 
> > well, the basic idea of a read/write loop is, but the calls with which
> > that entire loop is made up aren't. there should be a windows version,
> > but for lack of hardware i can't do it, i try and copy 'n paste it
> > from somewhere if that would help, but i couldn't even test to see if
> > it compiles...
> 
> use CLISP i/o, not OS i/o.
> i.e., create CLISP streams and use read_byte_sequence.

1)

i implemented copy-file via make_file_stream and read_byte. (for some
odd reason (i did not dig deeply) read_byte_sequence always returned 0
bytes read). however, i timed this against the unix specific
implementation i had done before and found it to be almost an order of
magnitutde slower, average of 3.9 seconds for system independant
copy-file vs. 0.5 seconds for unix specific. should i just leave both
but use the unix version #if defined(UNIX)?

2) is there anything blatently wrong with this:

var object buffer = make_ssbvector(4096);

pushSTACK(buffer);
pushSTACK(source_stream);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sam Steingold | 1 Aug 2002 15:27
Picon

Re: [PATCH] copy-file

> * In message <m2ado7a113.fsf <at> bese.it>
> * On the subject of "Re: [PATCH] copy-file"
> * Sent on 01 Aug 2002 02:14:00 +0200
> * Honorable Marco Baringer <empb <at> bese.it> writes:
>
> Sam Steingold <sds <at> gnu.org> writes:
> 
> > > > 4. it's UNIX-only even though file copying is quite platform
> > > >    independent.
> > > 
> > > well, the basic idea of a read/write loop is, but the calls with which
> > > that entire loop is made up aren't. there should be a windows version,
> > > but for lack of hardware i can't do it, i try and copy 'n paste it
> > > from somewhere if that would help, but i couldn't even test to see if
> > > it compiles...
> > 
> > use CLISP i/o, not OS i/o.
> > i.e., create CLISP streams and use read_byte_sequence.
> 
> 1)
> 
> i implemented copy-file via make_file_stream and read_byte. (for some
> odd reason (i did not dig deeply) read_byte_sequence always returned 0
> bytes read). however, i timed this against the unix specific
> implementation i had done before and found it to be almost an order of
> magnitutde slower, average of 3.9 seconds for system independant
> copy-file vs. 0.5 seconds for unix specific.

please make sure all streams are buffered and use read_byte_sequence
(with the sequence length the same as the buffer size.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Aug 2002 15:35
Picon

[clisp cvs] "clisp/utils comment5.c,1.7,1.8"

Update of /cvsroot/clisp/clisp/utils
In directory usw-pr-cvs1:/tmp/cvs-serv10792

Modified Files:
	comment5.c 
Log Message:
check for errors before closing files

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Aug 2002 17:52
Picon

[clisp cvs] "clisp/src spvw.d,1.197,1.198 pathname.d,1.192,1.193 makemake.in,1.275,1.276 constsym.d,1.158,1.159 ChangeLog,1.1676,1.1677"

Update of /cvsroot/clisp/clisp/src
In directory usw-pr-cvs1:/tmp/cvs-serv1140/src

Modified Files:
	spvw.d pathname.d makemake.in constsym.d ChangeLog 
Log Message:
cygwin: understand win32 "c:" pathnames

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Aug 2002 17:56
Picon

[clisp cvs] "clisp/src init.lisp,1.64,1.65 defs1.lisp,1.19,1.20 ChangeLog,1.1677,1.1678"

Update of /cvsroot/clisp/clisp/src
In directory usw-pr-cvs1:/tmp/cvs-serv2570/src

Modified Files:
	init.lisp defs1.lisp ChangeLog 
Log Message:
simplified messages

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Aug 2002 18:10
Picon

[clisp cvs] "clisp/doc impext.xml,1.99,1.100 impbody.xml,1.104,1.105"

Update of /cvsroot/clisp/clisp/doc
In directory usw-pr-cvs1:/tmp/cvs-serv7469/doc

Modified Files:
	impext.xml impbody.xml 
Log Message:
documented the change in `upgraded-complex-part-type'

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Aug 2002 18:35
Picon

[clisp cvs] "clisp/src makemake.in,1.276,1.277 ChangeLog,1.1678,1.1679"

Update of /cvsroot/clisp/clisp/src
In directory usw-pr-cvs1:/tmp/cvs-serv14885/src

Modified Files:
	makemake.in ChangeLog 
Log Message:
(DISTFILE): strip parens from OS version for cygwin

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Aug 2002 18:41
Picon

[clisp cvs] "clisp/src type.lisp,1.27,1.28 ChangeLog,1.1679,1.1680 CHANGES.LOG,1.201,1.202"

Update of /cvsroot/clisp/clisp/src
In directory usw-pr-cvs1:/tmp/cvs-serv17241/src

Modified Files:
	type.lisp ChangeLog CHANGES.LOG 
Log Message:
Type COMPLEX now correctly uses UPGRADED-COMPLEX-PART-TYPE.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Aug 2002 18:41
Picon

Re: upgraded-complex-part-type?

> * In message <4nn0saze63.fsf <at> rtp.ericsson.se>
> * On the subject of "Re: upgraded-complex-part-type?"
> * Sent on 29 Jul 2002 12:34:12 -0400
> * Honorable Raymond Toy <toy <at> rtp.ericsson.se> writes:
>
> I have another question.  What does Clisp think (complex (eql 0))
> really is?  From a discussion on CMUCL, some think this is the empty
> type because there is not complex number whose parts are both the
> integer 0.  Others think it is identical to (complex rational) since
> CMUCL upgrades (eql 0) to rational.
> 
> I think, but don't know for sure, that ACL and Lispworks thinks
> (complex (eql 0)) is the same as (complex rational).  They both think
> (typep #c(0 1) '(complex (eql 0))) is T.

CLHS:

        Every element of this type is a complex whose real part and
        imaginary part are each of type (upgraded-complex-part-type
        typespec). This type encompasses those complexes that can result
        by giving numbers of type typespec to complex.

        (complex type-specifier) refers to all complexes that can result
        from giving numbers of type type-specifier to the function
        complex, plus all other complexes of the same specialized
        representation.

it appears that
        (complex foo bar) ==
        (complex (upgraded-complex-part-type foo)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Sam Steingold | 1 Aug 2002 18:44
Picon

[clisp cvs] "clisp/tests type.tst,1.9,1.10 ChangeLog,1.86,1.87"

Update of /cvsroot/clisp/clisp/tests
In directory usw-pr-cvs1:/tmp/cvs-serv18258/tests

Modified Files:
	type.tst ChangeLog 
Log Message:
Type COMPLEX now correctly uses UPGRADED-COMPLEX-PART-TYPE.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |

Gmane