AltME groups: search

I remember that most platforms account real scheduler timeslices 
in this function, while some basically take wall clock time

That's stable scheduler timing. Problem solved, I guess, but not 
a good verdict for Windows

http://softinnov.org/rebol/scheduler.shtml

Very nice the scheduler, but I have not understand if it blocks program 
activity while waiting and if no why. I have solved my problem by 
using a View timer (face/rate: 0:0:1) since that does not block program 
activity.

The scheduler lives in the event loop, so it does not block event-based 
apps.

the service is a simple test:

install-service [
  name: 'test
  port-id: 9000
  module: 'my-module

  on-load: func[] [
    do %scheduler.r
    scheduler/plan [every 10 s do my-func]
    scheduler/wait
  ]
  on-task-done: func[data] [print data]
  my-func: func[][
    data: load datafile
    foreach [key value] data [
      shared/do-task [value] self
    ]
  ]
]

Ok, from the UniServe folder, this code works:

    uniserve-path: %./
    do %uni-engine.r
    uniserve/boot

I had to change your absolute path in %reminder.r to:

- line 11:   do uniserve-path/libs/scheduler.r
- line 24:   feeds: load uniserve-path/docs/feeds.r

In %reminder.r, you shouldn't use: scheduler/wait. Uniserve is already 
providing an event loop. You need to remove that line.

removed the scheduler/wait line...now:

uniserve-path: %./
== %./
>> do %uni-engine.r
Script: "UniServe kernel" (17-Jan-2010)
Script: "Encap virtual filesystem" (21-Sep-2009)
== true
>> uniserve/boot
booya
** Script Error: Invalid path value: server-ports
** Where: reform
** Near: mold any [uniserve/shared/server-ports port-id]
>>

From that, it seems to work until the job event is raised, then the 
server crashes (not sure if it's your code, scheduler or Uniserve 
that causes that).

just to persist with using uniserve...i think something i may be 
getting there

uniserve-path: %./
== %./
>> do %uni-engine.r
Script: "UniServe kernel" (17-Jan-2010)
Script: "Encap virtual filesystem" (21-Sep-2009)
== true
>> uniserve/boot
booya
127.0.0.1
127.0.0.1
== none
>>

i commented out the lines from on-started:

on-started: has [file][
		worker-args: reform [

   "-worker" mold any [in uniserve/shared 'server-ports port-id]		;TBD: 
   fix shared object issues
		]
		if not encap? [
			append worker-args reform [" -up" mold uniserve-path]
			if value? 'modules-path [
				append worker-args reform [" -mp" mold modules-path]
			]
			if all [
				uniserve/shared
				;file: uniserve/shared/conf-file 
			][		
				;append worker-args reform [" -cf" mold file]
			]
		]
		if integer? shared/pool-start [loop shared/pool-start [fork]]
	]

...since conf-file is cheyenne specific


i think maybe the scheduler is killing UniServe - it exits while 
returning none...

nope - the scheduler is just fine...

i'm now thinking it may have to do with using the shared/do-task 
in the on-load function...

Scheduler library released (see Announce channel). A few words about 
that :


- it allows you to program deferred tasks (like night batchs or short-term 
tasks like sending a mail in 10 minute from now).

- it's feature-close to CRON or QUARTZ java library (not covering 
100% yet).

- it needs a lot of additional testing before using it in production 
for critical tasks.

- some issues are not yet addressed like tasks execution overlapping 
over other tasks events, daylight saving gaps or system time changes.
- minimum delay between 2 events is 1 second.

- maximum delay between 2 events is 9999 hours (a little more than 
a year)

- event loop is currently a custom one, next version will add 'do-events 
patching for a easier and more transparent integration with View 
or network apps.

Sounds so cool :-) I was just in need to produce simple scheduler 
for power-point  replay of multiple files, so I will look into your 
script :-)

Precisely, I'm working on a scheduler lib for UniServe and I was 
wondering if I could wait for date!, but it looks like not.

This issue is making my scheduler lib useless for general purpose 
usage (won't work for jobs scheduled in more than 24 days). As usual, 
stuck at 99% of the goal...

This is part of my scheduler dialect

away-days  is a block of [ start-date end-date reasons ]
current-date is the date I am looking at

The syntax is

away 25-Dec-2005 on holiday
away 25-Dec-2005
away from 25-Dec-2005 to 7-Jan-2006 on "summer holidays"

I want to add

away every Wednesday at "golf course"

- A new scheduler, which makes things like audio and video much more 
usable. You can now keep using the system for other tasks while playing 
multimedia. In fact, we can now easily replicate the famous BeOS 
demo with six videos running at the same time

We have a new audio framework in userspace, but our scheduler still 
needs to be improved

The real boot code is GrUB. There must be assembler in there, but 
it's out of our hands. We have a bit of assembler code that are probably 
small pieces of our part of the boot process, and maybe things like 
the scheduler

BTW a similar scheduler was written by a hig priest and was quickly 
included. quite unfair. and the article is about kernel, not desktop, 
as con mentions in comments

But a user-oriented scheduler versus a server-oriented scheduler 
(as Kaj mentioned with Syllable already on the crest) will be the 
next wave in Desktop Linux, umm, I hope.

A scheduler is not much use if the rest of the system doesn't present 
meaningful pieces to schedule

Major apps like Thunderbird and REBOL effectively locking the rest 
of the system means that the system is not meaningfully handling 
apps in a concurrent way, so I would venture to say that the scheduler 
has very little if any effect on this

In fact, Syllable used to have a very primitive scheduler and was 
already as responsive as now, except for some corner cases

MULTITHREAD DEMO for REBOL (you can esyly transform this to a lib-thread 
by puting scheduler and Rthread object and related data to a lib-thread.r 
file) I think this could be very interresting if it would be added 
into REBOL VM. Work have been make by François Jouen  you can download 
it hrere: http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=threaddemo.r

Jobs scheduler library for REBOL (1st beta) : http://softinnov.org/dl/scheduler-r090.zip
- see %scheduler.r header for quick doc & samples

- please use [All] channel for replies and discussions about this 
library

this would be a quick complement for scheduler based application

Graham - nice interface - what widget is used for the scheduler displaying 
time slots?

So - R3's kernel is imo just cross-platform library, but nothing 
like OS kernel, where you normally need scheduler, timers, tasks, 
etc - those will be external here (open source), but essential - 
rebol kernel means nothing separately here - it can't run without 
them ...

Q3 : Not yet. It's a planned feature that I need also to add a simple 
CRON-like task scheduler inside Cheyenne. Feel free to add your own 
in your mod, I don't that I'll have time to work on it before middle 
summer (low priority task).

SVN r15

FEAT: scheduler lib added
FEAT: 'job config keyword added (CRON-like jobs)

FIX: cheyenne freezing on exiting (only if config reloading was used)

Warning: the scheduler integration with Cheyenne is at beta stage, 
minimaly tested, so if you want to put it in production, take the 
time to test it well.

But the scheduler is still very fresh, no logging, not much tested,...

Is this scheduler part of Cheyenne or Uniserve?  Just not sure what 
it has to do with Cheyenne

Something I'd like to do is run a backup of my database, compress 
it and upload it to S3.  I use a script for that at the moment .. 
so maybe I can use the scheduler.

Scheduler is a standalone library. Cheyenne uses it to manage jobs 
defined in config file. UniServe will use it for example, to retry 
sending emails after x minutes.

The scheduler doesn't spawn any new process by itself. When you specify 
an action, you can use CALL or LAUNCH in the action code to run your 
task in background. You can also use a URL pointing to a local CGI 
or RSP script (making it run in the background using one of the task-master 
worker processes).

A few words about the new MTA and email capabilities :


- Emails are written to disk before sending in async mode. Upper 
email size limit is 2GB. Concurrent emails sending supported (limited 
only by machine resources).

- Only the higher priority MX is used (fallback on others MX should 
be added soon).

- The MTA currently supports only 8BITMIME compliant SMTP servers 
(fallback to 7bit mode will be added if it still make sense to support 
it).

- MTA will  try to send an email once. If the server is busy, it 
will report a failure. Deferred retries will be added using the scheduler 
module (if MX fallback is not enough).

- Emails queue saving should be added in next update (the queue will 
survive to server restart, but not server crash).

- Automatic failure reports are sent back to emitter (From: field).
- Reports can be fully customized.

- Still needs a lot of testing for tracking small errors or issues 
that can trigger antispam filters (e.g. gmail is very picky about 
correct emails format).


You can test it using the provided test script : http://localhost/email.rsp

Re: greylisting, the plan was to use the freshly integrated scheduler 
library : scheduler/add [in 5 mn do [resend <email-id>]]

Tried: going to try it today, scheduler is working ok inside Cheyenne, 
just need to add more logging info.

in MTA.r, line 135 change this line

						scheduler/plan compose/only/deep only  [

to 

						scheduler/plan compose/only/deep [

SVN r27

FIX: better integration of scheduler in Cheyenne's event loop.
FIX: bug fixes in deferred task (MX or SMTP retries)

Terry, in the ws framework I'm working on, there will be a timer 
system with an on-timer handler that you can use for server-side 
events (timer ticks are produced by my scheduler library http://softinnov.org/rebol/scheduler.shtml
recently integrated in Cheyenne).

Doc, the scheduler dialect is great. Wonder why it wasn't thought 
of before.
I was considering purchasing a copy of nnCron this week.

Terry: I've asked myself the same question while implementing this 
scheduler lib this summer, I couldn't believe that no one did it 
before in ten years...that the bad side of having a micro-community 
(one of the good side is not seeing guys like Ratio popping up too 
often).

Steeve seemed to imply that R3 has its own thread scheduler. Is that 
true?

There's also now the ability to define a timer per socket application 
to generate server-side events (powered by my scheduler library).

SVN r51
FEAT: /ws-apps folders are now protected from direct access.

FEAT: modified socket apps source files are reloaded and used by 
new clients.

FIX:  web socket application's 'session object renamed to the more 
accurate 'rsp-session.
FIX:  'do-task calls now supported in 'on-timer handler.
FIX:  scheduler issue with deleted jobs.

It depends on the type of the "action" part of the job rule. Here's 
what does the scheduler by default (UniServe/libs/scheduler.r):

	url!   	  [read action]
	block! 	  [do action]
	file! 	  [launch action]
	function! [do :action]
	word!	  [do get :action]

You can just pass a block! value as a job to the scheduler and call 
your code from there, it would be cleaner than hacking in on-timer.

Doc: "You can just pass a block! value as a job to the scheduler 
and call your code from there, it would be cleaner than hacking in 
on-timer."

How do I interact with "clients" connected via ws inside a "job" 
block?

I have "clients" block in on-timer event and I able to send messages 
to them. Is it possible from jobs?

but why no small own tasking? We want WildMan, right? It will need 
its own tasking/scheduler :-)