June 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Microservices using Pharo

by Norbert Hartl

> Am 26.06.2018 um 20:44 schrieb Andrei Stebakov <lispercat(a)gmail.com>: > > What would be an example for load balancer for Pharo images? Can we run multiple images on the same server or for the sake of balancing configuration we can only run one image per server? > There are a lot of possibilities. You can start multiple images on different ports and use nginx with an upstream rule to load balance. I would recommend using docker for spawning multiple images on a host. Again with nginx as frontend load balancer. The point is that you can have at least twice as muh inages running then you have CPU cores. And of course a lot more. Norbert >> On Tue, Jun 26, 2018, 14:32 Andrei Stebakov <lispercat(a)gmail.com> wrote: >> Thanks, guys! I really appreciate your input! >> >>> On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> > On 26 Jun 2018, at 15:52, Norbert Hartl <norbert(a)hartl.name> wrote: >>> > >>> > >>> > >>> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >> >>> >> >>> >> >>> >>> On 26 Jun 2018, at 15:24, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> >>> >>> >>> >>> >>> >>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lispercat(a)gmail.com>: >>> >>>> >>> >>>> Does anyone use Pharo for Miro services? I heard about Seaside and Teapot, just was wondering if Pharo can handle multiple simultaneous requests and if it can, where it reaches the limit. >>> >>> >>> >>> I use it extensively. I use Zinc-REST package to offer services. The answer how much it can handle in parallel is hard to answer. For this you need to tell what you are about to do. But a rule of thumb is not to exceed 5 parallel tasks that are working at the same time. But a lot of tasks have wait times while accessing another HTTP service, a database, a filesystem etc. For this you can easily go up to 10 I guess. >>> >>> >>> >>> But these numbers are more of a gut feeling then something scientific >>> >>> >>> >>> Norbert >>> >> >>> >> A single ZnServer instance on a single image can handle thousands of requests per seconds (local network, very small payload, low concurrency). On a modern multi core / multi processor machine with lots of memory you can 10s if not 100s of Pharo image under a load balancer, provided you either do not share state or use high performance state sharing technology - this is the whole point of REST. >>> >> >>> >> Of course, larger payloads, more complex operations, real world networking, etc will slow you down. And it is very easy to make some architectural or implementation error somewhere that makes everything slow. As they say, YMMV. >>> >> >>> > >>> > I meant it regarding what a single image can do. And it can do thousands of requests only if there is no I/O involved and I doubt this will be a very useful service to build if it does not any additional I/O. Still I would try not to have more than 5 req/s on a single image before scaling up. The only number I can report is that 2 images serving 30 requests/s while using mongodb are not noticable in system stats. >>> > >>> > Norbert >>> >>> That is what I meant: it is an upper limit of an empty REST call, the rest depends on the application and the situation. If your operation takes seconds to complete, the request rate will go way down. >>> >>> But with in memory operations and/or caching, responses can be quite fast (sub 100 ms). >>> >>>

June 26, 2018

Re: [Pharo-users] Microservices using Pharo

by Andrei Stebakov

I guess for multiple images on the same server we need to spawn off images listening on different ports. On Tue, Jun 26, 2018, 14:44 Andrei Stebakov <lispercat(a)gmail.com> wrote: > What would be an example for load balancer for Pharo images? Can we run > multiple images on the same server or for the sake of balancing > configuration we can only run one image per server? > > On Tue, Jun 26, 2018, 14:32 Andrei Stebakov <lispercat(a)gmail.com> wrote: > >> Thanks, guys! I really appreciate your input! >> >> On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> >>> > On 26 Jun 2018, at 15:52, Norbert Hartl <norbert(a)hartl.name> wrote: >>> > >>> > >>> > >>> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >> >>> >> >>> >> >>> >>> On 26 Jun 2018, at 15:24, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> >>> >>> >>> >>> >>> >>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lispercat(a)gmail.com >>> >: >>> >>>> >>> >>>> Does anyone use Pharo for Miro services? I heard about Seaside and >>> Teapot, just was wondering if Pharo can handle multiple simultaneous >>> requests and if it can, where it reaches the limit. >>> >>> >>> >>> I use it extensively. I use Zinc-REST package to offer services. The >>> answer how much it can handle in parallel is hard to answer. For this you >>> need to tell what you are about to do. But a rule of thumb is not to exceed >>> 5 parallel tasks that are working at the same time. But a lot of tasks have >>> wait times while accessing another HTTP service, a database, a filesystem >>> etc. For this you can easily go up to 10 I guess. >>> >>> >>> >>> But these numbers are more of a gut feeling then something scientific >>> >>> >>> >>> Norbert >>> >> >>> >> A single ZnServer instance on a single image can handle thousands of >>> requests per seconds (local network, very small payload, low concurrency). >>> On a modern multi core / multi processor machine with lots of memory you >>> can 10s if not 100s of Pharo image under a load balancer, provided you >>> either do not share state or use high performance state sharing technology >>> - this is the whole point of REST. >>> >> >>> >> Of course, larger payloads, more complex operations, real world >>> networking, etc will slow you down. And it is very easy to make some >>> architectural or implementation error somewhere that makes everything slow. >>> As they say, YMMV. >>> >> >>> > >>> > I meant it regarding what a single image can do. And it can do >>> thousands of requests only if there is no I/O involved and I doubt this >>> will be a very useful service to build if it does not any additional I/O. >>> Still I would try not to have more than 5 req/s on a single image before >>> scaling up. The only number I can report is that 2 images serving 30 >>> requests/s while using mongodb are not noticable in system stats. >>> > >>> > Norbert >>> >>> That is what I meant: it is an upper limit of an empty REST call, the >>> rest depends on the application and the situation. If your operation takes >>> seconds to complete, the request rate will go way down. >>> >>> But with in memory operations and/or caching, responses can be quite >>> fast (sub 100 ms). >>> >>> >>>

June 26, 2018

Re: [Pharo-users] Microservices using Pharo

by Andrei Stebakov

What would be an example for load balancer for Pharo images? Can we run multiple images on the same server or for the sake of balancing configuration we can only run one image per server? On Tue, Jun 26, 2018, 14:32 Andrei Stebakov <lispercat(a)gmail.com> wrote: > Thanks, guys! I really appreciate your input! > > On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> >> > On 26 Jun 2018, at 15:52, Norbert Hartl <norbert(a)hartl.name> wrote: >> > >> > >> > >> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> >> >> >> >> >>> On 26 Jun 2018, at 15:24, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> >> >>> >> >>> >> >>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lispercat(a)gmail.com >> >: >> >>>> >> >>>> Does anyone use Pharo for Miro services? I heard about Seaside and >> Teapot, just was wondering if Pharo can handle multiple simultaneous >> requests and if it can, where it reaches the limit. >> >>> >> >>> I use it extensively. I use Zinc-REST package to offer services. The >> answer how much it can handle in parallel is hard to answer. For this you >> need to tell what you are about to do. But a rule of thumb is not to exceed >> 5 parallel tasks that are working at the same time. But a lot of tasks have >> wait times while accessing another HTTP service, a database, a filesystem >> etc. For this you can easily go up to 10 I guess. >> >>> >> >>> But these numbers are more of a gut feeling then something scientific >> >>> >> >>> Norbert >> >> >> >> A single ZnServer instance on a single image can handle thousands of >> requests per seconds (local network, very small payload, low concurrency). >> On a modern multi core / multi processor machine with lots of memory you >> can 10s if not 100s of Pharo image under a load balancer, provided you >> either do not share state or use high performance state sharing technology >> - this is the whole point of REST. >> >> >> >> Of course, larger payloads, more complex operations, real world >> networking, etc will slow you down. And it is very easy to make some >> architectural or implementation error somewhere that makes everything slow. >> As they say, YMMV. >> >> >> > >> > I meant it regarding what a single image can do. And it can do >> thousands of requests only if there is no I/O involved and I doubt this >> will be a very useful service to build if it does not any additional I/O. >> Still I would try not to have more than 5 req/s on a single image before >> scaling up. The only number I can report is that 2 images serving 30 >> requests/s while using mongodb are not noticable in system stats. >> > >> > Norbert >> >> That is what I meant: it is an upper limit of an empty REST call, the >> rest depends on the application and the situation. If your operation takes >> seconds to complete, the request rate will go way down. >> >> But with in memory operations and/or caching, responses can be quite fast >> (sub 100 ms). >> >> >>

June 26, 2018

Re: [Pharo-users] Microservices using Pharo

by Andrei Stebakov

Thanks, guys! I really appreciate your input! On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 26 Jun 2018, at 15:52, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > > >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> > >> > >> > >>> On 26 Jun 2018, at 15:24, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > >>> > >>> > >>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lispercat(a)gmail.com>: > >>>> > >>>> Does anyone use Pharo for Miro services? I heard about Seaside and > Teapot, just was wondering if Pharo can handle multiple simultaneous > requests and if it can, where it reaches the limit. > >>> > >>> I use it extensively. I use Zinc-REST package to offer services. The > answer how much it can handle in parallel is hard to answer. For this you > need to tell what you are about to do. But a rule of thumb is not to exceed > 5 parallel tasks that are working at the same time. But a lot of tasks have > wait times while accessing another HTTP service, a database, a filesystem > etc. For this you can easily go up to 10 I guess. > >>> > >>> But these numbers are more of a gut feeling then something scientific > >>> > >>> Norbert > >> > >> A single ZnServer instance on a single image can handle thousands of > requests per seconds (local network, very small payload, low concurrency). > On a modern multi core / multi processor machine with lots of memory you > can 10s if not 100s of Pharo image under a load balancer, provided you > either do not share state or use high performance state sharing technology > - this is the whole point of REST. > >> > >> Of course, larger payloads, more complex operations, real world > networking, etc will slow you down. And it is very easy to make some > architectural or implementation error somewhere that makes everything slow. > As they say, YMMV. > >> > > > > I meant it regarding what a single image can do. And it can do thousands > of requests only if there is no I/O involved and I doubt this will be a > very useful service to build if it does not any additional I/O. Still I > would try not to have more than 5 req/s on a single image before scaling > up. The only number I can report is that 2 images serving 30 requests/s > while using mongodb are not noticable in system stats. > > > > Norbert > > That is what I meant: it is an upper limit of an empty REST call, the rest > depends on the application and the situation. If your operation takes > seconds to complete, the request rate will go way down. > > But with in memory operations and/or caching, responses can be quite fast > (sub 100 ms). > > >

June 26, 2018

Re: [Pharo-users] The cool implication of gtDocumentor gluing examples and how we might augment source naviagation

by Tim Mackinnon

This is all so cool - I see a lot of stuff really coming together (and I still think gtInspector and moldability continue to have legs which nicely underpin documentor). Iâm sad I canât make it to esug this year as Iâd love to be inspired more. Tim Sent from my iPhone > On 26 Jun 2018, at 18:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Tim, > > Thanks a lot for the detailed comments! More inline. > > >> On Jun 26, 2018, at 2:57 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi Doru - Iâll comment inline below: >> >>> On 26 Jun 2018, at 13:05, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>>> On Jun 26, 2018, at 1:16 PM, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> Hi guys - not sure how many people noticed this, but at the end of the tutorial for gtDocumentor, there is a section on Examples as Documentation. >>> >>> Thanks for going through the tutorial. Quick questions: >>> - how did it feel to go through it? >>> - did applying changes work fine for you? >>> - was there any confusion about what happened and where you were in the tutorial? >>> - anything missing that might have helped? >> >> Going through the tutorial felt reasonably intuitive (I have sort of seen people use Jupyter from afar, so I guess I had an idea of what it was trying to do) >> >> I did notice that when I click on the Apply buttons, the change to âAppliedâ was a bit subtle - particular if you scroll back to see if you missed a step. So not sure if colouring the applied buttons or having some kind of Tick might make it a bit more obvious (but it wasnât that bad) > > Ok. > >> Applying the changes seemed to work fine - sometimes examples took a bit of time, (but there is the progress indicator top left - although I was looking at the button that I clicked, so maybe some subtle feedback there might help as well) > > Ok. > >> I didnât really get confused - however I will confess I only superficially followed along and didnât question any of what it was telling me (e.g. what methods actually got created etc.). But conceptually it felt compelling and I believed it. > > This is great! > >> I did find it a little bit sluggish to scroll (on a MacBook Pro 13â 2015 16gb ram) - so sometimes I over scrolled - I also kind of missed having a proper scrollbar in the window to help me understand how far down I was. I already mentioned the diff pane scrolling issue. Also, only being able to resize output boxes down was sometimes a bit frustrating (but workable) > > What do you mean by only being able to resize down? You should be able to resize them up as well. Or did I misunderstand? > >> I wasnât clear on whether I was supposed to be able to edit the markup myself while reading - e.g. putting * around some text didnât make it bold (I kind of thought it might - but maybe thatâs not supported?) > > Bold is not added in the highlighter. Indeed, what you see is a live editor so editing is intended. However, we still have a few issues with it. While they are small, the experience can appear brittle at the moment. > >> When I click on the + or - magnifying glasses, I also canât scroll anymore (so its not like a zoom level - but again maybe this is just how its supposed to work? - clicking circle/square icon put it back to 100% and it worked fine). > > Thanks. We have to update those. > >> Before I loaded the full gToolkit, I did get some messages about things being undefined - but the example still worked and I understood I needed to load something else (and hence asked you here). > > Ok. > >> Something that did cross my mind (and this was something I questioned about Jupyter) - if you want to reuse intermediate results - as in assign a script result to a variable and then reference later down in your text (like when doing a mathâs problem) - it wasnât clear if that is possible and obvious. Something like >> >> X := ${example:GtExamplesTutorial>>#createFileInMemory}$ >> And then you talk about X and then demonstrate something like (making use of X): >> >> ${example:GtExamplesTutorial>>#selectUppcaseLinesFrom: X}$ >> Iâm guessing you can hide it all in the image with global variables - but I was thinking about how we auto define variables in the playground, and then incorporating those in the narrative. > > The document already provides an out variable with the output of the previous snippet, and and outs variable with all results. However, we do want to extend this a bit more. For example, if you define a variable in a script, that variable will be usable in other snippets throughout the document. > > Indeed, we can bring the narrative significantly further than it is now. > >> Anyway I was very impressed (as was the group at UK Smalltalk) - there is lots of legs in this. > > Thanks! > >> Tim >> >> P.s. It was cool that the inspectors work and jump into the gtInspector stuff. I wasnât clear on what all the different tabs are - maybe of which are similar (_Pillar vs _GT) - but I assume this is just the WIP nature of it. I did also get a few talkbacks clicking on items in the inspector -but again WIP or just missing dependencies? > > We are now in a transition period: because we do not have windows and enough widgets in Bloc, we are reusing the existing Morphic-based infrastructure. All presentations that start with _ are rendered in Bloc. _GT is the new bloc-based inspector that has its own extension mechanism. This is what you see when you execute a snippet in Documenter. So, when in the Bloc world, you will only see Bloc based renderings. So, in the near future we will start to get more duplicated renderings(one in Bloc one in Morphin) for various objects. > > Cheers, > Doru > >> >>> >>>> What is neat (and easily missed) is how when an example references another - there is a little triangle you can toggle to expose that example inline. (See photo). >>>> >>>> This isnât a completely new ideas (didnât Newspeak hopscotch do this?) but its very well done in gtDocumentor and this implication could be that if our code editors had this too - then its very handy to unfold code to understand it in one place without having to open new windows. (I still think there are times when you may want to do that - particularly for long chains of methods?) but its certainly an idea that I would be very receptive to having in our code browsers (heck - give me all of gtDocumentor in our source editors). >>> >>> This actually a new take on the nature of an editor. Hopscotch did not allow expanding things inside the text editor. The editor was always a leaf, and it is so in all editors I have seen so far. In our case, the triangle is added live by the syntax highlighter. Right now, we only use it for navigating examples both because we needed to explore how we can make deeply nested examples simple to reason about, and because we wanted to validate the Bloc architecture. >>> >>> Of course, this ability is usable in many different ways. For example, the embedding in Pillar of various artifacts is done using the same mechanisms. And I think you will start seeing all sorts of applications in the UI area that you will simply not see in other places. >>> >>> >>>> Iâm wondering what others thing of this? Perhpas not for Pharo 7 - but Pharo 8 (pretty please?) >>>> >>>> Tim >>>> >>>> p.s. Note to @feenk, as its the last example its incredibly tricky to expand it to actually see it well as you canât scroll further down to then drag the window bigger. I had to add a lot of Crâs to make some space to do this. >>> >>> Thanks. Indeed, the resizer solution you see now is just a first attempt without much polishing. >>> >>> >>> Cheers, >>> Doru >>> >>> >>>> <PastedGraphic-1.png> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > >

June 26, 2018

Re: [Pharo-users] Interesting Pharo Launcher feedback

by Tim Mackinnon

Good point on the potential projects collision (aside: that does nothing in Calypso at the moment right?). I was thinking that in Eclipse or IntelliJ, when you launch the IDE and go to do something, you create a ânew projectâ and typically identify it as a a web project, or Java spring project (so effectively Templates). We kind of do that too donât we? A moose project or a seaside project (although we seem to load more stuff from scratch these days - but potentially maybe weâre missing a trick of not helping someone create a fresh baselineOf to point to some pre-loaded assets in a template image?). I know we often think more about a blank canvas and then explore and pull stuff in as we find it - but if weâre trying to build a bridge for newcomers (particularly students who use other similarish tools) then this terminology is what they would expect. Going back to Benâs point - what then is the project in Calypso. Is my project - eg. PagerDutyWeb is the main project in my image, and it depends on sub projects like Seaside,Willow and NeoJson - or are those latter items libraries? Iâm not actually clear on what our terminology is. In writing this, itâs usefully got me thinking that when I create a Launcher image (project?), rather than name it after the template, as in âPharo 6.1 (stable)â, this should really be meta data on a directory and image called âPagerDutyâ. We have a crude form of that in a file called description.txt, but maybe that should be called image.json and have fields for description, template, build, createdDate etc. Of course this is a bit more work - but as you build up a list of images, it would be handier to manage them better. Tim Sent from my iPhone >> On 26 Jun 2018, at 14:37, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> >> On 6/26/18, Tim Mackinnon <tim(a)testit.works> wrote: >> As I mentioned - the user in question was quite complimentary, just confused >> on first launch. >> >> Equally we donât want to impact power users, and ultimately we want to >> encourage everyone to try newer images to help with improvements. >> >> I honestly think that some slightly improved terminology and a bit of >> guidance to get your first image (eg picking the correct one) is all it >> takes. > > +1 > Maybe just a note on the download website which 'new project' (image) > beginners should go for.... > > --Hannes >> >> Once youâve groked it - you are off. We just want that first experience to >> be pleasant. >> >> I personally like to see the list of images and understand how many builds >> have been made as itâs comforting to see the progress and be encouraged to >> join in. >> >> I as going to propose a simple change to the name on the lists like: >> >> âTemplatesâ -> âImage Templatesâ or maybe even âProject Templatesâ >> >> âImagesâ -> âDownloaded Imagesâ or maybe âCreated Projectsâ >> >> (While we are familiar with the term image, maybe itâs an implementation >> detail - eclipse and IntelliJ create projects, and we arenât so different) >> >> We could also as Cyril suggests, have a little welcome window with some text >> and a picture. >> >> Both really simple to do and probably enough to get people started. After >> all, our audience is reasonable technical so we shouldnât need to dumb It >> down too much. >> >> Iâm also conscious about here is a lot of Pharo 7 work to do as well. >> >> Tim >> >> Sent from my iPhone >> >>> On 26 Jun 2018, at 08:09, Christophe Demarey <christophe.demarey(a)inria.fr> >>> wrote: >>> >>> Hi Tim, >>> >>>> Le 26 juin 2018 Ã 03:00, Ben Coman <btc(a)openinworld.com> a Ã©crit : >>>> >>>> On 26 June 2018 at 06:17, Tim Mackinnon <tim(a)testit.works> wrote: >>>>> Hi everyone - at tonights month UK Smalltalk Meetup, we got some nice >>>>> compliments on the state of Pharo (the participants - all ex small >>>>> talkers - although ex in so much as they fondly remembered it and wanted >>>>> to use it for something relevant now because they enjoyed it in the >>>>> past). >>>>> >>>>> Anyway, one interesting comment stuck out - he had downloaded Pharo >>>>> (having used Visual Age 15+ years ago) and was a bit overwhelmed with >>>>> what laugher presented to him. He didnât hate it - but was initially a >>>>> bit lost as to what it all meant and how to startâ¦ he figured it out, >>>>> but I thought the feedback was interesting and made me think that maybe >>>>> we need some form of intro wizard to get people off to a quick start but >>>>> leave them confident enough that they might come back and try a Pharo 7 >>>>> or Moose etc. >>>>> >>>>> I encouraged him to post something on here, but thoughtI would note it >>>>> (as it seems quite easy to fix) as an idea while it was fresh in my >>>>> mind. >>>> >>>> A welcome tutorial is a good idea. And btw, the sort of idea that only >>>> comes from broader use of PharoLauncher. >>> >>> Thanks for the feedback. >>> We also got this feedback from students. We know we have to improve the UI >>> by simplifying it. >>> Our idea was to only provide a window with a toolbar and the list of >>> images as the main Pharo Launhcer window. >>> On this windows, clicking on the + button will open a Â« wizard Â» like the >>> one for creating repositories in Iceberg. There you could choose to create >>> an image from Â« featured images Â» or ci, etc. >>> >>> It would lower a lot the cognitive charge of the current window. >>> We just need time to implement it. >>> >>> Cheers, >>> Christophe >

June 26, 2018

Re: [Pharo-users] The cool implication of gtDocumentor gluing examples and how we might augment source naviagation

by Tudor Girba

Hi Tim, Thanks a lot for the detailed comments! More inline. > On Jun 26, 2018, at 2:57 PM, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Doru - Iâll comment inline below: > >> On 26 Jun 2018, at 13:05, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >>> On Jun 26, 2018, at 1:16 PM, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi guys - not sure how many people noticed this, but at the end of the tutorial for gtDocumentor, there is a section on Examples as Documentation. >> >> Thanks for going through the tutorial. Quick questions: >> - how did it feel to go through it? >> - did applying changes work fine for you? >> - was there any confusion about what happened and where you were in the tutorial? >> - anything missing that might have helped? > > Going through the tutorial felt reasonably intuitive (I have sort of seen people use Jupyter from afar, so I guess I had an idea of what it was trying to do) > > I did notice that when I click on the Apply buttons, the change to âAppliedâ was a bit subtle - particular if you scroll back to see if you missed a step. So not sure if colouring the applied buttons or having some kind of Tick might make it a bit more obvious (but it wasnât that bad) Ok. > Applying the changes seemed to work fine - sometimes examples took a bit of time, (but there is the progress indicator top left - although I was looking at the button that I clicked, so maybe some subtle feedback there might help as well) Ok. > I didnât really get confused - however I will confess I only superficially followed along and didnât question any of what it was telling me (e.g. what methods actually got created etc.). But conceptually it felt compelling and I believed it. This is great! > I did find it a little bit sluggish to scroll (on a MacBook Pro 13â 2015 16gb ram) - so sometimes I over scrolled - I also kind of missed having a proper scrollbar in the window to help me understand how far down I was. I already mentioned the diff pane scrolling issue. Also, only being able to resize output boxes down was sometimes a bit frustrating (but workable) What do you mean by only being able to resize down? You should be able to resize them up as well. Or did I misunderstand? > I wasnât clear on whether I was supposed to be able to edit the markup myself while reading - e.g. putting * around some text didnât make it bold (I kind of thought it might - but maybe thatâs not supported?) Bold is not added in the highlighter. Indeed, what you see is a live editor so editing is intended. However, we still have a few issues with it. While they are small, the experience can appear brittle at the moment. > When I click on the + or - magnifying glasses, I also canât scroll anymore (so its not like a zoom level - but again maybe this is just how its supposed to work? - clicking circle/square icon put it back to 100% and it worked fine). Thanks. We have to update those. > Before I loaded the full gToolkit, I did get some messages about things being undefined - but the example still worked and I understood I needed to load something else (and hence asked you here). Ok. > Something that did cross my mind (and this was something I questioned about Jupyter) - if you want to reuse intermediate results - as in assign a script result to a variable and then reference later down in your text (like when doing a mathâs problem) - it wasnât clear if that is possible and obvious. Something like > > X := ${example:GtExamplesTutorial>>#createFileInMemory}$ > And then you talk about X and then demonstrate something like (making use of X): > > ${example:GtExamplesTutorial>>#selectUppcaseLinesFrom: X}$ > Iâm guessing you can hide it all in the image with global variables - but I was thinking about how we auto define variables in the playground, and then incorporating those in the narrative. The document already provides an out variable with the output of the previous snippet, and and outs variable with all results. However, we do want to extend this a bit more. For example, if you define a variable in a script, that variable will be usable in other snippets throughout the document. Indeed, we can bring the narrative significantly further than it is now. > Anyway I was very impressed (as was the group at UK Smalltalk) - there is lots of legs in this. Thanks! > Tim > > P.s. It was cool that the inspectors work and jump into the gtInspector stuff. I wasnât clear on what all the different tabs are - maybe of which are similar (_Pillar vs _GT) - but I assume this is just the WIP nature of it. I did also get a few talkbacks clicking on items in the inspector -but again WIP or just missing dependencies? We are now in a transition period: because we do not have windows and enough widgets in Bloc, we are reusing the existing Morphic-based infrastructure. All presentations that start with _ are rendered in Bloc. _GT is the new bloc-based inspector that has its own extension mechanism. This is what you see when you execute a snippet in Documenter. So, when in the Bloc world, you will only see Bloc based renderings. So, in the near future we will start to get more duplicated renderings(one in Bloc one in Morphin) for various objects. Cheers, Doru > >> >>> What is neat (and easily missed) is how when an example references another - there is a little triangle you can toggle to expose that example inline. (See photo). >>> >>> This isnât a completely new ideas (didnât Newspeak hopscotch do this?) but its very well done in gtDocumentor and this implication could be that if our code editors had this too - then its very handy to unfold code to understand it in one place without having to open new windows. (I still think there are times when you may want to do that - particularly for long chains of methods?) but its certainly an idea that I would be very receptive to having in our code browsers (heck - give me all of gtDocumentor in our source editors). >> >> This actually a new take on the nature of an editor. Hopscotch did not allow expanding things inside the text editor. The editor was always a leaf, and it is so in all editors I have seen so far. In our case, the triangle is added live by the syntax highlighter. Right now, we only use it for navigating examples both because we needed to explore how we can make deeply nested examples simple to reason about, and because we wanted to validate the Bloc architecture. >> >> Of course, this ability is usable in many different ways. For example, the embedding in Pillar of various artifacts is done using the same mechanisms. And I think you will start seeing all sorts of applications in the UI area that you will simply not see in other places. >> >> >>> Iâm wondering what others thing of this? Perhpas not for Pharo 7 - but Pharo 8 (pretty please?) >>> >>> Tim >>> >>> p.s. Note to @feenk, as its the last example its incredibly tricky to expand it to actually see it well as you canât scroll further down to then drag the window bigger. I had to add a lot of Crâs to make some space to do this. >> >> Thanks. Indeed, the resizer solution you see now is just a first attempt without much polishing. >> >> >> Cheers, >> Doru >> >> >>> <PastedGraphic-1.png> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

June 26, 2018

Re: [Pharo-users] Microservices using Pharo

by Sven Van Caekenberghe

> On 26 Jun 2018, at 15:52, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> >>> On 26 Jun 2018, at 15:24, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> >>> >>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lispercat(a)gmail.com>: >>>> >>>> Does anyone use Pharo for Miro services? I heard about Seaside and Teapot, just was wondering if Pharo can handle multiple simultaneous requests and if it can, where it reaches the limit. >>> >>> I use it extensively. I use Zinc-REST package to offer services. The answer how much it can handle in parallel is hard to answer. For this you need to tell what you are about to do. But a rule of thumb is not to exceed 5 parallel tasks that are working at the same time. But a lot of tasks have wait times while accessing another HTTP service, a database, a filesystem etc. For this you can easily go up to 10 I guess. >>> >>> But these numbers are more of a gut feeling then something scientific >>> >>> Norbert >> >> A single ZnServer instance on a single image can handle thousands of requests per seconds (local network, very small payload, low concurrency). On a modern multi core / multi processor machine with lots of memory you can 10s if not 100s of Pharo image under a load balancer, provided you either do not share state or use high performance state sharing technology - this is the whole point of REST. >> >> Of course, larger payloads, more complex operations, real world networking, etc will slow you down. And it is very easy to make some architectural or implementation error somewhere that makes everything slow. As they say, YMMV. >> > > I meant it regarding what a single image can do. And it can do thousands of requests only if there is no I/O involved and I doubt this will be a very useful service to build if it does not any additional I/O. Still I would try not to have more than 5 req/s on a single image before scaling up. The only number I can report is that 2 images serving 30 requests/s while using mongodb are not noticable in system stats. > > Norbert That is what I meant: it is an upper limit of an empty REST call, the rest depends on the application and the situation. If your operation takes seconds to complete, the request rate will go way down. But with in memory operations and/or caching, responses can be quite fast (sub 100 ms).

June 26, 2018

[Ann] OSSubprocess v1.0.1

by Guillermo Polito

Hi all, There is a new version of OSSubprocess available. This is a Bugfix release. This release fixes a problem with waitpid that happened regularly and randomly in OSSubprocess users mostly in the CI. For those interesting, the details of the bug can be read in: https://github.com/pharo-contributions/OSSubprocess/issues/36 Bugfix list #39 <https://github.com/pharo-contributions/OSSubprocess/issues/39> travis_wait hides smalltalkCI output #36 <https://github.com/pharo-contributions/OSSubprocess/issues/36> Often get waitpid() -1 in CI Thanks a lot to Pablo and Santi that helped me debugging, Enjoy, Guille

June 26, 2018

Re: [Pharo-users] Microservices using Pharo

by Norbert Hartl

> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 26 Jun 2018, at 15:24, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lispercat(a)gmail.com>: >>> >>> Does anyone use Pharo for Miro services? I heard about Seaside and Teapot, just was wondering if Pharo can handle multiple simultaneous requests and if it can, where it reaches the limit. >> >> I use it extensively. I use Zinc-REST package to offer services. The answer how much it can handle in parallel is hard to answer. For this you need to tell what you are about to do. But a rule of thumb is not to exceed 5 parallel tasks that are working at the same time. But a lot of tasks have wait times while accessing another HTTP service, a database, a filesystem etc. For this you can easily go up to 10 I guess. >> >> But these numbers are more of a gut feeling then something scientific >> >> Norbert > > A single ZnServer instance on a single image can handle thousands of requests per seconds (local network, very small payload, low concurrency). On a modern multi core / multi processor machine with lots of memory you can 10s if not 100s of Pharo image under a load balancer, provided you either do not share state or use high performance state sharing technology - this is the whole point of REST. > > Of course, larger payloads, more complex operations, real world networking, etc will slow you down. And it is very easy to make some architectural or implementation error somewhere that makes everything slow. As they say, YMMV. > I meant it regarding what a single image can do. And it can do thousands of requests only if there is no I/O involved and I doubt this will be a very useful service to build if it does not any additional I/O. Still I would try not to have more than 5 req/s on a single image before scaling up. The only number I can report is that 2 images serving 30 requests/s while using mongodb are not noticable in system stats. Norbert

June 26, 2018