Fixed select bug in devel

The select system got broken in the last round of devel changes.  The patch
is very minor:

$ hg diff
diff -r 9f6b8596d82b c/unix/event.c
--- a/c/unix/event.c	Fri Jun 27 08:35:39 2008 +0200
+++ b/c/unix/event.c	Mon Jun 30 17:23:11 2008 -0700
@@ -841,7 +841,7 @@
       return errno;
   }
 }
-#elif defined HAVE_SIGNAL
+#elif defined HAVE_SELECT
 /*
  * Call select() on the pending ports and move any ready ones to the ready
  * queue.  If wait is true, seconds is either -1 (wait forever) or the

scheme48-1.8 and --as-needed, DESTDIR, -D_GNU_SOURCE

Hi scheme48's developers,

 Recently, in gentoo, after upgrading to glibc-2.8, we experienced some
bugs in compilation time of scheme48-1.8. The first had to do with
headers: 

<cut>
i686-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H
-D__COMPILING_SCHEME48_ITSELF__
-DS48_HOST_ARCHITECTURE=\"i686-pc-linux-gnu\" -I ./c -I./c -I./c/bibop
-O2 -march=i686 -pipe -pthread -o c/unix/socket.o c/unix/socket.c
c/unix/socket.c: In function ‘gethostbyname_thread’:
c/unix/socket.c:354: error: ‘struct hostent’ has no member named
‘h_addr’
c/unix/socket.c: In function ‘s48_get_host_by_name’:
c/unix/socket.c:385: error: ‘struct hostent’ has no member named
‘h_addr’
make: *** [c/unix/socket.o] Error 1
make: *** Waiting for unfinished jobs....
</cut>

This happens because the new header /usr/include/netdb.h does now:

#if defined __USE_MISC || defined __USE_GNU
# define        h_addr  h_addr_list[0] /* Address, for backward
# compatibility.*/
#endif

and to be __USE_GNU defined, "-D_GNU_SOURCE" must be added to the
default $(DEFS). 

Where is the source code repository?

Where is the s48 repository located?  Given what we discussed before, it 
would be best if I used the most recent code for stuff.

Thanks,
-a

Unuseable target in Makefile

[jar <at> ashby scheme48-1.8]$ make build/initial.image-64
make: *** No rule to make target `build/UnicodeData.txt', needed by  
`scheme/rts/syntax-info.scm'.  Stop.
[jar <at> ashby scheme48-1.8]$
[jar <at> ashby scheme48-1.8]$
[jar <at> ashby scheme48-1.8]$

What is the point of having a target in the distribution's Makefile,  
if it can't be made?

I would suggest making sure all targets can be made, in either of two  
ways:
1. remove unmakeable targets so that they're not a tease, and put them  
in a second distribution package, or
2. add sufficient rules to permit the target to be made.

In this case, if one can get the needed source files from the web,  
include a rule to do so (using, say, wget), or emit manual  
instructions telling people like me where to get the files and where  
to put them.

I assume the entire URL is http://www.unicode.org/Public/UNIDATA/UnicodeData.txt 
  and that the other four URLs are constructed similarly; maybe that  
could be put in the Makefile as documentation.

--------------------------------

OK, in the time it took me to write the above, I've become stuck in a  
different way:

\ before ' !!?

Hey, c'mon guys, if it ain't broke don't fix it, ok?

[jar <at> ashby trunk]$ scheme48
Welcome to Scheme 48 1.4 (made by root on Thu Jan 11 12:47:50 EST 2007)
Copyright (c) 1993-2006 by Richard Kelsey and Jonathan Rees.
Please report bugs to scheme-48-bugs <at> s48.org.
Get more information at http://www.s48.org/.
Type ,? (comma question-mark) for help.
 > "foo'bar"
"foo'bar"
 > ,exit
[jar <at> ashby trunk]$ ../build/external/scheme48-1.8/go
Welcome to Scheme 48 1.8 (made by jar on Sun May  4 15:16:30 EDT 2008)
Copyright (c) 1993-2008 by Richard Kelsey and Jonathan Rees.
Please report bugs to scheme-48-bugs <at> s48.org.
Get more information at http://www.s48.org/.
Type ,? (comma question-mark) for help.
 > "foo'bar"
"foo\'bar"
 > "foo\'bar"

Error: invalid escaped character in string
        #\'
        (&i/o-port-error (port . #{Input-port #{Input-channel  
"standard input"}}))
        (&i/o-read-error (port . #{Input-port #{Input-channel  
"standard input"}}))
 > 

bug in CPS conversion

Hi,
I'm experimenting with the CPS conversion of the native-code compiler
and I get this error message:
----------
Error: incompatible jumps
       51
       51
1> ,preview
  signal in signals
  loop in complete-to-cps in template->node
  unnamed
  closure->node in template->node
  x->node in cfa-optimizer-frontend
  unnamed in cps-transform-globals in cfa-optimizer-frontend
  loop in for-each1 in scheme-level-1
  cps-transform-globals in cfa-optimizer-frontend
  analyze-proc/bench in cfa-optimizer-frontend
  lp in run-benchmark in cfa-bench
  loop in for-each1 in scheme-level-1
  evaluate-and-select in command-processor
  command-loop
  thread-start in thread-top-level in threads
-----------

when I try to CPS-convert the following code:
-----------
(define (app flag)
  ((lambda (f arg)
     (+ 16 (f arg)))
   (if flag

Pre-Scheme Raytracer

Sure thing.  I took out the pre-made Scheme48 images also, which were  
the biggest files in the tarball.  You'll have to make your own Pre- 
Scheme compiler image (you would have needed to do this anyway if  
using a different version of Scheme48) if you need to compile  
schemeray.  A pre-made i386 Mach-O binary is included.

For those of you just tuning in - here is a raytracer I wrote in Pre- 
Scheme.  It is a rough sketch of something I've been wanting to do.   
It has a few serious flaws, mainly that it doesn't clean up after  
itself.  The general malloc'ing/free'ing activity is poorly optimized  
and handled.  I'm working on turning a lot of the vector operations  
destructive, and making sure I free what I allocate.  This should make  
it run faster.

There are also a bunch of optimizations I want to make.  It still runs  
rather well - about twice as fast as the equivalent Gambit-C program.   
This is to be expected, of course, as we aren't running through any  
kind of virtual machine.

- James

On Jun 4, 2008, at 2:18 AM, Michael Sperber wrote:

>
> This is great.  I'd love to forward this to the mailing list, but the
> attachment is too big for that.  Would you be willing to resubmit  

-pthread unrecognized

This doesn't seem to make any difference. Just an FYI.  -Jonathan

30-16-246:~/nc/trunk jar$ make scheme48
mkdir -p `dirname ../build/downloads/scheme48-1.8.tgz`
wget -nv -O ../build/downloads/scheme48-1.8.tgz http://s48.org/1.8/ 
scheme48-1.8.tgz
17:36:00 URL:http://s48.org/1.8/scheme48-1.8.tgz [3173151/3173151] ->  
"../build/downloads/scheme48-1.8.tgz" [1]
mkdir -p ../build/external
tar -x -z -f ../build/downloads/scheme48-1.8.tgz -C ../build/external
(cd ../build/external/scheme48-1.8; ./configure; make)
checking build system type... i386-apple-darwin8.11.1
checking host system type... i386-apple-darwin8.11.1
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether we must build a 32bit binary... no
checking bits per byte... 8
checking size of void *... 4
checking for BIT_SUFFIX... 32
checking whether we are building a Universal Binary... no
checking how to compile position independent code... no extra option  
necessary
checking -rdynamic... yes

full polymorphism in Pre-Scheme

Hi,

I have a few questions about Pre-Scheme's type system.  I will be  
referencing the following paper as "the paper":

Pre-Scheme: A Scheme Dialect for Systems Programming (http://citeseer.ist.psu.edu/196055.html 
)

and I am using Pre-Scheme from scheme48 v1.8.  Note that I don't have  
much experience with type systems, this is just my first step in  
understanding them.  I am interested in these problems because I would  
like to extend Pre-Scheme's type system to treat numbers with more  
granular interest, such as integer16 and integer32.

------

1.The paper states that Pre-Scheme's type reconstruction algorithm  
supports 4 kinds of polymorphism, one of them being full  
polymorphism.  The example case in the paper to illustrate this is one  
which would normally be rejected by basic type systems:

(define (add-one x)
   (+ x 1))

(* (add-one 1.5)
     (vector-ref v (add-one 3)))

I understand the polymorphic nature of the above expressions, and how  
full polymorphism would support this.  The problem is that Pre-Scheme  
does *not* seem to support this, from pragmatic testing.  The  

Re: File too large

Jonathan Rees <jar <at> creativecommons.org> writes:

> Error: File too large
>        (&primitive-i/o-error (status . 27) (operation . #{Procedure
> 2490 (call-with-input-file in channel-ports)}) (arguments "/work/gene/
> xml/Danio_rerio.xml"))
> make: *** [/work/gene/ttl/Danio_rerio.ttl] Error 1
>
>
> [jar <at> ashby trunk]$ ls -l /work/gene/xml/Danio_rerio.xml
> -rw-rw-r--  1 jar nc 2576696915 May  3 18:49 /work/gene/xml/
> Danio_rerio.xml
> [jar <at> ashby trunk]$
>
>
> Why should scheme48 care how big the file is?

Scheme 48 is just passing something on it's getting from the operating
system.  Is this Linux?  If so, I think this may be relevant:

http://www.suse.de/~aj/linux_lfs.html

> If I switch to the 64-bit version will this start working?

I would hope so.

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

File too large

Error: File too large
        (&primitive-i/o-error (status . 27) (operation . #{Procedure  
2490 (call-with-input-file in channel-ports)}) (arguments "/work/gene/ 
xml/Danio_rerio.xml"))
make: *** [/work/gene/ttl/Danio_rerio.ttl] Error 1

[jar <at> ashby trunk]$ ls -l /work/gene/xml/Danio_rerio.xml
-rw-rw-r--  1 jar nc 2576696915 May  3 18:49 /work/gene/xml/ 
Danio_rerio.xml
[jar <at> ashby trunk]$

Why should scheme48 care how big the file is?
If I switch to the 64-bit version will this start working?

Thanks
Jonathan