April 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] GitHub Mirror Workflow

by Stephan Eggermont

On 08/04/15 14:38, Esteban Lorenzano wrote: > I donât know your problemâ¦ why would you want another format form mirroring? Because with packages the size of Roassal2 you might get rather unhappy on a machine without an SSD. That is a lot of files. Stephan

April 8, 2015

Re: [Pharo-users] ZnClient: getting more that 19 tweet for data scrapping

by Sven Van Caekenberghe

> On 08 Apr 2015, at 15:29, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Offray - What Sven said is correct. You're not getting an answer about how > to violate their Terms of Service because this isn't that kind of place. > You've asked 3 times. Once is usually enough. Use the API. For the Soup > questions get an inspector on an instance of a SoupTag and start sending it > messages it understands and see what you get. Trial and error. Or read the > python Soup docs as the commands probably have an equivalent in the > Smalltalk library. Most of this programming stuff is reading, doing a > little experiment, thinking, then trying again. > > Sven - I only showed him that SoupTag has a #text message. I'm sure you're > busy and had forgotten that the first time he/she asked they stated that > they don't want to use the api: > http://forum.world.st/Data-scrapping-in-pharo-Extracting-tweets-contents-td… > and provided the download code in an ws.stfx.eu snippet. Paul, I know you understand, we're on the same page. Sven > Hope this helps > > Paul > > > Sven Van Caekenberghe-2 wrote >> What Paul showed is basically just a hack. >> >> What you probably what is full API access to Twitter, that gives you the >> real thing, but it is more work and you have to understand all the >> technical details (unless somebody already did it for you, I don't know - >> I know that Zinc-SSO can connect to Twitter). >> >> https://dev.twitter.com/overview/api >> >>> On 07 Apr 2015, at 20:23, Offray Vladimir Luna CÃ¡rdenas < > >> offray@ > >> > wrote: >>> >>> Hi, >>> >>> Recently Paul DeBruicker taught me how to refine my code for getting >>> tweets properly. Consider this: >>> >>> =[1]==================================== >>> | source anUrl tweet | >>> >>> anUrl := 'https://twitter.com/offrayLC'. >>> source := Soup fromString: (ZnEasy get: anUrl ) contents asString. >>> tweets := (source findAllTagsByClass: 'ProfileTweet-text') collect:[:ea | >>> ea text]. >>> ======================================== >>> >>> Is working fine, but I would like to get more that 19 tweets, that is >>> what you get by default. There is any way to tell ZnEasy and friends to >>> get more tweets, something similar to what you do when you scroll down >>> into a twitter page? >>> >>> And by the way, I would like to make more sense of the Soup I got in the >>> last line. ea text gives me the tweet contents, but how can I interpret >>> the metadata in the soup? (is a retweet, date of publishing and so on). I >>> could make this for most part of the twitter profile page, but the tweet >>> is kind of elusive, for example how to know that "text" is the proper >>> message for getting the tweet content? Any pointer to how to make sense >>> of it by myself is greatly appreciated. >>> >>> Cheers, >>> >>> Offray >>> > > > > > > -- > View this message in context: http://forum.world.st/ZnClient-getting-more-that-19-tweet-for-data-scrappin… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 8, 2015

Re: [Pharo-users] Messaging solutions for Pharo

by Bernat Romagosa

Thanks! I guess I'll use mosquitto as a middleware then, and Zinc/Websockets from Pharo. Best, Bernat. 2015-04-08 16:47 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Hi Bernat, > > I did some with MQTT in Java/Android and JavaScript with Paho, but > never used it with Pharo nor in any of our products. > > Regards! > Esteban A. Maringolo > > > 2015-04-08 10:55 GMT-03:00 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com > >: > > Hi Esteban, > > > > did you finally choose MQTT? I'm in the beginning of a project right now > > where we need to communicate with a bunch of devices and we've considered > > MQTT, but we don't know whether to use some existing broker like > mosquitto > > or implement it in Pharo. Have you been down this path? > > > > Thanks! > > Bernat. > > > > 2014-11-24 11:55 GMT+01:00 Andres Fortier <andres.fortier(a)gmail.com>: > >> > >> Hi Stef, > >> > >> thanks! Glad to be doing things in Pharo :) > >> > >> On Sun, Nov 23, 2014 at 9:24 AM, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> Hello Andres > >>> > >>> nice to see you on this list :) > >>> > >>> Stef > >>> > >>> Le 19/11/14 19:40, Andres Fortier a Ã©crit : > >>> > >>> Hi Esteban, > >>> Never used either of them, but IIRC there was a Jabber package in > >>> Visualworks (JabberXMPP?), although not sure if it provided both > client and > >>> server. There is also > >>> http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, > but > >>> maybe worth a shot considering you only need the server side? > >>> > >>> HTH, > >>> AndrÃ©s > >>> > >>> On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo > >>> <emaringolo(a)gmail.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I'll be needing to add bidirectional messaging to our current Android > >>>> (Java) application, and as usual I'm expecting to manage the server > side of > >>>> the communication with Pharo. > >>>> > >>>> I'm evaluating two alternatives, but I'm in open to other, proven, > >>>> options. > >>>> > >>>> Option 1. WebSockets > >>>> Open a WebSocket on each device, and push/retrieve messages from each > of > >>>> these, tracking the device id if I need to recreate a new socket > (avoiding > >>>> recreating new sockets in case of connectivity issues, very common). > >>>> > >>>> Option 2. MQTT [1] > >>>> This is basically a mobile oriented MQ, super low footprint on mobile. > >>>> For what I saw, I could implement the server using an intermediate MQ > >>>> (RabbitMQ) and use STOMP to connect to it. > >>>> > >>>> Option 3. XMPP [3] > >>>> Provides several features I'll need in the future, like file transfer > in > >>>> addition to regular text messaging. It is very well supported in > Android > >>>> with Smack [4], but I don't know if we have a Pharo server for it, or > if > >>>> somebody ever played with it. > >>>> > >>>> By means of simplicity and use load I favor option 1, because I can > >>>> understand it better, and as everything moves towards web based > >>>> technologies, I could implement WAMP [5] on top of that in the future. > >>>> > >>>> Right now I'd need to have a hundred websockets opened at the same > time, > >>>> which doesn't sound like a heavy load to me, but I certainly don't > know. In > >>>> the future it could be an order of magnitude bigger, and that's why I > don't > >>>> discard more complex solutions like XMPP or MQTT. > >>>> > >>>> Regards! > >>>> > >>>> > >>>> [1] http://mqtt.org/ > >>>> [2] https://github.com/svenvc/docs/blob/master/neo/stamp.md > >>>> [3] http://xmpp.org/ > >>>> [4] http://www.igniterealtime.org/projects/smack/ > >>>> [5] http://wamp.ws/ > >>>> > >>>> > >>> > >>> > >> > > > > > > > > -- > > Bernat Romagosa. > > -- Bernat Romagosa.

April 8, 2015

Re: [Pharo-users] Messaging solutions for Pharo

by Esteban A. Maringolo

Hi Bernat, I did some with MQTT in Java/Android and JavaScript with Paho, but never used it with Pharo nor in any of our products. Regards! Esteban A. Maringolo 2015-04-08 10:55 GMT-03:00 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > Hi Esteban, > > did you finally choose MQTT? I'm in the beginning of a project right now > where we need to communicate with a bunch of devices and we've considered > MQTT, but we don't know whether to use some existing broker like mosquitto > or implement it in Pharo. Have you been down this path? > > Thanks! > Bernat. > > 2014-11-24 11:55 GMT+01:00 Andres Fortier <andres.fortier(a)gmail.com>: >> >> Hi Stef, >> >> thanks! Glad to be doing things in Pharo :) >> >> On Sun, Nov 23, 2014 at 9:24 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hello Andres >>> >>> nice to see you on this list :) >>> >>> Stef >>> >>> Le 19/11/14 19:40, Andres Fortier a Ã©crit : >>> >>> Hi Esteban, >>> Never used either of them, but IIRC there was a Jabber package in >>> Visualworks (JabberXMPP?), although not sure if it provided both client and >>> server. There is also >>> http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but >>> maybe worth a shot considering you only need the server side? >>> >>> HTH, >>> AndrÃ©s >>> >>> On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo >>> <emaringolo(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I'll be needing to add bidirectional messaging to our current Android >>>> (Java) application, and as usual I'm expecting to manage the server side of >>>> the communication with Pharo. >>>> >>>> I'm evaluating two alternatives, but I'm in open to other, proven, >>>> options. >>>> >>>> Option 1. WebSockets >>>> Open a WebSocket on each device, and push/retrieve messages from each of >>>> these, tracking the device id if I need to recreate a new socket (avoiding >>>> recreating new sockets in case of connectivity issues, very common). >>>> >>>> Option 2. MQTT [1] >>>> This is basically a mobile oriented MQ, super low footprint on mobile. >>>> For what I saw, I could implement the server using an intermediate MQ >>>> (RabbitMQ) and use STOMP to connect to it. >>>> >>>> Option 3. XMPP [3] >>>> Provides several features I'll need in the future, like file transfer in >>>> addition to regular text messaging. It is very well supported in Android >>>> with Smack [4], but I don't know if we have a Pharo server for it, or if >>>> somebody ever played with it. >>>> >>>> By means of simplicity and use load I favor option 1, because I can >>>> understand it better, and as everything moves towards web based >>>> technologies, I could implement WAMP [5] on top of that in the future. >>>> >>>> Right now I'd need to have a hundred websockets opened at the same time, >>>> which doesn't sound like a heavy load to me, but I certainly don't know. In >>>> the future it could be an order of magnitude bigger, and that's why I don't >>>> discard more complex solutions like XMPP or MQTT. >>>> >>>> Regards! >>>> >>>> >>>> [1] http://mqtt.org/ >>>> [2] https://github.com/svenvc/docs/blob/master/neo/stamp.md >>>> [3] http://xmpp.org/ >>>> [4] http://www.igniterealtime.org/projects/smack/ >>>> [5] http://wamp.ws/ >>>> >>>> >>> >>> >> > > > > -- > Bernat Romagosa.

April 8, 2015

Re: [Pharo-users] Messaging solutions for Pharo

by Bernat Romagosa

Hi Esteban, did you finally choose MQTT? I'm in the beginning of a project right now where we need to communicate with a bunch of devices and we've considered MQTT, but we don't know whether to use some existing broker like mosquitto or implement it in Pharo. Have you been down this path? Thanks! Bernat. 2014-11-24 11:55 GMT+01:00 Andres Fortier <andres.fortier(a)gmail.com>: > Hi Stef, > > thanks! Glad to be doing things in Pharo :) > > On Sun, Nov 23, 2014 at 9:24 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hello Andres >> >> nice to see you on this list :) >> >> Stef >> >> Le 19/11/14 19:40, Andres Fortier a Ã©crit : >> >> Hi Esteban, >> Never used either of them, but IIRC there was a Jabber package in >> Visualworks (JabberXMPP?), although not sure if it provided both client and >> server. There is also >> http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but >> maybe worth a shot considering you only need the server side? >> >> HTH, >> AndrÃ©s >> >> On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo < >> emaringolo(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'll be needing to add bidirectional messaging to our current Android >>> (Java) application, and as usual I'm expecting to manage the server side of >>> the communication with Pharo. >>> >>> I'm evaluating two alternatives, but I'm in open to other, proven, >>> options. >>> >>> Option 1. WebSockets >>> Open a WebSocket on each device, and push/retrieve messages from each of >>> these, tracking the device id if I need to recreate a new socket (avoiding >>> recreating new sockets in case of connectivity issues, very common). >>> >>> Option 2. MQTT [1] >>> This is basically a mobile oriented MQ, super low footprint on mobile. >>> For what I saw, I could implement the server using an intermediate MQ >>> (RabbitMQ) and use STOMP to connect to it. >>> >>> Option 3. XMPP [3] >>> Provides several features I'll need in the future, like file transfer in >>> addition to regular text messaging. It is very well supported in Android >>> with Smack [4], but I don't know if we have a Pharo server for it, or if >>> somebody ever played with it. >>> >>> By means of simplicity and use load I favor option 1, because I can >>> understand it better, and as everything moves towards web based >>> technologies, I could implement WAMP [5] on top of that in the future. >>> >>> Right now I'd need to have a hundred websockets opened at the same >>> time, which doesn't sound like a heavy load to me, but I certainly don't >>> know. In the future it could be an order of magnitude bigger, and that's >>> why I don't discard more complex solutions like XMPP or MQTT. >>> >>> Regards! >>> >>> >>> [1] http://mqtt.org/ >>> [2] https://github.com/svenvc/docs/blob/master/neo/stamp.md >>> [3] http://xmpp.org/ >>> [4] http://www.igniterealtime.org/projects/smack/ >>> [5] http://wamp.ws/ >>> >>> >>> >> >> > -- Bernat Romagosa.

April 8, 2015

Re: [Pharo-users] ZnClient: getting more that 19 tweet for data scrapping

by Paul DeBruicker

Offray - What Sven said is correct. You're not getting an answer about how to violate their Terms of Service because this isn't that kind of place. You've asked 3 times. Once is usually enough. Use the API. For the Soup questions get an inspector on an instance of a SoupTag and start sending it messages it understands and see what you get. Trial and error. Or read the python Soup docs as the commands probably have an equivalent in the Smalltalk library. Most of this programming stuff is reading, doing a little experiment, thinking, then trying again. Sven - I only showed him that SoupTag has a #text message. I'm sure you're busy and had forgotten that the first time he/she asked they stated that they don't want to use the api: http://forum.world.st/Data-scrapping-in-pharo-Extracting-tweets-contents-td… and provided the download code in an ws.stfx.eu snippet. Hope this helps Paul Sven Van Caekenberghe-2 wrote > What Paul showed is basically just a hack. > > What you probably what is full API access to Twitter, that gives you the > real thing, but it is more work and you have to understand all the > technical details (unless somebody already did it for you, I don't know - > I know that Zinc-SSO can connect to Twitter). > > https://dev.twitter.com/overview/api > >> On 07 Apr 2015, at 20:23, Offray Vladimir Luna CÃ¡rdenas < > offray@ > > wrote: >> >> Hi, >> >> Recently Paul DeBruicker taught me how to refine my code for getting >> tweets properly. Consider this: >> >> =[1]==================================== >> | source anUrl tweet | >> >> anUrl := 'https://twitter.com/offrayLC'. >> source := Soup fromString: (ZnEasy get: anUrl ) contents asString. >> tweets := (source findAllTagsByClass: 'ProfileTweet-text') collect:[:ea | >> ea text]. >> ======================================== >> >> Is working fine, but I would like to get more that 19 tweets, that is >> what you get by default. There is any way to tell ZnEasy and friends to >> get more tweets, something similar to what you do when you scroll down >> into a twitter page? >> >> And by the way, I would like to make more sense of the Soup I got in the >> last line. ea text gives me the tweet contents, but how can I interpret >> the metadata in the soup? (is a retweet, date of publishing and so on). I >> could make this for most part of the twitter profile page, but the tweet >> is kind of elusive, for example how to know that "text" is the proper >> message for getting the tweet content? Any pointer to how to make sense >> of it by myself is greatly appreciated. >> >> Cheers, >> >> Offray >> -- View this message in context: http://forum.world.st/ZnClient-getting-more-that-19-tweet-for-data-scrappin… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 8, 2015

Re: [Pharo-users] GitHub Mirror Workflow

by kilon alios

probably I kinda cheat, I use the smalltalkhub repo as nothing more than a shell for my github repo. I commit to it only my configuration which in turn loads the code from github . I have done this with Ephestos and Nireas , the configuration browsers entries just load the baseline from my github repos this way people who are not familiar with github can load my code from sthub without installing git or learning git but will getting automagically the latest code from my github repos. Its a win win situation and beats having to maintain multiple repos of the same project :) There is also no need to touch the configuration either so all my work is focus just on the github repo. I recently updated to add info to it for the package catalog. On Wed, Apr 8, 2015 at 3:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Bump :) > > > Sean P. DeNigris wrote > > for the "Mirror on Github" use case, I wonder if less granularity > wouldn't > > clearly be more appropriate. I read about using chunk format (not ideal, > > but perhaps a bit more readable on the mirror) via Gitocello, but loading > > in Pharo 4.0 broke on the FFI dependency. Any thoughts/suggestions? > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818339.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 8, 2015

Re: [Pharo-users] GitHub Mirror Workflow

by Esteban Lorenzano

I donât know your problemâ¦ why would you want another format form mirroring? Esteban > On 08 Apr 2015, at 14:07, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Bump :) > > > Sean P. DeNigris wrote >> for the "Mirror on Github" use case, I wonder if less granularity wouldn't >> clearly be more appropriate. I read about using chunk format (not ideal, >> but perhaps a bit more readable on the mirror) via Gitocello, but loading >> in Pharo 4.0 broke on the FFI dependency. Any thoughts/suggestions? > > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818339.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Thierry Goubier

Le 08/04/2015 13:23, Sean P. DeNigris a Ã©crit : > Dale Henrichs-3 wrote >> My mail may have been a bit harsh, so please read my reply to Peter ... >> where I think I take a bit more positive tack:) > > We are beyond politeness, my friend... Not our first rodeo :) > > > Dale Henrichs-3 wrote >> I am really pressed for time so I don't have the luxury to blue sky >> ideas ... > > I understand. I was not suggesting anyone do anything. Also, I agree that > methods seem to be the proper level for SCM versioning as they are in the > Smalltalk image. I was simply asking, in light of the appearance that the > merge driver could seemingly ignore the changes to certain files while still > committing them with Git, if it would be feasible to add read-only > one-class-per files "for viewing on GitHub". This is more of a sanity check > to see if I understood what the merge driver makes possible. The merge driver seemingly ignoring the changes to certain files while still committing? No, doesn't work that way. The merge driver never commits. Unless you mean that, in case of conflicts on merging that file, that the merge driver should be disregarding the conflicts and choose one version over another... Not sure to see how that would work. Remember that the merge driver is only called by git merge. Nothing else. Adding a description file would enter it into the git and make it tracked as are all other files. And adding a file is really not a big deal. Thierry > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818323… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 8, 2015

Re: [Pharo-users] GitHub Mirror Workflow

by Sean P. DeNigris

Bump :) Sean P. DeNigris wrote > for the "Mirror on Github" use case, I wonder if less granularity wouldn't > clearly be more appropriate. I read about using chunk format (not ideal, > but perhaps a bit more readable on the mirror) via Gitocello, but loading > in Pharo 4.0 broke on the FFI dependency. Any thoughts/suggestions? ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818339.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 8, 2015