October 2018 - Pharo-users - lists.pharo.org

glamorous toolkit alpha.2

by Tudor Girba

Hi, Glamorous Toolkit has evolved quite a bit over the past months, and we now would like to announce that we reached alpha.2 version. It runs on top of Pharo 7: feenk.com/gt There quite a number of new things. Some highlights are: - We added extensive documentation for GT, Bloc and Brick. By running "GtWorld openTourâ you essentially transform the image into an elaborate wiki. - We worked on Coder, a new set of tools that are dedicated for affecting code. For example, in the picture below we see an editor on embedded examples that can be edited and run independently. And this one shows how we can visualize and edit the result of querying. Just a note: To make Coder work the way we want, we extended Brick with several widgets, and enhanced significantly the linear and grid layouts. - We added the first version of xdoc in order to serialize the Playground every time you evaluate something. As always, we are looking forward to your feedback. Have fun, The feenk team -- www.feenk.com -- www.feenk.com "Every thing should have the right to be different."

Oct. 31, 2018

Re: [Pharo-users] Http persistent connections

by Jimmie Houchin

On 10/31/18 8:16 AM, Sven Van Caekenberghe wrote: > Hi Jimmie, > >> On 31 Oct 2018, at 14:01, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> >> Hello, >> >> I am writing an app which accesses a REST api. The documentation says this. >> >> Connection Limits >> >> To provide equal resources to all clients, we recommend limiting both the number of new connections per second, and the number of requests per second made on a persistent connection (see above/below). >> >> For new connections, we recommend you limit this to twice per second (2/s). Establishing a new TCP and SSL connection is expensive for both client and server. To allow a better experience, using a persistent connection will allow more requests to be performed on an established connection. >> >> For an established connection, we recommend limiting this to one hundred per second (100/s). Please see following section on persistent connections to learn how to maintain a connection once it is established. >> >> HTTP Persistent Connection >> >> This keeps the underlying TCP connection active for multiple requests/responses. Subsequent requests will result in reduced latency as the TCP handshaking process is no longer required. >> >> If you are using an HTTP 1.0 client, ensure it supports the keep-alive directive and submit the header Connection: Keep-Alive with your request. >> >> Keep-Alive is part of the protocol in HTTP 1.1 and enabled by default on compliant clients. However, you will have to ensure your implementation does not set the connection header to other values. >> >> >> >> I do not know how to reuse a connection. >> >> I see in ZnClient #canReuseConnection and #connectionReuseTimeout. >> >> Is the timeout from connection time or last request or access time? >> >> Does that handle everything automatically for me? >> >> I will be accessing this api multiple times a minute, sometimes multiple times a second for almost all the time. >> >> How long can I keep a persistent connection open? >> >> What are best practices? >> >> Any help and wisdom greatly appreciated. >> >> Thanks. >> >> Jimmie > Yes, Zn fully and automagically supports persistent connections. > > In a first approach, just create one ZnClient instance, configure it with your host, etc, and then keep on reusing this instance for each (subsequent) request. Zn will keep client side connections open indefinitely. But a (busy) server will kill idle connections for sure. ZnClient will always try to connect again, before giving an error, so it effectively reconnects. > > You can look at client side logging by inspecting > > ZnLogEvent announcer > > to figure out what is happening. > > One warning though: if your app is multi user / multi threaded, you will probably need an http client instance per session. It is possibly necessary to prevent mixing up authentication info as well. > > HTH, > > Sven Thanks Sven. I thought that would be how it worked. You write beautiful software. I love to try to learn from what you write. Thanks for the pointer. Jimmie

Oct. 31, 2018

Re: [Pharo-users] MetaLink>>level: failing?

by Vitor Medina Cruz

Thanks! Is there an issue on fogbuzz where I can be notified of resolution? Do you need me to create it? After that how can update the code? Software update is safe or should I create a new image? regards, Vitor On Mon, Oct 29, 2018 at 12:08 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 25 Oct 2018, at 01:33, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Hello, > > I am playing with MetaLink, really cool!, but I am having issues that I am > unsure if it's some erro or if I am doing something wrong (I am using Pharo > 6.1 32 bits in windows.). Consider: > > TestMetaLink>>execute > UIManager default alert: 'Actual Version'. > > And in Playground: > > | link | > > link := MetaLink new metaObject: [ :object | UIManager default alert: > 'Linked Version' ]; > selector: #value:; > arguments: #(#object); > control: #instead. > > > (TestMetaLink >> #execute) ast link: link. > TestMetaLink new execute. > link uninstall. > > This works as expected, an alert with 'Linked Version' is promped. But > then suppose I want to execute the actual node alongside with the linked > one considering some condition: > > | link choice | > > choice := true. > link := MetaLink new metaObject: [ :object :selector :arguments | > UIManager default alert: > 'Linked Version'. > choice ifTrue: [ object > perform: selector withArguments: arguments]. > ]; > selector: #value:value:value:; > arguments: #(#object #selector #arguments); > control: #instead; > * level: 0*. > > > (TestMetaLink >> #execute) ast link: link. > TestMetaLink new execute. > link uninstall. > > As I understand, level:0 is necessary in order to avoid an infinite loop, > but then I get an error: > > KeyNotFound: key #RFArgumentsReificationVar not found in Dictionary > > Am I doing something wrong? Is that an error? > > Hello, > > Yes, this looks like a bug. I will fix it over the next days. > > Marcus > > > > > > > >

Oct. 31, 2018

Re: [Pharo-users] Http persistent connections

by Sven Van Caekenberghe

Hi Jimmie, > On 31 Oct 2018, at 14:01, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > Hello, > > I am writing an app which accesses a REST api. The documentation says this. > > Connection Limits > > To provide equal resources to all clients, we recommend limiting both the number of new connections per second, and the number of requests per second made on a persistent connection (see above/below). > > For new connections, we recommend you limit this to twice per second (2/s). Establishing a new TCP and SSL connection is expensive for both client and server. To allow a better experience, using a persistent connection will allow more requests to be performed on an established connection. > > For an established connection, we recommend limiting this to one hundred per second (100/s). Please see following section on persistent connections to learn how to maintain a connection once it is established. > > HTTP Persistent Connection > > This keeps the underlying TCP connection active for multiple requests/responses. Subsequent requests will result in reduced latency as the TCP handshaking process is no longer required. > > If you are using an HTTP 1.0 client, ensure it supports the keep-alive directive and submit the header Connection: Keep-Alive with your request. > > Keep-Alive is part of the protocol in HTTP 1.1 and enabled by default on compliant clients. However, you will have to ensure your implementation does not set the connection header to other values. > > > > I do not know how to reuse a connection. > > I see in ZnClient #canReuseConnection and #connectionReuseTimeout. > > Is the timeout from connection time or last request or access time? > > Does that handle everything automatically for me? > > I will be accessing this api multiple times a minute, sometimes multiple times a second for almost all the time. > > How long can I keep a persistent connection open? > > What are best practices? > > Any help and wisdom greatly appreciated. > > Thanks. > > Jimmie Yes, Zn fully and automagically supports persistent connections. In a first approach, just create one ZnClient instance, configure it with your host, etc, and then keep on reusing this instance for each (subsequent) request. Zn will keep client side connections open indefinitely. But a (busy) server will kill idle connections for sure. ZnClient will always try to connect again, before giving an error, so it effectively reconnects. You can look at client side logging by inspecting ZnLogEvent announcer to figure out what is happening. One warning though: if your app is multi user / multi threaded, you will probably need an http client instance per session. It is possibly necessary to prevent mixing up authentication info as well. HTH, Sven

Oct. 31, 2018

Http persistent connections

by Jimmie Houchin

Hello, I am writing an app which accesses a REST api. The documentation says this. Connection Limits To provide equal resources to all clients, we recommend limiting both the number of new connections per second, and the number of requests per second made on a persistent connection (see above/below). For new connections, we recommend you limit this to twice per second (2/s). Establishing a new TCP and SSL connection is expensive for both client and server. To allow a better experience, using a persistent connection will allow more requests to be performed on an established connection. For an established connection, we recommend limiting this to one hundred per second (100/s). Please see following section on persistent connections to learn how to maintain a connection once it is established. HTTP Persistent Connection This keeps the underlying TCP connection active for multiple requests/responses. Subsequent requests will result in reduced latency as the TCP handshaking process is no longer required. If you are using an HTTP 1.0 client, ensure it supports the keep-alive directive and submit the header |Connection: Keep-Alive| with your request. Keep-Alive is part of the protocol in HTTP 1.1 and enabled by default on compliant clients. However, you will have to ensure your implementation does not set the connection header to other values. I do not know how to reuse a connection. I see in ZnClient #canReuseConnection and #connectionReuseTimeout. Is the timeout from connection time or last request or access time? Does that handle everything automatically for me? I will be accessing this api multiple times a minute, sometimes multiple times a second for almost all the time. How long can I keep a persistent connection open? What are best practices? Any help and wisdom greatly appreciated. Thanks. Jimmie

Oct. 31, 2018

Re: [Pharo-users] About the IoT Hackathon last Friday

by Denis Kudriashov

Thanks Sven. (somehow skip your encouraging mail). Interesting to know impression of visitors from outside of pharo community. And how many were there? Ð¿Ð½, 22 Ð¾ÐºÑ. 2018 Ð³., 15:24 Sven Van Caekenberghe <sven(a)stfx.eu>: > Last Friday we went to the IoT Hackathon in KÃ¶ln and it was a great > experience. > > Thank you Norbert, Christian, Markus and the whole ZweiDenker team for > their generous hospitality: the accommodations where great (beautiful > office), the food and drinks super tasty, everybody friendly and welcoming. > > Thank you Allex (Oliviera, Inria/RMOD) for running the workshop and for > being so patient, friendly and tireless in helping everyone with all > aspects of getting experiments up and running. > > I knew about PharoThings [1] and TelePharo [2] before, but actually using > it in practice to experience connecting software and hardware felt a bit > like magic. Thank you Denis (Kudriashov) and Inria/RMOD for developing > these packages. > > > > Sven > > [1] https://github.com/pharo-iot/PharoThings > [2] https://github.com/pharo-ide/TelePharo > > >

Oct. 30, 2018

Re: [Pharo-users] MetaLink>>level: failing?

by Marcus Denker

> On 25 Oct 2018, at 01:33, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Hello, > > I am playing with MetaLink, really cool!, but I am having issues that I am unsure if it's some erro or if I am doing something wrong (I am using Pharo 6.1 32 bits in windows.). Consider: > > TestMetaLink>>execute > UIManager default alert: 'Actual Version'. > > And in Playground: > > | link | > > link := MetaLink new metaObject: [ :object | UIManager default alert: 'Linked Version' ]; > selector: #value:; > arguments: #(#object); > control: #instead. > > > (TestMetaLink >> #execute) ast link: link. > TestMetaLink new execute. > link uninstall. > > This works as expected, an alert with 'Linked Version' is promped. But then suppose I want to execute the actual node alongside with the linked one considering some condition: > > | link choice | > > choice := true. > link := MetaLink new metaObject: [ :object :selector :arguments | > UIManager default alert: 'Linked Version'. > choice ifTrue: [ object perform: selector withArguments: arguments]. > ]; > selector: #value:value:value:; > arguments: #(#object #selector #arguments); > control: #instead; > level: 0. > > > (TestMetaLink >> #execute) ast link: link. > TestMetaLink new execute. > link uninstall. > > As I understand, level:0 is necessary in order to avoid an infinite loop, but then I get an error: > > KeyNotFound: key #RFArgumentsReificationVar not found in Dictionary > > Am I doing something wrong? Is that an error? > Hello, Yes, this looks like a bug. I will fix it over the next days. Marcus

Oct. 29, 2018

Re: [Pharo-users] [Moose-dev] Re: Re: Re: Plotting genome scale values with Roassal

by Alexandre Bergel

Hi HernÃ¡n, > was reading a bit on the subject of plotting billions of points, and it seems there are libraries which can do it: > > http://holoviews.org/user_guide/Large_Data.html > > This is based on a technique they call datashading. > > However since I don't know Roassal internals, I cannot tell what's the fundamental difference. > Is it a big change to reproduce the datashading principles in Roassal? Sounds interesting. I do not think there is any showstopper to have this behavior in Roassal. I went through the documentation youâve sent. The idea is to select a subset of the points to visualize. So, yes, this is easy :-) > If I correctly understood the idea. I could reduce my collection of x values: > > #(15 15 15 15 15 15 15 15 20 20 20 20 32 32 32 45 45 45 45 45 45) > > having repetitions count of 8 4 3 6 respectively, and set a threshold, for example 4 to obtain: > > #(15 15 20 45) > > Is that correct? Yes. You got the point. Alexandre > On Oct 28, 2018, at 5:10 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hi Alex, > > El vie., 12 oct. 2018 a las 19:37, Alexandre Bergel (<alexandre.bergel(a)me.com>) escribiÃ³: > Hi HernÃ¡n, > > Sorry for the late reply. > > > No problem, my replay is even more delayed! > > Regarding your first question, you can do: > -=-=-=-=-=-= > g := RTGrapher new. > > d := RTData new. > d connectColor: Color blue. > d noDot. > d points: (-3.14 to: 3.14 by: 0.1). > d y: #sin. > d x: #yourself. > g add: d. > > g axisX numberOfTicks: 10; numberOfLabels: 5. > g > -=-=-=-=-=-= > > As you can see, the line "g axisX numberOfTicks: 10; numberOfLabels: 5.â allows you to set the number of ticks and the number of labels. > > > Thanks, with you and Milton's help I could set up the labels as I needed. > > Regarding your second question, where can I find the file OrderedCollection_3712516797.obj ? > > I think the attachment was truncated in the moose-dev mailing list because I received: Message body is too big: 3346796 bytes with a limit of 1000 KB > However it should be accessible through the pharo-users mailing list. Let me know if you cannot download it. > > Or, how can I reproduce it. > Anyway, I believe the problem is that you have too many points. In this case, I suggest you to reduce the number of points. > > > I was reading a bit on the subject of plotting billions of points, and it seems there are libraries which can do it: > > http://holoviews.org/user_guide/Large_Data.html > > This is based on a technique they call datashading. > > However since I don't know Roassal internals, I cannot tell what's the fundamental difference. > Is it a big change to reproduce the datashading principles in Roassal? > > > For example, a slight variation of the previous example [DO NOT RUN IT]: > -=-=-=-=-=-= > points := -3.14 to: 3.14 by: 0.000001. > > g := RTGrapher new. > > d := RTData new. > d connectColor: Color blue. > d noDot. > d points: points. > d y: #sin. > d x: #yourself. > g add: d. > > g axisX numberOfTicks: 10; numberOfLabels: 5. > g > -=-=-=-=-=-= > > The script tries to build the same graph but with 6 280 001 points. Which obviously, is way too many. > > Instead, you can do something like: > -=-=-=-=-=-= > points := SortedCollection new. > 1000 timesRepeat: [ points add: (-3.14 to: 3.14 by: 0.000001) atRandom ]. > > g := RTGrapher new. > > d := RTData new. > d connectColor: Color blue. > d noDot. > d points: points. > d y: #sin. > d x: #yourself. > g add: d. > > g axisX numberOfTicks: 10; numberOfLabels: 5. > g > -=-=-=-=-=-= > > Which only display the graph with 1000 points. > > > If I correctly understood the idea. I could reduce my collection of x values: > > #(15 15 15 15 15 15 15 15 20 20 20 20 32 32 32 45 45 45 45 45 45) > > having repetitions count of 8 4 3 6 respectively, and set a threshold, for example 4 to obtain: > > #(15 15 20 45) > > Is that correct? > > Cheers, > > HernÃ¡n > > Cheers, > Alexandre > > >> On Oct 4, 2018, at 12:49 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >> This is weird, could you check: >> >> http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2018-October/0… >> >> HernÃ¡n >> >> El miÃ©., 3 oct. 2018 a las 22:41, Alexandre Bergel >> (<alexandre.bergel(a)me.com>) escribiÃ³: >>> >>> I am lost. What are the questions? I do not see them in the mailing list. >>> >>> Alexandre >>> >>>> On Oct 3, 2018, at 11:11 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>>> >>>> Hi Alex, >>>> >>>> Thanks. Please note there are two questions related to Roassal :) >>>> I have isolated the script so you don't need to load BioSmalltalk >>>> >>>> Maybe someone can check or give a hint? >>>> >>>> El mar., 2 oct. 2018 a las 22:31, Alexandre Bergel >>>> (<alexandre.bergel(a)me.com>) escribiÃ³: >>>>> >>>>> Pretty cool! >>>>> >>>>> Alexandre >>>>> >>>>>> On Oct 2, 2018, at 2:21 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>>>>> >>>>>> <a TRMorph(28411392).png><skew_diagram_ecoli.png> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)list.inf.unibe.ch >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > <Screenshot 2018-10-12 19.35.44.png><Screenshot 2018-10-12 19.35.44.png>

Oct. 29, 2018

Re: [Pharo-users] [Moose-dev] Re: Re: Re: Plotting genome scale values with Roassal

by HernÃ¡n Morales Durand

Hi Alex, El vie., 12 oct. 2018 a las 19:37, Alexandre Bergel (< alexandre.bergel(a)me.com>) escribiÃ³: > Hi HernÃ¡n, > > Sorry for the late reply. > > No problem, my replay is even more delayed! > Regarding your first question, you can do: > -=-=-=-=-=-= > g := RTGrapher new. > > d := RTData new. > d connectColor: Color blue. > d noDot. > d points: (-3.14 to: 3.14 by: 0.1). > d y: #sin. > d x: #yourself. > g add: d. > > g axisX numberOfTicks: 10; numberOfLabels: 5. > g > -=-=-=-=-=-= > As you can see, the line "g axisX numberOfTicks: 10; numberOfLabels: 5.â > allows you to set the number of ticks and the number of labels. > > Thanks, with you and Milton's help I could set up the labels as I needed. > Regarding your second question, where can I find the file > OrderedCollection_3712516797.obj ? > I think the attachment was truncated in the moose-dev mailing list because I received: Message body is too big: 3346796 bytes with a limit of 1000 KB However it should be accessible through the pharo-users mailing list. Let me know if you cannot download it. Or, how can I reproduce it. > Anyway, I believe the problem is that you have too many points. In this > case, I suggest you to reduce the number of points. > > I was reading a bit on the subject of plotting billions of points, and it seems there are libraries which can do it: http://holoviews.org/user_guide/Large_Data.html This is based on a technique they call datashading. However since I don't know Roassal internals, I cannot tell what's the fundamental difference. Is it a big change to reproduce the datashading principles in Roassal? > For example, a slight variation of the previous example [DO NOT RUN IT]: > -=-=-=-=-=-= > points := -3.14 to: 3.14 by: 0.000001. > > g := RTGrapher new. > > d := RTData new. > d connectColor: Color blue. > d noDot. > d points: points. > d y: #sin. > d x: #yourself. > g add: d. > > g axisX numberOfTicks: 10; numberOfLabels: 5. > g > -=-=-=-=-=-= > > The script tries to build the same graph but with 6 280 001 points. Which > obviously, is way too many. > > Instead, you can do something like: > -=-=-=-=-=-= > points := SortedCollection new. > 1000 timesRepeat: [ points add: (-3.14 to: 3.14 by: 0.000001) atRandom ]. > > g := RTGrapher new. > > d := RTData new. > d connectColor: Color blue. > d noDot. > d points: points. > d y: #sin. > d x: #yourself. > g add: d. > > g axisX numberOfTicks: 10; numberOfLabels: 5. > g > -=-=-=-=-=-= > > Which only display the graph with 1000 points. > > If I correctly understood the idea. I could reduce my collection of x values: #(15 15 15 15 15 15 15 15 20 20 20 20 32 32 32 45 45 45 45 45 45) having repetitions count of 8 4 3 6 respectively, and set a threshold, for example 4 to obtain: #(15 15 20 45) Is that correct? Cheers, HernÃ¡n Cheers, > Alexandre > > > On Oct 4, 2018, at 12:49 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > This is weird, could you check: > > > http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2018-October/0… > > HernÃ¡n > > El miÃ©., 3 oct. 2018 a las 22:41, Alexandre Bergel > (<alexandre.bergel(a)me.com>) escribiÃ³: > > > I am lost. What are the questions? I do not see them in the mailing list. > > Alexandre > > On Oct 3, 2018, at 11:11 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > Hi Alex, > > Thanks. Please note there are two questions related to Roassal :) > I have isolated the script so you don't need to load BioSmalltalk > > Maybe someone can check or give a hint? > > El mar., 2 oct. 2018 a las 22:31, Alexandre Bergel > (<alexandre.bergel(a)me.com>) escribiÃ³: > > > Pretty cool! > > Alexandre > > On Oct 2, 2018, at 2:21 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > <a TRMorph(28411392).png><skew_diagram_ecoli.png> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Oct. 28, 2018

XMLHTTPParser - Highlighting error when inspecting a parsed XML/HTML in P7

by CÃ©drick BÃ©ler

Hi, When loading XMLParserHTTP, I have an error when trying to inspect a parsed stream. It complains about SHTextStylerST80 being absent. Changing SHTextStylerST80 to SHRBTextStyler fix it. But I guess it will only work in Pharo 7, not 6 ? I include the filet of the method (couldnât publish the code). Cheers, CÃ©drick

Oct. 27, 2018