| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a way to large commit. But I see no feasable way to break it
down into multiple smaller commits.
The main "secret" to solving timezones for recurring events was to
remember to recalculate timezones whenever a new instance of the object
was generated.
This current implementation seems really slow (> 1s). Further testing is
needed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Add earlier work on timezones, with a few inline modifications. This is
really to big of a commit. But we are so far from a stable release that
it should be fine.
The current version seems to eager, and recalculates to many times. This
will soon be fixed in a future version.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Made the fact that properties belong to an attribute shine through to
scheme. This by setting the SCM field in the strbuf:ers in my
vcomponents to a pair of their old SCM value, and a hash table
representing the properties.
This also meant that the primitive set-attribute! could be replaced by a
set-car! on the pair returned by the primitive get-attribute. And that
both set- and get-property now simple works on the hash table returned
by get-attribute.
The major problem with this release was that I for a while missed that
DEEP_COPY(strbuf) now also needed to deep copy the SCM values. Without
that attributes in a copied vcomponent would be shared with the
original. This mainly lead to repeating events all being the same.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
VIRTUAL vcomponents are vcomponents created without a source. Their
primiary purpose is for creating brand new events, which will later be
dumped to the proper files.
They can however also be used in testing for great effect.
|
| |
|
