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
Oops, attached an OLD VERSION of the 0003 patch. Current one attached.
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 :)
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).
Thanks in advance ;-)
Paulo
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);
Old GammaMOO had a function to reconnect a player (ie #-4 to #2, or even #2 to
#500).
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.
>
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
On that note, it might be interesting to allow opening files as MOO sockets
(ie, negative object numbers) and using notify/read on them ;)
I'll post when I have the thing up.
~swain
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
I implemented with force_input(). After the remote authentication a
token is created and I use force_input to "co player token"