Reports: R Kelly's girlfriend Joycelyn Savage makes a series of serious allegations against incarcerated singer
Cape Town - Joycelyn Savage, R. Kelly's alleged live-in girlfriend has reportedly gone on to make even more bombshell claims against him in a reported post on Patreon according to The Chicago Sun-Times.
The embattled artist has been in jail since July, following his arrest on charges including child pornography and enticement of a minor.
According to the Chicago publication, Joycelyn writes in her post: "I realised I was pregnant by this monster ... Eventually, I ended up getting an abortion I was forced to get the surgery done at his house."
SEE JOYCELYN'S INSTAGRAM POST ABOUT HER PATREON HERE:
Back in March 2019 according to Rolling Stone Magazine Gerald Griggs, an attorney for the Savage family tweeted that Joycelyn reached out to her parents by phone after R. Kelly’s explosive interview with Gayle King and reiterated that she remains with the performer by choice.
READ NEXT: R. Kelly interview becomes a spotlight moment for Gayle King.
According to Fox News Jocelyn has been living with him since she was 19 years old and this is the first time, she has spoken out on social media for the first time in two years.
Compiled by Alex Isaacs. (Sources: Rolling Stone, TMZ, Chicago Sun-Times, Fox News)
(Photo: Getty Images)


Each geometric object is considered an infinite set of points.
As a set, their most fundamental operations are of the same nature as the standard operations of Java collections.
We may therefore see a geometry as a kind of java.util.Set
in which the elements are points,
except that the number of elements contained in the set is infinite (with the exception of geometries representing a simple point).
To better represent this concept, the ISO standard and GeoAPI define a TransfiniteSet
interface
which we could see as a Set
of infinite size.
Although a parent relationship exists conceptually between these interfaces,
GeoAPI does not define TransfiniteSet
as a sub-interface of java.util.Set
,
as the definition of certain methods such as size()
and iterator()
would be problematic.
However, we find very similar methods such as contains(…)
and intersects(…)
.
All geometries are specializations of TransfiniteSet
.
The parent class of those geometries is called GM_Object
in ISO 19107 standard.
GeoAPI interfaces use the Geometry
name instead, as the omission of the GM_
prefix (as prescribed in GeoAPI convention) would leave a name too similar to Java’s Object
class.
ISO 19107 defines two types of structures to represent a point:
GM_Point
and DirectPosition
.
The first type is a true geometry and may therefore be relatively cumbersome, depending on the implementation.
The second type is not formally considered to be a geometry;
it extends neither GM_Object
nor TransfiniteSet
.
It barely defines any operations besides the storing of a sequence of numbers representing a coordinate.
It may therefore be a more lightweight object.
In order to allow the API to work equally with these two types of positions,
ISO 19107 defines Position
as a union of
DirectPosition
and GM_Point
.
It is a union in the sense of C/C++. For the Java language, GeoAPI obtains the same effect by defining
Position
as the parent interface of DirectPosition
and Point
.
In practice, the great majority of Apache SIS’s API works on DirectPosition
s,
or occasionally on Position
s when it seems useful to also allow geometric points.
Envelopes store minimal and maximal coordinate values of a geometry.
Envelopes are not geometries themselves; they are not infinite sets of points (TransfiniteSet
).
There is no guarantee that all the positions contained within the limits of an envelope are geographically valid.
Envelopes must be seen as information about extreme values that might take the coordinates of a geometry as if
each dimension were independent of the others, nothing more.
Nevertheless, we speak of envelopes as rectangles, cubes or hyper-cubes (depending on the number of dimensions)
in order to facilitate discussion, while bearing in mind their non-geometric nature.
Example: We could test whether a position is within the limits of an envelope. A positive result does not guarantee that the position is within the geometry delimited by the envelope, but a negative result guarantees that it is outside the envelope. We can perform intersection tests in the same way. On the other hand, it makes little sense to apply a rotation to an envelope, as the result may be very different from that which we would obtain be performing a rotation on the original geometry, and then recalculating its envelope.
An envelope might be represented by two positions corresponding to two opposite corners of a rectangle,
cube or hyper-cube.
For the first corner, we often take the one whose ordinates all have the maximal value (upperCorner
).
When displayed using a conventional system of coordinates (with y axis values running upwards),
these two positions appear respectively in the lower left corner and the upper right corner of a rectangle.
Care must be taken with different coordinate systems, however, which may vary the positions of these corners on the screen.
The expressions lower corner and upper corner should thus be understood in the mathematical rather than the visual sense.
Minimums and maximums are the values most often assigned to lowerCorner
and upperCorner
.
But the situation becomes complicated when an envelope crosses the antimeridian (-180° or 180° longitude).
For example, an envelope 10° in size may begin at 175° longitude and end at -175°.
In this case, the longitude value assigned to lowerCorner
is greater than that assigned to upperCorner
.
Apache SIS therefore uses a slightly different definition of these two corners:
lowerCorner
:
the starting point, if we move along the inside of the envelope in the direction of ascending values.
upperCorner
:
the end-point, if we move along the inside of the envelope in the direction of ascending values.
If the envelope does not cross the antimeridian, these two definitions are equivalent to the selection of minimal and
maximal values respectively. This is the case in the green rectangle in the figure below.
When the envelope crosses the antimeridian, the lowerCorner
and the
upperCorner
appear again at the bottom and top of the rectangle
(assuming a standard system of coordinates), so their names remain appropriate from a visual standpoint.
However, the left and right positions are switched.
This case is illustrated by the red rectangle in the figure below.
The notions of inclusion and intersection, however, interpreted slightly differently in these two cases.
In the usual case where we do not cross the antimeridian, the green rectangle covers a region of inclusion.
The regions excluded from this rectangle continue on to infinity in all directions.
In other words, the region of inclusion is not repeated every 360°.
But in the case of the red rectangle, the information provided by the envelope actually covers a region of exclusion
between the two edges of the rectangle. The region of inclusion extends to infinity to the left and right.
We could stipulate that all longitudes below -180° or above 180° are considered excluded,
but this would be an arbitrary decision that would not be an exact counterpart to the usual case (green rectangle).
A developer may wish to use these values, for example, in a mosaic where the map of the world is repeated several times
horizontally and each repetition is considered distinct.
If developers wish to perform operations as though the regions of inclusion or exclusion were repeated every 360°,
they themselves will have to bring the longitudinal values between -180° and 180° in advance.
All the add(…)
, contains(…)
,
intersect(…)
, etc. functions of all the envelopes defined in the
org.apache.sis.geometry
package perform their calculations according to this convention.
In order for functions such as add(…)
to work correctly,
all objects involved must use the same coordinate reference system, including the same range of values.
Thus an envelope that expresses longitudes in the range [-180 … +180]° is not compatible with an envelope that expresses
longitudes in the range [0 … 360]°.
The conversions, if necessary, are up to the user
(the Envelopes
class provides convenience methods to do this).
Moreover, the envelope’s coordinates must be included within the system of coordinates,
unless the developer explicitly decides to consider (for example) 300° longitude as a position distinct from -60°.
The GeneralEnvelope
class provides a normalize()
method to bring
coordinates within the desired limits, sometimes at the coast of lower values being higher than
upper values.


Thank you for installing Ritchie CLI.
Open a new terminal and run the following command to get started with Ritchie:
$ rit init
Run the following command to uninstall Ritchie.
$ sudo bash /Library/rit/uninstall.sh
Copyright © 2020 Zup IT Innovation Inc. All rights reserved. Ritchie CLI and its use subject to a license agreement and are also subject to copyright, trademark patent and/or other laws.


Administrator's Guide
Table of Content
1. Introduction
After the LuxCal calendar has been installed or upgraded, using the installation_guide.html, this Administrator's Guide is meant to help the calendar administrator to set up the more advanced functions of the LuxCal calendar and to maintain the calendar so that it's functionality meets the needs of the users in the best suitable way.
A good place to start in managing your calendar is to . . .
- customize the calendar settings via the admin's Settings page
- create a number of categories for your events
- edit the default user groups created during the installation or add new user groups
To familiarize yourself with the LuxCal calendar's capabilities, it is important to take notice of the other function and possibilities described in this section.
For a detailed description of all calendar functions and capabilities you should visit the LuxCal fansite produced by John Schwartz in Denmark. This fansite also provides various descriptions and demonstrations of how the calendar can be used in a great number of different fields. The forum on this fansite offers an excellent opportunity to exchange views with John and other LuxCal users.
2. Managing the Calendar
Managing the LuxCal calendar is the responsibility of the calendar administrator, who has all calendar access rights.
Managing event categories, user profiles and user groups can be done by either the calendar administrator, or users with 'manager' rights.
In order to change configuration settings, or use other administration functions, you must select Log In in the navigation bar at the top right corner of the screen. Enter the administrator name or email address and the password you specified during the installation, and log in. On the right side of the navigation bar the administration drop down menu will appear.
a. Calendar Settings
The Settings page in the administration menu on the navigation bar can be used to easily change the calendar's configuration settings which are stored in the settings table of the database. These settings, for instance, define the calendar title, the time zone, the language file to be used for the user interface, the default initial view when the calendar is started, the number of weeks/months displayed in the various views, the date and time format, etc.
IMPORTANT: Currently the TimeZone is set to "Europe/Amsterdam". If you are in a different time zone, change the TimeZone to your local time zone. See the PHP Supported Time Zones for possible values.
b. Event Categories
It is recommended to create a number of categories for your events, each with its own color. Adding categories with different colors - though not required - will greatly enhance the views of the calendar. Categories can be for example: meeting, important, holiday, birthday, etc.
The initial installation has only one category which is named "no cat". To manage categories, select Categories in the administration drop down menu. This takes you to a page with a list of all categories where you can add new categories and edit or delete current categories.
When adding / editing events the defined categories can be selected from a pull down list. The order in which categories are displayed in the pull down list is determined by the Sequence field on the Categories page.
The field "Repeat" can be used to pre-define recurring events. A category "birthday" or "anniversary" can be set to repeat every year. If a repeat value is specified, all events defined in this category will repeat as specified. The repeat value specified here will overrule possible user 'repeat' settings.
If the "No overlap allowed" check box is checked, events within this category may not overlap. If a user tries to create an event in this category which overlaps with an existing event, an error message with the specified error text will be displayed. This feature can be used when you want to use this event category for booking events. For details on how to create a booking calendar, see Advanced Functions hereafter.
With the field "Default time slot" you can specify the default duration of an event in case the user specifies a start time without an end time. This can be useful for instance when using this category for "booking" events which may not overlap (see above).
When the checkbox "Day color" has been checked, the full day cell in the calendar views will get the background color specified below. This may be useful to clearly mark for example holidays, birthdays, or other special days.
When activated, the field "Event needs approval" will activate the propose/approve feature for events in this category. For a detailed description, see "Proposing / Approving Events" in section 3 below.
A check mark can be activated which will be displayed in front of the event title for all events in this category. The user can use this check mark to flag events, for example, as "completed". Events in this category will appear in the ToDo list, which can be opened from the calendars navigation bar.
The fields "Text color" and "Background" define the colors used to display events in the calendar assigned to this category.
The field "Sequence" defines the location of this event category in the category drop-down menus.
c. Calendar User Groups
The initial installation has a User Group defined for each possible type of user permission. Each calendar user is assigned to one of the existing user groups. User groups can be edited, and new user groups can be added, by users with administrator or manager rights. Adding and editing user groups is done via the Administration drop-down menu in the navigation bar. A user group defines the user access rights of the users assigned to this group and the event categories available to the users in the group. Furthermore a number of check boxes are available to specify whether users in this group may upload event attachements and may enter repeating events, multi-day events and private events. Via a color palette a background color can be selected for each group. On the admin's Settings page the administrator can specify whether calendar events should be displayed with the color of the event category or the color of the group to which the creator of the event belongs.
Possible access rights:
None
The user - normally the Public User - has no access rights and has to log in to use the calendar.
View
The user can view the calendar, but has has no rights to add or edit events.
Post/Edit Own
The user can view the calendar and can add events. The user can only edit his/her own events.
Post/Edit All
The user can view the calendar and can add events. The user can edit his/her own events as well as events of other users.
Post/Edit + Manager
A user with 'Manager' rights can do the same as a user with 'Post All' rights and in addition:
- Can change the owner of an event (in the Event window). So for instance a manager can create events for other users by creating an event and then assign an owner to it.
- Can approve events created by other users. See Advanced Functions hereafter.
- Has access, via the Administration drop-down menu, to the Categories, Users and User Groups pages and consequently can manage event categories, user profiles and user groups.
Administrator
The administrator has all right described above and in addition has access to all technical, user-interface and database related settings and functions.
d. Calendar Users
Via the Administration drop-down menu user(s) with manager rights or the calendar administrator can add and edit user profiles. Per user the name, e-mail address, password and the user group can be specified. As described above, the group determines the access rights and the available event categories. It is important to specify a valid email address for the user to be able to receive email notifications of due dates of events. When defined users log in to the calendar they can specify their default user interface language. Thereafter, when a user logs in, the user-interface will be displayed in the specified language.
The initial installation has two users defined. One is the Public Access user, who initially is assigned to the "Read access" user group and the other is the calendar administrator, who is assigned to the "Admin" user group and has all access rights.
Unless the calendar administrator has given "View" access (via the "Read access" user group) to Public Access users, users must log in to use the calendar using their name or email address and password. Depending on the group to which a user has been assigned, a user can have different access rights.
If the administrator has enabled user self-registration on the Settings page, users can register themselves via the Login page. Self-registered users will automatically be assigned to the user group for self registered users specified by the administrator on the admin's Settings page and consequently will have the access rights specified for that user group.
e. Calendar Database
The Database menu in the navigation bar allows the calendar administrator to start the following functions:
Compact database
During normal use of the calendar, when deleting events, the event records are not physically deleted from the database, but are marked as 'deleted'. They can still be used in views and reports; for example in the Changes view. The compact database function permanently removes events from the database which have been marked as 'deleted' more than 30 days ago. Thereafter all tables are compressed to free unused space and to reduce database overhead. This action can also be done automatically if a cron job has been created and on the admin's Settings page, under Periodic Functions, the number of Event expiry days has been specified.
Backup database
This function creates a backup of the structure and contents of all database tables in the files/ directory. The file name is cal-dump-yyyymmdd-hhmmss.sql (where 'yyyymmdd' = year, month, and day, and hhmmss = hour, minutes and seconds). The file type is .sql and the created file can be downloaded and used to re-create the database tables structure and contents, for instance by using the Restore database function (see hereafter) or by importing the file a database management tool which is available on the server of most web hosts.
Restore database
This function uploads the database backup file specified by the administartor and uses this file to recreate the calendar database. The database backup file must be of the same calendar version as the currently running calendar. The restore function accepts back up files from the MySQL version as well as the SQLite version of the calendar, as long as the version number matches the current calendar.
The database will be recreated from scratch, which means that, before recreating a table, the existing table and its data will be deleted. For each recreated table the corresponding records from the back-up file will be restored to the newly created table.
To restore backup files of older LuxCal versions the "lctool.php" file from the toolbox should be uploaded to the calendar root and launched via the browser.
delete / undelete events
With this function the administrator can delete or undelete all events in a specified date range. Deleted events will be marked 'deleted', but are not yet physically deleted from the database. When the administrator runs the 'compact database' function, described above, events which are physically deleted from the database cannot be undeleted anymore.
When selecting this function and a date in the date range is not specified, the default will be 'unlimited'. This means that if both start and end date are not specified, all events will be (marked as) deleted / undeleted.
f. CSV File Import
CSV (Comma Separated Values) text files with event data can be imported into the LuxCal calendar. This function can for instance be used to import a CSV file with event data exported by MS Outlook. The dialogue to import CSV files is opened by selecting CSV Import from the administration drop-down menu in the navigation bar.
The CSV file contains one line per event and each line contains a number of fields each separated by a comma (or any other unique character). The order of the fields in each line of the CSV file is: title, venue, category id, date, end date, start time, end time and description. The first line of the CSV file is ignored by the import function and can be used for column descriptions (default in MS Outlook exports).
Sample CSV files - with different date/time formats - can be found in the files/ directory of the LuxCal Calendar installation and have the file extension ".csv".
g. iCal File Import/Export
Events from iCalendar files can be imported into the LuxCal calendar. The content of the iCal file to be imported must meet the [RFC5545 standard] of the Internet Engineering Task Force. The LuxCal calendar can also export events into an iCal file which can be downloaded by the calendar administrator. The dialogue to import/export iCal files is opened by selecting iCal Import / iCal export from the administration drop-down menu in the navigation bar.
This function can for instance be used to back up the events of your LuxCal calendar, or to exchange events with other calendars, e.g. to import public holidays available in iCalendar format on the internet. Please note that some LuxCal event fields are not supported in the iCalendar format (e.g. private event, notify, email addresses) and consequently are not copied to the iCal file. Some iCal event repetition rules are not supported by the LuxCal calendar; these events will be displayed and earmarked as such, but will not be added to the calendar.
Various sample iCal files can be found in the files/ directory of the LuxCal Calendar installation and have the file extension ".ics".
3. Advanced Functions
The normal day-to-day use of the calendar is explained in the help file which can be viewed by selecting 'Help' (or the question mark) on the right side of the calendar's navigation bar. There are however a number of more advanced functions which can be enabled / configured by users with manager rights or by the calendar administrator.
These advanced functions are described hereafter.
a. Changing the Lay-out of Events
On the Settings page, the admin can specify which fields of the event body are in use and in which order they will be displayed in the various views. This can be done via the 'Event template' under Events by specifying a sequence of numbers in the range 1 - 7, where each number represents an event field.
Possible fields in the event body:
- 1: Venue field
- 2: Event category field
- 3: Description field
- 4: Extra field 1
- 5: Extra field 2
- 6: Email notification data (only if an email notification has been requested
- 7: Date/time added/edited and the associated users
Fields (numbers) which are not specified, will not be visible in the calendar views. Extra fields 1 and 2 are extra fields for which the admin can specify a dedicated label on the same Settings page under Events. If the these fields have been specified, the field label as well as the content will be displayed. In the calendar views active fields which are empty will not be shown. The Event window will of course always show all active fields, including the empty fields.
Example: Event template "43126", with the label for Extra field 1 set to "Department", will for instance result in the following event body lay-out (explanation between brackets):
Department: Sales (extra field 1 with label "Department")
Emmett Brown will be working on-site for the BTTF project. (description)
Venue: Hill Valley (venue)
Category: Absent (event category)
(Notify: 4 day(s)) (This line is not displayed, because no email notification was requested)
On the Settings page, the fields 'Event fields - general hover box' under Events, 'Event fields - mini calendar hover box' under Mini Calendar and 'Event fields - sidebar hover box' under Stand-Alone Sidebar can be used by the admin to specify the event fields to be displayed in the various hover boxes. The sequence of the fields in the hover boxes depend on the event template described before.
b. Adding Attachments to Events
Users belonging to a User group for which File Upload is enabled, can add pdf, image and video attachments to events. Adding and removing attachments to events can be done in the Event window when adding or editing events. The actual attachment file is stored in the calendar's subfolder "attachments" and the link from the event to the file is saved in the event record in the calendar database. Uploaded attachments will be shown as hyperlinks in the event data in the various calendar views. When clicking these hyperlinks, the attachment will open in a new window.
When an attachment file is stored in the attachment folder, its file name is prefixed with the current date and time. E.g<PHONE_NUMBER>3557Agenda.pdf.
On the administrators Settings page, under Views, in the Event templates it can be specified if and at what position within the event data hyperlinks to attachments should be displayed in the various calendar views.
c. Event Check Mark and To Do List
On the admin's Categories page, when adding/editing an event category, if you select "Check mark" and specify a label and a check mark, events in this category will have a check mark displayed just in front of the event title in the various views. For the owner of the event and users with "manager" rights this check mark is a hyperlink and, when clicked, will result in checking/unchecking the check mark. This feature can be used for instance to mark an event as "complete" or "done". Events with a check mark will show up in the To Do list, which - when enabled by the administrator - can be selected from the calendar's navigation bar.
d. Proposing / Approving Events
On the admin's Categories page, when adding/editing an event category, if you select "Events need approval", users with post rights can - in this category - create events which are not visible to other users until a user with at least "manager" rights has approved the event. Until the event has been approved, no other user will see the event and both the originator and users with manager rights will see the proposed event in the various views displayed with a red bar on the left side. Once a user with "manager" rights has approved the event, the event will become visible to all users and the event will be locked and cannot be edited anymore by the originator. A user with at least manager rights can still edit the event. Of course, if you don't like the words "proposing" and "approving", you could for example also consider the words "booking" and "confirming".
e. Private Events
When adding/editing events, if the "Private" check box is checked, the event will only be visible to the user who created the event and to the administrator. For obvious reasons private events can only be created by logged in users.
On the Settings page, under Events, the administrator can set "posting of private events to disabled, enabled, default and always with the following meaning:
- disabled: The "Private" check box will not be visible in the Event window, so no private events can be created.
- enabled: The "Private" check box will be visible in the Event window and will initially be unchecked.
- default: The "Private" check box will be visible in the Event window and will initially be checked.
- always: The "Private" check box will not be visible in the Event window and all created events will be private.
The creation of private events can also be enabled/disabled per individual user group (see Calendar User Groups above). If for a calendar user group private events have been disabled, this will overrule the "Posting of private events = always" setting on the admin's Settings page.
f. Using the Calendar to Book Events
One or several event categories of the calendar can be set up for booking events with event overlap checking. The idea is to let users create events which may not overlap with already existing events in the same event category. If a user tries to create an event which overlaps, an error message will be displayed. Single-day and multi-day events are checked. Recurring events and private events are not checked.
How to set up a booking system, is illustrated by the following example.
Billiard table booking example:
In this example we will set up a booking system for three billiard tables.
Create a new event category and give it the name "Billiard table 1", uncheck the "No overlap
allowed" check box, and optionally set the error text, displayed in case of creating an event
which overlaps with an existing event, to "Billiard table 1 in use, choose an other time or
table". If desired, the "Default time slot" can be specified, which - when creating / editing
an event - will automatically be added to the start time of an event if no end time is specifies.
Give this category a color (text/background) which belongs to table 1.
Create two more categories for the other two billiard tables in a similar way but with a
different name, error text and color.
Now a user group can be created, for instance with the name "Billiards" for those users who can
book one of the three billiard tables. For this user group the three categories created for the
billiard tables should be selected and the check boxes "May post repeating events" and "May post
private events" should be unchecked. Because the billiard tables can only be booked for a
limited time, the check box "May post multi-day events" can also be unchecked. So now if a user
in this group add/edits an event, the Event window will be simplified and will contain no
"Private" check box, no "End date" field and no "Repeat" feature.
On the Settings page, under User Accounts, "Self registration" can be enabled and the "Self
registration user group" should be set to the user group "Billiards" created in the step above.
In the above example, users can register themselves and will be part of the "billiard" user group; they will have access to the three categories "Billiard table 1", "Billiard table 2" and "Billiard table 3" and will only be able to book a billiard table which is free.
Note: For a booking system for chalets for instance, in the user group the check box "May post multi-day events" should remain checked, to allow for booking the chalets for several days.
g. Sidebar with Upcoming Events or Todo List
A stand-alone sidebar with upcoming events or a Todo list (see above) can be integrated in your web page. An advantage of the sidebar, compared to embedding the calendar in an html iframe, is that the sidebar is displayed in a <div> container and can be freely styled to match the style of your web page. A second advantage is that the hoverbox with many event details is not clipped by iframe boundaries. Further detail on how to add one or more stand-alone sidebars to your web page can be found in the installation_guide.html. Examples of what a sidebar can look like can be found on the LuxSoft Demo page.
h. Color-coding Events
When defining user groups, for each group a background color can be specified and when defining event categories, a text color and a background color can be specified for each category. On the admin's Settings page, under Events, the admin can select whether on the calendar pages the color of the event titles in the various views should correspond to the color of the user group to which the originator of the event belongs or to the event category to which the event belongs.
When adding/editing event categories a check box "Day color" can be checked. If this check box is checked, in the various calendar views, if an event in this category is displayed for a certain day, the background of the whole day will take the color of the event. This can for instance be useful to make special events, like holidays or birthdays, more visible.
i. Importing Data of Previous LuxCal Versions
There are different ways to import calendar data of previous LuxCal versions, back to LuxCal version 2.7.2. If you want to import data of a LuxCal version less than 2.7.2, read the Upgrade Instructions in the Release Notes (release_notes_xxx.html, where xxx = the LuxCal version).
- Upgrading the calendar
- Importing data via the LuxCal Toolbox (see section 4 below)
- Importing data via an external tool
When upgrading the calendar to a newer version, following the upgrade steps in the Release Notes, the calendar(s) in the database will automatically be upgraded to the new Calendar version.
The lctools.php file from the calendar toolbox can be uploaded to the calendar root directory and launched via the browser. Via these tools a database back up files of a previous LuxCal version (as of LuxCal 2.7.2) can be imported. At the end of the import process, the database schema will be upgraded to the current calendar version without loss of data. Thereafter the calendar can be started.
You can use an external tool on your server, e.g. phpMyAdmin or phpLiteAdmin, to import database back up files of previous LuxCal versions directly into the database. Before starting the calendar, the upgradexxx.php file should be uploaded to the calendar root folder on your server and be launched via your browser. Thereafter the calendar can be started.
When in doubt if the calendar data in your database is up to date, you can at any time upload the upgradexxx.php file to the calendar root folder on your server and launch it. The script will verify, and if necessary upgrade, the database schema of your calendar(s).
4. LuxCal Toolbox
The toolbox contains several tools and utilities, which can help you set up and manage your calendar. Below you will find a short description of each of the tools / utilities.
4a. General Toolbox - lctools.php
The lctool.php file should be uploaded to the calendar's root directory and launched via your browser. This toolbox is particularly useful when managing multiple calendars. It contains tools to perform the following actions:
- Test the configuration
- Create new calendars
- Set the default calendar
- Delete calendars
- Replicate data and/or settings from file
- Back up calendars
- Download a backup file from the 'files' folder
- Import a calendar backup file of a previous LuxCal version
Most actions should be used with caution. Always carefully read the displayed instruction!
4b. PHP Installation Details - phpinfo.php
The phpinfo.php utility should be uploaded to the calendar's root directory on your server and should be launched via your browser. When started, this utility will display all installation details of the PHP installation on your server.
4c. SMTP Mail Test Utility - smtptest.php
When you prefer to use SMTP mail, rather than PHP mail, for your email reminders and cron job reports, you can select SMTP mail on the admin's Settings page of your calendar. Before doing so you can use the SMTP Mail Test Utility "smtptest.php", in the smtpmail folder, to test your SMTP mail and its parameters. The smtptest.php file should be uploaded to the calendar's root directory on your server. Before launching it via your browser, you should start the calendar and specify the SMTP parameters on the admin's Settings page, under Email Settings.
4d. LDAP Integration (Experimental)
In the ldapmod folder you will find instructions and files to implement LDAP (Lightweight Directory Access Protocol) integration for the LuxCal calendar. A common usage of LDAP is to provide a "single sign on" where one password for a user is shared between various services on an intranet.
The LDAP Integration module has been produced by Martin Dziobek, HLRS Uni Stuttgart. For further details see the README.txt file in the ldapmod folder in the LuxCal toolbox.
4e. Database Administration with phpLiteAdmin
In the phpliteadmin folder you will find phpLiteAdmin, an easy to use web-based SQLite database admin tool written in PHP. details on how to use this free tool can be found here.
In the associated phpliteadmin.config.php file, you should at least set the following variables:
- $password - password to gain access
- $directory - directory of the database file(s)
- $allowed_extensions - array with allowed database file extensions (for LuxCal: ".cdb")
5. Calendar Settings - Description
The calendar settings which are automatically generated during the installation process are stored in the settings table of the database. All settings can be changed by the calendar administrator via the Settings page in the administration drop down menu on the navigation bar at the top right corner of the screen.
For those interested in technical details: The following are explanations of the PHP variables stored in the settings table of the database:
calendarTitle: The title of the LuxCal calendar that is displayed in the header of the various calendar views.
calendarUrl: The full URL address of the calendar, used for notification purposes, E.g. http://www.mysite.xxx/calendar/index.php.
calendarEmail: The sender's e-mail address ("From") in emails sent by the calendar. E.g. reminders, cron job summary reports. See also notifSender below.
backLinkUrl: URL of parent page. If specified, a Back button will be displayed on the left side of the Navigation Bar which links to this URL. For instance to link back to the parent page from which the calendar was started.
timeZone: Your local time zone. See the PHP Supported Time Zones for possible values. Setting the correct time zone is important for the "today" indication in the various views and when the "notification" feature is used.
notifSender: When the calendar sends reminder emails, the sender field of the email can contain either the calendar email address, or the email address of the user who created the event. In case of the user email address, the receiver can reply to the email.
rssFeed: If enabled: RSS feed links will be displayed in the calendar footer and will be included in the HTML head section.
navButText: If enabled: The buttons on the navigation bar will be displayed with text
navToapList: If enabled: A To approve list button will be displayed on the navigation bar for users with at least manager rights. The button can be used to display the list of events that need approval.
navTodoList: If enabled: A Todo list button will be displayed on the navigation bar, which can be used to display the Todo list.
navUpcoList: If enabled: An Upcoming button will be displayed on the navigation bar, which can be used to display the Upcoming Events list.
viewMenu: Specifies whether the view menu is displayed in the calendar's options panel. Possible values: 0 = disabled, 1 = enabled.
groupMenu: Specifies whether the user group filter is displayed in the calendar's options panel. Possible values: 0 = disabled, 1 = enabled.
userMenu: Specifies whether the user filter is displayed in the calendar's options panel. Possible values: 0 = disabled, 1 = enabled.
catMenu: Specifies whether the event category filter is displayed in the calendar's options panel. Possible values: 0 = don't display the category filter menu, 1 = display the category filter menu.
langMenu: Specifies whether the calendar users are allowed to select their preferred user interface language the calendar's options panel. Possible values: 0 = don't display the language selection menu, 1 = display the language selection menu.
viewButtons: View buttons to be displayed on the navigation bar (1:year, 2:month, 3:work month, 4:week, 5:work week 6:day, 7:upcoming, 8:changes, 9:matrix)
defaultView: The initial calendar view to be displayed when the LuxCal Calendar is started. Possible values/views: 1 = Year, 2 = Full Month, 3 = Work Month, 4 = Full Week, 5 = Work Week, 6 = Day (today), 7 = Upcoming events, 8 = Changes and 9 = matrix.
language: The default user interface language. Only installed languages can be specified.
ownerTitle: When enabled, the event owner's name will be shown in front of the event title in the various calendar views (0:disabled 1:enabled).
privEvents: Can be disabled, enabled or default. If enabled: The user can choose to create private events, which are hidden from other users. If default: All events entered by a logged in user will default to private.
details4All: If disabled: event details will only be visible to the owner of the event and to users with 'post all' rights. If enabled: event details will be visible to the owner of the event and to all other users. If "for logged-in users": Event details will only be visible to logged-in users.
evtDelButton: If disabled: the Delete button in the Event window will not be visible. If enabled: the Delete button in the Event window will be visible, so all users with sufficient rights can delete events. If manager: the Delete button in the Event window will only be visible to users with "manager" rights.
eventColor: Specifies whether events should be displayed with the event owner color, or with the event category color (0: owner color, 1: category color)
xField1Label / xField2Label: The name of two optional free format text fields, which can be added to the Event window form and in all calendar views and pages. The specified name can be max. 15 characters long. E.g. 'Email address', 'Website', 'Phone number'.
xField1Public / xField2Public: Specifies if the respective extra field is visible to all users, or just to logged in users. Possible values: 0 = disabled, 1 = enabled.
selfReg: Indicates whether users can register themselves via the Log-in page. Possible values: 0 = self-registration disabled, 1 = self-registration enabled.
selfRegGrp: The ID of the group to which self-registered users are automatically assigned.
selfRegNot: Indicates whether a notification should be sent to the admin when a user has self-registered. Possible values: 0 = disabled, 1 = enabled.
restLastSel: Indicates whether the last user selections (the Option Panel settings) should be restored. When the user revisits the calendar at a later moment, these values will be restored. Possible values: 0 = not set, 1 = set
cookieExp: Number of days before a 'Remember me' cookie - set during Login - expires
evtTemplGen: Specifies which event fields should be displayed and in which order, on the general calendar views and pages.
evtTemplUpc: Specifies which event fields should be displayed and in which order in the Upcoming Events view.
evtTemplPop: Specifies which event fields should be displayed in the pop-up box when hovering events.
popBoxYear: Specifies whether a pop up box with event details should be displayed in Year view when hovering an event.
popBoxMonth: Specifies whether a pop up box with event details should be displayed in Month view when hovering an event.
popBoxWkDay: Specifies whether a pop up box with event details should be displayed in Week/Day view when hovering an event.
popBoxUpc: Specifies whether a pop up box with event details should be displayed in Upcoming Events view when hovering an event.
yearStart: The start month in year view (1-12 or 0, 0: current month).
YvColsToShow: The number of months to show per row in year view.
YvRowsToShow: The number of 4-months rows to show in year view. The default value is 4.
MvWeeksToShow: The number of weeks to show in month view. The value 0 (zero) has a special meaning and will result in the display of just one single full month. The default value is 10.
workWeekDays: A string of numbers which specify the days of the week to show in work month view and work week view. Valid day numbers are: 1 = Monday, 2 = Tuesday, ... , 7 = Sunday.
XvWeeksToShow: The number of weeks to show in matrix view. The default value is 8.
lookaheadDays: The number of days to look ahead in upcoming view, todo list and RSS feeds. The default value is 14 (two weeks).
dwStartHour: The start of the full time block on the day and week views. The default value is 6 (corresponding to 6:00am). This parameter helps to avoid wasting space for the nightly hours, where normally no, or very few, events are planned.
dwEndHour: The end of the full time block on the day and week views. The default value is 18 (corresponding to 18.00/6:00pm). This parameter helps to avoid wasting space for the nightly hours, where maybe no, or very few, events are planned.
dwTimeSlot: The time slot size (in minutes) in day/week view. Together with the dwStartHour (see above) this value determines the number of rows in day/week view.
dwTsHeight: The time slot display height (in number of pixels) in day/week view.
showLinkInMV: Specifies whether URL-links, specified in the description field or one of the extra fields (see xField1 and xField2 above) of the events, should be shown in month view (0: no, 1: yes)
monthInDCell: Specifies whether in month view in each day cell the three-letter month abbreviation should be displayed (0: no, 1: yes)
dateFormat: Text string defining the format of dates in dd, mm and yyyy. Possible characters: y: yyyy, m: mm, d: dd and any non-alphanumeric as separator.
MdFormat: Text string defining the format of dates in dd and month. Possible characters: d: dd, M: month in letters and any non-alphanumeric as separator.
MdyFormat: Text string defining the format of dates in dd, month and yyyy. Possible characters: d: dd, M: month in letters, y: yyyy and any non-alphanumeric as separator.
MyFormat: Text string defining the format of dates in month and yyyy. Possible characters: M: month in letters, y: yyyy and any non-alphanumeric as separator.
DMdFormat: Text string defining the format of dates in weekday, dd and month. Possible characters: WD: weekday in text, d: dd, M: month in letters and any non-alphanumeric as separator.
DMdyFormat: Text string defining the format of dates in weekday, dd, month and yyyy. Possible characters: WD: weekday in text, d: dd, M: month in letters, y: yyyy and any non-alphanumeric as separator.
timeFormat: Text string defining the format of times in hh and mm. Possible characters: h: hours, m: minutes, a: am/pm (optional), A: AM/PM (optional) and any non-alphanumeric as separator.
weekStart: The first day of the week. Possible values: 0 = Sunday, 1 = Monday.
weekNumber: Specifies whether week numbers should be displayed in the various calendar views. Possible values: 0 = disabled, 1 = enabled. The default value is 1.
mailServer: Specifies whether PHP mail or SMTP mail should be used for email reminders and periodic reports. Possible values: 0 = mail disabled, 1 = PHP mail, 2 = SMTP mail. The default value is 1.
smtpServer: Text string specifying the name of the SMTP server. For gmail this is for instance 'smtp.gmail.com'.
smtpPort: Specifies the SMTP port number. For example 25, 465, 587. Gmail for example uses port number 465.
smtpSsl: Specifies whether Secure Sockets Layer (SSL) should be used. Possible values: 0 = no, 1 = yes. Gmail for instance uses SSL. The default value is 1.
smtpAuth: Specifies whether authentication should be used when sending SMTP mail. Possible values: 0 = no, 1 = yes. Gmail for instance uses authentication. The default value is 1.
smtpUser: Text string specifying the SMTP user name. Required when SMTP authentication should be used.
smtpPass: Text string specifying the SMTP password. Required when SMTP authentication should be used.
cronHost: Specifies where the cron service, used for the periodic functios, is hosted. Possible values: 0 = local (on the same server as the calendar), 1 = the cron service of a remote server is used, or lcalcron.php is started manually via the browser (for testing purposes), 2 = the cron service of an external server with a specified IP address is used.
cronIpAddr: A text string with the IP address of the remote cron server. IP address format: xxx.xxx.xxx.xxx, where xxx is a figure in the range 0 - 255
adminCronSum: Specifies whether the calendar administrator will receive a summary report after the periodic functions have been executed. Automatic periodic functions should be installed (see below) and emailing cron job output should be enabled on the server.
chgEmailList: A list with destination email addresses for calendar changes sent by the sendchg.php script. Automatic periodic functions should be installed (see below).
chgNofDays: The number of days the sendchg.php script (see previous variable) should look back for calendar changes. If the automatic periodic functions have been installed (see below), this variable could be set to 1 (one day)
icsExport: Export events in iCalendar format to a .ics file in the 'files' folder. The file name is the calendar name with blanks replaced by a underscore. This function works via a cron job.
eventExp: The number of days after the event's due date when an event expires and will be automatically deleted (0:never). This function works via a cron job.
maxNoLogin: Indicates after how many 'no-login' days a user account should be automatically deleted. Possible values: 0 = never delete a user account, 1 - 365 = number of days. Automatic periodic functions should be installed (see below).
miniCalView: The calendar view for the LuxCal mini calendar. Possible values/views: 1 = Full Month, 2 = Work Month, 3 = Full Week, 4 = Work Week.
miniCalPost: Indicates whether events can be added, edited and deleted via the mini calendar without opening the full calendar. Possible values: 0 = posting of events disabled, 1 = posting of events enabled. The default value is 0.
popFieldsMcal: Specifies which event fields should be displayed in the hover box with event details in the mini calendar. Only fields which are also defined in the setting "evtTemplGen" will be displayed. If no fields are specified, no hover box will be displayed.
mCalUrlFull: When clicking the month at the top of the mini calendar, to go to the full calendar, the user will be directed to this URL. If not specified, the full calendar will open in a new window. This URL is in particular useful when the full calendar is embedded in an existing user page.
popFieldsSbar: Specifies which event fields should be displayed in the hover box with event details in the stand-alone sidebar. Only fields which are also defined in the setting "evtTemplGen" will be displayed. If no fields are specified, no hover box will be displayed.
showLinkInSB: Specifies whether URL-links, from the description field of the events, should be shown in the sidebar (0: no, 1: yes).
sideBarDays: The number of days to look ahead in the sidebar. The default value is 14 (two weeks).


Readme¶
Overview¶
This package provides a IPython [magic commands](http://ipython.readthedocs.io/en/stable/interactive/magics.html) to delegate cell content execution to a workload scheduler.
Workload scheduler are mostly used in High Performance Computing environment to manage resources usability to users. Currently, this package supports only [Slurm](http://slurm). It exists other schedulers, that contributors should feel free to add support:
- [Slurm](http://slurm) (supported)
- OAR
- PBS
- ...
This package is also supporting basic SSH instead of workload scheduler.
This package exposes functionalities through a cell magic command : %%execute. Backend is provided in the execute_batch_scheduler Python sub-package.
Installation¶
This package installs through Python distutils :
python setup.py install
The default backend workload scheduler may be configured on install. Example for slurm:
python setup.py install –workloadmanager=slurm
Default command line arguments may also be configured on install. Example for setting a specific slurm QOS:
python setup.py install –workloadmanager=slurm –workloadmanagercmdargs=–quos=ipythoncell
Example for setting a specific slurm QOS and a host for ssh:
python setup.py install –workloadmanagercmdargs=’{“slurm”: “–quos=ipythoncell”, “ssh”: “–host=amachine”}’
The magic command is then activated as an IPython extension:
In [1]: %load_ext execute_batch_scheduler.execute_magic
Usage example¶
A single entry point is the %%execute magic:
```text In [2]: %%execute -n8 -N4 srun -n 8 hostname ...: Submitted batch job 957969 Running . End batch job 957969 Status: COMPLETED
romeo137 romeo137 romeo138 romeo138 romeo139 romeo139 romeo140 romeo140 ```
Command line arguments (-n8 -N4 in the example above) are passed to the workload manager submission command, salloc here for Slurm. Some command line arguments are reserved, and intercepted, by the magic command. See below
#### Common arguments:
- –wlm=<backend> : select the backend workload manager (currently available: ssh, slurm). Default value is set at install.
- –shell=<SHELL> : shell to use as a script shebang !#SHELL. Default value is /bin/bash
- –bg : run the cell content in background. No output will be printed for this cell.
- –amgr=<VAR> : variable in user namespace to store backend object. Only way to get cell output when used with –bg.
### SSH example
SSH backend is not a workload manager but simply use ssh to reach executing resources. The ssh is not taking any standard input from user so it must connect without password or passphrase.
Specific arguments:
- –host : host to reach with ssh
`text
In [3]: %%execute --workloadmanager=ssh --host=adistantmachine
echo "Hello from $(hostname)"
...:
SSH started with pid: 10315
Running .
Done
Hello from adistantmachine
`
### Slurm example
Slurm backend to run cell content as slurm jobs. All parameters are passed to sbatch command.
```text In [4]: %%execute -n8 -N1 –reservation=rsv –time=00:42:00 echo $SLURM_JOB_ID srun -n 8 hostname ...: Submitted batch job 957970 Running . End batch job 957970 Status: COMPLETED
957970 romeo141 romeo141 romeo141 romeo141 romeo141 romeo141 romeo141 romeo141 ```
## Overriding installed configuration
A IPython profile specific configuration may be wanted for ‘on-the-fly’ generated profiles (associated to a specific usage). This configuration would override install parameters. To do so, inserts this kind of line in the ipython_config.py file of the profile:
```python c.InteractiveShellApp.exec_lines = [
‘import execute_cell; execute_cell._DEFAULT_LINE_CMD_ARGS=”–host=amachine”; execute_cell._DEFAULT_MGR=”ssh”’


Links
Events
Second IEEE International Workshop on Mobile Vision
Fist IEEE International Workshop on Mobile Vision
Special Issues
IJCV Special Issue on Mobile Vision
|
CFP
Computer - What's Real About Augmented Reality?
Color
Charles Poynton
Easy RGB
Efficient Color For Efficient Web Applications
Color Vison and Art
EXIF
Exif (wikipedia)
Exif Format
Exif Example
Copyright ©
Luiz Velho


Recursive least square adaptive filtered average.
y = ewrls(data,p,lambda) y = ewrls(data,p,lambda,nPreAvg) y = ewrls(data,p,lambda,nPreAvg,delta) y = ewrls(data,p,lambda,nPreAvg,delta,dir) ewrls(...)
This function computes a filtered average of the input data, using an adaptive filter method called exponentially weighted recursive least squares (RLS or EWRLS) filtering.
It takes an 2D input array data
containing the spectral data. Each column
should represent one scan, and there should be multiple scans. It returns the filtered average in y
.
The filter contains two parameters: The filter length p
is typically in the range 5-50 and
deterimes how many consequtive points are used to predict the next point. The memory factor lambda
is a positive number slighty smaller than 1 (typically 0.9-0.99) and determines the memory of the filter,
larger lambda
values corresponding to longer memory.
The parameter nPreAvg
determines how many scans are used to estimate a target signal. This
number should be smaller than the number of scans in the data array, or it can be zero. If it is zero, all
the scans are used. This is the preferred setting, and also the default.
delta
is the regularization parameter and is used to initialize the matrix P in the
recursive least squares algorithm. Usually, there is no need to set this value.
dir
determines the direction the filter is applied. 'f'
is the forward direction,
'b'
is the backward direction, and 'fb'
computes an average of the forward and
the backward direction. This is the default.
Let's generate some dummy data
nScans = 100; nPoints = 1001; t = linspace(-1,1,nPoints); signal = gaussian(t,0.2,0.3,1) + gaussian(t,-0.2,0.15,1)/2; signal = signal(:)/max(signal); for k = 1:nScans datamatrix(:,k) = addnoise(signal,2,'n'); end
Now let's compute a filtered average using ewrls
, and have the
function plot the result:
p = 20; % filter length lambda = 0.96; % memory factor nPreAverage = 0; delta = 100; % regularization parameter ewrls(datamatrix,p,lambda,nPreAverage,delta,'fb');
ewrl
is described in


Provides an 'htmlwidgets' interface to 'billboard.js', a re-usable easy interface JavaScript chart library, based on D3 v4+. Chart types include line charts, scatterplots, bar/lollipop charts, histogram/density plots, pie/donut charts and gauge charts. All charts are interactive, and a proxy method is implemented to smoothly update a chart without rendering it again in 'shiny' apps.
| Version: | 0.2.4 |
| Depends: | R (≥ 3.1.0) |
| Imports: | htmlwidgets, htmltools, magrittr, jsonlite, ggplot2, scales |
| Suggests: | RColorBrewer, shiny, testthat, knitr, rmarkdown, prettydoc |
| Published: | 2018-10-08 |
| Author: | Victor Perrier [aut, cre], Fanny Meyer [aut], NAVER Corp [cph] (billboard library) |
| Maintainer: | Victor Perrier <victor.perrier at dreamrs.fr> |
| BugReports: | https://github.com/dreamRs/billboarder/issues |
| License: | MIT + file LICENSE |
| URL: | https://github.com/dreamRs/billboarder |
| NeedsCompilation: | no |
| Materials: | README NEWS |
| CRAN checks: | billboarder results |
| Reference manual: | billboarder.pdf |
| Vignettes: |
Introduction - basic use Mapping - map variables to the chart Options - styling charts |
| Package source: | billboarder_0.2.4.tar.gz |
| Windows binaries: | r-devel: billboarder_0.2.4.zip, r-release: billboarder_0.2.4.zip, r-oldrel: billboarder_0.2.4.zip |
| OS X binaries: | r-release: billboarder_0.2.4.tgz, r-oldrel: billboarder_0.2.4.tgz |
| Old sources: | billboarder archive |
Please use the canonical form https://CRAN.R-project.org/package=billboarder to link to this page.


I'm young motivated and obsessed of doing things and solving a problems man. That’s why I choosed to learn Law and Software engineering. I love black Americano with one spoon of sugar, my favourite number is one cause I love to be first at everything. I love challenges and the weekends with my friends. I like to see my boss smile when I have done all day work until lunch.
The job included mostly work with clients, money and cooking. I really enjoyed it because I love working with people and most of all cooking - it's my passion.
I helped clients by building there presents only using wordpress.
I am proud to say that I studied math four f*cking years but let's be honest for four year of math. I don't want to see it anymore.
I am still on my jurney to filling out this paragraph and I hope this momment is comming soon.
Solving a problems and helping peoples is the best antistress pill for me.
That's a wordpress website I build for one of my clinets. It's about about buying hourses in the Baltimore area.
View ProjectMaryland Productions are entertainment and event technology company. They offer rental of music equpment, lights video producstions and more.
View Project


Back to project repo
Sample progressbar
{{ preciseCurrent || current }}/{{ max }}
Increment
Decrement
Increment 10
Decrement 10
Customize!
Semicircle:
Responsive:
Rounded:
Clockwise:
Gradient:
Current:
Max:
Stroke:
Radius:
Offset:
Duration:
Animation:
Animation delay:
Color:
Background color:
Clock example
{{ time }}


Cabinet approves sale of 5 PSUs including BPCL, Shipping Corp, CONCOR
Finance Minister Nirmala Sitharaman said the Cabinet has given the in-principle approval for disinvestment in select CPSEs.
by Moneycontrol NewsFinance Minister Nirmala Sitharaman said the Cabinet has given the in-principle approval for disinvestment in select CPSEs.
This includes the government's stake of 53.2 percent Bharat Petroleum Corporation Limited (BPCL). This is excluding BPCL’s equity shareholding in Numalighar Refinery, based in Assam.
The in-principle approval has also been granted for the government's 63.75 percent in Shipping Corporation of India, 30.8 percent of Container Corporation of India, to a strategic buyer.
Further, 74.23 percent of THDC and 100 percent in North Eastern Electric Power Coporation Limited (NEEPCO) will be sold to NTPC.
Sitharaman also said that the management control of these respective companies will be handed over to the strategic buyer.


#comment Copyright 2016 Erik Neumann. All Rights Reserved. #comment Use of this source code is governed by the Apache License, Version 2.0. #comment See the LICENSE file and http://www.apache.org/licenses/LICENSE-2.0. #define #TOP_DIR ../.. #define #APP_PATH sims.experimental.BikeTimerApp #include "#TOP_DIR/macros.html" #DOC_TYPE
#META_TAGS #HIDE_ALL #SITE_LOGO


There has been some sort of error! We are working on fixing it now, in the meantime go to the home page and try again.