February 2014 - Pharo-users

Re: [Pharo-users] Streaming API for Pharo?

by Arturo Zambrano

Thanks Sven, I will give it a try. Best regards art On Thu, Feb 13, 2014 at 4:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hello Arturo, > > On 13 Feb 2014, at 15:00, Arturo Zambrano <arturo.zambrano(a)gmail.com> > wrote: > > > Hi All, > > we are playing with Roassal for the visualization of Twitter data. > > So far we used Zn-SSO to connect to twitter and call REST API to > > get some tweets for playing. > > > > Now, we would like to use the streaming API. I could not figure out how > to > > do this with Zn-*. > > > > According to Twitter Streaming API docs: > > Some HTTP client libraries only return the response body after the > connection has been closed by the server. These clients will not work for > accessing the Streaming API. You must use an HTTP client that will return > response data incrementally > > > > I would like to know if Zn allows to get data incrementally. > Furthermore it would be great to know if there is some example where I can > start from. > > > > > > Once we have our toy working we plan to release it to the community. > > > > thanks. > > > > art > > Zinc HTTP Components is a framework that does allow you to do pretty much > everything related to HTTP. I would suggest you load the Zinc WebSockets > addon package: > > https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md > > In particular, look at ZnWebSocket class>>#to: where after an initial > request/response interaction, the actual connection used in the client is > taken and used to run a completely different protocol. I guess in your case > you would then keep on reading responses. > > But it might be simpler than that, if the server returns an actual > infinite response, you could ask for ZnClient>>#streaming: true and use the > resulting ZnStreamingResponse's contents (a stream) to keep on reading. > > Good luck and let me know how it goes, I am pretty sure we can get this > working ! > > If you can tell me how I can access such a response with my twitter > account, I can try as well. > > Sven > > > >

Feb. 16, 2014

Re: [Pharo-users] Streaming API for Pharo?

by Arturo Zambrano

thanks! I will take a look at it. art On Thu, Feb 13, 2014 at 11:48 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Arturo Zambrano wrote > > I would like to know if Zn allows to get data incrementally > > The Nabble mirror (http://forum.world.st/Pharo-f1294836.html will check > both > dev and user lists) has a great search feature. "Zinc stream" returned some > interesting results... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Streaming-API-for-Pharo-tp4743273p4743294.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 16, 2014

Re: [Pharo-users] Choosing 'Sb' as an umbrella package prefix?

by Esteban A. Maringolo

There is no solution for this other than namespacing (which is an issue in itself). If it's not a conflict now, it will be in the future. I prefix my domain classes with Ts and Gpt, so far it doesn't clash with anything else. May it ever happen, I will rant. :) Regards, Esteban A. Maringolo 2014-02-14 14:28 GMT-03:00 Michael J. Forster <mike(a)sharedlogic.ca>: > Hi, > > I have two questions regarding the choice of package prefix, but, first, > some background. > > We have a number of packages that I would like to publish as open source > on smalltalkhub.com over the coming year. As well, we have several > proprietary customer packages in our internal MC repository. Obviously, we > want to avoid name collisions with everyone else, but we want to keep our > package and class names from bloating, too. > > I'm thinking of choosing the umbrella package/class prefix 'Sb' (for the > element Antimony, shamelessly following Sven's example) for everything we > write. We would use one or two further characters to distinguish our > actual packages and classes (public and proprietary). For example, > > SbWA... - our Seaside utilities > SbPG... - our PostgresV2 utilities > SbPr... - our Prolog query engine > SbMt... - a proprietary client project > > My first question: Does this sound reasonable? I don't want to give > potential users the impression that unstated dependencies exist between our > open source 'Sb' packages. I'm simply trying to carve out a namespace. > > Second, I installed all of the packages I could using the Metacello > Configuration browser in Pharo 2.0 and collected the first three characters > of all packages and classes. I didn't find any use of the 'Sb' prefix. > Does anyone know of a conflict? > > > Thanks! > > Mike > > -- > Michael J. Forster, B.Sc. (Hons.), B.Sc. > COO, Programmer > Shared Logic Inc. > >

Feb. 14, 2014

Choosing 'Sb' as an umbrella package prefix?

by Michael J. Forster

Hi, I have two questions regarding the choice of package prefix, but, first, some background. We have a number of packages that I would like to publish as open source on smalltalkhub.com over the coming year. As well, we have several proprietary customer packages in our internal MC repository. Obviously, we want to avoid name collisions with everyone else, but we want to keep our package and class names from bloating, too. I'm thinking of choosing the umbrella package/class prefix 'Sb' (for the element Antimony, shamelessly following Sven's example) for everything we write. We would use one or two further characters to distinguish our actual packages and classes (public and proprietary). For example, SbWA... - our Seaside utilities SbPG... - our PostgresV2 utilities SbPr... - our Prolog query engine SbMt... - a proprietary client project My first question: Does this sound reasonable? I don't want to give potential users the impression that unstated dependencies exist between our open source 'Sb' packages. I'm simply trying to carve out a namespace. Second, I installed all of the packages I could using the Metacello Configuration browser in Pharo 2.0 and collected the first three characters of all packages and classes. I didn't find any use of the 'Sb' prefix. Does anyone know of a conflict? Thanks! Mike -- Michael J. Forster, B.Sc. (Hons.), B.Sc. COO, Programmer Shared Logic Inc.

Feb. 14, 2014

Re: [Pharo-users] [gsoc-mentors] Re: GSoC: call for ideas

by Alejandro Infante

Project idea Name: Instance Derreferencer for Pharo Skill level: Intermediate Possible Mentors: Name of the Student: Alejandro Infante Description: A problem with image based environment is, when you detect a memory leak is removing those objects from the system. This tool would provide a handy UI to inspect the current instances of the classes that we think they have a memory leak and, in case there are objects that are not being garbage collected, offer to the user a Derreference button. This is going to iterate over all the objects that have a reference to my object and remove that reference, finally enabling the Garbage Collector to get rid of the leak. 2014-02-14 5:08 GMT-08:00 Nicolas Petton <petton.nicolas(a)gmail.com>: > > Paolo Bonzini writes: > > > Il 11/02/2014 10:42, Damien Cassou ha scritto: > >> Hi fellow Pharo hackers, > >> > >> ESUG, the European Smalltalk User Group, is applying for this > >> year's Google Summer of Code. As you probably know, the Summer > >> of Code provides the opportunity to fund students to work during > >> the summer on Pharo. Please reply to this > >> email (be sure to use "Reply to all") if you have ideas you > >> would like to propose. > >> > >> Please include a summary of the project and links to web pages > >> that can help prospective students to write their application. > >> Please also include the following information: > >> > >> - if applicable, other dialects that you would be willing to > >> mentor this project for > >> > >> - the skill level > >> > >> - name of the mentor(s), email addresses, and possibly any IRC > >> network/channel/nickname where they can be found. > >> > >> Thanks for contributing to ESUG's Summer of Code application! > >> > > > > Just a note that I haven't yet processed this thread, but our ideas page > > is already looking pretty well (and Pharo section is big) so I'll > > probably do it in the weekend or next Monday. > > I can do it if you want. > > Cheers, > Nico > >

Feb. 14, 2014

Re: [Pharo-users] Athens question - #openInSceneView

by Igor Stasenko

On 14 February 2014 15:57, J.F. Rick <self(a)je77.com> wrote: > Incomplete, though EllipseMorph would be quite easy to implement. You > would have to implement drawOnAthensCanvas: on EllipseMorph. It is > currently just inheriting that from Morph. > > Right. > Cheers, > > Jeff > > > On Wed, Feb 12, 2014 at 10:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> If I understand correctly #openInSceneView wraps a morph in an >> Athens scene. I tried some examples: >> >> "Smalltalk ui icons configIcon asMorph openInSceneView" >> "BorderedMorph new openInSceneView" >> >> First two work, but the third: >> >> "EllipseMorph new openInSceneView" >> >> brought up a yellow morph - but as rectangle not as ellipse >> like in "EllipseMorph new openInWorld". >> >> Havent looked deeper. Incomplete or a bug? >> >> Thx >> T. >> >> >> >> >> >> >> >> > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Best regards, Igor Stasenko.

Feb. 14, 2014

Re: [Pharo-users] Improving Strings Manipulation topic

by Daniela Meneses

Hi Doru: Thank you for your reply, I will take a look to them. I'm from Bolivia. :D -- Cheers, Dani

Feb. 14, 2014

Re: [Pharo-users] Athens question - #openInSceneView

by J.F. Rick

Incomplete, though EllipseMorph would be quite easy to implement. You would have to implement drawOnAthensCanvas: on EllipseMorph. It is currently just inheriting that from Morph. Cheers, Jeff On Wed, Feb 12, 2014 at 10:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > If I understand correctly #openInSceneView wraps a morph in an > Athens scene. I tried some examples: > > "Smalltalk ui icons configIcon asMorph openInSceneView" > "BorderedMorph new openInSceneView" > > First two work, but the third: > > "EllipseMorph new openInSceneView" > > brought up a yellow morph - but as rectangle not as ellipse > like in "EllipseMorph new openInWorld". > > Havent looked deeper. Incomplete or a bug? > > Thx > T. > > > > > > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Feb. 14, 2014

Re: [Pharo-users] [gsoc-mentors] Re: GSoC: call for ideas

by Nicolas Petton

Paolo Bonzini writes: > Il 11/02/2014 10:42, Damien Cassou ha scritto: >> Hi fellow Pharo hackers, >> >> ESUG, the European Smalltalk User Group, is applying for this >> year's Google Summer of Code. As you probably know, the Summer >> of Code provides the opportunity to fund students to work during >> the summer on Pharo. Please reply to this >> email (be sure to use "Reply to all") if you have ideas you >> would like to propose. >> >> Please include a summary of the project and links to web pages >> that can help prospective students to write their application. >> Please also include the following information: >> >> - if applicable, other dialects that you would be willing to >> mentor this project for >> >> - the skill level >> >> - name of the mentor(s), email addresses, and possibly any IRC >> network/channel/nickname where they can be found. >> >> Thanks for contributing to ESUG's Summer of Code application! >> > > Just a note that I haven't yet processed this thread, but our ideas page > is already looking pretty well (and Pharo section is big) so I'll > probably do it in the weekend or next Monday. I can do it if you want. Cheers, Nico

Feb. 14, 2014

Re: [Pharo-users] [gsoc-mentors] GSoC: call for ideas

by Ronie Salgado

I am proposing the following as a student: Project idea Name: Unified Foreign Function Interface Skill level: Advanced Possible Mentors: Igor Stasenko / Esteban Lorenzano Name of the Student: Ronie Salgado Description: Because NativeBoost has problems with portability and cannot be used anywhere(iOS), one proposal is making a modular unified foreign function interface. This UFFI should support multiples backends, a portable function calls specification, portable easy to use callbacks support, and portable foreign resources management. Full Description Document: http://users.dcc.uchile.cl/~rsalgado/uffi-fourth-draft.pdf 2014-02-13 12:21 GMT-03:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Project idea > > Description: Enhance refactorings with type information > Skill level: Advance > Possible Mentors: Guillermo Polito / Esteban Lorenzano / Santiago > Bragagnolo > Name of the Student: Pablo Tesone > Keywords: tools, refactoring, code completion, type inference. > > Description: > > During the development of a program in any programming language, the IDE > has a very important role. It will never replace the knowledge of the > programmer but it can make his life easier. > As Smalltalk doesn't have explicit type information, the IDE can not > perform the same mechanisms that are present in IDE like Eclipse or > Intellij IDEA. These mechanisms can be very useful. > The idea of this project is to add type inference mechanisms to try to > provide more information to the refactoring and code completion tools. > It is important to say that the idea is not to check types or correct the > program, but to allow the programmer to have more information. > > > > On Thu, Feb 13, 2014 at 12:06 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: > >> [Anne Etien could not post this msg on the mentors list I m forwarding it >> on her behalf]. >> >> Title: FAST JavaScript model >> >> Level: advanced >> >> Possible mentor: Anne Etien >> >> Possible second mentor: Nicolas Anquetil or Yuriy Tymchuk >> >> Description: >> For in depth source code analysis a support of abstract syntax trees is >> required. FAST is an abstract syntax tree extension for FAMIX meta-model >> that is used by Moose technology. The goal of this project is to create >> a JavaScript version of FAST. >> >> Technical Details: >> As programming languages are different, their AST representations are >> different too. FAST model aims for creation of as generic as possible >> core that can be extended for different languages. Also the structure of >> a model allows creation of generic algorithms like symbol resolution, >> metrics calculation and rule checking that will work for any language. >> Prototypes of FAST for Smalltalk and Java are already implemented. >> During the project a student will implement the JavaScript model. More >> detailed information about FAST is provided in the Moose day >> presentation: http://youtu.be/dRr3WHOD3x4 >> >> Benefits to the Student: >> The student will gain a deep understanding of a JavaScript syntax and >> abstract syntax tree model. He will also learn about PetitParser >> framework, and gain knowledge about software modeling and analysis. >> >> Benefits to the Community: >> Community will get a FAST model for JavaScript that can be used for >> software assessment with Moose. Also this model can be used later in PhD >> projects such as automation of source code translation. With this third >> model, the community will have raw material to real think and improve >> generic algorithms based on AST. >> >> >> On Tue, Feb 11, 2014 at 10:42 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: >> >>> Hi fellow Pharo hackers, >>> >>> ESUG, the European Smalltalk User Group, is applying for this >>> year's Google Summer of Code. As you probably know, the Summer >>> of Code provides the opportunity to fund students to work during >>> the summer on Pharo. Please reply to this >>> email (be sure to use "Reply to all") if you have ideas you >>> would like to propose. >>> >>> Please include a summary of the project and links to web pages >>> that can help prospective students to write their application. >>> Please also include the following information: >>> >>> - if applicable, other dialects that you would be willing to >>> mentor this project for >>> >>> - the skill level >>> >>> - name of the mentor(s), email addresses, and possibly any IRC >>> network/channel/nickname where they can be found. >>> >>> Thanks for contributing to ESUG's Summer of Code application! >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." >>> Winston Churchill >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Smalltalk GSoC mentors" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to smalltalk-gsoc-mentors+unsubscribe(a)googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Smalltalk GSoC mentors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to smalltalk-gsoc-mentors+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

Feb. 13, 2014