bodom_lx at task3 dot cc

As promised, Dycapo 0.0.2 is out.

Dycapo will be an open client (mobile)/server system that will improve travel experiences of users in a city. The system will let people to define a destination on their mobile phone. DyCaPo will suggest and arrange trips by either using the Public Transport Service or Carpooling volunteers.
That is, DyCaPo will implement full Dynamic Carpooling functionalities as well as static approaches.

More information and download on the official page.

Here are the release notes and the changes since 0.0.1:

RELEASE NOTES
***************
2010-01-10 Daniel Graziotin 
Dycapo 0.0.2 is just for _showing_out_some_functionalities_ of the system and testing the underlying technologies. Dycapo 0.0.2 incorporates and shows:
* OpenTrip Core adoption and OpenTrip Dynamic data structures proposal (in Django Model format)
* Use of XML-RPC with Django (rpc4django over HTTP and HTTPS)
* (Sort of) integration of Dycapo models with Django and rpc4django
* Authentication
* Insertion of a trip by a driver
* Start of a trip by a driver
* Search of a trip by a rider
* Send a ride request to a driver
* Let the driver accept the ride request
No one exported XML-RPC function will surely be included in the final API! No one exported XML-RPC function is either optimized or completely working!
Code is (somewhat) documented. Expect a completely better work for 0.1.0 

CHANGES SINCE 0.0.1
***************
Some refactoring to make the code cleaner.
Lots of bugs fixed.
Test suite rewritten and (finally) fully working.

models.py:
- added utility methods (i.e. __unicode__ and to_xmlrpc)
- use of OpenTrip id proposal instead of Django id
- addition of fields to Participation model, regarding a ride request and a request accepted

trip.py:
this module has been splitted in four files:
- driver.py - holds all the XML-RPC methods that a Driver needs.
- rider.py - holds all the XML-RPC methods that a Rider needs.
- commin.py - will hold all the XML-RPC methods shared by Rider and Driver
- utils.py - holds some utility functions.

driver.py (formerly trip.py):
- added check_ride_requests(trip) - checks for ride requests
- added accept_ride_request(trip, person) - for accepting a Rider

rider.py (formerly trip.py):
- added request_ride(trip) - sends a ride request to a trip

tests/:
- Cleaner code and better organization
- Added test_all_simple.py - creates a Driver and a Rider with the same destination as target
- test_all.py - creates 3 drivers and 5 riders with random locations as target

Related posts

• Announcing Dycapo 0.0.1 (0)
• Update: first UML diagrams, some implementation thoughts (0)
• Introduction To Software Testing (0)
• Some systems analyzed, thinking about protocols (0)
• Unipoli (0)

I’m working to Dycapo 0.0.2.
This release will introduce some improvements to the test suites, as well as model enhancements and new methods regarding the paring between riders and an Active trip.
I think I will release it before Sunday.

Related posts

• Dycapo, road to 0.0.1 (0)
• Announcing Dycapo 0.0.2 (1)
• Announcing Dycapo 0.0.1 (0)
• Windows Vista?!?!? (3)
• What is taking me busy – Pomotux! (0)

It’s a pleasure for me to announce Dycapo-0.0.1, the very first release of the project.
Dycapo-0.0.1 is part of the pre-alpha-dontuse releases, to only illustrate some functionalities.
Here are the release notes:

2009-12-26 Daniel Graziotin <daniel DOT graziotin AT gmail DOT com>

Dycapo 0.0.1 is just for showing out some functionalities of the system and
testing the underlying technologies.
Dycapo 0.0.1 incorporates and shows:

• OpenTrip Core adoption and OpenTrip Dynamic data structures proposal (in Django Model format)
• Use of XML-RPC with Django (rpc4django over HTTP and HTTPS)
• (Sort of) integration of Dycapo models with Django and rpc4django
• Authentication
• Insertion of a trip by a driver
• Start of a trip by a driver
• Search of a trip by a rider
• Accepting a ride

No one exported XML-RPC function will surely be included in the final API!
No one exported XML-RPC function is either optimized or completely working!

Code is (somewhat) documented. Expect a completely better work for 0.1.0

You can read much more about Dycapo and download it at Dycapo official project page. Project page also hosts installation instructions and configuration steps.

The research behind Dycapo (Dynamic Carpooling system) is illustrated here.

Related posts

• Announcing Dycapo 0.0.2 (1)
• Unipoli (0)
• Introduction To Software Testing (0)
• BD-review (0)
• About Me (0)

I’m doing some refactoring to the code and writing some useful documentation for the first pre-alpha-dontuse version of Dycapo (a.k.a. DyCaPo – Dynamic CarPooling system).
Dycapo 0.0.1 will only be for illustrating some functionalities of the system and the integration of the technologies.
The following is an explanation of our version codes:

• 0.0.x releases are all pre-alpha-dontuse releases, to only illustrate some functionalities.
  API will likely change very often.
• 0.x.x releases are still alpha-releases, that cover some internal development cycles but have
  important features that will appear on a stable releases. API for the important parts of the
  project will likely not be changed.
• 1.0.0 will be considered a stable release that can be used for testing in a small reality. API
  will be frozen.

Related posts

• Announcing Dycapo 0.0.2 (1)
• Announcing Dycapo 0.0.1 (0)
• BD-shell (0)
• BD-review (0)
• Update: first UML diagrams, some implementation thoughts (0)

I love to be back to Slackware, my very first distribution. However, there are a couple of things that I’m missing from the other more comfortable distributions. From among them, I totally miss Network Manager.
I saw many people asking in forums on how to install Network Manager in Slackware 13.0. There is Wicd, already present in Slackware “repositories”. Every Slackware maniac will tell you that it does the same job of Network Manager, but I don’t agree. It does not always work and is more complicated to be configured than NM.

Anyway, I’m going to explain to Slackware newbies the dirty way to have a fully working Network Manager on Slackware 13.0. This method is totally against Slackware philosophy and will also replace some important libraries of the system! Anyway, the packages being replaced are prepared from the guys behind GNOME SlackBuild, a project to bring Gnome in every Slackware release.
You have two way to have Network Manager in your Slackware: either install the entire Gnome from them (or any other similar project) or use slapt-get against their repositories and just install Network-Manager. Here are the instructions. All the following actions must be performed as root user:

1. Download, install and configure slapt-get. Instructions are provided on their website.
2. Update your system with:
   

   slapt-get –update
   slapt-get –dist-upgrade

3. Add GNOME SlackBuild repository in /etc/slapt-get/slapt-getrc:

   SOURCE=http://mirror.switch.ch/ftp/mirror/gsb/gsb-current/

4. Update the list of available packages and replace some system packages:

   slapt-get –update
   slapt-get –add-keys
   slapt-get –install –reinstall alsa-lib bluez glib2 gtk+2 libwnck

5. Now install Network Manager and its GTK applet:

   slapt-get –install NetworkManager network-manager-applet

6. Be sure that dbus, hal and NetworkManager daemons will be loaded at boot time:

   chmod +x /etc/rc.d/rc.messagebus /etc/rc.d/rc.hald /etc/rc.d/rc.networkmanager

7. Add your user to the plugdev group. Edit /etc/group, find the line

   netdev:x:86:root

   Add your username after root (bodom_lx is my case)

   netdev:x:86:root,bodom_lx

8. You are quite finished now! Log back as normal user and create a startup script for network-manager-applet:

   cd ~/.kde/Autostart/

   Create a file called nm-applet.sh with the following content:

   #!/usr/bin/bash
   nm-applet –sm-disable &

   Give it execution permission:

   chmod +x nm-applet.sh

   .

Reboot your system. Everything should work fine now.

To uninstall Network Manager and restore the system as it was before the installation follow these instructions, as root::

1. remove any GNOME SlackBuild package using:
   

   removepkg /var/log/packages/*gsb

2. Comment GNOME SlackBuild entry in /etc/slapt-get/slapt-getrc:

   #SOURCE=http://mirror.switch.ch/ftp/mirror/gsb/gsb-current/

3. Update your slapt-get sources and re-install the replaced Slackware packages:

   slapt-get –update
   slapt-get –reinstall –install glib2 libwnck alsa-lib gtk+2

4. Toggle execution permission to the auto-started network-manager-applet. Log back as normal user and type:

   chmod -x ~/.kde/Autostart/nm-applet.sh

Feel free to comment any suggestion.

Related posts

• Testing Ubuntu 8.10 (Intrepid Ibex) beta on a Macbook (updated!) (6)
• Fedora 10, thank you very much! (macbook review and fixes) (3)
• gOS 3 Gadgets (Beta) Review (11)
• Pomotux (0)
• Introduction To Software Testing (0)

For those that chose ext4 as default file-system type for their boot partition, and are having problems booting their Slackware 13.0 distribution, I built a .tgz package containing the latest Grub 2 release (currently 1.97-beta4).
It also contains a default grub.cfg file.

Please download the file here: grub-1.97~beta4-i486-1.tgz for Slackware 13.0

It should also work for Slackware 12.x and 11.0.

Enjoy!

P.S. The package is based on the one created for Grub-1.96 by user mbvo on linuxquestions.org. I simply adapted it for Grub-1.97. I also provided a new description for the package and a simpler grub.cfg file.

Related posts

• BD-shell (0)
• Testing Ubuntu 8.10 (Intrepid Ibex) beta on a Macbook (updated!) (6)
• Unipoli (0)
• Publications (0)
• Introduction To Software Testing (0)