Re: [fossil-users] Using fossil with Golang (go get)

2018-06-18 Thread Mark Janssen (fossil)

On 2018-06-18 23:42, Zack Scholl wrote:

Hi Mark,

The meta tag

 

will not work for importing Go code. The first term needs to match the
import path, e.g. "X" in the `go get X` command. And "http(s)://" is
not allowed in the import path for `go get`.

Is there a fossil variable similar to "$baseurl" for the base URL
without the http(s):// ? That could be used instead to replace the
first $baseurl in that meta tag and serve as a valid import path.



I could have sworn this worked when I tested it :) . I don't think the 
variable you want exists, but you can use the following instead:





Mark
___
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] Using fossil with Golang (go get)

2018-06-18 Thread Zack Scholl
Hi Mark,

The meta tag



will not work for importing Go code. The first term needs to match the
import path, e.g. "X" in the `go get X` command. And "http(s)://" is not
allowed in the import path for `go get`.

Is there a fossil variable similar to "$baseurl" for the base URL without
the http(s):// ? That could be used instead to replace the first $baseurl
in that meta tag and serve as a valid import path.

Sincerely,

Zack

P.S. I hope this email reply worked to go on the mailing list correctly,
I'm new at this.
___
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 fossil library

2018-06-18 Thread Alek Paunov

Sorry: s/collection, UDFs/collection of UDFs/

___
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 fossil library

2018-06-18 Thread Alek Paunov

But those intricate algorithms for deduplication, hash chaining, and
merging, those would come
in handy across the board.

A bit about drift: it's a natural outcome of parallel codebases, even with
something like a common
standard. Without that, it's guaranteed, unless one of the forks doesn't
get used.



Just a thought (probably stupid, since I haven't started to study fossil 
and libfossil codebases yet):


Is it possible and feasible (i.e. will it have serious negative impact 
on performance and resources usage) if fossil internal representations 
and algorithms gradually be ported to collection, UDFs, VTables and 
sqlite memdb tables where needed?


If the above is possible, both fossil(1) and libfossil core layers could 
be written in SQL using the same sqlite extensions (eventually sharing 
big portions of the code).


Kind Regards,
Alek
___
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 fossil library

2018-06-18 Thread Sam Putman
On Mon, Jun 18, 2018 at 4:54 AM, Stephan Beal  wrote:

> On Sun, Jun 17, 2018 at 11:11 PM Sam Putman  wrote:
>
>> On Sun, Jun 17, 2018 at 6:39 AM, David Mason  wrote:
>>
>>> Just had a quick thought that might make the conversion to library much
>>> easier.
>>>
>>> If you have a relatively small API interface, each of the API functions
>>> could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h
>>>
>>
>>
> This is the kind of approach I glossed over as a "goto cleanup", so we're
>> on
>> the same track here.
>>
>> I haven't had a chance to go over some of the core C files in libfossil
>> yet,
>> curious to what degree it follows this pattern already.
>>
>
> i have to admit that you lost me at setjmp. There are certain C APIs which
> i won't touch unless absolutely forced to, and setjmp/longjmp belong to
> that category. gotos are widely used in libfossil to simplify error
> handling/deallocation within a given function.
>
>
setjmp/longmp are of course weapons of awesome power.  In this context,
just a way of goto jumping farther than
goto alone allows for.

Never use them when a simple goto will do, and it sounds like it will. I
think the proposal was to replace every crash
with the same longjmp, to simplify porting the code, but you've already
taken the time to do it right.

In libfossil, all error state is propagated as an integer, with some cases
> providing additional information in an Error object owned by the Context
> object (each Context manages, at most, one opened repo instance). The API
> docs describe, where relevant, which result codes must be considered
> fatal/unrecoverable (allocation error being the primary case). An example
> of propagating more information is SQL query preparation failure - the
> error string from sqlite would be propagated back up via the Context's
> Error object. An allocation error, on the other hand, is simply returned as
> the enum entry FSL_RC_OOM, as we can't provide more information for that
> case without more allocation (which would presumably fail).
>
>
Excellent, no surprises here.
___
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 fossil library

2018-06-18 Thread Sam Putman
On Mon, Jun 18, 2018 at 4:43 AM, Stephan Beal  wrote:

> On Sun, Jun 17, 2018 at 11:07 PM Sam Putman  wrote:
>
>> About those objects...
>>
>> What your docs call fossil(1) is written in plain C. Or rather C, Tcl,
>> SQL and TH1, if you prefer.
>> In any case, not C++.
>>
>
> liubfossil is 100% C89 except that it requires "long long" because sqlite3
> requires it. long long is not strictly C89 but all compilers supports it.
> The C++ code in the tree is simply optional high-level wrappers, intended
> primarily to allow me to "exercise" the core API, to make sure that it
> would be useful in other contexts.
>
>

Oh that's good news. A C++ wrapper is even a useful template for FFI
bindings.


> I'm still pretty convinced the work on libfossil won't go to waste.
>>
>
>> The excellent documentation alone has advanced my understanding
>> considerably.
>>
>
> :)
>
>
>> What might make sense is a sort of 'parallel construction'. Nice thing
>> about a revision control
>> system, it's got all the revisions.
>>
>> So to write a clean C libfossil, we can start with the first commit and
>> follow the breadcrumbs.
>>
>
> The only "problem" with that (for a given definition of "problem") is that
> i'm rather chaotic in terms of how i work on code: there's little rhyme or
> reason, nor any specific ordering to commits or (for the most part)
> features. You won't find any reasonable order to the timeline. The
> implementation required, of course, certain features before others, though,
> so... there is that.
>
>

It's never fun to take a forensic approach to a codebase.

This was all predicated on some references to a Context object, both in the
thread and the docs.

A Capitalized pure-C struct being referred to as an object is not unheard
of! But it did lead me down
the wrong path.



> I don't think it's strongly tied to the patch-centric model, it's a
>> (relatively) simple matter of
>> representing possible outcomes as distinct states.  There might be some
>> potentially
>> exponential bad behavior, we are talking about permutations after all.
>>
>
> It might even be feasible to store each such variation in the 'stash'
> table (llibfossil never got far enough to implement the 'stash' or 'undo'
> parts, as both depend on the merge process, which was the final "big/scary"
> hurdle left to port).
>
>
Looking like all I've got is a small chicken-and-egg problem.

Needing to port a few more modules over is a-ok.

Trouble is the repos I want to work with are c. 2018 (or ported in 2018
from older git), so they'd
be using the new hash.  I could start linking in libfossil and poke around
an older repository,
but that breaks the feedback loop. Big difference between playing around
with a library and
dogfooding it.

I got the sense from the docs that the hash is using the SQLite style
versioned API, so it follows that
the old hash code is sitting where it needs to.

Does this amount to following the style of that file for another similar
file in fossil(1)?

That's a bite small enough I might be able to chew it.
___
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] Using fossil with Golang (go get)

2018-06-18 Thread Mark Janssen (fossil)

On 2018-06-17 14:57, Zack Scholl wrote:


All you need to do is update your "Header" skin (Admin -> Skins) to
include a special meta tag that `go get` will fetch to interpret your
fossil as a Go library/program. For example, if you have a fossil
hosted at https://yourdomain.com/hello-world then you need to add the
meta tag in between the  tags:

https://yourdomain.com/hello-world";>



Works very well, thank you.
To add, easier and repo independent is: content="$baseurl fossil $baseurl">

IMO this would be a nice candidate for inclusion in the standard skins.

---
Mark
___
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] Perception of Fossil

2018-06-18 Thread Eduard
A lot of people allow wiki append by anonymous on their repos. You may choose 
not to. Maybe PR should get its own capability so you may restrict to 
authenticated or particular users (or not).


On June 18, 2018 8:39:59 AM EDT, Karel Gardas  wrote:
>On Mon, 18 Jun 2018 00:01:33 +0300
>John Found  wrote:
>
>> > Please no, this would be real security nightmare. Anyone can attack
>any fossil public repo then by simple DoS. Do not ever allow anonymous
>to play with your pristine repository! If anon needs to "push"
>something, then he/she needs to make his/her repo public and *you* can
>investigate the patch of her/him first.
>> > 
>> > Thanks,
>> > Karel
>> 
>> At first it seems you underestimate the ability of fossil to
>withstand high load. But then, there are many ways to overload web
>server without pushing bundles. My experience is that fossil is pretty
>hard to be overloaded, even on very lightweight servers.
>
>I've not been talking about DoS using CPU consumption, but rather about
>DoS based on disk size consumption. Is it that hard to create a bundle
>automatically and then push that to the remote server and do that in
>loop to consume all the drive space? Let's see then how underlying OS
>stops logging into /var/log due to partition shared with /fossil data.
>Will all the important daemons survived 0 available space etc. etc.
>
>By openning option to upload data somewhere for anyone, you put
>yourself on very danger land indeed. IMHO!
>___
>fossil-users mailing list
>fossil-users@lists.fossil-scm.org
>http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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] Perception of Fossil

2018-06-18 Thread Karel Gardas
On Mon, 18 Jun 2018 00:01:33 +0300
John Found  wrote:

> > Please no, this would be real security nightmare. Anyone can attack any 
> > fossil public repo then by simple DoS. Do not ever allow anonymous to play 
> > with your pristine repository! If anon needs to "push" something, then 
> > he/she needs to make his/her repo public and *you* can investigate the 
> > patch of her/him first.
> > 
> > Thanks,
> > Karel
> 
> At first it seems you underestimate the ability of fossil to withstand high 
> load. But then, there are many ways to overload web server without pushing 
> bundles. My experience is that fossil is pretty hard to be overloaded, even 
> on very lightweight servers.

I've not been talking about DoS using CPU consumption, but rather about DoS 
based on disk size consumption. Is it that hard to create a bundle 
automatically and then push that to the remote server and do that in loop to 
consume all the drive space? Let's see then how underlying OS stops logging 
into /var/log due to partition shared with /fossil data. Will all the important 
daemons survived 0 available space etc. etc.

By openning option to upload data somewhere for anyone, you put yourself on 
very danger land indeed. IMHO!
___
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 fossil library

2018-06-18 Thread Stephan Beal
On Sun, Jun 17, 2018 at 11:11 PM Sam Putman  wrote:

> On Sun, Jun 17, 2018 at 6:39 AM, David Mason  wrote:
>
>> Just had a quick thought that might make the conversion to library much
>> easier.
>>
>> If you have a relatively small API interface, each of the API functions
>> could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h
>>
>
>
This is the kind of approach I glossed over as a "goto cleanup", so we're on
> the same track here.
>
> I haven't had a chance to go over some of the core C files in libfossil
> yet,
> curious to what degree it follows this pattern already.
>

i have to admit that you lost me at setjmp. There are certain C APIs which
i won't touch unless absolutely forced to, and setjmp/longjmp belong to
that category. gotos are widely used in libfossil to simplify error
handling/deallocation within a given function.

In libfossil, all error state is propagated as an integer, with some cases
providing additional information in an Error object owned by the Context
object (each Context manages, at most, one opened repo instance). The API
docs describe, where relevant, which result codes must be considered
fatal/unrecoverable (allocation error being the primary case). An example
of propagating more information is SQL query preparation failure - the
error string from sqlite would be propagated back up via the Context's
Error object. An allocation error, on the other hand, is simply returned as
the enum entry FSL_RC_OOM, as we can't provide more information for that
case without more allocation (which would presumably fail).

-- 
- 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


Re: [fossil-users] A fossil library

2018-06-18 Thread Stephan Beal
On Sun, Jun 17, 2018 at 11:07 PM Sam Putman  wrote:

> About those objects...
>
> What your docs call fossil(1) is written in plain C. Or rather C, Tcl, SQL
> and TH1, if you prefer.
> In any case, not C++.
>

liubfossil is 100% C89 except that it requires "long long" because sqlite3
requires it. long long is not strictly C89 but all compilers supports it.
The C++ code in the tree is simply optional high-level wrappers, intended
primarily to allow me to "exercise" the core API, to make sure that it
would be useful in other contexts.


> I'm still pretty convinced the work on libfossil won't go to waste.
>

> The excellent documentation alone has advanced my understanding
> considerably.
>

:)


> What might make sense is a sort of 'parallel construction'. Nice thing
> about a revision control
> system, it's got all the revisions.
>
> So to write a clean C libfossil, we can start with the first commit and
> follow the breadcrumbs.
>

The only "problem" with that (for a given definition of "problem") is that
i'm rather chaotic in terms of how i work on code: there's little rhyme or
reason, nor any specific ordering to commits or (for the most part)
features. You won't find any reasonable order to the timeline. The
implementation required, of course, certain features before others, though,
so... there is that.


> I don't think it's strongly tied to the patch-centric model, it's a
> (relatively) simple matter of
> representing possible outcomes as distinct states.  There might be some
> potentially
> exponential bad behavior, we are talking about permutations after all.
>

It might even be feasible to store each such variation in the 'stash' table
(llibfossil never got far enough to implement the 'stash' or 'undo' parts,
as both depend on the merge process, which was the final "big/scary" hurdle
left to port).

-- 
- 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