June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SimpleWebDoc

by StÃ©phane Ducasse

Better focus on the one developed by camillo bruni and that we should put online when he is back from Japan. Stef On Jun 2, 2011, at 8:31 PM, GastÃ³n Dall' Oglio wrote: > What about the current state of http://www.squeaksource.com/SimpleWebDoc.html ?

June 2, 2011

Re: [Pharo-project] [squeak-dev] Re: usability of Pharo and Squeak

by Andreas Wacknitz

Am 02.06.2011 um 13:53 schrieb StÃ©phane Ducasse: > and what do you do to change the situation? > I have reported what I have been told after promoting Smalltalk. Alas I neither have the luck to work with Smalltalk on my daily job nor much free time due to my family. I am not able to follow the pace Pharo is developing at. So the best thing I can do is to try to convince people to have a look at Smalltalk. But that is hard. Most developers don't even bother to have a look at it because it's not mainstream (they never heard of it). And if they do, they will complain immediately about not working on files, the user interface (strange widgets, misuse of buttons, missing integration in the host os) and lack of version management. If, in the rare case, someone takes a closer look, he will complain like my friend: annoying window sizes and positions, cluttered windows all over. The new generation of developers is used to use tabbed window IDE's like Eclipse, NetBeans and VisualStudio. Smalltalk systems have to fight against these well supported products. And furthermore I like to emphasis what I wrote before: Squeak's and Pharo's problem is also, that they are seen as tools and not products. Tools are being developed and used for a certain problem to solve. Pharo seems to have two major fields of use: 1. web development (in combination with Seaside) 2. research Of course this is fully ok because it's free and nobody can ask you or other people involved for certain enhancements. But if you want to spread the use of Smalltalk you should hear to voices from the outside. The quality of the code and Smalltalk's elegance and kind of OO are only seen after the first hurdle is being taken. And I count the user interface and the development tools as the first hurdle. In other words: It takes time to convince people that Smalltalk's way of doing things has big advantages over C# or Java. But most people don't give us the time... Regards, Andreas

June 2, 2011

[Pharo-project] SimpleWebDoc

by GastÃ³n Dall' Oglio

What about the current state of http://www.squeaksource.com/SimpleWebDoc.html ?

June 2, 2011

Re: [Pharo-project] Scratch on Pharo

by Mariano Martinez Peck

wow. AWESOME. On Thu, Jun 2, 2011 at 7:44 PM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > It's an extremely nice move to keep the babies at home > > http://smalltalk.cat/blog/Scat+-+Communiqu%E9 > > Hilaire > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > > -- Mariano http://marianopeck.wordpress.com

June 2, 2011

[Pharo-project] Scratch on Pharo

by Hilaire Fernandes

It's an extremely nice move to keep the babies at home http://smalltalk.cat/blog/Scat+-+Communiqu%E9 Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

June 2, 2011

Re: [Pharo-project] [dev] TilingWM - layout policies

by Patrick Barroca

Hello, I've published a version in the repo : Filename: TWM-PatrickBarroca.45.mcz Author: Timestamp: 2 June 2011 7:10:11 pm UUID: 9af76406-16a9-42a3-aa54-8931a8934f99 Ancestors: TWM-LaurentLaffont.44.mcz Message: Added human readable names to layout strategies Downloads: Web: 1 On Tue, May 31, 2011 at 10:58 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > Thanks to Stefan, Serge, Patrick and Estelle now you can choose a Layout Strategy in settings. > Actually there's Horizontal (default) and Vertical (last used windows fills all remaining space) strategies. > To add your own just subclass TWMLayoutStrategy and implement #tileWindows: > Cheers, > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st -- Patrick Barroca

June 2, 2011

Re: [Pharo-project] [squeak-dev] Re: usability of Pharo and Squeak

by Dale Henrichs

Andreas, You are not alone. I too suffer from tooManyWindowsItis ... I am also doing something about it:) The project is in it's very early stages ... I'm drawing on kraft paper with fat crayons ... but I am encouraged by the results so far. The system is called tODE "the Object (centric) Development Environment" and is written in Seaside, so it is javascript/web browser based. I am developing the system in Pharo, but it is targeted as the next generation development environment for GLASS. I've enclosed a screenshot ... the system uses a single tab in the web-browser, but provides it's own www-style navigation through the Smalltalk object-space (so it is a browser inside of a browser) ... each of the tODE tabs is a view on an object and each object is wrapped by a TOObjectFrame that holds onto the tODE-specific state ... links take you to other objects ... you type Smalltalk-expressions in the input area at the top (and in the workspace tab)... I'm not a javascript guy (which is where the fat crayons come into play:)...You can inspect stacks in a "debugger", I've started work on the Metacello tab....etc. With only one window, you never have to open/close another window!:) and with infinite history (at the bottom) you never lose the ability to go back to a previous object ... The framework is very small: 21 classes in the TOOBject hierarchy and another 20 support classes, but being built on top of Seaside, it can't be called "light weight". It is designed to be easily customizable and extensible through the use of pragmas ... I have just started using the system for development (you got to eat your own dog food), but often have to fall back into Pharo, so the system is really not ready for folks to play with ... yet... I need to solve the debugger issues before I can feel comfortable with letting folks play with it:) Finally, while tODE is written on top of Seaside, I don't think that I'm leveraging Seaside for much more than rendering and javascript generation, which means that tODE could be adapted to other GUI frameworks ...I imagine ... Dale ----- Original Message ----- > After following the discussion for some time, I have the impression > that there are some smalltalkers suffering similar usability > problems like my friend and me and some more or less enjoy the > actual state. > Dolphin 6 Professional introduced IdeaSpace. With that you can have > both - single windows and tabbed windows. > It's up to the user to either open windows outside IdeaSpace as > independent windows or inside IdeaSpace as tabbed windows. > Having the free choice is a good thing. Especially if you don't want > to alienate newcomers that are used to use tabbed windows. I like > this approach. > > I haven't looked at TWM yet due to lack of time. I am hardly able to > read the mail traffic in the evenings. > But I asked my friend to have a look at it. He promised to do so > although it's not suited to Pharo 1.2.1. > As Pharo 1.3 is not yet stable I fear that he might have new problems > in other areas. > > What strikes me during this discussion is that nobody seem to have > the same problem with window sizes and positions. > I don't like RealEstateAgent and I don't think that a revamped one > will solve the problems. At least as long it doesn't provide the > possibility > to set sizes on the fly. No algorithm can guess the requirements of > all users. > I also haven't heard about applications written in Squeak or Pharo > and what about user thereof think about the usability. IMO there is > a lack of > an appropriate framework for dealing with such things. Or is > everybody developing web applications nowadays? > > I have a hard time to promote Smalltalk because of its actual state. > I always tell people about my favorite programming > language, but I also tell them that alas there is no good > implementation of it available. This is sad but true, even if Pharo > and Squeak made > big progress during the last months. Both, Squeak and Pharo, aren't > products but just tools. And that makes a big difference. > The commercial products have characteristics that make them not very > attractive to people not yet involved. Despite Dolphin they all have > dated user interfaces, too. When I try to convince people to have a > look at Dolphin they typically tell me: very nice but it seems to be > dead already. > > Regards, > Andreas >

June 2, 2011

Re: [Pharo-project] [GS/SS Beta] serializing object graphs / ordering graph anchors

by Mariano Martinez Peck

On Thu, Jun 2, 2011 at 12:38 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Before I start a utility myself I want to ask if there is such a tool > already. > > I'm using sixx for object graph serialization. It works quite good but it > has some severe limits. I am interesting in listening which ones apart from performance/speed. > Well, the limits are not really sixx dependent but a problem of usual > serializers. My problem is the size of the stack such a tool generates. The stack is a problem??? By stack you mean stack of MethodContexts ? why do you say a "usual" problem of serializers? do you mean because of the fact the the graph is usually traversed with a recursion? Especially in gemstone this appears to be a problem because the stack is > limited per gem. > > In which sense the stack is limited? > If I look at the serializers I know the mechanics are simple: > > 1. take an object and look it up in a table. > 2. if the object is in the table it has already been serialized. We take a > reference from the table and write it down > 3. if it isn't in the table it means the object has not been serialized and > the contents need to be written. After that the object with a reference > representation is written to the table > 4. while writing the content of an object (inst vars) I encounter simple > objects (direct string representation) or complex objects (composite). In > the latter case we start over from 1. > > If the object graph is well interconnected than the odds are high that a > stack will grow high until the first reference can be written. With a small > pier kernel I already matched a stack size of 1000. > > In Fuel we traverse the graph but instead of using a recursion we use our own simple stack implementation where we push and pop objects. But Martin may explaint better than me. > One solution I can think of is to collect and order objects in the graph > that cover smaller segments from the overall graph. This way I would > construct a sorted collection that is sorted by stack depth (lowest first). > The collection will then be serialized leading to a much smaller possible > stack sizes. It might be there are cases it can't work but I think for most > cases it will do its job. And it will be slow of course. > > Does anybody know if such a tool exists? > > Norbert > > > -- Mariano http://marianopeck.wordpress.com

June 2, 2011

Re: [Pharo-project] usability of Pharo and Squeak

by laurent laffont

On Thu, Jun 2, 2011 at 5:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Jun 2, 2011, at 4:47 PM, laurent laffont wrote: > > > For me Emacs is the best development environment, this is the vision that > push me to do TWM. > > I hope that we can do better.... and that this one is not invented yet. > > sure :) Laurent. > Stef > > >

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Norbert Hartl

Am 02.06.2011 um 15:00 schrieb Igor Stasenko: > Btw, what deserializer does, if it discovers that instance of some > class, which you want to bring to life from storage > now has its format changed? > suppose that when saving graph, some class has inst vars 'a b c' > but then you changed the class definition and its inst vars now 'a d e' > ? > > I think it is not a responsibility of serializer to deal with that > (there should be a higher level layer which can handle instance > migration), > while serializer just reports an error that it can't reify an object > because its original class are either gone or changed format. > I think the throwing of an error you need anyway in case something goes wrong. But I would welcome a support in the serializer to plug in a class shape changer. Most of the time I do format changes I know exactly what to convert and so it might be a good option to desribe it together in one object. This object would be different for every oldversion-newversion tuple. In gemstone it is different because there are class versions. Each class can have a migrateTo: method that deals with it. Norbert > On 2 June 2011 14:51, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck: >> >> Thanks Norbert. Now I could successfully run benchmarks for SIXX and compare >> with Fuel. But that's not really fare because we are comparing a text based >> serializer against a binary one. >> >> It is interesting anyway. I like to know if it is 20 times faster or even >> more. On the other hand it is not fair either. I don't know fuel but I think >> it platform dependent, right? So it is not fair the other way round because >> you compare a cross-platform serializer with a platform-dependent one ;) I >> think these are the categories that people think about when the are about to >> choose what util to use. >> Norbert >> >> Mariano >> >> On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: >>> >>>>> serialize: anObject on: aStream >>> | sws | >>> sws := SixxWriteStream on: aStream. >>> sws nextPut: anObject. >>> sws close. >>> >>> serialize: anObject on: aStream >>> anObject sixxOn: aStream >>> >>>>> materializeFrom: aStream >>> | srs objects | >>> srs := SixxReadStream on: aStream. >>> objects := srs contents. >>> srs close. >>> ^ objects >>> >>> materializeFrom: aStream >>> ^ Object readSixxFrom: aStream >>> Norbert >>> >>> >>> >>> Is that correct or I am doing it wrong? All I want to do is to serialize >>> a graph into a stream. >>> >>> The stream I am using is or this: >>> >>> (FileDirectory default forceNewFileNamed: 'Bench') >>> >>> or >>> >>> (RWBinaryOrTextStream on: '') >>> >>> >>> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I mean, >>> sometimes anObject is a collection and sometimes it is not. So, which one >>> should I use? >>> >>> Thanks >>> >>> Mariano >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

June 2, 2011