- Pharo-dev - lists.pharo.org

Pharo+Git cons?

by Luc Fabresse

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

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by phil＠highoctane.be

On Tue, Dec 2, 2014 at 4:42 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Coral is currently broken because I didn't maintain it through the > pharo releases (the current CommandLine stuff is more or less > extracted from it). However, the option-parsers part should still be > OK, it's the hooking at image startup that is not up to date. > For me the leverage is coming from the ability to declare classes in a file and use them. A lÃ GST. Can't we have that? Coral is interestingly engineered but what good does it gives if we cannot use it? Maybe a Coral-light would be way sufficient as a part we can hook into the system. Like you see in the ScriptRunner of Guille in Scale. Turn bits of Coral into the ScriptRunner and we can go a long way (and in a lot of places, including sending scripts around through whatever servers). Phil > > There were/are multiple goals : > > - make a text-file friendly syntax for code, to make it possible to > quickly put some logic in a file with #!/usr/bin/env pharo at the top > to run it as any other shell command. Obviously this has some overlap > with filetree. > > - provide a framework to declare commands in a convenient way (with > automatic --help documentation, completion helpers for shells, etc). > This is using PetitParser to analyse the arguments list, and provides > off-the-shelf parsers for the common patterns -x -aBc --long-option > --foo=value. > > IMHO getopt could be nice for the VM options, but for scripts it's > really procedural and string-oriented, at least for the > implementations I have some experience with (ruby, shell). For any > real script, you want something higher-level, like http://docopt.org > > There is also a problem specific to us : a given image can have many > command line handlers installed, so there needs to be some dispatch / > priority resolution to make the composition work. > > > On 2 December 2014 at 11:24, Torsten Bergmann <astares(a)gmx.de> wrote: > >>Combined with a small image, it would be a terrific tool. > > > > That was/is the goal of Coral. http://rmod.lille.inria.fr/coral/ > > > > Dont know about its current state. > > > > Thx > > T. > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > >

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by Ben Coman

phil(a)highoctane.be wrote: > On Tue, Dec 2, 2014 at 4:30 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: > > > > > On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com> > <mailto:sean@clipperadams.com <mailto:sean@clipperadams.com>>__> > wrote: > > EstebanLM wrote > > is cool. > > I would like to explore the possibility to replace our > command > line parser > > with getopt. You knowâ¦ is more compatible at the end :) > > I find the implementation of our command line handlers very > confusing. It > seems like it grew organically from a smaller idea and the > design > got out of > control. There are many assumptions that can make it hard to > extend, > especially to combine multiple options, as Ben and I > discovered when > implementing the "don't run startup scripts" handler. It > would be > nice to > revisit starting from a behavioral specification. > > > Well, what makes you say that? > The core CommandLineHandler itself is pretty generic and can do > a lot of things. > > Then, yeah, what is under is quite varied. But that's to be > expected when trying out "new tech". > > I've been making one of my own here for a given project with > about 20-30 commands and I had to put in some structure indeed. > > > Is that part available somewhere that can be reviewed ? > > > You mean? > > CommandLineHandler and CommandLineArguments is in the base image. > No, I meant.. "I had to put in some structure indeed" or is it too application specific? cheers -ben

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by Damien Pollet

Coral is currently broken because I didn't maintain it through the pharo releases (the current CommandLine stuff is more or less extracted from it). However, the option-parsers part should still be OK, it's the hooking at image startup that is not up to date. There were/are multiple goals : - make a text-file friendly syntax for code, to make it possible to quickly put some logic in a file with #!/usr/bin/env pharo at the top to run it as any other shell command. Obviously this has some overlap with filetree. - provide a framework to declare commands in a convenient way (with automatic --help documentation, completion helpers for shells, etc). This is using PetitParser to analyse the arguments list, and provides off-the-shelf parsers for the common patterns -x -aBc --long-option --foo=value. IMHO getopt could be nice for the VM options, but for scripts it's really procedural and string-oriented, at least for the implementations I have some experience with (ruby, shell). For any real script, you want something higher-level, like http://docopt.org There is also a problem specific to us : a given image can have many command line handlers installed, so there needs to be some dispatch / priority resolution to make the composition work. On 2 December 2014 at 11:24, Torsten Bergmann <astares(a)gmx.de> wrote: >>Combined with a small image, it would be a terrific tool. > > That was/is the goal of Coral. http://rmod.lille.inria.fr/coral/ > > Dont know about its current state. > > Thx > T. > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by phil＠highoctane.be

On Tue, Dec 2, 2014 at 4:30 PM, Ben Coman <btc(a)openinworld.com> wrote: > phil(a)highoctane.be wrote: > >> >> >> >> On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <sean(a)clipperadams.com >> <mailto:sean@clipperadams.com>> wrote: >> >> EstebanLM wrote >> > is cool. >> > I would like to explore the possibility to replace our command >> line parser >> > with getopt. You knowâ¦ is more compatible at the end :) >> >> I find the implementation of our command line handlers very >> confusing. It >> seems like it grew organically from a smaller idea and the design >> got out of >> control. There are many assumptions that can make it hard to extend, >> especially to combine multiple options, as Ben and I discovered when >> implementing the "don't run startup scripts" handler. It would be >> nice to >> revisit starting from a behavioral specification. >> >> >> Well, what makes you say that? >> The core CommandLineHandler itself is pretty generic and can do a lot of >> things. >> >> Then, yeah, what is under is quite varied. But that's to be expected when >> trying out "new tech". >> >> I've been making one of my own here for a given project with about 20-30 >> commands and I had to put in some structure indeed. >> > > Is that part available somewhere that can be reviewed ? > You mean? CommandLineHandler and CommandLineArguments is in the base image. Phil > cheers -ben > > >

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by Ben Coman

phil(a)highoctane.be wrote: > > > > > On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> wrote: > > EstebanLM wrote > > is cool. > > I would like to explore the possibility to replace our command > line parser > > with getopt. You knowâ¦ is more compatible at the end :) > > I find the implementation of our command line handlers very > confusing. It > seems like it grew organically from a smaller idea and the design > got out of > control. There are many assumptions that can make it hard to extend, > especially to combine multiple options, as Ben and I discovered when > implementing the "don't run startup scripts" handler. It would be > nice to > revisit starting from a behavioral specification. > > > Well, what makes you say that? > The core CommandLineHandler itself is pretty generic and can do a lot of > things. > > Then, yeah, what is under is quite varied. But that's to be expected > when trying out "new tech". > > I've been making one of my own here for a given project with about 20-30 > commands and I had to put in some structure indeed. Is that part available somewhere that can be reviewed ? cheers -ben

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by phil＠highoctane.be

On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > EstebanLM wrote > > is cool. > > I would like to explore the possibility to replace our command line > parser > > with getopt. You knowâ¦ is more compatible at the end :) > > I find the implementation of our command line handlers very confusing. It > seems like it grew organically from a smaller idea and the design got out > of > control. There are many assumptions that can make it hard to extend, > especially to combine multiple options, as Ben and I discovered when > implementing the "don't run startup scripts" handler. It would be nice to > revisit starting from a behavioral specification. > Well, what makes you say that? The core CommandLineHandler itself is pretty generic and can do a lot of things. Then, yeah, what is under is quite varied. But that's to be expected when trying out "new tech". I've been making one of my own here for a given project with about 20-30 commands and I had to put in some structure indeed. Phil > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/GetOpt-tp4793474p4793621.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 2, 2014

12854 TestRunner>>categorySelected hard coded zero

by Ben Coman

Anyone know why TestRunner>>categorySelected was hard coded to return zero? It breaks shift-click multiple selection in TestRunner. Seems we've lived with it a long time... * Version info --> "lr 10/31/2005 15:11" btw, SystemReporter>>categorySelected method is identical * Hardcoded to return zero * Version info --> "lr 10/31/2005 15:11" maybe one class was copied to the other? cheers -ben Fix submitted... https://pharo.fogbugz.com/default.asp?12854

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by Sean P. DeNigris

EstebanLM wrote > is cool. > I would like to explore the possibility to replace our command line parser > with getopt. You knowâ¦ is more compatible at the end :) I find the implementation of our command line handlers very confusing. It seems like it grew organically from a smaller idea and the design got out of control. There are many assumptions that can make it hard to extend, especially to combine multiple options, as Ben and I discovered when implementing the "don't run startup scripts" handler. It would be nice to revisit starting from a behavioral specification. ----- Cheers, Sean -- View this message in context: http://forum.world.st/GetOpt-tp4793474p4793621.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2014

Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14

by Mariano Martinez Peck

On Tue, Dec 2, 2014 at 11:52 AM, Ben Coman <btc(a)openinworld.com> wrote: > Mariano Martinez Peck wrote: > >> >> >> On Mon, Dec 1, 2014 at 2:00 AM, <seaside(a)rmod.lille.inria.fr <mailto: >> seaside(a)rmod.lille.inria.fr>> wrote: >> >> Hi! We're sending this automatic email twice a month, to give the >> community an opportunity to easily know what's happening and to >> coordinate efforts. Just answer informally, and feel free to spawn >> discussions thereafter! >> >> ### Here's what I've been up to since the last WhatsUp: >> >> >> >> - I gave 3 Smalltalk/Pharo related presentations (Web Development with >> Smalltalk, Smalltalk and Business, and Marea) at >> http://ilas.memi.umss.edu.bo/ (sponsored by ESUG). Slides: >> >> http://www.slideshare.net/MarianoMartinezPeck/web- >> development-with-smalltalk >> > > > I am curious to learn why Seaside "scalability is a bit different" ? > The most immediate reason is that session affinity is a requirement, not an option, as with other stateless frameworks. Unless you are in GemStone, where sessions are persisted and hence session affinity is not a requirement. Another would be memory requirements. Depending on your app, if you use the statefull side of the framework a lot (#states and friends) and you do keep large graphs in there, the system itself will obviously consume more memory. So that's another thing to consider that may not be the same when dealing with stateless framworks. Maybe there were more reasons that I cannot remember now. > cheers -ben > > > http://www.slideshare.net/MarianoMartinezPeck/smalltalk-and-business >> http://www.slideshare.net/MarianoMartinezPeck/thesis- >> presentation-14987645 >> >> I hope at least to get some guys involved! >> >> >> ### What's next, until 2014-12-14 (*): >> >> >> >> Back to work and update CV. >> >> >> (*) we'll be expecting results by then ;) >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2014