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

[Pharo-project] Store your source code in the cloud using Amazon S3

by Sven Van Caekenberghe

For a long time, I had this idea that it would be a good idea to use Amazon S3 to store Smalltalk source code. A couple of weeks ago I decided to build and deploy a proof of concept. Have a look at: http://mc.stfx.eu Everything is explained on that page. Two of my repositories are publically available: http://mc.stfx.eu/ZincHTTPComponents/ http://mc.stfx.eu/Zodiac/ You can create the relevant MCHttpRepository as usual: MCHttpRepository location: 'http://mc.stfx.eu/ZincHTTPComponents' user: '' password: '' MCHttpRepository location: 'http://mc.stfx.eu/Zodiac' user: '' password: '' If you are interested in testing this, let me know. I have some code to easily copy/sync between repositories. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 9, 2012

Re: [Pharo-project] Socket listenOn: 0 & accept

by Norbert Hartl

Am 09.03.2012 um 18:44 schrieb Sven Van Caekenberghe: > > On 09 Mar 2012, at 16:56, Philippe Marschall wrote: > >> On 03/09/2012 04:44 PM, Sven Van Caekenberghe wrote: >>> Most socket API's allow for the creation of a server socket on the next available port, often by specifying 0 instead of a port. When the socket is bound, one can retrieve the local port and let the client(s) know. I tried to do that in Pharo today, and these steps seem to work, by accepting an incoming connection gives a primitive failed. >> >> Stupid n00b question, isn't 0 a valid port number? > > I don't think so, in Java: > > http://docs.oracle.com/javase/1.4.2/docs/api/java/net/ServerSocket.html#Ser… > > ServerSocket > > public ServerSocket (int port) throws IOException > > Creates a server socket, bound to the specified port. A port of 0 creates a socket on any free port. > Well, I think it is sort of a definition thing. From the protocol perspective 0 is a valid port number in the priviledged segment (0-1023). But reservation of services is done via IANA and there port 0 is "reserved" for UDP and TCP. For your own services you usually wouldn't choose a reserved port numbe like 80,22,etc. That makes 0 kind of free for intermediate use :) Norbert

March 9, 2012

Re: [Pharo-project] Socket listenOn: 0 & accept

by Sven Van Caekenberghe

On 09 Mar 2012, at 16:56, Philippe Marschall wrote: > On 03/09/2012 04:44 PM, Sven Van Caekenberghe wrote: >> Most socket API's allow for the creation of a server socket on the next available port, often by specifying 0 instead of a port. When the socket is bound, one can retrieve the local port and let the client(s) know. I tried to do that in Pharo today, and these steps seem to work, by accepting an incoming connection gives a primitive failed. > > Stupid n00b question, isn't 0 a valid port number? I don't think so, in Java: http://docs.oracle.com/javase/1.4.2/docs/api/java/net/ServerSocket.html#Ser… ServerSocket public ServerSocket (int port) throws IOException Creates a server socket, bound to the specified port. A port of 0 creates a socket on any free port. [â¦]

March 9, 2012

Re: [Pharo-project] ClassBuilder depending -in some way- on text

by Chris Cunningham

On Fri, Mar 9, 2012 at 2:09 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 March 2012 04:28, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: >> >> Guille, >> this likely pre-dates Exceptions (or at least wide-spread use of >> them). Â A much better direction is to use exceptions (or >> Announcements?) here, and have a process capture them and display >> appropriately for what they can display. The mechanism should probably >> include Class name and exception text, which could be rich-formatted >> as above, or plain formatted for command-line UI, or interrogated for >> other observers. >> > if you replace it with exception, it doesn't means that exception should > use text and bold.. > so... > Right, if with exception, just the raw data needed, no fancy formatting (that's for the UI or presentation to handle, if it wants too).

March 9, 2012

Re: [Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by Stefan Krecher

Hi Torsten, my theory is simple: people working in Softwaredevelopment-Departments are somehow techies. So if they see pharo in action and have the ability to use it in a way that is uncritical for the business - they would try it out. Of course they can't decide to use pharo/ seaside for the next project (if the main development environment in that enterprise is Java or .NET). But maybe they can decide to use a Ticketing-system for one of their next projects, which is built on pharo. So they can play around with it, try to enhance it, have fun with it, love it. Exactly like the people who have to play around with Trac, adjust some python-code, enhance it (and hate it). I don't think of pharo as the next-big-thing, but if developers start to use it for little things of their daily work, they will use it for real-projects too. Someday. regards, Stefan Am 9. MÃ¤rz 2012 17:11 schrieb Torsten Bergmann <astares(a)gmx.de>: > Hi Stefan, > > I'm not sure if it is a killer app that is required to get more > visibility for Pharo or a better adoption of Smalltalk. > > We already have nice open-source apps ranging from Seaside, Pier, > Moose, Swiki, ... up to other Smalltalk apps that are sucessfull > also in business life. > > Look at JPMorgans Kapital project done in VW, other big Smalltalk > projects or the Pharo success stories [2] meanwhile known to the world. > Still Smalltalk is very unknown among developers ... > > I agree with Dave Thomas who said that the object abstraction is too > complex for the majority of programmers. [1] > Most people are happy with (boring) CRUD applications and > I doubt a killer app implemented in Smalltalk will change this. > Most of them see no need for switching from Java, C#, ... > > Not that I would not want to see Trac/Bugzilla/... one-click replacements > done in Smalltalk - but building them will eat up our resources to build > something that should be even better than current Smalltalks. > > I doubt that Pharo will become the "next big thing". I'm not > sad about that since most hype technologies will easily fade away > when the next hype comes up. > > Maybe you remember auctomatic.com - these guys have built an app > with Seaside and sold the company for lots of money. So it must > have been a killer app. > > One of them (Patrick) shares some nice thoughts on his > page [3] - if you replace "auctomatic" with Pharo and "ebay" > with one of the mainstream technologies like Java it is an > interesting guide for a future of Pharo too. > Especially regarding internationalization which is I think > an interesting area to get more people into Smalltalk. > > Bye > Torsten > > > [1] http://smalltalk-bob.blogspot.com/2012/03/who-needs-objects.html > [2] http://www.pharo-project.org/about/success-stories > [3] http://patrickcollison.com/blog/2009/10/surprises > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

March 9, 2012

Re: [Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by Camillo Bruni

On 2012-03-09, at 17:11, Torsten Bergmann wrote: > Hi Stefan, > > I'm not sure if it is a killer app that is required to get more > visibility for Pharo or a better adoption of Smalltalk. > > We already have nice open-source apps ranging from Seaside, Pier, > Moose, Swiki, ... up to other Smalltalk apps that are sucessfull > also in business life. > > Look at JPMorgans Kapital project done in VW, other big Smalltalk > projects or the Pharo success stories [2] meanwhile known to the world. > Still Smalltalk is very unknown among developers ... we need visibility... the image as a sole source does not help here, most programmers like files and scripts and their common editors :) - use common tools (github for instance will be available soon on Pharo) - get indexable documentation (google doesn't seem to like squeaksource that much) :) - we need better system integration (accessing ENV vars and program args is still a bit messy in Pharo) - we need an embeddable VM (I guess that is also on the way :)) > I agree with Dave Thomas who said that the object abstraction is too > complex for the majority of programmers. [1] > Most people are happy with (boring) CRUD applications and > I doubt a killer app implemented in Smalltalk will change this. > Most of them see no need for switching from Java, C#, ... look at ruby with ruby on rails, people seem to like it despite the heavy meta programming used in it => we need a decent scripting api (almost there with coral) > Not that I would not want to see Trac/Bugzilla/... one-click replacements > done in Smalltalk - but building them will eat up our resources to build > something that should be even better than current Smalltalks. that might be true, but looking at pharo I seem we still lack some basic tools of a modern programming language. However we made a massive progress over the last years ;) > I doubt that Pharo will become the "next big thing". I'm not > sad about that since most hype technologies will easily fade away > when the next hype comes up. > > Maybe you remember auctomatic.com - these guys have built an app > with Seaside and sold the company for lots of money. So it must > have been a killer app. > > One of them (Patrick) shares some nice thoughts on his > page [3] - if you replace "auctomatic" with Pharo and "ebay" > with one of the mainstream technologies like Java it is an > interesting guide for a future of Pharo too. > Especially regarding internationalization which is I think > an interesting area to get more people into Smalltalk. > > Bye > Torsten > > > [1] http://smalltalk-bob.blogspot.com/2012/03/who-needs-objects.html > [2] http://www.pharo-project.org/about/success-stories > [3] http://patrickcollison.com/blog/2009/10/surprises > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

March 9, 2012

Re: [Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by Stefan Krecher

Am 9. MÃ¤rz 2012 17:24 schrieb Frank Shearar <frank.shearar(a)gmail.com>: > Um. That makes no sense. Pharo developers should develop Pharo, not > something that merely uses Pharo. Or: "Pharo's not being developed > fast enough! Let's make the devs work on something else!" if one of the main goals of the pharo-team would be something like "increase the popularity of pharo", there would be no problem with pharo-developers working on some project using pharo. And i guess that everybody here would like to see pharo more popular and everybody is working somehow on reaching this goal - but it is no bundled community action with one collective goal. But of course you are right - pharo-devs should develop pharo an make it even better - so other people can write great software with it. regards, Stefan

March 9, 2012

Re: [Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by Frank Shearar

On 9 March 2012 15:11, Stefan Krecher <stefan.krecher(a)googlemail.com> wrote: > Am 9. MÃ¤rz 2012 15:01 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> A simple and good looking Ticketing-System for use in an agile team >>> would be a good thing - it's a CRUD-Application with some Reporting >>> and maybe some eye candy. >> >> Why don't you start based on experience to build a tool and share with us. > > i guess, that's what i'm going to do - my problem is, that i'm quite > new too seaside and have no experience with building "eyecandy". I > work at the server-side ... or deal with projectmanagement-stuff > >>> Is anyone interested in creating some OpenSource-Projects for use in a >>> wider range? Those Tools should look "sexy" and should be easy to try >>> (OneClick) or to install as a Service. >> >> Yes we are lot of people interested in that. Just quite busy. > > that's a problem. > > But let me dream: > If pharo was organized as a scrum-project and if i was the product > owner, i would suspend the current pharo development and instruct the > team to work the complete next sprint (e.g. 4 weeks) on an > OpenSource-Project for some general use. > Imagine what a bunch of pharo developers could create in 4 weeks ... > And if companies start to evaluate and use the new software, this > would be a big boost for pharo/ smalltalk. > It would be a complete new way of pushing an Open Source Project. Um. That makes no sense. Pharo developers should develop Pharo, not something that merely uses Pharo. Or: "Pharo's not being developed fast enough! Let's make the devs work on something else!" frank

March 9, 2012

[Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by Torsten Bergmann

Hi Stefan, I'm not sure if it is a killer app that is required to get more visibility for Pharo or a better adoption of Smalltalk. We already have nice open-source apps ranging from Seaside, Pier, Moose, Swiki, ... up to other Smalltalk apps that are sucessfull also in business life. Look at JPMorgans Kapital project done in VW, other big Smalltalk projects or the Pharo success stories [2] meanwhile known to the world. Still Smalltalk is very unknown among developers ... I agree with Dave Thomas who said that the object abstraction is too complex for the majority of programmers. [1] Most people are happy with (boring) CRUD applications and I doubt a killer app implemented in Smalltalk will change this. Most of them see no need for switching from Java, C#, ... Not that I would not want to see Trac/Bugzilla/... one-click replacements done in Smalltalk - but building them will eat up our resources to build something that should be even better than current Smalltalks. I doubt that Pharo will become the "next big thing". I'm not sad about that since most hype technologies will easily fade away when the next hype comes up. Maybe you remember auctomatic.com - these guys have built an app with Seaside and sold the company for lots of money. So it must have been a killer app. One of them (Patrick) shares some nice thoughts on his page [3] - if you replace "auctomatic" with Pharo and "ebay" with one of the mainstream technologies like Java it is an interesting guide for a future of Pharo too. Especially regarding internationalization which is I think an interesting area to get more people into Smalltalk. Bye Torsten [1] http://smalltalk-bob.blogspot.com/2012/03/who-needs-objects.html [2] http://www.pharo-project.org/about/success-stories [3] http://patrickcollison.com/blog/2009/10/surprises -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

March 9, 2012

Re: [Pharo-project] Adding a statement programmatically

by HernÃ¡n Morales Durand

| parseTree resultNode searchTree | parseTree := RBParser parseMethod: 'renderContentOn: aRenderer aRenderer div id: ''id1''; with: [ aRenderer div id: ''idInner1''; render: ''text1'' ].'. searchTree := RBParser parseExpression: 'aRenderer div id: ''idInner1''; render: ''text1''.'. resultNode := ( RBParseTreeSearcher new matchesTree: searchTree do: [ :aNode :answer | aNode parent ] ) executeTree: parseTree. resultNode addNode: (RBParser parseExpression: 'envelopes := nil'). parseTree formattedCode. 2012/3/7 Sean P. DeNigris <sean(a)clipperadams.com> > What's the easiest way to add a statement to an existing method? > > In the case I'm thinking about, it's going at the end, so I can cheat and > just recompile with the string appended, but I'd like to know how to insert > into an arbitrary place in the AST... > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/Adding-a-statement-programmatically-tp4454447p4454447… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

March 9, 2012