foo-devel — foo development list

Re: [foo-devel] next foo release deferred

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

dear foo developpers,

On 17. Feb 2004, at 11:16 PM, martin rumori wrote:

> if you have the time, you could try to build the current elk (3.99.6)
> from http://sam.zoy.org/projects/elk/ on mac os x.  i had no luck in
> the studio, because ./configure died at the very beginning.  i found
> that gcc is called with an illegal option, which happens on other
> software packages, too.  i guess we could blame it on a broken
> installation on the studio computer.
>
> if elk compiles and runs on mac, we know that autotools seem to work
> (though not with objc) and if the elk_init_ magic is working on mac,
> too.  this could give some hints how to go on.

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

Then make and make install ran through without any problem. Works like 
a charm.

Best regards from Krems,

Gerhard

[foo-devel] case sensitivity on file loading

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

dear sam,

i just encountered another problem:

in our program, we used a scm-file tree which contains upper/lowercase
filenames mixed.  i now have problems to load them, because elk now
lowers all the filenames.

in r5rs, i didn't find a clear answer.  it states that case doesn't
matter in scheme for identifiers, but i don't find a statement
regarding filenames.

if case doesn't matter in scheme, then it's perhaps better to make no
distinction there for filenames, but that leads to some
platform-dependent problems.  perhaps we should try to match for
upper/lowercase filenames then, which is quite ineffective...  another
way would be to preserve case for file operations, which is useful for
unix systems.  on the other hand, mixing upper/lowercase names with
the sames letters leads to incompatabilities with case-insensitive
filenames.

what are your thoughts about that?  perhaps we should lower all of our
filenames, but it don't know yet what implications this has regarding
existing code.

thanks, all the best,

martin

[foo-devel] Re: [elk] Re: dynamic library loading

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

On Wed, Feb 18, 2004 at 11:45:38AM +0100, Sam Hocevar wrote:
>    elk only uses the dlname entry of the .la file. You can create a
> dummy libfoo.la file containing only this line:
> 
>     dlname='libfoo.so'

thank you very much.  this issue is solved now.  the problem was an
unresolved symbol in my lib, which i didn't encounter because when
loading the '.so' directly (with the tweaked load.c) elk doesn't
complain about it, even with -v init...  is working fine now.


bests,

martin

[foo-devel] dynamic library loading

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

dear sam,

recently i tried to integrate our cleaned sound synthesis system with
the new elk.  it is written in objective-c and therefore uses gnustep
on linux (mac os x support ist planne=E1=B8=8B).  right now, we use
gnustep-make as the build system, because it's easy to setup and to
maintain and versatile enough for our purposes.

unfortunetaly, gnustep-make doesn't use libtool and thus there are
just .so-libraries created, not libtool-ones (.la).  elk refused to
load them.  after some few changes in src/load.c (introducing the
'.so' as a valid extension for libraries) i was able to load the
library (load 'libfoo.so), but the elk_init_ magic didn't take place.
with elk-3.0 this was no problem.  if i don't use a library but link
our stuff as an application against libelk, the self-parsing for
elk_init_ doesn't work, too.

the files were not stripped.  nm shows (snippet):

0002e970 T elk_init_defaults
0003ceb0 T elk_init_tell
00035400 T elk_init_modules
000365f0 T elk_init_pointer
00037820 T elk_init_signals
000394f0 T elk_init_snd
0003a870 T elk_init_soundfile

though there are different kinds of elk_init:

0002eae0 t _GLOBAL__I_elk_init_defaults
0003aa20 t _GLOBAL__I_elk_init_soundfile
0003cfa0 t _GLOBAL__I_elk_init_tell

i am not sure why this is the case (and why all of the
_GLOBAL__I_elk_init_ things are doubled with elk_init_ while there are
other elk_init_ ones that are not doubled) and i am not an expert for
binary formats etc.

are there known problems regarding this issue?  what about mac os x,
does autotools/libtool work and elk_init_ magic?

i am considering to use autotools for our project rather than
gnustep-make, but i'm a bit unsure whether this really addresses the
problem or if it was a workaround...

bests,

martin

[foo-devel] next foo release deferred

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

dear foo developers,

i spent quite the whole day today to prepare the release of
foo-0.0.3.

i completely restructured the source tree in preparation for the new
internal structure of foo (core/modules) while leaving the actual
structure as is for now.

i started to integrate a build system using gnustep-make, which is
quite sophisticated and easy to handle.

unfortunetaly, it doesn't create libtool compliant libraries
(.la/.a/.so), just normal .so files, but the new elk seems to rely on
the libtool ones.  after some few modifications on elk i am able to
load the libfoo.so file, but the automatic initialization
(elk_init_xxx) doesn't take place, though there is definitely a symbol
table in the library.

for today i'm about to give up.  for the next steps, i am considering
using the normal autotools build system instead of gnustep-make to
have libtool support, but this is quite much work and i don't how this
is handled on mac os x (and how well it integrates with gnustep, but
we could "steal" from the gnustep-gui code, which contains most of the
necessary macros to figure out the particular gnustep installation).
anyway, supercollider for example uses autotools on linux and
projectbuilder on mac, though this leads to sync problems when
maintaining two independent build systems separately.  best thing
would a common system for both mac and linux, and since foo is a
command line tool, i think autotools are acceptable even on mac (when
working).

on the other hand, i think there must be something wrong with elks
initialization code, since it should allow loading of .so files as
well.  i will try to figure out what is happening there.

unfortunetaly i have to do a lot of urgent homeworks towards the end
of the semester, thus i can't proceed right now with foo.  gerhard, if
you want to build it, you may try it with the current versions
released at sourceforge, but there is some handwork to do, for example
the scm-tree has to be copied to /usr/share/foo or whatever by
hand...  and it's not very suited for development since some things
changed in my local copy, but it's still in a mess.

if you have the time, you could try to build the current elk (3.99.6)
from http://sam.zoy.org/projects/elk/ on mac os x.  i had no luck in
the studio, because ./configure died at the very beginning.  i found
that gcc is called with an illegal option, which happens on other
software packages, too.  i guess we could blame it on a broken
installation on the studio computer.

if elk compiles and runs on mac, we know that autotools seem to work
(though not with objc) and if the elk_init_ magic is working on mac,
too.  this could give some hints how to go on.

all the best for now!

martin

[foo-devel] FOO prefix "registered"

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

dear foo-devels,

i released FOO as the prefix for all class names etc. for our project
at

http://wiki.gnustep.org/index.php/PrefixIndex

i am curious what will happen as soon as the gnu people see this
(using FOO as an ordinary name)...

bests,

martin

Re: [foo-devel] ready to go

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

On Mon, Feb 16, 2004 at 03:43:28PM +0100, Gerhard Eckel wrote:
> foo than in the past. As a first thing I would like to install the 
> current version of foo on my laptop unter Redhat 8.0. Martin, could you 
> please advise me what I need to do, what to download from where to 
> actually build a version of foo on my machine?

i am about to release foo-0.0.3, which has support for the new elk
containing all necessary patches (read rationals, new readline
extension).  the elk will be released as fooelk as well, as long as
the new features are not included with the main elk distribution.  i
hope to be able to upload the new files this evening or tomorrow, then
there's really the last version available.

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'll announce the new version as soon as it is available.

all the best,

martin

[foo-devel] ready to go

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

Dear friends of foo,

I am installed in Krems now and ready to more actively contribute to 
foo than in the past. As a first thing I would like to install the 
current version of foo on my laptop unter Redhat 8.0. Martin, could you 
please advise me what I need to do, what to download from where to 
actually build a version of foo on my machine?

Best regards from Krems,

Gerhard

[foo-devel] Re: [elk] Re: elk readline extension

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

On Thu, Feb 12, 2004 at 08:05:53PM +0100, Sam Hocevar wrote:
>    You read minds! :) This was next on my TODO list: I adopted the
> editline (a BSD implementation of readline) Debian package 2 weeks ago
> with exactly this in mind.

ah, great.  yes, i used the debian package, too.  right, at read that
you are the maintainer of libeditline.

>    I don't know yet, I'll think about it. You may have a look at
> editline and see whether it might be used as well (needs a bit of tuning
> though):
> 
> http://http.us.debian.org/debian/pool/main/e/editline/editline_1.12.orig.tar.gz

i did already.  my first attempt was a version for (plain) BSD
libedit.  but i got some strange results, and, apart from that, i
already was familiar with the readline api, so i wanted a working
result first and switched back to readline.

yes, i looked at libeditline, too.  i didn't used it because of the
missing rl_completion_entry_function.  but that was an option, too.
one has to modify the library according to readline's custom
completion function interface.  should not be too complicated.  but i
don't know about its user interface.  that's why i'd rather like to
see at least a possibility for using the original readline: all the
things like history-searching, editing etc., without having to learn
something new.  perhaps a ./configure-switch for (optionally) using
readline instead of BSD libedit or libeditline would the best deal.

all the best,

martin

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

[foo-devel] elk readline extension

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

dear sam,

during the further development of foo, the sound synthesis system made
with elk,  i rewrote the readline extension, which we used.

it's not longer a reader extension, but an independent dynamically
loadable extension.  it provides a (readline-read) function which is
meant as a (read) replacement for terminal input, along with some
convenience stuff like (readline-set-prompt) and
(readline-add-history).  there is also a simple toplevel symbol
completer implemented.

the patch just adds an extension directory lib/readline, adds a
slightly modified toplevel file toplevel-readline.scm which uses
(readline-read) instead of (read) and patches the lib/Makefile.am and
./configure.ac to compile the extension.  it does not yet add anything
to check for libreadline etc.

i am not sure about licensing issues.  libreadline is GPL, elk looks
like a bsd-style license, which seems no to be compatible.  i don't
know, if it is compatible for GPL-compatible projects linked with
elk.  but in any case, it's a problem to include this with elk.   i
had a look at libedit.  my readline extension compiles out of the box
with the readline-wrapper of libedit, which is BSD licensed.

the sourceforge-libeditline doesn't have an entry point of a
user-provided completion function.

what do you think, how should this extension be distributed?  included
with elk?  we could make a ./configure-option for both libreadline or
libedit support, however the user wants it, while mentioning the
license issues.

at least i hope you will like this extension...

all the best!

martin


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

[foo-devel] Re: reading rational numbers patch

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

sorry for replying to myself:

On Thu, Feb 05, 2004 at 08:41:53PM +0100, martin rumori wrote:
> > 4.0 because it might be too big a change, but I will create a 4.99.*
> > development series (which will lead to 5.0) and apply your patch to that

i forgot to mention that the read_rationals patch as well as the P_Pow
exports patch was written by Gerhard Eckel, i am just reviewing and
submitting it, so his name should appear in the AUTHORS file as well.

thanks a lot, all the best

martin

[foo-devel] reading rational numbers patch

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

On Mon, Feb 02, 2004 at 11:43:40AM +0100, Sam Hocevar wrote:
>    Yes, R5RS support is the plan for Elk 5.0. I plan to release 4.0
> (which is only R4RS compliant -- notice how the version numbers
> pleasantly match :D) when it has proved to be stable enough. The only

great.  ahh, i didn't notice that reading of rationals is not part of
R4RS...

> > issues when adding ratnum support (like exact/inexact stuff etc.)
> > that i am overlooking?
> 
>    I don't know. There are certainly issues that won't be noticed right

with the reader extension patch for rational numbers:

> (exact? 8/4)
#t

which seems to be true, since 8 and 4 are exact and / is in this case
an integer operation which produces exact results.  in the patch
Make_Reduced_Flonum() is used.

> 4.0 because it might be too big a change, but I will create a 4.99.*
> development series (which will lead to 5.0) and apply your patch to that

it's just a few lines inside Parse_Number in read.c.  seems to be
quite stable, since it worked for ten years on the original NeXTStep
version of the sound synthesis program...  but if it's not R4RS
conformant, it's possibly better to include it in the 4.99 branch.

all the best,

martin

[foo-devel] Re: [elk] Re: subversion tree, R5RS conformity

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

On Thu, Jan 29, 2004 at 03:13:58PM +0100, Sam Hocevar wrote:
> On Wed, Jan 28, 2004, martin rumori wrote:
> > when checking out, subversion says:
> > 
> > "svn: insn 9212 has non-positive length"
> 
>    I have never seen such an error. Even the great Google shaman doesn't
> know of it :-)  I am using SVN version 0.33.0 (r7737) and it works
> perfectly (I just checked the repository). There might be something

working perfectly for me now, too.  i used just the same version of
subversion again (two days later), and there were no problem.
probably temporary network/server/client/whatever failure.

> > > (exact? (* 0 440.0))
> >  #f
> > 
>    Which "may" be true, as R5RS says :-)  However it was a very trivial
> change to do, so I commited the fix to SVN.

wasn't meant as an urgent "alert" -- just noticed it.  thank you for
fixing this.

in our audio application we used a reader extension for reading
rational numbers (of the form 6/13).  this is necessary for expressing
musical values as they are thought (rather than calculated).  since i
am integrating the sound software with the new elk and we didn't
wanted to use a patched version of elk any longer, i thought we have
to throw out this extension.

we noticed that reading of rational numbers is part of the R5RS, which
is great.  unfortunetaly, there is no support for it in elk.  are
there any plans regarding this issue?  i could integrate our "old"
patch with the new elk and send you a patch, if there is nothing else
planned.  are there more "serious" issues when adding ratnum support
(like exact/inexact stuff etc.) that i am overlooking?

all the best,

martin

Re: [foo-devel] semitone/rational reader extension & other

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

dear delevopers,

thanks for your thoughts, ramon.

is there any special reason for not writing to the foo-devel-list?
o.k., there are just you and gerhard and me on this list (right now),
but these are important questions on the development road to a better
foo, thus they belong to the foo-devel-list.  the lists will be
archived, so they are accessible later, which might get important
later, when more people are using foo and are interested in the
history of the program (after foo has beaten windows :-))

On Wed, Jan 28, 2004 at 03:58:30PM +0100, Ramon Gonzalez-Arroyo wrote:
> Replacing the semitonal notation by a function is certainly not a big 
> deal -of course there are already functions in Foo to deal with this and 

you are absolutely right with your thoughts about musical thinking and
notation.

fortunetaly, i found a possible solution for the semitone extension:
in elk, there is a way to define a custom reader (Define_Reader()),
which is suitable for defining a semitone reader extension.  but the
current syntax has to be changed, since the custom reader extensions
have to start with '#'.  the bistring extension is such a thing
('#*100010'), semitone reader could be '#s6' for example.  if i
understood the scheme r5rs correctly, the sign 's' within a number is
already reserved for giving the precision of a number: '3.4122355s0'
should specify 'short' precision.  since this is not implemented in
elk, it could get used for the semitone thing in the past, but is
dangerous...

> the way one thinks it. And with this in mind you'll agree that 1/5 tells 
>  much more than 0.2 (although in this trivial case it could be less 

there's no question about this.  you are absolutely right.  the
question was just about finding a way to use the "stock" elk
distribution without the need of patching it.  that way, we could
benefit of the further development of elk in an easier way.

since reading of rationals is part of R5RS:

the grammar says:
<ureal R> ---> <uinteger R> | <uinteger R> / <uinteger R> | <decimal R>

i won't hesitate to integrate the old rational reader extension with
the new elk and propose this to sam (the current elk maintainer).  in
the new read.c of elk, there is even a statement:

        /* Lacking ratnums, there's nothing we can do if #e has been
         * specified-- just return the inexact number.
         */
 
thank you for pointing out that reading of rationals belongs to the
scheme standard.  i didn't know that.

> 2) What happens with the Oops patch? Before oops patch, methods could 
> have optional arguments. The oops patch prevents methods from using 
> optional arguments. It doesn't give an error, it simply doesn't work. I 
> sent Gerhard the other day an example of both cases. I think this 
> problem is worth looking at it.

of course.  i simply don't know what it really does.  i just copied
the oops patch from the old NeXT-elk-distribution to the new one.
should be one of the next steps to track this down.

> the Abstraction is quite another question. Therefore I see at least 
> three levels of control sources:
> -The old sources with their optional arguments and whatever (working, by 
> the way, in Martin's first implementation (when removing the oops patch))
> -The strict new implementation of the old sources. Adapted to oops.patch 
> or probably better to new ELK (whatever that may mean : cleaning up of 
> optional arguments, cleaning up of semitonals and rationals, etc.)
> -The new developed sources with the new ideas and changes; new classes, 
> new structure, whatever.

you are right.  i already thought of still working at the initial port
of foo, just to retain compatability.  perhaps we could gain
compatability with the first port using the new elk (but without the
new soundfile stuff).  i'd love to see a foo which is almost
completely conformant to foo-2.1 (besides the 'main', boosted foo
branch).

for the readline extension, i think i found a clean and elegant way to
bring it into elk (as an optional, dynamically loadable extension),
which could probably also integrated with the official elk
distribution.  i'm working at it.  expect some news for the weekend.

all the best,

martin

--
foo sound synthesis
http://foo.sourceforge.net

[foo-devel] Re: subversion tree, R5RS conformity

[Sam H. <sa...@zo...>]

On Wed, Jan 28, 2004, martin rumori wrote:

> i've got some problems with the current elk-trunk subversion tree.  i
> tried to checkout the tree with subversion, but i got an incomplete
> tree: most of the lib/_xxx_ extensions are missing as well as the
> toplevel ./Makefile.am and some of the doc/_xxx_ subdirs.  therefore i
> am not able to build elk from the svn tree.  the ./bootstrap script is
> missing, too.
> 
> when checking out, subversion says:
> 
> "svn: insn 9212 has non-positive length"

   I have never seen such an error. Even the great Google shaman doesn't
know of it :-)  I am using SVN version 0.33.0 (r7737) and it works
perfectly (I just checked the repository). There might be something
wrong with your SVN installation, or maybe packet losses; in this case,
try to cd to your incomplete directory and re-run "svn update".

> while following a discussion on the linux-audio-devel-list regarding
> strong/weak typing etc. i noticed a R5RS inconformity of elk:
> 
> > (exact? (* 0 440.0))
>  #f
> 
> which should be true:

   Which "may" be true, as R5RS says :-)  However it was a very trivial
change to do, so I commited the fix to SVN.

Regards,
-- 
Sam.

Re: [foo-devel] semitone/rational reader extensin & other

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

Dear Sirs,

Some issues.

1) I don't think I have used the semitonal or the fractional readline 
possibility in the Foo sources. (I would have to check, but it is 
improbable). However, I have used them intensily in all my "music 
sources". Rationals should have been part of elk, since it is in the 
scheme report. Perhaps we could press the elk peaople, so.

Replacing the semitonal notation by a function is certainly not a big 
deal -of course there are already functions in Foo to deal with this and 
more refined related questions [Pitch.foo in ~/Control/Utilities]. Even 
more easy to change 1/3 by 0.3333.

The problem of course is that a function does not solve the problem of 
notation. One of our main concerns when doing Foo (and elsewhare) is 
that the way one expresses something should be as close as possible to 
the way one thinks it. And with this in mind you'll agree that 1/5 tells 
  much more than 0.2 (although in this trivial case it could be less 
dramatic). A proportion is a most important way of supplying data. In 
music as in many other arts proportions are paramount, and these 
elements of a description should stand clearly in the way one is 
formulating a(n artistic) statement.

As you probably see I have less of a problem with loosing the semitonal 
notation (since it is anyway a particular case (though of course not any 
particular one)), than with loosing rationals. That would be an extreme 
pity and I would love to have some more thinking about it, {and if you 
allow me some more pushing} before just wiping it out from our lives.

2) What happens with the Oops patch? Before oops patch, methods could 
have optional arguments. The oops patch prevents methods from using 
optional arguments. It doesn't give an error, it simply doesn't work. I 
sent Gerhard the other day an example of both cases. I think this 
problem is worth looking at it.

If I ask this is because both the Node as the Abstraction classes use 
optional arguments in their methods. I have cleaned the Node from 
optional arguments, although the documentation has to be changed. But 
the Abstraction is quite another question. Therefore I see at least 
three levels of control sources:
-The old sources with their optional arguments and whatever (working, by 
the way, in Martin's first implementation (when removing the oops patch))
-The strict new implementation of the old sources. Adapted to oops.patch 
or probably better to new ELK (whatever that may mean : cleaning up of 
optional arguments, cleaning up of semitonals and rationals, etc.)
-The new developed sources with the new ideas and changes; new classes, 
new structure, whatever.

I think it would be very interesting to have at the developers site 
these three levels very clear. I think with the kernel we have a very 
similar situation. And of course with the Documentation.

Well, that was it for now. All the best,

Ramon

[foo-devel] subversion tree, R5RS conformity

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

hi sam,

thank you for integrating the P_Pow patch that quickly with elk...

i've got some problems with the current elk-trunk subversion tree.  i
tried to checkout the tree with subversion, but i got an incomplete
tree: most of the lib/_xxx_ extensions are missing as well as the
toplevel ./Makefile.am and some of the doc/_xxx_ subdirs.  therefore i
am not able to build elk from the svn tree.  the ./bootstrap script is
missing, too.

when checking out, subversion says:

"svn: insn 9212 has non-positive length"

before finishing.  is this a serious error?  i'm not (yet) too
familiar with svn...  or is the elk-trunk tree really incomplete?

------

while following a discussion on the linux-audio-devel-list regarding
strong/weak typing etc. i noticed a R5RS inconformity of elk:

> (exact? (* 0 440.0))
 #f

which should be true:

Rohan Drape posted:
> Actually, R5RS says:
>
>  An operation may, however, return an exact result if it can prove
>  that the value of the result is unaffected by the inexactness of
>  its arguments. For example, multiplication of any number by an
>  exact zero may produce an exact zero result, even if the other
>  argument is inexact.

not that important, just for the record...

all the best,

martin

[foo-devel] read rationals + sourceforge

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

hi again,

1. i forgot to mention that the things i wrote about the "read semitones"
foo-elk-reader-extension applies to the "read rationals"-extension,
too, of course.

2. yesterday i uploaded the fooelk, foo and old foo-2.1 files to
sourceforge.  unfortunetaly, they can't be downloaded and the size of
all the files is "0".  i tried uploading the stuff again.  no
success.  i will file a support request at sourceforge on this issue.

3. added links to ircam and zkm in the copyright line at the website.

bests,

martin

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

[foo-devel] semitone reader extension

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

good evening again,

as stated earlier, the future versions of foo should get rid of the
special version of elk.

some obvious changes (exporting of the pow function) i mailed to the
new maintainer of elk, they were applied to the official elk release.

for the libreadline support, i'll either discuss with the elk
maintainer, too (perhaps it's possible to get readline support into
the official elk release), or we'll use a custom "front-reader"
solution like avango does.

one thing remains: the semitone extension ("12s").  this extension was
made deeply inside the elk reader and it's therefore not possible to
replace it with a "front-reader", since that affects the reader
mechanism in general (the readline-capable "front-reader" ist just for
keyboard input, while the semitone-extension must also be present when
reading a file e.g.).  otherwise, the reader extension is no scheme
standard, thus there will be no chance to get such an extension into
the official elk distribution.

i considered this issue with gerhard during his berlin trip.  the
cleanest solution would be:

using the standard reader, in other words: remove the semitone
extension from the reader, and replace it by a function (similar to
pitch->freq).

ramon: how often did you use the reader extension?  would it be very
complicated to replace all occurences of the semitone syntax by a
function (semi->ratio or whatever)?  since it's a simple text
processing, this task could be done by a sed-someliner, i think...

all the best,

martin

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

[foo-devel] foo website up

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

good evening,

this afternoon i set up a simple raw cooked website for foo, just to
make the sourceforge appearance more friendly...

http://foo.sf.net
http://foo.sourceforge.net (which is identical)

on the project summary site (http://sf.net/projects/foo) i uploaded
the source files as they are.  there is the original foo-2.1 + docs
tarball, plus the fooelk-0.0.1 and the foo-0.0.1 and foo-0.0.2
archives (current versions).

the next version (0.0.3) will not longer depend on a special version
of elk.

bests,

martin

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

[foo-devel] I am here

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

Hello everybody,

I am now also subscribed to the three foo lists.

Best regards,

Gerhard

[foo-devel] Re: [sam@zoy.org: [elk] Re: patch again as text]

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

great elk news!

one question concerning the foo-lists: i tried subscribing as 
gu...@us.... i understood that email to this address is 
forwarded to the addres with which i subscribed at sf.net. do i have to 
subscribe to the foo-lists with another (my normal) email address?

best regards,

gerhard

On 19. Jan 2004, at 8:34 PM, martin rumori wrote:

> CC:ing as long as you are not on the foo-devel mailing list...
>
> the P_Pow patch is now in the official elk distribution.  for us,
> there remains the problem with the customized reader.  i have not yet
> an idea of how to do this.  will have a look at the avango sources for
> that.
>
> bests,
>
> martin

[foo-devel] [sam@zoy.org: [elk] Re: patch again as text]

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

CC:ing as long as you are not on the foo-devel mailing list...

the P_Pow patch is now in the official elk distribution.  for us,
there remains the problem with the customized reader.  i have not yet
an idea of how to do this.  will have a look at the avango sources for
that.

bests,

martin

[foo-devel] test mail

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

this is an initial test mail to foo-devel.