index marker in a file

[Dedan]

I am writting a script that will post poems to the channel.
I have 40 poems, ALL in 1 file. They have between 5-20 lines each.
I do not know what index pointer would be best or how to locate it.
I have posted a "test" file at the bottom.

The channel commands will be like !p1 or !p25 or !p37

Thanks for any help given.

Code: Select all

#                       ### Poem Player ####

set poem_file "/home/eggdrop/poems/poemfile"

set poem_chan "#Poem_player_Testing"
set master_poem_mode "1"
set poem_mode "0"
set poem_chan [string tolower $poem_chan]


bind pubm -|- "!p" que:poem

proc que:poem {nick uhost handle channel text} {
  global botnick master_poem_mode poem_chan poem_mode poem_file
  # checks to see if an OP has turned off the player
  if {$master_poem_mode == 0} {return 0}
  # checks to see if the player is already playing
  if {$poem_mode == 1} {return 0}
  # checks to see if the channel is poem channel
  set chan [string tolower $channel]
  if {!($chan == $poem_chan)} {return 0}
  if {![botisop $poem_chan]} {return 0}

  set poem_to_play [lindex [split $text] 0]

  if {[file exists $poem_file]} {
    # set poem_mode 1
    set opened_poem_file [open $poem_file r]


 #      ****** I do NOT know what to do here ******
 # need to look for our index marker to retrive the correct Poem
 # Remember: ALL 40 poems are in the same file with index markers
 # I do not know what kind of index marker would be best,
 # i am open for suggestions


    set poem_timer 1
    while {![eof $opened_poem_file]} {

      set poem_line [gets $opened_poem_file]

      # I am using proc and timer, so the poem can be stopped mid-poem
      utimer $poem_timer [list play:poem $poem_line]

      incr poem_timer 5
    }
    close $poem_file     - or is it -    close $opened_poem_file


    # reset the poem mode so a new poem can be played
    utimer [expr $poem_timer + 5] {set poem_mode 0}
    return 0
  }
  set poem_mode 0
  return 0
}
#                           Play Poem                                #

proc play:poem {poem_line} {
  global master_poem_mode poem_chan
  # I am using this proc and timer, so the poem can be stopped mid-poem
  if {$master_poem_mode == 0} {return 0}
  puthelp "PRIVMSG $poem_chan :$poem_line"
  return 0
}

#                     Master shut-off Switch                         #

# Master shut-off switch, available to ANY OP in Channel
bind pub -|- "!pon" enable:poems
bind pub -|- "!poff" disable:poems

proc enable:poems {nick uhost handle channel} {
  global poem_chan master_poem_mode poem_mode
  if {[isop $nick $poem_chan]} {
    set master_poem_mode "1"
    set poem_mode "0"
    puthelp "PRIVMSG $poem_chan :Type: !p<poem number> to play a Poem"
  }
  return 0
}

proc disable:poems {nick uhost handle channel text} {
  global poem_chan master_poem_mode poem_mode
  if {[isop $nick $poem_chan]} {
    set master_poem_mode "0"
    puthelp "PRIVMSG $poem_chan :Poem Player has been locked in OFF mode."
  }
  return 0
}

Here is an example of the test file, the index marker
may need to be changed.

poemfile

Code: Select all

[1]
1. This line 1 from poem 1
2. This line 2 from poem 1
3. This line 3 from poem 1
4. This line 4 from poem 1
5. This line 5 from poem 1
6. This line 6 from poem 1
7. This line 7 from poem 1, the last line of poem 1

[2]
1. This line 1 from poem 2
2. This line 2 from poem 2
3. This line 3 from poem 2, the last line of poem 2

[3]
1. This line 1 from poem 3
2. This line 2 from poem 3
3. This line 3 from poem 3
4. This line 4 from poem 3
5. This line 5 from poem 3
6. This line 6 from poem 3, the last line of poem 3

thanks again for any help

[user]

I'd use a list for each poem (each line being a element in the list). That way you can have one poem per line in the file and you won't need all that parsing. Fetching the poem by number then gets as easy as counting lines.

For the output of lines I suggest keeping the current poem in a var like you do now, and output and remove the first element of the list each time the output proc is called (untill the list is empty (no more lines))

[strikelight]

your poemfile doesn't need to be changed to generate a list..
it's as simple as doing the following:

Code: Select all

set infile [open "poemfile.txt" r]
set buffer [read $infile]
close $infile
regsub -all {\[[0-9]+\]} $buffer "\x81" buffer
set buffer [lrange [split $buffer \x81] 1 end] 
# split will result in first element in list being empty since [1] (now
# changed to the token to split on) will have been first in the buffer
# thus we want the list range beginning with 1, not 0.

While storing a poem per line would have its advantages,
it also presents work in creating the file as such, and also
maintaining that format for future revisions. Tedious work,
which makes it more practical to keep your poems in the format they were originally intended, without losing their flow when displaying.

You can, however, ditch the numbering of the lines in each poem.

[user]

Tedious work, which makes it more practical to keep your poems in the format they were originally intended, without losing their flow when displaying.

That depends on how his means of adding new poems are. If it is by editing the text file by hand, I aggree, but he might aswell add new poems from irc/dcc, and then the list formatting would involve no extra hassles.

You can, however, ditch the numbering of the lines in each poem.

That would be a good idea. And by also ditching the "header" number and using two newlines (or something like that) as a poem separator you could replace the regsub with 'string map' and lose the lrange, because there'd be no empty element at the start.
Or you could keep the [N] and just omit it when displaying the poem (just skip the first line in each poem)

[strikelight]

That depends on how his means of adding new poems are. If it is by editing the text file by hand, I aggree, but he might aswell add new poems from irc/dcc, and then the list formatting would involve no extra hassles.

The thing to remember here though, is we are talking about poetry, where in a poem, to read it properly, you must retain the text on the seperate lines that they were meant to be on and read as... So, unless one is willing to use a character sequence (like \n) when entering via irc/dcc, and then executing code to parse the data and split it up again with that, you aren't gaining anything.

[user]

So, unless one is willing to use a character sequence (like \n) when entering via irc/dcc, and then executing code to parse the data and split it up again with that, you aren't gaining anything.

I'd use braces around the input and 'info complete' to notice completion...eg:
!addPoem {
bla bla
poetry in motion
bla bla bla
}

or some other "end command"

[strikelight]

So, unless one is willing to use a character sequence (like \n) when entering via irc/dcc, and then executing code to parse the data and split it up again with that, you aren't gaining anything.

I'd use braces around the input and 'info complete' to notice completion...eg:
!addPoem {
bla bla
poetry in motion
bla bla bla
}

or some other "end command"

And then you'll need code to check if the user disconnected during entering of the data, data cleanup in such a case, etc.. etc...
Unneccessary bindings, procs... too much work in such a case.

[user]

And then you'll need code to check if the user disconnected during entering of the data, data cleanup in such a case, etc.. etc...Unneccessary bindings, procs... too much work in such a case.

All you'd need would be a msgm/pumb bind or to 'control' the dcc connection. As for cleaning up incomplete input that could be done when ever someone starts a new input session, so detecting quits could be avoided and dcc sessions would have that built in to the ONE proc controlling the dcc connection.

Not too much work if that's what he wants

[strikelight]

And then you'll need code to check if the user disconnected during entering of the data, data cleanup in such a case, etc.. etc...Unneccessary bindings, procs... too much work in such a case.

All you'd need would be a msgm/pumb bind or to 'control' the dcc connection. As for cleaning up incomplete input that could be done when ever someone starts a new input session, so detecting quits could be avoided and dcc sessions would have that built in to the ONE proc doing it all.

Not too much work if that's what he wants

It's still extraneous code to write for such an incomplete session, even if it is ONE proc, it's one proc with extra code it should never have had in the first place, imho.

[user]

It's still extraneous code to write for such an incomplete session, even if it is ONE proc, it's one proc with extra code it should never have had in the first place, imho.

It would take like 5-10 minutes to code (the dcc solution (complete)) and it'd probably save cpu cycles compared to using regsub and lrange to parse the file.

[strikelight]

It would take like 5-10 minutes to code (the dcc solution (complete)) and it'd probably save cpu cycles compared to using regsub and lrange to parse the file.

Not really... As stated, in the event a user disconnects, you'll have to waste cpu time to do the cleanup eventually. (and cleaning up upon the next entry of a poem isn't a great solution, as the data will be idling in memory for no purpose other than to occupy space until then).. Also, you will be wasting cpu to lappend/append/set the poem lines onto each other... cpu for comparisons (for end of entering data, for example).. Not to mention, if you want to deal with a dcc session, you'll want to make it an array, to handle multiple dcc connections, which means more cpu time to handle multiple cleanup (see array thread on this forum ).. It's just overall a bad implementation for a simple concept.

[user]

Consider this...

Code: Select all

bind dcc n +poem dcc:+poem
proc dcc:+poem {h i a} {
	global poetInput
	set poetInput($i) ""
	putdcc $i "Type '.done' when done, '.abort' or just disconnect if you screw up."
	control $i dcc:poetInput
}
proc dcc:poetInput {i a} {
	global poetInput
	if {![string len $a]||$a==".abort"} {
		unset poetInput($i)
		return 1
	}
	if {$a==".done"} {
		# add $poetInput($i) to the list of poems (if you're keeping them in memory)
		# and/or append it to the file
		unset poetInput($i)
		return 1
	} {
		lappend poetInput($i) $a
		return 0
	}
}

I don't think it's that bad...having a left over array doesn't mean anything...or if you're that picky, just check 'array size' after deleting the element and unset if it's 0.

[strikelight]

Consider this...

Code: Select all

bind dcc n +poem dcc:+poem
proc dcc:+poem {h i a} {
	global poetInput
	set poetInput($i) ""
	putdcc $i "Type '.done' when done, '.abort' or just disconnect if you screw up."
	control $i dcc:poetInput
}
proc dcc:poetInput {i a} {
	global poetInput
	if {![string len $a]||$a==".abort"} {
		unset poetInput($i)
		return 1
	}
	if {$a==".done"} {
		# add $poetInput($i) to the list of poems (if you're keeping them in memory)
		# and/or append it to the file
		unset poetInput($i)
		return 1
	} {
		lappend poetInput($i) $a
		return 0
	}
}

I don't think it's that bad...having a left over array doesn't mean anything...or if you're that picky, just check 'array size' after deleting the element and unset if it's 0.

Come on.. surely you can see how this has blown the simple task of the initial problem way out of proportion and made it ten times more complex than it has to be. Look at all those additional lines of code... look at those comparisons, set's, unset's .. All that could be wiped straight out of mind, when just entering his poems via text editor in the first place.

[user]

Come on.. surely you can see how this has blown the simple task of the initial problem way out of proportion

Yes...but he might want to let other people add poems without giving them direct access to the file or whatever. Anyway...we need to stop doing this or GodOfSuicide will kill us before he kills himself because he's so envious of our post count :/

[user]

The channel commands will be like !p1 or !p25 or !p37

Then I suggest using a mask that will match those triggers:

Code: Select all

bind pubm -|- "% !p*" que:poem

Btw: Good luck finding your answers in this thread