- Pharo-users - lists.pharo.org

Re: [Pharo-users] RESTful API with Pharo with Gemstones

by Sebastian Heidbrink

Am 23.06.2015 um 11:40 schrieb sergio_101: > I have been a project coming up that I really onlyneed a restful API on. > > The front end will be first built on a mobile device(iOS )then back > on possibly android, with a very stripped down web application. > > i would like to use pharo/gemstones as the database. > > is there a project out there that allows for such restful API > development in pharo land? This would be so fun! > > thanks I am not so sure what you mean exactly but this is my stack. I use pure Zinc-REST on the Gemstone side and the REST API is described in Swagger-Spec from within Gmestone. Clients are VBA, Amber and Pharo and they utilize the Swagger API spec to access the server. Works pretty well and is much more preformant than the intial Pharo MongoDB backend I initially used. Have a look into http://smalltalkhub.com/#!/~HeSe/Swagger-Spec There you can find most of the needed Swagger implementation some minor details like type constants are missing. Once your Gemstoneserver knows how to host his Swagger-Spec you can host it via https://github.com/swagger-api/swagger-ui This saves a lot of explaning time to client developers. Sebastian

June 23, 2015

RESTful API with Pharo with Gemstones

by sergio_101

I have been a project coming up that I really onlyneed a restful API on. The front end will be first built on a mobile device(iOS )then back on possibly android, with a very stripped down web application. i would like to use pharo/gemstones as the database. is there a project out there that allows for such restful API development in pharo land? This would be so fun! thanks

June 23, 2015

Re: [Pharo-users] Any YAML parser?

by Julien Delplanque

Oh thanks! I'll search through this web site next time before asking :)... On 22/06/15 01:50, Peter UhnÃ¡k wrote: > I suggest using http://forum.world.st/ for searching through mailing lists; > using Google is often hit-or-miss (which even with all its neural networks > and tracking me everywhere is still after years suggesting Pharaoh...) > > Anyway, there seems to be something > http://forum.world.st/PetitYAML-td4803677.html > > If you are not familiar with PetitParser, there's a chapter about it in > PBE2 ( > http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/PetitParser.… > ) > > Peter > > On Sat, Jun 20, 2015 at 4:10 PM, Julien Delplanque <julien(a)tamere.eu> wrote: > >> Hi everybody, >> >> I googled a bit for a YAML parser in Pharo but I didn't found anything. >> >> Does anybody wrote a YAML parser for Pharo? >> >> Regards, >> Julien >> >>

June 23, 2015

Re: [Pharo-users] Roasal: Putting a white background instead of a transparent one in word clouds

by Alexandre Bergel

Done! Sorry for taking so long before actingâ¦ Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Apr 17, 2015, at 5:56 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > There is any other way I can help with debugging this? Should I open a bug report to get this solved on Roassal? > This is best directed at Alex, but I would think that the solution should be pretty straight forward (maybe just copying part of the solution between the exporters). > > Alex: could you please rename DCTRCanvasExporter to TRCanvasExporter? Or whatever you fancy, but without the DC prefix. This was mentioned before by Jan but probably got lost somewhere. > > Peter

June 23, 2015

Re: [Pharo-users] Roasal: Putting a white background instead of a transparent one in word clouds

by Alexandre Bergel

Hi Jan! Sorry to replied so lately. I have renamed DCTRCanvasExporter into RTCanvasExporter. As you said, it works essentially on Trachel for now. However, I suspect this will change. You often want to particularize the export (e.g., do you want to have the menu or not?) Thanks! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Apr 17, 2015, at 6:30 PM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > > Second, it's not much of a problem, but in the class name, > DCTRCanvasExporter, the "DC" letters we use to indicate it is part of our > project, DynaCASE, but since it became part of whole roassal, I think the > "DC" is not appropriate anymore there.

June 23, 2015

Re: [Pharo-users] Moose

by abdelghani ALIDRA

Ok. Thanks a lot. Abdelghani DeÂ : Tudor Girba <tudor(a)tudorgirba.com> ÃÂ : abdelghani ALIDRA <alidrandco(a)yahoo.fr> CcÂ : Any question about pharo is welcome <pharo-users(a)lists.pharo.org> EnvoyÃ© le : Mardi 23 juin 2015 13h51 ObjetÂ : Re: [Pharo-users] Moose You do not have to return anything if you do not have any information. FAMIXAssociation already does that job for you. Doru On Tue, Jun 23, 2015 at 11:42 AM, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: Thank you Tudor, Yes, it makes sence.Then I suppose that I just return nil if I dont want to display the previous and next information. Regards DeÂ : Tudor Girba <tudor(a)tudorgirba.com> ÃÂ : abdelghani ALIDRA <alidrandco(a)yahoo.fr>; Any question about pharo is welcome <pharo-users(a)lists.pharo.org> EnvoyÃ© le : Lundi 22 juin 2015 21h25 ObjetÂ : Re: [Pharo-users] Moose Hi, from/to are derived properties and they should describe the association. For example: FAMIXAccess>> from ^ self accessorÂ FAMIXAccess>> to ^ self variableÂ next/previous denote the position of the association in the code with respect to the other associations. For example, imagine this Pharo code: self doSomething.self doSomethingElse. you will get two FAMIXInvocations, and these can be linked through the previous property (next is derived). Does this make sense? Btw, these questions are better suited for the Moose mailing list:http://www.moosetechnology.org/#twitter Cheers,Doru On Mon, Jun 22, 2015 at 5:06 PM, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: Hi everybody, when working with the FAMIX meta model, one must implement the previous, next, from and to methods for each class extending FAMIXAssosiation. What is the diffence between previous/from and next/to?if I make MyFamixClass>>from^previousthe same information is displayed twice in the Moose panel (because both methods are annotated with the MSEProperty in the superclass)Who can one avoid that? Regards Abdelghani -- www.tudorgirba.com "Every thing has its own flow" -- www.tudorgirba.com "Every thing has its own flow"

June 23, 2015

Re: [Pharo-users] Moose

by Tudor Girba

You do not have to return anything if you do not have any information. FAMIXAssociation already does that job for you. Doru On Tue, Jun 23, 2015 at 11:42 AM, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: > Thank you Tudor, > > Yes, it makes sence. > Then I suppose that I just return nil if I dont want to display the > previous and next information. > > Regards > > ------------------------------ > *De :* Tudor Girba <tudor(a)tudorgirba.com> > *Ã :* abdelghani ALIDRA <alidrandco(a)yahoo.fr>; Any question about pharo > is welcome <pharo-users(a)lists.pharo.org> > *EnvoyÃ© le :* Lundi 22 juin 2015 21h25 > *Objet :* Re: [Pharo-users] Moose > > Hi, > > from/to are derived properties and they should describe the association. > For example: > > FAMIXAccess>> from > ^ self accessor > FAMIXAccess>> to > ^ self variable > > next/previous denote the position of the association in the code with > respect to the other associations. For example, imagine this Pharo code: > > self doSomething. > self doSomethingElse. > > you will get two FAMIXInvocations, and these can be linked through the > previous property (next is derived). > > Does this make sense? > > Btw, these questions are better suited for the Moose mailing list: > http://www.moosetechnology.org/#twitter > > Cheers, > Doru > > > > > > On Mon, Jun 22, 2015 at 5:06 PM, abdelghani ALIDRA <alidrandco(a)yahoo.fr> > wrote: > > Hi everybody, > > when working with the FAMIX meta model, one must implement the previous, > next, from and to methods for each class extending FAMIXAssosiation. > What is the diffence between previous/from and next/to? > if I make > MyFamixClass>>from > ^previous > the same information is displayed twice in the Moose panel (because both > methods are annotated with the MSEProperty in the superclass) > Who can one avoid that? > > Regards > > Abdelghani > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

June 23, 2015

Re: [Pharo-users] Moose

by abdelghani ALIDRA

Thank you Tudor, Yes, it makes sence.Then I suppose that I just return nil if I dont want to display the previous and next information. Regards DeÂ : Tudor Girba <tudor(a)tudorgirba.com> ÃÂ : abdelghani ALIDRA <alidrandco(a)yahoo.fr>; Any question about pharo is welcome <pharo-users(a)lists.pharo.org> EnvoyÃ© le : Lundi 22 juin 2015 21h25 ObjetÂ : Re: [Pharo-users] Moose Hi, from/to are derived properties and they should describe the association. For example: FAMIXAccess>> from ^ self accessorÂ FAMIXAccess>> to ^ self variableÂ next/previous denote the position of the association in the code with respect to the other associations. For example, imagine this Pharo code: self doSomething.self doSomethingElse. you will get two FAMIXInvocations, and these can be linked through the previous property (next is derived). Does this make sense? Btw, these questions are better suited for the Moose mailing list:http://www.moosetechnology.org/#twitter Cheers,Doru On Mon, Jun 22, 2015 at 5:06 PM, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: Hi everybody, when working with the FAMIX meta model, one must implement the previous, next, from and to methods for each class extending FAMIXAssosiation. What is the diffence between previous/from and next/to?if I make MyFamixClass>>from^previousthe same information is displayed twice in the Moose panel (because both methods are annotated with the MSEProperty in the superclass)Who can one avoid that? Regards Abdelghani -- www.tudorgirba.com "Every thing has its own flow"

June 23, 2015

Re: [Pharo-users] Environment-independent styler?

by Martin Dias

On Mon, Jun 22, 2015 at 3:30 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > My 2 cents: > > we need a diff model. Because for now there is TextDiffBuilder which > âdiffsâ text by lines i.e. bad granularity, and there is a DiffMorph that > produces nice diffs but itâs hard to reuse it in other contexts. > +1 > > Uko > > > > On 22 Jun 2015, at 15:18, Martin Dias <tinchodias(a)gmail.com> wrote: > > After debugging a bit and discovering the mess around... I think the best > decision is to first migrate the DiffMorph to the new text widget, and then > see... > > MartÃn > > > > > On Mon, Jun 22, 2015 at 9:53 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2015-06-22 9:11 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> >>> > On 17 Jun 2015, at 18:54, Martin Dias <tinchodias(a)gmail.com> wrote: >>> > >>> > Hello, >>> > >>> > Suppose that you want to show the diff between the source code of two >>> methods. In the case that both methods are in the same class, and that such >>> class is present in the system, then no problem: In a DiffModel, one can >>> set a context to the smalltalk syntax styler and get a nice output. >>> > >>> > DiffModel new >>> > leftText: (Point >> #x) sourceCode; >>> > rightText: (Point >> #y) sourceCode; >>> > contextClass: Point; >>> > openWithSpec. >>> > >>> > <Screen Shot 2015-06-17 at 18.33.22.png> >>> > >>> > But what happens in the case that the class does not exist in the >>> system? >>> > >>> > If one doesn't set any context to the styler, then the string will be >>> shown all in black, which is not nice. A partial solution could be to set >>> Object as a context, then the styler will color the code, but instance >>> variables are in red: >>> > >>> > DiffModel new >>> > leftText: (Point >> #x) sourceCode; >>> > rightText: (Point >> #y) sourceCode; >>> > contextClass: Object; >>> > openWithSpec. >>> > >>> > <Screen Shot 2015-06-17 at 18.33.27.png> >>> > >>> > Which is also not nice. In my opinion, there should be a styler that >>> just colors the code following the syntax, without checking if the >>> variables or classes are present in the system. It would be an >>> environment-independent styler. >>> > >>> > What do you recommend to implement this? I guess it should be easy to >>> subclass SHTextStylerST80 and override some methods to do not check >>> anything in the environment. >>> > >>> > What's your opinion? >>> > >>> >>> Right now we have the problem that we have 3 Stylersâ¦ (for the old text >>> model one based on Shout, one AST, and one for TxText based on the AST. Ah, >>> and Rubric subclasses the >>> shout one, too. Which means 4. >>> >>> One question is: could a styler fall back onto a being environment >>> independent as soon as the environment is not set? >>> >> >> Yes. With a bit of ternary logic which says that symbols are in three >> states: defined, undefined and unknown. First two require a context; third >> one applies if you don't have a context. >> >> Thierry >> > > >

June 23, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Ben Coman

On Tue, Jun 23, 2015 at 6:13 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Thank you all for your answers (For whatever reason all replies by Torsten > to this thread ended up as separate threads.. maybe mail client issues?) > > It seems that <sample> is then the go-to naming for now. I also like that > the word starts differently so it's easy to differentiate them at a glance. We should also see what Doru comes up with. > > > On Mon, Jun 22, 2015 at 5:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> It is important to note that these methods COULD BUT >> MUST NOT RETURN an instance. Usually such a method is only there to >> demonstrate code. > > > I'm not sure I understand the purpose of this restriction. For example > BorderedMorph>>exampleGradient could on top of opening a morph also return > the instance. > If you are running it from Nautilus it makes no difference, but when you run > it manually you could also inspect the instance, so you could further > manipulate with it... in a sense two-in-one. :) > Otherwise you would have to get it via inspecting morph halos. > > Or in another sense you could either inspect <sample> and then manually run > it, or execute <example> that would on top of that also return inspectable > value of the <sample>. > > >> 2. returning examples >> ===================== >> While some example methods just demo code and code usage (like "Job >> example" or "BorderedMorph exampleGradient") >> a subset of them directly return an instance of the method defining >> class (like LabelMorph>>example). >> >> The idea of the GT Tools is to call these methods and display the return >> value as inspectable "instances" in the tools, >> so for instance if you inspect class VirtualMachine or Character you get >> a tab entitled "E.g." where you can click on >> these sample instances. >> >> GT and (because GT )now latest Pharo currently still uses "gtExample" >> method prefix or <gtExample> pragma to mark such methods and there >> is also to wish to remove the "gt" prefix. But with this we would have a >> clash with the other "exampleXXX" usage. >> >> => I would propose to mark the code examples that return an instance >> with an <exemplar> method. >> >> According to Google definition of <exemplar> noun - "a person or >> thing serving as a typical example or excellent model." > > >> >> Urban dictionary defines <exemplar> as "a typical or standard model >> or specimen" > > > As a side note... I think it's best to use urban dictionary for slang, and > not Pharo dev. :) Looking up the name of it there shows at least a bit of > self-reflection. :) Good idea, but even this can be misleading and the usual wiki concerns with apply. While (b) seems reasonable, (a) and (c) are very suspect. Note the author "placefake." http://www.urbandictionary.com/define.php?term=exemplar (a) the mythical task occupying any computer technician, preferably employed by a university or other educational institute, for their summer months of 'down time.' (b) a typical or standard model or specimen: (i.e. and example. just said with a really dorky 15th century word.) (c) any action performed by don swanner. by placefakeJune 04, 2010 cheers -ben

June 23, 2015