On Wed, 7 Aug 2013 21:00:45 +0200 Irek Szczesniak wrote:
> On Wed, Aug 7, 2013 at 8:56 PM, Glenn Fowler <[email protected]> wrote:
> >
> > On Wed, 7 Aug 2013 20:34:55 +0200 Irek Szczesniak wrote:
> >> On Wed, Aug 7, 2013 at 3:21 PM, Glenn Fowler <[email protected]> wrote:
> >> >
> >> > the AT&T Software Technology ast alpha 2013-08-07 source release
> >> > has been posted to the download site
> >> > http://www.research.att.com/sw/download/alpha/
> >> > the package names and md5 checksums are
> >> > INIT 47f2073fae4b73fe5210cc4e287556ca
> >> > ast-open e6927faa687a2af8ee94431b793c08ac
> >> > ast-ksh 43b7379fdf573811c66f41ce231cbac0
> >> > the md5 sums should match the ones listed on the download page
> >> >
> >> > still tracking down build problems and regressions on some systems /
> >> > compilers
> >> > *in general no new features until then*
> >> > except for ksh93v- and features required to fix problems and regressions
> >> >
> >> > our macos now has clang as the default cc so playing nice with it is at
> >> > the top of the list
> >> >
> >> > why so many problems and regressions?
> >> > adding patches is easy
> >> > getting them right is hard
> >> > especially the ones that require emulation
> >> >
> >> > fus3d is a work in progress replacement for 3d -- still missing some
> >> > features
> >> >
> >> > changes since 2013-07-27
> >> >
> >> > :::::::: gzip ::::::::
> >> >
> >> > 13-07-30 gzip.c: 6 now default compression level (same as gzip(1)) for
> >> > 5x time savings for negligible size in some cases
> >> >
> >> > :::::::: fus3d ::::::::
> >> >
> >> > 2013-07-29 snarf from amazing dr.ek, ast-ize, and its alive
> >> >
> >> > :::::::: ksh93 ::::::::
> >> >
> >> > 13-08-05 --- Release ksh93v- ---
> >> > 13-08-05 Fix a bug in which read -C could reference uninitialized
> >> > memory.
> >> > 13-07-31 Fixed a bug with index arrays of short integer types in arrays
> >> > inside types that could lead to a core dump.
> >> > 13-07-30 Fixed a bug with short integer arithemtic that could lead to a
> >> > core dump.
> >> > 13-07-30 +An experimental change to each enumeration variable have
> >> > subvariables
> >> > for each enumeration constant. ${enum.name} will expand to the
> >> > numerical value of the enumeration name associatied with enum.
> >> > 13-07-30 +An experimental change to allow ${foo.__} to expand to the
> >> > parent
> >> > node for foo, or foo if foo doesn't have a parent. There are
> >> > no
> >> > regression tests for .__ yet.
> >> >
> >> > :::::::: setid ::::::::
> >> >
> >> > 13-07-31 first release
> >> >
> >> > :::::::: tw ::::::::
> >> >
> >> > 13-08-02 find: add { -show -delete } for gnu/sol compatibility
> >> >
> >> > :::::::: libast ::::::::
> >> >
> >> > 13-08-06 tm/tvsleep.c: fix interrupted select() remaining time logic
> >> > 13-08-06 path/pathopen.c,pathdev.c: handle /dev/fd/ dir pseudo stat
> >> > 13-08-05 vmalloc/malloc.c: add VMALLOC_OPTIONS=usage => VM_usage
> >> > 13-08-01 path/pathopen.c: fix /dev/fd/<fd>/trailing-path bug that missed
> >> > trailing-path
> >> > 13-07-31 features/lib: add setregid
> >> > 13-07-29 vmalloc/vmdcsystem.c: add EINTR restart checks for system
> >> > getmemory
> >
> >> fgetcwd() is missing.
> >
> >> While I do understand the conservative approach I'd value it if
> >> standalone api changes, those which add new features and don't
> >> interfere with existing code, would be adopted faster during the
> >> alpha/beta cycle. Sometimes the lack of development schedule
> >> performance causes me to rip out my hairs, quite literally. Just
> >> saying that as the diff we use at GE Healthcare to patch ksh93 is
> >> nearly as large as the ast-ksh sources. And that's not a good sign.
> >
> > sorry about the size of the diffs
> > if there were only one target that would be true
> > but with multiple targets even a change like adding fgetcwd() can burn a
> > full day
> > since its my days being burned I lean towards build stability first
> > then new features
> Why does it take a *full day* to do that? I'm sometimes amazed where
> the time is spend, but please surprise me: Why does it take a day?
> Typically for big projects like kernel.org (Linux kernel, which is way
> way larger than AST) you stage a patch and kick off the automated
> build and test systems to collect feedback from all platforms. That
> hardly takes 2-3 hours, but not a day.
the build on the master source host is easy
then one command syncs the source on the build farm and builds
24 hosts => 37 different arch's -- diff cc / options / 32 vs 64 bit /
etc
most hosts finish in 1 to 15 minutes depending on the change
touching some headers => more recompilation
then one command to run the regression tests
then one command to view the regressions
so there's your hardly 2 hours
now add in the time to deal with build failures:
* header contention between ast / cc / native
* symbol contention between ast / cc / native static and dynamic libs
* new compiler error / warnings
suppose just one host fails
remediation involves:
* debug changes on the failed host
* move changes back to master host
* restart from the top
add in
* "ast is not gsf/dgk's only job"
* only change a few things at a time before hitting the farm to keep sanity
* code review patches to see if parts are already done in ast
and days start vaporizing
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
