March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.
by George Herolyants March 12, 2010

March 12, 2010

Hi, guys! Here is a project idea for GSoC. Something that, I think, one day came into everyone's mind. I've just written it: --------------------------- ++ Pharo/Squeak integration with git/mercurial. Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas. Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round these disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial. **Technical details** This project may go different ways towards it's goal, depending on decisions being made during it. Initial steps will be: * Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. * Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk. * Studying how Squeak/Pharo handles system changes (changes of classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API. * (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively. Additional steps may include: * Implementing import/export tool for Monticello repositories. * Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment. Integration with widely used OmniBrowser would be even better. In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require: * Exploring the current mechanism used in Pharo/Squeak to maintain method version history. * Replacing it with the developed system which will write changes to the local git/mercurial repository. **Benefits to the student** The student will: * learn about modern source code management systems; * study their interfaces, both command line and API; * study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions. * get experience in usage of FFI or writing plugins for Smalltalk VM; * get experience with making GUI in Pharo/Squeak; * enjoy writing programs in Smalltalk :) **Benefits to the community** Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow. Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level). ---------------------------- I would like to be a mentor (if no one agrees to mentor) or co-mentor, if you guys don't mind. Hope it's not too late :) George

4 10

Re: [Pharo-project] GSOC 2010: Extensible parsing and persistency for Pier
by Mariano Martinez Peck March 12, 2010

March 12, 2010

Excellent. Which difficult you think it should have ? beginner, intermediate or advanced ? thanks Mariano On Fri, Mar 12, 2010 at 8:43 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Here is the description for a project related to Pier. > > Cheers, > Doru > > > > ---------- > > Extensible parsing and persistency for Pier > > > Mentors: Tudor Girba, Lukas Renggli > > Pier is an open-source content management system that aims at allowing > users to manage their content from the browser. It is based on a highly > object-oriented model dealing with multiple issues: multiple types of > structures that are meta-described, security management, user management, or > persistency. The preferred way to define content is through an wiki-like > syntax. Using this syntax, the user can specify multiple types of links, can > choose to embed entire structures, and it can even access external services > (like YouTube). > > This project will tackle two important problems related to extending Pier: > 1. While the Pier model is extensible the parser of the Pier syntax is not > easily extensible. The first job will be to rewrite the Pier parser to offer > hooks for syntax extensions. A possible path towards this implementation is > the use of the PetitParser framework. > 2. The main persistency mechanism in Pier is image-based. While the Pier > model is meta-described for most parts, there are still parts that are > accessed directly without the use of meta-descriptions. This poses a problem > for a generic persistency mechanism. The second part of the project will > focus on providing a mechanism for allowing each structure to specify a > persistency strategy. > > Benefits for the student: > - learn about meta-modeling and parsing. > - learn Seaside and work on a platform that has a wide acceptance already. > > Benefits for the community: > - a better content management system > > >

1 0

[Pharo-project] Fwd: GSOC 2010: Extensible parsing and persistency for Pier
by Tudor Girba March 12, 2010

March 12, 2010

Hi Mariano, Here is the description for a project related to Pier. Cheers, Doru ---------- Extensible parsing and persistency for Pier Mentors: Tudor Girba, Lukas Renggli Pier is an open-source content management system that aims at allowing users to manage their content from the browser. It is based on a highly object-oriented model dealing with multiple issues: multiple types of structures that are meta-described, security management, user management, or persistency. The preferred way to define content is through an wiki-like syntax. Using this syntax, the user can specify multiple types of links, can choose to embed entire structures, and it can even access external services (like YouTube). This project will tackle two important problems related to extending Pier: 1. While the Pier model is extensible the parser of the Pier syntax is not easily extensible. The first job will be to rewrite the Pier parser to offer hooks for syntax extensions. A possible path towards this implementation is the use of the PetitParser framework. 2. The main persistency mechanism in Pier is image-based. While the Pier model is meta-described for most parts, there are still parts that are accessed directly without the use of meta-descriptions. This poses a problem for a generic persistency mechanism. The second part of the project will focus on providing a mechanism for allowing each structure to specify a persistency strategy. Benefits for the student: - learn about meta-modeling and parsing. - learn Seaside and work on a platform that has a wide acceptance already. Benefits for the community: - a better content management system -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

1 0

[Pharo-project] Code bubbles
by StÃ©phane Ducasse March 12, 2010

March 12, 2010

The kind of stuff I would have love to see people experimenting with Squeak. We failed to be sexy on the UI level. Stef > > > Ideas for IDE UIs > http://www.cs.brown.edu/people/acb/codebubbles_site.htm > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > > _______________________________________________ > Lsehub-staff mailing list > Lsehub-staff(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff

5 5

Re: [Pharo-project] LAST CHANCE Foreing Function Interface GSOC [WAS] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
by John M McIntosh March 12, 2010

March 12, 2010

Ah, well I can also help eliot on this, sometimes he gets too busy... plus I want to ensure the objective-c binding happens. On 2010-03-11, at 11:26 AM, Gilad Bracha wrote: > Hi Mariano, > > I'm pretty sure you mean to list Eliot as the co-mentor or mentor on this one. If anyone got stuck and asked my help, I would end up bugging Eliot anyway. And he did agree. > > > > On Thu, Mar 11, 2010 at 10:18 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Tomorrow morning we will be submitting...so, for this project, we only have this proposal: > > Work on a cross-dialect foreign function call interface and implement it in at least two dialects. Candidates include Alien and GNU Smalltalk's CObject (using existing implementation has the advantage of having to implement in only _one_ other dialect!). Bonus points for implementing a C parser that would be able to construct bindings. GNU Smalltalk already contains a C preprocessor implementation. > There is some support for parsing C headers in the Newspeak system. Aliens have been ported to Strongtalk as well as Squeak. > > The mentor will be John McIntosh and Gilad Brancha co-mentor. > > Can this proposal be more complete and have similar structure to the rest ? If true, send me the proposal. > > Check http://gsoc2010.esug.org/ideas.html > > Cheers > > Mariano > > -- > Cheers, Gilad -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

2 1

[Pharo-project] networking problem (repost)
by Michael Roberts March 11, 2010

March 11, 2010

i'm not sure this email came through whilst the list was down sunday/monday so i am reposting by request. i will add some further content at the end ===================================================== I have dug around the network problem (OS X) in Pharo 1.0. I am convinced #useOldNetwork = true does not work. Looking through old core images, it never worked; at least with my current OS and VM choice. i have been using Magma as a test case. Indeed it is broken on 10508 rc2, however if I set NetNameResolver classPool at: #UseOldNetwork put: false and hack #initializeNetwork to make the reference false as well (since it can change its value once set)... I can run the first 10mins of the Magma test suite which is heavy on network use. I only can't complete the magma test case due to unrelated issues. I've asked Chris to see if these changes work for him. i propose in Pharo Core 1.0 -set UseOldNetwork := false, and change all references that try and set it to true -now we are only using the new network infrastructure, -gather fresh test cases from the community where networking fails and fix them with a final push. -do not try and fix the UseOldNetwork := true branches If we can not get this approach above to work then as a fallback I propose to remove all the new network code and revert it all back to the point where it was simpler where socket addresses were just byte arrays...We then spend more time in 1.1 trying to get it to work properly. Does anyone care at this point how the infrastructure looks in 1.0? The fact that our rc2 network layer is totally bust is enough to do something drastic to finish the cycle. I propose in Pharo 1.1 -strip out all useOldNetwork = true branches. it does not work, and it is a mess to have these two branches side by side, especially when the value of useOldNetwork can change on its own (this happened a number of times to me) I guess due to all the attempts to check and initialize the network. somewhere it flips. obviously we need some focus on testing a final set of changes, but please consider the direction I outline. thanks, Mike ==================================================== I spent some time after writing this above looking at the magma test case more deeply and chatting to Chris offline. After fixing a quoting issue with magma image launching i managed to get the magma test suite to run for about 30 mins (until it stopped...). So in principle the networking does work... Then to my astonishment i could not get it to run again at all for another few hours, i got no where... it was like it was a dream. I suspect the problem is the exact network interfaces that the server and client try to connect/bind to. In the old ipv4 world it was fairly simple. i suspect in the ipv6 world, different parts of magma are binding to different interfaces and i find it impenetrable to work out which. i have lots of interfaces on my machine (wifi, ethernet, parallels virtual, etc) and when you do NetNameResolver localHostAddress (or whatever the message is) you get back only the first one. I think this could be the cause of issues. Adrian mentions to me John thought they came back randomly. So now my conclusion is firmly we have to take a step back and simplify. for pharo 1.0 unless we have someone with a lot of time i do not feel we can untangle the resolver and socket code. We should revert it back to the original #[192 168 0 10] style code when it used to be simple. This assumes the primitives still support this. Then what I would like to see in Pharo 1.1 or 1.2, is that we separate out classes for ip4 and ip6 support, and make them work cleanly and transparently together. Just because we have ip6 support i don't want to be forced to use it. we should have a clearer interface to enumerate all the network interfaces on the machine, and we should really document this heavily. I think the new help system would be great for this. I started to have to write my own scripts just to document the change in API across images. these can go straight into a help system... cheers, Mike

6 8

[Pharo-project] [update] #10512
by Marcus Denker March 11, 2010

March 11, 2010

10512 ----- Issue 1850: Add MetacelloRepository to default repository list Issue 1967: Cleaning included Monticello repositories in PharoCore -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [update 1.1] #11258
by Marcus Denker March 11, 2010

March 11, 2010

11258 ----- Issue 1481: remove class MethoProperties Issue 1850: Add MetacelloRepository to default repository list Issue 1967: Cleaning included Monticello repositories in PharoCore -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] DEADLINE for submitting projects
by Mariano Martinez Peck March 11, 2010

March 11, 2010

Hi Folks. Tomorrow (12/03/2010) morning is the deadline for the project submission. We want to apply by noon so we will be adding the last projects in the morning. So...the deadline is 9:00 am in GMT +1 Cheers Mariano

1 0

[Pharo-project] LAST CHANCE Foreing Function Interface GSOC [WAS] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
by Mariano Martinez Peck March 11, 2010

March 11, 2010

Tomorrow morning we will be submitting...so, for this project, we only have this proposal: Work on a cross-dialect foreign function call interface and implement it in at least two dialects. Candidates include Alien and GNU Smalltalk's CObject (using existing implementation has the advantage of having to implement in only _one_ other dialect!). Bonus points for implementing a C parser that would be able to construct bindings. GNU Smalltalk already contains a C preprocessor implementation. There is some support for parsing C headers in the Newspeak system. Aliens have been ported to Strongtalk as well as Squeak. The mentor will be John McIntosh and Gilad Brancha co-mentor. Can this proposal be more complete and have similar structure to the rest ? If true, send me the proposal. Check http://gsoc2010.esug.org/ideas.html Cheers Mariano On Wed, Mar 10, 2010 at 10:03 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > Ok, I'm a bit behind in my email but I would help mentor if need be. Just > to ensure it works ok on os-x and also to ensure support for objective-c > creeps in there somehow since Apple's direction is towards everything in > Objective-C frameworks versus "C" library calls. > > > On 2010-03-07, at 3:24 PM, Gilad Bracha wrote: > > I'm all for it, and hope that John or Eliot can mentor. Datapoints I'll > add: > > There is some support for parsing C headers in the Newspeak system. > Aliens have been ported to Strongtalk as well as Squeak. > > Finally - what licensing would apply if GNU Smalltalk were used? GPL is a > big problem. Even LGPL elicits an immune response in a lot of commercial > contexts. Is there a GSoC policy on this? > > On Sun, Mar 7, 2010 at 3:09 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >>> 5) Work on a cross-dialect foreign function call interface and implement >>> it in at least two dialects. Candidates include Alien and GNU Smalltalk's >>> CObject (using existing implementation has the advantage of having to >>> implement in only _one_ other dialect!). Bonus points for implementing a C >>> parser that would be able to construct bindings. GNU Smalltalk already >>> contains a C preprocessor implementation. >>> >>> >> I think this project could be a good idea for GSoC. As I said, I would >> love if it (optionally at least) could not to block the complete VM while a >> function is being called. >> >> I would also love what you said: parse .h of libraries and automatically >> create the wrapper for Smalltalk. At least create the invocations to the >> functions, and map the structures to objects... >> >> We need to write a title, a little description and if possible titles like >> "technical details", "benefits to the students" and "benefits to the >> community". >> >> If you are interested please send it to me and I add it to the list. >> >> We also need a mentor (and a student, of course)...anyone is willing to do >> it ? >> >> Cheers >> >> Mariano >> > > > > -- > Cheers, Gilad > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/listinfo/esug-list > >

1 0