Thus said Stephan Beal on Wed, 24 Jul 2013 16:51:07 +0200:
This probably isn't what you want to do, but i think you could
add anonymous support by piping the /json/anonymousPassword and
/json/login calls through to manage the two-step authentication
process for anonymous
2013/7/24 Warren Young war...@etr-usa.com:
The bundled SQLite is almost certainly broken with that patch because it
probably isn't using the Cygwin 1.7.20+ F_LCK_MANDATORY feature, so it won't
cooperate properly with any program based on native Windows SQLite.
Agreed. It was just an experiment.
Native, pure-blooded windows binaries run just fine on cygwin, right? So
why are we complicating the code with exceptions, special cases, and hacks
for cygwin?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
2013/7/25 Richard Hipp d...@sqlite.org:
Native, pure-blooded windows binaries run just fine on cygwin, right? So
why are we complicating the code with exceptions, special cases, and hacks
for cygwin?
There are three things that a windows fossil binary can never do
in the Cygwin environment:
Le 2013-07-25 06:43, Jan Nijtmans a écrit :
2013/7/25 Richard Hipp d...@sqlite.org:
Native, pure-blooded windows binaries run just fine on cygwin,
right? So
why are we complicating the code with exceptions, special cases, and
hacks
for cygwin?
There are three things that a windows
On Thu, Jul 25, 2013 at 07:44:16AM -0400, Martin Gagnon wrote:
Le 2013-07-25 06:43, Jan Nijtmans a écrit :
2013/7/25 Richard Hipp d...@sqlite.org:
Native, pure-blooded windows binaries run just fine on cygwin,
right? So
why are we complicating the code with exceptions, special cases,
and
Thank you all for the ideas. I'll have a look at shunning, if it could
be used. I'll have a look at it.
Best regards,
Petr
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon eme...@gmail.com wrote:
In Theory, fossil should build and work on fossil like on any other unix
like Operating system (like linux/*bsd etc..) That's what cygwin is for.
grep tells me that there are 33 instances of the __CYGWIN__ macro in
On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote:
On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon eme...@gmail.com wrote:
In Theory, fossil should build and work on fossil like on any other unix
like Operating system (like linux/*bsd etc..) That's what cygwin is for.
grep
On Thu, Jul 25, 2013 at 8:05 AM, Lluís Batlle i Rossell vi...@viric.namewrote:
On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote:
On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon eme...@gmail.com wrote:
In Theory, fossil should build and work on fossil like on any other
unix
On 7/25/13 2:05 PM, Lluís Batlle i Rossell wrote:
[---]
grep tells me that there are 33 instances of the __CYGWIN__ macro in
Fossil, in 8 different files. So if you use sed to change them all to
__CYGWIN_OFF_ (or something else harmless) and then do ./configure; make,
does it work? (I don't
On 7/25/13 2:10 PM, Richard Hipp wrote:
Move to banish __CYGWIN__ from both Fossil and SQLite sources. Do I have a
second?
Seconded.
/Jan
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
2013/7/25 Richard Hipp d...@sqlite.org:
If it does work, then I move for the immediate banishment of all __CYGWIN__
macros.
Doing that will break four things:
- Accessing a check-out repository on Cygwin, while the previous check-out
was done in win32.
- Allow usage of win32 paths (possibly
On Thu, Jul 25, 2013 at 03:46:21PM +0200, Jan Nijtmans wrote:
2013/7/25 Richard Hipp d...@sqlite.org:
If it does work, then I move for the immediate banishment of all __CYGWIN__
macros.
Doing that will break four things:
- Accessing a check-out repository on Cygwin, while the previous
On Sun, Jul 21, 2013 at 10:12 AM, Eduardo Morras emorr...@yahoo.es wrote:
On Sun, 21 Jul 2013 12:54:05 +0200
Stephan Beal sgb...@googlemail.com wrote:
I post them here then:
a) Creation of graphs to show statistics.
I'm on it now, writing a minimal png with 32bit ARGB color and a minimal
From fossil's /shun page:
Do not shun artifacts merely to remove them from sight - set the hidden tag
on such artifacts instead.
The only other reference I could find while searching this list was a
note from drh (circa 2009 or so?) noting that it had not been
implemented yet. Is this still
On 7/25/2013 06:24, Jan Danielsson wrote:
So .. we used the __CYGWIN__ macro to explicitly break fossil on
cygwin? That seems unnecessarily creative to me.
It is well known that the creators of Cygwin do this sort of thing
because They're Just Mean. Maybe Fossil's creators are the same
On Thu, Jul 25, 2013 at 02:42:23PM -0600, Warren Young wrote:
On 7/25/2013 06:24, Jan Danielsson wrote:
So .. we used the __CYGWIN__ macro to explicitly break fossil on
cygwin? That seems unnecessarily creative to me.
It is well known that the creators of Cygwin do this sort of thing
On 7/25/2013 07:46, Jan Nijtmans wrote:
2013/7/25 Richard Hipp d...@sqlite.org:
If it does work, then I move for the immediate banishment of all __CYGWIN__
macros.
Doing that will break four things:
- Accessing a check-out repository on Cygwin, while the previous check-out
was done in
Warren Young wrote:
I'm up for some spelunking. Let's go:
What about all the __CYGWIN__ blocks in the following files?
1. add.c
2. blob.c
3. checkin.c
4. db.c
5. file.c
6. utf8.c
Frankly, I'm not convinced of how many of these are actually necessary.
--
Joe Mistachkin
It appears that gitolite works much like mercurial-server.
What I would expect (I haven't set up fossil yet, because I need this
functionality) is that the authorized_keys file for the fossilcm user
would have:
command=/home/fossilcm/bin/fossil gate admin ssh-rsa ...
On 7/25/2013 04:29, Richard Hipp wrote:
Native, pure-blooded windows binaries run just fine on cygwin, right?
Mostly, yes.
There are exceptions. The Windows console infrastructure isn't as
general and as easy to hook into a the Unix TTY equivalent, so there are
programs that only work
On 7/25/2013 16:03, Joe Mistachkin wrote:
Warren Young wrote:
I'm up for some spelunking. Let's go:
What about all the __CYGWIN__ blocks in the following files?
I guess they already got taken out of the trunk. I did my spelunking in
a current pull of the tree.
That explains why
Warren Young wrote:
I guess they already got taken out of the trunk. I did my spelunking in
a current pull of the tree.
I'm simply searching trunk for __CYGWIN__.
--
Joe Mistachkin
___
fossil-users mailing list
My apologies for taking so long to respond myself, I've been a little under
the weather the last couple of days. I appreciate the time you took in
responding to my first message on this thread.
On Tue, Jul 23, 2013 at 4:54 AM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jul 23, 2013 at
[Effing GMail sent this before it was fully responded to. My fault for
writing my response using the GMail web interface instead of composing it
in a text editor like a Real Programmer would have done.]
On Thu, Jul 25, 2013 at 9:17 PM, Joseph R. Justice jayare...@gmail.comwrote:
My apologies
On 7/25/2013 16:52, Joe Mistachkin wrote:
Warren Young wrote:
I guess they already got taken out of the trunk. I did my spelunking in
a current pull of the tree.
I'm simply searching trunk for __CYGWIN__.
I was stuck on a branch from February. wince
Now that I'm actually looking at the
On 7/24/2013 05:06, Warren Young wrote:
On 7/24/2013 02:33, Jan Nijtmans wrote:
Just wait on the Cygwin64 people to bring out a new Sqlite package with
the same fixes already done in Cygwin32.
Um, it's the same people. Me. :)
Oh, I see what you mean. I forgot that I didn't release
Some of what I wrote was based on wrong assumptions due to being stuck
here on a February branch of Fossil's repo. Now that I've looked at the
__CYGWIN__ blocks in an up-to-date Fossil trunk, I understand your post
better, Jan. Updated commentary inline below.
On 7/25/2013 15:59, Warren
29 matches
Mail list logo
