August 2012 - Pharo-users - lists.pharo.org

PhD topics with RMOD

by StÃ©phane Ducasse

Hi guys we have a position for a PhD. If you are interested we can talk at ESUG 2012 or by Skype. Stef Context: Dynamically-typed languages cannot take advantage of static type information. In this context we would like to study the benefit of the introduction of static types *annotations* on library design and general robustness. The benefits can be at the level of the robustness (bug identification), but also tools (IDE) and support for assembly generation/c in case of JIT. The PhD grant is financed in the context of the Safe Python project therefore the Ph.D. will have to work in contact do we with the project partners and help in the context of some deliverables. The following tasks have to be done: - RPython is not formally defined. One of the first task will be to define the formal semantic of RPython. One approach is to write a RPython interpreter based on an operational semantics and to compare the output with the RPython interpreter. We will certainly use PLT redex which is a domain-specific language to specify and debug operational semantics. - We may use the abstract syntax tree of PyLint and use the Frama-C infrastructure. We will also consider to build a Python parser based on petitParser. - Define of some default metrics may also be necessary for the SafePython project. Their definition should be trivial on ASTs. - Analysis of the benefits of static typing for RPython. One idea is to study the existing python libraries and analyze the "distance" to the RPython subset. - Exploring type checking in presence of inconsistent type annotations. - Since we are developing Pharo and that static type annotation are important to support C or assembly generation, we would like to apply the same technique to Pharo: - define a syntax to support type annotation (reuse the one developed by Pleaid team member) - perform some analysis of existing library. References [1] D. Ancona, M. Ancona, A Cuni, and N. Matsakis. RPython: a Step Towards Reconciling Dynamically and Statically Typed OO Languages. In OOPSLA 2007 Proceedings and Companion, DLS'07: Proceedings of the 2007 Symposium on Dynamic Languages, pages 53-64. ACM, 2007. [2] A Visual Environment for Developing Context-Sensitive Term Rewriting Systems Jacob Matthews, Robert Bruce Findler, Matthew Flatt, and Matthias Felleisen [3] Felleisen,M.,Hieb,R.:The revised report on the syntactic theories of sequential control and state. (1992) 235â271 Skills and Profile You must hold a Master's in computer science, control engineering, mathematics, scientific computation or an equivalent diploma. Nationality is not taken into consideration. Knowledge in programming language design. Object-oriented programming with knowledge of Smalltalk and Python are a plus. About Lille and INRIA: Lille is located in the north of france at the border to Belgium one hour from Paris, 1h20 from London, 35 min from Brussels, by train. French food, combined with belgian beer. RMoD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille/ INRIA in General: http://www.inria.fr Lille: http://en.wikipedia.org/wiki/Lille http://wikitravel.org/en/Lille Benefits/Users/ducasse/Workspace/FirstCircle/Administration/Ad-INRIA/Projects/2012-SafePython/PhDtopics.txt Duration : 36 months â starting date of the contract : October 2012, 15th Salary: 1957,54 EUR the first two years and 2058,84 EUR the third year Monthly salary after taxes: around 1597,11 EUR the 1st two years and 1679,76 EUR the 3rd year (social security included). Possibility of French courses Help for housing Scientific Resident card and help for husband/wife visa Additional Information Application deadline: 15 September 2012 Contact for position: stephane.ducasse(a)inria.fr

Aug. 24, 2012

GSoC - Package management with Fuel

by Martin Dias

Hi This week has ended Google Summer of Code program 2012. I have to thank Marcus and Carlos Ferro, my mentors, as well as Mariano, Guille Polito, Camillo Bruni, and others, who collaborated in different ways during these three months. Also thank, of course, to Carla and Janko... and Google ;) The main purpose of this mail is to summarize the work done for my project, named "Package management with Fuel" [1][2]. Tools for managing code in Pharo export classes, traits, and methods as series of source definitions, which then import by evaluating them with the compiler. This is basically how FileOut/FileIn or Monticello works. This is slow on large pieces of code, so if you want to install a big package, you need a lot of time compiling it. Why should you compile it again, given that it was all compiled when you exported the package? The bytecodes will be the same again, you know... If you just could load the Classes and Compiled Methods instead of compiling it all again, you can save time. With this goal in mind, I started working in FuelPackageLoader[4] (now Tanker[3]), a prototype we wrote last year, which already exports and imports packages without using any compiler. But it has two important issues: it wasn't capable of export source code, and it wasn't able to tolerate class-shape changes in hierarchies (ie, a change on inst vars in a external superclass). So, we decided to start from scratch with a new prototype, code name Carbono. The idea was to reify how FileOut and FileIn are done, but storing binary information so that compilation can be avoided. In a nutshell, Carbono stores a package into two files: - A sources file, imitating the traditional FileOut chunk format. - A binary file, where uses Fuel[5] to serialize a series of code definitions. Each of them knows the position in the sources file where its source code counterpart is. For example, a class definition knows the position of its comment (in the case it exists), and a method definition knows the position of its source code. A basic example, to export a couple of classes: TAExport new binariesOn: aBinaryStream sourcesOn: aTextStream; behaviors: {ClassA. ClassB}; methods: {}; initializeClasses: true; run. which then you can import with: TAImport new binariesFrom: aBinaryStream sourcesFrom: aTextStream; run. Anyway, you can also choose to: - export only binaries or only sources - import only binaries (source code can be decompiled) - import only sources (via #fileIn) Mariano Martinez Peck worked a lot on it, fixing bugs, and especially optimizing it A LOT, so I hope you will enjoy his demonstration this Monday on ESUG Innovation Awards. Seems that he could export Seaside, Pier and Magritte, and import them in another image, with source code, and just in a few seconds ;) Also, some ultra confidential WikiLeaks revealed that he could export almost all Pharo packages, and import them in a kernel image, all with source codes but without using the compiler :) Note1: Tolerating class-shape changes in hierarchies is not yet done, but it should in some days. So far, the only strategy when a change is detected will be to recompile methods, but it may be more sophisticated in a not-so-far future. Note2: Although finally it was not strictly necessary, Guillermo Polito and me wrote tests for a new ClassBuilder. It is part of Slot, a kind of reification of objects layout made by Toon Verwaest and Camillo Bruni. It is too long to explain it here, but the thing is that was not an easy job, and we hope it will be integrated in Pharo. This is a work in progress, but you can install and try it on latest Pharo 2.0, evaluating: Gofer it squeaksource3: 'PharoTaskForces'; package: 'Slot'; package: 'SlotTests'; load. (Smalltalk at: #SlotVirus) perform: #spread. Gofer it squeaksource3: 'PharoTaskForces'; package: 'SlotsClassBuilderIntegration'; load. Gofer new smalltalkhubUser: 'marianopeck' project: 'Tanker'; package: 'ConfigurationOfTanker'; load. (Smalltalk at: #ConfigurationOfTanker) loadBleedingEdge. Gofer new squeaksource: 'FuelExperiments'; package: 'Carbono'; package: 'CarbonoTests'; load. Cheers, MartÃn [1]: http://gsoc2012.esug.org/projects/fuel-packages [2]: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/tin… [3]: http://marianopeck.wordpress.com/2012/08/11/tanker-transporting-packages-wi… [4]: http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… [5]: http://rmod.lille.inria.fr/web/pier/software/Fuel

Aug. 24, 2012

Zinc-HTTP-Deprecated

by Sven Van Caekenberghe

There is a class category called 'Zinc-HTTP-Deprecated'. It contains some old classes that were replaced/superceded by newer ones almost a year ago. I plan to actually delete these and their unit tests in a commit in the next couple of days. Specifically, the following classes will be removed: - ZnClientOld - ZnFixedClient - ZnExtendedFixedClient - ZnUserAgent - ZnHttpClient - ZnUserAgentSettings I hope nobody uses these anymore. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Aug. 23, 2012

Re: [Pharo-users] Pharo usage poll

by HernÃ¡n Morales Durand

Hi Esteban. Thanks for clarifying. For me it doesn't need to be perfect. Answering polls is fun actually if you know how to enjoy. So I'm looking forward to more questions :) Cheers, HernÃ¡n 2012/8/22 Esteban Lorenzano <estebanlm(a)gmail.com> > Hernan, > > There is always room for improvement, but I think you are missing the > point here. > Of course, the poll is narrow (*all* polls are)... We could collect more > data, but there is no poll without a question to answer, and here the real > question is "what for?" What questions do you want to answer when making a > poll. And then, when you see narrowness, I see clarity: I just have three > questions that want answered (well, and a "hidden" one, but that's for > later :). In fact, two of your three examples of questions were present in > my first draft, and I removed them because they didn't provide more insight > in *my* questions, which are pretty straightforward. Yes, I missed some > other interesting questions for what I'm looking for, e.g. "why are you > still using an older version of Pharo?", but well... you cannot make it > perfect :) > Of course, everybody has their own questions, and of course, if you want a > "pharo census", we need to make much more questions... but that was off > what I was looking for :) > > Esteban > > ps: yes, we can prepare a "pharo census", that can be interesting > information too, and I would really like to have your help on preparing > it... but lets complete this one small poll first. > > On Aug 22, 2012, at 6:05 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > 2012/8/22 Igor Stasenko <siguctua(a)gmail.com> > >> or look at this form another perspective: >> if you know how to make things better, improve them, what you waiting >> for and not doing it in a first place? >> > > I'm doing it, saying that a brief poll could be better is pushing Pharo > developers to make things better. Don't you think so? > > >> Pharo is open project after all. >> Or at least, if you having a great idea but have no time/resources to >> do it, why you don't proposing it or asking around who interested in >> implementing it, but sitting there waiting to be asked .. >> >> > Yes, I'd like to be asked for the right questions. Your questions tell me > your interests much as your lack of questions. I'm proposing more accurate > polls... like "which packages do you use often?", "which non-core > Collection classes do you need more?", "do you use Traits?", etc. > Nobody is obliged to answer any poll, if too many questions, you just > don't answer :) > > HernÃ¡n > > >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > HernÃ¡n Morales > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. > > >

Aug. 22, 2012

Re: [Pharo-users] Pharo usage poll

by HernÃ¡n Morales Durand

2012/8/22 Igor Stasenko <siguctua(a)gmail.com> > On 22 August 2012 06:05, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > > > 2012/8/22 Igor Stasenko <siguctua(a)gmail.com> > >> > >> or look at this form another perspective: > >> if you know how to make things better, improve them, what you waiting > >> for and not doing it in a first place? > > > > > > I'm doing it, saying that a brief poll could be better is pushing Pharo > > developers to make things better. Don't you think so? > > > > The main problem with this is that often questions and received answers > will remain to be just a questions and received answers: the results > are never implemented/reflected into something material. > So, as to me it is more useful to do something real instead of asking > around "what something real we should do?" and then unable to do it. > > Everyone wants X, but nobody doing it. Do you know how many of those > X's i heard over past few years? More than you can do even if you > spend all of your life doing them. > > I see, but I'm not talking about what people wants. Just saying that more good feedback would be useful to Pharo developers for future releases. It doesn't mean asking for feature X. > >> > >> Pharo is open project after all. > >> Or at least, if you having a great idea but have no time/resources to > >> do it, why you don't proposing it or asking around who interested in > >> implementing it, but sitting there waiting to be asked .. > >> > > > > Yes, I'd like to be asked for the right questions. Your questions tell me > > your interests much as your lack of questions. I'm proposing more > accurate > > polls... like "which packages do you use often?", "which non-core > Collection > > classes do you need more?", "do you use Traits?", etc. > > Nobody is obliged to answer any poll, if too many questions, you just > don't > > answer :) > > > Once again, i don't think that showing interest in something in form > of pool is the best way to > communicate.. > And polls is one way communication.. and pretty obscure one. > I disagree with your obscurity claim. There have been even democratic elections through internet based polls. There are hundreds of case studies based on polls/surveys in the software engineering knowledge management field. There are peer-reviewed scientific papers discussing e-voting infrastructure systems. It's ok if you don't want to use the available technology for polls, but believing it's an obscure communication is not valid anymore. > For example, if you ask in poll "do you use Traits" most of people may > answer "no", so that may drive your decision to remove them.. > until you discover that most of people actually meant to say is: "i > don't use traits in my current project, but they should stay because > they can be useful and i can see their potential" > > You are worried about falsifications, but you may ask cleverly. For example, you could ask "do you see potential use of Traits for your future projects?" and "do you have verifiable experience with Traits?". It takes some time, but you may discover much more than sitting there without questioning yourself anything. > > HernÃ¡n > > -- > Best regards, > Igor Stasenko. > >

Aug. 22, 2012

Re: [Pharo-users] Pharo usage poll

by HernÃ¡n Morales Durand

2012/8/22 Norbert Hartl <norbert(a)hartl.name> > > Am 22.08.2012 um 04:30 schrieb HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com>: > > Proof? > > > You offered already to provide questions. Just create a long survey and > invite everyone on that list. Then ask Esteban how many answered his poll > and compare it with the number you got ;) > > Is not the same, because AFAIK Esteban is working (payed) for Pharo, then he's actually in a different position when posing questions. > Norbert >

Aug. 22, 2012

poll reminder

by Esteban Lorenzano

Hi, Just a reminder. The poll is still on: https://docs.google.com/spreadsheet/viewform?fromEmail=true&formkey=dFZKeXU… please, answer it... they are just 3 questions! (in fact many people think there are too few questions :) thanks, Esteban

Aug. 22, 2012

Versionner screencast

by Juan Pablo Sandoval Alcocer

Hi all, I would like to share Versionner screencast http://youtu.be/6x0nsd9U4OE You can find more about Versionner here: http://www.dcc.uchile.cl/~jsandova/versionner. Including the install instructions and screenshots. Regards, Juan Pablo

Aug. 22, 2012

Re: [Pharo-users] Pharo usage poll

by Esteban Lorenzano

thats other of the questions I took off in my effort to keep the poll simple. yes... I agree with both things: it would be good to know and it looks like mac is the most used Esteban On Aug 22, 2012, at 4:56 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > This is a side question of the poll, but what is the predominant OS used for > development today? (with Pharo, of course). > > It seems to me(*), that many of the most active contributors are using some > kind of Mac. > > (*) Based on screenshots, comments, tools mentioned, etc. > > Do we have any info about this? > > > Best regards, > > -- > Esteban. > > > > -- > View this message in context: http://forum.world.st/Pharo-usage-poll-tp4644852p4644988.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 22, 2012

Re: [Pharo-users] Pharo usage poll

by Esteban A. Maringolo

This is a side question of the poll, but what is the predominant OS used for development today? (with Pharo, of course). It seems to me(*), that many of the most active contributors are using some kind of Mac. (*) Based on screenshots, comments, tools mentioned, etc. Do we have any info about this? Best regards, -- Esteban. -- View this message in context: http://forum.world.st/Pharo-usage-poll-tp4644852p4644988.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 22, 2012