December 2016 - Pharo-users

Re: [Pharo-users] real world pharo web application set ups

by Dimitris Chloupis

That 5% idle CPU consumption is not the only problem, creating a new process will add additional overheads anyway so it does not make sense to have more pharo processes than CPU cores. Concurrency can be handled by pharo forks. I am not web dev even by a remote imagination but my recent experience with UFFI is that Pharo can go to insane speeds when it relies on C libraries , especially performance orientated ones. Of course learning C and playing with C is a pain by itself but necessary evil if top performance is the goal. On Wed, Dec 14, 2016 at 8:28 PM Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2016-12-14 15:11 GMT-03:00 Volkert <volkert(a)nivoba.de>: > > Pharo is currently successful used. Scalability and Performance will > always > > an issue. I like Pharo really, but i have not to goal ending up in a > complex > > deployment of Pharo Nodes, because a Pharo with Seaside can only handle - > > say 20 user - ... > > The 20 user depends more on the I/O than anything else. > However you can scale Seaside horizontally using a front reverse proxy > like nginx using session affinity. > > Memory is cheap, and the only limit now is CPU, the current Pharo > image has an idle CPU consumption ~5%, so you can't have many > concurrent images running in the same machine. > > > Regards, > > > Esteban A. Maringolo > >

Dec. 14, 2016

Re: [Pharo-users] What can we look forward to in 2017?

by Norbert Hartl

> Am 14.12.2016 um 18:00 schrieb Ben Coman <btc(a)openinworld.com>: > > > >> On Thu, Dec 15, 2016 at 12:38 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >>> On Wed, Dec 14, 2016 at 5:35 PM Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>> This is a good example of the "empowering map" I talk about about "Pharo/Smalltalk places for you". What we can look forward in 2017 is different for different people, so going beyond the "most exiting developments", hype and shiny new things is also a way to show how Pharo/Smalltalk are different. We can provide shine and hype, but also we're building stuff for different interests and people and that is even more worthy to look for the upcoming times (2017 and beyond). >>> >>> Cheers, >>> >>> Offray >>> >> >> I think there is big difference between doing something exciting versus doing something useful. Excitement dies out but usefulness does not. I don't do it to make Pharo look cool, I do it because I need it. I also do not like to do something and then abandon it like it happens for 99% of the open source software. >> >> Also maintenance becomes a big issue if the scope is wide. Of course you can also combine excitement with usefulness and still keep the scope reasonably achievable. >> >> A thing I love about Pharo is because its so limited third party library wise it forces me to go do that stuff myself and this definitely builds confidence in one's coding skills. I really like this DYI approach and I am definitely moving to the opposite direction of "do not reinvent the wheel". This would have been unthinkable in communities of very popular languages. I really like that Pharo forces me to be much less lazy as a coder. > > Because reinventing the wheel is a good way to learn about wheels... I like that argument. I copy that ð Norbert > cheers -ben > >> >> Its also impressive to see the things that other people do by themselves too and be inspired by it. >> >> The real problem is that this work is not really visible, I think Pharo needs something like a magazine and people should be encouraged to share their work even if it is in early stage because you never know who will find it useful. I feel the things we see in the mailing list is only the tip of the iceberg of what people work on and is pity all this code to be lost in obscurity. >

Dec. 14, 2016

Re: [Pharo-users] real world pharo web application set ups

by Esteban A. Maringolo

2016-12-14 15:11 GMT-03:00 Volkert <volkert(a)nivoba.de>: > Pharo is currently successful used. Scalability and Performance will always > an issue. I like Pharo really, but i have not to goal ending up in a complex > deployment of Pharo Nodes, because a Pharo with Seaside can only handle - > say 20 user - ... The 20 user depends more on the I/O than anything else. However you can scale Seaside horizontally using a front reverse proxy like nginx using session affinity. Memory is cheap, and the only limit now is CPU, the current Pharo image has an idle CPU consumption ~5%, so you can't have many concurrent images running in the same machine. Regards, Esteban A. Maringolo

Dec. 14, 2016

Re: [Pharo-users] real world pharo web application set ups

by Vitor Medina Cruz

> > If I tell you that my current estimate is that a Smalltalk image with > Seaside will not be able to handle more than 20 concurrent users, in many > cases even less. Seriously? That is kinda a low number, I would expect more for each image. Certainly it depends much on many things, but it is certainly very low for a rough estimate, why you say that? On Tue, Dec 13, 2016 at 5:29 PM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > Volkert, > > I surely cannot help you with concrete answers. We are not even using > Pharo for our Seaside App. > > All I've learned is that all of these questions are extremely hard to > answer. Will Pharo or any other Server side technology scale? Forget it, > nobody will be able to tell you the truth. > > What I've learnt so far is that this whole thing is mostly a question of > distributing services between servers (images and external processes). Make > things small and devidable. Load the number crunching off of your web > facing image and build clever UIs that give good feedback about the > progress of lengthy operations. > > If I tell you that my current estimate is that a Smalltalk image with > Seaside will not be able to handle more than 20 concurrent users, in many > cases even less. What does that actually tell you? YMMV based on the work > that is done in that image, and there are so many influencing factors. If > of these 20 users only 1 currently asks for heavy computation, this can > already mean the server is slow for the other 19. > > Our Application is very different from what you describe: Accounting is > mostly CRUD operations, which means there are not many things you can > delegate to external programs or even servers. Your scenario sounds very > different. It sounds like you can do the data aggregation and refinement > part in a separate (maybe REST based and stateless) server and mostly > render nice "wait, we're working for you" dialogs and present nice results > once they're done. This scales wonderfully and the front-end web server > mostly does nothing other than send out self-reloading please-wait pages. > Such a server (image) can probably even handle 50 or more concurrent users. > Thus you end up with several layers on which you can scale easily and > mostly independently. If your aggreations are slow, add a few images that > do the aggregations. > > So if your question is whether you can handle 500 concurrent users in > Smalltalk or Pharo with Seaside, the answer is definitely YES. If you want > to know how many Images are needed, how many servers you'd have to order, > you'll probably not get any useful answers. My feeling is that you can't > know exactly because every app is so different. There probably are just not > enough projects out there to collect relevant data... > > Joachim > > > > Am 13.12.16 um 20:06 schrieb Volkert: > > >> >> On 12.12.2016 19:52, Norbert Hartl wrote: >> >>> Am 12.12.2016 um 19:16 schrieb Volkert <volkert(a)nivoba.de>: >>>> >>>> After reading reading "Enterprise Pharo a Web perspective", i am >>>> curious to learn more about current real world pharo web application set >>>> ups. any case studies or blue prints around? i am interested in application >>>> domain, system architecture, infrastructure (HW/OS/DB), performance goals >>>> (concurrent users, transactions, ...), system sizing, scalability >>>> strategies, .... >>>> >>>> everything which could important to convince "me" to select pharo as a >>>> platform for a saas solution â¦ >>>> >>>> What you really want to know? All the things you mentioned above are >>> not pharo related at all! Can you at least roughly sketch in which area you >>> would consider to use pharo? >>> >>> Norbert >>> >>> >>> I like to know more about current real world pharo web application set >> up ... not more, not less. >> >> Think of a environmental information management system >> 50000 User / 500 Concurrent >> Data Aggregation >> Data Refinement / Processing >> Data Visualization >> 15-20 Dataprovider >> Web UI >> >> >> >> >> >> > >

Dec. 14, 2016

Re: [Pharo-users] real world pharo web application set ups

by Volkert

Thanks Joachim, for the answer. I had the same thoughts about the architecture. And yes of course, there is no easy and simple answer ... such an answer is always wrong ... So it is more important to see, were for which parts of distributed architectures Pharo is currently successful used. Scalability and Performance will always an issue. I like Pharo really, but i have not to goal ending up in a complex deployment of Pharo Nodes, because a Pharo with Seaside can only handle - say 20 user - ... i will now read the BetaNine case, Joe mentioned ;-) On 13.12.2016 20:29, jtuchel(a)objektfabrik.de wrote: > Volkert, > > I surely cannot help you with concrete answers. We are not even using > Pharo for our Seaside App. > > All I've learned is that all of these questions are extremely hard to > answer. Will Pharo or any other Server side technology scale? Forget > it, nobody will be able to tell you the truth. > > What I've learnt so far is that this whole thing is mostly a question > of distributing services between servers (images and external > processes). Make things small and devidable. Load the number crunching > off of your web facing image and build clever UIs that give good > feedback about the progress of lengthy operations. > > If I tell you that my current estimate is that a Smalltalk image with > Seaside will not be able to handle more than 20 concurrent users, in > many cases even less. What does that actually tell you? YMMV based on > the work that is done in that image, and there are so many influencing > factors. If of these 20 users only 1 currently asks for heavy > computation, this can already mean the server is slow for the other 19. > > Our Application is very different from what you describe: Accounting > is mostly CRUD operations, which means there are not many things you > can delegate to external programs or even servers. Your scenario > sounds very different. It sounds like you can do the data aggregation > and refinement part in a separate (maybe REST based and stateless) > server and mostly render nice "wait, we're working for you" dialogs > and present nice results once they're done. This scales wonderfully > and the front-end web server mostly does nothing other than send out > self-reloading please-wait pages. Such a server (image) can probably > even handle 50 or more concurrent users. Thus you end up with several > layers on which you can scale easily and mostly independently. If your > aggreations are slow, add a few images that do the aggregations. > > So if your question is whether you can handle 500 concurrent users in > Smalltalk or Pharo with Seaside, the answer is definitely YES. If you > want to know how many Images are needed, how many servers you'd have > to order, you'll probably not get any useful answers. My feeling is > that you can't know exactly because every app is so different. There > probably are just not enough projects out there to collect relevant > data... > > Joachim > > > > Am 13.12.16 um 20:06 schrieb Volkert: >> >> >> On 12.12.2016 19:52, Norbert Hartl wrote: >>>> Am 12.12.2016 um 19:16 schrieb Volkert <volkert(a)nivoba.de>: >>>> >>>> After reading reading "Enterprise Pharo a Web perspective", i am >>>> curious to learn more about current real world pharo web >>>> application set ups. any case studies or blue prints around? i am >>>> interested in application domain, system architecture, >>>> infrastructure (HW/OS/DB), performance goals (concurrent users, >>>> transactions, ...), system sizing, scalability strategies, .... >>>> >>>> everything which could important to convince "me" to select pharo >>>> as a platform for a saas solution â¦ >>>> >>> What you really want to know? All the things you mentioned above are >>> not pharo related at all! Can you at least roughly sketch in which >>> area you would consider to use pharo? >>> >>> Norbert >>> >>> >> I like to know more about current real world pharo web application >> set up ... not more, not less. >> >> Think of a environmental information management system >> 50000 User / 500 Concurrent >> Data Aggregation >> Data Refinement / Processing >> Data Visualization >> 15-20 Dataprovider >> Web UI >> >> >> >> >> > >

Dec. 14, 2016

Re: [Pharo-users] What can we look forward to in 2017?

by Ben Coman

On Thu, Dec 15, 2016 at 12:38 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > On Wed, Dec 14, 2016 at 5:35 PM Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > >> This is a good example of the "empowering map" I talk about about >> "Pharo/Smalltalk places for you". What we can look forward in 2017 is >> different for different people, so going beyond the "most exiting >> developments", hype and shiny new things is also a way to show how >> Pharo/Smalltalk are different. We can provide shine and hype, but also >> we're building stuff for different interests and people and that is even >> more worthy to look for the upcoming times (2017 and beyond). >> >> Cheers, >> >> Offray >> > > I think there is big difference between doing something exciting versus > doing something useful. Excitement dies out but usefulness does not. I > don't do it to make Pharo look cool, I do it because I need it. I also do > not like to do something and then abandon it like it happens for 99% of the > open source software. > > Also maintenance becomes a big issue if the scope is wide. Of course you > can also combine excitement with usefulness and still keep the scope > reasonably achievable. > > A thing I love about Pharo is because its so limited third party library > wise it forces me to go do that stuff myself and this definitely builds > confidence in one's coding skills. I really like this DYI approach and I am > definitely moving to the opposite direction of "do not reinvent the wheel". > This would have been unthinkable in communities of very popular languages. > I really like that Pharo forces me to be much less lazy as a coder. > Because reinventing the wheel is a good way to learn about wheels... cheers -ben > > Its also impressive to see the things that other people do by themselves > too and be inspired by it. > > The real problem is that this work is not really visible, I think Pharo > needs something like a magazine and people should be encouraged to share > their work even if it is in early stage because you never know who will > find it useful. I feel the things we see in the mailing list is only the > tip of the iceberg of what people work on and is pity all this code to be > lost in obscurity. >

Dec. 14, 2016

Re: [Pharo-users] What can we look forward to in 2017?

by Dimitris Chloupis

On Wed, Dec 14, 2016 at 5:35 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > This is a good example of the "empowering map" I talk about about > "Pharo/Smalltalk places for you". What we can look forward in 2017 is > different for different people, so going beyond the "most exiting > developments", hype and shiny new things is also a way to show how > Pharo/Smalltalk are different. We can provide shine and hype, but also > we're building stuff for different interests and people and that is even > more worthy to look for the upcoming times (2017 and beyond). > > Cheers, > > Offray > I think there is big difference between doing something exciting versus doing something useful. Excitement dies out but usefulness does not. I don't do it to make Pharo look cool, I do it because I need it. I also do not like to do something and then abandon it like it happens for 99% of the open source software. Also maintenance becomes a big issue if the scope is wide. Of course you can also combine excitement with usefulness and still keep the scope reasonably achievable. A thing I love about Pharo is because its so limited third party library wise it forces me to go do that stuff myself and this definitely builds confidence in one's coding skills. I really like this DYI approach and I am definitely moving to the opposite direction of "do not reinvent the wheel". This would have been unthinkable in communities of very popular languages. I really like that Pharo forces me to be much less lazy as a coder. Its also impressive to see the things that other people do by themselves too and be inspired by it. The real problem is that this work is not really visible, I think Pharo needs something like a magazine and people should be encouraged to share their work even if it is in early stage because you never know who will find it useful. I feel the things we see in the mailing list is only the tip of the iceberg of what people work on and is pity all this code to be lost in obscurity.

Dec. 14, 2016

Re: [Pharo-users] What can we look forward to in 2017?

by Offray Vladimir Luna CÃ¡rdenas

This is a good example of the "empowering map" I talk about about "Pharo/Smalltalk places for you". What we can look forward in 2017 is different for different people, so going beyond the "most exiting developments", hype and shiny new things is also a way to show how Pharo/Smalltalk are different. We can provide shine and hype, but also we're building stuff for different interests and people and that is even more worthy to look for the upcoming times (2017 and beyond). Cheers, Offray On 14/12/16 04:15, Dimitris Chloupis wrote: > > On Tue, Dec 13, 2016 at 6:15 PM horrido <horrido.hobbies(a)gmail.com > <mailto:horrido.hobbies@gmail.com>> wrote: > > Fellow Pharoers: What is the most exciting development in 2017 to look > forward to? I'm asking for things to put into the end-of-year post > in my > "Make Smalltalk Great Again!" campaign. Thanks. > > > I would not call it "most exciting development" for anyone but is > definitely for me > > Generally the plans for my project Ephestos for 2017 are > > 1) To create an Unreal API for Pharo > 2) To create a Blender API for Pharo > 3) To create a Supercollider API for Pharo > > Unreal is the most powerful game/graphics engine. > Blender is the most powerful 3d editor. > Supercollider is the most powerful live coding music and audio > synthesis platform. > > I have developed the foundation for all three , the only thing > remaining know is to wrap their APIs for Pharo. > > So by end of 2017 Pharo will have received a massive boost to its 2d > and 3d graphics capabilities and > music and audio synthesis capabilities. > > Supercollider part is not a high priority goal as the other two, but I > think I can squeeze it through. > > Low priority goals and less exciting for me are > > 1) improvements to Nireas expanding its customisability, recreating > the GUI , improving the blue theme and offer multiple other themes too > 2) a tool that unifies workspace, system browser and inspector under > one roof. I have not tested yet grafoscopio in detail, so it may form > the basis for this tool > 3) further contributions to Pharo By Example and possibly other books >

Dec. 14, 2016

Re: [Pharo-users] accessing local/instance variables with metalinks

by Marcus Denker

Hi, I think I found a simple solution: the ability to reference any variable. https://pharo.fogbugz.com/f/cases/19467/Metalinks-support-accessing-variabl… This test shows how to use it for a temp: testAccessTemp | varNode instance | varNode := (ReflectivityExamples>>#exampleAssignment) ast body statements second. link := MetaLink new metaObject: self; selector: #tagExec:; arguments: {RBVariableNode named: #temp}. varNode link: link. self assert: varNode hasMetalink. self assert: (tag isNil). instance := ReflectivityExamples new . self assert: (instance exampleAssignment = 3). self assert: (tag = 3). I have not yet tested it for any other example, but it should work for your case, too, which would look like this: MetaLink new metaObject: [ :surface :trachelCanvas | surface clear: trachelCanvas color. ]; selector: #value:value:; arguments: {RBVariableNode named: #surface . RBVariableNode named: #trachelCanvas }. control: #instead. > On 12 Dec 2016, at 09:36, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > Not yet. It should be easy to add if we find a good API for itâ¦ > > I will work on it this week (I have blocked some time for RF related hacking). > > e.g I think we have to extend the syntax for reifications to use classes. > > something like: > > arguments: {RFTempReification named: #trachelCanvas}; > > The current symbols then would be the same as using > > RFReification named: #object > > But subclasses can be used directly and parametrized. > > Marcus > >> On 5 Dec 2016, at 20:42, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> what is the best way to access variables from within a metalink? >> >> for example I have a message send `surface clear` and I want to change it to `surface clear: trachelCanvas color`. >> >> I can use #instVarNamed: >> >> ``` >> MetaLink new >> metaObject: [ :object | >> (object instVarNamed: #surface) clear: (object instVarNamed: #trachelCanvas) color. >> ]; >> selector: #value:; >> arguments: #(object); >> control: #instead. >> ``` >> >> but the above isn't exactly nice, plus it wouldn't work with temporary variables. >> >> Thanks, >> Peter >> >

Dec. 14, 2016

Re: [Pharo-users] accessing local/instance variables with metalinks

by Marcus Denker

Hi, I think I found a simple solution: the ability to reference any variable. https://pharo.fogbugz.com/f/cases/19467/Metalinks-support-accessing-variabl… This test shows how to use it for a temp: testAccessTemp | varNode instance | varNode := (ReflectivityExamples>>#exampleAssignment) ast body statements second. link := MetaLink new metaObject: self; selector: #tagExec:; arguments: {RBVariableNode named: #temp}. varNode link: link. self assert: varNode hasMetalink. self assert: (tag isNil). instance := ReflectivityExamples new . self assert: (instance exampleAssignment = 3). self assert: (tag = 3). I have not yet tested it for any other example, but it should work for your case, too, which would look like this: MetaLink new metaObject: [ :surface :trachelCanvas | surface clear: trachelCanvas color. ]; selector: #value:value:; arguments: {RBVariableNode named: #surface . RBVariableNode named: #trachelCanvas }. control: #instead. > On 12 Dec 2016, at 09:36, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > Not yet. It should be easy to add if we find a good API for itâ¦ > > I will work on it this week (I have blocked some time for RF related hacking). > > e.g I think we have to extend the syntax for reifications to use classes. > > something like: > > arguments: {RFTempReification named: #trachelCanvas}; > > The current symbols then would be the same as using > > RFReification named: #object > > But subclasses can be used directly and parametrized. > > Marcus > >> On 5 Dec 2016, at 20:42, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> what is the best way to access variables from within a metalink? >> >> for example I have a message send `surface clear` and I want to change it to `surface clear: trachelCanvas color`. >> >> I can use #instVarNamed: >> >> ``` >> MetaLink new >> metaObject: [ :object | >> (object instVarNamed: #surface) clear: (object instVarNamed: #trachelCanvas) color. >> ]; >> selector: #value:; >> arguments: #(object); >> control: #instead. >> ``` >> >> but the above isn't exactly nice, plus it wouldn't work with temporary variables. >> >> Thanks, >> Peter >> >

Dec. 14, 2016