- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] ToolBuilder / Pharo 1.0 changes
by Igor Stasenko April 23, 2010

April 23, 2010

On 23 April 2010 13:57, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > Ok let us know. > > Your goal is to have ToolBuilder shared between Pharo and Squeak? > We should pay attention because we want to be able not to be backwards compatible but we can try. > Well, i think that if we keep this part shared, then developers will have at least a basis for building their UIs and do not bother with using different ports, if they want to support Pharo and Squeak both in their projects. > Stef > > On Apr 23, 2010, at 6:50 AM, Andreas Raab wrote: > >> Hi - >> >> Here are the changes between the latest ToolBuilder from http://www.squeaksource.com/ToolBuilder vs. Pharo 1.0 (again there are additional but fairly minor edits involved): >> >> Package ToolBuilder-Kernel >> -------------------------- >> - ToolBuilderTests >> Removed. >> >> - UIManager >> Â * fontFromUser: >> Â -- >> Â * chooseFrom:lines:message: >> Â * chooseFrom:lines:message:title: >> Â * chooseFrom:message: >> Â * chooseFrom:message:title: >> Â * chooseFrom:values:lines:message: >> Â * chooseFrom:values:lines:message:title: >> Â * chooseFrom:values:message: >> Â * chooseFrom:values:message:title: >> Â -- >> Â * createPageTestWorkspace >> Â * checkForNewDisplaySize >> Â * composeFormFor: >> Â * grafPort >> Â * interactiveParserFor: >> Â * newDisplayDepthNoRestore: >> Â * onDebug:context:title:full: >> Â * onPrimitiveError: >> Â * onEventSensorStartup: >> Â * onSnapshot >> Â * restoreDisplay >> Â * restoreDisplayAfter: >> >> Two sets of issues that we should discuss: If you care about unloading the (very small) set of tests we should move those into a separate package, which is easy enough. >> >> Secondly, UIManager. It seems there have been three types of additions: >> >> 1) 'Genuine' user requests like fontFromUser:. Since we added a similar protocol in Squeak we should work out which protocol is preferable and use it (or even both). >> >> 2) Polymorph extensions. Assuming Gary agrees, we should move those into UIManager but I'll point out that a quick look at senders didn't reveal any users? All the references were between these methods no apparent external callers. Are these used in other packages? >> >> 3) Methods that are not about user requests (everything from creatPageTestWorkspace through restoreDisplayAfter:). I don't really like those very much (after all UIManager is all about asking users for information); is there really no better place in Pharo to put these? I can kind of see why one would stick some of those into UIManager if there is absolutely no other place but ... is there? >> >> Package ToolBuilder-Morphic >> --------------------------- >> - MorphicToolBuilderTests >> Removed. >> >> - MorphicUIManager >> Â * isActiveManager - presumes Morphic-only >> Â * (all the code for the new methods in UIManager) >> >> Not much new stuff here. >> >> Package Polymorph-ToolBuilder-Morphic >> ------------------------------------- >> * PSPluggableListSpec >> Adds icon and double click selector to the list spec. >> >> This should be folded all the way up into PluggableListSpec. The lack of these is a real oversight. >> >> That's about it for the Pharo changes. Except from the methods in UIManager that don't really belong there, there's little to worry about. >> >> The next thing I'll do is post some recommendations of how I think we can move this forward. I'll have to think about this a little though. >> >> Cheers, >> Â - Andreas >> > > > -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] New company selling Smalltalk products
by Nicolas Petton April 23, 2010

April 23, 2010

Hi, SÃ©bastien Audier and I recently started a company named ObjectFusion selling Smalltalk web applications, using Iliad web framework. Our first product, Odyssey CMS, is a web content managment system. The system is available in english and french. It is designed to be extensible, flexible and easy to use. Instead of using a formatting syntax or a WYSIWYG text editor, our CMS is using inline editing, inspired by CMSBox. Every part of the page can be arranged and edited in place, and is automatically adapted to the design of the website. Odyssey also features mutliple undo/redo for all actions on a page. Any mistake can be cancelled at any time. When editing a page, it is also possible to copy/cut/paste any part. We offer several plans & pricing with commercial hosting. If you want to learn more about services we offer, you can visit our website (in french) : http://www.objectfusion.fr Cheers, Nicolas Petton

4 3

[Pharo-project] Fix 2344 - OmniBrowser using depreciated asSortedArray
by Sean P. DeNigris April 23, 2010

April 23, 2010

In inbox. http://code.google.com/p/pharo/issues/detail?id=2344 Sean DeNigris -- View this message in context: http://forum.world.st/Fix-2344-OmniBrowser-using-depreciated-asSortedArray-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] ToolBuilder / Pharo 1.0 changes
by Andreas Raab April 23, 2010

April 23, 2010

Hi - Here are the changes between the latest ToolBuilder from http://www.squeaksource.com/ToolBuilder vs. Pharo 1.0 (again there are additional but fairly minor edits involved): Package ToolBuilder-Kernel -------------------------- - ToolBuilderTests Removed. - UIManager * fontFromUser: -- * chooseFrom:lines:message: * chooseFrom:lines:message:title: * chooseFrom:message: * chooseFrom:message:title: * chooseFrom:values:lines:message: * chooseFrom:values:lines:message:title: * chooseFrom:values:message: * chooseFrom:values:message:title: -- * createPageTestWorkspace * checkForNewDisplaySize * composeFormFor: * grafPort * interactiveParserFor: * newDisplayDepthNoRestore: * onDebug:context:title:full: * onPrimitiveError: * onEventSensorStartup: * onSnapshot * restoreDisplay * restoreDisplayAfter: Two sets of issues that we should discuss: If you care about unloading the (very small) set of tests we should move those into a separate package, which is easy enough. Secondly, UIManager. It seems there have been three types of additions: 1) 'Genuine' user requests like fontFromUser:. Since we added a similar protocol in Squeak we should work out which protocol is preferable and use it (or even both). 2) Polymorph extensions. Assuming Gary agrees, we should move those into UIManager but I'll point out that a quick look at senders didn't reveal any users? All the references were between these methods no apparent external callers. Are these used in other packages? 3) Methods that are not about user requests (everything from creatPageTestWorkspace through restoreDisplayAfter:). I don't really like those very much (after all UIManager is all about asking users for information); is there really no better place in Pharo to put these? I can kind of see why one would stick some of those into UIManager if there is absolutely no other place but ... is there? Package ToolBuilder-Morphic --------------------------- - MorphicToolBuilderTests Removed. - MorphicUIManager * isActiveManager - presumes Morphic-only * (all the code for the new methods in UIManager) Not much new stuff here. Package Polymorph-ToolBuilder-Morphic ------------------------------------- * PSPluggableListSpec Adds icon and double click selector to the list spec. This should be folded all the way up into PluggableListSpec. The lack of these is a real oversight. That's about it for the Pharo changes. Except from the methods in UIManager that don't really belong there, there's little to worry about. The next thing I'll do is post some recommendations of how I think we can move this forward. I'll have to think about this a little though. Cheers, - Andreas

1 0

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?
by Andreas Raab April 22, 2010

April 22, 2010

On 4/21/2010 4:32 AM, Hannes Hirzel wrote: > A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same? > Or if there is a difference what is the impact of it? > > Or put the question in another way. If I code an UI using the > ToolBuilder in Squeak 4.1 will it run in Pharo? They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested). Cheers, - Andreas

3 7

[Pharo-project] About help
by StÃ©phane Ducasse April 22, 2010

April 22, 2010

Hi pharo Gofer new squeaksource: 'HelpSystem'; version: 'HelpSystem-Core-tbn.35'; load and enjoy HelpBrowser openOn: SystemReference HelpBrowser openOn: (SystemReference forClass: Integer) HelpBrowser openOn: (SystemReference hierarchyFor: Integer) HelpBrowser openOn: (SystemReference hierarchyWithMethodsFor: Integer) with some tweaks it can be realllllly cool. Stef

2 2

[Pharo-project] HelpSystem (was Documentation Team)
by Torsten Bergmann April 22, 2010

April 22, 2010

To clearify a few things from my side on the discussion on squeak-dev: 1. HelpSystem is working, if ASCII is OK for now we can use it Pharo/Squeak - otherwise I would see it as an early preview. I have clear goals how it should look like in the next iterations. For this more patience is necessary. 2. HelpSystem is independent from where and how the actual information is stored (I think I demonstrated this with the IRC example, the books and the API help). 3. I hope to keep HelpSystem in sync for major Squeak distributions (Squeak, Pharo, Cuis, ...) The last additions from Hannes already broke the code in Pharo. Seems to be a Pharo issue this time http://code.google.com/p/pharo/issues/detail?id=2342 But please dont commit when it is only working in Squeak since my development environment is Pharo. 4. Yes, the content is currently ASCII but the design is prepared to add other types in future releases. A HelpTopic defines an ivar "contents" - currently referring to a string. I may add another ivar "contentType" in the future to handle/distinguish additionaly types (HTML, SqueaksRichText, Morphs/BookMorph, ...) 5. HelpSystem should not be limited to Squeak. It should also serve the case that when you write and deploy a commercial app in Squeak you may use it to provide help to your end user/customer 6. There are two types of help I see: A. SystemHelp: Help books/Tutorials/Manuals B. SystemReference: API Help, class comments HelpSystem is supporting both. I already wrote about the differences and details in http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024857.html 7. I would really like to see support for HTML viewing in the image (HTMLViewMorph or so) - maybe based on Scamper to get a better viewer (headings, tables, ...) than the current plain text. If people want to contribute they should start right with this task. I know that Laurent already made Scamper loadable in Pharo, dont know about the state in Squeak. There is also another HTML browser with markup and CSS now available open source as MIT (WithStyle), I already mentioned this. http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true&… 8. I know that we now have discussions on which syntax (Wiki,...) to use for describing the contents. My answer is: it is important but I dont care (yet) since this discussion is useless until we have an HTML viewer (see 7.) and even when there are different syntax styles you can provides builders to transform them into HTML or other contentTypes afterwards. See the class HelpBuilder and subclasses. 9. If you want to write a book for SystemHelp (see 6.A) then the help system provides a class "CustomHelp" similar to TestCase in SUnit. This class is used to directly map book structures to the class hierarchy. The intention was to be able to create, store and manage these books directly with the usual Smalltalk tools. You can even restructure your book with the RefactoringBrowser. 10. If you want to write API help you (see 6.B) can contribute right now by commenting all the undocumented classes in the standard image. HelpSystem just queries these informations from the usual sources (class comments, ...). I would not change this or make it too complicated since this is what people are used too. I dont see more documented classes by introducing a special syntax (wiki or whatever) people have to learn/know about - so lets clean up documenting the classes first. 11. HelpSystem is able to get contents from external sources (see the IRC example) - but I would prefer that authoring/viewing could be done right from within the image. Even when the result is stored external afterwards. Look at my example books: I can view and change them right from the image and make them available to other images using Metacello/Squeaksource. Accessibility of docu (viewing and authoring) is the key to keep the system and docu in sync and up to date. External authoring mostly results in unmaintained docu (see the Squeak Swiki). 12. I thought again if it is ready to integrate into Pharo and Squeak. From all the discussions I would say it is too early. 13. If one wants the docu on the web the answer is easy: we can generate static files or serve them with Seaside. But I have no need for that right now, especially since this is already available in various forms. We can do many things (similar to Python, JavaDoc, you name it) But - let's do it step by step. As I said: - Someone working on a good HTML Viewer that I can integrate would really help moving this forward (based on Scamper or by porting WithStyle) - Updating class comments would also help a lot Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

4 6

[Pharo-project] Automatic generation of abstract methods
by Cyrille Delaunay April 22, 2010

April 22, 2010

Hello, Would it be difficult to generate automatically superclass-abstract methods (with an empty contents) when creating a new subclass? For example, imagine I want to make my own subclass of Collection. As there is a lot of methods in this class and probably abstract methods, it would be cool to see them directly in my subclass without having to look to Collection method one by one (?). I'm probably not the first to ask this question, but in case it is, that's done:)

3 2

Re: [Pharo-project] [Vm-dev] CMake for Windows?
by Geoffroy Couprie April 22, 2010

April 22, 2010

Ping! I know everyone is busy, but could someone test these CMake files? I can't install a VM to build unix Squeak right now, but I'll do it in the future. I just want to know if it's still possible to create unix squeak with these files :) On Sat, Apr 17, 2010 at 1:23 AM, Geoffroy Couprie <geo.couprie(a)gmail.com> wrote: > Hello, > > You'll find my work on the CMake files at > http://eleves.ec-lille.fr/~couprieg/divers/patches.zip > > I put a CMakeLists.txt file just under the platforms/ directory, along > with the cmake/ directory. These files are based on the unix ones. I > modified them to change the source directory depending on the > platform. I also modified the configure file accordingly, but i > commented the code using subversion for my convenience during > development (feel free to change it back). > > These CMake files are not perfect, it's just the beginning. First, I > want to make sure that the unix port still builds with my file, and > then, I'll go on with the config.cmake and build.cmake files for the > plugins, and I'll clean CMakeLists.txt Â a bit. > > Feel free to comment, but note that I'm beginning with CMake, and that > I don't write bash code very often. And please, try it with the unix > port. I don't want to break everything :) > > Anyway, it works for me here (I can build a VM on Windows with the > File, Security, LargeIntegers and MiscPrimitive plugins using > MSYS+MinGW). > > Best regards, > > Geoffroy >

2 1

[Pharo-project] Hints and clues for a Pharo newb
by Peter Hugosson-Miller April 22, 2010

April 22, 2010

Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm working on a small improvement to the testing framework, using ideas that I have found to be very useful in my daily job over the past 15 years. Note that I am doing this from scratch, so that I don't accidentally steal anything that I've done in my work, but I know how it all works in VisualAge, so I feel sure that I'll eventually be able to find the corresponding classes and methods in Pharo. What I would like are a few hints, clues and nudges in the right direction for scenarios and questions that I will describe in this thread. What I *don't* want are full-blown solutions, because then I won't learn anything. I hope that some kind souls will be able to give me a little help in the beginning that will eventually bring me up to speed and let me be productive. So to start with, one scenario and one question: 1) I want to find or write a method on Process that will print a stack trace onto a supplied Stream. Ideally I'd like to be able to decide the start and stop depth of the trace, so for example if I know that the top 4 stack frames will always be uninteresting, I would want to be able to write something like this: Processor activeProcess printStackFrom: 5 to: 15 on: aStream. 2) What *exactly* is "thisContext"? It appears to be a reserved word in Pharo, just like the familiar "self", "super", "true", "false", "nil" that are always reserved in Smalltalk. I'd also like to get an idea of what it's good for, and if anyone can describe it in terms of something that is in VisualAge, that would be nice too :-) BTW, if this is not the appropriate place for a thread like this, then please tell me where I should put it (politely, of course :-p) -- Cheers, Peter

8 9