January 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Problem to open Pharo 50 on Windows

by Justine STIENNE

Hi, I always have the same problem. When I want to open the image, Pharo is loading but it never becomes opened. Thanks in advance, Justine 2016-01-22 11:18 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > Hi, > > For the latest Pharo 5 you need a new virtual machine: spur. > > You can get it at http://files.pharo.org/get-files/50/pharo-win-stable.zip > > To manage your images you can use the latest version of Pharo Launcher > that will choose the right VM if you give the paths in the settings. ( > http://www.smalltalkhub.com/#%21/%7EPharo/PharoLauncher) > > -- > Cyril > > On Friday, January 22, 2016, Justine STIENNE <justine.stienne(a)gmail.com> > wrote: > >> Hi, >> >> I wanted to download the lastest version of Pharo 50 on this website: >> http://files.pharo.org/get-files/50/ >> After having downloaded the lastest version for Windows >> (pharo-win-latest.zip) and the image in Pharo.zip, I try to to open the >> image with Pharo.exe but nothing appears, and the application never opened. >> Has anyone already had this problem and could help me ? >> >> Thank you, >> Justine >> > > > -- > Cheers > Cyril Ferlicot > >

Jan. 28, 2016

Re: [Pharo-users] Pharo + git workflow

by Offray Vladimir Luna CÃ¡rdenas

For me what monticello has and git not is that is unobtrusive. Yes interface is not pretty, but once you have the basics it becomes invisible. Not the case with git. Hopefully the DVCS support will have the same amount of invisibility. I know that now things are moving, but long threads about the integration of git + pharo show the responsiveness of the community in one hand and the lot of support it needs for working on the other. Cheers, Offray On 26/01/16 13:10, Dimitris Chloupis wrote: > I love live coding , dynamic language, beautiful syntax and close > integration with IDE. But yeah Monticello , I don't get it. I love > Pharo and always respect the hard work of others but that does not > mean I love every part of it. Same story is Blender , Python and all > other tools I use. That ok I don't worry if some parts I don't like. > It's what make with the tools you have that matters most. > On Tue, 26 Jan 2016 at 19:46, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > Sometimes I really don't understand what you see in Pharo ... > > > On 26 Jan 2016, at 17:53, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > > > "If git compares two versions, it does not understand what is in > it." > > > > why it should ? its a version control system, not a refactoring > tool. > > > > " > > When Monticello compares versions, it knows about classes, > methods, inheritance, > > it can explain diffs in the same structured (browsable) form > that you wrote them." > > > > is that Monticello or is that refactoring classes and methods of > pharo ? Because the way I see it is like this if you have a > refactoring language, a language that can refactor its own code , > that language should be able to take two diffirent pieces of code > and not only show you a diff but also show you how your > inheritance is affected, your classes even your live state. > > > > The big question here, from my side is why a version control > system should do that ? Refactoring and version controlling for me > at least is two very different tasks. I dont also see how a > version control system that is self aware refactoring wise when > already have refactoring tools in my IDE, is giving me any > advantage me as a user. Most IDEs come with them anyway. > > > > Its not as if you will use a python IDE, or whatever language > you use and the IDE will go "sorry dude I cannot tell you what git > did there because it has no refactoring and I am too stupid to use > my own refactoring tools". That IDE would belong to the bin. This > is why we use specialized Git gui tools, they are not there just > to make our screens pretty. > > > > "Putting Smalltalk in plain text files can be done, has been > done, and was not successful, because you lose something essential > by leaving the environment." > > > > What you lose is the live state which monticello does not store > anyway, how could it ? it only stores text files, its actually far > more anti-Smalltalk than git is. Because with git you can version > control your pharo images or your fuel files than contain the live > state or you could export the live state and live code to a binary > file. Now try that with monticello. The irony is very large, Git > is far more Smalltalk friendly, than Monticello is. > > > > "The island argument is also a bit too easy: any platform can be > seen as an island that needs to integrate with others, there are > degrees of openness. Your Blender or Python are islands too, just > like SAP, Microsoft and Oracle. Some connections/interfaces are > easy, some are hard(er). It all depends on your position." > > > > I completely agree in the end every API ever programm is to a > degree an island. No code ever shakes in terror saying "oh my god > I need to make my code 100% compatible with whatever is out there" > . Its not possible. But the culture of those other languages is > "lets keep things close" , "lets make coder's life" easier , "lets > keep compatibility and standard/common practices" . > > > > Smalltalk does not do that because it loves experimentation, the > whole smalltalk enviroment is experimentation heaven playground. > Thats great because without it we dont have smalltalk but its also > bad. > > > > "When have you last looked at the source code of git ?" > > > > Never ? Why should I, I dont even take a look at monticello > source code. I tried to improve auto completion and my head kept > spinning around and around, 10s of hours still could not figure > out the code. I am not smart or knowledgable to judge Monticello > on a source code basis. Maybe source code wise, core wise, > Monticello is 1000 times better than Git, but my complains with > Monticello is on the user level. As a smalltalker I just dont see > the point of prefering Monticello over Git , or screw Git, you > want mercurial ? thats fine too. > > > > I just dont see it whats the big deal with Monticello. > > > > "And be honest, do you find git always easy to use ?" > > > > I have been honest from the very start when I started pushing > for git and Github. I have been crystal clear. My usage of git is > super simple. > > > > I dont work in teams, I work alone, I dont even use branches, I > do git pull, git add, git commit and git push. I have reverted > commits a couple of times, I have reset to head sometimes because > of some nasty merges and that was it. I am almost never have > merge conflicts. > > > > You want me to compare my experience with monticello and StHub > VS git and Github using Pharo ? Nope you dont. > > > > Do I find git always easy to use ? You know what , I am a python > coder and I definetly appreciate ease of use and simplicity but > lets be frank here Git was made by the same guy that made the > freaking Linux kernel. He made Git not to be easy but able to > manage an enormous amount of code the easy way the fastest > possible way and he accomplished that goal. > > > > So do I find git easy to use ? Nope > > > > Do I care ? Nope, because I rather use something that is > difficult to use but powerful and with good performance than > something that is very easy to use , limited and slow. Hell , I > dont even find Pharo easy to use , its power and flexibility that > made me love it. > > > > > > On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > > On 26 Jan 2016, at 16:49, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > > > > > Obviously it will better fit Pharo since its made to work with > smalltalk code, but that does not make it any less terrible. Just > because you have one implementation of something that does not > mean its good. Its just means its there and it works. > > > > > > I dont know the internal, they are not documented anyway, > there are some class comments here and there but thats pretty much > it. I dont even remember when was the last time monticello got an > updated, I mean a serious update not just a couple of bug fixes > the 2 years I have been around. > > > > > > Secondly GUI is just plain awful, Smalltalk maybe be the first > or one of the first to implement guis, but those implementations > never ended up to something that would be approachable and easy to > use on a day to day basis, some tools suffer more from this some > less, Monticello is up there with the worse design. > > > > > > Thirdly the inability of the system to version control images > , audio files and other assets it defeats the central purpose of > smalltalk of everything being objects with a loud "Nope !" from > Monticello "Only source code is". > > > > > > So its awesome that Smalltalk , and Squeak got its own version > control system, that is easy to use and Pharo inherited it. > Congratulations to people behind it. But the GUI needs to go, its > a bad advertisement to Pharo, and we need something that is not > stuck to dark ages as you correctly pointed but for the opposite > reason. Because any way you try to turn Monticello you wont find a > label written "modern" on it. The label you may find on it is more > like "abandonware". > > > > > > Also there like a ton of OOP languages out there using git > with no major problems, the problem with smalltalk is that > smalltalk is an island. > > > > > > And the problem with islands is when you end having fun with > them you feel stuck since they dont provide an easy access to the > outside world. > > > > > > "Git just manages blobs, text files at best. Dead text" > > > > > > Last time I checked Monticello used a format called mcz which > is nothing more than a zip file containing st files, which are as > you call it "dead text" files. Also I would like to remind you > that git is used by the CUIS smalltalk to version control their > images, I thought images are live code. > > > > > > Personally I dont see the diffirence between live and dead > text. Its just text to me. The VM is the one that makes it live > anyway. > > > > Yes and no. > > > > If git compares two versions, it does not understand what is in it. > > > > When Monticello compares versions, it knows about classes, > methods, inheritance, > > it can explain diffs in the same structured (browsable) form > that you wrote them. > > > > Putting Smalltalk in plain text files can be done, has been > done, and was not successful, because you lose something essential > by leaving the environment. > > > > The island argument is also a bit too easy: any platform can be > seen as an island that needs to integrate with others, there are > degrees of openness. Your Blender or Python are islands too, just > like SAP, Microsoft and Oracle. Some connections/interfaces are > easy, some are hard(er). It all depends on your position. > > > > When have you last looked at the source code of git ? > > > > And be honest, do you find git always easy to use ? > > > > > On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > > > > On 26 Jan 2016, at 15:59, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > > > > > > > To be fair my experience with pharo and git have been not > always smooth either. I have the VM crashing again and again > completely randomly when it was trying to pull SmaCC as dependency > for my project Ephestos, had to drop SmaCC and moving my python > type parsing at python side. > > > > > > > > But I find it ironic someone using Monticello, trying to > equate git with dark ages, you cant get more dark ages than > monticello, frankly. No offense to people who made it , its great > that is in there but its full of problems and bad designs and cant > even begin to be compared with Github and GIT GUI clients. > Monticello is according to my personal opinion by far the worst > tool of Pharo. > > > > > > No it is not. It is a version management system that > understands our object and code model, a system that we control. > Git just manages blobs, text files at best. Dead text. > > > > > > (This does not mean it is perfect, nor that it cannot improve, > nor that we should not improve our git integration.) > > > > > > > On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: > > > > NorbertHartl wrote > > > > > - I need to use BaselineOf instead of ConfigurationOf. > Thus you cannot use > > > > > Versionner anymore > > > > > > > > Unfortunately. This is the biggest drag for me after > switching all my > > > > personal projects to git (GitHub for public and BitBucket > for private). I > > > > had gotten spoiled by Versionner and hand-editing MetaC > artifacts feels like > > > > going back to the dark ages :/ > > > > > > > > Well, I guess copying the baselines generated by Versionner > into a BaselineOf is probably a way to do it. > > > > > > > > Thierry > > > > > > > > > > > > > > > > > > > > ----- > > > > Cheers, > > > > Sean > > > > -- > > > > View this message in context: > http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html > > > > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > > > > > > > > > > > >

Jan. 28, 2016

Re: [Pharo-users] CommandLineHandler surprises

by Esteban Lorenzano

Hi, > On 27 Jan 2016, at 23:38, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > Another surprise. > > ./pharo Pharo.image update > > blows up. Both in the stable 4 and 5 and latest (alpha) versions. On the Pharo 4 version it maxed at 1gb ram and the Pharo 5 versions maxed at 3.8gb ram and both maxed out a cpu thread. The Pharo4 version never quit, I had to kill. The Pharo5 version core dumped. > > Just wanted to let you know. yes, we are aware. but thatâs not a problem of the command line tools but the update process: it is broken since ages and IMO, we should just remove it (at least hide it). Esteban > > Shalom Aleichem > > Jimmie > > > > > On 01/27/2016 12:59 PM, Jimmie Houchin wrote: >> Hello, >> >> I am reading the Deep Into Pharo book. I have been playing with the CommandLineHandler. I have been surprised by some of its behavior. Though I have used Pharo a long time. I have not played with it from the command line. I am a very long time Linux user and am very comfortable on the command line. >> >> When according to the book I execute: >> >> ./pharo Pharo.image --list >> >> It will provide me with a list of the available handlers. >> >> I did not expect it to open up an image for me. That is not what I expected or wanted. I did not intend to use an image at this time. I am on the command line and expecting to see results there. Not for a new window to pop up. >> >> As of yet I have always opened up Pharo on the command line. I have yet to use PharoLauncher, but do intend to do so soon. So I am comfortable with Pharo opening up a new window and image from the command line. >> >> However it is very unintuitive and seemingly unnecessary to open up an image for these command line handlers. I naively think they should simply return the results. Now if that requires opening a headless image for a moment and close, then fine. >> >> --list >> --help >> --version >> --copyright >> eval >> printVersion >> >> Some other handlers I do not know if opening an image is the correct default. I have not spent the time learning them yet. >> >> Thanks. Shalom Aleichem. >> >> Jimmie > >

Jan. 28, 2016

Re: [Pharo-users] Pharo + git workflow

by Norbert Hartl

Hi Thierry, > Am 27.01.2016 um 06:40 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: > > Hi Norbert, > > the development version on Pharo4 has the credentials working now. It switches to https instead of ssh if you add a username and a password, since a ssh url can't carry a password and, in the case of github, the ssh user is allways git. > thanks very much. I need to find some time to try it out. I have kind of a workflow but that does only work if I use a single repository. Norbert > Thierry > > Le 26/01/2016 13:32, Norbert Hartl a Ã©crit : >> >>> Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert(a)hartl.name >>> <mailto:norbert@hartl.name>>: >>> >>>> >>>> Am 25.01.2016 um 23:32 schrieb Thierry Goubier >>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: >>>> >>>> Le 25/01/2016 23:13, Norbert Hartl a Ã©crit : >>>>> >>>>>> Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert(a)hartl.name >>>>>> <mailto:norbert@hartl.name>>: >>>>>> >>>>>> Hi, >>>>>> >>>>>>> Am 25.01.2016 um 22:55 schrieb Thierry Goubier >>>>>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: >>>>>>> >>>>>>> Hi Norbert, >>>>>>> >>>>>>> Just tell me if you need any additional parameter to the git clone >>>>>>> for the credentials, because I'm not sure I have written the code >>>>>>> which will handle them. >>>>>>> >>>>>> I'll check that. The easiest approach is to use the authority part >>>>>> of the url like >>>>>> >>>>>> https://user:pass@bitbucket.org/â¦. >>>> >>>> I'm nearly sure my code doesn't check for them and silently drop them :( >>>> >>>>>> I try that tomorrow. >>>>>> >>>>> But then I don't think that sub-directories work per http. >>>> >>>> They do over https. But remember the syntax is, to take your url, >>>> >>>> gitfiletree://user:pass@bitbucket.org/...?protocol=https >>> >>> Does not work for me. It complains about unknown url scheme. But using >>> the read-only version of gitfiletree would still mean I have to >>> install gitfiletree, no? I have no glue hot the url with bitbucket:// >>> could work. >>>> >>>> I wonder if I can write code that considers that if you have a >>>> username and a password, then it should use https and not ssh. >>> >>> I see no reason why. You can use ssh with username and password as well. >>> >> Ok, I got it through the unknown url scheme but indeed the credentials >> are stripped off. >> >> Norbert >> > >

Jan. 28, 2016

Re: [Pharo-users] Some Spotter Questions

by Sven Van Caekenberghe

Doru, > On 27 Jan 2016, at 17:46, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Jan 27, 2016, at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> I managed to add a spotter extension and preview, but I still have some questions. > > Thank you! Can you describe the extension? Not yet, but soon ;-) >> Is there some global top level overview documentation about writing Spotter extensions ? > > Only some blog posts: > https://www.google.com/search?client=safari&rls=en&q=site:humane-assessment… I found that, I also used Torsten's article: https://medium.com/concerning-pharo/multiple-desktops-for-pharo-5cbc46f3179f which is using GT tools in a nice/cool way. Still, it is not enough. > Writing a help is in progress. It would be very useful to drive it through your questions. > > >> Is the only way to add a 'global/first' search extension by adding a method to class GTSpotter itself ? > > Yes. > > >> I don't see any other package do that (in a modular way), it feels a bit wrong compared to how modular the GT inspector is. > > It is exactly the same design as the inspector. Every step in Spotter has an object as an input (like the inspector), and the first object when opening Spotter is an instance of GTSpotter. It just felt strange to be the first to add an extension there. >> Is there a way to reuse a GT inspector view as a preview ? I tried that but it did not work, but what I copied over was 99% identical. > > Not yet. The problem is the missing 1% :) Duplicating the functionality like we have to do today should ideally be avoided (see my example at the end). >> Can you have tabs (multiple pages) in the preview ? > > Not for now. At the moment, you can have multiple previews, and only the first one will be displayed. OK >> Is it possible to control on what tab an inspector opens when a matching item is clicked (like to maintain the same view as the preview) ? > > No. > > >> What are some best practices for the order, exact matches, fast searching, etc â¦ ? > > Not much. The best practice is to simply watch the usage, and try to accommodate the best way :). It is very cool to be able to inspect the pragma and browse each usage as source code ! >> Is it possible to search in multiple ways (multiple properties), not just collection -> itemName -> GTFilterSubstring ? (Say I want to search all fields of an address object). > > Of course. Take a look at the GTFilter hierarchy, and you can just write your own. > > >> Searching for Color by name, or by RGB and other representations would seem like a good tutorial example (for me). > > I am not sure I understand, but it sounds intriguing and I am looking for a case that we can use for a tutorial. Could you elaborate? Perhaps we can write this together. GTSpotter>>#spotterForColorFor: aStep <spotterOrder: 20> aStep listProcessor title: 'Color'; allCandidates: [ Color brickColorRegistry values ]; itemName: [ :each | each name ]; filter: GTFilterSubstring; wantsToDisplayOnEmptyQuery: false Color>>#spotterPreviewColorIn: aComposite <spotterPreview: 0> aComposite custom: (BorderedMorph new color: self) This works fine. Just for fun, I would also like to be able to search using CSS style color specs, like FFF or C0C0C0 (3 or 6 hex digits for RGB). How would that fit in ? There is #asHexString, but I would like a bit more control and intelligence from my part: I want to write the test and there would only be one answer. Sven > Cheers, > Doru > > >> Thx, >> >> Sven > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > >

Jan. 28, 2016

Re: [Pharo-users] mini Actor model in two classes and

by stepharo

thanks I will have a look. (now drilling the floor ;) I was reading the implementation of Actalk (port by serge) Serge BTW the subclass of SharedQueue are not working anymore because they access to state that does not exist. Stef Le 27/1/16 22:20, Norbert Hartl a Ã©crit : > Super simple implementation. I made Andrew Blacks Erlang example run > on pharo a while ago if you are interested. > > http://smalltalkhub.com/#!/~NorbertHartl/Erlang > <http://smalltalkhub.com/#%21/%7ENorbertHartl/Erlang> > > Keep us posted what you learn so we can, too ;) > > Norbert > > Am 27.01.2016 um 21:53 schrieb stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > >> Hi >> >> Since long time I wanted to have fun building a mini actor model. >> So I did one and I attached the skeleton of a future chapter for >> FunWithPharo :) >> >> Now I will read about futures and the rest. >> >> may be there is a problem with the compiling behavior. >> (see thread learningObject) >> >> Stef >> >> <Actalk.pdf>

Jan. 28, 2016

Re: [Pharo-users] CommandLineHandler surprises

by Jimmie Houchin

You are right, I just easily added it. :) Tested it and it works. Now I just need to go read up on how to "Contribute to Pharo" and become a productive citizen. :) Shalom Aleichem Jimmie On 01/27/2016 04:32 PM, Esteban Lorenzano wrote: > >> On 27 Jan 2016, at 23:28, Jimmie Houchin <jlhouchin(a)gmail.com >> <mailto:jlhouchin@gmail.com>> wrote: >> >> The one thing I didn't know and it didn't work was the attempt to get >> multiple items. >> >> ./pharo Pharo.image get XMLParser NBSQLite3 >> >> failed. It got the first and ignored the second. > > yesâ¦ I never added that :) > can be easily added, thoughâ¦ > > Esteban > >> >> I was just playing and thought I would give it a try. :) >> >> I look forward to seeing what a command line Pharo can be. The best >> in command line and the best in full UI development, environment and >> applications. Exciting times. >> >> Shalom Aleichem >> >> Jimmie >> >> On 01/27/2016 04:21 PM, Esteban Lorenzano wrote: >>> >>>> On 27 Jan 2016, at 23:03, Sven Van Caekenberghe <sven(a)stfx.eu >>>> <mailto:sven@stfx.eu>> wrote: >>>> >>>>> >>>>> On 27 Jan 2016, at 22:56, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>>>> >>>>> Yes, I did not express myself well. What I am meaning is that I do >>>>> not expect to have a UI window for the image pop-up. But it does, >>>>> every time. >>>>> >>>>> The difference that I can find is that I have been downloading VMs >>>>> from >>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>> >>>>> These VMs have only a "pharo" and not a "pharo-ui". So ./pharo >>>>> always opens an image in a UI window. >>>>> >>>>> When I do >>>>> wget -O- get.pharo.org/stable+vm <http://get.pharo.org/stable+vm> >>>>> | bash >>>>> >>>>> Then it generates a pharo and a pharo-ui script. >>>>> >>>>> This is probably the problem that I am having is that the manual >>>>> downloads from the website are not like the zeroconf scripts and >>>>> so there are no explicit UI and Headless scripts. >>>>> >>>>> These zeroconf VMs with their differing scripts do exactly as >>>>> advertised. Are the generated scripts different for different >>>>> Linux distros? Is there a reason for the zipped downloads on the >>>>> website to not include them? >>>> >>>> They are not that different. The 'secret' is the --nodisplay VM >>>> option, that's all. If you know what you are doing, there is >>>> actually something to say for not using the .sh wrapper scripts. >>>> >>>>> I tried the "get" handler and had it install XMLParser. Very nice. >>>> >>>> Good ! >>> >>> yes, the âgetâ command is one of the lastest cool additions (not >>> because I added it ;) ) >>> but the capability of express >>> >>> ./pharo Pharo.image get Seaside3 >>> >>> (for example) >>> is very convenient :) >>> >>> Esteban >>> >>>> >>>> Yes, once it works this is all very slick. >>>> >>>>> Thanks and Shalom Aleichem. >>>>> >>>>> Jimmie >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 01/27/2016 01:21 PM, Sven Van Caekenberghe wrote: >>>>>> Jimmie, >>>>>> >>>>>> Of course it opens an image, else nothing would work ;-) >>>>>> I suspect you mean it opens a UI ? >>>>>> That should not happen, it depends on what your ./pharo actually >>>>>> is or does. >>>>>> In any case, rest assured, using it on the command line works >>>>>> perfectly. >>>>>> >>>>>> On the first Linux server that I log in to: >>>>>> >>>>>> $ cat ~/pharo/bin/pharo >>>>>> #!/usr/bin/env bash >>>>>> # some magic to find out the real location of this script dealing >>>>>> with symlinks >>>>>> DIR=`readlink "$0"` || DIR="$0"; >>>>>> DIR=`dirname "$DIR"`; >>>>>> cd "$DIR" >>>>>> DIR=`pwd` >>>>>> cd - > /dev/null >>>>>> # disable parameter expansion to forward all arguments >>>>>> unprocessed to the VM >>>>>> set -f >>>>>> # run the VM and pass along all arguments as is >>>>>> "$DIR"/"pharo-vm/pharo" --nodisplay "$@" >>>>>> >>>>>> $ ~/pharo/bin/pharo ~/pharo/build/Pharo.image --list >>>>>> Currently installed Command Line Handlers: >>>>>> Fuel Loads fuel files >>>>>> config Install and inspect Metacello Configurations >>>>>> from the command line >>>>>> save Rename the image and changes file >>>>>> update Load updates >>>>>> printVersion Print image version >>>>>> st Loads and executes .st source files >>>>>> test A command line test runner >>>>>> clean Run image cleanup >>>>>> eval Directly evaluates passed in one line scripts >>>>>> >>>>>> $ ~/pharo/bin/pharo ~/pharo/build/Pharo.image eval '123 factorial' >>>>>> 12146304367025329675766243241881295855454217088483382315328918161829235892362167668831156960612640202170735835221294047782591091570411651472186029519906261646730733907419814952960000000000000000000000000000 >>>>>> >>>>>> >>>>>> HTH >>>>>> >>>>>> Sven >>>>>> >>>>>>> On 27 Jan 2016, at 19:59, Jimmie Houchin <jlhouchin(a)gmail.com >>>>>>> <mailto:jlhouchin@gmail.com>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am reading the Deep Into Pharo book. I have been playing with >>>>>>> the CommandLineHandler. I have been surprised by some of its >>>>>>> behavior. Though I have used Pharo a long time. I have not >>>>>>> played with it from the command line. I am a very long time >>>>>>> Linux user and am very comfortable on the command line. >>>>>>> >>>>>>> When according to the book I execute: >>>>>>> >>>>>>> ./pharo Pharo.image --list >>>>>>> >>>>>>> It will provide me with a list of the available handlers. >>>>>>> >>>>>>> I did not expect it to open up an image for me. That is not what >>>>>>> I expected or wanted. I did not intend to use an image at this >>>>>>> time. I am on the command line and expecting to see results >>>>>>> there. Not for a new window to pop up. >>>>>>> >>>>>>> As of yet I have always opened up Pharo on the command line. I >>>>>>> have yet to use PharoLauncher, but do intend to do so soon. So I >>>>>>> am comfortable with Pharo opening up a new window and image >>>>>>> from the command line. >>>>>>> >>>>>>> However it is very unintuitive and seemingly unnecessary to open >>>>>>> up an image for these command line handlers. I naively think >>>>>>> they should simply return the results. Now if that requires >>>>>>> opening a headless image for a moment and close, then fine. >>>>>>> >>>>>>> --list >>>>>>> --help >>>>>>> --version >>>>>>> --copyright >>>>>>> eval >>>>>>> printVersion >>>>>>> >>>>>>> Some other handlers I do not know if opening an image is the >>>>>>> correct default. I have not spent the time learning them yet. >>>>>>> >>>>>>> Thanks. Shalom Aleichem. >>>>>>> >>>>>>> Jimmie >>> >> >

Jan. 27, 2016

Re: [Pharo-users] CommandLineHandler surprises

by Jimmie Houchin

Another surprise. ./pharo Pharo.image update blows up. Both in the stable 4 and 5 and latest (alpha) versions. On the Pharo 4 version it maxed at 1gb ram and the Pharo 5 versions maxed at 3.8gb ram and both maxed out a cpu thread. The Pharo4 version never quit, I had to kill. The Pharo5 version core dumped. Just wanted to let you know. Shalom Aleichem Jimmie On 01/27/2016 12:59 PM, Jimmie Houchin wrote: > Hello, > > I am reading the Deep Into Pharo book. I have been playing with the > CommandLineHandler. I have been surprised by some of its behavior. > Though I have used Pharo a long time. I have not played with it from > the command line. I am a very long time Linux user and am very > comfortable on the command line. > > When according to the book I execute: > > ./pharo Pharo.image --list > > It will provide me with a list of the available handlers. > > I did not expect it to open up an image for me. That is not what I > expected or wanted. I did not intend to use an image at this time. I > am on the command line and expecting to see results there. Not for a > new window to pop up. > > As of yet I have always opened up Pharo on the command line. I have > yet to use PharoLauncher, but do intend to do so soon. So I am > comfortable with Pharo opening up a new window and image from the > command line. > > However it is very unintuitive and seemingly unnecessary to open up an > image for these command line handlers. I naively think they should > simply return the results. Now if that requires opening a headless > image for a moment and close, then fine. > > --list > --help > --version > --copyright > eval > printVersion > > Some other handlers I do not know if opening an image is the correct > default. I have not spent the time learning them yet. > > Thanks. Shalom Aleichem. > > Jimmie

Jan. 27, 2016

Re: [Pharo-users] CommandLineHandler surprises

by Esteban Lorenzano

> On 27 Jan 2016, at 23:28, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > The one thing I didn't know and it didn't work was the attempt to get multiple items. > > ./pharo Pharo.image get XMLParser NBSQLite3 > > failed. It got the first and ignored the second. yesâ¦ I never added that :) can be easily added, thoughâ¦ Esteban > > I was just playing and thought I would give it a try. :) > > I look forward to seeing what a command line Pharo can be. The best in command line and the best in full UI development, environment and applications. Exciting times. > > Shalom Aleichem > > Jimmie > > On 01/27/2016 04:21 PM, Esteban Lorenzano wrote: >> >>> On 27 Jan 2016, at 23:03, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>> >>>> >>>> On 27 Jan 2016, at 22:56, Jimmie Houchin < <mailto:jlhouchin@gmail.com>jlhouchin(a)gmail.com <mailto:jlhouchin@gmail.com>> wrote: >>>> >>>> Yes, I did not express myself well. What I am meaning is that I do not expect to have a UI window for the image pop-up. But it does, every time. >>>> >>>> The difference that I can find is that I have been downloading VMs from >>>> http://files.pharo.org/vm/pharo-spur32/linux/ <http://files.pharo.org/vm/pharo-spur32/linux/> >>>> >>>> These VMs have only a "pharo" and not a "pharo-ui". So ./pharo always opens an image in a UI window. >>>> >>>> When I do >>>> wget -O- get.pharo.org/stable+vm | bash >>>> >>>> Then it generates a pharo and a pharo-ui script. >>>> >>>> This is probably the problem that I am having is that the manual downloads from the website are not like the zeroconf scripts and so there are no explicit UI and Headless scripts. >>>> >>>> These zeroconf VMs with their differing scripts do exactly as advertised. Are the generated scripts different for different Linux distros? Is there a reason for the zipped downloads on the website to not include them? >>> >>> They are not that different. The 'secret' is the --nodisplay VM option, that's all. If you know what you are doing, there is actually something to say for not using the .sh wrapper scripts. >>> >>>> I tried the "get" handler and had it install XMLParser. Very nice. >>> >>> Good ! >> >> yes, the âgetâ command is one of the lastest cool additions (not because I added it ;) ) >> but the capability of express >> >> ./pharo Pharo.image get Seaside3 >> >> (for example) >> is very convenient :) >> >> Esteban >> >>> >>> Yes, once it works this is all very slick. >>> >>>> Thanks and Shalom Aleichem. >>>> >>>> Jimmie >>>> >>>> >>>> >>>> >>>> >>>> On 01/27/2016 01:21 PM, Sven Van Caekenberghe wrote: >>>>> Jimmie, >>>>> >>>>> Of course it opens an image, else nothing would work ;-) >>>>> I suspect you mean it opens a UI ? >>>>> That should not happen, it depends on what your ./pharo actually is or does. >>>>> In any case, rest assured, using it on the command line works perfectly. >>>>> >>>>> On the first Linux server that I log in to: >>>>> >>>>> $ cat ~/pharo/bin/pharo >>>>> #!/usr/bin/env bash >>>>> # some magic to find out the real location of this script dealing with symlinks >>>>> DIR=`readlink "$0"` || DIR="$0"; >>>>> DIR=`dirname "$DIR"`; >>>>> cd "$DIR" >>>>> DIR=`pwd` >>>>> cd - > /dev/null >>>>> # disable parameter expansion to forward all arguments unprocessed to the VM >>>>> set -f >>>>> # run the VM and pass along all arguments as is >>>>> "$DIR"/"pharo-vm/pharo" --nodisplay "$@" >>>>> >>>>> $ ~/pharo/bin/pharo ~/pharo/build/Pharo.image --list >>>>> Currently installed Command Line Handlers: >>>>> Fuel Loads fuel files >>>>> config Install and inspect Metacello Configurations from the command line >>>>> save Rename the image and changes file >>>>> update Load updates >>>>> printVersion Print image version >>>>> st Loads and executes .st source files >>>>> test A command line test runner >>>>> clean Run image cleanup >>>>> eval Directly evaluates passed in one line scripts >>>>> >>>>> $ ~/pharo/bin/pharo ~/pharo/build/Pharo.image eval '123 factorial' >>>>> 12146304367025329675766243241881295855454217088483382315328918161829235892362167668831156960612640202170735835221294047782591091570411651472186029519906261646730733907419814952960000000000000000000000000000 >>>>> >>>>> >>>>> HTH >>>>> >>>>> Sven >>>>> >>>>>> On 27 Jan 2016, at 19:59, Jimmie Houchin <jlhouchin(a)gmail.com <mailto:jlhouchin@gmail.com>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am reading the Deep Into Pharo book. I have been playing with the CommandLineHandler. I have been surprised by some of its behavior. Though I have used Pharo a long time. I have not played with it from the command line. I am a very long time Linux user and am very comfortable on the command line. >>>>>> >>>>>> When according to the book I execute: >>>>>> >>>>>> ./pharo Pharo.image --list >>>>>> >>>>>> It will provide me with a list of the available handlers. >>>>>> >>>>>> I did not expect it to open up an image for me. That is not what I expected or wanted. I did not intend to use an image at this time. I am on the command line and expecting to see results there. Not for a new window to pop up. >>>>>> >>>>>> As of yet I have always opened up Pharo on the command line. I have yet to use PharoLauncher, but do intend to do so soon. So I am comfortable with Pharo opening up a new window and image from the command line. >>>>>> >>>>>> However it is very unintuitive and seemingly unnecessary to open up an image for these command line handlers. I naively think they should simply return the results. Now if that requires opening a headless image for a moment and close, then fine. >>>>>> >>>>>> --list >>>>>> --help >>>>>> --version >>>>>> --copyright >>>>>> eval >>>>>> printVersion >>>>>> >>>>>> Some other handlers I do not know if opening an image is the correct default. I have not spent the time learning them yet. >>>>>> >>>>>> Thanks. Shalom Aleichem. >>>>>> >>>>>> Jimmie >> >

Jan. 27, 2016

Re: [Pharo-users] CommandLineHandler surprises

by Jimmie Houchin

The one thing I didn't know and it didn't work was the attempt to get multiple items. ./pharo Pharo.image get XMLParser NBSQLite3 failed. It got the first and ignored the second. I was just playing and thought I would give it a try. :) I look forward to seeing what a command line Pharo can be. The best in command line and the best in full UI development, environment and applications. Exciting times. Shalom Aleichem Jimmie On 01/27/2016 04:21 PM, Esteban Lorenzano wrote: > >> On 27 Jan 2016, at 23:03, Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> >>> >>> On 27 Jan 2016, at 22:56, Jimmie Houchin <jlhouchin(a)gmail.com >>> <mailto:jlhouchin@gmail.com>> wrote: >>> >>> Yes, I did not express myself well. What I am meaning is that I do >>> not expect to have a UI window for the image pop-up. But it does, >>> every time. >>> >>> The difference that I can find is that I have been downloading VMs from >>> http://files.pharo.org/vm/pharo-spur32/linux/ >>> >>> These VMs have only a "pharo" and not a "pharo-ui". So ./pharo >>> always opens an image in a UI window. >>> >>> When I do >>> wget -O- get.pharo.org/stable+vm | bash >>> >>> Then it generates a pharo and a pharo-ui script. >>> >>> This is probably the problem that I am having is that the manual >>> downloads from the website are not like the zeroconf scripts and so >>> there are no explicit UI and Headless scripts. >>> >>> These zeroconf VMs with their differing scripts do exactly as >>> advertised. Are the generated scripts different for different Linux >>> distros? Is there a reason for the zipped downloads on the website >>> to not include them? >> >> They are not that different. The 'secret' is the --nodisplay VM >> option, that's all. If you know what you are doing, there is actually >> something to say for not using the .sh wrapper scripts. >> >>> I tried the "get" handler and had it install XMLParser. Very nice. >> >> Good ! > > yes, the âgetâ command is one of the lastest cool additions (not > because I added it ;) ) > but the capability of express > > ./pharo Pharo.image get Seaside3 > > (for example) > is very convenient :) > > Esteban > >> >> Yes, once it works this is all very slick. >> >>> Thanks and Shalom Aleichem. >>> >>> Jimmie >>> >>> >>> >>> >>> >>> On 01/27/2016 01:21 PM, Sven Van Caekenberghe wrote: >>>> Jimmie, >>>> >>>> Of course it opens an image, else nothing would work ;-) >>>> I suspect you mean it opens a UI ? >>>> That should not happen, it depends on what your ./pharo actually is >>>> or does. >>>> In any case, rest assured, using it on the command line works >>>> perfectly. >>>> >>>> On the first Linux server that I log in to: >>>> >>>> $ cat ~/pharo/bin/pharo >>>> #!/usr/bin/env bash >>>> # some magic to find out the real location of this script dealing >>>> with symlinks >>>> DIR=`readlink "$0"` || DIR="$0"; >>>> DIR=`dirname "$DIR"`; >>>> cd "$DIR" >>>> DIR=`pwd` >>>> cd - > /dev/null >>>> # disable parameter expansion to forward all arguments unprocessed >>>> to the VM >>>> set -f >>>> # run the VM and pass along all arguments as is >>>> "$DIR"/"pharo-vm/pharo" --nodisplay "$@" >>>> >>>> $ ~/pharo/bin/pharo ~/pharo/build/Pharo.image --list >>>> Currently installed Command Line Handlers: >>>> Fuel Loads fuel files >>>> config Install and inspect Metacello Configurations >>>> from the command line >>>> save Rename the image and changes file >>>> update Load updates >>>> printVersion Print image version >>>> st Loads and executes .st source files >>>> test A command line test runner >>>> clean Run image cleanup >>>> eval Directly evaluates passed in one line scripts >>>> >>>> $ ~/pharo/bin/pharo ~/pharo/build/Pharo.image eval '123 factorial' >>>> 12146304367025329675766243241881295855454217088483382315328918161829235892362167668831156960612640202170735835221294047782591091570411651472186029519906261646730733907419814952960000000000000000000000000000 >>>> >>>> >>>> HTH >>>> >>>> Sven >>>> >>>>> On 27 Jan 2016, at 19:59, Jimmie Houchin <jlhouchin(a)gmail.com >>>>> <mailto:jlhouchin@gmail.com>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I am reading the Deep Into Pharo book. I have been playing with >>>>> the CommandLineHandler. I have been surprised by some of its >>>>> behavior. Though I have used Pharo a long time. I have not played >>>>> with it from the command line. I am a very long time Linux user >>>>> and am very comfortable on the command line. >>>>> >>>>> When according to the book I execute: >>>>> >>>>> ./pharo Pharo.image --list >>>>> >>>>> It will provide me with a list of the available handlers. >>>>> >>>>> I did not expect it to open up an image for me. That is not what I >>>>> expected or wanted. I did not intend to use an image at this time. >>>>> I am on the command line and expecting to see results there. Not >>>>> for a new window to pop up. >>>>> >>>>> As of yet I have always opened up Pharo on the command line. I >>>>> have yet to use PharoLauncher, but do intend to do so soon. So I >>>>> am comfortable with Pharo opening up a new window and image from >>>>> the command line. >>>>> >>>>> However it is very unintuitive and seemingly unnecessary to open >>>>> up an image for these command line handlers. I naively think they >>>>> should simply return the results. Now if that requires opening a >>>>> headless image for a moment and close, then fine. >>>>> >>>>> --list >>>>> --help >>>>> --version >>>>> --copyright >>>>> eval >>>>> printVersion >>>>> >>>>> Some other handlers I do not know if opening an image is the >>>>> correct default. I have not spent the time learning them yet. >>>>> >>>>> Thanks. Shalom Aleichem. >>>>> >>>>> Jimmie >

Jan. 27, 2016