A full stack web developer with demonstrated experience as a Civil Drafter for a year and have background in Mechanical Engineering. A detail-oriented engineer who is effective to perform problem solving assignments within guidelines. Dedicated to keep learning, adjust, and grow to achieve success in the competitive industry
-
-
-
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.
I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.


{% extends "base.html" %} {% block body %} {% from "security/_macros.html" import render_field_with_errors, render_field %} {% include "security/_messages.html" %}
We recently changed our login system. If your password isn't working, please reset your password.


{% extends "projects/import_base.html" %} {% load i18n %} {% load socialaccount %} {% block content %}
{% blocktrans %} Import a project, using one of the methods below. The project will be added to your dashboard and automatically built for the first time. {% endblocktrans %}
{% get_social_accounts request.user as accounts %}{% blocktrans %} Import one of your public GitHub repositories to start using your documentation. {% endblocktrans %}
{% else %}{% blocktrans %} Once your account is connected to your GitHub account, you will be able to automatically import and configure your public GitHub repositories. {% endblocktrans %} Connect to Github {% trans "to import your first repository." %}
{% endif %}{% blocktrans %} Import one of your public Bitbucket repositories to start using your documentation. {% endblocktrans %}
{% else %}{% blocktrans %} Once your account is connected to your Bitbucket account, you will be able to automatically import and configure your public Bitbucket repositories. {% endblocktrans %} Connect to Bitbucket {% trans "to import your first repository." %}
{% endif %}{% blocktrans %} Public repositories can be imported manually from anywhere. {% endblocktrans %}


Handling Player Input
As I’ve added more and more game mechanics to Flex, I’ve experimented with different input methods a player can use to interact with the world besides the typical ‘Press E to interact’ (spinning a valve by rotating a joystick is one alternative method). So far I’ve added support for keyboard, mouse, and XBOX controllers, but I will likely further expand the number of supported devices in the future (midi keyboards anyone?). The code I have been using to handle each input method is quite messy and needed to be cleaned up. This post will cover the process I went through to get where I’m at today with the system.
To see why I felt this change was necessary, take a look at how I was checking for a jump input:
if (g_InputManager->IsGamepadButtonPressed(m_Index, GamepadButton::A) ||
(g_InputManager->bPlayerUsingKeyboard[m_Index] &&
g_InputManager->GetKeyPressed(KeyCode::KEY_SPACE)))
{
// ...
}
Clearly not good in a number of ways:
1. The player can not edit keybindings. This is the first item on the “basic” category on the great Game Accessibility Guidelines, so I’d say it’s a necessary feature to have if you have any desire to cater toward disabled gamers, plus it’s a useful feature for able gamers alike.
2. That’s simply too much code for catching an action event, and it will only grow longer as more input methods are added. This will inevitably lead to typos and copy-paste errors.
3. Single events could be handled multiple times by different systems leading to, for example, the player walking forward when ‘W’ was pressed, even when a text box showing above the play area already handled the keypress.
Abstraction
To get around the first two issues noted above, we can add a layer of abstraction between the usage code and the input events. (It’s the Fundamental theorem of software engineering after all!)
Once a mapping exists between game-specific-actions (like MOVE_FORWARD
and INTERACT
) and inputs (like KeyCode::KEY_W
and GamepadButton::A
), the usage code can be simplified to just check for an Action
and players will be able to remap keys as they like.
To implement this mapping, I created an enumeration which defines all possible actions that can be taken in-game. I also created an InputBinding
struct which holds all necessary info about which actual inputs each action maps to. The mapping process is then simply indexing into the list using an Action
as the index.
enum class Action
{
MOVE_LEFT,
MOVE_RIGHT,
MOVE_FORWARD,
MOVE_BACKWARD,
INTERACT,
// ...
_NONE
};
struct InputBinding
{
KeyCode keyCode = KeyCode::_NONE;
MouseButton mouseButton = MouseButton::_NONE;
MouseAxis mouseAxis = MouseAxis::_NONE;
GamepadButton gamepadButton = GamepadButton::_NONE;
GamepadAxis gamepadAxis = GamepadAxis::_NONE;
bool bNegative = false;
};
InputBinding m_InputBindings[(i32)Action::_NONE + 1];
Now, rather than that mess shown earlier, we can catch jump event as follows:
if (g_InputManager->GetActionPressed(Action::JUMP))
{
// ...
}
For the curious, see how GetActionPressed
is implemented here.
This system addresses the first two issues noted above, but to solve the third problem (event handling duplication) we’ll need go deeper.
Callbacks
In order to allow one system to “consume” an event, thereby preventing other systems from also handling it, I added a callback system for each event type.
To allow an event caller to call member functions on miscellaneous types, I created an abstract class that contains one virtual function. The event caller can maintain a list of listeners using this abstract type, and call the function without knowing anything about the subclass that implements it and keeps a reference to the object which the member function should be called on. The syntax is a little strange, but it works.
enum class EventReply
{
CONSUMED,
UNCONSUMED
};
class ICallbackMouseButton
{
public:
virtual EventReply Execute(MouseButton button, KeyAction action) = 0;
};
template<typename T>
class MouseButtonEventCallback : public ICallbackMouseButton
{
public:
using CallbackFunction = EventReply(T::*)(MouseButton, KeyAction);
MouseButtonEventCallback(T* obj, CallbackFunction fun) :
mObject(obj),
mFunction(fun)
{
}
virtual EventReply Execute(MouseButton button, KeyAction action) override
{
return (mObject->*mFunction)(button, action);
}
private:
CallbackFunction mFunction;
T* mObject;
};
The trickiest part about that code was the using
declaration syntax, but luckily I know a template wizard who helped me out.
I defined similar classes for mouse move & keyboard events, but I’ll leave them out for the sake of brevity.
To register a callback, a system has to define a function matching the signature of the callback, as well as an instance of the subclassed callback object. This instance takes the type of the listener as a template argument, which is how it’s able to call the member function you point it towards.
EventReply OnMouseButtonEvent(MouseButton button, KeyAction action);
MouseButtonEventCallback<DebugCamera> mouseButtonCallback;
Because the callback object has no default constructor you must initialize it in the constructor of the listener. You must also bind and unbind at the appropriate times:
DebugCamera::DebugCamera() :
mouseButtonCallback(this, &DebugCamera::OnMouseButtonEvent)
{
}
void DebugCamera::Initialize()
{
g_InputManager->BindMouseButtonEventCallback(&mouseButtonCallback);
}
void DebugCamera::Destroy()
{
g_InputManager->UnbindMouseButtonEventCallback(&mouseButtonCallback);
}
EventReply DebugCamera::OnMouseButtonEvent(MouseButton button, KeyAction action)
{
if (button == MouseButton::LEFT && action == KeyAction::PRESS)
{
// ...
return EventReply::CONSUMED;
}
return EventReply::UNCONSUMED;
}
The binding/unbinding functions simply add and remove entries into the list of listeners.
std::vector<ICallbackMouseButton*> m_MouseButtonCallbacks;
When an event is generated, the event caller can iterate over the listeners until one listener consumes it, at which point the propagation stops.
// Called by OS callback on mouse button press
void InputManager::MouseButtonCallback(MouseButton mouseButton,
KeyAction action, i32 mods)
{
// ...
for (auto iter = m_MouseButtonCallbacks.rbegin();
iter != m_MouseButtonCallbacks.rend();
++iter)
{
if ((*iter)->Execute(mouseButton, action) == EventReply::CONSUMED)
{
break;
}
}
}
This system nicely handles the third issue I noted at the start, but it ignores the first issue! To solve all three, I added yet another callback, this time for Action
events. Determining when to call these took a bit of fiddling, especially since I wanted to keep the other callbacks. This was made more complex by the priority system I had since added which determines the order in which the callbacks are called. Priority is determined simply by an integer specified at event bind-time. (diff) You can find the code in its entirety on GitHub if you’d like to dig through it further.
Conclusion
I would prefer to be able to store the callback objects in the event caller classes so that each listener doesn’t require an extra member, but I don’t believe that’s possible without a reflection system (which I’m not keen enough on to bother implementing). Maybe one of these days someone will release a decent programming language with reflection support…
While implementing this system I was very wary of compile times, and knowing that templates and modern C++ classes are known for being slow in several senses, I tried to keep things as simple as I could. However, I think there’s still some work to be done in that regard. With that said, this system feels like a big step forward and I’ve been really enjoying cleaning up the old code to use it.


| Top |
| guint | gtk_get_major_version () |
| guint | gtk_get_minor_version () |
| guint | gtk_get_micro_version () |
| guint | gtk_get_binary_age () |
| guint | gtk_get_interface_age () |
| const gchar * | gtk_check_version () |
| #define | GTK_CHECK_VERSION() |
| #define | gtk_major_version |
| #define | gtk_minor_version |
| #define | gtk_micro_version |
| #define | gtk_binary_age |
| #define | gtk_interface_age |
| #define | GTK_MAJOR_VERSION |
| #define | GTK_MINOR_VERSION |
| #define | GTK_MICRO_VERSION |
| #define | GTK_BINARY_AGE |
| #define | GTK_INTERFACE_AGE |
GTK+ provides version information, primarily useful in configure checks for builds that have a configure script. Applications will not typically use the features described here.
guint
gtk_get_major_version (void
);
Returns the major version number of the GTK+ library. (e.g. in GTK+ version 3.1.5 this is 3.)
This function is in the library, so it represents the GTK+ library your code is running against. Contrast with the GTK_MAJOR_VERSION macro, which represents the major version of the GTK+ headers you have included when compiling your code.
Since: 3.0
guint
gtk_get_minor_version (void
);
Returns the minor version number of the GTK+ library. (e.g. in GTK+ version 3.1.5 this is 1.)
This function is in the library, so it represents the GTK+ library your code is are running against. Contrast with the GTK_MINOR_VERSION macro, which represents the minor version of the GTK+ headers you have included when compiling your code.
Since: 3.0
guint
gtk_get_micro_version (void
);
Returns the micro version number of the GTK+ library. (e.g. in GTK+ version 3.1.5 this is 5.)
This function is in the library, so it represents the GTK+ library your code is are running against. Contrast with the GTK_MICRO_VERSION macro, which represents the micro version of the GTK+ headers you have included when compiling your code.
Since: 3.0
guint
gtk_get_binary_age (void
);
Returns the binary age as passed to libtool
when building the GTK+ library the process is running against.
If libtool
means nothing to you, don't
worry about it.
Since: 3.0
guint
gtk_get_interface_age (void
);
Returns the interface age as passed to libtool
when building the GTK+ library the process is running against.
If libtool
means nothing to you, don't
worry about it.
Since: 3.0
const gchar * gtk_check_version (guint required_major
,guint required_minor
,guint required_micro
);
Checks that the GTK+ library in use is compatible with the given version. Generally you would pass in the constants GTK_MAJOR_VERSION, GTK_MINOR_VERSION, GTK_MICRO_VERSION as the three arguments to this function; that produces a check that the library in use is compatible with the version of GTK+ the application or module was compiled against.
Compatibility is defined by two things: first the version
of the running library is newer than the version
required_major.required_minor
.required_micro
. Second
the running library must be binary compatible with the
version required_major.required_minor
.required_micro
(same major version.)
This function is primarily for GTK+ modules; the module
can call this function to check that it wasn’t loaded
into an incompatible version of GTK+. However, such a
check isn’t completely reliable, since the module may be
linked against an old version of GTK+ and calling the
old version of gtk_check_version()
, but still get loaded
into an application using a newer version of GTK+.
required_major |
the required major version |
|
required_minor |
the required minor version |
|
required_micro |
the required micro version |
NULL
if the GTK+ library is compatible with the
given version, or a string describing the version mismatch.
The returned string is owned by GTK+ and should not be modified
or freed.
[nullable]
#define GTK_CHECK_VERSION(major,minor,micro)
Returns TRUE
if the version of the GTK+ header files
is the same as or newer than the passed-in version.
#define GTK_MAJOR_VERSION (3)
Like gtk_get_major_version()
, but from the headers used at
application compile time, rather than from the library linked
against at application run time.
#define GTK_MINOR_VERSION (22)
Like gtk_get_minor_version()
, but from the headers used at
application compile time, rather than from the library linked
against at application run time.
#define GTK_MICRO_VERSION (12)
Like gtk_get_micro_version()
, but from the headers used at
application compile time, rather than from the library linked
against at application run time.
#define GTK_BINARY_AGE (2212)
Like gtk_get_binary_age()
, but from the headers used at
application compile time, rather than from the library linked
against at application run time.
#define GTK_INTERFACE_AGE (12)
Like gtk_get_interface_age()
, but from the headers used at
application compile time, rather than from the library linked
against at application run time.


Extension argument processing code
| Class | Description |
|---|---|
| Auth_OpenID_Mapping | An Auth_OpenID_Mapping maintains a mapping from arbitrary keys to arbitrary values. (This is unlike an ordinary PHP array, whose keys may be only simple scalars.) |
| Auth_OpenID_NamespaceMap | Maintains a bijective map between namespace uris and aliases. |
| Auth_OpenID_Message | In the implementation of this object, null represents the global namespace as well as a namespace with no key. |
Import tools needed to deal with messages.
Registers a (namespace URI, alias) mapping in a global namespace
alias map. Raises NamespaceAliasRegistrationError if either the namespace URI or alias has already been registered with a different value. This function is required if you want to use a namespace with an OpenID 1 message.
Removes a (namespace_uri, alias) registration from the global namespace alias map. Returns true if the removal succeeded; false if not (if the mapping did not exist).
Documentation generated on Tue, 21 Apr 2009 11:31:31 -0700 by phpDocumentor 1.3.2


Disclaimer
The following page provides spending and/or investments that may or may not be tax deductable. It is advised to speak with tax service before including the following in your taxes.
$12,000.00
$2,000.00
$1,000.00
$19.99
$15.00
Store Name
Description
Money Spent


Bugfixes:
- Visual Studio doesn't allow saving read only files (issue 571)
- Path.GetDirectoryName() doesn't handle paths longer than 248
characters
- Extra validations in SvnClientPool cleanup
- Not possible to add non-numbers in issuenumber fields (issue 572)
- User Settings editor focus is stolen on editting an unmodified
file, making the editor read-only.


We are exploring the possibilities of using the FoodKG to suggest ingredient substitutions in recipes. This work is motivated by trying to make recipes healthier for people with specific dietary constraints, like trying to reduce their carbohydrate intake or avoiding eating specific types of foods.
We calculate a substitutability score based on a heuristic we have developed, DIISH. This heuristic combines both implicit and explicit semantic information about ingredients to try to determine good substitutes.
We calculate implicit semantics using word embeddings models - a Word2Vec model trained on data from the Im2Recipe project, and a word embedding model from spaCy.
We calculate explicit semantics using recipe and ingredient information in the FoodKG. We calculate scores to try to capture information like whether ingredients are used in similar recipe contexts and whether ingredients are paired together with similar ingredients.
The DIISH substitutability score is calculated for ingredients, and we rank substitute candidates to provide our final result. We also leverage the FoodKG's links to FoodOn's food ontology to help generalize ingredient uses, as well as filter out options that are unlikely to be considered good substitutes.
One source that we used to collect substitution data is The Cook's Thesaurus. This website has a large catalog of ingredients, providing background information about the ignredient as well as some common options for substitutions.
We also use Food.com review data to collect more data on substitutions. More information about the data set can be found here.
The scripts used to scrape and parse the pages from The Cook's Thesaurus, as well as the scripts used to parse the Food.com review data into ingredient substitution tuples, is open sourced and can be found here
requirements.txt


LaTeX2Image allows LaTeX math equations to be exported directly to multiple image formats, and saved for use in other documents.
The original / modified source code is available on GitHub. Behind the scenes, a Node.js app starts an isolated Docker container with a LaTeX installation for each request, compiling the generated .tex file and converting it to an SVG vector image. If required, the SVG file is then converted to a raster image format.


Near extremality, often have [Cano et al., 1910.14324]:
Fractional \(\alpha\) is physcially reasonable. \(M_{\rm ext}(Q,\epsilon)\approx M_{\rm ext}^{0}(Q)+\epsilon\Delta M_{\rm ext}(Q)\)
Implies \(T(M,\Q,\epsilon)\approx \frac{(M-M_{\rm ext}(Q,\epsilon))^{1-\alpha}}{\alpha F(\Q)}\)
Derivative of interest:
Shows \(\Delta M\approx -T\Delta S\) even slightly away from extremality, in such cases
Probe \(M\) s.t. \(T(M,\Q)\approx T_0+\epsilon \Delta T\) with \(T_0\gg\epsilon \Delta T\)
Expect \(S(M,\Q,\epsilon)\approx S_{0}(M,\Q)+\epsilon \Delta S(M,\Q)\) here. Full relation:
Expect \(M(T,\Q,\epsilon)\), \(S(T,\Q,\epsilon)\) have nice expansions in \(T\)
LHS is \(\frac{\partial}{\partial \epsilon}\left(M-TS\right)_{T,\Q}\approx \partial_{\epsilon}M_{\rm ext}(\Q,\epsilon)+{\cal O}(T)\)
RHS is \(-T\Delta S(M,\Q)\), matching gives \(\Delta M=-T_{0}\Delta S\) in approx. extremal regime
Near extremality, often have [Cano et al., 1910.14324]:
Fractional \(\alpha\) is physcially reasonable. \(M_{\rm ext}(Q,\epsilon)\approx M_{\rm ext}^{0}(Q)+\epsilon\Delta M_{\rm ext}(Q)\)
Probe \(M=(1+\delta)\times M_{\rm ext}^{0}\) with \(0<\delta\ll 1\) but large enough so we can expand in \(\epsilon\)
Equivalent to working with \(T(M,\Q)\approx T_0+\epsilon \Delta T\) with \(T_0\gg\epsilon \Delta T\)
In this regime, still have \(\partial_{\epsilon}M(T,Q,\epsilon)\)
The thermodynamic potential
Compute \(\Delta M_{\rm ext}\) using \(\mu(Q,T)\approx 1-2\pi Q T\) at small T
Compute \(T_0\), \(\Delta S\) at \(M=Q\times (1+\delta)\)
Combining results:
The zero-\(T\) limit generically contains non-analyticities, as seen from
\(\left(\frac{\partial S}{\partial \epsilon}\right)_{M,\Q}\) must diverge as \(T^{-1}\) at low-\(T\), though \(S(M,\Q,\epsilon)\) needn't
Related: when \(\Delta T(M,\Q)\) is comparable to \(T_0(M,\Q)\), \(S\) may not be analytic in \(\epsilon\).
\(\Delta M\approx -T_0\Delta S\) derived for \(\Delta T\ll T_0\) where analytic \(S\approx S_0+\epsilon\Delta S\)
Non-analyticity in \(\epsilon\) is physically sensible.
Some typical forms of low-\(T\) corrections: [Cano et al., 1910.14324]:
The unperturbed extremal state \(M=M_{\rm ext}^{0}(\Q)\) only has real entropy for \(\epsilon>0\)
Whether \(S\) has analytic expansion in \(\epsilon\) depends on \(\frac{M-M_{\rm ext}^{0}}{M}\), or equivalently on \(\frac{T-T_{0}}{T}\)
Some typical forms of low-\(T\) corrections: [Cano et al., 1910.14324]:
For \(\Delta M\approx -T_0\Delta S\), work at \(M=(1+\delta)\times M_{\rm ext}^{0}\) with \(0<\delta \ll 1\)
while maintaining \(\Delta T\ll T_0(M,\Q)\), which are
\[ S(M,\Q,\epsilon)\approx S^{0}_{\rm ext}(\Q)+F(M,\Q)\sqrt{M_{\rm ext}^{0}(\Q)\times \delta+\epsilon} \]
\(\Delta M\approx -T_0\Delta S\) holds for \(|\epsilon|\gg M_{\rm ext}\delta\)
Changed to \(\Delta M\approx -\frac{1}{2}T_0\Delta S\) holds for \(|\epsilon|\ll M_{\rm ext}\delta\)
Both sides computed at leading order in \(\delta,\epsilon\)
If \(\Delta S>0\), then \(\partial_{\epsilon}M_{\rm ext}=-T\partial_{\epsilon}S\) suggests \(\Delta M_{\rm ext}>0\)
This reasoning first used in [Cheung, Remmen, Liu, 1801.08546] as evidence for WGC
\(\partial_{\epsilon}M_{\rm ext}=-T\partial_{\epsilon}S\) can degenerate to \(0=0\) with \(\Delta S\neq 0\)
Total derivative changes \(S\), but not \(M(T,\Q)\)
Approx. \(\Delta M\approx -T_{0}\Delta S\) relation also trivial at zeroth order in \(\delta=\frac{M}{M_{\rm ext}^{0}}-1\)
Sometimes relation reads \(0=0\)
Non-generic: \(\Delta M=T=0\) and \(\Delta S\neq 0\)
Non-generic: \(\Delta M=T=0\) and \(\Delta S\neq 0\)
A gravitational example: the Gauss-Bonnet term [Cano et al, 1909.08530]
Total derivative doesn't change EOM, but does change
Ends up generating \(\Delta S\neq 0\) while keeping \(M=Q\) at extremality


--- layout: default title: EventBus Documentation permalink: /documentation/eventbus/ redirect_from: /software/eventbus/documentation/ section: software ---
Welcome to the EventBus documentation!


patients SARS-CoV- infection {border-style COVID- px;} #ffffff;} coronavirus disease transmission Epub ahead print respiratory IBD March â€". liver risk severe novel virus endoscopy acute clinical pandemic potential Wuhan, contact pneumonia px; {font-family European endoscopic font-size higher infected patients, syndrome double; elevated new treatment treatments used Endoscopy Liver SARS Society [], border-color border-width cases cells epidemic hands infection, long possible procedures research shall solid; {font-style {font-weight China. East Figure Gastroenterology However, Med. SARS-CoV-. absence antiviral associated biologics bold case characteristics courier; elective em; evidence evidenced gastrointestinal immunomodulators level local ongoing online pre-existing pt;} rapidly reported room showed spread strategy surfaces travel


each_with index
Calls block with two arguments, the item and its index, for each item in enum. Given arguments are passed through to each().If no block is given, an enumerator is returned instead.
hash = {};
array = ["seal", "giraffe", "squirrel"]
array.each_with_index { |item, index| hash[item] = index }
puts hash.inspect #=> {"seal"=>0, "giraffe"=>1, "squirrel"=>2}
max
Returns the object in enum with the maximum value. The first form assumes all objects implement Comparable; the second uses the block to return a <=> b.
a = ["albatross", "dog", "horse"]
a.max(2) #=> ["horse", "dog"]
a.max(2) {|a, b| a.length <=> b.length } #=> ["albatross", "horse"]
min
Returns the object in enum with the minimum value. The first form assumes all objects implement Comparable; the second uses the block to return a <=> b.
a = ["albatross", "dog horse"]
a.min(2) #=> ["albatross", "dog"]
a.min(2) {|a, b| a.length <=> b.length } #=> ["dog", "horse"]
include?
Returns true if any member of enum equals obj. Equality is tested using ==.
(1..10).include?(2) #=> true
inject/reduce
Combines all elements of enum by applying a binary operation, specified by a block or a symbol that names a method or operator.
(5..10).reduce(:+)
#=> 45
(5..10).inject { |sum, n| sum + n }
#=> 45
map/collect
Returns a new array with the results of running block once for every element in enum. If no block is given, an enumerator is returned instead.
(1..4).map { |i| i*i }
#=> [1, 4, 9, 16]
[3,6,9].collect { |i| i*i }
=> [9, 36, 81]
(1..4).collect { "cat" }
#=> ["cat", "cat", "cat", "cat"]
each_slice
Iterates the given block for each slice of n elements. If no block is given, returns an enumerator.
(1..10).each_slice(3) { |a| p a }
# outputs below
[1, 2, 3]
[4, 5, 6]
[7, 8, 9]
[10]


API Documentation
Introduction
This document describes the use of the Lua API for declaring the behavior of a virtual plant. The set Lua API functions can be divided into blocking, game state changing functions, as well as non-blocking information gathering ones. These functions are written from the perspective of the 'tip' of a plant. Environment modifying functions
grow("DIR")
This function takes a string literal chosen from {"left", "right", "up", "down"} which instructs the tip to grow further. It has a price in Energy, and will block until the plant has a sufficient amount.
This function splits the tip of the current node into two: one new tip and itself. The new tip will have its own copy of the script you defined, starting at the top. The <DIR> argument represents the direction that the new node will begin to travel, and the <META> argument sets a variable accessible in the new tip with the meta() function. This function requires Energy to execute.
terminate()
This function turns the current active tip node into a passive plant node.
spawn()
This function calls terminates() the current tip, and releases a 'spore', a game object that gently falls to the ground and plants a new instance of your plant. It requires Energy to execute.
wait()
This function pauses your tip until the next tick.
This functions returns the string passed in from the parent split call. If called from the stem, it returns "".
get_energy()
This function return an integer representing your plant's current energy level.
get_age()
This function return an integer representing your plant's age.
lighting("DIR")
This function takes in a Direction String and returns an integer representing the light currently available at that node.


Apple is holding a surprise event in December, but don’t expect much
by Napier LopezHere’s a surprise: Apple has one more event in store for the year, and this time it’s for… apps? The company sent out invites to an event “honoring our favorite apps and games of 2019″ taking place in NYC on December 2.
While Apple hands out awards for the year’s best apps every year, it’s never hosted a physical event it. For some reason, Apple decided it needed to go bigger.
It seems highly unlikely there’ll be new hardware on December 2, especially given it appears to be a low-key event. There doesn’t seem to be a livestream either. But hey, maybe Apple will finally tell us the release date for the new Mac Pro; it’s been teasing long enough.
Via MacRumors


The issue tracker is the preferred channel for feedback on the project,
bugs relating to the publishing infrastructure (which is still a a
work-in-progress) or other discussion points.
Note:
-
Please do not open issues or pull requests that involve including
answers to any of the questions.
-
If you have a proposal for a new question or revision of an existing
question, please just open a pull request.


| 1 | package fr.sii.ogham.core.subject.provider; | |
| 2 | ||
| 3 | import fr.sii.ogham.core.message.Message; | |
| 4 | import fr.sii.ogham.core.message.content.Content; | |
| 5 | import fr.sii.ogham.core.message.content.MultiContent; | |
| 6 | ||
| 7 | /** | |
| 8 | * Subject provider that is able to handle messages with {@link MultiContent}. | |
| 9 | * The aim is to try to generate a subject from the {@link MultiContent}. The | |
| 10 | * subject generation is delegated to another subject provider. Each part of the | |
| 11 | * {@link MultiContent} is extracted and the delegated subject provider is | |
| 12 | * called with the content part. | |
| 13 | *
 | |
| 14 | *
 | |
| 15 | * If one of the content part could be used to generate the subject then this | |
| 16 | * subject is returned.
 | |
| 17 | *
If several content parts could be used to generate the subject then only | |
| 18 | * the first generated subject is used.
 | |
| 19 | *
If none of the content part could generate a subject then | |
| 20 | * null is returned.
 | |
| 21 | *
If the content is not a {@link MultiContent} then null is returned.
 | |
| 22 | *
 | |
| 23 | * | |
| 24 | * @author Aurélien Baudet | |
| 25 | * | |
| 26 | */ | |
| 27 | public class MultiContentSubjectProvider implements SubjectProvider { | |
| 28 | /** | |
| 29 | * The delegate subject provider that is applied on every content part | |
| 30 | */ | |
| 31 | private SubjectProvider provider; | |
| 32 | ||
| 33 | public MultiContentSubjectProvider(SubjectProvider provider) { | |
| 34 | super(); | |
| 35 | this.provider = provider; | |
| 36 | } | |
| 37 | ||
| 38 | @Override | |
| 39 | public String provide(Message message) { | |
| 40 |
1
1. provide : negated conditional → RUN_ERROR |
if (message.getContent() instanceof MultiContent) { |
| 41 | MultiContent multiContent = (MultiContent) message.getContent(); | |
| 42 | for (Content content : multiContent.getContents()) { | |
| 43 |
1
1. provide : removed call to fr/sii/ogham/core/message/Message::setContent → RUN_ERROR |
message.setContent(content); |
| 44 | String subject = provider.provide(message); | |
| 45 |
1
1. provide : removed call to fr/sii/ogham/core/message/Message::setContent → RUN_ERROR |
message.setContent(multiContent); |
| 46 |
1
1. provide : negated conditional → RUN_ERROR |
if (subject != null) { |
| 47 |
1
1. provide : replaced return value with "" for fr/sii/ogham/core/subject/provider/MultiContentSubjectProvider::provide → RUN_ERROR |
return subject; |
| 48 | } | |
| 49 | } | |
| 50 | } | |
| 51 |
1
1. provide : replaced return value with "" for fr/sii/ogham/core/subject/provider/MultiContentSubjectProvider::provide → RUN_ERROR |
return null; |
| 52 | } | |
| 53 | ||
| 54 | } | |
Mutations | ||
| 40 |
1.1 |
|
| 43 |
1.1 |
|
| 45 |
1.1 |
|
| 46 |
1.1 |
|
| 47 |
1.1 |
|
| 51 |
1.1 |


| PERLGIT(1) | Perl Programmers Reference Guide | PERLGIT(1) |
You can make a read-only clone of the repository by running:
% git clone git://github.com/Perl/perl5.git perl
This uses the git protocol (port 9418).
If you cannot use the git protocol for firewall reasons, you can also clone via http:
% git clone https://github.com/Perl/perl5.git perl
% git branch * blead
Using the -a switch to "branch" will also show the remote tracking branches in the repository:
% git branch -a * blead origin/HEAD origin/blead ...
The branches that begin with "origin" correspond to the "git remote" that you cloned from (which is named "origin"). Each branch on the remote will be exactly tracked by these branches. You should NEVER do work on these remote tracking branches. You only ever do work in a local branch. Local branches can be configured to automerge (on pull) from a designated remote tracking branch. This is the case with the default branch "blead" which will be configured to merge from the remote tracking branch "origin/blead".
You can see recent commits:
% git log
And pull new changes from the repository, and update your local repository (must be clean first)
% git pull
Assuming we are on the branch "blead" immediately after a pull, this command would be more or less equivalent to:
% git fetch % git merge origin/blead
In fact if you want to update your local repository without touching your working directory you do:
% git fetch
And if you want to update your remote-tracking branches for all defined remotes simultaneously you can do
% git remote update
Neither of these last two commands will update your working directory, however both will update the remote-tracking branches in your repository.
To make a local branch of a remote branch:
% git checkout -b maint-5.10 origin/maint-5.10
To switch back to blead:
% git checkout blead
% git status
This command will produce as output a description of the current state of the repository, including modified files and unignored untracked files, and in addition it will show things like what files have been staged for the next commit, and usually some useful information about how to change things. For instance the following:
% git status On branch blead Your branch is ahead of 'origin/blead' by 1 commit. Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: pod/perlgit.pod Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: pod/perlgit.pod Untracked files: (use "git add <file>..." to include in what will be committed) deliberate.untracked
This shows that there were changes to this document staged for commit, and that there were further changes in the working directory not yet staged. It also shows that there was an untracked file in the working directory, and as you can see shows how to change all of this. It also shows that there is one commit on the working branch "blead" which has not been pushed to the "origin" remote yet. NOTE: This output is also what you see as a template if you do not provide a message to "git commit".
If you already have a Perl repository, you should ensure that you're on the blead branch, and your repository is up to date:
% git checkout blead % git pull
It's preferable to patch against the latest blead version, since this is where new development occurs for all changes other than critical bug fixes. Critical bug fix patches should be made against the relevant maint branches, or should be submitted with a note indicating all the branches where the fix should be applied.
Now that we have everything up to date, we need to create a temporary new branch for these changes and switch into it:
% git checkout -b orange
which is the short form of
% git branch orange % git checkout orange
Creating a topic branch makes it easier for the maintainers to rebase or merge back into the master blead for a more linear history. If you don't work on a topic branch the maintainer has to manually cherry pick your changes onto blead before they can be applied.
That'll get you scolded on perl5-porters, so don't do that. Be Awesome.
Then make your changes. For example, if Leon Brocard changes his name to Orange Brocard, we should change his name in the AUTHORS file:
% perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS
You can see what files are changed:
% git status On branch orange Changes to be committed: (use "git reset HEAD <file>..."  If at this time, you only want to commit some of the files you have worked on, you can omit the "-a" and use the command "git add FILE ..." before doing the commit. "git add --interactive" allows you to even just commit portions of files instead of all the changes in them.
The "-m" option is used to specify the commit message. If you omit it, git will open a text editor for you to compose the message interactively. This is useful when the changes are more complex than the sample given here, and, depending on the editor, to know that the first line of the commit message doesn't exceed the 50 character legal maximum. See "Commit message" in perlhack for more information about what makes a good commit message.
 to include in what will be committed) deliberate.untracked nothing added to commit but untracked files present (use "git add" to track)
When in doubt, before you do anything else, check your status and read it carefully, many questions are answered directly by the git status output.
You can examine your last commit with:
% git show HEAD
and if you are not happy with either the description or the patch itself you can fix it up by editing the files once more and then issue:
% git commit -a --amend
Now, create a fork on GitHub to push your branch to, and add it as a remote if you haven't already, as described in the GitHub documentation at <https://help.github.com/en/articles/working-with-forks>:
% git remote add fork git@github.com:MyUser/perl5.git
And push the branch to your fork:
% git push -u fork orange
You should now submit a Pull Request (PR) on GitHub from the new branch to blead. For more information, see the GitHub documentation at <https://help.github.com/en/articles/creating-a-pull-request-from-a-fork>.
You can also send patch files to<EMAIL_ADDRESS><EMAIL_ADDRESS>directly if the patch is not ready to be applied, but intended for discussion.
To create a patch file for all your local changes:
% git format-patch -M blead.. 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch
Or for a lot of changes, e.g. from a topic branch:
% git format-patch --stdout -M blead.. > topic-branch-changes.patch
If you want to delete your temporary branch, you may do so with:
% git checkout blead % git branch -d orange error: The branch 'orange' is not an ancestor of your current HEAD. If you are sure you want to delete it, run 'git branch -D orange'. % git branch -D orange Deleted branch orange.
To reset your working directory to a pristine condition you can do:
% git clean -dxf
However, be aware this will delete ALL untracked content. You can use
% git clean -Xf
to remove all ignored untracked files, such as build and test byproduct, but leave any manually created files alone.
If you only want to cancel some uncommitted edits, you can use "git checkout" and give it a list of files to be reverted, or "git checkout -f" to revert them all.
If you want to cancel one or several commits, you can use "git reset".
The core provides a wrapper program, Porting/bisect.pl, which attempts to simplify as much as possible, making bisecting as simple as running a Perl one-liner. For example, if you want to know when this became an error:
perl -e 'my $a := 2'
you simply run this:
.../Porting/bisect.pl -e 'my $a := 2;'
Using Porting/bisect.pl, with one command (and no other files) it's easy to find out
usually without needing to know which versions of perl to use as start and end revisions, as Porting/bisect.pl automatically searches to find the earliest stable version for which the test case passes. Run "Porting/bisect.pl --help" for the full documentation, including how to set the "Configure" and build time options.
If you require more flexibility than Porting/bisect.pl has to offer, you'll need to run "git bisect" yourself. It's most useful to use "git bisect run" to automate the building and testing of perl revisions. For this you'll need a shell script for "git" to call to test a particular revision. An example script is Porting/bisect-example.sh, which you should copy outside of the repository, as the bisect process will reset the state to a clean checkout as it runs. The instructions below assume that you copied it as ~/run and then edited it as appropriate.
You first enter in bisect mode with:
% git bisect start
For example, if the bug is present on "HEAD" but wasn't in 5.10.0, "git" will learn about this when you enter:
% git bisect bad % git bisect good perl-5.10.0 Bisecting: 853 revisions left to test after this
This results in checking out the median commit between "HEAD" and "perl-5.10.0". You can then run the bisecting process with:
% git bisect run ~/run
When the first bad commit is isolated, "git bisect" will tell you so:
ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 Author: Dave Mitchell<EMAIL_ADDRESS>Date: Sat Feb 9 14:56:23 2008 +0000 [perl #49472] Attributes + Unknown Error ... bisect run success
You can peek into the bisecting process with "git bisect log" and "git bisect visualize". "git bisect reset" will get you out of bisect mode.
Please note that the first "good" state must be an ancestor of the first "bad" state. If you want to search for the commit that solved some bug, you have to negate your test case (i.e. exit with 1 if OK and 0 if not) and still mark the lower bound as "good" and the upper as "bad". The "first bad commit" has then to be understood as the "first commit where the bug is solved".
"git help bisect" has much more information on how you can tweak your binary searches.
Following bisection you may wish to configure, build and test perl at commits identified by the bisection process. Sometimes, particularly with older perls, "make" may fail during this process. In this case you may be able to patch the source code at the older commit point. To do so, please follow the suggestions provided in "Building perl at older commits" in perlhack.
% branch="$yourname/$some_descriptive_name" % git checkout -b $branch ... do local edits, commits etc ... % git push origin -u $branch
Should you be stuck with an ancient version of git (prior to 1.7), then "git push" will not have the "-u" switch, and you have to replace the last step with the following sequence:
% git push origin $branch:refs/heads/$branch % git config branch.$branch.remote origin % git config branch.$branch.merge refs/heads/$branch
If you want to make changes to someone else's topic branch, you should check with its creator before making any change to it.
You might sometimes find that the original author has edited the branch's history. There are lots of good reasons for this. Sometimes, an author might simply be rebasing the branch onto a newer source point. Sometimes, an author might have found an error in an early commit which they wanted to fix before merging the branch to blead.
Currently the master repository is configured to forbid non-fast-forward merges. This means that the branches within can not be rebased and pushed as a single step.
The only way you will ever be allowed to rebase or modify the history of a pushed branch is to delete it and push it as a new branch under the same name. Please think carefully about doing this. It may be better to sequentially rename your branches so that it is easier for others working with you to cherry-pick their local changes onto the new version. (XXX: needs explanation).
If you want to rebase a personal topic branch, you will have to delete your existing topic branch and push as a new version of it. You can do this via the following formula (see the explanation about "refspec"'s in the git push documentation for details) after you have rebased your branch:
# first rebase % git checkout $user/$topic % git fetch % git rebase origin/blead # then "delete-and-push" % git push origin :$user/$topic % git push origin $user/$topic
NOTE: it is forbidden at the repository level to delete any of the "primary" branches. That is any branch matching "m!^(blead|maint|perl)!". Any attempt to do so will result in git producing an error like this:
% git push origin :blead *** It is forbidden to delete blead/maint branches in this repository error: hooks/update exited with error code 1 error: hook declined to update refs/heads/blead To ssh://perl5.git.perl.org/perl ! [remote rejected] blead (hook declined) error: failed to push some refs to 'ssh://perl5.git.perl.org/perl'
As a matter of policy we do not edit the history of the blead and maint-* branches. If a typo (or worse) sneaks into a commit to blead or maint-*, we'll fix it in another commit. The only types of updates allowed on these branches are "fast-forwards", where all history is preserved.
Annotated tags in the canonical perl.git repository will never be deleted or modified. Think long and hard about whether you want to push a local tag to perl.git before doing so. (Pushing simple tags is not allowed.)
296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930
It is particularly important to have this graft line if any bisecting is done in the area of the "merge" in question.
% git config remote.origin.url git@github.com:Perl/perl5.git
You can also set up your user name and e-mail address. Most people do this once globally in their ~/.gitconfig by doing something like:
% git config --global user.name "AEvar Arnfjoerd` Bjarmason" % git config --global user.email<EMAIL_ADDRESS>However, if you'd like to override that just for perl, execute something like the following in perl:
% git config user.email<EMAIL_ADDRESS>It is also possible to keep "origin" as a git remote, and add a new remote for ssh access:
% git remote add camel git@github.com:Perl/perl5.git
This allows you to update your local repository by pulling from "origin", which is faster and doesn't require you to authenticate, and to push your changes back with the "camel" remote:
% git fetch camel % git push camel
The "fetch" command just updates the "camel" refs, as the objects themselves should have been fetched when pulling from "origin".
First we need to create a temporary new branch for these changes and switch into it:
% git checkout -b experimental
Patches that were formatted by "git format-patch" are applied with "git am":
% git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch Applying Rename Leon Brocard to Orange Brocard
Note that some UNIX mail systems can mess with text attachments containing 'From '. This will fix them up:
% perl -pi -e's/^>From /From /' \ 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch
If just a raw diff is provided, it is also possible use this two-step process:
% git apply bugfix.diff % git commit -a -m "Some fixing" \ --author="That Guy<EMAIL_ADDRESS>Now we can inspect the change:
% git show HEAD commit b1b3dab48344cff6de4087efca3dbd63548ab5e2 Author: Leon Brocard<EMAIL_ADDRESS>Date: Fri Dec 19 17:02:59 2008 +0000 Rename Leon Brocard to Orange Brocard diff --git a/AUTHORS b/AUTHORS index 293dd70..722c93e 100644 --- a/AUTHORS +++ b/AUTHORS @@ -541,7 +541,7 @@ Lars Hecking<EMAIL_ADDRESS>Laszlo Molnar<EMAIL_ADDRESS>Leif Huhn<EMAIL_ADDRESS>Len Johnson<EMAIL_ADDRESS>-Leon Brocard<EMAIL_ADDRESS>+Orange Brocard<EMAIL_ADDRESS>Les Peters<EMAIL_ADDRESS>Lesley Binks<EMAIL_ADDRESS>Lincoln D. Stein<EMAIL_ADDRESS>If you are a committer to Perl and you think the patch is good, you can then merge it into blead then push it out to the main repository:
% git checkout blead % git merge experimental % git push origin blead
If you want to delete your temporary branch, you may do so with:
% git checkout blead % git branch -d experimental error: The branch 'experimental' is not an ancestor of your current HEAD. If you are sure you want to delete it, run 'git branch -D experimental'. % git branch -D experimental Deleted branch experimental.
Before pushing any local change to blead, it's incredibly important that you do a few things, lest other committers come after you with pitchforks and torches:
Sometimes, blead will move while you're building or testing your changes. When this happens, your push will be rejected with a message like this:
To ssh://perl5.git.perl.org/perl.git ! [rejected] blead -> blead (non-fast-forward) error: failed to push some refs to 'ssh://perl5.git.perl.org/perl.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.
When this happens, you can just rebase your work against the new position of blead, like this (assuming your remote for the master repository is "p5p"):
% git fetch p5p % git rebase p5p/blead
You will see your commits being re-applied, and you will then be able to push safely. More information about rebasing can be found in the documentation for the git-rebase(1) command.
For larger sets of commits that only make sense together, or that would benefit from a summary of the set's purpose, you should use a merge commit. You should perform your work on a topic branch, which you should regularly rebase against blead to ensure that your code is not broken by blead moving. When you have finished your work, please perform a final rebase and test. Linear history is something that gets lost with every commit on blead, but a final rebase makes the history linear again, making it easier for future maintainers to see what has happened. Rebase as follows (assuming your work was on the branch "committer/somework"):
% git checkout committer/somework % git rebase blead
Then you can merge it into master like this:
% git checkout blead % git merge --no-ff --no-commit committer/somework % git commit -a
The switches above deserve explanation. "--no-ff" indicates that even if all your work can be applied linearly against blead, a merge commit should still be prepared. This ensures that all your work will be shown as a side branch, with all its commits merged into the mainstream blead by the merge commit.
"--no-commit" means that the merge commit will be prepared but not committed.  Without "--no-commit", the commit would be made with nearly no useful message, which would greatly diminish the value of the merge commit as a placeholder for the work's description.
When describing the merge commit, explain the purpose of the branch, and keep in mind that this description will probably be used by the eventual release engineer when reviewing the next perldelta document.
To commit to a maintenance version of perl, you need to create a local tracking branch:
% git checkout --track -b maint-5.005 origin/maint-5.005
This creates a local branch named "maint-5.005", which tracks the remote branch "origin/maint-5.005". Then you can pull, commit, merge and push as before.
You can also cherry-pick commits from blead and another branch, by using the "git cherry-pick" command. It is recommended to use the -x option to "git cherry-pick" in order to record the SHA1 of the original commit in the new commit message.
Before pushing any change to a maint version, make sure you've satisfied the steps in "Committing to blead" above.
Fortunately, there is a way to get your change smoke-tested on various OSes: push it to a "smoke-me" branch and wait for certain automated smoke-testers to report the results from their OSes. A "smoke-me" branch is identified by the branch name: specifically, as seen on github.com it must be a local branch whose first name component is precisely "smoke-me".
The procedure for doing this is roughly as follows (using the example of of tonyc's smoke-me branch called win32stat):
First, make a local branch and switch to it:
% git checkout -b win32stat
Make some changes, build perl and test your changes, then commit them to your local branch. Then push your local branch to a remote smoke-me branch:
% git push origin win32stat:smoke-me/tonyc/win32stat
Now you can switch back to blead locally:
% git checkout blead
and continue working on other things while you wait a day or two, keeping an eye on the results reported for your smoke-me branch at <http://perl.develop-help.com/?b=smoke-me/tonyc/win32state>.
If all is well then update your blead branch:
% git pull
then checkout your smoke-me branch once more and rebase it on blead:
% git rebase blead win32stat
Now switch back to blead and merge your smoke-me branch into it:
% git checkout blead % git merge win32stat
As described earlier, if there are many changes on your smoke-me branch then you should prepare a merge commit in which to give an overview of those changes by using the following command instead of the last command above:
% git merge win32stat --no-ff --no-commit
You should now build perl and test your (merged) changes one last time (ideally run the whole test suite, but failing that at least run the t/porting/*.t tests) before pushing your changes as usual:
% git push origin blead
Finally, you should then delete the remote smoke-me branch:
% git push origin :smoke-me/tonyc/win32stat
(which is likely to produce a warning like this, which can be ignored:
remote: fatal: ambiguous argument 'refs/heads/smoke-me/tonyc/win32stat': unknown revision or path not in the working tree. remote: Use '--' to separate paths from revisions
) and then delete your local branch:
% git branch -d win32stat
| 2019-10-28 | perl v5.30.3 |


Before you start
You will need to know:
- the names of your subcontractors
- how much money you will be paying them
- the funding streams they will provide training for each subcontractor
- the number of learners or apprentices
- where the training will take place


--- title: Visual Refreshment 2009 date: 2009-01-09 21:39:25 +1100 modified: 2009-01-10 08:39:25 +1100 uid: http://paul.annesley.cc/articles/2009/01/09/visual-refreshment layout: post ---
To bring in the new year on a bright note, I decided to turf my old, tired, dark, noisy blue design. Welcome to paul.annesley.cc — 2009 edition, with a refreshed, dare I say "cleaner" white design.
Dropping a column and removing all the graphics, backgrounds, borders and so on was a simple task — a testament to CSS and the separation of structure and presentation. Adjustments to the navigation and the addition of an about page were quick thanks to Django.
Enjoy, and happy new year!


Your Quote
Input Quote
Quote By:
Input Author Name
Posted By:
Input Publisher
Completion
Complete Date is Required
Publish Quote


Unauthorized!
You are not authenticated and are trying to access content that requires authenticated access!
Go back to the storage area index page


Helipad takes the pain out of landing pages. Launch in a few clicks. Elimate wasted time fiddling with code, deployment and hosting.
Send traffic to your landing pages, experiment, test, prove ideas and collect early user data.
Work on attracting and growing a relevant audience, helping you get early traction for your idea. Fast.
To help you get started easily, Helipad comes with some simple templates. Simply pick a theme and add your content.
Choose which form fields to include on the page to maximize conversion.
Helipad has been configured for AWS Cloudformation, so it's preconfigured for deployment.
Configuration of DNS, hosting and database is automatic, so you need to spend time on configuration.
User sign-ups are stored in DynamoDB's document database. Access to information is easy, through the AWS console.
From the outset, your data is stored securely with admin-only access by default.


Fostering a community
Whether it be the creation of a hobby rocket or the large scale devlopment necessary for intercollegiate competitions, the Vancouver Rocketry Society aims to unite the community towards a central goal of helping the next generation of rocket scientists, engineers and enthusiasts.
Forming Connections
The Vancouver Rocketry Society works closely with UBC Rocket in the testing and development of rockets, and aspires to form similar bonds with other rocketry-related groups throughout greater Vancouver.
Building Something Amazing
At the end of the day, the Vancouver Rocketry Society is about trying to find the most incredible and technologically advanced ways of hurdling an earth bound object up sky high. If that sounds interesting then you're in the right place!


Howto create a batch source with the new Source framework
May 3, 2023 - Etienne Chauchot (@echauchot)Introduction #
The Flink community has designed a new Source framework based on FLIP-27 lately. Some connectors have migrated to this new framework. This article is a how-to for creating a batch source using this new framework. It was built while implementing the Flink batch source for Cassandra. If you are interested in contributing or migrating connectors, this blog post is for you!
Implementing the source components #
The source architecture is depicted in the diagrams below:
Source #
The source interface only does the “glue” between all the other components. Its role is to instantiate all of them and to define the source Boundedness . We also do the source configuration here along with user configuration validation.
SourceReader #
Example Cassandra SourceReader
As shown in the graphic above, the instances of the SourceReader (which we will call simply readers in the continuation of this article) run in parallel in task managers to read the actual data which is divided into Splits. Readers request splits from the SplitEnumerator and the resulting splits are assigned to them in return.
Flink provides the SourceReaderBase implementation that takes care of all the threading. Flink also provides a useful extension to this class for most cases: SingleThreadMultiplexSourceReaderBase . This class has the threading model already configured: each SplitReader instance reads splits using one thread (but there are several SplitReader instances that live among task managers).
What we have left to do in the SourceReader class is:
- Provide a SplitReader supplier
- Create a RecordEmitter
- Create the shared resources for the SplitReaders (sessions, etc…). As the SplitReader supplier is created in the SourceReader constructor in a super() call, using a SourceReader factory to create the shared resources and pass them to the supplier is a good idea.
- Implement start(): here we should ask the enumerator for our first split
- Override close() in SourceReaderBase parent class to free up any created resources (the shared resources for example)
- Implement initializedState() to create a mutable SplitState from a Split
- Implement toSplitType() to create a Split from the mutable SplitState
- Implement onSplitFinished(): here, as it is a batch source (finite data), we should ask the Enumerator for next split
Split and SplitState #
The SourceSplit represents a partition of the source data. What defines a split depends on the backend we are reading from. It could be a (partition start, partition end) tuple or an (offset, split size) tuple for example.
In any case, the Split object should be seen as an immutable object: any update to it should be done
on the
associated SplitState.
The split state is the one that will be stored inside the Flink
checkpoints
. A checkpoint may happen between 2 fetches for 1 split. So, if we’re reading a split, we
must store in the split state the current state of the reading process. This current state needs to
be something serializable (because it will be part of a checkpoint) and something that the backend
source can resume from. That way, in case of failover, the reading could be resumed from where it
was left off. Thus we ensure there will be no duplicates or lost data.
For example, if the records
reading order is deterministic in the backend, then the split state can store the number n of
already read records to restart at n+1 after failover.
SplitEnumerator and SplitEnumeratorState #
Example Cassandra SplitEnumerator and SplitEnumeratorState
The SplitEnumerator is responsible for creating the splits and serving them to the readers. Whenever possible, it is preferable to generate the splits lazily, meaning that each time a reader asks the enumerator for a split, the enumerator generates one on demand and assigns it to the reader. For that we implement SplitEnumerator#handleSplitRequest() . Lazy splits generation is preferable to splits discovery, in which we pre-generate all the splits and store them waiting to assign them to the readers. Indeed, in some situations, the number of splits can be enormous and consume a lot a memory which could be problematic in case of straggling readers. The framework offers the ability to act upon reader registration by implementing addReader() but, as we do lazy splits generation, we have nothing to do there. In some cases, generating a split is too costly, so we can pre-generate a batch (not all) of splits to amortize this cost. The number/size of batched splits need to be taken into account to avoid consuming too much memory.
Long story short, the tricky part of the source implementation is splitting the source data. The
good equilibrium to find is not to have too many splits (which could lead to too much memory
consumption) nor too few (which could lead to sub-optimal parallelism). One good way to meet this
equilibrium is to evaluate the size of the source data upfront and allow the user to specify the
maximum memory a split will take. That way they can configure this parameter accordingly to the
memory
available on the task managers. This parameter is optional so the source needs to provide a default
value. Also, the source needs to control that the user provided max-split-size is not too little
which would
lead to too many splits. The general rule of thumb is to let the user some freedom but protect him
from unwanted behavior.
For these safety measures, rigid thresholds
don’t work well as the source may start to fail when the thresholds are suddenly exceeded.
For example if we enforce that the number of splits is below twice the parallelism, if
the job is regularly run on a growing table, at some point there will be
more and more splits of max-split-size and the threshold will be exceeded. Of course, the size of
the source data needs to be evaluated without
reading the actual data. For the Cassandra connector it was
done like this.
Another important topic is state. If the job manager fails, the split enumerator needs to recover. For that, as for the split, we need to provide a state for the enumerator that will be part of a checkpoint. Upon recovery, the enumerator is reconstructed and receives an enumerator state for recovering its previous state. Upon checkpointing, the enumerator returns its state when SplitEnumerator#snapshotState() is called. The state must contain everything needed to resume where the enumerator was left off after failover. In lazy split generation scenario, the state will contain everything needed to generate the next split whenever asked to. It can be for example the start offset of next split, split size, number of splits still to generate etc… But the SplitEnumeratorState must also contain a list of splits, not the list of discovered splits, but a list of splits to reassign. Indeed, whenever a reader fails, if it was assigned splits after last checkpoint, then the checkpoint will not contain those splits. Consequently, upon restoration, the reader won’t have the splits assigned anymore. There is a callback to deal with that case: addSplitsBack() . There, the splits that were assigned to the failing reader, can be put back into the enumerator state for later re-assignment to readers. There is no memory size risk here as the number of splits to reassign is pretty low.
The above topics are the more important regarding splitting. There are 2 methods left to implement: the usual start() /close() methods for resources creation/disposal. Regarding implementing start(), the Flink connector framework provides enumeratorContext#callAsync() utility to run long processing asynchronously such as splits preparation or splits discovery (if lazy splits generation is impossible). Indeed, the start() method runs in the source coordinator thread, we don’t want to block it for a long time.
SplitReader #
This class is responsible for reading the actual splits that it receives when the framework calls handleSplitsChanges() . The main part of the split reader is the fetch() implementation where we read all the splits received and return the read records as a RecordsBySplits object. This object contains a map of the split ids to the belonging records and also the ids of the finished splits. Important points need to be considered:
- The fetch call must be non-blocking. If any call in its code is synchronous and potentially long, an escape from the fetch() must be provided. When the framework calls wakeUp() we should interrupt the fetch for example by setting an AtomicBoolean.
- Fetch call needs to be re-entrant: an already read split must not be re-read. We should remove it from the list of splits to read and add its id to the finished splits (along with empty splits) in the RecordsBySplits that we return.
It is totally fine for the implementer to exit the fetch() method early. Also a failure could interrupt the fetch. In both cases the framework will call fetch() again later on. In that case, the fetch method must resume the reading from where it was left off using the split state already discussed. If resuming the read of a split is impossible because of backend constraints, then the only solution is to read splits atomically (either not read the split at all, or read it entirely). That way, in case of interrupted fetch, nothing will be output and the split could be read again from the beginning at next fetch call leading to no duplicates. But if the split is read entirely, there are points to consider:
- We should ensure that the total split content (records from the source) fits in memory for example by specifying a max split size in bytes ( see SplitEnumarator)
- The split state becomes useless, only a Split class is needed
RecordEmitter #
Example Cassandra RecordEmitter
The SplitReader reads records in the form of an intermediary record format that the implementer provides for each record. It can be the raw format returned by the backend or any format allowing to extract the actual record afterwards. This format is not the final output format expected by the source. It contains anything needed to do the conversion to the record output format. We need to implement RecordEmitter#emitRecord() to do this conversion. A good pattern here is to initialize the RecordEmitter with a mapping Function. The implementation must be idempotent. Indeed the method maybe interrupted in the middle. In that case, the same set of records will be passed to the record emitter again later.
Serializers #
Example Cassandra SplitSerializer and SplitEnumeratorStateSerializer
We need to provide singleton serializers for:
- Split: splits are serialized when sending them from enumerator to reader, and when checkpointing the reader’s current state
- SplitEnumeratorState: the serializer is used for the result of the SplitEnumerator#snapshotState()
For both, we need to implement SimpleVersionedSerializer . Care needs to be taken at some important points:
- Using Java serialization is forbidden in Flink mainly for migration concerns. We should rather manually write the fields of the objects using ObjectOutputStream. When a class is not supported by the ObjectOutputStream (not String, Integer, Long…), we should write the size of the object in bytes as an Integer and then write the object converted to byte[]. Similar method is used to serialize collections. First write the number of elements of the collection, then serialize all the contained objects. Of course, for deserialization we do the exact same reading with the same order.
- There can be a lot of splits, so we should cache the OutputStream used in SplitSerializer. We can do so by using.
ThreadLocal<DataOutputSerializer> SERIALIZER_CACHE = ThreadLocal.withInitial(() -> new DataOutputSerializer(64));
The initial stream size depends on the size of a split.
Testing the source #
For the sake of concision of this article, testing the source will be the object of the next article. Stay tuned !
Conclusion #
This article gathering the implementation field feedback was needed as the javadocs cannot cover all the implementation details for high-performance and maintainable sources. I hope you enjoyed reading and that it gave you the desire to contribute a new connector to the Flink project !


public class CLDeviceCapabilities
extends java.lang.Object
| Constructor and Description |
|---|
CLDeviceCapabilities(CLDevice device) |
| Modifier and Type | Method and Description |
|---|---|
int |
getMajorVersion() |
int |
getMinorVersion() |
java.lang.String |
toString() |
public final int majorVersion
public final int minorVersion
public final boolean OpenCL11
public final boolean OpenCL12
public final boolean CL_AMD_bus_addressable_memory
public final boolean CL_AMD_device_attribute_query
public final boolean CL_AMD_device_memory_flags
public final boolean CL_AMD_fp64
public final boolean CL_AMD_media_ops
public final boolean CL_AMD_media_ops2
public final boolean CL_AMD_offline_devices
public final boolean CL_AMD_popcnt
public final boolean CL_AMD_printf
public final boolean CL_AMD_vec3
public final boolean CL_APPLE_SetMemObjectDestructor
public final boolean CL_APPLE_gl_sharing
public final boolean CL_EXT_atomic_counters_32
public final boolean CL_EXT_atomic_counters_64
public final boolean CL_EXT_device_fission
public final boolean CL_EXT_migrate_memobject
public final boolean CL_INTEL_immediate_execution
public final boolean CL_INTEL_printf
public final boolean CL_INTEL_thread_local_exec
public final boolean CL_KHR_3d_image_writes
public final boolean CL_KHR_byte_addressable_store
public final boolean CL_KHR_depth_images
public final boolean CL_KHR_fp16
public final boolean CL_KHR_fp64
public final boolean CL_KHR_gl_depth_images
public final boolean CL_KHR_gl_event
public final boolean CL_KHR_gl_msaa_sharing
public final boolean CL_KHR_gl_sharing
public final boolean CL_KHR_global_int32_base_atomics
public final boolean CL_KHR_global_int32_extended_atomics
public final boolean CL_KHR_image2d_from_buffer
public final boolean CL_KHR_initialize_memory
public final boolean CL_KHR_int64_base_atomics
public final boolean CL_KHR_int64_extended_atomics
public final boolean CL_KHR_local_int32_base_atomics
public final boolean CL_KHR_local_int32_extended_atomics
public final boolean CL_KHR_mipmap_image
public final boolean CL_KHR_mipmap_image_writes
public final boolean CL_KHR_select_fprounding_mode
public final boolean CL_KHR_spir
public final boolean CL_KHR_srgb_image_writes
public final boolean CL_KHR_subgroups
public final boolean CL_KHR_terminate_context
public final boolean CL_NV_compiler_options
public final boolean CL_NV_device_attribute_query
public final boolean CL_NV_pragma_unroll
public CLDeviceCapabilities(CLDevice device)
Copyright © 2002-2010 lwjgl.org. All Rights Reserved.


**Expressive Vector Engine**
`eve::minus`
(insert ../../../crumbs.html here)
Synopsis
====================================================================================================
**Required header:**
Function object representing the minus unary operation.
Member functions
====================================================================================================
Performs the [element-wise](../../../glossary.html#element-wise) minus operation on its parameter.
Parameters
----------------------------------------------------------------------------------------------------
`x`
: [value](../../concepts.html#value).
Return value
----------------------------------------------------------------------------------------------------
Computes [element-wise](../../../glossary.html#elment-wise) a value with the same type as `x`.
The result is the opposite of `x` if this value is representable in the type of `x`.
More specifically, for signed integers the opposite value of [their lowest finite value](../../constants.html#valmin)
is not representable and the result is undefined behaviour.
!!! WARNING
Although the operator notation with `-` is supported, the `-` operator on
standard scalar type is the original one and so can lead to automatic promotion.
Supported Decorators
====================================================================================================
[`saturated_`](../decorator/saturated.html)
: The call `saturated_(minus)(x)` computes the saturated opposite of `x`. The only interest of this behaviour is that
for integral signed type T `saturated_(minus)(Valmin< T >())` returns `Valmax< T >()` and is not u.b.
Masked calls
====================================================================================================
The [masked](../../../tutorial/masking.html) calls `minus[cond](x)` and `saturated_(minus[cond])(x)` where `cond` satisfies the
[conditionnal-expression](../../concepts.html#conditionnal) requirements are supported.
More precisely, if `cond` is
a mere [logical value](../../concepts.html#value) these expressions compute the opposite (resp the saturated opposite) of `x`
if the condition `cond` is satisfied else returns `x`. The calls are respectively equivalent to :
.
* `if_else(cond, minus(x), x)`,
* `if_else(cond, saturated_(minus)(x), x)`;
(insert ../../src/minus.src.html here)
(insert ../../out/minus.out.html here)
See Also
====================================================================================================
[eve::plus](./plus.html)


|
Welcome, friends, to the Rotten Library, an unforgettable collection of all that mankind swore to forget, but which we have trapped in agonizing clarity to remember always. Step carefully and remember the location of the eyewash stations as we present to you the lowest that we have traveled and the worst of what we have become. Enjoy! And remember the words of our head librarian:
"We are all in this together, but we all die alone."
|


{% for form in resource_image_formset %}
{% with forloop.counter0 as id %}
{{ form.id }}
{{ form.resource }}
{% include "respa_admin/forms/_select.html" with field=form.type inline=True %}
{% include "respa_admin/forms/_input.html" with field=form.caption_fi inline=True %}
{% include "respa_admin/forms/_input.html" with field=form.caption_en inline=True %}
{% include "respa_admin/forms/_input.html" with field=form.caption_sv inline=True %}
{% if form.instance.image %}
{% include "respa_admin/forms/_image.html" with field=form.image image=form.instance.image.url id=id %}
{% else %}
{% include "respa_admin/forms/_image.html" with field=form.image image=None id=id %}
{% endif %}


<<< BACK <<<
STM-114: ContractLarva
Authors
Ellul, Joshua and Pace, Gordon J
Venue and Year
EDCC, 2018
Original Work
Runtime Verification of Ethereum Smart Contracts
Defense Modality
Additive
Core Method(s)
code synthesis
Input-Output Mapping
source code + specifications => source code
Targeted Contracts
Any Ethereum
Threat Model
Vulnerable contract, malicious contract, or both
both
Targeted Vulnerabilities