text:
Primitives are objects that you can render. There isn't really much else in a fluxus scene, except lights, a camera and lots of primitives.
The normal way to create a primitive is to set up some state which the primitive will use, then call it's build function and keep it's returned ID (using with-primitive) to modify it's state later on.
(define myobj (with-state (colour (vector 0 1 0)) (build-cube))) ; makes a green cube (with-primitive myobj (colour (vector 1 0 0))) ; changes its colour to red
So primitives contain a state which describes things like colour, texture and transform information. This state operates on the primitive as a whole – one colour for the whole thing, one texture, shader pair and one transform. To get a little deeper and do more we need to introduce primitive data.
Primitive Data Arrays [aka. Pdata]
A pdata array is a fixed size array of information contained within a primitive. Each pdata array has a name, so you can refer to it, and a primitive may contain lots of different pdata arrays (which are all the same size). Pdata arrays are typed – and can contain floats, vectors, colours or matrices. You can make your own pdata arrays, with names that you choose, or copy them in one command.
Some pdata is created when you call the build function. This automatically generated pdata is given single character names. Sometimes this automatically created pdata results in a primitive you can use straight away (in commands such as build-cube) but some primitives are only useful if pdata is setup and controlled by you.
In polygons, there is one pdata element per vertex – and a separate array for vertex positions, normals, colours and texture coordinates.
So, for example (build-sphere) creates a polygonal object with a spherical distribution of vertex point data, surface normals at every vertex and texture coordinates, so you can wrap a texture around the primitive. This data (primitive data, or pdata for short) can be read and written to inside a with-primitive corresponding to the current object.
(pdata-set! name vertnumber vector)
Sets the data on the current object to the input vector
(pdata-ref name vertnumber)
Returns the vector from the pdata on the current object
Returns the size of the pdata on the current object (the number of vertices).
The name describes the data we want to access, for instance "p" contains the vertex positions:
(pdata-set! "p" 0 (vector 0 0 0))
Sets the first point in the primitive to the origin (not all that useful)
(pdata-set! "p" 0 (vadd (pdata-ref "p" 0) (vector 1 0 0)))
The same, but sets it to the original position + 1 in the x offsetting the position is more useful as it constitutes a deformation of the original point. (See Deforming, for more info on deformations)
pdata-ref procedures are useful, but there is a more powerful way of deforming primitives. Map and fold relate to the scheme functions for list processing, it's probably a good idea to play with them to get a good understanding of what these are doing.
(pdata-map! Procedure read/write-pdata-name read-pdata-name...)
Maps over pdata arrays – think of it as a for-every pdata element, and writes the result of procedure into the first pdata name array.
An example, using pdata-map to invert normals on a primitive:
(define p (build-sphere 10 10)) (with-primitive p (pdata-map! (lambda (n) (vmul n -1)) "n"))
This is more concise and less error prone than using the previous functions and setting up the loop yourself.
(pdata-index-map! Procedure read/write-pdata-name read-pdata-name...)
pdata-map! but also supplies the current pdata index number to the procedure as the first argument.
(pdata-fold procedure start-value read-pdata-name read-pdata-name...)
This example calculates the centre of the primitive, by averaging all it's vertex positions together:
(define my-torus (build-torus 1 2 10 10)) (define torus-centre (with-primitive my-torus (vdiv (pdata-fold vadd (vector 0 0 0) "p") (pdata-size)))))
(pdata-index-fold procedure start-value read-pdata-name read-pdata-name...)
pdata-fold but also supplies the current pdata index number to the procedure as the first argument.
Sometimes retained mode primitives can be unwieldy to deal with. For instance, if you are rendering thousands of identical objects, or doing things with recursive graphics, where you are calling the same primitive in lots of different states – keeping track of all the Ids would be annoying to say the least.
This is where instancing is helpful, all you call is:
Will redraw any given object in the current state (immediate mode). An example:
(define myobj (build-nurbs-sphere 8 10)) ; make a sphere (define (render-spheres n) (cond ((not (zero? n)) (with-state (translate (vector n 0 0)) ; move in x (draw-instance myobj)) ; stamp down a copy (render-spheres (- n 1))))) ; recurse! (every-frame (render-spheres 10)) ; draw 10 copies
Built In Immediate Mode Primitives
To make life even easier than having to instance primitives, there are some built in primitives that can be rendered at any time, without being built:
(draw-cube) (draw-sphere) (draw-plane) (draw-cylinder)
(define (render-spheres n) (cond ((not (zero? n)) (with-state (translate (vector n 0 0)) ; move in x (draw-sphere)) ; render a new sphere (render-spheres (- n 1))))) ; recurse! (every-frame (render-spheres 10)) ; draw 10 copies
These built in primitives are very restricted in that you can't edit them or change their resolution settings etc, but they are handy to use for quick scripts with simple shapes.


Christophe Limbrée
 - Citations Per Year
Learn More
In the railway domain, an interlocking is the system ensuring safe train traffic inside a station by controlling its active elements such as the signals or points. Modern interlockings are configured using particular data, called application data, reflecting the track layout and defining the actions that the interlocking can take. The safety of the train(More)
In the railway domain, an interlocking is a computerised system that controls the railway signalling objects in order to allow a safe operation of the train traffic. Each interlocking makes use of particular data, called application data, that reflects the track layout of the station under control. The verification and validation of the application data are(More)
In the railway domain, an electronic interlocking is a computerised system that controls the railway signalling components (e.g. switches or signals) in order to allow a safe operation of the train traffic. Interlockings are controlled by a software logic that relies on a generic software and a set of application data particular to the station under(More)
 - 1


text:
October 20, 2022
Buildup of ice likely cause of fatal crash near Calgary
Accident site looking northwest (Image: TSB)
The Transportation Safety Board of Canada on October 17 released its investigation report (A22W0027) into the April 22, 2022, in-flight icing and fatal collision with terrain involving a Mooney M20K aircraft near Springbank Airport, Calgary, Alberta.
The pilot of the aircraft, Michael James Wilton, was killed and a passenger was taken to hospital with life-threatening injuries. Wilton was president of FlightSimple, an aircraft sales company.
The Transportation Safety Board (TSB) in its report explains the Mooney M20K departed Runway 35 at Calgary/Springbank Airport (CYBW) for a local round-robin flight on an instrument flight rules (IFR) flight plan with the two pilots on board. The aircraft had recently been purchased, and the purpose of this flight was for the right-seat pilot to become familiar with operating the Mooney 231 and learn from the pilot-in-command, who was occupying the left seat and had experience on the aircraft type.
After takeoff, TSB explains the aircraft turned left toward the TURNY waypoint, climbing to a cruising altitude of 9000 feet above sea level (ASL). It flew over High River Aerodrome (CEN4), Alberta, and headed northeast toward the EBGAL waypoint. The aircraft, explains TSB, then turned left and proceeded back toward the TURNY waypoint. When the aircraft was flying just northwest of Okotoks (CFX2), Alberta, at an altitude of approximately 8000 feet ASL, it turned slightly to the right to cross the initial approach waypoint (SEKEM) and return to CYBW for an instrument approach and landing on Runway 35.
Before crossing SEKEM, TSB explains the pilot-in-command contacted air traffic services (ATS) and requested a lower altitude because the aircraft was "picking up a little ice." ATS cleared the aircraft to descend, with a restriction of not below 6200 feet ASL.
The aircraft crossed SEKEM at an altitude of 6100 feet ASL, according to TSB, travelling at a ground speed of 97 knots. TSB explains the aircraft then crossed the step-down waypoint (XUBUM) at an altitude of 5900 feet ASL, travelling at a ground speed of 114 knots, and crossed the final approach waypoint (TARTI) at an altitude of 5800 feet ASL, approximately 500 feet above the vertical path angle and still travelling at a ground speed of 114 knots.
The aircraft, according to TSB, continued to descend and passed below the vertical path and ultimately below the decision altitude of 4190 feet ASL. It then struck the bank of a ditch on the north side of the Trans-Canada Highway, 0.6 nautical miles (NM) south of the threshold of the runway, according to the TSB report, and slid to a halt in a pasture. The pilot-in-command was fatally injured from the impact forces.

source: m-a-p/FineFineWeb


text:
This research is devoted to statics analysis of structural members under mechanical loads. Static analysis of beams under uniform transverse mechanical loads is presented. The beams are supported by simply supported boundary condition at both sides. The equilibrium equation of the beams is obtained and solved using analytical method and numerical method. The numerical method employed in this work is generalized differential quadrature (GDQ) method. The type of differential quadrature method used for numerical solution is the polynomial-based GDQ method. The differential equation is discretized into algebraic equations based on the GDQ technique. The algebraic equations are then solved to obtain the deflections of the beam. The results of GDQ method are compared with the analytical solutions. It is found that the result of GDQ method are in good agreement with those of analytical solution which shows high accuracy of the GDQ method. Effects of material properties, geometrical property (cross section of beam), and mechanical loads on deflection of the beams is investigated.
Calderon, Amani; Villalona, Alexis; and Alinaghizadeh, Farhad, "Static Analysis of Structural Members" (2019). CUNY Academic Works.

source: openbmb/Ultra-FineWeb


text:
Home → LayTOOLS Products → Physical Design → LAYVER
LayVER - Verification
LayVER is a sophisticated and comprehensive layout verification package that provides a complete set of tools to validate IC designs of any size and complexity. It offers database layer operations, it provides spacing, intersection, extension, and sizing checks, as well as device and node extraction, and net-list comparison all under the same umbrella. With these features, design rule checks (drc), layout to schematic comparison (lvs), electrical rules checks (erc) and parameter extraction (lpe) can be efficiently performed.
LayVER's flexibility accommodates very complex design constructs and can adapt to special technology demands. Unlike some traditional verification programs that use fixed device structures, LayVER offers user-definable devices – indeed any unique design structure may be identified and extracted as a device. LayVER supports industry standard database formats and net-list formats such as HSpice, PSpice, or EDIF. With its flexibility and sophisticated algorithms, LayVER delivers unparalleled verification performance.
The powerful LayVER command file language includes such features as jump and branch instructions, allows definition of variables, and, where needed for database massaging (or biasing), can output data in a LayED compatible format. It is complemented by a tool (CaliLay) which allows the import of CalibreTM command files (run-decks).
The traditional drc and lvs functions may be complemented with parasitic parameter extraction (lpe), including track resistance, contact and via resistance, and the various components of parasitic capacitance (area, lateral and fringing terms). The drc and lvs violations are placed in a file which can be overlaid on the LayED data base (using the LayED LVI* feature) for easy graphical identification of any issues flagged.
- Imports GDS2, DXF2D, CIF, GERBER (RS-274X) databases
- Operates directly on LayED databases (DBX), or on imported database
- Technology independent
- Operations may be carried out on polygons, paths, edges, or text
- Recognizes LayED PGroups
- No restrictions on polygon shape or database size
- Comprehensive select, combinatorial (logical), and sizing operations
- Full set of traditional design rules-checking commands and options
- Includes geometric and nodal checking filters
- Reads and writes various net-list formats (HSpice, PSpice, EDIF)
- Net-list devices may be combined (serial or parallel)
- Parameter expressions accepted in net-list
- Parameter tolerances may be defined for LVS net-list comparison
- Includes antenna check commands
- Provides coverage (density) checks, including 'walking window' checks for local coverage
- Comprehensive graphical evaluation of results using the LVI interface within LayED*
- Checks for soft connections
- Allows gate-swapping (or 'gate-building' for digital circuits)
- Detects and identifies text shorts
- Net-list to net-list comparison option (SVS)
- Unrestricted user-defined device structures
- Handles complex constructs such as asymmetrical contact and via rules.
- Device parameter extraction using user-defined expressions
- Comprehensive parasitic parameter extraction (LPE)
- Extracts vertical, lateral, and fringe capacitance parasitics
- Also extracts contact, via, and track resistance.
- Allows definition of variables and variable values
- Conditional branching at run time according to database contents or defined variable value
- All data extracted can be interrogated either within LayVER or graphically using LayED*
* LVI is a module that allows LayED to interface with LayVER
LayED includes the LVI option as standard
LayED screen example showing on-line DRC and LayVER report file
Latest Updates (Release 5.6)
Further speed optimizations: with special emphasis on "classical" DRC operations which are now up to three times faster.•
The EXIT command of LayVER
accepts the new qualifier /DELETE to delete (large) LayVER
databases or log files before LayVER
finishes its work.•
The COMBINE command supports so-called M-factors by the new qualifier /P_MFACTOR[=...].•
The /PROPERTY qualifier of DBINIT when used for string-valued properties has been extended to support selection using wildcard strings.•
To handle path names in different operating systems with different path separators ("/" for unix-like or "" for mswindows-like) the predefined preprocessor variable "mswindows" can be evaluated which is set only in the case LayVER
runs in an MS WindowsTM environment.


Forbidding the Clipboard for the specified process
Written by:
Vladimir Shamray,
Senior Developer
Contents
1.B B B B B Introduction
1.1.B B B B B B B The task
1.2.B B B B B B B Who is this article for?
2.B B B B B About the Windows Clipboard
2.1.B B B B B B B Clipboard overview
2.2.B B B B B B B How does it all work?
3.B B B B B Solution description
3.1.B B B B B B B Possible task solutions
3.2.B B B B B B B Project implementation
3.2.1.B B B B B B B B B How to find an unexported function?
3.2.2.B B B B B B B B B Finding the signatures
3.2.3.B B B B B B B B B Function search implementation
3.2.4.B B B B B B B B B Setting hooks
3.2.5.B B B B B B B B B Hooks implementation
3.3.B B B B B B B Building the sample
3.4.B B B B B B B Supported Windows versions
4.B B B B B Conclusions
5.B B B B B Bibliography

Introduction
This article is based on the real task from the project I participated in, the task was to create a software system for protecting the Windows Clipboard against unauthorized data exchange. Though the Clipboard is one of the fundamental parts of the Windows operating system, there is little information about how it works, especially in the low level. In this article, I'm going to tell you something about the Clipboard internals by showing how you can forbid access to it. I simplified the task as much as it was possible to give you a possibility to focus on the most important parts.
The task
Create a program to forbid copying data via the Clipboard from one specified application (Wordpad) to another (Notepad). The names of the applications will be hardcoded. There will be no additional control possibilities. Also, no GUI is intended.
Who is this article for
The article is written for C/C++ developers, who are familiar with Windows API and kernel-mode driver development and who are interested in how to work with the Clipboard on the low level.
The reader is supposed to have some knowledge in C programming language, Windows API (both user- and kernel-mode ones) and the OS architecture. The reader doesn't have to be an expert in driver development but he/she has to know what drivers are and how to write the simplest one.
About the Windows Clipboard
Clipboard overview
As you know, the Clipboard is Windows component which enables applications to transfer data. An application places data into the clipboard for cut and copy operations and retrieves data from the clipboard for paste operations. Data in the clipboard can be in various formats. Each format is identified by an unsigned integer value.
An application places data into the clipboard in as many clipboard formats as possible, ordered from the most descriptive clipboard format to the least descriptive. For each format, the application calls the SetClipboardData function, specifying the format identifier and a global memory handle.
HANDLE SetClipboardData(
 UINT uFormat,
 HANDLE hMem
 );
To retrieve data from the clipboard, an application first determines the clipboard format to retrieve. Typically, an application enumerates the available clipboard formats by using the EnumClipboardFormats function and uses the first format it recognizes. Alternatively, an application can use the GetPriorityClipboardFormat function. This function identifies the best available clipboard format according to the specified priority. An application can determine whether a format is available by using the IsClipboardFormatAvailable function.
After determining the clipboard format to use, an application calls the GetClipboardData function. This function returns the handle to a global memory object containing data in the specified format.
HANDLE GetClipboardData(
 UINT uFormat
 );
Before doing some operations with the Clipboard, an application must open it with OpenClipboard function. After finishing all operations with the Clipboard it must be closed with CloseClipboard.
How does it all work?
The Clipboard is implemented as a part of the Windows subsystem. API functions of this subsystem, including Clipboard API, are in user32.dll dynamic library. But the main work is preformed in win32k.sys module, which is the kernel mode part of the Windows subsystem. Win32k.sys is responsible for many things like managing windows and window messages, drawing graphics, working with the clipboard, etc. Win32k.sys has more than 600 functions which are undocumented and not exported.
Before placing data into the Clipboard application allocates memory using GlobalAlloc function and copies the data to that memory. Eventually, application calls SetClipboard with a format code and a handle returned by GlobalAlloc as arguments. SetClipboardData in its turn makes call to the kernel-mode function NtUserSetClipboardData, which performes actual work.
When some other application wants to get data from the clipboard it calls GetClipboardData, which also calls the kernel-mode function inside itself, NtUserGetClipboardData. If retrieving the data is succeeded, it returns the handle of the data.
Solution description
Possible task solutions
Now, let's get back to the task. We want to forbid copying data from one specific process to another. Copying some data via the Clipboard is actually separated on two independent operations: copy (or cut), which is represented by SetClipboardData and paste, represented by GetClipboardData. So, on copying we have to save the process name from which data is copied and on pasting we can choose, to allow or to forbid the copying.
There are two approaches. The first approach is to hook SetClipboardData and GetClipboardData in the user mode. Both functions are well documented and, that is much more important, they are exported. This is the main advantage. But this approach requires setting hooks for all processes in the system. Also we need to track creation of the new processes to set hooks in their address spaces too.
The second approach, which is described in this article, is to hook kernel-mode functions NtUserSetClipboardData and NtUserGetClipboardData. In this case we need to set hooks only once. But both functions are not exported from win32k.sys, so it is quite a problem to find them.
Project implementation
How to find an unexported function?
Hooking a couple of functions is not a big problem. But before that we need to find them. How to find a function which is not exported? One way is to hardcode the function address in the program. The address can be easily found manually, using WinDbg, for instance. Unfortunately, it is necessary to keep a base of these addresses for each operating system (and, probably, for each service pack) which you're going to support.
Other way is to keep not an address but some sequence of bytes from which that address can be obtained. This sequence of bytes is called unique signature. It can be a piece of the function's code or a piece of code from where the function is called. Though this way is not very portable too, it much less depends on differences between the various operating system versions.
Finding the signatures
First of all, we need to find the unique signatures for two functions: NtUserSetClipboardData and NtUserGetClipboardData. Both of them are in the win32k.sys. To do it, we will use WinDbg. Let's start with the signature for NtUserGetClipboardData.
As I mentioned the function we're looking for is in the win32k.sys and this module is mapped to a session address space, it means that it is available only in the context of some interactive process, like explorer.exe. To switch to explorer.exe, you can use !process 0 0 explorer.exe to get the address of its EPROCESS and then use .process command.
kd> !process 0 0 explorer.exe
PROCESS 81946990 SessionId: 0 Cid: 063c Peb: 7ffd4000 ParentCid: 060c
 DirBase: 09b85000 ObjectTable: e19cafb8 HandleCount: 260.
 Image: explorer.exe
kd> .process /p 81946990
Implicit process is now 81946990
.cache forcedecodeuser done
Let's take a look at the NtUserGetClipboardData. We can see its disassembly using u debugger command
kd> u win32k!NtUserGetClipboardData win32k!NtUserGetClipboardData+93
win32k!NtUserGetClipboardData:
bf8e9569 6a20 push 20h
bf8e956b 6888b198bf push offset win32k!'string'+0x268 (bf98b188)
bf8e9570 e84376f1ff


text:
Photo credit: gifrancis via Flickr
Clothespin Games are two-fold in their purpose. They can address target learning skills and they are great for strengthening fine motor skills in little hands. Plus, clothespins are cheap! You can find them at the dollar stores in the laundry supplies. I prefer the wooden clothespins because they can be written on to address skills.
There are a variety of ways to make simple clothespin games:
- ABC Order: Label clothespins A-Z and have kids pin them to a hanger in the correct order.
- Number Order: Label clothespins 1-20 and have kids pin them to a hanger in the correct order.
- Spelling: Use the A-Z clothespins to spell names, sight words, etc.
- Word Families: Use the A-Z clothespins when working on word families. Have kids change the first letter to change the words.
- The Adventures of Bear ~ Clothespin Color Game
- The Adventures of Bear ~ Clothespin Spelling
- The Adventures of Bear ~ Paint Chip Color Clothespin Match-up
- 221Vision.com ~ Paint Chip Color Clothespin Match-up
Printable Clothespin Games:
- Confessions of a Homeschooler ~ A-Z Review Clothespin Match-up & Number Circles
- Confessions of a Homeschooler ~ Clothespin Number Cards
- Confessions of a Homeschooler ~ Beginning Math Skills
- Teach Mama ~ ABC Cards and Clothespin Match on a string
- 1+1+1=1 ~ Learning Color Wheels
- 1+1+1=1 ~ Uppercase/Lowercase Matching
- 1+1+1=1 ~ How Many? Number Cards
- Some of the preschool packs from Homeschool Creations and 1+1+1=1 have cards that can be made into a clothespin game.

source: HuggingFaceFW/fineweb-edu


text:
You may have situations, especially when your app requires user interaction with the map, that call for displaying some sort of instructions. Have a look at this Esri sample and note the bit of text along the top of the map enclosed within a semi-transparent box.
This text box is created through two steps:
- In the HTML, a div element is defined and assigned an id. Within the div, the desired text is placed inside a p element.
- In the CSS, the div is placed through absolute positioning 10 pixels from the top of the page and 62 pixels from the left. A padding of 12 pixels is added to the left and right of the div so that the text isn't rendered too close to the edge. The text is given a white color, while the background of the element is made black with a transparency value of 0.5. This allows the text to be displayed to the user without completely obstructing the view of the map underneath.