Re: [fossil-users] This mailing list is now deprecated

[Offray Vladimir Luna Cárdenas]

Hi,

I can not login after registering myself. I got the registration email,
follow the link, but now I'm trying to login without success. I can't
find an option for recovering or changing an old password.

Cheers,

Offray


On 08/08/18 07:40, Richard Hipp wrote:
> The new "forum" feature of Fossil is now live on the self-hosting website:
>
> https://fossil-scm.org/forum
>
> The forum feature is intended as a replacement for mailing lists like
> this one. Though still very "beta", I believe in eating ones own
> dogfood, and hence I am cutting over to the forum for Fossil itself.
>
> There is a "subscribe" option on the link above where you can sign up
> for email notifications to new forum posts.  The enhance email
> notification should work just like a mailing list, with individual
> emails for each forum post containing complete post content and
> correct In-Reply-To headers.  The only major difference between the
> forum and this list is that you must go to the forum website to post
> new content.  New submissions via email are disallowed as an anti-spam
> measure.
>
> The Fossil homepage now has a link to the forum instead of a link to
> mailing list sign-up.
>
> Please discontinue use of this mailing list except as an emergency
> back-up to the forum in case the forum stops working.  If forum is not
> working, you can also send email directly to me.
>
> After we have shaken out the forum feature a little further, I will
> shut down this legacy mailing list.
>

___
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] About to merge the forum-v2 branch

[Offray Vladimir Luna Cárdenas]

Hi,


On 02/08/18 10:33, Jungle Boogie wrote:
> I enjoy mailing lists, having a copy of the mail and being able to reply from
> mutt (which I'm doing now), but I think what's been implemented within fossil 
> is
> something we can all appreciate and find use of. A small project may not use
> tickets, the wiki, or tech notes. That project probably won't have a mailing
> list either.
> Now there's another feature, for free, that they also may not use - a forum.

I also enjoy mailing list. Hopefully some RSS way of
subscribing/replying to the forum from a mail client will be provided
and I will stay here as much as possible before subscribing to the
forum. But i think that its a good addition to have in Fossil. Even for
a small project, like the ones I admin in Fossil, I have found a use for
several of its integrated features: files and tickets (mainly), wiki
(before discovering embedded doc) and tech notes (in a minor way). Not
that forum will be enabled, I foresee it as a welcomed feature for our
projects.

Cheers,

Offray
___
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] Feature slideshow on fossil homepage

[Offray Vladimir Luna Cárdenas]

On 09/07/18 16:31, Will Parsons wrote:
> On Monday,  9 Jul 2018 12:06 PM -0400, mario wrote:
>> As followup to last month` Show time.. discussion:
>>
>> → http://fossilslideshow.tmp.include-once.org/
>>
>> (Take in mind this ain't a mockup yet; just as example.)
> 
>
>> Discussion
>> ==
>>
>> Is this something the Fossil homepage should have?
>>
>> Any strong opinions or thoughts on image bloat?
> I *hate* this!  I find this sort of thing incredibly annoying on every
>  webpage that I've ever seen that contains it!  Please
> don't!
>

I don't like it. A more lighter and visual explanation could be done
with a bootstrap or Material Design Lite theme included in the Fossil
site if the current front page seems to textish, without going into the
slideshow explanation, which I find distracting and not responsible in
variety of screens. For example, gitea[1] and Gogs[2] both have a light
text front page without going into the slideshow route (which I think is
making more harm that good presenting ideas to the general public and
particularly in conferences, courses and the educational sector)

[1] https://gitea.io/
[2] https://gogs.io/

Cheers,

Offray

___
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] Syntax Highlighting

[Offray Vladimir Luna Cárdenas]

Lester,

Thanks a lot for your efforts in that front. I'm planing into extending
Fossil with Lua using javascript, so the steps you describe here are
pretty useful (maybe they could be collected in some of your public
repositories that serve as a showcase of your Fossil customizations). It
will be my first attempt on that front and I need to finish some other
stuff before, but I will try do document it as well.

Cheers,

Offray


On 26/06/18 13:02, Lester L. Martin II wrote:
> Recently I had the pleasure of succeeding in enabling syntax
> highlighting. Even
> with that success I still found some things that could make the
> process easier
> and more robust.
>
> One major issue would be that fossil by default inserts the following
> in the
> head:
>
> 
>
> This is fairly prohibitive towards trying to get outside resources
> included so
> as to allow syntax highlighting. The solution? Download jquery,
> highlightjs, and
> a CSS file to the directory that fossil server is serving up and tell
> it with
> the "--files" glob pattern to serve those sorts of files. Even so, I
> understand
> it's perhaps useful when running as it's own http server during local
> development but truthfully when ran with say the "--scgi" parameter
> I'm unsure
> that it does any good setting things that can be set in headers by the
> http
> server that is proxying it. In my case I use nginx and had my own set
> of CSP
> headers defined that I use across quite a few different resources.
> This confused
> me for a good minute when trying to use a CDN for highlightjs.
>
> The next major issue is that the "Artifact Content" pages use
> "" instead of "". This means that there
> are quite a
> few syntax highlighting tools that will absolutely not work. These
> tools insist
> on the latter (think prism.js). Luckilly highlightjs doesn't insist.
> Regardless,
> even if its "", utilizing "" would
> be far
> better. I've looked at the function in "src/info.c" and I also notice
> one other
> area where this could be improved if it were to move to "".
> The
> function already knows the file name and thereby could ascertain the
> file's
> extension quite easily. That said, say the file name is "bla.lua", it
> could
> detect the extension "lua", and set the class of the code block to it
> like
> "".
>
> Having the ability to utilize syntax highlighting would greatly
> enhance fossil
> and I'd love to see the previous paragraph's proposal implemented
> because most
> syntax highlighting detection engines will be more than horribly
> incorrect (I've
> played with highlightjs and have had nothing but incorrect detection).
>
> Finaly, I'd love to contribute, and had thought to go ahead and write
> a probably
> horrible patch considering I haven't read the entirety of the code
> base and am
> ultimately not up to speed with the project from a programming
> perspective. I
> saw on the site that a contributors agreement is needed but I also
> didn't see a
> way to submit the agreement even if I did fill it out. I at the moment
> believe
> someone other than myself could implement this feature correctly and less
> horribly than I could before I could manage to appropriately submit
> such an
> agreement. Even so, I'd like to get a contributors agreement on file
> so if
> anyone can help with that.
>
> -- 
> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] `unversioned' questions

[Offray Vladimir Luna Cárdenas]

Hi,


On 26/06/18 13:22, j. van den hoff wrote:
> On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth
>  wrote:
>
>> I think the next project that needs this feature should write a
>> utility script for themselves that uses the uv commands to extract
>> files however makes sense for them.  This live experimentation is
>> necessary to figure what is needed in practice.  No one is forced to
>> wait for any changes to be made to Fossil itself.  One day, a set of
>> best practices (i.e., a vague consensus on which compromises and
>> heuristics most people can live with most of the time) will emerge,
>> at which point Fossil can adopt them as useful defaults, but people
>> should always be able to write new scripts that work best for their
>> specific projects.
>>
>> On 06/26/18 10:31, Richard Hipp wrote:
>>> My thought was to provide a new setting (perhaps versionable) that
>>> specified a directory relative to the root of the check-out into which
>>> unversioned files are written whenever one does "fossil update" or
>>> "fossil checkout".  If the setting is missing or empty, then Fossil
>>> works as it does now.  If you turn on the setting, though, then the
>>> unversioned files work just like other files in the check-out, except
>>> that Fossil never records their history.
>>
>> I overall like the idea, but I can envision an endless stream of
>> feature creep as people want to do any of the following and more:
>>
>> - Deal with files having platform-incompatible names (slashes,
>> backslashes, drive letters, characters unsupported by the filesystem)
>> - Extract only files within certain size ranges
>> - Extract only files within certain date ranges
>> - Extract only files matching certain glob patterns
>> - Update the unversioned files when checking in
>> - Get diffs showing which unversioned files have changed
>> - Handle new files being added to the unversioned directory
>> - Reverse filename mapping done for platform compatibility when
>> checking in or adding new unversioned files
>> - Selectively check in unversioned files along with the rest of the
>> check-in
>>
>> And on it goes.  All of the above can be done today via shell
>> scripts, so projects wanting to experiment are invited to get started
>> right away.
>
> I dislike feature creep and endless "please implement this for me"
> requests, too. but I don't think this argument applies here, really.
> anyway the developer(s) decide what they implement and what not...
>
> from this thread I have learned in the meantime, that uv-files where
> intended for something different than what I would have guessed
> ("created for the purpose of providing a place to store build products
> when Fossil is used as a server") and that uv-files usually(is that
> right?) are residing outside of the checkout. so be it. and then I can
> understand why fossil does what it does with uv-files (and what it
> does not, namely providing a `fsl uv up' command that would do the
> same with uv-files that `fsl up' does with versioned files.
>
> all the possible issues with file system /OS issues etc. are sure
> valid but to the extent that fossil handles these with versioned files
> it could do the same with uv-files (at least as long as their
> pathnames are relative to the checkout root).
>
> so my question would be:
>
> is their any strong argument against a `fossil up -u' command? would
> it be undesirable to have? (if it really is going to be implemented
> und whether drh is willing to invest the time is a different question,
> naturally.) I think it would be quite valuable for assorted projects,
> notably those depending on large binary files such as jpeg-images (or
> libs) that are *project-specific* and prone to multiple changes over
> the duration of the project but where tracking changes of these files
> is not required. I simply would find it useful to be able to do `fsl
> up; fsl up -u' (or both with a single command) in order to bring my
> checkout including uv-files up to date...
>
> and yes, I will write a shell or TCL script to do this, if everything
> else fails. but it will be inferior to integration of this feature
> into fossil.
>

I'm using Fossil in this precise context for storing inside a repository
a large PDF file that is produced from LaTeX source files. What is most
surprising to me, is the fact that I need to add again the unversioned
file *every time* before I want to do `fossil uv -v` to update such file
in the repository.

So, I'm pretty interested in this thread and the solutions and
suggestions that you arrive. Using Fossil as a DVCS for reproducible
documentation, research and publishing is the exact case you're
advocating for and the features for least surprise regarding unversioned
files inside the repository are pretty pertinent there.

Cheers,

Offray

___
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] `unversioned' questions

[Offray Vladimir Luna Cárdenas]

Hi,

I share J. approach on this. Unversioned files, *when* used inside a
repo, containing relative paths should provide more automatization, for
example, when making some sync or cloning. Of course, you may not want
to sync each unversioned file each time (for example when large PDFs are
unversioned files in the repository), but having to add them, *each
time* before making any sync seems counter intuitive. `fossil uv sync
-v` should, in some setting, allow such automatic behavior without
previous `fossil uv add path/to/the-same-file` each time we want to
resync unversioned files already in the repo.

Cheers,

Offray


On 26/06/18 11:48, j. van den hoff wrote:
> On Tue, 26 Jun 2018 18:33:22 +0200, Stephan Beal
>  wrote:
>
>> On Tue, Jun 26, 2018 at 5:45 PM  wrote:
>>
>>> ​Can unversioned files respect their original paths when added?
>>> I have several locations for bitmaps, icons, pdf's, etc.
>>> They do not necessarily reside in an isolated folder.​
>
> yes, same here, *but* in directories *within* the checkout dir.
>
>>>
>>
>> That wouldn't work cross-platform. You might store file the C:\D\e\f.txt
>>
>> which i could not extract on Unix because we don't have drive
>> letters. If
>> we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless
>> i was
>> the root user. Case sensitivity is another problem in that regard. If
>> you
>> store C:\D\e.txt and C:\d\e.txt, those would map to two different
>> folders
>> on Unix systems.
>>
>> Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive
>> should it use?).
>
> I was only thinking about *relative* pathnames w.r.t. checkout root
> and that sure could be managed with the same logic cross-plattform as
> versioned files, right?
>
> but as explained, I have not used uv-files until today (and have not
> followed the discussion closely, when it was implemented). so I do not
> know all the use cases that are of relevance here.
>
> I now -- in view of your mail -- understand of course that there could
> be use cases (possibly the majority) where uv-files are located
> somewhere else in the file tree, rather than in the checkout. no idea
> how these should be properly handled, than. probably the way DRH just
> proposed would than be the only way.
>
> o.t.o.h.: the special case, where *everything* (versioned and
> unversioned files) reside together in the checkout dir might deserve
> special consideration/handling. it seems to me the "logical"
> extension/next step beyond "put everything under revision control":
> still keep all the stuff that constitutes "the project" together in
> one place (the checkout dir), but decide which files could be handled
> as uv-files in order to safe on disk space/repo size.
>
> this would imply special handling of the case "`fossil uv ls'" reports
> relative, rather than absolute pathnames" but maybe it could be quite
> useful, just think of my simple example: a LaTeX doc including several
> project-specific image files that I do not want to keep under revision
> control but as part of the repo. the tex-file will no longer compile
> on "the other side" if the uv-files are not put back into the expected
> (relative) location...
>
>>
>
>


___
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] [sqlite] Mailing list shutting down...

[Offray Vladimir Luna Cárdenas]

On 14/06/18 18:07, Thomas wrote:
> On 2018-06-14 23:19, Warren Young wrote:
>> I just checked, and for the flight I’ll be on, it’ll cost me about
>> 1/10 the monthly cost of my residential Internet service, per
>> device.  If I want to use my phone, tablet, and laptop, that’s 3/10
>> my monthly cost for a few hours of terrible service.
>
> That means again that it's probably better not to answer any support
> requests from this mailing list, which you will have downloaded eons
> ago already nonetheless (since you got no internet access). Your
> replies might be terribly outdated once you roll in to the nearest
> free wifi.
>
> I actually find it quite amusing that some people seem to be so
> personally involved in their favour of a mailing list over a forum,
> while this discussion has ceased for pretty much any other software
> product already, and many people even getting very personal, including
> insults.

For me what is amusing  is that people thinks that their reality defines
the reality of everyone else. In several countries in Latin America,
Asia and Africa (yes they're still a different part of the world in the
XXI century, despite of the efforts of "colonizers" to deny their
individuality since eons) there is not online all time and answering an
email from 3 days ago is not like being disconnected from centuries,
because three days still felt like 3 days and not like centuries in
those places.

Anything that allows offline participation is really appreciated over
the so called "Global South". I have been using Discourse Forum, with
mail suscription and mailing lists and I can see the advantages of the
first for a more peripheral participation and mailing list in
communities where I want to be more involved.

Just my 2 pesos, from another perspective in another place of the world.

Cheers,

Offray

Cheers,

Offray

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Repository reports as JSON

[Offray Vladimir Luna Cárdenas]

Hi,

I would like to have access to the activity reports information in JSON
format. I know that the json interface is enabled and that is mostly
used by preceding the usual url by the "json/" command (see for example
[1]), but for some reason I can not get any output for several commands
like json/timeline or json/reports in my Fossil repositories. What I'm
missing? Is reports activity available as JSON data?

[1] http://mutabit.com/repos.fossil/dataweek/json/dir?ci=tip

Thanks,

Offray


___
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] Show time...

[Offray Vladimir Luna Cárdenas]

On 03/06/18 20:28, Richard Hipp wrote:
> There is suddenly a big uptick in traffic to fossil-scm.org,
> apparently due to the recent GitHub rumor.  Unlike that traditional
> "slashdot effect", though, the referrals seem to be coming for a large
> variety of sources.
>
> So, if anybody sees any last minute tidying up that we need to do to
> the website in anticipation of a huge influx of first-time visitors,
> please speak up.  Quickly.
>

I think that would be fine to compile some "Powered by Fossil" projects,
for the upcoming show time. Maybe that could be a growing list. GitHub
is mostly famous by the projects there and their network effect, not
because of the inherent goodness of Git. We, using self hosted
repositories don't have such central place for visibility and FossilSCM
could be that place. Maybe a custom made form (also powered by the
Fossil SQL capabilities) could collect repos info (project name,
important urls, and maybe some extra comments).

This, of course would not be for last minute adds, but to  benefit from
the increased interest on Fossil that will come with the centralization
wave comming from MS+GitHub news.

Cheers,

Offray


___
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] Unnable to merge: Cannot find a common ancestor between the current checkout and ID

[Offray Vladimir Luna Cárdenas]

On 31/05/18 10:22, Richard Hipp wrote:
> On 5/31/18, Richard Hipp  wrote:
>> Thanks for the bug report.  Probably I should enhance Fossil so that
>> will successfully find the "pivot" (aka "most recent common ancestor")
>> without the use of timestamp information.
> That fix is now on trunk.  So if you rebuild your local Fossil using
> the latest sources, the merge should no just work - without having to
> correct the timewarp.
>
>
Thanks Richard. I will do it this weekend.

Cheers,

Offray

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Unnable to merge: Cannot find a common ancestor between the current checkout and ID

[Offray Vladimir Luna Cárdenas]

Hi,

I have a fossil repository at [1] with two branches, resulting from a
fork. I have tried the usual `fossil update` and `fossil merge ID` but I
get this message:

cannot find a common ancestor between the current checkout and f7e3308f63

I have tried with the `--baseline ID` as advised in [2], but I get the
message "lack both primary and secondary files", no matter the ID of the
supposed common ancestor. At [2] there is a reference on shunning
artifacts and I may have shunned something here, but I think that
merging should work without not shunning as a prerequisite.

[1] http://mutabit.com/repos.fossil/dataweek/
[2]
https://stackoverflow.com/questions/19104534/fossil-scm-merge-leafs-back-to-trunk

How can I merge these branches?

Thanks,

Offray

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Extending Fossil with Lua?

[Offray Vladimir Luna Cárdenas]

Hi Joseph,

Thanks for your thoughtful and detailed response. It gives me a good
view of the required effort. My intent is to extend Fossil with Lua, not
to embed it into Fossil (that could be, in the future). Extension could
be worked to decrease the natural friction and inertia you mention over
other embedding other languages and give an easy probe of concept.

I will try an organic approach to this problem. First starting with some
external functionality in the similar vein of how syntax highlighting is
done using JS  [1], then trying some bindings between JS and installed
and then I will try to enable something like Asciidoctor.js to put it in
the rendering hook, to see if, in the same way that files ended with
particular extensions can be rendered with color, I can render files
ended in 'adoc' or 'ad' using Asciidoctor.js. After that I would try
some approach that enables something similar using Lunamark[2].

[1] https://www.fossil-scm.org/index.html/wiki?name=Cookbook#source-hilight
[2] http://jgm.github.io/lunamark/

This will be a slow project. But I think that is important to increase
Fossil extensibility and scriptability. Javascript seems the easiest
path now, but at some point, some easy to embed and (kind of) more
widely used languages as Lua should be part of this ecosystem.

I will keep you updated about my advances and making documentation as I go.

I'm subscribed to the mailing list, so any answer to it will be fine also.

Cheers,

Offray

Ps: My used family name is Luna (yes, it means the same in Spanish that
Lua in Portuguese or Moon in English, but that's just a coincidence).
Here in Latin America we have two family names: one taken from the
family name of your father and other taken from the family name of your
mother, following the Spanish tradition... which seems more fair :-).

On 24/03/18 17:52, Joseph R. Justice wrote:
> [Response intentionally CC'd to the original poster, on the off chance
> he's not already subscribed to the mailing list]
>
>
> On Mon, Mar 19, 2018 at 7:42 PM, Offray Vladimir Luna Cárdenas
> <off...@riseup.net <mailto:off...@riseup.net>> wrote:
>
> This is just kind of a next semester project, but I would like to
> start
> exploring the options.
>
> I'm using Fossil mainly to store documentation (using the superb
> embedded documentation feature) for my Grafoscopio[1] project. I think
> that SQLite and Fossil are good examples of what I call pocket
> infrastructures (simple, self-contained and working well on-line and
> off-line) that can help to democratize fields like data visualization
> and storytelling[2]. But, despite its advantages, Fossil is
> starting to
> feel limited, particularly with the Yaml metadata blocks that the
> Pandoc
> Markdown variant uses[3]. So I would like to explore the
> possibility to
> use Lua (which is already integrated in Pandoc and easily
> integrable in
> other programs) to read such metadata y show it in a proper way. I
> also
> think that the support for Lua should open a lot of scriptability
> options and ecosystem, far beyond TH1 and Tcl, by using a more wide
> spread scripting language with a bigger ecosystem.
>
> [1] http://mutabit.com/grafoscopio/index.en.html
> <http://mutabit.com/grafoscopio/index.en.html>
> [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1
> <http://mutabit.com/offray/blog/en/entry/panama-papers-1>
> [3] https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> <https://pandoc.org/MANUAL.html#extension-yaml_metadata_block>
>
> What should be done to explore such Lua extensions to Fossil?
> Where can
> I start?
>
>
> Dear Mr. Cardenas (my apologies for misspelling your name, but I'm
> just Yet Another Damned Monolingual Yankee),
>
> I saw your question above when you first sent it to the fossil-users
> list, and meant to respond to it, at least to give "one bystander's
> opinion".  My apologies for taking so long to respond.  I *do*
> personally think it's an interesting idea, but for reasons I'll give
> below, it might not be as interesting to the core Fossil developers,
> at least at this point.
>
> Before I continue, I need to emphasize to the utmost extent that I am
> *not* a core Fossil developer or committer to this project; I am *not*
> an active external developer for it submitting patches or modules to
> be integrated with it; nor am I even just someone actively using it
> and perhaps submitting bug reports, documentation, user feedback,
> etc.  (Perhaps I will be some of these things at some point if I ever
> get around to getting myself a real system suitable for development,
> but at this time I am not.)  I have, however, been follow

[fossil-users] Extending Fossil with Lua?

[Offray Vladimir Luna Cárdenas]

Hi,

This is just kind of a next semester project, but I would like to start
exploring the options.

I'm using Fossil mainly to store documentation (using the superb
embedded documentation feature) for my Grafoscopio[1] project. I think
that SQLite and Fossil are good examples of what I call pocket
infrastructures (simple, self-contained and working well on-line and
off-line) that can help to democratize fields like data visualization
and storytelling[2]. But, despite its advantages, Fossil is starting to
feel limited, particularly with the Yaml metadata blocks that the Pandoc
Markdown variant uses[3]. So I would like to explore the possibility to
use Lua (which is already integrated in Pandoc and easily integrable in
other programs) to read such metadata y show it in a proper way. I also
think that the support for Lua should open a lot of scriptability
options and ecosystem, far beyond TH1 and Tcl, by using a more wide
spread scripting language with a bigger ecosystem.

[1] http://mutabit.com/grafoscopio/index.en.html
[2] http://mutabit.com/offray/blog/en/entry/panama-papers-1
[3] https://pandoc.org/MANUAL.html#extension-yaml_metadata_block

What should be done to explore such Lua extensions to Fossil? Where can
I start?

Thanks,

Offray

___
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] Experimental timeline "View Mode" changes.

[Offray Vladimir Luna Cárdenas]

Hi,


On 17/03/18 11:23, Richard Hipp wrote:
> On 3/17/18, Stephan Beal  wrote:
>> Fwiw, i prefer the Classic, with the uid at the start of the message. When
>> it's at the end, the eyes and mouse hand have to look for it in a different
>> place for every entry.
>>
> That's why I left it as an option.  But you will need to change your
> preference from "Verbose" to "Classic" when you upgrade versions.
>
>
I would like something like Classic with checksums links at left, but
with the rounded shapes and spaces from Modern... That's is what usually
happens with themes, you want mixed features of several and I don't know
if it is too much work to try to included another theme variation.

Cheers,

Offray
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Typo on Fossil Documentation

[Offray Vladimir Luna Cárdenas]

Hi,

I was reading [1] and I found that it says "langauge" instead of
"language". I tried to loging anonymously and open a ticket, but the
only feature habilitated for such profile in the tickets tab was to
search for tickets, so I report the issue here instead. I remember that
you could create tickets anonymously before, but maybe that was disabled
by anti-SPAM policies.

[1] https://www.fossil-scm.org/index.html/doc/trunk/www/embeddeddoc.wiki

Cheers,

Offray

___
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] How to revert a wiki page to a specific revision

[Offray Vladimir Luna Cárdenas]

Thanks Warren. I will change to embedded documentation for this Fossil
repo also.

Cheers,

Offray


On 07/12/17 19:35, Warren Young wrote:
> On Dec 7, 2017, at 10:41 AM, Offray Vladimir Luna Cárdenas 
> <off...@riseup.net> wrote:
>> I have been looking in the help on revert, but it seems related to files
>> and I wonder which is the command to revert a wiki page from it
>> particular version to some previous one.
>>
>> Now that web interface is changing, maybe something like the Wikipedia
>> or Dokuwiki interface to select two revisions and compare them or to go
>> from current version to a previous one, could be implemented in the WUI.
> Wiki pages are stored in much the same way as regular file assets, but the 
> features you’re looking for simply don’t exist yet, doubtless because no one 
> has wanted them badly enough to spend the time writing them.
>
> Most of the weaknesses of the current wiki scheme are fixed by moving to 
> [embedded documentation][1].  If you don’t like the longer URLs that gives, 
> Fossil recently got [a feature][2] that can help.
>
> The way I decide between wiki and embedded docs is whether the information is 
> “evergreen,” applying to multiple versions of the software equally, or if it 
> needs to be held in lock-step with the software.
>
>
> [1]: https://www.fossil-scm.org/index.html/doc/trunk/www/embeddeddoc.wiki
> [2]: https://www.fossil-scm.org/index.html/help?cmd=/waliassetup
> ___
> 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

[fossil-users] How to revert a wiki page to a specific revision

[Offray Vladimir Luna Cárdenas]

Hi,

I have been looking in the help on revert, but it seems related to files
and I wonder which is the command to revert a wiki page from it
particular version to some previous one.

Now that web interface is changing, maybe something like the Wikipedia
or Dokuwiki interface to select two revisions and compare them or to go
from current version to a previous one, could be implemented in the WUI.

Cheers,

Offray


___
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] A-B comparison of proposed timeline changes

[Offray Vladimir Luna Cárdenas]

Hi Andy,


On 29/11/17 00:45, Andy Bradford wrote:
> Thus said Offray Vladimir Luna C?rdenas on Mon, 27 Nov 2017 18:20:44 -0500:
>
>> I agree with Warren's design and improved readability by adding space.
>> Timeline now has more "air to breath" and is more pleasant to the eye.
> If you're talking about what is currently visible on
>
> http://www.fossil-scm.org/index.html/timeline
>
> then I  respectfully disagree  that it  is more pleasant  to the  eye. I
> found the  original timelines more  pleasant precisely because  they had
> more  whitespace in  them---natural whitespace  inbetween comments  from
> variable length comments. Now it all seems a blur.
>
> If  you're talking  about  something  else, maybe  an  example would  be
> helpful?
>
> Thanks,
>
> Andy

This could be an example of what I'm talking about. I found [1] more
pleasant to the eye that [2] (my current setup).

[1] http://www.fossil-scm.org/index.html/timeline
[2] http://mutabit.com/repos.fossil/mapeda/timeline

Cheers,

Offray
___
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] A-B comparison of proposed timeline changes

[Offray Vladimir Luna Cárdenas]

On 27/11/17 18:02, Warren Young wrote:
> On Nov 27, 2017, at 3:46 PM, Warren Young  wrote:
>> On Nov 27, 2017, at 3:41 PM, Richard Hipp  wrote:
>>> The big down-side is that less
>>> information is visible on a single screen now, so you have to scroll
>>> more.  But that seems to be the trend with websites these days….
>> The design ideas I tapped into this were old when desktop publishing was the 
>> new hotness.  Human factors haven’t changed in millennia.  It’s why an iPad 
>> is about the same size as books made before Gutenberg first sneezed.
> That’s an incomplete thought.
>
> My point is, what’s changed isn’t that we’re getting sloppy in web site 
> design these days, it’s that screens are finally starting to get big enough 
> and to have high enough levels of contrast and resolution that we can afford 
> to put some of the space in that book and magazine publishers have known is a 
> good idea for centuries, and which has had solid science behind it for 
> decades at least.
>
> Wall-o-text is hard to read, in any medium.
>
> My proposed design changes do not waste space, they buy readability.
>
> Also, I just want to emphasize that I do not think this is the paragon of web 
> site design.  I hope someone riffs on it and does something even better with 
> it.

I agree with Warren's design and improved readability by adding space.
Timeline now has more "air to breath" and is more pleasant to the eye.

Cheers,

Offray
___
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] Trolling GitHub for ideas

[Offray Vladimir Luna Cárdenas]

On 25/11/17 09:17, Richard Hipp wrote:
> The SQLite project is mirrored on GitHub (not by me).  This mirror
> provides a good opportunity to compare the interfaces of GitHub and
> Fossil using the same underlying data.
>
> https://sqlite.org/srcx/timeline?basic
> https://github.com/mackyle/sqlite/commits/master
>
> Your suggestions for useful features found in GitHub but missing from
> Fossil, or for pages in GitHub that work especially well and that you
> would like to see replicated in Fossil, are greatly appreciated.
>
The first think that jumps into attention are user avatars and checksums
in front of each commit. There ares some users with generic avatars and
others with custom ones. I think that some users would like to have some
small eye candy for their users inside fossil repositories, like
avatars. The checksums could be handy. Fossil seems more minimal (as we
know) and is really good to have the branches with code colors showed in
the time line.

Cheers,
Offray
___
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] Fossil-NG Bloat?

[Offray Vladimir Luna Cárdenas]

On 22/11/17 19:09, Richard Hipp wrote:
> On 11/22/17, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:
>> I'm dubious over making Fossil a client for
>> any other main DVCS out there.
> But making Fossil work as a client for Git is the cornerstone of my
> plan for world domination!  :-)
>
> One important reason that many people use Git is because so much OSS
> is hosted on GitHub and everybody wants to be part of the action.  If
> developer Alice wants to play in the OSS world, she has to use Git.
> But if Fossil were able to clone, push, and pull from Git
> repositories, that would enable Alice to use Fossil instead, opening
> the door to wider adoption.
>

I understand better now, thanks. In that context, Warren's proposal of a
single step clone + open, should be considered and improved. As long as
Fossil use/install keep as simple as now for Fossil users and current
users don't end with a kitchen sink and huge binary with a lot of flags
to support any workflow, I think your world domination plan can continue
without problem ;-).

Cheers,

Offray


___
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] Fossil-NG Bloat?

[Offray Vladimir Luna Cárdenas]

Hi Dave,


On 22/11/17 15:27, David Mason wrote:
> Also as a mere fossil user, I would find it useful if fossil could
> respond to a git client and serve files. I use Pharo, which is working
> toward integrated support for git, but I'd much rather trust my bits
> to Fossil. While the Fossil UI is nice, I see much less value in using
> a local Fossil to access a remote git/hg repo.

I'm also a Pharo User. I think that is important let a Fossil be
employed by Git clients, but I'm dubious over making Fossil a client for
any other main DVCS out there. Fossil's web interface has been pretty
useful in our workshops on data activism and visualization over there to
teach newbies (like myself) about DVCS. BTW I understand that this is
not a discussion on the capability of more expert users and devs to
implement the idea, but about how it impacts the wider community. I for
example didn't understand the original discussion about ".fossil"
because I thought it was (only) about shallow copies instead of the
default behavior for making a single step clone and open, like Git.
Making Fossil a client of majors DVCS means learning a lot of variations
on what happens to make it behave like others. Of course, we need to see
where it makes sense, but the context/motivation of that discussion will
be difficult and sometimes will scape for those of us that chose Fossil
because it was like itself, instead of because was like others.

Support for multiple VCS formats is clear as a server, but the nuances
and complexities code/learning wise it will introduce as a client should
be considered for those of us that like/choose Fossil because of its
simplicity.


>
> 2) Allow me to designate any file in the directory structure as
> unversioned.  The current unversioning model does not work well for
> me.  It essentially is equivalent to Dropbox. I am working with
> PharoJS which produces Javascript files from Smalltalk code. I want my
> source code and the generated code in Fossil. I also have movies and
> image files that I want in particular places.  I realize the Fossil
> model is to be able to revert to exactly the state of things on
> such-and-such a date, including the versions of movies and images as
> they were, but I - at least - very rarely care that images and movies
> are exactly as they were, I'd almost always be perfectly happy using
> the current version. An ideal alternative would be to have versioned
> files but where it only kept snapshots of versions I explicitly asked
> for, otherwise it would just update the current version.

I'm still trying to understand unversioned files. What I would like is
to make them sync automatically when the rest of the repo is
synchronized (via sync or commit). Something like if the unversioned
file changed locally, just send the new version to the remote repo. If
that is the intended behavior, there is something in the workflow I'm
missing.

>
> Thanks for fossil!
>

Yes. Thanks a lot!

Offray

___
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] Fossil-NG Bloat?

[Offray Vladimir Luna Cárdenas]

On 21/11/17 19:42, Warren Young wrote:
> On Nov 21, 2017, at 5:22 PM, Offray Vladimir Luna Cárdenas 
> <off...@riseup.net> wrote:
>> I don't see the point of raising this in the users list if
>> any voice we raise as users is answered as dumb or rudely by more
>> experienced users or devs.
> Since you’re replying to me, I can only take that reply as saying that my 
> reply implies that you or others are dumb, or that I am being rude.
>
> I do not intend to be rude, and I don’t think anyone here is dumb.
>
> I thought we were having a rational discussion.  Are we not?

Mostly. Unfortunately rational and polite are not always in hand. Some
FLOSS communities are evolving into having both.

Offray

___
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] Fossil-NG Bloat?

[Offray Vladimir Luna Cárdenas]

I agreed with Zoltán as also just a mortal Fossil user. Of course time
will tell if the path of Fossil-NG serves well current and future users
and others and of course everybody does what they want with their time
and effort. I don't see the point of raising this in the users list if
any voice we raise as users is answered as dumb or rudely by more
experienced users or devs.

Cheers,

Offray


On 21/11/17 18:52, Warren Young wrote:
> On Nov 21, 2017, at 4:44 PM, Zoltán Kócsi  wrote:
>> Adding unnecessary complexity to its innermost workings would open the
>> door to a maintenance hell, I think.
> If it were someone else proposing this feature as something for drh to do, 
> then I might well agree with you, but since it is drh proposing work that drh 
> will almost certainly end up doing, that changes things drastically.
>
> Not only is it his time to do with as he pleases, he also has a far better 
> chance of pulling this off, any personal brilliance aside, purely because 
> it’s apparently his own itch.
>
> Thus I cheerlead.
> ___
> 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] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

OK. My mistake. I misunderstood the post.

Cheers,

Offray


On 20/11/17 18:04, Warren Young wrote:
> On Nov 20, 2017, at 3:41 PM, Offray Vladimir Luna Cárdenas 
> <off...@riseup.net> wrote:
>> On 20/11/17 17:22, Warren Young wrote:
>>> On Nov 20, 2017, at 3:12 PM, Offray Vladimir Luna Cárdenas 
>>> <off...@riseup.net> wrote:
>>>> I thought that was the extension
>>>> the shallow cloned repository would get if no extension name was specified.
>>> If you say
>>>
>>>$ fossil clone https://fossil-scm.org fossil
>>>
>>> You get a repository file called “fossil”, not “fossil.fossil”.
>> No. I was referring to the later case (fossil.fossil)
> If you’re simply arguing that .fossil should be appended if a clone file name 
> is given but no extension is given, that’s a separate topic from anything 
> I’ve brought up.  I’m ambivalent about the idea: I’m fine with the current 
> behavior and I wouldn’t be upset if it changed.
>
>>> In my clone-and-open scheme, leaving off the final parameter above would 
>>> give you a directory called “Fossil”
>> Well my argument is related with how I setup the web server to serve
>> files ended in ".fossil", but I can just add more extensions as the
>> community decides.
> I don’t see that clone-and-open impacts that either way.  This feature would 
> be used primarily by people who want to use someone else’s repository.  If 
> they re-serve it at all, it’ll probably be via a bare “fossil server” 
> command, not pointing to a directory of fossils at all or using a front-end 
> proxy layer.
>
> I’m targeting the GitHub use case here: someone publishes a project and 
> people want to just copy the repo contents down into a local directory to 
> mess with, in the fewest steps possible.  Git allows you to do this in 2 
> steps: clone & cd.  Fossil currently requires 5, as I showed up-thread.  
> That’s a problem.
> ___
> 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] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

On 20/11/17 17:22, Warren Young wrote:
> On Nov 20, 2017, at 3:12 PM, Offray Vladimir Luna Cárdenas 
> <off...@riseup.net> wrote:
>> I thought that was the extension
>> the shallow cloned repository would get if no extension name was specified.
> If you say
>
> $ fossil clone https://fossil-scm.org fossil
>
> You get a repository file called “fossil”, not “fossil.fossil”.

No. I was referring to the later case (fossil.fossil)

>
> In my clone-and-open scheme, leaving off the final parameter above would give 
> you a directory called “Fossil”, since I propose that we reuse the /zip and 
> /tarball option from Admin > Configuration.  Since Fossil’s own repository 
> leaves that option unset, it uses the project name, which is capital-F 
> “Fossil”.
>
> The argument in this sub-thread, then, is what to call the actual repository 
> file.  I’m not wedded to .fslrepo, but it does follow established conventions 
> nicely.  .fslclone could also work, for example, though it would break the 
> 8.3 restriction that Fossil once upon a time held itself to for such critical 
> file names, since the equivalent on Windows would presumably be _fslclone.

Well my argument is related with how I setup the web server to serve
files ended in ".fossil", but I can just add more extensions as the
community decides.

Cheers,

Offray
___
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] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

On 20/11/17 17:01, Warren Young wrote:
> On Nov 20, 2017, at 2:55 PM, Offray Vladimir Luna Cárdenas 
> <off...@riseup.net> wrote:
>> On 20/11/17 16:45, Carlo Miron wrote:
>>> On Mon, Nov 20, 2017 at 9:33 PM, Warren Young <war...@etr-usa.com> wrote:
>>>
>>>> When the FILENAME parameter is not given, it produces a “Fossil” 
>>>> subdirectory containing the contents of tip-of-trunk, with the directory 
>>>> name coming from the project configuration under Admin.  The SQLite repo 
>>>> file is stored inside the subdirectory in a hidden file; I propose 
>>>> .fslrepo.
>>> Or maybe `.fossil`, as in Kyle's golang contribution?
>>> https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330
>> I would go also with ".fossil" as default extension (is the one I use
>> right now).
> .fossil as an extension for clones is one thing: it is not simply a 
> convention due to “fossil server /DIRECTORY” scanning behavior.
>
> There is no reason the hidden file need follow this convention.  In fact, it 
> would be harmful:
>
> $ fossil server /path/to/clone-and-open/checkout/directory
>
> This would find .fossil and require that you pass an empty name in the clone 
> URL.  Confusing and maybe not even possible, since http://localhost:8080 and 
> http://localhost:8080/ are normally treated as equivalent.
>
> Furthermore, we already have .fsl* at the root of a checkout.  Shouldn’t we 
> follow the existing convention?

OK. I didn't understand this totally. I thought that was the extension
the shallow cloned repository would get if no extension name was specified.

Cheers,

Offray
___
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] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

On 20/11/17 16:45, Carlo Miron wrote:
> On Mon, Nov 20, 2017 at 9:33 PM, Warren Young  wrote:
>
>
>> There is one more thing Git really gets right compared to Fossil: 
>> single-step clone-and-open.  We should be able to do the same:
>>
>> $ fossil clone https://fossil-scm.org
>>
>> When the FILENAME parameter is not given, it produces a “Fossil” 
>> subdirectory containing the contents of tip-of-trunk, with the directory 
>> name coming from the project configuration under Admin.  The SQLite repo 
>> file is stored inside the subdirectory in a hidden file; I propose .fslrepo.
> Or maybe `.fossil`, as in Kyle's golang contribution?
> https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330
>
> ㎝
>

I would go also with ".fossil" as default extension (is the one I use
right now).

Cheers,

Offray
___
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] JSON API

[Offray Vladimir Luna Cárdenas]

Stephan,

I have been an active user of the JSON API and I have explored fossil as
a backend for a distributed open data portal [1] (early alpha). So, I
just want to say you thanks for your work, get well and give priority to
your health. World needs generous, clever people and is important to
have them well.

[1] http://smalltalkhub.com/#!/~Offray/Brea

Best of luck with your operation on 2018. Take care and rest.

Cheers,

Offray

On 12/11/17 09:45, Stephan Beal wrote:
> On Sun, Nov 12, 2017 at 1:12 PM,  > wrote:
>
> Good day to you all,
>
> I have been trying to find up-to-date information about the JSON API
> built into Fossil. Is there any plans on moving forward with this?
>
>
> i'm the original developer of the JSON API, but a severe, long-term
> case of RSI (since Dec. 2014) has forced me to retire from my open
> source work (except for occasional tiny patches), thus i don't
> personally work on it any more. It's unclear if/when my damaged elbow
> nerves will ever recover, so i can't make any code-related commitments
> (my left elbow is still not fully recovered after an OP last May, and
> i've got a second operation planned for early 2018 to try to alleviate
> the problem in the right elbow).
>  
> That's not to say that the JSON API is off-limits to other developers!
> i would love to see someone take it over and actively work on it.
>  
>
> The latest information I could find is a link to a document on Google
> Docs in a mail dated back in 2013 or so, and I cannot tell when the
> document was last updated. The last time it was mentioned on the
> official fossil-users mailing list was in March 2017
> 
> (https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24857.html
> 
> )
> but simply mentioned the same Google Docs document:
> 
> https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view
> 
> 
>
>
> Those are still the current/complete docs. If someone has mutated the
> JSON code such that it no longer matches those docs, i'm not aware of it.
>  
>
> Has this API been abandoned?
>
>
> Not abandoned, just not currently actively developed.
>  
>
> It seems like a nice feature if you
> want to develop a custom UI or application that uses Fossil as a
> back-end, such as a full-blown wiki, for example.
>
>
> That's exactly what i use the JSON API for. e.g.:
>
> http://fossil.wanderinghorse.net/wikis/cson
>
> that uses a custom front-end to server/manage wiki content from/in a
> fossil repo. It uses client-side rendering using the GoogleCode wiki
> format, rather than Fossil's built-in one.
>
> -- 
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct
> of those who insist on a perfect world, freedom will have to do." --
> Bigby Wolf
>
>
> ___
> 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] toc.tcl

[Offray Vladimir Luna Cárdenas]

Hi,


On 29/08/17 20:11, Andy Goth wrote:
> On 08/27/17 21:14, dewey.hyl...@gmail.com wrote:
>> my static site generator leverages blackfriday for markdown parsing,
>> and pygment-colored code blocks are framed with "```" ... these blocks
>> do not get ignored by your script, and the commented lines inside the
>> code blocks get meddled with.
>
> "```" is not special to Fossil, so it's not recognized by my script.
> But that's easily remedied.  Please try:
>
> https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl
>
> To keep this email relevant to Fossil, let me ask if there is any
> interest in adding "```" which appears to be intended to mark a code
> block without having to indent each line.  I vote no because what we
> have works for me, but others may disagree.
>

I would vote yes. It's used in Pandoc's markdown and others and is
becoming a standard practices for documentation made with this popular
Markdown families.

Cheers,

Offray
___
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] Fossil JSON API: How to create a wiki page?

[Offray Vladimir Luna Cárdenas]

Thanks Warren,

The problem was related with the curled quotes. Now is working fine.

The simpler test was because I was getting "

curl: (6) Could not resolve host:  -d

So I was interested in see the host resolution with a simpler command.

Cheers,

Offray

On 06/06/17 20:58, Warren Young wrote:
> On Jun 6, 2017, at 5:51 PM, Offray Vladimir Luna Cárdenas <off...@riseup.net> 
> wrote:
>> When I try something similar with:
>>
>> curl -H "Content-Type: application/json" \ -d '{"authToken":
>> "mytoken",\
>>"payload": {"name": “foo", "content": "bar"}}'
>> http://localhost:8081/json/wiki/create
> You’re missing a backslash between the JSON string and the URL.
>
> The backslashes are largely for formatting reasons, so that I could continue 
> a long command onto multiple lines in the email.  I recommend that you just 
> type this as a single command, not copy-paste it as shown in the email.
>
> Also, my mailer curled one of the quotes around “foo”, which you’ve copied 
> into your command, and that will break the JSON parser.  It needs to be an 
> ASCII double quote.
>
> (I try to catch it when this happens, but sometimes my mailer is smarter than 
> I am.)
>
>> but if I do:
>>
>> curl http://localhost:8081/json/wiki/timeline
>>
>> I get:
>>
>> {"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496792951,"command":"wiki/timeline","procTimeUs":,"procTimeMs":3,"payload":{"limit":20,"timeline":[]}}%
>>
>>
>> So, wiki is properly served via JSON API from the local host.
> That’s a much simpler call.  It doesn’t require any permissions, and it’s a 
> GET call, not a POST call.  That test proves little other than that you have 
> a working JSON API in your local Fossil instance.
> ___
> 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] Fossil JSON API: How to create a wiki page?

[Offray Vladimir Luna Cárdenas]

Thanks Warren for your quick answer.

When I try something similar with:

curl -H "Content-Type: application/json" \ -d '{"authToken":
"mytoken",\
"payload": {"name": “foo", "content": "bar"}}'
http://localhost:8081/json/wiki/create

I get:

curl: (6) Could not resolve host:  -d
curl: (3) [globbing] nested brace in column 141
{"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496792818,"resultCode":"FOSSIL-3002","resultText":"'name'
parameter is
missing.","command":"wiki/create","procTimeUs":0,"procTimeMs":0}%

but if I do:

curl http://localhost:8081/json/wiki/timeline

I get:

{"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496792951,"command":"wiki/timeline","procTimeUs":,"procTimeMs":3,"payload":{"limit":20,"timeline":[]}}%


So, wiki is properly served via JSON API from the local host.

What I'm missing?

Cheers,

Offray

On 06/06/17 16:04, Warren Young wrote:
> On Jun 6, 2017, at 1:09 PM, Offray Vladimir Luna Cárdenas <off...@riseup.net> 
> wrote:
>> I don't know how the page name is supposed to be given in the URL.
> The document you point to says it’s supposed to be sent in the payload, not 
> in the request URL:
>
> $ curl -H "Content-Type: application/json"  \
>-d '{"authToken": "nunyabinness",\
> "payload": {"name": “foo", "content": "bar"} }' \
>http://localhost:8080/json/wiki/create
>
> Incidentally, I found a bug while working that incantation out: if you leave 
> off the quotes around the property names, you get 
>
> fossil: Fatal error: could not allocate response object
>
> on the console that is running the Fossil server instance.  All errors that 
> occur down the /json path should give a JSON reply, not kill off the forked 
> child with a vague and highly nonhelpful error.
> ___
> 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

[fossil-users] Fossil JSON API: How to create a wiki page?

[Offray Vladimir Luna Cárdenas]

Hi,

I've been trying to create a wiki page, ufollowing the documentation of
the Fossil JSON API
.
When I put the URL |http://myrepo.top/json/wiki/create?name=test| I get
and answer similar to:

|{"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496771043,"resultCode":"FOSSIL-3002","resultText":"'name'
parameter is
missing.","command":"wiki/create","procTimeUs":4000,"procTimeMs":4} |

I don't know how the page name is supposed to be given in the URL. I was
imagining that was similar to the way you query wiki pages, but seems
that the API is expecting something different. Could someone show me the
proper way of adding the page name to the Fossil JSON API URL?

Thanks,

Offray

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users