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

[Pharo-project] [update 1.1] #11259
by StÃ©phane Ducasse March 12, 2010

March 12, 2010

11259 ----- - Issue 1614: EmptyBlock is returning last argument instead of nil (thanks lukas and jorge) Stef

1 0

Re: [Pharo-project] [squeak-dev] Re: [vwnc] GSoC idea: Brainstorming portal for better community decision process
by Janko MivÅ¡ek March 12, 2010

March 12, 2010

Hi Gregory, On 12. 03. 2010 01:47, Gregory Bourassa wrote: > Paul has made some criticisms of your idea elsewhere on the thread...and > some of his points are certainly worth considering. > > However, a system with some of the attributes you describe might be > implemented as a "fun" tool to experiment with social communities and > the outcomes of their interactions. If you take one step of > abstraction away from "serious" consensus-seeking and make the tool > configurable enough to support "playing at consensus seeking", it > might become a runaway hit. :-) It seems so :) Sometimes one needs to dress his idea as a toy to easier convince the people, I agree, ok, let we make a toy :) Thanks for that proposal, I'll actually start thinking in this direction! Janko > > Gregory Bourassa > > > Janko MivÅ¡ek wrote: >> Dear Smalltalkers, >> >> Becasue we have quite some problems in a community with seeking a >> consensus on important questions, from organization ones and on, I came >> to idea to build a tool for help. And a GSoC project can be an ideal >> opportunity to build such a tool. What do you think? >> >> Here is a description: >> >> Brainstorming portal for better community decision process >> ========================================================== >> >> Create a web portal for brainstorming sessions/meetings to get ideas and >> answers to important questions in Smalltalk community. Portal should >> allow on-line to: >> >> 1. brainstorm the ideas >> 2. vote to get-out the best ideas >> 3. seek consensus >> 4. analyze - report >> >> On-line session/meeting should look like a Skype session together with a >> brainstorming portal, from collecting ideas to a final decision >> proposal. Example of such session can be a Squeak Oversight Board >> meeting or planning session for a new Smalltalk project. Or some broader >> session in the community, like on a question how to organize better. >> >> Some important concepts: >> >> * anonymity of idea proposers >> * associations: proposers see the ideas of anonymous others to >> facilitate an association for proposing an even better idea >> * seeking consensus to avoid 51/49% decisions but to come closer to >> 100% agreement on important ideas. >> >> Technical details >> >> * a web application for gathering brainstormed ideas in real-time >> (using Ajax and Comet technology). >> * voting system with appropriate algorithms >> * analytics with on-line graphs and reports on paper/PDF >> * installation on a publicly available hosting server >> >> Benefits to the Student >> >> * getting insight into group dynamics of Smalltalk community and in >> general >> * gaining knowledge of modern web technologies in Smalltalk and in >> general >> >> Benefits to the Community >> >> Better community decision process by getting the best ideas from the >> members while on the other side avoiding stalemates so frequent in >> Smalltalk community those days >> >> >> Best regards >> Janko >> >> >> > > ----------------------------------------- > Key Technology, Inc. Disclaimer Notice - The information and > attachment(s) contained in this communication are intended for the > addressee only, and may be confidential and/or legally privileged. If > you have received this communication in error, please contact the sender > immediately, and delete this communication from any computer or network > system. Any interception, review, printing, copying, re-transmission, > dissemination, or other use of, or taking of any action upon this > information by persons or entities other than the intended recipient is > strictly prohibited by law and may subject them to criminal or civil > liability. Key Technology, Inc. is not liable for the improper and/or > incomplete transmission of the information contained in this > communication or for any delay in its receipt. > > > > -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

Re: [Pharo-project] [squeak-dev] RE: [vwnc] GSoC idea: Brainstorming portal for better community decision process
by Janko MivÅ¡ek March 12, 2010

March 12, 2010

Hi Paul, On 11. 03. 2010 22:51, Paul Baumann wrote: >>> What do you think? > > Big mistake to ask that... :) Not at all :) > So "report" is the end goal? Not a big fancy report for big bosses of course. But a result in some easy understand form to base further decisions on. > Consensus doesn't accomplish anything. Many truly great things are not understood by a voting majority. A mixture of pride and reward is required to get work done. Few would anonymously give away great ideas. Who is going to implement a commonly recognized "great" idea that is not their own? Usually the quality and results of work lacking incentive are mediocre at best. What about the destructive personalities that take pride in destroying good ideas? It is those types that love to participate in consensus groups because that is how they derive satisfaction. The outcome of what you are proposing would be the common (mis)understanding of problems. Consensus doesn't mean that understanding is correct. Consensus doesn't mean that what is proposed will really accomplish anything. Consensus doesn't get the goals actually achieved. Consensus work does little more than mimic what someone else already struggled to prove successful--diminishing incentive from people who deserve the credit. I've never seen anything good come from a consensus. About consensus: I don't have in mind bad compromises etc, but moving the initial majory voting result from too frequent 51/49% slowly closer to ideal 100/0%. By continuing the argumented debate, revoting etc. Remember that majory voting usualy leaves a substantial percent of voters unsatisfied, which is not good and can lead to polarization of a community. Seeking a consensus is a technique to lower this percent. But this is also a cultural thing, Japanese are for instance more inclined to consensus seeking. About destructive personalities: Anonymity is here to solve and silence such people, because everyone can say what has in his mind freely, without fear of exposure and any represalies of any form. Also, the result of such idea gathering and voting is a strong argument against such the people. We have just now an example in Squeak community and with a collection of "ideas" with such a tool I'm sure we'd measure what a community really think quite precisely and this will be an undeniable argument against the guy, who thinks that only he knows well, what the community really think. About pride and reward: Well, authors of the best ideas at the end can be announced, but on the other side author of such idea will know that he wins even if he stays anonymous. Also remember that such a tool is not good for every possible case. I think the best is for collecting initial ideas as freely as possible and measuring the opinion about them from others. This can then be a base for the real decisions. Best regards Janko > Better to act in an environment that forms a cycle of individual liberty and reward. Create a market for change where people can work for reward. Pride is the dominant incentive in young markets. Incentive markets originate from pride in the hope to establish a market for financial reward. > > "Stalemate"? That means that there is a gatekeeper blocking change or destroying incentives. What stops a Linux developer from evolving code? Obviously the cost of getting Microsoft to change their code would be a disincentive. Smalltalk is between those extremes, but with fewer incentives to overcome the cost-of-change. To me, Smalltalk development is about rapid evolution. Years ago I stopped caring about releasing code though gatekeepers. I expect you'll find many people have already done really great things but are not sharing them. That is a market opportunity for someone smart enough to develop it. > > Paul Baumann > > > > -----Original Message----- > From: vwnc-bounces(a)cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] On Behalf Of Janko MivÅ¡ek > Sent: Thursday, March 11, 2010 6:15 AM > To: Squeak; Pharo-project(a)lists.gforge.inria.fr; GNU Smalltalk; GemStone Seaside beta discussion; 'VWNC' > Subject: [vwnc] GSoC idea: Brainstorming portal for better community decision process > > Dear Smalltalkers, > > Becasue we have quite some problems in a community with seeking a consensus on important questions, from organization ones and on, I came to idea to build a tool for help. And a GSoC project can be an ideal opportunity to build such a tool. What do you think? > > Here is a description: > > Brainstorming portal for better community decision process ========================================================== > > Create a web portal for brainstorming sessions/meetings to get ideas and answers to important questions in Smalltalk community. Portal should allow on-line to: > > 1. brainstorm the ideas > 2. vote to get-out the best ideas > 3. seek consensus > 4. analyze - report > > On-line session/meeting should look like a Skype session together with a brainstorming portal, from collecting ideas to a final decision proposal. Example of such session can be a Squeak Oversight Board meeting or planning session for a new Smalltalk project. Or some broader session in the community, like on a question how to organize better. > > Some important concepts: > > * anonymity of idea proposers > * associations: proposers see the ideas of anonymous others to > facilitate an association for proposing an even better idea > * seeking consensus to avoid 51/49% decisions but to come closer to > 100% agreement on important ideas. > > Technical details > > * a web application for gathering brainstormed ideas in real-time > (using Ajax and Comet technology). > * voting system with appropriate algorithms > * analytics with on-line graphs and reports on paper/PDF > * installation on a publicly available hosting server > > Benefits to the Student > > * getting insight into group dynamics of Smalltalk community and in > general > * gaining knowledge of modern web technologies in Smalltalk and in > general > > Benefits to the Community > > Better community decision process by getting the best ideas from the members while on the other side avoiding stalemates so frequent in Smalltalk community those days > > > Best regards > Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

[Pharo-project] image overload
by Eliot Miranda March 12, 2010

March 12, 2010

Hi All, I'm sure Im opening an old topic but anyway, as I was riding the train to work today I saw a shop called "Audio Images" and it struck me how overloaded the term image is, and how poor a term for the contents of the image file Smalltalk image is. What's in the image is a snapshot of... almost the entire system (minus platform-specific virtual machine and possibly minus sources). So Smalltalk system file would be a far better term and stsys a more unique file extension (and according to Wikipedia STS is unused too). I can imagine that changing form image would be hugely expensive in documentation terms (docs, websites, workspaces, etc, etc). But I can at least dream of a better term. P.S. I know, wasting one's time worrying about names. Almost as bad as worrying about colours "And the wheel," said the Captain, "What about this wheel thingy? It sounds a terribly interesting project." "Ah," said the marketing girl, "Well, we're having a little difficulty there." "Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? It's the single simplest machine in the entire Universe!" The marketing girl soured him with a look. "Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what colour it should be."

3 2

[Pharo-project] Class comments are in the .sources ?
by Mariano Martinez Peck March 12, 2010

March 12, 2010

Hi folks. I was playing a bit with the ClassOrganizer stuff. I thought that class comments were in the image, but it seems they are kept in the .source. Is this correct ? They are ALWAYS kept in the .sources? I know that the class of the instancia variable "classComment" in the ClassOrganizer can be Text, ByteString or even RemoteString. I though that only those who have RemoteString were in .sources but it seems all are there. I am correct ? is this the desired behavior ? Thanks! Mariano

5 10

Re: [Pharo-project] [vwnc] image overload
by Eliot Miranda March 12, 2010

March 12, 2010

On Fri, Mar 12, 2010 at 10:51 AM, Bruce Boyer <bruce.boyer(a)alumni.uci.edu>wrote: > This is rather a sensitive area with me at the moment, as I'm working on > indexing docs. I've had to resort to using "image" and "graphical image" to > try to distinguish these two, but "image" remains unclear to anyone who > doesn't already know. > > I could guess that the term "snapshot" came first, as a methaphorical > attempt to describe what saving that thing is, and "image" is what snapshots > give (or pictures or something even worse for that thing). But, it's only a > guess. > Right. That's why I don't like either snapshot or image. What are these snapshots or images of? They are intentionally abstract terms and are unhelpful. Yes, snapshot is much better, but still hopelessly abstract. > If a really good term were proferred, the documentation cost will be > amortized over a long period of time, so not a worry. Getting it accepted > by smalltalkers will be the harder problem. > > I'm not sure, though, that "system file" is right. The file part is just > an artifact of saving the state of the system, providing a way to preserving > it for a restart. > But I see a snapshot file are more than just a memory dump. It /is/ the entire Smalltalk system, class library, potentially compiler, debugger, tools. It is in a format that requires the virtual machine to run it, but it is in fact the Smalltalk system in quiescent form. It is not a memory dump. It is only a dump of the Smalltalk object heap, not the entire memory space. It is more than just a way of saving the state. It is also a way of moving that state and resuming it on a different system. Once you have the virtual machine key you can unlock the image, uh, system, but everything you need to program the system (beyond execution display and input devices) is there. Is there a recognizable term for the state of memory at a moment? > Cognitive scientists might have something, though I'm sure it would be > hugely debated whether there is any such thing. > I forget... > > Waste of time? Perhaps. But, beats indexing :) > > Bruce > > ----- Original Message ----- > *From:* Eliot Miranda <eliot.miranda(a)gmail.com> > *To:* The general-purpose Squeak developers list<squeak-dev(a)lists.squeakfoundation.org>; Pharo > Development <pharo-project(a)lists.gforge.inria.fr> ; vwnc NC<vwnc(a)cs.uiuc.edu> > *Sent:* Friday, March 12, 2010 9:59 AM > *Subject:* [vwnc] image overload > > Hi All, > > I'm sure Im opening an old topic but anyway, as I was riding the train > to work today I saw a shop called "Audio Images" and it struck me how > overloaded the term image is, and how poor a term for the contents of the > image file Smalltalk image is. What's in the image is a snapshot of... > almost the entire system (minus platform-specific virtual machine and > possibly minus sources). So Smalltalk system file would be a far better > term and stsys a more unique file extension (and according to Wikipedia STS > is unused too). I can imagine that changing form image would be hugely > expensive in documentation terms (docs, websites, workspaces, etc, etc). > But I can at least dream of a better term. > > P.S. I know, wasting one's time worrying about names. Almost as bad as > worrying about colours > > "And the wheel," said the Captain, "What about this wheel thingy? It sounds > a terribly interesting project." > "Ah," said the marketing girl, "Well, we're having a little difficulty > there." > "Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? > It's the single simplest machine in the entire Universe!" > The marketing girl soured him with a look. > "Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what > colour it should be." > > ------------------------------ > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >

1 0

Re: [Pharo-project] [Esug-list] Smalltalk app demo for GSoC
by Mariano Martinez Peck March 12, 2010

March 12, 2010

In the other thread, Stan Shepherd, proposed the following proposal: what do you think ??? for me is ok. Don't worry for the technology. It can be decided after, by the mentors and student. Now...we need a mentor...volunteer??? ........Stan mail: Hi, I had a first pass at a proposal. Feel free to improve upon it. The major question is whether we should bite the bullet and nominate what technologies we would use to build the reference implementation. It would also make it easier to nominate the mentors, if they are to be experts in the particular technologies. I think we had some volunteers previously for Seaside/Grease related projects? Smalltalk is enjoying a resurgence in its development, with a great deal of development going into building out its abilities to underpin a web framework. Auctomatic was a recent startup built in Smalltalk, that received seed funding from Y-Combinator and was acquired by Live Current Media. People who build in Smalltalk know that it lends itself to fast development, and that web aplications can be upgraded on the fly, without the need to take down the server. The goal of this project is to spread the use of Smalltalk to a wider audience. The scope is to produce a reference implementation of a Smalltalk stack, in the form of a working e-commerce site. The participants will select and integrate the preferred technologies, and build on existing demonstration systems. The result will make it much easier for potential new Smalltalkers to evaluate the technology, by seeing a fully working example, and then to get started on their own application by downloading that same example as a working template. The Smalltalk community, and in particular the open source Smalltalk community, will benefit as follows: improved quality and documentation of the technology stack at its interfaces Availability of a one stop solution as the basis for new projects better ability to attract new participants and projects to Smalltalk. The student participant will gain experience of implementation of a real world Smalltalk project, and of the practicalities of e-commerce development. The student would be well positioned to participate in a startup using the technology stack. 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 ;) > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/listinfo/esug-list >

4 11

[Pharo-project] URGENT!! Please help for GSoC
by Mariano Martinez Peck March 12, 2010

March 12, 2010

There was a new question in the submission to GSoC which says: "If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006." Does someone understand this ? is this acceptance projects (google slots) over the total proposed projects ? If true, I know in 2008 were selected 5 projects over 18, but I have no idea about 2007. Please, we are almost in deadline :( Thanks Mariano

4 4

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 March 12, 2010

March 12, 2010

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

1 0

Re: [Pharo-project] GSoC Idea: GLORP & Magritte integration/refactoring
by Mariano Martinez Peck March 12, 2010

March 12, 2010

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

2 1