Homebrew.jl: OSX Binary dependency provider for Julia

Unmaintained

Note: This package is unmaintained, all users are strongly encouraged to use JLL packages for their binary needs.

Homebrew.jl (OSX only)

Homebrew.jl sets up a homebrew installation inside your Julia package directory. It uses Homebrew to provide specialized binary packages to satisfy dependencies for other Julia packages, without the need for a compiler or other development tools; it is completely self-sufficient.

Package authors with dependencies that want binaries distributed in this manner should open an issue here for inclusion into the package database.

NOTE: If you have MacPorts installed, and are seeing issues with git or curl complaining about certificates, try to update the the curl and curl-ca-bundle packages before using Homebrew.jl. From the terminal, run:

port selfupdate
port upgrade curl curl-ca-bundle

Usage (Users)

As a user, you ideally shouldn't ever have to use Homebrew directly, short of installing it via Pkg.add("Homebrew"). However, there is a simple to use interface for interacting with the Homebrew package manager:

• Homebrew.add("pkg") will install pkg, note that if you want to install a package from a non-default tap, you can do so via Homebrew.add("user/tap/formula"). An example of this is installing the metis4 formula from the Homebrew/science tap via Homebrew.add("homebrew/science/metis4").
• Homebrew.rm("pkg") will uninstall pkg
• Homebrew.update() will update the available formulae for installation and upgrade installed packages if a newer version is available
• Homebrew.list() will list all installed packages and versions
• Homebrew.installed("pkg") will return a Bool denoting whether or not pkg is installed
• Homebrew.prefix() will return the prefix that all packages are installed to

Usage (Package Authors)

As a package author, the first thing to do is to write/find a Homebrew formula for whatever package you wish to create. The easiest way to tell if the binary will work out-of-the-box is Homebrew.add() it. Formulae from the default homebrew/core tap need no prefix, but if you are installing something from another tap, you need to prefix it with the appropriate tap name. For example, to install metis4 from the homebrew/science tap, you would run Homebrew.add("homebrew/science/metis4"). Programs installed to <prefix>/bin and libraries installed to <prefix>/lib will automatically be availble for run()'ing and dlopen()'ing.

If that doesn't "just work", there may be some special considerations necessary for your piece of software. Open an issue here with a link to your formula and we will discuss what the best approach for your software is. To see examples of formulae we have already included for special usage, peruse the homebrew-juliadeps repository.

To have your Julia package automatically install these precompiled binaries, Homebrew.jl offers a BinDeps provider which can be accessed as Homebrew.HB. Simply declare your dependency on Homebrew.jl via a @osx Homebrew in your REQUIRE files, create a BinDeps library_dependency and state that Homebrew provides that dependency:

using BinDeps
@BinDeps.setup
nettle = library_dependency("nettle", aliases = ["libnettle","libnettle-4-6"])

...
# Wrap in @osx_only to avoid non-OSX users from erroring out
@osx_only begin
    using Homebrew
    provides( Homebrew.HB, "nettle", nettle, os = :Darwin )
end

@BinDeps.install Dict(:nettle => :nettle)

Then, the Homebrew package will automatically download the requisite bottles for any dependencies you state it can provide. This example garnered from the build.jl file from Nettle.jl package.

Why Package Authors should use Homebrew.jl

A common question is why bother with Homebrew formulae and such when a package author could simply compile the .dylib's needed by their package, upload them somewhere and download them to a user's installation somewhere. There are multiple reasons, and although they are individually surmountable Homebrew offers a simpler (and standardized) method of solving many of these problems automatically:

On OSX shared libraries link via full paths. This means that unless you manually alter the path inside of a .dylib or binary to have an @rpath or @executable_path in it, the path will be attempting to point to the exact location on your harddrive that the shared library was found at compile-time. This is not an issue if all libraries linked to are standard system libraries, however as soon as you wish to link to a library in a non-standard location you must alter the paths. Homebrew does this for you automatically, rewriting the paths during installation via install_name_tool. To see the paths embedded in your libraries and executable files, run otool -L <file>.

Dependencies on other libraries are handled gracefully by Homebrew. If your package requires some heavy-weight library such as cairo, glib, etc... Homebrew already has those libraries ready to be installed for you.

Releasing new versions of binaries can be difficult. Homebrew.jl has builtin mechanisms for upgrading all old packages, and even detecting when a binary of the same version number has a new revision (e.g. if an old binary had an error embedded inside it).

Why doesn't this package use my system-wide Homebrew installation?

Some of the formulae in the staticfloat/juliadeps tap are specifically patched to work with Julia. Some of these patches have not (or will not) be merged back into Homebrew mainline, so we don't want to conflict with any packages the user may or may not have installed.

Users can modify Homebrew's internal workings, so it's better to have a known good Homebrew installation than to risk bug reports from users that have unknowingly merged patches into Homebrew that break functionality we require.

If you already have something installed, and it is usable, (e.g. BinDeps can load it and it passes any quick internal tests the Package authors have defined) then Homebrew.jl won't try to install it. BinDeps always checks to see if there is a library in the current load path that satisfies the requirements setup by package authors, and if there is, it doesn't build anything.

Advanced usage

Homebrew.jl provides a convenient wrapper around most of the functionality of Homebrew, however there are rare cases where access to the full suite of brew commands is necessary. To facilitate this, users that are familiar with the brew command set can use Homebrew.brew() to directly feed commands to the brew binary within Homebrew.jl. Example usage:

julia> using Homebrew

julia> Homebrew.brew(`info staticfloat/juliadeps/libgfortran`)
staticfloat/juliadeps/libgfortran: stable 6.2 (bottled)
http://gcc.gnu.org/wiki/GFortran
/Users/sabae/.julia/v0.5/Homebrew/deps/usr/Cellar/libgfortran/6.2 (9 files, 2M) *
  Poured from bottle on 2016-11-21 at 13:14:33
From: https://github.com/staticfloat/homebrew-juliadeps/blob/master/libgfortran.rb
==> Dependencies
Build: gcc ✘

Download Details: 

Author: JuliaPackaging
Source Code: https://github.com/JuliaPackaging/Homebrew.jl 
License: View license

#julia #binary 

What is GEEK

Buddha Community

Binary MLM Software Demo | Binary Compensation Plan, MLM Woocommerce

Binary MLM Software Demo | Binary MLM Compensation Plan, MLM Woocommerce Price USA, Philippines : Binary MLM Woocommerce Software is a web application that integrate with the Woo-commerce plugin and helps to manage binary MLM networks. LETSCMS provide worldwide service, such as USA, Hong Kong, China, UK, UAE, Jordan, Saudi Arabia, Pakistan, Philippines, Japan, Singapore, Romania, Vietnam, Canada, Hong Kong, Russia, Hungary, Romania, Poland, Thailand, Laos and many others.

Binary MLM Woo-commerce includes a two legged structure where in a parent Node has two sub nodes where each new distributor or members is placed in either left or right sub-tree. One sub-tree is known as a Power Leg or Profit Leg while the second sub-tree is a Profit Leg or a weak leg.. It  is one of the basic Binary MLM plan which is required by all the MLM organizations be it small or large. The binary MLM plan helps admin managing users or sub nodes in a binary network to keep record of their income, expenses etc.

Admin Demo : https://wpbmw.mlmforest.com/wp-admin/admin.php?page=bmw-settings

Front Demo : https://wpbmw.mlmforest.com/?page_id=56

Features
Admin Features
Payout Reports.
Report to show complete details of an individual payouts.
Affiliate Commission.
Pair Commission .
Bonus Commission.
Specify eligibility criteria in the admin.
Configuration of commission and bonus details in the admin.
Service Charges for payout.
Run payouts manually.
Payout Detail based on user in admin .

Frontend Features
Register a Binary MLM User from provided registration page.
Register new Members using Genealogy.
New Join Network Page for non-Network Members .
MLM registration can happen by the Checkout page also.
Members can view full payout details in their account.

If you want to know more information and any queries regarding Binary MLM Woo-commerce, you can contact our experts through 
Skype: jks0586, 
Mail: letscmsdev@gmail.com, 
Website: www.letscms.com, www.mlmtrees.com,
Call/WhatsApp/WeChat: +91-9717478599.

more information : https://www.mlmtrees.com/product/binary-mlm-ecommerce

Vedio : https://www.youtube.com/watch?v=gji5XnnTJNc&list=PLn9cGkS1zw3QMCC-89p5zK39mPtfltkwq&index=5

 

#mlm_plan #Binary_mlm #binary_mlm_plan #Binary_mlm_wordpress_plugin #Binary_mlm_woo-commerce #binary_mlm_ecommerce #binary_mlm_software #binary_mlm_wp_plugin #biary_mlm_ecommerce #mlm_plan
 

Homebrew.jl: OSX Binary dependency provider for Julia

Unmaintained

Note: This package is unmaintained, all users are strongly encouraged to use JLL packages for their binary needs.

Homebrew.jl (OSX only)

Homebrew.jl sets up a homebrew installation inside your Julia package directory. It uses Homebrew to provide specialized binary packages to satisfy dependencies for other Julia packages, without the need for a compiler or other development tools; it is completely self-sufficient.

Package authors with dependencies that want binaries distributed in this manner should open an issue here for inclusion into the package database.

NOTE: If you have MacPorts installed, and are seeing issues with git or curl complaining about certificates, try to update the the curl and curl-ca-bundle packages before using Homebrew.jl. From the terminal, run:

port selfupdate
port upgrade curl curl-ca-bundle

Usage (Users)

As a user, you ideally shouldn't ever have to use Homebrew directly, short of installing it via Pkg.add("Homebrew"). However, there is a simple to use interface for interacting with the Homebrew package manager:

• Homebrew.add("pkg") will install pkg, note that if you want to install a package from a non-default tap, you can do so via Homebrew.add("user/tap/formula"). An example of this is installing the metis4 formula from the Homebrew/science tap via Homebrew.add("homebrew/science/metis4").
• Homebrew.rm("pkg") will uninstall pkg
• Homebrew.update() will update the available formulae for installation and upgrade installed packages if a newer version is available
• Homebrew.list() will list all installed packages and versions
• Homebrew.installed("pkg") will return a Bool denoting whether or not pkg is installed
• Homebrew.prefix() will return the prefix that all packages are installed to

Usage (Package Authors)

As a package author, the first thing to do is to write/find a Homebrew formula for whatever package you wish to create. The easiest way to tell if the binary will work out-of-the-box is Homebrew.add() it. Formulae from the default homebrew/core tap need no prefix, but if you are installing something from another tap, you need to prefix it with the appropriate tap name. For example, to install metis4 from the homebrew/science tap, you would run Homebrew.add("homebrew/science/metis4"). Programs installed to <prefix>/bin and libraries installed to <prefix>/lib will automatically be availble for run()'ing and dlopen()'ing.

If that doesn't "just work", there may be some special considerations necessary for your piece of software. Open an issue here with a link to your formula and we will discuss what the best approach for your software is. To see examples of formulae we have already included for special usage, peruse the homebrew-juliadeps repository.

To have your Julia package automatically install these precompiled binaries, Homebrew.jl offers a BinDeps provider which can be accessed as Homebrew.HB. Simply declare your dependency on Homebrew.jl via a @osx Homebrew in your REQUIRE files, create a BinDeps library_dependency and state that Homebrew provides that dependency:

using BinDeps
@BinDeps.setup
nettle = library_dependency("nettle", aliases = ["libnettle","libnettle-4-6"])

...
# Wrap in @osx_only to avoid non-OSX users from erroring out
@osx_only begin
    using Homebrew
    provides( Homebrew.HB, "nettle", nettle, os = :Darwin )
end

@BinDeps.install Dict(:nettle => :nettle)

Then, the Homebrew package will automatically download the requisite bottles for any dependencies you state it can provide. This example garnered from the build.jl file from Nettle.jl package.

Why Package Authors should use Homebrew.jl

A common question is why bother with Homebrew formulae and such when a package author could simply compile the .dylib's needed by their package, upload them somewhere and download them to a user's installation somewhere. There are multiple reasons, and although they are individually surmountable Homebrew offers a simpler (and standardized) method of solving many of these problems automatically:

On OSX shared libraries link via full paths. This means that unless you manually alter the path inside of a .dylib or binary to have an @rpath or @executable_path in it, the path will be attempting to point to the exact location on your harddrive that the shared library was found at compile-time. This is not an issue if all libraries linked to are standard system libraries, however as soon as you wish to link to a library in a non-standard location you must alter the paths. Homebrew does this for you automatically, rewriting the paths during installation via install_name_tool. To see the paths embedded in your libraries and executable files, run otool -L <file>.

Dependencies on other libraries are handled gracefully by Homebrew. If your package requires some heavy-weight library such as cairo, glib, etc... Homebrew already has those libraries ready to be installed for you.

Releasing new versions of binaries can be difficult. Homebrew.jl has builtin mechanisms for upgrading all old packages, and even detecting when a binary of the same version number has a new revision (e.g. if an old binary had an error embedded inside it).

Why doesn't this package use my system-wide Homebrew installation?

Some of the formulae in the staticfloat/juliadeps tap are specifically patched to work with Julia. Some of these patches have not (or will not) be merged back into Homebrew mainline, so we don't want to conflict with any packages the user may or may not have installed.

Users can modify Homebrew's internal workings, so it's better to have a known good Homebrew installation than to risk bug reports from users that have unknowingly merged patches into Homebrew that break functionality we require.

If you already have something installed, and it is usable, (e.g. BinDeps can load it and it passes any quick internal tests the Package authors have defined) then Homebrew.jl won't try to install it. BinDeps always checks to see if there is a library in the current load path that satisfies the requirements setup by package authors, and if there is, it doesn't build anything.

Advanced usage

Homebrew.jl provides a convenient wrapper around most of the functionality of Homebrew, however there are rare cases where access to the full suite of brew commands is necessary. To facilitate this, users that are familiar with the brew command set can use Homebrew.brew() to directly feed commands to the brew binary within Homebrew.jl. Example usage:

julia> using Homebrew

julia> Homebrew.brew(`info staticfloat/juliadeps/libgfortran`)
staticfloat/juliadeps/libgfortran: stable 6.2 (bottled)
http://gcc.gnu.org/wiki/GFortran
/Users/sabae/.julia/v0.5/Homebrew/deps/usr/Cellar/libgfortran/6.2 (9 files, 2M) *
  Poured from bottle on 2016-11-21 at 13:14:33
From: https://github.com/staticfloat/homebrew-juliadeps/blob/master/libgfortran.rb
==> Dependencies
Build: gcc ✘

Download Details: 

Author: JuliaPackaging
Source Code: https://github.com/JuliaPackaging/Homebrew.jl 
License: View license

#julia #binary 

BinaryProvider.jl: A Reliable Binary Provider for Julia

BinaryProvider

Basic concepts

Packages are installed to a Prefix; a folder that acts similar to the /usr/local directory on Unix-like systems, containing a bin folder for binaries, a lib folder for libraries, etc... Prefix objects can have tarballs install()'ed within them, uninstall()'ed from them, etc...

BinaryProvider has the concept of a Product, the result of a package installation. LibraryProduct and ExecutableProduct are two example Product object types that can be used to keep track of the binary objects installed by an install() invocation. Products can check to see if they are already satisfied (e.g. whether a file exists, or is executable, or is dlopen()'able), allowing for very quick and easy build.jl construction.

BinaryProvider also contains a platform abstraction layer for common operations like downloading and unpacking tarballs. The primary method you should be using to interact with these operations is through the install() method, however if you need more control, there are more fundamental methods such as download_verify(), or unpack(), or even the wittingly-named download_verify_unpack().

The method documentation within the BinaryProvider module should be considered the primary source of documentation for this package, usage examples are provided in the form of the LibFoo.jl mock package within this repository, as well as other packages that use this package for binary installation such as

Usage

To download and install a package into a Prefix, the basic syntax is:

prefix = Prefix("./deps")
install(url, tarball_hash; prefix=prefix)

It is recommended to inspect examples for a fuller treatment of installation, the LibFoo.jl package within this repository contains a deps/build.jl file that may be instructive.

To actually generate the tarballs that are installed by this package, check out the BinaryBuilder.jl package.

Miscellanea

This package contains a run(::Cmd) wrapper class named OutputCollector that captures the output of shell commands, and in particular, captures the stdout and stderr streams separately, colorizing, buffering and timestamping appropriately to provide seamless printing of shell output in a consistent and intuitive way. Critically, it also allows for saving of the captured streams to log files, a very useful feature for BinaryBuilder.jl, which makes extensive use of this class, however all commands run by BinaryProvider.jl also use this same mechanism to provide coloring of stderr.

When providing ExecutableProducts to a client package, BinaryProvider will automatically append Julia's private library directory to LD_LIBRARY_PATH on Linux, and DYLD_LIBRARY_PATH on macOS. This is due to the fact that the compiled binaries may be dependent on libraries such as libgfortran, which ship with Julia and must be found by the system linker or else the binaries will not function. If you wish to use the binaries outside of Julia, you may need to override those environment variables in a similar fashion; see the generated deps.jl file for the check_deps() function where the precise overriding values can be found.

Download Details:

Author: JuliaPackaging
Source Code: https://github.com/JuliaPackaging/BinaryProvider.jl 
License: View license

#julia #dependency 

CondaBinDeps.jl: Conda BinDeps provider for Julia

CondaBinDeps.jl 

This package, which builds on the Conda.jl package allows one to use conda as a BinDeps binary provider for Julia. While other binary providers like Homebrew.jl, AptGet or WinRPM.jl are platform-specific, CondaBinDeps.jl is a cross-platform alternative. It can also be used without administrator rights, in contrast to the current Linux-based providers.

As such, Conda.jl primary audience is Julia packages developers who have a dependency on some native library.

conda is a package manager which started as the binary package manager for the Anaconda Python distribution, but it also provides arbitrary packages. Instead of the full Anaconda distribution, Conda.jl uses the miniconda Python environment, which only includes conda and its dependencies.

CondaBinDeps.jl is NOT an alternative Julia package manager, nor a way to manage Python installations. It will not use any pre-existing Anaconda or Python installation on your machine.

Basic functionality

You can install this package by running Pkg.add("CondaBinDeps") at the Julia prompt. See the Conda.jl package for information on setting up conda environments, etcetera.

BinDeps integration: using Conda.jl as a package author

CondaBinDeps.jl can be used as a Provider for BinDeps with the Conda.Manager type. You first need to write a conda recipe, and upload the corresponding build to binstar. Then, add CondaBinDeps in your REQUIRE file, and add the following to your deps/build.jl file:

using BinDeps
@BinDeps.setup
netcdf = library_dependency("netcdf", aliases = ["libnetcdf" "libnetcdf4"])

...

using CondaBinDeps
provides(CondaBinDeps.Manager, "libnetcdf", netcdf)

If your dependency is available in another channel than the default one, you should register that channel.

CondaBinDeps.Conda.add_channel("my_channel")
provides(CondaBinDeps.Manager, "libnetcdf", netcdf)

If the binary dependency is only available for some OS, give this information to BinDeps:

provides(CondaBinDeps.Manager, "libnetcdf", netcdf, os=:Linux)

To tell BinDeps to install the package to an environment different from the root environment, use EnvManager.

provides(CondaBinDeps.EnvManager{:my_env}, "libnetcdf", netcdf)

Bugs and suggestions

CondaBinDeps has been tested on Linux, OS X, and Windows. It should work on all these platforms.

Please report any bug or suggestion as a github issue

Download Details: 

Author: JuliaPackaging
Source Code: https://github.com/JuliaPackaging/CondaBinDeps.jl 
License: View license

#julia #binary 

BSON.jl: Julia Package for Working with The Binary JSON Serialisation

BSON

BSON.jl is a Julia package for working with the Binary JSON serialisation format. It can be used as a general store for Julia data structures, with the following features:

• Lightweight and ubiquitous, with a simple JSON-like data model and clients in many languages.
• Efficient for binary data (eg. arrays of floats).
• Flexible enough to handle anything you throw at it – closures, custom types, circular data structures, etc.
• Backwards compatible, so that if data layout changes old files will still load.

julia> using BSON

julia> bson("test.bson", Dict(:a => [1+2im, 3+4im], :b => "Hello, World!"))

julia> BSON.load("test.bson")
Dict{Symbol,Any} with 2 entries:
  :a => Complex{Int64}[1+2im, 3+4im]
  :b => "Hello, World!"

(Note that the top-level object in BSON is always a Dict{Symbol,Any}).

⚠️ Warning: Loading BSON files is not safe from malicious or erroneously constructed data. Loading BSON files can cause arbitrary code to execute on your machine. Do not load files from unknown or untrusted sources.

There a few utility methods for working with BSON files.

julia> using BSON

julia> bson("test.bson", a = 1, b = 2)

julia> BSON.load("test.bson")
Dict{Symbol,Any} with 2 entries:
  :a => 1
  :b => 2

julia> using BSON: @save, @load

julia> a, b = 1, 2
(1, 2)

julia> @save "test.bson" a b # Same as above

julia> @load "test.bson" a b # Loads `a` and `b` back into the workspace

For external files you can use BSON.parse to load raw BSON data structures without any Julia-specific interpretation. In basic cases, this will look that same, but Julia-specific types will be stored in a more complex format.

julia> BSON.parse("test.bson")
Dict{Symbol,Any} with 2 entries:
  :a => 1
  :b => 2

julia> BSON.parse("test.bson")[:data]
Dict{Symbol,Any} with 4 entries:
  :tag  => "array"
  :type => Dict(:tag=>"datatype",:params=>Any[],:name=>["Core","Int64"])
  :size => [3]
  :data => UInt8[0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00  …  ]

This is also how the data will appear to readers in other languages, should you wish to move data outside of Julia.

Notes

Below is some semi-official documentation on more advanced usage.

Loading custom data types within modules

For packages that use BSON.jl to load data, just writing BSON.load("mydata.bson") will not work with custom data types. Here's a simple example of that for DataFrames.jl:

module A
  using DataFrames, BSON
  d = DataFrame(a = 1:10, b = 5:14)
  bson("data.bson", Dict(:d=>d))
  d2 = BSON.load("data.bson") # this will throw an error
end

In these cases, you can specify the namespace under which to resolve types like so:

d2 = BSON.load("data.bson", @__MODULE__)

This will use the current module's namespace when loading the data. You could also pass any module name as the second argument (though almost all cases will use @__MODULE__). By default, the namespace is Main (i.e. the REPL).

Download Details:

Author: JuliaIO
Source Code: https://github.com/JuliaIO/BSON.jl 
License: View license

#julia #binary #json