February 2015 - Pharo-users

Re: [Pharo-users] pharo and ui again
by Hilaire Feb. 12, 2015

Feb. 12, 2015

Hi Joachim, I agree with your disagreement. Lack of developer support is really a problem. Just get me right: nobody is to blame. We are still a small community, although a growing one. For me one of the biggest lack is documentation (although the huge efforts done by several people). Polymorph for example is really nice to build UI, it offer a nice framework for common UI block but you are still free to hack it with Morph, but we do not have much documentation. You can also read my recent struggle with Magritte, the framework is marvelous but once you get on the trivial use case, you are really on your own to fit to your need. In all these situations your productivity is severely hit. What to do? Personally I try to discipline myself in community contribution: help in the mailing list when possible, even responding to myself when I ask for help and find myself an answer: it is likely it could be useful for other, and easily retrieved from the archive. Now I would like to do a bit more on writing notes on a kind-of knoweldge base for Pharo, in a wiki place or so. But I don't know where yet... Any idea, suggestion? Hilaire Le 12/02/2015 10:03, Joachim Tuchel a Ã©crit : > Hilaire. > > I completely disagree. The 2 areas you spend most of your time (and often waste it ) in my experience with business applications are > > a) The gui > b) persistency > > The tool support for both is pretty poor and both areas have been reinvented over and over again. Most of the reinventions were extremely poor in supporting the developer in getting things done, not to mention maintenance. Sick, isnt it? > > I can only underline what Sebastian said: if building a ui is hard, a system is probably not worth wasting time learning it. > > Just my 2 cents, > > Joachim > > Am 12.02.2015 09:46 schrieb Hilaire <hilaire(a)drgeo.eu>: >> Le 11/02/2015 23:28, Sebastian Heidbrink a Ã©crit : >>> I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I >>> feel like the UI development removes all the productivity that one >>> usually has with Smalltalk. >> You are pretty right. For a small UI project, the UI development can be >> high. >> For a bigger project, where the UI part represent a small fraction of >> the whole project, it is a different story as most of the development >> will be out of the UI land and will benefit from the Pharo productivity. >> This is what I experienced with DrGeo. >> >> By the way, before Polymorph, the situation was even worst. >> Did you look at the Polymorph example in the WidgetExamples class ? >> There are good starter. >> >> Hilaire >> >> -- >> Dr. Geo - http://drgeo.eu >> iStoa - http://istoa.drgeo.eu >> >> >> >> -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

1 0

Re: [Pharo-users] pharo and ui again
by Joachim Tuchel Feb. 12, 2015

Feb. 12, 2015

Let me try to be clearer.... Your observation may be right for some Applications, where there is some heavy lifting in computation and logic. So it is unfair to say you are wrong. There are, however, many areas where its all about searching some data, modifying and saving it. Think crm, erp, accounting, most web apps, and whatnot. These are the ones I had in mind. And in these, gui is the most important area, and the one that eats lots of time and effort. Joachim Am 12.02.2015 10:03 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: > > Hilaire. > > I completely disagree. The 2 areas you spend most of your time (and often waste it ) in my experience with business applications are > > a) The gui > b) persistency > > The tool support for both is pretty poor and both areas have been reinvented over and over again. Most of the reinventions were extremely poor in supporting the developer in getting things done, not to mention maintenance. Sick, isnt it? > > I can only underline what Sebastian said: if building a ui is hard, a system is probably not worth wasting time learning it. > > Just my 2 cents, > > Joachim > > Am 12.02.2015 09:46 schrieb Hilaire <hilaire(a)drgeo.eu>: > > > > Le 11/02/2015 23:28, Sebastian Heidbrink a Ã©crit : > > > I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I > > > feel like the UI development removes all the productivity that one > > > usually has with Smalltalk. > > > > You are pretty right. For a small UI project, the UI development can be > > high. > > For a bigger project, where the UI part represent a small fraction of > > the whole project, it is a different story as most of the development > > will be out of the UI land and will benefit from the Pharo productivity. > > This is what I experienced with DrGeo. > > > > By the way, before Polymorph, the situation was even worst. > > Did you look at the Polymorph example in the WidgetExamples class ? > > There are good starter. > > > > Hilaire > > > > -- > > Dr. Geo - http://drgeo.eu > > iStoa - http://istoa.drgeo.eu > > > > > > > >

1 0

Re: [Pharo-users] pharo and ui again
by Joachim Tuchel Feb. 12, 2015

Feb. 12, 2015

Hilaire. I completely disagree. The 2 areas you spend most of your time (and often waste it ) in my experience with business applications are a) The gui b) persistency The tool support for both is pretty poor and both areas have been reinvented over and over again. Most of the reinventions were extremely poor in supporting the developer in getting things done, not to mention maintenance. Sick, isnt it? I can only underline what Sebastian said: if building a ui is hard, a system is probably not worth wasting time learning it. Just my 2 cents, Joachim Am 12.02.2015 09:46 schrieb Hilaire <hilaire(a)drgeo.eu>: > > Le 11/02/2015 23:28, Sebastian Heidbrink a Ã©crit : > > I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I > > feel like the UI development removes all the productivity that one > > usually has with Smalltalk. > > You are pretty right. For a small UI project, the UI development can be > high. > For a bigger project, where the UI part represent a small fraction of > the whole project, it is a different story as most of the development > will be out of the UI land and will benefit from the Pharo productivity. > This is what I experienced with DrGeo. > > By the way, before Polymorph, the situation was even worst. > Did you look at the Polymorph example in the WidgetExamples class ? > There are good starter. > > Hilaire > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > > >

1 0

Nautilus groups
by Christophe Demarey Feb. 12, 2015

Feb. 12, 2015

Hello, We would like to know if some of you use Nautilus groups functionality: dynamic groups: 'Last modified packages', 'Most viewed classes', 'Work' user defined groups : from the menu, you can flatten the content of many packages and get all classes into the newly created group. We have the feeling that it is not used (or not a lot) and we think to replace it with another mechanism (for example, let the user define his/her 'favorites' classes / packages). Thanks for the feedback.

6 7

Problems evaluating message sends in run-time arrays
by Andy Burnett Feb. 12, 2015

Feb. 12, 2015

I would like to create an array with a collection of colour values. I tried both: colorList := {Color blue} and colourList := {Color named: #blue.}. In both cases it evaluates to 'Color blue' rather than the Color object. What surprised me was that: charList := {Character digitValue:35. Character digitValue:33.}. Does evaluate to an array of two characters. What is going on? Cheers Andy á§

5 5

Re: [Pharo-users] GSOC 2015 application
by Stephan Eggermont Feb. 12, 2015

Feb. 12, 2015

Ben wrote: >Now google say... "Umbrella organizations get more slots. > If an organization is acting as an umbrella for other projects, chances are >we'll allocate more students to you simply because there's a great deal of >different types of work to be done, and we're hoping our students will end >up with something that appeals to them among this wide offering." [1] >The Pharo Consortium might conceivably be considered an umbrella organization, >if a reasonable amount of selected projects relate to applications built on top of Pharo >and not "just" improvements in the Pharo release. e.g. SciSmalltalk, PhaROS, Phratch. > I guess that is a balance to be determined later. New organizations get a low number of slots. Marginalizing other smalltalks is not in our best interest. I think it would be sad not to run as Esug this year. Running as Esug shows we can overcome last years trouble, and start healing the pain. I totally understand Stef doesn't want to be involved, considering the amount of accusations and abuse it has brought, not just last year. Stephan

2 1

Re: [Pharo-users] Problems evaluating message sends in run-time arrays
by Andy Burnett Feb. 11, 2015

Feb. 11, 2015

á§ Sean P. DeNigris wrote <<< Andy Burnett wrote > In both cases it evaluates to 'Color blue' rather than the Color object. 'Color blue' is the Color object you created and put in your array. It is aColor object. It's print string is 'Color blue'. See Color>>#printOn: for more info. >>> Ah, of course! I completely misunderstood what the inspector was telling me. Thanks very much

1 0

get them while they are young
by Martin BÃ¤hr Feb. 11, 2015

Feb. 11, 2015

here is the reaction of a student preparing for a GSoC project for which the student needs to learn smalltalk: "I have installed Pharo v4.0 and started the book Pharo By Example as suggested by you .... I just wanted to say that I am in the initial stages and loving it already :)" greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

4 5

Re: [Pharo-users] GSOC 2015 application
by Stephan Eggermont Feb. 11, 2015

Feb. 11, 2015

Some project ideas 1 Better support for cross-platform co-development Glorp is originally maintained in VisualWorks. We now have a version in Pharo that is forked. It would be nice if we could make sure that changes can be synchronized. The rewriting engine is available on both platforms, and Glorp has a large number of unit tests. If we can describe both migrations with refactorings, we should be able to create builds in ci for both that show when changes break things and otherwise synchronize two-way. This might also be beneficial for Roassal2 and Seaside, that currently use a compatibility layer. Another place where this rewriting can be useful would be in maintaining compatibility between Squeak and Pharo, and in making it easier keeping older code alive. Marcel Taeumel has written a number of interesting applications (UIBuilder, Widgets, XPForums) using a 'signals' style communication. In Pharo it would make sense to have them use Announcements. 2 Use code rewriting to help migrate projects forwards In https://pharo.fogbugz.com/default.asp?13754 cleaning strings API there are 3 method renames. These were included in build 40165. Projects source for pharo can be found on a number of repositories (smaltalkhub, squeaksource, ss3, etc). Upgrade scripts can be generated for these projects to help do these migrations. Stephan

3 3

Re: [Pharo-users] recover lost changes
by Stephan Eggermont Feb. 11, 2015

Feb. 11, 2015

Norbert wrote: >Yes but resources are still sparse. I'm usually arguing the same way like you. >But at the moment I have the feeling we postpone the integration of too much too long. >If the release is postponed until july I'd vote for integrating it now and iron it out. >Otherwise it might be never integrated and that is our poor history of >good projects dying because. I don't know the current state of epicea. To me, it sounds like something that should have some time in real use before the code freeze. I agree that a postponed release would make that time available if we can integrate real soon now. Stephan

1 0