Marcos Roriz $:

Pessoal, Geek, Anime, Jogos, Ciência da Computação e Open Source…

How to Install PEAR on Windows 7

with 4 comments

I’ve just installed Windows 7 and one of the main problems is that I can’t get PEAR to work. So after lots of googling here is the solution to get it working:

  1. Uncomment the line in your php.ini file and set it to off:
     phar.require_hash = Off 
  2. Now as a admin start the cmd prompt and run go-pear.bat in the php dir (It will complain about Structures Graph).
  3. Now go to PEAR website and download manually the Structures Graph package.
  4. Extract the content of the package and move the Structures folder to the PEAR directory.
  5. Issue “pear install Structures_Graph”. Even though the files are present, Structures_Graph is not really installed unless you issue the above command.
     pear install Structures_Graph 


  6. Issue “pear upgrade PEAR”. This upgrades PEAR itself to the current version.
     pear upgrade PEAR 


  7. Issue “pear upgrade Console_Getopt”. This upgrades Console_Getopt to the current version.
     pear upgrade Console_Getopt 

Problem solved by: jjkramer @

Written by marcosroriz

February 20, 2011 at 10:17 am

Posted in Open Source, Windows

Tagged with

FISL, I was there \o/

with one comment

Hello guys, well when I applied to Google Summer of Code I had no idea on how it was going to change my life. So far not only I have been learning new things, but also meeting awesome developers. The climax of this was when we (brazillian students) asked for a small financial help to Google to take us to FISL (Forum Internacional de Software Livre – International Free Software Forum) in Brazil. Google did the amazing favor to help us so that we can learn/spread free software to others. We are in huge debt with them, and we’re amazed by their concerns about free software ideals. We managed not only to meet there (#gsoc-br) but also we managed to meet excellent FOSS developers there and had a lecture about the GsoC experience in FISL.

There I met the remaining gsocers, we shared our difficulties and we exchanged tips on how to solve problems. They all joked on me, :/, when I said that I preferred svn over dscm, like git or mercurial. But at the same time they gave me a very brief and informal talk/introduction to git (which I’m kinda liking :D). I talked also a lot about X and XCB with friend and hackers there since it’s directly related to my proposal.


I had a chance to meet some badass developers (like ‘Maddog’) and get amazing talks (like Glassfigh in OSGi bundles and What’s new on OpenJDK 7). I took some photos and the most cool was with the GNU.

Overall, It was a amazing experience, and I want to thank again Google, specially Carol (which is so kind =]), all the cool guys there (FISL) and my mentor Mario Torre (which understand that I’m a little behind but getting up the schedule now =).

GNU and Me

GNU and Me

Written by marcosroriz

July 27, 2010 at 2:14 pm


leave a comment »

Hello guys, sorry for the lack of updates, been a busy week here.
The progress so far is that I’m ending up the refactoring in Escher (already finished the core java pkgs) which lend me changing almost all classes in XPeer @ GNU Classpath, I’m waiting right now to submit this patch and some review of my mentor (Mario Torre) so I can make it a best refactoring.
So far:

  • Reintegrated Escher to XPeer @ GNU Classpath (First task)
  • Refactored Escher (Almost finishing)
  • Next → Generate the protocol code in a description way (Mario Torre gave the huge cool idea in generating on @nnotations :D)

One of the things that I changed in XPeer too was the lazy connection. IMHO there is no need to wait for someone to getDisplay() to make all the overhead of connecting to the Xserver. Since usually after the instantiation of the Xtoolkit class there will be use it I did the start right ahead. This change made *somehow* the start of the gui way faster. Am I missing the reason behind lazy connection?

Written by marcosroriz

July 3, 2010 at 6:57 pm

Delete or keep is the question.

leave a comment »

Hello guys, I’ve stumbled up on some tricky code here in Escher. More exactly theres a lot of parts that are *important* but are not used on the code, like this one:

 // Can be removed
 public static float [] linearize (float [] [] src) {
   int s1 = src [0].length;
   int s2 = src.length;
   float [] dst = new float [s1 * s2];

   for (int i=0; i<s2; i++) {
     int offset = i * s1;
     System.arraycopy (src [i], 0, dst, offset, s1);
   return dst;

  // Can't be removed
  public static float [] linearize (float [] [] [] src) {
    int s1 = src [0] [0].length;
    int s2 = src [0].length;
    int s3 = src.length;
    float [] dst = new float [s1 * s2 * s3];

    for (int i=0; i<s3; i++)
      for (int j=0; j<s2; j++) {
        int offset = s1 * (j + s2 * i);
        System.arraycopy (src [i] [j], 0, dst, offset, s1);
    return dst;

This method is part of the Misc class (which contains ‘handy’ methods for vector/graphic manipulation). So the question is, while this method does have it’s meaning in the program it’s not used anywhere on it. And to complicate it more the ‘same’ method with a different argument (3 dimension array) is used in the code. Should I remove it the unused??? I’m not totally sure but I think if they are not used we should remove it >_<‘. And that what I’ll probably do on my next commit. What you guys think? Should I keep or delete? :3

Other problems is that in general the classes uses a lot of public and static variables/methods, I’m doing some basic encapsulation on it. Also my next commit will include a revision/refactoring of the glorious gnu.x11.Display class with it’s > 1.4k lines of code. After I finish it’s refactoring the other classes will be easier, since they are usually < 200 lines of code. After classes refactoring is done is time to start going for the parser to generate automatic X11 code, the coolest part!

To sum it up I also received the confirmation that I can now commit oficially to GNU Classpath, so now I can submit code to XPeer there ^_^. Mr. Donald R. Robertson, III, J.D. sended me the confirmation. I’m honored to be able to contribute to a GNU project :]

Accepted by FSF =D~

PDF of the agreement

Written by marcosroriz

June 17, 2010 at 10:37 pm

GSoC Updates

with 2 comments

First of all I would like to apologize for my lack of attention with GSoC this week it was basically because my university (UFG) sent us to a coding week in other one (UFPB). To make that time lost up I’ll work double until the program end. I’ll everyday post here about what I’m refactoring and how I’m doing this stuff, and how I’m applying the corrections that Mario Torre is giving me. So to not lose some time I’ll post today some basic AWT Relationship (which explains Escher) and the class refactoring that I’m working right know (gnu.x11.Display).

AWT Relationship

Java has by default at least one AWT (Abstract Window Toolkit) implementation, which enables various ways to manipulate GUI in general (graphics/events). Everything starts with Toolkit which is a abstract class that defines the basic functionality of a rendering kit, that is a AWT. To add extra functionality GNU Classpath subclass the Toolkit into ClasspathToolkit which basically add extra methods for extra information, such as, getting all truetype fonts available on the system. The same process, sub-classing and adding extra methods, happens on OpenJDK but is called SunToolkit.

Now we need peers to make the communication with the toolkit (Gtk, Qt, X11) and Java. We basically have a bunch of implementation making calls to their respective peer, usually using JNI to call the C/C++ code. The X11 toolkit is special in a sense that it doesn’t need a full desktop environment to run, it needs only a X11 Server. Escher is the implementation of the X11 peer written totally in Java. It send and receive requests from the X11 Server and repass to Java. Since Escher is written totally in Java and the X11 peer don’t need a full desktop environment it makes perfect sense to use it on a embedded device that needs a low memory footprint. To sum up Escher like any X client can handle extension, in fact it already implemented the famous GLX extension which allow a client (application) to use OpenGL inside a X11 window.

AWT <--> Escher Relationship

Tomorrow I’ll bring some of the refactoring that I’m doing…

Sleeeeep ZZZZzzzZZ

Written by marcosroriz

June 14, 2010 at 1:27 am

GNU Classpath/Escher and GSoC

with one comment

Hello everyone,

First of all, most of my posts will now be written on English. After all, the main reason for this change is to reach a higher number of users, as English is considered the universal language these days. The other reason is that I’m currently participating on Google Summer of Code for the GNU Classpath project. I’ll post here my progress on the program, including achievements, solutions to problems and future ideas. So to start off, I’m going to present you what is and what I’m doing for GNU Classpath.

GNU Classpath is a free software implementation of the Java standard library. Ok, what does that means? It’s a implementation of the standard Java API, things like Swing, Socket, Math, FileOutputStream, RMI and so on. It’s not a Java Runtime, i.e., it’s doesn’t do memory management, security, etc. The Java Runtime uses these class library to run the application. A full JVM according to Sun/Oracle standards is the sum of the class library and these runtime algorithms. Since the JVM is majority written in Java (classlib) the runtime implements very low-level things in C, like garbage collection.

Now a brief history of GNU Classpath. In the old days there were a bunch of FOSS projects that had a implementation of the runtime and the standard class library. Since each project implemented the same classes over and over, this turned out to become a incomplete and redundant implementation of the standard class library. So they united their efforts to produce ‘one’ class library, which is GNU Classpath. And they all implemented their runtime algorithms to manipulate this library. Cacao, Jikes, JamVM, Jamaica, IKVM, all this and others free JVM’s are used with GNU Classpath.

GNU Classpath Logo

GNU Classpath Logo

“Revive and Restructure the Escher project”. This is my GsoC task/proposal title. So what is this Escher? What’s the relationship with GNU Classpath? Escher is basically a client for the X Window System (X11) written entirely in Java. It was started and developed by Mario Torre (my mentor), Roman Kennke and Stephen Tse, they are all nice guys. Back to the story, inside GNU Classpath we have various graphics peers, including GTK, Qt and XPeer (which uses Escher). They all send requests to a X Server, when they are demanded to draw something, such as a Box or a Font. The Gtk is the default peer, Qt and XPeer is also dead. The thing here is to revive XPeer which basically means reviving Escher also, since both projects are intimately related. But why XPeer, what does it have that the other peers don’t? It’s because XPeer communicates directly with a X Server standalone. This is useful specially on a embedded scenario. These devices usually, almost all ways, doesn’t have a Gtk/Qt-Peer. So I’ll be doing a synchronization with the development of GNU Classpath, refactoring XPeer and Escher with design patterns and also start decoupling Escher for other back-ends, such as DirectFB. The coolest part is that GNU Classpath is on various architectures ranging from ARM to SPARC so we can manipulate graphics on all these architectures.

I’m very anxious/excited with GSoC. My mentor (Mario Torre) is really cool and he is very patient on teaching (he the most patient/kind FOSS developer ever!). He’s also the most badass developer that I’ve seen :D. The other guys from the channel are all kind/patient too. They are all awesome! I’m really excited with GNU Classpath/Escher with these guys! Tomorrow I’ll post more of what I’ve already done (this is the first week of coding), including the patches for synchronization, some refactoring and the repository that I’m using. From now on I’ll post here my progress :).

Written by marcosroriz

May 31, 2010 at 1:26 am

ClassLoader desmitificado.

with 3 comments

Até recentemente não dava muita importância no funcionamento da estrutura interna da plataforma Java até quando tive problemas que o Google não conhece. Para resolver meus problemas tive que mergulhar a fundo no interior da JVM. E apesar de ter vários materiais na rede é complicado compreender o linguajar e o funcionamento interno da mesma. Para começar entender o funcionamento do seu programa dentro da Máquina Virtual Java (Java Virtual Machine – JVM) é necessário compreender o coração da JVM  o ClassLoader (CL). De maneira simples, um CL é uma estrutura que tem como responsabilidade o carregamento dos seus bytecodes (.class). Cada ClassLoader contém o que ela pode carregar no seu classpath específico, isso é, o endereço (diretórios) das classes. Um classpath pode conter vários diretórios, sendo assim o CL irá procurar a classe no primeiro diretório especificado, se não achar irá pro segundo, assim suscetivamente até acabar a lista de diretórios do classpath. Porém o mais importante é entender como o CL carrega as suas classes e como ele é organizado internamente.

Antes de mais nada é necessário explicar que um tipo (classe) em java é identificado pelo seu nome e seu CL. Ou seja um objeto da classe Folha de CL 0x2bbd86 é diferente de um objeto da classe Folha de CL 0x813b2 pois apesar de serem da mesma classe esses possuem CL diferentes. O java faz isso para garantir a consistência de objetos internamente na JVM. Pois caso contrário poderia ocorrer um conflito entre um objeto Folha que representa uma árvore e sua atribuição a um objeto Folha que representa uma folha de pagamento. Ou seja, objetos originados de uma classe de mesmo nome pode não possuir estruturas idênticas.

Também é importante entender o processo chave de carregamento de classe, a delegação. Um ClassLoader possui ClassLoader pais e sempre irá fazer o seguinte:

  • A Classe sempre irá pedir a ClassLoader que o carregou para carregar suas dependências;
  • ClassLoader sempre irá delegar o carregamento da classe ao seu pai, para verificar se o mesmo quer carrregar a classe antes.

Agora iremos explicar a hierarquia dos ClassLoaders. Quando a JVM inicia ela não possui nenhuma classe carregada. A JVM usa o mecanismo de carregamento de classes conhecido como lazyness, preguiçoso, a JVM vai carregando as classes conforme é necessário. Porém existe um problema, o código que carrega uma classe é o ClassLoader que em si é uma classe em Java, se a JVM não possui nenhuma classe carregada como é que ela vai carregar as outras classes pois conforme a especificação Java uma classe só é carregada quando todas as suas dependências forem carregadas. Conforme novamente a especificação Java, ClassLoader herda de Object que em si deve ser carregado por uma ClassLoader o que leva a um dead-lock. A solução para isso é ter um ClassLoader que de fato não é escrito em Java e sim em código nativo. Esse CL nativo irá carregar as classes ClassLoader, AppClassLoader e ExtClassLoader. A árvore de CL é a hierarquia formada pelo agrupamento dos mesmos. Por padrão temos a seguinte hierarquia:

Hierarquia de ClassLoaders

O BootStrap é o CL nativo executado pela JVM o seu classpath encontra as classes do sistema, principalmente o runtime do Java. O ExtCL (Extension ClassLoader) tem como seu classpath frameworks ou aplicativos específicos do usuário, caso queira que esses sejam visíveis em toda a VM. O pai do ExtCL é o BootStrap. E por fim o AppClassLoader que é o CL que irá carregar sua aplicação e seu classpath é o especificado no manifest do jar ou o passado na linha de comando, e o pai desse é o ExtCL.

Faremos uma aplicação para demonstrar os conceitos vistos:

public class Info {
	public static void main(String args[]) {
		System.out.println("Boot class path: " + System.getProperty("sun.boot.class.path"));
		System.out.println("Extension class path: " + System.getProperty("java.ext.dirs"));
		System.out.println("AppClassPath: " + System.getProperty("java.class.path"));

		Info i = new Info();
		System.out.println("\nBoot CL: " + java.lang.Object.class.getClassLoader());
		System.out.println("App ClassLoader: " + i.getClass().getClassLoader());

Resultado obtido:

[marcos@hades AUR]$ java Info
Boot class path: /opt/java/jre/lib/resources.jar:/opt/java/jre/lib/rt.jar:/opt/java/jre/lib/sunrsasign.jar:/opt/java/jre/lib/jsse.jar:/opt/java/jre/lib/jce.jar:/opt/java/jre/lib/charsets.jar:/opt/java/jre/classes
Extension class path: /opt/java/jre/lib/ext:/usr/java/packages/lib/ext
AppClassPath: .

Boot CL: null
App ClassLoader: sun.misc.Launcher$AppClassLoader@19134f4

Desse resultado podemos claramente ver o que foi explicado, o classpath do BootStrap é o “SDK” do Java, o do ExtClassLoader é o diretório de extensões e o da AppClassLoader é o passado no argumento na cli, caso não tenha sido passado ele assume que é o diretório local: ., ou lido do manifest do jar. E também vemos que quem carregou nossa classe principal foi o AppClassLoader. Também vemos que o bootstrap CL é representado por null.

Bem você já deve ter adivinhado por agora que somente esses três CL são pré-definidos sendo assim nós podemos adicionar e alterar classloaders nessa árvore. Isso garante flexibilidade e isolamento de código, algo muito utilizado em Servidores de Aplicação como o JBoss e Glassfish. O servidor vai isolar cada requisição criando classloader de modo que uma requisição não seja visível na “árvore” a outra, isso garante uma robustez e segurança muito grande a plataforma.

Outro grande exemplo da manipulação de classloaders é o escopo estático de uma variável. Uma variável tem seu escopo estático, isso é, visibilidade, do CL  que foi carregado pra baixo. Vejamos um exemplo abaixo:

public class EscopoEstatico {
	public static int instanceCount = 0;
	public EscopoEstatico() {
		System.out.println("Valor da instancia:" + ++instanceCount);

	public static void main (String args[]) throws Exception {
		new EscopoEstatico();
		// Vamos criar um Cl novo e colocalo abaixo do bootstrap
		// Consequentemente a variavel static vai ser diferente lá
		// do que a especificada.
		URL urlArray = {new File(System.getProperty("user.dir")).toURL() };
		URLClassLoader cl = new URLClassLoader(urlArray, null);


[marcos@hades AUR]$ java EscopoEstatico
Valor da instancia:1
Valor da instancia:1

O que fizemos pode ser visualizado na imagem abaixo:
O problema é que a variável estática não está definida no caminho definido pelo o outro CL, então é considerado um novo “escopo”.

Então um dos problemas que pode surgir é, dado que eu carrego uma requisição em classloaders diferente e de modo que os mesmos não tenham nenhum CL em Comum, todos sejam filhos de null como garantir a visibilidade dó código ao longo da JVM? Bem o que sabemos é que todos diretamente ou indiretamente tem um CL em comum, o CL bootstrap (null). Porém esse CL só carrega os runtimes da plataforma Java, por padrão. Poucos sabem que podemos editar, adicionar, sobrescrever o classpath do BootStrap. Você pode até mesmo sobrescrever a implementação de uma classe que não gosta do JDK, como a implementação da pilha, etc. Concluindo, a ideia é estender os jars visíveis a este adicionando os arquivos que você queria que seja visível na JVM inteira. Isso é feito utilizando as opções X (extended) da JVM.

[marcos@hades AUR]$ java -X
    -Xmixed           mixed mode execution (default)
    -Xint             interpreted mode execution only
    -Xbootclasspath:<directories and zip/jar files separated by :>
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:<directories and zip/jar files separated by :>
                      append to end of bootstrap class path
    -Xbootclasspath/p:<directories and zip/jar files separated by :>

Como disse anteriormente você pode sobrescrever (-Xbootclasspath) ou adicionar no começo (/p de prefix) ou no fim (/a de append) jars ao classpath do Bootstrap. Você pode até mesmo sobrescrever classes do JDK. Vejamos um exemplo abaixo:

Copie o arquivo do source do jdk (java/lang) e modifique seu construtor

public class Integer {
    public Integer(int value) {
		System.out.println("Vou dividir seu int por 2, pq sou mau =P");
		System.out.println("VALOR ANTES: " + value + " VALOR DEPOIS " + value/2 + "\n");
		this.value = value / 2;

Crie um diretório temporário, como ~/temp e também crie ~/temp/java/lang. Note que ~ representa o diretório home do usuário.
Compile o arquivo e copie o seus .class’s para o seguinte diretório, ~/temp/java/lang.
Agora vamos fazer um simples teste.

public class Teste {
	public static void main(String args[]) {
		new Integer(33);

Compile e coloque esse arquivo no diretório ~/temp.
Agora execute a seguinte linha de comando:

[marcos@hades AUR]$ java -Xbootclasspath/p:. Teste
Vou dividir seu int por 2, pq sou mau =P

Vou dividir seu int por 2, pq sou mau =P

Vou dividir seu int por 2, pq sou mau =P

Vou dividir seu int por 2, pq sou mau =P

Vamos chamar agora sem modificar o classpath do bootstrap:

[marcos@hades AUR]$ java Teste

A própria JVM quando inicia executa algumas chamadas criando novos Integers, como podemos ver. Porém o grande resultado é que vemos que o diretório atual, representado por ., foi pré-fixado na classpath do BootStrap e não foi chamado o Integer normal do JDK. Isso garante uma flexibilidade enorme, pois podemos facilmente alterar qualquer implementação não desejada do JDK. Alguns hackers modificavam versões da classe System pois o método getEnv de pegar o PATH do usuário foi depreciado antigamente e não era possível chama-lo até recentemente (acho que adicionaram denovo no jdk 1.5-1.6). Porém a ideia principal é que podemos facilmente garantir uma classe escopo global na JVM colocando seu jar ou .class na lista de classpath do BootStrap.

No próximo tópico irei postar algumas modificações, manipulações e resultados de brincar com os classloaders.

[1] Java Geek, Using the BootClasspath –
[2] Inside the Java Virtual Machine – Bill Vernes – The McGraw-Hill Companies (1997)
[3] Inside Java™ 2 Platform Security: Architecture, API Design, and Implementation, Second Edition By Li Gong, Gary Ellison, Mary Dageforde

Written by marcosroriz

December 16, 2009 at 8:00 pm

Posted in Ciência da Computação, Java

Tagged with ,