# Generated from y_nelson-2.3.8.gem by gem2rpm -*- rpm-spec -*-
%global gem_name y_nelson

Name: rubygem-%{gem_name}
Version: 2.3.8
Release: 1%{?dist}
Summary: A fusion of a universal Petri net with a zz structure that formalizes and generalizes spreadsheet. As an extension of YPetri (y_petri) gem, YNelson inherits all its capabilities for modelling dynamical systems, but adds the capability to represent relations between model nodes and parameters
License: GPLv3
Source0: https://rubygems.org/gems/%{gem_name}-%{version}.gem
BuildRequires: ruby(release)
BuildRequires: rubygems-devel
BuildRequires: ruby >= 2.0
BuildArch: noarch

%description
Zz structures are an interesting way of representing relations invented by Ted
Nelson, whose domain model I provide in a gem Yzz. In this gem, YNelson, I
combine Yzz with the universal Petri net provided by YPetri (another gem I
wrote) to obtain a hybrid data structure that formalizes and generelizes a
spreadsheet. Because let us note spreadsheets (as I have seen them) can be
considered Petri nets of a kind, with cell functions acting as Petri net
transitions. At the same time, spreadsheets are globally orthogonal structures
with 3 typical dimensions (rows, columns and sheets). By using zz structures,
the globally orthogonal spreadsheet is generalized as a locally orthogonal zz
structure, with relations represented as zz dimensions, thus generalizing and
formalizing a spreadsheet. The catch is that I have not yet finished the
thinking process regarding what everything should be a zz object: Places
(cells) and transitions definitely yes, but how about nets and dimensions?
Should YNelson go as far as making namespaces into zz objects? The reason why
these questions are hard to answer is because Ted Nelson himself, while
providing interfaces guidelines (zz structure views, cursors...) did not
comment on these questions. While being a (textual) DSL, YNelson aims to
provide convenience on par with actual spreadsheet apps. Unlike YPetri,
YNelson also aims to be able to specify more than one Petri net node per
command, but this is still under development. See the user guide and the
documentation for the details. YNelson documentation is available online, but
due to formatting issues, you may prefer to generate the documentation on your
own by running rdoc in the gem directory. For an example of how YPetri can be
used to model complex dynamical systems, see the eukaryotic cell cycle model
which I released as "cell_cycle" gem.


%package doc
Summary: Documentation for %{name}
Requires: %{name} = %{version}-%{release}
BuildArch: noarch

%description doc
Documentation for %{name}.

%prep
%setup -q -n %{gem_name}-%{version}

%build
# Create the gem as gem install only works on a gem file
gem build ../%{gem_name}-%{version}.gemspec

# %%gem_install compiles any C extensions and installs the gem into ./%%gem_dir
# by default, so that we can move it into the buildroot in %%install
%gem_install

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/* \
        %{buildroot}%{gem_dir}/



%check
pushd .%{gem_instdir}
# Run the test suite.
popd

%files
%dir %{gem_instdir}
%exclude %{gem_instdir}/.gitignore
%{gem_instdir}/ACKNOWLEDGMENT.txt
%{gem_instdir}/Introduction_to_Ruby_for_YPetri_and_YNelson_Users.pdf
%{gem_instdir}/Introduction_to_YPetri_and_YNelson.pdf
%license %{gem_instdir}/LICENSE.txt
%{gem_instdir}/Object_model_of_YPetri_and_YNelson.pdf
%{gem_libdir}
%exclude %{gem_cache}
%{gem_spec}

%files doc
%doc %{gem_docdir}
%{gem_instdir}/Gemfile
%doc %{gem_instdir}/README.md
%{gem_instdir}/Rakefile
%{gem_instdir}/test
%{gem_instdir}/y_nelson.gemspec

%changelog
* Thu Sep 16 2021 mockbuilder - 2.3.8-1
- Initial package