- Pharo-dev - lists.pharo.org

[Pharo-project] Introducing smallUML: a little project to help us document :)

by Carla F. Griggio

Hi everyone! Well, here I am announcing the resulting project of my GSoC experience during the [your] summer: smallUML, a project to help us building diagrams and sharing them with any package of code. My mentor was Stephane Ducasse and my co-mentor Geert Claes, so thanks to them for the guidance up to now, and also to Fernando Olivero who helped me a lot (hope to do some coding with you at ESUG! :P). You can gofer it: Gofer it > squeaksource: 'smallUML'; > package: 'ConfigurationOfSmallUML'; > load. > (Smalltalk at: #ConfigurationOfSmallUML) project latestVersion load. > And then open the Diagram Browser of the current little examples evaluating: DiagramDrawingDocumentation openDiagramBrowser . > This is beta and I'm still working on it, my work will continue after GSoC's deadline, so of course your welcome to give some feedback and think about what features would you like it to have and if you're confortable with the current features. It would be really nice if this helped to get all Pharo projects more documented, with visual diagrams that help understanding them at a glance. Talking about that... the current features are: - Open a *Diagram Browser* for an existing Category Diagrams Holder (this is a class ment to hold the created diagrams and there should be one per category, for now; you can browse DiagramDrawingDocumentation to see an example) - *Create and edit diagrams* programatically describing them with "diagram code" (the diagram code it's just a protocol of methods meant to describe diagrams, you can see some diagram code browsing DiagramDrawingDocumentation methods or each Class Box in the Diagram Browser) - Every diagram you build through the Diagram Browser it's saved as "diagram code", so you can *share it as code* that will reproduce your diagram :) That means that diagrams can 'travel' along it's package when you commit your changes with Monticello! And then they can be edited by anybody, they're not just a pretty picture. - You can *export* your diagram as a *PNG* picture or you can export it's "diagram code" as a *workspace*. - Only *Class Diagrams* can be built for now. - Class Boxes of a class diagram can be *dragged* to be easily positioned. Some details that are missing: - It's funny, but I can't center the class boxes title! :P - I tried adding some scrollbars to the "whiteboard" where you can view your diagrams in the Diagram Browser, but if I did that the drag & drop of the class boxes worked funny :( I'll ask about that to you later. On the way: - Tests and documentation, and a screencast showing every feature. - Lots of refactors: as I'm adding more kind of diagrams right now, so I'm doing a lot of refactors to make everything more flexible and improving all the messy code there. - A version of Minimal Connectors for anybody to use if they feel like connecting morphs for another project. - Some usability improvements. - Object diagrams - Sequence diagrams - Your feedback :D So I'd really appreciate if you can give it a try and tell me how you feel about it, I'd like it to be very usable. Cheers! Carla

Aug. 19, 2010

Re: [Pharo-project] FW: [Seaside] Changes file too big

by Robert Sirois

I can't be responsible for all my code ;) What is the solution by the way? My changes file is up from 9mb last night to 31.5 just this morning already... RS Date: Thu, 19 Aug 2010 16:01:13 +0200 From: marianopeck(a)gmail.com To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big 2010/8/19 Marcus Denker <marcus.denker(a)inria.fr> From: Robert Sirois <watchlala(a)hotmail.com> Date: August 19, 2010 3:17:56 PM GMT+02:00 To: <pharo-project(a)lists.gforge.inria.fr> Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big Mmk, thank you. Pharo: pharo1.0-10505-rc1dev10.01.2.image VM: Squeak 4.2.2beta1U The log file is attached. mmmm wierd...are you tryiing to create a class called serhgresh ? it should be uppercase... Serhgresh On Aug 19, 2010, at 3:09 PM, StÃ©phane Ducasse wrote: > on which os are you? > Normally there is a log file just close to your vm or image. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ 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

Aug. 19, 2010

Re: [Pharo-project] Senders of #haltOnce

by Henrik Johansen

On Aug 19, 2010, at 4:05 52PM, Carla F. Griggio wrote: > Yes, but even the haltOnce? They're really annoying, I noticed them too. > > Maybe we should comment on that bug ticket everytime we notice them. No, those are debugging artifacts accidentally left in :/ In my defense, 50% of them were in code hastily copy-pasted to the list as example code, not submitted as a package :) Cheers, Henry

Aug. 19, 2010

Re: [Pharo-project] Senders of #haltOnce

by Carla F. Griggio

Yes, but even the haltOnce? They're really annoying, I noticed them too. Maybe we should comment on that bug ticket everytime we notice them. On Thu, Aug 19, 2010 at 10:08 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > A time ago I noticed them. And I realized most of them were used to > notify error conditions instead of using just #error:. Each halt must > be analyzed independently :/ > > On Thu, Aug 19, 2010 at 9:02 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I > > was using this functionality to debug my own code. I submitted a fix: > > > > http://code.google.com/p/pharo/issues/detail?id=2833 > > > > Also I discovered countless senders of #halt and friends in library > > code and tests. This is really bad for continuous integration and for > > deploying images, because they open debuggers. All these senders > > should be changed to throw an error or fail the test in some > > controllable fashion. > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > _______________________________________________ > > 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 >

Aug. 19, 2010

Re: [Pharo-project] Senders of #haltOnce

by Carla F. Griggio

Yes, but even the haltOnce? They're really annoying, I noticed them too. Maybe we should comment on that bug ticket everytime we notice them. On Thu, Aug 19, 2010 at 10:08 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > A time ago I noticed them. And I realized most of them were used to > notify error conditions instead of using just #error:. Each halt must > be analyzed independently :/ > > On Thu, Aug 19, 2010 at 9:02 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I > > was using this functionality to debug my own code. I submitted a fix: > > > > http://code.google.com/p/pharo/issues/detail?id=2833 > > > > Also I discovered countless senders of #halt and friends in library > > code and tests. This is really bad for continuous integration and for > > deploying images, because they open debuggers. All these senders > > should be changed to throw an error or fail the test in some > > controllable fashion. > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > _______________________________________________ > > 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 >

Aug. 19, 2010

Re: [Pharo-project] FW: [Seaside] Changes file too big

by Mariano Martinez Peck

2010/8/19 Marcus Denker <marcus.denker(a)inria.fr> > > > > From: Robert Sirois <watchlala(a)hotmail.com> > Date: August 19, 2010 3:17:56 PM GMT+02:00 > To: <pharo-project(a)lists.gforge.inria.fr> > Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big > > > Mmk, thank you. > > Pharo: pharo1.0-10505-rc1dev10.01.2.image > VM: Squeak 4.2.2beta1U > > The log file is attached. > > > mmmm wierd...are you tryiing to create a class called serhgresh ? it should be uppercase... Serhgresh > > > > On Aug 19, 2010, at 3:09 PM, StÃ©phane Ducasse wrote: > > > on which os are you? > > Normally there is a log file just close to your vm or image. > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 19, 2010

Re: [Pharo-project] FW: [Seaside] Changes file too big

by Marcus Denker

From: Robert Sirois <watchlala(a)hotmail.com> Date: August 19, 2010 3:17:56 PM GMT+02:00 To: <pharo-project(a)lists.gforge.inria.fr> Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big Mmk, thank you. Pharo: pharo1.0-10505-rc1dev10.01.2.image VM: Squeak 4.2.2beta1U The log file is attached. On Aug 19, 2010, at 3:09 PM, StÃ©phane Ducasse wrote: > on which os are you? > Normally there is a log file just close to your vm or image. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 19, 2010

Re: [Pharo-project] Probably a bug

by Henrik Johansen

On Aug 19, 2010, at 3:09 42PM, GÃ¶ran Krampe wrote: > On 08/19/2010 02:03 PM, Henrik Johansen wrote: >> What would you say the right thing is? > > Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using "asString" would give me a String of size 5. Also, "Character space asString" does NOT give me 'Character space' but actually ' '. Maybe its just me, but I'd rather not have SequenceableCollection >> asString mean "If I contain only elements which may represent characters, return a string containing those, if not, return my printString" > > Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String > regards, GÃ¶ran And it is, using either collection as: String, or String withAll: collection In both cases you then explicitly specify that this collection will contain only elements which can be converted to a string, rather than have a later reader of the code have to question "hmmm, does the use of asString here mean he'll be using the collections printString, or the string with its elements?" Cheers, Henry

Aug. 19, 2010

Re: [Pharo-project] SocketStream enh

by StÃ©phane Ducasse

Tx I will forward that to squeakers because they may be interested too. On Aug 19, 2010, at 3:04 PM, LUIS E QUIJANO wrote: > Stef, > > I have been testing your SocketStream code. So far so good. > > I noticed that if accidentally a SmallInteger versus a CharacterOrByte parameter is used in the method SocketStream>>upTo:, the environment goes into a degraded state that persists until the original instance of SocketStream gets closed. For example, no more new Socket connects. After closing the original instance of SocketStream, the environment "seems" to be back to "normal". A simple example for reproducing the "bad parameter" situation is below. > > Hope this helps, > > Luis > -=-=- > Luis Quijano > quijano(a)panasoft.com > -=-=- > | hostName portNumber hostIP ss data | > hostName := '10.10.10.100'. > portNumber := 10001. > hostIP := NetNameResolver addressForName: hostName timeout: 20. > ss := SocketStream openConnectionToHost: hostIP port: portNumber. > Transcript > show: '---------- Connecting ----------'; cr; > show: 'hostName = ' , hostName; cr; > show: 'hostIP = ' , hostIP printString; cr; > show: 'portNumber = ' , portNumber printString; > cr. > "data := ss upTo: (Character value: 68)." "Good parameter" > data := ss upTo: 68. "Bad parameter" > Transcript > show: 'Data received: '; > show: data; > cr. > ss close. > Transcript > show: '---------- Connection Closed ----------'; > cr. > data inspect. > ===== > At 11:43 AM 8/8/2010, you wrote: >> Hi lukas and others.... >> >> I will integrate the following SocketStream tests and before I would love to see if this >> does not impact seaside >> >> http://code.google.com/p/pharo/issues/detail?id=2767 >> >> 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

Aug. 19, 2010

Re: [Pharo-project] FW: [Seaside] Changes file too big

by Mariano Martinez Peck

On Thu, Aug 19, 2010 at 3:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > on which os are you? > Normally there is a log file just close to your vm or image. > > It is in the same directory where your image is and it is called PharoDebug.log but it is opened as append...thus all erros go there. To report an issue is better to remove it, reproduce again the bug and then you will have a clean PharoDebug.log with only that error. cheers mariano > > On Aug 19, 2010, at 3:03 PM, Robert Sirois wrote: > > > How do I get the log? > > > > RS > > > > Date: Wed, 18 Aug 2010 23:00:40 +0200 > > From: marianopeck(a)gmail.com > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big > > > > With condenseCHanges we used to have the problem with "Invalid UTF input > dected" (or something like that), but I don't know a possition error. > Provide, VM and image version, and a clean PharoDebug.log. > > > > cheers > > > > mariano > > > > On Wed, Aug 18, 2010 at 10:58 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Oops. > > Robert can you tell us which version you are using? > > > > Stef > > > > > How do I clear my changes file? Smalltalk condenseChanges. just brings > up a PositionalStream error. > > > > > > Thanks, RS > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 19, 2010