I think he's running the My Pictures tool:
http://radio.userland.com/userGuide/reference/tools/myPicturesTool

It does exactly that: watch a folder and move every image that's
dropped there into the www/images/YYYY/MM/DD folder.

Peter

--- In radio-dev@yahoogroups.com, Steve Kirks <steve.kirks@g...> wrote:
> Radio upstream folder--do you mean the 'www/images' folder?  Do you
> have a custom script or tool that moves images into date-based
> folders?
>
> Steve
>
>
> On 6/22/05, jaksonofjack <iJak@m...> wrote:
> >  .
> >
> >  Well Lawrence,
> >
> >  Thank you for the work. ...
> >
> >  As of now I have installed the update, and my streaming seems to
mostly
> > work for the
> >  normally scheduled upstream files, like the .opml files. ...
> >
> >  I was interested in upstreaming images, so I tried that first. It
did not
> > work.
> >  What normally happens is that I place an image in the Radio Upstream
> > folder, that images
> >  gets moved into a date heirachy of the images folder in the www
folder. ...
> >
> >  Excuse me. I thought it did not work at all, but it just took 30
minutes
> > for the image to
> >  upstream, and then open the Home page with the image html in place.
> >
> >  I have placed another image in the upstream folder and am now
waiting to
> > see what
> >  happens.
> >  ...
> >  I have waited about 15 minutes since I placed the image in the
folder. ...
> > It has not yet
> >  upstreamed and updated the home page.
> >
> >  Good night, I will revisit this tomorrow.
> >  Jack
> >
> >
> >
> >
> >  --- In radio-dev@yahoogroups.com, Lawrence Lee <lawrence@u...> wrote:
> >  > We made some changes to the upstreaming in Radio, adding some
new scan
> >  > intervals for different folders. This reduces the load that
Radio places
> > on
> >  > the processor during each scan.
> >  >
> >  > *** New callbacks
> >  >
> >  > We also added 3 user callbacks, to accomodate 2 new projects, the
> > Markdown
> >  > Tool and the Radio Factory
> >  >
> >  > user.radio.callbacks.adminMenu - called from radio.macros.adminMenu
> >  >
> >  > user.radio.callbacks.renderItem - called from
> > radio.macros.weblogRecentPosts
> >  > and radio.trackback.ping
> >  >
> >  > user.radio.callbacks.renderStory - called from
> > radio.webserver.buildPage
> >  >
> >  > *** How do I install it?
> >  >
> >  > Important: Quit Radio and backup the entire Radio UserLand
folder.  This
> > is
> >  > good practice before installing any beta software or tools.
> >  >
> >  > 1. Download this file and save it to disk:
> >  >
> >  >
> > http://lawrence.userland.com/radioParts/upstreamingBeta08.fttb
> >  >
> >  > 2. Import the beta parts into Radio using the Open command in
Radio's
> > File
> >  > menu.
> >  >
> >  > 3. In the QuickScript window (Ctrl-;), run the following script:
> >  >
> >  > workspace.upstreamingBeta08.installer ()
> >  >
> >  > If you need to remove the beta parts, you can run the following
command
> > in a
> >  > QuickScript command to restore the original parts (prior to
installing of
> >  > the beta parts):
> >  >
> >  > workspace.upstreamingBeta08.installer (false)
> >
> >
> >
> >
> >  ________________________________
> >  Yahoo! Groups Links
> >
> > To visit your group on the web, go to:
> > http://groups.yahoo.com/group/radio-dev/
> >
> > To unsubscribe from this group, send an email to:
> > radio-dev-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
> --
> Steve Kirks
> Product Manager, Radio UserLand
> http://steve.userland.com/

Radio upstream folder--do you mean the 'www/images' folder?  Do you
have a custom script or tool that moves images into date-based
folders?

Steve


On 6/22/05, jaksonofjack <iJak@...> wrote:
>  .
>
>  Well Lawrence,
>
>  Thank you for the work. ...
>
>  As of now I have installed the update, and my streaming seems to mostly
> work for the
>  normally scheduled upstream files, like the .opml files. ...
>
>  I was interested in upstreaming images, so I tried that first. It did not
> work.
>  What normally happens is that I place an image in the Radio Upstream
> folder, that images
>  gets moved into a date heirachy of the images folder in the www folder. ...
>
>  Excuse me. I thought it did not work at all, but it just took 30 minutes
> for the image to
>  upstream, and then open the Home page with the image html in place.
>
>  I have placed another image in the upstream folder and am now waiting to
> see what
>  happens.
>  ...
>  I have waited about 15 minutes since I placed the image in the folder. ...
> It has not yet
>  upstreamed and updated the home page.
>
>  Good night, I will revisit this tomorrow.
>  Jack
>
>
>
>
>  --- In radio-dev@yahoogroups.com, Lawrence Lee <lawrence@u...> wrote:
>  > We made some changes to the upstreaming in Radio, adding some new scan
>  > intervals for different folders. This reduces the load that Radio places
> on
>  > the processor during each scan.
>  >
>  > *** New callbacks
>  >
>  > We also added 3 user callbacks, to accomodate 2 new projects, the
> Markdown
>  > Tool and the Radio Factory
>  >
>  > user.radio.callbacks.adminMenu - called from radio.macros.adminMenu
>  >
>  > user.radio.callbacks.renderItem - called from
> radio.macros.weblogRecentPosts
>  > and radio.trackback.ping
>  >
>  > user.radio.callbacks.renderStory - called from
> radio.webserver.buildPage
>  >
>  > *** How do I install it?
>  >
>  > Important: Quit Radio and backup the entire Radio UserLand folder.  This
> is
>  > good practice before installing any beta software or tools.
>  >
>  > 1. Download this file and save it to disk:
>  >
>  >
> http://lawrence.userland.com/radioParts/upstreamingBeta08.fttb
>  >
>  > 2. Import the beta parts into Radio using the Open command in Radio's
> File
>  > menu.
>  >
>  > 3. In the QuickScript window (Ctrl-;), run the following script:
>  >
>  > workspace.upstreamingBeta08.installer ()
>  >
>  > If you need to remove the beta parts, you can run the following command
> in a
>  > QuickScript command to restore the original parts (prior to installing of
>  > the beta parts):
>  >
>  > workspace.upstreamingBeta08.installer (false)
>
>
>
>
>  ________________________________
>  Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/radio-dev/
>
> To unsubscribe from this group, send an email to:
> radio-dev-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
Steve Kirks
Product Manager, Radio UserLand
http://steve.userland.com/

.

Well Lawrence,

Thank you for the work. ...

As of now I have installed the update, and my streaming seems to mostly work for
the
normally scheduled upstream files, like the .opml files. ...

I was interested in upstreaming images, so I tried that first. It did not work.
What normally happens is that I place an image in the Radio Upstream folder,
that images
gets moved into a date heirachy of the images folder in the www folder. ...

Excuse me. I thought it did not work at all, but it just took 30 minutes for the
image to
upstream, and then open the Home page with the image html in place.

I have placed another image in the upstream folder and am now waiting to see
what
happens.
...
I have waited about 15 minutes since I placed the image in the folder. ... It
has not yet
upstreamed and updated the home page.

Good night, I will revisit this tomorrow.
Jack



--- In radio-dev@yahoogroups.com, Lawrence Lee <lawrence@u...> wrote:
> We made some changes to the upstreaming in Radio, adding some new scan
> intervals for different folders. This reduces the load that Radio places on
> the processor during each scan.
>
> *** New callbacks
>
> We also added 3 user callbacks, to accomodate 2 new projects, the Markdown
> Tool and the Radio Factory
>
> user.radio.callbacks.adminMenu - called from radio.macros.adminMenu
>
> user.radio.callbacks.renderItem - called from radio.macros.weblogRecentPosts
> and radio.trackback.ping
>
> user.radio.callbacks.renderStory - called from radio.webserver.buildPage
>
> *** How do I install it?
>
> Important: Quit Radio and backup the entire Radio UserLand folder.  This is
> good practice before installing any beta software or tools.
>
> 1. Download this file and save it to disk:
>
> http://lawrence.userland.com/radioParts/upstreamingBeta08.fttb
>
> 2. Import the beta parts into Radio using the Open command in Radio's File
> menu.
>
> 3. In the QuickScript window (Ctrl-;), run the following script:
>
> workspace.upstreamingBeta08.installer ()
>
> If you need to remove the beta parts, you can run the following command in a
> QuickScript command to restore the original parts (prior to installing of
> the beta parts):
>
> workspace.upstreamingBeta08.installer (false)

We made some changes to the upstreaming in Radio, adding some new scan
intervals for different folders. This reduces the load that Radio places on
the processor during each scan.

*** New callbacks

We also added 3 user callbacks, to accomodate 2 new projects, the Markdown
Tool and the Radio Factory

user.radio.callbacks.adminMenu - called from radio.macros.adminMenu

user.radio.callbacks.renderItem - called from radio.macros.weblogRecentPosts
and radio.trackback.ping

user.radio.callbacks.renderStory - called from radio.webserver.buildPage

*** How do I install it?

Important: Quit Radio and backup the entire Radio UserLand folder.  This is
good practice before installing any beta software or tools.

1. Download this file and save it to disk:

http://lawrence.userland.com/radioParts/upstreamingBeta08.fttb

2. Import the beta parts into Radio using the Open command in Radio's File
menu.

3. In the QuickScript window (Ctrl-;), run the following script:

workspace.upstreamingBeta08.installer ()

If you need to remove the beta parts, you can run the following command in a
QuickScript command to restore the original parts (prior to installing of
the beta parts):

workspace.upstreamingBeta08.installer (false)

I also had another bug reported ... I didn't implement the edit/update post
function.  So new posts work ... Editing a post does not yet update the post
on Blogger.

Ok ... I have some more work to do ...  :-)


Scott C. Lemon




-----Original Message-----
From: radio-dev@yahoogroups.com [mailto:radio-dev@yahoogroups.com] On Behalf
Of Scott C. Lemon
Sent: Thursday, June 09, 2005 1:28 PM
To: radio-dev@yahoogroups.com
Subject: RE: [radio-dev] Re: Posting from Radio to Blogger.com ... via Atom
API ...


Ok ... I have another "bug" that I found today ... It's actually a
dependency.

It appears that I had already installed Steve Hookers other tool ... The
backLogAllRSS Tool.

Steve's xManilaBloggerBridge - that I based this tool on - has a call to the
backLogAllRSS tool.  You can go and get a copy of this tool from here:
http://www.cybersaps.org/publicTools/backLogAllRSS/

Install this tool in Radio and it will solve the dependency until I can get
a new code drop out.


Scott C. Lemon




-----Original Message-----
From: radio-dev@yahoogroups.com [mailto:radio-dev@yahoogroups.com] On Behalf
Of Scott C. Lemon
Sent: Wednesday, June 08, 2005 11:57 PM
To: radio-dev@yahoogroups.com
Subject: RE: [radio-dev] Re: Posting from Radio to Blogger.com ... via Atom
API ...


Ok ... So I'm several days overdue ... But here it is:
http://radioatombridge.blogspot.com/

Go here and you can grab a copy of my RadioAtomBridge Tool ... Let me know
if it works ... If it doesn't ... And any changes that you would like. Maybe
I'll do them.  :-)

Right now I have tested it with two categories and two blogs on Blogspot. It
seems to be working fine for me with the testing that I have done.  You can
now easily mirror posts from any Radio category to a Blogger.com or
Blogspot.com blog.  I've got a few tweaks that I want to do ... But I want
to do some other work for a week or so.

I'm also sending a copy of the code to Userland ... Since it's technically
their code ... So that they can incorporate this into the next version of
Radio!


Scott C. Lemon




-----Original Message-----
From: radio-dev@yahoogroups.com [mailto:radio-dev@yahoogroups.com] On Behalf
Of Marc Barrot
Sent: Thursday, June 02, 2005 1:53 PM
To: radio-dev@yahoogroups.com
Subject: [radio-dev] Re: Posting from Radio to Blogger.com ... via Atom API
...


> got my first successful post to the Atom API on blogger.com from
Radio...

An Atom API posting interface is a great addition to Radio. Would you
consider sharing your code, may be include it in a tool ?

Cheers

Marc





Yahoo! Groups Links










Yahoo! Groups Links










Yahoo! Groups Links

Ok ... I have another "bug" that I found today ... It's actually a
dependency.

It appears that I had already installed Steve Hookers other tool ... The
backLogAllRSS Tool.

Steve's xManilaBloggerBridge - that I based this tool on - has a call to the
backLogAllRSS tool.  You can go and get a copy of this tool from here:
http://www.cybersaps.org/publicTools/backLogAllRSS/

Install this tool in Radio and it will solve the dependency until I can get
a new code drop out.


Scott C. Lemon




-----Original Message-----
From: radio-dev@yahoogroups.com [mailto:radio-dev@yahoogroups.com] On Behalf
Of Scott C. Lemon
Sent: Wednesday, June 08, 2005 11:57 PM
To: radio-dev@yahoogroups.com
Subject: RE: [radio-dev] Re: Posting from Radio to Blogger.com ... via Atom
API ...


Ok ... So I'm several days overdue ... But here it is:
http://radioatombridge.blogspot.com/

Go here and you can grab a copy of my RadioAtomBridge Tool ... Let me know
if it works ... If it doesn't ... And any changes that you would like. Maybe
I'll do them.  :-)

Right now I have tested it with two categories and two blogs on Blogspot. It
seems to be working fine for me with the testing that I have done.  You can
now easily mirror posts from any Radio category to a Blogger.com or
Blogspot.com blog.  I've got a few tweaks that I want to do ... But I want
to do some other work for a week or so.

I'm also sending a copy of the code to Userland ... Since it's technically
their code ... So that they can incorporate this into the next version of
Radio!


Scott C. Lemon




-----Original Message-----
From: radio-dev@yahoogroups.com [mailto:radio-dev@yahoogroups.com] On Behalf
Of Marc Barrot
Sent: Thursday, June 02, 2005 1:53 PM
To: radio-dev@yahoogroups.com
Subject: [radio-dev] Re: Posting from Radio to Blogger.com ... via Atom API
...


> got my first successful post to the Atom API on blogger.com from
Radio...

An Atom API posting interface is a great addition to Radio. Would you
consider sharing your code, may be include it in a tool ?

Cheers

Marc





Yahoo! Groups Links










Yahoo! Groups Links

Ok ... So I'm several days overdue ... But here it is:
http://radioatombridge.blogspot.com/

Go here and you can grab a copy of my RadioAtomBridge Tool ... Let me know
if it works ... If it doesn't ... And any changes that you would like.
Maybe I'll do them.  :-)

Right now I have tested it with two categories and two blogs on Blogspot.
It seems to be working fine for me with the testing that I have done.  You
can now easily mirror posts from any Radio category to a Blogger.com or
Blogspot.com blog.  I've got a few tweaks that I want to do ... But I want
to do some other work for a week or so.

I'm also sending a copy of the code to Userland ... Since it's technically
their code ... So that they can incorporate this into the next version of
Radio!


Scott C. Lemon




-----Original Message-----
From: radio-dev@yahoogroups.com [mailto:radio-dev@yahoogroups.com] On Behalf
Of Marc Barrot
Sent: Thursday, June 02, 2005 1:53 PM
To: radio-dev@yahoogroups.com
Subject: [radio-dev] Re: Posting from Radio to Blogger.com ... via Atom API
...


> got my first successful post to the Atom API on blogger.com from
Radio...

An Atom API posting interface is a great addition to Radio. Would you
consider sharing your code, may be include it in a tool ?

Cheers

Marc





Yahoo! Groups Links

Scott C. Lemon wrote:
> While working on my new RadioAtomBridge tool, I found some "bugs" in
> these two verbs:
>
> xml.entityDecode:  In reviewing the code, it does not handle the
> " " encoded space.  This is a real problem.  I was able to "fix"
> this be simply adding "s = string.replaceall (s, " ", " ")" at the
> end of this code.  Does anyone see any issues with doing this?

  is not an XML entity. The function is quite, ah, incomplete, but
given what it is, that is not incorrect behavior.

(You're "supposed" to read the entities out of the DTD for the document
type. However, the ones that the function does, IIRC, are the ones
defined for pure XML.)

> xml.entityEncode:  As a mirror of the "bug" above, the xml.entityEncode
> does not seem to encode properly when multiple consecutive spaces are
> found in a string.  Usually, all but one of these spaces is converted to
>   encodings.  In this code there does not appear to be any checking
> for multiple consecutive spaces.  I haven't done anything about this one
> yet.

Along with the same point applying here again, that this is an XML verb
and you're talking HTML, there is *another* problem here that
xml.entityEncode can't really solve for you, even in principle. Several
spaces in a row is perfectly legitimate HTML. That *you* want  s is
not knowable to xml.entityEncode. (In fact, the general problem of
re-coding entities from text is, AFAIK, an unsolved one, short of
working in pure DOM at all times.) You need to add those yourself if you
know you want them.

I don't know if you can find an HTML encoding function lying around that
will do what you want. You can crib from the xml.*code verbs, if you
like; just watch the order the & gets encoded in. (First to be encoded,
last to be decoded.) Be careful with this encoding stuff... Here There
Be Dragons. Double check your resulting code can double-encode and
double-decode test strings correctly... generally if you can do that
it's working right. (i.e., for all fancy strings "x" you can cook up,
yourDecode(yourDecode(yourEncode(yourEncode(x)))) == x ... A *lot* of
bugs can slip by just one iteration. Slap that in a for loop, and
iterate on a list of ugly strings, and you've got decent test there. A
list of ugly strings I used for the Jabber driver can be found somewhere
in that code.)

Yes ... I'm actually completing the code as a new tool, as a fork of the
xManilaBloggerBridge tool ...

I'm hoping to complete that in the next couple of days, or over the weekend.
I'll put a copy out to the world and would love feedback ...

It's something that I wanted for a while ... Finally got motivated enough to
hack it out!  :-)


Scott C. Lemon




-----Original Message-----
From: radio-dev@yahoogroups.com [mailto:radio-dev@yahoogroups.com] On Behalf
Of Marc Barrot
Sent: Thursday, June 02, 2005 1:53 PM
To: radio-dev@yahoogroups.com
Subject: [radio-dev] Re: Posting from Radio to Blogger.com ... via Atom API
...


> got my first successful post to the Atom API on blogger.com from
Radio...

An Atom API posting interface is a great addition to Radio. Would you
consider sharing your code, may be include it in a tool ?

Cheers

Marc





Yahoo! Groups Links

> got my first successful post to the Atom API on blogger.com from
Radio...

An Atom API posting interface is a great addition to Radio. Would you
consider sharing your code, may be include it in a tool ?

Cheers

Marc

Scott:

You are correct, there is optimized upstreaming code currently in beta
that addresses this issue. You can download and try it out here:

http://groups.yahoo.com/group/radio-dev/message/8357

Cheers!
Patrick

--- In radio-dev@yahoogroups.com, "Scott C. Lemon" <Scott.Lemon@H...>
wrote:
> I have long tried to "fix" the broken situation on my copy of Radio,
where -
> for what ever reason - it *always* does the checks for upstreaming
every 10
> seconds.  Although I have set the parameter on the prefs page:
> http://127.0.0.1:8080/system/pages/prefs?page=1.4 to be "300" seconds (5
> minutes) I notice the constant 10 second pounding of my CPU.
>
> I spent some time this morning to investigate, and found that
according to
> the way I read the code, this 300 second interval - which is stored in
> user.radio.prefs.upstream.secsBetweenChecks will simply never be used.
>
> According to how I read the code, the
system.verbs.builtins.radio.init block
> has the following code:
>
>  bundle //thread prefs
>
> * if not defined (user.radio.prefs.thread)
>
> * new (tabletype, @user.radio.prefs.thread)
>
> * if not defined (user.radio.prefs.thread.secsBetweenChecks)
>
> * if defined (user.playlist.data.upstream.secsBetweenChecks)
>
> * user.radio.prefs.thread.secsBetweenChecks =
> user.playlist.data.upstream.secsBetweenChecks
>
> * else
>
> * user.radio.prefs.thread.secsBetweenChecks = 10
>
> * if not defined (user.radio.prefs.thread.minuteToDoHourlyScan)
>
> * if defined (myUserLandData.prefs.minuteToDoHourlyScan)
>
> * user.radio.prefs.thread.minuteToDoHourlyScan =
> myUserLandData.prefs.minuteToDoHourlyScan
>
> * else
>
> * user.radio.prefs.thread.minuteToDoHourlyScan = 0
>
> * if defined (radio.thread.agents.getServerCapabilities) //obsolete
>
> * delete (@radio.thread.agents.getServerCapabilities)
>
> The core point here is that the line that states "if not defined
> (user.radio.prefs.thread.secsBetweenChecks) ...
>
> On my system ... this *is* defined ... as 10 seconds!  So then the lines
> following never are executed ... correct?
>
> So this never gets set to my preference of 300 seconds that is saved in
> user.radio.prefs.upstream.secsBetweenChecks!  In fact, again looking
at the
> code above, even if the thread.secsBetweenChecks was *not* defined
... my
> pref would *still* not be used since it is being set to
> user.PLAYLIST.DATA.upstream.secsBetweenChecks. ?? ??
>
> I'm just trying to understand if I am completely off base, or if
this is the
> correct place to manually change the interval ... is this the value
that is
> being used, and causing these 10 second poundings?  Am I accurate in my
> assessment that I can change this thread value to 300 to change this
to be 5
> minutes?
>
> Comments?  Ideas?
>
> Thanks!
>
> Scott C. Lemon

--- In radio-dev@yahoogroups.com, Lawrence Lee <lawrence@u...> wrote:
> We released a fix for the upstreamScanFolder callback that caused custom
> folders from never being upstreamed.


status using radio categories with upstream beta 06

Mac OS X
local file upstream driver

No longer gets caught in endless loop in categories.

BUT: if the "home page" selection is not checked,  but another is...
it upstreams the old content.  I have not tried this with "upstream
only after publishing".

CPU load appears to be improved; ranges from 7% to about 54%.

http://jaihome.myvnc.com/categories/radiotest/
http://jaihome.myvnc.com/categories/myInterests/
http://jaihome.myvnc.com/

We released a fix for the upstreamScanFolder callback that caused custom
folders from never being upstreamed.

*** How do I install it?

Important: Quit Radio and backup the entire Radio UserLand folder.  This is
good practice before installing any beta software or tools.

1. Download this file and save it to disk:

http://lawrence.userland.com/radioParts/upstreamingBeta06.fttb

2. Import the beta parts into Radio using the Open command in Radio's File
menu.

3. In the QuickScript window (Ctrl-;), run the following script:

workspace.upstreamingBeta06.installer ()

If you need to remove the beta parts, you can run the following command in a
QuickScript command to restore the original parts (prior to installing of
the beta parts):

workspace.upstreamingBeta06.installer (false)

On 5/17/05, Jeff Imig <jeff@...> wrote:

>  I was just happy the uninstall works.

Thank Patrick Ritchie for that....he wrote the code...  :)

--
Steve Kirks
Product Manager, Radio UserLand
http://steve.userland.com/

I'll be trying it again.

The endless loop did finally quit... but it took about an hour.

I was just happy the uninstall works.

	 Jeff

On May 17, 2005, at 8:24 PM, Steve Kirks wrote:

> Jeff:
>
> Beta 6 will ship tomorrow....
>
> Steve
>
> On 5/17/05, Forest Oak <jeff@...> wrote:
>>>> In the meantime, we're still interested by reports about the current
>>>> beta's behaviour.
>>>>
>>>> Marc
>>>
>>> Hmm... I'm having a situation where categories starts upstreaming in
>>> an endless loop.
>>>
>>
>>  I've uninstalled the upstreaming beta,  & now my home index.html is
>>  getting published, but the endless loop of publishing & republishing
>>  the categories is still happening.
>>
>>    :-(
>>
>>
>>
>>
>>
>>
>>  ________________________________
>>  Yahoo! Groups Links
>>
>> To visit your group on the web, go to:
>> http://groups.yahoo.com/group/radio-dev/
>>
>> To unsubscribe from this group, send an email to:
>> radio-dev-unsubscribe@yahoogroups.com
>>
>> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
> --
> Steve Kirks
> Product Manager, Radio UserLand
> http://steve.userland.com/
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
____________________________________________________

   see http://jaihome.myvnc.com for latest news & views in my life

____________________________________________________

Jeff:

Beta 6 will ship tomorrow....

Steve

On 5/17/05, Forest Oak <jeff@...> wrote:
>  > > In the meantime, we're still interested by reports about the current
>  > > beta's behaviour.
>  > >
>  > > Marc
>  >
>  > Hmm... I'm having a situation where categories starts upstreaming in
>  > an endless loop.
>  >
>
>  I've uninstalled the upstreaming beta,  & now my home index.html is
>  getting published, but the endless loop of publishing & republishing
>  the categories is still happening.
>
>    :-(
>
>
>
>
>
>
>  ________________________________
>  Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/radio-dev/
>
> To unsubscribe from this group, send an email to:
> radio-dev-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
Steve Kirks
Product Manager, Radio UserLand
http://steve.userland.com/

> > In the meantime, we're still interested by reports about the current
> > beta's behaviour.
> >
> > Marc
>
> Hmm... I'm having a situation where categories starts upstreaming in
> an endless loop.
>

I've uninstalled the upstreaming beta,  & now my home index.html is
getting published, but the endless loop of publishing & republishing
the categories is still happening.

   :-(

--- In radio-dev@yahoogroups.com, "Marc Barrot" <marc@p...> wrote:
> "Marc Barrot" <marc@p...> wrote:
> > I won't make modifications to a potential beta06 till I've had more
> > feedback from the current version.
>
> Well, meanwhile I've managed to replicate the bug evidenced by Steve
> and  locate its origin: a rather obvious mistake in
> radio.upstream.uploadChangedFiles.
>
...
> In the meantime, we're still interested by reports about the current
> beta's behaviour.
>
> Marc

Hmm... I'm having a situation where categories starts upstreaming in
an endless loop.

It's alphabetic though,  because if something comes before
"categories" it gets published,  so there's something in my categories
that's holding up business.

for example  http://jaihome.myvnc.com/index.html (the default) never
gets published,  but http://jaihome.myvnc.com/aaindex.html does as do
the categories.

I am using the upstreaming beta.

This MAY be related to other problems I've been struggling with for a
long time.  I believe I found recently that I had my "urls & folders"
set wrong,  particularly the "folders" part.

I need to dig out Rogers' book & review categories (yet again).

Mac OS X 10.3.9,  G4  400mhz.

    Jeff Imig

Hi Patrick

On 5/10/05, Patrick Ritchie <flashblade@...> wrote:
> Slight correction to below, if you want to run doHourlyTask manually
> you have to setup the global tables it expects first.
>

Thanks for that.  It turns out I had a problem in my background script
but confusingly it didn't error and, for some reason, although I put a
msg() in the scheduler.monitor script it didn't appear leading me to
believe that background script execution had stopped.

It's all working well now thanks.

M

--
Matt Mower :: http://matt.blogs.it/

Slight correction to below, if you want to run doHourlyTask manually
you have to setup the global tables it expects first.

If you want to debug this way, use scheduler.monitor as a guide on how
to set things up.

Cheers!
Patrick

> Hey Matt,
>
> You can't run system.verbs.builtins.scheduler.doHourlyTasks manually,
> it needs to be called by system.verbs.builtins.scheduler.monitor which
> sets up some globals.
>
> Specifically taskInfo is a sub-table of logtable...
>
> If you set user.scheduler.prefs.keepLog to true you should get some
> information about why your everyHour script is not being run...
>
> Cheers!
> Patrick
>
> > Hi,
> >
> > In one my tools I have a simple background.everyHour script which
> > doesn't seem to be run.  I've confirmed that it is listed in
> > user.scheduler.hourly.  In fact I'm not sure any of the background
> > scripts are run.
> >
> > To test this out I tried to debug:
> >
> >   system.verbs.builtins.scheduler.doHourlyTasks
> >
> > However this script blows up with an error:
> >
> >   Can't find a sub-table named "taskInfo".
> >
> > At the line:
> >
> >   new (tabletype, @taskInfo.subTaskInfo)
> >
> > And indeed I can't see where the "taskInfo" variable is springing
from.
> >
> > On the other hand this code doesn't appear to have been modified since
> > 1998 and I'm prepared to bet someone would have noticed if background
> > tasks hadn't been working for 7 years.
> >
> > Can anyone help me with this?
> >
> > M
> >
> > --
> > Matt Mower :: http://matt.blogs.it/

Hey Matt,

You can't run system.verbs.builtins.scheduler.doHourlyTasks manually,
it needs to be called by system.verbs.builtins.scheduler.monitor which
sets up some globals.

Specifically taskInfo is a sub-table of logtable...

If you set user.scheduler.prefs.keepLog to true you should get some
information about why your everyHour script is not being run...

Cheers!
Patrick

> Hi,
>
> In one my tools I have a simple background.everyHour script which
> doesn't seem to be run.  I've confirmed that it is listed in
> user.scheduler.hourly.  In fact I'm not sure any of the background
> scripts are run.
>
> To test this out I tried to debug:
>
>   system.verbs.builtins.scheduler.doHourlyTasks
>
> However this script blows up with an error:
>
>   Can't find a sub-table named "taskInfo".
>
> At the line:
>
>   new (tabletype, @taskInfo.subTaskInfo)
>
> And indeed I can't see where the "taskInfo" variable is springing from.
>
> On the other hand this code doesn't appear to have been modified since
> 1998 and I'm prepared to bet someone would have noticed if background
> tasks hadn't been working for 7 years.
>
> Can anyone help me with this?
>
> M
>
> --
> Matt Mower :: http://matt.blogs.it/

Hi,

In one my tools I have a simple background.everyHour script which
doesn't seem to be run.  I've confirmed that it is listed in
user.scheduler.hourly.  In fact I'm not sure any of the background
scripts are run.

To test this out I tried to debug:

   system.verbs.builtins.scheduler.doHourlyTasks

However this script blows up with an error:

   Can't find a sub-table named "taskInfo".

At the line:

   new (tabletype, @taskInfo.subTaskInfo)

And indeed I can't see where the "taskInfo" variable is springing from.

On the other hand this code doesn't appear to have been modified since
1998 and I'm prepared to bet someone would have noticed if background
tasks hadn't been working for 7 years.

Can anyone help me with this?

M

--
Matt Mower :: http://matt.blogs.it/

Hey Matt,

I considered doing that but then then you break backwards
compatibility, so it's not a fix we could release...

But in your specific situation it may save you a few clock cycles.

Can't help you with the bandwidth problem though ;)

Cheers!
Patrick

--- In radio-dev@yahoogroups.com, Matt Mower <matt.mower@g...> wrote:
> On 5/7/05, Patrick Ritchie <flashblade@v...> wrote:
> > Glad I could help out :)
> >
>
> It's made a big difference.  Now if you could only figure out how to
> queeze the 534 xml files I generate through my upstream bandwidth
> faster ;-)
>
> I did make one minor modification to the encoding function: I've moved
> the alpha entities into a copy of the replacements table.  The code
> then selects which replacements table to use based upon the
> flAlphaEntities parameter.
>
> I haven't timed it but I assume it will be a smidgeon quicker than
> using the replaceAll() calls and it looked neater to my eye.  I put it
> in workspace.entityEncode2 so it won't overwrite the original.  It's
> in the files section also.
>
> Regards,
>
> Matt
>
> --
> Matt Mower :: http://matt.blogs.it/

On 5/7/05, Patrick Ritchie <flashblade@...> wrote:
> Glad I could help out :)
>

It's made a big difference.  Now if you could only figure out how to
queeze the 534 xml files I generate through my upstream bandwidth
faster ;-)

I did make one minor modification to the encoding function: I've moved
the alpha entities into a copy of the replacements table.  The code
then selects which replacements table to use based upon the
flAlphaEntities parameter.

I haven't timed it but I assume it will be a smidgeon quicker than
using the replaceAll() calls and it looked neater to my eye.  I put it
in workspace.entityEncode2 so it won't overwrite the original.  It's
in the files section also.

Regards,

Matt

--
Matt Mower :: http://matt.blogs.it/

"Marc Barrot" <marc@p...> wrote:
> I won't make modifications to a potential beta06 till I've had more
> feedback from the current version.

Well, meanwhile I've managed to replicate the bug evidenced by Steve
and  locate its origin: a rather obvious mistake in
radio.upstream.uploadChangedFiles.

In the inner fileloop of the folderloop function, we check each
entry's last character: if it's a path separator, we cleverly deduct
the entry is a folder and proceed to call the folderloop function
recursively.

Well, recursion is tricky, or rather we've been a little careless:
when the code returns from its recursive call to folderloop, variable
f is restored to its initial pre-call value. f contains the path of a
folder - we've just looped through its content - so we should not be
executing the remaining folderloop lines in this iteration of the
fileloop.

In short, we forgot to place an else statement after testing for a
folder entry.

I'll prepare an optimized and corrected beta06 component over the
week-end, for distribution by Userland next week I expect.

In the meantime, we're still interested by reports about the current
beta's behaviour.

Marc

Hi Matt,

Glad I could help out :)

Cheers!
Patrick

> Hi Patrick,
>
> On 5/6/05, Patrick Ritchie <flashblade@v...> wrote:
> > Kernelization would be best, but string.multipleReplaceAll isn't bad
> > either.
> >
>
> As you say, kernelization would be ideal.  Neverthless I am grateful
> for you taking the time to look at this and for coming up with a neat
> improvement.
>
> > Initial testing results are that this method is ~3x faster.
> >
>
> Anecdotally that seems to be what i'm seeing.  Much better.
>
> Again, many thanks for doing this.
>
> Regards,
>
> Matt
>
> --
> Matt Mower :: http://matt.blogs.it/

Hi Patrick,

On 5/6/05, Patrick Ritchie <flashblade@...> wrote:
> Kernelization would be best, but string.multipleReplaceAll isn't bad
> either.
>

As you say, kernelization would be ideal.  Neverthless I am grateful
for you taking the time to look at this and for coming up with a neat
improvement.

> Initial testing results are that this method is ~3x faster.
>

Anecdotally that seems to be what i'm seeing.  Much better.

Again, many thanks for doing this.

Regards,

Matt

--
Matt Mower :: http://matt.blogs.it/