Re: [fossil-users] Couple of beginner questions

[Ross Berteig]

On 3/31/2017 2:04 PM, Shal Farley wrote:

Warren wrote:
> Someone brought up TECO. I don’t expect anyone’s TECO implementation
> to handle UTF-8,


That was me...

Hmm... I was going to say in jest that the DECUS swap tapes have a 
version written in C, were anyone nuts enough to take a crack at it. 
However Google reveals that it is closer at hand than I thought - 
someone has already ported it to Windows, Mac and Linux:

https://github.com/blakemcbride/TECOC


Since I am just nuts enough and already have Git, Visual Studio, and 
past exposure to TECO thanks to Shal and others, I checked it out and 
built it on Windows 10, 64-bit. I could certainly have built it for 
32-bit, but when overdoing something, there's no point in holding back.


So I accidentally wrote a blog post about the experiment.

https://curiouser.cheshireeng.com/2017/04/01/ancient-tools-the-teco-editor-vs-utf-8-text/

The takeaway is that, surprisingly, a 54 year old ASCII based text 
editor actually can edit a Unicode document stored in UTF-8. But it is 
not very good at it.


As someone who once wrote ad-hoc utilities as TECO macros, all I can 
say is: No.


There are languages that would be less pleasant to use for transforming 
text. TECO at least was designed for the purpose. And aside from a few 
control characters it is almost entirely oblivious to the character set 
in use. Since UTF-8 was designed to leave 7-bit ASCII intact, TECO will 
"work" on UTF-8 text with a couple of constraints.


But I won't recommend you try it at home.

--
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] REST API and client for same

[Warren Young]

On Apr 4, 2017, at 11:24 AM, Paul Hammant  wrote:
> 
> > I have little need for such a thing myself, so I’m just throwing this idea 
> > out
> > there for anyone who thinks it looks like a good itch to scratch.
> 
> I do have a need for this class of use. My thread "Fossil as an app server" 
> (nearly a week ago on this list) is in the same direction. 

Only in the vaguest sort of way.

My idea is just that you should be able to replace the fossil binary as a 
client with a series of HTTP calls, which lets you replace fossil-the-client 
without duplicating all of its internal functionality.

This idea of turning Fossil into a generic application server is off on a 
completely wild tangent from that point.

While thinking about this sort of thing, consider the XSS problem just brought 
up on the mailing list.  To me, “generic application server” implies multiple 
independent — possibly mutually-untrusting — applications running on a single 
platform.  So, you’d better solve the XSS problem first.
___
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] REST API and client for same

[Paul Hammant]

>
>
> I have little need for such a thing myself, so I’m just throwing this idea
> out there for anyone who thinks it looks like a good itch to scratch.
>


I do have a need for this class of use. My thread "Fossil as an app server"
(nearly a week ago on this list) is in the same direction.

Here's something I made 8/9 years ago -  a WYSInWYG wiki on top of
Subversion using it's auto-increment feature - https://www.youtube.com/watc
h?v=WfjK0Pb6IIM. and GET/PUT (and an application in the middle). It bumped
head revision and did nothing for clash detection. I'm not going to breath
life into that again.

Here's where I'm going more recently -

0. Here's the "seatmap" app I made using CouchDB again -
http://paulhammant.com/2015/12/21/angular-and-svg-and-couchdb/. It works
with CORS enabled directly from JavaScript to CouchDB - REST-centric
PUT/GET of a resource.  CouchDB isn't a SCM, but it could be with some
enhancements. Prospective users of CouchDB should know it is insecure in
ways that security experts roll their eyes - https://blog.couchdb.
org/2017/01/24/couchdb-ransom-notes/.

1. http://paulhammant.com/2016/06/26/using-rhodecode-and-
angular1-as-an-editor-for-a-config-as-code-system/ - the last incarnation
of a thing I'm still chasing. An Angular 'form' - directly saving JSON to
HEAD revision of a Subversion or Git or Mercurial repo. Heavy lifting
courtesy of Rhodecode, which is probably maintaining working copy for me,
somehow. While the class of application (SCM backed apps) is what I'm
after, there's no REST involved here.

2. Here's me stretching my skills to make a similar editor for Github as a
backing store - http://paulhammant.com/2015/06/07/custom-json-editors-for-
github/. Again the right class of application, but no REST involved.

3. Going back in time - I coached a new starter (Logan McGrath) at my old
company into making a real config editing thing with Perforce as a backing
store - http://loganmcgrath.com/blog/2012/11/16/scm-backed-applica
tion-configuration-with-perforce/.  We wrote this thing, so we sure as shit
knew we were maintaining working copy for the client on the server. Right
class of application, no REST involved.

4. A pre-cursor for #3 - http://paulhammant.com/2012/
08/14/app-config-using-git-and-angular/ - using Git a the backing store

My nirvana is Fossil upgraded to allow discrete CRUD operations over HTTPS.
I'd prefer REST, but will live with anything that I can perform from
JavaScript in a page that was a] served up (with mime types) from the same
HTTPS interface, or b] from another site/server and interoperating with
Fossil resources via CORS.  Towards that #0 is the reference that's
relevant for the 'ask' now, and #1-#4 are supporting on the class of
application, not the precise mechanism (REST or something close enough).

I'm pretty sure it's just a question of time until doc-store and VCS
convergence happens.

As I blog around this topic area,
http://paulhammant.com/2012/11/20/very-small-data/ might be interesting too,

- Paul
___
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] SSL on Mac

[Marc Simpson]

On Tue, Apr 4, 2017 at 7:01 AM, Warren Young  wrote:
>
>
> > $ sudo mv ~/Downloads/fossil /usr/local/bin/fossil
> > $ fossil up
> > dyld: Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
>
> Looks like you should build from source, or get your binary from another
source.

The point is that official Fossil builds (from
https://www.fossil-scm.org/index.html/uv/download.html) are linked
against non-standard library paths and ought to be rebuilt:

$ otool -L fossil
fossil:
/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version
1.0.0, current version 1.0.0)
/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version
1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version
7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)
___
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] SSL on Mac

[Warren Young]

On Apr 3, 2017, at 6:13 PM, J. Cameron Cooper  wrote:
> 
> SSL: cannot connect to host chiselapp.com:443 ()

That generally means the server has tightened down its rules on what it will 
accept for an SSL connection: dropping old, broken, versions of the protocol, 
dropping old, broken ciphersuites, etc.

When that eliminates all the methods your local SSL implementation has for 
communicating with it, you get this error.

The solution is to upgrade to a newer version of the TLS/SSL library, which is 
not necessarily the same thing as upgrading Fossil itself.  It depends on 
whether Fossil is statically linked to the SSL library, and whether your system 
allows upgrading the SSL library independently to a sufficient level.

> $ sudo mv ~/Downloads/fossil /usr/local/bin/fossil
> $ fossil up
> dyld: Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib

Looks like you should build from source, or get your binary from another source.

I see that Homebrew is shipping Fossil 2.1 with Homebrew’s own private version 
of OpenSSL, so that should work nicely for you.

> I don't know much about OS X internals.

That error means the person who built those binaries had OpenSSL installed in a 
nonstandard location and dynamically linked to it, so it’ll only work on 
systems that have a third-party OpenSSL installed in the same location.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users