similar to: debug(sum) error

On 7/24/19 7:17 AM, Richard W.M. Jones wrote: > In preparation for closure lifetimes, split up the Closure so it no > longer describes a list of closures, but a single callback. > > This changes the API because functions which take 2 or more closures > now pass a separate user_data for each one. > --- > docs/libnbd.pod | 3 +- >

This has an annoying subtlety around the fact that we can pass a single user_data and multiple closures in one function call. The LIBNBD_CALLBACK_FREE function would be called several times with the same user_data in this case, which means the callback must do some kind of reference counting before the user_data can be freed. I propose that we split up Closure so it describes a single closure,

On 7/16/19 6:04 AM, Richard W.M. Jones wrote: > A Closure is a list of (usually one, but can be more) closures. In C > there is also a singe ‘void *user_data’ parameter which is passed by > the caller into the function and through as the first parameter of > each callback invocation. > > By grouping the previously separate Opaque and Callback* parameters > together we can

A somewhat random question: I'm wondering if there's any kind of trick in LLVM that would allow me to implement closures efficiently. We can assume that a closure function has a hidden parameter which points to its environment, that is, the values of the variables which were in scope at the point where the closure function was defined. The problem comes when mixing closure and

On Mon, 25 Oct 2004, Marc Ordinas i Llopis wrote: > Misha Brukman wrote: > >>1. Opcodes and intrinsics > >> > > That's not really correct. The intrinsics such as llvm.frameaddress and > > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > > the intrinsics is specifically machine-dependent, and LLVM (and its > > opcodes) are

Hello Guys, Following up my earlier mail where I am trying to write an alternative front-end for R, I had a question about accessing the closures and environments in R code. Here's the function taken and modified a little from "*Lexical Scope and Statistical Computing*" ===================================================================== f<-function(){

On 7/24/19 7:17 AM, Richard W.M. Jones wrote: > Previously closures had a crude flag which tells if they are > persistent or transient. Transient closures (flag = false) last for > the lifetime of the currently called libnbd function. Persistent > closures had an indefinite lifetime which could last for as long as > the handle. In language bindings handling persistent closures

It seems odd/inconvenient to me that the "ignore.environment" argument of identical() only applies to closures (which I read as 'functions' -- someone can enlighten me about the technical differences between functions and closures if they like -- see below for consequences of my confusion). This is certainly not a bug, it's clearly documented, but it seems like a design

Full_Name: Keith Bare Version: 2.7.1 OS: Linux Submission from: (NULL) (128.2.134.48) I observed unexpected behavior attempting to use lapply to vary parameters in generated closures. All the generated closures ran with the last parameter value in the list. Here's a simple example: > funcs <- lapply(c("alpha", "beta", "gamma", "delta"),

Dear list, I may have found a bug in model.frame.default (called by the lm function). The problem arises in my R dev version but not in my R 2.4.0. Here is my config : > version _ platform x86_64-unknown-linux-gnu arch x86_64

More thoughts on callbacks, etc. following on from: https://www.redhat.com/archives/libguestfs/2019-July/thread.html#00184 Closure lifetimes ----------------- Closures could have a lifetime if we had a little bit of support from the C library. We would generate (from C only): nbd_set_free_<fn>_<closure> (nbd, free_closure); which calls free_closure (user_data) as soon as the

Hi LLVM-devels, > Yup, I think I completely missed your point. :) funny, that if even so, I got two similar and concrete answers already: "it is suitable for LLVM, though not implemented yet" :) > > generally you are right. But only generally :) > > In particular, my example showed a feature of typical lexical closure. > > Can you explain more about what you

On 7/24/19 11:54 AM, Richard W.M. Jones wrote: > Previously closures had a crude flag which tells if they are > persistent or transient. Transient closures (flag = false) last for > the lifetime of the currently called libnbd function. Persistent > closures had an indefinite lifetime which could last for as long as > the handle. In language bindings handling persistent closures

Hmm writing a blog post about TNTC is beyond the time I have right now. Here is some high level documentation of the layout of Heap objects in GHC: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables With TNTC enabled we generate code for closures of this form: .text .align 8 .long Main_main1_srt-(Main_main1_info)+0 .long 0 .quad 4294967299 .quad 0

On Feb 14, 2012, at 10:30 AM, David Terei wrote: > Hmm writing a blog post about TNTC is beyond the time I have right now. Sure, understandable. I'm surprised someone else hasn't already :) > Here is some high level documentation of the layout of Heap objects in GHC: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables > > With

I was trying to use closures within a library as follows - foo <- local({ # some code creating local variables function() { # uses the local variables created above }) It did not work because call to do_libfixup in library replaces all the closure environments by the global environment. One way around this would be to do the replacement only for closures that have the same

On Mon, Aug 12, 2019 at 11:00:01PM +0100, Richard W.M. Jones wrote: > On Mon, Aug 12, 2019 at 01:53:56PM -0500, Eric Blake wrote: > > We then have the design question of whether to make an OClosure type, > > where C has two functions nbd_aio_pread and nbd_aio_pread_callback for > > convenience, but where other languages have only a single nbd.aio_pread > > where the

On Wed, Jul 24, 2019 at 10:02:04AM -0500, Eric Blake wrote: > On 7/24/19 7:17 AM, Richard W.M. Jones wrote: > > In preparation for closure lifetimes, split up the Closure so it no > > longer describes a list of closures, but a single callback. > > > > This changes the API because functions which take 2 or more closures > > now pass a separate user_data for each

On Feb 15, 2012, at 12:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 14, 2012, at 10:30 AM, David Terei wrote: > >> Hmm writing a blog post about TNTC is beyond the time I have right now. > > Sure, understandable. I'm surprised someone else hasn't already :) > >> Here is some high level documentation of the layout of Heap objects

Hi Duncan, Martin Here's a small patch that fixes bug 15199 reported at: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15199 I was able to reproduce the bug as Duncan had outlined just fine, but I did notice that when we debug(f), the problem went away. I later realized that f(1,,3) behaved correctly the first time it was executed, but misbehaved as documented on subsequent calls.