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

[Pharo-project] DEADLINE for submitting projects

by Mariano Martinez Peck

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

March 11, 2010

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

by George Herolyants

Hi, Mariano. 2010/3/11 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Would be cool to see what other think. Now...do this make sense if we > already have SqueakSVN ?Â which this new project would be better than > SqueakSVN or why isn't it worth to continue with SqueakSVN instead of start > from scratch ? There's some points. First, Git and Mercurial become more and more popular, especially in the open source world. Second, they are distributed which is important aspect, especially again for the open source. I tried SqueakSVN and it also requires some work. Less than this project, of course. But I think some parts of the SqueakSVN can be reused. SVN is client-server SCM so it can't compete with Monticello which is highly distributed. Competition is good, and more choice is better. I even think that developing them in parallel can help each of them and Monticello too. And I'm generally interested in distributed solutions, while svn isn't one of them. Also, Git/Mercurial suit better to replace changes/sources again because of their distributed nature.

March 11, 2010

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

by Mariano Martinez Peck

Hi Stan. Today **Stephan Eggermont submitted two prejects that you can see in http://gsoc2010.esug.org/ideas.html The prjects are Tutorial application for Suixoand Add functionality to Suixo I think they are quite related. What do you think ? it is worth to add your proposal ? do a merge ? Thanks Mariano On Thu, Mar 11, 2010 at 7:38 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > > Mariano Martinez Peck wrote: > > > > So...I keep the proposal as it first version or do I change something ? > > > > I think it can stay as is, as we're not specifying the technology stack > ...Stan > -- > View this message in context: > http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589512.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 11, 2010

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

by Stan Shepherd

Mariano Martinez Peck wrote: > > So...I keep the proposal as it first version or do I change something ? > I think it can stay as is, as we're not specifying the technology stack ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589512.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 11, 2010

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

by Mariano Martinez Peck

Hi George. Thanks for the proposal. Yes, you have time until tomorrow morning :) Would be cool to see what other think. Now...do this make sense if we already have SqueakSVN ? which this new project would be better than SqueakSVN or why isn't it worth to continue with SqueakSVN instead of start from scratch ? Is it just because GIT seems to be better than SVN ? Maybe a clarification of this in your proposal will be better so that people like me understand why this project is interesting. Cheers Mariano On Thu, Mar 11, 2010 at 7:27 PM, George Herolyants < george.herolyants(a)gmail.com> wrote: > 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 >

March 11, 2010

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

by George Herolyants

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

March 11, 2010

[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

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 > >

March 11, 2010

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

by Mariano Martinez Peck

So...I keep the proposal as it first version or do I change something ? please let me know as soon as possible On Thu, Mar 11, 2010 at 3:00 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > > Mariano Martinez Peck wrote: > > > > 2010/3/11 Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <tallman(a)inbox.ru> > > > >> > "...to show the rest of the world what kind of things can be done in > >> Smalltalk nowadays" > >> > >> Yes. I really hate strange situation, when people "likes" smalltalk. > >> Sometimes they even make some cryptic tools for smalltalk. But, when > some > >> end-user application needed, they don't choose smalltalk for it. Even if > >> they have a choice. Don't know about ESUG, but in RSUG (Russian > Smalltalk > >> Users Group) it's a common situation. > >> > >> Generally, I hate the situation, when it's "cool" to make system tools, > >> tools for developing, tools for tools for developing, fremeworks, > >> sometimes > >> really very cool and usefull...but somewhy it's "not cool" to use all > >> this > >> staff to make real applications to solve real problems. What all this > >> cool > >> stuff for then, huh? > >> > >> > The idea is to present potential newcomers to Smalltalk with a viable > >> stack that could be picked up as is, to give a > >> > starting point for developing web applications. > >> > >> I working for SmallPOS (http://squeaksource.com/SmallPOS.html) project > >> for > >> some time. And it's very close to what you talking about. Even more, it > >> tends to be real application, with real shop using it for trading. I > made > >> it > >> opensource for exactly same reason - to show possibilities, to give an > >> example can be used to learn, to give a starting point to not start new > >> application from scratch and finally - fight this strange situation with > >> rarely practical application of smalltalk. > >> > >> > edit > >> > copy > >> > search > >> > display in list > >> > display in report > >> > a stuff or a list of stuff. > >> > >> Yes, all this and lot of details. I trying to use > >> Magritte+GLORP+Seaside+Scriptaculous enviroment. It was a good (and > >> unexpectedly painfull) practical experience. So, you can find: > >> - generating of lists and tree-like lists from magritte descriptions > >> - list filters and list fast searches based on magritte descriports, too > >> - custom magritte descriptors, components and memento, custom magritte > >> renderers and, generally, how to use Magritte descriptions for something > >> new, not-yet-implemented > >> - using both full-generated, full-customized and _partially-customized_ > >> (you don't touch component's structure, and you uses magrittes field > >> editors, but you can fully control when they situated) web-forms > >> - using web-forms with table parts inside them > >> - nested editing (to add Order you need add person, to add person, you > >> need > >> to add City it lives at, to add a City you need to add a Country and so > >> on) > >> - using GLORP with sometimes not-trivial mappings (not VERY untrivial > I'm > >> sorry) > >> - using (custom magritte) mementos to fight the absence of nested > >> UnitOfWorks in GLORP, so nested editing becomes possible > >> - using AJAX to make interactive - and painless - webforms. You just > >> added > >> list of affected fields in metadescriptor of given field - and they will > >> be > >> updated via AJAX when form will be generated. > >> - using KomHttpServer to host files like icons and CSS-styles. > >> > >> I beleive this list will be expanded 'till GSoC will begins. So, maybe > it > >> will help to solve problem > >> > >> > The only thing I am concerned a bit is the scope of the project. It > >> seems > >> quite big. > >> > >> Maybe using SmallPOS as a basis will make things easier and faster, and > >> avoid some already-made efforts. Well, SmallPOS is not "web shop", it's > >> POS, > >> but it should be quite posible - and even not too hard - to convert it > >> into > >> webshop. I especially tried to keep it as modular as possible. I want > to > >> try to use another persistence level and another GUI one day. > >> > >> Another problem necessary to solve is: I try to keep code more or less > >> clean, but due to time restrictins I can't totally avoid fast dirty > >> tricks. > >> I just trying to mark them for future fixes :) > >> > >> Next, I absolutely do not worried about internationalisation. Taking > into > >> account SmallPOS practically (maybe even totally) have no hardcoded > >> labels > >> (they all comes from magritte descriptors or from domain-specific > >> webforms) > >> it's not a conceptual problem, but it makes fast education virtually > >> impossible for non-russians. > >> > >> Finaly, PayPal prohibits receiving money for russian users, so I can't > >> make > >> a paypal connector for e-business...I just can't test it ;) > >> > >> So there are still a lot of work for a student, but, utilising ready > >> results it may make things much easier - or, as an option, it make > >> possible > >> to reach much more shining results with great efforts ;) > >> > > > > Hi Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ ( is that Tallman? - I got your reply third hand via > different lists ;) ) > > I wasn't aware of SmallPOS, and indeed it sounds like it could be a great > starting point for such a project. I'll try to load it up soon; are there > any screenshots etc available? > > I'm glad you've used Magritte for it. Could this act as an abstraction > layer > for the GUI side? I ask because there seems more action in JQueryUI than > Scriptaculous in the Seaside world. It would be perfect if the reference > application could be GUI agnostic. Similar argument for persistence > back-end. > > re internationalisation, & putting on a marketing hat for a moment, the > name > sounds a lot like the fatal disease smallpox. If you're willing to consider > rebranding, that could be worth considering. It could be the sort of thing > people only notice once your application becomes well known, and then > rebranding is difficult. > > Also re internationalisation, it could be a nice to have feature that > people > could provide translations for a given phrase in their own language, from > within the application. Not hard to do I think, but perhaps would need to > be > moderated. > > Thanks for the suggestion, and for supporting the idea, ...Stan > > > > > -- > View this message in context: > http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1588990.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 11, 2010

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

by Marcus Denker

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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 11, 2010

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

by Mariano Martinez Peck

> > 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 ? Thanks Mariano > > Cheers > > > > Mariano > >> > >> > Thanks! > >> > > >> > Mariano > >> > > >> > _______________________________________________ > >> > 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 > > > > > > -- > 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 11, 2010