Home
Place Order
View Orders
Update Order
First name
Last name
Pickup Location
Address
Please provide a valid Address.
State
Please provide a valid state.
City
Please provide a valid city.
Pickup Contact
First name
Last name
Dropoff Location
Address
Please provide a valid Address.
State
Please provide a valid state.
City
Please provide a valid city.
Dropoff Contact
First name
Last name
Submit form


Welcome
ACCOMODATIONS
ACTIVITIES
TRAVEL ARRANGEMENTS
CONTACT INFORMATION
PICTURES
ACTIVITIES
Here are some of the activities:
Activity
Location
Swimming
PIrates
River boating
Pirates
Island tour
Sub marine
Surfing
Nyali
Night snokerling
Nyali


Bolton fire: Terrifying footage shows just how fast blaze spread in student block
EXCLUSIVE A video shows just quick the fire spread to the top floor but Greater Manchester Fire and Rescue said the cladding is not the same as Grenfell
by Phil Cardy, https://www.mirror.co.uk/authors/phil-cardy/Terrifying footage shows devastating flames rip through the fourth floor right up to the roof of a student accommodation block in a matter of minutes.
The video taken by Ryan Pardon, exclusively obtained by the Sunday People, shows flames engulf the building which is home to 211 students.
Ryan, who filmed the blaze from a neighbouring flat, started recording when the fire had taken hold on the fourth and fifth floors of six-storey Cube in Bolton.
But within 90 seconds it had spread to top level - and a mere 40 seconds later they were through the roof.
Alarms can be heard going off throughout the video, as Ryan and his friend speculate about the cladding used on the block of flats.
Fire crews were examining the cladding - which was a central factor in the Grenfell disaster which claimed 72 lives in 2017.
Eyewitness Ryan told the Sunday People: “The speed it spread was terrifying.
"The cladding has to be looked at. My building has the same cladding, they’re only four metres apart, and we were worried the fire would spread.
“It’s a miracle that no-one was seriously hurt or killed. I couldn’t sleep last night, my mind was racing about what could’ve happened.”
He added: “I’ve been told I won’t be able to go home for two or three days. Every building needs to be tested to make sure the cladding is safe. It doesn’t matter about the cost.”
More than 200 firefighters fought through the night to bring the blaze under control while students made their way to safety.
Shocked witness spoke of flames “crawling up the cladding” with every floor of the six-storey building alight.
Yesterday bosses at Greater Manchester Fire and Rescue said the cladding on The Cube was NOT the same as Grenfell - but is under investigation because the fire spread rapidly on the outside.
Assistant chief Fire Officer Dave Keelan said lessons learnt from Grenfell helped with the evacuation.
He said: “The procedures and subsequent training we have done since then has paid absolute dividends. The fire spread extremely quickly, that’s why I can’t praise the firefighters enough for initiating a full evacuation as soon as they got here.”
The Fire Brigades Union condemned the “complete failure” of the UK’s fire safety system and said not enough had been done to make cladded buildings safer.
General secretary Matt Wrack said: “It’s deeply troubling to see fire spread rapidly up a building’s exterior again - a shocking indictment of the government’s shameful inaction after Grenfell.”
The fire broke out at 8.30pm on Friday in the privately-owned building which houses students at the University of Bolton. Witnesses spoke of flames “tearing up and across” the building.
Student Melissa McGarrigle, 18, said: “Everyone thought it was just the fire alarms acting up as usual until we heard people screaming.”
Onlooker Dominic Walsh, 36, said: “We could see the embers in the sky. We could see the building glowing at the top.”
Paramedics treated two people at the scene for minor injuries, including one person rescued by fire crews from an aerial platform.
Rescuers believe there are no casualties but are appealing for students to confirm they are safe and contact their parents to re-assure them.
Action group Grenfell United said the fire “brings back memories”.


rules: you need a webcam. arrow keys to move. joystick in the bottom left for mobile users. click one of the options below to start!
screensharing works on chrome only. audio screensharing only supported in windows.
use the menu in the top right (once you're in) to add things to your room!
you can add images or webpages, and everyone can see!
right click webpage borders or images to delete them.


At one of the Hyde Park Salons, I saw Jonathan Marks' presentation on anamorphic art. He had morphed images so that they only looked correct when reflected in a mirrored cylinder. He morphed his images by hand. I was interested in trying out some morphed images, but didn't have the patience or artistic skill to do it by hand, so I made a python script to do it for me. I'm posting it in case anyone else wants to try it out.
Set a cylinder radius (replace 'Set radius in inches' with a number, e.g. 2) pick an image, and the transform should automatically appear (you may need to scroll down). Right-click on the image for the option to save it. Refresh the page to reset it. My friend Zenna helped me make this javascript app, and here's my original python script anamorphic.py. Let me know if you need help, or have suggestions (e l m at m i t dot e d u)


A function is a set of statements organized together to perform a specific task. R has a large number of in-built functions and the user can create their own functions. In R, a function is an object so the R interpreter is able to pass control to the function, along with arguments that may be necessary for the function to accomplish the actions. The function in turn performs its task and returns control to the interpreter as well as any result which may be stored in other objects.
An R function is created by using the keyword function
. The basic syntax of an R function definition is as follows −
function_name <- function(arg_1, arg_2, ...) {
Function body
}
The different parts of a function are −
Function Name
− This is the actual name of the function. It is stored in R environment as an object with this name.
Arguments
− An argument is a placeholder. When a function is invoked, you pass a value to the argument. Arguments are optional; that is, a function may contain no arguments. Also arguments can have default values.
Function Body
− The function body contains a collection of statements that defines what the function does.
Return Value
− The return value of a function is the last expression in the function body to be evaluated.
R has many in-built functions which can be directly called in the program without defining them first. We can also create and use our own functions referred as user defined functions.
We can create user-defined functions in R. They are specific to what a user wants and once created they can be used like the built-in functions. Below is an example of how a function is created and used.
<- function(a) {
new.function for(i in 1:a) {
<- i^2
b print(b)
}
}
# Call the function new.function supplying 6 as an argument.
new.function(6)
[1] 1
[1] 4
[1] 9
[1] 16
[1] 25
[1] 36
The arguments to a function call can be supplied in the same sequence as defined in the function or they can be supplied in a different sequence but assigned to the names of the arguments.
# Create a function with arguments.
<- function(a,b,c) {
new.function <- a * b + c
result print(result)
}
# Call the function by position of arguments.
new.function(5,3,11)
[1] 26
# Call the function by names of the arguments.
new.function(a = 11, b = 5, c = 3)
[1] 58
We can define the value of the arguments in the function definition and call the function without supplying any argument to get the default result. But we can also call such functions by supplying new values of the argument and get non default result.
# Create a function with arguments.
<- function(a = 3, b = 6) {
new.function <- a * b
result print(result)
}
# Call the function without giving any argument.
new.function()
[1] 18
# Call the function with giving new values of the argument.
new.function(9,5)
[1] 45
Now we will write functions for the following Statistical measurements:
# Creating a random sample
=sample(20:50,20)
x=sample(20:50,20) y
# Function for mean
=function(x){
my.mean# getting sum of the observations
=sum(x)
s# getting number of observations
=length(x)
n# calculating the mean
=s/n
avg# rounding of the result to 4 decimal places
=round(avg,4) #this step is optional.
avg# if you are not using the next line then comment this out.
#printing the result
cat(c("The arithmetic mean is",avg,"\n")) # This step is optional,
#if you want a simple function without any text in the result,
#comment out this step and uncomment the next line.
#print(avg)
}my.mean(x)
The arithmetic mean is 35.05
my.mean(y)
The arithmetic mean is 34.9
# Function for Standard Deviation
=function(x){
my.sd#mean of x
=mean(x)
avg# number of observations
=length(x)
n# the deviation from mean
=x-avg
dif# square of deviations
=dif^2
dif2# sum of squares of deviation
=sum(dif2)
s# the stndard daviation
=sqrt(s/n)
std.dev#rounding off the number to 2 decimal places
=round(std.dev,2)
std.devcat(c("The Standard deviation is",std.dev,"\n"))
}my.sd(x)
The Standard deviation is 9.07
my.sd(y)
The Standard deviation is 8.81
# Function for Co-efficient of variation
=function(x){
my.cv#mean of x
=mean(x)
avg=round(avg,2)
avg# number of observations
=length(x)
n# the deviation from mean
=x-avg
dif# square of deviations
=dif^2
dif2# sum of squares of deviation
=sum(dif2)
s# the stndard daviation
=sqrt(s/n)
std.dev=round(std.dev,2)
std.dev# calculating the coeficient of variation
=(std.dev/avg)*100
cv=round(cv,2)
cvcat(c("The mean is",avg,"\n"))
cat(c("The Standard deviation is",std.dev,"\n"))
cat(c("The Co-efficient of variation (CV) is",cv,"\n"))
}
my.cv(x)
The mean is 35.05
The Standard deviation is 9.07
The Co-efficient of variation (CV) is 25.88
my.cv(y)
The mean is 34.9
The Standard deviation is 8.81
The Co-efficient of variation (CV) is 25.24
# Function for Coefficient of correlation
=function(x,y){
my.cor
=mean(x)
mean.x=mean(y)
mean.y=sum(x*y)
s.xy=length(x)
n=(s.xy/n)-mean.x*mean.y
cov.xy=(x-mean.x)^2
dx=(y-mean.y)^2
dy=sum(dx)
s.x=sum(dy)
s.y=sqrt(s.x/n)
sd.x=sqrt(s.y/n)
sd.y=cov.xy/(sd.x*sd.y)
cor.xy
cat(c("The Co-efficient of Correlation is","\n"))
print(cor.xy)
}my.cor(x,y)
The Co-efficient of Correlation is
[1] -0.4590532
# Function for Regression coefficient
=function(x,y){
my.reg=mean(x)
mean.x=mean(y)
mean.y=sum(x*y)
s.xy=length(x)
n=(s.xy/n)-mean.x*mean.y
cov.xy=(x-mean.x)^2
dx=(y-mean.y)^2
dy=sum(dx)
s.x=sum(dy)
s.y=sqrt(s.x/n)
sd.x=sqrt(s.y/n)
sd.y=cov.xy/(sd.x*sd.y)
cor.xy=cor.xy*(sd.y/sd.x)
b.yx=cor.xy*(sd.x/sd.y)
b.xy
cat(c("The regression coefficient of Y on X is","\n"))
print(b.yx)
cat("\n")
cat(c("The regression coefficient of X on Y is","\n"))
print(b.xy)
}
my.reg(x,y)
The regression coefficient of Y on X is
[1] -0.4461534
The regression coefficient of X on Y is
[1] -0.4723259
# Function for single mean t test
=function(x,mu=0,alpha=0.95){
my.t.single=mean(x)
mean.x=sd(x)
S=length(x)
n=n-1
df=(mean.x-mu)/(S/sqrt(n))
t.cal=qt(alpha,df)
t.tab
if(abs(t.cal)<=t.tab){
cat("The null hypothesis should be accepted \n")
else{
}cat("The null hypothesis should be rejected \n")
}cat("The sample mean is \n")
print(mean.x)
cat("Calculated t statistic \n")
print(t.cal)
=2*pt(-abs(t.cal),df)
p.valuecat("p-value \n")
print(p.value)
}my.t.single(x,50)
The null hypothesis should be rejected
The sample mean is
[1] 35.05
Calculated t statistic
[1] -7.185494
p-value
[1] 7.947795e-07
# Function for paired mean t test
=function(x,y,alpha=0.95){
my.t.paired=mean(x)
mean.x=mean(y)
mean.y=sd(x)
S.x=sd(y)
S.y=length(x)
n.x=length(y)
n.y=n.x+n.y-2
df=sqrt(((n.x-1)*var(x)+(n.y-1)*var(y))/(n.x+n.y-2))
S=(mean.x-mean.y)/(S*sqrt((1/n.x)+(1/n.y)))
t.cal=qt(alpha,df)
t.tab
if(abs(t.cal)<=t.tab){
cat("The null hypothesis should be accepted \n")
else{
}cat("The null hypothesis should be rejected \n")
}
cat("Calculated t statistic \n")
print(t.cal)
=2*pt(-abs(t.cal),df)
p.valuecat("p-value \n")
print(p.value)
}my.t.paired(x,y)
The null hypothesis should be accepted
Calculated t statistic
[1] 0.05170028
p-value
[1] 0.9590383


Dr. Mohammad Faisal is working as a Professor in the Department of Electrical and Electronic Engineering (EEE) of Bangladesh University of Engineering & Technology (BUET). Dr. Faisal has been serving as a faculty member in this department since 2001. He used to take different theory courses in undergraduate level and in postgraduate level. In addition to theory courses, he used to conduct different labs and supervise thesis/project of the students. Other than academic activates, he has been supporting the university administration in different services.
Dr. Faisal has also been serving as an expert member in the field of Telecommunication and Electrical Engineering at the Bureau of Research, Testing and Consultation (BRTC) of the Department of EEE. He has been working and carrying out research in the field of Telecommunication, particularly in fiber-optic communications and photonics. He worked with different government organization, i.e. in public sectors like BPDB, DPDC, Hazrat Shahjalal International Airport (HSIA) under the Civil Aviation Authority of Bangladesh (CAAB), NIMCo and different private sectors/companies like Bengal Communications Limited (BCL), Summit Communications Ltd., EnergyPac Engineering Ltd., AKS etc. nominated by BUET. Furthermore, as a technical expert, he also worked with Bangladesh Police, PGCB, Bangladesh Betar and Bangladesh Television etc.
| From - To [Year] | Employer | Positions held |
|---|---|---|
| 2016 - Present | BUET | Professor |
| 2012 - 2016 | BUET | Associate Professor |
| 2010 - 2012 | BUET | Assistant Professor |
| 2006 - 2010 | Osaka University | PhD Scholar |
| 2005 - 2006 | Osaka University | Research Student |
| 2004 - 2005 | BUET | Assistant Professor |
| 2001 - 2004 | BUET | Lecturer |
Fiber-optic communication systems, Fiber nonlinearities, Photonics.
My research experiences and interests include the challenging issues of modeling of optical fiber transmission systems focusing on various linear and nonlinear impairments. The research target is to design ultra-high speed short-haul and long-haul fiber-optic communication (single-channel and multi-channel: WDM or OFDM) systems in order to meet the huge growing demand for bandwidth efficiently. Furthermore, I have been conducting research on photonics where I have focused on waveguide design for Terahertz transmission. Photonic crystal fiber based dispersion compensating fiber, sensor and optical signal processing devices are under investigation. Some of the research activities that are carried out and some ongoing works are as follows:


XmlBase is a base class for building XML builders. See Builder::XmlMarkup and Builder::XmlEvents for examples.
Create an XML markup builder.
| out: | Object receiving the markup. out must respond to <<. |
| indent: | Number of spaces used for indentation (0 implies no indentation and no line breaks). |
| initial: | Level of initial indentation. |
[ show source ]
# File vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb, line 22 22: def initialize(indent=0, initial=0) 23: @indent = indent 24: @level = initial 25: end
Append text to the output target without escaping any markup. May be used within the markup brackets as:
builder.p { |x| x << "
HI" } #=>

HI

This is useful when using non-builder enabled software that generates strings. Just insert the string directly into the builder without changing the inserted markup.
It is also useful for stacking builder objects. Builders only use << to append to the target, so by supporting this method/operation builders can use other builders as their targets.
[ show source ]
# File vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb, line 97 97: def <<(text) 98: _text(text) 99: end
Create XML markup based on the name of the method. This method is never invoked directly, but is called for each markup method in the markup block.
[ show source ]
# File vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb, line 37 37: def method_missing(sym, *args, &block) 38: text = nil 39: attrs = nil 40: sym = "#{sym}:#{args.shift}" if args.first.kind_of?(Symbol) 41: args.each do |arg| 42: case arg 43: when Hash 44: attrs ||= {} 45: attrs.merge!(arg) 46: else 47: text ||= '' 48: text << arg.to_s 49: end 50: end 51: if block 52: unless text.nil? 53: raise ArgumentError, "XmlMarkup cannot mix a text argument with a block" 54: end 55: _indent 56: _start_tag(sym, attrs) 57: _newline 58: _nested_structures(block) 59: _indent 60: _end_tag(sym) 61: _newline 62: elsif text.nil? 63: _indent 64: _start_tag(sym, attrs, true) 65: _newline 66: else 67: _indent 68: _start_tag(sym, attrs) 69: text! text 70: _end_tag(sym) 71: _newline 72: end 73: @target 74: end
For some reason, nil? is sent to the XmlMarkup object. If nil? is not defined and method_missing is invoked, some strange kind of recursion happens. Since nil? won‘t ever be an XML tag, it is pretty safe to define it here. (Note: this is an example of cargo cult programming, cf. fishbowl.pastiche.org/2004/10/13/cargo_cult_programming).
[ show source ]
# File vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb, line 107 107: def nil? 108: false 109: end
Create a tag named sym. Other than the first argument which is the tag name, the arguments are the same as the tags implemented via method_missing.
[ show source ]
# File vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb, line 30 30: def tag!(sym, *args, &block) 31: method_missing(sym.to_sym, *args, &block) 32: end
Append text to the output target. Escape any markup. May be used within the markup brackets as:
builder.p { |b| b.br; b.text! "HI" } #=>

HI

[ show source ]
# File vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb, line 80 80: def text!(text) 81: _text(_escape(text)) 82: end


graphics file formats
this topic describes the graphics-file formats used by the microsoft windows operating system. graphics files include bitmap files, icon-resource files, and cursor-resource files. bitmap-file formats windows bitmap files are stored in a device-independent bitmap (dib) format that allows windows to display the bitmap on any type of display device. the term "device independent" means that the bitmap specifies pixel color in a form independent of the method used by a display to represent color. the default filename extension of a windows dib file is .bmp. bitmap-file structures each bitmap file contains a bitmap-file header, a bitmap-information header, a color table, and an array of bytes that defines the bitmap bits. the file has the following form: bitmapfileheader bmfh; bitmapinfoheader bmih; rgbquad acolors[]; byte abitmapbits[]; the bitmap-file header contains information about the type, size, and layout of a device-independent bitmap file. the header is defined as a bitmapfileheader structure. the bitmap-information header, defined as a bitmapinfoheader structure, specifies the dimensions, compression type, and color format for the bitmap. the color table, defined as an array of rgbquad structures, contains as many elements as there are colors in the bitmap. the color table is not present for bitmaps with 24 color bits because each pixel is represented by 24-bit red-green-blue (rgb) values in the actual bitmap data area. the colors in the table should appear in order of importance. this helps a display driver render a bitmap on a device that cannot display as many colors as there are in the bitmap. if the dib is in windows version 3.0 or later format, the driver can use the biclrimportant member of the bitmapinfoheader structure to determine which colors are important. the bitmapinfo structure can be used to represent a combined bitmap-information header and color table. the bitmap bits, immediately following the color table, consist of an array of byte values representing consecutive rows, or "scan lines," of the bitmap. each scan line consists of consecutive bytes representing the pixels in the scan line, in left-to-right order. the number of bytes representing a scan line depends on the color format and the width, in pixels, of the bitmap. if necessary, a scan line must be zero-padded to end on a 32-bit boundary. however, segment boundaries can appear anywhere in the bitmap. the scan lines in the bitmap are stored from bottom up. this means that the first byte in the array represents the pixels in the lower-left corner of the bitmap and the last byte represents the pixels in the upper-right corner. the bibitcount member of the bitmapinfoheader structure determines the number of bits that define each pixel and the maximum number of colors in the bitmap. these members can have any of the following values: value meaning 1 bitmap is monochrome and the color table contains two entries. each bit in the bitmap array represents a pixel. if the bit is clear, the pixel is displayed with the color of the first entry in the color table. if the bit is set, the pixel has the color of the second entry in the table. 4 bitmap has a maximum of 16 colors. each pixel in the bitmap is represented by a 4-bit index into the color table. for example, if the first byte in the bitmap is 0x1f, the byte represents two pixels. the first pixel contains the color in the second table entry, and the second pixel contains the color in the sixteenth table entry. 8 bitmap has a maximum of 256 colors. each pixel in the bitmap is represented by a 1-byte index into the color table. for example, if the first byte in the bitmap is 0x1f, the first pixel has the color of the thirty-second table entry. 24 bitmap has a maximum of 2^24 colors. the bmicolors (or bmcicolors) member is null, and each 3-byte sequence in the bitmap array represents the relative intensities of red, green, and blue, respectively, for a pixel. the biclrused member of the bitmapinfoheader structure specifies the number of color indexes in the color table actually used by the bitmap. if the biclrused member is set to zero, the bitmap uses the maximum number of colors corresponding to the value of the bibitcount member. an alternative form of bitmap file uses the bitmapcoreinfo, bitmapcoreheader, and rgbtriple structures. bitmap compression windows versions 3.0 and later support run-length encoded (rle) formats for compressing bitmaps that use 4 bits per pixel and 8 bits per pixel. compression reduces the disk and memory storage required for a bitmap. compression of 8-bits-per-pixel bitmaps when the bicompression member of the bitmapinfoheader structure is set to bi_rle8, the dib is compressed using a run-length encoded format for a 256-color bitmap. this format uses two modes: encoded mode and absolute mode. both modes can occur anywhere throughout a single bitmap. encoded mode a unit of information in encoded mode consists of two bytes. the first byte specifies the number of consecutive pixels to be drawn using the color index contained in the second byte. the first byte of the pair can be set to zero to indicate an escape that denotes the end of a line, the end of the bitmap, or a delta. the interpretation of the escape depends on the value of the second byte of the pair, which must be in the range 0x00 through 0x02. following are the meanings of the escape values that can be used in the second byte: second byte meaning 0 end of line. 1 end of bitmap. 2 delta. the two bytes following the escape contain unsigned values indicating the horizontal and vertical offsets of the next pixel from the current position. absolute mode absolute mode is signaled by the first byte in the pair being set to zero and the second byte to a value between 0x03 and 0xff. the second byte represents the number of bytes that follow, each of which contains the color index of a single pixel. each run must be aligned on a word boundary. following is an example of an 8-bit rle bitmap (the two-digit hexadecimal values in the second column represent a color index for a single pixel): compressed data expanded data 03 04 04 04 04 05 06 06 06 06 06 06 00 03 45 56 67 00 45 56 67 02 78 78 78 00 02 05 01 move 5 right and 1 down 02 78 78 78 00 00 end of line 09 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 00 01 end of rle bitmap compression of 4-bits-per-pixel bitmaps when the bicompression member of the bitmapinfoheader structure is set to bi_rle4, the dib is compressed using a run-length encoded format for a 16-color bitmap. this format uses two modes: encoded mode and absolute mode. encoded mode a unit of information in encoded mode consists of two bytes. the first byte of the pair contains the number of pixels to be drawn using the color indexes in the second byte. the second byte contains two color indexes, one in its high-order nibble (that is, its low-order 4 bits) and one in its low-order nibble. the first pixel is drawn using the color specified by the high-order nibble, the second is drawn using the color in the low-order nibble, the third is drawn with the color in the high-order nibble, and so on, until all the pixels specified by the first byte have been drawn. the first byte of the pair can be set to zero to indicate an escape that denotes the end of a line, the end of the bitmap, or a delta. the interpretation of the escape depends on the value of the second byte of the pair. in encoded mode, the second byte has a value in the range 0x00 through 0x02. the meaning of these values is the same as for a dib with 8 bits per pixel. absolute mode in absolute mode, the first byte contains zero, the second byte contains the number of color indexes that follow, and subsequent bytes contain color indexes in their high- and low-order nibbles, one color index for each pixel. each run must be aligned on a word boundary. following is an example of a 4-bit rle bitmap (the one-digit hexadecimal values in the second column represent a color index for a single pixel): compressed data expanded data 03 04 0 4 0 05 06 0 6 0 6 0 00 06 45 56 67 00 4 5 5 6 6 7 04 78 7 8 7 8 00 02 05 01 move 5 right and 1 down 04 78 7 8 7 8 00 00 end of line 09 1e 1 e 1 e 1 e 1 e 1 00 01 end of rle bitmap bitmap example the following example is a text dump of a 16-color bitmap (4 bits per pixel): win3dibfile bitmapfileheader type 19778 size 3118 reserved1 0 reserved2 0 offsetbits 118 bitmapinfoheader size 40 width 80 height 75 planes 1 bitcount 4 compression 0 sizeimage 3000 xpelspermeter 0 ypelspermeter 0 colorsused 16 colorsimportant 16 win3colortable blue green red unused [00000000] 84 252 84 0 [00000001] 252 252 84 0 [00000002] 84 84 252 0 [00000003] 252 84 252 0 [00000004] 84 252 252 0 [00000005] 252 252 252 0 [00000006] 0 0 0 0 [00000007] 168 0 0 0 [00000008] 0 168 0 0 [00000009] 168 168 0 0 [0000000a] 0 0 168 0 [0000000b] 168 0 168 0 [0000000c] 0 168 168 0 [0000000d] 168 168 168 0 [0000000e] 84 84 84 0 [0000000f] 252 84 84 0 image . . bitmap data . icon-resource file format an icon-resource file contains image data for icons used by windows applications. the file consists of an icon directory identifying the number and types of icon images in the file, plus one or more icon images. the default filename extension for an icon-resource file is .ico. icon directory each icon-resource file starts with an icon directory. the icon directory, defined as an icondir structure, specifies the number of icons in the resource and the dimensions and color format of each icon image. the icondir structure has the following form: typedef struct icondir { word idreserved; word idtype; word idcount; icondirentry identries[1]; } iconheader; following are the members in the icondir structure: idreserved reserved; must be zero. idtype specifies the resource type. this member is set to 1. idcount specifies the number of entries in the directory. identries specifies an array of icondirentry structures containing information about individual icons. the idcount member specifies the number of structures in the array. the icondirentry structure specifies the dimensions and color format for an icon. the structure has the following form: struct icondirectoryentry { byte bwidth; byte bheight; byte bcolorcount; byte breserved; word wplanes; word wbitcount; dword dwbytesinres; dword dwimageoffset; }; following are the members in the icondirentry structure: bwidth specifies the width of the icon, in pixels. acceptable values are 16, 32, and 64. bheight specifies the height of the icon, in pixels. acceptable values are 16, 32, and 64. bcolorcount specifies the number of colors in the icon. acceptable values are 2, 8, and 16. breserved reserved; must be zero. wplanes specifies the number of color planes in the icon bitmap. wbitcount specifies the number of bits in the icon bitmap. dwbytesinres specifies the size of the resource, in bytes. dwimageoffset specifies the offset, in bytes, from the beginning of the file to the icon image. icon image each icon-resource file contains one icon image for each image identified in the icon directory. an icon image consists of an icon-image header, a color table, an xor mask, and an and mask. the icon image has the following form: bitmapinfoheader icheader; rgbquad iccolors[]; byte icxor[]; byte icand[]; the icon-image header, defined as a bitmapinfoheader structure, specifies the dimensions and color format of the icon bitmap. only the bisize through bibitcount members and the bisizeimage member are used. all other members (such as bicompression and biclrimportant) must be set to zero. the color table, defined as an array of rgbquad structures, specifies the colors used in the xor mask. as with the color table in a bitmap file, the bibitcount member in the icon-image header determines the number of elements in the array. for more information about the color table, see section 1.1, "bitmap-file formats." the xor mask, immediately following the color table, is an array of byte values representing consecutive rows of a bitmap. the bitmap defines the basic shape and color of the icon image. as with the bitmap bits in a bitmap file, the bitmap data in an icon-resource file is organized in scan lines, with each byte representing one or more pixels, as defined by the color format. for more information about these bitmap bits, see section 1.1, "bitmap-file formats." the and mask, immediately following the xor mask, is an array of byte values, representing a monochrome bitmap with the same width and height as the xor mask. the array is organized in scan lines, with each byte representing 8 pixels. when windows draws an icon, it uses the and and xor masks to combine the icon image with the pixels already on the display surface. windows first applies the and mask by using a bitwise and operation; this preserves or removes existing pixel color. windows then applies the xor mask by using a bitwise xor operation. this sets the final color for each pixel. the following illustration shows the xor and and masks that create a monochrome icon (measuring 8 pixels by 8 pixels) in the form of an uppercase k: windows icon selection windows detects the resolution of the current display and matches it against the width and height specified for each version of the icon image. if windows determines that there is an exact match between an icon image and the current device, it uses the matching image. otherwise, it selects the closest match and stretches the image to the proper size. if an icon-resource file contains more than one image for a particular resolution, windows uses the icon image that most closely matches the color capabilities of the current display. if no image matches the device capabilities exactly, windows selects the image that has the greatest number of colors without exceeding the number of display colors. if all images exceed the color capabilities of the current display, windows uses the icon image with the least number of colors. cursor-resource file format a cursor-resource file contains image data for cursors used by windows applications. the file consists of a cursor directory identifying the number and types of cursor images in the file, plus one or more cursor images. the default filename extension for a cursor-resource file is .cur. cursor directory each cursor-resource file starts with a cursor directory. the cursor directory, defined as a cursordir structure, specifies the number of cursors in the file and the dimensions and color format of each cursor image. the cursordir structure has the following form: typedef struct _cursordir { word cdreserved; word cdtype; word cdcount; cursordirentry cdentries[]; } cursordir; following are the members in the cursordir structure: cdreserved reserved; must be zero. cdtype specifies the resource type. this member must be set to 2. cdcount specifies the number of cursors in the file. cdentries specifies an array of cursordirentry structures containing information about individual cursors. the cdcount member specifies the number of structures in the array. a cursordirentry structure specifies the dimensions and color format of a cursor image. the structure has the following form: typedef struct _cursordirentry { byte bwidth; byte bheight; byte bcolorcount; byte breserved; word wxhotspot; word wyhotspot; dword lbytesinres; dword dwimageoffset; } cursordirentry; following are the members in the cursordirentry structure: bwidth specifies the width of the cursor, in pixels. bheight specifies the height of the cursor, in pixels. bcolorcount reserved; must be zero. breserved reserved; must be zero. wxhotspot specifies the x-coordinate, in pixels, of the hot spot. wyhotspot specifies the y-coordinate, in pixels, of the hot spot. lbytesinres specifies the size of the resource, in bytes. dwimageoffset specifies the offset, in bytes, from the start of the file to the cursor image. cursor image each cursor-resource file contains one cursor image for each image identified in the cursor directory. a cursor image consists of a cursor-image header, a color table, an xor mask, and an and mask. the cursor image has the following form: bitmapinfoheader crheader; rgbquad crcolors[]; byte crxor[]; byte crand[]; the cursor hot spot is a single pixel in the cursor bitmap that windows uses to track the cursor. the crxhotspot and cryhotspot members specify the x- and y-coordinates of the cursor hot spot. these coordinates are 16-bit integers. the cursor-image header, defined as a bitmapinfoheader structure, specifies the dimensions and color format of the cursor bitmap. only the bisize through bibitcount members and the bisizeimage member are used. the biheight member specifies the combined height of the xor and and masks for the cursor. this value is twice the height of the xor mask. the biplanes and bibitcount members must be 1. all other members (such as bicompression and biclrimportant) must be set to zero. the color table, defined as an array of rgbquad structures, specifies the colors used in the xor mask. for a cursor image, the table contains exactly two structures, since the bibitcount member in the cursor-image header is always 1. the xor mask, immediately following the color table, is an array of byte values representing consecutive rows of a bitmap. the bitmap defines the basic shape and color of the cursor image. as with the bitmap bits in a bitmap file, the bitmap data in a cursor-resource file is organized in scan lines, with each byte representing one or more pixels, as defined by the color format. for more information about these bitmap bits, see section 1.1, "bitmap-file formats." the and mask, immediately following the xor mask, is an array of byte values representing a monochrome bitmap with the same width and height as the xor mask. the array is organized in scan lines, with each byte representing 8 pixels. when windows draws a cursor, it uses the and and xor masks to combine the cursor image with the pixels already on the display surface. windows first applies the and mask by using a bitwise and operation; this preserves or removes existing pixel color. window then applies the xor mask by using a bitwise xor operation. this sets the final color for each pixel. the following illustration shows the xor and the and masks that create a cursor (measuring 8 pixels by 8 pixels) in the form of an arrow: following are the bit-mask values necessary to produce black, white, inverted, and transparent results: pixel result and maskxor mask black 0 0 white 0 1 transparent 1 0 inverted1 1 windows cursor selection if a cursor-resource file contains more than one cursor image, windows determines the best match for a particular display by examining the width and height of the cursor images. ============================================================================== bitmapfileheader (3.0) typedef struct tagbitmapfileheader { /* bmfh */ uint bftype; dword bfsize; uint bfreserved1; uint bfreserved2; dword bfoffbits; } bitmapfileheader; the bitmapfileheader structure contains information about the type, size, and layout of a device-independent bitmap (dib) file. member description bftype specifies the type of file. this member must be bm. bfsize specifies the size of the file, in bytes. bfreserved1 reserved; must be set to zero. bfreserved2 reserved; must be set to zero. bfoffbits specifies the byte offset from the bitmapfileheader structure to the actual bitmap data in the file. comments a bitmapinfo or bitmapcoreinfo structure immediately follows the bitmapfileheader structure in the dib file. see also bitmapcoreinfo, bitmapinfo ============================================================================== bitmapinfo (3.0) typedef struct tagbitmapinfo { /* bmi */ bitmapinfoheader bmiheader; rgbquad bmicolors[1]; } bitmapinfo; the bitmapinfo structure fully defines the dimensions and color information for a windows 3.0 or later device-independent bitmap (dib). member description bmiheader specifies a bitmapinfoheader structure that contains information about the dimensions and color format of a dib. bmicolors specifies an array of rgbquad structures that define the colors in the bitmap. comments a windows 3.0 or later dib consists of two distinct parts: a bitmapinfo structure, which describes the dimensions and colors of the bitmap, and an array of bytes defining the pixels of the bitmap. the bits in the array are packed together, but each scan line must be zero-padded to end on a long boundary. segment boundaries, however, can appear anywhere in the bitmap. the origin of the bitmap is the lower-left corner. the bibitcount member of the bitmapinfoheader structure determines the number of bits which define each pixel and the maximum number of colors in the bitmap. this member may be set to any of the following values: value meaning 1 the bitmap is monochrome, and the bmcicolors member must contain two entries. each bit in the bitmap array represents a pixel. if the bit is clear, the pixel is displayed with the color of the first entry in the bmcicolors table. if the bit is set, the pixel has the color of the second entry in the table. 4 the bitmap has a maximum of 16 colors, and the bmcicolors member contains 16 entries. each pixel in the bitmap is represented by a four-bit index into the color table. for example, if the first byte in the bitmap is 0x1f, the byte represents two pixels. the first pixel contains the color in the second table entry, and the second pixel contains the color in the sixteenth table entry. 8 the bitmap has a maximum of 256 colors, and the bmcicolors member contains 256 entries. in this case, each byte in the array represents a single pixel. 24 the bitmap has a maximum of 2^24 colors. the bmcicolors member is null, and each 3-byte sequence in the bitmap array represents the relative intensities of red, green, and blue, respectively, of a pixel. the biclrused member of the bitmapinfoheader structure specifies the number of color indexes in the color table actually used by the bitmap. if the biclrused member is set to zero, the bitmap uses the maximum number of colors corresponding to the value of the bibitcount member. the colors in the bmicolors table should appear in order of importance. alternatively, for functions that use dibs, the bmicolors member can be an array of 16-bit unsigned integers that specify an index into the currently realized logical palette instead of explicit rgb values. in this case, an application using the bitmap must call dib functions with the wusage parameter set to dib_pal_colors. note: the bmicolors member should not contain palette indexes if the bitmap is to be stored in a file or transferred to another application. unless the application uses the bitmap exclusively and under its complete control, the bitmap color table should contain explicit rgb values. see also bitmapinfoheader, rgbquad ============================================================================== bitmapinfoheader (3.0) typedef struct tagbitmapinfoheader { /* bmih */ dword bisize; long biwidth; long biheight; word biplanes; word bibitcount; dword bicompression; dword bisizeimage; long bixpelspermeter; long biypelspermeter; dword biclrused; dword biclrimportant; } bitmapinfoheader; the bitmapinfoheader structure contains information about the dimensions and color format of a windows 3.0 or later device-independent bitmap (dib). member description bisize specifies the number of bytes required by the bitmapinfoheader structure. biwidth specifies the width of the bitmap, in pixels. biheightspecifies the height of the bitmap, in pixels. biplanesspecifies the number of planes for the target device. this member must be set to 1. bibitcount specifies the number of bits per pixel. this value must be 1, 4, 8, or 24. bicompression specifies the type of compression for a compressed bitmap. it can be one of the following values: value meaning bi_rgb specifies that the bitmap is not compressed. bi_rle8 specifies a run-length encoded format for bitmaps with 8 bits per pixel. the compression format is a 2-byte format consisting of a count byte followed by a byte containing a color index. for more information, see the following comments section. bi_rle4 specifies a run-length encoded format for bitmaps with 4 bits per pixel. the compression format is a 2-byte format consisting of a count byte followed by two word-length color indexes. for more information, see the following comments section. bisizeimage specifies the size, in bytes, of the image. it is valid to set this member to zero if the bitmap is in the bi_rgb format. bixpelspermeter specifies the horizontal resolution, in pixels per meter, of the target device for the bitmap. an application can use this value to select a bitmap from a resource group that best matches the characteristics of the current device. biypelspermeter specifies the vertical resolution, in pixels per meter, of the target device for the bitmap. biclrused specifies the number of color indexes in the color table actually used by the bitmap. if this value is zero, the bitmap uses the maximum number of colors corresponding to the value of the bibitcount member. for more information on the maximum sizes of the color table, see the description of the bitmapinfo structure earlier in this topic. if the biclrused member is nonzero, it specifies the actual number of colors that the graphics engine or device driver will access if the bibitcount member is less than 24. if bibitcount is set to 24, biclrused specifies the size of the reference color table used to optimize performance of windows color palettes. if the bitmap is a packed bitmap (that is, a bitmap in which the bitmap array immediately follows the bitmapinfo header and which is referenced by a single pointer), the biclrused member must be set to zero or to the actual size of the color table. biclrimportant specifies the number of color indexes that are considered important for displaying the bitmap. if this value is zero, all colors are important. comments the bitmapinfo structure combines the bitmapinfoheader structure and a color table to provide a complete definition of the dimensions and colors of a windows 3.0 or later dib. for more information about specifying a windows 3.0 dib, see the description of the bitmapinfo structure. an application should use the information stored in the bisize member to locate the color table in a bitmapinfo structure as follows: pcolor = ((lpstr) pbitmapinfo + (word) (pbitmapinfo->bmiheader.bisize)) windows supports formats for compressing bitmaps that define their colors with 8 bits per pixel and with 4 bits per pixel. compression reduces the disk and memory storage required for the bitmap. the following paragraphs describe these formats. bi_rle8 when the bicompression member is set to bi_rle8, the bitmap is compressed using a run-length encoding format for an 8-bit bitmap. this format may be compressed in either of two modes: encoded and absolute. both modes can occur anywhere throughout a single bitmap. encoded mode consists of two bytes: the first byte specifies the number of consecutive pixels to be drawn using the color index contained in the second byte. in addition, the first byte of the pair can be set to zero to indicate an escape that denotes an end of line, end of bitmap, or a delta. the interpretation of the escape depends on the value of the second byte of the pair. the following list shows the meaning of the second byte: value meaning 0 end of line. 1 end of bitmap. 2 delta. the two bytes following the escape contain unsigned values indicating the horizontal and vertical offset of the next pixel from the current position. absolute mode is signaled by the first byte set to zero and the second byte set to a value between 0x03 and 0xff. in absolute mode, the second byte represents the number of bytes that follow, each of which contains the color index of a single pixel. when the second byte is set to 2 or less, the escape has the same meaning as in encoded mode. in absolute mode, each run must be aligned on a word boundary. the following example shows the hexadecimal values of an 8-bit compressed bitmap: 03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1e 00 01 this bitmap would expand as follows (two-digit values represent a color index for a single pixel): 04 04 04 06 06 06 06 06 45 56 67 78 78 move current position 5 right and 1 down 78 78 end of line 1e 1e 1e 1e 1e 1e 1e 1e 1e end of rle bitmap bi_rle4 when the bicompression member is set to bi_rle4, the bitmap is compressed using a run-length encoding (rle) format for a 4-bit bitmap, which also uses encoded and absolute modes. in encoded mode, the first byte of the pair contains the number of pixels to be drawn using the color indexes in the second byte. the second byte contains two color indexes, one in its high-order nibble (that is, its low-order four bits) and one in its low-order nibble. the first of the pixels is drawn using the color specified by the high-order nibble, the second is drawn using the color in the low-order nibble, the third is drawn with the color in the high-order nibble, and so on, until all the pixels specified by the first byte have been drawn. in absolute mode, the first byte contains zero, the second byte contains the number of color indexes that follow, and subsequent bytes contain color indexes in their high- and low-order nibbles, one color index for each pixel. in absolute mode, each run must be aligned on a word boundary. the end-of-line, end-of-bitmap, and delta escapes also apply to bi_rle4. the following example shows the hexadecimal values of a 4-bit compressed bitmap: 03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1e 00 01 this bitmap would expand as follows (single-digit values represent a color index for a single pixel): 0 4 0 0 6 0 6 0 4 5 5 6 6 7 7 8 7 8 move current position 5 right and 1 down 7 8 7 8 end of line 1 e 1 e 1 e 1 e 1 end of rle bitmap see also bitmapinfo ============================================================================== rgbquad (3.0) typedef struct tagrgbquad { /* rgbq */ byte rgbblue; byte rgbgreen; byte rgbred; byte rgbreserved; } rgbquad; the rgbquad structure describes a color consisting of relative intensities of red, green, and blue. the bmicolors member of the bitmapinfo structure consists of an array of rgbquad structures. member description rgbblue specifies the intensity of blue in the color. rgbgreenspecifies the intensity of green in the color. rgbred specifies the intensity of red in the color. rgbreserved not used; must be set to zero. see also bitmapinfo ============================================================================== rgb (2.x) colorref rgb(cred, cgreen, cblue) byte cred; /* red component of color */ byte cgreen; /* green component of color */ byte cblue; /* blue component of color */ the rgb macro selects an rgb color based on the parameters supplied and the color capabilities of the output device. parameter description cred specifies the intensity of the red color field. cgreen specifies the intensity of the green color field. cblue specifies the intensity of the blue color field. returns the return value specifies the resultant rgb color. comments the intensity for each argument can range from 0 through 255. if all three intensities are specified as zero, the result is black. if all three intensities are specified as 255, the result is white. comments the rgb macro is defined in windows.h as follows: #define rgb(r,g,b) ((colorref)(((byte)(r)|((word)(g)<<8))| \ (((dword)(byte)(b))<<16))) see also getbvalue, getgvalue, getrvalue, paletteindex, palettergb ============================================================================== bitmapcoreinfo (3.0) typedef struct tagbitmapcoreinfo { /* bmci */ bitmapcoreheader bmciheader; rgbtriple bmcicolors[1]; } bitmapcoreinfo; the bitmapcoreinfo structure fully defines the dimensions and color information for a device-independent bitmap (dib). windows applications should use the bitmapinfo structure instead of bitmapcoreinfo whenever possible. member description bmciheader specifies a bitmapcoreheader structure that contains information about the dimensions and color format of a dib. bmcicolors specifies an array of rgbtriple structures that define the colors in the bitmap. comments the bitmapcoreinfo structure describes the dimensions and colors of a bitmap. it is followed immediately in memory by an array of bytes which define the pixels of the bitmap. the bits in the array are packed together, but each scan line must be zero-padded to end on a long boundary. segment boundaries, however, can appear anywhere in the bitmap. the origin of the bitmap is the lower-left corner. the bcbitcount member of the bitmapcoreheader structure determines the number of bits that define each pixel and the maximum number of colors in the bitmap. this member may be set to any of the following values: value meaning 1 the bitmap is monochrome, and the bmcicolors member must contain two entries. each bit in the bitmap array represents a pixel. if the bit is clear, the pixel is displayed with the color of the first entry in the bmcicolors table. if the bit is set, the pixel has the color of the second entry in the table. 4 the bitmap has a maximum of 16 colors, and the bmcicolors member contains 16 entries. each pixel in the bitmap is represented by a four-bit index into the color table. for example, if the first byte in the bitmap is 0x1f, the byte represents two pixels. the first pixel contains the color in the second table entry, and the second pixel contains the color in the sixteenth table entry. 8 the bitmap has a maximum of 256 colors, and the bmcicolors member contains 256 entries. in this case, each byte in the array represents a single pixel. 24 the bitmap has a maximum of 2^24 colors. the bmcicolors member is null, and each 3-byte sequence in the bitmap array represents the relative intensities of red, green, and blue, respectively, of a pixel. the colors in the bmcicolors table should appear in order of importance. alternatively, for functions that use dibs, the bmcicolors member can be an array of 16-bit unsigned integers that specify an index into the currently realized logical palette instead of explicit rgb values. in this case, an application using the bitmap must call dib functions with the wusage parameter set to dib_pal_colors. note: the bmcicolors member should not contain palette indexes if the bitmap is to be stored in a file or transferred to another application. unless the application uses the bitmap exclusively and under its complete control, the bitmap color table should contain explicit rgb values. see also bitmapinfo, bitmapcoreheader, rgbtriple ============================================================================== bitmapcoreheader (3.0) typedef struct tagbitmapcoreheader { /* bmch */ dword bcsize; short bcwidth; short bcheight; word bcplanes; word bcbitcount; } bitmapcoreheader; the bitmapcoreheader structure contains information about the dimensions and color format of a device-independent bitmap (dib). windows applications should use the bitmapinfoheader structure instead of bitmapcoreheader whenever possible. member description bcsize specifies the number of bytes required by the bitmapcoreheader structure. bcwidth specifies the width of the bitmap, in pixels. bcheightspecifies the height of the bitmap, in pixels. bcplanesspecifies the number of planes for the target device. this member must be set to 1. bcbitcount specifies the number of bits per pixel. this value must be 1, 4, 8, or 24. comments the bitmapcoreinfo structure combines the bitmapcoreheader structure and a color table to provide a complete definition of the dimensions and colors of a dib. see the description of the bitmapcoreinfo structure for more information about specifying a dib. an application should use the information stored in the bcsize member to locate the color table in a bitmapcoreinfo structure with a method such as the following: lpcolor = ((lpstr) pbitmapcoreinfo + (uint) (pbitmapcoreinfo->bcsize)) see also bitmapcoreinfo, bitmapinfoheader, bitmapinfoheader ============================================================================= rgbtriple (3.0) typedef struct tagrgbtriple { /* rgbt */ byte rgbtblue; byte rgbtgreen; byte rgbtred; } rgbtriple; the rgbtriple structure describes a color consisting of relative intensities of red, green, and blue. the bmcicolors member of the bitmapcoreinfo structure consists of an array of rgbtriple structures. windows applications should use the bitmapinfo structure instead of bitmapcoreinfo whenever possible. the bitmapinfo structure uses an rgbquad structure instead of the rgbtriple structure. member description rgbtbluespecifies the intensity of blue in the color. rgbtgreen specifies the intensity of green in the color. rgbtred specifies the intensity of red in the color. see also bitmapcoreinfo, bitmapinfo, rgbquad |


Hurrah! I am clearly not alone in my loathing of Twitter. It seems to me thoroughly corrosive, of both journalism and public debate more broadly. But we cannot now uninvent it, so a way must be found to turn people away from it, and steer them towards a more elevated form of social network communication.
Three cheers, then, for Twitsum Twatsum, a new platform launched yesterday. This allows users to couch their every banal waking thought in the form of lengthy disquisitions in Latin, peppered with classical quotations and abstruse scholarly bagatelles. The minimum length of a so-called “Tweetum” is ten thousand words, and if a user attempts to insert one of those wretched “emoticon” horrors, the software is designed to cause their device (phone, tablet, etc.) to explode with a loud bang!, shattering it to smithereens.
I feel sure that millions around the world, who are currently destroying what is left of our civilisation by their endless Twittering, will embrace this splendid new service. I have already posted my first Tweetum, a crushingly tedious comment on what I had for breakfast made uncrushingly untedious by dint of its inordinate length, finely-wrought Latin prose, and quotations from Catullus.


Lightweight
With only 89 mods,
we hand pick and thoroughly vet each of our additions
Up-to-date
The latest versions are always supported, and mods are regularly updated!
Active Community
190+ members on Discord, and dedicated helpers are waiting for your question!


Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
111 mm men comm or ii; cmcurr macs mm» 1'1-us ms 15'"! ha?  R CHANDANAGOUIDAR, ADV.) TBHARATI GOPAL GHATAGE AGE : 45 YEARS Oi;.'§C : HOUSEHOLD WORK "R/<:) PLOT No.1, S.No. 595 " ANGOL, BELGAUM -590 003 ... RESPONDENT
r7K~fv'"
THIS PETITION IS FILED {US 432 CR.P.C. PH:Ai*ir;{3'-fro; QUASH THE ENTIRE PROCEEDINGS IN c.c.No,;574;,V2ojca.%or; THE FILE OF' JMFC 11 COURT, BELGAUM. " -- TI-{IS PETITION comm an F0? An.M1sLs1<3t¢.A%M_'T§1:s %' BAY, THE COURT MADE THE_FOLL()W'i1§G: A * - 2 ﬂ.onD£R , This petition is Cr.P.C. to quash the on the ﬁle of JMFCEI % No.1 and 2 are accused No.2 and 3 bcfére Couxt Accused No.1 and 2 am the partners of Respondent ﬁled complaint against the petitioners and others under Section 200 Cr.F'.C. for the oﬁ"§nt$e'v----1:5un1aha' 1318 under Section 37, 38, 39 and 40 of Air " {PI*s§?enﬁon and Control of Pollution) Act, 1981 R[w &ctio11s 157, 268, 2'?8, 299, 336, 463, 503, 505 River Section 107 of WC. The Trial Court Vida order dated 04.07.2008 had. taken cowizance of the offence against Atfcuscd Nos. 1 to 3 and OWN, issued process. Aggrieved by this order of the 'the petitioners. are before this Court to , pmceedings.
3. The learned the under Section 43 of the:4_i%<_:t, of the offence except on a person who has given notice qf min manner prescribed and of his to the Board or Oﬁcer authorised as that under Rule 20(3) of the shall be in Form No.9. In the absence ef" in the instant case, the '{';m_1rt taking cognizance of the offence "$9 nequirement under the Act i this oontention ofthe karned the at this stage. A perusal of the V that the xespondentl complainant gave 2 X' mgnpxgiﬂa to several authoriiies including the Bmrd. " complaints given by the complainant are in aeeuxelxmce with the Act and Rules is a matter of evidence,


About
Blurb
The Innertube Widgets API is used to create widgets of personal informatics visualizations for users to add to their Innertube Dashboard.
Dependencies
Innertube Widgets API is dependent on these great open-source projects:
- easyXDM for cross-domain messaging
- Underscore.js for utility functions
Examples
Here is a timeline example that describes the structure of an Innertube Widget.
You can find more examples of widgets created with the Innertube Widgets API at the Innertube web site.


My first photo
12/14
This is my first photo of the feed. This is a multi line comment for testing purposes. I am learning to code with #BreatheCode
This is my first photo of the feed. This is a multi line comment for testing purposes. I am learning to code with #BreatheCode
The internet approves this cute dog... #BreatheCode
This is me waiting for the screen to show my awesome first website made at #BreatheCode
Because no photo feed is cool without food on it! #BreatheCode


The City of New York was introduced to proffesional football on the same day that the city was introduced to the New York Giants. It was a clear sunny October afternoon in 1925 when Giants took the field to play against the Frankford Yellow Jackets


|
PX4 Firmware
PX4 Autopilot Software http://px4.io
|
#include <messages.h>
Public Attributes | |
| uint8_t | start |
| Start byte. More... | |
| uint8_t | gam_sensor_id |
| GAM sensor id. More... | |
| uint8_t | warning_beeps |
| uint8_t | sensor_text_id |
| uint8_t | alarm_invers1 |
| uint8_t | alarm_invers2 |
| uint8_t | cell1 |
| Lipo cell voltages. More... | |
| uint8_t | cell2 |
| uint8_t | cell3 |
| uint8_t | cell4 |
| uint8_t | cell5 |
| uint8_t | cell6 |
| uint8_t | batt1_L |
| Battery 1 voltage LSB value. More... | |
| uint8_t | batt1_H |
| uint8_t | batt2_L |
| Battery 2 voltage LSB value. More... | |
| uint8_t | batt2_H |
| uint8_t | temperature1 |
| Temperature 1. More... | |
| uint8_t | temperature2 |
| Temperature 2. More... | |
| uint8_t | fuel_procent |
| Fuel capacity in %. More... | |
| uint8_t | fuel_ml_L |
| Fuel in ml scale. More... | |
| uint8_t | fuel_ml_H |
| uint8_t | rpm_L |
| RPM in 10 RPM steps. More... | |
| uint8_t | rpm_H |
| uint8_t | altitude_L |
| Altitude in meters. More... | |
| uint8_t | altitude_H |
| uint8_t | climbrate_L |
| Climb rate in 0.01m/s. More... | |
| uint8_t | climbrate_H |
| uint8_t | climbrate3s |
| Climb rate in m/3sec. More... | |
| uint8_t | current_L |
| Current in 0.1A steps. More... | |
| uint8_t | current_H |
| uint8_t | main_voltage_L |
| Main power voltage using 0.1V steps. More... | |
| uint8_t | main_voltage_H |
| uint8_t | batt_cap_L |
| Used battery capacity in 10mAh steps. More... | |
| uint8_t | batt_cap_H |
| uint8_t | speed_L |
| Speed in km/h. More... | |
| uint8_t | speed_H |
| uint8_t | min_cell_volt |
| Minimum cell voltage in 2mV steps. More... | |
| uint8_t | min_cell_volt_num |
| Number of the cell with the lowest voltage. More... | |
| uint8_t | rpm2_L |
| RPM in 10 RPM steps. More... | |
| uint8_t | rpm2_H |
| uint8_t | general_error_number |
| Voice error == 12. More... | |
| uint8_t | pressure |
| Pressure up to 16bar. More... | |
| uint8_t | version |
| uint8_t | stop |
| Stop byte. More... | |
| uint8_t | checksum |
| Lower 8-bits of all bytes summed. More... | |
Definition at line 131 of file messages.h.
| uint8_t gam_module_msg::alarm_invers1 |
Definition at line 136 of file messages.h.
| uint8_t gam_module_msg::alarm_invers2 |
Definition at line 137 of file messages.h.
| uint8_t gam_module_msg::altitude_H |
Definition at line 157 of file messages.h.
| uint8_t gam_module_msg::altitude_L |
| uint8_t gam_module_msg::batt1_H |
Definition at line 145 of file messages.h.
| uint8_t gam_module_msg::batt1_L |
| uint8_t gam_module_msg::batt2_H |
Definition at line 147 of file messages.h.
| uint8_t gam_module_msg::batt2_L |
| uint8_t gam_module_msg::batt_cap_H |
Definition at line 166 of file messages.h.
| uint8_t gam_module_msg::batt_cap_L |
Used battery capacity in 10mAh steps.
Definition at line 165 of file messages.h.
| uint8_t gam_module_msg::cell1 |
| uint8_t gam_module_msg::cell2 |
Definition at line 139 of file messages.h.
| uint8_t gam_module_msg::cell3 |
Definition at line 140 of file messages.h.
| uint8_t gam_module_msg::cell4 |
Definition at line 141 of file messages.h.
| uint8_t gam_module_msg::cell5 |
Definition at line 142 of file messages.h.
| uint8_t gam_module_msg::cell6 |
Definition at line 143 of file messages.h.
| uint8_t gam_module_msg::checksum |
Lower 8-bits of all bytes summed.
Definition at line 177 of file messages.h.
| uint8_t gam_module_msg::climbrate3s |
| uint8_t gam_module_msg::climbrate_H |
Definition at line 159 of file messages.h.
| uint8_t gam_module_msg::climbrate_L |
| uint8_t gam_module_msg::current_H |
Definition at line 162 of file messages.h.
Referenced by build_gam_response(), and publish_gam_message().
| uint8_t gam_module_msg::current_L |
Current in 0.1A steps.
Definition at line 161 of file messages.h.
Referenced by build_gam_response(), and publish_gam_message().
| uint8_t gam_module_msg::fuel_ml_H |
Definition at line 153 of file messages.h.
| uint8_t gam_module_msg::fuel_ml_L |
| uint8_t gam_module_msg::fuel_procent |
Fuel capacity in %.
Values 0 - 100 Graphical display ranges: 0 25% 50% 75% 100%
Definition at line 150 of file messages.h.
| uint8_t gam_module_msg::gam_sensor_id |
| uint8_t gam_module_msg::general_error_number |
| uint8_t gam_module_msg::main_voltage_H |
Definition at line 164 of file messages.h.
Referenced by build_gam_response(), and publish_gam_message().
| uint8_t gam_module_msg::main_voltage_L |
Main power voltage using 0.1V steps.
Definition at line 163 of file messages.h.
Referenced by build_gam_response(), and publish_gam_message().
| uint8_t gam_module_msg::min_cell_volt |
| uint8_t gam_module_msg::min_cell_volt_num |
Number of the cell with the lowest voltage.
Definition at line 170 of file messages.h.
| uint8_t gam_module_msg::pressure |
| uint8_t gam_module_msg::rpm2_H |
Definition at line 172 of file messages.h.
| uint8_t gam_module_msg::rpm2_L |
| uint8_t gam_module_msg::rpm_H |
Definition at line 155 of file messages.h.
Referenced by build_gam_response(), and publish_gam_message().
| uint8_t gam_module_msg::rpm_L |
RPM in 10 RPM steps.
300 = 3000rpm
Definition at line 154 of file messages.h.
Referenced by build_gam_response(), and publish_gam_message().
| uint8_t gam_module_msg::sensor_text_id |
Definition at line 135 of file messages.h.
Referenced by build_gam_response().
| uint8_t gam_module_msg::speed_H |
Definition at line 168 of file messages.h.
| uint8_t gam_module_msg::speed_L |
Speed in km/h.
Definition at line 167 of file messages.h.
| uint8_t gam_module_msg::start |
| uint8_t gam_module_msg::stop |
| uint8_t gam_module_msg::temperature1 |
Temperature 1.
offset of 20. a value of 20 = 0°C
Definition at line 148 of file messages.h.
Referenced by build_gam_response(), and publish_gam_message().
| uint8_t gam_module_msg::temperature2 |
Temperature 2.
offset of 20. a value of 20 = 0°C
Definition at line 149 of file messages.h.
Referenced by build_gam_response().
| uint8_t gam_module_msg::version |
Definition at line 175 of file messages.h.
| uint8_t gam_module_msg::warning_beeps |
Definition at line 134 of file messages.h.


Drawing Lines
Drawing Curves
Using Path Methods
Using Rect Method
Fill Gradient
Radial Gradient
External Image Fill Pattern
Photo by Miguel Á. Padriñán from Pexels
Drawing Image
Photo by Omran Jamal from Pexels
Photo by Miguel Á. Padriñán from Pexels
Photo by Omran Jamal from Pexels


|
JTS Topology Suite version 1.13 | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object com.vividsolutions.jts.algorithm.MinimumDiameter
public class MinimumDiameter
Computes the minimum diameter of a Geometry
.
The minimum diameter is defined to be the
width of the smallest band that
contains the geometry,
where a band is a strip of the plane defined
by two parallel lines.
This can be thought of as the smallest hole that the geometry can be
moved through, with a single rotation.
The first step in the algorithm is computing the convex hull of the Geometry. If the input Geometry is known to be convex, a hint can be supplied to avoid this computation.
This class can also be used to compute a line segment representing the minimum diameter, the supporting line segment of the minimum diameter, and a minimum rectangle enclosing the input geometry. This rectangle will have width equal to the minimum diameter, and have one side parallel to the supporting segment.
ConvexHull
| Constructor Summary | |
|---|---|
MinimumDiameter(Geometry inputGeom)
Compute a minimum diameter for a given Geometry . |
|
MinimumDiameter(Geometry inputGeom,
boolean isConvex)
Compute a minimum diameter for a giver Geometry ,
with a hint if
the Geometry is convex
(e.g. |
| Method Summary | |
|---|---|
LineString |
getDiameter()
Gets a LineString which is a minimum diameter |
double |
getLength()
Gets the length of the minimum diameter of the input Geometry |
Geometry |
getMinimumRectangle()
Gets the minimum rectangular Polygon which encloses the input geometry. |
LineString |
getSupportingSegment()
Gets the segment forming the base of the minimum diameter |
Coordinate |
getWidthCoordinate()
Gets the Coordinate forming one end of the minimum diameter |
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Constructor Detail |
|---|
public MinimumDiameter(Geometry inputGeom)
Geometry
.
geom
- a Geometrypublic MinimumDiameter(Geometry inputGeom, boolean isConvex)
Geometry
,
with a hint if
the Geometry is convex
(e.g. a convex Polygon or LinearRing,
or a two-point LineString, or a Point).
geom
- a Geometry which is convexisConvex
- true
if the input geometry is convex| Method Detail |
|---|
public double getLength()
public Coordinate getWidthCoordinate()
Coordinate
forming one end of the minimum diameter
public LineString getSupportingSegment()
public LineString getDiameter()
LineString
which is a minimum diameter
LineString
which is a minimum diameterpublic Geometry getMinimumRectangle()
Polygon
which encloses the input geometry.
The rectangle has width equal to the minimum diameter,
and a longer length.
If the convex hull of the input is degenerate (a line or point)
a LineString
or Point
is returned.
The minimum rectangle can be used as an extremely generalized representation for the given geometry.
|
JTS Topology Suite version 1.13 | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


Nov 29th 2008 by neue
Not Rated
Nov 29th 2008 by neue
Not Rated
Nov 29th 2008 by neue
Four Stars
Nov 29th 2008 by mike1052
Not Rated
Nov 29th 2008 by FrancescoOnAir
Five Stars
Nov 29th 2008 by John Doe
Not Rated
Nov 29th 2008 by John Doe
Not Rated
Nov 29th 2008 by John Doe
Not Rated
Nov 29th 2008 by John Doe
Not Rated
Nov 29th 2008 by John Doe
Not Rated
Nov 29th 2008 by John Doe
Not Rated
Nov 29th 2008 by John Doe
Not Rated
Nov 29th 2008 by John Doe
Not Rated


MPI_SCATTER( sendbuf, sendcount, sendtype, recvbuf,
recvcount, recvtype, root, comm)
[ IN sendbuf] address of send buffer (choice, significant
only at root)
[ IN sendcount] number of elements sent to each process
(integer, significant only at root)
[ IN sendtype] data type of send buffer elements
(significant only at root) (handle)
[ OUT recvbuf] address of receive buffer (choice)
[ IN recvcount] number of elements in receive buffer (integer)
[ IN recvtype] data type of receive buffer elements (handle)
[ IN root] rank of sending process (integer)
[ IN comm] communicator (handle)
int MPI_Scatter(void* sendbuf, int sendcount, MPI_Datatype sendtype, void* recvbuf, int recvcount, MPI_Datatype recvtype, int root, MPI_Comm comm)
MPI_SCATTER(SENDBUF, SENDCOUNT, SENDTYPE, RECVBUF, RECVCOUNT, RECVTYPE, ROOT, COMM, IERROR)
<type> SENDBUF(*), RECVBUF(*)
INTEGER SENDCOUNT, SENDTYPE, RECVCOUNT, RECVTYPE, ROOT, COMM, IERROR
MPI_SCATTER is the inverse operation to MPI_GATHER.
The outcome is as if the root executed n send operations,
and each process executed a receive,
An alternative description is that the root sends a message with MPI_Send(sendbuf, sendcount n, sendtype, ...). This message is split into n equal segments, the ith segment is sent to the ith process in the group, and each process receives this message as above.
The send buffer is ignored for all non-root processes.
The type signature associated with sendcount, sendtype at the root must be equal to the type signature associated with recvcount, recvtype at all processes (however, the type maps may be different). This implies that the amount of data sent must be equal to the amount of data received, pairwise between each process and the root. Distinct type maps between sender and receiver are still allowed.
All arguments to the function are significant on process root, while on other processes, only arguments recvbuf, recvcount, recvtype, root, comm are significant. The arguments root and comm must have identical values on all processes.
The specification of counts and types should not cause any location on the root to be read more than once.
[] Rationale.
Though not needed, the last restriction is imposed so as
to achieve symmetry with
MPI_GATHER, where the corresponding restriction (a multiple-write
restriction) is necessary.
( End of rationale.)
MPI_SCATTERV( sendbuf, sendcounts, displs, sendtype,
recvbuf, recvcount, recvtype, root, comm)
[ IN sendbuf] address of send buffer (choice, significant
only at root)
[ IN sendcounts] integer array (of length group size)
specifying the number of elements to send to each processor
[ IN displs] integer array (of length group size). Entry
i specifies the displacement (relative to sendbuf from
which to take the outgoing data to process i
[ IN sendtype] data type of send buffer elements (handle)
[ OUT recvbuf] address of receive buffer (choice)
[ IN recvcount] number of elements in receive buffer (integer)
[ IN recvtype] data type of receive buffer elements (handle)
[ IN root] rank of sending process (integer)
[ IN comm] communicator (handle)
int MPI_Scatterv(void* sendbuf, int *sendcounts, int *displs, MPI_Datatype sendtype, void* recvbuf, int recvcount, MPI_Datatype recvtype, int root, MPI_Comm comm)
MPI_SCATTERV(SENDBUF, SENDCOUNTS, DISPLS, SENDTYPE, RECVBUF, RECVCOUNT, RECVTYPE, ROOT, COMM, IERROR)
<type> SENDBUF(*), RECVBUF(*)
INTEGER SENDCOUNTS(*), DISPLS(*), SENDTYPE, RECVCOUNT, RECVTYPE, ROOT, COMM, IERROR
MPI_SCATTERV is the inverse operation to MPI_GATHERV.
MPI_SCATTERV extends the functionality of MPI_SCATTER by allowing a varying count of data to be sent to each process, since sendcounts is now an array. It also allows more flexibility as to where the data is taken from on the root, by providing the new argument, displs.
The outcome is as if the root executed n send operations,
and each process executed a receive,
The send buffer is ignored for all non-root processes.
The type signature implied by sendcount[i], sendtype at the root must be equal to the type signature implied by recvcount, recvtype at process i (however, the type maps may be different). This implies that the amount of data sent must be equal to the amount of data received, pairwise between each process and the root. Distinct type maps between sender and receiver are still allowed.
All arguments to the function are significant on process root, while on other processes, only arguments recvbuf, recvcount, recvtype, root, comm are significant. The arguments root and comm must have identical values on all processes.
The specification of counts, types, and displacements should not cause any location on the root to be read more than once.


# Calque - reactive calculator # (cheat sheet is available via right click menu) # Expressions 2 + 2 * 2 sqrt(3^2 + 4^2) 2 inch to cm cos(45 deg) # Variables a = 25 b = a * 2 postal code = 1122 # Summing lists animals: cats = 2 dogs = 3 plants: trees = 20 vegetables: potatoes = 10 carrots = 10 # Functions pow2(x) = x ^ 2 pow2(6) # Last result 2 * 2 last + 1 # Keys # Duplicate line or selection: Ctrl+D # Change selected number: Up/Down # Change selected number 10x: Shift+Up/Down # Change indent: Tab/Shift+Tab # Zoom in: Ctrl+Shift+Plus # Zoom out: Ctrl+Minus # Themes can be changed via the right click menu. # Calque Desktop on Github # https://github.com/unplugred/calque-desktop # Fork of Calque: # https://github.com/grimalschi/calque # Using Math.js: # https://github.com/grimalschi/mathjs


QVideoRendererControl Class
The QVideoRendererControl class provides a media control for rendering video to a QAbstractVideoSurface. More...
| Header: | #include <QVideoRendererControl> |
| qmake: | QT += multimedia |
| Inherits: | QMediaControl |
Public Functions
| ~QVideoRendererControl() | |
| virtual void | setSurface(QAbstractVideoSurface *surface) = 0 |
| virtual QAbstractVideoSurface * | surface() const = 0 |
- 32 public functions inherited from QObject
Protected Functions
| QVideoRendererControl(QObject *parent = Q_NULLPTR) |
- 9 protected functions inherited from QObject
Macros
Additional Inherited Members
- 1 property inherited from QObject
- 1 public slot inherited from QObject
- 2 signals inherited from QObject
- 1 public variable inherited from QObject
- 10 static public members inherited from QObject
- 2 protected variables inherited from QObject
Detailed Description
The QVideoRendererControl class provides a media control for rendering video to a QAbstractVideoSurface.
Using the surface() property of QVideoRendererControl a QAbstractVideoSurface may be set as the video render target of a QMediaService.
QVideoRendererControl *rendererControl = mediaService->requestControl<QVideoRendererControl *>(); rendererControl->setSurface(myVideoSurface);
QVideoRendererControl is one of a number of possible video output controls.
The interface name of QVideoRendererControl is org.qt-project.qt.videorenderercontrol/5.0
as defined in QVideoRendererControl_iid.
See also QMediaService::requestControl() and QVideoWidget.
Member Function Documentation
[protected]
QVideoRendererControl::QVideoRendererControl(QObject *parent = Q_NULLPTR)
Constructs a new video renderer media end point with the given parent.
QVideoRendererControl::~QVideoRendererControl()
Destroys a video renderer media end point.
[pure virtual]
void QVideoRendererControl::setSurface(QAbstractVideoSurface *surface)
Sets the surface a video producer renders to.
See also surface().
[pure virtual]
QAbstractVideoSurface *QVideoRendererControl::surface() const
Returns the surface a video producer renders to.
See also setSurface().
Macro Documentation
QVideoRendererControl_iid
org.qt-project.qt.videorenderercontrol/5.0
Defines the interface name of the QVideoRendererControl class.


Jury chooses death for convicted killer of Tecumseh police officer
by Kim MoravaEarlier coverage:
SHAWNEE — In less than two hours Friday afternoon, a Pottawatomie County jury returned verdicts on four aggravating factors and chose the death penalty for Byron James Shepard, the man convicted earlier this week in the 2017 killing of Tecumseh police officer Justin Terney.
Shepard, 38, of Okemah, had no reaction as the court clerk read the jury's verdict before a packed courtroom that included Terney's family and several area police officers. District Judge John G. Canavan has scheduled formal sentencing for 9 a.m. Jan. 3.
After Friday's decision, Tecumseh Police Chief J.R. Kidney said he had no words to describe the emotions.
“The justice system came through for us today. I know that's what the family, I know that's what law enforcement was looking for,” he said. “We all went to the courtroom with a very good feeling and they didn't let us down.”
Kidney said Terney, who wanted to be a police officer since he was 3 years old, became an officer at age 21 and started living his dream.
“Less than one year into it, his dream was taken away, so don't let the memory of Justin Terney die. Remember that he was a young man doing what he loved and fighting for his community the night that he died,” Kidney said.
Terney, 22, died March 27, 2017, from gunshot wounds he suffered the night before in a shootout with Shepard, who was a passenger in a vehicle stopped by Terney that night.Prosecutors argued Shepard, who was a fugitive, shot Terney that night to avoid going to jail. Prosecutors pointed out Shepard's criminal history, as well as past violence and drug use. Shepard's public defenders argued that the shooting and officer's death were unintentional, and asked the jury to spare his life and allow him to spend the rest of his life in prison.
In the state's closing arguments, Prosecutor Pattye High told the jury they were tasked with deciding the death penalty because of the choices Shepard made that night, which included lying to the officer and giving him a false name before running into a dark treeline.
“Jail wasn't an option for Byron Shepard on March 26, 2017, and jail is not an option today — sentence him to death,” High said.
Public Defender Shea Smith told jurors they needed to look at Shepard's entire life and “not just what happened in the field that night.”
Smith reminded the jury that Shepard has some humanity in him.
“Send him to prison forever and throw away the key,” Smith said as she asked the jury to spare Shepard from death.
Several of Terney's family members quietly showed signs of relief as the verdict was read. During the second phase of the trial, Terney's siblings were among those who testified.The jury also found Shepard guilty of knowingly concealing stolen property relating to the stolen firearm used in the homicide, along with a charge of possession of controlled dangerous substance, methamphetamine. Shepard will remain jailed in the Pottawatomie County jail until formal sentencing.Shepard's girlfriend, Brooklyn Danielle Williams, who was driving the vehicle the night of the traffic stop, stood trial this year and was convicted of second-degree murder in Terney's death. She is serving a 25-year prison sentence.
Related Photos