March 2019 - Pharo-users - lists.pharo.org

Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Tim Mackinnon

Hey guys - Iâm wondering if someone might have a nice way of selecting the previous value in a list - but wrapping around to the last value if you are at the front. Essentially I have an exercise with some values in a collection like: list := #($a $e $o $u). And I have an index into the list, and want to loop around from index 1, back to 4 when I hit the beginning of the list. While moving forwards is pretty easy with mod - e.g. ^list at: (index \\ list size + 1) Iâm struggling with the cleanest way to do this backwards - as the following is unreadable to me (assuming index = 1) ^list at: (index - 2 \\ list size + 1) And then I tried (which isn't bad - but still not quite right). ^list before: (list at: index) ifAbsent: [ids last]. Iâm sure there is a better way to do this - but itâs alluding me? Tim

March 28, 2019

Re: [Pharo-users] Resolving DNS in-image

by Holger Freyther

> On 28. Mar 2019, at 08:02, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Holger & Norbert, > great. Regardless of how many versions exist. We should get one into the image with proper platform integration. I wasn't aware of your code but I assumed it is something you could write, hence the Paleo prefix. Now that the Paleo code is the Neo one is more funny... > NeoSimplifiedDNSClient default addressForName: 'pharo.org'. "104.28.27.35" > > One of my goals was to use it as a more reliable, non-blocking 'do we have internet access' test: > > NeoNetworkState default hasInternetConnection. "true" What is internet access and how would this be used? Is this about captive portals? With local network policy the big anycast services might be blocked but the user can still reach services. Or with deployed microservices they might reach other but not the outside? ... snip ... > The main problems are concurrent and asynchronous requests, as well as error handling. > > I would be great if we could do this well in-image. (But getting OS DNS settings is hard too). > > We should talk ;-) Agreed that getting the OS DNS settings is hard but not impossible (go seems to get away with its implementation on unix). It seems we manage to honor platform settings for http proxies and I am confident we can do it for DNS as well. I planned to solve concurrency by creating one stub resolver per request and having a shared cache. The internet can be a hostile place and DNS is an easy victim. Cache poisoning does exist and random source port, 0x20 randomization, random transaction ids, disrespecting PTMU ICMP messages are the few mitigations we have. Let's definitely talk. I hang out in the pharo discord group. :) holger

March 28, 2019

Re: [Pharo-users] Resolving DNS in-image

by Sven Van Caekenberghe

Hi Holger & Norbert, Great, but ... This did already exist in various forms, a couple of years ago I made a newer version, they can all be found in http://www.smalltalkhub.com/#!/~BenComan/DNS/ - including unit tests (but some of the older code in there is a bit stale). It covers most record types, but most of them are not used a lot. Simple usage: NeoSimplifiedDNSClient default addressForName: 'pharo.org'. "104.28.27.35" One of my goals was to use it as a more reliable, non-blocking 'do we have internet access' test: NeoNetworkState default hasInternetConnection. "true" >From the class comments: ======================= I am NeoSimplifiedDNSClient. I resolve fully qualified hostnames into low level IP addresses. NeoSimplifiedDNSClient default addressForName: 'stfx.eu'. I use the UDP DNS protocol. I handle localhost and dot-decimal notation. I can be used to resolve Multicast DNS addresses too. NeoSimplifiedDNSClient new useMulticastDNS; addressForName: 'zappy.local'. Implementation I execute requests sequentially and do not cache results. This means that only one request can be active at any single moment. It is technically not really necessary to use my default instance as I do not hold state. ==================================== I am NeoDNSClient. I am a NeoSimplifiedDNSClient. NeoDNSClient default addressForName: 'stfx.eu'. I add caching respecting ttl to DNS requests. I allow for multiple outstanding requests to be handled concurrently. Implementation UDP requests are asynchroneous and unreliable by definition. Since DNS requests can take some time, it should be possible to have multiple in flight at the same time, thus concurrently. Replies will arrive out of order and need to be matched to their outstanding request by id. If a request has been seen before and its response is not expired, it will be answered from the cache. Each incoming request is handled by creating a NeoDNSRequest object and adding that to the request queue. This triggers the start up of the backend process, if necessary. The client then waits on the semaphore inside the request object, limited by the timeout. The backend process loops while there are still outstanding requests that have not expired. It sends all unsent requests at once, and then listens briefly for incoming replies. It cleans up expired requests. When a reply comes in, it is connected to its request by id. The semaphore in the request object is then signalled so that the waiting client can continue and the request is removed from the queue. The process then loops. If the queue is empty, the backend process stops. ================ But that last one is less reliable, it was my last addition. The main problems are concurrent and asynchronous requests, as well as error handling. I would be great if we could do this well in-image. (But getting OS DNS settings is hard too). We should talk ;-) Sven > On 28 Mar 2019, at 01:32, Holger Freyther <holger(a)freyther.de> wrote: > > Norbert and me looked at using DNS for service discovery and ran into some of the limitations of the NetNameResolver[1]. In the end I created an initial DNS implementation in Pharo called Paleo-DNS[2] to overcome these. > > DNS is a protocol we use every day but rarely think of. There is an active IETF community that is evolving the protocol and finding new usages (service discovery is one of them). > > In DNS there are different types of resource records (RR). The most commonly used ones in a client ("stub") are "A" for IPv4 addresses, "AAAA" for IPv6 addresses, "CNAME" for aliases, "SRV" records. So far only support for "A" records was implemented. > > So if you are curious about DNS then this is a great opportunity to add your favorite RR implementation to it and send a PR. There are probably 20+ of them to go. ;) > > > Query example using DNS-over-TLS (DoT) to Google Public DNS > > PaleoDNSTLSTransport new > destAddress: #[8 8 4 4] port: 853; > timeout: 2 seconds; > query: (PaleoDNSQuery new > transactionId: (SharedRandom globalGenerator nextInt: 65535); > addQuestion: (PaleoRRA new rr_name: 'pharo.org.'); > addAdditional: (PaleoRROpt new udpPayloadSize: 4096)) > > > [1] It's blocking on Unix, on Mac only one look-up may occur at a time and it returns exactly one address. There is also no IPv6 support. > > [2] https://github.com/zecke/paleo-dns

March 28, 2019

[ANN] Pharo Launcher 1.8.1 released

by Christophe Demarey

Hi all, Pharo Launcher 1.8.1 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>. Here is the changelog: Bug fixes: #326 Edit image description doesn't update when editing existing description #325 Instance of MacProcess did not understand #waitForCommand: #324 sources file not found for Pharo < 3.0 #321 abort process if not responding. Uses TaskIt Improvements: #239 Mac OS menus display "SqueakOSXApp" instead of Â« PharoLauncher Â» #323 Check if pharo-version.st should be updated #322 do not try to run image without preferences if not supported by the image Thanks to all contributors, including issue reports. Regards, The Pharo team.

March 28, 2019

Resolving DNS in-image

by Holger Freyther

Norbert and me looked at using DNS for service discovery and ran into some of the limitations of the NetNameResolver[1]. In the end I created an initial DNS implementation in Pharo called Paleo-DNS[2] to overcome these. DNS is a protocol we use every day but rarely think of. There is an active IETF community that is evolving the protocol and finding new usages (service discovery is one of them). In DNS there are different types of resource records (RR). The most commonly used ones in a client ("stub") are "A" for IPv4 addresses, "AAAA" for IPv6 addresses, "CNAME" for aliases, "SRV" records. So far only support for "A" records was implemented. So if you are curious about DNS then this is a great opportunity to add your favorite RR implementation to it and send a PR. There are probably 20+ of them to go. ;) Query example using DNS-over-TLS (DoT) to Google Public DNS PaleoDNSTLSTransport new destAddress: #[8 8 4 4] port: 853; timeout: 2 seconds; query: (PaleoDNSQuery new transactionId: (SharedRandom globalGenerator nextInt: 65535); addQuestion: (PaleoRRA new rr_name: 'pharo.org.'); addAdditional: (PaleoRROpt new udpPayloadSize: 4096)) [1] It's blocking on Unix, on Mac only one look-up may occur at a time and it returns exactly one address. There is also no IPv6 support. [2] https://github.com/zecke/paleo-dns

March 28, 2019

Re: [Pharo-users] how to -- buffered read / write to stdio

by Alistair Grant

Hi Isaac, On Wed, 27 Mar 2019 at 17:18, Isaac Gouy via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > From â "Pharo 7 file streams guideline" > > https://github.com/pavel-krivanek/pharoMaterials/blob/master/Filestreams.MD > > > I have some ideas like â > > in := ZnFastLineReader on: (ZnCharacterReadStream on: Stdio stdin). out := ZnBufferedWriteStream on: > (ZnCharacterWriteStream on: Stdio stdout). > > > What would be faster / better / more Pharo ways to do buffered reads and buffered writes to stdio ? This is heading in the right direction. The buffered wrappers are normally placed on the underlying binary stream, and then wrapped with the encoder / decoder. Follow through FileReference>>writeStream and FileReference>>readStream to see how it is done for files. in := ZnFastLineReader on: (ZnCharacterReadStream on: (ZnBufferedReadStream on: Stdio stdin)). out := ZnCharacterWriteStream on: (ZnBufferedWriteStream on: Stdio stdout). Note that if you're doing terminal IO you'll need to handle stdin differently. If you're writing to a terminal on Linux / MacOS you'll need to use LFs instead of Pharo's standard CRs, so it may be worthwhile adding ZnNewLineWriterStream on: out. HTH, Alistair

March 27, 2019

Re: [Pharo-users] More info & examples on MAAdaptiveModel ?

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > I am looking for more info or usage examples of MAAdaptiveModel. The Nabble mirror site provides convenient search across many Smalltalk MLs. I don't know if any of these help, but there are several hits: http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 27, 2019

how to -- buffered read / write to stdio

by Isaac Gouy

>From â "Pharo 7 file streams guideline" https://github.com/pavel-krivanek/pharoMaterials/blob/master/Filestreams.MD I have some ideas like â Â Â in := ZnFastLineReader on: Â Â Â Â Â (ZnCharacterReadStream on: Stdio stdin).Â Â out := ZnBufferedWriteStream on: Â Â Â Â Â (ZnCharacterWriteStream on: Stdio stdout). What would be faster / better / more Pharo ways to do buffered reads and buffered writes to stdio ?

March 27, 2019

Re: [Pharo-users] Smalltalk CI - anyone have any luck excluding tests?

by Guillermo Polito

Hi Tim, I got something like what you describe that working for pillar and OSSubprocess, but putting different tests in different packages, not tags. https://github.com/pillar-markup/pillar https://github.com/pharo-contributions/OSSubprocess On Tue, Mar 12, 2019 at 6:00 PM Tim Mackinnon <tim(a)testit.works> wrote: > FYI: Just bumping this - but on investigation it looks like the Pharo > support for Tags breaks in Smalltalk CI - so top level packages with > similar names (e.g. Exercism and ExercismWIP) all seem to get included by > the include directive of âExercismâ (with no wildcard). > > This is in an issue: https://github.com/hpi-swa/smalltalkCI/issues/417 > > It does mean that many of you might be running more tests than you need > to, and it might explain strange build failures if you are trying to use > exclude. > > At some point I will have a go at fixing this, if someone doesnât beat me > to it. > > Tim > > On 6 Mar 2019, at 09:10, Tim Mackinnon <tim(a)testit.works> wrote: > > As part of Exercism we have to show our language track can build and run > tests - and they use Travis - so, pretty awesome we have that tooling. > > So it was pretty straightforward t hook in - and there are enough examples > around to support the docs for the .yml and .ston file - however I hit an > issue with the inclusion and exclusion of test files. I put an issue on > SmalltalkCI - but its sat there for 8days ( > https://github.com/hpi-swa/smalltalkCI/issues/417) so Iâm wondering if > anyone has experience with this? > > Essentially if I include my other packages âExercismDevâ and > âExercismToolsâ (see sample below - Iâve removed them from the include > list) then some of my tests run twice (I believe because the exclude of > #AllExercismTests doesnât work). I also have some environmental tests that > need improving to run more generically (Submit/Download) and again those > donât seem to be excluded. > > Itâs like âexclude" simply doesnât work - but I would think this would be > reported more widely if this was the case. So maybe I donât understand the > overlap of include/exclude etc. Anyone have any thoughts? > > Tim > > SmalltalkCISpec { > #loading : [ > SCIMetacelloLoadSpec { > #baseline : 'Exercism', > #directory : 'dev/src', > #load : [ 'dev' ], > > #platforms : [ #pharo ] > } > ], > > #testing : { > #include : { > #packages : [ 'Exercism' ] > }, > #exclude : { > #classes : [ #AllExercismTests, #ExercismTest, #ExercismSubmitTest, #ExercismDownloadTest ], > #packages : [ 'ExercismWIP'] > } > } > } > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 27, 2019

Re: [Pharo-users] how to convert this with a stream

by Roelof Wobben

March 27, 2019