Re: [fossil-users] Using fossil with Golang (go get)
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)
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
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
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
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
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)
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
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
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
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
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
