foo-devel — foo development list

Re: [foo-devel] fooing

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

Dear Martin,

Indeed, it works wunderbarichly. I had indeed to install automake,  
autoconf and libtool as you mentioned in your mail, which I thought I  
had done as first thing just after installing macports.

Certainly it was different because now I  was getting a mesage  
telling that none of these files existed in .../macports/distfiles  
but that it was getting them from .../pub/gnu. I don't recall having  
seen this message before.

After that I have not had any further problems, not even compiling  
readline which seems to work fine.

Indebted for life …………

Ramon

Re: [foo-devel] fooing

[Martin R. <fo...@ru...>]

Dear fooers,

foo should compile on mac os x 10.6 now.  There are some pitfalls though:

for "bootstrapping" the package (compiling from CVS) you would need the
autotools from macports, the ones shipped with the Mac developer tools
do not work for some reasons.

$ sudo port -v install automake autoconf libtool

Gerhard reported some problems with compiling the readline support for
fooelk, which I could not reproduce nor track down.  The short solution
is not to use libreadline but libedit (just omit the
--enable-gnu-readline flag at configure time).  You will loose history
support and filename completion within strings, which is survivable.

You may also checkout the README files in fooelk and foo which I updated
to the recent changes.

So far, cheers,

Martin


On Fri, Apr 30, 2010 at 07:39:27PM +0200, Ramon Gonzalez-Arroyo wrote:
> Dear Martin,
> 
> I was seeing with much pleasure all these foo-cvs messages coming. I  
> want to thank you for your work on it.
> 
> I am not sure if you have finished updating all that you wanted.  
> Anyway, unable to wait longer, I have tried to compile it with the  
> new OSX. Unfortunately, the first problem seems to persist.  In  
> fooelk, bootstrap complaining about autoconf > 2.61
> 
> I wait for a sign to know that I can retry again.
> 
> All the best to you,
> 
> Ramón
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> foo-devel mailing list
> foo...@li...
> https://lists.sourceforge.net/lists/listinfo/foo-devel

Re: [foo-devel] is a statically linked foo the solution?

[Martin R. <fo...@ru...>]

Dear Fooers,

yes, no doubt it would be great to have a standalone version of foo with
all libraries like libsndfile etc. included.

The solution could be mac os x style foo.app which contains everything
needed.  I am working on it, please stay tuned.

All the best,

Martin


On Sat, Apr 10, 2010 at 05:05:52PM +0200, Gerhard Eckel wrote:
> Dear Fooers,
> 
> last time I talked with Ramón, we thought it would be great to have a
> statically linked version of foo, which would install easily. I find
> it quite a pain that every time any component foo is dependent upon
> changes, we run into trouble building it (or even running it - at the
> moment I have a libsndfile with an mismatching architecture for my
> currentlty installed foo). If one masters the build system, then one
> is probably less frightened about this situation, because one can act
> in a situation of urgency. As I am not in this positions, it has
> happened several times in the last years, that I maneuver myself into
> a situation, where I break my installed version by upgrading to newer
> libs I need for other projects and only discover that I broke foo some
> time later, when I typically need it urgently (like now). Then I am
> stuck, as one tool needs the new libraries and the one the old
> ones. For this situation also and for installing foo quickly one
> somebody elses system (typically students' systems), I think a stat
> ically linked version would be very handy. Is this very difficult to
> realize? It would be great if one could specify this at build time.
> 
> Best regards,
> 
> Gerhard
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> foo-devel mailing list
> foo...@li...
> https://lists.sourceforge.net/lists/listinfo/foo-devel

[foo-devel] fooing

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

Dear Martin,

I was seeing with much pleasure all these foo-cvs messages coming. I  
want to thank you for your work on it.

I am not sure if you have finished updating all that you wanted.  
Anyway, unable to wait longer, I have tried to compile it with the  
new OSX. Unfortunately, the first problem seems to persist.  In  
fooelk, bootstrap complaining about autoconf > 2.61

I wait for a sign to know that I can retry again.

All the best to you,

Ramón

[foo-devel] is a statically linked foo the solution?

[Gerhard E. <ec...@ie...>]

Dear Fooers,

last time I talked with Ramón, we thought it would be great to have a statically linked version of foo, which would install easily. I find it quite a pain that every time any component foo is dependent upon changes, we run into trouble building it (or even running it - at the moment I have a libsndfile with an mismatching architecture for my currentlty installed foo). If one masters the build system, then one is probably less frightened about this situation, because one can act in a situation of urgency. As I am not in this positions, it has happened several times in the last years, that I maneuver myself into a situation, where I break my installed version by upgrading to newer libs I need for other projects and only discover that I broke foo some time later, when I typically need it urgently (like now). Then I am stuck, as one tool needs the new libraries and the one the old ones. For this situation also and for installing foo quickly one somebody elses system (typically students' systems), I think a statically linked version would be very handy. Is this very difficult to realize? It would be great if one could specify this at build time.

Best regards,

Gerhard

[foo-devel] problem with autoconf

[Gerhard E. <ec...@ie...>]

Dear Fooers,

here comes the result of my attempt to compile foo on Mac OS X 10.6.2. There seems to be a problem with autoconf. I have 2.65 installed. Any ideas what I can do?

Best regards,

Gerhard

P.S.: The transcript:

pb-eckel:foo> cvs -d:pserver:ano...@fo...:/cvsroot/foo login 
Logging in to :pserver:ano...@fo...:2401/cvsroot/foo
CVS password: 
pb-eckel:foo> cvs -z3 -d:pserver:ano...@fo...:/cvsroot/foo co foo
U foo/AUTHORS
[...]
U foo/libfoo/tests/foosine/foosine.m
pb-eckel:foo> cvs -z3 -d:pserver:ano...@fo...:/cvsroot/foo co fooelk
U fooelk/AUTHORS
[...]
U fooelk/src/vector.c
pb-eckel:foo> cd fooelk
pb-eckel:fooelk> ./bootstrap
+ set -e
+ LANG=C
+ export LANG
+ CYGWIN=binmode
+ export CYGWIN
+ amvers=no
+ automake-1.10 --version
+ amvers=-1.10
+ test -1.10 = no
+ libtoolize=no
+ libtoolize --version
+ glibtoolize --version
+ libtoolize=glibtoolize
+ test glibtoolize = no
+ rm -f aclocal.m4 configure config.guess config.log config.sub config.cache config.h.in config.h compile ltmain.sh libtool ltconfig missing mkinstalldirs depcomp install-sh INSTALL
+ rm -Rf autom4te.cache autotools
+ mkdir autotools
+ glibtoolize --copy --force
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `autotools'.
glibtoolize: copying file `autotools/ltmain.sh'
glibtoolize: You should add the contents of the following files to `aclocal.m4':
glibtoolize:   `/opt/local/share/aclocal/libtool.m4'
glibtoolize:   `/opt/local/share/aclocal/ltoptions.m4'
glibtoolize:   `/opt/local/share/aclocal/ltversion.m4'
glibtoolize:   `/opt/local/share/aclocal/ltsugar.m4'
glibtoolize:   `/opt/local/share/aclocal/lt~obsolete.m4'
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
+ test -f ltmain.sh
+ aclocal-1.10
+ autoconf
aclocal.m4:14: error: this file was generated for autoconf 2.61.
You have another version of autoconf.  If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:14: the top level
autom4te: /opt/local/bin/gm4 failed with exit status: 63
pb-eckel:fooelk>

Re: [foo-devel] memory leak, WAS: Some buggies, examples to show

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

Dear Martin,

Indeed, you're right. Problem seems to have dissapeared. It seems  
that I didn't get or didn't see the message communicating your  
update, so I was unaware you had commited some changes. I have  
updated now and it works.

Great. Thanks!

Ramón

Re: [foo-devel] memory leak, WAS: Some buggies, examples to show

[Martin R. <fo...@ru...>]

Dear Ramon,

just a quick answer to the first question, more to follow:

On Fri, Apr 10, 2009 at 02:37:56AM +0200, Ramon Gonzalez-Arroyo wrote:
> > Did some tests and they look fine -- could you please test for you
> > also?
> >
>   I don't understand what do you mean. I have already done new tests  
> with the just recently downloaded foo and as my report said, I have  
> had problems when snd-region is applied after snd-extract, but not  
> the other way round, which was the case with the previous foo.
> 
> Are you not having problems?

Yes, of course I had, I was just referring to the bugfixes and changes
I did yesterday and checked in.  I think the bug is solved now, I just
asked for a "second opinion".

But for now I wish all fooers nice easter days!

All the best,

Martin

Re: [foo-devel] memory leak, WAS: Some buggies, examples to show

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

Dear Martin,

Thanks for your quick answer.

With respect to snd-region/snd-extract.

> Did some tests and they look fine -- could you please test for you
> also?
>


  I don't understand what do you mean. I have already done new tests  
with the just recently downloaded foo and as my report said, I have  
had problems when snd-region is applied after snd-extract, but not  
the other way round, which was the case with the previous foo.

Are you not having problems?

...

With respect to memory-leak. Let me see if my reasoning is right…

What I am doing is iteratively repeating the evaluation of the same  
patch (actually three different patches Test3a&b (sampling with  
forced gc/no forced gc), Test3c (synthesis with forced gc), Test3d&e  
(very simple synthesis (no sampling) with forced gc/no forced gc)).

My foo has a default-heapsize=65536.

In the cases where gc is forced once per cycle, since the patches are  
quite simple, never more memory is required.

In the case where I do not force gc, it happens only when it is  
needed, which is probably when the heap is filled (* 2 65536)=131072  
and then it remains constant.

As you can see, in the old foo memory was constantly increasing,  
whether or not forcing gc.

This could mean that actually there is no memory leak.

But maybe before being so forward I should do more complex tests. And  
also tests where I do not kill-context every cycle.

Does it make sense my reasoning?

All the best,

Ramon

Re: [foo-devel] memory leak, WAS: Some buggies, examples to show

[Martin R. <fo...@ru...>]

Dear Ramon,

thanks for your message.

On Mon, Apr 06, 2009 at 01:09:35AM +0200, Ramon Gonzalez-Arroyo wrote:
> 2) The problem with snd-region/snd-extract seems to have been reversed 
> from what we had when I did the previous tests. So now: (snd-region 
> (snd-extract ...)) gives errors, while  (snd-extract (snd-region ...)) 
> works fine. You can see both these tests in BoogiesNew.foo attached. They 
> are, on the other hand, the same tests as before.

Had a look at this -- this bug also seems to be a leftover from the
generalisation for making nesting snd-region/snd-extract possible.  I
think before both snd-region and snd-extract only worked on sndfiles.

Did some tests and they look fine -- could you please test for you
also?

> It looks as if the "finaliser question" and the memory leak left over  
> could be related, don't you think so? I will check with more complex  
> examples as a next step, but I think these tests give a clear image.

Yes, maybe it's that.

Still strange the differences between manual (collect) vs. not.
Should not make a difference actually, or maybe an elk bug?  I will
have a closer look.

All the best to all,

Martin

Re: [foo-devel] memory leak, WAS: Some buggies, examples to show

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

Dear Gentlemen,

It was rather fluent to move into macports,  downloading it,  
installing libsndfile, readline & autoconf.

Having a new foo was wonderfully easy, absolutely no problem.  
Actually I installed it in /opt/local so as to keep a previous foo  
around in case of checking needs, as it has been the case now.

1) Offset & Reference now seem to be working perfectly.

2) The problem with snd-region/snd-extract seems to have been  
reversed from what we had when I did the previous tests. So now: (snd- 
region (snd-extract ...)) gives errors, while  (snd-extract (snd- 
region ...)) works fine. You can see both these tests in  
BoogiesNew.foo attached. They are, on the other hand, the same tests  
as before.

3) Memory Leak. I attach a file with my results (theTestsNw.txt),  
both with the previous and the new foo. You are right Martin as far  
as I can see. When forcing regularly a garbagge-collect, memory keeps  
steady, when not forcing gc, memory increases but at a slower rate  
thean before. It was a pain because top and ps have different options/ 
flags on the Mac and Linux, so I had to play around a bit, and  
actually I didn't manage to do a top script. But it doesn't matter,  
ps shows quite well the situation.

I haven't done new/more complex examples as Martin suggests yet, but  
have adapted the old examples I did to proof, on first instance, the  
memory leak question. You are certainly on the right track.

4) About kill-context. I can't remember now when it was suggested to  
do that in a consistent way. Actually, the funtion SP-run (this is  
the function that finally creates, executes contexts, tasks and  
synthesis) has a kill-context as the last thing to do. As far as I  
remember, I agree with what Martin presumes, it was something related  
to things not being properly finalised.

It looks as if the "finaliser question" and the memory leak left over  
could be related, don't you think so? I will check with more complex  
examples as a next step, but I think these tests give a clear image.

This is it, for the time being. If you would need more specific  
tests, please do tell me. O therwise I will re-start the set of tests/ 
examples.

All the best,

Ramon

Re: [foo-devel] memory leak, WAS: Some buggies, examples to show

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

Friends, countrymen:

> I think I yesterday spotted the memory leak culprit.  With Ramon's
> tests, I don't have a growing memory footprint anymore.
>

Would wunderwar be.

Yes, I think you had asked to call kill-context.

But all this I can check better when back to life.

Bests,

ramon

Re: [foo-devel] Some buggies, examples to show

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

Dearest all,

Yes, the reference/offset mess was  clarified some time ago. It was a  
conceptual error that managed to survive for ages.


> On Tue, Apr 10, 2007 at 05:17:20PM +0200, Ramon Gonzalez-Arroyo wrote:
>
>> Boogies.foo shows 2 things :
>>
>> 1) error with snd-extract/snd-region.
>>    Basically (snd-extract (snd-region ..)) gives an error
>>
>
> This one, I think, we solved sometime earlier...

I also thought this was corrected, but it seems to have been reversed :

Try these both

(define (doTest1b)
   (let* ((Outn "~/snd/bug1b")
	 (Inn "~/snd/ex1.aiff")
	 (dur (soundfile-length Inn))
	 (onam))
     (for-each
      (lambda (x)
        (set! onam (make-sndname (format #f "~a.~a" Outn x)))	
        (synt 1 2 onam 'aiff 'short 44100
	     (output~ 1
		(read-snd~
		  (snd-extract (snd-region (open-snd Inn) 1. 2.) 1)))))
      '(1 2))))

;
(define (doTest1a)
   (let* ((Outn "~/snd/bug1a")
	 (Inn "~/snd/ex1.aiff")
	 (dur (soundfile-length Inn))
	 (onam))
     (for-each
      (lambda (x)
        (set! onam (make-sndname (format #f "~a.~a" Outn x)))	
        (synt 1 2 onam 'aiff 'short 44100
	     (output~ 1
		(read-snd~
		  (snd-region (snd-extract (open-snd Inn) 1) 1. 2.)))))
      '(1 2))))
;

ALl the best,

Ramon

Re: [foo-devel] different things

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

  Fooers of the universe,

Please do excuse me for this silence. I hae been very busy and I will  
be very busy until mid next week. Today, being a little island of  
calmness, I profit to thanks Martin a lot for all his good vibes &  
energy.

I will proceed to checks, corrections, docs from mid-next week. The  
first thing I'll do is get the new Foo so that we are all running the  
same, of course. Thus, I need to install macports because I still  
have old fink around me. As far as I understood from your mails, I  
better move out the fink branch, correct?

All the best,

Ramon

Re: [foo-devel] OK to commit? a few cleanings... ooops, i did it...

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

  Foos of the world!

Yes, I agree. Commit, and I will act consequently.

Since you did, don't worry, my yes was on the go.

Ramon

[foo-devel] ooops, i did it...

[Martin R. <fo...@ru...>]

Dear fooers,

sorry for the spam -- I was unintentionally commiting yesterday's
changes to the scheme functions without waiting for ramon's o.k.

While adjusting the configure.ac and READMEs I was misplacing the -l
option of CVS which should have limited the action to the current
directory, but as it was in the wrong place, it commited all elkfoo
changes which were pending in my working copy.  I hope you'll forgive
me...

All the best,

Martin

Re: [foo-devel] foo zkm book

[Martin R. <fo...@ru...>]

Dear Ramon,

On Fri, Mar 13, 2009 at 01:54:09AM +0100, Ramon Gonzalez-Arroyo wrote:
> Does the conf distinguish between OSX 10.5 and 10.4. ? I guess so,  
> but I thought better to ask before svn'ing your last changes.

I just tried: foo compiles and runs fine on both 10.5 and 10.4 using
the latest version of macports.

All the best!

Martin

Re: [foo-devel] OK to commit? a few cleanings...

[Gerhard E. <ec...@ie...>]

Dear Martin,

from my side: go ahead!

Best regards,

Gerhard

On Mar 23, 2009, at 7:54 PM, Martin Rumori wrote:

> Dear fooers,
>
> as we discussed approx. one year ago or so, for consistency I prepared
> the following cleanups:
>
> 1. foo-default-soundfile-format
>
> -> was a variable, is now a function, with setter/getter methods:
>
> (foo-default-soundfile format)
> (set-foo-default-soundfile format!)
>
> and the corresponding "internal" functions:
>
> (foo:default-soundfile format)
> (foo:set-default-soundfile format!)
>
>
> 2. foo-default-soundfile-filetype
>
> -> same as above, plus:
>
> -> I moved these definitions from util/soundfile-funs.foo to
>   kernel/elkfoo.scm in order to have these definitions in one place
>   (was distributed over both files before)
>
> -> as I saw from Ramon's definitions in util/soundfile-funs.foo, the
>   name "foo-default-soundfile-filetype" reads a bit strange, so I
>   changed it to "foo-default-soundfile-type", which is more
>   intuitive.
>
> -> for consistency, this also meant to change "soundfile-filetype" to
>   "soundfile-type" and the kernel function "foo:soundfile-filetype"
>   to "foo:soundfile-type" in elkfoo/src/soundfile.m
>
> -> all this hassle was caused by myself, but for the reason, that
>   there was the distinction between "snd-type" and "snd-filetype",
>   where "snd-type" means the Substrate class of a snd substrate.  But
>   I think the risk of mixing both up is low or it should be fixed
>   here (e.g. "snd-class") instead of using "soundfile-filetype",
>   which is rather ugly....
>
>
> 3. foo-default-play-command
>
> -> same as 1.
>
>
> 4. foo-default-edit-command
>
> -> same as 1.
>
>
> 5. I changed all occurrences of the abovementioned variables/functions
>   which I could find with grep in the scheme code.  I just wanted to
>   know whether you use these functions extensively in your code,
>   which would be broken by these changes, or
>   whether it would be o.k. to commit these changes to CVS.
>
>
> Thanks for a notice, all the best,
>
> Martin
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
> are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly  
> and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
> development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com_______________________________________________
> foo-devel mailing list
> foo...@li...
> https://lists.sourceforge.net/lists/listinfo/foo-devel

[foo-devel] OK to commit? a few cleanings...

[Martin R. <fo...@ru...>]

Dear fooers,

as we discussed approx. one year ago or so, for consistency I prepared
the following cleanups:

1. foo-default-soundfile-format

-> was a variable, is now a function, with setter/getter methods:

(foo-default-soundfile format)
(set-foo-default-soundfile format!)

and the corresponding "internal" functions:

(foo:default-soundfile format)
(foo:set-default-soundfile format!)


2. foo-default-soundfile-filetype

-> same as above, plus:

-> I moved these definitions from util/soundfile-funs.foo to
   kernel/elkfoo.scm in order to have these definitions in one place
   (was distributed over both files before)

-> as I saw from Ramon's definitions in util/soundfile-funs.foo, the
   name "foo-default-soundfile-filetype" reads a bit strange, so I
   changed it to "foo-default-soundfile-type", which is more
   intuitive.

-> for consistency, this also meant to change "soundfile-filetype" to
   "soundfile-type" and the kernel function "foo:soundfile-filetype"
   to "foo:soundfile-type" in elkfoo/src/soundfile.m

-> all this hassle was caused by myself, but for the reason, that
   there was the distinction between "snd-type" and "snd-filetype",
   where "snd-type" means the Substrate class of a snd substrate.  But
   I think the risk of mixing both up is low or it should be fixed
   here (e.g. "snd-class") instead of using "soundfile-filetype",
   which is rather ugly....


3. foo-default-play-command

-> same as 1.


4. foo-default-edit-command

-> same as 1.


5. I changed all occurrences of the abovementioned variables/functions
   which I could find with grep in the scheme code.  I just wanted to
   know whether you use these functions extensively in your code,
   which would be broken by these changes, or
   whether it would be o.k. to commit these changes to CVS.


Thanks for a notice, all the best,

Martin

[foo-devel] memory leak, WAS: Some buggies, examples to show

[Martin R. <fo...@ru...>]

Dear fools again,

I think I yesterday spotted the memory leak culprit.  With Ramon's
tests, I don't have a growing memory footprint anymore.

1. Anyway, this only seems to work when calling (collect) regularly --
if I don't call it, memory grows, even if the garbage collector kicks
in from time to time (garbage-collect-notify? is #t).  Is that normal
for your elky scheme?  Or just a kind of wrong information from top?

2. In Ramon's examples, he uses regularly (kill-context).  I have the
feeling that I asked this before: from the code, it looks whether
there was not a "finaliser" function, which would clean all the
objc-mess bound to a context on elk garbage collection.  Also, a quick
scan of the elk documentation did not enlighten me -- is this the
reason why there is a (kill-context) at all?

Ramon: would be great if you could try whether this solves the memory
problems, maybe also with some more complex examples.

All the best,

m

Re: [foo-devel] foo zkm book

[Martin R. <fo...@ru...>]

Dear fooers again,

thanks for your message, Ramon.

On Fri, Mar 13, 2009 at 01:54:09AM +0100, Ramon Gonzalez-Arroyo wrote:
> The people downloading Foo, get some old version as compared to the  
> ones svn'ing it. We said at some point that that we should have a  
> downloading version update, and for that it would be convenient   
> (i.e. use it as an excuse) to do some general inspection/cleaning and  
> documentation. I think we talked about that when last we met, a year  
> and something ago. Actually, I have started n times parts of this  
> process, so I have here and there, corrections, testers and docs. We  
> are all busy so it is a question that one starts and pushes a bit  
> (with loving care) another one, and so on.

Yes, we should go on with this in order to have at least a 0.1.0
release soonish.

>   I still have my linux around and do use it. One of these days,  
> however, I will go for some ubuntu thing or something of the kind,  
> because by now my system looks like a warrior coming back from the  
> crusades, a bit lame, one eye less, scarfs everywhere, but  upright  
> and proud (somehow).

Good to hear!  Imagine how a window system would look like in this
situation :-)

> I see you are using macports, have you then dropped fink ?

It seems that fink has been discontinued, and the former DarwinPorts
seems to have been replaced by MacPorts.  That's why there does not
seem to be any fink anymore, just MacPorts.

> Does the conf distinguish between OSX 10.5 and 10.4. ? I guess so,  
> but I thought better to ask before svn'ing your last changes.

The foo conf does not especially distinguish between 10.5 and 10.4,
but there were very little changes.  Actually, it *should* work on
both.  I try to check on a 10.4 system.

All the best,

Martin

Re: [foo-devel] Some buggies, examples to show

[Martin R. <fo...@ru...>]

Dear fools,

here a reply to an older mail of Ramon:

On Tue, Apr 10, 2007 at 05:17:20PM +0200, Ramon Gonzalez-Arroyo wrote:
> Boogies.foo shows 2 things :
>
> 1) error with snd-extract/snd-region.
>    Basically (snd-extract (snd-region ..)) gives an error

This one, I think, we solved sometime earlier...
>
> 2) error with offset.
>    Basically offset produces wrong result.

This seems to be solved now, please check.  Actually, the problem was
not with reference/offset, but with FOOBreakpointFunction.  When
calculation was started in the middle of a bpf, foo did nothing for
finding the corresponding segment in order to start correctly.  But as
far as I can see this was never the case, not even in foo-2.1.

I also tried to find a solution for bpf-reverse and bpf-region, but it
is not so easy.  The code so far seems to origin from a version
without an alpha parameter, so I think we should leave it out this
time.

Memleak hunt still ongoing...

All the best,

Martin

Re: [foo-devel] foo zkm book

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

Dear friends,

Thanks for all the mails!

I don't know when is the book coming out, but the person contacting  
me was in great haste. However I am not sure this haste means much;  
probably in order to coordinate well such a thing you better act as  
if the end of time would already be here or you wont have the chance  
to get all answers in time.

The people downloading Foo, get some old version as compared to the  
ones svn'ing it. We said at some point that that we should have a  
downloading version update, and for that it would be convenient   
(i.e. use it as an excuse) to do some general inspection/cleaning and  
documentation. I think we talked about that when last we met, a year  
and something ago. Actually, I have started n times parts of this  
process, so I have here and there, corrections, testers and docs. We  
are all busy so it is a question that one starts and pushes a bit  
(with loving care) another one, and so on.

  I still have my linux around and do use it. One of these days,  
however, I will go for some ubuntu thing or something of the kind,  
because by now my system looks like a warrior coming back from the  
crusades, a bit lame, one eye less, scarfs everywhere, but  upright  
and proud (somehow).

I see you are using macports, have you then dropped fink ?
Does the conf distinguish between OSX 10.5 and 10.4. ? I guess so,  
but I thought better to ask before svn'ing your last changes.

All the best to all of you, and … we keep in contact …

Ramon

Re: [foo-devel] foo zkm book

[Gerhard E. <ec...@ie...>]

Dear Ramon,

what exactely do you mean by "updating it" on sourceforge?

Best regards from Birmingham,

Gerhard

On Mar 10, 2009, at 12:17 PM, Ramon Gonzalez-Arroyo wrote:

> Dear friends,
>
> It has been nice to see you fooing around. I'm glad that it works now
> on Leopard. I still don't have a machine with Leopard, but I was
> thinking in moving into it, though hindered by its fooless life.
>
> Just recently I was contacted by ZKM, because they are preparing a
> publication with presentation of the works done there, something of a
> 20-year -existence event. They sent me some forms to correct, and so
> I did. Foo was well under-informed. I included the dear """new"""
> collaborator, some references and the addresses to find it in. Maybe
> this could be used as an excuse to give the push in order to update
> it in the sourceforge. I know it has to be mainly my job, but it
> cannot be only mine. Encouragement would be welcome.
>
> All the best to both of you. Longing to see you soonish,
>
> Ramon
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> foo-devel mailing list
> foo...@li...
> https://lists.sourceforge.net/lists/listinfo/foo-devel
>

Re: [foo-devel] foo zkm book

[Peter P. <pl...@mu...>]

Dear Ramon,

Ramon Gonzalez-Arroyo wrote:
> Just recently I was contacted by ZKM, because they are preparing a  
> publication with presentation of the works done there, something of a  
> 20-year -existence event.

Great, that's a good thing to do and a nice opportunity to push foo a 
bit. :-)
Did the ZKM people say when they want to release the book?

regards, Peter