IE, innerHTML
"The (innerHTML) property is read/write for all objects(source)
except the following, for which it is read-only:
COL, COLGROUP, FRAMESET, HTML, STYLE, TABLE, TBODY,
TFOOT, THEAD, TITLE, TR."
excellent ...
excellent ...
Disable screensaver in Ubuntu
#To disable the screensaver:(via: http://ubuntuforums.org/showthread.php?t=428967)
gconftool-2 -s /apps/gnome-screensaver/idle_activation_enabled --type=bool false
#To disable monitor sleeping:
gconftool-2 -s /apps/gnome-power-manager/ac_sleep_display --type=int 0
Fedora - replace NetworkManager with netwok init script
chkconfig NetworkManager off chkconfig –levels 35 network on /etc/init.d/network restart
Zend Search Lucene and large result sets
Index size does not affect Lucene's search speed per-se: what matters is the frequency of the search terms. And terms tend to have larger frequencies in larger indexes. (Doug Cutting on java-user)Given our index includes a keyword field that indicates a type, e.g. whether an index entry represents an article or a document. Queries should be made on these type subsets, for example to match only articles that contain `lucene' in the title. Approximately 80-90% of all indexed documents represent articles. The overall size of the index is roughly ~500'000 documents. A Boolean query consisting of two subqueries for `title:lucene' and `type:article' (both mandatory) takes unexpectedly long to execute. In this case, the blame for the delay can be clearly put to the `type:article' subquery that matches a very large result set.
$term1 = new Zend_Search_Lucene_Index_Term('t0', 'type');
$term2 = new Zend_Search_Lucene_Index_Term('lucene', 'title');
$query = new Zend_Search_Lucene_Search_Query_Boolean();
$queryt1 = new Zend_Search_Lucene_Search_Query_Term($term1);
$queryt2 = new Zend_Search_Lucene_Search_Query_Term($term2);
$query->addSubquery($queryt1, true);
$query->addSubquery($queryt2, true);
Measurements:
| Subquery 1 (type) : | 10.5533s |
| Subquery 2 (title): | 0.0889s |
| Combined: | 11.68558s |
Lucene's inherent way to retrieve documents is to successively search for every term of a query, collect the results and then perform calculations for conjunctions or intersections based on the search term operators. The complexity of the search syntax semantics probably prevents any chance for reasonable search-within-search features in order to already narrow the search space before execution of the next term (e.g. get all documents matching the title and then substract all items not matching the type). Moreover all limiting and sorting seems to be applied after the full retrieval is completed.
However, Java Lucene offers different Filters that work with cacheable BitSet objects to efficiently post-process the results, so that the expensive `type' subquery could be implemented in such a manner. Zend Search Lucene does not have filters (yet). Using termDocs() to retrieve the document ids for entries matching the title, followed by crude looping to leave out all non-article types proved to be efficient for this particular case (Measured 0.08670s).
$hits = array();
$count = 0;
$term = new Zend_Search_Lucene_Index_Term('lucene', 'title');
$docIds = $this->searchIndex->termDocs($term);
foreach($docIds as $key => $docId) {
$doc = $this->searchIndex->getDocument($docId);
if ($doc->type === 'article') {
array_push($hits, $doc);
$count++;
}
if ($count === $maxRes) break;
}
return $hits;
Adding a new disk in FreeBSD
finding newly added disk:
# cat /var/run/dmesg.bootinitializing the disk:
# fdisk -BI /dev/ad8creating the disklabel for the first slice:
# bsdlabel -w -B ad8s1editing the disklabel for the created slice:
# bsdlabel -e ad8s1verify disklabel:
# bsdlabel ad8s1Create a new ufs2 filesystem on each partition:
# /dev/ad8s1:
8 partitions:
size offset fstype [fsize bsize bps/cpg]
b: 716800 0 swap
c: 976773105 0 unused 0 0
e: 976056305 716800 4.2BSD 2048 16384 28528
# newfs /dev/ad8s1eTest:
# mount /dev/ad8s1e /dataLinks:
REST in peace
Within the descriptions of REST as an architectural style, every information or resource is supposed to be identifiable by a resource identifier or URI. Components in a RESTful environment can apply actions on resources according to their representational state. A webbrowser for example issues a request for a particular URI and retrieves the current state of the resource in xhtml. The browser is then capable of rendering the representation into a colorful webpage.
According to a purist view on REST, the distinctiveness of an URI implies its persistence independent of the action applied to it (/fileinfo/delete/myfile.txt and /fileinfo/add/myfile.txt are two different uris for the same resource). Moreover, REST relies on HTTP with its variety of request methods and it is not counted to be RESTful, if all actions have to be performed via GET. Besides the argument of not using HTTP the way it should be, there are also reasons from the view of the implementation that i find more convincing: Parameters are a source for errors, lead to ambigous requests, have to be caught and evaluated etc.
The specifications suggest a mapping of HTTP request methods that refer to particular functions:
The perfect world is nice. However, in practice one hardly finds anything beyond GET and POST methods in relation to REST apis. GET for read-only requests and POST often combines requests to either create or update a resource. An interesting option would be to include reflection mechanisms into HEAD requests. Especially since REST doesn't has something likethe unnecessary complicated WSDL to describe a service. The ways to define REST apis seem to be quite versatile. Yahoo for example defines a single resource for the websearch api. Further adjustements on the result representation are all applicable via parameters.
References / more:
According to a purist view on REST, the distinctiveness of an URI implies its persistence independent of the action applied to it (/fileinfo/delete/myfile.txt and /fileinfo/add/myfile.txt are two different uris for the same resource). Moreover, REST relies on HTTP with its variety of request methods and it is not counted to be RESTful, if all actions have to be performed via GET. Besides the argument of not using HTTP the way it should be, there are also reasons from the view of the implementation that i find more convincing: Parameters are a source for errors, lead to ambigous requests, have to be caught and evaluated etc.
The specifications suggest a mapping of HTTP request methods that refer to particular functions:
| Method | Operation | |
| GET | retrieve | retrieves the representaiton of a resource |
| HEAD | retrieves metadata for the representation and the resource |
|
| POST | create | creates a resource |
| PUT | update | updates a resource |
| DELETE | delete | deletes a resource |
The perfect world is nice. However, in practice one hardly finds anything beyond GET and POST methods in relation to REST apis. GET for read-only requests and POST often combines requests to either create or update a resource. An interesting option would be to include reflection mechanisms into HEAD requests. Especially since REST doesn't has something like
References / more:
- Roy Thomas Fielding - Architectural Styles and the Design of Network-based Software Architectures
- Robert Richards - Pro PHP XML and Web Services
- Yahoo! Search APIs
Flash/Javascript integration kit with mtasc
The following corrections were nescessary to get Macromedias flash/javascript integration kit working with mtasc:
Â
Â
-------- JavaScriptProxy.as ---------
* Replace:
public function __resolve(functionName:String):Function
{
var f:Function = function()
{
arguments.splice(0,0, functionName);
var f:Function = call;
f.apply(this, arguments);
};
return f;
}
* With:
public function __resolve(functionName:String):Function
{
var f:Function = function()
{
arguments.splice(0,0, functionName);
var f:Function = this.call; //change!!
f.apply(this, arguments);
};
return f;
}
-------- JavaScriptSerializer.as ---------
* Replace:
/* Deserializes a Boolean Value */
public static function deserializeBoolean(s:String):String
{
return Boolean(s);
}
* With:
/* Deserializes a Boolean Value */
public static function deserializeBoolean(s:String):Boolean
{
return Boolean(s);
}
//////////////////////////////////////////
//mtasc has a more strict scope rule so
* Replace:
for(var x:Number = 0; x < len; x++)
{
arr.push(parseNode(children[x], o));
}
* With:
for(var childNo:Number = 0; childNo < len; childNo++)
{
arr.push(parseNode(children[childNo], o));
}
Via: osflash mailinglist
MagickWand
The MagickWand API is the recommended interface between the C programming language and the ImageMagick image processing libraries. Unlike the MagickCore C API, MagickWand uses only a few opaque types. Accessors are available to set or get important wand attributes.i.e....
#include <wand/MagickWand.h>
MagickBooleanType status;
MagickWand *magick_wand;
PixelWand *pxlwnd;
int main() {
/* Using MagickWand for rotating a png */
magick_wand = NewMagickWand();
pxlwnd = NewPixelWand();
status=MagickReadImage(magick_wand, pngfile);
if (status != MagickFalse) {
MagickRotateImage(magick_wand, pxlwnd, 270.0);
status=MagickWriteImages(magick_wand, pngfile, MagickTrue);
if (status != MagickFalse) {
DestroyMagickWand(magick_wand);
}
return 0;
}
MagickWand needs to be linked against various libraries.
#: gcc `Wand-config --cflags --cppflags` -c wand/wand.c #: gcc -o wandtest wand.o wandtest.c `Wand-config --ldflags --libs`The API is very comprehensive - have yet only caught a glimpse of its whole function spectrum. There is a php extension too which follows pretty much the structure of the C api.
mp3 frame length
framesize (fs) = 1152 Samples/Frame (Layer 2 and 3 only) bytefactor = 1152 Samples/Frame / 8bits = 144 FrameLength (fl) = bytefactor * (BitRate / SampleRate) + Padding fl = 144 * (128'000 / 44100 ) + Padding = 418 bytes
Framelength may vary within the same file due to different paddings or vbr encoding.
→ http://www.dv.co.yu/mpgscript/mpeghdr.htm
http 1.1 ranges
Support for ranges?
HEAD /test.mp3 HTTP/1.1 Host:blog.var.cc HTTP/1.1 200 OK Date: Sun, 18 Dec 2005 21:09:07 GMT Server: Apache/2.0.54 (Ubuntu) PHP/5.1.1 Last-Modified: Sun, 18 Dec 2005 18:16:00 GMT ETag: "a706f-bacb1-6d309800" Accept-Ranges: bytes Content-Length: 765105 Content-Type: audio/mpeg
Request the first 100 bytes
GET /test.mp3 HTTP/1.1 Host:blog.var.cc Range: bytes=0-100 HTTP/1.1 206 Partial Content Date: Sun, 18 Dec 2005 21:14:29 GMT Server: Apache/2.0.54 (Ubuntu) PHP/5.1.1 Last-Modified: Sun, 18 Dec 2005 18:16:00 GMT ETag: "a706f-bacb1-6d309800" Accept-Ranges: bytes Content-Length: 101 Content-Range: bytes 0-100/765105 Content-Type: audio/mpeg
Requests bytes 0-100 and 200-250. Response body contains range-parts delimited by a boundary.
GET /test.mp3 HTTP/1.1 Host:blog.var.cc Range: bytes=0-100,200-250 HTTP/1.1 206 Partial Content Date: Sun, 18 Dec 2005 21:16:15 GMT Server: Apache/2.0.54 (Ubuntu) PHP/5.1.1 Last-Modified: Sun, 18 Dec 2005 18:16:00 GMT ETag: "a706f-bacb1-6d309800" Accept-Ranges: bytes Content-Length: 351 Content-Type: multipart/byteranges; boundary=40838f1dda9586bd8 --40838f1dda9586bd8 Content-type: audio/mpeg Content-range: bytes 0-100/765105 // binary data --40838f1dda9586bd8 Content-type: audio/mpeg Content-range: bytes 200-250/765105 // binary data
Next1-10/11
