"Light Makes Right"
January 15, 1988
Volume 1, Number 2
Compiled by
All contents are copyright (c) 1988, all rights reserved by the individual authors
Archive locations: anonymous FTP at
ftp://ftp-graphics.stanford.edu/pub/Graphics/RTNews/,
wuarchive.wustl.edu:/graphics/graphics/RTNews, and many others.
You may also want to check out the Ray Tracing News issue guide and the ray tracing FAQ.
Speaking of whom, Andrew Glassner would like contributions to "The Ray Tracing News", hardcopy edition. He hopes to publish another one soon, but says it may be the last if no one sends him any more material. So, if you have an interesting technical memo or other short (less than 5 pages) piece you'd like to share with the rest of us, please write him (see the mailing list).
All for now,
Eric
back to contents
Here is the abstract:
Solid modelling with faceted primitives
F.W. Jansen
Computer Aided Design and Computer Graphics techniques are valuable tools in industrial design for the design and visualisation of objects. For the internal representation of the geometry of objects, several geometric modelling schemes are used. One approach, Constructive Solid Geometry (CSG), models objects as combinations of primitive solids. The subject of research in this project is a CSG representation where the surfaces of the primitives are approximated with flat surface elements (facets). Techniques to improve the efficiency of the display of models with a large number of these surface elements have been developed.
Two approaches have been taken. The first approach is based on the use of additional data structures to enhance the processing, sorting and search of these surface elements. Further, a method is presented to store intermediate results of the logical computations needed for the processing of CSG representations. These methods are applied to a CSG polygon modelling system.
The second approach aims at the development of algorithms for multi-processor systems and VLSI-based display systems. The central method is a CSG depth-buffer algorithm. A tree traversal method is introduced that combines several techniques to reduce the processing and memory use. The methods have been applied to a CSG halfspace modelling system.
Keywords: computer graphics, geometric modelling, solid modelling, Constructive Solid Geometry (CSG), ray tracing algorithm, depth-buffer algorithm, z-buffer algorithm, list-priority algorithm, depth-priority algorithm, spatial subdivision, CSG classification, CSG coherence.
____
The following subjects are also included: adaptive subdivision, crack removal.
You can send this information to all. I will read the discussion more carefully and will comment on it later.
Erik Jansen
back to contents
The discussions so far is very interesting one and I have several comments.
As I am charged for foreign mail (about $1 for 1K bytes, both incoming and out going), it costs considerablely to mail everyone on the list separately. So, I would like you to re-distribute my transpacific mail to everyone else.
Masataka Ohta
My comment on the flatness criteria with reflections follows: -----------------------------
Though I don't like subdividing patches into polygons for ray tracing (it's incoherent and, for example, CSG objects are difficult to render), good "flatness criteria" even with reflection, refraction or shadowing can be given using ray bound tracing.
The basic idea is simple. Ray bound is a combination of two bounds: a bound of ray origins and a bound of ray directions. A efficient bound can be formed by using a sphere for bounding ray origins and using a circle (on a unit sphere, i.e. using spherical geometry) for ray directions.
To begin with, bound a set of all rays which originates from each pixel. Flatness of a patch for the first generation ray should be computed against this ray bound, which is equivalent to measure flatness with perspective transformation, because rays are bounded by a pixel-sized cone.
As for the second generation rays, they can be bounded by a certain ray bound which can be calculated form the first generation ray bound. And those ray bounds should be used for the flatness check.
For those further interested in ray bound tracing, I will physically mail my paper titled "Bounded ray tracing for perfect and efficient anti-aliasing".
back to contents
__________
[Note: this first problem is kinda boring if you've never implemented an octree subdivision scheme before. Skip on to problem # 2, which I think is more important].
The first problem is: How do I cleverly chose octree bounds? This problem was first mentioned to me by Mike Kaplan, which I did not think about much until I suddenly noticed that all available memory was getting gobbled by certain polygonalized splines. The problem is that there are two parameters which are commonly used to end the further subdivision of an octree cube into its eight component "cubies".
One is a maximum number of primitives per octree cube. To make the octree in the first place we have a bounding cube which contains the environment. If the cube has more than a certain number of primitives in it, then octree subdivision takes place. The octree cubies formed are then each treated in a like fashion, subdividing until all leaf cubies contain less than or equal to the number of primitives. The second parameter is the maximum tree depth, which is the number of levels beyond which we will not subdivide cubes. This parameter generally has precedence over the first parameter, i.e. if the maximum level has been reached but the maximum number of primitives is still exceeded, subdivision will nonetheless halt.
The trick is that you have to pay close attention to both parameters. Originally I set these parameters to some reasonable numbers: 6 primitives and 8 levels being my maximums. What I found is that some objects would have very deep octrees, all the way down to level 8, even though their number of primitives was low. For example, an object with 64 patches would still have some leaf nodes down at level 8 which had 7+ primitives in them. I was pretty surprised by this problem.
My solution for spline surfaces was to keep the maximum number of primitives at 6 and use another parameter to determine the maximum level. I use the formula:
max level = round_up [ ln( primitives / K ) / ln( S ) ]
where K is the maximum number of primitives (i.e. 6) and S was a prediction of how much an octree subdivision would cut down the number of primitives in an octree. For example, in an environment consisting of a set of randomly distributed points, one would expect that when the octree cube containing these points was subdivided into eight octree cubies, each octree cubie would have about 1/8th of the points inside it. For a spline surface I reasoned that about four of the octree cubies might have some part of the surface in them, which would give an S=4 (Note that the largest, original octree must have at least four cubies filled by the surface. However, this is not necessarily true for suceedingly smaller cubies). Another factor which had to be taken into account was that there would also be some overlap: some primitives would appear in two or more cubies. So, as a final reasonable guess I chose S=3.5 . This seems to work fairly well in practice, though further testing would be very worthwhile.
Coming up with some optimal way to chose a maximum octree depth still seems to be an open question. Further study on how various environments actually fill space would be worthwhile: how many octree nodes really are filled on the average for each subdivision? More pragmatically, how do we determine the best maximum depth for ray-tracing an environment? The problem with not limiting the maximum level is primarily one of memory. If the octree grows without reasonable bounds a simple scene could use all available memory. Also, a large number of unnecessary octree nodes results in additional access time, either through having to search through the octree or through having extraneous objects in the hashing table.
A more intelligent approach might be to do adaptive subdivision: subdivide an octree cube as usual, then see how many fewer primitives there are in each cubie. If some cube has more than some percentage of primitives in it, the subdivision could be deemed useless and so subdivision would end at this point. If anyone knows a master's candidate looking for a project, this whole question of when it is profitable to subdivide might make a worthwhile topic. Judging from the interest in octrees by ray tracing researchers at last year's roundtable, I think this will become more and more important as time goes on.
_____________
The second problem with octrees: I decided to go with octrees for spline surfaces only because these objects would have fairly localized and even distribution of primitives (i.e. quadrilateral patches). I feel that octree efficiency techniques are probably horrible for ray tracing in general.
For example, imagine you have a football stadium made of, say, 5K primitives. Sitting on a goal line is a shiny polygonalized teapot of 5K quadrilaterals (note that the teapot is teapot sized compared to the stadium). You fill the frame with the teapot for a ray trace, hoping to get some nice reflections of the stadium on its surface.
If you use an octree for this scene, you'll run into an interesting problem. The teapot is, say, a foot long. The stadium is 200 yards long. So, the teapot is going to be only 1/600th the size of the stadium. Each octree subdivision creates 8 cubies which are each half the length of the parent cube. You could well subdivide down to 9 levels (with that 9th level cubie having a length of 1/512th of the stadium length: about 14 inches) of octrees and still have the whole teapot inside one octree cube, still undivided. If you stopped at this 9th level of subdivision, your ray trace would take forever. Why? Because whenever a ray would enter the octree cubie containing the teapot (which most of the rays from your eye would do, along with all those reflection and shadow rays), the cubie would contain a list of the 5K teapot polygons. Each of these polygons would have to be tested against the ray, since there is no additional efficiency structure to help you out. In this case the octree has been a total failure.
Now, you may be in a position where you know that your environments will be well behaved: you're ray tracing some specific object and the surrounding environment is limited in size. However, the designer who is attempting to create a system which can respond to any user's modeling requests is still confronted by this problem. Further subdivision beyond level nine down to level eighteen may solve the problem in this case. But I can always come up with a worse pathological case. Some realistic examples are an animation zooming in on a texture mapped earth into the Caltech campus: when you're on the campus the sphere which represents the earth would create a huge octree node, and the campus would easily fall within one octree cubie. Or a user simply wants to have a realistic sun, and places a spherical light source 93 million miles away from the scene being rendered. Ridiculous? Well, many times I find that I will place positional light sources quite some distance away from a scene, since I don't really care how far the light is, but just the direction the light is coming from. If a primitive is associated with that light source, the octree suddenly gets huge.
Solutions? Mine is simply to avoid the octree altogether and use Goldsmith's automatic bounding volume generation algorithm (IEEE CG&A, May 1987). However, I hate to give up all that power of the octree so easily. So, my question: has anyone found a good way around this problem? One method might be to do octree subdivision down to a certain level, then consider all leaf cubies that have more than the specified number of primitives in their lists as "problem cubies". For this list of primitives we perform Goldsmith's algorithm to get a nice bounding volume hierarchy. This method reminds me of the SIGGRAPH 87 paper by John Snyder and Alan Barr, "Ray Tracing Complex Models Containing Surface Tesselations". Their paper uses SEADS on the tesselated primitives and hierarchy on these instanced SEADS boxes to get around memory constraints, while my idea is to use the octree for the total environment so that the quick cutoff feature of the octree can be used (i.e. if any primitive in an octree cubie is intersected, then ray trace testing is done, versus having to test the whole environment's hierarchy against the ray). Using bounding volume hierarchy locally then gets rid of the pathological cases for the octree.
However, I tend to think the above just is not worthwhile. It solves the pathological cases, but I think that automatic bounding volume hierarchy (let's call it ABVH) methods will be found to be comparable in speed to octrees in many cases. I think I can justify that assertion, but first I would like to get your opinions about this problem.
back to contents
Without further ado, here are my top ten book recommendations. Most should be well known to you all, and so are listed mostly as a kernel of core books I consider useful. I look forward to your additions!
_The Elements of Programming Style, 2nd Edition_, Brian W. Kernighan, P.J. Plauger, 168 pages, Bell Telephone Laboratories Inc, 1978.
All programmers should read this book. It is truly an "Elements of Style" for programmers. Examples of bad coding style are taken from other textbooks, corrected, and discussed. Wonderful and pithy.
_Fundamentals of Interactive Computer Graphics_, James D. Foley, A. Van Dam, 664 pages, Addison-Wesley Inc, 1982.
A classic, covering just about everything once over lightly.
_Principles of Interactive Computer Graphics, 2nd Edition_, William M. Newman, R.F. Sproull, 541 pages, McGraw-Hill Inc, 1979.
The other classic. It's older (e.g. ray-tracing did not exist at this point), but gives another perspective on various algorithms.
_Mathematical Elements for Computer Graphics_, David F. Rogers, J.A. Adams, 239 pages, McGraw-Hill Inc, 1976.
An oldie but goodie, its major thrust is a thorough coverage of 2D and 3D transformations, along with some basics on spline curves and surfaces.
_Procedural Elements for Computer Graphics_, David F. Rogers, 433 pages, McGraw-Hill Inc, 1985.
For information on how to actually implement a wide variety of graphics algorithms, from Bresenham's line drawer on up through ray-tracing, this is the best book I know. However, for complicated algorithms I would recommend also reading the original papers.
_Numerical Recipes_, William H. Press, B.P. Flannery, S.A. Teukolsky, W.T. Vetterling, 818 pages, Cambridge University Press, 1986.
Chock-full of information on numerical algorithms, including code in FORTRAN and PASCAL (no "C", unfortunately). The best part of this book is that they give good advice on what methods are appropriate for different types of problems.
_A First Course in Numerical Analysis, 2nd Edition_, Anthony Ralston, P. Rabinowitz, 556 pages, McGraw-Hill Inc, 1978.
Tom Duff's recommendation says it best: "This book is SO GOOD [<-these words should be printed in italics] that some colleges refuse to use it as a text because of the difficulty of finding exam questions that are not answered in the book". It covers material in depth which _Numerical Recipes_ glosses over.
_C: A Reference Manual_, Samuel P. Harbison, G.L. Steele Jr., 352 pages, Prentice-Hall Inc, 1984.
A comprehensive and comprehensible manual on "C".
_The Mythical Man-Month_, Frederick P. Brooks Jr, 195 pages, Addison-Wesley Inc, 1982.
A classic on the pitfalls of managing software projects, especially large ones. A great book for beginning to learn how to schedule resources and make good predictions of when software really is going to be finished.
_Programming Pearls_, Jon Bentley, 195 pages, Bell Telephone Laboratories Inc, 1986.
Though directed more towards systems and business programmers, there are a lot of clever coding techniques to be learnt from this book. Also, it's just plain fun reading.
As an added bonus, here's one more that I could not resist:
_Patterns in Nature_, Peter S. Stevens, 240 pages, Little, Brown and Co. Inc, 1974.
The thesis is that simple patterns recur again and again in nature and for good reasons. A quick read with wonderful photographs (my favorite is the comparison of a turtle shell with a collection of bubbles forming a similar shape). Quite a few graphics researchers have used this book for inspiration in simulating natural processes.
back to contents
previous discussion of problem
__________
About the normal vector transform:
Eric, you are absolutely right. I also ran into this when some of my squashed objects just didn't look right, about 4 years ago. I would just like to offer a slightly different way of looking at the same thing. I find I have difficulty with mathematical concepts unless I can attatch some sort of physical significance to them. (I think of a 3x4 transformation matrix as three basis vectors and a displacement vector instead of an amorphous pile of 12 numbers.)
My first attack at finding a transformed normal was to find two non-paralell surface vectors at the point in question. These could be transformed regularly and the transformed normal would be their cross product. This certainly works, but is computationally slow. It seemed clear that there should exist some 3x3 matrix that was the total transform the normal vector really went thru. To simplify the thought experiment, what if the original normal vector was exactly along the X axis? Well, the unit surface vectors would be the Y and Z axis vectors. When these are sent thru the regular 3x3 transformation matrix, they become the Y and Z basis vectors of that matrix. The final resulting normal vector is therefore the cross product of the Y and Z basis vectors of the regular matrix. This is then what the X basis vector of the normal vector transformation matrix should be. In general, a basis vector in the normal vector transformation matrix is the cross product of the other two basis vectors of the regular transformation matrix. I wasn't until about a year later that I realized that this resulting matrix was the inverse transpose of the regular one.
This derivation results in exactly the same matrix that Eric was talking about, but leaves me with more physical understanding of what it represents.
Now for a question: It has always bothered me that this matrix trashes the vector magnitude. This usually implies re-unitizing the transformed normal vector in practise. Does anyone avoid this step? I don't want to do any more SQRTs than necessary. You can assume that the original normal vector was of unit length, but that the result also needs to be.
__________
About octrees:
1) I don't use Andrew's hashing scheme either. I transform the ray so that my octree always lives in the (0,0,0) to (1,1,1) cube. To find the voxel containing any one point, I first convert the coordinates to 24 bit integers. The octree now sits in the 0 to 2**23 cube. Picking off the most significant address bit for each coordinate yields a 3 bit number. This is used to select one of 8 voxels at the top level. Now pick off the next address bit down and chose the next level of subordinate voxel, etc, until you hit a leaf node. This process is LOGn, and is very quick in practise. Finding a leaf voxel given an integer coordinate seems to consume about 2.5% of the time for most images. I store direct pointers to subordinate voxels directly in the parent voxel data block. In fact, this is the ONLY way I have of finding all but the top voxel.
2) Choosing subdivision criteria: First, the biggest win is to subdivide on the fly. Never subdivide anything until you find there is a demand for it. My current subdivision criteria in order of precidence (#1 overrides #2) are:
1) Do not subdivide if hit subdivision generation limit. This is the same as what Eric talked about. I think everyone does this.
2) Do not subdivide if voxel is empty.
3) Subdivide if voxel contains more than one object.
4) Do not subdivide if less than N rays passed thru this voxel, but did not hit anything. Currently, N is set to 4.
5) Subdivide if M*K < N. Where M is the number of rays that passed thru this voxel that DID hit something, and K is a parameter you chose. Currently, K is set to 2, but I suspect it should be higher. This step seeks to avoid subdividing a voxel that may be large, but has a good history of producing real intersections anyway. Keep in mind that for every ray that did hit something, there are probably light source rays that did not hit anything. (The shader avoids launching light rays if the surface is facing away from the light source.) This can distort the statistics, and make a voxel appear less "tight" than it really is, hence the need for larger values of K.
6) Subdivide.
Again, the most important point is lazy evaluation of the octree. The above rules are only applied when a ray passes thru a leaf node voxel. Before any rays are cast, my octree is exactly one leaf node containing all the objects.
3) First solution to teapot in stadium: This really cries out for nested objects. Jim Arvo, Dave Kirk, and I submitted a paper last year on "The Ray Tracing Kernel" which discussed applying object oriented programming to designing a ray tracer. Jim just told me he is going to reply about this in detail so I will make this real quick. Basically, objects are only defined implicitly by the results of various standard operations they must be able to perform, like "intersect yourself with this ray". The caller has no information HOW this is done. An object can therefore be an "aggregate" object which really returns the result of intersecting the ray with all its subordinate objects. this allows for easily and elegantly mixing storage techniques (octrees, linear space, 5D structures, etc.) in the same scene. More on this from JIM.
4) Second solution to teapot in stadium: I didn't understand why an octree wouldn't work well here anyway. Suppose the teapot is completely enclosed in a level 8 voxel. That would only "waste" 8x8=64 voxels in getting down to the space you would have chosen for just the teapot alone. Reflection rays actually hitting the rest of the stadium would be very sparse, so go ahead and crank up the max subdivision limit. Am I missing something?
__________________________________
(This is a reply to Olin Lathrop. Summary: "well, maybe the octree is not so bad after all...").
From: Eric Haines
Olin Lathrop writes:
> To simplify the thought experiment, what if the original normal vector was exactly
> along the X axis? Well, the unit surface vectors would be the Y and Z axis
> vectors. When these are sent thru the regular 3x3 transformation matrix,
> they become the Y and Z basis vectors of that matrix. The final resulting
> normal vector is therefore the cross product of the Y and Z basis vectors of the
> regular matrix. This is then what the X basis vector of the normal vector
> transformation matrix should be. In general, a basis vector in the normal
> vector transformation matrix is the cross product of the other two basis
> vectors of the regular transformation matrix. It wasn't until about a year
> later that I realized that this resulting matrix was the inverse transpose
> of the regular one.
The problem is the sign of the basis vector is unclear by this method. I tried this approach, but it fails on mirror matrices. Suppose your transformation matrix is: [ -1 0 0 0 ] [ 0 1 0 0 ] [ 0 0 1 0 ] [ 0 0 0 1 ]
This matrix definitely affects the surface normal in X, but your two vectors in Y and Z are unaffected. This problem never occurs in the "real" world because such a matrix is equivalent to twisting an object through 4D space and making it go "through the looking glass". However, it happens in computer graphics a lot: e.g. I model half a car body, then mirror reflect to get the other half. If you have a two sided polygon laying in the YZ plane, with one side red & the other blue, and apply the above transformation, no vertices (and no tangent vectors) have any non-zero X components, and so will not change. But the normal does reverse, and the sides switch colors. My conclusion was that you have to use the transpose of the inverse to avoid this problem, since surface normals fail for this case. (p.s. did you get a copy of Glassner's latest (2nd edition) memo on this problem? He does a good job explaining the math).
> About octrees:
>
> 1) I don't use Andrew's hashing scheme either. I transform the ray so that
> my octree always lives in the (0,0,0) to (1,1,1) cube...
Actually, this is the exact approach I finally took, also. I had rejected the hashing scheme earlier, and forgotten why (and misremembered that it was because of memory costs) - the correct reason for not hashing is that it's faster to just zip through the octree by the above method; no hashing is needed. It's pretty durn fast to find the right voxel, I agree.
Have you experimented with trying to walk up and down the octree, that is, when you are leaving an octree voxel you go up to the parent and see if the address is inside the parent? If not, you go to its parent and check the address, etc, until you find that you can go back down. Should be faster than the straight downwards traversal when the octree is deep: the neighboring voxels of the parent of the voxel you're presently in account for 3 of the 6 directions the ray can go, after all. You have 1/2 a chance of descending the octree if you check the parent, 3/4ths if you go up two parents, etc. (Where did I read of this idea, anyway? Fujimoto? Kaplan? Whatever the case, it's not original with me).
Another idea that should be mentioned is one I first heard from Andrew Glassner: putting quadtree-like structures on the cube faces of the octree cubes. It's additional memory, but knowing which octree cube is the next would be a faster process. Hopefully Andrew will write this up sometime.
The subdivision criteria ideas are great - makes me want to go and try them out! When are you going to write it up and get it published somewhere? Lazy subdivision sounds worthwhile: it definitely takes awhile for the octrees to get set up under my present "do it all at the beginning" approach (not to mention the memory costs). That was something I loved about the Arvo/Kirk paper - without it the 5D scheme would appear to be a serious memory hog.
> 4) Second solution to teapot in stadium: I didn't understand why an octree
> wouldn't work well here anyway. Suppose the teapot is completely enclosed
> in a level 8 voxel. That would only "waste" 8x8=64 voxels in getting down
> to the space you would have chosen for just the teapot alone. Reflection
> rays actually hitting the rest of the stadium would be very sparse, so go
> ahead and crank up the max subdivision limit. Am I missing something?
There are two things which disturbed me about the use of the octree for this problem. One was that if the maximum subdivision level was reached prematurely then the octree falls apart. I mentioned that you could indeed subdivide down another 9 levels and have an 18 level octree that would work. However, the problem with this is knowing when to stop - why not go on to 24 levels? For me it boils down to "when do I subdivide?". I suspect that your additional criteria might solve a lot of the pathological cases, which is why I want to test them out. Also note that there are built in maximum subdivision levels in octree schemes which could be reached and still not be sufficient (though admittedly your 24 levels of depth are probably enough. Of course, I once thought 16 bits was enough for a z-buffer - now I'm not so sure. Say you have a satellite which is 5 feet tall in an image, with the earth in the background. We're now talking 23 levels of subdivision before you get within the realm of subdividing the satellite. With 24 levels of depth being your absolute maximum you've hit the wall, with only one subdivision level helping you out on the satellite itself).
Good point that as far as memory goes it's really just 8x8 more voxels "wasted". One problem is: say I'm 8 feet in each direction from the teapot, with me and the teapot in diagonally opposite corners of a cube which is then made into an octree. The only way to get through the 8 cubes in the containing box is to travel through 4 of them (i.e. if I'm in Xhi, Yhi, Zhi and the teapot is in Xlo, Ylo, Zlo, then I have to intersect my own box and then three other boxes to move me through in each "lo" direction). In this case there are only 3 levels of octree cubes I have to go through before getting to the 1 foot cube voxel which contains the teapot. The drawback of the octree is that I have to then do 3x4=12 box intersections which must be done each ray and which are useless. Minor, but now think of reflection rays from the teapot which try to hit the stadium: each could go through up to 8 levels x 4 voxels per level = 32 voxels just to escape the stadium without hitting anything (not including all the voxels needed to be traversed from the teapot to the one foot cube). Seems like a lot of intersection and finding the next octree address and tree traversal for hitting the background. I suspect less bounding volumes would be hit using hierarchy, and the tests would be simpler (many of them being just a quick "is the ray origin inside this box?": if so, check inside the box).
I guess it just feels cleaner to have to intersect only bounding volumes which are needed, which is the feel which automatic bounding volume hierarchy has to it. Boxes can be of any size, so that if someone adds a huge earth behind a satellite all that is added is a box that contains both. With hierarchy you can do some simple tricks to cut down on the number of bounding volumes intersected. For example, by recording that the ray fired at the last pixel hit such and so object, you can test this object first for intersection. This quickly gets you a maximum depth that you need not go beyond: if a bounding volume is intersected beyond this distance you don't have to worry about intersecting its contents. This trick seems to gain you about 90% of the speed-up of the octree (i.e. not having to intersect any more voxels once an intersection is found), while also allowing you the speed up of avoiding needless octree voxel intersections. I call this the "ray coherency" speedup - it can be used for all types of rays (and if you hit when the ray is a shadow ray, you can immediately stop testing - this trick will work for the octree, too! Simply save a pointer to the object which blocked a particular shadow ray for a particular light last pixel and try it again for the next shadow ray).
I still have doubts about the octree. However, with lazy evaluation I think you get rid of one of my major concerns: subdividing too deep makes for massive octrees which soak up tons of memory. Have you had to deal with this problem, i.e. has the octree ever gotten too big, and do you have some way to free up memory (some "least recently used" kind of thing)?
An interesting comment that I read by John Peterson on USENET news some months ago was:
>> [John Watson @ Ames:]
>> Anyway, I know there have been a few variations of the constant-time
>> algorithms around, and what I need to know is, what is the _best_,
>> i.e. simplest, most effiecent, etc, ... version to implement.
>>
>> Could some of you wonderful people comment on these techniques in general,
>> and maybe give me some pointers on recent research, implementions, etc.
>
> This is an interesting question. Here at Utah, myself and Tom Malley
> implemented three different schemes in the same ray tracer; Whitted/Rubin,
> Kay/Kajiya, and an octree scheme (similar to the Glassner/Kaplan, camp, I
> think). The result? All three schemes were within 10-20% of each other
> speedwise. Now, we haven't tested these times extensively; I'm sure you could
> find wider variances for pathological cases. But on the few generic test
> cases we measured, there just wasn't much difference. (If we get the time,
> we plan on benchmarking the three algorithms more closely).
I suspect that this is probably the case, with octree working best when the scene depth (i.e. the number of objects which are intersected by each ray, regardless of distance) is high, the "ray coherency" method outlined above for hierarchy fails, and so cutting off early is a big benefit. Automatic hierarchy probably wins when there are large irregularities in the density of the number of objects in space. (Of course, the SEADS method (equal sized voxels and 3DDDA) is ridiculous for solving the "teapot in a stadium" kind of problems, but it's probably great for machines with lots of memory ray tracing scenes with a localized set of objects.
By the way, I found Whitted/Rubin vs. Kay/Kajiya to be about the same: Kay had less intersections, but the sorting killed any time gained. I find the coherency ray technique mostly does what Kay/Kajiya does: quickly gets you a maximum intersection depth for cutoff.
Without the memory constraints limiting the effectiveness of the octree I can believe it well could be the way of the future: it is ideal for hardware solution (so those extra voxel intersection and traversal tests don't bother me if they're real fast), sort of like how the z-buffer is the present winner in hidden surface algorithms because of its simplicity.
So, how's that for a turnabout on my polemical anti-octree position? Nonetheless, I'm not planning to change my hierarchy code in the near future - not until the subdivision and memory management problems are more fully understood.
All for now,
Eric Haines
back to contents
One way that we've dealt with situations similar to Eric's teapot example is to use a combination of spatial subdivision and bounding volume techniques. For instance, we commonly mix two or three of the following techniques into a "meta" hierarchy for ray tracing a single environment:
1) Linear list
2) Bounding box hierarchy
3) Octrees (including BSP trees)
4) Linear grid subdivision
5) Ray Classification
We commonly refer to these as "subspaces". For us this means some (convex) volume of space, a collection of objects in it, and some technique for intersecting a ray with those objects. This technique is part of an "aggregate object", and all the objects it manages are the "children". Any aggregate object can be the child of any other aggregate object, and appears simply as a bounding volume and intersection technique to its parent. In other words, it behaves just like a primitive object.
Encapsulating a subspace as just another "object" is very convenient. This is something which Dave and Olin and I agreed upon in order to make it possible to "mix and match" our favorite acceleration techniques within the same ray tracer for testing, benchmarking, and development purposes.
As an example of how we've used this to ray trace moderately complex scenes I'll describe the amusement park scene which we animated. This consisted of a number of rides spread throughout a park, each containing quite a bit of detail. We often showed closeups of objects which reflected the rest of the park (a somewhat scaled down version of the teapot reflecting the stadium). There were somewhere around 10,000 primitive objects (not including fractal mountains), which doesn't sound like much anymore, but I think it still represents a fairly challenging scene to ray trace -- particularly for animating.
The organization of the scene suggested three very natural levels of detail. A typical example of this is
I) Entire park ( a collection of rides, trees, and mountains ) II) Triple decker Merry-go-round ( one of the rides ) III) A character riding a horse ( a "detail" of a ride )
Clearly a single linear grid would not do well here because of the scale involved. Very significant collections of primitives would end up clumped into single voxels. Octress, on the other hand, can deal with this problem but don't enjoy quite the "voxel walking" speed of the linear grid. This suggests a compromise.
What we did initially was to place a coarse linear grid around the whole park, then another linear grid (or octree) around each ride, and frequently a bounding box hierarchy around small clusters of primitives which would fall entirely with a voxel of even the second-level (usually 16x16x16) linear grid.
Later, we began to use ray classification at the top level because, for one thing, it did some optimizations on first-generation rays. The other levels of the hierarchy were kept in place for the most part (simplified a bit) in order to run well on machines with < 16 MB of physical memory. This effectively gave the RC (ray classification) aggregate object a "coarser" world to deal with, and drastically cut down the size of the candidate sets it built. Of course, it also "put blinders" on it by not allowing it to distinguish between objects inside these "black boxes" it was handed. It's obviously a space-time trade-off. Being able to nest the subspaces provides a good deal of flexibility for making trade-offs like this.
A small but sort of interesting additional benefit which falls out of nesting subspaces is that it's possible to take better advantage of "sparse" transformations. Obviously the same trick of transforming the rays into a canonical object space before doing the intersection test (and transform the normal on the way out) also works for aggregate objects. Though this means doing possibly several transforms of a ray before it even gets to a primitive object, quite often the transforms which are lower in the hierarchy are very simple (e.g. scale and translate). So, there are cases when a "dense" (i.e. expensive) transform gets you into a subspace where most of the objects have "sparse" (i.e. cheap) transforms. [I'll gladly describe how we take advantage of matrix sparsity structures if anybody is interested.] If you end up testing N objects before finding the closest intersection, this means that (occasionally) you can do the job with one dense transform and N sparse ones, instead of N dense transforms. This is particularly appropriate when you build a fairly complex object from many scaled and translated primitives, then rotate the whole mess into some strange final orientation. Unfortunately, even in this case it's not necessarily always a win. Often just pre-concatenating the transforms and tossing the autonomous objects (dense transforms and all) into the parent octree (or whatever) is the better thing to do. The jury is still out on this one.
Currently, all of the "high level" decisions about which subspaces to place where are all made manually and specified in the modeling language. This is much harder to do well than we imagined initially. The tradeoffs are very tricky and sometimes counter-intuitive. A general rule of thumb which seems to be of value is to put an "adaptive" subspace (e.g. an octree, RC) at the top level if the scene has tight clusters of geometry, and a Linear grid if the geometry is fairly uniform. Judicious placement of bounding box hierarchies within an adaptive hierarchy is a real art. On the one hand, you don't want to hinder the effectiveness of the adaptive subspace by creating large clumps of geometry that it can't partition. On the other hand, a little a priori knowledge about what's important and where bounding boxes will do a good job can often make a big difference in terms of both time and space (the space part goes quintuple for RC).
Now, the obvious question to ask is "How can this be done automatically?" Something akin to Goldsmith and Salmon's automatic bounding volume generation algorithm may be appropriate. Naturally, in this context, we're talking about a heterogeneous mixture of "volumes," not only differing in shape and surface area, but also in "cost," both in terms of space and time. Think of each subspace as being a function which allows you to intersect a ray with a set of objects with a certain expected (i.e. average) cost. This cost is very dependent upon the spatial arrangement and characteristics of the objects in the set, and each type of subspace provides different trade-offs. Producing an optimal (or at least good) organization of subspaces is then a very nasty combinatorial optimization problem.
An idea that I've been toying with for quite some time now is to use "simulated annealing" to find a near-optimal subspace hierarchy, where "optimality" can be phrased in terms of any desired objective function (taking into account, e.g., both space and time). Simulated annealing is a technique for probabilistically exploring the vast solution space (typically) of a combinatorial optimization problem, looking for incremental improvements WITHOUT getting stuck too soon in a local minimum. It's very closely linked to some ideas in thermodynamics, and was originally motivated by nature's ability to find near-optimal solutions to mind-bogglingly complex optimization problems -- like getting all the water molecules in a lake into a near-minimum-energy configuration as the temperature gradually reaches freezing. It's been fairly successfull at "solving" NP-hard problems such as the travaling salesman and chip placement (which are practically the same thing).
This part about simulated annealing and subspace hierarchies is all very speculative, mind you. It may not be practical at all. It's easy to imagine the "annealing" taking three CPU-years to produce a data structure which takes an hour to ray trace (if it's done as a preprocessing step -- not lazily). There are many details which I haven't discussed here -- largely because I haven't figured them out yet. For example, one needs to get a handle on the distribution of rays which will be intersected with the environment in order to estimate the efficiency of the various subspaces. Assuming a uniform distribution is probably a good first approximation, but there's got to be a better way -- perhaps through incremental improvements as the scene is ray traced and, in particular, between successive frames of an animation.
If this has any chance of working it's going to require an interesting mix of science and "art". The science is in efficiently estimating the effectiveness of a subspace (i.e. predicting the relevant costs) given a collection of objects and a probability density function of rays (probably uniform). The art is in selecting an "annealing schedule" which will let the various combinations of hierarchies percolate and gradually "freeze" into a near-optimal configuration. Doing this incrementally for an animation is a further twist for which I've seen no analogies in the simulated annealing literature.
If you've never heard of simulated annealing and you're interested in reading about it, there's a very short description in "Numerical Recipes." The best paper that I've found, though, is "Optimization by Simulated Annealing," by S. Kirkpatrick, C. D. Gelatt, Jr., and M. P. Vecchi, in the May 13, 1983 issue of Science.
Does this sound at all interesting to anybody? Is anyone else thinking along these or similar lines?
(Twenty years later, Andrew Kensler did something along these lines. See RTNv21n1.) related discussion of topic
back to contents


{% extends 'base.html' %} {% block title %}Not Found | {{ site.title | safe }}{% endblock title %} {% block content %}
Sorry, we couldn't find that. It might have been deleted.
Click here to go back to the homepage.


There is no 3rd party involved in the transaction. There is also the option to transfer funds through a self hosted escrow.
This means that azanians can add financial functionality to their websites without worrying about 3rd parties adding more costs and distrust to the transaction.
The platform is just a gateway to the Azanian client and provides the tools necessary to interact with the Blockchain.
Azania is still in its pilot phase therefore there are NO transaction fee. The cost is the one the seller and buyer agreed upon for a particular service.
The NAS Blockchain provides the immutability and persistance of the transactions.
Below is a basic escrow transaction flow between a seller and a buyer.
The buyer or the seller starts a transaction in which they describe the product details that is being traded and the price in NAS.
The seller/buyer accepts the escrow transaction details and price and chooses to reject or accept the transaction.
After buyer has deposited the necessary funds within the Nebulas contract, the seller can choose to Ship the product and provide the shipment details.
After receiving the product, the buyer has X amount of days to inspect the item and release the funds to the seller.
Buy Bitcon to interact with the Azanian ecosystem. BTC will allow you to purchase products in the Azanian ecosystem and to pay Azanian developers. You will have to create a cold wallet here there after you can make a BTC order before receiving a Bitcoin.
You can learn about Azania or interact with azania bellow
You can either sign up as a developer or a user below:
For any platform problems or enquiries, or any dispute arrangements
please use the email address below.
andilexmchunu@gmail.com


Mode: Create Edit Load
* = required
Custom Graphics? Yes No
Local home addr.: Education: Employment: Criminal Activity: Enhanced Identification Notes:


Watch: Hezvo………. Slay Queen Brings Varsity To A Standstill In ‘N_ude’ Outfit
by AndrewA National University of Science and Technology Student (NUST) recently pulled a shocker after attending lectures clad in a see-through dress exposing her undergarments.
According to reports reaching iHarare, the girl, whose identity could not be verified at the time of publishing, is reported to have gained notoriety for being scantily dressed.
More to follow……………
Watch video…………..
To View and Apply for the latest Jobs and Vacancies in Zimbabwe, Please Visit our Sister website iHarare Jobs


GLAMpipe
version
GLAMpipe is ready...
Users with projects
Choose the user whose projects you would like see.
Create project
Project contains your data, transforms, downloads etc.
Title
Create project
http://glampipe.org
From GLAM to GLAMs
All projects
Are you sure?


About Me
Welcome to the Portfolio Webpage of Nam Hoon Kim, also known as "Alex". We all know Alex as a passionate and young adult who's interested in becoming the next big persona in the tech world, but nobody really knows about his background and upbringing.
Alex was born on April 29 at a hospital in Seoul, South Korea. As a child, Alex was just like any other child -- he enjoyed playing outside with his friends at the playground. However, Alex was born into a period of rapid technological growth, as outdoor playtime was becoming quickly replaced by video games and computer dominance with the release of the immensely popular video gaming platform Sony Playstation and the release of StarCraft on the PC. Alex showed interest in technology early, becoming interested in computer games and displaying interest in PC functions.
In the summer the new millenium, Alex's parents decided to move the family to the States, deciding ultimately to settle in Irvine, California known for providing great education and safe haven for immigrant families. As a teen, Alex showed talent in academics, especially in math. Ultimately, Alex was accepted to the mathematics program at the prestigious UCLA.
Despite having majored in Mathematics, Alex knew in his heart that the theoretical concepts of mathematics alone cannot stand on its own. After graduation, Alex had a crisis in trying to find something to do with a math degree, ultimately failing to find a place to keep him happy. As a result, Alex decided to learn more coding and programming to supplement his mathematical background.
Here's the first big step into his newfound journey to becoming the next Mark Zuckerberg, Bill Gates, or Steve Jobs!


[Erowid Warning: Our understanding of the literature is that there is no such thing as safe use of volatile solvents, aerosols and other street inhalants : their psychoactive effects are inseparable from nerve and organ damage. We have chosen to include these reports to help document the real world use of inhalants, but their inclusion is not intended to imply that they are anything but dangerous.]
I have to say I was highly surprised when my friend had mentioned to me that he had taken Freon from air conditioners and used it to get high. At the time, I was still poorly researched and uninformed on the subject of drugs.
However, I found myself in a situation where Freon was being taken by others around me, and after a bit of reluctance decided to try the substance.
This was actually my first experience with any kind of drug (alcohol excluded) so I was a bit nervous, yet excited to try the substance.
I should take a moment to describe the environment. I was sitting in my friend's beat-up Nissan Pathfinder at the dead end of a residential road at night time. He had the lights on inside the car.
After my other friend in the back seat took his turn, I decided to go ahead with mine. I nervously began huffing the sweet-tasting substance and let go of the balloon.
I am simply amazed. The freon hit at once. I immediately noticed my voice had dropped several octaves to what could be described as the voice of Lucifer.
Within five seconds I began to feel almost as if I had left my body. My head bowed down and my vision began to spin and converge into bright yellow patterns. I could see a limited portion of the outside world, but only if I stared directly at something, and then the vision would only last for a second.
As far as the auditory sense, it is overloaded with a repeating, mechanical sound - something described as the 'wa-wa's by some people.
The mind experience is simply amazing. The animal brain seems to sit around saying 'wheeeeeeeeeeee' while the intelligent brain runs through thoughts at what seems like a billion miles per hour. Not that I can coherently interpret all that I think and contribute it in an experience report later.
My first time was a bit disorienting - having never had done any drugs and suddenly having been cast into a wild experience, I forgot for several seconds that I had taken Freon, and for a microsecond, wanted to return to normal.
I looked over and saw my friend laughing. I felt as if he was a troll of some sort, so I began to punch him in the face. He tried to deflect my punches to no avail.
Shortly after, I noticed the effects starting to fade. The whole experience had lasted nearly a minute long. As the experiences faded, my vision slowly returned to normal, and I realized that I had been laughing the whole time. It took nearly five seconds of continuing to laugh before I regained control and sat with a huge grin on my face.
That night, and several times in the future, I had other experiences. I wish to describe one of them in order to elaborate on the effects.
This time, I was sitting in my friend's Ford Mustang. Again, this experience was done at night time. I had huffed the freon while he was driving. Having had done it several times, I knew to hold my fingers around the balloon to save whatever might be left.
As I started to get hit by the effects, I saw my friend requesting that I hand him the balloon. I said in a really low voice, 'No, not while you're driving!'
I watched him pull the shifter down, which was a surreal experience as it was basically two frames - shifter forward, shifter backwards.
But right at that instant I watched him pull the parking brake and realized that we were stopped at the curb in a residential area. Right then, the effect started to kick in.
All of the trips I've had have had many of the same elements, so my memory tends to be able to recall the effects but all of the environments seem somewhat the same.
This time, I tried to remember what it was like to live at home or what my parents look like. I could form a mental image for all of a second before it fell apart and I maintained a pleasant but foerign feeling.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Lvl 5:
Lvl 4:
Lvl 3:
Lvl 2:
Lvl 1:
Foil:
This site requires a public profile, instructions can be found here.
After table is loaded:
Color code legend:
This site uses a local cache of Steam's information, so it is not always up to date.
To update game cards and prices, click the update button located at the right of each row.
To update your game list, inventory, and badges use the update profile button.
A custom URL (http://steamcommunity.com/id/use-this-name) or your 17-digit steamid is required on initial sync, but your profile name can be used thereafter
Start by loading all games into the table:
A feedback forum can be found on my Steam Group Page
This project is hosted on Github


Tags: nan
Style: Impressionism
Artist: Monet Claude
Title: Head of the Dog
Year: 1882
Genre: animal painting
Categories: Tibetan_terrier (32.4%); Dandie_Dinmont (13.3%); Lhasa (11.9%); Shih-Tzu (9.1%); silky_terrier (7.8%)
<< previous image next image >>


A verification condition is a formula that, if valid, implies the correctness of an action, logical judgment, or logical statement.
Ivy's default tactic for a proof automatically generates a verification condition for the context requiring the proof. If the verification condition does not fall within the FAU logical fragment, the user will need to participate in constructing a proof or changing the context.
The same default verification condition generation tactic is involved in proving a free-standing logical judgment or an assertion, precondition or postcondition statement inside an action. Only the input to the tactic varies depending on context.
This tactic can also be invoked explicitly within a manual proof with tactic vcgen
.
Anywhere a proof is required but not provided, it is equivalent to there being a proof consisting of tactic vcgen
.
Verification conditions in Ivy are generated from the calculus of weakest liberal preconditions.
For example, the following program:
type t
interpret t -> nat
action decr(x:t) returns (y:t) = {
require x > 0;
y := x - 1;
ensure y < x;
}
export decr
has the following VC:
x > 0 -> x - 1 < x
See the page on weakest liberal precondition for details on exactly how it is calculated.
Checking VCs with SMT solvers
A typical SMT solver solver (including Z3, the one Ivy uses) can determine definitely whether this formula is satisfiable, since it is expressed in the form of affine constraints over the natural numbers without quantifiers. Solving constraints of this kind is an NP-complete problem. This means that all known solution algorithms use exponential time in the worst case, but in practice we can almost always solve problems that have a moderate number of variables.
More generally, a typical SMT solver can handle a theory called QFLIA, which stands for "quantifier-free linear integer arithmetic" and allows us to form arbitrary combinations of affine constraints with "and", "or" and "not". We can easily reduce formulas with natural-number variables to formulas using only integer variables, so the solver doesn't need a special theory for natural numbers.
Technically, the way this is done is by negating the formula, then passing it to the solver to determine if it is satisfiable. In this case, the negated verification condition is:
~(x > 0 -> x - 1 < x)
which is logically equivalent to:
x > 0 & x - 1 >= x
We can easily see that this is unsatisfiable, in the sense that there is no natural number x
that makes it true.
If the negated verification condition has a solution, it means that the verification condition is not valid, so something is wrong with our proof. Suppose, for example, we change the precondition of action decr
from x > 0
to x < 42
. The negated verification condition becomes:
x < 42 & x - 1 >= x
Models and counter-models
In Ivy's natural number theory, we have 0 - 1 = 0
. That means that the above formula is actually true for x = 0
. The assignment x = 0
is called a model of the formula, that is, it describes a possible situation in which the formula is true. That means the assignment x = 0
is also a counter-model for the verification condition: it shows
why the proof doesn't work.
Counter-models are extremely important from the point of view of transparency. That is, if our proof fails, we need a clear explanation of the failure so we can correct the system or its specification.
Positive and negative occurrences of formulas in VCs
Verification conditions for even moderately complex programs are big messy formulas that are hard to read. Fortunately, from the point of view of decidability, we need not be concerned with the exact form of the VC. Rather, for each formula occurring in the program or its specifications, we will be concerned with whether the formula occurs positively in the VC, or negatively or both.
Backlinks
- assumption
- command
- effectively propositional
- first-order logic
- ghost
- guarantee
- invariant
- logical fragment
- macro definition
- positive and negative occurrences
- postcondition
- precondition
- property
- recovering decidability
- sort
- stratification
- tactic
- theorem
- transition relation
- weakest liberal precondition


Home
(current)
Notifications
4
Messages
1
Search
@clumsy86
Trends for you
Trend 1
Trend 2
Trend 3
Trend 4
Tweet
Username Date
Post
Edit
Who to follow
Follow
Follow
Follow
Follow
© 2018 Twitter
About
Help Center
Terms
Privacy policy
Cookies
Ads info
Brand
Blog


Constructs the request builder service.
Angular's Http service, used to execute HTTP requests.
Returns a RequestBuilder configured to perform a DELETE request to the specified URL.
Returns a RequestBuilder configured to perform a GET request to the specified URL.
Returns a RequestBuilder configured to perform a HEAD request to the specified URL.
Returns a RequestBuilder configured to perform a OPTIONS request to the specified URL.
Returns a RequestBuilder configured to perform a PATCH request to the specified URL.
Returns a RequestBuilder configured to perform a POST request to the specified URL.
Returns a RequestBuilder configured to perform a PUT request to the specified URL.
Returns a RequestBuilder configured to perform a GET request to the specified URL.
Generated using TypeDoc
An Angular service to easily create RequestBuilder objects.
import { Injectable } from '@angular/core'; import { RequestBuilderService } from 'ng-request-builder'; @Injectable() export class MyService { constructor(private requestBuilderService: RequestBuilderService) { } public doStuff(): Observable<Response> { return this.requestBuilderService .get('http://example.com') .header('Authorization', 'Bearer secret') .search('offset', 25) .search('limit', 50) .execute() } }


Data Fields
Field Documentation
Gets the data buffer containing the audio samples.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
- Returns:
- A pointer to the beginning of the data buffer.
Gets the size of the data buffer in bytes.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
- Returns:
- The size of the data buffer in bytes.
Gets the number of channels in the audio buffer.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
- Returns:
- The number of channels in the audio buffer.
Gets the number of samples in the audio buffer.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
- Returns:
- The number of samples in the audio buffer. For example, at a sampling rate of 44,100 Hz in stereo audio, a buffer containing 4410 * 2 samples would have a duration of 100 milliseconds.
Gets the sample rate of the audio buffer.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
- Returns:
- The sample rate of the audio buffer.
Gets the sample size of the audio buffer.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
- Returns:
- The sample size of the audio buffer.
Gets the timestamp of the audio buffer.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
- Returns:
- A
PP_TimeDelta
containing the timestamp of the audio buffer. Given in seconds since the start of the containing audio stream.
Determines if a resource is an AudioBuffer resource.
- Parameters:
-
| [in] | resource | The PP_Resource to test. |
- Returns:
- A
PP_Bool
with PP_TRUE
if the given resource is an AudioBuffer resource or PP_FALSE
otherwise.
Sets the timestamp of the audio buffer.
- Parameters:
-
| [in] | buffer | A PP_Resource corresponding to an audio buffer resource. |
| [in] | timestamp | A PP_TimeDelta containing the timestamp of the audio buffer. Given in seconds since the start of the containing audio stream. |
The documentation for this struct was generated from the following file:


Random Matrix Generator
Enter your selections below, and a random matrix will be generated.
Number of rows:
Number of columns:
Minimum value:
Maximum value:


AMAZING PEOPLE ARE MAKING AMAZING DESIGNS IN A FUN ENVIRONMENT
When you work with us, you are part of a team of committed collaborators.All aspects of our software
development process are integrated, iterative
and agile.
Our approach unifies design, development and project management to create exceptional products.
We start each project by understanding our business goals, the user's needs and the products requirements.
Then we help translate them into effective and elegant solutions
Before we sign a contract or write a line of code our team will spend the necessary
time
needed to
understand your product vision.
The outcome of this scoping session is a proposal or high level statement of work.
based on your requirements,we can provide a complete offering or just the pieces you need.
Delani Project1
Delani Project2
Delani Project3
Delani Project4
Delani-project5
Delani Project6
Delani Project7
Delani Project8


Private Island Resort
Accomodations
Activities
Travel Arrangements
Pictures, etc.
Contact Information


13 Debugging
13.1 Tools and FAQ
Persons who use Orber for the first time may find it hard to tell what goes wrong when trying to setup communication between an Orber-ORB and ORB:s supplied by another vendor or another Orber-ORB. The purpose of this chapter is to inform about the most common mistakes and what tools one can use to overcome these problems.
Tools
To begin with, Orber can be configured to run in debug mode. There are four ways to set this parameter:
- erl -orber orber_debug_level 10 - can be added to a start-script.
- corba:orb_init([{orber_debug_level, 10}]) - this operation must be invoked before starting Orber.
- orber:configure(orber_debug_level, 10) - this operation can be invoked at any time.
- OrberWeb - via the Configuration menu one can easily change the configuration. For more information, see the OrberWeb chapter in this User's Guide.
When Orber runs i debug mode, printouts will be generated if anything abnormal occurs (not necessarily an error). An error message typically looks like:
=ERROR REPORT==== 29-Nov-2001::14:09:55 === =================== Orber ================= [410] corba:common_create(orber_test_server, [{pseudo,truce}]); not a boolean(truce). ===========================================
In the example above, we tried to create an object with an incorrect option (i.e. should have been {pseudo,true}).
If you are not able to solve the problem, you should include all generated reports when contacting support or using the erlang-questions mailing list.
It is easy to forget to, for example, set all fields in a struct, which one may not discover when developing an application using Orber. When using a typed language, such faults would cause a compile time error. To avoid these mistakes, Orber allows the user to activate automatic typechecking of all local invocations of CORBA Objects. For this feature to be really useful, the user must create test suites which cover as much as possible. For example, invoking an operation with invalid or incorrect arguments should also be tested. This option can be activated for one object or all object via:
- 'MyModuyle_MyInterface':oe_create(Env, [{local_typecheck, true}]) - This approach will only activate, or deactivate, typechecking for the returned instance. Naturally, this option can also be passed to oe_create_link/2, corba:create/4 and corba:create_link/4.
- erl -orber flags 2 - can be added to a start-script. All object invocations will be typechecked, unless overridden by the previous option.
- corba:orb_init([{flags, 16#0002}]) - this operation must be invoked before starting Orber. Behaves as the previous option.
If incorrect data is passed or returned, Orber uses the error_logger to generate logs, which can look like:
=ERROR REPORT==== 10-Jul-2002::12:36:09 === ========= Orber Typecheck Request ========= Invoked......: MyModule_MyInterface:foo/1 Typecode.....: [{tk_enum,"IDL:MyModule/enumerant:1.0", "enumerant", ["one","two"]}] Arguments....: [three] Result.......: {'EXCEPTION',{'MARSHAL',[],102,'COMPLETED_NO'}} ===========================================
Note, that the arity is equivalent to the IDL-file. In the example above, an undefined enumerant was used. In most cases, it is useful to set the configuration parameter orber_debug_level 10 as well. Due to the extra overhead, this option MAY ONLY be used during testing and development. For more information, see also configuration settings.
It is also possible to trace all communication between an Orber-ORB and, for example, a Java-ORB, communicating via IIOP. All you need to do is to activate an interceptor. Normally, the users must implement the interceptor themselves, but for your convenience Orber includes three pre-compiled interceptors called orber_iiop_tracer, orber_iiop_tracer_silent and orber_iiop_tracer_stealth.
Logging all traffic is expensive. Hence, only use the supplied interceptors during test and development.
The orber_iiop_tracer and orber_iiop_tracer_silent interceptors uses the error_logger module to generate the logs. If the traffic is intense you probably want to write the reports to a log-file. This is done by, for example, invoking:
erl> error_logger:tty(false). erl> error_logger:logfile({open, "/tmp/IIOPTrace"}).
The IIOPTrace file will contain, if you use the orber_iiop_tracer interceptor, reports which looks like:
=INFO REPORT==== 13-Jul-2005::18:22:39 === =============== new_out_connection ======= Node : myNode@myHost From : <IP_ADDRESS>:47987 To : <IP_ADDRESS>:4001 ========================================== =INFO REPORT==== 29-Nov-2001::15:26:28 === =============== out_request ============== Connection: {"<IP_ADDRESS>",4001,"<IP_ADDRESS>",47987} Operation : resolve Parameters: [[{'CosNaming_NameComponent', "AIK","SwedishIcehockeyChampions"}]] Context : [{'IOP_ServiceContext',1, {'CONV_FRAME_CodeSetContext',65537,65801}}] ==========================================
The orber_iiop_tracer_silent will not log GIOP encoded data. To activate one the interceptors, you have two options:
- erl -orber interceptors "{native,[orber_iiop_tracer]}" - can be added to a start-script.
- corba:orb_init([{interceptors, {native, [orber_iiop_tracer_silent]}}]) - this operation must be invoked before starting Orber.
It is also possible to active and deactivate an interceptor during run-time, but this will only affect currently existing connections. For more information, consult Orber's Reference Manual regarding the operations orber:activate_audit_trail/0/1 and orber:activate_audit_trail/0/1.
FAQ
Q: When my client, typically written in C++ or Java, invoke narrow on an Orber object reference it fails?
A: You must register your application in the IFR by invoking oe_register(). If the object was created by a COS-application, you must run install (e.g. cosEventApp:install()).
A: Confirm, by consulting the IDL specifications, that the received object reference really inherit from the interface you are trying to narrow it to.
Q: I am trying to register my application in the IFR but it fails. Why?
A: If one, or more, interface in your IDL-specification inherits from other interface(s), you must register them before registering your application. Note, this also apply when you inherit interfaces supported by a COS-application. Hence, they must be installed prior to registration of your application.
Q: I have a Orber client and server residing on two different Orber instances but I only get the 'OBJECT_NOT_EXIST' exception, even though I am sure that the object is still alive?
A: If the two Orber-ORB's are not intended to be a part of multi-node ORB, make sure that the two Orber-ORB's have different domain names set (see configuration settings). The easiest way to confirm this is to invoke orber:info() on each node.
Q: When I'm trying to install and/or start Orber it fails?
A: Make sure that no other Orber-ORB is already running on the same node. If so, change the iiop_port configuration parameter (see configuration settings).
Q: My Orber server is invoked via IIOP but Orber cannot marshal the reply?
A: Consult your IDL file to confirm that your replies are of the correct type. If it is correct and the return type is, for example, a struct, make sure you have set every field in the struct. If you do not do that it will be set to the atom 'undefined', which most certainly is not correct.
A: Check that you handle inout and out parameters correctly (see the IDL specification). For example, a function which have one out-parameter and should return void, then your call-back module should return {reply, {ok, OutParam}, State}. Note, even though the return value is void (IDL) you must reply with ok.
Q: I cannot run Orber as a multi-node ORB?
A: Make sure that the Erlang distribution have been started for each node and the cookies are correct. For more information, consult the System Documentation


Stickers curated monthly from your favorite Etsy shops, sized to fit an Erin Condren Planner
A selection of inserts, stickers and pens for your personal sized planner!
We are producers of 100% grass-fed beef log grown mushrooms. Through intensively managed rotational grazing and responsible agro forestry methods, we aim to create efficient strategies to improve our land and ecosystem in a way that mimics nature's perennial processes. Our goal is to produce good, healthy food and to share an understanding of our role in the natural world. Back Paddock Farm is located in New Paltz, NY. Our farm was selected to participate in Glynwood's Hudson Valley Farm Business Incubator, which provides the tools and resources aspiring agricultural entrepreneurs need to develop and manage viable farm businesses in the Hudson Valley


Month Picker demo page
Simple Month Picker unbound
The currently selected month is
while the selected year is
.
Show selected year
Show selected month


#define _GNU_SOURCE /* See feature_test_macros(7) */ #include <stdio.h> FILE *fopencookie(void *cookie, const char *mode, cookie_io_functions_t io_funcs);
In order to create a custom stream the programmer must:
The fopencookie() function serves a purpose similar to fopen(3): it opens a new stream and returns a pointer to a FILE object that is used to operate on that stream.
The cookie argument is a pointer to the caller's cookie structure that is to be associated with the new stream. This pointer is supplied as the first argument when the standard I/O library invokes any of the hook functions described below.
The mode argument serves the same purpose as for fopen(3). The following modes are supported: r, w, a, r+, w+, and a+. See fopen(3) for details.
The io_funcs argument is a structure that contains four fields pointing to the programmer-defined hook functions that are used to implement this stream. The structure is defined as follows
typedef struct { cookie_read_function_t *read; cookie_write_function_t *write; cookie_seek_function_t *seek; cookie_close_function_t *close; } cookie_io_functions_t;The four fields are as follows:
ssize_t read(void *cookie, char *buf, size_t size);
The buf and size arguments are, respectively, a buffer into which input data can be placed and the size of that buffer. As its function result, the read function should return the number of bytes copied into buf, 0 on end of file, or -1 on error. The read function should update the stream offset appropriately.
If *read is a null pointer, then reads from the custom stream always return end of file.
ssize_t write(void *cookie, const char *buf, size_t size);
The buf and size arguments are, respectively, a buffer of data to be output to the stream and the size of that buffer. As its function result, the write function should return the number of bytes copied from buf, or 0 on error. (The function must not return a negative value.) The write function should update the stream offset appropriately.
If *write is a null pointer, then output to the stream is discarded.
int seek(void *cookie, off64_t *offset, int whence);
The *offset argument specifies the new file offset depending on which of the following three values is supplied in whence:
As its function result, the seek function should return 0 on success, and -1 on error.
If *seek is a null pointer, then it is not possible to perform seek operations on the stream.
int close(void *cookie);
The cookie argument is the cookie that the programmer supplied when calling fopencookie().
As its function result, the close function should return 0 on success, and EOF on error.
If *close is NULL, then no special action is performed when the stream is closed.
$ ./a.out 'hello world' /he/ / w/ /d/ Reached end of fileNote that a more general version of the program below could be improved to more robustly handle various error situations (e.g., opening a stream with a cookie that already has an open stream; closing a stream that has already been closed).
#define _GNU_SOURCE #include <sys/types.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #define INIT_BUF_SIZE 4 struct memfile_cookie { char *buf; /* Dynamically sized buffer for data */ size_t allocated; /* Size of buf */ size_t endpos; /* Number of characters in buf */ off_t offset; /* Current file offset in buf */ }; ssize_t memfile_write(void *c, const char *buf, size_t size) { char *new_buff; struct memfile_cookie *cookie = c; /* Buffer too small? Keep doubling size until big enough */ while (size + cookie->offset > cookie->allocated) { new_buff = realloc(cookie->buf, cookie->allocated * 2); if (new_buff == NULL) { return -1; } else { cookie->allocated *= 2; cookie->buf = new_buff; } } memcpy(cookie->buf + cookie->offset, buf, size); cookie->offset += size; if (cookie->offset > cookie->endpos) cookie->endpos = cookie->offset; return size; } ssize_t memfile_read(void *c, char *buf, size_t size) { ssize_t xbytes; struct memfile_cookie *cookie = c; /* Fetch minimum of bytes requested and bytes available */ xbytes = size; if (cookie->offset + size > cookie->endpos) xbytes = cookie->endpos - cookie->offset; if (xbytes < 0) /* offset may be past endpos */ xbytes = 0; memcpy(buf, cookie->buf + cookie->offset, xbytes); cookie->offset += xbytes; return xbytes; } int memfile_seek(void *c, off64_t *offset, int whence) { off64_t new_offset; struct memfile_cookie *cookie = c; if (whence == SEEK_SET) new_offset = *offset; else if (whence == SEEK_END) new_offset = cookie->endpos + *offset; else if (whence == SEEK_CUR) new_offset = cookie->offset + *offset; else return -1; if (new_offset < 0) return -1; cookie->offset = new_offset; *offset = new_offset; return 0; } int memfile_close(void *c) { struct memfile_cookie *cookie = c; free(cookie->buf); cookie->allocated = 0; cookie->buf = NULL; return 0; } int main(int argc, char *argv[]) { cookie_io_functions_t memfile_func = { .read = memfile_read, .write = memfile_write, .seek = memfile_seek, .close = memfile_close }; FILE *fp; struct memfile_cookie mycookie; ssize_t nread; long p; int j; char buf[1000]; /* Set up the cookie before calling fopencookie() */ mycookie.buf = malloc(INIT_BUF_SIZE); if (mycookie.buf == NULL) { perror("malloc"); exit(EXIT_FAILURE); } mycookie.allocated = INIT_BUF_SIZE; mycookie.offset = 0; mycookie.endpos = 0; fp = fopencookie(&mycookie,"w+", memfile_func); if (fp == NULL) { perror("fopencookie"); exit(EXIT_FAILURE); } /* Write command-line arguments to our file */ for (j = 1; j < argc; j++) if (fputs(argv[j], fp) == EOF) { perror("fputs"); exit(EXIT_FAILURE); } /* Read two bytes out of every five, until EOF */ for (p = 0; ; p += 5) { if (fseek(fp, p, SEEK_SET) == -1) { perror("fseek"); exit(EXIT_FAILURE); } nread = fread(buf, 1, 2, fp); if (nread == -1) { perror("fread"); exit(EXIT_FAILURE); } if (nread == 0) { printf("Reached end of file\n"); break; } printf("/%.*s/\n", nread, buf); } exit(EXIT_SUCCESS); }


This test will only print "PASS" or "FAIL" if link prefetches are enabled, otherwise it will show nothing below.


cLinkedList: A simple C library that implements a doubly linked list.
More...
#include "macrodef.h"
#include <stddef.h>
#include <stdlib.h>
Go to the source code of this file.
|
| long | cListLength (cLinkedList *) |
| |
| int | cListEmpty (cLinkedList *) |
| |
| cListElem * | cListFirstElem (cLinkedList *) |
| |
| cListElem * | cListLastElem (cLinkedList *) |
| |
| cListElem * | cListNextElem (cLinkedList *, cListElem *) |
| |
| cListElem * | cListPrevElem (cLinkedList *, cListElem *) |
| |
| cListElem * | cListFindElem (cLinkedList *, void *) |
| |
| void * | cListFindData (cLinkedList *, void *) |
| |
| void * | cListFirstData (cLinkedList *) |
| |
| void * | cListLastData (cLinkedList *) |
| |
| void * | cListNextData (cLinkedList *, void *) |
| |
| void * | cListPrevData (cLinkedList *, void *) |
| |
| int | cListInit (cLinkedList *) |
| |
| int | cListInsertAfter (cLinkedList *, void *, cListElem *) |
| |
| int | cListInsertBefore (cLinkedList *, void *, cListElem *) |
| |
| int | cListAppend (cLinkedList *, void *) |
| |
| int | cListPrepend (cLinkedList *, void *) |
| |
| void | cListUnlinkElem (cLinkedList *, cListElem *) |
| |
| void | cListUnlinkAll (cLinkedList *) |
| |
| void | cListUnlinkData (cLinkedList *, void *) |
| |
cLinkedList: A simple C library that implements a doubly linked list.
- Author
- Suraj Chakravarthi Raja
◆ cLinkedList
Structure for a linked list of cListElem elements.
◆ cListElem
Structure for a single element on the cLinkedList linked list.
◆ cListAppend()
| int cListAppend |
( |
cLinkedList * |
myList, |
|
|
void * |
newData |
|
) |
| |
Inserts the specified new data at the end of the supplied linked list as the last element.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
| newData | void pointer to the new data to be inserted. |
- Returns
- Upon successful insertion, the function returns a (int) 1.
◆ cListEmpty()
Checks to see if the cLinkedList linked list passed a parameter is empty.
- Parameters
-
| myList | cLinkedList pointer of the linked list which we need to check if empty. |
- Returns
- Returns (bool) TRUE if the passed linked list is empty and (bool) FALSE otherwise.
◆ cListFindData()
| void* cListFindData |
( |
cLinkedList * |
myList, |
|
|
void * |
myData |
|
) |
| |
Attempts to find an element linked in a cLinkedList list using the data that would be held by the list element to be found. Returns a void pointer to the data found on the linked list. Returns a NULL pointer if the data isn't found. The longer the list, the longer it could take to find the element. This is a linear search.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be read. |
| myData | void pointer to the data that would be held by the list element that needs to be found. |
- Returns
- void pointer to the data found on the linked list.
◆ cListFindElem()
Attempts to find an element linked in a cLinkedList list using the data that would be held by the list element to be found. Returns a cListElem pointer to the first element holding the data if the data is found in the list. Returns a NULL pointer if the data isn't found. The longer the list, the longer it could take to find the element. This is a linear search.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be read. |
| myData | void pointer to the data that would be held by the list element that needs to be found. |
- Returns
- cListElem pointer to the first element found that holds the data being used to find the element.
◆ cListFirstData()
Returns a pointer to the data held by the first element on the cLinkedList list. But, it returns a NULL pointer if the list is empty.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
- Returns
- void pointer to the data held by the first element in the linked list passed as a pointer.
◆ cListFirstElem()
Returns a cListElem pointer to the first element on the linked list passed as a parameter. Returns a NULL pointer if the list is empty.
- Parameters
-
| myList | cLinkedList pointer to the linked list whose first element we need. |
- Returns
- cListElem pointer to the first element of the linked list.
◆ cListInit()
Dynamically initialized the cLinkedList pointer with a linked list.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
- Returns
- 1 if the linked list was succesfully iniitialized and 0 if it wasn't.
◆ cListInsertAfter()
Inserts the data element passed into the linked list specified as a list element after the specified list element.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
| newData | void pointer to the new data to be inserted. |
| elem | cListElem pointer to the element next to which the new data needs to be inserted |
- Returns
- Upon successful insertion, the function returns a (int) 1.
◆ cListInsertBefore()
Inserts the data element passed into the linked list specified as a list element before the specified list element.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
| newData | void pointer to the new data to be inserted. |
| elem | cListElem pointer to the element before which the new data needs to be inserted |
- Returns
- Upon successful insertion, the function returns a (int) 1.
◆ cListLastData()
Returns a pointer to the data held by the last element on the cLinkedList list. But, it returns a NULL pointer if the list is empty.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
- Returns
- void pointer to the data held by the last element in the linked list passed as a pointer.
◆ cListLastElem()
Returns a cListElem pointer to the last element of the linked list passed as a paramener. Returns a NULL pointer if the list is empty.
- Parameters
-
| myList | cLinkedList pointer to the linked list whose last element we need. |
- Returns
- cListElem pointer to the last element of the linked list.
◆ cListLength()
Returns the length of the cLinkedList linked list passed to it as a parameter.
- Parameters
-
| myList | cLinkedList pointer of the linked list whose length is returned. |
- Returns
- Length of the linked list passed as a parameter.
◆ cListNextData()
| void* cListNextData |
( |
cLinkedList * |
myList, |
|
|
void * |
myData |
|
) |
| |
Returns a pointer to the data next to the data on the cLinkedList list as passed to the function. But, it returns a NULL pointer if the list is empty or if the passed data does not exist.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
| myData | void pointer to the data next to which we get the want look for the next data. |
- Returns
- void pointer to the data held by the next element in the linked list passed as a pointer.
◆ cListNextElem()
Returns a cListElem pointer to the element in a cLinkedList linked list that is next to and after another element. Returns a NULL pinter if the list is empty or the element being passed as a pointer is the last element.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be read. |
| myElem | The function returns the element next to the element pointed to by this cListElem pointer. |
- Returns
- cListElem pointer to the element next to the element passed as a parameter.
◆ cListPrepend()
| int cListPrepend |
( |
cLinkedList * |
myList, |
|
|
void * |
newData |
|
) |
| |
Inserts the specified new data at the beginning of the supplied linked list as the first element.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
| newData | void pointer to the new data to be inserted. |
- Returns
- Upon successful insertion, the function returns a (int) 1.
◆ cListPrevData()
| void* cListPrevData |
( |
cLinkedList * |
myList, |
|
|
void * |
myData |
|
) |
| |
Returns a pointer to the data before the data on the cLinkedList list as passed to the function. But, it returns a NULL pointer if the list is empty or if the passed data does not exist.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
| myData | void pointer to the data before which we look for the previous data. |
- Returns
- void pointer to the data held by the previous element in the linked list passed as a pointer.
◆ cListPrevElem()
Returns a cListElem pointer to the element in a cLinkedList linked list that is before another element. Returns a NULL pinter if the list is empty or the element being passed as a pointer is the first element.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be read. |
| myElem | The function returns the element beefore the element pointed to by this cListElem pointer. |
- Returns
- cListElem pointer to the element that is before the element passed as a parameter.
◆ cListUnlinkAll()
Unlinks all elements from the linked list and empties the cLinkedList list. Calling this function before the end of the program ensure that the linked list does not leave any orphaned memory locations when the program exits.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
◆ cListUnlinkData()
| void cListUnlinkData |
( |
cLinkedList * |
delList, |
|
|
void * |
delData |
|
) |
| |
Unlinks the first element in the list which holds the data pointed to by this pointer.
- Parameters
-
| delList | cLinkedList pointer to the linked list need to be used. |
| delData | void pointer to the data whose element needs to be unlinked from the list. |
◆ cListUnlinkElem()
Unlinks the element requested from the linked list if it exists in the linked list.
- Parameters
-
| myList | cLinkedList pointer to the linked list need to be used. |
| delElem | cListElem pointer to the element that needs to unlinked. |


Class Pump
source code
object --+
|
Pump
Pumps data from a ReadStream to a WriteStream and performs flow
control where necessary to prevent the write stream from getting
overloaded.
Instances of this class read bytes from a ReadStream and write them to
a WriteStream. If data can be read faster than it can be written this
could result in the write queue of the WriteStream growing without bound,
eventually causing it to exhaust all available RAM. To prevent this,
after each write, instances of this class check whether the write queue
of the WriteStream is full, and if so, the ReadStream is paused, and a
WriteStreamdrain_handler is set on the WriteStream. When the WriteStream
has processed half of its backlog, the drain_handler will be called,
which results in the pump resuming the ReadStream.
This class can be used to pump from any ReadStream to any
WriteStream, e.g. from an HttpServerRequest to an AsyncFile, or from
NetSocket to a WebSocket.
|
|
write_queue_max_size = property(fset= set_write_queue_max_size)
|
__init__(self,
read_stream,
write_stream)
(Constructor)
| source code
|
- Overrides:
object.__init__
- (inherited documentation)
|
|
Set the write queue max size
Keyword arguments:
- Parameters:
val - The write queue max size
|
|
Start the Pump. The Pump can be started and stopped multiple
times.
|
|
Stop the Pump. The Pump can be started and stopped multiple times.
|
|
return the total number of bytes pumped by this pump.
- Decorators:
|


It took Kaley Cuoco a While to Find Harley Quinn's Voice
by Steve RussellIt can be a daunting process bringing a beloved comic book character to life, let alone one as popular as Harley Quinn, who has a new adult animated series on DC Universe.
For Kaley Cuoco, who voices the titular anti-hero, finding the right tone and character for her version of Quinn was harder than she initially thought, with the actor eventually heading back to re-record earlier dialogue after discovering right balance later on in production.
"After a few weeks, it became more manic and hysterical, so I wanted to go back and re-record [the earlier episodes] to make sure it was just as badass from the beginning," Cuoco told TVLine. "I think with any character, especially when on a new show, it takes some getting used to. I've perfected certain looks and facial expressions over the years, so this in a way was harder — also because I'm voicing someone as iconic as Harley. And also, my voice is very recognizable, so I didn't want to force an accent or try to be someone I'm not. I'm 'Kaley as Harley,' and accepting that early on enabled me to me free and very authentic."
Click the button below to start this article in quick view.
DC Universe's Harley Quinn stars Kaley Cuoco, Lake Bell, Diedrich Bader, Alan Tudyk, Rahul Kohli, Christopher Meloni, Tony Hale, Ron Funches, Wanda Sykes, Natalie Morales, Jim Rash, Giancarlo Esposito, Jason Alexander and J.B. Smoove. The series premieres on Nov. 29.
https://schema.orgBreadcrumbListListItem1Homehttps://www.cbr.com/ListItem2TVhttps://www.cbr.com/category/tv/ListItem3TV Newshttps://www.cbr.com/category/tv/news-tv/ListItem4It took Kaley Cuoco a While to Find Harley Quinn's Voicehttps://www.cbr.com/harley-quinn-dc-universe-kaley-cuoco-harleys-voice/


Across: 1. May be appropriate to place wagers about Formula One (6) 4. Reasons for copper getting stuck in Essex (7) 9. Police give info to ladies about Rex (9) 10. I am given one turn to get to final stage (5) 11. Boy steals gems from 9 (5) 12. Allow Queen on to boat to get possession (9) 13. Is he too big-headed, for example, to turn back first? (7) 15. Begins essay on condition of property (6) 17. One has majority of 9 on list (6) 19. Like Sonny's wife's treasure (7) 22. Scones for priest? (9) 24. Lassie endlessly unpicking fibre (5) 26. Puts out about egghead being disturbed (5) 27. Obviously slice tuna at get-together (9) 28. Wild journalist held for central government (7) 29. Roy leaves out second prayer (6) Down: 1. Shoot old glove into holdall, perhaps (7) 2. Sounds like discovery may be penalised! (5) 3. Might he be treading a career path on the boards? (9) 4. Characteristic quality of eastern scenes (7) 5. He bawls out Eric King! (5) 6. Roll peas tight in pasta (9) 7. Bends down and prevents duck coming in (6) 8. I am left to bring in (6) 14. Groan about side being put together (9) 16. Financier rues art being collected by Queen (9) 18. Club magazine (7) 19. Artist taken in by shrewd clergyman... (6) 20. ...Can holy orders become idyllic? (7) 21. Note, furs on back-to-front trap cold at the back of the neck! (6) 23. Go into part of Camden terminus (5) 25. Thus Dawson gets under one's feet! (5)


Javascript
We covered three types of loops: for
, while
, and for-in
. The following example loops through a kitties array and then logs each item.
var kitties = [
"magda",
"grumpy cat",
"pi",
"roscoe",
"adventure kitty"
];
Each loop below does nearly the exact same thing.
for
loop should be used when you know how you want to control your loop. You have complete control over the condition.for (var i = 0; i < kitties.length; i++) {
console.log(kitties[i]);
}
for-in
loop will allow you to iterate and access every item in your array but may or may not return everything in the appropriate order. If you need to access all items without concern for order, you should use a for-in
loop.for (var cat in kitties) {
console.log(kitties[cat]);
}
while
loop is designed to allow you to do something without knowing how long it could occur. Remember the b button for Mario running example?var i = 0;
while (i < kitties.length) {
console.log(kitties[i]);
i++;
}
Javascript
// FIRST, let us create our object
var myObj = {
name: "James",
students: [
'Jason', 'Paul', 'Ruth', 'Katie'],
food: 'soylent',
favouriteMusic: 'indie pop',
favouriteAnimal: 'cat',
colour: 'purple',
phone: 'HTC',
money: 'none, I am broke',
isTired: false,
isAwake: false
};
// for-in loop on an object
// the goal is to log out all values in keys
console.log("Logging keys then values using for-in loop:");
console.log("---------------------------------");
// var key = index
// myObj = object
for (var key in myObj) {
// log the key only
// ie: myObj.name
// "name" is the key
console.log(key);
// only logging my values per each
// myObj.key
// or myObj[key]
console.log(myObj[key]);
}
console.log("Only logging keys using for loop:");
console.log("---------------------------------");
// create an array of my keys
// Object.keys() returns an array of all
// keys in an Object
var myKeys = Object.keys(myObj);
// now, we will just do a for loop
// for each key to be printed out
for (var counter = 0; counter < myKeys.length; counter++) {
console.log(myKeys[counter]);
}
// for-in loop on an object
// log the key : value on same line
console.log("Logging keys : values using for-in loop:");
console.log("---------------------------------");
// var key = index
// myObj = object
for (var key in myObj) {
console.log("Key: " + key + ", Value: " + myObj[key]);
}


SAX -- Simple API for XML
Print XML document report from SAX events
Do the following:
- Create a SAX parser.
- Define an SAX content handler. Your content handler should
respond to the following events:
- startDocument
- startElement
- characters
- endElement
- endDocument
- Your content handler should display (print out) the following:
(1) the tag or element name, (2) all attributes, (3) any
character data.
- Parse and display an XML document.
What you will learn:
- How to create and use a SAX parser and a SAX content handler.
- How to parse an XML file with SAX and respond to various "events"
in that file (for example, startElement, endElement, characters,
etc.).
Construct document tree from SAX events
Do the following:
- Add to your "application" a class that you will use to represent
each element in an XML document.
- Add to your SAX content handler, the ability to create a tree of
instances of your new class that represents the structure and
content of the XML document.
- Implement a function that walks the tree and "annotates" it, for
example, add an instance variable that gives the number of
characters in the character content of this node/element.
- Display the tree.
What you will learn:
- How to define a class that represents a "node" in the XML
document tree.
- How to build a tree structure from an XML document using SAX.
- How to walk and "annotate" that tree.
- How to walk the tree and print a report.


[Best] Almost Blue: Best Of Chet Baker - Almost Blue
Chet Baker Sings: It Could Happen To You-Dancing On The Ceiling (Album Version)
My Funny Valentine


I grew up in Northern Germany and attended the Christian-Albrechts-Universität in Kiel, a harbor town at the Baltic sea. I received a M.S. in computer science from Syracuse University, and a Ph.D. in mathematics from the University of Michigan in Ann Arbor. For four years, I was VP and CTO of an Internet startup that went from 3 people in a tiny office to a public company. I now teach computer science at San Jose State University and held visiting appointments at universities in Switzerland, Vietnam, and Macau. In my copious spare time I write books and articles on programming languages and computer science education.
printf("%10.2f", x);
cout << setw(10) << setprecision(2) << showpoint << x;
java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance(); formatter.setMinimumFractionDigits(2); formatter.setMaximumFractionDigits(2); String s = formatter.format(x); for (int i = s.length(); i < 10; i++) System.out.print(' '); System.out.print(s);
System.out.printf("%10.2f", x);
printf("%10.2f", x)
(Thanks to Will Iverson for the update. He writes: “Note the lack of semi-colon. Improvement!”)
println(f"$x%10.2f")
(Thanks to Dominik Gruntz for the update, and to Paul Phillips for pointing out that this is the first version that is checked at compile time. Now that's progress.)
Check them out to see what was exciting circa 1995.


{% extends "base.html" %} {% block content %}
Sorry, cannot find this page or it does not exist. There can sometimes be a slight delay between new transactions and the explorer. If this is the case you can try the page again after a few seconds.