pull request: #12

1. motivation:
   the Store in simpy has a feature: the sender can wait on the store when the store is full and the receiver can wait on the store when the store is empty. So the scheduler needs to be changed when encountering Request and Release events

• current behavior: when Request happened: the scheduler will issue one new event when the resource return Some event or zero when the resource returns None when Release happened: the scheduler will issue 2 events when the resource return Some event and issue 1 event(the original one) when the resource returns nothing.
• new behavior:
  • when requesting on a store: the scheduler will need to schedule zero, one, or two events depending on the current store ( #12 ), as same as when releasing on a store

2. things change from the original code:

• change the Resource trait return type:

pub trait Resource<T> {
    fn allocate_or_enqueue(&mut self, event: Event<T>) -> Vec<Event<T>>;
    fn release_and_schedule_next(&mut self, event: Event<T>) -> Vec<Event<T>>;
}

instead of returning an optional value, the resource can now return zero or multiple events

• change the scheduler behavior:

                            Effect::Request(r) => {
                                let res = &mut self.resources[r];
                                let request_event = Event::new(self.time, event.process(), y);
                                for e in res.allocate_or_enqueue(request_event) {
                                    self.future_events.push(Reverse(e))
                                }
                            }
                            Effect::Release(r) => {
                                let res = &mut self.resources[r];
                                let request_event = Event::new(self.time, event.process(), y);
                                let events = res.release_and_schedule_next(request_event);
                                for e in events {
                                    self.future_events.push(Reverse(e));
                                }
                            }

now the scheduler always schedules all the events that the resource returned.

• chagne the original SimpleResource implementation: release will always return at least one event.

    fn release_and_schedule_next(&mut self, event: Event<T>) -> Vec<Event<T>> {
        match self.queue.pop_front() {
            Some(mut request_event) => {
                // some is waiting for the request, schedule it! and schedule the self
                request_event.set_time(event.time());
                vec![request_event, event]
            }
            None => {
                // no one is waiting for the resorce, restore the availiable and return self
                assert!(self.available < self.quantity);
                self.available += 1;
                vec![event]
            }
        }
    }

3. new store type: see #12

The link to the api docs on the repo landing page is dead.

Is it possible to add container feature in a similar way as in simpy container? https://simpy.readthedocs.io/en/latest/topical_guides/resources.html#res-type-container

I'm trying to asses the opportunity for one or more pull requests that add some features to desim. Most of those are the result of my own needs for discrete event simulation, but I would like to see if there is wider interest:

Currently already done but in need of polishing (marked below) or in my near-term pipeline:

• Improved monitoring, driven by user-provided data types (Effect + arbitrary additional state)
• Event callbacks, currently implemented: on_event_processed, on_resource_acquire, on_resource_enqueue, on_resource_release
• Allow for arbitrary resource queuing disciplines by providing a SimResource trait that all Resources implement
• Schedulers (Time Sharing): I'm currently designing this so that sets of Processes can be logically run in a time-sharing fashion (each being given a time slice). This is more disruptive to the code as simulation steps are no longer entirely driven by resuming generators.

At the moment the new code lives in my own fork of desim in a "new_features" branch but that is just a messy experiment and separate pull requests would have to be teased from that. However, I don't plan on maintaining a separate fork if you are interested in the changes upstream.

Is it possible to implement process interruption in a similar way as in simpy?

Hi,

Using desim v0.2 results in some import errors in the examples or when using desim as described in the examples.
For example, the carwash example does not compile with the following errors:

18 | use desim::prelude::*;
   |            ^^^^^^^ could not find `prelude` in `desim`

error[E0432]: unresolved import `desim::resources`
  --> simulator/src/bin/carwash.rs:19:12
   |
19 | use desim::resources::SimpleResource;
   |            ^^^^^^^^^ could not find `resources` in `desim`

In contrast, the example compiles successfully using the version on git , i.e. desim = {git = "https://github.com/garro95/desim"} .
The crate has not been updated on crates.io which is evident when looking at the last update on crates.io vs the commit history here.
It would be nice if you would update the crate.

Any idea how to access simulation time from within the process?

This code won't compile:

#![feature(generators, generator_trait)]
extern crate desim;
use desim::{Simulation, Effect, Event, EndCondition};

fn main() {


    let mut s = Simulation::new();
    let g = Box::new(|| {
        let tik = 0.7;
        loop{
            println!("tik {}", s.time());
            yield Effect::TimeOut(tik);
        }
    });

    let p = s.create_process(g);
    s.schedule_event(Event{time: 0.0, process: p});
    let s = s.run(EndCondition::Time(10.0));
}

The problem is accessing s from within the closure - it introduces immutable borrow of s with conflicts with the need to use the mutable borrow later. Any idea how to solve this without using Rc and RefCell?

Write a test to ensure that log trace is correct