David Mason:
> Fossil appears to be careful with memory allocation too, with very few
> raw calls to malloc, so memory allocations can be unwound.
SQLite has the "Zero-malloc" and "Application-supplied memory
allocators" options [0], which may be helpful for cases without proper
db engine
There is nothing wrong with a C library handling its internal processing
using setjmp/longjmp, as long as there's no C++ callbacks or any other way
that C++ code that might use throw/catch can be executed from within calls
to that library.
It's a little bit more work than just replacing the calls
On Mon, Jun 25, 2018 at 2:30 PM Warren Young wrote:
> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal
> wrote:
>
>> Isn't adding hundreds (literally) of gotos just as fraught with
>> opportunities for failure ;)?
>>
>
> #ifdef LIBFOSSIL
> # define FOSSIL_EXIT(n) longjmp(blabla)
> #else
> #
I was thinking it would be a little more than this, but perhaps:
# define FOSSIL_EXIT(n) (api_exit_status-=n,longjmp(blabla))
would actually be enough.
And a similar setjmp-calling macro at the beginning of each API function
would be all that would be required there.
../Dave
On 25 June
On Mon, Jun 25, 2018 at 2:30 PM Warren Young wrote:
> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal
> wrote:
>
>> Isn't adding hundreds (literally) of gotos just as fraught with
>> opportunities for failure ;)?
>>
>
> #ifdef LIBFOSSIL
> # define FOSSIL_EXIT(n) longjmp(blabla)
> #else
> #
Actually, setjmp/longjmp isn't goto, it's try-catch/throw.
It unwinds the stack, so you can only (correctly) longjmp to a point that
is in the current call-chain. Of course, this is C, so you can screw it up,
but said screw-ups are not subtle! And subtle bugs are the ones to worry
about.
I count
On Sun, Jun 24, 2018 at 11:19 PM David Mason wrote:
> I really don't understand the reticence to use setjmp/longjmp to turn all
> of these short-cut exits into library return-to-API trampolines. It
>
To be clear: that's my reticence, not Richard's. libfossil was always
effectively a
I really don't understand the reticence to use setjmp/longjmp to turn all
of these short-cut exits into library return-to-API trampolines. It would
allow you to retain all the existing fossil codebase. Rewriting the code
into library form is an interesting project, but it seems like a huge
On 6/16/18, Stephan Beal wrote:
>
> 3) Fossil effectively uses exit() to handle just about any type of
> non-allocation error. i.e. there's little library-friendly error handling
> in fossil.
Not just errors. If Fossil finds an opportunity to send a "304 Not
Modified" reply, it does so and then
On 6/19/18, Stephan Beal wrote:
> i have _no_ idea what the differences are between sha1 and
> sha1-hard,
SHA1-hard is a modified SHA1 algorithm that is resistant to the
SHAttered attack (https://shattered.io/) against SHA1 that came out
about a year ago. SHA1-hard generates the same hashes as
On Tue, Jun 19, 2018 at 11:28 AM, Stephan Beal
wrote:
> On Tue, Jun 19, 2018 at 8:13 PM Sam Putman wrote:
>
>>
>>>
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.
On Tue, Jun 19, 2018 at 8:13 PM Sam Putman wrote:
>
>>
>>> 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
On Tue, Jun 19, 2018 at 10:20 AM, Stephan Beal
wrote:
> On Mon, Jun 18, 2018 at 7:18 PM Sam Putman wrote:
>
>> A Capitalized pure-C struct being referred to as an object is not unheard
>> of! But it did lead me down
>> the wrong path.
>>
>
> Here's my little contribution to spreading the word
On Mon, Jun 18, 2018 at 7:18 PM Sam Putman wrote:
> A Capitalized pure-C struct being referred to as an object is not unheard
> of! But it did lead me down
> the wrong path.
>
Here's my little contribution to spreading the word about OO in C:
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
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
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
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%
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
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.
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 and then the
> fatal
On Sun, Jun 17, 2018 at 4:50 AM, Stephan Beal wrote:
> On Sat, Jun 16, 2018 at 11:44 PM Sam Putman wrote:
>
>>
>> An incremental refactoring of this into something more modular would
>> be a boon to maintenance and testing. Seems like a sleeping dog we can
>> let lie for now.
>>
>
> That's
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 and then the fatal
error routines could longjmp back. This would give you API safety, at
On Sat, Jun 16, 2018 at 11:44 PM Sam Putman wrote:
> I'll be reading through the codebase and documentation, some initial
> thoughts:
>
No pressure, but: i would _love_ to see someone pick up the torch and run
with it.
A bit of background: in Sept. 2011 i had the great pleasure of meeting
On Sat, Jun 16, 2018 at 3:07 AM, Stephan Beal wrote:
> On Sat, Jun 16, 2018 at 12:46 AM Stephan Beal
> wrote:
>
>> i will write a longer response when i'm back on the PC, but short version:
>>
>> - refactoring to a lib is a huge effort.
>> ...
>> More details upcoming about that first point in
On Sat, Jun 16, 2018 at 12:07 PM Stephan Beal wrote:
> libfossil had essentially all of the core-most functionality
> running (documented, too)
>
http://fossil.wanderinghorse.net/repos/libfossil/doxygen/
Ah, those were the days... (i actually _miss_ documenting software.)
--
- stephan
On Sat, Jun 16, 2018 at 12:46 AM Stephan Beal wrote:
> i will write a longer response when i'm back on the PC, but short version:
>
> - refactoring to a lib is a huge effort.
> ...
> More details upcoming about that first point in the morning.
>
So...
On Jun 15, 2018, at 4:46 PM, Stephan Beal wrote:
>
> - refactoring to a lib is a huge effort.
That’s the real trick, I think: the library needs to be part of Fossil proper,
so that it stays up to date.
That in turn means finding and maintaining a strong boundary between whatever
your
i will write a longer response when i'm back on the PC, but short version:
- refactoring to a lib is a huge effort.
- up until late 2014 i was actively working on a library port and had most
of the core features working.
- RSI struck me down and has since effectively removed me from the
29 matches
Mail list logo
