Hi, Clark! A brief response from the office, and a longer one tonight when i get home...
On Mon, Jul 22, 2013 at 2:01 AM, Clark Christensen <cdcmi...@yahoo.com>wrote: > Scripting language: I understand the Tcl roots, and I hope you would > consider Javascript as a target. JS seems more universal these days. > Maybe the Tcl guys would disagree. I have no idea what that means from an > implementation standpoint. > The problem is the interpreter. i am not aware of a small embedable JS interpreter. SpiderMonkey/Jaegermonkey are complex and poorly documented. Google V8 is nice but (A) huge, (B) C++, and (C) they recently made drastic API changes which invalidated every single v8-using client out there (breaking 4-5 years of accumulated code of mine, and i'll never have the time to fix it), which means that very few people outside of Google can actually use v8 at the moment. JS _would_ also be my first choice, if we only had a small, well-maintained interpreter.i don't know TCL, but the TCL and Fossil communities seem to be cosmically bound to one another. There are relatively few well-established small/embeddable interpreters. Lua, TCL, ... none others come to mind (which are small). I use Fossil as much as a straight ticketing system almost as much as I do > as SCM. OK, maybe that's an exaggeration :-) In my company, doing > anything through channels takes an act of god. So being able to throw > together an ad-hoc issue tracker for a project in a matter of an hour is > valuable. So, in the ticketing subsystem, I'd like to see, in no > particular order: > * built-in persistent integer ticket numbers in addition to the SHA1 > ticket/artifact ID. The SHA1 hexdigest fragments are too geeky for > management during the weekly status meeting. > Stable incremental numbers are literally not possible to solve for DCVS systems, which is why the SHA's (geeky/unwieldy as they are) are used. > * persistent ticket create time built-into the ticket record. It's tough > to write aging reports without a create time. I know I can add it after > the fact. I just don't want to have to. > Certainly this data is there? (Maybe not as a concrete, field, though?) > * ticket event notifications, or a table where they're queued for some > other process to retrieve/send them. > This implies hooks, which basically implies scripting, so it's a few levels of abstraction away from being possible (but is certainly something to be looked at closely - this has been a long-requested feature). > Otherwise, Fossil as-is fulfills my needs pretty well. Though, > admittedly, my needs are relatively small at about 20 active project > repos. The projects themselves are relatively small Perl/JS/HTML/CSS apps > and the shared code to support them. > > Thanks for listening to me ramble :-)) > Please keep it coming - in my experience users provide far better ideas for new features than developers tend to. i'll answer in more detail tonight... -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
