TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

Unusual #map write-to-file behaviour

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
tangobravo



Joined: 02 Jan 2010
Posts: 37
Location: TorilMUD

PostPosted: Mon Aug 09, 2010 9:15 am    Post subject: Unusual #map write-to-file behaviour Reply with quote

*Finally* had a chance to update my TinTin install and try and put it through its paces (jumped from 2.0.1 to 2.0.3)... there seems to be something odd with the map write-to-file function.

In prior versions, binding the #event {MAP ENTER ROOM} to something like {#map map write 88x23 map.txt} would cause the map written to file to update every time the client fired that event, appending it to the map.txt file so it could be used with 'tail -f map.txt' in another screen split or terminal window. Now, this seems to actually overwrite the prior output, making tail sense that something has been changed.. but gives 1 of 3 results:

1. A single line is output to the display
2. NOTHING is output to the display
3. A terminal error indicating: tail: map.txt: file truncated

Any thoughts?

P.S., LOVE all the new updates, Scandum.. Still the best MUD client in existence =) Keep up all the killer work!! Thumbs Up Can't wait to play around with more of the new features, and optimize alot of my old scripts...
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Mon Aug 09, 2010 5:37 pm    Post subject: Reply with quote

People were having issues with the map file growing increasingly big so I disabled the appending behavior.

Easiest is probably to write your own tailer in tt++:

Code:

#var oldfile {}

#nop #delay {0.5} {tail}

#alias {tail}
{
    #script {newfile} {ls -l map.txt};
   
    #if {"$oldfile[1]" != "$newfile[1]"}
    {
        #var {oldfile} {$newfile};
        #scan map.txt;
        #buffer end
    };
    #delay {0.5} {tail}
}


Back to top
View user's profile Send private message Send e-mail
tangobravo



Joined: 02 Jan 2010
Posts: 37
Location: TorilMUD

PostPosted: Tue Aug 10, 2010 10:01 am    Post subject: Reply with quote

Thanks for the rely, Scandum -- you are on top of things, as always! Big Smile

Hmmmm... I guess I never considered that a problem any more than maintaining my regular log files and communications capturing #line log actions... My map.txt I always just cleared on a daily basis with a cron function =)

Honestly, writing the TinTin-based tail function seems like an unnecessary use of system resources to require a constant tick'ing of those commands... As more of an idea/feature request, do you think it'd be possible to do this as a #config flag? or maybe the way the #log function does (i.e., #map map {write} {size} {append | overwrite}) ?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue Aug 10, 2010 3:05 pm    Post subject: Reply with quote

Either is an option.

I'm wondering if tail -F <filename> works on Linux?
Back to top
View user's profile Send private message Send e-mail
tangobravo



Joined: 02 Jan 2010
Posts: 37
Location: TorilMUD

PostPosted: Tue Aug 10, 2010 5:18 pm    Post subject: Reply with quote

Hmm.... would / should that be different than the 'tail -f <filename>' that I use already? Not sure what the capital 'F' would denote.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue Aug 10, 2010 8:12 pm    Post subject: Reply with quote

From tail --help:

Code:

  -F                       same as --follow=name --retry
      --retry              keep trying to open a file even when it is or
                             becomes inaccessible; useful when following by
                             name, i.e., with --follow=name


I don't think tail -F will work though.

One option is to run tail -f within tintin++ with a trigger to scan and show the map file.

Code:

#run tail tail -f map.log

#config {verbose on}

#act {UPDATE MAP} {#scan map.txt}


And in the map event you'd use:
Code:

#event {MAP ENTER ROOM}
{
    #map map 80x25 map.txt;
    #line log map.log UPDATE MAP
}
Back to top
View user's profile Send private message Send e-mail
tangobravo



Joined: 02 Jan 2010
Posts: 37
Location: TorilMUD

PostPosted: Tue Aug 10, 2010 11:53 pm    Post subject: Reply with quote

Yeah, -F made no difference... results are the same. I'm guessing this is because it is operating the same as -f, because the 'retry' interval timing would have to land directly during the overwrite function.

Running tail within TinTin somewhat defeats my purposes, unfortunately, because then I can't be following it within the tmux / gnuscreen split area I utilize (Vertical split, containing another horizontal split seperating my comms log along with map.txt output)

I found the change made that altered the function from 'append' to 'overwrite' in the code, and reverted it for my particular build - works good enough for me for now =) Now having fun playing with some of the other awesome new features... Thanks again, Scandum!
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Wed Aug 11, 2010 7:08 am    Post subject: Reply with quote

Sounds good. Next release you can use: #map map 80x25 map.txt {a}

The 'a' will make it append.
Back to top
View user's profile Send private message Send e-mail
tangobravo



Joined: 02 Jan 2010
Posts: 37
Location: TorilMUD

PostPosted: Mon Oct 10, 2011 2:05 pm    Post subject: Reply with quote

Hey Scandum --

After quite a furlough from Mudding, I'm just getting back into my mud of choice.. and ran into this problem again. Did the 'append' function ever make it into the version? (i.e., #map map <size> {a})
Back to top
View user's profile Send private message
tangobravo



Joined: 02 Jan 2010
Posts: 37
Location: TorilMUD

PostPosted: Mon Oct 10, 2011 2:26 pm    Post subject: Reply with quote

Ack - nevermind. I'm blind, apparently. The option IS there, both in the Changelog, and in source... just didn't see it in the #map help.

... Just strange that I am suddenly having the same old problem as I originally posted, even though i *am* appending.
Back to top
View user's profile Send private message
tangobravo



Joined: 02 Jan 2010
Posts: 37
Location: TorilMUD

PostPosted: Mon Oct 10, 2011 3:11 pm    Post subject: Reply with quote

Bah -- purely a problem of my own rust from not playing enough in the last year =) My problem was that I had changed my old build of tt++ in the source back to append... and my default config file was simply loading an:

#event {MAP ENTER ROOM} {#map map write <size>}

So even though I was manually putting in my {a} argument, it wasn't sticking because the event code was loading without =)

Now to play with all the new stuff you've put in since I last used it much... keep up the killer work, Scandum! Thumbs Up
Back to top
View user's profile Send private message
karvec



Joined: 16 Jul 2010
Posts: 50

PostPosted: Sat Jan 12, 2013 6:35 pm    Post subject: Reply with quote

Sorry to dig up an old topic, but I was just trying to get tail to do the same thing... I did this to get it to work w/o truncating..

#event {MAP ENTER ROOM}
{#sys rm map.txt;
#map map 80x24 map.txt {a}
}


is that too much disk hashing?
Back to top
View user's profile Send private message
Slysven



Joined: 10 Apr 2011
Posts: 365
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Sat Jan 12, 2013 7:22 pm    Post subject: Reply with quote

Humm, are you tailing with -f or -F and surely the "#sys rm map.txt" should be deleting the old map before you write the new one...

I suppose behaviour may be dependent on the operating and file system specifics - if write caching is taking place it could be confounding things perhaps? To avoid thrashing a real disk you could use virtual disk in memory...? Cool
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Sat Jan 12, 2013 10:40 pm    Post subject: Reply with quote

I probably should change this so it saves it to a variable so you can use netcat and avoid ruining your hard drive.

Which I guess will annoy some people, but so be it.
Back to top
View user's profile Send private message Send e-mail
karvec



Joined: 16 Jul 2010
Posts: 50

PostPosted: Thu Jan 17, 2013 9:29 pm    Post subject: Reply with quote

Solved my problem using a ramdisk...

No disk thrashing necessary! Thanks for the feedback, lemme know when you start sending it to a variable Big SmileBig SmileBig Smile
Back to top
View user's profile Send private message
chosig



Joined: 02 Feb 2012
Posts: 19

PostPosted: Wed Feb 06, 2013 12:53 am    Post subject: Reply with quote

karvec wrote:
#event {MAP ENTER ROOM}
{#sys rm map.txt;
#map map 80x24 map.txt {a}
}



You can use this to empty the file, without destroying and recreating it all the time.
Code:
#event {MAP ENTER ROOM}
 {#sys {echo /dev/null > map.txt};
  #map map 80x24 map.txt {a}
 }

_________________
chosig@Discworld MUD
Back to top
View user's profile Send private message
karvec



Joined: 16 Jul 2010
Posts: 50

PostPosted: Fri Apr 12, 2013 2:01 am    Post subject: Reply with quote

please just do a variable we can netcat scandum... i will love you forever.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group