Menu
▾
▴
foo-devel — foo development list
You can subscribe to this list here.
| 2004 |
Jan
(11) |
Feb
(38) |
Mar
(39) |
Apr
(12) |
May
(11) |
Jun
(5) |
Jul
(16) |
Aug
(84) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(24) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(8) |
Dec
(1) |
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(22) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: martin r. <fo...@ru...> - 2004-03-16 11:05:05
|
dear developers, http://on1.zkm.de/zkm/stories/storyReader$3857 the foo talk will be held at friday, april 30, at zkm. unfortunetaly, there are 2 sessions in parallel at this time, so we have to concur against frank barknecht presenting pd... that's a pity, since i am interested in franks talk, too... but that's life. perhaps this way it's assured that only the hard guys will listen to the talk, since all being eager for a gui won't join us... bests, martin -- martinrumori (ma...@ru...) /* home is where your home directory is */ |
|
From: martin r. <fo...@ru...> - 2004-03-12 18:29:06
|
dear developers again, there seems to be a bug in foo regarding soundfiles at least in foo-0.0.3 (might be thing which ramon discovered): at least when creating 'aiff-files (the default), there no correct header is written. sndfile-play can play the file though, but with alsaplayer: silencium. sndfile-info reports a number of '0' frames in the file. there is the possibility to tell libsndfile to update the header in the soundfile after every write (not just when closing the file). i enabled that, but afterwards there are FOO_ERRORs when seeking (looks like a negative seek). perhaps that's the reason for the incorrect header, but i am still wondering why this isn't reported as an error without SFC_SET_UPDATE_HEADER_AUTO. when switching to 'wav format, however, the headers seem to be o.k. (but the seek error still exists when running with HEADER_AUTO). unfortunetaly, i don't have the time to track that down now (next exam on tuesday...), but it's scheduled... bests, martin |
|
From: martin r. <fo...@ru...> - 2004-03-12 16:16:25
|
dear gerhard, do you have some more information about that nasty GC-bug or some hints? perhaps we should ask juergen for that, too... bests, martin |
|
From: martin r. <li...@ru...> - 2004-03-12 16:10:11
|
On Fri, Mar 12, 2004 at 02:29:09PM +0100, Sam Hocevar wrote: > Do you have more information on this bug? I fixed at least five > critical GC bugs since I took over Elk, maybe it was one of them. unfortunetaly, i was not too deeply involved with elk but more with the c++ side... i know, that (apparently) the same bug already occured in the sound synthesis program many years ago (the first version is from 1993) on a NeXTStep system. the 3-d-system has a completely different architecture and runs on SGI/Irix and Linux, the bug seems to be the same. i will ask gerhard eckel, which started the sound synthesis project and was deeply involved with the 3-d-system, too, for some more information. bests, martin |
|
From: martin r. <li...@ru...> - 2004-03-12 13:33:35
|
On Fri, Mar 12, 2004 at 02:09:00PM +0100, Sam Hocevar wrote:
> > Panic: Visit: object not in prev space at 0x401dcf44 ('pair') 3 277 (dumping core).
>
> Okay, I can confirm that bug. I thought I'd never have to look at the
> GC again, but it looks as if I was wrong :-)
j'suis vraiment désolé...
in the institute where i used to work and where elk is used in a
realtime 3-d-graphics system i knew of some hackers looking for a bug
like that for a long time (in elk-3.0)... they gave up one day...
i hope there will be solution. honestly, for me the garbage collector
code is far beyond my limits... i admire those who can deal with it.
thank you for putting so much efforts into elk.
all the best,
martin
|
|
From: martin r. <fo...@ru...> - 2004-03-12 13:27:06
|
looks like there are coming better days... |
|
From: martin r. <fo...@ru...> - 2004-03-12 13:24:28
|
dear developers,
here comes another mailbomb: since december 3rd i have a mail from
gerhard with the remarks to my foo roadmap file. for the record,
i want to mention some topics again to not forget them:
DYNAMICALLY LOADED MODULES
--------------------------
this will be one of the next issues when making the Interface mac os
x-conform. i thought about that several times. there are several
ways:
* the simple elk-way: provide a .scm file along with each external and
do a (load 'external.la) in it. this is useful especially when
providing some supporting scheme functions together with the external.
* the OpenStep automagic: load classes ('bundles') dynamically on
demand. we just need a way to know the names of the classes in
question. this could be done by a translation scheme, like:
(foo-require 'foo:convolve-signals) -> FOOConvolveSignals
- load FOOConvolveSignals
- generate Define_Primitive call (foo:make-convolve-signals)
- (define convolve-signals~) dynamically
AFAIK this is a common way on many systems. after loading we have to
dynamically issue a Define_Primitive call adopted to the signature of
the module constructor. i think that's possible.
this has the great opportunity of being independent from elk regarding
the loading mechanism. the last hassle with elk has shown that we
should try to keep the foo kernel as independent as possible from a
specific interface language/implementation to be more flexible.
SOUNDFILE ACCESS
----------------
still to try: what difference in performance we can expect if
reading/writing soundfiles in another thread in much larger chunks
than the rendering block size?
CONTEXT - OUTPUT - TASK
-----------------------
forget the crazy things i proposed regarding different samplerates
when both realtime playing and rendering to a file at the same time:
there might be some situations in which this could be useful, but for
now it just appears bloated and takes some of the charm of simplicity
away (for what foo got famous once).
but i am still thinking of the part when foo is getting its "feet down
to earth" == when outputting the stuff to whatever media.
i already talked with gerhard about that. we saw that enhancing the
semantics of context could get rather complex...
for now, i'd just like to see the semantics of context, output~ and
task represented in the actual code:
* output~ is just an "output", just the connection to the outer side
of a context, where the task could touch the thing and pull out the
sound. thus nothing soundfile-related should be necessary in an
output.
* CONTEXT should be a structuring entity, archiving entity, whatever,
a representation of a piece of sound (like stated in FOO-Concepts) and
independent of a specific medium.
* TASK actually should do the rendering work (not output~ nor
context). a task could support different output media (whether
modularized or builtin to task): soundfile, alsa-play, jack-play,
whatever. this, of course, will obsolete play~ (which is still not
ported...), but looks cleaner to me. here comes the question with
outputting to more than one media at the same time, but that's not for
now. assuming that the patch could be rendered in realtime, this was
already possible as soon as we had jack-support (the lowlatency linux
audio server).
CONTEXT LOCKING/COMPILING
-------------------------
i thought about the context compiling/locking mechanism. what about
combining these two? instead of doing
(make-task x x "" context)
we could have something like:
(define atask (make-soundfile-task "filename"))
(run-task atask ref off context)
the context gets locked and compiled just for the rendering process.
after that, it is reset and released by the task. or is there any
special reason why a context has to be locked longer than for
rendering?
o.k., thanks for reading...
martin
|
|
From: martin r. <fo...@ru...> - 2004-03-12 11:50:36
|
dear devels, to make life easier when having problems with the readline extension, i added another toplevel file to the fhg listen/foo/foo repository. unfortunetaly, you can't load it just by foo -l toplevel-no-rl.foo since elk doesn't know the loadpath of foo before the toplevel file is loaded. therefore i changed the 'foo' binary. now there is an option foo --no-rl which will cause the toplevel-no-rl.foo to be loaded. the readline extension then is not necessary to run foo (but readline support is disabled, too, of course :-() bests, martin |
|
From: martin r. <fo...@ru...> - 2004-03-12 08:27:42
|
dear foo developers, i have to apologize for the mess i am causing to the listen/foo cvs repository... but i think it's the only way for now, since we have different codebases by now which should still remain independent. i added a new directory 'ng' for "next generation" (which has nothing to do with "NeXT generation", n.b.). i hope this could get the candidate for the initial checkin for the sourceforge cvs and the mac os x version of foo. until now, i already reviewed the Core code (Modules and Interface still to come...) i expect the most work for the interface since that is the sensible thing regarding the Objective-C runtime. another issue still not solved for the new version is serialization. COSMETIC CHANGES: ----------------- * prepend our "officially registered" prefix FOO to each file and each class * prepend an LGPL header to each file * review coding style for better readability i oriented at the coding style for GNUstep itself: * more spaces in objc code, declarations: - (FOOBuffer *) initWithSize: (unsigned int)samples; calls: [self fillCacheFromFrame: fromFrame frames: frames]; (in short terms, a space after each colon) SUBSTANTIAL CHANGES ------------------- * derive FOOObject from NSObject (instead of Object). this had many, many implications all over the code, regarding memory management stuff etc. * use static typing whereever possible (e. g. FOOBuffer * instead of id). this leads to some oddities and warnings while compiling. i am not quite sure about how ot proceed. Objective-C also knows so called "protocols", something like interface definitions. perhaps using them would be a smart solution. * use NSString instead of char * for filenames etc. NOT YET SOLVED -------------- * serialization (has to be done the OpenStep way now) bests, martin |
|
From: martin r. <fo...@ru...> - 2004-03-11 17:39:36
|
On Thu, Mar 11, 2004 at 02:10:57PM +0100, Gerhard Eckel wrote: > the problems seems to be that the -lreadline check faisl in the fooelk > configure. I couldn't figure it out though. > > checking for readline in -lreadline... no aha. i tried to build fooelk on a machine at the university -- same problem (though it's suse). one can set the LDFLAGS and CPPFLAGS before running configure (or with 'env'), but that didn't help. strange. for now, i don't know what to do. looks like something autotools related, or whatever. but you could do something dirty in configure.ac: configure.ac, lines 105-111, change them to: else AC_CHECK_HEADERS(readline/readline.h readline/history.h) # AC_CHECK_LIB(readline, readline, # [ac_cv_my_have_readline=yes # RL_LIBS="-lreadline"], # [ac_cv_my_have_readline=no]) ac_cv_my_have_readline=yes RL_LIBS="-lreadline" fi after that, you have to ./bootstrap again. this disables the library check and makes configure believe that the library was found. i tried that and the readline extension was compiled and linked successfully, apparently. but not a real solution... good luck again! martin |
|
From: Gerhard E. <ger...@im...> - 2004-03-11 17:30:38
|
Dear Martin,
the problems seems to be that the -lreadline check faisl in the fooelk
configure. I couldn't figure it out though.
checking for readline in -lreadline... no
The libraries are there:
% locate libreadline | grep /usr/lib
/usr/lib/libreadline.so.4
/usr/lib/libreadline.so.4.3
/usr/lib/libreadline.a
/usr/lib/libreadline.so
/usr/lib/libreadline.so.4.1
%
But the load-path in fooelk is fine:
("." "/usr/local/share/fooelk" "/usr/local/lib/fooelk")
But the files you expect are missing:
% ls /usr/local/lib/fooelk
bitstring.a elk-eval.la* hack.so* record.a struct.la*
xaw.so*
bitstring.la* elk-eval.so* motif.a record.la* struct.so*
xlib.a
bitstring.so* gdbm.a motif.la* record.so* unix.a
xlib.la*
debug.a gdbm.la* motif.so* regexp.a unix.la*
xlib.so*
debug.la* gdbm.so* newhandler.a regexp.la* unix.so*
debug.so* hack.a newhandler.la* regexp.so* xaw.a
elk-eval.a hack.la* newhandler.so* struct.a xaw.la*
%
My redhat version is 8.0
Best regards,
Gerhard
On Mar 11, 2004, at 11:58 AM, martin rumori wrote:
> On Wed, Mar 10, 2004 at 10:38:18PM +0100, Gerhard Eckel wrote:
>>> 1. for a first try, comment the (require 'readline.la') in
>>> /usr/local/share/foo/toplevel.foo to see if everything else works.
>>
>> didn't work since the readline-set-prompt isn't defined
>
> yes, sorry. short-thought. the toplevel-file of foo doesn't print
> the prompt itself (like elk), since that leads to some strange
> behaviour of readline (readline has to know ho many chars are at the
> beginning of a line as a prompt). there is also (readline-read) which
> replaces (read). that reminds me of the fact that i wanted to make
> the use of readline optionally in the toplevel-file.
>
>>> ./configure --enable-gnu-readline
>>
>> I did configure it like that and the ./configure output reads like you
>> expect
>>
>>> checking readline/readline.h usability... yes
>>> checking readline/readline.h presence... yes
>>> checking for readline/readline.h... yes
>
> what about:
>
> checking for readline in -lreadline... yes
>
> some lines below, perhaps the headers are in place, but the lib itself
> is not found?
>
>> % fooelk
>>> (require 'readline.la)
>> require: file "readline.la" not found
>
> getting really strange...
>
> what is your load-path in fooelk set to? should be something like
>
>> load-path
> ("." "/usr/local/share/fooelk" "/usr/local/lib/fooelk")
>
> you could then examine the contents of /usr/local/lib/fooelk, should
> contain
>
> readline.a readline.la readline.so
>
> besides all the other extensions.
>
> who knows, perhaps the readline extension isn't actually built on your
> system, for whatever reason... guess i have to install redhat on my
> machine...
>
> by the way, you may add a
>
> /usr/local/lib
>
> to your /etc/ld.so.conf (followed by a call of 'ldconfig' as root
> after that), then you won't have to modify LD_LIBRARY_PATH... but
> this should not have to do something with the above problem.
>
> what is your redhat version? some time ago, there were some redhat
> systems in the university, perhaps i could try to build fooelk
> there...
>
> bests,
>
> martin
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> foo-devel mailing list
> foo...@li...
> https://lists.sourceforge.net/lists/listinfo/foo-devel
>
|
|
From: martin r. <ma...@ru...> - 2004-03-11 12:37:35
|
hi meikel, On Tue, Mar 09, 2004 at 11:25:27PM +0100, Meikel Brandmeyer wrote: > > > Huu... I don't know about Sam Hocevar. I once talked with Oliver Naumann, > > he's is the somehow current official maintainer of elk and debian > > packages of elk are in the unstable distribution. > Hmm... > > > http://sam.zoy.org/projects/elk/ > I also can't access the site. i wrote to sam about these problems. but i don't know whether he can do very much about it... looks like a strange routing problem somewhere near below top-level... > looked for the original source of the garbage collector and rewrote it > myself. Now, I understand (more or less) what's happening there and my > conclusion was to use the boehm collector :]. But to understand the dump perhaps the garbage collector is the most sensible thing in elk... we have had problems with it for several years across different platforms (NeXT, SGI, Linux) ("PANIC! object not in prev space"), which seem not to be solved until now. the elk-distribution by sam now even compiles on mac os x... > Bundling the efforts would be appreciated. :) Especially feedback on the all your plans sound nice. i am much more a user of elk (it's used in a sound synthesis framework) than a developer. i just noticed your website and guessed that you didn't know of other efforts going on regarding elk. i hope sam's site will be accessible soon. perhaps you'll want to contact him. there is a mailing list for the elk project (informations about it on his site). i've got the impression that him and me are the only two members right now... all the best, martin -- martinrumori (ma...@ru...) /* home is where your home directory is */ |
|
From: martin r. <li...@ru...> - 2004-03-11 11:18:35
|
On Thu, Mar 11, 2004 at 11:11:14AM +0100, Sam Hocevar wrote: > On Wed, Feb 18, 2004, martin rumori wrote: > > filenames mixed. i now have problems to load them, because elk now > > lowers all the filenames. > The default behaviour changed for symbols (they are now case > insensitive, hence always converted to lowercase) but not for > filenames. Are you using symbol arguments or string arguments? thanks, yes, i finally noticed the change of the default behaviour... we used mostly symbol arguments for file loading, that might be the problem... for now, i simply switched back to case sensitive behaviour. but now we are aware of that problem. bests, martin |
|
From: martin r. <li...@ru...> - 2004-03-11 11:15:59
|
On Thu, Mar 11, 2004 at 11:26:42AM +0100, Sam Hocevar wrote: > On Sat, Feb 21, 2004, martin rumori wrote: > > > i added the ./configure support for the readline patch. ./configure > > now looks for BSD libedit, unless the user specifies > > Okay, your code looks fine. I'll just adapt the coding style before > commiting it. thank you, that's great. i'll have a look at the style after that, then i will make it correctly the next time :-) i heard about some problems on redhat regarding the readline extension. don't know yet if it's a compile-time-problem or something regarding the load-path on that system... perhaps a line in your configure-summary would be fine to be informed whether the readline extension will be build with which library. thanks, martin |
|
From: martin r. <fo...@ru...> - 2004-03-11 11:09:36
|
On Wed, Mar 10, 2004 at 10:38:18PM +0100, Gerhard Eckel wrote:
> >1. for a first try, comment the (require 'readline.la') in
> >/usr/local/share/foo/toplevel.foo to see if everything else works.
>
> didn't work since the readline-set-prompt isn't defined
yes, sorry. short-thought. the toplevel-file of foo doesn't print
the prompt itself (like elk), since that leads to some strange
behaviour of readline (readline has to know ho many chars are at the
beginning of a line as a prompt). there is also (readline-read) which
replaces (read). that reminds me of the fact that i wanted to make
the use of readline optionally in the toplevel-file.
> >./configure --enable-gnu-readline
>
> I did configure it like that and the ./configure output reads like you
> expect
>
> >checking readline/readline.h usability... yes
> >checking readline/readline.h presence... yes
> >checking for readline/readline.h... yes
what about:
checking for readline in -lreadline... yes
some lines below, perhaps the headers are in place, but the lib itself
is not found?
> % fooelk
> > (require 'readline.la)
> require: file "readline.la" not found
getting really strange...
what is your load-path in fooelk set to? should be something like
> load-path
("." "/usr/local/share/fooelk" "/usr/local/lib/fooelk")
you could then examine the contents of /usr/local/lib/fooelk, should
contain
readline.a readline.la readline.so
besides all the other extensions.
who knows, perhaps the readline extension isn't actually built on your
system, for whatever reason... guess i have to install redhat on my
machine...
by the way, you may add a
/usr/local/lib
to your /etc/ld.so.conf (followed by a call of 'ldconfig' as root
after that), then you won't have to modify LD_LIBRARY_PATH... but
this should not have to do something with the above problem.
what is your redhat version? some time ago, there were some redhat
systems in the university, perhaps i could try to build fooelk
there...
bests,
martin
|
|
From: Gerhard E. <ger...@im...> - 2004-03-10 21:49:52
|
Hello Martin, On Mar 9, 2004, at 5:48 PM, martin rumori wrote: > two solutions: > > 1. for a first try, comment the (require 'readline.la') in > /usr/local/share/foo/toplevel.foo to see if everything else works. didn't work since the readline-set-prompt isn't defined > 2. readline.la depends on libreadline, but doesn't come with it. > readline.la is the readline extension of fooelk (my readline patch). > > i guess you forgot to run the ./configure when building fooelk with > the option: > > ./configure --enable-gnu-readline I did configure it like that and the ./configure output reads like you expect > checking readline/readline.h usability... yes > checking readline/readline.h presence... yes > checking for readline/readline.h... yes But when I try to load readline.la, I get this: % fooelk > (require 'readline.la) require: file "readline.la" not found 1> hmm... I am stuck here... Best regards, Gerhard |
|
From: martin r. <fo...@ru...> - 2004-03-09 16:57:27
|
On Tue, Mar 09, 2004 at 05:13:25PM +0100, Gerhard Eckel wrote: > I am getting closer and closer. It builds now, but when I try to run > it, I get: good to know. > % foo > foo sound synthesis version 0.0.3 > (C) 1993-2004 gerhard eckel, ramon gonzalez-arroyo, zkm, ircam > (C) 2003-2004 martin rumori > require: file "readline.la" not found > % > > But readline is installed! two solutions: 1. for a first try, comment the (require 'readline.la') in /usr/local/share/foo/toplevel.foo to see if everything else works. 2. readline.la depends on libreadline, but doesn't come with it. readline.la is the readline extension of fooelk (my readline patch). i guess you forgot to run the ./configure when building fooelk with the option: ./configure --enable-gnu-readline if this option is not present, fooelk looks for BSD libedit (license compliant with elk), which might not present on your system. anyway, you could watch the ./configure output when it's testing for readline. should look like this (somewhere in between): checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking for readline in -lreadline... yes if started without --enable-gnu-readline: checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/history.h usability... no checking editline/history.h presence... no checking for editline/history.h... no checking for readline in -ledit... no there is no warning about that, since it's still a testing patch and not really necessary to run fooelk... bests, martin |
|
From: martin r. <fo...@ru...> - 2004-03-09 16:46:05
|
dear sirs, On Sun, Mar 07, 2004 at 11:53:27AM +0100, ar...@ma... wrote: > Doesn't look very appealing this "other" elk-page. What happens with > Sam? Is he still not responding? sam just seems to busy... nothing serious, i guess. responded to me, but still nothing about the garbage collector... > Another question: what is your feeling about the alsa sound > drivers. This should be the real standard for Linux now, isn't it? yes, using the old oss driver is deprecated in the new (2.6) linux kernel. it's by far not that flexible and supports much less soundcards. > Martin, told me that libsndfile does not work with the alsa > drivers. That could be an inconvenient, but probably there is some > other solution. CCRMA uses exclusively alsa, and they probably have > to deal with several soundfile formats. yes, that's correct, but i think there is a misunderstanding: libsndfile has nothing to do with playing soundfiles, so libsndfile itself doesn't rely on any sound driver. it's just sndfile-play coming with libsndfile. it's more meant as a programming example how to use libsndfile. the actual playing is done via oss in this program, but nobody is prevented from writing a player using libsndfile which uses the alsa-interface. alsaplayer is such a program. if you have installed it on your system, simply replace 'sndfile-play' by 'alsaplayer -i text' or even 'alsaplayer -q -i text' (quiet). this enables alsaplayer using the text interface. if you are running x11, it's also possible to call just 'alsaplayer', which will open a graphical interface... regarding the MixSnd problems, it would be nice to have an example. perhaps we could generate some sinewave-files and try to merge them to see if that works? > How were your exams, Martin? Went well I hope. yes, until now, well. there is still one outstanding for coming tuesday... all the best, greetings to paris! martin |
|
From: Gerhard E. <ger...@im...> - 2004-03-09 16:25:04
|
Dear Martin,
I am getting closer and closer. It builds now, but when I try to run
it, I get:
% foo
foo sound synthesis version 0.0.3
(C) 1993-2004 gerhard eckel, ramon gonzalez-arroyo, zkm, ircam
(C) 2003-2004 martin rumori
require: file "readline.la" not found
%
But readline is installed!
(I also had to add to /usr/local/lib for elk to LD_LIBRARY_PATH)
Best regards,
Gerhard
On Mar 9, 2004, at 4:03 PM, martin rumori wrote:
> dear gerhard,
>
> On Tue, Mar 09, 2004 at 03:37:27PM +0100, Gerhard Eckel wrote:
>> /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../crt1.o: In function
>> `_start':
>> /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../crt1.o(.text+0x18):
>> undefined reference to `main'
>
> o.k., i nearly "expected" that. GSConfig.h now defines the fakeroot
> function, but since the binary "foo" (which is built in Source/Main)
> is just linked against elk this gnustep-stuff isn't known there.
>
> i changed the GNUmakefile in the cvs tree to reflect this ("foo" is
> now linked against gnustep-base). hope this solves the problem.
>
> bests,
>
> martin
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> foo-devel mailing list
> foo...@li...
> https://lists.sourceforge.net/lists/listinfo/foo-devel
>
|
|
From: martin r. <fo...@ru...> - 2004-03-09 16:18:40
|
dear ramon, On Mon, Mar 01, 2004 at 02:06:43AM +0100, Ramon Gonzalez-Arroyo wrote: > 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 hmm. i don't know exactly, but if i remember correctly, i had to compile the libffcall separately, then compiling gnustep worked on gcc-2.9x. but anyway, perhaps no fun... from gerhards report it looks like libffcall was necessary with gcc-3.x, too. > 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. you are a "scheme" developer and therefore that's no sin :-) perhaps sourceforge should provide a hardware lisp machine running foo... :-) > 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 i thought about that, and i think it's worth to keep a way for compatability with foo-2.1 as much as possible. i checked in a next-compat.foo in the listen's foo repository. if i got everything correctly it should be possible to retain compatability on the scheme level. comments and regions, however, are even not supported on fooL-0.0.1... i just changed the signatures for create-soundfile and make-soundfile. the default filetype went back to 'snd, which is changeable in next-compat.foo. there is an old (synt) macro with the right number of arguments. in any case, the default filetype is used. do you thing that's a way to retain compatability? would be nice, since this way you could benefit from the advantages of the new foo versions (by know just more bugs...) while being able to "process your former life"... bests, martin |
|
From: martin r. <fo...@ru...> - 2004-03-09 15:13:04
|
dear gerhard,
On Tue, Mar 09, 2004 at 03:37:27PM +0100, Gerhard Eckel wrote:
> /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../crt1.o: In function
> `_start':
> /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../crt1.o(.text+0x18):
> undefined reference to `main'
o.k., i nearly "expected" that. GSConfig.h now defines the fakeroot
function, but since the binary "foo" (which is built in Source/Main)
is just linked against elk this gnustep-stuff isn't known there.
i changed the GNUmakefile in the cvs tree to reflect this ("foo" is
now linked against gnustep-base). hope this solves the problem.
bests,
martin
|
|
From: Gerhard E. <ger...@im...> - 2004-03-09 14:49:14
|
Dear Martin, I finally got to the point of verifying your suggestion. Indeed, #define GS_FAKE_MAIN 0 in GNUSTEP_ROOT/System/Library/Headers/GSConfig.h is set to '1' in my configuration. I used the LISTEN CVS version, which contains the #include of GSConfig.h, but this produces the following problem: make[2]: Entering directory `/localhome/eckel/src/listen/foo/foo/Source/Main' Making all for ctool foo... Compiling file main.c ... Linking ctool foo ... /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make[3]: *** [shared_obj/foo] Error 1 make[2]: *** [foo.all.ctool.variables] Error 2 make[2]: Leaving directory `/localhome/eckel/src/listen/foo/foo/Source/Main' make[1]: *** [internal-all] Error 2 make[1]: Leaving directory `/localhome/eckel/src/listen/foo/foo/Source' make: *** [internal-all] Error 2 So we probably have another problem ... Best regards, Gerhard |
|
From: martin r. <li...@ru...> - 2004-03-09 13:27:02
|
On Thu, Mar 04, 2004 at 03:52:50PM +0100, Sam Hocevar wrote: > Looks like a rooting issue somewhere in the Global Crossing network. like a SERIOUS routing issue (a long-standing). in the meantime, i heard from another user who can't reach the site from another domain (*.fraunhofer.de, might be the same backbone). the problem still exists. when i use a dialup-connection, everything is fine. really strange. are there any news regarding the garbage collector? am i missing something? bests, martin |
|
From: martin r. <ma...@ru...> - 2004-03-09 13:23:57
|
hi meikel, On Thu, Mar 04, 2004 at 11:33:55PM +0100, Meikel Brandmeyer wrote: > Huu... I don't know about Sam Hocevar. I once talked with Oliver Naumann, he's is the somehow current official maintainer of elk and debian packages of elk are in the unstable distribution. the site is: http://sam.zoy.org/projects/elk/ but it seems if there was a routing problem: the site is not reachable from some nodes at least in germany, anyway, if i use a dialup connection, it's no problem... sam went over all the code, turned the old-fashioned K&R-syntax into "modern" c, fixed some bugs (but apparently there are still some of them esp. in the garbage collector), autotool'd the stuff, it now compiles even with mac os x. > which is clearly not tolerable for a library. So Elk is currently a > total mess. In particular it is not useable in its current state. I'm i made use of it for our system before having discovered sam's site. the build system is somehow old-fashioned, but quite clever. perhaps it's wise to bundle the efforts. o.k., might be you want to get something else out of elk, so splitting the project may not be avoidable... bests, martin -- martinrumori (ma...@ru...) /* home is where your home directory is */ |
|
From: <ar...@ma...> - 2004-03-07 11:00:35
|
Hello Sirs, Doesn't look very appealing this "other" elk-page. What happens with Sam? Is he still not responding? Another question: what is your feeling about the alsa sound drivers. This should be the real standard for Linux now, isn't it? Probably we should think in how to migrate; What do you think? You, Martin, told me that libsndfile does not work with the alsa drivers. That could be an inconvenient, but probably there is some other solution. CCRMA uses exclusively alsa, and they probably have to deal with several soundfile formats. I am currently in Paris, rather busy that might serve as a good excuse for my little interaction. I'll be back to Madrid at the end of next week. But I can read the mail here. How were your exams, Martin? Went well I hope. All the best, Ramon |
11 messages has been excluded from this view by a project administrator.
