I use the properties($^) and src(edge) functions starting from "2" over sell to find "1". But the returned results are different, as shown below.
(root#nebula) [basketballplayer]> go from "2" over follow reversely yield properties($$)
+-------------------+
| properties($$) |
+-------------------+
| {name: "A"} |
+-------------------+
(root#nebula) [basketballplayer]> go from "2" over follow reversely yield src(edge)
+------------+
| src(EDGE) |
+------------+
| "1" |
+------------+
find a vertex starting from vid2
Can you tell me the difference in the usage of properties($^) and src(edge) in Nebula Graph?
src(edge) always represents the src in the edge, and $^ represents the vertex from which to expand in the NebulaGraph database.
Related
When I prepare for my exam, I meet the following statement:
If file1 and file2 are hard linked, and two processes open file1 and file2,
their read/write pointer keeps the same.
Which, according to the answer (no explanation), is wrong. So I searched google, and found something different.
This link: https://www.usna.edu/Users/cs/wcbrown/courses/IC221/classes/L09/Class.html Says the read/write pointer is in the (system wide) open file table.
But this link http://www.cs.kent.edu/~walker/classes/os.f08/lectures/Walker-11.pdf
Says the pointer is in the per process file table.
Which one is true?
IHMO, the read/write offset clearly has to be a per process property. You could easily crash other proceses if this was a system wide per file property. This is my understang, but I'd rather have this confirmed by an informed source.
I took a look at the 1986 AT&T book "The design of the Unix Operating System" by Maurice J. Bach, which I consider a informed source.
In topic 2.2.1 An Overview of the File Subsytem it sais:
... Inodes are stored in the file system ... The kernel reads them
into an in-core inode table when manipulating files ... The kernel
contains two other data structures, the file table and the user
file descriptor table. The file table is a global kernel
structure, but the user file descriptor table is allcated per
process ... The file table keeps track of the (read/write) byte
offset ...
This would contradict my statement. But then, clarification can be read in topic 5.1 OPEN, pages 92ff. Figure 5.3 shows an example of a process having done three opens, two of them being for the same file, /x/y/z (I simplfy the naming here, and in the illustration below).
User File
Descriptor Table File Table inode Table
+--------------+ +------------+ +------------+
0| | | | | |
+--------------+ | . | | . |
1| | | . | | . |
+--------------+ | . | | . |
2| | +------------+ | |
+--------------+ +-->| read offset|----+ | |
3| | | +------------+ | | |
+--------------+ | | | | +------------+
4| |---+ | . | +->| inode of |
+--------------+ | . | +--->| /x/y/z |
5| |----+ | . | | +------------+
+--------------+ | +------------+ | | . |
6| |-+ +->| read |----+ | . |
+--------------+ | +------------+ | | | . |
| . | | | . | | | +------------+
| . | | | . | | +->| inode of |
| | | | . | | | /a/b |
+--------------+ | +------------+ | +------------+
+---->|write offset|--+ | . |
+------------+ | . |
| . | | . |
| . | | . |
+------------+ +------------+
The final answer is in the text following figure 5.3 on page 94:
Figure 5.3 shows the relationship between the inode table, file
table, and user file descriptor table structures. Each open
returns a file descriptor to the process, and the corresponding entry
in the user file descriptor table points to a unique entry in the
kernel file table even though one file (/x/y/z) is opened twice.
To answer your question: The read/write offset is kept in the kernel file table, not in a per process table, but a unique entry is allocated upon each open().
But, why is there a kernel file table? After all, the read/write offsets could have been stored in the per process user file descriptor table, instead of in a kernel table, couldn't they?
To understand why there is a kernel file table, think of what the dup() and fork() functiones do with respect to file descriptors: They duplicate the state of an open file. Under a new file descriptor in the same process, dup(), or under the same file descriptor (number) but in a duplicated user file descriptor table in the new (child) process. In both cases, duplicating the state of an open file includes the read/write offset. So for these cases, more than one file descriptor will point to a single file table entry.
There are several wrapper types in the Rust standard library:
The cells in the std::cell module: Cell and RefCell
The reference-counted wrappers, like Rc and Arc.
The types in the std::sync module: Mutex or AtomicBool for example
As I understand it, these are wrappers which provide further possibilities than a simple reference. While I understand some basics, I cannot see the whole picture.
What do they do exactly? Do cells and reference-counted families provide orthogonal or similar features?
There are two essential concepts in Rust:
Ownership,
Mutability.
The various pointer types (Box, Rc, Arc) are concerned with Ownership: they allow controlling whether there is a single or multiple owners for a single object.
On the other hand, the various cells (Cell, RefCell, Mutex, RwLock, AtomicXXX) are concerned with Mutability.
The founding rule of Rust's safety is Aliasing NAND Mutability. That is, an object can only be safely mutated if there is no outstanding reference to its interior.
This rule is generally enforced at compile time by the borrow checker:
if you have a &T, you cannot also have a &mut T to the same object in scope,
if you have a &mut T, you cannot also have any reference to the same object in scope.
However, sometimes, this is not flexible enough. Sometimes you DO need (or want) the ability to have multiple references to the same object and yet mutate it. Enter the cells.
The idea of Cell and RefCell is to permit mutability in the presence of aliasing in a controlled manner:
Cell prevents the formation of reference to its interior, avoiding dangling references,
RefCell shifts the enforcement of Aliasing XOR Mutability from compile time to runtime.
This functionality is sometimes described as providing interior mutability, that is where an object which otherwise looks immutable from the outside (&T) can actually be mutated.
When this mutability extends across multiple threads, you will instead use Mutex, RwLock or AtomicXXX; they provide the same functionality:
AtomicXXX are just Cell: no reference to the interior, just moving in/out,
RwLock is just RefCell: can obtain references to the interior through guards,
Mutex is a simplified version of RwLock which does not distinguish between a read-only guard and write guard; so conceptually similar to a RefCell with only a borrow_mut method.
If you come from a C++ background:
Box is unique_ptr,
Arc is shared_ptr,
Rc is a non thread-safe version of shared_ptr.
And the cells provide a similar functionality as mutable, except with additional guarantees to avoid aliasing issues; think of Cell as std::atomic and RefCell as a non thread-safe version of std::shared_mutex (which throws instead of blocking if the lock is taken).
Thanks to Matthieu's good answer, here is a diagram to help people to find the wrapper they need:
+-----------+
| Ownership |
+--+--------+ +================+
| +-Static----->| T |(1)
| | +================+
| |
| | +================+
| +-----------+ | Local Val| Cell<T> |(1)
+-Unique-->| Borrowing +--+-Dynamic---->|----------------|
| +-----------+ | Ref| RefCell<T> |(1)
| | +================+
| |
| | +================+
| | Threaded | AtomicT |(2)
| +-Dynamic---->|----------------|
| | Mutex<T> |(1)
| | RwLock<T> |(1)
| +================+
|
|
| +================+
| +-No--------->| Rc<T> |
| | +================+
| Locally +-----------+ |
+-Shared-->| Mutable? +--+ +================+
| +-----------+ | Val| Rc<Cell<T>> |
| +-Yes-------->|----------------|
| Ref| Rc<RefCell<T>> |
| +================+
|
|
| +================+
| +-No--------->| Arc<T> |
| | +================+
| Shared +-----------+ |
+-Between->| Mutable? +--+ +================+
Threads +-----------+ | | Arc<AtomicT> |(2)
+-Yes-------->|----------------|
| Arc<Mutex<T>> |
| Arc<RwLock<T>> |
+================+
In those cases, T can be replaced with Box<T>
Use AtomicT when T is a bool or a number
To know if you should use Mutex or RwLock, see this related question.
This is related to Creating a peek in effect with animate.css which was answered via using overflow:hidden, but does not work with column-count:
I am using the excellent animate.css library for animations. I was wondering if its possible to create a "peek in" and "peek out" effect that is similar to the SlideIn/SlideOut but with the following difference:
slideOutRight
+-------------+ +-------------+
| | | |
| | | |
| +---------+ | +---+----+
| | anim | | | anim |
| +---------+ | +---+----+
| | | |
+-------------+ +-------------+
peekOutRight
+-------------+ +--------------+
| | | |
| | | |
| +---------+ | +----+
| | anim | | | an|
| +---------+ | +----+
| | | |
+-------------+ +--------------+
In other words, the difference is that peek does not go out of the parent object boundaries. I've tried adding clip/clip-path to the anim element but it does not look like translate3d takes that into account.
The slideInRight/OutRight code of animate.css is pretty straighforward -
It's moving X by 100% - I'd like to make sure it gets cropped as it moves out of the parent frame.
I've setup a codepen to illustrate this in action - would appreciate any advice
http://codepen.io/pliablepixels/pen/pgxqOX
The caveat is that it must work with -column-count. as you see in the codepen, the moment you use column-count, the 2nd column does not show the header
Added Clarification on why I need it to work with columns:
I need to pack the frames so that odd sized frames are not arranged by row. This codepen illustrates the issue of using flex-row vs. column-count -http://codepen.io/pliablepixels/pen/MKPLBp
If you switch to byrow you'll see images are aligned in a way that the row takes up the height of the largest image, which means if you reduce the browser width,"D" goes to row 3 instead of going under "C". Switch to column mode and it packs in better.
The below is rewarded with a complaint that Remove Directory requires 1 or 2 arguments and I gave it none. I'm using 2.6.3, and dcsLshLocation is a variable (and adding an x in front doesn't change the error). I'm using the Java version of all this.
*** Settings ***
| Documentation | http://jira.basistech.net:8080/browse/JEST-226
| Resource | src/main/resources/jug-shared-keywords.txt
| Force Tags | integration |
| Suite Precondition | Run Keywords |
| | ... | Validate SUT Installations |
| | ... | Launch Derby Server |
| | ... | Copy file ${jddInstallDir}/conf/jdd-conf-basic.xml to ${jddInstallDir}/conf/jdd-conf.xml
| | ... | Remove Directory | ${dcsLshLocation} |
| Suite Teardown | Run Keywords | Shutdown Derby
| Test Timeout | 20 minutes
When this question was originally written, Run Keywords could only run keywords that do not take arguments. That is no longer true. From the documentation:
Starting from Robot Framework 2.7.6, keywords can also be run with arguments using upper case AND as a separator between keywords. The keywords are executed so that the first argument is the first keyword and proceeding arguments until the first AND are arguments to it. First argument after the first AND is the second keyword and proceeding arguments until the next AND are its arguments. And so on.
The code in the question can thus be expressed like this:
| Suite Precondition | Run Keywords |
| | ... | Validate SUT Installations
| | ... | AND | Launch Derby Server
| | ... | AND | Copy file ${jddInstallDir}/conf/jdd-conf-basic.xml to ${jddInstallDir}/conf/jdd-conf.xml
| | ... | AND | Remove Directory | ${dcsLshLocation}
The following is the original answer to the question, which others may still find useful. It is still relevant for versions of robot framework prior to 2.7.6.
When you use Run Keywords, you cannot run keywords that take arguments. Admittedly the documentation is a bit unclear, but this is what it says:
User keywords must nevertheless be used if the executed keywords need
to take arguments.
What it should say is that, when you use Run Keywords, each argument is the name of a keyword to run. This keyword cannot take any arguments itself because robot can't know where the arguments for one keyword ends and the next keyword begins.
Remember that ... simply means that the previous row is continued on the next, so while it looks like each row is a separate keyword with arguments, it's not. You example is the same as:
| Suite Precondition | Run Keywords |
| | ... | Validate SUT Installations |
| | ... | Launch Derby Server |
| | ... | Copy file ${jddInstallDir}/conf/jdd-conf-basic.xml to ${jddInstallDir}/conf/jdd-conf.xml
| | ... | Remove Directory |
| | ... | ${dcsLshLocation} |
From the get go: sorry if I'm not using the proper emacs terminology -- I'm relatively wet behind the ears in the emacs world.
Most of my work in emacs is for programming R, and I'm using ESS and ECB to do so quite happily. I'd like to build a custom ECB layout which uses the entire bottom of the screen as my R console, while putting some ECB-specific buffers on the left.
Using ECB-esque layout diagrams, I'd like my layout to look like pretty much exactly like "left13", except I'd like the entirety of the "compilation" buffer to be my running R console (or any shell, for that matter):
-------------------------------------------------------
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| Directories | Edit |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
-------------------------------------------------------
| |
| R Console |
| |
-------------------------------------------------------
If I can just split my buffer in two (vertically), then call ecb-activate from the top buffer (and not allow it to touch my bottom buffer), I'm imagining it could work (hence the subject of my question).
That doesn't work, though, and I don't know how to get an entier "bottom pane" out of a layout to work in the way I like using trying to use ECB's customize layout functionality.
Does anybody know if/how I can do this?
Short answer: No.
Longer answer: Unfortunately, ECB completely takes over Emacs "window" management at a very low level. So it's all or nothing. You can't comfortably combine it with regular window splitting. What you might be able to do, is to adjust the layout ECB gives you or to program a custom layout. (Some assembly required.)