Re: [fossil-users] Meta-enhancement
On Jun 28, 2018, at 8:53 PM, David Mason wrote: > > Looks nice. What I meant was: what do I have to change to make it work. Clone my repository, go into Fossil UI, then navigate to Admin > Tickets. Copy as much or as little of what you see there into your Admin > Tickets sections as makes sense for your your purposes. Then do the same for Admin > Skins. At minimum here, you’ll want my Bugs and Wish List button changes. You need to copy from a local clone because you won’t be able to get into my repository’s Admin section via my public Fossil instance, lacking admin privileges on that instance. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Meta-enhancement
Looks nice. What I meant was: what do I have to change to make it work. Thanks ../Dave On 28 June 2018 at 18:33, Warren Young wrote: > On Jun 28, 2018, at 6:15 AM, David Mason wrote: > > > > where did you make these changes? > > It’s most readily seen in this repository: > > https://tangentsoft.com/pidp8i > > In addition to the reporting changes I previously described, there are > others, mainly in Admin > Tickets > Common. For instance, my > resolution_choices list includes the nonstandard “Implemented” choice, > which I use instead of “Fixed” when I finish implementing a feature request > ticket. > > Further thoughts on this topic: > > Features do sometimes jump multiple levels. For instance, an idea that > was once just a good idea — “Medium” in my system — may eventually be > deemed essential and thus jump straight to Immediate priority. > > Features sometimes also fall multiple levels. A person filing a feature > request might have what he thinks is a really hot idea (“High”) but when we > later go through the release planning exercise, management may think it’s a > bad idea for some reason, so it drops to Low rather than being deleted. We > may add a comment on reprioritizing at this point to record who spiked the > idea, so we know who has to be convinced if the idea comes back up again. > > The High priority pool rarely drains, even immediately after planning the > next release. We have more great ideas than time to implement them. We > just hope to get to those ideas before the world changes enough that the > feature ideas become worthless, in which case we need more developers: > we’ve left fruit on the tree. > > The Medium pool never drains until the project planners run out of good > ideas, at which point it’s time to mothball the project. > > If the Low pool ever drains, it probably means you’re not capturing enough > of the organization’s knowledge in Fossil. After enough member turnover, > the organization will forget things it should remember. > > “Low” may be an idea graveyard in a private repository, but in a public > repo, it is where features that the core developers are unlikely to get to > land. This pool is a good place to point outside contributors, since > they’re ideas worth keeping but they’re unlikely to conflict with a core > developer’s plans. That’s not an exclusive characterization: Medium will > have more such ideas, just with a higher risk that some core developer has > his eye on it and has plans to get to it someday. > > Fossil’s ticketing system is really quite flexible. There’s a good chance > you don’t have to accept things you don’t like about it: the fix might be > easily accomplished. > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 2018-06-28 12:49, Chad Perrin wrote:
Server side syntax highlighting is an excellent idea, though I'm not
quite sure at this time how to implement it. The other issue with such
being that fossil would basically need to cache the results of running
a highlight for the liftime of the program up until something
invalidates the cache. Line numbering does/will need serious work to
integrate with syntax highlighting regardless of the approach.
Yeah, that'd probably be more work overall, and would likely reduce the
customization for syntax highlighting allowed to people deploying
Fossil
repositories to the web. It would make how line numbering and syntax
highlighting integrate much more "deterministic", though, in that
Fossil
devs would have a clearer view of everything that happens when trying
to
account for it in updates to Fossil source. It's a trade-off, as with
most such decisions.
I'm not sure syntax highlighting is Fossil's task, though integrating
easily with other things that do syntax highlighting sounds like it is
something of benefit to Fossil. That said, I would not want to be
responsible for writing syntax parsers in C so as to generate pretty
content. It might be horrible to offload this to the client via JS,
but that might actually be the best solution just because it keeps
Fossil flexible.
> Thus, you would have HTML for a line of code that looks something
> like this (using a totally made-up function as example code):
>
>
> $num
>
> uint16_t get_next() {
>
>
Basically how GitHub and several other things implement it.
I guess my intuition about how to handle it is in good company, for
some
definition of "good".
The way GitHub does it is fine, however, they have existed before
something of the power of CSS line counters existed likely. Either that
or they tried such an approach and found an issue that I can't think of
at the moment. This will see more addressed a bit further down.
The issue with just applying highlights first is how will line endings
be tracked since html elements need not necessarily be rendered
similarly by all highlighting libraries. Detecting line endings in a
generic way after markup has been applied will be very difficult and
likely library specific. I keep using Prism.js as my goto for
illustration but I would bet that the differences between hljs and
prism are enough that the JS needing to be written to (hopefully)
detect marked up line endings between them would be different and we
get into a "supports $library" case vs a generic case like it has been
so far without syntax highlights and how it'd remain if we didn't go
forward with syntax highlighting when lines are numbered.
If you mean that syntax highlighting libraries might insert literal
newlines into the file when marking it up for highlighting, that's
pretty awful, and could indeed screw up the whole exercise.
I mean that a syntax highlighting library can do it however it likes
and while I'd think most wouldn't insert a literal newline, I might not
think I could plausibly count on `` to be a consistent method
guaranteeing numbering. The other problem is if the syntax highlighter
fails halfway through but doesn't undo it's work, leaving things
partially highlighted you're in for some confusion in the JS you write
yourself. This might not be common but it is quite possible.
We still would end up depending on the "Line numbers" checkbox being a
call into JS to add those in for everything but the server-side case.
I'd rather not have to write JS to try to target 2 different
highlighting engines (or possibly more dependent upon what other users
prefer). Then that means that we'd need to check the JS code written
against say... the latest 3 versions of each highlighting engine in
our "support list". At that point it could be said that our hold ups
in deploying a new version are tied up in making sure integration with
several external resources will move along properly. We'd also get
into a case of saying "supports up to $version_number of this library"
(and more of those statements for other libraries supported). At this
point I came to the conclusion it's a huge undertaking and would
require extensive long term management, and believe at that point, it
might be best to "bless" a certain syntax highlighting library and
forgo anything else. If that library was included in fossil, then
wouldn't need to worry about having to possibly push a fix to allow
the newest version to work.
This pretty much makes the detriments of a server-side approach that I
described earlier apply to the client-side approach, too. There are
other concerns that apply to the server-side, too, though, such as the
fact I suspect more rewriting of Fossil source would be required,
though
I'm just guessing at this point. I'm beginning to think that the best
approach might be to ship a JS syntax highlighting library with Fossil,
or just bless a single library, and allow people d
Re: [fossil-users] Meta-enhancement
On Jun 28, 2018, at 6:15 AM, David Mason wrote: > > where did you make these changes? It’s most readily seen in this repository: https://tangentsoft.com/pidp8i In addition to the reporting changes I previously described, there are others, mainly in Admin > Tickets > Common. For instance, my resolution_choices list includes the nonstandard “Implemented” choice, which I use instead of “Fixed” when I finish implementing a feature request ticket. Further thoughts on this topic: Features do sometimes jump multiple levels. For instance, an idea that was once just a good idea — “Medium” in my system — may eventually be deemed essential and thus jump straight to Immediate priority. Features sometimes also fall multiple levels. A person filing a feature request might have what he thinks is a really hot idea (“High”) but when we later go through the release planning exercise, management may think it’s a bad idea for some reason, so it drops to Low rather than being deleted. We may add a comment on reprioritizing at this point to record who spiked the idea, so we know who has to be convinced if the idea comes back up again. The High priority pool rarely drains, even immediately after planning the next release. We have more great ideas than time to implement them. We just hope to get to those ideas before the world changes enough that the feature ideas become worthless, in which case we need more developers: we’ve left fruit on the tree. The Medium pool never drains until the project planners run out of good ideas, at which point it’s time to mothball the project. If the Low pool ever drains, it probably means you’re not capturing enough of the organization’s knowledge in Fossil. After enough member turnover, the organization will forget things it should remember. “Low” may be an idea graveyard in a private repository, but in a public repo, it is where features that the core developers are unlikely to get to land. This pool is a good place to point outside contributors, since they’re ideas worth keeping but they’re unlikely to conflict with a core developer’s plans. That’s not an exclusive characterization: Medium will have more such ideas, just with a higher risk that some core developer has his eye on it and has plans to get to it someday. Fossil’s ticketing system is really quite flexible. There’s a good chance you don’t have to accept things you don’t like about it: the fix might be easily accomplished. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 11:40:01AM -0700, Sam Putman wrote: > > As a target, I would suggest the emitted html look as much like this > as possible: > > view-source:https://github.com/jvirkki/libbloom/blob/master/bloom.c > > The actual code block begins at line 821. > > This style of markup is a de-facto standard and leads to a linking > style that would greatly aid migration from git if fossil could adhere > to it. My example was nothing but off the top of my head equivalent to pseudocode (except I think the code was all valid HTML around valid C). Only the class names change between my version and this version, apart from some extra details like data-line-number and id properties, in any case. That means I was evidently thinking identically (in principle) to the thoughts of whoever wrote the code that produced your example. I'm not sure how this has any effect on migration from git to fossil, though. Git export and Fossil import wouldn't touch this code. Are you talking about some kind of external tools being able to interact with this code in the browser? If so, the classes involved probably come from whatever JS library is used for syntax highlighting anyway, rather than from something like code internal to Fossil (unless syntax highlighting gets implemented in C as part of Fossil). I guess the upshot is that I'm not sure what you mean, and all I've been able to do so far is guess. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On Thu, Jun 28, 2018 at 03:26:42PM -0400, Richard Hipp wrote: > On 6/28/18, Martin Gagnon wrote: > > > > To use the ns_* function, you needs to install libbind from packages: > > pkg_add -r libbind. > > > > I'm thinking I will probably end up having to write my own DNS query > response parser > Ok, that's would be ideal I guess (for portability). But still, FYI: I just manage to compile and link it successfully with libbind on OpenBSD. I don't know how to configure autosetup to detect it automatically, but I just had to edit the Makefile manually after the "./configure" as the following: - addition to CFLAGS variable: -I/usr/local/include/bind - addition to LIB variable: -L/usr/local/lib/libbind -lbind -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, Martin Gagnon wrote: > > To use the ns_* function, you needs to install libbind from packages: > pkg_add -r libbind. > I'm thinking I will probably end up having to write my own DNS query response parser -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On Thu, Jun 28, 2018 at 11:58:55AM -0700, jungle Boogie wrote: > On 28 June 2018 at 11:42, Richard Hipp wrote: > > On 6/28/18, jungle Boogie wrote: > >> Hi All, > >> > >> I know it's still very early on to make use of the new smtp logic, but > >> I thought I'd report these issues. Is anyone else experiencing issues > >> with compiling? > > > > Did you rerun ./configure? > > > > fossil clean -x > > ./configure > > make > > > > The build took place in a separate directory, outside my trunk version > of Fossil. > > > If you still get errors then, please let me know. But first, figure > > out what library OpenBSD wants to link against in order to pick up the > > DNS parsing routines. > > Does this help? > http://man.openbsd.org/man3/getrrsetbyname.3 To use the ns_* function, you needs to install libbind from packages: pkg_add -r libbind. Then, I guess we will needs to modify our autosetup script, so it detect if libbind is installed. If it's the case, it needs to add: - /usr/local/include/bind to include path - /usr/local/lib/bind to lib path - add -lbind to link agains libbind. I got it to compile, I still have an issue with the linking part. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, jungle Boogie wrote: > > The res_query() function provides an interface to the server query > mechanism. It constructs a query, sends it to the local server, awaits > a response, and makes preliminary checks on the reply. The query > requests information of the specified type and class for the specified > fully qualified domain name dname. The reply message is left in the > answer buffer with length anslen supplied by the caller. Values for > the class and type fields are defined in . > > I think that's what you want! Indeed. So can you write up a little subroutine to parse the binary DNS reply and extract the name of the MX host for us? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 28 June 2018 at 12:07, Richard Hipp wrote: > On 6/28/18, jungle Boogie wrote: >> >> Does this help? >> http://man.openbsd.org/man3/getrrsetbyname.3 >> > > That seems to be an OpenBSD-only library function. So, no, it doesn't > really help. > > Does OpenBSD have req_query() at least? I suppose I could write my > own DNS record parser. (sigh...) > https://man.openbsd.org/resolver.3 res_query, res_search, res_mkquery, res_send, res_init, dn_comp, dn_expand — resolver routines The res_query() function provides an interface to the server query mechanism. It constructs a query, sends it to the local server, awaits a response, and makes preliminary checks on the reply. The query requests information of the specified type and class for the specified fully qualified domain name dname. The reply message is left in the answer buffer with length anslen supplied by the caller. Values for the class and type fields are defined in . I think that's what you want! > -- > D. Richard Hipp > d...@sqlite.org --- inum: 883510009027723 sip: jungleboo...@sip2sip.info ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, jungle Boogie wrote: > > Does this help? > http://man.openbsd.org/man3/getrrsetbyname.3 > That seems to be an OpenBSD-only library function. So, no, it doesn't really help. Does OpenBSD have req_query() at least? I suppose I could write my own DNS record parser. (sigh...) -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 28 June 2018 at 11:42, Richard Hipp wrote: > On 6/28/18, jungle Boogie wrote: >> Hi All, >> >> I know it's still very early on to make use of the new smtp logic, but >> I thought I'd report these issues. Is anyone else experiencing issues >> with compiling? > > Did you rerun ./configure? > > fossil clean -x > ./configure > make > The build took place in a separate directory, outside my trunk version of Fossil. > If you still get errors then, please let me know. But first, figure > out what library OpenBSD wants to link against in order to pick up the > DNS parsing routines. Does this help? http://man.openbsd.org/man3/getrrsetbyname.3 > > -- > D. Richard Hipp > d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, jungle Boogie wrote: > Hi All, > > I know it's still very early on to make use of the new smtp logic, but > I thought I'd report these issues. Is anyone else experiencing issues > with compiling? Did you rerun ./configure? fossil clean -x ./configure make If you still get errors then, please let me know. But first, figure out what library OpenBSD wants to link against in order to pick up the DNS parsing routines. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 9:07 AM, Chad Perrin wrote:
> See if this makes sense:
>
> Apply syntax highlighting to a block of code. Organize the code in
> second column TD elements of a table. Organize line numbers in first
> column TD elements of a table.
>
> Thus, you would have HTML for a line of code that looks something like
> this (using a totally made-up function as example code):
>
>
> $num
>
> uint16_t class="color-label">get_next() {
>
>
>
> Of course, that's just off the top of my head. I don't actually know
> how the HTML resulting from application of the syntax highlighting code
> would look in this case. The upshot, though, is that applying syntax
> highlighting to the code to be displayed first, then organizing it into
> table cells with number cells, might avoid JS syntax highlighting issues
> with line numbers, including any issues around multiline highlighting.
> The downside is that it would result in either having to do all line
> numbering in JS or applying syntax highlighting server-side.
>
>
As a target, I would suggest the emitted html look as much like this as
possible:
view-source:https://github.com/jvirkki/libbloom/blob/master/bloom.c
The actual code block begins at line 821.
This style of markup is a de-facto standard and leads to a linking style
that would
greatly aid migration from git if fossil could adhere to it.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] smtp.c build failures
Hi All, I know it's still very early on to make use of the new smtp logic, but I thought I'd report these issues. Is anyone else experiencing issues with compiling? FIG_H -D_HAVE_SQLITE_CONFIG_H -g -O2 -o bld/smtp.o -c bld/smtp_.c ./src/smtp.c:54:3: error: use of undeclared identifier 'ns_msg' ns_msg h; /* DNS reply parser */ ^ ./src/smtp.c:62:8: warning: implicit declaration of function 'ns_initparse' is invalid in C99 [-Wimplicit-function-declaration] rc = ns_initparse(aDns,nDns,&h); ^ ./src/smtp.c:62:32: error: use of undeclared identifier 'h' rc = ns_initparse(aDns,nDns,&h); ^ ./src/smtp.c:64:10: warning: implicit declaration of function 'ns_msg_count' is invalid in C99 [-Wimplicit-function-declaration] nRec = ns_msg_count(h, ns_s_an); ^ ./src/smtp.c:64:23: error: use of undeclared identifier 'h' nRec = ns_msg_count(h, ns_s_an); ^ ./src/smtp.c:64:26: error: use of undeclared identifier 'ns_s_an' nRec = ns_msg_count(h, ns_s_an); ^ ./src/smtp.c:66:5: error: use of undeclared identifier 'ns_rr' ns_rr x; ^ ./src/smtp.c:69:10: warning: implicit declaration of function 'ns_parserr' is invalid in C99 [-Wimplicit-function-declaration] rc = ns_parserr(&h, ns_s_an, i, &x); ^ ./src/smtp.c:69:22: error: use of undeclared identifier 'h' rc = ns_parserr(&h, ns_s_an, i, &x); ^ ./src/smtp.c:69:25: error: use of undeclared identifier 'ns_s_an' rc = ns_parserr(&h, ns_s_an, i, &x); ^ ./src/smtp.c:69:38: error: use of undeclared identifier 'x' rc = ns_parserr(&h, ns_s_an, i, &x); ^ ./src/smtp.c:71:9: warning: implicit declaration of function 'ns_rr_rdata' is invalid in C99 [-Wimplicit-function-declaration] p = ns_rr_rdata(x); ^ ./src/smtp.c:71:21: error: use of undeclared identifier 'x' p = ns_rr_rdata(x); ^ ./src/smtp.c:72:10: warning: implicit declaration of function 'ns_rr_rdlen' is invalid in C99 [-Wimplicit-function-declaration] sz = ns_rr_rdlen(x); ^ ./src/smtp.c:72:22: error: use of undeclared identifier 'x' sz = ns_rr_rdlen(x); ^ ./src/smtp.c:82:5: warning: implicit declaration of function 'ns_name_uncompress' is invalid in C99 [-Wimplicit-function-declaration] ns_name_uncompress(aDns, aDns+nDns, pBest+2, ^ 6 warnings and 10 errors generated. *** Error 1 in /home/jungle/fossil-repos/smtp (./src/main.mk:1628 'bld/smtp.o') OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0) Target: amd64-unknown-openbsd6.3 Thread model: posix InstalledDir: /usr/bin Running openBSD -current Thanks! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 12:11:11PM -0500, Lester L. Martin II wrote:
> On 2018-06-28 11:07, Chad Perrin wrote:
> >
> > I think a cleaner approach, though it might take a bit of rewriting for
> > file display, would use an HTML table, possibly assembled by
> > JavaScript.
> > Note that I'm feeling a little dirty for suggesting this; it's
> > something
> > that could also reasonably be done server-side, though it would
> > probably
> > require using something server-side for the syntax highlighting, too.
>
> Server side syntax highlighting is an excellent idea, though I'm not
> quite sure at this time how to implement it. The other issue with such
> being that fossil would basically need to cache the results of running
> a highlight for the liftime of the program up until something
> invalidates the cache. Line numbering does/will need serious work to
> integrate with syntax highlighting regardless of the approach.
Yeah, that'd probably be more work overall, and would likely reduce the
customization for syntax highlighting allowed to people deploying Fossil
repositories to the web. It would make how line numbering and syntax
highlighting integrate much more "deterministic", though, in that Fossil
devs would have a clearer view of everything that happens when trying to
account for it in updates to Fossil source. It's a trade-off, as with
most such decisions.
> >
> > See if this makes sense:
> >
> > Apply syntax highlighting to a block of code. Organize the code in
> > second column TD elements of a table. Organize line numbers in
> > first column TD elements of a table.
> >
> > Thus, you would have HTML for a line of code that looks something
> > like this (using a totally made-up function as example code):
> >
> >
> > $num
> >
> > uint16_t > class="color-label">get_next() {
> >
> >
>
> Basically how GitHub and several other things implement it.
I guess my intuition about how to handle it is in good company, for some
definition of "good".
> >
> > Of course, that's just off the top of my head. I don't actually
> > know how the HTML resulting from application of the syntax
> > highlighting code would look in this case. The upshot, though, is
> > that applying syntax highlighting to the code to be displayed first,
> > then organizing it into table cells with number cells, might avoid
> > JS syntax highlighting issues with line numbers, including any
> > issues around multiline highlighting. The downside is that it would
> > result in either having to do all line numbering in JS or applying
> > syntax highlighting server-side.
>
> The issue with just applying highlights first is how will line endings
> be tracked since html elements need not necessarily be rendered
> similarly by all highlighting libraries. Detecting line endings in a
> generic way after markup has been applied will be very difficult and
> likely library specific. I keep using Prism.js as my goto for
> illustration but I would bet that the differences between hljs and
> prism are enough that the JS needing to be written to (hopefully)
> detect marked up line endings between them would be different and we
> get into a "supports $library" case vs a generic case like it has been
> so far without syntax highlights and how it'd remain if we didn't go
> forward with syntax highlighting when lines are numbered.
If you mean that syntax highlighting libraries might insert literal
newlines into the file when marking it up for highlighting, that's
pretty awful, and could indeed screw up the whole exercise.
>
> We still would end up depending on the "Line numbers" checkbox being a
> call into JS to add those in for everything but the server-side case.
> I'd rather not have to write JS to try to target 2 different
> highlighting engines (or possibly more dependent upon what other users
> prefer). Then that means that we'd need to check the JS code written
> against say... the latest 3 versions of each highlighting engine in
> our "support list". At that point it could be said that our hold ups
> in deploying a new version are tied up in making sure integration with
> several external resources will move along properly. We'd also get
> into a case of saying "supports up to $version_number of this library"
> (and more of those statements for other libraries supported). At this
> point I came to the conclusion it's a huge undertaking and would
> require extensive long term management, and believe at that point, it
> might be best to "bless" a certain syntax highlighting library and
> forgo anything else. If that library was included in fossil, then
> wouldn't need to worry about having to possibly push a fix to allow
> the newest version to work.
This pretty much makes the detriments of a server-side approach that I
described earlier apply to the client-side approach, too. There are
other concerns that apply to the server-side, too, though, such as the
fact I suspect more rewriting of Fossil so
Re: [fossil-users] email.c typo
And I assume " to send an announcements" should be either " to send announcements" or " to send an announcement" /email.c > > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 2018-06-28 11:07, Chad Perrin wrote:
On Thu, Jun 28, 2018 at 10:40:19AM -0500, Lester L. Martin II wrote:
I've developed a way to do highlighting with line numbering...
The issues are as follows however:
1. The JS code responsible for the highlighting is external to Fossil
itself.
2. The JS code highlights blocks, so if there is a
`$line$line2` each code block
is
highlighted individually.
3. Context is lost between code blocks.
Each line gets wrapped in a separate code block because you can use
css to insert a line number vs manually inserting the line number via
code per line.
That said, if you have a comment block `/* comments */` broken up over
a few lines, it won't apply the comment coloring to the lines
in-between when line numbering is enabled. Thus, I'd consider that
while it half works, such is inherently broken unless we decide to
depend upon a certain JS library to handle highlighting.
I think a cleaner approach, though it might take a bit of rewriting for
file display, would use an HTML table, possibly assembled by
JavaScript.
Note that I'm feeling a little dirty for suggesting this; it's
something
that could also reasonably be done server-side, though it would
probably
require using something server-side for the syntax highlighting, too.
Server side syntax highlighting is an excellent idea, though I'm not
quite sure at this time how to implement it. The other issue with such
being that fossil would basically need to cache the results of running
a highlight for the liftime of the program up until something
invalidates the cache. Line numbering does/will need serious work to
integrate with syntax highlighting regardless of the approach.
See if this makes sense:
Apply syntax highlighting to a block of code. Organize the code in
second column TD elements of a table. Organize line numbers in first
column TD elements of a table.
Thus, you would have HTML for a line of code that looks something like
this (using a totally made-up function as example code):
$num
uint16_t get_next()
{
Basically how GitHub and several other things implement it.
Of course, that's just off the top of my head. I don't actually know
how the HTML resulting from application of the syntax highlighting code
would look in this case. The upshot, though, is that applying syntax
highlighting to the code to be displayed first, then organizing it into
table cells with number cells, might avoid JS syntax highlighting
issues
with line numbers, including any issues around multiline highlighting.
The downside is that it would result in either having to do all line
numbering in JS or applying syntax highlighting server-side.
The issue with just applying highlights first is how will line endings
be tracked since html elements need not necessarily be rendered
similarly
by all highlighting libraries. Detecting line endings in a generic way
after markup has been applied will be very difficult and likely library
specific. I keep using Prism.js as my goto for illustration but I would
bet that the differences between hljs and prism are enough that the JS
needing to be written to (hopefully) detect marked up line endings
between them would be different and we get into a "supports $library"
case vs a generic case like it has been so far without syntax highlights
and how it'd remain if we didn't go forward with syntax highlighting
when lines are numbered.
We still would end up depending on the "Line numbers" checkbox being
a call into JS to add those in for everything but the server-side
case. I'd rather not have to write JS to try to target 2 different
highlighting engines (or possibly more dependent upon what other
users prefer). Then that means that we'd need to check the JS code
written against say... the latest 3 versions of each highlighting
engine in our "support list". At that point it could be said that our
hold ups in deploying a new version are tied up in making sure
integration with several external resources will move along properly.
We'd also get into a case of saying "supports up to $version_number
of this library" (and more of those statements for other libraries
supported). At this point I came to the conclusion it's a huge
undertaking and would require extensive long term management, and
believe at that point, it might be best to "bless" a certain syntax
highlighting library and forgo anything else. If that library was
included in fossil, then wouldn't need to worry about having to possibly
push a fix to allow the newest version to work.
So so far I see 4 "valid" options:
1. Move towards server side highlighting implementing a caching
mechanism.
2. Chase multiple versions of differing libraries and maintain our
own JS that either calls the library's line numbering function
or uses our own stuff to afix numbering after the other has been
done.
3. Bless a certain highlighting library and/or version of that library
with possible inclusio
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 10:40:19AM -0500, Lester L. Martin II wrote:
>
> I've developed a way to do highlighting with line numbering...
> The issues are as follows however:
> 1. The JS code responsible for the highlighting is external to Fossil
> itself.
> 2. The JS code highlights blocks, so if there is a
>`$line$line2` each code block is
>highlighted individually.
> 3. Context is lost between code blocks.
>
> Each line gets wrapped in a separate code block because you can use
> css to insert a line number vs manually inserting the line number via
> code per line.
>
> That said, if you have a comment block `/* comments */` broken up over
> a few lines, it won't apply the comment coloring to the lines
> in-between when line numbering is enabled. Thus, I'd consider that
> while it half works, such is inherently broken unless we decide to
> depend upon a certain JS library to handle highlighting.
I think a cleaner approach, though it might take a bit of rewriting for
file display, would use an HTML table, possibly assembled by JavaScript.
Note that I'm feeling a little dirty for suggesting this; it's something
that could also reasonably be done server-side, though it would probably
require using something server-side for the syntax highlighting, too.
See if this makes sense:
Apply syntax highlighting to a block of code. Organize the code in
second column TD elements of a table. Organize line numbers in first
column TD elements of a table.
Thus, you would have HTML for a line of code that looks something like
this (using a totally made-up function as example code):
$num
uint16_t get_next() {
Of course, that's just off the top of my head. I don't actually know
how the HTML resulting from application of the syntax highlighting code
would look in this case. The upshot, though, is that applying syntax
highlighting to the code to be displayed first, then organizing it into
table cells with number cells, might avoid JS syntax highlighting issues
with line numbers, including any issues around multiline highlighting.
The downside is that it would result in either having to do all line
numbering in JS or applying syntax highlighting server-side.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Embedded Documentation Force Trailing Slash?
Thanks for the reply. It would be great if the following feature request be considered for future versions. Currently if a FILE ends in "/" then the names "FILE/index.html", "FILE/index.wiki", and "FILE/index.md" are tried in that order. If no "/" at the end, if the FILE is not found a 404 is served. Changing it to if a FILE doesn't end in "/" and also if the FILE isn't found, then it should be tried as a directory and hence the "FILE/index.html", "FILE/index.wiki" and "FILE/index.md" should be tried. Failing all of that a 404 should be served. I can file a feature request using the Fossil ticketing system if you'd like. Thanks again. On Thu, Jun 28, 2018, at 8:08 AM, Richard Hipp wrote: > On 6/28/18, MKG wrote: > > > > /index.cgi/doc/trunk/test/ ---> works > > "/index.cgi/doc/trunk/test ---> doesn't work > > > > Technically, this is correct but I'm wondering if there is a way to add the > > trailing slash when necessary to make it more usable. > > I don't recall a way of making the /doc webpage do that. > > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 2018-06-28 08:12, Richard Hipp wrote: Please mail in your CLA when you get a chance. Sending later today, hopefully regular stamped mail won't take 2 weeks. I've developed a way to do highlighting with line numbering... The issues are as follows however: 1. The JS code responsible for the highlighting is external to Fossil itself. 2. The JS code highlights blocks, so if there is a `$line$line2` each code block is highlighted individually. 3. Context is lost between code blocks. Each line gets wrapped in a separate code block because you can use css to insert a line number vs manually inserting the line number via code per line. That said, if you have a comment block `/* comments */` broken up over a few lines, it won't apply the comment coloring to the lines in-between when line numbering is enabled. Thus, I'd consider that while it half works, such is inherently broken unless we decide to depend upon a certain JS library to handle highlighting. Highlightjs is compatible (BSD2 licensed) but I also could see that its probably unwanted to include yet more JS. I'm not sure if line numbering shouldn't be shifted to a "up to the user" ordeal like syntax highlighting was. That however means stripping away the "?ln" query capabilities. I'm unsure how this situation would best be handled, because as it is, syntax highlighting works, doesn't work with line numbering, and likely cannot work with line numbering without bringing in something as a dependency and depending on it to handle the line numbering for us. All that said... what I did was more a proof of concept with the line numbering syntax highlighting and even "?ln" query capabilities went untested when I first noticed the loss of context issue and figured that it would be best to figure out what trade offs should be made to be able to highlight whilst displaying numbers or if the trade off is to not be highlight capable when numbers are displayed. -- Lester L. Martin II ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Embedded Documentation Force Trailing Slash?
On 6/28/18, MKG wrote: > > /index.cgi/doc/trunk/test/ ---> works > "/index.cgi/doc/trunk/test ---> doesn't work > > Technically, this is correct but I'm wondering if there is a way to add the > trailing slash when necessary to make it more usable. I don't recall a way of making the /doc webpage do that. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Embedded Documentation Force Trailing Slash?
Hi Fossil Users, I'm trying to setup a site using fossil embedded documentation and since run into an issue. Here I have a document "test/index.md" in the file tree. When accessing the file with the following url "/index.cgi/doc/trunk/test/" it works as expect. But without the trailing slash "/index.cgi/doc/trunk/test" the document isn't served. /index.cgi/doc/trunk/test/ ---> works "/index.cgi/doc/trunk/test ---> doesn't work Technically, this is correct but I'm wondering if there is a way to add the trailing slash when necessary to make it more usable. BTW I'm using CGI and the server runs Apache. Thanks. MKG. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 6/28/18, Lester L. Martin II wrote: > > Indeed. The entire code dealing with adding in line numbering would need > reworking to enable it (and probably updates to CSS as well). I might > can > look into getting that working as well. I actually think there would be > a way that would be simpler than IIRC prefixing each line with spaces > and > the number and then more spaces. Excellent. Please mail in your CLA when you get a chance. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 2018-06-28 07:11, Richard Hipp wrote: On 6/28/18, Lester L. Martin II wrote: This patch changes the way `void artifact_page(void)` renders a files content. Formerly a `` was issued for content, whereas now a `` is issued where $ext is the file's extension (example, "blah.lua" extension would be "lua"). But then the syntax highlighting goes away if you select line numbering, no? Indeed. The entire code dealing with adding in line numbering would need reworking to enable it (and probably updates to CSS as well). I might can look into getting that working as well. I actually think there would be a way that would be simpler than IIRC prefixing each line with spaces and the number and then more spaces. -- Lester L. Martin II ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Meta-enhancement
Warren, this looks great! Apologies for not knowing, but where did you make these changes? On 28 June 2018 at 04:11, Warren Young wrote: > On Jun 27, 2018, at 8:16 AM, Richard Hipp wrote: > > > > If I leave [a feature request ticket] open, then > > people become alarmed at all the open bugs against Fossil. > > I solve that problem in my repositories by distinguishing “Bugs” from > “Feature Requests.” > > First, I rename the default “All Tickets” report to “Bugs,” making little > to no change to it. > > Then I create a “Wish List” report with the following SQL, which is > closely related to the default report: > > > SELECT > CASE priority >WHEN 'Immediate' THEN '#f2dcdc' >WHEN 'High' THEN '#e8e8bd' >WHEN 'Medium' THEN '#cfe8bd' >WHEN 'Low' THEN '#cacae5' >ELSE '#c8c8c8' END as 'bgcolor', > substr(tkt_uuid,1,10) AS '#', > datetime(tkt_mtime) AS 'mtime', > status, > subsystem, > title > FROM ticket > WHERE (type='Feature Request' or type='Documentation') and status != > 'Closed' > ORDER BY substr(bgcolor, 2) DESC > > > Finally, I replace the Tickets navbar link with “Bugs” and “Wish List” > links, which each take you to the report of the same name. > > Not only does this solve the expectation problem, it means we can then use > the ticket system as a release planning tool: > > - Immediate: features for the next release. When all such features are > implemented, the upcoming release goes into beta (feature-complete) state. > > - High: things we want to get to in the next release, or maybe the one > after that > > - Medium: feature ideas we like, but which we aren’t willing to commit to > a particular release > > - Low: ideas worth keeping, but which we’re not likely to ever get to. If > nothing else, this prevents the same ideas from being re-filed: it says, > “Yes, someone else has had this idea already, and we’re not likely to > implement it; patches thoughtfully considered.” > > > Feature requests generally move up and down one priority level at a time, > if at all. Ideally, all requests would move up towards Immediate, but in > reality, many features never make it out of Medium and almost none make it > out of Low. > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 6/28/18, Lester L. Martin II wrote: > This patch changes the way `void artifact_page(void)` renders a files > content. > Formerly a `` was issued for content, whereas now a > `` is issued where $ext is the file's > extension (example, "blah.lua" extension would be "lua"). But then the syntax highlighting goes away if you select line numbering, no? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 2018-06-28 00:36, Chad Perrin wrote:
On Wed, Jun 27, 2018 at 11:31:57PM -0500, Lester L. Martin II wrote:
This patch changes the way `void artifact_page(void)` renders a files
content. Formerly a `` was issued for content,
whereas now a `` is issued where
$ext is the file's extension (example, "blah.lua" extension would be
"lua").
This allows for proper integration with syntax highlighting systems
such as "highlight.js" and "prism.js" where only the former was
tested. This allows syntax highlighting without having to have
language detection.
It's pretty cool you did this. I'm going to look over this and the
syntax highlighting tools that might work with it to see if I want to
start using it, though I guess I'd have to compile my own Fossil if I
wanted to do it sooner rather than later. Thanks for the work.
Glad you may find it useful, the steps to get it working with
highlightjs
is just to edit a Skin/Theme you like and add the following lines:
https://your_domain/agate.min.css";>
https://your_domain/highlight.min.js";>
hljs.configure({languages: []})
hljs.initHighlightingOnLoad();
You'll need to download highlightjs, and the corresponding CSS theme
for it that you like of course, and either configure nginx, or your
webserver or choice, to serve a static directory on the same domain,
or to use fossil's "--files" param to get fossil to serve those files.
Remaining work likely includes changing the CSS of all themes to take
this into account. Other things that might be considered is to
conditionally remove the `` part from all but the content
rendering. Another part would be rendering syntax highlights with line
numbers (currently unimplemented).
Have you checked it against any themese to see if it affects them at
all? If so, which themes did you find weren't problematic? I'm
guessing that if you found some that were you'd mention it.
The only themes it doesn't look visually opinion with this IMO are
Ardoise and Bootstrap. Note I didn't test all themes in a dark mode. The
following is a review of each theme.
Works:
Default, Blitz, Original, Enhanced Original, Black and White (menu on
the
left), Plain Gray no Logo
Works with comment:
Blitz (looks decent)
Xekri (doubled border, looks decent still)
Shadow Boxes and Rounded Corners (doubled border, looks decent still)
Doesn't work:
Ardoise (my fav theme at the moment, doubled borders look horrid)
Bootstrap (not bad, but the doubled border isn't great either)
If a theme is left unmentioned it probably worked, the list of what
worked
was growing far too long.
Below is the output of 'fossil diff' ran against checkout
'6a7d2ad8f1dd5c542eba0b885418328803d8d802' with my changes:
Index: src/info.c
==
--- /home/masky/misc/fossil/src/info.c~02018-06-27 23:21:48.520779000
-0500
+++ /home/masky/misc/fossil/src/info.c 2018-06-27 16:48:28.683256000
-0500
@@ -670 +670 @@
-
+
@@ -2157 +2157,2 @@
-const char *z;
+const char *z, *ext, *name;
+char *tmp;
@@ -2158,0 +2160,3 @@
+name = blob_str(&downloadName);
+
+ext = (tmp = strrchr(name, '.')) == NULL ? "" : tmp+1;
@@ -2162 +2166 @@
- @
+ @
@@ -2164 +2168 @@
- @
+ @
@@ -2232 +2236 @@
- ? db_text("(No title)",
+ ? db_text("(No title)",
!!END!!
I'm unsure why "@@ -2232 +2236 @@" section got included as no changes
were
made to that.
I haven't looked at the code in context; I've only seen the patch you
inlined in the email so far. It looks sane to me, though. I might
come
back and look at it again in the morning, and check it against the
Fossil source code for context.
I would like to submit a contributor agreement to make it official.
This
change is so small that my previous post to the list serv considered,
one could have implemented it in less time than it would take for a
contributor agreement to finally be filed but as there was no reply
I didn't wait upon such.
Even if they want the contributor agreement on file before
incorporating
it, I'm glad you sent it to the list for people who might want to start
using it sooner than the next Fossil release.
Thanks, really hope someone (or lots of people) find this a great,
easy enhancement.
--
Lester L. Martin II
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil set uv-sync question
I am still struggling with unversioned files: after "discovering" the
uv-sync setting I tried it out:
* on the server I did `fossil set --global uv-sync on'.
* doing, then, a file system based clone on the server `fossil clone
{path_to_server_repo} {path_to_clone_in_server_file_system} works as
expected (uv-files cloned as well), fine. BUT
* doing from the remote machine (after setting `uv-sync on' there, too)
`fossil clone {ssh-transport:path_to_server_repo} {path_to_local_clone}
does not work: the uv-files residing in the server repo are still not
synced/cloned. they appear only after opening the clone and issuing
`fossil sync' again (so the local uv-sync setting, then, actually *is
recognized*.
question 2: should not the clone via ssh-transport from the remote
machine, too, clone the uv-files just as the file system based clone on
the server side?
if it matters: the server-side repo had been created while `uv-sync' was
still off. (question 3: does a closed repo have "local" settings? where
are they stored? can't find them in the schema...)
thank you,
joerg
PS: uv-sync seems nowhere to be mentioned (let alone explained) in the
command line help (only found it in the GUI). maybe it should be
mentioned/explained in `fossil help uv'? also, the current explanation
reads:
If true, automatically send unversioned files as part
of a "fossil clone" or "fossil sync" command. The
default is false, in which case the -u option is
needed to clone or sync unversioned files.
it was not obvious from this text whether the server-side or the
clone-side setting is relevant ("if true, automatically send..." seems to
indicate it's the server-side, but actually it is the clone-side). maybe
this could be rephrased?
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Help with making a subroutine x-platform to windows
On 27.06.2018 21:24, Richard Hipp wrote:
> If anybody can suggest patches that will get this routine
> (https://fossil-scm.org/fossil/info/5e083abf6?ln=47) to compile and
> work on windows, that would really be helpful. Thanks.
>
Sample Windows program, needs the dnsapi.lib for linking:
#include /* Windows */
#include/* DNS API's */
#include /* Windows sockets */
#include/* For strdup() */
#include /* Standard I/O */
char *smtp_mx_host(const char *zDomain){
DNS_STATUS status; /* Return status */
PDNS_RECORD pDnsRecord, p; /* Pointer to DNS_RECORD structure */
int iBestPriority = 999; /* Best priority */
unsigned char *pBest = 0;/* RDATA for the best answer */
status = DnsQuery_UTF8(zDomain,/* Domain name */
DNS_TYPE_MX,/* DNS record type */
DNS_QUERY_STANDARD, /* Query options */
NULL, /* List of DNS servers */
&pDnsRecord,/* Query results */
NULL); /* Reserved */
if( status ) return NULL;
p = pDnsRecord;
while( p ){
if( p->Data.MX.wPreferenceData.MX.wPreference;
pBest = p->Data.MX.pNameExchange;
}
p = p->pNext;
}
if( pBest ){
pBest = strdup(pBest);
}
DnsRecordListFree(pDnsRecord, DnsFreeRecordListDeep);
return pBest;
}
int main(int argc, char *argv[]){
int i;
for(i=1; ihttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Help with making a subroutine x-platform to windows
It seems to me it would be simpler and more robust to simply call the relevant win32 api function: https://docs.microsoft.com/en-us/windows/desktop/api/windns/nf-windns-dnsquery_a On Wed, Jun 27, 2018, 23:22 Scott Doctor wrote: > A way may be using the system() command to run nslookup. From > the windows command line help for the command: > > Commands: (identifiers are shown in uppercase, [] means > optional)NAME- print info about the host/domain NAME > using default serverNAME1 NAME2 - as above, but use NAME2 as > serverhelp or ? - print info on common commandsset > OPTION - set an optionall - print > options, current server and host[no]debug - print > debugging information[no]d2 - print exhaustive > debugging information[no]defname - append domain > name to each query[no]recurse - ask for recursive > answer to query[no]search - use domain search > list[no]vc - always use a virtual circuit > domain=NAME - set default domain name to NAME > srchlist=N1[/N2/.../N6] - set domain to N1 and search list to > N1,N2, etc.root=NAME - set root server to NAME > retry=X - set number of retries to X > timeout=X - set initial time-out interval to X > secondstype=X - set query type (ex. > A,,A+,ANY,CNAME,MX,NS,PTR,SOA,SRV) > querytype=X - same as typeclass=X - set > query class (ex. IN (Internet), ANY)[no]msxfr - > use MS fast zone transferixfrver=X - current > version to use in IXFR transfer requestserver NAME - set > default server to NAME, using current default serverlserver > NAME- set default server to NAME, using initial > serverroot- set current default server to the rootls > [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: > output to FILE)-a - list canonical names and > aliases-d - list all records-t TYPE - > list records of the given RFC record type (ex. A,CNAME,MX,NS,PTR > etc.)view FILE - sort an 'ls' output file and view it > with pgexit- exit the program > > - > Scott Doctor > sc...@scottdoctor.com > - > > On 6/27/2018 12:24, Richard Hipp wrote: > > > If anybody can suggest patches that will get this routine > > (https://fossil-scm.org/fossil/info/5e083abf6?ln=47) to compile and > > work on windows, that would really be helpful. Thanks. > > > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Meta-enhancement
On Jun 27, 2018, at 8:16 AM, Richard Hipp wrote: > > If I leave [a feature request ticket] open, then > people become alarmed at all the open bugs against Fossil. I solve that problem in my repositories by distinguishing “Bugs” from “Feature Requests.” First, I rename the default “All Tickets” report to “Bugs,” making little to no change to it. Then I create a “Wish List” report with the following SQL, which is closely related to the default report: SELECT CASE priority WHEN 'Immediate' THEN '#f2dcdc' WHEN 'High' THEN '#e8e8bd' WHEN 'Medium' THEN '#cfe8bd' WHEN 'Low' THEN '#cacae5' ELSE '#c8c8c8' END as 'bgcolor', substr(tkt_uuid,1,10) AS '#', datetime(tkt_mtime) AS 'mtime', status, subsystem, title FROM ticket WHERE (type='Feature Request' or type='Documentation') and status != 'Closed' ORDER BY substr(bgcolor, 2) DESC Finally, I replace the Tickets navbar link with “Bugs” and “Wish List” links, which each take you to the report of the same name. Not only does this solve the expectation problem, it means we can then use the ticket system as a release planning tool: - Immediate: features for the next release. When all such features are implemented, the upcoming release goes into beta (feature-complete) state. - High: things we want to get to in the next release, or maybe the one after that - Medium: feature ideas we like, but which we aren’t willing to commit to a particular release - Low: ideas worth keeping, but which we’re not likely to ever get to. If nothing else, this prevents the same ideas from being re-filed: it says, “Yes, someone else has had this idea already, and we’re not likely to implement it; patches thoughtfully considered.” Feature requests generally move up and down one priority level at a time, if at all. Ideally, all requests would move up towards Immediate, but in reality, many features never make it out of Medium and almost none make it out of Low. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
