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 thread:
On Sat, Oct 1, 2011 at 11:22 PM, Paul Ruizendaal p...@planet.nl 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,
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.
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 body to
On Sat, Oct 01, 2011 at 09:55:36AM -0400, Richard Hipp wrote:
On Sat, Oct 1, 2011 at 9:07 AM, Paul Ruizendaal p...@planet.nl 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 jo...@britannica.bec.de
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
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:
2011/10/2 Lluís Batlle i Rossell virik...@gmail.com
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
On Sun, Oct 02, 2011 at 12:33:08PM +0200, Stephan Beal wrote:
2011/10/2 Lluís Batlle i Rossell virik...@gmail.com
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
2011/10/2 Lluís Batlle i Rossell virik...@gmail.com
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
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'.
Yes, it
2011/10/2 Lluís Batlle i Rossell virik...@gmail.com
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
On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal p...@planet.nl 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
On Sun, Oct 2, 2011 at 2:22 PM, Stephan Beal sgb...@googlemail.com 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:
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 be
2011/10/1 Lluís Batlle i Rossell virik...@gmail.com
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,
On Sat, Oct 01, 2011 at 11:12:51AM +0200, Stephan Beal wrote:
2011/10/1 Lluís Batlle i Rossell virik...@gmail.com
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
2011/10/1 Lluís Batlle i Rossell virik...@gmail.com
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
On Sat, Oct 01, 2011 at 11:23:32AM +0200, Stephan Beal wrote:
2011/10/1 Lluís Batlle i Rossell virik...@gmail.com
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
-users] minor milestone: Java client
On Sat, Oct 01, 2011 at 11:23:32AM +0200, Stephan Beal wrote:
2011/10/1 Lluís Batlle i Rossell virik...@gmail.com
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
2011/10/1 Lluís Batlle i Rossell virik...@gmail.com
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
On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal p...@planet.nl 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
On Sat, Oct 1, 2011 at 9:07 AM, Paul Ruizendaal p...@planet.nl 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
On 1 Oct 2011, at 15:28 , Stephan Beal wrote:
On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal p...@planet.nl 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
24 matches
Mail list logo
