| varTable {lavaan} | R Documentation |
Summary information about the variables included in either a data.frame, or a fitted lavaan object.
varTable(object, ov.names = names(object), ov.names.x = NULL, ordered = NULL, factor = NULL, as.data.frame. = TRUE)
object |
Either a data.frame, or an object of class
|
ov.names |
Only used if object is a data.frame. A character vector containing the variables that need to be summarized. |
ov.names.x |
Only used if object is a data.frame. A character vector containing additional variables that need to be summarized. |
ordered |
Character vector. Which variables should be treated as ordered factors |
factor |
Character vector. Which variables should be treated as (unordered) factors? |
as.data.frame. |
If TRUE, return the list as a data.frame. |
A list
or data.frame
containing summary information about
variables in a data.frame. If object
is a fitted lavaan object,
it displays the summary information about the observed variables that are
included in the model. The summary information includes
variable type (numeric, ordered, ...), the number of non-missing values,
the mean and variance for numeric variables, the number of levels of
ordered variables, and the labels for ordered variables.
HS.model <- ' visual =~ x1 + x2 + x3 textual =~ x4 + x5 + x6 speed =~ x7 + x8 + x9 ' fit <- cfa(HS.model, data=HolzingerSwineford1939) varTable(fit)


{% extends 'base.html' %} {% block content %} {% load widget_tweaks %}
| # | Task | Deliverable | Resources |
|---|---|---|---|
| 1 | Do a thing | Some deliverable | List of km content or something |
| 2 | Do a thing | Some deliverable | List of km content or something |
| 2 | Do a thing | Some deliverable | List of km content or something |
| 3 | Do a thing | Some deliverable | List of km content or something |
| 4 | Do a thing | Some deliverable | List of km content or something |


Create a new game
Join an existing game
Play with computer
Choose side
Choose mode
All following games play for one chosen side
After the end of each game be able to change the side
Player
Tie
Bot
0
0
0
New game
Reset
Leave
Resign


ZIP: 225 Title: Version 5 Transaction Format Owners: Daira Emma Hopwood<EMAIL_ADDRESS>Jack Grigg<EMAIL_ADDRESS>Sean Bowe<EMAIL_ADDRESS>Kris Nuttycombe<EMAIL_ADDRESS>Ying Tong Lai<EMAIL_ADDRESS>Status: Final Category: Consensus Created: 2021-02-28 License: MIT Discussions-To: <https://github.com/zcash/zips/issues/440>
The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. 1
The character § is used when referring to sections of the Zcash Protocol Specification 2.
This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol 2. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.
This ZIP also depends upon and defines modifications to the computation of the values TxId Digest, Signature Digest, and Authorizing Data Commitment defined by ZIP 244 7.
The new Orchard shielded pool requires serialized data elements that are distinct from any previous Zcash transaction. In addition, with the activation of ZIP 244, the serialized transaction format will no longer be consensus-critical. It makes sense at this point to define a format that can readily accommodate future extension in a systematic fashion, where elements required for support for a given pool are kept separate.
The new format must fully support the Orchard protocol.
The new format should lend itself to future extension or pruning to add or remove value pools.
The computation of the non-malleable transaction identifier hash must include all newly incorporated elements except those that attest to transaction validity.
The computation of the commitment to authorizing data for a transaction must include all newly incorporated elements that attest to transaction validity.
More general forms of extensibility, such as definining a key/value format that allows for parsers that are unaware of some components, are not required.
All fields in this specification are encoded as little-endian.
The Zcash transaction format for transaction version 5 is as follows:
| Bytes | Name | Data Type | Description |
|---|---|---|---|
| Common Transaction Fields | |||
4 |
header |
uint32 |
|
4 |
nVersionGroupId |
uint32 |
Version group ID (nonzero). |
4 |
nConsensusBranchId |
uint32 |
Consensus branch ID (nonzero). |
4 |
lock_time |
uint32 |
Unix-epoch UTC time or block height, encoded as in Bitcoin. |
4 |
nExpiryHeight |
uint32 |
A block height in the range {1 .. 499999999} after which the transaction will expire, or 0 to disable expiry. [ZIP-203] |
| Transparent Transaction Fields | |||
varies |
tx_in_count |
compactSize |
Number of transparent inputs in tx_in . |
varies |
tx_in |
tx_in |
Transparent inputs, encoded as in Bitcoin. |
varies |
tx_out_count |
compactSize |
Number of transparent outputs in tx_out . |
varies |
tx_out |
tx_out |
Transparent outputs, encoded as in Bitcoin. |
| Sapling Transaction Fields | |||
varies |
nSpendsSapling |
compactSize |
Number of Sapling Spend descriptions in vSpendsSapling . |
96 * nSpendsSapling |
vSpendsSapling |
SpendDescriptionV5[nSpendsSapling] |
A sequence of Sapling Spend descriptions, encoded per protocol §7.3 ‘Spend Description Encoding and Consensus’. |
varies |
nOutputsSapling |
compactSize |
Number of Sapling Output Decriptions in vOutputsSapling . |
756 * nOutputsSapling |
vOutputsSapling |
OutputDescriptionV5[nOutputsSapling] |
A sequence of Sapling Output descriptions, encoded per protocol §7.4 ‘Output Description Encoding and Consensus’. |
8 |
valueBalanceSapling |
int64 |
The net value of Sapling Spends minus Outputs |
32 |
anchorSapling |
byte[32] |
A root of the Sapling note commitment tree at some block height in the past. |
192 * nSpendsSapling |
vSpendProofsSapling |
byte[192 * nSpendsSapling] |
Encodings of the zk-SNARK proofs for each Sapling Spend. |
64 * nSpendsSapling |
vSpendAuthSigsSapling |
byte[64 * nSpendsSapling] |
Authorizing signatures for each Sapling Spend. |
192 * nOutputsSapling |
vOutputProofsSapling |
byte[192 * nOutputsSapling] |
Encodings of the zk-SNARK proofs for each Sapling Output. |
64 |
bindingSigSapling |
byte[64] |
A Sapling binding signature on the SIGHASH transaction hash. |
| Orchard Transaction Fields | |||
varies |
nActionsOrchard |
compactSize |
The number of Orchard Action descriptions in vActionsOrchard . |
820 * nActionsOrchard |
vActionsOrchard |
OrchardAction[nActionsOrchard] |
A sequence of Orchard Action descriptions, encoded per §7.5 ‘Action Description Encoding and Consensus’. |
1 |
flagsOrchard |
byte |
|
8 |
valueBalanceOrchard |
int64 |
The net value of Orchard spends minus outputs. |
32 |
anchorOrchard |
byte[32] |
A root of the Orchard note commitment tree at some block height in the past. |
varies |
sizeProofsOrchard |
compactSize |
Length in bytes of proofsOrchard . Value is
\(2720 + 2272 \cdot \mathtt{nActionsOrchard}\)
. |
sizeProofsOrchard |
proofsOrchard |
byte[sizeProofsOrchard] |
Encoding of aggregated zk-SNARK proofs for Orchard Actions. |
64 * nActionsOrchard |
vSpendAuthSigsOrchard |
byte[64 * nActionsOrchard] |
Authorizing signatures for each Orchard Action. |
64 |
bindingSigOrchard |
byte[64] |
An Orchard binding signature on the SIGHASH transaction hash. |
valueBalanceSapling
and bindingSigSapling
are present if and only if
\(\mathtt{nSpendsSapling} + \mathtt{nOutputsSapling} > 0\)
. If valueBalanceSapling
is not present, then
\(\mathsf{v^{balanceSapling}}`\)
is defined to be 0.anchorSapling
is present if and only if
\(\mathtt{nSpendsSapling} > 0\)
.flagsOrchard
, valueBalanceOrchard
, anchorOrchard
, sizeProofsOrchard
, proofsOrchard
, and bindingSigOrchard
are present if and only if
\(\mathtt{nActionsOrchard} > 0\)
. If valueBalanceOrchard
is not present, then
\(\mathsf{v^{balanceOrchard}}\)
is defined to be 0.vSpendProofsSapling
and vSpendAuthSigsSapling
have a 1:1 correspondence to the elements of vSpendsSapling
and MUST be ordered such that the proof or signature at a given index corresponds to the SpendDescriptionV5
at the same index.vOutputProofsSapling
have a 1:1 correspondence to the elements of vOutputsSapling
and MUST be ordered such that the proof at a given index corresponds to the OutputDescriptionV5
at the same index.proofsOrchard
, and the elements of vSpendAuthSigsOrchard
, each have a 1:1 correspondence to the elements of vActionsOrchard
and MUST be ordered such that the proof or signature at a given index corresponds to the OrchardAction
at the same index.enableSpendsOrchard
bit MUST be set to 0
.The encodings of tx_in
, and tx_out
are as in a version 4 transaction (i.e. unchanged from Canopy). The encodings of SpendDescriptionV5
, OutputDescriptionV5
and OrchardAction
are described below. The encoding of Sapling Spends and Outputs has changed relative to prior versions in order to better separate data that describe the effects of the transaction from the proofs of and commitments to those effects, and for symmetry with this separation in the Orchard-related parts of the transaction format.
SpendDescriptionV5
) | Bytes | Name | Data Type | Description |
|---|---|---|---|
32 |
cv |
byte[32] |
A value commitment to the net value of the input note. |
32 |
nullifier |
byte[32] |
The nullifier of the input note. |
32 |
rk |
byte[32] |
The randomized validating key for the element of spendAuthSigsSapling corresponding to this Spend. |
The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification 3.
OutputDescriptionV5
) | Bytes | Name | Data Type | Description |
|---|---|---|---|
32 |
cv |
byte[32] |
A value commitment to the net value of the output note. |
32 |
cmu |
byte[32] |
The u-coordinate of the note commitment for the output note. |
32 |
ephemeralKey |
byte[32] |
An encoding of an ephemeral Jubjub public key. |
580 |
encCiphertext |
byte[580] |
The encrypted contents of the note plaintext. |
80 |
outCiphertext |
byte[80] |
The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key. |
The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification 4.
OrchardAction
) | Bytes | Name | Data Type | Description |
|---|---|---|---|
32 |
cv |
byte[32] |
A value commitment to the net value of the input note minus the output note. |
32 |
nullifier |
byte[32] |
The nullifier of the input note. |
32 |
rk |
byte[32] |
The randomized validating key for the element of spendAuthSigsOrchard corresponding to this Action. |
32 |
cmx |
byte[32] |
The x-coordinate of the note commitment for the output note. |
32 |
ephemeralKey |
byte[32] |
An encoding of an ephemeral Pallas public key |
580 |
encCiphertext |
byte[580] |
The encrypted contents of the note plaintext. |
80 |
outCiphertext |
byte[80] |
The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key. |
The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification 5.
The original version of ZIP-225 included Sprout-related fields nJoinSplit
, vJoinSplit
, joinSplitPubKey
, and joinSplitSig
in the V5 transaction format. The Electric Coin Company and Zcash Foundation teams have elected to remove these fields from the V5 transaction format as part of the continuing process of deprecation of the Sprout shielded pool. As a consequence of these fields being removed:
Removing these fields reduces the complexity of the NU5 upgrade in the following ways:
Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 6 extension or by other means not yet determined.
The original definitions for the transaction fields that have been removed are:
| Sprout Transaction Fields | |||
varies |
nJoinSplit |
compactSize |
The number of JoinSplit descriptions in vJoinSplit . |
1698 * nJoinSplit |
vJoinSplit |
JSDescriptionGroth16[nJoinSplit] |
A sequence of JoinSplit descrptions using Groth16 proofs, encoded per §7.2 ‘JoinSplit Description Encoding and Consensus’. |
32 |
joinSplitPubKey |
byte[32] |
An encoding of a JoinSplitSig public validating key. |
64 |
joinSplitSig |
byte[64] |
A signature on a prefix of the transaction encoding, to be verfied using joinSplitPubKey as specified in §4.11 ‘Non-malleability (Sprout)’. |
joinSplitPubKey
and joinSplitSig
fields were specified to be present if and only if
\(\mathtt{nJoinSplit} > 0\)
.| 1 | RFC 2119: Key words for use in RFCs to Indicate Requirement Levels |
|---|
| 2 | Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] |
|---|
| 3 | Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions |
|---|
| 4 | Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions |
|---|
| 5 | Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.6: Action Descriptions |
|---|
| 6 | ZIP 222: Transparent Zcash Extensions |
|---|
| 7 | ZIP 244: Transaction Identifier Non-Malleability |
|---|
| 8 | ZIP 307: Light Client Protocol for Payment Detection |
|---|


NEWS.md
A new vignette show use of TileDB array via RMariaDB and the MyTile extension to MariaDB (#221)
Matrices can now be returned directly from suitable two-dimensional TileDB arrays (#225)
More data types are supported in the non-empty domain accessor function (#229)
The DESCRIPTION, README.md and pkgdown site were updated (#230)
Creation of TileDB arrays from data.frame object has been made more robust (#238)
On startup, versions numbers of the R package and the TileDB Embedded library are displayed (#239)
The pkgdown website now shows the ChangeLog derived from this NEWS file (#240)
Two tests with datetime comparisons which fail only on one macOS system are now conditional (#216)
Result sets with all-character column now fall back to estimated result sizes (#217)
Setup of support for duplicate values in sparse arrays has been corrected (#223)
Error messages concerning an array types and selection mismatch are now clearer (#224)
Writes from data.frame objects to dense array revert back to column-major order (#226)
Tests of sparse writes to dense matrices now use UNORDERED layout (#228)
Data.frame returns of selected columns now coversion dimensions as well (#231)
Schema creation has been generalized and made more robust (#232)
Selection of dimension ranges now maps date and datetime values correctly (#233, #241)
Selection and setting of dimension ranges has been generalized and made more robust (#235, #236)
The older implementations tiledb_dense
and tiledb_sparse
are now marked as deprecated in favor of tiledb_array
. No removal date is set or planned yet, but it is recommended to migrate to new code. (#180)
Updated the underlying TileDB library to use TileDB 2.1.2 on macOS and Linux (when no system library is found) (#181)
There is extended support for array creation directly from DataFrame objects. (#182)
Internal TileDB performance statistics can now be exported ‘raw’ in JSON format (for TileDB versions greater than 2.0.3). (#183, #186)
The vignette was updated with respect to the preferred used of tiledb_array
. (#184)
The Hilbert cell layout added recently to TileDB Embbeded is supported. (#185)
Virtual File System functions now use the default VFS object which allows for a simpler interface (#187)
TileDB Array Dimension support has been extended to more data types (#188)
Datetime support for Dimensions and Attributes has been extended (#189)
The API coverage has been increased alongside an update of the documentation (#190)
The Array schema can now be accessed and printed directly from a URI (#191)
The accessor for the estimated array result size was updated with the updaded API (#192)
Initial Arrow support for importing and exporting vector has been added (#193, #199)
Support for the default TileDB Embedded library was set to 2.1.3 and 2.1.4 (#194, #195)
The package documentation was updated and extended (#196)
Support for ‘time-traveling’ access to arrays was extended (#197)
Support for the default TileDB Embedded library was set to 2.1.5 and 2.1.6 (#198, #200)
Support for the default TileDB Embedded library was set to 2.2.0 and 2.2.1 (#201, #202)
The vignettes were updated and extended (#203)
The fromDataFrame()
function was extended (#204)
Some unit tests were conditioned on having TileDB Embedded 2.1.0 or later (#205)
Support for the default TileDB Embedded library was set to 2.2.2 and 2.2.3 (#206, #208)
The default TileDB Embedded library version is now set centrally (#207)
Support was added to write and read sparse matrices directly via higher-level functions (#209)
Arrow array and schema allocation and deallocation helper functions were added (#210)
Support for Nullable vectors has been added (#211)
Support for the default TileDB Embedded library has been set to 2.2.4 (#212)
Small tweaks to timezone and factor settings in unit tests, and vignette (#213, #214, #215)
The tiledb_stats_reset()
function is now exported, and tiledb_stats_print()
has been re-added as a wrapper to tiledb_stats_dump()
(#174)
Configuration options for compute and input/output concurrency set only the new TileDB 2.1 configuration options; documentation on how to checking values has been expanded. (#175)
The download.file()
use now (re-)sets the timeout to the standard value to accomodate uses where a lower value may be set such as some CRAN builders (#176)
Build scripts have been updated for use of TileDB 2.1.1 on Windows, macOS and Linux (when no system library is found) (#178)
A new function limitTileDBCores()
controls resource use, it is being used in tests (#139)
The function tiledb_get_context()
is now exported (#140)
A new S4 class tiledb_vfs
provides access to the virtual file system functionality (#140)
Functionality of selected_ranges()
was extended (#142)
More (signed and unsigned) integer types are supported as dimension types in sparse arrays (#143), as well as in dense arrays (#144) and as attributes (#144)
A new S4 class tiledb_query
offers access to the query object functionality in the underlying library (#145, #161)
Examples are running with a lowered thread count setting per CRAN Policies (#152)
External pointer objects now use explicitly set finalizers (#149)
Users can explicitly select a TileDB Embedded shared library built to be used (#151)
Compile-time configuration was refactored and changes (#158)
Windows builds are now possible also using TileDB Embedded build 2.0.8 (#159, #164)
Continuous integration now uses Azure for macOS and Linux (#160) and GitHub Actions for Windows (#162,#165)
Range selection for tiledb_array objects can get/set matrices defining range (#132)
The show
methods are now consistently exported and documented (#134)
TileDB is listed as copyright owner in DESCRIPTION as well (#134)
The selected_ranges
method for tiledb_array
types was improved, and more tests were added (#135)
C++ source code was rearranged slightly with respect to possible API deprecations in the libary (#136)
A very simple example for using TileDB Cloud from R was added (#136)
The helper scripts for the package build are now in the tools/
directory (#137)
The (optional) library download now relied on suggested R packages ‘jsonlite’ and ‘curl’ (#137)
All S4 classes are now consistently documented or aliased (#117)
If needed, the build system now builds TileDB and its required component (#118)
Data.frame support has been extended further and made more robust (#119, #123, #128)
The Description: in DESCRIPTION
has been refreshed (#120)
Builds on Linux and macOS can use a pre-built TileDB library (#121, #122, #124, #127)
Copyright headers were added to source files (#125)
The pkg-config helper can be used when building from source (#126)
Added support for heterogenous domains
Added support for string dimensions
Added support for duplicate dimension values in sparse arrays
Added support for data.frame object import and conversion to dense and sparse arrays
Added enhanced support for data.frame returns from dense array
Added support for data.frame column selection (i.e. attributes) from dense array
Added support for new filter types for md5 and sha256 checksums
Added support for Date, Datetime (i.e. POSIXct) and nanosecond dense and sparse array attributes and domains
Documentation and examples were enhanced and extended
tiledb_stats_dump()
is now simpler (but needs to be enabled first as usual)
Support for nanosecond and integer64 columns was added, this is an optional feature for which the nanotime (and bit64) packages need to be installed


Protocols
The following protocols are available globally.
-
Classes that implement this protocol should represent possible actions that can be passed to a reducer.
Ideally, an app should define an enum for this purpose, so that it can pass data as enum arguments.
Declaration
Swift
public protocol ReduxActionType
-
Represents an object that provides an action dispatcher.
See moreDeclaration
Swift
public protocol ReduxDispatcherProviderType
-
This represents a Redux store that can dispatch actions to mutate internal state and broadcast state updates to subscribers.
See moreDeclaration
Swift
public protocol ReduxStoreType : ReduxDispatcherProviderType, ReduxUnsubscriberProviderType
-
Represents an object that has a unique ID.
See moreDeclaration
Swift
public protocol UniqueIDProviderType
-
Represents a job that can await for its result.
See moreDeclaration
Swift
public protocol AwaitableType
-
Provides an state unsubscribe function.
See moreDeclaration
Swift
public protocol ReduxUnsubscriberProviderType
-
Implement this protocol to represent a navigatable screen. Usually we would use an enum such as the following:
enum Screen: RouterScreenType { case login case dashboard }
Declaration
Swift
public protocol RouterScreenType : ReduxActionType
-
Implement this protocol to handle in-app navigations. We can pass in the top navigation controller and, depending on the screen, go to the page associated with that screen or replace the whole stack:
See moreenum Screen: RouterScreenType { case login case dashboard } struct NavigationRouter: ReduxRouterType { private let controller: UINavigationController init(_ controller: UINavigationController) { self.controller = controller } func navigate(_ screen: Screen) { switch screen { case .login: // Go to login screen using nav controller. case .dashboard: // Go to dashboard screen using nav controller. } } }
Declaration
Swift
public protocol ReduxRouterType
-
Similar to a normal Redux router, but allows navigation method to return a Bool value to indicate whether it succeeds.
See moreDeclaration
Swift
public protocol VetoableReduxRouterType : UniqueIDProviderType
-
Implement this protocol to convert to an effect instance.
See moreDeclaration
Swift
public protocol SagaEffectConvertibleType
-
Implement this protocol to represent a Redux saga effect.
See moreDeclaration
Swift
public protocol SagaEffectType : SagaEffectConvertibleType
-
Represents a saga effect that will emit only one event, and thus can be awaited for the result.
Declaration
Swift
public protocol SingleSagaEffectType : SagaEffectType
-
Monitors all Saga outputs and call each stored output’s action dispatcher every time an action arrives. This is the only way to notify all output action dispatchers, no matter how nested it is.
See moreDeclaration
Swift
public protocol SagaMonitorType : ReduxDispatcherProviderType
-
Middleware provider that can be used to wrap a base store.
See moreDeclaration
Swift
public protocol MiddlewareProviderType
-
Represents an object that can run some operation on the main thread.
See moreDeclaration
Swift
public protocol MainThreadRunnerType
-
A view that conforms to this protocol can receive state/action props and subscribe to state changes.
See moreDeclaration
Swift
public protocol PropContainerType : AnyObject, UniqueIDProviderType
-
Inject views with state/action props, similar to how React.js performs connect.
See moreDeclaration
Swift
public protocol PropInjectorType
-
Prop mapper that maps state/dispatch to Redux props. Redux props include StateProps (information to populate the UI) and ActionProps (set of actions to handle UI interactions).
The methods defined here are static because we want to restrict usage of internal state as much as possible. We should only use whatever data that are passed in via parameters to create props (e.g. state, outProps).
See moreDeclaration
Swift
public protocol PropMapperType : AnyObject


{% if include.alt_body %}{{include.alt_body}}{% else %}Be part of the movement to repair our republic.{% endif %}
We respect your privacy. Your phone number will not be shared with outside parties. Note: If submitting your cell number, you are certifying that this cell phone number belongs to you and granting Mayday PAC and its contracted phone vendors permission to call you at this cell phone number during legal calling hours. Message & data rates may apply.


With the nomination of Brett Kavanaugh to the Supreme Court, Chief Justice John Roberts is likely to be the median justice. How has the ideology of the median justice and chief justice shifted over time?
Data sources: Andrew D. Martin and Kevin M. Quinn, Lee Epstein
Tools:
With so much discussion of the ideological changes in the Supreme Court, I wanted to visualize the court's historical ideological shifts. In researching the topic and methods of measurement, I saw mostly line charts of individual justices over time. I wanted to do something different and make it easier to track changes in the median justice and chief justice - the two court members most important to its overall ideology.
Using R, I imported the Martin-Quinn data set, which assigns a score to each justice for each term, and the Supreme Court Database, which provides additional information on justices' term dates and successors. After some analysis, I charted the data using a color scale to indicate ideology score and a marker for the chief justice.
I imported the R chart into Illustrator, decided on a vertical orientation, and added the annotations. To add more context, I plotted the chief and median justice scores for the longer chief justice terms in the same color scale. Finally, given the data, I framed the story to focus on the overwhelmingly conservative ideology in the measured history.


User Management
The User Management component of the WSO2 Carbon facilitates the management
and control of user accounts and user roles at different levels. The key
functionalities of this component include:
- Add, modify or remove user accounts
- Add, modify or remove user roles
Managing User Roles
Use the Roles page to add new user roles, modify
existing roles, or delete existing roles.
Figure 1: Roles Management
- In the navigator, under Configure, click Users and Roles
. The User Management
page appears.
- Click on Roles in the System User Store
panel. The Roles page appears.
- Click Add New Role on the
Roles page.
- Enter the role name.
- Click Next.
Figure 2: Add user role
- In step 2, select the permissions you want to assign to the role. Please refer to the
Role Permissions guide for details on permissions.
Figure 3: Add permission to user role
Note:
- If you connect to an external user store (like LDAP) in read only mode, you can read existing roles from it
but you can not edit/delete the roles.
-
In this case, you can still create new roles which will be managed internally and which are editable.
- If you connect to the external user store in read/write mode, you can edit the roles in external user store as well.


dA Message Notifier
Credits
Author:
Alexander "Xan" Kashev, aka logeg
Original idea and inspiration:
deviantAnywhere for Firefox
and its author PostaL2600
Valuable testing/ideas,
in alphabetical order:
CSS:
Options and release notes page: clairejones
Credits page: Craig Buckler
Code libraries:


{% extends 'event_layout.html' %} {% block event_content %}
FallFest 1.16 is a modding event that will run from Thursday, October 1st thru Thursday, October 15th, 2020. Like all ModFest modding events, FallFest is a great excuse to try something new, practice your modding abilities, get starting on a new mod you've been thinking about, or any other reason to make a mod.
ModFest regularly runs modding events for each major Minecraft version, but 'MiniFest' events are slightly different. While the main ModFest modding events are open enough to allow essentially any mod in that follows the rules, MiniFest events require you to meet additional criteria, usually revolving around a specific theme. This time around, the theme is Fall/Halloween.
FallFest will be much more display-oriented than previous ModFest events. The showcase server will have the theme of a fall/Halloween festival, and players can participate in fun minigames, events, and battles, while finding collectibles, hanging out, and getting lost in mazes. While ModFest's end goal has always been about creating more mods, we would ask that for this one, you also consider how your mod could be used to make the FallFest showcase server a fun place to play on. Consider mechanics for minigames and other things that players could interact with when on the server.
ModFest awards are just for fun and ModFest is not a highly competitive event. The ultimate goal of the event is simple: to make mods and have a good time doing it. If you stress about the awards the whole time, you probably won't have as much fun.
Unlike past ModFest events, we aren't doing sign ups! Just make your mod within the time and submit it at the end via our Discord server (more instructions on how that works will come later, make sure to join our Discord server for updates).
Also, definitely come check out our Discord server if you want to see previews of the mods people are working on or are just curious about ModFest in general. Feel free to chat, lurk, ask questions, or participate in FallFest 1.16.
{% endblock %}


Peter Rabbit and Other Stories
by Beatrix Potter
“The Tale of Two Bad Mice”
Additional Information
- Year Published: 0
- Language: English
- Country of Origin: England
- Source: Beatrix Potter, The Great Big Treasury of Beatrix Potter
-
Readability:
- Flesch–Kincaid Level: 5.0
- Word Count: 948
- Genre: Fantasy
- ✎ Cite This
Downloads
Once upon a time there was a very beautiful doll’s-house; it was red brick with white windows, and it had real muslin curtains and a front door and a chimney.
It belonged to two dolls called Lucinda and Jane; at least it belonged to Lucinda, but she never ordered meals.
Jane was the Cook; but she never did any cooking, because the dinner had been bought ready-made, in a box full of shavings.
There were two red lobsters and a ham, a fish, a pudding, and some pears and oranges.
They would not come off the plates, but they were extremely beautiful.
One morning Lucinda and Jane had gone out for a drive in the doll’s perambulator. There was no one in the nursery, and it was very quiet. Presently there was a little scuffling, scratching noise in a corner near the fireplace, where there was a hole under the skirting-board.
Tom Thumb put out his head for a moment, and then popped it in again. Tom Thumb was a mouse.
A minute afterwards, Hunca Munca, his wife, put her head out, too; and when she saw that there was no one in the nursery, she ventured out on the oilcloth under the coal-box.
The doll’s-house stood at the other side of the fire-place. Tom Thumb and Hunca Munca went cautiously across the hearthrug. They pushed the front door—it was not fast.
Tom Thumb and Hunca Munca went upstairs and peeped into the dining-room. Then they squeaked with joy!
Such a lovely dinner was laid out upon the table! There were tin spoons, and lead knives and forks, and two dolly-chairs—all SO convenient!
Tom Thumb set to work at once to carve the ham. It was a beautiful shiny yellow, streaked with red.
The knife crumpled up and hurt him; he put his finger in his mouth.
“It is not boiled enough; it is hard. You have a try, Hunca Munca.”
Hunca Munca stood up in her chair, and chopped at the ham with another lead knife.
“It’s as hard as the hams at the cheesemonger’s,” said Hunca Munca.
The ham broke off the plate with a jerk, and rolled under the table.
“Let it alone,” said Tom Thumb; “give me some fish, Hunca Munca!”
Hunca Munca tried every tin spoon in turn; the fish was glued to the dish.
Then Tom Thumb lost his temper. He put the ham in the middle of the floor, and hit it with the tongs and with the shovel—bang, bang, smash, smash!
The ham flew all into pieces, for underneath the shiny paint it was made of nothing but plaster!
Then there was no end to the rage and disappointment of Tom Thumb and Hunca Munca. They broke up the pudding, the lobsters, the pears and the oranges.
As the fish would not come off the plate, they put it into the red-hot crinkly paper fire in the kitchen; but it would not burn either.
Tom Thumb went up the kitchen chimney and looked out at the top— there was no soot.
While Tom Thumb was up the chimney, Hunca Munca had another disappointment. She found some tiny canisters upon the dresser, labeled— Rice—Coffee—Sago—but when she turned them upside down, there was nothing inside except red and blue beads.
Then those mice set to work to do all the mischief they could—especially Tom Thumb! He took Jane’s clothes out of the chest of drawers in her bedroom, and he threw them out of the top floor window.
But Hunca Munca had a frugal mind. After pulling half the feathers out of Lucinda’s bolster, she remembered that she herself was in want of a feather bed.
With Tom Thumbs’s assistance she carried the bolster downstairs, and across the hearth-rug. It was difficult to squeeze the bolster into the mouse-hole; but they managed it somehow.
Then Hunca Munca went back and fetched a chair, a book-case, a bird-cage, and several small odds and ends. The book-case and the bird-cage refused to go into the mousehole.
Hunca Munca left them behind the coal-box, and went to fetch a cradle.
Hunca Munca was just returning with another chair, when suddenly there was a noise of talking outside upon the landing. The mice rushed back to their hole, and the dolls came into the nursery.
 Lucinda sat upon the upset kitchen stove and stared; and Jane leant against the kitchen dresser and smiled—but neither of them made any remark.
The book-case and the bird-cage were rescued from under the coal-box—but Hunca Munca has got the cradle, and some of Lucinda’s clothes.
She also has some useful pots and pans, and several other things.
The little girl that the doll’s-house belonged to, said,—“I will get a doll dressed like a policeman!”
But the nurse said,—“I will set a mouse-trap!”
So that is the story of the two Bad Mice,—but they were not so very very naughty after all, because Tom Thumb paid for everything he broke.
He found a crooked sixpence under the hearth-rug; and upon Christmas Eve, he and Hunca Munca stuffed it into one of the stockings of Lucinda and Jane.
And very early every morning— before anybody is awake—Hunca Munca comes with her dust-pan and her broom to sweep the dollies’ house!


BlogCafe
Dashboard
Posts
Categories
Users
Welcome Manish
Profile
Settings
Logout
Categories
Search
Latest Categories
#
Title
Data Posted
1
Web Development
Feb 27, 2018
2
Web Tech Gadgets
Feb 27, 2018
3
Health & Wellness
Feb 28, 2018
4
Travel
Mar 1, 2018
5
Entertainment
Mar 2, 2018
Previous
1
2
3
Next


Abstract: There is a subset of Joy in which quotations contain at most one element and nesting of quotations is not allowed. For every Joy program there is a corresponding program in this subset, and when the corresponding program is executed, the original is restored. A translation from full Joy to the subset can be written in full Joy (and, if one wanted to, also in the subset itself).
In most high level programming languages programs contain nested structures, typically in conditionals and loops. Nested structures also arise in data as in nested arrays or nested lists. Concatenative languages such as Forth, Joy, Slava Pestov's Factor, and Stevan Apters's cK and XY are no exception. But nesting interrupts the concatenative semantics: a concatenative program must treat a quotation, a contained nested program, as an indivisible unit, but when the quotation is executed by a combinator, its concatenative semantics unfolds. In the "concatenative" mailing group Billy Tanksley raised the question whether it would be possible to design a concatenative language without nesting, a flat concatenative language.
The written representation of programs in any language consists of a sequencce of symbols which themselves are sequences of characters. The characters are collected by a scanner or tokeniser to form symbols, and the symbols are examined by a parser to form a syntax tree and by the compiler to form a program which typically is nested. Note that the sequence of symbbols is not nested, but it contains some special symbols such as brackets and IF, THEN, WHILE.. . These symbols direct the compiler to buils the nested structures. So one can think of the sequencce of symbols as a program that is executed by the compiler and produces an internal nested structure. Surprisingly the sequence of symbols constitutes a flat concatenative language. The compiler computes a function, and so does the interpreter. Hence the composition of the compiler and the interpreter is an interpreter for a flat concatenative language.
Stevan Apter has adopted this principle in his web page http://www/nsl.com/k/xy/xy.htm. There he uses his concatenative language XY to write a proof-of-concept implementation for a flat concatenative language. The XY language uses a stack X, like all concatenative languages, but also a queue Y. It so happens that this arrangement is suitable implementing a flat concatenative language. Essentially it works by compiling the flat input language to form quotations prior to every execution. So the compilation is done by the XY interpreter, and the result is then again interpreted by XY. The alternative solution offered in the remainder of this note borrows some of these ideas. Instead of a queue Y an ordinary Joy list is used. The flat input language is actually a subset of Joy.
Let Floy ("FLat jOY") be that subet of Joy in which quotations are not allowed to contain more than one atom. This means that [] [3] [dup] [*] and [map] are allowed, but [[]] [1 2 3] [[3]] [dup *] and [[map]] are not. The aim of this note is to demonstrate the following theorem about Joy:
For every Joy program J there is a Floy program F which constructs the quotation [J] of the Joy program J: F => [J] and hence F i == [J] i == JThe proof uses a technique commonly used in the theory of computability: One shows that there is a translation function T such that T(J) = F. The translation function is computable, so the proof is constructive. The translation could be computed by a program in any Turing complete language.
Joy is Turing complete, so the translation function from Joy to Floy can be written in Joy itself. Let j2f be a Joy program which takes the quotation [J] of a Joy program J as a parameter and produces the quotation [F] of the corresponding Floy program F. Note that the quotation [F] itself will in general not be a Floy program. The translation program j2f must satisy:
[J] j2f == [F] and hence [J] j2f i == [F] i == [J] and [J] j2f i i == [F] i i == [J] i == JFrom the second line above [J] j2f i == [J] and hence j2f i == id. So j2f is the left inverse of i, and i is the right inverse of j2f.
The quotation [F] of the Floy program F, when executed by i, has to reconstruct the quotation [J] of the Joy program J, including all internal quotations of J which may b nested. There are two ways in which these quotations can be constructed by F. Both must begin with the empty quotation []. Then, in the forward direcction, start with the first, second .. item and append them in that order to the quotation so far. Alternatively, in the reverse direction, start with the last, second-last .. item and prepend them in that order to the quotation so far. Since there are two ways in which a Floy program could operate, there are in fact two possible Floy programs corresponding to a given Joy program. And, for sheer perversity, a Floy program could use a mixture of these two strategies. But such mixtures wil not be further considered here. The forward or backward versions can be constructed by two different Joy-to-Floy programs, j2f-forwards and j2f-reverse. Both Joy-to-Floy programs traverse the original Joy quotation [J] and any of its internal quotations in the forward direction. Both start building [F] as an empty quotation []. Then j2f-forwards starts at the first, second .. item of [J] or its internal quotation to build [F] in the forward direction, so that when [F] is ever executed by the i combinator, it will reconstruct [J] in the forward direction. On the other hand, j2f-reverse also starts at the first, second .. item to build [F] in the reverse direction, so that when [F] is ever executed by i, it will reconstruct [J] in the reverse direction. Is your head spinning yet? So was mine when writing the code.
The remainder of this note consists of the separately commented output flatjoy.out from running flatjoy.joy. The first definitions define four quoted Joy programs that will later be used to test the two Joy-to-Floy translators. The first is the program that does nothing, the second contains some actual code without nesting, the third has two occurrances of one level of nesting, and the fourth has two occurrances of two levels.
DEFINE P0 == []; # empty code P1 == [2 3 + dup *]; # non-empty code P2 == [[1 2 3] [dup *] map]; # nest data & code P3 == [ [[1 2][3 4][5] []] [[dup *] map] map ]. # double nesting
Next comes the definition of j2f-forwards and its subsidiaries. The forward version [F] has to use a lot of concatenation, so the first definition abbreviates concat to c. The second definition is for j2f-f, a recursive operator, the real workhorse. If the item to be translated is a list, then do some preparation, step recursively through the list, and then do some finalisation. The preparation consists of appending an empty list to what has been constructed so far, and the finalisation consists of appending code which, when executed by i, will append the unit list of the reconstructed list to the partially reconstructed [J]. On the other hand, if the item is not a list, but an atom foo, build code and append code which, when executed by i, will append foo to the partially reconstructed [J]. The final definition is for j2f-forwards, which must provide an empty starting list [] and then step through [J] by calling j2f-f.
DEFINE c == concat; j2f-f == [ list ] [ [[[]] concat] dip [j2f-f] step [[] cons c] concat ] [ [] cons [c] cons concat ] ifte; j2f-forwards == [[]] swap [j2f-f] step.
The following are the tests. For each of P0..P3, we see the original quoted Joy program [J], then its translation [F] by j2f-forwards, then the result of executing this by the i combinator to yield the original [J]. For each of P1..P3 we also see the result of executing this by a further i combinator. In [F], remember that c is short for concat.
P0 . [] P0 j2f-forwards . [[]] P0 j2f-forwards i . [] P1 . [2 3 + dup *] P1 j2f-forwards . [[] [2] c [3] c [+] c [dup] c [*] c] P1 j2f-forwards i . [2 3 + dup *] P1 j2f-forwards i i . 25 P2 . [[1 2 3] [dup *] map] P2 j2f-forwards . [[] [] [1] c [2] c [3] c [] cons c [] [dup] c [*] c [] cons c [map] c] P2 j2f-forwards i . [[1 2 3] [dup *] map] P2 j2f-forwards i i . [1 4 9] P3 . [[[1 2] [3 4] [5] []] [[dup *] map] map] P3 j2f-forwards . [[] [] [] [1] c [2] c [] cons c [] [3] c [4] c [] cons c [] [5] c [] cons c [] [] cons c [] cons c [] [] [dup] c [*] c [] cons c [map] c [] cons c [map] c] P3 j2f-forwards i . [[[1 2] [3 4] [5] []] [[dup *] map] map] P3 j2f-forwards i i . [[1 4] [9 16] [25] []]
The Floy programs so constructed are almost readable, and with some practice one might even learn to write that way - if one really had to. But there is something else that is unsatisfactory. On inspecting the code for j2f-f and the translations that it produces, we see that both use a lot of concatenations: j2f-f uses concat directly, and the translations use the abbreviation c, which will be executed when the translation is executed by the i combinator. In both cases the concatenation serves to append a quite short list to another list which might already be quite long. But that means that the other longer list has to be copied entirely to have the short list as its new tail. This is inefficient, and a better solution would be to work the other way, so that a short list is prepended rather than appended.
The following definition for translator j2f-reverse addresses the problem. From a given Joy program [J] it constructs in reverse an equivalent Floy program [F] which when executed by the i combinator reconstructs in reverse the original Joy program [J]. Instead of c for concat, define s for swoncat, to be used inside the translation [F]. The workhorse is j2f-r. If the item is a list do some preparation, recursively step through the list and then do some finalisation. Finalisation consists in prepending [] to the [F] built so far, it will be the starting point when the completed [F] is executed by i. Preparation consists in prepending to [F] code which when executed i will prepend the constructed quotation to the partially rebuilt [J]. If the item is not a list but say foo, construct and prepend code which when executed by i, will prepend foo. The final j2f-reverse has to provide an inital empty list [] and after stepping through [J] prepend another empty list to that.
DEFINE s == swoncat; j2f-r == [ list ] [ [[swons] swoncat] dip [j2f-r] step [] swons ] [ [] cons [s] cons swoncat ] ifte; j2f-reverse == [] swap [j2f-r] step [] swons.
The tests for j2f-reverse are the same as for j2f-forwards: Show [J], then translate to yield [F] , then i the translation to reconstruct [J], and where appropriate, i the reconstruction.
P0 . [] P0 j2f-reverse . [[]] P0 j2f-reverse i . [] P1 . [2 3 + dup *] P1 j2f-reverse . [[] [*] s [dup] s [+] s [3] s [2] s] P1 j2f-reverse i . [2 3 + dup *] P1 j2f-reverse i i . 25 P2 . [[1 2 3] [dup *] map] P2 j2f-reverse . [[] [map] s [] [*] s [dup] s swons [] [3] s [2] s [1] s swons] P2 j2f-reverse i . [[1 2 3] [dup *] map] P2 j2f-reverse i i . [1 4 9] P3 . [[[1 2] [3 4] [5] []] [[dup *] map] map] P3 j2f-reverse . [[] [map] s [] [map] s [] [*] s [dup] s swons swons [] [] swons [] [5] s swons [] [4] s [3] s swons [] [2] s [1] s swons swons] P3 j2f-reverse i . [[[1 2] [3 4] [5] []] [[dup *] map] map] P3 j2f-reverse i i . [[1 4] [9 16] [25] []]As may be seen, the reverse Floy programs are much harder to read and write when one's mindset is for postfix notation. Finally, I could not resist flattening the already flattened:
# Double flattening - an exercise in Joy obfuscation: P3 j2f-forwards j2f-reverse .  [[] [] [] [1] c [2] c [] cons c [] [3] c [4] c [] cons c [] [5] c [] cons c [] [] cons c [] cons c [] [] [dup] c [*] c [] cons c [map] c [] cons c [map] c] # full de-obfuscation - again by Joy: P3 j2f-forwards j2f-reverse i i . gc - 191 nodes inspected, 126 nodes copied, clock: 1 [[[1 2] [3 4] [5] []] [[dup *] map] map] # final run of de-obfuscated original: P3 j2f-forwards j2f-reverse i i i . [[1 4] [9 16] [25] []]
This ends the output file flatjoy.out from running the source file flatjoy.joy. The definitions of the two translators j2f-forwards and j2f-backwards have been added in slightly modified form to the Joy library for symbolic manipulation, symlib.joy.
Here again is the theorem already mentioned at the beginning:
For every Joy program J there is a Floy program F which constructs the quotation [J] of the Joy program J: F => [J] and hence F i == [J] i == JThe proof is by induction on the structure of the Joy program J, using either of the two Joy-to-Floy translators just shown. A informal version of the proof is as follows: The base case is for the quoted empty program []; the two tests for P0 have demonstrated the correctness of the translators. For the induction on the length of the program without any internal quotations, the two tests for P1 have demonstrated the correctness. For the induction on the depth of nested quotations, the two tests for each of P2 and P3 demonstrate the correctness. A more formal proof would need to proceed by analysing the actual code for the translators and even of the implementation of Joy, but this is outside the scope of this note.
The translations into the two versions of Floy contain many occurrances of unitlists of the form [foo], each followed by a c (for concat) in the forward version, or by a s (for swoncat) in the reverse version. It might be thought that unitlists already break the ideal of flatness. For Joy as it is, there seems to be no other solution. But the syntax of Joy could be extended by adding unary operators in prefix notation. Two kinds of solutions suggest themselves:
Writing say Q for one such operator, Q foo would be the same as [foo]. Then for the forward and reverse versions of Floy one might write Q foo concat, or Q foo swoncat. Then one might combine the quoting operator with the concat or swoncat in two other unary operators C or S, and then writing C foo, or S foo.
The other kind of solution would introduce an operator F, so that F foo would be the same as [foo] first, with the effect of pushing foo onto the stack. Then concat or swoncat would have to be replaced by append and prepend, possibly by combined unary operators A and P, and then writing A foo, or P foo.
Similar unary operators have been suggested before in different contexts for different purposes. But such a major addition to the syntax does not sit so well with the ideal of simple concatenativity, and no such addition is currently planned for Joy. However, it may so turn out that compelling arguments for additional syntax will emerge in the future.


PWD
menu
home
Home
business
About Us
web
Contact Us
person
Log In
person
Admin Log In
person
Log out
home
Home
business
About Us
contact_phone
Contact Us
person
Log In
person
Admin Log In
person
Logout
Enter your Employee Id
account_circle
Emp_id
fingerprint
password
Login
Welcome to the employee section
enter attendance
logout


TDReplicator Class Reference
| Inherits from | NSObject |
| Declared in | TDReplicator.h |
Tasks
Other Methods
-
+ progressChangedNotification
-
+ stoppedNotification
-
– initWithDB:remote:push:continuous:
-
db
property -
remote
property -
isPush
property -
continuous
property -
filterName
property -
filterParameters
property -
options
property -
requestHeaders
Optional dictionary of headers to be added to all requests to remote servers.
property -
authorizer
property -
– start
Starts the replicator.
Replicators run asynchronously so nothing will happen until later. A replicator can only be started once; don't reuse it after it stops.
-
– stop
Request to stop the replicator.
Any pending asynchronous operations will be canceled. TDReplicatorStoppedNotification will be posted when it finally stops.
-
running
Is the replicator running? (Observable)
property -
online
Is the replicator able to connect to the remote host?
property -
active
Is the replicator actively sending/receiving revisions? (Observable)
property -
error
Latest error encountered while replicating.
propertyThis is set to nil when starting. It may also be set to nil by the client if desired. Not all errors are fatal; if .running is still true, the replicator will retry.
-
sessionID
A unique-per-process string identifying this replicator instance.
property -
changesProcessed
Number of changes (docs or other metadata) transferred so far.
property -
changesTotal
Approximate total number of changes to transfer.
propertyThis is only an estimate and its value will change during replication. It starts at zero and returns to zero when replication stops.
-
activeRequestsStatus
JSON-compatible array of status info about active remote HTTP requests.
property
Extension Methods
-
lastSequence
property -
– maybeCreateRemoteDB
-
– beginReplicating
-
– addToInbox:
-
– addRevsToInbox:
-
– processInbox:
-
– sendAsyncRequest:path:body:onCompletion:
-
– addRemoteRequest:
-
– removeRemoteRequest:
-
– asyncTaskStarted
-
– asyncTasksFinished:
-
– stopped
-
– databaseClosing
-
– revisionFailed
-
– retry
-
– reachabilityChanged:
-
– goOffline
-
– goOnline
-
savingCheckpoint
property
Properties
active
Is the replicator actively sending/receiving revisions? (Observable)
@property (readonly, nonatomic) BOOL active
Discussion
Is the replicator actively sending/receiving revisions? (Observable)
Declared In
TDReplicator.h
changesProcessed
Number of changes (docs or other metadata) transferred so far.
@property (readonly, nonatomic) NSUInteger changesProcessed
Discussion
Number of changes (docs or other metadata) transferred so far.
Declared In
TDReplicator.h
changesTotal
Approximate total number of changes to transfer.
This is only an estimate and its value will change during replication. It starts at zero and returns to zero when replication stops.
@property (readonly, nonatomic) NSUInteger changesTotal
Discussion
Approximate total number of changes to transfer.
This is only an estimate and its value will change during replication. It starts at zero and returns to zero when replication stops.
Declared In
TDReplicator.h
error
Latest error encountered while replicating.
This is set to nil when starting. It may also be set to nil by the client if desired.
Not all errors are fatal; if .running is still true, the replicator will retry.
@property (retain, nonatomic) NSError *error
Discussion
Latest error encountered while replicating.
This is set to nil when starting. It may also be set to nil by the client if desired.
Not all errors are fatal; if .running is still true, the replicator will retry.
Declared In
TDReplicator.h
online
Is the replicator able to connect to the remote host?
@property (readonly, nonatomic) BOOL online
Discussion
Is the replicator able to connect to the remote host?
Declared In
TDReplicator.h
requestHeaders
Optional dictionary of headers to be added to all requests to remote servers.
@property (copy) NSDictionary *requestHeaders
Discussion
Optional dictionary of headers to be added to all requests to remote servers.
Declared In
TDReplicator.h
Instance Methods
initWithDB:remote:push:continuous:
- (id)initWithDB:(TDDatabase *)db remote:(NSURL *)remote push:(BOOL)push continuous:(BOOL)continuous
sendAsyncRequest:path:body:onCompletion:
- (TDRemoteJSONRequest *)sendAsyncRequest:(NSString *)method path:(NSString *)relativePath body:(id)body onCompletion:(TDRemoteRequestCompletionBlock)onCompletion
start
Starts the replicator.
Replicators run asynchronously so nothing will happen until later.
A replicator can only be started once; don't reuse it after it stops.
- (void)start
Discussion
Starts the replicator.
Replicators run asynchronously so nothing will happen until later.
A replicator can only be started once; don't reuse it after it stops.
Declared In
TDReplicator.h
stop
Request to stop the replicator.
Any pending asynchronous operations will be canceled.
TDReplicatorStoppedNotification will be posted when it finally stops.
- (void)stop
Discussion
Request to stop the replicator.
Any pending asynchronous operations will be canceled.
TDReplicatorStoppedNotification will be posted when it finally stops.
Declared In
TDReplicator.h


University Of Nairobi Suspends Self-sponsored Programmes Management In Restructuring Move
by Mercy AumaThe University of Nairobi (UoN) has suspended the Centre for self sponsored programmes (CESSP), the body that manages self-sponsored programmes in the institution.
All staff in the CESSP departments will be re-deployed to the mainstream services with duties aligned to their training.
In a statement signed by the University chairperson Prof Julia Ojiambo, the office of the university council stated that they had arrived at the conclusion following a consultative meeting that was held on November 19, 2018.
Banking facilities in the CESSP departments will be operated by the University’s duly authorized signatories.
Other activities and programs under CESSP will be designated to other competent university organs.
Read: UoN To Scrap These 40 Courses In Varsity Reforms
“The council resolved that CESSP is revoked immediately with staff under it redeployed to other mainstream services in accordance to training. Banking facilities shall until further notice be operated by the Council’s duly authorized signatories….all activities under CESSP shall be re-designated to other competent university organs,” read the statement.
The university says that the changes will not interfere with the University program under any circumstances, with reassurance that services would be discharged seamlessly.


All you have to do to get started is pick your cold ones of choice and play a drinking game!


We apologize, our site isn't quite done yet.If you would like to get an email when our site is done,
please let us know by submitting your
information below.
If you would not like to share your name, fill out the form with Potential Customer as your first and last name.


Top Recipes
| Sweet Potato and Chickpea Curry | |
|---|---|
| You can whip up this easy chickpea curry with just a few store cupboard staples - perfect for a laid-back supper. This is designed to be a low cost recipe |
| Wild Mushroom and Sweetcorn Biryani Parcels | |
|---|---|
| Biryani with Wild mushrooms and sweetcorns blended in a Parcel |
| Karara Aloo Chaat | |
|---|---|
| Chaat masala is the spice mix that gives that characteristic zing to Indian snacks. Here it’s used to flavour crisp fried potatoes with a quick homemade chutney and a yogurt foam. |
| Wonton Baskets | |
|---|---|
| Filled with lemon Chantilly, raspberries and raspberry coulis |
| Onion Masala Sauce | |
|---|---|
| Want to give your curries real depth of flavour? Try this versatile masala sauce. The secret to the rich taste is cooking the onions slowly until they are very dark. Add pan-fried chicken, meat, prawns or vegetables for a delicious quick curry. |


read_gardasil.Rd
Title Read Gardasil data from csv file
read_gardasil(other.as.NA = FALSE)
| other.as.NA | If FALSE (default), unknown/other race is treated as its own category. If TRUE, treat unknown/other race as NA. |
|---|
Cleaned/formatted data.frame. This data.frame could be documented here as its codebook, but such documentation is demonstrated under the prepared `gardasil` dataset (see `?gardasil`)
The other.as.NA option is provided because the original manuscript was unclear about how other/unknown race was treated. Reproducing the reported results requires this parameter to be FALSE, but its coefficients are not reported.
#> Age AgeGroup Race Shots Completed #> Min. :11.00 18-26:712 white :732 Min. :1.000 no :944 #> 1st Qu.:15.00 11-17:701 black :443 1st Qu.:1.000 yes:469 #> Median :18.00 hispanic : 52 Median :2.000 #> Mean :18.55 other/unknown:186 Mean :2.069 #> 3rd Qu.:22.00 3rd Qu.:3.000 #> Max. :26.00 Max. :3.000 #> InsuranceType MedAssist Location #> medical assistance:275 yes: 275 Odenton :798 #> private payer :723 no :1138 White Marsh :165 #> hospital based : 84 Johns Hopkins Outpatient Center: 89 #> military :331 Bayview :361 #> #> #> LocationType PracticeType RaceSummary #> urban :450 pediatric :515 white :732 #> suburban:963 family practice:365 minority:495 #> OB-GYN :533 NA's :186 #> #> #>


§134-13 Revocation of permits. All permits and licenses provided for under this part may be revoked, for good cause, by the issuing authority or by the judge of any court. [L 1988, c 275, pt of §2]


Remove MGNL System properties...
This action allows you to select mgnl and jcr system properties and remove those in any YML file.


--- layout: post title: Profiling CSS for fun and profit popular: popular tags: - css ---
I’ve been recently working on optimizing performance of a so-called one-page web app. The application was highly dynamic, interactive, and was heavily stuffed with new CSS3 goodness. I’m not talking just border-radius and gradients. It was a full stack of shadows, gradients, transforms, sprinkled with transitions, smooth half-transparent colors, clever pseudo-element -based CSS tricks, and experimental CSS features.
Aside from looking into bottlenecks on Javascript/DOM side, I decided to step into the CSS land. I wanted to see the kind of impact these nice UI elements have on performance. The old version of the app — the one without all the fluff — was much snappier, even though the JS logic behind it hasn’t changed all that drastically. I could see by scrolling and animations that things are just not as quick as they should be.
Was styling to blame?
Fortunately, just few days before, Opera folks came out with an experimental “style profiler” (followed by WebKit’s ticket+patch shortly after). The profiler was meant to reveal the performance of CSS selector matching, document reflow, repaint, and even document and css parsing times.
Perfect!
I wasn’t thrilled about profiling in one environment, and optimizing according to one engine (especially the engine that’s used only in one browser), but decided to give it a try. After all, the offending styles/rules would probably be similar in all engines/browsers. And this was pretty much the only thing out there.
The only other somewhat similar tool was WebKit’s “timeline” tab in Developer Tools. But timeline wasn’t very friendly to work with. It wouldn’t show total time of reflow/repaint/selector matching, and the only way to extract that information was by exporting data as json and parsing it manually (I’ll get to that later).
Below are some of my observations from profiling using both WebKit and Opera tools. TL;DR version is at the end.
Before we start, I’d like to mention that most (if not all) of these notes apply best to large, complex applications. Documents that have thousands of elements and that are highly interactive will benefit the most. In my case, I reduced page load time by ~650ms (~500ms (!) on style recalculation alone, ~100ms on repaint, and ~50ms on reflow). The application became noticeably snappier, especially in older browsers like IE7.
For simpler pages/apps, there are plenty of other optimizations that should be looked into first.
The fastest rule is the one that doesn’t exist. There’s a common strategy to combine stylesheet “modules” into one file for production. This makes for one big collection of rules, where some (lots) of them are likely not used by particular part of the site/application. Getting rid of unused rules is one of the best things your can do to optimize CSS performance, as there’s less matching to be done in the first place. There are certain benefits of having one big file, of course, such as the reduced number of requests. But it should be possible to optimize at least critical parts of the app, by including only relevant styles.
This isn’t a new discovery by any means. Page Speed has always been warning against this. However, I was really surprised to see just how much this could really affect the rendering time. In my case, I shaved ~200-300ms of selector matching — according to Opera profiler — just by getting rid of unused CSS rules. Layout and paint times went down as well.
Reducing reflows — another well-known optimization — plays big role here as well. Expensive styles are not so expensive when fewer reflows/repaints need to be performed by the browser. And even simple styles could slow things down if they’re applied a lot. Reducing reflows AND reducing complexity of CSS go hand in hand.
Most expensive selectors tend to be universal ones ("*"
), and those with multiple classes (".foo.bar"
, "foo .bar.baz qux"
, etc.). We already knew this, but it’s nice to get confirmation from profilers.
Watch out for universal selectors ("*"
) that are used for “no reason”. I found selectors like "button > *"
, even though throughout the site/app buttons only had
’s in them. Replacing "button > *"
with "button > span"
made for some amazing improvements in selector performance. The browser no longer needs to match every element (due to right-left matching). It only needs to walk over ’s — the number of which could be significantly smaller — and check if parent element is <button>. You obviously need to be careful substituting "*"
with specific tags, as it’s often hard to find all the places where this selector could be used.
The big downside of this optimization is that you lose flexibility, as changing markup will now require changing CSS as well. You won’t be able to just replace one button implementation with another one in the future. I felt iffy doing this replacement, as it's essentially getting rid of useful abstraction for the sake of performance. As always, find the right compromise for your particular case, until engines start to optimize such selectors and we don't have to worry about them.
I used this snippet to quickly find which elements to substitute "*"
with.
$$(selector).pluck('tagName').uniq(); // ["SPAN"]
This relies on Array#pluck
and Array#uniq
extensions from Prototype.js. For plain version (with reliance on ES5 and selectors API), perhaps something like this would do:
Object.keys([].slice.call(
document.querySelectorAll('button > *'))
.reduce(function(memo, el){ memo[el.tagName] = 1; return memo; }, {}));
In both Opera and WebKit, [type="..."]
selectors seem to be more expensive than input[type="..."]
. Probably due to browsers limiting attribute check to elements of specified tag (after all, [type="..."]
IS a universal selector).
In Opera, pseudo "::selection"
and ":active"
are also among more expensive selectors — according to profiler. I can understand ":active"
being expensive, but not sure why "::selection"
is. Perhaps a “bug” in Opera’s profiler/matcher. Or just the way engine works.
In both Opera and WebKit, "border-radius"
is among the most expensive CSS properties to affect rendering time. Even more than shadows and gradients. Note that it doesn’t affect layout time — as one would think — but mainly repaint.
As you can see from this test page, I created a document with 400 buttons.
I started checking how various styles affect rendering performance (“repaint time” in profiler). The basic version of button only had these styles:
background: #F6F6F6;
border: 1px solid rgba(0, 0, 0, 0.3);
font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;
font-size: 14px;
height: 32px;
vertical-align: middle;
padding: 7px 10px;
float: left;
margin: 5px;
The total repaint time of 400 buttons with these basic styles only took 6ms (in Opera). I then gradually added more styles, and recorded change in repaint time. The final version had these additional styles, and was taking 177ms to repaint — a 30x increase!
text-shadow: rgba(255, 255, 255, 0.796875) 0px 1px 0px;
box-shadow: rgb(255, 255, 255) 0px 1px 1px 0px inset, rgba(0, 0, 0, 0.0976563) 0px 2px 3px 0px;
border-radius: 13px;
background: -o-linear-gradient(bottom, #E0E0E0 50%, #FAFAFA 100%);
opacity: 0.9;
color: rgba(0,0,0,0.5);
The exact breakdown of each one of those properties was as follows:
The text-shadow and linear-gradient were among the least expensive ones. Opacity and transparent rgba() color were a little more expensive. Then there was box-shadow, with inset one (0 1px 1px 0
) slightly faster than regular one (0 2px 3px 0
). Finally, the unexpectedly high border-radius.
I also tried transform with rotate parameter (just 1deg) and got really high numbers. Scrolling the page — with 400 slightly rotated buttons on it — was also noticeably jerky. I’m sure it’s not easy to arbitrarily transform an element on a page. Or maybe this is the case of lack of optimization? Out of curiosity, I checked different degrees of rotation and got this:
Note how even rotating element by 0.01 degree is very expensive. And as the angle increases, the performance seems to drop, although not linearly but apparently in a wavy fashion (peaking at 45deg, then falling at 90deg).
There’s room for so many tests here — I’d be curious to see performance characteristics of various transform options (translate, scale, skew, etc.) in various browsers.
In Opera, page zoom level affects layout performance. Decreasing zoom increases rendering time. This is quite understandable, as more stuff has to be rendered per same area. It might seem like an insignificant detail, but in order to keep tests consistent, it’s important to make sure zoom level doesn’t mess up your calculations. I had to redo all my tests after discovering this, just to make sure I’m not comparing oranges to grapefruits.
Speaking of zoom, it could make sense to test decreased font and see how it affects overall performance of an app — is it still usable?
In Opera, resizing browser window doesn’t affect rendering performance. It looks like layout/paint/style calculations are not affected by window size.
In Chrome, resizing browser window does affect performance. Perhaps Chrome is smarter than Opera, and only renders visible areas.
In Opera, page reloads negatively affect performance. The progression is visibly linear. You can see from the graph how rendering time slowly increases over 40 page reloads (each one of those red rectangles on the bottom correspond to page load followed by few second wait). Paint time becomes almost 3 times slower at the end. It looks almost like page is leaking. To err on a side of caution, I always used the average of first ~5 results to get “fresh” numbers.
Script used for testing (reloading page):
window.onload = function() {
setTimeout(function() {
var match = location.href.match(/\?(\d+)$/);
var index = match ? parseInt(match[1]) : 0;
var numReloads = 10;
index++;
if (index < numReloads) {
location.href = location.href.replace(/\?\d+$/, '') + '?' + index;
}
}, 5000);
};
I haven't checked if page reloads affect performance in WebKit/Chrome.
An interesting offending pattern I came across was a SASS chunk like this:
a.remove > * {
/* some styles */
.ie7 & {
margin-right: 0.25em;
}
}
..which would generate CSS like this:
a.remove > * { /* some styles */ }
.ie7 a.remove > * { margin-right: 0.25em }
Notice the additional IE7 selector, and how it has a universal rule. We know that universal rules are slow due to right-left matching, and so all browsers except IE7 (which .ie7 — probably on  element — is supposed to target) are taking an unnecessary performance hit. This is obviously the worst case of IE7-targeted selector.
Other ones were more innocent:
.steps {
li {
/* some styles */
.ie7 & {
zoom: 1;
}
}
}
..which produces CSS like:
.steps li { /* some styles */ }
.ie7 .steps li { zoom: 1 }
But even in this case engine needs to check each

element (that’s within element with class “steps”) until it would “realize” that there’s no element with “ie7” class further up the tree.
In my case, there was close to a hundred of such .ie7 and .ie8 -based selectors in a final stylesheet. Some of them were universal. The fix was simple — move all IE-related styles to a separate stylesheet, included via conditional comments. As a result, there were that many less selectors to parse, match and apply.
Unfortunately, this kind of optimization comes with a price. I find that putting IE-related styles next to the original ones is actually a more maintainable solution. When changing/adding/removing something in the future, there’s only one place to change and so there’s less chance to forget IE-related fixes. Perhaps in the future tools like SASS could optimize declarations like these out of the main file and into conditionally-included ones.
In Chrome (and WebKit), you can use “Timeline” tab in Developer tools to get similar information about repaint/reflow/style recalculation performance. Timeline tab allows you to export data as JSON. First time I’ve seen this done was by Marcel Duran in this year’s Performance Calendar. Marcel used node.js and a script to parse and extract data.
Unfortunately, his script was including "Recalculate styles" time in the “layout” time — something I wanted to avoid. I also wanted to avoid page reloads (and getting average/median time). So I tweaked it to a much simpler version. It walks over entire data, filtering entries related to Repaint, Layout, and Style Calculation; then sums up total time for each of those entries:
var LOGS = './logs/',
fs = require('fs'),
files = fs.readdirSync(LOGS);
files.forEach(function (file, index) {
var content = fs.readFileSync(LOGS + file),
log,
times = {
Layout: 0,
RecalculateStyles: 0,
Paint: 0
};
try {
log = JSON.parse(content);
}
catch(err) {
console.log('Error parsing', file, ' ', err.message);
}
if (!log || !log.length) return;
log.forEach(function (item) {
if (item.type in times) {
times[item.type] += item.endTime - item.startTime;
}
});
console.log('\nStats for', file);
console.log('\n Layout\t\t', times.Layout.toFixed(2), 'ms');
console.log(' Recalculate Styles\t', times.RecalculateStyles.toFixed(2), 'ms');
console.log(' Paint\t\t\t', times.Paint.toFixed(2), 'ms\n');
console.log(' Total\t\t\t', (times.Layout + times.RecalculateStyles + times.Paint).toFixed(2), 'ms\n');
});
After saving timeline data and running a script, you would get information like this:
Layout 6.64 ms
Recalculate Styles 0.00 ms
Paint 114.69 ms
Total 121.33 ms
Using Chrome’s “Timeline” and this script, I ran original button test that I tested before in Opera and got this:
Similarly to Opera, border-radius was among least performant. However, linear-gradient was comparatively more expensive than that in Opera and box-shadow was much higher than text-shadow.
One thing to note about Timeline is that it only provides "Layout" information, whereas Opera's profiler has "Reflow" AND "Layout". I'm not sure if reflow data analogous to Opera's is included in WebKit's "Layout" or if it's discarded. Something to find out in the future, in order to have correct testing results.
When I was almost done with my findings, WebKit has added selector profiler similar to Opera’s one.
I wasn’t able to do many tests with it, but noticed one interesting thing. Selector matching in WebKit was marginally faster than that of Opera. The same document — that one-page app I was working on (before optimizations) — took 1,144ms on selector matching in Opera, and only 18ms in WebKit. That’s a ~65x difference. Either something is off in calculations of one of the engines, or WebKit is really much much faster at selector matching. For what it’s worth, Chrome’s timeline was showing ~37ms for total style recalculation (much closer to WebKit), and ~52ms for repaint (compare to Opera’s 225ms “Paint” total; different but much closer). I wasn’t able to save “Timeline” data in WebKit, so couldn’t check reflow and repaint numbers there.
.ie7 .foo .bar
)[type="url"]
)As I end these notes, I have tons of other questions related to CSS performance:
[type=search]
vs [type="search"]
). How does this affect performance of selector matching?As our pages/apps become more interactive, the complexity of CSS increases, and browsers start to support more and more “advanced” CSS features, CSS performance will probably become even more important. The existing tools are only scratching the surface. We need the ones for mobile testing and tools in more browsers (IE, Firefox). I created a ticket for Mozilla, so perhaps we’ll see something come out of it soon. I would love to see CSS performance data exposed via scripting, so that we could utilize it in tools like jsperf.com (cssperf.com?). Meanwhile, there's plenty of tests to be done with existing profilers. So what are you waiting for? ;)


WITNESS LIST
Jurisprudence
March 12, 2013 1:30 PM - or upon adjournment
FOR:
Gutierrez, Bobby Constable (Justice of Peace & Constables Assoc), Georgetown, TX
Lee, Abby Associate Counsel (Texas Association of Realtors), Austin, TX
Mintz, David VP Govt Affairs (Texas Apartment Association), Austin, TX
Registering, but not testifying:
FOR:
Gonzalez, Daniel (Texas Association of Realtors), Austin, TX
Lopez, Carlos (Justice of the Peace and Constables Assoc of Tx), Austin, TX
Rickers, Emily (Alliance for Texas Families), Austin, TX
FOR:
Garza, Jessica (Self), Austin, TX
Langbein, Jan Executive Director (Genesis Women's Shelter), Dallas, TX
Registering, but not testifying:
FOR:
Grinstead-Everly, Tracy (Texas Council on Family Violence), Austin, TX
Kenderdine, Marshall (Texas Pediatric Society), Austin, TX
Martinez, Diana Director of Public Policy (TexProtects, The Texas Asso for the Protection
of Children), Wimberley, TX
Rickers, Emily (Alliance for Texas Families), Austin, TX
FOR:
Lov Muro, Mona (Denton County Friends of the Family), Corinth, TX
Registering, but not testifying:
FOR:
Bresnen, Steve (Texas Family Law Foundation), Austin, TX
LeBleu, Stephanie Public Policy Coordinator (Texas Court Appointed Special Advocates),
Austin, TX
Martinez, Diana Director of Public Policy (TexProtects, The Texas Asso. for the Protection
of Children), Wimberley, TX
Milam, Susan (National Association of Social Workers/Texas Chapter), Austin, TX
Rickers, Emily (Alliance for Texas Families), Austin, TX
Setliff, Aaron Director of Policy (Texas Council on Family Violence), Austin, TX
FOR:
Davis, Chris County Judge (Cherokee County), Rusk, TX
ON:
Slayton, David (Office of Court Administration), Austin, TX
Registering, but not testifying:
FOR:
Sugg, Paul (Texas Association of Counties), San Antonio, TX
WITNESS LIST
Jurisprudence
March 12, 2013 1:30 PM - or upon adjournment
ON:
Lehman, Jim (Office of Court Administration), Austin, TX
Registering, but not testifying:
ON:
Kepple, Rob (District & County Attorneys Association), Austin, TX
FOR:
Sibley, James President (Title Data, Inc.), Spring, TX
AGAINST:
Hamlin, Marc Brazos County District Clerk (County and District Clerks Association of
Texas), Bryan, TX
Registering, but not testifying:
FOR:
Baggett, Donnis Executive Vice President (Texas Press Association), Waco, TX
Chadwick, Ashley (Freedom of Information Foundation of Texas), Austin, TX
Kralj, Nick (Fidelity National Title Chicago Title), Austin, TX
Lee, Randy Senior VP (Stewart Title & Stewart Title Guaranty Co.), Austin, TX
Schneider, Michael Director of Newsroom and Legal Services (Texas Association of
Broadcasters), Austin, TX
Thomas, Chelsey (Texas Association of Realtors), Austin, TX
AGAINST:
Roberts, Cary (County and District Clerks), Austin, TX
AGAINST:
Newman, Jeremy (Texas Home School Coalition), Lucas, TX
Wood, Cecilia (Self), Austin, TX
Registering, but not testifying:
FOR:
LeBleu, Stephanie (Texas Court Appointed Special Advocates (CASA)), Austin, TX
Martinez, Diana Director of Policy (Texas Asso. for the Protection of Children),
Wimberley, TX
FOR:
Davis, Lauren (Self), Austin, TX
Rodgers, Kelly (Wells Fargo Bank), Austin, TX
ON:
Karisch, Glenn (Texas Academy of Probate and Trust Lawyers), Austin, TX
Registering, but not testifying:
FOR:
Embrey, Celeste (Texas Bankers Association), Austin, TX
Gilbert, Bo (United Services Automobile Association), San Antonio, TX
WITNESS LIST
Jurisprudence
March 12, 2013 1:30 PM - or upon adjournment
Torgeson, Janice Senior Vice President (Frost Bank), Austin, TX


Installing GDAL with Python in Ubunut1204
2014-06-18
##InstallingGDALwith_Python##
- to make geotiff file from wrf output, python script requiers gdal such as for this from osgeo import gdal and from osgeo import osr
- to install it in Ubuntu 12.04, it reuiers to install gdal-bin, libgdal1 and ptthon-gdal, after installing running python and importing crahes
python with this message segmentation error(core dumped)
- first it was detected of version difference, so installed with deb packages avaolable for the version for 1.9.2
- this alos not removed this eroro
- another attmept made is follwoign this
but the routine command for compiiling from source I used is a problematic(explained here) in long run sudo make install
, just install the file in where ever it
like and removing the package is virtually iporssible, instaead it is suggested that to run sudo checkinstall
- to remove a packae in ubuntu use dpkg -s <packagename>
, to view the installed packages in python pip freeze
- so with all this step also no devlopement, importing gdal crashes python
- for a resuce tryed with Anaconda, a distributin of python with all packages for sicentific computing
- Anaconda can be downaoded as .sh file and installed in linux by bash file.sh
, it asks for licencane, set to envirotnma variable and location of the anacond directory
- based on some old page tryed with virtualenv with anaconda and tryed to isntlle gdal from its normal source but it gives error of same nature, and it not reactivatiing the virtuaenv in ubunutu also
- instead followed this and installed gdal with anaconda simplly by
conda install gdal
, it just installed gdal and importing works with out any error.
- like wise netcdf4 also installed conda install netcdf4
and it works the wrfncxnj.py appliation, so wrfoutput python routine just works outofbox with Anaconda! site to refer 1, 2


VapeON
Make e-liquid yourself
Size
30ml
100ml
50ml
150ml
70ml
200ml
PG/VG
50/50
70/30
Flavor
Tobacco
Arabic
Black Honey
Cubano Type
Black Cherry
Fruit
Acai
Apricot
Berry Mix
Coconut
Apple
Banana
Cantaloupe
Dragonfriut
Bake/Sweet
Banana Cream
Berry Cereal
Bubblegum
Bavarian Cream
Brown Sugar
Caramel
Nicotine
0
1
3
6
Total cost: $15.15
Login
Register
Forgot Password?


The Straits Times covers a vast trove of news stories over a period of 170 years,
spanning many critical checkpoints in Singapore’s history. Distilling the contemporary
mood of the era through the myriad stories is a daunting task, but technology may aid
the process. Stories have been compiled in digital form via online archives of the
National Library Board which enables deep data analysis methods on the news.
The following visualization looks at the key words that have been used in each year of
the Straits Times and presents a dynamic portrayal of how words have evolved over time,
suggesting an ebb and flow in tandem with the nation’s history.


Update: this is indeed a dodgy method I’ve posted below. I’ll update this post when I can, but you’re better off digging out your 8th grade maths and working out the coordinates of surrounding cells and constraining all edges to each other. Friends don’t let friends blog at 12.30am.
So I’ve been puzzling for a few weeks through the dim and darkened alleyways of Leopard’s new Core Animation APIs and the rather wonderful CALayer. One of the features I’m planning for Hyperspaces is a desktop pager that will show basic approximations of your on-screen windows - sort of like what used to be in VirtueDesktops, but way cooler because it will use Core Animation to smoothly animate changes in state.
Unfortunately, I hit a rather interesting problem while attempting to draw a grid of self-positioning CALayers. See, you can tie CALayers together using constraints, but in a traditional grid of objects you need to tie all the edges of the grid objects to each other (and the outer grid objects to the frame of the constraining frame) - but you can’t constrain CALayers using CALayers that haven’t been created yet (still with me? sounds sane, right?).
So the answer turned out to be to cheat. First, constrain the width and height of all CALayer grid objects to be consistently based on the height and width of the constraining CALayer (scaled to fit the number of columns and rows we’re trying to get onscreen). Tie all the “outer” CALayers to the constraining CALayer on the edges where they connect with it. Now, tie the left and top edges of all CALayers to the right and bottom edges of the CALayers around them as shown to the left.
So in the interests of getting more Core Animation code out there, here is my somewhat dodgy, but completely re-usable approach to drawing a grid of CALayers in your own monstrosity of an application. I’m open to being completely corrected by someone willing to write a proper CALayoutManager for this. Neil, James - now that you’ve been through Cocoa bootcamp, I expect to see some really inappropriate Core Animation, OK? Use this as a starting point:


Osiris Jailbreak
for all 64-Bit devices on iOS 11.2 -> 11.3.1
THIS IS NOT A COMPLETE JAILBREAK. IF YOU NEED A REAL JAILBREAK, USE UNC0VER OR ELECTRA. THIS PROJECT WAS ABANDONED
WARNING!
This is a work-in-progress Jailbreak and it should NOT be used by inexperienced users. This jailbreak is not meant for public usage.  Use at your own risk (or better don't).
Working Features:
Alpha 3
- Escapes the SandBox
- Patches AMFI (CodeSign)
- Remounts ROOT FS as R/W on iOS 11.2.x
- Disables the iOS Updates and removes already downloaded ones
- Spawns Dropbear for SSH (remote access from PC) on port 22 (Use iPhoneTunnel for tunneling)
- Fixed the signing issue and uicache now works thanks to @IBSparkes who pointed me to the correct debugging tools
- Fixed the File Descriptor Leak in multi_path thanks to luckycat889 on http://newosxbook.com/forum/
What needs to be implemented
- REQUIRES DEVELOPER ACCOUNT (I USE MULTI_PATH)
- The whole code-base can be improved
- Doesn't contain Cydia
- Doesn't jailbreak your device. For that use Electra or Unc0ver.
- Remounting doesn't yet work on iOS 11.3.x


DAP.js Demo
Flash and debug mbed enabled development boards in the browser using CMSIS-DAP over WebUSB. Currently tested in Google Chrome on Windows with an NXP Freedom K64F and the micro:bit.
WebUSB is an experimental technology providing low-level USB access from JavaScript code running in the browser.
Select a device:
Choose platform:
Flash a binary:
Tools: