Show cache hits and misses when rendering partials.
Partials using the
cache
helper will show whether a render hit or missed the cache:Rendered messages/_message.html.erb in 1.2 ms [cache hit] Rendered recordings/threads/_thread.html.erb in 1.5 ms [cache miss]
This removes the need for the old fragment cache logging:
Read fragment views/v1/2914079/v1/2914079/recordings/70182313-20160225015037000000/d0bdf2974e1ef6d31685c3b392ad0b74 (0.6ms) Rendered messages/_message.html.erb in 1.2 ms [cache hit] Write fragment views/v1/2914079/v1/2914079/recordings/70182313-20160225015037000000/3b4e249ac9d168c617e32e84b99218b5 (1.1ms) Rendered recordings/threads/_thread.html.erb in 1.5 ms [cache miss]
Though that full output can be reenabled with
config.action_controller.enable_fragment_cache_logging = true
.Stan Lo
Don't override the
Accept
header in integration tests when called withxhr: true
.Fixes #25859.
David Chen
Fix 'defaults' option for root route.
A regression from some refactoring for the 5.0 release, this change fixes the use of 'defaults' (default parameters) in the 'root' routing method.
Chris Arcand
Check
request.path_parameters
encoding at the point they're set.Check for any non-UTF8 characters in path parameters at the point they're set in
env
. Previously they were checked for when used to get a controller class, but this meant routes that went directly to a Rack app, or skipped controller instantiation for some other reason, had to defend against non-UTF8 characters themselves.Grey Baker
Don't raise ActionController::UnknownHttpMethod from ActionDispatch::Static
Pass
Rack::Request
objects toActionDispatch::FileHandler
to avoid it raisingActionController::UnknownHttpMethod
. If an unknown method is passed, it should exception higher in the stack instead, once we've had a chance to define exception handling behaviour.Grey Baker
Handle
Rack::QueryParser
errors inActionDispatch::ExceptionWrapper
Updated
ActionDispatch::ExceptionWrapper
to handle the Rack 2.0 namespace forParameterTypeError
andInvalidParameterError
errors.Grey Baker
Please check 5-0-stable for previous changes.


GO.sh documentation
GO.sh: Simple Accounting using HAML and CSV
Description
- Simple accounting for my personal use. Generates HTML from HAML and CSV.
- Individual records are stored in CSV and HAML files. They must be in same directory. CSV file contains transactions. HAML file contains client's record (long content possible).
- Client's name is in first line of HAML file. First line should be something like ~CLIENT'S NAME. The client's name comes after the tilde (~).
Usage
./GO.sh directory_containing_data
- If records are in example directory, the command to process them is:
./GO.sh example
- GO.sh will generate table.html and new files in out. To distribute the generated files, copy table.html, out directory and script directory.
- Keep different sets of data in their own directories, e.g.
- office_accounts = for office accounts
- house_expenses = for household expenses.
- To view records in web browser, enter:
./GO.sh example
firefox table.html
- You can view the generated files anywhere using: (a) table.html and (b) two directories of out and script.
Notes
- Contents of out will be deleted everytime GO.sh is run.
- GO.sh uses Linux, Python and the HamlPy package.
- Banks do end of day processing, so take a hint. You only need to regenerate HTML as needed.
- Records are managed by editing CSV and HAML.
About this project
Hacked together by Kevin Koo Seng Kiat from Kuala Lumpur. Reach me on Twitter at @kevinkoosk


RESEARCH EXPERIENCE
Institute of Human Language Technology, Soochow University
Research on NLP
Sep 2013 – Jan 2017
Developed a reptile program to get parallel corpus from website based on JAVA, which can be used as training or testing file for SMT and NMT experiments. Classify the corpus and writing documents.
Project of term extraction using statistical methods. It can extract bilingual terms from parallel corpus efficiently.
Designing different Convolutional neural networks to improve the accuracy of the existent translation system using Theano and Python.
Translation Analysis System
Jul. 2015 - Aug. 2015
Designed a Translation Visualization system using ECharts and JavaScript, which can help researchers analyses the machine translation process in a clear and convenient way.
Designed an Intelligent machine translation analysis system, which can tell users both general and specific performance of two different translation systems, based on HTML, JSP, Bootstrap, and JAVA.
Directed Research Project ‘KashFlow’ in USC (NLP)
Jan 2018 - Now
Using crawler to capture information of financial products, and collecting user’s financial story by Plaid.
Chunking and analysis data using NLTK.
Created a method to automatically suggest & open new products (credit cards &/or loans) to “normalize”
user’s credit profile and squeeze more cash or points out of user’s current situation.
WORK EXPERIENCE
AI R&D reseach Intern, Knexus research Corporation
Jun. 2018 - Aug. 2018
Responsible for the development of AI and ML algorithm
Intern, NONEAD Corporation
Aug. 2016 - Apr. 2017
Responsible for the development of embedded system
Developed the software of robot: Nexteer automatic screw project, Nexteer rotor sprint project.
Intern, Jiangsu Suzhou Local Taxation Bureau
Jul. 2015 - Aug. 2015
Responsible for online platform work for the tax system
Responsible for online account cancellation made by enterprises
Responsible for online invoice sales
Design
JQuery,Javasript,HTML,CSS,Bootstrap
Tools
Pytorch, NLTK, NetBeans, Apache Tomcat, Github
Awards
China Talent Scholarship 2016
1st Prize of Excellent Student Scholarship 2015 - 2016
Foreign Exchange Student Scholarship 2015
Excellent Student Scholarship of Government Office 2015
International Exchange Student Scholarship of UW-Madison 2015
Quality Development Scholarship 2015
2nd Prize of Excellent Student Scholarship 2014 - 2015
Comprehensive Scholarship 2014 & 2015& 2016
Merit Student of Soochow University 2014 & 2016
Social Work Scholarship 2014 & 2016
1st Prize of Excellent Student Scholarship 2013 - 2014


cpgf library -- general frequently asked questions
General
Reflection
Script binding (Lua and Google V8 Javascript)
General
What's the exception safety in cpgf library?back top
The library provides basic exception safety. That's to say, when exception occurs, no memory leak, and the object is not garbled.
However, it's hard to guarantee the exceptio safety. So if you find anything that's not exception safety, let me know.
What's the thread safety in cpgf library?back top
The library is not safe for writting at the same time in multiple thread.
Due to the static objects and lazy meta data building, before the static objects intializes and lazy occurs. reading from multiple thread is not safe.
But when all static objects initializes and lazy occurs, reading is safe in multiple thread.
For example, if you get a meta method in one thread, calling the method in several threads at the same time should be safe.
However, the library is not tested in multiple threads environment yet, so take your own risk.
Some of the library document is bad, I want to help to rephrase it, how can I help?back top
First, any intention of helping the library is appreciated.
Second, about the documentation.
I wrote a Perl script to parse my own defined document format to create the document.
So it's hard for anyone else to edit the document source file directly unless you want to learn my own format.
To help to improve the document, you just need to copy the paragraph, or the whole text, from the web page, edit it in a text editor, then send the revision back to me by email.
You can find my gmail address in the About page.
Note: you can only help to improve the content, not the format.
Reflection
When I build meta data for method, why the compiler issues warning like returning reference to temporary object?back top
This is because either the parameter, or the return value, is a reference-to-const to an object which can be constructed implicitly from a fundamental (int, char, etc) type or pointer or reference to a fundamental type.
For example, if we have this method,
void setName(const std::string & name);
std::string can be constructed implicitly from const char *.
When this kind of method is reflected, GVariant will try to return reference to local temporary object.
That warning is dangerous, it may crash your program.
To solve this issue, use policy GMetaPolicyCopyAllConstReference.
That policy will force the parameter or return value being passed by value instead of reference.
._method("setName", &setName, GMetaPolicyCopyAllConstReference())
cpgf doesn't support reflecting meta data for namespace. I need namespace, please!back top
It's true that cpgf doesn't support reflecting namespace.
There are two reasons for it.
1, Reflecting namespace will cause using meta data much more complicated.
2, Namespace in C++ is less important. It's mainly used to avoid naming clash.
However, we can simulate namespace reflection in cpgf perfectly.
There is a typedef in gmetadefine.h
typedef GDefineMetaClass<void> GDefineMetaNamespace;
GDefineMetaNamespace acts as a virtual meta class.
A GDefineMetaNamespace can hold any meta data.
A GDefineMetaNamespace can be added to global, or even another meta class (in C++ we can't have namespace in a class, but in cpgf we can).
The OpenGL and Box2D sample code in cpgf package demonstrate the use of namespace well.
Script binding (Lua and Google V8 Javascript)
When should I use bindMethod and bindMethodList?back top
If you are only binding classes, never you need to call bindMethod or bindMethodList.
cpgf will bind all class members automatically.
bindMethod and bindMethodList are useful if you want to bind methods to global scope under current script object.
Why the Google V8 binding is based on an old version V8 (v3.4.5)?back top
First, the V8 version used in cpgf is not very old. It should be already stable version.
Second, the reason cpgf doesn't use an up to date V8 version is that, V8 is always using some exotic building system, from Scons to gyp, rather than makefile or CMake, which is widely accepted by C++ world.
It's very hard to get those weird building system working correctly under MS VC and MinGW, both of which are used to develop cpgf.
You may check the user comments on V8 web page
here and
here to see how other V8 users said.
The total time I wasted on building V8 is much longer than total time I spent on building wxWidgets and Qt.
I would like to invest my time on more valuable works, rather than building a third party library.
So let's stick with current V8 version 3.4.5, until the future V8 is not compatible with it.


class: center, middle, inverse, title-slide # Using Data from my Backyard Garden to Teach Introductory Data Science ### Lisa Lendway, PhD ### Macalester College --- background-image: url(images/IMG_0952.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse # Jungle Garden  ??? Welcome to my garden. Before I talk about how I use data from it in my intro course, I want to tell you a little bit about how my garden came to be. I started gardening in the summer of 2004, the first year I had a house with a backyard. I don't have a picture from back then, but here's one from 2013. Perhaps it gives you a sense of why I fondly refer to it as the jungle garden? --- background-image: url(images/IMG_8551.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse # Starting over ??? In 2017, my family and I moved. So, in 2018, I needed to start fresh. --- background-image: url(images/IMG_8619.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? We made boxes for raised beds and built a fence to keep all the rabbits out! --- background-image: url(images/IMG_8879.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? I laid A LOT of bricks for paths. --- background-image: url(images/IMG_0446.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? By May of 2019, things were really shaping up (and my forearms were quite sore from lifting all those bricks!). --- background-image: url(images/IMG_2800.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? This photo is from June 2020, with the garden just starting to bloom. --- background-image: url(images/IMG_2985.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? I love spending time in my garden. --- background-image: url(images/IMG_2987.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? And this new one has lived up to the jungle garden name of its predecessor. --- background-image: url(images/IMG_3017.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? The pumpkin/squash arch is my favorite feature and is abuzz with bees most of the summer. --- background-image: url(images/IMG_3065.jpeg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? It's a fairly productive garden, too! --- background-image: url(images/IMG_2993.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? I preserve and eat as much as I can. --- background-image: url(images/IMG_3048.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse ??? And share with others, too. That's zucchini bread, if you're wondering. ---  ??? Last year, I harvested nearly 1000 pounds of food from the garden! Which reminds me ... I'm supposed to be talking to you about using the data in my class. Let's get to that. --- # Garden data * Why use data from the garden? - I could use it to teach a lot of intro data science topics. - It's interesting (at least I think it is). - Personal connection. - Why not?! * How? - Google sheet and later an R package called [gardenR](https://github.com/llendway/gardenR): https://github.com/llendway/gardenR - To introduce new functions & for a perfect garden graph assignment ??? Sometime in the spring of 2020, I realized that I could combine my love of my garden with my love of data by collecting data about my garden to use in my intro data science course. And, why did I think this was a good idea? I could use the data to introduce almost every topic I intended to teach in my intro data science course at Macalester College. Topics include data visualization - bar charts, histograms, line graphs, scatterplots, boxplots, and more!; data wrangling - creating new variables, summarizing data, joining, rearranging, string manipulation, etc.; adding animation and interactivity to graphs, including creating shiny apps; importing data; and creating nice tables. The two places where I didn't use my garden data were creating maps and scraping data. I know I'm biased, but I thought it was fairly interesting. Something I didn't realize initially was the personal connection it would bring. Students could ask questions about data collection that they couldn't usually ask about data we use in the class since I had collected and curated it. So, why not give it a try?! And, how did I use it? To answer that literally, as in how did students access the data, at first, the data were collected in a google sheet (I'll show that in a moment). After I finished collecting data for the year, I created an R data package. And, how as in what ways did we use the data? I already mentioned how I used it to introduce new topics. Later I'll talk to you about the "Perfect Garden Graph" assignment. --- # The data! ```r library(gardenR) # for garden data :) head(garden_harvest) ```

 ??? I'm going to jump over to RStudio in a moment, but wanted to at least introduce the main dataset here. Each row in the data is a “harvest” for a variety of a vegetable. So, vegetables might have multiple rows on a day, especially if they are things I eat twice a day (lettuce) or there are many different varieties of the vegetable (tomatoes). We'll see some examples of this later. There are 5 columns or variables: vegetable, variety, date of harvest, weight, and units of weight (which turn out to all be in grams, but I wasn't sure that would be the case when I started collecting data). --- # Demo in RStudio For more examples of using the data, see my Introduction to Data Science course website: https://ds112-lendway.netlify.app/. ??? Go over examples. --- # Perfect garden graphs Each week, you will submit a graph using my garden data. For this graph, you should ask a question of the data and then create a graph to answer that question. You will get feedback from me each week and will build on your previous graph. So, you don’t create a completely NEW graph each week, but rather continue to improve on the SAME graph over the entire course. This assignment will focus on the details of the graph that we don’t usually have time for in weekly assignments. It will also be about writing nice code and annotating it. ??? This is the description of the perfect garden graph assignment. I'll read it to you. Then, we'll take a look at some examples from my students who gave me permission to share their work. --- background-image: url(pgg_examples/chloe1.png) background-size: contain background-position: 50% 50% class: right, top, inverse # Chloé Nance ??? Chloé wanted to know the average harvest size of the different vegetables. In this first week my feedback was, "One idea would be to make the actual points smaller and lighter colored (using size and alpha outside of the aes() but inside the geom_point()), and then put the average harvest size on top of that maybe even using a different shape and color." --- background-image: url(pgg_examples/chloe2.png) background-size: contain background-position: 50% 50% class: left, top, inverse ??? The next week, Chloé only plotted the averages but had some other ideas. My feedback was, "For this week, just stick with the point plot of average. Order the vegetables from largest to smallest average and make the points a different color but all the points should be the same color. Capitalize the first letter of the vegetable name using a str_XXX function." --- background-image: url(pgg_examples/chloe3.png) background-size: contain background-position: 50% 50% class: left, top, inverse ??? My feedback this week: "Yes! I’m liking how this is looking. Now put the weight in pounds or kilograms since they are pretty large numbers. Eliminate the horizontal grid lines using arguments in the theme() function. Instead of plotting the raw data with it, try coloring or sizing the points by the number of harvests of each vegetable - you can compute that in the summarize() you already have using the n() function." --- background-image: url(pgg_examples/chloe4.png) background-size: contain background-position: 50% 50% class: left, top, inverse ??? My feedback this week: "Great! If you want to just change the size of the point, use size in geom_point() and keep it outside of the aes(). I think harvest size is so big for tomatoes mainly due to having so many varieties. So, instead of using n() which finds the number of harvests but includes each variety separately, let’s find the number of days that each vegetable was harvested. Do that by replacing n() with n_distinct(date) and call that variable n_days or something like that. In the labs, give that variable a nice name." --- background-image: url(pgg_examples/chloe5.png) background-size: contain background-position: 50% 50% class: left, top, inverse ??? Here the graph is looking really great. My only feedback was, "Nice. Change the title of Harvest quantity to Days harvested and either leave out the size=1 or move it outside the aes()." --- background-image: url(pgg_examples/chloe_nance_perfect_garden.png) background-size: contain background-position: 50% 50% class: left, top, inverse ??? --- class: right, top # Katie Herrick ![](pgg_examples/katie_gif.gif) ??? --- class: left, top # Will Orser  ??? --- # Perfect Garden Graph recap * Small amounts of feedback at a time. * Students can work on details that they don't always have time for in other assignments. * They have fun! ??? I can give students small amounts of feedback at a time. Usually I try to focus on one big thing or 1-3 small things for them to work on each week. They get an opportunity to work on details that they don't always have time for in other assignments, like how the title should be aligned and which gridlines should be kept, if any. They have fun - I received a lot of positive feedback on my end of course surveys about this assignment. Students liked it and found it helpful. --- background-image: url(images/back_view_garden.jpg) background-size: cover background-position: 50% 50% class: left, top, inverse # Thank you! ??? Thank you!


| 1 | /* | |
| 2 | * Licensed to the Apache Software Foundation (ASF) under one or more | |
| 3 | * contributor license agreements. See the NOTICE file distributed with | |
| 4 | * this work for additional information regarding copyright ownership. | |
| 5 | * The ASF licenses this file to You under the Apache License, Version 2.0 | |
| 6 | * (the "License"); you may not use this file except in compliance with | |
| 7 | * the License. You may obtain a copy of the License at | |
| 8 | * | |
| 9 | * http://www.apache.org/licenses/LICENSE-2.0 | |
| 10 | * | |
| 11 | * Unless required by applicable law or agreed to in writing, software | |
| 12 | * distributed under the License is distributed on an "AS IS" BASIS, | |
| 13 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
| 14 | * See the License for the specific language governing permissions and | |
| 15 | * limitations under the License. | |
| 16 | */ | |
| 17 | package org.apache.commons.collections4.functors; | |
| 18 | ||
| 19 | import java.io.Serializable; | |
| 20 | ||
| 21 | import org.apache.commons.collections4.Closure; | |
| 22 | import org.apache.commons.collections4.FunctorException; | |
| 23 | ||
| 24 | /** | |
| 25 | * Closure implementation that always throws an exception. | |
| 26 | * | |
| 27 | * @since 3.0 | |
| 28 | * @version $Id: ExceptionClosure.java 1543950 2013-11-20 21:13:35Z tn $ | |
| 29 | */ | |
| 30 | public final class ExceptionClosure<E> implements Closure<E>, Serializable { | |
| 31 | ||
| 32 | /** Serial version UID */ | |
| 33 | private static final long serialVersionUID =<PHONE_NUMBER>121985545L; | |
| 34 | ||
| 35 | /** Singleton predicate instance */ | |
| 36 | @SuppressWarnings("rawtypes") // the static instance works for all types | |
| 37 | public static final Closure INSTANCE = new ExceptionClosure<Object>(); | |
| 38 | ||
| 39 | /** | |
| 40 | * Factory returning the singleton instance. | |
| 41 | * | |
| 42 | * @param <E> the type that the closure acts on | |
| 43 | * @return the singleton instance | |
| 44 | * @since 3.1 | |
| 45 | */ | |
| 46 | @SuppressWarnings("unchecked") // the static instance works for all types | |
| 47 | public static <E> Closure<E> exceptionClosure() { | |
| 48 |
1
1. exceptionClosure : mutated return of Object value for org/apache/commons/collections4/functors/ExceptionClosure::exceptionClosure to ( if (x != null) null else throw new RuntimeException ) → KILLED |
return (Closure<E>) INSTANCE; |
| 49 | } | |
| 50 | ||
| 51 | /** | |
| 52 | * Restricted constructor. | |
| 53 | */ | |
| 54 | private ExceptionClosure() { | |
| 55 | super(); | |
| 56 | } | |
| 57 | ||
| 58 | /** | |
| 59 | * Always throw an exception. | |
| 60 | * | |
| 61 | * @param input the input object | |
| 62 | * @throws FunctorException always | |
| 63 | */ | |
| 64 | public void execute(final E input) { | |
| 65 | throw new FunctorException("ExceptionClosure invoked"); | |
| 66 | } | |
| 67 | ||
| 68 | private Object readResolve() { | |
| 69 |
1
1. readResolve : mutated return of Object value for org/apache/commons/collections4/functors/ExceptionClosure::readResolve to ( if (x != null) null else throw new RuntimeException ) → KILLED |
return INSTANCE; |
| 70 | } | |
| 71 | ||
| 72 | } | |
Mutations | ||
| 48 |
1.1 |
|
| 69 |
1.1 |


|
Xenomai
3.0.4
|
The implementation of the memory allocator follows the algorithm described in a USENIX 1988 paper called "Design of a General Purpose Memory Allocator for the 4.3BSD Unix Kernel" by Marshall K. More...
Functions | |
| int | xnheap_init (struct xnheap *heap, void *membase, u32 size) |
| Initialize a memory heap. More... | |
| void | xnheap_set_name (struct xnheap *heap, const char *name,...) |
| Set the heap's name string. More... | |
| void | xnheap_destroy (struct xnheap *heap) |
| Destroys a memory heap. More... | |
| void * | xnheap_alloc (struct xnheap *heap, u32 size) |
| Allocate a memory block from a memory heap. More... | |
| void | xnheap_free (struct xnheap *heap, void *block) |
| Release a block to a memory heap. More... | |
The implementation of the memory allocator follows the algorithm described in a USENIX 1988 paper called "Design of a General Purpose Memory Allocator for the 4.3BSD Unix Kernel" by Marshall K.
McKusick and Michael J. Karels. You can find it at various locations on the net, including http://docs.FreeBSD.org/44doc/papers/kernmalloc.pdf.
| void * xnheap_alloc | ( | struct xnheap * | heap, |
| u32 | size | ||
| ) |
Allocate a memory block from a memory heap.
Allocates a contiguous region of memory from an active memory heap. Such allocation is guaranteed to be time-bounded.
| heap | The descriptor address of the heap to get memory from. |
| size | The size in bytes of the requested block. Sizes lower or equal to the page size are rounded either to the minimum allocation size if lower than this value, or to the minimum alignment size if greater or equal to this value. In the current implementation, with MINALLOC = 8 and MINALIGN = 16, a 7 bytes request will be rounded to 8 bytes, and a 17 bytes request will be rounded to 32. |
| void xnheap_destroy | ( | struct xnheap * | heap | ) |
Destroys a memory heap.
Destroys a memory heap.
| heap | The heap descriptor. |
| void xnheap_free | ( | struct xnheap * | heap, |
| void * | block | ||
| ) |
Release a block to a memory heap.
Releases a memory block to a heap.
| heap | The heap descriptor. |
| block | The block to be returned to the heap. |
| int xnheap_init | ( | struct xnheap * | heap, |
| void * | membase, | ||
| u32 | size | ||
| ) |
Initialize a memory heap.
Initializes a memory heap suitable for time-bounded allocation requests of dynamic memory.
| heap | The address of a heap descriptor to initialize. |
| membase | The address of the storage area. |
| size | The size in bytes of the storage area. size must be a multiple of PAGE_SIZE and smaller than 2 Gb in the current implementation. |
| void xnheap_set_name | ( | struct xnheap * | heap, |
| const char * | name, | ||
| ... | |||
| ) |
Set the heap's name string.
Set the heap name that will be used in statistic outputs.
| heap | The address of a heap descriptor. |
| name | Name displayed in statistic outputs. This parameter can be a printk()-like format argument list. |


With a library of over 4,000 videos on everything from arithmetic to physics, finance, and history and hundreds of skills to practice, we're on a mission to help you learn what you want, when you want, at your own pace.
We are a donor-supported not-for-profit and would not be possible without the generous support of users everywhere. In particular, we'd like to thank The Bill and Melinda Gates Foundation, Ann & John Doerr, the O'Sullivan Foundation, Reed Hastings, Google, and the Windsong Trust for their strong support of our mission.


fcntl() performs one of the operations described below on the open file
descriptor fd. The operation is determined by cmd.
fcntl() can take an optional third argument. Whether or not
this argument is required is determined by cmd. The required argument
type is indicated in parentheses after each cmd name (in most cases,
the required type is int, and we identify the argument using the name
arg), or void is specified if the argument is not
required.
Certain of the operations below are supported only since a
particular Linux kernel version. The preferred method of checking whether
the host kernel supports a particular operation is to invoke fcntl()
with the desired cmd value and then test whether the call failed with
EINVAL, indicating that the kernel does not recognize this value.
- F_DUPFD (int)
- Duplicate the file descriptor fd using the lowest-numbered
available file descriptor greater than or equal to arg. This is
different from dup2(2), which uses exactly the file descriptor
specified.
- On success, the new file descriptor is returned.
- See dup(2) for further details.
- F_DUPFD_CLOEXEC (int; since Linux 2.6.24)
- As for F_DUPFD, but additionally set the close-on-exec flag for the
duplicate file descriptor. Specifying this flag permits a program to avoid
an additional fcntl() F_SETFD operation to set the
FD_CLOEXEC flag. For an explanation of why this flag is useful, see
the description of O_CLOEXEC in open(2).
The following commands manipulate the flags associated with a file descriptor.
Currently, only one such flag is defined: FD_CLOEXEC, the close-on-exec
flag. If the FD_CLOEXEC bit is set, the file descriptor will
automatically be closed during a successful execve(2). (If the
execve(2) fails, the file descriptor is left open.) If the
FD_CLOEXEC bit is not set, the file descriptor will remain open across
an execve(2).
- F_GETFD (void)
- Return (as the function result) the file descriptor flags; arg is
ignored.
- F_SETFD (int)
- Set the file descriptor flags to the value specified by arg.
In multithreaded programs, using fcntl() F_SETFD to
set the close-on-exec flag at the same time as another thread performs a
fork(2) plus execve(2) is vulnerable to a race condition that
may unintentionally leak the file descriptor to the program executed in the
child process. See the discussion of the O_CLOEXEC flag in
open(2) for details and a remedy to the problem.
Each open file description has certain associated status flags, initialized by
open(2) and possibly modified by fcntl(). Duplicated file
descriptors (made with dup(2), fcntl(F_DUPFD), fork(2),
etc.) refer to the same open file description, and thus share the same file
status flags.
The file status flags and their semantics are described in
open(2).
- F_GETFL (void)
- Return (as the function result) the file access mode and the file status
flags; arg is ignored.
- F_SETFL (int)
- Set the file status flags to the value specified by arg. File
access mode (O_RDONLY, O_WRONLY, O_RDWR) and file
creation flags (i.e., O_CREAT, O_EXCL, O_NOCTTY,
O_TRUNC) in arg are ignored. On Linux, this command can
change only the O_APPEND, O_ASYNC, O_DIRECT,
O_NOATIME, and O_NONBLOCK flags. It is not possible to
change the O_DSYNC and O_SYNC flags; see BUGS, below.
Linux implements traditional ("process-associated") UNIX record locks,
as standardized by POSIX. For a Linux-specific alternative with better
semantics, see the discussion of open file description locks below.
F_SETLK, F_SETLKW, and F_GETLK are used to
acquire, release, and test for the existence of record locks (also known as
byte-range, file-segment, or file-region locks). The third argument,
lock, is a pointer to a structure that has at least the following
fields (in unspecified order).
struct flock {
...
short l_type; /* Type of lock: F_RDLCK,
F_WRLCK, F_UNLCK */
short l_whence; /* How to interpret l_start:
SEEK_SET, SEEK_CUR, SEEK_END */
off_t l_start; /* Starting offset for lock */
off_t l_len; /* Number of bytes to lock */
pid_t l_pid; /* PID of process blocking our lock
(set by F_GETLK and F_OFD_GETLK) */
...
};
The l_whence, l_start, and l_len fields of
this structure specify the range of bytes we wish to lock. Bytes past the
end of the file may be locked, but not bytes before the start of the
file.
l_start is the starting offset for the lock, and is
interpreted relative to either: the start of the file (if l_whence is
SEEK_SET); the current file offset (if l_whence is
SEEK_CUR); or the end of the file (if l_whence is
SEEK_END). In the final two cases, l_start can be a negative
number provided the offset does not lie before the start of the file.
l_len specifies the number of bytes to be locked. If
l_len is positive, then the range to be locked covers bytes
l_start up to and including l_start+l_len-1. Specifying
0 for l_len has the special meaning: lock all bytes starting at the
location specified by l_whence and l_start through to the end
of file, no matter how large the file grows.
POSIX.1-2001 allows (but does not require) an implementation to
support a negative l_len value; if l_len is negative, the
interval described by lock covers bytes l_start+l_len
up to and including l_start-1. This is supported by Linux since
kernel versions 2.4.21 and 2.5.49.
The l_type field can be used to place a read
(F_RDLCK) or a write (F_WRLCK) lock on a file. Any number of
processes may hold a read lock (shared lock) on a file region, but only one
process may hold a write lock (exclusive lock). An exclusive lock excludes
all other locks, both shared and exclusive. A single process can hold only
one type of lock on a file region; if a new lock is applied to an
already-locked region, then the existing lock is converted to the new lock
type. (Such conversions may involve splitting, shrinking, or coalescing with
an existing lock if the byte range specified by the new lock does not
precisely coincide with the range of the existing lock.)
- F_SETLK (struct flock *)
- Acquire a lock (when l_type is F_RDLCK or F_WRLCK) or
release a lock (when l_type is F_UNLCK) on the bytes
specified by the l_whence, l_start, and l_len fields
of lock. If a conflicting lock is held by another process, this
call returns -1 and sets errno to EACCES or EAGAIN.
(The error returned in this case differs across implementations, so POSIX
requires a portable application to check for both errors.)
- F_SETLKW (struct flock *)
- As for F_SETLK, but if a conflicting lock is held on the file, then
wait for that lock to be released. If a signal is caught while waiting,
then the call is interrupted and (after the signal handler has returned)
returns immediately (with return value -1 and errno set to
EINTR; see signal(7)).
- F_GETLK (struct flock *)
- On input to this call, lock describes a lock we would like to place
on the file. If the lock could be placed, fcntl() does not actually
place it, but returns F_UNLCK in the l_type field of
lock and leaves the other fields of the structure unchanged.
- If one or more incompatible locks would prevent this lock being placed,
then fcntl() returns details about one of those locks in the
l_type, l_whence, l_start, and l_len fields of
lock. If the conflicting lock is a traditional (process-associated)
record lock, then the l_pid field is set to the PID of the process
holding that lock. If the conflicting lock is an open file description
lock, then l_pid is set to -1. Note that the returned information
may already be out of date by the time the caller inspects it.
In order to place a read lock, fd must be open for reading.
In order to place a write lock, fd must be open for writing. To place
both types of lock, open a file read-write.
When placing locks with F_SETLKW, the kernel detects
deadlocks, whereby two or more processes have their lock requests
mutually blocked by locks held by the other processes. For example, suppose
process A holds a write lock on byte 100 of a file, and process B holds a
write lock on byte 200. If each process then attempts to lock the byte
already locked by the other process using F_SETLKW, then, without
deadlock detection, both processes would remain blocked indefinitely. When
the kernel detects such deadlocks, it causes one of the blocking lock
requests to immediately fail with the error EDEADLK; an application
that encounters such an error should release some of its locks to allow
other applications to proceed before attempting regain the locks that it
requires. Circular deadlocks involving more than two processes are also
detected. Note, however, that there are limitations to the kernel's
deadlock-detection algorithm; see BUGS.
As well as being removed by an explicit F_UNLCK, record
locks are automatically released when the process terminates.
Record locks are not inherited by a child created via
fork(2), but are preserved across an execve(2).
Because of the buffering performed by the stdio(3) library,
the use of record locking with routines in that package should be avoided;
use read(2) and write(2) instead.
The record locks described above are associated with the process
(unlike the open file description locks described below). This has some
unfortunate consequences:
- If a process closes any file descriptor referring to a file, then
all of the process's locks on that file are released, regardless of the
file descriptor(s) on which the locks were obtained. This is bad: it means
that a process can lose its locks on a file such as /etc/passwd or
/etc/mtab when for some reason a library function decides to open,
read, and close the same file.
- The threads in a process share locks. In other words, a multithreaded
program can't use record locking to ensure that threads don't
simultaneously access the same region of a file.
Open file description locks solve both of these problems.
Open file description locks are advisory byte-range locks whose operation is in
most respects identical to the traditional record locks described above. This
lock type is Linux-specific, and available since Linux 3.15. (There is a
proposal with the Austin Group to include this lock type in the next revision
of POSIX.1.) For an explanation of open file descriptions, see open(2).
The principal difference between the two lock types is that
whereas traditional record locks are associated with a process, open file
description locks are associated with the open file description on which
they are acquired, much like locks acquired with flock(2).
Consequently (and unlike traditional advisory record locks), open file
description locks are inherited across fork(2) (and clone(2)
with CLONE_FILES), and are only automatically released on the last
close of the open file description, instead of being released on any close
of the file.
Conflicting lock combinations (i.e., a read lock and a write lock
or two write locks) where one lock is an open file description lock and the
other is a traditional record lock conflict even when they are acquired by
the same process on the same file descriptor.
Open file description locks placed via the same open file
description (i.e., via the same file descriptor, or via a duplicate of the
file descriptor created by fork(2), dup(2), fcntl()
F_DUPFD, and so on) are always compatible: if a new lock is placed on
an already locked region, then the existing lock is converted to the new
lock type. (Such conversions may result in splitting, shrinking, or
coalescing with an existing lock as discussed above.)
On the other hand, open file description locks may conflict with
each other when they are acquired via different open file descriptions.
Thus, the threads in a multithreaded program can use open file description
locks to synchronize access to a file region by having each thread perform
its own open(2) on the file and applying locks via the resulting file
descriptor.
As with traditional advisory locks, the third argument to
fcntl(), lock, is a pointer to an flock structure. By
contrast with traditional record locks, the l_pid field of that
structure must be set to zero when using the commands described below.
The commands for working with open file description locks are
analogous to those used with traditional locks:
- F_OFD_SETLK (struct flock *)
- Acquire an open file description lock (when l_type is
F_RDLCK or F_WRLCK) or release an open file description lock
(when l_type is F_UNLCK) on the bytes specified by the
l_whence, l_start, and l_len fields of lock.
If a conflicting lock is held by another process, this call returns -1 and
sets errno to EAGAIN.
- F_OFD_SETLKW (struct flock *)
- As for F_OFD_SETLK, but if a conflicting lock is held on the file,
then wait for that lock to be released. If a signal is caught while
waiting, then the call is interrupted and (after the signal handler has
returned) returns immediately (with return value -1 and errno set
to EINTR; see signal(7)).
- F_OFD_GETLK (struct flock *)
- On input to this call, lock describes an open file description lock
we would like to place on the file. If the lock could be placed,
fcntl() does not actually place it, but returns F_UNLCK in
the l_type field of lock and leaves the other fields of the
structure unchanged. If one or more incompatible locks would prevent this
lock being placed, then details about one of these locks are returned via
lock, as described above for F_GETLK.
In the current implementation, no deadlock detection is performed
for open file description locks. (This contrasts with process-associated
record locks, for which the kernel does perform deadlock detection.)
Warning: the Linux implementation of mandatory locking is unreliable. See
BUGS below. Because of these bugs, and the fact that the feature is believed
to be little used, since Linux 4.5, mandatory locking has been made an
optional feature, governed by a configuration option
(CONFIG_MANDATORY_FILE_LOCKING). This is an initial step toward
removing this feature completely.
By default, both traditional (process-associated) and open file
description record locks are advisory. Advisory locks are not enforced and
are useful only between cooperating processes.
Both lock types can also be mandatory. Mandatory locks are
enforced for all processes. If a process tries to perform an incompatible
access (e.g., read(2) or write(2)) on a file region that has
an incompatible mandatory lock, then the result depends upon whether the
O_NONBLOCK flag is enabled for its open file description. If the
O_NONBLOCK flag is not enabled, then the system call is blocked until
the lock is removed or converted to a mode that is compatible with the
access. If the O_NONBLOCK flag is enabled, then the system call fails
with the error EAGAIN.
To make use of mandatory locks, mandatory locking must be enabled
both on the filesystem that contains the file to be locked, and on the file
itself. Mandatory locking is enabled on a filesystem using the "-o
mand" option to mount(8), or the MS_MANDLOCK flag for
mount(2). Mandatory locking is enabled on a file by disabling group
execute permission on the file and enabling the set-group-ID permission bit
(see chmod(1) and chmod(2)).
Mandatory locking is not specified by POSIX. Some other systems
also support mandatory locking, although the details of how to enable it
vary across systems.
When an advisory lock is obtained on a networked filesystem such as NFS it is
possible that the lock might get lost. This may happen due to administrative
action on the server, or due to a network partition (i.e., loss of network
connectivity with the server) which lasts long enough for the server to assume
that the client is no longer functioning.
When the filesystem determines that a lock has been lost, future
read(2) or write(2) requests may fail with the error
EIO. This error will persist until the lock is removed or the file
descriptor is closed. Since Linux 3.12, this happens at least for NFSv4
(including all minor versions).
Some versions of UNIX send a signal (SIGLOST) in this
circumstance. Linux does not define this signal, and does not provide any
asynchronous notification of lost locks.
F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX,
F_GETSIG and F_SETSIG are used to manage I/O availability
signals:
- F_GETOWN (void)
- Return (as the function result) the process ID or process group currently
receiving SIGIO and SIGURG signals for events on file
descriptor fd. Process IDs are returned as positive values; process
group IDs are returned as negative values (but see BUGS below). arg
is ignored.
- F_SETOWN (int)
- Set the process ID or process group ID that will receive SIGIO and
SIGURG signals for events on the file descriptor fd. The
target process or process group ID is specified in arg. A process
ID is specified as a positive value; a process group ID is specified as a
negative value. Most commonly, the calling process specifies itself as the
owner (that is, arg is specified as getpid(2)).
- As well as setting the file descriptor owner, one must also enable
generation of signals on the file descriptor. This is done by using the
fcntl() F_SETFL command to set the O_ASYNC file
status flag on the file descriptor. Subsequently, a SIGIO signal is
sent whenever input or output becomes possible on the file descriptor. The
fcntl() F_SETSIG command can be used to obtain delivery of a
signal other than SIGIO.
- Sending a signal to the owner process (group) specified by F_SETOWN
is subject to the same permissions checks as are described for
kill(2), where the sending process is the one that employs
F_SETOWN (but see BUGS below). If this permission check fails, then
the signal is silently discarded. Note: The F_SETOWN
operation records the caller's credentials at the time of the
fcntl() call, and it is these saved credentials that are used for
the permission checks.
- If the file descriptor fd refers to a socket, F_SETOWN also
selects the recipient of SIGURG signals that are delivered when
out-of-band data arrives on that socket. (SIGURG is sent in any
situation where select(2) would report the socket as having an
"exceptional condition".)
- The following was true in 2.6.x kernels up to and including kernel
2.6.11:
- If a nonzero value is given to F_SETSIG in a multithreaded process
running with a threading library that supports thread groups (e.g., NPTL),
then a positive value given to F_SETOWN has a different meaning:
instead of being a process ID identifying a whole process, it is a thread
ID identifying a specific thread within a process. Consequently, it may be
necessary to pass F_SETOWN the result of gettid(2) instead
of getpid(2) to get sensible results when F_SETSIG is used.
(In current Linux threading implementations, a main thread's thread ID is
the same as its process ID. This means that a single-threaded program can
equally use gettid(2) or getpid(2) in this scenario.) Note,
however, that the statements in this paragraph do not apply to the
SIGURG signal generated for out-of-band data on a socket: this
signal is always sent to either a process or a process group, depending on
the value given to F_SETOWN.
- The above behavior was accidentally dropped in Linux 2.6.12, and won't be
restored. From Linux 2.6.32 onward, use F_SETOWN_EX to target
SIGIO and SIGURG signals at a particular thread.
- F_GETOWN_EX (struct f_owner_ex *) (since Linux 2.6.32)
- Return the current file descriptor owner settings as defined by a previous
F_SETOWN_EX operation. The information is returned in the structure
pointed to by arg, which has the following form:
-
struct f_owner_ex {
int type;
pid_t pid;
};
- The type field will have one of the values F_OWNER_TID,
F_OWNER_PID, or F_OWNER_PGRP. The pid field is a
positive integer representing a thread ID, process ID, or process group
ID. See F_SETOWN_EX for more details.
- F_SETOWN_EX (struct f_owner_ex *) (since Linux 2.6.32)
- This operation performs a similar task to F_SETOWN. It allows the
caller to direct I/O availability signals to a specific thread, process,
or process group. The caller specifies the target of signals via
arg, which is a pointer to a f_owner_ex structure. The
type field has one of the following values, which define how
pid is interpreted:
- F_OWNER_TID
- Send the signal to the thread whose thread ID (the value returned by a
call to clone(2) or gettid(2)) is specified in
pid.
- F_OWNER_PID
- Send the signal to the process whose ID is specified in pid.
- F_OWNER_PGRP
- Send the signal to the process group whose ID is specified in pid.
(Note that, unlike with F_SETOWN, a process group ID is specified
as a positive value here.)
- F_GETSIG (void)
- Return (as the function result) the signal sent when input or output
becomes possible. A value of zero means SIGIO is sent. Any other
value (including SIGIO) is the signal sent instead, and in this
case additional info is available to the signal handler if installed with
SA_SIGINFO. arg is ignored.
- F_SETSIG (int)
- Set the signal sent when input or output becomes possible to the value
given in arg. A value of zero means to send the default
SIGIO signal. Any other value (including SIGIO) is the
signal to send instead, and in this case additional info is available to
the signal handler if installed with SA_SIGINFO.
- By using F_SETSIG with a nonzero value, and setting
SA_SIGINFO for the signal handler (see sigaction(2)), extra
information about I/O events is passed to the handler in a
siginfo_t structure. If the si_code field indicates the
source is SI_SIGIO, the si_fd field gives the file
descriptor associated with the event. Otherwise, there is no indication
which file descriptors are pending, and you should use the usual
mechanisms (select(2), poll(2), read(2) with
O_NONBLOCK set etc.) to determine which file descriptors are
available for I/O.
- Note that the file descriptor provided in si_fd is the one that was
specified during the F_SETSIG operation. This can lead to an
unusual corner case. If the file descriptor is duplicated (dup(2)
or similar), and the original file descriptor is closed, then I/O events
will continue to be generated, but the si_fd field will contain the
number of the now closed file descriptor.
- By selecting a real time signal (value >= SIGRTMIN), multiple
I/O events may be queued using the same signal numbers. (Queuing is
dependent on available memory.) Extra information is available if
SA_SIGINFO is set for the signal handler, as above.
- Note that Linux imposes a limit on the number of real-time signals that
may be queued to a process (see getrlimit(2) and signal(7))
and if this limit is reached, then the kernel reverts to delivering
SIGIO, and this signal is delivered to the entire process rather
than to a specific thread.
Using these mechanisms, a program can implement fully asynchronous
I/O without using select(2) or poll(2) most of the time.
The use of O_ASYNC is specific to BSD and Linux. The only
use of F_GETOWN and F_SETOWN specified in POSIX.1 is in
conjunction with the use of the SIGURG signal on sockets. (POSIX does
not specify the SIGIO signal.) F_GETOWN_EX,
F_SETOWN_EX, F_GETSIG, and F_SETSIG are Linux-specific.
POSIX has asynchronous I/O and the aio_sigevent structure to achieve
similar things; these are also available in Linux as part of the GNU C
Library (Glibc).
F_SETLEASE and F_GETLEASE (Linux 2.4 onward) are used to establish
a new lease, and retrieve the current lease, on the open file description
referred to by the file descriptor fd. A file lease provides a
mechanism whereby the process holding the lease (the "lease holder")
is notified (via delivery of a signal) when a process (the "lease
breaker") tries to open(2) or truncate(2) the file referred
to by that file descriptor.
- F_SETLEASE (int)
- Set or remove a file lease according to which of the following values is
specified in the integer arg:
- F_RDLCK
- Take out a read lease. This will cause the calling process to be notified
when the file is opened for writing or is truncated. A read lease can be
placed only on a file descriptor that is opened read-only.
- F_WRLCK
- Take out a write lease. This will cause the caller to be notified when the
file is opened for reading or writing or is truncated. A write lease may
be placed on a file only if there are no other open file descriptors for
the file.
- F_UNLCK
- Remove our lease from the file.
Leases are associated with an open file description (see
open(2)). This means that duplicate file descriptors (created by, for
example, fork(2) or dup(2)) refer to the same lease, and this
lease may be modified or released using any of these descriptors.
Furthermore, the lease is released by either an explicit F_UNLCK
operation on any of these duplicate file descriptors, or when all such file
descriptors have been closed.
Leases may be taken out only on regular files. An unprivileged
process may take out a lease only on a file whose UID (owner) matches the
filesystem UID of the process. A process with the CAP_LEASE
capability may take out leases on arbitrary files.
- F_GETLEASE (void)
- Indicates what type of lease is associated with the file descriptor
fd by returning either F_RDLCK, F_WRLCK, or
F_UNLCK, indicating, respectively, a read lease , a write lease, or
no lease. arg is ignored.
When a process (the "lease breaker") performs an
open(2) or truncate(2) that conflicts with a lease established
via F_SETLEASE, the system call is blocked by the kernel and the
kernel notifies the lease holder by sending it a signal (SIGIO by
default). The lease holder should respond to receipt of this signal by doing
whatever cleanup is required in preparation for the file to be accessed by
another process (e.g., flushing cached buffers) and then either remove or
downgrade its lease. A lease is removed by performing an F_SETLEASE
command specifying arg as F_UNLCK. If the lease holder
currently holds a write lease on the file, and the lease breaker is opening
the file for reading, then it is sufficient for the lease holder to
downgrade the lease to a read lease. This is done by performing an
F_SETLEASE command specifying arg as F_RDLCK.
If the lease holder fails to downgrade or remove the lease within
the number of seconds specified in /proc/sys/fs/lease-break-time,
then the kernel forcibly removes or downgrades the lease holder's lease.
Once a lease break has been initiated, F_GETLEASE returns
the target lease type (either F_RDLCK or F_UNLCK, depending on
what would be compatible with the lease breaker) until the lease holder
voluntarily downgrades or removes the lease or the kernel forcibly does so
after the lease break timer expires.
Once the lease has been voluntarily or forcibly removed or
downgraded, and assuming the lease breaker has not unblocked its system
call, the kernel permits the lease breaker's system call to proceed.
If the lease breaker's blocked open(2) or
truncate(2) is interrupted by a signal handler, then the system call
fails with the error EINTR, but the other steps still occur as
described above. If the lease breaker is killed by a signal while blocked in
open(2) or truncate(2), then the other steps still occur as
described above. If the lease breaker specifies the O_NONBLOCK flag
when calling open(2), then the call immediately fails with the error
EWOULDBLOCK, but the other steps still occur as described above.
The default signal used to notify the lease holder is
SIGIO, but this can be changed using the F_SETSIG command to
fcntl(). If a F_SETSIG command is performed (even one
specifying SIGIO), and the signal handler is established using
SA_SIGINFO, then the handler will receive a siginfo_t
structure as its second argument, and the si_fd field of this
argument will hold the file descriptor of the leased file that has been
accessed by another process. (This is useful if the caller holds leases
against multiple files.)
- F_NOTIFY (int)
- (Linux 2.4 onward) Provide notification when the directory referred to by
fd or any of the files that it contains is changed. The events to
be notified are specified in arg, which is a bit mask specified by
ORing together zero or more of the following bits:
- DN_ACCESS
- A file was accessed (read(2), pread(2), readv(2), and
similar)
- DN_MODIFY
- A file was modified (write(2), pwrite(2), writev(2),
truncate(2), ftruncate(2), and similar).
- DN_CREATE
- A file was created (open(2), creat(2), mknod(2),
mkdir(2), link(2), symlink(2), rename(2) into
this directory).
- DN_DELETE
- A file was unlinked (unlink(2), rename(2) to another
directory, rmdir(2)).
- DN_RENAME
- A file was renamed within this directory (rename(2)).
- DN_ATTRIB
- The attributes of a file were changed (chown(2), chmod(2),
utime(2), utimensat(2), and similar).
- (In order to obtain these definitions, the _GNU_SOURCE feature test
macro must be defined before including any header files.)
- Directory notifications are normally "one-shot", and the
application must reregister to receive further notifications.
Alternatively, if DN_MULTISHOT is included in arg, then
notification will remain in effect until explicitly removed.
- A series of F_NOTIFY requests is cumulative, with the events in
arg being added to the set already monitored. To disable
notification of all events, make an F_NOTIFY call specifying
arg as 0.
- Notification occurs via delivery of a signal. The default signal is
SIGIO, but this can be changed using the F_SETSIG command to
fcntl(). (Note that SIGIO is one of the nonqueuing standard
signals; switching to the use of a real-time signal means that multiple
notifications can be queued to the process.) In the latter case, the
signal handler receives a siginfo_t structure as its second
argument (if the handler was established using SA_SIGINFO) and the
si_fd field of this structure contains the file descriptor which
generated the notification (useful when establishing notification on
multiple directories).
- Especially when using DN_MULTISHOT, a real time signal should be
used for notification, so that multiple notifications can be queued.
- NOTE: New applications should use the inotify interface
(available since kernel 2.6.13), which provides a much superior interface
for obtaining notifications of filesystem events. See
inotify(7).
- F_SETPIPE_SZ (int; since Linux 2.6.35)
- Change the capacity of the pipe referred to by fd to be at least
arg bytes. An unprivileged process can adjust the pipe capacity to
any value between the system page size and the limit defined in
/proc/sys/fs/pipe-max-size (see proc(5)). Attempts to set
the pipe capacity below the page size are silently rounded up to the page
size. Attempts by an unprivileged process to set the pipe capacity above
the limit in /proc/sys/fs/pipe-max-size yield the error
EPERM; a privileged process (CAP_SYS_RESOURCE) can override
the limit.
- When allocating the buffer for the pipe, the kernel may use a capacity
larger than arg, if that is convenient for the implementation. (In
the current implementation, the allocation is the next higher power-of-two
page-size multiple of the requested size.) The actual capacity (in bytes)
that is set is returned as the function result.
- Attempting to set the pipe capacity smaller than the amount of buffer
space currently used to store data produces the error EBUSY.
- Note that because of the way the pages of the pipe buffer are employed
when data is written to the pipe, the number of bytes that can be written
may be less than the nominal size, depending on the size of the
writes.
- F_GETPIPE_SZ (void; since Linux 2.6.35)
- Return (as the function result) the capacity of the pipe referred to by
fd.
File seals limit the set of allowed operations on a given file. For each seal
that is set on a file, a specific set of operations will fail with
EPERM on this file from now on. The file is said to be sealed. The
default set of seals depends on the type of the underlying file and
filesystem. For an overview of file sealing, a discussion of its purpose, and
some code examples, see memfd_create(2).
Currently, file seals can be applied only to a file descriptor
returned by memfd_create(2) (if the MFD_ALLOW_SEALING was
employed). On other filesystems, all fcntl() operations that operate
on seals will return EINVAL.
Seals are a property of an inode. Thus, all open file descriptors
referring to the same inode share the same set of seals. Furthermore, seals
can never be removed, only added.
- F_ADD_SEALS (int; since Linux 3.17)
- Add the seals given in the bit-mask argument arg to the set of
seals of the inode referred to by the file descriptor fd. Seals
cannot be removed again. Once this call succeeds, the seals are enforced
by the kernel immediately. If the current set of seals includes
F_SEAL_SEAL (see below), then this call will be rejected with
EPERM. Adding a seal that is already set is a no-op, in case
F_SEAL_SEAL is not set already. In order to place a seal, the file
descriptor fd must be writable.
- F_GET_SEALS (void; since Linux 3.17)
- Return (as the function result) the current set of seals of the inode
referred to by fd. If no seals are set, 0 is returned. If the file
does not support sealing, -1 is returned and errno is set to
EINVAL.
The following seals are available:
- F_SEAL_SEAL
- If this seal is set, any further call to fcntl() with
F_ADD_SEALS fails with the error EPERM. Therefore, this seal
prevents any modifications to the set of seals itself. If the initial set
of seals of a file includes F_SEAL_SEAL, then this effectively
causes the set of seals to be constant and locked.
- F_SEAL_SHRINK
- If this seal is set, the file in question cannot be reduced in size. This
affects open(2) with the O_TRUNC flag as well as
truncate(2) and ftruncate(2). Those calls fail with
EPERM if you try to shrink the file in question. Increasing the
file size is still possible.
- F_SEAL_GROW
- If this seal is set, the size of the file in question cannot be increased.
This affects write(2) beyond the end of the file,
truncate(2), ftruncate(2), and fallocate(2). These
calls fail with EPERM if you use them to increase the file size. If
you keep the size or shrink it, those calls still work as expected.
- F_SEAL_WRITE
- If this seal is set, you cannot modify the contents of the file. Note that
shrinking or growing the size of the file is still possible and allowed.
Thus, this seal is normally used in combination with one of the other
seals. This seal affects write(2) and fallocate(2) (only in
combination with the FALLOC_FL_PUNCH_HOLE flag). Those calls fail
with EPERM if this seal is set. Furthermore, trying to create new
shared, writable memory-mappings via mmap(2) will also fail with
EPERM.
- Using the F_ADD_SEALS operation to set the F_SEAL_WRITE seal
fails with EBUSY if any writable, shared mapping exists. Such
mappings must be unmapped before you can add this seal. Furthermore, if
there are any asynchronous I/O operations (io_submit(2)) pending on
the file, all outstanding writes will be discarded.
- F_SEAL_FUTURE_WRITE (since Linux 5.1)
- The effect of this seal is similar to F_SEAL_WRITE, but the
contents of the file can still be modified via shared writable mappings
that were created prior to the seal being set. Any attempt to create a new
writable mapping on the file via mmap(2) will fail with
EPERM. Likewise, an attempt to write to the file via
write(2) will fail with EPERM.
- Using this seal, one process can create a memory buffer that it can
continue to modify while sharing that buffer on a "read-only"
basis with other processes.
Write lifetime hints can be used to inform the kernel about the relative
expected lifetime of writes on a given inode or via a particular open file
description. (See open(2) for an explanation of open file
descriptions.) In this context, the term "write lifetime" means the
expected time the data will live on media, before being overwritten or erased.
An application may use the different hint values specified below
to separate writes into different write classes, so that multiple users or
applications running on a single storage back-end can aggregate their I/O
patterns in a consistent manner. However, there are no functional semantics
implied by these flags, and different I/O classes can use the write lifetime
hints in arbitrary ways, so long as the hints are used consistently.
The following operations can be applied to the file descriptor,
fd:
- F_GET_RW_HINT (uint64_t *; since Linux 4.13)
- Returns the value of the read/write hint associated with the underlying
inode referred to by fd.
- F_SET_RW_HINT (uint64_t *; since Linux 4.13)
- Sets the read/write hint value associated with the underlying inode
referred to by fd. This hint persists until either it is explicitly
modified or the underlying filesystem is unmounted.
- F_GET_FILE_RW_HINT (uint64_t *; since Linux 4.13)
- Returns the value of the read/write hint associated with the open file
description referred to by fd.
- F_SET_FILE_RW_HINT (uint64_t *; since Linux 4.13)
- Sets the read/write hint value associated with the open file description
referred to by fd.
If an open file description has not been assigned a read/write
hint, then it shall use the value assigned to the inode, if any.
The following read/write hints are valid since Linux 4.13:
- RWH_WRITE_LIFE_NOT_SET
- No specific hint has been set. This is the default value.
- RWH_WRITE_LIFE_NONE
- No specific write lifetime is associated with this file or inode.
- RWH_WRITE_LIFE_SHORT
- Data written to this inode or via this open file description is expected
to have a short lifetime.
- RWH_WRITE_LIFE_MEDIUM
- Data written to this inode or via this open file description is expected
to have a lifetime longer than data written with
RWH_WRITE_LIFE_SHORT.
- RWH_WRITE_LIFE_LONG
- Data written to this inode or via this open file description is expected
to have a lifetime longer than data written with
RWH_WRITE_LIFE_MEDIUM.
- RWH_WRITE_LIFE_EXTREME
- Data written to this inode or via this open file description is expected
to have a lifetime longer than data written with
RWH_WRITE_LIFE_LONG.
All the write-specific hints are relative to each other, and no
individual absolute meaning should be attributed to them.


Feel free to submit a location of chronic violators of poop bag etiquette to poopfairyinoregon@gmail.com.


Created by Jeremy Prevost / @jerrocks
I work at Northwestern University's Galter Health Sciences Library.
I don't thinks ours sucks more than most, but a lot of it is not actually used.
That's the percent of our core space (non-header/footer) that results in less than 1% of our front page clicks.
To be fair, the top half of the right column (16.67% of the width) contains no links. But still! 83% results in 1% of clicks.
That's the percent of our clicks that come from 16% of our horizontal space.
Or about 16% of our core space generates 87% of our clicks.
All Popular Links: 58% of clicks
Of that...
I can see two obvious take aways...
The link to PubMed should take up 25% of our core space.
Or, the link to PubMed should be even smaller so people click on other stuff.
While numbers don't lie, the do only tell you one story.
The library news promos, that take up 67% of the core space but were clicked than 1% of the time need to go away. Maybe one row and then rely on the list for more news. (although just a link to News in the Top Nav might be even more appropriate.
What links are NOT on our front page that users actually would love to click if only they were there.


Operations
Delegate power
Transfer
Delegate Power
Delegate From:
Active SP:
Delegated SP:
Delegate To:
Active:
Received:
Scorum Power:
SP
Delegate ScorumPower
Private Key
DELEGATE
Transaction


{% extends "home/base.html" %} {% load static %} {% load humanize %} {% block content %}
The main article A community Biased signaling Atlas
has been publisehd on Nature Chemical Biology.
We invite you all to read the article to have a deeper insight of this new resource.
Biased Signaling Atlas
Biased signaling entails hormones, probes, or drugs binding the same GPCR but engaging different intracellular
signaling pathways leading to distinct functional outcomes. This may let drugs favor therapeutic over adverse signal pathways.
Photo: MRC Laboratory of Molecular Biology in Cambridge
#} {#The GPCRdb is developed by the Gloriam group.#} {# It integrates data from the large GPCR community and maintains an active collaboration with the#} {# Guide To Pharmacology (IUPHAR), GPCRmd and the European Research Network on Signal#} {# Transduction (ERNEST).#} {# If you use the GPCRdb, please remember to cite us.#} {#
#} {# #} {#


|
BuildmLearn Store
<IP_ADDRESS>
An android app, which is a store for apps built using BuildmLearn ToolKit
|
Helper class which creates the Tabs strips for the Home Page for Tab View. More...
Inherits LinearLayout.
Classes | |
| class | SimpleTabColorizer |
| Class which adds color to the tabs and its indicators. More... | |
Protected Member Functions | |
| void | onDraw (Canvas canvas) |
| This method is executed when the Object is drawn. More... | |
Package Functions | |
| SlidingTabStrip (Context context) | |
| Constructor of the Helper class. More... | |
| void | setCustomTabColorizer (SlidingTabLayout.TabColorizer customTabColorizer) |
| Sets colors to the tabs. More... | |
| void | setSelectedIndicatorColors (int...colors) |
| Set the Color to the active Tab. More... | |
| void | onViewPagerPageChanged (int position, float positionOffset) |
| This method is activated, when the tabs are changed. More... | |
Static Private Member Functions | |
| static int | setColorAlpha (int color) |
| Set the alpha value of the. More... | |
| static int | blendColors (int color1, int color2, float ratio) |
| Blend. More... | |
Private Attributes | |
| final int | mBottomBorderThickness |
| final Paint | mBottomBorderPaint |
| final int | mSelectedIndicatorThickness |
| final Paint | mSelectedIndicatorPaint |
| int | mSelectedPosition |
| float | mSelectionOffset |
| SlidingTabLayout.TabColorizer | mCustomTabColorizer |
| final SimpleTabColorizer | mDefaultTabColorizer |
Static Private Attributes | |
| static final int | DEFAULT_BOTTOM_BORDER_THICKNESS_DIPS = 0 |
| static final byte | DEFAULT_BOTTOM_BORDER_COLOR_ALPHA = 0x26 |
| static final int | SELECTED_INDICATOR_THICKNESS_DIPS = 3 |
| static final int | DEFAULT_SELECTED_INDICATOR_COLOR = 0xFF33B5E5 |
Helper class which creates the Tabs strips for the Home Page for Tab View.
|
package |
Constructor of the Helper class.
| context | Context object of the Helper Class |
|
staticprivate |
Blend.
and
using the given ratio.
| ratio | of which to blend. 1.0 will return color1
color2
|
|
protected |
This method is executed when the Object is drawn.
| canvas | Canvas Object |
|
package |
This method is activated, when the tabs are changed.
| position | Index of the current Page in the View Pager. |
| positionOffset | Offset in float |
|
staticprivate |
Set the alpha value of the.
to be the given
value.
|
package |
Sets colors to the tabs.
| customTabColorizer | TabColorizer object |
|
package |
Set the Color to the active Tab.
| colors | Color array |
|
staticprivate |
|
staticprivate |
|
staticprivate |
|
private |
|
private |
|
private |
|
private |
|
private |
|
private |
|
private |
|
private |
|
staticprivate |


@(launchUrl: String, assignment: Assignment, problems: List[models.Problem], preFix: String)
If you are done adding problems, please click on Done! button otherwise click on Edit! button


6.8 The packmail Module
(Obsolete) The packmail module contains tools to create Unix shell
archives. If you have the right tools installed (if you have
a Unix box, they are installed), you can unpack such an archive simply
by executing it. Example 6-10 shows how to pack a single file using packmail, while Example 6-11 shows how the module can pack an entire directory tree.
Example 6-10. Using the packmail Module to Pack a Single File
File: packmail-example-1.py
import packmail
import sys
packmail.pack(sys.stdout, "samples/sample.txt", "sample.txt")
echo sample.txt
sed "s/^X//" >sample.txt <<"!"
XWe will perhaps eventually be writing only small
Xmodules, which are identified by name as they are
Xused to build larger ones, so that devices like
Xindentation, rather than delimiters, might become
Xfeasible for expressing local structure in the
Xsource language.
X -- Donald E. Knuth, December 1974
!
Example 6-11. Using the packmail Module to Pack an Entire Directory Tree
File: packmail-example-2.py
import packmail
import sys
packmail.packtree(sys.stdout, "samples")
Note that this module cannot handle binary files, such as sound snippets and images.
|


Micah 1:10
Declare ye it not at Gath, weep ye not at all: in the house of Aphrah roll thyself in the dust.


Before I started Uni, I was familiar with the standard procedural paradigm of programming - you give a subroutine some values, tell it what to do, and some stuff happens. But a few months in to my first year I was introduced to the idea of _functional _programming - the example being Haskell. My lecturer at the time was a massive fan of the Haskell, hailing it as a potentially superior base for an operating system, or other large projects like that - but revealing that its relative lack of popularity on the main scene has kept it back.
The main point laboured was how precise these languages are. Given a constant set of inputs, the same conditions will always occur, and the same answers will always be the result. They’re the closest thing to mathematical formulation in a programming language I’ll find, they said.
The main thing I noticed was how little code was actually on the page, thinking “is that it?” when I saw that a program that could probably launch a rocket to the moon took up around 4 lines. Thinking of the impending programming assignments I was rubbing my hands together at the prospect of tapping out a few words and calling it a day as this magic language sorted it all out for you, but the reality was pretty different. We were given a choice between Haskell and Java for our final assignment, and I wussed out and took the Java option. But there were robots in that one, so nyeah.
Haskell is a strange language. Based around its ‘lazy semantics’ (i.e. it only calls what it has to), it’s a lot different from the others I’d seen, but can appreciate why its taught. It’s immensely powerful, very lenient in terms of data handling (no buggering about with pointers et cetera), and almost seems to intuitively know what you’re on about when you hand it values and instructions. It really is like maths. But, like maths, there’s little deviation in how you can actually achieve a task. With procedural/OO languages, you can hack at a problem from pretty much any direction and get a round-about answer. With Haskell you can sit for hours until you come up with two lines that solve the entire problem - it’s frustrating work, which is why it pays to sit and think it through before you sprint in.
For comparison, below is a version of the upper-bounded Sieve of Eratosthenes algorithm I wrote in Java (topical, since I was working on a number program recently):
 String getprimes(String args) { int prinum = Integer.parseInt(args), amount=0, i=0, j=0, k=0, l=0; double[] primes = new double[prinum];
if (prinum == 1 || prinum == 0) return "N/A. Number given is " + prinum + ".";
StringBuffer pri = new StringBuffer();
String primecheck = "No.", prodprim = "";
// Check if 1 is found, this is a dodgy answer, since it is not prime
// (arguably), and contains no primes
if (args == "1")
{
pri.append("N/A");
String prilist = pri.toString();
return prilist;
}
boolean[] PrimeMarker = new boolean[prinum+1];
for(i=2;i<=prinum;i++) PrimeMarker[i] = true;
// Mark non-primes in true Eratosthenes fashion.
for(i=2;i*i<=prinum;i++)
{
if (PrimeMarker[i] == true)
{
for (j=i;i*j<=prinum;j++) PrimeMarker[i*j] = false;
}
}
for(i=2;i<=prinum;i++)
{
if (PrimeMarker[i] == true)
{
pri.append(i);
pri.append(", ");
amount++;
primes[l] = (double) i;
l++;
}
}
pri.delete(pri.length()-2,pri.length());
String prilist = pri.toString();
return prilist; }

 I think we can agree that it’s not exactly light on its feet. Now, let’s compare that with a similar tiny method in Haskell (a guarded Turner sieve [1]):
getprimes m = 2 : sieve [3,5..m] where sieve (p:xs) | p*p > m = p : xs | True = p : sieve [x | x<-xs, rem x p /= 0]
 When running the programs, the Java algorithm stalls and belches all the numbers out in one big lump, whereas the Haskell one reels them off one by one. I can’t tell which is quicker by eye, there’s no discernible difference. But for me, as a beginner to functional languages, the Java version is considerably easier to read and debug, despite its size. The Haskell version is easy to follow, but not easy to understand exactly why or how things work as they do, especially coming from more verbose languages such as Java.
It’s probably worth sticking at, since these languages may well rise up in the future. But looking at people who have made 3D first-person shooters and the like using them, well, hats off to them, I haven’t the first idea!
References: [1] [http://en.literateprograms.org/Sieve_of_Eratosthenes(Haskell)](http://en.literateprograms.org/Sieve_of_Eratosthenes(Haskell))


You:
I've only ever experienced sexism outside of my own home ironically. Being a twin was always an awkward task because we got different chores and responsibilities mostly because of our gender. Therefore whereas I was able to go out at times, my sister wasn't because "she is a girl" and "anything can happen to her". I think it was all out of good intention but bad approach.
CoolPenguin123:
I do not consider benevolent sexism a good thing, for despite the positive feelings it may indicate for the perceiver, its underpinnings lie in traditional stereotyping and masculine dominance (e.g., the man as the provider and woman as his dependent), and its consequences are often damaging. Benevolent sexism is not necessarily experienced as benevolent by the recipient. For example, a man’s comment to a female coworker on how ‘cute’ she looks, however well-intentioned, may undermine her feelings of being taken seriously as a professional .
Add as a friend!


|
Laser game V2B1
|
This class is used to control the state of the game when running. More...
#include <run_game.hpp>
Public Member Functions | |
| Rungame (send_controller &send_channel, GameRules &game_par, Beeper &p_beeper, DisplayController &p_display, score &scores, TransferHits &transferHitCtrl) | |
| Construct a new Rungame object. More... | |
| void | write (uint16_t msg) override |
| writes the msg into the message chhannel More... | |
| void | buttonPressed () override |
| sets the button_pressed_flag when button is pressed More... | |
This class is used to control the state of the game when running.
Definition at line 31 of file run_game.hpp.
|
inline |
Construct a new Rungame object.
| send_channel | The channel of the IR sender |
| game_par | The game parameters |
| p_beeper | |
| p_display | |
| scores | The class which stores the score of players who have shot you |
| transferHitCtrl | The class which sends the score via usb to the host pc |
Definition at line 76 of file run_game.hpp.
|
inlineoverridevirtual |
sets the button_pressed_flag when button is pressed
Implements Buttonlistener.
Definition at line 109 of file run_game.hpp.
|
inlineoverridevirtual |
writes the msg into the message chhannel
| msg | the 16 bit message you want to write to the channel |
Implements MsgListener.
Definition at line 101 of file run_game.hpp.


#include <xrpcP.h>
Data Fields | |
| int | port |
| char | path [SZ_PATH] |
| char | url [SZ_PATH] |
| char | config [SZ_PATH] |
| char | logfile [SZ_PATH] |
| Method * | method_head |
| Method * | method_tail |
| int | num_methods |
| Caller | caller |
| pthread_attr_t | attr |
| pthread_t | thread |
| xmlrpc_default_method | defMethod |
| xmlrpc_server_abyss_parms | serverparm |
| xmlrpc_registry * | registry |
| xmlrpc_env | env |
| int | trace |
| pthread_attr_t Server::attr |
method calling struct
number of methods
| char Server::config[SZ_PATH] |
full server URL
| xmlrpc_default_method Server::defMethod |
server thread
| char Server::logfile[SZ_PATH] |
server config file
server log file
server method list
server method tail
| char Server::path[SZ_PATH] |
server port numnber
| xmlrpc_server_abyss_parms Server::serverparm |
dispatcher method
| pthread_t Server::thread |
server thread attribute
| char Server::url[SZ_PATH] |
path e.g. "/RPC2"


My name is Eleonora, I'm 17 and I'm a Student at a scientific high school in Turin (Italy). I still need time to get to know myself and the person I want to become but somewhere I should start :)
Lets get in touch and talk about your next project.
w3c css styles has been used to build this site. Go check it out


AOT: Appearance Optimal Transport Based Identity Swapping for Forgery Detection NeurIPS 2020
Abstract
Recent studies have shown that the performance of forgery detection can be improved with diverse and challenging Deepfakes datasets. However, due to the lack of Deepfakes datasets with large variance in appearance, which can be hardly produced by recent identity swapping methods, the detection algorithm may fail in this situation. In this work, we provide a new identity swapping algorithm with large differences in appearance for face forgery detection. The appearance gaps mainly arise from the large discrepancies in illuminations and skin colors that widely exist in real-world scenarios. However, due to the difficulties of modeling the complex appearance mapping, it is challenging to transfer fine-grained appearances adaptively while preserving identity traits. This paper formulates appearance mapping as an optimal transport problem and proposes an Appearance Optimal Transport model (AOT) to formulate it in both latent and pixel space. Specifically, a relighting generator is designed to simulate the optimal transport plan. It is solved via minimizing the Wasserstein distance of the learned features in the latent space, enabling better performance and less computation than conventional optimization. To further refine the solution of the optimal transport plan, we develop a segmentation game to minimize the Wasserstein distance in the pixel space. A discriminator is introduced to distinguish the fake parts from a mix of real and fake image patches. Extensive experiments reveal that the superiority of our method when compared with state-of-the-art methods and the ability of our generated data to improve the performance of face forgery detection.
Pipeline
Manipulated Dataset
The following datasets and the checkpoints of detectors can be downloaded from the BaiduYun (code: dzgc).
We currently provide 100 manipulated videos of FF++ by refining the results of DeepFaceLab and DeeperForensics-1.0, respectively. The more manipulated videos are coming soon.
Face Forgery Detection
Binary detection accuracy of two video classification baselines: I3D and TSN on the hidden set provided by DeeperForensics-1.0.
- We trained the baselines on four manipulated datasets of FF++ produced by DeepFakes, Face2Face, FaceSwap, and NeuralTextures (Green bars).
- Then, we add 100 manipulated videos produced by our method to the training set. All detection accuracies are improved with the addition of our data. (Blue bars).
In order to pass this information through the NeRF network, we fit a multivariate Gaussian to the conical frustum and use the integrated positional encoding described above to create the input feature vector to the network.
Citation
Acknowledgements
ANY RESOUCES PROVIDED HERE ARE NOT TO BE USED FOR MALICIOUS OR INAPPROPRIATE USE CASES.


Numeric Text fields typically reside in forms but can appear in other places, like dialog boxes and search.
disabled


Topics in Differential Geometry
Office: Shan 3420
Email<EMAIL_ADDRESS>Office Phone:<PHONE_NUMBER>
Fax:<PHONE_NUMBER>
Office Hours: Tuesday 3:00pm - 4:00pm or by appointment
Course Meeting:
Monday, 2:45pm - 4:00pm
Wednesday, 2:45pm - 4:00pm
Course Location:
Harvey Mudd College Shan 2460
Graders/Tutoring Hours:
● Paul David<EMAIL_ADDRESS>● Maggie Li<EMAIL_ADDRESS>Tutoring Hours: (Optional)
Monday: 7:00pm - 8:30pm (Location TBD)
Textbook:
All members of the class will be required to obtain the
following texts:
● Information Geometry and its Applications by Shun-ichi Amari
● Riemannian Geometry by Do Carmo
Grading:
● 30% Homework
● 30% Midterm Project
● 40% Final Project
Course Requirements and Evaluation:
● Homework
Homework will be assigned once a week and will be due every Monday
before the lecture. Discussions and collaboration is encouraged.
Solution hints also will be provided if necessary. But you must
write up your own solution. Before tackling any problems, read
the relevant section of the text and review your lecture notes.
Consult with the faculty, the tutor (Paul David) or your
classmates about matters that are unclear to you.
NEVER LET YOURSELF FALL BEHIND.
Note:
I am trying my best to help you succeed in this course.
Trust me, I am on your side. However, you must try your best.
This is a very advanced and challenge course. It will greatly
benefit you for your future graduate study or industry work.
Though it is very hard at the beginning since there are many
very high level new concepts, you will finally get used to
them. By the time you are in your graduate school or your
work, you will certainly be at the top of the "mountain"
as a student or an employee with your talent ought to be.
So let us work really hard now!
● Midterm/Final Projects
The midterm and final projects are the largest components of the course.
Each student will discover, explore, and attack a real world
problem of your choosing. The detailed description and requirements
for the midterm and final projects can be found under the
"Mid/Final Project" tab.
● GitHub
Students are expected to
become comfortable with Github. Hence, each student is required
to create a Github account for midterm and
final project submission. If you already have a Github account,
that's perfect. If not, please create a personal Github account
and go over the tutorials online.
Classroom Policies:
● Attendence
Attendence for each lecture is mandatory and is expected of all
class members. if you're going to miss a lecture, it is neccessary
for you to inform the instructor as soon as possible. You are also
responsible for obtaining notes from another class member.
● Devices
You are welcome to use your computer or tablet for note-taking
(the PowerPoint slides will also be posted shortly after the
lecture for your convenience).
Diabilities:
Students who need disability-related accommodations are encouraged to discuss this with the instructor as soon as possible.


GGA Year Round Gift Giving Project with Non-Profit Organizations
The idea of giving all year long developed from our collaborations with the estate sale organizations. These estate sale organizations gift us whatever household items are left from their sales and we then gift these items to small non- profit organizations that are in need of these items. These collaborations allow us to spread some positive energy in the community, assist those in need and help the non-profits continue to do their work with the families who are in need of assistance.
As a result of these collaborations with estate sales, we have already established connections with 40+ small non- profit organizations serving the community (
click here for a current listing of those organizations with whom we are working). We are in process of establishing a permanent clearinghouse of "in kind" donations that are gifted directly to those families and organizations in need. We have gifted countless families now. Stay in touch as things progress on this front.
Does this idea of directly assisting the community appeal to you? Interested in helping us? We are seeking professional grant writers, business people and fundraisers to assist us in funding this organization. We are also seeking volunteers to help us pick up and sort through these donations and even refurbish furniture in need of a make-over.
If you are interested in assisting, contact Kalei at
<EMAIL_ADDRESS>Our collaboration with several estate sale organizations:
Follow this link to see the list of the local estate sale organizations who have or are currently partnering with us to help provide items for the small non profit organizations housing the homeless or those in housing crisis and also with small non profit community art centers.
The Christmas Gift Giving project's main focus is on unadulterated giving. It is about gifting others, total strangers, just to spread joy and kindness. It is the purest form of giving, basically giving without an agenda. What a beautiful exchange of energy! The project has grown and others have asked to become involved. So, it is now an integral part of Gift Givers Anonymous.
How Does the Project Work: We collect donated "gently used items" or even new items all year long that people no longer need. We take those gifts and turn them into new gifts that can be gifted to people throughout the Albuquerque community. Then, in late November volunteers come together to package and wrap gifts. On one special weekend in December, we all go out into the community and give gifts away to people!! Each gift receives a card (pictured above) that says "You've Just Been Tagged By An Anonymous Gift Of Kindness...Continue The Chain and Pass A Gift Of Kindness On."
The best descriptions of the Christmas Project can be found on the Gift Giving Stories on this website. Click on the tab to read people’s experiences both in being the giver and recipient of these surprise gifts at Christmas time.
Christmas Gifting is coming up!
Last year we gifted over 700 gifts to the community. We had so many items we had 2 gift packing parties for gifting the community. We had 3 generations helping to pack the gifts and people from all over the community helping to gift. Let's replicate that again this year and have even more people helping to distribute. Christmas is coming up. Our goal is to gift 1200 gifts throughout ABQ this Christmas.
Contact us if you want more information.


Contains core routines to read different combinations of scalars and 1D arrays from a file
Read in multiple items from a line
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| real(kind=r64), | intent(out) | :: | d | Number |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| real(kind=r64), | intent(out) | :: | d | Number |
||
| real(kind=r64), | intent(out) | :: | e | Number |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a(:) | Vector |
||
| real(kind=r64), | intent(out) | :: | b(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a(:) | Vector |
||
| real(kind=r64), | intent(out) | :: | b(:) | Vector |
||
| real(kind=r64), | intent(out) | :: | c(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b(:) | Vector |
||
| real(kind=r64), | intent(out) | :: | c(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| real(kind=r64), | intent(out) | :: | d | Number |
||
| real(kind=r64), | intent(out) | :: | e(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| real(kind=r64), | intent(out) | :: | d(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| real(kind=r64), | intent(out) | :: | d(:) | Vector |
||
| real(kind=r64), | intent(out) | :: | e(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c(:) | Vector |
||
| real(kind=r64), | intent(out) | :: | d(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| real(kind=r64), | intent(out) | :: | d | Number |
||
| real(kind=r64), | intent(out) | :: | e | Number |
||
| real(kind=r64), | intent(out) | :: | f(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |
Interfaced with readLine()
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| real(kind=r64), | intent(out) | :: | a | Number |
||
| real(kind=r64), | intent(out) | :: | b | Number |
||
| real(kind=r64), | intent(out) | :: | c | Number |
||
| real(kind=r64), | intent(out) | :: | d | Number |
||
| real(kind=r64), | intent(out) | :: | e | Number |
||
| real(kind=r64), | intent(out) | :: | f(:) | Vector |
||
| real(kind=r64), | intent(out) | :: | g(:) | Vector |
||
| character(len=*), | intent(in) | :: | fname | File name |
||
| integer(kind=i32), | intent(in) | :: | iunit | File id number to read from |
||
| character(len=*), | intent(in), | optional | :: | buf | Character string to read from instead of the line in the file |