April 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Report about the D4D datathon challenge

by Thierry Goubier

Le 09/04/2015 22:37, stepharo a Ã©crit : > Superb > > Now what would be great is to continue to story to make sure that Pharo > and roassal can be used for real. > Having a streaming API for files is apparently a first step. We have such a streaming API. (In the case of the D4D, we had. NeoCSV has it)... But if the VM is unable to open the file in the first place :( What can we do? Thierry > > Stef > > > Le 9/4/15 20:10, volkert a Ã©crit : >> Great story and great work. Really helpfull to get a feeling about the >> current "limits" of >> the Pharo Platform ... far away from my current data volume >> requirements, but >> good to know ... >> >> Thanks for sharing. >> >> BW, >> Volkert >> >> Am 09.04.2015 um 16:52 schrieb Serge Stinckwich: >>> Dear all, >>> >>> this is a small report about the RESILIENCE team using Pharo&Roassal >>> for the D4D datathon challenge: http://www.d4d.orange.com/en/home >>> >>> The idea was to use mobile network data from Senegal provided by >>> Orange company in order to solve some development problems. >>> >>> The amount of data provided by Orange was really huge, something like >>> 66 Gb: we have the number and the durations of calls between each >>> pairs of GSM >>> antennas in Senegal (1666 different antennas) and also some >>> information about the mobility of people. You can find more >>> information about the data here: >>> http://arxiv.org/abs/1407.4885 >>> >>> We try to extract some data from August 2013, because we know that >>> some floods occurs at that time in Dakar. Our main objective was to to >>> be able to visualise mobility and communications patterns with ROASSAL >>> to see if there is any differences before and after the floods. >>> >>> We had a lot of problems to solve in a short period of time :-) >>> >>> At the beginning, we couldn't open huge files with Pharo. Only open a >>> file that is around 3.4Go is impossible. Pharo says that the file does >>> not exist. >>> Thierry tells us that us that one must compile the VM with >>> -D_FILE_OFFSET_BITS=64. (the Cog VMs are also built with >>> -D_GNU_SOURCE). >>> Why this is not done by default ? >>> >>> After that we decide to split the files in many smaller files and we >>> try to use a mySQL database and various other tools but still have >>> many troubles because of the size of the data ... At the end, we have >>> done some visualisations but only on a tiny portion of the data on one >>> day (one day is around 100Mb of data). You could find some >>> visualisations done by our team here: >>> https://twitter.com/sergestinckwich/status/586178094215606273 >>> >>> Managing huge amount in Pharo and also ROASSAL is still a challenge >>> and we definitively need more tools in this area. >>> >>> We had some problems with ROASSAL: bugs with RTEdgesBuilder (Alvaro >>> can you send a report to Alex about that ?), to much time to process >>> some viz, ... >>> >>> At the end, our team receive the honorary price: >>> https://twitter.com/sergestinckwich/status/585866625745887232 >>> >>> This is a brief description of our project. >>> >>> ========================================================= >>> Project name: RESILIENCE >>> Team members: ClÃ©mence Douard (ENSCI), Onil Goubier (CIRELA), Alvaro >>> Peralta (LabU / Chile University), AurÃ©lie Thouron (ENSCI), Serge >>> Stinckwich >>> (IRD / UMMISCO) >>> >>> The main concern of this project is to improve resilience after an >>> environmental crisis in a southern city. During the preparedness phase >>> before crisis, records of inhabitants habits (like patterns of >>> mobility or communications) are done in order to characterize the >>> situation before the crisis. Assessments of the improvements will then >>> be done by providing suitable visualizations of the resilience >>> dynamic. The goal is to help citizens to represent these improvements >>> and to take advantage of them in their daily lives. >>> >>> We took as an example the city of Dakar during the flooding that >>> occurred in August 2013. >>> >>> The data used are those of the dataset 1 (communication between >>> antennas) and 2 (user mobility) provided Orange. We use this >>> information, coupled to OSM, and other data related to floods of >>> August in Dakar to construct maps and indicators to show resilience. >>> Visualizations are made with agile visualization platform Roassal: >>> http://agilevisualization.com/ >>> ========================================================= >>> >>> I would like to thank all the team members and also the people who >>> help us remotely: Alexandre Bergel (ObjectProfile/Chile University) >>> and Thierry Goubier (CEA) >>> >>> I would like to thank also the SIMPLON team and ORANGE for organizing >>> such a nice event. >>> >>> Regards, >> >> >> > > > >

April 9, 2015

Re: [Pharo-users] Report about the D4D datathon challenge

by Serge Stinckwich

On Thu, Apr 9, 2015 at 8:32 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> On 09 Apr 2015, at 20:10, volkert <volkert(a)komponentenwerkstatt.de> wrote: >> >> Great story and great work. Really helpfull to get a feeling about the current "limits" of >> the Pharo Platform ... far away from my current data volume requirements, but >> good to know ... >> >> Thanks for sharing. >> >> BW, >> Volkert >> >> Am 09.04.2015 um 16:52 schrieb Serge Stinckwich: >>> Dear all, >>> >>> this is a small report about the RESILIENCE team using Pharo&Roassal >>> for the D4D datathon challenge: http://www.d4d.orange.com/en/home >>> >>> The idea was to use mobile network data from Senegal provided by >>> Orange company in order to solve some development problems. >>> >>> The amount of data provided by Orange was really huge, something like >>> 66 Gb: we have the number and the durations of calls between each pairs of GSM >>> antennas in Senegal (1666 different antennas) and also some >>> information about the mobility of people. You can find more >>> information about the data here: >>> http://arxiv.org/abs/1407.4885 >>> >>> We try to extract some data from August 2013, because we know that >>> some floods occurs at that time in Dakar. Our main objective was to to >>> be able to visualise mobility and communications patterns with ROASSAL >>> to see if there is any differences before and after the floods. >>> >>> We had a lot of problems to solve in a short period of time :-) >>> >>> At the beginning, we couldn't open huge files with Pharo. Only open a >>> file that is around 3.4Go is impossible. Pharo says that the file does >>> not exist. >>> Thierry tells us that us that one must compile the VM with >>> -D_FILE_OFFSET_BITS=64. (the Cog VMs are also built with >>> -D_GNU_SOURCE). >>> Why this is not done by default ? > > no ideaâ¦ probably because I donât work in windows then this things escapes to me :) We use a Linux VM. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 9, 2015

Re: [Pharo-users] Report about the D4D datathon challenge

by stepharo

Superb Now what would be great is to continue to story to make sure that Pharo and roassal can be used for real. Having a streaming API for files is apparently a first step. Stef Le 9/4/15 20:10, volkert a Ã©crit : > Great story and great work. Really helpfull to get a feeling about the > current "limits" of > the Pharo Platform ... far away from my current data volume > requirements, but > good to know ... > > Thanks for sharing. > > BW, > Volkert > > Am 09.04.2015 um 16:52 schrieb Serge Stinckwich: >> Dear all, >> >> this is a small report about the RESILIENCE team using Pharo&Roassal >> for the D4D datathon challenge: http://www.d4d.orange.com/en/home >> >> The idea was to use mobile network data from Senegal provided by >> Orange company in order to solve some development problems. >> >> The amount of data provided by Orange was really huge, something like >> 66 Gb: we have the number and the durations of calls between each >> pairs of GSM >> antennas in Senegal (1666 different antennas) and also some >> information about the mobility of people. You can find more >> information about the data here: >> http://arxiv.org/abs/1407.4885 >> >> We try to extract some data from August 2013, because we know that >> some floods occurs at that time in Dakar. Our main objective was to to >> be able to visualise mobility and communications patterns with ROASSAL >> to see if there is any differences before and after the floods. >> >> We had a lot of problems to solve in a short period of time :-) >> >> At the beginning, we couldn't open huge files with Pharo. Only open a >> file that is around 3.4Go is impossible. Pharo says that the file does >> not exist. >> Thierry tells us that us that one must compile the VM with >> -D_FILE_OFFSET_BITS=64. (the Cog VMs are also built with >> -D_GNU_SOURCE). >> Why this is not done by default ? >> >> After that we decide to split the files in many smaller files and we >> try to use a mySQL database and various other tools but still have >> many troubles because of the size of the data ... At the end, we have >> done some visualisations but only on a tiny portion of the data on one >> day (one day is around 100Mb of data). You could find some >> visualisations done by our team here: >> https://twitter.com/sergestinckwich/status/586178094215606273 >> >> Managing huge amount in Pharo and also ROASSAL is still a challenge >> and we definitively need more tools in this area. >> >> We had some problems with ROASSAL: bugs with RTEdgesBuilder (Alvaro >> can you send a report to Alex about that ?), to much time to process >> some viz, ... >> >> At the end, our team receive the honorary price: >> https://twitter.com/sergestinckwich/status/585866625745887232 >> >> This is a brief description of our project. >> >> ========================================================= >> Project name: RESILIENCE >> Team members: ClÃ©mence Douard (ENSCI), Onil Goubier (CIRELA), Alvaro >> Peralta (LabU / Chile University), AurÃ©lie Thouron (ENSCI), Serge >> Stinckwich >> (IRD / UMMISCO) >> >> The main concern of this project is to improve resilience after an >> environmental crisis in a southern city. During the preparedness phase >> before crisis, records of inhabitants habits (like patterns of >> mobility or communications) are done in order to characterize the >> situation before the crisis. Assessments of the improvements will then >> be done by providing suitable visualizations of the resilience >> dynamic. The goal is to help citizens to represent these improvements >> and to take advantage of them in their daily lives. >> >> We took as an example the city of Dakar during the flooding that >> occurred in August 2013. >> >> The data used are those of the dataset 1 (communication between >> antennas) and 2 (user mobility) provided Orange. We use this >> information, coupled to OSM, and other data related to floods of >> August in Dakar to construct maps and indicators to show resilience. >> Visualizations are made with agile visualization platform Roassal: >> http://agilevisualization.com/ >> ========================================================= >> >> I would like to thank all the team members and also the people who >> help us remotely: Alexandre Bergel (ObjectProfile/Chile University) >> and Thierry Goubier (CEA) >> >> I would like to thank also the SIMPLON team and ORANGE for organizing >> such a nice event. >> >> Regards, > > >

April 9, 2015

Re: [Pharo-users] String operations

by stepharo

It will be a first "draft" Stef Le 9/4/15 22:07, Tudor Girba a Ã©crit : > Great. I am interested in providing feedback. > > Doru > > On Thu, Apr 9, 2015 at 3:34 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi sean > > with damien we are restarting to work on analysing String API. > We would like to have it much more regular. We will finish a first > small articles > summarizing our analysis and send it around. > > Stef > > Le 9/4/15 12:59, Sean P. DeNigris a Ã©crit : > > Damien Pollet-2 wrote > > Indeed, there is much to say about the String API :) > Thanks for mentioning this, I'm gathering missing behavior > like this ! > > It seems unanimous that we should add these. I agree that they > are useful in > some cases. However, strings are so general that IMHO there > are infinite > such operations that we could add. Already "String methodDict > size = 333", > and one can't depend on method protocols to sort things out > because they are > hijacked for package extensions, so it's easy to be fooled by > thinking "let > me check the converting protocol for that" and (maybe) finding > out later > that you missed it because #asXyz is in *OtherPackage, which > now forces you > to manually scroll through 333 methods to make sure your > desired message > hasn't been implemented. > > So I'm not saying "don't add them". I just want to have a > conversation > about: > 1. How often would these be needed? (We should have that > conversation about > most of String's methods) > 2. Do we have any plans for real protocols, with the concepts > of privacy and > package extension extracted into other objects where they belong? > 3. In the mean time, what is a reasonable cognitive limit for > an API? For me > 333 is way beyond comprehension with the current tooling, > crippled somewhat > by #2. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/String-operations-tp4817803p4818540.html > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

April 9, 2015

Re: [Pharo-users] Report about the D4D datathon challenge

by Sean P. DeNigris

EstebanLM wrote > I added the flags to the builds and hopefully tomorrow there will be > capable VMs. Step by step we will get there :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Report-about-the-D4D-datathon-challenge-tp4818602p481… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 9, 2015

Re: [Pharo-users] String operations

by Tudor Girba

Great. I am interested in providing feedback. Doru On Thu, Apr 9, 2015 at 3:34 PM, stepharo <stepharo(a)free.fr> wrote: > Hi sean > > with damien we are restarting to work on analysing String API. > We would like to have it much more regular. We will finish a first small > articles > summarizing our analysis and send it around. > > Stef > > Le 9/4/15 12:59, Sean P. DeNigris a Ã©crit : > > Damien Pollet-2 wrote >> >>> Indeed, there is much to say about the String API :) >>> Thanks for mentioning this, I'm gathering missing behavior like this ! >>> >> It seems unanimous that we should add these. I agree that they are useful >> in >> some cases. However, strings are so general that IMHO there are infinite >> such operations that we could add. Already "String methodDict size = 333", >> and one can't depend on method protocols to sort things out because they >> are >> hijacked for package extensions, so it's easy to be fooled by thinking >> "let >> me check the converting protocol for that" and (maybe) finding out later >> that you missed it because #asXyz is in *OtherPackage, which now forces >> you >> to manually scroll through 333 methods to make sure your desired message >> hasn't been implemented. >> >> So I'm not saying "don't add them". I just want to have a conversation >> about: >> 1. How often would these be needed? (We should have that conversation >> about >> most of String's methods) >> 2. Do we have any plans for real protocols, with the concepts of privacy >> and >> package extension extracted into other objects where they belong? >> 3. In the mean time, what is a reasonable cognitive limit for an API? For >> me >> 333 is way beyond comprehension with the current tooling, crippled >> somewhat >> by #2. >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/String- >> operations-tp4817803p4818540.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

April 9, 2015

CFP IWST 2015 - Deadline extension - 17th April

by jannik laval

Please note that the deadline has been extended to the 17th April 2015 . [Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST15 â International Workshop on Smalltalk Technologies Brescia, Italy; July 15, 2015 http://www.esug.org/wiki/pier/Conferences/2015/International-Workshop-IWST_… ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- *Submission deadline: April 17th, 2015* Notification deadline: May 20th, 2015 Workshop : July 15th, 2015 All accepted papers will be published in ACM DL ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be eligible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst2015 ------------------- Program chairs ------------------- Anne Etien (UniversitÃ© de Lille 1, France) Jannik Laval (Ecole des Mines de Douai, France) -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

April 9, 2015

builder pattern

by Peter UhnÃ¡k

Is there some common / best way for coding builders? Two ways that I see are: a) using a block - I've seen this in menus and some other, however in my case I need to add an extra parameter as label "variant with two params" aForm addDropList: 'Type' with: [ :dropList | dropList items: #(input #output); " ... ". ]. "variant with one method param and value holder" aForm addDropList: [ :labelHolder :dropList | labelHolder value: 'Type'. dropList items: #(input #output); " ... ". ]. b) using return value - no blocks, no extra code (aForm addDropList: 'Type') items: #(input #output); " ... ". I would use the second variant as it looks much cleaner, however considering how widespread is the use of the first variant I think I must be missing something. Thanks, Peter

April 9, 2015

Re: [Pharo-users] pillar internal link

by Peter UhnÃ¡k

> > ${inputFile:myFile.pillar}$ > on your file to include your myFile.pillar. > Cool! I can stop using my Ruby-based preprocessing soon :). (Especially when the variant with the scripts will be added.) > How do you feel about also having a GitHub repo for the Pillar project? > That way, we could open individual issues for those to-do items, and have > discussions on each one, assign them to people who are working on them > (instead of emailing you), etc? > As a Pillar user (=not developer) the idea that I would have to go check some issue tracker somewhere isn't very appealing. To me it seems fine to discuss implementation details there, but since majority of people are Pillar users, notifying them or having broader discussion on the issues seems much more fitting for a mailing list. Peter

April 9, 2015

Re: [Pharo-users] Report about the D4D datathon challenge

by Esteban Lorenzano

> On 09 Apr 2015, at 20:10, volkert <volkert(a)komponentenwerkstatt.de> wrote: > > Great story and great work. Really helpfull to get a feeling about the current "limits" of > the Pharo Platform ... far away from my current data volume requirements, but > good to know ... > > Thanks for sharing. > > BW, > Volkert > > Am 09.04.2015 um 16:52 schrieb Serge Stinckwich: >> Dear all, >> >> this is a small report about the RESILIENCE team using Pharo&Roassal >> for the D4D datathon challenge: http://www.d4d.orange.com/en/home >> >> The idea was to use mobile network data from Senegal provided by >> Orange company in order to solve some development problems. >> >> The amount of data provided by Orange was really huge, something like >> 66 Gb: we have the number and the durations of calls between each pairs of GSM >> antennas in Senegal (1666 different antennas) and also some >> information about the mobility of people. You can find more >> information about the data here: >> http://arxiv.org/abs/1407.4885 >> >> We try to extract some data from August 2013, because we know that >> some floods occurs at that time in Dakar. Our main objective was to to >> be able to visualise mobility and communications patterns with ROASSAL >> to see if there is any differences before and after the floods. >> >> We had a lot of problems to solve in a short period of time :-) >> >> At the beginning, we couldn't open huge files with Pharo. Only open a >> file that is around 3.4Go is impossible. Pharo says that the file does >> not exist. >> Thierry tells us that us that one must compile the VM with >> -D_FILE_OFFSET_BITS=64. (the Cog VMs are also built with >> -D_GNU_SOURCE). >> Why this is not done by default ? no ideaâ¦ probably because I donât work in windows then this things escapes to me :) I added the flags to the builds and hopefully tomorrow there will be capable VMs. cheers, Esteban >> >> After that we decide to split the files in many smaller files and we >> try to use a mySQL database and various other tools but still have >> many troubles because of the size of the data ... At the end, we have >> done some visualisations but only on a tiny portion of the data on one >> day (one day is around 100Mb of data). You could find some >> visualisations done by our team here: >> https://twitter.com/sergestinckwich/status/586178094215606273 >> >> Managing huge amount in Pharo and also ROASSAL is still a challenge >> and we definitively need more tools in this area. >> >> We had some problems with ROASSAL: bugs with RTEdgesBuilder (Alvaro >> can you send a report to Alex about that ?), to much time to process >> some viz, ... >> >> At the end, our team receive the honorary price: >> https://twitter.com/sergestinckwich/status/585866625745887232 >> >> This is a brief description of our project. >> >> ========================================================= >> Project name: RESILIENCE >> Team members: ClÃ©mence Douard (ENSCI), Onil Goubier (CIRELA), Alvaro >> Peralta (LabU / Chile University), AurÃ©lie Thouron (ENSCI), Serge Stinckwich >> (IRD / UMMISCO) >> >> The main concern of this project is to improve resilience after an >> environmental crisis in a southern city. During the preparedness phase >> before crisis, records of inhabitants habits (like patterns of >> mobility or communications) are done in order to characterize the >> situation before the crisis. Assessments of the improvements will then >> be done by providing suitable visualizations of the resilience >> dynamic. The goal is to help citizens to represent these improvements >> and to take advantage of them in their daily lives. >> >> We took as an example the city of Dakar during the flooding that >> occurred in August 2013. >> >> The data used are those of the dataset 1 (communication between >> antennas) and 2 (user mobility) provided Orange. We use this >> information, coupled to OSM, and other data related to floods of >> August in Dakar to construct maps and indicators to show resilience. >> Visualizations are made with agile visualization platform Roassal: >> http://agilevisualization.com/ >> ========================================================= >> >> I would like to thank all the team members and also the people who >> help us remotely: Alexandre Bergel (ObjectProfile/Chile University) >> and Thierry Goubier (CEA) >> >> I would like to thank also the SIMPLON team and ORANGE for organizing >> such a nice event. >> >> Regards, > >

April 9, 2015