Lyntin

I'm in the process of overhauling all the commands in basic.py and 
advanced.py to use Josh's new argparser code which should fix a whole lot 
of the argument parsing issues you mention.

Lyntin 3.0 is a total rewrite from the ground up and we're still at the 
point where we're trying to get the internals correctly architected and 
programmed.  So while I'd like a scheduler (and it's on the list and I 
remember when it was written for Lyntin originally), it's not something 
I'm going to add until things stabalize a lot.  We do have the ticker 
thread, and someone could easily implement a scheduler as a module with 
the existing codebase.

In regards to the todo list in the lyntin cvs module, that list is a list 
of things I wanted to do to the old code-base prior to deciding to rewrite 
everything from scratch.  In the rewrite, many of the items have been and 
are being addressed.  So that's cool.

The #logging command is implemented as it was specified.

In regards to commands to set length of data buffer, history, etc, this
all falls in the realm of the new #config command and system.  It's on the
list of things to overhaul.

You keep asking what I want you to code and I don't have answers because
I'm working on my list of things to do to get things stabilized--I'm not
really prepared to manage a project with multiple developers by handing
out tasks and coordinating events.  If you're into coding why don't you
fix some of the things you're noticing and send in diffs.

The way to do it would be do a cvs update, then make your changes, then do
a cvs diff and send me the results of that cvs diff.

Also, we created a new mailing list called lyntin-cvs.  When we check 
things into the cvs repository an email is sent to lyntin-cvs with the 
diff and the checkin comments.  This is pretty useful if you want to be 
kept abreast of what's happening development-wise.

/will


-- 
whatever it is, you can find it at http://www.bluesock.org/~willg/
except Will--you can only see him in real life.

hi will,

- speedwalk.py should use self._regexp.match(), not self._regexp.search() -
  would be slightly faster i think, and a bit cleaner.
- included is a patch to the testserver, allowing to append new commands
  faster.
- in modules/basic.py, textin_cmd(), the code tries to fetch
  'args["filename"]', but in the command_dict the entry is only "file", so
  an exception is thrown by python.
- in speedwalk.py you should change 'swdirs.append(self._dirs[dir])' +
  'return "\n".join(swdirs)' with 'swdirs.append(self._dirs[dir] + "\n")' +
  'return "".join(swdirs)', because currently it doesn't send a trailing
  newline char, the last command won't be executed.

Sebastian.


-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

On Fri, 3 May 2002, Sebastian John wrote:
> - speedwalk.py should use self._regexp.match(), not self._regexp.search() -
>   would be slightly faster i think, and a bit cleaner.

Done.


> - included is a patch to the testserver, allowing to append new commands
>   faster.

I think you missed the attachment.  I'm not sure how you would append new 
commands faster since I've got it doing it in one line.


> - in modules/basic.py, textin_cmd(), the code tries to fetch
>   'args["filename"]', but in the command_dict the entry is only "file", so
>   an exception is thrown by python.

Done.


> - in speedwalk.py you should change 'swdirs.append(self._dirs[dir])' +
>   'return "\n".join(swdirs)' with 'swdirs.append(self._dirs[dir] + "\n")' +
>   'return "".join(swdirs)', because currently it doesn't send a trailing
>   newline char, the last command won't be executed.

Are you sure?  It works fine for me right now.  I double-checked even that 
all the commands I was feeding the speedwalking stuff were getting 
executed.  I know that if I implement this fix we'll be sending two \n's 
to the mud.

/will


-- 
whatever it is, you can find it at http://www.bluesock.org/~willg/
except Will--you can only see him in real life.