| Prev | Contents | Next |
Knowing what grit is capable of is only the first step. To use it comfortably, you need to know how to integrate it into the standard build process of your project. In this chapter, I'll explain how to do that. First up is, using grit with or without .grit configuration files. After that, I'll show how to use these rules on the standard template makefiles. Finally, I'll describe how to split off the image conversion to a separate process, keeping the interference to the main makefile to a minimum. Part of this is step is also putting the graphics into an archive (.a) and creating a master header file.
The basic format of a grit command is as follows
grit source files options
The list of options start at the first argument that begins with a hyphen, '-'. You have have one or more source files, but you cannot use wildcards. The output file can be specified with the -o flag, but it is not required. If no options are given, grit will try to guess what you meant from the file itself, but this can be a bit dangerous. It is advised to give at least graphics type (-gb/-gt for bitmaps/tiles), bitdepth (-gB num) and probably output filetype as well (-ft type). Examples:
# Single bitmap # Input: foo.bmp # Output: foo.s, 16bpp bitmap as asm array named fooBitmap grit foo.bmp -fts -gb -gB16 # Sprite sheets (32x32p sprites) # Input mario.png, luigi.png # Output: karts.s, 4bpp tiles in 4x4t groups as arrays marioTiles and # luigiTiles, no palette. grit mario.png luigi.png -o karts.s -gt -gB4 -Mw4 -Mh4 -p!
The previous examples would work if you'd enter them on the command-line manually, or via a batchfile. for makefiles, you'd need a little bit extra. The (near) equivalent of the previous examples in makefilese are:
GRIT := grit.exe # foo.bmp -> foo.s ; fooBitmap = 16bpp bitmap. foo.s foo.h : foo.bmp $(GRIT) $< -fts -gb -gB16 # mario.png, luigi.png -> karts.s ; marioTiles, luigiTiles as 4bpp tiles. karts.s karts.h : mario.png luigi.png $(GRIT) $^ -o$* -fts -gt -gB4 -Mw4 -Mh4 -p!
The terms $<
, $^
and $*
are
some of makefile's automatic variables; they stand for the first
prerequisite, all prerequisites and the 'stem' of the targets,
respectively. In these rules, that equates to
$<
= foo.bmp
,
$^
= mario.png luigi.png
and
$*
= karts
.Note that in the second
rule, -o$*
doesn't add an extension. This is alright
because -fts
takes care of that.
I should point out that
the use of $*
is somewhat iffy. Sometimes it works just
fine, but in other cases it's empty, which mucks up everything. Usually,
$@
works just as well.
Having separate rules for each image doesn't exactly scale well. For this reason, grit also allows you to read the flags from configuration files, usually with the .grit extension. With these files, you can put the image-specific options inside the config file and call them with a generalized rule.
You can indicate the config file with the -ff option. For
example, `-ff foo.grit' would read additional options from
foo.grit. The config file uses the '#
' character
for comments, much like makefiles. The config file for foo.bmp
would look something like this:
# # foo.grit : example of a .grit file # -gb # Bitmapped output -gB16 # 16 bpp
The rule to go with this would be something like the following. Here you have a pattern rule that likes a .s and .h file to a .png and .grit file, so that if either the png or grit file is altered, the rule is run again. Technically, there should be a `-ff $*.grit' argument here as well, but grit always looks for an appropriate grit-file automatically, so I can omit it here.
Note that the -fts option is still in the rule itself. The extra options from the .grit-file are simply added to the set of command-line options; they do not replace them.
# Main rule.
%.s %.h : %.png %.grit
$(GRIT) $< -fts
This procedure works out nice if you have lots of different options for different files, but when you have a great many images that use the same conversion, you really don't want to have to write grit-files for each image. It would be preferable to have a single grit-file that can be used by all.
In most cases, you'd have to write explicit rules for this because you can't get the name of the grit-file from the names of the images. There is one exception to this, namely when you have a whole directory of images. If you then base the name of the grit-file on the directory name (say, dir/dir.grit), you can use this:
# Using dir.grit for a whole directory.
%.s %.h : %.png
$(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit
The tricky part is `$(<D)/$(notdir $(<D)).grit'. This takes the directory part of a source image and turns it into a full path for the grit-file. For example, for /c/stuff/dir/foo.png, it gives /c/stuff/dir/dir.grit.
The single-file rule (`%.png %.grit') and the directory rule (`%.png') can work in the same makefile, but you do have to be little careful with it. When make checks for matching files to rules, it'll use the first rule that gives a match. You need to have the single-file rule before the directory-rule. In that case the single-file rule is used if a png-file does have an accompanying grit-file, but it'll fall back on the directory-rule if it's absent. If you reversed the order of the rules, it'd always use the directory-rule, which is probably not what you'd want.
These rules are for .png files. You can create similar rules of other image types, obviously.
In a makefile, if a prerequisite or combination of prerequisites follows more than one rule, the first rule that fits is used. So order the grit rules like this:
# With matching grit-file %.s %.h : %.png %.grit $(GRIT) $< -fts # No grit-file: try using dir.grit %.s %.h : %.png $(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit
The standard practice for building gba/nds homebrew apps nowadays is to use the template makefiles that come with the devkitPro distribution, or derivatives thereof. These makefiles may have to be altered in several places to make them work for grit. Here is a summary of you may need to do.
The GRAPHICS variable is for graphics what SOURCES is for the source files: it's a list of all the directories with graphics. Technically, creating a GRIT variables isn't required, but it can be useful if you have different grit versions around. Add GRIT somewhere at the top, near the inclusion of gba_rules or nds_rules, and GRAPHICS near SOURCES.
include $(DEVKITARM)/ds_rules
GRIT := grit
# ... stuff ...
TARGET := $(notdir $(CURDIR))
BUILD := build
SOURCES := source
DATA := data
INCLUDES := include
GRAPHICS := gfx
The graphics directory also needs to be added to VPATH:
export VPATH := $(foreach dir, $(SOURCES), $(CURDIR)/$(dir)) \ $(foreach dir, $(DATA), $(CURDIR)/$(dir)) \ $(foreach dir, $(GRAPHICS), $(CURDIR)/$(dir))
Next, we need a list of all the graphics files. This is the analogon of CFILES for the C sources, and it's placed in the same spot.
CFILES := $(foreach dir, $(SOURCES), $(notdir $(wildcard $(dir)/*.c))) CPPFILES := $(foreach dir, $(SOURCES), $(notdir $(wildcard $(dir)/*.cpp))) SFILES := $(foreach dir, $(SOURCES), $(notdir $(wildcard $(dir)/*.s))) BINFILES := $(foreach dir, $(DATA), $(notdir $(wildcard $(dir)/*.*))) GFXFILES := $(foreach dir, $(GRAPHICS), $(notdir $(wildcard $(dir)/*.png)))
If you want BMPs as well, you can add them here in the same way, only
with +=
instead of :=
.
This is the trickiest step. OFILES lists all the object (.o) files that the build creates, and it will run along these files in the order they're listed. For this reason, the object files of the GFXFILES must occur before those of the cpp/c/s files. If not, make will try to compile/assemble the files that grit creates before they're actually created. yet.
## NOTE: add the GFXFILES line before the sources!!! export OFILES := $(addsuffix .o,$(BINFILES)) \ $(GFXFILES:.png=.o) \ $(CPPFILES:.cpp=.o) $(CFILES:.c=.o) $(SFILES:.s=.o)
Finally, add the rules for grit conversion that I gave before. The best place to add these are at the bottom of the makefile; somewhere after the $(OUTPUT) lines, but before the dependencies.
# With matching grit-file %.s %.h : %.png %.grit $(GRIT) $< -fts # No grit-file: try using dir.grit %.s %.h : %.png $(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit -include $(DEPENDS) endif
For other image filetypes, add similar rules with those extensions.
Adding the rules to the main makefile works, but it has a number of disadvantages. First, of course, is that you have to change the makefile, and this can be tricky in itself for those new to makefiles. Tied to that is the fact that the order of the changes matters as well. Finally, it makes it harder to create specialized rules. The rules I created above process one image at a time, but sometimes you really need to have multiple sources, like when sharing palettes or tilesets.
In many ways, it'll be easier to handle image conversion as a completely separate process, to be done before any real source files are done. Not only are you more in control of the build order, but you can also do all the unseemly steps that you may require in image processing without it upsetting main makefile itself.
In this section, I'll illustrate how you can convert the images in different ways and archive the output into a resource library to be linked into the project like any other lib. I'll also show how you can combine the separate headers into a master header, which makes #including the declarations considerably easier. This is one step that would simply be impossible if you'd use a single makefile.
Splitting of the graphics conversion involved the use of a second makefile which I call gfxmake. Here it is in full.
# # Making a gfx library from grit output # # For use on data-arrays only. NO CODE!!! # # --------------------------------------------------------------------- # SETUP # --------------------------------------------------------------------- export PATH := $(DEVKITARM)/bin:$(PATH) GRIT := grit.exe .SUFFIXES: include $(DEVKITARM)/base_rules # --------------------------------------------------------------------- # (1) PROJECT DETAILS # --------------------------------------------------------------------- # GFXTITLE : Graphics library name # BUILD : Directory for build process temporaries. Should NOT be empty! # GFXDIRS : List of graphics directories # GFXEXTS : Graphics extensions. # General note: use . for the current dir, don't leave them empty. BUILD := build GFXDIRS := gfx level1 palmerge smkkarts GFXLIB ?= libgfx.a GFXHDR ?= all_gfx.h GFXEXTS := png bmp # --- Exceptions --- # Add files/file-variables for special rules here. Put the rules # At the bottom of the makefile. Be careful with directories, as # we'll be in $(BUILD) when converting. # GFXSPECIALS : removed from GFXFILES # OSPECIALS : added to OFILES export LOZLEVEL1 ?= $(notdir $(wildcard level1/*.png)) export PALMERGE ?= $(notdir $(wildcard palmerge/*.png)) # Key exception variables export GFXSPECIALS := $(LOZLEVEL1) $(PALMERGE) OSPECIALS := level1.o palmerge.o # --------------------------------------------------------------------- # BUILD FLAGS # --------------------------------------------------------------------- # Since there's no code to compile, we won't need optimizations, # architectures etc. CFLAGS := CXXFLAGS := $(CFLAGS) -fno-rtti -fno-exceptions ASFLAGS := # --------------------------------------------------------------------- # (2) BUILD PROCEDURE # --------------------------------------------------------------------- ifneq ($(BUILD),$(notdir $(CURDIR))) # still in main directory. export TARGET := $(CURDIR)/$(GFXLIB) export VPATH := $(foreach dir, $(GFXDIRS), $(CURDIR)/$(dir)) export DEPSDIR := $(CURDIR)/$(BUILD) GFXFILES := $(filter-out $(GFXSPECIALS), \ $(foreach dir, $(GFXDIRS), \ $(foreach ext, $(GFXEXTS), \ $(notdir $(wildcard $(dir)/*.$(ext))) \ ))) export OFILES := $(addsuffix .o, $(basename $(GFXFILES))) $(OSPECIALS) # --- More targets ---------------------------------------------------- .PHONY: $(BUILD) clean # --- Create BUILD if necessary, and run this makefile from there --- $(BUILD): @[ -d $@ ] || mkdir -p $@ @make --no-print-directory -C $(BUILD) -f $(CURDIR)/gfxmake all : $(BUILD) clean: @echo clean ... @rm -fr $(BUILD) $(TARGET) $(GFXHDR) # --------------------------------------------------------------------- else DEPENDS := $(OFILES:.o=.d) .PHONY : all all : $(TARGET) $(GFXHDR) $(TARGET) : $(OFILES) @echo Archiving into $(notdir $@) -@rm -f $@ @$(AR) rcs $@ $(OFILES) $(GFXHDR) : $(OFILES) @echo "Creating master header: $@" @$(call master-header, $@, $(notdir $(^:.o=.h)) ) # --------------------------------------------------------------------- # (3) BASE CONVERSION RULES # --------------------------------------------------------------------- # --- With separate .grit file --- %.s %.h : %.png %.grit $(GRIT) $< -fts %.s %.h : %.bmp %.grit $(GRIT) $< -fts %.s %.h : %.pcx %.grit $(GRIT) $< -fts %.s %.h : %.jpg %.grit $(GRIT) $< -fts # --- Without .grit file ; uses dirname/dirname.grit for options --- %.s %.h : %.png $(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit %.s %.h : %.bmp $(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit %.s %.h : %.pcx $(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit %.s %.h : %.jpg $(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit # --------------------------------------------------------------------- # (4) SPECIAL RULES # --------------------------------------------------------------------- level1.s level1.h : level1.grit $(LOZLEVEL1) @echo $(notdir $^) $(GRIT) $(sort $(filter %.png,$^)) -o$@ -ff $< palmerge.s palmerge.h : palmerge.grit $(PALMERGE) @echo $(notdir $^) $(GRIT) $(filter %.png,$^) -o$@ -ff $< # --------------------------------------------------------------------- # (5) UTILITY FUNCTIONS # --------------------------------------------------------------------- ## Merge all headers into a single large one for easier including. define master-header # $1 : master path, $2 separate header paths echo -e "//\n// $(notdir $(strip $1))\n//" > $1 echo -e "// One header to rule them and in the darkness bind them" >> $1 echo -e "// Date: $(shell date +'%F %X' )\n" >> $1 echo -e "#ifdef __cplusplus\nextern \"C\" {\n#endif" >> $1 cat $2 >> $1 echo -e "\n#ifdef __cplusplus\n};\n#endif\n" >> $1 endef ## if you just want to include the separate headers, use this instead of cat: # for hdr in $2 ; \ # do echo -e "#include \"$$hdr\"" >> $1 ; done; # --- odds and ends --- ## Get the title-part of filename. define title # $1: filepath $(basename $(notdir $1)) endef ## Get a valid C identifier for a name. define cident # $1: name `echo $1 | sed -e 's|^\([0-9]\)|_\1| ; s|[./\\-]|_|g'` endef ## Create a header file for a bin2s converted binary. define bin-header # $1: path, $2: identifier echo "extern const u32 $(strip $2)_size;" > $1 echo "extern const u8 $(strip $2)[];" >> $1 endef # --------------------------------------------------------------------- # DEPENDENCIES # --------------------------------------------------------------------- -include $(DEPENDS) endif
The gfxmake makefile is divided into a number of sections, of which the five numbered ones are the most important.
Under project details, you can find the most relevant items for the
graphics conversions. The BUILD
variable is the directory
that the converted items go into and GFXDIRS
are the
directories where the graphics are. The next two variables,
GFXLIB
and GFXHDR
are the names of the
graphics library and master header that gfxmake
creates.
GFXEXTS
are the extensions used for the images.
The subsection under exceptions
can be ignored for now.
The variables given there are excluded from the GFXFILES
and OFILES
, so that they can be built from custom rules.
Here the variables GFXFILES
and OFILES
are created, much like it was done in the template makefile. Note
that because we're not mixing code and data, the order of listing
in OFILES
is not important.
Note the use of GFXSPECIALS
and OSPECIALS
here. The names under GFXSPECIALS
are filtered out
of GFXFILES
because I want their conversion procedure
to follow special rules. The object files created in those rules
still have to be added to the OFILES
, of course,
and that's what OSPECIALS
is for.
Under the else
, right before the Rules section, are the
main targets. The target itself is the library file given by
GFXLIB
, which in this case is called libgfx.a.
There is also a rule to make the master header, GFXHDR
.
The latter rule uses a user defined function
master-header
, which I'll get to shortly.
These are the same rules as before, in the same order. I've already added versions for some other popular graphics types, but more could be added if required. All these rules use assenbly for their output because assembly can be converted to object files a hell of a lot faster than C sources. Since you probably never need to browse through the generated files, assembly should be the better option here.
There is an interesting point that may be worth mentioning about
how make goes about using these rules to turn graphics into
assembly into objects. The rules here go from .png in
PNGFILES
to .s, but nowhere are the .s
files mentioned explicitly. Only the o. files they become
are given (under OFILES
). Basically, the .s
files are implicit temporaries, and what make does in such a
case is to remove the temporaries at the end. Only after
running through the rules a second time will the assembly files
remain in existence.
It's a bit odd, I know but that's how it is. This can be more than a little annoying if you want to do something else to those files later, so consider yourself warned.
The normal rules will convert single images into single assembly/object files. For something like sharing tilesets among different maps, this simply won't do. For such occasions, you have to use explicit rules of some kind.
gfxmake makes this process easier through the
GFXSPECIALS
and OSPECIALS
variables. Files
added to GFXSPECIALS
won't follow the standard rules,
but can be redirected to your own custom rules. In this
particular case, I have all the rooms from the first dungeon in
Zelda 1 in the level1
directory, and I want to
convert the maps with a shared tileset. The steps of interest for
that are the following.
# Create a variable with the level1 filenames export LOZLEVEL1 ?= $(notdir $(wildcard level1/*.png)) # Add the sources to GFXSPECIALS and the output file to OSPECIALS export GFXSPECIALS := $(LOZLEVEL1) OSPECIALS := level1.o # Rule to for the conversion level1.s level1.h : level1.grit $(LOZLEVEL1) @echo $(notdir $^) $(GRIT) $(sort $(filter %.png,$^)) -o$@ -ff $<
Once GFXSPECIALS
and OSPECIALS
are set up,
you can do with those files whatever you like. The custom rule looks
similar to rule for the karts from before, except that now there is a
grit-file as well. Unfortunately, I do need some makefile trickery to
get it all done. To get the list of sources from the prerequisites, I
need to filter for .pngs only. The sort is somewhat optional,
but recommended as well. Another thing I'm doing here is to place
the grit-file first in the list. This enables me to get its name
with $<
, rather than having to filter it out as well.
make allows you to create your own functions as well.
These can help in doing special things. Though the others are useful
as well, the only one I make actual use of in this
gfxmake is master-header
:
# Merge all headers into a single large one for easier including. define master-header # $1 : master path, $2 separate header paths echo -e "//\n// $(notdir $(strip $1))\n//" > $1 echo -e "// One header to rule them and in the darkness bind them" >> $1 echo -e "// Date: $(shell date +'%F %X' )\n" >> $1 echo -e "#ifdef __cplusplus\nextern \"C\" {\n#endif" >> $1 cat $2 >> $1 echo -e "\n#ifdef __cplusplus\n};\n#endif\n" >> $1 endef # Usage example $(GFXHDR) : $(OFILES) @echo "Creating master header: $@" @$(call master-header, $@, $(notdir $(^:.o=.h)) )
The master-header
function takes two arguments: the path of the
master header that's to be created, and a list of the original headers. It
will create a single header file with a tile-stamped preface and then
copies all the separate headers into it. This means that the output of
gfxmake
is a combination of one header and one archive, which
can be put to use with more ease than a bucketful of separate files.
Of course, even with gfxmake you still need some changes to the template makefile, but they're smaller than adding all of gfxmake functionality into the template. There are two main changes to make.
The first is to add make libgfx.a
and its headers visible. This is done like adding any other library:
add -lgfx
to the LIBS
variable. Technically
you should add the appropriate paths to LIBDIRS
as well,
but since because the files are in the current dir and
BUILD
, this isn't really necessary.
The second is to invoke gfxmake from the main makefile. This comes down to adding a line that calls it to the build rule. The whole thing comes down to something like this.
## Create a gfx library variable GFXLIBS ?= libgfx.a ## Add it to the library list. LIBS := standard libs -lgfx ## Make the .elf depend on the graphics lib(s) $(OUTPUT).elf : $(OFILES) $(GFXLIBS) ## Add line to invoke gfxmake $(BUILD): @[ -d $@ ] || mkdir -p $@ @make --no-print-directory -f $(CURDIR)/gfxmake @make --no-print-directory -C $(BUILD) -f $(CURDIR)/Makefile
And that's about it. I think it should be possible to make it even easier, but this should be enough for now.
Getting grit to work inside your makefile shouldn't be too difficult if you follow these steps. The main thing to remember is to use configuration files and the following makefile rules:
# With matching grit-file %.s %.h : %.png %.grit $(GRIT) $< -fts # No grit-file: try using dir.grit %.s %.h : %.png $(GRIT) $< -fts -ff $(<D)/$(notdir $(<D)).grit
With these rules, you can convert single image either by using a similarly named grit-file, or share a grit-file for a whole directory by naming the grit-file the same basename as the directory. Adding explicit rules is also an option, of course.
You also need to add a few variables to the makefiles for bookkeeping purposes. These have to be added very carefully, because the order sometimes matters. An alternative is to pass the conversion process to another script (makefile or otherwise). This can probably save you a lot of hassle in the long run, which is why I'm using that method in grit's demo project. In the end, of course, what you use is up to you.
| Prev | Contents | Next |
| Grit | Wingrit |


About us
Shop & Roastery
Barista courses
Online shop
Exeter's Independent Coffee Roastery
19 Heavitree Road
Exeter
EX1 2LD
Coffee shop opening hours
M
8am-4pm
T
8am-4pm
W
8am-4pm
Th
8am-4pm
F
8am-4pm
Sa
Closed
Su
Closed
Tweets by execoffeeroast


sim_adtte.Rd
This function simulates survival data with correlated time to progression and overall survival times. Optionally crossover from treatment arms can be simulated.
sim_adtte( rc_siminfo = FALSE, rc_origos = FALSE, id = 1, seed = 1234, rho = 0, pswitch = 0, proppd = 0, beta_1a = log(0.7), beta_1b = log(0.7), beta_2a = log(0.7), beta_2b = log(0.7), beta_pd = log(0.4), arm_n = 250, enroll_start = 0, enroll_end = 1, admin_censor = 2, os_gamma = 1.2, os_lambda = 0.3, ttp_gamma = 1.5, ttp_lambda = 2 )
| rc_siminfo | Should simulation params be included in simulated dataframe (logical). Defaults to FALSE. |
|---|---|
| rc_origos | Should OS without switching be included in simulated dataframe (logical). Defaults to FALSE. |
| id | Identifer added to simulated dataframe. Defaults to 1. |
| seed | Seed used for random number generator. Defaults to 1234. |
| rho | correlation coefficient between TTP and OS. Defaults to 0. |
| pswitch | proportion of patients who switch. Defaults to 0. |
| proppd | proportion of patients with PFS before switch allowed. Defaults to 0. |
| beta_1a | treatment effect (as log(Hazard Ratio)) for OS pre PFS. Defaults to log(0.7). |
| beta_1b | treatment effect (as log(Hazard Ratio)) for OS post PFS. Defaults to log(0.7). |
| beta_2a | treatment effect (as log(Hazard Ratio)) for OS pre PFS (switch). Defaults to log(0.7). |
| beta_2b | treatment effect (as log(Hazard Ratio)) for OS post PFS (switch). Defaults to log(0.7). |
| beta_pd | treatment effect on progression (as log(HR)). Defaults to log(0.4). |
| arm_n | patients per arm. Defaults to 250. |
| enroll_start | start of enrollment. Defaults to 0. |
| os_gamma | weibull shape - for OS. Defaults to 1.2. |
| os_lambda | weibull scale - for OS. Defaults to 0.3. |
| ttp_gamma | weibull shape - for TTP. Defaults to 1.5. |
| ttp_lambda | weibull scale - for TTP. Defaults to 2. |
| enroll.end | end of enrollment. Defaults to 1. |
| admin.censor | end of trial. Defaults to 2. |
The simulation times are derived from formulas in Austin 2012 adapted to enable correlations between endpoints. Austin, P.C. (2012), Generating survival times to simulate Cox proportional hazards models with time‐varying covariates. Statist. Med., 31: 3946-3958. https://doi.org/10.1002/sim.5452
require(survival)#>require(dplyr)#>#> #>#>#> #>#>#> #>


|
|
IFXRenderMaterial Class ReferenceThis interface encapsulates all material settings needed for vertex lighting.
More...
List of all members.
Detailed Description
This interface encapsulates all material settings needed for vertex lighting.
All material settings for vertex lighting must be set through this interface, and then submitted to an IFXRender object with IFXRenderContext::SetMaterial().
- See also:
- IFXRenderContext::SetMaterial()
Constructor & Destructor Documentation
| IFXINLINE IFXRenderMaterial::IFXRenderMaterial |
( |
|
) |
|
|
| IFXINLINE IFXRenderMaterial::~IFXRenderMaterial |
( |
|
) |
[virtual] |
|
Member Function Documentation
| IFXINLINE const IFXVector4 & IFXRenderMaterial::GetAmbient |
( |
|
) |
const |
|
|
|
Gets the ambient material color.
- Returns:
- The ambient material color.
- See also:
- SetAmbient()
|
| IFXINLINE const IFXVector4 & IFXRenderMaterial::GetDiffuse |
( |
|
) |
const |
|
|
|
Gets the diffuse material color.
- Returns:
- The diffuse material color.
- See also:
- SetDiffuse()
|
| IFXINLINE const IFXVector4 & IFXRenderMaterial::GetEmissive |
( |
|
) |
const |
|
|
|
Gets the emissive material color.
- Returns:
- The emissive material color.
- See also:
- SetEmissive()
|
| IFXINLINE BOOL IFXRenderMaterial::GetFastSpecular |
( |
|
) |
const |
|
|
|
Gets whether or not a fast specular calculation is being used.
- Returns:
- Boolean value.
- Return values:
-
| TRUE | The fast specular calculation is being used |
| FALSE | The "correct" specular calculation is being used. |
- See also:
- SetFastSpecular()
|
| IFXINLINE IFXenum IFXRenderMaterial::GetRenderStyle |
( |
|
) |
const |
|
|
|
Gets the currently set render style.
- Returns:
- An IFXenum value.
- Return values:
-
| IFX_FILLED | Polygons are rendered filled (normal). |
| IFX_WIREFRAME | Polygons have their edges rendered only. |
| IFX_POINT | Polygons only have their vertices rendered as points. |
- See also:
- SetRenderStyle().
|
| IFXINLINE IFXenum IFXRenderMaterial::GetShadeModel |
( |
|
) |
const |
|
|
|
Gets the currently set shading model.
- Returns:
- An IFXenum value.
- Return values:
-
| IFX_SMOOTH | Polygons and lines are shaded normally (gouraud shading). |
| IFX_FLAT | Polygons and lines use a single color to fill the interior of the primitive. |
- See also:
- SetShadeModel().
|
| IFXINLINE F32 IFXRenderMaterial::GetShininess |
( |
|
) |
const |
|
|
|
Gets the currently set shininess value.
- Returns:
- The shininess value.
- See also:
- SetShininess()
|
| IFXINLINE const IFXVector4 & IFXRenderMaterial::GetSpecular |
( |
|
) |
const |
|
|
|
Gets the specular material color.
- Returns:
- The specular material color.
- See also:
- SetSpecular()
|
| IFXINLINE BOOL IFXRenderMaterial::GetUseVertexColors |
( |
|
) |
const |
|
|
|
Gets whether or not the lighting system is using vertex colors that are supplied with the mesh.
- Returns:
- Boolean value.
- Return values:
-
| TRUE | The lighting system uses vertex colors. |
| FALSE | The lighting system does not use vertex colors. |
- See also:
- SetUseVertexColors()
|
| IFXINLINE void IFXRenderMaterial::InitData |
( |
|
) |
|
|
|
|
Resets all data to default values.
Default values are:
- Emissive Color: IFXVector4(0,0,0,1)
- Ambient Color: IFXVector4(0.25,0.25,0.25,1)
- Diffuse Color: IFXVector4(0.5,0.5,0.5,1)
- Specular Color: IFXVector4(1,1,1,1)
- Shininess: 0.3
- Fast Specular: TRUE
- Render Style: IFX_FILLED
- Shade Model: IFX_SMOOTH
- Use Vertex Colors: TRUE
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetAmbient |
( |
const IFXVector4 & |
vColor |
) |
|
|
|
|
Sets the ambient material color.
The ambient color is multiplied by the global ambient color and added to the emissive color before any lights in the scene are used for lighting. This is also multiplied by each light's ambient light color and added into the final result.
- Parameters:
-
| vColor | Input IFXVector4 representing the material's ambient color. Color component values are clamped between (0.0 - 1.0). |
- Returns:
- An IFXRESULT error code.
- Return values:
-
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetDiffuse |
( |
const IFXVector4 & |
vColor |
) |
|
|
|
|
Sets the diffuse material color.
The diffuse color is multiplied by each light's diffuse light color and then attenuated according to the light attenuation property and the direction of the vertex normal. This attenuated value is then added into the final lit color of the vertex.
If the mesh that is lit contains per vertex diffuse, this value is ignored.
- Parameters:
-
| vColor | Input IFXVector4 representing the material's diffuse color. Color component values are clamped between (0.0 - 1.0). |
- Returns:
- An IFXRESULT error code.
- Return values:
-
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetEmissive |
( |
const IFXVector4 & |
vColor |
) |
|
|
|
|
Sets the emissive material color.
The emissive color is the color used as a base before any lighting occurs. This will show through even if there are no lights in the scene.
If the mesh contains per vertex diffuse, and the UseLights property is disabled, the diffuse vertex colors will be used instead of this value.
- Parameters:
-
| vColor | Input IFXVector4 representing the material's emissive color. Color component values are clamped between (0.0 - 1.0). |
- Returns:
- An IFXRESULT error code.
- Return values:
-
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetFastSpecular |
( |
BOOL |
bEnabled |
) |
|
|
|
|
Specifies whether or not to use a fast specular calculation.
If this is FALSE, then a vertex to camera vector is calculated for every vertex in the model being lit. If TRUE, then the camera direction vector is calculated once per model and used for every vertex. This has the effect of assuming the camera is an infinite distance away from the model.
- Parameters:
-
| bEnabled | Input BOOL specifying to use fast specular calculation. |
- Returns:
- An IFXRESULT error code
- Return values:
-
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetRenderStyle |
( |
IFXenum |
eStyle |
) |
|
|
|
|
Specifies the rendering style to be used (either filled, wireframe, or points).
- Parameters:
-
| eStyle | Input IFXenum specifying the rendering style to be used. Valid options are:
- IFX_FILLED: Renders normal filled polygons.
- IFX_WIREFRAME: Renders only the edges of polygons.
- IFX_POINTS: Renders a point for every vertex.
|
- Returns:
- An IFXRESULT error code
- Return values:
-
| IFX_OK | No error. |
| IFX_E_INVALID_RANGE | The eStyle parameter is invalid. |
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetShadeModel |
( |
IFXenum |
eShadeModel |
) |
|
|
|
|
Specifies the shading model for polygons and lines (either gouraud shading or flat shading).
Flat shading uses a single color for filling the entire polygon or line. Smooth shading evaluates colors at each vertex, and interpolates between these colors across the polygon or line.
- Parameters:
-
| eShadeModel | Input IFXenum specifying the shading model to be used. Valid options are:
- IFX_SMOOTH: Normal gouraud shading.
- IFX_FLAT: Flat shading.
|
- Returns:
- An IFXRESULT error code.
- Return values:
-
| IFX_OK | No error. |
| IFX_E_INVALID_RANGE | The eShadeModel parameter is invalid. |
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetShininess |
( |
F32 |
fShininess |
) |
|
|
|
|
Sets the material's specular reflectivity exponent.
Specular reflections are calculated based on the light position, the vertex normal, and the camera position. This value is then raised to an exponent to control specular light falloff. A Shininess setting of 1.0 corresponds to an exponent of 128. A shininess of 0 will disable specular lighting.
- Parameters:
-
| fShininess | Input F32 specifying the material shininess. Values are clamped between (0,1) |
- Returns:
- An IFXRESULT error code
- Return values:
-
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetSpecular |
( |
const IFXVector4 & |
vColor |
) |
|
|
|
|
Sets the specular material color.
The specular color is multiplied by each light's specular light color and then attenuated according to the light attenuation properties, the direction of the vertex normal, the direction of the viewer, and the material shininess value. This attenuated value is then added to the final result color AFTER texture maps are applied.
If the mesh being lit contains per vertex specular, this value is ignored.
- Parameters:
-
| vColor | Input IFXVector4 representing the material's specular color. Color component values are clamped between (0.0 - 1.0). |
- Returns:
- An IFXRESULT error code
- Return values:
-
|
| IFXINLINE IFXRESULT IFXRenderMaterial::SetUseVertexColors |
( |
BOOL |
bUserVertexColor |
) |
|
|
|
|
Specifies whether or not to use colors that are attached to the vertex.
This is useful when the mesh contains per vertex color info, but you do not want to use them.
- Parameters:
-
| bUseVertexColor | Input BOOL specifying whether or not to use any per vertex colors associated with the mesh. |
- Returns:
- An IFXRESULT error code.
- Return values:
-
|
Member Data Documentation
© 1999 - 2006 Intel Corporation. All rights reserved.
* Other names and brands may be claimed as the property of others.
|
|


new GOWN.Slider(theme)
Simple slider with min. and max. value
| Name | Type | Description |
|---|---|---|
theme |
GOWN.Theme | optional theme for the slider |
Extends
Members
-
static,readonlyGOWN.Slider.SKIN_NAMEString
-
Default slider skin name
-
allowDestroyCachebool
-
Will destroy the skin cache when the skinable gets destroyed
- Default Value:
- true
-
directionString
-
The scrollable direction
- Default Value:
- Scrollable.HORIZONTAL
-
enabledBoolean
-
Enables/Disables the control. (not implemented yet)
-
heightNumber
-
The height of the Scrollable, setting this will redraw the track and thumb.
-
inverseBoolean
-
Inverse the progress bar
-
maximumNumber
-
Set maximum and update value if necessary
- Default Value:
- 100
-
minimumNumber
-
Set minimum and update value if necessary
- Default Value:
- 0
-
modeString
-
The scrollable mode
- Default Value:
- Scrollable.DESKTOP_MODE
-
scrolldeltaNumber
-
Number of pixels you scroll at a time (if the event delta is 1 / -1)
- Default Value:
- 10
-
skinFallbackString
-
The fallback skin if the other skin does not exist (e.g. if a mobile theme that does not provide a "hover" state is used on a desktop system) (normally the default "up"-state skin)
- Default Value:
- 'up'
-
skinNameString
-
Change the skin name. You normally set the skin name as constant in your control, but if you want you can set another skin name to change skins for single components at runtime.
-
valueNumber
-
Set value (between minimum and maximum)
- Default Value:
- 0
-
widthNumber
-
The width of the Scrollable, setting this will redraw the track and thumb.
Methods
-
inherited changeSkin(skin)
-
Remove old skin and add new one
Name Type Description skin
DisplayObject -
inherited destroy()
-
Destroy the Skinable and empty the skin cache
-
inherited fromSkin(name, callback)
-
Get image from skin (will execute a callback with the loaded skin when it is loaded or call it directly when it already is loaded)
Name Type Description name
String name of the state callback
function callback that is executed if the skin is loaded -
inherited protectedhandleDown(mouseData)
-
Handle mouse down/touch start. Move scroll thumb.
Name Type Description mouseData
mouse data provided by PIXI -
inherited protectedhandleMove(mouseData)
-
Handle mouse move. Moves the thumb.
Name Type Description mouseData
mouse data provided by PIXI -
inherited protectedhandleUp()
-
Handle mouse up/touch end
-
inherited protectedhandleWheel(event)
-
Handle mouse wheel. Moves thumb on track.
Name Type Description event
mouse wheel event from browser -
inherited maxHeight(){Number}
-
Returns the max. height in pixel (normally this.height - thumb height)
Returns:
Type Description Number -
inherited maxWidth(){Number}
-
Returns the max. width in pixel (normally this.width - thumb width)
Returns:
Type Description Number -
inherited mousePos(){PIXI.Point}
-
Get the local mouse position from PIXI.InteractionData
Returns:
Type Description PIXI.Point -
inherited moveThumb(x, y){boolean}
-
Move the thumb on the scroll bar within its bounds
Name Type Description x
Number New x position of the thumb y
Number New y position of the thumb Returns:
Type Description boolean Returns true if the position of the thumb has been moved -
inherited pixelToValue(position){Number}
-
Calculate value of slider based on the current pixel position of the thumb
Name Type Description position
Number current pixel position of the thumb Returns:
Type Description Number Value between minimum and maximum -
inherited positionThumb(value)
-
Position the thumb to a given value
Name Type Description value
Number The value to which the thumb gets moved -
inherited preloadSkins()
-
Initiate all skins first
-
inherited protectedredraw()
-
Update before draw call. Redraw track and progressbar and create thumb.
-
inherited scrollToPosition()
-
Scroll to a specific position (not implemented yet)
-
inherited setTheme(theme)
-
Change the theme
Name Type Description theme
GOWN.Theme the new theme -
inherited thumbMoved(x, y)
-
Thumb has new x/y position
Name Type Description x
Number x-position that has been scrolled to (ignored when vertical) y
Number y-position that has been scrolled to (ignored when horizontal) -
inherited updateTheme(data)
-
Overwrite data from theme for this specific component. (usable if you want to change e.g. background color based on selected items)
Name Type Description data
updated skin data -
inherited valueToPixel(value){Number}
-
Calculate current pixel position of thumb based on given value
Name Type Description value
Number The value of the thumb position Returns:
Type Description Number Position of the scroll thumb in pixel


Computes isotropic and fast-motional cw EPR spectra of radicals in solution.
garlic(Sys,Exp) garlic(Sys,Exp,Opt) spec = garlic(...) [B,spec] = garlic(...)
See also the user guide on how to use garlic
.
garlic
computes isotropic and fast-motional cw EPR spectra of douplet radicals
in solution, i.e., of spin systems with an electron spin S=1/2 coupled to an
arbitrary number of nuclear spins I>=1/2 with small hyperfine couplings.
The composition of the spin system is specified in Sys
,
and the experimental settings are given in Exp
.
garlic
then returns the spectrum in spec
and,
if requested, a field range vector in B
(in units of mT).
If neither B
nor spec
are requested, garlic
plots the simulated spectrum. garlic
can also simulate frequency-swept spectra.
The following table lists all possible fields in the spin system structure Sys
.
Note that Sys
here contains only a few fields of the general spin system structure
as used by functions like pepper and salt.
All fields except n
are mandatory.
g
Sys.g = 2.005; % isotropic g Sys.g = [2.001 2.004]; % axial g Sys.g = [2.001 2.002 2.004]; % orthorhombic g
Nucs
Sys.Nucs = '1H,13C'
.
n
Sys.n = [2,3]
, if the spin system contains
two 1H and three 13C nuclei. Can be omitted
if all nuclei in Sys.Nucs
occur only once.
A
Sys.A = [10 52]
.Sys.A = [15 15 40;-4 -3 7]
for two nuclei.
lwpp
GaussianPP
.[GaussianPP LorentzianPP]
.lw
GaussianFWHM
.[GaussianFWHM LorentzianFWHM]
.
For simulations in the fast motional regime, the principal values of the g and all A tensors
have to be given. One more parameter in Sys
specifies the speed of the rotational motion:
tcorr
, scalartcorr
is omitted or set to zero, the isotropic limit spectrum is computed.
For isotropic rotational motion, the correlation time tcorr
and the diffusion rate D
are related by tcorr = 1/(6*D)
.
Anisotropic diffusion is not supported.
logtcorr
tcorr
is ignored.
If tcorr
or logtcorr
is given, the fast-motional spectrum is computed. The necessary line widths
are computed via the function fastmotion (for details see
there). The resulting
spectrum is additionally broadened by Lorentzian and Gaussian broadenings specified in Sys.lw
using convolution, just as in the isotropic case.
If the inverse of the correlation time becomes similar in magnitude to the spectral anisotropy, the fast-motional model used by garlic
(via fastmotion) is not valid anymore.
For simulating a multi-component mixture, Sys
should be a cell array of spin systems,
e.g. {Sys1,Sys2}
for a two-component mixture. Each of the component spin systems should
have a field weight
that specifies the weight of the corresponding component in the final
spectrum.
The experiment structure Exp
contains all parameters relating to the experiment. These settings are identical for all cw EPR simulation functions (pepper, chili, garlic). See the page on cw EPR experimental parameters.
The structure Opt
collects computational parameters. Opt
need not be specified, in which case default values for all fields are used. The field names and their possible values are listed below.
Method
: 'exact'
, 'perturb1'
, 'perturb2'
, 'perturb3'
, 'perturb4'
, 'perturb5'
'exact'
, which is also the default, indicates the Breit-Rabi method. This gives exact resonance fields for each single nucleus, which are then combined to give the total spectrum. Cross-nuclear terms are neglected.
'perturb1'
etc. indicate the order of perturbation theory (1st through 5th) to be used to calculate the single-nucleus resonance fields. Cross-nuclear terms are neglected as well. Apart from demonstration purposes, there is no reason to use perturbation theory.
If cross-nuclear terms are anticipated to be significant (e.g. in a 250 MHz EPR spectrum of a radical containing a nucleus with a hyperfine coupling of 100 MHz and other nuclei), then use pepper with matrix diagonalization (Opt.Method='matrix'
instead of garlic
.
Verbosity
: 0, 1, or 2garlic
prints to the command window. If Opt.Verbosity=0
, garlic
is silent. 1 logs relevant information, 2 gives more details.
IsoCutoff
: scalarIsoCutoff
is 1e-6.
AccumMethod
:
''
(default), 'binning'
, 'explicit'
, 'template'
Determines how the spectrum is constructed once all the line positions, intensities and widths are calculated.
''
indicates that garlic
will automatically choose the optimal method for the given simulation.
'explicit'
instructs garlic
to explicitly evaluate the line shape functions (Gaussian, Lorentzian) for every single line in the spectrum and add them up. This is the most accurate, but also by far the slowest method.
'binning'
tells garlic
to first construct a stick spectrum with delta peaks, and then convolute it with the requested broadening line shape. This method is the fastest, but can run into problems if the Gaussian or Lorentzian linewidth is on the order of, or smaller than, the field increment. In these cases, either use another accumulation method, increase the number of points in the spectrum (Exp.nPoints
), or increase the linewidth. 'binning'
does not work for simulations in the fast-motion regime, since there each line has a different linewidth.
'template'
instructs garlic
to build the spectrum by pre-computing a high-resolution version of the broadening line shape function and then use it as a template to interpolatively construct the total spectrum from it. This method is almost as accurate as the 'explicit'
method, but significantly faster. Still, in situations with very many peaks, it can be quite slow. This won't work for simulations in the fast-motion regime, since there each line has a different linewidth.
To compute resonance fields, garlic
uses a fixed-point iteration based on the exact Breit-Rabi solutions for a S=1/2 with an arbitrary nuclear spin. This is superior to using perturbation expressions, since it gives resonance field values accurate to within numerical error. For multi-nuclear spin systems, cross-terms between nuclei are neglected, so the Breit-Rabi solver is not exact in that case.
Only allowed transitions are computed. If the hyperfine couplings are too large, garlic
will refuse to run. All transition intensities are assumed to be equal.
Sets of equivalent nuclei are transformed into a coupled representation (see equivcouple). Non-equivalent groups of equivalent nuclei are treated sequentially, i.e. cross terms are neglected.
For the computation of fast-motional line widths, the function fastmotion is used.
Spectra from systems with many nuclei are easily simulated.
Sys = struct('g',2,'Nucs','1H,14N','A',[30,40],'n',[5 4]); Sys.lwpp = [0 0.1]; % only Lorentzian broadening Exp = struct('mwFreq',9.7); garlic(Sys,Exp);To simulate a radical spectrum with its 13C satellite lines, just specify
'C'
instead of '13C'
for the carbon nucleus,
and EasySpin will automatically simulate the spectra of all isotope combinations,
in this case 98.93% with 12C and 1.07% with 13C.
Sys.g = 2; Sys.Nucs = '1H,1H,C'; Sys.n = [2 3 1]; Sys.A = [10 11 3]; Sys.lwpp = [0 0.01]; Exp.mwFreq = 9.7; Exp.CenterSweep = [346.5 2.8]; garlic(Sys,Exp);
Zoom in to see the 13C satellite lines.
A simple example of a spectral simulation in the fast motional regime using the rotational correlation time:
A = mt2mhz([5.8 5.8 30.8]/10); Sys = struct('g',[2.0088 2.0061 2.0027],'Nucs','14N','A',A); Sys.tcorr = 5e-9; Exp = struct('mwFreq',9.5); garlic(Sys,Exp);
esfit, fastmotion, pepper, resfields, resfields_perturb, salt


If you’ve managed OS X for any amount of time, chances are you’ve needed to deploy software. And chances also are that you’ve come across a vendor (I’m looking at you, Adobe) that seems to be incapable of distributing their software in a useful manner. Or maybe you’ve got your own scripts or software that you need to get installed on the machines that you look after - either way, you’re going to want to build a package.
You’ve got a few options - Iceberg, Packages, Composer, you’ve even got Package Maker. However, my personal choice is The Luggage. It has a few advantages over the alternatives:
It’s all text files: You’re building software distributions, you should be checking the files in to build the packages into version control, such as Git. Text files are ideal for checking into version control.
It’s free: if it costs nothing, there’s no reason it can’t be installed on everyone’s machine.
It’s (still) all text files: Want to see what will be in the package without any extra work? Crack open the Makefile and you can see straight away what will be in the package.
The Luggage has a metric buttload of shortcuts built in: it does the hard work, so you don’t have to.
It’s repeatable: Have you ever tried to talk someone through a series of windows and buttons to get the same result as you’re getting? Every time you run The Luggage, you will get the same result.
It’s (really, still) all text files: It’s the most precise tool I’ve used - you only package exactly what you need, no cruft is left behind.
 We’ll be going through more advanced workflows in future posts, but let’s get started with using The Luggage.
Pull down the latest version of crankd (or use a local or remote repository if you specify one)
Build a package that includes crankd and your custom settings and scripts.
I’ve included two examples, one that implements calling Munki and Puppet as detailed in the last post, and one to run a Casper policy.
If you’re happy with what crankd does and using the command line, head on over to the repository and enjoy. If you need a bit more help to get started, read on.
Updated 14/7/2013: After Alister’s suggestion, the script now loops over network interfaces up to en19 (hopefully that’s enough!).
So, you’ve heard of this crankd thing, maybe even had a look at it, but have no idea how to get it going? You’re in the right place. I’m by no means an expert on it, having only been playing with it for less than a week, but I already have it running in production running the simple script below. My initial work, and therefore this post was inspired by Gary Larizza’s twoarticles on the subject.
What is crankd?
It’s part of the PyMacAdmin set of tools that Chris Adams and Nigel Kersten released a while ago. In a nutshell, it runs in the background via a LaunchDaemon and reacts to events on the Mac by running a script or a Python function, class or method. It has loads of events it knows about (application launches, power events, network events etc), but in this case I wanted to run something when there was a network change. Some of our machines never get turned off (and for some reason the Puppet Launch Daemon has crapped out), or aren’t turned on long enough for Puppet or Munki to run. I wanted a script that would run every time the machine came back onto the network, checking if there was an active connection and run Puppet and Munki.
What do I need to do?
There are a few parts that we need to bring together to make this work:
For those of you who attended my talk yesterday at PSU MacAdmins on Managing Macs with Puppet, here are are my slides and all of the code and servers used are up on grahamgilbert/puppet_psu_2013 on GitHub. Please comment, email me or catch me on the twitter if you have any questions about any of this. Hopefully the video will be up soon, so those of you who weren’t there to laugh at the guy with the funny accent can see me dealing with internet fails and my obscure British sit-com references.
At work, we’ve recently changed how we build our bootstrap package to having the main code that connects a Mac to our Puppet infrastructure pulled down from GitHub when the client boots up for the first time.
Why?
This might sound like madness to you. Why would anyone want to do this? We had two main issues to solve:
I got sick of rebuilding our images every time our bootstrap script changed.
Our engineers got sick of downloading the latest version of our package every time they thin / no-imaged a Mac.
Why would our script change so much? In our case, it is to install the latest versions of Puppet and Facter. This isn’t strictly necessary, as we update Puppet and Facter with Munki, but occasionally there will be something in our Puppet config that requires a specific version - for example, when we started configuring usernames on 10.8 Macs with Puppet, the salt parameter was introduced. This required Puppet 3.0.2-ish or higher - which meant that any NetRestore image or old package that contained a version of Puppet lower than this would fail, and the engineer on site was in for a world of pain.
Ok, I’m convinced.
I’ve put an example up on GitHub. This is a sanitised version of the bootstrap script we use at pebble.it. All we do in the script that gets deployed to the client is set the address of our Puppet server and then pull the rest of the script from GitHub - if you don’t need to set any variables, you could do all of the work in the remote script.
So this can be used with all of the deployment methods we use at pebble.it (imaging, createOSXinstallPkg and no imaging), we do the actual work in a script that is triggered by a launch daemon, so we can be sure we’re a) performing the work in a full OS X environment (we need Python to be available for our script) and that we’re running it on the boot volume of the client Mac (we need the serial number, and this could be installed via Target Disk Mode when no-imaging.
So when the bootstrap script needs to be updated, rather than rebuilding the package and distributing it to engineers and baking it into images, the workflow becomes:
Update script, push to GitHub.
Restore image with puppet_bootstrap.pkg baked in or install the package manually.
install_puppet.py downloads and installs the correct versions of Puppet and Facter and configures Puppet.
Puppet downloads, installs and configures Munki along with all of the other configuration.
PROFIT
This clearly isn’t required or suitable for all types of script - but if you have a package that is frequently updated and you have staff installing it by hand, this is a relatively simple way to make sure they’ve got the latest version at all times.


{% extends "base.html" %} {% load staticfiles %} {% block content %}
There is only one API here, which provides full RESTful service on ToDo Items. Purposed to help everyone to test their code to integrate with a RESTful API.
ToDo items are grouped by sessions, you can override the session id by specifying SESSION-ID value in your request header.
There is a maximum rows limit in ToDo table globally to protect the service from being overrun, once maximum rows has reached, it will start evicting oldest items.
Any problems, email james@lin.net.nz


{% extends 'base.html' %} {% block title %} QuizUp - Welcome {% endblock title %} {% block body %}
You have successfully logged in.
Before you play the quiz, take a look at rules


wait()
methods that may occur while the current thread is holding two locks.
Since the call to wait()
releases the only lock on its target,
waiting with two locks held can easily lead to deadlock.
Example:
synchronized (lockA) { synchronized (lockB) { lockB.wait(); //warning //thread A is stuck here holding lockA } } synchronized (lockA) { //thread B can't enter the block and release thread A lockB.notify(); }


Consider a type of binary trees where the nodes are labeled with an arbitrary type A:Set and define the relation "t is the left or right subtree of t'" Show that this relation is well-founded (Please give two different proofs.)
Follow this link


Here we list some of the Data Narratives examples we have been building automatically from different workflows on a web analytics domain:
- Narratives of an image resulting of a topic detection workflow.
- Narratives for the image accessibility analytics depicting the accesses of users to a website.
- Narratives for the result on understanding the user access workflow.
- Narratives for the results of a workflow for trying to identify the problematic users of a website.
- Narratives for the visualization of the trending topic of a website.
Examples from other domains will be added soon


Did you know that...
A Gram-positive, aerobic, nonmotile, toxin-producing, rod-shaped bacteria belonging to the order Actinomycetales, which are typically found in soil, but also have pathogenic members such as streptomyces and mycobacteria. C. diphtheriae is best known for causing the disease Diphtheria in human beings, which results from production of Diphtheria toxin in conjunction with infection by a bacteriophage which provides it with the toxin-producing gene. Because historically it has been a very deadly disease, especially for children where mortality rates before vaccines and antitoxin amounted to nearly 80%, it has been heavily studied. Oddly enough, mice and other rodents are naturally immune to the Diphtheria toxin so it has been difficult to study Diphtheria in the lab.
Corynebacterium diphtheria can cause Deptheria Diphtheria is an infectious disease caused by the bacterium Corynebacterium diphtheriae. This disease primarily affects the mucous membranes of the respiratory tract (respiratory diphtheria), although it may also affect the skin (cutaneous diphtheria) and lining tissues in the ear, eye, and the genital areas.


Tools for detecting cellwise outliers and robust methods to analyze data which may contain them.
| Version: | 2.0.10 |
| Depends: | R (≥ 3.2.0) |
| Imports: | reshape2, scales, ggplot2, matrixStats, gridExtra, Rcpp (≥ <IP_ADDRESS>) |
| LinkingTo: | Rcpp, RcppArmadillo (≥ 0.7.600.1.0) |
| Suggests: | knitr, robustHD, robustbase, rrcov, MASS, svd, ellipse |
| Published: | 2018-06-25 |
| Author: | Jakob Raymaekers [aut, cre], Peter Rousseeuw [aut], Wannes Van den Bossche [aut] |
| Maintainer: | Jakob Raymaekers <jakob.raymaekers at kuleuven.be> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| NeedsCompilation: | yes |
| CRAN checks: | cellWise results |
| Reference manual: | cellWise.pdf |
| Vignettes: |
DDC examples Wrap examples |
| Package source: | cellWise_2.0.10.tar.gz |
| Windows binaries: | r-devel: cellWise_2.0.10.zip, r-release: cellWise_2.0.10.zip, r-oldrel: cellWise_2.0.10.zip |
| OS X binaries: | r-release: cellWise_2.0.10.tgz, r-oldrel: cellWise_2.0.10.tgz |
| Old sources: | cellWise archive |
| Reverse imports: | GSE, OutliersO3 |
Please use the canonical form https://CRAN.R-project.org/package=cellWise to link to this page.


- Intel 8700K
- RTX 2080
- 16GB DDR4 2666
- 512GB m.2 PCI-e SSD
- 2TB 5400 RPM 3.5” HDD
- Z370 Motherboard
- 650 Watt PSU
Our Intel series of high performance gaming desktops come standard with liquid cooling for both the GPU and the CPU. Destroy the competition with the latest, most powerful Intel and Nvidia hardware. Expertly assembled as a turn-key system.
Primary components from MSI


{% extends "layout.html" %} {% block title %}Index{% endblock %} {% block head %} {% endblock %} {% block content %}
My name is Weebo 😊. This is my console, feel free to ask me anything!


{% load static %} {% load crispy_forms_tags %}
Registration Form
ST. MONICA'S CATHOLIC CHURCH, KORODUMA
PARISH MEMBERSHIP REGISTRATION FORM
{% csrf_token %} {{ form|crispy }}


Toggle navigation
Start Bootstrap
About
Services
Contact
Shopping Cart
Remove
Item
Quantity
Price
Subtotal
Cool Boots for Kids
4000
8000
Sandals for the Spartan
1000
1000
Dollshoes for that ballerina
1500
4500
Total:
13500


A practical and easy-to-use Android application to apply several filters to an image at once.
Features
- Applying several filters
- Undoing filters one by one
- Maintaining maximum image quality
- Taking photos using camera or choosing from SD-Card
Filters
- Boost-Up Colors
- Brightness
- Color Depth
- Color Filter
- Contrast
- Emboss
- Flip and Rotation
- Gamma
- Gaussian Blur
- Grayscale
- Hue
- Invert
- Noise
- Saturation
- Sepia
- Sharpen
- Sketch
- Tint
- Vignette
Screenshots


Lists all organizations, in the order that they were created on GitHub Enterprise.
Note: Pagination is powered exclusively by the
since
parameter. Use the
Link header to get the URL
for the next page of organizations.
GET /organizations
| Name | Type | Description |
|---|---|---|
since |
integer |
The integer ID of the last organization that you've seen. |
Status: 200 OK
Link: <https://api.github.com/organizations?since=135>; rel="next"
[
{
"login": "github",
"id": 1,
"node_id": "MDEyOk9yZ2FuaXphdGlvbjE=",
"url": "https://api.github.com/orgs/github",
"repos_url": "https://api.github.com/orgs/github/repos",
"events_url": "https://api.github.com/orgs/github/events",
"hooks_url": "https://api.github.com/orgs/github/hooks",
"issues_url": "https://api.github.com/orgs/github/issues",
"members_url": "https://api.github.com/orgs/github/members{/member}",
"public_members_url": "https://api.github.com/orgs/github/public_members{/member}",
"avatar_url": "https://github.com/images/error/octocat_happy.gif",
"description": "A great organization"
}
]


Jeremiah 4:27
For thus hath the LORD said, The whole land shall be desolate; yet will I not make a full end.


Beta This is a test version of the layout of this page. Take the survey to help us improve it
FOI release
A request and disclosure for information relating to the Building Schools for the Future programme and the coalition government's strategy for the education of those with HF autism and Asperger syndrome.
Can the department disclose the following:
‘Building Schools for the Future’- has this strategy been totally scrapped? And what is the name of the strategy for schools in its place, if any?
Does it include any consideration for the education needs of those with HF autism, Asperger’s / ASCS?
What is the new coalition government’s strategy for the education of those with HF autism and Asperger’s Syndrome?
The Building Schools for the Future scheme has been responsible for about one third of this entire department’s capital spending. But throughout its life it has been characterised by massive overspends, tragic delays, botched construction projects and needless bureaucracy. It is for this reason that we are bringing this programme to a close. It is vital that future capital investment represents good value for money and strongly supports the government’s ambitions to raise standards and tackle disadvantage.
The government remains committed to meeting the needs of children with autism and other special educational needs and disabilities (SEND). The department recognises the concern that not all children’s needs are being met. It believes that all children with SEND should have the same opportunities as their peers.
The department recognises that over recent years there has been an assumption that more children with statements of SEN should be educated in mainstream schools and indeed, this bias towards mainstream education is written into the law. What is important is for parents to be empowered to make a choice about where their child goes to school, whether that is a special or mainstream setting.
The life-long nature of autism means it is important that we prepare these children for adulthood, giving them the necessary skills for greater independence and work. For this reason the department will be launching a green paper on SEND in the autumn. It will look at the transition process and how we can make the system less adversarial and more transparent so that parents don’t feel as if they have to battle at every stage to get what their child needs.
We will be working closely with SEN and disability organisations, including those representing the autism community, to ensure we are listening to a wide breadth of views. We also want to hear from parents, young people and all those who have an interest in this area. Details about how to contribute your views will be available on the department’s website over the coming weeks. I do hope you will look out for these and respond.


A blogging site with CMS using Laravel 5.8
Hi! I'm Ebne Faiz Al-Amin, passionate about computer and programming. Prefer to work in the field of web application development. Currently focusing on full-stack development. Learning ReactJS.
A blogging site with CMS using Laravel 5.8
Le's Bookstore developed by Spring-boot,Hibernet, MySQL, Thymeleaf
A doctor appointment system which is backend by raw php and MySQL
An Arduino based project for detecting the leakage of methane gas from stove
An android based weather application
Let's Socialize


--- layout: default title: BlockSec.ca Github site ---
Here you will find the repository for BlockSec.ca public projects, as a supplement to the blog. More info here
For additional information check the project list included in the README.md file


Loading upcoming reports...
No Reports
Reporting Time Frame:
Report Type:
Submission Due Date
{{ report.type === "adhoc" ? "Ad hoc" : report.type }}
{{ report.dueDate | date: "dd-MMM-yyyy" }}
Loading upcoming reports...
No Reports
Reporting Time Frame:
Report Type:
Submission Due Date
{{ report.type === "adhoc" ? "Ad hoc" : report.type }}
{{ report.dueDate | date: "dd-MMM-yyyy" }}


ELLES A film review by Steve Rhodes Copyright 1999 Steve Rhodes RATING (0 TO ****): ** 1/2
If you're a woman who has been apprehensive lately about what your life may be like after you reach your 40s and 50s, the motion picture ELLES may provide just the perfect romantic fantasy for you. Director Luís Galvão Teles has a vision of your middle age that makes it look downright desirable. (His vision for the men looks pretty enjoyable too, but the focus in this movie is on the women's lives.)
In short, here is what lies ahead. Your looks will be somewhere between attractive and downright gorgeous.  And your age will be no problem for the men, even if you are twice their age. Being called their mother will be a bit off-putting, but no fairy tale is perfect.
And if that doesn't stretch credulity enough, how about this one. You'll become close friends with your ex, and have romantic dinners outside with him while you discuss your beautiful and accomplished grown children.

The light, upbeat dialog by the director and Don Bohlinger varies from the trite to the touching. The love affair between the professor (Carmen Maura) and her student is the most passionate and credible. Their love making, while not that explicit, displays an intensity rarely seen in American films.
The women briefly suffer some crises toward the end of the story, but the director wants to make this a feel good film, so he has them dispatch most of their worries quickly. Even the guys get to engage in some fantasies of their own. Notice that a fair number of the middle-aged guys hit it off with young, glamorous girlfriends. Granted none of this is very credible, but, hey, audiences deserve their dreams. There are more than enough downer movies to see.
ELLES runs 1:37. The film is in French with English subtitles. It is not rated but would be an R for sex, nudity, profanity and one drug usage scene and would be fine for older and mature teenagers.
Email<EMAIL_ADDRESS>Web: www.InternetReviews.com
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Tutorials Version: Kinetic
This is the ROS Kinetic version of the tutorials, intended for ROS Kinetic users only. If you are using a ROS Melodic release, we recommmend the Melodic tutorials or the latest master branch tutorials.


The Basic Sample Network is imported by default, have a play and learn what Fabric Composer is all about.


For the fig-swirl: Melt butter over medium heat in a saucepan. Add brown sugar and stir to dissolve. Halve all of the figs and toss in the saucepan with water and lemon juice. Cook over medium heat, stirring frequently, until you have a chunky-jammy mixture. Add salt with one or two stirs, set aside and let cool completely.
Ice cream: In a small pot over medium heat, combine milk, and granulated sugar until sugar is completely dissolved and the milk is just barely lukewarm. Whisk in the egg yolks. Set mixture in the fridge and wait until the fig mixture is cooled.
Using an ice cream machine, pour liquids into the frozen basin and process according to manufacturer instructions, i.e., let spin and chicken for 20 minutes before adding mascarpone, fig jam mixture, and the nuts. Continue to process for +/- 10 minutes. Pour semi-frozen mixture into a pyrex dish or glass tupperware. Freeze for at least two hours before serving.
Delicious © 2013 · All Rights Reserved.
Proudly Published with Ghost.


@(TMS allows you to publish and subscribe most important internal operations in the CMS.) @(TMS documentation).
@(With the Total.js API key, you can store and monitor logs in the Total.js Platform Logger app.)


Fading-Sliding-Custom
Animation
Fade In
Fade Out
Fade To 40%
Fade To 80%
Vibrate
Slide up
Slide down
Slide toggle
grow width
shrink
grow animation
move
multiple


Other applications can be invoked passing in context information, such as the URL of the
message selected.
So, for example, Nmap could be invoked passing the site
which you want it to scan.
Applications are configured using the Options Applications screen.
| Sites tab | 'Run application' right click menu item | |
| History tab | 'Run application' right click menu item |


{{title}}
In order to gain a good understanding of the design of register machines, we must test the machines we design to see if they perform as expected. One way to test a design is to hand-simulate the operation of the controller, as in Exercise 5-5. But this is extremely tedious for all but the simplest machines. In this section we construct a simulator for machines described in the register-machine language. The simulator is a Scheme program with four interface procedures. The first uses a description of a register machine to construct a model of the machine (a data structure whose parts correspond to the parts of the machine to be simulated), and the other three allow us to simulate the machine by manipulating the model:
constructs and returns a model of the machine with the given registers, operations, and controller.
stores a value in a simulated register in the given machine.
returns the contents of a simulated register in the given machine.
simulates the execution of the given machine, starting from the beginning of the controller sequence and stopping when it reaches the end of the sequence.
As an example of how these procedures are used, we can define gcd-machine to be a model of the GCD machine of section 5.1.1 as follows:
The first argument to make-machine is a list of register names. The next argument is a table (a list of two-element lists) that pairs each operation name with a Scheme procedure that implements the operation (that is, produces the same output value given the same input values). The last argument specifies the controller as a list of labels and machine instructions, as in section 5.1.
To compute GCDs with this machine, we set the input registers, start the machine, and examine the result when the simulation terminates:
This computation will run much more slowly than a gcd procedure written in Scheme, because we will simulate low-level machine instructions, such as assign, by much more complex operations.
Exercise 5.7: Use the simulator to test the machines you designed in Exercise 5-4.
The machine model generated by make-machine is represented as a procedure with local state using the message-passing techniques developed in Chapter 3. To build this model, make-machine begins by calling the procedure make-new-machine to construct the parts of the machine model that are common to all register machines. This basic machine model constructed by make-new-machine is essentially a container for some registers and a stack, together with an execution mechanism that processes the controller instructions one by one.
Make-machine then extends this basic model (by sending it messages) to include the registers, operations, and controller of the particular machine being defined. First it allocates a register in the new machine for each of the supplied register names and installs the designated operations in the machine. Then it uses an assembler (described below in section 5.2.2) to transform the controller list into instructions for the new machine and installs these as the machine's instruction sequence. Make-machine returns as its value the modified machine model.
We will represent a register as a procedure with local state, as in Chapter 3. The procedure make-register creates a register that holds a value that can be accessed or changed:
The following procedures are used to access registers:
We can also represent a stack as a procedure with local state. The procedure make-stack creates a stack whose local state consists of a list of the items on the stack. A stack accepts requests to push an item onto the stack, to pop the top item off the stack and return it, and to initialize the stack to empty.
The following procedures are used to access stacks:
The make-new-machine procedure, shown in Figure 5-13, constructs an object whose local state consists of a stack, an initially empty instruction sequence, a list of operations that initially contains an operation to initialize the stack, and a register table that initially contains two registers, named flag and pc (for ``program counter''). The internal procedure allocate-register adds new entries to the register table, and the internal procedure lookup-register looks up registers in the table.
The flag register is used to control branching in the simulated machine. Test instructions set the contents of flag to the result of the test (true or false). Branch instructions decide whether or not to branch by examining the contents of flag.
The pc register determines the sequencing of instructions as the machine runs. This sequencing is implemented by the internal procedure execute. In the simulation model, each machine instruction is a data structure that includes a procedure of no arguments, called the instruction execution procedure , such that calling this procedure simulates executing the instruction. As the simulation runs, pc points to the place in the instruction sequence beginning with the next instruction to be executed. Execute gets that instruction, executes it by calling the instruction execution procedure, and repeats this cycle until there are no more instructions to execute (i.e., until pc points to the end of the instruction sequence).
Figure 5.13: The make-new-machine procedure, which implements the basic machine model. @smalllisp (define (make-new-machine) (let ((pc (make-register 'pc)) (flag (make-register 'flag)) (stack (make-stack)) (the-instruction-sequence '())) (let ((the-ops (list (list 'initialize-stack (lambda () (stack 'initialize))))) (register-table (list (list 'pc pc) (list 'flag flag)))) (define (allocate-register name) (if (assoc name register-table) (error "Multiply defined register: " name) (set! register-table (cons (list name (make-register name)) register-table))) 'register-allocated) (define (lookup-register name) (let ((val (assoc name register-table))) (if val (cadr val) (error "Unknown register:" name)))) (define (execute) (let ((insts (get-contents pc))) (if (null? insts) 'done (begin ((instruction-execution-proc (car insts))) (execute))))) (define (dispatch message) (cond ((eq? message 'start) (set-contents! pc the-instruction-sequence) (execute)) ((eq? message 'install-instruction-sequence) (lambda (seq) (set! the-instruction-sequence seq))) ((eq? message 'allocate-register) allocate-register) ((eq? message 'get-register) lookup-register) ((eq? message 'install-operations) (lambda (ops) (set! the-ops (append the-ops ops)))) ((eq? message 'stack) stack) ((eq? message 'operations) the-ops) (else (error "Unknown request -- MACHINE" message)))) dispatch))) @end smalllisp
As part of its operation, each instruction execution procedure modifies pc to indicate the next instruction to be executed. Branch and goto instructions change pc to point to the new destination. All other instructions simply advance pc, making it point to the next instruction in the sequence. Observe that each call to execute calls execute again, but this does not produce an infinite loop because running the instruction execution procedure changes the contents of pc.
Make-new-machine returns a dispatch procedure that implements message-passing access to the internal state. Notice that starting the machine is accomplished by setting pc to the beginning of the instruction sequence and calling execute.
For convenience, we provide an alternate procedural interface to a machine's start operation, as well as procedures to set and examine register contents, as specified at the beginning of section 5.2:
These procedures (and many procedures in sections 5-2-2 and 5-2-3) use the following to look up the register with a given name in a given machine:
The assembler transforms the sequence of controller expressions for a machine into a corresponding list of machine instructions, each with its execution procedure. Overall, the assembler is much like the evaluators we studied in Chapter 4---there is an input language (in this case, the register-machine language) and we must perform an appropriate action for each type of expression in the language.
The technique of producing an execution procedure for each instruction is just what we used in section 4.1.7 to speed up the evaluator by separating analysis from runtime execution. As we saw in Chapter 4, much useful analysis of Scheme expressions could be performed without knowing the actual values of variables. Here, analogously, much useful analysis of register-machine-language expressions can be performed without knowing the actual contents of machine registers. For example, we can replace references to registers by pointers to the register objects, and we can replace references to labels by pointers to the place in the instruction sequence that the label designates.
Before it can generate the instruction execution procedures, the assembler must know what all the labels refer to, so it begins by scanning the controller text to separate the labels from the instructions. As it scans the text, it constructs both a list of instructions and a table that associates each label with a pointer into that list. Then the assembler augments the instruction list by inserting the execution procedure for each instruction.
The assemble procedure is the main entry to the assembler. It takes the controller text and the machine model as arguments and returns the instruction sequence to be stored in the model. Assemble calls extract-labels to build the initial instruction list and label table from the supplied controller text. The second argument to extract-labels is a procedure to be called to process these results: This procedure uses update-insts! to generate the instruction execution procedures and insert them into the instruction list, and returns the modified list.
Extract-labels takes as arguments a list text (the sequence of controller instruction expressions) and a receive procedure. Receive will be called with two values: (1) a list insts of instruction data structures, each containing an instruction from text; and (2) a table called labels, which associates each label from text with the position in the list insts that the label designates.
Extract-labels works by sequentially scanning the elements of the text and accumulating the insts and the labels. If an element is a symbol (and thus a label) an appropriate entry is added to the labels table. Otherwise the element is accumulated onto the insts list.@footnote{Using the receive procedure here is a way to get extract-labels to effectively return two values---labels and insts---without explicitly making a compound data structure to hold them. An alternative implementation, which returns an explicit pair of values, is
which would be called by assemble as follows:
You can consider our use of receive as demonstrating an elegant way to return multiple values, or simply an excuse to show off a programming trick. An argument like receive that is the next procedure to be invoked is called a ``continuation.'' Recall that we also used continuations to implement the backtracking control structure in the amb evaluator in section 4.3.3.}
Update-insts! modifies the instruction list, which initially contains only the text of the instructions, to include the corresponding execution procedures:
The machine instruction data structure simply pairs the instruction text with the corresponding execution procedure. The execution procedure is not yet available when extract-labels constructs the instruction, and is inserted later by update-insts!.
The instruction text is not used by our simulator, but it is handy to keep around for debugging (see Exercise 5-16).
Elements of the label table are pairs:
Entries will be looked up in the table with
Exercise 5.8: The following register-machine code is ambiguous, because the label here is defined more than once:
With the simulator as written, what will the contents of register a be when control reaches there? Modify the extract-labels procedure so that the assembler will signal an error if the same label name is used to indicate two different locations.
The assembler calls make-execution-procedure to generate the execution procedure for an instruction. Like the analyze procedure in the evaluator of section 4.1.7, this dispatches on the type of instruction to generate the appropriate execution procedure.
For each type of instruction in the register-machine language, there is a generator that builds an appropriate execution procedure. The details of these procedures determine both the syntax and meaning of the individual instructions in the register-machine language. We use data abstraction to isolate the detailed syntax of register-machine expressions from the general execution mechanism, as we did for evaluators in section 4.1.2, by using syntax procedures to extract and classify the parts of an instruction.
The make-assign procedure handles assign instructions:
Make-assign extracts the target register name (the second element of the instruction) and the value expression (the rest of the list that forms the instruction) from the assign instruction using the selectors
The register name is looked up with get-register to produce the target register object. The value expression is passed to make-operation-exp if the value is the result of an operation, and to make-primitive-exp otherwise. These procedures (shown below) parse the value expression and produce an execution procedure for the value. This is a procedure of no arguments, called value-proc, which will be evaluated during the simulation to produce the actual value to be assigned to the register. Notice that the work of looking up the register name and parsing the value expression is performed just once, at assembly time, not every time the instruction is simulated. This saving of work is the reason we use execution procedures, and corresponds directly to the saving in work we obtained by separating program analysis from execution in the evaluator of section 4.1.7.
The result returned by make-assign is the execution procedure for the assign instruction. When this procedure is called (by the machine model's execute procedure), it sets the contents of the target register to the result obtained by executing value-proc. Then it advances the pc to the next instruction by running the procedure
Advance-pc is the normal termination for all instructions except branch and goto.
Make-test handles test instructions in a similar way. It extracts the expression that specifies the condition to be tested and generates an execution procedure for it. At simulation time, the procedure for the condition is called, the result is assigned to the flag register, and the pc is advanced:
The execution procedure for a branch instruction checks the contents of the flag register and either sets the contents of the pc to the branch destination (if the branch is taken) or else just advances the pc (if the branch is not taken). Notice that the indicated destination in a branch instruction must be a label, and the make-branch procedure enforces this. Notice also that the label is looked up at assembly time, not each time the branch instruction is simulated.
A goto instruction is similar to a branch, except that the destination may be specified either as a label or as a register, and there is no condition to check---the pc is always set to the new destination.
The stack instructions save and restore simply use the stack with the designated register and advance the pc:
The final instruction type, handled by make-perform, generates an execution procedure for the action to be performed. At simulation time, the action procedure is executed and the pc advanced.
The value of a reg, label, or const expression may be needed for assignment to a register (make-assign) or for input to an operation (make-operation-exp, below). The following procedure generates execution procedures to produce values for these expressions during the simulation:
The syntax of reg, label, and const expressions is determined by
Assign, perform, and test instructions may include the application of a machine operation (specified by an op expression) to some operands (specified by reg and const expressions). The following procedure produces an execution procedure for an ``operation expression''---a list containing the operation and operand expressions from the instruction:
The syntax of operation expressions is determined by
Observe that the treatment of operation expressions is very much like the treatment of procedure applications by the analyze-application procedure in the evaluator of section 4.1.7 in that we generate an execution procedure for each operand. At simulation time, we call the operand procedures and apply the Scheme procedure that simulates the operation to the resulting values. The simulation procedure is found by looking up the operation name in the operation table for the machine:
Exercise 5.9: The treatment of machine operations above permits them to operate on labels as well as on constants and the contents of registers. Modify the expression-processing procedures to enforce the condition that operations can be used only with registers and constants.
Exercise 5.10: Design a new syntax for register-machine instructions and modify the simulator to use your new syntax. Can you implement your new syntax without changing any part of the simulator except the syntax procedures in this section?
Exercise 5.11: When we introduced save and restore in section 5.1.4, we didn't specify what would happen if you tried to restore a register that was not the last one saved, as in the sequence
There are several reasonable possibilities for the meaning of restore:
Exercise 5.12: The simulator can be used to help determine the data paths required for implementing a machine with a given controller. Extend the assembler to store the following information in the machine model:
Extend the message-passing interface to the machine to provide access to this new information. To test your analyzer, define the Fibonacci machine from Figure 5-12 and examine the lists you constructed.
Exercise 5.13: Modify the simulator so that it uses the controller sequence to determine what registers the machine has rather than requiring a list of registers as an argument to make-machine. Instead of pre-allocating the registers in make-machine, you can allocate them one at a time when they are first seen during assembly of the instructions.
Simulation is useful not only for verifying the correctness of a proposed machine design but also for measuring the machine's performance. For example, we can install in our simulation program a ``meter'' that measures the number of stack operations used in a computation. To do this, we modify our simulated stack to keep track of the number of times registers are saved on the stack and the maximum depth reached by the stack, and add a message to the stack's interface that prints the statistics, as shown below. We also add an operation to the basic machine model to print the stack statistics, by initializing the-ops in make-new-machine to
Here is the new version of make-stack:
Exercise 5-15 through Exercise 5-19 describe other useful monitoring and debugging features that can be added to the register-machine simulator.
Exercise 5.14: Measure the number of pushes and the maximum stack depth required to compute n! for various small values of n using the factorial machine shown in Figure 5-11. From your data determine formulas in terms of n for the total number of push operations and the maximum stack depth used in computing n! for any n > 1. Note that each of these is a linear function of n and is thus determined by two constants. In order to get the statistics printed, you will have to augment the factorial machine with instructions to initialize the stack and print the statistics. You may want to also modify the machine so that it repeatedly reads a value for n, computes the factorial, and prints the result (as we did for the GCD machine in Figure 5-4), so that you will not have to repeatedly invoke get-register-contents, set-register-contents!, and start.
Exercise 5.15: Add instruction counting to the register machine simulation. That is, have the machine model keep track of the number of instructions executed. Extend the machine model's interface to accept a new message that prints the value of the instruction count and resets the count to zero.
Exercise 5.16: Augment the simulator to provide for instruction tracing . That is, before each instruction is executed, the simulator should print the text of the instruction. Make the machine model accept trace-on and trace-off messages to turn tracing on and off.
Exercise 5.17: Extend the instruction tracing of Exercise 5-16 so that before printing an instruction, the simulator prints any labels that immediately precede that instruction in the controller sequence. Be careful to do this in a way that does not interfere with instruction counting (Exercise 5-15). You will have to make the simulator retain the necessary label information.
Exercise 5.18: Modify the make-register procedure of section 5.2.1 so that registers can be traced. Registers should accept messages that turn tracing on and off. When a register is traced, assigning a value to the register should print the name of the register, the old contents of the register, and the new contents being assigned. Extend the interface to the machine model to permit you to turn tracing on and off for designated machine registers.
Exercise 5.19: Alyssa P. Hacker wants a breakpoint feature in the simulator to help her debug her machine designs. You have been hired to install this feature for her. She wants to be able to specify a place in the controller sequence where the simulator will stop and allow her to examine the state of the machine. You are to implement a procedure
that sets a breakpoint just before the nth instruction after the given label. For example,
installs a breakpoint in gcd-machine just before the assignment to register a. When the simulator reaches the breakpoint it should print the label and the offset of the breakpoint and stop executing instructions. Alyssa can then use get-register-contents and set-register-contents! to manipulate the state of the simulated machine. She should then be able to continue execution by saying
She should also be able to remove a specific breakpoint by means of
or to remove all breakpoints by means of


This is an example styleguide demonstrating the Default skin from styledown-skins. The components and associated documentation are borrowed from the Pure Framework.
To style an HTML table, add the
pure-table
classname. This class adds padding and borders to table elements, and emphasizes the header.
| # | Make | Model | Year |
|---|---|---|---|
| 1 | Honda | Accord | 2009 |
| 2 | Toyota | Camry | 2012 |
| 3 | Hyundai | Elantra | 2010 |

#
Make
Model
Year

1
Honda
Accord
2009

2
Toyota
Camry
2012

3
Hyundai
Elantra
2010


When I realize everything’s equality
I forget all about my close friends and my relatives
It’s OK to forget the objects of your attachment
When I realize wisdom beyond thought
I forget everything included in perceiver and perceived
It’s OK to forget these causes of happiness and pain
Beyond memory, beyond feelings
I forget all about experiences, the good ones and the bad
It’s OK to forget them, they just go up and down
When I know the three kayas are present naturally
I forget all about the deity’s generation stage practice
It’s OK to forget the Dharma made of concepts
When I realize the result’s inside of me
I forget all about the results you have to strive and strain to get
It’s OK to forget the Dharma of the relative truth
Meditating on the key instructions
I forget all other explanations and their conventional terms
It’s OK to forget the Dharma that makes you arrogant
When I realize appearances are my texts
I forget all about those big books with their letters in black
It’s OK to forget the Dharma that’s just a heavy load
I have no parents; I make the heavens and earth my parents.
I have no home; I make awareness my home.
I have no life or death; I make the tides of breathing my life and death.
I have no divine power; I make honesty my divine power.
I have no means; I make understanding my means.
I have no magic secrets; I make character my magic secret.
I have no body; I make endurance my body.
I have no eyes; I make the flash of lightening my eyes.
I have no ears; I make sensibility my ears.
I have no limbs; I make promptness my limbs.
I have no strategy; I make "unshadowed by thought" my strategy.
I have no designs; I make "seizing opportunity by the forelock" my design.
I have no miracles; I make right-action my miracles.
I have no principles; I make adaptability to all circumstances my principles.
I have no tactics; I make emptiness and fullness my tactics.
I have no talents; I make ready wit my talent.
I have no friends; I make my mind my friend.
I have no enemy; I make carelessness my enemy.
I have no armor; I make benevolence and righteousness my armor.
I have no castle; I make immovable-mind my castle.
I have no sword; I make absence of self my sword.


CHIKV cells mice cell vaccine virus responses vaccinated viral CHKVf footpad IFNγ AdV MCMV using al.. peptides :–. (). levels (Figure ELISpot peptide protection calf infected infection ipsilateral AdV- Chikungunya Mice ankle antibodies neutralizing nsP {border-style performed swelling control px;} splenocytes #ffffff;} challenged data dpi fusion muscle days animals depletion elicited joint mice. mouse protective role tissue Figure epitopes loads vaccination vaccines CBL/ antibody challenge incubated measured < :e. cells. chikungunya infection. significantly assays challenge, following i.m. increased post vectors Dis. PFU Splenocytes assay compared disease elicit group groups immunity infectious response (A) CHIKVf However, chronic controls did dpi, gene generated immune plaque prior reduced significant tissues (B) CHIKV-specific PCR RNA Virol. cells, challenge. containing dilution expressing observed presence protect px; right {font-family ./journal.pntd. CHIKV, CHIKV-induced Negl Trop Vero acute added analyzed detected developed different dpi. font-size isolated limiting overlapping protein test (C) AdV-CHKVf Adenovirus CHIKV. Footpad PBS States[], amino analysis ankle, anti-CD cellular clearance comparison contralateral cytokine disease. double; efficacy highly identified inflammation multiple receiving reduce results serum shown survival washed (D) (Figures (–). AdV-Control B). C). CHIKV-infected CHKVf-vaccinated Cell Cells Department National RRV Similarly, addition, adenovirus adenoviruses and/or ankles antiviral assays. bold boosted border-color border-width collected confirmed directed followed high higher indicates infection, inflammatory inoculated lacking load major mice, monoclonal muscle. pain patients plates positive previously reduction robust sera showed solid; supplemented titers vaccine, vaccine-induced virus. weeks {font-style {font-weight (), (*p -mer ./JVI.- ./jimmunol. A). AdV-, Following Ifnar−/− Immunol. Infect Infectious Mouse Research Statistical University Virus acid additional alphavirus antigen article artificial bacterial boost confirm constructs courier; decreased demonstrated depleting described development effective em; encephalitis epitope expression failed footpad. impact important included indicating intramuscularly log-transformed memory min min, model monitored new peptides, placed plates. present prophylactic pt;} quadriceps reduces region relative samples stained stimulation suggesting tested tissues. transferred type used vaccine. viremia


Lookup help
The ETS lookup functionality finds entries with a the same key specified.
The ETS UI only supports tables of type set or ordered_set, as a bag or duplicate_bag table may contain multiple entries with the same key, and this could cause problems when querying on key, in terms of performance or memory usage.
Simple example
Lets create our table
1> ets:new(example_table, [public, named_table, ordered_set]).
example_table
2>
public, so that anyone can read/write to it, named_table is for accessing it by name and ordered_set is a fancy way of saying the table key/index is ordered, and has no duplicates.
Then insert some entries
2> [ ets:insert(example_table, {Id, Id rem 2 == 0}) || Id <- lists:seq(1, 10) ].
[true,true,true,true,true,true,true,true,true,true]
3>
rem 2 == 0
is a simple check whether the key is odd/even, for visual aid in querying.
fetching all would result in
{1,false}
{2,true}
{3,false}
{4,true}
{5,false}
{6,true}
{7,false}
{8,true}
{9,false}
{10,true}
So let's find an entry where the key is 5, enter the follow into the key lookup textbox
5
So the lookup with key == 5 above will result with an entry below
{5,false}
That was a simple lookup with a key value