Comprehensive list of options available in Assemble
Most options are defined in the assemble
task or target options in the Gruntfile, some options may only be defined inside the [YAML front matter][yaml-front-matter] of a file, and some may be defined in either location.
Additionally, options may be defined in "external" [JSON][] or [YAML][] configuration files.
For the purposes of clarity, we will refer to options that are defined in the Gruntfile as "configuration" options, and options that are defined in the YFM as "page" options.
These options are defined in the assemble
task in your project's Gruntfile. Any option may be defined at the task or target level.
| Option | Description |
|---|---|
| [assets][options-assets] | directory that contains commonly used "assets" for a project, such as images, fonts, javascripts and stylesheets. Assemble will generate a relative path from dest files to the given assets directory. |
| [collections][options-collections] | |
| [data][options-data] | path to data files to supply the data that will be passed into templates. |
| [engine][options-engine] | engine to be used for processing templates. Handlebars is the default. |
| [ext][options-ext] | extension to be used for dest files. |
| [helpers][options-helpers] | path to custom helper(s) to be registered and used by the current template engine. Handlebars is the default. |
| [layout][options-layout] * | [Layouts][] are optional and assemble will build [pages][] without one. However, when a layout is specified the file must contain a {{> body }} tag, since this tag indicates where the content from each file in a target should be inserted. |
| [layoutdir][options-layoutdir] * | [Layouts][] are optional and assemble will build [pages][] without one. However, when a layout is specified the file must contain a {{> body }} tag, since this tag indicates where the content from each file in a target should be inserted. |
| [partials][options-partials] | the partials or "includes" to be used with [pages][]. |
*Note that when a layout is used the [{{> body }}][Layouts] tag must be included inside the layout in order for content from pages to be "pulled in".
These options are defined in the assemble
task in your Gruntfile.
Type: String|Array
(optional)
Default: src/data
Retrieves data from any specified JSON
and/or YAML
files to populate the templates when rendered. Data gets passed through the data
object to the options on the assemble task, and then to the context in your templates. Also useful for specifying [configuration][] data.
options: { data: 'src/data/**/*.{json,yml}' }
Note that assemble
merges the task and target-level data for options.data
.
Type: String
(optional)
Default: undefined
Layouts are optional and may be defined at the task and/or target level. Unlike Jekyll, Assemble requires a file extension since you are not limited to using a single file type.
options: { layout: 'src/layouts/default.hbs' }
Type: String
(optional)
Default: undefined
Path to the "assets" or "public" directory that will be used by dest files. Assemble uses path in the assets
option to generate a relative path from dest files to the given "assets" directory. The "assets" folder commonly contains the CSS, JavaScripts, images and other similar files for a project. The assets
option may be defined at the task or target-level.
options: { assets: 'docs/assets' }
Type: String|Array
(optional)
Default: undefined
Specifies the Handlebars partials files, or paths to the directories of files to be used.
options: { partials: 'src/partials/**/*.hbs' }
Note that assemble
merges the task and target-level data for options.partials
.
Type: String
(optional)
Default: .html
Specify the file extension to be used for destination files. For example:
assemble: {
// Build sitemap from JSON and templates
sitemap: {
options: { ext: '.xml'},
files: {
'.': ['path/to/sitemap.tmpl']
}
},
// Build README from YAML and templates
readme: {
options: { ext: '.md' },
files: {
'.': ['path/to/readme.tmpl']
}
}
}
Learn more about the [ext option][options-ext].
Type: String
(optional)
Default: handlebars
The engine to use for processing client-side templates. Assemble ships Handlebars as the default template engine, to learn more about adding other template engines please read the documentation on [assemble methods][methods].
Also, we welcome pull requests for additional template engines. If you have questions please create an [Issue][assemble-issues].
Type: String|Array
(optional)
Default: 100+ helpers from [helper-lib][]
Assemble depends on [helper-lib][], an external library which includes more than 100 Handlebars helpers. So any helpers from that project may be used in your templates.
If you wish for Assemble to use custom helpers with Handlebars or any specified template engine, just provide the path to the helper or helpers in options.helpers
:
options: { helpers: 'your/custom/helpers' }
Type: Boolean
Default: false
Remove extraneous whitespace added by Handlebars in rendered files. Use at your own risk, this is an experimental option and may be removed.
These options are defined in the [YAML front matter][yaml-front-matter] of a page.
type: string
default: undefined
Specifies the [layout][Layouts] file to be used. Layouts defined in [YFM][yaml-front-matter] will override layouts defined in the Gruntfile.
type: boolean
default: true
Defining published: false
in the [YAML front matter][yaml-front-matter] of a page will:
pages
collection. Custom, user-defined variables may be specified in the [Options][options-overview] of the assemble task or target. Any variables defined in the options will be added to the root of the data context and thus they will also be available in any templates.
A common use case for defining custom variables in the options is for easily including or excluding content based on current "development status".
For example, assuming we have defined a custom option, production
:
assemble: {
options: {
production: false
},
files: {
'site/': ['src/pages/*.hbs']
}
}
And we add the production
variable to our templates:
{{#if production}}

{{else}}

{{/if}}
Since production: false
is defined in the Assemble [task options][options], the following HTML will be rendered with the non-minified version of the script:

The following is just a handful of options that can be used in your Gruntfile. Please visit the Grunt documentation to learn more.
expand
Set to true
to enable the following options:cwd
All src
matches are relative to (but don't include) this path.src
Pattern(s) to match, relative to the cwd
.dest
Destination path prefix.ext
Replace any existing extension with this value in generated dest
paths.flatten
Remove all path parts from generated dest
paths.rename
This function is called for each matched src
file, (after extension renaming and flattening). The dest
and matched src
path are passed in, and this function must return a new dest
value. If the same dest
is returned more than once, each src
which used it will be added to an array of sources for it.[Variables][built-in-variables]
[YAML Options][YAML]
"Assets" directory to be used by dest files in a target.
Type: String
(optional)
Default: undefined
options.assets
may be defined at the task- and/or target-levels.
Oftentimes an "assets" directory is used in projects for containing the CSS, JavaScripts, images and other similar files.
Once the assets
variable is defined in the Gruntfile, you may use the {{assets}}
variable anywhere in your templates and Assemble will generate a relative path from dest
files to the specified assets
directory.
Given the following task configuration in your project's Grunfile:
assemble: {
options: {
// Set the "default" assets dir at the task-level
assets: 'docs/assets'
},
docs: {
files: {
'docs/': ['src/pages/**/*.hbs']
}
},
components: {
files: {
'docs/components/': ['src/partials/**/*.hbs']
}
},
main: {
options: {
// Override the task-level assets dir
assets: 'dist/assets'
},
files: {
'dist/': ['src/pages/**/*.hbs']
}
}
// other stuff
}
And given the following templates:
<link rel="stylesheet" href="{{assets}}/css/bootstrap.css">
The output HTML will render as follows:
For the assemble.docs
target
<link rel="stylesheet" href="assets/css/bootstrap.css">
For the assemble.components
target
<link rel="stylesheet" href="../assets/css/bootstrap.css">
For the assemble.main
target
<link rel="stylesheet" href="assets/css/bootstrap.css">
Note that for assets
to work predictably, a slash must follow the `{{assets}} variable
The following built-in collections are available at the root of the context:
| Collection | Collection item | Description |
|---|---|---|
tags |
tag |
Used to specify tags associated with the current page. Multiple tags may be associated with each page. Useful for adding semantic tags or tag clouds to your content. |
categories |
category |
Used to specify categories associated with the current page. Multiple categories may be associated with each page. Similar to tags but more appropriate for categorizing pages by "broader" concepts. |
pages |
page |
See Pages collection differences below |
"[Pages][]" and "page" differ from other collections and collection items in the following ways:
src
of a given target will be the collection items associated with the "pages" object for that target.You may then add items to collections in the YAML front matter of any files that should include those collections:
---
title: My Blog
archives:
- 2013
- May
- 12
---
Additionally, any collection item from the collections
object can list the [pages][pages] associated with that collection. For example, each "tag" would list the [pages][pages] associated with that tag.
{
tag: 'news',
pages: ['one.html', 'two.html', 'three.html']
}
type: Array
default: null
Custom collections
may be defined using the collections
option:
assemble: {
options: {
collections: ['archives', 'posts']
}
}
And then in the YAML front matter of a page:
---
archives:
- 2013
- May
- 12
---
There are no restrictions on the number of collections creatd, you may specify as many custom collections as you require.
Currently, for the sake of ease of use, the collection method uses the inflection library to convert a collection's item key into the correct syntax:
tags
converts to: { tag: 'ficus', pages: [] }
categories
converts to: { category: 'trees', pages: [] }
If words you wish to use are either missing or don't work properly, please let us know by creating an Issue on Assemble's GitHub repository.
Declaring tags and categories for a page within the page's [YAML front matter][yaml-front-matter]
---
tags:
- feature
- priority
categories:
- open
---
List all tags

{{#tags}}

{{tag}}

{{/tags}}

List all categories

{{#categories}}

{{category}}

{{/categories}}

List tags on current page

{{#page.tags}}

{{.}}

{{/page.tags}}

List categories on current page

{{#page.categories}}

{{.}}

{{/page.categories}}

Also see the wiki page for [data types][data].
You must first define the paths to any data files you wish to use via the options.data
object in the assemble
task or target, then Assemble will automatically supply data to your templates:
assemble: {
options: {
data: 'src/data/*.json'
}
files: {
'site/': ['src/pages/*.hbs']
}
}
Context to the name of the data file is the same as the associated template, and we
To use "external" data files (versus YAML front matter), y
"widget component" example
Given a data file, such as widget.json
or widget.yml
:
{
"name": "This is a square widget",
"modifier": "widget-square"
}
With the following Handlebars expressions in out template, widget.hbs
:

{{ widget.name }}

The result after running grunt assemble
will be:

This is a square widget

package.json example #1
Add package.json
to the data
object:
assemble {
myProject: {
options: {
data: 'package.json'
},
files: {
'dest': ['src/templates/**/*.hbs']
}
}
}
And we will not be able to retrieve metadata from package.json
by using variables such as:
{{package.verson}}
{{package.name}}
{{package.description}}
{{package.author.url}}
{{package.author.name}}
package.json example #2
Assuming we add the following code to our Gruntfile
pkg: grunt.file.readJSON('package.json'),
assemble {
myProject: {
options: {
pkg: '<%= pkg %>',
data: 'other/data/*.json'
},
files: {
'dest': ['src/templates/**/*.hbs']
}
}
}
We can now use the following expresions in our templates:
{{pkg.verson}}
{{pkg.name}}
{{pkg.description}}
{{pkg.author.url}}
{{pkg.author.name}}
Also see: [YAML front matter][yaml-front-matter]
init
methodDescribes init
method to assemble.engine
, and exposes engine on assemble.engine
.
If you don't wish to use Handlebars as your templates engine, you may add your own engine by providing an init
function that takes in options from the assemble task/target. You may also override the init
function in the task/target options by providing an initializeEngine
function that takes the engine and the options:
assemble: {
options: {
engine: 'consolidate',
initializeEngine: function(engine, options) {
engine.engine.swig.init(options);
}
},
docs: {
files: {
'docs/': ['src/templates/**/*.tmpl']
}
}
}
Assemble will attempt to load an engine and automatically add it's own wrapper methods around it while holding an instance of the engine. This is a way for engine plugin authors to write adapters between other engines and assemble's wrapper. To make these functions on the options useful, we've exposed the underlying engine through the assemble.engine
object so developers can use the raw engine.
This is particularly useful when a) a library such as [consolidate][] is used, where the engine is consolidate
, and b) the developer wants to use another engine such as handlebars, swig, mustache etc.
init
function allows assemble to pass in options to be used in initializing this engine plugin.init
function is exposed, and helper-lib is registered inside the init so that options can be passed in.Admittedly, the engine.engine
syntax is strange. This is "alpha", so feedback and pull requests are especially welcome if you have ideas for improving this.
Specify the file extension to use on dest files. Extensions can be specified at the task and target-levels.
Type: String
(optional)
Default: .html
When planning out the strategy for your build targets, [templates][templates] and [data][data], don't forget to take the ext
variable into consideration. ext
opens up a few doors by "bending the rules" around how your source files will be compiled or rendered.
In 90% of cases, the ext
option will not be needed, and simply using the .hbs
file extension on your [templates][templates] will suffice. However, in scenarios where you are using mixed content, say HTML and markdown with Handelbars templates embedded in one or both formats, you may need to use the ext
option to esure that you get the output you need.
Consider the following scenario:
Your end goal is for all of your markdown content to be rendered to HTML in the output.
and you want your need to compile some markdown files to HTML, and you want to use other markdown files as "includes" or "partials" inside other markdown files, in which case you want the markdown files to be rendered as markdown in the output. You may even want to embed Handlebars templates inside your markdown files to be parsed and compiled.
As of NaN/NaN/NaN NaN:NaNAM, Assemble's extensions map "whitelists" the following extensions:
Handlebars extensions
handlebar : handlebars
handlebars: handlebars
hb : handlebars
hbars : handlebars
hbrs : handlebars
hbs : handlebars
hbt : handlebars
htm : handlebars
html : handlebars
mustache : handlebars
template : handlebars
tmpl : handlebars
tpl : handlebars
Markdown extensions
markd : markdown
markdown: markdown
md : markdown
If you need Assemble to process templates in files with an extension that isn't in extensions.yml, you must explicitly define the template engine in the task/target options to force Assemble to process your templates.
So given this example:
assemble: {
options: {
engine: "Handlebars" // case insensitive
},
files: {
'dist/': ['src/pages/*.snickerdoodle']
}
}
So now that we have defined an engine, Handlebars, Assemble knows to use that engine to process templates with the .snickerdoodle
extension. Even better, your templates will also be compiled into delicious Christmas cookies with cinnamon and sugar sprinkled on top.
Here are some examples that cover common use cases.
If your repo is on GitHub, it's a safe bet you're using markdown format on your READMEs and wikis. Here we're going to show you how to use templates to generate markdown files, so if you work on big projects, or a lot of projects, you can potentially reduce the amount of time you spend updating documentation, changelogs, links, common metadata and so on.
Now, of course there are many ways to accomplish the same goal, this is an example so we're going for simplicity. Here's what we want to accomplish:
src
content written in markdownsrc
content contains templates, package.json
(this is arbitrary, you can use more than one file if you want, .yml
format is fine too)dest
files must remain in markdown format. In other words, we want Assemble to process the templates, but not to convert the markdown to HTML. Here is what we need to do:
Example configuration:
assemble: {
options: {
data: 'src/data/readme.yml',
partials: 'src/content/*.hbs',
ext: '' // add the "empty" ext property
},
readme: {
files: {
'./': ['src/templates/README.md.hbs']
}
}
}
Our goal here is to tell the assemble
task to treat the src
markdown files as regular content. In other words we don't want the task to convert the markdown files to HTML, so we use a sort of trick that allows us to write our README content in markdown along with embedded Handlebars templates.
Our goal here is to tell the assemble
task.
Here, we tell the assemble
task not to use an extension on dest
files by leaving ext: ''
blank. We do this because our templates have the extenions .md.hbs
and assemble only slices off the last extension at build time. So by 1) telling assemble not to add another extension to the rendered templates, and 2) by naming our template files with the .md.hbs
extension, we
Common use cases:
assemble: {
options: {
engine: "Handlebars" // case insensitive
},
files: {
'dist/': ['src/pages/*.md.hbs']
}
}
Rendered pages will have the .html
extension by default.
Helpers manipulate the output of variables
For the most part helper expressions follow this pattern: {{ helper_name variable_name }}
. For example:
<title>{{ uppercase title }}</title>
Renders to:
<title>PAGE TITLE</title>
Custom helpers may be loaded with the current engine via options: { helpers: []}
in the assemble task or target. But any helpers registered at the target level will override task-level helpers.
Globbing patterns may be used to specify paths to the helpers to be loaded:
assemble: {
options: {
helpers: ['./lib/helpers/**/*.js']
}
}
Helpers can either be an object or a single register
function. If register
is on the object, then it calls the register
function passing in the engine, otherwise each method is registered as a helper. For example, the following will result in 2 helpers being registered:
module.exports.foo = function(msg) { return msg; };
module.exports.bar = function(msg) { return msg; };
And this will result in the foo
helper getting register directly through Handlebars:
module.exports.register = function(Handlebars, options) {
Handlebars.registerHelper('foo', function(msg) {
return msg;
});
};
The Handlebars.registerHelper
method takes the name of the helper and the helper function as arguments. Handlebars.js then takes whatever is returned from the helper function and writes it out to the template, so be sure to always return a string from your custom helpers.
assemble.options
into helpersAny assemble.options
may be passed to custom helpers when the helper defines the register
method. For example:
Given our Gruntfile.js
has the following assemble
task configuration:
assemble: {
options: {
version: '0.1.0', // or we could use '<%= pkg.version %>'
helpers: ['lib/helpers/**/*.js']
},
blog: {
files: {
'articles/': ['src/posts/*.md']
}
}
}
And given we have defined a custom helper, opt
, which gets properties from the assemble.options
object and returns them:
module.exports.register = register = function(Handlebars, options) {
Handlebars.registerHelper('opt', function(key) {
return options[key] || '';
});
};
We can now user our helper in a Handlebars template like this:

Version: v{{opt 'version'}}

And the output would be:

Version: v0.1.0

Layouts are commonly used with client-side templates as a quick way to "wrap" a number of [pages][] with commonly used page "sections", such as the head, footer or navigation.
Oftentimes you will need more than one layout for your project, so layouts can be defined using the options.layout
variable at the task or target-level, or they can be specified at the page-level by adding a layout
property to the [YFM][YAML front matter].
{{> body }}
tagAlthough layouts are optional, the {{> body }}
tag is required for content to be pulled into a layout.
<!DOCTYPE html>

<title>{{title}}</title>

{{> body }}

Path to the directory to be used as the "cwd" for layouts
layoutdir
makes maintaining [layouts][options-layout] a little easier on projects that require more than one layout. The primary advantage of using the feature is that you can change or rename the directory where your layouts are stored without having to update the path to each layout used throughout your project. It could also reduce some clutter in the Gruntfile and [YAML Front Matter][yaml-front-matter].
Additionally, a layoutdir
can be defined for each [targets][targets], allowing for even greater control over how [layouts][] are used in your projects.
layoutdir
When layoutdir
is not defined, each layout must be defined using the full path from the project root to the layout:
assemble: {
options: {
layout: 'src/templates/layouts/default-layout.hbs'
},
docs: {
options: {
layout: 'src/templates/layouts/docs-layout.hbs'
},
...
},
blog: {
options: {
layout: 'src/templates/layouts/blog-layout.hbs'
},
...
}
// etc.
}
This also applies to [YAML front matter][yaml-front-matter] when it is necessary to "override" layouts at the page-level:
---
title: Blog
layout: src/templates/layouts/blog-layout.hbs
---
layoutdir
When layoutdir
is defined only require the name of the layout to be used (must include the file extension):
assemble: {
options: {
layoutdir: 'src/templates/layouts',
layout: 'default-layout.hbs'
},
docs: {
options: {
layout: 'docs-layout.hbs'
},
...
},
blog: {
options: {
layout: 'blog-layout.hbs'
},
...
}
// etc.
}
And in [YAML front matter][yaml-front-matter]:
---
title: Blog
layout: blog-layout.hbs
---
While layoutdir
can make your project a little easier to manage, it is strongly recommended that you establish clear and consistent conventions for your layouts, and follow them. Otherwise, this feature might end up causing more problems than it solves.
Here are some recommendations.
default-layout.hbs
versus simply default.hbs
, andTo understand why this is important, imagine that you're project has three "sub-projects", or [targets][]: components
, docs
and blog
, and that each target has a different layout. This is a fairly basic, common scenario. But remember that each may also have its own layoutdir
as well, which creates potential for conventions that lead to using the wrong layout accidentally, such as this:
assemble: {
components: {
options: {
layoutdir: 'src/components/layouts',
layout: 'default.hbs'
}
...
},
docs: {
options: {
layoutdir: 'src/docs/layouts',
layout: 'default.hbs'
}
...
},
blog: {
options: {
layoutdir: 'src/blog/layouts',
layout: 'default.hbs'
}
...
}
// etc.
}
Note that the layout name is the same for each target, but the layoutdir
is a different directory, indicating that there are three different "default" layouts.
While it might make sense for each target to have its own layoutdir
, since layouts can be overridden in the [YAML front matter][yaml-front-matter] of individual pages, it is not a good idea to use the same name for multiple layouts, unless you are intentionally using this naming convention as a strategy. The reason is that it gets very difficult to track which page is building from which layout when working inside the pages themselves.
Without layoutdir
, you have the entire path to follow, but without it you must rely on the name of the layout itself to guide you.
---
title: Any Page
layout: default.hbs
---
Using a more descriptive name for the layout helps avoid confusion now:
---
title: Any Page
layout: blog-default.hbs
---
Of course, these are only recommendations and you will need to find a strategy that works for you and your team.
Assemble automatically registers any partials supplied via the partials
option at the task or target levels.
assemble {
docs: {
options: {
partials: ['src/templates/partials/**/*.md']
},
files: {
'docs/': ['src/templates/pages/*.md']
}
}
}
Any partials registered at the task level are are also available at the target level.
Important! It is standard in Grunt.js for target-level options to overwrite task-level options. However, assemble merges the list of partials defined at the task-level with the partials defined for each target.
You can establish context inside the partials:
{{> module module.panel-primary}}
{{> module module.panel-info}}
{{> module module.panel-success}}
{{> module module.panel-warning}}
{{> module module.panel-danger}}
{{> module module.panel-query}}
Wrap partials in block expressions and either set the context on the partial:
{{#module}}
{{> module panel-inverse}}
{{> module panel-success}}
{{> module panel-info}}
{{/module}}
Or on the section tags:
{{#module.panel-base}}
{{> module }}
{{/module.panel-base}}
Assemble includes helper-lib as a dependency, so all of the helpers from that library are available by default.
helper-lib includes more than 100 Handlebars helpers from that library in your templates.
Most helpers from helper-lib can be used with any Handlebars project, but a handful of helpers were created specifically for Assemble, including:
path/to/variables.md
. Usage: {{dirname [path]}}
variables.md
. Usage: {{filename "docs/toc.md"}}
pagename
. variables
Usage: {{base "docs/toc.md"}}
.md
Usage: {{extension "docs/toc.md"}}
extension
. {{relative [from] [to]}}
. This can also be used with page
and pages
.{{#markdown}}{{/markdown}}
{{md [path]}}
{{embed 'path/to/file.js'}}
or {{embed 'path/to/file.hbs' 'html'}}
{{jsfiddle [id] [tabs]}}
{{gist [id] [file]}}
{{authors}}
or {{ authors [file] }}
{{changelog [src]}}
{{roadmap [src]}}
Many additional helpers are available in the following categories:
assemble
collections
comparisons
dates
file
html
inflections
logging
markdown
math
miscellaneous
numbers
objects
path
special
strings
url
Visit helper-lib to learn more.
Layouts are used for "wrapping" the content of individual pages with common HTNL, such as a "header" and "footer".
Layouts are optional, but the {{> body }}
tag is required for content to be pulled into a layout.
<!DOCTYPE html>

<title>{{title}}</title>

{{> body }}

options
for each target. Offers greater control over which "types" of pages get which layout
. Since you can create as many [targets][] as you require, defining layouts in the Gruntfile is a great way of quickly setting up your layout "defaults". In the assemble
task in your Gruntfile.js, you can define a layout at the task-level, and/or a different layout for each build target:
assemble: {
options: {
layout: 'layouts/default.hbs'
},
site: {
files: {
'site/': ['templates/pages/*.hbs']
}
},
blog: {
options: {
layout: 'layout/post.hbs'
},
files: {
'blog/': ['templates/posts/*.hbs']
}
},
docs: {
options: {
layout: 'layouts/docs.hbs'
},
files: {
'docs/': ['templates/docs/*.hbs']
}
}
}
If you require a higher level of granularity than defining layouts in the Gruntfile, you may also define layouts on a page-by-page basis, thus overriding both the task-level ("global") defaults and the target-level defaults.
To do so, just add the layout to the [YFM][yaml-front-matter] of the page like this:
---
layout: path/to/layout.hbs
---
layout: false
to the YAML front matter of any page that should build without a layout. layout: false
to the options of any target that should build pages without a layout. Your imagination is the only limit to what can be done with layouts, so these are just examples.
This is something you might use to wrap basic pages for a demo, documentation, etc.
<!DOCTYPE html>

<title>{{title}}</title>

{{title}}

{{description}}

{{> body }}

<!DOCTYPE html>

<title>{{page.title}} · {{ site.title }}</title>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
{{> head-extras }}

{{#section main-header}}

{{#if site.logo}}

{{else}}
{{ site.title }}
{{/if}}

{{/section}}

{{#section tagline}}

{{.}}

{{/section}}

{{> main-navigation }}

{{> body }}

{{> footer }}

Layouts don't have to be HTML, they can be whatever language you want them to be. If you're generating markdown pages instead of HTML, maybe for a project wiki or other markdown documentation, then you'll want to use a markdown formatted layout
.
In this example, instead of adding adding the traditional head and footer we'll add some link references to make sure the same ones are used on every generated page. This makes it easier to maintain links and it also cuts down on potential for broken links:
{{> body }}
---
_This page was generated using Grunt and [assemble][repo] on {{ today }}._
[org]: https://github.com/assemble
[repo]: https://github.com/assemble/assemble
[issues]: https://github.com/assemble/assemble/issues
[wiki]: https://github.com/assemble/assemble/wiki
{{> body }}
tag to render content from any file that uses the layout. Partials are reusable fragments of code that can be included in a page and rendered
Partials are useful when you have blocks of reusable code that is applicable in different contexts. The Handlebars.registerPartial
method, which registers a partial, accepts the name of the partial as its first argument and either a template source string or a compiled template as its second argument.
Accepting a compiled template as the second argument enables you, for example, to use the partial in a loop that outputs a list but also append items to the list later using the partial’s template function.
To use a partial from a template, simply include {{> partial-name }}
. For example:
Mix and match JSON, YAML, YAML front matter, and data stored in the Gruntfile however you want.
Table of Contents
Any of the following data formats may be used:
my-data.json
my-data.yml
Visit the [options.data][options-data] page to learn about supplying data to your templates.
Let's start by creating a template, which can be any kind of markdown, text, xml or markup/HTML that we want to use. For this example our template is going to be HTML, and since I'm feeling creative let's call it my-template.hbs
.
Now, focusing only on the head
of our HTML document, let's add template variables for title
and author
so that we can later replace them with real data:
<!DOCTYPE html>

<title>{{title}}</title>
<meta name="author" content="{{author}}">

Handlebars.js is the default template engine in Assemble, so our variables are wrapped in "Handlebars expressions": {{
and }}
.
Here is an example of what we might put inside of my-template.json
to populate our template with data.
{
"title": "Assemble",
"author": "Brian Woodward"
}
Here is the same in YAML format: my-template.yml
title: Assemble
author: Brian Woodward
And this template:
my-template.hbs

{{ title }}

Or, in cases where we only require simple metadata we can use YAML Front-matter to eliminate the need for an external data file:
---
title: Assemble
author: Brian Woodward
---

{{ title }}

Outputs:

Assemble

Brian Woodward

Furthermore, we can optionally use underscore templates in the YAML front-matter to translate external variables into data inside the content:
---
title: <%= some.title.variable %>
author: <%= some.author.variable %>
---

{{ title }}

{{ author }}

Using data.json
or data.yml
should work, but works a little bit differently than if you put data into a file called myData.json
. When the data is in data.json
, it's loaded directly into the root of the context...
data.json
:
{
"title": "My Title"
}
myTemplate.hbs
:
Data
When used in myData.json
, the data can be accessed through the name of the file...
myData.json
:
{
"title": "My Title"
}
myTemplate.hbs
:
In Assemble, context is the current JSON data object that templates can use.
If you are unfamiliar with how Handlebar templates work, please visit the Handlebar documentation for more information. Also see Assemble's wiki page for Templates and [Data][].
In Handlebars, every template has a context. Blocks such as {{#if}} create "inline" templates, and the "if" helper then determines in which context to render the template.
Some helpers, like {{#if}}, preserve the current context, while others such as {{#each}} and {{#with}} change the context in different ways. Helpers can even change the context to something totally new if they want:
options.fn({
published: true
})
Handlebars also supports nested contexts, making it possible to look up properties nested below the current context. Nested handlebars paths can also include ../
segments, which evaluate their paths against a parent context.
The ..
feature means "look this up on the context of the parent template". In some cases, that will amount to the parent in the current object (with). In other cases, it will not. In cases like if, which preserve the context, .. will happen to point to the same object, but this is just a coincidence. In all cases, ..
is lexically bound to the parent template.
The context object is just a [JSON data][JSON] object that when passed to the compiled template function becomes the value of this inside your template. You must use the name of the associated [data file][Data] to access properties and call helper methods on the context object.
Given we have a data file alert.json
that contains the following properties:
{
"title": "Heads up!"
}
In our template alert.hbs
, we will now look up the properites of alert.json
by using the name of the file, alert
, as the current context. So to retrieve the title
property, we would do this:

{{alert.title}}

Which renders to:

Heads up!

In Assemble, the root of the context is where the data object starts. Everything under the root is a child property. Also, when a variable is at "the root of the context" the variable may be used as-is, or "raw", enabling you to look up properties for the "current" object without nesting the context within the current object. In other words, the "path" of the current object does not need to be appended to the variable, so instead of about_us.title
, you may simply use title
.
In layout.hbs
we will use {{title}}
to lookup the title
property on each page that is passed into the layout.
<!doctype html>

<meta charset="UTF-8">
<title>{{title}}</title>

{{> body }}

When data is added directly to a file named data.json
(or data.yml
) it will be loaded directly into the root of the context by Assemble. Note that your templates will need to be namespaced differently than if you put data into a file called myData.json
.
For example, given we have a file named data.json
with:
{
"title": "My Title"
}
Inside myTemplate.hbs
, we would use:
{{title}}
However, using the same example but with a file named myData.json
, the data must now be accessed using the name of the file.
So, given we have myData.json
with:
{
"title": "My Title"
}
Out template, myTemplate.hbs
, would have:
{{myData.title}}
You can use the this
expression in any context to refer to the current context.
For example (from http://handlebarsjs.com/), inside the {{#each}}
block, you can use this
to reference the element being iterated over.

when used with this context, people.json
:
[
"Jon Schlinkert",
"Brian Woodward"
]
will result in:

Jon Schlinkert

Brian Woodward

Mix and match JSON, YAML, YAML front matter, and data stored in the Gruntfile however you want.
Any of the following data formats may be used:
my-data.json
my-data.yml
Visit the [options.data][options-data] page to learn about supplying data to your templates.
Let's start by creating a template, which can be any kind of markdown, text, xml or markup/HTML that we want to use. For this example our template is going to be HTML, and since I'm feeling creative let's call it my-template.hbs
.
Now, focusing only on the head
of our HTML document, let's add template variables for title
and author
so that we can later replace them with real data:
<!DOCTYPE html>

<title>{{title}}</title>
<meta name="author" content="{{author}}">

Handlebars.js is the default template engine in Assemble, so our variables are wrapped in "Handlebars expressions": {{
and }}
.
Here is an example of what we might put inside of my-template.json
to populate our template with data.
{
"title": "Assemble",
"author": "Brian Woodward"
}
Here is the same in YAML format: my-template.yml
title: Assemble
author: Brian Woodward
And this template:
my-template.hbs

{{ title }}

Or, in cases where we only require simple metadata we can use YAML Front-matter to eliminate the need for an external data file:
---
title: Assemble
author: Brian Woodward
---

{{ title }}

Outputs:

Assemble

Brian Woodward

Furthermore, we can optionally use underscore templates in the YAML front-matter to translate external variables into data inside the content:
---
title: <%= some.title.variable %>
author: <%= some.author.variable %>
---

{{ title }}

{{ author }}

options.data
. YFM is an optional section of valid YAML that is placed at the top of a page and is used for maintaining metadata for the page and its contents.
Actually, YFM can be used with both [pages][pages] and [partials][partials], so unless otherwise noted you can safely assume that when the documentation YFM of a page, the same applies for YFM of a partial.
src
property of a task or target)TOPICS TO COVER
Use cases:
layout
: Optionally define or override the layout to use. You must include file extension, since Assemble can process multiple file types. Layout files can exist in any directory, and may be.published
: set to false
to exclude a file from being rendered by a task-target.category
/categories
/tags
: Define the categories and tags as YAML lists or a space-separated string. for each category and tag, Assemble will generate a page in the dest
directory.If set, allows to specify tags attributed to given entry. Tag pages are generated automatically. Entry may belong to more than one tag, use YAML List to specify multiple tags.
Any variables in the front-matter that are not predefined are mixed into the data that is sent to the Liquid templating engine during the conversion. For instance, if you set a title, you can use that in your layout to set the page title:
<title>{{ page.title }}</title>
This may not be obvious at first, is that YAML Front-Matter acts as a kind of "conduit" for passing information to pages via Lo-Dash templates.
So you could do this:
grunt.initConfig({
assemble: {
component: {
options: {
data: 'page.json'
},
files: {
'index.html': ['src/pages/*.hbs']
}
}
}
});
With page.json
containing:
{
"index": {
"title": "Home"
},
"about": {
"title": "About Us"
}
}
And the YAML Front-Matter of the page, use underscore templates:
---
title: <%= page.index.title %>
---
YAML front matter
Alternatively, inside the Grunfile you can use grunt.config.set
to define the data to be used for a given variable:
grunt.config.set('page.index.title', 'Home');
---
title:
list: <% _.forEach(people, function(name) { %>
<%= name %>
<% }); %>
people:
- Jon Schlinkert
- Brian Woodward
---
<!DOCTYPE html>

<meta charset="UTF-8">
<title>YAML front matter</title>

---
layout: default.hbs
title: Early humans discovered...
description: Lots of things, because they were early humans.
date: 2013-07-04
categories:
- anthropology
- unibrows
- various wooly animals
tags:
- rocks
- wheel
- 30 inch wooden rims
published: false
---
---
title: My Blog
description: Like I said, my bloggg!
example:
custom:
variables:
- one
- two
- three
---

YAML front matter

---
title: <%= component.name ][ pkg.name %
require: [<%= title %>.css, <%= title %>.js]
---

User Settings

My Profile

Friend Requests

Account Settings

Support

Log Out

<!DOCTYPE html>

<meta charset="UTF-8">
<title>{{ titleize component }} Component</title>
<link rel="stylesheet" href="{{assets}}/css/{{component}}.css">

{{> body }}

Use YAML Associative Arrays for rendering lists of information.
Indented Blocks, common in YAML data files, use indentation and new lines to separate the key: value
pairs
---
title: Associative arrays
people:
name: John Smith
age: 33
Inline Blocks, common in YAML data streams, use comma+space to separate the key: value
pairs between braces:
morePeople: {name: Grace Jones, age: 21}
---
Used like this:

{{{title}}}

Associative arrays

{{#people}}

Name:

{{name}}

Age:

{{age}}

{{/people}}
{{#morePeople}}

Name:

{{name}}

Age:

{{age}}

{{/morePeople}}

See some great usage examples in assemble's YAML test files:
Please note: YFM cannot be parsed if it is not the first thing on the page.
YAML Front-Matter was made popular by Jekyll, the "blog-aware, static site generator" that powers GitHub Pages.
---
) and three dashes following (below) (---
).Example:
---
title: YAML front-matter
description: A very simple way to add structured data to a page.
---
"Front matter is essentially metadata about the document its attached to, formatted in such a way that it does not get in the way. In other words, if you don't know its “Front Matter”, you probably wouldn't wonder what it is, or what its doing there."

 {{ title }}

Page content here... {{ eieio }}

Custom Variables
Lo-Dash Templates
.json
or .yaml
data filesYAML is a "human-readable data serialization format" that may be used with Assemble as an alternative to JSON
As a data format, YAML may be used as an alternative to JSON.
YAML front matter was made popular by Jekyll, the "blog-aware, static site generator" that powers GitHub Pages.
YAML front-matter is optionally used at the beginning of a page to define metadata for the page's content. In order for YAML front-matter to be processed, it must be the first thing at the top of the page, and it must be "wrapped" properly using three dashes above (---
) and three below (---
).
More information


Do you want to to go
Additional Details:
Date:
Location:
Additional Details:
List of Items for the event:
This list is empty.
Item:
Quantity:
Here is the list of people planning to attend this event
Delete This Potluck


|
Graphitti
A toolkit/software architecture to ease creating high-performance neural network simulators
|
Public Member Functions | |
| AllSpikingSynapses (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) |
| virtual void | loadParameters () override |
| Load member variables from configuration file. Registered to OperationManager as Operation::op::loadParameters. | |
| virtual void | printParameters () const override |
| virtual void | createEdge (const BGSIZE iEdg, int srcVertex, int destVertex, BGFLOAT *sumPoint, const BGFLOAT deltaT, edgeType type) override |
| virtual bool | allowBackPropagation () |
| virtual void | printSynapsesProps () const |
| Prints SynapsesProps data to console. | |
| virtual void | advanceEdge (const BGSIZE iEdg, IAllVertices *neurons) override |
| virtual void | preSpikeHit (const BGSIZE iEdg) |
| virtual void | postSpikeHit (const BGSIZE iEdg) |
| Public Member Functions inherited from AllNeuroEdges | |
| AllNeuroEdges (const int numVertices, const int maxEdges) | |
| int | edgSign (const edgeType type) |
| Public Member Functions inherited from AllEdges | |
| AllEdges (const int numVertices, const int maxEdges) | |
| virtual void | addEdge (BGSIZE &iEdg, edgeType type, const int srcVertex, const int destVertex, BGFLOAT *sumPoint, const BGFLOAT deltaT) |
| 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 | eraseEdge (const int neuronIndex, const BGSIZE iEdg) |
Static Public Member Functions | |
| static AllEdges * | Create () |
Public Attributes | |
| BGFLOAT * | decay_ |
| The decay for the psr. | |
| BGFLOAT * | tau_ |
| The synaptic time constant [units=sec; range=(0,100)]. | |
| BGFLOAT | tau_II_ |
| BGFLOAT | tau_IE_ |
| BGFLOAT | tau_EI_ |
| BGFLOAT | tau_EE_ |
| BGFLOAT | delay_II_ |
| BGFLOAT | delay_IE_ |
| BGFLOAT | delay_EI_ |
| BGFLOAT | delay_EE_ |
| int * | totalDelay_ |
| The synaptic transmission delay, descretized into time steps. | |
| uint32_t * | delayQueue_ |
| Pointer to the delayed queue. | |
| int * | delayIndex_ |
| int * | delayQueueLength_ |
| Length of the delayed queue. | |
| Public Attributes inherited from AllNeuroEdges | |
| 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_ |
Protected Member Functions | |
| virtual void | setupEdges (const int numVertices, const int maxEdges) |
| virtual void | initSpikeQueue (const BGSIZE iEdg) |
| bool | updateDecay (const BGSIZE iEdg, const BGFLOAT deltaT) |
| defined(USE_GPU) More... | |
| virtual void | readEdge (istream &input, const BGSIZE iEdg) override |
| virtual void | writeEdge (ostream &output, const BGSIZE iEdg) const override |
| bool | isSpikeQueue (const BGSIZE iEdg) |
| virtual void | changePSR (const BGSIZE iEdg, const BGFLOAT deltaT) |
| Protected Member Functions inherited from AllEdges | |
| edgeType | edgeOrdinalToType (const int typeOrdinal) |
Additional Inherited Members | |
| Static Public Attributes inherited from AllNeuroEdges | |
| static constexpr BGFLOAT | SYNAPSE_STRENGTH_ADJUSTMENT = 1.0e-8 |
| The factor to adjust overlapping area to edge weight. | |
| 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 35 of file AllSpikingSynapses.h.
|
overridevirtual |
Advance one specific Synapse.
| iEdg | Index of the Synapse to connect to. |
| neurons | The Neuron list to search from. |
Implements AllEdges.
Reimplemented in AllSTDPSynapses.
Definition at line 280 of file AllSpikingSynapses.cpp.
|
virtual |
Check if the back propagation (notify a spike event to the pre neuron) is allowed in the synapse class.
Reimplemented in AllSTDPSynapses.
Definition at line 336 of file AllSpikingSynapses.cpp.
|
protectedvirtual |
Calculate the post synapse response after a spike.
| iEdg | Index of the synapse to set. |
| deltaT | Inner simulation step duration. |
Reimplemented in AllDSSynapses, and AllDynamicSTDPSynapses.
Definition at line 307 of file AllSpikingSynapses.cpp.
|
overridevirtual |
Create a Synapse and connect it to the model.
| iEdg | Index of the synapse to set. |
| srcVertex | Coordinates of the source Neuron. |
| destVertex | Coordinates of the destination Neuron. |
| sumPoint | Summation point address. |
| deltaT | Inner simulation step duration. |
| type | Type of the Synapse to create. |
Implements AllEdges.
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 180 of file AllSpikingSynapses.cpp.
|
protectedvirtual |
Initializes the queues for the Synapse.
| iEdg | index of the synapse to set. |
Reimplemented in AllSTDPSynapses.
Definition at line 84 of file AllSpikingSynapses.cpp.
|
protected |
Checks if there is an input spike in the queue.
| iEdg | Index of the Synapse to connect to. |
Definition at line 230 of file AllSpikingSynapses.cpp.
|
virtual |
Prepares Synapse for a spike hit (for back propagation).
| iEdg | Index of the Synapse to update. |
Reimplemented in AllSTDPSynapses.
Definition at line 273 of file AllSpikingSynapses.cpp.
|
virtual |
Prepares Synapse for a spike hit.
| iEdg | Index of the Synapse to update. |
Definition at line 246 of file AllSpikingSynapses.cpp.
|
overridevirtual |
Prints out all parameters to logging file. Registered to OperationManager as Operation::printParameters
Reimplemented from AllEdges.
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 121 of file AllSpikingSynapses.cpp.
|
overrideprotectedvirtual |
Sets the data for Synapse to input's data.
| input | istream to read from. |
| iEdg | Index of the synapse to set. |
Reimplemented from AllNeuroEdges.
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 139 of file AllSpikingSynapses.cpp.
|
virtual |
Reset time varying state vars and recompute decay.
| iEdg | Index of the synapse to set. |
| deltaT | Inner simulation step duration |
Reimplemented from AllNeuroEdges.
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 101 of file AllSpikingSynapses.cpp.
|
protectedvirtual |
Setup the internal structure of the class (allocate memories and initialize them).
| numVertices | Total number of vertices in the network. |
| maxEdges | Maximum number of synapses per neuron. |
Reimplemented from AllNeuroEdges.
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 66 of file AllSpikingSynapses.cpp.
|
protected |
defined(USE_GPU)
Updates the decay if the synapse selected.
| iEdg | Index of the synapse to set. |
| deltaT | Inner simulation step duration |
Updates the decay if the synapse selected.
| iEdg | Index of the synapse to set. |
| deltaT | Inner simulation step duration |
Definition at line 321 of file AllSpikingSynapses.cpp.
|
overrideprotectedvirtual |
Write the synapse data to the stream.
| output | stream to print out to. |
| iEdg | Index of the synapse to print out. |
Reimplemented from AllNeuroEdges.
Reimplemented in AllSTDPSynapses, AllDynamicSTDPSynapses, and AllDSSynapses.
Definition at line 161 of file AllSpikingSynapses.cpp.
| int* AllSpikingSynapses::delayIndex_ |
The index indicating the current time slot in the delayed queue Note: This variable is used in GpuSim_struct.cu but I am not sure if it is actually from a synapse. Will need a little help here. -Aaron Note: This variable can be GLOBAL VARIABLE, but need to modify the code.
Definition at line 283 of file AllSpikingSynapses.h.


ifplugd - manual page for ifplugd 1.31.1
BusyBox v1.31.1 (2020-04-30 13:38:01 EDT) multi-call binary.
Network interface plug detection daemon
- -n
- Don't daemonize
- -s
- Don't log to syslog
- -i IFACE
- Interface
- -f/-F
- Treat link detection error as link down/link up (otherwise exit on
error)
- -a
- Don't up interface at each link probe
- -M
- Monitor creation/destruction of interface (otherwise it must exist)
- -r PROG
- Script to run
- -x ARG
- Extra argument for script
- -I
- Don't exit on nonzero exit code from script
- -p
- Don't run "up" script on startup
- -q
- Don't run "down" script on exit
- -l
- Always run script on startup
- -t SECS
- Poll time in seconds
- -u SECS
- Delay before running script after link up
- -d SECS
- Delay after link down
- -m MODE
- API mode (mii, priv, ethtool, wlan, iff, auto)
- -k
- Kill running daemon


--- layout: post title: 'Interim Release: Making SL2 Beta 2 Clients Work With .NET Fx 3.5 SP1 RTM Servers' date: 2008-09-02 19:27:36.000000000 -04:00 type: post published: true status: publish categories: [] tags: - Astoria - Silverlight meta: _encloseme: '1' orig_url: http://blogs.msdn.microsoft.com/b/phaniraj/archive/2008/09/03/interim-release-making-sl2-beta-2-clients-work-with-net-fx-3-5-sp1-rtm-servers.aspx orig_site_id: '7524' orig_post_id: '8920950' orig_parent_id: '8920950' orig_thread_id: '603863' _wds_ratings_users: '0' orig_application_key: phaniraj orig_post_author_id: '56365' orig_post_author_username: PhaniRajuYN orig_post_author_created: Nov 10 2006 05:47:39:000PM orig_is_approved: '1' orig_attachment_count: '0' orig_url_title: http://blogs.msdn.com/b/phaniraj/archive/2008/09/02/interim-release-making-sl2-beta-2-clients-work-with-net-fx-3-5-sp1-rtm-servers.aspx opengraph_tags: | author: login: phanirajuyn email<EMAIL_ADDRESS>display_name: Phani Raju MSFT first_name: '' last_name: '' ---
Cross-posted from here : Interim Release: Making SL2 Beta 2 Clients Work With .NET Fx 3.5 SP1 RTM Servers
As an offshoot of the feedback we got from different channels , ( Blogs , Direct emails to team members , our discussion forums, etc) we are releasing an “interim build” of the data services Silverlight client which works with the Silverlight 2 Beta 2 runtime ,and works with the RTM ADO.NET Data Services Server released as part of .Net Framework 3.5 SP1 RTM.
Download Location : ADO.NET Data Services Silverlight 2 B2 Client Refresh
How did we get here ?
We have different ship vehicles for the client and the server components.
When the Silverlight 2 Beta 2 Client shipped , the ADO.NET Data Services Server which was available was the one from .NET Framework 3.5 SP1 Beta1 and we made the SL client library work with the Server which was available when SL2 Beta 2 shipped.
When the RTM of .NET Framework 3.5 SP1 was released, the Silverlight Client library was still the one from the SL2 Beta 2 release.
The original plan was to ship a Silverlight Client Library for ADO.NET Data Services when Silverlight 2 RTMs. This meant that for a certain period of time , between when 3.5 SP1 RTM and SL2.0 RTM, users would have a Silverlight Client Library for ADO.NET Data Services which would not work with the RTM Server.
You can read more about this here : Compat Note: Silverlight Beta 2 Client & .NET Framework 3.5 SP1 Server Components
What is this release about ?
We took the Silverlight Client Library code that was going be released as part of the SL 2.0 RTM SDK (or almost, you never know when you’re set and won’t touch the bits again) and built it against the SL 2 Beta 2 Runtime and SDK components.This new downloadable assembly will allow your Silverlight applications built against Silverlight 2 Beta 2 to talk to Data Services servers built with the .NET 3.5 SP1 RTM release
Should everyone upgrade to this release of the client library ?
If your client applications are built on SL2 Beta 2 SDK and talk to the ADO.NET Data Services Server released as part of .NET Framework 3.5 SP1 Beta1 , then upgrading to this Assembly will break your client applications. Don’t upgrade unless the Data Services Server is from .NET Framework 3.5 SP1 RTM.
If you want your Silverlight applications built on SL2 Beta 2 SDK to talk to the Astoria Server released as part of the .NET Framework 3.5 SP1 RTM, then you should upgrade to this version of the System.Data.Services.Client Library.
Are there any gotchas to be aware of ?
Yes -- Don’t depend on this “interim release” for your production applications.
Wait until Silverlight 2.0 RTMs to deploy any Silverlight applications that use the System.Data.Services.Client library.
How different is this from the RTM library ?
Well, most of the code is the same as will be shipped in the Silverlight RTM SDK. The difference being that we have to depend on the SL2 Beta 2 Runtime for certain core functionality. So , consider this an early look at something close to what will come later on. Any feedback you give us will only help make the RTM library that much better.
Using the new Assembly
Download the new Silverlight Client Assembly from here : ADO.NET Data Services Silverlight 2 B2 Client Refresh
Installing the New Silverlight Client Assembly
1. Go to the %ProgramFiles%\Microsoft SDKs\Silverlight\v2.0\Libraries\Client folder
2. Backup the older System.Data.Services.Client.dll
3. Replace the older assembly with the new one.
Upgrading your applications to use the new SL Client Assembly
1. Remove any references to the older SL client library in your applications .
2. Compile to make sure that the build fails .
3. Add a reference to the newer SL Client assembly .
4. Compile again to make sure that the build succeeds .
Phani Raj
ADO.NET Data Services Test Team


S3 Storage Features¶
Synapse can use a variety of storage mechanisms to store content, however the most common storage solution is AWS S3. This article illustrates some special features that can be used with S3 storage and how they interact with the Python client.
External storage locations¶
Synapse folders can be configured to use custom implementations for their underlying data storage. More information on this feature can be found here. The most common implementation of this is to configure a folder to store data in a user controlled AWS S3 bucket rather than Synapse’s default internal S3 storage.
The following illustrates creating a new folder backed by a user specified S3 bucket.
Ensure that the bucket is properly configured.
Create a folder and configure it to use external S3 storage:
# create a new folder to use with external S3 storage folder = syn.store(Folder(name=folder_name, parent=parent)) syn.create_s3_storage_location( folder=folder, bucket_name='my-external-synapse-bucket', base_key='path/within/bucket', )
Once an external S3 storage folder exists, you can interact with it as you would any other folder using Synapse tools. If you wish to add an object that is stored within the bucket to Synapse you can do that by adding a file handle for that object using the Python client and then storing the file to that handle.
parent_synapse_folder_id = 'syn123' local_file_path = '/path/to/local/file' bucket = 'my-external-synapse-bucket' s3_key = 'path/within/bucket/file' # in this example we use boto to create a file independently of Synapse s3_client = boto3.client('s3') s3_client.upload_file( Filename=local_file_path, Bucket=bucket, Key=s3_key ) # now we add a file handle for that file and store the file to that handle file_handle = syn.create_external_s3_file_handle( bucket, s3_key, local_file_path, parent=parent_synapse_folder_id, ) file = File(parentId=folder['id'], dataFileHandleId=file_handle['id']) file_entity = syn.store(file)
STS Storage Locations¶
Create an STS enabled folder to use AWS Security Token Service credentials with S3 storage locations. These credentials can be scoped to access individual Synapse files or folders and can be used with external S3 tools such as the awscli and the boto3 library separately from Synapse to read and write files to and from Synapse storage. At this time read and write capabilities are supported for external storage locations, while default Synapse storage is limited to read only. Please read the linked documentation for a complete understanding of the capabilities and restrictions of STS enabled folders.
Creating an STS enabled folder¶
Creating an STS enabled folder is similar to creating an external storage folder as described above, but this time passing an additional sts_enabled=True keyword parameter. The bucket_name and base_key parameters apply to external storage locations and can be omitted to use Synapse internal storage. Note also that STS can only be enabled on an empty folder.
# create a new folder to use with STS and external S3 storage folder = syn.store(Folder(name=folder_name, parent=parent)) syn.create_s3_storage_location( folder=folder, bucket_name='my-external-synapse-bucket', base_key='path/within/bucket', sts_enabled=True, )
Using credentials with the awscli¶
This example illustrates obtaining STS credentials and using them with the awscli command line tool. The first command outputs the credentials as shell commands to execute which will then be picked up by subsequent aws cli commands.
$ synapse get-sts-token -o shell syn123 read_write export SYNAPSE_STS_S3_LOCATION="s3://my-external-synapse-bucket/path/within/bucket" export AWS_ACCESS_KEY_ID="<access_key_id>" export AWS_SECRET_ACCESS_KEY="<secret_access_key>" export AWS_SESSION_TOKEN="<session_token> # if the above are executed in the shell, the awscli will automatically apply them # e.g. copy a file directly to the bucket using the exported credentials $ aws s3 cp /path/to/local/file $SYNAPSE_STS_S3_LOCATION
Using credentials with boto3 in python¶
This example illustrates retrieving STS credentials and using them with boto3 within python code, in this case to upload a file.
# the boto output_format is compatible with the boto3 session api. credentials = syn.get_sts_storage_token('syn123', 'read_write', output_format='boto') s3_client = boto3.client('s3', **credentials) s3_client.upload_file( Filename='/path/to/local/file, Bucket='my-external-synapse-bucket', Key='path/within/bucket/file', )
Automatic transfers to/from STS storage locations using boto3 with synapseclient¶
The Python Synapse client can be configured to automatically use STS tokens to perform uploads and downloads to enabled storage locations using an installed boto3 library rather than through the traditional Synapse client APIs. This can improve performance in certain situations, particularly uploads of large files, as the data transfer itself can be conducted purely against the AWS S3 APIs, only invoking the Synapse APIs to retrieve the necessary token and to update Synapse metadata in the case of an upload. Once configured to do so, retrieval of STS tokens for supported operations occurs automatically without any change in synapseclient usage.
To enable STS/boto3 transfers on all get and store operations, do the following:
Ensure that boto3 is installed in the same Python installation as synapseclient.
pip install boto3
To enable automatic transfers on all uploads and downloads, update your Synapse client configuration file (typically “.synapseConfig” in your $HOME directory, unless otherwise configured) with the [transfer] section, if it is not already present. To leverage STS/boto3 transfers on a per Synapse client object basis, set the use_boto_sts_transfers property.
# add to .synapseConfig to automatically apply as default for all synapse client instances [transfer] use_boto_sts=true # alternatively set on a per instance basis within python code syn.use_boto_sts_transfers = True
Note that if boto3 is not installed, then these settings will have no effect.


INFO: This program is use for export default printer
of Windows as web printer. Only support PDF files currently. VERSION: {{ view.project_version }} AUTHOR: {{ view.project_author }} <{{ view.project_email }}> LICENSE: It's licensed under Apache License 2.0.


Goodreads Recommendation Engine
Github
Wearable Tech Clustering Predictions
Github
E-Commerce Sentiment Analysis
Github
Fraud Detection: Credit Card Data
Github
Nicolas Cage Rating Predictor
Github
Paranormal Romance Title Generator
Github
Web Scraping a Weather Dataset
Github
Labor Statistics Exploratory Data Analysis
Github
Admission Regression Project
Github
MLB Promotion Attendance Regression
Github
Hotel Recommendation Project
Github


From the name of the product (CS-Script) you may
guess that
it is
all
about
C#. The full potential of scripting with the CS-Script engine can be
utilised only when using the C# code. However, it is
impossible not to recognize
that some developers may need to work with
other programming
languages. Therefore CS-Script also provides some
support for other CLR languages (currently JScript, VB.NET, C++/CLI and CC#).
Support for non-C# languages is provided by the means of plug'n'play compilers
(code
providers) implemented as an external assembly. It means that you can
implement your own compiler for non-C# syntax or use any existing one.
The current version of CS-Script code is distributed
with the cs-script/Lib/CSSCodeProvider.dll
assembly which provides access to Microsoft
JScript, VB.NET and C++/CLI compilers. See Implementing
non-C# compilers tutorial for details.
In This Section
- VB.NET
- Information about execution scripts written in VB.NET syntax.
J#
- Information about execution scripts written in J#/JScript syntax.
C++/CLI
- Information about execution scripts written in C++/CLI syntax.
Classless C#
- Information about execution scripts written in special flavor
of C# - classless C# (C# code without class or method
declaration).
- Alternative
compilers
- Description of the concept of the CS-Script Alternative Compilers the foundation of the support for languages other than C#.


{% if ci.identity_claims.count %}
| Service | Identity | |
|---|---|---|
| {{ claim.identity.service }} | {{ claim.identity.identity }} | delete |
You haven't entered any identities yet.
Adding identities will help Tell Trail identify data about you, and apply your policies to its use.
{% endif %}


Mister Oragahn
Junior Member
Registered: Dec 2002
Location:
Posts: 19 |
Power and Resitance calculations - bring as many clues and notes as you can pleez
I guess that now, since each other major sci-fi universe had it done, Stargate also needs its own power calculations to be made, in order to know how powerfull are the weapons we saw (various guns and cannons), how resistant are the shields, hulls and armours, etc...
But to do so, we need clues and notes, be they visual evidence or quotes from the film/show.
For example, I read that the small Goa'uld 3 sided ships' shields could stop an attack up to 2 gigatons.
Another point. I remember that in 48 hours, Teal'c was able to make Tanith's Al-kesh explode with just one shot of a glider staff.
Were the shields of the Al-Kesh raised ?
If yes, what I doubt btw, it would mean that the glider staff is very powerfull, probably beyond logic and continuity.
If no, then it could tell us that the cockpit isn't very protected by the glass and could probably made of some weak alloy.
Anyway, see, if you have notes, numbers, quotes or evidence, bring them here.
Report this post to a moderator | ? + *
|


Welcome to my digital space
I’m Renz Pulvira, I’m a software developer in the Philippines. I like taking film photographs and making keyboards from scratch.
I’m Renz Pulvira, I’m a software developer in the Philippines. I like taking film photographs and making keyboards from scratch.


Champions
League of Legends features an everexpanding roster of champions, each with a unique design and playstyle. Here you can browse the current lineup and find out more about characters that interest you.
League of Legends features an everexpanding roster of champions, each with a unique design and playstyle. Here you can browse the current lineup and find out more about characters that interest you.
Here you can find information about the tons of items in the game.
You can customize your summoner through different summoner spells or runes resulting in thousands of different combinations for your champ so you can find the one that suits your individual playstyle.
Battlefields fall into several primary game modes: Classic and Dominion.  A game of Dominion requires you to hold the majority of capture points on the map to damage the enemy nexus.
The community is massive and very friendly. Join over 100 million active monthly players on their conquest to become the best on the rift. Your friends are probably there too.


My ideal weight is XXX.
My ideal activities is XXX a day.
My ideal Calories is XXX a day
My current weight is XXX.
My current activities is XXX a day.
My current Calories is XXX a day


Cornell University's New Fine Arts Library Opens in Ithaca
- by Eric Baldwin
- about 15 hours
Cornell's new Mui Ho Fine Arts Library has opened in Ithaca, New York for the fall 2019 semester. The opening follows an 18-month renovation of the historic Rand Hall. Housing a circulating collections of fine art and design materials, the library aims to create space for the physical artifact as a durable and irreplaceable academic and creative resource in the visual arts and design disciplines.
The new library is four levels of massed stacks with shelves of books suspended as a centerpiece. The collection is surrounded by new spaces for research, computing, and instruction as well as a reading and study space. As J. Meejin Yoon, Dean of Cornell AAP said, “I think what’s extraordinary about this building is that it will house both a library and a fabrication facility. The production of new knowledge, ranging from scholarship to research and fabrication and making, tying those activities together as all forms of new knowledge is exciting.”
As Cornell explains, the stacks accommodate approximately 100,000 volumes in a configuration forming an inverted ziggurat of books. The four levels are accessible by elevator, stairs, and grated walkways. Free of walls, the transparency across and between levels provides visitors multiple overlapping views across interior spaces and outward to the natural surroundings. Rand Hall is located at a prominent point of entry to Cornell's campus, marking its northern gateway. The 108-year-old industrial building has been entirely rehabilitated and includes a new rooftop deck outfitted with baseplates for the display of temporary experimental structures created by students and faculty.
“This building has an amazing history. Rand Hall is an early example of adaptive reuse for many different programs," says J. Meejin Yoon. "From industrial purposes to engineering and architecture programs and now as a fine arts library above a state-of-the-art fabrication facility. It represents the full spectrum of media and material coming together.” The ground floor of Rand Hall is a new fabrication shop including wood, metal, and digital fabrication shops, a maker space, a research lab, and small-tool repository.
“On the first floor an energetic fabrication space filled with machines, and on the second floor a silent and clean space where more than 100,000 volumes of books are hung between earth and the skies,” said Wolfgang Tschapeller (M.Arch. '87), the project’s design architect and AAP alumnus. “Thus, we have two factories in one building. One is the factory for the material, and one is the factory for thought and concepts — both wrapped by Rand Hall to one interacting volume.” Mui Ho '62 (B.Arch. '66), an architect and educator retired from the University of California–Berkeley, committed $6 million to the library in 2013. The New York City–based STV is the architectural firm of record, with a team led by Harris Feinn (B.Arch. '69, M.Arch. '71).
News via Cornell


Video shows Arizona deputy pinning 15-year-old amputee with no arms or legs to the ground
TUCSON, Arizona (KABC) -- An Arizona sheriff's deputy is under scrutiny over an arrest of a 15-year-old boy with no arms and legs that was caught on video.
The disturbing video shows the quadruple amputee being pinned down by the deputy at a group home in Tucson, where the teen had allegedly been causing a disturbance.
The video shows the boy, struggling to move and screaming as the deputy pins hims to the ground while yelling at him to stop resisting. The teen was arrested but the charges have now been dropped and the incident is under investigation.


For this prototype, you are able to join a room and the game will start after at least 6 people are present and 20 seconds have passed. There are timers set up to advance the game from night into day. There is the start of chat commands (!choose displayName) which will be used in order to have roles use their actions in the game. The role actions and voting themselves are not implemented, but I wanted to make sure the foundation of the game setting up and running itself were in place first.
The goal of this game is to create an engaging Social Deduction game in the style of Mafia/Werewolf where every player has a power role, or a role that allows them to take actions or gain information. Here is some planning for the roles and how the game will plan out.
Role Rules:
There is always one Assassin. In a game of 6, the one evil will always be an assassin
There can only be one of each role
In a game of 12, there will be one of each role
Role Splits
6 Players: 1 Evil, 5 good
7 Players: 2 Evil, 5 good
8 Players: 2 Evil, 6 good
9 Players: 2 Evil, 7 good
10 Players: 3 Evil, 7 good
11 Players: 3 Evil, 8 good
12 Players: 4 Evil, 8 good
Roles and Descriptions
The Medic: Good, Visit at night to heal and prevent death
The Investigator: Good, Visit at night to get the faction of the player (Good or Evil)
The Follower: Good, watch a person to see who they visit
The Observer: Good, watch a person to see who visits them
The Guardian: Good, Protect a player, dying or being poisoned in their place, or Attempt to kill a player.
The Flirt: Good, distract someone at night, stopping their night action
The Vigilante: Good, One bullet, shoots someone at night (one use only)
The Crier: Good, Can talk to all players at night but name is hidden
The Assassin: Evil, Kills once a night
The Phantom: Evil, Can choose to permanently disguise themselves as the player the Assassin kills that night (one use only)
The Chemist: Evil, Poisons a player, the player is notified of being poisoned and dies the next night if they are not healed before then
The Informant: Evil, gets the specific role of a player
Night Actions play out in this order
The Flirt -> The Chemist -> The Medic -> The Guardian -> The Follower -> The Observer -> The Informant -> The Assassin == The Vigilante -> The Phantom
The chemist poisons before the medic heals. If the medic heals the player who is being poisoned, they are notified that they had been poisoned, but that they were healed of the poison. Kills from The Assassin and The Vigilante will happen at the same time, so even if one of these players dies, the kill still happens.


The purpose of this wiki page is to explain benefits of using business processes for your continuous integration (CI) and also to list current integration solutions.
Why jBPM?
jBPM is a flexible business process management suite developed by JBoss community. Business processes can be useful to handle complex CI situations.
- business process can be drafted in a web based process designer, which is part of the jBPM suite
- business process can save your resources like job executors, because for example they can allocate database in advance before actually run the job
- integration with human task service - QA engineer can easily interact with business process instance and decide next execution of the flow, for example based on the results of finished jobs
- human task service and jbpm console can be easily integrated with your corporate infrastructure, like LDAP directory service (necessary for large QA environments)
First two projects are developed by Jiri Svitak, member of jbpm community.
Current integration projects
This project implements a jBPM work item handler, which can be used inside of business processes to remotely control Jenkins jobs using REST API. Process instances are running inside the jBPM console.
This plugin implements a Jenkins build step. Business process engine is embedded and running inside the Jenkins server. The plugin uses jBPM 5.4.0, which is based on the BPMN 2.0 standard.
This project was developed by Tom Huybrechts, but shows no activity for several years. It's based on jBPM 3, which uses its own format jPDL, so nowadays this technology is considered deprecated.


Class: Layout::SketchUpModel
| Relationships | |
| Super Chains via Extension / Inclusion / Inheritance | |
|
Class Chain:
self,
Entity
|
|
|
Instance Chain:
self,
Entity
|
|
| Inherits: |
Layout::Entity
|
Overview
A SketchUp Model entity. This is an instance of a SketchUp Model that is inserted into a .layout file. You can change the render mode, line weight, and set the current scene for the SketchUp Model with this interface.
Constant Summary
-
BACK_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 24
Stub value.
nil
-
BOTTOM_RELATIVE_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 21
Constants
nil
-
BOTTOM_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 22
Stub value.
nil
-
CUSTOM_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 26
Stub value.
nil
-
FRONT_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 28
Stub value.
nil
-
HYBRID_RENDER =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 30
Stub value.
nil
-
ISO_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 32
Stub value.
nil
-
LEFT_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 34
Stub value.
nil
-
RASTER_RENDER =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 36
Stub value.
nil
-
RIGHT_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 38
Stub value.
nil
-
TOP_RELATIVE_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 40
Stub value.
nil
-
TOP_VIEW =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 41
Stub value.
nil
-
VECTOR_RENDER =
# File 'lib/sketchup-api-stubs/stubs/Layout/SketchUpModel.rb', line 43
Stub value.
nil
Class Method Summary
-
.new(path, bounds) ⇒ Layout::SketchUpModel
constructor
The
#initialize
method creates a newSketchUpModel
.
Instance Attribute Summary
-
#camera_modified? ⇒ Boolean
readonly
The #camera_modified? method returns whether the camera of the
SketchUpModel
has been modified. -
#clip_mask ⇒ Layout::Entity
rw
The #clip_mask method returns the clip mask entity for the
SketchUpModel
, ornil
if it does not have one. -
#clip_mask=(clip_mask)
rw
The #clip_mask= method sets a clip mask for the
SketchUpModel
. -
#current_scene ⇒ Integer
rw
The #current_scene method returns the index of the most recently selected scene of the
SketchUpModel
. -
#current_scene=(index)
rw
The #current_scene= method sets the scene of the
SketchUpModel
. -
#current_scene_modified? ⇒ Boolean
readonly
The #current_scene_modified? method returns whether the most recently selected scene of the
SketchUpModel
has been modified. -
#dash_scale ⇒ Float
rw
The #dash_scale method returns the dash scale for the
SketchUpModel
. -
#dash_scale=(dash_scale)
rw
The #dash_scale= method sets the dash scale for the
SketchUpModel
. -
#display_background=(display)
rw
The #display_background= method sets whether the background is displayed for the
SketchUpModel
. -
#display_background? ⇒ Boolean
rw
The #display_background? method returns whether the background is displayed for the
SketchUpModel
. -
#effects_modified? ⇒ Boolean
readonly
The #effects_modified? method returns whether the shadow or fog settings of the
SketchUpModel
have been modified. -
#layers_modified? ⇒ Boolean
readonly
The #layers_modified? method returns whether the layers of the
SketchUpModel
has been modified. -
#line_weight ⇒ Float
rw
The #line_weight method returns the line weight for the
SketchUpModel
. -
#line_weight=(line_weight)
rw
The #line_weight= method sets the line weight for the
SketchUpModel
. -
#perspective=(perspective)
rw
The #perspective= method sets whether the
SketchUpModel
‘s view is perspective or orthographic. -
#perspective? ⇒ Boolean
rw
The #perspective? method returns whether the
SketchUpModel
‘s view is perspective or orthographic. -
#preserve_scale_on_resize=(preserve_scale)
rw
The #preserve_scale_on_resize= method sets whether the scale is preserved when the
SketchUpModel
is resized. -
#preserve_scale_on_resize? ⇒ Boolean
rw
The #preserve_scale_on_resize? method returns whether the scale is preserved when the
SketchUpModel
is resized. -
#render_mode ⇒ Integer
rw
The #render_mode method returns the render mode of the
SketchUpModel
. -
#render_mode=(render_mode)
rw
The #render_mode= method sets the render mode of the
SketchUpModel
. -
#render_needed? ⇒ Boolean
readonly
The #render_needed? method returns whether the
SketchUpModel
needs to be rendered. -
#scale ⇒ Float
rw
The #scale method returns the scale of the
SketchUpModel
. -
#scale=(scale)
rw
The #scale= method sets the scale of the
SketchUpModel
. -
#style_modified? ⇒ Boolean
readonly
The #style_modified? method returns whether the style of the
SketchUpModel
has been modified. -
#view ⇒ Integer
rw
The #view method returns the standard view of the
SketchUpModel
. -
#view=(view)
rw
The #view= method sets the standard view of the
SketchUpModel
.
Entity
- Inherited
| #locked= | The |
| #locked? | The |
| #on_shared_layer? | |
| #style | |
| #style= | |
| #untransformed_bounds | The |
| #untransformed_bounds= | The |
Instance Method Summary
- #entities ⇒ Layout::Entity
-
#model_to_paper_point(model_point) ⇒ Geom::Point2d
The #model_to_paper_point method converts the
::Geom::Point3d
in theSketchUpModel
to a::Geom::Point2d
in paper space. -
#render
The #render method renders the
SketchUpModel
. -
#reset_camera
The #reset_camera method resets the
SketchUpModel
‘s camera to the scene’s setting. -
#reset_effects
The #reset_effects method resets the
SketchUpModel
‘s shadow and fog settings to the scene’s settings. -
#reset_layers
The #reset_layers method resets the
SketchUpModel
‘s layers to the scene’s setting. -
#reset_style
The #reset_style method resets the
SketchUpModel
‘s style to the scene’s setting. -
#scenes ⇒ Array<String>
The #scenes method returns an array of scene names that are available for the
SketchUpModel
.
Entity
- Inherited
| #== | The |
| #bounds | The |
| #document | |
| #drawing_bounds | The |
| #group | |
| #layer_instance | The |
| #move_to_group | |
| #move_to_layer | |
| #page | |
| #transform! | The |
| #transformation | The |
Constructor Details
.new(path, bounds) ⇒ SketchUpModel
The #initialize
method creates a new SketchUpModel
.
Instance Attribute Details
#camera_modified? ⇒ Boolean
(readonly)
The #camera_modified?
method returns whether the camera of the SketchUpModel
has been modified.
#clip_mask ⇒ Layout::Entity (rw)
#clip_mask=(clip_mask) (rw)
#current_scene ⇒ Integer
(rw)
The #current_scene
method returns the index of the most recently selected scene of the SketchUpModel
.
#current_scene=(index) (rw)
LayOut automatically adds the scene “Last Saved SketchUp View” to each SketchUpModel
. This means that the ::Sketchup::Model
‘s scenes start with index 1.
The #current_scene=
method sets the scene of the SketchUpModel
.
#current_scene_modified? ⇒ Boolean
(readonly)
The #current_scene_modified?
method returns whether the most recently selected scene of the SketchUpModel
has been modified.
#dash_scale ⇒ Float
(rw)
The #dash_scale
method returns the dash scale for the SketchUpModel
. A scale value of 0.0 means the dashes are scaled based on the line weight.
#dash_scale=(dash_scale) (rw)
The #dash_scale=
method sets the dash scale for the SketchUpModel
. A scale value of 0.0 or lower will “auto” scale the dashes based on the line weight.
#display_background=(display) (rw)
The #display_background=
method sets whether the background is displayed for the SketchUpModel
.
#display_background? ⇒ Boolean
(rw)
The #display_background?
method returns whether the background is displayed for the SketchUpModel
.
#effects_modified? ⇒ Boolean
(readonly)
The #effects_modified?
method returns whether the shadow or fog settings of the SketchUpModel
have been modified.
#layers_modified? ⇒ Boolean
(readonly)
In SketchUp 2020, SketchUp “layers” were renamed to “tags”. For consistency with the SketchUp API, this will continue to refer to “tags” as “layers”.
The #layers_modified?
method returns whether the layers of the SketchUpModel
has been modified.
#line_weight ⇒ Float
(rw)
The #line_weight
method returns the line weight for the SketchUpModel
.
#line_weight=(line_weight) (rw)
The #line_weight=
method sets the line weight for the SketchUpModel
. Line weight must be at least 0.01.
#perspective=(perspective) (rw)
The #perspective=
method sets whether the SketchUpModel
‘s view is perspective or orthographic.
#perspective? ⇒ Boolean
(rw)
The #perspective?
method returns whether the SketchUpModel
‘s view is perspective or orthographic.
#preserve_scale_on_resize=(preserve_scale) (rw)
The #preserve_scale_on_resize=
method sets whether the scale is preserved when the SketchUpModel
is resized.
#preserve_scale_on_resize? ⇒ Boolean
(rw)
The #preserve_scale_on_resize?
method returns whether the scale is preserved when the SketchUpModel
is resized.
#render_mode ⇒ Integer
(rw)
The #render_mode
method returns the render mode of the SketchUpModel
.
The render mode can be one of the following:
Layout::SketchUpModel::RASTER_RENDER
Layout::SketchUpModel::HYBRID_RENDER
Layout::SketchUpModel::VECTOR_RENDER
#render_mode=(render_mode) (rw)
The #render_mode=
method sets the render mode of the SketchUpModel
.
The render mode can be one of the following:
Layout::SketchUpModel::RASTER_RENDER
Layout::SketchUpModel::HYBRID_RENDER
Layout::SketchUpModel::VECTOR_RENDER
#render_needed? ⇒ Boolean
(readonly)
The #render_needed?
method returns whether the SketchUpModel
needs to be rendered.
#scale ⇒ Float
(rw)
The #scale
method returns the scale of the SketchUpModel
.
#scale=(scale) (rw)
The #scale=
method sets the scale of the SketchUpModel
. Scale must be at least 0.0000001, and the view must be orthographic.
#style_modified? ⇒ Boolean
(readonly)
The #style_modified?
method returns whether the style of the SketchUpModel
has been modified.
#view ⇒ Integer
(rw)
The #view
method returns the standard view of the SketchUpModel
.
The standard view can be one of the following values:
Layout::SketchUpModel::CUSTOM_VIEW
Layout::SketchUpModel::TOP_VIEW
Layout::SketchUpModel::TOP_RELATIVE_VIEW
Layout::SketchUpModel::BOTTOM_VIEW
Layout::SketchUpModel::BOTTOM_RELATIVE_VIEW
Layout::SketchUpModel::FRONT_VIEW
Layout::SketchUpModel::BACK_VIEW
Layout::SketchUpModel::LEFT_VIEW
Layout::SketchUpModel::RIGHT_VIEW
Layout::SketchUpModel::ISO_VIEW
#view=(view) (rw)
The #view=
method sets the standard view of the SketchUpModel
.
The standard view can be one of the following values:
Layout::SketchUpModel::TOP_VIEW
Layout::SketchUpModel::TOP_RELATIVE_VIEW
Layout::SketchUpModel::BOTTOM_VIEW
Layout::SketchUpModel::BOTTOM_RELATIVE_VIEW
Layout::SketchUpModel::FRONT_VIEW
Layout::SketchUpModel::BACK_VIEW
Layout::SketchUpModel::LEFT_VIEW
Layout::SketchUpModel::RIGHT_VIEW
Layout::SketchUpModel::ISO_VIEW
Instance Method Details
#entities ⇒ Layout::Entity
#model_to_paper_point(model_point) ⇒ Geom::Point2d
The #model_to_paper_point
method converts the ::Geom::Point3d
in the SketchUpModel
to a ::Geom::Point2d
in paper space.
#render
#reset_camera
The #reset_camera
method resets the SketchUpModel
‘s camera to the scene’s setting.
#reset_effects
The #reset_effects
method resets the SketchUpModel
‘s shadow and fog settings to the scene’s settings.
#reset_layers
In SketchUp 2020, SketchUp “layers” were renamed to “tags”. For consistency with the SketchUp API, this will continue to refer to “tags” as “layers”.
The #reset_layers
method resets the SketchUpModel
‘s layers to the scene’s setting.
#reset_style
The #reset_style
method resets the SketchUpModel
‘s style to the scene’s setting.
#scenes ⇒ Array<String>
The #scenes
method returns an array of scene names that are available for the SketchUpModel
. The first scene will always be the default scene, called “Last saved SketchUp View”.


Video Player with MediaElementPlayer.js Fallback
Your browser doesn't support HTML5 video or Flash, but you can
download the video
(MP4, 2.4 MB).


| 1 |
Fthenakis_2015 |
Interactions between parasitic infections and reproductive efficiency in sheep |
Fthenakis, G.C.; Mavrogianni, V.S.; Gallidis, E.; Papadopoulos, E. |
2015 |
2015-02-28 |
PMC |
N |
PMC7130998 |
25577675.0 |
10.1016/j.vetpar.2014.12.017 |
cdo7y3ob |
0.791077 |
|
|
| 2 |
Samiullah_2015 |
Eggshell color in brown-egg laying hens — a review |
Samiullah, S.; Roberts, J.R.; Chousalkar, K. |
2015 |
2015-10-01 |
PMC |
N |
PMC7107097 |
26240390.0 |
10.3382/ps/pev202 |
xxhdx8cn |
0.752837 |
|
|
| 3 |
Xie_L_2014 |
Normal Thoracic Radiographic Appearance of the Cynomolgus Monkey (Macaca fascicularis) |
Xie, Liang; Zhou, Qinming; Liu, Shigang; Wu, Qingyuan; Ji, Yongjia; Zhang, Lujun; Xu, Fan; Gong, Wei; Melgiri, Narayan D.; Xie, Peng |
2014 |
2014-01-08 |
COMM-USE |
N |
PMC3885584 |
24416248.0 |
10.1371/journal.pone.0084599 |
231s58eq |
0.740790 |
|
|
| 4 |
Carlson_2008 |
Reproductive Biology of the Coyote (Canis latrans): Integration of Mating Behavior, Reproductive Hormones, and Vaginal Cytology |
Carlson, Debra A.; Gese, Eric M. |
2008 |
2008-06-05 |
PMC |
N |
PMC7108653 |
|
10.1644/06-mamm-a-436r1.1 |
sh59v89y |
0.710281 |
|
Carlson_2009 |
| 5 |
Carlson_2009 |
Influence of exogenous gonadotropin-releasing hormone on seasonal reproductive behavior of the coyote (Canis latrans) |
Carlson, D.A.; Gese, E.M. |
2009 |
2009-10-01 |
PMC |
N |
PMC7103131 |
19631975.0 |
10.1016/j.theriogenology.2009.05.012 |
43m6rdnk |
0.676179 |
Carlson_2008, Sasaki_2017 |
Carlson_2008, Vlčková_2018 |
| 6 |
Peebles_2017 |
Comparative effects of in ovo versus subcutaneous administration of the Marek's disease vaccine and pre-placement holding time on the processing yield of Ross 708 broilers 1 1 This publication is a contribution of the Mississippi Agricultural and Forestry Experiment Station. , 2 2 This material is based upon work that is supported by the National Institute of Food and Agriculture, U.S. Department of Agriculture, Hatch project under accession number 329260. , 3 3 Use of trade names in this publication does not imply endorsement by Mississippi Agricultural and Forestry Experiment Station of these products, nor similar ones not mentioned. |
Peebles, E.D.; Barbosa, T.M.; Cummings, T.S.; Dickson, J.; Womack, S.K.; Gerard, P.D. |
2017 |
2017-11-01 |
PMC |
N |
|
29050405.0 |
10.3382/ps/pex201 |
iugtmdtk |
0.661695 |
Kuehn_1994, Dezfouli_2006, Franklin_2003, Summers_2015 |
|
| 7 |
Novo_2017 |
Effect of maternal cells transferred with colostrum on the health of neonate calves |
Novo, Sylvia Marquart Fontes; Costa, Juliana Fraça dos Reis; Baccili, Camila Costa; Sobreira, Natália Meirelles; Silva, Bruno Toledo; de Oliveira, Pamella Lorenci; Hurley, David John; Gomes, Viviani |
2017 |
2017-06-30 |
PMC |
N |
PMC7127623 |
28187318.0 |
10.1016/j.rvsc.2017.01.025 |
pz2fq3tk |
0.581868 |
Brückmann_2000, Summers_2015, Luebbe_2019 |
Costa_2017, Quigley_2001 |
| 8 |
Jensen_2014 |
Effects of level of social contact on dairy calf behavior and health |
Jensen, Margit Bak; Larsen, Lars Erik |
2014 |
2014-08-31 |
PMC |
N |
PMC7094583 |
24856985.0 |
10.3168/jds.2013-7311 |
31ybwrzc |
0.580217 |
|
Quigley_1995, Donovan_1998, Berge_2009 |
| 9 |
Bean_2008 |
Effects of housing density on Long Evans and Fischer 344 rats |
Bean, Krystal; Nemelka, Kevin; Canchola, Patrick; Hacker, Sander; Sturdivant, Rodney X.; Rico, Pedro J. |
2008 |
2008-01-01 |
PMC |
N |
PMC7091589 |
18719695.0 |
10.1038/laban0908-421 |
bvi590x5 |
0.517303 |
Medinsky_1982, Rommereim_1990 |
Medinsky_1982, Mangham_1987 |
| 10 |
Scanes_2020 |
Chapter 20 Reproductive management of poultry |
Scanes, Colin G.; Butler, Leasea D.; Kidd, Michael T. |
2020 |
2020-12-31 |
PMC |
N |
PMC7153309 |
|
10.1016/b978-0-12-817052-6.00020-3 |
fm3587ww |
0.486614 |
|
|
| 11 |
Tardif_2012 |
Chapter 8 Reproduction and Breeding of Nonhuman Primates |
Tardif, Suzette; Carville, Angela; Elmore, David; Williams, Lawrence E.; Rice, Karen |
2012 |
2012-12-31 |
PMC |
N |
PMC7150151 |
|
10.1016/b978-0-12-381365-7.00008-x |
85jb728w |
0.463336 |
|
Carlson_2008, Fthenakis_2015 |
| 12 |
Burns_2010 |
A review of factors that impact on the capacity of beef cattle females to conceive, maintain a pregnancy and wean a calf—Implications for reproductive efficiency in northern Australia |
Burns, B.M.; Fordyce, G.; Holroyd, R.G. |
2010 |
2010-10-31 |
PMC |
N |
PMC7131258 |
20447780.0 |
10.1016/j.anireprosci.2010.04.010 |
qzw00q1s |
0.429996 |
Stevenson_2011 |
Luebbe_2019, Summers_2015, Fthenakis_2015 |
| 13 |
Costa_2017 |
Innate immune response in neonate Holstein heifer calves fed fresh or frozen colostrum |
Costa, Juliana França Dos Reis; Novo, Sylvia Marquart Fontes; Baccili, Camila Costa; Sobreira, Natália Meirelles; Hurley, David John; Gomes, Viviani |
2017 |
2017-12-31 |
PMC |
N |
PMC7125648 |
28135671.0 |
10.1016/j.rvsc.2017.01.008 |
tlducear |
0.380101 |
|
Novo_2017, Quigley_2001 |
| 14 |
de_Leon_2003 |
Panspermia—true or false? |
de Leon, Samuel Ponce; Lazcano, Antonio |
2003 |
2003-08-02 |
PMC |
N |
PMC7135165 |
12907026.0 |
10.1016/s0140-6736(03)14040-8 |
21htepa1 |
0.345744 |
|
|
| 15 |
Mangham_1987 |
Three-generation toxicity study of rats ingesting Brown HT in the diet |
Mangham, B.A.; Moorhouse, S.R.; Grant, D.; Brantom, P.G.; Gaunt, I.F. |
1987 |
1987-12-31 |
PMC |
N |
|
3692409.0 |
10.1016/0278-6915(87)90295-x |
o5gqnwf6 |
0.314633 |
|
Medinsky_1982, Khan_2018, WANG_2016 |


--- layout: default title: Travel Tech Con 2017 slug: index one_liner: The conference for travel startups and developers. tickets_link: Register tickets_caption: Startup Tickets From $150 endorsement_quote: If you are in the industry and want to understand true innovation, I encourage you to attend Travel Tech Con. endorsement_author: Norm Rose, Travel Tech Consulting hoverboard: This is a hoverboard. Welcome to the future! navigation: - title: TTC url: http://traveltechcon.com/ttc-home - title: Agenda slug: conference-agenda - title: Pitch Competition slug: pitch-competition - title: Workshops slug: workshops - title: Conference Day slug: conference-day ---
{{ page.tickets_caption }}
Get the official conference app and get $10 Lyft discount for the ride to the venue on May 24th
“{{ page.endorsement_quote }}”
{{ page.endorsement_author }}
At Travel Tech Con Pitch competition 20 best travel startups, divided into two cohorts (early-stage and VC-backed), will pitch in front of a panel of esteemed industry experts in order to win amazing prizes from our partners, including a pitch spot at Phocuswright Battleground: The Americas and a ticket to The Phocuswright Conference ($4,199 value).
You can submit your application to pitch below. 500 Startups partners will provide feedback to startups that will come to the training days on May 8th and May 10th.
The 20 startups that will be selected for the finals will be provided with full conference tickets, one ticket per company, plus a discount for other team members.
Coffee, Snacks, Networking
All ticket holders are welcome!
Awesome Bar Nearby
May 24, 5:30 pm at Treasure Island Venue
Workshop is a 1.5-hour long interactive session with the speaker. You have a unique opportunity to learn from the industry experts and connect with them.
Each track is limited to maximum 30 attendees.
Coffee, Snacks, Networking
Full Ticket Required
Boxed Lunch Provided
Awesome Bar Nearby
The main conference day is where it's at. Connect with attendees from top travel industry companies and startups, learn from business and technology experts, talk about real problems and how to solve them.
Coffee, Snacks, Networking
Boxed Lunch Provided
Hawthorn, 46 Geary St.


The bay at Akra Sounion is not a harbour, but can be a useful stop to wait out a meltemi
and to visit the 5th century temple of Poseidon. This is clearly visible on the Cape from a distance and is easily reached after a short walk.
Position 37°39.2' N, 024°01.35' E.
Moor in 5m in the NW corner just below a small chapel where the bottom is sandy.  Make sure the anchor is well dug in as the bay is subject to severe gusts and dragging is common. Beware of some unmarked rocks on the eastern side.
The best time to visit the temple is in the early morning, before the day-trippers arrive. The young Byron is said to have carved his name on one of the columns.
There is a taverna and hotel ashore with a small wooden dock suitable for dinghies.
Gaidouronisa Island, off Cape Sounion
A reasonable alternative to the Sounion anchorage in SW winds, but a bit rolly due to the swell created by passing power boats. Anchor between the fish farm and the beach in 10m over sand.
Lavrion
If wishing to spend longer exploring this peninsula, then the Olympic Marina at Lavrion is a secure and comfortable place to leave the boat. It is approximately 5nm north of Sounion.
Last updated February 2016.


MIT App Inventor
As the name implies, MIT App Inventor was created by Massachusetts Institute of Technology and is an open source initiave that enables young children through adults to create fully funcitonal apps. Being a visual-based program, App Inventor concludes that apps can be built in as little as a half hour. Most noteably, MIT App Invetor is at no cost.
Lightbot
Lightbot is a puzzle-based app that encourages kids to use logic, a skill needed in computer science, to solve the puzzles. There are junior coding puzzles for children ages 4 - 8 and puzzles geared towards children 9 and older. The Junior puzzles are available in the Android, Kindle and Apple stores and the app for the older elmentary and onward age range, is availale in the stores mentioned previously in addition to the Windows and Mac stores.


Testing your installation#
To make sure MNE-Python was installed correctly, type the following command in a terminal:
python -c "import mne; mne.sys_info()"
Hint
If you installed MNE-Python using one of our installers, enter the above command in the Prompt.
This should display some system information along with the versions of MNE-Python and its dependencies. Typical output looks like this:
Platform: Linux-5.0.0-1031-gcp-x86_64-with-glibc2.2.5
Python: 3.8.1 (default, Dec 20 2019, 10:06:11) [GCC 7.4.0]
Executable: /home/travis/virtualenv/python3.8.1/bin/python
CPU: x86_64: 2 cores
Memory: 7.8 GB
mne: 0.21.dev0
numpy: 1.19.0.dev0+8dfaa4a {blas=openblas, lapack=openblas}
scipy: 1.5.0.dev0+f614064
matplotlib: 3.2.1 {backend=QtAgg}
sklearn: 0.22.2.post1
numba: 0.49.0
nibabel: 3.1.0
cupy: Not found
pandas: 1.0.3
dipy: 1.1.1
pyvista: 0.25.2 {pyvistaqt=0.1.0}
vtk: 9.0.0
qtpy: 2.0.1 {PySide6=6.2.4}
If you get an error…
If you see an error like:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'mne'
This suggests that your environment containing MNE-Python is not active.
If you followed the setup for 3D plotting/source analysis (i.e., you
installed to a new mne
environment instead of the base
environment)
try running conda activate mne
first, and try again. If this works,
you might want to set your terminal to automatically activate the
mne
environment each time you open a terminal:
echo conda activate mne >> ~/.bashrc # for bash shells
echo conda activate mne >> ~/.zprofile # for zsh shells
If something else went wrong during installation and you can’t figure it out, check out the Advanced setup instructions to see if your problem is discussed there. If not, the MNE Forum is a good resources for troubleshooting installation problems.