December 2015 - Pharo-users

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

by 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 < offray(a)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. > > > > >

Dec. 16, 2015

Re: [Pharo-users] New web tutorial

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

Dec. 16, 2015

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

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

Dec. 16, 2015

Re: [Pharo-users] Machine Learning in Pharo

by 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 <stepharo(a)free.fr> 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/

Dec. 16, 2015

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

by 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.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Dec. 16, 2015

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

by Nicolai Hess

2015-12-16 12:28 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> 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 <alexandre.bergel(a)me.com> >> 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 <btc(a)openInWorld.com> wrote: >> >> >> >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc(a)openinworld.com> >> wrote: >> >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak(a)gmail.com> >> 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… >> >>>> >> >>>>> >> >>>>> Cheers, >> >>>>> Alejandro >> >>>>> >> >>>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga(a)gmail.com> >> 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 :) >> >>>>>> >> >>>>>> <Screenshot from 2015-12-07 17:23:05.png> >> >>>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> Peter >> >>>> >> >> >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> >

Dec. 16, 2015

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

by Esteban Lorenzano

> On 16 Dec 2015, at 12:28, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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 <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> 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 <btc(a)openInWorld.com> wrote: > >> > >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> 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 <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 <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… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106…> > >>>> > >>>>> > >>>>> Cheers, > >>>>> Alejandro > >>>>> > >>>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga(a)gmail.com <mailto:paropoga@gmail.com>> 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> <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 :) > >>>>>> > >>>>>> <Screenshot from 2015-12-07 17:23:05.png> > >>>>>> > >>>>> > >>>> > >>>> -- > >>>> Peter > >>>> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Dec. 16, 2015

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

by Nicolai Hess

2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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 <alexandre.bergel(a)me.com> > 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 <btc(a)openInWorld.com> wrote: > >> > >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc(a)openinworld.com> wrote: > >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak(a)gmail.com> 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… > >>>> > >>>>> > >>>>> Cheers, > >>>>> Alejandro > >>>>> > >>>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga(a)gmail.com> > 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 :) > >>>>>> > >>>>>> <Screenshot from 2015-12-07 17:23:05.png> > >>>>>> > >>>>> > >>>> > >>>> -- > >>>> Peter > >>>> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Dec. 16, 2015

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

by 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 <alexandre.bergel(a)me.com> 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 <btc(a)openInWorld.com> wrote: >> >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak(a)gmail.com> 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… >>>> >>>>> >>>>> Cheers, >>>>> Alejandro >>>>> >>>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga(a)gmail.com> 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 :) >>>>>> >>>>>> <Screenshot from 2015-12-07 17:23:05.png> >>>>>> >>>>> >>>> >>>> -- >>>> Peter >>>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 16, 2015

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

by 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 <btc(a)openInWorld.com> wrote: > > On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc(a)openinworld.com> wrote: >> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak(a)gmail.com> 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… >>> >>>> >>>> Cheers, >>>> Alejandro >>>> >>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga(a)gmail.com> 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 :) >>>>> >>>>> <Screenshot from 2015-12-07 17:23:05.png> >>>>> >>>> >>> >>> -- >>> Peter >>> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 16, 2015