Re: [Pharo-users] Rocket Chat - An open source alternative to Slack

[Offray Vladimir Luna Cárdenas]

I think both, rocket.chat and mattermost.org are interesting. Owning 
vital infrastructure, like the one of communications, is key for proper 
community empowerment, but the problem is that this is a small community 
without many spare resources and I don't know if any has the 
time/infrastructure to volunteer hosting them and making the test. What 
is a fact is that Slack has changed the way community interacts, mostly 
for good so exploring and owning alternatives is a valuable pursuit.


Cheers,

Offray

On 16/12/15 07:05, Martin Bähr wrote:

Excerpts from Dimitris Chloupis's message of 2015-12-16 11:04:04 +0100:

So since Slack has been so successful for our community , far more that IRC
has been in terms of participation and useful discussions (at least the 2
years I have been around)

it made me wonder if I could find an open source alternative to Slack that
is at least as good as it if not better without a very different workflow
(so we have to learn everything from zero) all the big pros and something
that could easily interface with Pharo.

Ladies and gentlemen meet Rocket Chat

https://rocket.chat/

The good news about Rocket chat is that it seems to have all the pros of
Slack like close integration with tweeter, github etc etc . It has clients
for all OS and mobile devices.

what it doesn't have is support for irc clients:
https://github.com/RocketChat/Rocket.Chat/issues/1259

for me, that's a deal breaker. because as nice as these services are, i don't
have the patience to run a dozen clients for all different communication
services.

it is bad enough that these services are not federated and i have to connect to
them to communicate, but at least support for common, already existing clients,
should be there.

it does seem to have an irc bridge at least. a bit ugly, but workable.

but there is also mattermost: http://mattermost.org/ (and it has irc client 
support)
seems at least as mature as rocket.chat.

greetings, martin.

Re: [Pharo-users] New web tutorial

[stepharo]

We will

Le 15/12/15 09:46, Torsten Bergmann a écrit :

In the Bootstrap for Seaside part you should mention two pages:

Code Repo + Documentation:http://smalltalkhub.com/#!/~TorstenBergmann/Bootstrap
Demo:http://pharo.pharocloud.com/bootstrap

Thanks
T.

Re: [Pharo-users] Rocket Chat - An open source alternative to Slack

[Dimitris Chloupis]

I completely agree with this is why I did not push it further I just
brought it to your attention.

In any case, I am fine with Slack and I rely mostly on this mailing list
anyway. I rather focus on coding for Pharo than worry about a chat system
;)

On Wed, Dec 16, 2015 at 6:51 PM Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> I think both, rocket.chat and mattermost.org are interesting. Owning
> vital infrastructure, like the one of communications, is key for proper
> community empowerment, but the problem is that this is a small community
> without many spare resources and I don't know if any has the
> time/infrastructure to volunteer hosting them and making the test. What
> is a fact is that Slack has changed the way community interacts, mostly
> for good so exploring and owning alternatives is a valuable pursuit.
>
> Cheers,
>
> Offray
>
> On 16/12/15 07:05, Martin Bähr wrote:
> > Excerpts from Dimitris Chloupis's message of 2015-12-16 11:04:04 +0100:
> >> So since Slack has been so successful for our community , far more that
> IRC
> >> has been in terms of participation and useful discussions (at least the
> 2
> >> years I have been around)
> >>
> >> it made me wonder if I could find an open source alternative to Slack
> that
> >> is at least as good as it if not better without a very different
> workflow
> >> (so we have to learn everything from zero) all the big pros and
> something
> >> that could easily interface with Pharo.
> >>
> >> Ladies and gentlemen meet Rocket Chat
> >>
> >> https://rocket.chat/
> >>
> >> The good news about Rocket chat is that it seems to have all the pros of
> >> Slack like close integration with tweeter, github etc etc . It has
> clients
> >> for all OS and mobile devices.
> > what it doesn't have is support for irc clients:
> > https://github.com/RocketChat/Rocket.Chat/issues/1259
> >
> > for me, that's a deal breaker. because as nice as these services are, i
> don't
> > have the patience to run a dozen clients for all different communication
> > services.
> >
> > it is bad enough that these services are not federated and i have to
> connect to
> > them to communicate, but at least support for common, already existing
> clients,
> > should be there.
> >
> > it does seem to have an irc bridge at least. a bit ugly, but workable.
> >
> > but there is also mattermost: http://mattermost.org/ (and it has irc
> client support)
> > seems at least as mature as rocket.chat.
> >
> > greetings, martin.
> >
>
>
>

Re: [Pharo-users] #storeOn: question

[stepharo]

hi doru

what is isPharoClass?
Why do you need it?

Stef

Le 9/12/15 21:49, Tudor Girba a écrit :

I created an issue with a slice:
https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo

Cheers,
Doru



On Dec 9, 2015, at 3:33 PM, Tudor Girba  wrote:

Hi again,


On Dec 9, 2015, at 3:30 PM, Tudor Girba  wrote:

Hi,

Thanks for the question. I am at a conference, and I just took this problem to 
explain someone what code querying can mean :).

Here is the result:
http://ws.stfx.eu/CCSNJVWX3JKS


I just realized that isPharoClass only exists in my image for the moment :)

Doru





I think this is how we should document our communication because now we have 
the tools.

Cheers,
Doru



On Dec 3, 2015, at 7:00 AM, Werner Kassens  wrote:

Hi Stephane,
there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: 
minus around 10 tests, also things like the PharoChangesCondenser use it. then 
there are 26 senders of #storeString (essentially the same functionality 
implemented via #storeOn:, but returns a string) eg used by the 
StartupPreferencesLoader. and there are several senders of #store: that are not 
implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated 
to me and is obviously way above my head.
werner

On 11/30/2015 09:42 PM, stepharo wrote:

It would be good to check who is using that and evaluate if we can
remove it.

--
www.tudorgirba.com

"Every thing should have the right to be different."




--
www.tudorgirba.com

"One cannot do more than one can do."

--
www.tudorgirba.com

"Yesterday is a fact.
  Tomorrow is a possibility.
  Today is a challenge."

Re: [Pharo-users] #storeOn: question

[Tudor Girba]

Hi,

I wanted to have an easy way to distinguish between a class that ships with 
Pharo and another class that is built on top. Unfortunately, I did not find a 
good enough heuristic (I used to rely on the repository of the package where 
the class is defined as being the Pharo one), so this was not added until we 
find a different solution.

This is useful in several situations. The one I am in very often is to use 
extra tools that are in Moose to analyze Pharo. This was the case below where 
we needed to get the list of the storeOn: senders more accurately.

Cheers,
Doru


> On Dec 16, 2015, at 10:41 PM, stepharo  wrote:
> 
> hi doru
> 
> what is isPharoClass?
> Why do you need it?
> 
> Stef
> 
> Le 9/12/15 21:49, Tudor Girba a écrit :
>> I created an issue with a slice:
>> https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Dec 9, 2015, at 3:33 PM, Tudor Girba  wrote:
>>> 
>>> Hi again,
>>> 
 On Dec 9, 2015, at 3:30 PM, Tudor Girba  wrote:
 
 Hi,
 
 Thanks for the question. I am at a conference, and I just took this 
 problem to explain someone what code querying can mean :).
 
 Here is the result:
 http://ws.stfx.eu/CCSNJVWX3JKS
 
>>> I just realized that isPharoClass only exists in my image for the moment :)
>>> 
>>> Doru
>>> 
>>> 
 
 
 I think this is how we should document our communication because now we 
 have the tools.
 
 Cheers,
 Doru
 
 
> On Dec 3, 2015, at 7:00 AM, Werner Kassens  wrote:
> 
> Hi Stephane,
> there are 89 senders of #storeOn: minus around 30 implementations of 
> #storeOn: minus around 10 tests, also things like the 
> PharoChangesCondenser use it. then there are 26 senders of #storeString 
> (essentially the same functionality implemented via #storeOn:, but 
> returns a string) eg used by the StartupPreferencesLoader. and there are 
> several senders of #store: that are not implementations of #storeOn:. iow 
> deprecating #storeOn: looks a bit complicated to me and is obviously way 
> above my head.
> werner
> 
> On 11/30/2015 09:42 PM, stepharo wrote:
>> It would be good to check who is using that and evaluate if we can
>> remove it.
 --
 www.tudorgirba.com
 
 "Every thing should have the right to be different."
 
 
 
>>> --
>>> www.tudorgirba.com
>>> 
>>> "One cannot do more than one can do."
>> --
>> www.tudorgirba.com
>> 
>> "Yesterday is a fact.
>>  Tomorrow is a possibility.
>>  Today is a challenge."
>> 
>> 
>> 
>> 
>> 
> 
> 

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

"It's not what we do that matters most, it's how we do it."

Re: [Pharo-users] Rocket Chat - An open source alternative to Slack

[John Pfersich]

I set up a public #pharo channel. Join it!

Sent from my iPad

> On Dec 16, 2015, at 02:04, Dimitris Chloupis  wrote:
> 
> So since Slack has been so successful for our community , far more that IRC 
> has been in terms of participation and useful discussions (at least the 2 
> years I have been around) 
> 
> it made me wonder if I could find an open source alternative to Slack that is 
> at least as good as it if not better without a very different workflow (so we 
> have to learn everything from zero) all the big pros and something that could 
> easily interface with Pharo.
> 
> Ladies and gentlemen meet Rocket Chat
> 
> https://rocket.chat/
> 
> The good news about Rocket chat is that it seems to have all the pros of 
> Slack like close integration with tweeter, github etc etc . It has clients 
> for all OS and mobile devices. But not the big cons like the 10.000 messages 
> limit ( which we have long exceeded). Its open source and most importantly 
> written in javascript and we know that pharo can interface with javascript in 
> many diffirent ways .
> 
> Hosted on Github and deployable with open source technologies. 
> 
> And even its license is MIT. 
> 
> The reviews I have read about it are very positive. 
> 
> So what do you think ? 

Re: [Pharo-users] Rocket Chat - An open source alternative to Slack

[Dimitris Chloupis]

Where ?
On Thu, 17 Dec 2015 at 08:21, John Pfersich  wrote:

> I set up a public #pharo channel. Join it!
>
> Sent from my iPad
>
> On Dec 16, 2015, at 02:04, Dimitris Chloupis 
> wrote:
>
> So since Slack has been so successful for our community , far more that
> IRC has been in terms of participation and useful discussions (at least the
> 2 years I have been around)
>
> it made me wonder if I could find an open source alternative to Slack that
> is at least as good as it if not better without a very different workflow
> (so we have to learn everything from zero) all the big pros and something
> that could easily interface with Pharo.
>
> Ladies and gentlemen meet Rocket Chat
>
> https://rocket.chat/
>
> The good news about Rocket chat is that it seems to have all the pros of
> Slack like close integration with tweeter, github etc etc . It has clients
> for all OS and mobile devices. But not the big cons like the 10.000
> messages limit ( which we have long exceeded). Its open source and most
> importantly written in javascript and we know that pharo can interface with
> javascript in many diffirent ways .
>
> Hosted on Github and deployable with open source technologies.
>
> And even its license is MIT.
>
> The reviews I have read about it are very positive.
>
> So what do you think ?
>
>

Re: [Pharo-users] get json data from external url

[Sabine Manaa]

Hi Sven,

thanks, that works perfect and is much more readable.

Doru, yes the Inspector is very useful for that.

regards
Sabine

2015-12-16 6:25 GMT+01:00 Tudor Girba-2 [via Smalltalk] <
ml-node+s1294792n4867243...@n4.nabble.com>:

> Somewhat related: please keep in mind that the inspector provides basic
> support for navigating dictionaries, and this is equivalent with a JSON
> browser:
>
>
> Cheers,
> Doru
>
>
>
> On Dec 15, 2015, at 11:44 PM, Sven Van Caekenberghe <[hidden email]
> > wrote:
>
> When putting non-ASCII in URLs it is best (needed) to construct the URL
> manually from components.
>
> ZnClient new
>  url: (ZnUrl new scheme: #http; host: 'maps.googleapis.com';
> addPathSegments: #(maps api geocode json); queryAt: #address put:
> 'Flughafen Schönefeld, 12521 Schönefeld, Germany'; queryAt: #sensor put:
> false; yourself);
>  contentReader: [ :entity | NeoJSONReader fromString: entity contents ];
>  get.
>
> If you know how to write such URL in their full encoded form, #asZnUrl
> still works.
>
> 'http://maps.googleapis.com/maps/api/geocode/json?address=Flughafen%20Sch%C3%B6nefeld,%2012521%20Sch%C3%B6nefeld,%20Germany=false'
> asZnUrl.
>
> On 15 Dec 2015, at 22:14, Sabine Manaa <[hidden email]
> > wrote:
>
> Hi Sven,
>
>
> what do you recommend in this case:
>
> ZnClient new
>  url: 'http://maps.googleapis.com/maps/api/geocode/json?address=
> http://maps.googleapis.com/maps/api/geocode/json?address=Günsel Ideli,
> 8152 Glattbrugg, Schweiz=false=false';
>  contentReader: [ :entity | NeoJSONReader fromString: entity contents];
> ifFail: [:ex|  ];
>  get.
>
> ->>
> ZnCharacterEncodingError signal: 'ASCII character expected'
>
> It is the "ü" n "Günsel"
>
> or:
>
> ZnClient new
>  url: 'http://maps.googleapis.com/maps/api/geocode/json?address=
> http://maps.googleapis.com/maps/api/geocode/json?address=Guarulhos - São
> Paulo, Brasilien=false=false';
>  contentReader: [ :entity | NeoJSONReader fromString: entity contents];
> ifFail: [:ex|  ];
>  get.
>
> "ã"
>
> regards
> Sabine
>
> 2015-12-15 19:23 GMT+01:00 Sabine Manaa <[hidden email]
> >:
> Hi Sven,
>
> great and thanks a lot for the immediate response. I can proceed with this!
>
> Have a nice christmas
> Sabine
>
> 2015-12-15 18:47 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk]
> <[hidden email]>:
> Hi,
>
> This will do (provided you have NeoJson loaded):
>
> ZnClient new
>  url: 'http://maps.googleapis.com/maps/api/geocode/json?
> address=1600+Amphitheatre+Parkway,+Mountain+View,+CA=false';
>  contentReader: [ :entity | NeoJSONReader fromString: entity contents];
>  get.
>
> Sven
>
> On 15 Dec 2015, at 18:30, Sabine Manaa <[hidden email]> wrote:
>
> I assume it is simple but I don't get it:
>
> Entering this in the web browser, I get a Json string in the web browser:
> http://maps.googleapis.com/maps/api/geocode/json?
> address=1600+Amphitheatre+Parkway,+Mountain+View,+CA=false
>
> I want to call this from Pharo and I want to use the results within pharo.
>
> Can anyone give me a hint?
>
> I was experimenting with sth like this but I was not successful:
>
> (html jQuery getJson
>  url:
> '
> http://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA=false
> ';
>onSuccess: '???';
> dataType: 'json') inspect
>
> Regards
> Sabine
>
>
>
> --
> View this message in context:
> http://forum.world.st/get-json-data-from-external-url-tp4867166.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>
>
>
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.world.st/get-json-data-from-external-url-tp4867166p4867169.html
> To start a new topic under Pharo Smalltalk Users, email [hidden email]
> To unsubscribe from get json data from external url, click here.
> NAML
>
>
> View this message in context: Re: get json data from external url
>
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.world.st/get-json-data-from-external-url-tp4867166p4867243.html
> To start a new topic under Pharo Smalltalk Users, email
> ml-node+s1294792n1310670...@n4.nabble.com
> To unsubscribe from get json data from external url, click here
> 
> .
> NAML
> 

Re: [Pharo-users] Roassal Performance Issues when applying layout

[Esteban Lorenzano]

that’s most probably a bug in new FFI-NB backend. 
I would love some help here :)
In any case, I will get back to FFI-NB as soon as I finish migration.

Esteban

> On 16 Dec 2015, at 12:03, Alexandre Bergel  wrote:
> 
> Currently text in Roassal does not work with Spur: it is wrongly positioned, 
> and does not appear sometime… I did not look into more detail.
> 
> Cheers,
> Alexandre
> 
> 
>> On Dec 16, 2015, at 2:26 AM, Ben Coman  wrote:
>> 
>> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman  wrote:
>>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak  wrote:
 On 12/07, Alejandro Infante wrote:
> Hi,
> It is really difficult to help you just with a profile and without 
> looking at your code.
> Even though, I have noticed that most of the time is used on calculating 
> properties related to CompositeShapes (like position and encompassing 
> rectangle).
> 
> Would be possible for you to run the same code but replacing the 
> CompositeShape by another less complex shape (like RTBox)?
> If this new experiment is fast, then the problem would be those 2 
> properties (position and encompassing rectangle) are too expensive, and 
> therefore we should think how to optimize that code.
> 
> I know that ForceLayout is not the fastest layout, but 59 seconds is too 
> much for just 13 elements.
 
 The complexity should be nlog(n) per iteration.
 For such small diagram this should be pretty much instant.
 
 However from the profiler I can see that a _lot_ of time is spent in
 calculating the label size, which definitely shouldn't be this slow...
>>> 
>>> I had this problem with labels a while a go in Rossal 1 when using
>>> Unicode in a label.
>>> https://github.com/moosetechnology/moose/issues/898
>>> 
>>> From memory it came down to calculating the width of a unicode string.
>>> I think I hacked it in the rendering loop, such that the string width
>>> is cached along with a copy of the string. Next iteration if the
>>> string was the same return the cached value, otherwise recalculate. I
>>> think I discounted resetting the cache to nil when setting the label
>>> string due to inter thread races.
>>> 
>>> cheers -ben
>> 
>> Spur should help also with WideString ~8 times speedup
>> https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
>> 
>> which we should be able to test soon...
>> cheers -ben
>> 
>>> 
 
 If you want to look at the other layouts, look at this
 https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html
 
> 
> Cheers,
> Alejandro
> 
>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco  wrote:
>> 
>> Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer 
>> Science students at Universidad de Chile.
>> 
>> We are currently taking a course on Robotics Software Engineering 
>> dictated by Johan Fabry.
>> 
>> We want to visualize a simple directed graph and we are experiencing 
>> performance issues when layouting our visualization in Roassal.
>> 
>> We provide the report from the Time Profiler when we visualize 13 
>> elements and 38 edges: http://pastebin.com/zsh8YFPx 
>> 
>> 
>> Should it take so much time? How could we improve it? Is there another 
>> more appropriate layout?
>> 
>> Thanks in advance :)
>> 
>> 
>> 
> 
 
 --
 Peter
 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-users] Roassal Performance Issues when applying layout

[Nicolai Hess]

2015-12-16 12:28 GMT+01:00 Nicolai Hess :

>
>
> 2015-12-16 12:10 GMT+01:00 Esteban Lorenzano :
>
>> that’s most probably a bug in new FFI-NB backend.
>>
>
> On windows (with spur-vm) most athens examples with transformations and/or
> text don't work (-> crash the vm).
>

interestingly:

AthensSurfaceExamples draw2Strings.
-> crash

FreeTypeFontProvider current updateFromSystem.

AthensSurfaceExamples draw2Strings.
-> works



>
>
>> I would love some help here :)
>>
>
> where to start? Is there a documentation about ffi/nb changes ( I hope
> so!). I saw some changes in Athens code but I don't understand it.
>
>
>
>
>> In any case, I will get back to FFI-NB as soon as I finish migration.
>>
>>
>
>
>
>> Esteban
>>
>> > On 16 Dec 2015, at 12:03, Alexandre Bergel 
>> wrote:
>> >
>> > Currently text in Roassal does not work with Spur: it is wrongly
>> positioned, and does not appear sometime… I did not look into more detail.
>> >
>> > Cheers,
>> > Alexandre
>> >
>> >
>> >> On Dec 16, 2015, at 2:26 AM, Ben Coman  wrote:
>> >>
>> >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman 
>> wrote:
>> >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak 
>> wrote:
>>  On 12/07, Alejandro Infante wrote:
>> > Hi,
>> > It is really difficult to help you just with a profile and without
>> looking at your code.
>> > Even though, I have noticed that most of the time is used on
>> calculating properties related to CompositeShapes (like position and
>> encompassing rectangle).
>> >
>> > Would be possible for you to run the same code but replacing the
>> CompositeShape by another less complex shape (like RTBox)?
>> > If this new experiment is fast, then the problem would be those 2
>> properties (position and encompassing rectangle) are too expensive, and
>> therefore we should think how to optimize that code.
>> >
>> > I know that ForceLayout is not the fastest layout, but 59 seconds
>> is too much for just 13 elements.
>> 
>>  The complexity should be nlog(n) per iteration.
>>  For such small diagram this should be pretty much instant.
>> 
>>  However from the profiler I can see that a _lot_ of time is spent in
>>  calculating the label size, which definitely shouldn't be this
>> slow...
>> >>>
>> >>> I had this problem with labels a while a go in Rossal 1 when using
>> >>> Unicode in a label.
>> >>> https://github.com/moosetechnology/moose/issues/898
>> >>>
>> >>> From memory it came down to calculating the width of a unicode string.
>> >>> I think I hacked it in the rendering loop, such that the string width
>> >>> is cached along with a copy of the string. Next iteration if the
>> >>> string was the same return the cached value, otherwise recalculate. I
>> >>> think I discounted resetting the cache to nil when setting the label
>> >>> string due to inter thread races.
>> >>>
>> >>> cheers -ben
>> >>
>> >> Spur should help also with WideString ~8 times speedup
>> >> https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
>> >>
>> >> which we should be able to test soon...
>> >> cheers -ben
>> >>
>> >>>
>> 
>>  If you want to look at the other layouts, look at this
>> 
>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html
>> 
>> >
>> > Cheers,
>> > Alejandro
>> >
>> >> On Dec 7, 2015, at 5:26 PM, Pablo Polanco 
>> wrote:
>> >>
>> >> Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer
>> Science students at Universidad de Chile.
>> >>
>> >> We are currently taking a course on Robotics Software Engineering
>> dictated by Johan Fabry.
>> >>
>> >> We want to visualize a simple directed graph and we are
>> experiencing performance issues when layouting our visualization in Roassal.
>> >>
>> >> We provide the report from the Time Profiler when we visualize 13
>> elements and 38 edges: http://pastebin.com/zsh8YFPx <
>> http://pastebin.com/zsh8YFPx>
>> >>
>> >> Should it take so much time? How could we improve it? Is there
>> another more appropriate layout?
>> >>
>> >> Thanks in advance :)
>> >>
>> >> 
>> >>
>> >
>> 
>>  --
>>  Peter
>> 
>> >>
>> >
>> > --
>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> > Alexandre Bergel  http://www.bergel.eu
>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >
>> >
>> >
>> >
>>
>>
>>
>

Re: [Pharo-users] Machine Learning in Pharo

[Serge Stinckwich]

Yes you can just here:

https://groups.google.com/forum/#!forum/scismalltalk

Regards,

On Sun, Dec 13, 2015 at 10:15 PM, stepharo  wrote:
> Check the sciSmalltalk mailing-list.
> and the Numerical book
>
> Stef
>
> Le 13/12/15 21:02, Evan Donahue a écrit :
>
>> I saw a post on pharo-dev a little while ago about adding some machine
>> learning libraries to pharo, and I was just wondering if there have
>> been any developments on that front. I'm about to do some machine learning
>> work myself, so it might make sense to coordinate with anyone out there
>> already working on it.
>>
>> Cheers,
>> Evan
>
>
>



-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-users] Roassal Performance Issues when applying layout

[Nicolai Hess]

2015-12-16 12:10 GMT+01:00 Esteban Lorenzano :

> that’s most probably a bug in new FFI-NB backend.
>

On windows (with spur-vm) most athens examples with transformations and/or
text don't work (-> crash the vm).


> I would love some help here :)
>

where to start? Is there a documentation about ffi/nb changes ( I hope
so!). I saw some changes in Athens code but I don't understand it.




> In any case, I will get back to FFI-NB as soon as I finish migration.
>
>



> Esteban
>
> > On 16 Dec 2015, at 12:03, Alexandre Bergel 
> wrote:
> >
> > Currently text in Roassal does not work with Spur: it is wrongly
> positioned, and does not appear sometime… I did not look into more detail.
> >
> > Cheers,
> > Alexandre
> >
> >
> >> On Dec 16, 2015, at 2:26 AM, Ben Coman  wrote:
> >>
> >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman  wrote:
> >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak  wrote:
>  On 12/07, Alejandro Infante wrote:
> > Hi,
> > It is really difficult to help you just with a profile and without
> looking at your code.
> > Even though, I have noticed that most of the time is used on
> calculating properties related to CompositeShapes (like position and
> encompassing rectangle).
> >
> > Would be possible for you to run the same code but replacing the
> CompositeShape by another less complex shape (like RTBox)?
> > If this new experiment is fast, then the problem would be those 2
> properties (position and encompassing rectangle) are too expensive, and
> therefore we should think how to optimize that code.
> >
> > I know that ForceLayout is not the fastest layout, but 59 seconds is
> too much for just 13 elements.
> 
>  The complexity should be nlog(n) per iteration.
>  For such small diagram this should be pretty much instant.
> 
>  However from the profiler I can see that a _lot_ of time is spent in
>  calculating the label size, which definitely shouldn't be this slow...
> >>>
> >>> I had this problem with labels a while a go in Rossal 1 when using
> >>> Unicode in a label.
> >>> https://github.com/moosetechnology/moose/issues/898
> >>>
> >>> From memory it came down to calculating the width of a unicode string.
> >>> I think I hacked it in the rendering loop, such that the string width
> >>> is cached along with a copy of the string. Next iteration if the
> >>> string was the same return the cached value, otherwise recalculate. I
> >>> think I discounted resetting the cache to nil when setting the label
> >>> string due to inter thread races.
> >>>
> >>> cheers -ben
> >>
> >> Spur should help also with WideString ~8 times speedup
> >> https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
> >>
> >> which we should be able to test soon...
> >> cheers -ben
> >>
> >>>
> 
>  If you want to look at the other layouts, look at this
> 
> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html
> 
> >
> > Cheers,
> > Alejandro
> >
> >> On Dec 7, 2015, at 5:26 PM, Pablo Polanco 
> wrote:
> >>
> >> Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer
> Science students at Universidad de Chile.
> >>
> >> We are currently taking a course on Robotics Software Engineering
> dictated by Johan Fabry.
> >>
> >> We want to visualize a simple directed graph and we are
> experiencing performance issues when layouting our visualization in Roassal.
> >>
> >> We provide the report from the Time Profiler when we visualize 13
> elements and 38 edges: http://pastebin.com/zsh8YFPx <
> http://pastebin.com/zsh8YFPx>
> >>
> >> Should it take so much time? How could we improve it? Is there
> another more appropriate layout?
> >>
> >> Thanks in advance :)
> >>
> >> 
> >>
> >
> 
>  --
>  Peter
> 
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
>
>

Re: [Pharo-users] Rocket Chat - An open source alternative to Slack

[Martin Bähr]

Excerpts from Dimitris Chloupis's message of 2015-12-16 11:04:04 +0100:
> So since Slack has been so successful for our community , far more that IRC
> has been in terms of participation and useful discussions (at least the 2
> years I have been around)
> 
> it made me wonder if I could find an open source alternative to Slack that
> is at least as good as it if not better without a very different workflow
> (so we have to learn everything from zero) all the big pros and something
> that could easily interface with Pharo.
> 
> Ladies and gentlemen meet Rocket Chat
> 
> https://rocket.chat/
> 
> The good news about Rocket chat is that it seems to have all the pros of
> Slack like close integration with tweeter, github etc etc . It has clients
> for all OS and mobile devices. 

what it doesn't have is support for irc clients:
https://github.com/RocketChat/Rocket.Chat/issues/1259

for me, that's a deal breaker. because as nice as these services are, i don't
have the patience to run a dozen clients for all different communication
services.

it is bad enough that these services are not federated and i have to connect to
them to communicate, but at least support for common, already existing clients,
should be there. 

it does seem to have an irc bridge at least. a bit ugly, but workable.

but there is also mattermost: http://mattermost.org/ (and it has irc client 
support)
seems at least as mature as rocket.chat.

greetings, martin.

-- 
eKita   -   the online platform for your entire academic life
-- 
chief engineer   eKita.co
pike programmer  pike.lysator.liu.secaudium.net societyserver.org
secretary  beijinglug.org
mentor   fossasia.org
foresight developer  foresightlinux.orgrealss.com
unix sysadmin
Martin Bähr  working in chinahttp://societyserver.org/mbaehr/

Re: [Pharo-users] Roassal Performance Issues when applying layout

[Alexandre Bergel]

Currently text in Roassal does not work with Spur: it is wrongly positioned, 
and does not appear sometime… I did not look into more detail.

Cheers,
Alexandre


> On Dec 16, 2015, at 2:26 AM, Ben Coman  wrote:
> 
> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman  wrote:
>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak  wrote:
>>> On 12/07, Alejandro Infante wrote:
 Hi,
 It is really difficult to help you just with a profile and without looking 
 at your code.
 Even though, I have noticed that most of the time is used on calculating 
 properties related to CompositeShapes (like position and encompassing 
 rectangle).
 
 Would be possible for you to run the same code but replacing the 
 CompositeShape by another less complex shape (like RTBox)?
 If this new experiment is fast, then the problem would be those 2 
 properties (position and encompassing rectangle) are too expensive, and 
 therefore we should think how to optimize that code.
 
 I know that ForceLayout is not the fastest layout, but 59 seconds is too 
 much for just 13 elements.
>>> 
>>> The complexity should be nlog(n) per iteration.
>>> For such small diagram this should be pretty much instant.
>>> 
>>> However from the profiler I can see that a _lot_ of time is spent in
>>> calculating the label size, which definitely shouldn't be this slow...
>> 
>> I had this problem with labels a while a go in Rossal 1 when using
>> Unicode in a label.
>> https://github.com/moosetechnology/moose/issues/898
>> 
>> From memory it came down to calculating the width of a unicode string.
>> I think I hacked it in the rendering loop, such that the string width
>> is cached along with a copy of the string. Next iteration if the
>> string was the same return the cached value, otherwise recalculate. I
>> think I discounted resetting the cache to nil when setting the label
>> string due to inter thread races.
>> 
>> cheers -ben
> 
> Spur should help also with WideString ~8 times speedup
> https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
> 
> which we should be able to test soon...
> cheers -ben
> 
>> 
>>> 
>>> If you want to look at the other layouts, look at this
>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html
>>> 
 
 Cheers,
 Alejandro
 
> On Dec 7, 2015, at 5:26 PM, Pablo Polanco  wrote:
> 
> Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science 
> students at Universidad de Chile.
> 
> We are currently taking a course on Robotics Software Engineering 
> dictated by Johan Fabry.
> 
> We want to visualize a simple directed graph and we are experiencing 
> performance issues when layouting our visualization in Roassal.
> 
> We provide the report from the Time Profiler when we visualize 13 
> elements and 38 edges: http://pastebin.com/zsh8YFPx 
> 
> 
> Should it take so much time? How could we improve it? Is there another 
> more appropriate layout?
> 
> Thanks in advance :)
> 
> 
> 
 
>>> 
>>> --
>>> Peter
>>> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-users] Roassal Performance Issues when applying layout

[Esteban Lorenzano]

> On 16 Dec 2015, at 12:28, Nicolai Hess  wrote:
> 
> 
> 
> 2015-12-16 12:10 GMT+01:00 Esteban Lorenzano  >:
> that’s most probably a bug in new FFI-NB backend.
> 
> On windows (with spur-vm) most athens examples with transformations and/or 
> text don't work (-> crash the vm).
>  
> I would love some help here :)
> 
> where to start? Is there a documentation about ffi/nb changes ( I hope so!). 
> I saw some changes in Athens code but I don't understand it.

I will do a blog post soon (™) :)

cheers, 
Esteban

> 
> 
>  
> In any case, I will get back to FFI-NB as soon as I finish migration.
> 
> 
> 
>  
> Esteban
> 
> > On 16 Dec 2015, at 12:03, Alexandre Bergel  > > wrote:
> >
> > Currently text in Roassal does not work with Spur: it is wrongly 
> > positioned, and does not appear sometime… I did not look into more detail.
> >
> > Cheers,
> > Alexandre
> >
> >
> >> On Dec 16, 2015, at 2:26 AM, Ben Coman  wrote:
> >>
> >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman  >> > wrote:
> >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak  >>> > wrote:
>  On 12/07, Alejandro Infante wrote:
> > Hi,
> > It is really difficult to help you just with a profile and without 
> > looking at your code.
> > Even though, I have noticed that most of the time is used on 
> > calculating properties related to CompositeShapes (like position and 
> > encompassing rectangle).
> >
> > Would be possible for you to run the same code but replacing the 
> > CompositeShape by another less complex shape (like RTBox)?
> > If this new experiment is fast, then the problem would be those 2 
> > properties (position and encompassing rectangle) are too expensive, and 
> > therefore we should think how to optimize that code.
> >
> > I know that ForceLayout is not the fastest layout, but 59 seconds is 
> > too much for just 13 elements.
> 
>  The complexity should be nlog(n) per iteration.
>  For such small diagram this should be pretty much instant.
> 
>  However from the profiler I can see that a _lot_ of time is spent in
>  calculating the label size, which definitely shouldn't be this slow...
> >>>
> >>> I had this problem with labels a while a go in Rossal 1 when using
> >>> Unicode in a label.
> >>> https://github.com/moosetechnology/moose/issues/898 
> >>> 
> >>>
> >>> From memory it came down to calculating the width of a unicode string.
> >>> I think I hacked it in the rendering loop, such that the string width
> >>> is cached along with a copy of the string. Next iteration if the
> >>> string was the same return the cached value, otherwise recalculate. I
> >>> think I discounted resetting the cache to nil when setting the label
> >>> string due to inter thread races.
> >>>
> >>> cheers -ben
> >>
> >> Spur should help also with WideString ~8 times speedup
> >> https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html 
> >> 
> >>
> >> which we should be able to test soon...
> >> cheers -ben
> >>
> >>>
> 
>  If you want to look at the other layouts, look at this
>  https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html
>   
>  
> 
> >
> > Cheers,
> > Alejandro
> >
> >> On Dec 7, 2015, at 5:26 PM, Pablo Polanco  >> > wrote:
> >>
> >> Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer 
> >> Science students at Universidad de Chile.
> >>
> >> We are currently taking a course on Robotics Software Engineering 
> >> dictated by Johan Fabry.
> >>
> >> We want to visualize a simple directed graph and we are experiencing 
> >> performance issues when layouting our visualization in Roassal.
> >>
> >> We provide the report from the Time Profiler when we visualize 13 
> >> elements and 38 edges: http://pastebin.com/zsh8YFPx 
> >>   >> >
> >>
> >> Should it take so much time? How could we improve it? Is there another 
> >> more appropriate layout?
> >>
> >> Thanks in advance :)
> >>
> >> 
> >>
> >
> 
>  --
>  Peter
> 
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu 
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> 
> 
> 

[Pharo-users] Rocket Chat - An open source alternative to Slack

[Dimitris Chloupis]

So since Slack has been so successful for our community , far more that IRC
has been in terms of participation and useful discussions (at least the 2
years I have been around)

it made me wonder if I could find an open source alternative to Slack that
is at least as good as it if not better without a very different workflow
(so we have to learn everything from zero) all the big pros and something
that could easily interface with Pharo.

Ladies and gentlemen meet Rocket Chat

https://rocket.chat/

The good news about Rocket chat is that it seems to have all the pros of
Slack like close integration with tweeter, github etc etc . It has clients
for all OS and mobile devices. But not the big cons like the 10.000
messages limit ( which we have long exceeded). Its open source and most
importantly written in javascript and we know that pharo can interface with
javascript in many diffirent ways .

Hosted on Github and deployable with open source technologies.

And even its license is MIT.

The reviews I have read about it are very positive.

So what do you think ?