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

[Yuriy Tymchuk]

By the way, we need to add a rubric highlighting to the classes somehow :).

Uko



> On 12 Dec 2016, at 13:36, Marcus Denker  wrote:
> 
> Hello,
> 
> Not yet. It should be easy to add if we find a good API for it…
> 
> I will work on it this week (I have blocked some time for RF related hacking).
> 
> e.g I think we have to extend the syntax for reifications to use classes.
> 
> something like:
> 
> arguments: {RFTempReification named: #trachelCanvas};
> 
> The current symbols then would be the same as using
> 
> RFReification named: #object
> 
> But subclasses can be used directly and parametrized.
> 
>   Marcus
> 
>> On 5 Dec 2016, at 20:42, Peter Uhnak  wrote:
>> 
>> Hi,
>> 
>> what is the best way to access variables from within a metalink?
>> 
>> for example I have a message send `surface clear` and I want to change it to 
>> `surface clear: trachelCanvas color`.
>> 
>> I can use #instVarNamed:
>> 
>> ```
>> MetaLink new
>>  metaObject: [ :object |
>>  (object instVarNamed: #surface) clear: (object instVarNamed: 
>> #trachelCanvas) color.
>>  ];
>>  selector: #value:;
>>  arguments: #(object);
>>  control: #instead.
>> ```
>> 
>> but the above isn't exactly nice, plus it wouldn't work with temporary 
>> variables.
>> 
>> Thanks,
>> Peter
>> 
> 
> 

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

[Dimitris Chloupis]

On Tue, Dec 13, 2016 at 6:15 PM horrido  wrote:

> Fellow Pharoers: What is the most exciting development in 2017 to look
> forward to? I'm asking for things to put into the end-of-year post in my
> "Make Smalltalk Great Again!" campaign. Thanks.
>

I would not call it "most exciting development" for anyone but is
definitely for me

Generally the plans for my project Ephestos for 2017 are

1) To create an Unreal API for Pharo
2) To create a Blender API for Pharo
3) To create a Supercollider API for Pharo

Unreal is the most powerful game/graphics engine.
Blender is the most powerful 3d editor.
Supercollider is the most powerful live coding music and audio synthesis
platform.

I have developed the foundation for all three , the only thing remaining
know is to wrap their APIs for Pharo.

So by end of 2017 Pharo will have received a massive boost to its 2d and 3d
graphics capabilities and
music and audio synthesis capabilities.

Supercollider part is not a high priority goal as the other two, but I
think I can squeeze it through.

Low priority goals and less exciting for me are

1) improvements to Nireas expanding its customisability, recreating the GUI
, improving the blue theme and offer multiple other themes too
2) a tool that unifies workspace, system browser and inspector under one
roof. I have not tested yet grafoscopio in detail, so it may form the basis
for this tool
3)  further contributions to Pharo By Example and possibly other books

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

[Ben Coman]

On Wed, Dec 14, 2016 at 5:15 PM, Dimitris Chloupis 
wrote:

>
> On Tue, Dec 13, 2016 at 6:15 PM horrido  wrote:
>
>> Fellow Pharoers: What is the most exciting development in 2017 to look
>> forward to? I'm asking for things to put into the end-of-year post in my
>> "Make Smalltalk Great Again!" campaign. Thanks.
>>
>
> I would not call it "most exciting development" for anyone but is
> definitely for me
>
> Generally the plans for my project Ephestos for 2017 are
>
> 1) To create an Unreal API for Pharo
> 2) To create a Blender API for Pharo
> 3) To create a Supercollider API for Pharo
>
> Unreal is the most powerful game/graphics engine.
> Blender is the most powerful 3d editor.
> Supercollider is the most powerful live coding music and audio synthesis
> platform.
>

> I have developed the foundation for all three , the only thing remaining
> know is to wrap their APIs for Pharo.
>
> So by end of 2017 Pharo will have received a massive boost to its 2d and
> 3d graphics capabilities and
> music and audio synthesis capabilities.
>

I like your ambition and you seem to be having great fun, so good luck.
cheers -ben


>
> Supercollider part is not a high priority goal as the other two, but I
> think I can squeeze it through.
>
> Low priority goals and less exciting for me are
>
> 1) improvements to Nireas expanding its customisability, recreating the
> GUI , improving the blue theme and offer multiple other themes too
> 2) a tool that unifies workspace, system browser and inspector under one
> roof. I have not tested yet grafoscopio in detail, so it may form the basis
> for this tool
> 3)  further contributions to Pharo By Example and possibly other books
>
>

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

[Marcus Denker]

There is a MetalinkIconStyler already.

But I think that it is better to have stylers for the users of metalinks, e.g. 
there is a special
styler for breakpoints.

I see the general styler more as a debug tool (it is off by default).

Marcus
> On 14 Dec 2016, at 05:10, Yuriy Tymchuk  wrote:
> 
> By the way, we need to add a rubric highlighting to the classes somehow :).
> 
> Uko
> 
> 
> 
>> On 12 Dec 2016, at 13:36, Marcus Denker  wrote:
>> 
>> Hello,
>> 
>> Not yet. It should be easy to add if we find a good API for it…
>> 
>> I will work on it this week (I have blocked some time for RF related 
>> hacking).
>> 
>> e.g I think we have to extend the syntax for reifications to use classes.
>> 
>> something like:
>> 
>> arguments: {RFTempReification named: #trachelCanvas};
>> 
>> The current symbols then would be the same as using
>> 
>> RFReification named: #object
>> 
>> But subclasses can be used directly and parametrized.
>> 
>>  Marcus
>> 
>>> On 5 Dec 2016, at 20:42, Peter Uhnak  wrote:
>>> 
>>> Hi,
>>> 
>>> what is the best way to access variables from within a metalink?
>>> 
>>> for example I have a message send `surface clear` and I want to change it 
>>> to `surface clear: trachelCanvas color`.
>>> 
>>> I can use #instVarNamed:
>>> 
>>> ```
>>> MetaLink new
>>> metaObject: [ :object |
>>> (object instVarNamed: #surface) clear: (object instVarNamed: 
>>> #trachelCanvas) color.
>>> ];
>>> selector: #value:;
>>> arguments: #(object);
>>> control: #instead.
>>> ```
>>> 
>>> but the above isn't exactly nice, plus it wouldn't work with temporary 
>>> variables.
>>> 
>>> Thanks,
>>> Peter
>>> 
>> 
>> 
> 
> 

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

[Dimitris Chloupis]

Thank you Ben , but just to clarify those APIs will be partial and depend
on the needs of a game I develop. Obviously it's unrealistic to wrap the
entire Blender or Unreal API in a single year. Each one contains over ten
thousands methods. Probably in a year I can do one hundred methods each
maybe more again depending on the needs of the game.

But I am looking into automatic wrapping like Igor did for NBOpenGL using
header files so I won't need to do this manually which is both time
consuming and boring.

Documentation is also the same story, I won't be porting it to Pharo, again
because I don't need to. That means the user will need to understand both
APIs and know both Python and c++.

So my "ambition" is far smaller than it may seem. In the end I am just one
guy with limited time like most of you.
On Wed, 14 Dec 2016 at 12:46, Ben Coman  wrote:

> On Wed, Dec 14, 2016 at 5:15 PM, Dimitris Chloupis 
> wrote:
>
>
> On Tue, Dec 13, 2016 at 6:15 PM horrido  wrote:
>
> Fellow Pharoers: What is the most exciting development in 2017 to look
> forward to? I'm asking for things to put into the end-of-year post in my
> "Make Smalltalk Great Again!" campaign. Thanks.
>
>
> I would not call it "most exciting development" for anyone but is
> definitely for me
>
> Generally the plans for my project Ephestos for 2017 are
>
> 1) To create an Unreal API for Pharo
> 2) To create a Blender API for Pharo
> 3) To create a Supercollider API for Pharo
>
> Unreal is the most powerful game/graphics engine.
> Blender is the most powerful 3d editor.
> Supercollider is the most powerful live coding music and audio synthesis
> platform.
>
>
> I have developed the foundation for all three , the only thing remaining
> know is to wrap their APIs for Pharo.
>
> So by end of 2017 Pharo will have received a massive boost to its 2d and
> 3d graphics capabilities and
> music and audio synthesis capabilities.
>
>
> I like your ambition and you seem to be having great fun, so good luck.
> cheers -ben
>
>
>
> Supercollider part is not a high priority goal as the other two, but I
> think I can squeeze it through.
>
> Low priority goals and less exciting for me are
>
> 1) improvements to Nireas expanding its customisability, recreating the
> GUI , improving the blue theme and offer multiple other themes too
> 2) a tool that unifies workspace, system browser and inspector under one
> roof. I have not tested yet grafoscopio in detail, so it may form the basis
> for this tool
> 3)  further contributions to Pharo By Example and possibly other books
>
>

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

[Yuriy Tymchuk]

Ah, looks like I didn’t read the topic correctly… I’d like to have styling for 
the class template, because it is a bit complicated to highlight variables.

Uko

> On 14 Dec 2016, at 12:44, Marcus Denker  wrote:
> 
> There is a MetalinkIconStyler already.
> 
> But I think that it is better to have stylers for the users of metalinks, 
> e.g. there is a special
> styler for breakpoints.
> 
> I see the general styler more as a debug tool (it is off by default).
>   
>   Marcus
>> On 14 Dec 2016, at 05:10, Yuriy Tymchuk  wrote:
>> 
>> By the way, we need to add a rubric highlighting to the classes somehow :).
>> 
>> Uko
>> 
>> 
>> 
>>> On 12 Dec 2016, at 13:36, Marcus Denker  wrote:
>>> 
>>> Hello,
>>> 
>>> Not yet. It should be easy to add if we find a good API for it…
>>> 
>>> I will work on it this week (I have blocked some time for RF related 
>>> hacking).
>>> 
>>> e.g I think we have to extend the syntax for reifications to use classes.
>>> 
>>> something like:
>>> 
>>> arguments: {RFTempReification named: #trachelCanvas};
>>> 
>>> The current symbols then would be the same as using
>>> 
>>> RFReification named: #object
>>> 
>>> But subclasses can be used directly and parametrized.
>>> 
>>> Marcus
>>> 
 On 5 Dec 2016, at 20:42, Peter Uhnak  wrote:
 
 Hi,
 
 what is the best way to access variables from within a metalink?
 
 for example I have a message send `surface clear` and I want to change it 
 to `surface clear: trachelCanvas color`.
 
 I can use #instVarNamed:
 
 ```
 MetaLink new
metaObject: [ :object |
(object instVarNamed: #surface) clear: (object instVarNamed: 
 #trachelCanvas) color.
];
selector: #value:;
arguments: #(object);
control: #instead.
 ```
 
 but the above isn't exactly nice, plus it wouldn't work with temporary 
 variables.
 
 Thanks,
 Peter
 
>>> 
>>> 
>> 
>> 
> 
> 

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

[Marcus Denker]

Ah, yes. And context menus…

> On 14 Dec 2016, at 10:46, Yuriy Tymchuk  wrote:
> 
> Ah, looks like I didn’t read the topic correctly… I’d like to have styling 
> for the class template, because it is a bit complicated to highlight 
> variables.
> 
> Uko
> 
>> On 14 Dec 2016, at 12:44, Marcus Denker  wrote:
>> 
>> There is a MetalinkIconStyler already.
>> 
>> But I think that it is better to have stylers for the users of metalinks, 
>> e.g. there is a special
>> styler for breakpoints.
>> 
>> I see the general styler more as a debug tool (it is off by default).
>>  
>>  Marcus
>>> On 14 Dec 2016, at 05:10, Yuriy Tymchuk  wrote:
>>> 
>>> By the way, we need to add a rubric highlighting to the classes somehow :).
>>> 
>>> Uko
>>> 
>>> 
>>> 
 On 12 Dec 2016, at 13:36, Marcus Denker  wrote:
 
 Hello,
 
 Not yet. It should be easy to add if we find a good API for it…
 
 I will work on it this week (I have blocked some time for RF related 
 hacking).
 
 e.g I think we have to extend the syntax for reifications to use classes.
 
 something like:
 
 arguments: {RFTempReification named: #trachelCanvas};
 
 The current symbols then would be the same as using
 
 RFReification named: #object
 
 But subclasses can be used directly and parametrized.
 
Marcus
 
> On 5 Dec 2016, at 20:42, Peter Uhnak  wrote:
> 
> Hi,
> 
> what is the best way to access variables from within a metalink?
> 
> for example I have a message send `surface clear` and I want to change it 
> to `surface clear: trachelCanvas color`.
> 
> I can use #instVarNamed:
> 
> ```
> MetaLink new
>   metaObject: [ :object |
>   (object instVarNamed: #surface) clear: (object instVarNamed: 
> #trachelCanvas) color.
>   ];
>   selector: #value:;
>   arguments: #(object);
>   control: #instead.
> ```
> 
> but the above isn't exactly nice, plus it wouldn't work with temporary 
> variables.
> 
> Thanks,
> Peter
> 
 
 
>>> 
>>> 
>> 
>> 
> 
> 

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

[Marcus Denker]

Hi,

I think I found a simple solution: the ability to reference any variable.
https://pharo.fogbugz.com/f/cases/19467/Metalinks-support-accessing-variables-for-arguments

This test shows how to use it for a temp:

testAccessTemp
| varNode instance |
varNode := (ReflectivityExamples>>#exampleAssignment) ast body 
statements second.
link := MetaLink new 
metaObject: self; 
selector: #tagExec:;
arguments: {RBVariableNode named: #temp}.
varNode link: link.
self assert: varNode hasMetalink.
self assert: (tag isNil).
instance := ReflectivityExamples new .
self assert: (instance exampleAssignment = 3).
self assert: (tag = 3).

I have not yet tested it for any other example, but it should work for your 
case, too, which would look 
like this:

MetaLink new
metaObject: [ :surface :trachelCanvas |
surface clear: trachelCanvas color.
];
selector: #value:value:;
arguments:  {RBVariableNode named: #surface . RBVariableNode named: 
#trachelCanvas }.
control: #instead.



> On 12 Dec 2016, at 09:36, Marcus Denker  wrote:
> 
> Hello,
> 
> Not yet. It should be easy to add if we find a good API for it…
> 
> I will work on it this week (I have blocked some time for RF related hacking).
> 
> e.g I think we have to extend the syntax for reifications to use classes.
> 
> something like:
> 
> arguments: {RFTempReification named: #trachelCanvas};
> 
> The current symbols then would be the same as using
> 
> RFReification named: #object
> 
> But subclasses can be used directly and parametrized.
> 
>   Marcus
> 
>> On 5 Dec 2016, at 20:42, Peter Uhnak  wrote:
>> 
>> Hi,
>> 
>> what is the best way to access variables from within a metalink?
>> 
>> for example I have a message send `surface clear` and I want to change it to 
>> `surface clear: trachelCanvas color`.
>> 
>> I can use #instVarNamed:
>> 
>> ```
>> MetaLink new
>>  metaObject: [ :object |
>>  (object instVarNamed: #surface) clear: (object instVarNamed: 
>> #trachelCanvas) color.
>>  ];
>>  selector: #value:;
>>  arguments: #(object);
>>  control: #instead.
>> ```
>> 
>> but the above isn't exactly nice, plus it wouldn't work with temporary 
>> variables.
>> 
>> Thanks,
>> Peter
>> 
> 

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

[Marcus Denker]

Hi,

I think I found a simple solution: the ability to reference any variable.
https://pharo.fogbugz.com/f/cases/19467/Metalinks-support-accessing-variables-for-arguments

This test shows how to use it for a temp:

testAccessTemp
| varNode instance |
varNode := (ReflectivityExamples>>#exampleAssignment) ast body 
statements second.
link := MetaLink new 
metaObject: self; 
selector: #tagExec:;
arguments: {RBVariableNode named: #temp}.
varNode link: link.
self assert: varNode hasMetalink.
self assert: (tag isNil).
instance := ReflectivityExamples new .
self assert: (instance exampleAssignment = 3).
self assert: (tag = 3).

I have not yet tested it for any other example, but it should work for your 
case, too, which would look 
like this:

MetaLink new
metaObject: [ :surface :trachelCanvas |
surface clear: trachelCanvas color.
];
selector: #value:value:;
arguments:  {RBVariableNode named: #surface . RBVariableNode named: 
#trachelCanvas }.
control: #instead.



> On 12 Dec 2016, at 09:36, Marcus Denker  wrote:
> 
> Hello,
> 
> Not yet. It should be easy to add if we find a good API for it…
> 
> I will work on it this week (I have blocked some time for RF related hacking).
> 
> e.g I think we have to extend the syntax for reifications to use classes.
> 
> something like:
> 
> arguments: {RFTempReification named: #trachelCanvas};
> 
> The current symbols then would be the same as using
> 
> RFReification named: #object
> 
> But subclasses can be used directly and parametrized.
> 
>   Marcus
> 
>> On 5 Dec 2016, at 20:42, Peter Uhnak  wrote:
>> 
>> Hi,
>> 
>> what is the best way to access variables from within a metalink?
>> 
>> for example I have a message send `surface clear` and I want to change it to 
>> `surface clear: trachelCanvas color`.
>> 
>> I can use #instVarNamed:
>> 
>> ```
>> MetaLink new
>>  metaObject: [ :object |
>>  (object instVarNamed: #surface) clear: (object instVarNamed: 
>> #trachelCanvas) color.
>>  ];
>>  selector: #value:;
>>  arguments: #(object);
>>  control: #instead.
>> ```
>> 
>> but the above isn't exactly nice, plus it wouldn't work with temporary 
>> variables.
>> 
>> Thanks,
>> Peter
>> 
> 

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

[Offray Vladimir Luna Cárdenas]

This is a good example of the "empowering map" I talk about about 
"Pharo/Smalltalk places for you". What we can look forward in 2017 is 
different for different people, so going beyond the "most exiting 
developments", hype and shiny new things is also a way to show how 
Pharo/Smalltalk are different. We can provide shine and hype, but also 
we're building stuff for different interests and people and that is even 
more worthy to look for the upcoming times (2017 and beyond).


Cheers,

Offray


On 14/12/16 04:15, Dimitris Chloupis wrote:


On Tue, Dec 13, 2016 at 6:15 PM horrido > wrote:


Fellow Pharoers: What is the most exciting development in 2017 to look
forward to? I'm asking for things to put into the end-of-year post
in my
"Make Smalltalk Great Again!" campaign. Thanks.


I would not call it "most exciting development" for anyone but is 
definitely for me


Generally the plans for my project Ephestos for 2017 are

1) To create an Unreal API for Pharo
2) To create a Blender API for Pharo
3) To create a Supercollider API for Pharo

Unreal is the most powerful game/graphics engine.
Blender is the most powerful 3d editor.
Supercollider is the most powerful live coding music and audio 
synthesis platform.


I have developed the foundation for all three , the only thing 
remaining know is to wrap their APIs for Pharo.


So by end of 2017 Pharo will have received a massive boost to its 2d 
and 3d graphics capabilities and

music and audio synthesis capabilities.

Supercollider part is not a high priority goal as the other two, but I 
think I can squeeze it through.


Low priority goals and less exciting for me are

1) improvements to Nireas expanding its customisability, recreating 
the GUI , improving the blue theme and offer multiple other themes too
2) a tool that unifies workspace, system browser and inspector under 
one roof. I have not tested yet grafoscopio in detail, so it may form 
the basis for this tool

3)  further contributions to Pharo By Example and possibly other books

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

[Dimitris Chloupis]

On Wed, Dec 14, 2016 at 5:35 PM Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> This is a good example of the "empowering map" I talk about about
> "Pharo/Smalltalk places for you". What we can look forward in 2017 is
> different for different people, so going beyond the "most exiting
> developments", hype and shiny new things is also a way to show how
> Pharo/Smalltalk are different. We can provide shine and hype, but also
> we're building stuff for different interests and people and that is even
> more worthy to look for the upcoming times (2017 and beyond).
>
> Cheers,
>
> Offray
>

I think there is big difference between doing something exciting versus
doing something useful. Excitement dies out but usefulness does not. I
don't do it to make Pharo look cool, I do it because I need it. I also do
not like to do something and then abandon it like it happens for 99% of the
open source software.

Also maintenance becomes a big issue if the scope is wide. Of course you
can also combine excitement with usefulness and still keep the scope
reasonably achievable.

A thing I love about Pharo is because its so limited third party library
wise it forces me to go do that stuff myself and this definitely builds
confidence in one's coding skills. I really like this DYI approach and I am
definitely moving to the opposite direction of "do not reinvent the wheel".
This would have been unthinkable in communities of very popular languages.
I really like that Pharo forces me to be much less lazy as a coder.

Its also impressive to see the things that other people do by themselves
too and be inspired by it.

The real problem is that this work is not really visible, I think Pharo
needs something like a magazine and people should be encouraged to share
their work even if it is in early stage because you never know who will
find it useful. I feel the things we see in the mailing list is only the
tip of the iceberg of what people work on and is pity all this code to be
lost in obscurity.

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

[Ben Coman]

On Thu, Dec 15, 2016 at 12:38 AM, Dimitris Chloupis 
wrote:

>
> On Wed, Dec 14, 2016 at 5:35 PM Offray Vladimir Luna Cárdenas <
> offray.l...@mutabit.com> wrote:
>
>> This is a good example of the "empowering map" I talk about about
>> "Pharo/Smalltalk places for you". What we can look forward in 2017 is
>> different for different people, so going beyond the "most exiting
>> developments", hype and shiny new things is also a way to show how
>> Pharo/Smalltalk are different. We can provide shine and hype, but also
>> we're building stuff for different interests and people and that is even
>> more worthy to look for the upcoming times (2017 and beyond).
>>
>> Cheers,
>>
>> Offray
>>
>
> I think there is big difference between doing something exciting versus
> doing something useful. Excitement dies out but usefulness does not. I
> don't do it to make Pharo look cool, I do it because I need it. I also do
> not like to do something and then abandon it like it happens for 99% of the
> open source software.
>
> Also maintenance becomes a big issue if the scope is wide. Of course you
> can also combine excitement with usefulness and still keep the scope
> reasonably achievable.
>
> A thing I love about Pharo is because its so limited third party library
> wise it forces me to go do that stuff myself and this definitely builds
> confidence in one's coding skills. I really like this DYI approach and I am
> definitely moving to the opposite direction of "do not reinvent the wheel".
> This would have been unthinkable in communities of very popular languages.
> I really like that Pharo forces me to be much less lazy as a coder.
>

Because reinventing the wheel is a good way to learn about wheels...
cheers -ben


>
> Its also impressive to see the things that other people do by themselves
> too and be inspired by it.
>
> The real problem is that this work is not really visible, I think Pharo
> needs something like a magazine and people should be encouraged to share
> their work even if it is in early stage because you never know who will
> find it useful. I feel the things we see in the mailing list is only the
> tip of the iceberg of what people work on and is pity all this code to be
> lost in obscurity.
>

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

[Volkert]

Thanks Joachim, for the answer. I had the same thoughts about the 
architecture. And yes of course, there
is no easy and simple answer ... such an answer is always wrong ... So 
it is more important to see, were for which parts of distributed 
architectures Pharo is currently successful used. Scalability and 
Performance will always an issue. I like Pharo really, but i have not to 
goal ending up in a complex deployment of Pharo Nodes, because a Pharo 
with Seaside can only handle - say 20 user - ...


i will now read the BetaNine case, Joe mentioned ;-)

On 13.12.2016 20:29, jtuc...@objektfabrik.de wrote:

Volkert,

I surely cannot help you with concrete answers. We are not even using 
Pharo for our Seaside App.


All I've learned is that all of these questions are extremely hard to 
answer. Will Pharo or any other Server side technology scale? Forget 
it, nobody will be able to tell you the truth.


What I've learnt so far is that this whole thing is mostly a question 
of distributing services between servers (images and external 
processes). Make things small and devidable. Load the number crunching 
off of your web facing image and build clever UIs that give good 
feedback about the progress of lengthy operations.


If I tell you that my current estimate is that a Smalltalk image with 
Seaside will not be able to handle more than 20 concurrent users, in 
many cases even less. What does that actually tell you? YMMV based on 
the work that is done in that image, and there are so many influencing 
factors. If of these 20 users only 1 currently asks for heavy 
computation, this can already mean the server is slow for the other 19.


Our Application is very different from what you describe: Accounting 
is mostly CRUD operations, which means there are not many things you 
can delegate to external programs or even servers. Your scenario 
sounds very different. It sounds like you can do the data aggregation 
and refinement part in a separate (maybe REST based and stateless) 
server and mostly render nice "wait, we're working for you" dialogs 
and present nice results once they're done. This scales wonderfully 
and the front-end web server mostly does nothing other than send out 
self-reloading please-wait pages. Such a server (image) can probably 
even handle 50 or more concurrent users. Thus you end up with several 
layers on which you can scale easily and mostly independently. If your 
aggreations are slow, add a few images that do the aggregations.


So if your question is whether you can handle 500 concurrent users in 
Smalltalk or Pharo with Seaside, the answer is definitely YES. If you 
want to know how many Images are needed, how many servers you'd have 
to order, you'll probably not get any useful answers. My feeling is 
that you can't know exactly because every app is so different. There 
probably are just not enough projects out there to collect relevant 
data...


Joachim



Am 13.12.16 um 20:06 schrieb Volkert:



On 12.12.2016 19:52, Norbert Hartl wrote:

Am 12.12.2016 um 19:16 schrieb Volkert :

After reading reading "Enterprise Pharo a Web perspective", i am 
curious to learn more about current real world pharo web 
application set ups. any case studies or blue prints around? i am 
interested in application domain, system architecture, 
infrastructure (HW/OS/DB),  performance goals (concurrent users, 
transactions, ...), system sizing, scalability strategies, 


everything which could important to convince "me" to select pharo 
as a platform for a saas solution …


What you really want to know? All the things you mentioned above are 
not pharo related at all! Can you at least roughly sketch in which 
area you would consider to use pharo?


Norbert


I like to know more about current real world pharo web application 
set up ... not more, not less.


Think of a environmental information management system
5 User / 500 Concurrent
Data Aggregation
Data Refinement / Processing
Data Visualization
15-20 Dataprovider
Web UI

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

[Vitor Medina Cruz]

>
> If I tell you that my current estimate is that a Smalltalk image with
> Seaside will not be able to handle more than 20 concurrent users, in many
> cases even less.


Seriously? That is kinda a low number, I would expect more for each image.
Certainly it depends much on many things, but it is certainly very low for
a rough estimate, why you say that?

On Tue, Dec 13, 2016 at 5:29 PM, jtuc...@objektfabrik.de <
jtuc...@objektfabrik.de> wrote:

> Volkert,
>
> I surely cannot help you with concrete answers. We are not even using
> Pharo for our Seaside App.
>
> All I've learned is that all of these questions are extremely hard to
> answer. Will Pharo or any other Server side technology scale? Forget it,
> nobody will be able to tell you the truth.
>
> What I've learnt so far is that this whole thing is mostly a question of
> distributing services between servers (images and external processes). Make
> things small and devidable. Load the number crunching off of your web
> facing image and build clever UIs that give good feedback about the
> progress of lengthy operations.
>
> If I tell you that my current estimate is that a Smalltalk image with
> Seaside will not be able to handle more than 20 concurrent users, in many
> cases even less. What does that actually tell you? YMMV based on the work
> that is done in that image, and there are so many influencing factors. If
> of these 20 users only 1 currently asks for heavy computation, this can
> already mean the server is slow for the other 19.
>
> Our Application is very different from what you describe: Accounting is
> mostly CRUD operations, which means there are not many things you can
> delegate to external programs or even servers. Your scenario sounds very
> different. It sounds like you can do the data aggregation and refinement
> part in a separate (maybe REST based and stateless) server and mostly
> render nice "wait, we're working for you" dialogs and present nice results
> once they're done. This scales wonderfully and the front-end web server
> mostly does nothing other than send out self-reloading please-wait pages.
> Such a server (image) can probably even handle 50 or more concurrent users.
> Thus you end up with several layers on which you can scale easily and
> mostly independently. If your aggreations are slow, add a few images that
> do the aggregations.
>
> So if your question is whether you can handle 500 concurrent users in
> Smalltalk or Pharo with Seaside, the answer is definitely YES. If you want
> to know how many Images are needed, how many servers you'd have to order,
> you'll probably not get any useful answers. My feeling is that you can't
> know exactly because every app is so different. There probably are just not
> enough projects out there to collect relevant data...
>
> Joachim
>
>
>
> Am 13.12.16 um 20:06 schrieb Volkert:
>
>
>>
>> On 12.12.2016 19:52, Norbert Hartl wrote:
>>
>>> Am 12.12.2016 um 19:16 schrieb Volkert :

 After reading reading "Enterprise Pharo a Web perspective", i am
 curious to learn more about current real world pharo web application set
 ups. any case studies or blue prints around? i am interested in application
 domain, system architecture, infrastructure (HW/OS/DB),  performance goals
 (concurrent users, transactions, ...), system sizing, scalability
 strategies, 

 everything which could important to convince "me" to select pharo as a
 platform for a saas solution …

 What you really want to know? All the things you mentioned above are
>>> not pharo related at all! Can you at least roughly sketch in which area you
>>> would consider to use pharo?
>>>
>>> Norbert
>>>
>>>
>>> I like to know more about current real world pharo web application set
>> up ... not more, not less.
>>
>> Think of a environmental information management system
>> 5 User / 500 Concurrent
>> Data Aggregation
>> Data Refinement / Processing
>> Data Visualization
>> 15-20 Dataprovider
>> Web UI
>>
>>
>>
>>
>>
>>
>
>

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

[Esteban A. Maringolo]

2016-12-14 15:11 GMT-03:00 Volkert :
> Pharo is currently successful used. Scalability and Performance will always
> an issue. I like Pharo really, but i have not to goal ending up in a complex
> deployment of Pharo Nodes, because a Pharo with Seaside can only handle -
> say 20 user - ...

The 20 user depends more on the I/O than anything else.
However you can scale Seaside horizontally using a front reverse proxy
like nginx using session affinity.

Memory is cheap, and the only limit now is CPU, the current Pharo
image has an idle CPU consumption ~5%, so you can't have many
concurrent images running in the same machine.


Regards,


Esteban A. Maringolo

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

[Norbert Hartl]

> Am 14.12.2016 um 18:00 schrieb Ben Coman :
> 
> 
> 
>> On Thu, Dec 15, 2016 at 12:38 AM, Dimitris Chloupis  
>> wrote:
>> 
>>> On Wed, Dec 14, 2016 at 5:35 PM Offray Vladimir Luna Cárdenas 
>>>  wrote:
>>> This is a good example of the "empowering map" I talk about about 
>>> "Pharo/Smalltalk places for you". What we can look forward in 2017 is 
>>> different for different people, so going beyond the "most exiting 
>>> developments", hype and shiny new things is also a way to show how 
>>> Pharo/Smalltalk are different. We can provide shine and hype, but also 
>>> we're building stuff for different interests and people and that is even 
>>> more worthy to look for the upcoming times (2017 and beyond).
>>> 
>>> Cheers,
>>> 
>>> Offray
>>> 
>> 
>> I think there is big difference between doing something exciting versus 
>> doing something useful. Excitement dies out but usefulness does not. I don't 
>> do it to make Pharo look cool, I do it because I need it. I also do not like 
>> to do something and then abandon it like it happens for 99% of the open 
>> source software. 
>> 
>> Also maintenance becomes a big issue if the scope is wide. Of course you can 
>> also combine excitement with usefulness and still keep the scope reasonably 
>> achievable. 
>> 
>> A thing I love about Pharo is because its so limited third party library 
>> wise it forces me to go do that stuff myself and this definitely builds 
>> confidence in one's coding skills. I really like this DYI approach and I am 
>> definitely moving to the opposite direction of "do not reinvent the wheel". 
>> This would have been unthinkable in communities of very popular languages. I 
>> really like that Pharo forces me to be much less lazy as a coder.
> 
> Because reinventing the wheel is a good way to learn about wheels...

I like that argument. I copy that 😀

Norbert
> cheers -ben
>  
>> 
>> Its also impressive to see the things that other people do by themselves too 
>> and be inspired by it. 
>> 
>> The real problem is that this work is not really visible, I think Pharo 
>> needs something like a magazine and people should be encouraged to share 
>> their work even if it is in early stage because you never know who will find 
>> it useful. I feel the things we see in the mailing list is only the tip of 
>> the iceberg of what people work on and is pity all this code to be lost in 
>> obscurity. 
> 

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

[Dimitris Chloupis]

That 5% idle CPU consumption is not the only problem, creating a new
process will add additional overheads anyway so it does not make sense to
have more pharo processes than CPU cores. Concurrency can be handled by
pharo forks. I am not web dev even by a remote imagination but my recent
experience with UFFI is that Pharo can go to insane speeds when it relies
on C libraries , especially performance orientated ones. Of course learning
C and playing with C is a pain by itself but necessary evil if top
performance is the goal.

On Wed, Dec 14, 2016 at 8:28 PM Esteban A. Maringolo 
wrote:

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

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

[Dimitris Chloupis]

>
>
> Because reinventing the wheel is a good way to learn about wheels...
> cheers -ben
>
>

Absolutely , actually I find it funny when I hear or read "do not reinvent
the wheel" . How many different wheels do we not already have out there,
just a huge number and each serves a specific purpose very well.  Out of
the so many objects one could pick , wheel is the worst option because of
the versatility and efficient of its variations in its designs.

As you said reinvention allow you to basically reverse engineer and really
learn your subject matter but that is half of the story, the other half is
that you apply this knowledge to make a customised version which will be an
actual improvement for the specific role you want it.

This is why in most case scenarios a customised solution will work much
better than a generic solution.

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

[Esteban A. Maringolo]

2016-12-14 15:41 GMT-03:00 Dimitris Chloupis :
> That 5% idle CPU consumption is not the only problem, creating a new process
> will add additional overheads anyway so it does not make sense to have more
> pharo processes than CPU cores.

Not exactly, thinking it that way would disable you from running Pharo
in a machine with other daemon services running (if daemons > cores).
But those other daemons at idle consume less than 1% of the total CPU,
whilst 10 idle Pharo images will consume 50%.

With peak demand a single image can take 100% of the CPU core.

> Concurrency can be handled by pharo forks.

A Pharo forked process is still running under the vm single threaded
process... so it's more a matter of in-image blocking rather than
external access.

> I am not web dev even by a remote imagination but my recent experience with
> UFFI is that Pharo can go to insane speeds when it relies on C libraries ,
> especially performance orientated ones. Of course learning C and playing
> with C is a pain by itself but necessary evil if top performance is the
> goal.

This is true. And non-blocking callbacks really alleviate the weight a
single threaded vm can support.

However any CPU intensive request will block the process, and that
will happen with looping server like Pharo or an evented VM like
NodeJS.

Unless you're targeting to an initial really high concurrent users
count, then you can scale up gradually.

Esteban A. Maringolo

[Pharo-users] GitFileTree in Pharo 5

[sergio ruiz]

Hey, all.

I am trying to install GitFileTree from the Catalog Browser. I get a warning 
that it’s not tested with Pharo 5. I go ahead anyway, and it just hangs.

Has anyone else installed it on macOS?

Is there a different package I should be using?

Thanks!


peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.Village-Buzz.com
http://www.ThoseOptimizeGuys.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc
Description: Message signed with OpenPGP using AMPGpg

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

[Dimitris Chloupis]

"A Pharo forked process is still running under the vm single threaded
process... so it's more a matter of in-image blocking rather than
external access."

There is parallelism which means code that execute at the same time
instruction by instruction
There is concurency which means code that executes a bit of it from
different parts giving the illusion that codes run at the same time

OS threads do parallelism
VM threads , aka green threads, do concurrency

VM technically speaking uses several OS threads but the byte code is indeed
executed on the main thread only , thus VM alllows only green threads for
pharo code.

I am not saying you do not know this stuff, I am just mention it here so
everyone is on the same page.

You cannot have more parallelism than cores, actually that may not be true
because I think each core allows for two parallel threads because of
hyperthreading but more or less thats the idea.

Just for the record there are cases when multiple OS threads running on
multiple cores can be actually slower than one thread running on one core.
This the nightmare that is called parallelism and why coders generally
avoid it.  The usually reason why multiple OS threads may be slower it has
to do with CPU cache and how it exchanges data between threads and CPU
cores.

I had the pleasure of getting a taste of this nightmare when I was learning
OpenMP which is the most popular library for parallel execution for C/C++.
Of course there are also the usual problems with synchronisation etc.

Technically speaking you can do OS threads from Pharo with my CPP library.
Thats possible because CPP works by having two isolated process (actually
you can have an infinite amount of processes if your hardware can handle
them ) , in this case one C++ executable and one for Pharo that share an
area of memory that both can directly access to. You could implement
callbacks to, you could do anything and you would not have to worry about
joining threads or providing compatibility with Pharo VM because you deal
with shared data and not code execution.  Because CPP uses shared memory
which in turn uses OS kernel native memory access and management functions,
you get top speed.

So you can have one process using OpenMP taking full advantage of the
hardware acceleration (triggering multiple OS threads) of your CPU cores
and one for Pharo that will drive the OpenMP process.

There is still the issue of data synchronisation, who locks the data and
who accesses it at what time, but those are usual issues for any kind of
thread orientated coding, you wont be doing anything diffirent.

"However any CPU intensive request will block the process, and that
will happen with looping server like Pharo or an evented VM like
NodeJS."

Again you can avoid that with my CPP library. You do not need to block ,
you could let the external process do its thing and just block it when you
decide to fetch data after it finishes or on specific intervals. There are
so many ways you can do this. You can also have like the VM one central OS
thread that is able to be blocked by Pharo and multiple secondary ones that
Pharo will have no control over either than the level of control that the
main thread provides.

In any case, most servers run Apache which should deal with many of those
issues, there are wrappers for many languages , Apaches is wrriten in C/C++
so its should be able to tap into this technology to avoid solving problems
that have been already solved. So its a matter of writing wrappers for
Pharo too.

On Wed, Dec 14, 2016 at 8:59 PM Esteban A. Maringolo 
wrote:

> 2016-12-14 15:41 GMT-03:00 Dimitris Chloupis :
> > That 5% idle CPU consumption is not the only problem, creating a new
> process
> > will add additional overheads anyway so it does not make sense to have
> more
> > pharo processes than CPU cores.
>
> Not exactly, thinking it that way would disable you from running Pharo
> in a machine with other daemon services running (if daemons > cores).
> But those other daemons at idle consume less than 1% of the total CPU,
> whilst 10 idle Pharo images will consume 50%.
>
> With peak demand a single image can take 100% of the CPU core.
>
> > Concurrency can be handled by pharo forks.
>
> A Pharo forked process is still running under the vm single threaded
> process... so it's more a matter of in-image blocking rather than
> external access.
>
> > I am not web dev even by a remote imagination but my recent experience
> with
> > UFFI is that Pharo can go to insane speeds when it relies on C libraries
> ,
> > especially performance orientated ones. Of course learning C and playing
> > with C is a pain by itself but necessary evil if top performance is the
> > goal.
>
> This is true. And non-blocking callbacks really alleviate the weight a
> single threaded vm can support.
>
> However any CPU intensive request will block the process, and that
> will happen with looping server like Pharo or an evented VM like
> NodeJS.
>
> Unless you're targeting to

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

[Ramon Leon]

On 12/14/2016 10:27 AM, Esteban A. Maringolo wrote:

Memory is cheap, and the only limit now is CPU, the current Pharo
image has an idle CPU consumption ~5%, so you can't have many
concurrent images running in the same machine.


Sure you can, a multi-core server isn't going to get maxed out by idle 
CPU consumption as each image will only do that on a single core; you 
can also reduce consumption on headless images by suspending the UI 
process which isn't needed getting you down to perhaps 2-3%.



whilst 10 idle Pharo images will consume 50%.


Only on a single CPU machine which isn't what you're going to have on a 
server. Running two images per core on a 12 core virtual server and 
you'll be sitting more like 5-6% idle which is totally fine. Spread that 
across 10 or 15 virtual servers and you can handle 1000 concurrent users 
just fine.


--
Ramon Leon

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

[Stephan Eggermont]

On 14/12/16 19:41, Dimitris Chloupis wrote:

That 5% idle CPU consumption is not the only problem, creating a new
process will add additional overheads anyway so it does not make sense
to have more pharo processes than CPU cores.


You can probably run a few thousand images on a single high-end x86 
server (2*22 Core Xeon, 1TB ram). I just started 21 images on my 
dual-core i5 MBP. top tells me my system is 75-80% idle, pharo processes 
taking 2-3%CPU and 1.6GB MEM (33MB-146MB)


Stephan

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

[Esteban A. Maringolo]

2016-12-14 16:31 GMT-03:00 Ramon Leon :
> On 12/14/2016 10:27 AM, Esteban A. Maringolo wrote:
>>
>> Memory is cheap, and the only limit now is CPU, the current Pharo
>> image has an idle CPU consumption ~5%, so you can't have many
>> concurrent images running in the same machine.
>
>
> Sure you can, a multi-core server isn't going to get maxed out by idle CPU
> consumption as each image will only do that on a single core; you can also
> reduce consumption on headless images by suspending the UI process which
> isn't needed getting you down to perhaps 2-3%.

Can you extend on suspending the UI process? I never did that.

>> whilst 10 idle Pharo images will consume 50%.

> Only on a single CPU machine which isn't what you're going to have on a
> server. Running two images per core on a 12 core virtual server and you'll
> be sitting more like 5-6% idle which is totally fine. Spread that across 10
> or 15 virtual servers and you can handle 1000 concurrent users just fine.

Won't the idle use add up?

In my case I served up to 20 concurrent users (out of ~100 total) with
only 5 images. Plus another two images for the REST API. In a dual
core server.

Regards.

Esteban A. Maringolo

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

[Ramon Leon]

On 12/14/2016 12:09 PM, Esteban A. Maringolo wrote:

Can you extend on suspending the UI process? I never did that.


I feed my images a start script on the command line

pharo-vm-nox \
-vm-sound-null -vm-display-null \
/var/pharo/app.image \
/var/pharo/startScript

startScript containing one line (among others) like so...

Project uiProcess suspend.

I'm on an older Pharo, but I presume the newer ones are the same or 
similar. No sense in wasting CPU on a UI in a headless image



Won't the idle use add up?


Sure eventually, but you don't run more than a 2 or so per core so 
that'll never be a problem.  You shouldn't be running 5 images on a 
single core, let alone more.



In my case I served up to 20 concurrent users (out of ~100 total) with
only 5 images. Plus another two images for the REST API. In a dual
core server.


That's barely a server, most laptops these days have more cores. Rent a 
virtual server with a dozen or more cores, then you can run a few images 
per core without the idle mattering at all and run 2 dozen images in 
total per 12 core server.


Scale by adding cores and ram allowing you to run more images per box; 
or scale by running more boxes, ultimately, you need to spread out the 
load across many many cores.


--
Ramon Leon

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

[Vitor Medina Cruz]

Pharo don't have non-blocking I/O?

On Wed, Dec 14, 2016 at 6:59 PM, Ramon Leon 
wrote:

> On 12/14/2016 12:09 PM, Esteban A. Maringolo wrote:
>
>> Can you extend on suspending the UI process? I never did that.
>>
>
> I feed my images a start script on the command line
>
> pharo-vm-nox \
> -vm-sound-null -vm-display-null \
> /var/pharo/app.image \
> /var/pharo/startScript
>
> startScript containing one line (among others) like so...
>
> Project uiProcess suspend.
>
> I'm on an older Pharo, but I presume the newer ones are the same or
> similar. No sense in wasting CPU on a UI in a headless image
>
> Won't the idle use add up?
>>
>
> Sure eventually, but you don't run more than a 2 or so per core so that'll
> never be a problem.  You shouldn't be running 5 images on a single core,
> let alone more.
>
> In my case I served up to 20 concurrent users (out of ~100 total) with
>> only 5 images. Plus another two images for the REST API. In a dual
>> core server.
>>
>
> That's barely a server, most laptops these days have more cores. Rent a
> virtual server with a dozen or more cores, then you can run a few images
> per core without the idle mattering at all and run 2 dozen images in total
> per 12 core server.
>
> Scale by adding cores and ram allowing you to run more images per box; or
> scale by running more boxes, ultimately, you need to spread out the load
> across many many cores.
>
> --
> Ramon Leon
>
>
>

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

[p...@highoctane.be]

I can try that: I've some 48-core 500+ GB RAM boxes around at the moment.

If someone can make me a test script, can run it.

Phil

On Wed, Dec 14, 2016 at 8:54 PM, Stephan Eggermont  wrote:

> On 14/12/16 19:41, Dimitris Chloupis wrote:
>
>> That 5% idle CPU consumption is not the only problem, creating a new
>> process will add additional overheads anyway so it does not make sense
>> to have more pharo processes than CPU cores.
>>
>
> You can probably run a few thousand images on a single high-end x86 server
> (2*22 Core Xeon, 1TB ram). I just started 21 images on my dual-core i5 MBP.
> top tells me my system is 75-80% idle, pharo processes taking 2-3%CPU and
> 1.6GB MEM (33MB-146MB)
>
> Stephan
>
>
>
>
>

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

[Sven Van Caekenberghe]

> On 14 Dec 2016, at 23:29, Vitor Medina Cruz  wrote:
> 
> Pharo don't have non-blocking I/O?

It certainly does at the networking level, but some native code interfaces 
might not act so nice.

> On Wed, Dec 14, 2016 at 6:59 PM, Ramon Leon  wrote:
> On 12/14/2016 12:09 PM, Esteban A. Maringolo wrote:
> Can you extend on suspending the UI process? I never did that.
> 
> I feed my images a start script on the command line
> 
> pharo-vm-nox \
> -vm-sound-null -vm-display-null \
> /var/pharo/app.image \
> /var/pharo/startScript
> 
> startScript containing one line (among others) like so...
> 
> Project uiProcess suspend.
> 
> I'm on an older Pharo, but I presume the newer ones are the same or similar. 
> No sense in wasting CPU on a UI in a headless image
> 
> Won't the idle use add up?
> 
> Sure eventually, but you don't run more than a 2 or so per core so that'll 
> never be a problem.  You shouldn't be running 5 images on a single core, let 
> alone more.
> 
> In my case I served up to 20 concurrent users (out of ~100 total) with
> only 5 images. Plus another two images for the REST API. In a dual
> core server.
> 
> That's barely a server, most laptops these days have more cores. Rent a 
> virtual server with a dozen or more cores, then you can run a few images per 
> core without the idle mattering at all and run 2 dozen images in total per 12 
> core server.
> 
> Scale by adding cores and ram allowing you to run more images per box; or 
> scale by running more boxes, ultimately, you need to spread out the load 
> across many many cores.
> 
> -- 
> Ramon Leon
> 
> 
> 

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

[horrido]

You've inspired me to consider a new subproject. It's tentatively called
"Smalltalk Showcase" (although I'll try to come up with a better name) and
it will present a series of stories about Pharo/Smalltalk developments that
demonstrate the incredible versatility and usefulness of Smalltalk. (It
doesn't have to be Pharo, but I'll be pleasantly surprised if there are cool
developments in Squeak, Cincom, Dolphin, GNU, etc.)

Here's an open call to Pharoers (and Smalltalkers) everywhere: Submit a
favourite project, including a URL to a website or repository that shows the
project in the best light, as well as an "abstract" that nicely summarizes
what the project is trying to accomplish. I'll select the ones that are most
interesting and do work-ups on them. If necessary, I'll query for more
details in an email reply. Send all submissions to: richard@outlook.com

Most appreciated.

By the way, the first story will be on Grafoscopio.



--
View this message in context: 
http://forum.world.st/What-can-we-look-forward-to-in-2017-tp4926791p4926986.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] wwwhisper

[Robert Withers]

I have no idea if that's true, I like to dream and I am just glad it is 
here. happy holidays.



On 12/14/2016 6:46 PM, Robert Withers wrote:
here's a good step I think it settled well. encoders are next. I 
haven't got any java left . Merry Christmas! Here's the profile. AS 
fast as bitblt are you serious?




 - 27380 tallies, 28129 msec.

**Tree**

Process: (40s) 95416: nil

13.6% {3815ms} MessageTally class>>spyOn:reportOtherProcesses:
  13.6% {3815ms} MessageTally>>spyEvery:on:
13.6% {3815ms} BlockClosure>>ensure:
  13.6% {3815ms} [] TestRunner>>runProfiled
13.6% {3815ms} TestRunner>>runAll
  13.6% {3814ms} TestRunner>>runSuite:
13.6% {3814ms} TestRunner>>basicRunSuite:do:
  13.6% {3814ms} BlockClosure>>ensure:
13.6% {3814ms} [] TestRunner>>basicRunSuite:do:
  13.6% {3814ms} 
OrderedCollection(Collection)>>do:displayingProgress:every:
13.6% {3814ms} 
ByteString(String)>>displayProgressFrom:to:during:
  13.6% {3814ms} 
ByteString(String)>>displayProgressAt:from:to:during:
13.6% {3814ms} ProgressInitiationException 
class>>display:at:from:to:during:
  13.6% {3814ms} 
ProgressInitiationException>>display:at:from:to:during:
13.6% {3814ms} 
ProgressInitiationException(Exception)>>signal
  13.6% {3814ms} 
MethodContext(ContextPart)>>handleSignal:
13.6% {3814ms} 
UndefinedObject>>handleSignal:
  13.6% {3814ms} 
ProgressInitiationException>>defaultAction
13.6% {3814ms} 
ProgressInitiationException(Exception)>>resume
  13.6% {3814ms} 
ProgressInitiationException>>defaultResumeValue
13.6% {3814ms} 
MorphicUIManager>>displayProgress:at:from:to:during:
  13.6% {3813ms} 
BlockClosure>>ensure:
13.6% {3813ms} [] 
MorphicUIManager>>displayProgress:at:from:to:during:
  13.6% {3811ms} 
BlockClosure>>on:do:
13.6% {3811ms} [[]] 
MorphicUIManager>>displayProgress:at:from:to:during:
  13.6% {3811ms} [] 
OrderedCollection(Collection)>>do:displayingProgress:every:
13.6% {3811ms} 
OrderedCollection>>do:
  13.6% {3811ms} 
[[]] OrderedCollection(Collection)>>do:displayingProgress:every:
13.2% {3719ms} 
[] TestRunner>>runSuite:
  13.2% 
{3719ms} TestRunner>>runTest:
13.2% 
{3718ms} MoreDataTestCase(TestCase)>>run:

13.2% {3718ms} TestResult>>runCase:
13.2% {3718ms} BlockClosure>>on:do:
13.2% {3718ms} [] TestResult>>runCase:
13.2% {3718ms} BlockClosure>>on:do:
13.2% {3718ms} [[]] TestResult>>runCase:
13.2% {3718ms} MoreDataTestCase(TestCase)>>runCase
13.2% {3718ms} BlockClosure>>ensure:
13.2% {3718ms} [] MoreDataTestCase(TestCase)>>runCase
12.7% {3583ms} MoreDataTestCase(TestCase)>>timeout:after:
12.7% {3582ms} BlockClosure>>ensure:
12.7% {3582ms} [] MoreDataTestCase(TestCase)>>timeout:after:
12.7% {3582ms} BlockClosure>>on:do:
12.7% {3582ms} [[]] MoreDataTestCase(TestCase)>>runCase
12.7% {3580ms} MoreDataTestCase(TestCase)>>performTest
1.3% {366ms} MoreDataTestCase>>testDoubleDataDBL_AESede
1.3% {366ms} ConnectTestCase>>testConnect
1.3% {365ms} MoreDataTestCase>>testDoubleData
1.3% {364ms} DataTestCase>>testData
1.3% {358ms} SqueakJavaTestCase>>testData
1.3% {356ms} MoreDataTestCase>>testDoubleDataNoisy
1.3% {354ms} MoreDataTestCase>>testDoubleDataAES
1.3% {354ms} MoreDataTestCase>>testDoubleDataDES
1.2% {350ms} MoreDataTestCase>>testEmptyData
1.2% {347ms} MoreDataTestCase>>testDoubleDataDESOverAESede

Process: other processes

67.0% {18857ms} [] ProcessorScheduler class>>startUp
  |67.0% {18857ms} ProcessorScheduler class>>idleProcess
18.6% {5241ms} [] TransportEndpoint(ProtocolEndpoint)>>run
  18.6% {5241ms} TransportEndpoint(ProtocolEndpoint)>>serverLoop
18.5% {5206ms} BlockClosure>>on:do:
  18.5% {5206ms} [] TransportEndpoint(ProtocolEndpoint)>>serverLoop
18.2% {5120ms} FrameChunker>>upcallFrame:
  18.2% {5119ms} FrameChunker>>drainBuffer
17.8% {5002ms} BlockClosure>>on:do:
  17.8% {5002ms} [] FrameChunker>>drainBuffer
17.8% {5002ms} OperationProtocol>>upcallFrame:
  10.2% {2867ms} 
OperationProtocol(StatefulProtocol)>>transitionEven

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

[Offray Vladimir Luna Cárdenas]

On 14/12/16 11:38, Dimitris Chloupis wrote:


On Wed, Dec 14, 2016 at 5:35 PM Offray Vladimir Luna Cárdenas 
mailto:offray.l...@mutabit.com>> wrote:


This is a good example of the "empowering map" I talk about about
"Pharo/Smalltalk places for you". What we can look forward in 2017
is different for different people, so going beyond the "most
exiting developments", hype and shiny new things is also a way to
show how Pharo/Smalltalk are different. We can provide shine and
hype, but also we're building stuff for different interests and
people and that is even more worthy to look for the upcoming times
(2017 and beyond).

Cheers,

Offray


I think there is big difference between doing something exciting 
versus doing something useful. Excitement dies out but usefulness does 
not. I don't do it to make Pharo look cool, I do it because I need it. 
I also do not like to do something and then abandon it like it happens 
for 99% of the open source software.




Yes. That's why I'm inviting Richard to go beyond exiting to 
interesting. He has accepted my invitation.


Cheers,

Offray