/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* GimpTextLayer
* Copyright (C) 2002-2004 Sven Neumann
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
/**
* gimp_text_layer_new:
* @image: the #GimpImage the layer should belong to
* @text: a #GimpText object
*
* Creates a new text layer.
*
* Return value: a new #GimpTextLayer or %NULL in case of a problem
**/
GimpLayer *
gimp_text_layer_new (GimpImage *image,
GimpText *text)
{
GimpTextLayer *layer;
g_return_val_if_fail (GIMP_IS_IMAGE (image), NULL);
g_return_val_if_fail (GIMP_IS_TEXT (text), NULL);
if (! text->text)
return NULL;
layer = g_object_new (GIMP_TYPE_TEXT_LAYER, NULL);
gimp_drawable_configure (GIMP_DRAWABLE (layer),
image,
0, 0, 1, 1,
gimp_image_base_type_with_alpha (image),
NULL);
gimp_text_layer_set_text (layer, text);
if (! gimp_text_layer_render (layer))
{
g_object_unref (layer);
return NULL;
}
return GIMP_LAYER (layer);
}
cd cover + colorize in gimp
Copyright (C) 1995 Spencer Kimball and Peter Mattis . GPL GIMP colorize.c
.
.
.
void
colorize (Colorize *colorize,
PixelRegion *srcPR,
PixelRegion *destPR)
{
const guchar *src, *s;
guchar *dest, *d;
gboolean alpha;
gint w, h;
gint lum;
/* Set the transfer arrays (for speed) */
h = srcPR->h;
src = srcPR->data;
dest = destPR->data;
alpha = (srcPR->bytes == 4) ? TRUE : FALSE;
while (h--)
{
w = srcPR->w;
s = src;
d = dest;
while (w--)
{
lum = (colorize->lum_red_lookup[s[RED_PIX]] +
colorize->lum_green_lookup[s[GREEN_PIX]] +
colorize->lum_blue_lookup[s[BLUE_PIX]]); /* luminosity */
if (colorize->lightness > 0)
{
lum = (gdouble) lum * (100.0 - colorize->lightness) / 100.0;
lum += 255 - (100.0 - colorize->lightness) * 255.0 / 100.0;
}
else if (colorize->lightness lightness + 100.0) / 100.0;
}
d[RED_PIX] = colorize->final_red_lookup[lum];
d[GREEN_PIX] = colorize->final_green_lookup[lum];
d[BLUE_PIX] = colorize->final_blue_lookup[lum];
if (alpha)
d[ALPHA_PIX] = s[ALPHA_PIX];
s += srcPR->bytes;
d += destPR->bytes;
}
src += srcPR->rowstride;
dest += destPR->rowstride;
}
}
http://www.jeffgraphics.in/2010/12/09/cd-cover-colorize-in-gimp/
RMS + lomograph
A Lomograph holds a charm all of its own. Somehow, everything is amplified, making ordinary objects stand out, enhancing details that would normally go unnoticed. Characterised by ever-changing variables such as the mysterious vignettes that frame the shot, light leaks, lo-fi grain, beautiful blurs, the magical balance of contrast and saturation just to name a few. A combination these factors and a healthy touch of the unexpected go into making each Lomograph unique. Essentially, Lomography embraces the element of surprise that only analogue film photography can bring and wholeheartedly celebrates the outcome. Experiment with different kinds of films, and try different tips and techniques, such as cross-processing (x-pro) it works well with Lomographic cameras!
coding standard related work for Linux kernel code using checkpatch.pl tool
$git fetch origin
$
$./scripts/checkpatch.pl --file --terse sound/sound_core.c | more
sound/sound_core.c:71: ERROR: trailing whitespace
sound/sound_core.c:83: ERROR: trailing whitespace
sound/sound_core.c:85: ERROR: trailing whitespace
sound/sound_core.c:115: ERROR: open brace '{' following
struct go on the same line
sound/sound_core.c:123: WARNING: externs should be avoided in .c files
sound/sound_core.c:126: WARNING: externs should be avoided in .c files
sound/sound_core.c:155: ERROR: do not initialise statics to 0 or NULL
sound/sound_core.c:163: ERROR: that open brace { should be on the
previous line
sound/sound_core.c:175: WARNING: line over 80 characters
.
.
.
.
.
.
sound/sound_core.c:586: ERROR: trailing whitespace
sound/sound_core.c:633: ERROR: space required after that ',' (ctx:VxV)
total: 77 errors, 26 warnings, 667 lines checked
.
.
.
.
.
.
total: 73 errors, 26 warnings, 666 lines checked
As an alternative to automatic variables, it is possible to define
variables that are external to all functions, that is, variables that
can be accessed by name by any function. (This mechanism is rather
like Fortran COMMON or Pascal variables declared in the outermost
block.) Because external variables are globally accessible, they can
be used instead of argument lists to communicate data between
functions. Furthermore, because external variables remain in existence
permanently, rather than appearing and disappearing as functions are
called and exited, they retain their values even after the functions
that set them have returned.
.
.
.
.
total: 28 errors, 23 warnings, 663 lines checked
$./scripts/checkpatch.pl --file --terse sound/sound_core.c
sound/sound_core.c:122: WARNING: externs should be avoided in .c files
sound/sound_core.c:125: WARNING: externs should be avoided in .c files
.
.
.
.
.
total: 0 errors, 11 warnings, 662 lines checked
$
kernel work log sound 0.11
$git fetch origin
$
$./scripts/checkpatch.pl --file --terse sound/sound_core.c | more
sound/sound_core.c:71: ERROR: trailing whitespace
sound/sound_core.c:83: ERROR: trailing whitespace
sound/sound_core.c:85: ERROR: trailing whitespace
sound/sound_core.c:115: ERROR: open brace '{' following
struct go on the same line
sound/sound_core.c:123: WARNING: externs should be avoided in .c files
sound/sound_core.c:126: WARNING: externs should be avoided in .c files
sound/sound_core.c:155: ERROR: do not initialise statics to 0 or NULL
sound/sound_core.c:163: ERROR: that open brace { should be on the
previous line
sound/sound_core.c:175: WARNING: line over 80 characters
.
.
.
.
.
.
sound/sound_core.c:586: ERROR: trailing whitespace
sound/sound_core.c:633: ERROR: space required after that ',' (ctx:VxV)
total: 77 errors, 26 warnings, 667 lines checked
.
.
. <fixing>
.
.
.
total: 73 errors, 26 warnings, 666 lines checked
As an alternative to automatic variables, it is possible to define variables that are external to all functions, that is, variables that can be accessed by name by any function. (This mechanism is rather like Fortran COMMON or Pascal variables declared in the outermost block.) Because external variables are globally accessible, they can be used instead of argument lists to communicate data between functions. Furthermore, because external variables remain in existence permanently, rather than appearing and disappearing as functions are called and exited, they retain their values even after the functions that set them have returned.
. . . < fixing > . total: 28 errors, 23 warnings, 663 lines checked $./scripts/checkpatch.pl --file --terse sound/sound_core.c sound/sound_core.c:122: WARNING: externs should be avoided in .c files sound/sound_core.c:125: WARNING: externs should be avoided in .c files . . . . . total: 0 errors, 11 warnings, 662 lines checked $
Some idea about creating a linux kernel patch using Git
ABOUT creating a linux kernel patch using Git
[bash]
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/jeffrin/linux-2.6/.git/
remote: Counting objects: 1806930, done.
remote: Compressing objects: 100% (278260/278260), done.
Receiving objects: 14% (2553100/1806930), 117.83 MiB | 127 KiB/s
Resolving deltas: 100% (1513210/1513210), done.
$cd linux-2.6
$./scripts/ge
genksyms/ get_maintainer.pl
$./scripts/get_maintainer.pl –file sound/ac97_bus.c
Jaroslav Kysela <perex@perex.cz>
Takashi Iwai <tiwai@suse.de>
alsa-devel@alsa-project.org
linux-kernel@vger.kernel.org
$
[/bash]
[bash]
$ git status
# On branch master
nothing to commit (working directory clean)
$ git branch jeffrin
$ git branch
jeffrin
* master
$ git checkout jeffrin
Switched to branch ‘jeffrin’
$
$git status
# On branch jeffrin
nothing to commit (working directory clean)
$
$./scripts/checkpatch.pl
checkpatch.pl: no input files
$./scripts/checkpatch.pl –file –terse sound/ac97_bus.c
sound/ac97_bus.c:22: WARNING: line over 80 characters
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 0 errors, 2 warnings, 77 lines checked
[/bash]
[bash]
$vim sound/ac97_bus.c +22
$./scripts/checkpatch.pl –file –terse sound/ac97_bus.c
sound/ac97_bus.c:22: ERROR: trailing whitespace
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 1 errors, 1 warnings, 77 lines checked
$vim sound/ac97_bus.c +22
$./scripts/checkpatch.pl –file –terse sound/ac97_bus.c
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 0 errors, 1 warnings, 77 lines checked
$vim sound/ac97_bus.c +75
[/bash]
[bash]
$git status
# On branch jeffrin
# Changed but not updated:
# (use "git add …" to update what will be committed)
# (use "git checkout — …" to discard changes in working directory)
#
# modified: sound/ac97_bus.c
#
no changes added to commit (use "git add" and/or "git commit -a")
$git diff
diff –git a/sound/ac97_bus.c b/sound/ac97_bus.c
index a351dd0..c93251a 100644
— a/sound/ac97_bus.c
+++ b/sound/ac97_bus.c
@@ -19,9 +19,9 @@
/*
* Let drivers decide whether they want to support given codec from their
– * probe method. Drivers have direct access to the struct snd_ac97 structure and may
– * decide based on the id field amongst other things.
– */
+ * probe method. Drivers have direct access to the struct snd_ac97
+ * structure and may decide based on the id field amongst other things.
+*/
static int ac97_bus_match(struct device *dev, struct device_driver *drv)
{
return 1;
$
[/bash]
[bash]
$git commit sound/ac97_bus.c
[jeffrin a2c2867] sound: Fixed line limit issue in sound/ac97_bus.c
This is a patch to the sound/ac97_bus.c file that fixes up a 80
character line limit issue found by the checkpatch.pl tool.
Signed-off-by: Jeffrin Jose
1 files changed, 3 insertions(+), 3 deletions(-)
$git show HEAD
commit a2c2867876c246420a199a0fb4c36ad29100a42cc
Author: Jeffrin Jose
Date: Mon Dec 6 19:27:53 2010 +0530
sound: Fixed line limit issue in sound/ac97_bus.c
This is a patch to the sound/ac97_bus.c file that fixes up a 80 character
line limit issue found by the checkpatch.pl tool.
Signed-off-by: Jeffrin Jose
diff –git a/sound/ac97_bus.c b/sound/ac97_bus.c
index a351dd0..c93251a 100644
— a/sound/ac97_bus.c
+++ b/sound/ac97_bus.c
@@ -19,9 +19,9 @@
/*
* Let drivers decide whether they want to support given codec from their
– * probe method. Drivers have direct access to the struct snd_ac97 structure and may
– * decide based on the id field amongst other things.
– */
+ * probe method. Drivers have direct access to the struct snd_ac97
+ * structure and may decide based on the id field amongst other things.
+*/
static int ac97_bus_match(struct device *dev, struct device_driver *drv)
{
return 1;
[/bash]
[bash]
$git format-patch master..jeffrin
0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch
[/bash]
[bash]
$./scripts/checkpatch.pl 0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch
total: 0 errors, 0 warnings, 12 lines checked
0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch has no obvious style
problems and is ready for submission.
$
[/bash]
write linux kernel patch 0.23 raw
write linux kernel patch 0.21 raw Contentgit clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Initialized empty Git repository in /home/jeffrin/linux-2.6/.git/ remote: Counting objects: 1806930, done. remote: Compressing objects: 100% (278260/278260), done. Receiving objects: 14% (255365/1806930), 117.83 MiB | 127 KiB/s Resolving deltas: 100% (1513210/1513210), done.$cd linux-2.6 $./scripts/ge genksyms/ get_maintainer.pl $./scripts/get_maintainer.pl --file sound/ac97_bus.c Jaroslav Kysela <perex@perex.cz> Takashi Iwai <tiwai@suse.de> alsa-devel@alsa-project.org linux-kernel@vger.kernel.org $$ git status # On branch master nothing to commit (working directory clean) $ git branch jeffrin $ git branch jeffrin * master $ git checkout jeffrin Switched to branch 'jeffrin' $ $git status # On branch jeffrin nothing to commit (working directory clean) $ $./scripts/checkpatch.pl checkpatch.pl: no input files $./scripts/checkpatch.pl --file --terse sound/ac97_bus.c sound/ac97_bus.c:22: WARNING: line over 80 characters sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable total: 0 errors, 2 warnings, 77 lines checked$vim sound/ac97_bus.c +22 $./scripts/checkpatch.pl --file --terse sound/ac97_bus.c sound/ac97_bus.c:22: ERROR: trailing whitespace sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable total: 1 errors, 1 warnings, 77 lines checked $vim sound/ac97_bus.c +22 $./scripts/checkpatch.pl --file --terse sound/ac97_bus.c sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable total: 0 errors, 1 warnings, 77 lines checked $vim sound/ac97_bus.c +75$git status # On branch jeffrin # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: sound/ac97_bus.c # no changes added to commit (use "git add" and/or "git commit -a") $git diff diff --git a/sound/ac97_bus.c b/sound/ac97_bus.c index a351dd0..c93251a 100644 --- a/sound/ac97_bus.c +++ b/sound/ac97_bus.c @@ -19,9 +19,9 @@ /* * Let drivers decide whether they want to support given codec from their - * probe method. Drivers have direct access to the struct snd_ac97 structure and may - * decide based on the id field amongst other things. - */ + * probe method. Drivers have direct access to the struct snd_ac97 + * structure and may decide based on the id field amongst other things. +*/ static int ac97_bus_match(struct device *dev, struct device_driver *drv) { return 1; $$git commit sound/ac97_bus.c [jeffrin a2c2867] sound: Fixed line limit issue in sound/ac97_bus.c This is a patch to the sound/ac97_bus.c file that fixes up a 80 character line limit issue found by the checkpatch.pl tool. Signed-off-by: Jeffrin Jose 1 files changed, 3 insertions(+), 3 deletions(-) $git show HEAD commit a2c2867876c246420a199a0fb4c36ad2965a42cc Author: Jeffrin Jose Date: Mon Dec 6 19:27:53 2010 +0530 sound: Fixed line limit issue in sound/ac97_bus.c This is a patch to the sound/ac97_bus.c file that fixes up a 80 character line limit issue found by the checkpatch.pl tool. Signed-off-by: Jeffrin Jose diff --git a/sound/ac97_bus.c b/sound/ac97_bus.c index a351dd0..c93251a 100644 --- a/sound/ac97_bus.c +++ b/sound/ac97_bus.c @@ -19,9 +19,9 @@ /* * Let drivers decide whether they want to support given codec from their - * probe method. Drivers have direct access to the struct snd_ac97 structure and may - * decide based on the id field amongst other things. - */ + * probe method. Drivers have direct access to the struct snd_ac97 + * structure and may decide based on the id field amongst other things. +*/ static int ac97_bus_match(struct device *dev, struct device_driver *drv) { return 1; $git format-patch master..jeffrin 0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch $./scripts/checkpatch.pl 0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch total: 0 errors, 0 warnings, 12 lines checked 0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch has no obvious style problems and is ready for submission. $
Dirty: 8 kB
What is an Unevictable LRU Infrastructure ?
RELATED TO Unevictable
The Unevictable LRU infrastructure addresses the following classes of unevictable pages: + page owned by ram disks or ramfs + page mapped into SHM_LOCKed shared memory regions + page mapped into VM_LOCKED [mlock()ed] vmas
Least Recently Used (LRU): discards the least recently used items first. This algorithm requires keeping track of what was used when, which is expensive if one wants to make sure the algorithm always discards the least recently used item. General implementations of this technique require to keep "age bits" for cache-lines and track the "Least Recently Used" cache-line based on age-bits. In such implementation, every time a cache-line is used, the age of all other cache-lines changes. LRU is actually a family of caching algorithms with members including: 2Q by Theodore Johnson and Dennis Shasha and LRU/K by Pat O'Neil, Betty O'Neil and Gerhard Weikum. Hugetlb pages are also unevictable. Hugepages are already implemented in a way that these pages don't reside on the LRU and hence are not iterated over during the vmscan. So there is no need to move around these pages across different LRU's. We just account these pages as unevictable for correct statistics. The Unevictable LRU adds an additional LRU list to track unevictable pages and to hide these pages from vmscan. This mechanism is based on a patch by Larry Woodman of Red Hat to address several scalability problems with page reclaim in Linux. The problems have been observed at customer sites on large memory x86_64 systems. For example, a non-numal x86_64 platform with 128GB of main memory will have over 32 million 4k pages in a single zone. When a large fraction of these pages are not evictable for any reason [see below], vmscan will spend a lot of time scanning the LRU lists looking for the small fraction of pages that are evictable. This can result in a situation where all cpus are 4 spending 100% of their time in vmscan for hours or days on end, with the system completely unresponsive.
TYPICAL COMMANDLINE RELATED EXPOSURE
[bash]
$sudo cat /proc/meminfo | grep -A 5 -B 5 Unevictable
Inactive: 1591548 kB
Active(anon): 595404 kB
Inactive(anon): 502680 kB
Active(file): 1009628 kB
Inactive(file): 1088868 kB
Unevictable: 130612 kB
Mlocked: 80 kB
SwapTotal: 8075260 kB
SwapFree: 8074736 kB
Dirty: 260 kB
Writeback: 0 kB
$
[/bash]
LINKS
https://www.kernel.org/doc/Documentation/vm/unevictable-lru.txt
https://serverfault.com/questions/886483/how-to-determine-which-processes-have-unevictable-memory
https://stackoverflow.com/questions/4343249/unevictable-page
https://stackoverflow.com/questions/1072643/how-can-i-make-grep-print-the-lines-below-and-above-each-matching-line
Unevictable: 4 kB 0.1
Unevictable: 4 kB
The Unevictable LRU infrastructure addresses the following classes of unevictable pages: + page owned by ram disks or ramfs + page mapped into SHM_LOCKed shared memory regions + page mapped into VM_LOCKED [mlock()ed] vmas
Least Recently Used (LRU): discards the least recently used items first. This algorithm requires keeping track of what was used when, which is expensive if one wants to make sure the algorithm always discards the least recently used item. General implementations of this technique require to keep "age bits" for cache-lines and track the "Least Recently Used" cache-line based on age-bits. In such implementation, every time a cache-line is used, the age of all other cache-lines changes. LRU is actually a family of caching algorithms with members including: 2Q by Theodore Johnson and Dennis Shasha and LRU/K by Pat O'Neil, Betty O'Neil and Gerhard Weikum.
Hugetlb pages are also unevictable. Hugepages are already implemented in a way that these pages don't reside on the LRU and hence are not iterated over during the vmscan. So there is no need to move around these pages across different LRU's. We just account these pages as unevictable for correct statistics.
The Unevictable LRU adds an additional LRU list to track unevictable pages and to hide these pages from vmscan. This mechanism is based on a patch by Larry Woodman of Red Hat to address several scalability problems with page reclaim in Linux. The problems have been observed at customer sites on large memory x86_64 systems. For example, a non-numal x86_64 platform with 128GB of main memory will have over 32 million 4k pages in a single zone. When a large fraction of these pages are not evictable for any reason [see below], vmscan will spend a lot of time scanning the LRU lists looking for the small fraction of pages that are evictable. This can result in a situation where all cpus are spending 100% of their time in vmscan for hours or days on end, with the system completely unresponsive.