headers
Martin Vuille | 4 Aug 21:35

FSM Review Announcement

The formal review for Andrey Semashev's Finite State Machines (FSM) 
library is scheduled for August 11th to 20th.

Quoting from the documentation:

"The main goals of the library are:

* Simplicity. It should be very simple to create state machine
  using this library. 
* Performance. The state machine infrastructure should not be very 
  time and memory-consuming in order to be applicable in more use
  cases. 
* Extensibility. A developer may want to add more states to the
  existing state machine, and this addition should be relatively
  safe since it shouldn't interfere with the existing states. The
  developer should also be able to specify additional transitions
  and events for the machine with minimum modifications to the
  existing code."

"The following compilers are known to have problems or most likely
will have ones:

* Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to
  compile due to lack of partial template specialization support.
* Borland C++ Builder 5.5.1 (free version). Fails to compile due
  to lack of partial template specialization and in-class using
  declarations support. Some other minor problems also have been
  noticed. Newer versions of the compiler have not been tested.
* OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL
  code. Newer versions of the compiler have not been tested.
(Continue reading)

Permalink | Reply |
headers
Giovanni Piero Deretta | 5 Aug 10:17

Re: FSM Review Announcement

On Mon, Aug 4, 2008 at 9:36 PM, Martin Vuille <martin <at> jpmvrealtime.com> wrote:
> The formal review for Andrey Semashev's Finite State Machines (FSM)
> library is scheduled for August 11th to 20th.
>
<snip>
> The current submission is available from the sandbox vault at
> http://tinyurl.com/yjozfn (or
> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip
> &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1,
> if you prefer.)
>

Are the docs available online somewhere?

--

-- 
gpd
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Andrey Semashev | 5 Aug 19:36

Re: FSM Review Announcement

Giovanni Piero Deretta wrote:
> On Mon, Aug 4, 2008 at 9:36 PM, Martin Vuille <martin <at> jpmvrealtime.com> wrote:
>> The formal review for Andrey Semashev's Finite State Machines (FSM)
>> library is scheduled for August 11th to 20th.
>>
> <snip>
>> The current submission is available from the sandbox vault at
>> http://tinyurl.com/yjozfn (or
>> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip
>> &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1,
>> if you prefer.)
>>
> 
> Are the docs available online somewhere?

Sorry, the library is not hosted anywhere. I wonder if libraries in the 
Boost sandbox have some hosting for docs?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Frank Mori Hess | 5 Aug 20:05

Re: FSM Review Announcement


On Tuesday 05 August 2008 13:36 pm, Andrey Semashev wrote:
> >
> > Are the docs available online somewhere?
>
> Sorry, the library is not hosted anywhere. I wonder if libraries in the
> Boost sandbox have some hosting for docs?

I don't know if it's a recommended practice for the sandbox, but if you commit 
your html to the sandbox, it's available to any web browser by pointing it 
directly at the svn URL.  For example, there is some html checked into the 
boost_docs part of the sandbox:

http://svn.boost.org/svn/boost/sandbox/boost_docs/trunk/tools/boostbook/doc/html/index.html
Permalink | Reply |
headers
Eric Niebler | 5 Aug 20:54

Re: FSM Review Announcement

Frank Mori Hess wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 05 August 2008 13:36 pm, Andrey Semashev wrote:
>>> Are the docs available online somewhere?
>> Sorry, the library is not hosted anywhere. I wonder if libraries in the
>> Boost sandbox have some hosting for docs?

You can put your docs at http://boost-sandbox.sf.net/. Just ssh into 
shell.sf.net, cd to /home/groups/b/bo/boost-sandbox/htdocs, make a 
directory for your stuff (probably under libs/), then exit and use scp 
to copy your docs to the correct place.

I created the following bash script that gzips xpressive's html 
directory, pushes it to shell.sf.net, and unzips it remotely. You might 
find it useful. (Obviously, you'll need to change the username.)

#!/bin/sh

rm html.tar.gz

tar -czf html.tar.gz html

scp html.tar.gz \
eric_niebler <at> shell.sf.net:/home/groups/b/bo/boost-sandbox/htdocs/libs/xpressive/doc

ssh eric_niebler <at> shell.sf.net \
   'cd /home/groups/b/bo/boost-sandbox/htdocs/libs/xpressive/doc; \
    rm -rf html; \
(Continue reading)

Permalink | Reply |
headers
Jeremy Pack | 5 Aug 20:38

Re: FSM Review Announcement

Giovanni,

On Tue, Aug 5, 2008 at 10:36 AM, Andrey Semashev
<andrey.semashev <at> gmail.com>wrote:

> <snip>
>
>> Are the docs available online somewhere?
>>
>
> Sorry, the library is not hosted anywhere. I wonder if libraries in the
> Boost sandbox have some hosting for docs?

I've hosted the docs here:

http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html
http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html

If anyone else needs documentation hosting for potential Boost libraries, I
can donate space. The server ought to be faster than hosting them straight
from the sandbox.

Jeremy Pack
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Martin Vuille | 5 Aug 23:15

Re: FSM Review Announcement

"Jeremy Pack" <rostovpack <at> gmail.com> wrote in
news:1b251b590808051138x6ec7920v33d754c8f33fff7e <at> mail.gmail.com: 

> I've hosted the docs here:
> 
> http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html
> http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.h
> tml 
> 
> If anyone else needs documentation hosting for potential Boost
> libraries, I can donate space. The server ought to be faster than
> hosting them straight from the sandbox.
> 

Thank you very much Jeremy for taking care of this.

MV

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Jurko Gospodnetić | 5 Aug 10:52

Re: FSM Review Announcement

   Hi Martin.

> The formal review for Andrey Semashev's Finite State Machines (FSM) 
> library is scheduled for August 11th to 20th.

   What are the intended and actual differences from the already 
accepted Statechart library?

   Best regards,
     Jurko Gospodnetić

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Andrey Semashev | 5 Aug 19:43

Re: FSM Review Announcement

Jurko Gospodnetić wrote:
>   Hi Martin.
> 
>> The formal review for Andrey Semashev's Finite State Machines (FSM) 
>> library is scheduled for August 11th to 20th.
> 
>   What are the intended and actual differences from the already accepted 
> Statechart library?

The main differences are simplicity and performance. The performance 
tests show difference by an order of magnitude, in the best case for 
Boost.Statechart. The overall design of Boost.FSM is geared more to 
compile-time code generation, while Boost.Statechart aims to support 
more scaled machines and therefore is geared towards run-time. There is 
a section in the docs that compares the libraries.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Chris Knight | 5 Aug 20:30

Re: FSM Review Announcement

Andrey Semashev wrote:
> Jurko Gospodnetić wrote:
> >   What are the intended and actual differences from the already accepted
> > Statechart library?
>
> The main differences are simplicity and performance. The performance
> tests show difference by an order of magnitude, in the best case for
> Boost.Statechart. The overall design of Boost.FSM is geared more to
> compile-time code generation, while Boost.Statechart aims to support
> more scaled machines and therefore is geared towards run-time. There is
> a section in the docs that compares the libraries.

I can attest to the necessity of this. We have several exchange libraries that
require state machines to implement their data protocols but we use a 
home-brewed boost::mpl::inherit_linearly implementation because the 
features of Boost.StateChart simply brings in to many performance penalties
for our simpler usage that would fit within the Boost.FSM framework. In fact,
if I remember correctly, we used a thing on Boost.Vault called "FSM" as an 
implementation guide.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 5 Aug 23:34

Re: FSM Review Announcement


on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:

> Andrey Semashev wrote:
>> Jurko Gospodnetić wrote:
>> >   What are the intended and actual differences from the already accepted
>> > Statechart library?
>>
>> The main differences are simplicity and performance. The performance
>> tests show difference by an order of magnitude, in the best case for
>> Boost.Statechart. The overall design of Boost.FSM is geared more to
>> compile-time code generation, while Boost.Statechart aims to support
>> more scaled machines and therefore is geared towards run-time. There is
>> a section in the docs that compares the libraries.
>
> I can attest to the necessity of this. We have several exchange libraries that
> require state machines to implement their data protocols but we use a 
> home-brewed boost::mpl::inherit_linearly implementation because the 
> features of Boost.StateChart simply brings in to many performance penalties
> for our simpler usage that would fit within the Boost.FSM framework. In fact,
> if I remember correctly, we used a thing on Boost.Vault called "FSM" as an 
> implementation guide.

I don't know if you've seen the FSM examples from "C++ Template
Metaprogramming" or not.  It would be interesting for this library's
documentation to explain its advantages over that approach (I can see
some from here already).

One other thing I'd like to see is an implementation of nested states.
I once promised some people who needed that functionality that I'd
(Continue reading)

Permalink | Reply |
headers
Chris Knight | 6 Aug 00:02

Re: FSM Review Announcement

On Tuesday 05 August 2008 4:34:30 pm David Abrahams wrote:

> I don't know if you've seen the FSM examples from "C++ Template
> Metaprogramming" or not.  It would be interesting for this library's
> documentation to explain its advantages over that approach (I can see
> some from here already).
>
> One other thing I'd like to see is an implementation of nested states.
> I once promised some people who needed that functionality that I'd
> extend our framework to support them, but was never able to figure out
> what their semantics are ;-)

Nested states would be nice. I looked through the "C++ Template 
Metaprogramming" book as another reference when developing our internal 
implementation. I didn't get too fancy in our own but some protocol's like 
FIX for instance has many, many dark corners. I would see nested states as 
simply a further restriction on the matching of the from state. This could 
provide further optimizations as a well designed transition table could 
reduce the set of states to match against. However, I'm not quite sure how 
that plays out in a design with the enter/exit state handlers, transition 
handlers, et al.

The finite state machine I came up with for the FIX protocol was well over 50 
transitions. I implemented ours so that the from state could be boost::any 
which acts acts like '.' in regexps and I suppose means our implementation 
should be renamed kmt::nfsm. It was a zero-cost implentation as it simply 
adds one last transition to each from state's action linked-list.I was able 
to get the transition list down to 22 with that one feature. Mostly all the 
different error conditions that you want to handle gracefully in a text 
protocol originally designed in the 1980's and still used by finance
(Continue reading)

Permalink | Reply |
headers
Andrey Semashev | 6 Aug 16:59

Re: FSM Review Announcement

Chris Knight wrote:
> On Tuesday 05 August 2008 4:34:30 pm David Abrahams wrote:
> 
> The finite state machine I came up with for the FIX protocol was well over 50 
> transitions. I implemented ours so that the from state could be boost::any 
> which acts acts like '.' in regexps and I suppose means our implementation 
> should be renamed kmt::nfsm. It was a zero-cost implentation as it simply 
> adds one last transition to each from state's action linked-list.I was able 
> to get the transition list down to 22 with that one feature. Mostly all the 
> different error conditions that you want to handle gracefully in a text 
> protocol originally designed in the 1980's and still used by finance 
> exchanges today. <sigh>

The Boost.FSM library supports similar feature. You can use any_state 
placeholder in transitions in order to tell that the transition works 
for any source state.

> The other feature that I'm not sure whether FSM supports or not is static 
> registering of posted event types so as to skip around run-time double 
> dispatching. I suspect any implementation that seeks to provide a 
> simplified/speedier interface over StateChart should support that as well.

I'm not sure what you mean by that "registering". The library does one 
event dispatching if it is known at compile time that no entry in the 
transition map will be triggered. If a transition map entry is 
triggered, then two dispatches are done - one to deliver event to the 
transition handler, and second to deliver the event to the active state. 
In any case, dispatching is very efficient and is basically a call on a 
function pointer that is acquired from an array by index.
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Chris Knight | 6 Aug 18:48

Re: FSM Review Announcement

On Wednesday 06 August 2008 9:59:43 am Andrey Semashev wrote:
> I'm not sure what you mean by that "registering". The library does one
> event dispatching if it is known at compile time that no entry in the
> transition map will be triggered. If a transition map entry is
> triggered, then two dispatches are done - one to deliver event to the
> transition handler, and second to deliver the event to the active state.
> In any case, dispatching is very efficient and is basically a call on a
> function pointer that is acquired from an array by index.

I was referring to deferred event dispatching. I see on another thread that 
Boost.FSM does not support such a concept. I was simply noting that any
such implementation can/should be done without the use of rtti/virtuals.

Chris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Andrey Semashev | 6 Aug 19:03

Re: FSM Review Announcement

Chris Knight wrote:
> On Wednesday 06 August 2008 9:59:43 am Andrey Semashev wrote:
>> I'm not sure what you mean by that "registering". The library does one
>> event dispatching if it is known at compile time that no entry in the
>> transition map will be triggered. If a transition map entry is
>> triggered, then two dispatches are done - one to deliver event to the
>> transition handler, and second to deliver the event to the active state.
>> In any case, dispatching is very efficient and is basically a call on a
>> function pointer that is acquired from an array by index.
> 
> I was referring to deferred event dispatching. I see on another thread that 
> Boost.FSM does not support such a concept. I was simply noting that any
> such implementation can/should be done without the use of rtti/virtuals.

I don't see the connection between rtti/virtuals and event deferring. 
Anyway, in case of Boost.FSM virtual functions are only used for enter 
state handlers in case of run-time version of state switching. Type info 
is used for convenience only - it provides default state names and 
diagnostic information in case of exceptions.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Chris Knight | 6 Aug 19:23

Re: FSM Review Announcement

On Wednesday 06 August 2008 12:03:27 pm Andrey Semashev wrote:
> I don't see the connection between rtti/virtuals and event deferring.
> Anyway, in case of Boost.FSM virtual functions are only used for enter
> state handlers in case of run-time version of state switching. Type info
> is used for convenience only - it provides default state names and
> diagnostic information in case of exceptions.

template< typename T > void on_process(T const&);

void on_process_dynamic(base_event const& base)
{
	base->some_virtual();
	// or
	m_events[base->id].some_non_virtual();
}

My only point I suppose is that with a 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Chris Knight | 6 Aug 19:26

Re: FSM Review Announcement

On Wednesday 06 August 2008 12:03:27 pm Andrey Semashev wrote:
> I don't see the connection between rtti/virtuals and event deferring.
> Anyway, in case of Boost.FSM virtual functions are only used for enter
> state handlers in case of run-time version of state switching. Type info
> is used for convenience only - it provides default state names and
> diagnostic information in case of exceptions.

template< typename T > void on_process(T const&);

void on_process_dynamic(base_event const& base)
{
        base->some_virtual();
        // or
        m_events[base->id].some_non_virtual();
}

My only point was that with a little bit of help from the library, 
implementing dynamic/defferred event processing should be possible.

Chris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Andrey Semashev | 6 Aug 20:18

Re: FSM Review Announcement

Chris Knight wrote:
> On Wednesday 06 August 2008 12:03:27 pm Andrey Semashev wrote:
>> I don't see the connection between rtti/virtuals and event deferring.
>> Anyway, in case of Boost.FSM virtual functions are only used for enter
>> state handlers in case of run-time version of state switching. Type info
>> is used for convenience only - it provides default state names and
>> diagnostic information in case of exceptions.
> 
> template< typename T > void on_process(T const&);
> 
> void on_process_dynamic(base_event const& base)
> {
>         base->some_virtual();
>         // or
>         m_events[base->id].some_non_virtual();
> }
> 
> My only point was that with a little bit of help from the library, 
> implementing dynamic/defferred event processing should be possible.

Sorry, I still don't get it. You already can pass events with virtual 
functions and process them through base classes. The main problem with 
deferred events is that there's nobody to call process(deferred_event) 
of the FSM. Another problem is that you generally don't know the 
complete FSM type in states or transitions, but this issue is solvable 
with a change in the state and transition base classes.

Could you elaborate your point, please?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Chris Knight | 7 Aug 00:44

Re: FSM Review Announcement

On Wednesday 06 August 2008 1:18:33 pm Andrey Semashev wrote:
> Chris Knight wrote:
> > template< typename T > void on_process(T const&);
> >
> > void on_process_dynamic(base_event const& base)
> > {
> >         base->some_virtual();
> >         // or
> >         m_events[base->id].some_non_virtual();
> > }
> >
> > My only point was that with a little bit of help from the library,
> > implementing dynamic/defferred event processing should be possible.
>
> Sorry, I still don't get it. You already can pass events with virtual
> functions and process them through base classes. The main problem with
> deferred events is that there's nobody to call process(deferred_event)
> of the FSM. Another problem is that you generally don't know the
> complete FSM type in states or transitions, but this issue is solvable
> with a change in the state and transition base classes.
>
> Could you elaborate your point, please?

I think you basically have it. I agree that the deferred event processing
while (events_to_process) { fsm.process_dynamic(event); } shouldn't be 
included in boost.FSM, the process_dynamic(event_c& const) function should 
be.

Using the TagV in the event_c class, it should be possible to provide a member 
function in state_machine to process events given only a reference to the
(Continue reading)

Permalink | Reply |
headers
Andrey Semashev | 7 Aug 17:58

Re: FSM Review Announcement

Chris Knight wrote:
> On Wednesday 06 August 2008 1:18:33 pm Andrey Semashev wrote:
>> Sorry, I still don't get it. You already can pass events with virtual
>> functions and process them through base classes. The main problem with
>> deferred events is that there's nobody to call process(deferred_event)
>> of the FSM. Another problem is that you generally don't know the
>> complete FSM type in states or transitions, but this issue is solvable
>> with a change in the state and transition base classes.
>>
>> Could you elaborate your point, please?
> 
> I think you basically have it. I agree that the deferred event processing
> while (events_to_process) { fsm.process_dynamic(event); } shouldn't be 
> included in boost.FSM, the process_dynamic(event_c& const) function should 
> be.
> 
> Using the TagV in the event_c class, it should be possible to provide a member 
> function in state_machine to process events given only a reference to the 
> event_c base class and that calls the appropriate process(event& const) via 
> dispatching on the integer TagV. 

I see. However, tags are not a good candidate to dispatch events on 
since different events can have same tags. I think, the event itself 
should contain enough information to be dispatched after being postponed.

BTW, you can achieve the same functionality right now if you bind the 
event to the process function of the FSM and save the call into 
boost::function.

> I'm trying to figure out whether this would be a simple feature addition or
(Continue reading)

Permalink | Reply |
headers
Chris Knight | 7 Aug 18:14

Re: FSM Review Announcement

On Thursday 07 August 2008 10:58:21 am Andrey Semashev wrote:
> I see. However, tags are not a good candidate to dispatch events on
> since different events can have same tags. I think, the event itself
> should contain enough information to be dispatched after being postponed.
>
> BTW, you can achieve the same functionality right now if you bind the
> event to the process function of the FSM and save the call into
> boost::function.

I never thought of that one. Maybe a little mention in the Documentation would 
be good. I imagine other potential users might want to do the same.

> I think, this would be an interesting feature to add in future releases.
> I won't be able to implement it before the review. State and transition
> base classes will have to be extended, in order to allow to postpone
> events. State machine and event classes will have to be modified too.

Yeah, something like EventID and TransactionID in each event and transaction 
would be nice along with I imagine a deferred_state_machine and a 
deferred_lock_state_machine

Thanks,
Chris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Andrey Semashev | 7 Aug 19:47

Re: FSM Review Announcement

On Thursday 07 August 2008 20:14:32 Chris Knight wrote:
> On Thursday 07 August 2008 10:58:21 am Andrey Semashev wrote:
> > I see. However, tags are not a good candidate to dispatch events on
> > since different events can have same tags. I think, the event itself
> > should contain enough information to be dispatched after being postponed.
> >
> > BTW, you can achieve the same functionality right now if you bind the
> > event to the process function of the FSM and save the call into
> > boost::function.
>
> I never thought of that one. Maybe a little mention in the Documentation
> would be good. I imagine other potential users might want to do the same.

Ok, I will.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Chris Knight | 6 Aug 00:12

Re: FSM Review Announcement

After a little more thought, I believe I can explain what the semantics might be. The following is the state
machine for the finance exchange protocol. You will notice the "selfSyncWait" 
and "peerSyncWait" states. These states exist only to express the further restriction of matching events
while protocol level message syncing is executed immediately following session 
authentication. 

Syntactic sugar to more cleanly express that sort of "synthetic" state would be nice. Instead of giving the
states names, they would simply be expressed as anonymous sub-states 
within the layout of the transition table.

    typedef boost::mpl::list25<
     transition<any,           events::MessageRecv,         disconnected,  &Machine::handle_message_unexpected>,
     transition<any,           events::SessionRejectRecv,   disconnected,  &Machine::handle_session_reject>,
     transition<any,           events::SeqNumLow,           disconnected,  &Machine::handle_seqnum_low>,
     transition<any,           events::SeqNumHigh,          disconnected,  &Machine::handle_seqnum_high>,
     transition<any,           events::LogoutRecv,          disconnected,  &Machine::handle_logout_unexpected>,
     transition<any,           events::LogoutSend,          logoutSent,    &Machine::handle_logout_initiate>,
     transition<any,           events::TimeoutSend,         disconnected,  &Machine::handle_timeout_send>,
     transition<any,           events::TimeoutRecv,         disconnected,  &Machine::handle_timeout_recv>,
     transition<any,           events::ErrorRecv,           disconnected,  &Machine::handle_error_recv>,
     transition<any,           events::ErrorSend,           disconnected,  &Machine::handle_error_send>,
     transition<any,           events::ErrorHandle,         disconnected,  &Machine::handle_error_handle>,

     transition<active,        events::MessageRecv,         active,        &Machine::handle_message_recv>,
     transition<active,        events::MessageSend,         active,        &Machine::handle_message_send>,
     transition<active,        events::SessionRejectRecv,   active,        &Machine::handle_session_reject>,
     transition<active,        events::TimeoutSend,         active,        &Machine::handle_heartbeat_send>,
     transition<active,        events::LogoutRecv,          disconnecting, &Machine::handle_logout_accept>,

     transition<connected,     events::LogonSend,           logonSent,     &Machine::handle_logon_initiate>,
(Continue reading)

Permalink | Reply |
headers
Andrey Semashev | 6 Aug 05:02

Re: FSM Review Announcement

David Abrahams wrote:
> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
> 
>> Andrey Semashev wrote:
>>> Jurko Gospodnetić wrote:
>>>>   What are the intended and actual differences from the already accepted
>>>> Statechart library?
>>> The main differences are simplicity and performance. The performance
>>> tests show difference by an order of magnitude, in the best case for
>>> Boost.Statechart. The overall design of Boost.FSM is geared more to
>>> compile-time code generation, while Boost.Statechart aims to support
>>> more scaled machines and therefore is geared towards run-time. There is
>>> a section in the docs that compares the libraries.
>> I can attest to the necessity of this. We have several exchange libraries that
>> require state machines to implement their data protocols but we use a 
>> home-brewed boost::mpl::inherit_linearly implementation because the 
>> features of Boost.StateChart simply brings in to many performance penalties
>> for our simpler usage that would fit within the Boost.FSM framework. In fact,
>> if I remember correctly, we used a thing on Boost.Vault called "FSM" as an 
>> implementation guide.
> 
> I don't know if you've seen the FSM examples from "C++ Template
> Metaprogramming" or not.  It would be interesting for this library's
> documentation to explain its advantages over that approach (I can see
> some from here already).

No, I don't have that book.

> One other thing I'd like to see is an implementation of nested states.
> I once promised some people who needed that functionality that I'd
(Continue reading)

Permalink | Reply |
headers
Michael Caisse | 6 Aug 09:47

Re: FSM Review Announcement

Andrey Semashev wrote:
>
> I thought about nested states, but, the way I understand it, there are 
> no advantages of nested states over nested state machines. Obviously, 
> you can define as much FSMs as you like and nest them within states as 
> you need.
> _______________________________________________

Perhaps I don't understand your use of nesting FSMs within a state yet. 
"Nested states" or hierarchical state machines can provide extremely 
powerful semantics such as return-to-history.

--

-- 

----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Andrey Semashev | 6 Aug 16:39

Re: FSM Review Announcement

Michael Caisse wrote:
> Andrey Semashev wrote:
>>
>> I thought about nested states, but, the way I understand it, there are 
>> no advantages of nested states over nested state machines. Obviously, 
>> you can define as much FSMs as you like and nest them within states as 
>> you need.
>> _______________________________________________
> 
> Perhaps I don't understand your use of nesting FSMs within a state yet. 
> "Nested states" or hierarchical state machines can provide extremely 
> powerful semantics such as return-to-history.

Maybe I just misunderstand what you mean by "nested states". I 
understand it as a more detailed description of the machine condition. 
For example, we have electronic watches that show either current date or 
current time and while showing time the colon between hours and minutes 
is blinking. The top level states could be showing_date and 
showing_time, and showing_time could have nested states with_colon and 
without_colon. If this is what you call "nested states", then the 
approach is similar to having a separate FSM with states with_colon and 
without_colon within the showing_time state.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 8 Aug 02:30

Re: FSM Review Announcement


on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

> David Abrahams wrote:
>> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
>>
>>> Andrey Semashev wrote:
>>>> Jurko Gospodnetić wrote:
>>>>>   What are the intended and actual differences from the already accepted
>>>>> Statechart library?
>>>> The main differences are simplicity and performance. The performance
>>>> tests show difference by an order of magnitude, in the best case for
>>>> Boost.Statechart. The overall design of Boost.FSM is geared more to
>>>> compile-time code generation, while Boost.Statechart aims to support
>>>> more scaled machines and therefore is geared towards run-time. There is
>>>> a section in the docs that compares the libraries.
>>> I can attest to the necessity of this. We have several exchange libraries that
>>> require state machines to implement their data protocols but we use
>>> a home-brewed boost::mpl::inherit_linearly implementation because
>>> the features of Boost.StateChart simply brings in to many
>>> performance penalties
>>> for our simpler usage that would fit within the Boost.FSM framework. In fact,
>>> if I remember correctly, we used a thing on Boost.Vault called
>>> "FSM" as an implementation guide.
>>
>> I don't know if you've seen the FSM examples from "C++ Template
>> Metaprogramming" or not.  It would be interesting for this library's
>> documentation to explain its advantages over that approach (I can see
>> some from here already).
>
(Continue reading)

Permalink | Reply |
headers
Andrey Semashev | 8 Aug 18:55

Re: FSM Review Announcement

David Abrahams wrote:
> on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
> 
>> David Abrahams wrote:
>>> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
>>> I don't know if you've seen the FSM examples from "C++ Template
>>> Metaprogramming" or not.  It would be interesting for this library's
>>> documentation to explain its advantages over that approach (I can see
>>> some from here already).
>> No, I don't have that book.
> 
> For your perusal:
> 
> http://www.boostpro.com/mplbook/examples/player.cpp
> http://www.boostpro.com/mplbook/examples/player2.cpp

Thanks for the info. I guess I'm not the first one who came up with such 
approach. :)

My implementation has similarities to player2.cpp, however, there are 
significant advantages in Boost.FSM.
- The library does not take addresses of user's functions, which allows 
to use templates and simplifies overloading.
- States are not an enum values but classes that may have a common 
virtual base, which allows to have state-specific and shared data in the 
FSM. The events are processed in states.
- States support enter and leave handlers. There is also a reset method 
that allows to clear the states and silently transit to the initial state.
- Other minor things, like auto-generated state names, dynamic handler 
for unsupported events, thread-safety issues, etc.
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 11 Aug 00:32

Re: FSM Review Announcement


on Fri Aug 08 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

> David Abrahams wrote:
>> on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>>
>>> David Abrahams wrote:
>>>> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
>>>> I don't know if you've seen the FSM examples from "C++ Template
>>>> Metaprogramming" or not.  It would be interesting for this library's
>>>> documentation to explain its advantages over that approach (I can see
>>>> some from here already).
>>> No, I don't have that book.
>>
>> For your perusal:
>>
>> http://www.boostpro.com/mplbook/examples/player.cpp
>> http://www.boostpro.com/mplbook/examples/player2.cpp
>
> Thanks for the info. I guess I'm not the first one who came up with
> such approach. :)
>
> My implementation has similarities to player2.cpp, however, there are
> significant advantages in Boost.FSM.
> - The library does not take addresses of user's functions, which
> allows to use templates and simplifies overloading.

Huh?  The member function pointers involved in our code are all
compile-time constants, and thus work very well with templates (in fact,
they are passed as template arguments).
(Continue reading)

Permalink | Reply |
headers
Andrey Semashev | 11 Aug 16:52

Re: FSM Review Announcement

David Abrahams wrote:
> on Fri Aug 08 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
> 
>> David Abrahams wrote:
>>> on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>>>
>>>> David Abrahams wrote:
>>>>> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
>>>>> I don't know if you've seen the FSM examples from "C++ Template
>>>>> Metaprogramming" or not.  It would be interesting for this library's
>>>>> documentation to explain its advantages over that approach (I can see
>>>>> some from here already).
>>>> No, I don't have that book.
>>> For your perusal:
>>>
>>> http://www.boostpro.com/mplbook/examples/player.cpp
>>> http://www.boostpro.com/mplbook/examples/player2.cpp
>> Thanks for the info. I guess I'm not the first one who came up with
>> such approach. :)
>>
>> My implementation has similarities to player2.cpp, however, there are
>> significant advantages in Boost.FSM.
>> - The library does not take addresses of user's functions, which
>> allows to use templates and simplifies overloading.
> 
> Huh?  The member function pointers involved in our code are all
> compile-time constants,

No, they are stored into the dispatching map array and thus there is no 
benefit in passing them as template arguments.
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 11 Aug 18:58

Re: FSM Review Announcement


on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

> David Abrahams wrote:
>> on Fri Aug 08 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>>
>>> David Abrahams wrote:
>>>> on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>>>>
>>>>> David Abrahams wrote:
>>>>>> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
>>>>>> I don't know if you've seen the FSM examples from "C++ Template
>>>>>> Metaprogramming" or not.  It would be interesting for this library's
>>>>>> documentation to explain its advantages over that approach (I can see
>>>>>> some from here already).
>>>>> No, I don't have that book.
>>>> For your perusal:
>>>>
>>>> http://www.boostpro.com/mplbook/examples/player.cpp
>>>> http://www.boostpro.com/mplbook/examples/player2.cpp
>>> Thanks for the info. I guess I'm not the first one who came up with
>>> such approach. :)
>>>
>>> My implementation has similarities to player2.cpp, however, there are
>>> significant advantages in Boost.FSM.
>>> - The library does not take addresses of user's functions, which
>>> allows to use templates and simplifies overloading.
>>
>> Huh?  The member function pointers involved in our code are all
>> compile-time constants,
(Continue reading)

Permalink | Reply |
headers
Andrey Semashev | 11 Aug 19:53

Re: FSM Review Announcement

David Abrahams wrote:

>>>> - States are not an enum values but classes that may have a common
>>>> virtual base, which allows to have state-specific and shared data in
>>>> the FSM. The events are processed in states.
>>> I'm not sure that isn't overkill.  In our implementation you are free to
>>> add any data you like to the FSM and use it in your transition (member)
>>> functions.  
>> Your approach doesn't allow to separate state-specific data from the
>> common data. 
> 
> Yes, but in your approach the common data can't persist across state
> transitions.  Is that not a serious limitation?

Why? It does persist as long as the FSM persists. All states and their 
base classes are constructed and destroyed with the FSM and never in the 
middle.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 11 Aug 20:11

Re: FSM Review Announcement


on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

> David Abrahams wrote:
>
>>>>> - States are not an enum values but classes that may have a common
>>>>> virtual base, which allows to have state-specific and shared data in
>>>>> the FSM. The events are processed in states.
>>>> I'm not sure that isn't overkill.  In our implementation you are free to
>>>> add any data you like to the FSM and use it in your transition (member)
>>>> functions.  
>>>
>>> Your approach doesn't allow to separate state-specific data from the
>>> common data. 
>>
>> Yes, but in your approach the common data can't persist across state
>> transitions.  Is that not a serious limitation?
>
> Why? It does persist as long as the FSM persists. All states and their
> base classes are constructed and destroyed with the FSM and never in
> the middle.

I'm confused.  If states 1 and 2 have associated data of types A and B,
the fact that A and B are both derived from C does not mean that there
is only one copy of the base class... or are you doing something special
to have states 1 and 2 share a single object of type D derived from A
and B?

[Please keep in mind that I'm not trying to say that the Book's FSM is
better than the one in your library.  It's clearly more limited.]
(Continue reading)

Permalink | Reply |
headers
Andrey Semashev | 11 Aug 20:27

Re: FSM Review Announcement

David Abrahams wrote:
> on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
> 
>> David Abrahams wrote:
>>
>>>>>> - States are not an enum values but classes that may have a common
>>>>>> virtual base, which allows to have state-specific and shared data in
>>>>>> the FSM. The events are processed in states.
>>>>> I'm not sure that isn't overkill.  In our implementation you are free to
>>>>> add any data you like to the FSM and use it in your transition (member)
>>>>> functions.  
>>>> Your approach doesn't allow to separate state-specific data from the
>>>> common data. 
>>> Yes, but in your approach the common data can't persist across state
>>> transitions.  Is that not a serious limitation?
>> Why? It does persist as long as the FSM persists. All states and their
>> base classes are constructed and destroyed with the FSM and never in
>> the middle.
> 
> I'm confused.  If states 1 and 2 have associated data of types A and B,
> the fact that A and B are both derived from C does not mean that there
> is only one copy of the base class... or are you doing something special
> to have states 1 and 2 share a single object of type D derived from A
> and B?

That's right, the library constructs a composite class that derives from 
all states. This allows states to virtually derive from a common base 
and share its data between each other. This composite class is a part of 
the complete FSM, so all states live as long as the FSM does. Switching 
between states only calls enter/leave handlers in the states, which can
(Continue reading)

Permalink | Reply |
headers
Henrik Vallgren | 14 Aug 17:48

Re: FSM Review Announcement


Is there any difference between the book and the sample described at:

http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/paper/mpl_paper.pdf

David Abrahams-3 wrote:
> 
> 
> I'm confused.  If states 1 and 2 have associated data of types A and B,
> the fact that A and B are both derived from C does not mean that there
> is only one copy of the base class... or are you doing something special
> to have states 1 and 2 share a single object of type D derived from A
> and B?
> 
> [Please keep in mind that I'm not trying to say that the Book's FSM is
> better than the one in your library.  It's clearly more limited.]
> 
> -- 
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 

--

-- 
View this message in context: http://www.nabble.com/FSM-Review-Announcement-tp18820219p18984305.html
Sent from the Boost - Dev mailing list archive at Nabble.com.
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 14 Aug 20:08

Re: FSM Review Announcement


On Thu, 14 Aug 2008 08:48:08 -0700 (PDT), Henrik Vallgren
<henrik.vallgren <at> streamspace.com> wrote:
> 
> Is there any difference between the book and the sample described at:
> 
> http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/paper/mpl_paper.pdf

Yes, there's some difference.  I linked to a copy of the code we discuss in
the book earlier in this thread.

--

-- 
David Abrahams
Boostpro Computing
http://www.boostpro.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Aleksey Gurtovoy | 19 Aug 05:27

Re: FSM Review Announcement

Hi Andrey,

I thought I'd clarify a couple of points below.

On Fri, 08 Aug 2008 11:55:30 -0500, Andrey Semashev  
<andrey.semashev <at> gmail.com> wrote:
> My implementation has similarities to player2.cpp, however, there are  
> significant advantages in Boost.FSM.
> - The library does not take addresses of user's functions, which allows  
> to use templates and simplifies overloading.
> - States are not an enum values but classes that may have a common  
> virtual base, which allows to have state-specific and shared data in the  
> FSM.

Enum- vs. class-based states *per se* is a relatively minor aspect of
the MPL's FSM example. You can have it either way [1]. In fact, earlier
version of the example does use (non-polymorphic) classes to represent
states:

http://svn.boost.org/trac/boost/browser/trunk/libs/mpl/example/fsm/player.cpp

Our derivative version here at work allows for state-specific data.

> The events are processed in states.

This one, however, is IMHO the biggest difference between the approaches.

> - States support enter and leave handlers.

Along with other niceties such as state invariants, this comes for free
(Continue reading)

Permalink | Reply |
headers
Martin Vuille | 19 Aug 02:07

Re: FSM Review Announcement

On 05 Aug 2008, you wrote in gmane.comp.lib.boost.devel:

> Andrey Semashev wrote:
>> Jurko Gospodnetić wrote:
>> >   What are the intended and actual differences from the
>> >   already accepted 
>> > Statechart library?
>>
>> The main differences are simplicity and performance. The
>> performance tests show difference by an order of magnitude, in
>> the best case for Boost.Statechart. The overall design of
>> Boost.FSM is geared more to compile-time code generation, while
>> Boost.Statechart aims to support more scaled machines and
>> therefore is geared towards run-time. There is a section in the
>> docs that compares the libraries. 
> I can attest to the necessity of this. We have several exchange
> libraries that require state machines to implement their data
> protocols but we use a home-brewed boost::mpl::inherit_linearly
> implementation because the features of Boost.StateChart simply
> brings in to many performance penalties for our simpler usage
> that would fit within the Boost.FSM framework. In fact, if I
> remember correctly, we used a thing on Boost.Vault called "FSM"
> as an implementation guide.

Hi Chris,

I am the review manager for the proposed FSM library, and
I was wondering whether you might have time to submit a more
comprehensive review?
(Continue reading)

Permalink | Reply |
headers
Kowalke Oliver (QD IT PA SI | 6 Aug 08:13

Re: FSM Review Announcement

Hello,

> >   Hi Martin.
> >
> >> The formal review for Andrey Semashev's Finite State
> Machines (FSM)
> >> library is scheduled for August 11th to 20th.
> >
> >   What are the intended and actual differences from the already
> > accepted Statechart library?
>
> The main differences are simplicity and performance. The
> performance tests show difference by an order of magnitude,
> in the best case for Boost.Statechart. The overall design of
> Boost.FSM is geared more to compile-time code generation,
> while Boost.Statechart aims to support more scaled machines
> and therefore is geared towards run-time. There is a section
> in the docs that compares the libraries.

Is it correct that Boost.FSM can not defer an events (I didn't found a statement in the docs)?
That means in yout tutorial the state Processing consumes the event passed to template< typename T > void
on_process(T const&)? If so - how Boost.FSM supports you if the order of passed events are not predictable?

Oliver
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Andrey Semashev | 6 Aug 16:28

Re: FSM Review Announcement

Kowalke Oliver (QD IT PA SI) wrote:
> Hello,
> 
>>>   Hi Martin.
>>>
>>>> The formal review for Andrey Semashev's Finite State
>> Machines (FSM)
>>>> library is scheduled for August 11th to 20th.
>>>   What are the intended and actual differences from the already
>>> accepted Statechart library?
>> The main differences are simplicity and performance. The
>> performance tests show difference by an order of magnitude,
>> in the best case for Boost.Statechart. The overall design of
>> Boost.FSM is geared more to compile-time code generation,
>> while Boost.Statechart aims to support more scaled machines
>> and therefore is geared towards run-time. There is a section
>> in the docs that compares the libraries.
> 
> Is it correct that Boost.FSM can not defer an events (I didn't found a statement in the docs)?

Yes, this feature is not supported.

> That means in yout tutorial the state Processing consumes the event passed to template< typename T > void
on_process(T const&)?

Right.

> If so - how Boost.FSM supports you if the order of passed events are not predictable?

The library itself does not mandate the order of events and I am
(Continue reading)

Permalink | Reply |
headers
Markus Werle | 6 Aug 15:24

Re: FSM Review Announcement

Martin Vuille <martin <at> jpmvrealtime.com> writes:

> The formal review for Andrey Semashev's Finite State Machines (FSM) 
> library is scheduled for August 11th to 20th.

... and again (!) this is not announced on the main web page where it 
should, so I nearly missed that one again.

Could you please trigger an update of the webpage news section?

I have a proposal: Mails to *.boost.announce should automatically
be reflected on the web page news section, so the review manager 
is released from this burden. 

Or better: After login to www.boost.org the review manager fills
in a web form for the announcement, which is then sent to the ML
_AND_ brought to the frontpage news at the same time.

Markus

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Martin Vuille | 6 Aug 17:03

Re: FSM Review Announcement

Markus Werle <numerical.simulation <at> web.de> wrote in
news:loom.20080806T131306-688 <at> post.gmane.org: 

> Could you please trigger an update of the webpage news section?
> 
> I have a proposal: Mails to *.boost.announce should automatically
> be reflected on the web page news section, so the review manager 
> is released from this burden. 
> 
> Or better: After login to www.boost.org the review manager fills
> in a web form for the announcement, which is then sent to the ML
> _AND_ brought to the frontpage news at the same time.
> 

I admit that I did not think about updating the news, but there
also doesn't seem to be any concensus on what review-related
events are newsworthy. All events (announcement, reminder, start,
end, etc.) or just start and end, or ???

MV

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Martin Vuille | 7 Aug 13:47

Boost.org news, recent announcements vs. reviews (was: FSM Review Announcement)

Markus Werle <numerical.simulation <at> web.de> wrote in
news:loom.20080806T131306-688 <at> post.gmane.org: 

> Martin Vuille <martin <at> jpmvrealtime.com> writes:
> 
>> The formal review for Andrey Semashev's Finite State Machines (FSM) 
>> library is scheduled for August 11th to 20th.
> 
> ... and again (!) this is not announced on the main web page where it 
> should, so I nearly missed that one again.
> 
> Could you please trigger an update of the webpage news section?
> 
> I have a proposal: Mails to *.boost.announce should automatically
> be reflected on the web page news section, so the review manager 
> is released from this burden. 
> 
> Or better: After login to www.boost.org the review manager fills
> in a web form for the announcement, which is then sent to the ML
> _AND_ brought to the frontpage news at the same time.
> 

I would like to understand how the News and Recent Announcements sections of 
the website's front page are intended to be used. Are they supposed to be 
updated automatically through some means, or manually?

What is the difference between News and Recent Announcements? Should review-
related matters be posted in the News, the Recent Announcements, or both?

To my mind, it would make the most sense to keep the News focused on major
(Continue reading)

Permalink | Reply |
headers
Rene Rivera | 7 Aug 16:50

Re: Boost.org news, recent announcements vs. reviews

Martin Vuille wrote:
> Markus Werle <numerical.simulation <at> web.de> wrote in
> news:loom.20080806T131306-688 <at> post.gmane.org: 
> 
>> Martin Vuille <martin <at> jpmvrealtime.com> writes:
>>
>>> The formal review for Andrey Semashev's Finite State Machines (FSM) 
>>> library is scheduled for August 11th to 20th.
>> ... and again (!) this is not announced on the main web page where it 
>> should, so I nearly missed that one again.
>>
>> Could you please trigger an update of the webpage news section?
>>
>> I have a proposal: Mails to *.boost.announce should automatically
>> be reflected on the web page news section, so the review manager 
>> is released from this burden. 
>>
>> Or better: After login to www.boost.org the review manager fills
>> in a web form for the announcement, which is then sent to the ML
>> _AND_ brought to the frontpage news at the same time.
>>
> 
> I would like to understand how the News and Recent Announcements sections of 
> the website's front page are intended to be used. Are they supposed to be 
> updated automatically through some means, or manually?

Technically, the news section reflects a combination of the news feeds 
<http://svn.boost.org/trac/boost/browser/website/public_html/live/feed>. 
Which are "hand" edited as is deemed appropriate by any Boost developer. 
But really is only touched by the release team, moderators, and review
(Continue reading)

Permalink | Reply |
headers
Martin Vuille | 7 Aug 17:15

Re: Boost.org news, recent announcements vs. reviews

Rene Rivera <grafikrobot <at> gmail.com> wrote in
news:489B0BAA.9090909 <at> gmail.com: 

> 
> Technically, the news section reflects a combination of the news
> feeds 
> <http://svn.boost.org/trac/boost/browser/website/public_html/live
> /feed>. Which are "hand" edited as is deemed appropriate by any
> Boost developer. But really is only touched by the release team,
> moderators, and review manager. And the "Recent Announcements"
> is a direct reflection of the messages posted to the Boost
> announce list. 
> 

I see that the Recent Announcements heading links to the posts
from boost-announce, but is the list of recent announcements
below the heading supposed to be updated automatically, or does
it have to be updated manually as well?

MV

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Rene Rivera | 7 Aug 17:23

Re: Boost.org news, recent announcements vs. reviews

Martin Vuille wrote:
> Rene Rivera <grafikrobot <at> gmail.com> wrote in
> news:489B0BAA.9090909 <at> gmail.com: 
> 
>> Technically, the news section reflects a combination of the news
>> feeds 
>> <http://svn.boost.org/trac/boost/browser/website/public_html/live
>> /feed>. Which are "hand" edited as is deemed appropriate by any
>> Boost developer. But really is only touched by the release team,
>> moderators, and review manager. And the "Recent Announcements"
>> is a direct reflection of the messages posted to the Boost
>> announce list. 
>>
> 
> I see that the Recent Announcements heading links to the posts
> from boost-announce, but is the list of recent announcements
> below the heading supposed to be updated automatically, or does
> it have to be updated manually as well?

It's automatic, as in there's a cronjob on the web server that reflects 
the list content periodically.

--

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Martin Vuille | 7 Aug 18:22

Re: Boost.org news, recent announcements vs. reviews

Rene Rivera <grafikrobot <at> gmail.com> wrote in
news:489B1389.1070409 <at> gmail.com: 

>> 
>> I see that the Recent Announcements heading links to the posts
>> from boost-announce, but is the list of recent announcements
>> below the heading supposed to be updated automatically, or does
>> it have to be updated manually as well?
> 
> It's automatic, as in there's a cronjob on the web server that
> reflects the list content periodically.
> 

OK, thanks. How often does the cron job run? I posted a review
announcement on boost-announce late on Monday, it showed up on
the list on Tuesday, but was not reflected on the front page
until this morning (or maybe late last night).

MV

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Martin Vuille | 8 Aug 13:42

Re: Boost.org news, recent announcements vs. reviews

Rene Rivera <grafikrobot <at> gmail.com> wrote in
news:489B0BAA.9090909 <at> gmail.com: 

> Technically, the news section reflects a combination of the news
> feeds 
> <http://svn.boost.org/trac/boost/browser/website/public_html/live
> /feed>. Which are "hand" edited as is deemed appropriate by any
> Boost developer. But really is only touched by the release team,
> moderators, and review manager. And the "Recent Announcements"
> is a direct reflection of the messages posted to the Boost
> announce list. 

So, for example, I would create a new .qbk file in the news 
subdirectory and the scripts would take care of updating the RSS feed 
and the website front page?

Are the scripts run automatically, or do I need to run them myself to 
perform the updates?

Is this all described somewhere that I should be reading?

MV

_______________________________________________
Unsubscribe & other changes: