Re: [fossil-users] Meta-enhancement

2018-06-28 Thread Warren Young
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

2018-06-28 Thread David Mason
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

2018-06-28 Thread Lester L. Martin II

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

2018-06-28 Thread Warren Young
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

2018-06-28 Thread Chad Perrin
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

2018-06-28 Thread Martin Gagnon
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

2018-06-28 Thread Richard Hipp
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

2018-06-28 Thread Martin Gagnon
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

2018-06-28 Thread Richard Hipp
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

2018-06-28 Thread jungle Boogie
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

2018-06-28 Thread Richard Hipp
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

2018-06-28 Thread jungle Boogie
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

2018-06-28 Thread Richard Hipp
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

2018-06-28 Thread Sam Putman
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

2018-06-28 Thread jungle Boogie
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

2018-06-28 Thread Chad Perrin
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

2018-06-28 Thread Donald Griggs
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

2018-06-28 Thread Lester L. Martin II

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

2018-06-28 Thread Chad Perrin
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?

2018-06-28 Thread MKG
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

2018-06-28 Thread Lester L. Martin II

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?

2018-06-28 Thread Richard Hipp
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?

2018-06-28 Thread MKG

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

2018-06-28 Thread Richard Hipp
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

2018-06-28 Thread Lester L. Martin II

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

2018-06-28 Thread David Mason
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

2018-06-28 Thread Richard Hipp
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

2018-06-28 Thread Lester L. Martin II

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

2018-06-28 Thread j. van den hoff
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

2018-06-28 Thread Thomas Schnurrenberger
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

2018-06-28 Thread Antoine Chavasse
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

2018-06-28 Thread Warren Young
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