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

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

by volkert

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] pillar internal link

by Dmitri Zagidulin

On Thu, Apr 9, 2015 at 11:02 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > > So, any chance to make them multi-line capable? > > that's a feature I would also like to see. Would you please add this to > the list of feature requests? > http://www.smalltalkhub.com/#!/~Pier/Pillar. I've just added > DmitriZagidulin to the Pier members. The next step would be for you to > add the corresponding automated tests. > Oh, thanks! Appreciated. I added that item to the TODO list on the Pillar SH repo. 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?

April 9, 2015

SDL2 and fork

by Matthieu Lacaton

Hello everyone, I tried to use the SDL2 binding to Pharo to create a very basic 2D application (just some sprites and events) and it worked great. The issue I have is that when I start my application, as long as I have an active SDL window, I can't use my Pharo image anymore (it freezes). To solve this problem I tried opening my application in another thread by doing so : [ (MyApplication new) start. ] forkAt: Processor lowestPriority. (If I don't chose a low priority it changes nothing) The problem is that even if it kind of works, it is really slow and it slows my whole operating system as well (I use windows XP) How can I fork more efficiently or open a SDL window without losing control of my image ? Thanks, Matthieu

April 9, 2015

Re: [Pharo-users] pillar internal link

by Damien Cassou

Dmitri Zagidulin <dmitri(a)zagidulin.net> writes: > Ahh, that's very cool! > > Though this is way off-topic from internal links (but I'm not sure where to > bring this up, if there's a pillar repo somewhere) -- is there any way you > can implement multi-line annotations? (and multi-line list items, for that > matter). Using either an open/close syntax, or Markdown style (where if the > next line begins with 4 spaces, it's counted as a continuation of the > previous line. > > I bump into this a lot, with the PBE book. Working on a large text file > using GitHub for version control kind of neccesitates hard line breaks at > 80 chars. (Otherwise it's very awkward to see diffs, since long lines > require scrolling horizontally). > > Regular Pillar paragraphs can be hard-wrapped at 80 chars no problem. But > annotation lines or list item lines cannot. So one is stuck either avoiding > them altogether (and emulating them using bold / italic / etc), or having > to deal with the difficulty with diffs. > > So, any chance to make them multi-line capable? that's a feature I would also like to see. Would you please add this to the list of feature requests? http://www.smalltalkhub.com/#!/~Pier/Pillar. I've just added DmitriZagidulin to the Pier members. The next step would be for you to add the corresponding automated tests. Best -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 9, 2015

Report about the D4D datathon challenge

by 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, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 9, 2015

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by Norbert Hartl

> Am 09.04.2015 um 15:54 schrieb stepharo <stepharo(a)free.fr>: > > > > Le 8/4/15 11:16, Norbert Hartl a Ã©crit : >> What you are after? A static site generator or a dynamic engine? > > A mix between the two. > I want simple static contents + logic generated :) Haha, some goes for me. Just didn't find time so far to make that wish a bit more concrete. Norbert >> Btw. what do you use to render pillar inside the image to something readable? >> >> Norbert >> >>> Am 08.04.2015 um 08:32 schrieb stepharo <stepharo(a)free.fr>: >>> >>> I started to work on using pillar to do that but nothing ready for people to use. >>> I will work on it at Lviv or during my vacations just after. >>> I want to use it for my website. Right now parts of it are automatically generated from Pharo. >>> >>> Stef >>> >>> Le 7/4/15 10:56, Yuriy Tymchuk a Ã©crit : >>>> Oh, I knew that there was a discussion about that, but couldnât find where. >>>> >>>> Still, is anybody else using Marina except for Pharo website? >>>> >>>> Uko >>>> >>>> >>>> >>>>> On 07 Apr 2015, at 10:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>>>> >>>>> >>>>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: >>>>> >>>>>> if I want to create a site/blog in pharoâ¦ What do I use? I know that >>>>>> there is Pier, but when you check its webpage, the last update is in >>>>>> 2011. Pharo website is built with Marina, but when I check the repo, >>>>>> the last commit was done by me and it was 2 month ago. Will Marina >>>>>> continue to evolve? And is anyone else using Marina? >>>>> http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615… >>>>> -- >>>>> Damien Cassou >>>>> http://damiencassou.seasidehosting.st >>>>> >>>>> "Success is the ability to go from one failure to another without >>>>> losing enthusiasm." --Winston Churchill >>>>> >>>> >>> >> >> > >

April 9, 2015

Re: [Pharo-users] pillar internal link

by Dmitri Zagidulin

Ahh, that's very cool! Though this is way off-topic from internal links (but I'm not sure where to bring this up, if there's a pillar repo somewhere) -- is there any way you can implement multi-line annotations? (and multi-line list items, for that matter). Using either an open/close syntax, or Markdown style (where if the next line begins with 4 spaces, it's counted as a continuation of the previous line. I bump into this a lot, with the PBE book. Working on a large text file using GitHub for version control kind of neccesitates hard line breaks at 80 chars. (Otherwise it's very awkward to see diffs, since long lines require scrolling horizontally). Regular Pillar paragraphs can be hard-wrapped at 80 chars no problem. But annotation lines or list item lines cannot. So one is stuck either avoiding them altogether (and emulating them using bold / italic / etc), or having to deal with the difficulty with diffs. So, any chance to make them multi-line capable? Thanks again! On Thursday, April 9, 2015, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > Hi. > With Damien we're working on the creation of Annotation and Transformers. > > Now you can use this Annotation's tag : > ${inputFile:myFile.pillar}$ > on your file to include your myFile.pillar. > > That still can change a bit, i'm working on it and i still need to do the > tests. > > On 7 April 2015 at 18:40, Dmitri Zagidulin <dmitri(a)zagidulin.net > <javascript:_e(%7B%7D,'cvml','dmitri(a)zagidulin.net');>> wrote: > >> Thanks, Cyril! >> >> We bumped into the internal link (with label) limitation, too, in Updated >> Pharo by Example ( >> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/10#… >> ). >> >> So, +1 interest to that feature, here :) >> >> >> >> >> On Tue, Apr 7, 2015 at 11:03 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com >> <javascript:_e(%7B%7D,'cvml','cyril.ferlicot(a)gmail.com');>> wrote: >> >>> Hi ! >>> Inter-File link are on the TODO list of pillar. Currently you can't. >>> I'm working on Pillar now, if i add inter-file link i'll say it to you ! >>> >>> On 7 April 2015 at 16:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com >>> <javascript:_e(%7B%7D,'cvml','i.uhnak(a)gmail.com');>> wrote: >>> >>>> Hi, >>>> >>>> how does one add an internal link? >>>> I have chapter 'Framework' (and file 'Framework/Framework.pillar') and >>>> 'Palette' (and file 'Palette/Palette.pillar') >>>> >>>> Can I in Framework.pillar write something like *Palette/Palette* to >>>> create a link? >>>> Currently it fails at >>>> >>>> *** Warning: PRReferenceNotFound: Can't find anchor named >>>> 'Palette/Palette' >>>> >>>> Thanks, >>>> Peter >>>> >>>> >>> >>> -- >>> Cheers >>> Cyril Ferlicot >>> >> >> > > > -- > Cheers > Cyril Ferlicot >

April 9, 2015

Re: [Pharo-users] pillar internal link

by Cyril Ferlicot

Hi. With Damien we're working on the creation of Annotation and Transformers. Now you can use this Annotation's tag : ${inputFile:myFile.pillar}$ on your file to include your myFile.pillar. That still can change a bit, i'm working on it and i still need to do the tests. On 7 April 2015 at 18:40, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > Thanks, Cyril! > > We bumped into the internal link (with label) limitation, too, in Updated > Pharo by Example ( > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/10#… > ). > > So, +1 interest to that feature, here :) > > > > > On Tue, Apr 7, 2015 at 11:03 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > wrote: > >> Hi ! >> Inter-File link are on the TODO list of pillar. Currently you can't. >> I'm working on Pillar now, if i add inter-file link i'll say it to you ! >> >> On 7 April 2015 at 16:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Hi, >>> >>> how does one add an internal link? >>> I have chapter 'Framework' (and file 'Framework/Framework.pillar') and >>> 'Palette' (and file 'Palette/Palette.pillar') >>> >>> Can I in Framework.pillar write something like *Palette/Palette* to >>> create a link? >>> Currently it fails at >>> >>> *** Warning: PRReferenceNotFound: Can't find anchor named >>> 'Palette/Palette' >>> >>> Thanks, >>> Peter >>> >>> >> >> -- >> Cheers >> Cyril Ferlicot >> > > -- Cheers Cyril Ferlicot

April 9, 2015

Re: [Pharo-users] String operations

by Henrik Johansen

+1. In addition, half the methods you usually look for is actually implemented in their proper place (that is, SequenceableCollection, not String). Cheers, Henry > On 09 Apr 2015, at 12:59 , Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > 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. >

April 9, 2015

Re: [Pharo-users] Devnology presentation slides

by stepharo

superb Le 7/4/15 18:39, Stephan Eggermont a Ã©crit : > On 02/04/15 23:18, Stephan Eggermont wrote: >> Diego and I presented Pharo at the Devnology meeting in Arnhem. >> >> http://www.slideshare.net/StephanEggermont/pharo-devnology20150401 > > And a narrative: > > Pharo, the Immersive Programming Experience > > Why do we choose to use Pharo? We feel that Pharo > provides the best way to combat complexity in > software development. > > As long as the number of software developers paid to > make software smaller and throw away code is a lot > smaller than the number of developers paid to add > code, the software we deal with on a daily basis will continue > to grow. This inevitably leads to an increase in the > complexity of the systems we build. This complexity is > problematic because decision making in difficult > situations is biased (1), using first fit heuristics instead > of best fit. > > An interesting observation (2) is that successful software > tends to have technical debt. If a software system is > successfull, the market pressure to deliver more and faster > than technically advisable is difficult to resist. When growing > very fast, it can make sense to make choices that enable > short-term growth that will need refactoring later. Additionally, > an architecture that is optimal for a small system is not > ideal for a large system and vice-versa. > > So, what can we do? There are several interesting models dealing > with complex software systems. Let's check a few of them, and > see what Pharo has to offer there. > > The Cynefin framework (3) categorizes the problem space into > 5 domains: > - Obvious, where the relationship between cause and effect is obvious > to all; > - Complicated, where the relationship between cause and effect requires > analysis and/or the application of expert knowledge; > - Complex, where the relationship between cause and effect can only be > perceived in retrospect; > - Chaotic, where there is no relationship between cause and effect > - Disorder, where the type of causality is unknown. > Each domain needs a different approach. In the complex domain > the approach is Probe, Sense, Response, or run multiple safe-to-fail > experiments simultaneously and see how the system responds. > > Pharo is well-suited to doing experiments and prototyping. > > It offers fast feedback with instantaneous compilation of the > currently edited method, optionally running an autotest on the > changed code. > > The system contains all the source code of all the tools, and they are > designed to be quickly customizable by the individual developer. > A stated goal is to be able to build a custom tool in 10 minutes. > > Pharo immerses you in a sea of objects and provides you with > lots of different ways of looking at them. > The late binding allows manipulating these objects at runtime, > even modifying the runtime stack. > > Real Options (4) provides a decision model based on > - Options have Value > - Options Expire > - Never commit early unless you know why > > Pharo embraces this model. Code is compiled as late as > possible, in the running system. This makes it possible to > use information available only then to customize behaviour > > Behaviour is triggered only by message passing, and the > receiving object decides what to do with a message. > Sending an object a message it does not understands > is caught at runtime and can be dealt with in several ways. > It makes it easy to create proxies and can be used to > learn objects new behaviour. > > Debugger-Driven-Design is an approach unique to smalltalk systems. > It makes it possible to design the way objects communicate while > implementing it. It supports a superior way of doing > test driven development. > > Small is Beautiful (5) is something that is very much applicable > to software. Software systems suffer from diseconomies of scale. > > Pharo uses a very simple and orthogonal language, using a > very small set of constructs. This reduces the cost of building > custom tools and makes it possible to cost-effectively provide > such an advanced environment. The systematic refactoring > applied over many years pays off in a very "dense" library > that makes it possible to solve problems writing a very low > number of lines of code. > > The state of the art in mainstream software development > to battle complexity is reuse at the application level, building > systems out of large-grained components (database, web server). > > Pharo supports reuse at a much lower granularity. > It has lots of small domain specific languages to deal > with specific problems. Because smalltalk has so little > syntax and supports fluent interfaces, these languages > support describing problems and their solutions in a > language near to that of the domain expert. > > All software development environments support > programming yourself into a corner. Making decisions > that turn out to be bad is inevitable when building > complex systems. Being able to program yourself out > of that corner again makes it possible to approach > a problem without fear. > > Pharo offers easy meta programming and a code > rewriting engine to help undoing bad design decisions > and and cleaning up large amounts of code in a controlled > way. > > The choices made by the Pharo project put it on the > left hand side on the value chain map (6). suitable for > innovation, focusing on effectiveness instead of > efficiency. > > Pharo is an open source project, supported by the > Pharo Consortium. It is both a research vehicle and a > platform for commercial software. We use continuous > integration to make sure that the innovations from > research don't destabilize commercial developments. > Next week we hope to release Pharo 4, and in a few > months the much faster new "Spur" vm with support > for 64 bits. > > This was an introduction presentation for the Devnology > workshop of April 1. 2015. Devnology is a Dutch > group of people interested in improving software > development, organizing a monthly meetup. > > (1) Gary Klein (1999) Sources of Power: How People Make Decisions. > > (2) @meekrosoft, Mike Long (Long Life Software), 2013, > Cleaning Code - Tools and Techniques for legacy restoration projects > > (3) Dave Snowden > http://cognitive-edge.com/ > > (4) Chris Matts and Olav Maassen, Committment, the Book. > Expands on the ideas articulated by Kent Beck in > "Extreme Programming Explained, Embrace Change" > http://commitment-thebook.com/ > > (5) E.F. Schumacher, (1973) Small is beautiful: A Study of Economics > As if People Mattered. > > (6) Simon Wardley, http://blog.gardeviance.org/ > > >

April 9, 2015