externals

Randall Lee Reetz randall at randallreetz.com
Thu Jan 22 16:36:25 EST 2009


Hey all... closer all the time...

Here is a reposting of a link to a page describing the files system  
events reporter fslogger:
http://osxbook.com/software/fslogger/

And another link (from the bottom of the above linked page) to  
fslogger's source code (just 3 or 4 pages of C):
http://osxbook.com/software/fslogger/download/fslogger.c

If anyone has the inkling or the hankering to fuse this source into  
an external for xTalk on the Mac... please please please let me know.

Thanks,

Randall



On Jan 22, 2009, at 10:14 AM, Randall Lee Reetz wrote:

> So, it appears that most OS's now have mechanisms for real time  
> publishing of files system events in real time.  The platform of  
> interest to me is the Mac... OS X is evolving a set of protocols  
> and tools to deal with this opportunity.  Specifically, a low level  
> event publisher called fslogger and a systems level accumulative  
> log file called "" which attempts to archive these events as they  
> are published.  In the old pre-log scheme, apps and processes  
> needing to react to file system changes would subscribe directly to  
> receive fsEvents fire-hose of data.  Spotlight, Apple's user level  
> disk directory index and search system, is the primary official  
> subscriber to this data stream.  Receiving the fslogger data is one  
> thing, then the subscriber code must parse the stream and filter it  
> for domain specific events.  But the real potential for problems  
> come to play if the subscriber intends to actively react to file  
> system events through functions that cause other file system  
> events.  If your code intends to move a file or create an alias of  
> a file each time one is created or moved, and this file system  
> events will trigger yet more reactive events, It should be obvious  
> that undue recursion will arise and will need therefore to be dealt  
> with proactively before the resulting feedback loop gets out of  
> control.  Specifically, any process or app that intends to react to  
> file system events through the creation of other file system events  
> will need to actively track those events its own code causes and  
> filter these events from the cue of events it reacts to.
>
> Still, the mechanisms appear to exist for real time tracking of  
> file system events as they occur.  I downloaded an app called  
> fsEventer which provides a visual representation of file system  
> events as they happen.  I wrote a stack that created a hundred text  
> files within a folder and tested the performance with fsEventer  
> running and then without.  With fsEventer app running, file system  
> events were almost two and a half times slower.  Of course, this  
> only shows how a real time graphical display of file system events  
> will slow down file system I/O... which is to be expected.  Both  
> tests were run while the file system event API running... it is  
> always running!
>
> What I am still not able to understand, and this probably has more  
> to do with the fact that I am more an interface and interaction  
> designer than a deep systems-level programmer, is how to send xtalk  
> events  to xtalk clients (projects, stacks, and standalones).  What  
> is the intra-application communication protocol that would allow  
> for the sending of xtalk messages to xtalk clients?  Another tack  
> would be to write a stack that subscribed directly to the API that  
> sflogger subscribes to.  Any ideas?  Anyone willing to attempt this  
> code as an external?
>
> Randall
>
>
> On Jan 22, 2009, at 2:03 AM, Luis wrote:
>
>> Hiya,
>>
>> Google glasses on:
>>
>> http://www.macosxhints.com/article.php?story=20060817044149264
>>
>> http://www.ibm.com/developerworks/linux/library/l-ubuntu- 
>> inotify/     (OS X is in there too)
>>
>> http://developer.apple.com/mac/articles/cocoa/ 
>> filesystemevents.html     (DIY)
>>
>> http://oss.sgi.com/projects/fam/     (FAM: Check the Links page)
>> http://www.gnome.org/~veillard/gamin/     (FAM subset)
>>
>> http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx      
>> (I'm assuming this has command line options too)
>>
>> And then writing a Rev front end to these command line tools?
>>
>> Cheers,
>>
>> Luis.
>>
>>
>> On 21 Jan 2009, at 17:46, Randall Reetz wrote:
>>
>>> Defeats the purpose (real time, and universal)!
>>>
>>> -----Original Message-----
>>> From: "viktoras d." <viktoras at ekoinf.net>
>>> To: "How to use Revolution" <use-revolution at lists.runrev.com>
>>> Sent: 1/21/2009 2:27 AM
>>> Subject: Re: externals
>>>
>>> Hi,
>>>
>>> why not instead let user choose folders or files that should be
>>> monitored and then monitor these by comparing files (get files  
>>> etc...),
>>> folders (get folders) regularly. Use recursion to get into sub  
>>> folders,
>>> etc. Revolution is fast enough to do this efficiently.
>>>
>>> Best wishes
>>> Viktoras
>>>>
>>>> I am asking for outside help here.  An intermediate application  
>>>> that would launch at startup and listen to the flile system  
>>>> event loop... Waiting for user defined events and sending them  
>>>> out to my reactor app. (or any other stack or app so inclined).
>>>>
>>>> I dont write binding code... Just xtalk... So i am dependent on  
>>>> that other dark art called "the nerd" for deep access to system  
>>>> processing.
>>>> Randall
>>>>
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your  
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your  
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>




More information about the Use-livecode mailing list