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

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

by Mariano Martinez Peck

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 >

March 10, 2010

[Pharo-project] How I build squeak-vm with FT2Plugin on Linux

by laurent laffont

Hi, As a memento for me, I've written a tutorial to build the VM on Linux. http://magaloma.blogspot.com/2010/03/how-i-build-squeak-vm-on-archlinux.html I also provide the binaries and Pharo image with VMMaker loaded. As I'm newbie on building a VM, thanks for additional informations. Cheers, Laurent Laffont

March 10, 2010

Re: [Pharo-project] ESUG gentle actions reminder

by StÃ©phane Ducasse

On Mar 10, 2010, at 10:56 PM, John M McIntosh wrote: > > On 2010-03-10, at 1:20 PM, StÃ©phane Ducasse wrote: > >> Hi john >> BTW did you say that to the scratch people? May be you should mention that to etoyers and squeakers too. May be etoy could run on iPhone/iPad? > > Ah, ok I'll send a note to John Maloney then so he understands the side effects of ESUG funding. > There isn't a technical reason *why* eToys couldn't run on an iPad. I can't speak for performance, or issues about approval tho. > Plus you need to port the ogg plugin, and as always how does the software engineer get paid? Ok fair. >> We are happy to get scratch further too. I heard rumors that they would rewrite everything in another language >> so the iphone and ipad support may be the best way to keep them in smalltalk. I hope. > > They have done work with Java, and I believe Flash. Unfortunately the 400 kilogram gorilla in the room (Apple) has > managed to choose neither, :) send him banana to compliment him :) > which then makes it rough for them to work with the iPad. > >> >> I have a question. I could not try yet (I asked mariano to play with an ipod touch and we will buy an ipad) >> is scratch working ok from a speed point of view on an ipod touch? > > Some projects are good, some are poor. John Maloney sent me some graphic test cases. > We see a full background frame takes Squeak about 80 ms to render to the Squeak Display form, > for a sprite it's about 32 milliseconds. The time taken to take the Squeak Display form and splash on > the glass is near zero. A few hours last night spent fiddling with compiler magic and other things showed > the current setting I'm using are optimal. 60%+ of the time is in copyLoop anyway. > > So it's all about optimization in the Smalltalk code. Ok we should continue pushing that. > Rumour is an iPad is much faster. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > >

March 10, 2010

Re: [Pharo-project] freeNamesAndValues

by StÃ©phane Ducasse

ok it was removed by pavel so this is a good move. Stef On Mar 10, 2010, at 10:19 PM, Eliot Miranda wrote: > > > On Wed, Mar 10, 2010 at 1:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > freeNamesAndValues > | aStream eval | > eval := > [ :string | > self class evaluatorClass new > evaluate2: string readStream > in: self > to: nil > notifying: nil > ifFail: > [ "fix this" > self error: 'bug' ] > logged: false ]. > aStream := '' writeStream. > self freeNames doWithIndex: > [ :name :index | > aStream > nextPutAll: name; > nextPut: $:; > space; > tab. > (eval value: name) printOn: aStream. > aStream cr ]. > ^ aStream contents > > apparently > > freeNames > > ^ self methodNode freeNames > > freeNames is not defined on compiledMethod > > Elliot do you have that in your image? > > Nope. Never heard of it. > > > Stef > > _______________________________________________ > 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 10, 2010

Re: [Pharo-project] ESUG gentle actions reminder

by John M McIntosh

On 2010-03-10, at 1:20 PM, StÃ©phane Ducasse wrote: > Hi john > BTW did you say that to the scratch people? May be you should mention that to etoyers and squeakers too. May be etoy could run on iPhone/iPad? Ah, ok I'll send a note to John Maloney then so he understands the side effects of ESUG funding. There isn't a technical reason *why* eToys couldn't run on an iPad. I can't speak for performance, or issues about approval tho. Plus you need to port the ogg plugin, and as always how does the software engineer get paid? > We are happy to get scratch further too. I heard rumors that they would rewrite everything in another language > so the iphone and ipad support may be the best way to keep them in smalltalk. I hope. They have done work with Java, and I believe Flash. Unfortunately the 400 kilogram gorilla in the room (Apple) has managed to choose neither, which then makes it rough for them to work with the iPad. > > I have a question. I could not try yet (I asked mariano to play with an ipod touch and we will buy an ipad) > is scratch working ok from a speed point of view on an ipod touch? Some projects are good, some are poor. John Maloney sent me some graphic test cases. We see a full background frame takes Squeak about 80 ms to render to the Squeak Display form, for a sprite it's about 32 milliseconds. The time taken to take the Squeak Display form and splash on the glass is near zero. A few hours last night spent fiddling with compiler magic and other things showed the current setting I'm using are optimal. 60%+ of the time is in copyLoop anyway. So it's all about optimization in the Smalltalk code. Rumour is an iPad is much faster. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 10, 2010

Re: [Pharo-project] [Seaside] Google Summer Of Code 2010 news!!!

by Stan Shepherd

StÃ©phane Ducasse wrote: > > > On Mar 10, 2010, at 3:08 PM, stan shepherd wrote: > >> I know the deadline approaches, however- how does the community feel >> about a project to implement a real demonstration system (along the >> lines of defunct Sushi store)? >> ... >> >> Do people think it's useful for me to develop a proposal? > > yes! >> >> Cheers, ..Stan >> >> PS I realise that picking a component as part of the stack is fraught >> with possibilities of offending supporters of an alternative project. >> But more Smalltalkers overall means more potential users of each >> project >> > 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. Cheers, ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1588111.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 10, 2010

Re: [Pharo-project] MIT strikes back (was Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!)

by StÃ©phane Ducasse

great links Stef On Mar 10, 2010, at 9:59 PM, Torsten Bergmann wrote: > Two interesting articles: > > How Sun failed with OpenSource [1] ... > > and on Liferay switching away from MIT to LGPL (see [2]), interesting - especially the reaction from community in the comments. > > Bye > T. > > > [1] http://blogs.zdnet.com/BTL/?p=31418&tag=nl.e539 > [2] http://www.liferay.com/web/bryan.cheung/blog/-/blogs/liferay-adopting-the-l… > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 10, 2010

Re: [Pharo-project] ESUG gentle actions reminder

by StÃ©phane Ducasse

Hi john Excellent! I forgot to thank the local organizers like michele, alain that help us to make money with the conference organization. You know when we took over ESUG we dreamed of making things but the money was not there because the conference in itself was the goal and this was ok. But we wanted to do more :) BTW did you say that to the scratch people? May be you should mention that to etoyers and squeakers too. May be etoy could run on iPhone/iPad? We are happy to get scratch further too. I heard rumors that they would rewrite everything in another language so the iphone and ipad support may be the best way to keep them in smalltalk. I hope. I have a question. I could not try yet (I asked mariano to play with an ipod touch and we will buy an ipad) is scratch working ok from a speed point of view on an ipod touch? On Mar 10, 2010, at 9:52 PM, John M McIntosh wrote: > > On 2010-03-09, at 11:28 PM, StÃ©phane Ducasse wrote: > >> who knows? >> Some people with a small vision :) >> >> And may be some people may not have noticed that over the years some open source dialect got a lot out of ESUG >> and they could insinuate that ESUG coudl be against it. >> We did not put all the cost of the actions because we are not that picky >> but a project is about 2500 Euros, and summertalk was 1500 Euros now 2500 Euros >> and cleaning Squeak VM for example cost several project cost. > > Because of that, (Squeak for the Macintosh V5 and iSqueak v2.x ) It made it possible for me to implement a Scratch viewer for the iPhone > If you check the reviews at http://itunes.apple.com/us/app/scratch/id358266270?mt=8 > You'll see it made a lot of 12 years old kids happy. Although the kids don't directly see the ESUG funding here, it did have an impact in their lives. > Also out of it the MIT folks will have a transition platform (Scratch on the iPad) to explore UI issues with. > > -- > =========================================================================== > 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

March 10, 2010

Re: [Pharo-project] freeNamesAndValues

by Eliot Miranda

On Wed, Mar 10, 2010 at 1:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > freeNamesAndValues > | aStream eval | > eval := > [ :string | > self class evaluatorClass new > evaluate2: string readStream > in: self > to: nil > notifying: nil > ifFail: > [ "fix this" > self error: 'bug' ] > logged: false ]. > aStream := '' writeStream. > self freeNames doWithIndex: > [ :name :index | > aStream > nextPutAll: name; > nextPut: $:; > space; > tab. > (eval value: name) printOn: aStream. > aStream cr ]. > ^ aStream contents > > apparently > > freeNames > > ^ self methodNode freeNames > > freeNames is not defined on compiledMethod > > Elliot do you have that in your image? > Nope. Never heard of it. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 10, 2010

[Pharo-project] freeNamesAndValues

by StÃ©phane Ducasse

freeNamesAndValues | aStream eval | eval := [ :string | self class evaluatorClass new evaluate2: string readStream in: self to: nil notifying: nil ifFail: [ "fix this" self error: 'bug' ] logged: false ]. aStream := '' writeStream. self freeNames doWithIndex: [ :name :index | aStream nextPutAll: name; nextPut: $:; space; tab. (eval value: name) printOn: aStream. aStream cr ]. ^ aStream contents apparently freeNames ^ self methodNode freeNames freeNames is not defined on compiledMethod Elliot do you have that in your image? Stef

March 10, 2010