- Pharo-users - lists.pharo.org

Migrating to Nautilus
by Hilaire Fernandes May 14, 2014

May 14, 2014

Hi, In DrGeo, I add this code snippet to: browser := Browser newOnClass: DrGeoUserScripts selector: mathItem script. browser addDependent: self domain. browser codeTextMorph owner owner extent: 450@350. browser topView setProperty: #morphicLayerNumber toValue: 5. 1. open a minimal browser 2. set a dependency so DrGeo is noticed when the user edited and compile its script (so Drgeo can update the sketch) 3. rescale the browser so the user can still see his sketch 4. set the minimal browser in a permanent top position. As Browser is broken and not gonna be fixed, I need to redo the same with Nautilus, but this one is a big beast. Any tips how to do it? Thansk Hilaire -- Dr. Geo http://drgeo.eu

3 6

Re: [Pharo-users] Problem learning about Magritte
by Stephan Eggermont May 14, 2014

May 14, 2014

Peter wrote >Well, I am carrying on, but I do wonder why Pharo has to be such a rapidly >moving target. There are virtues in stability, and perhaps there should be a >filtering process before any change is made, to ensure that the benefits >outweigh any disruption. I must admit that, at times, Pharo looks like a >playground for a fairly small group of very clever people who are in love >with the process of development. There is virtue in stability as well as in innovation and in cleaning up. Pharo errs on the side of innovation and radical cleaning up. While doing that, we find out how to get better and faster at change. we do that by breaking things and then fixing them, trying to create as fast a feedback loop as possible. Squeak errs on the side of stability, trying to make things unloadable while keeping up compatibility. To work well with Pharo, as soon as possible set up a ci project in the inria infrastructure. That way you know when something gets broken (and the pharo core developers can see when they break something). A lot of the names are explained in Pharo by Example, Deep into Pharo and pharo for the enterprise https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english In the Forum image are also parts of Moose (Glamour, Roassal). FOBrowser open FOTutorial open Stephan

1 0

Re: [Pharo-users] Problem learning about Magritte
by Stephan Eggermont May 14, 2014

May 14, 2014

Peter wrote: >It all looks a maze of >new terminology to me - I don't understand the difference between Monticello >and Metacello, for instance. Both are part of configuration management. Historically, Monticello came first. It supports distributed version control of a single package. Package is a problematic concept in Pharo (and Squeak), as multiple class categories belong to one package. Class category and package are often used as if they are the same. The Magritte-Model package contains all categories starting with 'Magritte-Model', a.o. Magritte-Model-Core. Monticello has support for required packages, but this is better expressed in Metacello. Metacello solves the problem of dealing with multiple platforms, dependencies of packages and different status. Better and longer explanations can be found in the Deep into Pharo book http://www.deepintopharo.com >I am sure to an expert your explanation of how >to check the correct version of Magritte3 is quite straightforward, but I >would never have found my way to that conclusion myself. Yes, that takes time and experience. A smalltalk system is large and finding your way around is not simple. I hope explaining how I find out helps. >As I pointed out to >Esteban, I used the configuration browser on 5 May to get the stable version >of Magritte3. If that was already out of date, I am pretty well lost. There was no test for this, so the build was green :( >Still, I am making progress with my original aim of learning about Magritte, >and there are many helpful people on this group, so you can just regard this >as me blowing off steam after things had not gone completely easily. Good. Just continue telling us where we need to improve. Stephan

1 0

Re: [Pharo-users] Problem learning about Magritte
by Stephan Eggermont May 14, 2014

May 14, 2014

Peter wrote: >is there a method #asMorph which will give the >morphic version as easily, or if not how do I get an editor as a Pharo >window? There is asMagritteMorph yes, defined in Magritte-Morph. You might need to load that additionally (it is loaded in the Forum image). Stephan

3 3

Scaling an Athens surface
by Hilaire Fernandes May 14, 2014

May 14, 2014

I have morph embedded in a AthensWrapMorph, before exporting it to a bitmap, I would like to rescale the AthenSurface. How can I do it at the Athens level to get the best quality. Hilaire -- Dr. Geo http://drgeo.eu

1 0

Gorgeous
by Hilaire Fernandes May 13, 2014

May 13, 2014

DrGeo canvas with Athens looks really nice. Hilaire -- Dr. Geo http://drgeo.eu

2 2

Re: [Pharo-users] Problem learning about Magritte
by Stephan Eggermont May 13, 2014

May 13, 2014

Hi Peter That sounds like you have independently installed Seaside and Magritte. You might miss the part connecting them together. Seaside can be used without Magritte, and Magritte without Seaside. That happens if you just install stable Seaside and stable Magritte from the configuration browser. Can you check if you have Magritte-Seaside loaded? That is in the Seaside group of Magritte. If not, you need the other option in the configuration browser, just loading the configuration of Magritte3. Then in a workspace, do-it (ConfigurationOfMagritte3 project version: #stable) load: 'Seaside'. A faster way to start can be to use one of the images from https://ci.inria.fr/pharo-contribution/ Pier, QCMagritte and Forum all come with both Magritte and Seaside preloaded. Stephan

5 5

Re: [Pharo-users] Domaintalk - PDF Files
by Bob Williams May 13, 2014

May 13, 2014

I received the following comment: My interest is in understanding the utility of such a proposal in enterprise context viz: say in Banking Can Domain driven DSL provide a plausible power user interface for Banking apps driven primarily by UI screens and backend processes. MathsDomain specially may have an appeal in that direction. I responded: My concept of Domaintalk is that it would not be limited to one particular platform, but used on a wide range of platforms; in you example both for the PC, tablet, workstation and mainframe or server, maybe even phones. Its use would be open ended, limited only by the users' imagination. A simple example should suffice to convey my meaning, while not a domain per se, Digitalk's Smalltalk/V used a global dictionary to open up the OS2 and Windows APIs to the programmer, even allowing the user to extend the APIs made available; moreover, all of the OS specific attributes, like handles, were made available. Something that was not available in ObjectWorks and I am not sure is available int Pharo. If domains were added to Pharo, then I am sure someone working on the Pharo internals (VM) could make the OS APIs available and provide a means to add new ones. Such a domain would not even require exposure of the OS attributes of the window because the programmer could simply create their own windows. A word of caution, this would mean that use of that OS specific domain would limit the application to that specific platform; however, that is something that I am willing to live with, in fact, it is something I desire, then I could give the application user the UI that they expect, the one that matches their platform. I can see where a banking application could benefit from the SQL Domain and the Math Domain decimal class and methods, I recall the heavy use of the decimal data and instructions in the IBM mainframes. I can even envision a domain that wrapped the windowing API that made it more usable, so that someone could create another domain that used that domain to add a language that would make window creation easier, either a graphical window builder (similar to the WindowBuilder application of Smalltalk/V) or a scripting type language. The term banking congers up many things to me, of course there is the standard banking account transaction processing, but there also the investment side of the business and other backroom analytical functions. I believe that application for all those diverse requirement could benefit from Domaintalk. For about thirteen year I was the head of computer departments with multimillion dollar IBM MVS mainframes. One thing that I could count on was that when I took over a new department I would find a staff that though that programs always had bugs the they would need to fix. I always seemed that 40% of my programming resources was spend fixing bugs. (Just like the ObamaCare web site.) I established the policy that programmers created bugs, not programs, and implemented step to eliminate all bugs, including having the heads of projects that had bugs meet with me each morning for a very uncomfortable meeting. I took about six months to get the level of bugs down to an acceptable level, about 5%, and mostly in programs scheduled for replacement. So I am well aware of what is required for an enterprise quality application. One reason I want Domaintalk is that, I have observed that, code that is not readable lends itself to errors. Another observation is that when the syntax of a language is stretched beyond its intended use, it become unreadable. I apologize for the lengthy response and I look forward to your response, and answer to the DSL question. BW

1 0

Problem learning about Magritte
by PBK Research May 13, 2014

May 13, 2014

Hello Sorry if this is the wrong place to ask this. I am trying to understand how Magritte works, initially by following the first example in Ch. 26.2 of the Seaside book. I have started with a fresh download of Pharo 3.0, and I have installed Magritte 3 and Seaside 3. I realise that the Seaside book example is based on Magritte 2, so I have made necessary changes to the example code (descriptions are on the instance side, insert <magritteDescription> pragmas, change #description to #magritteDescription). All works well up to the point where I try to generate the Seaside editor. This fails because the code: Address example1 asComponent produces a 'does not understand' message for #asComponent. I have not been able to work through all of Seaside to see where this method is defined, and I am at a bit of a loss. I know this is rather elementary, but could someone give me a pointer? Also, if Magritte 3 is now the norm, will the Seaside book examples be updated to reflect this? Thanks in advance for any help Peter Kenny

2 1

Re: [Pharo-users] Problem learning about Magritte
by Stephan Eggermont May 12, 2014

May 12, 2014

Esteban wrote: >I don't like this "faster way" of prebuilt images. >Makes me think of seeds for forked branches. >Unless something is wrong with the package system, I would encourage >its use, even if it takes long. I strongly encourage the use of ci images. And of course you should add your own, once you've decided what packages you need. The main advantage is that it provides feedback to the core pharo development on changes. Stephan

2 2