Method, ram block and ram blowout preventer (BOP) for sealing a well. The BOP includes a body having a first chamber extending along a first direction and a second chamber extending along a second direction, substantially perpendicular to the first direction; a ram block configured to move inside the first chamber, the ram block having a packer region and at least one channel that extends all the way through the ram block; a packer configured to be provided in the packer region to seal a tool provided inside the second chamber; and at least one double piston provided through the at least one channel so that a pressure from the well is transmitted to the packer.
1. Technical Field
Embodiments of the subject matter disclosed herein generally relate to methods and devices and, more particularly, to mechanisms and techniques for increasing a pressure applied to a ram blowout preventer (BOP) for sealing a wellbore.
2. Discussion of the Background
One apparatus for sealing a well is the ram BOP. The ram BOP (herein simply BOP) is a safety mechanism that is used at a wellhead of an oil or gas well. The BOP may be used for offshore drilling and also for land-based drilling. The BOP is configured to shut the flow from the well when certain events occur. One such event may be the uncontrolled flow of gas, oil or other well fluids (e.g., mud) from an underground formation into the well. Such event is sometimes referred to as a “kick” or a “blowout” and may occur when formation pressure exceeds the pressure generated by the column of drilling fluid. This event is unforeseeable and if no measures are taken to prevent and/or control it, the well and/or the associated equipment may be damaged.
The BOP may be installed on top of the well to seal the well in case that one of the above events is threatening the integrity of the well. The BOP is conventionally configured to prevent the release of pressure either in the annular space between the casing and the drill pipe or in the open hole (i.e., hole with no drill pipe) during drilling or completion operations.
In this regard, the BOP has two ram blocks that are configured to move towards each other or away from each other as desired by the operator of the rig. The operator of the rig controls the closing and opening of the ram blocks by activating various valves that control a hydraulic fluid. The hydraulic fluid is either provided from accumulators provided next to the BOP (e.g., undersea for an undersea BOP) or through pipes from the surface. By allowing the hydraulic fluid under pressure to enter a closing chamber the ram blocks are closed and by allowing the hydraulic fluid to enter an opening chamber the ram blocks are opened.
The ram blocks have at their frontal faces an elastomeric material, a packer, that has a semi-spherical profile. Thus, when the drill line is still inside (i.e., crossing the BOP) and there is a need to close the well, the ram blocks close around the drill line and the profile of the packers ensure that an interface between the drill line and the ram blocks is sealed. It is noted that shearing ram blocks have cutting edges instead of packers and when there is a need to close the BOP, the shearing ram blocks will close the well by severing the drill line.
However, in practice it is noted that sometimes the interface between the packers and the drill line is not completely sealed, i.e., there is a leakage of mud or other fluids that are present in the well. The leak is more serious as the diameter of the drill line increases. Thus, there is a need in the industry to provide a better sealing when a ram block with a packer is used to close a well while a tool is still inside the BOP.
Accordingly, it would be desirable to provide systems and methods that achieve the sealing of the well irrespective of the diameter of the drill line and to avoid the above noted shortcomings.
According to one exemplary embodiment, there is a ram blowout preventer (BOP) for sealing a well. The ram blowout preventer includes a body having a first chamber extending along a first direction and a second chamber extending along a second direction, substantially perpendicular to the first direction; a ram block configured to move inside the first chamber, the ram block having a packer region and at least one channel that extends all the way through the ram block; a packer configured to be provided in the packer region to seal a tool provided inside the second chamber; and at least one double piston provided through the at least one channel so that a pressure from the well is transmitted to the packer.
According to another exemplary embodiment, there is a ram block configured to move inside a first chamber of a ram blowout preventer (BOP). The ram block includes a packer region and at least one channel that extends all the way through the ram block; a packer configured to be provided in the packer region to seal a tool provided inside a second chamber of the BOP; and at least one double piston provided through the at least one channel so that a pressure from a well to which the BOP is attached is directly transmitted to the packer.
According to still another exemplary embodiment, there is a method for manufacturing a ram block for a ram blowout preventer. The method includes providing a ram block; forming a packer region in the ram block; forming at least one channel that extends all the way through the ram block; installing at least one double piston through the at least one channel; and installing a packer in the packer region so that a first piston side of the double piston contacts the packer when pressure is applied on a second piston side of the double piston.
According to yet another exemplary embodiment, there is a method of operating a ram blowout preventer (BOP) for sealing a well. The method includes activating a primary system for closing a ram block to seal with a packer a tool provided in the BOP; and applying well pressure on a double piston provided through at least one channel of the ram block so that a first piston side of the double piston directly applies a corresponding force on the packer.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:
figref[FIG. 1] is a schematic diagram illustrating a BOP with novel ram blocks according to an exemplary embodiment;
figref[FIG. 2] is a schematic diagram of a back view of a ram block according to an exemplary embodiment;
figref[FIG. 3] is a front view of a ram block according to an exemplary embodiment;
figref[FIG. 4] is a back view of a ram block having two channels according to an exemplary embodiment;
figref[FIG. 5] is an overall view of a double piston to be added to a ram block according to an exemplary embodiment;
figref[FIG. 6] is a front view of a ram block having metal plates according to an exemplary embodiment;
figref[FIG. 7] is an overall view of a packer having metal inserts according to an exemplary embodiment;
figref[FIG. 8] is a top view of a ram block having a double piston according to an exemplary embodiment;
figref[FIG. 9] is a flow chart of a method for assembling a ram block with a double piston according to an exemplary embodiment; and
figref[FIG. 10] is a flow chart of a method for operating a BOP with ram blocks having double pistons according to an exemplary embodiment.
The following description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. The following embodiments are discussed, for simplicity, with regard to the terminology and structure of a ram BOP. However, the embodiments to be discussed next are not limited to these systems, but may be applied to other systems, i.e., a gate valve.
Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the subject matter disclosed. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification is not necessarily referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.
According to an exemplary embodiment, a ram BOP is configured to have ram blocks provided with at least one through-channel that accommodates a corresponding double piston. The double piston has a first face exposed to a fluid that is present in a wellbore and a second face that contacts a packer of the ram block. The pressure from the wellbore is exerted on the packer for a better sealing of a tool present in the BOP.
Novel features of this ram BOP are now discussed with regard to the figures. figref[FIG. 1] illustrates a cut view of a BOP 16. The BOP 16 has ram blocks 20 configured to move along a longitudinal first chamber 18. A second chamber 19, substantially perpendicular on the first chamber 18, is configured to accommodate a tool 21, e.g., a drill line. The term “substantially” here means that even if the direction of the first chamber makes an angle in the range of 85 to 95 degrees with the direction of the second chamber, the two chambers are still considered perpendicular. Thus, the second chamber 19 is open while the first chamber 18 is closed. The ram blocks 20 are shown closed on the tool 21 inside the first chamber 18.
A primary activation mechanism for the ram blocks 20 includes a closing chamber 22 and an opening chamber 24 (having a substantially zero volume when the ram blocks are closed as in figref[FIG. 1] ). A piston 26 is provided between the closing chamber 22 and the opening chamber 24. A rod 28 is attached to the piston 26 and is also configured to connect to the ram block 20. Thus, when pressure in the closing chamber 22 overcomes the pressure in the opening chamber 24, the piston 24 moves to left in figref[FIG. 1] , closing the ram block 20 (i.e., pressing the ram block on the drill line 21). This is the primary system for applying pressure on the ram blocks and on the packers. A packer 30 is shown on a frontal face of the ram block 20. The packer 30 contacts the drill line 21 for a better seal.
When a pressure in the wellbore 40 needs to be controlled, the ram blocks 20 are closed. The increasing pressure in the wellbore 40 determines the ram blocks 20 to be pressed upward, i.e., along a Z direction in figref[FIG. 1] . A seal 31 is provided on an upper part of the ram block 20 to achieve a seal between the ram block 20 and a body 42 of the ram BOP 16. A further seal 44 may be provided to further increase the seal between the ram block and the body of the BOP. This means that a fluid present in the wellbore 40, e.g., mud, may enter the first chamber 18 but should not be able to pass past the packer 30 into a first region 50 of the second chamber 19.
The pressure of the wellbore that is present in the first chamber 18 may be used to apply further pressure on the packer 30 as discussed now with regard to figref[FIG. 2] . figref[FIG. 2] shows a side back view of a ram block 20. The ram block 20 has a back portion 60 that is configured to connect to the rod 28 and a frontal portion 62 that is configured to hold the packer 30. The frontal portion 62 is configured to face the drill line 21 when the ram blocks 20 are closed. figref[FIG. 2] also illustrates a groove 64 that is configured to accommodate seal 31 for achieving the seal between the body 42 of the ram BOP and the ram block 20.
A channel 70 is illustrated in figref[FIG. 2] on the side of the ram block 20. The channel 70 passes all the way through the ram block 20, i.e., from a side that communicates with the first chamber 18 to a side that communicates with the packer 30. One or more such channels 70 may be formed in each ram block 20, depending on the type of ram block, its geometry, and the available space.
figref[FIG. 3] is a front view of the ram block 20 and shows the other end of the channel 70. figref[FIG. 3] also shows a packer region 66 that is configured to receive the packer 30. figref[FIG. 4] is a back view of the ram block 20 and illustrates an embodiment in which there are two channels 70 per ram block 20. Each channel 70 is configured to accommodate a double piston 80 as shown in figref[FIG. 5] .
The double piston 80 of figref[FIG. 5] has a central portion 82 that connects to two piston sides 84 and 86. The piston side 84 is configured to directly contact the packer 30 while the piston side 86 is configured to contact the fluid existent in the wellbore. In one application, the size of the piston side 86 is larger than the size of the piston side 84 in order to multiply a pressure effect of the wellbore on the packer. The double piston 80 may be made of a metal or composite that can withstand the large pressures and temperatures existing in a wellbore and also the corrosive environment in the wellbore. A shape of the piston side 84 may be made to match a shape of the corresponding packer 30. For example, the piston side 84 may have an elliptical shape. Various other shapes may be used. One or both of the piston sides 84 and 86 may be attached to the central part 82 by various means. Such means may be screws, welding, etc.
figref[FIG. 6] shows an embodiment in which the channel 70 has a cross-section larger than a cross-section of the piston side 84. Thus, a plate 90 is bolted with bolts 92 to the ram block 20 and the plate 90 has an opening configured to accommodate the piston side 84 as shown in the figure. Other mechanisms may be envisioned for providing the double piston 80 into the channel 70.
The packer may be a conventional one piece elastomer or a more sophisticated one as shown in figref[FIG. 7] . The packer 100 shown in figref[FIG. 7] has plural metallic inserts 102 partially provided inside the elastomeric part 104. The profile of the metallic inserts 102 and the flexibility of the elastomeric part 104 make the packer 100 to have a variable radius R. This means that a single packer 100 (variable radius packer) is configured to mate with drill lines (or other tools) having various diameters. For such a packer, the secondary pressure mechanism discussed above is more advantageous than for a conventional one piece elastomer that is designed for a drill line having a given radius. Thus, the sealing of the variable radius packer 100 can be improved by using the channels 70 and double piston 82.
One advantage provided by one or more of the exemplary embodiments presented above is now discussed. A shape of a face of some of the packers is elliptical. Thus, when the ram blocks are closed to seal a tool, the packers do not completely seal the tool due to this specific shape. This problem is illustrated in figref[FIG. 8] . figref[FIG. 8] shows the at least one channel 70 through the ram block 20 and also the components of the double piston 80, i.e., the first piston side 84 facing the packer 30 and the second piston side 86 facing a pressure well. As the packer 30 does not completely seal a region A defined by an interface between the tool 21 and the packer 30, the extra pressure applied by the well fluid at 100 on the second piston side 86 helps to bring the packer 30 closer to the tool 21 in region A as the first piston side 84 directly presses the packer 30 toward the tool 21. Thus, a better seal is achieved by using the double piston 80.
In another application, a spring 102 or equivalent means is provided between the second piston side 86 and the body of the ram block 20 so that only a certain well pressure (above the threshold pressure established by the spring 102) is applied on the packer 30.
According to an exemplary embodiment illustrated in figref[FIG. 9] , there is a method for manufacturing a ram block for a ram blowout preventer. The method includes a step 900 of providing a ram block ( 20); a step 902 of forming a packer region ( 64) in the ram block ( 20); a step 904 of forming at least one channel ( 70) that extends all the way through the ram block ( 20); a step 906 of installing at least one double piston ( 80) through the at least one channel ( 70); and a step 908 of installing a packer ( 30) in the packer region ( 64) so that a first piston side ( 84) of the double piston ( 80) contacts the packer ( 30) when pressure is applied on a second piston side ( 86) of the double piston ( 80).
According to another exemplary embodiment illustrated in figref[FIG. 10] , there is a method of operating a ram blowout preventer for sealing a well. The method includes a step 1000 of activating a primary system ( 22, 24, 26, 28) for closing a ram block ( 20) to seal with a packer ( 30) a tool ( 21) provided in the BOP ( 16); and a step 1002 of applying well pressure on a double piston ( 80) provided through at least one channel ( 70) of the ram block ( 20) so that a first piston side ( 84) of the double piston ( 80) directly applies a corresponding force on the packer ( 30).
The disclosed exemplary embodiments provide a ram block, blowout preventer and method for improving a seal between a packer and a tool in a BOP. It should be understood that this description is not intended to limit the invention. On the contrary, the exemplary embodiments are intended to cover alternatives, modifications and equivalents, which are included in the spirit and scope of the invention as defined by the appended claims. Further, in the detailed description of the exemplary embodiments, numerous specific details are set forth in order to provide a comprehensive understanding of the claimed invention. However, one skilled in the art would understand that various embodiments may be practiced without such specific details.
Although the features and elements of the present exemplary embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein.
This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other example are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements within the literal languages of the claims.


|
My Project
|
An iterator over values a switch variable can take. More...
#include <jumptable.hh>
Public Member Functions | |
| virtual void | truncate (int4 nm)=0 |
| Truncate the number of values to the given number. | |
| virtual uintb | getSize (void) const =0 |
| Return the number of values the variables can take. | |
| virtual bool | contains (uintb val) const =0 |
| Return true if the given value is in the set of possible values. | |
| virtual bool | initializeForReading (void) const =0 |
| Initialize this for iterating over the set of possible values. More... | |
| virtual bool | next (void) const =0 |
| Advance the iterator, return true if there is another value. | |
| virtual uintb | getValue (void) const =0 |
| Get the current value. | |
| virtual Varnode * | getStartVarnode (void) const =0 |
| Get the Varnode associated with the current value. | |
| virtual PcodeOp * | getStartOp (void) const =0 |
| Get the PcodeOp associated with the current value. | |
| virtual bool | isReversible (void) const =0 |
| Return true if the current value can be reversed to get a label. | |
| virtual JumpValues * | clone (void) const =0 |
| Clone this iterator. | |
An iterator over values a switch variable can take.
This iterator is intended to provide the start value for emulation of a jump-table model to obtain the associated jump-table destination. Each value can be associated with a starting Varnode and PcodeOp in the function being emulated, via getStartVarnode() and getStartOp().
|
pure virtual |
Initialize this for iterating over the set of possible values.
Implemented in JumpValuesRangeDefault, and JumpValuesRange.


Reported manual date-time manipulations are introducing DST (summer/winter time shifts) issues and shall be replaced with using DateTime layer.


TidTipFinder¶
-
class
Data_Reduction.TAMS_tipping.
TidTipFinder
(dss=43, remote=True, date=None)¶ Bases:
object
- Attributes::
am directory files logger tsys
Methods Summary
get_session_files
(date)Get the files for the specified data
get_tipping_data
(filename)Gets tipping data from a file made with observatoryCtrl
plot_elevations
(index[, tipfiles])Plots tipping curve data from a specified file
sort_by_time
([name_template, subdir])Returns a time-ordered dict of tipping files with UNIX times as keys
Methods Documentation
-
get_session_files
(date)¶ Get the files for the specified data
-
get_tipping_data
(filename)¶ Gets tipping data from a file made with observatoryCtrl
-
plot_elevations
(index, tipfiles=None)¶ Plots tipping curve data from a specified file
:param tipfiles : dict keyed on filename with file times :type tipfiles : dict
:param index : file in tipfiles to be plotted :type index : int
-
sort_by_time
(name_template='tipping_data', subdir=None)¶ Returns a time-ordered dict of tipping files with UNIX times as keys
:param directory : where the files are :type directory : str
:param name_template : part of name common to all files :type name_template : str
- Returns
dict keyed on filenames


Preparation time
less than 30 mins
Cooking time
less than 10 mins
Serves
Serves 4
For the veal, heat a griddle pan until hot. Brush the veal with half of the olive oil and press the smallest pieces of rosemary onto the surface of the veal.
Season with salt and freshly ground black pepper and place the veal directly on the griddle pan. Griddle on both sides for 1-2 minutes each (for rare), or until cooked to your liking, then remove and place on a warm plate, covered, to rest.
Meanwhile, heat a frying pan until hot, add the remaining olive oil and the mushrooms. Fry for 2-3 minutes until browned, then season with a little salt and freshly ground black pepper.
Add the crushed garlic and butter to the pan, reduce the heat and cook for one more minute. Add the chopped parsley and lemon juice and stir to combine. Taste again and adjust the seasoning as necessary.
For the salad, mix the salad leaves together with the walnuts in a salad bowl.
In a small bowl, whisk the sherry vinegar and olive oil together. Pour the dressing over the salad leaves and mix well.
To serve, slice the veal on the diagonal, and place onto four serving plates. Spoon the mushrooms over the top and serve the salad on the side.


for_each
|
|
| Category: algorithms |
Component type: function |
Prototype
template <class InputIterator, class UnaryFunction>
UnaryFunction for_each(InputIterator first, InputIterator last, UnaryFunction f);
Description
For_each applies the function object f to each element in the
range [first, last); f's return value, if any, is ignored.
Applications are performed in forward order, i.e. from first to
last. For_each returns the function object after it has been
applied to each element. [1]
Definition
Defined in algo.h.
Requirements on types
-
InputIterator is a model of Input Iterator
-
UnaryFunction is a model of Unary Function
-
UnaryFunction does not apply any non-constant operation through
its argument.
-
InputIterator's value type is convertible to UnaryFunction's
argument type.
Preconditions
-
[first, last) is a valid range.
Complexity
Linear. Exactly last - first applications of UnaryFunction.
Example
template<class T> struct print : public unary_function<T, void>
{
print(ostream& out) : os(out), count(0) {}
void operator() (T x) { os << x << ' '; ++count; }
ostream& os;
int count;
};
int main()
{
int A[] = {1, 4, 2, 8, 5, 7};
const int N = sizeof(A) / sizeof(int);
print<int> P = for_each(A, A + N, print<int>(cout));
cout << endl << P.count << " objects printed." << endl;
}
Notes
[1]
This return value is sometimes useful, since a function object
may have local state. It might, for example, count the number of
times that it is called, or it might have a status flag to indicate
whether or not a call succeeded.
See also
The function object overview, count, copy
Copyright © 1996 Silicon Graphics, Inc.
|


KotlinFiler(processingEnv: ProcessingEnvironment)
The Kotlin Filer is used to make a file in an specific directory


| ID | {{job.id}} |
| Name | {{job.name}} |
| Owner | {{job.owner}} |
| Status | {{job.status}} |
| Execution System | {{job.executionSystem}} |
| Archive | {{job.archive}} |
| Archive System | {{job.archiveSystem}} |
| Archive Path | {{job.archivePath}} |
| Output Path | {{job.outputPath}} |
| Batch Queue | {{job.batchQueue}} |
| Application ID | {{job.appId}} |


--- layout: post title: "Introducing kdeconnect.el: My First Emacs Package" permalink: /:title/ tags: [emacs, lisp, kde connect] ---
I've used Emacs since I was an impressionable sophomore in college hearing about this weird old program's ability to integrate with everything a social scientist needs: R, LaTeX, Bash, and just about anything else you can do with text on a computer. Though I started using GNU/Linux casually in middle school1, I never really learned about how any of it worked or the culture around free software until I played with Arch Linux for the first time.2 While Arch started it, Emacs is the piece of software that has stayed with me the most. For just about any computing task that isn't browsing the web or playing games,3 Emacs is front and center. I am heavily indebted to the Emacs community for writing extensions such as Emacs Speaks Statistics, AUCTeX, and org-mode that are integral to my workflow.
Today I am proud to contribute my first piece of software back to Emacs: kdeconnect.el, now available in MELPA. It's an Emacs interface to the fantastic KDE Connect library that lets you communicate with your Android devices from Emacs. You can send files, make your phone ring, send notifications, etc. Note that KDE Connect is currently only available on GNU/Linux, but it does not require you to use KDE.
At its heart, kdeconnect.el is simply a wrapper for the CLI version of KDE Connect.
I'm very appreciative of the efforts KDE Connect has made to ensure that their work can be easily accessed by scripts and other programs, as it made my life much easier.
Everything I needed to know was just a kdeconnect-cli --help
away.
Usage is similarly simple.
Install via MELPA, add your device IDs to your init.el
file, choose an active device either via init.el
or kdeconnect-select-active-device
, and have fun.
More detailed instructions are available at the source repo.
While the KDE Connect side of things was easy, there was the matter of learning some Emacs Lisp before I could write kdeconnect.el. After months of firing up Dolphin just to send files to my phone, I finally decided I'd had enough and started learning what all these parentheses and setqs were about. Emacs' help documents were a great start, and I'm very thankful to the Emacs IRC chat room for some help I received there that helped me get started. It's an easy enough language to pick up for basic things, but more importantly, I now grok Emacs much better than before and feel like I've made the jump to "intermediate" Emacs user.
Special thanks also to Syohei Yoshida and Steve Purcell for giving my code a once-over upon submission to MELPA. Emacs might be almost twice my age, but thanks to its community, it feels as spry and healthy as any other program I use.
The first computer I ever bought for myself was an Acer netbook I got for $220 on Newegg in 2008. Those were the days of 10.1" screens, 90% keyboards, and touchpads that shared their dimensions with some of the larger sticks of gum.  I had heard about Ubuntu Netbook Remix somewhere online and installed it. It was a great little OS, snappy and self-explanatory. Even my friends had no issues using it despite their zero GNU/Linux experience compared to my epsilon experience.
I don't use Arch anymore, but I learned more in the year I spent with it than my five or six years with Ubuntu. I respect its simple elegance and fantastic documentation but find openSUSE to be more appropriate for my needs.


This is the page where you can find out all about me and the things I am working on. Don't mind the nerdy touch.
If you are fond of the terminal, you can find out more about me by using it with the common unix commands. (Let me know it I am missing some through the contact form!)
Else you can check out what my site has to offer down below ↓
If you have any questions regarding this site or some of my work or even just want to have a nice conversation you can hit me up through the contact form.
Else If you want to suggest something for this site feel free to open an issue or a pull request on GitHub here.
Else I don't know what could possibly be of interest on this part of the page. (The only reason I haven't stopped talking yet is that this space needs to be filled, otherwise the contact form looks so deserted)


{% extends "app/layout.html" %} {% block content %}
Course home for {{ courseid }} in {{ subject }}
Search Courses »


{{basics.website}}
{{basics.email}}
{{basics.location.city}}, {{basics.location.region}} {{basics.location.countryCode}}
{{basics.summary}}
This resume is open source code.
Check it out on GitHub!
{{school.startDate | DateYearMonth}} — {{school.endDate | DateYearMonth}}


- ACTION_BUTTONS - Static variable in class it.polimi.se2019.client.util.Constants
-
- ACTION_TILE - Static variable in class it.polimi.se2019.client.util.Constants
-
- ACTIONS - Static variable in class it.polimi.se2019.util.DeserializerConstants
-
- ActionsDeserializer - Class in it.polimi.se2019.server.deserialize
-
- ActionsDeserializer() - Constructor for class it.polimi.se2019.server.deserialize.ActionsDeserializer
-
- ActionsDeserializerSupplier - Class in it.polimi.se2019.server.deserialize
-
- ActionsDeserializerSupplier() - Constructor for class it.polimi.se2019.server.deserialize.ActionsDeserializerSupplier
-
- ActionUnit - Class in it.polimi.se2019.server.actions
-
The action unit is the basic action used in the game, it has effects and conditions to be triggered.
- ActionUnit(boolean, String, String, List<Effect>, List<Condition>, boolean, int, int, boolean) - Constructor for class it.polimi.se2019.server.actions.ActionUnit
-
Default constructor
- ACTIONUNIT - Static variable in class it.polimi.se2019.util.CommandConstants
-
- ACTIONUNIT - Static variable in class it.polimi.se2019.util.DeserializerConstants
-
- ActionUnitDeserializer - Class in it.polimi.se2019.server.deserialize
-
- ActionUnitDeserializer() - Constructor for class it.polimi.se2019.server.deserialize.ActionUnitDeserializer
-
- ActionUnitDeserializerSupplier - Class in it.polimi.se2019.server.deserialize
-
- ActionUnitDeserializerSupplier() - Constructor for class it.polimi.se2019.server.deserialize.ActionUnitDeserializerSupplier
-
- actionUnitName - Variable in class it.polimi.se2019.server.actions.conditions.Distance
-
- actionUnitName - Variable in class it.polimi.se2019.server.actions.effects.Damage
-
- ActionUnitTest - Class in it.polimi.se2019.server.actions
-
- ActionUnitTest() - Constructor for class it.polimi.se2019.server.actions.ActionUnitTest
-
- AddAmmo - Class in it.polimi.se2019.server.actions.effects
-
This effect adds ammo to the curent player of an amout specified by the ammoToAdd parameter.
- AddAmmo(Map<AmmoColor, Integer>) - Constructor for class it.polimi.se2019.server.actions.effects.AddAmmo
-
Default constructor.
- addAmmo(Map<AmmoColor, Integer>) - Method in class it.polimi.se2019.server.games.player.CharacterState
-
The addAmmo method adds a certain amount of new ammo to the ammoBag;
it keeps an ammo color's max value to 3.
- addDamage(PlayerColor, Integer, Game) - Method in class it.polimi.se2019.server.games.player.CharacterState
-
This method add damages on the damage bar.
- addDeath(Player, boolean) - Method in class it.polimi.se2019.server.games.Game
-
This method is called when a player is killed.
- addDeath(Player, boolean) - Method in class it.polimi.se2019.server.games.KillShotTrack
-
Adds the player death to the kill shot track and notifies all the players for score update.
- addEdge(T, T) - Method in class it.polimi.se2019.server.graphs.Graph
-
Ad an edge between two vertex.
- addErrorMessage(String) - Static method in class it.polimi.se2019.server.controller.ControllerState
-
Adds an error message to the list of stored error messages (errorMessages).
- addInput(String, String) - Method in class it.polimi.se2019.client.gui.GUIController
-
The addInput method receives a key string and an id string to build the input.
- addMarker(PlayerColor, Integer) - Method in class it.polimi.se2019.server.games.player.CharacterState
-
This method allow the user to set markers on the character.
- addMoveActionFailure(Boolean) - Method in class it.polimi.se2019.server.games.Game
-
This method adds a boolean to the moveActionFailure.
- AddPowerUp - Class in it.polimi.se2019.server.actions.effects
-
This effect gives a powerUp to the current player.
- AddPowerUp() - Constructor for class it.polimi.se2019.server.actions.effects.AddPowerUp
-
- addPowerUp(PowerUp) - Method in class it.polimi.se2019.server.games.player.CharacterState
-
This method allow the user to add a power up card to player's power up bag.
- AddPowerUpTest - Class in it.polimi.se2019.server.actions.effects
-
- AddPowerUpTest() - Constructor for class it.polimi.se2019.server.actions.effects.AddPowerUpTest
-
- addUpdateToBuffer(StateUpdate) - Method in class it.polimi.se2019.server.net.CommandHandler
-
The buffer adder
- addUserToWaitingList(UserData, CommandHandler) - Method in class it.polimi.se2019.server.games.GameManager
-
This method adds a new user to the waiting list and starts a ping daemon fr that player.
- addUserToWaitingList(UserData, CommandHandler, boolean) - Method in class it.polimi.se2019.server.games.GameManager
-
This method adds a new user to the waiting list.
- addVertex(T) - Method in class it.polimi.se2019.server.graphs.Graph
-
Method to add a vertex in the graph.
- addWeapon(Weapon) - Method in class it.polimi.se2019.server.games.player.CharacterState
-
This method allow the user to add a weapon in the player's weapon bag.
- AllWeaponTest - Class in it.polimi.se2019.server.cards.weapons
-
- AllWeaponTest() - Constructor for class it.polimi.se2019.server.cards.weapons.AllWeaponTest
-
- AlreadyPlayingException(String) - Constructor for exception it.polimi.se2019.server.games.GameManager.AlreadyPlayingException
-
- AMMO - Static variable in class it.polimi.se2019.client.util.Constants
-
- AMMO_PATH - Static variable in class it.polimi.se2019.client.util.Constants
-
- AmmoColor - Enum in it.polimi.se2019.server.games.player
-
This enum contains the possible colors for the ammp.
- AMMOCOLOR - Static variable in class it.polimi.se2019.util.CommandConstants
-
- AmmoCrate - Class in it.polimi.se2019.server.cards.ammocrate
-
The ammocrate has nothing more than a normal card
- AmmoCrate(List<ActionUnit>, String) - Constructor for class it.polimi.se2019.server.cards.ammocrate.AmmoCrate
-
- AMMOCRATEDECK - Static variable in class it.polimi.se2019.util.DeserializerConstants
-
- AmmoCrateDeserializer - Class in it.polimi.se2019.server.deserialize
-
- AmmoCrateDeserializer() - Constructor for class it.polimi.se2019.server.deserialize.AmmoCrateDeserializer
-
- AmmoCrateDeserializerSupplier - Class in it.polimi.se2019.server.deserialize
-
- AmmoCrateDeserializerSupplier() - Constructor for class it.polimi.se2019.server.deserialize.AmmoCrateDeserializerSupplier
-
- AmmoCrateUpdate - Class in it.polimi.se2019.server.dataupdate
-
This update message is sent by the model to the views when one the ammo crates is re-spawned.
- AmmoCrateUpdate(int, int, AmmoCrate) - Constructor for class it.polimi.se2019.server.dataupdate.AmmoCrateUpdate
-
Builds a new AmmoCrateUpdate message.
- AmmoTest - Class in it.polimi.se2019.server.actions.effects
-
- AmmoTest() - Constructor for class it.polimi.se2019.server.actions.effects.AmmoTest
-
- amount - Variable in class it.polimi.se2019.server.actions.conditions.Distance
-
- amount - Variable in class it.polimi.se2019.server.actions.effects.Damage
-
- AMOUNT - Static variable in class it.polimi.se2019.util.DeserializerConstants
-
- applyAction(PlayerAction) - Method in class it.polimi.se2019.server.controller.Controller
-
This method is used to execute an action
- askInput() - Method in class it.polimi.se2019.client.cli.CLIView
-
Not used
- askInput() - Method in class it.polimi.se2019.client.gui.GUIView
-
The askInput method removes a runnable object from the list of request input.
- askInput() - Method in class it.polimi.se2019.client.View
-
The askInput method runs a runnable function from the input requested list.
- askUserInput(String) - Method in class it.polimi.se2019.client.cli.CLIUtil
-
This is one of the many ways to ask the user a question, here you just provide a question
- askUserInput(String, String) - Method in class it.polimi.se2019.client.cli.CLIUtil
-
This is one of the many ways to ask the user a question, here you just provide a question and a default answer
that is convenient for the user
- askUserInput(String, List<String>, Boolean) - Method in class it.polimi.se2019.client.cli.CLIUtil
-
This is one of the many ways to ask the user a question, here you just provide a question and the valid responses
to choose from, the print layout can be numbered or not.
- askUserInput(String, String, List<String>, Boolean) - Method in class it.polimi.se2019.client.cli.CLIUtil
-
This is one of the many ways to ask the user a question, here you just provide a question, the valid responses
to choose from, the print layout can be numbered or not and the default answer
- AVAILABLE - Static variable in class it.polimi.se2019.util.DeserializerConstants
-


HTML Video
Your browser does not support HTML5 video.
Play/Pause
Big
Small
Normal
HTML Audio
Your browser does not support the audio element.
HTML Plug-ins
HTML YouTube Videos


--- layout: post status: publish published: true title: IU Fan's Analysis of Kyle Schwarber author: display_name: DeRose login: DeRose email<EMAIL_ADDRESS>url: '' author_login: DeRose author_email<EMAIL_ADDRESS>wordpress_id: 10077 wordpress_url: http://ivyenvy.com/?p=10077 date: '2014-06-06 07:43:50 +0000' date_gmt: '2014-06-06 12:43:50 +0000' categories: - Uncategorized tags: - Kyle Schwarber - Indiana University comments: - id: 11434 author: Kurtis Tucker author_email<EMAIL_ADDRESS>author_url: '' date: '2014-06-06 08:52:45 +0000' date_gmt: '2014-06-06 13:52:45 +0000' content: I like the pick. College experience, under slot, low risk. Now, bring on the pitchers. - id: 11435 author: Joshua Adams author_email: '' author_url: '' date: '2014-06-06 09:07:27 +0000' date_gmt: '2014-06-06 14:07:27 +0000' content: Thanks for the scouting report- I had no idea who this guy was until now. I'm sure he'll be much better, but a lefty power-hitting catcher reminds me of Rick Wilkins. That was fun for a year. - id: 11440 author: guest author_email<EMAIL_ADDRESS>author_url: '' date: '2014-06-06 11:46:55 +0000' date_gmt: '2014-06-06 16:46:55 +0000' content: Oh sweet a 1B/DH lefty that can hit. OH wait...the cubs already have TWO players with that description.  Terrible pick. - id: 11444 author: IvyEnvy - Corey author_email<EMAIL_ADDRESS>author_url: http://ivyenvy.com/ date: '2014-06-06 13:52:16 +0000' date_gmt: '2014-06-06 18:52:16 +0000' content: "@guest We don't know that we have two of those. Vogelbach is a long way from the big leagues. It's silly to not draft a position because you have someone good at the position at the MLB level." - id: 11446 author: Kurtis Tucker author_email<EMAIL_ADDRESS>author_url: '' date: '2014-06-06 15:02:48 +0000' date_gmt: '2014-06-06 20:02:48 +0000' content: IvyEnvy - Corey New acronym. BPAFTM. Best player available for the money. - id: 11472 author: Darryl Lusk author_email: '' author_url: '' date: '2014-06-07 07:36:08 +0000' date_gmt: '2014-06-07 12:36:08 +0000' content: Don't insult the poor kid. I see an Evan gattis type ---
Cubs fans, take heart. The front office DID select someone of note in the first round. As you all know by now, Kyle Schwarber from Indiana University, has been selected with the fourth overall pick. I am sure this came as a surprise for most of you, but this selection was great and here's why.
Schwarber just destroys baseballs. He is considered to be the best college hitter, in this year's draft and this is significant. Ever since the NCAA changed the bats, in 2011, the numbers of college players have adjusted to more “wood bat” like numbers. This for example is why Kris Bryant's monster college numbers were something to really behold (31 home runs in 62 games). Schwarber's numbers are pretty darn good and even give hints to his total potential. He has some speed to go with his larger frame. In his short college career he had 41 doubles and 12 triples. He is also projected to hit for average and power in the majors. He could develop his catching ability, but will very likely end up in the outfield.
Another thing to consider is the fact that he is a left handed hitter. The Cubs have been so heavily right handed, for so many years, he could help balance out the lineup. I'll let you all consider what sort of hitting power the Cubs might have in a few years. Schwarber, again, is a college pick and will likely be fast tracked to the majors. He just has less to work on, at least offensively. He has patience at the plate and a pretty good swing. The swing can be improved though. He maybe attempts to hit harder thus causing a strange follow through. He still gets results though and this oddity isn't often. Most of the time his hands are through the zone and fast.
The last positive is that he has many of the intangibles. By all accounts he is a great clubhouse guy and is someone that will rally the team. If you don't believe the hype there, just look at what he did in the 2013 College World Series. It was the first appearance for the Hoosiers and the first Big Ten team to make it since 1984. A ton of that had to do with Schwarber killing the baseball, backing some good pitching.
Now for the so-so part.
He isn't Brady Aiken, Alex Jackson, Nick Gordon, etc etc. I am sure there are Cub fans that are confused or even mad about the pick. I personally would of loved to have either Aiken or Jackson, but there are two more things to consider. The first is that Aiken was never going to fall to the fourth pick, leaving the Cubs with the options they had. The other is that the front office is going to sign Schwarber in an underslot deal. The money saved WILL translate to the Cubs taking chances at guys that are very good and just needed some “convincing”.
I'll leave you all with a video of Schwarber from his freshman year, just ignore the Reds comment.


Futures¶
Futures are derivative contracts that allow the control of a fixed size of underlying asset to the owner, and an obligation to deliver the underlying asset at the strike price by the seller. The underlying asset can be a commodity, such as corn, or a financial index, such as the S&P 500.
Three types are provided to model futures including Future, LongFuture and ShortFuture. The Future type can be used to represent both long and short positions, simply by providing positive or negative values in the basis element. LongFuture and ShortFuture types are provided as a convenience and methods dispatched on them assumes long and short positions, respectively.
| Stock type | Description |
|---|---|
| Future | futures contract with either long or short posiition permitted |
| LongFuture | futures contract with only long positions allowed |
| ShortFuture | futures contract with only short positions allowed |
All the futures types hold the same fields. To create an object, only the ticker and basis elements needs to be provided. Default values or Nullable fields will be filled in for the other fields.
| Type field | Description | Type |
|---|---|---|
| ticker | trading symbol | Ticker |
| basis | position price | Float64 |
| suffix | month and year expiry string | UTF8String |
| currency | national currency | Currency |
| tick | increments traded in | Float64 |
| multiplier | degree to adjust position based on price | Flot64 |
| expirty | expiration date for the contrct | Date |
| id | a unique non-exchange identification symbol | FinancialID |
An example in REPL, creating an object representing the ES (S&P 500) contract:
julia> sp500 = LongFuture(Ticker("ES"), 2050.25)
ticker: ES
suffix:
Other field information is accessible with standard . notation:
julia> sp500.currency
USD


| Interface | Description |
|---|---|
| MediaItemQueue |
Represents a sequence of
MediaItems . |
| SessionAvailabilityListener |
Listener of changes in the cast session availability.
|
| Class | Description |
|---|---|
| CastPlayer |
Player implementation that communicates with a Cast receiver app. |
| DefaultCastOptionsProvider |
A convenience
OptionsProvider to target the default cast receiver app. |
| MediaItem |
Representation of an item that can be played by a media player.
|
| MediaItem.Builder |
A builder for
MediaItem instances. |
| MediaItem.DrmScheme |
Represents a DRM protection scheme, and optionally provides information about how to acquire
the license for the media.
|
| MediaItem.UriBundle |
Bundles a resource's URI with headers to attach to any request to that URI.
|


May 24, 2015
Until just recently, my studies at Dev Bootcamp have focused on Ruby, a popular object-oriented programming language. This past week, we've been introduced to JavaScript. Although Ruby and JavaScript are alike in many ways, they also have some major differences. In this blog post, I'd like to explore some of these differences by comparing how Ruby and JavaScript address if...else statements.
Below you will see two if...else statements. They are identical except one is written in JavaScript and the other is in Ruby. Both are written to compare a user's score with an existing high score to determine if a new record has been set.
Ruby:
user_score = 20
high_score = 10
if user_score > high_score
puts "Amazing! You set a new high score!"
elsif user_score == high_score
puts "Great job! You tied the high score!"
else
puts "Good job!"
end
JavaScript:
var userScore = 20
var highScore = 10
if (userScore > highScore) {console.log("Amazing! You set a new high score!")}
else if(userScore === highScore){console.log("Great job! You tied the high score!")}
else{console.log("Good job!")};
As you can see above, both Ruby and JavaScript utilize a similar structure. They both use if
and else
, while Ruby uses elsif
and JavaScript uses else if
. Beyond this, there are a number of differences.
This first difference can be seen in the statement that is being evaluated. In ruby if user_score > high_score
is used, while in JavaScript If(userScore > highScore)
is used. JavaScript requires parenthesis to be used to contain the evaluated statement. After the statement is evaluated, the code block is also formatted differently in each of the two languages. In Ruby, the code between the line with the if and the line with the elsif will run in the event the if statement's condition is true. This code must be on a new line. In JavaScript this code does not need to be on a new line, but must be written inside curly brackets. To finish an if...else statement in Ruby an end
is required, while in JavaScript only a semicolon is used.