Kind of makes you wonder what would happen if somebody else were to say the same thing in your regard: the universe might explode from all the arrogance! :surprised:

It's a little harsh, innit, to speak of "the website" and its "context" when we only have a tiny snippet of it, hmm…? If you're going to make snarky comments about websites and their contexts, you could at the very least provide that context so we can marvel at your wisdom a little more, or perhaps just admit that yes, the context is different.

EDIT: to clarify why the context is important here, as I said, Lua has libraries that can persist any function without difficulty. So obviously there is either something magical about Lua, or some very important difference in how closures are created. If some of us were willing to provide more interesting information as to why they are making claims, the rest of us could learn something.

Sorry I don't care about what YOU are arguing (your "context"). Both the webpage blurb cited by CB and I are saying that a closure's context can comprise just about anything and everything in memory at that point. I'm in agreement with the webpage blurb.

All "snarky" comments on this thread belong to either you or Flumpy. If either of you are confused about that I can certainly quote every single one of them back to y'all. I'd prefer to ignore the juvenile language war in favor of explaining Ruby and how it works.
I seriously don't give two shits about Groovy or LUA, which isn't being snarky, just delineating my area of interest here.

I think was perfectly clear in my followup about what serializing execution context for closures would entail in Ruby.

I guess I wasn't clear enough. My question to you is to try to figure out what makes Ruby closures so special that they cannot be serialized while they can be serialized in other languages. Clearly something very different is going on, because in one language (btw, it's not 'LUA' but 'Lua') we see concrete evidence of possibility whereas you are citing theoretical impossibility. So, obviously, you believe that there is some major difference. Now, at least, you have made clear that you don't give a crap about anything but Ruby, no matter what; that's cool. But you certainly have not explained Ruby or how it works, you have merely said "no", "no", "not possible", "no". In case you want a nice, clear, concise question, I gave you one just above (what is it about Ruby closures that is different from Lua – hint: it's not the fact that they can access memory). But I guess I shouldn't hold my breath on you sharing anything useful at this point, given the very clear stance you have taken. :smile:

I'm not sure, though, why you're talking to other people if you don't give a hoot about "their context" (whatever exactly that means to you).

Two of my cats tend to enjoy annoying one another at every opportunity. It is, however, somewhat unfortunate when a third cat decides they're thirsty and can't get to the water bowl because the other two are hissing, growling, and swiping at one another, effectively blocking the path between the non-combatant and the water.

Eh? Sorry… must have been typing in the wrong window… obviously no relevance to the topic.

I apologize for thinking that getting elucidation (instead of simple wave-away dismissals) on Ruby's persistence mechanisms would be useful and on-topic. My bad.

Ok I'm going to ignore the ranting. I'm honestly not attacking ruby here, I was asking a specific question because I noticed a deficiency in my own language (which mirrors ruby in some ways, being dynamic an' all) in that the metaclass cannot be serialized.



Ok let me stop you right there. Aren't Ruby procs, lamdas, iterators and the like objects too? I thought Ruby was a first class language? Therefore these things are all objects I assume?

And if we keep that in mind, why wouldn't I be able to serialize references to other objects? You know where in your code they are declared, your interpreter surely knows how to compile it? Once you've done that, backfilling the data is surely trivial. It shouldn't theoretically matter where in the 'memory' it is, and you only have to walk as far as your references take you..

Anything else, such as local context etc can be made transient and retrieved when the object is de-serialized.

Perhaps I'm just not understanding this because of my Java roots or something.





I am really desperately trying to keep this discussion about Ruby, but to answer that: actually you can serialize closures in Groovy. I've done it. In fact, the 3rd post I made says:



tbh I haven't tested the limits of this tho. Let me state it again: It was the metaclass I wanted to serialize, because it's handy and I can use "responsdsTo" instead of checking some arbitrary map.

[edited for clarity]

Yes, that is my issue as well: it should be possible to simply follow the memory wherever it takes you. If it takes you to the global symbol table, well, you want to serialize that table. If it doesn't, well, that's great. I'm not seeing where any theoretical impossibility comes from. Not trivial is not the same as impossible. That said, I'm not sure why it's hugely non-trivial, either. At the time of creation of the closure, you know what upvalues the function has – the variables in the closure if you will – what the locals are, and what the global environment pointer is. At the point of serialization, you know what everything in there refers to. So just follow the graph. It might or might not end up serializing a bunch of stuff, but again, you might want it to serialize a bunch of stuff.

Anyhow, I'll probably end up seeking elucidation elsewhere than here because I've been given the impression that the question is not welcome. If I get around to it before somebody else does, I'll post again…

I'd like to answer your last question before I leave this too:

I would like to have an object that is serialized, be de-serialized in it's entirety. Part of this entirety are the methods I add to that object, because well, without them my object isn't whole.

In other words, when I say "save me a foo with bells on" I want to get a foo with bells on back, not just a foo.

Let's look at it another way:

Forgetting the complexity of walking trees and so on etcetc. If these Lamda and Proc objects were written by yourself, for a critical application that processed data for some kind of work related project, would you want them to just disappear from existence?

It is not *impossible* to do what you want in Ruby. It is *impossible* to do so with the serialization libraries that come standard with ruby. I'm not familiar with one that will allow you to do that so you should fall back to the methods mentioned on Ruby Quiz to roll your own. Is xtream a standard lib?

Ah well, I suppose I was somehow given the erroneous impression that there was some kind of theoretical issue here. That's what the initial reply/ies to my "I don't buy it" post suggested, at least.

The Lua mechanism for very rich serialization uses C for various things. A pure Lua solution cannot serialize coroutines or closures, IIRC. I'm in the process of playing with a full serialization library, however it would appear that it has 64-bit compatibility issues… harrumph.

Yeah, Tyche had mentioned it also but I think a lot of what you guys were saying to each other was lost in frustration/whatever =)

But the question was about whether or not it's possible. So you're saying that it is possible to do it, you just can't do it with those three libraries? (which happen to come as standard)
That begs the question then: are there libraries out there to do it?

Perhaps some of the confusion came from the fact that I wasn't treating "marshal" as a proper but as a common noun. So when I say "you can marshal x", it just means serialize, store, whatever, not "do whatever the marshal library does".

No, xstream is a 3rd part xml marshalling library.

However, it does pretty much the same thing as java serialization, but I haven't tried it. Generally, if XStream can do it, so can java serialization.