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

Re: [Pharo-dev] Duration year

by Sean P. DeNigris

Esteban A. Maringolo wrote > Ej, which one of the followings is OK? > '2012-02-29' asDate + 1 year "=> 2013-02-28" > '2011-03-01' asDate + 1 year "=> 2012-02-29" One solution (just ignore the source ha ha) - http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110… ----- Cheers, Sean -- View this message in context: http://forum.world.st/Duration-year-tp4791727p4793656.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Denis Kudriashov

2014-12-02 12:22 GMT+03:00 kilon alios <kilon.alios(a)gmail.com>: > True ? Smalltalk cannot even begin to compete with the tools and library > support of these two behemoths programming languages. Just for few cents. If you group this million tools by logical functionality I'm sure it will be much less then smalltalk systems have. Most tools just repeat each other. And you know most smalltalk development tools are absent in other systems. And every year when I read ESUG presentations I see another batch of new tools. I'm not see such progress in another languages.

Dec. 2, 2014

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

by Yuriy Tymchuk

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. 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. 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. Uko > On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse(a)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

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by phil＠highoctane.be

On Tue, Dec 2, 2014 at 4:55 PM, Ben Coman <btc(a)openinworld.com> wrote: > phil(a)highoctane.be wrote: > >> On Tue, Dec 2, 2014 at 4:30 PM, Ben Coman <btc(a)openinworld.com <mailto: >> btc(a)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? > Oh, that, yeah it is full of customer code, so no way. But I like to use protocols to organise things and do lookups using that. So I do not have complicated tables to maintain not pragmas to put around. so: (activate) for the main activate along with some self hasOption:#debug ifTrue: [ self beDebug ] ifFalse: [self beNormal] option to trigger console logging in order to see what's going on in the process. I've put a logCall here and there with self log: thisContext receiver so I can see what's going on. This thing is triggered by the beDebug. Some NonInteractiveTranscript install as well. that looks in the following prototcol (activate commands) activateAbc activateDef And the class side does its thing with isResponsibleFor: activateAbc will ask for Abc in the (actions) protocol Abc will call GetOpt to read the parms of the command. The some logic and exits. The self exit things are streamlined (more of a pattern than a mechanism). ... Once this was done, I added a ton of commands in no time and they all look like the same "way of doing things". HTH Phil > cheers -ben > > > >

Dec. 2, 2014

Monticello repository-browser not emphasizing packages with newer versions.

by Ben Coman

Hi Torsten, I really like the icons you added to Monticello https://pharo.fogbugz.com/default.asp?14451 however one thing I notice that seems lacking is indication of which packages have newer versions available. When clicking on a package on the left, on the right versions that are newer are shown in bold. It used to be that the corresponding packages on the left would also be bold, but now it does not. Do you have any ideas on how we can get bolded packages back in the left pane? cheers -ben

Dec. 2, 2014

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