November 2017 - Pharo-users

Re: [Pharo-users] New Pharo article at The Cohort

by Norbert Hartl

I just skimmed at it and found that piece Back to the Future Everybody has heard of Smalltalk. This venerable programming language has had a long and illustrious history <https://hackernoon.com/smalltalk-is-the-nikola-tesla-of-the-it-industry-dbe…>. It was the first programming language to popularize object-oriented programming (or OOP). Remember the famous August 1981 BYTE cover? Just to add my personal statistics. I would say that about 2% of all developers I talk to know that there is programming language called Smalltalk. And somewhat like 8% of all are older than that mentioned magazine. So to me that sounds rather strange. But even more important is that I don't understand why people always talk about the future when the only thing they do is telling the past. I think we are better than this. Norbert > Am 16.11.2017 um 05:13 schrieb horrido <horrido.hobbies(a)gmail.com>: > > Why Pharo Might be the Future of Software Development > <https://blog.appacademy.io/pharo-future-software-development/> > > Spread the word. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 16, 2017

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

by Ben Coman

On 26 October 2017 at 18:37, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Nothing complex about two images exchanging messages, its not even complex > to transmit objects via fuel, you even transmit a debugger or any part of > the live environment or even make an "internet" of images that join objects > together. Sky is the limit. Pharo already provides you will all the > tools/libraries to do this. > > A streamsocket (not to be confused with regular sockets) will delay the > messages (a collection of bytes) until they arrive to the receiver or until > they have reached the timeout period. Offline mode is pretty much > obligatory even for plain old internet web apps because of drops in > connection or the plain fact a connection can become slow. > > I used streamsockets in my Pharo to Python bridge (Atlas) because the > execution was not necessary synchronous , I was sending Python command to a > 3d application from Pharo and I had to make sure that the bridge was > working even in the case of a command that could take hours to execute like > a rendering process. > And others are finding similar results... "Inter-process communication is a (surprisingly) effective way to couple two programming languages " R into Go... http://user2015.math.aau.dk/presentations/236.pdf cheers -ben

Nov. 16, 2017

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Mariano Martinez Peck

On Wed, Nov 15, 2017 at 7:04 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote > > Sorry for making you do all the work > > Not at all; happy to help. It takes a village! BTW I tracked it down to the > spaces in the command path. IIRC from my OSP hacking days, it probably has > something to do with the path not being run through the shell to interpret > the $\s. > > Yeah, OSSubprocess wont interpret, not expand anything. If you want to use shell, then you have to use #shellCommand: or #shell:command: (see its senders for test examples) Cheers, -- Mariano http://marianopeck.wordpress.com

Nov. 16, 2017

Re: [Pharo-users] New Pharo article at The Cohort

by Ben Coman

I liked it. Actually I thought it was Richard's most balanced piece to date - except the poke in the cl paragraph. Something softer like "Pharo might not be right for you, but its worth taking a look at" would be better. And for spreading the word, perhaps controversy is better than being ignored - hard to know though. Duty calls... https://xkcd.com/386/ btw, in the linked study interesting to see that Excel has even better function point efficiency than Smalltalk - which reminds me, Excel provides a workable "Image" analogy. The data shares the same file as the code. cheers -ben On 16 November 2017 at 17:07, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Please, please, please, stop to write such kind of articles. You are doing > a really bad service to us. You can help to Pharo in many other ways. You > will not convince people to use Pharo by spitting on everything else. > One fixed typo has incomparably bigger value than blogpost like this. > > -- Pavel > > 2017-11-16 5:13 GMT+01:00 horrido <horrido.hobbies(a)gmail.com>: > >> Why Pharo Might be the Future of Software Development >> <https://blog.appacademy.io/pharo-future-software-development/> >> >> Spread the word. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >

Nov. 16, 2017

Re: [Pharo-users] Network data exchange - Basys and Seamless usage questioning

by Denis Kudriashov

Ok, I try answer your original question: 2017-11-12 10:47 GMT+01:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > > My objective is to have several images running (one representing one app > belonging to one or more singular entity realm). > > Lets say image A1, A2, A3 belongs to Alice. And image B1, B2, â¦ to Bob. > > They exchange messages conveying information. So the aim of the network > layer is for me to keep messages synchronized betweens A(s) and B(s). I > have inbox and outbox for that. This is actually quite close to the basys > abstractions on LocalPeer and RemotePeer (active and passive). > > So I played a bit with basys and can declare a network between A1 and B1 > for instance. I wonder if I need as much network as possible connection > (A1B1 A1B2 â¦ but also A1A2, A1A3, A2A3, â¦). Not sure how to declare network > with more than 2 nodesâ¦ > Probably not but if you have different purpose of connecting A<->A nodes and connecting A<->B nodes then it can be suitable to have separate networks for that. But it is difficult to answer without more information. I imaging following schema: On each node you have single network instance. Let's say we have node A1. Then other A1, A2 and B nodes connect to A1. By Basys logic they will be represented by remote peers inside A1 network instance. So you are able to enumerate all connected peers and sync some local information with them: network remotePeers do: [:each | each sendDataPackage: myNewLocalData]. And for incoming messages you can put them into inbox collection stored inside network instance: YourNetwork>> process: anExchangeData receivedFrom: aRemotePeer inboxQueue add: anExchangeData And you can have separate process which handle this queue. So in that case I do not see the reason to create multiple instances of network for each pair of connected nodes. What you think? Is my example relevant to your case?

Nov. 16, 2017

Re: [Pharo-users] New Pharo article at The Cohort

by Serge Stinckwich

And can you remove this sentence: ââ Pharo is being used to fight Ebola : http://ummisco.github.io/kendrick/ âYou cite my research work about KENDRICK, a domain-specific language built in order to analyze epidemiological models. Thank you for the link, but we never fight Ebola ... We only participate to a âhackathon about Ebola in 2014 and we implement some basic Ebola mathematical models in KENDRICK at that time. We never have any impact on Ebola unfortunately. âDon't spread false informations. Thank you.â On Thu, Nov 16, 2017 at 10:07 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Please, please, please, stop to write such kind of articles. You are doing a really bad service to us. You can help to Pharo in many other ways. You will not convince people to use Pharo by spitting on everything else. > One fixed typo has incomparably bigger value than blogpost like this. > > -- Pavel > > 2017-11-16 5:13 GMT+01:00 horrido <horrido.hobbies(a)gmail.com>: >> >> Why Pharo Might be the Future of Software Development >> <https://blog.appacademy.io/pharo-future-software-development/> >> >> Spread the word. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute." http://www.doesnotunderstand.org/

Nov. 16, 2017

Re: [Pharo-users] New Pharo article at The Cohort

by Pavel Krivanek

Please, please, please, stop to write such kind of articles. You are doing a really bad service to us. You can help to Pharo in many other ways. You will not convince people to use Pharo by spitting on everything else. One fixed typo has incomparably bigger value than blogpost like this. -- Pavel 2017-11-16 5:13 GMT+01:00 horrido <horrido.hobbies(a)gmail.com>: > Why Pharo Might be the Future of Software Development > <https://blog.appacademy.io/pharo-future-software-development/> > > Spread the word. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Nov. 16, 2017

New Pharo article at The Cohort

by horrido

Why Pharo Might be the Future of Software Development <https://blog.appacademy.io/pharo-future-software-development/> Spread the word. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 16, 2017

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Sean P. DeNigris

Alistair Grant wrote > I'm glad (and relieved :-)) to hear that it is working. > > Would you mind sending the modified command path that you're using so > I can update the code? (I guess that it is just removing the > backspaces, but just in case...). That is correctâ¦ OSSUnixSubprocess new command: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'; arguments: #('--user-data-dir=/tmp/pharo/GoogleChrome/debugSession' '--remote-debugging-port=9222'); run. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 15, 2017

Re: [Pharo-users] Network data exchange - Basys and Seamless usage questioning

by CÃ©drick BÃ©ler

Hi, sorry for the late reply Denis, > > Can you show example how you work with your objects using this network? Itâs not fully decided yet. Iâm just trying to show that 2 peers A and B can exchange and sync information without central server, but also considering they have multiples devices (connected on demand P2P - offline first is a major requirement). So for now, to test, I just connect A and B through basys by sending a connection in both direction A->B B->A. I think ok keeping a "message hub Â» specific to each interaction A can have with B(s), C(s)... A queue but that kind of never deletes messages but changes its meta content - so as to sync with other devices when they eventually connect). So for now, my need is quite simple regarding connections. I used mostly for now #sendDataPacket: I could do it also with Zinc in HTTP. But, as always in Smalltalk, I explore in plenty of directions and discover great stuffs like Seamless perfectly usable and some less finished or older gems like BitTalk or UbiquiTalkâ¦ Very interesting as I will need more functionalities to deal with decentralized networks. > > BasisNetworkStub is only created for tests. And I think it misses one important function: how identify peers. When your image get new connection it should identify what remote peer is connected by it. So two connections from same remote image should be identified as single peer instance on your local image. Yes, sure Iâve spotted that and I definitely need a way to identify peer-devices (belonging to a peer realm/swarm). Iâll do later. > > I would of course use Seamless for distributed applications because it allows to implement solution with objects locally and then transparently split them over network. > But Seamless not implements any kind of message queue. So I would use some proven solution for it instead of custom implementation. But it can depends on the task. Do you think of something in particular ? :) For now my queue will only be ordered collections or whatever simple collection. It should be enough to start with. > > 2) or may I use Seamless straight with restrictions (I wonder if limiting the classes that can be executed would suffice - proxies should only be on the peer inbox and outbox I think) ? > 3) or maybe I should do a lighter version of seamless ? If so where should I look at/change ? > > You can try subclass SeamlessNetwork and override request processing method with special restrictions on what requests are permitted. Maybe you can propose such kind of policy to the Seamless itself. Subclassing Seamless seems to be a very good simple and powerful possibility (to get inspiration too) and I may do that. Anyway most of what I have to do is build a system that seamlessly present to the user information extracted from messages (stored locally- versioned) => its actually just transposing what you all are used too with tools like git but applied to Â« general information exchange and processing Â». Enterprise information systems are so boringâ¦ they should be far more a la smalltalk ^^ Cheers, CÃ©drick

Nov. 15, 2017