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

Re: [Pharo-project] Code bubbles

by Tudor Girba

Sounds intriguing. Do you have any pointers regarding this (except of code)? Cheers, Doru On 12 Mar 2010, at 03:21, Chris Muller wrote: > Well, this is what Maui for Squeak 3.9 does, except Maui is for any > domain, not just developer IDE objects.. > > On Thu, Mar 11, 2010 at 2:12 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: >> On 11 March 2010 09:43, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> The kind of stuff I would have love to see people experimenting >>> with Squeak. >>> We failed to be sexy on the UI level. >>> >> >> Amazing stuff!Have no idea how it fits with java, but for smalltalk >> it >> would be really cool! :) >> >>> 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 >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

March 12, 2010

Re: [Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.

by George Herolyants

Oh, sorry, here it is: ++ 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 this and some other 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. There is already SqueakSVN project but it aims to SVN integration. SVN is classic client-server SCM. But nowadays this kind of SCM's become less popular, while popularity of distributed SCM's (such as git/mercurial) is still growing. It is also crucial for open source projects like Pharo/Squeak to have distributed SCM to ease development process. Monticello is highly distributed and the new SCM must be distributed as well to successfully compete with Monticello. So git/mercurial fits this goal very well. **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. There's also pure Smalltalk implementation of Git storage format on SqueakSource, so this step will require examining it as well. * 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).

March 12, 2010

Re: [Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.

by George Herolyants

Here's slightly updated proposal (I included some info about SqueakSVN project and about Smalltalk implementation of Git storage format): ----------------------------- ++ 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 this and some other 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. There is already SqueakSVN project but it aims to SVN integration. SVN is classic client-server SCM. But nowadays this kind of SCM's become less popular, while popularity of distributed SCM's (such as git/mercurial) is still growing. It is also crucial for open source projects like Pharo/Squeak to have distributed SCM to ease development process. Monticello is highly distributed and the new SCM must be distributed as well to successfully compete with Monticello. So git/mercurial fits this goal very well. **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. There's also pure Smalltalk implementation of Git storage format, so this step will require examining it as well. * 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. (There's also pure smalltalk implementation of Git storage format on SqueakSource. * 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). -------------------------------

March 12, 2010

Re: [Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.

by George Herolyants

Argh... This "reply to" vs. "reply to all". ---------- Forwarded message ---------- From: George Herolyants <george.herolyants(a)gmail.com> Date: 2010/3/12 Subject: Re: [Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial. To: Mariano Martinez Peck <marianopeck(a)gmail.com> 2010/3/11 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Yes!!! moreover he can be co-mentor or something like that...Of course, if > the project still have sense (I have no idea what is done in that project) So I emailed him (Tony Garnock-Jones) yesterday. Still have no reply. I should have cc'ed the email to this list, but it was at the end of the day and my brain just stopped working :)

March 12, 2010

Re: [Pharo-project] LAST CHANCE Foreing Function Interface GSOC [WAS] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!

by Javier PimÃ¡s

Hi! Recently I discovered that there is a parser project called SmaCC. I don't know if it works, but I think it includes parsers for C, Java and Smalltalk, do you know/did you try it? Regards, Javier. 2010/3/11 John M McIntosh <johnmci(a)smalltalkconsulting.com> > 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 > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 12, 2010

Re: [Pharo-project] Class comments are in the .sources ?

by Igor Stasenko

On 11 March 2010 17:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 11, 2010, at 3:58 PM, Mariano Martinez Peck wrote: > >> >> > Â What do you think? >> > >> >> allClassesDo: [:class | class organization setDefaultList: #() ] >> >> >> Seems to be more complicated than that. There is a problem with the notifications.... >> >> Now, I added to ClassOrganizer the method >> >> putAllSelectorInDefaultCategory >> Â Â self elementArray do: [:each | self classify: each under: self class default suppressIfDefault: false] >> >> And then I evaluate: >> >> Smalltalk allClassesDo: [:each | each organization putAllSelectorInDefaultCategory]. >> Smalltalk allClassesDo: [:each | each organization removeEmptyCategories]. >> Smalltalk garbageCollect. >> >> >> That seems to work. I mean, all method of all classes uses the same category. As it is Â a ByteSymbol, there is only one instance. However, after saving the image, is it is bigger than before evaluating that.... >> >> there is of course something I am not understanding. Is there some chapter, tutorial or link to read about all the ClassOrganizer stuff ? >> > no... all the ClassOrganizer stuff is so old that it seriously needs to be replaced... it looks like it comes from a time when the only collection available was an Array :-) > It's very badly done from today's OO design perspective. Hard to understand, difficult to use (I can never remember how to get all classes of one category, for example). > And it's not OO. Categories are not Object, for example. They are just symbols. Asking for classes of one category gives you names, not classes. > > In addition it's slow. > e.g. we discovered in 3.9 that asking a class for it's category needed to iterate over the whole array, making it very slow. Than we saw that there was > an unused "category" iVar in Class, which we used to cache the category. MC suddenly became 2 times faster in loading. > Marcus, once before, i did examined the ClassOrganizer implementation. Yes, it is slow, complex and using Arrays. But i know why - it was designed for compactness to have a small memory footprint. So, all of good things, like simplicity, good OO etc etc was sacrificed towards having less memory in image. > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 12, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by Levente Uzonyi

On Thu, 11 Mar 2010, Henrik Johansen wrote: > > > Den 11.03.2010 01:54, skrev Nicolas Cellier: >> 2010/3/11 Igor Stasenko <siguctua(a)gmail.com>: >> >>> On 10 March 2010 15:07, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>>> self collect: aBlock as: Set >>>> >>>> >>> One more time, i found this very beatiful and useful extension to >>> Collection protocol. >>> And i am proud being a witness when this thing is born! :) >>> >>> >> Yes, >> I remember saying I was not convinced some times ago... >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129457.html >> Being able to change own opinion is a good thing ! >> >> Nicolas >> > I have to admit, I still don't quite see what's wrong with > 1. > (self collect: aBlock) asSet ('foo' collect: [ :each | each asciiValue ]) asSet "===> boom :)" > or > 2. > mySet := Set new: self size. > self do: aBlockAddingToMySetAtEnd. That's ok, but it's two lines + a temporary declaration. > > or (well, this one is IMO indeed a bit ugly) > 3. > self inject: (Set new:self size) into: > [ :sub :next | > sub add: next collectValue; yourself ] ... > > Sure, they're a bit verbose, and when you'd like to use 1 vs 2 or 3 > varies abit on the collection contents, but they all work in all > dialects, and aren't THAT much longer, unless your collect block is > really short. I did a quick sampling (not representative) and found that 1 out of 20 collect blocks is longer than a single line. #collect:as: is a solution to the problem about #species which limits the use of #collect: in some cases. You can find the proposal about #collect:as: here if you're interested: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/141245… And who knows, maybe other dialects will implement these methods too, until then, don't use #collect:as: in code which should be portable across dialects. Levente > > Cheers, > Henry >> >>>> 2010/3/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>> >>>>> Hi. I was needing something like the SQL select distinct, that doesn't take >>>>> into account repeated objects. I didn't found anything useful in Collection, >>>>> and thus, I have implemented this: >>>>> >>>>> Collection >> collectDistinct: aBlock >>>>> >>>>> >>>>> collectDistinct: aBlock >>>>> "Evaluate aBlock with each of the receiver's elements as the argument. >>>>> Collect the resulting values into a Set, thus repeated objects will not >>>>> be present. >>>>> Answer the new collection." >>>>> >>>>> | newSet | >>>>> newSet := self species new asSet. >>>>> self do: [:each | newSet add: (aBlock value: each)]. >>>>> ^ newSet >>>>> >>>>> >>>>> Is there a better way ? Do you think it make sense to put this in Pharo ? >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 12, 2010

Re: [Pharo-project] Code bubbles

by Chris Muller

Well, this is what Maui for Squeak 3.9 does, except Maui is for any domain, not just developer IDE objects.. On Thu, Mar 11, 2010 at 2:12 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 11 March 2010 09:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> The kind of stuff I would have love to see people experimenting with Squeak. >> We failed to be sexy on the UI level. >> > > Amazing stuff!Have no idea how it fits with java, but for smalltalk it > would be really cool! :) > >> 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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 12, 2010

Re: [Pharo-project] Code bubbles

by Andrey Larionov

As a Java developer, i cant say what system like this can boost my productivity. This idea is in the air for about 2 years (seen same ideas for MS VS). As for me, the best IDE i ever seen (from productivity point of view) was a Hopscotch from Vasily and Gillad. On Thu, Mar 11, 2010 at 11:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > oh yes! > > Stef > > On Mar 11, 2010, at 9:12 AM, Igor Stasenko wrote: > >> On 11 March 2010 09:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> The kind of stuff I would have love to see people experimenting with Squeak. >>> We failed to be sexy on the UI level. >>> >> >> Amazing stuff!Have no idea how it fits with java, but for smalltalk it >> would be really cool! :) >> >>> 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 >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 12, 2010

Re: [Pharo-project] [Esug-list] Smalltalk app demo for GSoC

by Stan Shepherd

Mariano, the proposals are related in wanting to show the stack fully integrated. The healthcare application wouldn't have the second benefit that it could be set up ready to roll for a web business. I think that would be a key deliverable of the process I had in mind. It sounds like SmallPOS would be a closer fit from that point of view. So I'd prefer to keep them separate; an attempt to do both projects as one would probably be too large to get either part done. Cheers, ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589873.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 11, 2010