A CLI based eclectic set of geochemical data manipulation, QC and plotting tools.

Pygeochemtools is a python library and command line interface tool to enable rapid manipulation, filtering, QC and plotting
of geochemical data. It is primarily designed to allow people with limited or no coding experience to deal with
very large datasets when programs like Excel will struggle. It is designed to natively load and manipulate the geochemical datasets output by the Geological Survey of South Australia, but will easily handle other datasets with a little bit of configuration in later updates.

For more information checkout the pygeochemtools documentation.

Currently pygeochemtools provides the following functionality:

• Filter large datasets based on a list of elements, sample type or drillhole numbers (or a combination of all three) and convert from long to wide format.
• Add detailed geochemical methods columns onto the SARIG geochemical dataset.
• Extract single element datasets from large geochemical datasets.
• Plot maximum down hole geochemical data maps.
• Plot maximum down hole chemistry per interval geochemical data maps.

The project’s documentation contains a section to help you
get started as a user or
developer of the library.

If you’re going to be working in the code (rather than just using the library), you’ll want a few utilities.

• GNU Make
• Pandoc

Below are some handy resource links.

• Project Documentation
• Click is a Python package for creating beautiful command line interfaces in a composable way with as little code as necessary.
• Sphinx is a tool that makes it easy to create intelligent and beautiful documentation, written by Geog Brandl and licnsed under the BSD license.
• pytest helps you write better programs.
• GNU Make is a tool which controls the generation of executables and other non-source files of a program from the program’s source files.

• Rian Dutch – Initial work – github

See also the list of contributors who participated in this project.

Copyright (c) Rian Dutch

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Setup • Implementing Methods • Implementing Fields • Tips • TODO • Credits • License

FalsoJNI (falso as in fake from Italian) is a simple, zero-dependency fake JVM/JNI interface written in C.

It is created mainly to make JNI-heavy Android→PSVita ports easier, but probably could be used for other purposes as well.

Since there are no dependencies, FalsoJNI is not supplied with a Makefile of its own, so to get started just include in your own Makefile/CMakeLists.txt all the source files:

FalsoJNI/FalsoJni.c
FalsoJNI/FalsoJni_ImplBridge.c
FalsoJNI/FalsoJni_Logger.c
FalsoJNI/converter.c

Second thing you need to do, is to create your own FalsoJNI_Impl file. You will use it later to provide implementations for custom JNI Methods (the ones called with jni->CallVoidMethodV and similars) and Fields.

To do this, from FalsoJNI_ImplSample.h copy the definitions between COPY STARTING FROM HERE! and COPY UP TO HERE! to your project in any .c file (you could also split it up into several files if you need to).

After that, you already init FalsoJNI and supply JNIEnv and JavaVM objects to your client application, like this:

#include "FalsoJNI.h"

int main() {
    // ...
    
    jni_init(); // Initializes jvm and jni objects

    int (*JNI_OnLoad)(JavaVM* jvm) = (void*)so_symbol(&so_mod,"JNI_OnLoad");
    JNI_OnLoad(&jvm);

    // ...
}

That’s it for the basic setup. In a theoretical situation where your client application doesn’t use any Methods or Fields, you’re done here. Otherwise, read on.

The easiest way to figure out which methods you need to implement is to run the app as-is and look for FalsoJNI’s errors in logs, particularly with GetMethodID / GetStaticMethodID functions:

[ERROR][/tmp/soloader/FalsoJNI.c:295][GetMethodID] [JNI] GetMethodID(env, 0x83561570, "SetShiftEnabled", "(Z)V"): not found
[ERROR][/tmp/soloader/FalsoJNI.c:295][GetMethodID] [JNI] GetMethodID(env, 0x83561570, "Shutdown", "()V"): not found

Two important things you get from this log are the method name ("SetShiftEnabled") and the method signature ("(Z)V").

You can learn what each symbol in Java type signature means here.

To cut on the long details, here are a few self-explanatory examples of how Java method signatures are translated into FalsoJNI-compatible implementations:

// FalsoJNI always passes arguments as a va_list to be able to make single
// function implementation no matter how it is called (i.e. CallMethod,
// CallMethodV, or CallMethodA ).

// "SetShiftEnabled", "(Z)V"
void SetShiftEnabled(jmethodID id, va_list args) { // V (ret type) is a void
    jboolean arg = va_arg(args, jboolean); // Z is a boolean
    // do something
}

// "GetDisplayOrientationLock", "()I"
jint GetDisplayOrientationLock(jmethodID id, va_list args) { // I (ret type) is an integer
    // no arguments here
    return 0;
}

// "GetUsername", "(Ljava/lang/String;)Ljava/lang/String;"
jstring GetUsername(jmethodID id, va_list args) { // Ljava/lang/String; (ret type) is a jstring
    jstring _email = va_arg(args, jstring);
    
    // If you want to work with Java strings, always use respective JNI methods!
    // They are NOT c-strings.
    const char * email = jni->GetStringUTFChars(&jni, _email, NULL);
    const char * username = MyCoolFunctionToLookupUsername(_email);
    jni->ReleaseStringUTFChars(&jni, _email, email);
    
    return jni->NewStringUTF(&jni, username);
}

// "read", "([BII)I"
jint InputStream_read(jmethodID id, va_list args) { // I (ret type) is an integer
    jbyteArray _b = va_arg(args, char*); // [B is a byte array.
    jint off = va_arg(args, int); // I is an int
    jint len = va_arg(args, int); // I is an int

    // Before accessing/changing the array elements, we have to do the following:
    JavaDynArray * jda = (JavaDynArray *) _b;
    if (!jda) {
        log_error("[java.io.InputStream.read()] Provided buffer is not a valid JDA.");
        return 0;
    }

    char * b = jda->array; // Now this array we can work with
}

Pay great attention to the last example. Java arrays are notably different from C arrays by always having the array size information with them, so FalsoJNI mimics Java arrays behavior with a special struct, JavaDynArray (or jda in short).

Every time you receive an array of any kind as an argument, you have to get the “real”, underlying array from it like shown in the example. You can also use jda_sizeof(JavaDynArr *) function to get the length of the array you are operating on.

If you need to return an array in Java method implementation, — likewise. Work with jda->array, return jda.

Also notice the second-to-last example to see how you can work with Java strings.

Now that you have your implementations in place, the only thing left to do to allow the client application to use them is to fill in the arrays in the implementation file you copied from FalsoJNI_ImplSample.h earlier.

You just need to figure out the return types for your methods and come up with any (unique!) method IDs you like. Example of filling the arrays for methods from Step 1:

NameToMethodID nameToMethodId[] = {
    { 100, "SetShiftEnabled", METHOD_TYPE_VOID },
    { 101, "GetDisplayOrientationLock", METHOD_TYPE_INT },
    { 102, "read", METHOD_TYPE_INT },
};

MethodsVoid methodsVoid[] = {
    { 100, SetShiftEnabled }
};

MethodsInt methodsInt[] = {
    { 101, GetDisplayOrientationLock },
    { 102, InputStream_read }
};

With Fields, it’s basically the same thing. Run your app, look for the errors in GetFieldID, GetStaticFieldID to figure out the needed Fields names and signatures (well, just types in this case).

When you know them, fill in the arrays in the same fashion:

NameToFieldID nameToFieldId[] = {
    { 8, "screenWidth",            FIELD_TYPE_INT },
    { 9, "screenHeight",           FIELD_TYPE_INT },
    { 10, "is_licensed",           FIELD_TYPE_BOOLEAN }
};

FieldsBoolean fieldsBoolean[] = {
    { 10, JNI_TRUE }
};

FieldsInt fieldsInt[] = {
    { 8, 960 },
    { 9, 544 },
};

Everything else will be taken care of by FalsoJNI.

1. There is a very verbose logging in this lib to debug difficult situations. Either define FALSOJNI_DEBUGLEVEL or edit FalsoJNI.h if you need to change the verbosity level:

#define FALSOJNI_DEBUG_NO    4
#define FALSOJNI_DEBUG_ERROR 3
#define FALSOJNI_DEBUG_WARN  2
#define FALSOJNI_DEBUG_INFO  1
#define FALSOJNI_DEBUG_ALL   0

#ifndef FALSOJNI_DEBUGLEVEL
#define FALSOJNI_DEBUGLEVEL FALSOJNI_DEBUG_WARN
#endif

2. There are things in JNI that can not be implemented without some terrible overengineering. If you come across one of them, the library will throw a warning-level log at you.

3. I tried to keep the code as clean and self-explanatory as possible, but didn’t have time yet to write a proper documentation. As a direction for further info, look at FalsoJNI_ImplBridge.h header for common type definitions and JDA functions.

4. Oracle JNI spec is your friend.

1. Exception handling. They are completely ignored now.
2. GetArrayLength for ObjectField values. (if needed?)
3. MonitorEnter/MonitorExit (per-javaobject semaphores).
4. DirectByteBuffers.
5. Keep track of references and destroy objects when there aren’t any left.
6. Dry Run mode that would record methods/fields definitions to FalsoJNI_Impl.c for you.

• TheFloW and Rinnegatamante for fake JNI interfaces implementations in gtasa_vita that served as inspiration and basis for this lib.

This software may be modified and distributed under the terms of the MIT license. See the LICENSE file for details.

Contains parts of Dalvik implementation of JNI interfaces, copyright (C) 2008 The Android Open Source Project,
licensed under the Apache License, Version 2.0.

Includes converter.c and converter.h, copyright (C) 2015 Jonathan Bennett jon@autoitscript.com, licensed under the Apache License, Version 2.0.

List of most active GitHub users based on public contributions private contributions and number of followers by country or state. The list updated 2025/8/29 3:05 PM UTC.

This repository contains users 19 countries and 130 cities. To get into the list you need to have minimum number of followers that varies in each country. The list can be found in config.json.

Contribute to GitHub action ePlus-DEV/top-github-users-action. The project maintained by ePlus-DEV. Don’t forget to follow him on GitHub, Twitter, and Website.

• @octokit/graphql – Send GraphQL requests to GitHub API.
• fs-extra – Creating directories and files.
• simple-git – Handling Git commands.

• GitHub Action – ePlus-DEV/top-github-users-action
• Repository – ePlus-DEV/top-github-users
• Data in the ./cache directory – Open Database License

List of most active GitHub users based on public contributions private contributions and number of followers by country or state. The list updated 2025/8/29 3:05 PM UTC.

This repository contains users 19 countries and 130 cities. To get into the list you need to have minimum number of followers that varies in each country. The list can be found in config.json.

Contribute to GitHub action ePlus-DEV/top-github-users-action. The project maintained by ePlus-DEV. Don’t forget to follow him on GitHub, Twitter, and Website.

• @octokit/graphql – Send GraphQL requests to GitHub API.
• fs-extra – Creating directories and files.
• simple-git – Handling Git commands.

• GitHub Action – ePlus-DEV/top-github-users-action
• Repository – ePlus-DEV/top-github-users
• Data in the ./cache directory – Open Database License

Desenvolver uma aplicação utilizando javascript, css e html simulando a etapa de cadastro de endereço e escolha do mesmo para entregar de um produto.

• salvar os endereços em localstorage
• uma segunda página ou aba dentro do mesmo formulário deve permitir ao usuário escolher entre os endereços previamente cadastrados como endereço para entrega, preenchendo assim os campos necessários
• a página deve permitir a exclusão de um endereço já cadastrado

• acessibilidade

• a página deve possuir um logo com endereço da empresa
• a página deve possuir um formulário com os campos nome do cliente e endereço
• os campos devem ser preenchidos automaticamente após informar o cep
• o formulário deve conter as validações necessárias

• favicon
• botão Enter vai para o próximo input com enterkeyhint="next"
• atributo autocomplete
• limpar o formulário para nova busca de cep
• botão para limpar o formulário
• validar as informações vindas da api cep
• responsividade

• ARQUITETURA
• INTERFACE E USABILIDADE
• CLEAN CODE
• RESPONSIVIDADE

• NODE V10.16.0
• VSCODE
• SUBLIME TEXT 3
• GIT BASH

• Template Formulário em w3schools
• Formulários em web.dev/learn/forms
• Brasil API para cep
• Viacep API para cep
• Consultar CEPs
• Consultar CEPs
• Autopreencher com API de CEP – 1
• Autopreencher com API de CEP – 2
• Validar formulário – 2
• Cep com undefined: 68160-000
• Cep com completo: 02227-001
• função ternária

• etapa 3

• etapa 2

• etapa 1

Feito com ❤️ por Douglas A B Novato 👋🏽 Entre em contato!

Fonte do projeto é um desafio para vaga de dev.

An independent set of benchmarks for testing common Scala idioms.

• Functional Programming
  • Folding
  • Chained Higher-Order Functions
  • Concatenation
• Mutable Data
  • List, IList and Array
  • Builder Classes
  • Mutable Set and Java’s ConcurrentHashMap
• Pattern Matching
  • Deconstructing Containers
  • Guard Patterns

We often want to collapse a collection into some summary of its elements.
This is known as a fold, a reduce, or a catamorphism:

List(1,2,3).foldLeft(0)(_ + _)  // 6

How fast is this operation in the face of the JVM’s while and mutable
variables? For instance the familiar, manual, and error-prone:

var n: Int = 0
var i: Int = coll.length - 1

while (i >= 0) {
  n += coll(i)
  i -= 1
}

FoldBench compares List, scalaz.IList, Vector, Array, Stream, and
Iterator for their speeds in various fold operations over Ints.
FoldClassBench tries these same operations over a simple wrapping class to see
how boxing/references affect things.

Int Results:

All times are in microseconds. Entries marked with an asterisk are sped up by
optimization flags. Entries marked with two are slowed down by them.

Pair Class Results:

All times are in microseconds.

Observations:

• foldLeft is always better than both foldRight and manual tail recursion for
  catamorphisms (reduction to a single value).
• sum should be avoided.
• Iterator benefits from while, but not enough to beat List.
• Collections with random access (especially Array) benefit from while
  loops.
• Array has no advantage over List when holding non-primitive types!

Recommendation:

List.foldLeft is concise and performant for both primitive and boxed types.
If you were already dealing with an Array[Int] or likewise, then a while
loop will be faster.

It’s common to string together multiple operations over a collection, say:

List(1,2,3,4).map(foo).filter(pred).map(bar)

which is certainly shorter and cleaner in its intent than manually manipulating
a mutable collection in a while loop. Are higher-order operations like these
still fast? People used to Haskell’s list fusion might point out that these
operations typically don’t fuse in Scala, meaning that each chained operation
fully iterates over the entire collection and allocates a new copy. Stream and
Iterator are supposed to be the exceptions, however.

Stream in particular is what people wanting Haskell’s lazy lists may reach for
first, on the claim that the elements memoize, chained operations fuse, and they
support infinite streams of values. Let’s see how everything performs.

StreamBench performs the following operations on List, scalaz.IList,
Vector, Array, Stream, scalaz.EphemeralStream and Iterator. We test:

• Head: map-filter-map-head. Which collections “short-circuit”, only
  fully processing the head and nothing else?
• Max: map-filter-map-max. How quickly can each collection fully process itself?
  Does fusion occur (esp. with Stream)?
• Reverse: reverse-head. Can any of the collections “cheat” and grab the last
  element quickly?
• Sort: map-filter-map-sorted-head. Does Stream still leverage laziness with
  a “mangling” operation like sort?

Results:

All times are in microseconds.

Observations:

• Stream won’t do work it doesn’t have to, as advertised (re: Head).
• Stream is very slow to fully evaluate, implying no operation fusion.
  Nothing clever happens with sorting.
• Iterator overall is the fastest collection to chain higher-order
  functions.
• List has the fastest reverse.

Recommendation:

If you want to chain higher-order operations in Scala, use an Iterator.
If you have something like a List instead, create an Iterator first
with .iterator before you chain.

Sometimes we need to merge two instances of a container together, end-to-end.
This is embodied by the classic operator ++, available for all the major
collection types.

We know that the collection types are implemented differently. Are some better
than others when it comes to ++? For instance, we might imagine that the
singly-linked List type would be quite bad at this. The lazy Stream types
should be instantaneous.

ConcatBench tests List, scalaz.IList, Array, Vector, Stream, and
scalaz.EphemeralStream for their performance with the ++ operator. Two
results are offered for Array: one with Int and one for a simple Pair
class, to see if primitive Arrays can somehow be optimized here by the JVM, as
they usually are. Otherwise, the results are all for collections of Int.

All times are in microseconds.

Observations:

• The Stream types were instantaneous, as expected.
• Array is quick! Somehow quicker for classes, though.
• The drastic slowdown for Array at the millions-of-elements scale is strange.
• IList beats List until millions-of-elements scale.
• Vector has no advantage here, despite rumours to the contrary.

Recommendation:

If your algorithm requires concatenation of large collections, use Array.
If you’re worried about passing a mutable collection around your API, consider
scalaz.ImmutableArray, a simple wrapper that prevents careless misuse.

Above we saw that List performs strongly against Array when it comes to
chaining multiple higher-order functions together. What happens when we just
need to make a single transformation pass over our collection – in other words,
a .map? Array with a while loop is supposed to be the fastest iterating
operation on the JVM. Can List and IList still stand up to it?

MapBench compares these operations over increasing larger collection sizes of
both Int and a simple wrapper class.

Results:

All times are in microseconds.

Observations:

• For List, there isn’t too much difference between Ints and classes.
• Array is fast to do a single-pass iteration.

Recommendation:

If your code involves Array, primitives, and simple single-pass
transformations, then while loops will be fast for you. Otherwise, your code
will be cleaner and comparitively performant if you stick to immutable
collections and chained higher-order functions.

You want to build up a new collection, perhaps iterating over an existing one,
perhaps from some live, dynamic process. For whatever reason .map and
.foldLeft are not an option. Which collection is best for this? VectorBench
tests how fast each of List, scalaz.IList, ListBuffer, Vector,
VectorBuilder, Array, ArrayBuilder, and IndexedSeq can create themselves
and accumulate values. For List, this is done with tail recursion. For
IndexedSeq, this is done via a naive for-comprehension. For all others, this
is done with while loops. The Buffer and Builder classes perform a
.result call at the end of iterating to take their non-builder forms (i.e.
VectorBuilder => Vector). ArrayBuilder is given an overshot size hint (with
.sizeHint) in order to realistically minimize inner Array copying.

Results:

All times are in microseconds.

Observations:

• For primitives, Array is king.
• Avoid appending to immutable Vectors.
• Avoid repeated use of ListBuffer.prepend! Your runtime will slow by an order of magnitude vs +=:.
• For classes, at small scales (~1000 elements) there is mostly no difference between
  the various approaches.
• ArrayBuilder can be useful if you’re able to ballpark what the final result size will be.
• VectorBuilder fulfills the promise of Builders, but can only append to the right.
  You’d have to deal with the fact that your elements are reversed.

Recommendation:

The best choice here depends on what your next step is.

If you plan to perform while -based numeric calculations over primitives only,
stick to Array. If using ArrayBuilder with primitives, avoid the .make
method. Use something like .ofInt instead. Also make sure that you use
.sizeHint to avoid redundant inner Array copying as your collection grows.
Failing to do so can introduce a 5x slowdown.

Otherwise, consider whether your algorithm can’t be reexpressed entirely in
terms of Iterator. This will always give the best performance for subsequent
chained, higher-order functions.

If the algorithm can’t be expressed in terms of Iterator from the get-go, try
building your collection with VectorBuilder, call .iterator once filled,
then continue.

You’d like to build up a unique set of values and for some reason calling
.toSet on your original collection isn’t enough. Perhaps you don’t have an
original collection. Scala’s collections have been criticized for their
performance, with one famous complaint saying how their team had to fallback to
using Java collection types entirely because the Scala ones couldn’t compare
(that was for Scala 2.8, mind you).

Is this true? UniquesBench compares both of Scala’s mutable and immutable
Set types with Java’s ConcurrentHashMap to see which can accumulate unique
values faster.

Results:

All values are in microseconds.

Note: About half the time the 10000-value benchmark for mutable.Set
optimizes down to ~600us instead of the ~800us shown in the chart.

Observations:

• mutable.Set is fastest at least for small amounts of data, and might be
  fastest at scale.
• immutable.Set is slower and has worse growth, as expected.

Recommendation:

First consider whether your algorithm can’t be rewritten in terms of the usual
FP idioms, followed by a .toSet call to make the collection unique.

If that isn’t possible, then trust in the performance of native Scala
collections and use mutable.Set.

It’s common to decontruct containers like this in recursive algorithms:

def safeHead[A](s: Seq[A]): Option[A] = s match {
  case Seq() => None
  case h +: _ => Some(h)
}

But List and Stream have special “cons” operators, namely :: and #::
respectively. The List version of the above looks like:

def safeHead[A](l: List[A]): Option[A] = l match {
  case Nil => None
  case h :: _ => Some(h)
}

How do these operators compare? Also, is it any slower to do it this way than a
more Java-like:

def safeHead[A](l: List[A]): Option[A] =
  if (l.isEmpty) None else l.head

The MatchContainersBench benchmarks use a tail-recursive algorithm to find the
last element of each of List, scalaz.IList, Vector, Array, Seq, and
Stream.

Results:

All times are in microseconds.

Observations:

• Canonical List and IList matching is fast.
• Seq matching with +:, its canonical operator, is ironically slow.
• Pattern matching with +: should be avoided in general.
• if is generally faster than pattern matching, but the code isn’t as nice.
• Avoid recursion with Vector and Array!
• Array.tail is pure evil. Each call incurs ArrayOps wrapping and
  seems to reallocate the entire Array. Vector.tail incurs a similar
  slowdown, but not as drasticly.

Recommendation:

Recursion involving containers should be done with List and pattern matching
for the best balance of speed and simplicity. If you can take scalaz as a
dependency, its IList will be even faster.

It can sometimes be cleaner to check multiple Boolean conditions using a match:

def foo(i: Int): Whatever = i match {
  case _ if bar(i) => ???
  case _ if baz(i) => ???
  case _ if zoo(i) => ???
  case _ => someDefault
}

where we don’t really care about the pattern match, just the guard. This is in
constrast to if branches:

def foo(i: Int): Whatever = {
  if (bar(i)) ???
  else if (baz(i)) ???
  else if (zoo(i)) ???
  else someDefault
}

which of course would often be made more verbose by many {} pairs. Are we
punished for the empty pattern matches? MatchBench tests this, with various
numbers of branches.

Results:

All times are in nanoseconds.

Identical! Feel free to use whichever you think is cleaner.

• Maiorani Simone
• Venturi Marco

The project carried out aims to display information relating to a collection of opera performances that took place throughout Europe between 1775 and 1833.

{
  "opera_performances": [
    {
      "rism_id": "125794",
      "composer": "Paisiello, Giovanni",
      "librettist": "Metastasio, Pietro",
      "title": "Achille in Sciro",
      "performance_year": "1778",
      "placename": "Sankt Petersburg"
    },
    {
      "rism_id": "101479",
      "composer": "Mayr, Johann Simon",
      "librettist": "Rossi, Gaetano",
      "title": "Adelaide di Guesclino",
      "performance_year": "1799",
      "placename": "Venezia"
    },
    ...

Before Starting this adveture in first 800’s, we asked to ourself what we would learn from these data. After some documentation about opera world we were curios about:

• How operas move throught nations and time?
• Which are the most important cities where operas are perform?
• How librettist and composer worked toghether?
• How many operas they made?
• With how many composers a librettist can work and vice versa?
• …

These are just some of the questions that we tried to answer using graph visualization.

Types of graphs used:

• Map graphs
• Force Directed graph

Tecnologies:

• Node.js v18.0.0
• Electron

Libraries:

• Bootstrap v5.2
• D3.js v7
• amCharts v5

The map graphs aims to focus on the cities where the opera took place. The nodes represent the cities while the edges between two nodes are present if and only if a opera was performed in both cities (the source and destination are established on the basis of the year in which the opera took place in the two cities). A second map graph shows only a few cities that hosted a opera that took place nowhere else. The edges represent this common feature between the various cities in question.

When the mouse passes over the nodes, the name of the city appears. If you select a node, information on the names and years of the opera that took place in that city appears.
By clicking on the legend you have a focus on the individual opera, highlighting only the edges involved.

The force directed graph aim to focus on reletionship between librettist and composer. Blu nodes reppresent composer, while orange nodes are librettist. These nodes are connected by edges if and only if they worked toghether at least one time, while edges color and thickness, represent respectively the first year that a librettist and a composer worked toghether and the number of time that they worked toghether.

When a click event happen on a edge the two nodes connected to that edge change color to red, while dark grey rectangle under nodes legend, it shows operas titles and number of operas which librettist and composer made toghether.

The header is a composition of 3 button:

1. Mappa del Mondo: Load Map graph
2. Rigenera Colori: Reload the page and assign new edges colors
3. Reset info: Restore Information and red nodes to their original appearance.

• Maiorani Simone
• Venturi Marco

The project carried out aims to display information relating to a collection of opera performances that took place throughout Europe between 1775 and 1833.

{
  "opera_performances": [
    {
      "rism_id": "125794",
      "composer": "Paisiello, Giovanni",
      "librettist": "Metastasio, Pietro",
      "title": "Achille in Sciro",
      "performance_year": "1778",
      "placename": "Sankt Petersburg"
    },
    {
      "rism_id": "101479",
      "composer": "Mayr, Johann Simon",
      "librettist": "Rossi, Gaetano",
      "title": "Adelaide di Guesclino",
      "performance_year": "1799",
      "placename": "Venezia"
    },
    ...

Before Starting this adveture in first 800’s, we asked to ourself what we would learn from these data. After some documentation about opera world we were curios about:

• How operas move throught nations and time?
• Which are the most important cities where operas are perform?
• How librettist and composer worked toghether?
• How many operas they made?
• With how many composers a librettist can work and vice versa?
• …

These are just some of the questions that we tried to answer using graph visualization.

Types of graphs used:

• Map graphs
• Force Directed graph

Tecnologies:

• Node.js v18.0.0
• Electron

Libraries:

• Bootstrap v5.2
• D3.js v7
• amCharts v5

The map graphs aims to focus on the cities where the opera took place. The nodes represent the cities while the edges between two nodes are present if and only if a opera was performed in both cities (the source and destination are established on the basis of the year in which the opera took place in the two cities). A second map graph shows only a few cities that hosted a opera that took place nowhere else. The edges represent this common feature between the various cities in question.

When the mouse passes over the nodes, the name of the city appears. If you select a node, information on the names and years of the opera that took place in that city appears.
By clicking on the legend you have a focus on the individual opera, highlighting only the edges involved.

The force directed graph aim to focus on reletionship between librettist and composer. Blu nodes reppresent composer, while orange nodes are librettist. These nodes are connected by edges if and only if they worked toghether at least one time, while edges color and thickness, represent respectively the first year that a librettist and a composer worked toghether and the number of time that they worked toghether.

When a click event happen on a edge the two nodes connected to that edge change color to red, while dark grey rectangle under nodes legend, it shows operas titles and number of operas which librettist and composer made toghether.

The header is a composition of 3 button:

1. Mappa del Mondo: Load Map graph
2. Rigenera Colori: Reload the page and assign new edges colors
3. Reset info: Restore Information and red nodes to their original appearance.

Installs php-fpm from IUS Community Project RPMs on RHEL / CentOS 7. Where archived verions of php are required, the ius-archive repository may be enabled.

Currently this role installs php-fpm pre-configured with defaults built around the Magento 2 application. Some of these defaults may be high than required for other applications of the php-fpm service. One of these areas would by the php-opcache defaults, which must be very high for high Magento 2 application performance and may otherwise be reduced. See defaults/main.yml and vars/opcache.yml for details.

None.

php_version: 73

Any php version supported by IUS RPMs may be specified: 55, 56, 70, 71, 72, 73, 74, etc. For older versions, php_enablerepo: ius-archive will also need to be specified.

See defaults/main.yml for complete list of variables available to customize the php-fpm installation.

• davidalger.repo_ius

- hosts: web-servers
  roles:
    - { role: davidalger.php_fpm, tags: php-fpm }

This work is licensed under the MIT license. See LICENSE file for details.

This role was created in 2017 by David Alger.