To help contribute to the Erlang community I've published my hacks over xmlrpc Erlang library.
This library has already received various patches that you can found around the web. I've decided to rather build a repository in the hope that it might drains contributions and help keep this library alive.
October 16, 2009
October 10, 2009
AppEngine next language ?
Python, Java, ...
Java also opened the door for JRuby. The next language could be a less generic one. The upcoming Wave service powered over XMPP and suggesting OpenFire server for support could well be the application killer boosting Erlang language via a server like ejabberd.
Erlang is opensource, powered by a virtual machine, highly suitable for network oriented applications. Surely the community around the language is sparse but it's gaining more and more interest as people face threading problems.
Java also opened the door for JRuby. The next language could be a less generic one. The upcoming Wave service powered over XMPP and suggesting OpenFire server for support could well be the application killer boosting Erlang language via a server like ejabberd.
Erlang is opensource, powered by a virtual machine, highly suitable for network oriented applications. Surely the community around the language is sparse but it's gaining more and more interest as people face threading problems.
September 18, 2009
Mind the limits !
Running load simulator programs from linux might lead you to a limit ! This limit is often met through messages like :
or in Erlang a more criptic message for the newbie :
It means you've bump on the hard limit of opened files by processes.
Changing the values in /etc/limits.conf or /etc/security/limits.conf will allow you to raise those limits.
Don't forget to close all your shell sessions to allow the system to effectively raise the limit !
Too many opened files
or in Erlang a more criptic message for the newbie :
{{badmatch,{error,emfile}},[{gen_tcp....It means you've bump on the hard limit of opened files by processes.
Changing the values in /etc/limits.conf or /etc/security/limits.conf will allow you to raise those limits.
Don't forget to close all your shell sessions to allow the system to effectively raise the limit !
May 2, 2009
OOPHM mode with GWT on OSX
Suffice to say that UsingOOPHM and building GWT from source allows to launch this mode
via
via
ant oophmThe behaviour of the interface is a little bit rough on the edges though on OSX.
Building GWT from SVN on OSX
Building GWT from svn trunk is documented in Making GWT Better.
But the compile process invoke a nasty parsing of svn info command which fails if your langage setting is not english.
You'll find that in build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java :
This pattern fails miserably on svn info like this :
I had to switch form iTerm to Terminal to achieve a good setup of my environment to achieve a sucessful building.
In Terminal preferences uncheck the LANG setting flag and in your shell do
This should be enough to build GWT successfully !
PS: Pay attention to not interfere with JDK 1.6 if you have it installed on your machine.
But the compile process invoke a nasty parsing of svn info command which fails if your langage setting is not english.
You'll find that in build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java :
/**
* A pattern that matches the Repository Root line in svn info output.
*/
private static final Pattern ROOT_PATTERN =
Pattern.compile("\\s*Repository Root:\\s*(" + URL_REGEX + ")\\s*");
This pattern fails miserably on svn info like this :
Chemin : .
URL : http://google-web-toolkit.googlecode.com/svn/trunk
Racine du dépôt : http://google-web-toolkit.googlecode.com/svn
UUID du dépôt : 8db76d5a-ed1c-0410-87a9-c151d255dfc7
Révision : 5320
Type de noeud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : jgw@google.com
Révision de la dernière modification : 5320
Date de la dernière modification: 2009-05-01 22:23:02 +0200 (Ven, 01 mai 2009)
I had to switch form iTerm to Terminal to achieve a good setup of my environment to achieve a sucessful building.
In Terminal preferences uncheck the LANG setting flag and in your shell do
export LANG=en_US
ant
This should be enough to build GWT successfully !
PS: Pay attention to not interfere with JDK 1.6 if you have it installed on your machine.
September 13, 2005
Ajax libraries
Jean-Marc Orliaguet jmo at ita.chalmers.se on Z3lab mailing-list Thu Jul 14 21:26:20 CEST 2005
Hi!
I've been testing various "Ajax" libraries recently and these are my
impressions (they correspond to the use cases that I have, others
certainly have other needs):
- first of all there is a lot of buzz around Ajax, when you start
looking for an Ajax framework you are likely to find all sorts of
libraries that do just anything on earth: drag-and-drop, visual
effects, animations, sortable lists; they belong to the "Application
framework" category.
Then there are the XMLHttpRequest wrapper libraries (belonging to the so
called "Infrastructure framework" category).
- some of the libraries are meant to be kept simple and lightweight,
others are really heavy-weight libraries. The Rico [1] / Prototype [2]
libs for instance take a lot of CPU on every page load (up to 3 or 4
seconds depending on your hardware). You really feel it when you tune
down your CPU to 800MHz. Obviously you are not supposed to reload the page.
- for drag-and-drop stuff, contextual menus, etc. I find that PDLib [7]
is just fine for what I need. It has the advantage compared to the other
libraries that I've seen so far to refer to classes of elements as
opposed to a collection of element Ids. The Rico lib [2] and
script.aculo.us [3] for instance need to register as many Ids as there
draggable and droppable elements. With PDLib, you just have to declare a
CSS class as draggable and a class as droppable. That makes a difference
when you have lots of elements on a page. The only problem with the
PDLib library is that there are a lots of versions around. I have done
some local modifications on it for CPSSkins [8] with bug fixes from
CompositePack [9], etc.
- By the way: what does drag-and-drop have to do with AJAX?
drag-and-drop has been around for years... My impression is that it is
better to keep the XMLHttpRequest part separate from the fancy stuff.
- So the next question is: what is the core functionality you'd expect
from an "Ajax" JS library? I've done a list of use cases for cpsskins
and it all comes down to one thing: being able to send requests to the
server and getting the result of the request inserted into the page in a
given place without reloading the page.
- An important factor is that it should go fast, so I started to look to
'lightweight' libraries [5] [6] with the minimum number of features
implemented. Sarissa [4] has a lot of XML/XSLT features that I feel
could as well be implemented in zope and that I presently have little
need for.
So I tested 'DataRequestor.js' [5] which is exactly what I need (simple
to use and fast).
- I've set up a test / demo page that updates a fragment of a page with
the date fetched from zope every time the uses clicks on the button:
http://cvs.ita.chalmers.se:8980/ajax/demo
- Conclusion: be careful with the buzz that surrounds Ajax, identify the
needs of your application, do benchmarks.
I hope that this review can be useful.
regards
/JM
References:
-----------------
[1] http://openrico.org/demos.page - rico.js (69kB ...) + prototype.js
(28kB)
[2] http://prototype.conio.net/ - prototype.js (28kB)
[3] http://script.aculo.us/ - dragdrop.js (19kB) - effects.js (21kB) +
prototype.js (28kB)
[4] http://sarissa.sourceforge.net/doc/ - sarissa.js (27kB)
[5] http://mikewest.org/projects.php?action=viewProject&projectID=1 -
DataRequestor.js (16kB / documentation included - 6.4kB without the doc)
[6] http://xkr.us/code/javascript/XHConn/ XHConn.js (1.4kB)
[7] http://svn.zope.org/pdlib/trunk/
[8]
http://svn.nuxeo.org/trac/pub/file/CPSSkins/trunk/skins/CPSSkins/cpsskins_pdlib.js.dtml
[9] http://plone.org/products/compositepack
Hi!
I've been testing various "Ajax" libraries recently and these are my
impressions (they correspond to the use cases that I have, others
certainly have other needs):
- first of all there is a lot of buzz around Ajax, when you start
looking for an Ajax framework you are likely to find all sorts of
libraries that do just anything on earth: drag-and-drop, visual
effects, animations, sortable lists; they belong to the "Application
framework" category.
Then there are the XMLHttpRequest wrapper libraries (belonging to the so
called "Infrastructure framework" category).
- some of the libraries are meant to be kept simple and lightweight,
others are really heavy-weight libraries. The Rico [1] / Prototype [2]
libs for instance take a lot of CPU on every page load (up to 3 or 4
seconds depending on your hardware). You really feel it when you tune
down your CPU to 800MHz. Obviously you are not supposed to reload the page.
- for drag-and-drop stuff, contextual menus, etc. I find that PDLib [7]
is just fine for what I need. It has the advantage compared to the other
libraries that I've seen so far to refer to classes of elements as
opposed to a collection of element Ids. The Rico lib [2] and
script.aculo.us [3] for instance need to register as many Ids as there
draggable and droppable elements. With PDLib, you just have to declare a
CSS class as draggable and a class as droppable. That makes a difference
when you have lots of elements on a page. The only problem with the
PDLib library is that there are a lots of versions around. I have done
some local modifications on it for CPSSkins [8] with bug fixes from
CompositePack [9], etc.
- By the way: what does drag-and-drop have to do with AJAX?
drag-and-drop has been around for years... My impression is that it is
better to keep the XMLHttpRequest part separate from the fancy stuff.
- So the next question is: what is the core functionality you'd expect
from an "Ajax" JS library? I've done a list of use cases for cpsskins
and it all comes down to one thing: being able to send requests to the
server and getting the result of the request inserted into the page in a
given place without reloading the page.
- An important factor is that it should go fast, so I started to look to
'lightweight' libraries [5] [6] with the minimum number of features
implemented. Sarissa [4] has a lot of XML/XSLT features that I feel
could as well be implemented in zope and that I presently have little
need for.
So I tested 'DataRequestor.js' [5] which is exactly what I need (simple
to use and fast).
- I've set up a test / demo page that updates a fragment of a page with
the date fetched from zope every time the uses clicks on the button:
http://cvs.ita.chalmers.se:8980/ajax/demo
- Conclusion: be careful with the buzz that surrounds Ajax, identify the
needs of your application, do benchmarks.
I hope that this review can be useful.
regards
/JM
References:
-----------------
[1] http://openrico.org/demos.page - rico.js (69kB ...) + prototype.js
(28kB)
[2] http://prototype.conio.net/ - prototype.js (28kB)
[3] http://script.aculo.us/ - dragdrop.js (19kB) - effects.js (21kB) +
prototype.js (28kB)
[4] http://sarissa.sourceforge.net/doc/ - sarissa.js (27kB)
[5] http://mikewest.org/projects.php?action=viewProject&projectID=1 -
DataRequestor.js (16kB / documentation included - 6.4kB without the doc)
[6] http://xkr.us/code/javascript/XHConn/ XHConn.js (1.4kB)
[7] http://svn.zope.org/pdlib/trunk/
[8]
http://svn.nuxeo.org/trac/pub/file/CPSSkins/trunk/skins/CPSSkins/cpsskins_pdlib.js.dtml
[9] http://plone.org/products/compositepack
August 5, 2005
The amazing web
Who can image what the web will look like in two years ?
If you look back in time on what the web look like in 2002-2003...
Where Google was ?
If you look back in time on what the web look like in 2002-2003...
Where Google was ?
Subscribe to:
Posts (Atom)