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

Re: [Pharo-project] Can't file in *.st exports

by Peter Hugosson-Miller

Pardon me for being blunt, Robert, but we're going to need a bit more to go on than "some sort of weird system error". Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois <watchlala(a)hotmail.com> wrote: > There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to "CR" for a debugger or any key to restart. I ended up having to force quit. > > This is in the latest 1.1 one-click. > > Thanks, > RS > _______________________________________________ > 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

[Pharo-project] Wiki spam experience

by Schwab,Wilhelm K

Hello all, Are there any tricks to running a wiki and not ending up a directory of Nigerian ecomomic scams and pornography? Is moderation the only way to do it, or can it be more automatic? Bill

Aug. 19, 2010

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

by Tudor Girba

I took a quick look, and it looks quite nice! Here is a bit of feedback: - I would prefer to have the menus for manipulating entities directly on the canvas, and not in the panes below - It looks like the last character from the name of the class gets trimmed - sometimes the last character from the names of the methods appears on the next row - When trying to create a box from existing class, I get DNU when the class does not exist. Here I would expect to have the option of selecting this class from a list, not to know it upfront - I would prefer another notation for interfaces vs. classes. Right now you have two borders on top of each other: solid for those entities that can hold code, and dotted for those that cannot be instantiated. I would prefer to have only one border with different thicknesses or different shades of gray to denote code, and italic text to denote abstractness (for traits and interfaces). I am not sure if it matters, but I have to mention that I tested in on a Pharo 1.1 on a CogVM. Cheers, Doru On 19 Aug 2010, at 16:56, Carla F. Griggio wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Aug. 19, 2010

[Pharo-project] Can't file in *.st exports

by Robert Sirois

There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to "CR" for a debugger or any key to restart. I ended up having to force quit.This is in the latest 1.1 one-click.Thanks,RS

Aug. 19, 2010

[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