File I/O patches

Showing 1-21 of 21 messages
File I/O patches lu...@dashjr.org 11/3/11 5:43 PM
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

Re: File I/O patches lu...@dashjr.org 11/3/11 5:51 PM
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.

Re: File I/O patches Todd Sundsted 11/3/11 6:09 PM
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
Re: [MOO-talk] Re: File I/O patches lu...@dashjr.org 11/3/11 7:03 PM
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 :)

Re: File I/O patches Todd Sundsted 11/10/11 10:10 AM
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
Re: File I/O patches Todd Sundsted 11/10/11 10:12 AM
I see your point, however.

Todd

On Nov 3, 9:03 pm, "Luke-Jr" <l...@dashjr.org> wrote:
Re: [MOO-talk] Re: File I/O patches lu...@dashjr.org 11/10/11 10:43 AM
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).

Re: File I/O patches Todd Sundsted 11/10/11 1:10 PM
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
Re: [MOO-talk] Re: File I/O patches Paulo A Ferreira 11/15/11 2:44 AM
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

Re: [MOO-talk] Re: File I/O patches lu...@dashjr.org 11/15/11 6:59 AM
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);

Re: File I/O patches Todd Sundsted 11/15/11 3:31 PM
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
Re: [MOO-talk] Re: File I/O patches lu...@dashjr.org 11/15/11 3:37 PM
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).

Re: File I/O patches Todd Sundsted 11/15/11 3:43 PM
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
Re: File I/O patches Todd Sundsted 11/15/11 4:18 PM
And the starting point for the builtin was:

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

Props to Ryan Smith.

Todd
Re: [MOO-talk] Re: File I/O patches Steve Wainstead 11/27/11 4:53 PM
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.
>

Re: [MOO-talk] Re: File I/O patches lu...@dashjr.org 11/27/11 5:10 PM
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)

Re: File I/O patches Todd Sundsted 11/27/11 8:06 PM
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

Re: [MOO-talk] Re: File I/O patches lu...@dashjr.org 11/27/11 8:08 PM
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 ;)

Re: [MOO-talk] Re: File I/O patches Steve Wainstead 11/27/11 8:24 PM
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

> --
> 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.
>

Re: [MOO-talk] Re: File I/O patches lu...@dashjr.org 11/27/11 9:29 PM
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

Re: [MOO-talk] Re: File I/O patches Paulo A Ferreira 11/29/11 7:49 AM


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

More topics »