foo-devel — foo development list

[foo-devel] current elk status

[martin r. <li...@ru...>]

dear elk-scheme makers,

i just discovered your site elk-scheme.de.

since i can't find any hint on your site regarding the date of the
last changes of you site, i was wondering if the elk-scheme.de
-project is a recent one and whether it's still active...

i am one of the developers of a sound synthesis system which is
written in objective-c and which uses elk (since 1993).  now we are
porting the stuff to linux and mac os x and developing it further.

thus we are interested in the current development status of elk.
what's the relation of your site and current elk development?  are you
in touch wich sam hocevar, which is the current elk maintainer, as far
as i know?  since his elk-site seems to be down for a time, do you
know what's happening?

i just want to gather some information about remaining development
efforts regarding elk and about the current users of elk.

all the best,

martin

[foo-devel] elk website

[martin r. <li...@ru...>]

dear sam,

what happened to the elk website?  it seems to be down for the last
time...

we've got a problem which seems to be related to elk's garbage
collector:

> (require 'record)

> (define (crash) (collect) (crash))
crash
> (crash)

Panic: Visit: object not in prev space at 0x401dcf44 ('pair') 3 277 (dumping core).
Aborted

this occurs just after starting elk.  after having evaluated some
stuff, this bug sometimes doesn't appear.

we know a bug like this since several years on different platforms
(NeXTStep, Irix, Linux) in different environments (sound synthesis,
3D-environment).

this time i thought it's related to our application, but with the
above lines it's possible to kill pure elk.  the (require 'record) is
necessary for this, (require 'oops) e. g. doesn't show this behavior.

i don't know if (collect)ing in an endless loop is the right thing to
track that down, but it's the only possibility i found so far to
reproduce the bug.

after a quick view over the record extension i can't find any obvious
bug.

how to track that down?  is this a known bug?

all the best

martin

Re: [foo-devel] libsndfile

[Ramon Gonzalez-A. <ar...@ma...>]

Dear Martin,

Unfortunately no. I'm afraid I didn't express myself well enough. I have 
not yet been able to have foo-0.0.3 running. As a matter of fact, I 
managed to have foo-elk running, and then I started the 
download/installation of the GNU system (base and make) as you 
suggested, following also the steps that Gerhard documents in one of his 
mails. I have stopped, because the compiler I have is a gcc2.something 
version, and for all that I read I should better compile with 
gcc3.whatever. And this is a problem, because I don't want to break 
anything and I don't feel very secure. This, stated in a sourceforge 
devel list, is probably almost a blasphemy (shame on me!) but so is life.

I am using fooL-0.0.1. Actually I was using fooL-0.0.2, until I had this 
problem I mentioned, which I assigned to libsndfile. So I migrated to 
fooL-0.0.1. I am interested in keeping alive fooL-0.0.1 because it 
allows me to run my old code without any changes 
(sndfile-format/sndfile-type related). Actually I wanted to do the new 
work already with fooL-0.0.2 because of obvious reasons. (and if 
possible, of course, with foo-0.0.3).

Concerning libsndfile. My files are not huge, but the process of 
creating them complex (they call functions which call functions bla bla 
bla). Therefore, what I said, that they are useless in order to trace 
the real problem. My feeling is that it is related to the blending. (You 
know, we open an sndfile and add to the contents of the file the result 
of our new calculation). But, as I said, I am not 100% positive. I'll 
have to do a simple test, so that the problem can be traced.

I think your new (crash) test is rather interesting. What is important 
to know is if elk by itself crashes, without readline or foo. Your last 
test points in that direction. Another good choice to blame is oops of 
course. I will try that one too. I don't think it is a silly test, 
because I don't think the interpreter should be killed by collecting 
once and again. But, if you want to be sure, just wait for Gerhard's 
tip. I guess he will re-incorporate to foo-life tomorrow.

All the best,

Ramon

Re: [foo-devel] libsndfile

[martin r. <fo...@ru...>]

On Sun, Feb 29, 2004 at 05:41:50AM +0100, Ramon Gonzalez-Arroyo wrote:
> I yet cannot proof it, but I'm not very sure of libsndfile. I believe, 
> for instance, that "blending" is not working correctly. I know we need a 

so, did you manage to get foo-0.0.3 running on your system?
congratulations!  from gerhard reports, i got the impression that
building gnustep on readhat is rather painful...

> clearcut simple test that shows it, and what I have is a something huge. 

hmm, there were reports on the linux audio list that in
libsndfile-1.0.5 was a bug regarding files > 2 GB, which is fixed
again in 1.0.6.  but apart from that: i think libsndfile is the last
place to look for an error, it is used in so many audio projects all
over the world, that bugs should get discovered rather quickly.

instead, i would take the responsability rather on my shoulders
regarding the libsndfile integration with foo.

> But when I ran the same thing with fooL.0.0.2 and fooL.0.0.1, the 
> results are quite different. In the second case it is as expected, in 
> the first case its garbage (not-collected).

so, fooL-0.0.1 works as expected, -0.0.2 produces garbage?  good to
know.  the sndfile-interface is still a weak thing after porting.  in
0.0.2, support for creating/writing soundfiles with different types
was introduces, who knows...

anyway, a small, clean example would be great to track this down.

> Item 2. Martin, you could have called your talk something like:
> 	Once again text & parenthesis but less silly :
> 	sound synthesis with Foo

didn't want to face fernando with the hard reality... :-)  guess, i'm
lacking some knowlege about CLM, CM, Nyquist etc...  i heard something
about rick taube was porting all his stuff to scheme...

btw. what is your opinion regarding my (crash) -test?  i think,
collecting garbage again and again must not kill the interpreter.  i
am just thinking about reporting this issue to the elk maintainer.  i
am just afraid of leaving the impression of coming with silly tests to
prove something completely unrelated...  just bless me... :-)


bests,

martin

[foo-devel] libsndfile

[Ramon Gonzalez-A. <ar...@ma...>]

Dear Sirs,

I yet cannot proof it, but I'm not very sure of libsndfile. I believe, 
for instance, that "blending" is not working correctly. I know we need a 
clearcut simple test that shows it, and what I have is a something huge. 
But when I ran the same thing with fooL.0.0.2 and fooL.0.0.1, the 
results are quite different. In the second case it is as expected, in 
the first case its garbage (not-collected).


Item 2. Martin, you could have called your talk something like:
	Once again text & parenthesis but less silly :
	sound synthesis with Foo

		(joke, of course)


Ramon

[foo-devel] sincerely, your garbage collector

[martin r. <fo...@ru...>]

dear foo developers,

while trying to tracking down the problem, there were some first
interesting things discovered:

* bug in the new readline extension (GC_Link issue, as expected)

BUT:

if i run fooelk without readline, the following lines bring the crash,
too:

> (require 'record)
[dlopen /usr/local/lib/fooelk/record.so]
[calling elk_init_lib_record]

> (define (crash) (collect) (crash))
crash
> (crash)

Panic: Visit: object not in prev space at 0x401e4f14 ('symbol') 3 1521 (dumping core).
Aborted

at least a small hint.

unfortunetaly, i have a huge exam on monday, thus i can't hack too
much this weekend...  but i am really tensed, hoping it's the bug we
are looking for...

bests,

martin

Re: [foo-devel] Re: [foo-announce] foo-0.0.3 released

[martin r. <fo...@ru...>]

dear ramon,

On Fri, Feb 27, 2004 at 12:59:41PM +0100, Ramon Gonzalez-Arroyo wrote:
> I have managed to compile,install and run fooelk, but when trying to 
> install foo ==>
> 
> I run ./config and it returns the following error:
> 
> configure: error: You must run the GNUstep initialization script first!
> 
> I don't see any GNUstep initialization script.

i guess you are lacking gnustep-make and gnustep-base on your system.
the binary version coming with fooL doesn't come with the necessary
header files (if i remember correctly, i removed them from the binary
distribution to save space).  after installing these packages you have
to source the GNUSTEP_ROOT/System/Makefiles/GNUstep.sh or .csh into
your shell.

compiling gnustep can get a bit tedious: i guess you have to install
libffcall before (like gerhard had to).  but perhaps gerhard could
bundle his binary GNUstep system for you, if your redhat versions are
compatible.

you may also go to http://www.gnustep.org. ther are compiling
instructions for the packages.  for foo, you'll need gnustep-make and
gnustep-base (no gnustep-gui).

in the meantime, i found a bug (i think it's one) in my readline
extension.  unfortunately, that wasn't all.

> I have run your (crash) function with fooelk. It doesn't crash, at least 
> after some "good time" running. Memory expands, though.

if you run

fooelk -l toplevel-readline.scm

the readline extension is used, and fooelk should crash on (crash).
but foo anyway still crashes without readline extension, too.

all the best,

martin

[foo-devel] Re: [foo-announce] foo-0.0.3 released

[Ramon Gonzalez-A. <ar...@ma...>]

I have managed to compile,install and run fooelk, but when trying to 
install foo ==>

I run ./config and it returns the following error:

configure: error: You must run the GNUstep initialization script first!

I don't see any GNUstep initialization script.


Yet another item:

I have run your (crash) function with fooelk. It doesn't crash, at least 
after some "good time" running. Memory expands, though.

Best,
ramon

[foo-devel] latest mail: most serious things: foo-0.0.3

[martin r. <fo...@ru...>]

dear foo developers,

sorry for the huge bunch of mails sent by me this night.  i just took
the time to answer most of the open questions.

but now the serious thing:

as i announced earlier, i finally released foo-0.0.3 and
fooelk-0.0.2. (available at http://sourceforge.net/projects/foo)
though the new features were promising, i had to notice that the
garbage collector bug is still present, apparently.

the first time in my life i saw the error, and that with the new
foo...  i am quite disappointed.

rumori@amadora:~$ foo -h 2048
foo sound synthesis version 0.0.3
(C) 1993-2004 gerhard eckel, ramon gonzalez-arroyo, zkm, ircam
(C) 2003-2004 martin rumori

foo: panic: Visit: object not in prev space at 0x40217878 ('compound') 3 5 (dumping core).
Aborted


NEXT TRY:

rumori@amadora:~$ foo -h 32768
foo sound synthesis version 0.0.3
(C) 1993-2004 gerhard eckel, ramon gonzalez-arroyo, zkm, ircam
(C) 2003-2004 martin rumori
foo> 

starts up, but:

foo> (define (crash) (collect) (crash))
crash
foo> (crash)

foo: panic: Visit: object not in prev space at 0x401e0b8c ('symbol') 3 169 (dumping core).
Aborted

takes half a second to kill foo.  in contrast, starting just fooelk
and doing that doesn't crash (though slowly increases the memory
footprint of elk, when watching it with top.  wasn't that called
"proper tail recursion" or what?).

since it's such a big problem, i hope that there's somewhere an issue
with GC_Link in foo.  looks like it.  how to track that down?


CVS CHECKIN
-----------

for the next steps, i checked in foo-0.0.3 in listen-cvs (foo/foo).  i
didn't touch the old porting tree (foo/work), since the directory
layout of the new archive has been completely changed.  ramon, you may
checkin your updated control library, so that all of us have access to
it.  this way it's easier to maintain the changes.

i still wanted to wait before using the sourceforge-cvs until the
greatest problems have been solved.


FUTURE
------

http://rscheme.org

if nothing else helps: coming with a hard realtime capable garbage
collector, still maintained, compiling scheme to bytecode or even to
c, thus promising performance.  i don't know nearly nothing about it,
but perhaps worth a look if the problem is really related to elk.


i am just a bit desperated after all the hard work...   will get some
sleep know.

all the best,

martin

Re: [foo-devel] Some aspects of life

[martin r. <fo...@ru...>]

On Wed, Feb 25, 2004 at 08:39:16PM +0100, Ramon Gonzalez-Arroyo wrote:
> the Next, as related to number calculations, and the same or similar 
> errors happen. I am rather puzzled, though,  because since I am using 
> fooL.0.0.2 I am becoming aware of problems, which (by chance?) never 
> showed up before.(10 years after!). But now I know.

must have something to do with the precision, so that error showed up
much later on the NeXT.  but not comfortable, anyway.  that's computer
life.

there's just the chance to implement fractional number arithmetics
using only integer operations.  not so performant anyway, but for
musical things a good thing.  and writable in scheme, of course...

> 2. As related to the new foo-release (with new elk), I am wondering if 
> we should first try to see, whether we need the oops patch. If we do, we 
> cannot use optional arguments in methods; if we don't we can. In other 

i even don't understand, what is does.  since gerhard has lots of time
now, i think it's the perfect job for him :-)

bests, martin

Re: [foo-devel] Some aspects of life

[martin r. <fo...@ru...>]

On Tue, Feb 24, 2004 at 02:23:24AM +0100, Ramon Gonzalez-Arroyo wrote:
> >- soundfile creation/processing with foo (linux) -> .aiff-file
> >- soundfile convert with 'sndconvert' (linux)	 -> .snd-file
> >- importing that file into foo (next)		 -> channels swapped
> >
> 
> Almost. I create the aiff file with Foo-Linux. I convert it into 
> .snd-file with sndfile-convert (linux) (~fooL/bin/), I import it into 

ahh, o.k.  i don't know much about sndfile-convert, it is just a small
tool coming with libsndfile (used in foo for reading/writing different
types of soundfiles) to demonstrate its capabilities.  perhaps it's
mixing up something or the next understands the format a bit
different...  but you could report this issue to erik de castro-lopo,
the author of libsndfile.  i don't know it's address by mind, but you
could google for "libsndfile" and i guess you will meet his site with
a bug report address...

anyway, for the future we could write small foo scripts (like gerhard
does earlier) e.g. to convert soundfiles.

Another item, this time about sndfile-play. If you try to play a mono
file, with a soundcard that only accepts stereo files (as it is my
case), it plays at double speed. /usr/bin/play on the other hand

sndfile-play is just the other tool coming with libsndfile.  it makes
use of oss-output, which is the old audio driver on linux.  i just
took sndfile-play since it was instantly available.  there's no reason
why we shouldn't include another tool into kernel.foo.  perhaps it
should be a tool using alsa (like aplay), but aplay doesn't use
libsndfile and therefore just plays wav or so.

> Again thanks for your answer. I'll try to prepare a lower-cased control 
> with some corrections I have been doing in time for the new release. 

fortunetaly, this issue is solved.  the behaviour of elk regarding
case-sensitivity was configurable (-i).  now the default behaviour
changed from case-sensitive to insensitive.  option (-g) is now used
to force to case-sensitive mode.  don't know where the garbage-collect
flag (-g in former times) has gone...  i just changed the case
bahaviour of elk in the startup code of foo, now everything is working
fine.

the bad thing with lower-case symbols is not just the filenames, but
all symbols, thus a simple

(tell 'Add 'alloc) or so wouldn't proceed, since it looks after class
"add"...

bests,

martin

Re: [foo-devel] building gnustep

[martin r. <fo...@ru...>]

On Wed, Feb 25, 2004 at 10:18:02AM +0100, Gerhard Eckel wrote:
> to install GNUstep and compile foo-0.0.2, but I get the following error 
> when I try to run it:
> 
> % ./foo
> load: dlopen failed:
> "/usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1: undefined 
> symbol: gnustep_base_user_main"
> 
> Any ideas?

no at all.  i never saw this before.  looks really weird.  but from my
experience with gnustep/gnustep-make, i remember that i had sometimes
issues like that: looks like gnustep-make doesn't check linking for
unresolved symbols after building.

/* grepping through gnustep */

found a hint: you could check the file

GNUSTEP_ROOT/System/Library/Headers/GSConfig.h

approx line 38, if

#define GS_FAKE_MAIN	0

is set to '1' in your configuration.  maybe the configure script
decided to set this to yes on your system.   the comment following
this define is quite interesting and funny.  perhaps that's the
problem on your system.

if i read gnustep-base/configure.ac correctly, this happens, if

AC_DEFINE(HAVE_LOAD_METHOD,1,
            [Define if your Obj-C compiler calls +load methods before main])

is not true, whatever this particularly means, and/or your system
doesn't have a /proc filesystem (AC_SYS_PROCFS) (which is for sure not
the case).  perhaps it's a compiler related issue with this load
method.

GSConfig.h states that we have to include it if GS_FAKE_MAIN is set in
our program which implements the main function and which links again
libgnustep-base.  since in case of foo-0.0.2 the main function is in
elk, which gets indirectly linked against libgnustep-base when loading
libfoo.so, we had to include this file in elk...  ugly.

fortunetaly, this is not true for foo-0.0.3, which i just released
(see next mail).  i added the #include <GSConfig.h> to
Source/Main/main.c (listen CVS only), if it works for you, you could
try to comment it out and see if the error occurs again.  would be a
good hint.

if not, we could try to link the foo executable (built from main.c)
explicitly against libgnustep-base (which is not the case now since it
should be enough to link it against libelk/libfooelk).

but perhaps we should figure out whether this #define is set on your
system.

>  http://old_fool.rumori.de/dl/0.0.1/fooL-0.0.1-bin.tar.gz

> does not download (with mozilla) ...

yahoodomains seems to have problems.  please try directly:

http://www.informatik.hu-berlin.de/~voelkel/projects/old_fool/

hope that'll work.

all the best,

martin

Re: [foo-devel] Some aspects of life

[Ramon Gonzalez-A. <ar...@ma...>]

Hello,

1. It seems I was quite wrong. I have checked what the situation is in 
the Next, as related to number calculations, and the same or similar 
errors happen. I am rather puzzled, though,  because since I am using 
fooL.0.0.2 I am becoming aware of problems, which (by chance?) never 
showed up before.(10 years after!). But now I know.

2. As related to the new foo-release (with new elk), I am wondering if 
we should first try to see, whether we need the oops patch. If we do, we 
cannot use optional arguments in methods; if we don't we can. In other 
words, if we can use optional arguments in methods, I would use the 
original object definitions, but if we are forced to patch oops again, 
then, and until the patch is revised to see why does it prevent the 
usage of optional arguments (which seems to be a side effect rather than 
a wished feature), we should release the "cleaned" class definitions. 
What do you think?

Ramon

Fwd: [foo-devel] building gnustep

[Gerhard E. <ger...@im...>]

was sent to Martin only ...

Begin forwarded message:

> From: Gerhard Eckel <ger...@im...>
> Date: February 25, 2004 10:22:39 AM CET
> To: martin rumori <fo...@ru...>
> Subject: Re: [foo-devel] building gnustep
>
> Hello Fooers,
>
> in my last email I forgot to add that I had to add /usr/local/lib to 
> the LD_LIBRARY_PATH so that libsndfile was found.
>
> So the full list should read:
>
> For the record, here is what I did to get things installed (with 
> standard documented procedures):
>
> installed gnustep from:
>  ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-make-1.9.0.tar.gz
>  ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-base-1.9.0.tar.gz
>  configured gnustep-base with
>   --with-ffcall-include=/usr/local/include 
> --with-ffcall-library=/usr/local/lib
>
> installed libffcall from:
>  ftp://ftp.santafe.edu/pub/gnu/ffcall-1.9.tar.gz
>
> installled libsndfile from:
>   http://www.mega-nerd.com/libsndfile/libsndfile-1.0.6.tar.gz
>
> Changed (load 'libfooL.so) to (load 'libfoo.so) in toplevel.foo
>
> Add /usr/local/lib to LD_LIBRARY_PATH in bash:
> % LD_LIBRARY_PATH=$LD_LIBRARY_PARH:\/usr/local/lib
>
> Best regards,
>
> Gerhard
>

Re: [foo-devel] building gnustep

[Gerhard E. <ger...@im...>]

Dear Martin,

than you for the pointers to build GNUstep and foo-0.0.2. I now managed 
to install GNUstep and compile foo-0.0.2, but I get the following error 
when I try to run it:

% ./foo
load: dlopen failed:
"/usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1: undefined 
symbol: gnustep_base_user_main"

Any ideas?

GNUstep is installed in /usr/GNUstep. Foo is installed in 
/localhome/eckel/src/foo-0.0.2. Here comes my current foo script:

--- cut here ---

#!/bin/sh

# foo script (exerimental)

FOO_TOPLEVEL_FILE="toplevel.foo"

FOO_ROOT_DIR="/localhome/eckel/src/foo-0.0.2"
GNUSTEP_ROOT_DIR="/usr/GNUstep"
ELK_ROOT_DIR=${FOO_ROOT_DIR}
ADDITIONAL_SOFTWARE_DIR=${FOO_ROOT_DIR}

###################################################################

. ${GNUSTEP_ROOT_DIR}/System/Makefiles/GNUstep.sh

FOO_SCM_TOP=${FOO_ROOT_DIR}"/scm/foo"
FOO_LIB_DIR=${GNUSTEP_ROOT_DIR}"/Local/Library/Libraries"
ELK_SCM_TOP=${ELK_ROOT_DIR}"/share/elk"
ELK_LIB_DIR=${ELK_ROOT_DIR}"/lib/elk"

PATH=${PATH}:${ADDITIONAL_SOFTWARE_DIR}"/bin"
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${ADDITIONAL_SOFTWARE_DIR}"/lib"

export PATH LD_LIBRARY_PATH

# call the interpreter
scheme_foo -l ${FOO_TOPLEVEL_FILE} \
     -p ${FOO_SCM_TOP}:${FOO_LIB_DIR}:${ELK_SCM_TOP}:${ELK_LIB_DIR}

--- cut here ---

For the record, here is what I did to get things installed (with 
standard documented procedures):

installed gnustep from:
  ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-make-1.9.0.tar.gz
  ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-base-1.9.0.tar.gz
  configured gnustep-base with
   --with-ffcall-include=/usr/local/include 
--with-ffcall-library=/usr/local/lib

installed libffcall from:
  ftp://ftp.santafe.edu/pub/gnu/ffcall-1.9.tar.gz

installled libsndfile from:
   http://www.mega-nerd.com/libsndfile/libsndfile-1.0.6.tar.gz

Changed (load 'libfooL.so) to (load 'libfoo.so) in toplevel.foo

By the way:

  http://old_fool.rumori.de/dl/0.0.1/fooL-0.0.1-bin.tar.gz

does not download (with mozilla) ...

Best regards,

Gerhard

Re: [foo-devel] Some aspects of life

[Ramon Gonzalez-A. <ar...@ma...>]

I have just seen your mail, after I sent mine.

> 
> i could imagine that elk under NeXT used single precision floating
> point numbers (32 bit), while elk with linux seems to use double
> precision (64 bit).  then the rounding errors are noticeable
> "earlier".  i was wondering about that when implementing the new
> "fractional tones" reader extension (supporting semi- and
> quartertones, until now), since the static mulitpliers got much longer
> now than in the NeXT version (calculated with elk, of course...).
> 
> 
>> >

This makes sense, concerning what is happening, but it still is weird.


> - soundfile creation/processing with foo (linux) -> .aiff-file
> - soundfile convert with 'sndconvert' (linux)	 -> .snd-file
> - importing that file into foo (next)		 -> channels swapped
> 

Almost. I create the aiff file with Foo-Linux. I convert it into 
.snd-file with sndfile-convert (linux) (~fooL/bin/), I import it into 
the Next, but not into Foo. I am playing it there, because it is there 
that I have 4-channel dacs. I thought it was some bug of the 
sndfile-convert, but what I don't understand is that if I sndnorm it in 
the Next, then the channels are put correctly. Of course sndnorm creates 
another file, but seems to understand the channels correctly....

Concerning cases and filenames. There are two distinct parts. One is the 
control library. There it is finally not a big deal to rename all files 
to lowercase and change the initialize too. The other part is all of the 
files of my previous compositions, or libraries of things which have not 
(yet?) made their way into a general release. These are many.

> fortunetaly, that does not apply to soundfiles in foo, since they are
> strings on the scheme side.
> 

Does this mean that if I load a file not as a symbol but as a string 
then the problem is gone?

So if I write (load "Whatever/Or/whateveR") it works?

Then it would be cool, because I think I have always (or almost always) 
acted so. Or maybe I am understanding it wrongly"

Again thanks for your answer. I'll try to prepare a lower-cased control 
with some corrections I have been doing in time for the new release. 
WHen do you want to

Best,

Ramon

Re: [foo-devel] Some aspects of life

[Ramon Gonzalez-A. <ar...@ma...>]

Dear friends,

Thanks for your answers.

I know that the "Panic: Visit :object not in prev space" happens in both 
garbage collector modes. We (I) had always used the so called 
stop-and-copy gc before, and now we are using the generational one. I 
think that the heap size can only be set when using the stop-and-copy 
gc, and the size is in KByets, not MBytes. At least 
foo-2.1/src/elk-3.0/config/site says:

# The default heap size of the Scheme interpreter in KBytes (if the
# stop-and-copy garbage collector is used).

I wonder if it would make sense to compile a fooL-0.0.2 with 
stop-and-copy gc. I don't have the sources, and most probably I will be 
lacking something or other in my computer in order to compile it.

Concerning the number question I think indeed the problem is much more 
dramatic under the present circumstances than it was with the Next, or 
even a PC running NextStep. Or at least, this seems to me now. I am 
using  libraries of objects/functions I have had been building since 
long, and I am encountering now all of these problems, which I was not 
aware of previously. I know the problems with floats/doubles, but I 
though this was more related with old Lispian languages: I remember I 
had similar questions with LeLisp at Ircam. With the Next and elk, well, 
now and then one would encounter one such inconsistency , but I had 
never seen something as bad as it seems to me now. Perhaps I am a bit 
off, but to me these ones :

(= 0.1 (+ 0.04 0.06))  ==> #t
(= 0.1 (+ 0.04 0.05 0.01)) ==> #f
(= (* 100 0.1) (* gu 100))  ==> #t
(= (* 1000 0.1) (* gu 1000))  ==> #f

leave me trembling!

Concerning the case of filenames. Since I am touching almost all control 
files now and then, perhaps I can start a clean-of-cases process, when 
you think it convenient.

Let's see how the new Elk works.

All the best,

Ramon


P.S. I mentioned sndconvert in my previous mail. I should have called it 
sndfile-convert which is its proper name. (I had made an aliased link, 
so I might have confussed you about which program it is.

Another item, this time about sndfile-play. If you try to play a mono 
file, with a soundcard that only accepts stereo files (as it is my 
case), it plays at double speed. /usr/bin/play on the other hand 
recognizes the problem and overrides format, playing it correctly. This 
one is even as cunning as playing four channels soundfiles correctly 
(but only two channels of course).

Re: [foo-devel] Some aspects of life

[martin r. <fo...@ru...>]

On Sun, Feb 22, 2004 at 02:30:01PM +0100, Ramon Gonzalez-Arroyo wrote:
> I don't know if these should go to foo-devel or to foo-users, or perhaps 
> only to the gentlemen behind. But, anyway.

from my point of view: definitely to foo-devel.  foo-users should be
for user questions and problems (how do i make a 440 Hz sine?), while
foo-devel is for bug reports or development-specific stuff...  though
there are questions applying to both the lists...

On Mon, Feb 23, 2004 at 04:39:16PM +0100, Gerhard Eckel wrote:
> >Panic: Visit: object not in prev space at 0x4159b7d4 ('signal') 423 
> >425 (dumping core).
> >/localhome/ramon/bin/fooL: line 28:  1969 Aborted scheme_foo -l 
> >${FOO_TOPLEVEL_FILE} -p 
> >${FOO_SCM_TOP}:${FOO_LIB_DIR}:${ELK_SCM_TOP}:${ELK_LIB_DIR}
> 
> Indeed, I do!

o.k., looks like this IS the famous bug i never saw before...

> did for Raumfaltung) and apply this to foo. As soon as I have a running 
> version of foo on my laptop, I can start working on this.

> >> (= (* 100 0.1) (* gu 100))
> >#t
> >> (= (* 1000 0.1) (* gu 1000))
> >#f

> I am afraid this is a usual problem with floating point computation 
> independently of what language or system one uses. As far as I know one 
> can never rely on the float/double computation in the way your examples 

i thought of replying in quite the same way.  yes, i guess it's not
just a scheme but a general floating point operation problem.

> imply. Do I understand right that the results on the NeXT are
> different than under Linux?

i could imagine that elk under NeXT used single precision floating
point numbers (32 bit), while elk with linux seems to use double
precision (64 bit).  then the rounding errors are noticeable
"earlier".  i was wondering about that when implementing the new
"fractional tones" reader extension (supporting semi- and
quartertones, until now), since the static mulitpliers got much longer
now than in the NeXT version (calculated with elk, of course...).

> >This was the second aspect. Third aspect refers to
> >
> >sndconvert.

is 'sndconvert' a binary tool on linux?  first i thought it's a foo
function, but i don't find anything in the foo code.   but strange
enough.  but i am not quite sure about the procedure that's going on:

- soundfile creation/processing with foo (linux) -> .aiff-file
- soundfile convert with 'sndconvert' (linux)	 -> .snd-file
- importing that file into foo (next)		 -> channels swapped

is that correct?

> >Last. What is the problem with lower-case/upper-case and the control 
> >library? Am I defining functions with the same name but difference of 
> >case only? I don't think so, but if that is the "case", it should be 
> >corrected, of course. Please tell me.
> 
> It is filenames which are in question and not scheme symbols.

yes.  since sam doesn't react to my questions until now (perhaps it's
a problem to figure out what's wrong, or holiday or whatever), i think
we should find a solution now.  that way, we could release the next
version of foo.

the thing in question is to rename all the FILEnames of the foo
control library to lowercase (e.g. Abstraction/Funx-Type.foo ->
abstraction/funx-type.foo).  that would be a workaround for the
problem right now.  it doesn't solve the problem that files with
uppercase names are not accessable from inside elk in the moment.
fortunetaly, that does not apply to soundfiles in foo, since they are
strings on the scheme side.

ramon: do you rely on the spelling of the filenames in your
compositions?  even if yes, if we just lowercase the names, scheme
will do as well and find the file, if specified as "Funx-Type.foo" or
"funx-type.foo".  but i guess, it is not used.  the files are loaded
in initialize.foo once, and if we correct that, too, the problem is
gone.

but there might remain problems with the code of your pieces if you
use uppercase letters in their filenames.  too bad, i hope it will be
solved soon, but it's a general scheme/elk thing.

all the best,

martin

Re: [foo-devel] Some aspects of life

[Gerhard E. <ger...@im...>]

Dear Ramon,

I am sorry to hear that you still have to work with the NeXT!

> I guess you remember this one :
>
> Panic: Visit: object not in prev space at 0x4159b7d4 ('signal') 423 
> 425 (dumping core).
> /localhome/ramon/bin/fooL: line 28:  1969 Aborted scheme_foo -l 
> ${FOO_TOPLEVEL_FILE} -p 
> ${FOO_SCM_TOP}:${FOO_LIB_DIR}:${ELK_SCM_TOP}:${ELK_LIB_DIR}

Indeed, I do!

> Foo (fooL which I'm running at the moment), goes blindingly fast. So 
> one can do more, but more means more of the panics, so I'm suffering 
> much. With respect to this, I remember elk had two memory allocation 
> (garbagge collection) modes, one was incremental and the other static, 
> or something of the kind. I think the bin versions I have are of the 
> incremental type. WIth the static type I used to increment the 
> elk-space in order to have less gc's and less probability of visiting 
> a gc'd object. With the incremental one I think we have no handle, do 
> we?

When starting elk, one can set the heap size with the flag -h 
<heap-size-in-Mb>. This should allow you to allocate a huge heap 
provoking less collects. By setting garbage-collect-notify? to #t, you 
can see when it collects and how much the collector reclaimed. With 
(garbage-collect-status) you get the current collector type. The 
collector type can only be choosen at compile time. From what I 
remember, the "Panic: Visit: object not in prev space" bug appears in 
both modes, strangely enough.

What we need to do is to see if the bug still appears with the new elk 
and we need to see how we could circumvent the problem in Avango (as we 
did for Raumfaltung) and apply this to foo. As soon as I have a running 
version of foo on my laptop, I can start working on this.

> This was aspect number one.
>
> Aspect number two can be shown as follows :
>
> > (= 1.0 (* 0.1 10))
> #t
> > (= 1.0 (+ 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1))
> #f
> > (= 1 (/ 1.0 (+ 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1)))
> #t
>
> > (= 0.1 0.1)
> #t
> > (= 0.1 (+ 0.05 0.05))
> #t
> > (= 0.1 (+ 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01))
> #f
> > (= 0.1 (+ 0.04 0.06))
> #t
> > (= 0.1 (+ 0.04 0.05 0.01))
> #f
>
> (define gu (+ 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01))
> > (= 1 (/ (* gu 10)))
> #t
> > (= 0.1 (/ gu))
> #f
> > (< 0.1 (/ gu))
> #t
> > (> 0.1 (/ gu 1.0))
> #t
> > (= (* 100 0.1) (* gu 100))
> #t
> > (= (* 1000 0.1) (* gu 1000))
> #f
>
>
> As you may see, there is no way to have an algorithm in elk now which 
> assures one will get a sound result. Depends what calculation gets you 
> to a certain number it will be greater or smaller than the number it 
> should be. This, which is anyway a lispian malady, happens in such a 
> dramatic way, that much code of the previous Next-Foo has to be 
> checked. At the time being I am trying to solve the problem, by 
> defining a set of functions of the type :
>
> (define (igual? a b . precision)
>   (let ((Defaultprecision 1000.0))
>       (set! precision (if (not (null? precision)) (car precision)
> 	                                          Defaultprecision))
>       (= (inexact->exact (* a precision))
>          (inexact->exact (* b precision)))
>  ))
> ;
> which, at least, allows me to compare two numbers. But a real huge 
> pain.

I am afraid this is a usual problem with floating point computation 
independently of what language or system one uses. As far as I know one 
can never rely on the float/double computation in the way your examples 
imply. Do I understand right that the results on the NeXT are different 
than under Linux?

> This was the second aspect. Third aspect refers to
>
> sndconvert.
>
> So sndconvert seems to change the channel mapping when converting aiff 
> files into snd files. Exactly 1 becomes 3 (2->4, 3->1, 4->2). At least 
> this is what happens when read by the NeXt-Cube. Funnily enough, if I 
> sndnorm the soundfile on the NeXT, channels become the correct ones 
> again.

Hmm ... did this work fine on the NeXT? Martin, do you have any idea? I 
don't have a clue ...

> (You may wonder why the .... am I still using the Next, but so is 
> life!!!)
>
> Last. What is the problem with lower-case/upper-case and the control 
> library? Am I defining functions with the same name but difference of 
> case only? I don't think so, but if that is the "case", it should be 
> corrected, of course. Please tell me.

It is filenames which are in question and not scheme symbols.

Best regards,

Gerhard

Re: [foo-devel] Some aspects of life

[martin r. <fo...@ru...>]

On Sun, Feb 22, 2004 at 02:30:01PM +0100, Ramon Gonzalez-Arroyo wrote:
> I guess you remember this one :
> 
> Panic: Visit: object not in prev space at 0x4159b7d4 ('signal') 423 425 
> (dumping core).
> /localhome/ramon/bin/fooL: line 28:  1969 Aborted 
> scheme_foo -l ${FOO_TOPLEVEL_FILE} -p 
> ${FOO_SCM_TOP}:${FOO_LIB_DIR}:${ELK_SCM_TOP}:${ELK_LIB_DIR}

is this the famous garbage collector thing which can be reached with
extensively using call/cc (thus i never saw it before)...

i will try to answer your mail later in detail, but for the first
thing:

fooL-0.0.2 still runs with elk-3.0 (like foo on NeXT), it is just
slightly ported to linux.

the upcoming foo-0.0.3 (with the filename issue remaining before
releasing) uses a patched 3.99.6-elk.  i guess and i hope that there
are many fixes in it since 3.0.  which may lead to some odd things,
too, but i hope not too much...

more later on,

martin

-- 
martinrumori (ma...@ru...)
/* home is where your home directory is */

[foo-devel] building gnustep

[martin r. <fo...@ru...>]

On Sat, Feb 21, 2004 at 04:27:39PM +0100, Gerhard Eckel wrote:
> I could configure and make gnustep-make without problems. With  

great.

> gnustep-base I am apparently lacking libffi. I am using gcc 3.2, which  

yes, i had this problem, too, some time ago...

> -print-file-name=libffi.so should return 2.0.0 or higher, which it  
> doesn't. It just says "libffi.so" and no version number. I installed  

the same behaviour on my system.  gcc seems just to echo what there's
put in if the library is not found.  a full path name is shown if the
library exists (the command shows against which library gcc would link
when requiring this library).

> ftp://rpmfind.net/linux/PLD/current/dists/ac/ready/i386/libffi-3.3.3 
> -1.i386.rpm (not redhat, I know, but I thougt it would do) and this  
> didn't change anything. I am a bit desparate at this point. I also  

perhaps you'll need a "devel"-package, too, which contains the
headers... (libffi-dev or something like that)

whenever i ran into that problem, i used libffcall (with libcallback
in it), which is used by default on my system, too.  libffi is even
not installed.

rumori@amadora:~$ gcc -print-file-name=libcallback.so
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../libcallback.so

i am sure there are redhat packages for libffcall/libffcall-dev,
otherwise you have to build it first...  you may then specify

--with-ffcall-include=xxx --with-ffcall-library=xxx

to ./configure of gnustep-base when it is not found automatically.

i understood it the same way, that gcc-3.x has libffi inside, but my
gnustep-installation (debian) relies on libffcall anyway, so who
knows...

hope that solves the problem...

best,

martin

[foo-devel] Some aspects of life

[Ramon Gonzalez-A. <ar...@ma...>]

Dear Sirs,

I don't know if these should go to foo-devel or to foo-users, or perhaps 
only to the gentlemen behind. But, anyway.

I guess you remember this one :

Panic: Visit: object not in prev space at 0x4159b7d4 ('signal') 423 425 
(dumping core).
/localhome/ramon/bin/fooL: line 28:  1969 Aborted 
scheme_foo -l ${FOO_TOPLEVEL_FILE} -p 
${FOO_SCM_TOP}:${FOO_LIB_DIR}:${ELK_SCM_TOP}:${ELK_LIB_DIR}


Foo (fooL which I'm running at the moment), goes blindingly fast. So one 
can do more, but more means more of the panics, so I'm suffering much. 
With respect to this, I remember elk had two memory allocation (garbagge 
collection) modes, one was incremental and the other static, or 
something of the kind. I think the bin versions I have are of the 
incremental type. WIth the static type I used to increment the elk-space 
in order to have less gc's and less probability of visiting a gc'd 
object. With the incremental one I think we have no handle, do we?


This was aspect number one.

Aspect number two can be shown as follows :

 > (= 1.0 (* 0.1 10))
#t
 > (= 1.0 (+ 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1))
#f
 > (= 1 (/ 1.0 (+ 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1)))
#t

 > (= 0.1 0.1)
#t
 > (= 0.1 (+ 0.05 0.05))
#t
 > (= 0.1 (+ 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01))
#f
 > (= 0.1 (+ 0.04 0.06))
#t
 > (= 0.1 (+ 0.04 0.05 0.01))
#f

(define gu (+ 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01))
 > (= 1 (/ (* gu 10)))
#t
 > (= 0.1 (/ gu))
#f
 > (< 0.1 (/ gu))
#t
 > (> 0.1 (/ gu 1.0))
#t
 > (= (* 100 0.1) (* gu 100))
#t
 > (= (* 1000 0.1) (* gu 1000))
#f


As you may see, there is no way to have an algorithm in elk now which 
assures one will get a sound result. Depends what calculation gets you 
to a certain number it will be greater or smaller than the number it 
should be. This, which is anyway a lispian malady, happens in such a 
dramatic way, that much code of the previous Next-Foo has to be checked. 
At the time being I am trying to solve the problem, by defining a set of 
functions of the type :

(define (igual? a b . precision)
   (let ((Defaultprecision 1000.0))
       (set! precision (if (not (null? precision)) (car precision)
	                                          Defaultprecision))
       (= (inexact->exact (* a precision))
          (inexact->exact (* b precision)))
  ))
;
which, at least, allows me to compare two numbers. But a real huge pain.


This was the second aspect. Third aspect refers to

sndconvert.

So sndconvert seems to change the channel mapping when converting aiff 
files into snd files. Exactly 1 becomes 3 (2->4, 3->1, 4->2). At least 
this is what happens when read by the NeXt-Cube. Funnily enough, if I 
sndnorm the soundfile on the NeXT, channels become the correct ones again.

(You may wonder why the .... am I still using the Next, but so is life!!!)

Last. What is the problem with lower-case/upper-case and the control 
library? Am I defining functions with the same name but difference of 
case only? I don't think so, but if that is the "case", it should be 
corrected, of course. Please tell me.

Sorry, I'm reporting only problems. I am busy using Foo, and seem to be 
a bit off the track with respect to the current developments.

All the best,

Ramon

Re: [foo-devel] ready to go

[Gerhard E. <ger...@im...>]

Dear Foo developpers,

On Feb 16, 2004, at 4:13 PM, martin rumori wrote:

> in the meantime, you can figure out whether there are packages for
> gnustep on redhat.  you will need gnustep-make and gnustep-base.
> alternatively, you may go to http://www.gnustep.org and download these
> two packages.  there are some instruction for installing them on the
> web, too (http://gnustep.made-it.com/BuildGuide/).  for me it wasn't
> very difficult to build them when using a recent gcc (>= 3.2).  as far
> as i know, you don't need window maker, perhaps not even the graphics
> libraries (not sure about that, ./configure should complain), because
> we don't need gnustep-gui for foo.

I could configure and make gnustep-make without problems. With  
gnustep-base I am apparently lacking libffi. I am using gcc 3.2, which  
is supposed to come with libffi (as far as I understand). In  
http://gnustep.made-it.com/BuildGuide I read that gcc  
-print-file-name=libffi.so should return 2.0.0 or higher, which it  
doesn't. It just says "libffi.so" and no version number. I installed  
ftp://rpmfind.net/linux/PLD/current/dists/ac/ready/i386/libffi-3.3.3 
-1.i386.rpm (not redhat, I know, but I thougt it would do) and this  
didn't change anything. I am a bit desparate at this point. I also  
tried gcc 3.3 which is installed on my machine for Avango, but it isn't  
built with the Obj-C part, so I am lost. Any ideas?

Best regards,

Gurx

Re: [foo-devel] next foo release deferred

[martin r. <fo...@ru...>]

On Fri, Feb 20, 2004 at 04:28:55PM +0100, Gerhard Eckel wrote:
> I used gcc 3.3. The configure script printed the following summary at 
> the end:
> 
> Elk configuration summary
> build C++ plugins: no
> libgdbm support: no
> X11 support: no
> Xaw support: no
> Motif support: no
> build documentation: yes

most of this must have something to do with lacking X11-support on mac
os x.  apparently the development libraries are not included with
X11.app...  anyway, doesn't matter for foo.

great to hear that.  building elk on mac os x is the first step.
gnustep is also available for mac os x.  i thought about trying to
compile gnustep on mac os x, perhaps it is easier to get foo working
there for the first time.  but anyway, i expect most of the problems
regarding the objc-runtime, which is a different one on mac os x.

i have fooelk-0.0.2 together with foo-0.0.3 running.  foo is built
with a configure/gnustep-make mixture.  but i had to disable the
entire control library because of the lowercase issues on load files
with the new elk.  should i wait for news from sam regarding this
issue or should i release the files anyway?  foo kernel level at least
works.

all the best,

martin

[foo-devel] configure for readline-extension

[martin r. <li...@ru...>]

dear sam,

since we want to release the next version of our sound synthesis
system, we will package up a customized version of elk for that
purpose (containing all of our patches).

i added the ./configure support for the readline patch.  ./configure
now looks for BSD libedit, unless the user specifies
--enable-gnu-readline at the command line.  i prepared another
fallback solution if libedit is not found, but it is commented out
yet.  i didn't find the time to adopt libeditline to our needs.  for
the first step, it would be o.k. to disable the completion in that
case.

the new readline-patch is attached.

what about the lowercase filenames while (load )ing something?  is
this intended to have lower case filenames in all cases?  i'm just
wondering if it would be better to rename our scheme-library to
lowercase.  but the implications on case sensivite filesystems wasn't
yet solved, was it?

all the best,

martin


-- 
martinrumori (ma...@ru...)
/* home is where your home directory is */