May 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Versionner: Specifying un-configured packages as dependencies

by Arturo Zambrano

Sorry, SSO is a Group in ConfigurationOfZincHTTPComponent. I got confused as I didn't know about groups. Please ignore my previous email, I just need to make my project depend on Zinc SSO group On Sat, May 24, 2014 at 10:58 PM, Arturo Zambrano <arturo.zambrano(a)gmail.com > wrote: > I think I'm now at the same point... I need to add Zinc-SSO as a > dependency. > Should I create a configuration for it? Where should it be stored? > > thanks > > > On Thu, May 22, 2014 at 1:55 PM, stepharo <stepharo(a)free.fr> wrote: > >> + 100 >> >> The reason is that any package* should be self described. Your >> configuration describes your project. If you use another piece of software, >> it should also be self-described. >> Let's take the following example: >> >> - for now, it's easy for you to add a direct dependency >> to Roassal2Spec, just as if it was a part of your project ... => no problem >> - ... but it is not. Maybe tomorrow, Alex will need to add a >> dependency to one or more packages for Roassal2Spec => you will have >> problems because you will not get these dependencies. Of course, you can >> still add them to your configuration but you can easily see that you will >> end with a configuration including all flatten dependencies, and with a lot >> of dependencies not directly related to your project (transitive >> dependencies). Flatten dependencies is really something that we should >> avoid, else maintenance of dependencies will be a hell. >> >> That's why I'm really in favor of having configurations, even for one >> single MC package inside the configuration. >> >> * I mean, not a Monticello package but a piece of software that you >> want to deliver independently. It may be a whole project or part of it. It >> may also refers to one or many Monticello packages >> >> >> >

May 25, 2014

Re: [Pharo-users] Versionner: Specifying un-configured packages as dependencies

by Arturo Zambrano

I think I'm now at the same point... I need to add Zinc-SSO as a dependency. Should I create a configuration for it? Where should it be stored? thanks On Thu, May 22, 2014 at 1:55 PM, stepharo <stepharo(a)free.fr> wrote: > + 100 > > The reason is that any package* should be self described. Your > configuration describes your project. If you use another piece of software, > it should also be self-described. > Let's take the following example: > > - for now, it's easy for you to add a direct dependency > to Roassal2Spec, just as if it was a part of your project ... => no problem > - ... but it is not. Maybe tomorrow, Alex will need to add a > dependency to one or more packages for Roassal2Spec => you will have > problems because you will not get these dependencies. Of course, you can > still add them to your configuration but you can easily see that you will > end with a configuration including all flatten dependencies, and with a lot > of dependencies not directly related to your project (transitive > dependencies). Flatten dependencies is really something that we should > avoid, else maintenance of dependencies will be a hell. > > That's why I'm really in favor of having configurations, even for one > single MC package inside the configuration. > > * I mean, not a Monticello package but a piece of software that you want > to deliver independently. It may be a whole project or part of it. It may > also refers to one or many Monticello packages > > >

May 25, 2014

Re: [Pharo-users] Class definition changes in change log

by Arturo Zambrano

On Mon, May 19, 2014 at 1:49 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Also, I've wondered why it's not an error to attempt to apply a change that > creates a method on a non-existent class... > > +1 when installing code with Gofer/Monticello to non- existent class an exception is raised. seems to be reasonable to expect the same behavior when importing changes... > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Class-definition-changes-in-change-log-tp4759413p4759… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 25, 2014

Re: [Pharo-users] Class definition changes in change log

by Arturo Zambrano

thanks Stef, using it now. On Mon, May 19, 2014 at 3:35 AM, stepharo <stepharo(a)free.fr> wrote: > Hi Arturo > > May be you spot a bug, sadly. I remember that we got a problem in the past > and I thought it was fixed. > You can use Epicea the new and working change recording system developed > by Martin Dias. > > Stef > > > > On 18/5/14 14:58, Arturo Zambrano wrote: > >> Hi All, >> >> Trying to recover lost changes from another (broken) image I noticed >> that only method definition and do-it are saved. >> >> I'm in a middle of a refactoring where I changed hierarchies, renamed >> classes and inst vars. >> >> When trying to recover the changes, class name changes are not there, so >> most of the method changes are not applicable. >> >> I don't know if I am missing something important regarding how to >> recover changes. I just dragged the old changes file onto my new image and >> then browse the changes (where I can only see methods and do-its) >> >> As a work around I manually did all the class definition changes >> (superclass, class name, >> inst var names), and re run all the changes from the "Recent Changes" >> window. As a result I recovered most of the work of the last night :) >> (but I lost some time trying to figure out the problem) >> >> Is it OK that my changes file has not class definition changes? Am I >> missing sth? This is the expected behavior when recovering the changes from >> another image? >> >> >> thanks >> >> best regards >> >> arturo >> >> > >

May 25, 2014

Re: [Pharo-users] Downloading tweets

by Arturo Zambrano

Hi, I copied the relevant part of the pdf to project info in SmalltalkHub http://smalltalkhub.com/#!/~arturozambrano/TwitterRoassalPlayGround On Fri, May 23, 2014 at 3:58 PM, Arturo Zambrano <arturo.zambrano(a)gmail.com>wrote: > Hi Steph, > it is in pdf.. that's why we need more practical documentation ;-) > > Gofer new url: > 'http://smalltalkhub.com/mc/arturozambrano/TwitterRoassalPlayGround/main'; > package: 'TwitterÂConnection'; > load. > > > there are other packages but they are other parts of our twitter thing, I > think they are not useful for the community. > > best regards > > > > > > On Fri, May 23, 2014 at 3:45 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hello Arturo >> >> nice to see you more and more on this list :). >> Where is the code? >> So that we can advertize it >> >> Stef >> >> >> On 23/5/14 03:39, Arturo Zambrano wrote: >> >>> Hi All, >>> you can now download some code for downloading tweets using REST and >>> Streaming Twitter APIs. >>> It is far from complete but do the job we need for now. >>> >>> Besides tweets downloading you can also: >>> - get users information. >>> - retrieve the profile picture of users. >>> - ask for the relationship of the two users >>> >>> Please find attached some info regarding dependencies (no metacello >>> config for now), and manual login procedure for the first time you connect >>> to twitter. >>> >>> >>> We will work on tests, completion and more practical documentation soon. >>> At the same time, when the visualization part of our Twitter thing is >>> ready, we will communicate it. >>> >>> Thanks Rosario for her help, and Sven for advice on the streaming >>> feature of Zinc. >>> >>> regards >>> art >>> >> >> >> >

May 24, 2014

MNU PREyeInspector>>elements for PRDocument with EyeTreeInspector

by Ben Coman

I was looking at PRAnnotatedParagraphTest>>testParseBasic and Inspected the result of the following... | wiki text tree | wiki := '@@foo bar zork'. text := 'bar zork'. tree := PRDocument new add: (PRAnnotatedParagraph new annotation: 'foo'; add: (PRText content: 'bar zork'); yourself); yourself. The Inspector comes up okay using PREyeItemInspector to show PRDocument. However when I change to EyeTreeInspector I get the error "MNU: PREyeItemInspector>>elements" I tried digging into this but its beyond my current understanding. In particular, PREyeInspector seems to have two potential sources of elements: * ivar /tree/ holding a TreeModel that might return roots and/or children * ivar /object/ holding a NewValueHolder holding a PRDocument that might return its children. Is there somewhere I should log a case for Pillar? cheers -ben

May 24, 2014

Re: [Pharo-users] deep into pharo(esug 2013) translate to korean draft version.

by peter yoo

I'm going to publish korean translation of Deep Into Pharo on my blog. Translation progress is all done and now I'm checking the translated document before I publish. It would be honor to me if you would like to put a URL link to my korean translation of Deep Into Pharo on your website. The URL of translated document is here http://ta.onionmixer.net/wordpress/?attachment_id=265 â For now, I'm publishing it on wordpress blog. If you need any additional information, always welcome.

May 24, 2014

Re: [Pharo-users] deep into pharo(esug 2013) translate to korean draft version.

by Damien Cassou

On Fri, May 23, 2014 at 5:42 PM, peter yoo <onionmixer(a)gmail.com> wrote: > hm.... really? can then i want. but really ok? sorry, I don't understand. I propose to add an url to your document on our website. If you are interested, no problem. Even if your translation is work in progress. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 24, 2014

Re: [Pharo-users] [smallwiki] Pillar annotations for Latex

by Damien Cassou

On Sat, May 24, 2014 at 10:51 AM, Ben Coman <btc(a)openinworld.com> wrote: > 'dothis' = anAnnotatedParagraph annotation asLowercase > ifTrue: > [ canvas newLine. "<----THIS LINE ADDED" > > ^ canvas command > name: 'dothis' ; > parameter: [ super visitAnnotatedParagraph: > anAnnotatedParagraph ] > ]. > > which seems better, but maybe still not the best. that's the right way I guess, thank you for your contribution. Please add related unit tests. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 24, 2014

Re: [Pharo-users] [smallwiki] Pillar annotations for Latex

by stepharo

Really nice! > > @@note Pay attention to the class definition for your new > ""==BlankCellTest=="". It must be a subclass of the class > ""==TestCase=="". This is easy to overlook. If you did it wrong > already, no problem, just go back and correct it now and then save the > code again. > > Within a class, methods are organised into "protocols" that are shown > in the third browser pane from the left of Figure > *testCellStateShouldBeOffEmpty*. We will group our "tests" inside a > protocol of the same name. > > to produce this nice looking PDF showing the note indented with > dividing lines... > > > > Now that was real easy to do!! Thanks for making Pillar accessible. I > can't imagine making a similar change as easy in a Markdown processor > in some other language. :)

May 24, 2014