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

Re: [Pharo-project] [Esug-list] GSoC - Package management with Fuel

by NicolÃ¡s Paez

Great work!!! Congrats. Saludos! NicoPaez <http://nicopaez.wordpress.com/> On Fri, Aug 24, 2012 at 5:01 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > 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 > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Aug. 24, 2012

[Pharo-project] 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

Re: [Pharo-project] GSoC - Package management with Fuel

by Fernando Olivero

Hi Martin, Thanks for reporting on the results, i wasnt aware of such a cool project. Looking forward to use it, instead of what we have now, i remember how fast it was to load objects in Visual Smalltalk. Saludos, Fernando On Fri, Aug 24, 2012 at 10:01 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > 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

Re: [Pharo-project] New Text Completion suggestions

by Esteban Lorenzano

what Doru says makes sense... but in the other side, all the IDEs in the world use enter for completion. We should also welcome newcomers... so, I vote for enter or better, a configuration. Esteban On Aug 24, 2012, at 10:12 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Camillo the system should be like that > > - user can define to use a map > vim > emacs > customizable > + pharo > > for Pharo we need to have a good default. > > To me the remarks of henrik make sense: > the pop up should not stay > using arrows should not pop up something on the left of the screen > after I really understand that enter is not suited for completion just because of the simple scenario > that doru mentioned. but if people cannot leave with enter why not having an option > > Stef

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by Sven Van Caekenberghe

On 24 Aug 2012, at 10:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Aug 24, 2012, at 10:05 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Aug 23, 2012, at 4:24 PM, Camillo Bruni wrote: >> >>> So you're saying modifiable keyboard shortcuts are a bad design? >> >> not necessarily but I prefer to have a good default :) so that I do not have to do it. > > +1 for configurations > +1 for a good default Yes, +agree But also, +igor Smalltalk editing is not big text shuffling, we can and should do what is best for ourselves.

Aug. 24, 2012

Re: [Pharo-project] [In Progress] WebSocket support being added to Zinc HTTP Components

by Pavel Krivanek

Coool, let's try :-) -- Pavel On Thu, Aug 23, 2012 at 9:27 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Yes, the rumors are true: WebSocket support is coming to Zinc HTTP Components and thus to Pharo Smalltalk ! > > Several people asked for it, but Andy Burnett of Knowinnovation USA provided a financial incentive (thanks a lot Andy for sponsoring open-source Smalltalk software like that), so I am now putting in the effort to make this happen. > > > The goal is to add WebSocket (RFC 6455) client and server support over plain and TLS/SSL streams (ws:// and wss://) to Zinc HTTP Components maintaining compatibility with Pharo 1.3, 1.4 and 2.0, as well as community suported portability to Gemstone/Smalltalk and Squeak. > > The test for success will be: > > Use Pharo Smalltalk as both client and server for the Echo example at http://www.websocket.org/echo.html as well as implement the same example directly (through a locally served page). > > The final code will be open source and MIT licensed. It will include unit tests, documentation as well as basic support on the mailing list. > > > The purpose of this email is twofold: to announce the fact that this is happening and to look for early alpha testers that can help shape the API. > > > Although as yet unfinished, largely undocumented and untested, still containing debugging and tracing code and subject to change, there is already working code that meets the functional goals available in the main development Zn repository. > > Gofer it > url: 'http://mc.stfx.eu/ZincHTTPComponents'; > package: 'Zinc-HTTP'; > package: 'Zinc-FileSystem'; > package: 'Zinc-Tests'; > package: 'Zinc-WebSocket-Core'; > package: 'Zinc-WebScoket-Tests'; > load > > The first working example is accessing an existing WebSocket test application at http://www.websocket.org/echo.html > > ZnWebSocketTests>>#testEchoWebSocketsDotOrg > | webSocket message | > webSocket := ZnWebSocket to: 'ws://echo.websocket.org'. > message := 'Greetings from Pharo Smalltalk @ ', TimeStamp now printString. > webSocket sendMessage: message. > self assert: webSocket readMessage equals: message. > webSocket close. > > The second working example is Zinc implementing the same echo service itself as well as accessing it > > ZnWebSocketTests>>#testEchoLocally > | webSocket message | > ZnServer startDefaultOn: 1701. > ZnServer default logToTranscript. > ZnServer default delegate > map: 'ws-test' > to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestHtml) ]; > map: 'ws-test-local' > to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestLocalHtml) ]; > map: 'ws-echo' > to: (ZnWebSocketDelegate new > prefixFromString: 'ws-echo'; > handler: ZnWebSocketEchoHandler new; > yourself). > webSocket := ZnWebSocket to: 'ws://localhost:1701/ws-echo'. > message := 'Greetings from Pharo Smalltalk @ ', TimeStamp now printString. > webSocket sendMessage: message. > self assert: webSocket readMessage equals: message. > webSocket close. > ZnServer stopDefault. > > Where > > ZnWebSocketEchoHandler>>#value: webSocket > "I implement an echo service conversation as a server: > reading messages and echoing them back until ConnectionClosed" > > [ > webSocket runWith: [ :message | > self crLog: 'Received message: ', message printString, ' echoing...'. > webSocket sendMessage: message ] ] > on: ConnectionClosed > do: [ self crLog: 'Ignoring connection close, done' ] > > If you select and execute the following part from the above > > ZnServer startDefaultOn: 1701. > ZnServer default logToTranscript. > ZnServer default delegate > map: 'ws-test' > to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestHtml) ]; > map: 'ws-test-local' > to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestLocalHtml) ]; > map: 'ws-echo' > to: (ZnWebSocketDelegate new > prefixFromString: 'ws-echo'; > handler: ZnWebSocketEchoHandler new; > yourself). > > You can use your browser to access the echo service through the standard JavaScript API > > http://localhost:1701/ws-test > http://localhost:1701/ws-test-local > > The first URL goes out to websocket.org, the second uses the local Zinc implementation. > > Again, this is early code, anything might change. > > So, if you have some prior knowledge in this area and are interested, have a look and let me know what you think. > > Thx, > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by StÃ©phane Ducasse

Camillo the system should be like that - user can define to use a map vim emacs customizable + pharo for Pharo we need to have a good default. To me the remarks of henrik make sense: the pop up should not stay using arrows should not pop up something on the left of the screen after I really understand that enter is not suited for completion just because of the simple scenario that doru mentioned. but if people cannot leave with enter why not having an option Stef

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by Esteban Lorenzano

On Aug 24, 2012, at 10:05 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 23, 2012, at 4:24 PM, Camillo Bruni wrote: > >> So you're saying modifiable keyboard shortcuts are a bad design? > > not necessarily but I prefer to have a good default :) so that I do not have to do it. +1 for configurations +1 for a good default > > Stef > >

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by StÃ©phane Ducasse

On Aug 23, 2012, at 4:24 PM, Camillo Bruni wrote: > So you're saying modifiable keyboard shortcuts are a bad design? not necessarily but I prefer to have a good default :) so that I do not have to do it. Stef

Aug. 24, 2012

[Pharo-project] 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