31 Oct 2014

feedPlanet Python

Jorgen Schäfer: Elpy 1.6.0 released

I just released version 1.6.0 of Elpy, the Emacs Python Development Environment. This is a feature release.

Elpy is an Emacs package to bring powerful Python editing to Emacs. It combines a number of other packages, both written in Emacs Lisp as well as Python.

Quick Installation

Evaluate this:

(require 'package)
(add-to-list 'package-archives
'("elpy" .
"http://jorgenschaefer.github.io/packages/"))

Then run M-x package-install RET elpy RET.

Finally, run the following (and add them to your .emacs):

(package-initialize)
(elpy-enable)

Changes in 1.6.0

31 Oct 2014 5:56pm GMT

Jorgen Schäfer: Elpy 1.6.0 released

I just released version 1.6.0 of Elpy, the Emacs Python Development Environment. This is a feature release.

Elpy is an Emacs package to bring powerful Python editing to Emacs. It combines a number of other packages, both written in Emacs Lisp as well as Python.

Quick Installation

Evaluate this:

(require 'package)
(add-to-list 'package-archives
'("elpy" .
"http://jorgenschaefer.github.io/packages/"))

Then run M-x package-install RET elpy RET.

Finally, run the following (and add them to your .emacs):

(package-initialize)
(elpy-enable)

Changes in 1.6.0

31 Oct 2014 5:56pm GMT

Europython: EuroPython 2015 Call for Participation: On-site Teams

The EuroPython Society (EPS) is happy to announce the Call for Participation (CFP) for EuroPython 2015. The purpose of this call is to select teams willing to help organize the EuroPython conference on-site at a suitable location.

Introduction

This Call for Participation is meant to collect proposals from teams wishing to help run EuroPython 2015 in a location they are local to. As on-site team, you will be integrated into the new workgroups organizational structure the EPS is currently putting in place to run future EuroPython conferences:

EuroPython Workgroups: Call for Volunteers

The main idea behind this workgroup model is to make sure that tasks which do not need to be done by on-site team members can be implemented by distributed workgroups, that can work remotely and persist from location to location, greatly reducing the loss of institutional knowledge we have seen in recent location switches.

Another major aspect of setting up the EPS workgroups rather than having a structure centered around a local organizer, is to reduce the amount of work and financial risk for the on-site teams. As on-site team you no longer have to enter 5-6 figure Euro contracts for the venue or catering and you don't have to bother with running a website or arranging the conference program. Please note that we still encourage local team members to participate in the workgroups for these tasks, since this simplifies coordination.

The EPS strives to keep the EuroPython conference quality as high as possible, in all of its components. We expect the on-site team to take their proposals very seriously, knowing that they will need to work hard to make the conference a real success.

Timeline for Proposals

The Call for Participation will run until the following deadline for submissions. Proposals must be submitted until midnight UTC on the deadline day, and must adhere the requirements specified in this document. Please make sure to read the whole document carefully.

  • 2014-11-28 - Deadline for submissions (announcement + 4 weeks)
  • 2014-12-05 - Deadline for EPS to review proposals (1 week)
  • 2014-12-12 - Deadline for amended proposals (1 week)
  • 2014-12-26 - Decision on the next EP host (within 2 weeks)

Proposal Workflow

  1. Send your proposal as PDF to the board list: board@europython.eu. This is a private list, so you can include confidential information such as quotes from venues and caterers.

  2. The board will review the proposals and possibly request amendments directly from the submitters. This is done in private between the submitters and the EPS board.

  3. The final version of each proposal will be released to the public after the amendment deadline (with confidential information removed). The EPS will ask to the Python community to provide comments relating to the proposals and take an active role in to discussions.

  4. The final decision for the selection of the on-site team and location will be announced by the EPS board within two weeks after the deadline for amended proposals.

What is EuroPython

EuroPython is the second largest Python conference in the world, right after PyCon US in North America. These are some statistics from EuroPython 2014, to give you an idea of what the on-site team should be ready to handle:

Note that we are open to accepting proposal which can only host fewer attendees, with 600 attendees being the minimum. These numbers are just to give you an idea of how big the EuroPython event has become over the years and how much potential there is for growth.

Please see the EPS EuroPython page for more details on past EuroPython conferences:

http://www.europython-society.org/europython

How EuroPython is run

The EuroPython conference series brand is owned by the EPS. In the past the EPS granted permission to use the brand to local organizers based on a set of requirements, and the local organizing team then had to run the event in collaboration with the EPS.

Since this model no longer scales and doesn't encourage the community to take part in the organization process, we have started a new approach based on workgroups as explained in the document linked to in the introduction. The on-site team will integrate with the other EPS workgroups and be responsible for taking care of the tasks related to the conference organization on site.

Unlike in previous years, and to further reduce the burden on the on-site teams, we will only request the on-site teams to sign up for one year, keeping in mind, of course, that the team may want to submit a follow-up proposal for the next year. The EPS will take such prior knowledge into account when deciding on the proposals.

On-site Team Requirements

These are the requirements the on-site teams signs up to when submitting a proposal. Changes to these requirements are possible, but must be signed off by the EPS board before they can be put in place.

  1. The conference will be financially and legally run by the EPS, so the on-site team does not have to be a legal entity or enter into high-risk contracts.

  2. The on-site team should be geographically located in a specific country within Europe.

  3. The on-site team must be willing to actively coordinate with the EPS board and the other workgroups, so that all parts of the EuroPython ecosystem can work together in a productive way.

  4. The on-site team must be composed of at least 5 active people. We feel that 5 is the bare minimum for the team to successfully handle the amount of work. Please keep in mind that the team is required to grow significantly during the conference days and it's considered an advantage, if the on-site team can show that they already have a good number of volunteers to count on during the conference days.

  5. The on-site team must provide at least 2 available venue options, together with catering options for the venues. Locations must provide room for hosting at least 600 attendees, but please keep in mind that demand for EuroPython is more in the range of 1000+ attendees.

  6. The conference must provide the following services to all attendees. Proposals will have to provide details about how these can be implemented at the proposed venues.

    1. Food and drinks for lunches and breaks on all conference days and the sprints

    2. Optionally, breakfast on all conference days (not necessarily on the sprint days)

    3. WLAN service to access the Internet during the conference and the sprints

    4. At least one social event, which can be a dinner, a show or some other form of entertainment, where food and drinks are served. The main social event should ideally be available to all attendees, but may also be limited to a lower number of people, if the selected venue cannot serve as many participants.

    5. A partner program

    6. Audio/video facilities to support speakers and talk recordings.

  7. The conference must take place within the following timeframe: May 1st - October 31th. The venues have to be available for one week plus a setup day during this timeframe. It is possible to propose more than just one possible conference date, since the costs may vary across this timeframe.

  8. The on-site team will work as on-site workgroup in the context of the EPS (see below for details) and has to follow the same rules as all other workgroups in the EPS. Members of the on-site team should also participate in other workgroups to simplify coordination, e.g. there should be on-site team members in the sponsors workgroup to help the sponsors with booth setups, shipment of goods, customs, etc.

  9. The on-site team will coordinate with the EPS board and workgroups to implement the chosen EuroPython structure. The current structure is: conference days from Monday to Sunday, in which 5 days are used for parallels talks and trainings, and 2 weekend days for sprints.

  10. The on-site team must provide a local expenses budget plan as part of the proposal. A example budget plan can be provided on request. The budget figures will then be used as basis for the conference budget maintained by the EPS and its workgroups, so care has to be taken to provide sound numbers in the budget plan.

  11. The on-site team will receive a budget for the work on site, e.g. to pay for logistics, printing, local service companies, etc. It must work together with the EPS financial workgroup to keep it updated on any spendings and changes in a timely manner. Budget changes must be approved by the EPS board.

  12. The on-site team must be able to provide supporting letters for visa applicants wanting to attend the conference.

Proposal Structure

The proposal must cover all of the following points:

  1. A proposal introduction which describes the motivation for the proposal, underlines the willingness to commit to the needed work and acknowledges the above requirements.

  2. A description of the on-site team, its members and history in the context of their local Python community.

  3. Short biography of the key members and their previous experience in conference and events organizations.

  4. Previous conference history of the on-site team (if any). Describe which conferences were run and provide some figures on their size (registrations, tracks, total income)

  5. Assignment of key positions to on-site team members. Positions to be assigned (one member can be responsible for more than one of the following roles):

    1. Chairperson of the on-site team workgroup: usually also the conference chair and representative of conference for that year

    2. Sponsor manager: on site contact for all sponsor activities, responsible for local sponsors

    3. Venue manager: handling all contacts with the venue and caterer

    4. Logistics manager: handling all aspects of local logistics and customs

    5. Conference desk manager: responsible for the on site help desk, on site registrations, tickets, cash refunds, attendee support, etc.

  6. List of all team members that will be present during the conference itself as volunteers (but not necessarily help before the conference begins), and/or sources from which people can be or will be acquired if needed (eg: universities, other local associations, etc.). This list is indicative, as most of the volunteers helping during the conference are usually enrolled during the last months/weeks before the conference, usually started of through a call for volunteers.

  7. List of potential local sponsors. The EPS manages contacts with international sponsors, but local sponsors also help a lot in funding the conference. These are often smaller companies which will not move to new locations with the conference, so a local contact is highly beneficial in attracting these sponsors.

  8. Proposed dates for EuroPython 2015.

  9. Conference Events. Describe which kind of (social) events you can propose for the conference and are able to provide support for.

  10. Expected differences from previous EuroPython conferences (2013 and 2014). Please highlight what things would need to be changed in the way the conference is run on site. Examples of things we would consider worthwhile to be mentioned:

    1. "We can get additional support from the local government / city council"

    2. "We need to provide tickets to city locals at reduced prices"

    3. "We intend to serve meals in a different venue"

    4. "We have some extra space available for posters / sponsors"

    5. "We want to have our local Python conference run as satellite event"

  1. Venue proposal. Describe the following subitems:

    1. Location, reachability by car, train, plane

    2. Venue floor plans, catering floor plans (if different from venue)

    3. Total capacity for talk rooms, training rooms, plenary sessions, booth space and catering/restaurants; if possible, including room plans

    4. A/V equipment

    5. Video recording, availability of on-site support for A/V recordings, possibly even including live- or post-editing

    6. Lightning equipment, availability of on-site support for lighting

    7. Upstream internet connection (at least 100Mbit/s up and downstream)

    8. WLAN structure, service provider, their experience with similar events (WLAN has to be able to handle more than 1000 devices without problems)

    9. Available space for conference desk, sponsor booths, posters, social event, etc., planned locations of these on the floor plans

  2. Accomodation. Describe the following subitems:

    1. Available hotels/hostels near the conference venues, their distance from the conference venue, city center, airport and train station

    2. Rates for the hotels/hostels and, optionally, special rates which can be made available to attendees

    3. The above for three different categories: high end, average and low end

    4. Optionally, a "main" hotel that serves as default choice for conference attendees and serves as social hub

  3. City tourist information. Describe the following subitems:

    1. General information: touristic information, restaurants, mobility

    2. Travel information: how to get to the city and to the conference venue. This information should indicate how easily the conference city and venue are accessible from across Europe and from overseas. It should also answer questions like: Are there convenient ways to get to the conference venue from airports/trains and bus stations and without having a car/taxi?

    3. Travel costs from the previous mentioned travel hubs to the conference venue

  4. Visa: if attendees may require a visa to enter the country/city, please provide detailed information.

  5. Proposed local budget.

    1. The budget should include all expected costs for the on-site support, including the venue costs, catering, on-site rental of equipment, costs for venue services and logistics, extras like public transport passes, museum/tourist passes, etc. Optional budget positions should be indicated as such, to give more flexibility in comparing proposals.

    2. The budget must handle different scenarios related to different venues, including fixed rooms costs, catering, services, etc. Please provide cost estimates for 600, 800, 1000 and 1200 attendees (if possible with the venue).

    3. Please write to the EPS board if you need help with setting up a budget plan.

  6. Taxes/Legal. If there are special tax/legal requirements in the on-site team's country that require the EPS to register with the local government or pay attention to special regulations, please describe the necessary steps and provide a local accounting/legal contact who can help us work out the details.

Proposal Format

Some things to consider when sending the proposal document.

This Call for Participation (CFP) is also available as PDF file.

Thank you
-
EuroPython Society

31 Oct 2014 3:04pm GMT

Europython: EuroPython 2015 Call for Participation: On-site Teams

The EuroPython Society (EPS) is happy to announce the Call for Participation (CFP) for EuroPython 2015. The purpose of this call is to select teams willing to help organize the EuroPython conference on-site at a suitable location.

Introduction

This Call for Participation is meant to collect proposals from teams wishing to help run EuroPython 2015 in a location they are local to. As on-site team, you will be integrated into the new workgroups organizational structure the EPS is currently putting in place to run future EuroPython conferences:

EuroPython Workgroups: Call for Volunteers

The main idea behind this workgroup model is to make sure that tasks which do not need to be done by on-site team members can be implemented by distributed workgroups, that can work remotely and persist from location to location, greatly reducing the loss of institutional knowledge we have seen in recent location switches.

Another major aspect of setting up the EPS workgroups rather than having a structure centered around a local organizer, is to reduce the amount of work and financial risk for the on-site teams. As on-site team you no longer have to enter 5-6 figure Euro contracts for the venue or catering and you don't have to bother with running a website or arranging the conference program. Please note that we still encourage local team members to participate in the workgroups for these tasks, since this simplifies coordination.

The EPS strives to keep the EuroPython conference quality as high as possible, in all of its components. We expect the on-site team to take their proposals very seriously, knowing that they will need to work hard to make the conference a real success.

Timeline for Proposals

The Call for Participation will run until the following deadline for submissions. Proposals must be submitted until midnight UTC on the deadline day, and must adhere the requirements specified in this document. Please make sure to read the whole document carefully.

  • 2014-11-28 - Deadline for submissions (announcement + 4 weeks)
  • 2014-12-05 - Deadline for EPS to review proposals (1 week)
  • 2014-12-12 - Deadline for amended proposals (1 week)
  • 2014-12-26 - Decision on the next EP host (within 2 weeks)

Proposal Workflow

  1. Send your proposal as PDF to the board list: board@europython.eu. This is a private list, so you can include confidential information such as quotes from venues and caterers.

  2. The board will review the proposals and possibly request amendments directly from the submitters. This is done in private between the submitters and the EPS board.

  3. The final version of each proposal will be released to the public after the amendment deadline (with confidential information removed). The EPS will ask to the Python community to provide comments relating to the proposals and take an active role in to discussions.

  4. The final decision for the selection of the on-site team and location will be announced by the EPS board within two weeks after the deadline for amended proposals.

What is EuroPython

EuroPython is the second largest Python conference in the world, right after PyCon US in North America. These are some statistics from EuroPython 2014, to give you an idea of what the on-site team should be ready to handle:

Note that we are open to accepting proposal which can only host fewer attendees, with 600 attendees being the minimum. These numbers are just to give you an idea of how big the EuroPython event has become over the years and how much potential there is for growth.

Please see the EPS EuroPython page for more details on past EuroPython conferences:

http://www.europython-society.org/europython

How EuroPython is run

The EuroPython conference series brand is owned by the EPS. In the past the EPS granted permission to use the brand to local organizers based on a set of requirements, and the local organizing team then had to run the event in collaboration with the EPS.

Since this model no longer scales and doesn't encourage the community to take part in the organization process, we have started a new approach based on workgroups as explained in the document linked to in the introduction. The on-site team will integrate with the other EPS workgroups and be responsible for taking care of the tasks related to the conference organization on site.

Unlike in previous years, and to further reduce the burden on the on-site teams, we will only request the on-site teams to sign up for one year, keeping in mind, of course, that the team may want to submit a follow-up proposal for the next year. The EPS will take such prior knowledge into account when deciding on the proposals.

On-site Team Requirements

These are the requirements the on-site teams signs up to when submitting a proposal. Changes to these requirements are possible, but must be signed off by the EPS board before they can be put in place.

  1. The conference will be financially and legally run by the EPS, so the on-site team does not have to be a legal entity or enter into high-risk contracts.

  2. The on-site team should be geographically located in a specific country within Europe.

  3. The on-site team must be willing to actively coordinate with the EPS board and the other workgroups, so that all parts of the EuroPython ecosystem can work together in a productive way.

  4. The on-site team must be composed of at least 5 active people. We feel that 5 is the bare minimum for the team to successfully handle the amount of work. Please keep in mind that the team is required to grow significantly during the conference days and it's considered an advantage, if the on-site team can show that they already have a good number of volunteers to count on during the conference days.

  5. The on-site team must provide at least 2 available venue options, together with catering options for the venues. Locations must provide room for hosting at least 600 attendees, but please keep in mind that demand for EuroPython is more in the range of 1000+ attendees.

  6. The conference must provide the following services to all attendees. Proposals will have to provide details about how these can be implemented at the proposed venues.

    1. Food and drinks for lunches and breaks on all conference days and the sprints

    2. Optionally, breakfast on all conference days (not necessarily on the sprint days)

    3. WLAN service to access the Internet during the conference and the sprints

    4. At least one social event, which can be a dinner, a show or some other form of entertainment, where food and drinks are served. The main social event should ideally be available to all attendees, but may also be limited to a lower number of people, if the selected venue cannot serve as many participants.

    5. A partner program

    6. Audio/video facilities to support speakers and talk recordings.

  7. The conference must take place within the following timeframe: May 1st - October 31th. The venues have to be available for one week plus a setup day during this timeframe. It is possible to propose more than just one possible conference date, since the costs may vary across this timeframe.

  8. The on-site team will work as on-site workgroup in the context of the EPS (see below for details) and has to follow the same rules as all other workgroups in the EPS. Members of the on-site team should also participate in other workgroups to simplify coordination, e.g. there should be on-site team members in the sponsors workgroup to help the sponsors with booth setups, shipment of goods, customs, etc.

  9. The on-site team will coordinate with the EPS board and workgroups to implement the chosen EuroPython structure. The current structure is: conference days from Monday to Sunday, in which 5 days are used for parallels talks and trainings, and 2 weekend days for sprints.

  10. The on-site team must provide a local expenses budget plan as part of the proposal. A example budget plan can be provided on request. The budget figures will then be used as basis for the conference budget maintained by the EPS and its workgroups, so care has to be taken to provide sound numbers in the budget plan.

  11. The on-site team will receive a budget for the work on site, e.g. to pay for logistics, printing, local service companies, etc. It must work together with the EPS financial workgroup to keep it updated on any spendings and changes in a timely manner. Budget changes must be approved by the EPS board.

  12. The on-site team must be able to provide supporting letters for visa applicants wanting to attend the conference.

Proposal Structure

The proposal must cover all of the following points:

  1. A proposal introduction which describes the motivation for the proposal, underlines the willingness to commit to the needed work and acknowledges the above requirements.

  2. A description of the on-site team, its members and history in the context of their local Python community.

  3. Short biography of the key members and their previous experience in conference and events organizations.

  4. Previous conference history of the on-site team (if any). Describe which conferences were run and provide some figures on their size (registrations, tracks, total income)

  5. Assignment of key positions to on-site team members. Positions to be assigned (one member can be responsible for more than one of the following roles):

    1. Chairperson of the on-site team workgroup: usually also the conference chair and representative of conference for that year

    2. Sponsor manager: on site contact for all sponsor activities, responsible for local sponsors

    3. Venue manager: handling all contacts with the venue and caterer

    4. Logistics manager: handling all aspects of local logistics and customs

    5. Conference desk manager: responsible for the on site help desk, on site registrations, tickets, cash refunds, attendee support, etc.

  6. List of all team members that will be present during the conference itself as volunteers (but not necessarily help before the conference begins), and/or sources from which people can be or will be acquired if needed (eg: universities, other local associations, etc.). This list is indicative, as most of the volunteers helping during the conference are usually enrolled during the last months/weeks before the conference, usually started of through a call for volunteers.

  7. List of potential local sponsors. The EPS manages contacts with international sponsors, but local sponsors also help a lot in funding the conference. These are often smaller companies which will not move to new locations with the conference, so a local contact is highly beneficial in attracting these sponsors.

  8. Proposed dates for EuroPython 2015.

  9. Conference Events. Describe which kind of (social) events you can propose for the conference and are able to provide support for.

  10. Expected differences from previous EuroPython conferences (2013 and 2014). Please highlight what things would need to be changed in the way the conference is run on site. Examples of things we would consider worthwhile to be mentioned:

    1. "We can get additional support from the local government / city council"

    2. "We need to provide tickets to city locals at reduced prices"

    3. "We intend to serve meals in a different venue"

    4. "We have some extra space available for posters / sponsors"

    5. "We want to have our local Python conference run as satellite event"

  1. Venue proposal. Describe the following subitems:

    1. Location, reachability by car, train, plane

    2. Venue floor plans, catering floor plans (if different from venue)

    3. Total capacity for talk rooms, training rooms, plenary sessions, booth space and catering/restaurants; if possible, including room plans

    4. A/V equipment

    5. Video recording, availability of on-site support for A/V recordings, possibly even including live- or post-editing

    6. Lightning equipment, availability of on-site support for lighting

    7. Upstream internet connection (at least 100Mbit/s up and downstream)

    8. WLAN structure, service provider, their experience with similar events (WLAN has to be able to handle more than 1000 devices without problems)

    9. Available space for conference desk, sponsor booths, posters, social event, etc., planned locations of these on the floor plans

  2. Accomodation. Describe the following subitems:

    1. Available hotels/hostels near the conference venues, their distance from the conference venue, city center, airport and train station

    2. Rates for the hotels/hostels and, optionally, special rates which can be made available to attendees

    3. The above for three different categories: high end, average and low end

    4. Optionally, a "main" hotel that serves as default choice for conference attendees and serves as social hub

  3. City tourist information. Describe the following subitems:

    1. General information: touristic information, restaurants, mobility

    2. Travel information: how to get to the city and to the conference venue. This information should indicate how easily the conference city and venue are accessible from across Europe and from overseas. It should also answer questions like: Are there convenient ways to get to the conference venue from airports/trains and bus stations and without having a car/taxi?

    3. Travel costs from the previous mentioned travel hubs to the conference venue

  4. Visa: if attendees may require a visa to enter the country/city, please provide detailed information.

  5. Proposed local budget.

    1. The budget should include all expected costs for the on-site support, including the venue costs, catering, on-site rental of equipment, costs for venue services and logistics, extras like public transport passes, museum/tourist passes, etc. Optional budget positions should be indicated as such, to give more flexibility in comparing proposals.

    2. The budget must handle different scenarios related to different venues, including fixed rooms costs, catering, services, etc. Please provide cost estimates for 600, 800, 1000 and 1200 attendees (if possible with the venue).

    3. Please write to the EPS board if you need help with setting up a budget plan.

  6. Taxes/Legal. If there are special tax/legal requirements in the on-site team's country that require the EPS to register with the local government or pay attention to special regulations, please describe the necessary steps and provide a local accounting/legal contact who can help us work out the details.

Proposal Format

Some things to consider when sending the proposal document.

This Call for Participation (CFP) is also available as PDF file.

Thank you
-
EuroPython Society

31 Oct 2014 3:04pm GMT

EuroPython Society: EuroPython 2015 Call for Participation: On-site Teams

The EuroPython Society (EPS) is happy to announce the Call for Participation (CFP) for EuroPython 2015. The purpose of this call is to select teams willing to help organize the EuroPython conference on-site at a suitable location.

Introduction

This Call for Participation is meant to collect proposals from teams wishing to help run EuroPython 2015 in a location they are local to. As on-site team, you will be integrated into the new workgroups organizational structure the EPS is currently putting in place to run future EuroPython conferences:

EuroPython Workgroups: Call for Volunteers

The main idea behind this workgroup model is to make sure that tasks which do not need to be done by on-site team members can be implemented by distributed workgroups, that can work remotely and persist from location to location, greatly reducing the loss of institutional knowledge we have seen in recent location switches.

Another major aspect of setting up the EPS workgroups rather than having a structure centered around a local organizer, is to reduce the amount of work and financial risk for the on-site teams. As on-site team you no longer have to enter 5-6 figure Euro contracts for the venue or catering and you don't have to bother with running a website or arranging the conference program. Please note that we still encourage local team members to participate in the workgroups for these tasks, since this simplifies coordination.

The EPS strives to keep the EuroPython conference quality as high as possible, in all of its components. We expect the on-site team to take their proposals very seriously, knowing that they will need to work hard to make the conference a real success.

Timeline for Proposals

The Call for Participation will run until the following deadline for submissions. Proposals must be submitted until midnight UTC on the deadline day, and must adhere the requirements specified in this document. Please make sure to read the whole document carefully.

  • 2014-11-28 - Deadline for submissions (announcement + 4 weeks)
  • 2014-12-05 - Deadline for EPS to review proposals (1 week)
  • 2014-12-12 - Deadline for amended proposals (1 week)
  • 2014-12-26 - Decision on the next EP host (within 2 weeks)

Proposal Workflow

  1. Send your proposal as PDF to the board list: board@europython.eu. This is a private list, so you can include confidential information such as quotes from venues and caterers.

  2. The board will review the proposals and possibly request amendments directly from the submitters. This is done in private between the submitters and the EPS board.

  3. The final version of each proposal will be released to the public after the amendment deadline (with confidential information removed). The EPS will ask to the Python community to provide comments relating to the proposals and take an active role in to discussions.

  4. The final decision for the selection of the on-site team and location will be announced by the EPS board within two weeks after the deadline for amended proposals.

What is EuroPython

EuroPython is the second largest Python conference in the world, right after PyCon US in North America. These are some statistics from EuroPython 2014, to give you an idea of what the on-site team should be ready to handle:

Note that we are open to accepting proposal which can only host fewer attendees, with 600 attendees being the minimum. These numbers are just to give you an idea of how big the EuroPython event has become over the years and how much potential there is for growth.

Please see the EPS EuroPython page for more details on past EuroPython conferences:

http://www.europython-society.org/europython

How EuroPython is run

The EuroPython conference series brand is owned by the EPS. In the past the EPS granted permission to use the brand to local organizers based on a set of requirements, and the local organizing team then had to run the event in collaboration with the EPS.

Since this model no longer scales and doesn't encourage the community to take part in the organization process, we have started a new approach based on workgroups as explained in the document linked to in the introduction. The on-site team will integrate with the other EPS workgroups and be responsible for taking care of the tasks related to the conference organization on site.

Unlike in previous years, and to further reduce the burden on the on-site teams, we will only request the on-site teams to sign up for one year, keeping in mind, of course, that the team may want to submit a follow-up proposal for the next year. The EPS will take such prior knowledge into account when deciding on the proposals.

On-site Team Requirements

These are the requirements the on-site teams signs up to when submitting a proposal. Changes to these requirements are possible, but must be signed off by the EPS board before they can be put in place.

  1. The conference will be financially and legally run by the EPS, so the on-site team does not have to be a legal entity or enter into high-risk contracts.

  2. The on-site team should be geographically located in a specific country within Europe.

  3. The on-site team must be willing to actively coordinate with the EPS board and the other workgroups, so that all parts of the EuroPython ecosystem can work together in a productive way.

  4. The on-site team must be composed of at least 5 active people. We feel that 5 is the bare minimum for the team to successfully handle the amount of work. Please keep in mind that the team is required to grow significantly during the conference days and it's considered an advantage, if the on-site team can show that they already have a good number of volunteers to count on during the conference days.

  5. The on-site team must provide at least 2 available venue options, together with catering options for the venues. Locations must provide room for hosting at least 600 attendees, but please keep in mind that demand for EuroPython is more in the range of 1000+ attendees.

  6. The conference must provide the following services to all attendees. Proposals will have to provide details about how these can be implemented at the proposed venues.

    1. Food and drinks for lunches and breaks on all conference days and the sprints

    2. Optionally, breakfast on all conference days (not necessarily on the sprint days)

    3. WLAN service to access the Internet during the conference and the sprints

    4. At least one social event, which can be a dinner, a show or some other form of entertainment, where food and drinks are served. The main social event should ideally be available to all attendees, but may also be limited to a lower number of people, if the selected venue cannot serve as many participants.

    5. A partner program

    6. Audio/video facilities to support speakers and talk recordings.

  7. The conference must take place within the following timeframe: May 1st - October 31th. The venues have to be available for one week plus a setup day during this timeframe. It is possible to propose more than just one possible conference date, since the costs may vary across this timeframe.

  8. The on-site team will work as on-site workgroup in the context of the EPS (see below for details) and has to follow the same rules as all other workgroups in the EPS. Members of the on-site team should also participate in other workgroups to simplify coordination, e.g. there should be on-site team members in the sponsors workgroup to help the sponsors with booth setups, shipment of goods, customs, etc.

  9. The on-site team will coordinate with the EPS board and workgroups to implement the chosen EuroPython structure. The current structure is: conference days from Monday to Sunday, in which 5 days are used for parallels talks and trainings, and 2 weekend days for sprints.

  10. The on-site team must provide a local expenses budget plan as part of the proposal. A example budget plan can be provided on request. The budget figures will then be used as basis for the conference budget maintained by the EPS and its workgroups, so care has to be taken to provide sound numbers in the budget plan.

  11. The on-site team will receive a budget for the work on site, e.g. to pay for logistics, printing, local service companies, etc. It must work together with the EPS financial workgroup to keep it updated on any spendings and changes in a timely manner. Budget changes must be approved by the EPS board.

  12. The on-site team must be able to provide supporting letters for visa applicants wanting to attend the conference.

Proposal Structure

The proposal must cover all of the following points:

  1. A proposal introduction which describes the motivation for the proposal, underlines the willingness to commit to the needed work and acknowledges the above requirements.

  2. A description of the on-site team, its members and history in the context of their local Python community.

  3. Short biography of the key members and their previous experience in conference and events organizations.

  4. Previous conference history of the on-site team (if any). Describe which conferences were run and provide some figures on their size (registrations, tracks, total income)

  5. Assignment of key positions to on-site team members. Positions to be assigned (one member can be responsible for more than one of the following roles):

    1. Chairperson of the on-site team workgroup: usually also the conference chair and representative of conference for that year

    2. Sponsor manager: on site contact for all sponsor activities, responsible for local sponsors

    3. Venue manager: handling all contacts with the venue and caterer

    4. Logistics manager: handling all aspects of local logistics and customs

    5. Conference desk manager: responsible for the on site help desk, on site registrations, tickets, cash refunds, attendee support, etc.

  6. List of all team members that will be present during the conference itself as volunteers (but not necessarily help before the conference begins), and/or sources from which people can be or will be acquired if needed (eg: universities, other local associations, etc.). This list is indicative, as most of the volunteers helping during the conference are usually enrolled during the last months/weeks before the conference, usually started of through a call for volunteers.

  7. List of potential local sponsors. The EPS manages contacts with international sponsors, but local sponsors also help a lot in funding the conference. These are often smaller companies which will not move to new locations with the conference, so a local contact is highly beneficial in attracting these sponsors.

  8. Proposed dates for EuroPython 2015.

  9. Conference Events. Describe which kind of (social) events you can propose for the conference and are able to provide support for.

  10. Expected differences from previous EuroPython conferences (2013 and 2014). Please highlight what things would need to be changed in the way the conference is run on site. Examples of things we would consider worthwhile to be mentioned:

    1. "We can get additional support from the local government / city council"

    2. "We need to provide tickets to city locals at reduced prices"

    3. "We intend to serve meals in a different venue"

    4. "We have some extra space available for posters / sponsors"

    5. "We want to have our local Python conference run as satellite event"

  1. Venue proposal. Describe the following subitems:

    1. Location, reachability by car, train, plane

    2. Venue floor plans, catering floor plans (if different from venue)

    3. Total capacity for talk rooms, training rooms, plenary sessions, booth space and catering/restaurants; if possible, including room plans

    4. A/V equipment

    5. Video recording, availability of on-site support for A/V recordings, possibly even including live- or post-editing

    6. Lightning equipment, availability of on-site support for lighting

    7. Upstream internet connection (at least 100Mbit/s up and downstream)

    8. WLAN structure, service provider, their experience with similar events (WLAN has to be able to handle more than 1000 devices without problems)

    9. Available space for conference desk, sponsor booths, posters, social event, etc., planned locations of these on the floor plans

  2. Accomodation. Describe the following subitems:

    1. Available hotels/hostels near the conference venues, their distance from the conference venue, city center, airport and train station

    2. Rates for the hotels/hostels and, optionally, special rates which can be made available to attendees

    3. The above for three different categories: high end, average and low end

    4. Optionally, a "main" hotel that serves as default choice for conference attendees and serves as social hub

  3. City tourist information. Describe the following subitems:

    1. General information: touristic information, restaurants, mobility

    2. Travel information: how to get to the city and to the conference venue. This information should indicate how easily the conference city and venue are accessible from across Europe and from overseas. It should also answer questions like: Are there convenient ways to get to the conference venue from airports/trains and bus stations and without having a car/taxi?

    3. Travel costs from the previous mentioned travel hubs to the conference venue

  4. Visa: if attendees may require a visa to enter the country/city, please provide detailed information.

  5. Proposed local budget.

    1. The budget should include all expected costs for the on-site support, including the venue costs, catering, on-site rental of equipment, costs for venue services and logistics, extras like public transport passes, museum/tourist passes, etc. Optional budget positions should be indicated as such, to give more flexibility in comparing proposals.

    2. The budget must handle different scenarios related to different venues, including fixed rooms costs, catering, services, etc. Please provide cost estimates for 600, 800, 1000 and 1200 attendees (if possible with the venue).

    3. Please write to the EPS board if you need help with setting up a budget plan.

  6. Taxes/Legal. If there are special tax/legal requirements in the on-site team's country that require the EPS to register with the local government or pay attention to special regulations, please describe the necessary steps and provide a local accounting/legal contact who can help us work out the details.

Proposal Format

Some things to consider when sending the proposal document.

This Call for Participation (CFP) is also available as PDF file.

Thank you
-
EuroPython Society

31 Oct 2014 3:02pm GMT

EuroPython Society: EuroPython 2015 Call for Participation: On-site Teams

The EuroPython Society (EPS) is happy to announce the Call for Participation (CFP) for EuroPython 2015. The purpose of this call is to select teams willing to help organize the EuroPython conference on-site at a suitable location.

Introduction

This Call for Participation is meant to collect proposals from teams wishing to help run EuroPython 2015 in a location they are local to. As on-site team, you will be integrated into the new workgroups organizational structure the EPS is currently putting in place to run future EuroPython conferences:

EuroPython Workgroups: Call for Volunteers

The main idea behind this workgroup model is to make sure that tasks which do not need to be done by on-site team members can be implemented by distributed workgroups, that can work remotely and persist from location to location, greatly reducing the loss of institutional knowledge we have seen in recent location switches.

Another major aspect of setting up the EPS workgroups rather than having a structure centered around a local organizer, is to reduce the amount of work and financial risk for the on-site teams. As on-site team you no longer have to enter 5-6 figure Euro contracts for the venue or catering and you don't have to bother with running a website or arranging the conference program. Please note that we still encourage local team members to participate in the workgroups for these tasks, since this simplifies coordination.

The EPS strives to keep the EuroPython conference quality as high as possible, in all of its components. We expect the on-site team to take their proposals very seriously, knowing that they will need to work hard to make the conference a real success.

Timeline for Proposals

The Call for Participation will run until the following deadline for submissions. Proposals must be submitted until midnight UTC on the deadline day, and must adhere the requirements specified in this document. Please make sure to read the whole document carefully.

  • 2014-11-28 - Deadline for submissions (announcement + 4 weeks)
  • 2014-12-05 - Deadline for EPS to review proposals (1 week)
  • 2014-12-12 - Deadline for amended proposals (1 week)
  • 2014-12-26 - Decision on the next EP host (within 2 weeks)

Proposal Workflow

  1. Send your proposal as PDF to the board list: board@europython.eu. This is a private list, so you can include confidential information such as quotes from venues and caterers.

  2. The board will review the proposals and possibly request amendments directly from the submitters. This is done in private between the submitters and the EPS board.

  3. The final version of each proposal will be released to the public after the amendment deadline (with confidential information removed). The EPS will ask to the Python community to provide comments relating to the proposals and take an active role in to discussions.

  4. The final decision for the selection of the on-site team and location will be announced by the EPS board within two weeks after the deadline for amended proposals.

What is EuroPython

EuroPython is the second largest Python conference in the world, right after PyCon US in North America. These are some statistics from EuroPython 2014, to give you an idea of what the on-site team should be ready to handle:

Note that we are open to accepting proposal which can only host fewer attendees, with 600 attendees being the minimum. These numbers are just to give you an idea of how big the EuroPython event has become over the years and how much potential there is for growth.

Please see the EPS EuroPython page for more details on past EuroPython conferences:

http://www.europython-society.org/europython

How EuroPython is run

The EuroPython conference series brand is owned by the EPS. In the past the EPS granted permission to use the brand to local organizers based on a set of requirements, and the local organizing team then had to run the event in collaboration with the EPS.

Since this model no longer scales and doesn't encourage the community to take part in the organization process, we have started a new approach based on workgroups as explained in the document linked to in the introduction. The on-site team will integrate with the other EPS workgroups and be responsible for taking care of the tasks related to the conference organization on site.

Unlike in previous years, and to further reduce the burden on the on-site teams, we will only request the on-site teams to sign up for one year, keeping in mind, of course, that the team may want to submit a follow-up proposal for the next year. The EPS will take such prior knowledge into account when deciding on the proposals.

On-site Team Requirements

These are the requirements the on-site teams signs up to when submitting a proposal. Changes to these requirements are possible, but must be signed off by the EPS board before they can be put in place.

  1. The conference will be financially and legally run by the EPS, so the on-site team does not have to be a legal entity or enter into high-risk contracts.

  2. The on-site team should be geographically located in a specific country within Europe.

  3. The on-site team must be willing to actively coordinate with the EPS board and the other workgroups, so that all parts of the EuroPython ecosystem can work together in a productive way.

  4. The on-site team must be composed of at least 5 active people. We feel that 5 is the bare minimum for the team to successfully handle the amount of work. Please keep in mind that the team is required to grow significantly during the conference days and it's considered an advantage, if the on-site team can show that they already have a good number of volunteers to count on during the conference days.

  5. The on-site team must provide at least 2 available venue options, together with catering options for the venues. Locations must provide room for hosting at least 600 attendees, but please keep in mind that demand for EuroPython is more in the range of 1000+ attendees.

  6. The conference must provide the following services to all attendees. Proposals will have to provide details about how these can be implemented at the proposed venues.

    1. Food and drinks for lunches and breaks on all conference days and the sprints

    2. Optionally, breakfast on all conference days (not necessarily on the sprint days)

    3. WLAN service to access the Internet during the conference and the sprints

    4. At least one social event, which can be a dinner, a show or some other form of entertainment, where food and drinks are served. The main social event should ideally be available to all attendees, but may also be limited to a lower number of people, if the selected venue cannot serve as many participants.

    5. A partner program

    6. Audio/video facilities to support speakers and talk recordings.

  7. The conference must take place within the following timeframe: May 1st - October 31th. The venues have to be available for one week plus a setup day during this timeframe. It is possible to propose more than just one possible conference date, since the costs may vary across this timeframe.

  8. The on-site team will work as on-site workgroup in the context of the EPS (see below for details) and has to follow the same rules as all other workgroups in the EPS. Members of the on-site team should also participate in other workgroups to simplify coordination, e.g. there should be on-site team members in the sponsors workgroup to help the sponsors with booth setups, shipment of goods, customs, etc.

  9. The on-site team will coordinate with the EPS board and workgroups to implement the chosen EuroPython structure. The current structure is: conference days from Monday to Sunday, in which 5 days are used for parallels talks and trainings, and 2 weekend days for sprints.

  10. The on-site team must provide a local expenses budget plan as part of the proposal. A example budget plan can be provided on request. The budget figures will then be used as basis for the conference budget maintained by the EPS and its workgroups, so care has to be taken to provide sound numbers in the budget plan.

  11. The on-site team will receive a budget for the work on site, e.g. to pay for logistics, printing, local service companies, etc. It must work together with the EPS financial workgroup to keep it updated on any spendings and changes in a timely manner. Budget changes must be approved by the EPS board.

  12. The on-site team must be able to provide supporting letters for visa applicants wanting to attend the conference.

Proposal Structure

The proposal must cover all of the following points:

  1. A proposal introduction which describes the motivation for the proposal, underlines the willingness to commit to the needed work and acknowledges the above requirements.

  2. A description of the on-site team, its members and history in the context of their local Python community.

  3. Short biography of the key members and their previous experience in conference and events organizations.

  4. Previous conference history of the on-site team (if any). Describe which conferences were run and provide some figures on their size (registrations, tracks, total income)

  5. Assignment of key positions to on-site team members. Positions to be assigned (one member can be responsible for more than one of the following roles):

    1. Chairperson of the on-site team workgroup: usually also the conference chair and representative of conference for that year

    2. Sponsor manager: on site contact for all sponsor activities, responsible for local sponsors

    3. Venue manager: handling all contacts with the venue and caterer

    4. Logistics manager: handling all aspects of local logistics and customs

    5. Conference desk manager: responsible for the on site help desk, on site registrations, tickets, cash refunds, attendee support, etc.

  6. List of all team members that will be present during the conference itself as volunteers (but not necessarily help before the conference begins), and/or sources from which people can be or will be acquired if needed (eg: universities, other local associations, etc.). This list is indicative, as most of the volunteers helping during the conference are usually enrolled during the last months/weeks before the conference, usually started of through a call for volunteers.

  7. List of potential local sponsors. The EPS manages contacts with international sponsors, but local sponsors also help a lot in funding the conference. These are often smaller companies which will not move to new locations with the conference, so a local contact is highly beneficial in attracting these sponsors.

  8. Proposed dates for EuroPython 2015.

  9. Conference Events. Describe which kind of (social) events you can propose for the conference and are able to provide support for.

  10. Expected differences from previous EuroPython conferences (2013 and 2014). Please highlight what things would need to be changed in the way the conference is run on site. Examples of things we would consider worthwhile to be mentioned:

    1. "We can get additional support from the local government / city council"

    2. "We need to provide tickets to city locals at reduced prices"

    3. "We intend to serve meals in a different venue"

    4. "We have some extra space available for posters / sponsors"

    5. "We want to have our local Python conference run as satellite event"

  1. Venue proposal. Describe the following subitems:

    1. Location, reachability by car, train, plane

    2. Venue floor plans, catering floor plans (if different from venue)

    3. Total capacity for talk rooms, training rooms, plenary sessions, booth space and catering/restaurants; if possible, including room plans

    4. A/V equipment

    5. Video recording, availability of on-site support for A/V recordings, possibly even including live- or post-editing

    6. Lightning equipment, availability of on-site support for lighting

    7. Upstream internet connection (at least 100Mbit/s up and downstream)

    8. WLAN structure, service provider, their experience with similar events (WLAN has to be able to handle more than 1000 devices without problems)

    9. Available space for conference desk, sponsor booths, posters, social event, etc., planned locations of these on the floor plans

  2. Accomodation. Describe the following subitems:

    1. Available hotels/hostels near the conference venues, their distance from the conference venue, city center, airport and train station

    2. Rates for the hotels/hostels and, optionally, special rates which can be made available to attendees

    3. The above for three different categories: high end, average and low end

    4. Optionally, a "main" hotel that serves as default choice for conference attendees and serves as social hub

  3. City tourist information. Describe the following subitems:

    1. General information: touristic information, restaurants, mobility

    2. Travel information: how to get to the city and to the conference venue. This information should indicate how easily the conference city and venue are accessible from across Europe and from overseas. It should also answer questions like: Are there convenient ways to get to the conference venue from airports/trains and bus stations and without having a car/taxi?

    3. Travel costs from the previous mentioned travel hubs to the conference venue

  4. Visa: if attendees may require a visa to enter the country/city, please provide detailed information.

  5. Proposed local budget.

    1. The budget should include all expected costs for the on-site support, including the venue costs, catering, on-site rental of equipment, costs for venue services and logistics, extras like public transport passes, museum/tourist passes, etc. Optional budget positions should be indicated as such, to give more flexibility in comparing proposals.

    2. The budget must handle different scenarios related to different venues, including fixed rooms costs, catering, services, etc. Please provide cost estimates for 600, 800, 1000 and 1200 attendees (if possible with the venue).

    3. Please write to the EPS board if you need help with setting up a budget plan.

  6. Taxes/Legal. If there are special tax/legal requirements in the on-site team's country that require the EPS to register with the local government or pay attention to special regulations, please describe the necessary steps and provide a local accounting/legal contact who can help us work out the details.

Proposal Format

Some things to consider when sending the proposal document.

This Call for Participation (CFP) is also available as PDF file.

Thank you
-
EuroPython Society

31 Oct 2014 3:02pm GMT

Carl Trachte: Gtk.TreeView (grid view) with mono, gtk-sharp, and IronPython

The post immediately prior to this one was an attempt to reproduce Windows.Forms Calendar controls in Gtk for cross platform (Windows/*nix) effective rendering.

This time I am attempting to get familiar with gtk-sharp/Gtk's version of a grid view - the Gtk.TreeView object. Some of the gtk-sharp documentation suggests the NodeView object would be easier to use. I had some trouble instantiating the objects associated with the NodeView and went with the TreeView instead in the hopes of getting more control.

The Windows.Forms GridView I did years ago is here. It became apparent to me shortly after embarking on this journey that I would be hard pressed to recreate all the functionality of that script in a timely manner. I settled for a tabular view of drillhole data (fabricated, mock data) with some custom formatting.

Aside: this is typically how mineral exploration drillhole data (core, reverse circulation drilling) is presented in tabular format - a series of from-to intervals with assay values. Assuming the assays are all separate elements, the reported weight percents should not sum more than 100%, and never do unless someone fat fingers a decimal place. I've projected a couple screaming hot polymetallic drill holes that end near surface (lack of funding for drilling), but show enough promise that the new mining town of Trachteville (the drill hole name CBT-BNZA stands for CBT-Bonanza) will spring up there at any moment . . . one can dream.

The data store object for the grid view Gtk.ListStore object would not instantiate in IronPython. I was not the only person to have experienced this problem (I cannot locate the link to the mailing list thread or forum reference, but like the big fish that got away, I swear I saw it). I didn't want to drop the effort just because of that, so I hacked and compiled some C# code:

public class storex
{
public Gtk.ListStore drillhole =
// 7 columns
// drillhole id
new Gtk.ListStore (typeof (string),
// from
typeof (double),
// to
typeof (double),
// assay1
typeof (double),
// assay2
typeof (double),
// assay3
typeof (double),
// assay4
typeof (double));
}


The mono command on Windows was

C:\UserPrograms\Mono-3.2.3>mcs -pkg:gtk-sharp-2.0 /target:library C:\UserPrograms\IronPythonGUI\storex.cs

Those are my file paths; locations depend on where you install things like mono and IronPython.

Anyway, I got my dll and I was off to the races. Getting to know the Gtk and gtk-sharp object model proved challenging for me. I'm glad I got some familiarity with it, but it would take me longer to do something in Gtk than it did with Windows.Forms. The most fun and gratifying part of the project was getting the custom formatting to work with a Gtk.TreeCellDataFunc. I used a function that yielded specific functions for each column - something that's really easy to do in Python.

Anyway, here are a couple screenshots and the IronPython code:





The OpenBSD one below turned out pretty good, but the Windows one had a little double line underneath the first row - it looked as though it was still trying to select that row when I told it specifically not to. I'm not a design perfectionist Steve Jobs type, but niggling nits like that drive me batty. For now, though it's best I publish the code and move on.

#!/usr/local/bin/mono /home/carl/IronPython-2.7.4/ipy64.exe

import clr

GTKSHARP = 'gtk-sharp'
PANGO = 'pango-sharp'

# Mock store C#
STOREX = 'storex'

clr.AddReference(GTKSHARP)
clr.AddReference(PANGO)

# C# module compiled for this project.
# Problems with Gtk.ListStore in IronPython.
clr.AddReference(STOREX)

import Gtk
import Pango

import storex

TITLE = 'Gtk.TreeView Demo (Drillholes)'
MARKUP = '<span font="Courier New" size="14" weight="bold">{:s}</span>'
MARKEDUPTITLE = MARKUP.format(TITLE)

CENTERED = 0.5
RIGHT = 1.0

WINDOWWIDTH = 350

COURFONTREGULAR = 'Courier New 12'
COURFONTBOLD = 'Courier New Bold 12'

DHNAME = 'DH_CBTBNZA-{:>02d}'
DHNAMELABEL = 'drillhole'
FROM = 'from'
TO = 'to'
ASSAY1 = 'assay1'
ASSAY2 = 'assay2'
ASSAY3 = 'assay3'
ASSAY4 = 'assay4'

FP1FMT = '{:>5.1f}'
FP2FMT = '{:>4.2f}'

DHDATAX = {(DHNAME.format(1), 0.0):{TO:8.7,
ASSAY1:22.27,
ASSAY2:4.93,
ASSAY3:18.75,
ASSAY4:35.18},
(DHNAME.format(1), 8.7):{TO:15.3,
ASSAY1:0.27,
ASSAY2:0.09,
ASSAY3:0.03,
ASSAY4:0.22},
(DHNAME.format(1), 15.3):{TO:25.3,
ASSAY1:2.56,
ASSAY2:11.34,
ASSAY3:0.19,
ASSAY4:13.46},
(DHNAME.format(2), 0.0):{TO:10.0,
ASSAY1:0.07,
ASSAY2:1.23,
ASSAY3:4.78,
ASSAY4:5.13},
(DHNAME.format(2), 10.0):{TO:20.0,
ASSAY1:44.88,
ASSAY2:12.97,
ASSAY3:0.19,
ASSAY4:0.03}}

FIELDS = [DHNAMELABEL, FROM, TO, ASSAY1, ASSAY2, ASSAY3, ASSAY4]
BOLDEDCOLUMNS = [DHNAMELABEL, FROM, TO]
NONKEYFIELDS = FIELDS[2:]

BLAZINGCUTOFF = 10.0

def genericfloatformat(floatfmt, index):
"""
For cell formatting in Gtk.TreeView.

Returns a function to format floats
and to format floats' foreground color
based on cutoff value.

floatfmt is a format string.

index is an int that indicates the
column being formatted.
"""
def setfloatfmt(treeviewcolumn, cellrenderer, treemodel, treeiter):
cellrenderer.Text = floatfmt.format(treemodel.GetValue(treeiter, index))
# If it is one of the assay value columns.
# XXX - not generic.
if index > 2:
if treemodel.GetValue(treeiter, index) > BLAZINGCUTOFF:
cellrenderer.Foreground = 'red'
else:
cellrenderer.Foreground = 'black'
return Gtk.TreeCellDataFunc(setfloatfmt)

class TreeViewTest(object):
def __init__(self):
Gtk.Application.Init()
self.window = Gtk.Window('')
# DeleteEvent - copied from Gtk demo on internet.
self.window.DeleteEvent += self.DeleteEvent
# Frame property provides a frame and title.
self.frame = Gtk.Frame(MARKEDUPTITLE)
self.tree = Gtk.TreeView()
self.tree.EnableGridLines = Gtk.TreeViewGridLines.Both
self.frame.Add(self.tree)

# Fonts for formatting.
self.fdregular = Pango.FontDescription.FromString(COURFONTREGULAR)
self.fdbold = Pango.FontDescription.FromString(COURFONTBOLD)

# C# module
self.store = storex().drillhole

self.makecolumns()
self.adddata()
self.tree.Model = self.store

self.formatcolumns()
self.formatcells()
self.prettyup()

self.window.Add(self.frame)
self.window.ShowAll()
# Keep text viewable - size no smaller than intended.
self.window.AllowShrink = False
# XXX - hack to keep lack of gridlines on edges of
# table from showing.
self.window.AllowGrow = False
# Unselect everything for this demo.
self.tree.Selection.UnselectAll()
Gtk.Application.Run()

def makecolumns(self):
"""
Fill in columns for TreeView.
"""
self.columns = {}
for fieldx in FIELDS:
self.columns[fieldx] = Gtk.TreeViewColumn()
self.columns[fieldx].Title = fieldx
self.tree.AppendColumn(self.columns[fieldx])

def formatcolumns(self):
"""
Make custom labels for columnn headers.

Get each column properly justified (all
are right justified,floating point numbers
except for the drillhole 'number' -
actually a string).
"""
self.customlabels = {}

for fieldx in FIELDS:
# This centers the labels at the top.
self.columns[fieldx].Alignment = CENTERED
self.customlabels[fieldx] = Gtk.Label(self.columns[fieldx].Title)
self.customlabels[fieldx].ModifyFont(self.fdbold)
# 120 is about right for from, to, and assay columns.
self.columns[fieldx].MinWidth = 120
self.customlabels[fieldx].ShowAll()
self.columns[fieldx].Widget = self.customlabels[fieldx]
# ShowAll required for new label to take.
self.columns[fieldx].Widget.ShowAll()

def formatcells(self):
"""
Add and format cell renderers.
"""
self.cellrenderers = {}

for fieldx in FIELDS:
self.cellrenderers[fieldx] = Gtk.CellRendererText()
self.columns[fieldx].PackStart(self.cellrenderers[fieldx], True)
# Drillhole 'number' (string)
if fieldx == FIELDS[0]:
self.cellrenderers[fieldx].Xalign = CENTERED
self.columns[fieldx].AddAttribute(self.cellrenderers[fieldx],
'text', 0)
else:
self.cellrenderers[fieldx].Xalign = RIGHT
try:
self.columns[fieldx].AddAttribute(self.cellrenderers[fieldx],
'text', FIELDS.index(fieldx))
except ValueError:
print('\n\nProblem with field definitions; field not found.\n\n')
for fieldx in BOLDEDCOLUMNS:
self.cellrenderers[fieldx].Font = COURFONTBOLD
self.columns[fieldx].Widget.ShowAll()

# XXX - not very generic, but better than doing them one by one.
# from, to columns.
for x in xrange(1, 3):
self.columns[FIELDS[x]].SetCellDataFunc(self.cellrenderers[FIELDS[x]],
genericfloatformat(FP1FMT, x))
# assay<x> columns.
for x in xrange(3, 7):
self.columns[FIELDS[x]].SetCellDataFunc(self.cellrenderers[FIELDS[x]],
genericfloatformat(FP2FMT, x))

def usemarkup(self):
"""
Refreshes UseMarkup property on widgets (labels)
so that they display properly and without
markup text.
"""
# Have to refresh this property each time.
self.frame.LabelWidget.UseMarkup = True

def prettyup(self):
"""
Get Gtk objects looking the way we
intended.
"""
# Try to get Courier New on treeview.
self.tree.ModifyFont(self.fdregular)
# Get rid of line.
self.frame.Shadow = Gtk.ShadowType.None
self.usemarkup()

def adddata(self):
"""
Put data into store.
"""
# XXX - difficulty figuring out sorting
# function for TreeView. Hack it
# with dictionary here.
keytuples = [key for key in DHDATAX]
keytuples.sort()
datax = []
for tuplex in keytuples:
# XXX - side effect comprehension.
# Not great for readability,
# but compact.
[datax.append(x) for x in tuplex]
for fieldx in NONKEYFIELDS:
datax.append(DHDATAX[tuplex][fieldx])
self.store.AppendValues(*datax)
# Reinitiialize data row list.
datax = []

def DeleteEvent(self, widget, event):
Gtk.Application.Quit()

if __name__ == '__main__':
TreeViewTest()


Thanks for stopping by.

31 Oct 2014 7:15am GMT

Carl Trachte: Gtk.TreeView (grid view) with mono, gtk-sharp, and IronPython

The post immediately prior to this one was an attempt to reproduce Windows.Forms Calendar controls in Gtk for cross platform (Windows/*nix) effective rendering.

This time I am attempting to get familiar with gtk-sharp/Gtk's version of a grid view - the Gtk.TreeView object. Some of the gtk-sharp documentation suggests the NodeView object would be easier to use. I had some trouble instantiating the objects associated with the NodeView and went with the TreeView instead in the hopes of getting more control.

The Windows.Forms GridView I did years ago is here. It became apparent to me shortly after embarking on this journey that I would be hard pressed to recreate all the functionality of that script in a timely manner. I settled for a tabular view of drillhole data (fabricated, mock data) with some custom formatting.

Aside: this is typically how mineral exploration drillhole data (core, reverse circulation drilling) is presented in tabular format - a series of from-to intervals with assay values. Assuming the assays are all separate elements, the reported weight percents should not sum more than 100%, and never do unless someone fat fingers a decimal place. I've projected a couple screaming hot polymetallic drill holes that end near surface (lack of funding for drilling), but show enough promise that the new mining town of Trachteville (the drill hole name CBT-BNZA stands for CBT-Bonanza) will spring up there at any moment . . . one can dream.

The data store object for the grid view Gtk.ListStore object would not instantiate in IronPython. I was not the only person to have experienced this problem (I cannot locate the link to the mailing list thread or forum reference, but like the big fish that got away, I swear I saw it). I didn't want to drop the effort just because of that, so I hacked and compiled some C# code:

public class storex
{
public Gtk.ListStore drillhole =
// 7 columns
// drillhole id
new Gtk.ListStore (typeof (string),
// from
typeof (double),
// to
typeof (double),
// assay1
typeof (double),
// assay2
typeof (double),
// assay3
typeof (double),
// assay4
typeof (double));
}


The mono command on Windows was

C:\UserPrograms\Mono-3.2.3>mcs -pkg:gtk-sharp-2.0 /target:library C:\UserPrograms\IronPythonGUI\storex.cs

Those are my file paths; locations depend on where you install things like mono and IronPython.

Anyway, I got my dll and I was off to the races. Getting to know the Gtk and gtk-sharp object model proved challenging for me. I'm glad I got some familiarity with it, but it would take me longer to do something in Gtk than it did with Windows.Forms. The most fun and gratifying part of the project was getting the custom formatting to work with a Gtk.TreeCellDataFunc. I used a function that yielded specific functions for each column - something that's really easy to do in Python.

Anyway, here are a couple screenshots and the IronPython code:





The OpenBSD one below turned out pretty good, but the Windows one had a little double line underneath the first row - it looked as though it was still trying to select that row when I told it specifically not to. I'm not a design perfectionist Steve Jobs type, but niggling nits like that drive me batty. For now, though it's best I publish the code and move on.

#!/usr/local/bin/mono /home/carl/IronPython-2.7.4/ipy64.exe

import clr

GTKSHARP = 'gtk-sharp'
PANGO = 'pango-sharp'

# Mock store C#
STOREX = 'storex'

clr.AddReference(GTKSHARP)
clr.AddReference(PANGO)

# C# module compiled for this project.
# Problems with Gtk.ListStore in IronPython.
clr.AddReference(STOREX)

import Gtk
import Pango

import storex

TITLE = 'Gtk.TreeView Demo (Drillholes)'
MARKUP = '<span font="Courier New" size="14" weight="bold">{:s}</span>'
MARKEDUPTITLE = MARKUP.format(TITLE)

CENTERED = 0.5
RIGHT = 1.0

WINDOWWIDTH = 350

COURFONTREGULAR = 'Courier New 12'
COURFONTBOLD = 'Courier New Bold 12'

DHNAME = 'DH_CBTBNZA-{:>02d}'
DHNAMELABEL = 'drillhole'
FROM = 'from'
TO = 'to'
ASSAY1 = 'assay1'
ASSAY2 = 'assay2'
ASSAY3 = 'assay3'
ASSAY4 = 'assay4'

FP1FMT = '{:>5.1f}'
FP2FMT = '{:>4.2f}'

DHDATAX = {(DHNAME.format(1), 0.0):{TO:8.7,
ASSAY1:22.27,
ASSAY2:4.93,
ASSAY3:18.75,
ASSAY4:35.18},
(DHNAME.format(1), 8.7):{TO:15.3,
ASSAY1:0.27,
ASSAY2:0.09,
ASSAY3:0.03,
ASSAY4:0.22},
(DHNAME.format(1), 15.3):{TO:25.3,
ASSAY1:2.56,
ASSAY2:11.34,
ASSAY3:0.19,
ASSAY4:13.46},
(DHNAME.format(2), 0.0):{TO:10.0,
ASSAY1:0.07,
ASSAY2:1.23,
ASSAY3:4.78,
ASSAY4:5.13},
(DHNAME.format(2), 10.0):{TO:20.0,
ASSAY1:44.88,
ASSAY2:12.97,
ASSAY3:0.19,
ASSAY4:0.03}}

FIELDS = [DHNAMELABEL, FROM, TO, ASSAY1, ASSAY2, ASSAY3, ASSAY4]
BOLDEDCOLUMNS = [DHNAMELABEL, FROM, TO]
NONKEYFIELDS = FIELDS[2:]

BLAZINGCUTOFF = 10.0

def genericfloatformat(floatfmt, index):
"""
For cell formatting in Gtk.TreeView.

Returns a function to format floats
and to format floats' foreground color
based on cutoff value.

floatfmt is a format string.

index is an int that indicates the
column being formatted.
"""
def setfloatfmt(treeviewcolumn, cellrenderer, treemodel, treeiter):
cellrenderer.Text = floatfmt.format(treemodel.GetValue(treeiter, index))
# If it is one of the assay value columns.
# XXX - not generic.
if index > 2:
if treemodel.GetValue(treeiter, index) > BLAZINGCUTOFF:
cellrenderer.Foreground = 'red'
else:
cellrenderer.Foreground = 'black'
return Gtk.TreeCellDataFunc(setfloatfmt)

class TreeViewTest(object):
def __init__(self):
Gtk.Application.Init()
self.window = Gtk.Window('')
# DeleteEvent - copied from Gtk demo on internet.
self.window.DeleteEvent += self.DeleteEvent
# Frame property provides a frame and title.
self.frame = Gtk.Frame(MARKEDUPTITLE)
self.tree = Gtk.TreeView()
self.tree.EnableGridLines = Gtk.TreeViewGridLines.Both
self.frame.Add(self.tree)

# Fonts for formatting.
self.fdregular = Pango.FontDescription.FromString(COURFONTREGULAR)
self.fdbold = Pango.FontDescription.FromString(COURFONTBOLD)

# C# module
self.store = storex().drillhole

self.makecolumns()
self.adddata()
self.tree.Model = self.store

self.formatcolumns()
self.formatcells()
self.prettyup()

self.window.Add(self.frame)
self.window.ShowAll()
# Keep text viewable - size no smaller than intended.
self.window.AllowShrink = False
# XXX - hack to keep lack of gridlines on edges of
# table from showing.
self.window.AllowGrow = False
# Unselect everything for this demo.
self.tree.Selection.UnselectAll()
Gtk.Application.Run()

def makecolumns(self):
"""
Fill in columns for TreeView.
"""
self.columns = {}
for fieldx in FIELDS:
self.columns[fieldx] = Gtk.TreeViewColumn()
self.columns[fieldx].Title = fieldx
self.tree.AppendColumn(self.columns[fieldx])

def formatcolumns(self):
"""
Make custom labels for columnn headers.

Get each column properly justified (all
are right justified,floating point numbers
except for the drillhole 'number' -
actually a string).
"""
self.customlabels = {}

for fieldx in FIELDS:
# This centers the labels at the top.
self.columns[fieldx].Alignment = CENTERED
self.customlabels[fieldx] = Gtk.Label(self.columns[fieldx].Title)
self.customlabels[fieldx].ModifyFont(self.fdbold)
# 120 is about right for from, to, and assay columns.
self.columns[fieldx].MinWidth = 120
self.customlabels[fieldx].ShowAll()
self.columns[fieldx].Widget = self.customlabels[fieldx]
# ShowAll required for new label to take.
self.columns[fieldx].Widget.ShowAll()

def formatcells(self):
"""
Add and format cell renderers.
"""
self.cellrenderers = {}

for fieldx in FIELDS:
self.cellrenderers[fieldx] = Gtk.CellRendererText()
self.columns[fieldx].PackStart(self.cellrenderers[fieldx], True)
# Drillhole 'number' (string)
if fieldx == FIELDS[0]:
self.cellrenderers[fieldx].Xalign = CENTERED
self.columns[fieldx].AddAttribute(self.cellrenderers[fieldx],
'text', 0)
else:
self.cellrenderers[fieldx].Xalign = RIGHT
try:
self.columns[fieldx].AddAttribute(self.cellrenderers[fieldx],
'text', FIELDS.index(fieldx))
except ValueError:
print('\n\nProblem with field definitions; field not found.\n\n')
for fieldx in BOLDEDCOLUMNS:
self.cellrenderers[fieldx].Font = COURFONTBOLD
self.columns[fieldx].Widget.ShowAll()

# XXX - not very generic, but better than doing them one by one.
# from, to columns.
for x in xrange(1, 3):
self.columns[FIELDS[x]].SetCellDataFunc(self.cellrenderers[FIELDS[x]],
genericfloatformat(FP1FMT, x))
# assay<x> columns.
for x in xrange(3, 7):
self.columns[FIELDS[x]].SetCellDataFunc(self.cellrenderers[FIELDS[x]],
genericfloatformat(FP2FMT, x))

def usemarkup(self):
"""
Refreshes UseMarkup property on widgets (labels)
so that they display properly and without
markup text.
"""
# Have to refresh this property each time.
self.frame.LabelWidget.UseMarkup = True

def prettyup(self):
"""
Get Gtk objects looking the way we
intended.
"""
# Try to get Courier New on treeview.
self.tree.ModifyFont(self.fdregular)
# Get rid of line.
self.frame.Shadow = Gtk.ShadowType.None
self.usemarkup()

def adddata(self):
"""
Put data into store.
"""
# XXX - difficulty figuring out sorting
# function for TreeView. Hack it
# with dictionary here.
keytuples = [key for key in DHDATAX]
keytuples.sort()
datax = []
for tuplex in keytuples:
# XXX - side effect comprehension.
# Not great for readability,
# but compact.
[datax.append(x) for x in tuplex]
for fieldx in NONKEYFIELDS:
datax.append(DHDATAX[tuplex][fieldx])
self.store.AppendValues(*datax)
# Reinitiialize data row list.
datax = []

def DeleteEvent(self, widget, event):
Gtk.Application.Quit()

if __name__ == '__main__':
TreeViewTest()


Thanks for stopping by.

31 Oct 2014 7:15am GMT

Carl Trachte: Mono gtk-sharp IronPython CalendarView

A number of years ago I did a post on the IronPython Cookbook site about the Windows.Forms Calendar control. I could never get the thing to render nicely on *nix operating systems (BSD family). It sounds as though Windows.Forms development for mono (and in general) is kind of dead, so there is not much hope that solution/example will ever render nicely on *nix. Recently I've been playing with mono and decided to give gtk-sharp a shot with IronPython.

Quick disclaimers:

1) I suspect from the examples I've seen on the internet that PyGtk is a little easier to deal with than gtk-sharp. That's OK; I wanted to use IronPython and have the rest of the mono/dotNet framework available, so I went through the extra trouble to forego CPython and PyGtk and go with IronPython and gtk-sharp instead.

2) The desktop is not the most cutting edge or sexy platform in 2014. Nonetheless, where I work it is alive and well. When I no longer see engineers hacking solutions in Excel and VBA, I'll consider the possibility of outliving the desktop. Right now I'm not hopeful :-\

The results aren't bad, at least as far as rendering goes. I couldn't get the Courier font to take on OpenBSD, but the Gtk Calendar control looks acceptable. All in all, I was OK with the results on both Windows and OpenBSD. I've heard Gtk doesn't do quite as well on Apple products, but I don't own a Mac to test with. Here are a couple screenshots:






I run the cwm window manager on OpenBSD and have it set up to cut out borders on windows, hence the more minimalist look to the control there.

IronPython output on *nix has always come out in yellow or white - it doesn't show up on a white background, which I prefer. In order to get around this, I run an xterm with a black background:

xterm -bg black -fg white

Here is the code for the gtk-sharp Gtk.Calendar control:

#!/usr/local/bin/mono /home/carl/IronPython-2.7.4/ipy64.exe

import clr

GTKSHARP = 'gtk-sharp'
PANGO = 'pango-sharp'

clr.AddReference(GTKSHARP)
clr.AddReference(PANGO)

import Gtk
import Pango

import datetime

TITLE = 'Gtk.Calendar Demo'
MARKUP = '<span font="Courier New" size="14" weight="bold">{:s}</span>'
MARKEDUPTITLE = MARKUP.format(TITLE)

INFOMSG = '<span font="Courier New 12">\n\n Program set to run for:\n\n '
INFOMSG += '{:%Y-%m-%d}\n\n</span>'

DATEDIFFMSG = '<span font="Courier New 12">\n\n '
DATEDIFFMSG += 'There are {0:d} days between the\n'
DATEDIFFMSG += ' beginning of the epoch and\n'
DATEDIFFMSG += ' {1:%Y-%m-%d}.\n\n</span>'

ALIGNMENTPARAMS = (0.0, 0.5, 0.0, 0.0)

WINDOWWIDTH = 350

CALENDARFONT = 'Courier New Bold 12'


class CalendarTest(object):
inthebeginning = datetime.datetime.fromtimestamp(0)
# Debug info - make sure beginning of epoch really
# is +midnight, Jan 1, 1970 GMT.
print(inthebeginning)
def __init__(self):
Gtk.Application.Init()
self.window = Gtk.Window(TITLE)
# DeleteEvent - copied from Gtk demo on internet.
self.window.DeleteEvent += self.DeleteEvent
# Frame property provides a frame and title.
self.frame = Gtk.Frame(MARKEDUPTITLE)
self.calendar = Gtk.Calendar()
# Handles date selection event.
self.calendar.DaySelected += self.dateselect
# Sets up text for labels.
self.getcaltext()
# Puts little box around text.
self.datelabelframe = Gtk.Frame()
# Try to get datelabel to align with other label.
self.datelabelalignment = Gtk.Alignment(*ALIGNMENTPARAMS)
self.datelabel = Gtk.Label(self.caltext)
self.datelabelalignment.Add(self.datelabel)
self.datelabelframe.Add(self.datelabelalignment)
# Puts little box around text.
self.datedifflabelframe = Gtk.Frame()
self.datedifflabelalignment = Gtk.Alignment(*ALIGNMENTPARAMS)
self.datedifflabel = Gtk.Label(self.timedifftext)
self.datedifflabelalignment.Add(self.datedifflabel)
self.datedifflabelframe.Add(self.datedifflabelalignment)
self.vbox = Gtk.VBox()
self.vbox.PackStart(self.datelabelframe)
self.vbox.PackStart(self.datedifflabelframe)
self.vbox.PackStart(self.calendar)
self.frame.Add(self.vbox)
self.window.Add(self.frame)
self.prettyup()
self.window.ShowAll()
# Keep text viewable - size no smaller than intended.
self.window.AllowShrink = False
Gtk.Application.Run()

def getcaltext(self):
"""
Get messages for run date.
"""
# Calendar month is 0 based.
yearmonthday = self.calendar.Year, self.calendar.Month + 1, self.calendar.Day
chosendate = datetime.datetime(*yearmonthday)
self.caltext = INFOMSG.format(chosendate)
# For reporting of number of days since beginning of epoch.
timediff = chosendate - CalendarTest.inthebeginning
self.timedifftext = DATEDIFFMSG.format(timediff.days, chosendate)

def usemarkup(self):
"""
Refreshes UseMarkup property on widgets (labels)
so that they display properly and without
markup text.
"""
# Have to refresh this property each time.
self.frame.LabelWidget.UseMarkup = True
self.datelabel.UseMarkup = True
self.datedifflabel.UseMarkup = True

def prettyup(self):
"""
Get Gtk objects looking the way we
intended.
"""
# Try to make frame wider.
# XXX
# Works nicely on Windows - try on Unix.
# Allows bold, etc.
self.usemarkup()
self.frame.SetSizeRequest(WINDOWWIDTH, -1)
# Get rid of line in middle of text on title.
self.frame.Shadow = Gtk.ShadowType.None
# Try to get Courier New on calendar.
fd = Pango.FontDescription.FromString(CALENDARFONT)
self.calendar.ModifyFont(fd)
self.datelabel.Justify = Gtk.Justification.Left
self.datedifflabel.Justify = Gtk.Justification.Left
self.window.Title = ''
self.usemarkup()

def dateselect(self, widget, event):
self.getcaltext()
self.datelabel.Text = self.caltext
self.datedifflabel.Text = self.timedifftext
self.prettyup()

def DeleteEvent(self, widget, event):
Gtk.Application.Quit()

if __name__ == '__main__':
CalendarTest()


Thanks for stopping by.

31 Oct 2014 6:25am GMT

Carl Trachte: Mono gtk-sharp IronPython CalendarView

A number of years ago I did a post on the IronPython Cookbook site about the Windows.Forms Calendar control. I could never get the thing to render nicely on *nix operating systems (BSD family). It sounds as though Windows.Forms development for mono (and in general) is kind of dead, so there is not much hope that solution/example will ever render nicely on *nix. Recently I've been playing with mono and decided to give gtk-sharp a shot with IronPython.

Quick disclaimers:

1) I suspect from the examples I've seen on the internet that PyGtk is a little easier to deal with than gtk-sharp. That's OK; I wanted to use IronPython and have the rest of the mono/dotNet framework available, so I went through the extra trouble to forego CPython and PyGtk and go with IronPython and gtk-sharp instead.

2) The desktop is not the most cutting edge or sexy platform in 2014. Nonetheless, where I work it is alive and well. When I no longer see engineers hacking solutions in Excel and VBA, I'll consider the possibility of outliving the desktop. Right now I'm not hopeful :-\

The results aren't bad, at least as far as rendering goes. I couldn't get the Courier font to take on OpenBSD, but the Gtk Calendar control looks acceptable. All in all, I was OK with the results on both Windows and OpenBSD. I've heard Gtk doesn't do quite as well on Apple products, but I don't own a Mac to test with. Here are a couple screenshots:






I run the cwm window manager on OpenBSD and have it set up to cut out borders on windows, hence the more minimalist look to the control there.

IronPython output on *nix has always come out in yellow or white - it doesn't show up on a white background, which I prefer. In order to get around this, I run an xterm with a black background:

xterm -bg black -fg white

Here is the code for the gtk-sharp Gtk.Calendar control:

#!/usr/local/bin/mono /home/carl/IronPython-2.7.4/ipy64.exe

import clr

GTKSHARP = 'gtk-sharp'
PANGO = 'pango-sharp'

clr.AddReference(GTKSHARP)
clr.AddReference(PANGO)

import Gtk
import Pango

import datetime

TITLE = 'Gtk.Calendar Demo'
MARKUP = '<span font="Courier New" size="14" weight="bold">{:s}</span>'
MARKEDUPTITLE = MARKUP.format(TITLE)

INFOMSG = '<span font="Courier New 12">\n\n Program set to run for:\n\n '
INFOMSG += '{:%Y-%m-%d}\n\n</span>'

DATEDIFFMSG = '<span font="Courier New 12">\n\n '
DATEDIFFMSG += 'There are {0:d} days between the\n'
DATEDIFFMSG += ' beginning of the epoch and\n'
DATEDIFFMSG += ' {1:%Y-%m-%d}.\n\n</span>'

ALIGNMENTPARAMS = (0.0, 0.5, 0.0, 0.0)

WINDOWWIDTH = 350

CALENDARFONT = 'Courier New Bold 12'


class CalendarTest(object):
inthebeginning = datetime.datetime.fromtimestamp(0)
# Debug info - make sure beginning of epoch really
# is +midnight, Jan 1, 1970 GMT.
print(inthebeginning)
def __init__(self):
Gtk.Application.Init()
self.window = Gtk.Window(TITLE)
# DeleteEvent - copied from Gtk demo on internet.
self.window.DeleteEvent += self.DeleteEvent
# Frame property provides a frame and title.
self.frame = Gtk.Frame(MARKEDUPTITLE)
self.calendar = Gtk.Calendar()
# Handles date selection event.
self.calendar.DaySelected += self.dateselect
# Sets up text for labels.
self.getcaltext()
# Puts little box around text.
self.datelabelframe = Gtk.Frame()
# Try to get datelabel to align with other label.
self.datelabelalignment = Gtk.Alignment(*ALIGNMENTPARAMS)
self.datelabel = Gtk.Label(self.caltext)
self.datelabelalignment.Add(self.datelabel)
self.datelabelframe.Add(self.datelabelalignment)
# Puts little box around text.
self.datedifflabelframe = Gtk.Frame()
self.datedifflabelalignment = Gtk.Alignment(*ALIGNMENTPARAMS)
self.datedifflabel = Gtk.Label(self.timedifftext)
self.datedifflabelalignment.Add(self.datedifflabel)
self.datedifflabelframe.Add(self.datedifflabelalignment)
self.vbox = Gtk.VBox()
self.vbox.PackStart(self.datelabelframe)
self.vbox.PackStart(self.datedifflabelframe)
self.vbox.PackStart(self.calendar)
self.frame.Add(self.vbox)
self.window.Add(self.frame)
self.prettyup()
self.window.ShowAll()
# Keep text viewable - size no smaller than intended.
self.window.AllowShrink = False
Gtk.Application.Run()

def getcaltext(self):
"""
Get messages for run date.
"""
# Calendar month is 0 based.
yearmonthday = self.calendar.Year, self.calendar.Month + 1, self.calendar.Day
chosendate = datetime.datetime(*yearmonthday)
self.caltext = INFOMSG.format(chosendate)
# For reporting of number of days since beginning of epoch.
timediff = chosendate - CalendarTest.inthebeginning
self.timedifftext = DATEDIFFMSG.format(timediff.days, chosendate)

def usemarkup(self):
"""
Refreshes UseMarkup property on widgets (labels)
so that they display properly and without
markup text.
"""
# Have to refresh this property each time.
self.frame.LabelWidget.UseMarkup = True
self.datelabel.UseMarkup = True
self.datedifflabel.UseMarkup = True

def prettyup(self):
"""
Get Gtk objects looking the way we
intended.
"""
# Try to make frame wider.
# XXX
# Works nicely on Windows - try on Unix.
# Allows bold, etc.
self.usemarkup()
self.frame.SetSizeRequest(WINDOWWIDTH, -1)
# Get rid of line in middle of text on title.
self.frame.Shadow = Gtk.ShadowType.None
# Try to get Courier New on calendar.
fd = Pango.FontDescription.FromString(CALENDARFONT)
self.calendar.ModifyFont(fd)
self.datelabel.Justify = Gtk.Justification.Left
self.datedifflabel.Justify = Gtk.Justification.Left
self.window.Title = ''
self.usemarkup()

def dateselect(self, widget, event):
self.getcaltext()
self.datelabel.Text = self.caltext
self.datedifflabel.Text = self.timedifftext
self.prettyup()

def DeleteEvent(self, widget, event):
Gtk.Application.Quit()

if __name__ == '__main__':
CalendarTest()


Thanks for stopping by.

31 Oct 2014 6:25am GMT

Vasudev Ram: PDF in a Net, with Netius, a pure Python network library

By Vasudev Ram


I came across Netius, a pure Python network library, recently.

Excerpt from the Netius home page:

[ Netius is a Python network library that can be used for the rapid creation of asynchronous non-blocking servers and clients. It has no dependencies, it's cross-platform, and brings some sample netius-powered servers out of the box, namely a production-ready WSGI server. ]

Note: They mention some limitations of the async feature. Check the Netius home page for more on that.

To try out netius a little (not the async features, yet), I modified their example WSGI server program to serve a PDF of some hard-coded text, generated by xtopdf, my PDF creation library / toolkit.

The server, netius_pdf_server.py, running on port 8080, generates and writes to disk, a PDF of some text, and then reads back that PDF from disk, and serves it to the client.

The client, netius_pdf_client.py, uses the requests Python HTTP library to make a request to that server, gets the PDF file in the response, and writes it to disk.

Note: this is proof-of-concept code, without much error handling or refinement. But I did run it and it worked.

Here is the code for the server:

# test_netius_wsgi_server.py 

import time
from PDFWriter import PDFWriter
import netius.servers

def get_pdf():
pw = PDFWriter('hello-from-netius.pdf')
pw.setFont('Courier', 10)
pw.setHeader('PDF generated by xtopdf, a PDF library for Python')
pw.setFooter('Using netius Python network library, at {}'.format(time.ctime()))
pw.writeLine('Hello world! This is a test PDF served by Netius, ')
pw.writeLine('a Python networking library; PDF created with the help ')
pw.writeLine('of xtopdf, a Python library for PDF creation.')
pw.close()
pdf_fil = open('hello-from-netius.pdf', 'rb')
pdf_str = pdf_fil.read()
pdf_len = len(pdf_str)
pdf_fil.close()
return pdf_len, pdf_str

def app(environ, start_response):
status = "200 OK"
content_len, contents = get_pdf()
headers = (
("Content-Length", content_len),
("Content-type", "application/pdf"),
("Connection", "keep-alive")
)
start_response(status, headers)
yield contents

server = netius.servers.WSGIServer(app = app)
server.serve(port = 8080)

In my next post, I'll show the code for the client, and the output.

You may also like to see my earlier posts on similar lines, about generating and serving PDF content using other Python web frameworks:

PDF in a Bottle , PDF in a Flask and PDF in a CherryPy.

The image at the top of this post is of Chinese fishing nets, a tourist attraction found in Kochi (formerly called Cochin), Kerala.

- Enjoy.
- Vasudev Ram - Dancing Bison EnterprisesSignup for email about new products from me. Contact Page

Share |
Vasudev Ram

31 Oct 2014 5:11am GMT

Vasudev Ram: PDF in a Net, with Netius, a pure Python network library

By Vasudev Ram


I came across Netius, a pure Python network library, recently.

Excerpt from the Netius home page:

[ Netius is a Python network library that can be used for the rapid creation of asynchronous non-blocking servers and clients. It has no dependencies, it's cross-platform, and brings some sample netius-powered servers out of the box, namely a production-ready WSGI server. ]

Note: They mention some limitations of the async feature. Check the Netius home page for more on that.

To try out netius a little (not the async features, yet), I modified their example WSGI server program to serve a PDF of some hard-coded text, generated by xtopdf, my PDF creation library / toolkit.

The server, netius_pdf_server.py, running on port 8080, generates and writes to disk, a PDF of some text, and then reads back that PDF from disk, and serves it to the client.

The client, netius_pdf_client.py, uses the requests Python HTTP library to make a request to that server, gets the PDF file in the response, and writes it to disk.

Note: this is proof-of-concept code, without much error handling or refinement. But I did run it and it worked.

Here is the code for the server:

# test_netius_wsgi_server.py 

import time
from PDFWriter import PDFWriter
import netius.servers

def get_pdf():
pw = PDFWriter('hello-from-netius.pdf')
pw.setFont('Courier', 10)
pw.setHeader('PDF generated by xtopdf, a PDF library for Python')
pw.setFooter('Using netius Python network library, at {}'.format(time.ctime()))
pw.writeLine('Hello world! This is a test PDF served by Netius, ')
pw.writeLine('a Python networking library; PDF created with the help ')
pw.writeLine('of xtopdf, a Python library for PDF creation.')
pw.close()
pdf_fil = open('hello-from-netius.pdf', 'rb')
pdf_str = pdf_fil.read()
pdf_len = len(pdf_str)
pdf_fil.close()
return pdf_len, pdf_str

def app(environ, start_response):
status = "200 OK"
content_len, contents = get_pdf()
headers = (
("Content-Length", content_len),
("Content-type", "application/pdf"),
("Connection", "keep-alive")
)
start_response(status, headers)
yield contents

server = netius.servers.WSGIServer(app = app)
server.serve(port = 8080)

In my next post, I'll show the code for the client, and the output.

You may also like to see my earlier posts on similar lines, about generating and serving PDF content using other Python web frameworks:

PDF in a Bottle , PDF in a Flask and PDF in a CherryPy.

The image at the top of this post is of Chinese fishing nets, a tourist attraction found in Kochi (formerly called Cochin), Kerala.

- Enjoy.
- Vasudev Ram - Dancing Bison EnterprisesSignup for email about new products from me. Contact Page

Share |
Vasudev Ram

31 Oct 2014 5:11am GMT

Montreal Python User Group: Election for MTL:PY this Monday

It's that time of the year again: the organisation team for the Montréal-Python community is going to proceed to the election of its board. People elected to the board are the legal representatives of the association, but they're also people who contribute their energy and ideas to drive the community.

Anyone who is subscribed to the mailing list can apply to one of these positions:

Please note that other positions could be added if needed.

We'd like to stress that it is not necessary to be a member of the board (or even a member of the permanent organisation team) to organise events under the banner of Montréal-Python; the board is the official organ, but it is you, the members of the community, who do great things with Python in Montreal.

When:

Monday, November 3rd, 8pm

Where:

Ajah offices, 1124 Marie-Anne Est https://goo.gl/maps/xN1ck

How:

Show of hands

Comme see us on Monday! :)

31 Oct 2014 4:00am GMT

Montreal Python User Group: Election for MTL:PY this Monday

It's that time of the year again: the organisation team for the Montréal-Python community is going to proceed to the election of its board. People elected to the board are the legal representatives of the association, but they're also people who contribute their energy and ideas to drive the community.

Anyone who is subscribed to the mailing list can apply to one of these positions:

Please note that other positions could be added if needed.

We'd like to stress that it is not necessary to be a member of the board (or even a member of the permanent organisation team) to organise events under the banner of Montréal-Python; the board is the official organ, but it is you, the members of the community, who do great things with Python in Montreal.

When:

Monday, November 3rd, 8pm

Where:

Ajah offices, 1124 Marie-Anne Est https://goo.gl/maps/xN1ck

How:

Show of hands

Comme see us on Monday! :)

31 Oct 2014 4:00am GMT

30 Oct 2014

feedPlanet Python

PyCharm: JetBrains Debuts PyCharm Educational Edition

If you've ever wanted to learn Python programming, get ready to be blown away.

Today we're launching the free and open source PyCharm Educational Edition for students and teachers. This easy-to-use yet powerful Python IDE includes special interactive educational functionality to help novice programmers learn the craft and turn professional quicker than ever before! It combines the easy learning curve of interactive coding platforms with the power of a real-world professional tool.

screenshot1@2x

Why PyCharm Educational Edition?

We all know that computer programming studies are one of today's major global trends, driven by open-access, non-credit education. Python has long been used for educational purposes and is now the most popular language used to teach programming for beginners. We decided to create this new educational IDE, because we at JetBrains PyCharm, being a part of the Python community, are committed to providing quality, professional, seamless solutions for learning programming with Python, keeping the needs of both novice programmers and educators in mind.

What is so special about PyCharm Educational Edition?

In designing this tool we have been inspired by Guido van Rossum, the creator of the Python programming language, who said:

guido"We believe that there should be no clear-cut distinction between tools used by professionals and tools used for education-just as professional writers use the same language and alphabet as their readers!" https://www.python.org/doc/essays/cp4e/

PyCharm is a professional tool recognized among professionals all around the globe. At some point it occurred to us that, with some work, its power could also be harnessed to serve educational purposes.

We analyzed educational trends and tools on the market carefully. To understand what should be improved in PyCharm and how to make it the best educational IDE possible, we polled hundreds of instructors from different universities all around the world.

1
We found out that there are two opposite approaches to learning programming. One is based on using interactive online educational platforms and editors, which are extremely easy to start with. Despite an easy learning curve, these are not real development tools, and once you get used to them it may be difficult to switch to a real development environment and develop something real. The other approach is centered around real code editors and IDEs tools. While advanced, they are often too complex for beginners. Instead of learning programming, you must invest considerable efforts and time just into understanding how the tool works, before actually learning the essentials of programming.

PyCharm Educational Edition aims to combine both these two worlds. We've made it easy to get started with, not intimidating, yet powerful enough to guide you all the way through to becoming a professional developer.

All the learning you need, for FREE

freePyCharm Educational Edition is absolutely free and open-source. Novice programmers can download and use it for educational or any other purposes-for free. Instructors and course authors can use it to create, modify and share their own courses.

Included are learning essentials like an integrated Python console, Debugger and VCS, along with unique educational features such as "fill in the missing code" exercises, intelligent hints, checks, smart suggestions, code auto-completion, and much more.

So, what's inside, besides the PyCharm Community Edition?

Possible Applications

possiblePyCharm Educational Edition can be used in MOOCs, self-studying courses or traditional programming courses. In addition to going through interactive courses, you can also use normal Python projects and the integrated Python console, as well as the debugger, VCS, and everything else that PyCharm already offers.

What to do next?

Don't wait any longer - download PyCharm Education Edition for your platform and start learning Python programming today!

For more details and learning materials, visit the PyCharm Educational Edition website and check the Quick Start guide to get rolling. Or, for a quick visual overview, watch this introductory video:

Then, get involved:

Read our blog to stay tuned for news, updates and everything that goes on with PyCharm Educational Edition. And do give us feedback on how we're doing.

Did you know?
JetBrains recently launched the Free Student License program. With this program any student or educator can use any JetBrains product for free!

Develop with pleasure!
JetBrains PyCharm Team

30 Oct 2014 6:34pm GMT

PyCharm: JetBrains Debuts PyCharm Educational Edition

If you've ever wanted to learn Python programming, get ready to be blown away.

Today we're launching the free and open source PyCharm Educational Edition for students and teachers. This easy-to-use yet powerful Python IDE includes special interactive educational functionality to help novice programmers learn the craft and turn professional quicker than ever before! It combines the easy learning curve of interactive coding platforms with the power of a real-world professional tool.

screenshot1@2x

Why PyCharm Educational Edition?

We all know that computer programming studies are one of today's major global trends, driven by open-access, non-credit education. Python has long been used for educational purposes and is now the most popular language used to teach programming for beginners. We decided to create this new educational IDE, because we at JetBrains PyCharm, being a part of the Python community, are committed to providing quality, professional, seamless solutions for learning programming with Python, keeping the needs of both novice programmers and educators in mind.

What is so special about PyCharm Educational Edition?

In designing this tool we have been inspired by Guido van Rossum, the creator of the Python programming language, who said:

guido"We believe that there should be no clear-cut distinction between tools used by professionals and tools used for education-just as professional writers use the same language and alphabet as their readers!" https://www.python.org/doc/essays/cp4e/

PyCharm is a professional tool recognized among professionals all around the globe. At some point it occurred to us that, with some work, its power could also be harnessed to serve educational purposes.

We analyzed educational trends and tools on the market carefully. To understand what should be improved in PyCharm and how to make it the best educational IDE possible, we polled hundreds of instructors from different universities all around the world.

1
We found out that there are two opposite approaches to learning programming. One is based on using interactive online educational platforms and editors, which are extremely easy to start with. Despite an easy learning curve, these are not real development tools, and once you get used to them it may be difficult to switch to a real development environment and develop something real. The other approach is centered around real code editors and IDEs tools. While advanced, they are often too complex for beginners. Instead of learning programming, you must invest considerable efforts and time just into understanding how the tool works, before actually learning the essentials of programming.

PyCharm Educational Edition aims to combine both these two worlds. We've made it easy to get started with, not intimidating, yet powerful enough to guide you all the way through to becoming a professional developer.

All the learning you need, for FREE

freePyCharm Educational Edition is absolutely free and open-source. Novice programmers can download and use it for educational or any other purposes-for free. Instructors and course authors can use it to create, modify and share their own courses.

Included are learning essentials like an integrated Python console, Debugger and VCS, along with unique educational features such as "fill in the missing code" exercises, intelligent hints, checks, smart suggestions, code auto-completion, and much more.

So, what's inside, besides the PyCharm Community Edition?

Possible Applications

possiblePyCharm Educational Edition can be used in MOOCs, self-studying courses or traditional programming courses. In addition to going through interactive courses, you can also use normal Python projects and the integrated Python console, as well as the debugger, VCS, and everything else that PyCharm already offers.

What to do next?

Don't wait any longer - download PyCharm Education Edition for your platform and start learning Python programming today!

For more details and learning materials, visit the PyCharm Educational Edition website and check the Quick Start guide to get rolling. Or, for a quick visual overview, watch this introductory video:

Then, get involved:

Read our blog to stay tuned for news, updates and everything that goes on with PyCharm Educational Edition. And do give us feedback on how we're doing.

Did you know?
JetBrains recently launched the Free Student License program. With this program any student or educator can use any JetBrains product for free!

Develop with pleasure!
JetBrains PyCharm Team

30 Oct 2014 6:34pm GMT

Machinalis: IEPY 0.9 was released


We're happy to announce that IEPY 0.9 was released!!
It's an open source tool for Information Extraction focused on Relation Extraction.
It's aimed at:
  • users needing to perform Information Extraction on a large dataset.
  • scientists wanting to experiment with new IE algorithms.

To give an example of Relation Extraction, if we are trying to find a birth date in:

"John von Neumann (December 28, 1903 - February 8, 1957) was a Hungarian and American pure and applied mathematician, physicist, inventor and polymath."

Then IEPY's task is to identify "John von Neumann" and "December 28, 1903" as the subject and object entities of the "was born in" relation.

Features

Documentation: http://iepy.readthedocs.org/en/0.9.0/
Github: https://github.com/machinalis/iepy PyPi: https://pypi.python.org/pypi/iepy twitter:@machinalis

30 Oct 2014 4:28pm GMT

Machinalis: IEPY 0.9 was released


We're happy to announce that IEPY 0.9 was released!!
It's an open source tool for Information Extraction focused on Relation Extraction.
It's aimed at:
  • users needing to perform Information Extraction on a large dataset.
  • scientists wanting to experiment with new IE algorithms.

To give an example of Relation Extraction, if we are trying to find a birth date in:

"John von Neumann (December 28, 1903 - February 8, 1957) was a Hungarian and American pure and applied mathematician, physicist, inventor and polymath."

Then IEPY's task is to identify "John von Neumann" and "December 28, 1903" as the subject and object entities of the "was born in" relation.

Features

Documentation: http://iepy.readthedocs.org/en/0.9.0/
Github: https://github.com/machinalis/iepy PyPi: https://pypi.python.org/pypi/iepy twitter:@machinalis

30 Oct 2014 4:28pm GMT

Hernan Grecco: PyVISA command-line utilities

PyVISA is a Python frontend for the VISA library that enables controlling all kinds of measurement equipment through GPIB, RS232, USB and Ethernet among others interfaces.

If you are following the development of PyVISA you might have seen that we have recently made the visa module executable to provide a few useful utilities. To try this, you need to update to the latest PyVISA:

$ pip install -U https://github.com/hgrecco/pyvisa/zipball/master

First, we now provide a simpler way to get debug information:

$ python -m visa info
Machine Details:
Platform ID: Darwin-10.8.0-x86_64-i386-32bit
Processor: i386

Python:
Implementation: CPython
Executable: /Users/grecco/envs/lantz/bin/python
Version: 3.2.3
Compiler: GCC 4.2.1 (Apple Inc. build 5666) (dot 3)
Bits: 32bit
Build: Apr 10 2012 11:25:50 (#v3.2.3:3d0686d90f55)
Unicode: UCS2

PyVISA Version: 1.6.1

Backends:
ni:
Version: 1.6.1 (bundled with PyVISA)
#1: /Library/Frameworks/visa.framework/visa:
found by: auto
bitness: 32
Vendor: National Instruments
Impl. Version: 5243392
Spec. Version: 5243136
py:
Version: 0.1.dev0
ASRL INSTR: Available via PySerial (10.8.0)
TCPIP INSTR: Available
USB INSTR: Available via PyUSB (1.0.0rc1). Backend: libusb0


Notice also that more useful information is given, including details about the different backends (in this case ni and py).

Another utility is the VISA shell which was taken from the Lantz project. It provides a way to list, open and query devices. It also allows you to get (and in the near future set) attributes. The shell has in-built help, autocomplete and

$ python -m visa shell
Welcome to the VISA shell. Type help or ? to list commands.

(visa) list
( 0) ASRL2::INSTR
( 1) ASRL1::INSTR
(visa) open ASRL1::INSTR
ASRL1::INSTR has been opened.
You can talk to the device using "write", "read" or "query".
The default end of message is added to each message
(open) attr
+-----------------------------+------------+----------------------------+-------------------------------------+
| VISA name | Constant | Python name | val |
+-----------------------------+------------+----------------------------+-------------------------------------+
| VI_ATTR_ASRL_ALLOW_TRANSMIT | 1073676734 | allow_transmit | 1 |
| VI_ATTR_ASRL_AVAIL_NUM | 1073676460 | bytes_in_buffer | 0 |
| VI_ATTR_ASRL_BAUD | 1073676321 | baud_rate | 9600 |
| VI_ATTR_ASRL_BREAK_LEN | 1073676733 | break_length | 250 |
| VI_ATTR_ASRL_BREAK_STATE | 1073676732 | break_state | 0 |
| VI_ATTR_ASRL_CONNECTED | 1073676731 | | VI_ERROR_NSUP_ATTR |
| VI_ATTR_ASRL_CTS_STATE | 1073676462 | | 0 |
| VI_ATTR_ASRL_DATA_BITS | 1073676322 | data_bits | 8 |
| VI_ATTR_ASRL_DCD_STATE | 1073676463 | | 0 |
| VI_ATTR_ASRL_DISCARD_NULL | 1073676464 | discard_null | 0 |
| VI_ATTR_ASRL_DSR_STATE | 1073676465 | | 0 |
| VI_ATTR_ASRL_DTR_STATE | 1073676466 | | 1 |
| VI_ATTR_ASRL_END_IN | 1073676467 | end_input | 2 |
| VI_ATTR_ASRL_END_OUT | 1073676468 | | 0 |
| VI_ATTR_ASRL_FLOW_CNTRL | 1073676325 | | 0 |
| VI_ATTR_ASRL_PARITY | 1073676323 | parity | 0 |
| VI_ATTR_ASRL_REPLACE_CHAR | 1073676478 | replace_char | 0 |
| VI_ATTR_ASRL_RI_STATE | 1073676479 | | 0 |
| VI_ATTR_ASRL_RTS_STATE | 1073676480 | | 1 |
| VI_ATTR_ASRL_STOP_BITS | 1073676324 | stop_bits | 10 |
| VI_ATTR_ASRL_WIRE_MODE | 1073676735 | | 128 |
| VI_ATTR_ASRL_XOFF_CHAR | 1073676482 | xoff_char | 19 |
| VI_ATTR_ASRL_XON_CHAR | 1073676481 | xon_char | 17 |
| VI_ATTR_DMA_ALLOW_EN | 1073676318 | allow_dma | 0 |
| VI_ATTR_FILE_APPEND_EN | 1073676690 | | 0 |
| VI_ATTR_INTF_INST_NAME | 3221160169 | | ASRL1 (/dev/cu.Bluetooth-PDA-Sync) |
| VI_ATTR_INTF_NUM | 1073676662 | interface_number | 1 |
| VI_ATTR_INTF_TYPE | 1073676657 | | 4 |
| VI_ATTR_IO_PROT | 1073676316 | io_protocol | 1 |
| VI_ATTR_MAX_QUEUE_LENGTH | 1073676293 | | 50 |
| VI_ATTR_RD_BUF_OPER_MODE | 1073676330 | | 3 |
| VI_ATTR_RD_BUF_SIZE | 1073676331 | | 4096 |
| VI_ATTR_RM_SESSION | 1073676484 | | 3160976 |
| VI_ATTR_RSRC_CLASS | 3221159937 | resource_class | INSTR |
| VI_ATTR_RSRC_IMPL_VERSION | 1073676291 | implementation_version | 5243392 |
| VI_ATTR_RSRC_LOCK_STATE | 1073676292 | lock_state | 0 |
| VI_ATTR_RSRC_MANF_ID | 1073676661 | | 4086 |
| VI_ATTR_RSRC_MANF_NAME | 3221160308 | resource_manufacturer_name | National Instruments |
| VI_ATTR_RSRC_NAME | 3221159938 | resource_name | ASRL1::INSTR |
| VI_ATTR_RSRC_SPEC_VERSION | 1073676656 | spec_version | 5243136 |
| VI_ATTR_SEND_END_EN | 1073676310 | send_end | 1 |
| VI_ATTR_SUPPRESS_END_EN | 1073676342 | | 0 |
| VI_ATTR_TERMCHAR | 1073676312 | | 10 |
| VI_ATTR_TERMCHAR_EN | 1073676344 | | 0 |
| VI_ATTR_TMO_VALUE | 1073676314 | | 2000 |
| VI_ATTR_TRIG_ID | 1073676663 | | -1 |
| VI_ATTR_WR_BUF_OPER_MODE | 1073676333 | | 2 |
| VI_ATTR_WR_BUF_SIZE | 1073676334 | | 4096 |
+-----------------------------+------------+----------------------------+-------------------------------------+
(open) close
The resource has been closed.



Again, this release is only possible thanks to the contribution of a lot of people that contributed bug reports, testing and code. Thanks to everybody!

Submit your bug reports, comments and suggestions in the Issue Tracker. We will address them promptly.

Read the development docs: https://pyvisa.readthedocs.org/en/master/
or fork the code: https:/https://github.com/hgrecco/pyvisa/

30 Oct 2014 1:33pm GMT

Hernan Grecco: PyVISA command-line utilities

PyVISA is a Python frontend for the VISA library that enables controlling all kinds of measurement equipment through GPIB, RS232, USB and Ethernet among others interfaces.

If you are following the development of PyVISA you might have seen that we have recently made the visa module executable to provide a few useful utilities. To try this, you need to update to the latest PyVISA:

$ pip install -U https://github.com/hgrecco/pyvisa/zipball/master

First, we now provide a simpler way to get debug information:

$ python -m visa info
Machine Details:
Platform ID: Darwin-10.8.0-x86_64-i386-32bit
Processor: i386

Python:
Implementation: CPython
Executable: /Users/grecco/envs/lantz/bin/python
Version: 3.2.3
Compiler: GCC 4.2.1 (Apple Inc. build 5666) (dot 3)
Bits: 32bit
Build: Apr 10 2012 11:25:50 (#v3.2.3:3d0686d90f55)
Unicode: UCS2

PyVISA Version: 1.6.1

Backends:
ni:
Version: 1.6.1 (bundled with PyVISA)
#1: /Library/Frameworks/visa.framework/visa:
found by: auto
bitness: 32
Vendor: National Instruments
Impl. Version: 5243392
Spec. Version: 5243136
py:
Version: 0.1.dev0
ASRL INSTR: Available via PySerial (10.8.0)
TCPIP INSTR: Available
USB INSTR: Available via PyUSB (1.0.0rc1). Backend: libusb0


Notice also that more useful information is given, including details about the different backends (in this case ni and py).

Another utility is the VISA shell which was taken from the Lantz project. It provides a way to list, open and query devices. It also allows you to get (and in the near future set) attributes. The shell has in-built help, autocomplete and

$ python -m visa shell
Welcome to the VISA shell. Type help or ? to list commands.

(visa) list
( 0) ASRL2::INSTR
( 1) ASRL1::INSTR
(visa) open ASRL1::INSTR
ASRL1::INSTR has been opened.
You can talk to the device using "write", "read" or "query".
The default end of message is added to each message
(open) attr
+-----------------------------+------------+----------------------------+-------------------------------------+
| VISA name | Constant | Python name | val |
+-----------------------------+------------+----------------------------+-------------------------------------+
| VI_ATTR_ASRL_ALLOW_TRANSMIT | 1073676734 | allow_transmit | 1 |
| VI_ATTR_ASRL_AVAIL_NUM | 1073676460 | bytes_in_buffer | 0 |
| VI_ATTR_ASRL_BAUD | 1073676321 | baud_rate | 9600 |
| VI_ATTR_ASRL_BREAK_LEN | 1073676733 | break_length | 250 |
| VI_ATTR_ASRL_BREAK_STATE | 1073676732 | break_state | 0 |
| VI_ATTR_ASRL_CONNECTED | 1073676731 | | VI_ERROR_NSUP_ATTR |
| VI_ATTR_ASRL_CTS_STATE | 1073676462 | | 0 |
| VI_ATTR_ASRL_DATA_BITS | 1073676322 | data_bits | 8 |
| VI_ATTR_ASRL_DCD_STATE | 1073676463 | | 0 |
| VI_ATTR_ASRL_DISCARD_NULL | 1073676464 | discard_null | 0 |
| VI_ATTR_ASRL_DSR_STATE | 1073676465 | | 0 |
| VI_ATTR_ASRL_DTR_STATE | 1073676466 | | 1 |
| VI_ATTR_ASRL_END_IN | 1073676467 | end_input | 2 |
| VI_ATTR_ASRL_END_OUT | 1073676468 | | 0 |
| VI_ATTR_ASRL_FLOW_CNTRL | 1073676325 | | 0 |
| VI_ATTR_ASRL_PARITY | 1073676323 | parity | 0 |
| VI_ATTR_ASRL_REPLACE_CHAR | 1073676478 | replace_char | 0 |
| VI_ATTR_ASRL_RI_STATE | 1073676479 | | 0 |
| VI_ATTR_ASRL_RTS_STATE | 1073676480 | | 1 |
| VI_ATTR_ASRL_STOP_BITS | 1073676324 | stop_bits | 10 |
| VI_ATTR_ASRL_WIRE_MODE | 1073676735 | | 128 |
| VI_ATTR_ASRL_XOFF_CHAR | 1073676482 | xoff_char | 19 |
| VI_ATTR_ASRL_XON_CHAR | 1073676481 | xon_char | 17 |
| VI_ATTR_DMA_ALLOW_EN | 1073676318 | allow_dma | 0 |
| VI_ATTR_FILE_APPEND_EN | 1073676690 | | 0 |
| VI_ATTR_INTF_INST_NAME | 3221160169 | | ASRL1 (/dev/cu.Bluetooth-PDA-Sync) |
| VI_ATTR_INTF_NUM | 1073676662 | interface_number | 1 |
| VI_ATTR_INTF_TYPE | 1073676657 | | 4 |
| VI_ATTR_IO_PROT | 1073676316 | io_protocol | 1 |
| VI_ATTR_MAX_QUEUE_LENGTH | 1073676293 | | 50 |
| VI_ATTR_RD_BUF_OPER_MODE | 1073676330 | | 3 |
| VI_ATTR_RD_BUF_SIZE | 1073676331 | | 4096 |
| VI_ATTR_RM_SESSION | 1073676484 | | 3160976 |
| VI_ATTR_RSRC_CLASS | 3221159937 | resource_class | INSTR |
| VI_ATTR_RSRC_IMPL_VERSION | 1073676291 | implementation_version | 5243392 |
| VI_ATTR_RSRC_LOCK_STATE | 1073676292 | lock_state | 0 |
| VI_ATTR_RSRC_MANF_ID | 1073676661 | | 4086 |
| VI_ATTR_RSRC_MANF_NAME | 3221160308 | resource_manufacturer_name | National Instruments |
| VI_ATTR_RSRC_NAME | 3221159938 | resource_name | ASRL1::INSTR |
| VI_ATTR_RSRC_SPEC_VERSION | 1073676656 | spec_version | 5243136 |
| VI_ATTR_SEND_END_EN | 1073676310 | send_end | 1 |
| VI_ATTR_SUPPRESS_END_EN | 1073676342 | | 0 |
| VI_ATTR_TERMCHAR | 1073676312 | | 10 |
| VI_ATTR_TERMCHAR_EN | 1073676344 | | 0 |
| VI_ATTR_TMO_VALUE | 1073676314 | | 2000 |
| VI_ATTR_TRIG_ID | 1073676663 | | -1 |
| VI_ATTR_WR_BUF_OPER_MODE | 1073676333 | | 2 |
| VI_ATTR_WR_BUF_SIZE | 1073676334 | | 4096 |
+-----------------------------+------------+----------------------------+-------------------------------------+
(open) close
The resource has been closed.



Again, this release is only possible thanks to the contribution of a lot of people that contributed bug reports, testing and code. Thanks to everybody!

Submit your bug reports, comments and suggestions in the Issue Tracker. We will address them promptly.

Read the development docs: https://pyvisa.readthedocs.org/en/master/
or fork the code: https:/https://github.com/hgrecco/pyvisa/

30 Oct 2014 1:33pm GMT

Reinout van Rees: Ubuntu PPA madness

I'm going flipping insane. In ye olde days, when I was programming with the python CMS Plone, my dependencies were limited to python and PIL. Perhaps lxml. LXML was a pain to install sometimes, but there were ways around it.

Working on OSX was no problem. Server setup? Ubuntu. The only thing you really had to watch in those days was your python version. Does this old site still depends on python 2.4 or is it fine to use 2.6? Plone had its own Zope database, so you didn't even need database bindings.

Now I'm working on Django sites. No problem with Django, btw! But... the sites we build with it are pretty elaborate geographical websites with lots of dependencies. Mapnik, matplotlib, numpy, scipy, gdal, spatialite, postgis. And that's not the full list. So developing on OSX is no fun anymore, using a virtual machine (virtualbox or vmware) is a necessity. So: Ubuntu.

But... ubuntu 12.04, which we still use on most of the servers, has too-old versions of several of those packages. We need a newer gdal, for instance. And a newer spatialite. The common solution is to use a PPA for that, like ubuntugis-stable.

Now for some random things that can go wrong:

  • We absolutely need a newer gdal, so we add the ubuntugis-stable PPA. This has nice new versions for lots of geo-related packages, for instance the "proj" projection library.

  • It doesn't include the "python-pyproj" package, though, which means that the ubuntu-installed python-pyproj package is compiled against a different proj library. Which means your django site segfaults. Digging deep with strace was needed to discover the problem.

  • Of course, if you need that latest gdal for your site, you add the PPA to the server. Everything runs fine.

  • A month later, the server has to be rebooted. Now the three other sites on that same server fail to start due to the pyproj-segfault. Nobody bothered to check the other sites on the server, of course. (This happened three times on different servers. This is the sort of stuff that makes you cast a doubtful eye on our quite liberal "sudo" policy...)

  • Pinning pyproj to 1.9.3 helped, as 1.9.3 worked around the issue by bundling the proj library instead of relying on the OS-packaged one.

  • Ubuntugis-stable sounds stable, but they're of course focused on getting the latest geo packages into ubuntu. So they switched from gdal 1.9 to 1.10 somewhere around june. So /usr/lib/libgdal1.so became /usr/lib/libgdal1h.so and suddenly "apt-get update/upgrade" took down many sites.

    See this travis-ci issue for some background.

  • The solution for this PPA problem was another PPA: the postgres one. That includes gdal 1.9 instead of the too-new 1.10.

  • Possible problem: the postgres PPA also uses 1.9 on the new ubuntu 14.04. 14.04 contains gdal 1.10, so using the postgres PPA downgrades gdal. That cannot but break a lot of things for us.

  • I just discovered a site that couldn't possibly work. It needs the ubuntugis-stable PPA as it needs a recent spatialite. But it also needs the postgres PPA for the 1.9 gdal! And those two don't match.

  • It still works, though. I'm not totally sure why. On a compilation machine where we build a custom debian package for one of the components, the postgres PPA was installed manually outside of the automatic build scripts. And a jenkins server where we test it still has the ubuntugis PPA, but somehow it still has the old 1.9 gdal. Probably someone pinned it?

  • Another reason is probably that one of the components was compiled before the 1.9/1.10 gdal change and didn't need re-compilation yet. Once that must be done we're probably in deep shit.

  • If I look at some ansible scripts that are used to set up some of our servers, I see the ubuntugis PPA, the mapnik/v2.2.0 PPA and the redis PPA. Oh, how can that ever work? The software on those servers needs the 1.9 gdal, right?

  • I asked a colleague. Apparently the servers were all created before june and they haven't done an "apt-get upgrade" since. That's why they still work.

Personally, I think the best way forward is to use ubuntu 14.04 LTS with its recent versions. And to stick to the base ubuntu as much as possible. And if one or two packages are needed in more recent versions, try to somehow make a custom package for it without breaking the rest. I did something like that for mapnik, where we somehow needed the ancient 0.7 version on some servers.

If a PPA equates to never being able to do "apt-get update", I don't really think it is the best way forward for servers that really have to stay up.

Does someone have other thoughts? Other solutions? And no, I don't think docker containers are the solution as throwing around PPAs doesn't get more stable once you isolate it in a container. You don't break anything else, true, but the container itself can be broken by an update just fine.

30 Oct 2014 10:10am GMT

Reinout van Rees: Ubuntu PPA madness

I'm going flipping insane. In ye olde days, when I was programming with the python CMS Plone, my dependencies were limited to python and PIL. Perhaps lxml. LXML was a pain to install sometimes, but there were ways around it.

Working on OSX was no problem. Server setup? Ubuntu. The only thing you really had to watch in those days was your python version. Does this old site still depends on python 2.4 or is it fine to use 2.6? Plone had its own Zope database, so you didn't even need database bindings.

Now I'm working on Django sites. No problem with Django, btw! But... the sites we build with it are pretty elaborate geographical websites with lots of dependencies. Mapnik, matplotlib, numpy, scipy, gdal, spatialite, postgis. And that's not the full list. So developing on OSX is no fun anymore, using a virtual machine (virtualbox or vmware) is a necessity. So: Ubuntu.

But... ubuntu 12.04, which we still use on most of the servers, has too-old versions of several of those packages. We need a newer gdal, for instance. And a newer spatialite. The common solution is to use a PPA for that, like ubuntugis-stable.

Now for some random things that can go wrong:

  • We absolutely need a newer gdal, so we add the ubuntugis-stable PPA. This has nice new versions for lots of geo-related packages, for instance the "proj" projection library.

  • It doesn't include the "python-pyproj" package, though, which means that the ubuntu-installed python-pyproj package is compiled against a different proj library. Which means your django site segfaults. Digging deep with strace was needed to discover the problem.

  • Of course, if you need that latest gdal for your site, you add the PPA to the server. Everything runs fine.

  • A month later, the server has to be rebooted. Now the three other sites on that same server fail to start due to the pyproj-segfault. Nobody bothered to check the other sites on the server, of course. (This happened three times on different servers. This is the sort of stuff that makes you cast a doubtful eye on our quite liberal "sudo" policy...)

  • Pinning pyproj to 1.9.3 helped, as 1.9.3 worked around the issue by bundling the proj library instead of relying on the OS-packaged one.

  • Ubuntugis-stable sounds stable, but they're of course focused on getting the latest geo packages into ubuntu. So they switched from gdal 1.9 to 1.10 somewhere around june. So /usr/lib/libgdal1.so became /usr/lib/libgdal1h.so and suddenly "apt-get update/upgrade" took down many sites.

    See this travis-ci issue for some background.

  • The solution for this PPA problem was another PPA: the postgres one. That includes gdal 1.9 instead of the too-new 1.10.

  • Possible problem: the postgres PPA also uses 1.9 on the new ubuntu 14.04. 14.04 contains gdal 1.10, so using the postgres PPA downgrades gdal. That cannot but break a lot of things for us.

  • I just discovered a site that couldn't possibly work. It needs the ubuntugis-stable PPA as it needs a recent spatialite. But it also needs the postgres PPA for the 1.9 gdal! And those two don't match.

  • It still works, though. I'm not totally sure why. On a compilation machine where we build a custom debian package for one of the components, the postgres PPA was installed manually outside of the automatic build scripts. And a jenkins server where we test it still has the ubuntugis PPA, but somehow it still has the old 1.9 gdal. Probably someone pinned it?

  • Another reason is probably that one of the components was compiled before the 1.9/1.10 gdal change and didn't need re-compilation yet. Once that must be done we're probably in deep shit.

  • If I look at some ansible scripts that are used to set up some of our servers, I see the ubuntugis PPA, the mapnik/v2.2.0 PPA and the redis PPA. Oh, how can that ever work? The software on those servers needs the 1.9 gdal, right?

  • I asked a colleague. Apparently the servers were all created before june and they haven't done an "apt-get upgrade" since. That's why they still work.

Personally, I think the best way forward is to use ubuntu 14.04 LTS with its recent versions. And to stick to the base ubuntu as much as possible. And if one or two packages are needed in more recent versions, try to somehow make a custom package for it without breaking the rest. I did something like that for mapnik, where we somehow needed the ancient 0.7 version on some servers.

If a PPA equates to never being able to do "apt-get update", I don't really think it is the best way forward for servers that really have to stay up.

Does someone have other thoughts? Other solutions? And no, I don't think docker containers are the solution as throwing around PPAs doesn't get more stable once you isolate it in a container. You don't break anything else, true, but the container itself can be broken by an update just fine.

30 Oct 2014 10:10am GMT

S. Lott: My First Webcast

http://www.oreilly.com/pub/e/3255

I'm a pretty good public speaker. But I've avoided webcasting and podcasting because it's kind of daunting. In a smaller venue, the audience members are right there, and you can tell if you're not making sense. In a webcast, the feedback will be indirect. In a podcast it's seems like it would be nonexistent.

Also, I find that programming is an intensely literate experience. It's about reading and writing. A podcast -- listening and watching -- seems very un-programmerly to me. Perhaps I'm just being an old "get-of-my-lawn-you-kids" fart.

But I'll see how the webcast thing goes in January, and perhaps I'll try to do some podcasts.

30 Oct 2014 8:00am GMT

S. Lott: My First Webcast

http://www.oreilly.com/pub/e/3255

I'm a pretty good public speaker. But I've avoided webcasting and podcasting because it's kind of daunting. In a smaller venue, the audience members are right there, and you can tell if you're not making sense. In a webcast, the feedback will be indirect. In a podcast it's seems like it would be nonexistent.

Also, I find that programming is an intensely literate experience. It's about reading and writing. A podcast -- listening and watching -- seems very un-programmerly to me. Perhaps I'm just being an old "get-of-my-lawn-you-kids" fart.

But I'll see how the webcast thing goes in January, and perhaps I'll try to do some podcasts.

30 Oct 2014 8:00am GMT

Calvin Spealman: The Curl Pipe

If anything deserves to be called an anti-pattern it is probably the common and worry-inducing practice of documenting your installation process by asking asking users to copy and paste a line into their shell that will snag some file off the internet and pipe its contents directly into your shell to execute.


Sometimes this is even done as root.


This is something known to be awful, but which remains a cornerstone via its use by some of the most important tools in our belts. Homebrew does it. NPM does it, too. And some projects look better, but are they? Pip asks you to download get-pip.py and run it to install, which isn't practically any different than piping from curl, just less efficient.


But worst of all, we might as well be doing this even more often, because our most depended about tooling is all just as guilty even without doing the curl pipe sh dance. What do you think happens when you pip install your favorite Python package, anyway? Pip downloads a file from the internet and executes it. Simple as that, for the purposes here. Sure, these days we have saner defaults. It has to be HTTPS and it has to be from PyPI by default, but its not like these packages are screened.


For all our concerns about security and frets over SHELLSHOCK and POODLE vulnerabilities, doesn't it seem like the developer community does an awful lot of executing random files off the internet?

30 Oct 2014 2:56am GMT

Calvin Spealman: The Curl Pipe

If anything deserves to be called an anti-pattern it is probably the common and worry-inducing practice of documenting your installation process by asking asking users to copy and paste a line into their shell that will snag some file off the internet and pipe its contents directly into your shell to execute.


Sometimes this is even done as root.


This is something known to be awful, but which remains a cornerstone via its use by some of the most important tools in our belts. Homebrew does it. NPM does it, too. And some projects look better, but are they? Pip asks you to download get-pip.py and run it to install, which isn't practically any different than piping from curl, just less efficient.


But worst of all, we might as well be doing this even more often, because our most depended about tooling is all just as guilty even without doing the curl pipe sh dance. What do you think happens when you pip install your favorite Python package, anyway? Pip downloads a file from the internet and executes it. Simple as that, for the purposes here. Sure, these days we have saner defaults. It has to be HTTPS and it has to be from PyPI by default, but its not like these packages are screened.


For all our concerns about security and frets over SHELLSHOCK and POODLE vulnerabilities, doesn't it seem like the developer community does an awful lot of executing random files off the internet?

30 Oct 2014 2:56am GMT

Armin Ronacher: Don't Panic! The Hitchhiker's Guide to Unwinding

Rust has an awesome developer community but sometimes emotions can cloud the discussions that are taking place. One of the more interesting discussions (or should I say flamewars) evolve around the concept of stack unwinding in Rust. I consider myself very strongly on one side of this topic but I have not been aware of how hot this topic is until I accidentally tweeted by preference. Since then I spent a bit of time reading up no the issue and figured I might write about it since it is quite an interesting topic and has huge implications on how the language works.

What is this About?

As I wrote last time, there are two different error handling models in Rust these days. In this blog post I will call them result carriers and panics.

A result carrier is a type that can carry either a success value or a failure value. In Rust there are currently two very strong ones and a weak one: the strong ones are Result<T, E> which carries a T result value or an E error value and the Option<T> value which either carries a T result value or None which indicates that no value exists. By convention there is also a weak one which is bool which generally indicates success by signalling true and failure by signalling false. There is a proposal to actually formalize the carrier concept by introducing a Carrier trait that can (within reason) convert between any of those types which would aid composability.

The second way to indicate failure is a panic. Unlike value carriers which are passed through the stack explicitly in the form of return values, panics fly through the stack until they arrive at the frame of the task in which case they will terminate it. Panics are for all intents and purposes task failures. The way this works is by unwinding the stack slice by slice, invoking cleanup code at each level and finally terminate the task. Panics are intended for situations where the runtime runs out of choices about how to deal with this failure.

Why the Panic?

Currently there is definitely a case where there are too many calls in Rust that will just panic. For me one of the prime examples of something that panics in a not very nice way is the default print function. In fact, your rust Hello World example can panic if invoked the wrong way:

$ ./hello
Hello World!
$ ./hello 1< /dev/null
task '<main>' panicked at 'failed printing to stdout: Bad file descriptor'

The "task panicked" message is a task responding to a panic. It immediately stops doing what it does and prints an error message to stderr. It's a very prevalent problem unfortunately with the APIs currently as people do not want to deal with explicit error handling through value carriers and as such use the APIs that just fail the task (like println). That all the tutorials in Rust also go down this road because it's easier to read is not exactly helping.

One of my favorite examples is that the rustc compiler's pretty printing will cause an internal compiler error when piped into less and less is closed with the q key because the pipe is shutting down:

$ rustc a-long-example.rs --pretty=expanded|less
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task '<main>' panicked at 'failed printing to stdout: broken pipe (Broken pipe)'

The answer to why the panic is that computers are hard and many things can fail. In C for instance printf returns an integer which can indicate if the command failed. Did you ever check it? In Rust the policy is to not let failure go through silently and because nobody feels like handling failures of every single print statement, that panicking behavior is in place for many common APIs.

But let's assume those APIs would not panic but require explicit error handling, why do we even need panics? Primarily the problem comes up in situations where a programming error happened that could not have been detected at compile time or the environment in which the application is executing is not providing the assumptions the application makes. Some good examples for the former are out of bound access in arrays and an example for the latter are out of memory errors.

Rust has safe and unsafe access to array members but the vast majority of array access goes through the unsafe access. Unsafe in this case does not mean that you get garbage back, but it means that the runtime will panic and terminate the task. Everything is still safe and everything but you just killed your thread of execution.

For memory errors and things of that nature it's more tricky. malloc in C returns you a null pointer when it fails to allocate. It looks a bit obvious that if you just inherit this behavior you don't need to panic. What that would allow you to do is to run a bit longer after you ran out of memory but there is very little you can actually do from this point onwards. The reason for this is that you just ran out of memory and you are at risk that any further thing you are going to do in order to recover from it, is going to run into the same issue. This is especially a problem if your error representation in itself requires memory. This is hardly a problem that is unique to Rust. Python for instance when it boots up needs to preallocate a MemoryError so that if it ever runs out of memory has an error it can use to indicate the failure as it might be impossible at that point to actually allocate enough memory to represent the out of memory failure.

You would be limited to only calling things that do not allocate anything which might be close to impossible to do. For instance there is no guarantee that just printing a message to stdout does not require an internal allocation.

What's Unwinding?

Stack unwinding is what makes panics in Rust work. To understand how it works you need to understand that Rust sticks very close to the metal and as such stack unwinding requires an agreed upon protocol to work.

When you raise an exception you need to immediately bubble up stack frame by stack frame until you hit your exception handler. In case of Rust you will hit the code that shuts down the task as you cannot setup handlers yourself. However as you blaze through the stack frames, Rust needs to execute all necessary cleanup code on each level so that no memory or resources leak.

This unwinding protocol is highly related to the calling conventions and not at all standardized. One of the big problems with stack unwinding is that it's not exactly an operation that comes natural to program execution, at least not on modern processors. When you want to fly through some stack frames you need to figure out what was the previous stack frame. On AMD64 for instance there is no guaranteed way to get a stacktrace at all without implementing DWARF. However stack unwinding does have the assumed benefit that because you are generally not going down the error path, there are less branches to take when a function returns as the calling frame does not have to check for an error result. If an error does occur, stack unwinding automatically jumps to the error branch and otherwise it's not considered.

What's the Problem with Unwinding?

Traditionally I think there are two problems with stack unwinding. The first one is that unlike function calling conventions, stack unwinding is not particularly standardized. This is especially a problem if you try to combine functions from different programing languages together. The most portable ABI is the C ABI and that one does not know anything about stack unwinding. There is some standardization on some operating systems but even then it does not guarantee that it will be used. For instance on Windows there is Structured Exception Handling (SEH) which however is not used by LLVM currently and as such not by Rust.

If the stack unwinding is not standardized between different languages it automatically limits the usefulness. For instance if you want to use a C++ library from another programming language, your best bet is actually to expose a C interface for it. This also means that any function you invoke through the C wrapper needs to catch down all exceptions and report them through an alternative mechanism out, making it more complicated for everybody. This even causes quite a bit of pain in the absence of actually going through a programming language boundary. If you ever used the PPL libraries (a framework for asynchronous task handling and parallelism) on Windows you might have seen how it internally catches down exceptions and reconstructs them in other places to make them travel between threads safely.

The second problem with stack unwinding is that it's really complex. In order to unwind a stack you need to figure out what your parent frame actually is. This is not necessarily a simple thing to do. On AMD64 for instance there is not enough information available on the stack to find higher stack frames so your only option is to implement the very complex DWARF spec or change the calling conventions so that you do have enough meta information on the stack. This might be simple for a project that has full control of all dependencies, but the moment you call into a library you did not compile, this no longer works.

It's no surprise that stack unwinding traditionally is one of the worse supported features in programming languages. It's not unheard of that a compiler does not implement exceptions for C++ and the reason for this is that stack unwinding is a complex thing. Even if they do implement it, very often exceptions are just made to work but not made to be fast.

Exceptions in a Systems Language

You don't have to be a kernel developer to not be a fan of stack unwinding. Any person that wants to develop a shared library that is used by other people will sooner or later have to think about how to prevent things from throwing exceptions. In C++ it's not hard to actually wrap all exported functions in huge try / catch blocks that will just catch down everything and report a failure code out, but in Rust it's currently actually a bit more complex.

The reason for this is that in Rust you cannot actually handle exceptions. When a function panics it terminates the task. This implies that there needs to be task in the first place that can isolate the exception or you cause issues for your users. Because tasks furthermore are actually threads the cost of encapsulating every function call in a thread does not sound very appealing.

Today you already are in the situation in Rust that if you write a library that wants to export a C ABI and is used by other people you can already not call into functions that panic unless you are in the situation where your system is generally running a thread and you dispatch messages into it.

Panicking Less and Disabling Unwinding

I wish I personally have for the language is that you can write code that is guaranteed to not panic unless it really ends up in a situation where it has no other choice. The biggest areas of concern there are traditionally memory allocations. However in the vast majority of situations failure from memory allocation is actually not something you need to be concerned with. Modern operating systems make it quite hard to end up in a situation where an allocation fails. There is virtual memory management and swapping and OOM killers. An malloc that returns null in a real world situation, other than by passing an unrealistically large size, is quite uncommon. And on embedded systems or similar situations you usually already keep an eye on if you are within your budget and you just avoid ever hitting the limit. This allocation problem is also a lot smaller if you are you a specialized context where you just avoid generic containers that allocate memory on regular operations.

Once panics are unlikely to happen, it's an option to disable the support for unwinding and to just abort the application if a panic ever happens. While this sounds pretty terrible, this is actually the right thing to do for a wide range of environments.

The best way to isolate failures is on the operating system level through separate processes. This sounds worse than it actually is for two reasons: the first is that the operating system provides good support for shipping data between processes. Especially for server applications the ability to have a watchdog processes that runs very little critical code, opens sockets and passes the file descriptors into worker processes is a very convincing concept. If you do end up crashing the worker no request is lost other than the currently handled one if it's single threaded. And if it's multi threaded you might kill a few more requests but new, incoming requests are completely oblivious that a failure happened as they will queue up in the socket held by the watchdog. This is something that systemd and launchd for instance provide out of the box.

In Rust especially a process boundary is a lot less scary than in other programming languages because the language design strongly discourages global state and encourages message passing.

Less Panic Needs Better APIs

The bigger problem than making panic a fatal thing and removing unwinding, is actually providing good APIs that make this less important. The biggest problem with coming up with replacements for panics is that any stack frame needs to deal with failure explicitly. If you end up writing a function that only ever returned a true or false for indicating success or failure, but you now need to call into something that might fail with important and valuable error information you do not have a channel to pass that information out without changing your own function's interface.

The other problem is that nobody wants to deal with failure if they can avoid doing so. The print example is a good one because it's the type of application where people really do not want to deal with it. "What can go wrong with printing". Unfortunately a lot. There are some proposals for Rust about how error propagation and handling can be made nicer but we're quite far from this reality.

Until we arrive there, I don't think disabling of stack unwinding would be a good idea. On the long run however I hope it's a goal because it would make Rust both more portable and interesting as a language to write reusable libraries in.

30 Oct 2014 12:00am GMT

Armin Ronacher: Don't Panic! The Hitchhiker's Guide to Unwinding

Rust has an awesome developer community but sometimes emotions can cloud the discussions that are taking place. One of the more interesting discussions (or should I say flamewars) evolve around the concept of stack unwinding in Rust. I consider myself very strongly on one side of this topic but I have not been aware of how hot this topic is until I accidentally tweeted by preference. Since then I spent a bit of time reading up no the issue and figured I might write about it since it is quite an interesting topic and has huge implications on how the language works.

What is this About?

As I wrote last time, there are two different error handling models in Rust these days. In this blog post I will call them result carriers and panics.

A result carrier is a type that can carry either a success value or a failure value. In Rust there are currently two very strong ones and a weak one: the strong ones are Result<T, E> which carries a T result value or an E error value and the Option<T> value which either carries a T result value or None which indicates that no value exists. By convention there is also a weak one which is bool which generally indicates success by signalling true and failure by signalling false. There is a proposal to actually formalize the carrier concept by introducing a Carrier trait that can (within reason) convert between any of those types which would aid composability.

The second way to indicate failure is a panic. Unlike value carriers which are passed through the stack explicitly in the form of return values, panics fly through the stack until they arrive at the frame of the task in which case they will terminate it. Panics are for all intents and purposes task failures. The way this works is by unwinding the stack slice by slice, invoking cleanup code at each level and finally terminate the task. Panics are intended for situations where the runtime runs out of choices about how to deal with this failure.

Why the Panic?

Currently there is definitely a case where there are too many calls in Rust that will just panic. For me one of the prime examples of something that panics in a not very nice way is the default print function. In fact, your rust Hello World example can panic if invoked the wrong way:

$ ./hello
Hello World!
$ ./hello 1< /dev/null
task '<main>' panicked at 'failed printing to stdout: Bad file descriptor'

The "task panicked" message is a task responding to a panic. It immediately stops doing what it does and prints an error message to stderr. It's a very prevalent problem unfortunately with the APIs currently as people do not want to deal with explicit error handling through value carriers and as such use the APIs that just fail the task (like println). That all the tutorials in Rust also go down this road because it's easier to read is not exactly helping.

One of my favorite examples is that the rustc compiler's pretty printing will cause an internal compiler error when piped into less and less is closed with the q key because the pipe is shutting down:

$ rustc a-long-example.rs --pretty=expanded|less
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task '<main>' panicked at 'failed printing to stdout: broken pipe (Broken pipe)'

The answer to why the panic is that computers are hard and many things can fail. In C for instance printf returns an integer which can indicate if the command failed. Did you ever check it? In Rust the policy is to not let failure go through silently and because nobody feels like handling failures of every single print statement, that panicking behavior is in place for many common APIs.

But let's assume those APIs would not panic but require explicit error handling, why do we even need panics? Primarily the problem comes up in situations where a programming error happened that could not have been detected at compile time or the environment in which the application is executing is not providing the assumptions the application makes. Some good examples for the former are out of bound access in arrays and an example for the latter are out of memory errors.

Rust has safe and unsafe access to array members but the vast majority of array access goes through the unsafe access. Unsafe in this case does not mean that you get garbage back, but it means that the runtime will panic and terminate the task. Everything is still safe and everything but you just killed your thread of execution.

For memory errors and things of that nature it's more tricky. malloc in C returns you a null pointer when it fails to allocate. It looks a bit obvious that if you just inherit this behavior you don't need to panic. What that would allow you to do is to run a bit longer after you ran out of memory but there is very little you can actually do from this point onwards. The reason for this is that you just ran out of memory and you are at risk that any further thing you are going to do in order to recover from it, is going to run into the same issue. This is especially a problem if your error representation in itself requires memory. This is hardly a problem that is unique to Rust. Python for instance when it boots up needs to preallocate a MemoryError so that if it ever runs out of memory has an error it can use to indicate the failure as it might be impossible at that point to actually allocate enough memory to represent the out of memory failure.

You would be limited to only calling things that do not allocate anything which might be close to impossible to do. For instance there is no guarantee that just printing a message to stdout does not require an internal allocation.

What's Unwinding?

Stack unwinding is what makes panics in Rust work. To understand how it works you need to understand that Rust sticks very close to the metal and as such stack unwinding requires an agreed upon protocol to work.

When you raise an exception you need to immediately bubble up stack frame by stack frame until you hit your exception handler. In case of Rust you will hit the code that shuts down the task as you cannot setup handlers yourself. However as you blaze through the stack frames, Rust needs to execute all necessary cleanup code on each level so that no memory or resources leak.

This unwinding protocol is highly related to the calling conventions and not at all standardized. One of the big problems with stack unwinding is that it's not exactly an operation that comes natural to program execution, at least not on modern processors. When you want to fly through some stack frames you need to figure out what was the previous stack frame. On AMD64 for instance there is no guaranteed way to get a stacktrace at all without implementing DWARF. However stack unwinding does have the assumed benefit that because you are generally not going down the error path, there are less branches to take when a function returns as the calling frame does not have to check for an error result. If an error does occur, stack unwinding automatically jumps to the error branch and otherwise it's not considered.

What's the Problem with Unwinding?

Traditionally I think there are two problems with stack unwinding. The first one is that unlike function calling conventions, stack unwinding is not particularly standardized. This is especially a problem if you try to combine functions from different programing languages together. The most portable ABI is the C ABI and that one does not know anything about stack unwinding. There is some standardization on some operating systems but even then it does not guarantee that it will be used. For instance on Windows there is Structured Exception Handling (SEH) which however is not used by LLVM currently and as such not by Rust.

If the stack unwinding is not standardized between different languages it automatically limits the usefulness. For instance if you want to use a C++ library from another programming language, your best bet is actually to expose a C interface for it. This also means that any function you invoke through the C wrapper needs to catch down all exceptions and report them through an alternative mechanism out, making it more complicated for everybody. This even causes quite a bit of pain in the absence of actually going through a programming language boundary. If you ever used the PPL libraries (a framework for asynchronous task handling and parallelism) on Windows you might have seen how it internally catches down exceptions and reconstructs them in other places to make them travel between threads safely.

The second problem with stack unwinding is that it's really complex. In order to unwind a stack you need to figure out what your parent frame actually is. This is not necessarily a simple thing to do. On AMD64 for instance there is not enough information available on the stack to find higher stack frames so your only option is to implement the very complex DWARF spec or change the calling conventions so that you do have enough meta information on the stack. This might be simple for a project that has full control of all dependencies, but the moment you call into a library you did not compile, this no longer works.

It's no surprise that stack unwinding traditionally is one of the worse supported features in programming languages. It's not unheard of that a compiler does not implement exceptions for C++ and the reason for this is that stack unwinding is a complex thing. Even if they do implement it, very often exceptions are just made to work but not made to be fast.

Exceptions in a Systems Language

You don't have to be a kernel developer to not be a fan of stack unwinding. Any person that wants to develop a shared library that is used by other people will sooner or later have to think about how to prevent things from throwing exceptions. In C++ it's not hard to actually wrap all exported functions in huge try / catch blocks that will just catch down everything and report a failure code out, but in Rust it's currently actually a bit more complex.

The reason for this is that in Rust you cannot actually handle exceptions. When a function panics it terminates the task. This implies that there needs to be task in the first place that can isolate the exception or you cause issues for your users. Because tasks furthermore are actually threads the cost of encapsulating every function call in a thread does not sound very appealing.

Today you already are in the situation in Rust that if you write a library that wants to export a C ABI and is used by other people you can already not call into functions that panic unless you are in the situation where your system is generally running a thread and you dispatch messages into it.

Panicking Less and Disabling Unwinding

I wish I personally have for the language is that you can write code that is guaranteed to not panic unless it really ends up in a situation where it has no other choice. The biggest areas of concern there are traditionally memory allocations. However in the vast majority of situations failure from memory allocation is actually not something you need to be concerned with. Modern operating systems make it quite hard to end up in a situation where an allocation fails. There is virtual memory management and swapping and OOM killers. An malloc that returns null in a real world situation, other than by passing an unrealistically large size, is quite uncommon. And on embedded systems or similar situations you usually already keep an eye on if you are within your budget and you just avoid ever hitting the limit. This allocation problem is also a lot smaller if you are you a specialized context where you just avoid generic containers that allocate memory on regular operations.

Once panics are unlikely to happen, it's an option to disable the support for unwinding and to just abort the application if a panic ever happens. While this sounds pretty terrible, this is actually the right thing to do for a wide range of environments.

The best way to isolate failures is on the operating system level through separate processes. This sounds worse than it actually is for two reasons: the first is that the operating system provides good support for shipping data between processes. Especially for server applications the ability to have a watchdog processes that runs very little critical code, opens sockets and passes the file descriptors into worker processes is a very convincing concept. If you do end up crashing the worker no request is lost other than the currently handled one if it's single threaded. And if it's multi threaded you might kill a few more requests but new, incoming requests are completely oblivious that a failure happened as they will queue up in the socket held by the watchdog. This is something that systemd and launchd for instance provide out of the box.

In Rust especially a process boundary is a lot less scary than in other programming languages because the language design strongly discourages global state and encourages message passing.

Less Panic Needs Better APIs

The bigger problem than making panic a fatal thing and removing unwinding, is actually providing good APIs that make this less important. The biggest problem with coming up with replacements for panics is that any stack frame needs to deal with failure explicitly. If you end up writing a function that only ever returned a true or false for indicating success or failure, but you now need to call into something that might fail with important and valuable error information you do not have a channel to pass that information out without changing your own function's interface.

The other problem is that nobody wants to deal with failure if they can avoid doing so. The print example is a good one because it's the type of application where people really do not want to deal with it. "What can go wrong with printing". Unfortunately a lot. There are some proposals for Rust about how error propagation and handling can be made nicer but we're quite far from this reality.

Until we arrive there, I don't think disabling of stack unwinding would be a good idea. On the long run however I hope it's a goal because it would make Rust both more portable and interesting as a language to write reusable libraries in.

30 Oct 2014 12:00am GMT

29 Oct 2014

feedPlanet Python

Brett Cannon: Bringing someone into the modern age of technology

A relative just visited whose current technology consists of a Windows computer and a flip-phone. It was one of those situations where someone was coming to me as a blank slate for a technology upgrade! So I seized on the moment and made some recommendations.

For a phone I said he should get either a phone from Motorola, Google, or Apple. It would come down to price and who was going to provide technical support as to exactly which phone they should get.

For a computer we actually gave the relative an old Chromebook. With no baggage as to some set of programs they had to have access to, it made the decision easy. Even if we didn't have a spare Chromebook to give away I would have suggested a Chromebook for its price and ease of maintenance. This probably would have also led to a suggestion of a new printer that supported Google Cloud Print to work with the Chromebook. And then the final perk was the integration with Google Drive as a way to move them into cloud backup.

For watching movies I would suggest getting a Netflix account and either a Chromecast or Roku box depending on their comfort level. I personally prefer Chromecast for its flexibility but I realize some people just prefer having a dedicated remote control.

Finally, we said to consider a music streaming service and Sonos. For ease of setup Sonos is great when someone doesn't have pre-existing A/V equipment that they need to work with. And a streaming service like Google Play Music All-Access gives quick access to digital music to a level people who are upgrading their technological lives are not used to.

29 Oct 2014 11:37pm GMT

Brett Cannon: Bringing someone into the modern age of technology

A relative just visited whose current technology consists of a Windows computer and a flip-phone. It was one of those situations where someone was coming to me as a blank slate for a technology upgrade! So I seized on the moment and made some recommendations.

For a phone I said he should get either a phone from Motorola, Google, or Apple. It would come down to price and who was going to provide technical support as to exactly which phone they should get.

For a computer we actually gave the relative an old Chromebook. With no baggage as to some set of programs they had to have access to, it made the decision easy. Even if we didn't have a spare Chromebook to give away I would have suggested a Chromebook for its price and ease of maintenance. This probably would have also led to a suggestion of a new printer that supported Google Cloud Print to work with the Chromebook. And then the final perk was the integration with Google Drive as a way to move them into cloud backup.

For watching movies I would suggest getting a Netflix account and either a Chromecast or Roku box depending on their comfort level. I personally prefer Chromecast for its flexibility but I realize some people just prefer having a dedicated remote control.

Finally, we said to consider a music streaming service and Sonos. For ease of setup Sonos is great when someone doesn't have pre-existing A/V equipment that they need to work with. And a streaming service like Google Play Music All-Access gives quick access to digital music to a level people who are upgrading their technological lives are not used to.

29 Oct 2014 11:37pm GMT

Paul Everitt: Faster relevance ranking didn’t make it into PostgreSQL 9.4

Alas, the one big feature we really needed, the patch apparently got rejected.

PostgreSQL has a nice little full-text search story, especially when you combine it with other parts of our story (security-aware filtering of results, transactional integrity, etc.) Searches are very, very fast.

However, the next step - ranking the results - isn't so fast. It requires a table scan (likely to TOAST files, meaning read a file and gunzip its contents) on every row that matched.

In our case, we're doing prefix searches, and lots and lots of rows match. Lots. And the performance is, well, horrible. Oleg and friends had a super-fast speedup for this ready for PostgreSQL 9.4, but it apparently got rejected.

So we're stuck. It's too big a transition to switch to ElasticSearch or something. The customer probably should bail on prefix searching (autocomplete) but they won't. We have an idea for doing this the right way (convert prefixes to candidate full words, as Google does, using PG's built-in lexeme tools) but that is also too much for budget. Finally, we don't have the option to throw SSDs at it.


29 Oct 2014 5:34pm GMT

Paul Everitt: Faster relevance ranking didn’t make it into PostgreSQL 9.4

Alas, the one big feature we really needed, the patch apparently got rejected.

PostgreSQL has a nice little full-text search story, especially when you combine it with other parts of our story (security-aware filtering of results, transactional integrity, etc.) Searches are very, very fast.

However, the next step - ranking the results - isn't so fast. It requires a table scan (likely to TOAST files, meaning read a file and gunzip its contents) on every row that matched.

In our case, we're doing prefix searches, and lots and lots of rows match. Lots. And the performance is, well, horrible. Oleg and friends had a super-fast speedup for this ready for PostgreSQL 9.4, but it apparently got rejected.

So we're stuck. It's too big a transition to switch to ElasticSearch or something. The customer probably should bail on prefix searching (autocomplete) but they won't. We have an idea for doing this the right way (convert prefixes to candidate full words, as Google does, using PG's built-in lexeme tools) but that is also too much for budget. Finally, we don't have the option to throw SSDs at it.


29 Oct 2014 5:34pm GMT

10 Nov 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: King Willams Town Bahnhof

Gestern musste ich morgens zur Station nach KWT um unsere Rerservierten Bustickets für die Weihnachtsferien in Capetown abzuholen. Der Bahnhof selber ist seit Dezember aus kostengründen ohne Zugverbindung - aber Translux und co - die langdistanzbusse haben dort ihre Büros.


Größere Kartenansicht




© benste CC NC SA

10 Nov 2011 10:57am GMT

09 Nov 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein

Niemand ist besorgt um so was - mit dem Auto fährt man einfach durch, und in der City - nahe Gnobie- "ne das ist erst gefährlich wenn die Feuerwehr da ist" - 30min später auf dem Rückweg war die Feuerwehr da.




© benste CC NC SA

09 Nov 2011 8:25pm GMT

08 Nov 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: Brai Party

Brai = Grillabend o.ä.

Die möchte gern Techniker beim Flicken ihrer SpeakOn / Klinke Stecker Verzweigungen...

Die Damen "Mamas" der Siedlung bei der offiziellen Eröffnungsrede

Auch wenn weniger Leute da waren als erwartet, Laute Musik und viele Leute ...

Und natürlich ein Feuer mit echtem Holz zum Grillen.

© benste CC NC SA

08 Nov 2011 2:30pm GMT

07 Nov 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: Lumanyano Primary

One of our missions was bringing Katja's Linux Server back to her room. While doing that we saw her new decoration.

Björn, Simphiwe carried the PC to Katja's school


© benste CC NC SA

07 Nov 2011 2:00pm GMT

06 Nov 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: Nelisa Haircut

Today I went with Björn to Needs Camp to Visit Katja's guest family for a special Party. First of all we visited some friends of Nelisa - yeah the one I'm working with in Quigney - Katja's guest fathers sister - who did her a haircut.

African Women usually get their hair done by arranging extensions and not like Europeans just cutting some hair.

In between she looked like this...

And then she was done - looks amazing considering the amount of hair she had last week - doesn't it ?

© benste CC NC SA

06 Nov 2011 7:45pm GMT

05 Nov 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: Mein Samstag

Irgendwie viel mir heute auf das ich meine Blogposts mal ein bischen umstrukturieren muss - wenn ich immer nur von neuen Plätzen berichte, dann müsste ich ja eine Rundreise machen. Hier also mal ein paar Sachen aus meinem heutigen Alltag.

Erst einmal vorweg, Samstag zählt zumindest für uns Voluntäre zu den freien Tagen.

Dieses Wochenende sind nur Rommel und ich auf der Farm - Katja und Björn sind ja mittlerweile in ihren Einsatzstellen, und meine Mitbewohner Kyle und Jonathan sind zu Hause in Grahamstown - sowie auch Sipho der in Dimbaza wohnt.
Robin, die Frau von Rommel ist in Woodie Cape - schon seit Donnerstag um da ein paar Sachen zur erledigen.
Naja wie dem auch sei heute morgen haben wir uns erstmal ein gemeinsames Weetbix/Müsli Frühstück gegönnt und haben uns dann auf den Weg nach East London gemacht. 2 Sachen waren auf der Checkliste Vodacom, Ethienne (Imobilienmakler) außerdem auf dem Rückweg die fehlenden Dinge nach NeedsCamp bringen.

Nachdem wir gerade auf der Dirtroad losgefahren sind mussten wir feststellen das wir die Sachen für Needscamp und Ethienne nicht eingepackt hatten aber die Pumpe für die Wasserversorgung im Auto hatten.

Also sind wir in EastLondon ersteinmal nach Farmerama - nein nicht das onlinespiel farmville - sondern einen Laden mit ganz vielen Sachen für eine Farm - in Berea einem nördlichen Stadteil gefahren.

In Farmerama haben wir uns dann beraten lassen für einen Schnellverschluss der uns das leben mit der Pumpe leichter machen soll und außerdem eine leichtere Pumpe zur Reperatur gebracht, damit es nicht immer so ein großer Aufwand ist, wenn mal wieder das Wasser ausgegangen ist.

Fego Caffé ist in der Hemmingways Mall, dort mussten wir und PIN und PUK einer unserer Datensimcards geben lassen, da bei der PIN Abfrage leider ein zahlendreher unterlaufen ist. Naja auf jeden Fall speichern die Shops in Südafrika so sensible Daten wie eine PUK - die im Prinzip zugang zu einem gesperrten Phone verschafft.

Im Cafe hat Rommel dann ein paar online Transaktionen mit dem 3G Modem durchgeführt, welches ja jetzt wieder funktionierte - und übrigens mittlerweile in Ubuntu meinem Linuxsystem perfekt klappt.

Nebenbei bin ich nach 8ta gegangen um dort etwas über deren neue Deals zu erfahren, da wir in einigen von Hilltops Centern Internet anbieten wollen. Das Bild zeigt die Abdeckung UMTS in NeedsCamp Katjas Ort. 8ta ist ein neuer Telefonanbieter von Telkom, nachdem Vodafone sich Telkoms anteile an Vodacom gekauft hat müssen die komplett neu aufbauen.
Wir haben uns dazu entschieden mal eine kostenlose Prepaidkarte zu testen zu organisieren, denn wer weis wie genau die Karte oben ist ... Bevor man einen noch so billigen Deal für 24 Monate signed sollte man wissen obs geht.

Danach gings nach Checkers in Vincent, gesucht wurden zwei Hotplates für WoodyCape - R 129.00 eine - also ca. 12€ für eine zweigeteilte Kochplatte.
Wie man sieht im Hintergrund gibts schon Weihnachtsdeko - Anfang November und das in Südafrika bei sonnig warmen min- 25°C

Mittagessen haben wir uns bei einem Pakistanischen Curry Imbiss gegönnt - sehr empfehlenswert !
Naja und nachdem wir dann vor ner Stunde oder so zurück gekommen sind habe ich noch den Kühlschrank geputzt den ich heute morgen zum defrosten einfach nach draußen gestellt hatte. Jetzt ist der auch mal wieder sauber und ohne 3m dicke Eisschicht...

Morgen ... ja darüber werde ich gesondert berichten ... aber vermutlich erst am Montag, denn dann bin ich nochmal wieder in Quigney(East London) und habe kostenloses Internet.

© benste CC NC SA

05 Nov 2011 4:33pm GMT

31 Oct 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: Sterkspruit Computer Center

Sterkspruit is one of Hilltops Computer Centres in the far north of Eastern Cape. On the trip to J'burg we've used the opportunity to take a look at the centre.

Pupils in the big classroom


The Trainer


School in Countryside


Adult Class in the Afternoon


"Town"


© benste CC NC SA

31 Oct 2011 4:58pm GMT

Benedict Stein: Technical Issues

What are you doing in an internet cafe if your ADSL and Faxline has been discontinued before months end. Well my idea was sitting outside and eating some ice cream.
At least it's sunny and not as rainy as on the weekend.


© benste CC NC SA

31 Oct 2011 3:11pm GMT

30 Oct 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: Nellis Restaurant

For those who are traveling through Zastron - there is a very nice Restaurant which is serving delicious food at reasanable prices.
In addition they're selling home made juices jams and honey.




interior


home made specialities - the shop in the shop


the Bar


© benste CC NC SA

30 Oct 2011 4:47pm GMT

29 Oct 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: The way back from J'burg

Having the 10 - 12h trip from J'burg back to ELS I was able to take a lot of pcitures including these different roadsides

Plain Street


Orange River in its beginngings (near Lesotho)


Zastron Anglican Church


The Bridge in Between "Free State" and Eastern Cape next to Zastron


my new Background ;)


If you listen to GoogleMaps you'll end up traveling 50km of gravel road - as it was just renewed we didn't have that many problems and saved 1h compared to going the official way with all it's constructions sites




Freeway


getting dark


© benste CC NC SA

29 Oct 2011 4:23pm GMT

28 Oct 2011

feedPython Software Foundation | GSoC'11 Students

Benedict Stein: Wie funktioniert eigentlich eine Baustelle ?

Klar einiges mag anders sein, vieles aber gleich - aber ein in Deutschland täglich übliches Bild einer Straßenbaustelle - wie läuft das eigentlich in Südafrika ?

Ersteinmal vorweg - NEIN keine Ureinwohner die mit den Händen graben - auch wenn hier mehr Manpower genutzt wird - sind sie fleißig mit Technologie am arbeiten.

Eine ganz normale "Bundesstraße"


und wie sie erweitert wird


gaaaanz viele LKWs


denn hier wird eine Seite über einen langen Abschnitt komplett gesperrt, so das eine Ampelschaltung mit hier 45 Minuten Wartezeit entsteht


Aber wenigstens scheinen die ihren Spaß zu haben ;) - Wie auch wir denn gücklicher Weise mussten wir nie länger als 10 min. warten.

© benste CC NC SA

28 Oct 2011 4:20pm GMT