public final class ClientAssociation
extends java.lang.Object
ClientAssociation
is obtained using ClientSap
. An association object can be
used to execute the IEC 61850 ACSI services. Note that not all ACSI services have a corresponding
function in this API. For example all GetDirectory and GetDefinition services are covered by
retrieveModel()
. The control services can be executed by using getDataValues and
setDataValues on the control objects in the data model.| Modifier and Type | Method and Description |
|---|---|
void |
cancelUrcbReservation(Urcb urcb) |
void |
close()
Will close the connection simply by closing the TCP socket.
|
void |
createDataSet(DataSet dataSet)
The client should create the data set first and add it to either the non-persistent list or to
the model.
|
void |
deleteDataSet(DataSet dataSet) |
void |
deleteFile(java.lang.String filename)
Delete a file from the server
|
void |
disableReporting(Rcb rcb) |
void |
disconnect()
Will send a disconnect request first and then close the TCP socket.
|
void |
enableReporting(Rcb rcb) |
void |
getAllDataValues()
Will update all data inside the model except for control variables (those that have FC=CO).
|
java.util.List<ServiceError> |
getDataSetValues(DataSet dataSet)
The implementation of the GetDataSetValues ACSI service.
|
void |
getDataValues(FcModelNode modelNode)
The implementation of the GetDataValues ACSI service.
|
void |
getFile(java.lang.String filename,
GetFileListener listener)
Read a file from the server
|
java.util.List<FileInformation> |
getFileDirectory(java.lang.String directoryName)
Read the file directory of the server
|
void |
getRcbValues(Rcb rcb) |
int |
getResponseTimeout()
Gets the response timeout.
|
boolean |
isOpen() |
void |
operate(FcModelNode controlDataObject)
Executes the Operate ACSI Service on the given controllable Data Object (DO).
|
void |
reserveBrcb(Brcb brcb,
short resvTime) |
void |
reserveUrcb(Urcb urcb) |
ServerModel |
retrieveModel()
Triggers all GetDirectory and GetDefinition ACSI services needed to get the complete server
model.
|
boolean |
select(FcModelNode controlDataObject)
Performs the Select ACSI Service of the control model on the given controllable Data Object
(DO).
|
java.util.List<ServiceError> |
setDataSetValues(DataSet dataSet) |
void |
setDataValues(FcModelNode modelNode)
The implementation of the SetDataValues ACSI service.
|
java.util.List<ServiceError> |
setRcbValues(Rcb rcb,
boolean setRptId,
boolean setDatSet,
boolean setOptFlds,
boolean setBufTm,
boolean setTrgOps,
boolean setIntgPd,
boolean setPurgeBuf,
boolean setEntryId)
Sets the selected values of the given report control block.
|
void |
setResponseTimeout(int timeout)
Sets the response timeout.
|
void |
setServerModel(ServerModel model)
Set the server model instead of retrieving it from the server device.
|
void |
startGi(Rcb rcb) |
void |
updateDataSets()
This function will get the definition of all persistent DataSets from the server and update the
DataSets in the ServerModel that was returned by
retrieveModel or set using setServerModel . |
public int getResponseTimeout()
public void setResponseTimeout(int timeout)
timeout
- the response timeout in milliseconds.public void setServerModel(ServerModel model)
model
- the server modelpublic ServerModel retrieveModel() throws ServiceError, java.io.IOException
ServiceError
- if a ServiceError occurs while calling any of the ASCI services.java.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public void getDataValues(FcModelNode modelNode) throws ServiceError, java.io.IOException
ServiceError
will be thrown.modelNode
- the functionally constrained model node that is to be read.ServiceError
- if a ServiceError is returned by the server.java.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public java.util.List<FileInformation> getFileDirectory(java.lang.String directoryName) throws ServiceError, java.io.IOException
directoryName
- name of a directory or empty string for the root directoryServiceError
- if a ServiceError is returned by the server or parsing of response failed.java.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public void deleteFile(java.lang.String filename) throws ServiceError, java.io.IOException
filename
- name of the file to deleteServiceError
- if a ServiceError is returned by the serverjava.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public void getFile(java.lang.String filename, GetFileListener listener) throws ServiceError, java.io.IOException
filename
- name of the file to deletelistener
- callback handler to receive fall dataServiceError
- if a ServiceError is returned by the serverjava.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public void getAllDataValues() throws ServiceError, java.io.IOException
ServiceError
- if a ServiceError is returned by the server.java.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public void setDataValues(FcModelNode modelNode) throws ServiceError, java.io.IOException
ServiceError
will be thrown. In this case it is not possible to find out which of
several Basic Data Attributes could not be written.modelNode
- the functionally constrained model node that is to be written.ServiceError
- if a ServiceError is returned by the server.java.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public void updateDataSets() throws ServiceError, java.io.IOException
retrieveModel
or set using setServerModel
. It will delete DataSets that have been deleted since the last update and add
any new DataSetsServiceError
- if a ServiceError is returned by the server.java.io.IOException
- if a fatal association error occurs. The association object will be closed
and can no longer be used after this exception is thrown.public void createDataSet(DataSet dataSet) throws ServiceError, java.io.IOException
dataSet
- the data set to be created on the server sideServiceError
- if a ServiceError is returned by the server.java.io.IOException
- if a fatal IO error occurs. The association object will be closed and can
no longer be used after this exception is thrown.public void deleteDataSet(DataSet dataSet) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public java.util.List<ServiceError> getDataSetValues(DataSet dataSet) throws java.io.IOException
null
if reading was successful and a ServiceError if reading of this member failed.dataSet
- the DataSet that is to be read.java.io.IOException
- if a fatal IO error occurs. The association object will be closed and can
no longer be used after this exception is thrown.public java.util.List<ServiceError> setDataSetValues(DataSet dataSet) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public void getRcbValues(Rcb rcb) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public void reserveUrcb(Urcb urcb) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public void reserveBrcb(Brcb brcb, short resvTime) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public void cancelUrcbReservation(Urcb urcb) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public void enableReporting(Rcb rcb) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public void disableReporting(Rcb rcb) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public void startGi(Rcb rcb) throws ServiceError, java.io.IOException
ServiceError
java.io.IOException
public java.util.List<ServiceError> setRcbValues(Rcb rcb, boolean setRptId, boolean setDatSet, boolean setOptFlds, boolean setBufTm, boolean setTrgOps, boolean setIntgPd, boolean setPurgeBuf, boolean setEntryId) throws java.io.IOException
The data set reference as it is set in an RCB must contain a dollar sign instead of a dot to separate the logical node from the data set name, e.g.: 'LDevice1/LNode$DataSetName'. Therefore his method will check the reference for a dot and if necessary convert it to a '$' sign before sending the request to the server.
The parameters PurgeBuf, EntryId are only applicable if the given rcb is of type BRCB.
rcb
- the report control blocksetRptId
- whether to set the report IDsetDatSet
- whether to set the data setsetOptFlds
- whether to set the optional fieldssetBufTm
- whether to set the buffer timesetTrgOps
- whether to set the trigger optionssetIntgPd
- whether to set the integrity periodsetPurgeBuf
- whether to set purge buffersetEntryId
- whether to set the entry IDjava.io.IOException
- if a fatal IO error occurs. The association object will be closed and can
no longer be used after this exception is thrown.public boolean select(FcModelNode controlDataObject) throws ServiceError, java.io.IOException
The selection is canceled in one of the following events:
controlDataObject
- needs to be a controllable Data Object that contains a Data Attribute
named "SBO".ServiceError
- if a ServiceError is returned by the server.java.io.IOException
- if a fatal IO error occurs. The association object will be closed and can
no longer be used after this exception is thrown.public void operate(FcModelNode controlDataObject) throws ServiceError, java.io.IOException
controlDataObject
- needs to be a controllable Data Object that contains a Data Attribute
named "Oper".ServiceError
- if a ServiceError is returned by the serverjava.io.IOException
- if a fatal IO error occurs. The association object will be closed and can
no longer be used after this exception is thrown.public boolean isOpen()
public void close()
public void disconnect()


{# #} {# #} {# #}
The List of Device
| Device Number | Location | Type | Description |
|---|---|---|---|
| {{ device.0 }} | {{ device.1 }} | {{ device.2 }} | {{ device.3 }} |
Please select the device:
#}Please select the attribute:
#} {#You can choose
#} {#The Result of Analyzing
this is data
#} {#this is the data-point
#} {#this is the x-point
#}


Ammonia leak prompts food bank to dump 1.8M pounds of food
by The Associated PressHOUSTON — An ammonia leak that contaminated all three of the Houston Food Bank’s refrigerated storage areas has forced it to dump 1.8 million pounds of food just over a week before Thanksgiving Day.
The Houston Chronicle reports a fan broke in one of the food storage areas a week ago, severing a line feeding ammonia coolant and contaminating the food.
No injuries were reported from the toxic contamination, but Food Bank President Brian Greene says the food contaminated ranged from oranges and apples to rice and beans.
As of Tuesday, the shelves in the vast storage room where the leak happened had been emptied and a team had begun scrubbing down the areas.
___
Information from: Houston Chronicle, http://www.houstonchronicle.com
The Associated Press


TRLuck
Home
Person
Show All Person
Add Person
Authority
Toggle Sidebar
Welcome Come to Universal System!


Opencast Proposals
All important decisions for Opencast have to be made on list. For more details, please have a look at out documentation about decision making.
The following list contains a list of passed proposals for reference.
Passed Proposals
Automate translation merges
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Wed, 29 Sept 2018
Hi everyone,
a few weeks ago we discussed on the technical meeting that it would be
great if we could automatically merge back translations on a regular
basis.
That is why I hereby #propose:
Updates to translations for existing languages may be pushed into
Opencast's repository automatically.
Note that adding or removing languages will still need a regular pull
request and a review
If this proposal passes, I can implement the automation.
–Lars
No more merge tickets
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Thu, 17 May 2018
Hi everyone,
tl;dr
I hereby #propose to drop the practice of keeping a Jira ticket for
synchronizing merges
Today we had a short internal discussion about Opencast's merge tickets
where we found that all of us here at Osnabrück think that we should
drop the practice of keeping them.
The original goal for those was to prevent two developers to merge
things simultaneously causing conflicts for each other. Nowadays most
people use Github's merge button anyway which makes this far less
problematic since developers do not need to keep track of the upstream
branch but can just merge which will just magically work as long as
there is no conflict.
Some people still merge via command line but they are usually those who
can handle conflicts anyway ;-)
What also plays into this proposal is that we do not have that many
merges. So this is not that big a problem in the first place. And for
the few occasions where there are many merges (e.g. I remember some
merge sprints before a feature freeze) we always coordinated those
efforts anyway (who is taking which review, what's the progress, …) so
that not having a merge ticket wouldn't be a problem here either.
From experience I can say that even for cutting a release I probably
could have worked without a merge ticket with no problem: I pulled the
version I was cutting into my local branch anyway, so I could work
there and additional merges would not have interfered.
Finally, if there is a rare case where it actually makes sense to block
a branch, I deem us flexible enough to shout out on list, which may even
work better since the message is not drowned by hundreds of similar
messages :)
Best regards,
Lars
Migrate Docker Images to Quay.io
Proposed by Matthias Neugebauer<EMAIL_ADDRESS>passed on Tue, 1 May 2018
Hi,
as you might have noticed, there are currently no images available on Docker Hub
for Opencast 4.3. The problem is, that Docker Hub itself uses an old version of
Docker to build new images (version 17.06.1 is from mid 2017). When Opencast 4.3
was released, I prepared new Dockerfiles and also fixed an issue that resulted
in unnecessary large images. Now the problem is, that this requires (only for
building images) a feature that was only added to Docker 17.09 in September
2017. In addition, I found Docker Hub to be really slow and unreliable. Builds
start minutes after triggering and take a long time to complete. And there are
times when nearly all builds simply fail, e.g. because the base image could not
be downloaded or the machine used for building run out of disk space. All things
that should not happen leaving me quite frustrated with Docker Hub.
While Docker Hub is the "official" (more like default) image registry, there
exist multiple alternatives. Quay (https://quay.io/), for example, is another
bigger registry now run by CoreOS (owned by Red Hat). The service is free for
public images and offers some additional features compared to Docker Hub (e.g.
image vulnerability scanning). In my initial tests, I was really pleased. I
don't know what they are doing, but image builds start quick and take under 6
minutes! My local builds take 15-20 minutes :D
To come to the point: I herby #propose to further test out Quay and, if this
service performs well, migrate the Docker images to this registry. For the
tests, I would need to connect the opencast-docker repository to Quay, for which
I don't have the permissions. Also, the migration would leave the already
existing images on Docker Hub, but users would be advised to use the new
repository ("quay.io/opencast/allinone" instead of "opencast/allinone").
Best regards
Matthias
Drop Undocumented Workflow Handler
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Fri, 10 Nov 2017
Hi,
lately I discovered a couple of undocumented and probably unused
workflow operation handler, for example the 'failing' operation to name
one of them. All of these are not really useful in their current
undocumented form. That is why I hereby #propose to
drop all workflow operation handler still undocumented at the end of
the year.
If this proposal passes, I will create and publish a list of all
operations which would be dropped in their current state. If someone
still wants to keep any of them, the only thing they need to do is to
write a short documentation page for those operations. A task easily
done.
That way we may get rid of some unused, unnecessary old operations
while ensuring that all of the actually useful ones are documented and
thus usable without special inner knowledge of Opencast.
Regards,
Lars
Changing Translation Sources
Proposed by Sven Stauber<EMAIL_ADDRESS>passed on December 20, 2017
Dear Opencast Developers
I hereby #propose to add an additional rule to our development process as
described on [1]:
Adding or changing translation sources is not allowed in release branches
(implying that pull requests doing so need to be directed to the branch
develop).
Best regards
Sven
[1] https://docs.opencast.org/develop/developer/development-process/
Crowdin Acceptance Policy
Proposed by Greg Logan<EMAIL_ADDRESS>passed on November 17, 2017
Hi all,
Per the discussion in the meeting today, we need to set a policy regarding what
is expected of our Crowdin translators prior to joining the translation team.
My proposal is that they must write a brief, understandable sentence regarding
why they want to help translate Opencast via the Crowdin UI. This is an
optional field in the workflow where they request to be a translator (ie, no new
tools or fields) which is sometimes filled in, but mostly left blank. Something
like
'I want to help translate $project into [language]'
would be sufficient. This filters out the bots, yet is simple enough that
someone with Google translate ought to be able to work something out. Once this
passes I will update the Crowdin and Opencast docs regarding the requirements,
and then we should be good to go.
Proposal closes EOD 2017-11-17.
Rename Matterhorn Repository To Opencast
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on July 13, 2017
Hi everyone,
I think we have reached a point where people are wondering what the
hell matterhorn is ;-D
That is why I #propose to rename our official repository from
matterhorn to opencast:
old: https://bitbucket.org/opencast-community/matterhorn/
new: https://bitbucket.org/opencast-community/opencast/
This proposal will end on Thu Jul 13 16:00 CEST 2017
Regards,
Lars
Criteria For Inclusion Of Translations
Proposed by Sven Stauber<EMAIL_ADDRESS>passed on April 28, 2017
Dear all,
There are currently no rules about the criteria needed for a translation to be
included or excluded from the official Opencast releases.
I hereby propose the following rules:
1. A not yet supported translation is included into the next major release if
it is translated to at least 90% at the time when the release branch is cut.
The release managers will take the review if no other reviewer can be found.
2. A not yet supported translation may be included in the current release
branch anytime if it is translated to 100% and a reviewer is found. It will
then be part of the next minor release and major release if feasible
3. An endangered translation is a supported translation that is translated less
than 80% at the time when the release branch of the next major release is
cut. The release managers will publish a list of endangered languages if any
4. An endangered translation will be removed with the next major release if it
is not saved. The release managers take care of the removal in case no other
person will
5. An endangered translation may be saved by reaching at least 90% translated
until at least two weeks before the release date of the next major release
and a reviewer is found
6. Considering the percentages of being translated, Crowdin acts as reference
7. Considering the dates of the release cuts of major releases, the respective
releases schedules act as reference
Best,
Sven
Make Maintenance Releases Easier
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on April 24, 2017
Hi everyone,
over the last years, I have cut a lot of Opencast maintenance releases.
The process is to announce that a release will be cut, create a release
candidate and wait 72h without veto to actually release.
I have always sent out the voting mail as required by our release
process and I can always count on the usual response: No reply.
This is actually not very surprising since for example now for the
2.3.3 release, people have either already tested the latest state of
r/2.3.3 or are involved in the next big release already.
In short this means that we always have a three day waiting period in
which basically nothing happens. That is why I would like to change the
process for *maintenance releases* in the following way:
A release manager may cut new maintenance releases at any time
without prior release candidate.
He should openly announce the date for a new release a week before
the release or at any earlier point in time.
Note that this will also allow a release manager to release as fast as
possible if necessary (e.g. security fix) since the announcement is not
strictly required but only a strong advise.
This should lessen the work for the a release managers and will enable
more agile release processes. We also should not really loose any QA
work since everyone knows when releases will happen and people can
always test the latest state of a release branch which will become the
new release.
This proposal will not affect major releases where release candidates
with three days testing period would still be required.
I hope you agree with this change,
Lars
Minor documentation changes do not require JIRA issues or PRs
Proposed by Stephen Marquard<EMAIL_ADDRESS>passed on June 9, 2017
To reduce the overhead involved in improving our documentation, I #propose that
minor fixes to documentation may be committed to either maintenance branches or
develop without requiring a JIRA issue or pull request.
Markdown docs can be edited directly on bitbucket (and git should we move to
that), which is a very fast and convenient way for developers to fix
documentation.
Constraints: documentation fixes committed in this way should be minor changes
only; for example fixing typos, layout, formatting, links or small changes to
existing content, but no significant new content (which should continue to go
through the usual review process).
Requiring Java 1.8 for 3.0
Proposed by Greg Logan<EMAIL_ADDRESS>passed on June 12, 2017
Hi folks,
For those following along, James Perrin has identified an issue where 3.0
requires Java 1.8 at runtime. We haven't formally included that
requirement for 3.0 yet (it's already required for 4.0), but I hereby
propose that we do. No one seems to have noticed this requirement was
already present in 3.0 (not even me!), even at this late in the release
cycle which speaks, I think, to the already widespread adoption of Java
1.8. We would also have to go back and redo all of our testing were we to
change the problematic jar to an earlier version, which would be
unfortunate for our release timelines.
This proposal closes EOD 2017-06-12 UTC -6, at which point I should be able
to cut the release.
G
Change version numbers scheme
Proposed by Rüdiger Rolf<EMAIL_ADDRESS>passed on Mar 23, 2017
Hi all,
as we currently approach a new release, I would like to raise a question
when it comes to our version numbers: du we need a version number that
consists of three parts?
At the moment we have
<main-version-number>.<major-release-number>.<minor-release-number>.
With our current release process, with a new release every 6 month we
would always increase the <major-release-number>. Additional to this we
have the <minor-release-number> for bug-fix-releases, whenever they are
needed.
But we do not have a process for increasing the <main-version-number>.
Okay 2 years ago we were lucky enough that two long running sub-projects
that replaced all UIs in one release were finished. That was an obvious
reason to increase the main version. But will we ever be that lucky
again? Is only replacing all UIs justifying a main version increase?
If I look at the project history we had several milestones that could
have justified a new main version, like a nearly complete refactoring of
the backend in 1.4, the video-editor in 1.6, the Karaf update in 2.1,
the External API in 2.3.
*So my #proposal would be to remove the first part of the version number
for all upcoming releases. So our next release would be 3.0 and the
release at the end of the year it would be 4.0. *
We would follow other projects like Sakai in this change - although
without the confusing part of going from 2.9.3 to 10.0, where they
removed the first number.
What are your thoughts?
Regards
Rüdiger
Officially declare the Admin UI Facade as internal API for exclusive use by the module matterhorn-adminui-ng
Proposed by Sven Stauber<EMAIL_ADDRESS>passed on December 16, 2016
Dear all,
I hereby propose to officially declare the Admin UI Facade as internal API for
exclusive use by the module matterhorn-adminui-ng.
Reason:
The Admin UI Facade is essentially the backend of the Admin UI. While it would
be technically possible to use this API for other purposes, this would introduce
dependencies to components other than the Admin UI.
Allowing such dependencies to come into existence would cause changes to the
Admin UI Facade to potentially break other (possibly unknown external)
components. Hence, we would need to announce, coordinate and discuss changes to
this API to not break dependencies to components we potentially don't even know.
This would unnecessarily slow down the future development of the Admin UI. In
addition, Opencast 2.3 introduces the External API which has been explicitly
designed to meet the requirements of an API used to integrate other components.
Changes needed:
The documentation needs to reflect that the Admin UI Facade is an internal API
that will be changed without prior announcement whenever needed without
respecting dependencies other than the Admin UI itself and therefore people
shall not use this API for integration purposes.
Best,
Sven
Opencast Next: Code Cleanup
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Thu, 7 July 2016 15:21:19 UTC
Hi everyone,
a while ago we discussed on the technical meeting that we would like to
remove some old code from Opencast since these parts do not work
properly (sometimes not at all) or are unused.
Why cleaning up? To name some reasons:
- Less code to run (less memory, faster start-up)
- Less things to compile (faster build)
- Less dependencies
- People do not accidentally stumble upon broken things
- Less work for maintenance
And now here is what I #propose to remove and a reason why I think this
should be removed. I already took the comments people made in the first
draft [1] into account, although I still dared to include the two last
items but this time, hopefully with a convincing reason for why they
should be removed.
1. Old Administrative User Interface (matterhorn-admin-ui)
The reason for this should be obvious: We got a new one. The old one
has not been tested for the last three releases, is not linked
anywhere anymore and is partly buggy due to changes to Opencast. To
maintain two interfaces for one thing do not make sense.
2. Hold-state Workflow Operations
These do not work with the new interface any longer and the concept
has since been replaced by the actions you can perform on archived
material.
3. CleanSessionsFilter
Old temporary bug fix. For more details read the thread on our
developer list.
4. Republish Workflow Operation Handler
It can be removed since it has been replaced by a flag on
the publish operation in 2.x.
5. Old workflows + encodings
We got new ones. These were only left because of the old ui.
6. Old player (Flash in engage ui)
Flash is dead. We have the new player and Paella.
7. Most of shared_ressources
Almost everything in here belongs to old user interfaces.
8. matterhorn-engage-player
This is the old player Flex project. Iam not even sure it can still
be compiled.
9. matterhorn-test-harness
Old integration tests
10. matterhorn-mediapackage-ui
Old UI ressources
11. matterhorn-manager-*
Old, outdated configuration modification via web ui. This was never
used and would need a major update to get it working again at all.
12. matterhorn-load-test*
Some tests. I have never seen them executed by anyone.
13. matterhorn-holdstate-workflowoperation
Workflow operations requiring a hold state which does not exist
anymore with the new admin interface.
14. matterhorn-deprecated-workflowoperation
The name says everything. This includes the download DVD operation.
15. matterhorn-annotation-*
This should not work with either of the current players anymore.
16. docs/jmeter, docs/scripts/load_testing
Configuration for a performance testing tool. Not used for a long
time and not up-to-date.
17. Everything unused from:
https://data.lkiesow.de/opencast/apidocs/deprecated-list.html
E.g. FunctionException and ProcessExecutor(Exception)
18. matterhorn-webconsole
Karaf comes with a web console. We do not use our old implementation
anymore.
19. matterhorn-mediapackage-manipulator
Rest endpoint for media package manipulation. It's not used anymore
except by components to be removed.
20. matterhorn-search-service-feeds
Broken implementation for RSS/Atom feeds
21. matterhorn-caption-* and embed operation
Service for converting different subtitle formats and operation to
embed these subtitles into the media files. This is *not* player
caption support. If required, FFmpeg can be used for conversion
between several subtitle formats. Asked on list [2], no one uses
this.
As indicated before, points 20 and 21 had some comments for leaving them
in which did not convince me to not propose this. “Instead of removing
it, fix it” is an easy thing to say but sadly requires ressources.
Keeping it, announcing it as features and then tell people that it is
not working only afterwards is a bad thing and I would like to avoid
that.
Note that all the code is still in our history so that we loose nothing
if we want the old code back.
Please feel free to indicate if this action is fine for you or if you
want to keep some of the marked code. Please provide a reason if you do.
Best regards,
Lars
[1] http://bit.ly/28YOEZ1
[2] http://bit.ly/28Ztlt8
This proposal has passed with these additional corrections:
Hi,
we discussed this on today's technical meeting and I'm slightly
changing the proposal:
20. Let's remove matterhorn-search-service-feeds only after September
1st which is a realistic time to get things into the next Opencast
release. If someone has fixed the issue by them, we will, of
course, keep it.
This change takes into account that some people have said they are
interested into fixing that module, but will make sure that it's
removed if no one fixes it to not have an advertised but broken
feature.
21. I will be looking into adding subtitle support in a sensible way
before removing the matterhorn-caption-* modules or at least
clarify if they can still be used.
Regards,
Lars
Hi James,
a couple of days, I talked to someone saying that he will soon provide
a patch adding exactly this functionality. The holdstate operations are
definitely broken due to their UI.
My suggestion for a compromise here:
- Remove them if that patch for archiving the options is released
- Remove them if no one fixes them in time (September 1st) for 2.3
If you want to bring them back later, we always keep the code in our
history.
Regards,
Lars
> Hi,
> I would like to keep 2 and presumably 13. Both Manchester and AFAIK
> Cape Town have use cases for hold states since there is still no
> mechanism for passing WF configuration options from one WF to another.
> Regards
> James
The patch has already been published.
Opencast Community Repository Owners
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Fri, 13 May 2016 18:41:52 UTC
Hi,
today, in the technical meeting, we shortly discussed how to handle
requests, problems, etc regarding the other repositories we are hosting
under the umbrella of the Opencast community:
https://bitbucket.org/opencast-community/profile/repositories
While we have people who care about the official Opencast repository as
well as rules about what may be merged, who may merge things, … we do
not have that for other repositories and for some it's very unclear.
That is why I would like to propose that every repository under the
umbrella of the Opencast community needs to have a “project owner”
being responsible for that repository. Usually it should be the one
requesting that repository, but of course it can be someone else known
in the community.
I would also like to propose that if there is no one willing to take up
the responsibility to take care of a repository (ownership) if an old
owner leaves, the repository should either be removed or marked as
deprecated and moved to a separate section if so requested.
Finally, I would like to propose that we use the new “project” feature
of BitBucket to group the repositories into the groups:
- Opencast
- Contrib
- Adopters
- Deprecated (<- to be created if needed)
Currently, all repositories are in one big project.
Regards,
Lars
Rename Opencast Mailing Lists
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Thu, 14 Apr 2016 00:00:00 UTC
Hi everyone,
traditionally, we have the three mailing lists:
-<EMAIL_ADDRESS>(development list)
-<EMAIL_ADDRESS>(user list)
-<EMAIL_ADDRESS>(more or less announcements)
Recently, though, we have seen especially the last two list being used
for user questions and problems. That is not surprising as we dropped
the name “Matterhorn” and new users do not know what that the list
matterhorn-users is meant for questions about Opencast.
That is why I would like to rename these lists to
-<EMAIL_ADDRESS>or<EMAIL_ADDRESS>(I prefer the short
name but don't have very strong feelings about that)
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>Together with the already existing security-notices list, this gives
these lists a very clear meaning. It would also have the benefit that
users only interested in general announcements could subscribe to one
list only which would likely be a very low-traffic mailing list.
Additionally, this would make it sufficient to send announcements to
one list, instead of sending it to all three lists.
To prevent general questions on the announcements list, I suggest we
grant posting rights to board members, committers or other people who
have or had a role in our community only. I don't think we need to be
too strict here but should make sure that people understand what this
list is for.
Finally, for the sake of our current members, I would suggest that we
forward the mails to the old addresses for at least until the end of
the year, if that is possible.
Best regards,
Lars
Documentation Pull Request Merge Order
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Thu, 25 Feb 2016 20:52:00 UTC
Hi everyone,
as discussed in this weeks technical meeting, I hereby #propose to
allow out-of-order merges of documentation pull requests in the same way
we have this exception for bug-fixes.
to be precise, I #propose to change the development process docs for
reviewing and merging [1] in the following way:
[old]
- Pull requests for bug fixes (t/MH-XXXXX-...) may be reviewed and
merged out of order.
[new]
- Pull requests for bug fixes or documentation may be reviewed and
merged out of order.
Regards,
Lars
[1] https://docs.opencast.org/develop/developer/reviewing-and-merging/
Removing instances of print statements with a style rule #proposal
Proposed by Greg Logan<EMAIL_ADDRESS>passed on Wed, 12 Feb 2016 12:00:00 UTC
Hi folks,
I noticed in a recently review that there are still System.out.println
statements in use in our codebase. I was surprised, because thought we had
previously implemented a checkstyle rule which would have banned those
statements! I hereby #propose that we implement the changes outlined in
https://opencast.jira.com/browse/MH-11222, and remove these statements in
favour of logger statements. I also propose that we add this rule to the
checkstyle ruleset so that we don't have to deal with this again going
forward. Proposal closes EOD 2016-02-03.
G
How to release a new Opencast version…
Proposed by Lars Kiesow<EMAIL_ADDRESS>passed on Fri, 14 Aug 2015 12:54:51 UTC
Hi everyone,
serving as co-release manager for two versions of Opencast, I noticed
that our current release process has some aspects of the release defined
in a way that is more hindering than helpful and I want to #propose a
slight change to these recommendations.
I hereby #propose:
1. Get rid of the `master` branch, make `develop` the main branch.
2. Do not use the --no-ff flags for merges
3. Do not create versions/tags in a release branch. Separate them.
Reasoning:
1. The short explanation whould be: When did you explicitely checked
out `master` last time? People rarely do that. If I want a specific
version, I use the tag, if not I want the release branch or
`develop`.
If you think about it, then the whole reason for `master` in GitFlow
is to always provide the last stable version to users who just check
out the repository and do nothing else. The problem with Opencast is,
that we support multiple versions at the same time. If in a couple
of weeks 1.6.2 is being released, it is the latest stable. Is it? If
I check out `master`, however, I will still get 2.0 as we cannot
merge 1.6.x afterwards. While you can grasp the reasons behind this,
it is a bit confusing for users and it is much easier to just tell
them to use the tag to check out a specific version.
That it, if they do not use the tarballs from BitBucket anyway.
2. First of all, most people seem to be using BitBucket for
auto-merging and it does not use --no-ff. So we are not really
consistent anyway. Being consistent and using --no-ff would mean to
forbid the usage of the BitBucket merge.
Second, have a look at the confusing mess that are the current
branches (I tried to find something in the visualization a while ago
but gave up). It would be much cleaner to try using fast-forward
merges. So instead of using non-fast-forward commits I would argue
that we should instead try to use as many fast-forward commits as
possible.
3. Once we decided to have the tags in our branches like this:
---- A ---- B (tagged) ----- C ---- D -->
A is the commit containing the version that is decided to be
released. B is the tagged version. It is exactly the same code as A
except for the pom.xml versions that are modified. Finally C then
reverts B as the modified version should not be part of the release
branch, .... After C, the code is basically A again except for the
history (which we later need to merge which can be problematic). D
would then be the next “real” commit, meaning the next fix.
Much easier to handle would be the following structure:
---- A ---- D -->
\
B (tagged)
You do not have to revert that commit, you do not need to merge the
easily conflicting pom.xml changes and in the end, you would anyway
check out the tag using git checkout <tag> if you want that
specific version
Branching structure:
To have a complete overview, this is what the new branching structure
would look like:
develop --*--*--*--*--*----*--------*--------*---->
\ / /
r/x.y.z *--*--*---*--*--*--*--*--*---->
\ \
* x.y.z-beta1 * x.y.z-rc1
Regards,
Lars
Moving away from the 3rd party scripts
Proposed by Greg Logan<EMAIL_ADDRESS>passed by Fri, 24 Jul 2015 16:45:40 UTC
Hi folks,
As it stands right now we depend on the 3rd party tool script to
install a great many of our 3rd party dependencies. These are
utilities like tesseract, ffmpeg, sox, etc. This script is maintained
by Matjaz, in his own time. I'd like to take a moment to thank him
for a doing a great job on a particularly annoying aspect of
supporting our work! I know it hasn't been easy, especially
supporting vast number of different OS versions!
With the release of 2.0 I noticed that our 3rd party tool script is
becoming both a little out of date, and difficult to maintain. I took
a quick look around and it seems like *most* of our dependencies are
available from normal distribution repositories for Debian based
systems, and I'm told that there is a similar situation for Redhat
based systems. I am unsure of how many of our users are running
Matterhorn on Mac, but I would hope that our developers who are
working on Mac would be able to provide instructions and/or binaries
for those users. The only dependency where there might be a universal
sticking point is ffmpeg (due to patent concerns), however ffmpeg
builds a full static binary with each release, so I assume we can
either depend on this and/or cache them somewhere.
What this means is that we can potentially remove the 3rd party script
from our repository. I hereby #propose we find a way to do that,
which would remove the 3rd party script from the repository and
replace it with a number of new steps in the install documentation.
G
Status of youtube in 2.0 and #proposal to change the default workflow
Proposed by Rüdiger Rolf<EMAIL_ADDRESS>passed on Sat, 13 Jun 2015 14:15:55 UTC
Hi list!
There was some discussion in the DevOps meeting yesterday if the
Youtube distribution would work or not. I offered to check this.
The good news first: IT WORKS!
Just follow this manual and your Matterhorn - ups Opencast - is ready
to distribute to Youtube.
http://docs.opencast.org/r/2.0.x/admin/modules/youtubepublication/
The bad news: The default workflow definition does not really support
the publishing on Youtube, as only one video file could be published
by the current WOH.
https://opencast.jira.com/browse/MH-10920
The reason is simple and the fix would be too. But there are some
options to fix this:
1. Remove the option to distribute to Youtube from the default workflow
definition, as the complicated configuration would have to come
first anyway.
2. Only let "presenter" or "presentation" be published to Youtube. We
would need a new youtube tag and add this to the compose operation
and the youtube operation.
3. Introduce the composite operation to the workflow definition and
publish only the resulting single stream to Youtube.
4. Upgrade the WOH to support publishing of multiple files.
I would say that option 4 could be 2.1 goal, but not for 2.0.
I would #propose to go for option 1, as nobody can use Youtube
out-of-the-box anyway. And the admin could then setup an appropriate
Youtube workflow for their needs too.
Regards
Rüdiger
Episode DublinCore Catalog
Proposed by Karen Dolan<EMAIL_ADDRESS>Passed on Sat, 30 May 2015 12:39:05 UTC
Dear Opencast-ees,
The following proposal addresses MH-10821[1]. An issue that exposes a
know long time ambiguity regarding metadata and the ingest service.
The reason that its a proposal is that it normalizes the handling of
inbound episode catalog metadata in the ingest service.
1) A new configuration parameter, boolean, for the Ingest Service. The
config param identifies if episode metadata precedence is for
Ingestee (i.e. Opencast system) or the Ingester (i.e. Capture
Agent).
For example: at our site, the scheduling entity is the metadata
authority. All updates are made to the Scheduling endpoint. The
Capture Agent always has stale episode catalog metadata. At other
sites, updates are made on the Capture Agent directly. The
community default can be for priority to the Capture Agent.
2) All Ingest endpoints perform the same consistent process to ensure
that an episode catalog will exist, manually or automatically
provided.
3) The process performs the following...
3.1. Gather data
- Check if inbound media package contain a reference to an Episode
DublinCore catalog and if that catalog contains a title.
- Check if the inbound media package contains a title attribute.
- Check if the Workflow service has a reference to the mediapackage's
Episode Dublin Core catalog
- Check if the Scheduler service retained a reference to the event's
Episode Dublin Core catalog
3.2. Use config param to prioritize action on acquiring an Episode dc
catalog for the media package
If Capture Agent metadata takes precedence:
- Take the inbound Episode dc catalog, if it exists
- Take the Episode dc catalog from the workflow service, if it
exists
- Take the Episode dc catalog from the scheduler service, if it
exists
- Create an Episode dc catalog from the title in the media
package,, if it exists
- Create an Episode dc catalog using a default title (i.e.
"Recording-1234556XYZ")
If Opencast metadata takes precedence:
- Take the Episode dc catalog from the workflow service, if it
exists
- Take the Episode dc catalog from the scheduler service, if it
exists
- Take the inbound Episode dc catalog if it exists
- Create an Episode dc catalog from the title in the media
package, if it exists
- Create an Episode dc catalog using a default title (i.e.
"Recording-1234556XYZ")
I'll start a pull for the above, and appreciate any thoughts.
Regards,
Karen
[1] https://opencast.jira.com/browse/MH-10821
Dropping Taglines
Proposed by Greg Logan<EMAIL_ADDRESS>Passed on Fri, 29 May 2015 16:19:09 UTC
Hi folks,
I hereby propose that we drop the practice of having taglines. I
propose this because we don't have a place in the new admin UI to put
them, nor have I ever heard any of the adopters make use of it. I know
we don't use it as a committing group, which means that *no one* is
using them.
G
Wiki Cleanup
Proposed by Lars Kiesow<EMAIL_ADDRESS>Passed on Fri, 24 May 2015 11:36:49 UTC
Hi everyone,
since we partly switched to our new documentation [1] I would like to
make sure that the old and mostly outdated documentation goes away so
that no one stumbles upon that. When I had a look at the wikis we
currently have I noticed that most of our 17(!) wikis have not been
touched in years and can probably go away.
Here is a list of our wikis and what I #propose to do with/to them:
Keep (maybe clean-up a bit):
- Matterhorn Adopter Guides
- Matterhorn Developer Wiki
- Opencast Matterhorn D/A/CH
- Opencast Matterhorn Español
- LectureSight
Export as PDF to archive the contents and then delete:
- Matterhorn Release Docs - 1.0
- Matterhorn Release Docs - 1.1
- Matterhorn Release Docs - 1.2
- Matterhorn Release Docs - 1.3
- Matterhorn Release Docs - 1.4
- Matterhorn Release Docs - 1.5
- Matterhorn Release Docs - TRUNK
Keep until 2.1 is out then export as PDF and delete:
- Matterhorn Release Docs - 1.6
Just delete:
- Analytic video annotation
- Infra
- Matterhorn Documents
- Opencast Community
Please let me know if you agree or disagree with this proposal.
Regards,
Lars
[1] http://documentation.opencast.org
Jira Clean-Up
Proposed by Lars Kiesow<EMAIL_ADDRESS>Passed on Fri, 8 May 2015 11:52:16 UTC
Hi everyone,
as discussed in the technical meeting, I hereby #propose:
The “Blocker” and “Release Blocker” severity status are more or less
redundant. As part of cleaning up Jira, let us remove the “Release
Blocker” severity in favor of “Blocker”.
As footnote, some statistics: Since the beginning of 2014, 70 Release
Blockers have been files in Jira while mere *8* Blockers have been
files.
Regards,
Lars
Opencast Documentation
Proposed by Rüdiger Rolf<EMAIL_ADDRESS>Passed on Sat, 02 May 2015 14:43:28 UTC
Hi all,
Tobias, Basil, Lars and I discussed status of the current migration of
the Opencast (Matterhorn) documentation to GIT. We still see some open
issues that need clarification so we would like to propose the
following points:
*1. Formating and Hosting of the Documentation *
We want to use https://readthedocs.org to or a similar service create
a more appealing HTML version from the Markdown of the documentation.
The documentation will be versioned there so that for older versions
the documentation is still available. By default the "latest" version
is shown. The versions of the documenation will be generated based on
the release branches.
*2. Structure of the Documentation*
We see the documentation in*Git *separating into 3 sections:
- /Administration Guide/: with information about the installation,
configuration, customization and integration. This will be the part
of information by an administrator to setup
Opencast.
- /Developer Guide/: All information related to implementation
details of Opencast, so that this will be updated in a pull request
(API changes, module descriptions, architecture). The development
process documents should also go here as only committers usually
should change these.
- /User Guide/: Documentation of the (new) Admin UI that was already
started by Entwine and the Engage UI (especially Theodul Player).
This guide should only describe options available on the UIs.
Within the *Wiki* we still see the need for 2 sections:
- /Developer Wiki/: Proposals, working documents and meeting notes
will be kept here so that anybody can edit these. So information
not to close to any existing implementation that might still be in
a process of discussion can be found here.
- /Adopters Wiki/: This can be the place where adopters share their
best practises, configurations, hardware recommendations,
third-party software documentation etc. Again anyone can contribute
to this wiki.
The difference between the Wiki and Git is in the first line that the
Git documentation should become a quality assured ressource for
Opencast users. The Git documentation should be reviewed within the
release process and it will be part of the review process of a pull
request, to make sure that the needed documentation changes have been
contributed too.
The Wikis on the other hand should be a more open platform where
everybody can contribute and users might find cookbooks to enhance
their system, or they can share ideas.
So now we would like to get your opinion on this proposal.
Thank you,
Rüdiger
Requirement Specification
Proposed by Lars Kiesow<EMAIL_ADDRESS>Passed on Thu, 16 Apr 2015 15:55:31 UTC
On list or IRC we often see that people do not really know the current
requirements for a specific version of Opencast Matterhorn. Of course
there are the pom.xml files specifying internal dependencies, but there
is nothing for 3rd-party-tools, ...
It would be nice to add a file specifying these requirements in a
format that is easy to parse and can hence be used for automatic
scripts to generate dependency lists, ...
That is why I hereby #propose to add a requirements.xml file that
specifies the requirements for Opencast Matterhorn:
- Required tools including versions
- Which modules require which tools
- Which modules conflict with each other (negative requirement)
This is mainly what is not specified by the pom.xml files yet.
Jira Clean-Up (Tags VS Labels)
Proposed by Lars Kiesow<EMAIL_ADDRESS>Passed on Thu, 19. Mar 2015 15:43:20 UTC
…then hereby I officially #propose removing the labels from Jira.
For more details, have a look at the mail thread at:
https://groups.google.com/a/opencast.org/forum/#!topic/matterhorn/vIdWQkZmbdQ
FFmpeg Update
Proposed by Lars Kiesow<EMAIL_ADDRESS>Passed on Sat, 14 Mar 2015 22:12:18 UTC
Looking at the FFmpeg project for the last two years, you will notice
that they developed a pretty stable release cycle with a release of a
new stable version approximately every three month.
To stop us from having to propose an update again and again, I hereby
propose the following general rule for our support of FFmpeg:
A Matterhorn release will oficially support the latest stable
version of FFmpeg released at the time the release branch is cut and
all other FFmpeg versions with the same major version number released
afterwards.
For example, for Matterhorn 2 this would mean that we will officially
support FFmpeg 2.5.4 and all later 2.x versions like 2.6 which has
been released on the 7th of March or a possible 2.7 onece it is
released. We would, however, not necessarily support an FFmpeg 3 as it
*might* come with an interface change that *could* break compatibility.
That obviously does not mean that older versions of FFmpeg just stop
working. In fact, most parts of the default Matterhorn configuration
should at the moment still work with FFmpeg 1.x but we will not test or
fix compatibility problems.
Proposal Log
Proposed by Lars Kiesow<EMAIL_ADDRESS>Passed on Sat, 14 Mar 2015 16:35:08 UTC
It would be wonderful if we had a central place to look up the proposals
that have passed.
That is why I hereby propose that:
- We create a proposal log in our new documentation containing all
proposals that have passed on list.
- A proposal will become effective only after it is written down in
that log. That should usually be done by the person who sent out
that proposal.
This will, of course, not affect the existing decision making rules
(proposal on list, marked with #proposal, lazy consensus after three
days, no -1, ...)


| Synonym | Reference | Specificity |
| CYP epoxygenases | Exact | |
| CYP epoxygenase | Exact |
| Identifier | Name | Relation |
| HGNC:2648 | CYP4F8 | isa |
| HGNC:2631 | CYP2E1 | isa |
| HGNC:2622 | CYP2C8 | isa |
| HGNC:2596 | CYP1A2 | isa |
| HGNC:15654 | CYP2S1 | isa |
| HGNC:2646 | CYP4F3 | isa |
| HGNC:2623 | CYP2C9 | isa |
| HGNC:2642 | CYP4A11 | isa |
| HGNC:2621 | CYP2C19 | isa |
| HGNC:2595 | CYP1A1 | isa |
| HGNC:2637 | CYP3A4 | isa |
| HGNC:2620 | CYP2C18 | isa |
| HGNC:2645 | CYP4F2 | isa |
| HGNC:2634 | CYP2J2 | isa |
| HGNC:18857 | CYP4F12 | isa |
| Relation | Identifier | Name |
| isa | FPLX:CYP | CYP |


Menu COMPOSE UPLOAD Dashboard Me Time Today Tomarrow Yestorday This Week Trash All Status Ready Ongoing Completed


Linkedin, gmail and github might not be sufficient so please feel free to use this form to get in touch with me!


>
This is part of the old website. New website begins at fontforge.github.io
Are you a web developer? Help us migrate this page on Github
In summer of 2007 (as I write) MicroSoft is proposing an extension to OpenType
which will allow fonts to contain information useful for mathematical
typesetting. The information all lives in a new 'MATH'
table.
FontForge now allows you to perform basic editing on this table.
The
table is divided into several parts. One part provides information on font-wide
constants (And I do not mean "pi" or 2.71828... when I say constant here).
These have to do with the size of various elements of mathematical formulae
with respect to one another, and the spacing between them. So
FractionNumeratorGapMin
specifies the minimum gap (white space)
between the bottom of the numerator of a fraction and the fraction bar (the
rule between the numerator and denominator.
I will not describe all of these constants here, there are about 60 of them (and they take up 8 panes in the dialog). Most are fairly self-explanatory, but some I do not understand myself. FontForge has little popup messages plagerized from the specification which try to go into more detail.
Some of these constants are stored as percentages of some other size (ScriptPercentScaleDown is and means that sub-elements should be drawn at a pointsize 73% of the current one -- I think). But most constants are represented in em-units, and most of these may also have device table adjustments specified. (At small pixel sizes (such as those used for screen fonts) the rounding error introduced by converting from em-units to pixels may be as large as the movement itself. A device table allows you to specify that (in the case of AxisHeight above) when the font is rasterized to be 10 pixels high the Axis should be moved up by one pixel).
FontForge is not always configured to support device tables, so if these columns are missing you just need to reconfigure and rebuild it.
In addition to the constants there are various bits of data that potentially pertain to each glyph.
The simplest of these per-glyph data is a flag which indicates whether a glyph is an extended shape. Extended shapes tend to be taller than normal characters and need to have superscripts raised higher than normal shapes.
This sub-table consists of a list of glyph names and an indication of whether
this glyph is an extended shape (you may add additional glyphs at the bottom
of the list, order is irrelevant here).
The concept of "Italic correction" will be familiar to users of TeX. Basically when an upright glyph is placed after an italic (or oblique) glyph the slanted glyph may overlap the upright one slightly (since it is designed to fit next to another slanted glyph). The italic correction is a small addition to the glyph's advance width applied when followed by an upright glyph (and in some other cases too).
If you allow the mouse cursor to hover over an entry a small window will pop up showing the glyph, the normal advance width (as a dotted line), and the corrected advance width.
Here again you are allowed to specify a device table to adjust the
correction.
When positioning an accent above a glyph Mathmatical typesetting follows complex rules to determine how high about the glyph it should go. The standard Mark To Base GPOS lookup is inappropriate here.
Instead all that needs to be specified is the horizontal position at which the glyph and accent should attach.
This table can be used to specify that position in both the base glyph and the accent. In the example at right I show one of each. The vertical line indicates the attachment position in each, and the glyphs will be adjusted so the two lines match up.
Again a device table may be specified to control positioning at small pixel
sizes.
This subtable is used when positioning subscripts and superscripts at various corners of a glyph. A glyph may have a superscript attached to either its top left or top right edge (limits for integral signs use the same mechanism, and probably other concepts will as well), and a subscript at the bottom left or right.
In a slanted glyph it is clear that the horizontal positioning of a subscript should be different from the horizontal positioning of a superscript -- A problem similar to the italic correction. But this is more complex as the positioning point may depend on the size of the sub/superscript and exactly where it attaches vertically.
This subtable allows you to specify a list of glyph kerning/height pairs
for each corner of the glyph. Click on the word "Change" above to get a new
dialog. These data may be specified textually:
At any given height a kerning value may be specified. This value is relative
to the default position of the subscript (and I'm not entirely sure what
that is). As always device table adjustments may be specified.
FontForge also allows you to specify these data graphically
FontForge displays bottom right attachments relative to the advance width
line of the glyph
FontForge displays top right attachments relative to the advance width plus
the italic correction.
FontForge displays bottom left attachments relative to the origin of the
glyph.
FontForge displays top left attachments relative to the italic correction.
Note: If you are familiar with the MATH table spec you will recall that the last kern value does not have a height attached to it. FontForge tries to guess a reasonable value for the unspecified height (because it makes editing easier if I let the user move a point around), but have no fears, that guessed at value will never show up in the MATH table itself.
Some glyphs, like parentheses and brackets need to be drawn in many sizes depending on the size of the formula they are enclosing. One possibility is just to draw them at a larger pointsize, but that is non-optimal because then the glyph will be symetrically scaled and so much bolder than it should be. Another solution is to design several variants of these glyphs at steadily increasing sizes. A third solution (which we will come to in the next section) is to design the glyph in sections so that it can be composed at any size.
In this sub-table you may specify a normal sized glyph (here "leftparen") and then a list of variants in increasing sizes.
Glyphs may be grow along either the vertical axis (as here) or the horizontal
axis.
As I said above, it is also possible to build a glyph out of bits of other glyphs.
Each such constructed glyph has (potentially) and Italic Correction (and device table adjustment). This value should be independent of the size of the glyph.
The components are rather difficult to specify in this display, but if you
scroll the dialog to the far right you will find a little rectanglular box,
and clicking on this will produce the dialog below.
Every
component
is either an "Extender" component -- which means it may be stuck in the composed
glyph as often as needed (or not at all) to make the glyph be as big as needed.
Component glyphs may overlap one another. You may specify a maximum overlap for each end of each component. You may also specify how much the component adds to the total height (or width) of the composed glyph.
Finally there is a font-wide constant (in the Connectors pane of the Constants
section) called MinConnectorOverlap which specifies that glyphs must overlap
by at least this amount.
The per-glyph information may also be specified from the
Glyph Information dialog.
I wish to thank Sergey Malkin at MicroSoft who provided me with a copy of the spec, and Apostolos Syropoulos who provided me with a test font containing a 'MATH' table.


acct("/var/log/pacct");
When process accounting is enabled, the kernel writes a record to the accounting file as each process on the system terminates. This record contains information about the terminated process, and is defined in <sys/acct.h> as follows:
#define ACCT_COMM 16 typedef u_int16_t comp_t; struct acct { char ac_flag; /* Accounting flags */ u_int16_t ac_uid; /* Accounting user ID */ u_int16_t ac_gid; /* Accounting group ID */ u_int16_t ac_tty; /* Controlling terminal */ u_int32_t ac_btime; /* Process creation time (seconds since the Epoch) */ comp_t ac_utime; /* User CPU time */ comp_t ac_stime; /* System CPU time */ comp_t ac_etime; /* Elapsed time */ comp_t ac_mem; /* Average memory usage (kB) */ comp_t ac_io; /* Characters transferred (unused) */ comp_t ac_rw; /* Blocks read or written (unused) */ comp_t ac_minflt; /* Minor page faults */ comp_t ac_majflt; /* Major page faults */ comp_t ac_swaps; /* Number of swaps (unused) */ u_int32_t ac_exitcode; /* Process termination status (see wait(2)) */ char ac_comm[ACCT_COMM+1]; /* Command name (basename of last executed command; null-terminated) */ char ac_pad[X]; /* padding bytes */ }; enum { /* Bits that may be set in ac_flag field */ AFORK = 0x01, /* Has executed fork, but no exec */ ASU = 0x02, /* Used superuser privileges */ ACORE = 0x08, /* Dumped core */ AXSIG = 0x10 /* Killed by a signal */ };
The comp_t data type is a floating-point value consisting of a 3-bit, base-8 exponent, and a 13-bit mantissa. A value, c, of this type can be converted to a (long) integer as follows:
v = (c & 0x1fff) << (((c >> 13) & 0x7) * 3);
The ac_utime, ac_stime, and ac_etime fields measure time in "clock ticks"; divide these values by sysconf(_SC_CLK_TCK) to convert them to seconds.
struct acct_v3 { char ac_flag; /* Flags */ char ac_version; /* Always set to ACCT_VERSION (3) */ u_int16_t ac_tty; /* Controlling terminal */ u_int32_t ac_exitcode; /* Process termination status */ u_int32_t ac_uid; /* Real user ID */ u_int32_t ac_gid; /* Real group ID */ u_int32_t ac_pid; /* Process ID */ u_int32_t ac_ppid; /* Parent process ID */ u_int32_t ac_btime; /* Process creation time */ float ac_etime; /* Elapsed time */ comp_t ac_utime; /* User CPU time */ comp_t ac_stime; /* System time */ comp_t ac_mem; /* Average memory usage (kB) */ comp_t ac_io; /* Characters transferred (unused) */ comp_t ac_rw; /* Blocks read or written (unused) */ comp_t ac_minflt; /* Minor page faults */ comp_t ac_majflt; /* Major page faults */ comp_t ac_swaps; /* Number of swaps (unused) */ char ac_comm[ACCT_COMM]; /* Command name */ };
In kernels up to and including 2.6.9, a separate accounting record is written for each thread created using the NPTL threading library; since Linux 2.6.10, a single accounting record is written for the entire process on termination of the last thread in the process.
The proc/sys/kernel/acct file, described in proc(5), defines settings that control the behavior of process accounting when disk space runs low.


Build a report that analyzes the success of promotions. The client would like to measure the "success" of the promotion using two metrics, the Average Sales Quantity Per Day during the promotion, and the Product Quantity Return Ratio.
The client would like two pages in the report, one page for the promotion analysis, and one page to see the product detail breakouts, for any given promotion.
Once you've created a completed report, the next step is to publish the report so the client can view the report, and consume its content online. To demonstrate you're able to publish a completed report, create a dashboard.
Data contains sales information for a fictitious company, Contoso Inc.


QtRpi is a complete bundle to simplify the cross-compilation of Qt applications on the Raspberry Pi. This bundle is composed of:
QtRpi is a completely free and open-source. It relies on the MIT licence. In short, you can do whatever you want.
Everything is hosted on GitHub:
Supported versions of Qt:
Today, the following modules are cross-compiled in the bundle:
QtRpi relies on multiple components:
Right now, we support the following versions of Raspberry Pi:
To use Qtrpi, you need the following:
Right now, Qtrpi has been tested on an Ubuntu system. If you used something else (other Linux distro, macOS, Windows with Bash / Cygwin), please tell us!
QtRpi requires a couple of tasks to be properly installed on both your computer and your Raspberry Pi. To make the installation easier, we created a script to automatically perform all the steps for you. This script, init-qtrpi-minimal.sh, can be found on our QtRpi repository on GitHub.
32-bit linux host is currently not supported
git clone https://github.com/neuronalmotion/qtrpi.git cd qtrpi
The script supports multiple versions of Qt and Raspberry Pi. If you want to install a specific version of QtRpi, set the following environment variables:
| Name | Description | Supported values | Default value |
|---|---|---|---|
| QTRPI_QT_VERSION | The version of the Qt framework |
5.6.2 5.7.0 |
5.7.0 |
| QTRPI_TARGET_DEVICE | The version of the Raspberry Pi board |
linux-rasp-pi-g++ linux-rasp-pi2-g++ linux-rpi3-g++ |
linux-rasp-pi2-g++ |
| QTRPI_TARGET_HOST | The Raspberry Pi SSH host name (usually the IP of your board) | user@ip | None |
Here is an example to configure qtrpi with Qt 5.6.2 on a Raspberry Pi 3 (you can do this in your terminal or add it to your /home/user/.bashrc):
export QTRPI_QT_VERSION='5.6.2' export QTRPI_TARGET_DEVICE='linux-rpi3-g++' export<EMAIL_ADDRESS>The last export QTRPI_TARGET_HOST should contain the IP address of your Raspberry Pi. This variable will be picked later by the deploy-qtrpi.sh script to deploy the Qt binaries.
Once the environment variables are set, execute the following command (from your cloned repository of qtrpi):
./init-qtrpi-minimal.sh
At the end of the execution of the script, you should have a new directory /opt/qtrpi with:
Once your Raspberry Pi is reachable within your network, execute:
./deploy-qtrpi.sh --prepare-rpi
This script will connect to your Raspbery Pi and install / update everything that is needed to run Qt applications.
The script will use sudo several times to install the packages on the board. You should add your SSH key in your Raspberry Pi (using ssh-copy-id for example) or update your /home/user/.netrc to avoid retyping pi's user password.
At the end of the script, your Raspberry Pi should contain the directory /usr/local/qt5pi with the the precompiled Qt for Raspberry Pi.
Add the directory /opt/qtrpi/bin to your PATH.
export PATH=/opt/qtrpi/bin:$PATH # Add this line to your /home/user/.bashrc source ~/.bashrc
Now that QtRpi is installed on your computer and deployed to your Raspberry Pi, you can cross-compile Qt applications. You can do it easily on your project with qmake-qtrpi.
cd myproject /opt/qtrpi/bin/qmake-qtrpi # the full path can be omitted if you added /opt/qtrpi/bin to your PATH make
The generated binary file is ready to be copied and executed on your Raspberry Pi!
We published a video on Youtube to describe the configuration of Qt Creator with QtRpi. With this configuration you will have:
The only step that you have to do before watching the video is to install the multi-architecture debugger (gdb-multiarch):
sudo apt-get install gdb-multiarch
We assume that your QtRpi is already properly installed (on your computer and Raspberry Pi).
This video targets a Raspberry Pi 3, but you can use any supported version of Raspberry Pi (1, 2, 3)
You can fill a contact form from our official website or send us an email at contact |at] neuronalmotion [dot] com.
Our company, NeuronalMotion, works heavily with Qt and in some of our projects, we needed to deploy Qt applications to a Raspberry Pi. Because we are developers and like to be lazy, we decided to store the precompiled Qt dependencies on a website, rather than recompiling them each time.


| Interface | Description |
|---|---|
| StreamObjectVisitor | |
| XMLConstants | |
| XMLOptions |
| Class | Description |
|---|---|
| DefaultErrorHandler |
A simple error handler using the given XMLOptions to determine the desired
behavior when an error is encountered.
|
| DefaultOptions | |
| DocumentMarshaller | Deprecated |
| ErrorLocator | |
| Marshaller |
An data-graph traversal based assembler/builder abstract superclass.
|
| StreamMarshaller |
A Streaming API for XML (StAX) based XML marshaler which converts/writes an
SDO data graph to various supplied (stream-based) XML output sources.
|
| StreamNode | |
| StreamUnmarshaller |
A Streaming API for XML (StAX) parser based XML unmarshaller which converts
various (stream-based) XML input source types into an SDO data graph.
|
| Unmarshaller | |
| XMLProcessor |
| Enum | Description |
|---|---|
| MarshallerFlavor |
Indicates a category or type of marshaler.
|
| UnmarshallerFlavor |
Indicates a category or type of unmarshaller.
|
| Exception | Description |
|---|---|
| DuplicateContainmentReferenceException | |
| InvalidReferenceException | |
| MarshallerException | |
| MarshallerRuntimeException | |
| UnmarshallerException | |
| UnmarshallerRuntimeException |
PlasmaSDO™ and PlasmaQuery™ are trademarks of TerraMeta Software, Inc. Copyright © 2011 - All Rights Reserved.


| {{match.startedAgo}}m ago | {{match.mode}} |
{{player.actor|vgLookup}} ({{player.player}}){{$last ? '' : ', '}} |
VS |
{{player.actor|vgLookup}} ({{player.player}}){{$last ? '' : ', '}} |
Lookup a Match by ID |
|
|
Enter a match id number to gather view prediction results and match insights! |
|
Lookup a Player by ID |
|
|
Enter a player id number to gather view prediction results and match insights! |
|


Print
Guido
Invoice #
0043128641
Invoice date:
03/10/2021
Supplier
Guido LLC.
2301 Ravenswood Rd Madison,
WI 53711
Due date:
03/10/2021
Customer
John Doe.
329 Queensberry Street, North Melbourne VIC
3051, Australia.
Description
Hour
Quantity
Price
Design UX and UI
14
3
$943
Design UX and UI
14
3
$943
Design UX and UI
14
3
$943
Total
$3,750


Our History
Important milestones in the growth of our organization
{% else %}Archive
{% endif %}-
{% include list-posts.html posts=paginator.posts %}
---
title: About @rtifice
layout: default
---
{% if paginator.page == 1 %}
In times of crisis, the wise build bridges while the foolish build barriers. @rtifice is a Woodlawn-based organization that uses project-based, hands-on learning to endow participants with the tech and entrepreneurial skills that will make them the masters of their own destiny. Since 2013, we've worked to combine tech and entrepreneurial competencies in a way that will sustainably raise the economic and educational prospects of the neighborhood and surrounding areas.
Our Mission
The volunteers that make this all possible
Important milestones in the growth of our organization
{% else %}


Deitel
Textbooks
Internet & World Wide Web How to Program, 4/e
Java How to Program, 7/e
Visual Basic 2005 How to Program, 3/e
C# For Programmers, 2/e


{
Fionaz is the world’s leading professional makeup authority because of our unrivalled expertise in makeup ARTISTRY.
Fionaz celebrates diversity and INDIVIDUALITY we are for All Ages, All Races, All Sexes.
Fionaz is a proud COMMUNITY of professional makeup artists working together to bring our vision to life.
Fionaz is at the forefront of fashion TRENDSETTING, collaborating with leading talents from fashion, art and popular culture. Our Artists create trends backstage at fashion weeks around the world.
Fionaz believes in SOCIAL RESPONSIBILITY, with initiatives such as VIVA GLAM and the Fionaz AIDS Fund at the heart and soul of our unique culture
}
All Ages, All Races, All Sexes A professional makeup brand setting trends backstage at fashion weeks around the world. Today, Fionaz means so many things to its millions of fans in every corner of the planet, but a global beauty phenomenon has to begin somewhere.
Make-Up Art Cosmetics started life in Chennai , India. Makeup artist and photographer Tony and salon owner Fiona became frustrated by the lack of makeup that photographed well, so they decided to create their own. At first, they made the cosmetics in their kitchen and sold them straight from the salon to fellow makeup artists, as well as models and photographers. Soon, stylists and fashion editors got in on the action. As the magazine credits racked up and word-of-mouth popularity grew, the duo launched Fionaz in March 1984 from a counter in a Chennai department store.
Their approach was chic utility, with the makeup coming in black pots rather than compacts. While other major makeup brands at the time were predominantly skincare companies, Fionaz chose instead to establish itself as the ultimate colour authority. Professional makeup artists manned the counter, an industry first. One of the most popular offerings was an intense matte red lipstick, which got a boost with an appearance in a photo-shoot of the fast-rising Madonna, later seen wearing a fionaz T-shirt.


--- layout: post title: old Storyboards frame scan date: '2014-02-19T07:31:16+01:00' categories: - Storyboards picture_url: https://film-Storyboards.tumblr.com/post/77171242512/old-Storyboards-frame-scan ---
Old Storyboards frame scan.


Tom Hanks says he first passed on Mister Rogers role
by Wade SheridanNov. 19 (UPI) -- Tom Hanks said on Today Tuesday that he originally passed on portraying Mister Rogers in A Beautiful Day in the Neighborhood until he was convinced to take on the role by director Marielle Heller.
"She told me that she was not interested in any kind of editorial comment on who Mister Rogers was nor did she want an imitation of Mister Rogers' physicality or presentation," Hanks told Today's Savannah Guthrie.
"She said essentially you will get a wig and we'll do something with your eyebrows and all the rest is gonna be up to you," the actor continued about Heller.
Hanks also discussed how the late Mister Rogers connected with children through his beloved series, Mister Rogers' Neighborhood.
"It's not for us. It's not for grown-ups who know how the world works," he said. "It's for children who are looking to be invested in by somebody who cares about them."
The 63-year-old said that he spoke with Rogers' widow Joanne Rogers who explained what her husband might have done today amid a divisive world.
"'He would just be, the best person he could. Just be, good,'" Hanks said of what Joanne Rogers mentioned.
A Beautiful Day in the Neighborhood is set to hit theaters on Friday.


Highcharts 데모
라인 차트
Basic line
With data labels
With annotations
Time series, zoomable
Spline with plot bands
Line chart with 500k points
영역 차트
Basic area
Area with negative values
Stacked area
Percentage area
Area range
Area range and line
컬럼 차트 / 바 차트
Basic bar
Stacked bar
Bar with negative stack
Basic column
Column with negative values
Stacked and grouped column
Column with rotated labels
Fixed placement columns
Column range
파이 차트
Pie chart
Pie with legend
Donut chart
Semi circle donut
Pie with drilldown
Variable radius pie
스캐터 차트 / 버블 차트
Scatter plot
Scatter plot with 1 million points
Bubble chart
3D bubbles
Packed bubble chart
Split Packed bubble chart
접근성 차트
Accessible line chart
Accessible pie chart
Advanced accessible chart
3D 차트
3D column
3D cylinder
3D funnel
3D column with stacking and grouping
3D donut
3D scatter chart
게이지 차트
Gauge series
Solid gauge
Bullet graph
히트맵 / 트리맵
Heat map
Tree map with color axis
Tree map with levels


Welcome to Fablab Singapore Polytechnic!
We are the first Fablab in Singapore and is part of the global Fab Academy movement. We are an established training center for the Global Fab Academy diploma.
Fablab Singapore Polytechnic is located in 3 areas:
Our fab labs are fully equipped with 3D Printers, Laser Cutters, 2D Routers, Flatbed Cutters, 3-axis Milling machines, Vacuum Formers, Electric and Manual hand-tools.
We are also capable of SMD PCB production and host a variety of Electronic Workbenches for production and trouble-shooting of embedded controllers.
We have experienced, well-trained and capable personnel who can offer you great advice on how to complete your projects.
We offer you the opportunity to come and Make something, be it small-or-large! You will have opportunities to learn and share your knowledge with like-minded people.
You can take courses, book equipment, share ideas with the International as well as local Fab Lab Community.
Come and visit us now!


"CONCISION "(Gr. katatome; i.e., “mutilation”), a term used by Paul contemptuously of those who were zealots for circumcision (Phil. 3:2). Instead of the warning, “Beware of the circumcision” (peritome) i.e., of the party who pressed on Gentile converts the necessity of still observing that ordinance, he says, “Beware of the concision;” as much as to say, “This circumcision which they vaunt of is in Christ only as the gashings and mutilations of idolatrous heathen.”
"CONCISION "(Gr. katatome; i.e., “mutilation”), a term used by Paul contemptuously of those who were zealots for circumcision (Phil. 3:2).
Instead of the warning, “Beware of the circumcision” (peritome) i.e., of the party who pressed on Gentile converts the necessity of still observing that ordinance, he says, “Beware of the concision;” as much as to say, “This circumcision which they vaunt of is in Christ only as the gashings and mutilations of idolatrous heathen.”


|
Graphitti
A toolkit/software architecture to ease creating high-performance neural network simulators
|
Public Member Functions | |
| AllNeuroEdges (const int numVertices, const int maxEdges) | |
| virtual void | setupEdges () override |
| Setup the internal structure of the class (allocate memories and initialize them). | |
| virtual void | resetEdge (const BGSIZE iEdg, const BGFLOAT deltaT) |
| int | edgSign (const edgeType type) |
| virtual void | printSynapsesProps () const |
| Prints SynapsesProps data to console. | |
| Public Member Functions inherited from AllEdges | |
| AllEdges (const int numVertices, const int maxEdges) | |
| virtual void | loadParameters () |
| virtual void | printParameters () const |
| virtual void | addEdge (BGSIZE &iEdg, edgeType type, const int srcVertex, const int destVertex, BGFLOAT *sumPoint, const BGFLOAT deltaT) |
| virtual void | createEdge (const BGSIZE iEdg, int srcVertex, int destVertex, BGFLOAT *sumPoint, const BGFLOAT deltaT, edgeType type)=0 |
| virtual EdgeIndexMap * | createEdgeIndexMap () |
| Create a edge index map. | |
| template<class Archive > | |
| void | save (Archive &archive) const |
| template<class Archive > | |
| void | load (Archive &archive) |
| virtual void | advanceEdges (IAllVertices *vertices, EdgeIndexMap *edgeIndexMap) |
| virtual void | advanceEdge (const BGSIZE iEdg, IAllVertices *vertices)=0 |
| virtual void | eraseEdge (const int neuronIndex, const BGSIZE iEdg) |
Public Attributes | |
| BGFLOAT * | psr_ |
| is going on in the edge. More... | |
| Public Attributes inherited from AllEdges | |
| int * | sourceVertexIndex_ |
| The location of the edge. | |
| int * | destVertexIndex_ |
| The coordinates of the summation point. | |
| BGFLOAT * | W_ |
| The weight (scaling factor, strength, maximal amplitude) of the edge. | |
| BGFLOAT ** | summationPoint_ |
| This edge's summation point's address. | |
| edgeType * | type_ |
| Synapse type. | |
| bool * | inUse_ |
| The boolean value indicating the entry in the array is in use. | |
| BGSIZE * | edgeCounts_ |
| BGSIZE | totalEdgeCount_ |
| The total number of active edges. | |
| BGSIZE | maxEdgesPerVertex_ |
| The maximum number of edges for each vertex. | |
| int | countVertices_ |
Static Public Attributes | |
| static constexpr BGFLOAT | SYNAPSE_STRENGTH_ADJUSTMENT = 1.0e-8 |
| The factor to adjust overlapping area to edge weight. | |
Protected Member Functions | |
| virtual void | setupEdges (const int numVertices, const int maxEdges) override |
| Setup the internal structure of the class (allocate memories and initialize them). More... | |
| virtual void | readEdge (istream &input, const BGSIZE iEdg) override |
| virtual void | writeEdge (ostream &output, const BGSIZE iEdg) const override |
| Protected Member Functions inherited from AllEdges | |
| edgeType | edgeOrdinalToType (const int typeOrdinal) |
Additional Inherited Members | |
| Protected Attributes inherited from AllEdges | |
| log4cplus::Logger | fileLogger_ |
| Loggers used to print to using log4cplus logging macros, prints to Results/Debug/logging.txt. | |
| log4cplus::Logger | edgeLogger_ |
Definition at line 41 of file AllNeuroEdges.h.
| int AllNeuroEdges::edgSign | ( | const edgeType | type | ) |
Get the sign of the edgeType.
| type | edgeType I to I, I to E, E to I, or E to E |
Definition at line 93 of file AllNeuroEdges.cpp.
|
overrideprotectedvirtual |
Sets the data for Synapse to input's data.
| input | istream to read from. |
| iEdg | Index of the edge to set. |
Reimplemented from AllEdges.
Reimplemented in AllSTDPSynapses, AllSpikingSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 56 of file AllNeuroEdges.cpp.
|
virtual |
Reset time varying state vars and recompute decay.
| iEdg | Index of the edge to set. |
| deltaT | Inner simulation step duration |
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, AllDSSynapses, and AllSpikingSynapses.
Definition at line 48 of file AllNeuroEdges.cpp.
|
overrideprotectedvirtual |
Setup the internal structure of the class (allocate memories and initialize them).
Setup the internal structure of the class (allocate memories and initialize them).
| numVertices | Total number of vertices in the network. |
| maxEdges | Maximum number of edges per vertex. |
Reimplemented from AllEdges.
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, AllDSSynapses, and AllSpikingSynapses.
Definition at line 34 of file AllNeuroEdges.cpp.
|
overrideprotectedvirtual |
Write the edge data to the stream.
| output | stream to print out to. |
| iEdg | Index of the edge to print out. |
Reimplemented from AllEdges.
Reimplemented in AllSTDPSynapses, AllSpikingSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 80 of file AllNeuroEdges.cpp.
| BGFLOAT* AllNeuroEdges::psr_ |
is going on in the edge.
The post-synaptic response is the result of whatever computation
Definition at line 102 of file AllNeuroEdges.h.


Regression Plots¶
from __future__ import print_function
from statsmodels.compat import lzip
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import statsmodels.api as sm
from statsmodels.formula.api import ols
Duncan's Prestige Dataset¶
Load the Data¶
We can use a utility function to load any R dataset available from the great Rdatasets package.
prestige = sm.datasets.get_rdataset("Duncan", "car", cache=True).data
prestige.head()
prestige_model = ols("prestige ~ income + education", data=prestige).fit()
print(prestige_model.summary())
Influence plots¶
Influence plots show the (externally) studentized residuals vs. the leverage of each observation as measured by the hat matrix.
Externally studentized residuals are residuals that are scaled by their standard deviation where
$$var(\hat{\epsilon}_i)=\hat{\sigma}^2_i(1-h_{ii})$$with
$$\hat{\sigma}^2_i=\frac{1}{n - p - 1 \;\;}\sum_{j}^{n}\;\;\;\forall \;\;\; j \neq i$$$n$ is the number of observations and $p$ is the number of regressors. $h_{ii}$ is the $i$-th diagonal element of the hat matrix
$$H=X(X^{\;\prime}X)^{-1}X^{\;\prime}$$The influence of each point can be visualized by the criterion keyword argument. Options are Cook's distance and DFFITS, two measures of influence.
fig, ax = plt.subplots(figsize=(12,8))
fig = sm.graphics.influence_plot(prestige_model, ax=ax, criterion="cooks")
As you can see there are a few worrisome observations. Both contractor and reporter have low leverage but a large residual.
RR.engineer has small residual and large leverage. Conductor and minister have both high leverage and large residuals, and,
therefore, large influence.
Partial Regression Plots¶
Since we are doing multivariate regressions, we cannot just look at individual bivariate plots to discern relationships.
Instead, we want to look at the relationship of the dependent variable and independent variables conditional on the other
independent variables. We can do this through using partial regression plots, otherwise known as added variable plots.
In a partial regression plot, to discern the relationship between the response variable and the $k$-th variabe, we compute
the residuals by regressing the response variable versus the independent variables excluding $X_k$. We can denote this by
$X_{\sim k}$. We then compute the residuals by regressing $X_k$ on $X_{\sim k}$. The partial regression plot is the plot
of the former versus the latter residuals.
The notable points of this plot are that the fitted line has slope $\beta_k$ and intercept zero. The residuals of this plot
are the same as those of the least squares fit of the original model with full $X$. You can discern the effects of the
individual data values on the estimation of a coefficient easily. If obs_labels is True, then these points are annotated
with their observation label. You can also see the violation of underlying assumptions such as homooskedasticity and
linearity.
fig, ax = plt.subplots(figsize=(12,8))
fig = sm.graphics.plot_partregress("prestige", "income", ["income", "education"], data=prestige, ax=ax)
fix, ax = plt.subplots(figsize=(12,14))
fig = sm.graphics.plot_partregress("prestige", "income", ["education"], data=prestige, ax=ax)
As you can see the partial regression plot confirms the influence of conductor, minister, and RR.engineer on the partial relationship between income and prestige. The cases greatly decrease the effect of income on prestige. Dropping these cases confirms this.
subset = ~prestige.index.isin(["conductor", "RR.engineer", "minister"])
prestige_model2 = ols("prestige ~ income + education", data=prestige, subset=subset).fit()
print(prestige_model2.summary())
For a quick check of all the regressors, you can use plot_partregress_grid. These plots will not label the
points, but you can use them to identify problems and then use plot_partregress to get more information.
fig = plt.figure(figsize=(12,8))
fig = sm.graphics.plot_partregress_grid(prestige_model, fig=fig)
Component-Component plus Residual (CCPR) Plots¶
The CCPR plot provides a way to judge the effect of one regressor on the
response variable by taking into account the effects of the other
independent variables. The partial residuals plot is defined as
$\text{Residuals} + B_iX_i \text{ }\text{ }$ versus $X_i$. The component adds $B_iX_i$ versus
$X_i$ to show where the fitted line would lie. Care should be taken if $X_i$
is highly correlated with any of the other independent variables. If this
is the case, the variance evident in the plot will be an underestimate of
the true variance.
fig, ax = plt.subplots(figsize=(12, 8))
fig = sm.graphics.plot_ccpr(prestige_model, "education", ax=ax)
As you can see the relationship between the variation in prestige explained by education conditional on income seems to be linear, though you can see there are some observations that are exerting considerable influence on the relationship. We can quickly look at more than one variable by using plot_ccpr_grid.
fig = plt.figure(figsize=(12, 8))
fig = sm.graphics.plot_ccpr_grid(prestige_model, fig=fig)
Regression Plots¶
The plot_regress_exog function is a convenience function that gives a 2x2 plot containing the dependent variable and fitted values with confidence intervals vs. the independent variable chosen, the residuals of the model vs. the chosen independent variable, a partial regression plot, and a CCPR plot. This function can be used for quickly checking modeling assumptions with respect to a single regressor.
fig = plt.figure(figsize=(12,8))
fig = sm.graphics.plot_regress_exog(prestige_model, "education", fig=fig)
Fit Plot¶
The plot_fit function plots the fitted values versus a chosen independent variable. It includes prediction confidence intervals and optionally plots the true dependent variable.
fig, ax = plt.subplots(figsize=(12, 8))
fig = sm.graphics.plot_fit(prestige_model, "education", ax=ax)
Statewide Crime 2009 Dataset¶
Compare the following to http://www.ats.ucla.edu/stat/stata/webbooks/reg/chapter4/statareg_self_assessment_answers4.htm
Though the data here is not the same as in that example. You could run that example by uncommenting the necessary cells below.
#dta = pd.read_csv("http://www.stat.ufl.edu/~aa/social/csv_files/statewide-crime-2.csv")
#dta = dta.set_index("State", inplace=True).dropna()
#dta.rename(columns={"VR" : "crime",
# "MR" : "murder",
# "M" : "pctmetro",
# "W" : "pctwhite",
# "H" : "pcths",
# "P" : "poverty",
# "S" : "single"
# }, inplace=True)
#
#crime_model = ols("murder ~ pctmetro + poverty + pcths + single", data=dta).fit()
dta = sm.datasets.statecrime.load_pandas().data
crime_model = ols("murder ~ urban + poverty + hs_grad + single", data=dta).fit()
print(crime_model.summary())
Partial Regression Plots¶
fig = plt.figure(figsize=(12,8))
fig = sm.graphics.plot_partregress_grid(crime_model, fig=fig)
fig, ax = plt.subplots(figsize=(12,8))
fig = sm.graphics.plot_partregress("murder", "hs_grad", ["urban", "poverty", "single"], ax=ax, data=dta)
Leverage-Resid2 Plot¶
Closely related to the influence_plot is the leverage-resid2 plot.
fig, ax = plt.subplots(figsize=(8,6))
fig = sm.graphics.plot_leverage_resid2(crime_model, ax=ax)
Influence Plot¶
fig, ax = plt.subplots(figsize=(8,6))
fig = sm.graphics.influence_plot(crime_model, ax=ax)
Using robust regression to correct for outliers.¶
Part of the problem here in recreating the Stata results is that M-estimators are not robust to leverage points. MM-estimators should do better with this examples.
from statsmodels.formula.api import rlm
rob_crime_model = rlm("murder ~ urban + poverty + hs_grad + single", data=dta,
M=sm.robust.norms.TukeyBiweight(3)).fit(conv="weights")
print(rob_crime_model.summary())
#rob_crime_model = rlm("murder ~ pctmetro + poverty + pcths + single", data=dta, M=sm.robust.norms.TukeyBiweight()).fit(conv="weights")
#print(rob_crime_model.summary())
There isn't yet an influence diagnostics method as part of RLM, but we can recreate them. (This depends on the status of issue #888)
weights = rob_crime_model.weights
idx = weights > 0
X = rob_crime_model.model.exog[idx.values]
ww = weights[idx] / weights[idx].mean()
hat_matrix_diag = ww*(X*np.linalg.pinv(X).T).sum(1)
resid = rob_crime_model.resid
resid2 = resid**2
resid2 /= resid2.sum()
nobs = int(idx.sum())
hm = hat_matrix_diag.mean()
rm = resid2.mean()
from statsmodels.graphics import utils
fig, ax = plt.subplots(figsize=(12,8))
ax.plot(resid2[idx], hat_matrix_diag, 'o')
ax = utils.annotate_axes(range(nobs), labels=rob_crime_model.model.data.row_labels[idx],
points=lzip(resid2[idx], hat_matrix_diag), offset_points=[(-5,5)]*nobs,
size="large", ax=ax)
ax.set_xlabel("resid2")
ax.set_ylabel("leverage")
ylim = ax.get_ylim()
ax.vlines(rm, *ylim)
xlim = ax.get_xlim()
ax.hlines(hm, *xlim)
ax.margins(0,0)


A perfect number is equal to the sum of its divisors; eg
6 = 1 + 2 + 3,
28 = 1 + 2 + 4 + 7 + 14
Not many perfect numbers are known, because they become very big very soon. But there is a formula for generating some of them, known since Euclid’s time: add together a series of powers of 2 until you get a prime number, and then multiply by the last power of two you used.
eg, 20 + 21 + 22 = 1 + 2 + 4 = 7, which is prime; multiply by 4 to get 28, which is perfect.
All the known perfect number are even.


First Bootrap Page
第一列
Learn for doing what we want
再牛逼的梦想，也抵不住你傻逼似的坚持
第二列
Learn for doing what we want
再牛逼的梦想，也抵不住你傻逼似的坚持
第三列
Learn for doing what we want
再牛逼的梦想，也抵不住你傻逼似的坚持
第一列
Learn for doing what we want
再牛逼的梦想，也抵不住你傻逼似的坚持