not.
To achieve the first task of cleaning up the with-fluids the most
simple solution would be to store a pointer to the dynwind stack at
each call frame and then at a return unwind the dynwind stack all the
way to that pointer. On the other hand this overhead to handle
something
On Fri 04 Jan 2013 00:36, l...@gnu.org (Ludovic Courtès) writes:
Hmm, I can’t see how ‘with-fluids’ or ‘parameterize’ could be
tail-recursive given that it uses ‘dynamic-wind’. Am I missing
something?
It doesn't use dynamic-wind.
scheme@(guile-user) ,x (lambda () (with-fluids ((foo 1)) 2
overhead, 2. I'm yet a
little ignorant
about the inner workings of guile fluids. But in principle, one add meta
information
to the fluids so that one can know that it's safe to overwrite the old
fluid.
2. The one I implemented was simply pushing things on the dynstack located
on the heap
Hi Stefan,
Stefan Israelsson Tampe stefan.ita...@gmail.com skribis:
(define f (lambda (n) (if (= n 0) (fluid-ref a) (with-fluids ((a n)) (f (-
n 1))
with the modified VM:
scheme@(guile-user) (f 1000)
$2 = 1
with the old VM, it craches. It works!
Hmm, I can’t see how ‘with-fluids
I think with-fluids could at least be semi-tail-recursive. If you imagine a
normal non-tail-recursive implementation, you might get to a point where
your continuation is going to set a fluid back to a value, and then the
*next* continuation is going to set that fluid back to *another* value.
Since
Hi BT,
BT Templeton b...@hcoop.net skribis:
Andy Wingo wi...@pobox.com writes:
[...]
Here I disagree. From the perspective of semantics and security, it's
important to be able to make assertions as to the type of value returned
by a procedure -- that (current-input-port) returns a port.
. In this case I would use all three --
expose the fluids you need to, but only if you need to; by convention,
avoid direct fluid access to other modules' fluids; and such access
should cause compile-time warnings (to give feedback to the user about
our conventions).
We should do the same for global
Andy Wingo wi...@pobox.com writes:
Hi Mark,
On Mon 18 Jul 2011 23:57, Mark H Weaver m...@netris.org writes:
From an efficiency perspective, it is much more straightforward and
reliable for a compiler to understand what operation is done by
(fluid-ref x) than (x).
This is true.
More
set of primitives.
Fluids will still exist, of course. But I think you are conflating two
things:
1) Optimizability. I don't think this matters much TBH. One could
define an inlinable parameter and have all the safety guarantees of
parameters compiling down to a fluid-ref.
2
argue that fluids are the far superior interface.
From an efficiency perspective, it is much more straightforward and
reliable for a compiler to understand what operation is done by
(fluid-ref x) than (x). Granted, this requires an assumption that
`fluid-ref' has not been set to something else
Hi,
A late reply :)
On Sun 28 Feb 2010 23:16, Neil Jerram n...@ossau.uklinux.net writes:
it was recently suggested to me that when a Guile program is running
under a debugger, and hits some kind of error, the debugger could
offer a menu of places in the program to jump back to. I think that
Hi,
I've gone through the code for fluids to understand it. And how it relates to
unification variables.
Some facts for fluids:
* Allocation is slow, can be made faster but still it seams to be slow
- Allocates on the heap
- uses a mutex
Hi,
On Wed 26 May 2010 13:16, Stefan stefan.ta...@spray.se writes:
I've gone through the code for fluids to understand it. And how it relates to
unification variables.
Some facts for fluids:
* Allocation is slow, can be made faster but still it seams to be
slow
Indeed; you don't want
On Wed 03 Mar 2010 00:52, l...@gnu.org (Ludovic Courtès) writes:
l...@gnu.org (Ludovic Courtès) writes:
Andy Wingo wi...@pobox.com writes:
But you can't / shouldn't make a new fluid every time you enter a
`catch', because currently fluids are never garbage collected! We really
need to fix
Hi Andy,
Andy Wingo wi...@pobox.com writes:
On Wed 03 Mar 2010 00:52, l...@gnu.org (Ludovic Courtès) writes:
l...@gnu.org (Ludovic Courtès) writes:
Andy Wingo wi...@pobox.com writes:
But you can't / shouldn't make a new fluid every time you enter a
`catch', because currently fluids
Hello,
l...@gnu.org (Ludovic Courtès) writes:
Andy Wingo wi...@pobox.com writes:
But you can't / shouldn't make a new fluid every time you enter a
`catch', because currently fluids are never garbage collected! We really
need to fix this. I think it's a 1.9 regression.
Indeed. We should
Andy Wingo wi...@pobox.com writes:
Efficient with-fluids: check! So on to figuring out the prompt and
abort implementations...
Prompt and abort: check! Now to finally implement catch, throw, and
all that in terms of delimited continuations... (Do I foresee a future
reply from myself
Hola,
On Thu 18 Feb 2010 23:35, Andy Wingo wi...@pobox.com writes:
Feeling a little silly replying to myself, but...
Following a pattern, are we?
On Mon 15 Feb 2010 23:07, Andy Wingo wi...@pobox.com writes:
I need an efficient with-fluids, some pieces of prompt and abort
Hi,
A brief note.
On Sun 14 Feb 2010 13:33, Andy Wingo wi...@pobox.com writes:
I am currently shaving a yak.
I wrote more about the yak:
http://wingolog.org/archives/2010/02/14/sidelong-glimpses
In it I concluded,
I need an efficient with-fluids, some pieces of prompt and abort
.
But you can't / shouldn't make a new fluid every time you enter a
`catch', because currently fluids are never garbage collected! We really
need to fix this. I think it's a 1.9 regression.
To do so effectively, I think you'd need to make fluid objects store
their values directly, so that the GC
Hi Andy!
Andy Wingo wi...@pobox.com writes:
But you can't / shouldn't make a new fluid every time you enter a
`catch', because currently fluids are never garbage collected! We really
need to fix this. I think it's a 1.9 regression.
Indeed. We should use a weak vector or some such instead
Heya,
On Sun 14 Feb 2010 15:32, l...@gnu.org (Ludovic Courtès) writes:
Andy Wingo wi...@pobox.com writes:
But you can't / shouldn't make a new fluid every time you enter a
`catch', because currently fluids are never garbage collected! We really
need to fix this. I think it's a 1.9
On Feb 14, 2010, at 10:50, Andy Wingo wrote:
My only qualm regards the number of potential pthread_key variables. My
current emacs session has about 15K functions and 7K variables. Does the
pthread_key mechanism scale well to this number of thread-local
variables?
Repeating the IRC info, for
23 matches
Mail list logo
