Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
CoolCelesteFilters
Last updated at 1:44 pm UTC on 16 January 2006
In working on the Squeak anthology's chapter on networking, I felt obliged to sit down and try to come up with some cool filters. Filters that really showcases how cool Celeste filters are. I have a feeling that I'll have to cut some for space reasons (wimper!) so I decided to share them here. Feel free to add your favorite useful or simply wacky filters! –Bijan Parsia

(Hmm. I'd like to do this as a table but that means using straight HTML as the SwikiSyntax version doesn't handle code very well. Oh well.)

Filter codeComments
m textHas: 'X-Mailer: Celeste'Göran Hultgren (goran.hultgren@bluefish.se) whipped this up to check who's been a good little Celesteer and who's not. It shamed me (Bijan) into making the full time switch!
m participantHas: 'squeak@cs.uiuc.edu'Very simple filter. The only thing interesting about it is the #patricipantHas checks the from:, to:, and cc: fields. --BJP
m participantHas: 'me@wherever.we'Look for messages that explicitly name you in the header. Such messages are usually of personal interest.
Time now hours < 12
    ifTrue: [m participantHas: 'squeak@cs.uiuc.edu']
    ifFalse: [m subjectHas: '[BUG]']
 Filters are just Squeak code! This filter has a different effect in the morning and in the evening (morning for goofing off reading the Squeak list and the afternoon for those serious bug reports). Remember, the filter must return 'true' or 'false' for each message!--BJP
(m subjectHas: #(music go protest)
    ifFalse: [Transcript cr; show: 'Rejecting note from ', m from.
                 false]
 Kinda pointless, but it does demontrate two interesting filter features: 1) the "helper" methods (i.e., fooHas:) can take arrays as arguments, and will coerce the items to strings (this makes "or" searchs way more compact), 2) your filters are just Squeak code and can have interesting side effects. --BJP
(m fromHas: #('[ENH]' '[BUG]' '[FIX]')
    ifTrue: [self catgeory = 'new' 
       ifTrue: [self queueMessageWithText: m rawText.
                mailDB file: m msgID inCategory: 'BugList'.
                mailDB remove: m msgID fromCategory: 'new']
       true]
    ifFalse: [false]
 This one pushes things to the limit :) and requires a minor change to Celeste>>makeFilterFor: (which I'll submit to the Squeak list), to wit 
^Compiler evaluate:
         '[ :m | ' , filterExpr , ']'
    for: self
    logged: false
 This lets you send stuff to your current Celeste and access its instance variables. Ooops! Wrong-o! I don't know if it's a recent change or just an error on my part, but this is a *class* method (why?) and thus "self" refers to the class. Boo hoo bah! So, *three* changes. Change as above. Move it instance side. Alter editFilterNamed:filterExpr: to call the instance side method. And that lets you do such things as have category sensitive filters, and filters that generate responses (both of these things done in this sample). One tricky bit: the browser lists won't be properly updated. Of course, this was the easy way out. I suppose I could turn filters into a two argument block. But then you wouldn't have access to the instance variables, which is key for doing all sorts of thing. That fact is, I think, a flaw in the programmatic interfact to Celeste. (Although a simple #mailDB accessor would solve most of the problems.) --BJP