Re: [fossil-users] Fossil interprets plain-text file as a binary file
On 3/27/2017 6:21 PM, Richard Hipp wrote: On 3/27/17, Ross Berteig wrote: I believe that a line is too long if it is more than about 8191 ASCII characters, a restriction based on the size of the buffer used in the diff engine. Technically, that restriction is due to the way hashes are computed on individual lines during the diff. For diffing, the file is broken up into individual lines, and every line is given a 32-bit hash that helps to speed up locating the differences. The lower 13 bits of the hash are the length of the line in bytes. The upper 19 bytes are the actual hash. Interesting. I didn't read further into the code than the definition of LENGTH_MASK and the comment that describes it in diff.c. I did wonder slightly at the name of that symbol, but it was described as the length of a line so I just ran with it. In lookslike.c we have UTF16_LENGTH_MASK which is described by the comment as being the same quantity expressed for UTF16 chars. But the comment and definition don't seem to agree. Richard, take a look at https://www.fossil-scm.org/index.html/artifact?name=3ac38fafa91d274c&ln=220-226 Line 225 would compute UTF16_LENGTH_MASK to be 13-2-1 or 10, and get 1023 for UTF16_LENGTH_MASK. But the comment says 4096 Either the code, the comment, or I are confused here. Since I'm poking at test cases for this stuff. I'll see if I can add one that probes the UTF16 line length question. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 interprets plain-text file as a binary file
On 3/27/2017 6:40 PM, Byron Sanchez wrote: That was it! I ran the command and received the output: Starts with UTF-8 BOM: no Starts with UTF-16 BOM: no Looks like UTF-8: no Has flag LOOK_NUL: yes Has flag LOOK_CR: no Has flag LOOK_LONE_CR: no Has flag LOOK_LF: yes Has flag LOOK_LONE_LF: yes Has flag LOOK_CRLF: no Has flag LOOK_LONG: no Has flag LOOK_INVALID: no Has flag LOOK_ODD: no Has flag LOOK_SHORT: no I deleted the null characters. I didn't have to address any of the other flags in my case, just the null characters. After that, fossil recognized the file as plain text again. Unexpected NUL characters in a field of normal text will definitely cause fossil to treat a file as binary. If you really do need to store a NUL byte in a text file (as some sort of delimiter, perhaps) fossil permits the over-long two byte UTF-8 encoding 0xC0 0x80 even though that is a technical violation of the UTF-8 specification. Allowing that particular over-long encoding is a common extension of UTF-8. The other flags just indicate that you have normal *nix line endings rather than CR LF endings used by DOS and Windows (and many many older systems) or the CR only endings used by older Macs. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] "CGI" command and argc
On 3/28/17, Florian Balmer wrote: > > If I may I would like to suggest that the control file passed to the > "CGI" command be read even if there's additional command line > arguments following, Since I have no way to test this, could you be specific about what change you would like to see? Perhaps by sending patch? -- D. Richard Hipp d...@sqlite.org ___ 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] Command-line output format
On Tue, 28 Mar 2017 09:16:33 +0200, Florian Balmer wrote: Citation from: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24841.html ... What can we do to help you move away from scripts that depend on the details of command-line output and toward something that is more likely to survive an update? ... Would it be better to run SQL queries directly against the repository database? ... Are new fixed-output-format commands needed in Fossil to extract information that is important to scripts? I'm working with a lot of scripts to process Fossil command-line output. The JSON interface is not available with some of the precompiled binaries I'm using, and parsing JSON from shell scripts or Windows batch files seems not so trivial. Running SQL queries directly would mean to reinvent the wheel and perform complex operations in many cases, as i.e. the output of `fossil whatis [check-in]` involves parsing and integrating all amendments to a check-in (or thorough knowledge of the internal Fossil storage format if this information is cached in some table). Therefore, I would like to vote for the command-line output to remain as stable as possible, make the suggested "fixed-output-format" the default, and carefully document modifications to the command-line output format in the Fossil change logs. +1 --Florian ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 ui` startup delay
On my Windows XP machines (one is a standard installation, the other a highly tweaked system), I noticed a considerable timeout for the web browser to appear when `fossil ui` is invoked. The delay seems to origin from StartServiceCtrlDispatcherW(), called from win32_http_service() [0] inside cmd_webserver() [1], the latter of which handling both the `fossil ui` and `fossil server` commands. The timeout occurs regardless of whether the Fossil service (`fossil winsrv`) is started, stopped, or not registered at all. Modifying the `ServicesPipeTimeout` registry setting [2] as an attempt to have StartServiceCtrlDispatcherW() abort earlier has no effect. [0] http://fossil-scm.org/index.html/artifact/a3970bdc0b?ln=642-669 [1] http://fossil-scm.org/index.html/artifact/5105d4bc1b?ln=2532 [2] https://support.microsoft.com/en-us/kb/922918 Each new `fossil ui` server that is not able to bind to the default port 8080 takes the next available port. This is also true if the Fossil service (`fossil winsrv`) is up and running, in this case `fossil ui` (or `fossil server`) brings up a new server listening to a new port. So these facilities do not seem to be linked, i.e. the `winsrv` service does not seem to be "recycled" for the `ui` and `server` commands. Also, the comment to win32_http_service() [3] states that if Fossil was running in a interactive console session, the routine would fail, and if I get it right, this is most likely true if Fossil is run with either the `ui` or `server` command. So I would like to suggest to only issue the win32_http_service() call from cmd_webserver() if `isUiCmd` evaluates to false. Maybe the checks can be omitted entirely, so that `fossil server` will be unlinked from waiting for `fossil winsrv` as well. [3] http://fossil-scm.org/index.html/artifact/a3970bdc0b?ln=637-640 Do you think this makes sense, and could be changed in Fossil? Or am I missing something important? A patched version works fine on Windows XP, the web browser shows up instantly. I've seen no problems on Windows 7 and Windows 10 with the modified version, so far. A workaround for me is to start `fossil ui` only once in a separate console (preferably with a repository name indicated, so closing the repository won't interfere with the server) and leave it running in the background, then switch to the web browser and hit F5 as necessary each time I want to see new check-ins. But running `fossil ui` from the command line is a lot more straightforward, as it navigates directly to the current check-in, without the need to switch windows and refresh pages. I must admit, submitting change requests for Windows XP may seem a little odd, I agree, but it's the wide availability of Fossil that helps me archiving my projects from my old PCs, to be able to move on, one day, maybe. --Florian ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] "CGI" command and argc
I'm currently stuck on a shared web host running FreeBSD 9.1 without any C compilers available. I'm still able to run the latest version of Fossil from [0] with some quirks (see bottom if you're interested in details). [0] http://pkg.freebsd.org/ I have created an extra CGI script to start playing with Fossil 2.1, and decided to offload the CGI options from the former CGI script to a separate control file (named `fossil.config`), i.e. from: #!./fossil directory: ../.data/fossil ... to: #!./fossil cgi fossil.config Like this, the two CGI scripts for Fossil 1.x and Fossil 2.1 can share the same CGI server setup. However, I noticed that my custom `fossil.config` file was not loaded with the above CGI script, but only this version worked: #!./fossil fossil.config The CGI script name is appended as an extra argument to the shebang command line, and Fossil refuses to read the control file if the "CGI" command is followed by more than one argument [1]. The fallback is to use `g.argv[1]` in this case. [1] http://fossil-scm.org/index.html/artifact/5105d4bc1b?ln=1834 If I may I would like to suggest that the control file passed to the "CGI" command be read even if there's additional command line arguments following, so it works the same as if the "CGI" command was omitted (and CGI mode was triggered by the GATEWAY_INTERFACE environment variable). I feel that explicitly passing the "CGI" command followed by the control file (as documented in the Fossil help) is better for later reference and script maintenance than relying on the "Fossil thinks it's reading its own CGI script but I tricked it" fallback. To get Fossil 2.1 running on my FreeBSD 9.1 shared host, I downloaded Fossil 2.1 and the OpenSSL libraries for FreeBSD 11 from [0], and grabbed a copy of libc.so.7 from a FreeBSD 11 ISO image (for `strchrnul`). These files were saved in a separate ./fossil2 directory, and the symlinks libcrypto.so.9 -> libcrypto.so.7 and libssl.so.9 -> libssl.so.7 created. Now Fossil 2.1 works fine with the following one-line CGI script: #!/usr/bin/env -S LD_LIBRARY_PATH=fossil2 fossil2/fossil fossil.config I'm always amazed about the simplicity and modest system requirements of Fossil, thanks for this masterpiece! --Florian ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Command-line output format
Citation from: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24841.html > ... What can we do to help you move away from scripts that depend > on the details of command-line output and toward something that is > more likely to survive an update? ... Would it be better to run > SQL queries directly against the repository database? ... Are new > fixed-output-format commands needed in Fossil to extract > information that is important to scripts? I'm working with a lot of scripts to process Fossil command-line output. The JSON interface is not available with some of the precompiled binaries I'm using, and parsing JSON from shell scripts or Windows batch files seems not so trivial. Running SQL queries directly would mean to reinvent the wheel and perform complex operations in many cases, as i.e. the output of `fossil whatis [check-in]` involves parsing and integrating all amendments to a check-in (or thorough knowledge of the internal Fossil storage format if this information is cached in some table). Therefore, I would like to vote for the command-line output to remain as stable as possible, make the suggested "fixed-output-format" the default, and carefully document modifications to the command-line output format in the Fossil change logs. --Florian ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
