Re: [fossil-users] Binary file merge
On 9/21/2011 3:50 PM, Stephan Beal wrote: i'm trying to figure out if that's doable with a minor tweak to the current code, but i just don't see it (but i'm not at all familiar with the diff/merge code). The first problem i see with this change now is that the is-it-binary determination is made one or two levels too deep for us to respond by launching gmerge. gmerge is not launched until after blob_diff() returns (and reports success). gmerge takes 4 options: pivot original merge other. Fossil doesn't have all of those if blob_merge() fails, so it cannot call gmerge. In order to fix this it would have to figure out in advance if the object is binary and... and do what? We don't have a binary diff algo, AFAIK. If that's the case than I too would vote for a 'gmerge' command. Soon I will be doing the exact same thing as Tomek, where I want to handle merging of my own binary data. If necessary, when that time comes, I can look into implementing the command if someone more knowledgeable about that code doesn't beat me to it first :) Barring that, and not looking at the code right now, there could be a binary diff algo in Fossil that just reports a "Failed: Can not merge binary files" so if there is no user configured merge tool set, it still ends up with the same results. ___ 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] Binary file merge
On Wed, Sep 21, 2011 at 9:08 PM, Tomek Kott wrote: > As I see it, fossil doesn't need to know what the binary file is...it just > needs to call the external program. If the program can't handle it, then > presumably it would return an error anyway, and hence the same error message > would come out...Am I missing something? > That makes sense to me. > Maybe what I'm really asking for is for a "fossil gmerge" command that > would work the same as the fossil "gdiff" command. CUrrently, fossil has no > problem using gdiff on binary files. > i'm trying to figure out if that's doable with a minor tweak to the current code, but i just don't see it (but i'm not at all familiar with the diff/merge code). The first problem i see with this change now is that the is-it-binary determination is made one or two levels too deep for us to respond by launching gmerge. gmerge is not launched until after blob_diff() returns (and reports success). gmerge takes 4 options: pivot original merge other. Fossil doesn't have all of those if blob_merge() fails, so it cannot call gmerge. In order to fix this it would have to figure out in advance if the object is binary and... and do what? We don't have a binary diff algo, AFAIK. At least that's my understanding of it. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] any interest in integrating jimtcl w/fossil?
On 09/21/11 20:16, Martin S. Weber wrote: > Absolutely. Rest assured, I do: > > On 09/20/11 15:00, Martin S. Weber wrote: > > Of course if you're an IDE person, you'll > > appreciate easier integration with, say, the behemothian eclipse, the > > leviathan netbeans, the Zizian IDEA or the all-encompassing emacs. > > Sorry I forgot to mention the humongous VisualXXX ;) > LOL, sorry that I missed the mentioned post. :-) Regards, Ingo ___ 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] Binary file merge
To be clear, I'm not saying that fossil needs to handle the binary merge. That's why the external program is there. The user (who would generically know what kind of binary files are used in the repo) provides a shell script for the gmerge command. Fossil calls gmerge (if present) when there is a binary file (or a merge that goes haywire). The shell script goes through and decides the merge tool to use (for my case, lvmerge for the labview code) in the correct format (lvmerge "%baseline" "%original" "%merge" "%output"). In my case, this repository only handles these kinds of files, so instead of the shell script, I can call lvmerge directly. As I see it, fossil doesn't need to know what the binary file is...it just needs to call the external program. If the program can't handle it, then presumably it would return an error anyway, and hence the same error message would come out...Am I missing something? Maybe what I'm really asking for is for a "fossil gmerge" command that would work the same as the fossil "gdiff" command. CUrrently, fossil has no problem using gdiff on binary files. Tomek On Wed, Sep 21, 2011 at 2:46 PM, Stephan Beal wrote: > On Wed, Sep 21, 2011 at 8:42 PM, Tomek Kott wrote: > >> Then can I put in a feature request for gmerge to support binary file >> merging? With the assumption that the user will (through a system dependent >> method, like a shell script) call the appropriate binary file merger for the >> binary file type passed in? That would make my (merging) life much easier. I >> think that's the way that the diff command works currently. >> > > IIRC (but i won't promise that i do!), this discussion came up a few years > ago and the general opinion was (again, IIRC) that a binary merge is not > generically possible. To merge contents of binary files the merging program > has to understand their structure. e.g. i can't just (via a generic algo) > replace 17 bytes of a ZIP file (binary file) with 21 (or 5 or N) bytes > brought in by a merge because i'll corrupt it. The internal zip header's > idea of that field is now wrong (or i might have overwritten part of that > field via the merge). The same applies to any non-random binary data (but > who's versioning random data?). > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] Binary file merge
On Wed, Sep 21, 2011 at 8:42 PM, Tomek Kott wrote: > Then can I put in a feature request for gmerge to support binary file > merging? With the assumption that the user will (through a system dependent > method, like a shell script) call the appropriate binary file merger for the > binary file type passed in? That would make my (merging) life much easier. I > think that's the way that the diff command works currently. > IIRC (but i won't promise that i do!), this discussion came up a few years ago and the general opinion was (again, IIRC) that a binary merge is not generically possible. To merge contents of binary files the merging program has to understand their structure. e.g. i can't just (via a generic algo) replace 17 bytes of a ZIP file (binary file) with 21 (or 5 or N) bytes brought in by a merge because i'll corrupt it. The internal zip header's idea of that field is now wrong (or i might have overwritten part of that field via the merge). The same applies to any non-random binary data (but who's versioning random data?). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Binary file merge
Then can I put in a feature request for gmerge to support binary file
merging? With the assumption that the user will (through a system dependent
method, like a shell script) call the appropriate binary file merger for the
binary file type passed in? That would make my (merging) life much easier. I
think that's the way that the diff command works currently.
Thanks,
Tomek
On Wed, Sep 21, 2011 at 2:35 PM, Stephan Beal wrote:
> On Wed, Sep 21, 2011 at 8:16 PM, Tomek Kott wrote:
>
>> I guess the question is, does fossil even attempt to launch the gmerge
>> tool when merging binary files?
>>
>>
> The code says...
>
> The merge command ends up calling merge_3way(), which does:
>
> zGMerge = db_get("gmerge-command", 0);
> if( zGMerge && zGMerge[0] ){
> ... go run gmerge ...
> }
>
> The error string you report is not triggered until after merge_3way()
> returns, and only if merge_3way() returns <0. merge_3way() returns <0 if
> blob_merge() returns <0, so, which leads us to blob.c...
>
> blob_merge() says:
>
> ** The return is 0 upon complete success. If any input file is binary,
> ** -1 is returned and pOut is unmodified. If there are merge
>
> So it seems that binary merges are not supported at all (at least that's
> how i interpret it).
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
>
> ___
> 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] Binary file merge
On Wed, Sep 21, 2011 at 8:16 PM, Tomek Kott wrote:
> I guess the question is, does fossil even attempt to launch the gmerge tool
> when merging binary files?
>
>
The code says...
The merge command ends up calling merge_3way(), which does:
zGMerge = db_get("gmerge-command", 0);
if( zGMerge && zGMerge[0] ){
... go run gmerge ...
}
The error string you report is not triggered until after merge_3way()
returns, and only if merge_3way() returns <0. merge_3way() returns <0 if
blob_merge() returns <0, so, which leads us to blob.c...
blob_merge() says:
** The return is 0 upon complete success. If any input file is binary,
** -1 is returned and pOut is unmodified. If there are merge
So it seems that binary merges are not supported at all (at least that's how
i interpret it).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] any interest in integrating jimtcl w/fossil?
On Wed, Sep 21, 2011 at 8:12 PM, Ingo Koch wrote: > Please keep in mind that such an API should not only help implementing > language > bindings for fossil but should also support tool makers. > We're all agreed on the many potential benefits, i think. The only hurdle is the size of the task. It would be a major overhaul. That's not to discount the idea - i'm all for it. i did in fact start to do this way back in 2008, but quickly found that fossil's use of exit() as an error handling strategy (which makes sense in a standalone app) was just the first of several big worms i'd have to deal with. An other thing: > Seeing how much fossil developer related traffic currently is on the > mailing > list, maybe it is time to setup a new fossil-deve...@lists.fossil-scm.org? > Richard suggested that last week, but i don't think he's gotten around to it yet. For the sake of the non-dev users, who are certainly sick of my chatter by now, i hope he (or someone else with admin access? Bueler?) finds some time for it. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] any interest in integrating jimtcl w/fossil?
On 09/21/11 14:12, Ingo Koch wrote: On 09/20/11 15:53, Martin S. Weber wrote: On 09/20/11 19:20, Steve Bennett wrote: It is the interface to fossil which is important. Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. Absolutely. Rest assured, I do: On 09/20/11 15:00, Martin S. Weber wrote: > Of course if you're an IDE person, you'll > appreciate easier integration with, say, the behemothian eclipse, the > leviathan netbeans, the Zizian IDEA or the all-encompassing emacs. Sorry I forgot to mention the humongous VisualXXX ;) Regards, -Martin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Binary file merge
Hi folks, I use fossil for some LabView development (among other dev work). For those not familiar with it, it's a graphical programming environment, and the files are binary. That in itself isn't a big deal. Especially because we're provided with a merge tool. I've tested out the merge command I pass I set up in fossil (for gmerge): lvmerge "%baseline" "%original" "%merge" "%output" However, when I go to merge two branches, fossil just says "* Cannot merge binary file Measurements/Resistance/DC/Get Resistance.vi" without launching the merge tool. I guess the question is, does fossil even attempt to launch the gmerge tool when merging binary files? Thanks, Tomek ___ 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] any interest in integrating jimtcl w/fossil?
On 09/20/11 15:53, Martin S. Weber wrote: > On 09/20/11 19:20, Steve Bennett wrote: >> It is the interface to fossil which is important. > > Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll > have time for that (at least rounding up an API suggestion) next week. Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. I'm working on a C# library to use fossil commands and a Windows GUI for fossil (with the goal of Visual Studio integration) and I really miss a library like the one that exists for SQLite. Implementing tools around fossil would be so much easier if a library would be available. An other thing: Seeing how much fossil developer related traffic currently is on the mailing list, maybe it is time to setup a new fossil-deve...@lists.fossil-scm.org ? I think it would make sense to split because users looking for answers regarding their day to day usage problems and not being directly interested in development of fossil should not be bothered with development topics. Maybe someone of the active developers asks Richard to set up a new list? Regards, Ingo ___ 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] binary in JSON: maybe there is some hope...
On Wed, Sep 21, 2011 at 4:05 PM, Stephan Beal wrote: > From what i've read, his proposal is just that - to encode (as a string) > non- > It turns out i completely misunderstood what he's doing there. He's encoding the JSON itself as binary, as opposed to encoding binary data in JSON. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RFC: JSON error reporting conventions
Hi, all! Currently the JSON API reports app-level errors by setting a resultCode property to a string in the form FOSSIL- (==4-digit, left-zero-padded decimal integer). i used that because i already had code which did it and it works well in the project i stole that from. While tinkering with adding "non-fatal warnings" support i'm trying out plain integer values (the part of FOSSIL-) instead. So the different looks like: resultCode: "FOSSIL-1234" vs resultCode: 1234 Has anyone got any strong arguments in favour of one or the other? i'm tending now towards the second form, and the only reason i haven't done it already is because the first form is used in the docs so much ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 request: edit files via web interface
On Wed, Sep 21, 2011 at 11:10 AM, Stephan Beal wrote: > On Wed, Sep 21, 2011 at 5:59 PM, Bill Burdick wrote: > >> back through a server to get it. The data scheme essentially allows a >> client to emulate a web server for itself (note the mime-type in the >> example). >> > > Thank you for the explanation. Are data URLs always (or normally) > base64-encoded or do they allow arbitrary encodings? (i assume the latter > since the URL contains the encoding name?) If data URLs most commonly use > one format or another, i would strongly prefer to use that same format for > transferring binary over JSON (simply via "portability via ubiquity" > reasons). > No problem! It looks like you can choose base-64 or ascii (with %-escaped hex octets). This covers all of the details: http://en.wikipedia.org/wiki/Data_Uri Bill ___ 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 request: edit files via web interface
On Wed, Sep 21, 2011 at 5:59 PM, Bill Burdick wrote: > back through a server to get it. The data scheme essentially allows a > client to emulate a web server for itself (note the mime-type in the > example). > Thank you for the explanation. Are data URLs always (or normally) base64-encoded or do they allow arbitrary encodings? (i assume the latter since the URL contains the encoding name?) If data URLs most commonly use one format or another, i would strongly prefer to use that same format for transferring binary over JSON (simply via "portability via ubiquity" reasons). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 request: edit files via web interface
On Wed, Sep 21, 2011 at 10:43 AM, Stephan Beal wrote: > On Wed, Sep 21, 2011 at 5:27 PM, Bill Burdick wrote: > >> Maybe this is obvious, but a client-side editor could use data-scheme URIs >> to display intermediately edited data before you commit it to Fossil. >> > > It wasn't obvious to me, certainly. Naively i will ask: would that provide > any benefit to that over e.g. base64-encoding to an arbitrary JSON field? > The client has the binary data, so how/where he intends to encode it to > (data URL or in the request JSON) is pretty much up to him. Or am i missing > the point of the proper use of data urls? > The "data" scheme is for actually displaying the binary data, like an image, in a client. Displaying an image in a client is easy if the data came as a stand-alone HTTP document (like as the source of an image element) but if you get an image as part of a stream, like inside a JSON response, and you want to display it in a browser using an image tag or a canvas, you need a URL for that data and that's where the "data" scheme comes in. It allows you to provide that data in-line, rather than as an HTTP request, so you can construct a data URI from the data you got from JSON. That means you can process the image in the client and display the result without having to go back through a server to get it. The data scheme essentially allows a client to emulate a web server for itself (note the mime-type in the example). Bill ___ 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 request: edit files via web interface
On Wed, Sep 21, 2011 at 5:27 PM, Bill Burdick wrote: > Maybe this is obvious, but a client-side editor could use data-scheme URIs > to display intermediately edited data before you commit it to Fossil. > It wasn't obvious to me, certainly. Naively i will ask: would that provide any benefit to that over e.g. base64-encoding to an arbitrary JSON field? The client has the binary data, so how/where he intends to encode it to (data URL or in the request JSON) is pretty much up to him. Or am i missing the point of the proper use of data urls? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 request: edit files via web interface
On Wed, Sep 21, 2011 at 5:18 PM, Bill Burdick wrote: > data:image/gif;base64,R0lGODlhEAAOANUAAMyZNP/ > That's very good news because it (possibly) means that many JSON-consuming clients will (probably) provide base64 en/decoding APIs so that clients can construct/destruct these. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 request: edit files via web interface
On Wed, Sep 21, 2011 at 10:18 AM, Bill Burdick wrote: > On Tue, Sep 20, 2011 at 4:22 AM, Stephan Beal wrote: > >> On Tue, Sep 20, 2011 at 1:38 AM, Joshua Paine wrote: >> >>> On 9/19/2011 7:15 PM, Stephan Beal wrote: >>> and JS cannot natively deal with binary data (that's coming in v5 or >>> >>> whatever new version is coming soon). >>> >>> Standard javascript doesn't have this ability yet, but individual impl >>> have relevant capabilities. E.g., privileged JS in XUL has access to files >>> and can get base64 strings from them, and the canvas element has a toDataURL >>> method that returns base64 encoded data plus a tiny amount of metadata. >> >> >> The JS version accompanying HTMLv5 (i don't remember the version number) >> contains some support for binary data. Some browsers have already started >> implementing this and some apps already use it (e.g. gmail). >> >> So the option for binary data certainly can't be ruled out altogether. >> OTOH, while JS is expected to (==i expect) be the primary client, there will >> likely be other platforms out there for which base64 is more convenient. >> > > The "data:" URI scheme works well for this. There are examples on this > page: > http://www.websiteoptimization.com/speed/tweak/inline-images/folder-test.htmland > here is a data url that may work, if it comes through properly in this > email: > > > data:image/gif;base64,R0lGODlhEAAOANUAAMyZNP/MZ7OBG8uYM4ODg8jIyLqHIriFIK58FplnAcmWMaBuCJ5sBpxqBG1tbb2KJf/mgbWCHceUL7B+GIyMjMCNKKNxC5poAsKPKreEH0tLS7+MJ6h2ENOgO/f399ypROazTrSBHLyJJKVzDe+8V97e3vjFYKt5E//0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///wAAACH5BAAALAAQAA4AAAaWwNkMMFBIVCmhcglYYgrJpbApq8pmD0MmIpioPLPBC0UmSxGU0kzhgrTe8IroEBIIVBJWS7qEzCwULSsAVoVVJjILDhgBAzIvkJGQJDIMMRUBLTIunJ2cIDINMQ8BGzIsqKmoHzIXMQYBBzIrtLW0HTIJDipcEwgnHCMWCwwNFwkaBCkFBDHOz9AxBAUzKSow2NnaMEhBADs= > Maybe this is obvious, but a client-side editor could use data-scheme URIs to display intermediately edited data before you commit it to Fossil. Bill ___ 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 request: edit files via web interface
On Tue, Sep 20, 2011 at 4:22 AM, Stephan Beal wrote: > On Tue, Sep 20, 2011 at 1:38 AM, Joshua Paine wrote: > >> On 9/19/2011 7:15 PM, Stephan Beal wrote: >> >>> and JS cannot natively deal with binary data (that's coming in v5 or >> >> whatever new version is coming soon). >>> >> >> Standard javascript doesn't have this ability yet, but individual impl >> have relevant capabilities. E.g., privileged JS in XUL has access to files >> and can get base64 strings from them, and the canvas element has a toDataURL >> method that returns base64 encoded data plus a tiny amount of metadata. > > > The JS version accompanying HTMLv5 (i don't remember the version number) > contains some support for binary data. Some browsers have already started > implementing this and some apps already use it (e.g. gmail). > > So the option for binary data certainly can't be ruled out altogether. > OTOH, while JS is expected to (==i expect) be the primary client, there will > likely be other platforms out there for which base64 is more convenient. > The "data:" URI scheme works well for this. There are examples on this page: http://www.websiteoptimization.com/speed/tweak/inline-images/folder-test.htmland here is a data url that may work, if it comes through properly in this email: data:image/gif;base64,R0lGODlhEAAOANUAAMyZNP/MZ7OBG8uYM4ODg8jIyLqHIriFIK58FplnAcmWMaBuCJ5sBpxqBG1tbb2KJf/mgbWCHceUL7B+GIyMjMCNKKNxC5poAsKPKreEH0tLS7+MJ6h2ENOgO/f399ypROazTrSBHLyJJKVzDe+8V97e3vjFYKt5E//0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///wAAACH5BAAALAAQAA4AAAaWwNkMMFBIVCmhcglYYgrJpbApq8pmD0MmIpioPLPBC0UmSxGU0kzhgrTe8IroEBIIVBJWS7qEzCwULSsAVoVVJjILDhgBAzIvkJGQJDIMMRUBLTIunJ2cIDINMQ8BGzIsqKmoHzIXMQYBBzIrtLW0HTIJDipcEwgnHCMWCwwNFwkaBCkFBDHOz9AxBAUzKSow2NnaMEhBADs= Bill ___ 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] binary in JSON: maybe there is some hope...
On Wed, Sep 21, 2011 at 3:55 PM, Joshua Paine wrote:
> Precisely because it adds no types, it doesn't have anything to say about
> "what do I do if the data I want to send isn't one of the JSON types?"
>
>From what i've read, his proposal is just that - to encode (as a string)
non-JSON (primarily binary) types, basically as a list containing a type tag
and the byte values. After reading over more of it, i think it might be
easier/more portable (but perhaps less space-efficient) to recycle sqlite3's
blob-as-text format ("Xaabbccdd..."). That's trivial to encode/decode in all
but the most restrictive environments, though it may not be efficient to to
do. e.g. in JavaScript we could decode to an array (internally a linked list
or some such, so it'd have a HUGE overhead if we store only 1 byte per array
element) but we can't use a string because we can't change bytes of a JS
string (we can only create new strings). Some native-level JS toolkits
provide a ByteArray class for efficiently handling binary data, and the new
JS has various new array types for handling them. But JSON itself doesn't,
so i can't rely on any of those :/.
i was briefly very hopeful, but somehow i'm not anymore :/. (Nonetheless, i
find his proposal interesting for other specific use cases, and might find a
use for it elsewhere.)
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] any interest in integrating jimtcl w/fossil?
On Wed, Sep 21, 2011 at 3:53 PM, Martin S. Weber wrote: > Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll > have time for that (at least rounding up an API suggestion) next week. > i recently went through a very similar migration/refactoring (on a much smaller scale, but the exact same problems), and have some ideas about this. i would be VERY interested in assisting if you (or someone else) would take the reigns. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] binary in JSON: maybe there is some hope...
On 9/21/2011 9:29 AM, Stephan Beal wrote: his proposal adds binary support to JSON without actually extending JSON with new data types. It won't help you any. All that proposal is about is an alternate, non-text serialization for JSON data to avoid the expense of converting to text and back again, e.g., for an object database or some wire transmission scenarios. Precisely because it adds no types, it doesn't have anything to say about "what do I do if the data I want to send isn't one of the JSON types?" -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] potential backwards-compatible solution to the multi-login problem
Hi, all, i think i've found a backwards-compatible solution to the multi-login problem and wanted to run it by people familiar with the problem so that they can spot any holes in my thought process before i start hacking... (Just a quick reminder: while the lack of multiple logins is only a minor nuisance in the HTML interface (i've never needed multiple logins), in the JSON interface it will quickly become a hurdle.) Currently the login info is stored in the user table for non-anonymous users. For anonymous users we rely 100% on the cookie/auth token, which is a hash of various things and fossil can tell if it's been tampered with. (The cookie handling is very impressive, if you ask me.) My proposal would be to store the login-related info in a new table, keeping the same fields/algorithms as we currently use in the user table. The down-side would be that we could theoretically end up with arbitrary many stale login entries in the db (which could theoretically be used as attack vectors). The up-side is that we could support multiple logins per user this way. We could periodically purge contents which are older than X minutes/days/whatever (config option), and the number of login entries are very, very unlikely to every reach a point which notably impacts the db file size (we're talking probably <100 bytes per record). We could also limit the number of concurrent logins, purging the oldest ones for a given user if we go over the limit (config option). Logins would of course be excluded from syncing, and would in effect become a part of the local fossil db file (a non-critical part - the table could be dropped/emptied without affecting fossil's behaviour except that it would effectively log everyone out). A new command could be added which would force a cleanup of any stale (optionally all) login tokens (e.g. fossil login purge). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] any interest in integrating jimtcl w/fossil?
On 09/20/11 19:20, Steve Bennett wrote: The simple answer is, No, you will not be able run (any) Tcl code unaltered. Thanks for that info. It may not be unreasonable to allow an arbitrary language binding to fossil. Indeed. I've been looking into jim / tcl mostly because of Th1. j/t are a superset of Th1 - the logical alternatives (python, ruby, lua, forth, guile, ...) aren't. As I've written earlier, I'd really like to see a list of all the commands and subcommands of tcl on one side, and all of the commands and subcommands of jim on the other side, and an indicator whether a) jim does not support given command and/or subcommand, b) jim supports it but with differences, c) jim supports it and it behaves idempotent to the tcl command/subcommand, d) a) or b) is the case but by loading package x it becomes c). Without this information IMO it is impossible to do an informed choice on whether to use jim or tcl. I understand, but this is not trivial since there are some subtle differences which go beyond commands existing or not. Exactly that's why I'd expect the implementors of jim to document that as they go along implementing it. They are the ones who know best about the compatibility. I don't think the design proposal needs to care too much about the language features. Hmm, somewhat. If there will be language bindings, there will be a first one, perceived as the default. Choosing that first one (and/or the one that fossil uses on its own fossil) is tricky. But that's step #2 ... It is the interface to fossil which is important. Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. -Martin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] binary in JSON: maybe there is some hope...
Hi, all! A guy just posted this on the json mailing list: https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/edit?hl=en_US&pli=1 his proposal adds binary support to JSON without actually extending JSON with new data types. i haven't read all the way through it, but what i've read so far sounds reasonable enough. Just something to keep in mind once we get to a point where handling binary becomes necessary (e.g. committing arbitrary files over JSON). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] First JSON timeline demo
On Wed, Sep 21, 2011 at 1:00 AM, Nolan Darilek wrote: > Is it possible to dump all structures to the same call, then require > clients to intelligently determine which is which? > It is, of course, but i need to develop them independently (look at timeline.c:page_timeline() and you'll see why). Once the independent commands work, it's easy to merge them into a structure which contains different chunks for the wiki/ticket/commit info. It will also be easy to alias them to e.g. /json/timeline?t=ci (which is how the which-type distinction is currently made). > Seems like it should be fairly trivial on the client side. Mind you, I'm > not opposed to separate calls either, I just wonder why the different > structures automatically rule out someone taking up the challenge of > differentiating them in whatever clients they've dreamed up? > It doesn't actually - the complication is in the server-side implementation. page_timeline() is a beast (almost 400 lines long), and my brain needs smaller chunks to work with. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
