Odo Base Component
Base component for odo components. Inherits from EventEmitter and includes media query listeners. It's meant to be inherited from.
Support
IE9+
Dependencies
TinyEmitter, debounce (bundled)
Basic Base Component
The Odo Base component essentially is an ES6 bootstrap for modules you may want to build. It should be used with class inheritence to extend functionality of the module you wish to create.
By creating, or extending, the base component, a developer with have reference to the element as well as public methods to find children elements.
Setup
import OdoBaseComponent from '@odopod/odo-base-component';
class CoolModule extends OdoBaseComponent {
constructor(element) {
super(element);
}
}
Base Component - media query listeners
Browsers withoutwindow.matchMedia
or the addListener
method will not have any media query listeners.
Additionally, the base component can also bootstrap your module to listen on media queries using native matchMedia
method. By opting into listening to media queries defined within the base component, you can override the onMediaQueryChange
method to set your module to respond to different breakpoints, as well as access instance and static methods related to each media query defined.
The media queries defined within the base component:
OdoBaseComponent.queries.xs
- below 767pxOdoBaseComponent.queries.sm
- between 768px and 1023pxOdoBaseComponent.queries.md
- between 1024px and 1391pxOdoBaseComponent.queries.lg
- above 1392px
Setup
class CoolModule extends OdoBaseComponent {
constructor(element) {
super(element, true);
}
onMediaQueryChange() {
// Do something
}
}
Public Instance Methods
The following methods will return child elements of your base component:
getElementByClass(className)
Returns the first DOM element matching the class name or null if there are no matches.
getElementsByClass(className)
Retrieve elements by class name within the main element for this class.
getElementsBySelector(selector)
Retrieve elements by selector within the main element for this class.
onMediaQueryChange()
The media query listeners detected a change. Override this method to add your own implementation.
dispose()
Remove element references, event listeners, and media query listeners for the current instance.
Static Properties & Methods
breakpoint
Returns an object with matches
and current
. This is an alias for OdoBaseComponent.matches
and OdoBaseComponent.getCurrentBreakpoint()
.
OdoBaseComponent.breakpoint.matches('xs'); // true or false
OdoBaseComponent.breakpoint.current // 'xs', 'sm', 'md', or 'lg'
matches(breakpointKey)
Query the media query list to see if it currently matches. Will throw an error if the key is not recognized.
getCurrentBreakpoint()
Loop through the 4 media query lists to determine which one currently matches. Returns the key which matches.
defineBreakpoints(breakpoints)
Allows you to redefine the default breakpoints. If you want to redefine breakpoints, make sure you call this method before initializing classes which inherit from Odo Base Component. The only argument should be an array of 3 numbers.
OdoBaseComponent.defineBreakpoints([760, 992, 1200]);


Trying out the current version
One of Meld's lesser-known features is that it's easy to run without installing it. This is great for just trying out the current version, or for checking to see whether your pet bug has been fixed yet. Just get a copy of the source code from Git by opening a terminal and typing:
git clone https://gitlab.gnome.org/GNOME/meld.git
From the directory you cloned into, run:
bin/meld
Reporting bugs
If you find a problem, please report a bug at GNOME's GitLab.
Please, first check to see whether your bug still exists in the current version and see whether someone else has reported the bug already.
Getting Meld's source code
The Meld source code is kept at the GNOME Git repository. You can easily
browse the current version of the source code at:
https://gitlab.gnome.org/GNOME/meld
If you'd like to contribute, then grab a copy of the code, make some changes, and submit a patch to the mailing list or GitLab.
Getting involved
If you're interested in participating in Meld's development, or if you're just a generally curious person, you can join Meld's discussion forum.
Roadmap
Meld doesn't have an official roadmap as such. At least not one that's actually followed. Here are a list of things that are on the radar for the near future:
- Move to using gtkrc-defined colours everywhere
- Improve our comparison performance by adding a Cython version of MyersMatcher
- Add a limited D-Bus interface to support opening new comparisons in tabs


Today's image was also made at Uepi in September 2009, and features a nudibranch (Phyllidia varicosa) that is quite common in tropical Pacific waters.
It was captured at a dive site called BOTCH (Bottom Of The CHannel), which lies in the channel between Uepi Island and the adjacent island.
BOTCH is a more advanced dive, with depths of 40m+ being encountered, along with the possibility of reasonable currents. It is these currents which bring nutrients, creating a diversity of large and small marine life
This nudibranch (P. varicosa) was quite photogenic, being colourful and lying on a colourful background. I must admit I didn't notice the parasites on it until I downloaded the images to my laptop after the dive.
The nudi is quite large, and with my single strobe positioned over the top, there was some shadow detail under the mantle. Some basic HDR tone mapping has brought the shadow detail out quite nicely (IMHO), and also given the colours a natural pop.


[gecode-users] unknown system size
Chd Orti
richard.portell at gmail.com
Wed Aug 13 17:35:18 CEST 2014
Hello,
I have an array of integers with unknown size, with an easy constraint for
example :
Sum of array integers = 10;
It could be 1,9, or 3,3,4, or 1,1,1,7, etc ...
Is there a way gecode can handle that ?
Cheers,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20140813/75b0092f/attachment.html>
More information about the users
mailing list


Codeigniter Pagination Re Use Query Strings
A few months ago I had a problem. I was paginating some results based on some data the user had provided. So I needed to be able to pass that data from page to page during the pagination process. First I set to read the Codeigniter documentation to see if it was possible to do that with the pagination library.
Turns out I could if I set up that data to be a query string and save it in my suffix param. However this solution had a problem. Every-time the user clicked the first or last link on the pagination the query string would disappear. So I searched some more, and found something even better. The new version of the pagination Library (3.0) already had that feature. So if you ever need it and don’t want to wait for the next version of Codeigniter you just have to do the following.
Download the version 3.0 of the Pagination Library here.
Extend your current version of the pagination Library with the one that you just downloaded. (see how to do that here)
As you can see the pagination now has one more param than before. It’s called reuse_query_string. And just by setting that to TRUE, you can now use both uri segments and query strings in your pagination.
protected $base_url = ''; // The page we are linking to
protected $prefix = ''; // A custom prefix added to the path.
protected $suffix = ''; // A custom suffix added to the path.
protected $total_rows = 0; // Total number of items (database results)
protected $per_page = 10; // Max number of items you want shown per page
protected $num_links = 2; // Number of "digit" links to show before/after the currently viewed page
protected $cur_page = 0; // The current page being viewed
protected $use_page_numbers = FALSE; // Use page number for segment instead of offset
protected $first_link = '‹ First';
protected $next_link = '>';
protected $prev_link = '<';
protected $last_link = 'Last ›';
protected $uri_segment = 3;
protected $full_tag_open = '';
protected $full_tag_close = '';
protected $first_tag_open = '';
protected $first_tag_close = ' ';
protected $last_tag_open = ' ';
protected $last_tag_close = '';
protected $first_url = ''; // Alternative URL for the First Page.
protected $cur_tag_open = ' <strong>';
protected $cur_tag_close = '</strong>';
protected $next_tag_open = ' ';
protected $next_tag_close = ' ';
protected $prev_tag_open = ' ';
protected $prev_tag_close = '';
protected $num_tag_open = ' ';
protected $num_tag_close = '';
protected $page_query_string = FALSE;
protected $query_string_segment = 'per_page';
protected $display_pages = TRUE;
protected $_attributes = '';
protected $_link_types = array();
protected $reuse_query_string = FALSE;
protected $data_page_attr = 'data-ci-pagination-page';


| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This library provides functions for manipulating Unicode strings and for manipulating C strings according to the Unicode standard.
It consists of the following parts:
<unistr.h>
elementary string functions
<uniconv.h>
conversion from/to legacy encodings
<unistdio.h>
formatted output to strings
<uniname.h>
character names
<unictype.h>
character classification and properties
<uniwidth.h>
string width when using nonproportional fonts
<unigbrk.h>
grapheme cluster breaks
<uniwbrk.h>
word breaks
<unilbrk.h>
line breaking algorithm
<uninorm.h>
normalization (composition and decomposition)
<unicase.h>
case folding
<uniregex.h>
regular expressions (not yet implemented)
libunistring is for you if your application involves non-trivial text processing, such as upper/lower case conversions, line breaking, operations on words, or more advanced analysis of text. Text provided by the user can, in general, contain characters of all kinds of scripts. The text processing functions provided by this library handle all scripts and all languages.
libunistring is for you if your application already uses the ISO C / POSIX
<ctype.h>
, <wctype.h>
functions and the text it
operates on is provided by the user and can be in any language.
libunistring is also for you if your application uses Unicode strings as internal in-memory representation.
Unicode is a standardized repertoire of characters that contains characters from all scripts of the world, from Latin letters to Chinese ideographs and Babylonian cuneiform glyphs. It also specifies how these characters are to be rendered on a screen or on paper, and how common text processing (word selection, line breaking, uppercasing of page titles etc.) is supposed to behave on Unicode text.
Unicode also specifies three ways of storing sequences of Unicode characters in a computer whose basic unit of data is an 8-bit byte:
Every character is represented as 1 to 4 bytes.
Every character is represented as 1 to 2 units of 16 bits.
Every character is represented as 1 unit of 32 bits.
For encoding Unicode text in a file, UTF-8 is usually used. For encoding Unicode strings in memory for a program, either of the three encoding forms can be reasonably used.
Unicode is widely used on the web. Prior to the use of Unicode, web pages were in many different encodings (ISO-8859-1 for English, French, Spanish, ISO-8859-2 for Polish, ISO-8859-7 for Greek, KOI8-R for Russian, GB2312 or BIG5 for Chinese, ISO-2022-JP-2 or EUC-JP or Shift_JIS for Japanese, and many many others). It was next to impossible to create a document that contained Chinese and Polish text in the same document. Due to the many encodings for Japanese, even the processing of pure Japanese text was error prone.
References:
Internationalization is the process of changing the source code of a program so that it can meet the expectations of users in any culture, if culture specific data (translations, images etc.) are provided.
Use of Unicode is not strictly required for internationalization, but it makes internationalization much easier, because operations that need to look at specific characters (like hyphenation, spell checking, or the automatic conversion of double-quotes to opening and closing double-quote characters) don't need to consider multiple possible encodings of the text.
Use of Unicode also enables multilingualization: the ability of having text in multiple languages present in the same document or even in the same line of text.
But use of Unicode is not everything. Internationalization usually consists of four features:
A locale is a set of cultural conventions. According to POSIX, for a program, at any moment, there is one locale being designated as the “current locale”. (Actually, POSIX supports also one locale per thread, but this feature is not yet universally implemented and not widely used.) The locale is partitioned into several aspects, called the “categories” of the locale. The main various aspects are:
LC_CTYPE
category.
LC_COLLATE
category.
LC_MESSAGES
category.
LC_NUMERIC
category.
LC_MONETARY
category.
LC_TIME
category.
In particular, the LC_CTYPE
category of the current locale determines
the character encoding. This is the encoding of ‘char *’ strings.
We also call it the “locale encoding”. GNU libunistring has a function,
locale_charset
, that returns a standardized (platform independent)
name for this encoding.
All locale encodings used on glibc systems are essentially ASCII compatible: Most graphic ASCII characters have the same representation, as a single byte, in that encoding as in ASCII.
Among the possible locale encodings are UTF-8 and GB18030. Both allow to represent any Unicode character as a sequence of bytes. UTF-8 is used in most of the world, whereas GB18030 is used in the People's Republic of China, because it is backward compatible with the GB2312 encoding that was used in this country earlier.
The legacy locale encodings, ISO-8859-15 (which supplanted ISO-8859-1 in most of Europe), ISO-8859-2, KOI8-R, EUC-JP, etc., are still in use in some places, though.
UTF-16 and UTF-32 are not used as locale encodings, because they are not ASCII compatible.
There are three ways of representing strings in memory of a running program.
wchar_t
mess.
Of course, a ‘char *’ string can, in some cases, be encoded in UTF-8.
You will use the data type depending on what you can guarantee about how
it's encoded: If a string is encoded in the locale encoding, or if you
don't know how it's encoded, use ‘char *’. If, on the other hand,
you can guarantee that it is UTF-8 encoded, then you can use the
UTF-8 string type, uint8_t *
, for it.
The five types char *
, uint8_t *
, uint16_t *
,
uint32_t *
, and wchar_t *
are incompatible types at the C
level. Therefore, ‘gcc -Wall’ will produce a warning if, by mistake,
your code contains a mismatch between these types. In the context of
using GNU libunistring, even a warning about a mismatch between
char *
and uint8_t *
is a sign of a bug in your code
that you should not try to silence through a cast.
The classical C strings, with its C library support standardized by ISO C and POSIX, can be used in internationalized programs with some precautions. The problem with this API is that many of the C library functions for strings don't work correctly on strings in locale encodings, leading to bugs that only people in some cultures of the world will experience.
The first problem with the C library API is the support of multibyte
locales. According to the locale encoding, in general, every character
is represented by one or more bytes (up to 4 bytes in practice — but
use MB_LEN_MAX
instead of the number 4 in the code).
When every character is represented by only 1 byte, we speak of an
“unibyte locale”, otherwise of a “multibyte locale”. It is important
to realize that the majority of Unix installations nowadays use UTF-8
or GB18030 as locale encoding; therefore, the majority of users are
using multibyte locales.
The important fact to remember is:
|
A ‘char’ is a byte, not a character. |
As a consequence:
<ctype.h>
API is useless in this context; it does not work in
multibyte locales.
strlen
function does not return the number of characters
in a string. Nor does it return the number of screen columns occupied
by a string after it is output. It merely returns the number of
bytes occupied by a string.
strncpy
, can have the
effect of truncating it in the middle of a multibyte character. Such
a string will, when output, have a garbled character at its end, often
represented by a hollow box.
strchr
and strrchr
do not work with multibyte strings
if the locale encoding is GB18030 and the character to be searched is
a digit.
strstr
does not work with multibyte strings if the locale encoding
is different from UTF-8.
strcspn
, strpbrk
, strspn
cannot work
correctly in multibyte locales: they assume the second argument is a list of
single-byte characters. Even in this simple case, they do not work with
multibyte strings if the locale encoding is GB18030 and one of the
characters to be searched is a digit.
strsep
and strtok_r
do not work with multibyte strings
unless all of the delimiter characters are ASCII characters < 0x30.
strcasecmp
, strncasecmp
, and strcasestr
functions do not work with multibyte strings.
The workarounds can be found in GNU gnulib https://www.gnu.org/software/gnulib/.
mbslen
and mbswidth
that can be
used instead of strlen
when the number of characters or the
number of screen columns of a string is requested.
mbschr
and mbsrrchr
that are
like strchr
and strrchr
, but work in multibyte locales.
mbsstr
, like strstr
, but works
in multibyte locales.
mbscspn
, mbspbrk
, mbsspn
that are like strcspn
, strpbrk
, strspn
, but
work in multibyte locales.
mbssep
and mbstok_r
that are
like strsep
and strtok_r
but work in multibyte locales.
mbscasecmp
, mbsncasecmp
,
mbspcasecmp
, and mbscasestr
that are like strcasecmp
,
strncasecmp
, and strcasestr
, but
work in multibyte locales. Still, the function ulc_casecmp
is
preferable to these functions; see below.
The second problem with the C library API is that it has some assumptions built-in that are not valid in some languages:
The correct way to deal with this problem is
This is implemented in this library, through the functions declared in <unicase.h>
, see Case mappings <unicase.h>
.
libunistring supports Unicode strings in three representations:
uint8_t
).
uint16_t
).
uint32_t
).
As with C strings, there are two variants:
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Bruno Haible on January, 2 2022 using texi2html 1.78a.


As Genit is written in Ruby 1.9.2, you need at least the Ruby 1.9.2 interpreter to run it. You need rubygem too.
Rubygem is a marvelous Ruby application that acts as an installer.
Go to www.ruby-lang.org and follow the instructions...
If you run into troubles when installing Ruby 1.9.2, you can see the
book of Genit. The first chapter is about
installing Ruby.
Thanks to rubygem, downloading and installing Genit is as simple as open a console and type:
gem instal genit
All other dependencies will be downloaded and installed automatically.
This step is optional but performing the smoke test is a good thing to be sure
the installation is well done.
Open a console window and type:
genit create test
cd test
genit compile
Then go to the test/www/
folder and double click the index.html file.
That's it !


Get full control over your ads with us
Buy AdsNo account needed
Worried about the quality of traffic? Not with Coinzilla. We select our publishers carefully so we can deliver you only the best ones. As a plus, our system filters the traffic and assures a great experience for all of our customers.
You've got an issue? We're here to help! Our support will assist you with any technical issue. You are our number one priority and we'll do our best to solve your issues in minutes.
Choose between CPM or CPC Advertising and see which one suits you the best! One thing is for sure, Coinzilla's traffic will grow your earnings and increase your ROI starting from your first campaign.
Choose between our variety of Ad Formats and Display Zones that we have prepared for you. We've tested them ourselves and then we selected the best converting ones so you can succeed with them too.
Don't know which one to choose? Try both with Coinzilla. Specially selected Ad Formats for increasing conversions and ROI and a great selection of publishers is what makes Coinzilla your best advertising partner.
With Coinzilla, all the traffic is great. It's hard to find the best sources that deliver great traffic, but we do know for sure that everyone has a favorite, so we've implemented Website targeting in order to target your favorite publishers.
Create your advertisement
Buy AdsJoin us and earn Bitcoins
Start earning now


3555 Farnam Street
Omaha, NE 68131
Official Home Page
WWW.GEICO.COM OR CALL 1-888-395-6349, 24 HOURS A DAY
If you have any comments about our WEB page, you can either write us at the address shown above or e-mail us at<EMAIL_ADDRESS>However, due to the limited number of personnel in our corporate office, we are unable to provide a direct response.