- handleCellEvent() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the cell clicked by the player on the pattern card depending on the state of the game
- handleDicePool() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the dice clicked by the player in the draft pool depending on the state of the game
- handleDifficultyBox() - Method in class it.polimi.se2018.client.view.gui.GuiController
-
method that handle the difficulty selected from the user in the combo box for the single player mode
- handleOtherPattern(boolean) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the disable of the pattern card of the other player
- handlePattern(boolean) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the disable of the pattern card of the player
- handlePlayButton() - Method in class it.polimi.se2018.client.view.gui.GuiController
-
method that handle the click of the play button to set the name of the player to the server
- handlePrivateUnzoom() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the private card
- handlePrivateUnzoom() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the first private card
- handlePrivateUnzoom2() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the second private
- handlePrivateZoom() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the zoom of the private card
- handlePrivateZoom() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the first private card
- handlePrivateZoomTwo() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the second private
- handlePublicUnzoom1() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the first public card
- handlePublicUnzoom2() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the second public card
- handlePublicUnzoom3() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the third public card
- handlePublicZoom1() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the first public card
- handlePublicZoom2() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the second public card
- handlePublicZoom3() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the third public card
- handleRoundButton() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the round button clicked by the player on the round tracker depending on the state of the game
- handleRoundTracker(boolean) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the disable of the round tracker
- handleTool1(MouseEvent) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the tool card 5 in the board and manage what to do
depending on the state of the game
- handleTool1() - Method in class it.polimi.se2018.client.view.gui.ToolCardRequest
-
method that allows to select the tool 1
- handleTool12() - Method in class it.polimi.se2018.client.view.gui.ToolCardRequest
-
method that allows to select the tool 12
- handleTool2(MouseEvent) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the tool card 5 in the board and manage what to do
depending on the state of the game
- handleTool3(MouseEvent) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the tool card 5 in the board and manage what to do
depending on the state of the game
- handleTool4(MouseEvent) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the tool card 4 in the board and manage what to do
depending on the state of the game
- handleTool5(MouseEvent) - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the tool card 5 in the board and manage what to do
depending on the state of the game
- handleToolEleven() - Method in class it.polimi.se2018.client.view.gui.ToolCardRequest
-
method that allows to select a tool
- handleToolUnzoom1() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the first tool card
- handleToolUnzoom2() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the second tool card
- handleToolUnzoom3() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the third tool card
- handleToolUnzoom4() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the fourth tool card
- handleToolUnzoom5() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to unzoom the fifth tool card
- handleToolZoom1() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the first tool card
- handleToolZoom2() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the second tool card
- handleToolZoom3() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the third tool card
- handleToolZoom4() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the fourth tool card
- handleToolZoom5() - Method in class it.polimi.se2018.client.view.gui.ChoosePattern
-
method that allows to zoom the fourth tool card
- handleUnzoomPublic1() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the public card 1
- handleUnzoomPublic2() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the public card 2
- handleUnzoomPublic3() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the public card 3
- handleUnzoomTool1() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the tool card 1
- handleUnzoomTool2() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the tool card 2
- handleUnzoomTool3() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the tool card 5
- handleUnzoomTool4() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the tool card 4
- handleUnzoomTool5() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the unzoom of the tool card 5
- handleUpdatePattern2() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the pattern card of enemy player 2
- handleUpdatePattern3() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the pattern card of enemy player 3
- handleUpdatePattern4() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click of the pattern card of enemy player 4
- handleZoomPublic1() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the zoom of the private card
- handleZoomPublic2() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the zoom of the private card
- handleZoomPublic3() - Method in class it.polimi.se2018.client.view.gui.BoardController
-
method that handle the click for the zoom of the private card
- handlingDisconnection(int, VirtualView) - Method in class it.polimi.se2018.server.controller.GameController
-
method that manage the disconnection of the client on the basis of the current game moment, handle also the case of the
player doesn't set name or doesn't chose pattern card or both
- handlingReconnection(VirtualView) - Method in class it.polimi.se2018.server.controller.GameController
-
method that manage the reconnection of the client linking the new virtual view with that one previously disconnected
- hashCode() - Method in class it.polimi.se2018.client.network.rmi.RmiClientImpl
-
- hashCode() - Method in class it.polimi.se2018.server.network.rmi.RmiServerImpl
-
- host - Variable in class it.polimi.se2018.client.view.cli.ClientCli
-


EpBunch¶
| Author: | Santosh Philip. |
|---|
EpBunch is at the heart of what makes eppy easy to use. Specifically
Epbunch is what allows us to use the syntax building.Name
and
building.North_Axis
. Some advanced coding had to be done to make
this happen. Coding that would be easy for professional programmers, but
not for us ordinary folk :-(
Most of us who are going to be coding eppy are not professional programmers. I was completely out of my depth when I did this coding. I had the code reviewed by programmers who do this for a living (at python meetups in the Bay Area). In their opinion, I was not doing anything fundamentally wrong.
Below is a fairly long explanation, to ease you into the code. Read through the whole thing without trying to understand every detail, just getting a birds eye veiw of the explanation. Then read it again, you will start to grok some of the details. All the code here is working code, so you can experiment with it.
Magic Methods (Dunders) of Python¶
To understand how EpBunch or Bunch is coded, one has to have an understanding of the magic methods of Python. (For a background on magic methods, take a look at http://www.rafekettler.com/magicmethods.html) Let us dive straight into this with some examples
adict = dict(a=10, b=20) # create a dictionary
print adict
print adict['a']
print adict['b']
{'a': 10, 'b': 20}
10
20
What happens when we say d[‘a’] ?
This is where the magic methods come in. Magic methods are methods that
work behind the scenes and do some magic. So when we say d[‘a’], The
dict is calling the method __getitem__('a')
.
Magic methods have a double underscore “__
”, called dunder
methods for short
Let us override that method and see what happens.
class Funnydict(dict): # we are subclassing dict here
def __getitem__(self, key):
value = super(Funnydict, self).__getitem__(key)
return "key = %s, value = %s" % (key, value)
funny = Funnydict(dict(a=10, b=20))
print funny
{'a': 10, 'b': 20}
The print worked as expected. Now let us try to print the values
print funny['a']
print funny['b']
key = a, value = 10
key = b, value = 20
Now that worked very differently from a dict
So it is true, funny[‘a’] does call __getitem__()
that we just wrote
Let us go back to the variable adict
# to jog our memory
print adict
{'a': 10, 'b': 20}
# this should not work
print adict.a
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-5-8aa7211fcb66> in <module>()
1 # this should not work
----> 2 print adict.a
AttributeError: 'dict' object has no attribute 'a'
What method gets called when we say adict.a ?
The magic method here is __getattr__
() and __setattr__()
.
Shall we override them and see if we can get the dot notation to work ?
class Like_bunch(dict):
def __getattr__(self, name):
return self[name]
def __setattr__(self, name, value):
self[name] = value
lbunch = Like_bunch(dict(a=10, b=20))
print lbunch
{'a': 10, 'b': 20}
Works like a dict so far. How about lbunch.a ?
print lbunch.a
print lbunch.b
10
20
Yipeee !!! I works
How about lbunch.nota = 100
lbunch.anot = 100
print lbunch.anot
100
All good here. But don’t trust the code above too much. It was simply done as a demonstration of dunder methods and is not fully tested.
Eppy uses the bunch library to do something similar. You can read more about the bunch library in the previous section.
Open an IDF file¶
Once again let us open a small idf file to test.
# you would normaly install eppy by doing
# python setup.py install
# or
# pip install eppy
# or
# easy_install eppy
# if you have not done so, uncomment the following three lines
import sys
# pathnameto_eppy = 'c:/eppy'
pathnameto_eppy = '../../../'
sys.path.append(pathnameto_eppy)
from eppy import modeleditor
from eppy.modeleditor import IDF
iddfile = "../../../eppy/resources/iddfiles/Energy+V7_2_0.idd"
fname1 = "../../../eppy/resources/idffiles/V_7_2/dev1.idf"
IDF.setiddname(iddfile)
idf1 = IDF(fname1)
idf1.printidf()
VERSION,
7.3; !- Version Identifier
SIMULATIONCONTROL,
Yes, !- Do Zone Sizing Calculation
Yes, !- Do System Sizing Calculation
Yes, !- Do Plant Sizing Calculation
No, !- Run Simulation for Sizing Periods
Yes; !- Run Simulation for Weather File Run Periods
BUILDING,
Empire State Building, !- Name
30.0, !- North Axis
City, !- Terrain
0.04, !- Loads Convergence Tolerance Value
0.4, !- Temperature Convergence Tolerance Value
FullExterior, !- Solar Distribution
25, !- Maximum Number of Warmup Days
6; !- Minimum Number of Warmup Days
SITE:LOCATION,
CHICAGO_IL_USA TMY2-94846, !- Name
41.78, !- Latitude
-87.75, !- Longitude
-6.0, !- Time Zone
190.0; !- Elevation
MATERIAL:AIRGAP,
F04 Wall air space resistance, !- Name
0.15; !- Thermal Resistance
MATERIAL:AIRGAP,
F05 Ceiling air space resistance, !- Name
0.18; !- Thermal Resistance
dtls = idf1.model.dtls
dt = idf1.model.dt
idd_info = idf1.idd_info
dt['MATERIAL:AIRGAP']
[['MATERIAL:AIRGAP', 'F04 Wall air space resistance', 0.15],
['MATERIAL:AIRGAP', 'F05 Ceiling air space resistance', 0.18]]
obj_i = dtls.index('MATERIAL:AIRGAP')
obj_idd = idd_info[obj_i]
obj_idd
[{'memo': ['Air Space in Opaque Construction'], 'min-fields': ['2']},
{'field': ['Name'],
'reference': ['MaterialName'],
'required-field': [''],
'type': ['alpha']},
{'field': ['Thermal Resistance'],
'minimum>': ['0'],
'type': ['real'],
'units': ['m2-K/W']}]
For the rest of this section let us look at only one airgap object
airgap = dt['MATERIAL:AIRGAP'][0]
airgap
['MATERIAL:AIRGAP', 'F04 Wall air space resistance', 0.15]
Subclassing of Bunch¶
Let us review our knowledge of bunch
from bunch import Bunch
adict = {'a':1, 'b':2, 'c':3}
bunchdict = Bunch(adict)
print bunchdict
print bunchdict.a
print bunchdict.b
print bunchdict.c
Bunch(a=1, b=2, c=3)
1
2
3
Bunch lets us use dot notation on the keys of a dictionary. We need to
find a way of making airgap.Name
work. This is not straightforward
because, airgap is list and Bunch works on dicts. It would be
easy if airgap was in the form
{'Name' : 'F04 Wall air space resistance', 'Thermal Resistance' : 0.15}
.
The rest of this section is a simplified version of how EpBunch works.
class EpBunch(Bunch):
def __init__(self, obj, objls, objidd, *args, **kwargs):
super(EpBunch, self).__init__(*args, **kwargs)
self.obj = obj
self.objls = objls
self.objidd = objidd
The above code shows how EpBunch is initialized. Three variables are
passed to EpBunch to initialize it. They are obj, objls, objidd
.
obj = airgap
objls = ['key', 'Name', 'Thermal_Resistance'] # a function extracts this from idf1.idd_info
objidd = obj_idd
#
print obj
print objls
# let us ignore objidd for now
['MATERIAL:AIRGAP', 'F04 Wall air space resistance', 0.15]
['key', 'Name', 'Thermal_Resistance']
Now we override __setattr__()
and __getattr__()
in the following
way
class EpBunch(Bunch):
def __init__(self, obj, objls, objidd, *args, **kwargs):
super(EpBunch, self).__init__(*args, **kwargs)
self.obj = obj
self.objls = objls
self.objidd = objidd
def __getattr__(self, name):
if name in ('obj', 'objls', 'objidd'):
return super(EpBunch, self).__getattr__(name)
i = self.objls.index(name)
return self.obj[i]
def __setattr__(self, name, value):
if name in ('obj', 'objls', 'objidd'):
super(EpBunch, self).__setattr__(name, value)
return None
i = self.objls.index(name)
self.obj[i] = value
# Let us create a EpBunch object
bunch_airgap = EpBunch(obj, objls, objidd)
# Use this table to see how __setattr__ and __getattr__ work in EpBunch
obj = ['MATERIAL:AIRGAP', 'F04 Wall air space resistance', 0.15 ]
objls = ['key', 'Name', 'Thermal_Resistance']
i = 0 1 2
print bunch_airgap.Name
print bunch_airgap.Thermal_Resistance
F04 Wall air space resistance
0.15
print bunch_airgap.obj
['MATERIAL:AIRGAP', 'F04 Wall air space resistance', 0.15]
Let us change some values using the dot notation
bunch_airgap.Name = 'Argon in gap'
print bunch_airgap.Name
Argon in gap
print bunch_airgap.obj
['MATERIAL:AIRGAP', 'Argon in gap', 0.15]
Using the dot notation the value is changed in the list
Let us make sure it actually has done that.
idf1.model.dt['MATERIAL:AIRGAP'][0]
['MATERIAL:AIRGAP', 'Argon in gap', 0.15]
EpBunch
acts as a wrapper around
idf1.model.dt['MATERIAL:AIRGAP'][0]
In other words EpBunch
is just Syntactic Sugar for
idf1.model.dt['MATERIAL:AIRGAP'][0]
Variables and Names in Python¶
At this point your reaction may, “I don’t see how all those values in
idf1.model.dt
changed”. If such question arises in your mind, you
need to read the following:
- Other languages have ‘variables’
- Python has ‘names’
- Also see Facts and myths about Python names and values
This is especially important if you are experienced in other languages, and you expect the behavior to be a little different. Actually follow and read those links in any case.
Continuing with EpBunch¶
EpBunch_1¶
The code for EpBunch in the earlier section will work, but has been
simplified for clarity. In file bunch_subclass.py
take a look at the
class EpBunch_1 . This class does the first override of
__setattr__
and __getattr__
. You will see that the code is a
little more involved, dealing with edge conditions and catching
exceptions.
EpBunch_1 also defines __repr__
. This lets you print EpBunch in
a human readable format. Further research indicates that __str__
should have been used to do this, not __repr__
:-(
EpBunch_2¶
EpBunch_2
is subclassed from EpBunch_1
.
It overrides __setattr__
and __getattr__
to add a small
functionality that has not been documented or used. The idea was to give
the ability to shorten field names with alias. So
building.Maximum_Number_of_Warmup_Days
could be made into
building.warmupdays
.
I seemed like a good idea when I wrote it. Ignore it for now, although it may make a comeback :-)
EpBunch_3¶
EpBunch_3
is subclassed from EpBunch_2
.
EpBunch_3 adds the ability to add functions to EpBunch objects. This
would allow the object to make calculations using data within the
object. So BuildingSurface:Detailed
object has all the geometry data
of the object. The function ‘area’ will let us calculate the are of the
object even though area is not a field in BuildingSurface:Detailed
.
So you can call idf1.idfobjects["BuildingSurface:Detailed"][0].area
and get the area of the surface.
At the moment, the functions can use only data within the object for it’s calculation. We need to extend this functionality so that calculations can be done using data outside the object. This would be useful in calculating the volume of a Zone. Such a calculation would need data from the surfaces that the aone refers to.
EpBunch_4¶
EpBunch_4
is subclassed from EpBunch_3
.
EpBunch_4
overrides _setitem__
and __getitem__
. Right now
airgap.Name
works. This update allows airgap["Name"]
to work
correctly too
EpBunch_5¶
EpBunch_5
is subclassed from EpBunch_4
.
EpBunch_5
adds functions that allows you to call functions
getrange
and checkrange
for a field
Finally EpBunch¶
EpBunch = EpBunch_5
Finally EpBunch_5
is named as EpBunch. So the rest of the code uses
EpBunch and in effect it uses Epbunch_5


Puerto Chiapas is the southern most port in Mexico and 14 miles north of the Mexico-Guatemala border on the Pacific coast. Cruisers recommend this as a good place to haul out and do bottom work on your boat, and even store it during rainy season.
Logistically, it is the ideal place for northbound yachts to clear into Mexico and wait for a safe crossing of the notoriously windy 260-mile-wide Gulf of Tehuantepec. For southbound boats, it is a convenient stopover for refuelling, reprovisioning and for handling Zarpe paperwork before departing Mexico into Central American cruising waters.
Formally known as Puerto Madero, the name was changed a few years ago after the cruise ship terminal was built. Cruisers report that a great deal of work is on-going to improve the port and make it welcoming to visiting yachtsmen. Marina Chiapas (see photo taken from their website) opened here in December 2011.
Position 14° 41'38" N, 92°25'10"W (Harbour entrance)
Call the port captain on VHF Ch. 16 when you are near the sea buoy to ask permission to enter the port and give notice of where you intend to moor. All of the port officials speak English and all formalities can be carried out at the marina.
If you call the marina when you are a couple of miles out, they will come out to greet you and guide you in. The Port Captain, Customs, and Health inspection will come on board to complete formalities. Immigration are based at the airport which is 10 minutes by car. Cruisers have reported being given a lift there by marina staff.
If you arrive having applied online for a Temporary Import Permit (TIP) in advance, you won't have any problems checking in here. However, if you intend to get a TIP on arrival, this port is not recommended as the officials are not familiar with the necessary paperwork. Huatulco is the closest alternative port for clearance and the TIP process is reported to be relatively straightforward there. More comments on the TIP by cruisers who have visited PC can be found here.
Note that if you checked out of Mexico in Huatulco you cannot enter Puerto Chiapas for any reason (except emergencies) with out having to check back into (and out) of the country. Being low on fuel, tired, engine problems, and similar is not considered an emergency.

Last updated May 2016.
The curved access channel into the new private yacht basin lies off the eastern corner of the east bay, at Puerto Chiapas. The east bay also houses the Mexican navy base and two fuel docks.
Cruise ships enter and dock in the northern bay of Puerto Chiapas, so if boaters wish to anchor there temporarily, it is at the discretion of the port captain. The API charge 80 peso/day for mooring here.
The marina’s access channel and yacht basin are dredged to a minimum depth of 15 feet at mean low water. The location provides 360-degree shelter from Tehuantepec winds and is a good hurricane hole. This marina offers some of the best facilities for cruisers along the entire Pacific coast of Mexico.
The harbormaster is called Enrique Laclette and is reported to be very helpful. It may be difficult however to get an answer by email and the marina website is suspended (2016). Best to call by telephone in advance.
The marina no longer operate a shuttle into Tapachula for shopping, but buses and taxis are available. In Tapachula there is a Wal-Mart, Home Depot, Auto Zone, Sam's Club....... and it is a $20 taxi ride back. There are no chandleries/boat parts or accessories available here however. so if planning on doing work on your boat here it's advisable to bring everything with you.
Last updated May 2016.


PGMA Files
ASCII PGM Files (Portable Gray Map)
PGMA is a data directory which
contains examples of the ASCII PGM (Portable Gray Map) file format. It is a simple
grayscale image description. The definition is as follows:
-
the typical file extension is ".pgm", but an extension of
".pnm" is also occasionally used.
-
A "magic number" for identifying the file type. An
ASCII PGM file's magic
number is the two characters "P2".
-
Whitespace (blanks, TABs, CRs, LFs).
-
A width, formatted as ASCII characters in decimal.
-
Whitespace.
-
A height, again in ASCII decimal.
-
Whitespace.
-
The maximum gray value, again in ASCII decimal.
-
Whitespace.
-
Width * height gray values, each in ASCII decimal, between 0 and the
specified maximum value, separated by whitespace, starting at the
top-left corner of the graymap, proceeding in normal English
reading order.
A value of 0 means black, and the maximum value means white.
Characters from a "#" to the next end-of-line are ignored (comments).
No line should be longer than 70 characters.
Example ASCII PGM file:
P2
# feep.ascii.pgm
24 7
15
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 3 3 3 3 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 15 0
0 3 3 3 0 0 0 7 7 7 0 0 0 11 11 11 0 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 0 0
0 3 0 0 0 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ASCII PGM File Characteristics:
-
ASCII
-
Gray
-
2D
-
No compression
-
1 image
Licensing:
The computer code and data files described and made available on this web page
are distributed under
the GNU LGPL license.
Related Data and Programs:
PBMA,
a data directory which
describes ASCII PBM (Portable Bit Map) files.
PGMB,
a data directory which
describes binary PGM (Portable Gray Map) files.
PPMA,
a data directory which
describes ASCII PPM (Portable Pixel Map) files.
Reference:
-
the NETPBM homepage.
Sample Files:
-
apollonian_gasket.ascii.pgm,
a 600 wide by 600 high image of an Apollonian gasket.
-
apollonian_gasket.png, a PNG image.
-
baboon.ascii.pgm,
a 512 wide by 512 high image of a baboon.
-
baboon.png, a PNG image.
-
balloons.ascii.pgm,
a 640 wide by 480 high image of a couple, with balloons.
-
balloons.png, a PNG image.
-
balloons_noisy.ascii.pgm,
a 640 wide by 480 high image of a couple, with balloons,
after "salt and pepper" noise has been added.
-
balloons_noisy.png, a PNG image.
-
barbara.ascii.pgm,
a 512 wide by 512 high image of a woman.
-
barbara.png, a PNG image.
-
body1.ascii.pgm,
a 640 wide by 480 high image of a body scan.
-
body1.png, a PNG image.
-
body2.ascii.pgm,
a 640 wide by 480 high image of a body scan.
-
body2.png, a PNG image.
-
body3.ascii.pgm,
a 640 wide by 480 high image of a body scan.
-
body3.png, a PNG image.
-
brain_398.ascii.pgm,
a 720 wide by 486 high image of a visualization of the optical system.
-
brain_398.png, a PNG image.
-
brain_492.ascii.pgm
-
brain_492.png, a PNG image.
-
brain_508.ascii.pgm
-
brain_508.png, a PNG image.
-
brain_604.ascii.pgm,
a 720 wide by 486 high image of a visualization of the optical system.
-
brain_604.png, a PNG image.
-
casablanca.ascii.pgm,
a still from the movie "Casablanca";
-
casablanca.png,
a PNG version;
-
coins.ascii.pgm,
a 300 wide by 246 high image of 6 nickels and 4 dimes.
-
coins.png, a PNG image.
-
columns.ascii.pgm,
a 640 wide by 480 high image of a person standing by some columns;
-
columns.png, a PNG image.
-
dla.ascii.pgm,
an 800 by 800 image of a structure created by diffusion-limited aggregation.
-
dla.png,
a PNG version.
-
dragon.ascii.pgm,
a 475 wide by 460 high image of a cartoon dragon.
-
dragon.png, a PNG image.
-
f14.ascii.pgm,
a 640 wide by 480 high image of an F14 fighter jet.
-
f14.png, a PNG image.
-
feep.ascii.pgm,
a 24 wide by 7 high image that
displays "FEEP" in block letters.
-
feep.png, a PNG image.
-
foliage.ascii.pgm,
a 480 wide by 640 high image of foliage.
-
foliage.png, a PNG image.
-
fractal_tree.ascii.pgm,
a photograph of a tree suggesting a fractal structure.
-
fractal_tree.png,
a PNG version.
-
galaxy.ascii.pgm,
a 965 wide by 965 high image containing four pictures of
the same galaxy at different wavelengths.
-
galaxy.png, a PNG image.
-
gator.ascii.pgm,
a 633 wide by 621 high image of Junior the Alligator.
-
gator.png, a PNG image.
-
glassware_noisy.ascii.pgm,
a 320 wide by 428 high image of glassware, spotted with "salt and pepper" noise.
-
glassware_noisy.png, a PNG image.
-
hands.ascii.pgm,
a 640 wide by 480 high image of hands.
-
hands.png, a PNG image.
-
handsmat.ascii.pgm
-
handsmat.png, a PNG image.
-
lena.ascii.pgm
a 512 wide by 512 high image.
-
lena.png, a PNG image.
-
marcie.ascii.pgm
-
marcie.png, a PNG image.
-
mona_lisa.ascii.pgm,
a 250 wide by 360 high image of the Mona Lisa.
-
mona_lisa.png, a PNG image.
-
mother_daughter.ascii.pgm,
a snapshot of a mother and daughter;
-
mother_daughter.png,
a PNG version;
-
mountain.ascii.pgm,
a 640 wide by 480 high image of a mountain.
-
mountain.png, a PNG image.
-
pbmlib.ascii.pgm,
a 600x200 image created by PBMLIB.
-
pbmlib.png, a PNG image.
-
pepper.ascii.pgm,
a 256 wide by 256 high image of some peppers.
-
pepper.png, a PNG image.
-
roi_14.ascii.pgm,
a 507 wide by 505 high image an MRI, the 14th in a sequence.11
-
roi_14.png, a PNG image.
-
saturn.ascii.pgm
-
saturn.png, a PNG image.
-
screws.ascii.pgm
-
screws.png, a PNG image.
-
snap.ascii.pgm,
a 295 wide by 400 high snapshot of a mother and child.
-
snap.png, a PNG image.
-
surf.ascii.pgm,
a 640 wide by 480 high beach picture.
-
surf.png, a PNG image.
-
totem.ascii.pgm
a 640 wide by 480 high image of a totem pole.
-
totem.png, a PNG image.
-
tracks.ascii.pgm,
a 300 wide by 200 high image that looks like tracks.
-
tracks.png, a PNG image.
-
venus1.ascii.pgm,
a 640 wide by 480 high photo image from the surface of Venus.
-
venus1.png, a PNG image.
-
venus2.ascii.pgm
a 640 wide by 480 high photo image from the surface of Venus.
-
venus2.png, a PNG image.
-
x31_f18.ascii.pgm,
a 640 wide by 480 high image of X31 and F18 aircraft.
-
x31_f18.png, a PNG image.
You can go up one level to
the DATA page.
Last revised on 10 June 2011.


2048
Join the numbers and get to the 2048 tile!
SCORE
NEW GAME
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4x4 Grid
5x5 Grid
6x6 Grid
8x8 Grid


include "main.html" include "ecg_contents.html" include "ecg_vision.html" include "ecg_history.html" include "matrix_list.html" include "indicatorPagesTemplate-output.html" include "about.html"


|
Perhaps you considered goat suckling the province of fiction, coming across it in Chapter 8 of Finnegan's Wake, or Greek mythology in the opening passage from Longus' Daphnis and Chloe:
"He saw the ewe behaving just like a human being-offering her teats to the baby so that it could drink all the milk it wanted, while the baby, which was not even crying, greedily applied first to one teat and then to another a mouth shining with cleanliness, for the ewe was in the habit of licking its face with her tongue when it had had enough."
In more modern times, we have Elian Gonzales, the Cuban boy who was a pawn in the apparent "struggle" between good and evil. No, we are not suggesting he was suckled by goats.  This shocked Americans but did not surprise Cubans.
And similarly at first glance, the picture above seems shocking. But in turn-of-the-century rural Cuba, goat suckling was quite common. A plethora of souvenir postcards survive, depicting scenes similar to the above. They are testimony to the amusement Americans found visiting their newly-conquered island.
|


| AbstractEcolawModelTest (0%) |
| AbstractLSAModelTest (0%) |
| AbstractTestBooleanValue (0%) |
| AbstractTestDateTimeValue (0%) |
| AbstractTestDoubleValue (0%) |
| AbstractTestEcolawFactory (0%) |
| AbstractTestFloatValue (0%) |
| AbstractTestFormula (0%) |
| AbstractTestFormulaFactory (0%) |
| AbstractTestIntegerValue (0%) |
| AbstractTestLSA (0%) |
| AbstractTestLSAFactory (0%) |
| AbstractTestLSAParser (0%) |
| AbstractTestLSAid (0%) |
| AbstractTestLSAidValue (0%) |
| AbstractTestLSAspaceCore (0%) |
| AbstractTestLongValue (0%) |
| AbstractTestMatchingEcolawTemplate (0%) |
| AbstractTestPrivilegedLSAFactory (0%) |
| AbstractTestProperty (0%) |
| AbstractTestPropertyName (0%) |
| AbstractTestPropertyValue (0%) |
| AbstractTestSemanticDescription (0%) |
| AbstractTestURIValue (0%) |
| RDFSerializer (0%) |


Hi I'm Jacqueline! Welcome. I love watercolor illustration and graphic design. This space combines the two and allows me to share my creations with you. Every piece incorporates my own hand illustrations, crafted to fit the design of the final piece.
Utilizing my own graphic design I incorporate those illustrations into bespoke designs. We hope you find something you love, or follow me on Instagram or Pinterest to keep up with my latest creations!


Note: See the changes document. Window system implementation changed is major version. Comparing to the older version it has changed its laout significantly, introduced group, and released support of workspaces
org.openide.windows
package. Most module authors will want to look at
TopComponent
to subclass it, or perhaps at
CloneableTopComponent
.
java.awt.Window
),
since these would exist without the knowledge of NetBeans' window
manager. This window manager is capable of manipulating application
windows and panels, including docking and undocking them into
tabbed frames, and making the window configuration persistent across
sessions. Well-behaved modules will use the API so as to integrate
nicely into the feel of the rest of the application.
The API provides access to a set of modes, each of which can contain some top components. The API user cannot create modes directly. She can achieve that by specifying them in a XML layer.
Top components have some special trimming, they may have a popup menu of actions (e.g. Save, Close, ...) which can be displayed in the tab. Top components may provide special actions in this list as well.
At any given time, one top component is active. It will be the last docked top component containing focus, and of course will be in the selected tab. This component serves as the base for a number of things in NetBeans; for example, the current node selection is controlled by the active component.
NetBeans tries to save the current window configuration when it exits, including the positions of all modes, the arrangement of modes, and the components present in each mode; and grouos, their state; and then restore this configuration when next started.
TopComponent
TopComponent
.
This is a subclass of
JComponent
,
which means that it is possible to draw on it using a variety of
mechanisms; typically, it is treated as a container, and its layout
may be
set
and components
added
to it.
There are a few general ways in which you can customize the component besides painting subcomponents on it:
TopComponent.getHelpCtx()
should be overridden to provide a help link for the component as a
whole, if you have any context help. Or, subcomponents may have their
own more specific help. By default, context help is taken from the activated
node selection, if there is any to be found.
TopComponent.getUndoRedo()
allows you to associate undo/redo actions with the component, so
that these actions will work properly when your component is
focussed.
TopComponent.getActions()
permits you to provide a list of actions which will appear in a
popup menu, e.g. on a tab for the component. The system should
provide a few standard actions such as "Close"; you may want to add
more (for example, "Save" for an Editor pane). The
Actions API
describes how to write these.
You cannot create mode directly, however you can specify
new mode in XML layer. Then you can find such a mode by call
WindowManager.findMode(String)
. Do not keep references to modes, Rather use the above method to access them.
Modes could be removed from window system inbetween, thus manipulating with such
a mode wouldn't achieve desired goal.
To add top components to a mode, just call
Mode.dockInto(TopComponent)
.
For example:
public static class MyComponent extends TopComponent { public MyComponent(Object data, Image icon) { setName(NbBundle.getMessage(This.class, "LBL_widget_tree")); setIcon(icon); setLayout(new BorderLayout()); add(new JTree(createModel(data)), BorderLayout.CENTER); } public Action[] getActions() { List[] actions = Arrays.asList(super.getctions()); actions.add(new WidgetReparseAction()); return (Action[])actions.toArray(new Action[0]); } } // ... TopComponent myComponent1 = new MyComponent(firstData, firstIcon); TopComponent myComponent2 = new MyComponent(secondData, secondIcon); Mode myMode = WindowManager.getDefault().findMode("myWidgetsMode"); if (myMode != null) { myMode.dockInto(myComponent); myMode.dockInto(myComponent2); } else { // Mode was not found, i.e. it is not specified in XML layer, or some problem occured. // Then the TopComponent will be opened in default editor mode. } myComponent.open(); myComponent2.open(); myComponent2.requestActive();
CloneableTopComponent
,
you can create a component which is capable of cloning
itself, like the Editor does with the popup action "Clone View". If
Object.clone()
takes care of all of your instance state satisfactorily, then you
need do little more; otherwise, you can override
CloneableTopComponent.createClonedObject()
to specify exactly what fields should be shared with the original
top component. Typically all clones of a component should share any
underlying data object (e.g. edited files), but they may each have
different display parameters or other noncritical settings.
You may specify how these cloned windows act when they are
closed, by overriding
CloneableTopComponent.closeLast()
.
(There are more general methods for all top components pertaining
to closing them; this method is specific to cloneable top
components.) It will be called when the last clone of a component
is about to be closed. Components keeping some sort of user data,
such as the Editor, should offer to save it here, and also shut
down the editing system for that file. If you do not wish to close
the last clone (for example, Cancel was pressed on a save dialog),
just return false
.
Other methods allow you to keep track of when new clones are created, and to find the sister clones of a top component, if that is needed. As an example, you could provide a component action which would cause all visible clones to display a different part of the content of the data simultaneously, so the user could use the screen more effectively.
You can explicitly request that a top component be activated by calling
TopComponent.requestActive()
.
(It should be opened first.)
TopComponent.getRegistry()
and then
TopComponent.Registry.getActivated()
correspondingly finds the last-activated component.
Node
s
that it decides to treat as "active". The node selection will have
effects on other parts of the system - for example,
NodeAction
s
and
CookieAction
s
pay attention to it.
The selection may be set using
TopComponent.setActivatedNodes(...)
.
Explorer views embedded in as described at
ExplorerUtils
automatically make the node selection track user selections in the
view, as you would expect. Also, any top component associated with
a data object will automatically select that object's node
delegate, which is usually the intuitive behavior as well.
TopComponent
:
public class FlippableView extends TopComponent { public static int HORIZ_ORIENT = 1; public static int VERT_ORIENT = 2; private int orient = HORIZ_ORIENT; public int getOrientation() { /* ... */ } public void setOrientation(int ornt) { /* ... */ } public void writeExternal(ObjectOutput oo) throws IOException { super.writeExternal(oo); oo.writeInt(getOrientation()); } public void readExternal(ObjectInput oi) throws IOException, ClassNotFoundException { super.readExternal(oi); setOrientation(oi.readInt()); } }It is desirable to store as much of your component's configuration as possible (if you can do so safely, i.e. without triggering an exception typically during
readExternal
). For example, Editor windows will store
the open file and cursor position; Explorer windows, the current
node selection and expanded path; etc. If part of the configuration
you wish to store is some piece of serializable data that you are
not completely confident can be deserialized without error, please
instead store a
NbMarshalledObject
wrapping the data, which will protect the object streams from being
corrupted just because of one component. For example:
// Possible that you may break serialization of this class accidentally: private MySerObject state; // ... public void writeExternal(ObjectOutput oo) throws IOException { super.writeExternal(oo); Object toWrite; try { toWrite = new NbMarshalledObject(state); } catch (Exception e) { ErrorManager.getDefault().notify(ErrorManager.WARNING, e); toWrite = null; } oo.writeObject(toWrite); } public void readExternal(ObjectInput oi) throws IOException, ClassNotFoundException { super.readExternal(oi); NbMarshalledObject read =(NbMarshalledObject)oi.readObject(); if (read != null) { try { state = (MySerObject)read.get(); } catch (Exception e) { ErrorManager.getDefault().notify(ErrorManager.WARNING, e); } } }This example assumes that your component can survive a restart even without setting this piece of its state correctly (it can just use some default settings). If the component cannot be validly recreated without this information, still use an
NbMarshalledObject
, but do not throw the
original exception from it to the writeExternal
or
readExternal
callers - this will make the whole window
system stream be treated as corrupt and discarded! Instead, use:
try { // new NbMarshalledObject(obj) or nbmo.get() } catch (Exception e) { throw new SafeException(e); }This will cause your top component to not be stored or loaded, but other components in the system will be unaffected.
The default implementation of the read and write methods must
always be called. It stores the name and some internal information
pertaining to the Window System. You must save the icon yourself,
though most users will set the icon in the constructor. Remember
that a TopComponent
must have a default
constructor in order to be deserialized. In older versions of
NetBeans this needed to be public; this is no longer necessary.
Persistent singleton implementations (i.e. where only one instance of the class
should exist in NetBeans) are possible; just remember to assign the default
instance both in the default constructor, and also in the readResolve
method. To force deserialization of singleton instance by window system method
WindowManager.findTopComponent(String)
must be used. Pass unique TopComponent
ID (name of settings file) as parameter to this method. To be able to create
singleton instance 2 public static accessor methods must be provided: First eg.
getDefault
reserved for window system will be given as creation method
in settings file and also called from readResolve
. getDefault
creates singleton instance using constructor as usual in common singleton accessor.
Second eg. findDefault
will be used as normal accessor method to get correctly
deserialized singleton instance by window system. It can be used to access singleton
instance for example by view action. findDefault
will call
WindowManager.findTopComponent
. As WindowManager.findTopComponent
can return null
findDefault
should handle such case somehow
eg. by calling of getDefault
.
There is a
simple example module
where persistent singleton instance is defined in module layer as described here.
It is possible to use writeReplace
and readResolve
as well
for some advanced uses - but be very careful to resolve to a subclass of TopComponent
,
and to always invoke the default implementations of readExternal
and
writeExternal
.
It is recommended to explicitely set the persistence type of a
TopComponent subclass by overriding API method TopComponent.getPersistenceType
.
This method can return one of following constants:
TopComponent.PERSISTENCE_NEVER
TopComponent.PERSISTENCE_ONLY_OPENED
TopComponent.PERSISTENCE_ALWAYS
By default all top components are persisted but it is recommended not to rely on default but to set persistence type explicitely as described above.
WindowManager
instance is obtained by
WindowManager.getDefault()
.
WindowManager.getModes()
or
WindowManager.findMode(String)
(or also
WindowManager.findMode(TopComponent)
).
Mode.getTopComponents()
.
WindowManager.findTopComponentGroup(String)
TopComponent.getRegistry()
followed by
TopComponent.Registry.getActivated()
.
You can also get all opened components with
TopComponent.Registry.getOpened()
.
TopComponent.requestActive()
.
To close a top component programmatically, call
TopComponent.close()
.
WindowManager.addPropertyChangeListener(PropertyChangeListener)
.
TopComponent.Registry.addPropertyChangeListener(PropertyChangeListener)
.
Mode
nor in TopComponent
, though both
have modifiable properties which in principle there might be a need
to listen to.
The window system layout used by NetBeans is based on modes.
The was needed in two areas - modules and initial layout. What does this mean? Modules had limited possibilities to control layout of their modes. Also, the initial layout of system modes was hardcoded in core sources, which was not sufficient due to the nature of this information, which is likely to change frequently. Modifications of initial layout needed to be easier.
Main goals comes directly from the issues that were mentioned in motivation section:
Modules will have full control over layout of own modes, including frame MDI constraints.
Initial layout modifications should be as easy as possible, without changes in source code.
Core implementation currently specifies nearly all initial layout. However, right way to go is to let modules specify complete layout of their modes, such as inspector, palette, debugger etc.
Allow expert users to read, understand, modify, backup and make versions of stored window system content.
From above points, it's clear that description of modes layout should cover all features that window system offers (point 1.) and should be expressed in some human readable form (point 2, 4.). Mentioned requirements fits well into XML layers architecture, which is already supported by Netbeans' Open APIs.
Solution backbone reads like this:
Each module will have a possibility to define modes layout described in their module layer, expressed in XML document.
Core itself will define basic layout for explorer and editor modes (etc.), other modes will be specified directly by responsible modules.
Solution will use advantages of XML layers architecture, modes defined by individual modules and core will be merged into whole modes picture which will define overall content of window system.
WS implementation will read and understand XML mode layout format.
WS implementation will make its content persistent using XML layers support too.
Example of simple window system content expressed as merge of modes layouts from different modules is shown on picture below:
Note: The same applies for groups, but those are not dealing with laout, but rather opening and closing of component.
Above picture shows simple situation when modules (in this case form and debugger) define just their modes and nothing more. In reality, modules will want to influence other modes, especially modes created by core implementation.In first part of this chapter, overall structure of layout configuration is
discussed. XML layers architecture uses directory-like structure for storing
information. Directory structure itself is expressed in XML syntax, creating
picture of 'virtual filesystem' stored in XML file.
Further, exact format of folders and files which hold layout information is
specified, together with examples.
Physical storage of layout configuration documents is determined by layers support. Until modified, layout configuration files lives in modules that defined them. More exactly, they are read from files which are stored in module jar archives, together with other module classes.
However, modes layout configuration is likely to change frequently during
runtime of the system, so then modifications will be stored under (for example) the config
subdirectory of current userdir, as shows example directory tree below.
Described mechanism is fully driven by XML layers support provided by
Filesystems API and we needn't care about it more from the perspective of
window system. (The precise details of where customizations are stored
is dependent on the implementation; suffice it to say that the default file
system of the repository is responsible for holding the files and applying
any changes made.)
To effectively use XML layers, it's necessary to define directory structure for modes layout description. Following directory structure is fixed and in fact it represents part of API modules can deal with. It means that this structure will not change in incompatible manner and modules can rely on it. Again, the specification is of resource paths in the system filesystem rather than details of how this filesystem is composed and modified.
Window system is not part of individual projects as it was in previous releases.
Window system configuration is defined by modules in folder Windows2
and is stored
locally under $NBUSERDIR/config/Windows2Local
. It means that default initial configuration
defined by modules and customized configuration are separated to different folders.
See Structure of configuration data.
There exist direct mapping between instances of classes which are defined in traditional winsys API and folders and files shown above. Folders and files named "Mode_X" under Modes/ define modes (= component containers) belonging to window system, and map to instances of org.openide.windows.Mode (by which it is meant that the corresponding data objects have an appropriate instance cookie).
Naming of folders and files is important, because folder and file names are used as unique identifiers for modes and groups. Basically it means that winsys API methods Mode.getName() will return the same names as used for folders and files.
Folders for window manager, for each mode have to be
stored together with their properties, for example display name or icon URL.
This is done using "folder - file pair", as evident from example directory tree
above. Folders cannot hold their properties directly, that's why each folder
is accompanied by file on the same directory level, which has the same name as
folder and stores property information for its folder.
Note, window system will recognize only folder - file pairs with exactly same
names.
Components introduce a bit of complexity to the directory structure, because one top component can be a mode(=component containers) and also can by in some group. To handle that sharing correctly, modes and groups contains only references to components, Component's data are stored in separate folder named Windows2/Components/. Example of top component reference is file TC_1.wstcref or TC_1.wstcgrp shown above in directory tree. Top component data needs to be referenced through some unique identifiers, treated as unique IDs.
Directory structure of winsys configuration is fine-grained in the sense that each mode and group is represented by a folder, while each presence of top component is represented by special file. Such design will enhance module possibilities of configuring modes ang groups defined by other modules or by core implementation.
Detailed explanation: Imagine that debugger module wants to specify size, location, constraints of debugger window not only on its own debugger mode, but also on output mode. So debugger module specifies folder 'debugger', with proper 'debugger.wsmode' file content, under folder 'output'. Note that debugger module must not define 'execution.wsmode', because debugger module is not defining output mode, debugger is only completing output mode if present. As a result of layers merge done by system, 'debugger.wstcref' will appear as file under 'output'.
If there were no folders for frames, this operation would not be possible, because layering is done on folder and file level, not on file contents level.
Modules now can:Module builds its own modes and layout from the scratch by creating new folder and data file for mode. Module can put own components on such mode. Other modules can 'complete' such mode by their own components.
Module builds its own groups and layout from the scratch by creating new folder and data file for group. Module can put own components on such group. Other modules can 'complete' such group by their own components.
Module can install a component into mode that was defined by other
module or core implementation.
To achieve this, module is required to create folder named by foreign
mode, together with file '.wstcref' referencing its component.
Note that module which is using other module's mode may not
define '.wsmode' data file for such 'foreign' mode, because module
which define folder and '.wsmode' file for mode then owns that mode
and there cannot be multiple modules owning the same mode.
Module can install a component into group that was defined by other
module or core implementation.
To achieve this, module is required to create folder named by foreign
group, together with file '.wstcgrp' referencing its component.
Note that module which is using other module's group may not
define '.wsgrp' data file for such 'foreign' group, because module
which define folder and '.wsgrp' file for group then owns that group
and there cannot be multiple modules owning the same group.
As layers can overlap and hide information between each other, modules can also modify and/or hide winsys layout elements defined in other modules. However, module must depend on other module whose winsys layout it overrides, as is generally required when overriding layer-provided files.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE windowmanager PUBLIC "-//NetBeans//DTD Window Manager Properties 2.0//EN" "http://www.netbeans.org/dtds/windowmanager-properties2_0.dtd"> <windowmanager version="2.0"> <!-- size and location of the main window --> <main-window> <joined-properties centered-vertically="true" centered-horizontally="true" relative-width="0.8" relative-height="0.8"/> </main-window> <!-- size of the screen last displayed on --> <screen width="1024" height="768"/> <!-- reference to active mode --> <active-mode name="explorer"/> <!-- reference to maximized mode --> <maximized-mode name="explorer"/> <!-- reference to toolbar configuration --> <toolbar configuration="Standard"/> </windowmanager>Modules will typically never need to access these global properties, and modules should never try to change them.
Modules can either define own mode from scratch or reference mode defined by other modules.
Module defines mode by creating proper mode folder Windows2/Modes/MODE_UID/ and data file Windows2/Modes/MODE_UID.wsmode.
Here is example of valid mode data file:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mode PUBLIC "-//NetBeans//DTD Mode Properties 2.0//EN" "http://www.netbeans.org/dtds/mode-properties2_0.dtd"> <mode version="2.0"> <module name="org.netbeans.core.ui/1" spec="1.2" /> <name unique="explorer" /> <kind type="view" /> <state type="joined" /> <constraints> <path orientation="vertical" number="0" weight="0.7" /> <path orientation="horizontal" number="0" weight="0.25" /> </constraints> <active-tc id="filesystems" /> <empty-behavior permanent="true" /> </mode>
Module references mode defined by other module in order to place own components into such mode to complete its layout. Module specifies only mode folder Windows2/Modes/MODE_UID/ filled with own top component reference files. The mode data file should not be given.
Modules can either define own group from scratch or reference grouo defined by other modules.
Module defines group by creating proper group folder Windows2/Groups/GROUP_UID/ and data file Windows2/Groups/GROUP_UID.wsgrp.
Here is example of valid group data file:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE group PUBLIC "-//NetBeans//DTD Group Properties 2.0//EN" "http://www.netbeans.org/dtds/group-properties2_0.dtd"> <group version="2.0"> <module name="org.netbeans.modules.form/2" spec="1.7" /> <name unique="form" /> <state opened="false" /> </group>
Module references group defined by other module in order to place own components into such group to complete its layout. Module specifies only group folder Windows2/Groups/GROUP_UID/ filled with own top component reference files. The group data file should not be given.
For top component to appear in mode, reference file needs to be put into mode folder, for example file Windows2/Modes/MODE_UID/COMP_UID.wstcref. Keep in mind that component reference file is only a part of the story, to specify complete link to top component through COMP_UID, you have to provide file COMP_UID.settings or COMP_UID.ser and place it into Windows2/Components/ folder.
Example top component reference file content:
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE tc-ref PUBLIC "-//NetBeans//DTD Top Component in Mode Properties 2.0//EN" "http://www.netbeans.org/dtds/tc-ref2_0.dtd"> <tc-ref version="2.0"> <module name="org.netbeans.core.ui/1" spec="1.2" /> <tc-id id="filesystems" /> <state opened="true" /> </tc-ref>
For top component to appear in group, reference file needs to be put into group folder, for example file Windows2/Groups/GROUP_UID/COMP_UID.wstcgrp. Keep in mind that component reference file is only a part of the story, to specify complete link to top component through COMP_UID, you have to provide file COMP_UID.settings or COMP_UID.ser and place it into Windows2/Components/ folder.
Example top component reference in group file content:
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE tc-group PUBLIC "-//NetBeans//DTD Top Component in Group Properties 2.0//EN" "http://www.netbeans.org/dtds/tc-group2_0.dtd"> <tc-group version="2.0"> <module name="org.netbeans.modules.form/2" spec="1.7" /> <tc-id id="ComponentInspector" /> <open-close-behavior open="true" close="true" /> </tc-group>
Stored in folder Windows2/Components/ as *.settings or *.ser files, which holds data of top component. Top components are instantiated using information stored in these files. If top component is created dynamically in the code, system will automatically create a new file containing proper information during save operation.
Names of files in Windows2/Components/ (without extensions) are used to link top components and their references in modes and groups.
In the future other or even arbitrary file extensions and types may be supported
for storing top component information, provided that the result of
DataObject.getName()
matches the ID. Also currently all
settings for newly created components will be stored in *.settings files.
Top component can be divided from instantiation perspective to following types:
For static components, specifying their data file and link it with component reference in mode is well enough to describe all life of such component. However, for dynamic top components, situation is more complicated.
The window system API does not define any particular mode names; it only defines the structure given names. So the only files whose names are defined here are:
Modules that define modes, groups or component references can "mark" these items so that the system can perform automatic removal of these items when the module is uninstalled.
All three types of window system XML files may have module
information defined in the same way, using the optional
<module/>
element, which has two attributes
name
and spec
.
Normally a module will define just the name
attribute,
with its code name base (for example, org.domain.module).
The windowing elements will be removed if the module thus named is
uninstalled (or removed). name
may also be a full code
name (for example, org.domain.module/1) and
spec
may be given with the specification version (for
example, 1.0) in which case the windowing element will
also be removed if the module is present and enabled, but in an older
version than was specified - though this feature is unlikely to be
used commonly.
The window system may at its discretion just ignore XML files corresponding to missing modules; or it may actually delete them. In either case, removal of windowing components applies also to subcomponents: so for example a missing mode (or group) implies that any contained modes (or group) are not available either, even if they otherwise would have been.
Following chapter summarizes procedures that module can do in order to use features of XML mode layout. Each procedure is detailed into steps which module writers are required or supposed to do.
Specify module layer
To use module layer properly, specify reference to module layer in
module's manifest file using OpenIDE-Module-Layer entry, with
relative patch to the xml file describing module's xml layer.
In other words, add to the manifest line like this:
OpenIDE-Module-Layer: org/your_company/your_module/resources/YourModuleLayer.xml
Describe mode
Example of adding new mode, with id "my_own_mode", without any
components contained in mode yet:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE filesystem PUBLIC "-//NetBeans//DTD Filesystem 1.0//EN" "http://www.netbeans.org/dtds/filesystem-1_0.dtd"> <filesystem> <folder name="Windows2"> <folder name="Modes"> <!-- configuration file is stored separately --> <file name="my_own_mode.wsmode" url="my_own_mode.wsmode"/> <folder name="my_own_mode"/> </folder> </folder> </filesystem>
What example shows? Creates folder Windows2/Modes/my_own_mode and inserts description of its properties into file Windows2/Modes/my_own_mode.wsmode, which has format defined in its DTD (see above). Folder name must be unique, fixed name for mode identification.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE filesystem PUBLIC "-//NetBeans//DTD Filesystem 1.0//EN" "http://www.netbeans.org/dtds/filesystem-1_0.dtd"> <filesystem> <folder name="Windows2"> <folder name="Modes"> <!-- foreign mode, don't specify data file --> <folder name="bathroom"> <!-- configuration file stored separately --> <file name="shower.wstcref" url="shower.wstcref"> </folder> </folder> </folder> </filesystem>There are several other notes that developer should be aware of:
So let's say we have following example situation:
Solution:
Module A needs no changes, module B has to assure following:
Similar procedures can be applied when module needs to override only one top component reference entry or hide whole workspace.


app
/
cz.palda97.lpclient.model.repository
/
ConnectionDialogRepository
/
currentBinding
currentBinding
lateinit
var
currentBinding
:
Binding
Binding
that has been clicked on by user to add connection to.


Throw
Class representing a single Throw
Static Method Summary
| Static Public Methods | ||
| public static |
Factory function. |
|
| public static |
fromString(str: string): Throw Factory function. |
Constructor Summary
| Public Constructor | ||
| public |
constructor(num: number, multiplier: number) Initializes a new instance of the |
Member Summary
| Public Members | ||
| public get |
|
|
| public get |
|
|
| public get |
|
|
| public get |
multiplier: Number: * |
|
| public set |
multiplier(multiplier: Number): * Sets |
|
| public get |
Returns one of the followings: 'S' (single) or 'D' (double) or 'T' (triple) |
|
| public get |
|
|
| public set |
Sets |
Static Public Methods
public static fromString(str: string): Throw source
Factory function.
Params:
| Name | Type | Attribute | Description |
| str | string | String representing the throw |
Example:
let throwInstance1 = Throw.fromString('T20'); // triple 20
let throwInstance2 = Throw.fromString('S15'); // single 15
let throwInstance3 = Throw.fromString('DB'); // double Bull


CASE in Tools Hackathon Winner
Co-located with the Tools 50+1 conference, the CASE in Tools hackathon is open to companies, students, researchers and engineers to experiment together with all kinds of tools for Software Engineering (SE).
Arduino Certificate
A four week Arduino Certification Training Course : Programming the Internet of Things, from beginner basics to advanced techniques.
HACK WEAK-END 2018 Participant
HackWeakEnd Technology Event 2018 was held from Friday 27th April to Saturday 28th April 2018. It featured a Hackathon where participants creatively solved issues affecting the fishing sector in the Gambia and a software development training using Python programming language.
National Robotics Competition Finalist
The National Robotics Competition finals was held on Saturday 10th February 2018 at Medical Research Council Unit The Gambia at London School of Hygiene & Tropical Medicine Fajara main site. Five schools, Marina International, Gambia High School, Methodist Academy, SBEC International and SOS High School competed in the finals.


Welcome to AFC Web. Page is loading.
Published under the The Artistic License 2.0, copyright Aaron Filson 2019. Use of the website constitutes acceptance of the License. Full text is linked here. For comments, suggestions, and other good stuff, visit the code repository at GitHub: afcweb.


Are you ready to confront the power behind The Ring?
The Lord of the Rings: The Return of the King is a 2003 epic high fantasy adventure film directed by Peter Jackson based on the second and third volumes of J. R. R. Tolkien's The Lord of the Rings. It is the third and final installment in The Lord of the Rings trilogy, following The Fellowship of the Ring (2001) and The Two Towers (2002), preceding The Hobbit trilogy (2012–14).


{% extends "layout.html"%} {% block body%}
This is the platform where you can manage your laundry in the best possible way!
The end-to-end mechanism is a design in where end customers and we owners communicate, rather than a middle person
The user-interface is kept clear and user-friendly also helps user reach within not more than 2 clicks
To facilitate the purchase process, we provide shopping recommendation system for the consumers
You get to do easy payment and the transactions are made secured by the validation process
The website theme looks awesome at any size, be it a Laptop screen, Mobile or Tablet.
You can pay even without logging into your account, also flexible payment methods are provided
Our web app provide easy understanding using more of the images provided
We provide the Website as a add free website so that user can use it more efficiently
Our products is the best way to show our work, you can see here a big range of our work. Check them all and you will find what you are looking for.
A team that takes the work of laundrying and provides the best home-delievry and pickup facility.
:D
Art is everywhere its just the perspective of seeing the world around you
Just make the person inside you to be the one with most willingness
Just make the person inside you to be the one with most willingness
If you have some Questions or need Help! Please Contact Us!
We accept each and every variety of cloth materials.
WALCHAND INSTITUTE OF TECHNOLOGY, SOLAPUR
+101<PHONE_NUMBER>5
<EMAIL_ADDRESS>Weekdays:9am to 8pm
Saturday:9am to 2pm
Sunday:Closed


An object to store information about local settings and preferences.
When initialized, the hSettings object does the following:
Note
Maybe it would be better to save this file in User/Library/Preferences?
A dictionary containing general information about the local installation.
Currently, hDict contains only a few entries for FTP settings, and an additional custom test folder for .otfs.
>>> from hTools2.objects import hSettings
>>> s = hSettings()
>>> print s.hDict.keys()
['test', 'ftp']
>>> for k in s.hDict['ftp'].keys():
>>> print k, s.hDict['ftp'][k]
url myserver.com
folder www/mysite/assets/fonts
password abcd1234
login username
The full path to the settings file.
>>> from hTools2.objects import hSettings
>>> s = hSettings()
>>> print s.path
/fonts/hSettings.plist
The path to the local root folder for project files, imported from hTools2.ROOT. This is the only hardcoded path in hTools2.
>>> from hTools2.objects import hSettings
>>> s = hSettings()
>>> print s.root
/fonts
The name of the settings file. By default, hSettings.plist.
>>> from hTools2.objects import hSettings
>>> s = hSettings()
>>> print s.filename
hSettings.plist
Read settings from .plist file into hSettings.hDict.
Write contents of hSettings.hDict to its .plist file.


ROOM BOOKING WEBSITE
YOUR BEST BOOKING WEBSITE
Edit/Add Note
Contains here the note to be edited/added.....


=== Test case: lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 (click for source code)
=== Config value:
[{watchdog,infinity},
<EMAIL_ADDRESS>{tc_group_properties,[]},
{tc_group_path,[]},
{data_dir,"/Users/anne-francevanswieten/lasp/_build/test/lib/lasp/test/lasp_advertisement_counter_partition_overcounting_SUITE_data/"},
<EMAIL_ADDRESS>=== Current directory is<EMAIL_ADDRESS>=== Started at 2017-04-18 16:08:31
*** User 2017-04-18 16:08:31.952 ***
Beginning test case client_server_partition_overcounting_test
*** User 2017-04-18 16:08:31.965 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:08:31.965 ***
Launching Erlang distribution...
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.028 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
application: sasl
started_at: runner@MBPdeAnneFrance
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.038 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
application: syntax_tools
started_at: runner@MBPdeAnneFrance
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.051 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
application: compiler
started_at: runner@MBPdeAnneFrance
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.061 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
supervisor: {local,gr_sup}
started: [{pid,<0.476.0>},
{id,gr_counter_sup},
{mfargs,{gr_counter_sup,start_link,[]}},
{restart_type,permanent},
{shutdown,5000},
{child_type,supervisor}]
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.065 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
supervisor: {local,gr_sup}
started: [{pid,<0.478.0>},
{id,gr_param_sup},
{mfargs,{gr_param_sup,start_link,[]}},
{restart_type,permanent},
{shutdown,5000},
{child_type,supervisor}]
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.069 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
supervisor: {local,gr_sup}
started: [{pid,<0.480.0>},
{id,gr_manager_sup},
{mfargs,{gr_manager_sup,start_link,[]}},
{restart_type,permanent},
{shutdown,5000},
{child_type,supervisor}]
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.070 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
application: goldrush
started_at: runner@MBPdeAnneFrance
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.082 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
supervisor: {local,lager_sup}
started: [{pid,<0.487.0>},
{id,lager},
{mfargs,{gen_event,start_link,[{local,lager_event}]}},
{restart_type,permanent},
{shutdown,5000},
{child_type,worker}]
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.084 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
supervisor: {local,lager_sup}
started: [{pid,<0.489.0>},
{id,lager_handler_watcher_sup},
{mfargs,{lager_handler_watcher_sup,start_link,[]}},
{restart_type,permanent},
{shutdown,5000},
{child_type,supervisor}]
*** System report during lasp_advertisement_counter_partition_overcounting_SUITE:client_server_partition_overcounting_test/1 2017-04-18 16:08:32.087 ***
=PROGRESS REPORT==== 18-Apr-2017::16:08:32 ===
supervisor: {local,lager_sup}
started: [{pid,<0.491.0>},
{id,lager_crash_log},
{mfargs,
{lager_crash_log,start_link,
["log/crash.log",65536,10485760,[{hour,0}],5]}},
{restart_type,permanent},
{shutdown,5000},
{child_type,worker}]
*** User 2017-04-18 16:08:32.169 ***
Starting node: server
*** User 2017-04-18 16:08:32.171 ***
16:08:32.168 [info] Application lager started on node runner@MBPdeAnneFrance
*** User 2017-04-18 16:08:33.282 ***
Starting node: client_1
*** User 2017-04-18 16:08:34.355 ***
Starting node: client_2
*** User 2017-04-18 16:08:35.423 ***
Starting node: client_3
*** User 2017-04-18 16:08:36.519 ***
Starting node: client_4
*** User 2017-04-18 16:08:37.594 ***
Loading lasp on node: server@MBPdeAnneFrance
*** User 2017-04-18 16:08:37.628 ***
Loading lasp on node: client_1@MBPdeAnneFrance
*** User 2017-04-18 16:08:37.662 ***
Loading lasp on node: client_2@MBPdeAnneFrance
*** User 2017-04-18 16:08:37.698 ***
Loading lasp on node: client_3@MBPdeAnneFrance
*** User 2017-04-18 16:08:37.732 ***
Loading lasp on node: client_4@MBPdeAnneFrance
*** User 2017-04-18 16:08:39.032 ***
Starting lasp.
*** User 2017-04-18 16:08:40.532 ***
Custering nodes...
*** User 2017-04-18 16:08:40.533 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55080
*** User 2017-04-18 16:08:40.536 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55082
*** User 2017-04-18 16:08:40.537 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55084
*** User 2017-04-18 16:08:40.541 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55086
*** User 2017-04-18 16:08:40.542 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55078
*** User 2017-04-18 16:08:40.546 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55082
*** User 2017-04-18 16:08:40.548 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55084
*** User 2017-04-18 16:08:40.549 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55086
*** User 2017-04-18 16:08:40.550 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55078
*** User 2017-04-18 16:08:40.555 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55080
*** User 2017-04-18 16:08:40.556 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55084
*** User 2017-04-18 16:08:40.557 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55086
*** User 2017-04-18 16:08:40.559 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55078
*** User 2017-04-18 16:08:40.563 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55080
*** User 2017-04-18 16:08:40.565 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55082
*** User 2017-04-18 16:08:40.566 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55086
*** User 2017-04-18 16:08:40.568 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55078
*** User 2017-04-18 16:08:40.572 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55080
*** User 2017-04-18 16:08:40.573 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55082
*** User 2017-04-18 16:08:40.575 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55084
*** User 2017-04-18 16:08:40.577 ***
Lasp fully initialized.
*** User 2017-04-18 16:08:40.577 ***
Waiting for simulation to end
*** User 2017-04-18 16:10:30.589 ***
Simulation ended with success
*** User 2017-04-18 16:10:40.694 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:10:40.694 ***
Launching Erlang distribution...

*** User 2017-04-18 16:10:48.805 ***
Custering nodes...
*** User 2017-04-18 16:10:48.806 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55245
*** User 2017-04-18 16:10:48.809 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55247
*** User 2017-04-18 16:10:48.810 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55249
*** User 2017-04-18 16:10:48.811 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55251
*** User 2017-04-18 16:10:48.812 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55243
*** User 2017-04-18 16:10:48.815 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55247
*** User 2017-04-18 16:10:48.816 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55249
*** User 2017-04-18 16:10:48.817 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55251
*** User 2017-04-18 16:10:48.818 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55243
*** User 2017-04-18 16:10:48.821 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55245
*** User 2017-04-18 16:10:48.822 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55249
*** User 2017-04-18 16:10:48.823 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55251
*** User 2017-04-18 16:10:48.825 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55243
*** User 2017-04-18 16:10:48.828 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55245
*** User 2017-04-18 16:10:48.829 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55247
*** User 2017-04-18 16:10:48.830 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55251
*** User 2017-04-18 16:10:48.830 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55243
*** User 2017-04-18 16:10:48.834 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55245
*** User 2017-04-18 16:10:48.835 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55247
*** User 2017-04-18 16:10:48.836 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55249
*** User 2017-04-18 16:10:48.837 ***
Lasp fully initialized.
*** User 2017-04-18 16:10:48.837 ***
Waiting for simulation to end
*** User 2017-04-18 16:12:48.853 ***
Simulation ended with success
*** User 2017-04-18 16:12:58.956 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:12:58.956 ***
Launching Erlang distribution...

*** User 2017-04-18 16:13:07.266 ***
Custering nodes...
*** User 2017-04-18 16:13:07.266 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55374
*** User 2017-04-18 16:13:07.270 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55376
*** User 2017-04-18 16:13:07.271 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55378
*** User 2017-04-18 16:13:07.272 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55380
*** User 2017-04-18 16:13:07.274 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55372
*** User 2017-04-18 16:13:07.278 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55376
*** User 2017-04-18 16:13:07.279 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55378
*** User 2017-04-18 16:13:07.280 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55380
*** User 2017-04-18 16:13:07.281 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55372
*** User 2017-04-18 16:13:07.284 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55374
*** User 2017-04-18 16:13:07.285 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55378
*** User 2017-04-18 16:13:07.286 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55380
*** User 2017-04-18 16:13:07.287 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55372
*** User 2017-04-18 16:13:07.290 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55374
*** User 2017-04-18 16:13:07.291 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55376
*** User 2017-04-18 16:13:07.292 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55380
*** User 2017-04-18 16:13:07.293 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55372
*** User 2017-04-18 16:13:07.296 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55374
*** User 2017-04-18 16:13:07.298 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55376
*** User 2017-04-18 16:13:07.299 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55378
*** User 2017-04-18 16:13:07.299 ***
Lasp fully initialized.
*** User 2017-04-18 16:13:07.300 ***
Waiting for simulation to end
*** User 2017-04-18 16:15:17.313 ***
Simulation ended with success
*** User 2017-04-18 16:15:27.408 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:15:27.408 ***
Launching Erlang distribution...

*** User 2017-04-18 16:15:35.324 ***
Custering nodes...
*** User 2017-04-18 16:15:35.325 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55491
*** User 2017-04-18 16:15:35.328 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55493
*** User 2017-04-18 16:15:35.329 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55495
*** User 2017-04-18 16:15:35.330 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55497
*** User 2017-04-18 16:15:35.333 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55489
*** User 2017-04-18 16:15:35.336 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55493
*** User 2017-04-18 16:15:35.337 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55495
*** User 2017-04-18 16:15:35.339 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55497
*** User 2017-04-18 16:15:35.340 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55489
*** User 2017-04-18 16:15:35.343 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55491
*** User 2017-04-18 16:15:35.344 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55495
*** User 2017-04-18 16:15:35.345 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55497
*** User 2017-04-18 16:15:35.345 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55489
*** User 2017-04-18 16:15:35.348 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55491
*** User 2017-04-18 16:15:35.349 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55493
*** User 2017-04-18 16:15:35.350 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55497
*** User 2017-04-18 16:15:35.351 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55489
*** User 2017-04-18 16:15:35.354 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55491
*** User 2017-04-18 16:15:35.355 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55493
*** User 2017-04-18 16:15:35.356 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55495
*** User 2017-04-18 16:15:35.357 ***
Lasp fully initialized.
*** User 2017-04-18 16:15:35.357 ***
Waiting for simulation to end
*** User 2017-04-18 16:17:45.370 ***
Simulation ended with success
*** User 2017-04-18 16:17:55.528 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:17:55.528 ***
Launching Erlang distribution...

*** User 2017-04-18 16:18:03.365 ***
Custering nodes...
*** User 2017-04-18 16:18:03.365 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55650
*** User 2017-04-18 16:18:03.368 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55652
*** User 2017-04-18 16:18:03.369 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55654
*** User 2017-04-18 16:18:03.372 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55656
*** User 2017-04-18 16:18:03.373 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55648
*** User 2017-04-18 16:18:03.376 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55652
*** User 2017-04-18 16:18:03.377 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55654
*** User 2017-04-18 16:18:03.378 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55656
*** User 2017-04-18 16:18:03.379 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55648
*** User 2017-04-18 16:18:03.382 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55650
*** User 2017-04-18 16:18:03.383 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55654
*** User 2017-04-18 16:18:03.384 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55656
*** User 2017-04-18 16:18:03.385 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55648
*** User 2017-04-18 16:18:03.388 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55650
*** User 2017-04-18 16:18:03.389 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55652
*** User 2017-04-18 16:18:03.390 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55656
*** User 2017-04-18 16:18:03.391 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55648
*** User 2017-04-18 16:18:03.394 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55650
*** User 2017-04-18 16:18:03.395 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55652
*** User 2017-04-18 16:18:03.396 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55654
*** User 2017-04-18 16:18:03.397 ***
Lasp fully initialized.
*** User 2017-04-18 16:18:03.397 ***
Waiting for simulation to end
*** User 2017-04-18 16:20:23.414 ***
Simulation ended with success
*** User 2017-04-18 16:20:33.511 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:20:33.511 ***
Launching Erlang distribution...

*** User 2017-04-18 16:20:41.314 ***
Custering nodes...
*** User 2017-04-18 16:20:41.314 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55766
*** User 2017-04-18 16:20:41.317 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55768
*** User 2017-04-18 16:20:41.318 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55770
*** User 2017-04-18 16:20:41.319 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55772
*** User 2017-04-18 16:20:41.321 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55764
*** User 2017-04-18 16:20:41.325 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55768
*** User 2017-04-18 16:20:41.326 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55770
*** User 2017-04-18 16:20:41.327 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55772
*** User 2017-04-18 16:20:41.328 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55764
*** User 2017-04-18 16:20:41.330 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55766
*** User 2017-04-18 16:20:41.331 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55770
*** User 2017-04-18 16:20:41.332 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55772
*** User 2017-04-18 16:20:41.333 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55764
*** User 2017-04-18 16:20:41.336 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55766
*** User 2017-04-18 16:20:41.338 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55768
*** User 2017-04-18 16:20:41.339 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55772
*** User 2017-04-18 16:20:41.339 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55764
*** User 2017-04-18 16:20:41.342 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55766
*** User 2017-04-18 16:20:41.344 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55768
*** User 2017-04-18 16:20:41.344 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55770
*** User 2017-04-18 16:20:41.345 ***
Lasp fully initialized.
*** User 2017-04-18 16:20:41.345 ***
Waiting for simulation to end
*** User 2017-04-18 16:24:01.370 ***
Simulation ended with success
*** User 2017-04-18 16:24:11.499 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:24:11.499 ***
Launching Erlang distribution...

*** User 2017-04-18 16:24:19.674 ***
Custering nodes...
*** User 2017-04-18 16:24:19.674 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55956
*** User 2017-04-18 16:24:19.677 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55958
*** User 2017-04-18 16:24:19.678 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55960
*** User 2017-04-18 16:24:19.681 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55962
*** User 2017-04-18 16:24:19.682 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55954
*** User 2017-04-18 16:24:19.686 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55958
*** User 2017-04-18 16:24:19.687 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55960
*** User 2017-04-18 16:24:19.688 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55962
*** User 2017-04-18 16:24:19.689 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55954
*** User 2017-04-18 16:24:19.692 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55956
*** User 2017-04-18 16:24:19.693 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55960
*** User 2017-04-18 16:24:19.694 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55962
*** User 2017-04-18 16:24:19.695 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55954
*** User 2017-04-18 16:24:19.698 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55956
*** User 2017-04-18 16:24:19.699 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55958
*** User 2017-04-18 16:24:19.700 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 55962
*** User 2017-04-18 16:24:19.701 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 55954
*** User 2017-04-18 16:24:19.704 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 55956
*** User 2017-04-18 16:24:19.705 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 55958
*** User 2017-04-18 16:24:19.706 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 55960
*** User 2017-04-18 16:24:19.707 ***
Lasp fully initialized.
*** User 2017-04-18 16:24:19.707 ***
Waiting for simulation to end
*** User 2017-04-18 16:27:09.725 ***
Simulation ended with success
*** User 2017-04-18 16:27:19.828 ***
Running client_server_partition_overcounting_test with nodes [server,client_1,
client_2,
client_3,
client_4]
*** User 2017-04-18 16:27:19.828 ***
Launching Erlang distribution...

*** User 2017-04-18 16:27:27.836 ***
Custering nodes...
*** User 2017-04-18 16:27:27.837 ***
Joining node: server@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 56225
*** User 2017-04-18 16:27:27.840 ***
Joining node: server@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 56227
*** User 2017-04-18 16:27:27.840 ***
Joining node: server@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 56229
*** User 2017-04-18 16:27:27.841 ***
Joining node: server@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 56231
*** User 2017-04-18 16:27:27.845 ***
Joining node: client_1@MBPdeAnneFrance to server@MBPdeAnneFrance at port 56223
*** User 2017-04-18 16:27:27.848 ***
Joining node: client_1@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 56227
*** User 2017-04-18 16:27:27.849 ***
Joining node: client_1@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 56229
*** User 2017-04-18 16:27:27.850 ***
Joining node: client_1@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 56231
*** User 2017-04-18 16:27:27.851 ***
Joining node: client_2@MBPdeAnneFrance to server@MBPdeAnneFrance at port 56223
*** User 2017-04-18 16:27:27.854 ***
Joining node: client_2@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 56225
*** User 2017-04-18 16:27:27.855 ***
Joining node: client_2@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 56229
*** User 2017-04-18 16:27:27.856 ***
Joining node: client_2@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 56231
*** User 2017-04-18 16:27:27.857 ***
Joining node: client_3@MBPdeAnneFrance to server@MBPdeAnneFrance at port 56223
*** User 2017-04-18 16:27:27.860 ***
Joining node: client_3@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 56225
*** User 2017-04-18 16:27:27.861 ***
Joining node: client_3@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 56227
*** User 2017-04-18 16:27:27.862 ***
Joining node: client_3@MBPdeAnneFrance to client_4@MBPdeAnneFrance at port 56231
*** User 2017-04-18 16:27:27.864 ***
Joining node: client_4@MBPdeAnneFrance to server@MBPdeAnneFrance at port 56223
*** User 2017-04-18 16:27:27.866 ***
Joining node: client_4@MBPdeAnneFrance to client_1@MBPdeAnneFrance at port 56225
*** User 2017-04-18 16:27:27.867 ***
Joining node: client_4@MBPdeAnneFrance to client_2@MBPdeAnneFrance at port 56227
*** User 2017-04-18 16:27:27.868 ***
Joining node: client_4@MBPdeAnneFrance to client_3@MBPdeAnneFrance at port 56229
*** User 2017-04-18 16:27:27.869 ***
Lasp fully initialized.
*** User 2017-04-18 16:27:27.869 ***
Waiting for simulation to end
*** User 2017-04-18 16:29:57.887 ***
Simulation ended with success
*** User 2017-04-18 16:30:07.977 ***
Ending test case client_server_partition_overcounting_test
=== Ended at 2017-04-18 16:30:07
=== successfully completed test case
=== Returned value: ok
Test run history
| Top level test index


The development of exosomes pre-dates the divergence of eukaryotes and archaea. Exosomes appear to have developed from bacterial proteins responsible for RNA degradation, as their overall structures display striking similarities, and the proteins involved carry homologous domains.
PNPases (polynucleotide phosphorylases) are exoribonucleases that act as degradosomes, and are responsible for the 3’-5’ degradation of unstructured RNA in bacteria, mitochondria and chloroplasts. Bacterial PNPases contain three copies of a polypeptide that has two RNase-like PH domains, a KH domain and an S1 domain arranged in a single polypeptide. The homotrimer forms a ring of six RNase PH domains, with three S1 and KH domains arranged on one side of the ring. The PNPase PH (phosphorolytic) domain acts as the exoribonuclease to cleave nucleotides from the RNA substrates, while the KH and S1 are protein-nucleic acid recognition motifs. The KH domain (K homology) possesses a nucleic acid-recognising helix-turn-helix motif, and was originally identified in hnRNP-K, from which it takes its name. The S1 domain belongs to the olilgonucleotide/oligosaccharide-binding (OB) fold proteins, and was originally identified in ribosomal protein S1.
Exosomes display remarkable similarity in structure to PNPases. Archaeal exosomes have a simpler subunit composition than eukaryotic exosomes, but structurally they are very similar. Archaeal exosomes have four subunits: Rrp41, Rrp42, Rrp4 and Csl4. The Rrp41 and Rrp42 subunits contain the RNase PH domains, and are organised as a hexameric PH-ring consisting of a trimer of Rrp41/Rrp42 pairs that form a central degradation chamber, similar to that of PNPases. There are three exonuclease active sites within the Rrp41 subunit, which face inside the degradation chamber opposite the cap; Rrp42 is inactive, but contributes to the positioning of the Rrp41 active sites. The cap sits on one end of the hexameric PH-ring, and consists of a homotrimer of Rrp4 or Csl4 subunits, which contain S1, KH and zinc-ribbon domains used to bind the RNA substrate and feed it into the degradation chamber formed by the hexameric PH-ring.
Eukaryotic exosomes diverged from archaeal ones by increasing in complexity, but the core structure of a hexameric PH-ring with a cap of RNA-binding domains remains the same. Eukaryotic exosomes have 9-11 different subunits. The hexameric PH-ring forming the degradation chamber is usually composed of six different subunits, alternating Rrp41-like subunits (Rrp41, Rrp46 and Mtr3) with Rrp42-like subunits (Rrp42, Rrp43 and Rrp45). These subunits make specific pairs: Rrp41/45, Rrp46/43 and Mtr3/Rrp42. Some of these subunits appear to have lost enzymatic activity (in humans, only the Rrp41/45 dimer displays activity), and may play more of a regulatory role within the degradation chamber. The cap is formed by S1/KH domain-containing proteins (Csl4, Rrp4 and Rrp40).
In addition, eukaryotic exosomes often have ancillary proteins, such as Rrp6 or Rrp44. Rrp6 is a hydrolytic exonuclease (homologous to E. coli RNase-D) that is associated with nuclear exosomes. Rrp44 is another hydrolytic exonuclease (homologous to E. coli RNase-R and RNase-II) found in yeast exosomes. Both Rrp6 and Rrp44 interact with the bottom of the hexameric PH-ring opposite the cap.
The number of active sites can vary between species. Human exosomes appear to have only one active site/complex. Yeast have one active site/complex within the hexameric PH-ring, and another provided by Rrp44.
Eukaryotes possess both nuclear and cytoplasmic exosomes, which share the same core subunit composition. Nuclear exosomes process rRNA, snRNA and snoRNA, as well as unspliced pre-mRNAs, such as nonsense transcripts. Cytoplasmic exosomes are involved in the 3’-5’ pathway of mRNA degradation. Eukaryotes also have a separate 5’-3’ degradative pathway carried out by Xrn1 exonuclease within P bodies.