You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(2) |
Oct
(4) |
Nov
|
Dec
|
---|
From: Dave D. <dw...@be...> - 2002-10-14 16:19:32
|
Great, thank you very much! - Dave Dykstra On Mon, Oct 14, 2002 at 05:44:45PM +0200, Tobias Polzin wrote: > > Thank you for being willing to do as much as you did. > > Today, we decided to change our name to explab. > > > It's quite maddening > > that sourceforge makes it so difficult to change a project name. > > When you start a project, they explicitly warn you about that. > It's a complex system with a rich functionality. It's obvious > that there have to be some restrictions. > > > I haven't > > dealt very much with sourceforge, but it sounds like the web interface is > > only set up to request certain small changes. > > Well, I like the interface a lot. For many things that you typically have > to do, it's practical and although the functionality is complex, dealing > with it is quite intuitive. But changing the name is obviously not > a "typical thing to do". :-) > > > Is there a way to just > > explain what it is you want to do? Perhaps the support staff would do it > > for you if you described it, and maybe they'd be more willing if you told > > them why you needed it done. Tell them if you look up the exptools name > > on freshmeat.net it lists my project. > > I asked them once again for some help. If they can't do it, we will do it > "by hand". I will not be too much work, compared to the time > we have been spend discussing about the name change :-) > > Tobias Polzin > -- > Tobias Polzin, Max-Planck-Institut f?r Informatik > Stuhlsatzenhausweg 85, 66123 Saarbr?cken > Email: po...@mp... > Phone: +49-681-9325-122 Fax: +49-681-9325-199 |
From: Tobias P. <po...@mp...> - 2002-10-14 15:45:06
|
> Thank you for being willing to do as much as you did. Today, we decided to change our name to explab. > It's quite maddening > that sourceforge makes it so difficult to change a project name. When you start a project, they explicitly warn you about that. It's a complex system with a rich functionality. It's obvious that there have to be some restrictions. > I haven't > dealt very much with sourceforge, but it sounds like the web interface is > only set up to request certain small changes. Well, I like the interface a lot. For many things that you typically have to do, it's practical and although the functionality is complex, dealing with it is quite intuitive. But changing the name is obviously not a "typical thing to do". :-) > Is there a way to just > explain what it is you want to do? Perhaps the support staff would do it > for you if you described it, and maybe they'd be more willing if you told > them why you needed it done. Tell them if you look up the exptools name > on freshmeat.net it lists my project. I asked them once again for some help. If they can't do it, we will do it "by hand". I will not be too much work, compared to the time we have been spend discussing about the name change :-) Tobias Polzin -- Tobias Polzin, Max-Planck-Institut für Informatik Stuhlsatzenhausweg 85, 66123 Saarbrücken Email: po...@mp... Phone: +49-681-9325-122 Fax: +49-681-9325-199 |
From: Dave D. <dw...@be...> - 2002-10-02 14:31:44
|
Thank you for being willing to do as much as you did. It's quite maddening that sourceforge makes it so difficult to change a project name. I haven't dealt very much with sourceforge, but it sounds like the web interface is only set up to request certain small changes. Is there a way to just explain what it is you want to do? Perhaps the support staff would do it for you if you described it, and maybe they'd be more willing if you told them why you needed it done. Tell them if you look up the exptools name on freshmeat.net it lists my project. - Dave Dykstra On Wed, Oct 02, 2002 at 11:24:20AM +0200, Tobias Polzin wrote: > > Hi Dave, > > you asked us to change the name of our "exptools" package. > We discussed the topic and thought of a different name. > The problem is that is nearly impossible to change > the name of a sourceforge project. The only possibility > is to open a new project and delete the old one. We > already opened one with a different name ("explab") and > were willing to do some effort to transfer the project > data, but then we noticed that it is not possible to > transfer the submitted bugs and feature requests, without > filling out 40 www-forms. So, we give up and stay > with the old name. I hope, you can accept this. > > Regards, > Tobias > > -- > Tobias Polzin, Max-Planck-Institut f?r Informatik > Stuhlsatzenhausweg 85, 66123 Saarbr?cken > Email: po...@mp... > Phone: +49-681-9325-122 Fax: +49-681-9325-199 > |
From: Tobias P. <po...@mp...> - 2002-10-02 09:24:34
|
Hi Dave, you asked us to change the name of our "exptools" package. We discussed the topic and thought of a different name. The problem is that is nearly impossible to change the name of a sourceforge project. The only possibility is to open a new project and delete the old one. We already opened one with a different name ("explab") and were willing to do some effort to transfer the project data, but then we noticed that it is not possible to transfer the submitted bugs and feature requests, without filling out 40 www-forms. So, we give up and stay with the old name. I hope, you can accept this. Regards, Tobias -- Tobias Polzin, Max-Planck-Institut für Informatik Stuhlsatzenhausweg 85, 66123 Saarbrücken Email: po...@mp... Phone: +49-681-9325-122 Fax: +49-681-9325-199 |
From: <no...@so...> - 2002-09-03 13:01:54
|
Bugs item #603969, was opened at 2002-09-03 14:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=603969&group_id=59013 Category: labrun/labmex/labrerun Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Susan Hert (hert) >Assigned to: Tobias Polzin (polzin) Summary: deadlock when too much stderr output Initial Comment: labrun and labmex both use popen2 and wait to capture the output from stderr produced by a command. This unfortunately causes a deadlock when too much output is written to stderr (possibly a bug in Python?). A solution for labmex was to direct the stderr output to a file. Could possibly also work for labrun. ---------------------------------------------------------------------- >Comment By: Tobias Polzin (polzin) Date: 2002-09-03 15:01 Message: Logged In: YES user_id=586666 We now use tmpfiles and a nice class in labutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=603969&group_id=59013 |
From: <no...@so...> - 2002-09-03 12:41:23
|
Bugs item #603969, was opened at 2002-09-03 14:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=603969&group_id=59013 Category: labrun/labmex/labrerun Group: None Status: Open Resolution: None Priority: 2 Submitted By: Susan Hert (hert) Assigned to: Nobody/Anonymous (nobody) Summary: deadlock when too much stderr output Initial Comment: labrun and labmex both use popen2 and wait to capture the output from stderr produced by a command. This unfortunately causes a deadlock when too much output is written to stderr (possibly a bug in Python?). A solution for labmex was to direct the stderr output to a file. Could possibly also work for labrun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=603969&group_id=59013 |
From: <no...@so...> - 2002-08-30 15:23:51
|
Feature Requests item #602470, was opened at 2002-08-30 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=602470&group_id=59013 Category: Documentation Group: Near Future Status: Open Resolution: None Priority: 4 Submitted By: Tobias Polzin (polzin) Assigned to: Nobody/Anonymous (nobody) Summary: sus-tools-demo with correct filenames Initial Comment: The commands in sus-tools-demo do not give the correct filenames. Perhaps again differenciate between an ONLINE run and a BATCHED run of sus-tools-demo for ./demo2tex. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=602470&group_id=59013 |
From: <no...@so...> - 2002-08-26 09:04:24
|
Bugs item #591477, was opened at 2002-08-06 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=591477&group_id=59013 Category: labrun/labmex/labrerun Group: v0.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tobias Polzin (polzin) Assigned to: Nobody/Anonymous (nobody) Summary: labrun does not log segmentation faults Initial Comment: "Segmentation fault" messages are not printed to stdout or stderr. As a consequence they are not reported in the log-file. ---------------------------------------------------------------------- >Comment By: Tobias Polzin (polzin) Date: 2002-08-26 11:04 Message: Logged In: YES user_id=586666 errorlevel 139 will now be commented with (Segmentation fault) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=591477&group_id=59013 |
From: <no...@so...> - 2002-08-23 09:31:27
|
Bugs item #591237, was opened at 2002-08-05 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=591237&group_id=59013 Category: labrun/labmex/labrerun Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Susan Hert (hert) Assigned to: Nobody/Anonymous (nobody) Summary: NEX + labmex may remove running program Initial Comment: When multiple experiments are used, each of which should compile a single program in a single directory, on processes make may remove and then write over an executable being used by another process. ---------------------------------------------------------------------- >Comment By: Susan Hert (hert) Date: 2002-08-23 11:31 Message: Logged In: YES user_id=587148 -batch option now is handled differently to avoid two processes overwriting each other. ---------------------------------------------------------------------- Comment By: Tobias Polzin (polzin) Date: 2002-08-14 17:13 Message: Logged In: YES user_id=586666 This is mainly a problem of "--batch" . Also for other situations it could be better if the behaviour of --batch with NEX is changed: the NEX is processed after the command has finished. Perhaps this is possible with some reordering in the usage of os.fork. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=591237&group_id=59013 |
From: <no...@so...> - 2002-08-19 11:37:35
|
Feature Requests item #597100, was opened at 2002-08-19 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=597100&group_id=59013 Category: labrun/rerun/mex Features Group: Near Future Status: Open Resolution: None Priority: 2 Submitted By: Tobias Polzin (polzin) Assigned to: Nobody/Anonymous (nobody) Summary: verbosity of tools Initial Comment: Overall I find the default behaviour of the tools to "quiet". There are a lot of things done, and without -v you see nothing. You can use the ~/.labrc to turn on verbosity, but the default is not so good. I would suggest (an additional switch :-)): -q --quiet for silent behaviour (similar to the current default) -v --verbose for more detailed output ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=597100&group_id=59013 |
From: <no...@so...> - 2002-08-14 15:13:53
|
Bugs item #591237, was opened at 2002-08-05 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=591237&group_id=59013 Category: labrun/labmex/labrerun Group: None Status: Open Resolution: None Priority: 7 Submitted By: Susan Hert (hert) Assigned to: Nobody/Anonymous (nobody) Summary: NEX + labmex may remove running program Initial Comment: When multiple experiments are used, each of which should compile a single program in a single directory, on processes make may remove and then write over an executable being used by another process. ---------------------------------------------------------------------- >Comment By: Tobias Polzin (polzin) Date: 2002-08-14 17:13 Message: Logged In: YES user_id=586666 This is mainly a problem of "--batch" . Also for other situations it could be better if the behaviour of --batch with NEX is changed: the NEX is processed after the command has finished. Perhaps this is possible with some reordering in the usage of os.fork. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489603&aid=591237&group_id=59013 |
From: <no...@so...> - 2002-08-14 10:34:09
|
Feature Requests item #594993, was opened at 2002-08-14 12:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=594993&group_id=59013 Category: labrun/rerun/mex Features Group: Near Future Status: Open Resolution: None Priority: 6 Submitted By: Tobias Polzin (polzin) Assigned to: Nobody/Anonymous (nobody) Summary: labrerun: restart something different Initial Comment: I would like to be able to "restart" an experiement with little changes. I would like labrerun to extract a command line file, then I would call an editor, then labrun is stated. Perhaps a workaround would be an additional script (or a switch of labrerun) which does this. Then one stay with the current "print". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=594993&group_id=59013 |
From: <no...@so...> - 2002-08-14 09:11:13
|
Feature Requests item #594971, was opened at 2002-08-14 11:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=594971&group_id=59013 Category: labrun/rerun/mex Features Group: Near Future Status: Open Resolution: None Priority: 5 Submitted By: Tobias Polzin (polzin) Assigned to: Nobody/Anonymous (nobody) Summary: process ID Initial Comment: It would be nice, if one could figure out the PID of a running experiment (labrun with --batch), in case one wants to kill the program. Perhaps a PID of the labrun process could be enough. But I am not sure whether killing the labrun is enough to kill the process. Figuring out the PID of the experiment could be difficult, if not impossible (labrun labmex runsave.py ...). But anyway, it should be easy to guess the right PID of the experiment from the PID of the labrun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=489606&aid=594971&group_id=59013 |
From: Susan H. <he...@mp...> - 2002-08-01 16:26:43
|
Hi, I'm compiling the appendix of "other useful commands" and so far have come up with only the command to record the graphics board and the commands for recording more cache information. Are there other things any you can think of right now that should be included here? Susan |
From: Tobias P. <po...@gm...> - 2002-07-31 15:16:49
|
Okay, we are moving to sourceforge. What you have to do: - If you are not user of sourceforge by now: register https://sourceforge.net/account/register.php - The CVS root changes to: -d:ext:{your sf name}@cvs.exptools.sourceforge.net:/cvsroot/exptools The module is now called "exptools" (not "exp" as before) (the old CVS dir removed, the new one is not yet working) - If you want to work with cvs without the need of entering your password, you may enter ~/.ssh/id_*.pub at http://sourceforge.net/account/editsshkeys.php (it takes some time until the keys are working) - If you want to have look at the "Feature Requests", they are here: https://sourceforge.net/tracker/index.php?group_id=59013&atid=489606 - The web page for the project (that has to be updated) is at http://exptools.sourceforge.net - We have a mailinglist for developers and one for announces. You may send to exp...@li... to reach all the millions of developers out there. To the good or the bad, these messages are put into an archive at Geocrawler. That's all for now... Tobias |