File I/O patches

18 views
Skip to first unread message

Luke-Jr

unread,
Nov 3, 2011, 8:43:55 PM11/3/11
to Todd Sundsted, MOO Talk
I've cleaned up File I/O a bit. Since you seem to be the new de facto
maintainer, I thought it would be a good idea to send you the patches.
You *should* be able to apply these to your Stunt with 'git am <x>.patch', but
there might be some non-trivial merging necessary.

I also noticed your Stunt branch is not based on/cloned from the main
LambdaMOO git repository, and thus cannot be simply merged with repositories
that are. Is this intentional?

Luke

0003-Integrate-File-I-O-extension-into-the-server-distrib.patch
0002-Update-File-I-O-documentation-filename-and-remove-ol.patch
0001-indentation-normalization.patch

Luke-Jr

unread,
Nov 3, 2011, 8:51:32 PM11/3/11
to Todd Sundsted, MOO-...@googlegroups.com
On Thursday, November 03, 2011 8:43:55 PM Luke-Jr wrote:
> I've cleaned up File I/O a bit. Since you seem to be the new de facto
> maintainer, I thought it would be a good idea to send you the patches.
> You *should* be able to apply these to your Stunt with 'git am <x>.patch',
> but there might be some non-trivial merging necessary.

Oops, attached an OLD VERSION of the 0003 patch. Current one attached.

0003-Integrate-File-I-O-extension-into-the-server-distrib.patch

Todd Sundsted

unread,
Nov 3, 2011, 9:09:02 PM11/3/11
to MOO Talk
Thanks!

I started with the latest code on SourceForge because I was not sure
of the status of the LambdaMoo project on GitHub. At one point I
diff'd the latest of both and convinced myself that they were
identical -- though the commits/revisions do not line up between the
Git/SVN repos -- I don't know what's up with that. In hindsight it
was probably not the way to go...

Todd
>  0003-Integrate-File-I-O-extension-into-the-server-distrib.patch
> 7KViewDownload
>
>  0002-Update-File-I-O-documentation-filename-and-remove-ol.patch
> 1KViewDownload
>
>  0001-indentation-normalization.patch
> 82KViewDownload

Luke-Jr

unread,
Nov 3, 2011, 10:03:46 PM11/3/11
to MOO-...@googlegroups.com, Todd Sundsted
On Thursday, November 03, 2011 9:09:02 PM Todd Sundsted wrote:
> I started with the latest code on SourceForge because I was not sure
> of the status of the LambdaMoo project on GitHub. At one point I
> diff'd the latest of both and convinced myself that they were
> identical -- though the commits/revisions do not line up between the
> Git/SVN repos -- I don't know what's up with that. In hindsight it
> was probably not the way to go...

Any chance you'd be interested in recreating your Stunt branch the "right
way", so perhaps we could collaborate a bit more/closer?

https://github.com/wrog/lambdamoo/network is looking pretty :)

Todd Sundsted

unread,
Nov 10, 2011, 1:10:57 PM11/10/11
to MOO Talk
If wrog or someone would tag and release 1.8.4 I'd do so in a minute,
especially if it were the Github version that were so blessed.

Todd

Todd Sundsted

unread,
Nov 10, 2011, 1:12:21 PM11/10/11
to MOO Talk
I see your point, however.

Todd

On Nov 3, 9:03 pm, "Luke-Jr" <l...@dashjr.org> wrote:

Luke-Jr

unread,
Nov 10, 2011, 1:43:17 PM11/10/11
to MOO-...@googlegroups.com
On Thursday, November 10, 2011 1:10:57 PM Todd Sundsted wrote:
> If wrog or someone would tag and release 1.8.4 I'd do so in a minute,
> especially if it were the Github version that were so blessed.

The GitHub version (unfortunately-- I wish it were Gitorious) *is* by wrog.
Why does he have to tag it?

Note that I don't mean rebasing your code on the latest master. All bugfixes
(and ideally all features) should be branched from the earliest point that
makes sense (in the case of bugfixes, from the point the bug was introduced),
and then merged into the relevant "real world usage" branch.

Examples in GammaMOO branches:
- 'autoconf' (feature: upgraded autoconf support) is based on a commit from
2008 when .gitignore was last updated (in mainline), the earliest possible
commit where it still merges cleanly with the latest LambdaMOO HEAD.
- 'bit_operators' (feature: bitwise/bitshift operators) is based on a commit
from early 2010, when value_to_literal got replaced with unparse_value
(which is used for the implementation).
- 'bugfix_uninitialized_cmd_history' is based on the initial import back in
1997 because the bug has been there at least that long. It still merges
cleanly with the current LambdaMOO HEAD, as well as any other git tree based
on this import, no matter how backdated or old.
- 'scattering_for' is my own (cleaner IMO) rewrite of the classic scattering
for syntax change. While it is a feature, I was able to build it on the 1997
import as well, and it still merges cleanly with HEAD.
- 'fileio' was real fun. For historical purposes, I found the probable commit
File I/O would have logically been based on originally, and reconstructed
each change since the original 1.0 patch individually based on the ChangeLog
later introduced in 1.5p1, and the timestamps of files in the tarballs.
I was also careful to use --author to correctly attribute the original
authors of each change (with updated names/emails from GitHub). When I got
caught up to 1.5p1, I observed that you had taken over de-facto maintenance,
and that you had these changes in your own git repository. Since it was
incompatible, I used 'git format-patch' to pick out the relevant commits and
'git am' to cherry-pick them into my own 'fileio' branch. Only once I was
completely caught up with the current state of things, did I then go add my
own fixes and enhancements in new branches, which enabled me to send you the
patches which should apply cleanly to your Stunt branch(es).

Todd Sundsted

unread,
Nov 10, 2011, 4:10:24 PM11/10/11
to MOO Talk
Someone declaring "version 1.8.4" would clarify for me where the
future of LambdaMOO is (if there is going to be a future) and who's
driving the bus. That's not the _only_ reason I'd re-release my
branch, but it would be the strongest incentive.

Interestingly, I based my version off the latest commits in
sourceforge, which were also by wrog and add up to the same final
state as those on Github, even though the commits themselves differ.

Todd

Paulo A Ferreira

unread,
Nov 15, 2011, 5:44:36 AM11/15/11
to MOO-...@googlegroups.com
As you are all talking about patches and future :-) I just want a way
that in #0:do_login_command I can open a network connection to an
external authentication system. As 1.8.3 if I used a read() even for
this other external connection it doesn't associate the player
connection with the player object returned.

Thanks in advance ;-)

Paulo

Luke-Jr

unread,
Nov 15, 2011, 9:59:27 AM11/15/11
to MOO-...@googlegroups.com
On Tuesday, November 15, 2011 5:44:36 AM Paulo A Ferreira wrote:
> As you are all talking about patches and future :-) I just want a way
> that in #0:do_login_command I can open a network connection to an
> external authentication system. As 1.8.3 if I used a read() even for
> this other external connection it doesn't associate the player
> connection with the player object returned.

Workaround: store the negative-connection-number and authentication token in a
property, and force_input the neg-conn-num to check it.

ie,
$network.connect_connections_to = {@$network.connect_connections_to,
{connection, connect_to}};
force_input(connection, "", 1);

Todd Sundsted

unread,
Nov 15, 2011, 6:31:31 PM11/15/11
to MOO Talk
Any command which suspends the login task effectively foils the
association of a player with the connection. Internally, the verb
"returns" control back to the server with the read/suspend. It would
be possible to identify which task was created, and do the work when
it exits, but it would not be trivial. I had the same problem but
opted to add a built-in that effectively accomplished the same thing.
Details shortly...

Todd

Luke-Jr

unread,
Nov 15, 2011, 6:37:33 PM11/15/11
to MOO-...@googlegroups.com
On Tuesday, November 15, 2011 6:31:31 PM Todd Sundsted wrote:
> Any command which suspends the login task effectively foils the
> association of a player with the connection. Internally, the verb
> "returns" control back to the server with the read/suspend. It would
> be possible to identify which task was created, and do the work when
> it exits, but it would not be trivial. I had the same problem but
> opted to add a built-in that effectively accomplished the same thing.
> Details shortly...

Old GammaMOO had a function to reconnect a player (ie #-4 to #2, or even #2 to
#500).

Todd Sundsted

unread,
Nov 15, 2011, 6:43:12 PM11/15/11
to MOO Talk
The latest code for Stunt includes a builtin called
`switch_player()'. It explicitly associates a connection with a
player object. I started with an existing patch (props shortly) and
made a few modifications. Some version of this will absolutely be
part of Stunt, but right now it's *experimental* only -- there may be
risks to using this that I don't see.

Todd

Todd Sundsted

unread,
Nov 15, 2011, 7:18:11 PM11/15/11
to MOO Talk
And the starting point for the builtin was:

http://zanosoft.net/rsgames/moo-switchcon/

Props to Ryan Smith.

Todd

Steve Wainstead

unread,
Nov 27, 2011, 7:53:01 PM11/27/11
to MOO-...@googlegroups.com
On that note, I've been thinking of volunteering to maintain File I/O (if Todd is not interested).

I'd set up a new repository for it on github (and gitorious, as demand warrants), start with 1.5p1 (the last version, according to the previous maintainer, Andy Bakun; I traded emails with him back in June) and apply the patches so there's an audit trail in git.

I think my small contribution would be example usages of all methods, since I had to puzzle it out myself a while back and I took notes.

~swain

> --
> You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> To post to this group, send email to MOO-...@googlegroups.com.
> To unsubscribe from this group, send email to MOO-talk+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.
>

Luke-Jr

unread,
Nov 27, 2011, 8:10:37 PM11/27/11
to MOO-...@googlegroups.com, Steve Wainstead, Todd Sundsted
On Sunday, November 27, 2011 7:53:01 PM Steve Wainstead wrote:
> On that note, I've been thinking of volunteering to maintain File I/O (if
> Todd is not interested).

I consider Todd to be the de facto File I/O maintainer at the moment.

> I'd set up a new repository for it on github (and gitorious, as demand
> warrants), start with 1.5p1 (the last version, according to the previous
> maintainer, Andy Bakun; I traded emails with him back in June) and apply
> the patches so there's an audit trail in git.

I've already done a proper git import of File I/O (including splitting the
older versions across multiple commits best I could figure from the
changelog), and applied Todd's more recent changes on top of that:
https://github.com/luke-jr/gammamoo/commits/fileio
I also did some cleanup, which I sent to Todd as patches (I haven't checked to
see if he merged them yet):
https://github.com/luke-jr/gammamoo/commits/fileio_cleanup
After that, I updated the branch to merge cleanly with the new
server_version_full() framework (in the 1.8.3-in-progress):
https://github.com/luke-jr/gammamoo/commits/fileio_version_merge
And then I updated to the new stream-based raw byte handling code (another
upstream LambdaMOO change):
https://github.com/luke-jr/gammamoo/commits/fileio_update
Finally, I ported my old "File I/O Logger" mode (append-once logs):
https://github.com/luke-jr/gammamoo/commits/fileio_logger

These are all merged into GammaMOO:
https://github.com/luke-jr/gammamoo/commits/gammamoo
As part of GammaMOO, it has had a few weeks of proven testing. Do note,
however, that I *only* have the Logger mode enabled/used in my MOO, so I can't
vouch for the non-logger code (but it is basically without any substantial
changes)

Todd Sundsted

unread,
Nov 27, 2011, 11:06:03 PM11/27/11
to MOO Talk
I have no problem at all with handing over the reins. The more people
actively involved and coding, the better the environment will be for
all of us IMHO. Steve, if you do take up maintenance, take a look at
what Luke-Jr has done -- I'd planned on rolling most/all of it in.
Other than bug fixing, I don't plan on extending it further right now
(although I'd love to make the whole thing non-blocking at some point
down the road).

Todd

Luke-Jr

unread,
Nov 27, 2011, 11:08:53 PM11/27/11
to MOO-...@googlegroups.com, Todd Sundsted
On Sunday, November 27, 2011 11:06:03 PM Todd Sundsted wrote:
> (although I'd love to make the whole thing non-blocking at some point
> down the road).

On that note, it might be interesting to allow opening files as MOO sockets
(ie, negative object numbers) and using notify/read on them ;)

Steve Wainstead

unread,
Nov 27, 2011, 11:24:18 PM11/27/11
to MOO Talk
It was Luke's patches that reignited my interest in doing the maintenance! I will certainly include them.

I'll post when I have the thing up.
~swain

Luke-Jr

unread,
Nov 28, 2011, 12:29:41 AM11/28/11
to MOO-...@googlegroups.com, Steve Wainstead
On Sunday, November 27, 2011 11:24:18 PM Steve Wainstead wrote:
> It was Luke's patches that reignited my interest in doing the maintenance!
> I will certainly include them.

I would encourage just branching from my fileio_logger branch:
https://github.com/luke-jr/gammamoo/commits/fileio_logger
... and working on it from there. Then your branch will cleanly merge into
LambdaMOO and GammaMOO, at least.

Luke

Paulo A Ferreira

unread,
Nov 29, 2011, 10:49:48 AM11/29/11
to MOO-...@googlegroups.com


I implemented with force_input(). After the remote authentication a
token is created and I use force_input to "co player token"

Reply all
Reply to author
Forward
0 new messages