Menu
▾
▴
octave-dev
|
From: Julian A. de M. Ph.D <ju...@ma...> - 2001-05-15 23:11:51
|
Hey, what a crazy name you have (pronunciation please?)! So... re: the CVS, yes, it's a hairball and I brought that up with Paul K; partly it's a matter of where the matcompat (biggest/only upload so far) got situated. My own feeling is that each "PROJECT" should have its own parent folder in the CVS. So /matcompat/... /tk_octave/... for starters. This should clear up any mess, at least from a high-level perspective it will keep any hairballs localised. Let me see what the other devs thinks. re: JWE, yes, he's reluctant about anything GUI-related (he doesn't even use X-Windows, strictly a command-line dude as far as I know). But as I said before, I think once the code carries its own weight any lead will naturally turn into gold. There's still no FORMAL arrangement about pulling SF work into the main dist, but again I think that if the code proves itself it will happen one way or another. JWE runs a tight ship. SF provides a popular means within the Octave community for parallel efforts, and is thereby popularly de-facto legit. TCL/TK is the best proposition I've ever gleaned from the octave discussion archives on the GUI issue. Let me know when you get your SF handles registered. Be sure to check the SF HOW-TOs on CVS before you start uploading. =jo...@us... -----Original Message----- From: Przemek Klosowski [mailto:pr...@ja...] Sent: Tuesday, May 15, 2001 1:15 PM To: ju...@ma... Cc: jo...@ja...; pr...@ja... Subject: Re: GUI for Octave programs. You'd get full co-dev access to CVS etc. All code @ octave.sourceforge.net is meant for eventual absorption into the main dist. Details are actually being worked out, but generally folks agree that candidate code ought first demonstrate its worth before consideration. The SF site is the community-preferred place for doing so. If it seems scant right now that's only b/c we've just gotten it off the ground again following a big hiatus on the part of the original SF folks (had to pry the passcodes out of their hands! -- just kidding). OK, we'd be honored to work with you. I understand that this is what we'd be doing: export CVS_RSH=ssh cvs -z3 -d:ext:dev...@cv...:/cvsroot/octave co modulename after we get the accounts and passwords (we'd ask for 'przemek' and 'johnc'). I had a little trouble figuring out the layout of the CVS tree contrib dld Attic scripts Attic contrib dld scripts civil ode scripts numeric Attic Attic civil ode image (newmark) (ode) Attic (colormaps) and finally: octave Attic Fixes contrib dld nodld non-free scripts ver20 scripts au/grph/libo/mex/.. nonnumeric numeric so I take it that the correct path for our stuff might be something like cvsroot/octave/octave/dld/tk_octave unless you are planning to move things around there. Is it possible to collapse the tree by pulling out stuff from under cvsroot/octave/octave into cvsroot/octave/{Attic,Fixes,...} We asked Joao Cardoso, and he responded that he isn't planning to further develop tk_octave and basically gave us the permission to carry on with the development (we have to sort out if our changes didn't take away any functionality---if not, we agreed that he will repoint his own page to sourceforge). All code @ octave.sourceforge.net is meant for eventual absorption into the main dist. Details are actually being worked out, but generally folks agree that candidate code ought first demonstrate its worth before consideration. What's the latest on JWE's plans---I take it that he's not planning to have octave's sources on sourceforge, but is willing to pull out the most popular pieces off octave.sourceforge.net into the mainline release; am I close? John wasn't enthusiastic about Tcl as a vehicle for GUI building when I talked to him last, but I think it's an attractive proposition and I am looking forward to having people try it. przemek |
|
From: Paul K. <pki...@ki...> - 2001-05-16 14:01:38
|
On Tue, May 15, 2001 at 07:11:42PM -0400, Julian A. de Marchi, Ph.D wrote: > Hey, what a crazy name you have (pronunciation please?)! > > So... > > re: the CVS, yes, it's a hairball and I brought that up with Paul K; > partly it's a matter of where the matcompat (biggest/only upload so far) > got situated. My own feeling is that each "PROJECT" should have its own > parent folder in the CVS. So > > /matcompat/... > /tk_octave/... > > for starters. This should clear up any mess, at least from a high-level > perspective it will keep any hairballs localised. Let me see what the > other devs thinks. As you say, the only thing on the site is matcompat, it just happens to be in /octave/... instead. That suits me fine since many of the routines are useful to the wider octave community, not just those who want to run existing matlab code. The confusion in the present tree has two sources. One is the CVS download instructions. They should tell you how to grab the entire tree rather than just a single "module". The following seems to work: cvs -z3 -d:ext:dev...@cv...:/cvsroot/octave co . The other source of confusion is that CVS does not control directory structure, and does not allow you to remove empty directories. Rearrangements to accomodate the first problem left vestiges of the old organization and the confusing structure we have today. The whole project needs to be purged and a new CVS tree put in place having the structure we want, and clear instructions on where to put new files and directories. This may need to be done periodically, especially if routines are sucked off into the main Octave distribution with any regularity. Before putting the new tree is in place, feel free to rearrange the /octave/... subdirectory. I used the structure that was already in place since changing it would have made the tree even more confusing. I would particularly like the numeric/nonnumeric distinction to go away, and have the scripts tree be one level flatter. I would also prefer all the parts to a package together (scripts, dld, documentation, tests, demos, sample data) rather than in separate trees, but the current organization is closer to Octave's organization, so there are grounds for keeping things as they are. > > re: JWE, yes, he's reluctant about anything GUI-related (he doesn't even > use X-Windows, strictly a command-line dude as far as I know). But as > I said before, I think once the code carries its own weight any lead will > naturally turn into gold. There's still no FORMAL arrangement about > pulling SF work into the main dist, but again I think that if the code > proves itself it will happen one way or another. JWE runs a tight ship. > SF provides a popular means within the Octave community for parallel > efforts, and is thereby popularly de-facto legit. TCL/TK is the best > proposition I've ever gleaned from the octave discussion archives on the > GUI issue. There is a strong argument for not moving code into Octave proper. As long as OctaveSF contains useful routines people will continue to use it and any new contributions will immediately have a wide audience. If on the other hand you regular pick off the great and the good, then the only people who will bother with it are the hard core developers of which there are very few. Also, once the code is in Octave proper it is harder to maintain since all changes then have to be done through bug reports. Whether or not those bug reports receive action depends on John's level of interest. > > Let me know when you get your SF handles registered. Be sure to check the > SF HOW-TOs on CVS before you start uploading. > > =jo...@us... > > -----Original Message----- > From: Przemek Klosowski [mailto:pr...@ja...] > Sent: Tuesday, May 15, 2001 1:15 PM <snip> > John wasn't enthusiastic about Tcl as a vehicle for GUI building when I > talked to him > last, but I think it's an attractive proposition and I am looking forward to > having > people try it. It strikes me as wasteful to invoke another interpreter for a different language when we already have an interpreter available to us. For one thing, that requires your users to learn another language before being able to develop their own GUI. Is it feasible to control TK directly from Octave and avoid any TCL? Either way, your TK controls will need to be able to trigger Octave callbacks, so it would be nice to cut out the middle man. Paul Kienzle pki...@ki... |
|
From: Matthew W. R. <ma...@ne...> - 2001-05-17 20:55:00
|
On Wed, May 16, 2001 at 08:52:59AM +0100, Paul Kienzle wrote: > The whole project needs to be purged and a new CVS tree put in > place having the structure we want, and clear instructions on > where to put new files and directories. ... Agreed. There have been several discussions in the past on the directory structure: http://www.geocrawler.com/archives/3/3262/2001/2/0/ http://lists.sourceforge.net/archives/octave-dev/2000-October/thread.html http://lists.sourceforge.net/archives/octave-dev/2000-November/thread.html Personally, I would prefer to base the directories on a toolbox-type layout with each toolbox having its own directory. That way we can easily package toolboxes independently for distribution. BTW, for those that may have missed it, sourceforge has secured the sf.net domain. So an easier way to get to the home page is: http://octave.sf.net/ -- Matthew W. Roberts ------------------------------------------------------------------ Structural Engineering * Texas A&M University * ma...@ta... |
|
From: Paul K. <pki...@ki...> - 2001-05-18 00:50:54
|
Wow! You exist! Working on Octave I know can be very disheartening. Few people join in and collaborate on anything. Oh, well. Looking through the archives you point to, here are some random comments: 1) You need an autoconf like facility for the geometry toolbox (which needs to find libqhull), symbolic toolbox (which needs to find GiNaC among others), sparse toolbox (which needs SuperLU, but unfortunately a patched version), spline toolbox (which should use ATLAS if available), and if I get around to it, audio support (which ought to rely on snack and libsnd). Kai Habel was going to have a go at it for qhull but he promised it would take a while. 2) Toolboxes have cross-dependencies which will need to be resolved. Particularly image/signal, but also splines and things. Support for independent packaging is not appropriate at the moment since the toolboxes are mostly tiny (except signal and image) and enthusiasm is low. How about we put a hard limit of 5 Mb total main tree size before we worry about separate packaging? 3) Links to external packages may be best handled on matlinks.net. Let the sourceforge repository be an actual repository. The exception is if you have made a patch to get the package to work on Octave, in which case you want to keep around the version which you patched. 4) Could you let the admins in on the mailing list password? I would like to confirm that the developers I have been adding are subscribed to the list, and gently prod them to do so if they are not. 5) I agree that functions should be able to use the latest octave 2.1.x features if they make the code cleaner, but if 2.0.x can be supported with only minor hassle, the go for it. A small flat ver20 directory off the root can take care of the rest. Keeping the ver20 functions in sync with the main tree may be too difficult --- wait until somebody ambitious decides to take this on. 6) Functions should not require patched versions of Octave or gnuplot to run. 7) Directory structure should mirror the current Octave directory structure as far as possible (so no numeric/non-numeric distinction). Categories not covered could be added as needed. 8) I agree that external libs (qhull, etc.) should not be deep in the tree. 9) All the main toolboxes should go together under one directory, not hanging off the root. 10) Some scripts rely on external applications. It would be nice to be able to test for these at install time, and maybe set some global variables in the startup scripts to indicate the appropriate application. 11) Where to put mex and eng interfaces? contrib? main? support? 12) Here's what I propose for the project tree. Note that I have included most projects that I know of, though their principals may not be interested in joining us. Most people should just need main, and maybe some of the libraries from lib. + main <mainstream octave toolboxes all using octave conventions> | + FIXES <modified octave functions> | + audio <contains scripts and any data required for normal function> | | + doc <docs giving overview of toolbox> | | + test <test scripts for all functions in toolbox> | | + demo <minimal installation may want to exclude demos since required data files can be large> | | + dld <C/C++/Fortran code, but not external libs; script equivalents for the dld challenged> | + communications | + control | + finance | + general | + identification | + image | + linear-algebra | + miscellaneous | + optimization | + plot | + polynomial | + set | + signal | + sparse | + specfun | + special-matrix | + splines | + statistics | + strings | + struct | + symbolic | + system | + time + contrib <limited interest/experimental toolboxes> | + misc | + civil | + fake-sparse | + matcompat <aliases for other functions, provided for compatibility> | + testfun <needs work> + extern <toolboxes developed for matlab; link to original; distribute as tarball+patch+build/install/clean scripts> | + ode <until it is converted to octave conventions> | + integration <until it is converted to octave conventions> | + tsa <time series analysis toolbox> | + epstk <direct to postscript graphing> + graphics <various replacements for gnuplot, or for the command line> | + tk_octave | + plplot | + vrml | + vtk | + superficie | + goctave + lib <external libs; distribute as tarball+patch+build/install/clean scripts; link to original> | + qhull <for geometry toolbox> | + SuperLU <for sparse toolbox> | + GiNaC <for symbolic toolbox> | ? GSL <GNU scientific library> | ? snack <for multi-platform audio support> | ... + doc | + Joao Cardoso's Octave digest | + Doug Eck's oct-file FAQ | + Christoph Spiel's oct-file tutorial | + Paul Kienzle's compatibility database | + Various project docs + support | + mex <support for matlab mex interface; currently dld/mex> | + engine <use octave as compute engine; currently dld/liboct> | + oct2mat <deoctavate scripts for use in matlab> | + Etienne Grossman's dependencies resolver + nonfree <for purists; mirrors top-level structure> | + lib | + main | | + spline <noncommercial use only> | + contrib | + extern | | + wavelab <wavelet toolbox; must be distributed in its entirety> | | + testmatrix <test matrices; must be distributed in its entirety> | | + spctools <speech/signal processing; noncommercial use only> Paul Kienzle pki...@sf... On Thu, May 17, 2001 at 03:54:07PM -0500, Matthew W. Roberts wrote: > On Wed, May 16, 2001 at 08:52:59AM +0100, Paul Kienzle wrote: > > The whole project needs to be purged and a new CVS tree put in > > place having the structure we want, and clear instructions on > > where to put new files and directories. ... > > Agreed. There have been several discussions in the past on the > directory structure: > > http://www.geocrawler.com/archives/3/3262/2001/2/0/ > http://lists.sourceforge.net/archives/octave-dev/2000-October/thread.html > http://lists.sourceforge.net/archives/octave-dev/2000-November/thread.html > > Personally, I would prefer to base the directories on a toolbox-type > layout with each toolbox having its own directory. That way we can > easily package toolboxes independently for distribution. > > BTW, for those that may have missed it, sourceforge has secured the > sf.net domain. So an easier way to get to the home page is: > > http://octave.sf.net/ > > > > -- > Matthew W. Roberts > ------------------------------------------------------------------ > Structural Engineering * Texas A&M University * ma...@ta... > > _______________________________________________ > Octave-dev mailing list > Oct...@li... > http://lists.sourceforge.net/lists/listinfo/octave-dev > |
|
From: Matthew W. R. <ma...@ne...> - 2001-05-23 11:56:38
|
> Wow! You exist! Working on Octave I know can be very > disheartening. Few people join in and collaborate on anything. > Oh, well. Well, it's not so much that I'm disheartened. My Committee chair is retiring in December and I'm trying to get my Dissertation cranked out by then. I've been forced to use Matlab, unfortunately, in my research because of some of Octave's limitations with structures (can't save them, can't have arrays of structures). I was considering trying to finish up `in absentia', but then I found out how much it would cost to get a licensed version of Matlab. Eeek! Since then I've been racking my brain trying to figure out a way to start a company based on Octave. From what I've seen with Eazel, Corel Linux, Stormix, et al, I'm not sure an open source company can survive. Thanks for your comments. Some specific replies: > 2) ... Support for independent packaging is not appropriate at > the moment since the toolboxes are mostly tiny (except signal and > image) and enthusiasm is low. I agree. However, we should still set up the directory structure with packaging in mind. > How about we put a hard limit of 5 Mb total main tree size before > we worry about separate packaging? Sounds good to me. > 6) Functions should not require patched versions of Octave or > gnuplot to run. Definitely agree. I like your directory structure. The main tree is for additions to the standard octave distribution, right? -- Matthew W. Roberts ------------------------------------------------------------------ Structural Engineering * Texas A&M University * ma...@ta... |
|
From: Julian A. de M. Ph.D <ju...@ma...> - 2001-05-18 01:01:58
|
Personally, I would prefer to base the directories on a toolbox-type layout with each toolbox having its own directory. That way we can easily package toolboxes independently for distribution. >> I totally agree with you 100%. - Jules |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X