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

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

by Marcus Denker

On Mar 11, 2010, at 11:21 AM, StÃ©phane Ducasse wrote: > This is not bad or good. A lot of the design decision where taken for extremely small machines (80k loom) > Now marcus would say that he wants everything in memory. :) I would that my 13inch *laptop* has 4GB RAM *today* and that research should be about inventing the Future... :-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 12, 2010

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

by Mariano Martinez Peck

Ok...I added a description Eliot send me. You can check if you want. Cheers Mariano On Fri, Mar 12, 2010 at 7:24 AM, Gilad Bracha <gbracha(a)gmail.com> wrote: > > On Thu, Mar 11, 2010 at 9:44 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > >> 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? >> > > Thanks, but no thanks :-) > > I know SmaCC exists, but I never use parser generators. In Newspeak we use > parser combinators, which is a much nicer approach. There is a Smalltalk > version of the parser combinator library as well as a Newspeak one. > Making parsers is easy if you have the correct grammar. > > There is of course something to be said for a ready made parser if it > exists - but you have to be confident it is correct, and you become > dependent on the framework it uses. > > > >> >> 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 >> > > > > -- > Cheers, Gilad > > > >

March 12, 2010

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

by Mariano Martinez Peck

OK...I have just added this project. Cheers Mariano 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 12, 2010

Re: [Pharo-project] [squeak-dev] Re: GSoC Idea: GLORP & Magritte integration/refactoring

by George Herolyants

2010/3/12 Mariano Martinez Peck <marianopeck(a)gmail.com>: > BTW, which is your name with this alphabet ? I guess it is "Yuriy Mironenko".

March 12, 2010

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

by Mariano Martinez Peck

Excellent. I have just put it. Which level do you think it should be ? beginner, intermediate or advanced ? Cheers Mariano On Fri, Mar 12, 2010 at 8:18 AM, George Herolyants < george.herolyants(a)gmail.com> wrote: > 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 2010: Extensible parsing and persistency for Pier

by Mariano Martinez Peck

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

March 12, 2010

Re: [Pharo-project] GSoC Idea: GLORP & Magritte integration/refactoring

by Mariano Martinez Peck

Ok...Done. I put you as Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ as mentor (BTW, which is your name with this alphabet ?) and DiÃ³genes Moreira as co-mentor. Which difficult we should put ? beginner, intermediate or advanced ? Thanks Mariano 2010/3/12 Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <tallman(a)inbox.ru> > Glorp and Magritte both map between model-layer objects and other domains; > in Glorp's case, the relational database, in Magritte's case, the web. The > truth is that Magritte is a meta-description framework for all kind of > descriptions. However, it is mostly used for web applications. > > There are many similarities in how each framework manage model-layer class > - accessing model's fields, mapping those fields to it's representation, > caching/commiting/rollbacking, condition checking/validation and so on. Lot > of business applications are RDS-based, CRUD-like systems, with GUI > structure close to model structure, and model structure close to database > structure. So, developers sometimes feel they are repeating themselves when > they code first the Glorp descriptors and then the Magritte descriptors, or > vice versa. > > The goals of this project are: > Detect common aspects of both frameworks > Compare implementation of those common aspects in both frameworks, and > choose/compile "best" one > Detect any limitations of one framework revealed by comparison with the > other > Refactor the stuff, splitting it to three groups: "common metamodeling", > "Generic ORM" and "GLORP-related" > Cleanup GLORP from "common metamodeling" and "Generic ORM" stuff. > > The output is both a refactored codeset with three level of abstractness, > and an analysis of why functionality was splitted in this exactly way. > > Technical Details > =========== > Glorp and Magritte have good test suites. XP development to ensure existing > facilities remain functional will protect the student from breaking some > facilities as they experiment with refactorings. Maintaining, where > possible, deprecated methods that call new API in terms of old API may be > appropriate in the project, and may also assist introduction of the results > to the community. > > There are at least two projects to observe, one is for magritte-based SQL > mapping without GLORP, another one - generator of simple GLORP mappings with > Magritte descriptors. > > Maybe it will be necessary to make some tools for describing > domain-specific Magritte things. For example, something like "with this > domain-specific descriptor you should use this domain-specific memento for > caching". > > Benefits to the Student > =============== > Glorp and Magritte are two meta-modelling/mapping frameworks with > impressive capabilities solving real problems: the student who does this > project will acquire significant practical knowledge of this kind of > meta-modelling. Glorp and Magritte are also important parts of one way of > writing web applications: the student who does this project will have skills > that can be turned to practical account in web development. > > Benefits to the Community > =============== > Decreasing complexity and entry level for projects with both Magritte and > GLORP inside (a lot of enduser applications really). > Increasing quality of both Magritte and GLORP. Decreasing complexity of > GLORP, which is very complex now becouse of all the stuff for > meta-describing inside. > And avoiding double-efforts in future, so when we'll upgrade Magritte, > we'll upgrade GLORP simultaneously. > >

March 12, 2010

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

by Mariano Martinez Peck

Stan I am lost...do you volunteer to be the mentor of this project ? Tallman can be co-mentor if you want. PLease, let me know as soon as possible cheers mariano On Thu, Mar 11, 2010 at 11:49 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > 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. > > _______________________________________________ > 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] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.

by John M McIntosh

On 2010-03-11, at 11:18 PM, George Herolyants wrote: > Oh, sorry, here it is: > > > > ++ Pharo/Squeak integration with git/mercurial. > > * 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. Ok, sitting on my desktop here is the work from "The squeak world tour", Ginsu via Joseph Pelrine and John Sarkela. I think this might have some relevance to the project since it : I'll quote Joseph: "maps classes and methods (or better, their semantic definitions) into Subsystems, each of which can have a separate execution environment, allowing remote image work, alternate compilers, passive images, tethered compilation, etc. You can work on and validate code that's not installed in the image." But it is missing the repository backend. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 12, 2010

[Pharo-project] Fwd: GSOC 2010: Extensible parsing and persistency for Pier

by Tudor Girba

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

March 12, 2010