Re: [Pharo-users] Microservices using Pharo

[jtuc...@objektfabrik.de]

Norbert,

Am 26.06.18 um 21:41 schrieb Norbert Hartl:



Am 26.06.2018 um 20:44 schrieb 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?


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.




the last time I checked nginx, the load balancing and sticky session 
stuff was not available in the free edition. So I guess you either pay 
for nginx (which I think is good) or you know some free 3d party addons...


I wonder what exactly the benefit of Docker is in that game? On our 
servers we run 10 images on 4 cores with HT (8 virtual cores) and very 
rareley have real performance problems. We use Glorp, so there is a lot 
of SQL queriing going on for quite basic things already. So my guess 
would be that your "2 images per core"  are conservative and leave air 
for even a third one, depending on all the factors already discussed here.


What's not to underestimate is all the stuff around monitoring and 
restarting images when things go wrong, but that's another story...


Joachim


--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Microservices using Pharo

[jtuc...@objektfabrik.de]

Am 26.06.18 um 20:47 schrieb Andrei Stebakov:
I guess for multiple images on the same server we need to spawn off 
images listening on different ports.


exactly. We use Apache mod_proxy_balancer with sticky sessions for our 
configuration. The sticky session part is important if you use Seaside 
(share everything approach with state living on the server).


We do have problems with mod_proxy_balancer when an image gets stuck, 
because it is not actively monitoring its backends, so there are better 
options out there that we need to investigate once we havetime. Luckily, 
our Smalltalk images turn put to be very stable, the bottleneck being 
DB2 (surprisingly).


Joachim


--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

Re: [Pharo-users] copy & paste

[Otto Behrens]

>
> > The stable version on opensuse is quite old. And apparently not 6.1.
> > So, does this sadly mean that the paragraph on the top of the page
> > "Zip file" is updated, but the rest of the page not?
>
> Very likely, as the Zip packager (human) is probable not the Suse
> packager (another human)
>
> Does the zip package work for you?
>

I prefer to use the deb package because I make it part of my ubuntu
installation.

Does this mean that even the .zip package could be old?

I would just like to generally say that this could influence how people out
there see Pharo. If a newbie tries it out, he or she may just get stuck
with stupid things like this copy & paste (by trying to copy an example
from the Pharo site), only to realise that this is an old version. It gives
the impression that the "stable" version is not stable. Old campaigners
like me might persist, but most people will give up right here.

I think I should revert to the .zip.

Re: [Pharo-users] [Dynabook][Morphic][TLM][Geometry] Re: [ANN] GNU Dr. Geo release 18.06

[Hilaire]

As I am only reading this list throught Gname newsgroup I can't read the
senders' email, so please email me at hilaire [at] drgeo.eu so we can
engage a private conversation

Hilaire



Le 26/06/2018 à 05:41, H. Hirzel a écrit :
> This message is off-list as I do not have the capacity NOW  to
> maintain a conversation on this list.

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] copy & paste

[Hilaire]

Le 26/06/2018 à 05:48, Otto Behrens a écrit :
>
>
> We use the package installation for ubuntu described
> here: https://pharo.org/gnu-linux-installation-64.
>
> The stable version on opensuse is quite old. And apparently not 6.1.
> So, does this sadly mean that the paragraph on the top of the page
> "Zip file" is updated, but the rest of the page not?

Very likely, as the Zip packager (human) is probable not the Suse
packager (another human)

Does the zip package work for you?

Hilaire

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Microservices using Pharo

[Norbert Hartl]

> Am 26.06.2018 um 20:44 schrieb 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?
> 
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  wrote:
>> Thanks, guys! I really appreciate your input!
>> 
>>> On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe  wrote:
>>> 
>>> 
>>> > On 26 Jun 2018, at 15:52, Norbert Hartl  wrote:
>>> > 
>>> > 
>>> > 
>>> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe :
>>> >> 
>>> >> 
>>> >> 
>>> >>> On 26 Jun 2018, at 15:24, Norbert Hartl  wrote:
>>> >>> 
>>> >>> 
>>> >>> 
>>>  Am 26.06.2018 um 14:52 schrieb Andrei Stebakov :
>>>  
>>>  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).
>>> 
>>> 

Re: [Pharo-users] Microservices using Pharo

[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  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  wrote:
>
>> Thanks, guys! I really appreciate your input!
>>
>> On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe  wrote:
>>
>>>
>>>
>>> > On 26 Jun 2018, at 15:52, Norbert Hartl  wrote:
>>> >
>>> >
>>> >
>>> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe :
>>> >>
>>> >>
>>> >>
>>> >>> On 26 Jun 2018, at 15:24, Norbert Hartl  wrote:
>>> >>>
>>> >>>
>>> >>>
>>>  Am 26.06.2018 um 14:52 schrieb Andrei Stebakov >> >:
>>> 
>>>  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).
>>>
>>>
>>>

Re: [Pharo-users] Microservices using Pharo

[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  wrote:

> Thanks, guys! I really appreciate your input!
>
> On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe  wrote:
>
>>
>>
>> > On 26 Jun 2018, at 15:52, Norbert Hartl  wrote:
>> >
>> >
>> >
>> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe :
>> >>
>> >>
>> >>
>> >>> On 26 Jun 2018, at 15:24, Norbert Hartl  wrote:
>> >>>
>> >>>
>> >>>
>>  Am 26.06.2018 um 14:52 schrieb Andrei Stebakov > >:
>> 
>>  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).
>>
>>
>>

Re: [Pharo-users] Microservices using Pharo

[Andrei Stebakov]

Thanks, guys! I really appreciate your input!

On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe  wrote:

>
>
> > On 26 Jun 2018, at 15:52, Norbert Hartl  wrote:
> >
> >
> >
> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe :
> >>
> >>
> >>
> >>> On 26 Jun 2018, at 15:24, Norbert Hartl  wrote:
> >>>
> >>>
> >>>
>  Am 26.06.2018 um 14:52 schrieb Andrei Stebakov :
> 
>  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).
>
>
>

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

[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  wrote:
> 
> Hi Tim,
> 
> Thanks a lot for the detailed comments! More inline.
> 
> 
>> On Jun 26, 2018, at 2:57 PM, Tim Mackinnon  wrote:
>> 
>> Hi Doru - I’ll comment inline below:
>> 
>>> On 26 Jun 2018, at 13:05, Tudor Girba  wrote:
>>> 
>>> Hi,
>>> 
 On Jun 26, 2018, at 1:16 PM, Tim Mackinnon  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 

Re: [Pharo-users] Interesting Pharo Launcher feedback

[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  wrote:
>> 
>> On 6/26/18, Tim Mackinnon  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 
>>> wrote:
>>> 
>>> Hi Tim,
>>> 
 Le 26 juin 2018 à 03:00, Ben Coman  a écrit :
 
 On 26 June 2018 at 06:17, Tim Mackinnon  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 

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

[Tudor Girba]

Hi Tim,

Thanks a lot for the detailed comments! More inline.


> On Jun 26, 2018, at 2:57 PM, Tim Mackinnon  wrote:
> 
> Hi Doru - I’ll comment inline below:
> 
>> On 26 Jun 2018, at 13:05, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>>> On Jun 26, 2018, at 1:16 PM, Tim Mackinnon  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 

Re: [Pharo-users] Microservices using Pharo

[Sven Van Caekenberghe]

> On 26 Jun 2018, at 15:52, Norbert Hartl  wrote:
> 
> 
> 
>> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe :
>> 
>> 
>> 
>>> On 26 Jun 2018, at 15:24, Norbert Hartl  wrote:
>>> 
>>> 
>>> 
 Am 26.06.2018 um 14:52 schrieb Andrei Stebakov :
 
 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).

[Pharo-users] [Ann] OSSubprocess v1.0.1

[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 
travis_wait hides smalltalkCI output
#36  Often
get waitpid() -1 in CI

Thanks a lot to Pablo and Santi that helped me debugging,
Enjoy,
Guille

Re: [Pharo-users] Microservices using Pharo

[Norbert Hartl]

> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 26 Jun 2018, at 15:24, Norbert Hartl  wrote:
>> 
>> 
>> 
>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov :
>>> 
>>> 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

Re: [Pharo-users] Microservices using Pharo

[Sven Van Caekenberghe]

> On 26 Jun 2018, at 15:24, Norbert Hartl  wrote:
> 
> 
> 
>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov :
>> 
>> 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.

Sven

Re: [Pharo-users] Interesting Pharo Launcher feedback

[H. Hirzel]

On 6/26/18, Tim Mackinnon  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 
>> wrote:
>>
>> Hi Tim,
>>
>>> Le 26 juin 2018 à 03:00, Ben Coman  a écrit :
>>>
>>> On 26 June 2018 at 06:17, Tim Mackinnon  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
>>
>>
>

Re: [Pharo-users] Microservices using Pharo

[Norbert Hartl]

> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov :
> 
> 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

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

[Tim Mackinnon]

Hi Doru - I’ll comment inline below:

> On 26 Jun 2018, at 13:05, Tudor Girba  wrote:
> 
> Hi,
> 
>> On Jun 26, 2018, at 1:16 PM, Tim Mackinnon  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)

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)

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. 

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)

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?)

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).

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).

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.

Anyway I was very impressed (as was the group at UK Smalltalk) - there is lots 
of legs in this.

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?


> 
>> 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 

[Pharo-users] Microservices using Pharo

[Andrei Stebakov]

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.

Re: [Pharo-users] Pharo 7, Iceberg, Proxy and Windows

[Vitor Medina Cruz]

Thanks Guille, will do that on further occasions, I just got excited to
make it work for me :)

I had see the page you sent already, but git works fine in any other
program here (eg. command line, Intellij and Sourcetree) so I don't think
the problem here is related to what was described by the stackoverflow page
(and, well, I don't have admin rights in this machine, so I am unable to
apply the proposed patch  :(  ).

Anyways, I will try to use Iceberg only for commit/fetch and make the
pull/push from command line.

Regards,
Vitor


On Mon, Jun 25, 2018 at 6:23 AM, Guillermo Polito  wrote:

> Hi Vitor,
>
> I've created an issue with your problem.
>
> https://github.com/pharo-vcs/iceberg/issues/885
>
> I encourage you to do so too, because following the mailing list is
> sometimes hard :)
>
> About your second issue, you should know that libgit (
> libgit2.github.com/libgit2) will mostly bypass git and reimplement most
> of its features.
> So, most of the times it will read git's settings, and some other times
> not.
> And also there is the possibility that Iceberg overrides those settings
> too.
>
> For example, your fix
>
> *self prim_fetch_opts prim_proxy_opts prim_type: LGitProxyTypeEnum
> git_proxy_auto*
>
> does enable automatic proxy verification and forbids people to set their
> own proxy.
> Not saying that this is bad but the contrary: I think it is a really good
> default value :).
>
> Similar to that there are the ssh verifications on Iceberg. So far
>  - we do not check the certificate stores from the machine (we could
> through FFI, the sub-project is listed in here https://github.com/pharo-
> vcs/iceberg/wiki/How-to-help-us,-What-you-could-contribute)
>  - I don't think so far there is a hook to "disable ssh verification".
> This could be dangerous...
>
> I've googled the error a bit, and found this. Maybe you can try it and see
> wether the solution belongs to iceberg, or that we should enhance the
> documentation?
>
> https://stackoverflow.com/questions/48985995/gitkraken-
> and-github-failed-to-get-server-certificate-the-handle-is-in-the-wr
>
> Tx,
> Guille
>
> On Thu, Jun 21, 2018 at 5:49 PM Vitor Medina Cruz 
> wrote:
>
>> I am sorry, the correct message is "LGit_GIT_ERROR: failed to get server
>> certificate: The handle is in the wrong state for the requested operation".
>>
>>
>> I tried to add corporate certificates to the git curl-ca-bundle.crt, I
>> tried to git config --global http.sslVerify false also, no success... :(
>>
>> On Thu, Jun 21, 2018 at 9:31 AM, Vitor Medina Cruz 
>> wrote:
>>
>>> Ok, I forgot to mention I have changed 
>>> LGitRepository>>clone:url:local_path:options:,
>>> but for some odd reason it's arguments names were switched to arg 1, arg2,
>>> arg3 etc, so the out error was because was renamed to one of those generic
>>> arg names. I figure that out looking at the versions of the methods, and it
>>> apers that when I first access it this change is made.
>>>
>>> Anyways, I fixed that and I still get "IceGenericError: failed to get
>>> server certificate: The identifier is not in the correct state for the
>>> resquested operation"
>>>
>>> On Wed, Jun 20, 2018 at 4:49 PM, Vitor Medina Cruz >> > wrote:
>>>
 Hello,

 Iceberg fail to function behind a proxy on Pharo 7 32bits Windows. When
 I try to clone I get a:

 IceGenericError: failed to get server certificate: The identifier is
 not in the correct state for the resquested operation

 I had a similar problem some time ago with Pharo 6, in which I made a
 local hot fix after questioning here. The fix was to the LGitCloneOptions
 and LGitFetchOptions both at the initializeWithDefaults, currently this
 method on LGitCloneOptions is like this:


 initializeWithDefaults
 self withReturnHandlerDo: [
 self
 clone_init_options: self
 version: LGitOptionsVersionsEnum
 git_clone_options_version_1 ].



 *self prim_fetch_opts prim_proxy_opts prim_type: LGitProxyTypeEnum
 git_proxy_auto*
 The bold is the fix, but it should come first in the method:

 initializeWithDefaults


 *self prim_fetch_opts prim_proxy_opts prim_type: LGitProxyTypeEnum
 git_proxy_auto*self withReturnHandlerDo: [
 self
 clone_init_options: self
 version: LGitOptionsVersionsEnum
 git_clone_options_version_1 ].


 That way worked on Pharo 6, but now I got a:

 "FFIVariableNameNotFound: Could not find accessor for variable named
 'out'"

 Any clues?

 Regards,
 Vitor

>>>
>>>
>>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> 

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

[Sean P. DeNigris]

Tim Mackinnon wrote
> its very handy to unfold code to understand it in one place

There is also a Code Bubble-like demo from Feenk.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[Tudor Girba]

Hi,

> On Jun 26, 2018, at 1:16 PM, Tim Mackinnon  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?


> 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


> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-users] Interesting Pharo Launcher feedback

[Sean P. DeNigris]

Tim Mackinnon wrote
> maybe the project metaphor isn’t a bad one?

Let's sync with Denis because Calypso already has a stub for "Projects" and
we don't want to overload this term adding to the confusion!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [Moose-dev] [ann] gt documenter

[Tudor Girba]

Hi,

Thanks for trying it out.

I never encountered the issue you mentioned. However, the red cross appears due 
to a Morphic-related problem, not a Bloc one.

Cheers,
Doru



> On Jun 26, 2018, at 11:44 AM, Tim Mackinnon  wrote:
> 
> Hi - yes, doing the Reset Bloc did fix the problem and I can run both 
> examples (and it doesn’t appear to break after running one or the other). 
> HOWEVER - after the reset, when I ran the example with the Mondrian views - 
> right near the beginning where it opens a Pharo browser - the GTDocumentor 
> window turned red with a cross (Note: I had done inspect on the example vs. a 
> playground so I could have a bigger window. I only now noticed that the 
> playground doesn’t use a splitter to let you resize its panes?). 
> 
> I had to close my document and try it again - and this time it was fine - but 
> obviously something broke in the sequence of events.
> 
> Tim
> 
>> On 26 Jun 2018, at 06:02, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> It looks like something broke in your Bloc. You can reset Bloc from the 
>> world menu / Bloc / Reset Bloc. Please let me know if it works.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jun 26, 2018, at 12:54 AM, Tim Mackinnon  wrote:
>>> 
>>> Hi - so I managed to load up the full monty gtDocumentor into an image (a 
>>> few false starts as it you try and load the full monty on top of just 
>>> gtDocumentor e.g in a clean image load
>>> 
>>> Metacello new
>>>  baseline: 'GToolkit';
>>>  repository: '
>>> github://feenkcom/gtoolkit/src
>>> ';
>>>  load.
>>> 
>>> On top of this
>>> Metacello new
>>>  baseline: 'GToolkitDocumenter';
>>>  repository: '
>>> github://feenkcom/gtoolkit-documenter/src
>>> ';
>>>  load.
>>> 
>>> 
>>> It never completes - I gave up after 30 minutes and whining fans on a 
>>> MacBook Pro.
>>> 
>>> Anyway - in a completely clean image I loaded just GTookkit and then run
>>> 
>>> GtDocumenter editorForText: BrToggleExamples comment.
>>> 
>>> Which seemed to work fine - and showed me some buttons with different dots 
>>> on them.
>>> 
>>> So then I went and tried the example I really wanted to see:
>>> 
>>> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 
>>> 'doc' / 'tutorial' / 'examples-tutorial.pillar’. 
>>> 
>>> And it just gives a blank tab in the _Pillar, _Contents and _GT tabs? The 
>>> contents tab does show me pillar text unrendered.
>>> 
>>> Interestingly, If I then go back to the previous editorForText example, 
>>> that did work - it now also also show the same blank tabs. So it seems that 
>>> something get broken?
>>> 
>>> This is on OSX with the a 64bit image - labelled 6.1 - 64bit (tech preview) 
>>> - so the current stable pharo for 64 bit.
>>> 
>>> Is this a known issue?
>>> 
>>> Tim
>>> 
>>> 
 On 20 Jun 2018, at 02:53, Tim Mackinnon  wrote:
 
 Actually I realised it ended up on the be moose forum - here’s what Doru 
 replied (for any lurkers)
 
 
 
 Sent from my iPhone
> On Jun 18, 2018, at 1:21 PM, Tim Mackinnon  wrote:
> 
> Guys this is really impressive!
 
 Thanks.
 
 
> 2 things I noticed when going through the example in a new Pharo 6.1 
> image (with the latest Iceberg) -
> 
> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
> be worth a note in the readme (I’ll submit a PR)
 Show Quoted Content
> 2 things I noticed when going through the example in a new Pharo 6.1 
> image (with the latest Iceberg) -
> 
> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
> be worth a note in the readme (I’ll submit a PR)
 
 Ok.
 
 
> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian 
> DNU) when you try any of the graphical bits , making me think either the 
> dependencies are incorrect  on the Baseline (or the instruction for the 
> example also need to mention you need to load something else - presumably 
> Roassal?
 
 Indeed, this is due to the fact that loading GToolkitDocumenter does not 
 load GToolkitVisualizer which includes GtMondrian. We are still working on 
 finding the right dependencies balance.
 
 Until then, please load the whole GToolkit to get the full support.
 
 
> 3) You can’t scroll the Diff tabs of results, only the Code tabs
 
 Good catch!
 
 
 Cheers,
 Doru
 
 Sent from my iPhone
 
 On 20 Jun 2018, at 02:47, Tim Mackinnon  wrote:
 
> Bump (not sure this got through , and keen to know how to load the 
> diagramming bit)
> 
> Guys this is really impressive!
> 
> 2 

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

[Tim Mackinnon]

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.

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).

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.

Re: [Pharo-users] [Moose-dev] [ann] gt documenter

[Tim Mackinnon]

Hi - yes, doing the Reset Bloc did fix the problem and I can run both examples 
(and it doesn’t appear to break after running one or the other). HOWEVER - 
after the reset, when I ran the example with the Mondrian views - right near 
the beginning where it opens a Pharo browser - the GTDocumentor window turned 
red with a cross (Note: I had done inspect on the example vs. a playground so I 
could have a bigger window. I only now noticed that the playground doesn’t use 
a splitter to let you resize its panes?). 

I had to close my document and try it again - and this time it was fine - but 
obviously something broke in the sequence of events.

Tim

> On 26 Jun 2018, at 06:02, Tudor Girba  wrote:
> 
> Hi,
> 
> It looks like something broke in your Bloc. You can reset Bloc from the world 
> menu / Bloc / Reset Bloc. Please let me know if it works.
> 
> Cheers,
> Doru
> 
> 
>> On Jun 26, 2018, at 12:54 AM, Tim Mackinnon  wrote:
>> 
>> Hi - so I managed to load up the full monty gtDocumentor into an image (a 
>> few false starts as it you try and load the full monty on top of just 
>> gtDocumentor e.g in a clean image load
>> 
>> Metacello new
>>   baseline: 'GToolkit';
>>   repository: '
>> github://feenkcom/gtoolkit/src
>> ';
>>   load.
>> 
>> On top of this
>> Metacello new
>>   baseline: 'GToolkitDocumenter';
>>   repository: '
>> github://feenkcom/gtoolkit-documenter/src
>> ';
>>   load.
>> 
>> 
>> It never completes - I gave up after 30 minutes and whining fans on a 
>> MacBook Pro.
>> 
>> Anyway - in a completely clean image I loaded just GTookkit and then run
>> 
>> GtDocumenter editorForText: BrToggleExamples comment.
>> 
>> Which seemed to work fine - and showed me some buttons with different dots 
>> on them.
>> 
>> So then I went and tried the example I really wanted to see:
>> 
>> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' 
>> / 'tutorial' / 'examples-tutorial.pillar’. 
>> 
>> And it just gives a blank tab in the _Pillar, _Contents and _GT tabs? The 
>> contents tab does show me pillar text unrendered.
>> 
>> Interestingly, If I then go back to the previous editorForText example, that 
>> did work - it now also also show the same blank tabs. So it seems that 
>> something get broken?
>> 
>> This is on OSX with the a 64bit image - labelled 6.1 - 64bit (tech preview) 
>> - so the current stable pharo for 64 bit.
>> 
>> Is this a known issue?
>> 
>> Tim
>> 
>> 
>>> On 20 Jun 2018, at 02:53, Tim Mackinnon  wrote:
>>> 
>>> Actually I realised it ended up on the be moose forum - here’s what Doru 
>>> replied (for any lurkers)
>>> 
>>> 
>>> 
>>> Sent from my iPhone
 On Jun 18, 2018, at 1:21 PM, Tim Mackinnon  wrote:
 
 Guys this is really impressive!
>>> 
>>> Thanks.
>>> 
>>> 
 2 things I noticed when going through the example in a new Pharo 6.1 image 
 (with the latest Iceberg) -
 
 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
 has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
 be worth a note in the readme (I’ll submit a PR)
>>> Show Quoted Content
 2 things I noticed when going through the example in a new Pharo 6.1 image 
 (with the latest Iceberg) -
 
 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
 has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
 be worth a note in the readme (I’ll submit a PR)
>>> 
>>> Ok.
>>> 
>>> 
 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian 
 DNU) when you try any of the graphical bits , making me think either the 
 dependencies are incorrect  on the Baseline (or the instruction for the 
 example also need to mention you need to load something else - presumably 
 Roassal?
>>> 
>>> Indeed, this is due to the fact that loading GToolkitDocumenter does not 
>>> load GToolkitVisualizer which includes GtMondrian. We are still working on 
>>> finding the right dependencies balance.
>>> 
>>> Until then, please load the whole GToolkit to get the full support.
>>> 
>>> 
 3) You can’t scroll the Diff tabs of results, only the Code tabs
>>> 
>>> Good catch!
>>> 
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> Sent from my iPhone
>>> 
>>> On 20 Jun 2018, at 02:47, Tim Mackinnon  wrote:
>>> 
 Bump (not sure this got through , and keen to know how to load the 
 diagramming bit)
 
 Guys this is really impressive!
 
 2 things I noticed when going through the example in a new Pharo 6.1 image 
 (with the latest Iceberg) -
 
 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
 has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
 be worth a note in the readme (I’ll 

Re: [Pharo-users] Interesting Pharo Launcher feedback

[Tim Mackinnon]

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.

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  
> wrote:
> 
> Hi Tim,
> 
>> Le 26 juin 2018 à 03:00, Ben Coman  a écrit :
>> 
>> On 26 June 2018 at 06:17, Tim Mackinnon  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
> 
> 

Re: [Pharo-users] StCAD is open source

[Cédrick Béler]

Excellent !

(BTW, I have problem opening your website). 

It will be hard to port to pharo ?
The main difficulty is to have an equivalent for GF/ST 2D ?

Cheers,

Cedrick 

> Le 25 juin 2018 à 21:05, Hilaire  a écrit :
> 
> Impressive!
> 
> Hilaire
> 
> 
>> Le 25/06/2018 à 02:05, askoh a écrit :
>> I have just open source StCAD (MIT license) which has the code for freeCAD.
>> http://askoh.com/stcad
>> Although written in VisualWorks Smalltalk, I hope Pharo users will port it
>> in part or whole.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-users] Interesting Pharo Launcher feedback

[Christophe Demarey]

Hi Tim,

> Le 26 juin 2018 à 03:00, Ben Coman  a écrit :
> 
> On 26 June 2018 at 06:17, Tim Mackinnon  > 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

Re: [Pharo-users] Interesting Pharo Launcher feedback

[Cyril Ferlicot]

On mar. 26 juin 2018 at 00:18, Tim Mackinnon  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.
>
> Tim
>
Hi,

It is disabled in development I think but with a released version there is
a Welcome window. Maybe it should be where we add more tutorials.
-- 
Cyril Ferlicot
https://ferlicot.fr