Re: [fonc] s3 slides
Title: Re: [fonc] s3 slides Folks, On slide #42, Gezira, Shouldn't the top line be Max and not Min? Otherwise every edge contributes at least 1 to every pixel, no matter where it is! Or, am I grossly misunderstanding this? On slide #39, Maxwell's Equations, are you aware that they can be derived from just electrostatics (F = e1*e2/(r1-r2)^2) and the Lorentz transformation of special relativity. "From our present vantage point, the magnetic interaction of electric currents can be recognized as an inevitable corollary of Coulomb's law. If the postulates of relativity are valid, if electric charge is invariant, and if Coulomb's law holds, then the effects we commonly call "magnetic" are bound to occur. They will emerge as soon as we examine the electric interaction between a moving change and other moving charges." Electricity and Magnetism (Berkeley Physics Course - Volume 2) by Edward M. Purcell (1965) p173 This means that magnetism with all its funny properties is simply caused by ordinary charges moving at relativistic speeds (often inside an atom). The existence of a magnet is proof of special relativity. It is also very cool to be able to have a counter-intuitive relativistic effect that you can hold in your hand and play with! --Ted. -- Ted Kaehler http://www.squeakland.org/~ted/ (home) 3261 Montecito Drive, Las Vegas, NV 89120. voice (702) 456-7930 Puzzle: Faucets in a bathroom sink can either have long handles that turn opposite directions, or both can turn counter-clockwise to open. Is there any direction that a hot or cold faucet can turn and be incorrect in both schemes? --Ted. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Questions about id / paper "Open, extensible object models"
Hi,
On http://www.cs.ucla.edu/~awarth/
I find http://www.vpri.org/pdf/obj_mod_RN-2006-003-a.pdf
And on http://vpri.org/fonc_wiki/index.php/Main_Page
I find http://piumarta.com/software/cola/objmodel2.pdf
Is the latter paper an updated version of the former one?
Also, in an email Michael Fig wrote ("My visit to VPRI"): "Ian also
redesigned the Id object model to make it simpler and more flexible,
which drastically reduced the size of libid." -- Does this mean the
implemented Id is different from the one described in either of those
papers or is one of them up-to-date? What are the differences, or where
should I start to read the source to find out? (Or what are interesting
commits in SVN history?)
Greetings,
- Felix
signature.asc
Description: OpenPGP digital signature
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Questions about id / paper "Open, extensible object models"
Felix,
On Jun 13, 2008, at 12:40 PM, Felix Rabe wrote:
Is the latter paper an updated version of the former one?
Yes.
Also, in an email Michael Fig wrote ("My visit to VPRI"): "Ian also
redesigned the Id object model to make it simpler and more flexible,
which drastically reduced the size of libid." -- Does this mean the
implemented Id is different from the one described in either of those
papers or is one of them up-to-date?
No and both, respectively (typos in the first paper notwithstanding).
What are the differences, or where
should I start to read the source to find out? (Or what are
interesting
commits in SVN history?)
The new model is part of Jolt3, little of which is written (and none
of which is in the repo yet). There's nothing particularly
interesting or novel about it; the whole story can be reduced to
this: a Pepsi object's 'type' is just a Jolt environment binding
'selectors' to lambdas.
Cheers,
Ian
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] sideways composition and metacircularity
intention of having "messaging semantics that are described entirely in terms of those same objects and messages" is not attained. Not entirely, no. The statement tacitly assumes that the ABI will not have to change, which precludes extending the context of method execution by way of additional implicit method arguments. This is the reason _bind() and _send() had to change, since they introduced a new hidden argument in the ABI (splitting 'self' into a pair of arguments: the 'receiver' and the 'state fragment'). I should change the quoted statement to be more restrictive. That being said, redefining lookup is almost enough. Something very similar to the code in Section 2.2 of http://piumarta.com/software/ cola/objmodel2.pdf would work, and would support multiple delegation, provided the new semantics need only a single 'self'. Either the identity of the original receiver can be preserved as 'self' (and composition is not allowed to introduce additional or refer directly to state) or 'self' can be rebound to the fragment that implements the destination method (and sends to 'self' will no longer be referred back to the original composite receiver). 'Leiberman' prototypes require both 'selves' to be present in the destination method. I think the only way to build a completely extensible system (with respect to both the internal ABI and foreign calling conventions) is to have runtime control over the ABIs of interest, hence all the (dynamically-compilable) lambdas pointing at the intrinsic method invocation and sequencing parts of the diagram in the COLA whitepaper. (Controlling the scope of customised ABIs is probably a much harder problem than providing the customisation itself.) Send site descriptors (that have been discussed here on several occasions) can solve many of the internal ABI problems, but by no means all of them. However, I think they would be sufficient for Leiberman prototypes provided 'receiver self' was communicated to the destination method exclusively through the descriptor and the descriptor was made available to, and could be extended from within, lookup. Cheers, Ian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] s3 slides
On Fri, Jun 13, 2008 at 9:27 AM, Ted Kaehler <[EMAIL PROTECTED]> wrote: > Folks, > On slide #42, Gezira, Shouldn't the top line be Max and not Min? > Otherwise every edge contributes at least 1 to every pixel, no matter where > it is! Hi Ted, No, "min" is correct. The intention is that every edge contributes at most 1. Using max instead would allow a contribution to exceed one (which would be incorrect). Perhaps there is confusion about what the "min" function does. It returns the minimum of the two arguments. It might erroneously be thought of as returning "at least" the magnitude of the arguments. I'm guessing that that stems from our use of the word minimum in the English language, for example "At a minimum, you just do this..." for setting a lower bound. On the contrary, the min function actually sets an upper bound. It sets the upper bound by restricting the result to be the minimum of the arguments, where one of the arguments usually is an upper bound. Strange, isn't it :) Hope that helps, Dan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] s3 slides
On Fri, Jun 13, 2008 at 2:00 PM, Dan Amelang <[EMAIL PROTECTED]> wrote: > > No, "min" is correct. The intention is that every edge contributes at > most 1. Using max instead would allow a contribution to exceed one > (which would be incorrect). Whoops! Although what I said about the min function is correct, I wasn't careful about explaining how it fits in with the whole formula. At this point in the formula, we aren't restricting individual edge contributions. We have already summed up the contributions. What we are restricting at this point is the total contribution of the closed path to a given pixel. And that value cannot be greater that 1 (meaning entirely opaque). Sorry for any confusion, Dan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] s3 slides
On 13.06.2008, at 23:00, Dan Amelang wrote: On Fri, Jun 13, 2008 at 9:27 AM, Ted Kaehler <[EMAIL PROTECTED]> wrote: Folks, On slide #42, Gezira, Shouldn't the top line be Max and not Min? Otherwise every edge contributes at least 1 to every pixel, no matter where it is! Hi Ted, No, "min" is correct. The intention is that every edge contributes at most 1. Using max instead would allow a contribution to exceed one (which would be incorrect). Perhaps there is confusion about what the "min" function does. It returns the minimum of the two arguments. It might erroneously be thought of as returning "at least" the magnitude of the arguments. I'm guessing that that stems from our use of the word minimum in the English language, for example "At a minimum, you just do this..." for setting a lower bound. On the contrary, the min function actually sets an upper bound. It sets the upper bound by restricting the result to be the minimum of the arguments, where one of the arguments usually is an upper bound. Strange, isn't it :) That's a very common thinko. At least I'm always confused by min(max,max(min,x)) ... - Bert - ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] s3 slides
Dan, Ah, the problem is that I did not know whether the summation could be larger than 1.0 or not. I see now. --Ted. -- Ted Kaehler http://www.squeakland.org/~ted/ (home) 3261 Montecito Drive, Las Vegas, NV 89120. voice (702) 456-7930 Puzzle: Faucets in a bathroom sink can either have long handles that turn opposite directions, or both can turn counter-clockwise to open. Is there any direction that a hot or cold faucet can turn and be incorrect in both schemes? --Ted. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] sideways composition and metacircularity
> Send site descriptors (that have been discussed here on several > occasions) can solve many of the internal ABI problems, but by no means > all of them. However, I think they would be sufficient for Leiberman > prototypes provided 'receiver self' was communicated to the destination > method exclusively through the descriptor and the descriptor was made > available to, and could be extended from within, lookup. > Is now the time to reify messages as objects to support "message send" protocol extension? Create a message object on the stack in sendv(); but where to define the send(): on the message, receiver or a system object? I avoided recursion in MOS by bootstrapping lookup() and apply() on a pair of well-known meta-objects. What would be destroyed by adding a _meta slot in vtable? Use Marcus' meta-context technique to avoid recursion? Message objects could be created with a bootstrapping vtable known to implement a baseline send() meta-protocol. But is the receiver or the system implementing the "message send" meta-protocol? There is no MOP, only vtables, object, selectors and methods. system.send(message), message.send(), message.receiver.send(message) or a decompositon using all three to allow granularity? Elide message object creation if standard send() protocol is in effect. (This could be somewhat interesting to attempt in libid. :) The former appears to lend itself toward Marcus' meta-context, the later lends itself to proxying, tracing, etc. If one wants to introduce a low-level MOP, perhaps it should be orthogonal, expressly opposite of many reflection protocols are in many languages: "there can only be one reflection/MOP/serialization protocol". The question is: if one wants to dynamically change the vtable (or clone family) selected in _sendv() for the message object, how do one do so? By what protocol? Marcus's meta-context? Perhaps, simply avoid it all by making [message.addMethod: @send ...] a special case that also saves the send() method into a global function pointer in libid. At what point does libid disappear in the tool chain? Is the extension (or substitution) of send() only to be a privilege and destination of tools up the chain? Or should higher levels be allowed to reify send() at lower levels? Sorry, my reply had way too many questions. Where is the message itself? :) > Cheers, > Ian > Kurt ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
