February 2020 - Pharo-users

Re: [Pharo-users] [Lse-pharo4pharo] Alignment visualization performance

by HernÃ¡n Morales Durand

Done here : https://github.com/pharo-project/pharo/issues/5737 Cheers, HernÃ¡n El sÃ¡b., 22 feb. 2020 a las 5:22, StÃ©phane Ducasse (< stephane.ducasse(a)inria.fr>) escribiÃ³: > could you open a bug entry and we will tag it for large images. > > On 21 Feb 2020, at 06:40, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Hello guys. > > I want to visualize DNA sequence alignments in Pharo 8. For this task most > bioinformatics applications set a background color for each letter. But in > Pharo the Inspector is too slow to open even for just one small sequence of > 1Kb. Consider now there are about 37k sequences of COVID-19 and each genome > contains about 30k of letters, so visualizing and scrolling these should be > fast (as for zooming). > > But have a look at this script which takes about 6 seconds to open an > Inspector. The script uses BioSmalltalk, and the code could be enhanced for > sure, but that is not relevant to my performance problem of visualization: > > [ > | text attributes | > " Generate a Text object from a random sequence " > text := ((BioSequence forAlphabet: BioDNAAlphabet) randomLength: 1000) > sequence asText. > " Setup an array for each nucleotide background color " > attributes := Array new: text size. > 1 to: text size do: [ : index | > attributes at: index put: { > (TextBackgroundColor color: (BioDNAAlphabet colorMap at: (text at: > index))) } ]. > text runs: (RunArray newFrom: attributes). > text inspect > ] timeToRun asString "'0:00:00:05.911'" > > Also, resizing the opened Inspector takes 2-3 seconds to refresh. > You can see the output here: https://imgur.com/a/xUlBeVY > > I should say without the #inspect the code ran without performance issues: > "'0:00:00:00.009'" > > So I ran again the script for different sequence sizes: > > String streamContents: [ : stream | > 100 to: 2000 by: 100 do: [ : sl | > stream nextPutAll: ([ > | text attributes | > " Generate a Text object from a random sequence " > text := ((BioSequence forAlphabet: BioDNAAlphabet) randomLength: sl) > sequence asText. > " Setup an array for each nucleotide background color " > attributes := Array new: text size. > 1 to: text size do: [ : index | > attributes at: index put: { > (TextBackgroundColor color: (BioDNAAlphabet colorMap at: (text at: > index))) } ]. > text runs: (RunArray newFrom: attributes). > text inspect > ] timeToRun asString); > cr > ] > ] > > And these are the results: > > 0:00:00:00.147 > 0:00:00:00.28 > 0:00:00:00.568 > 0:00:00:00.993 > 0:00:00:01.776 > 0:00:00:02.123 > 0:00:00:03.111 > 0:00:00:04.084 > 0:00:00:04.574 > 0:00:00:06.192 > 0:00:00:07.214 > 0:00:00:07.915 > 0:00:00:10.382 > 0:00:00:12.725 > 0:00:00:12.359 > 0:00:00:17.357 > 0:00:00:17.147 > 0:00:00:20.651 > 0:00:00:20.392 > 0:00:00:23.238 > > At first I thought it was a problem of the Glamout text renderer for > Rubric Text, but profiling a single pass of the snippet for 2000 letters, > shows a couple of methods in Rubric scanner, after some DNU sends, which > are consuming a lot of the time: > RubCharacterBlockScanner(RubCharacterBlockScanner) >> > characterBlockAtPoint:index:in: and > RubCharacterBlockScanner(RubCharacterBlockScanner) >> endOfRun". I attached > the full profiler report so you may have a look if you like. But the > summary is: > > **Leaves** > 37.4% {8800ms} > RubCompositionScanner(RubCharacterScanner)>>basicScanCharactersFrom:to:in:rightX:stopConditions:kern: > 6.3% {1476ms} Dictionary>>at:ifAbsentPut: > 6.1% {1425ms} Context>>unwindComplete > 4.6% {1082ms} Semaphore>>criticalReleasingOnError: > 4.2% {991ms} Dictionary>>at:ifAbsent: > 3.3% {785ms} Context>>aboutToReturn:through: > 2.2% {527ms} Context>>resume:through: > 2.0% {470ms} ExternalAddress>>isNull > 1.8% {421ms} BlockClosure>>on:do: > 1.7% {402ms} > RubCharacterBlockScanner(RubCharacterScanner)>>setConditionArray: > 1.6% {378ms} FreeTypeFace>>validate > 1.6% {376ms} Dictionary>>scanFor: > 1.5% {364ms} Context>>unwindComplete: > 1.5% {344ms} Context>>unwindBlock > 1.4% {323ms} Array(SequenceableCollection)>>do: > 1.3% {299ms} Dictionary(HashedCollection)>>findElementOrNil: > 1.2% {293ms} RunArray>>at:setRunOffsetAndValue: > 1.2% {289ms} FreeTypeCache>>atFont:charCode:type:ifAbsentPut: > 1.1% {252ms} FreeTypeCacheLinkedList>>moveDown: > > **Memory** > old +0 bytes > young -1,485,272 bytes > used -1,485,272 bytes > free +1,485,272 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 947 totalling 1,576ms (7.0% uptime), avg 2.0ms > tenures 0 > root table 0 overflows > > So my question is, is there any other text rendering backends to try? And > when I say backends I say which don't use Rubric. > > Cheers, > > HernÃ¡n > > <Profile_DNABgColoring.txt>_______________________________________________ > Lse-pharo4pharo mailing list > Lse-pharo4pharo(a)lists.gforge.inria.fr > https://lists.gforge.inria.fr/mailman/listinfo/lse-pharo4pharo > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

Feb. 22, 2020

[ANN] Round 3 Results Are In

by Richard Kenneth Eng

https://www.youtube.com/watch?v=iNyu-3Y2arg This time, the teams must deal with Jump cells, Warp cells, and Death cells. If you land on a Death cell, you die and the simulation terminates. Next week is the most exciting round yet. Multiple teams will be competing on the same board! This will look so damn cool on YouTube. Richard

Feb. 22, 2020

Re: [Pharo-users] P8/Linux - External module not found LGitLibrary

by Hilaire

An update. I pickup the wget bash script option, and the provided VM is doing fine. Therefore, the issue is related to the proposed VM for download. Hilaire -- Dr. Geo http://drgeo.eu

Feb. 22, 2020

P8/Linux - External module not found LGitLibrary

by Hilaire

Hi, I have this issue with P8 standalone VM and image installed from pharo.org/download. Am I missing something? PharoDebug attached. Thanks Hilaire PS1: I need standalone to prepare dev. environment and application for drgeo. PS2: On the same host I have been running P7 to contribute pull request without this git issue. -- Dr. Geo http://drgeo.eu

Feb. 21, 2020

Glamour: multi section list.

by Federico.Balaguer

Hi! I am having problems to select multiple non-contiguous elements on a Glamour List such the one in the MultiSeclection List example of Glamour. On the Glamour example, I have a list 10 elements and I want to select the first and the last one. After selecting the first one (left click) I am trying to select the last one with Ctrl + left click but it does not work. A friend of mine said that in Mac (pharo8) it works but in my linux box (Pharo 7 and Pharo8) it does not. Do I have to change some setting? Thanks! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 21, 2020

Re: [Pharo-users] PolyMath v1.0.2 release

by Serge Stinckwich

On Fri, Feb 21, 2020 at 7:48 AM Markus Stumptner <mst(a)cs.unisa.edu.au> wrote: > Thanks for keeping working on this. I have a question, how much are the > core classes of Polymath changed beyond the original Besset classes (or, > beyond the "PM" prefix, how much has been changed relative to those that > come with the Visualworks distribution)? I'm not asking about external > bindings such as the Tensorflow stuff, just the consistency of protocols > for internal code. We have some long-running projects and compatibility > across environments (beyond the obvious environment differences) is quite > important. > > Hi Markus, thank you for your interest for PolyMath ! I add the polymath mailing-list in CC. This is a better place for discussions for PolyMath issues instead of Pharo-users. Unfortunately, I dunno exactly how much changes has been done compared to the original version, because we add a lot of unit tests, we fix bugs, we add new functionalities like automatic differentiation, ODE solvers, data analysis tools, etc ... Even if Didier Besset's code still represents an important part of PolyMath, this percentage decreases as we add more functionalities. If you want to continue to use the original code, this is still possible to find the original version of SqueakSource I think. I would be interested to know what you are doing with PolyMath. If this is something that you could not share here, you can send me a private email. You can also contribute bugs/code: https://github.com/PolyMathOrg/PolyMath/issues If someone want a port of last version of PolyMath to VW, please contribute some fundings :-) Regards, -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroon "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

Feb. 21, 2020

Re: Problem with ZnWebSocket and closed connections

by Davide Varvello

Hi Sven, Sorry, I put too many useless details in my previous email. The core issue is that if I point to the websocket directly (ws://localhost:8000) the connection lasts, otherwise it disconnects after a while. Cheers Davide Sven Van Caekenberghe-2 wrote > Hi Davide, > > I am away until next week, then I might try to answer, though you are > talking about a complicated setup. > > Sven > >> On 20 Feb 2020, at 19:08, Davide Varvello via Pharo-users < > pharo-users@.pharo > > wrote: >> >> >> From: Davide Varvello < > varvello@ > > >> Subject: Problem with ZnWebSocket and closed connections >> Date: 20 February 2020 at 19:08:43 GMT+1 >> To: > pharo-users@.pharo >> >> >> Hi guys! >> I've a problem with websockets, I'm quite a noob on the subject and I'm >> doing some tests with them. >> >> I run the echo websocket this way: >> >> ZnServer startDefaultOn: 8000. >> ZnServer default delegate: (ZnWebSocketDelegate handler: >> ZnWebSocketEchoHandler new). >> >> >> I tested it with with the chrome extension >> (https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblng…) >> that emulates a websocket client. If I point to the url >> ws://localhost:8000 >> everyting is fine >> BUT >> I want to test the websocket server via ngrok (https://ngrok.com/) and if >> I >> point the client to the ngrok url (i.e. ws://myurl.ngrok.io that maps >> localhost:8000) it happens a connection-closed after a while and I can't >> understand the cause, is there a timeout somewhere? >> >> I know that it is something related to Pharo (and not to ngrok) because >> if I >> implement a simple echo websocket served via websocketd >> (http://websocketd.com) the connection stays always active even if >> through >> ngrok. >> >> Can you help me please? >> TIA >> Davide >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 21, 2020

Re: [Pharo-users] PolyMath v1.0.2 release

by Markus Stumptner

Thanks for keeping working on this. I have a question, how much are the core classes of Polymath changed beyond the original Besset classes (or, beyond the "PM" prefix, how much has been changed relative to those that come with the Visualworks distribution)?Â Â I'm not asking about external bindings such as the Tensorflow stuff, just the consistency of protocols for internal code.Â We have some long-running projects and compatibility across environments (beyond the obvious environment differences) is quite important. Thanks Markus On 6/02/2020 23:49, Serge Stinckwich wrote: > Dear all, > > we are happy to announce the release of PolyMath 1.0.2, the > computational framework for Pharo. This release works on Pharo 7.0 and > Pharo 8.0. All the 815 tests and the CI are green on MacOs, Windows > and Linux :-) > > Please find more information about the project here: > https://github.com/PolyMathOrg/PolyMath > <https://github.com/PolyMathOrg/PolyMath> > > Changelog of modifications since version 1.0.1 is available here: > https://github.com/PolyMathOrg/PolyMath/milestone/4?closed=1 > > You can install the 1.0.2 version in a fresh Pharo 7.0&8.0 with the > following code snippet: > > Metacello new > repository: 'github://PolyMathOrg/PolyMath:v1.0.2/src'; > baseline: 'PolyMath'; > load > > You can join the dev team on #polymath channel for weekly meetings on > Thursday. We are looking for more people for tests and contributions. > > I'm starting a small experiment. If you want to support me working on > PolyMath or others of my project like Tensorflow Pharo bindings, you > can be one of my github sponsors. > > Please give a monthly support here: > https://github.com/sponsors/SergeStinckwich > > Regards, > -- > Serge Stinckwic > h > > Int. Research Unit > Â on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University > Â (SU) > French National Research Institute for Sustainable Development (IRD) > U > niversity of YaoundÃ© I, Cameroon > "Programs must be written for people to read, and only incidentally > for machines to execute." > https://twitter.com/SergeStinckwich >

Feb. 21, 2020

Alignment visualization performance

by HernÃ¡n Morales Durand

Hello guys. I want to visualize DNA sequence alignments in Pharo 8. For this task most bioinformatics applications set a background color for each letter. But in Pharo the Inspector is too slow to open even for just one small sequence of 1Kb. Consider now there are about 37k sequences of COVID-19 and each genome contains about 30k of letters, so visualizing and scrolling these should be fast (as for zooming). But have a look at this script which takes about 6 seconds to open an Inspector. The script uses BioSmalltalk, and the code could be enhanced for sure, but that is not relevant to my performance problem of visualization: [ | text attributes | " Generate a Text object from a random sequence " text := ((BioSequence forAlphabet: BioDNAAlphabet) randomLength: 1000) sequence asText. " Setup an array for each nucleotide background color " attributes := Array new: text size. 1 to: text size do: [ : index | attributes at: index put: { (TextBackgroundColor color: (BioDNAAlphabet colorMap at: (text at: index))) } ]. text runs: (RunArray newFrom: attributes). text inspect ] timeToRun asString "'0:00:00:05.911'" Also, resizing the opened Inspector takes 2-3 seconds to refresh. You can see the output here: https://imgur.com/a/xUlBeVY I should say without the #inspect the code ran without performance issues: "'0:00:00:00.009'" So I ran again the script for different sequence sizes: String streamContents: [ : stream | 100 to: 2000 by: 100 do: [ : sl | stream nextPutAll: ([ | text attributes | " Generate a Text object from a random sequence " text := ((BioSequence forAlphabet: BioDNAAlphabet) randomLength: sl) sequence asText. " Setup an array for each nucleotide background color " attributes := Array new: text size. 1 to: text size do: [ : index | attributes at: index put: { (TextBackgroundColor color: (BioDNAAlphabet colorMap at: (text at: index))) } ]. text runs: (RunArray newFrom: attributes). text inspect ] timeToRun asString); cr ] ] And these are the results: 0:00:00:00.147 0:00:00:00.28 0:00:00:00.568 0:00:00:00.993 0:00:00:01.776 0:00:00:02.123 0:00:00:03.111 0:00:00:04.084 0:00:00:04.574 0:00:00:06.192 0:00:00:07.214 0:00:00:07.915 0:00:00:10.382 0:00:00:12.725 0:00:00:12.359 0:00:00:17.357 0:00:00:17.147 0:00:00:20.651 0:00:00:20.392 0:00:00:23.238 At first I thought it was a problem of the Glamout text renderer for Rubric Text, but profiling a single pass of the snippet for 2000 letters, shows a couple of methods in Rubric scanner, after some DNU sends, which are consuming a lot of the time: RubCharacterBlockScanner(RubCharacterBlockScanner) >> characterBlockAtPoint:index:in: and RubCharacterBlockScanner(RubCharacterBlockScanner) >> endOfRun". I attached the full profiler report so you may have a look if you like. But the summary is: **Leaves** 37.4% {8800ms} RubCompositionScanner(RubCharacterScanner)>>basicScanCharactersFrom:to:in:rightX:stopConditions:kern: 6.3% {1476ms} Dictionary>>at:ifAbsentPut: 6.1% {1425ms} Context>>unwindComplete 4.6% {1082ms} Semaphore>>criticalReleasingOnError: 4.2% {991ms} Dictionary>>at:ifAbsent: 3.3% {785ms} Context>>aboutToReturn:through: 2.2% {527ms} Context>>resume:through: 2.0% {470ms} ExternalAddress>>isNull 1.8% {421ms} BlockClosure>>on:do: 1.7% {402ms} RubCharacterBlockScanner(RubCharacterScanner)>>setConditionArray: 1.6% {378ms} FreeTypeFace>>validate 1.6% {376ms} Dictionary>>scanFor: 1.5% {364ms} Context>>unwindComplete: 1.5% {344ms} Context>>unwindBlock 1.4% {323ms} Array(SequenceableCollection)>>do: 1.3% {299ms} Dictionary(HashedCollection)>>findElementOrNil: 1.2% {293ms} RunArray>>at:setRunOffsetAndValue: 1.2% {289ms} FreeTypeCache>>atFont:charCode:type:ifAbsentPut: 1.1% {252ms} FreeTypeCacheLinkedList>>moveDown: **Memory** old +0 bytes young -1,485,272 bytes used -1,485,272 bytes free +1,485,272 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 947 totalling 1,576ms (7.0% uptime), avg 2.0ms tenures 0 root table 0 overflows So my question is, is there any other text rendering backends to try? And when I say backends I say which don't use Rubric. Cheers, HernÃ¡n

Feb. 21, 2020

Re: [Pharo-users] Problem with ZnWebSocket and closed connections

by Sven Van Caekenberghe

Hi Davide, I am away until next week, then I might try to answer, though you are talking about a complicated setup. Sven > On 20 Feb 2020, at 19:08, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Davide Varvello <varvello(a)yahoo.com> > Subject: Problem with ZnWebSocket and closed connections > Date: 20 February 2020 at 19:08:43 GMT+1 > To: pharo-users(a)lists.pharo.org > > > Hi guys! > I've a problem with websockets, I'm quite a noob on the subject and I'm > doing some tests with them. > > I run the echo websocket this way: > > ZnServer startDefaultOn: 8000. > ZnServer default delegate: (ZnWebSocketDelegate handler: > ZnWebSocketEchoHandler new). > > > I tested it with with the chrome extension > (https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblng…) > that emulates a websocket client. If I point to the url ws://localhost:8000 > everyting is fine > BUT > I want to test the websocket server via ngrok (https://ngrok.com/) and if I > point the client to the ngrok url (i.e. ws://myurl.ngrok.io that maps > localhost:8000) it happens a connection-closed after a while and I can't > understand the cause, is there a timeout somewhere? > > I know that it is something related to Pharo (and not to ngrok) because if I > implement a simple echo websocket served via websocketd > (http://websocketd.com) the connection stays always active even if through > ngrok. > > Can you help me please? > TIA > Davide > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > >

Feb. 20, 2020