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

Re: [Pharo-project] URGENT!! Please help for GSoC

by askoh

In 2008, Squeak Project was allocated 5 students. We had 5 students and all passed. 100%. Aik-Siong Koh -- View this message in context: http://n4.nabble.com/URGENT-Please-help-for-GSoC-tp1590585p1590738.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 12, 2010

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

by Stan Shepherd

I am happy to volunteer, to to co-mentor with Tallman. I would however recommend eg Lukas instead of me, for ready access to a lot of the tacit knowledge about the stack. ...Stan On 12 March 2010 08:36, Mariano Martinez Peck [via Smalltalk] <ml-node+1590257-1441068202-4901(a)n4.nabble.com> wrote: > 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 <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ________________________________ > View message @ > http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590257.html > To unsubscribe from Re: [Esug-list] Smalltalk app demo for GSoC, click here. > -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590728.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 12, 2010

Re: [Pharo-project] URGENT!! Please help for GSoC

by Geert Claes

ESUG has not participated in the past, so I guess that the ratio would need to come from someone who was participating through the Squeak project in past GSoCs. -- View this message in context: http://n4.nabble.com/URGENT-Please-help-for-GSoC-tp1590585p1590677.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 12, 2010

Re: [Pharo-project] Collection

by Philippe Marschall

Lukas Renggli wrote: >> What would be cool for Seaside IMHO: >> - Multi Value Dictionaries, e.g. for request parameters >> - Some kind of thread safe map with atomic operations [2], e.g. for >> session store > > Why would that be cool? We already have a WAMultiValueDictionary for > request parameters. We could (theoretically, if other dialects follow) delete our code. Everybody who needs something similar doesn't need to write his own. > Also we have some ad-hock solutions for the thread > safe dictionaries. Yeah, the same comment as above applies. Cheers Philippe

March 12, 2010

Re: [Pharo-project] URGENT!! Please help for GSoC

by Mariano Martinez Peck

ok...Thanks...but I still don't know the answer. Does someone know ? 2010/3/12 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > I would recon they mean the percentage of students who actually finished > the projects they were allocated to in previous years, not the percentage of > projects proposals which were accepted. > > Cheers, > Henry > > Den 12.03.2010 15:34, skrev Mariano Martinez Peck: > > 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 > > > _______________________________________________ > Pharo-project mailing listPharo-project@lists.gforge.inria.frhttp://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] URGENT!! Please help for GSoC

by Henrik Johansen

I would recon they mean the percentage of students who actually finished the projects they were allocated to in previous years, not the percentage of projects proposals which were accepted. Cheers, Henry Den 12.03.2010 15:34, skrev Mariano Martinez Peck: > 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 > > > _______________________________________________ > 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

[Pharo-project] URGENT!! Please help for GSoC

by Mariano Martinez Peck

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

March 12, 2010

Re: [Pharo-project] Collection

by Lukas Renggli

> What would be cool for Seaside IMHO: > - Multi Value Dictionaries, e.g. for request parameters > - Some kind of thread safe map with atomic operations [2], e.g. for > session store Why would that be cool? We already have a WAMultiValueDictionary for request parameters. Also we have some ad-hock solutions for the thread safe dictionaries. I would be more interested to see ... - if it would be beneficial for a collection to be able to swap out its internal representation automatically depending on its load and use ... - what we can do by externalizing the enumeration protocol (no, this is not the same as streams or the iterable refactoring that was recently proposed) ... - how to make collections more composable, e.g. make them thread safe, make them read-only, make them ordered (sets and dictionaries), ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 12, 2010

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

by laurent laffont

Hi What do you think about a "Seaside app generator". Most "classic" web apps needs a bunch of models, a database and automatic forms to enter datas. (Think about Rails+sqlite+ActiveScaffold). I would like to type something like: SeasideApplication new name: 'MyLibrary'; model: 'Library' hasAttributes:#(name location); hasMany: 'Artwork'; model: 'Artwork' hasAttributes: #(title author); models: #(Book CD DVD) are: 'Artwork'; model: 'Artwork' hasMany: 'Copy'; withMagmaDatabase; generateInPackage: 'SeasideLibrary'. And create all the stuff with magritte forms, jquery and selected database, load the required packages and create basic unit tests. Cheers, Laurent Laffont 2010/3/12 Mariano Martinez Peck <marianopeck(a)gmail.com> > 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 >> > > > _______________________________________________ > 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] Collection

by Philippe Marschall

stephane ducasse wrote: > Hi guys > > tristan is a new student here and he would like to work on collection optimization and implementation. > I would like the get some ideas from you. > - are there some collections that would be cool to improve? > - are there some collections that would be cool to have and that we do not have yet? > If you have any idea related to optimizations let me know. I will get bashed but: [1] What would be cool for Seaside IMHO: - Multi Value Dictionaries, e.g. for request parameters - Some kind of thread safe map with atomic operations [2], e.g. for session store [1] http://code.google.com/p/google-collections/ [2] http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentMap.ht… Cheers Philippe

March 12, 2010