December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GetOpt

by phil＠highoctane.be

On Wed, Dec 3, 2014 at 9:51 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Phil, > > On Dec 2, 2014, at 2:18 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > Well, after looking at the command line handlers in the image for the way > options are handled, I was of opinion that I wanted something like getopt. > > So, I looked around and found that implementation of Ian that I plugged > into the CommandLineArguments in my activate methods. > > I like the dictionary + block approach > > I have quite a couple commands (like --create-user -u xxx -p xxx -e xxx -n > xxx -g xxx) and it was a pain to write the options parsing. > > So, something like this in my XXToolsCommandLineHandler > > activate > ... > self activateCreateUser > ... > > activateCreateUser > > GetOpt new at: $u put: [ :opt :arg | userName := arg ]; at: $p put: [ :opt > :arg | ... ]; at: $e put: [ :opt :arg | ... ]; at: $n put: [ :opt :arg | > ... ]. > at: $g put: [ :opt :arg | ... ]; > parse: self arguments. > "wrapped in some error handling" > XXTools makeUserNames: userName ... > > No more need to dig into a number of isXXXX methods and optionAt:... > > I think we should make this work with more integration etc but I have > other fish to fry at the moment and this works well for me. > > We need more doc on the CommandLineHandlers but it is a fantastic piece of > Pharo! > > Combined with a small image, it would be a terrific tool. > > I am investing some time on those CLI things as I need them for servers > and even if Bash is cool for some things, Pharo is better in terms of > cleanliness. > > One factor is the time taken for loading the image. > > > I bet that if you measure it you'll find that the load time is very small > and the bulk of the time is in unnecessary or insane activities. One if > these, which Ben Coman's recent changes above my 64-bit microsecond clock > should have fixed is a spin loop of up to a second to synchronize the > second and millisecond clocks. Another is a GC to start the new weakness > facilities. > > I found these either by profiling (clock sync; I can give you a change > set that allows profiling across a snapshot, quit, resume) or using the VM > simulator (GC to check for finalization facilities). > Nice to know! Yeah, send me the .cs, I am eager to try. The sim is not working for my Pharo. I admit that I've let that on the backburner when Clement told me he was using your image for that. (little depressing moment). I've used strace a bit to see what the VM was doing as well as instrumenting some plugins on a custom VM build. There is the dtrace enabled VM possibility (Ardian's thing) and this should be explored too for instrumentation. > > Maybe should we look into something like a pharod, a daemon that would > just run scripts and a lightweight CLI tool that would pass the scripts to > it. > > > IMO all that needs to be fine is to take a careful look at start-up and > eliminate costly but unnecessary activities. You should easily be able to > get startup times down to tens if milliseconds on modem hardware. > Yes it is fast when starting stuff. But when repeated a ton of times, it becomes long. It will be nice to get things super fast indeed. That would be a great bonus. Phil > > Something like: > http://www.martiansoftware.com/nailgun/ > > I think we could steal their C client right away/ > > Phil > > > > > > > On Tue, Dec 2, 2014 at 10:17 AM, stepharo <stepharo(a)free.fr> wrote: > >> Can you just tell me a bit more :) >> >> Le 2/12/14 08:45, phil(a)highoctane.be a Ã©crit : >> >>> I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 >>> >>> See: >>> >>> http://www.smalltalkhub.com/#!/~philippeback/GetOpt < >>> http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt> >>> >>> Nice tool even if we have some other support in CommandLineHandlers. >>> But for a quick parameters setting in your own CommandLineHandler, it is >>> fast to use and easy to debug. >>> >>> Phil >>> >>> >>> >>> >> >> >

Dec. 3, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Marcus Denker

Yes, seemingly we lost again the repos of external packages... this is a bug, something in the integraton process resets the reopsitories. On Sat, Nov 29, 2014 at 7:53 AM, Ben Coman <btc(a)openinworld.com> wrote: > > Sometimes when I am hacking around the system, I use Monticello to review > just what I've changed. > > In build 40390, I did a <Changes> > of Glamour-Core (BernardoContreras.286) against Pharo40/main and got > _lots_ of changes. Then it seems that this package is not in > Pharo40/main. Should it be? > > Maybe this is because its an external package - but then its repository is > not listed? > > cheers -ben > >

Dec. 3, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Marcus Denker

> On 29 Nov 2014, at 07:53, Ben Coman <btc(a)openInWorld.com> wrote: > > > 2014-11-27 10:02 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > >> >> The fact that Athens are part of Pharo distribution don't means, that its repository should be abandoned and all updates should come directly to Pharo. That would be a huge mistake. >> >> That's how I've done it recently. >> >> I'll merge the changes from pharo -> athens repository. > > Thanks for doing that! > > Hm, actually I don't know how to do that :) > Whats the common way for merging this changes back? > Do I just > open Monticello Browser, > select the Athens packages (Athens-Balloon/Athens-Cairo/Athens-Core ..) > and just save them in the 'http://smalltalkhub.com/mc/Pharo/Athens/main <http://smalltalkhub.com/mc/Pharo/Athens/main>' - repository ? > I would say -> merge with the repo (if there are changes) -> commit back to the repo -> sync with maintainer -> Maintainer should give OK and make a new Config Then we should make sure to have the same in the image as in the repo. Marcus

Dec. 3, 2014

Re: [Pharo-dev] GetOpt

by Eliot Miranda

Hi Phil, On Dec 2, 2014, at 2:18 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Well, after looking at the command line handlers in the image for the way options are handled, I was of opinion that I wanted something like getopt. > > So, I looked around and found that implementation of Ian that I plugged into the CommandLineArguments in my activate methods. > > I like the dictionary + block approach > > I have quite a couple commands (like --create-user -u xxx -p xxx -e xxx -n xxx -g xxx) and it was a pain to write the options parsing. > > So, something like this in my XXToolsCommandLineHandler > > activate > ... > self activateCreateUser > > ... > > activateCreateUser > > GetOpt new > at: $u put: [ :opt :arg | userName := arg ]; > at: $p put: [ :opt :arg | ... ]; > at: $e put: [ :opt :arg | ... ]; > at: $n put: [ :opt :arg | ... ]. > at: $g put: [ :opt :arg | ... ]; > parse: self arguments. > > "wrapped in some error handling" > XXTools makeUserNames: userName ... > > No more need to dig into a number of isXXXX methods and optionAt:... > > I think we should make this work with more integration etc but I have other fish to fry at the moment and this works well for me. > > We need more doc on the CommandLineHandlers but it is a fantastic piece of Pharo! > > Combined with a small image, it would be a terrific tool. > > I am investing some time on those CLI things as I need them for servers and even if Bash is cool for some things, Pharo is better in terms of cleanliness. > > One factor is the time taken for loading the image. I bet that if you measure it you'll find that the load time is very small and the bulk of the time is in unnecessary or insane activities. One if these, which Ben Coman's recent changes above my 64-bit microsecond clock should have fixed is a spin loop of up to a second to synchronize the second and millisecond clocks. Another is a GC to start the new weakness facilities. I found these either by profiling (clock sync; I can give you a change set that allows profiling across a snapshot, quit, resume) or using the VM simulator (GC to check for finalization facilities). > Maybe should we look into something like a pharod, a daemon that would just run scripts and a lightweight CLI tool that would pass the scripts to it. IMO all that needs to be fine is to take a careful look at start-up and eliminate costly but unnecessary activities. You should easily be able to get startup times down to tens if milliseconds on modem hardware. > > Something like: > http://www.martiansoftware.com/nailgun/ > > I think we could steal their C client right away/ > > Phil > > > > > > > On Tue, Dec 2, 2014 at 10:17 AM, stepharo <stepharo(a)free.fr> wrote: >> Can you just tell me a bit more :) >> >> Le 2/12/14 08:45, phil(a)highoctane.be a Ã©crit : >>> I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 >>> >>> See: >>> >>> http://www.smalltalkhub.com/#!/~philippeback/GetOpt <http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt> >>> >>> Nice tool even if we have some other support in CommandLineHandlers. >>> But for a quick parameters setting in your own CommandLineHandler, it is fast to use and easy to debug. >>> >>> Phil >

Dec. 3, 2014

Re: [Pharo-dev] class variable slots?

by Marcus Denker

>> > > One we did for Pharo4 is to use the Associations of Globals to model these variables as meta-objects (in the same spirit as the Slot objects). > > Thos means that > -> there is an Api to get them > -> they have an API to read /write > > This is just âsugarâ on what the associations did already: > > global := SmalltalkImage classVariableNamed: #CompilerClass. > global read. > global class > ==> ClassVariable > Having objects for concepts like this allows of course to leverage the power of the toolsâ¦ e.g. this adds an inspect pane that shows all users of variables: 14562 add a Users tab to GTInspector for Slots and LiteralVariables https://pharo.fogbugz.com/f/cases/14562

Dec. 3, 2014

[pharo-project/pharo-core] bc3f9f: 40396

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: bc3f9f3572b81f74918cf66da2981dc2ed9e2a26 https://github.com/pharo-project/pharo-core/commit/bc3f9f3572b81f74918cf66d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-03 (Wed, 03 Dec 2014) Changed paths: A AST-Interpreter-Test.package/InterpreterTest.class/class/testing/isAbstract.st A KernelTests.package/BooleanTest.class/instance/tests instance creation/testNew.st R KernelTests.package/BooleanTest.class/instance/tests/testBooleanNew.st R KernelTests.package/BooleanTest.class/instance/tests/testNew.st A KernelTests.package/FalseTest.class/instance/tests controlling/testAnd.st A KernelTests.package/FalseTest.class/instance/tests controlling/testIfFalse.st A KernelTests.package/FalseTest.class/instance/tests controlling/testIfFalseIfTrue.st A KernelTests.package/FalseTest.class/instance/tests controlling/testIfTrue.st A KernelTests.package/FalseTest.class/instance/tests controlling/testIfTrueIfFalse.st A KernelTests.package/FalseTest.class/instance/tests controlling/testOr.st A KernelTests.package/FalseTest.class/instance/tests converting/testAsBit.st A KernelTests.package/FalseTest.class/instance/tests instance creation/testNew.st A KernelTests.package/FalseTest.class/instance/tests logical operations/testAND.st A KernelTests.package/FalseTest.class/instance/tests logical operations/testNot.st A KernelTests.package/FalseTest.class/instance/tests logical operations/testOR.st A KernelTests.package/FalseTest.class/instance/tests logical operations/testXor.st A KernelTests.package/FalseTest.class/instance/tests printing/testPrintOn.st R KernelTests.package/FalseTest.class/instance/tests/testAND.st R KernelTests.package/FalseTest.class/instance/tests/testAnd.st R KernelTests.package/FalseTest.class/instance/tests/testAsBit.st R KernelTests.package/FalseTest.class/instance/tests/testIfFalse.st R KernelTests.package/FalseTest.class/instance/tests/testIfFalseIfTrue.st R KernelTests.package/FalseTest.class/instance/tests/testIfTrue.st R KernelTests.package/FalseTest.class/instance/tests/testIfTrueIfFalse.st R KernelTests.package/FalseTest.class/instance/tests/testNew.st R KernelTests.package/FalseTest.class/instance/tests/testNot.st R KernelTests.package/FalseTest.class/instance/tests/testOR.st R KernelTests.package/FalseTest.class/instance/tests/testOr.st R KernelTests.package/FalseTest.class/instance/tests/testPrintOn.st R KernelTests.package/FalseTest.class/instance/tests/testXor.st R KernelTests.package/TrueTest.class/instance/testing/testAND.st R KernelTests.package/TrueTest.class/instance/testing/testAsBit.st R KernelTests.package/TrueTest.class/instance/testing/testNew.st R KernelTests.package/TrueTest.class/instance/testing/testNot.st R KernelTests.package/TrueTest.class/instance/testing/testPrintOn.st R KernelTests.package/TrueTest.class/instance/testing/testXor.st A KernelTests.package/TrueTest.class/instance/tests controlling/testAnd.st A KernelTests.package/TrueTest.class/instance/tests controlling/testIfFalse.st A KernelTests.package/TrueTest.class/instance/tests controlling/testIfFalseIfTrue.st A KernelTests.package/TrueTest.class/instance/tests controlling/testIfTrue.st A KernelTests.package/TrueTest.class/instance/tests controlling/testIfTrueIfFalse.st A KernelTests.package/TrueTest.class/instance/tests controlling/testOr.st A KernelTests.package/TrueTest.class/instance/tests converting/testAsBit.st A KernelTests.package/TrueTest.class/instance/tests instance creation/testNew.st A KernelTests.package/TrueTest.class/instance/tests logical operations/testAND.st A KernelTests.package/TrueTest.class/instance/tests logical operations/testNot.st A KernelTests.package/TrueTest.class/instance/tests logical operations/testOR.st A KernelTests.package/TrueTest.class/instance/tests logical operations/testXor.st A KernelTests.package/TrueTest.class/instance/tests printing/testPrintOn.st M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/morphic ui/packageIcon_.st A MonticelloGUI.package/extension/ThemeIcons/instance/newerPackagesAvailableIcon.st A MonticelloGUI.package/extension/ThemeIcons/instance/newerPackagesAvailableIconContents.st A NautilusRefactoring.package/extension/TClassDescription/instance/renameMethodAllItem_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script396.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40396.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Traits.package/TClassDescription.class/instance/as yet unclassified/renameMethodAllItem_.st Log Message: ----------- 40396 12810 Examine TrueTest and FalseTest for the possibility of a common superclass https://pharo.fogbugz.com/f/cases/12810 14558 Monticello icon tools should indicate newer available package versions https://pharo.fogbugz.com/f/cases/14558 14557 Failign test: #testUnCategorizedMethods https://pharo.fogbugz.com/f/cases/14557 14560 InterpreterTest isAbstract should return true as it is abstract (without tests) https://pharo.fogbugz.com/f/cases/14560 http://files.pharo.org/image/40/40396.zip

Dec. 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40396 Home: https://github.com/pharo-project/pharo-core

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Yuriy Tymchuk

> On 03 Dec 2014, at 08:18, stepharo <stepharo(a)free.fr> wrote: > > Guille did a first attempt to add external resources to Monticello. interested people should contact him (now he cannot work on it since he should finish his PhD). > While I think that moving to use git is important we should also consider that we should not put all the eggs in the same basket > and that the design decision of our solution should be able to not systematically rely on git. Well, in my opinion Pharo have to understand a concept of âversioning systemâ and then there should be different drivers for each system. Instead Pharo understands Monticello and we are writing drivers to convert Monticello things into other versioning systems (git at the moment). Again, Iâm not criticizing, but Luc asked about cons, so Iâm pointing them out: âwe are not there yetâ. Uko > > Stef > >

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Yuriy Tymchuk

> On 03 Dec 2014, at 04:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Dec 2, 2014 at 11:41 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > > > On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > Le 02/12/2014 17:13, Yuriy Tymchuk a Ã©crit : > >> Hi Luc, > >> > >> most of these problems are solved by gitfiletree by Goubier Thierry. > >> It automatically commits the thing that you commit with Monticello, > >> it allows you to push, and it shows you the history (sometimes a bit > >> screwed, but good enough). ConfigurationOf works with GitHub > >> projects, but I think there is also something in a new Metacello that > >> I donât know about. > > > > If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually). > > > >> Big con is that you essentially communicate with git through > >> Monticello. And to doing advanced stuff, like a lot of branching, > >> pull requests and so on, gives an impression that you are always > >> hacking something. > > > > I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it. > > My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it backâ¦ But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features. Imagine if you could see a method blame from inside Pharo. > > So *implement* it. At least in Monticello *you* can make a change and have it spread through the entire Squeak/Pharo community very quickly. You can't do that with git. Your criticisms of git+Monticello don't hold up in pure Monticello. Yes, true, but Monticello can be missing versions, and I donât want to work with not reliable data. > > > > > >> If you want to really work with git, you want to be able to have only > >> git versions of your code, stage and commit certain changes, > >> communicate with remote repos, and if something goes wrong talk to > >> command line and deal with file-based pharo representation. But > >> instead of this you have one more screen of Monticello + nasty > >> metadata which complicates merging. > > > > You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it. > > Yes, but my main point is what when I merge, I donât care about monticello dataâ¦ I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking. > > Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do. For me one of the worst problems is that Monticello remains the bag of zips. I can throw away some zips and it will not complain. What kind of history is that? Oh yes, there are no branches, which again can be implemented, but Iâd rather use something maintained by other people. Uko > > > [and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much]. > > > > Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones. > > Uko > > > > > Thierry > > > >> Uko > >> > >>> On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> > >>> wrote: > >>> > >>> Hi, > >>> > >>> I continue the discussion here because I really would like to know > >>> the cons of using Git + Pharo. From kilon's video (thx) and the > >>> discussion that followed, I have the following questions about > >>> possible drawbacks of Git+Pharo: > >>> > >>> - The most important point to me is: does ConfigurationOf work > >>> correctly with a repo on GitHub for example? any example > >>> somewhere? > >>> > >>> - we should go to command line to commit/update but that could be > >>> saved with what has been done by Dale in tODE (shell integration, > >>> UI to commit, push/pull) IIUC. right? > >>> > >>> - Merging could be harder because it would rely on git tools? > >>> > >>> - opening a filetree repo in MC does not show the latest content > >>> since it is the local git repo that may not be in sync with the > >>> remote one => you should first pull the repo > >>> > >>> Thx for enlightening me, > >>> > >>> #Luc > >> > >> > >> > > > > > > > > > > -- > best, > Eliot

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by phil＠highoctane.be

On Wed, Dec 3, 2014 at 8:48 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Wed, Dec 3, 2014 at 7:25 AM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> >> >> 2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >>> Yes, but *I* care about the Monticello metadata. IMO its *better* than >>> the git metadata. >>> >> >> Eliot, you'll have to do better than just IMO on that one. >> >> Some of us work with *both*, and have code for going back and forth, so >> the *better*; bah. >> > > The main issue I have (and I love MCZ to transfer projects around, it is > super easy, especially to patch a running box without fuss). > > Now, the key problem are resource files. I am working on webapps, and you > get javascript, assets (images, css, svgs, mo files, and, in the current > project, other languages running the backend). > It is just a pain to maintain mczs on one side and assets on another one > and keeping it all in sync. > > So, the workflow is to save with filetree:// to have it all, but still > keep and eye on the package-cache/ to pick mczs as needed. > > One important thing to note is that Monticello saves a new mcz with a nice > author+number on each save where filetree:// writes over what is there. So, > if one isn't careful, it is easy to overwrite. > Mczs have saved my butt once or twice here. Kind of a backup mechanism. > > With Mczs, there is also this feeling of being closer to the versions as > they are just there in the environment. > > Both tools have value, and the discussion shouldn't be on what replaces > what, but on how to best complement each other. > > For the record, I use Thierry's merge driver and it makes things smoother. > It took me a while before installing that. And after a couple months of > solid git usage, I am still learning. That's a pain even if the result is > nice. > > FWIW, I have been using a cool command line tool for most of my git work > on servers: tig > http://jonas.nitro.dk/tig/ (runs on ubuntu without problems, has some > conflict with bash-completion on CentOS 6.5 but you can install). > > Try it with: > > tig show > > or > > tig status > > The keybindings are like vim (so: q will get you out of most screens). > > You do a tig status and use 'u' to stage/unstage along with j/k to move > around (or arrows). > > d will give you the diff view, which you can exit with q > > This is the kind of tool we could bring into Pharo and, while not > replacing Monticello, it would complement it magnificently. > Little article on tig: http://blogs.atlassian.com/2013/05/git-tig/ > > Phil > > >> I also happens to know how long it takes to parse hundreds of monticello >> metadata files... and I wasn't impressed with the result. >> >> >>> What's really lacking in Monticello is a) it's not high school so one >>> can't preen in front of the world on github and b) it has no support for >>> external files. Well, a) will be solved by growing up and b) can be solved >>> by building the solution. I know what I'd rather do. >>> >>> >>> [and apologies for being deliberately incendiary but I *hate* the >>> movement away from tools in Squeak/Pharo. It is a movement towards stasis >>> and death, and personally I'm enjoying life too much]. >>> >> >> You then have noticed that those threads are about working on tools? >> >> Thierry >> >> >> >> >

Dec. 3, 2014