On Sat, Oct 01, 2011 at 02:14:38AM +0200, Stephan Beal wrote:
> Hi, all!
>
> Another minor milestone: the 2nd proof-of-concept non-HTML client, this time
> in Java. It's fairly basic, and only supports synchronous operation, but
> it's a start.
Sorry, not that I care much about JSON, but can json
2011/10/1 Lluís Batlle i Rossell
> Sorry, not that I care much about JSON, but can json be used in a way that
> a
> program *spawns* fossil and talks to it using json, until it decides it's
> enough and fossil stops?
>
In theory, yes. It just has to start fossil server --port XYZ, send its
reque
On Sat, Oct 01, 2011 at 11:12:51AM +0200, Stephan Beal wrote:
> 2011/10/1 Lluís Batlle i Rossell
>
> > Sorry, not that I care much about JSON, but can json be used in a way that
> > a
> > program *spawns* fossil and talks to it using json, until it decides it's
> > enough and fossil stops?
> >
>
2011/10/1 Lluís Batlle i Rossell
> But that's only a hack. The spawner will not know when the server will be
> listening. And killing it, will not know if anyone else uses it and it is
> working.
i don't see any other way to do it unless/until fossil is split up into a
lib. The only entry point
On Sat, Oct 01, 2011 at 11:23:32AM +0200, Stephan Beal wrote:
> 2011/10/1 Lluís Batlle i Rossell
>
> > But that's only a hack. The spawner will not know when the server will be
> > listening. And killing it, will not know if anyone else uses it and it is
> > working.
>
>
> i don't see any other
from my BlackBerry® wireless device
-Original Message-
From: Lluís Batlle i Rossell
Sender: fossil-users-boun...@lists.fossil-scm.org
Date: Sat, 1 Oct 2011 11:28:39
To:
Reply-To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] minor milestone: Java client
On Sat, Oct 01
2011/10/1 Lluís Batlle i Rossell
> Maybe you could do some http-over-stdin/stdout, and speak json there. :)
>
> I think of people wanting to write frontends to fossil.
>
i was just thinking about that while i was out shopping. It is, in
principal, possible, but fossil's heavy use of exit() as an
> Maybe you could do some http-over-stdin/stdout, and speak json there. :)
Isn't "fossil cgi" already doing that? A front-end could build the appropriate
environment variables and fork/exec "fossil cgi", feeding the post body to
fossil's stdin.
Actually, I was thinking that http/json was a more
On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal wrote:
> > Maybe you could do some http-over-stdin/stdout, and speak json there. :)
>
> Isn't "fossil cgi" already doing that? A front-end could build the
> appropriate environment variables and fork/exec "fossil cgi", feeding the
> post body to fos
On Sat, Oct 1, 2011 at 9:07 AM, Paul Ruizendaal wrote:
>
> > after every command fossil runs, exit() is called somewhere, which makes
> it difficult or impossible to chain commands together in the same app
> session.
>
> Why?
>
>
I built Fossil using the old-school unix design paradigm of a light
On 1 Oct 2011, at 15:28 , Stephan Beal wrote:
> On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal wrote:
> > Maybe you could do some http-over-stdin/stdout, and speak json there. :)
>
> Isn't "fossil cgi" already doing that? A front-end could build the
> appropriate environment variables and for
On Sat, Oct 1, 2011 at 11:22 PM, Paul Ruizendaal wrote:
> ...Yes, and this is what any wrapper program can do. For example, there are
> folks that would like to have Tcl/Jim with Fossil, I would prefer Javascript
>
(me, too, but don't tell anyone ;)
Doing fork/exec sounds expensive, but on a po
On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote:
> Doing fork/exec sounds expensive, but on a posix box there is not much
> difference between that and spawning a thread:
> http://bulk.fefe.de/scalable-networking.pdf
Please don't base decisions on questionable micro-benchmarks. for
On Sat, Oct 01, 2011 at 03:07:52PM +0200, Paul Ruizendaal wrote:
> > Maybe you could do some http-over-stdin/stdout, and speak json there. :)
>
> Isn't "fossil cgi" already doing that? A front-end could build the
> appropriate environment variables and fork/exec "fossil cgi", feeding the
> post
On Sat, Oct 01, 2011 at 09:55:36AM -0400, Richard Hipp wrote:
> On Sat, Oct 1, 2011 at 9:07 AM, Paul Ruizendaal wrote:
>
> >
> > > after every command fossil runs, exit() is called somewhere, which makes
> > it difficult or impossible to chain commands together in the same app
> > session.
> >
>
On Sun, Oct 2, 2011 at 11:58 AM, Joerg Sonnenberger wrote:
> On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote:
> > http://bulk.fefe.de/scalable-networking.pdf
>
> Please don't base decisions on questionable micro-benchmarks. fork+exec
> is significantly more expensive than thread
On Sun, Oct 02, 2011 at 11:58:33AM +0200, Joerg Sonnenberger wrote:
> On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote:
> > Doing fork/exec sounds expensive, but on a posix box there is not much
> > difference between that and spawning a thread:
> > http://bulk.fefe.de/scalable-netwo
2011/10/2 Lluís Batlle i Rossell
> As for leaks, the memory leak about annotate was at every checkin
> traversed,
> though. Does the change in that branch look fine for a merge?
Just to be clear - that's not the only leak in fossil. There many, many
places where resources are left to be cleaned
On Sun, Oct 02, 2011 at 12:33:08PM +0200, Stephan Beal wrote:
> 2011/10/2 Lluís Batlle i Rossell
>
> > As for leaks, the memory leak about annotate was at every checkin
> > traversed,
> > though. Does the change in that branch look fine for a merge?
>
>
> Just to be clear - that's not the only
2011/10/2 Lluís Batlle i Rossell
> Well, those are exactly the kind of leaks that can be forgotten about,
> thanks to
> fork().
They can be forgotten because of exit(), not fork(). fork() will duplicate
leaked memory but exit() will clean it up.
I just wanted to state the difference about tho
On Sun, Oct 02, 2011 at 12:43:25PM +0200, Stephan Beal wrote:
> They can be forgotten because of exit(), not fork(). fork() will duplicate
> leaked memory but exit() will clean it up.
Well, I meant that.
> I just wanted to state the difference about those and the 'annotate
> > leak'.
> >
>
> Ye
2011/10/2 Lluís Batlle i Rossell
> messages to this list. I invite someone understanding clearly blob.c to
> review those, because I might have understood something wrong there.
>
blob.c was actually the first code from fossil i studied really deeply
(coming from the world of C++, i was amazed t
On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal wrote:
> Isn't "fossil cgi" already doing that? A front-end could build the
> appropriate environment variables and fork/exec "fossil cgi", feeding the
> post body to fossil's stdin.
>
How's this look... a first prototype at feeding POST data in vi
On Sun, Oct 2, 2011 at 2:22 PM, Stephan Beal wrote:
> How's this look... a first prototype at feeding POST data in via CLI
> mode...
>
And here's a second attempt, the major improvement being that the command to
run can be specified in the POST data:
[stephan@cheyenne:~/cvs/fossil/fossil-json]
On Oct 4, 2011, at 12:27 AM, Paul Ruizendaal wrote:
>
> On 2 Oct 2011, at 11:58 , Joerg Sonnenberger wrote:
>
>> On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote:
>>> Doing fork/exec sounds expensive, but on a posix box there is not much
>>> difference between that and spawning a
On 2 Oct 2011, at 11:58 , Joerg Sonnenberger wrote:
> On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote:
>> Doing fork/exec sounds expensive, but on a posix box there is not much
>> difference between that and spawning a thread:
>> http://bulk.fefe.de/scalable-networking.pdf
>
> Pl
26 matches
Mail list logo
