- Pharo-dev - lists.pharo.org

[Pharo-project] About danny help :)
by Torsten Bergmann March 5, 2010

March 5, 2010

Stef wrote: >Hi danny > >I would like to integrate your help system in pharo so we will have see how we can proceed. >... >Yes this is good for my ego :))) Hey, hey ... and it is not good for my ego if you keep saying it is danny's help system! Ever looked at the project and code? ;) While I appreciate that Danny wants to contribute to the project I think his changes are not aligned with the original goals, design and ideas. First and most important: I want a simple model for the help system, which I first provided as HelpTopic HelpBook HelpPage after Danny's changes the baseline now looks like this: HelpTopic DynamicHelpPage ClassAPIHelp MethodListHelp PackageAPIHelpBook HelpBook HelpPage I have several problems with these three introduced classes: - They do not stand the "is a" inheritance test since a book (PackageAPIHelpBook) now "is a" page (DynamicHelpPage) - To make it even worse the class DynamicHelpPage adds three new instance variables (using blocks) totally ignoring the ivars inherited from HelpTopic (leaving unused slots in the instances). - the three new classes are more intended towards extracting/building the three types of dynamic help informations (package, class, method), So the behavior is more oriented towards "building" a book or page - but this is what the (yet unfished) builders are used for. Therefore the classes are also misplaced. - there is no single test provided Sorry Danny - but your changes look more like a quick way on getting a dynamic help "hacked in" than a clean design towards a stable Pharo help system! However - I'm in the midst of refactoring all this and hope to provide an even simpler model than the one I originally used. Please be a little bit patient before we all jump into this "feature adding thing". Stef/Danny wrote: >>I would like to add it in a modular way. Does anybody has a nice idea? >I am not sure what you mean by modular. It has a Metacello configuration. Yes, it has a Metacello configuration which currently separates the test from the Core model/UI. My further work will provide an exchangable and more enhanced UI and no dependency on the Help system itself (at least for in image docu). I'm currently testing some ideas. >my point is if you imagine that we want a small system with good packages >where do we put the helpSystem. I intend to use pragmas to decouple this. So you could comment your code without having the help system installed. We have to make a clean distinction for the help system for: - in image documentation on classes/methods/packages/test cases that can also be accessed by the usual tools like browsers - big-picture like help (books, tutorials) I know you are all eager to play with the first in the help system but I think the second has more value and need for a help system. >A nice idea on squeak-dev was to add support for a simple structured markup >language like Markdown in class comments. We could use this to write "big- >picture" documentation directly in a class comment. Yes ... but a class comment is as the name implies just a comment for a class. You typically dont write a "big-picture" documentation in a class comment. If you write a documentation on how to use Streams, Collections or Exception Handling ... which is the class you would use for the comment? Dont get me wrong: I like well described classes but the Help system should mainly address the "big-picture" documentation for tools, frameworks, the system, ... Adding other types like the dynamic API help are easy to integrate/generate. Another goal is to use the HelpSystem to document a (commercial) software you have written in Pharo or reuse the content for a documentation appearing on a website. Danny wrote: >In a package you put in the most important class a comment that looks somehow >like this: How do you measure the importance of a class ... ? ;) Stef wrote: >we can load HelpSystem and use it but since we want to have core >we should get it in Pharo but still make sure that everything in Core is adapted to give info >to Pharo. Two simple goals: - help is always optional and core could be without it - infos provided should not be dependent on the help system itself (for comments) >In addition I would like to have a tag for promoting test to be list in the help. ><documentation> > >Would be nice. Yes, there are many things that would be nice like generating books/pages from tests or examples or even dynamically build UML diagrams. We can have that in future. But first we need a simple and good model we can built on and I'm working on it. Maybe I released too early ... Thanks T. -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

2 1

[Pharo-project] [update 1.1] #11246
by Marcus Denker March 5, 2010

March 5, 2010

11246 ----- Issue 1336: Stack should be re-implemented Issue 1346: Clean up sort: and sortBy: (step 1: add TSortable) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [update 1.1] #11245
by Marcus Denker March 5, 2010

March 5, 2010

11245 ----- Issue 2104: remove several unimplemented calls Issue 2113: asSortedArray -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [1.1] Object>>initialExtent
by Alexandre Bergel March 5, 2010

March 5, 2010

Hi! I do not have a solution, but Object>>initialExtent was recently deprecated and this causes great usability problem. This deprecation is very valuable for a clean UI separation. However, I have a warning deprecation each time a window is open. The reason stems from the method: SystemWindow>>initialExtent ^ model initialExtent For now, in my image, I suppressed this deprecation. Again, I do not have a clean solution. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 4

[Pharo-project] Add Alien in 1.1 (Issue 1360)
by Schmidt, Marco March 5, 2010

March 5, 2010

I have updated issue 1360 with a zip file containing my current build. The zip-File was too large for the mailing list... Marco Schmidt

1 0

[Pharo-project] AlienPlugin
by StÃ©phane Ducasse March 5, 2010

March 5, 2010

Excellent marco!!!!! This is an excellent news! Stef Begin forwarded message: > From: "Schmidt, Marco" <Marco.Schmidt(a)eads.com> > Date: March 5, 2010 11:06:10 AM GMT+01:00 > To: <Pharo-project(a)lists.gforge.inria.fr> > Subject: Test Alien on Win32... > > > Finally I had time to give AlienPlugin another try under Win32. Here it is. At the moment Iâm testing and building an interface to libcurl. > My work is based on the current vm-source (Andreas Raab, version 3.11.5) with some modifications harvested from the newspeak-source code. I have a local git-repository with all patches needed ready to review and integrate. Should we use github to mirror the squeakvm-repo? > > Marco Schmidt

1 0

[Pharo-project] About danny help :)
by StÃ©phane Ducasse March 5, 2010

March 5, 2010

Hi danny I would like to integrate your help system in pharo so we will have see how we can proceed. I would like to add it in a modular way. Does anybody has a nice idea? Now I would really like to see how we can produce some help automatically like by tagging and commenting some cool SUnit tests. At least we should have it in pharo-dev. Stef

2 6

[Pharo-project] Developing morphic apps with pharo - sorting wheat from chaff
by Michael Forster March 5, 2010

March 5, 2010

Hi, I'm writing a desktop business application for a customer. Having written a number of web applications using Pharo and Seaside, I would like to use Pharo and Morphic in this case. I have read the section on Morphic in `Pharo by Example', however, writing a business application (i.e. CRUD), I need to focus on (tedious) data browsing and entry, keyboard navigation, and so on as opposed to (cool) interactive morphs. My problem is trying to discern the the current and most stable approach to using Morphic for such an application. Clearly, I have a wealth of code at my fingertips and the Squeak wiki has numerous posts, but many of the latter seem outdated and speak only vaguely of the MVC vs. Morphic situation. Do I use ToolBuilder? Are pluggable morphs a vestige of MVC? Do I use PolyMorph widgets? Do I use dependencies, events, or announcements? I am very interested in seeing Pharo succeed as a business application development tool (among other uses), and I would be quite happy to contribute to code and documentation to help that along. However, first, I need to learn how to sort the wheat of Morphic from the chaff of MVC and whatever else is lying around in a Pharo image. Any pointers to (more) definitive documentation and classes would be much appreciated. Regards, Mike -- Michael J. Forster <mike(a)sharedlogic.ca>

6 7

[Pharo-project] O2 does not run on PharoCore 1.1
by Alexandre Bergel March 4, 2010

March 4, 2010

Unfortunately, I spotted some important bugs. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Re: [Pharo-project] about code formatting in pharo
by Dale Henrichs March 4, 2010

March 4, 2010

It is obvious that a consensus will not be reached on the "one and only true format." If my browser displays code formatted the way I want to see it and the difference tools are format neutral (i.e., the source and target code is formatted using the same rules) there is no need to agree on a standard style. For all intents and purposes each developer's favored format _is the standard_. We only need to agree to disagree and then figure out how to make it possible to customize the formatter and resolve any other technical details (performance and others) that are deemed important. These are technical problems with technical solutions. Dale ----- "Chris Muller" <asqueaker(a)gmail.com> wrote: | > Another visual problem with "[" and "]" is that they are but one | > character, and if you place them together with something else, like | > "[self", they lose their visual identity (btw, we read words in | chunks | > not by characters) and get harder to spot. It's true that some fonts | > and extra coloring could solve this problem, but whitespace is | always | > the best and least invasive design weapon. | | Tudor, for what its worth, the white-space surrounding the blocks is | not really at issue or discussion here. It's about formatting blocked | code into rectangular shapes. | | In fact, I agree with you about your point about the whitespace. IOW, | I prefer: | | someVar = someValue | ifTrue: [ self doOneThing ] | ifFalse: | [ self | doOtherThing ; | doYetAnotherThing. | anotherObject doSomething ] | | Not: | | someVar = someValue | ifTrue: [self doOneThing] | ifFalse: | [self | doOtherThing ; | doYetAnotherThing. | anotherObject doSomething] | | Perhaps if you looked at a longer method example, with nested blocks, | you might be able to "see", visually, the blocks more obviously. | Perhaps not, I don't know. | | Regards, | Chris | | > The lines are clearly belonging together, [ is clearly observed and | > clicking anywhere on the first line after [ will select the whole | block. | > | > Yet another thing it solves is the consistency between block and | > method. They both define behavior, and thus Â it would be great if | they | > would be treated similarly. This is better seen in the context of a | > block with parameter: | > | > aCollection do: [ :each | | > Â Â Â Â Â Â Â Â self something. | > Â Â Â Â Â Â Â Â self somethingElse. ] | > | > Just like a method has the top line with the signature and the | > parameters, a block should be the same. In this case, each is a | > parameter and it is clearly distinct from everything else. When | there | > is no parameter, this is information made very clear, too (because | of | > the absence of anything following [ ). | > | > | > An argument against this convention was that it looks like C and | that | > blocks are not dumb {. While I understand the built-in adversity, we | > are talking about a visual notation that makes sense for Smalltalk | and | > not one that make it different from everything else around us. | > | > Another option would be to have: | > boolean ifTrue: | > Â Â Â Â [ Â Â Â self clearCaches. | > Â Â Â Â Â Â Â Â self current soleInstance yada yada blah blah | > Â Â Â Â Â Â Â Â self recomputeAngle ] | > | > with everything inside the block being aligned. However, this has | the | > problem of wasting space. One space can also be used, but only when | > the font is monospaced, so it would not work in general. | Furthermore, | > it would be inconsistent or even more space wasting when it comes to | > blocks with parameters. | > | > Cheers, | > Doru | > | > | > On 4 Mar 2010, at 03:38, Chris Muller wrote: | > | >>>> Â Â ifTrue: [ | >>>> Â Â Â Â line1 yo. | >>>> Â Â Â Â line2 eh ] | >>> | >>> Horrible, horrible, horrible ;) Â Poor block. Â The block is an | >>> object... | >> | >> Exactly what I was thinking; and how some of the new editor | features | >> since 3.9, that seem to reify "statements". Â For example, clicking | >> inside parens or square-brackets selects that statement(s). Â I also | >> really enjoyed the ability to "surround", thereby creating | additional | >> statement-levels. | >> | >> The whole interaction becomes much more liked working with tiled | code | >> rather than a text-editor. | >> | >>> I think the conclusion has to be (and I can confirm that the | >>> VisualWorks | >>> team was equally divided) that no one formatting regime will make | >>> every one | >>> happy and that all regimes will make a substantial minority | >>> unhappy. Â So | >>> perhaps we should step up to having code formatted automatically | >>> according | >>> to tailorable preferences. | >> | >> | >> | >>> My only concern is comment formatting but the way to deal with | that | >>> is to | >>> use automatic formatting and deal with comment problems as they | >>> arise. Â I | >>> always used to be concerned about e.g. comments spanning multiple | >>> lines. | >>> Â But without day to day exposure I don't think one can know how | >>> much of an | >>> issue it is. | >> | >> As someone who's logged 5-digits of hours in Squeak these last few | >> years, I think the best thing is to just not. Â Let 'em wrap! Â Use | >> shout to turn them light gray, so they don't really intrude on the | >> code, but are there if you want focus on the extra prose. | >> | >> Unfortunately, the real problem with comments within BlockNodes is | how | >> they duplicate themselves within the parse-tree.. ouch! Â I hope | that | >> is what you and Nicolas were talking about or that you'll have a | fix | >> for that.. | >> | >>> One upside will be less effort reformatting when indent levels | >>> change. Â Have | >>> you noticed that Smalltalk tends to be more difficult to reformat | >>> than C | >>> syntax languages, I guess because of keywords? Â Not having to | worry | >>> about | >>> this could be great. | >> | >> Very cool, I hope there'll be enough additional consensus to adopt | >> these Beckian formats for Squeaks pretty-print refinement. | >> | >>> Of course, what format gets written to a source file could still | be | >>> a source | >>> of conflict ;) Â We may all want our syntax to be the Â format of | >>> record :) | >> | >> Absolutely. Â To not, would be the machine dictating to the user. | >> Invoking automatic formatting is always the users choice. | >> browseWithPrettyPrint allows readers to have it formatted | dynamically | >> if they wish.. | >> | >> Cheers.. | >> | >>> P.S. Â and don't get me started on the trailing period (putrid | >>> excressence), | >>> or the space between ^ and the return expression (vomitous mass). | >> | >> _______________________________________________ | >> 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 | > | > "Live like you mean it." | > | > | > _______________________________________________ | > 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

6 7