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. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
