mIRC Home    About    Download    Register    News    Help

Print Thread
#110021 04/02/05 12:12 AM
Joined: Feb 2003
Posts: 3,432
S
sparta Offline OP
Hoopy frood
OP Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
How would i go ahead to first check one file, if a word arent found in that one, then it should go to the next file, if word arent found in that one, then it shouldent do nothing.. any ideas? :tongue: i can get it to work if it's only one file, but not with two separate files on the same word.. confused i can paste my script here if u want to see it, but i guess it wont help much cos it can only read one file.. and i have no clue how to add the second file and make it read that one too.. not if i only want to send one command if word is found in any in the files, and another if word arent found in any of the files.. :tongue: this is the line i working with now..
$read($mircdirfile.txt, w, %var)
the word is set as a %var on text in a channel.. set %var $1, and should only be triggered if the %var is the first word in the file..


if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
#110022 04/02/05 12:28 AM
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
Why would reading from more than 1 file be any different to reading from 1 file? It's the same identifier, just need to group your if statements.

You say your script should trigger if a word is the first word in the file. How is your file grouped? Is it multiple lines with each line 1 word, or multiple words on each line?

In the case of 1 line = 1 word:

if $istok($read(myfile.txt,n,1) $read(myotherfile.txt,n,1),%var,32) { echo -a %var matched as first word in one of the files }

Otherwise you need to use $gettok(<input>,1,32) but the basis is the exact same.

* Note that continually reading from a file in an on text event is a big no-no, unless you hold a grudge against your hard drive. Hash tables/hidden windows, would be much preferred.

* Note you don't need $mircdir in a read statement if this file is located in your main mIRC folder.

* Note you can pass parameters to aliases, which makes the setting to var of $1 obsolete.

Example: on *:text:*:#: myalias $1

alias myalias {
echo -a Incoming parameter: $1
}


Gone.
#110023 04/02/05 12:46 AM
Joined: Feb 2003
Posts: 3,432
S
sparta Offline OP
Hoopy frood
OP Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
how would you use: Hash tables/hidden windows then ? never been using them to gather info from *.txt files befor.. and dont say read mirc.hlp, that dont say much about the subject.. only a fev lines and im not helped by that :tongue:


if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
#110024 04/02/05 12:52 AM
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
//window -h @mywindow | loadbuf @mywindow myfile.txt

You now have a hidden window which holds the contents of myfile.txt without having to continually read from your hard drive, since it's stored in memory.

First line of the window: $line(@mywindow,1)

/help /window and check out the commands and identifiers.


Gone.
#110025 04/02/05 08:30 AM
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
In the case of 1 line = 1 word:

if $istok($read(myfile.txt,n,1) $read(myotherfile.txt,n,1),%var,32) { echo -a %var matched as first word in one of the files }


I like that method of hitting both files at once, but i think you ment to say
if $istok($read(myfile.txt,nw,%var,1) $read(myotherfile.txt,nw,%var,1),%var,32) { echo -a %var matched as first word in one of the files }

Quote:
* Note that continually reading from a file in an on text event is a big no-no, unless you hold a grudge against your hard drive. Hash tables/hidden windows, would be much preferred.


In that case maybe would be better, (second $read not being invoked if first $read == %var)
if ((($read(myfile.txt,nw,%var,1) == %var) || ($read(myotherfile.txt,nw,%var,1) == %var)) { echo -a %var matched as first word in one of the files }


Actually I totally understand what you mean by continually reading a file on a text event should be a no-no but I dont actually think it in fact is,
If reading from file...
Downside (1) : File might need to be re-read from hdd [ see usside(1) ]
Downside (2) : assuming downside (1) then text matching time well be down on this event
Downside (3) : ? might be some others i cant think of one.
Upside (1) : OS well cache up file into ram so HDD access is reduced
Upside (2) : File can be updated internally or externally to mirc, and updates take effect instantly.

if reading from @window or hashtable
Downside (1) : file cant be updated externally as mirc well not see update, unless extra code added to monitor the file
Downside (2) : ok this sounds corny but Some Yahoo deletes the hidden window or kills the hashtable, this is scriptable around of course
Upside (1) : chance of HDD re-read nill


Heres my personal experence, I have had a huge file being read on a text event, and besides the first ever event it never accessed the hdd again, the OS cached up the file of course, I decided to change it to a hidden window one day because of something else i wanted to do with it, and discovered that doing a $fline was well slower than a $read on a cached file. At this point I changed to a hashtable to see what speed that migth have (totally side tracked from what i originally was doing), and the speed was fractionally faster than the file. Since I wanted a way to visuall inspect the contents of the file, the hashtable wasnt going to be much help, so i just stayed with the file.


This of course is just my 2 cents worth, and can be ignored at your pleasure :-)

#110026 04/02/05 03:27 PM
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
Quote:
I like that method of hitting both files at once, but i think you ment to say
if $istok($read(myfile.txt,nw,%var,1) $read(myotherfile.txt,nw,%var,1),%var,32) { echo -a %var matched as first word in one of the files }


Nope, he said he wanted to get the first word in the file, and if the assumption is that 1 line is 1 word, then $read(myfile.txt,n,1) simply returns this first word, no need for wildcards.

Quote:
In that case maybe would be better, (second $read not being invoked if first $read == %var)
if ((($read(myfile.txt,nw,%var,1) == %var) || ($read(myotherfile.txt,nw,%var,1) == %var)) { echo -a %var matched as first word in one of the files }

This is true of course, I thought about that pretty instantly afterwards, though seeing as I told him he should store his text file in memory (hidden win/htb) it didn't seem worth it to mention anymore.

Quote:
ok this sounds corny but Some Yahoo deletes the hidden window or kills the hashtable, this is scriptable around of course

This goes for anything, that yahoo might just delete the file as well when it sees this file which doesn't belong to him, but generated by a script. It'll actually be harder to delete the hidden window, since the person is never aware of it, unless they look in the window list, and issue a /close -@ @mywin or /window -c @mywind or a variation to that. Deleting a file is only a mouse click away.

As for the rest, I entirely disagree, let's compare file access to hash table/hidden win access:

FOR READING

//write -c test.txt test
//hadd -m test test test
//window -h @test | aline @test test

Code:
alias bench1 {
  var %a = 50000, %b = $ticks
  while %a {
    .echo -q $read(test.txt,n,1)
    dec %a
  }
  echo -s time taken reading from file: $calc($ticks - %b)
}

--> time taken reading from file: 8953 (1st time), 9796 (second time)

Code:
alias bench2 {
  var %a = 50000, %b = $ticks
  while %a {
    .echo -q $hget(test,test)
    dec %a
  }
  echo -s time taken reading from hash table: $calc($ticks - %b)
}

--> time taken reading from hash table: 1313 (1st time), 1328 (2nd time)

Code:
alias bench3 {
  var %a = 50000, %b = $ticks
  while %a {
    .echo -q $line(@test,1)
    dec %a
  }
  echo -s time taken reading from hidden window: $calc($ticks - %b)
}

---> time taken reading from hidden window: 1313 (1st time), 1328 (2nd time)

Quite funny how I got identical results for a hidden window and a hash table. I assume this is because it's only 1 data item in the htb, whereas htb's real advantage is reading from a large amount of data. Also the read from the hidden window is always the first line, so no seeking is involved.

There's a huge difference in accessing speed. Did my OS really cache that file to memory? I'd need to have some file monitoring program. Even if it did, the structure of a hash table is much better suited for data storage/retrieval, than a text file. Even doing a $line(@mywin,1) is much much faster than a $read(myfile.txt,n,1).

FOR WRITING

File handling commands don't count, since sparta's code also doesn't deal with an open file, it deals with a closed file.
Code:
alias bench4 {
  var %a = 50000, %b = $ticks
  while %a {
    write test.txt test
    dec %a
  }
  echo -s time taken writing to file: $calc($ticks - %b)
}

--> time taken writing to file: 14719

Code:
alias bench5 {
  var %a = 50000, %b = $ticks
  while %a {
    aline @test test
    dec %a
  }
  echo -s time taken writing to hidden window: $calc($ticks - %b)
}

--> time taken writing to hidden window: 2922

...


Gone.
#110027 04/02/05 05:15 PM
Joined: Feb 2003
Posts: 3,432
S
sparta Offline OP
Hoopy frood
OP Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
Just repleyd to somone in the list..

now when i have been reading your posts in here you make me unsecure, i maybe should explain what i want to do, so here we go wink

I trying to make a litle script that

1: gather info, and it gather info from the word's is or are.. if ($2 == is) or if ($1 == are) , and then it match the lines in two txt files, one for is and one for are, if the word befor is or are isnt in the txt files it write them down in them.

2: it idle on a channel, and then if somone type somthing in the channel it check the files for a match of $1 .. if match it type the line out in to the channel, if no match it do nothing..

what would be the best way to do this ? you say read from HD is a no-no, but i cant get it to read true the whole @windows i created, and make a match in that one, widow is created as -h @ window . and the lines are loaded in to that window, i get the first line in the @window, but i cant get it to cycle true all lines in that @window, and if i get it to cycle true the @window it wont stop, it going on untill excess flood, tyed to use this one:

set %line 1
set %firstline $line(@hidedwindow,%line)
:start
it working so far.

inc %line 1
if (%firstline != $line(@hidedwindow,%line)) { goto start }
else {
do this
this part dosnt work

so how would i do this the simplest way, i dont look for something advanced, just a simple script that cycle true the lines in the @window that it loads from the txt file..


if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
#110028 04/02/05 05:47 PM
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
Quote:
the word is set as a %var on text in a channel.. set %var $1, and should only be triggered if the %var is the first word in the file..


Why did you say this if this is not what you want at all... I spent 15 mins doing useless benchmarks and typing up that post frown

The fix is so easy it makes me wheep. You don't even need to do an if check for existance of the string.

//window -h @win1 | window -h @win2 | loadbuf @win1 file1.txt | loadbuf @win2 file2.txt

Now with each event you simply do:

aline -n @win1 <someword>
aline -n @win2 <someword>

The -n switch will only add a line to the window if it's not already there, so we don't even need to bother checking for it's existance anymore.

Don't forget to savebuf the windows to files again when you close mIRC. Use the on exit event.

To know if there is a match is even easier, just do: if $fline(@win1,<someword>) { echo -a it's there }

This is all based on the assumption that each line is 1 word, which gathering from your last code examples seems to be the case.

Bye


Gone.
#110029 04/02/05 05:59 PM
Joined: Feb 2003
Posts: 3,432
S
sparta Offline OP
Hoopy frood
OP Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
Still no go, if "some_word is in the @window", then it still add the word to the @window if the whole text dosnt match.. and thats wrong.. and it wont separate the is and are, they all will be loaded to the same @window, and if u save the buffer to a txt file, then are and is will be stored in the same file.. and as i said i will ONLY add a "is" if it dont exist in the @window, but if it exist, then it shouldent do anything.. like:

script IS kinda fun <<-- that is stored in the @window..

script IS a bit hard to create <<-- thats not in the @window..

but since SCRIPT is already comented with a IS, then it shouldent do anything.. and not store the line in the @window..

same with are..

you ARE nice that try to help me <<-- stored in the window..
you ARE at home now <<-- not stored

but since YOU is in the @win i dont want it to add it self again, cos then i end up with two that trigger on the same word "YOU".. :tongue:


if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
#110030 04/02/05 06:14 PM
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
Well, three times I've made the assumption of lines being single words in your text file, not once did you negate it. Now, after all this time, FINALLY we know the lines in your text file are NOT single words, but multiple words.

The solution: use wildcards in $fline, that's what it's made for actually;

if $fline(@win1,*are*) { echo -a are is in the window }

Note that are would match on square, because of the wildcards. What you can do is add an additional "if $istok(<input line>,are,32)" to see if it's really the stand alone word "are" and not "square".

You could instead do $fline(@win1,* are *) but then a single line containing only "are" will not match either, nor a line beginning/ending with "are".

Your best bet, if in fact you only want to match space delimited tokens, would be to use a regex in the $fline like this:

if $fline(@win1,/(?<=^|\s)is(?=\s|$)/,1,2) { echo -a found a stand alone occurence of "is" }

Note that the regex is case sensitive, meaning IS is not the same as is. If it may be case insensitive change it to: $fline(@win1,/(?<=^|\s)is(?=\s|$)/i,1,2)

Goodbye

Last edited by FiberOPtics; 04/02/05 06:20 PM.

Gone.
#110031 05/02/05 10:24 AM
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
Quote:
I like that method of hitting both files at once, but i think you ment to say
if $istok($read(myfile.txt,nw,%var,1) $read(myotherfile.txt,nw,%var,1),%var,32) { echo -a %var matched as first word in one of the files }


Nope, he said he wanted to get the first word in the file, and if the assumption is that 1 line is 1 word, then $read(myfile.txt,n,1) simply returns this first word, no need for wildcards.


he said "How would i go ahead to first check one file, if a word arent found in that one, then it should go to the next file, if word arent found in that one, then it shouldent do nothing.. any ideas? i can get it to work if it's only one file, but not with two"

That didnt sound like the first line only to me, so I was basing my possable correction of your code on the premies that he wanted to sweep a whole file.

Quote:
Quote:
ok this sounds corny but Some Yahoo deletes the hidden window or kills the hashtable, this is scriptable around of course

This goes for anything, that yahoo might just delete the file as well when it sees this file which doesn't belong to him, but generated by a script. It'll actually be harder to delete the hidden window, since the person is never aware of it, unless they look in the window list, and issue a /close -@ @mywin or /window -c @mywind or a variation to that. Deleting a file is only a mouse click away.


This is true, however since you must have the files in the first place to load the hidden window, there well always be a chance of them deleting the file regardless, if no window was used then that one possable problem is removed, the other the file deleting well always exist.

Quote:

As for the rest, I entirely disagree, let's compare file access to hash table/hidden win access:
--> time taken reading from file: 8953 (1st time), 9796 (second time)
--> time taken reading from hash table: 1313 (1st time), 1328 (2nd time)
--> time taken reading from hash table: 1313 (1st time), 1328 (2nd time)


Totally agree on them, but my premies was again that the whole file was being searched, the results appeared far different (see below)

Code:
alias benchsetup {
  echo -a standby creating file/window/hashtable
  var %text = $str(.,100)
  fclose testhandle? | fopen -no testhandle- test.txt | var %i = 1 | while (%i &lt;= 150001 ) { .fwrite -n testhandle- %i %text %i | inc %i } | fclose testhandle?
  window -c @test | window -hn @test | loadbuf @test test.txt
  hfree -sw test | hmake test 1225 | hload -sn test test.txt
  echo -a test.txt file lines = $lines(test.txt)
  echo -a @test window lines = $line(@test,0)
  echo -a test hashtable items = $hget(test,0).item
}
;
alias benchmark {
  var %c = 100001  
  while (%c &lt;= 150001) {
    var %text = %c $str(.,100) * | var %stxt = %c $str(.,100)
    var %t1 = $ticks | var %i = 100 | while (%i) { .echo -q $read(test.txt,ntw,%text,1) | dec %i } | var %t1 = $calc($ticks - %t1)
    var %t2 = $ticks | var %i = 100 | while (%i) { .echo -q $fline(@test,%text,1)       | dec %i } | var %t2 = $calc($ticks - %t2)
    var %t3 = $ticks | var %i = 100 | while (%i) { .echo -q $hfind(test,%text,1,w).data | dec %i } | var %t3 = $calc($ticks - %t3)
    var %t4 = $ticks | var %i = 100 | while (%i) { .echo -q $read(test.txt,nts,%stxt,1) | dec %i } | var %t4 = $calc($ticks - %t4)
    echo -a Results for 100 x wildmatches for line/item %c $+ , File = %t1 , Window = %t2 , Hastable = %t3 , also File using Start line matching = %t4
    inc %c 25000
  }
}
.
.
Results for 100 x wildmatches for line/item      1, File =   343 , Window =     16 , Hastable = 13422 , also File using Start line matching =   344
Results for 100 x wildmatches for line/item  25001, File = 15078 , Window =  18359 , Hastable = 13328 , also File using Start line matching = 12406
Results for 100 x wildmatches for line/item  50001, File = 29844 , Window =  36594 , Hastable = 13421 , also File using Start line matching = 24704
Results for 100 x wildmatches for line/item  75001, File = 44969 , Window =  55234 , Hastable = 13438 , also File using Start line matching = 36906
Results for 100 x wildmatches for line/item 100001, File = 63938 , Window =  81093 , Hastable = 14985 , also File using Start line matching = 53032
Results for 100 x wildmatches for line/item 125001, File = 80594 , Window =  98344 , Hastable = 13969 , also File using Start line matching = 66406
Results for 100 x wildmatches for line/item 150001, File = 97125 , Window = 122250 , Hastable = 15172 , also File using Start line matching = 82125
.
.
I changed the line lengths by changing $str(.,100) to $str(.,1) and came up with these results...
.
.
Results for 100 x wildmatches for line/item      1, File =   344 , Window =    16 , Hastable = 12375 , also File using Start line matching =   359
Results for 100 x wildmatches for line/item  25001, File =  3766 , Window =  4922 , Hastable = 12312 , also File using Start line matching =  3063
Results for 100 x wildmatches for line/item  50001, File =  7234 , Window =  9859 , Hastable = 12235 , also File using Start line matching =  5437
Results for 100 x wildmatches for line/item  75001, File = 10703 , Window = 14875 , Hastable = 12250 , also File using Start line matching =  8078
Results for 100 x wildmatches for line/item 100001, File = 14313 , Window = 19921 , Hastable = 12360 , also File using Start line matching = 10703
Results for 100 x wildmatches for line/item 125001, File = 18062 , Window = 25110 , Hastable = 12469 , also File using Start line matching = 13453
Results for 100 x wildmatches for line/item 150001, File = 21594 , Window = 29859 , Hastable = 12344 , also File using Start line matching = 16297


In these tests at least, when the filesize starts increasing in lines, seeking for a word becomes longer and longer, assuming you more often than not are seeking a word not in the file, then the max search times listed could be expected, regardless of size of each line the scaling up seems to be around constant, Of course the glaring obvious one is Hashtable, it starts off not so great, but remains constant through out, obviously due to its storage/access methods, this also was searching for a match in the data i did experement using item names but that appeared to be slightly slower to search for a match at around 15000 ticks

Quote:
There's a huge difference in accessing speed. Did my OS really cache that file to memory? I'd need to have some file monitoring program. Even if it did, the structure of a hash table is much better suited for data storage/retrieval, than a text file. Even doing a $line(@mywin,1) is much much faster than a $read(myfile.txt,n,1).


I just looked at my hdd light, it didnt go on, but i also decided to double check that, with a monitoring tool, and my system at least cached the whole file into ram.
I must say yes yes yes a hash table seems far better tyhan anyother, but is of course the hardest of the 3 to edit/view etc.


To sum I would say "to each his own, no system is fool proof or the fastest in every curcumstance I guess"

#110032 05/02/05 08:42 PM
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
Yea, no worries, I wonder if I sounded rude in my posts, because I was seriously pissed off for a number of reasons yesterday.

Anyway, I hate when people put contradictions in their description: you're right about that searching the whole file based on the quote you showed, though his last line in his initial post was:

the word is set as a %var on text in a channel.. set %var $1, and should only be triggered if the %var is the first word in the file..

So I was like: wtf, what is it now, first word in the file or wherever in the file?

These are some interesting results, I find it so unfortunate that there is no documentation on mIRC's underlying mechanics. It's striking that doing $fline on a hidden window, which is stored in memory, is slower than a $read with w switch on a file cached in memory. I'm no programmer of course, so hard to say, but imo there isn't really a distinct difference between a cached file, and a hidden window with the same contents. They both have the same structure, unlike a hash table which uses hashing. "Scratches head".

I am going to read up on this file caching, it's an interesting thing that I didn't know. I am very curious why the basic accessing of a file vs hidden win (what I benched) gives such bad results.

Also would like to know what kind of search methods mIRC uses for $read with w switch, versus $fline. Perhaps the coding for $fline isn't entirely optimized in mIRC's internals...who knows.

Anyway, meet you in another thread Dave, bye.


Gone.

Link Copied to Clipboard