#We can pipe commands into repl's stdin without the prompt interfering with the output.
#Although all command output for each line goes to stdout - not just what is emmited with puts
#Although all command output for each line goes to stdout - not just what is emitted with puts
if {$::tcl_interactive} {
flush stdout; #we are writing this prompt on stderr, but stdout could still be writing to screen
#our first char on stderr is based on the 'lastchar' of stdout which we have recorded but may not have arrived on screen.
#The issue we're trying to avoid is the (stderr)prompt arriving midway through a large stdout chunk
#REVIEW - this basic attempt to get stderr/stdout to cooperate is experimental and unlikely to achieve the desired effect
#note that our 'flush stdout' tcl call does not wait if stdout is non-blocking
#todo - investigate if the overhead is reasonable for a special channel that accepts stdout and stderr records with a reader to send to console in chunk-sizes we know will be emitted correctly
# - reader of such channel could be ok to be blocking (on read? on write to real channels?)... except everything still needs to be interruptable by things like signals?
#? - we want ordinary puts to stderr to be prioritized? to arrive on-screen - just not at arbitrary locations within stdout, and still must be correctly ordered wrt all other stderr
# - in our repl and code threads we don't want to put stderr/stdout writes in blocking mode and have code waiting on it
#does a dual git/fossil repo make sense if both are committing??
# see: https://fossil-scm.org/home/doc/trunk/www/inout.wiki for bidirectional sync info
proc workingdir_state {{abspath {}} args} {
#we should try to minimize executable calls
#an extra git/fossil executable call required for tags
#git seems to require more executable calls
set defaults [list\
-repotypes [list fossil git]\
-repopaths ""\
@ -408,6 +413,8 @@ namespace eval punk::repo {
set revision ""
set revision_iso8601 ""
set pathdict [dict create]
set branch ""
set tags ""
if {![llength $repotypes_to_query]} {
error "No tracking information available for project at $repodir with the chosen repotypes '$opt_repotypes'. Ensure project workingdir is a fossil (or git) checkout"
@ -437,6 +444,38 @@ namespace eval punk::repo {
}
set revision_iso8601 "${revision_ymd}T${revision_hms}${revision_tz}"
#REVIEW! what are the semantic difference between tags in fossil v git?
#fossil has tagtypes such as propagated and singleton(onetime)
#if we get all tag info for the revision - we can get the current branch (branch=somename tag) at the same time
#by retrieving with --raw - we have to process some prefixes such as sym- but probably best not done here
#we will return all tags that apply to the current revision and let the caller decide the meanings
if {![catch {punk::mix::util::do_in_path $repodir [list exec {*}$fossil_cmd tag ls --raw $revision]} cmdresult]} {
set branchinfo [lindex [grep {branch=*} $cmdresult] 0] ;#first line match - should only be one
set branch [lindex [split $branchinfo =] 1]
set tags [list]
foreach ln [split $cmdresult \n] {
if {[string trim $ln] eq ""} {
continue
}
lappend tags [string trim $ln]
}
}
#set tags_info [lindex [grep {tags:*} $fossilstate 0] ;#first line match - should only be one
set tags $cmdresult ;#review - we have short tags vs longer.. e.g v0.1a vs v0.1a-184-g856fab4 - which is returned? Also how are multiple separated?
}
#often there will be no tag - so the common case is actually an error "fatal: not ag exactly matchs 'xxxx...'"
# -- --- --- --- ---
#could use %ci for ISO8601 data - see git-show manpage, but this will be in timezone of developer's machine - we need it in UTC for comparison to fossil outputs and other devs
@ -600,6 +647,8 @@ namespace eval punk::repo {
puts stderr "workingdir_state - repotype $rt not supported"
}
}
dict set resultdict branch $branch
dict set resultdict tags $tags
dict set resultdict revision $revision
dict set resultdict revision_iso8601 $revision_iso8601
dict set resultdict paths $pathdict
@ -610,8 +659,13 @@ namespace eval punk::repo {
error "workingdir_state_summary error repostate doesn't appear to be a repostate dict. (use workingdir_state <path> to create)"
}
package require overtype
#the revision branch and tags are highly relevant to the file state - and workingdir_state currently retrieves them anyway
# - so we'll include them in the defaults
# - when we are including working dir state as part of other output - we could be duplicating branch/tag retrievals
# - todo - flags to stop duplicating effort ??
set defaults [dict create\
-fields {ahead behind unchanged changed new missing extra}\
#todo - something better - the 'channel' concept may not really apply on unix, as raw mode is for input and output modes
#todo - something better - the 'channel' concept may not really apply on unix, as raw mode is set for input and output modes currently - only valid to set on a readable channel?
#on windows they can be set independently (but not with stty) - REVIEW
#NOTE - the is_raw is only being set in current interp - but the channel is shared.
#this is problematic with the repl thread being separate. - must be a tsv? REVIEW
#todo - something better - the 'channel' concept may not really apply on unix, as raw mode is for input and output modes
#todo - something better - the 'channel' concept may not really apply on unix, as raw mode is set for input and output modes currently - only valid to set on a readable channel?
#on windows they can be set independently (but not with stty) - REVIEW
#NOTE - the is_raw is only being set in current interp - but the channel is shared.
#this is problematic with the repl thread being separate. - must be a tsv? REVIEW
Julian Noble
