[ast-developers] Branches in GitHub

[Siteshwar Vashisht]

Hello,

We are currently discussing the state of branches on GitHub[1]. I am thinking about :

* Merging beta branch into master and do the development in master.
* Remove both alpha and beta branches. Commits from alpha and beta branches can be tagged with respective git tags if required.

If you have any suggestions about it. Feel free to share it on GitHub or this mail thread.

[1] https://github.com/att/ast/issues/82

[Kurtis Rader]

Post by Siteshwar Vashisht
* Merging beta branch into master and do the development in master.
* Remove both alpha and beta branches. Commits from alpha and beta
branches can be tagged with respective git tags if required.

+1 to moving development from the "beta" to "master" branch as that seems
to be the most common git development model. And dropping both the "alpha"
and "beta" branch as they confuse people (e.g., me) and aren't needed at
this time given the current pace of development. We can always create
release specific branches or tags when that is needed.

[Kurtis Rader]

Post by Kurtis Rader

Post by Siteshwar Vashisht
* Merging beta branch into master and do the development in master.
* Remove both alpha and beta branches. Commits from alpha and beta
branches can be tagged with respective git tags if required.

+1 to moving development from the "beta" to "master" branch as that seems
to be the most common git development model. And dropping both the "alpha"
and "beta" branch as they confuse people (e.g., me) and aren't needed at
this time given the current pace of development. We can always create
release specific branches or tags when that is needed.

It's been a week and no one has commented on this proposal other than
myself. Nor has there been any feedback on the Github issues and PRs where
this proposal has been brought up. The key question isn't what SCM branches
(e.g., `beta`) should be more or less permanent fixtures of the project.
The key question is whether everything required to build ksh93 should be
split out from all the other AST code. Which would effectively ghettoize
the non ksh93 code.

Personally, I am only interested in ksh93. Not any of the other AST
commands. I have no interest in maintaining AST commands like `pax` since
every UNIX based OS provides a usable implementation that is being
maintained by others. I suspect my viewpoint is representative of the
majority of people. Given that https://github.com/att/ast/ is meant to
represent all the AST code a reasonable compromise may be to keep the
`master` branch representative of the entire code base and create a `ksh`
branch that eliminates all code not needed to build and test ksh. On the
other hand it may be better for the future of ksh if an `ast` branch that
includes everything is created and the `master` branch is stripped down to
the ksh code. Another option is to fork AST and in that fork strip out
everything not needed by the ksh program.

Please note that I do recognize there are people interested in the AST code
base as a whole. Most notably the Nmake build tools. The question is how
best to keep those people happy while maximizing the likelihood that ksh
will be a relevant, vibrant, shell in the future. Let the flame wars begin
:-)

[Jens Elkner]

Post by Kurtis Rader

Post by Kurtis Rader

Post by Siteshwar Vashisht
* Merging beta branch into master and do the development in master.
* Remove both alpha and beta branches. Commits from alpha and beta
branches can be tagged with respective git tags if required.

+1 to moving development from the "beta" to "master" branch as that seems
to be the most common git development model. And dropping both the "alpha"
and "beta" branch as they confuse people (e.g., me) and aren't needed at
this time given the current pace of development. We can always create
release specific branches or tags when that is needed.

+1

Post by Kurtis Rader
It's been a week and no one has commented on this proposal other than
myself. Nor has there been any feedback on the Github issues and PRs where

Just subscribed this week, because it is not that easy to find - I just
found a hint to an archived mail on mail-archive.com in an old issue. So
scimmed on mail-archive.com a little bit over the older stuff and
finally found a mail, that there is a mailman on lists.research.att.com
(and even so the web interface is down, it should work in "majordomo
mode" ;-)). 'til this time I assumed there is no ML at all and all stuff
gets discussed with gf (and dgk) directly ... So the silence isn't
really surprising I guess.

Post by Kurtis Rader
this proposal has been brought up. The key question isn't what SCM branches
(e.g., `beta`) should be more or less permanent fixtures of the project.
The key question is whether everything required to build ksh93 should be
split out from all the other AST code. Which would effectively ghettoize
the non ksh93 code.

Separate project for ksh93 would be IMHO fine and accelerate
development. [BTW: Is there any history available for the ast repo?
Asking because often looking at changes reveals some details why
something was done this way and not the other and may also give some
hints, where to look before one touches "this" thing ...]

Post by Kurtis Rader
Personally, I am only interested in ksh93. Not any of the other AST
commands. I have no interest in maintaining AST commands like `pax` since
every UNIX based OS provides a usable implementation that is being

Ehmmm, wrong! Everyone may provide a pax, but e.g. in case of Ubuntu
this is a piece of crap (basically bad mangled tar) and not POSIX
compatible (and I guess, all other Debian based distros have the same
problem) ... However, this is a different story, shouldn't prevent
putting ksh into a separate project.

Post by Kurtis Rader
maintained by others. I suspect my viewpoint is representative of the
majority of people. Given that https://github.com/att/ast/ is meant to
represent all the AST code a reasonable compromise may be to keep the
`master` branch representative of the entire code base and create a `ksh`
branch that eliminates all code not needed to build and test ksh. On the
other hand it may be better for the future of ksh if an `ast` branch that
includes everything is created and the `master` branch is stripped down to
the ksh code. Another option is to fork AST and in that fork strip out
everything not needed by the ksh program.

Hmmm, I don't see any benefit wrt. fork and cut. Since there is actually
no history of ksh, just the "inital" version canned into github alias
2012-08-01, you can actually start from scratch with the build system
you want and pull over and change step by step what is needed. When you
are done, you can tag it as e.g. 93.22.0 (i.e. this opportunity should be
used to switch over to semantic versioning) and merge over all related
patches applied to the ast/ast repo. This also allows, that people don't
need to wait 'til you are done, but can continue to work on ast/ast/
as is.

Have fun,
jel.

[Danny Weldon]

Before we decide this, I just commented on
https://github.com/att/ast/issues/42 hopefully a way to keep ast alive
to see what people think.

Here is an excerpt:

Therefore as an alternative, rather than changing build systems and
getting rid of nmake, how about:

Move ksh93 to it's own repo (att/ksh), but make it a git submodule
inside the ast repo.
So if someone wants to build the whole thing including ksh, they can simply run:

git clone --recursive https://github.com/att/ast

Then we create some ast OS packages for linux, freebsd, osx, etc such as:

ast lib (libraries)
ast devel (headers)
ast nmake (nmake, probe, iffe and their definition files)
ast commands (any other commands, but not ksh)

Then make travis for the ast repo just build the ast library and
packages and copy them somewhere to be uploaded as github downloads.

Then, the travis build for ast/ksh repo only has to install the ast
library, headers, nmake etc. from the packages and just focus on
building ksh. I'm sure that would speed things up the most, as it
would skip building all of ast, which I'm sure you will still have to
do if you move everything to another build system.

Then if anyone cares, they can work on improving nmake inside att/ast:

- updating the probes
- make it able to run on multiple cores
- caching of probe results (to speed up duplicate probes)
- improving documentation

While the rest of us can simply install the ast packages on our
machines and just focus on building att/ksh, which should build in
under a minute from scratch, or 6 seconds after updating a file.

Unless it is possible to add CMake/meson alongside the current build
system, which I doubt because I think the conditional includes inside
the source may have to change, perhaps then you could just switch the
ksh repo over to CMake/meson. It would still rely on the ast library,
but would only need to build ksh.

Or, split the repos like I suggest above, but convert both to
CMake/meson leaving the nmake and supporting code intact, but not
being used by the project itself any more.

WRT moving ksh to it's own repo, any ksh related issues in the ast
repo can be closed and reopened in the ksh repo with links back to
each other.

[Siteshwar Vashisht]

----- Original Message -----

Sent: Sunday, November 5, 2017 11:08:01 AM
Subject: Re: [ast-developers] Branches in GitHub
Before we decide this, I just commented on
https://github.com/att/ast/issues/42 hopefully a way to keep ast alive
to see what people think.
Therefore as an alternative, rather than changing build systems and

Why the build system should not be changed ? I can understand the decision to use it earlier but I don't see it as a good option going forward.

Move ksh93 to it's own repo (att/ksh), but make it a git submodule
inside the ast repo.
git clone --recursive https://github.com/att/ast
ast lib (libraries)
ast devel (headers)
ast nmake (nmake, probe, iffe and their definition files)
ast commands (any other commands, but not ksh)
Then make travis for the ast repo just build the ast library and
packages and copy them somewhere to be uploaded as github downloads.
Then, the travis build for ast/ksh repo only has to install the ast
library, headers, nmake etc. from the packages and just focus on
building ksh. I'm sure that would speed things up the most, as it
would skip building all of ast, which I'm sure you will still have to
do if you move everything to another build system.
- updating the probes
- make it able to run on multiple cores
- caching of probe results (to speed up duplicate probes)
- improving documentation

There are better tools to do the same job. It is worth an effort to switching to those tools instead of trying to improve existing ones.

While the rest of us can simply install the ast packages on our
machines and just focus on building att/ksh, which should build in
under a minute from scratch, or 6 seconds after updating a file.
Unless it is possible to add CMake/meson alongside the current build
system, which I doubt because I think the conditional includes inside
the source may have to change, perhaps then you could just switch the
ksh repo over to CMake/meson. It would still rely on the ast library,
but would only need to build ksh.
Or, split the repos like I suggest above, but convert both to
CMake/meson leaving the nmake and supporting code intact, but not
being used by the project itself any more.

That's what I would suggest, but instead of creating new repository we should create a new branch (for e.g. we can name it ast-full). All the code which was open sourced by AT&T under AST project will be available in this branch. We can do low maintenace fixes to it (for e.g. build fixes). I don't see any problems with this approach as it will keep the old code working, just under a different branch.

WRT moving ksh to it's own repo, any ksh related issues in the ast
repo can be closed and reopened in the ksh repo with links back to
each other.

We lose all the references to existing issues in commits etc. The effort to copy related issues to new repository is not worth it.

_______________________________________________
ast-developers mailing list
http://lists.research.att.com/mailman/listinfo/ast-developers

[Kurtis Rader]

Post by Siteshwar Vashisht
----- Original Message -----

Post by Danny Weldon
Therefore as an alternative, rather than changing build systems and

Why the build system should not be changed ? I can understand the decision
to use it earlier but I don't see it as a good option going forward.

Post by Danny Weldon
[some text by Danny about splitting out things like AST Nmake and libs

into their own packages elided]

Post by Danny Weldon
- updating the probes
- make it able to run on multiple cores
- caching of probe results (to speed up duplicate probes)
- improving documentation

There are better tools to do the same job. It is worth an effort to
switching to those tools instead of trying to improve existing ones

I wholeheartedly agree with Siteshwar. I don't doubt that at the time Nmake
was created and was still being actively maintained it was far superior to
the other options. It's certainly better than GNU autotools. But that is no
longer true. More importantly the probability that Nmake will be used by as
many projects as Cmake or Meson, even if we made the improvements suggested
by Danny, is so close to zero it's not worth arguing about.

Post by Siteshwar Vashisht

Post by Danny Weldon
Or, split the repos like I suggest above, but convert both to
CMake/meson leaving the nmake and supporting code intact, but not
being used by the project itself any more.

Danny, are you volunteering to implement Cmake or Meson for the non-ksh93
code? Because I'm not interested in doing that work. And I doubt anyone
else is either. The people using the non-ksh93 portions of this project are
likely to be uninterested in changing the build system. If the feedback
I've seen in this thread and the related Github issues is any indication.

Post by Siteshwar Vashisht
That's what I would suggest, but instead of creating new repository we
should create a new branch (for e.g. we can name it ast-full). All the code
which was open sourced by AT&T under AST project will be available in this
branch. We can do low maintenace fixes to it (for e.g. build fixes). I
don't see any problems with this approach as it will keep the old code
working, just under a different branch.

I'd like to move ahead with this proposal. Some people seem to be confused
by the current situation where changes are being committed to the beta
branch that either do, or potentially may, break projects that depend on
the current AST libraries. It's also a PITA to have to remember to tell
Github that a commit is based on AST/beta rather than AST/master when
creating a pull-request.

[Kurtis Rader]

Post by Danny Weldon
Before we decide this, I just commented on
https://github.com/att/ast/issues/42 hopefully a way to keep ast alive
to see what people think.
Therefore as an alternative, rather than changing build systems and
getting rid of nmake, how about: ....

That is an extremely bold proposal. As you alluded to there is a bit of a
chicken and egg problem. Ksh93 source in its current form cannot be built
independent of large chunks of the AST code base. So to be able to build
just ksh93 you first have to build and package the rest of the AST project
so that it is available to the ksh93 project on Linux, FreeBSD, macOS (via
Homebrew), etc. If someone steps up and does that work that would be great.
The question is whether there is anyone motivated to do that work. And even
if it were done it would make it difficult to modernize the ksh93 code by
removing support for things like K&R compilers.

[Jens Elkner]

Post by Kurtis Rader

Post by Danny Weldon
Before we decide this, I just commented on
https://github.com/att/ast/issues/42 hopefully a way to keep ast alive
to see what people think.
Therefore as an alternative, rather than changing build systems and
getting rid of nmake, how about: ....

That is an extremely bold proposal. As you alluded to there is a bit of a
chicken and egg problem. Ksh93 source in its current form cannot be built
independent of large chunks of the AST code base. So to be able to build

No, wrong! As said, just building the INIT "package" is sufficient:
It provides the basic stuff to be able to build ksh93 - see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/init-file-lst.diff

However, if the intent is to switch to a different build system, most of
this stuff is probably not needed anymore, because I guess a smart
approach would be to use, what tooling the new system provides and
adhere to its "standards".

Therefore I don't like the idea at all, to branch or sub-repo ksh on
ast/ast. I prefer a clean self-contained, independend ast/ksh repo -
using a tree structure for src etc. , that goes hand-in-hand with the
new build system and does not need to tweak several defaults etc, just
to be able to use the structure of the old/obsolete build system (INIT),
which doesn't/shouldn't get used anyway ...

And as said: because there seems to be no ksh93 history, nothing gets
lost, if one starts with what has been initially released, i.e. the
files from 2012-08-01 (but of course not with all the bloat but only,
what is really needed) - e.g. see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/ksh-src-file.lst and
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/ksh-built-file.lst

(To keep alias dup/mv the github issues over to the new repo, I'm pretty
sure, that github support is able to give some hints, how to do that or
they do it by themselves).

Have fun,
jel.

[Kurtis Rader]

Post by Jens Elkner

Post by Kurtis Rader
That is an extremely bold proposal. As you alluded to there is a bit of a
chicken and egg problem. Ksh93 source in its current form cannot be built
independent of large chunks of the AST code base. So to be able to build

It provides the basic stuff to be able to build ksh93 - see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/init-file-lst.diff
...

And as said: because there seems to be no ksh93 history, nothing gets

Post by Jens Elkner
lost, if one starts with what has been initially released, i.e. the
files from 2012-08-01 (but of course not with all the bloat but only,
what is really needed) - e.g. see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/ksh-src-file.lst

I recognize that because Jens is German and thus English is not their
native language I may have difficulty understanding some of the points they
are making. But I'm pretty certain I have a good grasp of the dependencies
needed to build ksh93. And stating that "the INIT package is sufficient" is
sophistry that in no way negates my point.

Notice that ksh-src-file.lst in the link above contains a large amount of
code from src/lib/libast, src/lib/libcmd, src/lib/libdll, etc. Which is
precisely my point. The fact that those files are dependencies of the
"INIT" package, and therefore do not need to be individually enumerated if
you simply state that building ksh93 only needs to depend on the "INIT"
package, is irrelevant to my point. Which is that huge chunks of the AST
code base is needed to build ksh93. That list also seems to be missing some
other dependencies that are needed, at least when not building on Solaris,
such as the src/cmd/msgcc and src/lib/libcodex directories.

Also, I didn't check but I'm betting there are items missing from that list
which are needed for the unit tests. Too, a lot of that code (e.g., the AST
malloc subsystem) should be replaced by the same facility provided by the
libraries of the operating system (e.g., libc). Thus eliminating the
dependency on the AST code that provides that functionality. Which allows
us to remove it from the AST source dependencies to build ksh93. Which in
turn reduces the amount of code that needs to be compiled from scratch when
building ksh93. And reduces the amount of code that has to be maintained to
keep ksh93 working.

P.S., I'm also confused by entries like "ksh/lib/package/ast-ksh.README" in
the file linked to above. They're not in the source tree and not generated
when I build ksh93. I suspect those are artifacts of building on Solaris
and thus irrelevant to this discussion.

[Danny Weldon]

Danny, are you volunteering to implement Cmake or Meson for the non-ksh93 code?

Sorry, I don't have the free time at my disposal and it probably is a
*lot* of work for little gain and that would take away from ksh
development itself, which is why my proposal was to separate it out
and leave it as is.

Anyway, I thought I would put my proposal out there, but if no-one
wants to do it that way, that's fine.

Whether the new ast+ksh code then is the new master or a separate repo
I don't care, either way.

To decrease build times perhaps some work could be done to make the
iffe probing be done in parallel.

That is an extremely bold proposal. As you alluded to there is a bit of a
chicken and egg problem. Ksh93 source in its current form cannot be built
independent of large chunks of the AST code base. So to be able to build
just ksh93 you first have to build and package the rest of the AST project
so that it is available to the ksh93 project on Linux, FreeBSD, macOS
(via Homebrew), etc. If someone steps up and does that work that would
be great. The question is whether there is anyone motivated to do that
work. And even if it were done it would make it difficult to modernize
the ksh93 code by removing support for things like K&R compilers.

bin/package has some support for building packages but as you say, it
would need updating for all those OS's. It doesn't sound too
difficult and would be done in lib/package/package.mk. I'm not sure I
understand why it would not be possible to remove support for K&R
compilers.

[Jens Elkner]

Post by Jens Elkner

Post by Jens Elkner

Post by Kurtis Rader
That is an extremely bold proposal. As you alluded to there is a bit of a
chicken and egg problem. Ksh93 source in its current form cannot be built
independent of large chunks of the AST code base. So to be able to build

It provides the basic stuff to be able to build ksh93 - see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/init-file-lst.diff
...

And as said: because there seems to be no ksh93 history, nothing gets

Post by Jens Elkner
lost, if one starts with what has been initially released, i.e. the
files from 2012-08-01 (but of course not with all the bloat but only,
what is really needed) - e.g. see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/ksh-src-file.lst

I recognize that because Jens is German and thus English is not their
native language I may have difficulty understanding some of the points they
are making. But I'm pretty certain I have a good grasp of the dependencies
needed to build ksh93. And stating that "the INIT package is sufficient" is
sophistry that in no way negates my point.

Well, I think, a good engineer should at least read the READMEs bundled
with the software he/she is gonna change in a dramtic way. IMHO reading
related documentation is essential to do a proper work, understand the
SW and its build system at least at a basic level and avoids postulating
wrong assumptions again and again!

Post by Jens Elkner
Notice that ksh-src-file.lst in the link above contains a large amount of
code from src/lib/libast, src/lib/libcmd, src/lib/libdll, etc. Which is
precisely my point. The fact that those files are dependencies of the
"INIT" package, and therefore do not need to be individually enumerated if
you simply state that building ksh93 only needs to depend on the "INIT"
package, is irrelevant to my point. Which is that huge chunks of the AST
code base is needed to build ksh93. That list also seems to be missing some

You are wrong, again! As said dozen? of times, the INIT and ast-ksh package
is all one needs to build ksh93! To understand this perhaps a little bit
better, I've digged out a Build script in my junk yard, which shows, how
I actually did it on linux systems in 2000+:
http://iks.cs.ovgu.de/~elkner/ksh.static/Build.sh

However, IMHO a good engineer reads the software's documentation
carefully, before starting to change it in a more or less dramtic way
and would have found out these more or less simple things by itself.
However, a good start (beside the bundled READMEs) would be e.g.:
https://web.archive.org/web/20150527152443/http://www2.research.att.com/~astopen/download/
or - available via the 'source install' menu point on the left side of
this page:
https://web.archive.org/web/20150527152549/http://www2.research.att.com/~astopen/download/gen/SOURCE.html

Post by Jens Elkner
other dependencies that are needed, at least when not building on Solaris,
such as the src/cmd/msgcc and src/lib/libcodex directories.
Also, I didn't check but I'm betting there are items missing from that list
which are needed for the unit tests. Too, a lot of that code (e.g., the AST
malloc subsystem) should be replaced by the same facility provided by the
libraries of the operating system (e.g., libc). Thus eliminating the
dependency on the AST code that provides that functionality. Which allows
us to remove it from the AST source dependencies to build ksh93. Which in
turn reduces the amount of code that needs to be compiled from scratch when
building ksh93. And reduces the amount of code that has to be maintained to
keep ksh93 working.

Well, optimizing is good. But first understanding, what the current
build system is doing, is better. I'm also excited in what you are coming
up with, but when seeing your current work, I get very mixed feelings ...

Post by Jens Elkner
P.S., I'm also confused by entries like "ksh/lib/package/ast-ksh.README" in
the file linked to above. They're not in the source tree and not generated
when I build ksh93. I suspect those are artifacts of building on Solaris
and thus irrelevant to this discussion.

Nope - as said, reading/understanding the docs of the software one is
going to mangle is usually one possible point of success. Wrt. the mentioned
wrong assumption you should 'bin/package --man' and optionally have a
look at lib/package/package.mk (and knowing, that a good instructor
wouldn't do this, I even give you the shortcut: lib/package/ast-open.README).
Last but not least I've already posted a script on github, which shows
the Q&D way to generate it (inkl. comments) - IIRC your comment was
"what I am supposed to do with that script ...". 'Reading it' is probably a
good answer ...

Have fun,
jel.

[Kurtis Rader]

Post by Jens Elkner

Post by Kurtis Rader
Another option is to fork AST and in that fork strip out
everything not needed by the ksh program.

Hmmm, I don't see any benefit wrt. fork and cut. Since there is actually
no history of ksh, just the "inital" version canned into github alias
2012-08-01, you can actually start from scratch with the build system
you want and pull over and change step by step what is needed. When you
are done, you can tag it as e.g. 93.22.0 (i.e. this opportunity should be
used to switch over to semantic versioning) and merge over all related
patches applied to the ast/ast repo. This also allows, that people don't
need to wait 'til you are done, but can continue to work on ast/ast/
as is.

The intent of creating a ksh93 only branch (or fork) is to make it easier
to perform a multitude of cleanup activities and improvements. Such as
removing support for pre ANSI C compilers. Running the code through
clang-format to normalize the style. Implement build rules for tools like
cppcheck, oclint, and iwyu. And then actually address the issues those
tools point out. Also, change to a modern build system like Cmake or Meson.
Etcetera. If we have to do all of that for the entire AST project then
that is significantly more work. As wonderful as the rest of the AST code
may be the reality is that it isn't going to be adopted by distros.

[Siteshwar Vashisht]

----- Original Message -----

Sent: Friday, October 27, 2017 11:24:40 AM
Subject: [ast-developers] Branches in GitHub
Hello,
* Merging beta branch into master and do the development in master.
* Remove both alpha and beta branches. Commits from alpha and beta branches
can be tagged with respective git tags if required.

I have created 2 new branches in the GitHub project:

1. '2012-08-01-master' branch[1] contains the current master branch. It is the last stable release. I have cherry-picked one change[2] into it to allow building on Linux.
2. '2016-01-10-beta' branch[3] contains last beta release and number of patches that were later added on top of it. I have forked it from last commit from beta branch before we started removing code.

This should allow the old code to keep working.

[1] https://github.com/att/ast/commits/2012-08-01-master
[2] https://github.com/att/ast/commit/e79c29295092fe2b2282d134e2b7cce32ec9dcac
[3] https://github.com/att/ast/commits/2016-01-10-beta

If you have any suggestions about it. Feel free to share it on GitHub or this mail thread.
[1] https://github.com/att/ast/issues/82
--
--
Siteshwar Vashisht
_______________________________________________
ast-developers mailing list
http://lists.research.att.com/mailman/listinfo/ast-developers

[EDGAR, ADAM]

With all this back and forth about branching ksh away from AST so it can be more easily be built we may be losing sight on a bigger issue. Right now many projected derived from some core AST functions have divergent versions of core libraries. The most obvious to me is cdt. Container Data Types is used heavily throughout AST to handle sets, lists, associative arrays and more. At AT&T we use it heavily in the vcodex/vczip data compression/transform system. It is also used by graphviz which is maintained externally to AT&T and AST now.

In order to avoid having multiple versions of core AST libraries on a system we should really be looking at providing a method of building and packaging the libraries in a more standard way. Doing so would not only clean up the dependency version mismatches but may provide reasons for other projects to use the powerful libraries developed over the years.

Personally, I’d like to see at least a CDT package (rpm or deb) and a vcodex package upon which ksh is built. I believe the way most packages are done there would be two packages for all libs. One with the .so files and another with .a .h and man files.

ASE


On 11/9/17, 2:39 PM, "ast-developers-***@lists.research.att.com on behalf of Siteshwar Vashisht" <ast-developers-***@lists.research.att.com on behalf of ***@redhat.com> wrote:



----- Original Message -----

Sent: Friday, October 27, 2017 11:24:40 AM
Subject: [ast-developers] Branches in GitHub
Hello,
We are currently discussing the state of branches on GitHub[1]. I am thinking
* Merging beta branch into master and do the development in master.
* Remove both alpha and beta branches. Commits from alpha and beta branches
can be tagged with respective git tags if required.

I have created 2 new branches in the GitHub project:

1. '2012-08-01-master' branch[1] contains the current master branch. It is the last stable release. I have cherry-picked one change[2] into it to allow building on Linux.
2. '2016-01-10-beta' branch[3] contains last beta release and number of patches that were later added on top of it. I have forked it from last commit from beta branch before we started removing code.

This should allow the old code to keep working.

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_att_ast_commits_2012-2D08-2D01-2Dmaster&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=2fZ9T41d9aranXLhOLJhmw&m=KFfowxv-ERrq1htS2FMBTt_jymJwDGirJJb9sd-WUFE&s=m6fG1MJQ-SfzBUjqpd9VkHhWuLN4MGsyysmn8MFW5oo&e=
[2] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_att_ast_commit_e79c29295092fe2b2282d134e2b7cce32ec9dcac&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=2fZ9T41d9aranXLhOLJhmw&m=KFfowxv-ERrq1htS2FMBTt_jymJwDGirJJb9sd-WUFE&s=VEanmsPTNWgzONiczbTkjaKb6Docoj9dsPF4Q-yXj7U&e=
[3] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_att_ast_commits_2016-2D01-2D10-2Dbeta&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=2fZ9T41d9aranXLhOLJhmw&m=KFfowxv-ERrq1htS2FMBTt_jymJwDGirJJb9sd-WUFE&s=nJpoIAGsHZ17kEYv-vI7fbnhE3et__EBVIFI1I_sXts&e=

If you have any suggestions about it. Feel free to share it on GitHub or this
mail thread.
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_att_ast_issues_82&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=2fZ9T41d9aranXLhOLJhmw&m=KFfowxv-ERrq1htS2FMBTt_jymJwDGirJJb9sd-WUFE&s=k1SmLzwwAEdN4HZ2fS0V_1vTI7ExN5JCrVkgrgDR5-Q&e=
--
--
Siteshwar Vashisht
_______________________________________________
ast-developers mailing list
http://lists.research.att.com/mailman/listinfo/ast-developers

--
--
Siteshwar Vashisht
_______________________________________________
ast-developers mailing list
ast-***@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers

[Kurtis Rader]

Post by EDGAR, ADAM
With all this back and forth about branching ksh away from AST so it can
be more easily be built we may be losing sight on a bigger issue. Right
now many projected derived from some core AST functions have divergent
versions of core libraries. The most obvious to me is cdt. Container Data
Types is used heavily throughout AST to handle sets, lists, associative
arrays and more. At AT&T we use it heavily in the vcodex/vczip data
compression/transform system. It is also used by graphviz which is
maintained externally to AT&T and AST now.
In order to avoid having multiple versions of core AST libraries on a
system we should really be looking at providing a method of building and
packaging the libraries in a more standard way. Doing so would not only
clean up the dependency version mismatches but may provide reasons for
other projects to use the powerful libraries developed over the years.
Personally, I’d like to see at least a CDT package (rpm or deb) and a
vcodex package upon which ksh is built. I believe the way most packages
are done there would be two packages for all libs. One with the .so files
and another with .a .h and man files.

Thank you, Adam, for taking the time to provide a thoughtful response. Your
reply suggests that I, and others focused on the `ksh` command, may not
have a good grasp of how the non-Korn shell code in the AST project is
being used. But I am perplexed by your reference to the graphviz project (
http://www.graphviz.org/Download_source.php). AFAICT it does not depend on
an externally packaged AST library. Nor can I find any libraries available
on Linux or macOS (via Homebrew) that provide subsets of the AST code. Feel
free to tell me I am stupid for missing the obvious.

I have no doubt that within AT&T there is extensive use of non-ksh related
code found in the Github, https://github.com/att/ast/, project. The
question is whether there is a non-trivial number of such uses in other
projects.

[Jens Elkner]

Post by Kurtis Rader

Post by EDGAR, ADAM
With all this back and forth about branching ksh away from AST so it can
be more easily be built we may be losing sight on a bigger issue. Right
now many projected derived from some core AST functions have divergent
versions of core libraries. The most obvious to me is cdt. Container Data
Types is used heavily throughout AST to handle sets, lists, associative
arrays and more. At AT&T we use it heavily in the vcodex/vczip data
compression/transform system. It is also used by graphviz which is
maintained externally to AT&T and AST now.

...

Post by Kurtis Rader
being used. But I am perplexed by your reference to the graphviz project (
http://www.graphviz.org/Download_source.php). AFAICT it does not depend on
an externally packaged AST library. Nor can I find any libraries available
on Linux or macOS (via Homebrew) that provide subsets of the AST code. Feel
free to tell me I am stupid for missing the obvious.

Kurtis, I'm wondering, why you are not doing your homework, before
replying to comments etc.? What about
https://github.com/ellson/MOTHBALLED-graphviz/tree/master/lib/cdt ?
Are 5 min really too much time to invest?

Post by Kurtis Rader
I have no doubt that within AT&T there is extensive use of non-ksh related
code found in the Github, https://github.com/att/ast/, project. The
question is whether there is a non-trivial number of such uses in other
projects.

It does not matter at all. It is used - and even if not yet, than
perhaps later. Just because you do not know, you have IMHO not the right
to burn it down - deny access to it.

Have fun,
jel.