q-lang-devel Mailing List for Q - Equational Programming Language
Brought to you by:
agraef
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
(13) |
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
(3) |
Dec
(8) |
2007 |
Jan
(3) |
Feb
(23) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Yann O. <or...@fr...> - 2005-07-08 09:47:54
|
Albert Graef a =E9crit : > Orlarey Yann wrote: > >> 4) Conclusion : Parallelism will be the chance for Functional=20 >> Programming to go for mainstream in the next decade and we must get=20 >> prepared... > > > Well, Q has multithreading, and we're currently tossing around the=20 > idea to interface to PVM. But fine-grained, massive parallelism is a=20 > totally different beast. I'd say that Faust is much better prepared=20 > for this, with its support for vector operations. In any case we will all have a *lot* of work to deal with parallelism at=20 such a large scale with our languages. But multimedia functional=20 languages (Q, Faust, ...) have two advantages : a) the functional model=20 fits well to parallelism and automatic parallelisation, b) the=20 multimedia data (images, spectrums, sounds, etc.) are generaly adapted=20 to parallel processing. Data parallelism is certainly an approach to=20 look at... Yann |
From: Albert G. <Dr....@t-...> - 2005-07-06 16:53:10
|
Orlarey Yann wrote: > 4) Conclusion : Parallelism will be the chance for Functional > Programming to go for mainstream in the next decade and we must get > prepared... Well, Q has multithreading, and we're currently tossing around the idea to interface to PVM. But fine-grained, massive parallelism is a totally different beast. I'd say that Faust is much better prepared for this, with its support for vector operations. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Orlarey Y. <or...@gr...> - 2005-07-06 08:20:30
|
(Cross-posted to the Faust and Q mailing lists.) Dear All, Some information interesting to relate : 1) Quoted from "Apple to Use Intel Microprocessors Beginning in 2006" : "Our goal is to provide our customers with the best personal computers in= the world, and=20 looking ahead Intel has the strongest processor roadmap by far,=94 said S= teve Jobs, Apple=92s=20 CEO. =93It=92s been ten years since our transition to the PowerPC, and we= think Intel=92s=20 technology will help us create the best personal computers for the next t= en years." http://www.apple.com/pr/library/2005/jun/06intel.html 2) Intel has published its "platform 2015" roadmap forecasting massively = parallel=20 multi-core processors within the next 10 years http://www.intel.com/technology/computing/archinnov/platform2015/ ftp://download.intel.com/technology/computing/archinnov/platform2015/down= load/Platform_2015.pdf 3) There is a special issue (May 2005) of the Journal of Functional Progr= amming on "High=20 Performance Parallel Functional Programming". Quoting P.W. Trinder in this issue : "Indeed, it can be argued that high-= performance=20 systems now rival prototyping, formal reasoning and education as areas wh= ere functional=20 technology has the greatest impact." 4) Conclusion : Parallelism will be the chance for Functional Programming= to go for=20 mainstream in the next decade and we must get prepared... Yann |
From: Thomas P. <tho...@gm...> - 2005-03-24 22:01:26
|
Hello, found the following: _fnametb[INDEX] in qc works all right but fnametb[INDEX] in q is always null. I still do not understand how the qc and q part interact if qc is not invoked seperately. Giving up for today, anyway. Cheers, aanno |
From: Albert G. <Dr....@t-...> - 2005-03-02 11:19:20
|
Thomas Pasch wrote: > (moved here from the user list because this is development stuff) Yes, good idea. > First of all, I couldn't disable building the octave extension with > --without-octave. Is this a bug with autoconf/automake? IIRC, there's no --without-octave, because there are no library dependencies for this module. It just drives the octave program through a bidirectional pipe. So it should compile even if octave is not installed at all. > Second, I wonder if it is possible to build q without (1) gmp and > (2) without clib. (1) No. (2) Yes, in principle, but I'm afraid you'll have to fiddle with the corresponding Makefile.am. (Also, you'll have to comment the "include clib"-line in prelude.q, otherwise the interpreter will complain about a missing clib.q when started.) If you take this route, you could as well try to just disable the building of *all* modules. I guess that it would be enough to just remove the "modules" entry in the SUBDIRS macro in the global Makefile.am. > Last not least I begone to look at q.c:resolve():around 1674 (where > the module load error is reported). Using the debugger was a > little strange until I realized that the symbol go an additional > (magic) prefix __qq__. (Is there an easy way to get rid of it?) You could try to just make mangle.h an empty file. (IIRC, this might cause incorrect resolution of some shared lib entry points due to naming conflicts, at least on some systems.) Better get used to the name mangling, it's fairly straightforward. :) > Most of the code is difficult to debug because it modifies untyped > memory with expression like: > > char *fname = strsp+fnametb[modno]; That strsp variable belongs to the bytecode. The corresponding data is declared in qbase.h. In the interpreter, strsp ("string space") is just a dynamically allocated char vector holding all the static strings in the bytecode (string constants, symbol identifiers, module names etc.). The strings are just stored in sequence (each string is (char)0-terminated). In the remainder of the bytecode data (e.g., in the virtual machine ops) the string data is then referred to using just an index into the strsp array (the index is the index of the first character of the string). I guess that's more or less how almost any PL compiler or interpreter does this kind of thing. ;-) Yes I know that the coding is a bit sloppy but, hey, this project was started when ANSI C was nothing but a spec. That's also why some portions of the code still look very much like K&R C. ;-) > The first expression is part of the problem: strsp is set to > malloced memory but fnametb[modno] is always NULL. If I'm not mistaken, fname[modno] should be an int, namely an index into strsp. And it shouldn't be zero, under no circumstances. If it is, then there's probably something going wrong in the bytecode compiler, qc. > How and where are fnametb and symtb calculated? Those are calculated while the bytecode compiler parses the source, in qc.y and qclex.l. IIRC, actually qc uses its own private copy of fnametb, _fnametb. Just grep for those symbols in src. The source files with a qc in front belong to the compiler, so this is where to look. Turning on DEBUG in qc (see below) should also help to track down this bug. > Are the any routines that could help to "dump" this > parts? Compile everything with the DEBUG symbol defined. The bytecode compiler will then spit out most of the bytecode it generates in a (more or less) readable format on stdout. (Search for #ifdef DEBUG in src to find out exactly what information is printed.) HTH, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Thomas P. <tho...@gm...> - 2005-02-24 19:46:07
|
Hello, (moved here from the user list because this is development stuff) I'm trying to figure out what goes wrong on AMD64. At the moment, however, I encounter some (more?) basic problems. I wanna strip q to the bare minimum but encountered some problems with this task. First of all, I couldn't disable building the octave extension with --without-octave. Is this a bug with autoconf/automake? Second, I wonder if it is possible to build q without (1) gmp and (2) without clib. Last not least I begone to look at q.c:resolve():around 1674 (where the module load error is reported). Using the debugger was a little strange until I realized that the symbol go an additional (magic) prefix __qq__. (Is there an easy way to get rid of it?) Most of the code is difficult to debug because it modifies untyped memory with expression like: char *fname = strsp+fnametb[modno]; or strcat(sym, strsp+symtb[xfno].pname); The first expression is part of the problem: strsp is set to malloced memory but fnametb[modno] is always NULL. Perhaps someone you explain the general setting to me. strsp seems to be a base address. What is the general layout of the memory accessed by this (base) address. It seems to be split in several parts. How and where are fnametb and symtb calculated? Are the any routines that could help to "dump" this parts? Cheers, aanno |
From: <ben...@id...> - 2004-05-25 09:10:46
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Kari P. <ka...@sa...> - 2004-03-12 03:59:15
|
On Sun, Mar 07, 2004 at 05:27:20AM +0100, Albert Graef wrote: > Done. Is linking to mentors.debian.net/ enough, or is there some other > (package-specific) page I could link to? Debian has per-package information on their web server, but mentors.debian.net doesn't. I asked for similar pages for the mentors from the admins, but it's up to them if and when they implement them. So far no Debian Developer has offered to take the package. Things have been silent, one DD just complained of a broken upload (the problem is on mentors' side). It'd be best to get Q into Debian, not just host the packages at mentors', but that's completely up to some individual DD's interest. With some luck it'd get in in time to be included in sarge. |
From: <Dr....@t-...> - 2004-03-07 04:44:22
|
Kari Pahula wrote: > I tried both versions 2.5.31 and 2.5.4a, both failed with the same > error. The earlier version was packaged to Debian to provide a > POSIX-compliant version of flex. Hmm, I'm running 2.5.4 here, which doesn't exhibit this problem (but maybe SuSE patched it). Will have to look into this for the next release. > As long as non-CVS versions do not die for odd flex versions, I'm not > that bothered with this one. I'll see if things break when the next > release comes. No, the source tarball always includes the .c sources, so that should be ok. > I packaged 5.2 some time ago already; update your web page. I would Thanks. > recommend against telling the complete directories of the .deb > packages, those are internal to apt-get and not really intented for > human use. apt-get is the standard way for getting packages for > Debian, not with dpkg -i on individual .debs. > > Also, please don't link my home page. Done. Is linking to mentors.debian.net/ enough, or is there some other (package-specific) page I could link to? -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-03-06 23:27:31
|
On Mon, Mar 01, 2004 at 05:53:18PM +0100, Albert Graef wrote: > What flex version do you have on your system? I tried both versions 2.5.31 and 2.5.4a, both failed with the same error. The earlier version was packaged to Debian to provide a POSIX-compliant version of flex. As long as non-CVS versions do not die for odd flex versions, I'm not that bothered with this one. I'll see if things break when the next release comes. > for the .l's. I meanwhile updated the q-5.2.tar.gz tarball and the other > 5.2 packages on SourceForge to include the latest fixes. Having two different releases with the same version number is bad karma. I packaged 5.2 some time ago already; update your web page. I would recommend against telling the complete directories of the .deb packages, those are internal to apt-get and not really intented for human use. apt-get is the standard way for getting packages for Debian, not with dpkg -i on individual .debs. Also, please don't link my home page. |
From: <Dr....@t-...> - 2004-03-01 17:09:09
|
Kari Pahula wrote: > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl -DYEAR=2004 -DSYSINFO=i686-pc-linux-gnu -DQPATH=.:/usr/local/share/q/lib:/usr/local/lib/q -DQEXEC=/usr/local/bin/q -DLIBTOOL=/usr/local/lib/q/libtool -DCC=gcc -g -O2 -c qmlex.c > qmlex.l: In function `__qq__peek': > qmlex.l:399: error: `yytext_ptr' undeclared (first use in this function) > qmlex.l:399: error: (Each undeclared identifier is reported only once > qmlex.l:399: error: for each function it appears in.) > make[2]: *** [qmlex.o] Error 1 > make[2]: Leaving directory `/home/kari/download/q/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/kari/download/q' > make: *** [all-recursive-am] Error 2 Yes, that seems to be a silly bug in some flex versions, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189332 What flex version do you have on your system? Unfortunately, I don't know a workaround for this which doesn't break with the "good" flex versions. :( So I guess that you'll just have to get a working flex or use the tarball version which includes the .c's for the .l's. I meanwhile updated the q-5.2.tar.gz tarball and the other 5.2 packages on SourceForge to include the latest fixes. -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-03-01 13:06:51
|
On Sun, Feb 29, 2004 at 06:13:53PM +0100, Albert Graef wrote: > Kari, could you please try the latest cvs sources and let me know > whether this works for you? gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl -DYEAR=2004 -DSYSINFO=i686-pc-linux-gnu -DQPATH=.:/usr/local/share/q/lib:/usr/local/lib/q -DQEXEC=/usr/local/bin/q -DLIBTOOL=/usr/local/lib/q/libtool -DCC=gcc -g -O2 -c qmlex.c qmlex.l: In function `__qq__peek': qmlex.l:399: error: `yytext_ptr' undeclared (first use in this function) qmlex.l:399: error: (Each undeclared identifier is reported only once qmlex.l:399: error: for each function it appears in.) make[2]: *** [qmlex.o] Error 1 make[2]: Leaving directory `/home/kari/download/q/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kari/download/q' make: *** [all-recursive-am] Error 2 |
From: <Dr....@t-...> - 2004-02-29 18:29:49
|
Albert Graef wrote: > * src/Makefile.am: rebuild qcwrap at installation time > s.t. library paths are properly set in the installed executable > > * ./Makefile.am: change directory order s.t. src is built last Forget about those, they were broken so I reverted them. -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: <Dr....@t-...> - 2004-02-29 17:26:40
|
All right, the following changes are in cvs now: 2004-02-29 Albert Graef <Dr....@t-...> * qdoc.texi: added @dircategory/@direntry (suggested by Kari Pahula) * configure.in: use installed libreadline if available * src/Makefile.am: rebuild qcwrap at installation time s.t. library paths are properly set in the installed executable * ./Makefile.am: change directory order s.t. src is built last * Makefile.am (various): avoid -L<builddir>/libq flag which ends up in the installed .la files (reported by Kari Pahula) I used Programming Languages as the @dircategory (that's what, e.g., Ocaml shows up under on my system, I think that's reasonable). Kari, could you please try the latest cvs sources and let me know whether this works for you? Albert -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: <Dr....@t-...> - 2004-02-29 07:03:06
|
Kari Pahula wrote: > The nearest thing you got to a standard is the "Installing Info > Directory Files" page in texinfo's doc and the dir-example file > included with texinfo. It has "Software development" category listed > in it, Q would fit under that. That'd be better than leaving it > unspecified, IMHO. Agreed. I'll add that in the next release. > I've put packages of 5.1 at mentors.debian.net. It's compiled now > with -O3. And Q 5.2 has just been released. ;-) It's only a couple of bug fixes this time, though. > It's only for sid for now, but I'll try to find a sponsor for it and > get it included in Debian proper. That'll take care of having > packages for sarge, too. I wouldn't bother with backporting the > package to woody, sarge should be released in the near future anyway. Sounds good. > I wouldn't bother to include readline with Q. Trivial replacement for > readline is scanf. That's what I've seen other projects do. Well, you're probably right, by now readline seems to be available almost everywhere. > I wouldn't provide those --with-*-includes options. The configure > script is supposed to find the required flags without user > intervention. Ideally the only things the user should have to concern > himself with are where to install (--prefix and friends) and what to > install (--enable-* and --with-*). And --with-libname is for a 'yes' > or 'no' input from the user, not the flag to pass to the compiler. Yes, that's exactly how my configure is supposed to work, too. I just added some functionality so I don't have to edit Makefiles and scripts just because, e.g., some lib is in /opt/sfw (SUN) or libpthread is actually called libc_r (FreeBSD). It's a convenience, and it doesn't break the standard --with-xyz={yes,no} behaviour, so why remove it? > This is what dependency_libs in clib.la looks like in a pristine build: > dependency_libs=' -L/home/kari/dl/q-5.1/libq /usr/local/lib/libq.la /usr/lib/libgmp.la -lpthread -lcrypt -lutil -lnsl -lm' Ouch. Yes, this definitely has to be fixed. On the TODO list. Thanks, Albert -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-02-29 01:34:56
|
On Mon, Feb 23, 2004 at 11:28:35PM +0100, Albert Graef wrote: > Kari Pahula wrote: > >I've begun building a Debian package of Q. Some things I've changed > >to make it conform more to Debian's standards: > > Ok. I have my gripes with scattering stuff belonging to a package all > over the place, but if that's the standard under Debian, then so be it... It's nice to have programs follow a uniform standard once you have thousands of them. > >I moved stuff away from share/q/etc and share/q/examples. > > Did you move *all* the stuff in examples? (I'm asking because a FreeBSD I didn't touch the example installation parts of the makefiles, I just let it install everything under /usr/share/q/examples and then mv it where I like afterwards. That should get them all. > >In the package: > >@dircategory Development > >@direntry > >* Q: (qdoc). The Q programming language and system. > >@end direntry > > Hmm, is that standard across different distros? Then I might add it to The nearest thing you got to a standard is the "Installing Info Directory Files" page in texinfo's doc and the dir-example file included with texinfo. It has "Software development" category listed in it, Q would fit under that. That'd be better than leaving it unspecified, IMHO. I don't know why Debian has chosen to put most of its info docs under "Development". "Software development" is used too. This isn't really something anybody has bothered to make any official decision on. > >Most of the packaging is done, but I'm stuck with the libraries. > >Things work fine until I run automake again. > > Yes, cvs had some files which should rather be regenerated when It's been a while since I've touched libtool, all my troubles were mostly due to my own neglicience. If in doubt, rebuild scripts... > I'll provide a pointer to your page on the Q website asap. BTW, on which I've put packages of 5.1 at mentors.debian.net. It's compiled now with -O3. > Debian system(s) will that package work? I guess that the different > library versions available will make it necessary to distribute separate > packages for woody, sarge and sid, no? It's only for sid for now, but I'll try to find a sponsor for it and get it included in Debian proper. That'll take care of having packages for sarge, too. I wouldn't bother with backporting the package to woody, sarge should be released in the near future anyway. I hope you don't mind if I say a few things about the build system. All of this is IMHO, of course. I wouldn't bother to include readline with Q. Trivial replacement for readline is scanf. That's what I've seen other projects do. I wouldn't provide those --with-*-includes options. The configure script is supposed to find the required flags without user intervention. Ideally the only things the user should have to concern himself with are where to install (--prefix and friends) and what to install (--enable-* and --with-*). And --with-libname is for a 'yes' or 'no' input from the user, not the flag to pass to the compiler. If you are using GNU extensions in glob and regex, then I guess it's ok to include them. I'm still changing the build system to use the ones in glibc for my packages. I would make a --with-ltdl option, which would use the system's version if it's 'yes' and use the included one if 'no'. That would be a more uniform semantics than the special --with-installed-ltdl used now. And there's one genuine problem with the build system. You are building modules which use a library built in the same build. You have specified SUBDIRS = ... libq modules ... and rely on the order of make in subdirectories for libq to be built. You then add -L$(top_builddir)/libq -lq in _la_LIBADD in the modules' Makefile.am files. This works, but that same flag ends up in dependency_libs in the final installed .la file. This may be an security risk, if that path is writable by an user. This is what dependency_libs in clib.la looks like in a pristine build: dependency_libs=' -L/home/kari/dl/q-5.1/libq /usr/local/lib/libq.la /usr/lib/libgmp.la -lpthread -lcrypt -lutil -lnsl -lm' I can think of two ways of preventing that extra -L ending up in there. The right way: build first anything but the modules, install them, then build the modules, no need for any extra -L flags as libq is already installed. Or the hack: change the .la files themselves. I did this for myself. I did this after everything was installed: for a in $(CURDIR)/debian/q-lang/usr/lib/q/*.la;\ do sed 's/-L[^ ]+libq//' -r < $$a >$$a.fixed;\ mv $$a.fixed $$a; done You might want to do something like that in your build too. |
From: <Dr....@t-...> - 2004-02-23 23:28:16
|
Kari Pahula wrote: > Of course I had to run libtoolize too. There may still be issues with > it, but it seems to be in usable state already. I put the Debian > package available at http://users.utu.fi/~kaolpa/debian/. Kari, I really have to thank you a lot for all your work on this. :) I'll provide a pointer to your page on the Q website asap. BTW, on which Debian system(s) will that package work? I guess that the different library versions available will make it necessary to distribute separate packages for woody, sarge and sid, no? I know that this is asking too much, but if you have some spare time maybe you could try to port the latest version, 5.1, as well? The installation layout hasn't changed much (just one new binary, qcwrap, going to <prefix>/bin). The new interpreter has some important new features, though, (e.g., full tail call elimination, Haskell-like [X..Y] enumeration syntax, Q->C translator) which should make the upgrade worthwhile. ;-) I hope that I soon have the time to install Debian on my development box so that I can try out your port myself. Then we can see whether we can get the other packages ported, too. > It'd be a good idea to build the included libraries only > conditionally. glob and regex are part of libc6, thus available on > linux systems universally. ltdl and readline are commonly present > too. Only ltdl was configurable to use the library present in the > system. Building the libraries *is* conditional. Configure will check what libraries are there and will then only build the modules for which the corresponding libraries are available. Concerning readline: You can force configure to use the installed library with --with-rl=-lreadline. Actually, that's what I do to build the system on other Linux distros, where I use a configure line like the following: CFLAGS="-O3" ./configure --prefix=/usr --with-rl=-lreadline (BTW, if you didn't use -O3 with your build, consider doing that, too, it makes a *great* difference, the interpreter will run much faster than with the default "-g -O2" flags.) Concerning glob and regex: I originally included these to resolve portability issues, specifically with Solaris and OSX which have system libs which are incompatible with the GNU versions. I could add configure flags to use the libc versions, or even make that the default behaviour on Linux, but as these libs are only a few KB I don't know whether it's really worth the effort. Cheers, Albert -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: <Dr....@t-...> - 2004-02-23 22:37:16
|
Kari Pahula wrote: > I've begun building a Debian package of Q. Some things I've changed > to make it conform more to Debian's standards: Ok. I have my gripes with scattering stuff belonging to a package all over the place, but if that's the standard under Debian, then so be it... > I moved stuff away from share/q/etc and share/q/examples. Did you move *all* the stuff in examples? (I'm asking because a FreeBSD porter did more or less the same thing, but forgot the examples in subdirs like examples/curl, etc.) > I installed q-mode.el to where emacs can find it. Yeah, actually automake has a target to do that automatically. I'm not using this right now, because it will only install to the GNU emacs directory, not xemacs, so I'm leaving that up to the users right now. > Single-letter package names aren't allowed. I named the package as > q-lang. Ok. > In the package: > @dircategory Development > @direntry > * Q: (qdoc). The Q programming language and system. > @end direntry Hmm, is that standard across different distros? Then I might add it to the qdoc.texi in cvs. Otherwise, if those categories are something Debian-specific, I'll just leave the source as it is now. > Most of the packaging is done, but I'm stuck with the libraries. > Things work fine until I run automake again. Yes, cvs had some files which should rather be regenerated when bootstrapping with a different set of autotools. That should be fixed now. If you check out the latest cvs and run autogen.sh then all autotools-related stuff should be regenerated from scratch. Unfortunately, this doesn't work with the source tarball which includes the autotools-generated files so that ppl can just run ./configure && make && make install. So you'll have to check out the sources from cvs to make this work (use tag 'R5_1' to get the latest release). -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-02-22 18:48:32
|
On Sun, Feb 22, 2004 at 02:40:59PM +0200, Kari Pahula wrote: > On Sun, Feb 22, 2004 at 05:39:21AM +0200, Kari Pahula wrote: > > Most of the packaging is done, but I'm stuck with the libraries. > > Things work fine until I run automake again. The .so files seem to > > Things work still after running automake, running aclocal again starts > all the trouble. Of course I had to run libtoolize too. There may still be issues with it, but it seems to be in usable state already. I put the Debian package available at http://users.utu.fi/~kaolpa/debian/. I had to change a number of things in Q build process to make it conform more to the Debian standards. It'd be a good idea to build the included libraries only conditionally. glob and regex are part of libc6, thus available on linux systems universally. ltdl and readline are commonly present too. Only ltdl was configurable to use the library present in the system. There's still a few things I could say about the build process, but that'll have to wait for another time. As well as packaging the add-ons. |
From: Kari P. <ka...@sa...> - 2004-02-22 12:51:25
|
On Sun, Feb 22, 2004 at 05:39:21AM +0200, Kari Pahula wrote: > Most of the packaging is done, but I'm stuck with the libraries. > Things work fine until I run automake again. The .so files seem to Things work still after running automake, running aclocal again starts all the trouble. |
From: Kari P. <ka...@sa...> - 2004-02-22 03:46:35
|
I've begun building a Debian package of Q. Some things I've changed to make it conform more to Debian's standards: I moved stuff away from share/q/etc and share/q/examples. I moved that stuff to /usr/share/doc/q-lang/ and /usr/share/doc/q-lang/examples/. I installed q-mode.el to where emacs can find it. Directory name "etc" implies system-wide configuration files. None of the stuff in there was that. Single-letter package names aren't allowed. I named the package as q-lang. I changed the info file to have the right section in it. It was originally like this: START-INFO-DIR-ENTRY * Q: (qdoc). The Q programming language and system. END-INFO-DIR-ENTRY In the package: @dircategory Development @direntry * Q: (qdoc). The Q programming language and system. @end direntry Most of the packaging is done, but I'm stuck with the libraries. Things work fine until I run automake again. The .so files seem to lose their suffix, I don't know if that's significant. The contents of /usr/lib/q/ are: clib curl.a gdbm.la libtool octave odbc.a tk.la clib.a curl.la ggi magick octave.a odbc.la clib.la gdbm ggi.a magick.a octave.la tk curl gdbm.a ggi.la magick.la odbc tk.a The files without suffix have their executable bit set too. This doesn't seem to be related to the debian packaging I've done, running automake and autoconf on the pristine source yields the same result. A few diagnostics on this: $ q Error /usr/lib/q/clib, line 1: parse error at or near symbol `_' $ file /usr/lib/q/clib /usr/lib/q/clib: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped $ file /usr/local/lib/q/clib.so /usr/local/lib/q/clib.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped Looks like /usr/lib/q/clib.la has libraries from the build directory listed in it, under my home directory. As an example, the file /usr/lib/q/curl.la: # curl.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4.2 (1.922.2.53 2001/09/11 03:18:52) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='curl' # Names of this library. library_names='curl curl curl' # The name of the static archive. old_library='curl.a' # Libraries that this one depends upon. dependency_libs=' -L/home/kari/dl/debian/q-lang-5.0/libq /usr/lib/libq.la /usr/l ib/libcurl.la -lz -lssl -lcrypto -ldl -lcrypt -lutil -lnsl -lm' # Version information for curl. current=0 age=0 revision=0 # Is this an already installed library? installed=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib/q' I tried automake versions 1.4, 1.6, 1.7 and 1.8 (you used 1.5 but that wasn't packaged in Debian). I need to be able to run automake again to get the needed changes properly done. |
From: Kari P. <ka...@sa...> - 2004-02-07 16:17:39
|
On Mon, Feb 02, 2004 at 12:58:04PM +0100, Albert Graef wrote: > P.S.: Did you port the other Q-related packages to Debian yet? If so, Ok, I had a look at the other packages. q-audio should check for the presence of sndfile in its configure script. src/sndfile.c failed to #include "sndfile.h" and failed with a bunch of errors about undefined variables. You mention this dependency in the README file, but it wouldn't hurt to make it explicit in the configure too. I didn't get q-audio to actually play any sound. I ran audio_examp.q with the following result: ==> play ("canary-long.wav") PaHost_OpenStream: could not open /dev/dsp for O_WRONLY PaHost_OpenStream: ERROR - result = -10000 play ("canary-long.wav") My audio config seems to be ok, sox played that file fine. audio_player failed with: libgg: Unknown target option 'keepcursor' display-x: error in arguments. Removing that keepcursor option from the ggi init made audio_player work. It displayed the sample data graphically, but didn't play any sound either. IANAL, but there might be some trouble with q-midi linking to MidiShare, whose licence is not compatible with GPL. The licence of MidiShare has: "You cannot modify all or part of the MidiShare software." AFAIK this means that q-midi can't be distributed in binary format. This is what kept KDE away from Debian for years. This particular problem can be fixed on your side with adding to the GPL something like "as a special exemption, you may link q-midi with MidiShare." Consult FSF for details on this. Besides, the compilation of q-midi fails with the same kind of errors as q-audio. The configure script should check for MidiShare. Graph compiled flawlessly and could be ran once I read the README and found out about the dependency on BFilter. > maybe you could contribute Debian packages for the latest release? That > would be truly great. :) It would be time-consuming for me too. And I think .deb packages do little good if they're not included in Debian proper. I would need to find a sponsor, as I am not a Debian developer... Besides, I'm not familiar with creating .debs either, at least no yet. I might do this later, when I have time and if I'm still interested in Q. Checking if things run is a lot less involving. |
From: <Dr....@t-...> - 2004-02-06 12:41:10
|
Hi, you probably noticed that messages sent to the q-lang mailing lists have been delayed for some time now. I didn't get a reply to my own support request yet, but I've seen the following notice about the ML issues from the SourceForge staff on the ggi-develop ML (which had the same problems, as did many other projects): ----------------------------------------------------- This is a canned response addressing a sitewide problem with SF.net. A filesystem issue on our of our list servers has caused a large backlog of mailing list messages to accumulate, sometimes causing reported delays of up to 5 days (although most messages were not impacted significantly). In some cases, you may have received a warning message from another SF.net mail server (either sf-mx1 or sf-mx2) that the message had spent an undue amount of time on the queue while receiving this error from sf-list1: 421 Unexpected failure, please try later We believe that this failure was due to heavy load on our mail servers (and by extenstion, the DNS servers) from the MyDoom/W32.SCO.* virii. This problem was fixed and over time, the backlog has been worked through (as well as the normal mailing list load). We believe that we are caught up at this point, although it's possible that there are a few exceptions. We deeply regret the inconvenience. If you are still seeing delays in mailing list messages posted after 02/05/2004 please let us know by opening a new Support Request. ----------------------------------------------------- Ok, let's hope that this is fixed now... Albert -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: <Dr....@t-...> - 2004-02-02 11:56:55
|
Kari Pahula wrote: > I had to give option --with-tk-includes=-I/usr/include/tcl8.4 to the > configure script to get the right include directory. Debian systems > install the headers there, not to plain /usr/include. Included is a > patch for configure.in to add the right include directory if > necessary. Thanks a lot for your patch, I already committed it to cvs. Note that I moved the TK_INCLUDES="" initialization before the "${TK_LIBS}" != "" test, to make sure that TK_INCLUDES is always properly initialized. Cheers, Albert P.S.: Did you port the other Q-related packages to Debian yet? If so, maybe you could contribute Debian packages for the latest release? That would be truly great. :) -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-02-01 14:47:47
|
I had to give option --with-tk-includes=-I/usr/include/tcl8.4 to the configure script to get the right include directory. Debian systems install the headers there, not to plain /usr/include. Included is a patch for configure.in to add the right include directory if necessary. |